Interoperabilidad, HL7 y FHIR, y sus controles

HL7 v2 es el estándar de mensajes de línea con segmentos separados por barras (MSH la cabecera, PID la identificación del paciente, PV1 la visita) que muchas clínicas aún usan entre sistemas internos y externos; suele viajar por MLLP, un protocolo de transporte sencillo que por sí mismo no cifra. FHIR modela los datos como recursos (Patient, Observation…) con una interfaz web y usa OAuth 2.0 mediante SMART para autorizar con alcances como patient/Observation.rs: leer y buscar observaciones del paciente en contexto.

Ninguno de los dos obliga a cifrar ni a autenticar: un mensaje perfectamente válido puede viajar en claro, y un recurso perfectamente definido puede estar abierto. La seguridad se decide en cada canal y en cada endpoint.

Los canales HL7 v2 de la clínica están definidos en un archivo con su protocolo, si usan TLS y el destino. Un mensaje de admisión lleva identificación del paciente y su ubicación en hospitalización. Si el canal no usa TLS, cualquiera en la ruta puede leerlo.

En la pasarela FHIR cada endpoint declara cómo se autentica y qué alcance exige. Uno de ellos dice auth=ninguna. Los recursos FHIR pueden contener documentos clínicos completos; un endpoint sin autenticación los entrega a quien conozca la dirección.

Una configuración abierta es un riesgo; una configuración abierta que alguien usó es un incidente en potencia. El aliado de laboratorio, cuyo contrato es solo publicar resultados nuevos, aparece leyendo documentos. Cuenta cuántas lecturas exitosas (estado 200) hizo ese cliente sobre el recurso sin autenticación.

El aliado tiene alcances de sistema con permisos de crear, leer, actualizar, borrar y buscar sobre todo, cuando su contrato solo le permite crear observaciones. Además hay un endpoint sin autenticación y un canal en claro.