Health Information Exchange - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Agrupaciones de actores requeridas

Un actor de HIX no se implementa desde cero. Se implementa agrupando actores de los perfiles IHE que HIX compone, y cada uno de ellos trae consigo sus transacciones, sus opciones y sus requisitos. La sección 2.2 dice qué transacciones ejecuta cada actor. Esta sección dice de qué está hecho, es decir, qué actores IHE agrupa y bajo qué opciones. Para quien implementa, es la lista de perfiles que debe leer y de agrupaciones que debe declarar al afirmar su conformidad. Para quien solo quiere entender la arquitectura, basta con la sección 2.2 y esta queda como referencia.

Las agrupaciones se describen primero en prosa, actor por actor, y se resumen al final en la Tabla 2.4-2.

Lo que casi todos agrupan

Tres perfiles acompañan a casi todos los actores de HIX. Se describen aquí una sola vez y no se repiten en cada actor.

IUA pone el token en cada transacción. Todo miembro es un Authorization Client de IUA. Obtiene el token del Authorization Server con ITI-71, que en la aplicación del paciente toma la forma de HIX-2, y lo presenta en cada solicitud con ITI-72. Todo actor ante el que un miembro presenta un token, directamente o a través del Record Locator Service, es un Resource Server de IUA, que recibe el token con ITI-72 y lo comprueba. Ambos pueden descubrir los endpoints del Authorization Server mediante ITI-103¹.

IUA exige a todo Resource Server declarar con qué opción comprueba el token (IUA, Tabla 34.2-1)². Las opciones son la Token Introspection Option, la JWT Token Option y la Authorization Server Metadata Option, y la Tabla 2.4-1 dice cuáles declara cada actor de HIX.

Tabla 2.4-1: Cómo comprueba el token cada actor

Actor	Opciones de IUA	Cómo comprueba el token
Record Locator Service	Token Introspection	Pregunta al Authorization Server con ITI-102
Custodio, Document Registry y registro de identidad maestra	JWT Token, Authorization Server Metadata	Por sí mismo, con las claves que el Authorization Server publica
Authorization Server	JWT Token, Authorization Server Metadata, Token Introspection	Emite los tokens como JWT, publica sus endpoints y sus claves con ITI-103 y responde ITI-102

Un mismo sistema puede ser las dos cosas. El Record Locator Service es Resource Server ante los miembros y Authorization Client ante los custodios y los actores centrales, y un custodio presenta tokens al publicar y los valida al servir documentos. Cómo se autentican entre sí los demás actores centrales queda a criterio de la implementación, porque pueden compartir un mismo sistema, como dice el apartado sobre los despliegues.

ATNA protege el canal y deja rastro. Todo sistema que participa en HIX, salvo la aplicación del paciente, es un Secure Node o Secure Application de ATNA. Autentica al nodo con el que habla y cifra el canal con ITI-19, bajo la opción STX: TLS 1.2 Floor using BCP195, y registra sus eventos de auditoría con ITI-20, como recursos AuditEvent bajo la opción ATX: FHIR Feed³ y con el contenido que cada perfil define a partir de los patrones de BALP. Esa opción pide a quien registra al menos una de las dos interacciones de ITI-20, y al Audit Record Repository las dos. Quien escribe esos registros es, en términos de BALP, un Audit Creator, que BALP agrupa precisamente con ese Secure Node o Secure Application (BALP, §1:52.1.1.1)⁴. Los actores centrales envían sus eventos al Audit Record Repository de la comunidad. Cada miembro conserva los suyos en su propio repositorio.

CT mantiene los relojes de acuerdo. Todo sistema que participa en HIX, salvo la aplicación del paciente, es un Time Client de CT y sincroniza su reloj con ITI-1 contra el Time Server que la comunidad designa, propio o una fuente de tiempo externa. Sin relojes de acuerdo, los eventos de una misma divulgación no podrían ordenarse entre sistemas y la vigencia de dos minutos del token intercambiado no significaría lo mismo en cada extremo.

Esta guía deja por ahora a la aplicación del paciente fuera de ATNA y de CT. Su actividad queda registrada por los dos actores centrales ante los que actúa, el Authorization Server al lanzarse y el Record Locator Service en cada consulta.

TODO. Alinear el tratamiento de la aplicación del paciente. Figura como cliente en el Authorization Server, puede ser un cliente confidencial cuando tiene backend propio, y de eso depende si se la considera miembro y qué le exigen ATNA, CT y la auditoría.

