ORCA (Nichirese) no es una historia clínica electrónica — la estructura de los sistemas médicos y del sistema de facturación desde la perspectiva de un ingeniero

¿Ha oído hablar de la expresión «el ORCA de la historia clínica electrónica»? Es un nombre que aparece sin falta en cualquier proyecto de sistemas para centros médicos, pero en realidad esta forma de llamarlo contiene un malentendido. ORCA (el Software Estándar de Facturación Médica de la Asociación Médica Japonesa) no es una historia clínica electrónica.

Este artículo está dirigido a ingenieros que se enfrentan por primera vez a un proyecto de TI médica, y su objetivo es responder a las siguientes preguntas.

• Qué es ORCA y en qué lugar de la arquitectura de sistemas de un centro médico se ubica
• Qué hace, desde el punto de vista de sistemas, el «trabajo de facturación (レセプト)» que realiza el sistema de facturación médica
• Con qué tecnología está construido y qué contiene el código fuente publicado
• Qué cambia con la migración a WebORCA y qué debe tener en cuenta quien construye integraciones

Todo lo descrito se basa en información primaria disponible públicamente. Las afirmaciones sobre el código fuente son el resultado de haber descargado y verificado realmente el código fuente oficial de Nichirese, serie 5.2 (instantánea publicada el 1 de julio de 2026, con la versión 5.2.0 según el archivo VERSION).

Índice

1. Primero, la conclusión — ORCA es un «sistema de facturación médica»
2. Qué es el trabajo de facturación — la explicación más directa desde el punto de vista de sistemas
3. Diagrama de la arquitectura de sistemas de un centro médico — dónde se ubica ORCA
4. Historia y licencia del proyecto ORCA
5. Pila tecnológica — contando de verdad el contenido de los 4 millones de líneas de COBOL
6. Cómo recorrer el árbol de código fuente — qué hay y dónde
7. Puntos de entrada para la integración — la API de Nichirese, PushAPI y CLAIM
8. Qué cambia con la migración a WebORCA
9. Resumen — los puntos que un ingeniero debe tener presentes
10. Referencias

1. Primero, la conclusión — ORCA es un «sistema de facturación médica»

El «Software Estándar de Facturación Médica de la Asociación Médica Japonesa» (abreviado Nichirese), que es el núcleo del proyecto ORCA, es un sistema de facturación médica (una computadora de facturación de reclamaciones). Un sistema de facturación médica es un sistema de negocio que calcula los honorarios médicos a partir del contenido de la atención prestada y elabora el recibo de facturación (informe detallado de honorarios médicos) que se presenta al organismo evaluador y pagador.

La historia clínica electrónica y el sistema de facturación médica tienen funciones claramente diferenciadas.

El apodo «el ORCA de la historia clínica electrónica» surgió porque muchos productos de historia clínica electrónica han adoptado una configuración en la que «la parte de facturación se integra con ORCA». Como ingeniero, conviene fijar desde el principio la distinción ORCA = núcleo del sistema de facturación, historia clínica electrónica = sistema de registro clínico; hacerlo facilita ordenar todo lo que sigue.

2. Qué es el trabajo de facturación — la explicación más directa desde el punto de vista de sistemas

Para entender qué tipo de sistema es un sistema de facturación médica, el camino más rápido es conocer el flujo de ingresos de un centro médico. En la atención médica cubierta por el seguro en Japón, el paciente paga en ventanilla, en principio, entre el 1 % y el 3 % del costo, y el resto lo reclama el centro médico, mensualmente, al organismo evaluador y pagador (el Fondo de Pago de Honorarios Médicos del Seguro Social o la Federación de Asociaciones Nacionales de Seguro de Salud). Esta factura es el recibo de facturación (レセプト).

Desde el punto de vista de sistemas, el sistema de facturación médica es un mecanismo que ejecuta el siguiente ciclo mensual por lotes.

