Guía MHD para HSI, Provincia de Buenos Aires.
0.3.0 - ci-build
Guía MHD para HSI, Provincia de Buenos Aires.
0.3.0 - ci-build
Guía MHD para HSI, Provincia de Buenos Aires. - Local Development build (v0.3.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
El intercambio de documentos clínicos mediante IHE Mobile access to Health Documents (MHD) involucra información personal y sanitaria sensible. Por esta razón, la implementación debe aplicar controles de seguridad en todas las capas: aplicación, API FHIR, transporte, infraestructura de intercambio, repositorios y auditoría.
Esta guía contempla dos formas de acceso al servicio MHD:
X-Road agrega identidad organizacional, control de acceso entre subsistemas, protección del transporte, firma de mensajes, sellado de tiempo y evidencia del intercambio. Sin embargo, X-Road no reemplaza la autenticación del usuario ni la autorización clínica aplicada por el servicio MHD.
La arquitectura debe aplicar los siguientes principios:
| Capa | Controles principales | Responsabilidad |
|---|---|---|
| Identidad organizacional | Certificados, identificación de miembros y subsistemas, configuración de confianza | X-Road |
| Transporte entre organizaciones | TLS mutuo, cifrado del canal y validación de certificados | X-Road |
| Evidencia del intercambio | Firma de mensajes, registro y sellado de tiempo | X-Road |
| Autenticación de aplicación o usuario | OAuth, IUA, OpenID Connect o mecanismo institucional equivalente | Plataforma de identidad y aplicación |
| Autorización clínica | Rol, organización, paciente, propósito de uso, consentimiento y tipo de documento | Servicio MHD |
| Validación de contenido | Validación FHIR, perfiles MHD, perfiles Core AR y reglas de negocio | Servidor FHIR/MHD |
| Protección del repositorio | Cifrado, control de acceso, respaldo y gestión de claves | Repositorio FHIR y documental |
| Auditoría clínica y de seguridad | AuditEvent, registros ATNA/BALP, SIEM y correlación con X-Road |
Aplicaciones e infraestructura |
El siguiente esquema muestra la separación entre la seguridad provista por X-Road y los controles propios del servicio MHD.
X-Road identifica a las organizaciones participantes, sus servidores de seguridad y los subsistemas que consumen o proporcionan servicios. Esta identidad se sustenta en certificados emitidos por autoridades de certificación reconocidas por la instancia X-Road.
El servidor de seguridad del proveedor debe permitir el acceso únicamente a los miembros, subsistemas o grupos autorizados para utilizar el servicio MHD publicado.
Esta autenticación permite responder preguntas como:
No permite determinar por sí sola qué persona utilizó el sistema ni si esa persona puede acceder a los documentos clínicos del paciente.
Las solicitudes MHD deben incorporar una identidad de aplicación y, cuando corresponda, la identidad del usuario que originó la operación.
Puede utilizarse IHE Internet User Authorization (IUA), OAuth u otro mecanismo institucional equivalente. Cuando se empleen tokens de acceso, el servicio debe validar como mínimo:
iss);aud);exp y, cuando corresponda, nbf);scope);jti), cuando corresponda; yLos tokens deben ser de corta duración y no deben almacenarse en registros, URLs, mensajes de error ni trazas técnicas.
X-Road permite transportar encabezados HTTP hacia el servicio proveedor. Por lo tanto, un token puede acompañar la solicitud a través del bus, pero debe ser validado por el componente de autorización o por el servicio MHD receptor.
La autorización debe evaluarse nuevamente en el punto de acceso al servicio MHD. No es suficiente que el subsistema consumidor esté autorizado en X-Road.
La decisión de acceso debería considerar:
Cuando se utilice IUA, pueden definirse ámbitos asociados a las transacciones MHD:
| Transacción | Ámbito general | Acceso esperado |
|---|---|---|
| ITI-65 Provide Document Bundle | ITI-65 |
Registro de documentos y metadatos autorizados. |
| ITI-67 Find Document References | ITI-67 |
Búsqueda de referencias documentales autorizadas. |
| ITI-68 Retrieve Document | ITI-68 |
Recuperación del contenido documental autorizado. |
Estos ámbitos no impiden aplicar restricciones adicionales por paciente, usuario, organización, tipo documental o propósito de uso.
Todas las comunicaciones deben utilizar HTTPS.
En una integración mediante X-Road deben protegerse tres tramos:
El tramo entre servidores de seguridad es protegido por X-Road mediante TLS mutuamente autenticado. Para los tramos internos entre los sistemas de información y sus servidores de seguridad también se recomienda TLS mutuo, especialmente cuando se trata de servicios clínicos privilegiados.
Los endpoints internos del servicio MHD no deberían quedar expuestos directamente a Internet cuando el acceso se haya definido exclusivamente mediante X-Road.
Antes de aceptar un Bundle de tipo transaction, el Document Recipient debe:
Bundle contra FHIR R4, IHE MHD y los perfiles nacionales aplicables;hash y size cuando sean aplicables;Provenance cuando corresponda.Si DocumentReference.content.attachment.url apunta a una dirección externa, el receptor debe prevenir ataques de tipo Server-Side Request Forgery (SSRF). Para ello debe utilizar una lista de dominios o repositorios permitidos, bloquear redes internas no autorizadas, impedir redirecciones inseguras y aplicar límites de tiempo y tamaño.
La búsqueda puede revelar la existencia de pacientes o documentos incluso cuando no entrega el contenido clínico. Por lo tanto, el Document Responder debe:
Bundle searchset;Los identificadores del paciente incluidos en una URL pueden quedar almacenados en historiales, proxies o registros. Cuando sea apropiado, puede utilizarse una búsqueda FHIR mediante POST [base]/DocumentReference/_search, manteniendo los parámetros fuera de la URL. Esto no reemplaza el uso de HTTPS ni la protección de los registros.
La autorización debe comprobarse nuevamente al recuperar el documento. Haber obtenido previamente un DocumentReference no constituye autorización suficiente para acceder a su contenido.
El Document Responder debe:
hash cuando esté disponible;Cuando se utilicen URLs temporales, estas deben tener una vigencia breve, alcance restringido y no deben reutilizarse como mecanismo permanente de autorización.
Cuando las transacciones MHD circulan mediante X-Road, la infraestructura aporta:
Estas capacidades permiten demostrar qué organizaciones intercambiaron información y proteger la comunicación entre ellas. No sustituyen:
La solución debe mantener dos niveles complementarios de trazabilidad:
Los servidores de seguridad registran las solicitudes y respuestas y pueden generar evidencia firmada y sellada en el tiempo. Estos registros permiten acreditar el intercambio entre organizaciones.
Debido a que los mensajes pueden contener información clínica, se debe revisar la configuración de los registros X-Road. Cuando el cuerpo de los mensajes sea almacenado, los registros deben cifrarse y protegerse con controles equivalentes a los aplicados al repositorio clínico. Si la política permite registrar solamente metadatos, debe conservarse suficiente información para la trazabilidad sin duplicar innecesariamente los documentos clínicos.
El servicio MHD debe registrar los eventos relevantes mediante AuditEvent o un mecanismo equivalente compatible con ATNA/BALP.
Cada evento debería registrar, cuando corresponda:
Los eventos de auditoría no deben admitir modificaciones o eliminaciones ordinarias y su acceso debe limitarse a funciones autorizadas de seguridad, privacidad y control.
AuditEvent registra el uso o acceso a la información. Provenance, en cambio, documenta el origen y las transformaciones que dieron lugar al estado actual de un recurso. Ambos recursos cumplen funciones diferentes y pueden utilizarse de manera complementaria.
Cada operación debe contar con un identificador de correlación único que acompañe la solicitud durante todo su recorrido:
Aplicación → X-Road consumidor → X-Road proveedor → API MHD → repositorio
El identificador debe permitir relacionar:
AuditEvent FHIR;OperationOutcome; yEl identificador no debe contener RUT, DNI, nombre del paciente u otra información clínica.
Los documentos, metadatos, índices, respaldos y registros deben protegerse mediante:
Las claves privadas utilizadas para firma, autenticación o cifrado deberían almacenarse en dispositivos o servicios especializados de gestión de claves. El acceso a estas claves debe ser restringido y auditado.
Los errores deben representarse mediante códigos HTTP apropiados y, cuando corresponda, mediante un recurso FHIR OperationOutcome.
Los mensajes no deben revelar:
La respuesta frente a una denegación debe definirse mediante una política consistente:
| Respuesta | Uso recomendado |
|---|---|
401 Unauthorized |
No existe una autenticación válida. |
403 Forbidden |
El solicitante está autenticado, pero no está autorizado y puede conocer esa condición. |
404 Not Found |
Se desea evitar revelar la existencia del recurso. |
200 OK con resultados filtrados o vacíos |
Búsquedas donde revelar la existencia de registros no autorizados produciría una fuga de información. |
| Amenaza | Controles principales |
|---|---|
| Suplantación de una organización | PKI X-Road, certificados, TLS mutuo y validación OCSP. |
| Suplantación de un usuario o aplicación | OAuth/IUA, MFA cuando corresponda, tokens firmados y validación de audiencia. |
| Acceso indebido a documentos | Autorización por usuario, paciente, rol, propósito, consentimiento y transacción. |
| Alteración del mensaje | TLS, firma X-Road, validación FHIR y verificación de integridad. |
| Repetición de solicitudes | Tokens breves, jti, identificadores únicos, controles de duplicados e idempotencia. |
| Enumeración de pacientes o documentos | Filtrado de respuestas, límites de frecuencia y política consistente de errores. |
| Extracción masiva de información | Paginación limitada, cuotas, detección de anomalías y alertas. |
| SSRF mediante URLs documentales | Lista de destinos permitidos, bloqueo de redes internas y validación de redirecciones. |
| Exposición de información en registros | Minimización, cifrado, control de acceso y política de retención. |
| Robo de credenciales o tokens | HTTPS, almacenamiento seguro, corta vigencia y rotación de secretos. |
| Denegación de servicio | Límites de tamaño, tiempo, frecuencia, concurrencia y monitoreo. |
Una implementación conforme con esta guía debe, como mínimo: