Qué sucede al presentar la tarjeta MyNumber de seguro médico — cómo leer la integración entre la confirmación de elegibilidad en línea y el sistema de facturación médica en el código fuente de ORCA

En la recepción de una clínica, basta con presentar la tarjeta MyNumber de seguro médico ante el lector para que la verificación de identidad y la confirmación del seguro terminen en unos segundos. Pero, ¿qué sistemas actúan detrás de esos segundos y en qué orden? En concreto, sospecho que son pocos los ingenieros capaces de explicar cómo llega la información del seguro hasta el sistema de facturación médica, que en última instancia es quien se encarga de la facturación.

En la primera entrega expliqué que ORCA (el software estándar de recetas médicas de la Asociación Médica de Japón) es un sistema de facturación médica, y en la segunda, cómo captar desde el código fuente el panorama completo de la API de Nichi-Rece. En esta entrega, como aplicación de lo anterior, diseccionamos la confirmación de elegibilidad en línea (conocida como “onshi”) desde el lado del sistema de facturación médica.

• El flujo completo desde que se presenta la tarjeta MyNumber de seguro médico hasta que la información del seguro queda registrada en el sistema de facturación médica
• El contenido de la “integración por archivos” que conecta el terminal de confirmación de elegibilidad con el sistema de facturación médica
• El punto de entrada del lado de ORCA — las 20 APIs relacionadas con la confirmación de elegibilidad y el conjunto de tablas tbl_onshi_*
• La cronología de la adaptación normativa entre 2020 y 2026, grabada en el historial de modificaciones del COBOL

Las afirmaciones sobre el marco normativo se basan en material público del Ministerio de Salud, Trabajo y Bienestar 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).

Las premisas de este artículo

El público al que se dirige este artículo son los ingenieros que desarrollan sistemas que se integran con el sistema de facturación médica, como sistemas de recepción, historias clínicas electrónicas o sistemas de citas. No hace falta saber leer COBOL (cada fragmento citado se explica en el texto), ni se da por hecha experiencia práctica en administración médica.

Como esta es la tercera entrega de la serie, aparecen tal cual los términos explicados en las dos anteriores. Para que el artículo pueda leerse de forma independiente, resumimos aquí el vocabulario mínimo indispensable.

Índice

1. La conclusión primero — la confirmación de elegibilidad es una posta entre “cuatro protagonistas”
2. Lo mínimo indispensable sobre el marco normativo — qué es la confirmación de elegibilidad en línea
3. Entre el terminal y el sistema de facturación médica — el punto de contacto llamado integración por archivos OQS
4. El punto de entrada del lado de ORCA — contar desde el código fuente las 20 APIs relacionadas con la confirmación de elegibilidad
5. El destino de los datos — las 13 tablas tbl_onshi_*
6. Leyendo tbl_onshi_kaku — qué deja registrado una sola confirmación de elegibilidad
7. El historial de modificaciones como cronología normativa — 2020-2026
8. El reflejo en el registro de pacientes — el resultado no se convierte “tal cual” en información del seguro
9. Puntos prácticos para quienes desarrollan el sistema de integración
10. Resumen
11. Referencias

1. La conclusión primero — la confirmación de elegibilidad es una posta entre “cuatro protagonistas”

Si se resume en una sola imagen el proceso desde que se presenta la tarjeta MyNumber de seguro médico hasta que la información del seguro queda registrada en el sistema de facturación médica, aparecen cuatro protagonistas.

flowchart LR
    subgraph clinic["Dentro del centro médico"]
        CR["Lector de tarjetas<br/>con reconocimiento facial"]
        TERM["Terminal de confirmación<br/>de elegibilidad"]
        REN["Programa de integración<br/>(en Nichi-Rece, onshi-tools)"]
        ORCA["ORCA/Nichi-Rece<br/>Acumula en tbl_onshi_*"]
        UKE["Recepción y registro<br/>de pacientes"]
        CR --> TERM
        TERM <-->|"Carpeta compartida<br/>OQS〜.xml"| REN
        REN -->|"API de confirmación<br/>de elegibilidad (registro)"| ORCA
        ORCA --> UKE
    end
    TERM <-->|"IP-VPN /<br/>IPsec+IKE"| OQS["Sistema de Confirmación de Elegibilidad<br/>en Línea (Fondo de Pagos, Federación Nacional)"]

