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

Conceptos y decisiones de arquitectura

Esta sección explica las decisiones que dan forma a esta comunidad. Cada una se presenta con lo que decide y por qué lo decide, y la Tabla 2.1-2 resume lo que cuestan. Son decisiones de arquitectura, no de implementación. Una comunidad puede desplegarlas de muchas maneras sin que cambie nada de lo que aquí se describe. La última subsección explica la relación de HIX con MHDS.

Comunidad y límite de confianza

Una comunidad HIX es un conjunto de organizaciones que acuerdan compartir documentos clínicos bajo una política común y a través de una infraestructura común. La pertenencia es explícita. Una organización es miembro cuando figura en el directorio de la comunidad y el Authorization Server reconoce a sus sistemas.

En una malla de pares, las garantías de la comunidad valen lo que valga su miembro más débil. Ese es el argumento que decide la topología. Si cada miembro descubre y consulta a los demás, cada uno tiene que implementar el descubrimiento y mantener tantas relaciones de confianza como miembros haya. Cada uno tiene que poner además un punto de aplicación de política, el PEP, delante de sus propios datos, y auditar por su cuenta. La política de la comunidad se aplica entonces en tantos lugares como miembros, con la calidad que cada uno pueda pagar, y basta un miembro mal implementado para que la garantía deje de existir para todos. IHE describe tres modelos de intercambio en su whitepaper sobre intercambio de información de salud, entre ellos el centralizado y el federado (HIE Whitepaper, §2.8)¹. HIX elige la centralizada y absorbe esa complejidad una sola vez, en el centro, donde se puede operar, verificar y auditar.

Por esta razón, la relación de confianza no se establece de forma directa entre los miembros, sino entre cada miembro y la infraestructura central. Un miembro no confía en los demás ni necesita conocerlos. Confía en que la comunidad autoriza, media y registra cada interacción. Integrarse a HIX es integrarse una sola vez, con la comunidad. No hay que integrarse con cada uno de los demás miembros, ni volver a hacerlo cuando entra uno nuevo.

Mediación central de la localización y la recuperación

Toda localización y toda recuperación pasan por el Record Locator Service, el mediador de la comunidad. Es el único actor que atiende a los miembros cuando localizan y recuperan, y el único que alcanza a un custodio. Un solicitante obtiene de él los punteros que la política le permite ver, y las URL de contenido que recibe apuntan al propio mediador, nunca al custodio. Al recuperar, el mediador alcanza al custodio en nombre del solicitante y le entrega el documento. Para el miembro, la comunidad es un único servidor FHIR, con independencia de cuántos custodios haya y de cómo se llegue a cada uno.

​MHDS admite que un consumidor alcance directamente al servicio que aloja un documento fuera del Document Registry (MHDS Vol. 1, §1:50.1.1.2)², y reconoce que en ese caso su opción de consentimiento no protege el contenido y que cada Document Source carga solo con la protección de sus documentos (MHDS Vol. 1, §1:50.2.2)³. Con custodia distribuida, eso obligaría a cada custodio a evaluar la política de la comunidad frente a cada consumidor. La mediación cierra ese hueco. La política se aplica en un solo lugar, con una única superficie auditable y un único contrato de integración.

El precio es que la infraestructura central se vuelve indispensable para operar, y se dimensiona y protege como tal. Todo byte clínico atraviesa el mediador. La sección 2.6 especifica lo que eso exige.

Mediar no es lo mismo que enrutar. El mediador es imprescindible donde hay que alcanzar a un custodio en nombre de un miembro, es decir, al recuperar, porque es quien obtiene el token mediado para ese custodio y recorre el canal que el directorio declara.

La decisión de divulgación sobre los punteros es otra cosa. La toma la infraestructura central antes de mover contenido alguno, y la evalúa el mediador o un Document Registry que conozca la política de la comunidad, según dónde la sitúe cada comunidad, como fija la sección 2.2. Como las localizaciones y recuperaciones de los miembros las atiende siempre el mediador, dónde se evalúe es invisible para ellos, y en ningún caso el mediador entrega un puntero o un documento que la decisión niegue.

