Interoperabilidad semántica: el traductor de datos médicos

Consiste en que ambos entiendan exactamente lo mismo cuando reciben un diagnóstico, un resultado de laboratorio o un procedimiento clínico.

La diferencia parece menor hasta que deja de serlo. Un sistema puede importar correctamente el valor de una analítica y, aun así, interpretarlo con una unidad distinta, asociarlo a otro tipo de prueba o perder el contexto clínico. El mensaje llega. El significado, no necesariamente.

En los sistemas de información hospitalaria, ese es el punto donde terminan las demostraciones comerciales y empieza el trabajo real. La interoperabilidad de datos clínicos exige conectar aplicaciones, pero también normalizar vocabularios, estructuras, identificadores y reglas de uso. Sin esa capa común, el historial clínico electrónico se convierte en un almacén de documentos que los profesionales deben reinterpretar a mano.

Más allá del intercambio de datos: sintaxis no es semántica

Conviene separar dos problemas que suelen aparecer mezclados en los proyectos de integración sanitaria.

La interoperabilidad sintáctica permite que un sistema envíe y otro reciba información en un formato reconocido. HL7 v2 y HL7 FHIR cumplen funciones relevantes en este nivel. Definen cómo se estructura y transmite un mensaje o un recurso: qué campos existen, cómo se organizan y de qué manera se intercambian.

Pero un mensaje bien formado no garantiza que el receptor comprenda el contenido clínico.

Si un sistema envía el texto libre «glucosa», el receptor puede mostrarlo sin errores. Lo que no tiene garantizado es si se trata de glucosa en sangre, glucosa en orina, una determinación en ayunas o un valor asociado a otra prueba. Tampoco tiene por qué saber qué unidad se ha utilizado ni si el dato es comparable con otro resultado almacenado en su propia base de datos.

La semántica introduce ese contexto. Vincula el dato con una terminología, un código, una definición y, cuando procede, una unidad de medida. El objetivo no es que dos aplicaciones compartan la misma pantalla. Es que puedan operar sobre el mismo significado clínico.

Los cuatro niveles que suelen confundirse

En un proyecto de interoperabilidad sanitaria aparecen varias capas. Cada una resuelve un fallo distinto:

• Interoperabilidad técnica: garantiza que los sistemas estén conectados y puedan comunicarse.
• Interoperabilidad sintáctica: define la estructura y el formato de los mensajes intercambiados.
• Interoperabilidad semántica: asegura que diagnósticos, hallazgos, pruebas y procedimientos mantengan el mismo significado en el sistema de destino.
• Interoperabilidad organizativa: alinea procesos, responsabilidades, políticas y reglas de uso entre las organizaciones participantes.

El error habitual consiste en contratar una interfaz y llamarlo interoperabilidad. La interfaz puede transportar los datos. No puede decidir por sí sola qué significa cada campo, qué código clínico debe utilizarse o cómo resolver dos conceptos que parecen similares, pero no lo son.

Un dato clínico no está interoperando porque llegue a destino. Interopera cuando conserva su significado y puede utilizarse sin una nueva traducción manual.

Esto tiene consecuencias directas en la práctica. Un resultado que no puede compararse de forma fiable no sirve para una alerta clínica robusta. Un diagnóstico que llega como texto libre dificulta la explotación epidemiológica. Un procedimiento codificado con criterios distintos distorsiona la gestión hospitalaria. Y una prescripción electrónica que no comparte identificadores consistentes puede generar fricción en la dispensación y en la continuidad asistencial.

Qué es la interoperabilidad semántica en salud

La definición operativa es sencilla: es la capacidad de distintos sistemas de información sanitaria para intercambiar datos y comprender de forma consistente su significado clínico, su contexto y sus relaciones.

La palabra decisiva es «comprender». No implica que el software razone como un médico. Implica que el sistema receptor puede identificar un concepto clínico sin depender de la interpretación subjetiva de quien lo registró o de quien lo lee.

Para conseguirlo, cada dato debe describirse con elementos que permitan responder a varias preguntas:

1. Qué representa: un diagnóstico, una observación, un procedimiento, un medicamento o un resultado.

2. Qué concepto exacto es: no basta con una etiqueta genérica si existen varias interpretaciones clínicas.

3. En qué contexto se registró: paciente, episodio, fecha, muestra, profesional o servicio.