1. El lector de tarjetas con reconocimiento facial lee la tarjeta MyNumber y verifica la identidad del paciente (mediante reconocimiento facial o PIN).
2. El terminal de confirmación de elegibilidad consulta, a través de la red del Sistema de Confirmación de Elegibilidad en Línea (una IP-VPN de un operador de líneas, o una conexión IPsec+IKE por internet), el Sistema de Confirmación de Elegibilidad en Línea (operado por el Fondo de Pagos de Honorarios Médicos del Seguro Social y la Federación Nacional de Asociaciones de Seguro Nacional de Salud), y recibe la información del seguro en formato XML.
3. Entre el terminal y el sistema de facturación médica, la base es la integración por archivos. El XML de resultado se coloca en una carpeta compartida y el programa de integración lo incorpora al sistema de facturación médica. En el caso de Nichi-Rece, el programa oficial que cumple este papel es onshi-tools.
4. El resultado incorporado se acumula primero en el conjunto de tablas exclusivas de la confirmación de elegibilidad dentro de ORCA (tbl_onshi_*), y desde ahí el trabajo de recepción y registro de pacientes lo refleja en la información del paciente y del seguro.

El punto clave es que el resultado de la confirmación de elegibilidad no se escribe directamente en el maestro de pacientes, sino que se acumula primero en una tabla exclusiva. Esta estructura en dos etapas, que separa “el registro de la consulta” de “su reflejo en el maestro de pacientes”, es la clave para entender la integración de ORCA con la confirmación de elegibilidad (capítulos 6 y 8).

2. Lo mínimo indispensable sobre el marco normativo — qué es la confirmación de elegibilidad en línea

Antes de entrar en el tema del sistema, resumamos brevemente el marco normativo.

• Qué hace este sistema: es un mecanismo que confirma en línea y de forma inmediata el seguro del paciente, usando como clave la tarjeta MyNumber (tarjeta MyNumber de seguro médico) o el número de símbolo de la tarjeta de seguro. Como los cambios de asegurador (por un cambio de trabajo o de domicilio, por ejemplo) se reflejan en el momento de la consulta, el mayor beneficio desde el punto de vista de la facturación es que se reducen las devoluciones de recetas por error de elegibilidad.
• Desde cuándo: la operación plena comenzó en octubre de 2021, y desde abril de 2023 la implantación del sistema es, en principio, obligatoria para los centros médicos y farmacias con seguro. En diciembre de 2024 terminó la emisión de nuevas tarjetas de seguro médico convencionales, y el sistema ha pasado a basarse en la tarjeta MyNumber de seguro médico.
• Qué más llega además de la elegibilidad: si el paciente da su consentimiento en el lector de tarjetas, el centro médico también puede consultar la información de medicación, la de chequeos médicos específicos y la información clínica. El alcance sigue ampliándose, e incluye ahora la confirmación de elegibilidad para la asistencia médica (protección social) y la integración de la información de subsidios médicos de los ayuntamientos (PMH: Public Medical Hub).

Aunque se llama “confirmación de elegibilidad”, la situación actual es que este sistema se está convirtiendo, en la práctica, en una vía principal de integración de información médica que, partiendo de la elegibilidad, llega hasta la información clínica. Cómo se refleja esta “ampliación del alcance” en el código del sistema de facturación médica se verá como una cronología en el capítulo 7.

3. Entre el terminal y el sistema de facturación médica — el punto de contacto llamado integración por archivos OQS

¿Cómo se conecta el punto de contacto dentro del centro médico, es decir, entre el terminal de confirmación de elegibilidad y el sistema de facturación médica (o la historia clínica electrónica)?

En el material oficial dirigido a proveedores de sistemas, se presentan como métodos de integración entre los sistemas existentes y el Sistema de Confirmación de Elegibilidad en Línea, además de la integración por archivos mediante una aplicación de integración, otros métodos como la integración por aplicación web, la integración por reconocimiento facial y la integración por API web. El método central, la integración por archivos, es, a grandes rasgos, un mecanismo clásico pero fiable: se coloca un archivo XML con un nombre determinado en una carpeta determinada, y se recibe a cambio un archivo XML con la respuesta.

Nichi-Rece también sigue este método. En la página oficial de ORCA “Confirmación de elegibilidad en línea de Nichi-Rece” se indica la siguiente convención de nombres para los archivos que se intercambian con el terminal de confirmación de elegibilidad:

• Solicitud: OQSsiquc01req_Oxxxxxxxxxxxx.xml
• Resultado: OQSsiquc01res_Oxxxxxxxxxxxx.xml

y estos archivos se intercambian a través de una carpeta compartida. Quien se encarga de este intercambio de archivos y de su incorporación a Nichi-Rece es onshi-tools, la herramienta oficial disponible en versión Ubuntu y versión Windows (también se publican, junto con ella, una herramienta para vigilar el servicio de incorporación y una herramienta de verificación del entorno).

