Sistema de identificación de pacientes orientado a servicios

Transcripción

1 Sistema de identificación de pacientes orientado a servicios Pablo Pazos Gutierrez SICTI, DiaCronic Samanta de Barros DiaCronic

2 Que son estas tres letras? EHR: Electronic Health Record IHE: Integrating the Healthcare Enterprise MPI: Master Patient Index HL7: Health Level Seven RIM: Reference Information Model CDA: Clinical Document Architecture MIF: Model Interchange Format ESB: Enterprise Service Bus PIX: Patient Identifier Cross-Referencing PDQ: Patient Demographics Query XDS: Cross-Enterprise Document Sharing PID: Patient Identification Domain

3 Hoja de ruta: Futuro: sistema de EHR. Hoy: interoperabilidad, intercambio de documentos clínicos. Perfiles IHE: descripción general. Creación de un MPI (índice maestro de pacientes) Perfil PIX en detalle. Rol de un ESB. Implementación del perfil PIX: PID, ESB, PIX Manager. Tecnologías. Principales problemas y soluciones. Conclusiones. Demo. Preguntas? Comentarios?

4 1. Futuro: sistema de EHR

5 Que es un EHR? Sistema distribuido que integra longitudinalmente toda la información de los registros clínicos de pacientes. Acceso a información de: medicaciones trabajo de laboratorio rayos X electrocardiogramas diagnósticos EHR permite: generar un registro completo de los encuentros clínicos del paciente. ofrece apoyo a las decisiones. administración de la calidad. Que errores se comenten y en que contexto. reportes clínicos.

6 EHR El EHR usa como fuente de información los sistemas existentes de EMR. EMR: (Electronic Medical Record) Sistema de registros clínicos de una organización proveedora de servicios de salud.

7 Para que un EHR? Información clínica de pacientes disponible donde y cuando sea necesaria. Análisis inteligente de datos clínicos. Alertas: globales: potenciales epidemias. personales: incompatibilidad de medicamentos. personales: alergia a medicación. Información estadística útil para la toma de decisiones. Uso de la información en docencia e investigación. Extraer nuevos conocimientos sobre enfermedades. Decisiones sobre uso y desarrollo de medicamentos.

8 Estamos lejos del EHR, y hasta de un EMR completo, pero el mundo está tendiendo a esto y Uruguay no se puede quedar atrás. No es solo un cambio tecnológico, es un cambio de paradigma en la atención médica, y el SNIS es un buen marco para el inicio del trabajo en esta área.

9 2. El problema a resolver hoy: interoperabilidad

10 Interoperabilidad Observación importante: El único punto en común de toda la información clínica y demográfica es el paciente. Comunicación de documentos clínicos: Muchos sistemas heterogéneos (plataforma / tecnologías). Muchas organizaciones (entidades estatales, hospitales, clínicas, etc). Mucha información (cientos de formularios distintos). Los mismos pacientes. Hoy algunas comunicaciones entre instituciones son necesarias: BPS / Mutualistas FNR / Hospitales

11 Problema de escalabilidad del sistema de comunicación Es necesario aplicar estándares para que el sistema de comunicación escale bien: Soporte para más tipos de mensajes. Soporte para más organizaciones comunicándose Si se implementa un sistema a medida no escala. Si se implementa un sistema a medida para comunicar un grupo pequeño de instituciones, los costos de escalar son mayores. Conclusión: los estándares se hacen necesarios para ahorrar dolores de cabeza futuros.

12 3. Perfiles IHE: descripción general

13 Perfiles IHE: descripción general IHE es una organización que define perfiles para resolver distintos problemas de sistemas en el área de salud. Perfiles definen: Define workflow. Define transacciones. Define actores. Restringe HL7 en el uso.

14 Perfiles IHE Perfil XDS: la solución de IHE para la comunicación de documentos. XDS: Cross-Enterprise Document Sharing Registro, distribución y acceso a documentos clínicos, que forman parte de la historia clínica de un paciente, entre organizaciones proveedoras de servicios. Perfil PIX: la solución de IHE para resolver identidades de pacientes. Mapa de identificadores de pacientes a través de distintos dominios de identificación. Dice como implementar un MPI. Perfil PDQ: la solución de IHE para la consulta de identificadores. Define la forma en que los distintos dominios deben consultar al MPI por información demográfica y por identificadores, y como deben ser devueltos los resultados.

15 Ejemplo Envío de documento clínico de un paciente. Org. 1: Genera documento clínico y envía a la Org. 2. Potencialmente usan distintos identificadores para pacientes. La Org. 2 no tiene el identificador del paciente que le envía la Org. 1. Solución: MPI Hay muchas soluciones, IHE plantea soluciones mediante HL7.

16 4. Creación de un MPI

17 MPI Solución: crear un MPI. MPI: índice maestro de pacientes. Resuelve referencias cruzadas para el mismo paciente. Verifica la identidad de una persona dados conjuntos incompletos de datos demográficos. En Uruguay se utiliza el procedimiento de verificación de identidad de la SUEIIDISS. Algoritmo probabilísimo, puede dar una respuesta definitiva si o no, o un porcentaje de seguridad. Un MPI guarda copias de registros de información demográfica de los pacientes y los identificadores para cada organización.

18 Problema de escalabilidad del sistema de comunicación El perfil PIX define un MPI con sus respectivos componentes, casos de uso y transacciones que implementarán las funcionalidades necesarias. Escalabilidad: Agregar nuevas organizaciones no debería ser un problema. No debería modificarse el sistema de MPI. Problemas de contar con un solo sistema al que todos se conectan. Seguridad: Todas las transacciones deben ser seguras. Encriptado de mensajes. Intercambio de certificados. Se deben tener información de auditoria por problemas que puedan ocurrir.

19 5. Perfil PIX en detalle

20 PIX: Patient Identity Cross- Referencing El perfil define 2 componentes: Patient Identification Domain PIX Manager

21 Perfil PIX Las funcionalidades definidas por PIX para el MPI son: Agregar pacientes al MPI. Modificar información de pacientes en el MPI. Notificar a otros participantes de eventos en el MPI. Resolver duplicados de información (saber que los datos de dos pacientes corresponden a la misma persona).

22 6. Rol de un ESB en un sistema distribuido.

23 ESB en un sistema distribuido Componente arquitectónico responsable de la comunicación entre sistemas heterogéneos Agrega un nivel de abstracción a la implementación

24 ESB Principales funcionalidades Invocación de servicios Ruteo Mediación Coreografía de procesos Orquestación de servicios

25 ESB en un EHR EHR: integra información de un paciente distribuida en distintos sistemas. EMR: se pueden ver como servicios consumidos por el EHR ESB como responsable de la comunicación: EHR habla sólo con ESB Escalabilidad: los EMR se agregan al ESB, no se modifica EHR

26 Aplicación de ESB a un MPI Problema a resolver: Escalabilidad del MPI Solución: Arquitectura de composite para sistemas MPI. Esta solución permite que se adopte el MPI de forma incremental. ESB sería un buen soporte de comunicación para esta arquitectura de MPI. Problema: el árbol puede crecer en altura, y llevar a problemas de performance. Una solución: redistribuir nodos en el árbol.

27 7. Implementación: PID, ESB, PIX Manager.

28 Arquitectura

29 DSS

30 Componente de armado y desarmado de mensajes:

31 Implementación de mensajería HL7 COMB: CMET-Oriented Message Builder Componente para armar y desarmar mensajes. Una clase por CMET (arma y desarma ese CMET). Operación getmessage() devuelve el mensaje del tipo correcto. Mensaje HL7 se obtiene de procesar el resultado de getmessage() mediante JavaSIG.

32 Receptor genérico de mensajes Opción 1: Esquema utilizado en PIS (DiaCronic) Crear un servicio para recibir cada tipo de mensaje Mucha lógica duplicada. Opción 2: Un servicio recibe muchos tipos de mensajes distintos. Reutiliza lógica. Permite registrar nuevos tipos de mensajes. Lógica para procesar nuevos mensajes se agrega a través de una interfaz. No es necesario modificar otras partes del sistema.

33 8. Tecnologías

34 Tecnologías Web Services: Conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones Probamos REST y SOAP. Nos quedamos con REST. JavaSIG: Librería para generar mensajes HL7. Implementa el RIM. Usa archivos MIF provistos por HL7.

35 Tecnologías Apache Service MIX: ESB OpenSource que cumple con la especificación JSR 208 para JBI.

36 Tecnologías Mirth: ESB OpenSource orientado a comunicación HL7. Desarrollado sobre Mule ESB. GUI presenta un administrador simple e intuitivo del ESB.

37 Tecnologías OpenLDAP: Implementación OpenSource del protocolo LDAP. Rápido para consultas. Grails: Framework ágil MVC y ORM para Java. Basado en el stack de frameworks Java más populares: Hibernate Spring Sitemesh Quartz Scheduling Jetty HSQLDB Groovy

38 Tecnologías Groovy: Lenguaje dinámico de Java. Menos verboso. Nuevos constructores (p.e. clausuras, builders, etc) Grails plugin AXIS2: Levantar WS de forma sencilla en Grails. Grails plugin GLdapo: Acceso a LDAP desde Grails. Sustituye el ORM por defecto. GroovyWS: Librería basada de Groovy para publicar y consumir WS.

39 9. Principales problemas y soluciones.

40 Problemas - Soluciones Perfiles: El trabajo fue basado en un documento draft de la IHE. Información desordenada, información incompleta. Se tomaron otras fuentes de información. Generación de mensajes: HL7 provee archivos MIF para generar mensajes. JavaSIG toma los MIFs y una estructura RIM y genera un mensaje válido. Los MIF que utilizamos no funcionaban. Para generar un mensajes válido para el CMET tuvimos que modificar archivos MIF.

41 Problemas - Soluciones Envío vía un POST HTTP (REST) de un mensaje a Mirth llega encodeado. Se recibe: %3C%3Fxml+version%3D%221.0%22+encoding%3D%22UTF- 8%22%3F%3E%0A%3CPatient+xmlns%3D%22urn%3Ahl7- org%3av3%22+xmlns%3axsi%3d%22http%3a%2f%2fwww.w3. org%2f2001%2fxmlschemainstance%22+classcode%3d%22 PAT%22%3E%0A+++%3 En lugar de: <?xml version="1.0" encoding="utf-8"?><patient xmlns="urn:hl7-org:v3" xmlns:xsi=" classcode="pat"> Se accede al request HTTP que recibe el Mirth desde el PID, ahí se extrae el parámetro del mensaje, y se envía al PIX Manager y ahí se decodea.

42 Problemas - Soluciones Mirth: Tiene poca documentación disponible. La documentación existente está orientada a HL7v2.x y nosotros utilizamos mensajes HL7v3 que no son compatibles con HL7v2.x Lo hicimos funcionar a prueba y error.

43 10. Conclusiones

44 Conclusiones ESB es más de lo necesario para el problema particular de PIX. Uso de estándares a través de perfiles IHE es necesario para obtener una solución escalable. Un receptor genérico de mensajes puede reusar lógica y disminuir el costo de agregar nuevos mensajes.

45 11. Demo

46 Mirth Admin Mirth Server PIX Manager PID Mirth http Listener Demo

47 12. Preguntas? Comentarios?

48 Gracias! Pablo Pazos Samanta de Barros