En las transacciones entre un miembro y un solo componente central, como declarar una identidad o publicar un puntero, no hay nada que mediar. El componente que las recibe comprueba que la petición cumple las reglas de la comunidad para esa transacción, por ejemplo que el miembro solo escribe en su propio dominio de identificadores, y la registra en el repositorio de auditoría de la comunidad. Que el mediador actúe además como fachada de esos componentes y les reenvíe esas transacciones es una decisión de infraestructura, como el canal de transporte. No cambia qué actor las responde ni las reglas que aplica, como explica la sección 2.4.

Nota. Por qué hay un mediador. El flujo de MHDS no lo necesita. Sin él, cada custodio tendría que aplicar la política de la comunidad por su cuenta frente a cada consumidor, con un PEP delante de sus documentos, y auditar por su cuenta, que es el reparto cuyos límites MHDS reconoce. La política se aplicaría en tantos lugares como custodios, con la calidad que cada uno pudiera pagar, y bastaría un custodio mal implementado para que la comunidad dejara de poder garantizar su política, como explica la apertura de esta sección. Cada consumidor tendría que obtener un token para cada custodio y alcanzarlo directamente, y la pregunta de quién accedió a un expediente ya no se respondería desde un solo lugar. La comunidad resultante sería MHDS, no HIX. Dejarían de valer las afirmaciones 1 y 4 del Volumen 1, la comunidad como única contraparte de sus miembros y la credencial derivada de la petición viva del solicitante, y desaparecería HIX-1, porque ya nadie actuaría en nombre de un solicitante. Por eso el mediador es un actor obligatorio de toda comunidad HIX.

Custodia distribuida y almacenamiento central

El documento permanece donde se produjo. El miembro que lo creó lo conserva, responde por su contenido y participa en cada recuperación que lo alcanza. La infraestructura central mantiene el índice, no una copia del expediente.

​MHDS admite dos ubicaciones válidas para el contenido, dentro del Document Registry o en cualquier otro lugar de la comunidad, incluido el sistema del propio Document Source (MHDS Vol. 1, §1:50.1.1.2)². HIX adopta la segunda como política por defecto y ofrece la primera como opción. Un custodio que no puede alojar un endpoint ejerce la Opción de Almacenamiento Central y entrega el contenido a la infraestructura central sin dejar de figurar como custodio.

Las dos ubicaciones tienen ejemplos nacionales. Estonia recupera cada documento del proveedor que lo produjo, como se ve en la sección de transporte. Suiza hace lo contrario. Cada comunidad de su expediente electrónico almacena los binarios en su propio Document Repository y las instituciones le entregan el documento al publicarlo (eHealth Suisse, EPR architecture, §3.3.4)⁴. Su acceso móvil se especifica sobre MHD en CH EPR FHIR. Como la API que ve el solicitante es idéntica bajo ambas ubicaciones, un custodio puede pasar de una a otra sin que ningún miembro lo note. Por eso "el contenido nunca sale del custodio" es una política por defecto y no un principio absoluto. La arquitectura admite las dos y la comunidad decide por custodio.

Identidad del paciente

Ningún miembro conoce ni usa los identificadores de paciente de los demás miembros, ni necesita conocerlos. Para la comunidad, cada miembro es un dominio de identificadores distinto, y un mismo MRN solo tiene sentido dentro del dominio del miembro que lo asignó. La comunidad no reemplaza los MRN. Mantiene una identidad maestra por persona y enlaza con ella las identidades locales que los miembros declaran, de modo que cualquier MRN, de cualquier miembro, resuelve a la misma persona.

La identidad maestra es un recurso Patient en un dominio reservado a la identidad verificada, en el que solo escribe la fuente autoritativa. Lleva un identificador de la persona que la fuente autoritativa reconoce, la cédula en el caso de la figura, que la ancla a alguien real, la demografía verificada que aporta la fuente autoritativa y los enlaces a sus identidades locales, uno por cada miembro que la haya declarado. Contra esa demografía buscan ITI-78 e ITI-119. No lleva demografía de los miembros. Los nombres y las fechas que cada miembro registra se quedan en él.

Figura 2.1-1: Identidad maestra e identidades locales

La Figura 2.1-1 muestra cómo se construye.

