Taller open ehr cais 2010 - pablopazos

1
Taller de OpenEHR
Un estándar para crear HCEs
Pablo Pazos Gutiérrez
http://informatica-medica.blogspot.com
JAIIO - CAIS 2010

2
Objetivos
• Aprender un nuevo estándar
• Aprender una enfoque “novedoso” de crear SIS
• Mejorar la participación de los médicos en
proyectos de SIS
• Aprender como crear mejores SIS
• Fomentar comunidad y colaboración
• ...

3
Agenda
 Parte1:
 ¿Cómo hacemos
Sistemas de
Información en Salud
hoy?
 Introducción a
OpenEHR
 Organización de la
información clínica
 Modelo dual
 Herramientas I
 Parte 2:
 Arquitectura
 Herramientas II
 Discusión

4
¿Cómo hacemos Sistemas de
Información en Salud hoy?
Un ejemplo particular

5
• Proceso de desarrollo:
– Análisis
• Requerimientos (F y no F)
– Casos de uso
• Modelo de dominio
– Surgen “conceptos clínicos”
– Diseño
• Arquitectura
• Diseño detallado de componentes
– Implementación
– Pruebas
– Producción
¿Cómo hacemos SIS hoy?

6
• Conceptos clínicos
– Surgen del análisis del dominio clínico
– Incluidos en el modelo de dominio
– Formados por:
• Son los datos más el contexto (propósito)
– Propósito
– Datos
– Estructuras
– Relaciones
– Restricciones
– No somos expertos, los expertos son los médicos.
• Aún así los informáticos seguimos modelando
conceptos clínicos

7
• ¿Porqué no dejar que los médicos definan y
actualicen los conceptos clínicos que manejará
el SIS?
• ¿Cómo lograrlo?

8
• Ejemplo: conceptos clínicos relevados en el análisis
– Signos vitales:
• Presión arterial
• Temperatura corporal
• Frecuencia cardíaca
– Imagenología:
• Orden de estudio
• Estudios imagenológicos (RM, ECO, TC, PET, ...)
• Informe radiológico
– Evaluaciones clínicas
• Vía aérea
• Exploración externa
• Diagnóstico

9
• Punto de vista de la arquitectura
– Cuatro capas
• Interfaz de usuario
• Lógica de negocio
• Persistencia
• Servicios

10
 Punto de vista funcional
 Requerimiento cero: registrar información clínica
 Otras funcionalidades:
 Agregación de datos
 Extracción de reportes
 Emisión de órdenes para estudios
 Visualización de resultados de estudios
 …

11
• Punto de vista de la información
 Colección de registros organizados con algún criterio
 Para un paciente, de un responsable médico
 Divididos por sector, servicio o departamento
 Cada uno con necesidades particulares
 La información clínica es la misma
 La información está relacionada con conceptos clínicos
relevados en el análisis
 Información clínica:
 Observaciones clínicas, evaluaciones, planes de tratamiento y acciones
terapéuticas.
 Emisión de órdenes y prescripciones de medicamentos.
 Resultados de estudios de laboratorio o imagenológicos.
 Etc….

12
• Problemas
– Arquitectura a medida
– Funcionalidad a medida
– Gran dependencia tecnológica
– Conocimiento clínico implementado de forma “dura” en
el software
– Cambios en los “conceptos clínicos” afectan a todos los
componentes del sistema
• Los problemas están relacionados con “cómo”
hacemos los sistemas
– Un sistema que modele un dominio complejo será
complejo.

13
 Problemas
 ¿Y con múltiples sistemas?
 Necesidades particulares por sector/depto
 Distintos procesos asistenciales
 Registran la misma información general (conceptos clínicos)
 Trabas a la interoperabilidad con información clínica
 ¿Equivalencias entre registros de <> sectores?
 ¿Donde se define la información de cada registro?
 ¿Cómo se organizan los registros?
 La HCE no puede ser única por paciente si hay inconsistencias
estructurales y semánticas en distintos sectores (int. interna).
 Mucho menos es posible la correcta comunicación con otros
actores del sistema de salud (int. externa).

