KomuraSoft LLC
Contáctenos
Menú

¿Dónde se producen el ajuste y la devolución? — Desglosamos la lógica de verificación de recibos de facturación a partir del código fuente de ORCA y los materiales públicos

· Actualizado el: · · TI médica, ORCA, Recibo de facturación, Verificación de recibos, Ajuste y devolución, Sistema de facturación médica

Los ingresos que un centro médico recibe en ventanilla son solo una parte; la mayor parte del ingreso depende de la facturación de recibos que se presenta una vez al mes. Por eso, en el día a día, expresiones como «me ajustaron la reclamación» o «llegó una devolución» tienen un peso considerable. Sin embargo, para el ingeniero que trabaja con estos sistemas, dónde y con qué lógica se producen el ajuste y la devolución es un tema sorprendentemente difícil de ver.

En la primera entrega de la serie tratamos el papel del sistema de facturación médica; en la segunda, la API de Nichirese; y en la tercera, la confirmación de elegibilidad en línea. En esta ocasión desglosamos la lógica de verificación y revisión, el núcleo del trabajo de facturación, alineando en fila los «puestos de control» por los que pasa cada recibo.

  • El significado exacto de los términos devolución, ajuste y reexamen
  • La verificación dentro del centro médico — la implementación de la verificación de datos y la tabla maestra de verificación de ORCA
  • La verificación del recibo electrónico antes de la presentación
  • La verificación del lado del organismo evaluador y pagador — verificación informática, verificación cruzada y verificación longitudinal
  • Que el sistema de facturación médica y el lado evaluador comparten, estructuralmente, la misma arquitectura de «tabla de reglas + motor»

Las descripciones sobre el lado institucional se basan en los materiales públicos del Fondo de Pago, los colegios médicos y otras entidades; las descripciones sobre la implementación de ORCA se basan en la lectura real del código fuente oficial de la serie 5.2 de Nichirese (instantánea publicada el 1 de julio de 2026).

El conjunto mínimo de términos — con esto basta para seguir el artículo

El sector médico está lleno de siglas y abreviaturas, así que antes de nada fijamos el mínimo indispensable. A partir de aquí, lea el artículo con este significado en mente.

Término Significado
Recibo de facturación (レセプト) Informe detallado de honorarios médicos. Es el detalle que resume, por paciente y por mes, «qué atención se prestó y cuánto se factura», y que el centro médico elabora para reclamar la parte cubierta por el seguro
Honorarios médicos y puntos La contraprestación de la atención cubierta por el seguro. A cada procedimiento médico y cada medicamento se le asignan puntos, y 1 punto equivale a 10 yenes
Sistema de facturación médica (レセコン) Computadora de facturación de reclamaciones. Es el nombre genérico de los sistemas que elaboran recibos de facturación
Nichirese / ORCA Software Estándar de Facturación Médica de la Asociación Médica Japonesa. Es un sistema de facturación médica que ofrece la Asociación Médica Japonesa y, como su código fuente es público, se puede leer y verificar su implementación, tal como hace este artículo
Recibo electrónico (レセ電) El Sistema de Procesamiento Electrónico de Recibos, y el archivo de recibo electrónico que maneja. Es el mecanismo para facturar con datos electrónicos en lugar de en papel
Organismo evaluador y pagador La entidad que revisa los recibos presentados y paga en representación del asegurador. Para el seguro de los trabajadores es el Fondo de Pago (Fondo de Pago de Honorarios Médicos del Seguro Social); para el seguro nacional de salud y las personas mayores es el Kokuhoren (Federación de Asociaciones Nacionales de Seguro de Salud)
Asegurador La entidad que administra el seguro médico público: cajas de seguro de salud, la Asociación de Seguro de Salud de Japón (Kyokai Kenpo), los municipios, etc. Es, en última instancia, la fuente del pago
Devolución / ajuste La devolución es el rechazo de un recibo (puede corregirse y volver a facturarse); el ajuste es el aumento o la reducción de puntos por la revisión (en la práctica, casi siempre una reducción). Más detalles en el capítulo 2

Si se resume en una sola imagen, el recibo de facturación y el dinero fluyen así.

Consulta y copagoRecibo (reclamación)Reclamación revisadaPagoPagoAviso de devolución o ajustePacienteCentro médico(elabora el recibo con el sistema de facturación)Organismo evaluador y pagador(Fondo de Pago y Kokuhoren)Asegurador

Este artículo trata la parte central de ese esquema: «qué se verifica y dónde, mientras el recibo pasa del centro médico al organismo evaluador y pagador».

El lector al que va dirigido este artículo es el ingeniero que trabaja con sistemas para centros médicos (integración con el sistema de facturación médica, historia clínica electrónica, sistemas departamentales) y el personal de sistemas de información dentro del centro médico. No se presupone experiencia práctica en administración médica. Tampoco se presupone haber leído las entregas anteriores de la serie, aunque leerlas facilita entender el contexto.