• La fuente autoritativa de identidad es quien crea la identidad maestra. Lo hace con el feed PMIR (ITI-93), una vez que comprobó quién es la persona. Nadie más puede crear una identidad maestra. HIX no designa cuál es esa fuente. La propuesta para Costa Rica es que sea el EDUS, como indica la introducción del volumen.
• Cada miembro que publica declara los pacientes de su dominio con el feed PIXm (ITI-104). Envía su MRN junto con un identificador de la persona que la fuente autoritativa reconoce, y el Master Patient Index enlaza ese MRN con la identidad maestra que ya existe para esa persona. Si la persona todavía no tiene identidad maestra, la declaración se rechaza por defecto, como explica la sección 2.2. Si la comunidad traduce identificadores, como describe el apartado sobre el puntero, el miembro no tiene que resolver la identidad maestra antes de publicar ni conservar nada de la respuesta. Nombra al paciente con el identificador que usó para declararlo o con su propio MRN. Si no, la obtiene con ITI-83 cuando la necesita. Un miembro vincula, nunca crea.

Tres consultas responden quién es un paciente, y todas buscan solo entre identidades maestras. La Tabla 2.1-1 las compara. La tercera da a cada resultado un grado de coincidencia, como exige PDQm (PDQm, §2:3.119.4.2.2.4), y los ordena de más a menos probable, como describen los casos de ITI-119⁵.

Tabla 2.1-1: Consultas de identidad

Consulta	Transacción	Qué recibe	Qué devuelve	Cuándo se usa
Por identificador	ITI-83 de PIXm	Un MRN o un identificador que la fuente autoritativa reconoce	La identidad maestra enlazada a él	Es la vía normal. La usan también el Document Registry, al indexar y al resolver el identificador de una consulta, y el Authorization Server al fijar el contexto de paciente
Por datos demográficos	ITI-78 de PDQm	Criterios como el nombre o la fecha de nacimiento	Las identidades maestras que coinciden con ellos	Cuando no hay un identificador fiable
Por coincidencia probabilística	ITI-119 de PDQm	Los datos de un candidato	Las identidades maestras que más se le parecen, de más a menos probable	Cuando los datos están incompletos o pueden traer errores, como un apellido mal escrito

Nota. Un miembro no puede crear una persona, fusionar dos personas ni escribir en el dominio de otro. Sobre las identidades locales de su propio dominio decide él. Y ninguna de las tres consultas prueba una identidad. Eso solo lo hace la fuente autoritativa.

El puntero

La unidad del índice es el puntero, un DocumentReference de FHIR R5 que describe un documento sin contenerlo. Toda decisión de la comunidad se toma sobre el puntero, antes de mover un byte del documento, así que lo que el puntero lleva es una decisión de arquitectura. Estos son sus elementos.

• ​subject apunta a la identidad maestra del paciente en todo puntero que la comunidad registra, nunca a una identidad local. Cómo llega esa identidad al puntero es una decisión de despliegue. La comunidad puede exigir que el custodio publique ya con la identidad maestra, que obtiene con ITI-83, o puede traducir al indexar el identificador con el que el custodio nombra al paciente. Si traduce el identificador de la persona que la fuente autoritativa reconoce, usa la referencia lógica que MHD admite cuando existe un identificador común (MHD, §2:3.65.4.1.2.2)⁶. Si traduce además el MRN del custodio, en su propio dominio, se aparta de MHD, que solo admite la referencia lógica por un identificador común, y la Tabla 2.1-3 lo declara. Con la traducción, ningún miembro tiene que resolver identidades antes de publicar. El Document Registry resuelve el subject con la consulta por identificador y escribe en él la identidad maestra al indexar, como muestra la sección 3.5. En cualquier caso, el puntero queda registrado con la identidad maestra.
• sourcepatient es una extensión que nombra a la identidad local con una referencia lógica, es decir, con el identificador del paciente en el dominio del custodio y sin referencia a ningún recurso, porque ningún actor de la comunidad sirve las identidades locales. Es la extensión estándar documentreference-sourcepatient, que en R5 reemplaza a context.sourcePatientInfo. Conserva la traza de qué miembro declaró a quién y permite volver a resolver subject si un enlace de identidad cambia. Todo puntero registrado lleva los dos, sourcepatient hacia la identidad local y subject hacia la identidad maestra.
• custodian.identifier nombra a la organización responsable con el mismo identificador que lleva su token y que publica el directorio. Nunca es una referencia a un recurso.
• content.attachment.url es una ruta relativa al endpoint del custodio cuando el contenido queda en él. Bajo la Opción de Almacenamiento Central apunta al contenido que conserva el Document Registry. Un puntero nunca contiene una dirección física ni nada que identifique un transporte. Cuando el contenido queda en el custodio, la dirección se resuelve en el directorio en cada recuperación.
• securityLabel lleva la etiqueta de confidencialidad del documento, un código del sistema v3-Confidentiality de HL7, como N para normal, R para restringido o V para muy restringido. Es obligatorio desde la primera publicación. Sin la etiqueta en el índice, decidir si un documento se puede divulgar exigiría leerlo primero, y añadirla después obligaría a releer todos los documentos en los custodios.
• identifier es el identificador de negocio del documento. Identifica una versión concreta, de modo que publicar dos veces la misma versión no duplica el puntero. Una versión nueva no sobrescribe el puntero anterior. Se publica como un puntero nuevo que declara en relatesTo que reemplaza al anterior, y el anterior pasa a estado superseded, como fija MHD (MHD, §2:3.65.4.1.2.3)⁷. Así el índice conserva la historia de cada documento.