1. Diario: en recepción se verifica la elegibilidad del seguro, se registran los procedimientos (consulta, análisis, medicación, tratamientos…) y se cobra el monto a cargo del paciente, calculado automáticamente según la tabla de puntos.
2. Mensual: se agregan los procedimientos de todo el mes por unidad de paciente y seguro, y se elabora el recibo de facturación. Antes de presentarlo se realiza una verificación de datos (por ejemplo, la coherencia entre el diagnóstico y la prescripción) y se presenta como recibo electrónico (datos de レセ電).
3. A partir del mes siguiente: se atienden las devoluciones («返戻») rechazadas en la revisión y las reducciones de puntos («査定»), se corrigen y se vuelve a facturar.

Lo importante aquí es que las reglas de cálculo de puntos cambian cada dos años con la revisión de los honorarios médicos. Si el software no logra seguir el ritmo de las revisiones del catálogo maestro de puntos, los precios de los medicamentos y las reglas de cálculo, el centro médico no puede facturar correctamente. La dificultad esencial de un software de facturación médica no está en la interfaz de usuario ni en la escala, sino en mantener ese seguimiento del sistema durante décadas. El historial de modificaciones grabado en el código fuente de ORCA, que se comenta más adelante, es precisamente el registro de ese esfuerzo.

3. Diagrama de la arquitectura de sistemas de un centro médico — dónde se ubica ORCA

Si se representa en un diagrama la configuración típica de una clínica, ORCA (Nichirese) ocupa una posición cercana al centro de los sistemas internos del centro médico.

flowchart LR
    subgraph clinic["Dentro del centro médico"]
        EMR["Historia clínica electrónica<br/>Registro clínico y órdenes"]
        RSV["Sistema de recepción y citas"]
        ONS["Terminal de verificación de elegibilidad en línea"]
        ORCA["ORCA/Nichirese<br/>Sistema de facturación médica (facturación de honorarios)"]
        EMR -->|"API de Nichirese (HTTP)"| ORCA
        RSV -->|"Integración de recepción y citas"| ORCA
        ONS -->|"Información de elegibilidad del seguro"| ORCA
    end
    ORCA -->|"Recibo de facturación (facturación mensual)"| PAY["Organismo evaluador y pagador<br/>Fondo de pago y federaciones de seguro nacional"]

Los puntos clave son los siguientes tres.

• En la mayoría de los casos, el maestro de datos básicos del paciente y de la información del seguro lo mantiene ORCA. La historia clínica electrónica lo consulta y actualiza mediante la API. Quién controla la asignación del número de paciente es el primer punto a decidir en el diseño de la integración.
• Los procedimientos (qué se hizo) se envían desde la historia clínica electrónica a ORCA, y ORCA realiza el cálculo de puntos y lo enlaza con el cobro y la facturación. La historia clínica electrónica describe la atención en el «lenguaje de las órdenes», mientras que ORCA lo hace en el «lenguaje de los puntos», por lo que esa conversión (el mapeo de los códigos de procedimiento) se convierte en el punto crítico práctico de la integración.
• La presentación mensual del recibo de facturación es tarea de ORCA. Es decir, los ingresos del centro médico se facturan a través de ORCA. Una característica de este ámbito es la tensión de que un error de integración no se manifiesta como un registro clínico faltante, sino como un importe de facturación incorrecto.

4. Historia y licencia del proyecto ORCA

ORCA es un proyecto de la Asociación Médica Japonesa (Nichii). En noviembre de 2001, la «Declaración de Informatización de la Asociación Médica Japonesa» estableció la política de publicar como código abierto el software que desarrollara la asociación, y Nichirese fue el software desarrollado como núcleo de esa iniciativa. Su uso en el ámbito clínico comenzó en 2002 y desde entonces el desarrollo continúa desde hace más de veinte años.

Desde la perspectiva de un ingeniero, lo más destacable es que el código fuente de un sistema de negocio lleva publicado de forma continua más de veinte años.

