¿Qué cambia la receta electrónica en el sistema de facturación médica? — Cómo aborda ORCA la receta electrónica, leído desde el código fuente

La receta electrónica, que entró en operación en enero de 2023, suele describirse como la segunda gran etapa de la transformación digital sanitaria tras la confirmación de elegibilidad en línea. Pero, ¿qué significa en concreto dar soporte a la receta electrónica para un sistema de facturación médica? Decir simplemente «digitalizar el formulario de la receta» no basta para diseñar nada.

En la primera entrega tratamos el papel del sistema de facturación médica; en la segunda, la API de Nichi-Rece; en la tercera, la confirmación de elegibilidad en línea; y en la cuarta, la verificación de recetas de facturación. En esta quinta entrega diseccionamos la receta electrónica desde el lado del sistema de facturación médica.

• Cómo cambia el flujo de prescripción con la receta electrónica (lo mínimo indispensable sobre el marco normativo)
• El panorama general del soporte de ORCA (Nichi-Rece) — la división de responsabilidades entre el núcleo y los programas de soporte
• El diseño de tbl_shoho_kanri, que gestiona el ID de receta, el número de canje y las reposiciones
• La conexión entre sistemas por la que la modalidad de emisión preferida llega desde la confirmación de elegibilidad en línea

Las afirmaciones sobre el marco normativo se basan en material público del Ministerio de Salud, Trabajo y Bienestar (MHLW) y del sitio oficial de ORCA; las afirmaciones sobre el código fuente se basan en la lectura directa del código fuente oficial de la serie 5.2 de Nichi-Rece (instantánea publicada el 1 de julio de 2026). (La forma de conseguir el código fuente se resume en el apartado 5 del capítulo 8).

Cómo leer este artículo

El público al que se dirige este artículo son los ingenieros de proveedores que desarrollan sistemas para centros médicos (historia clínica electrónica, apoyo a la prescripción, recepción, sistemas departamentales, etc.) y el personal de sistemas de información que se encarga de integrarlos dentro del centro. No se da por hecho ningún conocimiento previo sobre facturación médica o trabajo clínico, pero sí conocimientos generales de bases de datos relacionales e integración mediante API.

Lo que puede leerse de forma independiente: la estructura básica del sistema de receta electrónica (capítulo 2), la división de responsabilidades de ORCA (capítulo 4), el diseño de la tabla de gestión de recetas (capítulo 5), la integración CSV y los formularios (capítulo 6) y el entorno de verificación para proveedores (capítulo 8) pueden leerse tal cual, aunque no se hayan leído las entregas anteriores de la serie.

Entorno de referencia: las descripciones de la definición de tablas y del código fuente de este artículo se basan en Nichi-Rece serie 5.2 (edición local de WebORCA, instantánea del código fuente publicada el 1 de julio de 2026). La base de datos de Nichi-Rece es PostgreSQL, y en la configuración de la edición local de WebORCA se usa el usuario de base de datos orca con codificación UTF-8 (la versión de PostgreSQL depende del sistema operativo; en Ubuntu 22.04 LTS, para el que existe un procedimiento oficial, corresponde a la serie 14). Los nombres que empiezan por tbl_ que aparecen en el texto son tablas de esta base PostgreSQL.

Entregas que conviene leer antes: el texto da por conocidas cuatro entregas anteriores de la serie. No hace falta leerlas todas desde el principio: basta con volver a ellas cuando aparezca la referencia correspondiente.

Correspondencia de nombres y siglas: fijamos primero los términos cuyo nombre suele variar entre el material oficial y el texto.

Índice

1. La conclusión primero — la receta pasa de ser algo que se entrega a algo que se va a buscar
2. Lo mínimo indispensable sobre el marco normativo — el Servicio de Gestión de Recetas Electrónicas y el número de canje
3. Antecedentes — la receta lleva cargando un código QR desde 2001
4. El panorama general del soporte de ORCA — la división de responsabilidades entre el núcleo y los programas de soporte
5. Leyendo tbl_shoho_kanri — los atributos electrónicos de una sola receta
6. La salida de los datos — el CSV de receta electrónica y los formularios
7. La conexión con la confirmación de elegibilidad en línea — la modalidad de emisión llega desde la confirmación
8. Para proveedores — cómo preparar un entorno de verificación
9. Puntos prácticos para quienes desarrollan la integración
10. Resumen
11. Referencias

1. La conclusión primero — la receta pasa de ser algo que se entrega a algo que se va a buscar

La receta en papel era una «integración de datos en mano»: el centro médico la imprimía y el paciente la llevaba a la farmacia. Con la receta electrónica, el flujo se invierte.

flowchart LR
    subgraph clinic["Centro médico"]
        DR["Prescripción del médico"]
        RC["Sistema de facturación médica / historia clínica electrónica<br/>(en ORCA gestiona los datos de prescripción)"]
        SIGN["Programa de soporte de receta electrónica<br/>+ módulo de firma electrónica aparte<br/>(firma electrónica y envío)"]
        DR --> RC --> SIGN
    end
    SIGN -->|"Registro de datos de la receta"| EPS["Servicio de Gestión de Recetas<br/>Electrónicas (Fondo de Pagos /<br/>Federación de Seguro Nacional de Salud)"]
    EPS -->|"Número de canje (para el paciente)"| PT["Paciente<br/>(tarjeta MyNumber o número de canje)"]
    PT --> PH["Farmacia"]
    EPS -->|"Obtención de datos de la receta"| PH
    PH -->|"Registro del resultado de dispensación"| EPS2["(hacia el servicio de gestión)<br/>base de la verificación de<br/>medicación duplicada"]