14
• Problemas:
– Para la modificación de los formularios de registro
• Solucionamos todo con un “editor de formularios”
• Los cambios se hacen rápido, pero...
– La definición de formularios:
• No contiene la semántica de la información clínica a
registrar:
• Solo define una estructura de datos
• No con qué conceptos clínicos se corresponde
• Permite inconsistencias en el registro de la misma
información
– La orientación a formularios o documentos tiene
muchos problemas

16
El enfoque “novedoso”
• Claves para hacer mejores SIS:
– Que los médicos, enfermeras y técnicos se encarguen
de gestionar el conocimiento clínico.
– Los informáticos de hacer mejores sistemas, más
simples, más reusables.
– Depender menos de la tecnología.
– Lo importante es el conocimiento y la información que
se registra en función ese conocimiento.
– Los sistemas mueren con el cambio de la tecnología,
la información clínica vive durante toda la vida del
paciente.

17
Cómo informático:
• Crear componentes genéricos y reusables
– Usar estándares
– No reinventar la rueda
• No hacer tareas que debe hacer otro rol
– No soy un experto médico
– No soy experto en codificaciones ni terminología
médica
– No conozco los procesos asistenciales
– Pero puedo crear herramientas para que los roles
correctos puedan definir lo que necesitan

18
Como paciente:
• Toda la información clínica
– A lo largo de mi vida
– De múltiples instituciones y actores
• Independiente de la tecnología
– La tecnología cambia
– La información y el conocimiento se mantiene
– Independencia entre “la información y lo que
representa”, y “la aplicación de software”
• Información y semántica de la misma deben mantenerse a
largo plazo.

19
Agenda
 Parte1:
 ¿Cómo hacemos
Sistemas de
hoy?
 Introducción a
OpenEHR
 Modelo dual
 Herramientas I
 Parte 2:
 Arquitectura
 Herramientas II
 Discusión

20
Introducción a OpeEHR
 Organización
 Fundación internacional sin fines de lucro.
 Objetivos
 Hacer realidad la creación del registro de salud:
 Interoperable entre distintos actores del sistema de salud
 Durable a lo largo de la vida del paciente.
 Mejorar la atención de salud en la sociedad de la información
 ¿Cómo?
 Desarrollando especificaciones abiertas, herramientas de
software y recursos de conocimiento libres.
 Participando en implementación de proyectos clínicos.
 Participar en el desarrollo de normas internacionales.

21
Introducción a OpeEHR
 Estándar
 Estándar abierto para crear HCEs normalizadas
orientadas a la gestión del conocimiento.
 Para soportar proyectos de HCE económicamente
viables, mantenibles y adaptables.
 El costo más grande ocurre en la etapa de producción.
 HCE Virtual
 Capa de abstracción para el acceso, creación y modificación
global de registros clínicos de una persona.
 Logitudinal a la vida del paciente.
 Transversal a instituciones y actores del sistema de salud.
 Permite consistencia semántica entre toda la información
clínica existente para cada paciente en distintas instituciones.

22
Introducción a OpenEHR
• HCE Virtual

23
OpenEHR conceptos generales
• Modelo dual
– Toda aplicación debe contener conocimiento particular
del dominio que desea modelar.
– El “conocimiento” clínico que maneja la aplicación de
software y la aplicación en sí, son componentes
separados.
• La independencia permite generalidad, modularidad,
reusabilidad, bajo acoplamiento, ... en definitiva “calidad”.
• OpenEHR provee:
– Modelo de información estándarizado (sw)
• Modelo de referencia genérico
– Modelo de conocimiento (b.c.)
• Arquetipos y templates

24
Agenda
 Parte1:
 ¿Cómo hacemos
Sistemas de
hoy?
 Introducción a
OpenEHR
 Modelo dual
 Herramientas I
 Parte 2:
 Arquitectura
 Herramientas II
 Discusión

25
• Organización de documentos en carpetas
– Por sector, servicio o departamento
• Documentos separados y agrupados
– Se usan etiquetas o códigos de colores
• Cada documento es una colección de entradas
• Cada entrada agrupa datos con un criterio y un propósito
• Los datos tienen un tipo, se agrupan en estructuras y
deben tener un propósito definido
– Las estructuras, tipos de datos y propósitos deben ser definidos
en algún lado
Organización de la información clínica

