Health Information Exchange
0.1.0 - ci-build Costa Rica

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

Volumen 2. Transacciones

El Volumen 1 fija la arquitectura de HIX, es decir, qué actores tiene la comunidad, qué hace cada uno y por qué. Este volumen entra en el detalle de las transacciones entre esos actores. De cada una dice qué lleva la petición, qué se responde, cuándo se rechaza y qué se registra. Cuando una regla ya está en el Volumen 1, aquí se enlaza en lugar de repetirla.

Solo dos transacciones se especifican completas, Mediated Token Exchange [HIX-1] y Patient Application Launch [HIX-2], porque son propias de HIX y ningún perfil las define. Las demás vienen de perfiles IHE, y HIX las usa tal como las definen. De ellas este volumen solo dice con qué restricciones las usa la comunidad y lo muestra con ejemplos. Lo que este volumen no dice se aplica tal como lo publican IHE y OAuth 2.0.

Cómo leer este volumen

Cada página abre con lo que comparten sus transacciones. Después dedica una sección a cada transacción IHE, siempre con los mismos cuatro apartados y en el orden en que una transacción IHE presenta su alcance, sus mensajes y su auditoría.

  1. Alcance en HIX. Quién inicia la transacción y quién la responde, en términos de actores HIX.
  2. Petición. Los parámetros y elementos que HIX fija, con enlace a la sección exacta del perfil.
  3. Respuesta y rechazos. Las condiciones de rechazo que HIX aplica, cada una con su motivo.
  4. Auditoría. Una remisión a la Tabla 3-2, salvo que HIX añada algo.

HIX-1 y HIX-2 no siguen esa plantilla abreviada sino la completa de IHE, desde el alcance y los roles de actor hasta las consideraciones de seguridad y la auditoría.

Reglas comunes

Las reglas de esta sección se aplican a varias transacciones. Provienen del Volumen 1, salvo la regla sobre respuestas FHIR, que se establece aquí.

Peticiones a un Resource Server

El Resource Server SHALL rechazar la petición que no cumpla estas reglas.

  1. Lleva un token conforme a ITI-72 cuya audiencia incluye a ese Resource Server, según la sección 2.2.
  2. El scope del token incluye el identificador de la transacción IHE, por ejemplo ITI-67. Esto también se aplica al token de una aplicación del paciente, según la sección 2.6.
  3. El Resource Server toma del token la organización, el propósito de uso y, si corresponde, el contexto de paciente del solicitante. No los toma de la petición, como establece la sección 2.2. El Authorization Server fija la organización desde su propio registro y solo emite propósitos de uso que su registro admite, según sus requisitos.

Respuestas de error FHIR

Todo actor que rechaza una transacción FHIR SHALL incluir un OperationOutcome en la respuesta, junto con el status code del error.

Identificador de correlación

​El Record Locator Service genera el identificador de correlación y lo envía al custodio en el header X-Request-Id, como detalla Localización y recuperación. No reenvía un identificador propuesto por el solicitante, según la sección 2.6.

Registros de auditoría

Ningún registro de auditoría contiene un token completo ni contenido clínico, según la sección 2.6.

Índice de transacciones

La Tabla 3-1 reúne las veinte transacciones de HIX, agrupadas por la página que las especifica. De cada una dice el perfil que la define, qué actor la inicia y cuál la responde, y su nombre enlaza a su especificación. Las del último grupo HIX las usa sin restricciones propias, y por eso su nombre enlaza a IHE. La tabla incluye las transacciones de las Tablas 2.2-1 y 2.2-2 y las que traen consigo las agrupaciones de la Tabla 2.4-2.

Tabla 3-1: Transacciones de HIX

