Visión general de openEHR: el estándar abierto para historias clínicas electrónicas preparadas para el futuro

1. estándar abierto para historias clínicas
electrónicas preparadas para el futuro
¿para qué sirve?
Ing. Pablo Pazos Gutiérrez
pablo.pazos@cabolabs.com
1

2. openEHR
 Fundación internacional sin fines de lucro
 Comunidad
 Listas de correo (técnicas, clínicas)
 Herramientas libres y comerciales
 Implementaciones de referencia: Java, .Net,
Ruby, Python
 Internacional: ~1000 miembros de ~80 países
 En español: ~90+ miembros de 25 países
• http://openehr.org.es
 Curso openEHR: ACHISA
• ~ 80 estudiantes de 11 países
• http://informatica-medica.blogspot.com/2012/03/curso-de-openehr-en-espanol.html
2

3. openEHR: objetivos
 Uso efectivo (inteligente) de la información
 1) Atención médica y apoyo a las decisiones
 2) Investigación, educación, salud pública, epidemiología, def.
políticas, gestión, finanzas ...
 Independientemente de dónde se haya generado
 Neutral con respecto a formatos y tecnologías
 Sistemas económicamente viables
 Sistemas sustentables a largo plazo
 Sistemas modificables, evolución controlada
 Sistemas escalables, gran porte
 Sistemas longitudinales, transversales
 Centrados en el paciente
3

4. openEHR: solución propuesta
 Crear una plataforma informática de salud
 define arquitectura y estructuras básicas genéricas
 define modelos para su extensión
 define metodología para gestionar todos los elementos
 provee herramientas para trabajar con cada elemento
 permite gestión independiente de:
• conocimiento, información, tecnologías
 para crear nuevos sistemas o integrar existentes
 resultado: gobernabilidad
 Especificaciones de acceso libre
 Information Model, Archetype Model, Service Model
 Foco en la definición del contenido clínico (semántica)
 Esquemas XML para servicios
• intercambio dentro y entre sistemas openEHR
4

5. Plataforma Informática de Salud
Pablo Pazos, 2012 © CaboLabs.com 5

6. Plataforma de Información Clínica I
 Modelo de información de referencia
 pequeño, estable, genérico, implementado dentro software
 flexible: para representar cualquier clase de información
 Arquetipos: definiciones amplias de “conceptos clínicos”
 contenido cambiante, gestionado por fuera del software
 información específica como restricciones sobre el IM
 conjunto de datos mínimos vs. conjunto de conceptos mínimos
 Plantillas:
 usos particulares de arquetipos generales
6

7. Plataforma de Información Clínica II
 Separación entre estructuras estables y contenido
cambiante es la gran innovación de openEHR: el
modelo dual
 Nivel 1: modelo de información [ISO 13606-1 comp.]
 Nivel 2: modelo de arquetipos [ISO 13606-2]
 Permite ahorrar y gobernar el desarrollo
 mantenibilidad del software a largo plazo
• cambios por fuera del software
 cambios tecnológicos reutilizan todo el contenido
• arquetipos adoptables por nuevas herramientas de software
7

8. Arquetipos y Plantillas
Thomas Beale, 2007 © Ocean Informatics
8

9. Plataforma de Información Clínica III
 Terminologías:
 referenciadas desde arquetipos
 facilitan integración, CDS y procesamiento de la información
 Consultas:
 basadas en estructuras definidas en arquetipos
 capacidad de agregar información (reportes, gráficas, tablas)
 Permite crear servicios y el usar la información de forma efectiva
9

10. Evolución del EHR
 Ciclo de Evolución – Reingeniería: 7-10 años
 Cambios tecnológicos y metodológicos
 Cambios del dominio de la salud
 Sin openEHR unos cambios afectan a los otros
 Evolución controlada, reutilización, costo-efectividad
 Es más que un sistema de información: es una plataforma.
10

11. Modelos
Arquetipos, Información, Servicios
11

12. Modelo de Servicios (SM)
 EHR
 Gestión de registros
 Gestión de directorios (ej. casos, episodios)
 Auditoría y trazabilidad
 Demographic
 Personasl, Roles, Organizaciones, Agentes, Grupos
 Archetypes, Templates, Terminology
 Definiciones semánticas de conceptos clínicos
 Subsetting & mapping
 Query
 Consultas semánticas (basadas en arquetipos y terminologías)
 Rules
 Reglas para CDS, alertas, recordatorios, recomendaciones
 X-Ref
 Identificación cruzada de entidades entre distintos sistemas
 Audit Log, Security, Notification, Workflow/BPM, Messaging, …
12

13. Modelo de Información (RIM)
 EHR
 Control de cambios al EHR
• versionable, auditable, trazable
 Control de acceso al registro clínico
• reglas en cada EHR
 Directorio
• organización jerárquica de documentos y registros
 Documentos y Registros Clínicos EHR
 Composiciones:
• estructuras jerárquicas
Folders
• estructura definida mediante arquetipos Compositions
• eventuales (consulta médica)
• persistentes (lista de problemas) Sections
 Registros Demográficos
 también arquetipables Entries
 Extractos de EHR Clusters
 Fragmentos del EHR de uno o más pacientes
 Importar registros desde sistemas legados Elements
 Intercambio de registros entre sistemas EHR
Data values 13

