taller open ehr cais 2010 - pablopazos

1

Taller de OpenEHRUn estándar para crear HCEs

Pablo Pazos Gutiérrezhttp://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

Presenter

Presentation Notes

Conceptos Arquetipos, Tamplates, Modelo dual, Modelo de información clínica, etc Ejemplos Instancias de estructuras de datos clínicos, arquetipos, templates, etc. Herramientas Editor de arquetipos, vamos a ver y a crear arquetipos. Y acceder al gestor de contenidos. Arquitectura Componentes de una HCE, repositorios, contactos con otros estándares, etc.

4


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

¿Cómo hacemos SIS hoy?• 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

Presenter

Presentation Notes

Este sería nuestro “modelo de dominio”, obviamente, hay otros conceptos como el propio paciente y el médico.

9

• Punto de vista de la arquitectura– Cuatro capas

• Interfaz de usuario• Lógica de negocio• Persistencia• Servicios


Presenter

Presentation Notes

Implementación Peor caso: Un cambio en el conocimiento clínico, y habrá que tocar las 4 capas, por ejemplo al agregar un dato en la información de un concepto clínico. Mejor caso: Se tiene un editor de formularios, donde el cambio se hace simplemente agregando un campo. PROBLEMA: ese editor de formularios solo sirve para ese sistema particular, ¿que pasa si quiero compartir esa definición de formulario con otros sistemas distintos?

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….


Presenter

Presentation Notes

Hay tanta información clínica para registrar como hay conceptos clínicos en el dominio.

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.


Presenter

Presentation Notes

Muchos problemas radican en “cómo hacemos los sistemas”, no en los sistemas en sí. Arquitectura Implementación de componentes “a medida” dificulta el mantenimiento y la adaptabilidad del software a largo plazo. Funcionalidad Nuevos requerimientos en la funcionalidad básica del sistema, afectan a diversos componentes, también dificulta el mantenimiento a largo plazo. Peor caso: cuando se implementa el registro de cada tipo de información, se implementa lógica particular para resolver la interfaz de ususario, el procesamiento y la persistencia de los datos.

13

¿Cómo hacemos SIS hoy? 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).

Presenter

Presentation Notes

Cada departamento tiene su propia forma de funcionar, su propia forma de atender al paciente, sus reglas, sus competencias, etc. Cada departamento tiene su forma generar y registrar la información sobre la atención médica del paciente. Pero la medicina es una sola, y mucha de la información que se registra en distintos departamentos es la misma. Se manejan los mismos conceptos clínicos pero no hay correspondencias en cómo se usan (datos, estructuras, relaciones).

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


Presenter

Presentation Notes

Formulario = Ficha = Interfaz donde el usuario ingresa datos. Cuando hay que hacer un cambio en el registro clínico, p.e. agregar un campo, es necesario modificar varias áreas del sistema Interfaz de usuario, Lógica de negocio, Persistencia, Servicios

15

El enfoque “novedoso”

16


• 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.

Presenter

Presentation Notes

Esta es la parte de motivación. Luego de los puntos 1 y 2: Quienes hacen herramientas y quienes conocen el sistema de salud por dentro no son las mismas personas.

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

Presenter

Presentation Notes

En el proceso actual de desarrollo de software en salud muchas veces se sigue lo contrario: Componentes a medida, sin reusabilidad No se aplican estándares, se hace “a ojo de buen cubero”, o sea “al tanteo” No hay un procedimiento establecido de cómo hacer las cosas, resultando en una calidad variable La rueda se reinventa cada vez El informático hace todo, debe hacer de médico, de técnico, de administrativo, debe conocer procesos y terminología, se hace cargo del trabajo de los demás

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.

Presenter

Presentation Notes

Motivacion para crear mejores sistemas de HCE. Hasta acá son unos 20 min.

19

Agenda Parte1:




Modelo dual

Herramientas I

Parte 2:

Arquitectura

Herramientas II

Discusión

Presenter

Presentation Notes

Conceptos Arquetipos, Templates, Modelo dual, Modelo de información clínica, etc Ejemplos Instancias de estructuras de datos clínicos, arquetipos, templates, etc. Herramientas Editor de arquetipos, vamos a ver y a crear arquetipos. Y acceder al gestor de contenidos. Arquitectura Componentes de una HCE, repositorios, contactos con otros estándares, etc.

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.

Presenter

Presentation Notes

La idea es concentrarse en “cómo” hacer los sistemas.

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.

Presenter

Presentation Notes

Alto costo en etapa de producción: en general los proyectos no calculan este costo y queda “oculto”. Hace que el producto quede estático, perdiendo efectividad a medida que pasa el tiempo.

22


• HCE Virtual

Presenter

Presentation Notes