Miembros

Custodio. Es un Document Source de MHD con la Comprehensive Metadata Option, porque el Document Registry exige metadatos completos al publicar, como hace el de MHDS⁵. Declara también la UnContained Reference Option, porque sourcepatient referencia al paciente que el custodio declaró en el registro de identidad, en lugar de llevar una copia contenida⁶. Es un Document Responder de MHD, que sirve el contenido de sus documentos con ITI-68 cuando el Record Locator Service se lo pide, y por eso también un Resource Server de IUA, que valida localmente el token intercambiado. Es un Patient Identity Source de PIXm, que declara sus identidades locales con ITI-104. Y es un Authorization Client de IUA, que obtiene el token con el que publica y declara. Bajo la Opción de Almacenamiento Central deja de ser Document Responder y Resource Server, porque entrega el contenido al publicar y ya no responde recuperaciones.

Consumidor. Es un Document Consumer de MHD, que localiza con ITI-66 e ITI-67 y recupera con ITI-68 a través del Record Locator Service, y un Authorization Client de IUA. Puede agrupar además un Patient Identifier Cross-reference Consumer de PIXm, para resolver con ITI-83 un identificador que ya conoce, y, bajo la Opción de Demografía, un Patient Demographics Consumer de PDQm con la Patient Search Option, para buscar con ITI-78 a un paciente del que solo conoce sus datos. Bajo la Opción de Coincidencia Demográfica ese mismo actor declara la Match Operation Option, para buscarlo con ITI-119. No es Resource Server, porque no responde transacciones de nadie.

Aplicación del paciente. Es un Document Consumer de MHD y un Authorization Client de IUA, y nada más. Obtiene su token con HIX-2 y desde ahí localiza y recupera como cualquier consumidor, confinada al paciente que la usa.

Actores centrales

Record Locator Service. Hacia los miembros es un Document Responder de MHD, que recibe sus localizaciones y recuperaciones, y un Resource Server de IUA con la Token Introspection Option, porque comprueba cada token con ITI-102. Hacia el Document Registry y los custodios es un Document Consumer de MHD, que ejecuta esas mismas transacciones a nombre del solicitante, y un Authorization Client de IUA, que obtiene para cada destino el token intercambiado con HIX-1. Agrupa además un Patient Identifier Cross-reference Consumer de PIXm, con el que resuelve la identidad del paciente con ITI-83, y un Query Client de mCSD, con el que obtiene el endpoint de cada custodio con ITI-90.

Document Registry. Es un actor de HIX que toma su nombre y su función del Document Registry de MHDS. HIX lo define por los actores que agrupa, que son los que MHDS fija para el suyo⁷ más uno, porque el miembro publica con su identidad local y la comunidad la traduce por él.

• Un Document Recipient de MHD con la Comprehensive Metadata Option y la UnContained Reference Option, que recibe las publicaciones y admite que sourcepatient referencie a un paciente del registro de identidad.
• Un Document Responder de MHD, que responde las localizaciones y, bajo la Opción de Almacenamiento Central, también las recuperaciones.
• Un Patient Identity Consumer de PMIR, que recibe por ITI-93 las altas, los cambios y las fusiones de las identidades maestras y las aplica a los punteros y a las listas que conserva⁸.
• Un Query Client de mCSD, con el que comprueba que quien publica es un miembro activo de la comunidad.
• Un Patient Identifier Cross-reference Consumer de PIXm, que HIX añade, con el que comprueba al indexar que la persona existe y está activa en la comunidad, la misma comprobación que MHDS pide a su Document Registry al validar una publicación⁹, y con el que resuelve la identidad local de un puntero a su identidad maestra cuando la publicación le llega sin resolver.
• Un Resource Server de IUA, que valida por sí mismo cada token que recibe.

HIX no declara las opciones que MHDS define para su Document Registry. La decisión de divulgación puede aplicarla el Record Locator Service o el propio Document Registry cuando conoce las reglas de la comunidad, como explica la sección 2.1, y validar la terminología de los metadatos queda a criterio de cada implementación.

Authorization Server. Es el Authorization Server de IUA, con las tres opciones de la Tabla 2.4-1. Es también un OpenID Provider, es decir, un servidor de autorización que además autentica a la persona y acredita esa autenticación con un id_token¹⁰. Lo es porque HIX-2 se apoya en SMART App Launch, y SMART entrega ese id_token junto con el token de acceso cuando la aplicación pide el scope openid¹¹. Y agrupa un Patient Identifier Cross-reference Consumer de PIXm, con el que resuelve a la identidad maestra la identidad de la persona autenticada para fijar el contexto de paciente.