El prefijo OQS al principio es común a todos los archivos que se intercambian con el Sistema de Confirmación de Elegibilidad en Línea (el material público no aclara qué siglas representa). El nombre del archivo se compone del prefijo OQS + una parte que indica el tipo de solicitud (como siquc01) + req (solicitud) o res (resultado) + un identificador que asigna el centro médico. Con el mismo sistema, el archivo de solicitud de la información de medicación lleva el prefijo YZK, y el de la información de chequeos específicos, el prefijo TKK (capítulo 4).

Este vocabulario “OQS” también aparece en el código fuente público de ORCA. Por ejemplo, en la definición de respuesta record/xml_onlinequares1.db de la API que construye y devuelve los datos de solicitud de consulta para el programa de integración (onlinequa1, que veremos en el capítulo 4), figuran campos como InsurerNumber (número de asegurador), InsuredCardSymbol (símbolo de la tarjeta de asegurado), QualificationConfirmationDate (fecha de confirmación de elegibilidad) y LimitApplicationCertificateRelatedConsFlg (indicador de consentimiento relacionado con el certificado de aplicación del límite). En el mismo archivo de definición aparece, como comentario, el nombre del archivo de solicitud de cancelación del consentimiento de consulta para la atención domiciliaria, OQSsihvd01req_xxxxxxxxxxxx.xml (con una nota de 2024-11), de modo que la convención de nombres OQS aparece tal cual en el código fuente. Los nombres de los campos XML del Sistema de Confirmación de Elegibilidad en Línea atraviesan, tal cual, hasta la API del sistema de facturación médica. Para quien desarrolla el sistema de integración, este diseño es de agradecer, porque permite cotejar las especificaciones oficiales y el código de ORCA con el mismo vocabulario.

4. El punto de entrada del lado de ORCA — contar desde el código fuente las 20 APIs relacionadas con la confirmación de elegibilidad