• El centro médico registra los datos de la receta en el Servicio de Gestión de Recetas Electrónicas (gestionado, igual que la confirmación de elegibilidad en línea, por el Fondo de Pagos y la Federación Nacional de Asociaciones de Seguro Nacional de Salud).
• En lugar de llevar papel, el paciente se identifica en la farmacia con la tarjeta MyNumber de seguro médico, o bien comunica el número de canje (junto con los datos de la tarjeta de seguro u otro documento equivalente).
• La farmacia va a buscar los datos de la receta al servicio de gestión y registra el resultado de la dispensación.

Desde el punto de vista del sistema de facturación médica, lo esencial son dos cambios. El primero es que la receta deja de ser un formulario que se completa dentro del centro y pasa a ser datos estructurados registrados en un servicio externo. El segundo es que, al concentrarse en el servicio de gestión el historial de prescripción y dispensación, se hace posible la verificación de medicación duplicada entre distintos centros médicos y farmacias. En la cuarta entrega escribimos que cruzar datos con los de otras instituciones es, en principio, imposible dentro del propio centro; la receta electrónica puede entenderse como la infraestructura nacional que permite superar esa barrera en el ámbito de la prescripción (en el momento de prescribir, no en el de la revisión de facturación).

2. Lo mínimo indispensable sobre el marco normativo — el Servicio de Gestión de Recetas Electrónicas y el número de canje

Resumimos solo los puntos clave del marco normativo.

• Desde cuándo: la operación comenzó en enero de 2023. Es un mecanismo que se apoya en la red y en la infraestructura de la confirmación de elegibilidad en línea, y el número de centros con soporte se ha ido ampliando por etapas.
• Cómo se identifica la receta: a cada receta electrónica emitida se le asigna un ID de receta. Si el paciente se identifica en la farmacia con la tarjeta MyNumber de seguro médico, la receta se identifica seleccionándola en el lector de tarjetas (hay un paso de selección cuando existe más de una); si no usa la tarjeta MyNumber, se identifica comunicando a la farmacia el número de canje junto con los datos de la tarjeta de seguro u otro documento equivalente (el número de canje por sí solo no permite identificarla).
• Verificación de medicación duplicada: como la información de prescripción y dispensación se acumula en el servicio de gestión, el médico y el farmacéutico pueden consultar, en el momento de prescribir, el resultado de cruzar los datos con la prescripción y dispensación más recientes.
• Receta con reposición (refill): introducida en la revisión de aranceles médicos del ejercicio 2022, es una receta que puede usarse repetidamente dentro de un periodo determinado. La receta electrónica encaja bien con la gestión del uso repetido de las reposiciones, y, como se verá más adelante, las tablas de ORCA incorporan también campos de reposición.

Cómo circulan los identificadores entre el hospital y la farmacia

La estructura de la receta electrónica se ve mejor si seguimos, en orden cronológico desde la emisión hasta la dispensación, por qué manos pasan los tres identificadores: el ID de receta, el número de canje y los datos del asegurado.

sequenceDiagram
    participant MED as Centro médico<br/>(ORCA + módulo de receta/firma)
    participant EPS as Servicio de Gestión de<br/>Recetas Electrónicas
    participant PT as Paciente
    participant PH as Farmacia
    Note over MED: Prescripción confirmada y firmada electrónicamente
    MED->>EPS: Registro de los datos de la receta (incluye datos del asegurado)
    EPS-->>MED: Emisión del ID de receta + número de canje
    Note over MED: Se registra en tbl_shoho_kanri<br/>el número de canje se imprime en el comprobante
    MED-->>PT: Entrega del comprobante (con el número de canje)
    alt Identificación con tarjeta MyNumber de seguro médico
        PT->>PH: Presenta la tarjeta MyNumber y<br/>selecciona la receta en el lector de tarjetas
        PH->>EPS: Consulta con los datos del asegurado
    else Identificación con número de canje
        PT->>PH: Comunica el número de canje + los datos de la tarjeta de seguro u otro documento
        PH->>EPS: Consulta con el número de asegurado, etc. + número de canje
    end
    EPS-->>PH: Devuelve los datos de la receta (gestionados internamente por el ID de receta)
    PH->>EPS: Registro del resultado de dispensación

De este diagrama hay dos cosas que conviene extraer.

Primero, los datos de integración de sistemas nunca pasan directamente del hospital a la farmacia. Los datos autoritativos de la receta siempre pasan por el servicio de gestión. Lo que lleva el paciente es una «llave» (la tarjeta MyNumber de seguro médico o el número de canje); puede que también reciba y lleve consigo el comprobante en papel con el contenido de la receta, pero ese comprobante es solo información de referencia: los datos autoritativos que usa la farmacia para dispensar se obtienen del servicio de gestión. A cambio de no tener que construir una integración punto a punto entre hospital y farmacia, para ambos la calidad de la integración con el servicio de gestión lo es todo.

Segundo, los tres identificadores tienen roles claramente diferenciados.

