Agenda Appliance PS Contexto

Presentación del tema: "Agenda Appliance PS Contexto"— Transcripción de la presentación:

1 Agenda Appliance PS Contexto
El Sistema Nacional Integrado de Salud (SNIS) Conceptos Fundamentales Red Federada de eSalud Platforma eSalud Componentes Principales Appliance PS First, we will describe the current context of the Nationwide Healthcare system in Uruguay. Next, we will see an outline of the eHealth Federated Network, and the description of the e-Health Platform Then, we will see some example scenarios, and finally we will talk about the next steps and conclusions of the work done. Escenarios Evolución Conclusiones

2 Participación Ciudadana Acceso a la Información
Identidad Eletrónica Internet Para todos Salud Protección de Datos Personales Educación Equidad Sistema de Cuidados Plan Ceibal Participación Ciudadana Seguridad Social Vivienda Seguridad Firma Electrónica Cultura Acceso a la Información Trámites y Servicios Energía Inclusión Social

3 Contexto El Sistema Nacional Integrado de Salud (SNIS)
MSP Comprehensive Healthcare Providers Partial Healthcare Providers The Nationwide Integrated Healthcare System (SNIS in Spanish) from Uruguay has the following features: gives universal coverage, is tax-financed, and services are delivered by a network of healthcare providers. One provider is public and the others are private. They may give full or partial care, depending on the services they deliver. Users form the core and backbone of this healthcare system. The user is entitled to choose freely a healthcare comprehensive institution. The relationship user-institution shall last, at least, 3 years, and the SNIS is aware of this affiliation. Each individual may receive health care from another institution, different from the healthcare provider to which is affiliated. Apart from comprehensive healthcare providers, there are partial providers, such as private medical labs, imaging clinics, non-hospital emergency services, private physician offices or office networks, among others, which are authorized and operate under regulations issued by the Ministry of Public Health (MSP in Spanish), but are not part of the SNIS. Those service providers also produce relevant medical information which must be considered by the Nationwide Electronic Health Record System (HCEN in Spanish). Usually, people are affiliated to one comprehensive healthcare provider and to one mobile emergency service. Also, individuals use to undergo medical examinations in private offices. Pharmacy networks must also be considered.

4 Contexto Conceptos Fundamentales
Cada proveedor tiene su propio sistema de HCE en diferentes niveles de desarrollo, estandarización, alcance y madurez. La complementación de servicios, requiere, al menos, integración de aplicaciones Los pacientes están afiliados a un proveedor integral de salud, esta institución es responsable por su cuidado y actúa como custodio de su Historia Clínica (ley SNIS) Los pacientes se atienden en más de un proveedor de salud, requiere interoperabilidad a nivel de HCE, Id Pacientes, etc. La plataforma de salud debe facilitar el acceso a servicios centrales del MSP (Aplicaciones, diccionarios, tablas y servicios) Main services such as: vaccines, master tables, dictionaries, terminology services, vademecum, others. Ver concepto de dominio de afinidad

5 Premisas básicas Federación con niveles altos de garantía de calidad (Servicios, Datos: Integridad, Completitud, Calidad, Seguridad) Los documentos clínicos no deben estar centralizados Se requiere servicios centrales (MPI, Terminología, Catálogos, Vacunaciones, Nacidos vivos, Carnets niño.., etc. Se requiere acceso a todos los registros médicos con independencia del lugar de atención Se requiere capacidad de análisis de datos por parte del MSP Asegurar continuidad de servicios locales y entrega de información a la red Proteger los desarrollos locales de cada prestador, frente a los cambios y definiciones en el proceso de estandarización. No debe provocar que se tire lo que funciona. Main services such as: vaccines, master tables, dictionaries, terminology services, vademecum, others. Ver concepto de dominio de afinidad

6 ESTANDARIZACIÓN Reducción de Costos Concepción SOA Seguridad
Protocolos Semántica Operativa Gobernanza Reducción de Costos Economías de escala Facilidades de implementación Administración y monitoreo Disponibilidad, SLA Concepción SOA Reutilización de servicios Arquitectura flexible Capacidades de Integración Marco Legal Marco Normativo Técnico

7 Tecnológicos 03/2008 Plataforma de Gobierno electrónico “Los productos y servicios a adquirir en estas licitaciones conformarán el núcleo de la plataforma de Gobierno Electrónico del Estado Uruguayo. En el futuro ser irán realizando otras licitaciones públicas para incorporar funcionalidades específicas a esta plataforma, tal será el caso del Root CA (Autoridad Certificadora Raízdel Estado Uruguayo); de un sistema central de expediente electrónico; del broker de expediente electrónico; de un Business Process Manager (BPM); del broker de HL7; del sistema de trazabilidad de trámites, expedientes y procesos de negocios; entre otros. La plataforma de middleware debe ser integrable con mecanismos de seguridad que proveerán facilidades de Identificación y Autenticación Federadas en general, y de Single-Sign On para las aplicaciones que se ejecuten en la plataforma de Middleware. Asimismo, debe ser integrable con servicios de Metadatos y Catálogos de información …” 03/2008, Red.uy “Crear una infraestructura de conectividad para que todas las entidades del Estado estén interconectadas de manera segura, con adecuados niveles de servicio, de seguridad informática y alta disponibilidad.” En el futuro ser irán realizando otras licitaciones públicas para incorporar funcionalidades específicas a esta plataforma, tal será el caso del broker de HL7 ……

8 Caso Salud Encapsulando más complejidades
Mensajería IHE – XDS Servicios Terminológicos Firma electrónica Avanzada Suscripción a servicios asociados a información clínica de pacientes Sincronización con plataforma local Manejo de fallas en la comunicación y gestión de recuperación y reintentos

9 salud.uy Arquitectura de referencia
Framework Salud: Marco Técnico y Legal XDS Efectores Profesionales S.Terminológicos HCE básica PAC’s /RIS Prestadores Medicamentos Financiadores Prestaciones Sistemas para la Complementación HCE-O Insumos Servicios Fundacionales SaaS Plataforma Salud Gestor Perfiles Salud Gestor Novedades (suscripción)Usuarios Salud Consentimientos Salud Índice Actos Clínicos (XDS) ESB Salud Registro Usuarios Salud Repositorio Salud (XDS) Mencionar el tema de domicilios Plataforma de Gobierno Electrónico / Plataforma Interoperabilidad

10 Red Salud – Esquema de Conectividad -

11 Red Federada de Salud Platform eHealth Red Salud Red Salud
Emergency Services Public Hospitals Red Salud Imagenology Services eHealth Platform Doctors & Small Clinics Clinical Laboratories Private Hospital The e-Health Platform consists of hardware and software intended to ease the interoperation of health information among different stakeholders, allowing the creation of a nationwide e-health record. This platform is the core component of the federated network, formed by healthcare institutions which are part of the SNIS, the Ministry of Public Health or some other networks (drugstores, emergency services, private imaging clinics, labs, others). This federation creates a relationship of trust among systems which are part of it, and allows the complementation of services required by the SNIS. The point of access to this platform as well as all the comunications between healthcare institutions is RedSalud.Uy, a high-speed private and secure network. Red Salud DrugStores Private Hospitals Ministry of Public Health

12 Componentes Principales de la PS
This chart shows the main components of the e-Health Platform, and the different components of the solution. The component is the EMPI; a repository of healthcare users, including patient’s identifiers from all healthcare institutions where he or she is affiliated. It is important to note that chances to find repeated users are reduced through the use of complex algorithms. The HCEN Registry contains metadata needed to locate clinical records related to certain patient. NST-PS (non-standard transactions) is aimed at performing non-standard changes in clinic records, in order to ease the integration with previous systems. Finally, ESB-PS is aimed at changing interoperability protocols and standards used at a governmental level into protocols and standards used at healthcare level, which not always are the same. Those components use different services provided by the e-Government Platform; for instance, IaaS services (because the whole infrastructure is cloud-based in Presidency), access control, and specifically, they use the Interoperability Platform, which has certain features that are used by the e-Health Platform. They are the following: - Access control through the application of AAA policies on transactions. - Middleware platform that allows routing messages and ease publishing and using changes related to e-health records. - Metadata that allows semantic interoperability. - Finally, the interoperability platform provides a legal framework for all transactions, because they are signed using institution’s legal entity certificates. There is also a SaaS layer (Software as a Service) that includes different services of the e-health network: central services of the Health Ministry, terminology, data dictionaries, oncology e-health records, appointment system, etc. Finally, there are health care providers that have their own computing systems (on management, appointments, specialized lab repositories, xds, imaging, among others). The challenge is to allow those systems to interoperate with the e-Health Platform, using the proper standards. To ensure interoperability we designed the “Appliance PS”, a hardware and software component aimed at enabling interoperability among those components and the components of the e-Health Platform. It will be described in detail in the next slide.

13 Appliance PS Web Service Layer PACS Integration Service
App Server PS Integration Logic Web Service Layer Digital Signature Service Scheduled Processes Message Queue Publish & Subscribe Services PACS Integration Service IHE/HL7 Integration System Other Services The appliance was created because it was needed to solve the complexity of the interoperation between systems that are very different and also are in different stages of maturity. At the same time, it allows adding previous systems to e-health records. This slide shows the main components of the Appliance PS. Web Service Layer: states the point of contact from and to the e-Health Platform, enables publishing and using web services required for interoperation. PS Integration Logic is an integration layer, affecting all other components, which contains the logic needed to perform integrations from and to the e-Health Platform, in particular, it contains the logic needed to comply with authentication and authorization procedures required by the e-Government Platform. This set of modules perform main features of this component: - Integration with imaging systems (DICOM) - Integration systems based on HL7 messages and IHE protocols. - Scheduled processes to sincronize appointments. - Digital signature of health records - Publish & Subscribe, key services to keep updated e-health records within each healthcare institution. - Services to retry communication in case the connection is interrupted. Finally, there is an “App Server” layer, intended to include specific adapters to perform integration with internal and external systems. It allows regular integrations and particular cases with each provider. Providers that have this component will maintain and manage this layer. Specific modules and the App Server layer may be extended through different plugins. In the next slide we will see an example showing the interactions that occur within this component and other components of the eHealth Platform and provider’s local systems.

14 Escenario 1 Paciente se atiende en su institución
My Health Provider Health Platform Retreive History If Pending Notifications PGE ESB PS EMPI APPLIANCE PS Retreive Pending Notifications REGISTRY Retreive History Retreive History Other Health Provider APPLIANCE PS XDS This example shows the communications that occur when the patient receives care from the health care provider he or she is affiliated to. - First, provider’s system requests to the XDS local medical information stored in specialized repositories. - After that, the system checks the “Appliance PS” to know if there are pending notifications related to the patient. If yes, it requests the records to be updated. - Then, the e-Health Platform requests the records to the respective providers, in order to return them to the original healthcare provider. XDS IMG HCE LIS

15 Escenario 2 Paciente se atiende en otra institución
Other Health Provider eHealth Platform PGE ESB PS Retrieve Patient Id’s EMPI APPLIANCE PS Retrieve History Retrieve History Notify Update Get Documents Location REGISTRY Retrieve History Retrieve Documents Notify Update Update History Retrieve Documents Notify Update My Health Provider APPLIANCE PS XDS This example shows the interactions that occur when a patient receives care from a provider different from the one he or she is affiliated to. - First, the system of the healthcare institution sends a message to the Appliance asking for the records associated to this patient. - The appliance sends this request to the ESB-PS through the e-Government Platform. - The ESB requests to the EMPI the patient’s ID associated to the health care institution the patient is affiliated to; after that, looks up in the Registry to know the location of patient’s health records. - Then, the ESB requests the records associated through the e-Government Platform; the healthcare provider receives those records from the XDS, through the Appliance. After that, records are returned to the provider that submitted the first request. - When the physician performs a medical procedure to this patient, the system will give notice to the provider the user is affiliated to, referred to the record update, so the institution may request the respective updates. Retrieve Documents XDS IMG HCE LIS

16 Otros casos de Uso Imagenología
Como intercambio de Imágenes e informes en el proceso de atención Como complementación de servicios (Diagnóstico Remoto) Como Tercerización de servicios (Agenda, Informes e imágenes) here you can see the next steps we are going take in order to evolve e-Health Platform

17 Otros casos de Uso Imagenología
here you can see the next steps we are going take in order to evolve e-Health Platform

18 Otros casos de Uso Draft Imagenología – Tercerización completa -
here you can see the next steps we are going take in order to evolve e-Health Platform

19 Otros casos de Uso Draft Imagenología – consumo -
here you can see the next steps we are going take in order to evolve e-Health Platform

20 En qué estamos Documentación del diseño y especificación de componentes a ser adquiridos o desarrollados EMPI y ESB salud Adjudicados, proveedores trabajando Pilotos funcionando: XDS, Appliance PS PGE y servicios 100% operativos Red en proceso de despliegue El desarrollo y la definición de tablas, diccionarios, catálogos, conjunto de datos mínimos, actualización de regulaciones del MSP, entre otros requerimientos contribuirá a la evolución continua del modelo Cada proveedor de salud deberá continuar con sus desarrollos conforme a las normas y plan de adopción Se realizó un conectaton exitoso here you can see the next steps we are going take in order to evolve e-Health Platform

21 En qué estamos El Appliance PS será suministrado bajo modalidad a definir. Los proveedores de salud deberán integrarlo a su plataforma. Los servicios del Appliance se incorporarán en forma gradual. Se implementarán servicios bajo la modalidad SaaS para facilitar el acceso a la HCEN a los pequeños proveedores de servicios de salud XDS piloto disponible Servicios de Pacs y RIS disponibles (piloto) Piloto de HCEO funcionando en modo centralizado Existen otros componentes piloto que puede ser utilizados here you can see the next steps we are going take in order to evolve e-Health Platform

22 Conclusiones Se ha establecido una arquitectura escalable , confiable y segura que satisface las necesidades del Sistema de eSalud de alcance nacional. Se basa en las normas nacionales e internacionales en materia de interoperabilidad , seguridad electrónica , privacidad y protección de datos personales La estructuración como extensión de la PGE simplifica desarrollo, despliegue y operación Se reusan los instrumentos relacionados con la autenticación y control de acceso. En forma sencilla estos instrumentos podrán ser utilizados por todos los proveedores de salud y por los usuarios (Single Sign On Ciudadano) Las lecciones aprendidas en interoperabilidad a nivel nacional, se ha aplicado a la plataforma eHealth – Appliance PS Transferir el conocimiento, producto y operación al administrador de salud Complex engineering mechanisms related to authentication and access control, exchange of messages assuring security, privacy and information completeness, as well as supporting various protocols and data models, has been solved and will be used by all health care providers.

23 Preguntas?