Alternativas de Persistencia para Información Clínica de distintos tipos y Arquitectura de sistemas de Historia Clínica Electrónica Un poco de bases de datos, de qué tipos hay y para qué las deberíamos usar, y otro poco sobre las experiencias en desarrollo de sistemas de HCE, llevados a resumir las buenas prácticas a nivel de arquitectura.

1. http://openehr.org.es
Persistencia de Información
Clínica y Arquitectura de
Sistemas de Historia Clínica
Electrónica
Ing. Pablo Pazos
http://informatica-medica.blogspot.com
1

2. Agenda
 Información clínica
 Alternativas de persistencia
 Arquitectura de EHR
 Conclusiones
2

3. Información Clínica
 Altamente jerárquica
 Estructuras complejas y variadas
 Tipos de datos variados
 Existen modelos estándar
3

4. Modelos
4

5. Modelos
 Para EHR
 openEHR IM
 HL7 CDA (solo documental)
 NCIPC DEEDS (emergencia)
 Para comunicación (modelo + formato)
 CEN/ISO 13606 (extractos)
 HL7 CDA
 ASTM CCR (resumen de HC)
 HL7 CCD (CDA para CCR)
 OMG COAS (solo observaciones)
 Conceptuales
 HL7 RIM
5

6. Persistencia
 Bases de datos
 Relacionales
 Orientadas a objetos
 Orientadas a documentos
 Orientadas a grafos
 Clave/Valor, Entidad/Atributo/Valor
6

7. Relacionales
 Modelo tabla-columna-registro-relación
 Problemas con información jerárquica
 Problemas con información compleja
 Formas normales
 Bueno para información estructurada
 Esquema rígido
 Necesita conversor OO a relacional
 SQL
7

8. Orientadas a objetos
 Muchas entidades
 Tan complejas como sea necesario
 Listas, Tablas, Árboles, y otras estructuras
 Trabaja con objetos de forma nativa
 Más flexibilidad estructural
 Objetos almacenados como tales sin
conversión
 SQL o similar
8

9. Orientadas a documentos
 Información jerárquica
 Tan complejas como sea necesario
 Documentos pueden anidarse y
vincularse
 Flexible
 No sigue un esquema fijo
 JSON/BSON, XQuery/XPath
9

10. Orientadas a grafos
 Información muy compleja
 Muchas relaciones entre las entidades
 No necesariamente jerárquica
 Ejemplos:
 información molecular
 relaciones entre personas
 representación multidimensional
10

11. Clave/Valor, E-A-V
 Orientados a columnas
 En lugar de a filas como en relacional
 Información altamente desagregada/plana
 Valor relativamente complejo
11

12. Información Clínica
12

13. Información Clínica
 Varios tipos de repositorios necesarios
 Operativo
 Series temporales
 Documental
 Vinculado
 Análisis
 Datawarehouse
 Solución one-fits-all imposible!
13

14. Información Clínica
 Repositorios operativos
 Mantienen registro clínico durante la sesión
• Interacciones en tiempo real
 Pasos previos a asentar el registro en el EHR
 Dentro de una única aplicación
 Orientado al ingreso de datos
• Poco volumen de datos
• Relativamente poca variabilidad
• Datos estructurados
 DB: Relacional
14

15. Información Clínica
 Series temporales
 Mantener registro durante monitoreo
• Interacciones en tiempo real
 Usuarios = dispositivos
 Orientado al ingreso de datos
• Mucho volumen de datos
• Poca variabilidad (ej. signos vitales)
 Poca estructura
• Datos planos
 DB: Cualquiera con atributos de temporalidad claros
15

16. Información Clínica
 Repositorio documental
 Mantener registros episódicos longitudinalmente
• Interacciones en segundo plano o casi tiempo real
 Documentos autocontenidos
• No hay cruce de datos con otros documentos
 Alta complejidad interna
• Muchos datos
• Muy variados
 Orientado a lectura
• Se crea una vez, se consulta N veces
 Consideraciones de seguridad, alta disponibilidad
 DB: Documentos