En el lado de ORCA, el rastro de este ida y vuelta queda en la tabla de gestión de recetas que se ve más adelante. El ID de receta y el número de canje que devuelve el servicio de gestión en el momento de la emisión se almacenan tal cual (PRESCRIPTIONID y ACCESSCODE), y se usan tanto para imprimirlos en el comprobante como para el cotejo en las anulaciones y modificaciones.

3. Antecedentes — la receta lleva cargando un código QR desde 2001

«Convertir la receta en datos» no es en realidad algo nuevo. En el código fuente de ORCA existe un programa, cobol/common/ORCSQRCSV.CBL, «Salida de datos QR de la receta», cuya fecha de creación es septiembre de 2001. La práctica de imprimir un código QR en la receta de papel para que el sistema de la farmacia lo lea e importe en su sistema de dispensación existe desde hace más de veinte años.

Es decir, el cambio que trajo la receta electrónica no es «convertirla en datos», sino estandarizar dónde viven los datos y cómo se obtienen. El código QR era «los datos de esa única hoja» impresos en papel; la receta electrónica, en cambio, se registra en un servicio de gestión común a todo el país y cualquiera puede obtenerla (dentro de sus permisos) mediante el ID de receta. Esta diferencia es la que hizo posibles funciones transversales como la verificación de medicación duplicada. Que convivan en el mismo código fuente dos mecanismos, el antiguo y el nuevo, es una estampa muy propia de un sistema de facturación médica en plena transición.

4. El panorama general del soporte de ORCA — la división de responsabilidades entre el núcleo y los programas de soporte

Según la página oficial («Nichi-i Hyōjun Recept Software: receta electrónica»), el soporte de receta electrónica de ORCA se compone de el núcleo de Nichi-Rece + los programas de soporte de receta electrónica (la API de receta electrónica). Leyendo el código fuente público de la serie 5.2, esta línea divisoria se confirma también en la implementación.

Lo interesante es la última fila. Todo lo relacionado con la firma electrónica —el punto técnico más destacado de la receta electrónica— no aparece en absoluto en los cuatro millones de líneas del núcleo de Nichi-Rece. El núcleo se dedica por completo a seguir siendo la fuente autoritativa de los datos de prescripción, y las áreas que cambian rápido, como la firma y la comunicación, se separan en programas aparte: el mismo patrón de división que vimos en la integración de confirmación de elegibilidad en línea de la tercera entrega (el núcleo aporta la API y las tablas, y el intercambio de archivos corre por cuenta de onshi-tools). Puede interpretarse como un diseño que desacopla los cambios de especificación de la infraestructura nacional del ciclo de publicación del núcleo.

Entonces, ¿qué hay en el lado separado? Así es el elenco de programas de soporte que figura en la página oficial.

El sistema operativo compatible varía según el componente: el módulo de receta electrónica y el asistente ampliado de receta electrónica son exclusivos de Windows 11 (x64), mientras que la pantalla de entrada de prescripción funciona en Windows, Mac y Ubuntu (el soporte de Ubuntu solo en la edición local de WebORCA). Al planificar los equipos del centro, hay que tener en cuenta que los módulos relacionados con la emisión dan por hecho Windows. La división de la firma también es importante: la página oficial indica expresamente que «para introducir la receta electrónica es necesario un módulo de firma electrónica aparte». Los módulos de firma electrónica verificados (suministrados por I-O Data Device y Mitsubishi Electric IT Solutions) se encargan de la firma local mediante tarjeta HPKI (HPKI = infraestructura de clave pública del ámbito sanitario y de bienestar; una tarjeta IC que almacena un certificado electrónico capaz de acreditar cualificaciones profesionales nacionales como la de médico) y de la firma remota (autenticación FIDO, autenticación con tarjeta HPKI, autenticación con tarjeta MyNumber). Es decir, el punto más cambiante de la receta electrónica —cómo materializar la firma electrónica del médico— se ha separado tanto del núcleo de Nichi-Rece como del módulo de receta electrónica y se ha absorbido en una capa de firma dedicada. Esa es la respuesta a por qué HPKI no aparece en el código fuente del núcleo.

Cuando hay historia clínica electrónica, ¿quién asume la emisión?

Los diagramas anteriores comprimían todo lo que ocurre dentro del centro médico en un único flujo, pero en la práctica es habitual que la historia clínica electrónica y el sistema de facturación médica coexistan. En ese caso, la ruta que sigue la prescripción hasta llegar a la farmacia (el servicio de gestión) se divide, a grandes rasgos, en dos patrones.

Dibujado como diagrama, la diferencia entre los dos patrones se reduce a en qué lado está el bloque de «firma y registro».

flowchart TB
    subgraph A["Patrón A: ORCA como emisor"]
        direction LR
        EMRA["Historia clínica electrónica<br/>(orden)"] -->|"API de Nichi-Rece"| ORCAA["ORCA<br/>tbl_shoho_kanri"]
        ORCAA --> MODA["Módulo de receta electrónica<br/>+ módulo de firma electrónica"]
        MODA -->|"Registro"| EPSA["Servicio de Gestión de<br/>Recetas Electrónicas"]
    end
    subgraph B["Patrón B: la historia clínica electrónica como emisor"]
        direction LR
        EMRB["Historia clínica electrónica<br/>(soporte propio de receta<br/>electrónica + firma)"] -->|"Registro"| EPSB["Servicio de Gestión de<br/>Recetas Electrónicas"]
        EMRB -->|"Envío de la prescripción para facturación"| ORCAB["ORCA<br/>(elaboración de la factura)"]
    end

