Arquitectura de Negocio - Inicio - Arquitectura Salud.uy

Dentro de la arquitectura de negocio de la Plataforma Nacional de Salud, interesa particularmente identificar los actores que participan, los roles que cumplen los mismos, las unidades organizacionales, las capacidades que posee 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 PNS a través de sus diferentes servicios de negocio. Estas interacciones muestran, con alto nivel de abstracción, qué servicios de negocio se ofrecen, cómo interactúan los distintos componentes y qué datos se intercambian.

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). Estos servicios están fuertemente basados, en la mayoría de los casos, en las definiciones del ITI TF, introducido en la Sección 6.

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

Tabla 2 - 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 Conector Salud.uy. 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 7 presenta gráficamente esta interacción.

Figura 7 - Crear o Modificar Usuario

2) 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 Conector Salud.uy. 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 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 8 presenta gráficamente esta interacción.

Figura 8 - Consultar Golden Record

3) Registrar Documento

Este proceso es iniciado por un Prestador con el objetivo de registrar los metadatos de 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 el servicio de la plataforma se encuentra disponible (hay conexión). La modalidad asincrónica se realiza cuando la plataforma no se encuentra disponible (no hay conexión). Cuando no hay conexión la transacción se guarda en una cola para que luego se aplique una lógica de reintentos que ejecute todas las transacciones que se encuentran en cola cuando haya conexión. 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”).

Figura 3 - Registrar Documento

4) Consultar Documentos

Este proceso es iniciado por un Prestador con el objetivo de obtener los metadatos de todos los documentos clínicos asociados a un Paciente. El Bus de la plataforma le envía al INUS una consulta PIX Query (ITI-9) para obtener el identificador nacional del paciente. Luego el Bus busca si existen convenios con el prestador y 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). Este proceso se basa en la transacción ITI-18 (“Registry Stored Query””).

Figura 4 - Consultar Documentos

5) Recuperar Documento

Este proceso es iniciado por un Prestador con el objetivo de obtener un documento clínico. Usualmente, el usuario realizará el proceso de Consultar Documentos, en donde verá los metadatos de los documentos asociados a un paciente, y a continuación realizará el proceso de 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. Este proceso implementa la transacció ITI-43 (“Retrieve Document Set”).

Figura 5 - Recuperar Documento

6) Vincular/Desvincular Pacientes

Este proceso es iniciado dentro del INUS cuando se realiza una vinculación de usuarios (merge), es decir, cuando se detecta que la misma persona estaba registrado con dos identificadores de paciente distintos, o una desvinculación de pacientes (unmerge), cuando se detecta que un mismo identificador de paciente está asociado dos personas diferentes. Este proceso utiliza la transacción ITI-10 (“PIX Update Notification”).

Figura 6 - Vincular/Desvincular Pacientes

Servicios Terminológicos

El uso de los servicios terminológicos (ST) es para el Programa Salud.uy un componente esencial dentro del desarrollo de la Historia Clínica Electrónica Nacional (HCEN), pues su implementación se orienta a fortalecer la calidad semántica de los datos registrados durante el acto asistencial. Podemos citar como ejemplo de casos de uso: el registro de 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 (soporte a decisiones, gestión, investigación, etc.), gracias al mapeo existente con algunas clasificaciones internacionales como la CIE-10, CIE9-MC, ATC entre otras.

En la Figura 7 se muestra el proceso de negocio “Busqueda Terminológica” que generaliza un subconjunto de operaciones ofrecidas por los ST, orientadas a la búsqueda de términos que poseen los mismos datos de entrada (Tabla 3). Estas operaciones 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.

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

Figura 7 - Búsqueda Terminológica