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.

Cada actor de HIX SHALL implementar los actores agrupados que le asigna la Tabla 2.4-2. Las agrupaciones se describen primero en prosa, actor por actor, y la tabla las resume al final.

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 y el grant Client Credentials, salvo la aplicación del paciente, que lo obtiene con 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)². Cada actor declara al menos una de la JWT Token Option o la Token Introspection Option, y puede declarar además la Authorization Server Metadata Option para descubrir los endpoints del Authorization Server. 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
Master Patient Index	Token Introspection, JWT Token, Authorization Server Metadata	El token del miembro que le declara o consulta identidades, y el token propio del Document Registry o del Authorization Server, preferiblemente con ITI-102
Document Registry	Token Introspection, JWT Token, Authorization Server Metadata	El token del miembro que publica y el token propio del Record Locator Service, preferiblemente con ITI-102. El token mediado, por sí mismo
Directorio de la comunidad	Token Introspection, JWT Token, Authorization Server Metadata	El token propio del Record Locator Service o del Document Registry, preferiblemente con ITI-102. El token mediado, por sí mismo
Custodio	JWT Token, Authorization Server Metadata. Token Introspection, si la comunidad la admite	Por sí mismo, con las claves que el Authorization Server publica, como fija la sección 2.6
Authorization Server	JWT Token, Authorization Server Metadata, Token Introspection	Emite los tokens, 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 registro de auditoría.

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 mediado 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.

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 el puntero no lleva copias contenidas. subject y custodian referencian lo que la comunidad conserva, y sourcepatient, que MHD deja opcional y sin forma fija bajo esa opción, es una referencia lógica por identificador⁶. No es un Document Responder de MHD, porque las localizaciones con ITI-66 e ITI-67 las responde el Document Registry, que guarda los punteros. Es el servicio que aloja el contenido fuera del Document Registry, como lo prevé MHDS (MHDS Vol. 1, §1:50.1.1.2)⁷, y lo sirve con ITI-68 solo al Record Locator Service. Por eso es también un Resource Server de IUA, que valida localmente el token mediado. 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. Puede agrupar además un Patient Identifier Cross-reference Consumer de PIXm para comprobar por su cuenta el contexto de paciente, como admite la sección 2.6. Bajo la Opción de Almacenamiento Central deja de alojar el contenido y de ser 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 el token mediado con HIX-1 para cada custodio y, salvo que la comunidad autorice un token propio conforme a la sección 2.2, para cada actor central desplegado como un sistema distinto. Agrupa además un Query Client de mCSD, con el que obtiene el endpoint de cada custodio con ITI-90.

Document Registry. HIX toma el nombre y la función de este actor del Document Registry de MHDS y adapta sus agrupaciones a la arquitectura de la comunidad⁸. Agrupa los siguientes actores:

• Un Document Recipient de MHD con la Comprehensive Metadata Option y la UnContained Reference Option, que recibe las publicaciones sin exigir copias contenidas, de modo que sourcepatient nombra a la identidad local por su identificador en el dominio del custodio. Esta referencia conserva la identidad con la que la fuente conoce al paciente y no debe confundirse con subject, que HIX vincula con la identidad maestra (golden record) de la comunidad.
• 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. Aplica las fusiones a los punteros y a las listas que conserva, que es lo que MHDS pide a su Document Registry, y conserva las altas y los cambios solo para comprobar que un paciente es reconocido y está activo⁹. Las recibe porque está suscrito con ITI-94. Esa suscripción la crea un Patient Identity Subscriber de PMIR, que puede ser el propio Document Registry o la operación de la comunidad.
• Un Query Client de mCSD (que MHDS todavía denomina Care Services Selective Consumer), 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 a la identidad maestra los identificadores con los que el custodio nombra al paciente en subject y en sourcepatient, y con los que una consulta ITI-66 o ITI-67 nombra al paciente.
• Un Authorization Client de IUA, que obtiene con ITI-71 y el grant Client Credentials el token con el que consulta el Master Patient Index y el directorio.
• Un Resource Server de IUA, que comprueba cada token que recibe con las opciones de la Tabla 2.4-1.

