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 Master Patient Index. El custodio que la atiende declara a la comunidad qué identidad local le corresponde. El Master Patient Index vincula esa identidad con la identidad maestra y, desde entonces, los documentos que ese custodio publique sobre esa persona quedan asociados a la misma identidad maestra 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 el Master Patient Index, en su propio dominio de identificadores y con el identificador nacional de la persona. El Master Patient Index comprueba que el dominio corresponde a la organización del token y vincula la identidad local con la maestra. Por defecto, si la persona no tiene identidad maestra, rechaza la declaración e indica el motivo, como explica la sección 2.2.
3. Un consumidor resuelve su identificador a la identidad maestra mediante ITI-83 ante el Master Patient Index 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 el identificador nacional de la persona y con el MRN que él mismo declaró, 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 el Document Registry. 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. El Document Registry resuelve a la identidad maestra, mediante ITI-83, el identificador nacional con el 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, o el custodio no declaró esa identidad local, 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 mediado 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 el custodio de un documento no responde, esa recuperación lo indica, sin que se confunda con un documento inexistente. La localización y las demás recuperaciones no se ven afectadas.

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 cuya audiencia incluye 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 el Master Patient Index.
2. 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.
3. El consumidor recupera mediante ITI-68 sobre una de esas URL.
4. El Record Locator Service relee el puntero y vuelve a evaluar la divulgación. Cuando el contenido queda en el custodio, resuelve su endpoint 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 mediado 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, normalmente la propia persona, con el código PATRQT de la Tabla 2.2-3. La comunidad decide si un familiar o un representante legal puede actuar en su nombre, y en qué condiciones. 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-66, 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 lo fija cada comunidad, como indica la Tabla 2.2-3. HIX ya exige que quede registrado en la auditoría, como fija la sección 2.6.
• Identidad del personal sanitario. El Authorization Server federa hacia el proveedor de identidad de cada institución en lugar de alojar cuentas de profesionales.