Directorio de la comunidad. Es el Directory de mCSD. Lo consultan el Record Locator Service, para dirigir cada recuperación, y el Document Registry, para validar a quien publica. No agrupa ningún otro actor.

Registro de identidad maestra. Agrupa tres actores que trabajan sobre los mismos datos, y es Resource Server de IUA ante todos ellos.

• El Patient Identity Registry de PMIR, que recibe por ITI-93 las identidades maestras de la fuente autoritativa y las reenvía a quien las consume, como el Document Registry.
• El Patient Identifier Cross-reference Manager de PIXm, que recibe por ITI-104 las identidades locales que los miembros declaran, las enlaza con la identidad maestra y responde ITI-83.
• El Patient Demographics Supplier de PDQm con la Match Operation Option, que responde por ITI-78 las búsquedas por datos demográficos y por ITI-119 las de coincidencia probabilística.

Audit Record Repository. Es el Audit Record Repository de ATNA con la opción ATX: FHIR Feed, que recibe por ITI-20 los eventos de los actores centrales como recursos AuditEvent. No agrupa ningún otro actor.

Fuente autoritativa de identidad. Es el Patient Identity Source de PMIR, que crea, actualiza, fusiona y desactiva las identidades maestras con ITI-93, y un Authorization Client de IUA, porque lo hace con un token del Authorization Server de la comunidad. Es externa a la comunidad, y HIX no le pide nada que PMIR, IUA, ATNA y CT no pidan a cualquier sistema que participa.

Resumen

La Tabla 2.4-2 reúne lo anterior en una sola vista. Las opciones van entre corchetes. ATNA Secure Node o Secure Application, BALP Audit Creator y CT Time Client acompañan a todos los actores salvo a la aplicación del paciente y no se repiten en cada fila.

Tabla 2.4-2: Actores que agrupa cada actor de HIX

Actor de HIX	Actores agrupados
Custodio	MHD Document Source [Comprehensive Metadata, UnContained Reference], PIXm Patient Identity Source, IUA Authorization Client. Salvo bajo la Opción de Almacenamiento Central, también MHD Document Responder e IUA Resource Server [JWT Token, Authorization Server Metadata]
Consumidor	MHD Document Consumer, IUA Authorization Client. Opcionalmente PIXm Patient Identifier Cross-reference Consumer y, bajo las opciones de Demografía y de Coincidencia Demográfica, PDQm Patient Demographics Consumer [Patient Search, Match Operation]
Aplicación del paciente	MHD Document Consumer, IUA Authorization Client
Record Locator Service	MHD Document Responder, MHD Document Consumer, PIXm Patient Identifier Cross-reference Consumer, mCSD Query Client, IUA Resource Server [Token Introspection], IUA Authorization Client
Document Registry	MHD Document Recipient [Comprehensive Metadata, UnContained Reference], MHD Document Responder, PMIR Patient Identity Consumer, mCSD Query Client, PIXm Patient Identifier Cross-reference Consumer, IUA Resource Server [JWT Token, Authorization Server Metadata]
Authorization Server	IUA Authorization Server [JWT Token, Authorization Server Metadata, Token Introspection], OpenID Provider de OpenID Connect, PIXm Patient Identifier Cross-reference Consumer
Directorio de la comunidad	mCSD Directory
Registro de identidad maestra	PMIR Patient Identity Registry, PIXm Patient Identifier Cross-reference Manager, PDQm Patient Demographics Supplier [Match Operation], IUA Resource Server [JWT Token, Authorization Server Metadata]
Audit Record Repository	ATNA Audit Record Repository [ATX: FHIR Feed]
Fuente autoritativa de identidad	PMIR Patient Identity Source, IUA Authorization Client

Sobre los despliegues

Las agrupaciones anteriores son lógicas. Un despliegue puede repartir los actores agrupados entre varios sistemas o concentrarlos en uno solo, siempre que el comportamiento observable desde fuera sea el especificado. El Document Registry, el registro de identidad maestra y el directorio pueden vivir en un mismo servidor FHIR central sin que nada de esta sección cambie.

Referencias

Las citas reproducen el texto publicado por su fuente. Los recortes se marcan con "[…]" y la negrita es de esta guía.