16

17. Información Clínica
 Repositorio vinculado
 Registro de salud persistente
• Problemas de salud: alergias, crónicos, factores de riesgo
• Historial familiar, vacunas, medicamentos actuales
• Información derivada del rep. documental
• Puede requerir interacciones en tiempo real para lectura
 Complejidad acotada
• Muchos datos, poca variabilidad
 Orientado a lectura
• Se crea una vez, se utiliza N veces
• Pero hay actualizaciones!
 Consideraciones de versionado, alta disponibilidad
 DB: Relacional
17

18. Información Clínica
 Repositorio para análisis
 Datos para usos específicos
• Investigación, data mining/knowledge discovery
 Múltiples fuentes de datos
• Otros repositorios
 Mucha variabilidad, relaciones complejas
 DB: Grafos, Orientadas a Objetos
18

19. Información Clínica
 Datawarehouse
 Orientados a análisis de indicadores
• Evolución histórica
• Gestión, Definición de políticas, Predicción
 Múltiples fuentes de datos
 Complejidad acotada:
• Entidades y dimensiones prediseñados
 DB: Relacional, Grafos (multidimensional)
19

20. Información Clínica
 Distintos “clientes” de los repositorios
 Aplicaciones
• Protocolo interno
 Sistemas
• Servicios
 Personas
• Aplicación interna
20

21. Arquitectura EHR
21

22. Arquitectura EHR
 Interfaz de usuario
 Cómo el usuario interactúa con la aplicación
 Aplicación
 Implementa la operativa de los usuarios
 Repositorio
 Servicios no operativos para:
• otros sistemas
• otros usos de la información
22

23. Arquitectura EHR
23

24. Arquitectura EHR
 ¿Separación entre UI y App?
 Múltiples dispositivos capaces de ser
utilizados para ingreso de datos
 Permite reutilizar servicios comunes sin atarse
a una tecnología particular de
presentación/interfaz de usuario
 Mantenibilidad
• Enfoque actual de diseño de aplicaciones sin UI
embebida en la aplicación
• Cambios en UI no afectan a la App
24

25. Arquitectura EHR
 Aplicaciones de registro clínico
 Servicios para UI
• Gestión de sesión de usuario: autenticación & autorización
• Flujo de trabajo, ingreso de información (datos y registros
individuales)
 Lanzar eventos en otros sistemas (LAB, RAD, FAR)
 Persistencia operativa
 Cliente de Demographic Server: búsqueda
 Cliente de EHR Server: commit
• Las aplicaciones pueden hacer en nexo entre información
clínica y demográfica (si está separada físicamente)
25

26. Arquitectura EHR
 EHR Server
 Provee servicios a múltiples aplicaciones de registro
clínico
• Genéricos, orientados a registros autocontenidos
 Provee servicios de información clínica a otros
sistemas
• Directamente o a través de middleware
• Acceso global a información clínica generada por N
aplicaciones
 No contiene información demográfica
• Buena práctica, permite usos secundarios de la información
 Repositorio documental y vinculado
• Es el EHR del paciente!
26

27. Arquitectura EHR
 Demographic Server
 Servicios sobre personas y roles
• Identificación
• Búsqueda
• Auditoría y calidad de registros (interno)
 Provee servicios a aplicaciones de registro
clínico y a otros sistemas
 Acceso global a información demográfica
 Repositorio relativamente operativo
• Muchas lecturas
27

28. Conclusiones
28

29. Conclusiones
 Información variada, usos variados
 Múltiples componentes con
 necesidades de manejo de información y
responsabilidades bien definidas (servicios)
 Distintas soluciones de persistencia para cada
caso, mejor solución global
 Enfoque para proyectos “grandes”
 Separación de componentes
 Estandarización de servicios
 Solución mantenible y escalable
 Calidad
29

30. http://openehr.org.es
Persistencia de Información
Clínica y Arquitectura de
Sistemas de Historia Clínica
Electrónica
Ing. Pablo Pazos
http://informatica-medica.blogspot.com
30