26
Resumen del modelo de información normalizado de OpenEHR
Organización de la información clínica

27
• Proceso de resolución de problemas clínicos
– Síntesis del trabajo de Lawrence Weed (1969) sobre
el registro orientado por problemas y el modelo
hipotético-deductivo de Elstein (1987).
Modelo de información clínica

28
Modelo de información genérico de entradas

29
Para poder usar el modelo de información de
OpenEHR, debemos identificar con que objetos
de este modelo se corresponden las entidades-
objetos-conceptos relevados en la etapa de
análisis.

30

31
Registro SOEP:
•Subjetivo
•Objetivo
•Evaluación
•Plan

32
Protocolo para la medición de la presión arterial:
• Dispositivo
• Tamaño del manguito
• Posición del paciente

33
Estudio de tolerancia a la glucosa:
• Serie temporal (historial del estado del paciente)
• Dato medido

34
Agenda
 Parte1:
 ¿Cómo hacemos
Sistemas de
hoy?
 Introducción a
OpenEHR
 Modelo dual
 Herramientas I
 Parte 2:
 Arquitectura
 Herramientas II
 Discusión

35
OpenEHR modelo dual
Modelo de información vs. Modelo de conocimiento

36
• Principales objetivos:
– Separar conocimiento de información
– Para que el conocimiento se gestione, actualice y
amplíe independientemente de la tecnología
– Crear software más inteligente, más genérico, más
modificable y adaptable a nuevas necesidades
– El sistema de software puede sustituirse, el
conocimiento y la información no
• Deben acompañar toda la vida al paciente
– Permitir la interoperabilidad semántica entre distintos
actores para contar con una HCE completa
OpenEHR modelo dual

38
Modelo de conocimiento
• El conocimiento clínico se define usando arquetipos
• Los arquetipos son:
– Definición formal de contenido clínico
– Artefactos de conocimiento clínico
– Modelos de conceptos clínicos
– Restricciones sobre un modelo de información genérico
– Características:
• Computables
• Compartidos
• Versionados
• Extendidos
• Combinados
• Traducidos
• Usar terminologías (CIE 9, CIE 10, Snomed, CIAP2, ...)

39
• Arquetipos:
– Definen cómo se usa el modelo de información genérico
para representar conceptos clínicos particulares.
– Permiten reusabilidad de los mismos conceptos clínicos
en diferentes contextos:
• HCE de emergencia
• HCE de internación
• HCE ambulatorio
– Permite consistencia semántica entre distintos sistemas:
• Un mismo concepto clínico es definido por el mismo arquetipo
en 2 o más sistemas.

40
• Arquetipos:
– Definen cómo se usa el modelo de información genérico para
representar conceptos clínicos particulares.

41
• Arquetipos:
– Son especificados usando el lenguaje de definición de
arquetipos (ADL)
– Se usa un “editor de arquetipos”
• Distinto a “editor de formularios”
• Los formularios con estructuras de campos
• Los arquetipos son estructuras, relaciones y restricciones
entre conceptos clínicos especificados mediante un modelo
de información genérico.