• La licencia es el Contrato de Licencia de Código Abierto de la Asociación Médica Japonesa (JMA OpenSource License, versión 1.0), incluido junto con el código fuente. No es la GPL, sino un contrato propio de la asociación, que concede de forma no exclusiva y gratuita el uso del programa (incluyendo reproducción, adaptación, distribución y transmisión pública) y exige las mismas condiciones al distribuir versiones modificadas, con una estructura de tipo copyleft. La ley aplicable es la ley japonesa.
• Antiguamente había un repositorio CVS público, pero al comenzar a ofrecerse la versión comercial el CVS dejó de ser público, y actualmente el método consiste en publicar, el día 1 de cada mes, el código fuente correspondiente al día 1 del mes anterior en forma de archivo tar. Los componentes publicados son tres: el núcleo, los gastos públicos regionales y los formularios públicos, y se publican en paralelo las series 5.0, 5.1 y 5.2.
• El modelo de desarrollo y provisión también es particular. Al leer el historial de modificaciones del código fuente, en los inicios aparecen nombres de ingenieros de NACL (la empresa subcontratada para el desarrollo), y desde alrededor de 2022 los cambios pasan a registrarse a nombre de ORCAMO (la Organización de Gestión de ORCA de la Asociación Médica Japonesa). Es un modelo de división del trabajo en el que ORCAMO ofrece como versión comercial los servicios periféricos (soporte, paquetes, manuales, etc.), mientras que la implementación y el mantenimiento quedan a cargo de proveedores de soporte certificados en todo el país.

Es decir, ORCA es un software «de código abierto, pero no desarrollado de forma comunitaria al estilo de GitHub». Se puede leer el código, también se puede bifurcar (fork), pero el desarrollo principal avanza a cargo de una sola entidad, a la manera de un proveedor. Considerando que se trata del ámbito médico, donde no se permiten errores y es imprescindible seguir el ritmo del sistema regulatorio, me parece un punto de equilibrio razonable.

5. Pila tecnológica — contando de verdad el contenido de los 4 millones de líneas de COBOL

A partir de este capítulo aumentan de golpe los nombres propios, así que primero se presenta una tabla de términos. Conviene tener esta tabla a mano al leer los capítulos siguientes.

En el archivo INSTALL.ja de la serie 5.2 publicada figuran, como software necesario, MONTSUQI (panda), OpenCOBOL, PostgreSQL, MONPE, entre otros. La configuración se resume de la siguiente manera.

Como las palabras por sí solas no transmiten la magnitud, se presentan los resultados de contar de verdad la instantánea de la serie 5.2 (unos 8200 archivos y 237 MB una vez descomprimida).

Los nombres de las tablas de la base de datos son directos, y una vez que uno se acostumbra a leerlos, el trabajo administrativo se vuelve visible tal cual. La nomenclatura mezcla «abreviaturas en inglés» con «romanización del japonés», así que al devolver la parte japonesa a sus caracteres originales se capta el significado. Las principales se muestran a continuación.

La división de responsabilidades del capítulo 1 —«paciente, seguro, diagnóstico, procedimiento, puntos»— está implementada tal cual en la estructura de las tablas. El documento de definición de tablas está publicado en el sitio oficial, así que, ante cualquier duda de interpretación, se puede confirmar allí el nombre formal.

El eje de la arquitectura es MONTSUQI. Internamente, Nichirese funciona con un modelo clásico de procesamiento centralizado: el cliente Java (monsiaj) recibe las definiciones de pantalla del servidor y las muestra, y un programa COBOL del lado del servidor procesa la entrada y lee y escribe en PostgreSQL. Qué pantalla corresponde a qué programa COBOL está escrito de forma declarativa en los archivos de definición LD del directorio lddef/.

flowchart LR
    CL["monsiaj<br/>Cliente Java"] -->|"Operación de pantalla"| MW["MONTSUQI<br/>Servidor de aplicaciones"]
    API["Sistema de integración<br/>historia clínica electrónica, etc."] -->|"API de Nichirese (HTTP)"| MW
    MW -->|"Distribución según las definiciones de lddef/*.ld"| AP["Programas de negocio<br/>Unos 1750 archivos COBOL"]
    AP --> DB[("PostgreSQL<br/>285 tablas")]

Lo interesante es que el despacho de pantallas y el despacho de la API conviven en el mismo archivo de definición LD. Es decir, la API de Nichirese no es un servidor aparte añadido después, sino que está implementada como un «punto de entrada que conversa en XML en lugar de mediante pantallas», agregado sobre la misma plataforma de programas de negocio que las pantallas interactivas. Los detalles de este diseño se tratarán en el artículo siguiente.