El rastro del patrón A queda claramente registrado en el código fuente. La clasificación de origen de emisión (HAKKOKBN) de la tabla de gestión de recetas que veremos en el capítulo 5 tiene un valor que significa «envío de datos provisionales por API» (confirmable en los comentarios de la cláusula COPY CPSHOHO-KANRI.INC), de modo que las prescripciones enviadas por API desde la historia clínica electrónica se gestionan en la misma tabla que las introducidas en las pantallas de ORCA. El diseño que vimos en la segunda entrega —«la API es la versión API de las funciones de pantalla»— sigue vivo también en la vía de emisión de la receta electrónica.

En ninguno de los dos patrones hay un proceso que «envíe» algo a la farmacia. En el lado de la farmacia, es el sistema de facturación de la farmacia y el sistema de dispensación quienes obtienen los datos de la receta del servicio de gestión (para la integración dentro de los sistemas de la farmacia, el MHLW publica material sobre los datos de integración entre el sistema de facturación y la historia farmacéutica electrónica). Lo primero que un proveedor del lado del centro médico debe decidir en el diseño es en qué lado —la historia clínica o ORCA— se sitúa el punto de partida de la emisión, la firma y la anulación, y, en función de esa decisión, quién debe llevar la gestión equivalente a tbl_shoho_kanri para que el ID de receta y el número de canje puedan cotejarse con los datos de facturación.

5. Leyendo tbl_shoho_kanri — los atributos electrónicos de una sola receta

El centro del lado del núcleo de Nichi-Rece es la tabla de gestión de recetas tbl_shoho_kanri. A partir de la definición (record/tbl_shoho_kanri.db) y de los comentarios en japonés de la cláusula COPY, extraemos los campos principales.

tbl_shoho_kanri {
    TBL_UUID          varchar(36);  -- uuid de identificación
    RENNUM            number(1);    -- número de secuencia (la clave primaria es HOSPNUM+TBL_UUID+RENNUM)
    SRYYMD / PTID / SRYKA / HKNCOMBI  -- fecha de atención, paciente, departamento, combinación de seguro
    SHOHO_KEITAI      varchar(1);   -- clasificación de emisión de la receta (electrónica/papel)
    PRESCRIPTIONID    varchar(36);  -- ID de la receta
    ACCESSCODE        varchar(16);  -- número de canje
    REFILL_NUM        number(1);    -- número de reposiciones
    REFILL_ZAIKAISU   number(3);    -- días de la receta de reposición
    CANCEL_TIME / CANCEL_UNDO_TIME  -- fecha/hora de anulación de la receta y fecha/hora de UNDO de la anulación
    CHANGE_TIME / CHANGE_UNDO_TIME  -- fecha/hora de modificación y fecha/hora de UNDO de la modificación
};

Solo con esta tabla se transparenta la práctica de la receta electrónica.

• Tiene, en pareja, campos para el ID de receta (36 dígitos) y el número de canje (16 dígitos). Las claves correspondientes a las dos formas de identificación vistas en el capítulo 2 (tarjeta MyNumber / número de canje) figuran tal cual como atributos del registro. (El número de canje en la operación actual tiene 6 dígitos; los 16 son la capacidad de la columna. Sería más prudente no implementar el número de dígitos como un valor fijo.)
• Tanto la anulación como la modificación tienen su propia fecha/hora de UNDO. Como la receta electrónica es un dato ya registrado en el servicio de gestión, anular una prescripción dentro del centro obliga también a anular el registro, y hasta puede llegar a anularse esa anulación (restaurarla). Lo que en la época del papel era «romper y volver a escribir» se ha convertido en gestión de transiciones de estado.
• La reposición es un atributo desde el principio. El número de reposiciones y los días de prescripción forman parte de los campos básicos de gestión de recetas, de modo que la gestión del ciclo de vida orientada al uso repetido está incorporada al diseño.

El uso de un uuid para la identificación es, además, un idioma compartido con la tabla de confirmación de elegibilidad en línea (tbl_onshi_kaku) vista en la tercera entrega. Sin embargo, la clave primaria no es el uuid en solitario, sino la clave compuesta por número de centro médico + uuid + número de secuencia (RENNUM), un diseño en el que pueden colgar varias filas del mismo uuid. Cuando el sistema de integración maneje datos equivalentes a esta tabla, tenga cuidado: si trata el uuid como única clave de fila, varias filas quedarán colapsadas en una sola.

6. La salida de los datos — el CSV de receta electrónica y los formularios

Antes de continuar, resumimos en un único diagrama cómo circulan los datos dentro de ORCA, incluyendo tanto la tabla del capítulo 5 como la conexión con la confirmación de elegibilidad en línea del capítulo 7.

flowchart LR
    ONS["Confirmación de elegibilidad<br/>en línea (en recepción)"] -.->|"Preferencia de modalidad<br/>de emisión SHO_SHOHO_KEITAI"| TBL
    NYURYOKU["Entrada de la prescripción<br/>(pantalla / API de Nichi-Rece)"] --> TBL["tbl_shoho_kanri<br/>ID de receta, número de canje,<br/>reposición, anulación/modificación"]
    TBL -->|"Salida CSV<br/>(ORCSEPRECSV)"| MOD["Módulo de receta electrónica<br/>(arma y envía la solicitud de registro)"]
    SIGNM["Módulo de firma electrónica<br/>(firma electrónica)"] -.->|"Firma"| MOD
    MOD -->|"Registro"| EPS["Servicio de Gestión de<br/>Recetas Electrónicas"]
    EPS -.-> RET["ID de receta y número de canje<br/>(se registran en tbl_shoho_kanri y<br/>van al comprobante ORCHC02)"]

