Unattributed Code Systems

Copyright Fragment

This fragment is not visible to the reader

No use of external IP (other than from the FHIR specification)

Copyright and Registered Trademark Uses

External References

Type Reference Content
web profiles.ihe.net Document Registry. El registro de documentos de la comunidad. Conserva los punteros a los documentos publicados y, bajo la Opción de Almacenamiento Central, el contenido que los custodios le entregan. Toma su nombre y su función del Document Registry de MHDS , pero es un actor de HIX, definido por los actores que agrupa.
web profiles.ihe.net Authorization Server .
web profiles.ihe.net Audit Record Repository .
web profiles.ihe.net Document Source .
web profiles.ihe.net Document Consumer .
web profiles.ihe.net Document Responder .
web profiles.ihe.net Document Recipient .
web profiles.ihe.net Patient Identity Source .
web profiles.ihe.net Patient Identity Registry .
web profiles.ihe.net Patient Identity Consumer .
web profiles.ihe.net Patient Identifier Cross-reference Manager .
web profiles.ihe.net Patient Identifier Cross-reference Consumer .
web profiles.ihe.net Patient Demographics Supplier .
web profiles.ihe.net Patient Demographics Consumer .
web profiles.ihe.net Directory .
web profiles.ihe.net Query Client .
web profiles.ihe.net Authorization Client .
web profiles.ihe.net Resource Server .
web profiles.ihe.net Secure Node y Secure Application .
web profiles.ihe.net Time Client .
web openid.net OpenID Provider .
web meddyg.com IG © 2026+ Meddyg . Package meddyg.hix#0.1.0 based on FHIR 5.0.0 . Generated 2026-09-22
Links: Table of Contents | QA Report
web profiles.ihe.net Mobile Health Document Sharing (MHDS)
web profiles.ihe.net IUA
web www.rfc-editor.org OAuth 2.0
web x-road.global X-Road
web www.rfc-editor.org Las palabras clave MUST , MUST NOT , REQUIRED , SHALL , SHALL NOT , SHOULD , SHOULD NOT , RECOMMENDED , NOT RECOMMENDED , MAY y OPTIONAL , cuando aparecen íntegramente en mayúsculas, se interpretan conforme a RFC 2119 y RFC 8174 .
web www.rfc-editor.org Las palabras clave MUST , MUST NOT , REQUIRED , SHALL , SHALL NOT , SHOULD , SHOULD NOT , RECOMMENDED , NOT RECOMMENDED , MAY y OPTIONAL , cuando aparecen íntegramente en mayúsculas, se interpretan conforme a RFC 2119 y RFC 8174 .
web profiles.ihe.net MHDS
web profiles.ihe.net MHD
web profiles.ihe.net PMIR
web profiles.ihe.net PIXm
web profiles.ihe.net PDQm
web profiles.ihe.net mCSD
web profiles.ihe.net ATNA
web profiles.ihe.net CT
web profiles.ihe.net BALP
web hix.meddyg.com ​ Para asistentes de IA. llms.txt es un índice en texto plano con una línea por página, que dice de qué trata cada una y enlaza a su versión en Markdown. Un implementador puede dárselo a su agente para que lea solo las páginas que necesita. llms-full.txt reúne la guía completa en un solo archivo. Los dos se generan de forma automática en cada publicación, a partir de las mismas páginas que forman este sitio. No hay una segunda redacción, así que su contenido no puede apartarse del de la guía.
web hix.meddyg.com ​ Para asistentes de IA. llms.txt es un índice en texto plano con una línea por página, que dice de qué trata cada una y enlaza a su versión en Markdown. Un implementador puede dárselo a su agente para que lea solo las páginas que necesita. llms-full.txt reúne la guía completa en un solo archivo. Los dos se generan de forma automática en cada publicación, a partir de las mismas páginas que forman este sitio. No hay una segunda redacción, así que su contenido no puede apartarse del de la guía.
web github.com Para leer sin conexión. El PDF y el documento de Word de cada versión se adjuntan a su publicación en GitHub .
web www.rfc-editor.org Las descripciones siguen el orden de las tablas. Dos reglas valen para todos los actores y no se repiten en cada uno. Todo actor que recibe un token SHALL comprobar que está destinado a él y SHALL rechazar la solicitud si no lo está, como recomienda RFC 9700 para todo Resource Server ( RFC 9700, §4.10.2 ) 2 . Que el Authorization Server de la comunidad haya emitido un token no lo hace válido ante cualquier actor. Cada token nombra en su audiencia, el claim aud , a los actores ante los que vale, y ante cualquier otro no sirve, aunque lo haya emitido el mismo Authorization Server. Y todo sistema de un miembro y todo actor central registra sus propios eventos de auditoría, como exige la agrupación con ATNA de la sección 2.4 .
web profiles.ihe.net El custodio SHALL declarar mediante ITI-104 la identidad local de todo paciente sobre el que publique, en su propio dominio de identificadores y con el identificador nacional de la persona. SHALL publicar mediante ITI-65 punteros que lo nombren a él como custodio y lleven etiqueta de confidencialidad, con URL de contenido relativa cuando el contenido queda en él.
web profiles.ihe.net El custodio SHALL declarar mediante ITI-104 la identidad local de todo paciente sobre el que publique, en su propio dominio de identificadores y con el identificador nacional de la persona. SHALL publicar mediante ITI-65 punteros que lo nombren a él como custodio y lleven etiqueta de confidencialidad, con URL de contenido relativa cuando el contenido queda en él.
web profiles.ihe.net El custodio SHALL conservar el contenido y responder ITI-68 , salvo que declare la Opción de Almacenamiento Central. SHALL validar localmente el token de cada solicitud con las claves que publica el Authorization Server, conforme a la sección 2.6 . SHALL rechazar toda solicitud cuyo token no haya sido intercambiado por el Record Locator Service y SHALL NOT atender recuperaciones originadas directamente en otro miembro.
web profiles.ihe.net El consumidor SHALL obtener un token del Authorization Server destinado al Record Locator Service y SHALL presentarlo en toda solicitud. SHALL recuperar los documentos únicamente a través de las URL que el Record Locator Service le entrega. Puede resolver la identidad de un paciente con ITI-83 y, si declara la Opción de Demografía, buscarlo por sus datos demográficos con ITI-78 . Si declara la Opción de Coincidencia Demográfica, puede pedir además con ITI-119 las identidades que más se parecen a unos datos incompletos. Ambas sirven, por ejemplo, en una urgencia en la que no tiene un identificador fiable, como en la Figura 2.2-2 .
web profiles.ihe.net El consumidor SHALL obtener un token del Authorization Server destinado al Record Locator Service y SHALL presentarlo en toda solicitud. SHALL recuperar los documentos únicamente a través de las URL que el Record Locator Service le entrega. Puede resolver la identidad de un paciente con ITI-83 y, si declara la Opción de Demografía, buscarlo por sus datos demográficos con ITI-78 . Si declara la Opción de Coincidencia Demográfica, puede pedir además con ITI-119 las identidades que más se parecen a unos datos incompletos. Ambas sirven, por ejemplo, en una urgencia en la que no tiene un identificador fiable, como en la Figura 2.2-2 .
web profiles.ihe.net El consumidor SHALL obtener un token del Authorization Server destinado al Record Locator Service y SHALL presentarlo en toda solicitud. SHALL recuperar los documentos únicamente a través de las URL que el Record Locator Service le entrega. Puede resolver la identidad de un paciente con ITI-83 y, si declara la Opción de Demografía, buscarlo por sus datos demográficos con ITI-78 . Si declara la Opción de Coincidencia Demográfica, puede pedir además con ITI-119 las identidades que más se parecen a unos datos incompletos. Ambas sirven, por ejemplo, en una urgencia en la que no tiene un identificador fiable, como en la Figura 2.2-2 .
web profiles.ihe.net El Record Locator Service SHALL aceptar únicamente tokens emitidos por el Authorization Server de la comunidad. SHALL comprobarlos mediante ITI-102 una vez por operación y SHALL tomar de esa respuesta, y no de la solicitud, la organización, el propósito de uso y el contexto de paciente del solicitante.
web profiles.ihe.net El Record Locator Service SHALL evaluar la decisión de divulgación sobre los punteros antes de originar cualquier recuperación, SHALL omitir de la respuesta los punteros cuya divulgación no esté permitida y SHALL volver a evaluarla al atender un ITI-68 . La omisión SHALL NOT ser distinguible, para el solicitante, de la ausencia del documento, y SHALL quedar registrada en la auditoría. SHALL aplicar la misma decisión a las listas que devuelve por ITI-66 , porque una lista revela qué documentos existen. Un puntero cuya divulgación se niega SHALL NOT originar consulta al directorio, intercambio de token ni llamada al custodio.
web profiles.ihe.net El Record Locator Service SHALL evaluar la decisión de divulgación sobre los punteros antes de originar cualquier recuperación, SHALL omitir de la respuesta los punteros cuya divulgación no esté permitida y SHALL volver a evaluarla al atender un ITI-68 . La omisión SHALL NOT ser distinguible, para el solicitante, de la ausencia del documento, y SHALL quedar registrada en la auditoría. SHALL aplicar la misma decisión a las listas que devuelve por ITI-66 , porque una lista revela qué documentos existen. Un puntero cuya divulgación se niega SHALL NOT originar consulta al directorio, intercambio de token ni llamada al custodio.
web profiles.ihe.net Nota. Record Locator Service es el nombre que esta guía da al actor. No es vocabulario IHE. Corresponde al localizador central del modelo Centralized Discovery and Retrieve de IHE, el que permite descubrir dónde están los documentos y recuperarlos del custodio que registró su existencia ( IHE HIE Whitepaper, §2.8 ) 3 . En HIX media además la recuperación, y se implementa agrupando un Document Consumer y un Document Responder de MHD .
web profiles.ihe.net El Document Registry es el registro de documentos de la comunidad. Toma su nombre y su función del Document Registry de MHDS , pero es un actor de HIX, definido por los actores que agrupa en la sección 2.4 . Conserva los punteros a los documentos publicados y, bajo la Opción de Almacenamiento Central, el contenido que los custodios le entregan. Recibe por ITI-93 los cambios de las identidades maestras.
web profiles.ihe.net El Document Registry SHALL registrar cada puntero a nombre de la organización que declara el token, SHALL rechazar la publicación cuyo custodio no coincida con ella y SHALL validar mediante ITI-90 que esa organización es un miembro activo de la comunidad. SHALL aplicar a los punteros y a las listas que conserva las fusiones de identidades maestras que recibe por ITI-93, de modo que ningún puntero quede asociado a una identidad que dejó de existir.
web profiles.ihe.net El Document Registry SHALL registrar únicamente punteros cuyo subject sea la identidad maestra del paciente y que conserven en sourcepatient la identidad local con la que el custodio lo nombró. Cuando la publicación nombra al paciente solo con su identidad local, la infraestructura central SHALL resolverla mediante ITI-83 y escribir el resultado en subject al indexar. Así el miembro publica con sus propios identificadores y la comunidad traduce y valida por él.
web profiles.ihe.net Esa consulta comprueba a la vez que la persona existe y está activa en la comunidad, porque PIXm no resuelve una identidad desactivada o eliminada ( PIXm, §2:3.83.4.2.2.5 ) 4 . Es la misma comprobación que MHDS pide a su Document Registry antes de indexar, y que admite resolver preguntando al registro de identidad ( MHDS Vol. 1, §1:50.1.1.1.1 ) 5 .
web profiles.ihe.net Esa consulta comprueba a la vez que la persona existe y está activa en la comunidad, porque PIXm no resuelve una identidad desactivada o eliminada ( PIXm, §2:3.83.4.2.2.5 ) 4 . Es la misma comprobación que MHDS pide a su Document Registry antes de indexar, y que admite resolver preguntando al registro de identidad ( MHDS Vol. 1, §1:50.1.1.1.1 ) 5 .
web www.rfc-editor.org El Authorization Server SHALL restringir la audiencia de todo token que emite a destinatarios identificados explícitamente, como recomienda RFC 9700 ( RFC 9700, §2.3 ) 2 . El token del solicitante nombra a los actores centrales que el miembro alcanza directamente y el token intercambiado a un único destino, como fija la sección 2.6 .
web www.rfc-editor.org El Authorization Server SHALL atender HIX-1 únicamente para el Record Locator Service. El token intercambiado SHALL llevar como audiencia el único destino indicado en la petición de intercambio, el mismo sujeto, las mismas extensiones de IUA y, si lo hay, el mismo contexto de paciente que el token presentado, y como actor al Record Locator Service, en el claim act con el que OAuth 2.0 Token Exchange expresa la delegación ( RFC 8693, §4.1 ) 6 .
web profiles.ihe.net El Authorization Server SHALL fijar la organización y el propósito de uso del solicitante desde su propio registro y SHALL NOT aceptarlos de la solicitud. Cuando una persona se autentica, SHALL resolver su identidad verificada a la identidad maestra mediante ITI-83 y SHALL fijar ese resultado como contexto de paciente del token, conforme a HIX-2 . SHALL NOT emitir un token con contexto de paciente cuando esa identidad no resuelva a una identidad maestra.
web profiles.ihe.net El directorio SHALL responder ITI-90 y SHALL ser el único origen de los endpoints que usa la infraestructura central. SHALL identificar a cada organización con el mismo identificador que el Authorization Server incluye en sus tokens. Los miembros no consultan el directorio. Su contenido se mantiene administrativamente, al incorporar un miembro.
web profiles.ihe.net El registro de identidad maestra SHALL crear identidades maestras únicamente a partir de ITI-93 recibido de la fuente autoritativa de identidad. SHALL aceptar ITI-104 únicamente en el dominio de identificadores del miembro que lo origina y SHALL rechazar la declaración que no pueda vincularse a una identidad maestra existente. Dentro de su propio dominio el miembro gestiona sus identidades locales con libertad, incluida la resolución de sus propios duplicados que define ITI-104.
web profiles.ihe.net El registro de identidad maestra SHALL crear identidades maestras únicamente a partir de ITI-93 recibido de la fuente autoritativa de identidad. SHALL aceptar ITI-104 únicamente en el dominio de identificadores del miembro que lo origina y SHALL rechazar la declaración que no pueda vincularse a una identidad maestra existente. Dentro de su propio dominio el miembro gestiona sus identidades locales con libertad, incluida la resolución de sus propios duplicados que define ITI-104.
web profiles.ihe.net Una declaración de un miembro SHALL NOT crear, fusionar ni eliminar una identidad maestra. El registro SHALL NOT modificar la demografía de la identidad maestra a partir de lo que un miembro declara. SHALL responder ITI-83 únicamente con la identidad maestra, nunca con las identidades locales que otros miembros declararon. PIXm admite esa restricción, porque deja que la respuesta sea un subconjunto determinado por política ( PIXm, §2:3.83.4.1.3 ) 7 .
web profiles.ihe.net Una declaración de un miembro SHALL NOT crear, fusionar ni eliminar una identidad maestra. El registro SHALL NOT modificar la demografía de la identidad maestra a partir de lo que un miembro declara. SHALL responder ITI-83 únicamente con la identidad maestra, nunca con las identidades locales que otros miembros declararon. PIXm admite esa restricción, porque deja que la respuesta sea un subconjunto determinado por política ( PIXm, §2:3.83.4.1.3 ) 7 .
web profiles.ihe.net El Audit Record Repository es el actor de ATNA que recibe mediante ITI-20 los eventos que registran los actores centrales. Existe para que una divulgación pueda reconstruirse completa desde el lado de la comunidad, con la solicitud del miembro y la recuperación ante el custodio bajo un mismo identificador de correlación. Cada miembro registra su propio lado en su propio registro, como ATNA exige a todo Secure Node o Secure Application.
web profiles.ihe.net La fuente autoritativa SHALL alimentar el registro de identidad maestra mediante ITI-93 , con un token emitido por el Authorization Server de la comunidad. Es la única que crea, actualiza, fusiona o desactiva identidades maestras.
web www.rfc-editor.org Custodian Token Exchange [HIX-1]. El Record Locator Service presenta al Authorization Server el token del solicitante, un único destino y el alcance de la transacción que va a realizar, y recibe a cambio el token intercambiado para ese destino, sea un custodio o un actor central. Lo que ese token lleva lo fijan los requisitos del Authorization Server y lo resume la Tabla 2.6-1 . Es un intercambio OAuth 2.0 Token Exchange ( RFC 8693 ) con resource indicator ( RFC 8707 ), restringido al mediador. No es una transacción IUA . IUA limita ITI-71 a los grants Authorization Code y Client Credentials ( IUA, §34.1.1.1 ) 8 y toma de RFC 8693 solo el parámetro con el que se pide el tipo de token.
web www.rfc-editor.org Custodian Token Exchange [HIX-1]. El Record Locator Service presenta al Authorization Server el token del solicitante, un único destino y el alcance de la transacción que va a realizar, y recibe a cambio el token intercambiado para ese destino, sea un custodio o un actor central. Lo que ese token lleva lo fijan los requisitos del Authorization Server y lo resume la Tabla 2.6-1 . Es un intercambio OAuth 2.0 Token Exchange ( RFC 8693 ) con resource indicator ( RFC 8707 ), restringido al mediador. No es una transacción IUA . IUA limita ITI-71 a los grants Authorization Code y Client Credentials ( IUA, §34.1.1.1 ) 8 y toma de RFC 8693 solo el parámetro con el que se pide el tipo de token.
web profiles.ihe.net Custodian Token Exchange [HIX-1]. El Record Locator Service presenta al Authorization Server el token del solicitante, un único destino y el alcance de la transacción que va a realizar, y recibe a cambio el token intercambiado para ese destino, sea un custodio o un actor central. Lo que ese token lleva lo fijan los requisitos del Authorization Server y lo resume la Tabla 2.6-1 . Es un intercambio OAuth 2.0 Token Exchange ( RFC 8693 ) con resource indicator ( RFC 8707 ), restringido al mediador. No es una transacción IUA . IUA limita ITI-71 a los grants Authorization Code y Client Credentials ( IUA, §34.1.1.1 ) 8 y toma de RFC 8693 solo el parámetro con el que se pide el tipo de token.
web profiles.ihe.net Custodian Token Exchange [HIX-1]. El Record Locator Service presenta al Authorization Server el token del solicitante, un único destino y el alcance de la transacción que va a realizar, y recibe a cambio el token intercambiado para ese destino, sea un custodio o un actor central. Lo que ese token lleva lo fijan los requisitos del Authorization Server y lo resume la Tabla 2.6-1 . Es un intercambio OAuth 2.0 Token Exchange ( RFC 8693 ) con resource indicator ( RFC 8707 ), restringido al mediador. No es una transacción IUA . IUA limita ITI-71 a los grants Authorization Code y Client Credentials ( IUA, §34.1.1.1 ) 8 y toma de RFC 8693 solo el parámetro con el que se pide el tipo de token.
web profiles.ihe.net Patient Application Launch [HIX-2]. Una aplicación elegida por una persona obtiene del Authorization Server un token destinado al Record Locator Service cuyo contexto de paciente es la identidad maestra de esa persona. El Authorization Server resuelve esa identidad en el momento del consentimiento. Es la transacción Get Access Token [ITI-71] de IUA con el grant Authorization Code, perfilada por SMART App Launch . HIX le da identificador propio por lo que añade, que es el contexto de paciente que fija el Authorization Server, y no porque sea ajena a IUA . Se especifica en el Volumen 2.
web www.rfc-editor.org RFC 9700, §2.3 Access Token Privilege Restriction : "In particular, access tokens SHOULD be audience-restricted to a specific resource server or, if that is not feasible, to a small set of resource servers." §4.10.2 Audience-Restricted Access Tokens : "The authorization server associates the access token with the particular resource server, and the resource server is then supposed to verify the intended audience . If the access token fails the intended audience validation, the resource server refuses to serve the respective request ."  ↩   ↩2
web www.rfc-editor.org RFC 9700, §2.3 Access Token Privilege Restriction : "In particular, access tokens SHOULD be audience-restricted to a specific resource server or, if that is not feasible, to a small set of resource servers." §4.10.2 Audience-Restricted Access Tokens : "The authorization server associates the access token with the particular resource server, and the resource server is then supposed to verify the intended audience . If the access token fails the intended audience validation, the resource server refuses to serve the respective request ."  ↩   ↩2
web profiles.ihe.net 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".  ↩
web profiles.ihe.net PIXm, §2:3.83.4.2.2.5 Post Merge/Delete : "Based upon policy, when the Patient is deprecated or deleted, the response message shall return: 200 OK, and return a Bundle with no patient resource, or 404 Not Found "  ↩
web profiles.ihe.net MHDS Vol. 1, §1:50.1.1.1.1 When the grouped MHD Document Recipient is triggered : "The Document Registry SHALL validate that the subject of the DocumentReference, and List Resources is the same Patient, and that Patient is a recognized and active Patient within the Community . The Patient identity must be recognized and active by the PMIR Patient Identity Registry in the document sharing community. This may be accomplished by a query of the PMIR Patient Identity Registry , by way of a cached internal patient database, or other means."  ↩
web www.rfc-editor.org RFC 8693, §1.1 Delegation vs. Impersonation Semantics : "With delegation semantics, principal A still has its own identity separate from B, and it is explicitly understood that while B may have delegated some of its rights to A, any actions taken are being taken by A representing B ." §2.1 Request : "resource. OPTIONAL. A URI that indicates the target service or resource where the client intends to use the requested security token. " §4.1 "act" (Actor) Claim : "The act (actor) claim provides a means within a JWT to express that delegation has occurred and identify the acting party to whom authority has been delegated ."  ↩
web www.rfc-editor.org RFC 8693, §1.1 Delegation vs. Impersonation Semantics : "With delegation semantics, principal A still has its own identity separate from B, and it is explicitly understood that while B may have delegated some of its rights to A, any actions taken are being taken by A representing B ." §2.1 Request : "resource. OPTIONAL. A URI that indicates the target service or resource where the client intends to use the requested security token. " §4.1 "act" (Actor) Claim : "The act (actor) claim provides a means within a JWT to express that delegation has occurred and identify the acting party to whom authority has been delegated ."  ↩
web www.rfc-editor.org RFC 8693, §1.1 Delegation vs. Impersonation Semantics : "With delegation semantics, principal A still has its own identity separate from B, and it is explicitly understood that while B may have delegated some of its rights to A, any actions taken are being taken by A representing B ." §2.1 Request : "resource. OPTIONAL. A URI that indicates the target service or resource where the client intends to use the requested security token. " §4.1 "act" (Actor) Claim : "The act (actor) claim provides a means within a JWT to express that delegation has occurred and identify the acting party to whom authority has been delegated ."  ↩
web profiles.ihe.net PIXm, §2:3.83.4.1.3 Expected Actions : " The Patient Identifiers returned may be a subset based on policies that might restrict access to some Patient Identifiers. For guidance on handling Access Denied, see ITI TF-2: Appendix Z.7."  ↩
web profiles.ihe.net IUA, §34.1.1.1 Authorization Client : "The Get Access Token [ITI-71] transaction is scoped to the Authorization Code and Client Credential grant types (see ITI TF-1: 34.4.1.1 Authorization Grant Types)." §3.71.4.1.2.1 Client Credential grant type : "requested_token_type (optional): The requested token format shall be urn:ietf:params:oauth:token-type:jwt, urn:ietf:params:oauth:token-type:saml2 or urn:ietf:params:oauth:token-type:access-token [ RFC 8693 OAuth 2.0 Token Exchange , Section 3]."  ↩
web profiles.ihe.net IUA, §34.1.1.1 Authorization Client : "The Get Access Token [ITI-71] transaction is scoped to the Authorization Code and Client Credential grant types (see ITI TF-1: 34.4.1.1 Authorization Grant Types)." §3.71.4.1.2.1 Client Credential grant type : "requested_token_type (optional): The requested token format shall be urn:ietf:params:oauth:token-type:jwt, urn:ietf:params:oauth:token-type:saml2 or urn:ietf:params:oauth:token-type:access-token [ RFC 8693 OAuth 2.0 Token Exchange , Section 3]."  ↩
web profiles.ihe.net 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 ambas topologías en su whitepaper sobre intercambio de información de salud ( HIE Whitepaper, §2.8 y §3.2 ) 1 . HIX elige la centralizada y absorbe esa complejidad una sola vez, en el centro, donde se puede operar, verificar y auditar.
web profiles.ihe.net 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 ambas topologías en su whitepaper sobre intercambio de información de salud ( HIE Whitepaper, §2.8 y §3.2 ) 1 . HIX elige la centralizada y absorbe esa complejidad una sola vez, en el centro, donde se puede operar, verificar y auditar.
web profiles.ihe.net 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 ) 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 ) 3 . 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.
web profiles.ihe.net 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 ) 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 ) 3 . 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.
web profiles.ihe.net 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 ) 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.
web www.e-health-suisse.ch 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 ) 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.
web fhir.ch 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 ) 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.
web profiles.ihe.net 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 con su identificador nacional. Nadie más puede crear una identidad maestra. HIX no define cuál debe ser esa fuente, pero propone que sea el EDUS, como indica la introducción del volumen.
web profiles.ihe.net Cada miembro que publica declara los pacientes de su dominio con el feed PIXm ( ITI-104 ). Envía su identificador local junto con el identificador nacional de la persona, y el registro de identidad enlaza ese identificador local con la identidad maestra que ya existe para esa persona. Si la persona todavía no tiene identidad maestra, la declaración se rechaza. 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 ordena sus resultados y da a cada uno un grado de coincidencia, como fija PDQm ( PDQm, §2:3.119.4.2.2.4 ) 5 .
web profiles.ihe.net Cada miembro que publica declara los pacientes de su dominio con el feed PIXm ( ITI-104 ). Envía su identificador local junto con el identificador nacional de la persona, y el registro de identidad enlaza ese identificador local con la identidad maestra que ya existe para esa persona. Si la persona todavía no tiene identidad maestra, la declaración se rechaza. 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 ordena sus resultados y da a cada uno un grado de coincidencia, como fija PDQm ( PDQm, §2:3.119.4.2.2.4 ) 5 .
web profiles.ihe.net ITI-83 de PIXm
web profiles.ihe.net ITI-78 de PDQm
web profiles.ihe.net ITI-119 de PDQm
web profiles.ihe.net 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 ) 6 . Así el índice conserva la historia de cada documento.
web profiles.ihe.net 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 ) 7 . 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.
web profiles.ihe.net Los miembros no consultan el directorio, porque nunca se comunican entre sí. Lo consulta el mediador, en cada operación, para saber a qué custodio dirigirse y en qué endpoint. 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 ) 8 . 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.
web www.rfc-editor.org 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.
web profiles.ihe.net 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.
web www.rfc-editor.org Un miembro obtiene un token para hablar con el Record Locator Service, y solo con él. 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 ).
web profiles.ihe.net Un miembro obtiene un token para hablar con el Record Locator Service, y solo con él. 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 ).
web www.rfc-editor.org 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 un solo custodio y una sola 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.
web www.rfc-editor.org 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 un solo custodio y una sola 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.
web profiles.ihe.net 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 ) 9 . 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 ) 10 . 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.
web profiles.ihe.net 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 ) 9 . 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 ) 10 . 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.
web profiles.ihe.net 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 ) 11 y lo que MHDS exige a su Document Registry ( MHDS Vol. 1, §1:50.1.1.1 ) 12 . 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.
web profiles.ihe.net 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 ) 11 y lo que MHDS exige a su Document Registry ( MHDS Vol. 1, §1:50.1.1.1 ) 12 . 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.
web profiles.ihe.net 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 ) 11 y lo que MHDS exige a su Document Registry ( MHDS Vol. 1, §1:50.1.1.1 ) 12 . 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.
web profiles.ihe.net 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 ) 11 y lo que MHDS exige a su Document Registry ( MHDS Vol. 1, §1:50.1.1.1 ) 12 . 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.
web profiles.ihe.net 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 ) 13 . Así una divulgación se puede reconstruir completa desde sus dos lados.
web x-road.global La dirección física de un custodio vive únicamente en el directorio. El puntero lleva una organización y una ruta relativa. 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.
web e-estonia.com 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 por debajo del mediador. 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 ) 14 , y los sistemas de información del país se conectan entre sí sobre X-Road ( e-Estonia ) 15 . El token intercambiado sigue viajando por ese canal y el custodio sigue validándolo. La identidad que la red asigna a cada organización no lo sustituye.
web e-estonia.com 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 por debajo del mediador. 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 ) 14 , y los sistemas de información del país se conectan entre sí sobre X-Road ( e-Estonia ) 15 . El token intercambiado sigue viajando por ese canal y el custodio sigue validándolo. La identidad que la red asigna a cada organización no lo sustituye.
web profiles.ihe.net Una comunidad HIX puede conectarse con comunidades que operen sobre XDS o XCA mediante una pasarela. Ante HIX la pasarela es un miembro más, custodio de los documentos que trae de la otra comunidad o consumidor de los que le pide. Ante la otra comunidad es un Initiating Gateway o un Responding Gateway de XCA . Así la mediación se conserva, porque el Record Locator Service alcanza a la pasarela como a cualquier custodio y ningún miembro habla con la otra comunidad.
web profiles.ihe.net Una comunidad HIX puede conectarse con comunidades que operen sobre XDS o XCA mediante una pasarela. Ante HIX la pasarela es un miembro más, custodio de los documentos que trae de la otra comunidad o consumidor de los que le pide. Ante la otra comunidad es un Initiating Gateway o un Responding Gateway de XCA . Así la mediación se conserva, porque el Record Locator Service alcanza a la pasarela como a cualquier custodio y ningún miembro habla con la otra comunidad.
web profiles.ihe.net MHD prevé un puente así hacia XDS con su XDS on FHIR Option 16 , y advierte que no convive en un mismo despliegue con la UnContained Reference Option que declaran los actores de HIX. Por eso la pasarela es siempre un sistema aparte. Esta guía no la especifica.
web profiles.ihe.net 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 ) 17 . Por eso, de los compromisos de la tabla, la apuesta por la operación del centro es el que más pesa.
web profiles.ihe.net 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 ) 17 . Por eso, de los compromisos de la tabla, la apuesta por la operación del centro es el que más pesa.
web profiles.ihe.net 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 . La declara con los perfiles que MHDS compone, que son los que se mantienen, se prueban y se distribuyen como paquetes versionados.
web profiles.ihe.net Hay dos razones. La primera es que la última publicación de MHDS es de agosto de 2023 y está hecha sobre FHIR R4 18 , 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 ) 19 , de modo que MHDS nombra hoy actores que mCSD ya no define.
web profiles.ihe.net Hay dos razones. La primera es que la última publicación de MHDS es de agosto de 2023 y está hecha sobre FHIR R4 18 , 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 ) 19 , de modo que MHDS nombra hoy actores que mCSD ya no define.
web profiles.ihe.net La segunda es que algunas de sus decisiones chocan con los perfiles que compone. MHDS agrupa el Document Registry con el Authorization Server ( MHDS Vol. 1, §1:50.2.1 ) 20 y deja en este la gestión del consentimiento ( MHDS Vol. 1, §1:50.2.2 ) 21 . IUA , en cambio, se distingue precisamente por no atar el Authorization Server a los Resource Servers ( IUA, Relation to SMART-on-FHIR ) 22 .
web profiles.ihe.net La segunda es que algunas de sus decisiones chocan con los perfiles que compone. MHDS agrupa el Document Registry con el Authorization Server ( MHDS Vol. 1, §1:50.2.1 ) 20 y deja en este la gestión del consentimiento ( MHDS Vol. 1, §1:50.2.2 ) 21 . IUA , en cambio, se distingue precisamente por no atar el Authorization Server a los Resource Servers ( IUA, Relation to SMART-on-FHIR ) 22 .
web profiles.ihe.net La segunda es que algunas de sus decisiones chocan con los perfiles que compone. MHDS agrupa el Document Registry con el Authorization Server ( MHDS Vol. 1, §1:50.2.1 ) 20 y deja en este la gestión del consentimiento ( MHDS Vol. 1, §1:50.2.2 ) 21 . IUA , en cambio, se distingue precisamente por no atar el Authorization Server a los Resource Servers ( IUA, Relation to SMART-on-FHIR ) 22 .
web profiles.ihe.net 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 ) 23 . 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.
web profiles.ihe.net IHE HIE Whitepaper, §2.8 Document Sharing Models : "the centralized model requires knowledge only of the centralized locator […]. For Push and Federated approaches a detailed directory of participating entitles [sic] is typically used". §3.2 Centralized Discovery and Retrieve : "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".  ↩
web profiles.ihe.net IHE HIE Whitepaper, §2.8 Document Sharing Models : "the centralized model requires knowledge only of the centralized locator […]. For Push and Federated approaches a detailed directory of participating entitles [sic] is typically used". §3.2 Centralized Discovery and Retrieve : "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".  ↩
web profiles.ihe.net 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 . […] the service hosting the Binary shall: […] provide access to the community members ".  ↩   ↩2
web profiles.ihe.net MHDS Vol. 1, §1:50.2.2 Consent Manager Option : "Note that this option does not protect Binary content stored outside of the Document Registry […]. When documents are stored outside of the Document Registry, the Document Source system takes on the burden of protecting the document ."  ↩
web www.e-health-suisse.ch eHealth Suisse, EPR architecture. A detailed description, §3.3.4 XDS Document Repositories : "The Document Repository Service implements interfaces to store and query the binary objects of the XDS documents. The data are captured by the connected systems of the (core) communities when documents are saved and are registered via interfaces."  ↩
web profiles.ihe.net PDQm, §2:3.119.4.1.3 Expected Actions : "The results are ordered from most likely to least likely." §2:3.119.4.2.2.4 Quality of Match : " The Patient Demographics Supplier SHALL convey the quality of each match based on strength of the particular result to the supplied Patient Resource. […] it SHALL represent the confidence of a particular match within the bundle as a score attribute."  ↩
web profiles.ihe.net PDQm, §2:3.119.4.1.3 Expected Actions : "The results are ordered from most likely to least likely." §2:3.119.4.2.2.4 Quality of Match : " The Patient Demographics Supplier SHALL convey the quality of each match based on strength of the particular result to the supplied Patient Resource. […] it SHALL represent the confidence of a particular match within the bundle as a score attribute."  ↩
web profiles.ihe.net MHD, §2:3.65.4.1.2.3 Replace, Transform, Signs, and Append Associations : "The relatesTo.target element in the provided DocumentReference points at the pre-existing DocumentReference that is being replaced, transformed, signed, or appended. […] If a DocumentReference is being replaced, that DocumentReference needs to have the status element updated to superseded within the transaction bundle with the UpdateDocumentsRef slice".  ↩
web profiles.ihe.net MHD, §2:3.65.4.1.2 Message Semantics : "The Document Source shall initiate a FHIR “transaction” using a “create” action by sending an HTTP POST request method composed of a FHIR Bundle Resource containing: one SubmissionSet type List Resource; one or more DocumentReference Resources; zero or more Folder type List Resources; and zero or more Binary Resources to the Document Recipient."  ↩
web profiles.ihe.net mCSD, §1:46.8.2 Endpoint Content : "The Endpoint.connectionType and specificType extension indicate the type of connectivity enabled by the Endpoint. As such, Organization and OrganizationAffiliation Resources MAY have many Endpoints for the various types of connectivity they support."  ↩
web profiles.ihe.net MHDS Vol. 1, §1:50.2.2 Consent Manager Option : "The grouped IUA Authorization Server SHALL support consent configuration to enable Implied Consent and Explicit Consent environments. Implied Consent environments allow disclosure when no Consent has been recorded for that patient , Explicit Consent environments Deny disclosure when no Consent has been recorded for that patient."  ↩
web profiles.ihe.net PCF Vol. 1, §1:53.4 PCF Overview : "The PCF Profile enables authorized access to data according to terms agreed by the Patient and the Organization protecting the data." §1:53.1.1.3 Consent Authorization Server : "The Consent Authorization Server makes authorization decisions based on a given access requested context (e.g., oAuth, query/operation parameters), organizational policies, and current active Consent resources ."  ↩
web profiles.ihe.net PCF Vol. 1, §1:53.4 PCF Overview : "The PCF Profile enables authorized access to data according to terms agreed by the Patient and the Organization protecting the data." §1:53.1.1.3 Consent Authorization Server : "The Consent Authorization Server makes authorization decisions based on a given access requested context (e.g., oAuth, query/operation parameters), organizational policies, and current active Consent resources ."  ↩
web profiles.ihe.net ITI TF-1, §9.1.1.1 Secure Node : "Detect and report a Record Audit Event as specified in ITI TF-2: 3.20 for: all of the activity-related events for the Secure Node […] all transaction-related events for the Secure Node ".  ↩
web profiles.ihe.net MHDS Vol. 1, §1:50.1.1.1 Document Registry : "The Document Registry SHALL record all security relevant events to ATNA Audit Record Repository with the “ATX: FHIR Feed” Option."  ↩
web profiles.ihe.net BALP, §3:5.7.3.1 X-Request-Id header : "Where it is known that an http RESTful transaction included an X-Request-Id, that value should be recorded in an .entity dedicated to X-Request-Id. This ID can be used to correlated AuditEvents from client and server , and may aid with correlation on further activities recorded caused by the transaction."  ↩
web e-estonia.com e-Estonia, e-Health Record : "the e-Health Record actually retrieves data as necessary from various providers , who may be using different systems" and "presents it in a standard format".  ↩
web e-estonia.com e-Estonia, X-Road : "X-Road®, an open-source software and ecosystem solution that provides unified and secure data exchange between private and public sector organisations, is the backbone of e-Estonia . Invisible yet crucial, it allows the nation’s various public and private sector e-service information systems to link up and function in harmony."  ↩
web profiles.ihe.net MHD, §1:33.2.2 XDS on FHIR Option : " The Document Responder that supports this option shall be able to be grouped with an XDS Document Consumer so that any query or retrieve requests can be passed on to, and responded to, by an XDS environment." §1:33.2.3 UnContained Reference Option : "The UnContained Reference Option is not compatible with the XDS on FHIR Option. A system may be able to support both options, but only one will be able to be used at a given deployment ."  ↩
web profiles.ihe.net MHD, §1:33.2.2 XDS on FHIR Option : " The Document Responder that supports this option shall be able to be grouped with an XDS Document Consumer so that any query or retrieve requests can be passed on to, and responded to, by an XDS environment." §1:33.2.3 UnContained Reference Option : "The UnContained Reference Option is not compatible with the XDS on FHIR Option. A system may be able to support both options, but only one will be able to be used at a given deployment ."  ↩
web profiles.ihe.net MHDS Vol. 1, §1:50.5 MHDS Security Considerations : " The policy landscape that the community is built on needs to be defined well before the community is built. " §1:50.5.1 Policies and Risk Management : "IHE solves interoperability problems via the implementation of technology standards. It does not define Privacy or Security Policies , Risk Management, Healthcare Application Functionality, Operating System Functionality, Physical Controls, or even general Network Controls."  ↩
web profiles.ihe.net MHDS Vol. 1, §1:50.5 MHDS Security Considerations : " The policy landscape that the community is built on needs to be defined well before the community is built. " §1:50.5.1 Policies and Risk Management : "IHE solves interoperability problems via the implementation of technology standards. It does not define Privacy or Security Policies , Risk Management, Healthcare Application Functionality, Operating System Functionality, Physical Controls, or even general Network Controls."  ↩
web profiles.ihe.net MHDS, pie de la publicación vigente : "Package ihe.iti.mhds#2.3.1 based on FHIR 4.0.1. Generated 2023-08-04"  ↩
web profiles.ihe.net mCSD, Significant Changes : " Reworked all Actors to improve clarity ", con la tabla de equivalencias "New Actor (with Option)
web profiles.ihe.net MHDS Vol. 1, §1:50.2.1 Authorization Option : " The Document Registry SHALL be grouped with an IUA Resource Server and the IUA Authorization Server Actors. The IUA Authorization Server Metadata Option shall be supported."  ↩
web profiles.ihe.net MHDS Vol. 1, §1:50.2.2 Consent Manager Option : " The grouped IUA Authorization Server would be used to manage the consent status and make authorization decisions based on the consent status. […] The IUA Resource Server that is grouped with the MHDS Document Registry would enforce these decisions."  ↩
web profiles.ihe.net IUA, Relation to SMART-on-FHIR : " IUA promotes a loose coupling of Resource Server and Authorization Servers. This allows for deployments with multiple Resource Servers per Authorization Server as well as deployments with several or even no Authorization Servers."  ↩
web profiles.ihe.net MHDS Vol. 1, §1:50.1 MHDS Actors, Transactions, and Content Modules : " PMIR – Patient Identity Source and Patient Identity Registry – to provide patient identity lookup by demographics or identity, and to receive create and update of patient identity from participants "  ↩
web profiles.ihe.net 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 1 .
web profiles.ihe.net 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 1 .
web profiles.ihe.net 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 1 .
web profiles.ihe.net IUA exige a todo Resource Server declarar con qué opción comprueba el token ( IUA, Tabla 34.2-1 ) 2 . 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.
web profiles.ihe.net IUA exige a todo Resource Server declarar con qué opción comprueba el token ( IUA, Tabla 34.2-1 ) 2 . 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.
web profiles.ihe.net IUA exige a todo Resource Server declarar con qué opción comprueba el token ( IUA, Tabla 34.2-1 ) 2 . 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.
web profiles.ihe.net IUA exige a todo Resource Server declarar con qué opción comprueba el token ( IUA, Tabla 34.2-1 ) 2 . 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.
web profiles.ihe.net Pregunta al Authorization Server con ITI-102
web profiles.ihe.net 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 3 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 ) 4 . Los actores centrales envían sus eventos al Audit Record Repository de la comunidad. Cada miembro conserva los suyos en su propio repositorio.
web profiles.ihe.net 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 3 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 ) 4 . Los actores centrales envían sus eventos al Audit Record Repository de la comunidad. Cada miembro conserva los suyos en su propio repositorio.
web profiles.ihe.net 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 3 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 ) 4 . Los actores centrales envían sus eventos al Audit Record Repository de la comunidad. Cada miembro conserva los suyos en su propio repositorio.
web profiles.ihe.net 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 3 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 ) 4 . Los actores centrales envían sus eventos al Audit Record Repository de la comunidad. Cada miembro conserva los suyos en su propio repositorio.
web profiles.ihe.net 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.
web profiles.ihe.net 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 5 . 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 6 . 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.
web profiles.ihe.net 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.
web profiles.ihe.net 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.
web profiles.ihe.net 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.
web profiles.ihe.net 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.
web profiles.ihe.net 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 10 . 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 11 . 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.
web profiles.ihe.net 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.
web profiles.ihe.net 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.
web profiles.ihe.net IUA, Table 34.1-1 IUA Profile - Actors and Transactions : "Authorization Client | Get Access Token | R […] Incorporate Access Token | R […] Get Authorization Server Metadata | O […] Resource Server | Incorporate Access Token | R […] Introspect Token | O (Note 1) […] Get Authorization Server Metadata | O […] Note 1: Optionality of this transaction is "R" for an actor that supports the Token Introspection Option. "  ↩
web profiles.ihe.net IUA, Table 34.2-1 IUA - Actors and Options, Note 1 : " Authorization Server or Resource Server Actors shall support at least one of the following options: JWT Token, SAML, or Token Introspection. The Authorization Client is not and does not need to be aware of the token processing options."  ↩
web www.ihe.net RESTful ATNA (Query and Feed), Rev. 3.6, §9.2.7.1 ATX: FHIR Feed Option : "The ATX: FHIR Feed Option enables sending ATNA audit records using RESTful capabilities and FHIR resources . An Audit Record Repository that supports this option shall implement the two RESTful interactions defined in the Record Audit Event [ITI-20] transaction. A Secure Node, Secure Application or Audit Record Forwarder that supports this option shall at least support one of the two RESTful interactions defined in the Record Audit Event [ITI-20] transaction."  ↩
web profiles.ihe.net BALP, §1:52.1.1.1 Audit Creator : "The Audit Creator shall detect the defined auditable events and record a complaint AuditEvent as defined. The Audit Creator shall be grouped with an ATNA Secure Application or ATNA Secure Node with support for ATNA ATX:FHIR Feed Option defined in the RESTful ATNA Supplement for the recording of the compliant AuditEvent to the Audit Record Repository."  ↩
web profiles.ihe.net MHDS, §1:50.4.2.1 Use Case #1: Publication of a new document with persistence : " The MHD Comprehensive Metadata Option is required of the MHD Document Source as the MHD Document Recipient within the MHDS Document Registry will implement the Comprehensive Metadata Option."  ↩
web profiles.ihe.net MHD, §1:33.2.3 UnContained Reference Option : "When this longitudinal consistency is managed, then the author, authenticator, sourcePatientInfo, and author entries do not need to be a contained copy of the information known at the time of publication ITI-65 since a Reference to the information in these directories will be valid over the full lifecycle of the entries."  ↩
web profiles.ihe.net MHDS, Table 1:50.3-1 Required Actor Groupings : "Document Registry | Required | CT / Time Client […] Required | ATNA / Secure Node or Secure Application with the STX: TLS 1.2 with the BCP195 Option and the ATX: FHIR Feed Option […] Required | MHD / Document Responder […] Required | MHD / Document Recipient with the Comprehensive Metadata Option […] Required | PMIR / Patient Identity Consumer […] if the Authorization Option | IUA / Resource Server with the The IUA Authorization Server Metadata Option […] if the UnContained References Option | mCSD / Care Services Selective Consumer […] if the SVCM Validation Option | SVCM / Terminology Consumer".  ↩
web profiles.ihe.net MHDS Vol. 1, §1:50.1 MHDS Actors, Transactions, and Content Modules : " PMIR - Patient Identity Consumer provides patient identity synchronization and specifically the merge function to be applied to any data managed in the Document Registry."  ↩
web openid.net OpenID Connect Core 1.0, §1.2 Terminology : "OpenID Provider (OP): OAuth 2.0 Authorization Server that is capable of Authenticating the End-User and providing Claims to a Relying Party about the Authentication event and the End-User."  ↩
web profiles.ihe.net El custodio que declara esta opción SHALL enviar el contenido dentro del ITI-65 en lugar de una referencia, y SHALL NOT exponer un endpoint de recuperación. 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 SHALL atender la recuperación sin el salto hacia el custodio.
web profiles.ihe.net El custodio que declara esta opción SHALL enviar el contenido dentro del ITI-65 en lugar de una referencia, y SHALL NOT exponer un endpoint de recuperación. 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 SHALL atender la recuperación sin el salto hacia el custodio.
web profiles.ihe.net 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. 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.
web profiles.ihe.net El custodio que declara esta opción SHALL publicar en el directorio el endpoint que describe ese canal, y SHALL aceptar la transacción ITI-68 a través de él con el mismo contenido y los mismos requisitos de autorización. El token intercambiado sigue viajando en la solicitud y el custodio sigue validándolo. La identidad que el canal aporta SHALL NOT sustituir la validación del token.
web docs.x-road.global 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.
web profiles.ihe.net 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.
web profiles.ihe.net 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 .
web profiles.ihe.net El consumidor que declara esta opción SHALL presentar al menos un criterio demográfico en cada consulta ITI-78 . La infraestructura central SHALL responder sobre las identidades maestras, nunca sobre las identidades locales de los miembros, SHALL limitar la respuesta a los pacientes que la política de la comunidad permita revelar por esta vía y SHALL rechazar una consulta sin criterio. Es una búsqueda determinista. Cada criterio filtra, y ningún resultado lleva grado de coincidencia.
web profiles.ihe.net Permite a un consumidor encontrar a un paciente a partir de datos demográficos incompletos o inexactos, con la coincidencia probabilística del registro de identidad maestra. Corresponde a la Match Operation Option de PDQm .
web profiles.ihe.net El consumidor que declara esta opción SHALL presentar en cada ITI-119 los datos del paciente que busca. La infraestructura central SHALL responder sobre las identidades maestras, nunca sobre las identidades locales de los miembros, SHALL limitar la respuesta a los pacientes que la política de la comunidad permita revelar por esta vía, SHALL ordenar los resultados de más a menos probable y SHALL indicar el grado de coincidencia de cada uno, como fija PDQm ( PDQm, §2:3.119.4.2.2.4 ) 3 . Un resultado de esta búsqueda es un candidato, no una identidad confirmada.
web profiles.ihe.net El consumidor que declara esta opción SHALL presentar en cada ITI-119 los datos del paciente que busca. La infraestructura central SHALL responder sobre las identidades maestras, nunca sobre las identidades locales de los miembros, SHALL limitar la respuesta a los pacientes que la política de la comunidad permita revelar por esta vía, SHALL ordenar los resultados de más a menos probable y SHALL indicar el grado de coincidencia de cada uno, como fija PDQm ( PDQm, §2:3.119.4.2.2.4 ) 3 . Un resultado de esta búsqueda es un candidato, no una identidad confirmada.
web profiles.ihe.net 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 ."  ↩
web docs.x-road.global 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 ."  ↩
web profiles.ihe.net Esta sección describe el modelo de confianza de HIX, los controles que la arquitectura especifica y las decisiones que cada comunidad debe tomar por política. Sigue el orden de las consideraciones de seguridad de MHDS , es decir, políticas y gestión de riesgo, controles técnicos y aplicación al intercambio de documentos ( MHDS Vol. 1, §1:50.5 ) 1 . Como IHE, esta guía resuelve problemas de interoperabilidad mediante estándares. No define políticas de privacidad ni de seguridad, gestión de riesgo, funcionalidad clínica, controles físicos ni controles generales de red ( MHDS Vol. 1, §1:50.5.1 ) 2 . Lo que sigue separa lo que queda en manos de la comunidad de lo que fija la arquitectura.
web profiles.ihe.net Esta sección describe el modelo de confianza de HIX, los controles que la arquitectura especifica y las decisiones que cada comunidad debe tomar por política. Sigue el orden de las consideraciones de seguridad de MHDS , es decir, políticas y gestión de riesgo, controles técnicos y aplicación al intercambio de documentos ( MHDS Vol. 1, §1:50.5 ) 1 . Como IHE, esta guía resuelve problemas de interoperabilidad mediante estándares. No define políticas de privacidad ni de seguridad, gestión de riesgo, funcionalidad clínica, controles físicos ni controles generales de red ( MHDS Vol. 1, §1:50.5.1 ) 2 . Lo que sigue separa lo que queda en manos de la comunidad de lo que fija la arquitectura.
web www.rfc-editor.org En el destino, con las claves que publica el Authorization Server ( JWKs ), sin necesidad de introspección
web profiles.ihe.net El sujeto del token del solicitante es el sistema del miembro, porque el Authorization Server autentica a ese cliente y no a una persona, y en ese caso IUA pone como sujeto al cliente. La organización, el profesional y el propósito de uso van en las extensiones que IUA define para el token ( IUA, §3.71.4.2.2.1 ) 3 . Cuando el token lo obtiene una aplicación del paciente, el sujeto es la persona que la lanzó.
web www.rfc-editor.org Un token intercambiado vale ante un solo destino. El formato no lo impone. El claim aud de un JWT admite una lista de audiencias ( RFC 7519, §4.1.3 ) 4 , y el Authorization Server lo rellena con el recurso que el cliente indicó al pedir el token ( RFC 9068, §3 ) 5 . HIX lo restringe para el token intercambiado, porque de eso depende que un custodio no pueda reutilizarlo ante otro. El token del solicitante nombra a los actores centrales que el miembro alcanza directamente, que en este volumen es solo el Record Locator Service. Si la arquitectura cambiara y alcanzara otro, su token nombraría a ambos en aud sin que cambie nada más de este capítulo.
web www.rfc-editor.org Un token intercambiado vale ante un solo destino. El formato no lo impone. El claim aud de un JWT admite una lista de audiencias ( RFC 7519, §4.1.3 ) 4 , y el Authorization Server lo rellena con el recurso que el cliente indicó al pedir el token ( RFC 9068, §3 ) 5 . HIX lo restringe para el token intercambiado, porque de eso depende que un custodio no pueda reutilizarlo ante otro. El token del solicitante nombra a los actores centrales que el miembro alcanza directamente, que en este volumen es solo el Record Locator Service. Si la arquitectura cambiara y alcanzara otro, su token nombraría a ambos en aud sin que cambie nada más de este capítulo.
web www.rfc-editor.org El custodio recibe el token intercambiado y lo valida como RFC 9068 pide a todo Resource Server que recibe un token de acceso en forma de JWT ( RFC 9068, §4 ) 6 , más las comprobaciones que HIX añade sobre la delegación. El custodio SHALL comprobar, como mínimo, lo siguiente.
web www.rfc-editor.org Las tres comprobaciones que más pesan son la audiencia, el cliente y el actor. La audiencia sola no basta, porque un token emitido directamente a otro cliente para esa misma audiencia la pasaría. El cliente y el actor son lo que vuelve estructural que solo el Record Locator Service pueda alcanzar a un custodio en nombre de alguien, porque el claim act es la forma en que OAuth 2.0 Token Exchange declara que hubo delegación y quién actúa ( RFC 8693, §4.1 ) 7 .
web profiles.ihe.net El custodio SHALL validar el token intercambiado con las claves que publica el Authorization Server, y esa validación basta para aceptarlo. HIX no exige introspección en el custodio. El custodio MAY comprobarlo además por introspección, con la Token Introspection Option de IUA y ITI-102 , si la comunidad lo admite. Entonces cada recuperación depende del Authorization Server en el momento de atenderla, y esa dependencia se asume a sabiendas.
web profiles.ihe.net El custodio SHALL validar el token intercambiado con las claves que publica el Authorization Server, y esa validación basta para aceptarlo. HIX no exige introspección en el custodio. El custodio MAY comprobarlo además por introspección, con la Token Introspection Option de IUA y ITI-102 , si la comunidad lo admite. Entonces cada recuperación depende del Authorization Server en el momento de atenderla, y esa dependencia se asume a sabiendas.
web www.rfc-editor.org Deshabilitar un cliente en el Authorization Server SHALL revocar sus tokens vigentes, de modo que la siguiente introspección los declare inactivos, que es el estado que RFC 7662 prevé para un token revocado ( RFC 7662, §2.2 ) 8 , y ningún intercambio pueda partir de ellos. Un token ya intercambiado no tiene ciclo de vida propio. El Record Locator Service lo usa una sola vez, en la recuperación que lo motivó, y expira en dos minutos como máximo, así que una recuperación ya en curso termina.
web profiles.ihe.net El Record Locator Service SHALL registrar tanto la solicitud que recibe como cada recuperación que origina hacia un custodio, bajo un identificador de correlación que él mismo acuña y transmite al custodio, y SHALL NOT transmitir hacia el custodio ninguno que el solicitante proponga. Ningún registro de auditoría SHALL contener un token completo ni contenido clínico. Lo que ata un evento a su token es un identificador suyo, como el jti , que es la evidencia que BALP pide registrar en lugar del token ( BALP, §3:5.7.5 ) 9 .
web profiles.ihe.net La política de la comunidad determina qué solicitante alcanza qué documentos. MHDS lo plantea con una tabla de ejemplo que cruza el código de confidencialidad de cada documento con el rol del solicitante, y señala que ese rol y el propósito de uso llegan en el token de IUA ( MHDS Vol. 1, §1:50.5.3.2 ) 10 . La arquitectura ofrece el punto donde aplicarla y los datos con los que evaluarla, es decir, quién solicita, en nombre de qué organización, con qué propósito, sobre qué paciente y con qué etiqueta de confidencialidad. La Tabla 2.6-2 es la versión de HIX de ese ejemplo, con el propósito de uso en lugar del rol porque es lo que el token de HIX lleva siempre. Es un ejemplo, no un requisito.
web profiles.ihe.net MHDS pide reconocer los modos de emergencia desde el diseño, y advierte que anular una restricción del paciente por peligro inminente no es romper la política sino una condición explícita dentro de ella ( MHDS Vol. 1, §1:50.5.1 ) 12 . HIX distingue dos casos con los propósitos de uso de la Tabla 2.2-3 . Con ETREAT , un profesional autorizado atiende una urgencia y la política de la comunidad decide qué le permite frente a TREAT . Con BTG , accede quien no está autorizado para ese acceso, con anulación de la política, que es lo que HL7 define para ese código 13 .
web profiles.ihe.net MHDS cierra sus consideraciones de seguridad con la relación entre sus controles y los perfiles IHE que los aportan ( MHDS Vol. 1, §1:50.5.4 ). La Tabla 2.6-3 hace lo mismo para HIX.
web profiles.ihe.net MHDS Vol. 1, §1:50.5 MHDS Security Considerations : "It is especially important for the reader to understand that the scope of an IHE profile is only the technical details necessary to ensure interoperability . It is up to any organization building a community to understand and carefully implement the policies of that community and to perform the appropriate risk analysis. […] The policy landscape that the community is built on needs to be defined well before the community is built. "  ↩   ↩2
web profiles.ihe.net MHDS Vol. 1, §1:50.5.1 Policies and Risk Management : "IHE solves interoperability problems via the implementation of technology standards. It does not define Privacy or Security Policies , Risk Management, Healthcare Application Functionality, Operating System Functionality, Physical Controls, or even general Network Controls."  ↩
web profiles.ihe.net IUA, §3.71.4.2.2.1 JSON Web Token Option : "sub (required): If known, unique identifier of the user; the client_id otherwise [JWT, Section 4.1]. client_id (required): identifier of the client for which the token is issued." Y en §3.71.4.2.2.1.1 JWT IUA extension: "The Authorization Server and Resource Server shall support the following extensions to the JWT access token: subject_name (optional): The user's name as String. subject_organization_id (optional): Unique identifier of the user's organization. […] subject_role (optional): Coded values indicating the user's roles. […] purpose_of_use (optional): Purpose of use for the request. […] The above claims shall be wrapped in an "extensions" object with key 'ihe_iua'".  ↩
web www.rfc-editor.org RFC 7519, §4.1.3 "aud" (Audience) Claim : " In the general case, the "aud" value is an array of case-sensitive strings , each containing a StringOrURI value. In the special case when the JWT has one audience, the "aud" value MAY be a single case-sensitive string containing a StringOrURI value."  ↩
web www.rfc-editor.org RFC 9068, §3 Requesting a JWT Access Token : "If the request includes a "resource" parameter (as defined in [RFC8707]), the resulting JWT access token "aud" claim SHOULD have the same value as the "resource" parameter in the request. "  ↩
web www.rfc-editor.org RFC 9068, §4 Validating JWT Access Tokens : "Resource servers receiving a JWT access token MUST validate it in the following manner. The resource server MUST verify that the "typ" header value is "at+jwt" or "application/at+jwt" and reject tokens carrying any other value. […] The issuer identifier for the authorization server […] MUST exactly match the value of the "iss" claim. The resource server MUST validate that the "aud" claim contains a resource indicator value corresponding to an identifier the resource server expects for itself . […] The resource server MUST validate the signature of all incoming JWT access tokens according to [RFC7515] using the algorithm specified in the JWT "alg" Header Parameter. The resource server MUST reject any JWT in which the value of "alg" is "none". The resource server MUST use the keys provided by the authorization server. The current time MUST be before the time represented by the "exp" claim."  ↩
web www.rfc-editor.org RFC 8693, §4.1 "act" (Actor) Claim : "The act (actor) claim provides a means within a JWT to express that delegation has occurred and identify the acting party to whom authority has been delegated ."  ↩
web www.rfc-editor.org RFC 7662, §2.2 Introspection Response : "active. REQUIRED. Boolean indicator of whether or not the presented token is currently active. […] a "true" value return for the "active" property will generally indicate that a given token has been issued by this authorization server, has not been revoked by the resource owner , and is within its given time window of validity".  ↩
web profiles.ihe.net BALP, §3:5.7.5 OAuth Security Token : "There is still a need to include some evidence in the AuditEvent to tie this audit log entry with a specific token, but the whole token should not be recorded for security reasons ."  ↩
web profiles.ihe.net MHDS Vol. 1, §1:50.5.3.2 Protecting different types of documents : "This differentiation of the types of data can be represented using a diagram like found in Table 50.5.3.2-1: Sample Access Control Policies, showing an ‘X’ where the defined Role (rows) would have permitted access to data tagged with the given (columns) ConfidentialityCode (U-Unrestricted, L-Low, M-Moderate, N-Normal, R-Restricted, V-Very Restricted). […] These roles would be conveyed from the requesting organization through the use of the Internet User Authorization (IUA) Profile. […] Additional information can be carried such as the PurposeOfUse, what the user intends to use the data for. Note that Privacy Policies and Access Control rules can leverage any of the user context, patient identity, or document metadata discussed above."  ↩
web profiles.ihe.net MHDS Vol. 1, §1:50.5.1 Policies and Risk Management : "An important set of policies are those around emergency modes. […] When these use cases are factored in up-front, the mitigations are reasonable. […] Need to override a patient specified privacy block due to eminent danger to that patient – this override is not a breaking of the policy but would need to be an explicit condition within the policy. "  ↩
web profiles.ihe.net La fuente autoritativa de identidad alimenta la identidad maestra de la persona mediante ITI-93 .
web profiles.ihe.net El custodio declara su identidad local mediante ITI-104 ante la infraestructura central, en su propio dominio de identificadores y con el identificador nacional de la persona. La infraestructura central comprueba que el dominio corresponde a la organización del token, y el registro de identidad maestra vincula la identidad local con la maestra. Si la persona no existe en la comunidad, rechaza la declaración e indica el motivo.
web profiles.ihe.net Un consumidor resuelve su identificador a la identidad maestra mediante ITI-83 ante la infraestructura central y, si declara la Opción de Demografía, busca por datos demográficos mediante ITI-78 o, con la Opción de Coincidencia Demográfica, mediante ITI-119 .
web profiles.ihe.net Un consumidor resuelve su identificador a la identidad maestra mediante ITI-83 ante la infraestructura central y, si declara la Opción de Demografía, busca por datos demográficos mediante ITI-78 o, con la Opción de Coincidencia Demográfica, mediante ITI-119 .
web profiles.ihe.net Un consumidor resuelve su identificador a la identidad maestra mediante ITI-83 ante la infraestructura central y, si declara la Opción de Demografía, busca por datos demográficos mediante ITI-78 o, con la Opción de Coincidencia Demográfica, mediante ITI-119 .
web profiles.ihe.net El custodio publica los metadatos, agrupados en un SubmissionSet, mediante ITI-65 ante la infraestructura central. Bajo la Opción de Almacenamiento Central, incluye el contenido.
web profiles.ihe.net La infraestructura central resuelve a la identidad maestra, mediante ITI-83 , la identidad local con la que el custodio nombró al paciente, y la escribe como sujeto del puntero, que conserva también la identidad local. El Document Registry lo registra a nombre del custodio y responde. Si el paciente no resuelve a una identidad maestra, la publicación se rechaza.
web profiles.ihe.net El consumidor obtiene del Authorization Server un token destinado al Record Locator Service y localiza mediante ITI-67 . En una urgencia sin identificador conocido, busca antes a la persona por datos demográficos mediante ITI-78 o ITI-119 ante la infraestructura central.
web profiles.ihe.net El Record Locator Service comprueba el token mediante ITI-102 , resuelve la identidad maestra mediante ITI-83, consulta el Document Registry mediante ITI-67, evalúa la decisión de divulgación sobre cada puntero y devuelve los divulgados, con URL de contenido que apuntan a sí mismo.
web profiles.ihe.net El consumidor recupera mediante ITI-68 sobre una de esas URL.
web profiles.ihe.net El Record Locator Service relee el puntero, vuelve a evaluar la divulgación, resuelve el endpoint del custodio en el directorio mediante ITI-90 y obtiene mediante HIX-1 un token para ese custodio.
web profiles.ihe.net 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 precisión. 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.
web x-road.global 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.
web profiles.ihe.net 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)".  ↩
web profiles.ihe.net 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)".  ↩

Internal Images

central-architecture-diagram.svg
central-architecture-diagram.svg
hix-actores-hospital.svg
hix-actores-hospital.svg
hix-actores-laboratorio.svg
hix-actores-laboratorio.svg
hix-actores-paciente.svg
hix-actores-paciente.svg
hix-delegacion.svg
hix-delegacion.svg
hix-flujo-identidad.svg
hix-flujo-identidad.svg
hix-flujo-localizacion.svg
hix-flujo-localizacion.svg
hix-flujo-paciente.svg
hix-flujo-paciente.svg
hix-flujo-publicacion.svg
hix-flujo-publicacion.svg
hix-master-patient-index.svg
hix-master-patient-index.svg