La combinación «COBOL + middleware específico + PostgreSQL» parece muy alejada de la sensibilidad del desarrollo web moderno. Sin embargo, en el encabezado de un solo programa COBOL hay grabado, en comentarios, un historial de modificaciones desde 2002, y de ahí se puede leer que la misma base de código ha seguido adaptándose a las revisiones durante más de veinte años, hasta llegar a adaptaciones regulatorias recientes como la receta electrónica (2022) o la verificación de elegibilidad con la tarjeta de seguro vinculada al número Mi (2024). Esta configuración es también el resultado de haberse optimizado para «seguir funcionando de forma madura y estable».

6. Cómo recorrer el árbol de código fuente — qué hay y dónde

A modo de mapa para cuando se lee el código fuente, se organizan aquí los principales directorios del nivel superior.

Una advertencia práctica: la codificación de caracteres del código fuente es EUC-JP (el documento de licencia está en ISO-2022-JP). Si se abre con un editor moderno se ve corrupto, así que hay que leerlo pasándolo por iconv -f EUC-JP -t UTF-8. Es, en cierto modo, una cápsula del tiempo que conserva tal cual el estándar de los entornos Linux de la época de 2002.

7. Puntos de entrada para la integración — la API de Nichirese, PushAPI y CLAIM

Para un ingeniero de un sistema externo que necesita interactuar con ORCA, los puntos de entrada son, en la práctica, los tres siguientes.

1. La API de Nichirese — la opción recomendada actualmente. El sistema de integración envía solicitudes por HTTP para obtener información del paciente, registrar la recepción, registrar procedimientos, etc. Las operaciones de lectura usan básicamente GET o POST+XML, y las de actualización, POST+XML. La especificación de la API está publicada en el sitio oficial.
2. PushAPI — un mecanismo que notifica al sistema de integración los eventos que ocurren del lado de Nichirese (por ejemplo, instrucciones de impresión de formularios). Permite construir una sincronización de pantalla dirigida por eventos, en lugar de por sondeo (polling).
3. CLAIM — se ha usado durante mucho tiempo como protocolo estándar de intercambio de información médica, pero su soporte terminó en marzo de 2026. En el código fuente todavía quedan procesos relacionados con CLAIM, pero se da por sentado que las integraciones existentes basadas en CLAIM migrarán a la API.

Es decir, si se va a diseñar una integración con ORCA de aquí en adelante, la única opción razonable es la API de Nichirese. Y, como se mencionó antes, dado que la API está implementada sobre la misma plataforma de programas de negocio COBOL que las pantallas interactivas, cuando «no se entiende el comportamiento de la API» se puede bajar hasta el código fuente para verificarlo. El procedimiento concreto para comprender, a partir del código fuente, el panorama completo de la API (incluidos los puntos finales que no figuran en el listado oficial) se explica en el artículo siguiente.

8. Qué cambia con la migración a WebORCA

ORCA se encuentra actualmente en un período de transición hacia «WebORCA». Existen, a grandes rasgos, dos modalidades de provisión.

• WebORCA versión en la nube — la modalidad en la que se usa Nichirese como servicio en la nube ofrecido por la Organización de Gestión de ORCA. El centro médico queda liberado de la administración del servidor. La solicitud se realiza a través de un proveedor de soporte certificado, y la guía oficial estima alrededor de tres semanas entre la solicitud y el inicio del servicio. El centro médico no coloca ningún servidor en sus instalaciones, lo usa desde el navegador, y las actualizaciones de programa derivadas de las revisiones de honorarios médicos también se realizan de forma centralizada del lado de la nube. La tarifa es un régimen mensual por centro médico.
• WebORCA versión local (on-premise) — la modalidad en la que se instala en un servidor dentro del centro médico (Ubuntu) para usarlo. El entorno de provisión actual es Nichirese versión 5.2.0 sobre Ubuntu 22.04 (jammy).

En cuanto a la línea de tiempo de la migración, hay dos puntos que conviene tener presentes.