4. En qué unidad se expresa: especialmente en laboratorios y constantes fisiológicas.

5. Qué sistema de codificación lo identifica: SNOMED CT, LOINC, CIE u otra terminología controlada.

6. Cómo debe interpretarse en el destino: incluyendo estados, valores ausentes, negaciones y relaciones con otros datos.

La interoperabilidad semántica no elimina la necesidad de criterio clínico. Elimina trabajo mecánico y ambigüedad evitable. Permite que un profesional consulte información procedente de otra plataforma sin reconstruir el significado a partir de abreviaturas, nombres locales y campos incompletos.

Un ejemplo con un resultado de laboratorio

Supongamos que un laboratorio transmite un resultado con estos componentes:

• Identificador de la prueba.
• Valor numérico.
• Unidad de medida.
• Rango de referencia.
• Fecha y hora de la extracción.
• Tipo de muestra.
• Estado del resultado.
• Paciente y episodio asistencial.

Si el sistema solo recibe «glucosa: 112», ha recibido una frase legible, pero no un dato clínico suficientemente interoperable. Para interpretarlo necesita conocer, como mínimo, qué prueba se ha realizado, con qué muestra y en qué unidad.

LOINC se utiliza precisamente para identificar de forma unívoca observaciones y pruebas de laboratorio. Su base de datos incluye más de 70.000 términos médicos codificados. El código no sustituye al valor. Lo acompaña y permite que los sistemas sepan qué se está midiendo.

El mismo principio se aplica a diagnósticos y hallazgos. SNOMED CT ofrece una terminología clínica amplia para representar conceptos médicos y relaciones entre ellos. CIE-10 y CIE-11, por su parte, se utilizan en contextos de clasificación y codificación de enfermedades. No son piezas intercambiables sin más. Cada una responde a necesidades distintas.

SNOMED CT y LOINC: dos piezas con funciones diferentes

La terminología clínica no es un diccionario decorativo dentro del programa de historia clínica. Es una infraestructura de datos.

SNOMED CT: el concepto clínico y sus relaciones

SNOMED CT permite representar conceptos clínicos con un nivel de detalle que el texto libre no ofrece. Puede utilizarse para diagnósticos, hallazgos, procedimientos, situaciones clínicas y otros elementos del registro asistencial.

Su valor no se limita a asignar un código a una palabra. La terminología organiza relaciones entre conceptos. Eso facilita que una aplicación distinga, por ejemplo, entre una enfermedad confirmada, un antecedente, una sospecha o un hallazgo negado, siempre que el modelo de registro y la implementación lo contemplen correctamente.

En España, SNOMED CT se ha adoptado como terminología clínica de referencia dentro del Sistema Nacional de Salud. El Ministerio de Sanidad gestiona el área de recursos semánticos de referencia nacional y coordina políticas de normalización terminológica para el SNS.

Esto no significa que todos los centros, públicos y privados, hayan alcanzado el mismo grado de implantación ni que sus sistemas utilicen la terminología con idéntica profundidad. La adopción de una terminología nacional no resuelve automáticamente los catálogos locales, las migraciones de datos ni las decisiones de gobernanza.

LOINC: la identificación de observaciones y pruebas

LOINC está orientado a identificar mediciones, observaciones y documentos clínicos, con un peso especialmente claro en el ámbito del laboratorio.

Su utilidad aparece cuando varios centros utilizan nombres distintos para una prueba similar o cuando una misma etiqueta se aplica a determinaciones que no son equivalentes. Un identificador normalizado permite vincular el dato con el componente medido, el tipo de propiedad, el método, el momento y otros atributos relevantes.

La implementación debe respetar la granularidad necesaria. Mapear todas las pruebas de un laboratorio a un único concepto genérico puede producir una falsa sensación de normalización. El dato viajará con un código, pero seguirá siendo clínicamente ambiguo.

CIE no sustituye a las terminologías clínicas

CIE-10 y CIE-11 pertenecen al ámbito de las clasificaciones internacionales de enfermedades. Son esenciales para codificación, estadísticas sanitarias, actividad asistencial y otros procesos de gestión. Sin embargo, una clasificación no cubre todos los usos de una terminología clínica detallada.

Un sistema hospitalario puede necesitar:

• Una representación clínica rica para la continuidad asistencial.
• Una clasificación para elaborar estadísticas o agrupar episodios.
• Códigos específicos para pruebas de laboratorio.
• Identificadores de medicamentos y productos sanitarios.
• Terminologías propias de imagen médica o anatomía patológica.

El diseño serio no intenta forzar todos esos usos dentro de un solo catálogo. Define qué terminología corresponde a cada dominio y cómo se relacionan entre sí.

La tabla deja una idea incómoda, pero necesaria: HL7 FHIR no es una terminología médica. Es un estándar para modelar e intercambiar recursos. Puede transportar códigos SNOMED CT o LOINC, pero no reemplazarlos.

Cómo encaja HL7 FHIR en la interoperabilidad semántica

La pregunta «qué es la interoperabilidad semántica» suele llevar a otra: qué papel desempeña HL7 FHIR. La respuesta exige evitar una confusión frecuente.

FHIR aporta una arquitectura basada en recursos. Un paciente, una observación, una condición clínica, una cita o una medicación pueden representarse mediante estructuras definidas. Esto ayuda a que diferentes sistemas intercambien información de forma más predecible.

Sin embargo, una estructura FHIR puede contener información semánticamente pobre si sus campos se rellenan con texto libre o con códigos locales que solo entiende el sistema emisor.

Un recurso de observación puede estar correctamente construido y seguir siendo poco útil si:

• El código de la prueba pertenece a un catálogo interno sin correspondencia externa.
• La unidad no está normalizada.
• El método analítico no se especifica cuando resulta clínicamente relevante.
• El estado del resultado no está diferenciado.
• El dato se envía sin contexto temporal o sin identificar la muestra.
• Se mezclan valores numéricos y comentarios en un único campo textual.

FHIR resuelve una parte del problema. La capa semántica requiere perfiles de implementación, terminologías, conjuntos de valores, reglas de validación y acuerdos entre las organizaciones.

Un modelo práctico de integración

Para desplegar una integración con garantías, el trabajo suele dividirse en varias fases:

1. Inventariar los datos que realmente se intercambian.

No conviene comenzar por el estándar favorito del proveedor. Hay que identificar primero los casos de uso: continuidad asistencial, derivaciones, laboratorio, receta electrónica, urgencias, facturación o análisis poblacional.

2. Localizar los catálogos locales.

Cada hospital suele acumular abreviaturas, códigos históricos, nombres de servicio y reglas particulares. El catálogo del laboratorio puede no coincidir con el de la historia clínica. Sin este inventario, el mapa de conceptos nace incompleto.

3. Definir el concepto clínico de destino.

El objetivo no es encontrar una palabra parecida. Es seleccionar el concepto que representa el mismo significado, con el nivel de detalle que exige el caso de uso.

4. Mapear códigos y documentar excepciones.

Algunos conceptos tendrán una equivalencia directa. Otros requerirán una correspondencia parcial, una combinación de códigos o una revisión clínica. Las excepciones no deben ocultarse dentro de una transformación automática.

5. Validar los datos con profesionales.

Un equipo técnico puede detectar errores de formato. Un equipo clínico debe decidir si el resultado conserva sentido. El mapeo semántico sin participación asistencial es una automatización del desconocimiento.

6. Probar casos normales y casos límite.

Hay que incluir valores ausentes, resultados preliminares, pruebas canceladas, negaciones, antecedentes, duplicados, unidades diferentes y episodios con varios profesionales o servicios.

7. Auditar después del despliegue.

Los catálogos cambian. Se incorporan nuevas pruebas, se retiran códigos y se modifican circuitos. Una integración que nadie revisa se degrada aunque el software siga funcionando.

El problema que no resuelve ningún estándar: la gobernanza

La tecnología puede proporcionar una estructura común. No puede decidir quién tiene autoridad para modificarla.

La gobernanza semántica determina qué terminologías se utilizan, quién aprueba los cambios, cómo se versionan los mapas y qué ocurre cuando dos servicios emplean conceptos incompatibles. También define cómo se conserva la trazabilidad de una transformación.

Esto es especialmente relevante durante las migraciones. Un hospital puede pasar de un sistema de información a otro y conservar millones de registros históricos. Convertir esos datos a una terminología nueva no siempre es posible con una equivalencia exacta. Algunos códigos antiguos pueden ser demasiado genéricos, otros pueden haber cambiado de significado y otros pueden carecer de contexto.