El resto de elementos, como status, type o date, son los metadatos habituales de MHD y se especificarán más adelante en esta guía.

Un puntero nunca se publica suelto. Cada publicación es un ITI-65 con un SubmissionSet, un recurso List que agrupa los punteros publicados juntos y dice quién los publicó y cuándo, y puede llevar además carpetas, que también son recursos List (MHD, §2:3.65.4.1.2)⁸. El Document Registry conserva esas listas junto a los punteros, y son lo que devuelve ITI-66. Por eso la decisión de divulgación se aplica también a ellas, y las fusiones de identidad alcanzan a su subject igual que al de los punteros.

Directorio de la comunidad

El directorio describe las organizaciones participantes, su pertenencia a la comunidad y los endpoints en los que responden. Es la fuente de la que la infraestructura central aprende a quién dirigir una recuperación, por qué canal y qué opciones ejerce cada custodio.

Los miembros no consultan el directorio, porque nunca se comunican entre sí. Lo consulta el mediador, en cada recuperación cuyo contenido queda en el custodio, para saber a qué custodio dirigirse y en qué endpoint, y el Document Registry, para comprobar que quien publica es un miembro activo. Por eso incorporar un miembro no exige reconfigurar nada. Basta con darlo de alta en el directorio para que el mediador pueda alcanzarlo. Un custodio puede tener más de un endpoint, porque mCSD lo admite (mCSD, §1:46.8.2)⁹. Con qué criterio elige el mediador entre ellos es política de la comunidad. Si el directorio no devuelve ninguno activo, el mediador trata al custodio como no disponible.

El directorio fija dos valores que se usan tal cual en toda la comunidad. El identificador de la organización es el mismo que el Authorization Server incluye en los tokens del miembro para decir en nombre de qué organización actúa, y el mismo que sus punteros llevan en custodian.identifier. La dirección del endpoint es la URL a la que el mediador llama, la audiencia del token que obtiene para ese custodio y la base contra la que se resuelven las rutas relativas de sus punteros. Como token, puntero y directorio parten del mismo valor, no pueden desincronizarse.

Autorización y delegación

HIX usa OAuth 2.0 (RFC 6749) según lo perfila IUA. La idea de fondo es sencilla. Para hablar con la comunidad, un sistema necesita un token, y todos los tokens los emite un único Authorization Server.

Un miembro obtiene un token para hablar con los actores centrales que atienden sus transacciones, y solo con ellos. Ese token no sirve ante ningún custodio, y el miembro nunca recibe uno que sirva. El mediador comprueba cada token que recibe preguntando al Authorization Server si sigue siendo válido. Esa consulta es la introspección de RFC 7662, que IUA recoge como la transacción Introspect Token (ITI-102).

Cuando una operación exige llegar a un custodio, el mediador no reutiliza el token del solicitante. Lo intercambia por otro, siguiendo OAuth 2.0 Token Exchange (RFC 8693) con un resource indicator (RFC 8707). Presenta al Authorization Server el token del solicitante y pide a cambio uno nuevo, hecho a la medida de esa llamada. Vale para ese solo custodio y un solo tipo de transacción, dura como mucho dos minutos y dice dentro quién pidió y quién actúa en su nombre. La Tabla 2.6-1 detalla lo que lleva.

El custodio valida ese token por su cuenta, con las claves públicas del Authorization Server, sin tener que preguntarle. Así sabe quién pregunta, en nombre de quién actúa la comunidad y para qué.

