Arquitectura de referencia HCEN

Wiki

Arquitectura de Negocio

En la Arquitectura de Negocio para Salud, interesa particularmente identificar los actores que participan en el sistema, los roles que cumplen los mismos, las unidades organizacionales, las capacidades que brinda la plataforma (i.e. servicios de negocio) e interacciones que se realizan a través de la misma.

En esta sección se describen las principales interacciones que se dan en la Plataforma Salud.uy a través de sus diferentes servicios de negocio. Estas interacciones están basadas en el diseño de los casos de uso documentados en [16] y [17], pero con mayor nivel de abstracción, para focalizarse en qué servicios de negocio se ofrecen, cómo interactúan los distintos componentes y qué datos se intercambian.

PRINCIPIOS ESPECÍFICOS

A continuación se presentan los principios específicos para el dominio de negocio, los cuales se basan en los principios definidos en el Modelo de Referencia de Negocio (MRN).

PR-S-N-001: Perseguir objetivos estratégicos

DESCRIPCIÓN

Las actividades de negocio de las instituciones de salud, existen para cumplir con los objetivos estratégicos definidos por el Programa Salud.uy y el SNIS, según lo descrito en Contexto y Motivación.

JUSTIFICACIÓN

Este principio fomenta que las actividades de negocio de la diferentes Instituciones de Salud deben estar alineadas con los focos estratégicos definidos por Programa  Salud.Uy y el SNIS.

IMPLICANCIAS

  • Toda actividad de negocio debe estar asociada a un conjunto de requerimientos de negocio, claros y documentados. 
  • Todo cambio en una actividad de negocio debe ser a raíz de un cambio en un requerimiento de negocio, el cual debe ser gestionado y controlado, verificando que se alinee con el foco estratégico.

PR-S-N-002: Seguridad y privacidad del los procesos de negocio

DESCRIPCIÓN

Deben diseñarse controles de seguridad en el soporte de TI de cada proceso de negocio que se realice a través de la Plataforma Nacional de Salud (PNS).

JUSTIFICACIÓN

Este principio busca enfatizar en la criticidad de los procesos de negocio, dado que a través de ellos se maneja información altamente sensible. Por esta razón es necesario brindar  todas las garantías de seguridad y privacidad en el tratamiento de los mismos.

IMPLICANCIAS

  • Definir criterios de seguridad en todo el ciclo de vida de los datos clínicos gestionados a través de PNS: generación, almacenamiento, transmisión, acceso, análisis. Cualquier criterio de seguridad y privacidad debe respetar la legislación vigente sobre la protección de datos personales. 
  • Cualquier nuevo requerimiento de datos y tratamiento de los mismo debe respetar la legislación vigente sobre la protección de datos personales.

PRINCIPALES ACTORES

Los principales actores involucrados en las interacciones que se llevan a cabo a través de la Plataforma Salud.uy son los Prestadores de Salud y el Ministerio de Salud Pública (MSP).

Prestadores de Salud

Los Prestadores de Salud, tanto integrales como parciales, cuentan con sistemas de salud para gestionar la historia clínica de sus pacientes así como otra información relacionada al área de la Salud. Para dar soporte a la HCEN, los prestadores cuentan con Repositorios de imágenes y documentos clínicos. Los prestadores se conectan a la Plataforma Salud.uy a través de la RedUy utilizando el Appliance Salud.

Ministerio de Salud Pública

El MSP cuenta también con sistemas propios de uso interno así como otros sistemas que utilizan otros actores (p. ej. Certificado de Nacido Vivo Electrónico) y otros sistemas que son necesarios para la HCEN (p. ej. Registro Único de Cobertura de Asistencia Formal, RUCAF).

SERVICIOS HCEN

En esta sección se describen las interacciones de negocio que se dan utilizando los Servicios de la Historia Clínica Electrónica Nacional (HCEN) [17]. Estos servicios están fuertemente basados, en la mayoría de los casos, en las definiciones del ITI TF, introducido en el Marco Normativo Técnico

En la Tabla 6 se listan y describen los datos que se intercambian en las interacciones basadas en servicios que se detallan más adelante.

 Parámetro  Descripción 
 AA  Identificador del Prestador formado por el dominio del prestador y un OID de la aplicación.
 pacienteID  Identificador con el que el Prestador identifica al Paciente. 
 datosPatronimicos  Datos patronímicos (o demográficos) del paciente: primer nombre, segundo nombre, primer apellido, segundo apellido, documento de identidad (y/o pasaporte, y/o documento de identidad extranjero), fecha de nacimiento, sexo, dirección, teléfono, etc. 
 emisorDocumentoOID  OID que identifica al Emisor del Documento. 
 documento  Documento que identifica al Paciente según el Emisor anterior. 
 breakingTheGlass Flag utlizada para indicar que la consulta de registros o documentos clínicos se está realizando bajo un evento asistencial de   emergencia y es necesario omitir los consentimientos de acceso registrados por el paciente en cuestión.
 metadatos  Metadatos del documento clínico que se va a registrar. 
 filtros  Criterios de búsqueda para filtrar resultados. 
 CPOE  Orden de servicio. 
 docID  Identificador del documento que se quiere obtener. 
 repoID  Identificador del repositorio de documentos clínicos en donde se encuentra el documento. 
 urlImagen  URL de una imagen médica que se encuentra en un Prestador y es accesible mediante la RedSalud. 
 ticketB  Es un ticket de acceso (o "token") que permite obtener un determinado recurso (p. ej. una imagen) del Prestador "B".  
 nuevoMPIID  Identificador nacional al que se va a asociar un pacienteID. 
 viejoMPIID  Identificador nacional al que estaba asociado anteriormente un pacienteID. 
 

