Arquitectura de Aplicaciones - Inicio - Arquitectura Salud.uy

La Arquitectura de Aplicaciones se centra en las aplicaciones de software que dan soporte a los requerimientos de negocio del área de la salud en Uruguay. Esta arquitectura se basa en el Modelo de Referencia de Aplicaciones (MRA) de la Arquitectura Integrada de Gobierno.

PRINCIPIOS ESPECÍFICOS

Los principios específicos para el dominio de aplicaciones toman como base los principios definidos en el MRA y los especializa para el área de la salud.

PR-S-A-001: Estrategia de interoperabildiad

DESCRIPCIÓN

Las aplicaciones deben estar alineadas a la estrategia de crecimiento del área de la salud en Uruguay así como facilitar los servicios compartidos y la interoperabilidad.

JUSTIFICACIÓN

Este principio busca establecer que todas las aplicaciones del ecosistema de salud, ya sean de Instituciones de Salud como de plataformas compartidas, deben definirse fomentando la interoperabilidad de las mismas.

IMPLICANCIAS

• Contar con una definición clara de la arquitectura de integración e interoperabilidad de los diferentes actores del ecosistema de salud.
• Establecer estándares de interoperabilidad de Sistemas de información de salud
• Establecer estándares de seguridad, autenticación, autorización, auditoría, para todo el esquema de interoperabildiad de sistemas de información de salud.
• Facilitar las herramientas para que cualquier Institución de Salud pueda integrarse e interoperar con el ecosistema de salud.

PR-S-A-002: Foco en las necesidades de negocio del territorio uruguayo

DESCRIPCIÓN

Las aplicaciones deben existir para satisfacer necesidades de negocio puntuales del área de la salud en Uruguay.

JUSTIFICACIÓN

Este principio busca restringuir los requerimiento de las aplicaciones del ecosistema de salud, únicamente para lograr dar soporte a la historia clínica electrónica nacional (HCEN) en el territorio uruguayo.

IMPLICANCIAS

• Contar con requerimientos funcionales y no funcionales claros y bien documentados

PR-S-A-003: Diseño de calidad

DESCRIPCIÓN

El diseño de las aplicaciones debe promover la facilidad de uso, la accesibilidad, la protección de datos personales y el análisis de información.

JUSTIFICACIÓN

Este principio busca promover los principales atributos de calidad que se esperan tenga las aplicaciones del ecosistema de salud en Uruguay.

IMPLICANCIAS

• Definir y promover recomendaciones y buenas prácticas para el diseño de aplicaciones fomentando su facilidad de uso y accesibilidad.
• Promover que todas la aplicaciones respeten la ley vigente de protección de datos personales.
• Definir y promover buenas prácticas para el análisis de datos clínicos.

PR-S-A-004: Diseño opensource

DESCRIPCIÓN

En el diseño de aplicaciones se deberá ponderar el uso de estándares abiertos y software libre.

JUSTIFICACIÓN

Este principio busca establecer un diseño de aplicaciones sin licenciamiento que permita la reutilización y extensión de ellas, bajo una comunidad de desarrollo opensoruce.

IMPLICANCIAS

• Definir estándares abiertos
• Definir y promover el uso de software libre
• Generar comunidad de desarrollo

PR-S-A-005: Integración con externos

DESCRIPCIÓN

El diseño de las aplicaciones debe contemplar la integración con sistemas externos de forma estándar.

JUSTIFICACIÓN

Este principio busca unificar las integraciones entre los sistemas internos y externos.

IMPLICANCIAS

• Definir y especificar estándares y guías de integración

PR-S-A-006: Integración estándar

DESCRIPCIÓN

Las aplicaciones que se integren a la Plataforma Nacional de Salud (PNS) deben respetar el Marco Normativo Técnico establecido por Salud.uy, en particular, deben ajustarse a los estándares, especificaciones, guías y perfiles de integración definidos.

JUSTIFICACIÓN

Este principio busca alinear a los diferentes actores de salud en la construcción colectiva que permita homogeneizar la integración e interacción de las aplicaciones en el ecosistema de salud.

IMPLICANCIAS

• Definir y especificar estándares y guías de integración.
• Definir y especificar criterios para homologar aplicaciones que formen parte del ecosistema de salud.

CARACTERIZACIÓN DE APLICACIONES

En el marco de la PNS se utilizan distintas aplicaciones que pueden caracterizarse por el actor responsable (p. ej. Salud.uy, MSP), tipo de aplicación (p.ej. Servicio, Librería) y la ubicación física en la que se ejecutan (p. ej. AGESIC, Prestadores de Salud, MSP). La Tabla 8 presenta los principales tipos de aplicaciones que se utilizan en el marco de la PNS.

Tabla 8 - Tipos de Aplicaciones

Las aplicaciones de la PNS deben respetar además el Marco Normativo establecido por Salud.uy. En particular, estas aplicaciones deben ajustarse a los estándares y perfiles de integración presentados en la sección Marco Normativo.

En las siguientes secciones se presentan, caracterizan y describen varias de las aplicaciones de la PNS organizadas de acuerdo a su actor responsable.