El sistema debe diferenciar al menos tres situaciones:

• Equivalencia exacta: el concepto de origen y el de destino representan lo mismo.
• Equivalencia más amplia o más específica: el destino pierde o añade granularidad.
• Sin correspondencia segura: no existe una traducción que pueda aplicarse sin revisión.

Tratar los tres casos como si fueran idénticos contamina los análisis posteriores. Un mapa incompleto no es necesariamente un problema. Un mapa incompleto que se presenta como exacto sí lo es.

Los catálogos locales son el cuello de botella

En los proyectos de gestión hospitalaria software, la dificultad rara vez está en pronunciar HL7 FHIR o en adquirir una licencia terminológica. El obstáculo aparece en los miles de detalles acumulados durante años:

• Una misma prueba aparece con nombres distintos en urgencias y laboratorio.
• Un servicio utiliza abreviaturas que otro interpreta de forma diferente.
• Los códigos de un sistema antiguo se reutilizan para conceptos nuevos.
• Se registran diagnósticos en texto libre porque el catálogo resulta demasiado lento.
• Los valores de referencia dependen del equipo, la muestra o la población.
• Una modificación aparentemente local rompe informes, reglas de alerta o exportaciones.

La interoperabilidad semántica exige convertir ese inventario informal en una política de datos. No es un proyecto que pueda quedar completamente encapsulado en el departamento de informática.

El catálogo clínico no es una lista auxiliar del hospital. Es parte del sistema de seguridad del paciente.

El impacto real en la actividad asistencial

La interoperabilidad semántica se justifica por su efecto sobre los procesos, no por la elegancia de su arquitectura.

Continuidad asistencial

Cuando un paciente cambia de centro, la información clínica puede llegar en formatos diferentes. Si los diagnósticos, alergias, medicamentos y resultados están normalizados, el profesional puede identificar con mayor rapidez qué se sabe, qué falta y qué debe confirmar.

Esto no elimina la revisión médica. Reduce la dependencia de una lectura manual de documentos heterogéneos. En urgencias, esa diferencia puede ser operativa: encontrar un antecedente codificado y contextualizado no equivale a buscar una palabra dentro de varios informes PDF.

Alertas y soporte a la decisión

Las reglas clínicas necesitan datos estructurados. Una alerta de interacción farmacológica, una regla de seguimiento o un recordatorio de cribado no puede depender únicamente de que el diagnóstico aparezca escrito con la expresión exacta que espera el programa.

Pero aquí también aparece un riesgo: la normalización defectuosa puede multiplicar los falsos positivos. Si varios conceptos cercanos se tratan como equivalentes, el sistema puede activar avisos que no corresponden al paciente. El resultado es fatiga de alertas y pérdida de confianza por parte del facultativo.

La calidad semántica no consiste en generar más avisos. Consiste en que los avisos tengan una relación defendible con el dato clínico que los activa.

Gestión hospitalaria y análisis de datos

La administración sanitaria necesita comparar actividad, consumo, tiempos y resultados. Si cada centro codifica de forma distinta, las comparaciones pueden reflejar diferencias de registro en lugar de diferencias asistenciales.

La interoperabilidad de datos clínicos facilita consolidar información procedente de laboratorio, farmacia, consultas externas, hospitalización e imagen médica. También mejora la trazabilidad de los indicadores. Pero solo cuando se conocen las reglas de origen, las transformaciones aplicadas y las limitaciones del dato.

Un cuadro de mando visualmente impecable puede ofrecer conclusiones erróneas si mezcla conceptos no equivalentes. La analítica no corrige una semántica deficiente. La amplifica.

Automatización clínica

La automatización de tareas administrativas y asistenciales depende de que los sistemas puedan identificar eventos de manera fiable. Programar una derivación, clasificar una solicitud o cerrar un episodio requiere distinguir entre estados que el texto libre suele mezclar.

La inteligencia artificial tampoco escapa a esta dependencia. Un modelo puede procesar grandes volúmenes de historias clínicas, pero sus resultados estarán condicionados por la consistencia de los datos. El sesgo algorítmico no aparece solo en el modelo. Puede introducirse antes, en el catálogo, en la selección de variables o en la forma en que cada servicio registra la información.

Errores frecuentes al implantar interoperabilidad semántica

Los problemas de estos proyectos se repiten. No por falta de estándares, sino por una mala lectura del alcance.