Ante los actores centrales desplegados como sistemas distintos, el mediador actúa con tokens mediados, que es lo que esta guía recomienda, o con un token propio si la comunidad lo autoriza, como fija la sección 2.2. Solo ITI-90 escapa al scope del solicitante, y por eso HIX-1 lo admite por la delegación registrada. Cada llamada atiende una operación autorizada de un solicitante. Cuando los componentes forman un mismo sistema, la llamada es interna. El mediador es el primer punto de aplicación de la política de la comunidad, no un participante con autoridad propia.

La Figura 2.1-2 resume el recorrido de los tokens. Un solo token entra por la izquierda, el del miembro, y de él derivan los tokens mediados para alcanzar custodios y componentes centrales desplegados como sistemas distintos. Hacia los componentes centrales, la comunidad puede autorizar en su lugar un token propio del mediador.

Figura 2.1-2: Delegación de tokens en HIX

Tres reglas hacen que el mínimo privilegio sea estructural, en lugar de depender de la buena conducta de cada parte.

• Un token, el destino mínimo. Cada token vale solo ante quien tiene que recibirlo. El mediado nunca vale ante dos custodios, porque entonces uno de ellos podría usarlo contra el otro.
• Solo el mediador puede intercambiar. Ningún otro participante puede pedir un token a nombre de un tercero, y los custodios no aceptan tokens llegados por otro camino.
• La autoridad documental nunca crece. Para localizar y recuperar documentos, el token mediado solo permite lo que el solicitante ya podía y lo que la comunidad delega al mediador ante el destino. Solo ITI-90, que ningún solicitante tiene en su scope, se autoriza por la delegación registrada. Poder localizar un documento nunca da poder para recuperarlo.

Un token dice quién pide, qué puede pedir, ante quién y hasta cuándo. El token de un miembro no nombra a ningún paciente. Solo lo hace el de una persona que entra a su propio expediente con SMART App Launch, y ahí el contexto de paciente sirve para confinar el token a ese expediente. La cuenta con la que esa persona entra no es un identificador de paciente. El Authorization Server resuelve el contexto de paciente contra la identidad maestra con la consulta por identificador. En ambos casos, tener un token da derecho a preguntar, no a ver. Qué documentos se entregan lo decide la infraestructura central, puntero por puntero. Esa separación es la idea más importante de este volumen.

Divulgación

La decisión de divulgación se toma en la infraestructura central, sobre los punteros y antes de recuperar contenido alguno. La toma el mediador o, cuando la comunidad la sitúa allí, el Document Registry. Quien la toma combina dos fuentes. Del token toma lo que el Authorization Server avaló del solicitante, es decir, su organización, su propósito de uso y, cuando existe, el contexto de paciente. Del puntero toma el paciente, la etiqueta de confidencialidad, el tipo de documento y el custodio. Nada de lo que el solicitante afirme de sí mismo en la petición cuenta.

Ese orden es lo que hace que centralizar valga su costo. Un puntero cuya divulgación se niega no genera ninguna recuperación, ninguna consulta al directorio y ningún token. La decisión se toma una vez por consulta, y un documento atraviesa dos, porque revelar que existe ya es una divulgación. Al localizar, se filtran los punteros de la respuesta. Al recuperar, el mediador vuelve a evaluar el puntero pedido antes de alcanzar al custodio. Un puntero negado no aparece en la respuesta ni se anuncia como negado.

​El punto de partida es un entorno de consentimiento implícito, con una política única para toda la comunidad. MHDS lo describe en su Consent Manager Option como el entorno en el que se permite divulgar mientras el paciente no haya registrado un consentimiento (MHDS Vol. 1, §1:50.2.2)¹⁰. El destino es PCF, donde las directivas de consentimiento de cada paciente se evalúan en cada petición (PCF Vol. 1, §1:53.4)¹¹. La Opción de Consentimiento declara dónde se aplica esa decisión y qué información necesita. El modelo de consentimiento se especificará en una versión posterior de esta guía a partir de PCF.

Auditoría en ambos extremos

​Cada participante registra lo que hace. Es lo que ATNA exige a todo sistema que se declara Secure Node o Secure Application (ITI TF-1, §9.1.1.1 y §9.1.1.2)¹² y lo que MHDS exige a su Document Registry (MHDS Vol. 1, §1:50.1.1.1)¹³. Los registros siguen los patrones de BALP, que definen cómo se escribe un AuditEvent de FHIR para cada tipo de evento. La infraestructura central registra la solicitud que recibe del miembro y la recuperación que ella misma inicia hacia el custodio. El custodio registra la entrega.