Tabla 6 - Datos Intercambiados en Interacciones HCEN

1) Crear o Modificar Usuario

Esta interacción es iniciada por un prestador con el objetivo de dar de alta un nuevo Usuario de Salud en la plataforma. El prestador invoca un Servicio HCEN a través del Appliance Salud. El Bus de Salud recibe la solicitud y le envía los datos al INUS. Si no existe registro de ese paciente con ese prestador, se crea un nuevo registro. Si ya existe, se actualizan los datos patronímicos. La Figura 12 presenta gráficamente esta interacción.

Figura 1 - Crear/Modificar Usuario

Figura 12 - Crear o Modificar Usuario

2) Registrar Documento

Esta interacción es iniciada por un prestador con el objetivo de registrar  los metadatos de un nuevo documento clínico en el Registro Nacional de Documentos Clínicos. Este escenario posee dos modalidades de ejecución: sincrónica y asincrónica.

La modalidad sincrónica se realiza cuando los Servicios HCEN de la plataforma se encuentran disponibles (i.e. hay conexión). En caso contrario  (i.e. no hay conexión), se realiza la modalidad asincrónica. Cuando no hay conexión la transacción se guarda en una cola para que cuando haya conexión se aplique una lógica de reintentos que ejecute todas las transacciones que se encuentran en cola.

En el caso que el paciente no exista en la plataforma (no se puede registrar un documento de un paciente que no existe) se dará de alta el paciente, utilizando los datos patronímicos proporcionados, como parte de la misma transacción. Este proceso implementa la transacción ITI-42 (“Register Document Set-b”). La Figura 13 presenta gráficamente esta interacción.


Figura 3 - Registrar Documento

Figura 13 - Registrar Documento

3) Consultar Documentos

Esta interacción es iniciada por un prestador con el objetivo de obtener los metadatos de todos los documentos clínicos asociados a un paciente. El prestador invoca un Servicio HCEN a través del Appliance Salud. El Bus de Salud le envía al INUS una consulta PIX Query (ITI-9) para obtener el identificador nacional del paciente. Una vez obtenido ested ato, envía una nueva consulta de documentos al Registro Nacional de Documentos Clínicos (XDS) con el identificador nacional del paciente, los filtros de búsqueda recibidos y la lista de convenios encontrados. El XDS resuelve la consulta y se devuelve la lista de metadatos de los documentos encontrados (no solo los documentos completos). Una vez recibidos estos datos, y teniendo en cuenta que la consulta de documentos no ocurrió bajo un evento asistencial de emergencia (breaking the glass), el BUS de Salud deberá validar contra la Plataforma de Accesos y Privacidad si existe el consentimiento del paciente para compartir estos datos con el prestador que inició el flujo. 

Esta interacción, que se presenta gráficamente en la Figura 14, se basa en la transacción ITI-18 (“Registry Stored Query””).

Figura 14 - Consultar Documentos

4) Recuperar Documento

Esta interacción es iniciada por un prestador, invocando un Servicio HCEN a través del Aplliance Salud, con el objetivo de obtener un documento clínico.

Usualmente, el usuario realizará primero la interacción Consultar Documentos a través de la cual obtendrá los metadatos de los documentos asociados a un paciente. A continuación podrá realizar la interacción Recuperar Documento para ver los detalles de alguno de ellos. Este documento estará registrado en el Registro Nacional de Documentos Clínicos y alojado en el repositorio de otro prestador. Previamente a recuperar el documento desde el prestador correspondiente, y teniendo en cuenta que el flujo para recuperar el documento no ocurrió bajo un evento asistencial de emergencia (breaking the glass),  el BUS de Salud valida contra la Plataforma de Accesos y Privacidad si existe consentimiento del paciente para acceder al documento clínico. 

Esta interacción, que se presenta gráficamente en la Figura 15, implementa la transacción ITI-43 (“Retrieve Document Set”).

Figura 15 - Recuperar Documento

5) Recuperar Imagen

Esta interacción es iniciada por un prestador con el objetivo de obtener una imagen médica (p. ej. una radiografía) que se encuentra en otro prestador.