A nivel macro lo que tendríamos es: Una capa superior de servicios, tanto para personas como para otros sistemas. Una capa clínica intermedia con los SIS. Una capa inferior de conocimiento, en el cual todos los SIS deben basarse para tener consistencia semántica entre sus registros. Correspondencias con el mismo modelo de referencia genérico. Mismos conceptos clínicos, con un mismo propósito.

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

Presenter

Presentation Notes

Modelo dual: más detalles luego...

24

Agenda Parte1:




Modelo dual

Herramientas I

Parte 2:

Arquitectura

Herramientas II

Discusión

Presenter

Presentation Notes


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


Presenter

Presentation Notes

Primero ver cómo se organiza la información clínica en general para luego ir al detalle del modelo de información de openEHR Organización de registros (dibujo en pizarron): Carpetas para organizar registros de distintos servicios o departamentos. Etiquetas o códigos de colores para organizar los registros de un servicio o departamento. Cada registro es un conjunto de entradas en las que se registra distintos tipos de información estructurada según algún criterio. (un problema se da cuando el criterio de estructuración no está claro, ya que distintos servicios pueden estructurar la misma información de distintas formas, las cuales pueden ser incompatibles: caso presión como un campo (130-90 vs 130/90 vs 130,90 vs 90-130) o como 2 más unidad).

26

Resumen del modelo de información normalizado de OpenEHR


Presenter

Presentation Notes

Organización interna de un registro clínico según el modelo de información clínica de referencia normalizado. Composition: modela cualquier documento, mensaje, resumen, informe, etc. De información clínica. Es la unidad de información de más alto nivel Está compuesta de entradas o secciones. Secciones: sirven para organizar las entradas de una composition (documento, mensaje, informe, etc). Internamente las entradas están formadas por estructuras de datos genéricas. Y los datos son de diversos tipos: Cantidades Fechas Texto Texto codificado Intervalos (de tiempo, valores, etc) Identificadores Etc.

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 clínicaModelo de información genérico de entradas

Presenter

Presentation Notes

Las entradas clínicas en la HCE son de 4 clases: Observación: se utiliza para registrar hechos, observaciones y medidas. Evaluación: se utiliza para registrar deducciones hechas de las observaciones. Instrucción: una instrucción es algo que se indica para ser hecho, y puede estar formada por varias actividades. Acción: cada acción tiene un tiempo en el que se realiza, una descripción de lo realizado y la referencia la instrucción y actividad que generó esa acción. Otra información es la del estado actual de la acción. Muchas acciones no son puntuales y se ejecutan a lo largo del tiempo, y tienen que asociadas una máquina de estados. Existe un quinto tipo de entrada, utilizado para registrar datos administrativos.

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:




Modelo dual

Herramientas I

Parte 2:

Arquitectura

Herramientas II

Discusión

Presenter

Presentation Notes


35

OpenEHR modelo dualModelo 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

37

Modelo de conocimiento

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

Modelo de conocimientoOBSERVATION[at0000] matches { -- Blood Pressuredata matches {HISTORY[at0001] matches { -- historyevents cardinality matches {1..*; unordered} matches {EVENT[at0006] occurrences matches {0..*} matches { -- any eventdata matches {ITEM_TREE[at0003] matches { -- blood pressureitems cardinality matches {0..*; unordered} matches {ELEMENT[at0004] occurrences matches {0..1} matches { -- Systolicvalue 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 { -- Diastolicvalue matches {C_DV_QUANTITY <property = <[openehr::125]>list = <["1"] = <units = <"mm[Hg]">magnitude = <|0.0..<1000.0|>precision = <|0|>

...

...

43

Modelo de conocimientoInstancia del modelo de información que cumple con el arquetipo del ejemplo de ADL:

44

Agenda Parte1:




Modelo dual

Herramientas I

Parte 2:

Arquitectura

Herramientas II

Discusión

Presenter

Presentation Notes


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:




Modelo dual

Herramientas I

Parte 2:

Arquitectura

Herramientas II

Discusión

Presenter

Presentation Notes


48

Arquitectura de una HCE• Sistema mínimo de HCE según OpenEHR

Base de conocimiento

Repositorio de información clínica

Repositorio de datosdemográficos de pacientes

Presenter

Presentation Notes

Repositorio de historias clínicas electrónicas como COMPOSITIONS OpenEHR Desde ese repositorio de datos clínicos se referencia de forma indirecta a los conceptos demográficos de las personas relacionadas con esos registros. Los conceptos demográficos de OpenEHR sacan sus datos de un IMP local. Y la base de conocimiento está formada por arquetipos y terminologías.

49

Arquitectura de una HCE• Arquitectura en funcionamiento

50

Agenda Parte1:




Modelo dual

Herramientas I

Parte 2:

Arquitectura

Herramientas II

Discusión

Presenter

Presentation Notes


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

• Open EHR Standard Architecture– 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

• Open EHR Standard Architecture

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 [email protected]

http://informatica-medica.blogspot.com

taller open ehr cais 2010 - pablopazos

Technology