Entrega de referencia Qué se da por conocido en este artículo
Entrega 1: qué es el sistema de facturación médica Que el sistema de facturación médica es «un sistema que sigue continuamente a la institución». Por qué la tabla de reglas del capítulo 4 tiene un período de vigencia
Entrega 2: la API de Nichirese Cómo está construida la API con la que un sistema externo llama a ORCA. La base de la API de verificación de datos de los capítulos 3 y 5
Entrega 3: la confirmación de elegibilidad en línea El mecanismo de confirmación de elegibilidad. Dónde se produce el «error de elegibilidad» que causa una devolución

Índice

  1. Primero, la conclusión — el recibo pasa por «cuatro puestos de control»
  2. Resumen mínimo de términos — devolución, ajuste, aumento/reducción de puntos y reexamen
  3. Puesto de control ① — leer en el código fuente la labor de verificación de datos de ORCA
  4. La tabla maestra de verificación — el diseño de las tablas de la familia tbl_chk
  5. La verificación en el momento de la entrada y la API — la verificación no ocurre solo a fin de mes
  6. Puesto de control ② — la verificación del recibo electrónico, el control de los datos de facturación
  7. Puestos de control ③④ — la verificación informática del organismo evaluador y pagador, y las verificaciones cruzada y longitudinal
  8. Ambos lados son una arquitectura de «tabla de reglas + motor» — el mapa para el ingeniero
  9. Puntos prácticos — qué se puede hacer del lado del sistema para mejorar la precisión de la verificación
  10. Resumen
  11. Referencias

1. Primero, la conclusión — el recibo pasa por «cuatro puestos de control»

Si se resumen en una sola imagen los principales puntos de control por los que pasa un recibo, desde que se introduce en el centro médico hasta que se paga, queda así.

Organismo evaluador y pagador (Fondo de Pago, Kokuhoren)Dentro del centro médicoFacturación en líneaReclamación revisada③ Verificación informática+ verificación cruzada y longitudinal④ Verificación por el personal+ comité de revisiónEntrada diaria de datos(verificación en el momento de la entrada)① Labor de verificación de datos(ORCA: orca41)② Verificación del recibo electrónico(control de los datos de facturación)AseguradorPago(al centro médico, a través del organismo evaluador y pagador)Devolución (rechazo) y ajuste (reducción de puntos)(se notifica al centro médico → corrección y nueva facturación)
  • Puesto de control ① (verificación del contenido): el sistema de facturación médica comprueba la coherencia del contenido clínico, por ejemplo si «el diagnóstico y el medicamento coinciden» o si «falta algún ítem por calcular». En ORCA, esto lo realiza la labor de verificación de datos.
  • Puesto de control ② (verificación de los datos de facturación): se examina el recibo electrónico que se va a presentar (el archivo de recibo electrónico) como dato de facturación, desde el formato de registro hasta los requisitos de las observaciones. En ORCA, esto es la verificación del recibo electrónico.
  • Puesto de control ③ (revisión automática): la verificación informática del organismo evaluador y pagador recorre mecánicamente los recibos con reglas basadas en avisos, notificaciones oficiales y prospectos de medicamentos, y marca los ítems sospechosos. Aquí se incluyen también la verificación cruzada, que coteja los recibos médicos y de dispensación de un mismo paciente, y la verificación longitudinal, que compara con los recibos de meses anteriores.
  • Puesto de control ④ (revisión humana): a partir de las marcas puestas por el sistema, el personal revisa los recibos, y el comité de revisión toma la decisión final. El resultado se notifica al centro médico como devolución o ajuste.

Lo esencial que un ingeniero debe entender es que los puestos de control ① y ③ realizan «el mismo tipo de verificación» desde ambos lados. El centro médico quiere «detectar antes de presentar las reclamaciones que puedan quedar atrapadas en la revisión»; el lado evaluador quiere «detectar las reclamaciones que no cumplen las reglas». Esta simetría se manifiesta, como veremos más adelante, en la similitud de la arquitectura de implementación (en ambos casos, tabla de reglas + motor).

2. Resumen mínimo de términos — devolución, ajuste, aumento/reducción de puntos y reexamen

Repasamos de la forma más breve posible los términos institucionales.

