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 añadir a las que se le exigen. La Tabla 2.3-1 lista las que cada actor puede declarar. Un actor que declara una opción SHALL cumplir todos sus requisitos.
Tabla 2.3-1: Actores y opciones de HIX
| Actor | Opción |
|---|---|
| Record Locator Service | Opción de Consentimiento |
| Opción de Canal de Interconexión | |
| Document Registry | Opción de Almacenamiento Central |
| Opción de Consentimiento | |
| Opción de Canal de Interconexión | |
| Master Patient Index | Opción de Canal de Interconexión |
| Authorization Server | Opción de Canal de Interconexión |
| Sistema que publica y custodia documentos | Opción de Almacenamiento Central |
| Opción de Canal de Interconexión | |
| Sistema que consume documentos | Opción de Demografía |
| Opción de Coincidencia Demográfica | |
| Opción de Canal de Interconexión | |
| Aplicación del paciente | Opción de Canal de Interconexión, solo con backend propio |
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 SHALL declarar esta opción solo si el Document Registry de la comunidad también la declara. El custodio que la declara SHALL enviar el contenido dentro del ITI-65 en lugar de una referencia, y SHOULD NOT exponer un endpoint de recuperación, porque las recuperaciones ya no pasan por él. 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 atiende entonces la recuperación desde el Document Registry, como fija la sección 2.2.
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, como explica la sección 2.1. 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.
Las transacciones de la comunidad pueden recorrer un canal de interconexión distinto de HTTPS directo, cuando la comunidad opera sobre una red de intercambio ya establecida, como X-Road. Todo actor que la comunidad expone a otros participantes queda entonces bajo ese canal, sea un actor central o un custodio que responde recuperaciones, y lo mismo los miembros que llaman a esos actores. La excepción es la aplicación del paciente que es un cliente público, porque funciona en el navegador de la persona y solo puede usar HTTPS. Una aplicación con backend propio, que es un cliente confidencial, MAY declarar la opción para sus llamadas al Record Locator Service, aunque la autorización de HIX-2 siga pasando por el navegador.
El actor que declara esta opción SHALL atender y originar a través del canal las mismas transacciones, con el mismo contenido y los mismos requisitos de autorización. El directorio SHALL declarar, para el custodio que la declara, el endpoint que describe ese canal. El token sigue viajando en la solicitud y quien la recibe sigue validándolo. La identidad que el canal aporta SHALL NOT sustituir la validación del token.
El canal no cambia nada de la arquitectura. Resuelve cómo se conectan, se identifican y cifran su tramo las organizaciones, y las transacciones, los punteros, los tokens, la decisión de divulgación y la auditoría siguen siendo los mismos, como explica la sección 2.1. 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.
Habilita la evaluación de una decisión de divulgación por paciente antes de responder una localización o una recuperación. La decisión base, con la política única de la comunidad, es un requisito de la sección 2.2. Esta opción la extiende al consentimiento de cada paciente.
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, es decir, 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, lo decide la comunidad, 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 que nombre o describa a la persona en cada consulta ITI-78. Qué parámetros cuentan como criterio lo fija la sección 3.4. Es una búsqueda determinista. Cada criterio filtra, y ningún resultado lleva grado de coincidencia. Las reglas que el Master Patient Index aplica a su respuesta, como devolver solo identidades maestras y limitarlas según la política de la comunidad, las fija la sección 2.2.
Permite a un consumidor encontrar a un paciente a partir de datos demográficos incompletos o inexactos, con la coincidencia probabilística del Master Patient Index. 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. Un resultado de esta búsqueda es un candidato, no una identidad confirmada. Las reglas que el Master Patient Index aplica a su respuesta, como devolver solo identidades maestras e indicar el grado de coincidencia de cada una, las fija la sección 2.2.
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." ↩