El primero es que la ruta de migración está oficialmente definida. ORCA Project publica la «Guía de migración del entorno operativo de Nichirese», que especifica como alcance el procedimiento para migrar desde el entorno tradicional (versión MONTSUQI) de Nichirese 5.1.0 / 5.2.0, que funciona sobre Ubuntu 16.04 / 18.04 / 20.04, hacia WebORCA versión local (Ubuntu 22.04 + 5.2.0). No es posible migrar en sentido inverso, es decir, hacia un sistema operativo o una versión de Nichirese anteriores.

El segundo es que no se ha publicado un plazo uniforme del tipo «todos los centros médicos deben migrar a WebORCA antes de tal fecha». Lo que en la práctica funciona como plazo es la fecha de fin de soporte, que se fija para cada combinación de sistema operativo y paquete de Nichirese; esto se publica como el «cronograma de soporte del paquete de Nichirese y del sistema operativo», y las versiones cuyo fin de soporte se acerca se anuncian individualmente. Para quien construye un sistema de integración, el método práctico para captar la línea de tiempo no es preguntarse «¿cuándo será la migración a WebORCA?», sino verificar qué versión de Ubuntu y de Nichirese usa el centro médico con el que se integra, y cuál es la fecha de fin de soporte correspondiente.

Lo importante es que en ambos casos, por dentro, se trata del mismo Nichirese. El software que se ejecuta no se convierte en algo distinto según la modalidad de provisión, y tanto los tipos de API como su comportamiento son, básicamente, comunes. Las diferencias que un ingeniero de integración debe tener presentes se concentran no en la implementación, sino en todo lo relacionado con la conexión.

• Diferencias en el punto de entrada, como que la ruta de destino de las solicitudes de la API en la versión en la nube lleva el prefijo /api, o que la configuración de la información de conexión y de autenticación difiere según la modalidad de provisión. La especificación de la API en sí es común.
• En la versión en la nube, el sistema de integración dentro del centro médico llama a la API a través de internet, por lo que hay más aspectos a considerar respecto de la ruta de red y del diseño del comportamiento degradado en caso de falla, en comparación con una configuración local.
• El código fuente que se publica cada mes incluye tal cual las definiciones para WebORCA (por ejemplo, los archivos .db.weborca bajo record/). Esto es evidencia de que el mismo árbol de código fuente sostiene ambas modalidades, y el conocimiento obtenido al leer el código fuente también es aplicable a la versión en la nube. Cabe señalar que en la versión .weborca hay definiciones en las que se ajustan cosas como el límite de elementos de un arreglo en la respuesta, así que al verificar los detalles conviene comprobar también si existe una definición específica para WebORCA.

9. Resumen — los puntos que un ingeniero debe tener presentes

• ORCA (Nichirese) no es una historia clínica electrónica, sino un sistema de facturación médica. Sostiene el núcleo de los datos de facturación —paciente, seguro, diagnóstico, procedimiento, puntos— y los ingresos del centro médico se facturan a través de él.
• La dificultad esencial de un sistema de facturación médica es seguir el ritmo de la revisión de honorarios médicos cada dos años, durante décadas. El historial de modificaciones del código fuente de ORCA es el registro real de ese esfuerzo.
• Es un sistema de negocio de código abierto que continúa desde la Declaración de Informatización de la Asociación Médica Japonesa de 2001, con el código fuente publicado mensualmente como archivo tar. La licencia no es la GPL, sino el Contrato de Licencia de Código Abierto de la Asociación Médica Japonesa.
• Por dentro se compone de 1754 archivos COBOL con unos 4,06 millones de líneas, más MONTSUQI, más 285 tablas de PostgreSQL (medición de la serie 5.2). Es una arquitectura de procesamiento centralizado en la que tanto las pantallas como la API se despachan con la misma definición LD.
• El punto de entrada actual para la integración externa es la API de Nichirese. CLAIM terminó su soporte en marzo de 2026. La migración a WebORCA está en curso, pero tanto la versión en la nube como la versión local son, por dentro, el mismo Nichirese, y el conocimiento obtenido del código fuente público es aplicable a ambas.