1. Confundir una API con interoperabilidad completa

Una API permite que dos aplicaciones intercambien peticiones y respuestas. No garantiza que los conceptos clínicos sean equivalentes ni que el contexto viaje completo.

La pregunta correcta no es si existe una API. Es qué datos se intercambian, con qué terminología, con qué reglas y con qué mecanismo de validación.

2. Usar texto libre como solución universal

El texto libre es útil para matices clínicos y razonamiento narrativo. No debe cargar con funciones para las que se necesitan datos estructurados.

Cuando un diagnóstico, un resultado o una alergia solo existe como texto, se dificulta la búsqueda, la comparación y la activación de reglas. La respuesta no es eliminar la narración clínica, sino separar los elementos codificables de la información que requiere redacción profesional.

3. Mapear por similitud de palabras

Dos etiquetas pueden parecer iguales y representar conceptos diferentes. También puede ocurrir lo contrario: dos expresiones distintas pueden referirse al mismo concepto.

Los algoritmos de coincidencia textual sirven para proponer candidatos. No deben aprobar automáticamente los mapas clínicos sensibles. El proceso necesita revisión, trazabilidad y una política para los casos dudosos.

4. Creer que FHIR elimina la necesidad de acuerdos

FHIR facilita el intercambio, pero los centros deben acordar perfiles, campos obligatorios, terminologías, conjuntos de valores y reglas de interpretación. Sin ese contrato, dos implementaciones pueden ser formalmente compatibles y funcionalmente incompatibles.

5. Ignorar la versión de las terminologías

Los códigos y las definiciones evolucionan. Un mapa válido en una versión puede necesitar revisión en otra. Si el sistema no conserva la versión utilizada, resulta difícil explicar por qué un registro fue transformado de una determinada manera.

6. Medir solo si el mensaje llega

La métrica «mensaje entregado» es insuficiente. Hay que evaluar si el dato fue aceptado, si conserva contexto, si puede utilizarse en el flujo clínico y si generó errores o revisiones manuales.

Un sistema puede alcanzar una alta tasa de transmisión y seguir produciendo falsos positivos, duplicados o datos inutilizables.

Cómo auditar una integración antes de desplegarla

La auditoría debe centrarse en el recorrido completo del dato. Desde el registro en origen hasta su uso en destino.

Un equipo sanitario puede organizar la revisión alrededor de estas preguntas:

• ¿Qué sistema crea el dato y cuál es su responsabilidad sobre la calidad?
• ¿Qué terminología identifica el concepto?
• ¿Se conserva el contexto clínico durante la transmisión?
• ¿Cómo se representan las negaciones, los valores ausentes y los resultados preliminares?
• ¿Se transmiten las unidades y los rangos de referencia cuando son necesarios?
• ¿Qué ocurre si el sistema receptor no reconoce el código?
• ¿Se conserva el valor original junto con el valor transformado?
• ¿Quién revisa los cambios en catálogos y mapas?
• ¿Cómo se registra la versión de cada terminología?
• ¿Qué indicadores demostrarán que la integración mejora el proceso?

La respuesta no puede limitarse a documentación del proveedor. Hay que probar datos reales anonimizados o escenarios clínicos representativos. La prueba debe incluir tanto el caso habitual como la excepción que suele romper el circuito.

Indicadores que sí aportan información

Una batería razonable de seguimiento puede combinar métricas técnicas, semánticas y operativas:

• Mensajes rechazados por estructura o validación.
• Datos recibidos sin código normalizado.
• Porcentaje de conceptos enviados a revisión manual.
• Errores de unidad o de contexto.
• Duplicados generados durante la integración.
• Tiempo que tarda el profesional en localizar y comprender el dato.
• Alertas clínicas descartadas por falta de pertinencia.
• Cambios de catálogo pendientes de aprobación.
• Registros cuya transformación no tiene equivalencia exacta.

No se trata de construir un panel de indicadores por reflejo corporativo. Se trata de detectar dónde el dato deja de ser fiable o útil.

El papel del Sistema Nacional de Salud español

La normalización nacional reduce la fragmentación, pero no borra las diferencias de implantación entre organizaciones. El Ministerio de Sanidad coordina recursos semánticos de referencia y políticas de normalización para el SNS. Ese marco proporciona una base común para proyectos de interoperabilidad, pero cada centro debe resolver su propio catálogo, sus flujos y sus sistemas heredados.