La salida por la que los datos de prescripción pasan a los programas de soporte es ORCSEPRECSV.CBL (Salida de datos CSV de receta electrónica). El historial de modificaciones de su cabecera es, en sí mismo, un registro de la adaptación al marco normativo.

• Octubre de 2022, creación nueva — implementado antes del inicio de la operación en enero de 2023
• Junio de 2023, soporte para reflejar el maestro de posología — como la receta electrónica también codifica la posología (cómo se toma el medicamento), se hizo necesaria la coherencia con el maestro de posología
• 2024: soporte del número de reposiciones (enero), soporte de la anotación del número de entrega (marzo), soporte de la preferencia del paciente por el medicamento original (agosto), nombre en kanji a 40 bytes (diciembre) — movimientos del marco normativo, como el registro de la preferencia del paciente en la atención selectiva de medicamentos de larga cotización, se traducen directamente en nuevos campos
• 2025: soporte del aviso de código ficticio (enero), soporte de la fecha de caducidad (abril), soporte del número de dígitos de número de pagador / número de beneficiario (julio) — incluso dos años y medio después del inicio de la operación, las modificaciones siguen a un ritmo de varias al año

Como muestra este historial, la integración CSV de la receta electrónica no es «se construye una vez y ya está», sino que sigue cambiando en tiempo real. En el lado de los formularios, las versiones con soporte de receta electrónica se suman a los programas de formularios de receta (las familias ORCHC02 y ORCHCM19). Que los formularios no desaparezcan al pasar a la receta electrónica se debe a que persisten tanto el comprobante que se entrega al paciente (incluida la notificación del número de canje) como la coexistencia continuada con la operación en papel. La realidad de este periodo de transición no es «digitalización = fin de los formularios», sino que los formularios se mantienen mientras cambia el lugar donde vive el dato autoritativo, y la estructura de archivos del código fuente refleja esto con toda honestidad.

7. La conexión con la confirmación de elegibilidad en línea — la modalidad de emisión llega desde la confirmación

Visto como flujo interno del centro, la primera bifurcación de la receta electrónica es «¿este paciente recibirá la receta en formato electrónico o en papel?». ¿De dónde viene esta información? La respuesta es la confirmación de elegibilidad en línea.

Cuando el paciente se identifica con la tarjeta MyNumber de seguro médico, puede elegir en el lector de tarjetas cómo desea recibir la receta (electrónica o papel). Esa elección llega al sistema de facturación médica junto con el resultado de la confirmación de elegibilidad. La tabla de resultados de confirmación de elegibilidad tbl_onshi_kaku, que leímos en la tercera entrega, tiene un campo de modalidad de emisión de la receta (SHO_SHOHO_KEITAI) que, según el comentario de la definición, se añadió en julio de 2022. La definición XML de la confirmación de elegibilidad en línea también contiene un campo PrescriptionIssueSelect (modalidad de emisión de la receta). Medio año antes del inicio de la operación de la receta electrónica (enero de 2023), ya se había ampliado el punto de recepción del lado de la confirmación de elegibilidad: incluso el orden en que se fue apilando el marco normativo puede leerse en las fechas del código fuente.

La modalidad de emisión decidida en recepción se fija después, en el momento de prescribir, como tbl_shoho_kanri.SHOHO_KEITAI para cada receta individual. El traspaso de datos entre sistemas —confirmación de elegibilidad (recepción) → prescripción (consulta) → servicio de gestión (emisión)— está conectado a nivel de diseño de tablas. La descripción que hicimos en la tercera entrega de la confirmación de elegibilidad en línea como «la vía troncal por la que fluye la información a partir de la elegibilidad» queda confirmada también en la receta electrónica.

8. Para proveedores — cómo preparar un entorno de verificación

Lo primero con lo que se tropieza en el desarrollo de la integración de receta electrónica no es el código, sino el hecho de que «las vías para conseguir la documentación técnica y el entorno de pruebas están dispersas». Organizamos la información oficial por punto de entrada.

1) Obtención de la documentación técnica — «ONS de instituciones médicas»

Las especificaciones primarias para proveedores de sistemas están reunidas en «ONS de instituciones médicas» (医療機関等ONS), el sitio de información para proveedores que ofrece el Fondo de Pagos (aquí también están la especificación de la interfaz externa del sistema de confirmación de elegibilidad en línea y demás, y la especificación de condiciones de registro del Servicio de Gestión de Recetas Electrónicas). Es un sitio distinto del portal general que usan los centros médicos, y requiere darse de alta como proveedor. Además, en la página del MHLW «Receta electrónica (para proveedores de sistemas)» se publican el manual técnico para proveedores de sistemas (versión 2.04 en el momento de escribir esto) y material de integración para sistemas de farmacia. Cabe señalar que la «Guía de implementación de la receta electrónica» de JAHIS (一般社団法人保健医療福祉情報システム工業会, la asociación sectorial que reúne a los proveedores de sistemas de información sanitaria y elabora normas y guías de implementación), en su Ver. 1.2 de 2021, es material de estudio anterior al actual Servicio de Gestión de Recetas Electrónicas; las fuentes primarias de la especificación vigente son, en todo caso, las especificaciones y el manual técnico de ONS. Tenga cuidado, porque en las búsquedas suele aparecer primero el documento de JAHIS.

