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

Volumen 1. Arquitectura

HIX es una comunidad de intercambio de documentos clínicos sobre FHIR. Sigue el modelo que IHE llama Centralized Discovery and Retrieve, en el que un localizador central permite descubrir dónde están los documentos y recuperarlos del custodio que registró su existencia (IHE HIE Whitepaper, §2.8)1. HIX lo aplica con una variante deliberada, que registra la Tabla 2.1-3. También la recuperación pasa por ese localizador, de modo que la localización y la recuperación se median de forma centralizada, mientras la custodia de los documentos permanece distribuida entre los miembros que los producen.

IHE realiza ese modelo sobre FHIR con ​MHDS. HIX lo toma como arquitectura de referencia, sin declarar conformidad con él, y compone directamente los perfiles que resuelven cada pieza, por las razones que da la sección 2.1.

Cada perfil que HIX compone aporta una pieza de esa arquitectura.

  • MHD pone las transacciones con las que se publica, localiza y recupera un documento.
  • PMIR, PIXm y PDQm ponen la identidad maestra del paciente y su vínculo con las identidades locales.
  • mCSD pone el directorio del que la infraestructura central aprende dónde responde cada custodio.
  • IUA y OAuth 2.0 ponen los tokens que cruzan cada límite de confianza, con SMART App Launch cuando quien autoriza es una persona.
  • ATNA con BALP pone el registro que hace reconstruible cada divulgación.

Lo que ningún perfil cubre, como el intercambio de tokens con el que el mediador alcanza a un custodio, y según el despliegue a otros Resource Servers centrales, o el lanzamiento de la aplicación del paciente, HIX lo especifica como transacción propia, identificada como HIX-n, en el Volumen 2.

Infraestructura central

Infraestructura central de HIX

Figura 2-1: Infraestructura central de HIX

La Figura 2-1 muestra la infraestructura central de la comunidad, es decir, los servicios que HIX opera y las transacciones que los conectan. Es una vista de arquitectura, no de despliegue. Omite las agrupaciones transversales que casi todo actor lleva, como el Time Client de CT, y no dibuja los sistemas de los miembros, que solo tratan con la infraestructura central y nunca entre sí.

  • El Record Locator Service es el mediador de la comunidad. Localiza y recupera documentos en nombre de los miembros y aplica la decisión de divulgación.
  • El Authorization Server es el único emisor de tokens de la comunidad. Emite el token con el que un miembro llega al mediador y lo intercambia por otro, acotado al destino que nombra su resource, cada vez que el mediador tiene que alcanzar a un custodio y, según el despliegue, a otro Resource Server central.
  • El Document Registry conserva los punteros a los documentos publicados, cada uno con la identidad maestra del paciente como sujeto.
  • Los Shared HIE Services de la figura completan la infraestructura. El directorio de la comunidad describe a los miembros y sus endpoints, el Master Patient Index mantiene una identidad por persona y el Audit Record Repository concentra los eventos de los componentes centrales.
  • La fuente autoritativa de identidad es externa a la comunidad y la única que puede crear identidades maestras. HIX no la designa. La propuesta para Costa Rica es que sea el EDUS, el expediente digital único de la CCSS, que ya tiene resuelta la identificación de las personas.

Dicho en seis afirmaciones.

  1. La comunidad es la única contraparte de sus miembros. Ningún miembro interactúa con otro.
  2. El índice es central y el contenido es del custodio. Un documento se queda donde se produjo, y la comunidad sabe que existe, de quién es y quién lo conserva.
  3. La divulgación se decide una vez por cada consulta, en la infraestructura central, sobre los metadatos del índice y antes de mover contenido alguno. Localizar y recuperar son dos consultas.
  4. Cada recuperación alcanza al custodio con una credencial derivada de la petición viva del solicitante, el token mediado, que vale para ese único custodio, dura dos minutos como máximo y el custodio verifica por sí mismo. Ningún participante tiene una credencial que valga ante un custodio, ni siquiera el mediador.
  5. La identidad maestra del paciente está anclada en la identidad que verifica la fuente autoritativa. Los miembros declaran sus identidades locales, la comunidad las vincula y ningún miembro crea una persona.
  6. El transporte hacia cada custodio se declara en el directorio, no en los punteros ni en la API. Una red de intercambio como X-Road puede llevar ese tramo sin que cambie un puntero, un token ni una transacción.

Cómo leer este volumen

El Volumen 2 detalla las transacciones. Este volumen describe qué hace cada actor y por qué, y el siguiente, cómo.

Referencias

  1. IHE HIE Whitepaper, §2.8 Document Sharing Models: "Centralized Discovery and Retrieve – in this model, a centralized locator is used to discover the location of documents which enables a retrieval of the document from a custodian who has registered existence of the document with the centralized locator". §3 Document Sharing Profiles asocia ese modelo a "Mobile access to Health Documents (MHD), Mobile Health Document Sharing (MHDS), and Cross-Enterprise Document Sharing (XDS)". ↩