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

Casos de uso y flujos

Esta sección recorre los casos de uso que la arquitectura soporta. Cada uno se cuenta desde el punto de vista de quien lo vive y se acompaña del flujo entre actores, con las transacciones y el orden en que ocurren. El detalle de cada transacción está en el Volumen 2.

Los casos siguen las tres historias de las figuras de la sección 2.2, el laboratorio que publica, el hospital que consulta y la persona que accede a lo suyo, precedidas por la identidad del paciente, que es condición de todas. La publicación, la consulta y el acceso del paciente son independientes entre sí y ocurren en cualquier orden y con cualquier frecuencia. La incorporación de un miembro, que precede a todo, es un procedimiento administrativo y no un caso de uso de esta guía.

Identidad del paciente

Descripción del caso de uso

Una persona existe en la comunidad desde que la fuente autoritativa de identidad la alimenta al registro de identidad maestra. El custodio que la atiende declara a la comunidad qué identidad local le corresponde. El registro vincula esa identidad con la identidad maestra y, desde entonces, los documentos que ese custodio publique con su identificador local quedan asociados a la misma persona que los publicados por los demás miembros.

Un miembro que declaró sus identidades locales pregunta con su propio identificador de la persona y obtiene la identidad maestra enlazada, que es como la comunidad la nombra. Un miembro que solo consume no declara ninguna, y pregunta con el identificador nacional de la persona, cuyo dominio la comunidad siempre reconoce. Ninguno de los dos obtiene los identificadores de los demás miembros. Un miembro que no dispone de ningún identificador conocido por la comunidad puede, si declara la Opción de Demografía, buscar por datos demográficos entre las identidades maestras y, si declara la Opción de Coincidencia Demográfica, pedir las que más se parecen a unos datos incompletos.

Lo que un miembro declara vincula. Nunca crea una persona, nunca fusiona dos y nunca modifica lo que la identidad maestra dice de ella.

Flujo del proceso

Figura 2.5-1: Alimentación y resolución de la identidad del paciente

1. La fuente autoritativa de identidad alimenta la identidad maestra de la persona mediante ITI-93.
2. El custodio declara su identidad local mediante ITI-104 ante la infraestructura central, en su propio dominio de identificadores y con el identificador nacional de la persona. La infraestructura central comprueba que el dominio corresponde a la organización del token, y el registro de identidad maestra vincula la identidad local con la maestra. Si la persona no existe en la comunidad, rechaza la declaración e indica el motivo.
3. Un consumidor resuelve su identificador a la identidad maestra mediante ITI-83 ante la infraestructura central y, si declara la Opción de Demografía, busca por datos demográficos mediante ITI-78 o, con la Opción de Coincidencia Demográfica, mediante ITI-119.

Publicación de un documento

Descripción del caso de uso

Un laboratorio termina un resultado y lo publica en la comunidad. Envía los metadatos y conserva el documento. Desde ese momento el resultado es localizable por cualquier miembro autorizado, sin que el laboratorio deba anticipar quién lo buscará ni conocer a nadie más que a la comunidad. Lo publica con el propósito de uso de la atención, TREAT.

El laboratorio nombra al paciente con su identificador local, se nombra a sí mismo como custodio, indica dónde está el documento con una ruta relativa a su propio endpoint y etiqueta su confidencialidad. La comunidad comprueba que el laboratorio publica solo por sí mismo y solo sobre pacientes que él mismo declaró, resuelve la identidad maestra y registra el puntero. Si rechaza la publicación, dice por qué. Conviene que el laboratorio no dé por publicado un documento hasta recibir la confirmación.

Flujo del proceso

Figura 2.5-2: Publicación de un documento

1. El custodio conserva el documento en su repositorio y obtiene del Authorization Server un token para publicar.
2. El custodio publica los metadatos, agrupados en un SubmissionSet, mediante ITI-65 ante la infraestructura central. Bajo la Opción de Almacenamiento Central, incluye el contenido.
3. El Document Registry comprueba que el custodio del puntero es la organización que el token declara y que esa organización es un miembro activo según el directorio, que la URL de contenido es relativa y que el puntero lleva etiqueta de confidencialidad. Rechaza la publicación que no cumpla alguna de esas condiciones e indica el motivo.
4. La infraestructura central resuelve a la identidad maestra, mediante ITI-83, la identidad local con la que el custodio nombró al paciente, y la escribe como sujeto del puntero, que conserva también la identidad local. El Document Registry lo registra a nombre del custodio y responde. Si el paciente no resuelve a una identidad maestra, la publicación se rechaza.

Consulta del expediente por un profesional

Descripción del caso de uso

Un profesional de un hospital atiende a la misma persona y necesita su historial. Consulta la comunidad con el identificador que su propio sistema conoce de la persona, o con su identificador nacional, y con el propósito de uso de la atención habitual, TREAT. Obtiene la lista de documentos que la política le permite ver y recupera el que le interesa. No sabe, ni necesita saber, qué organización lo custodia.