2) Obtención de certificados y tarjetas para pruebas

Como la emisión de la receta electrónica exige la firma electrónica (HPKI) del médico o del dentista, también hacen falta certificados para las pruebas. Los puntos de contacto para obtenerlos varían según el uso.

• Tarjetas de prueba HPKI (para firma y para autenticación): el punto de contacto varía según la profesión. Para médicos, se obtiene enviando por correo postal el formulario de solicitud desde la página «Para proveedores» del Centro de Certificación Electrónica de la Asociación Médica Japonesa (JMACA; la autoridad certificadora HPKI que gestiona la Asociación Médica Japonesa, que emite la tarjeta de cualificación médica = tarjeta HPKI). Para dentistas y farmacéuticos, se sigue el procedimiento de la autoridad certificadora correspondiente (MEDIS = Centro de Desarrollo de Sistemas de Información Médica, y la autoridad certificadora de la Asociación Japonesa de Farmacéuticos).
• Uso del entorno de verificación del certificado electrónico secundario HPKI (firma sin tarjeta) y tarjetas MyNumber de prueba: se solicita por correo electrónico en la ventanilla específica de MEDIS.
• Como advertencia, incluso en condiciones normales, una tarjeta HPKI de producción tarda de 2 a 3 meses desde la solicitud hasta la emisión. Además, en el momento de escribir esto, el aviso de JMACA indica que, por escasez de tarjetas IC, se ha suspendido temporalmente la emisión de tarjetas físicas (tarjeta de cualificación médica) y se está siguiendo una operativa de emisión anticipada del certificado electrónico secundario HPKI (sin tarjeta). Antes de planificar algo que dé por sentado el uso de tarjetas, es más seguro comprobar el estado actual de la emisión y si es viable sustituirla por la firma sin tarjeta.

3) Verificación de conexión y comprobación previa al lanzamiento

La verificación de la conexión con el servicio de gestión se realiza siguiendo las instrucciones que llegan a través de ONS, pero lo que conviene leer primero como desarrollador es la «Lista de autocomprobación relativa al lanzamiento de software con soporte de receta electrónica (confirmación de finalización de pruebas)» (versión 4.2 en el momento de escribir esto) publicada por el MHLW. El planteamiento es que el proveedor confirma la finalización de las pruebas con esta lista antes de lanzar el software, lo que, dicho de otro modo, significa que ya existe de partida una lista oficial de «qué hay que probar». Trabajar hacia atrás a partir de esta lista es el camino más rápido para construir el plan de pruebas. Además, como alternativa a implementar el procesamiento de firma por cuenta propia, existe el módulo común de firma de receta electrónica, y las páginas del MHLW también incluyen una lista de proveedores de servicios de apoyo a la implantación.

4) El entorno de verificación del lado de ORCA

Si se verifica con la configuración de Nichi-Rece más programas de soporte, lo natural es levantar la edición local de WebORCA en un servidor de verificación y configurarla siguiendo el manual oficial de instalación del módulo de receta electrónica y el asistente ampliado de receta electrónica. Como se vio en el capítulo 6, la receta electrónica está enlazada con el maestro de posología, así que si no se completa antes la actualización del maestro, la verificación de los datos de salida no será real. Además, los códigos de posología estándar tienen fecha de caducidad. En el momento de escribir esto, la página oficial anuncia que a partir del 1 de agosto de 2026 algunos códigos de posología estándar dejarán de poder usarse en la receta electrónica, y que si queda algún mapeo a un código caducado, Nichi-Rece emitirá un código ficticio. No basta con actualizar el maestro: incluya también en sus verificaciones la comprobación del remapeo de los códigos de posología que use su propio sistema (una prueba que hoy pasa puede convertirse en salida de código ficticio en cuanto se cruce la fecha de caducidad). Al igual que con los archivos de patrones de verificación de la confirmación de elegibilidad en línea presentados en la tercera entrega, la regla de oro es comprobar los medios de verificación oficiales antes de inventar datos de prueba propios.

5) Leer el código fuente por cuenta propia

Todas las afirmaciones de este artículo sobre la implementación se han confirmado consultando directamente el código fuente público. Cualquiera puede hacer lo mismo. Así es el camino.

• Obtención: el código fuente se publica en la página de información técnica del ORCA Project. El día 1 de cada mes se publica, en forma de archivo tar (zip), el código fuente tal como estaba el día 1 del mes anterior; el núcleo de la serie 5.2 está en https://ftp.orca.med.or.jp/pub/src/jma-receipt.r_5_2_branch.zip (no se puede listar el directorio, así que hay que obtenerlo a través del enlace de la página de información técnica). Los gastos públicos regionales (jma-receipt-kk) y los formularios (jma-receipt-forms) están en archivos separados.
• Dónde mirar: la definición de las tablas está bajo record/ (por ejemplo, record/tbl_shoho_kanri.db), los comentarios en japonés de los campos están en la cláusula COPY de COBOL (cobol/copy/CPSHOHO-KANRI.INC), y el procesamiento propiamente dicho está bajo cobol/common/ (por ejemplo, ORCSEPRECSV.CBL). Cuando se quiera captar el panorama completo de las tablas, el «Documento de definición de tablas de la base de datos de Nichi-i Hyōjun Recept Software», disponible en la misma página de información técnica, sirve de índice.
• Cómo avanzar en la lectura: buscar por los comentarios en japonés depende de la codificación de caracteres del código fuente, así que lo más fiable es seguir primero los identificadores alfanuméricos.

