Terminología: la parte de un proyecto FHIR que menos se presupuesta

En las dos entregas anteriores comparamos el facade y el repositorio como caminos hacia FHIR. Los dos resuelven la forma del dato: qué tabla alimenta qué recurso y qué columna llega a qué elemento. Ninguno resuelve por su cuenta lo que ese dato significa.

Un recurso bien formado con un código que nadie entiende

El HIS de un hospital registra un diagnóstico con el código interno 0045 y la descripción HTA. El mapeo estructural lo convierte en un Condition correcto: paciente referenciado, fecha de registro, estado clínico. Si el perfil nacional exige CIE-10 o SNOMED CT en el código del diagnóstico, ese recurso no pasa la validación. Si el perfil solo lo recomienda, pasa, y el servidor de destino guarda un diagnóstico que ningún otro sistema sabe interpretar.

ORIGEN                     DESTINO
HIS       0045  HTA        CIE-10   I10       Hipertensión esencial
                           SNOMED   38341003  Hypertensive disorder
LIS       GLU              LOINC    2345-7    Glucosa en suero o plasma
Farmacia  AMOXI 500 CAP    ATC      J01CA04   Amoxicilina

La última fila tiene un matiz. ATC clasifica el principio activo, de modo que la presentación de 500 mg en cápsula viaja en otros elementos del recurso: forma farmacéutica y concentración. Un mapeo de vademécum casi nunca es una tabla de uno a uno.

El perfil decide cuánto importa

Cada elemento codificado de un perfil FHIR está ligado a un ValueSet con una fuerza de binding. Con required, solo se aceptan códigos de ese conjunto y cualquier otro es un error. Con extensible, hay que usar el conjunto cuando el concepto existe en él, y solo si no existe se admite otro código. Preferred y example orientan sin obligar.

Un código local puede producir un recurso válido que ningún otro sistema interpreta. La fuerza del binding decide si eso se detecta o pasa desapercibido.

Esa fuerza define si un código local detiene la carga o se cuela en el destino. Por eso hay que leerla elemento por elemento en el Implementation Guide antes de estimar el trabajo: dos perfiles del mismo recurso pueden exigir cosas muy distintas.

Por qué no se resuelve escribiendo más código

En un facade, la tabla de equivalencias vive dentro del traductor y se aplica en cada consulta. Una corrección rige desde la consulta siguiente, pero no hay un punto donde verificar que todo el acervo cumple. En un repositorio alimentado por scripts, la tabla vive en el script de carga y una corrección no toca lo que ya se cargó: hay que reprocesar a mano.

En los dos casos queda pendiente la parte que ningún integrador resuelve. Alguien tiene que decidir si HTA corresponde a I10 o a I15, que es hipertensión secundaria. Esa decisión es clínica y le toca al equipo de codificación o a un médico de la institución. Y se repite: el vademécum incorpora productos nuevos, el laboratorio agrega pruebas y las terminologías publican versiones con códigos nuevos y conceptos retirados.

El mapeo estructural se estima contando tablas y columnas. La terminología se mide en códigos distintos y en horas del personal clínico que los revisa, y su costo continúa después de la salida en vivo. Las estimaciones que solo cuentan tablas se quedan cortas.

Los códigos de alto volumen se mapean rápido. El tiempo se va en la cola de códigos poco frecuentes, y en el texto libre: un diagnóstico escrito como "HTA + DM2 desc." no lo resuelve ninguna tabla de equivalencias. Eso pide curaduría o procesamiento de lenguaje natural, y debe presupuestarse aparte.

Cada producto nuevo del vademécum es un código nuevo por mapear. La terminología se mantiene mientras el sistema esté en uso.

Cómo lo resolvemos en Harmony

En Harmony la traducción de terminología es configuración. Cada equivalencia vive en un ConceptMap versionado dentro del catálogo del plano de control, y la regla de mapeo lo referencia. Cada ejecución registra qué versión aplicó, así que cualquier carga se puede explicar después.

Antes de guardar un mapeo, el Mapper lo prueba contra datos reales y devuelve los hallazgos del validador FHIR oficial, sin escribir en el destino. Ahí aparecen los códigos que el ConceptMap todavía no cubre.

Un CodeableConcept admite varias codificaciones, y la práctica que recomendamos es enviar el código estándar junto con el código local original. El destino recibe lo que el perfil exige y un auditor puede rastrear cada valor hasta su fuente.

Para los códigos sin equivalencia, cada flujo define su política. En modo estricto, el registro se detiene y se genera una alerta. En modo permisivo, pasa marcado con su código local. Cuando el equipo clínico agrega la equivalencia que faltaba, se publica una versión nueva del ConceptMap y se vuelve a ejecutar el flujo: los upserts idempotentes corrigen el destino sin duplicar registros.

La decisión clínica sigue siendo de la institución. Harmony se encarga de que, una vez tomada, quede versionada y se aplique igual en cada ejecución.

Lo que viene

La próxima entrega vuelve al escenario que dejamos abierto en el artículo del facade: un médico que necesita ver en tiempo real la historia de un paciente atendido en varios establecimientos que no van a entregar su data a una base central. Ahí la pregunta cambia de escala, porque ya se trata de cómo se consulta una red de establecimientos sin copiar lo que cada uno guarda. La terminología vuelve a aparecer en ese escenario, porque cada establecimiento codifica a su manera y el médico necesita leer una sola historia.

Si su institución tiene un vademécum o un catálogo de laboratorio que debe llegar a un estándar, escríbanos a [email protected] y revisamos juntos una muestra de sus códigos.

HL7® y FHIR® son marcas registradas de HL7 International. SNOMED CT® es marca registrada de SNOMED International. LOINC® es marca registrada de Regenstrief Institute, Inc.