Término Significado Respuesta del centro médico
Devolución (返戻) El rechazo del recibo, que se devuelve al centro médico. Por defectos de registro, errores de elegibilidad, consultas sobre el contenido, etc. Se puede corregir y volver a facturar a partir del mes siguiente
Ajuste (査定) El aumento o la reducción de los puntos como resultado de la revisión (en la práctica, casi siempre una reducción) El importe se reduce en esa medida. Si hay disconformidad, cabe la solicitud de reexamen
Aviso de ajuste de puntos La notificación que comunica el contenido del ajuste (qué ítem se redujo y en cuántos puntos, con un código de motivo) Analizar el motivo para prevenir que se repita y decidir si se presenta una solicitud de reexamen
Verificación cruzada La verificación que coteja electrónicamente, para el mismo paciente y el mismo mes, el recibo médico (u odontológico) con el recibo de dispensación Una discrepancia entre el diagnóstico de quien prescribe y el contenido dispensado también afecta a quien prescribió
Verificación longitudinal La verificación que compara el recibo del mes en curso de un mismo paciente con el de varios meses anteriores Un caso típico es superar el límite de veces que se puede calcular un ítem (por ejemplo, una vez cada tantos meses)

Lo importante es que la devolución significa «hay que rehacerlo» y el ajuste significa «la reducción queda confirmada»: el peso de sus consecuencias es distinto. Y la verificación cruzada y la verificación longitudinal detectan errores que no se pueden descubrir mirando un único recibo por separado (límites de veces que cruzan meses, discrepancias entre lo médico y lo dispensado). Sin embargo, su naturaleza es diferente: el cotejo con recibos de otra institución (la verificación cruzada) es, por principio, imposible dentro del propio centro médico, mientras que la comparación con los meses anteriores del propio centro (equivalente a la verificación longitudinal) sí es posible dentro del alcance de los datos propios. Entendiendo esta línea divisoria, el objetivo del trabajo de verificación es «detectar dentro del centro médico todo lo que se pueda detectar dentro de él».

3. Puesto de control ① — leer en el código fuente la labor de verificación de datos de ORCA

Cómo obtener el código fuente y cómo seguir este artículo

A partir de aquí leemos el código fuente. Cualquiera puede hacer lo mismo en su propio entorno, así que primero dejamos anotado el camino para llegar hasta él.

  • Cómo obtenerlo: el código fuente se publica en la página de información técnica del ORCA Project. Cada día 1 de mes se publica, como archivo tar (zip), el código correspondiente al 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 desde el enlace de la página de información técnica).
  • Archivos que se abren de aquí en adelante: la estructura del negocio está en lddef/orca41.ld, las pantallas en screen/D0x.glade, el procesamiento de verificación en cobol/orca41/ y cobol/orcabt/, y la definición de la tabla de reglas en record/tbl_chk*.db y cobol/copy/CPCHK.INC.
  • Cómo seguir el rastro: la búsqueda en japonés depende de la codificación de caracteres, así que lo más fiable es guiarse primero por los identificadores alfanuméricos.
# Estructura de la labor de verificación de datos (lista de pantallas, lotes y APIs)
less lddef/orca41.ld

# Grupo de programas por lotes que forman el núcleo de la lógica de verificación
ls cobol/orcabt/ORCDTCHK*.CBL

# Definición de la tabla de reglas y de los campos, con comentarios en japonés
less record/tbl_chk.db
less cobol/copy/CPCHK.INC

También conviene fijar de antemano cómo se llama cada tipo de archivo. Aunque no esté familiarizado con COBOL ni con GTK, con entender solo estos tres términos podrá leer lo que sigue.