APLICACIONES EN PLATAFORMA SALUD.UY

Las aplicaciones en la Plataforma Salud.uy tienen diversos objetivos entre los que se destacan: dar soporte a la HCEN y brindar acceso a servicios externos. La Tabla 9 presenta un listado de las principales aplicaciones provistas en la Plataforma Salud.uy.

Tabla 9 - Aplicaciones en Plataforma Salud.uy

Los Servicios HCEN son un conjunto de servicios Web que brindan operaciones para dar soporte a la HCEN. Algunas de las operaciones de estos servicios son: Crear / Modificar Paciente, Registrar Documento, Consultar Documentos y Recuperar Documento. Estas operaciones se ajustan a lo establecido en los perfiles XDS.b y PIX de la IHE. En el Documento de Arquitectura HCEN [17] se brinda más detalle de estos servicios y operaciones (p. ej. parámetros de entrada y salida).

Los Servicios Terminológicos son un conjunto de operaciones expuestas a través de un servicio Web que brindan acceso al servidor terminológico del Hospital Italiano de Buenos Aires (HIBA). En la Guía técnica de Servicios Terminológicos [13] se brinda más detalle de estas operaciones y cómo accederlas.

APLICACIONES SALUD.UY DE SOPORTE

Salud.uy ha desarrollado y puesto a disposición de las instituciones de salud varias aplicaciones de soporte que apuntan a facilitar la integración de las instituciones con la plataforma. La Tabla 10 presenta un listado de las principales aplicaciones de soporte brindadas por Salud.uy.

Tabla 10 - Aplicaciones de Salud.uy de Soporte

El Registro / Repositorio XDS provee a los prestadores un Registro / Repositorio de documentos clínicos que se ajusta a lo establecido en el perfil XDS.b de la IHE. En el Documento de Arquitectura XDS [19] se puede obtener más información de este componente, el cual está disponible para ser descargado en el Repositorio de Recursos de Salud.uy.

Las librerías que provee Salud.uy apuntan a facilitar distintos aspectos en la integración de los Prestadores de Salud con la Plataforma Salud.uy. Las librerías están disponibles para descargar en el Repositorio de Recursos de Salud.uy.

APLICACIONES COMO SERVICIO Y SISTEMAS VERTICALES

La Tabla 11 presenta un listado de aplicaciones como servicio y sistemas verticales que brinda la PNS.

Tabla 11 - Aplicaciones como Servicio y Sistemas Verticales

La Historia Clínica Electrónica Oncológica (HCEO) es un sistema de información que contribuye a mejorar la atención médica del paciente oncológico, integrando la información clínica de todas las organizaciones que participan en el proceso asistencial de estos pacientes, independientemente de su localización geográfica. La cobertura de HCEO es de alcance nacional e incorpora los protocolos y pautas de prevención, diagnóstico y tratamiento de las enfermedades oncológicas elaboradas por los departamentos de Oncología Clínica y Radioterápica. El desarrollo de la HCEO se realizó a instancias de la Comisión Honoraria de Lucha contra el Cáncer (CHLCC), el Departamento de Oncología Radioterápica del Hospital de Clínicas y de los servicios oncológicos de la Asociación Española.

La Red Integrada de Diagnóstico por Imagen (RIDI) es un sistema de teleimagenología que facilita la complementación de servicios de imagenología médica de las instituciones adheridas y permite mejorar la gestión del flujo de trabajo de un servicio de diagnóstico por imagen. El sistema permite registrar toda la información relacionada con el proceso de imagenología que pueda ser de utilidad en los procesos asistenciales actuales y futuros, tanto dentro de la misma institución o de forma remota.

APLICACIONES MSP

Las aplicaciones que provee el MSP cubren distintos requerimientos del área de la salud en Uruguay como la gestión de información de afiliaciones de usuarios a prestadores y el soporte a los certificados de nacido vivo y defunción electrónicos. La Tabla 12 presenta un listado de las principales aplicaciones provistas por el MSP.

Tabla 12 - Aplicaciones MSP

El proyecto RUCAF en Línea [2] incluye la modernización tecnológica, la modernización operativa y la ampliación funcional del actual sistema RUCAF, así como la provisión de servicios de mantenimiento y de soporte. Tiene como objetivos principales incorporar datos de afiliados y afiliaciones en línea con los mecanismos de control necesarios, favoreciendo la accesibilidad de los interesados dentro del sistema y brindar una identificación única de los usuarios del SNIS mediante la implementación de un protocolo de interoperabilidad entre el RUCAF, el Índice Maestro de Pacientes y el acceso a la Dirección Nacional de Identificación Civil (DNIC), indispensable para la implantación de la HCEN.

La Historia Clínica Perinatal Electrónica (HCPe) es un sistema informático que está diseñando sobre la base del actual Sistema de Información Perinatal (SIP), desarrollado por el Centro Latinoamericano de Perinatología (CLAP) [20]. El sistema permite tener información oportuna sobre la gestación y aporta formas efectivas de comunicación con las embarazadas. Tiene prevista la posibilidad de enviar alertas en forma automática, vía mail y teléfono celular, a los profesionales actuantes en cada caso, así como emitir recordatorios de consultas de control a las embarazadas.