Contemos ahora el punto de entrada del lado de ORCA. Con el mismo método que en la segunda entrega, al extraer las declaraciones bindapi de las definiciones LD (lddef/*.ld) de la serie 5.2, los endpoints relacionados con la confirmación de elegibilidad suman 20 en total, repartidos en tres archivos LD. En todos los casos, el nombre de la función es una transcripción literal del “nombre del componente” que figura en la cabecera del programa COBOL correspondiente.

(La fecha de creación procede del campo de fecha de creación de la cabecera de cada programa, con el formato unificado a AAAA/MM. Solo onlinequa4 figura como “2021” porque la fecha de creación de su cabecera está escrita como 21/xx/xx, ocultando el mes y el día. El texto entre paréntesis de onlinequa1 es una aclaración añadida a partir del contenido de la implementación)

Esta lista se divide en tres grupos según su función.

1. Grupo de registro (terminal → Nichi-Rece): encabezado por onlinequa2 (reconocimiento facial) y onlinequa3 (tarjeta de seguro), incluye el “registro y actualización” de la medicación, el chequeo específico, la información clínica, la imagen OCR, la asistencia médica y los subsidios médicos. Es el punto de entrada por el que el resultado que llega del terminal de confirmación de elegibilidad se vuelca en Nichi-Rece.
2. Grupo de construcción de solicitudes (programa de integración → Nichi-Rece): por su nombre, onlinequa1 parece “una API de consulta de resultados”, pero al leer la implementación se ve que no es así. Con el uuid (obligatorio) lee el registro más reciente de tbl_onshi_kaku, y a partir de ahí construye y devuelve el contenido de la solicitud de consulta (solicitud OQS) que se envía al terminal de confirmación de elegibilidad: el número de asegurador, el símbolo y el indicador de consentimiento usados en la confirmación de elegibilidad, y los nombres de los archivos de solicitud de la información de medicación y del chequeo específico (YZKsiquc01req_～.xml, TKKsiquc01req_～.xml; el “～” es una cadena que rellena el final del número de paciente con X hasta fijarlo en 20 dígitos). Es la API a la que acude el programa de integración, tras recibir una instrucción de consulta del PushAPI, para saber “qué debe preguntarle al terminal”; no es una API que busque y devuelva los resultados acumulados.
3. Grupo de obtención (historia clínica electrónica, etc. → Nichi-Rece): las 3 APIs bajo /api01rv2/ sirven para que el sistema de integración obtenga la información de medicación, el chequeo específico y la información clínica acumulados. El hecho de que estén ubicadas en api01rv2, donde se agrupan las APIs de lectura, también sigue la regla de ubicación de las APIs de Nichi-Rece que vimos en la entrega anterior.

Además, el código fuente incluye la definición record/push_onlinequa.db, que muestra que existen eventos PushAPI relacionados con la confirmación de elegibilidad (Bulk_Qualification y patient_qualification). Al leer los puntos de emisión, se ve que la pantalla de consulta, la subrutina de confirmación de elegibilidad invocada desde la recepción y el registro de pacientes (ORCSONSHI001.CBL), la pantalla de consulta masiva de pacientes con cita (ORCGY06.CBL) y el proceso por lotes (ORCBONSHIPUSH.CBL) emiten cada uno eventos de instrucción de consulta. Es decir, este evento sirve sobre todo como el canal por el que Nichi-Rece envía al programa de integración la instrucción de “ir a confirmar la elegibilidad”. Sin embargo, el contenido difiere según el emisor. La clase puede contener Rreq (solicitud de consulta), pero también hay casos en los que se coloca directamente el valor del indicador de necesidad de confirmación (Yes), y el significado del uuid tampoco es constante: en los eventos individuales es el uuid del registro de tbl_onshi_kaku, en la consulta masiva de pacientes con cita es el uuid de gestión de trabajos, y en la instrucción masiva del proceso por lotes no hay uuid. El lado receptor debe invocar de forma diferenciada onlinequa1 (construcción de la solicitud individual), onlinequaapp1 (masiva de pacientes con cita) u onlinerefall1 (registro masivo de números de consulta) según el nombre del evento, la clase y el significado del uuid. El comentario inicial de record/xml_onlinequareq1.db describe el flujo en el que el programa receptor (onshi_receiver) que recibe la notificación Push obtiene los datos de solicitud mediante onlinequa1, y, si nos limitamos a los eventos individuales, se puede leer un ciclo completo: Push (instrucción de consulta) → onlinequa1 (construcción de la solicitud) → archivo de solicitud al terminal → onlinequa2/onlinequa3 (registro del resultado). En cambio, las APIs de registro de resultado por reconocimiento facial y tarjeta de seguro (onlinequa2/onlinequa3) no emiten este evento. Si se diseña una pantalla de recepción que espera del PushAPI “la notificación en el instante en que se registra el resultado”, conviene tener presente que esa notificación nunca llegará y la espera será indefinida (capítulo 9).

5. El destino de los datos — las 13 tablas tbl_onshi_*

¿Adónde van los datos que reciben las APIs de registro? Al extraer del listado de tablas de la base de datos (lddef/orcadb.inc) las que contienen onshi en el nombre, aparecen 13 tablas. Basta con mirar sus nombres para ver que reflejan, tal cual, los tipos de información que llegan a través de la confirmación de elegibilidad.

Aquí se ve con claridad la estructura en dos etapas mencionada en el capítulo 1. Los datos que provienen de la confirmación de elegibilidad no se escriben directamente en el maestro de pacientes (tbl_ptinf) ni en las tablas del seguro, sino que aterrizan primero en tbl_onshi_*, unas tablas que conservan tal cual el vocabulario de la confirmación de elegibilidad. Es un diseño que establece una zona de amortiguación entre el vocabulario del marco normativo nacional (elegibilidad, medicación, chequeo específico, información clínica…) y el vocabulario interno del sistema de facturación médica (paciente, seguro, fondos públicos…), y se puede leer en él cómo ha ido absorbiendo las ampliaciones del marco normativo (el propio hecho de que las tablas hayan llegado a 13 es una prueba de ello) sin romper el esquema central del sistema de facturación médica.

6. Leyendo tbl_onshi_kaku — qué deja registrado una sola confirmación de elegibilidad

Al leer la tabla central tbl_onshi_kaku (definida en record/tbl_onshi_kaku.db), se ve con detalle qué registra una sola confirmación de elegibilidad. El archivo de definición es un texto que simplemente enumera nombres de campos y tipos, con este aspecto (de un total de 668 líneas, se extraen aquí solo los fragmentos que aparecen en la explicación siguiente).

tbl_onshi_kaku {
	HOSPNUM				number(2,0);
	TBL_UUID     			varchar(36);
	AITE_UUID     			varchar(36);
	OYA_UUID     			varchar(36);
	KOUHI_UUID     			varchar(36);
	FUJYO_UUID     			varchar(36);
#---> PMHUID(2025-11)
	PMH_UUID     			varchar(36);
#---> Identificación de consentimiento masivo(2024/12)
	PROCESS_CLASS			varchar(01);
	（omitido）
#---> Nombre de archivo de imagen(2022/7)
	HKNOCR_FILENAME  		varchar(100);
	（omitido）
	SHO_HKNJANUM			varchar(8);
	SHO_KIGO     			varchar(80);
	SHO_NUM     			varchar(80);
	SHO_EDABAN    			varchar(2);
	SHO_BIRTHDAY    		varchar(8);
	（omitido）
	RES_HKNJANUM			varchar(8);
	RES_KIGO     			varchar(80);
	RES_NUM     			varchar(80);
	RES_EDABAN    			varchar(2);
	RES_HONKZKKBN	    		varchar(1);
	RES_HIHKNJANAME    		varchar(100);
	（omitido）
	KENSHIN_DOUIFLG  	  	varchar(1);
	KENSHIN_TIME  		  	varchar(14);
	KENSHIN_KIGENYMD   	  	varchar(14);
	YAKUZAI_DOUIFLG   	  	varchar(1);
	YAKUZAI_TIME  		  	varchar(14);
	YAKUZAI_KIGEN  		  	varchar(14);
#---> Información de consentimiento de tratamiento(2022/7)
	SHINRYO_DOUIFLG   	  	varchar(1);

Con solo fijarse en los prefijos de los nombres de campo (SHO_/RES_/~_DOUIFLG) y en los comentarios que empiezan por #--->, que indican cuándo se añadió cada campo, ya se puede intuir la estructura y la historia de esta tabla. A continuación se explican, de forma resumida, los principales grupos de campos.

• El conjunto de uuid: además de TBL_UUID (el propio registro), aparecen AITE_UUID, OYA_UUID, KOUHI_UUID (fondos públicos), FUJYO_UUID (asistencia médica) y PMH_UUID (subsidios médicos), uuid que apuntan a registros relacionados. La confirmación de elegibilidad, la de fondos públicos, la de asistencia y la información de subsidios se registran como registros independientes, y se agrupan en un mismo evento de recepción mediante una cadena de uuid. Por eso la API de construcción de solicitudes del capítulo 4 (onlinequa1) exige especificar el uuid.
• Las condiciones de búsqueda usadas en la consulta (SHO_*): el número de asegurador, el símbolo, el número, la sucursal y la fecha de nacimiento, entre otros datos indicados al hacer la consulta. Su origen es la “información de búsqueda de confirmación de elegibilidad” (QualificationConfirmSearchInfo) del lado de la solicitud, y es un registro de “con qué condiciones se hizo la consulta” (como en el anverso de la tarjeta MyNumber no figuran el número de asegurador ni el símbolo, no se trata de “una copia del anverso de la tarjeta”).
• La información de elegibilidad recibida (RES_*): el número de asegurador, el símbolo, el número, la sucursal, la relación con el titular del seguro y el nombre del asegurado, entre otros. Es el registro de “qué respondió el sistema de confirmación de elegibilidad”. Al tener las condiciones de la consulta (SHO) y el resultado (RES) en campos separados, se puede rastrear en el propio registro la diferencia entre el símbolo y número que se tenían a mano y la elegibilidad más reciente (por ejemplo, un cambio de elegibilidad debido a un cambio de trabajo o de domicilio).
• El resultado y el estado: el resultado del procesamiento (RESULT_*), el código y mensaje de error (ERR_*), la validez de la elegibilidad (SIKAKU_YUKO), la clasificación de la tarjeta de asegurado (CARD_CLASS — cuyo origen es InsuredCardClassification, es decir, la clasificación del registro de elegibilidad devuelto, no el tipo de tarjeta física), la fecha y hora de la confirmación, el vínculo con el número de paciente (PTID), el indicador de múltiples coincidencias (FUKUSU_GAITO), entre otros.
• Sobre el consentimiento: el indicador de consentimiento no es uno solo, sino que aparece separado por tipo de información. Además del de medicación (YAKUZAI_DOUIFLG), el de chequeo específico (KENSHIN_DOUIFLG) y el de información clínica (SHINRYO_DOUIFLG), están el del certificado de aplicación del límite máximo (GENDO_DOUIFLG) y el del certificado de tratamiento de enfermedad específica (SIKKAN_DOUIFLG), y la granularidad llega hasta unidades como cirugías, nombres de enfermedades y lesiones, enfermedades infecciosas, alergias, exámenes y prescripciones. Es decir, “la consulta de información basada en el consentimiento” mencionada en el capítulo 2 está implementada como campos de tabla que distinguen, tipo por tipo, a qué se refiere cada consentimiento.

Los comentarios del archivo de definición también conservan el momento en que se añadió cada campo: el campo del nombre de archivo OCR de la tarjeta de seguro lleva la anotación de julio de 2022, y PMH_UUID, la de noviembre de 2025. La propia definición de la tabla forma parte de la historia de adaptación normativa que veremos en el próximo capítulo.

7. El historial de modificaciones como cronología normativa — 2020-2026

En la primera entrega escribí que “el historial de modificaciones de la cabecera COBOL es una cronología de las reformas normativas”. El conjunto de programas relacionados con la confirmación de elegibilidad es el ejemplo más claro de ello. A continuación se comparan la fecha de creación y el historial de modificaciones de la tabla del capítulo 4 con los movimientos del marco normativo.

En la primera entrega escribí que “la dificultad esencial de un sistema de facturación médica es seguir adaptándose al marco normativo durante décadas”, y la confirmación de elegibilidad es un ejemplo de esto en pleno curso. Desde su creación en 2020 hasta 2026, casi todos los años se ha añadido alguna API o alguna tabla; este hecho es también una advertencia práctica: no hay que tratar la integración de la confirmación de elegibilidad como algo que “se construye una vez y se acaba” (capítulo 9).

Cabe señalar que, si se compara mensualmente el código fuente público, este tipo de ampliaciones se puede detectar como diferencias en lddef y record alrededor del anuncio oficial. La vigilancia de diferencias entre instantáneas mensuales que propuse en la entrega anterior resulta especialmente eficaz en el área de la confirmación de elegibilidad.

8. El reflejo en el registro de pacientes — el resultado no se convierte “tal cual” en información del seguro

¿Cómo se refleja finalmente en el maestro de pacientes el resultado acumulado en tbl_onshi_kaku?

Al contar los programas que consultan la tabla de resultados de la confirmación de elegibilidad, los más numerosos son los 16 del trabajo de registro de pacientes (cobol/orca12/), aunque también se consulta desde el trabajo de recepción (orca11) y desde el trabajo de consulta. Basta con fijarse en los comentarios de sección del programa central del registro de pacientes, ORCGP02.CBL, para ver el flujo del procesamiento.

* Búsqueda del UID de confirmación de elegibilidad en línea
* Procesamiento de datos de confirmación de elegibilidad en línea: alta de paciente nuevo
* Información de confirmación de elegibilidad en línea: procesamiento de información básica
* Información de confirmación de elegibilidad en línea: actualización de dirección
* Información de confirmación de elegibilidad en línea: procesamiento de información del seguro
* Información de confirmación de elegibilidad en línea: adición de fondos públicos como el límite máximo
* Información de confirmación de elegibilidad en línea: verificación de la fecha de inicio de fondos públicos

Es decir, Nichi-Rece no sobrescribe mecánicamente el resultado de la confirmación de elegibilidad, sino que lo refleja descomponiéndolo en decisiones individuales dentro del contexto del trabajo de registro de pacientes, como “crear un paciente nuevo”, “actualizar el nombre y la dirección”, “cotejar y actualizar la información del seguro”, “añadir la certificación del límite máximo o los fondos públicos” y “verificar la validez de la fecha de inicio”. El resultado de la confirmación de elegibilidad es material de decisión, y la autoridad final sobre el maestro de pacientes y del seguro sigue estando, en todo momento, en manos del trabajo de registro de pacientes. La estructura en dos etapas del capítulo 1 puede interpretarse como un diseño pensado para esta delimitación de responsabilidades.

La implicación para quien desarrolla una historia clínica electrónica o un sistema de recepción es clara. Crear un atajo que refleje el resultado de la confirmación de elegibilidad directamente en el maestro de pacientes desde el propio sistema equivale a saltarse esta lógica de cotejo. Lo correcto es que el reflejo pase por el trabajo de ORCA (o por una API equivalente).

9. Puntos prácticos para quienes desarrollan el sistema de integración

Resumimos los puntos clave al tratar con el entorno de la confirmación de elegibilidad desde sistemas de recepción, historias clínicas electrónicas o sistemas de citas, entre otros.

1. Hay dos puntos de contacto. El punto de contacto con el terminal de confirmación de elegibilidad (integración por archivos OQS) y el punto de contacto con el sistema de facturación médica (API de Nichi-Rece) son cosas distintas. En la configuración de Nichi-Rece, onshi-tools se encarga de la integración e incorporación de archivos, así que lo primero es determinar si el sistema de integración necesita manejar los archivos OQS por sí mismo, o si basta con los datos ya incorporados a Nichi-Rece (la API de obtención para medicación, chequeo específico e información clínica; la API habitual de información de pacientes para el resultado reflejado en el paciente y el seguro). En la mayoría de los casos, basta con esto último.
2. Incorporar al diseño la cadena de uuid. La confirmación de elegibilidad, la de fondos públicos, la asistencia médica y los subsidios médicos se encadenan como registros separados mediante uuid (capítulo 6). Conviene verificar de antemano, en las definiciones record/ del código fuente, el diseño de la clave que permite reconstruir “una recepción”, porque más adelante resulta muy útil.
3. Confirmar en el código fuente el “significado” del evento PushAPI antes de usarlo. El evento push_onlinequa existe, pero, a juzgar por sus puntos de emisión, su uso principal es la instrucción de solicitud de consulta (Rreq); las APIs de registro de resultado (onlinequa2/onlinequa3) no lo emiten. Tampoco onlinequa1 es una API que devuelva resultados, sino una API de construcción de la solicitud (capítulo 4). Si se va a crear una funcionalidad como el indicador de “elegibilidad confirmada” en la pantalla de recepción, no se puede dar por sentado que Nichi-Rece enviará una notificación de llegada de resultado. Quien primero se entera de la llegada del resultado es el lado que lo registra (el programa de integración), así que, si se necesita esa conexión, hay que emitir una notificación al propio sistema en el mismo punto que la vía de incorporación (en el momento en que termina el proceso de registro), o bien diseñar la pantalla dando por supuesto que el reflejo se produce en el trabajo de recepción y registro de pacientes de Nichi-Rece.
4. Respetar el estado de consentimiento por tipo de información. La información de medicación, del chequeo específico y clínica llega en función del consentimiento del paciente, y tbl_onshi_kaku dispone de indicadores de consentimiento por tipo de información, como YAKUZAI_DOUIFLG, KENSHIN_DOUIFLG y SHINRYO_DOUIFLG. El hecho de que la API de obtención devuelva un dato no significa que se pueda diseñar el sistema para usarlo sin comprobar antes el estado de consentimiento del tipo correspondiente.
5. Diseñar el mantenimiento partiendo de que “cada año habrá cambios”. Como se vio en el capítulo 7, tanto las APIs como las tablas relacionadas con la confirmación de elegibilidad se amplían casi cada año. Se recomienda incorporar a la operación la vigilancia de diferencias en lddef/record del código fuente publicado mensualmente, y adquirir el hábito de leerlas como notas de la versión de adaptación normativa.
6. Empezar la verificación por las herramientas oficiales. Además del programa de integración, ORCA publica archivos de patrones para verificación, herramientas de comprobación del entorno y herramientas de obtención masiva para la asistencia médica, la atención domiciliaria y la consulta en línea. Antes de crear datos de prueba por cuenta propia, conviene revisar los medios de verificación oficiales.

10. Resumen

• La recepción con la tarjeta MyNumber de seguro médico se procesa como una posta: lector de tarjetas → terminal de confirmación de elegibilidad → (integración por archivos) → programa de integración → sistema de facturación médica. Entre el terminal y el sistema de facturación médica, la base es el intercambio de archivos XML con la convención de nombres OQS, y en Nichi-Rece el puente oficial lo cumple onshi-tools.
• El punto de entrada del lado de ORCA son las 20 APIs relacionadas con la confirmación de elegibilidad (de registro, de construcción de solicitudes y de obtención). El resultado de la confirmación de elegibilidad no se escribe directamente en el maestro de pacientes, sino que se acumula primero en las 13 tablas tbl_onshi_*, en una estructura de dos etapas donde el trabajo de registro de pacientes retiene la decisión de cotejo y actualización.
• tbl_onshi_kaku guarda por separado las condiciones de búsqueda usadas en la consulta (SHO_*) y la información de elegibilidad recibida (RES_*), lo que permite rastrear en el propio registro la diferencia entre las condiciones de la consulta y la elegibilidad más reciente. Los registros relacionados se agrupan mediante una cadena de uuid.
• El historial de modificaciones COBOL relacionado con la confirmación de elegibilidad es, desde su creación en 2020 hasta el reconocimiento facial, el OCR, la información clínica, la asistencia médica, el PMH y la consulta en línea, la cronología misma de la ampliación normativa. La integración de la confirmación de elegibilidad no es algo que “se construye y se acaba”, sino un área que debe diseñarse partiendo de un mantenimiento que siga las ampliaciones de cada año.
• Como de costumbre, todo esto se puede verificar como información de primera mano a partir del código fuente público. Como el vocabulario de las especificaciones nacionales (los nombres de campo XML de OQS) atraviesa hasta la API del sistema de facturación médica, se puede cotejar el material normativo y el código fuente con las mismas palabras.

La próxima entrega de la serie tiene previsto tratar la lógica de verificación y evaluación de las recetas de facturación. Analizaremos, también a partir del código fuente y del material público, qué comprueba respectivamente la verificación de datos dentro del centro médico (el trabajo orca41 de ORCA) y la comprobación informática del lado de los organismos de revisión y pago.

11. Referencias

• Sobre la confirmación de elegibilidad en línea (para centros médicos, centros de tratamiento, etc., y proveedores de sistemas) - Ministerio de Salud, Trabajo y Bienestar
• Portal integral para centros médicos y afines (material técnico sobre la aplicación de integración, entre otros)
• Confirmación de elegibilidad en línea de Nichi-Rece - Software estándar de recetas médicas de la Asociación Médica de Japón - ORCA Project (onshi-tools, integración por archivos OQS, material de verificación)
• Herramienta de obtención masiva de confirmación de elegibilidad en línea - Software estándar de recetas médicas de la Asociación Médica de Japón - ORCA Project
• Sobre el soporte del software estándar de recetas médicas de la Asociación Médica de Japón a la confirmación de elegibilidad en línea - Organización de Gestión de ORCA de la Asociación Médica de Japón
• Código fuente del núcleo de Nichi-Rece, serie 5.2 (instantánea publicada en julio de 2026) lddef/orca14.ld / lddef/orca71.ld / lddef/api01rv2.ld / cobol/orca14/ORAPION*.CBL / cobol/orca71/ORAPION*.CBL / record/tbl_onshi_*.db / record/xml_onlinequares1.db / record/push_onlinequa.db / cobol/orca12/ORCGP02.CBL y otros — todas las descripciones del listado de APIs, los campos de tabla y el historial de modificaciones que aparecen en el 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.

Al hacer la recepción con la tarjeta MyNumber de seguro médico, ¿cómo llega la información del seguro al sistema de facturación médica?

Cuando la identidad del paciente queda verificada en el lector de tarjetas con reconocimiento facial, el terminal de confirmación de elegibilidad consulta el Sistema de Confirmación de Elegibilidad en Línea del Fondo de Pagos de Honorarios Médicos del Seguro Social y la Federación Nacional de Asociaciones de Seguro Nacional de Salud, y recibe la información del seguro como un archivo XML. La comunicación con el sistema de facturación médica se basa, por lo general, en una integración por archivos a través de una carpeta compartida; en el caso de ORCA (Nichi-Rece), el programa de integración oficial (onshi-tools) es quien incorpora el archivo de resultado. El resultado incorporado se acumula en las tablas relacionadas con la confirmación de elegibilidad dentro de Nichi-Rece (como tbl_onshi_kaku), y desde ahí, el trabajo de recepción y registro de pacientes lo refleja en la información del paciente y del seguro.

¿La confirmación de elegibilidad en línea solo transmite información del seguro?

No, no se limita a la información del seguro. Con el consentimiento del paciente, el centro médico también puede consultar la información de medicación, la de chequeos médicos específicos y la información clínica. En el código fuente de ORCA, además del resultado de la confirmación de elegibilidad, existen APIs de registro y tablas específicas independientes para la información de medicación, la de chequeos médicos específicos y la información clínica (médica y odontológica). Además, el alcance se amplía año tras año, con la confirmación de elegibilidad para la asistencia médica (protección social) y la integración de la información de subsidios médicos (PMH).

¿Cuántas APIs relacionadas con la confirmación de elegibilidad en línea tiene ORCA (Nichi-Rece)?

Al contar las definiciones LD del código fuente público de la serie 5.2 (instantánea de julio de 2026), hay 20 endpoints relacionados con la confirmación de elegibilidad en línea. Se dividen en tres grupos: los de registro, que incorporan a Nichi-Rece el resultado de la confirmación de elegibilidad y la información de medicación, chequeos específicos y datos clínicos; los de solicitud, que construyen y devuelven los datos de la solicitud de consulta que el programa de integración envía al terminal de confirmación de elegibilidad; y los de obtención, mediante los cuales la historia clínica electrónica y otros sistemas recuperan los datos acumulados. Los tres primeros se crearon en noviembre de 2020, y desde entonces se han ido añadiendo APIs cada vez que se ampliaba el sistema.

¿Qué hay que tener en cuenta al construir un sistema de integración relacionado con la confirmación de elegibilidad en línea?

Primero, hay que partir de la base de que la comunicación entre el terminal de confirmación de elegibilidad y el sistema de facturación médica se apoya, por lo general, en el intercambio de archivos XML (el método de aplicación de integración). A partir de ahí, conviene prestar atención a que la integración con ORCA está diseñada para seguir los registros relacionados mediante un uuid, a la diferencia de función entre las APIs de registro y las de obtención, y al hecho de que la consulta de la información de medicación, chequeos específicos y datos clínicos depende del estado de consentimiento del paciente. Además, como las APIs y las tablas se amplían casi cada año por los cambios del sistema, se recomienda incorporar a la operación la vigilancia de diferencias (diff) del código fuente que se publica mensualmente.

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.