http://openehr.org.esPersistencia de Información  Clínica y Arquitectura deSistemas de Historia Clínica         Electrónic...
Agenda Información clínica Alternativas de persistencia Arquitectura de EHR Conclusiones                              ...
Información Clínica Altamente jerárquica Estructuras complejas y variadas Tipos de datos variados Existen modelos está...
Modelos          4
Modelos   Para EHR       openEHR IM       HL7 CDA (solo documental)       NCIPC DEEDS (emergencia)   Para comunicació...
Persistencia Bases de datos     Relacionales     Orientadas a objetos     Orientadas a documentos     Orientadas a gr...
Relacionales Modelo tabla-columna-registro-relación Problemas con información jerárquica Problemas con información comp...
Orientadas a objetos Muchas entidades     Tan complejas como sea necesario     Listas, Tablas, Árboles, y otras estruct...
Orientadas a documentos Información jerárquica     Tan complejas como sea necesario Documentos pueden anidarse y  vincu...
Orientadas a grafos Información muy compleja Muchas relaciones entre las entidades No necesariamente jerárquica Ejempl...
Clave/Valor, E-A-V Orientados a columnas     En lugar de a filas como en relacional Información altamente desagregada/p...
Información Clínica                      12
Información Clínica Varios tipos de repositorios necesarios     Operativo     Series temporales     Documental     Vi...
Información Clínica Repositorios operativos     Mantienen registro clínico durante la sesión       • Interacciones en ti...
Información Clínica   Series temporales       Mantener registro durante monitoreo         • Interacciones en tiempo real...
Información Clínica   Repositorio documental       Mantener registros episódicos longitudinalmente         • Interaccion...
Información Clínica   Repositorio vinculado       Registro de salud persistente         •   Problemas de salud: alergias...
Información Clínica Repositorio para análisis     Datos para usos específicos       • Investigación, data mining/knowled...
Información Clínica Datawarehouse     Orientados a análisis de indicadores       • Evolución histórica       • Gestión, ...
Información Clínica Distintos “clientes” de los repositorios     Aplicaciones       • Protocolo interno     Sistemas   ...
Arquitectura EHR                   21
Arquitectura EHR Interfaz de usuario     Cómo el usuario interactúa con la aplicación Aplicación     Implementa la ope...
Arquitectura EHR                   23
Arquitectura EHR ¿Separación entre UI y App?     Múltiples dispositivos capaces de ser      utilizados para ingreso de d...
Arquitectura EHR   Aplicaciones de registro clínico       Servicios para UI         • Gestión de sesión de usuario: aute...
Arquitectura EHR   EHR Server       Provee servicios a múltiples aplicaciones de registro        clínico         • Genér...
Arquitectura EHR Demographic Server     Servicios sobre personas y roles       • Identificación       • Búsqueda       •...
Conclusiones               28
Conclusiones   Información variada, usos variados   Múltiples componentes con       necesidades de manejo de informació...
http://openehr.org.esPersistencia de Información  Clínica y Arquitectura deSistemas de Historia Clínica         Electrónic...
Upcoming SlideShare
Loading in …5
×

Persistencia de información clínica y arquitectura de sistemas de historia clínica electrónica

5,171 views

Published on

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.

Published in: Health & Medicine
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,171
On SlideShare
0
From Embeds
0
Number of Embeds
2,572
Actions
Shares
0
Downloads
89
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • http :// www.openehr.org / releases /1.0.2/ roadmap.html http :// www.cdc.gov / ncipc / pub -res/ deedspage.htm http :// www.omg.org / spec /COAS/ http :// www.astm.org / Standards /E2369. htm http :// www.interopsante.org / offres / file_inline_src /412/412_P_15660_82. pdf http :// reportingwiki.rsna.org / images /b/b1/ RSNA_Reporting_Forum_Behlen.pdf
  • http :// en.wikipedia.org / wiki / Entity%E2%80%93attribute%E2%80%93value_model
  • http :// www.postgresql.org / http :// www.sqlite.org / http://db.apache.org/derby/ http://www.firebirdsql.org/ http://hsqldb.org/
  • http://www.persvr.org/ http :// www.cubrid.org /
  • http://exist-db.org/ https :// github.com / BaseXdb / basex http :// couchdb.apache.org / http :// www.mongodb.org /
  • http ://neo4j. org / http :// www.kobrix.com / hgdb.jsp http :// infogrid.org / trac / http :// www.orientdb.org / index.htm
  • http :// wiki.basho.com / http://incubator.apache.org/cassandra/ http://memcached.org/ http://code.google.com/p/redis/ http :// ycmi.med.yale.edu / TrialDB / http :// senselab.med.yale.edu / http :// boilerbay.com / infinitydb /
  • seguridad: firma y encriptacion
  • http :// en.wikipedia.org / wiki / Data_mining
  • No menciono aplicaciones de análisis o DW
  • Concepto de HCE virtual
  • Persistencia de información clínica y arquitectura de sistemas de historia clínica electrónica

    1. 1. http://openehr.org.esPersistencia de Información Clínica y Arquitectura deSistemas de Historia Clínica Electrónica Ing. Pablo Pazos http://informatica-medica.blogspot.com 1
    2. 2. Agenda Información clínica Alternativas de persistencia Arquitectura de EHR Conclusiones 2
    3. 3. Información Clínica Altamente jerárquica Estructuras complejas y variadas Tipos de datos variados Existen modelos estándar 3
    4. 4. Modelos 4
    5. 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. 6. Persistencia Bases de datos  Relacionales  Orientadas a objetos  Orientadas a documentos  Orientadas a grafos  Clave/Valor, Entidad/Atributo/Valor 6
    7. 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. 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. 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. 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. 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. 12. Información Clínica 12
    13. 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. 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. 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. 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. 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. 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. 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. 20. Información Clínica Distintos “clientes” de los repositorios  Aplicaciones • Protocolo interno  Sistemas • Servicios  Personas • Aplicación interna 20
    21. 21. Arquitectura EHR 21
    22. 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. 23. Arquitectura EHR 23
    24. 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. 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. 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. 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. 28. Conclusiones 28
    29. 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. 30. http://openehr.org.esPersistencia de Información Clínica y Arquitectura deSistemas de Historia Clínica Electrónica Ing. Pablo Pazos http://informatica-medica.blogspot.com 30

    ×