Los registros de una misma divulgación comparten un identificador de correlación. El mediador lo genera al recibir la solicitud y lo transmite al custodio en cada llamada. BALP prevé este uso y reserva un elemento del AuditEvent para guardar el identificador de la petición y correlacionar los registros de cliente y servidor (BALP, §3:5.7.3.1)¹⁴. Así una divulgación se puede reconstruir completa desde sus dos lados.

El token mediado nombra al solicitante original y al mediador como actor. Por eso el custodio registra quién pidió el documento y en nombre de quién actuó la comunidad, y no solo que lo pidió la comunidad.

Ningún registro contiene un token completo ni contenido clínico. Basta un identificador del token, como su jti, para atar el evento a él. Todos los componentes centrales registran en el mismo Audit Record Repository de ATNA, el repositorio de auditoría de la comunidad. Como además toda divulgación pasa por el mediador, la pregunta "quién accedió al expediente de esta persona" se responde desde un solo lugar, ese repositorio. Cómo se consulta se especificará más adelante, como señala la descripción general. Eso no exime a ningún custodio de registrar su lado.

Transporte y redes de intercambio

La dirección física de un custodio vive únicamente en el directorio. El puntero lleva una organización y una ruta relativa. Cuando el contenido queda en el custodio, el mediador resuelve la dirección en cada recuperación y llega al custodio por el canal que el directorio declara para él. Ese canal puede ser una conexión directa o una red de intercambio ya establecida, como X-Road. En ambos casos el puntero, la API que ven los miembros y el modelo de tokens son los mismos. Cambiar de canal es cambiar un dato del directorio.

Una red de intercambio resuelve cómo se conectan las organizaciones y cómo se identifican entre sí. No dice nada de documentos, punteros ni consentimiento. Por eso HIX la usa solo entre cada miembro y la infraestructura central, nunca entre miembros. Si los miembros la usaran para hablar entre sí, volverían a la malla de pares que HIX descarta. Estonia sigue este mismo patrón. Su registro nacional de salud recupera los datos de cada proveedor cuando se necesitan y los presenta en un formato común (e-Estonia)¹⁵, y los sistemas de información del país se conectan entre sí sobre X-Road (e-Estonia)¹⁶. El token mediado sigue viajando por ese canal y el custodio sigue validándolo. La identidad que la red asigna a cada organización no lo sustituye.

Comunidades vecinas

Una comunidad HIX puede conectarse con otras comunidades mediante XCA. La pasarela, con sus Initiating Gateway y Responding Gateway, se agrupa en la infraestructura central junto al Record Locator Service, que la consulta al localizar y al recuperar, así que la mediación se conserva y ningún miembro habla con la otra comunidad. Esta guía no la especifica.

Compromisos asumidos

​IHE deja la gobernanza fuera de su alcance. Declara que no define políticas de privacidad ni de seguridad, y que el marco de políticas de una comunidad debe definirse antes de construirla (MHDS Vol. 1, §1:50.5 y §1:50.5.1)¹⁷. Por eso, de los compromisos de la tabla, el que más pesa es la apuesta por la operación del centro.

Tabla 2.1-2: Compromisos de la arquitectura

Compromiso	Qué se acepta	Cómo se mitiga
Acoplamiento de disponibilidad	Una recuperación mediada necesita al mediador, al Authorization Server y al custodio a la vez	La localización no depende de los custodios. Una recuperación ante un custodio caído falla sin confundirse con un documento inexistente. Cualquier custodio puede pasar a almacenamiento central sin que nadie lo note
Contenido en tránsito por el centro	Todo byte clínico atraviesa el mediador, que lo ve en claro	El mediador no guarda ni registra contenido. El canal entre organizaciones va cifrado. El índice se gobierna como dato sensible
Authorization Server en el camino crítico	Cada operación exige una introspección del token del solicitante y un intercambio por cada destino que el mediador alcanza	Se dimensiona con la misma disponibilidad que el mediador. Un token mediado vale solo ante el destino que nombra su resource, nunca ante dos custodios, y dura como mucho dos minutos, así que un token filtrado tiene una ventana de uso corta y conocida
Apuesta por la operación del centro	La garantía de la comunidad vale lo que valga la operación de su infraestructura central. Un centro bien operado supera a una federación operada a medias, y un centro mal operado es peor que esa federación	Quién certifica miembros, quién responde al paciente y quién financia el centro se fija en la gobernanza de la comunidad, antes de construirla. Es su riesgo principal a largo plazo

