Este documento presenta un marco de trabajo genérico para crear sistemas de historia clínica electrónica basados en documentos clínicos HL7-CDA. El marco define roles, requerimientos básicos, y decisiones clave como el modelo de referencia, modelo de conocimiento y tecnología a utilizar. Además, explica cómo el marco puede usarse a nivel de proyecto y de implementación para crear aplicaciones de historia clínica que sean flexibles, estandarizadas y permitan la interoperabilidad semántica.

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. Agenda
• Motivación
• Gestión del conocimiento
• Marco de trabajo
– nivel proyecto
– nivel implementación:
• Casos de uso y extensiones
• Conclusiones
• Preguntas
2

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. 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. 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. Gestión del conocimiento II
Modelo de información
=
CDA
Modelo del conocimiento
=
Plantillas CDA
Objetos y conceptos
=
Documentos clínicos
6

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. 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. 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. 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. 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. 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. Decisiones
• Roles involucrados
– Profesional Informático: es quien va a utilizar la tecnología para
implementar la solución
13

14. Marco de trabajo definido
14

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. 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. 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. 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. 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. 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. 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. Preguntas
A/C Pablo Pazos Gutiérrez
pablo.swp@gmail.com
22