De las opciones que MHDS define para su Document Registry, HIX adopta las agrupaciones de la Authorization Option, salvo la del Authorization Server, y las de la UnContained References Option. El Authorization Server queda fuera de la agrupación porque la comunidad dispone de uno solo para todos sus Resource Servers, como explica la sección 2.1. La decisión de divulgación la garantiza el Record Locator Service, y la evalúa él mismo o el Document Registry cuando la comunidad la sitúa allí, como fija la sección 2.2.

Nota. HIX todavía no define cómo manejar la SVCM Validation Option. 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 access token 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 cuando el contenido queda en el custodio, y el Document Registry, para validar a quien publica. Es Resource Server de IUA, porque el Record Locator Service le presenta un token en cada consulta, y agrupa además los comunes de lo que casi todos agrupan.

Master Patient Index. 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, responde las suscripciones de ITI-94 y envía por ITI-93 cada cambio a quien está suscrito, como el Document Registry. PMIR le exige además responder ITI-83 e ITI-78 con las reglas del Patient Identifier Cross-reference Manager y del Patient Demographics Supplier¹³.
• El Patient Identifier Cross-reference Manager de PIXm, que aporta ITI-104, con el que recibe las identidades locales que los miembros declaran y las enlaza con la identidad maestra.
• El Patient Demographics Supplier de PDQm con la Match Operation Option, que aporta ITI-119, la búsqueda por 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 más actores que los comunes de lo que casi todos agrupan.

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 que obtiene del Authorization Server de la comunidad con ITI-71 y el grant Client Credentials. Es externa a la comunidad, y HIX no le pide nada que PMIR, IUA, ATNA, BALP 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 IUA Resource Server [JWT Token, Authorization Server Metadata, Token Introspection si la comunidad la admite] como servicio que aloja el contenido. Opcionalmente PIXm Patient Identifier Cross-reference Consumer, para comprobar por su cuenta el contexto de paciente
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, 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 [Token Introspection, JWT Token, Authorization Server Metadata], IUA Authorization Client
Authorization Server	IUA Authorization Server [JWT Token, Authorization Server Metadata, Token Introspection], OpenID Provider de OpenID Connect, PIXm Patient Identifier Cross-reference Consumer, IUA Authorization Client
Directorio de la comunidad	mCSD Directory e IUA Resource Server [Token Introspection, JWT Token, Authorization Server Metadata]
Master Patient Index	PMIR Patient Identity Registry, PIXm Patient Identifier Cross-reference Manager, PDQm Patient Demographics Supplier [Match Operation], IUA Resource Server [Token Introspection, 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 describen funciones, no servidores. Una comunidad puede repartirlas entre varios sistemas o reunirlas en uno solo. Por ejemplo, el Document Registry, el Master Patient Index y el directorio pueden compartir un mismo servidor FHIR central.

La distribución no cambia las responsabilidades. El Record Locator Service atiende siempre las localizaciones y recuperaciones de los miembros y garantiza que se aplique la decisión de divulgación. El Document Registry recibe las publicaciones y el Master Patient Index, las declaraciones y consultas de identidad. Cada actor comprueba el token del miembro y aplica las reglas de la comunidad para la transacción que recibe.

La comunidad puede colocar una fachada común delante de estos servicios, incluido el propio Record Locator Service. Esa fachada cambia cómo se llega a ellos, pero cada actor conserva sus responsabilidades. Cuando el Record Locator Service y otro actor central forman un mismo sistema, sus llamadas son internas y no requieren intercambio de tokens mediante HIX-1.

Los requisitos de autorización de cada actor se detallan en la sección 2.2.

Referencias

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