Relación con MHDS

​HIX sigue la forma de comunidad que describe MHDS, con una infraestructura central de servicios compartidos y miembros que publican y consumen a través de ella, y toma de él buena parte de su vocabulario. No declara conformidad con MHDS. Sigue los perfiles que MHDS compone, que son los que se mantienen, se prueban y se distribuyen como paquetes versionados. Como la mayoría solo se publica sobre FHIR R4, HIX sigue sus modelos, transacciones y vocabulario sobre FHIR R5 sin declarar conformidad con sus artefactos R4, mientras IHE no publique ediciones R5.

Hay dos razones. La primera es que la última publicación de MHDS es de agosto de 2023 y está hecha sobre FHIR R4¹⁸, y los perfiles que compone siguieron cambiando después. MHD se publicó sobre FHIR R5 y mCSD rehízo y renombró todos sus actores (mCSD, Significant Changes)¹⁹, de modo que MHDS nombra hoy actores que mCSD ya no define.

​La segunda es que HIX no ejerce algunas de sus opciones. Bajo su Authorization Option, MHDS agrupa el Document Registry con el Authorization Server (MHDS Vol. 1, §1:50.2.1)²⁰, y bajo su Consent Manager Option deja en este la gestión del consentimiento (MHDS Vol. 1, §1:50.2.2)²¹. HIX quiere un único emisor para varios Resource Servers, el despliegue que IUA prevé al no atar el Authorization Server a los Resource Servers (IUA, Relation to SMART-on-FHIR)²².

De ahí salen dos reglas. Cuando MHDS y un perfil vigente dicen cosas distintas, prevalece el perfil vigente. Cuando MHDS y una decisión de HIX dicen cosas distintas, esta guía declara en qué se aparta y por qué. La Tabla 2.1-3 reúne lo que HIX toma de MHDS y lo que no.

Tabla 2.1-3: Lo que HIX toma de MHDS y lo que no

Asunto	En MHDS	En HIX
Forma de la comunidad	Infraestructura central de servicios compartidos, con miembros que publican y consumen	La misma
Document Registry	Actor propio de MHDS, con sus opciones	Actor de HIX con el mismo nombre y la misma función, definido por los actores que agrupa en la sección 2.4
Acceso de quien consulta	Directo al Document Registry y, si el contenido está fuera de él, al servicio que lo aloja	Siempre a través del Record Locator Service
URL del contenido fuera del Document Registry	Una URL persistente al Binary	Una ruta relativa al endpoint del custodio, que se resuelve en el directorio en cada recuperación
Identidad que aporta un miembro	El miembro crea y actualiza identidades en el registro de la comunidad, como Patient Identity Source de PMIR	El miembro declara sus identidades locales con ITI-104 de PIXm y nunca crea una persona
Identificador con el que un miembro nombra al paciente	Una referencia al Patient de la comunidad o una referencia lógica por un identificador común, como el nacional, que es lo que MHD admite	Además, si la comunidad lo autoriza, una referencia lógica por el identificador del propio dominio del miembro, que el Document Registry traduce con ITI-83 al publicar, al localizar o en ambos casos
Authorization Server	Agrupado con el Document Registry bajo la Authorization Option	Servicio central independiente y único emisor de la comunidad
Consentimiento	Lo gestiona y decide el Authorization Server agrupado	La decisión de divulgación se toma sobre los punteros en la infraestructura central, no en el Authorization Server. Eso no impide adoptar PCF más adelante, con los actores que defina
Versiones	FHIR R4 y las versiones de los perfiles vigentes en 2023	FHIR R5 y la versión vigente de cada perfil
Conformidad	Declarada con los perfiles sobre FHIR R4	Sigue sus modelos, transacciones y vocabulario sobre FHIR R5, sin declarar conformidad con sus artefactos R4

​El apartamiento de más peso es el de la identidad. MHDS deja que los participantes creen y actualicen identidades en el registro de la comunidad (MHDS Vol. 1, §1:50.1)²³. HIX reserva esa facultad a la fuente autoritativa, como explica el apartado sobre la identidad del paciente, para que ningún miembro pueda crear una persona.

Referencias

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