14. Modelo de Arquetipos (AM)
 Permite
 Simplificar especificación de requerimientos
 Comunicación entre miembros del proyecto
 Empoderamiento de clínicos en el modelado de información
 Usos de arquetipos y plantillas
 Definición de registros clínicos
• estructura y restricciones
• definiciones en lenguaje natural y traducciones
• correspondencias con terminologías estándar
 Validación de datos
• basado en restricciones y terminologías
 Búsqueda de información
• basada en definiciones semánticas, independiente de las estructuras de datos
 Comunicación de información
• entre sistemas, orientado a servicios
 Generación de UI
• automatización, ahorro de tiempo, uniformidad, calidad
 Integración de datos
• estandarización e importación de datos clínicos de sistemas legados
14

15. Archetype Definition Language
OBSERVATION[at0000] matches { -- Blood Pressure
data matches {
HISTORY[at0001] matches {
events cardinality matches {1..*; unordered} matches {
EVENT[at0006] occurrences matches {0..*} matches {
data matches {
ITEM_LIST[at0003] matches {
items cardinality matches {0..*; unordered} matches {
ELEMENT[at0004] occurrences matches {0..1} matches { -- Systolic
value matches {
C_DV_QUANTITY <
property = <[openehr::125]>
list = <
["1"] = <
units = <"mm[Hg]">
magnitude = <|0.0..<1000.0|>
precision = <|0|>
...
ELEMENT[at0005] occurrences matches {0..1} matches { -- Diastolic
...
term_bindings = <
["SNOMED-CT"] = <
items = <
["at0000"] = <[SNOMED-CT(2003)::163020007]> -- Blood pressure reading
["at0004"] = <[SNOMED-CT(2003)::163030003]> -- Systolic BP reading
["at0005"] = <[SNOMED-CT(2003)::163031004]> -- Diastolic BP reading
15

16. Modelo dual en la
práctica
Gestión del conocimiento
16

17. Gestión del Conocimiento
 Diseño de arquetipos
 Mind Maps
 Subsets y mappings
 Creación de arquetipos
 Archetype Editor o CKM MindMap: Blood Pressure
 Referencian a subsets en SSTT
 Creación de plantillas
 Combinación para usos concretos de arquetipos genéricos
 Creación de consultas (uso en CDS y reportes)
 Query Builder
 Basadas en estructura de arquetipos
 Creación de reglas
 Rule Designer
 Evolución controlada
 Arquetipos y plantillas versionables
17

18. Modelo dual en la
práctica
Sistema en funcionamiento
18

19. Registro de Paciente
 Servicio demográfico
 Persona, Rol=Paciente, Información de Contacto
 Identificador único (interno) + múltiples identificadores
(externos)
19

20. Creación del EHR
 Servicio EHR
 EHR para el paciente (referenciado desde PartyRef)
 Estructura de directorios
 Control de acceso al EHR
20

21. Creación de registros clínicos I
 Médico usa aplicación de registro clínico (EMR)
 UI basada en plantillas y arquetipos
 Validación basada en arquetipos
 Registros: signos y orden de laboratorio
 Firma y commit
 Cierre del registro en EMR y envío a servidor EHR
21

22. Creación de registros clínicos II
 EHR Server recibe el commit de registros para el EHR del paciente:
 Vincula registros a directorios
 Trazabilidad, auditoría, versionado
• composer: responsable del cambio
• audit: tipo de cambio, fecha y hora, firma
• contribuciones: visión de todos los cambios al EHR
 Permite acceso a datos
• Consultas semánticas definidas previamente
• Visualización de datos: documentos, tablas, gráficas
22

23. Query Builder
23

24. Visualización de datos
24

25. Visualización de datos
25

26. openEHR & HL7
 ¡Estándares complementarios!
 openEHR: foco en plataforma estandarizada de información
• gestión del conocimiento, integración y uso efectivo de la información clínica
• metodología para la evolución controlada de todos sus elementos
 HL7: foco en comunicación y protocolos
• datos, documentos, protocolos, formatos, diccionarios/códigos
• estándar técnico para ser implementado sobre tecnologías concretas
 Un sistema EHR openEHR también necesita:
 gestionar pacientes y turnos (ADT)
 enviar órdenes y recibir resultados (CPOE)
 enviar prescripción de medicamentos (CPOE)
 enviar y recibir documentos clínicos (CDA, CCR, CCD)
 …
 Plataforma openEHR necesita resolver comunicación a nivel técnico
 Compatible y complementaria a entornos IHE (HL7 v2.x / v3 / CDA)
 Sistemas departamentales y servicios externos HL7 v2.x, CDA
 IHE (ej. PIX, PDQ, XDS, LTW …)
26

27. Recomendados
 Orígenes de openEHR:
 http://www.openehr.org/about/origins.html
 Quién lo usa:
 http://www.openehr.org/shared-resources/usage
 Recomendados:
 the world’s record
• http://www.openehr.org/301-OE.html
 resumen openEHR en español
• http://www.openehr.org.es/cms2/display/openehr
 Estándares e interoperabilidad en salud
electrónica: Requisitos para una gestión sanitaria
efectiva y eficiente (CEPAL 2011)
27

28. Muchas gracias por su
amable atención
Ing. Pablo Pazos Gutiérrez
pablo.pazos@cabolabs.com
@ppazos
28