La recuperación atraviesa dos tramos autorizados. El profesional llega a la comunidad con un token del solicitante, y la comunidad llega al custodio con un token intercambiado para ese único custodio, que el custodio valida por sí mismo. La sección 2.6 compara los dos tokens y dice qué lleva cada uno.

Si un custodio no responde, el profesional recibe un resultado que lo dice, junto con todo lo demás que pidió. Un custodio caído degrada la respuesta y nunca la hace fallar.

En una urgencia la historia cambia en dos puntos. El profesional consulta con el propósito de uso ETREAT, y 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. Y si la persona llega sin un identificador fiable, el hospital puede buscarla por sus datos demográficos bajo la Opción de Demografía o la Opción de Coincidencia Demográfica, como en la Figura 2.2-2. La búsqueda la habilita el scope del token, no el propósito. El propósito se evalúa después, en la decisión de divulgación.

Flujo del proceso

Figura 2.5-3: Localización y recuperación mediada

1. El consumidor obtiene del Authorization Server un token destinado al Record Locator Service y localiza mediante ITI-67. En una urgencia sin identificador conocido, busca antes a la persona por datos demográficos mediante ITI-78 o ITI-119 ante la infraestructura central.
2. El Record Locator Service comprueba el token mediante ITI-102, resuelve la identidad maestra mediante ITI-83, consulta el Document Registry mediante ITI-67, evalúa la decisión de divulgación sobre cada puntero y devuelve los divulgados, con URL de contenido que apuntan a sí mismo.
3. El consumidor recupera mediante ITI-68 sobre una de esas URL.
4. El Record Locator Service relee el puntero, vuelve a evaluar la divulgación, resuelve el endpoint del custodio en el directorio mediante ITI-90 y obtiene mediante HIX-1 un token para ese custodio.
5. El Record Locator Service recupera el documento del custodio mediante ITI-68. El custodio valida el token con las claves públicas del Authorization Server y entrega el documento, que el Record Locator Service entrega al consumidor. Bajo la Opción de Almacenamiento Central, lo recupera del Document Registry en lugar del custodio, con un token intercambiado para él.

Acceso del paciente a su expediente

Descripción del caso de uso

Una persona abre una aplicación de su elección y accede a sus propios documentos. La aplicación no la opera la comunidad y no tiene autoridad permanente sobre nada, solo lo que esta persona le concedió y mientras dure.

La persona tiene una identidad verificada ante el Authorization Server. Cómo la obtiene es política de la comunidad. Al lanzar la aplicación, el Authorization Server la autentica, resuelve esa identidad a la identidad maestra y emite un token cuyo contexto de paciente es ella misma. La aplicación no elige a qué paciente accede. El contexto viene fijado en el token y el Record Locator Service confina cada consulta a ese paciente. El propósito de uso dice quién actúa, la propia persona, un familiar que ella autorizó o su representante legal, con los códigos de la Tabla 2.2-3. A partir de ahí, sus consultas y recuperaciones son las de cualquier otro solicitante.

Este caso es el que permite a HIX servir a la persona lo que es suyo, y no solo lo que la política de la comunidad permite entre organizaciones.

Flujo del proceso

Figura 2.5-4: Acceso del paciente a su expediente

1. La aplicación del paciente inicia HIX-2. El Authorization Server autentica a la persona, obtiene su autorización para la aplicación, resuelve su identidad verificada a la identidad maestra mediante ITI-83 y emite el token con ese contexto de paciente y el propósito de uso que corresponde a quien actúa.
2. La aplicación localiza y recupera mediante ITI-67 e ITI-68 a través del Record Locator Service, que confina cada operación al paciente del contexto.

Casos previstos

Los siguientes casos forman parte de la arquitectura y se especificarán en versiones posteriores de esta guía. La arquitectura ya fija dónde se aplican y qué información necesitan.

• Consentimiento anticipado del paciente. La persona registra una directiva que permite o restringe la divulgación de sus documentos por clase de solicitante, propósito de uso, categoría de documento y ventana de validez. Se evalúa en cada operación bajo la Opción de Consentimiento.
• Administración del consentimiento desde una aplicación. La persona concede a una aplicación de su elección permiso para leer y escribir sus directivas.
• Acceso solicitado por un miembro cuando no hay directiva. Un miembro dirige a la persona al Authorization Server, que autoriza ese acceso específico. El token resultante lleva el contexto de paciente y la divulgación avanza bajo una autoridad que un momento antes no existía.
• Acceso con anulación de la política. Un profesional accede a documentos que la política ordinaria no le permitiría, declarando el propósito de uso BTG. Cómo se admite y cómo se audita lo fija cada comunidad, como indica la Tabla 2.2-3.
• Identidad del personal sanitario. El Authorization Server federa hacia el proveedor de identidad de cada institución en lugar de alojar cuentas de profesionales.

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