Transacción Perfil Inicia Responde
Tokens y autorización      
Get Access Token [ITI-71] IUA Custodio, consumidor, fuente autoritativa de identidad, Record Locator Service, para su token de actor y, si la comunidad lo autoriza, para un token propio hacia los actores centrales, el Document Registry, para sus consultas ITI-83 e ITI-90, y el propio Authorization Server para su consulta ITI-83 Authorization Server
Introspect Token [ITI-102] IUA Record Locator Service, Document Registry, Master Patient Index y directorio de la comunidad, y el custodio cuando la comunidad admite la introspección Authorization Server
Mediated Token Exchange [HIX-1] HIX Record Locator Service Authorization Server
Patient Application Launch [HIX-2] HIX Aplicación del paciente Authorization Server
Incorporate Access Token [ITI-72] IUA Todo Authorization Client, es decir, los miembros, la aplicación del paciente, la fuente autoritativa de identidad, el Record Locator Service, el Document Registry en sus consultas ITI-83 e ITI-90 y el Authorization Server en su consulta ITI-83 Todo Resource Server, es decir, el Record Locator Service, el custodio, el Document Registry, el Master Patient Index y el directorio de la comunidad
Identidad del paciente      
​Mobile Patient Identity Feed [ITI-93] PMIR Fuente autoritativa de identidad, y el Master Patient Index hacia el Document Registry Master Patient Index y Document Registry
​Patient Identity Feed FHIR [ITI-104] PIXm Custodio Master Patient Index
​Mobile Patient Identifier Cross-reference Query [ITI-83] PIXm Consumidor, Document Registry y Authorization Server, y opcionalmente el custodio Master Patient Index
​Mobile Patient Demographics Query [ITI-78] PDQm Consumidor Master Patient Index
​Patient Demographics Match [ITI-119] PDQm Consumidor Master Patient Index
Publicación      
​Provide Document Bundle [ITI-65] MHD Custodio Document Registry
Localización y recuperación      
​Find Document Lists [ITI-66] MHD Consumidor y aplicación del paciente, y el Record Locator Service hacia el Document Registry Record Locator Service y Document Registry
​Find Document References [ITI-67] MHD Consumidor y aplicación del paciente, y el Record Locator Service hacia el Document Registry Record Locator Service y Document Registry
​Retrieve Document [ITI-68] MHD Consumidor y aplicación del paciente, y el Record Locator Service hacia el custodio o, bajo la Opción de Almacenamiento Central, el Document Registry Record Locator Service y custodio, o el Document Registry bajo la Opción de Almacenamiento Central
​Find Matching Care Services [ITI-90] mCSD Record Locator Service y Document Registry Directorio de la comunidad
Auditoría      
Record Audit Event [ITI-20] ATNA Todo actor salvo la aplicación del paciente El Audit Record Repository de la comunidad, o el del propio miembro
Sin restricciones de HIX      
Subscribe to Patient Updates [ITI-94] PMIR Patient Identity Subscriber, que puede ser el Document Registry o la operación de la comunidad Master Patient Index
Get Authorization Server Metadata [ITI-103] IUA Todo Authorization Client y todo Resource Server Authorization Server
Maintain Time [ITI-1] CT Todo actor salvo la aplicación del paciente Time Server que designa la comunidad
Authenticate Node [ITI-19] ATNA Todo actor salvo la aplicación del paciente, al abrir una conexión El actor con el que se conecta

El scope de cada transacción es su identificador, como fija la regla 2 para las peticiones a un Resource Server. HIX-2 pide además openid, fhirUser, launch/patient y, para renovar el token, offline_access.

ITI-71, HIX-1, HIX-2, ITI-72, ITI-102, ITI-103, ITI-20, ITI-1 e ITI-19 no tienen scope propio. ITI-71, HIX-1 y HIX-2 son las que piden los scopes, ITI-72 la que los transporta, y las demás forman parte de la infraestructura de seguridad de la comunidad. En HIX-1, el Record Locator Service pide el scope de la transacción que va a realizar ante el destino.

Auditoría

Todo actor de HIX, salvo la aplicación del paciente, registra sus eventos como recursos AuditEvent con Record Audit Event [ITI-20], como fija la sección 2.4. Los actores centrales los envían al Audit Record Repository de la comunidad y cada miembro registra los de su lado. Este volumen especifica ITI-20 aquí, una sola vez, para todas las transacciones.

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