# La definición de la tabla de gestión de recetas y la cláusula COPY con los nombres de campo + comentarios en japonés
less record/tbl_shoho_kanri.db
less cobol/copy/CPSHOHO-KANRI.INC

# Localizar los programas que manejan el ID de receta
grep -rl "PRESCRIPTIONID" cobol/ | head

# El comentario inicial de los programas COBOL contiene el historial de modificaciones (es un registro de la adaptación normativa)
head -60 cobol/common/ORCSEPRECSV.CBL

• Seguir los cambios: si se conservan los archivos mensuales y se hace diff -r contra el del mes anterior, se pueden detectar cambios antes que el anuncio oficial (apartado 5 del capítulo 9).

9. Puntos prácticos para quienes desarrollan la integración

Puntos clave al involucrarse en la receta electrónica desde sistemas de historia clínica electrónica, apoyo a la prescripción, recepción, etc.

1. Trace primero la división de responsabilidades. La configuración estándar de ORCA divide la gestión de los datos de prescripción en el núcleo de Nichi-Rece, y la firma y la comunicación con el servicio de gestión en los programas de soporte de receta electrónica. Diseñe primero, función por función, con qué lado debe hablar su propio sistema de integración. Decidir implementar la firma por cuenta propia implica también asumir la operación de las tarjetas HPKI.
2. Trate el ID de receta y el número de canje como entidades. Si se mantiene el modelo de datos «receta = documento impreso», la gestión de estados como anulación, modificación, UNDO y reposición acaba siendo un añadido a posteriori. La composición de campos de tbl_shoho_kanri es un excelente libro de referencia para diseñar la entidad de prescripción en la era de la receta electrónica (aunque lo que contiene es el número de reposiciones y los días, no el estado del número de usos consumidos ni el número de usos restantes. Diseñe partiendo de que el número de usos restantes es un dato que pertenece al ciclo de vida del lado de la dispensación y debe tratarse por separado).
3. La modalidad de emisión llega desde el punto de recepción, pero solo con identificación MyNumber. La preferencia electrónica/papel se incluye en el resultado de la confirmación de elegibilidad únicamente cuando la identificación se hizo con la tarjeta MyNumber de seguro médico. En pacientes que no la usan (por ejemplo, con documento de confirmación de elegibilidad), la operación pasa a ser que el personal o el médico confirmen la intención en el mostrador o en la consulta, así que si se depende únicamente de SHO_SHOHO_KEITAI queda abierta una vía por la que se llega a la prescripción sin haber confirmado la intención del paciente. Incluya en el diseño tanto el recorrido que arrastra la información de recepción hasta la consulta y la prescripción, como el flujo de confirmación para cuando no exista un valor procedente del lector de tarjetas.
4. Dé por sentado que dentro del «papel» hay dos tipos. La receta en papel seguirá existiendo hasta que todos los pacientes y todas las farmacias estén en electrónico, pero en los centros que ya han introducido la receta electrónica existe la práctica de registrar también en el servicio de gestión la información de prescripción y dispensación de una receta en papel (una receta en papel con número de canje), que entonces sí entra dentro de la verificación de medicación duplicada. En lugar de una dicotomía «electrónico/papel», lo realista es diseñar la bifurcación partiendo de tres opciones: electrónico, papel registrado en el servicio de gestión y papel con la operativa tradicional de código QR.
5. Tenga un mecanismo para seguir las ampliaciones del marco normativo. El soporte del maestro de posología, el soporte de la reposición… el código fuente alrededor de la receta electrónica se actualiza todos los años. Como venimos recomendando a lo largo de la serie, monitorizar los diffs de record/ y cobol/ en el código publicado mensualmente vuelve a ser aquí una forma de detectar cambios más rápido que el anuncio oficial.

10. Resumen

• La receta electrónica es un mecanismo que convierte la receta de «papel que lleva el paciente» en «datos estructurados registrados en un servicio de gestión y obtenidos mediante el ID de receta / número de canje». La concentración de la información de prescripción y dispensación ha hecho posible la verificación de medicación duplicada entre centros médicos y farmacias.
• El soporte de ORCA se compone de el núcleo de Nichi-Rece (gestión de datos, salida CSV, formularios) + la familia de programas de soporte (módulo de receta electrónica, asistente ampliado de receta electrónica, etc.) + un módulo de firma electrónica necesario por separado (producto verificado de un proveedor). La ausencia de la firma electrónica en el código fuente del núcleo es la prueba de esta división de responsabilidades.
• El centro del lado del núcleo es tbl_shoho_kanri, que gestiona por cada receta el ID de receta, el número de canje, el número de reposiciones/días y la anulación/modificación con sus fechas de UNDO. Su convivencia en el código fuente con la salida de código QR de la receta (desde 2001) refleja la verdadera naturaleza del cambio: de «convertir en datos» a «estandarizar dónde viven».
• La modalidad de emisión electrónica/papel llega en el momento de la recepción como parte del resultado de la confirmación de elegibilidad en línea, cuando la identificación es con MyNumber (el punto de recepción del lado de la confirmación se añadió por adelantado en el código fuente, en julio de 2022). Para pacientes con documento de confirmación de elegibilidad u otros, hace falta confirmar la intención por separado en el mostrador o en la consulta. La forma en que se apila el marco normativo —de la confirmación de elegibilidad a la receta electrónica— está conectada a nivel de las tablas y de las definiciones XML.

