Health Information Exchange
0.1.0 - ci-build
Costa Rica
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
Esta sección define los actores de HIX y las transacciones que los vinculan. Los actores y transacciones tomados de un perfil IHE conservan el significado que les da su especificación de origen. Las transacciones identificadas como HIX-n son propias de esta guía y se especifican en el Volumen 2.
HIX distingue tres clases de actor. Los actores centrales los opera la comunidad. Los actores de miembro los opera cada organización participante. La fuente autoritativa de identidad es externa a la comunidad. Un miembro solo trata con la infraestructura central, nunca con otro miembro. Obtiene sus tokens del Authorization Server, localiza y recupera a través del Record Locator Service, publica ante el Document Registry y declara identidades ante el Master Patient Index, que validan esas transacciones como describe la sección 2.1.
Las tres pestañas siguientes muestran a los actores de miembro en su escenario típico. La aplicación del paciente es la de una persona que entra a su propio expediente. El hospital es un sistema que consume documentos, en atención normal y en una emergencia, donde por ejemplo busca al paciente por sus datos demográficos con PDQm. El laboratorio es un sistema que publica y custodia documentos.
Figura 2.2-1: Aplicación del paciente ante la comunidad
Figura 2.2-2: Hospital que consulta, en atención normal y en emergencia (ETREAT con PDQm)
Figura 2.2-3: Laboratorio que publica documentos
Las dos tablas siguientes listan las transacciones que definen a cada actor. R significa que la transacción es requerida para declararse conforme con el actor, y O que es opcional. La columna Referencia indica el perfil IHE que define la transacción, o el Volumen 2 de esta guía para las propias de HIX. Los miembros, y los actores centrales ante los que presentan tokens, se agrupan además con IUA, y todos los actores salvo la aplicación del paciente con ATNA y CT. Esas agrupaciones, y las transacciones que traen consigo, se describen en la sección 2.4. Por eso las tablas listan las transacciones de IUA y ATNA solo para el actor que las responde, el Authorization Server y el Audit Record Repository. Quién inicia y quién responde cada transacción lo dice la Tabla 3-1.
Tabla 2.2-1: Actores de miembro
| Actor | Transacción | Opcionalidad | Referencia |
|---|---|---|---|
| Sistema que publica y custodia documentos | Patient Identity Feed FHIR [ITI-104] | R | PIXm |
| Provide Document Bundle [ITI-65] | R | MHD | |
| Retrieve Document [ITI-68] | R (nota 1) | MHD | |
| Mobile Patient Identifier Cross-reference Query [ITI-83] | O | PIXm | |
| Sistema que consume documentos | Find Document Lists [ITI-66] | R | MHD |
| Find Document References [ITI-67] | R | MHD | |
| Retrieve Document [ITI-68] | R | MHD | |
| Mobile Patient Identifier Cross-reference Query [ITI-83] | O | PIXm | |
| Mobile Patient Demographics Query [ITI-78] | O (nota 2) | PDQm | |
| Patient Demographics Match [ITI-119] | O (nota 3) | PDQm | |
| Aplicación del paciente | Patient Application Launch [HIX-2] | R | Vol. 2 |
| Find Document Lists [ITI-66] | R | MHD | |
| Find Document References [ITI-67] | R | MHD | |
| Retrieve Document [ITI-68] | R | MHD |
Tabla 2.2-2: Actores centrales y fuente de identidad
| Actor | Transacción | Opcionalidad | Referencia |
|---|---|---|---|
| Record Locator Service | Find Document Lists [ITI-66] | R | MHD |
| Find Document References [ITI-67] | R | MHD | |
| Retrieve Document [ITI-68] | R | MHD | |
| Find Matching Care Services [ITI-90] | R | mCSD | |
| Mediated Token Exchange [HIX-1] | R | Vol. 2 | |
| Document Registry | Provide Document Bundle [ITI-65] | R | MHD |
| Find Document Lists [ITI-66] | R | MHD | |
| Find Document References [ITI-67] | R | MHD | |
| Retrieve Document [ITI-68] | O (nota 4) | MHD | |
| Mobile Patient Identifier Cross-reference Query [ITI-83] | R | PIXm | |
| Find Matching Care Services [ITI-90] | R | mCSD | |
| Mobile Patient Identity Feed [ITI-93] | R | PMIR | |
| Authorization Server | Get Access Token [ITI-71] | R | IUA |
| Introspect Token [ITI-102] | R | IUA | |
| Get Authorization Server Metadata [ITI-103] | R | IUA | |
| Mediated Token Exchange [HIX-1] | R | Vol. 2 | |
| Patient Application Launch [HIX-2] | R | Vol. 2 | |
| Mobile Patient Identifier Cross-reference Query [ITI-83] | R | PIXm | |
| Directorio de la comunidad | Find Matching Care Services [ITI-90] | R | mCSD |
| Master Patient Index | Mobile Patient Identity Feed [ITI-93] | R | PMIR |
| Subscribe to Patient Updates [ITI-94] | R | PMIR | |
| Patient Identity Feed FHIR [ITI-104] | R | PIXm | |
| Mobile Patient Identifier Cross-reference Query [ITI-83] | R | PIXm | |
| Mobile Patient Demographics Query [ITI-78] | R | PDQm | |
| Patient Demographics Match [ITI-119] | R | PDQm | |
| Audit Record Repository | Record Audit Event [ITI-20] | R | ATNA |
| Fuente autoritativa de identidad (externa) | Mobile Patient Identity Feed [ITI-93] | R | PMIR |
Notas:
El propósito de uso no depende del actor sino del caso de uso. Es un código del conjunto PurposeOfUse de HL7, tomado del sistema v3-ActReason, que el Authorization Server incluye en el token de cada solicitante y que la decisión de divulgación evalúa. No decide qué transacciones puede pedir un solicitante. Eso lo fija el scope de su token. Un mismo hospital consulta con TREAT en la atención habitual y con ETREAT en una urgencia. HIX usa el conjunto completo de HL7 y no lo restringe. Qué propósitos acepta una comunidad, y con qué condiciones, es política de implementación. La Tabla 2.2-3 solo orienta al lector con los más frecuentes y el caso en el que aparece cada uno1.
Tabla 2.2-3: Propósitos de uso más frecuentes en HIX
| Código | Nombre en HL7 | Caso en el que aparece |
|---|---|---|
TREAT |
treatment | Atención habitual de un paciente. Con él consulta un hospital y publica un laboratorio |
ETREAT |
Emergency Treatment | Atención inmediata de una urgencia. Qué permite frente a TREAT lo fija la política de la comunidad. Por ejemplo, divulgar documentos que en atención habitual exigirían un consentimiento, aunque el paciente esté plenamente identificado |
BTG |
break the glass | Urgencia atendida por quien no está autorizado para ese acceso, con anulación de la política. Cómo se admite y se audita lo fija cada comunidad |
COC |
coordination of care | Coordinación de la atención de una persona entre varias organizaciones |
PATRQT |
patient requested | Acceso de una persona a su propio expediente |
FAMRQT |
family requested | Acceso de un familiar autorizado por el paciente, si la comunidad admite la representación |
PWATRNY |
power of attorney | Acceso del representante legal del paciente, como el padre o la madre de un menor, si la comunidad admite la representación |
HOPERAT |
healthcare operations | Actividades administrativas y contractuales de la organización |
HPAYMT |
healthcare payment | Actividades financieras relacionadas con el pago de la atención |
HRESCH |
healthcare research | Investigación en salud |
PUBHLTH |
public health | Actividades de salud pública, como la notificación de enfermedades de declaración obligatoria |
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)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.
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.
El custodio es el miembro que produce documentos. Los conserva, declara las identidades locales de sus pacientes y publica los punteros a sus documentos con el propósito de uso del caso, normalmente TREAT. Agrupa a un Document Source de MHD y a un Patient Identity Source de PIXm, y es el servicio que aloja el contenido de sus documentos, como explica la sección 2.4. Responde las recuperaciones que le llegan desde la infraestructura central, y solo desde ella.
El custodio SHALL declarar mediante ITI-104 la identidad local de todo paciente sobre el que publique, en su propio dominio de identificadores y con un identificador de la persona que la fuente autoritativa reconoce, como la cédula. SHALL publicar mediante ITI-65 punteros que lo nombren a él como custodio y lleven etiqueta de confidencialidad, con URL de contenido relativa cuando el contenido queda en él.
El custodio SHALL conservar el contenido y responder ITI-68, salvo que declare la Opción de Almacenamiento Central. SHALL validar localmente el token de cada solicitud con las claves que publica el Authorization Server, conforme a la sección 2.6. SHALL rechazar toda solicitud que no llegue con un token mediado obtenido por el Record Locator Service y SHALL NOT atender recuperaciones originadas directamente en otro miembro.
El consumidor es el miembro que consulta el expediente de un paciente. Localiza y recupera documentos a través del Record Locator Service y agrupa a un Document Consumer de MHD. Desde su punto de vista la comunidad es un único servidor FHIR. Actúa con el propósito de uso TREAT en la atención habitual y con ETREAT cuando atiende una urgencia.
El consumidor SHALL obtener un token del Authorization Server cuya audiencia incluya al Record Locator Service y SHALL presentarlo en toda solicitud. SHALL recuperar los documentos únicamente a través de las URL que el Record Locator Service le entrega. Puede resolver la identidad de un paciente con ITI-83 y, si declara la Opción de Demografía, buscarlo por sus datos demográficos con ITI-78. Si declara la Opción de Coincidencia Demográfica, puede pedir además con ITI-119 las identidades que más se parecen a unos datos incompletos. Ambas sirven, por ejemplo, en una urgencia en la que no tiene un identificador fiable, como en la Figura 2.2-2.
La aplicación del paciente accede al expediente de la persona que la usa, con el contexto de paciente que el Authorization Server fija durante el lanzamiento y el propósito de uso que corresponde a quien actúa, según la Tabla 2.2-3. Agrupa a un Document Consumer de MHD. A partir del lanzamiento, sus consultas y recuperaciones son las de cualquier otro consumidor, confinadas a ese único paciente.
Este actor SHALL obtener su token mediante HIX-2 y SHALL NOT solicitar ni asumir un contexto de paciente distinto del que el token declara. Su token solo autoriza ITI-66, ITI-67 e ITI-68, como fija HIX-2.
El Record Locator Service media la localización y recuperación de documentos en nombre de los miembros. Ante ellos es un Resource Server de IUA y un Document Responder de MHD. Ante el Document Registry y los custodios actúa como Document Consumer de MHD y, ante cada Resource Server al que llama, como Authorization Client de IUA. Es el único actor que atiende a los miembros al localizar y recuperar y el único que alcanza a un custodio. Responde de que ningún puntero ni documento llegue a un solicitante contra la decisión de divulgación, la evalúe él mismo o el Document Registry, según dónde la sitúe la comunidad.
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.
El Record Locator Service SHALL NOT entregar a un solicitante ningún puntero, lista ni documento cuya divulgación la política no permita, y SHALL garantizar que la decisión se evalúe sobre los punteros antes de que se origine cualquier recuperación. Puede evaluarla él mismo o, cuando la comunidad la sitúa allí, dejar que la evalúe el Document Registry sobre las consultas que recibe de él. En ese caso SHALL alcanzar al Document Registry con el token mediado de HIX-1, porque es el que le lleva el sujeto, la organización, el propósito de uso y el contexto de paciente del solicitante. La omisión SHALL NOT ser distinguible, para el solicitante, de la ausencia del documento, y SHALL quedar registrada en la auditoría. La misma decisión SHALL aplicarse a las listas que se devuelven por ITI-66, porque una lista revela qué documentos existen.
Al atender un ITI-68, el Record Locator Service SHALL someter de nuevo el puntero pedido a la decisión de divulgación antes de alcanzar al custodio, releyéndolo en el Document Registry cuando la evaluación está allí. Un puntero cuya divulgación se niega SHALL NOT originar consulta al directorio, intercambio de token ni llamada al custodio.
El Record Locator Service SHALL entregar a los solicitantes URL de contenido que apunten a sí mismo. SHALL resolver el endpoint del custodio en el directorio de la comunidad en cada recuperación, salvo bajo la Opción de Almacenamiento Central, y SHALL NOT revelar ese endpoint al solicitante.
El Record Locator Service SHALL obtener mediante HIX-1 un token mediado para cada custodio al que llama en nombre de un solicitante. Hacia cada actor central que la comunidad despliegue como un sistema distinto SHOULD obtenerlo también, salvo que la comunidad autorice un token propio conforme al apartado siguiente. SHALL pedir en cada intercambio únicamente el scope de la transacción que va a realizar y SHALL NOT reenviar a ninguno el token del solicitante.
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)3, la llamada entre ellos es interna y no requiere intercambio.
El Record Locator Service SHALL NOT conservar copias de los documentos que transitan por él ni registrar su contenido. No tiene acceso propio a ningún custodio ni al contenido, no llama al Master Patient Index, y hacia los demás actores centrales solo tiene el acceso que fija el apartado de llamadas a los actores centrales. Cuando el custodio no responde, SHALL indicar que el custodio no está disponible, de forma que esa recuperación no se confunda con un documento inexistente.
Toda llamada del Record Locator Service a un actor central desplegado como un sistema distinto lleva un token que SHALL emitir el Authorization Server de la comunidad, SHALL estar destinado a ese actor y SHALL limitarse a las transacciones que la comunidad autoriza ante él. Esta guía recomienda el token mediado de HIX-1, porque no deja al mediador ninguna credencial que valga sin una petición viva y lleva al destino el sujeto original. La comunidad MAY autorizar en su lugar un token propio, que el Record Locator Service obtiene con ITI-71 y el grant Client Credentials y reutiliza mientras esté vigente, y que el Authorization Server SHALL limitar al destino y a las transacciones autorizadas. Ese token SHALL NOT incluir ITI-68, porque el contenido solo se alcanza con un token mediado, también cuando lo conserva el Document Registry bajo la Opción de Almacenamiento Central. Tampoco sirve para ITI-66 ni ITI-67 cuando la comunidad sitúa la evaluación de la decisión de divulgación en el Document Registry, porque esa evaluación necesita el contexto del solicitante que solo lleva el token mediado.
ITI-90 es la única transacción que el solicitante no puede tener en su scope, porque los miembros no consultan el directorio. Cuando el Record Locator Service la pide con HIX-1, el Authorization Server SHALL comprobar que la delegación registrada la permite ante el directorio, sin exigir que el scope del token del solicitante la contenga.
En todos los casos, el Record Locator Service SHALL llamar a un actor central únicamente para atender una operación autorizada de un solicitante y SHALL registrar cada llamada bajo el identificador de correlación de esa operación. La comunidad puede adoptar otra forma de obtener el token si cumple las condiciones anteriores. La sección 2.6.5 compara las dos formas descritas.
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)4. En HIX media además la recuperación, y se implementa agrupando un Document Consumer y un Document Responder de MHD.
El Document Registry es el registro de documentos de la comunidad. Toma su nombre y su función del Document Registry de MHDS, pero es un actor de HIX, definido por los actores que agrupa en la sección 2.4. Conserva los punteros a los documentos publicados y, bajo la Opción de Almacenamiento Central, el contenido que los custodios le entregan.
El Document Registry SHALL conservar en el subject de los punteros, los SubmissionSet y las carpetas la identidad maestra del paciente. La comunidad MAY autorizar que traduzca a esa identidad, mediante ITI-83, el identificador de la persona que la fuente autoritativa reconoce o un identificador del propio dominio del miembro, al publicar, al localizar o en ambos casos. Las dos decisiones son independientes y permiten a los miembros usar, en las operaciones que la comunidad habilite, los identificadores que ya conocen sin consultar antes la identidad maestra.
El Document Registry SHALL registrar cada puntero a nombre de la organización que declara el token y SHALL rechazar la publicación cuyo custodio no coincida con ella. SHALL validar mediante ITI-90 que esa organización es un miembro activo de la comunidad. Esa consulta, y las que hace con ITI-83, las autentica con un token propio que obtiene con ITI-71 y el grant Client Credentials, con el destino como resource y solo esa transacción como scope.
El Document Registry SHALL validar mediante ITI-83 el subject de cada puntero, del SubmissionSet y de cada carpeta, y SHALL rechazar la publicación si alguno no corresponde a una identidad maestra activa o si no corresponden todos a la misma persona56. Si la comunidad autoriza la traducción al publicar, MAY aceptar en subject una referencia lógica por el identificador que la fuente autoritativa reconoce, como admite MHD7, o por un identificador del propio dominio del custodio, que es el apartamiento de MHD que declara la Tabla 2.1-3. Cuando la acepta, SHALL resolverla con ITI-83 y escribir la identidad maestra al indexar, y SHALL rechazar un subject con un identificador de cualquier otro dominio. Si no ofrece esa traducción, el custodio debe enviar la identidad maestra.
Cada puntero SHALL llevar en sourcepatient una referencia lógica a la identidad local que el custodio declaró con ITI-104, con el identificador en el dominio del custodio y sin referencia a un recurso. Si el custodio nombró al paciente en subject por ese identificador y no envió sourcepatient, el Document Registry SHALL copiarlo allí antes de escribir la identidad maestra. SHALL rechazar la publicación si falta sourcepatient y el subject no lo aporta, si la organización que publica no declaró esa identidad local o si esta no resuelve a la misma identidad maestra que el subject del puntero.
El Document Registry SHALL rechazar la publicación que carezca de etiqueta de confidencialidad y, cuando el contenido queda en el custodio, aquella cuya URL de contenido no sea relativa. La sección 3.5 describe la publicación y reúne en una tabla los rechazos que HIX añade.
El Document Registry MAY, si la comunidad autoriza la traducción al localizar, resolver mediante ITI-83 el identificador de paciente recibido en ITI-66 o ITI-67 y buscar por la identidad maestra resultante. Si no ofrece esa traducción, el solicitante debe nombrar al paciente por su identidad maestra. El Record Locator Service transmite el identificador recibido y no lo resuelve. Cuando la comunidad sitúa en él la decisión de divulgación, SHALL evaluarla sobre cada consulta que recibe del Record Locator Service con el contexto del solicitante que lleva el token mediado, conforme al apartado de decisión de divulgación del Record Locator Service.
El Document Registry recibe por ITI-93 los cambios de las identidades maestras. SHALL aplicar a los punteros y a las listas que conserva las fusiones recibidas, de modo que ninguno quede asociado a una identidad que dejó de existir.
El Authorization Server emite, comprueba e intercambia los tokens que circulan por la comunidad. Es el Authorization Server de IUA. Es el único actor que emite tokens y el único que conoce a la vez al solicitante, su organización y el scope que se le concede. No decide sobre consentimiento, relación terapéutica ni identidad de paciente.
El Authorization Server SHALL restringir la audiencia de todo token que emite a destinatarios identificados explícitamente, como recomienda RFC 9700 (RFC 9700, §2.3)2. El token 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.
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)8.
El scope del token mediado SHALL ser el pedido en el intercambio y SHALL estar contenido en la delegación registrada para el Record Locator Service ante el destino, es decir, las transacciones que la comunidad registra en el Authorization Server para ese destino. También SHALL estar contenido en el scope del token del solicitante, salvo para ITI-90, como fija el apartado de llamadas a los actores centrales de la sección 2.2. La vida del token mediado SHALL NOT superar los dos minutos ni la vida restante del token del solicitante. El Authorization Server SHALL NOT emitir por ningún otro camino un token cuya audiencia sea un custodio, ni un token propio del Record Locator Service cuyo scope incluya ITI-68.
El Authorization Server SHALL fijar la organización del solicitante desde su propio registro, sin aceptarla de la solicitud, y SHALL emitir como propósito de uso solo uno que su registro admita para ese cliente. Cómo indica el solicitante que necesita un propósito de emergencia lo decide la comunidad, porque IUA no define ningún mecanismo para ello, como explica la sección 2.6. Cuando una persona se autentica, SHALL resolver su identidad verificada a la identidad maestra mediante ITI-83, con un token propio que obtiene con el grant Client Credentials, y SHALL fijar ese resultado como contexto de paciente del token, conforme a HIX-2. SHALL NOT emitir un token con contexto de paciente cuando esa identidad no resuelva a una identidad maestra.
El directorio publica las organizaciones participantes, su pertenencia a la comunidad y los endpoints en los que responden. Es el Directory de mCSD de la comunidad y la única fuente de la que la infraestructura central aprende a quién dirigir una recuperación.
El directorio SHALL responder ITI-90 y SHALL ser el único origen de los endpoints que usa la infraestructura central. SHALL identificar a cada organización con el mismo identificador que el Authorization Server incluye en sus tokens. Es Resource Server de IUA y SHALL comprobar el token de cada consulta del Record Locator Service y del Document Registry como fija la Tabla 2.4-1. Los miembros no consultan el directorio. Su contenido se mantiene administrativamente, al incorporar un miembro.
El Master Patient Index agrupa al Patient Identity Registry de PMIR, al Patient Identifier Cross-reference Manager de PIXm y al Patient Demographics Supplier de PDQm. Conserva una identidad maestra por persona, creada por la fuente autoritativa de identidad, y los enlaces con las identidades locales que los miembros declaran.
El Master Patient Index SHALL crear identidades maestras únicamente a partir de ITI-93 recibido de la fuente autoritativa de identidad. SHALL aceptar ITI-104 únicamente en el dominio de identificadores del miembro que lo origina y SHALL rechazar la declaración que no pueda vincularse a una identidad maestra existente. Dentro de su propio dominio el miembro gestiona sus identidades locales con libertad, incluida la resolución de sus propios duplicados que define ITI-104.
Nota. Rechazar la declaración de una persona sin identidad maestra es la regla por defecto de esta versión y es una decisión abierta. Queda por definir cómo se declaran las personas que todavía no tienen un identificador que la fuente autoritativa reconozca, como un recién nacido, un paciente sin identificar en una urgencia o una persona extranjera.
Una declaración de un miembro SHALL NOT crear, fusionar ni eliminar una identidad maestra. El Master Patient Index SHALL NOT modificar la demografía de la identidad maestra a partir de lo que un miembro declara. SHALL responder ITI-83 únicamente con la identidad maestra, nunca con las identidades locales que otros miembros declararon. PIXm admite esa restricción, porque deja que la respuesta sea un subconjunto determinado por política (PIXm, §2:3.83.4.1.3)9.
El Master Patient Index SHALL responder ITI-78 e ITI-119 únicamente con identidades maestras, nunca con las identidades locales de los miembros, y SHALL limitar la respuesta a los pacientes que la política de la comunidad permita revelar por esa vía. SHALL rechazar una consulta ITI-78 que no lleve ningún criterio que nombre o describa a la persona. En ITI-119 SHALL indicar el grado de coincidencia de cada resultado, como exige PDQm (PDQm, §2:3.119.4.2.2.4)10. Además, SHALL ordenarlos de más a menos probable, como describen los casos de ITI-119.
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)11, con la agrupación que fija la sección 2.4.
La fuente autoritativa de identidad es el sistema, externo a la comunidad, contra el que se verifica la identidad de una persona y del que la comunidad obtiene sus identidades maestras. Es el Patient Identity Source de PMIR. HIX no designa cuál es. La propuesta para Costa Rica es que sea el EDUS, porque ya tiene resuelta la identificación de las personas.
La fuente autoritativa SHALL alimentar el Master Patient Index mediante ITI-93, con un token emitido por el Authorization Server de la comunidad. Es la única que crea, actualiza, fusiona o desactiva identidades maestras.
Mediated Token Exchange [HIX-1]. El Record Locator Service presenta al Authorization Server el token del solicitante y recibe a cambio un token mediado para el destino que nombra el resource y un solo tipo de transacción, como especifica la sección 3.2.
Patient Application Launch [HIX-2]. Una aplicación elegida por una persona obtiene del Authorization Server un token destinado al Record Locator Service cuyo contexto de paciente es la identidad maestra de esa persona, como especifica la sección 3.3.
Nota. La incorporación de un miembro, por la que una organización queda descrita en el directorio y reconocida por el Authorization Server, es un procedimiento administrativo y no una transacción.
Las citas reproducen el texto publicado por su fuente. Los recortes se marcan con "[…]" y la negrita es de esta guía.
v3-ActReason, TREAT: "treatment. To perform one or more operations on information for provision of health care." ETREAT: "Emergency Treatment. To perform one or more operations on information for provision of immediately needed health care for an emergent condition." PATRQT: "patient requested. To perform one or more operations on information in response to a patient's request." FAMRQT: "family requested. To perform one or more operations on information in response to a request by a family member authorized by the patient." PWATRNY: "power of attorney. To perform one or more operations on information in response to a request by a person appointed as the patient's legal representative." ↩
RFC 9700, §2.3 Access Token Privilege Restriction: "In particular, access tokens SHOULD be audience-restricted to a specific resource server or, if that is not feasible, to a small set of resource servers." §4.10.2 Audience-Restricted Access Tokens: "The authorization server associates the access token with the particular resource server, and the resource server is then supposed to verify the intended audience. If the access token fails the intended audience validation, the resource server refuses to serve the respective request." ↩ ↩2
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." ↩
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". ↩
PIXm, §2:3.83.4.2.2.5 Post Merge/Delete: "Based upon policy, when the Patient is deprecated or deleted, the response message shall return: 200 OK, and return a Bundle with no patient resource, or 404 Not Found" ↩
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." ↩
MHD, §2:3.65.4.1.2.2 Patient Identity: "A commonly accessible logical reference using Patient Identifier, instead of a literal reference, may be acceptable where there is a common Identifier, such as a national individual identifier." ↩
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." ↩
PIXm, §2:3.83.4.1.3 Expected Actions: "The Patient Identifiers returned may be a subset based on policies that might restrict access to some Patient Identifiers. For guidance on handling Access Denied, see ITI TF-2: Appendix Z.7." ↩
PDQm, §2:3.119.4.2.2.4 Quality of Match: "The Patient Demographics Supplier SHALL convey the quality of each match based on strength of the particular result to the supplied Patient Resource. […] it SHALL represent the confidence of a particular match within the bundle as a score attribute." Y en los casos de §2:3.119.4.1.3 Expected Actions: "The results are ordered from most likely to least likely." ↩
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. ↩