IP Review

This fragment is not visible to the reader

This publication includes IP covered under the following statements.

ISO maintains the copyright on the country codes, and controls its use carefully. For further details see the ISO 3166 web page: https://www.iso.org/iso-3166-country-codes.html
- ISO 3166-1 Codes for the representation of names of countries and their subdivisions — Part 1: Country code : HixHealthInformationExchange

hl7.fhir.us.hai: Healthcare Associated Infection Implementation Guide ®© HL7 | CC0 ( src )

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

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." ↩ ( src )

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	guides.ohie.org	Master Patient Index (MPI). Conserva una identidad maestra por persona y sus enlaces con las identidades locales. Agrupa al Patient Identity Registry de PMIR , al Patient Identifier Cross-reference Manager de PIXm y al Patient Demographics Supplier de PDQm . Es el componente que OpenHIE llama Client Registry .
web	profiles.ihe.net	Audit Record Repository .
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-10-10 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	ATNA
web	profiles.ihe.net	CT
web	www.rfc-editor.org	Perfil IHE utilizado por HIX como base de autorización para las interacciones protegidas entre sus participantes. HIX-1 se apoya además en RFC 8693 y RFC 8707 .
web	www.rfc-editor.org	Perfil IHE utilizado por HIX como base de autorización para las interacciones protegidas entre sus participantes. HIX-1 se apoya además en RFC 8693 y RFC 8707 .
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. Las reglas de estos dos párrafos 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 ) ² . 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	Todo actor central que recibe directamente el token de un solicitante SHOULD comprobarlo mediante ITI-102 en cada operación, y MAY validarlo por sí mismo con las claves del Authorization Server si el token es un JWT. Quien lo valida así no ve una revocación hasta que el token expira. El Record Locator Service no tiene esa opción, porque su apartado le exige la introspección. Quien introspecciona SHOULD NOT reutilizar el resultado en operaciones posteriores, porque un resultado cacheado sigue aceptando un token ya revocado. Quien introspecciona y no obtiene respuesta del Authorization Server SHALL rechazar la solicitud con el status code 503, porque no tiene cómo comprobar el token.
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	Cuando el Record Locator Service y un actor central forman un mismo sistema, como admite MHDS para toda la infraestructura central ( MHDS Vol. 1, §1:50.6.2.4 ) ³ , la llamada entre ellos es interna y no requiere intercambio.
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 ) ⁴ . En HIX media además la recuperación, y se implementa agrupando un Document Consumer y un Document Responder de MHD .
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 ) ² . El token de un miembro nombra a los Resource Servers centrales que define la comunidad, y el token mediado a los destinos que el Authorization Server asocia a su `resource` , 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 mediado SHALL llevar como audiencia los Resource Servers que el Authorization Server asocia al `resource` de la petición de intercambio, que son solo el custodio cuando el `resource` nombra a uno, y SHALL llevar 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 ) ⁸ .
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 detecta y registra los eventos de su propio lado, como ATNA exige a todo Secure Node o Secure Application ( ITI TF-1, §9.1.1.1 ) ¹¹ , con la agrupación que fija la sección 2.4 .
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 detecta y registra los eventos de su propio lado, como ATNA exige a todo Secure Node o Secure Application ( ITI TF-1, §9.1.1.1 ) ¹¹ , con la agrupación que fija la sección 2.4 .
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 ." ↩ ↩²
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 ." ↩ ↩²
web	profiles.ihe.net	MHDS Vol. 1, §1:50.6.2.4 Central Infrastructure as a single system : "This is a system that contains all of the Central Infrastructure defined in MHDS as supporting services. These actors do not need to be combined into one system." ↩
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	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	ITI TF-1, §9.1.1.1 Secure Node : "The Secure Node shall: […] 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.". La Secure Application tiene el mismo requisito en §9.1.1.2. ↩
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 tres modelos de intercambio en su whitepaper sobre intercambio de información de salud, entre ellos el centralizado y el federado ( HIE Whitepaper, §2.8 ) ¹ . HIX elige la centralizada y absorbe esa complejidad una sola vez, en el centro, donde se puede operar, verificar y auditar.
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 ) ² , y reconoce que en ese caso su opción de consentimiento no protege el contenido y que cada Document Source carga solo con la protección de sus documentos ( MHDS Vol. 1, §1:50.2.2 ) ³ . Con custodia distribuida, eso obligaría a cada custodio a evaluar la política de la comunidad frente a cada consumidor. La mediación cierra ese hueco. La política se aplica en un solo lugar, con una única superficie auditable y un único contrato de integración.
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 ) ² , y reconoce que en ese caso su opción de consentimiento no protege el contenido y que cada Document Source carga solo con la protección de sus documentos ( MHDS Vol. 1, §1:50.2.2 ) ³ . Con custodia distribuida, eso obligaría a cada custodio a evaluar la política de la comunidad frente a cada consumidor. La mediación cierra ese hueco. La política se aplica en un solo lugar, con una única superficie auditable y un único contrato de integración.
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 ) ² . 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 ) ⁴ . 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 ) ⁴ . 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	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 los actores centrales que atienden sus transacciones, y solo con ellos. Ese token no sirve ante ningún custodio, y el miembro nunca recibe uno que sirva. El mediador comprueba cada token que recibe preguntando al Authorization Server si sigue siendo válido. Esa consulta es la introspección de RFC 7662 , que IUA recoge como la transacción Introspect Token ( ITI-102 ).
web	profiles.ihe.net	Un miembro obtiene un token para hablar con los actores centrales que atienden sus transacciones, y solo con ellos. Ese token no sirve ante ningún custodio, y el miembro nunca recibe uno que sirva. El mediador comprueba cada token que recibe preguntando al Authorization Server si sigue siendo válido. Esa consulta es la introspección de RFC 7662 , que IUA recoge como la transacción Introspect Token ( ITI-102 ).
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 ese solo custodio y un solo tipo de transacción, dura como mucho dos minutos y dice dentro quién pidió y quién actúa en su nombre. La Tabla 2.6-1 detalla lo que lleva.
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 ese solo custodio y un solo tipo de transacción, dura como mucho dos minutos y dice dentro quién pidió y quién actúa en su nombre. La Tabla 2.6-1 detalla lo que lleva.
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 ) ¹⁰ . El destino es PCF , donde las directivas de consentimiento de cada paciente se evalúan en cada petición ( PCF Vol. 1, §1:53.4 ) ¹¹ . La Opción de Consentimiento declara dónde se aplica esa decisión y qué información necesita. El modelo de consentimiento se especificará en una versión posterior de esta guía a partir de PCF.
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 ) ¹⁰ . El destino es PCF , donde las directivas de consentimiento de cada paciente se evalúan en cada petición ( PCF Vol. 1, §1:53.4 ) ¹¹ . La Opción de Consentimiento declara dónde se aplica esa decisión y qué información necesita. El modelo de consentimiento se especificará en una versión posterior de esta guía a partir de PCF.
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 y §9.1.1.2 ) ¹² y lo que MHDS exige a su Document Registry ( MHDS Vol. 1, §1:50.1.1.1 ) ¹³ . Los registros siguen los patrones de BALP , que definen cómo se escribe un `AuditEvent` de FHIR para cada tipo de evento. La infraestructura central registra la solicitud que recibe del miembro y la recuperación que ella misma inicia hacia el custodio. El custodio registra la entrega.
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 y §9.1.1.2 ) ¹² y lo que MHDS exige a su Document Registry ( MHDS Vol. 1, §1:50.1.1.1 ) ¹³ . Los registros siguen los patrones de BALP , que definen cómo se escribe un `AuditEvent` de FHIR para cada tipo de evento. La infraestructura central registra la solicitud que recibe del miembro y la recuperación que ella misma inicia hacia el custodio. El custodio registra la entrega.
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 y §9.1.1.2 ) ¹² y lo que MHDS exige a su Document Registry ( MHDS Vol. 1, §1:50.1.1.1 ) ¹³ . Los registros siguen los patrones de BALP , que definen cómo se escribe un `AuditEvent` de FHIR para cada tipo de evento. La infraestructura central registra la solicitud que recibe del miembro y la recuperación que ella misma inicia hacia el custodio. El custodio registra la entrega.
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 y §9.1.1.2 ) ¹² y lo que MHDS exige a su Document Registry ( MHDS Vol. 1, §1:50.1.1.1 ) ¹³ . Los registros siguen los patrones de BALP , que definen cómo se escribe un `AuditEvent` de FHIR para cada tipo de evento. La infraestructura central registra la solicitud que recibe del miembro y la recuperación que ella misma inicia hacia el custodio. El custodio registra la entrega.
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. Cuando el contenido queda en el custodio, el mediador resuelve la dirección en cada recuperación y llega al custodio por el canal que el directorio declara para él. Ese canal puede ser una conexión directa o una red de intercambio ya establecida, como X-Road . En ambos casos el puntero, la API que ven los miembros y el modelo de tokens son los mismos. Cambiar de canal es cambiar un dato del directorio.
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 entre cada miembro y la infraestructura central, nunca entre miembros. Si los miembros la usaran para hablar entre sí, volverían a la malla de pares que HIX descarta. Estonia sigue este mismo patrón. Su registro nacional de salud recupera los datos de cada proveedor cuando se necesitan y los presenta en un formato común ( e-Estonia ) ¹⁵ , y los sistemas de información del país se conectan entre sí sobre X-Road ( e-Estonia ) ¹⁶ . El token mediado sigue viajando por ese canal y el custodio sigue validándolo. La identidad que la red asigna a cada organización no lo sustituye.
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 entre cada miembro y la infraestructura central, nunca entre miembros. Si los miembros la usaran para hablar entre sí, volverían a la malla de pares que HIX descarta. Estonia sigue este mismo patrón. Su registro nacional de salud recupera los datos de cada proveedor cuando se necesitan y los presenta en un formato común ( e-Estonia ) ¹⁵ , y los sistemas de información del país se conectan entre sí sobre X-Road ( e-Estonia ) ¹⁶ . El token mediado sigue viajando por ese canal y el custodio sigue validándolo. La identidad que la red asigna a cada organización no lo sustituye.
web	profiles.ihe.net	Una comunidad HIX puede conectarse con otras comunidades mediante XCA . La pasarela, con sus Initiating Gateway y Responding Gateway, se agrupa en la infraestructura central junto al Record Locator Service, que la consulta al localizar y al recuperar, así que la mediación se conserva y ningún miembro habla con la otra comunidad. Esta guía no la especifica.
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 ) ¹⁷ . Por eso, de los compromisos de la tabla, el que más pesa es la apuesta por la operación del centro.
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 ) ¹⁷ . Por eso, de los compromisos de la tabla, el que más pesa es la apuesta por la operación del centro.
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 . Sigue los perfiles que MHDS compone, que son los que se mantienen, se prueban y se distribuyen como paquetes versionados. Como la mayoría solo se publica sobre FHIR R4, HIX sigue sus modelos, transacciones y vocabulario sobre FHIR R5 sin declarar conformidad con sus artefactos R4, mientras IHE no publique ediciones R5.
web	profiles.ihe.net	La segunda es que HIX no ejerce algunas de sus opciones. Bajo su Authorization Option, MHDS agrupa el Document Registry con el Authorization Server ( MHDS Vol. 1, §1:50.2.1 ) ²⁰ , y bajo su Consent Manager Option deja en este la gestión del consentimiento ( MHDS Vol. 1, §1:50.2.2 ) ²¹ . HIX quiere un único emisor para varios Resource Servers, el despliegue que IUA prevé al no atar el Authorization Server a los Resource Servers ( IUA, Relation to SMART-on-FHIR ) ²² .
web	profiles.ihe.net	La segunda es que HIX no ejerce algunas de sus opciones. Bajo su Authorization Option, MHDS agrupa el Document Registry con el Authorization Server ( MHDS Vol. 1, §1:50.2.1 ) ²⁰ , y bajo su Consent Manager Option deja en este la gestión del consentimiento ( MHDS Vol. 1, §1:50.2.2 ) ²¹ . HIX quiere un único emisor para varios Resource Servers, el despliegue que IUA prevé al no atar el Authorization Server a los Resource Servers ( IUA, Relation to SMART-on-FHIR ) ²² .
web	profiles.ihe.net	La segunda es que HIX no ejerce algunas de sus opciones. Bajo su Authorization Option, MHDS agrupa el Document Registry con el Authorization Server ( MHDS Vol. 1, §1:50.2.1 ) ²⁰ , y bajo su Consent Manager Option deja en este la gestión del consentimiento ( MHDS Vol. 1, §1:50.2.2 ) ²¹ . HIX quiere un único emisor para varios Resource Servers, el despliegue que IUA prevé al no atar el Authorization Server a los Resource Servers ( IUA, Relation to SMART-on-FHIR ) ²² .
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 ) ²³ . 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 : "IHE has enabled three distinct 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" y "Federated Discovery and Retrieve – in this model, a collection of peer entities are enabled to query each other to locate documents of interest […] the centralized model requires knowledge only of 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 ". ↩ ↩²
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	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 ". La Secure Application tiene el mismo requisito en §9.1.1.2 . ↩
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 ". La Secure Application tiene el mismo requisito en §9.1.1.2 . ↩
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	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	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	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 y el grant Client Credentials, salvo la aplicación del paciente, que lo obtiene con HIX-2 , y lo presenta en cada solicitud con ITI-72 . Todo actor ante el que un miembro presenta un token, directamente o a través del Record Locator Service, es un Resource Server de IUA , que recibe el token con ITI-72 y lo comprueba. Ambos pueden descubrir los endpoints del Authorization Server mediante ITI-103 ¹ .
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 y el grant Client Credentials, salvo la aplicación del paciente, que lo obtiene con HIX-2 , y lo presenta en cada solicitud con ITI-72 . Todo actor ante el que un miembro presenta un token, directamente o a través del Record Locator Service, es un Resource Server de IUA , que recibe el token con ITI-72 y lo comprueba. Ambos pueden descubrir los endpoints del Authorization Server mediante ITI-103 ¹ .
web	profiles.ihe.net	IUA exige a todo Resource Server declarar con qué opción comprueba el token ( IUA, Tabla 34.2-1 ) ² . Cada actor declara al menos una de la JWT Token Option o la Token Introspection Option , y puede declarar además la Authorization Server Metadata Option para descubrir los endpoints del Authorization Server. La Tabla 2.4-1 dice cuáles declara cada actor de HIX.
web	profiles.ihe.net	IUA exige a todo Resource Server declarar con qué opción comprueba el token ( IUA, Tabla 34.2-1 ) ² . Cada actor declara al menos una de la JWT Token Option o la Token Introspection Option , y puede declarar además la Authorization Server Metadata Option para descubrir los endpoints del Authorization Server. La Tabla 2.4-1 dice cuáles declara cada actor de HIX.
web	profiles.ihe.net	IUA exige a todo Resource Server declarar con qué opción comprueba el token ( IUA, Tabla 34.2-1 ) ² . Cada actor declara al menos una de la JWT Token Option o la Token Introspection Option , y puede declarar además la Authorization Server Metadata Option para descubrir los endpoints del Authorization Server. La Tabla 2.4-1 dice cuáles declara cada actor de HIX.
web	profiles.ihe.net	IUA exige a todo Resource Server declarar con qué opción comprueba el token ( IUA, Tabla 34.2-1 ) ² . Cada actor declara al menos una de la JWT Token Option o la Token Introspection Option , y puede declarar además la Authorization Server Metadata Option para descubrir los endpoints del Authorization Server. La Tabla 2.4-1 dice cuáles declara cada actor de HIX.
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 ³ y con el contenido que cada perfil define a partir de los patrones de BALP . Esa opción pide a quien registra al menos una de las dos interacciones de ITI-20, y al Audit Record Repository las dos. Quien escribe esos registros es, en términos de BALP , un Audit Creator, que BALP agrupa precisamente con ese Secure Node o Secure Application ( BALP, §1:52.1.1.1 ) ⁴ . Los actores centrales envían sus eventos al Audit Record Repository de la comunidad. Cada miembro conserva los suyos en su propio registro de auditoría.
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 ³ y con el contenido que cada perfil define a partir de los patrones de BALP . Esa opción pide a quien registra al menos una de las dos interacciones de ITI-20, y al Audit Record Repository las dos. Quien escribe esos registros es, en términos de BALP , un Audit Creator, que BALP agrupa precisamente con ese Secure Node o Secure Application ( BALP, §1:52.1.1.1 ) ⁴ . Los actores centrales envían sus eventos al Audit Record Repository de la comunidad. Cada miembro conserva los suyos en su propio registro de auditoría.
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 ³ y con el contenido que cada perfil define a partir de los patrones de BALP . Esa opción pide a quien registra al menos una de las dos interacciones de ITI-20, y al Audit Record Repository las dos. Quien escribe esos registros es, en términos de BALP , un Audit Creator, que BALP agrupa precisamente con ese Secure Node o Secure Application ( BALP, §1:52.1.1.1 ) ⁴ . Los actores centrales envían sus eventos al Audit Record Repository de la comunidad. Cada miembro conserva los suyos en su propio registro de auditoría.
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 mediado 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 ⁵ . Declara también la UnContained Reference Option , porque el puntero no lleva copias contenidas. `subject` y `custodian` referencian lo que la comunidad conserva, y `sourcepatient` , que MHD deja opcional y sin forma fija bajo esa opción, es una referencia lógica por identificador ⁶ . No es un Document Responder de MHD , porque las localizaciones con ITI-66 e ITI-67 las responde el Document Registry, que guarda los punteros. Es el servicio que aloja el contenido fuera del Document Registry, como lo prevé MHDS ( MHDS Vol. 1, §1:50.1.1.2 ) ⁷ , y lo sirve con ITI-68 solo al Record Locator Service. Por eso es también un Resource Server de IUA , que valida localmente el token mediado. Es un Patient Identity Source de PIXm , que declara sus identidades locales con ITI-104. Y es un Authorization Client de IUA , que obtiene el token con el que publica y declara. Puede agrupar además un Patient Identifier Cross-reference Consumer de PIXm para comprobar por su cuenta el contexto de paciente, como admite la sección 2.6 . Bajo la Opción de Almacenamiento Central deja de alojar el contenido y de ser Resource Server, porque entrega el contenido al publicar y ya no responde recuperaciones.
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` ¹¹ . Lo es porque HIX-2 se apoya en SMART App Launch, y SMART entrega ese `id_token` junto con el access token cuando la aplicación pide el scope `openid` ¹² . Y agrupa un Patient Identifier Cross-reference Consumer de PIXm , con el que resuelve a la identidad maestra la identidad de la persona autenticada para fijar el contexto de paciente.
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 más actores que los comunes de lo que casi todos agrupan .
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	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	MHDS Vol. 1, §1:50.1.1.2 Storage of Binary : "This might be other centralized infrastructure, distributed infrastructure, or within the system implementing the Document Source . […] When this is used by the Community, the service hosting the Binary shall : persist the Binary for the lifecycle expected of the Community; provide access to the community members; use the security model agreed to by the community members ." ↩
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 Authorization Option \| IUA / Authorization 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." §1:50.1.1.1.3 When the grouped PMIR Patient Identity Consumer – is triggered : " No behavior is expected of the Document Registry on receipt of a feed containing create, delete, or update , although the Document Registry may consume and persist these to support the Document Registry requirements to validate Patient references as a recognized Patient within the Community." ↩
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." §1:50.1.1.1.3 When the grouped PMIR Patient Identity Consumer – is triggered : " No behavior is expected of the Document Registry on receipt of a feed containing create, delete, or update , although the Document Registry may consume and persist these to support the Document Registry requirements to validate Patient references as a recognized Patient within the Community." ↩
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	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	Esta opción corresponde a la primera de las dos ubicaciones del contenido que describe MHDS ( MHDS Vol. 1, §1:50.1.1.2 ) ¹ . Ambas coexisten en una misma comunidad, como explica la sección 2.1 . 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	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 ) ² . 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	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 ) ¹ , e intercala el modelo de confianza de HIX, que MHDS no necesita porque no tiene mediador. 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 ) ² . 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 ) ¹ , e intercala el modelo de confianza de HIX, que MHDS no necesita porque no tiene mediador. 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 ) ² . 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 y el propósito de uso van en las extensiones que IUA define para el token ( IUA, §3.71.4.2.2.1 ) ³ . 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 mediado nunca vale ante dos custodios. El formato no lo impone. El claim `aud` de un JWT admite una lista de audiencias ( RFC 7519, §4.1.3 ) ⁴ , y RFC 9068 recomienda rellenarlo con el recurso que el cliente indicó al pedir el token ( RFC 9068, §3 ) ⁵ . HIX lo restringe cuando el destino es un custodio, porque de eso depende que un custodio no pueda reutilizarlo ante otro. Ante actores centrales, un mismo `resource` puede corresponder a varios Resource Servers, igual que en el token del miembro. El token de un miembro, en cambio, nombra en `aud` a los Resource Servers centrales que define la comunidad, y nunca a un custodio, y el de la aplicación del paciente nombra solo al Record Locator Service.
web	www.rfc-editor.org	Un token mediado nunca vale ante dos custodios. El formato no lo impone. El claim `aud` de un JWT admite una lista de audiencias ( RFC 7519, §4.1.3 ) ⁴ , y RFC 9068 recomienda rellenarlo con el recurso que el cliente indicó al pedir el token ( RFC 9068, §3 ) ⁵ . HIX lo restringe cuando el destino es un custodio, porque de eso depende que un custodio no pueda reutilizarlo ante otro. Ante actores centrales, un mismo `resource` puede corresponder a varios Resource Servers, igual que en el token del miembro. El token de un miembro, en cambio, nombra en `aud` a los Resource Servers centrales que define la comunidad, y nunca a un custodio, y el de la aplicación del paciente nombra solo al Record Locator Service.
web	www.rfc-editor.org	El custodio recibe el token mediado y lo valida como RFC 9068 pide a todo Resource Server que recibe un access token en forma de JWT ( RFC 9068, §4 ) ⁶ . Eso cubre la firma con las claves que publica el Authorization Server, el rechazo de un `alg` con valor `none` , que el emisor sea exactamente el Authorization Server de la comunidad, que el tipo de token sea `at+jwt` , que la audiencia lo contenga y que el token no haya expirado. HIX añade las comprobaciones siguientes, que el custodio SHALL hacer además.
web	www.rfc-editor.org	Las comprobaciones que más pesan son la audiencia y el cliente. La audiencia sola no basta, porque un token emitido directamente a otro cliente para esa misma audiencia la pasaría. El cliente es lo que vuelve estructural que solo el Record Locator Service pueda alcanzar a un custodio en nombre de alguien, porque el Authorization Server no emite por otro camino un token con esa audiencia. El claim `act` lo confirma, porque es la forma en que OAuth 2.0 Token Exchange declara que hubo delegación y quién actúa ( RFC 8693, §4.1 ) ⁷ .
web	profiles.ihe.net	El custodio SHALL validar el token mediado 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 mediado 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	El Authorization Server SHALL revocar los tokens vigentes de un cliente al deshabilitarlo, 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 ) ⁸ , y ningún intercambio pueda partir de ellos. Un token mediado ya emitido no tiene ciclo de vida propio. El Record Locator Service lo usa una sola vez, en la transacción que lo motivó, y expira en dos minutos como máximo, así que una transacción ya en curso termina.
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 ) ¹¹ . 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 ) ¹³ . 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 ¹⁴ .
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. " ↩ ↩²
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	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	El Record Locator Service comprueba el token mediante ITI-102 y consulta el Document Registry mediante ITI-67 con el identificador que recibió. El Document Registry lo resuelve a la identidad maestra mediante ITI-83. El Record Locator Service 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	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 ) ¹ . HIX lo aplica con una variante deliberada, que registra la Tabla 2.1-3 . También la recuperación pasa por ese localizador, de modo que la localización y la recuperación se median de forma centralizada, mientras la custodia de los documentos permanece distribuida entre los miembros que los producen.
web	profiles.ihe.net	MHDS
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)". ↩
web	profiles.ihe.net	La petición es la de IUA . HIX exige el parámetro `resource` que define RFC 8707 ( RFC 8707, §2 ) ¹ , para limitar dónde se puede usar un access token. En el token de un miembro, el `resource` nombra a la infraestructura central, así que el token vale solo ante sus Resource Servers y nunca ante un custodio ni ante otro Resource Server fuera de ella.
web	www.rfc-editor.org	La petición es la de IUA . HIX exige el parámetro `resource` que define RFC 8707 ( RFC 8707, §2 ) ¹ , para limitar dónde se puede usar un access token. En el token de un miembro, el `resource` nombra a la infraestructura central, así que el token vale solo ante sus Resource Servers y nunca ante un custodio ni ante otro Resource Server fuera de ella.
web	profiles.ihe.net	El Authorization Server pone en `aud` la lista de Resource Servers centrales que la comunidad define para ese `resource` , como prevé IUA , que limita esa lista a los Resource Servers esenciales para interactuar con el `resource` , normalmente solo el propio Resource Server ( IUA, §3.71.4.1.3 ) ² . En HIX el `resource` nombra a la infraestructura central, y los esenciales son los Resource Servers centrales que la atienden. Cuáles son depende del despliegue , y el miembro pide el token de la misma forma en todos los casos.
web	www.rfc-editor.org	El token puede ser opaco o un JWT, a elección de la implementación. Si es un JWT, sigue RFC 9068 , y un Resource Server central distinto del Record Locator Service puede validarlo por sí mismo con las claves del Authorization Server, como permite la sección 2.2 . Ese Resource Server no ve entonces una revocación hasta que el token expira. El Record Locator Service, que introspecciona siempre, la ve en la operación siguiente.
web	www.rfc-editor.org	Nota. RFC 9068 recomienda que el `aud` de un JWT tenga el mismo valor que el `resource` , pero no lo exige ( RFC 9068, §3 ) ³ . HIX sigue en esto a IUA , que prevé una lista de Resource Servers para un único `resource` . Lo que RFC 9068 sí exige es que la autorización del token no sea ambigua, y en HIX no lo es, porque cada scope es una transacción que atiende un único Resource Server.
web	profiles.ihe.net	La respuesta es la definida en IUA . El token de un miembro incluye siempre las extensiones de IUA `subject_organization_id` y `purpose_of_use` , con los valores que el Authorization Server obtiene de su registro, como establece la sección 2.2 . El token de una persona lleva `purpose_of_use` y el contexto de paciente, y `subject_organization_id` solo si la aplicación tiene una organización registrada, como fija HIX-2 , y el token de actor del Record Locator Service no lleva ninguna de las dos.
web	profiles.ihe.net	La respuesta es la definida en IUA . El token de un miembro incluye siempre las extensiones de IUA `subject_organization_id` y `purpose_of_use` , con los valores que el Authorization Server obtiene de su registro, como establece la sección 2.2 . El token de una persona lleva `purpose_of_use` y el contexto de paciente, y `subject_organization_id` solo si la aplicación tiene una organización registrada, como fija HIX-2 , y el token de actor del Record Locator Service no lleva ninguna de las dos.
web	www.rfc-editor.org	Además de las validaciones que define IUA , el Authorization Server SHALL rechazar la petición en los casos de la Tabla 3.1-1 . Responde con la respuesta de error de OAuth 2.0 y el código de error que indica la tabla, definido en RFC 8707 o en RFC 6749.
web	www.rfc-editor.org	Además de las validaciones que define IUA , el Authorization Server SHALL rechazar la petición en los casos de la Tabla 3.1-1 . Responde con la respuesta de error de OAuth 2.0 y el código de error que indica la tabla, definido en RFC 8707 o en RFC 6749.
web	profiles.ihe.net	La petición es la de IUA , y quien pregunta se identifica con las credenciales que acuerda con el Authorization Server ( IUA, §3.102.5 ) ⁴ .
web	profiles.ihe.net	La petición es la de IUA , y quien pregunta se identifica con las credenciales que acuerda con el Authorization Server ( IUA, §3.102.5 ) ⁴ .
web	profiles.ihe.net	Nota. IUA permite cachear el resultado de una introspección hasta el `exp` que trae ( IUA, §3.102.4.2.3 ) ⁵ . HIX lo desaconseja, porque un resultado `active=true` cacheado sigue aceptando un token que ya fue revocado. Por esta razón, la sección 2.2 fija que quien introspecciona SHOULD NOT reutilizar el resultado en operaciones posteriores.
web	profiles.ihe.net	La respuesta es la de IUA . Solo pueden introspeccionar los actores centrales y, si la comunidad lo admite, los custodios. A cualquier otro el Authorization Server le responde con el código HTTP 401, como prevé IUA para quien no tiene acceso al introspection endpoint ( IUA, §3.102.4.1.3 ) ⁶ .
web	profiles.ihe.net	La respuesta es la de IUA . Solo pueden introspeccionar los actores centrales y, si la comunidad lo admite, los custodios. A cualquier otro el Authorization Server le responde con el código HTTP 401, como prevé IUA para quien no tiene acceso al introspection endpoint ( IUA, §3.102.4.1.3 ) ⁶ .
web	profiles.ihe.net	De la respuesta, el Resource Server toma la organización, el propósito de uso y, si lo hay, el contexto de paciente, y comprueba `aud` y `scope` , como fijan las reglas 1 a 3 para las peticiones a un Resource Server . Si el token está inactivo o no cumple esas reglas, rechaza la petición con el código HTTP 401, como pide IUA ( IUA, §3.72.4.3 ) ⁷ , y con el OperationOutcome que exigen las respuestas de error FHIR . Si el Authorization Server no responde, rechaza la petición con el código HTTP 503, porque no tiene cómo comprobar el token, como fija la sección 2.2 .
web	www.rfc-editor.org	RFC 8707, §2 Resource Parameter : " resource Indicates the target service or resource to which access is being requested. Its value MUST be an absolute URI […] The parameter can carry the location of a protected resource, typically as an https URL or a more abstract identifier ." ↩
web	profiles.ihe.net	IUA, §3.71.4.1.3 Expected Actions : " The Authorization Client is recommended to provide a resource value to limit usability of the requested token to the intended Resource Server. […] If the Authorization Client presented a resource value in the token request, the Authorization Server shall limit the list of Resource Server identifiers in the audience claim to only those that are essential to interact with the specified resource (typically only the Resource Server itself)." ↩
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. […] The authorization server MUST NOT issue a JWT access token if the authorization granted by the token would be ambiguous. " ↩
web	profiles.ihe.net	IUA, §3.102.5 Security Considerations : "The Resource Server shall securely identify itself towards the Authorization Server by using credentials agreed between the Authorization Server and Resource Server. At minimum, the Authorization Server and Resource Server shall support the use of Bearer tokens for Resource Server authentication as defined in [OAuth2.1, Section 7.2]. To obtain a bearer token, the Resource Server may request such a token from the Authorization Server, reusing the client credential grant flow as described in the Get Access Token [ITI-71] transaction […]". ↩
web	profiles.ihe.net	IUA, §3.102.4.2.3 Expected Actions : " If the active field is set to "false", the Resource Server shall return HTTP 401 (Not Authorized) for all requests carrying the introspected access token. The Resource Server shall use the introspection results as access token claims in all access control evaluations […] The Resource Server may cache introspection results for a given access token in case the introspection result contains an expiry field. This cache shall not extend the period as defined by the expiry field. " ↩
web	profiles.ihe.net	IUA, §3.102.4.1.3 Expected Actions : "Upon receiving the introspect request, the Authorization Server shall evaluate the Resource Server's access to the introspect endpoint. If access is not allowed, the Authorization Server shall return HTTP 401 (Not Authorized). The Authorization Server shall: […] Validate the active state of the token (e.g., check expiry or revocation). Evaluate configured access policies, taking into account the authorization claims related to the token and the Resource Server identity. […] If the one of the above checks fails the Authorization Server shall return an introspection response with the "active" field set to "false" as described in RFC7662, Section 2.2." ↩
web	profiles.ihe.net	IUA, §3.72.4.3 Expected Actions : "If the token includes a scope claim, the Resource Server shall verify that the scope covers the transaction to the requested resource [OAuth 2.1, Section 7]. If the token includes an audience claim, the Resource Server shall verify that the audience includes the Resource Server itself [OAuth 2.1, Section 7]. […] If the token verification, or scope matching, or the access policy enforcement fails, the Resource Server shall respond with a HTTP 401 (Unauthorized) error. " ↩
web	profiles.ihe.net	Authorization Client
web	profiles.ihe.net	Authorization Server
web	www.rfc-editor.org	RFC 6749 , The OAuth 2.0 Authorization Framework, octubre de 2012. Aporta el token endpoint, la autenticación del cliente y la respuesta de error.
web	www.rfc-editor.org	RFC 8693 , OAuth 2.0 Token Exchange, enero de 2020. Aporta el grant de intercambio, sus parámetros y el claim `act` .
web	www.rfc-editor.org	RFC 8707 , Resource Indicators for OAuth 2.0, febrero de 2020. Aporta el parámetro `resource` y el error `invalid_target` .
web	www.rfc-editor.org	RFC 9068 , JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens, octubre de 2021. Aporta la forma del token mediado y su validación en el destino.
web	www.rfc-editor.org	RFC 7519 , JSON Web Token (JWT), mayo de 2015. Aporta los claims del token, entre ellos `aud` y `jti` .
web	profiles.ihe.net	IUA , Internet User Authorization, revisión 2.5, junio de 2026. Aporta ITI-71, con el que el Record Locator Service obtiene su token de actor, ITI-72, con el que presenta el token mediado, y las extensiones `ihe_iua` que el token mediado copia del token del solicitante.
web	profiles.ihe.net	Nota. HIX-1 se apoya en ITI-71. El Record Locator Service obtiene con ITI-71 su token de actor, y el intercambio usa el mismo token endpoint del Authorization Server con otro grant. IUA limita ITI-71 a los grants Authorization Code y Client Credentials, y de RFC 8693 solo toma el parámetro `requested_token_type` ( IUA, §3.71.4.1.2.1 ). Admite que sus actores soporten otros grants ( IUA, §34.4.1.1 ) ¹ , y HIX-1 especifica uno de ellos, el grant Token Exchange de RFC 8693 con un resource indicator de RFC 8707.
web	profiles.ihe.net	Nota. HIX-1 se apoya en ITI-71. El Record Locator Service obtiene con ITI-71 su token de actor, y el intercambio usa el mismo token endpoint del Authorization Server con otro grant. IUA limita ITI-71 a los grants Authorization Code y Client Credentials, y de RFC 8693 solo toma el parámetro `requested_token_type` ( IUA, §3.71.4.1.2.1 ). Admite que sus actores soporten otros grants ( IUA, §34.4.1.1 ) ¹ , y HIX-1 especifica uno de ellos, el grant Token Exchange de RFC 8693 con un resource indicator de RFC 8707.
web	profiles.ihe.net	Nota. HIX-1 se apoya en ITI-71. El Record Locator Service obtiene con ITI-71 su token de actor, y el intercambio usa el mismo token endpoint del Authorization Server con otro grant. IUA limita ITI-71 a los grants Authorization Code y Client Credentials, y de RFC 8693 solo toma el parámetro `requested_token_type` ( IUA, §3.71.4.1.2.1 ). Admite que sus actores soporten otros grants ( IUA, §34.4.1.1 ) ¹ , y HIX-1 especifica uno de ellos, el grant Token Exchange de RFC 8693 con un resource indicator de RFC 8707.
web	www.rfc-editor.org	La petición sigue RFC 8693: un POST al token endpoint del Authorization Server con los parámetros en el body, codificados como `application/x-www-form-urlencoded` ( RFC 8693, §2.1 ) ² .
web	www.rfc-editor.org	Nota. RFC 8693 define `actor_token` como opcional en una solicitud general de Token Exchange ( §2.1 ) ² . HIX-1 lo requiere porque usa semántica de delegación, en la que `subject_token` representa al solicitante y `actor_token` al Record Locator Service, que actúa en su nombre ( §1.1 ) ³ . Una petición que solo lleva `subject_token` no expresa delegación ( Apéndice A.1.1 ) ⁴ . Además, separa las dos identidades en juego. La autenticación del cliente prueba quién llama al token endpoint, y el `actor_token` aporta el actor de la delegación que queda en el token mediado.
web	www.rfc-editor.org	Nota. RFC 8693 define `actor_token` como opcional en una solicitud general de Token Exchange ( §2.1 ) ² . HIX-1 lo requiere porque usa semántica de delegación, en la que `subject_token` representa al solicitante y `actor_token` al Record Locator Service, que actúa en su nombre ( §1.1 ) ³ . Una petición que solo lleva `subject_token` no expresa delegación ( Apéndice A.1.1 ) ⁴ . Además, separa las dos identidades en juego. La autenticación del cliente prueba quién llama al token endpoint, y el `actor_token` aporta el actor de la delegación que queda en el token mediado.
web	www.rfc-editor.org	Nota. RFC 8693 define `actor_token` como opcional en una solicitud general de Token Exchange ( §2.1 ) ² . HIX-1 lo requiere porque usa semántica de delegación, en la que `subject_token` representa al solicitante y `actor_token` al Record Locator Service, que actúa en su nombre ( §1.1 ) ³ . Una petición que solo lleva `subject_token` no expresa delegación ( Apéndice A.1.1 ) ⁴ . Además, separa las dos identidades en juego. La autenticación del cliente prueba quién llama al token endpoint, y el `actor_token` aporta el actor de la delegación que queda en el token mediado.
web	www.rfc-editor.org	El Record Locator Service se autentica en el token endpoint como cliente confidencial, con el método que acuerde con el Authorization Server ( RFC 6749, §2.3 ).
web	www.rfc-editor.org	El `resource` sale del directorio porque el directorio es el único origen de los endpoints que usa la infraestructura central, como fija la sección 2.2 . El Authorization Server restringe la audiencia del token a los Resource Servers que asocia a ese `resource` , y a ese único custodio cuando nombra a uno, como recomienda RFC 8707 ( RFC 8707, §2 ). La petición no lleva `audience` . RFC 8693 lo trataría como otro destino, y el token emitido sería válido en todos los destinos indicados ( RFC 8693, §2.1 y §2.1.1 ) ⁵ .
web	www.rfc-editor.org	El `resource` sale del directorio porque el directorio es el único origen de los endpoints que usa la infraestructura central, como fija la sección 2.2 . El Authorization Server restringe la audiencia del token a los Resource Servers que asocia a ese `resource` , y a ese único custodio cuando nombra a uno, como recomienda RFC 8707 ( RFC 8707, §2 ). La petición no lleva `audience` . RFC 8693 lo trataría como otro destino, y el token emitido sería válido en todos los destinos indicados ( RFC 8693, §2.1 y §2.1.1 ) ⁵ .
web	www.rfc-editor.org	El `resource` sale del directorio porque el directorio es el único origen de los endpoints que usa la infraestructura central, como fija la sección 2.2 . El Authorization Server restringe la audiencia del token a los Resource Servers que asocia a ese `resource` , y a ese único custodio cuando nombra a uno, como recomienda RFC 8707 ( RFC 8707, §2 ). La petición no lleva `audience` . RFC 8693 lo trataría como otro destino, y el token emitido sería válido en todos los destinos indicados ( RFC 8693, §2.1 y §2.1.1 ) ⁵ .
web	www.rfc-editor.org	RFC 8693 distingue la delegación de la suplantación: en la delegación, quien actúa conserva su identidad y representa a otro. Aquí, `subject_token` representa al solicitante y `actor_token` al Record Locator Service ( RFC 8693, §1.1 ). El claim `act` del token mediado procede del `actor_token` e identifica al actor de la delegación ( RFC 8693, §4.1 ) ³ . El destino SHOULD comprobar ese claim, como recomienda la sección 2.6 .
web	www.rfc-editor.org	RFC 8693 distingue la delegación de la suplantación: en la delegación, quien actúa conserva su identidad y representa a otro. Aquí, `subject_token` representa al solicitante y `actor_token` al Record Locator Service ( RFC 8693, §1.1 ). El claim `act` del token mediado procede del `actor_token` e identifica al actor de la delegación ( RFC 8693, §4.1 ) ³ . El destino SHOULD comprobar ese claim, como recomienda la sección 2.6 .
web	www.rfc-editor.org	Además de validar cada token que recibe, como exige RFC 8693 ( RFC 8693, §2.1 ) ² , el Authorization Server SHALL comprobar lo siguiente.
web	www.rfc-editor.org	HIX expresa la delegación como la describe RFC 8693, con el `actor_token` en la petición y el claim `act` en el token resultante ( RFC 8693, §1.1 ) ³
web	www.rfc-editor.org	RFC 6749 lo exige cuando el cliente se autentica con el header `Authorization` , como en el ejemplo, y lo admite en los demás casos ( RFC 6749, §5.2 ) ⁶
web	www.rfc-editor.org	RFC 8693 prevé ese código para un `subject_token` o un `actor_token` que no es válido o que la política no acepta ( RFC 8693, §2.2.2 ) ⁶
web	www.rfc-editor.org	RFC 8707 prevé ese código para un destino que el Authorization Server no acepta ( RFC 8707, §2 ) ⁵
web	www.rfc-editor.org	El Authorization Server responde a un intercambio concedido con el código HTTP 200 y un body JSON con los parámetros de la respuesta de RFC 8693 ( RFC 8693, §2.2.1 ) ⁷ . La Tabla 3.2-4 fija sus valores en HIX.
web	profiles.ihe.net	IHE no define ningún evento de auditoría para un intercambio de tokens. IUA solo define un evento de auditoría para la emisión de tokens en ITI-71 ( IUA, §3.71.5.1 ) ⁸ , y HIX-1 no es ITI-71. La obtención del token de actor sí es un ITI-71, y se registra como indica la Tabla 3-2 .
web	www.rfc-editor.org	El Authorization Server SHALL registrar cada intercambio, concedido o rechazado. En ese registro SHALL enlazar, por su `jti` , el token del solicitante, el token de actor y, si lo emitió, el token mediado ( RFC 7519, §4.1.7 ) ⁹ . Si rechazó el intercambio, enlaza los tokens de la petición que pueda identificar. El registro no contiene ningún token completo, como dice la regla común de los registros de auditoría .
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]." §34.4.1.1 Authorization Grant Types : "This profile specifies the use of the Authorization Code and Client Credential grant types. Actors of this profile may support other grant types as well. " ↩
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]." §34.4.1.1 Authorization Grant Types : "This profile specifies the use of the Authorization Code and Client Credential grant types. Actors of this profile may support other grant types as well. " ↩
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]." §34.4.1.1 Authorization Grant Types : "This profile specifies the use of the Authorization Code and Client Credential grant types. Actors of this profile may support other grant types as well. " ↩
web	www.rfc-editor.org	RFC 8693, §2.1 Request : "The following parameters are included in the HTTP request entity-body using the "application/x-www-form-urlencoded" format […] grant_type REQUIRED. The value "urn:ietf:params:oauth:grant-type:token-exchange" indicates that a token exchange is being performed. […] Multiple "resource" parameters may be used to indicate that the issued token is intended to be used at the multiple resources listed. […] subject_token REQUIRED. A security token that represents the identity of the party on behalf of whom the request is being made. […] actor_token OPTIONAL. A security token that represents the identity of the acting party. […] In processing the request, the authorization server MUST perform the appropriate validation procedures for the indicated token type and, if the actor token is present, also perform the appropriate validation procedures for its indicated token type." §3 Token Type Identifiers : "urn:ietf:params:oauth:token-type:access_token Indicates that the token is an OAuth 2.0 access token issued by the given authorization server ." ↩ ↩² ↩³
web	www.rfc-editor.org	RFC 8693, §2.1 Request : "The following parameters are included in the HTTP request entity-body using the "application/x-www-form-urlencoded" format […] grant_type REQUIRED. The value "urn:ietf:params:oauth:grant-type:token-exchange" indicates that a token exchange is being performed. […] Multiple "resource" parameters may be used to indicate that the issued token is intended to be used at the multiple resources listed. […] subject_token REQUIRED. A security token that represents the identity of the party on behalf of whom the request is being made. […] actor_token OPTIONAL. A security token that represents the identity of the acting party. […] In processing the request, the authorization server MUST perform the appropriate validation procedures for the indicated token type and, if the actor token is present, also perform the appropriate validation procedures for its indicated token type." §3 Token Type Identifiers : "urn:ietf:params:oauth:token-type:access_token Indicates that the token is an OAuth 2.0 access token issued by the given authorization server ." ↩ ↩² ↩³
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 . […] Typically, in the request, the "subject_token" represents the identity of the party on behalf of whom the token is being requested while the "actor_token" represents the identity of the party to whom the access rights of the issued token are being delegated . […] The "actor_token" request parameter, however, does provide a means for providing information about the desired actor, and the JWT "act" claim can provide a representation of a chain of delegation ." §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 . […] Typically, in the request, the "subject_token" represents the identity of the party on behalf of whom the token is being requested while the "actor_token" represents the identity of the party to whom the access rights of the issued token are being delegated . […] The "actor_token" request parameter, however, does provide a means for providing information about the desired actor, and the JWT "act" claim can provide a representation of a chain of delegation ." §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, Appendix A.1.1 Token Exchange Request : "In the following token exchange request, a client is requesting a token with impersonation semantics ( delegation is impossible with only a "subject_token" and no "actor_token" )." ↩
web	www.rfc-editor.org	RFC 8707, §2 Resource Parameter : "Its value MUST be an absolute URI […] invalid_target The requested resource is invalid, missing, unknown, or malformed. The authorization server SHOULD audience-restrict issued access tokens to the resource(s) indicated by the "resource" parameter. " RFC 8693, §2.1 Request : "The "audience" and "resource" parameters may be used together to indicate multiple target services with a mix of logical names and resource URIs." §2.1.1 Relationship between Resource, Audience, and Scope : "The semantics of such a request are that the client is asking for a token with the requested scope that is usable at all the requested target services . […] An authorization server can use the "invalid_target" error code, defined in Section 2.2.2, to inform a client that it requested access to too many target services simultaneously." ↩ ↩²
web	www.rfc-editor.org	RFC 8707, §2 Resource Parameter : "Its value MUST be an absolute URI […] invalid_target The requested resource is invalid, missing, unknown, or malformed. The authorization server SHOULD audience-restrict issued access tokens to the resource(s) indicated by the "resource" parameter. " RFC 8693, §2.1 Request : "The "audience" and "resource" parameters may be used together to indicate multiple target services with a mix of logical names and resource URIs." §2.1.1 Relationship between Resource, Audience, and Scope : "The semantics of such a request are that the client is asking for a token with the requested scope that is usable at all the requested target services . […] An authorization server can use the "invalid_target" error code, defined in Section 2.2.2, to inform a client that it requested access to too many target services simultaneously." ↩ ↩²
web	www.rfc-editor.org	RFC 8707, §2 Resource Parameter : "Its value MUST be an absolute URI […] invalid_target The requested resource is invalid, missing, unknown, or malformed. The authorization server SHOULD audience-restrict issued access tokens to the resource(s) indicated by the "resource" parameter. " RFC 8693, §2.1 Request : "The "audience" and "resource" parameters may be used together to indicate multiple target services with a mix of logical names and resource URIs." §2.1.1 Relationship between Resource, Audience, and Scope : "The semantics of such a request are that the client is asking for a token with the requested scope that is usable at all the requested target services . […] An authorization server can use the "invalid_target" error code, defined in Section 2.2.2, to inform a client that it requested access to too many target services simultaneously." ↩ ↩²
web	www.rfc-editor.org	RFC 8693, §2.2.2 Error Response : "If the request itself is not valid or if either the "subject_token" or "actor_token" are invalid for any reason, or are unacceptable based on policy, the authorization server MUST construct an error response, as specified in Section 5.2 of [RFC6749]. The value of the "error" parameter MUST be the "invalid_request" error code. If the authorization server is unwilling or unable to issue a token for any target service indicated by the "resource" or "audience" parameters, the "invalid_target" error code SHOULD be used in the error response. […] Other error codes may also be used, as appropriate. " RFC 6749, §5.2 Error Response : "The authorization server responds with an HTTP 400 (Bad Request) status code (unless specified otherwise) and includes the following parameters with the response: error REQUIRED. […] unauthorized_client The authenticated client is not authorized to use this authorization grant type. […] invalid_scope The requested scope is invalid, unknown, malformed, or exceeds the scope granted by the resource owner." Sobre invalid_client: "Client authentication failed […] The authorization server MAY return an HTTP 401 (Unauthorized) status code to indicate which HTTP authentication schemes are supported. If the client attempted to authenticate via the "Authorization" request header field, the authorization server MUST respond with an HTTP 401 (Unauthorized) status code and include the "WWW-Authenticate" response header field matching the authentication scheme used by the client." ↩ ↩²
web	www.rfc-editor.org	RFC 8693, §2.2.2 Error Response : "If the request itself is not valid or if either the "subject_token" or "actor_token" are invalid for any reason, or are unacceptable based on policy, the authorization server MUST construct an error response, as specified in Section 5.2 of [RFC6749]. The value of the "error" parameter MUST be the "invalid_request" error code. If the authorization server is unwilling or unable to issue a token for any target service indicated by the "resource" or "audience" parameters, the "invalid_target" error code SHOULD be used in the error response. […] Other error codes may also be used, as appropriate. " RFC 6749, §5.2 Error Response : "The authorization server responds with an HTTP 400 (Bad Request) status code (unless specified otherwise) and includes the following parameters with the response: error REQUIRED. […] unauthorized_client The authenticated client is not authorized to use this authorization grant type. […] invalid_scope The requested scope is invalid, unknown, malformed, or exceeds the scope granted by the resource owner." Sobre invalid_client: "Client authentication failed […] The authorization server MAY return an HTTP 401 (Unauthorized) status code to indicate which HTTP authentication schemes are supported. If the client attempted to authenticate via the "Authorization" request header field, the authorization server MUST respond with an HTTP 401 (Unauthorized) status code and include the "WWW-Authenticate" response header field matching the authentication scheme used by the client." ↩ ↩²
web	www.rfc-editor.org	RFC 8693, §2.2.1 Successful Response : "scope OPTIONAL if the scope of the issued security token is identical to the scope requested by the client ; otherwise, it is REQUIRED. refresh_token OPTIONAL. A refresh token will typically not be issued when the exchange is of one temporary credential (the subject_token) for a different temporary credential (the issued token) for use in some other context. […] Profiles or deployments of this specification should clearly document the conditions under which a client should expect a refresh token […]" §3 Token Type Identifiers : "The intent of this specification is that "urn:ietf:params:oauth:token-type:access_token" be an indicator that the token is a typical OAuth access token issued by the authorization server in question, opaque to the client , and usable the same manner as any other access token obtained from that authorization server." ↩
web	www.rfc-editor.org	RFC 8693, §2.2.1 Successful Response : "scope OPTIONAL if the scope of the issued security token is identical to the scope requested by the client ; otherwise, it is REQUIRED. refresh_token OPTIONAL. A refresh token will typically not be issued when the exchange is of one temporary credential (the subject_token) for a different temporary credential (the issued token) for use in some other context. […] Profiles or deployments of this specification should clearly document the conditions under which a client should expect a refresh token […]" §3 Token Type Identifiers : "The intent of this specification is that "urn:ietf:params:oauth:token-type:access_token" be an indicator that the token is a typical OAuth access token issued by the authorization server in question, opaque to the client , and usable the same manner as any other access token obtained from that authorization server." ↩
web	profiles.ihe.net	IUA, §3.71.5.1 Security Audit Considerations : "The Authorization Client or Authorization Server that is grouped with an ATNA Secure Node or Secure Application shall be able to send an audit event as defined below […] EventID […] EV(110114, DCM, "User Authentication") […] EventTypeCode […] EV("ITI-71", IHE, "User Authorization") ". ↩
web	www.rfc-editor.org	RFC 7519, §4.1.7 "jti" (JWT ID) Claim : "The "jti" (JWT ID) claim provides a unique identifier for the JWT ." RFC 9068, §2.2 Data Structure : " jti REQUIRED - as defined in Section 4.1.7 of [RFC7519]." ↩
web	www.rfc-editor.org	RFC 7519, §4.1.7 "jti" (JWT ID) Claim : "The "jti" (JWT ID) claim provides a unique identifier for the JWT ." RFC 9068, §2.2 Data Structure : " jti REQUIRED - as defined in Section 4.1.7 of [RFC7519]." ↩
web	profiles.ihe.net	HIX-2 es ITI-71 con el grant Authorization Code y PKCE (Proof Key for Code Exchange), más la renovación del token con el grant de refresh token. IUA limita ITI-71 a los grants Authorization Code y Client Credential, y admite que sus actores soporten otros, como el de refresh token ( IUA, §34.4.1.1 ) ¹ . Para el contexto de paciente, HIX-2 adopta determinados elementos de SMART App Launch, que IUA procura no contradecir ( IUA, Relation to SMART-on-FHIR ) ² . Tiene identificador propio porque en ella el Authorization Server fija el contexto de paciente, algo que ITI-71 no prevé.
web	profiles.ihe.net	HIX-2 es ITI-71 con el grant Authorization Code y PKCE (Proof Key for Code Exchange), más la renovación del token con el grant de refresh token. IUA limita ITI-71 a los grants Authorization Code y Client Credential, y admite que sus actores soporten otros, como el de refresh token ( IUA, §34.4.1.1 ) ¹ . Para el contexto de paciente, HIX-2 adopta determinados elementos de SMART App Launch, que IUA procura no contradecir ( IUA, Relation to SMART-on-FHIR ) ² . Tiene identificador propio porque en ella el Authorization Server fija el contexto de paciente, algo que ITI-71 no prevé.
web	profiles.ihe.net	HIX-2 es ITI-71 con el grant Authorization Code y PKCE (Proof Key for Code Exchange), más la renovación del token con el grant de refresh token. IUA limita ITI-71 a los grants Authorization Code y Client Credential, y admite que sus actores soporten otros, como el de refresh token ( IUA, §34.4.1.1 ) ¹ . Para el contexto de paciente, HIX-2 adopta determinados elementos de SMART App Launch, que IUA procura no contradecir ( IUA, Relation to SMART-on-FHIR ) ² . Tiene identificador propio porque en ella el Authorization Server fija el contexto de paciente, algo que ITI-71 no prevé.
web	www.rfc-editor.org	Nota. SMART App Launch exige a sus servidores aceptar el parámetro `aud` y deja `resource` como sinónimo opcional ⁵ . RFC 8707 separa la intención de la restricción, porque el Authorization Server restringe la audiencia del token a partir del `resource` , la comunica en el claim `aud` y puede usar el mismo valor o derivar de él otro identificador ( RFC 8707, §2 ) ¹² . Por esta razón, HIX-2 se aparta en este punto de SMART App Launch.
web	profiles.ihe.net	El Authorization Server sigue publicando sus metadatos de IUA con ITI-103 , y los dos documentos describen los mismos endpoints.
web	profiles.ihe.net	Authorization Server y OpenID Provider
web	profiles.ihe.net	IUA , Internet User Authorization, revisión 2.5, junio de 2026. Aporta ITI-71 con el grant Authorization Code y su evento de auditoría.
web	openid.net	OpenID Connect Core 1.0 , con la fe de erratas 2, diciembre de 2023. Aporta la autenticación de la persona, el `id_token` y los scopes `openid` y `offline_access` .
web	www.rfc-editor.org	RFC 6749 , The OAuth 2.0 Authorization Framework, octubre de 2012. Aporta el grant de refresh token y las respuestas de error.
web	www.rfc-editor.org	RFC 7636 , Proof Key for Code Exchange by OAuth Public Clients, septiembre de 2015. Aporta `code_challenge` , `code_verifier` y el método `S256` .
web	www.rfc-editor.org	RFC 9700 , Best Current Practice for OAuth 2.0 Security, enero de 2025. Aporta la protección de los refresh tokens de los clientes públicos.
web	profiles.ihe.net	La petición es un GET al authorization endpoint, con los parámetros en la query, como define IUA para el grant Authorization Code ( IUA, §3.71.4.1.2.2 ) ⁴ . La Tabla 3.3-4 dice qué valor fija HIX en cada parámetro.
web	www.rfc-editor.org	Una de las URI de redirección registradas para la aplicación. El Authorization Server SHALL compararla por coincidencia exacta, como exige RFC 9700 ( RFC 9700, §2.1 ) ¹⁴
web	profiles.ihe.net	Obligatorio, como exige IUA ( IUA, §3.71.4.1.2.2 ) ¹⁵ . Un valor impredecible que la aplicación genera para cada petición
web	profiles.ihe.net	Ninguno de los scopes de SMART ni de OpenID Connect autoriza operaciones ante el Record Locator Service. Lo que autoriza son los identificadores de transacción, según la regla 2 para las peticiones a un Resource Server . La aplicación pide solo los que necesita, como IUA exige a todo Authorization Client ( IUA, §3.71.5 ) ¹⁶ . El Authorization Server SHALL NOT conceder a una aplicación del paciente identificadores de transacción distintos de `ITI-66` , `ITI-67` e `ITI-68` , porque la aplicación solo localiza y recupera los documentos de la persona.
web	profiles.ihe.net	El Authorization Server valida los parámetros, autentica a la persona y obtiene su autorización para la aplicación, como IUA exige antes de emitir el código ( IUA, §3.71.4.1.3.2 ) ¹⁷ . Cómo se verifica la identidad de la persona es política de la comunidad, según la sección 2.6 .
web	openid.net	Nota. OpenID Connect exige al OpenID Provider obtener siempre el consentimiento antes de emitir un refresh token para el acceso sin conexión, y advierte que un consentimiento guardado no siempre basta. Para asegurarlo, la petición lleva `prompt=consent` , salvo que otras condiciones del procesamiento permitan el acceso sin conexión ( OpenID Connect Core, §11 ) ¹⁸ . En HIX esa condición es que el Authorization Server pide el consentimiento en cada lanzamiento y nunca reutiliza uno guardado, que es lo mismo que obtendría `prompt=consent` . Por esta razón, HIX-2 no exige a la aplicación enviar `prompt=consent` .
web	www.rfc-editor.org	Si concede la autorización, el Authorization Server redirige el navegador a la `redirect_uri` con `code` y `state` ⁴ . Si la rechaza, redirige con `error` y el `state` de la petición ( RFC 6749, §4.1.2.1 ) ¹⁹ .
web	www.rfc-editor.org	La petición es un POST al token endpoint, con los parámetros en el body en formato `application/x-www-form-urlencoded` . El canje del código sigue IUA ⁴ y SMART App Launch ( SMART App Launch, Obtain access token ) ²¹ . La renovación sigue RFC 6749 ( RFC 6749, §6 ) ²² y SMART App Launch ¹⁰ . La Tabla 3.3-6 dice qué valor fija HIX en cada parámetro de los dos grants.
web	www.rfc-editor.org	SMART App Launch exige el `client_id` en el canje de una aplicación pública ²¹ . La aplicación pública SHALL enviarlo también al renovar, como admite RFC 6749 ( RFC 6749, §3.2.1 ) ²³ , para que el Authorization Server compruebe a qué aplicación emitió el refresh token.
web	www.rfc-editor.org	Con una aplicación pública, el Authorization Server SHALL emitir un refresh token nuevo en cada renovación e invalidar el anterior, o ligar el refresh token a esa instancia de la aplicación, como exige RFC 9700 para los clientes públicos ( RFC 9700, §4.14.2 ) ²⁴ . Si rota los refresh tokens y recibe uno ya invalidado, SHALL revocar el refresh token vigente de esa autorización. RFC 9700 describe esa revocación como la respuesta de la rotación a un refresh token reutilizado ²⁴ .
web	profiles.ihe.net	El Authorization Server responde a una petición concedida con el código HTTP 200, un body JSON y los headers `Cache-Control: no-store` y `Pragma: no-cache` que exige IUA ( IUA, §3.71.4.2.2 ) ²⁵ . La Tabla 3.3-7 dice qué valor fija HIX en cada parámetro. La respuesta a una renovación tiene la misma forma, salvo por el `id_token` . El Authorization Server SHALL incluir `patient` en toda respuesta concedida, también en la de una renovación.
web	www.rfc-editor.org	El Authorization Server SHALL incluir en el scope del access token solo identificadores de transacción. `openid` , `fhirUser` , `launch/patient` y `offline_access` los consume él al emitir el token y no aparecen en él. El `scope` de la respuesta describe el access token ( RFC 6749, §5.1 ) ²⁷ , y por eso lleva solo esos identificadores, según la regla 2 para las peticiones a un Resource Server . La aplicación sabe qué obtuvo de OpenID Connect y de SMART por los parámetros que recibe, es decir, `id_token` , `refresh_token` y `patient` .
web	www.rfc-editor.org	Si rechaza la petición, el Authorization Server responde con la respuesta de error de OAuth 2.0 y el código HTTP 400 ( RFC 6749, §5.2 ) ²⁸ . SHALL rechazarla en las condiciones de la Tabla 3.3-8 .
web	profiles.ihe.net	El Authorization Server registra cada lanzamiento y cada renovación, concedidos o rechazados, con el evento que IUA define para ITI-71 ( IUA, §3.71.5.1 ) ³⁰ , como indica la Tabla 3-2 . IUA no define un evento para la renovación, y HIX usa para ella el mismo.
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)." §34.4.1.1 Authorization Grant Types : "This profile specifies the use of the Authorization Code and Client Credential grant types. Actors of this profile may support other grant types as well. " ↩
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)." §34.4.1.1 Authorization Grant Types : "This profile specifies the use of the Authorization Code and Client Credential grant types. Actors of this profile may support other grant types as well. " ↩
web	profiles.ihe.net	IUA, Relation to SMART-on-FHIR : " IUA is not based on SMART-on-FHIR, but does strive to not conflict with that standard. " ↩
web	profiles.ihe.net	IUA, §3.71.4.1.2.2 Authorization Code grant type : " resource (optional): Single valued identifier of the Resource Server endpoint to be accessed […] code_challenge (required) […] redirect_uri (optional) […] This parameter is required if the Authorization Client is registered at the Authorization Server with multiple redirect URI, optional otherwise […] code_verifier: The original code verifier string. " ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
web	profiles.ihe.net	IUA, adición a MHD Vol. 2, §3.67.5.2 Use with the Internet User Authorization (IUA) Profile : " scope: ITI-67 This scope request authorizes the full [ITI-67] transaction. " ↩
web	www.rfc-editor.org	RFC 8707, §2 Resource Parameter : " resource Indicates the target service or resource to which access is being requested. […] invalid_target The requested resource is invalid, missing, unknown, or malformed. The authorization server SHOULD audience-restrict issued access tokens to the resource(s) indicated by the "resource" parameter. Audience restrictions can be communicated in JSON Web Tokens [RFC7519] with the "aud" claim […] The authorization server may use the exact "resource" value as the audience or it may map from that value to a more general URI or abstract identifier for the given resource. " ↩ ↩²
web	www.rfc-editor.org	RFC 9700, §2.1 Protecting Redirect-Based Flows : "When comparing client redirection URIs against pre-registered URIs, authorization servers MUST utilize exact string matching except for port numbers in localhost redirection URIs of native apps" ↩
web	profiles.ihe.net	IUA, §3.71.4.1.2.2 Authorization Code grant type : "state (required): An unguessable value used by the client to track the state between the authorization request and the callback to the redirect URI. While this parameter is optional in the OAuth 2.1 Authorization Framework […] it is required in this profile for security reasons ." ↩
web	profiles.ihe.net	IUA, §3.71.5 Security Considerations : "Access token should be short-lived with a lifetime of 1 hour or less. […] Refresh token may be long lived. […] To reduce the attack surface, client claims and authorization grants shall be the minimal; i.e., the authorization grant scope requested by the Authorization Client shall be the minimal required scope for the resource request to be used for." ↩ ↩²
web	profiles.ihe.net	IUA, §3.71.4.1.3.2 Authorization Code grant type : " The Authorization Server shall authenticate confidential and credential clients […] If valid, the Authorization Server shall authenticate the user and obtain the user consent […]" ↩ ↩² ↩³
web	openid.net	OpenID Connect Core 1.0, §11 Offline Access : " When offline access is requested, a prompt parameter value of consent MUST be used unless other conditions for processing the request permitting offline access to the requested resources are in place. The OP MUST always obtain consent to returning a Refresh Token that enables offline access to the requested resources. A previously saved user consent is not always sufficient to grant offline access." ↩
web	www.rfc-editor.org	RFC 6749, §4.1.2.1 Error Response : "If the request fails due to a missing, invalid, or mismatching redirection URI, or if the client identifier is missing or invalid, the authorization server SHOULD inform the resource owner of the error and MUST NOT automatically redirect the user-agent to the invalid redirection URI. […] temporarily_unavailable The authorization server is currently unable to handle the request due to a temporary overloading or maintenance of the server." ↩ ↩² ↩³
web	www.rfc-editor.org	RFC 7636, §4.4.1 Error Response : "If the server requires Proof Key for Code Exchange (PKCE) by OAuth public clients and the client does not send the "code_challenge" in the request, the authorization endpoint MUST return the authorization error response with the "error" value set to "invalid_request" . […] If the server supporting PKCE does not support the requested transformation, the authorization endpoint MUST return the authorization error response with "error" value set to "invalid_request" ." §4.6 Server Verifies code_verifier before Returning the Tokens : "If the values are not equal, an error response indicating "invalid_grant" as described in Section 5.2 of [RFC6749] MUST be returned." ↩ ↩²
web	www.rfc-editor.org	RFC 7636, §4.4.1 Error Response : "If the server requires Proof Key for Code Exchange (PKCE) by OAuth public clients and the client does not send the "code_challenge" in the request, the authorization endpoint MUST return the authorization error response with the "error" value set to "invalid_request" . […] If the server supporting PKCE does not support the requested transformation, the authorization endpoint MUST return the authorization error response with "error" value set to "invalid_request" ." §4.6 Server Verifies code_verifier before Returning the Tokens : "If the values are not equal, an error response indicating "invalid_grant" as described in Section 5.2 of [RFC6749] MUST be returned." ↩ ↩²
web	www.rfc-editor.org	RFC 6749, §6 Refreshing an Access Token : " The requested scope MUST NOT include any scope not originally granted by the resource owner, and if omitted is treated as equal to the scope originally granted by the resource owner. […] Because refresh tokens are typically long-lasting credentials used to request additional access tokens, the refresh token is bound to the client to which it was issued . […] The authorization server MAY issue a new refresh token, in which case the client MUST discard the old refresh token and replace it with the new refresh token ." ↩ ↩² ↩³ ↩⁴
web	www.rfc-editor.org	RFC 6749, §3.2.1 Client Authentication : " A client MAY use the "client_id" request parameter to identify itself when sending requests to the token endpoint. In the "authorization_code" "grant_type" request to the token endpoint, an unauthenticated client MUST send its "client_id" to prevent itself from inadvertently accepting a code intended for a client with a different "client_id"." ↩
web	www.rfc-editor.org	RFC 9700, §4.14.2 Recommendations : " Authorization servers MUST utilize one of these methods to detect refresh token replay by malicious actors for public clients […] The authorization server cannot determine which party submitted the invalid refresh token, but it will revoke the active refresh token. […] Authorization servers MAY revoke refresh tokens automatically in case of a security event […] Refresh tokens SHOULD expire if the client has been inactive for some time " ↩ ↩² ↩³
web	profiles.ihe.net	IUA, §3.71.4.2.2 Message Semantics : "scope (required): The scope granted by the Authorization Server. […] refresh_token (optional): A token provided by the Authorization Server which can be used by the Authorization Client to obtain new access tokens using the same authorization grant . […] The Authorization Server shall include the HTTP Cache-Control response header field with value no-store and the Pragma response header field value no-cache to the access token response […]" ↩
web	openid.net	OpenID Connect Core 1.0, §12.2 Successful Refresh Response : "Upon successful validation of the Refresh Token, the response body is the Token Response of Section 3.1.3.3 […] except that it might not contain an id_token . If an ID Token is returned as a result of a token refresh request, the following requirements apply: its iss Claim Value MUST be the same as in the ID Token issued when the original authentication occurred, its sub Claim Value MUST be the same as in the ID Token issued when the original authentication occurred […]" ↩
web	www.rfc-editor.org	RFC 6749, §5.1 Successful Response : "scope OPTIONAL, if identical to the scope requested by the client; otherwise, REQUIRED. The scope of the access token as described by Section 3.3." ↩
web	www.rfc-editor.org	RFC 6749, §5.2 Error Response : "The authorization server responds with an HTTP 400 (Bad Request) status code (unless specified otherwise) and includes the following parameters with the response: error REQUIRED. […] invalid_grant The provided authorization grant (e.g., authorization code, resource owner credentials) or refresh token is invalid, expired, revoked , does not match the redirection URI used in the authorization request, or was issued to another client. […] invalid_scope The requested scope is invalid, unknown, malformed, or exceeds the scope granted by the resource owner ." ↩
web	profiles.ihe.net	IUA, §3.71.5.1 Security Audit Considerations : "Source (1) Human Requestor (0) Destination (0) Audit Source (Client Authentication Agent) (1) Participant Object (1) […] Token […] ParticipantObjectTypeCode M "2" (System) […] ParticipantObjectTypeCodeRole M "13" (Security Resource)" ↩
web	profiles.ihe.net	Get Authorization Server Metadata [ITI-103]
web	profiles.ihe.net	Maintain Time [ITI-1]
web	profiles.ihe.net	Authenticate Node [ITI-19]
web	www.ihe.net	ITI-20 se usa bajo la opción ATX: FHIR Feed. Un evento suelto viaja con la interacción Send Audit Resource Request, que es un `create` de FHIR, y varios juntos con Send Audit Bundle Request, que es un `batch` ( RESTful ATNA, 3.20.4.2 y 3.20.4.2 y ) ¹ . HIX la usa sin parámetros ni condiciones de rechazo propios. Lo que HIX fija es el contenido de los eventos, con las reglas comunes del identificador de correlación y de los registros de auditoría .
web	profiles.ihe.net	Ninguno. IUA define su propio evento, User Authentication con el subtipo ITI-71 ( IUA, §3.71.5.1 ) ³
web	profiles.ihe.net	Ninguno propio. El Resource Server registra la identidad del token en el evento de la transacción que lo lleva ( IUA, §3.72.5.1 ) ³ , y en un AuditEvent la añade con uno de los patrones OAuth Security Token de BALP ( BALP, §3:5.7.5 ) ⁴
web	profiles.ihe.net	Ninguno propio. El Resource Server usa el resultado de la introspección como atributos del evento ( IUA, §3.102.5.1 ) ³
web	profiles.ihe.net	El evento de ITI-71 ( IUA, §3.71.5.1 ) ³ . Lo detalla Patient Application Launch [HIX-2]
web	profiles.ihe.net	ITI-103, ITI-1 e ITI-19 no tienen fila, porque su especificación no define un evento propio. Los eventos generales de seguridad, como un fallo de autenticación de un nodo, son los de la tabla de ITI-20 que todo Secure Node o Secure Application debe poder registrar ( ITI TF-2, §3.20.4.1.1.1 ) ¹¹ .
web	www.ihe.net	RESTful ATNA (Query and Feed), Rev. 3.6, §3.20.4.2 Send Audit Resource Request Message – FHIR Feed Interaction : "A Secure Node, Secure Application or Audit Record Forwarder, that supports the ATX: FHIR Feed Option, uses this message to post a single AuditEvent Resource to the Audit Record Repository using a FHIR create interaction […]". §3.20.4.4 Send Audit Bundle Request Message – FHIR Feed Interaction: "A Secure Node, Secure Application or Audit Record Forwarder that supports the ATX: FHIR Feed Option uses this message to post a Bundle of AuditEvent Resources to the Audit Record Repository using a FHIR batch interaction […]" ↩
web	profiles.ihe.net	IUA, §3.71.5.1 Security Audit Considerations : "The Authorization Client or Authorization Server that is grouped with an ATNA Secure Node or Secure Application shall be able to send an audit event as defined below […] EventID […] EV(110114, DCM, "User Authentication") […] EventTypeCode […] EV("ITI-71", IHE, "User Authorization") ". §3.72.5.1 Security Audit Considerations : "When an ATNA Audit message needs to be generated by the Resource Server and the user is authenticated by way of a JWT Token, the ATNA Audit message UserName element shall record the JWT Token information […]". §3.102.5.1 Security Audit Considerations : " Resource Servers shall use the introspection results as authorization claims when formulating audit messages , as specified in ITI TF-2 3.72.5.1." ↩ ↩² ↩³ ↩⁴
web	profiles.ihe.net	IUA, §3.71.5.1 Security Audit Considerations : "The Authorization Client or Authorization Server that is grouped with an ATNA Secure Node or Secure Application shall be able to send an audit event as defined below […] EventID […] EV(110114, DCM, "User Authentication") […] EventTypeCode […] EV("ITI-71", IHE, "User Authorization") ". §3.72.5.1 Security Audit Considerations : "When an ATNA Audit message needs to be generated by the Resource Server and the user is authenticated by way of a JWT Token, the ATNA Audit message UserName element shall record the JWT Token information […]". §3.102.5.1 Security Audit Considerations : " Resource Servers shall use the introspection results as authorization claims when formulating audit messages , as specified in ITI TF-2 3.72.5.1." ↩ ↩² ↩³ ↩⁴
web	profiles.ihe.net	IUA, §3.71.5.1 Security Audit Considerations : "The Authorization Client or Authorization Server that is grouped with an ATNA Secure Node or Secure Application shall be able to send an audit event as defined below […] EventID […] EV(110114, DCM, "User Authentication") […] EventTypeCode […] EV("ITI-71", IHE, "User Authorization") ". §3.72.5.1 Security Audit Considerations : "When an ATNA Audit message needs to be generated by the Resource Server and the user is authenticated by way of a JWT Token, the ATNA Audit message UserName element shall record the JWT Token information […]". §3.102.5.1 Security Audit Considerations : " Resource Servers shall use the introspection results as authorization claims when formulating audit messages , as specified in ITI TF-2 3.72.5.1." ↩ ↩² ↩³ ↩⁴
web	profiles.ihe.net	ITI TF-2, §3.20.4.1.1.1 DICOM and IHE Audit Event messages : "An actor in any IHE profile, when grouped with a Secure Node or Secure Application, shall be able to report the relevant events defined in Table 3.20.4.1.1.1-1 (previously Table 3.20.6-1). This table of auditable events is not exhaustive. Additional reportable events are often identified for specific events in other IHE profiles , and are documented in that profile or transaction." La tabla incluye "Node-Authentication-failure", "A secure node authentication failure has occurred during TLS negotiation, e.g., invalid certificate." ↩

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

guides.ohie.org

Master Patient Index (MPI). Conserva una identidad maestra por persona y sus enlaces con las identidades locales. Agrupa al Patient Identity Registry de PMIR , al Patient Identifier Cross-reference Manager de PIXm y al Patient Demographics Supplier de PDQm . Es el componente que OpenHIE llama Client Registry .

web

profiles.ihe.net

Audit Record Repository .

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-10-10
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

web

profiles.ihe.net

MHDS

web

profiles.ihe.net

ATNA

web

profiles.ihe.net

web

www.rfc-editor.org

Perfil IHE utilizado por HIX como base de autorización para las interacciones protegidas entre sus participantes. HIX-1 se apoya además en RFC 8693 y RFC 8707 .

web

www.rfc-editor.org

Perfil IHE utilizado por HIX como base de autorización para las interacciones protegidas entre sus participantes. HIX-1 se apoya además en RFC 8693 y RFC 8707 .

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

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. Las reglas de estos dos párrafos 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 ) ² . 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

Todo actor central que recibe directamente el token de un solicitante SHOULD comprobarlo mediante ITI-102 en cada operación, y MAY validarlo por sí mismo con las claves del Authorization Server si el token es un JWT. Quien lo valida así no ve una revocación hasta que el token expira. El Record Locator Service no tiene esa opción, porque su apartado le exige la introspección. Quien introspecciona SHOULD NOT reutilizar el resultado en operaciones posteriores, porque un resultado cacheado sigue aceptando un token ya revocado. Quien introspecciona y no obtiene respuesta del Authorization Server SHALL rechazar la solicitud con el status code 503, porque no tiene cómo comprobar el token.

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

Cuando el Record Locator Service y un actor central forman un mismo sistema, como admite MHDS para toda la infraestructura central ( MHDS Vol. 1, §1:50.6.2.4 ) ³ , la llamada entre ellos es interna y no requiere intercambio.

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 ) ⁴ . En HIX media además la recuperación, y se implementa agrupando un Document Consumer y un Document Responder de MHD .

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 ) ² . El token de un miembro nombra a los Resource Servers centrales que define la comunidad, y el token mediado a los destinos que el Authorization Server asocia a su resource , 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 mediado SHALL llevar como audiencia los Resource Servers que el Authorization Server asocia al resource de la petición de intercambio, que son solo el custodio cuando el resource nombra a uno, y SHALL llevar 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 ) ⁸ .

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 detecta y registra los eventos de su propio lado, como ATNA exige a todo Secure Node o Secure Application ( ITI TF-1, §9.1.1.1 ) ¹¹ , con la agrupación que fija la sección 2.4 .

web

profiles.ihe.net

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 ." ↩ ↩²

web

www.rfc-editor.org

web

profiles.ihe.net

MHDS Vol. 1, §1:50.6.2.4 Central Infrastructure as a single system : "This is a system that contains all of the Central Infrastructure defined in MHDS as supporting services. These actors do not need to be combined into one system." ↩

web

profiles.ihe.net

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

web

www.rfc-editor.org

web

www.rfc-editor.org

web

profiles.ihe.net

ITI TF-1, §9.1.1.1 Secure Node : "The Secure Node shall: […] 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.". La Secure Application tiene el mismo requisito en §9.1.1.2. ↩

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 tres modelos de intercambio en su whitepaper sobre intercambio de información de salud, entre ellos el centralizado y el federado ( HIE Whitepaper, §2.8 ) ¹ . HIX elige la centralizada y absorbe esa complejidad una sola vez, en el centro, donde se puede operar, verificar y auditar.

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 ) ² , y reconoce que en ese caso su opción de consentimiento no protege el contenido y que cada Document Source carga solo con la protección de sus documentos ( MHDS Vol. 1, §1:50.2.2 ) . Con custodia distribuida, eso obligaría a cada custodio a evaluar la política de la comunidad frente a cada consumidor. La mediación cierra ese hueco. La política se aplica en un solo lugar, con una única superficie auditable y un único contrato de integración.

web

profiles.ihe.net

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 ) ² . 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 ) ⁴ . 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

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

web

www.rfc-editor.org

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

web

profiles.ihe.net

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 ese solo custodio y un solo tipo de transacción, dura como mucho dos minutos y dice dentro quién pidió y quién actúa en su nombre. La Tabla 2.6-1 detalla lo que lleva.

web

www.rfc-editor.org

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 ) ¹⁰ . El destino es PCF , donde las directivas de consentimiento de cada paciente se evalúan en cada petición ( PCF Vol. 1, §1:53.4 ) ¹¹ . La Opción de Consentimiento declara dónde se aplica esa decisión y qué información necesita. El modelo de consentimiento se especificará en una versión posterior de esta guía a partir de PCF.

web

profiles.ihe.net

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 y §9.1.1.2 ) ¹² y lo que MHDS exige a su Document Registry ( MHDS Vol. 1, §1:50.1.1.1 ) ¹³ . Los registros siguen los patrones de BALP , que definen cómo se escribe un AuditEvent de FHIR para cada tipo de evento. La infraestructura central registra la solicitud que recibe del miembro y la recuperación que ella misma inicia hacia el custodio. El custodio registra la entrega.

web

profiles.ihe.net

web

profiles.ihe.net

web

profiles.ihe.net

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. Cuando el contenido queda en el custodio, el mediador resuelve la dirección en cada recuperación y llega al custodio por el canal que el directorio declara para él. Ese canal puede ser una conexión directa o una red de intercambio ya establecida, como X-Road . En ambos casos el puntero, la API que ven los miembros y el modelo de tokens son los mismos. Cambiar de canal es cambiar un dato del directorio.

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 entre cada miembro y la infraestructura central, nunca entre miembros. Si los miembros la usaran para hablar entre sí, volverían a la malla de pares que HIX descarta. Estonia sigue este mismo patrón. Su registro nacional de salud recupera los datos de cada proveedor cuando se necesitan y los presenta en un formato común ( e-Estonia ) ¹⁵ , y los sistemas de información del país se conectan entre sí sobre X-Road ( e-Estonia ) ¹⁶ . El token mediado sigue viajando por ese canal y el custodio sigue validándolo. La identidad que la red asigna a cada organización no lo sustituye.

web

e-estonia.com

web

profiles.ihe.net

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

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 ) ¹⁷ . Por eso, de los compromisos de la tabla, el que más pesa es la apuesta por la operación del centro.

web

profiles.ihe.net

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 . Sigue los perfiles que MHDS compone, que son los que se mantienen, se prueban y se distribuyen como paquetes versionados. Como la mayoría solo se publica sobre FHIR R4, HIX sigue sus modelos, transacciones y vocabulario sobre FHIR R5 sin declarar conformidad con sus artefactos R4, mientras IHE no publique ediciones R5.

web

profiles.ihe.net

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

web

profiles.ihe.net

web

profiles.ihe.net

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 ) ²³ . 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 : "IHE has enabled three distinct 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" y "Federated Discovery and Retrieve – in this model, a collection of peer entities are enabled to query each other to locate documents of interest […] the centralized model requires knowledge only of 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 ". ↩ ↩²

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

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

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 ". La Secure Application tiene el mismo requisito en §9.1.1.2 . ↩

web

profiles.ihe.net

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

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

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

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

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 y el grant Client Credentials, salvo la aplicación del paciente, que lo obtiene con HIX-2 , y lo presenta en cada solicitud con ITI-72 . Todo actor ante el que un miembro presenta un token, directamente o a través del Record Locator Service, es un Resource Server de IUA , que recibe el token con ITI-72 y lo comprueba. Ambos pueden descubrir los endpoints del Authorization Server mediante ITI-103 ¹ .

web

profiles.ihe.net

web

profiles.ihe.net

IUA exige a todo Resource Server declarar con qué opción comprueba el token ( IUA, Tabla 34.2-1 ) ² . Cada actor declara al menos una de la JWT Token Option o la Token Introspection Option , y puede declarar además la Authorization Server Metadata Option para descubrir los endpoints del Authorization Server. La Tabla 2.4-1 dice cuáles declara cada actor de HIX.

web

profiles.ihe.net

web

profiles.ihe.net

web

profiles.ihe.net

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 ³ y con el contenido que cada perfil define a partir de los patrones de BALP . Esa opción pide a quien registra al menos una de las dos interacciones de ITI-20, y al Audit Record Repository las dos. Quien escribe esos registros es, en términos de BALP , un Audit Creator, que BALP agrupa precisamente con ese Secure Node o Secure Application ( BALP, §1:52.1.1.1 ) ⁴ . Los actores centrales envían sus eventos al Audit Record Repository de la comunidad. Cada miembro conserva los suyos en su propio registro de auditoría.

web

profiles.ihe.net

web

profiles.ihe.net

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 mediado 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 ⁵ . Declara también la UnContained Reference Option , porque el puntero no lleva copias contenidas. subject y custodian referencian lo que la comunidad conserva, y sourcepatient , que MHD deja opcional y sin forma fija bajo esa opción, es una referencia lógica por identificador ⁶ . No es un Document Responder de MHD , porque las localizaciones con ITI-66 e ITI-67 las responde el Document Registry, que guarda los punteros. Es el servicio que aloja el contenido fuera del Document Registry, como lo prevé MHDS ( MHDS Vol. 1, §1:50.1.1.2 ) ⁷ , y lo sirve con ITI-68 solo al Record Locator Service. Por eso es también un Resource Server de IUA , que valida localmente el token mediado. Es un Patient Identity Source de PIXm , que declara sus identidades locales con ITI-104. Y es un Authorization Client de IUA , que obtiene el token con el que publica y declara. Puede agrupar además un Patient Identifier Cross-reference Consumer de PIXm para comprobar por su cuenta el contexto de paciente, como admite la sección 2.6 . Bajo la Opción de Almacenamiento Central deja de alojar el contenido y de ser Resource Server, porque entrega el contenido al publicar y ya no responde recuperaciones.

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 ¹¹ . Lo es porque HIX-2 se apoya en SMART App Launch, y SMART entrega ese id_token junto con el access token cuando la aplicación pide el scope openid ¹² . Y agrupa un Patient Identifier Cross-reference Consumer de PIXm , con el que resuelve a la identidad maestra la identidad de la persona autenticada para fijar el contexto de paciente.

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 más actores que los comunes de lo que casi todos agrupan .

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

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

MHDS Vol. 1, §1:50.1.1.2 Storage of Binary : "This might be other centralized infrastructure, distributed infrastructure, or within the system implementing the Document Source . […] When this is used by the Community, the service hosting the Binary shall : persist the Binary for the lifecycle expected of the Community; provide access to the community members; use the security model agreed to by the community members ." ↩

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 Authorization Option | IUA / Authorization 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." §1:50.1.1.1.3 When the grouped PMIR Patient Identity Consumer – is triggered : " No behavior is expected of the Document Registry on receipt of a feed containing create, delete, or update , although the Document Registry may consume and persist these to support the Document Registry requirements to validate Patient references as a recognized Patient within the Community." ↩

web

profiles.ihe.net

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

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

Esta opción corresponde a la primera de las dos ubicaciones del contenido que describe MHDS ( MHDS Vol. 1, §1:50.1.1.2 ) ¹ . Ambas coexisten en una misma comunidad, como explica la sección 2.1 . 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

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 ) ² . 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

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 ) ¹ , e intercala el modelo de confianza de HIX, que MHDS no necesita porque no tiene mediador. 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 ) ² . Lo que sigue separa lo que queda en manos de la comunidad de lo que fija la arquitectura.

web

profiles.ihe.net

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 y el propósito de uso van en las extensiones que IUA define para el token ( IUA, §3.71.4.2.2.1 ) ³ . 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 mediado nunca vale ante dos custodios. El formato no lo impone. El claim aud de un JWT admite una lista de audiencias ( RFC 7519, §4.1.3 ) ⁴ , y RFC 9068 recomienda rellenarlo con el recurso que el cliente indicó al pedir el token ( RFC 9068, §3 ) ⁵ . HIX lo restringe cuando el destino es un custodio, porque de eso depende que un custodio no pueda reutilizarlo ante otro. Ante actores centrales, un mismo resource puede corresponder a varios Resource Servers, igual que en el token del miembro. El token de un miembro, en cambio, nombra en aud a los Resource Servers centrales que define la comunidad, y nunca a un custodio, y el de la aplicación del paciente nombra solo al Record Locator Service.

web

www.rfc-editor.org

web

www.rfc-editor.org

El custodio recibe el token mediado y lo valida como RFC 9068 pide a todo Resource Server que recibe un access token en forma de JWT ( RFC 9068, §4 ) ⁶ . Eso cubre la firma con las claves que publica el Authorization Server, el rechazo de un alg con valor none , que el emisor sea exactamente el Authorization Server de la comunidad, que el tipo de token sea at+jwt , que la audiencia lo contenga y que el token no haya expirado. HIX añade las comprobaciones siguientes, que el custodio SHALL hacer además.

web

www.rfc-editor.org

Las comprobaciones que más pesan son la audiencia y el cliente. La audiencia sola no basta, porque un token emitido directamente a otro cliente para esa misma audiencia la pasaría. El cliente es lo que vuelve estructural que solo el Record Locator Service pueda alcanzar a un custodio en nombre de alguien, porque el Authorization Server no emite por otro camino un token con esa audiencia. El claim act lo confirma, porque es la forma en que OAuth 2.0 Token Exchange declara que hubo delegación y quién actúa ( RFC 8693, §4.1 ) ⁷ .

web

profiles.ihe.net

El custodio SHALL validar el token mediado 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

web

www.rfc-editor.org

El Authorization Server SHALL revocar los tokens vigentes de un cliente al deshabilitarlo, 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 ) ⁸ , y ningún intercambio pueda partir de ellos. Un token mediado ya emitido no tiene ciclo de vida propio. El Record Locator Service lo usa una sola vez, en la transacción que lo motivó, y expira en dos minutos como máximo, así que una transacción ya en curso termina.

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 ) ¹¹ . 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 ) ¹³ . 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 ¹⁴ .

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. " ↩ ↩²

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

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

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

El Record Locator Service comprueba el token mediante ITI-102 y consulta el Document Registry mediante ITI-67 con el identificador que recibió. El Document Registry lo resuelve a la identidad maestra mediante ITI-83. El Record Locator Service 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

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 ) ¹ . HIX lo aplica con una variante deliberada, que registra la Tabla 2.1-3 . También la recuperación pasa por ese localizador, de modo que la localización y la recuperación se median de forma centralizada, mientras la custodia de los documentos permanece distribuida entre los miembros que los producen.

web

profiles.ihe.net

MHDS

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

web

profiles.ihe.net

La petición es la de IUA . HIX exige el parámetro resource que define RFC 8707 ( RFC 8707, §2 ) ¹ , para limitar dónde se puede usar un access token. En el token de un miembro, el resource nombra a la infraestructura central, así que el token vale solo ante sus Resource Servers y nunca ante un custodio ni ante otro Resource Server fuera de ella.

web

www.rfc-editor.org

web

profiles.ihe.net

El Authorization Server pone en aud la lista de Resource Servers centrales que la comunidad define para ese resource , como prevé IUA , que limita esa lista a los Resource Servers esenciales para interactuar con el resource , normalmente solo el propio Resource Server ( IUA, §3.71.4.1.3 ) ² . En HIX el resource nombra a la infraestructura central, y los esenciales son los Resource Servers centrales que la atienden. Cuáles son depende del despliegue , y el miembro pide el token de la misma forma en todos los casos.

web

www.rfc-editor.org

El token puede ser opaco o un JWT, a elección de la implementación. Si es un JWT, sigue RFC 9068 , y un Resource Server central distinto del Record Locator Service puede validarlo por sí mismo con las claves del Authorization Server, como permite la sección 2.2 . Ese Resource Server no ve entonces una revocación hasta que el token expira. El Record Locator Service, que introspecciona siempre, la ve en la operación siguiente.

web

www.rfc-editor.org

Nota. RFC 9068 recomienda que el aud de un JWT tenga el mismo valor que el resource , pero no lo exige ( RFC 9068, §3 ) ³ . HIX sigue en esto a IUA , que prevé una lista de Resource Servers para un único resource . Lo que RFC 9068 sí exige es que la autorización del token no sea ambigua, y en HIX no lo es, porque cada scope es una transacción que atiende un único Resource Server.

web

profiles.ihe.net

La respuesta es la definida en IUA . El token de un miembro incluye siempre las extensiones de IUA subject_organization_id y purpose_of_use , con los valores que el Authorization Server obtiene de su registro, como establece la sección 2.2 . El token de una persona lleva purpose_of_use y el contexto de paciente, y subject_organization_id solo si la aplicación tiene una organización registrada, como fija HIX-2 , y el token de actor del Record Locator Service no lleva ninguna de las dos.

web

profiles.ihe.net

web

www.rfc-editor.org

Además de las validaciones que define IUA , el Authorization Server SHALL rechazar la petición en los casos de la Tabla 3.1-1 . Responde con la respuesta de error de OAuth 2.0 y el código de error que indica la tabla, definido en RFC 8707 o en RFC 6749.

web

www.rfc-editor.org

web

profiles.ihe.net

La petición es la de IUA , y quien pregunta se identifica con las credenciales que acuerda con el Authorization Server ( IUA, §3.102.5 ) ⁴ .

web

profiles.ihe.net

La petición es la de IUA , y quien pregunta se identifica con las credenciales que acuerda con el Authorization Server ( IUA, §3.102.5 ) ⁴ .

web

profiles.ihe.net

Nota. IUA permite cachear el resultado de una introspección hasta el exp que trae ( IUA, §3.102.4.2.3 ) ⁵ . HIX lo desaconseja, porque un resultado active=true cacheado sigue aceptando un token que ya fue revocado. Por esta razón, la sección 2.2 fija que quien introspecciona SHOULD NOT reutilizar el resultado en operaciones posteriores.

web

profiles.ihe.net

La respuesta es la de IUA . Solo pueden introspeccionar los actores centrales y, si la comunidad lo admite, los custodios. A cualquier otro el Authorization Server le responde con el código HTTP 401, como prevé IUA para quien no tiene acceso al introspection endpoint ( IUA, §3.102.4.1.3 ) ⁶ .

web

profiles.ihe.net

web

profiles.ihe.net

De la respuesta, el Resource Server toma la organización, el propósito de uso y, si lo hay, el contexto de paciente, y comprueba aud y scope , como fijan las reglas 1 a 3 para las peticiones a un Resource Server . Si el token está inactivo o no cumple esas reglas, rechaza la petición con el código HTTP 401, como pide IUA ( IUA, §3.72.4.3 ) ⁷ , y con el OperationOutcome que exigen las respuestas de error FHIR . Si el Authorization Server no responde, rechaza la petición con el código HTTP 503, porque no tiene cómo comprobar el token, como fija la sección 2.2 .

web

www.rfc-editor.org

RFC 8707, §2 Resource Parameter : " resource Indicates the target service or resource to which access is being requested. Its value MUST be an absolute URI […] The parameter can carry the location of a protected resource, typically as an https URL or a more abstract identifier ." ↩

web

profiles.ihe.net

IUA, §3.71.4.1.3 Expected Actions : " The Authorization Client is recommended to provide a resource value to limit usability of the requested token to the intended Resource Server. […] If the Authorization Client presented a resource value in the token request, the Authorization Server shall limit the list of Resource Server identifiers in the audience claim to only those that are essential to interact with the specified resource (typically only the Resource Server itself)." ↩

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. […] The authorization server MUST NOT issue a JWT access token if the authorization granted by the token would be ambiguous. " ↩

web

profiles.ihe.net

IUA, §3.102.5 Security Considerations : "The Resource Server shall securely identify itself towards the Authorization Server by using credentials agreed between the Authorization Server and Resource Server. At minimum, the Authorization Server and Resource Server shall support the use of Bearer tokens for Resource Server authentication as defined in [OAuth2.1, Section 7.2]. To obtain a bearer token, the Resource Server may request such a token from the Authorization Server, reusing the client credential grant flow as described in the Get Access Token [ITI-71] transaction […]". ↩

web

profiles.ihe.net

IUA, §3.102.4.2.3 Expected Actions : " If the active field is set to "false", the Resource Server shall return HTTP 401 (Not Authorized) for all requests carrying the introspected access token. The Resource Server shall use the introspection results as access token claims in all access control evaluations […] The Resource Server may cache introspection results for a given access token in case the introspection result contains an expiry field. This cache shall not extend the period as defined by the expiry field. " ↩

web

profiles.ihe.net

IUA, §3.102.4.1.3 Expected Actions : "Upon receiving the introspect request, the Authorization Server shall evaluate the Resource Server's access to the introspect endpoint. If access is not allowed, the Authorization Server shall return HTTP 401 (Not Authorized). The Authorization Server shall: […] Validate the active state of the token (e.g., check expiry or revocation). Evaluate configured access policies, taking into account the authorization claims related to the token and the Resource Server identity. […] If the one of the above checks fails the Authorization Server shall return an introspection response with the "active" field set to "false" as described in RFC7662, Section 2.2." ↩

web

profiles.ihe.net

IUA, §3.72.4.3 Expected Actions : "If the token includes a scope claim, the Resource Server shall verify that the scope covers the transaction to the requested resource [OAuth 2.1, Section 7]. If the token includes an audience claim, the Resource Server shall verify that the audience includes the Resource Server itself [OAuth 2.1, Section 7]. […] If the token verification, or scope matching, or the access policy enforcement fails, the Resource Server shall respond with a HTTP 401 (Unauthorized) error. " ↩

web

profiles.ihe.net

Authorization Client

web

profiles.ihe.net

Authorization Server

web

www.rfc-editor.org

RFC 6749 , The OAuth 2.0 Authorization Framework, octubre de 2012. Aporta el token endpoint, la autenticación del cliente y la respuesta de error.

web

www.rfc-editor.org

RFC 8693 , OAuth 2.0 Token Exchange, enero de 2020. Aporta el grant de intercambio, sus parámetros y el claim act .

web

www.rfc-editor.org

RFC 8707 , Resource Indicators for OAuth 2.0, febrero de 2020. Aporta el parámetro resource y el error invalid_target .

web

www.rfc-editor.org

RFC 9068 , JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens, octubre de 2021. Aporta la forma del token mediado y su validación en el destino.

web

www.rfc-editor.org

RFC 7519 , JSON Web Token (JWT), mayo de 2015. Aporta los claims del token, entre ellos aud y jti .

web

profiles.ihe.net

IUA , Internet User Authorization, revisión 2.5, junio de 2026. Aporta ITI-71, con el que el Record Locator Service obtiene su token de actor, ITI-72, con el que presenta el token mediado, y las extensiones ihe_iua que el token mediado copia del token del solicitante.

web

profiles.ihe.net

Nota. HIX-1 se apoya en ITI-71. El Record Locator Service obtiene con ITI-71 su token de actor, y el intercambio usa el mismo token endpoint del Authorization Server con otro grant. IUA limita ITI-71 a los grants Authorization Code y Client Credentials, y de RFC 8693 solo toma el parámetro requested_token_type ( IUA, §3.71.4.1.2.1 ). Admite que sus actores soporten otros grants ( IUA, §34.4.1.1 ) ¹ , y HIX-1 especifica uno de ellos, el grant Token Exchange de RFC 8693 con un resource indicator de RFC 8707.

web

profiles.ihe.net

web

profiles.ihe.net

web

www.rfc-editor.org

La petición sigue RFC 8693: un POST al token endpoint del Authorization Server con los parámetros en el body, codificados como application/x-www-form-urlencoded ( RFC 8693, §2.1 ) ² .

web

www.rfc-editor.org

Nota. RFC 8693 define actor_token como opcional en una solicitud general de Token Exchange ( §2.1 ) ² . HIX-1 lo requiere porque usa semántica de delegación, en la que subject_token representa al solicitante y actor_token al Record Locator Service, que actúa en su nombre ( §1.1 ) ³ . Una petición que solo lleva subject_token no expresa delegación ( Apéndice A.1.1 ) ⁴ . Además, separa las dos identidades en juego. La autenticación del cliente prueba quién llama al token endpoint, y el actor_token aporta el actor de la delegación que queda en el token mediado.

web

www.rfc-editor.org

web

www.rfc-editor.org

web

www.rfc-editor.org

El Record Locator Service se autentica en el token endpoint como cliente confidencial, con el método que acuerde con el Authorization Server ( RFC 6749, §2.3 ).

web

www.rfc-editor.org

El resource sale del directorio porque el directorio es el único origen de los endpoints que usa la infraestructura central, como fija la sección 2.2 . El Authorization Server restringe la audiencia del token a los Resource Servers que asocia a ese resource , y a ese único custodio cuando nombra a uno, como recomienda RFC 8707 ( RFC 8707, §2 ). La petición no lleva audience . RFC 8693 lo trataría como otro destino, y el token emitido sería válido en todos los destinos indicados ( RFC 8693, §2.1 y §2.1.1 ) ⁵ .

web

www.rfc-editor.org

web

www.rfc-editor.org

web

www.rfc-editor.org

RFC 8693 distingue la delegación de la suplantación: en la delegación, quien actúa conserva su identidad y representa a otro. Aquí, subject_token representa al solicitante y actor_token al Record Locator Service ( RFC 8693, §1.1 ). El claim act del token mediado procede del actor_token e identifica al actor de la delegación ( RFC 8693, §4.1 ) ³ . El destino SHOULD comprobar ese claim, como recomienda la sección 2.6 .

web

www.rfc-editor.org

web

www.rfc-editor.org

Además de validar cada token que recibe, como exige RFC 8693 ( RFC 8693, §2.1 ) ² , el Authorization Server SHALL comprobar lo siguiente.

web

www.rfc-editor.org

HIX expresa la delegación como la describe RFC 8693, con el actor_token en la petición y el claim act en el token resultante ( RFC 8693, §1.1 ) ³

web

www.rfc-editor.org

RFC 6749 lo exige cuando el cliente se autentica con el header Authorization , como en el ejemplo, y lo admite en los demás casos ( RFC 6749, §5.2 ) ⁶

web

www.rfc-editor.org

RFC 8693 prevé ese código para un subject_token o un actor_token que no es válido o que la política no acepta ( RFC 8693, §2.2.2 ) ⁶

web

www.rfc-editor.org

RFC 8707 prevé ese código para un destino que el Authorization Server no acepta ( RFC 8707, §2 ) ⁵

web

www.rfc-editor.org

El Authorization Server responde a un intercambio concedido con el código HTTP 200 y un body JSON con los parámetros de la respuesta de RFC 8693 ( RFC 8693, §2.2.1 ) ⁷ . La Tabla 3.2-4 fija sus valores en HIX.

web

profiles.ihe.net

IHE no define ningún evento de auditoría para un intercambio de tokens. IUA solo define un evento de auditoría para la emisión de tokens en ITI-71 ( IUA, §3.71.5.1 ) ⁸ , y HIX-1 no es ITI-71. La obtención del token de actor sí es un ITI-71, y se registra como indica la Tabla 3-2 .

web

www.rfc-editor.org

El Authorization Server SHALL registrar cada intercambio, concedido o rechazado. En ese registro SHALL enlazar, por su jti , el token del solicitante, el token de actor y, si lo emitió, el token mediado ( RFC 7519, §4.1.7 ) ⁹ . Si rechazó el intercambio, enlaza los tokens de la petición que pueda identificar. El registro no contiene ningún token completo, como dice la regla común de los registros de auditoría .

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]." §34.4.1.1 Authorization Grant Types : "This profile specifies the use of the Authorization Code and Client Credential grant types. Actors of this profile may support other grant types as well. " ↩

web

profiles.ihe.net

web

profiles.ihe.net

web

www.rfc-editor.org

RFC 8693, §2.1 Request : "The following parameters are included in the HTTP request entity-body using the "application/x-www-form-urlencoded" format […] grant_type REQUIRED. The value "urn:ietf:params:oauth:grant-type:token-exchange" indicates that a token exchange is being performed. […] Multiple "resource" parameters may be used to indicate that the issued token is intended to be used at the multiple resources listed. […] subject_token REQUIRED. A security token that represents the identity of the party on behalf of whom the request is being made. […] actor_token OPTIONAL. A security token that represents the identity of the acting party. […] In processing the request, the authorization server MUST perform the appropriate validation procedures for the indicated token type and, if the actor token is present, also perform the appropriate validation procedures for its indicated token type." §3 Token Type Identifiers : "urn:ietf:params:oauth:token-type:access_token Indicates that the token is an OAuth 2.0 access token issued by the given authorization server ." ↩ ↩² ↩³

web

www.rfc-editor.org

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 . […] Typically, in the request, the "subject_token" represents the identity of the party on behalf of whom the token is being requested while the "actor_token" represents the identity of the party to whom the access rights of the issued token are being delegated . […] The "actor_token" request parameter, however, does provide a means for providing information about the desired actor, and the JWT "act" claim can provide a representation of a chain of delegation ." §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

web

www.rfc-editor.org

RFC 8693, Appendix A.1.1 Token Exchange Request : "In the following token exchange request, a client is requesting a token with impersonation semantics ( delegation is impossible with only a "subject_token" and no "actor_token" )." ↩

web

www.rfc-editor.org

RFC 8707, §2 Resource Parameter : "Its value MUST be an absolute URI […] invalid_target The requested resource is invalid, missing, unknown, or malformed. The authorization server SHOULD audience-restrict issued access tokens to the resource(s) indicated by the "resource" parameter. " RFC 8693, §2.1 Request : "The "audience" and "resource" parameters may be used together to indicate multiple target services with a mix of logical names and resource URIs." §2.1.1 Relationship between Resource, Audience, and Scope : "The semantics of such a request are that the client is asking for a token with the requested scope that is usable at all the requested target services . […] An authorization server can use the "invalid_target" error code, defined in Section 2.2.2, to inform a client that it requested access to too many target services simultaneously." ↩ ↩²

web

www.rfc-editor.org

web

www.rfc-editor.org

web

www.rfc-editor.org

RFC 8693, §2.2.2 Error Response : "If the request itself is not valid or if either the "subject_token" or "actor_token" are invalid for any reason, or are unacceptable based on policy, the authorization server MUST construct an error response, as specified in Section 5.2 of [RFC6749]. The value of the "error" parameter MUST be the "invalid_request" error code. If the authorization server is unwilling or unable to issue a token for any target service indicated by the "resource" or "audience" parameters, the "invalid_target" error code SHOULD be used in the error response. […] Other error codes may also be used, as appropriate. " RFC 6749, §5.2 Error Response : "The authorization server responds with an HTTP 400 (Bad Request) status code (unless specified otherwise) and includes the following parameters with the response: error REQUIRED. […] unauthorized_client The authenticated client is not authorized to use this authorization grant type. […] invalid_scope The requested scope is invalid, unknown, malformed, or exceeds the scope granted by the resource owner." Sobre invalid_client: "Client authentication failed […] The authorization server MAY return an HTTP 401 (Unauthorized) status code to indicate which HTTP authentication schemes are supported. If the client attempted to authenticate via the "Authorization" request header field, the authorization server MUST respond with an HTTP 401 (Unauthorized) status code and include the "WWW-Authenticate" response header field matching the authentication scheme used by the client." ↩ ↩²

web

www.rfc-editor.org

web

www.rfc-editor.org

RFC 8693, §2.2.1 Successful Response : "scope OPTIONAL if the scope of the issued security token is identical to the scope requested by the client ; otherwise, it is REQUIRED. refresh_token OPTIONAL. A refresh token will typically not be issued when the exchange is of one temporary credential (the subject_token) for a different temporary credential (the issued token) for use in some other context. […] Profiles or deployments of this specification should clearly document the conditions under which a client should expect a refresh token […]" §3 Token Type Identifiers : "The intent of this specification is that "urn:ietf:params:oauth:token-type:access_token" be an indicator that the token is a typical OAuth access token issued by the authorization server in question, opaque to the client , and usable the same manner as any other access token obtained from that authorization server." ↩

web

www.rfc-editor.org

web

profiles.ihe.net

web

www.rfc-editor.org

RFC 7519, §4.1.7 "jti" (JWT ID) Claim : "The "jti" (JWT ID) claim provides a unique identifier for the JWT ." RFC 9068, §2.2 Data Structure : " jti REQUIRED - as defined in Section 4.1.7 of [RFC7519]." ↩

web

www.rfc-editor.org

web

profiles.ihe.net

HIX-2 es ITI-71 con el grant Authorization Code y PKCE (Proof Key for Code Exchange), más la renovación del token con el grant de refresh token. IUA limita ITI-71 a los grants Authorization Code y Client Credential, y admite que sus actores soporten otros, como el de refresh token ( IUA, §34.4.1.1 ) ¹ . Para el contexto de paciente, HIX-2 adopta determinados elementos de SMART App Launch, que IUA procura no contradecir ( IUA, Relation to SMART-on-FHIR ) ² . Tiene identificador propio porque en ella el Authorization Server fija el contexto de paciente, algo que ITI-71 no prevé.

web

profiles.ihe.net

web

profiles.ihe.net

web

www.rfc-editor.org

Nota. SMART App Launch exige a sus servidores aceptar el parámetro aud y deja resource como sinónimo opcional ⁵ . RFC 8707 separa la intención de la restricción, porque el Authorization Server restringe la audiencia del token a partir del resource , la comunica en el claim aud y puede usar el mismo valor o derivar de él otro identificador ( RFC 8707, §2 ) ¹² . Por esta razón, HIX-2 se aparta en este punto de SMART App Launch.

web

profiles.ihe.net

El Authorization Server sigue publicando sus metadatos de IUA con ITI-103 , y los dos documentos describen los mismos endpoints.

web

profiles.ihe.net

Authorization Server y OpenID Provider

web

profiles.ihe.net

IUA , Internet User Authorization, revisión 2.5, junio de 2026. Aporta ITI-71 con el grant Authorization Code y su evento de auditoría.

web

openid.net

OpenID Connect Core 1.0 , con la fe de erratas 2, diciembre de 2023. Aporta la autenticación de la persona, el id_token y los scopes openid y offline_access .

web

www.rfc-editor.org

RFC 6749 , The OAuth 2.0 Authorization Framework, octubre de 2012. Aporta el grant de refresh token y las respuestas de error.

web

www.rfc-editor.org

RFC 7636 , Proof Key for Code Exchange by OAuth Public Clients, septiembre de 2015. Aporta code_challenge , code_verifier y el método S256 .

web

www.rfc-editor.org

RFC 9700 , Best Current Practice for OAuth 2.0 Security, enero de 2025. Aporta la protección de los refresh tokens de los clientes públicos.

web

profiles.ihe.net

La petición es un GET al authorization endpoint, con los parámetros en la query, como define IUA para el grant Authorization Code ( IUA, §3.71.4.1.2.2 ) ⁴ . La Tabla 3.3-4 dice qué valor fija HIX en cada parámetro.

web

www.rfc-editor.org

Una de las URI de redirección registradas para la aplicación. El Authorization Server SHALL compararla por coincidencia exacta, como exige RFC 9700 ( RFC 9700, §2.1 ) ¹⁴

web

profiles.ihe.net

Obligatorio, como exige IUA ( IUA, §3.71.4.1.2.2 ) ¹⁵ . Un valor impredecible que la aplicación genera para cada petición

web

profiles.ihe.net

Ninguno de los scopes de SMART ni de OpenID Connect autoriza operaciones ante el Record Locator Service. Lo que autoriza son los identificadores de transacción, según la regla 2 para las peticiones a un Resource Server . La aplicación pide solo los que necesita, como IUA exige a todo Authorization Client ( IUA, §3.71.5 ) ¹⁶ . El Authorization Server SHALL NOT conceder a una aplicación del paciente identificadores de transacción distintos de ITI-66 , ITI-67 e ITI-68 , porque la aplicación solo localiza y recupera los documentos de la persona.

web

profiles.ihe.net

El Authorization Server valida los parámetros, autentica a la persona y obtiene su autorización para la aplicación, como IUA exige antes de emitir el código ( IUA, §3.71.4.1.3.2 ) ¹⁷ . Cómo se verifica la identidad de la persona es política de la comunidad, según la sección 2.6 .

web

openid.net

Nota. OpenID Connect exige al OpenID Provider obtener siempre el consentimiento antes de emitir un refresh token para el acceso sin conexión, y advierte que un consentimiento guardado no siempre basta. Para asegurarlo, la petición lleva prompt=consent , salvo que otras condiciones del procesamiento permitan el acceso sin conexión ( OpenID Connect Core, §11 ) ¹⁸ . En HIX esa condición es que el Authorization Server pide el consentimiento en cada lanzamiento y nunca reutiliza uno guardado, que es lo mismo que obtendría prompt=consent . Por esta razón, HIX-2 no exige a la aplicación enviar prompt=consent .

web

www.rfc-editor.org

Si concede la autorización, el Authorization Server redirige el navegador a la redirect_uri con code y state ⁴ . Si la rechaza, redirige con error y el state de la petición ( RFC 6749, §4.1.2.1 ) ¹⁹ .

web

www.rfc-editor.org

La petición es un POST al token endpoint, con los parámetros en el body en formato application/x-www-form-urlencoded . El canje del código sigue IUA ⁴ y SMART App Launch ( SMART App Launch, Obtain access token ) ²¹ . La renovación sigue RFC 6749 ( RFC 6749, §6 ) ²² y SMART App Launch ¹⁰ . La Tabla 3.3-6 dice qué valor fija HIX en cada parámetro de los dos grants.

web

www.rfc-editor.org

SMART App Launch exige el client_id en el canje de una aplicación pública ²¹ . La aplicación pública SHALL enviarlo también al renovar, como admite RFC 6749 ( RFC 6749, §3.2.1 ) ²³ , para que el Authorization Server compruebe a qué aplicación emitió el refresh token.

web

www.rfc-editor.org

Con una aplicación pública, el Authorization Server SHALL emitir un refresh token nuevo en cada renovación e invalidar el anterior, o ligar el refresh token a esa instancia de la aplicación, como exige RFC 9700 para los clientes públicos ( RFC 9700, §4.14.2 ) ²⁴ . Si rota los refresh tokens y recibe uno ya invalidado, SHALL revocar el refresh token vigente de esa autorización. RFC 9700 describe esa revocación como la respuesta de la rotación a un refresh token reutilizado ²⁴ .

web

profiles.ihe.net

El Authorization Server responde a una petición concedida con el código HTTP 200, un body JSON y los headers Cache-Control: no-store y Pragma: no-cache que exige IUA ( IUA, §3.71.4.2.2 ) ²⁵ . La Tabla 3.3-7 dice qué valor fija HIX en cada parámetro. La respuesta a una renovación tiene la misma forma, salvo por el id_token . El Authorization Server SHALL incluir patient en toda respuesta concedida, también en la de una renovación.

web

www.rfc-editor.org

El Authorization Server SHALL incluir en el scope del access token solo identificadores de transacción. openid , fhirUser , launch/patient y offline_access los consume él al emitir el token y no aparecen en él. El scope de la respuesta describe el access token ( RFC 6749, §5.1 ) ²⁷ , y por eso lleva solo esos identificadores, según la regla 2 para las peticiones a un Resource Server . La aplicación sabe qué obtuvo de OpenID Connect y de SMART por los parámetros que recibe, es decir, id_token , refresh_token y patient .

web

www.rfc-editor.org

Si rechaza la petición, el Authorization Server responde con la respuesta de error de OAuth 2.0 y el código HTTP 400 ( RFC 6749, §5.2 ) ²⁸ . SHALL rechazarla en las condiciones de la Tabla 3.3-8 .

web

profiles.ihe.net

El Authorization Server registra cada lanzamiento y cada renovación, concedidos o rechazados, con el evento que IUA define para ITI-71 ( IUA, §3.71.5.1 ) ³⁰ , como indica la Tabla 3-2 . IUA no define un evento para la renovación, y HIX usa para ella el mismo.

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)." §34.4.1.1 Authorization Grant Types : "This profile specifies the use of the Authorization Code and Client Credential grant types. Actors of this profile may support other grant types as well. " ↩

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)." §34.4.1.1 Authorization Grant Types : "This profile specifies the use of the Authorization Code and Client Credential grant types. Actors of this profile may support other grant types as well. " ↩

web

profiles.ihe.net

IUA, Relation to SMART-on-FHIR : " IUA is not based on SMART-on-FHIR, but does strive to not conflict with that standard. " ↩

web

profiles.ihe.net

IUA, §3.71.4.1.2.2 Authorization Code grant type : " resource (optional): Single valued identifier of the Resource Server endpoint to be accessed […] code_challenge (required) […] redirect_uri (optional) […] This parameter is required if the Authorization Client is registered at the Authorization Server with multiple redirect URI, optional otherwise […] code_verifier: The original code verifier string. " ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

web

profiles.ihe.net

IUA, adición a MHD Vol. 2, §3.67.5.2 Use with the Internet User Authorization (IUA) Profile : " scope: ITI-67 This scope request authorizes the full [ITI-67] transaction. " ↩

web

www.rfc-editor.org

RFC 8707, §2 Resource Parameter : " resource Indicates the target service or resource to which access is being requested. […] invalid_target The requested resource is invalid, missing, unknown, or malformed. The authorization server SHOULD audience-restrict issued access tokens to the resource(s) indicated by the "resource" parameter. Audience restrictions can be communicated in JSON Web Tokens [RFC7519] with the "aud" claim […] The authorization server may use the exact "resource" value as the audience or it may map from that value to a more general URI or abstract identifier for the given resource. " ↩ ↩²

web

www.rfc-editor.org

RFC 9700, §2.1 Protecting Redirect-Based Flows : "When comparing client redirection URIs against pre-registered URIs, authorization servers MUST utilize exact string matching except for port numbers in localhost redirection URIs of native apps" ↩

web

profiles.ihe.net

IUA, §3.71.4.1.2.2 Authorization Code grant type : "state (required): An unguessable value used by the client to track the state between the authorization request and the callback to the redirect URI. While this parameter is optional in the OAuth 2.1 Authorization Framework […] it is required in this profile for security reasons ." ↩

web

profiles.ihe.net

IUA, §3.71.5 Security Considerations : "Access token should be short-lived with a lifetime of 1 hour or less. […] Refresh token may be long lived. […] To reduce the attack surface, client claims and authorization grants shall be the minimal; i.e., the authorization grant scope requested by the Authorization Client shall be the minimal required scope for the resource request to be used for." ↩ ↩²

web

profiles.ihe.net

IUA, §3.71.4.1.3.2 Authorization Code grant type : " The Authorization Server shall authenticate confidential and credential clients […] If valid, the Authorization Server shall authenticate the user and obtain the user consent […]" ↩ ↩² ↩³

web

openid.net

OpenID Connect Core 1.0, §11 Offline Access : " When offline access is requested, a prompt parameter value of consent MUST be used unless other conditions for processing the request permitting offline access to the requested resources are in place. The OP MUST always obtain consent to returning a Refresh Token that enables offline access to the requested resources. A previously saved user consent is not always sufficient to grant offline access." ↩

web

www.rfc-editor.org

RFC 6749, §4.1.2.1 Error Response : "If the request fails due to a missing, invalid, or mismatching redirection URI, or if the client identifier is missing or invalid, the authorization server SHOULD inform the resource owner of the error and MUST NOT automatically redirect the user-agent to the invalid redirection URI. […] temporarily_unavailable The authorization server is currently unable to handle the request due to a temporary overloading or maintenance of the server." ↩ ↩² ↩³

web

www.rfc-editor.org

RFC 7636, §4.4.1 Error Response : "If the server requires Proof Key for Code Exchange (PKCE) by OAuth public clients and the client does not send the "code_challenge" in the request, the authorization endpoint MUST return the authorization error response with the "error" value set to "invalid_request" . […] If the server supporting PKCE does not support the requested transformation, the authorization endpoint MUST return the authorization error response with "error" value set to "invalid_request" ." §4.6 Server Verifies code_verifier before Returning the Tokens : "If the values are not equal, an error response indicating "invalid_grant" as described in Section 5.2 of [RFC6749] MUST be returned." ↩ ↩²

web

www.rfc-editor.org

web

www.rfc-editor.org

RFC 6749, §6 Refreshing an Access Token : " The requested scope MUST NOT include any scope not originally granted by the resource owner, and if omitted is treated as equal to the scope originally granted by the resource owner. […] Because refresh tokens are typically long-lasting credentials used to request additional access tokens, the refresh token is bound to the client to which it was issued . […] The authorization server MAY issue a new refresh token, in which case the client MUST discard the old refresh token and replace it with the new refresh token ." ↩ ↩² ↩³ ↩⁴

web

www.rfc-editor.org

RFC 6749, §3.2.1 Client Authentication : " A client MAY use the "client_id" request parameter to identify itself when sending requests to the token endpoint. In the "authorization_code" "grant_type" request to the token endpoint, an unauthenticated client MUST send its "client_id" to prevent itself from inadvertently accepting a code intended for a client with a different "client_id"." ↩

web

www.rfc-editor.org

RFC 9700, §4.14.2 Recommendations : " Authorization servers MUST utilize one of these methods to detect refresh token replay by malicious actors for public clients […] The authorization server cannot determine which party submitted the invalid refresh token, but it will revoke the active refresh token. […] Authorization servers MAY revoke refresh tokens automatically in case of a security event […] Refresh tokens SHOULD expire if the client has been inactive for some time " ↩ ↩² ↩³

web

profiles.ihe.net

IUA, §3.71.4.2.2 Message Semantics : "scope (required): The scope granted by the Authorization Server. […] refresh_token (optional): A token provided by the Authorization Server which can be used by the Authorization Client to obtain new access tokens using the same authorization grant . […] The Authorization Server shall include the HTTP Cache-Control response header field with value no-store and the Pragma response header field value no-cache to the access token response […]" ↩

web

openid.net

OpenID Connect Core 1.0, §12.2 Successful Refresh Response : "Upon successful validation of the Refresh Token, the response body is the Token Response of Section 3.1.3.3 […] except that it might not contain an id_token . If an ID Token is returned as a result of a token refresh request, the following requirements apply: its iss Claim Value MUST be the same as in the ID Token issued when the original authentication occurred, its sub Claim Value MUST be the same as in the ID Token issued when the original authentication occurred […]" ↩

web

www.rfc-editor.org

RFC 6749, §5.1 Successful Response : "scope OPTIONAL, if identical to the scope requested by the client; otherwise, REQUIRED. The scope of the access token as described by Section 3.3." ↩

web

www.rfc-editor.org

RFC 6749, §5.2 Error Response : "The authorization server responds with an HTTP 400 (Bad Request) status code (unless specified otherwise) and includes the following parameters with the response: error REQUIRED. […] invalid_grant The provided authorization grant (e.g., authorization code, resource owner credentials) or refresh token is invalid, expired, revoked , does not match the redirection URI used in the authorization request, or was issued to another client. […] invalid_scope The requested scope is invalid, unknown, malformed, or exceeds the scope granted by the resource owner ." ↩

web

profiles.ihe.net

IUA, §3.71.5.1 Security Audit Considerations : "Source (1) Human Requestor (0) Destination (0) Audit Source (Client Authentication Agent) (1) Participant Object (1) […] Token […] ParticipantObjectTypeCode M "2" (System) […] ParticipantObjectTypeCodeRole M "13" (Security Resource)" ↩

web

profiles.ihe.net

Get Authorization Server Metadata [ITI-103]

web

profiles.ihe.net

Maintain Time [ITI-1]

web

profiles.ihe.net

Authenticate Node [ITI-19]

web

www.ihe.net

ITI-20 se usa bajo la opción ATX: FHIR Feed. Un evento suelto viaja con la interacción Send Audit Resource Request, que es un create de FHIR, y varios juntos con Send Audit Bundle Request, que es un batch ( RESTful ATNA, 3.20.4.2 y 3.20.4.2 y ) ¹ . HIX la usa sin parámetros ni condiciones de rechazo propios. Lo que HIX fija es el contenido de los eventos, con las reglas comunes del identificador de correlación y de los registros de auditoría .

web

profiles.ihe.net

Ninguno. IUA define su propio evento, User Authentication con el subtipo ITI-71 ( IUA, §3.71.5.1 ) ³

web

profiles.ihe.net

Ninguno propio. El Resource Server registra la identidad del token en el evento de la transacción que lo lleva ( IUA, §3.72.5.1 ) ³ , y en un AuditEvent la añade con uno de los patrones OAuth Security Token de BALP ( BALP, §3:5.7.5 ) ⁴

web

profiles.ihe.net

Ninguno propio. El Resource Server usa el resultado de la introspección como atributos del evento ( IUA, §3.102.5.1 ) ³

web

profiles.ihe.net

El evento de ITI-71 ( IUA, §3.71.5.1 ) ³ . Lo detalla Patient Application Launch [HIX-2]

web

profiles.ihe.net

ITI-103, ITI-1 e ITI-19 no tienen fila, porque su especificación no define un evento propio. Los eventos generales de seguridad, como un fallo de autenticación de un nodo, son los de la tabla de ITI-20 que todo Secure Node o Secure Application debe poder registrar ( ITI TF-2, §3.20.4.1.1.1 ) ¹¹ .

web

www.ihe.net

RESTful ATNA (Query and Feed), Rev. 3.6, §3.20.4.2 Send Audit Resource Request Message – FHIR Feed Interaction : "A Secure Node, Secure Application or Audit Record Forwarder, that supports the ATX: FHIR Feed Option, uses this message to post a single AuditEvent Resource to the Audit Record Repository using a FHIR create interaction […]". §3.20.4.4 Send Audit Bundle Request Message – FHIR Feed Interaction: "A Secure Node, Secure Application or Audit Record Forwarder that supports the ATX: FHIR Feed Option uses this message to post a Bundle of AuditEvent Resources to the Audit Record Repository using a FHIR batch interaction […]" ↩

web

profiles.ihe.net

IUA, §3.71.5.1 Security Audit Considerations : "The Authorization Client or Authorization Server that is grouped with an ATNA Secure Node or Secure Application shall be able to send an audit event as defined below […] EventID […] EV(110114, DCM, "User Authentication") […] EventTypeCode […] EV("ITI-71", IHE, "User Authorization") ". §3.72.5.1 Security Audit Considerations : "When an ATNA Audit message needs to be generated by the Resource Server and the user is authenticated by way of a JWT Token, the ATNA Audit message UserName element shall record the JWT Token information […]". §3.102.5.1 Security Audit Considerations : " Resource Servers shall use the introspection results as authorization claims when formulating audit messages , as specified in ITI TF-2 3.72.5.1." ↩ ↩² ↩³ ↩⁴

web

profiles.ihe.net

web

profiles.ihe.net

web

profiles.ihe.net

ITI TF-2, §3.20.4.1.1.1 DICOM and IHE Audit Event messages : "An actor in any IHE profile, when grouped with a Secure Node or Secure Application, shall be able to report the relevant events defined in Table 3.20.4.1.1.1-1 (previously Table 3.20.6-1). This table of auditable events is not exhaustive. Additional reportable events are often identified for specific events in other IHE profiles , and are documented in that profile or transaction." La tabla incluye "Node-Authentication-failure", "A secure node authentication failure has occurred during TLS negotiation, e.g., invalid certificate." ↩

Internal Images

central-architecture-diagram.svg