Nombre Qué es en realidad
Definición LD (lddef/*.ld) Un archivo de definición que enumera, para cada negocio (número de menú), qué pantallas, qué programas y qué APIs cuelgan de él. Equivale al índice de ese negocio
Cláusula COPY (cobol/copy/*.INC) La definición común de campos que cada programa incorpora con la sentencia COPY de COBOL. Contiene el nombre, el tipo y la longitud de cada campo, y en ORCA lleva comentarios en japonés
glade (screen/*.glade) El archivo de definición de pantalla de GTK (el conjunto de herramientas de interfaz gráfica muy usado en Linux). El diseño de pantalla, creado con el diseñador de interfaces Glade, se guarda en XML y se carga en tiempo de ejecución

La estructura del negocio

La verificación de datos de ORCA corresponde al menú de negocio número 41 y, en el código fuente, al directorio cobol/orca41/ y al archivo lddef/orca41.ld. Si se observa la definición LD, la estructura queda clara de inmediato.

  • Lado de pantallas: partiendo de D01, «Instrucción de verificación de recibos», se ramifica hacia D02 («Instrucción individual»), D03 («Registro de configuración de ítems a confirmar») y D04, «Confirmación del contenido del error»; D05 («Lista de configuración de excepciones») se invoca desde D04 (la ramificación está en el procesamiento de transición de ORCGD01.CBL y ORCGD04.CBL, y el nombre de cada pantalla se puede confirmar en el título de su screen/D0x.glade).
  • Lado del motor: el núcleo de la lógica de verificación no está en las pantallas, sino en el grupo de programas por lotes cobol/orcabt/ORCDTCHK000 a 011.CBL. Desde las pantallas, ORCGDSUB02.CBL invoca este lote como un trabajo (con el ID de shell ORCBSD1), de modo que la pantalla interactiva y el procesamiento de verificación quedan separados.
  • Lado de la API: está vinculada, con bindapi "datacheckv3", la API que invoca la verificación de datos desde el exterior (ORCGDAPI01).

La definición de la solicitud de la API (record/xml_data_checkv3req.db) es lo que muestra, de la forma más compacta, la especificación de entrada de este negocio.

data_checkv3req {
    Request_Number             varchar(02);   -- 00=obtener información / 01=ejecutar verificación / 02=consultar estado
    Karte_Uid                  varchar(36);   -- identificador de quien llama (obligatorio al ejecutar; error si está vacío)
    Orca_Uid                   varchar(36);   -- identificador del trabajo (obligatorio al consultar estado; se recibe en la respuesta de ejecución)
    Perform_Month              varchar(07);   -- año y mes de atención objetivo
    Start_Day / End_Day        varchar(02);   -- rango de fechas
    InOut                      varchar(01);   -- clasificación de hospitalización/ambulatorio
    Check_Insurance_Information { Id; }[6];   -- seguros objetivo (máximo 6)
    Check_Item_Information    { Id; }[22];    -- ID de ítem a confirmar (máximo 22)
    Patient_Information { Patient_ID; }[100]; -- pacientes objetivo (máximo 100)
};

(El significado de los valores de Request_Number se puede confirmar en la definición de constantes y en las ramificaciones de ORCGDAPI01.CBL; la verificación obligatoria de Karte_Uid y Orca_Uid se confirma en ORCGDAPI01S01.CBL y ORCGDAPI01S02.CBL. Es un diseño asíncrono: la ejecución (01) corre como un trabajo, y con el Orca_Uid recibido en la respuesta de ejecución se sigue el progreso mediante la consulta de estado (02))

Lo llamativo es que Check_Item_Information es un arreglo de 22 elementos. La verificación de datos no es una única inspección, sino un conjunto de comprobaciones llamadas «ítems a confirmar», y está construida de forma que se elige cuáles ejecutar en cada corrida. La pantalla de confirmación del contenido del error (D04.glade) también tiene un mecanismo de registro de excepciones, con el que se puede suprimir cada error individual marcándolo como «no verificar (este mes)» o «no verificar (siempre)» (las excepciones se guardan en la tabla tbl_chkreigai). Es la forma de un motor de reglas práctico, que permite ir eliminando los falsos positivos a través de la operación diaria.

Por cierto, en D04.glade figuran como datos de ejemplo «Pontal» (un antiinflamatorio y analgésico) y «úlcera gástrica», con la clasificación de tabla maestra de verificación «1: medicamento y diagnóstico». Incluso en el ejemplo de la definición de pantalla queda grabado el caso de uso representativo que veremos en el siguiente capítulo: la verificación de la correspondencia entre medicamento y diagnóstico.

4. La tabla maestra de verificación como tabla de reglas — el diseño de las tablas de la familia tbl_chk

El conocimiento de «qué es correcto» que maneja la verificación de datos se reparte en dos lugares distintos.

  • Lo que tiene la tabla de reglas (la tabla maestra de verificación): la correspondencia entre medicamentos y procedimientos médicos, como el diagnóstico de indicación, las contraindicaciones o el cálculo conjunto. No está codificado en COBOL, sino guardado como datos en un conjunto de tablas.
  • Lo que tiene el código del programa: las verificaciones relacionadas con la estructura básica del sistema, como la coherencia del seguro, el número de símbolo o los días reales de atención. Está implementado directamente en el grupo de lotes (ORCDTCHK*), y en el historial de modificaciones también aparecen añadidos del lado del código, como «adaptación de la verificación de datos por número de sucursal» o «adaptación de la verificación de datos por número de seguro laboral».

Es decir, es un error pensar que «con solo mantener actualizada la tabla maestra de verificación cambian todas las reglas». La tabla de reglas se ocupa únicamente del primer ámbito; el segundo solo cambia con una modificación del programa.

Con esta premisa, si se extraen las tablas relacionadas de la lista de tablas (lddef/orcadb.inc):

Tabla Función (según su nombre y definición)
tbl_chk El cuerpo principal de la tabla maestra de verificación
tbl_chk_master La parte suministrada de fábrica (su estructura es casi idéntica a la de tbl_chk)
tbl_chk_user La parte registrada por el usuario (el centro médico)
tbl_chkreigai Las excepciones de verificación (no generar este error)
tbl_chksnd / tbl_chktrd / tbl_chk005 Almacenamiento de reglas con una forma distinta (con cotejo de cadenas de diagnóstico, clasificación de mismo día o mismo mes, etc.)

La estructura de la regla se puede confirmar en record/tbl_chk.db y en la cláusula COPY cobol/copy/CPCHK.INC (con comentarios en japonés en los campos). Si se extrae solo la esencia, una línea de regla tiene esta forma.

Clasificación de verificación (CHKKBN) + código del procedimiento (SRYCD) + período de vigencia (YUKOSTYMD〜YUKOEDYMD)
  → conjunto de códigos correspondientes (CDKBN + CD), clasificación de hospitalización/ambulatorio, clasificación de procesamiento

Es decir, se trata de una regla declarativa del tipo: «para el código de procedimiento X, dentro del período Y, debe corresponder alguno de los códigos del conjunto Z (o bien no pueden coexistir)». Qué tipos de reglas existen queda enumerado en la pantalla de emisión de informes de la tabla maestra de verificación (screen/X91.glade).

  • Medicamento y diagnóstico / diagnóstico y medicamento (correspondencia del diagnóstico de indicación)
  • Procedimiento y diagnóstico / diagnóstico y procedimiento
  • Medicamento y contraindicación de uso conjunto
  • Medicamento con contraindicación de administración y diagnóstico
  • Cálculo conjunto de procedimientos (dentro del mismo día, del mismo mes o de la misma cuenta)
  • Ítems no calculados entre procedimientos relacionados
  • Verificación del número de veces calculado

Lo interesante es que «medicamento y diagnóstico» y «diagnóstico y medicamento» forman un par. Al invertir el sentido, también cambia lo que se quiere detectar.

Sentido de la regla Lo que expresa Lo que permite detectar Dónde se guarda
Medicamento → diagnóstico Si se prescribe este medicamento, hace falta este diagnóstico La falta del diagnóstico de indicación tbl_chksnd
Diagnóstico → medicamento Si existe este diagnóstico, debería existir este medicamento o esta prueba Los ítems no calculados tbl_chk005

Sin embargo, en la implementación no se trata de una búsqueda inversa sobre una única tabla. Al leer el programa de informes (cobol/orca103/ORCHXLST.CBL) se ve que, tal como muestra la tabla anterior, se gestionan con tablas y claves distintas, así que hay que tener presente que registrar un sentido no hace que el sentido inverso también funcione. El motivo de que exista un período de vigencia es que la regla debe seguir la revisión de honorarios médicos que ocurre cada dos años y las altas y bajas del precio de los medicamentos; la idea de que «seguir al sistema es la esencia del sistema de facturación médica», que vimos en la primera entrega, también atraviesa el diseño de la tabla de reglas.

Cabe señalar que no todas las reglas caben en la única forma anterior. tbl_chksnd y tbl_chk005 tienen una forma que maneja la cadena de texto del diagnóstico (BYOMEI) y el tratamiento del diagnóstico de sospecha, mientras que tbl_chktrd tiene una forma con clasificación de mismo día o mismo mes (DAYMONTHKBN): la propia tabla de reglas está normalizada en formas distintas según el tipo de verificación. El que se hable de «tabla de reglas» no significa que sea un único esquema, y ese es un punto a tener en cuenta al leer la implementación.

5. La verificación en el momento de la entrada y la API — la verificación no ocurre solo a fin de mes

La verificación de datos es una inspección mensual por lotes, pero no es la única verificación que existe. En el código fuente también se puede confirmar un mecanismo que funciona más arriba en el flujo, en el mismo momento de la entrada diaria de datos.

  • API de verificación de contraindicaciones de uso conjunto: /api01rv2/contraindicationcheckv2 (programa responsable ORAPI021R4V2, «Devolución de información de medicamentos con contraindicación de uso conjunto», con la cabecera fechada en 2016). Es una API que, al recibir el paciente y el medicamento, devuelve la información de contraindicación correspondiente, y permite construir una integración en la que la historia clínica electrónica consulta a Nichirese en el momento mismo de introducir la prescripción.
  • API de verificación de datos: el datacheckv3 visto en el capítulo anterior. Como permite invocar el lote mensual sin manejar la pantalla, se puede organizar una operación del tipo «cada noche, verificar automáticamente lo del mes en curso y sacar la lista de errores a la mañana siguiente».

Aquí hay una lección universal de diseño: cuanto más cerca del origen se corrige un error, más barato sale corregirlo. Un error detectado en la verificación de datos de fin de mes termina corrigiéndose de golpe para todo el mes, pero si se detecta la contraindicación de uso conjunto en el momento de introducir la prescripción, se puede resolver en unos segundos (cabe señalar que esta API solo cubre las contraindicaciones de uso conjunto; la verificación de correspondencias, como la falta del diagnóstico de indicación, sigue siendo responsabilidad de la verificación mensual de datos, y no queda cubierta de antemano en el momento de la entrada). El hecho de que el mecanismo de verificación de ORCA esté organizado en varios niveles —«en el momento de la entrada (API) → mensual (verificación de datos) → antes de la presentación (verificación del recibo electrónico)»— es la aplicación práctica de este principio.

6. Puesto de control ② — la verificación del recibo electrónico, el control de los datos de facturación

Mientras que la verificación de datos observa «la coherencia del contenido clínico», justo antes de la presentación aguarda otra verificación distinta: la verificación del recibo electrónico. Su objeto es el archivo de recibo electrónico, y examina la corrección como dato de facturación, es decir, el formato de registro y la presencia de los registros obligatorios.

Las condiciones de esta verificación se publican en PDF en el sitio oficial de ORCA como la «Especificación de condiciones de verificación del recibo electrónico» (en tres modalidades: seguro médico, accidentes laborales y atención posterior). Es decir, ORCA no solo publica la verificación de contenido (la tabla maestra de verificación se puede consultar en informes y CSV), sino que también documenta y publica la especificación de condiciones de la verificación del recibo electrónico, de modo que se puede confirmar «qué se verifica» en una fuente primaria.

Sin embargo, no es exacto considerar la verificación del recibo electrónico como «una inspección puramente de formato». Al examinar el código fuente se ve que del lado del procesamiento del recibo electrónico están implementados un subprograma que verifica los requisitos de redacción de los comentarios del recibo (cobol/common/ORCSRECECOMCHK.CBL, incorporado en 2018) y la verificación del historial de cálculo de los honorarios de gestión y orientación relacionados con la consulta a distancia y similares (ORCSRECESRCHK.CBL); y el script Ruby del procesamiento mensual (en el repositorio, scripts/monthly/receden_check.rb.in, una plantilla que en la instalación se coloca como receden_check.rb) llega incluso a verificar la coherencia con el catálogo maestro de puntos y el catálogo maestro de diagnósticos (que Ruby conviva con el mundo de COBOL es otro de los aspectos interesantes de este código fuente). A grandes rasgos, el reparto es «verificación de datos = contenido clínico, verificación del recibo electrónico = datos de facturación», pero el límite no es estricto, y parte de la verificación de significado la asume la verificación del recibo electrónico; si se entiende esta división de forma tajante, se puede confundir el origen de un error. El punto práctico clave es que solo al pasar por ambas se obtiene «un recibo listo para presentar a revisión».

7. Puestos de control ③④ — la verificación informática del organismo evaluador y pagador, y las verificaciones cruzada y longitudinal

El recibo presentado entra en la revisión del organismo evaluador y pagador (el Fondo de Pago para el seguro de los trabajadores; el Kokuhoren para el seguro nacional de salud y las personas mayores). Lo importante aquí es que una parte de las reglas de verificación del lado evaluador también se publica.

En la página del Fondo de Pago titulada «publicación relacionada con la verificación informática» se ofrecen dos tipos de archivos como objeto de publicación (ambos en formato CSV, y su alcance se va ampliando de forma gradual).

Archivo publicado Fundamento Volumen (según la página pública, al momento de escribir esto)
Condiciones de verificación de la sede central Avisos y notificaciones oficiales (reglas del cuadro de puntos de honorarios médicos) Unos 306.000 casos
Tabla maestra de verificación Prospectos de los medicamentos (indicación, posología, etc.) Unos 45.000 casos

Fíjese en el nombre: el lado del Fondo de Pago también usa el término «tabla maestra de verificación». La estructura que separa la gestión de las reglas basadas en avisos y notificaciones de las reglas basadas en prospectos corresponde con precisión a la estructura de ORCA, que guarda las reglas de cálculo de puntos en el programa y las indicaciones de los medicamentos en la tabla maestra de verificación.

Por otro lado, hay verificaciones que no se publican. En la página pública se indica expresamente que se estudia con cautela la publicación de casos que requieren confirmar el contenido de la columna de observaciones, casos que exigen un juicio médico, o casos relacionados con la indicación de medicamentos o procedimientos. Además, el Fondo de Pago explica repetidamente que la verificación informática se limita a marcar los ítems sospechosos, y que no se ajusta de forma mecánica, sino que pasa por la revisión del personal y el juicio del comité de revisión. Que «verificación informática» no sea igual a «ajuste automático» es algo que también quienes trabajan del lado del sistema deben entender con precisión.

Y luego están la verificación cruzada y la verificación longitudinal, mencionadas en el capítulo 2. Estas dos, que se consolidaron a partir de 2012, no son una inspección de un recibo aislado, sino una inspección de la relación entre recibos. Tracemos aquí la línea divisoria con precisión. La verificación cruzada (el cotejo entre el recibo médico y el recibo de dispensación de un mismo paciente) tiene como contraparte el recibo de otra institución, la farmacia dispensadora, así que, por principio, no se puede sustituir con una verificación dentro del centro médico. En cambio, lo equivalente a la verificación longitudinal (la comparación del mes en curso con los meses anteriores de un mismo paciente) sí es posible dentro del centro médico, en la medida del historial de facturación propio. Gestionar con rigor, dentro del alcance de los datos propios, los cálculos con límite de veces y los diagnósticos correspondientes a las recetas dispensadas fuera del centro es una medida práctica para reducir las observaciones en la verificación cruzada y la longitudinal.

8. Ambos lados son una arquitectura de «tabla de reglas + motor» — el mapa para el ingeniero

Si se condensa todo lo anterior en una sola imagen, el mundo de la verificación de recibos se ve así.

  Lado del centro médico (ORCA) Lado evaluador (Fondo de Pago)
Tabla de reglas Tabla maestra de verificación (familia tbl_chk) Condiciones de verificación de la sede central + tabla maestra de verificación (publicadas en CSV)
Origen de las reglas Cuadro de puntos, prospectos, operación propia del centro Avisos, notificaciones oficiales, prospectos
Motor Programa COBOL (grupo de lotes ORCDTCHK*, entre otros) El sistema del organismo evaluador y pagador
Manejo de excepciones Registro de excepciones (tbl_chkreigai) Revisión del personal y juicio individual del comité de revisión
Alcance de la verificación Solo los datos del propio centro El alcance de las reclamaciones que maneja esa institución, cruzando centros médicos y varios meses (verificación cruzada y longitudinal)

La estructura es del mismo tipo; la diferencia está en la cobertura de las reglas y el alcance de la verificación. De aquí se pueden extraer tres conclusiones para el ingeniero.

  1. La separación entre la regla como dato y el motor como programa fue una condición indispensable para seguir más de veinte años de revisiones del sistema. Si las reglas hubieran quedado incrustadas en el código, cada revisión habría significado una reforma completa.
  2. En el ámbito vinculado a la tabla maestra de verificación (diagnóstico de indicación, contraindicaciones, etc.), la precisión de la verificación del lado del centro médico depende más de cuán completa esté la tabla de reglas que de lo inteligente que sea el motor (en las verificaciones implementadas en el código, como el seguro o los días reales de atención, el alcance del propio programa se traduce directamente en capacidad de detección). La tabla maestra de verificación de ORCA tiene dos líneas: la parte suministrada de fábrica (tbl_chk_master) y la parte registrada por el usuario (tbl_chk_user), de modo que está diseñada para que cada centro pueda añadir sus propias reglas. En última instancia, el valor de los programas comerciales de verificación de recibos también reside en cuán completa esté su propia tabla de reglas.
  3. Ahora que se ha publicado una parte de las reglas del lado evaluador, un nuevo tema práctico es «cómo incorporar las reglas públicas del lado evaluador a la verificación del propio centro». El significado de que se ofrezcan en un formato legible por máquina, como un CSV público, es algo que ningún ingeniero debería pasar por alto.

9. Puntos prácticos — qué se puede hacer del lado del sistema para mejorar la precisión de la verificación

Resumimos, desde la posición del personal de sistemas del centro médico y de los proveedores de integración, los puntos que conviene tener presentes.

  1. Trasladar la estructura multinivel de la verificación a la operación diaria. Los tres niveles —en el momento de la entrada (API de contraindicaciones, etc.), mensual (verificación de datos) y antes de la presentación (verificación del recibo electrónico)— cumplen funciones distintas. Si la operación se limita a «ejecutar la verificación de datos una vez a fin de mes», queda margen para aprovechar los dos niveles anteriores.
  2. La verificación de datos se puede automatizar con la API. Con datacheckv3 se puede organizar una ejecución periódica que especifique los ítems a confirmar y los pacientes objetivo. Con un formato de lote nocturno más lista de errores por la mañana, se puede repartir a diario la carga de verificación de fin de mes.
  3. Tratar el registro de excepciones como «ajuste fino de las reglas». Si se deja acumular falsos positivos, la lista de errores deja de leerse. Mantener de forma planificada las excepciones (tbl_chkreigai) y las reglas propias del centro (tbl_chk_user), conservando una buena relación señal-ruido en la lista de errores, es la línea vital del trabajo de verificación.
  4. Devolver los resultados de la devolución y el ajuste al ciclo de análisis. Recopilar los motivos del aviso de ajuste de puntos y reflejar los patrones frecuentes en las reglas propias de la tabla maestra de verificación o en la operación del momento de la entrada: esto es «hacer crecer la tabla de reglas», y es la única manera de reducir la brecha de criterio con el lado evaluador.
  5. Revisar periódicamente los materiales públicos del lado evaluador. La publicación de verificación informática del Fondo de Pago se sigue actualizando. En una época en la que el lado evaluador explica oficialmente «qué observa», incluyendo la explicación de la verificación cruzada y la longitudinal, no tiene sentido dejar de leerla.

10. Resumen

  • El recibo pasa por puestos de control en varios niveles: ① verificación de contenido del sistema de facturación médica → ② verificación del recibo electrónico → ③ verificación informática del lado evaluador (+ verificación cruzada y longitudinal) → ④ personal y comité de revisión. La devolución es un rechazo y el ajuste es una reducción de puntos; la verificación cruzada, que coteja con el recibo de otra institución, no se puede sustituir dentro del centro médico (la comparación con los meses anteriores del propio centro sí es posible dentro de él).
  • La verificación de datos de ORCA está implementada como el negocio orca41, y reglas como el diagnóstico de indicación, las contraindicaciones o el cálculo conjunto se guardan como datos en la tabla maestra de verificación (la coherencia básica, como el seguro o los días reales de atención, está del lado del código). Se puede ejecutar eligiendo los ítems a confirmar, suprimir falsos positivos con el registro de excepciones, y también activarla desde el exterior con la API datacheckv3: todo esto se puede confirmar con el código fuente público.
  • El lado evaluador también publica en CSV una tabla de reglas formada por las condiciones de verificación de la sede central más la tabla maestra de verificación, de modo que el lado del centro médico y el lado evaluador comparten una arquitectura idéntica de «tabla de reglas + motor». La diferencia está en la cobertura de las reglas y el alcance de la verificación (solo el lado evaluador puede observar todas las instituciones y todos los meses).
  • Lo que determina la precisión de la verificación no es el motor, sino cuán completa esté la tabla de reglas y cómo se opera. El registro de excepciones, las reglas propias del centro, el ciclo de análisis de los resultados del ajuste y la incorporación de las reglas públicas del lado evaluador son los puntos clave en la práctica.

En las próximas entregas de la serie tenemos previsto un «capítulo de base de datos» que lea directamente el esquema de la base de datos de ORCA, y la operación práctica de un monitoreo automático de diferencias que siga la publicación mensual del código fuente.

11. Referencias

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.

¿Cuál es la diferencia entre el ajuste y la devolución?
Ambos términos están relacionados con la revisión del organismo evaluador y pagador (el Fondo de Pago de Honorarios Médicos del Seguro Social y el Kokuhoren, la Federación de Asociaciones Nacionales de Seguro de Salud), pero su significado es distinto. La devolución consiste en que el recibo se rechaza y se devuelve al centro médico, que puede corregir defectos de registro, errores de elegibilidad, etc., y volver a facturar a partir del mes siguiente. El ajuste consiste en que, como resultado de la revisión, se aumentan o reducen los puntos (en la práctica, casi siempre se reducen), de modo que el importe reclamado disminuye en esa medida. Si el centro médico no está de acuerdo con un ajuste, existe el trámite de la solicitud de reexamen.
¿Cuántas veces se verifica un recibo antes de presentarlo?
En términos generales, el recibo pasa por una verificación en varios niveles. Dentro del centro médico, primero está la verificación de contenido que realiza el sistema de facturación médica (en ORCA, la labor de verificación de datos) y, después, la verificación del recibo electrónico, que examina el archivo de recibo electrónico como dato de facturación. Tras la presentación, el recibo pasa por la verificación informática del organismo evaluador y pagador (con condiciones de verificación basadas en avisos y notificaciones oficiales, y una tabla maestra de verificación basada en los prospectos de los medicamentos), la verificación cruzada, que coteja los recibos médicos y de dispensación del mismo paciente, y la verificación longitudinal, que compara con los meses de facturación anteriores; a partir de ahí se realiza la revisión a cargo del personal y del comité de revisión.
¿Cómo está implementada la verificación de recibos en ORCA (Nichirese)?
Está implementada como la labor de verificación de datos (menú de negocio 41), y su implementación se puede confirmar en el código fuente público. Las reglas sobre la correspondencia entre medicamentos y procedimientos médicos (medicamento y diagnóstico, procedimiento y diagnóstico, medicamentos con contraindicación de uso conjunto, etc.) se guardan como datos en un conjunto de tablas llamado «tabla maestra de verificación», y un programa COBOL las interpreta para examinar los datos del paciente: es una arquitectura de «tabla de reglas + motor». Las verificaciones básicas, como la coherencia del seguro o de los días reales de atención, están implementadas directamente en el programa. También existen el registro de excepciones de error (no verificar este error) y una API (datacheckv3) para invocar la verificación de datos desde sistemas externos.
¿Se publican las reglas de verificación del organismo evaluador y pagador?
Una parte sí se publica. El Fondo de Pago, bajo el título «publicación relacionada con la verificación informática», publica en archivos CSV las condiciones de verificación de la sede central basadas en avisos y notificaciones oficiales, y la tabla maestra de verificación basada en los prospectos de los medicamentos, y va ampliando el alcance de forma gradual. El sitio oficial también explica el mecanismo de la verificación cruzada y la verificación longitudinal. No obstante, hay verificaciones que quedan fuera de lo publicado, como los casos que requieren revisar la columna de observaciones o que exigen un juicio médico.

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.

Contactar
Volver al blog