En España conviven historias clínicas electrónicas, sistemas departamentales, plataformas de laboratorio, soluciones de imagen, aplicaciones de farmacia y herramientas administrativas con grados de madurez distintos. La interoperabilidad debe atravesar ese ecosistema sin asumir que todos los componentes utilizan los mismos modelos de datos.

También hay una diferencia entre compartir un documento y compartir datos computables. Un informe clínico en formato legible puede ser suficiente para una consulta puntual. No ofrece las mismas posibilidades que una observación estructurada, codificada y vinculada a su contexto. Los dos formatos pueden coexistir, pero no deben presentarse como equivalentes.

El desarrollo del Espacio Europeo de Datos Sanitarios añade presión para mejorar el intercambio transfronterizo y el control sobre los datos. La dirección es clara: los sistemas tendrán que facilitar un uso más coherente de la información sanitaria. Eso no convierte la interoperabilidad en un trámite administrativo. Hace más visible el coste de no haber normalizado antes.

Qué debe exigir un hospital a un proveedor

La conversación con un proveedor no debería quedarse en una lista de estándares compatibles. «Admite FHIR» es una respuesta demasiado amplia para evaluar un sistema clínico.

Conviene exigir precisión sobre varios puntos:

• Qué recursos FHIR implementa y con qué perfiles.
• Qué terminologías admite de forma nativa.
• Cómo gestiona SNOMED CT, LOINC y CIE en cada caso de uso.
• Qué campos son obligatorios y cuáles se dejan como texto libre.
• Cómo valida códigos, unidades, fechas y referencias.
• Cómo mantiene las versiones de las terminologías.
• Qué herramientas ofrece para mapear catálogos locales.
• Cómo registra los cambios y las excepciones.
• Qué sucede cuando el receptor no reconoce un código.
• Cómo se exportan los datos si el hospital cambia de plataforma.

También hay que preguntar quién mantiene la integración después de la puesta en marcha. La interoperabilidad no termina con la instalación. Cambian los catálogos, aparecen nuevas pruebas, se actualizan las reglas y se modifican los procesos asistenciales.

Un contrato que describe únicamente la conexión inicial deja sin resolver la parte más costosa: la evolución.

La frontera entre normalizar y simplificar en exceso

Normalizar no significa reducir toda la clínica a códigos. Un registro asistencial contiene decisiones, incertidumbre, contexto y lenguaje natural. La estructura debe capturar los elementos que necesitan ser procesados por otros sistemas sin empobrecer la documentación profesional.

El equilibrio exige distinguir entre:

• Datos que deben ser codificados para activar una función.
• Información narrativa que necesita conservarse como texto.
• Conceptos que pueden representarse mediante una terminología estándar.
• Matices que requieren una extensión local documentada.
• Datos que no deben inferirse automáticamente.

La automatización que rellena huecos puede parecer eficiente, pero introduce riesgo si convierte una ausencia de información en un valor clínico. Un campo vacío no equivale a una respuesta negativa. Un diagnóstico no mencionado no equivale a la ausencia de la enfermedad. Un resultado preliminar no equivale a uno validado.

Estas distinciones son poco vistosas en una presentación comercial. Son decisivas en la planta.

Conclusión: el lenguaje común es una infraestructura, no un accesorio

La interoperabilidad semántica en salud resuelve un problema concreto: que los datos clínicos mantengan su significado cuando atraviesan sistemas, servicios y organizaciones diferentes.

SNOMED CT, LOINC, CIE, HL7 FHIR, HL7 v2, openEHR y DICOM cumplen funciones distintas dentro de ese objetivo. Ninguno, por separado, convierte un ecosistema fragmentado en un sistema interoperable. Hace falta modelar los datos, normalizar los conceptos, gobernar los cambios y validar el resultado con quienes utilizan la información.

La prueba final no está en que el mensaje llegue ni en que la integración figure en una memoria técnica. Está en si el facultativo puede utilizar el dato sin reinterpretarlo desde cero, si el hospital puede analizarlo sin mezclar conceptos y si una regla clínica puede ejecutarse sin disparar falsos positivos por culpa de un catálogo mal construido.

El resto es transporte. La semántica es lo que evita que el sistema entregue palabras cuando debería entregar información clínica.