42
OBSERVATION[at0000] matches { -- Blood Pressure
data matches {
HISTORY[at0001] matches { -- history
events cardinality matches {1..*; unordered} matches {
EVENT[at0006] occurrences matches {0..*} matches { -- any event
data matches {
ITEM_TREE[at0003] matches { -- blood pressure
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
value matches {
C_DV_QUANTITY <
property = <[openehr::125]>
list = <
["1"] = <
units = <"mm[Hg]">
magnitude = <|0.0..<1000.0|>
precision = <|0|>
...
...

43
Instancia del modelo de información que cumple
con el arquetipo del ejemplo de ADL:

44
Agenda
 Parte1:
 ¿Cómo hacemos
Sistemas de
hoy?
 Introducción a
OpenEHR
 Modelo dual
 Herramientas I
 Parte 2:
 Arquitectura
 Herramientas II
 Discusión

45
Herramientas I
• Para crear arquetipos usamos el Ocean Archetype
Editor:
– Permite definir de forma visual el contenido de un
arquetipo.
– Cada arquetipo se corresponde con un objeto del
modelo de información genérico.
• Recordar el modelo de entradas.
– El editor permite tener una idea de la interfaz de usuario
que se generará a partir de cada arquetipo.
– El arquetipo se guarda en formato ADL y está listo para
ser usado en un sistema de información.

46
Herramientas I
• ¡Hagamos un par de arquetipos!
– Acción: administración de sustancias
• Sustancia administrada
– Nombre (texto libre)
– Vía (texto codificado)
– Dosis (cantidad con dimensión)
• Fecha y hora de administración
– Observación: medida de presión arterial
• Presión sistólica
– Medida (cantidad con dimensión)
• Presión diastólica
– Medida (cantidad con dimensión)

47
Agenda
 Parte1:
 ¿Cómo hacemos
Sistemas de
hoy?
 Introducción a
OpenEHR
 Modelo dual
 Herramientas I
 Parte 2:
 Arquitectura
 Herramientas II
 Discusión

48
Arquitectura de una HCE
• Sistema mínimo de HCE según OpenEHR
Base de conocimiento
Repositorio de información clínica
Repositorio de datos
demográficos de pacientes

49
Arquitectura de una HCE
• Arquitectura en funcionamiento

50
Agenda
 Parte1:
 ¿Cómo hacemos
Sistemas de
hoy?
 Introducción a
OpenEHR
 Modelo dual
 Herramientas I
 Parte 2:
 Arquitectura
 Herramientas II
 Discusión

51
Herramientas II
• OpenEHR CKM (Clinical Knowledge Manager)
– Base de conocimiento global
– http://www.openehr.org/knowledge/
• Open EHR Standard Architecture
– Framework en desarrollo para la creación de HCEs
(SIS en general) orientado a la gestión del
conocimiento

52
Herramientas II
• OpenEHR CKM (Clinical Knowledge Manager)
– Buscar arquetipos para distintas clases de entradas:
• Observaciones, Evaluaciones, Instrucciones y Acciones
• Veamos sus estructura interna
– Propósito, uso, mal uso
– Datos
– Correspondencias con terminologías internacionales
– Traducciones a múltiples idiomas
– Los arquetipos son autocontenidos:
• Toda la información del concepto debe definirse en el mismo
arquetipo.

53
Herramientas II
– Permite generar un SIS a partir de arquetipos
• Las pantallas de registro de información se generan a partir
de los arquetipos en la base de conocimiento local.
• La validación y la persistencia de la información clínica
ingresada se realiza automáticamente.
– Tecnologías:
• Grails Framework, Groovy, MySQL.

54
Herramientas II

55
Open EHR Standard Architecture
Herramientas II

56
Resumen
• La gestión del conocimiento ayuda a:
– Crear sistemas más genéricos, reusables, mantenibles
y adaptables a nuevas necesidades.
– El conocimiento por fuera de la aplicación permite la
longitudinalidad del registro clínico.
– El conocimiento debe ser gestionados por expertos en
el dominio clínico.
– Las bases de conocimiento se pueden compartir entre
distintos sistemas, instituciones, países, ...
• aportando a la interoperabilidad semántica
• consistencia semántica de la información registrada en
distintos sistemas.

57
Resumen
• El proceso es:
– Analizar el dominio para identificar conceptos clínicos
– Realizar una correspondencia con las distintas clases
de entradas en el modelo de información
– Generar arquetipos para esos conceptos según las
clases del modelo de información
– Generar una aplicación que sea capaz de cargar
arquetipos, generar una interfaz de usuario, y procesar
datos que ingresa el usuario para persistirlos
– Configurar la aplicación para que tome el conjunto de
arquetipos definidos en la base del conocimiento
– Listo

58
Profundización
http://www.openehr.org

59
¡Muchas gracias!
Pablo Pazos Gutiérrez
pablo.swp@gmail.com
http://informatica-medica.blogspot.com

Taller open ehr cais 2010 - pablopazos

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (13)

Similar a Taller open ehr cais 2010 - pablopazos

Similar a Taller open ehr cais 2010 - pablopazos (20)

Más de Pablo Pazos

Más de Pablo Pazos (20)

Último

Último (15)

Taller open ehr cais 2010 - pablopazos