Marco de trabajo genérico para crear sistemas de Historia Clínica Electrónica basados en documentos clínicos HL7-CDA

4,891 views

Published on

Marco de trabajo genérico para crear sistemas de Historia Clínica Electrónica basados en documentos clínicos HL7-CDA

Published in: Health & Medicine
1 Comment
2 Likes
Statistics
Notes
No Downloads
Views
Total views
4,891
On SlideShare
0
From Embeds
0
Number of Embeds
116
Actions
Shares
0
Downloads
124
Comments
1
Likes
2
Embeds 0
No embeds

No notes for slide

Marco de trabajo genérico para crear sistemas de Historia Clínica Electrónica basados en documentos clínicos HL7-CDA

  1. 1. Marco de trabajo genérico para crear sistemas de Historia Clínica Electrónica basados en documentos clínicos HL7-CDA A/C Pablo Pazos Gutiérrez 1
  2. 2. Agenda • Motivación • Gestión del conocimiento • Marco de trabajo – nivel proyecto – nivel implementación: • Casos de uso y extensiones • Conclusiones • Preguntas 2
  3. 3. Motivación I • ¿Por qué crear un marco de trabajo genérico? • Marco de trabajo – Nivel proyecto • Marca pautas básicas a seguir • Es abierto, no todo está definido – Nivel implementación • Desarrollo parcial que sirve como estructura de soporte para crear otras aplicaciones. • Ayuda a no tener que partir de cero, acelerando tiempos de desarrollo. • miniClin permite crear cualquier HCE sobre él. 3
  4. 4. Motivación II • Características deseables: – Estandarización: en todas las áreas posibles – Generalidad: permitir implementar cualquier HCE – Flexibilidad: poder modificar, adaptar, corregir y extender – Accesibilidad: acceso 24x7 a toda la información disponible – Bajo costo de implementación – Bajas necesidades en infraestructura – Perdurables en el tiempo: validez de los registros – Independientes al cambio de la tecnología • El objetivo es crear un marco de trabajo que cumple con la mayoría de estas características para que sean heredadas por todos los sistemas de HCE creados sobre él. 4
  5. 5. Gestión del conocimiento I • Gestión del conocimiento: – Especificar, organizar, utilizar, reutilizar, compartir, actualizar • Se debe utilizar un modelo del conocimiento clínico: – Ontologías, arquetipos, plantillas • Se especifica en función de un modelo de información: – Estructura que contiene datos, los relaciona y les da semántica • El conocimiento debe ser definido por fuera del programa, y este debe ser capaz de consumirlo: – Hoy el conocimiento se define “duro” en la aplicación • El sistema de información se genera al consumirlo: – Captura, Almacenamiento, Visualización, Comunicación • Permite la comunicación a nivel de conceptos: – ¡GARANTIZA LA INTEROPERABILIDAD SEMÁNTICA! 5
  6. 6. Gestión del conocimiento II Modelo de información = CDA Modelo del conocimiento = Plantillas CDA Objetos y conceptos = Documentos clínicos 6
  7. 7. Propuesta • Generar un marco de trabajo que ayude en la construcción de sistemas de HCE: – Que garantice alcanzar las características deseables antes mencionadas. – Estará orientado a la gestión de conocimiento. • No es una implementación de una HCE particular, es una estructura de soporte para crear cualquier sistema de HCE. 7
  8. 8. Marco de trabajo: nivel proyecto • Pautas a seguir: – Definición de roles y responsabilidades – Definición de requerimientos básicos • Que funcionalidad básicas deben proveer todas las Historias Clínicas Electrónicas – Toma de decisiones: • Modelo de referencia • Modelo de conocimiento • Tecnología – Implementación del marco: 8
  9. 9. Roles • Profesional informático – Es quien crea el software junto al equipo de desarrollo – Debe conocer: • modelos para definición del conocimiento clínico • modelos de información clínica • tecnologías de implementación. • Profesional de la salud – Es quien utilizará el sistema para registrar información clínica de los pacientes. • Experto del dominio – Es un profesional de la salud capacitado en el uso de herramientas para la definición de conocimiento clínico. – Deben conocer: • modelos para definición del conocimiento clínico • modelos de información clínica 9
  10. 10. Requerimientos básicos • Captura de datos – Generar formularios para la captura de datos. • Almacenamiento de datos – Donde y cómo se guardan los datos capturados. • Visualización de datos – Conservando semántica que tuvieron en el ingreso. • Comunicación de datos – Con qué sistemas, mediante qué canales, en qué formato, etc. – Conservando semántica que tuvieron en el ingreso. 10
  11. 11. Decisiones • Los 3 roles involucrados – Profesional Informático: es parte de lo que se debe programar – Experto en el dominio: conoce el dominio y los modelos – Profesional de la salud: puede plantear necesidades particulares que el modelo debe cumplir 11
  12. 12. Decisiones • Roles involucrados – Profesional Informático: es parte de lo que debe implementar – Experto en el dominio: es quien especificará el conocimiento en la aplicación a través de este modelo 12
  13. 13. Decisiones • Roles involucrados – Profesional Informático: es quien va a utilizar la tecnología para implementar la solución 13
  14. 14. Marco de trabajo definido 14
  15. 15. Marco de trabajo: nivel implementación Visión del sistema completo: - Roles, flujo de trabajo, aplicación orientada a la gestión del conocimiento como nexo, uso de servicios y mejora continua. 15
  16. 16. Marco de trabajo: nivel implementación • El experto del dominio puede definir todas las plantillas que se necesiten: – Historia clínica de emergencia general – Historia clínica de emergencia de trauma – Historia clínica de CTI – Historia clínica de internación domiciliaria – Resumen de internación – Historia clínica ambulatoria – Descripción operatoria (planificación e informe) – Resumen de historia clínica – Indicaciones terapéuticas – Anotaciones de enfermería – Evaluación clínica – Evolución de signos vitales – Solicitud de exámenes de laboratorio – Resultados de exámenes de laboratorio – Solicitud de exámenes imagenológicos – Informe de radiología (puede incluir imágenes) – y más... 16
  17. 17. Ejemplo de uso I • Se pueden definir un conjunto de plantillas para cada servicios. • El usuario puede acceder a las plantillas definidas para su servicio. • Selecciona una para registrar datos. 17
  18. 18. Ejemplo de uso II Pantalla generada por miniClin a partir de la plantilla de “Resumen Clínico”. Con esta funcionalidad se cumple el primer objetivo: informatizar el registro clínico. Luego con un servicio de identificación de personas e instituciones que intercambien documentos clínicos, podemos lograr la HCE única para cada paciente. 18
  19. 19. Implementación • miniClin – http://code.google.com/p/miniclin/ • Yupp PHP Framework – http://code.google.com/p/yupp • PHP – http://www.php.net • MySQL – http://www.mysql.com 19
  20. 20. Casos de uso y extensiones • Casos de uso: – HCE para viajes • El paciente se lleva su resumen de HC en un pendrive o en su celular • Nuevo producto / servicio que puede ofrecer un prestador de servicios de salud (mutualista, emergencia móvil, etc) a sus usuarios – HCE única • Comunicación interinstitucional basada en el perfil XDS de IHE • Interoperabilidad semántica se logra intercambiando plantillas – Integración con servicios (por ejemplo CPOE) • integrando la HCE con farmacia, laboratorio y radiología • Extensiones: – Integración con otros sistemas • Laboratorio / radiología • Farmacia – Seguridad avanzada – Integración de guías / flujos de trabajo definidos 20
  21. 21. Conclusiones • Utilizando miniClin como marco de implementación se podrá: – Informatizar el registro clínico en todos los sectores de una institución de salud. – Interoperar mediante documentos CDA. – Con algunas extensiones se podrá integrar: • Acceso a servicios terminológicos • Acceso a servicios demográficos • Sacar indicadores epidemiológicos • Integrar una capa de seguridad • Pero cualquier otro marco de proyecto que se defina podrá cumplir con las características deseables para una HCE. • Crear un marco de trabajo para implementar cualquier HCE a largo plazo es mucho menos costoso que implementar cada sistema por separado. 21
  22. 22. Preguntas A/C Pablo Pazos Gutiérrez pablo.swp@gmail.com 22

×