El Certificado de Nacido Vivo (CNV) es un certificado que se expide a todo recién nacido con signos vitales que es emitido por el MSP y debe ser firmado por el médico o partera que asistió en el parto. El sistema Certificado de Nacido Vivo Electrónico (CNVe) da soporte a todo el proceso de generación de un CNV electrónico (CNV-e) que incluye, por ejemplo: i) el registro / actualización de los datos de la madre en el sistema, ii) el ingreso de los datos del parto y del recién nacido así como la firma electrónica por parte del médico o partera, y iii) la emisión del comprobante para su presentación en la Dirección General del Registro de Estado Civil (DGREC).

El Certificado de Defunción (CD) es un certificado emitido por el MSP que se expide ante todo fallecimiento y debe ser firmado por el médico tratante o, en caso de muertes violentas o sospechosas, por un médico forense. El sistema Certificado de Defunción Electrónico (CDe) da soporte a todo el proceso de generación de un CD electrónico (CNV-e) que incluye, por ejemplo: i) la firma electrónica de los certificados por parte de los médicos, ii) la realización de enmiendas en los certificados, iii) la impresión de certificados resumidos para su posterior envío a la DGREC, y iv) la codificación de la principal causa de muerte utilizando CIE-10.

El MSP también provee otras aplicaciones como el Sistema Informático de Vacunas, Registro de Malformaciones Congénitas, Pesquisa Neonatal (estudios metabólicos, sordera congénita y ecografía de cadera) y el Carnet del niño/niña.

ARQUITECTURAS DE REFERENCIA

Esta sección presenta arquitecturas de referencia para la utilización de algunas de las aplicaciones descriptas previamente por parte de los Prestadores de Salud. En particular, se presenta cómo los prestadores pueden utilizar distintas aplicaciones para lograr la integración con la Plataforma Salud.uy y, de esta forma, poder hacer uso de las aplicaciones que ésta provee (p. ej. Servicios HCEN, Servicio Terminológicos).

Integración de Prestador con Repositorio a la Plataforma Salud.uy

La Figura 20 muestra la arquitectura de referencia para la integración con la Plataforma Salud.uy de un Prestador de Salud que ya cuenta con un Repositorio de documentos clínicos.

Figura 20 - Integración de Prestador con Repositorio a Plataforma Salud.uy

A la izquierda de la Figura 20, se muestra la situación inicial del prestador donde personal del prestador interactúa con un HIS y el HIS almacena documentos clínicos en un Repositorio.

Por otro lado, a la derecha de la Figura 20 se muestra el uso del Appliance Salud para lograr la integración con la Plataforma Salud.uy. Esta integración permite que un HIS pueda invocar, a través del Appliance Salud, los servicios que ofrece esta plataforma (p. ej. Servicios HCEN, Servicios Terminológicos). La integración también permite que otros prestadores recuperen documentos clínicos almacenados en el Repositorio del prestador a través del Appliance Salud. Se requiere que el prestador cuente con un Certificado Electrónico de Persona Jurídica para que el Appliance Salud pueda realizar la autenticación con la Plataforma de Interoperabilidad (PDI), a través de la cual se exponen los servicios ofrecidos por la Plataforma Salud.uy.

Integración de Prestador sin Repositorio a la Plataforma Salud.uy

La Figura 21 muestra la arquitectura de referencia para la integración con la Plataforma Salud.uy de un Prestador de Salud que no cuenta con un Repositorio de documentos clínicos.

Figura 21 - Integración de Prestador sin Repositorio a Plataforma Salud.uy

A la izquierda de la Figura 21, se muestra la situación inicial del prestador donde personal del prestador interactúa con un HIS.

Por otro lado, a la derecha de la Figura 21 se muestra el uso del Appliance Salud y el Registro / Repositorio XDS provisto por Salud.uy para lograr la integración con la plataforma. El Prestador de Salud deberá almacenar los documentos clínicos que custodia en el Repositorio XDS, lo que requerirá alguna forma de interacción entre el HIS y este componente.

De la misma forma que en la arquitectura de referencia anterior, la integración del prestador con la Plataforma Salud.uy posibilitará distintas interacciones entre el prestador y la plataforma a través del Appliance Salud. También en este caso se requiere que el prestador cuente con un Certificado Electrónico de Persona Jurídica.

Generación y Firma de Documentos CDA

La Figura 22 muestra la arquitectura de referencia para la generación y firma de documentos CDA por parte de los prestadores utilizando las librerías provistas por Salud.uy.

Figura 22 - Generación y Firma de Documentos CDA

En particular, el Prestador de Salud utiliza la librería Generación CDA para generar documentos CDA (1) y luego utiliza la librería Firma CDA (2) para firmarlos digitalmente (2). Esto último requiere que el prestador cuente con un Certificado Electrónico de Persona Jurídica. El documento CDA firmado puede ser luego almacenado (3) en un repositorio de documentos clínicos (p. ej. el provisto por Salud.uy).