La próxima entrega de la serie tiene previsto abordar, o bien una «edición de base de datos» que lea el esquema completo de la base de datos de ORCA, o bien la operativa práctica de la monitorización mensual de diffs del código fuente.

11. Referencias

• Receta electrónica - Ministerio de Salud, Trabajo y Bienestar
• Nichi-i Hyōjun Recept Software: receta electrónica - ORCA Project (programas de soporte de receta electrónica y formularios objetivo)
• Sobre el soporte de receta electrónica de Nichi-i Hyōjun Recept Software - ORCA Project
• Receta electrónica (para proveedores de sistemas) - Ministerio de Salud, Trabajo y Bienestar (manual técnico, especificación de condiciones de registro, lista de autocomprobación previa al lanzamiento)
• Para proveedores (tarjetas de prueba HPKI) - Centro de Certificación Electrónica de la Asociación Médica Japonesa
• API de impresión de recetas - ORCA Project
• Información técnica - ORCA Project (publicación mensual del código fuente, documento de definición de tablas de la base de datos)
• Configuración de operación con dos equipos (Nichi-Rece 5.2 en adelante) - ORCA Project (que la base de datos de la edición local de WebORCA es PostgreSQL)
• HPKI: infraestructura de clave pública del ámbito sanitario y de bienestar, información de la autoridad de certificación electrónica - MEDIS
• Código fuente del núcleo de Nichi-Rece, serie 5.2 (instantánea publicada en julio de 2026): record/tbl_shoho_kanri.db / cobol/copy/CPSHOHO-KANRI.INC / cobol/common/ORCSEPRECSV.CBL / cobol/common/ORCSQRCSV.CBL / record/tbl_onshi_kaku.db y otros — todas las afirmaciones sobre la implementación en este texto se basan en esta instantánea

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿En qué se diferencia la receta electrónica de la receta en papel?

En lugar de que el paciente lleve la receta en papel a la farmacia, los datos de la receta se registran en el Servicio de Gestión de Recetas Electrónicas (gestionado por el Fondo de Pagos y la Federación Nacional de Asociaciones de Seguro Nacional de Salud), y la farmacia los obtiene en línea. El paciente puede identificarse con la tarjeta MyNumber de seguro médico y seleccionar la receta correspondiente en el lector de tarjetas, o bien comunicar a la farmacia el número de canje junto con los datos de la tarjeta de seguro (el ID de receta es un identificador interno del sistema, no un número que maneje el paciente). El mayor cambio es que, al concentrarse la información de prescripción y dispensación en el servicio de gestión, se pueden realizar comprobaciones como la de medicación duplicada entre distintos centros médicos y farmacias.

¿Cómo da soporte ORCA (Nichi-Rece) a la receta electrónica?

El papel se divide en dos partes. El propio Nichi-Rece gestiona la tabla (tbl_shoho_kanri) que guarda el ID de receta, el número de canje, el número de reposiciones y el historial de anulación/modificación, además del mecanismo que exporta el contenido de la receta como CSV y los formularios de receta adaptados a la receta electrónica. Por otro lado, la firma electrónica (firma local con tarjeta HPKI o firma remota) y la comunicación con el Servicio de Gestión de Recetas Electrónicas corresponden a los programas de soporte —el módulo de receta electrónica, el asistente ampliado de receta electrónica, etc.— y a un módulo de firma electrónica adicional (existen productos de proveedores verificados). El hecho de que en el código fuente público de Nichi-Rece no aparezca ningún procesamiento de firma electrónica confirma también esta división de responsabilidades.

¿Qué es el número de canje?

Es el número que utiliza el paciente para recoger una receta electrónica en la farmacia sin usar la tarjeta MyNumber de seguro médico. La farmacia identifica la receta a partir de este número junto con los datos de la tarjeta de seguro, y la obtiene del servicio de gestión. En la operación actual, el número de canje tiene 6 dígitos, y en el código fuente de ORCA (Nichi-Rece) se guarda en la tabla de gestión de recetas como ACCESSCODE (un campo de hasta 16 dígitos), gestionado junto con el ID de receta.

¿Qué relación hay entre la confirmación de elegibilidad en línea y la receta electrónica?

Están conectadas en el punto de entrada. Cuando el paciente se identifica con la tarjeta MyNumber de seguro médico, puede indicar en el lector de tarjetas si desea recibir la receta en formato electrónico o en papel, y esa información (la modalidad de emisión de la receta) llega al sistema de facturación médica junto con el resultado de la confirmación de elegibilidad. En el código fuente de ORCA también se añadió, en julio de 2022, un campo de modalidad de emisión de receta en la tabla de resultados de confirmación de elegibilidad, lo que muestra que la confirmación de elegibilidad en línea y la receta electrónica se apoyan en la misma base.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.