El contenido de cada evento es el que el perfil de la transacción define en su sección de auditoría. La mayoría de los perfiles lo construye sobre los patrones de BALP para las interacciones REST de FHIR, que son Create, Read, Update, Delete y Query, cada uno con una variante para cuando hay un paciente identificado (BALP, §3:5.7.3)2. La Tabla 3-2 dice qué evento corresponde a cada transacción y quién lo registra.

Tabla 3-2: Eventos de auditoría por transacción

Transacción Patrón BALP Quién registra
ITI-71 Ninguno. IUA define su propio evento, User Authentication con el subtipo ITI-71 (IUA, §3.71.5.1)3 El Authorization Server y el cliente que pide el token
ITI-72 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)3, y en un AuditEvent la añade con uno de los patrones OAuth Security Token de BALP (BALP, §3:5.7.5)4 El cliente y el Resource Server
ITI-102 Ninguno propio. El Resource Server usa el resultado de la introspección como atributos del evento (IUA, §3.102.5.1)3 El Record Locator Service, y el Document Registry, el Master Patient Index y el custodio cuando la usan
HIX-1 IHE no define ningún evento para un intercambio de tokens. Lo especifica Mediated Token Exchange [HIX-1] El Authorization Server
HIX-2 El evento de ITI-71 (IUA, §3.71.5.1)3. Lo detalla Patient Application Launch [HIX-2] El Authorization Server
ITI-93 Ninguno. PMIR define su propio evento, un Patient Record de ITI-20 que registran igual quien lo envía y quien lo recibe (PMIR, §2:3.93.5.1)5 La fuente autoritativa de identidad, el Master Patient Index y el Document Registry
ITI-104 PatientUpdate en el custodio, que no distingue un alta de una actualización, y PatientCreate o PatientUpdate en el Master Patient Index, que sí los distingue (PIXm, §2:3.104.5.1)6 El custodio y el Master Patient Index
ITI-83 PatientQuery (PIXm, §2:3.83.5.1)6 Quien consulta y el Master Patient Index
ITI-78 Query (PDQm, §2:3.78.5.1)7 El consumidor y el Master Patient Index
ITI-119 Query (PDQm, §2:3.119.5.1)7 El consumidor y el Master Patient Index
ITI-65 Ninguno. MHD define su propio evento, con criterios similares a los de ITI-41 (MHD, §2:3.65.5.1)8 El custodio y el Document Registry
ITI-66 PatientQuery, en la versión que publica MHD (MHD, §2:3.66.5.1)8 El consumidor, el Record Locator Service en sus dos papeles y el Document Registry
ITI-67 PatientQuery, en la versión que publica MHD (MHD, §2:3.67.5.1)8 El consumidor, el Record Locator Service en sus dos papeles y el Document Registry
ITI-68 PatientRead, en la versión que publica MHD (MHD, §2:3.68.5.1)8 El consumidor, el Record Locator Service en sus dos papeles y el custodio, o el Document Registry bajo la Opción de Almacenamiento Central
ITI-90 Query o Read, según la interacción (mCSD, §2:3.90.5.1)9 El Record Locator Service, el Document Registry y el directorio de la comunidad

El Record Locator Service registra la solicitud que recibe y cada recuperación que origina hacia un custodio, bajo un mismo identificador de correlación, como fija la sección 2.6. En ITI-66, ITI-67 e ITI-68 la tabla le da dos papeles, porque MHD pide registrar tanto al Document Responder, que es su papel ante el solicitante, como al Document Consumer, que es su papel ante el Document Registry o el custodio (MHD, 2:3.67.5.1.1 y 2:3.67.5.1.1 y )10. La aplicación del paciente no registra eventos. Su actividad la registran el Authorization Server al lanzarla y el Record Locator Service en cada consulta, como dice la sección 2.4.

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