Usualmente, el usuario realizará primero la interacción Recuperar Documento para obtener el documento clínico asociado a la imagen. Cuando obtenga el documento y lo abra, verá el vínculo correspondiente a la imagen e intentará descargar la misma para examinarla. En ese momento se realizará la interacción Recuperar Imagen que se muestra a continuación. En este caso, los componentes centrales de la Plataforma Salud.uy son utilizados únicamente para gestionar el ticket de acceso que le permitirá luego al Prestador A obtener la imagen directamente desde el Prestador B (a través de los respectivos Appliance Salud) sin pasar nuevamente por los componentes centrales. De esta manera se optimiza el tráfico de la red, teniendo en cuenta el gran tamaño en megabytes de las imágenes que se comparten. La Figura 16 presenta gráficamente esta interacción.


Figura 12 - Recuperar Imagen

Figura 16 - Recuperar Imagen

6) Consultar Golden Record

Esta interacción es iniciada por un prestador con el objetivo de obtener los mejores datos que se tengan en la plataforma de un paciente. El “Golden Record” es un registro en donde cada campo posee los datos de mayor confianza.

El prestador invoca un Servicio HCEN a través del Appliance Salud. El Bus de Salud le envía la consulta al INUS, el cual obtiene para cada campo los datos de las fuentes de mayor confianza (p. ej. un mismo paciente podría tener diferentes direcciones según diferentes fuentes). Luego el Bus de Salud consulta un servicio Web del RUCAF para obtener datos de afiliaciones (i.e. coberturas médicas) que posee ese paciente y con esos datos se complementa el Golden Record. La Figura 17 presenta gráficamente esta interacción.


Figura 13 - Consultar Golden Record

Figura 17 - Consultar Golden Record

7) Vincular/Desvincular Usuario

Esta interacción es iniciada en el INUS cuando se realiza una vinculación de usuarios (merge), es decir, cuando se detecta que la misma persona estaba registrada con dos identificadores de paciente distintos, o una desvinculación de pacientes (unmerge), cuando se detecta que un mismo identificador de paciente está asociado a dos personas diferentes.

Esta interacción, que se presenta gráficamente en la Figura 18, utiliza la transacción ITI-10 (“PIX Update Notification”).


Figura 14 -Vincular/Desvincular Paciente

Figura 18 - Vincular/Desvincular Pacientes

SERVICIOS COMPLEMENTARIOS

Servicios Terminológicos

El uso de los Servicios Terminológicos (ST) es esencial dentro del desarrollo de HCEN dado que apunta a fortalecer la calidad semántica de los datos registrados durante el acto asistencial. Por ejemplo, se pueden registrar los problemas de salud o diagnósticos planteados a un paciente durante una consulta, así como también los procedimientos o tratamientos que le son indicados. En estos casos, la implementación de los ST, permite que la información clínica que se registre se haga de forma estructurada, mediante un estándar de terminología clínica internacional (SNOMED-CT) que garantiza, por un lado la interoperabilidad semántica necesaria y por otro, que la información guardada pueda ser re-utilizada con otros fines (p. ej. soporte a decisiones, gestión, investigación), gracias al mapeo existente con algunas clasificaciones internacionales como la CIE-10, CIE9-MC y ATC, entre otras.

En la Figura 19 se presenta la interacción de negocio “Búsqueda Terminológica” que generaliza un subconjunto de operaciones ofrecidas por los ST, orientadas a la búsqueda de términos que poseen los datos de entrada descriptos en la Tabla 7.


Figura 15 - Búsqueda Terminológica

Figura 19 - Búsqueda Terminológica


 Parámetro  Descripción 
 término  Término en texto libre del que se quieren buscar textos estandarizados que estén relacionados y sus correspondientes códigos (p. ej. “lumbalgia”).
 dominioID  Identificador del dominio al que pertenece el término buscado. Los dominios posibles son “Problemas” (dominioD=601000999132) y “Procedimientos” (dominioID= 631000999139).
 prestadorID  Identificador del prestador de salud.

Tabla 7 - Datos de Entrada de Búsqueda Terminológica

Las operaciones ofrecidas por el ST son las siguientes:

  • Obtener Oferta de Textos: Esta operación permite obtener una lista de términos y sus correspondientes códigos, relacionados con el término ingresado.
  • Obtener Código de Tesauro: Esta operación permite obtener el código del término ingresado. Si el término ingresado no existía, se genera un código nuevo para ese término. Por esta razón, se recomienda que se ejecute primero la operación “Obtener Oferta de Textos” para comprobar si existe un término equivalente ya codificado.
  • Obtener Prompting: Esta operación permite obtener una lista de los cinco primeros textos que contienen el texto ingresado. Es utilizado usualmente para autocompletar un campo con textos sugeridos cuando el usuario ya ingresó al menos tres caracteres del término. El orden de aparición de los textos está dado por la fre­cuencia de uso.
  • Obtener Oferta Similitud: Esta operación permite obtener una lista de términos parecidos al término ingresado, ordenados según el grado de similitud. Es posible ingresar términos con errores y que el servicio reconozca el término correcto.