Health Information Exchange
0.1.0 - ci-build
Costa Rica
Health Information Exchange
0.1.0 - ci-build
Costa Rica
Health Information Exchange - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
Las opciones definen capacidades que un actor puede implementar sin dejar de ser conforme. La Tabla 2.3-1 lista las que cada actor puede declarar. Un actor que declara una opción SHALL cumplir todos los requisitos de esa opción.
Tabla 2.3-1: Actores y opciones de HIX
| Actor | Opción |
|---|---|
| Record Locator Service | Opción de Consentimiento |
| Document Registry | Opción de Almacenamiento Central |
| Opción de Consentimiento | |
| Sistema que publica y custodia documentos | Opción de Almacenamiento Central |
| Opción de Transporte Mediado | |
| Sistema que consume documentos | Opción de Demografía |
| Opción de Coincidencia Demográfica |
Un custodio que no puede conservar sus documentos delega el almacenamiento del contenido en la infraestructura central. El documento sigue siendo suyo. Figura como custodio en los metadatos y conserva la responsabilidad sobre su contenido, pero deja de participar en la recuperación.
El custodio que declara esta opción SHALL enviar el contenido dentro del ITI-65 en lugar de una referencia, y SHALL NOT exponer un endpoint de recuperación. El Document Registry que declara esta opción SHALL conservar el contenido durante el ciclo de vida que la comunidad establezca y SHALL responder ITI-68 con el contenido que conserva. El Record Locator Service SHALL atender la recuperación sin el salto hacia el custodio.
Esta opción corresponde a la primera de las dos ubicaciones del contenido que describe MHDS (MHDS Vol. 1, §1:50.1.1.2)1. Ambas coexisten en una misma comunidad. El solicitante no distingue cuál se aplica a cada documento y no necesita hacerlo. Qué custodios pueden ejercerla, y quién lo decide, es política de la comunidad.
Suiza opera todas sus comunidades con esta ubicación, como cuenta la sección 2.1. Lo que en HIX es una opción por custodio es allí la regla.
El tramo entre la infraestructura central y el custodio puede recorrer un canal de interconexión distinto de HTTPS directo, cuando la comunidad opera sobre una red de intercambio ya establecida, como X-Road.
El custodio que declara esta opción SHALL publicar en el directorio el endpoint que describe ese canal, y SHALL aceptar la transacción ITI-68 a través de él con el mismo contenido y los mismos requisitos de autorización. El token intercambiado sigue viajando en la solicitud y el custodio sigue validándolo. La identidad que el canal aporta SHALL NOT sustituir la validación del token.
El canal y la arquitectura son capas separadas que no se afectan entre sí. El canal resuelve cómo se conectan las organizaciones, cómo se identifican y cómo se cifra el tramo entre ellas. La arquitectura resuelve qué se intercambia y bajo qué reglas, es decir, las transacciones, los punteros, los tokens, la decisión de divulgación y la auditoría. Cambiar de canal no cambia nada de la segunda capa, y nada de la segunda capa exige un canal concreto. Por eso la recuperación sigue siendo mediada, el solicitante sigue sin alcanzar al custodio y ningún puntero cambia. La representación del canal en el directorio se especificará más adelante en esta guía.
Una red como X-Road autentica y cifra el tramo entre los servidores de seguridad de las dos organizaciones (X-Road, Arquitectura §3.3)2. El tramo entre el sistema del custodio y su propio servidor de seguridad queda dentro de su organización, y protegerlo es responsabilidad del custodio. Esta guía no lo especifica.
TODO. Comprobar con pruebas sobre X-Road qué guarda su registro de mensajes, para ver si guarda los mensajes completos, y cómo se configura. Reflejar el resultado en esta opción y en las decisiones de política de la sección 2.6.
Habilita la evaluación de una decisión de divulgación por paciente antes de responder una localización o una recuperación.
El actor que declara esta opción, sea el Record Locator Service o el Document Registry, SHALL consultar la decisión aplicable al paciente, al solicitante, a su organización, al propósito de uso que lleva su token y a la etiqueta de confidencialidad de cada puntero. SHALL omitir de la respuesta los documentos cuya divulgación no esté permitida, con las garantías que la sección 2.2 exige a toda omisión. Son que no se distinga de la ausencia del documento y que quede registrada en la auditoría.
El modelo de consentimiento, su ciclo de vida, su representación y sus políticas se especificarán en una versión posterior de esta guía a partir de PCF. Esta opción declara el punto en el que esa decisión se aplica y la información que necesita. Hasta entonces, la comunidad opera bajo la política de divulgación única que haya acordado, aplicada en el mismo punto.
En qué punto se aplica, en el Record Locator Service o en el Document Registry, es decisión de la implementación, como explica la sección 2.1. MHDS resuelve este mismo problema de otro modo, con un Authorization Server agrupado con su Document Registry que gestiona el consentimiento. HIX no sigue ese camino, por las razones que da la misma sección.
Permite a un consumidor localizar a un paciente por sus datos demográficos cuando no dispone de un identificador conocido por la comunidad. Corresponde a la Patient Search Option de PDQm.
El consumidor que declara esta opción SHALL presentar al menos un criterio demográfico en cada consulta ITI-78. La infraestructura central SHALL responder sobre las identidades maestras, nunca sobre las identidades locales de los miembros, SHALL limitar la respuesta a los pacientes que la política de la comunidad permita revelar por esta vía y SHALL rechazar una consulta sin criterio. Es una búsqueda determinista. Cada criterio filtra, y ningún resultado lleva grado de coincidencia.
Permite a un consumidor encontrar a un paciente a partir de datos demográficos incompletos o inexactos, con la coincidencia probabilística del registro de identidad maestra. Corresponde a la Match Operation Option de PDQm.
El consumidor que declara esta opción SHALL presentar en cada ITI-119 los datos del paciente que busca. La infraestructura central SHALL responder sobre las identidades maestras, nunca sobre las identidades locales de los miembros, SHALL limitar la respuesta a los pacientes que la política de la comunidad permita revelar por esta vía, SHALL ordenar los resultados de más a menos probable y SHALL indicar el grado de coincidencia de cada uno, como fija PDQm (PDQm, §2:3.119.4.2.2.4)3. Un resultado de esta búsqueda es un candidato, no una identidad confirmada.
Las citas reproducen el texto publicado por su fuente. Los recortes se marcan con "[…]" y la negrita es de esta guía.
MHDS Vol. 1, §1:50.1.1.2 Storage of Binary: "(1) The Document Source includes the Binary Resource in the [ITI-65] transaction, and the Document Registry is required to store it. (2) The Community allows the Binary to be stored elsewhere in the Community. […] This might be other centralized infrastructure, distributed infrastructure, or within the system implementing the Document Source." ↩
X-Road, Arquitectura §3.3 Message Transport Protocol: "The X-Road Message Transport Protocol is used by security server to exchange service requests and service responses. […] The protocol is based on HTTPS and uses mutual certificate-based TLS authentication." ↩
PDQm, §2:3.119.4.1.3 Expected Actions: "The results are ordered from most likely to least likely." §2:3.119.4.2.2.4 Quality of Match: "The Patient Demographics Supplier SHALL convey the quality of each match based on strength of the particular result to the supplied Patient Resource. […] it SHALL represent the confidence of a particular match within the bundle as a score attribute." ↩