Referencias

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

  1. 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 […]" ↩

  2. BALP, §3:5.7.3 RESTful activities: "When a FHIR RESTful interaction happens, the following AuditEvent patterns can be used. […] There are two sets of profiles distinguished by Patient as a subject being mandated to be populated." La tabla de esa sección nombra los patrones Create, Read, Update, Delete y Query, y sus variantes PatientCreate, PatientRead, PatientUpdate, PatientDelete y PatientQuery. ↩

  3. 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." ↩ ↩2 ↩3 ↩4

  4. BALP, §3:5.7.5 OAuth Security Token: "There are three patterns defined: opaque, minimal, and comprehensive. […] The profiling AuditEvent defined here is the AuditEvent that the Client and Server would record when using IUA with the ITI TF-2: 3.72 Incorporate Access Token [ITI-72] to secure some RESTful transaction." ↩

  5. PMIR, §2:3.93.5.1 Security Audit Considerations: "The Mobile Patient Identity Feed transaction is a Patient Record Message event as defined in ITI TF-2: 3.20.4.1.1.1-1. Note that the same audit message is recorded by both Supplier and Consumer. The difference being the Audit Source element. […] The actors involved shall record audit events according to the Audit Event for Mobile Patient Identity Feed by the Supplier and Consumer." Ese perfil, IHE.PMIR.Feed.Audit, deriva directamente de AuditEvent y no de un patrón de BALP. ↩

  6. PIXm, §2:3.104.5.1 Security Audit Considerations: "The Security audit logging will conform to the RESTful interactions following IHE-BALP Basic Audit Logging Patterns." 3.104.5.1.1 Patient Identity Source Audit: "The Patient Identity Source can't distinguish a Create from a Update" y "The Patient Identity Source will log a Delete or Update". 2:3.104.5.1.2 Patient Identifier Cross-reference Manager Audit: "The Patient Identifier Cross-Reference Manager can distinguish a Create and Update so is expected to record Create and Update specifically." §2:3.83.5.1 Security Audit Considerations dice lo mismo para ITI-83, y su perfil IHE.PIXm.Query.Audit.Manager dice "Build off of the IHE BasicAudit Patient Query event". ↩ ↩2

  7. PDQm, §2:3.78.5.1 Security Audit Considerations: "The Mobile Patient Demographics Query Transaction is a Query Information event as defined in Table 3.20.4.1.1.1-1. The actors involved SHALL record audit events according to the following". §2:3.119.5.1 dice lo mismo para ITI-119. Sus perfiles, como IHE.PDQm.Query.Audit.Supplier, dicen "Build off of the IHE BasicAudit Query event". ↩ ↩2

  8. MHD, §2:3.65.5.1 Security Audit Considerations: "The security audit criteria are similar to those for the Provide and Register Document Set-b [ITI-41] transaction as this transaction does export a document." Sus perfiles, como IHE.MHD.ProvideBundle.Audit.Recipient, derivan directamente de AuditEvent. Para ITI-67, el perfil IHE.MHD.FindDocumentReferences.Audit.Responder dice "Build off of the IHE BasicAudit PatientQuery event", como los de ITI-66, y para ITI-68 IHE.MHD.RetrieveDocument.Audit.Responder dice "Build off of the IHE BasicAudit PatientRead event". MHD 5.0.0 publica esos patrones en su propio paquete, sobre FHIR R5. ↩ ↩2 ↩3 ↩4

  9. mCSD, §2:3.90.5.1 Security Audit Considerations: "Note that when grouped with ATNA Secure Node or Secure Application Actor, the same audit message is recorded by both Directory and Query Client. […] the actors involved shall be able to record audit events according to the Audit Event for Find Matching Care Services for Read by the Directory and Query Client or the Audit Event for Find Matching Care Services for Query by the Directory and Query Client." Esos perfiles derivan de los patrones Read y Query de BALP. ↩

  10. MHD, §2:3.67.5.1.1 Document Consumer Audit: "The Document Consumer when grouped with ATNA Secure Node or Secure Application Actor shall be able to record a Find Document References Consumer Audit Event Log." §2:3.67.5.1.2 Document Responder Audit: "The Document Responder when grouped with ATNA Secure Node or Secure Application Actor shall be able to record a Find Document References Responder Audit Event Log." Las secciones §2:3.66.5.1 y §2:3.68.5.1 dicen lo mismo para ITI-66 e ITI-68. ↩

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