Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

openEHR: aspectos de interoperabilidad y mantenibilidad

1,701 views

Published on

Presentación para el evento Information and Communication Technologies and Mobile Health: Lessons Learned and Challenges for Latin America and the world 2015. Lima, Perú.

Published in: Healthcare
  • Be the first to comment

openEHR: aspectos de interoperabilidad y mantenibilidad

  1. 1. 1 Estándar Abierto para Historias Clínicas Electrónicas a Prueba de Futuro Aspectos de Interoperabilidad y Mantenibilidad
  2. 2. 2 Mantenibilidad • Habilidad de un sistema o componente de adaptarse a nuevos requerimientos y contextos con facilidad, y mantenerse estable ante los cambios. – Se mide en el costo de mantenimiento En software, la única constante es el cambio y tiene un alto costo asociado.
  3. 3. 3 Interoperabilidad • Habilidad de sistemas o componentes heterogéneos de intercambiar y utilizar información de forma efectiva. – Esta habilidad puede medirse en el costo de implementación • Interoperabilidad sintáctica: – refiere solo al intercambio de información • Interoperabilidad semántica: – es la que habilita la gestión y el uso efectivo (cumplir un fin asistencial, de gestión o de control ej. epidemiológico)
  4. 4. 4 Debemos hacer foco en la gestión y uso efectivo La comunicación de información en salud es un problema resuelto TCP MLLP HTTP SOAP XML JSON ER7
  5. 5. 5 Arquitectura Interna de Sistema de Información en Salud EHR99% del problema es el uso efectivo no de compartir información
  6. 6. 6 Contra la Interoperabilidad • La información definida solo a nivel de bases de datos – Semántica pobre, propenso a inconsistencias. • Semántica definida en documentos o hardcoded en el software – La semántica es interpretada de los documentos, propenso a errores (conocimiento clínico interpretado por informáticos). – No procesable: dificulta la automatización de procesos y el un uso efectivo de la información. • Evolución caótica de la definición de la información y de los sistemas – Se necesita controlar y tener trazabilidad. • Altos costos de interoperabilidad – Es probable que no llegue a un nivel semántico, solo intercambio. – Se pierde semántica en la comunicación por falta de modelos compartidos. • Fin del ciclo de vida del software (recambio tecnológico) – El conocimiento vertido en el software se pierde con él. – Alto costo de migración de la información al nuevo sistema, alto grado de inconsistencias. ¡También atentan contra la mantenibilidad!
  7. 7. 7 Estándar Abierto para Historias Clínicas Electrónicas a Prueba de Futuro
  8. 8. 8 • Estándar abierto – Foco en la gestión y uso de la información clínica (metodología) – http://openehr.org/programs/specification/releases/1.0.2 • Comunidad internacional – http://openehr.org/community/mailinglists • Comunidades locales – http://openehr.org.es • Programas con participación de miembros calificados – http://openehr.org/openehr_programs
  9. 9. 9 ¿Quién usa openEHR? Suecia – Cambio COSMIC 30% del mercado de EHRs en 2015 Noruega – DIPS Arena 70% del mercado de EHRs UK, Holanda, Brasil, Eslovenia, Portugal, Australia, Rusia, ... http://www.openehr.org/who_is_using_openehr/healthcare_providers_and_authorities
  10. 10. 10 El Modelo Dual de Los bloques básicos se pueden combinar para crear cualquier estructura de registro clínico, con guías computables que definen cómo se combinan
  11. 11. 11 El Modelo Dual de Bloques básicos (Modelo de Información) Semántica / Estructura del Registro Clínico (Modelo de Arquetipos)
  12. 12. 12 Un Modelo, Múltiples Registros Clínicos
  13. 13. 13 Un Modelo, Múltiples Registros Clínicos
  14. 14. 14 Modelo de Información Jerarquía del registro clínico Control de cambios (soporta versiones) Documentos clínicos (versionados)
  15. 15. 15 Arquetipos • “Lenguaje” para que los clínicos puedan definir historias clínicas electrónicas • Combinaciones de bloques básicos para definir estructuras de registros clínicos – Semántica: propósito, uso, definición de términos y traducciones – Validez global – No solo sirven para definir, también habilitan el uso efectivo (interoperabilidad!) – Incluyen restricciones y terminología • Un concepto por arquetipo – No es un modelo de la realidad, solo del registro • Conjunto de “datos” máximo – Se eligen qué partes utilizar en cada contexto • Versionables – Gestión controlada • Vínculos con terminologías estándar – Códigos específicos o subsets
  16. 16. 16 Arquetipos: MindMap http://ckm.openehr.org/ckm/#showArchetype_1013.1.130
  17. 17. 17 Arquetipos: ADL OBSERVATION[at0000] matches { -- Blood Pressure data matches { HISTORY[at0001] matches { -- history events cardinality matches {1..*; unordered} matches { EVENT[at0006] occurrences matches {0..*} matches { -- any event data matches { ITEM_TREE[at0003] matches { -- blood pressure items cardinality matches {0..*; unordered} matches { ELEMENT[at0004] occurrences matches {0..1} matches { -- Systolic value matches { C_DV_QUANTITY < property = <[openehr::125]> -- Pressure list = < ["1"] = < units = <"mm[Hg]"> -- UCUM units magnitude = <|0.0..<1000.0|> precision = <|0|> > ... ELEMENT[at0005] occurrences matches {0..1} matches { -- Diastolic value matches { C_DV_QUANTITY < property = <[openehr::125]> -- Pressure list = < ["1"] = < units = <"mm[Hg]"> -- UCUM units magnitude = <|0.0..<1000.0|> precision = <|0|> > ...
  18. 18. 18 Proceso de Desarrollo http://openehr.org/releases/1.0.2/architecture/overview.pdf
  19. 19. 19 Gestión del Conocimiento Clínico http://ckm.openehr.org – Clinical Knowledge Manager
  20. 20. 20 Recuperación de datos • Identificador de arquetipo ~ Tipo de información buscada – openEHR-EHR-OBSERVATION.blood_pressure.v1 • Cada nodo del arquetipo está identificado con una ruta ~ Dato específico – /data[at0001]/events[at0006]/data[at0003]/items[at0004]/value SELECT obs/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/magnitude, obs/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value/magnitude FROM EHR [ehr_id/value=$ehrUid] CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v1] CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.blood_pressure.v1] WHERE obs/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/magnitude >= 140 OR obs/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value/magnitude >= 90 Archetype Query Language (AQL) https://openehr.atlassian.net/wiki/display/spec/Archetype+Query+Language+Description
  21. 21. 21 Recuperación de datos http://www.slideshare.net/borutf/querying-ehr-data-with-archetype-query-language
  22. 22. 22https://www.youtube.com/watch?v=08vAk15utss < arquetipo (signos vitales) < rutas (presión arterial y FC) < opciones de salida < visualización de resultados Consultas basadas en arquetipos ¡las crean los clínicos!
  23. 23. 23 Ingreso y Visualización http://tinyurl.com/ehrgen-paper
  24. 24. 24 Utilización de datos • Reglas que utilizan arquetipos – Guideline Definitio Language (GDL) • Desarrollado por Cambio Healthcare Systems (Suecia) • Cálculos y verificación de condiciones complejas – Cálculo del score CHA2DS2-VASc (riesgo de fibrilación auricular) • https://github.com/openEHR/gdl-tools/blob/master/cm/guidelines/CHA2DS2VASc_Score_calculation.v1.gdl input score
  25. 25. 25 Aportes al uso efectivo de la información • Definición, Propósito, Validación – Modelo de Contenido Clínico: Arquetipos, Plantillas, ADL/XML – Los datos deben cumplir las restricciones definidas en los arquetipos • Ingreso y Visualización de Información clínica – Modelo de Interfaces de usuario, utiliza Arquetipos – http://tinyurl.com/uitemplate • Almacenamiento – Modelo de Persistencia, necesita ITS ej. openEHR  MongoDB / eXistDB / PostgreSQL – http://www.openehr.org/releases/1.0.2/html/architecture/overview/Output/its.html • Recuperación – Modelo de consultas: AQL (independiente de la tecnología de persistencia – Necesita ITS ej. AQL  SQL, AQL  XQuery, AQL  JSON Query, … – Capa de servicios aumenta capacidad de reutilización: REST, SOAP, XML-RPC, … • Agregación, Enriquecimiento, Vinculación, Consolidación – openEHR provee una base sólida para hacerlo • Utilización de la Información – Reglas, Reportes, Estudios Estadísticos, Cálculos (GDL) • Intercambio – Modelos de Intercambio: openEHR XML, compatible con HL7, CDA, CCR, DICOM, ISO13606, ... • Codificación – openEHR es compatible con estándares como SNOMED-CT, CIE-9, CIE-10, CIAP-2, .... • Evolución – Gestión controlada de cambios a los registros clínicos – Versionado de arquetipos y plantillas – Facilita recambio tecnológico
  26. 26. 26 Conclusiones
  27. 27. 27 Los modelos representan la parte cambiante del EHR, son independientes de las tecnologías de implementación, y se gestionan por fuera del software Aporta a la mantenibilidad y bajar el costo de implementación: sistemas se adaptan a los cambios, minimiza impacto, compatible hacia atrás Aumentar la capacidad de hacer un uso efectivo de la información registrada e intercambiada.
  28. 28. 28 Profesionales clínicos gestionan la definición y evolución del registro clínico, integrados al proceso de desarrollo gracias a una metodología formal. Definiciones formales de registros clínicos (arquetipos) Un modelo de información estándar Consistente para recolección, visualización y utilización Independencia tecnológica Amigable al recambio tecnológico Compatible con estándares de intercambio y codificación
  29. 29. 29 Otros temas • La capacitación es importantísima – Tanto para clínicos como informáticos – Desde 2011 formando a más de 200 profesionales de más de 15 países • www.achisa.org – ¡En MedInfo 2015 habrán varios tutoriales sobre openEHR! • http://www.medinfo2015.org/ • Arquitecturas orientadas a servicios, cloud y mobile app friendly – La arquitectura de EHR openEHR sigue estos principios – Crucial para el aprovechamiento de los recursos, foco en la reutilización
  30. 30. 30 ¡Muchas gracias! pablo.pazos@cabolabs.com @ppazos www.cabolabs.com github.com/ppazos openehr.org.es www.slideshare.net/pablitox

×