En la próxima entrega se leerá realmente este código fuente público y se explicará el método para comprender, a partir del código fuente, el panorama completo de la API de Nichirese (qué URL se procesa con qué programa COBOL, y cuáles son los puntos finales que no figuran en el listado oficial), junto con una tabla de correspondencia de los 137 puntos finales.

10. Referencias

• Qué es ORCA - ORCA Project
• Información técnica - Software Estándar de Facturación Médica de la Asociación Médica Japonesa - ORCA Project (publicación del código fuente, especificación de la API, documento de definición de tablas)
• API del Software Estándar de Facturación Médica de la Asociación Médica Japonesa - ORCA Project
• Software Estándar de Facturación Médica de la Asociación Médica Japonesa «ORCA» - Organización de Gestión de ORCA de la Asociación Médica Japonesa
• Sobre la versión comercial del Software Estándar de Facturación Médica de la Asociación Médica Japonesa - Organización de Gestión de ORCA de la Asociación Médica Japonesa
• WebORCA versión en la nube - ORCA Project
• Software Estándar de Facturación Médica de la Asociación Médica Japonesa [WebORCA versión en la nube] - Organización de Gestión de ORCA de la Asociación Médica Japonesa (vía de solicitud, modalidades de provisión, tarifas)
• Guía de migración del entorno operativo de Nichirese - ORCA Project (alcance y procedimiento de migración a WebORCA versión local)
• Software Estándar de Facturación Médica de la Asociación Médica Japonesa - Para quienes ya lo utilizan - ORCA Project (fuente donde se publica el «cronograma de soporte del paquete de Nichirese y del sistema operativo»)
• Código fuente del núcleo de Nichirese, serie 5.2 (instantánea publicada en julio de 2026), INSTALL.ja / doc/license.html / lddef/orcadb.inc, entre otros — todos los valores medidos en el cuerpo del artículo 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.

¿Es ORCA una historia clínica electrónica?

No. El Software Estándar de Facturación Médica de la Asociación Médica Japonesa (Nichirese), que es el núcleo del proyecto ORCA, es un sistema de facturación médica encargado de la facturación de honorarios médicos (reclamaciones). La historia clínica electrónica, que registra la atención clínica, es un software distinto, y en muchos centros médicos se usan la historia clínica electrónica y ORCA integrados mediante una API. Es más preciso pensar que la expresión «el ORCA de la historia clínica electrónica» es un apodo surgido porque suele usarse en conjunto con la historia clínica electrónica.

¿Puede cualquiera leer el código fuente de ORCA (Nichirese)?

Sí. El código fuente del núcleo del Software Estándar de Facturación Médica de la Asociación Médica Japonesa se publica bajo el Contrato de Licencia de Código Abierto de la Asociación Médica Japonesa (JMA OpenSource License), y cada día 1 de mes se puede descargar como archivo tar una instantánea correspondiente al día 1 del mes anterior. El antiguo repositorio CVS dejó de ser público al comenzar a ofrecerse la versión comercial, pero la publicación del código fuente en sí continúa.

¿Con qué tecnología está construido ORCA?

El servidor funciona sobre Linux, y la mayor parte de la lógica de negocio está escrita en COBOL. La base de datos es PostgreSQL, la plataforma de ejecución de los programas de negocio usa el middleware de código abierto MONTSUQI (panda), y en el cliente se usa, entre otros, monsiaj, escrito en Java. Al contar el código fuente de la serie 5.2, solo el COBOL suma unos 1750 archivos y más de 4 millones de líneas, y la base de datos tiene más de 280 tablas.

¿Cómo se integran la historia clínica electrónica y ORCA?

Actualmente lo recomendado es la API de Nichirese. Un sistema de integración, como la historia clínica electrónica, envía solicitudes por HTTP para obtener información del paciente, registrar procedimientos, etc. También existe PushAPI, que notifica eventos desde el lado de Nichirese. La integración mediante CLAIM (Protocolo de Intercambio de Información Médica), usada desde antes, terminó su soporte en marzo de 2026, por lo que resulta razonable diseñar cualquier integración nueva pensando en la API.

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.