Informática Médica y Estándares

Conclusiones del curso de openEHR en español

2012-01-03T13:49:00.003-02:00

Este curso surgió por mi interés en difundir una nueva forma de hacer sistemas de información en salud, tal que se reduzcan o eliminen los problemas que tienen actualmente estos sistemas, muchos de ellos causados por la forma en la que se desarrollan.

Esta nueva forma, más inteligente, plantea la creación de sistemas concentrándonos en el conocimiento clínico, dejando la tecnología en un segundo plano. Y por otro lado, promueve la adopción de estándares para garantizar la interoperabilidad.

¿Qué es openEHR?

Sobre el curso

Mi objetivo fue realizarlo antes de 2012, y gracias a ACHISA ese objetivo se cumplió en tiempo y forma.

Tuvimos solo una semana de difusión y apertura de inscripciones, y alcanzamos a tener 51 inscriptos, de los cuales quedaron 38 estudiantes que realizaron el curso. Estos estudiantes fueron de 6 países: Chile, Argentina, Colombia, Venezuela, España y Portugal. El perfil de los alumnos fue muy heterogéneo, mayoritariamente médicos, enfermeros, ingenieros y estudiantes de pregrado y postgrado.

La convocatoria fue un éxito y, al mismo tiempo, una gran responsabilidad. Además superó todas las expectativas que teníamos para una primera edición de un curso sobre un tema poco difundido en América Latina.

Lo que dijeron nuestros alumnos

Estas son las palabras de nuestros alumnos en la encuesta de evaluación del curso:

"Gracias por tan importante curso, debemos ampliar cobertura y enlazarnos como comunidad en Latinoamérica. Gracias a ACHISA, en verdad superaron en mucho mis expectativas!"

"Me pareció muy completo, bien confeccionado, generó la participación de todos e incluso, nos dejó a todos con las ganas de seguir conectados. No he visto una situación similar en ninguno de los cursos que he realizado."

"Me pareció uno de los mejores cursos que he realizado."

"Sobre el contenido del curso, considero que si bien es muy completo y cubre todo lo necesario"

"Muy bueno el material de lectura, aunque no los entendía bien, por algunas cosas ser lenguaje muy técnico, pero en las clases online se resolvia."

"The support materials, (PDFs and slides) were fantastic. Some of the best I've seen. Great tools to learn about the standard in a very approachable way. The forums were also a great resource."

"El orden, la temática son excelente como así también la modalidad implementada para la capacitación ya que de otra manera seria imposible para quienes no contamos con la posibilidad de desplazarnos para la misma. Los materiales entregados por el curso son de excelente calidad, como asi también las recomendaciones."

En general los alumnos solicitaron mejoras para futuras ediciones:

Crear guías y dar ejemplos de creación de arquetipos.
Profundización sobre distintos conceptos (modelos, arquetipos, templates).
Profundización sobre el diseño y desarrollo de software orientado al uso de openEHR.
Agregar ejemplos sobre la relación con otros estándares (DICOM, HL7, SNOMED, ISO/CEN 13606).
Agregar ejemplos de interoperabilidad con openEHR.
Crear talleres de práctica con herramientas (Archetype Editor, ADL Workbench, EHRGen).
Agregar guías sobre generación de interfaces de usuario a partir de arquetipos y templates.

Conclusiones y trabajo futuro

Sin dudas el curso nos dejó a todos con ganas de aprender más. El objetivo para 2012 es mejorar el curso en los aspectos más prioritarios para nuestra región, para poder aplicar estos conocimientos en nuestros respectivos países. También se atenderán las solicitudes de los alumnos, algunas tendrán repercusión directa en el temario del curso, y otras se tomarán en cuenta para generar otros cursos y talleres que puedan servir para complementar y profundizar los conocimientos adquiridos.

Un objetivo a mediano plazo es el de poder emitir certificados con validez ante la comunidad internacional de openEHR. El plan es proponer un currículo mínimo, con temas y formas de evaluación, para discutir y llegar a un consenso con la comunidad de openEHR. Nos pondremos el objetivo de tener en 2013 el primer curso con certificación internacional.

Por otro lado, también buscaremos fortalecer la comunidad de openEHR en español, primero apoyando al área de capacitación, y luego a la colaboración, tanto para la implementación de proyectos, como para la investigación científica. También buscaremos traducir a español los recursos disponibles en openEHR internacional (mayoritariamente en inglés). Otra línea de acción será fomentar la generación grupos de investigación y desarrollo a nivel nacional en América Latina y el Caribe.

Uno de los problemas que vimos en el curso es la falta de herramientas de código abierto que permita la adopción rápida de openEHR. Por esta razón propusimos 10 proyectos para el desarrollo de herramientas de software, y para el mejoramiento de las herramientas abiertas existentes. Pero no todo es software, también necesitamos más modeladores de conocimiento clínico (médicos, enfermeros, técnicos, etc.) para construir bases de conocimiento que cubran las necesidades de los registros clínicos a nivel nacional, y permitan reutilización e interoperabilidad a nivel internacional. A continuación se muestra un diagrama de estos proyectos:

Propuesta de herramientas para la adopción de openEHR

Lo que necesitamos son herramientas que permitan expresar el conocimiento del dominio de la salud, desde los procesos, pasando por los registros clínicos, y llegando hasta los conceptos clínicos (arquetipos, terminología). Todos estos "artefactos de conocimiento", que residen en la "base de conocimiento", pueden ser accedidos por el software de Historia Clínica Electrónica (HCE) para seguir distintos procesos clínicos, para registrar y validar información en función de cierto concepto, y para intercambiar información de distintos conceptos clínicos con otros sistemas (interoperabilidad semántica).

También se debe tener soporte a la toma de decisiones de forma integrada a la HCE, cuyas reglas estén basadas en los artefactos de conocimiento (reglas semánticas). Esto servirá tanto para el soporte de las decisiones clínicas, como para el control de enfermedades y vigilancia poblacional.

Todos los artefactos de conocimiento podrán ser compartidos entre diversos sistemas, incluso fuera del país. Y las bases de conocimiento pueden ser generadas a nivel local, regional, federal, nacional o internacional.

Se buscará colaboración con distintas universidades para poder llevar a cabo estos proyectos a mediano plazo, y dejar disponibles las herramientas a toda la comunidad, de forma que permitan la generación de planes piloto y de trabajos de investigación avanzados.

Agradezco profundamente a ACHISA por la oportunidad de realizar el curso, y a todos los alumnos del curso que dieron su voto de confianza para que este primer curso fuera un éxito. Gracias a todos, seguiremos trabajando!

Bonus track: evaluación de los alumnos

Nuevo Open EHRGen v0.7

2012-01-02T23:21:00.000-02:00

Estoy muy contento de anunciar la liberación de la nueva versión de Open EHRGen, la herramienta para crear Historias Clínicas Electrónicas estándar, basadas en la gestión del conocimiento clínico.

Descarga: http://code.google.com/p/open-ehr-gen-framework/downloads/list
Instalación: http://code.google.com/p/open-ehr-gen-framework/wiki/Instalacion

¿Qué es EHRGen?

No es un software de EHR, es un framework que permite crear uno.

Con la ventaja de que es genérico y está diseñado para soportar cualquier estructura de registro clínico, desde un registro simple completamente en texto libre, hasta un registro completamente estructurado y tan complejo como sea necesario.

Para ajustar los registros clínicos no es necesario modificar el código fuente de EHRGen, todo se hace por fuera del software y la integración es por configuración. Los registros clínicos se representan mediante templates, que utilizan conceptos clínicos representados como arquetipos openEHR. Los arquetipos permiten modelar conceptos clínicos tales como la presión arterial, frecuencia cardíaca, diagnósticos, evaluación de vía aérea, administración de medicamentos, etc., definiendo su propósito y estructura interna de forma genérica, estándar y procesable por computadora (más info sobre openEHR).

Los arquetipos y templates conforman una base de conocimiento capaz de ser utilizada por EHRGen para generar pantallas de registro clínico web para los profesionales de la salud.

EHRGen es un proyecto de código abierto en pleno desarrollo, se agradece la difusión del mismo.

Principales cambios con respecto a la versión 0.6:

Búsqueda semántica

Esta es la característica más interesante de la nueva versión. La búsqueda semántica permite que un profesional de la salud realice búsquedas basadas en conceptos clínicos y sus componentes, permitiendo una agregación de datos simple.

La ventaja desde el punto de vista del software es que estas búsquedas son genéricas, basándose únicamente en los conceptos clínicos (arquetipos) y sus elementos (identificados mediante rutas). Esto repercute en que las búsquedas no necesitan ser implementadas a medida, y que si se agregan nuevos arquetipos a la base de conocimiento, se pueden realizar búsquedas en base a esos conceptos clínicos sin necesidad de ningún cambio en el código fuente de la aplicación.

En las próximas versiones se dará más flexibilidad a las agregaciones de datos y a los filtros de la búsqueda. Una que EHRGEn esté instalado y corriendo, para ingresar a la búsqueda semántica se debe ingresar a http://localhost:8080/ehr/archetypeManager/query

Para realizar una búsqueda semántica, el profesional de la salud debe seleccionar un concepto clínico en el listado de conceptos clínicos:

Búsqueda semántica: listado de conceptos clínicos

Una vez seleccionado el concepto, se deben seleccionar las rutas (paths) a los elementos de interés dentro de la estructura del concepto clínico:

Búsqueda semántica: selección de concepto "triage de trauma"

Cuando se seleccionan las rutas y se hace clic en el botón "seleccionar paths", se muestran los datos registrados en el sistema para ese concepto clínico y esas rutas, agrupadas por el registro clínico de cada paciente:

Búsqueda semántica: selección de rutas dentro del concepto "triage de trauma"

Por último, para los datos de tipo DvCodedText o DvOrdinal, es posible seleccionar los datos para agregarlos en clases. Por ejemplo, el elemento "evaluación de trauma" es DvOrdinal, y tiene 5 valores posibles, en la siguiente imagen se muestra la agregación de los registros existentes en esos valores posibles:

Búsqueda semántica: agrupación de datos para una ruta

Mejoras en el uso de templates

EHRGen utiliza los templates para generar pantallas de registro clínico. Una de las mejoras es la generación de pantallas para cualquier idioma configurado en la herramienta, esto permite reutilizar los conceptos clínicos modelados en arquetipos para crear Historias Clínicas Electrónicas estándar a nivel internacional.

Otra mejora es el versionado de templates, permitiendo evolucionar las pantallas de registro indefinidamente. Por ejemplo, si se tiene un template.v1 y se realizan registros clínicos en la pantalla generada con ese template, pero luego se requieren hacer cambios, generando un template.v2, los registros para la versión anterior del template quedan incambiados y se pueden visualizar sin problemas. Mientras que los nuevos registros se guardan utilizando el template.v2.

Mejoras con respecto a la seguridad

En la versión 0.6 se comenzó la implementación de la verificación por rol de usuario de la autorización para ejecutar acciones en el sistema. En la versión 0.7 se agrega la gestión de permisos por dominio (ambulatorio, hospitalización, emergencia, etc.) y por tipo de registro clínico (template). En las próximas versiones se culminará la implementación completa con la gestión y verificación de permisos por rol, dominio, template, acción y también por credenciales del usuario (por ejemplo especialidad de un médico).

Listado de roles

Listado de permisos para el rol Médico

Gestión de personas

Correcciones generales y mejoras

Se corrigen pequeños errores encontrados, se agregan traducciones de términos, se mejoran aspectos de interfaz de usuario, y se corrigen las rutas al filesystem en linux (gracias por reportar el problema a los usuarios de linux).

Recorrida general por la aplicación

Este ejemplo muestra a EHRGen utilizando una base de conocimiento donde está modelado el registro clínico de emergencia de trauma. Otros dominios pueden ser modelados de forma análoga, esto es totalmente configurable.

Autenticación de usuarios

Listado de dominios

Listado de registros dentro del dominio de trauma

Vista de un registro en el dominio de trauma

Registro del triage (autogenerado a partir de template y arquetipos)

Registro de evaluación del estado circulatorio (autogenerado a partir de template y arquetipos)

Selección de diagnósticos CIE-10

Búsqueda de paciente para asociar al registro clínico

Resultado de búsqueda de pacientes

Selección de paciente para el registro actual

¡Seguiremos trabajando para crear mejores EHRs!

Vota por mi blog en e concurso de Healthline

2011-12-22T15:27:00.002-02:00

Vota por mi blog "INFORMÁTICA MÉDICA Y ESTÁNDARES" para el concurso de blogs de healthline http://www.healthline.com/health/best-health-blogs-contest

Best Health Blogs of 2011 Contest | Healthline

www.healthline.com

Enter Healthline's Best Health Blog of 2011 Contest & be eligible to win up to $5000. Nominate & vote for your favorite health, fitness & wellness blogs now!

Se agradece la difusión!

Iniciativa de modelos de informacion clinica: openEHR elegido

2011-12-14T23:11:00.000-02:00

CIMI (Clinical Information Modeling Initiative) es una colaboración internacional que busca proporcionar un formato común para las especificaciones detalladas de la representación de la información de salud, buscando que la información semánticamente interoperable pueda ser creada y compartida entre diversos registros de salud, mensajes y documentos.

Les dejo el texto original de la selección de los modelos, perdonen que está en inglés (usar google translate para leer en español: http://translate.google.com/).

Clinical Information Modelling Initiative goes with Archetypes & UML profile

[press release from the CIMI group]

The Clinical Information Modeling Initiative is an international collaboration that is dedicated to providing a common format for detailed specifications for the representation of health information content so that semantically interoperable information may be created and shared in health records, messages and documents. CIMI has been holding meetings in various locations around the world since July, 2011. All funding and resources for these meetings have been provided by the participants. At its most recent meeting in London, 29 November - 1 December 2011, the group agreed on the following principles and approach.

Principles

1. CIMI specifications will be freely available to all. The initial use cases will focus on the requirements of organisations involved in providing, funding, monitoring or governing healthcare and to providers of healthcare IT and healthcare IT standards as well as to national eHealth programs, professional organisations, health providers and clinical system developers.

2. CIMI is committed to making these specifications available in a number of formats, beginning with the Archetype Definition Language (ADL) from the openEHR Foundation (ISO 13606.2) and the Unified Modeling Language (UML) from the Object Management Group (OMG) with the intent that the users of these specifications can convert them into their local formats.

3. CIMI is committed to transparency in its work product and process.

Approach

ADL 1.5 will be the initial formalism for representing clinical models in the repository.

CIMI will use the openEHR constraint model (Archetype Object Model:AOM).
Modifications will be required and will be delivered by CIMI members on a frequent basis.

A set of UML stereotypes, XMI specifications and transformations will be concurrently developed using UML 2.0 and OCL as the constraint language.
A Work Plan for how the AOM and target reference models will be maintained and updated will be developed and approved by the end of January 2012.

Lessons learned from the development and implementation of the HL7 Clinical Statement Pattern and HL7 RIM as well as from the Entry models of 13606, openEHR and the SMART (Substitutable Medical Apps, Reusable Technologies) initiative will inform baseline inputs into this process.

A plan for establishing a repository to maintain these models will continue to be developed by the group at its meeting in January.

Representatives from the following organizations participated in the construction of this statement of principles and plan

B2i Healthcare www.B2international.com
Cambio Healthcare Systems www.cambio.se
Canada Health Infoway/Inforoute Santé Canada www.infoway-inforoute.ca
CDISC www.cdisc.org
Electronic Record Services www.e-recordservices.eu
EN 13606 Association www.en13606.org
GE Healthcare www.gehealthcare.com
HL7 www.hl7.org
IHTSDO www.ihtsdo.org
Intermountain Healthcare www.ihc.com
JP Systems www.jpsys.com
Kaiser Permanente www.kp.org
Mayo Clinic www.mayoclinic.com
MOH Holdings Singapore www.mohh.com.sg
National Institutes of Health (USA) www.nih.gov
NHS Connecting for Health www.connectingforhealth.nhs.uk
Ocean Informatics www.oceaninformatics.com
openEHR Foundation www.openehr.org
Results4Care www.results4care.nl
SMART www.smartplatforms.org
South Korea Yonsei University www.yonsei.ac.kr/eng
Tolven www.tolven.org
Veterans Health Administration (USA) www.va.gov/health

Further Information

In the future CIMI will provide information publicly on the Internet. For immediate further information, contact Stan Huff (stan.huff@imail.org)

Curso de openEHR en español: inscripciones abiertas

2011-11-18T00:02:00.000-02:00

1er curso virtual de openEHR en español

“openEHR: EL ESTÁNDAR ABIERTO PARA HISTORIAS CLÍNICAS ELECTRÓNICAS A PRUEBA DE FUTURO”

Luego de grandes esfuerzos y la ayuda invaluable de los amigos de ACHISA, pudimos lanzar el curso antes de fin de año.

En la página de ACHISA están los datos del curso, el temario y el formulario para inscribirse. Por favor no esperen hasta el último momento para inscribirse porque tenemos poco tiempo!

Info: http://www.achisa.org/

Inscripción: https://docs.google.com/spreadsheet/viewform?formkey=dFhfNTdiUkNFU0pXaldfcGczN1JELVE6MQ

Temario y cronograma: http://www.achisa.org/PDF/Brochure_OpenEHR_ACHISA_ed1.pdf

Los esperamos!

Curso de openEHR en español

2011-10-16T20:13:00.007-02:00

Estimados,

He definido el temario del curso. Ahora estoy intercambiando con colegas para evaluar su interés en la temática del curso y poder definir una fecha de comienzo.

Lo estoy preparando para que sea virtual, tal vez en una segunda edición podría hacerse de forma presencial.

Los requisitos para el curso son bastante laxos porque la idea es hacerlo amplio y autocontenido, pero es bueno si el alumno/a tiene nociones en:

UML: modelado de entidades y procesos
Arquitectura de sistemas
Sistemas de información (mejor si son en salud)

El tiempo total del curso para el alumno está calculado en 50hs: 24hs de clase, 16hs en 2 trabajos obligatorios, y 10 horas de estudio/lectura personal.

En este momento me encuentro terminando de armar y traducir el material de lectura que usaremos como referencia en el curso.

Aquí les dejo el temario actualizado al 29/10/2011:

Semana 1

Clase 1

Principales problemas de los sistemas informáticos clínicos.
Soluciones desde openEHR para resolver estos problemas.
Portal de openEHR internacional: recorrida para buscar información útil.
Los proyectos openEHR: especificación, software, modelos clínicos.
Conceptos clave en openEHR: el modelo dual, arquetipos, plantillas, conceptos clínicos, estructura de la información clínica.

Clase 2

El EHR según openEHR
Plataforma informática de EHR
Principales requerimientos de un EHR (ISO 18308 y openEHR).
Introducción al modelo dual y al modelo multinivel.

Semana 2

Clase 3

Introducción al modelo de información de openEHR: modelo de entradas basado en el modelo de resolución de problemas clínicos y la ontología de registro clínico.
Principales clases del modelo de información de openEHR: Composition, Section, Entry, DataStructure, History, Cluster y Element. Relación con otros modelos (HL7v3, ISO 13606, ASTM CCR).
Modelo de tipos de datos de openEHR. Relación con otros modelos (HL7v3, ISO 13606, ASTM CCR).

Clase 4

Modelo demográfico. Relación con otros modelos (HL7v3, ISO 13606, ASTM CCR).
Ejemplo de instancia completa de los modelos: EHR, tipos de datos y demográfico.

Semana 3

Clase 5

El modelo dual: conceptos, objetivos, artefactos.
Modelo de conocimiento: conceptos clínicos
Introducción a ADL (Archetype Definition Language)

Clase 6

Introducción a AOM: el modelo de arquetipos. Conceptos básicos: identificadores, rutas, versiones, ocurrencias, cardinalidad.
Ejemplos de ADL y AOM.
Conceptos de desarrollo de arquetipos y control de control de versiones.

Semana 4

Clase 7

Archetype Editor: creando nuestros primeros arquetipos.
Clinical Konwledge Manager: utilizando arquetipos existentes.
Trabajo 1: Presentación del taller de modelado.

Clase 8

Creando arquetipos avanzados: instrucciones y acciones. El manejo de la máquina de estados de la instrucción.
Caso de estudio: modelado y funcionamiento de instrucciones y acciones.

Semana 5

Clase 9

Introducción a plantillas y cambios para AOM 1.5. Restricciones de validez.
ADL Workbench: validando arquetipos.
Open EHR-Gen Framework: caso práctico de uso de arquetipos en un EHR.

Clase 10

Estrategias de implementación de openEHR, uso de arquetipos y plantillas en la práctica.
¿Cómo integrarlos a nuestros sistemas de información?
Visión desde los datos, estrategias de persistencia de información clínica jerárquica.
Visión desde la interfaz de usuario.

Semana 6

Clase 11

Integración de openEHR con otros estándares: DICOM, CDA, HL7v3, Terminologías y codificaciones.
Trabajo 2: planteo de temas para el trabajo escrito.
Entrega del trabajo 1.

Clase 12

Conceptos de seguridad, control de acceso, confidencialidad e integridad de los datos en openEHR.
Conceptos de control de cambios, eventos, contribución, participación, firma, auditoría.
Resumen y conclusiones del curso.

Y este es un texto a modo de motivación para difundir el curso:

1er curso virtual de openEHR en español

“openEHR: el estándar abierto para historias clínicas electrónicas a prueba de futuro”

El estándar openEHR define las bases para crear sistemas de historia clínica electrónica normalizados, flexibles, adaptables, extendibles, genéricos e interoperables.

Su propuesta de “modelo dual” basado en artefactos de conocimiento presenta un cambio de paradigma en el desarrollo de los sistemas de información en salud. Esta propuesta habilita a la evolución del conocimiento y la información clínica de forma independiente a los cambios tecnológicos. Permitiendo así la evolución de los sistemas de información en salud.

Los artefactos (arquetipos, plantillas y terminologías) pueden ser creados y compartidos entre distintos sistemas, manteniendo una coherencia semántica y consistencia estructural que permite la interoperabilidad semántica entre sistemas.

Estos artefactos forman una “base de conocimiento” que permite crear una historia clínica virtual, formada por diversos sistemas de información clínicos y paraclínicos, creados con diferentes tecnologías y objetivos, para brindar un conjunto global de servicios de forma homogénea.

Este enfoque busca crear un contexto distribuido, abierto e independiente para los sistemas de información en salud, y es diametralmente opuesto al enfoque centralizado-monolítico.
Aunque ambos enfoques buscan lograr el mismo resultado, el centralizado-monolítico no se corresponde con la realidad distribuida de los sistemas de salud, y parte del fracaso de la informatización en salud se debe a este hecho.

El nuevo paradigma de openEHR propone una mejor solución que vale la pena explorar. http://en.wikipedia.org/wiki/OpenEHR

Capacitacion en openEHR: estándar libre de HCE

2011-09-30T01:49:00.000-03:00

Disculpen la introducción tan personal, quiero dar el contexto completo del tema principal de este artículo: diseñar cursos sobre openEHR.

Un poco de contexto: haciendo un balance personal

Desde 2006 formo parte de la comunidad de openEHR internacional. Primero estudiando el estándar, luego probando distintas partes de la implementación. En 2010 terminé mi tesis de grado con un proyecto 100% basado en openEHR: el estándar libre para el desarrollo de historias clínicas electrónicas. Y en 2011 escribí junto a la Dra. Selene Indarte una publicación para CEPAL sobre interoperabilidad y estándares en Informática Médica (IM) (espero se publique antes de fin de año, igual pronto haré un artículo con los principales puntos de la publicación).

Hoy ya soy Ingeniero en Computación (título en trámite), sigo especializándome en estándares en IM (openEHR sobre todo), dirijo un proyecto de código abierto basado en openEHR, y he dictado capacitación y he dado charlas sobre distintos estándares (openEHR, HL7 CDA, CCR/CCD, DICOM, ...).

El perfil que estoy tratando de construir no está basado en el desarrollo de aplicaciones (en realidad programo por necesidad), lo que más me gusta es la gestión de proyectos, diseño y arquitectura de sistemas, la docencia, y la asesoría de proyectos en temas de estándares en IM e interoperabilidad.

Desde hace un tiempo, todo lo que leo y todo lo que aprendo trato de compartirlo con la comunidad, porque estoy convencido de que el conocimiento que no se comparte, no tiene razón de ser. Este blog es prueba de eso. También otros blogs y grupos de discusión que he creado. Hoy estoy tratando de formalizar un poco esa tarea de compartir conocimiento, y me encuentro armando un curso dirigido a openEHR, aunque rozando otros estándares importantes.

¿Porqué un curso de openEHR?

Hoy en día, openEHR es el único estándar orientado a la creación de sistemas de Historia Clínica Electrónica (HCE), de forma que sea interoperable desde el registro de la información clínica. Mi visión personal es que openEHR plantea una guía de cómo construir una buena HCE, mientras que otros estándares se centran en comunicar información clínica sin importar mucho si la HCE es buena o mala, es decir, si al comunicar la información que esta contiene, el resultado será consistente con el propósito de la información cuando esta fue registrada.

En mi artículo de introducción a openEHR puedes encontrar más información.

Además, consideremos el contexto actual en América Latina y el Caribe: existen numerosos proyectos de HCE en curso, se está comenzando a masificar el dictado de capacitación formal en IM tanto a informáticos como a médicos, y hay múltiples eventos cada mes que tocan el tema de la HCE. En este contexto ¿importa más crear una buena HCE o la comunicación entre sistemas? Mi respuesta es la primera, ya que la comunicación no puede existir si una buena HCE.

Otro argumento fuerte es que múltiples instituciones se encuentran en proyectos de reingeniería, cambiando sus HCEs anteriores por nuevas. Y esto no es un recambio tecnológico, es una adecuación de la HCE a la realidad, es decir que las HCEs anteriores no eran del todo buenas. ¿Qué hubiera pasado con buenas HCEs? Una buena HCE es flexible y adaptable por diseño, y si consideramos los costos de reingeniería, tal vez nos salga más barato invertir más tiempo en crear buenas HCEs.

El curso de openEHR que estoy diseñando

La idea central del curso es brindar una visión global del estándar, que se concentra en partes clave como el modelo de información y el modelo de arquetipos. Pero como no me gusta quedarme en lo conceptual, voy a mostrar cómo se integran esos conceptos con sistemas informáticos reales.

El núcleo del curso está basado en un taller que dicté el año pasado en el Congreso Argentino de Informática y Salud: http://www.slideshare.net/pablitox/taller-open-ehr-cais-2010-pablopazos
Este taller fue un verdadero desafío. Fueron 4 horas de taller y vinieron unas 14 personas (era más de lo que esperaba porque nadie me conocía y al lado había una charla de HL7 con gente super conocida). Igual la gente vino (y se quedó!), el 80% eran médicos, y la verdad se engancharon mucho con la temática. Luego me dio un poco de lástima que no pudieran profundizar más en el tema, y desde entonces me quedé con "la espina" de hacer algo más. Interés hay.

Este es un ejemplo de temario simplificado del curso:

Conceptos básicos: ¿qué es openEHR? ¿qué es un arquetipo? ¿qué es un template?
Analizando la realidad: conceptos clínicos, registros, procesos, estandarización, especificación.
Modelado: conceptos clínicos, información, interfaz de usuario, reglas de negocio.
Herramientas disponibles: gestor de conocimiento, editor de arquetipos, implementaciones de referencia.
Casos de estudio: creando una HCE para distintos dominios (emergencia, ambulatorio, internación, distintas especialidades)
Integración con estándares de contenido: Snomed, CIE 9, CIE 10, CIAP-2, Mesh, ATC.
Relación con otros estándares: ISO 13606, HL7 CDA, DICOM.
Comunicación con sistemas externos: interoperabilidad sintáctica, semántica y de negocio/proceso.

También estoy jugando con la idea de hacer algo especialmente para médicos con orientación informática, orientado a el modelado de información clínica, que podría ser un subconjunto del temario anterior. El objetivo de este cursillo sería promover métodos, herramientas, buenas prácticas y modelos de información clínica, para que los médicos que se encarguen de diseñar los registros clínicos, tanto electrónicos como en papel, puedan hacerlo lo mejor posible.

Algunos puntos que se podrían incluir son:

Conceptos básicos: ¿qué es un ...? (modelo, dato/información/conocimiento, proceso, registro, historia clínica, estructura de información, protocolo, estándar, concepto, ...).
Análisis de un caso de estudio: diseñar el registro clínico para el mismo.
Entre la libertad de registro y el registro estructurado: ventajas y desventajas.
Estructurando el registro: desde el dato a la historia clínica
Modelos de información clínica: identificando conceptos de la HC con openEHR, HL7 CDA, ASTM CCR e ISO 13606.
El registro contextualizado al proceso de atención: ¿quién? ¿para quién? ¿cuándo? ¿cómo? ¿dónde?
Análisis de caso de estudio: revisitando el caso de estudio y volviendo a diseñar el registro clínico.
Puesta a punto evaluando las diferencias entre los dos casos de estudio.

Planificación para el futuro

Uno de los objetivos de este artículo es medir el nivel de interés en la temática que planteo. El otro es saber su opinión sobre la temática, sobre lo que podría ser más interesante para incluir, o sobre lo que se podría hacer más hincapié.

También me gustaría ponerme en contacto con instituciones afines con la temática donde pueda dictar el curso, ya que mi idea para los próximos meses es vivir de la docencia. Además que voy a comenzar con mis estudios de maestría y podría hacer algún curso en la misma institución (para matar dos pájaros de un tiro).

Espero sus comentarios, y si saben de alguna institución que se pueda interesar, me avisan. Se agradece la difusión!

Un abrazo a todos.

PD: en mi cuenta de SlideShare hay más recursos.

Nueva version de OpenEHR-Gen Framework

2011-09-23T02:18:00.000-03:00

Estoy muy contento de anunciar una nueva liberacion de Open EHR-Gen Framework, la herramienta libre para crear sistemas de Historia Clínica Electrónica basados en estándares internacionales como openEHR, HL7 CDA y CIE 10.

La nueva versión 0.6 está disponible para la descarga aquí: http://code.google.com/p/open-ehr-gen-framework/downloads/list

OpenEHR-Gen Framework es 100% código abierto y gratuito. Se agradece la difusión del mismo.

¿Qué quiere decir esto? Que cualquiera puede bajar el código, probarlo, modificarlo, hacerle mejoras y adaptaciones a la realidad de cada institución sanitaria, y podrá contribuir con el desarrollo en comunidad de la herramienta.

¿Qué valor ofrece este proyecto? ¿Qué lo hace distinto?

En el corazón de la herramienta están considerados aspectos de estandarización que aportan a la interoperabilidad del sistema con cualquier otro sistema externo (farmacia, laboratorio, imagenología, sistemas administrativos, etc).

Otro diferenciador es la orientación a la gestión del conocimiento clínico, a través del uso de arquetipos openEHR como especificación del contenido del registro clínico. Ver más sobre arquetipos en el gestor de conocimiento clínico: http://www.openehr.org/knowledge. ¿Esto en qué te beneficia? En el el proceso de desarrollo de software es independiente del proceso de especificación del contenido clínico, y el resultado es un mejor proceso global, una herramienta de software más ligera y adaptable, y el control completo del contenido clínico por parte de los médicos.

Por último, está desarrollado sobre tecnologías web de nivel empresarial de última generación, como ser Grails, Groovy y Java.

Principales cambios con respecto a la versión anterior (*):

Reescritura completa del generador de interfaces de usuario, con gran aumento de performance.
Se agrega un gestor de usuarios y de roles.
Se modifica el modelo de datos persistentes para simplificarlo y mejorar performance de lectura-escritura de la base de datos.
Se sustituye librería javascript Prototype por jQuery. Con jQuery se implementa parte de la nueva generación de interfaces de usuario.
Se hacer varias correcciones y mejoras al componente data binder.
Se cambia un poco el estilo de la interfaz de usuario.

(*) Aquí se puede ver más información sobre la versión anterior, y puedes encontrar presentaciones y documentos sobre el proyecto.

Algunas capturas de pantalla de la nueva versión (clic para ver en grande):

Ingreso al sistema

Selección de dominio

Ingreso a dominio de trauma

Registro en dominio de trauma

Registro de triage en trauma

Registro de triage almacenado

Evaluación primaria de trauma: vía aérea

Evaluación primaria de trauma

Evaluación primaria de trauma: disfunción neurológica

Búsqueda de paciente para asociar al registro clínico

Resultado de la búqueda

Registro clínico con paciente seleccionado

Gestión de personas

Detalle de una persona

Listado de roles

Detalle de un rol

Edición de permisos de un rol

Rol con permisos guardados

Como siempre, todas las preguntas y comentarios son muy bienvenidos.

openEHR busca lograr impacto global

2011-09-13T02:37:00.000-03:00

Hace algunos meses que las listas de mail de openEHR están colmadas de propuestas sobre cómo mejorar la organización de la fundación openEHR, cómo coordinar el trabajo y cómo lograr resultados tangibles.

En estos días, muchas de estas propuestas fueron consideradas por las principales cabezas detrás de openEHR, y se están viendo avances. El avance más grande es un whitepaper que, a modo de manifesto, intenta reflejar el camino que tomará la fundación en el futuro cercano, tanto en temas organizativos como en el desarrollo del estándar y de herramientas relacionadas.

Éste es el link al whitepaper (que sigue en edición): http://www.openehr.org:8888/openehr/321-OE/version/default/part/AttachmentData/data/openEHR%20Foundation%20moving%20forward.pdf

También quiero dejarles los links a las principales discusiones sobre los temas del whitepaper:

- Anuncio de cambios: http://www.openehr.org/mailarchives/openehr-clinical/msg02145.html
- Sobre repositorios de conceptos clínicos (arquetipos y plantillas): http://www.openehr.org/mailarchives/openehr-clinical/msg02149.html y http://www.openehr.org/mailarchives/openehr-clinical/msg02146.html

Otros temas como la alineación a estándares como EN/ISO 13606 y HL7 CDA también están en la mesa.

Para quienes quieran participar de las discusiones, aquí están las listas para suscribirse: http://www.openehr.org/community/mailinglists.html

Por mi parte, creo que la descentralización es uno de los temas más importantes para lograr un impacto global en el uso de este estándar que promete mucho, pero que tal vez por falta de difusión y capacitación, es poco conocido en nuestra región. Creo que una vez que openEHR ingrese formalmente en la currícula de la formación en Informática Médica, la realidad será otra y podremos aprovechar lo que el estándar ofrece: permitir crear sistemas informáticos en salud "a prueba del futuro".

Gestion de proyectos de informatizacion en salud

2011-08-30T23:22:00.001-03:00

La informatización en el área clínica es un camino que muchas instituciones sanitarias están emprendiendo a nivel mundial. Este camino no es sencillo, está lleno de obstáculos, problemas, desentendimientos, expectativas incumplidas y proyectos fallidos.

Es este contexto tan hostil, ¿existirá alguna metodología o proceso que nos acerque al éxito o nos aleje del fracaso?. El objetivo de este artículo es dar mi opinión personal sobre algunas "áreas sensibles" que los gestores de proyectos deberían cuidar para que "el bote no haga agua".

Algunos de estos puntos podrán coincidir más o menos con los métodos y estrategias usados por los gestores de proyectos, y deberían considerarse como la humilde opinión de alguien que observa y analiza la realidad (de cerca), no como una solución a todos los problemas. Además trato de hacer énfasis en el "qué", no en el "cómo", pero la discusión está abierta.

El proyecto debería ser solo un grano de arena

El proyecto de informatización debe ubicarse en una estrategia organizacional de mejora, el proyecto no debería ser la estrategia, sino un resultado de esta.
Tener claro este punto facilita que el apoyo de los tomadores de decisión de la institución se haga visible, y ubica al proyecto en un lugar de la agenda institucional. De lo contrario, el apoyo se hace esquivo, y no se tiene una puerta donde ir a tocar cuando hay problemas a nivel de la institución.

La informatización es un camino solo de ida

Junto a la planificación de las distintas etapas de desarrollo e implantación de las soluciones informáticas en el área clínica, debería planificarse la estrategia de eliminación del papel de los procesos clínicos.
Dejar "vivo" al papel es atentar contra el uso de los productos del proyecto.

Evitar el proyecto de duración infinita

Todo gestor de proyectos sabe que un elemento característico de éstos es que tienen una fecha de fin.
Esa fecha de fin debería ser fija e inamovible, y se debería tener claro qué es lo que se va a entregar y qué es lo que no. Tres factores se debe tener en cuenta siempre: el alcance (cantidad y complejidad de necesidades a satisfacer), la calidad (cantidad de ciclos de mejora sobre una necesidad satisfecha) y el tiempo (demora en satisfacer una necesidad o de mejorar la forma en la que esta es satisfecha). Se dice que tenemos 3 balas y solo podemos disparar 2, por ejemplo un proyecto con un alcance muy grande y con gran calidad, requerirá mucho tiempo en desarrollarse. Otra posible combinación es que si tenemos poco tiempo y un alcance fijo, no podemos pedir mucha calidad. La regla general es que si aumentamos alcance, calidad o tiempo, aumenta el costo/presupuesto.
Siempre hay aspectos que pueden mejorar, y siempre habrá tiempo para mejorarlos, pero sobre la entrega de los productos no podemos empezar procesos de mejora. Es mucho mejor para el proyecto, para el proveedor y para el cliente: 1. entregar lo pactado, ni más ni menos; 2. aceptar lo que se debe entregar; 3. cerrar el proyecto; 4. sentarse a pensar en mejoras (...y ver si queda algo de presupuesto).

Las expectativas y la comunicación son también elementos a gestionar

Luego de fijar el alcance del proyecto, los clientes y los usuarios finales deberían saber qué es lo que se va a entregar y cuándo. Esto incluye el saber que es lo que NO se va a entregar.
La comunicación de estos elementos se debería hacer en cada oportunidad que se tenga, y si no se dan estas oportunidades, se deben crear. Por otro lado, todos los usuarios finales (sobre todo los médicos) tienen una idea de lo que quieren, y todos se imaginan que el producto será exactamente como ellos lo imaginan. Para evitar desilusionar a estos usuarios (riesgo a rechazo del producto), se debe dar una imagen clara del producto, de lo que tendrá y no tendrá, y bajar o subir las expectativas al nivel correcto. Esto también debería hacerse en todas las oportunidades que se tengan.

Contraparte es algo más que once letras

Sin contraparte no existe proyecto. Si somo un proveedor de software, la contraparte está formada por los tomadores de decisión, los usuarios finales y el staff informático del cliente. El cliente debe ser comunicado claramente de que para que el proyecto sea un éxito, se necesita tiempo de trabajo de los recursos humanos de la institución: médicos, enfermeras, técnicos, informáticos, etc.
Una forma de que el cliente tome conciencia de esta necesidad es que sepan claramente cómo será el proceso de desarrollo e implantación de los productos del proyecto, y que en cada una de esas etapas se requerirá la participación de ciertos roles claves, que necesitan un tiempo asignado a esas tareas, y que deberán dejar de hacer otras tareas que hoy tienen asignadas.
Este punto es tan obvio que muchas veces los gestores lo pasan por alto, y como consecuencia se pierde tiempo por no contar con alguien del otro lado a quien hacerle preguntas o con quien discutir posibles soluciones a los problemas que el propio cliente plantea.

Mantener las audiencias y el interés es un gran punto a favor

En los proyectos de informatización en salud se tienen dos grandes audiencias: los tomadores de decisión y los usuarios finales. Es frecuente que por la poca visibilidad del proyecto y sus avances, por la poca comunicación, o a veces por la duración tan prolongada de estos proyectos, las audiencias que antes nos apoyaban, aportaban y se interesaban por el proyecto, ya no están tan interesados.
Perder el interés de las audiencias, es perder apoyo y ganar resistencia, lo que es un gran punto en contra para el proyecto. El interés es otro punto a gestionar y cuidar, porque hay que recuperarlo antes de que sea demasiado tarde, por ejemplo: que se entregue el producto y nadie lo use.
A los gestores les gusta saber que se tienen productos listos, y a los usuarios les gusta dar su opinión y ver como esta repercute en el producto que van a usar. Ellos debe participar en todas las etapas del proyecto!.

El proyecto ~~informático~~ médico

La informática es un camino para lograr un objetivo, no debería ser considerado como el objetivo en si.
Tanto los tomadores de decisiones como los usuarios finales no deberían hablar de bases de datos ni servidores, con ellos y a ellos siempre se les debería hablar en un plano médico de usos y funcionalidades que soportará la herramienta. Como estrategia general, el proyecto debería presentarse como un proyecto médico, no un proyecto informático.

El paradigma del hiper-mercado vs. las pequeñas tiendas especializadas

Existen dos formas de encarar los proyectos de informatización en salud. El primero y más frecuente, es el de una gran herramienta centralizada, con una única base de datos, que provee soporte a diferentes sectores y diferentes usuarios. Donde los requisitos y necesidades de cada uno de estos sectores y usuarios es esencialmente distinto al de los demás. Este tipo de proyectos suele ser desarrollado en un largo período de tiempo, lo que contribuye a la pérdida de interés que mencioné antes. Este producto es el hiper-mercado.
Por otro lado, está el enfoque de partir el "problema" en pedazos, el clásico "divide y vencerás" (que muchas veces olvidamos al gestionar proyectos). La idea es desarrollar pequeñas herramientas, especializadas a cada sector o tipo de usuario, y con independencia de las demás herramientas, sectores y usuarios. Este tipo de herramientas son más sencillas de desarrollar, tienen un público objetivo acotado, un tiempo de desarrollo más pequeño, y por lo tanto un riesgo menor de fallar como proyecto. Por otro lado, este enfoque agrega un elemento nuevo: es necesario pensar en estándares e interoperabilidad para que estas herramientas puedan compartir información para lograr una verdadera sinergia. Estas son las pequeñas tiendas donde cada uno encuentra exactamente lo que quiere y necesita.
Este segundo es mi enfoque preferido, ya que como gestores nos permite concentrarnos en un elemento acotado a la vez, y nos permite hacer lo mejor en cada uno, a la vez que no perdemos de vista el proyecto global.

El éxito del proyecto no debería medirse en cantidades de usuarios o registros

Muchos gestores, para mostrar el éxito de sus proyectos muestran resultados numéricos como la cantidad de usuarios, la cantidad de registros clínicos, la cantidad de prescripciones electrónicas que fueron hechas, etc.
Si bien esos valores nos sirven para medir niveles de uso (cosa que se debe hacer frecuentemente), el éxito de un proyecto no se debería medir en esos términos, sino que debería medirse en los términos de "cómo ayudaron los productos del proyecto en alcanzar os objetivos organizacionales (tanto clínicos como de gestión)". Recordemos que estos proyectos son herramientas para lograr objetivos, y que sin estrategias organizacionales y objetivos de mejora estos proyectos no existirían. Por lo tanto deberíamos preguntarnos cosas como: con estas herramientas ¿cómo se aumenta la calidad de la asistencia a los pacientes? o ¿cómo se mejora el uso de recursos limitados?

Como siempre: ¡sus comentarios son muy bienvenidos!

Hasta la próxima.

Modelado de procedimientos con openEHR

2011-07-19T02:22:00.001-03:00

Este es otro excelente post de la Dra. Heather Leslie, donde adjunta una presentación que describe el modelado de los procedimientos clínicos mediante arquetipos openEHR. Personalmente me gusta mucho esta forma de modelado, porque ayuda a que quede plasmado en el registro clínico todo el proceso de instrucciones/órdenes y las acciones que se llevan a cabo para dichas órdenes.

El modelo de instrucciones y acciones puede encontrarse aquí.

ACTION archetypes

View more presentations from Ocean Informatics

Optimizacion de datos demograficos: buscando la herramienta perfecta

2011-07-13T02:02:00.000-03:00

Muchos de los colegas que siguen este blog ya saben que le he dedicado más de un post al tema de los datos demográficos. Creo que muchos de los que nos hemos topado con proyectos de informatización de cierta embergadura en instituciones sanitarias, sabemos que aunque los proyectos apunten a la "capa clínica", debemos prestar mucha atención a la "capa demográfica", porque es ahí donde estará la información para indizar correctamente los registros clínicos.

Hoy estuve pensando en los problemas que pueden causar los datos demográficos incorrectos o incompletos, y en las funcionalidades que debería tener un sistema informático de auditoría para resolver esos problemas. Si bien el sistema perfecto no existe, es bueno de vez en cuando parar un segundo y pensar en cómo sería la herramienta perfecta para nuestra organización. Aunque no se pueda construir la herramienta de forma inmediata, creo que esta es la única forma de saber hacia dónde se debe ir.

Aquí están algunas notas mentales de lo que para mí debería hacer el sistema perfecto:

Ejecución de algoritmos:

Detección de datos faltantes
Detección de datos incorrectos
Detección de duplicados

Presentación de informes para el auditor

Muestra problemas detectados
Muestra primero los casos con más prioridad a resolver
Permite acceder a las funcionalidades de resolución de problemas y optimización de datos

Completar datos faltantes
Corregir datos erróneos
Resolución de duplicados (unificación de identidades)
Agregar relaciones familiares (p.e. padre-hijo)

Registrar información de feedback

1. Toda herramienta para gestión y auditoría de datos demográficos debería contar con al menos estos 3 grupos de algoritmos. Los algoritmos para detección de datos faltantes, por ejemplo se fijan si el registro de una persona carece de un medio de contacto telefónico, o si falta registrar el segundo apellido. Los algoritmos para detección de datos incorrectos, pueden por ejemplo verificar el sexo a partir del nombre de la persona, un caso de error podría ser si para el nombre Carlos se tiene registrado sexo Femenino. Y los algoritmos para detección de duplicados, ya los he cubierto en artículos anteriores [1, 2].

2. Los problemas detectados deben ser revisados por una persona que pueda auditar los registros. Muchas veces se cae en el error de querer crear el sistema perfecto que detecte y resuelva todos los problemas, pero en este caso lo mejor es tener un sistema con la inteligencia suficiente para detectar problemas y mostrarlos, y que una persona sea la que los resuelva. Para resolver los problemas, muchas veces esta persona va a tener que ponerse en contacto con la persona a la cual pertenecen los registros con errores, para obtener la información correcta desde la fuente. También se pueden aprovechar las instancias en que la persona viene a atenderse, para solicitar que verifique su información. Una parte importante en este proceso es la de resolución de registros duplicados, porque puede implicar que se deban unificar también registros clínicos. La otra parte importante es la de registrar las relaciones familiares entre pacientes, porque esto permite asociar historias clínicas familiares, y es útil para detectar problemas hereditarios a tiempo. ¡Los datos demográficos también sirven para mejorar la salud de las personas!

3. Cuando los problemas detectados, no son realmente problemas (las computadoras son tontas), se debe dar información al sistema para que éste sepa que esos no son problemas. Entonces, el sistema va "aprendiendo", y en la próxima detección de problemas, no los vuelve a marcar como tales. De esta forma, se va tendiendo hacia el óptimo del cero problema. Pero, como sabemos, este tipo de sistema gestiona datos que están en constante modificación: hay nuevos pacientes, se dan de baja otros, se corrigen datos, se ingresan nuevos duplicados, etc., por lo que este es un proceso que nunca termina, y se debe volver al punto 1 con una frecuencia que cada organización debería estimar.

¿Qué les parece? ¿Qué agregarían?

Marco conceptual para proyectos de informatizacion en salud

2011-07-10T17:31:00.002-03:00

En mi artículo anterior informatización en salud ¿por dónde empezar? abrió una discusión muy interesante desde varios puntos de vista.

La primer conclusión que saqué de los comentarios fue que todos tenemos una idea distinta de lo que debe ser un proyecto de informatización en salud. Las diferencias pueden venir de la experiencia, de la formación, del estudio, etc, cada uno hace énfasis en lo que más le interesa/preocupa, algunos ponen énfasis en los temas relacionados con la gestión, otros con adaptarse a la forma de trabajo del médico y el equipo de salud, y otros están enfocados en la implementación concreta de herramientas (sobre todo los informáticos).

Estas diferencias me llevaron a pensar en una especie de marco conceptual, que sirva de punto común para que los distintos perfiles entiendan un mismo proyecto, y luego dentro de éste, cada uno puede definir su propia visión particular, basado en los factores antes mencionados.

Opino que si antes de empezar un proyecto, podemos saber que tipo de proyecto es y qué enfoque va a tener, la ejecución del mismo será mucho más sencilla, comparado con comenzar un proyecto sin tener una visión clara de qué tipo de proyecto es. Además esta clasificación de alto nivel podría servir para no errar el camino, y también para marcar objetivos particulares, para la planificación, para crear medidas de avance y cumplimiento en base el tipo particular de proyecto.

Aquí está el diagrama de clasificación del tipo de proyecto en base a lo que hablamos en el artículo anterior:

Lo que marca el diagrama son 5 niveles. Donde el nivel 0 debería estar predefinido, porque los proyectos de informatización en instituciones sanitarias deberían ser parte de la estrategia organizacional. De lo contrario, los proyectos de informatización serán un dolor de cabeza, porque habrá que remar contra la corriente cada vez que se necesite tomar una decisión importante, debido a que los habrá que convencer a los tomadores de decisión cada vez. Con el proyecto como parte de la estrategia organizacional, serán los propios tomadores de decisión quienes apoyen el proyecto antes inclusive de vislumbrarlo.

Los niveles de 1 a 4 marcarán fuertemente el tipo de proyecto. El nivel indica a grandes rasgos las tareas necesarias a realizar en la parte de planificación y relevamiento (mucho antes de comenzar a desarrollar una herramienta informática). A medida que subimos de nivel, las tareas serán más grandes y compleja, por lo que será un proyecto de mayor porte, pero también de mayor impacto. Además, cuanto mayor sea el nivel, los resultados del proyecto estarán más integrados a la organización, o sea que se adaptarán de mejor forma al funcionamiento de la organización y a su cultura, por lo que tendrá una menor resistencia y una mejor adopción por parte de los usuarios.

Luego de definir el nivel en el que será ejecutado el proyecto, el arco iris representa el enfoque que tendrá el mismo. Este enfoque estará basado fuertemente en la forma de gestión de la propia institución. En general las instituciones usan un nivel de gestión básico economista, orientado a las transacciones monetarias y a la contabilidad. Si bien esta forma de gestión es la más común, aunque no siempre la más apropiada, los proyectos de informatización en salud que estén marcados por este enfoque tendrán grandes problemas en su ejecución. Esto se debe a que los usuarios de las herramientas que cree el proyecto no serán las mismas personas que gestionan la institución, y desde la parte asistencial se puede percibir que están usando una herramienta que no se ajusta a sus necesidades. En este caso puede convenir partir en dos el proyecto, haciendo un proyecto más pequeño orientado a los RRHH o a los procesos, más adaptado a las necesidades del personal asistencial, y otro proyecto orientado completamente a la gestión. El resultado de este proyecto será una herramienta que permita a los gestores "espiar" lo que pasa en la parte asistencial, y vincular a esos actos toda la información económica y contable que necesitan.

El enfoque en los RRHH sería cuando se quiere optimizar el trabajo de cada persona o rol, de modo de aprovechar al máximo el tiempo y el aporte de cada profesional a la institución. El enfoque en los procesos es el que busca optimizar procesos complejos donde intervienen múltiples personas o roles, buscando un óptimo global para cada proceso.

Y el enfoque orientado a los resultados, es el que busca optimizar el producto de la institución: el paciente sano o "La salud". Aún hoy existen muchas instituciones sanitarias que no saben qué producen, esto mismo debe especificarse en el nivel 0. Esto también puede dar para otro artículo porque es un tema muy debatido. Mi opinión es que dependiendo de la forma de gestión, un profesional dirá que el producto es el acto médico (enfoque economista), y como comentaba antes, otros dirán que es el paciente sano o "La salud" (enfoque orientado a los resultados).

Ahora que sabemos exactamente qué tipo de proyecto tenemos, el último elemento del diagrama es la ejecución del proyecto. Esto incluye las tareas de planificación, relevamiento, análisis, diseño, programación, pruebas, puesta en producción y seguimiento posterior.

Seguramente faltan muchos puntos a considerar para tener un buen "marco conceptual" para los proyectos de informatización en salud, sus opiniones son muy bienvenidas. Hasta la próxima.

Informatización en instituciones sanitarias

2011-06-24T11:32:00.000-03:00

Informatización en instituciones sanitarias ¿por donde empezar?

He estado estudiando este tema desde hace tiempo y parece no haber una forma estándar o algún patrón que nos indique por donde tienen que empezar los procesos de informatización en las instituciones sanitarias, siempre pensando en el área clínica, no en el área administrativa que ya está informatizada.

Lo que pude detectar es que hay dos grandes formas de hacerlo, una es orientarse a los registros y otra es orientarse a los procesos. La primera creo que es la más común: el equipo de desarrollo analiza los registros que se realizan en la institución, y desarrollan un sistema que incluye esos registros de forma electrónica. La segunda forma es un poco más profunda y no tan común: consiste en analizar los procesos de la institución, saber qué se hace, quién hace qué, para luego llegar al nivel del registro, y saber quién registra qué y cuándo.

En el medio hay matices entre una y otra punta, aunque también existe una tercer opción o nivel, el cual incluye el análisis del sistema de información de la institución, esto es: la forma en que la información fluye dentro de la institución, quienes la generan, quienes la consumen, quienes la trancan, que dependencias de información existen, etc. Esto sería considerando cualquier tipo de información de salud, transmitida en cualquier medio: señales de humo, habla, teléfono, email, sistemas informáticos, etc.

Lo que noto es que muchas de las empresas proveedoras están en el nivel 1, el de análisis de registros, y esto es un problema para las instituciones. Lo otro que noto es que las instituciones tampoco están preparadas para los niveles 2 (análisis procesos) y 3 (análisis de sistemas de información), porque no hay definiciones formales de los procesos, y menos de los sistemas de información.

Lo que si he detectado, es que podemos generar un marco de evolución, donde se puede mostrar la madurez del proceso de informatización, formado por los 3 niveles antes mencionados. Donde cada nivel debe lograrse sobre el nivel anterior. Y esto pienso que no solo implica hacer más preguntas a la hora del análisis de la situación de la institución, pienso que implica un conocimiento profundo del área de la salud y del funcionamiento institucional.

Para concluir, creo que en un futuro cercano la realidad será otra. En principio porque vamos a tener la experiencia de varios proyectos, exitosos y fracasados. Lo segundo es que vamos a tener más gente formada en el área específica de la Informática Médica, con una mirada del problema desde la informática y desde la medicina. Esta mirada mixta es crucial para entender los problemas de la salud y la cultura de las instituciones (y no morir en el intento).

En un próximo artículo, trataré de comentar un proceso que desarrollé para el análisis de las instituciones sanitarias, orientado a los procesos (nivel 2), para lograr una herramienta informático adaptada a la cultura y forma de trabajo de cada institución.

¿Cuando es bueno no usar estandares internacionales?

2011-06-07T00:46:00.000-03:00

El título de este post es un poco contradictorio con el trabajo que hago a diario. Mi trabajo consiste en el modelado e integración de distintos sistemas de información, y detectar oportunidades de aplicación de estándares internacionales.

A veces mi tendencia a querer aplicar estándares cansa un poco a mis colegas y proveedores, que quieren hacer las cosas rápido y a medida. Muchas veces, sobresalen los argumentos de las ventajas que tiene utilizar uno o más estándares para implementar determinada funcionalidad, sobre todo ventajas a mediano y largo plazo, como la capacidad de integrar otros sistemas sin tener que trabajar más, o de hacer que el sistema sea más fácil de adaptar a requerimientos futuros, etc.

Pero también me gusta pararme del otro lado y pensar cómo sería la solución si no aplicara tal o cual estándar, porque tampoco soy un fundamentalista de la estandarización (aunque algunos piensen lo contrario jeje).

Entonces ¿vale la pena usar estándares para todo, y todo el tiempo?. La experiencia y algunos colegas y amigos, me han demostrado que la estandarización tiene sus límites, y que muchas veces la utilización o no de estándares, depende más del contexto que del problema a resolver.

Por ejemplo, el Dr. Sergio Montenegro, director del Depto. de Informática Médica del Hospital Madariaga de Misiones, Argentina, me contó sobre el proyecto que están llevando a cabo a nivel provincial para tener una Historia Clínica Electrónica única. Mientras él me contaba los pormenores del proyecto, yo me imaginaba una gran cantidad de sistemas, interactuando entre sí, con muchas comunicaciones y muchos estándares en el medio. En ese momento, Sergio me contó que sería un solo sistema en un único datacenter el que daría soporte a la HCE provincial, y toda la complejidad desapareció. Es verdad que el enfoque centralizado tiene sus desventajas, pero son compensables con soluciones técnicas, de procesos o de negocio.
Entonces, para este tipo de proyectos, los estándares de comunicación casi desaparecen, porque toda la comunicación es interna. Igualmente, existen múltiples estándares que son aplicables a la interna del sistema, como estándares de contenidos (CIAP-2, CIE10, Snomed, etc), estándares de modelo/arquitectura (openEHR) o estándares para documentación clínica (HL7 CDA, ASTM CCR, ISO 13606, etc).
También es claro que no en todas las regiones tienen las cosas tan claras como en Misiones, por ejemplo, en Uruguay, aunque solo tenemos 3.5M de habitantes, que haya un solo sistema único sería imposible, tanto a nivel nacional, o incluso departamental con unos cientos de miles de personas.

Otro ejemplo podría ser cuando se tiene una red de hospitales y en cada uno se utiliza un sistema de registro clínico distinto, y desean crear una HCE única para sus pacientes. En este contexto lo que uno gritaría HL7! de entrada, pero dependiendo del proyecto, tal vez HL7 no sea una buena opción. Por ejemplo, si se sabe que solo esos hospitales formarán una red clínica, con su HCE única, es posible desarrollar un estándar para implementar en esa red. Obviamente, un estándar hay que usar, pero no necesariamente debe ser uno internacional. Por ejemplo, el estándar a desarrollar puede estar basado y adaptado a los modelos de negocio, los modelos de atención y los sistemas de información presentes en los hospitales y en la región, con la diferencia de que si se usa HL7 se deberá perfilar el estándar internacional a su uso local. La creación de un estándar local específico para el intercambio de cierta información puede hacerse mucho más rápido que el perfilamiento de un estándar internacional. Igualmente, tener conocimiento de los estándares internacionales puede dar buenas pautas para el desarrollo del estándar local.

Con esto tengo un ejemplo concreto. En el proyecto FEMI Salud Digital donde trabajo ahora, desarrollé un Índice Maestro de Personas (IMP) que guarda un conjunto mínimo de datos patronímicos de pacientes, con el objetivo de poder linkear Historias Clínicas Electrónicas a nivel nacional entre 23 instituciones en distintos departamentos de Uruguay. Los servicios que provee este IMP están basados en los perfiles IHE PIX y PDQ, pero están implementados usando Web Services REST, en lugar de mediante Web Services SOAP, y en lugar de usar mensajería HL7 PA, utilizan mensajería XML a medida. La estructura de la mensajería XML es muy parecida a la estructura de los mensajes HL7v3, pero mucho más simple. En definitiva es mensajería XML sobre HTTP.

Ejemplos pueden haber mil, pero el mensaje es que quiero dejar es: siempre deberíamos tener 4 o 5 estándares internacionales como referencia (p.e. openEHR, HL7, DICOM, CIE10, CIAP-2), pero debemos considerar el contexto de cada proyecto para saber si vale la pena perfilar los estándares internacionales o crear nuevos estándares locales. La segunda opción solo se debería tener en cuenta, si primero se tienen en cuenta los aspectos clave de los estándares internacionales. Desarrollar un estándar local sin una referencia externa es un error conceptual a no ser que realmente no exista la referencia (cosa que no ocurre a menudo, lo que si ocurre mucho es que no se buscan referencias y se quiere reinventar la rueda a cada paso).

Ideas sobre escritorio médico electrónico

2011-05-28T21:24:00.001-03:00

Con el colega Sergio Retamar de Misiones, Argentina, empezamos a hablar de lo útil que es tener un escritorio médico integrado a los sistemas de historia clínica electrónica, justamente para ayudar a organizar el trabajo de los médicos y otros miembros del equipo de salud, la comunicación entre profesionales y la comunicación institucional, entre otros temas. Este hilo estará dedicado a proponer ideas de lo que debería (o no) estar dentro de un escritorio médico electrónico.

Con Sergio tuvimos un intercambio fuera de la lista para llegar con algo de valor al iniciar la discusión. La idea es que entre todos podamos aportar para llegar a una lista de requerimientos de lo que podría ser más útil. Esto luego puede volcar en cualquier sistema de historia clínica que desee desarrollar el concepto de "escritorio médico electrónico". Se aceptan sugerencias aquí.

Objetivos:

Debe haber información de valor para los médicos.
Debe haber información contextual:

A su trabajo inmediato
Al estado de sus pacientes
A su especialidad o área de interés
Al departamento/institución donde se desempeña
A su formación pasada, presente y futura

Contenido:

Trabajo inmediato:

Acceso a turnos de pacientes: lista de pacientes que según los registros del sistema (agenda) estarían esperando y próximos a presentarse para su atención. Al seleccionar un paciente (turno) debería acceder a su historia clínica.
Estudios solicitados: pendientes y resultados de los pedidos, de cualquier paciente/de pacientes en su agenda de turnos.
Acceso a la administración de sus agendas: cambio de horarios, reasignación de turnos, etc.
Búsqueda de pacientes: en la base de pacientes de la institución o red asistencial.

Comunicación:

Comunicados institucionales.
Mensajería interna entre médicos.
Noticias en prensa: relacionadas con su especialidad, con el estado de sus pacientes, con el departamento donde trabaja, etc.
Próximas reuniones: comités hospitalarios, gremiales, reuniones de directiva, etc.

Capacitación, investigación, eventos:

Noticias en revistas científicas/trabajos científicos: relacionadas con su especialidad, con el estado de sus pacientes, con el departamento donde trabaja, etc.
Congresos y eventos: relacionadas con su especialidad, con el estado de sus pacientes, con el departamento donde trabaja, etc.
Cursos: relacionados con su especialidad, con el estado de sus pacientes, con el departamento donde trabaja, etc.

Otros:

Estadísticas: sus estadísticas de uso del sistema, de su registro clínico, de sus errores cometidos, de cumplimiento de metas/objetivos, de su performance, de sus costos de atención, etc.
Acceso a su correo electrónico institucional.
Acceso a buscadores preconfigurados.

Idea sobre información contextual: quizás se podrían generar alertas (como se puede hacer en google: http://www.google.com/alerts) según los temas e interés del profesional (especialidad, patologías frecuentes en sus pacientes) y mostrar como noticias, presentaciones, publicaciones destacadas.

Parece muy adecuado que el contenido pueda ser opcional y configurable por cada profesional, permitiendo agregar lo que sea de mayor interés para cada usuario.

¿Que les parece?

Nueva version de OpenEHR-Gen Framework

2011-04-04T21:54:00.001-03:00

Estamos muy contentos de anunciar la liberación de una versión mejorada de OpenEHR-Gen Framework, la herramienta que ayuda a crear sistemas de Historia Clínica Electrónica usando estándares internacionales como openEHR, HL7 CDA y CIE 10. La nueva versión está disponible aquí: http://code.google.com/p/open-ehr-gen-framework

Lo interesante (o distinto) de este proyecto, es que todo el registro clínico es generado de forma dinámica y "al vuelo", en base a arquetipos que modelan conceptos clínicos (presión arterial, escala de Glasgow, frecuencia respiratoria, etc), y plantillas que indican cómo se debe mostrar cada formulario. Tanto los arquetipos como plantillas pueden ser definidos por el equipo de salud, y la herramienta genera el registro a partir de lo que ellos definen, sin necesidad de programar.

OpenEHR-Gen Framework es 100% código abierto y gratuito. Se agradece la difusión del mismo.

Aquí se pueden descargar algunas capturas de pantalla de la historia clínica del dominio de trauma: http://www.subirfacil.com/files/1BIEYWYQ/capturas_openehr-gen.zip

Este proyecto fue concebido desde nuestra tesis de grado, el cual también tenía integración del estándar DICOM (integración con imagenología digital) y de la especificación IHE PDQ (consulta de datos demográficos): http://informatica-medica.blogspot.com/2010/12/documentacion-de-mi-pr...

Algunas presentaciones y documentos sobre el proyecto que pueden ser de interés:

Los principales cambios con respecto a la versión anterior son:

Actualización del framework de desarrollo: Grails Framework de v1.1.1 a v1.3.7
Agregamos la implementación de la clase Folder del modelo de referencia de openEHR. La usamos para modelar distintos dominios de registro como "emergencia", "ambulatorio", "prehospitalario", etc., los registros de cada dominio van al mismo Folder.
Se mejoró el diseño de la interfaz de usuario para que sea más compacta, y se mejoró la generación dinámica de la interfaz de usuario.
Se agregó soporte a la directiva de interfaz de usuario "type=smallText" para los templates, que sirve para mostrar inputs de texto pequeños para los nodos DvText de los arquetipos. Antes se mostraban controles textarea/memo para todos los DvText aunque fueran para ingresar textos pequeños.
Se cambió el cierre del registro clínico por verificación dinámica de condiciones, ahora el registro debe ser explícitamente cerrado y firmado por el médico. Esto da mayor flexibilidad para la definición de nuevos tipos de registros.
Se agregó la validación de restricciones de ocurrencias sobre nodos de tipo ITEM_SINGLE, que no estaba implementado. Se corrigieron errores pequeños y se limpió el código.

Cualquier consulta o comentario es todo bienvenido.
Estamos completamente abiertos a la colaboración.

HL7 normalizando la comunicacion en salud

2011-02-09T01:43:00.004-02:00

Hablar del estándar HL7 es difícil, no solo por su complejidad estructural (ya que está formado por varios estándares), si no porque también es difícil elegir el enfoque. Para este artículo me voy a concentrar en el modelo de referencia de HL7, en el modelo de documentación clínica, y en aspectos conceptuales que me gustaría destacar y/o criticar de forma constructiva para ayudar a quienes encaran un proyecto usando HL7.

Introducción

Health Level Seven (HL7) no es un estándar en sí, si no que es un conjunto de estándares cuyo principal objetivo es especificar mensajería para la comunicación de información clínica, demográfica y financiera, entre sistemas informáticos. Existen algunos estándares dentro de HL7 que tienen otros focos, pero la mensajería es uno de los aspectos más fuertes de HL7.

HL7 tiene su origen en los EEUU, y sus estándares reflejan el modelo de atención en ese país. Por ejemplo, en su modelo de referencia, junto con la información clínica se encuentra la información para facturación. Igualmente, hoy en día HL7 tiene alcance internacional, debido a los capítulos locales del HL7 que se han creado en distintos países.

Los principales estándares que conforman a HL7 son:

Mensajería v2.x: mensajería basada en formatos EDI y XML, sin un modelo de referencia detrás.
Reference Implementation Model: modelo de referencia de HL7, en el que se basan todos los mensajes v3.
Mensajería v3: mensajería XML basada en el RIM.

Dominios: la mensajería v3 se divide en dominios específicos de aplicación.

Clinical Document Architecture: representación de documentos clínicos con XML basados en el RIM.
EHR System Functional Model: especifica las funcionalidades que debería implementar un sistema de Historia Clínica Electrónica.

Una lista más completa de estándares puede encontrarse aquí: http://upload.wikimedia.org/wikipedia/commons/6/60/HL7_RepEstandares.pdf. Esta es la página oficial de los estándares HL7.

Aquí se puede encontrar una introducción a HL7, con un poco de historia y situación actual: http://es.wikipedia.org/wiki/HL7

La única corrección que se le debe hacer a la página de HL7 en la wikipedia es que HL7 no usa UML para el modelado, si no que extiende de la notación UML (para mi gusto sin necesidad), combinándola con elementos del modelo de esquemas XML (XSD). Más adelante mencionaremos algunos de los problemas de modelado en HL7.

Como organización, HL7 es una organización con base en los EEUU, que se basa en membresías pagas para organizaciones e individuales. A nivel internacional, HL7 tiene filiales en varios países (ver http://es.wikipedia.org/wiki/HL7). La propiedad intelectual de los estándares HL7 es de la organización, y debe pagarse una licencia para utilizar la documentación (no tengo datos de costos, más información: http://www.hl7.com.au/FAQ.htm). HL7 mantiene fuertes vínculos con la ANSI, y varios estándares HL7 son también estándares ANSI. Los estándares HL7 están diseñados con el enfoque de "diseño por comité", donde el foco está en lograr especificaciones con la que todos los miembros del comité estén de acuerdo. Este es un enfoque muchas veces criticado, debido a que el foco no está puesto en lograr especificaciones técnicamente óptimas e implementables, y los miembros del comité tienen diversos perfiles, muchos no técnicos o con poca formación/experiencia en Ingeniería/Arquitectura de Sistemas y en Análisis y Modelado de Información, dos áreas de conocimiento sumamente necesarias para la definición de estándares que luego deberán ser implementados en software. La siguiente imagen resume las críticas al "diseño por comité":

¿Qué no es HL7?

NO es una aplicación
NO es una estructura de datos o especificación de base de datos
NO es una arquitectura para diseñar aplicaciones hospitalarias
NO es una especificación para un ruteador de mensajes

Nota: esto es algo que se muestra en todas las presentaciones de HL7 en las que he estado, y me parece bueno mostrarlo aquí. Igualmente, a mi criterio, queda claro que cuando uno dice que HL7 es un estándar, si se entiende lo que es un estándar, lo de arriba es redundante.

¿Qué veremos en este artículo?

En este artículo nos concentraremos en los estándares v3: RIM, mensajería v3 y CDA.

HL7 en pocas palabras:

Define un modelo información de referencia genérico en el cual se basan los demás estándares v3.
Apunta a resolver la comunicación entre sistemas mediante mensajería XML.
Objetivo: permitir interoperabilidad entre sistemas heterogéneos.

Modelo de información de referencia genérico:

El modelo de información de referencia de HL7 (HL7 RIM) está basado en cuatro clases de información básicas: Act, Participation, Rol, Entity. Traducido al español esto quiere modelar que en todo Acto, hay Entidades, que Participan jugando algún Rol. Como vemos, es un modelo muy genérico que podría estar expresando cualquier tipo de información en cualquier contexto, incluso fuera de lo que es información clínica. Esta generalidad puede como una ventaja o como una contra. Es una ventaja, porque dentro del complejo mundo de la salud, este modelo puede representar muchísimos escenarios, y es una contra porque esa generalidad le quita valor para representar de forma simple o correcta situaciones muy heterogéneas (como son la mayoría de las cosas en salud). Por otro lado, es un modelo muy simple de entender. En la siguiente imagen se pueden apreciar estas cuatro clases básicas.

Clases centrales del HL7 RIM

Un Acto, según la especificación del estándar, es un registro de algo que se está haciendo, se ha hecho, se puede hacer, o se pretende o se pidió para hacer. Una Entidad es una cosa física, o grupo de cosas físicas, o una organización capaz de participar en Actos jugando algún Rol. La competencia de una Entidad que participa en un acto es identificada, definida, garantida, o confirmada por el Rol que juega en dicho Acto. Una Participación es una relación entre un Rol y un Acto. Como comentamos previamente, estas definiciones pueden aplicarse a cualquier ámbito, por eso este es un modelo de información genérico.

Un punto central en la comprensión del modelo, es que toda la información clínica se debe modelar mediante Actos, ya que las demás clases refieren a información de Entidades (información demográfica) y su Participación según Roles (información administrativa). Las subclases específicas del Acto que modelan información clínica son: Observation, Procedure, DiagnosticImage, SubstanceAdministration, Supply, Diet, PublicHealthCase y podríamos considerar que PatientEncounter también (ya que toda la información clínica debería estar de alguna forma relacionada con el encuentro de un profesional de la salud con un paciente). Por otro lado, también como subclases del Acto podemos encontrar clases para representar información económico/contable como: Account, FinancialContract, FinancialTransaction, e InvoiceElement. Personalmente no estoy de acuerdo con el enfoque de modelar información económico/contable de la misma forma que se modela la información clínica, ya que tienen estructuras y objetivos muy distintos. Aquí se puede encontrar una imagen con el modelo de información de HL7 completo.

El HL7 RIM se basa en un segundo nivel de información básica, donde se definen los tipos de datos (datatypes) que se utilizan en el modelo. El modelo de datatypes está definido por separado al HL7 RIM, y contiene:

Estructuras básicas: List, Set, Interval, Bag.
Tipos de códigos: Concept Descriptor, Concept Role, Coded Simple Value, Coded Value, Coded Ordinal, etc.
Estructuras para representar nombres: Entity Name, Entity Name Part, Trivial Name, Organization Name, Person Name, etc.
Tipos de magnitudes y magnitudes físicas: Real Number, Ratio, Physical Quantity, Integer Number, Monetary Amount, etc.
Tipos para tiempos y fechas: Point in Time, Interval of Point in Time, General Timing Specification, etc.
Otros tipos básicos: History, Telecommunication Address, Universal Resource Locator, etc.

Aquí se puede encontrar una descripción completa de los datatypes HL7.

Una crítica al diseño del modelo de datatypes es que hay elementos que referencian a entidades en el HL7 RIM, por lo que existe un acoplamiento (innecesario) entre el modelo de referencia (primer nivel jerárquico) y el modelo de datatypes (segundo nivel jerárquico). Los ejemplos de esto son los tipos de código donde se referencia al Rol, y en las estructuras para nombres donde se mencionan Entidades, Organizaciones y Personas. Un enfoque más limpio sería que la dependencia de uso fuera en un solo sentido, por ejemplo que el RIM use datatypes, pero que datatypes sea independiente de "quien lo usa". Aquí se puede ver una imagen del modelo de datatypes completo.

Modelo plano

Si vemos al HL7 RIM incluyendo el segundo nivel con datatypes, podemos apreciar que es un modelo bastante plano, esto quiere decir que las estructuras de información necesarias para representar una determinada situación de la realidad no tienen muchos niveles jerárquicos. Por ejemplo, si pensamos en una estructura de árbol, la información representada con HL7 RIM no tendrá más de dos o tres niveles. Si bien esto representa una simplificación a la hora de implementar software (este tipo de estructuras planas son fáciles de implementar, tanto como estructuras en memoria, como estructuras en bases de datos), la información en salud es esencialmente estructurada y jerárquica, o sea que en la realidad tenemos muchos más niveles en nuestro "árbol" de información. En resumen, el modelo es fácil de implementar en software pero se aleja de la estructura real de la información, lo que puede dificultar el modelado de información compleja y altamente jerárquica (más de 5 o 6 niveles).

Por otro lado, si vemos las clases del HL7 RIM, veremos que las clases centrales definen casi todos los atributos que usarán las subclases. Esto va en contra de las mejores prácticas en el diseño orientado a objetos, donde los objetos centrales son los más genéricos y tienen la menor cantidad de atributos, y los objetos más alejados del centro, son los más específicos y tienen más atributos declarados (al tener más atributos son más específicos y representan particularidades de los objetos centrales). El enfoque de diseño de HL7 es todo lo contrario, usando un mecanismo centralizado de atributos (la mayoría declarados en las clases centrales), pero también la mayoría son declarados como opcionales. Mientras que en las subclases se declaran restricciones que indican que un atributo de la super-clase (o clase padre) no será usado. Esto también va en contra de las mejores prácticas en diseño orientado a objetos: un atributo no es declarado en una super-clase si no será usado en una subclase.

El enfoque de modelado plano de HL7 también tiene ventajas. Primero, es simple de implementar en software, tanto en estructuras de datos en memoria, como a nivel de estructuras de base de datos. Creo que quienes lo diseñaron tenían en vista estos elementos, más los elementos de representación de mensajería XML y la especificación de esquemas XML, el XSD, y por eso pasaron por alto las mejores prácticas en el modelado de la información. Esto también trae a la mesa la discusión de si un estándar, y el modelado de información (supuestamente) genérica dentro de éste, debe estar tan ligado a las tecnologías relacionadas con la implementación. Podemos decir que los modelos de información de HL7 son un híbrido entre un modelo de dominio abstracto (independiente de toda tecnología y estructuración de la información como bases de datos, XML o XSD), y la implementación de sistemas concretos. Tal vez estos problemas conceptuales sean parte de que HL7 v3 no sea aún ampliamente implementado. Estos temas quedan planteados para la reflexión y la discusión.

Como resumen, en todo momento no debemos perder el foco de que este modelo de información está orientado a la mensajería, y no está hecho como modelo de información para ser implementado en un sistema de información De todas formas existe un movimiento para utilizarlo como modelo de información de sistemas de información y bases de datos, como el comité RIMBAA. Mi opinión personal es que es un error conceptual modelar información de la realidad y procesarla y almacenarla según un modelo para mensajería. Tal como dijo el colega Seref Arikan, es como tener tanques de agua y cañerías, pero almacenar el agua en las cañerías (mejor usar los tanques, es decir, los modelos que están hechos para eso). Igualmente les dejo las palabras de Peter Hendler, uno de los integrantes del comité RIMBAA que expresa estas ideas con las cuales discrepo en muchísimos aspectos (ya mencionados):

"The [HL7 version 3] RIM model is too good to be limited to messaging. If someone were to show a programmer the RIM datamodel - and not give them any pre-information that it was created by an organization called HL7, and the scope of HL7 is messaging - if you just put the datamodel in front of a programmer or an architect and say: please look at this model, and you ask them: what do you think this model is for. Probably they'd look at the model and they'd say this is a very comprehensive model which could be used for making healthcare applications and could probably even be used to make persistence layers and relational databases."

Aquí la reflexión de Seref Arikan, con la que concuerdo, al respecto de lo que menciona Peter Hendler:

"I think this is an opinion, not a proven fact, and our field experience is all the contrary: the programmers do not understand the model, and the architects say that this way of modeling breaks all the good practices in modeling information models."

Y ya que estamos en contexto, dejo unas palabras de Tomas Beale (arquitecto y uno de los principales contribuyentes a la especificación de openEHR):

"It is an unavoidable fact (an inconvenient truth) that HL7's approach of putting context/use case specific attributes in general models, and then expecting them to be 'profiled out' is contrary to maintainability and reusability of these models. Where I would like to see them is not my personal choice, it is just a conclusion of basic good modelling practices."

Nota: disculpas por el texto en inglés, pero me pareció mejor dejarlo con las palabras de los autores.

Comunicación mediante mensajería XML:

Una de las cosas que HL7 hace bien (y mucho) es la definición de estructuras para la mensajería. Ya con HL7 v2.x, el cual es uno de los estándares más usados en el mundo (si no el que más) para la mensajería entre sistemas de información en salud. HL7 v3 cuenta con un gran número de mensajes definidos para diversos "dominios", tales como:

Contabilidad y facturación: Cubre la creación y gestión de las cuentas de pago de los pacientes, con el fin de recolectar los pagos y créditos (transacciones financieras) para apoyar la presentación de reclamos o reembolsos de facturas.
Prestación de atención médica: Habilita la información necesaria para el cuidado contínuo de los individuos, poblaciones y otros sujetos de atención.
Reclamos y reembolso: Refiere a la facturación (incluyendo la verificación de autorización y elegibilidad), adjudicación y pagos (incluyendo ajustes y consultas de las cuentas) de servicios de salud.
Apoyo a las decisiones clínicas: Se encarga de definir mensajería para infobuttons. Los infobuttons son instrumentos de información en puntos de atención, que generan consultas online automáticamente sobre recursos de información de salud, utilizando información extraída de la Historia Clínica Electrónica (HCE) del paciente y de información del contexto (datos demográficos, datos de la atención médica actual, etc). Estas consultas sirven para proveer al profesional de la salud de información útil en el cuidado de ese paciente específico.
Arquitectura de documento clínico: Define una sintaxis basada en XML para definir documentación clínica estructurada. Un documento CDA puede incluir información de distintos tipos: textual, imágenes, sonidos, y otros contenidos multimedia. La estructura de documentos CDA es flexible, pudiendo representar muchos tipos de documentos clínicos diferentes.
Clínica genómica: Permite la interrelación de información clínica y genómica. Gran parte de la información genómica, aún es genérica, por ejemplo el genoma humano son las secuencias de ADN que se creen comunes a todo ser humano. La visión de medicina personalizada está basada en dichas correlaciones, que hacen uso de información genómica personal, que se diferencia entre dos personas cualesquiera.
Declaraciones clínicas: Define mensajería útil para la comunicación de declaraciones clínicas. Está definido de forma amplia, por lo que una misma declaración clínica podría tener múltiples formas de representación. Por lo tanto, para ser usado efectivamente, es necesario definir restricciones sobre el modelo de mensajes para cada contexto determinado.
Tipos de mensajes de elementos comunes: Este dominio se encarga de definir partes de estructuras comunes y reutilizables para los mensajes de diversos dominios.
Medidas de calidad: Define un estándar para la representación de medidas de calidad en salud, como un documento electrónico. Una medida de calidad es una herramienta cuantitativa que proporciona indicadores de rendimiento de un individuo u organización, en relación con una acción o proceso específico, o como medida de resultados clínicos.
Inmunización: Refiere a la comunicación de información sobre la inmunización: administración de vacunas y sueros a las personas, para prevenir enfermedades infecciosas.
Laboratorio: Consta de los mensajes necesarios para la comunicación de información de estudios y observaciones de laboratorio, incluyendo áreas como: química, hematología, serología, histología, citología, anatomía patológica, microbiología y virología.
Registros médicos: Apoya la gestión y consulta de documentos clínicos.
Administración de pacientes: Define la información demográfica del paciente, la cual será consumida desde otros sistemas como registros clínicos o sistemas financieros.
Administración de personal: Contiene la definición de roles, relaciones, credenciales, certificados, capacidades, competencias, calificaciones, privilegios, responsabilidades y asignación de tareas, emitidos para, o gestionados por, distintas entidades (persinas, organizaciones, dispositivos, etc).
Farmacia: Se encarga de definir mensajería para la prescripción, dispensación, y administración de medicamentos, tanto en farmacias externas como internas a la institución. También define mensajería para la solicitud de información del registro de medicación de un paciente (drogras, recetas, etc).
Registros: Se encarga de los registros administrativos de personas, pacientes, proveedores, equipamiento y lugares de prestación de servicios sanitarios.
Reportes de Salud Pública: Incluye los mensajes para apoyar la denuncia e investigación de enfermedades en el contexto de la Salud Pública.
Productos regulados: Incluye las normas elaboradas para la aprobación de productos regulados, y los mensajes para comunicar información de estos productos.
Estudios regulados: Incluye normas elaboradas para el intercambio de información sobre la realización de estudios reguados, y la comunicación de la información recolectada durante esos estudios.
Coordinación: Ofrece un conjunto genérico de mensajes para poder implementar cualquier contexto de coordinación.
Muestras: Comprende los mensajes relacionados con cualquier tipo de muestra. La información contenido es de la propia muestra, de su envase, y de los contenidos de este antes, rurante y después de que la muestra fue colocada en este.
Dispositivos terapéuticos: Comprende mensajes necesarios para la comunicación relacionada con la terapia y las observaciones hechas por dispositivos medicos. En la actualidad está centrado en los dispositivos cardíacos implantables.

Lo bueno de la división en "dominios", es que ante un desarrollo de software y la necesidad de implementar una determinada comunicación, por ejemplo de la HCE con el laboratorio, podemos encontrar toda la información necesaria en el dominio de laboratorio. A su vez, un dominio puede usar mensajes definidos en otros dominios, en este caso, el dominio proporcionará las referencias a los demás dominios. La desventaja es que cada dominio es creado y mantenido por un comité distinto e independiente de los demás, generando casos de dominios que se solapan. Otro posible problema (depende de cómo se mire), es que al ser tan genéricos, los dominios no son usables de forma directa, si no que es necesario pasar por un proceso previo de restricción y adecuación de los mensajes para usarlos en contextos específicos. Este tema será comentado más adelante bajo el título "guías de implementación".

Para la mensajería, HL7 define un conjunto de elementos:

Trigger event: es un evento determinado, que debe suceder para lanzar el envío de un mensaje de un sistema a otro. Este evento puede ser lanzado por la acción de una persona sobre el sistema, o del cumplimiento de una determinada condición en el propio sistema (sin intervención humana).
Message: es el mensaje propiamente dicho, con la información útil. Cada dominio define un conjunto de estructuras de mensajes con propósitos determinados.
Acknowledge: debido a la naturaleza de algunas transacciones, existen envíos de mensajes que necesitan una confirmación del receptor. HL7 define estructuras de mensajes de confirmación para este tipo de transacciones.
Control Act: define la estructura intermedia en los mensajes HL7 que da contexto al mensaje, como quien debe recibir el mensaje (lista de distribución) y quién es el autor. Esta estructura es la que contiene la información del mensaje.
Transmission Infrastructure: define el formato general de los contenedores de mensajes HL7, donde se especifica el emisor, el receptor, el dispositivo que se utiliza para la comunicación (canal), e indica cómo se debe responder al mensaje. Su contenido es el ControlAct.
Query Infrastructure: define una estructura de mensaje especial, que es utilizada para realizar consultas sobre determinados sistemas usando mensajería HL7. Esto ayuda a que si se tiene un sistema X y se implementa una interfaz de consultas HL7, cualquier sistema que use mensajería HL7 para las consultas, puede obtener datos del sistema X.

Tomando la especificación de mensajes en cualquier dominio, podemos ver que para cada mensaje se define también: quien envía, quien recibe, el ControlAct Wrapper (definido en Control Act), el TransmissionWrapper (definido en Transmission Infrastructure), y el Trigger Event que lanzará el envío de ese mensaje. Aquí podemos ver un ejemplo de definición de un mensaje de laboratorio. Vemos los elementos definidos para el mensaje, cada uno con su identificador. Para hacerlo menos críptico, aquí está el significado de los prefijos de los identificadores:

MCCI: Message Control Infrastructure
MCAI: Message Act Infrastructure
POLB: Laboratory Observations

Más información sobre identificadores aquí.

Guías de implementación: bajando el estándar a tierra

Como mencioné en un artículo previo, la implementación de HL7 no es directa ni trivial, y requiere un esfuerzo de especificación extra sobre la especificación del propio estándar. Esto es debido a que el estándar de mensajería intenta abarcar tantos casos particulares de una sola forma genérica que los mensajes no son usables de forma directa, y debe especificarse cómo se usarán. Esta tarea se realiza mediante "guías de implementación", que son documentos en texto plano, donde se definen las estructuras particulares de mensajes y atributos que se utilizarán en determinado contexto, junto con la semántica de cada campo, vocabularios controlados que serán usados (listados de códigos), etc. Un ejemplo de una guía de implementación para el dominio de Farmacia puede encontrarse aquí.

Siguiendo la especificación de HL7, para el intercambio de mensajes es necesario implementar el modelo de referencia (directa o indirectamente, p.e. implementando solo las clases específicas, no las centrales genéricas), luego es necesario implementar la mensajería genérica (p.e. la estructura de documentos clínicos: CDA), y sobre ésta, implementar los mensajes específicos (en el caso de documentación clínica, serían los documentos específicos como: registro de consulta en ambulatorio, consulta en emergencia, orden de estudios de laboratorio, orden de estudios imagenológicos, prescripción de medicamentos, etc). La siguiente imagen ejemplifica el objetivo de la implementación de mensajes y el proceso real para poder implementarlos.

Implementación de mensajería HL7v3

Interoperabilidad entre sistemas heterogéneos:

Para lograr interoperabilidad, la mensajería HL7 se basa en dos niveles básicos: estructura y códigos.

La estructura está definida por los modelos de mensajería, que a su vez están definidos en función de clases del HL7 RIM. Cada una de estas clases contiene un número de atributos donde aproximadamente la mitad son códigos definidos dentro de algún vocabulario restringido, cada uno con una semántica bien definida. De esta forma, tanto emisor como receptor podrán procesar la información de forma natural, ya que ambos conocen el HL7 RIM, ambos conocen que tipos de mensajes se intercambian (los identificadores de mensajes, trigger events, control acts y message wrappers, están en el propio mensaje), y cada campo codificado tiene asociado un vocabulario restringido, que es básicamente una tabla donde se define para cada atributo, sus posibles códigos, cada uno con su definición en texto narrativo.

El vocabulario controlado de HL7 puede encontrarse aquí.

Este enfoque de estructura + codificación aparentemente alcanza para que el receptor del mensaje pueda "entender" y usar la información contenida en este, dando la idea de interoperabilidad semántica. El problema es que los mensajes son contenedores de información, pero no garantizar en sí que los datos que contienen cumplen con su definición, ni que son consistentes entre sí. Por ejemplo, los documentos clínicos CDA tienen dos niveles de especificación de información: información narrativa (texto libre) e información estructurada (y codificada). El problema es que CDA no define ningún mecanismo que permita controlar que para una misma entrada, la parte narrativa es semánticamente esquivalente a la parte estructurada. En este trabajo se plantean algunos de estos problemas.

Lo que se necesitaría es algún estándar que permitiera verificar la consistencia de la información que viaja en los mensajes HL7, de forma de garantizar que la información y su contexto serán correctamente interpretados del lado del receptor. Con la información sola no alcanza para poder interpretarla correctamente, es necesario tener información de contexto como:

Quién registró la información: médico, paciente, enfermera, etc.
Para quién o qué se registró, para quién no: paciente, muestra, etc.
En qué momento y qué lugar: vía pública, ambulancia, depto. de emergencia, hogar, etc.
Cómo se registró la información: escritura directa, transcripción, etc.
Con qué fin fue registrada esa información: histórico, análisis estadístico, investigación.
Como debería o no debería ser usada esa información.
Qué consentimientos se tienen sobre la información registrada.
¿La información está completa? ¿Es correcta? ¿Qué grado de confianza se tiene?
Cuantificaciones y evaluaciones: prioridad, importancia, urgencia, gravedad, etc.

HL7 y la IHE

Como comentamos previamente, debido a la generalidad de las estructuras de los mensajes HL7 en cada uno de sus dominios, para poder utilizar estos mensajes es necesario restringir estas estructuras genéricas, adaptándolas a un contexto de uso determinado. Este proceso se llama "profiling" o "perfilamiento". Es un hecho de que los estándares HL7 deben ser perfilados para su uso.

Con este objetivo surge una organización llamada Integrating the Healthcare Enterprise (IHE), que básicamente se encarga de crear y mantener diversos perfiles de los mensajes HL7 para dominios específicos como: Administración de Pacientes, Radiología, Cardiología, Salud Pública, Laboratorio, entre otros. Estos perfiles son especificaciones técnicas que dicen cómo usar estándares genéricos en contextos específicos, por lo tanto podríamos decir que un perfil es como un caso de uso.

Por este motivo, cuando queramos implementar mensajería HL7 para algún contexto específico, es bueno primero visitar las especificaciones de IHE donde se puede encontrar algún perfil que satisfaga los requerimientos.

IHE básicamente trabaja con estándares de ISO, HL7, DICOM y W3C. Igualmente, los conceptos detrás de los perfiles pueden aplicarse a diversos estándares. Por ejemplo, uno podría implementar el perfil de Laboratorio usando mensajería CEN 13606 basada en arquetipos, en lugar de usar mensajería HL7.

El hecho de que se necesite una organización para definir cómo se usan los estándares creados por otra organización, parece absurdo. Creo que esta es una de las cosas que le juegan en contra a la adopción de HL7 v3, porque me parece que HL7 es lo suficientemente fuerte (como organización) para definir perfiles a sus propios estándares. Por otro lado, también juega en contra de que se quieran crear mensajes universales, tal que un único mensaje pueda modelar cientos de contextos distintos. Esto hace inusable al estándar en sí, y apoya al surgimiento de organizaciones como IHE.

Conclusiones

En este artículo introductorio intenté dar una mirada crítica e independiente a los estándares HL7, la cual entiendo que es necesaria porque creo que hay una falta de este tipo de miradas. También noto que cuando se habla de HL7, a veces sin haberlo investigado o probado, se tiene la idea de que es el único estándar y que soluciona todos los problemas de interoperabilidad, en cualquier ámbito, y con una inversión mínima de tiempo. Si bien HL7 tien muchas fortalezas, estas ideas están alejadas de la realidad. De lo contrario, ya tendríamos un sistema integrado de salud basada en HL7v3 funcionando hace años.

HL7 como organización es consciente de muchos de los problemas actuales, y está haciendo esfuerzos para mejorar los estándares. Por ejemplo, en este momento se está trabajando en la próxima versión de documentación clínica CDA (CDA R3), la cual estoy seguro de que traerá soluciones a muchos de los problemas que hoy tiene CDA R2.

Ventajas:

Permite crear un marco de comunicación a gran escala.

Es un excelente punto de partida para discutir cómo vamos a comunicar (no así para saber qué vamos a comunicar).

No hay otro estándar de mensajería tan ampliamente difundido (e implementado en el caso de HL7v2).
El más completo (en referencia a los dominios)
Capacidad de integrar terminologías estándar (CIE, SNOMED, etc).
Esquema de comunicación simple, basado en eventos y mensajes.
HL7 v3 se basa en mensajería XML.

Desventajas:

Complejidad: un solo modelo, más de 20 dominios, decenas de CMETS, mensajes e interacciones.
No es aplicable directamente, necesita acuerdos previos y la construcción de "guías de implementación", por lo que cuarta las posibilidades de una interoperabilidad semántica global.
No garantiza interoperabilidad semántica básica o global: para la primera necesita guías de implementación y para la segunda no provee mecanismos como si proveen ontologías y arquetipos.
Especificaciones crípticas (hay que hacer un curso para entenderlas, literalmente), solo en inglés, ambigüas y dependientes de la interpretación. La especificación completa de HL7 ocupa 2 CDs sin comprimir.
No usa estándares de modelado (UML), presenta problemas en el modelado de la información (clasificación, ambigüedad).
Calidad variable, complejidad de evaluación y trabajo en comités.
Requiere de una organización externa, con especificaciones propias, para implementarse correctamente. (IHE)
Necesita perfilamiento para poder aplicarlo, lo cual es un gran costo en tiempo

Incluimos boton para Digg

2011-01-08T23:27:00.000-02:00

Digg es un sitio web principalmente sobre noticias de ciencia y tecnología. Combina marcadores sociales, blogging y sindicación con una organización sin jerarquías, con control editorial democrático, lo cual permite que se publiquen artículos sobre una gran variedad de géneros.

Los usuarios envían relatos de noticias y recomendaciones de páginas web y los ponen a disposición de la comunidad, quien las juzgan y cuyo característico sistema valorativo se mide según la calificación de los usuarios.

Ahora todos los artículos de este blog tienen un botón de Digg al comienzo, el cual podrás usar para compartir el artículo con otros, comentarlo, valorarlo, criticarlo, etc.

http://es.wikipedia.org/wiki/Digg

Brasil elige OpenEHR como estándar de HCE a todos los niveles del gobierno

2011-01-06T12:01:00.000-02:00

Aquí está toda la información en inglés y archivos en portugués:
http://www.openehr.org/mailarchives/openehr-announce/msg00107.html

Algo para notar es el mix de estándares que eligieron para distintos temas. Esta es otra afirmación de algo que no me canso de afirmar: la clave no es elegir un estándar, si no un conjunto de estándares que se complementen y ataquen distintas áreas del problema (cada estándar tiene un propósito central y ninguno cubre todas las áreas).

Modelo de información de la HCE: openEHR
Terminología clínica de referencia: SNOMED CT
Documentos clínicos: HL7 CDA
Ubicación de registros de pacientes: IHE PIX (Patient Identifier Cross-Referencing) and PDQ (Patients Demographics Query)

Esto es sin dudas una gran noticia y la verdad es que Brasil viene haciendo y sigue haciendo bien las cosas.

Pablo.
http://informatica-medica.blogspot.com/

De que hablamos en este blog

2010-12-30T15:26:00.000-02:00

A modo de introducción y contextualización de los temas de los que hablamos en este blog, he creado una página con la recopilación de un conjunto de definiciones sobre la Informática Médica, tratando de responder un poco a las preguntas ¿qué es? ¿para qué sirve? ¿a qué aplica? etc.

Aquí está la página: http://informatica-medica.blogspot.com/p/informatica-medica.html

Documentacion de mi proyecto de grado

2010-12-25T22:42:00.003-02:00

Estimados,

En esta ocasión me gustaría dejarles un recopilado de la documentación generada durante el transcurso de mi proyecto de grado. El mismo consistió en la creación de una Historia Clínica Electrónica para el registro de la asistencia médica de pacientes gravemente traumatizados, por ejemplo: accidentados en el tránsito, baleados, apuñalados, precipitados de grandes alturas, etc.

Introducción al proyecto

En este proyecto tratamos de balancear dos fuentes de requerimientos bien distintas, los que venían de la parte médica y los requerimientos del equipo de desarrollo (Leandro y quien escribe). Hubo una tercera fuente de requerimientos que venían de la contraparte informática de la institución donde atendían los médicos.

Los requerimientos de la parte médica apuntaban directamente al registro y a la estructuración para permitir el análisis posterior, o sea, que no faltara ningún dato y que los datos necesarios para calcular indicadores estuvieran bien estructurados para simplificar cálculos, agrupaciones y consolidaciones.

Por nuestra parte, buscábamos orientarnos hacia la aplicación de estándares cuando fuera posible. Por otro lado, buscamos optimizar el modelado del a información que nos proveían los médicos. Nuestra experiencia fue que ellos piensan en datos y variables independientes, en lugar de conceptos clínicos y estructuras, y parte de nuestro trabajo consistió en unir y relacionar esos datos y variables independientes en estructuras de más alto nivel, que tuvieran correspondencias con conceptos clínicos de la realidad. También tuvimos en nuestras manos las decisiones sobre las tecnologías a emplear.

Desde la contraparte informática, los requerimientos estuvieron orientados a la alineación con los desarrollos locales y los estándares que ya se habían implementado en la institución.

La institución asistencial es cuestión es el Hospital Maciel, el cual es un hospital público y es una de las principales puertas de emergencia del país en cuanto a los pacientes traumatizados. La contraparte médica estuvo integrada principalmente por el Dr. Fernando Machado y el Dr. Gustavo Sanchez, también participó el Dr. Gerardo Barrios, presidente de la UNASEV.

Resultados y conclusiones

Lo que logramos fueron varias cosas. Por un lado, un producto que permite registrar todo lo que pasa en la atención de emergencia de pacientes traumatizados, desde que ingresan a la emergencia, hasta que salen de esta. Una de las principales características es que este sistema tiene integrado el acceso a estudios imagenológicos digitales, así que un médico puede ver todos los estudios de imágenes de sus pacientes, a través de la misma historia clínica.

Otro resultado fue un framework genérico que sirve para crear diversos sistemas de HCE basados en arquetipos OpenEHR. En realidad el producto final fue desarrollado como una configuración particular del framework genérico. Aquí se puede encontrar toda la información relativa a este nuevo proyecto open source, creado luego de terminar la tesis.

Por otro lado se logró demostrar que la aplicación de estándares en diversos aspectos de una HCE es posible de realizar, en plazos limitados de tiempo y contando con poco recurso humano (el proyecto duró un año y 4 meses, y lo armamos desde cero entre dos personas). Los estándares y especificaciones que integramos son:

openEHR: determinó gran parte de la arquitectura, diseño, modelo de información y modelo de conocimiento. Es el corazón del framework.
DICOM: se utilizó para crear el componente de acceso a estudios imagenológicos, para poder ver imágenes diagnósticas desde la propia HCE web.
CIE 10: se utilizó para la codificación de diagnósticos. Solo se utilizaron los códigos del capítulo XIX: Traumatismos, envenenamientos y algunas otras consecuencias de causa externa.
CDA: se utilizó para la generación de documentos clínicos en base a la información registrada en el sistema, de esta forma, toda la información registrada en el sistema queda accesible desde otros sistemas intercambiando documentos HL7 CDA.
IHE PDQ: se utilizó para poder consultar la base de datos de pacientes (que ya tenía la institución) desde nuestra HCE de trauma.

Material

A continuación dejo un link con toda la información del proyecto. Por un lado la entrega del proyecto (la tesis) está dividida en dos, los capítulos y los anexos. Luego está la presentación final del proyecto ante el tribunal evaluador. También encontrarán el paper y la presentación hecha en el CAIS 2010 donde hablé sobre el proyecto.

Actualización: dejé la documentación aquí: http://code.google.com/p/open-ehr-gen-framework/downloads/list

Cualquier pregunta o comentario, todo es bienvenido.

¡Feliz 2011!

Algunos pensamientos sobre inversión e impacto

2010-12-17T20:46:00.002-02:00

Hace un tiempo vi esta charla de Derek Sivers en TED, que más allá de lo gracioso, me dejó pensando en el modelo de atención médica occidental.

La frase de Derek que me dejó pensando es esta: "en China algunos doctores creen que su trabajo es mantenerte sano. Entonces, cada mes en el que estés sano, les pagas, pero cuando estás enfermo no les pagas porque ellos lo toman como que han hecho mal su trabajo. O sea, que ellos se hacen ricos cuando estás sano y no enfermo".

La primera vez que vi el video no me pude sacar de la cabeza las preguntas: ¿qué pasaría si eso fuera así aquí también? ¿qué pasaría si el objetivo y la acción de los sistemas sanitarios fueran enfocados directamente en la prevención y promoción de la salud?.

Una realidad un poco contradictoria, que se sigue dando, es que la mayor parte de la inversión está destinada a la atención especializada y super-especializada, la cual solo abarca una una pequeñísima parte de los usuarios del sistema sanitario. Mientras que en la atención primaria, donde se debería hacer prevención y promoción de la salud, la inversión es notoriamente menor.

Opino que gastar más en prevenir más, es ahorrar más. Y que esto tiene una gran potencialidad para aumentar la calidad de vida de la mayoría de la población.

Uno de los problemas que veo en ese sentido es que muchas veces los resultados y el impacto de la inversión en el primer nivel de atención son tan difíciles de evaluar, que los gestores prefieren invertir en cosas más notorias, como podría ser la compra de equipamiento, o la creación de un nuevo centro asistencial. También creo que la dificultad que existe para medir los impactos y resultados de las inversiones se dan porque estas inversiones no son acompañadas de un plan efectivo de medición y control. No tengo dudas que con el debido apoyo de las Tecnologías de la Información y la Comunicación (TICs), la medición y control para evaluar resultados e impacto serían más que factibles.

Si esto fuera cierto, algunos de los problemas que pueden tener los equipos de administradores, gestores y efectivizadores de estas inversiones podrían catalogarse como "problemas en gestión de proyectos", y que a su vez podrían estar dentro de esta lista:

Problemas en análisis de riesgos: es necesario tener en cuenta los factores externos e internos que pueden poner en peligro los proyectos de inversión, y desarrollar planes de contingencia acordes. Parece redundante mencionar este punto porque está en la tapa de cualquier libro de gestión de proyectos, pero la verdad es que no se pone en práctica.
Problemas en plan de comunicación: poner un plan en marcha muchas veces requiere de la participación de múltiples actores. Si un plan se pone en marcha y surgen actores que no quieren llevarlo adelante, o quejas por falta de información, entonces el error es de quien puso en marcha el plan/proyecto antes de contactarse con las personas e instituciones necesarias. El problema claramente no es de quien no quiere hacer la tarea, es de quien no comunicó en su debido momento a esa persona.
Problemas en plan de control: previo a la puesta en marcha de cualquier proyecto, debe establecerse un proceso de medición y control, para detectar desvíos de lo planificado lo antes posible, y tomar medidas correctivas antes de que surjan los problemas. No tener un plan de medición y control, es un riesgo que se debe analizar y contener debidamente.
Problemas en análisis del impacto: el impacto no es el cumplimiento de los objetivos de un proyecto, plan o estrategia. El impacto es el resultado final de esas acciones. O sea, que es la diferencia entre el estado final y el estado inicial. El impacto muchas veces excede a los objetivos, por que los proyectos pueden impactar positiva o negativamente en un sin número de actores, directa o indirectamente. Para medirlo correctamente se necesita mucha información, tanto de la ejecución y control de cada proyecto, como información de realimentación de los propios actores. Por las inmensas cantidades de información que se deben manejar, no hay otra opción que utilizar TICs para analizar correctamente la información y tener una idea clara del impacto.
Problemas de agenda: muchas veces quienes ejecutan estas inversiones y planes son agentes políticos, por lo que a veces vale más poner un plan en marcha y hacerlo visible, a que el propio plan sea un éxito y beneficie realmente a la sociedad.
Problemas de asesoría: en cada área existen expertos, tanto en gestión de proyectos, gestión de riesgos, comunicación y cambio cultural, análisis de impacto y retorno de inversión, etc, etc. Sabiendo que existen, no recurrir a estos especialistas es en sí un problema y un riesgo en cualquier proyecto.

Seguramente existan más problemas que no estoy incluyendo aquí. Me gustaría saber sus opiniones sobre el tema, más que nada para ver que tan válido es este razonamiento, o también para ver si estoy muy alejado de la realidad.

Grandes problemas de estandarización

2010-12-10T17:51:00.002-02:00

Los grandes problemas de estandarización del Sistema Nacional Integrado de Salud uruguayo

Profundizando un poco la visión del artículo de Heather Leslie, me gustaría gastar algunas palabras en brindar una mirada crítica de lo que está pasando en Uruguay con respecto a la estandarización en salud.

Un hecho (un poco contradictorio) es que los grandes actores en el Sistema Nacional "Integrado" de Salud (SNIS) sostienen el discurso de "la estandarización es necesaria e inevitable si realmente queremos un sistema integrado". Pero por otro lado, la aplicación de TICs en salud que hacen estos mismos actores no contempla ningún tipo de estándar.

Las causas de esto son varias. Por un lado existe un gran ruido externo que promueve una familia de estándares para resolver "todos" los problemas de estandarización en l aplicación de TICs en salud, y nuestra cultura de "seguir al líder" aporta a que muchos quieran ir en el camino del que hace más ruido (muchas veces sin saber a ciencia cierta cual es el costo de ese camino y cual va a ser el retorno de inversión). Esto a su vez hace que quienes "dicen" que quieren aplicar estándares, no los saben aplicar correctamente, entonces cuando deben resolver un problema real, dejan los estándares de lado y se concentran el los desarrollos a medida que los saquen del paso.

Otra causa posible de esta contradicción es la falta de recursos humanos capacitados. En Uruguay existe muy poca gente que sabe de estándares aplicados a TICs en salud. Y con saber me refiero no a gente que sepa algunos nombres y cual es el objetivo de cada estándar, si no de gente que haya probado estándares, que conozca más de una alternativa para resolver un problema, que haya comparado estándares de forma crítica (con visión independiente), y que pueda saber cuál es el costo real de implementar un estándar, y pueda estimar cuál fue el retorno en esa inversión (como para saber si ese camino vale la pena). Lamentablemente existen muy pocos trabajos a nivel nacional en ese sentido.

Por otro lado, los estándares que son más nombrados (pero nunca analizados en profundidad), son estándares para la comunicación de datos clínicos. Pero no se están definiendo cuáles van a ser los contenidos de esas comunicaciones. Entonces tendríamos una gran cañería para pero sin saber que va a transportar: agua, gas, etc. Creo que esto es una de las grandes fallas de visión de todo el sistema, y a lo que apunta el artículo de Heather: concentrémonos en definir de forma coordinada y consensuada el contenido clínico, y luego pensemos en cómo comunicarlo (es un simple tema de orden).

Cabe hacer la aclaración que existen organizaciones dentro del sistema de salud que están definiendo contenidos clínicos, pero estos contenidos están basados en requerimientos locales de esas organizaciones, por lo que es posible que ese contenido no pueda ser reutilizado por otras organizaciones.

Mi visión en este tema es:

En lugar de "seguir a líder" (o por lo menos al que "hace más ruido"), "tomemos lo mejor, adaptémoslo al contexto nacional, e innovemos donde nuestros requerimientos no pueden ser satisfechos con estándares internacionales (creemos estándares locales)".
Definamos por un lado el contenido clínico: documentos, conceptos, datos, restricciones, reglas, etc, y por otro busquemos estándares que puedan modelar estos elementos (aplicándolos tal cual, o adaptándolos a la realidad nacional).
Generemos estándares locales para los elementos que no pueden ser modelados de forma efectiva por estándares internacionales.
Definamos procesos de certificación de las herramientas de software, para validar que los proveedores ofrecen herramientas que cumplen nuestros estándares.
Hagamos leyes que obliguen a que las herramientas que se usan en las instituciones sanitarias, en los entes reguladores, organismos y en el propio Ministerio de Salud Pública, deban estar certificadas.
Creemos una infraestructura de información en salud, criterios de intercambio de esta información, y servicios de uso público (tanto para las instituciones como para los pacientes y médicos). Esta infraestructura permitirá intercambiar toda la información necesaria para controlar a las instituciones sanitarias a nivel de gobierno (lo que hoy se realiza mediante procesos dolorosos, costosos y poco efectivos, hacerlos de forma automática, exacta y con costo cero).
Implantemos un proceso de mejora continua de todo el sistema de salud. Al final del proceso tendremos un sistema gestionable, medible, optimizable, coordinado, en definitiva: realmente integrado.

Algunas discusiones sobre estandarización a nivel nacional:

Imagenologia digital: breve introduccion

2010-12-07T17:53:00.004-02:00

Este el el primer artículo del blog sobre el tema de la imagenología digital. La idea inicial era crear un artículo sobre experiencias, pero me pareció que sería útil crear un artículo introductorio al tema y luego ahondar en las experiencias.

Seguramente publicaré un par de artículos como guía y contexto, uno sobre modalidades en imagenología digital y otro directamente sobre el estándar DICOM.

Fuente: Advertolog

Introducción

Hablamos de "imagenología" en lugar de "radiología" porque es un término más inclusivo, ya que la "radiología" implica que las imágenes se obtienen por la emisión de radiación, clasificación que deja por fuera modalidades como ecografía, resonancia magnética o PET.

El término "digital" lo utilizamos porque en última instancia el estudio termina siendo un conjunto de imágenes en formato digital, que se pueden almacenar en un medio magnético u óptico (disco duro, pendrie, DVD, etc). Esto no implica que las imágenes sean generadas de forma digital, existen modalidades generadas de forma analógica y luego digitalizadas, como es la radiografía computarizada (CR).

Por otro lado, la imagenología digital busca mejorar los procesos de petición, coordinación, realización, informe y obtención de resultados, resultando en ventajas para el paciente, el equipo médico, y la institución sanitaria.

Ventajas de la imagenología digital

Seguridad y comodidad del paciente

Con los avances hechos en al área, tanto los equipos digitales como los equipos analógicos cuyos resultados se digitalizan, requieren emitir un menor nivel de radiación para generar una imagen de calidad para el diagnósticos. Por lo tanto, la radiación absorbida por el paciente es menor.

Con el proceso digital, el paciente no se lleva para su casa grandes placas, que debe acumular durante toda su vida en su hogar, y que debe llevar a la institución sanitaria cada vez que tiene consulta con su médico. Por el contrario, toda la información queda almacenada en la propia institución.

Accesibilidad e integración con la HCE

Debido a que toda la información imagenológica se encuentra en la institución sanitaria, esta puede ser accedida desde cualquier punto de su red local, permitiendo que un médico pueda acceder a los estudios de su paciente, independientemente de dónde se encuentre dentro de la institución. Si además la institución permite acceso desde fuera de esta, el médico podría ver los estudios de sus pacientes desde su propia casa, oficina, o tomando un café en un bar.

El acceso a los estudios desde fuera de la institución, permite además la "teleradiología". Esta aplicación permite que un experto o grupo de expertos radiólogos, puedan visualizar y crear informes radiológicos sobre un determinado estudio. Por lo tanto, no se necesitaría un experto constantemente en la institución sanitaria. Entonces, cuando se tenga un estudio que debe ser informado, cualquier radiólogo disponible, puede crear el informe de forma remota. Esto permite que haya centros de diagnóstico especializados, con equipo como los costosos "monitores de grado médico", que permiten visualizar las imágenes digitales con un gran nivel de detalle y calidad.

Por otro lado, al tener los estudios imagenológicos en formato digital, pueden ser integrados a la historia clínica electrónica del paciente, por lo que cualquier médico que tenga acceso a la historia, podrá ver las imágenes y los informes de esos estudios. Esto aporta a la completitud de la HCE, cosa imposible de hacer con la HC tradicional en papel.

Mejoras en los procesos

La imagenología digital permite que los proceso que hoy se hacen con interfaz humano-humano y humano-papel-humano, con las contras que esto tiene (olvidos, errores, pérdidas, repetición de estudios, etc), sean realizados como procesos humano-sistema informático-humano con las ventajas de que:

Queda registrado quién pidió el estudio
Queda registrado para quién se pidió el estudio (paciente identificado correctamente desde el inicio)
Queda registrada toda la información del estudio (qué estudio, donde, cómo, etc)
Queda registrada la coordinación del estudio (día, hora, lugar, condiciones a cumplir por el paciente como ayuno, etc)
Queda registrado el estudio (conjunto de imágenes, que a su vez están identificadas con un determinado paciente)
Queda registrado el informe del estudio (identificando al autor del informe, al paciente y asociado al estudio correspondiente)
Toda la información queda disponible para consulta en cualquier momento

Acceso del médico que pidió el estudio
Gestión y mejora de calidad (medición de tiempos, satisfacción del paciente, etc)

Vinculación del estudio con la HCE a través de la identificación del paciente

Disminución de costos

Por último, ya no es necesario comprar películas ni placas, agentes químicos como reveladores y fijadores. Tampoco es necesaria la compra y mantenimiento de procesadores de placas y equipos de revelado. Por otro lado, el espacio necesario para almacenar esta información se reduce enormemente, debido a que todo puede ser almacenado en un servidor.

Procesos y sistemas de información involucrados

En los procesos relacionados con estudios imagenológicos, pueden existir y coexistir varios sistemas informáticos. En general se habla de la coexistencia de 3 sistemas informáticos bien separados:

HIS: Hospital Information System
RIS: Radiology Information System
PACS: Picture Archiving and Communication System

Si bien en la literatura se pueden encontrar como 3 sistemas bien separados, en realidad muchas veces sus funcionalidades se solapan, hasta el punto, por ejemplo, de que un solo sistema haga de RIS y PACS.

A continuación, dejo un excelente diagrama extraído de una presentación del curso de imágenes médicas [1], que muestra las funcionalidades y las relaciones entre los sistemas:

[1] Curso de imágenes médicas, IIE, FIng.
http://iie.fing.edu.uy/~mdavid/ib/imag%20digital%20y%20pacs%20Daniel%20Geido.pps

Informacion clinica no es solo comunicacion

2010-12-06T18:06:00.002-02:00

Hoy he leído un artículo bien interesante de Heather Leslie (@omowizard), donde compara los distintos enfoques de proyectos para sustentar el sistema de salud a nivel país, por un lado EEUU y por otro Suecia. Heather da algunos ejemplos de las áreas en las que hay que tener sumo cuidado, ejemplos de proyectos desastrosos, pero sobre todo el mensaje que da es "concentrémonos en modelar la información de una manera consistente en lugar de buscar mecanismos para intercambiar información (que ni siquiera sabemos si es consistente)".

Sin dudas es un artículo provocativo, pero en lugar de dar opinión sobre cual es el camino a seguir, plantea el debate para que nosotros pensemos en donde queremos estar en un futuro cercano y más a largo plazo.

Aquí el artículo original

Aquí el artículo traducido automáticamente

Importancia de la informacion en salud

2010-12-05T15:01:00.004-02:00

Aquí les dejo otra charla TED que no tiene que ver directamente con la informática médica, pero si con la información en general. En esta ocasión el presentador es David McCandless, y su charla "The beauty of data visualization" no tiene desperdicio.

McCandless brinda varios ejemplos de cómo poder visualizar datos y su contexto de forma de que su interpretación sea fundamentada y correcta, sobre todo cuando uno está sumergido en un mar de datos y no sabe por donde empezar a leerlos e interpretarlos. ¡Qué importante es esto para la salud!

Pensando en el dominio de la salud, un concepto que menciona McCandless y que me quedó grabado en la cabeza por varios días es: los datos, su estructura y contexto pueden cambiar nuestra forma de ver las cosas, nuestra perspectiva, y como consecuencia, cambia nuestro comportamiento. Entonces, si la información puede cambiar las acciones que un médico va a realizar, y éste cuenta con información errónea, incompleta, fragmentada, inaccesible, etc, etc, es probable que nuestro médico tome una decisión que no sea la óptima.

Un concepto que me gustaría agregar es que hoy la información (datos, estructura, relaciones y contexto) es un recurso básico en las instituciones sanitarias, con esto quiero decir que es tan o más importante que el agua, la electricidad, el teléfono, etc. Y que al igual que el agua, es necesario crear tanques y cañerías donde se pueda mantener y distribuir la información.

Aquí la charla:

Más información sobre David McCandless: http://www.davidmccandless.com/
Sitio sobre visualización de la información: http://www.informationisbeautiful.net/

Los 10 mandamientos de la HCE

2010-12-01T16:31:00.001-02:00

Luego de leer varias "biblias" de lo que se debe y no debe hacer en la implementación de la Historia Clínica Electrónica (HCE) en una institución sanitaria, y considerando de algunas experiencias de campo, creo que puede ser útil hacer una propuesta de los 10 puntos más importantes que son necesarios considerar en la creación e implementación de una HCE (a modo de "mandamientos", solo para hacerlo entretenido).

Los invito a hacer el mismo ejercicio y pensar para ustedes ¿cuáles serían los 10 temas más importantes en la creación e implantación de la HCE en una institución sanitaria?. Debajo del artículo pueden agregar sus comentarios.

1. Identificarás a tus personas

Todas las personas, que participan en cada acto médico y proceso asistencial, deben estar correctamente identificadas: pacientes, médicos, enfermeras, técnicos, administrativos, estudiantes, etc.

La identificación de los pacientes es la más complicada de resolver, ya que no depende de la asignación de un código o número identificador, si no, que depende de los procesos de asignación, verificación y auditoría.

Asignación: proceso de registro de información demográfica, y asignación de uno o más identificadores.
Verificación: obtención de la información suficiente para realizar una búsqueda y encontrar uno o más identificadores asignados a esa persona.
Auditoría: proceso que implica la certificación de que la información demográfica de la persona está completa y es correcta.

2. Identificarás a tus proveedores e insumos

Todas las empresas que provean algún tipo de insumo a una institución sanitaria, debe ser correctamente identificada, se deben tener medios de contacto de las personas que serán contraparte. También se deberá identificar cada insumo provisto por cada proveedor, y saber con certeza cuanto de cada insumo hay disponible en un momento dado (stock).

3. Identificarás a tus productos y servicios

Toda institución sanitaria debe saber con certeza qué productos y servicios provee, cual es el costo que insume brindarlos, por quién o quienes se brindan estos servicios (credenciales), desde donde se pueden brindar (lugares físicos) y para quién o quienes se brindan (clientes).

4. Sabrás quienes son tus pacientes, donde están y qué tienen

Aparte de que todo paciente deba estar unívoca e inequívocamente identificados en una institución sanitaria, los médicos de cabecera o médicos de familia deben saber cuáles pacientes tienen asignados, dónde viven y trabajan, y qué enfermedades, problemas de salud o condiciones tiene cada uno.
En este punto, la información geográfica y la identificación de problemas de salud es crucial. Este punto resume la base de la gestión clínica y de la epidemiología.

5. Especificarás tus procesos

Antes de poder comenzar con la informatización de los proceso asistenciales, es necesario saber cuáles son, quienes son responsables de estos procesos, quiénes participan, cuáles son los resultados esperados, y las precondiciones y restricciones que se dan.
Informatizar procesos indefinidos o caóticos es un error costoso.

6. El ADT es la primer aproximación a la HCE

El ADT (Admisión-Alta-Transferencia en inglés) puede implementarse como un sistema informático que sirva para saber:

por dónde, cuándo y con qué motivo ingresan los pacientes.
cuándo, a dónde, con qué motivo y a qué especialidad son transferidos los pacientes.
cuándo y a qué especialidades se realizan interconsultas.
a dónde, cuándo y con qué motivo se realizan las altas.

http://informatica-medica.blogspot.com/2009/11/primer-aproximacion-la-historia-clinica.html

7. La HCE permitirá registrar toda la información clínica

Ningún sistema informático puede establecer trabas a la libertad del registro del médico. La HCE mínima debe, por lo menos, contener al registro análogo en soporte papel.
En etapas tempranas, los registros con cuadros de texto libre son más aconsejables que los registros estructurados.
Estas HCEs mínimas se deberían implantar sobre los sistemas de ADT, ya que los eventos administrativos en el ADT desencadenan procesos de atención médica, con el respectivo registro en la HCE. Luego, los datos de ambos sistemas serán insumos fundamentales para la gestión.

8. Debes proveer trazabilidad en los sistemas informáticos

Debe quedar un registro de todas las acciones que realiza cada usuario del sistema informático. Para una correcta trazabilidad es necesario:

Identificar a los usuarios del sistema informático.
Registrar qué información ven, qué información agregan, qué información modifican.
Desde dónde acceden al sistema (lugar físico, terminal).
Cuándo acceden, durante cuánto tiempo (duración de la sesión, momento de cada acción).
Saber si intentan realizar acciones para las que no están autorizados (verificación de credenciales).

9. Debes crear un sistema usable

El sistema debe responder rápida y correctamente a los pedidos de los usuarios. Debe estar disponible cuando un usuario lo desea usar. Debe tener una interfaz gráfica amigable, simple, ordenada y fácil de entender. Se debe diseñar la interacción del usuario con el sistema (ejemplo: minimizar la cantidad de clics para que el usuario obtenga lo que desea del sistema). Los médicos deben acceder a la información de sus pacientes cuándo la necesiten y desde dónde la necesiten.

10. Aplicarás estándares

Para crear sistemas informáticos de calidad, debes basar tus sistemas en estándares probados y aceptados por una comunidad. Reutilizando y adaptándolos a la realidad de un país o una institución en particular. No reinventarás la rueda, y reutilizarás las herramientas existentes y disponibles.
La estandarización simplifica la informatización y el desarrollo de nuevos componentes y funcionalidades que extiendan y adapten el sistema informático a nuevos requerimientos.
La estandarización es la base de la interoperabilidad.

Si bien la idea no es crear una religión al rededor de estos mandamientos, tal vez sirvan como guía para quienes empiezan con desarrollos de HCE en sus instituciones (digamos que estamos evangelizando) a la comunidad de informáticos y médicos involucrados en desarrollos de HCE.

¡Espero sus comentarios!

El futuro de la medicina movil

2010-11-24T18:05:00.004-02:00

Esta es una gran presentación del Dr. Eric Topol para TED. Desde la primera vez, y siempre que la vuelvo a ver me cuestiono los límites de la aplicación de las Tecnologías de la Información y Comunicación (TICs) en el sector salud, la respuesta es siempre la misma: el límite es la imaginación.

Un mensaje claro del Dr. Topol es que no se está haciendo "futurología", hoy ya existe la tecnología que nos permite hacer cosas impresionantes y ver impactos reales en la mejora de la salud de la población. Lo que nos deberíamos preguntar es porqué estas tecnologías no son implementadas a niveles masivos. ¿Es a caso una resistencia del sector salud? ¿es un problema de los proveedores que no pueden mostrar y demostrar las ventajas de la tecnología bien aplicada? ¿es un problema de los gobiernos, su falta de resolución y la falta de asesoría? ¿es un problema de falta de recursos humanos capacitados y especializados? o ¿será una mezcla de todo?

Aquí la charla:

Taxonomia de estandares en informatica medica

2010-11-23T05:52:00.001-02:00

Este artículo más que mostrar y explicar algo que existe, está más orientado a dar mi opinión personal, a hacer alguna propuesta y a generar discusión al respecto.

Me ha pasado varias veces, que hablando con colegas en el ámbito de la Informática Médica (IM) (informáticos, médicos, técnicos, etc), me preguntan si elegir tal o cual estándar para aplicar en sus sistemas de información.

Me han preguntado cosas como ¿elegimos CIE 10 o Snomed?, ¿elegimos OpenEHR o HL7?, etc. En estos casos, detecto que hay dos problemas presentes. Primero, no se tiene claro "el requerimiento", o esa ¿para qué aplicar un estándar?. Suena obvio, pero muchos quieren aplicar estándares sin saber realmente en donde y porqué. Es como el típico comentario sobre la aplicación de la tecnología por la tecnología en sí, sin ver realmente a la tecnología como la herramienta (que es) para alcanzar un objetivo. Segundo, no podemos comparar papas con manzanas. El problema (creo) es que no existe una taxonomía clara que clasifique, catalogue y agrupe estándares que cubren una misma área o que tienen un objetivo similar.

El objetivo de este artículo es por un lado, tener un referencia para poder compartir con los colegas cuando hayan dudas respecto a los estándares, y otra, es proponer una taxonomía que pueda ayudar a ordenar un poco este "mar de estándares" en el que estamos inmersos. Creo que una "taxonomía definitiva" es difícil de alcanzar, porque para crearla se necesitan múltiples visiones, tanto la de los expertos en los estándares, la clínica y la informática (es necesario saber cómo se crean los sistemas informáticos para catalogar estándares que afecten a la arquitectura de un sistema, y a cómo un conjunto de sistemas se comunican entre sí, y estas son áreas cubiertas por múltiples estándares).

Existe un trabajo de K. Kim para la California Healthcare Foundation del 2005, en donde propone a grandes rasgos una categorización para los estándares, que divide en las siguientes categorías:

Intercambio de datos/mensajes
Terminología
Documentos
Conceptuales
De aplicación
De arquitectura

A continuación vemos con un poco más de detalle el significado de lo que llamaremos la "categorización de Kim".

Intercambio de datos/mensajes
Permiten que las transacciones fluyan consistentemente entre sistemas [informáticos] u organizaciones, debido a que contienen instrucciones (o especificaciones) para el formato, datos y estructura. Ejemplos que brinda Kim: HL7 para datos administrativos como información demográfica y de encuentros, DICOM para imágenes radiológicas, y NCPDP para prescripciones electrónicas.

Terminología
Estos vocabularios proveen códigos específicos para los conceptos clínicos como enfermedades, listas de problemas, alergias, medicaciones, y diagnósticos, que pueden tener descripciones textuales variables para un registro en papel o una transcripción. Ejemplos que brinda Kim: LOINC para resultados de laboratorio, SNOMED para términos clínicos, ICD para diagnósticos médicos.

Documentos:
Para indicar qué tipo de información es incluida en un documento y dónde esta información puede ser encontrada. Ejemplos que brinda Kim: formato SOEP (subjetivo, objetivo, evaluación, plan), CCR (continuity of care record), CDA (clinical document architecture).

Conceptuales:
Permiten que los datos puedan ser transportados entre sistemas sin que pierdan significado y contexto. Ejemplos que brinda Kim: HL7 RIM.

De aplicación:
Estos determinan la forma en que las reglas de negocio son implementadas, y en que los sistemas de software interaccionan. Ejemplos que brinda Kim: SSO (single sign-on), estándares para visualización de información entre bases de datos distribuidas.

De arquitectura:
Estos definen el proceso comprendido en el almacenamiento y distribución de datos. Ejemplos que brinda Kim: centros de control de enfermermedades y salud pública (PHIN), arquitectura funcional del Institute of Medicine y HL7.

Si bien la categorización de Kim parece comprensible, incluso creo que es un buen inicio cuando uno se está introduciendo en los estándares para Informática Médica, mi impresión al ver esta lista por primera vez fue "aquí falta algo". Esta impresión creo que se dio por dos razones. La primera, conocía estándares que no estaban considerados estríctamente en las categorías de Kim. Segundo, la categorización, así como todo el trabajo de Kim, está guiada más que nada por estándares HL7, de las terminologías que éste utiliza y de los estándares que comprenden los perfiles IHE (fuértemente ligados a HL7), entonces ¿qué pasa con los estándares ISO, CEN, OpenEHR, OMG, ...?

La crítica que le puedo hacer a la categorización de Kim (que como dije: es buena como primer aproximación), es para quienes necesitamos una categorización más clara, que considere la mayoría de estándares de aplicación en IM, sin un estándar que pueda caer en varias categorías (o sea categorías que se solapen), y que cada categoría tenga una descripción clara de qué tipos de estándares entran en ella y cuáles no. En definitiva: una categorización más rigurosa. Algunos ejemplos de la falta de rigurosidad de la categorización de Kim, en mi humilde opinión, son:

Las descripciones de las categorías "Intercambio de datos/mensajes" (...formato, datos y estructura), "Documentos" (...qué tipo de información es incluida en un documento y dónde esta información puede ser encontrada), "Conceptuales" (Permiten que los datos puedan ser transportados...) y "Arquitectura" (...distribución de datos), tienen claros signos de solapamiento. Entonces es útil definir una categoría donde se puedan agrupar los estándares que definen datos y su estructura, otra categoría para estándares que especifican la semántica de esos datos, otra para indicar cómo esos datos son representados mediante documentos y mensajes, y otra que especifique cómo distintos actores intercambian esos documentos y mensajes.
Los nombres de las categorías son ambiguos y su descripción no ayuda a clarificarlos. Por ejemplo, los estándares de "Terminología" son en sí clasificadores de conocimiento clínico, y la codificación de este conocimiento es un producto de estas clasificaciones que simplifica su uso en sistemas informáticos, aquí se presenta como que el objetivo de los estándares terminológicos es la codificación. Luego, el nombre de "Estándares conceptuales" es algo tan genérico que no agrega información. En si todos los estándares son conceptuales, ya que todos de una forma u otra intentan ordenar el conocimiento médico para permitir su representación en sistemas informáticos, y esto obviamente se hace mediante modelos y otras construcciones conceptuales. En este caso el nombre "Modelo" sería equivalente al de "Conceptual", el problema es que es necesario especificar modelo de qué cosa. El ejemplo que da Kim es HL7 RIM, así que una opción es "modelo de información para la mensajería", pero existen otras construcciones conceptuales que no son modelos de mensajería, como lo es el modelo datos de DICOM o el modelo de información de OpenEHR. Lo mismo ocurre con "estándares de aplicación", de una forma u otra todos son estándares que deben ser implementados en una aplicación de software. Además estándares para el almacenamiento y comunicación de información podrían estar en esta categoría, sin embargo están en la categoría "estándares de arquitectura". Y por último, los "estándares de arquitectura", para cualquier arquitecto de software es fácil saber que debería entrar en esta categoría: estándares para definir componentes, sus dependencias, y la forma en que estos interactúan (interfaces, transacciones, mensajes, servicios, etc, todos items que pueden caer en cualquiera de las categorías anteriores).
Algunos problemas con los ejemplos: en el caso de "estándares de documentos", se brinda SOEP como un estándar de formato de documento, junto con CCR y CDA. Si bien SOEP podría tomarse como una estructuración de un documento clínico con cuatro áreas bien marcadas, creo que SOEP es más un "modelo de registro" que un "formato de documento". Además en el contexto de los ejemplos, difiere de CCR y CDA en que éstos son definiciones para documentos electrónicos estructurados. En la categoría de "estándares conceptuales", ¿solo HL7 RIM permite que los datos puedan ser transportados sin perder significado y contexto? ¿qué hay de ISO 13606 o mismo del ASTM CCR?. Por otro lado, en la categoría de "arquitectura", los ejemplos que se brindan son de superarquitecturas al nivel de Estados Unidos, ¿donde entran las micro y meso arquitecturas?, es decir, arquitecturas a nivel de una institución, de una federación, o de un país pequeño. Por otro lado, muchos elementos descritos en las demás categorías, influyen en la arquitectura del sistema, cualquiera sea el tamaño de este, por lo que todas las categorías están relacionadas e interconectadas.

La pregunta que surge es ¿habrá una mejor categorización? ¿con categorías más claras y menos solapadas?. Creo que si, pero no creo que la presentación en un nivel sea la más correcta para esta categorización. Éste creo que es el principal problema de la categorización de Kim, que laa categoría "A" mira un conjunto de atributos desde un punto de vista, y otra categoría "B" mira otro conjunto de atributos (potencialmente compartidos con la categoría "A"), y ambas categorías se encuentran en un mismo nivel, entonces al querer clasificar un estándar no sabré en cual categoría ponerlo (tal vez elija la que considera más atributos importantes del estándar en cuestión, por ejemplo si hay que clasificar HL7 RIM en una sola categoría, lo pondría en "intercambio de mensajes", porque el objetivo de ese estándar es la representación de datos para el intercambio de mensajes).

De esta discusión surge entonces que para clasificar podría ser útil considerar distintos "puntos de vista", y luego clasificar según ese punto de vista, y tal vez el mismo estándar se pueda clasificar varias veces según distintos puntos de vista.

Según mi experiencia en el estudio de estándares en IM y en la creación de Sistemas de Información en Salud (SIS), algunos "puntos de vista" o "dimensiones" interesantes podrían ser (lista no exhaustiva):

Dimensión de la información y la semántica: cómo se definen y se representan los datos, la información y el conocimiento en salud.
Dimensión del sistema: componentes de un SIS, requerimientos, funcionalidad, servicios, etc.
Dimensión de la comunicación: cómo se comunican distintos SIS, qué información intercambian, con qué finalidad, protocolos, seguridad, interfaces, mensajes, etc.
Dimensión de la integración: evolución desde sistemas aislados hasta infraestructuras de información para salud, indica los distintos niveles por los que es necesario pasar para lograr un sistema de salud integrado.

Algunas ideas atrás de estas dimensiones:

Información y semántica
Múltiples estándares definen alguna forma de representar datos, estructuras, restricciones, reglas, contexto, etc. Creo que es útil analizar en qué se diferencian estos modelos de información y semántica y cuáles cosas tienen en común. Esto no solo sirve para clasificar un estándar en uno u otro grupo, si no que sirve para detectar compatibilidades o incompatibilidades entre varios estándares del mismo grupo.
Esta dimensión encierra todo lo referido al modelado y representación de la información, independientemente de su uso (persistencia, comunicación, conceptualización del dominio, etc).

Dimensión del sistema
Todo estándar de una u otra forma afecta a cómo son construidos los sistemas. Esta dimensión trata de catalogar los estándares según el componente que afecten dentro de la construcción del sistema. Y si son estándares que directamente definen una arquitectura determinada, también contemplarlos en esta dimensión.

Dimensión de la comunicación
El nombre está más que claro. Esta dimensión agrupará todos los estándares que afecten de alguna forma a algún elemento que participe en la comunicación de información, esto quiere decir que afecta: al emisor, al receptor, al canal, al mensaje y/o al contexto. Dentro de esta dimensión, distintos categorías pueden agrupar estándares de "protocolos de comunicación", de "formatos de mensajes", de "interfaces", etc.

Dimensión de la integración
Esta dimensión es la de "más alto nivel", es en donde se agrupan todas las visiones para lograr objetivos específicos, primero sistemas orientados por estándares, segundo redes de sistemas, y por último una plataforma de servicios que permita que nuevas redes y nuevos servicios puedan desplegarse bajo demanda (si, como un Internet para salud, a esta idea le dedicaré su propio artículo).

Una quinta dimensión podría agrupar los estándares de uso general, que suelen ser usados por estándares específicos en Informática Médica, como pueden ser XML, ADL, UML, OWL, etc. A esta dimensión podríamos llamarle "Dimensión de infraestructura" o "Dimensión transversal", porque atraviesa a las demás dimensiones.

El lector astuto ya habrá detectado un padrón en estas dimensiones, y es que si las seguimos en orden, lo que estamos haciendo es crear sistemas desde la unidad más básica, hasta llegar a grandes redes que pueden ofrecer servicios y soportar los sistemas de salud de los distintos países, cosa que es posible solamente si partimos de la estandarización a niveles casi atómicos en los SIS. Además, de estas descripciones pueden desprenderse algunas categorías interesantes, formando así una taxonomía genérica que podría clasificar cualquier estándar para IM. El resultado es algo así:

Dimensión de la información y la semántica:

Datos: son hechos, símbolos y señales objetivas. Son elementos semánticos atómicos. Por si solos son irrelevantes, por lo que necesitan un contexto que permita utilizar los valores Por ejemplo el símbolo "I10" por si solo no dice nada, pero si se establece el contexto de que es un código CIE 10, éste símbolo representa el concepto de "hipertensión arterial primaria". Existen varios ejemplos de elementos que caen en esta categoría, entre ellos las codificaciones resultado de las terminologías, y las definiciones de tipos de datos básicos que proveen varios estándares.
Información: es un conjunto de datos procesados, que tienen un significado (relevancia, propósito, contexto). En general se obtiene brindando formato, estructura, relaciones, restricciones y una correcta visualización sobre los datos atómicos. Un ejemplo claro de los elementos de esta categoría son los modelos de información.
Conocimiento:es todo mecanismo que permita procesar la información, integrarla, agregarla, consolidarla y derivar nueva información a partir de ella. En general tienen forma de reglas lógicas que deben cumplirse. Otro elemento que encontramos en está categoría es la "meta-información", o sea elementos y mecanismos que permiten definir y procesar información sobre la información, como pueden ser definiciones formales de información y clasificaciones, por ejemplo las ontologías y arquetipos.

Relación entre datos, información y conocimiento (fuente: Curso 10x10, Unidad 3, HIBA [1])

Dimensión del sistema:

Arquitectura: en esta categoría entran los estándares que definen los componentes de un sistema de información computarizado, cuáles son sus dependencias y cómo se relacionan y comunican.
Funcionalidad: en esta categoría se agrupan los estándares que especifican requerimientos sobre las funcionalidades del sistema.
Persistencia: aquí se agrupan todos los estándares que especifiquen mecanismos y elementos relacionados con cómo es persistida le información en los sistemas de información.
Reglas de negocio: esta categoría agrupa estándares que ayudan a definir reglas de negocio y los mecanismos para ejecutar esas reglas, y las condiciones y contexto en el que dichas reglas deben ser ejecutadas.
Procesos: esta categoría agrupa todo estándar que tenga que ver con la definición y formalización de los distintos procesos que se dan en la realidad y que repercuten en el sistema de información (generando, procesando y/o consumiendo información).
Servicios: aquí se agrupan todos los estándares que tengan que ver con la definición de servicios que un sistema de información puede prestar a otros sistemas. Implica obviamente que existirá una comunicación entre distintos sistemas, pero no especifica cómo se dará esta comunicación, se limita a especificar una interfaz que será consumida o utilizada por otro sistema.

Dimensión de la comunicación:

Protocolos: agrupa todo estándar que especifique algún protocolo de comunicación entre dos o más sistemas. Un protocolo involucra la definición de interfaces, mensajes, orden en que los mensajes se deben enviar y recibir, cómo debe reaccionar un sistema al recibir un mensaje (qué debe responder, qué acciones debe llevar a cabo), bajo qué condiciones deben darse las interacciones.
Mensajes: aquí se agrupa todo estándar que defina únicamente los mensajes que pueden ser intercambiados entre diversos sistemas. Se especifica la estructura interna de estos mensajes.
Interfaces: pueden depender de los protocolos usados para comunicarse. Los estándares en esta categoría permiten definir las interfaces mediante las cuales diversos sistemas se comunicarán. Las interfaces deben ser públicas (publicarse) para que otros sistemas que desean comunicarse puedan hacerlo. Agregar un nuevo sistema a la red de comunicación no debería afectar a las interfaces existentes (regla de bajo acoplamiento).
Seguridad: son estándares que permite definir mecanismos que permitan agregar seguridad sobre el acceso a la información en salud. Pueden ser tanto mecanismos sobre un sistema (como autenticación de usuarios y acceso por roles), hasta autenticación entre sistemas que se comunican (intercambio de certificados).
Contexto: en esta categoría entran los estándares que permiten definir el contexto de la información comunicada, por ejemplo, ¿dónde se generó la información?, ¿con qué propósito?, ¿quién la generó? ¿para quién se generó?, ¿cómo deberá o no ser usada esa información?, etc. Esto es sumamente necesario si queremos lograr interoperabilidad semántica.

Dimensión de la integración:

Sistemas: desde un punto de vista macro, éstos son átomos de generación y almacenamiento de información. Los estándares en esta categoría definen la responsabilidad de cada sub-sistema en un macro-sistema formado por múltiples sub-sistemas. Puede involucrar macro-sistemas formados por sistemas de información de distintos sectores de una misma organización, de distintas organizaciones, incluso de distintos países.
Redes: los estándares en esta categoría son los que definen los macro-sistemas que mencionamos antes, con todo lo que estos involucran: integración, servicios, protocolos, mensajes, etc. Estar redes pueden ser creadas mediante algún tipo de afinidad, como por ejemplo compartir el mismo modelo de información clínica y el mismo modelo de conocimiento clínico. Esto permitirá la creación de servicios de mayor nivel, incluso se podrán crear nuevos servicios, para los que ni los sistemas ni las redes fueron diseñados, sin necesidad de modificar los sistemas.
Infraestructura de información: es la categoría de más alto nivel. Implica la interconexión de diversas redes de sistemas (si, una redes de redes, ¿suena conocido?), sobre la cual puedan crearse servicios de uso público, que serán soportados por las diversas redes y sistemas de información. Para tener una idea de lo que se puede hacer con tecnologías y estándares que hoy existen: con un clic, en tiempo real, saber cuantos pacientes hay hoy en el sistema de salud nacional, o por ejemplo, se podrá implementar que una persona reciba un SMS cuando se le esté por vencer alguna vacuna o el carnet de salud, e incluso indicarle el centro de vacunación más cercano a su posición actual, o el centro de certificación para renovar el carnet de salud. Diría que en esta categoría entran todos los estándares existentes, ya que no existe un estándar específico enfocado en esta categoría, pero todos los estándares de una u otra forma, permitirán que estas ideas (no tan locas) puedan ser implementadas en el corto plazo, para que los pacientes se vean realmente beneficiados (es el objetivo de todo lo que hacemos, ya que los pacientes somos nosotros, nuestras familias y amigos).

Volviendo al inicio, antes de pensar en elegir un estándar u otro, primero es necesario saber qué se desea hacer y para qué se quiere aplicar, luego buscar los estándares que entran en esa categoría de aplicación, luego elegir el que más se adapte a las necesidades, basándose en algún criterio como recursos disponibles, conocimiento del estándar, experiencia, o simplemente elegir uno al azar (siempre es lo menos recomendado, pero a veces no hay otra opción). Lo bueno es que ahora se puede contar con una organización que permita simplificar la comparación y selección de un estándar (esa es la intensión).

Ahora la discusión:

¿Cuáles otras dimensiones piensas que serían interesantes considerar?
¿Cuáles otras categorías agregarías dentro de cada dimensión?
En general, esta taxonomía ¿te parece lo suficientemente clara, correcta, completa?

¡Todos los comentarios son bienvenidos!

[1] Curso 10x10, HIBA
http://campus.hospitalitaliano.org.ar/course/explicativa.php?curso=245

Espacio para compartir, discutir y aprender

2010-11-02T17:51:00.001-02:00

OpenEHR-ES intenta ser la génesis de un grupo de discusión en español (el primero en este idioma), en donde se planteen temas relacionados con OpenEHR y su enfoque para la creación de sistemas de información en salud.

No obstante, también es un espacio para charlar de otros estándares como HL7, CDA, ISO/CEN 13606, DICOM, terminologías y clasificaciones internacionales, etc, etc, etc. Esto es porque quienes creamos sistemas de información en salud, necesitamos distintos estándares para resolver distintos aspectos de nuestros sistemas.

Para ser parte del grupo, lo único que debes hacer es suscribirte aquí: http://groups.google.com/group/openehr-es

No es necesario que seas un experto, ni tampoco es excluyente para ningún rol o país. El grupo está formado por informáticos, médicos, veterinarios, y gente curiosa. También tenemos gente de Argentina, Chile, Colombia, Brazil, USA, España, Uruguay y más.

El primer objetivo del grupo es conocernos, saber quienes están interesados en trabajar con OpenEHR o ya están trabajando, intercambiar opiniones y experiencias, y ser un nexo entre profesionales para la colaboración en proyectos. En el futuro el grupo buscará agregar un área de capacitación, con cursos y materiales, de forma de simplificar la adopción y difusión de la norma, ya que muchos no tienen el tiempo suficiente de estudiar las especificaciones (¡y vaya que son largas!). También buscaremos eventos para poder compartir las experiencias, objetivos y para fortalecer la comunidad OpenEHR de habla hispana.

¡Son todos bienvenid@s!

OpenEHR el estándar abierto para historias clinicas electronicas

2010-10-23T16:14:00.001-02:00

Este es el primer artículo de la serie sobre estándares en Informática Médica.

El objetivo de esta serie es presentar distintos estándares desde un punto de vista práctico y muy crítico, ya que muchas veces nos llega mucho ruido de quienes promueven sus propios estándares, pero no contamos con una mirada independiente que nos ayude a entender si nos quieren "vender un buzón" o si realmente usando lo que nos dicen podemos solucionar los problemas que plantea la Informática Médica.

Un posible punto de introducción al tema: http://es.wikipedia.org/wiki/OpenEHR

OpenEHR en pocas palabras:

Estándar abierto que define un modelo de información y un modelo de conocimiento clínico.
Propone el enfoque de sistemas informáticos "orientados a la gestión del conocimiento clínico".
Objetivo: ayudar a crear sistemas "semánticamente abiertos", durables en el tiempo, y económicamente viables.

Explicando las "pocas palabras":

Estándar abierto: es generado, mantenido, probado y validado por una comunidad de usuarios dividida en dos grandes grupos: los expertos clínicos y los expertos en TICs (Tecnologías de la Información y las Comunicaciones). Para formar parte de la comunidad no es necesario pagar, toda la información es libre y para participar en las discusiones solo es necesario registrarse en su lista de correo.

Define un modelo de información clínica:

El modelo de información de OpenEHR es una especificación UML (orientada a objetos), y es la parte del estándar que debe implementarse dentro del software. La principal característica es que es un modelo genérico, es decir, que permite representar toda la información que se genera en la asistencia médica, pero no especifica la semántica de cada concepto clínico particular, solo contiene conceptos clínicos generales, como son: observaciones, evaluaciones, instrucciones y acciones. Luego profundizaremos más en los detalles del modelo de información clínica.

Define un modelo de conocimiento clínico:

El modelo de conocimiento de OpenEHR es básicamente una especificación de unos artefactos llamados "arquetipos". Los arquetipos son simples archivos de texto plano, que cumplen una sintaxis llamada ADL (Archetype Definition Language). El objetivo de los arquetipos es representar conceptos clínicos particulares y residen fuera del software (al contrario del modelo de información que representa conceptos clínicos generales y reside dentro del software). Los conceptos clínicos particulares son representados como un conjunto de restricciones sobre el modelo de información genérico. Luego veremos algún ejemplo.

Orientación a la gestión del conocimiento clínico:

La idea de que los conceptos clínicos particulares residan fuera de la aplicación de software, es en si un cambio de paradigma. Hoy en día, los Sistemas de Información en Salud son fabricados de forma que el conocimiento clínico está definido de forma "dura" en el software. Esto quiere decir, que si cambia el conocimiento clínico que maneja el software, se debe cambiar la aplicación de software (en el sentido que necesita adaptarse a los cambios en el conocimiento clínico). Esto hace que cada cambio sea muy costoso.

Por el contrario, si el conocimiento clínico es definido y gestionado por fuera del software, como la aplicación de software es genérica, los cambios en el conocimiento no repercuten en el software, ahorrando costos innecesarios. Este paradigma de "gestión del conocimiento clínico" no solo tiene ventajas en ahorro de costos, si no que puede tener implicancias más profundas en los proyectos de TICs en salud.

Hoy, para crear un sistema de software en salud, un grupo de analistas informáticos tiene una o varias reuniones con un grupo de médicos que les expresan sus necesidades (requerimientos sobre el software). La experiencia indica que este proceso es en general infructuoso. Por ejemplo, una historia que se repite es: cuando el grupo de analistas está convencido de que ha extraído todos los requerimientos, se comienzan a construir prototipos. Una vez finalizados, éstos les son mostrados a los médicos, los cuales comentan cosas como "esto no es lo que pedimos", "esto no me sirve", "yo no te dije esto", o directamente "esto es una porquería". Entonces se tira todo y se vuelve a empezar. Esto se repite unas cuantas veces, hasta que se logra lo que los médicos quieren. La regla del dedo indica: los informáticos no entienden a los médicos y viceversa. Uno de los problemas surge de que en este proceso, los informáticos deben gestionar el conocimiento clínico extraído de los médicos, tarea para lo que no estamos preparados (no somos expertos en el dominio clínico, los médicos si).

La pregunta clave: ¿porqué no hacer algo que permita que los médicos puedan gestionar el conocimiento clínico directamente sin tener que pasar por los analistas? ¿no nos ahorraríamos muchos dolores de cabeza, tiempo y dinero?. Bueno, esta es la clave de la "orientación a la gestión del conocimiento. Dado que el conocimiento clínico es definido fuera del software, si pudiéramos enseñarles a los médicos a usar una herramienta para generar arquetipos, los médicos podrían definir el contenido de la Historia Clínica Electrónica sin siquiera tener que hablar con un informático. Mientras, con el tiempo ganado, los informáticos podemos crear mejores sistemas de software, más genéricos y más inteligentes, que permitan cargar los arquetipos que definen los médicos y generar el sistema de información en base a ellos.

Esto tiene varias implicancias. Primero, es el médico quien decide que poner o no poner en un arquetipo, por transitiva, está decidiendo que va y que no va en la historia clínica. Por lo tanto, se evitan las quejas de que el sistema no registra lo que el médico necesita, porque está definiendo justamente lo que necesita. Segundo, se le da a los médicos un rol más preponderante en los desarrollos de TICs en salud. Con el enfoque actual, los informáticos hacemos "uso" de los médicos solo cuando los necesitamos, luego ellos pierden visibilidad del proyecto. Tercero, debido a la satisfacción del médico por haber sido él quien creó la historia clínica y por haber participado activamente en el desarrollo, se facilita el cambio cultural que involucra la inserción de las TICs en salud, evitando rechazos y ganando adeptos que pueden contagiar a los demás en usar el sistema. De esta forma deja de ser un proyecto informático y pasa a ser un proyecto médico.

Sistemas semánticamente abiertos

Los arquetipos son definiciones semánticas de conceptos clínicos particulares. Esto quiere decir que cada arquetipo expresa un concepto clínico, junto con su propósito, para qué se debería usar, para que no se debería usar, cual es su estructura interna, qué vínculos con codificaciones y vocabularios controlados tiene, entre otros elementos.

Los arquetipos pueden traducirse, esto quiere decir que puedo definir un arquetipo junto a sus contexto expresado en múltiples idiomas. Un arquetipo puede compartirse, de modo que si defino un arquetipo para el concepto "presión arterial" en español, puedo traducirlo a inglés y enviárselo a una institución sanitaria en Inglaterra, y ellos podrán entender lo que representa ese arquetipo. Incluso, sus sistemas informáticos podrían hacer uso de ese arquetipo, de modo que si les envío información referente a la presión arterial de un paciente desde Uruguay, ellos la podrían validar e interpretar utilizando el arquetipo.

Sistemas durables en el tiempo:

Con el enfoque de "gestión del conocimiento clínico", el conocimiento clínico reside por fuera de la aplicación de software, por lo tanto, a medida que avanza la medicina, el conocimiento puede gestionarse y actualizarse, sin necesidad de modificar la aplicación de software. Por otro lado, las tecnologías cambian, y la aplicación de software podría modificarse sin necesidad de modificar el conocimiento clínico. Esto quiere decir que los procesos de gestión del conocimiento y de gestión del software son independientes. Es más, son ejecutados por roles distintos: expertos en el dominio clínico (médicos, enfermeras, técnicos) y expertos en TICs (ingenieros, analistas, programadores), respectivamente. De esta forma, aunque la tecnología cambie, el conocimiento y la información deben sobrevivir el paso del tiempo, lo importante es mantener estos durante toda la vida del paciente, y aún más tiempo (podríamos hablar de que la información clínica debe durar unos 120 años).

Sistemas económicamente viables:

Debido a que ya no es necesario que los analistas extraigan requerimientos y se creen prototipos que los médicos van a rechazar, simplificamos el proceso de desarrollo, y estamos ahorrando en tiempo y dinero. Gracias al enfoque de "orientación a la gestión del conocimiento", el software no necesita modificarse con cada cambio en el conocimiento clínico (que ahora es gestionado de forma independiente por los expertos en el dominio clínico), y considerando que el mayor costo de los proyectos está en el mantenimiento y adaptación del software, este costo se reduce enormemente.

Dentro del modelo de información genérico:

El modelo de información de OpenEHR es básicamente un árbol, donde la raíz de éste es la estructura de más alto nivel, llamada "composición". La "composición" puede ser vista como un formulario de registro en papel, el cual está formado por partes más pequeñas que se "componen" para crear la hoja de registro.

Esas partes más pequeñas son llamadas "entradas" de la historia clínica. Estas entradas no son campos donde se ingresan datos, si no que son grandes conjuntos de campos donde se ingresan datos, que a su vez tienen alguna relación entre ellos, esa relación está contenido en cada "entrada".

Para no hacer una descripción de todo el modelo de información, vamos a concentrarnos en el modelo de entradas, que me parece fundamental para entender tanto el modelo de información como el modelo de conocimiento. En la figura 1 podemos ver el proceso de resolución de problemas clínicos. En éste vemos que cuando un médico recibe a un paciente, lo primero que hace es observarlo, medirlo, preguntarle. La información que surge de esas observaciones, se debe registrar. Luego el médico realiza evaluaciones, plantea objetivos y planes de cuidado, esto en base a su conocimiento y a fuentes de conocimiento externas. Esta información de las evaluaciones también debe ser registrada. El paso siguiente es dar instrucciones, indicaciones, órdenes. Desde solicitar que se haga un estudio de laboratorio, hasta darle indicaciones al paciente en el alta. Por último, cerramos el ciclo con la ejecución de las instrucciones, lo que vemos aquí como "acciones". Si el paciente no es dado de alta, el ciclo vuelve a ejecutarse. Todo debe quedar registrado.

Figura 1: proceso de resolución de problemas clínicos.

Indirectamente, lo que vemos es que toda la información clínica generada en la atención del paciente puede catalogarse en grandes clases, las cuales son: observaciones, evaluaciones, instrucciones y acciones. En la figura 2 vemos el modelo UML de estas clases. Lo central del diagrama, aunque parezca complejo, es ver que todas las entradas tienen una superclase abstracta "Entry". Luego tenemos dos subclases "Admin Entry" y "Care Entry", entradas administrativas y entradas de cuidado, respectivamente.Por último, dentro de las entradas de cuidado tenemos cuatro subclases "Observation", "Evaluation", "Instruction" y "Action". Lo que estamos viendo aquí es el corazón de la Historia Clínica Electrónica.

Figura 2: modelo UML de entradas OpenEHR

Algunos detalles del modelo de entradas. Podemos ver que una "instrucción" tiene varias "actividades" relacionadas. Esto modela que las tareas a realizar pueden ser complejas e involucrar varias actividades para ser realizadas, las actividades pueden verse como una lista de pasos para realizar la tarea. Por lo tanto, con una "instrucción" se podría modelar por ejemplo una guía clínica o un protocolo clínico.
A su vez, vemos que una "acción" puede tener relacionada los detalles de una instrucción, esto es para indicar que la acción fue realizada porque tal "instrucción" y tal "actividad" así lo indicaban. Por último, la "acción" también tiene asociada una "transición en una máquina de estados", esto sirve por ejemplo, en acciones que no son puntuales, si no que se ejecutan durante un período de tiempo (como dar una medicación durante 2 horas), para expresar que se comenzó a ejecutar la acción, se que finalizó, que se canceló, que se suspendió, etc. Todos esos son estados y están asociados a una máquina de estados con transiciones definidas, por ejemplo: no se puede cancelar la administración de un medicamento si todavía no se ha empezado a administrar.

Previamente comentábamos de que el modelo de información era genérico. ¿Pero donde está lo genérico? Imaginemos que necesitamos representar el concepto clínico "toma de la presión arterial". En el modelo de información no hay ninguna clase particular que represente ese concepto, por el contrario, existe una clase que agrupa todos los conceptos clínicos que sirven para medir cosas sobre el paciente, la "observación". Bien, entonces el concepto "toma de presión arterial" es una "observación", pero necesitamos definir particularidades para esta "observación" específica, eso lo hacemos con los arquetipos.

Ejemplos de conceptos clínicos particulares y con que clases del modelo de información se corresponden.

Toma de presión arterial: observación
Frecuencia cardíaca: observación
Frecuencia respiratoria: observación
Resultado de un estudio de laboratorio: observación
Evaluación de vía aérea: evaluación
Clasificación de gravedad del paciente (triage): evaluación
Evaluación de disfunción neurológica: evaluación
Diagnósticos: evaluación
Orden de estudios de laboratorio: instrucción
Indicaciones para el paciente: instrucción
Colocación de vía venosa central: acción
Administración de sustancias: acción

Uso concreto de OpenEHR: Open EHR-Gen Framework

En un año de trabajo, junto a mi colega Leandro Carrasco, hemos desarrollado una herramienta que implementa el modelo de información de OpenEHR. Esta herramienta toma arquetipos, o sea conceptos clínicos particulares, y genera automáticamente las pantallas de registro para que los médicos ingresen datos. También genera automáticamente las estructuras de información que se deben almacenar en la base de datos, a partir de los datos ingresados por los médicos. Además, valida automáticamente los datos ingresados por los médicos, contra las restricciones definidas en los arquetipos.

En definitiva, es un sistema de información para la salud, que se genera automáticamente a partir de lo que los médicos definan en los arquetipos. Este tipo de herramientas nos permite pensar en otras formas de construir los sistemas de información para el ámbito de la salud, en formas que se adapten a lo que el médico realmente necesita.

Además de que estamos hablando de sistemas dinámicos, que no necesitan cambios antes nuevas necesidades de registro por parte de los médicos. Son ellos quienes definen le registro a partir de los arquetipos. Estamos hablando de enormes ahorros potenciales tanto en tiempo como en dinero.

Lo malo en OpenEHR:

Esta es la sección donde me pongo duro con la crítica. Hasta ahora no he mencionado nada "malo" de este estándar, y hasta parece una excelente solución para muchos de los problemas que nos enfrentamos día a día quienes construimos sistemas de información en salud. La verdad es que OpenEHR agrega un montón de conceptos que realmente nos ayudan, pero nada es gratis.

El proceso

Vimos que el proceso de desarrollo puede simplificarse, en la medida de que los médicos, enfermeras y técnicos (expertos en el dominio clínico) definan sus necesidades mediante arquetipos. Para esto es necesario una capacitación, la cual no todos estarán de acuerdo en hacer. Muchos querrán seguir expresándole sus necesidades a los analistas informáticos. Esto es un problema, no directamente de OpenEHR, pero si de su aplicación práctica.

Por otro lado, se necesita un proceso definido y controlado en cuanto a la creación corrección y actualización de los arquetipos. Si los médicos empiezan a definir sus arquetipos sin control, muchas veces se llegarán a inconsistencias. Por ejemplo, es necesario un comité médico que evalúe la calidad del arquetipo y que proponga mejoras, antes de integrarlo al registro médico. Una cosa que puede pasar es que un médico defina en parte de un arquetipo, un concepto clínico que ya está modelado con un arquetipo, en lugar de reutilizar el arquetipo existente.

Limitaciones de los arquetipos

Los arquetipos son buenos para expresar estructuras de información y restricciones puntuales sobre esa información, pero no es suficiente para expresar restricciones complejas como: si es un hombre entonces no puede estar embarazado. Las restricciones complejas pueden referenciar a varios conceptos clínicos (arquetipo) y no pueden ser definidas dentro de un arquetipo, por lo que se debe buscar una estructura de mayor nivel donde definirlas.

Esto en sí no es un problema de los arquetipos, si no que los arquetipos no fueron diseñados para expresar esas restricciones complejas, que en cambio, si necesitamos en la práctica. Lo bueno es que teniendo los conceptos clínicos formalizados mediante arquetipos, la definición de esas restricciones complejas puede hacerse de forma sencilla, referenciando a esos arquetipos y sus nodos internos.

Actualización de las herramientas

Si bien la comunidad de OpenEHR provee un conjunto de herramientas libres y gratuitas, estas presentan algunos problemas que no parece que puedan ser solucionados a corto plazo. Obviamente, detrás de las herramientas hay personas, que muchas veces utilizan su tiempo libre en corregir y actualizar las mismas, y no reciben remuneración por hacerlo. Por un lado, es difícil exigirle algo a alguien en este esquema. Por otro lado, que estos proyectos queden estáticos, dificulta la introducción de nuevos adeptos al estándar, por que los desanima al momento en que prueban una herramienta y encuentran un problema.

La clave es que al ser herramientas de código abierto, la comunidad debería participar en mejorar y actualizar el código, tal como pasa con otros proyectos de código abierto. Pero esto no está pasando con las herramientas de la comunidad de OpenEHR. Muchos esperamos que otro solucione los problemas y nos sentamos a ver que pasa. Este es un problema más de la comunidad que del estándar en sí.

Estándar no oficial (de facto)

OpenEHR no es respaldado por una organización como ISO o ANSI, organizaciones creadoras de estándares respetadas en el mundo, por lo tanto OpenEHR es visto por los burócratas como un estándar no formal, o simplemente como que no es un estándar. DICOM también es un estándar abierto, pero es soportado por toda la industria en el área de diagnóstico por imágenes, lo cual lo hace el "estándar de facto" en el área de la imagenología digital. Tal vez, con mayor soporte de la industria, OpenEHR pueda ser el "estándar de facto" para crear sistemas de información en salud.

Conclusión

OpenEHR es un muy buen estándar y propone soluciones a problemas reales. Su aplicación puede tener serias dificultades, pero con un retorno de inversión potencial enorme. Requiere si un cambio cultural, tanto en los médicos como en los informáticos, ya que requiere cambiar (mejorar) el proceso de creación de los sistemas de información en salud. Y muchos de los problemas que hoy tiene la difusión y adopción del estándar, son debido a una comunidad que pide más de lo que da, y como en el mundo nada es gratis, es bueno que si tomamos algo del estándar, aportemos algo a la comunidad: creando una herramienta, corrigiendo las que ya existen, difundiendo el estándar entre otros, haciendo cursos, exponiendo en congresos, creando sistemas basados en el estándar, publicando artículos en blogs, etc.

Para ternimar, los invito a participar en el grupo de discusión en español sobre OpenEHR: http://groups.google.com.uy/group/openehr-es

Serie de articulos sobre estandares

2010-10-11T12:40:00.000-02:00

En este momento estoy armando una serie de artículos enfocados al análisis crítico y las posibles aplicaciones de los distintos estándares existentes para la creación de sistemas de información en salud.

La idea es que sean resúmenes en lenguaje de alto nivel (tratando de dejar lo técnico de lado) y que toquen los principales objetivos, usos y problemas que tienen los estándares como:

OpenEHR (modelos, gestión del conocimiento clínico)
HL7 v3 (mensajería, modelos)
CDA (documentos clínicos CDA)
ISO 13606 (documentos clínicos)
CCR/CCD (continuidad del cuidado)
IHE (perfiles de uso de HL7 y DICOM)
DICOM (imagenología)
CIE, CIAP, LOINC, ... (clasificaciones)

Lo que buscará esta serie es saber:

primero de qué estamos hablando realmente cuando decimos "OpenEHR" o "HL7"
qué estándar sirve para resolver qué problema
cómo aplicar varios estándares en un mismo sistema de información
fomentar la discusión y difusión de estos y otros estándares

Esto servirá de introducción para luego si tocar temas más técnicos.

Aumento en la calidad de datos patronimicos 2: heuristicas

2010-09-12T13:13:00.001-03:00

Introducción

En un artículo previo, he definido un algoritmo para detectar el Índice de Coincidencia (IC) entre dos identidades de personas. Estas identidades están formadas por un conjunto de datos arbitrario, como nombres, apellidos, sexo fecha de nacimiento, etc. En el artículo previo, no se especificó cómo eran seleccionadas las idendidades a ser comparadas. En este artículo la idea es definir los conceptos que permitan entender las distintas formas de pre-selección de identidades de forma que las comparaciones no tarden años en ejecutarse, y a la vez permita detectar la mayor cantidad de registros duplicados en una base de datos.

Objetivo

El objetivo final del cálculo del IC entre dos identidades es poder encontrar posibles duplicados en los registros de las personas (sobre todo entre los pacientes). Una vez que se encuentran dos o más registros duplicados, se procede a la unión de esos registros. Esto es esencial para garantizar que los procesos de identificación de personas (en el ámbito de la salud) funcionen correctamente, y para garantizar que el registro clínico se realiza para la persona correcta, y que todos los registros clínicos de esa persona están asignados a una única identidad (si la persona tiene más de una identidad, por tener registros de identidades duplicadas, su información sanitaria estará fragmentada, o sea siempre será incompleta).

Entonces, es necesario ejecutar el algoritmo que detecta coincidencias tomando y comparando de a 2 los registros de las personas en la base de datos de pacientes de una o múltiples instituciones sanitarias. El problema es que si en una base de datos con 1000 pacientes se hacen comparaciones de a 2, se terminan haciendo 1.000.000 (1M) comparaciones. Tal vez 1M comparaciones no sea un gran problema, pero ¿qué pasaría si la base de datos tuviera 1M registros de pacientes?, ¡las comparaciones se disparan a un millón de millones!. En este caso, si cada comparación tarda unos 3 segundos, el total de las comparaciones tardarían unos 95129 años aproximadamente.

El objetivo es claramente bajar ese tiempo de ejecución, pero a la vez garantizar que se encontrarán todos los duplicados en las identidades persentes en la base de datos.

Para lograr esto es necesario disminuir la cantidad de registros a comparar de 2 en 2, por lo que previamente a ejecutar la comparación entre 2 identidades, ejecutaremos una heurística que permita preseleccionar todas las identidades que deben compararse, siendo esta cantidad mucho menor a la cantidad de identidades de personas guardadas en la base de datos.

Debe quedar claro que el único método que garantiza que se encuentran todos los duplicados en una base de datos es comparar 2 a 2 todos los registros de la base, cosa que, como ya mencionamos, es impracticable en bases de datos con muchos registros.

La heurística con la que se consigan encontrar todos los duplicados, será la heurística óptima, pero ninguna heurística puede garantizar esto para cualquier base de datos con identidades de personas. O sea, que la los resultados de aplicar la heurística para preselección de registros, depende de la base de datos. Profundizaré sobre este concepto más adelante.

Metodología

El objetivo de las heurísticas es obtener conjuntos de registros de identidades que "se parecen en algo", pero sin necesidad de ejecutar el Algoritmo de Verificación de Identidades (AVI) para calcular el Índice de Coincidencia entre las identidades. A estos conjuntos de identidades "parecidas" les llamaremos "Clases de Preselección" o solo "CP". De este modo, las compararciones de a 2 identidades usando el AVI, se hacen solo sobre las identidades de cada CP, no sobre todos los registros de identidades.

A continuación voy a mostrar el camino lógico que seguí para ir de una comparación de 2 en 2 sobre todos los registros de una base, hasta la solución final encontrando algunas heurísticas por "sentido común", que luego fueron probadas y funcionaron correctamente.

El peor caso empieza teniendo que comparar todas las identidades de la base, de 2 en 2. Esto se puede representar en un cuadro de doble entrada, donde cada par de entradas señalan una comparación a realizar. En la fig. 1 se puede apreciar este cuadro, y como se realizan todas las comparaciones de 2 en 2, aparece todo pintado de verde (este color indica las comparaciones a realizar).

Fig. 1: cuadro de comparaciones inicial

La primer optimización es que si se compara la identidad A con la identidad B, no es necesario hacer la comparación de B con A, por lo que se reducen las comparaciones a algo menos que la mitad, ya que también se evitan las comparaciones de A con A, B con B, etc. En la fig. 2, las comparaciones se hacen solo sobre la mitad de los registros.

Fig. 2: se comparan solo la mitad de las identidades

Esta primer optimización reduce la cantidad total de comparaciones pero no cambia el orden o la magnitud de comparaciones a realizar, es decir, si antes había que hacer millones de comparaciones, ahora hay que hacer millones/2. Por lo que si antes tardábamos más de 95000 años en hacer las comparaciones de 1M registros, ahora tardaremos más de 47000 años, cosa que sigue siendo impracticable.

Bien, ahora ¿qué pasaría si tuviéramos algo que nos dijera que comparaciones hacer antes de hacerlas?, podríamos bajar el número total de comparaciones y llevar el tiempo total de ejecución a algo razonable. Hacer esto implica que debemos agrupar identidades "parecidas" pero sin calcular el IC, ya que eso nos llevaría de nuevo al problema inicial. La idea es que el algoritmo que agrupe entidades parecidas en Clases de Preselección, también sea un algoritmo rápido. O sea que el tiempo total de hacer la preselección, más el tiempo total de calcular el IC entre 2 identidades, para todas las identidades de cada CP, sea muchísimo menor al tiempo total de ejecución de la primer optimización que se muestra en la fig. 2.

La idea es bien fácil, primero hay que definir el criterio por el cual se agrupan las identidades en las Clases de Preselección. Los criterios que he utilizado en mis pruebas son:

Agrupar por primer letra del primer nombre
Agrupar por primer letra del primer apellido
Agrupar por fecha de nacimiento:

Total: día, mes y año (no sirve si las fechas tienen errores en alguno de sus 3 campos)
Parcial: solo día y mes, o solo mes y año (es más fuerte ante errores en algún campo de la fecha)

Para el criterio 1, lo que se hace es ordenar todas las identidades por primer nombre y tomar de a X identidades con X arbitrario, tomando como CPs por los registros 1..X, X+1..2X, etc., de esta forma cada CP tendrá solo X registros, siendo X mucho menor a N, con N la cantidad total de registros. Con N=1M y X=200, las comparaciones totales serían 5000 x 200^2 / 2 = 100M (en lugar de 1M de millones!). Igualmente este ejemplo, con cada comparación hecha en 3 segundos, tardaría unos 9 años. Si varía X, se podrá variar la cantidad total de comparaciones necesarias. Obviamente el tiempo de comparación de 2 registros dependerá de la velocidad del hardware y de lo complicado que sea el algoritmo de comparación entre 2 identidades.

En la fig. 3 se visualizan las comparaciones a realizar usando Clases de Preselección. Las flechas indican que hubo un ordenamiento de los registros según algún criterio. Se puede ver claramente que la cantidad total de comparaciones disminuye de forma considerable.

Fig. 3: primer aproximación para encontrar Clases de Preselección

De forma análoga se pueden aplicar otros criterios y obtener CPs alternativas. Un potencial problema es que los registros tengan errores y esos errores repercutan en el criterio que se use para crear las CPs. Por ejemplo, si se usa el criterio de tomar de a X identidades, tal que estén ordenadas por la primer letra del primer nombre, si existen muchos primeros nombres con error de registro en la primer letra, un potencial duplicado puede no ser detectado, ya que las identidades con error en la primer letra del primer nombre van a parar a otra CP. Con esto fundamentamos una afirmación hecha previamente: la heurística o criterio que se utilice para crear las CPs depende de cada base de datos, porque depende de los errores que haya en el registro.

Para conseguir una heurística fuerte ante los errores más comunes en nuestros registros, se pueden optar por dos estrategias:

Hacer un estudio estadístico de los errores más comunes en el registro
Utilizar más de una heurística para calcular los ICs entre las identidades

En mi caso opté por la segunda estrategia. Lo que hice fue calcular el IC para los registros de cada CP creada a partir del criterio de "primer letra del primer nombre", pero luego calculé de nuevo el IC para los CPs creados a partir del criterio "primer letra del primer apellido", de esa forma las comparaciones que se me escaparon en la primer vuelta, por tener errores en el primer nombre, en la segunda vuelta, utilizando el criterio por primer apellido, logro que se comparen. Obviamente, un registro puede tener errores en el primer nombre y en el primer apellido, pero la probabilidad de que esto suceda es menor de que un registro tenga error en el primer nombre o en el primer apellido.

Existe una optimización a este tercer paso, debido a un problema que presenta en los límites de las CPs. Ya que si se ordenan los registros y se toman 2 CPs contiguas, es problable que los últimos registros de la primer CP se parezcan a los primeros registros de la segunda CP, y al no considerar esto, estamos perdiendo duplicados potenciales. Para cubrir esto, lo que se hace es solapar un poco las CPs, así la primer CP calcula el IC entre sus identidades, pero también incluye a las primeras identidades de la segunda CP. En la fig. 4 se muestran las CPs solapadas para evitar que se escapen duplicados en los límites de las CPs.

Fig. 4: Clases de Preselección solapadas para incluir comparaciones de casos límite

Otras heurísticas pueden crearse en base a los datos disponibles, y usarse de forma coplementaria para no dejar registros parecidos afuera de las comparaciones.

Conclusiones

Es necesario crear alguna heurística que permita preseleccionar los registros que luego se van a comparar de 2 en 2, para así bajar los tiempos totales de ejecución.

Vimos que el éxito las heurísticas depende de los errores que se tengan en los registros de datos personales, por este motivo, antes de aplicar una heurística cualquiera para encontrar las CPs, es útil estudiar la base de datos para determinar cuáles son los errores más frecuentes y en cuáles datos. De este modo, podemos encontrar heurísticas que sean fuertes ante esos errores, permitiendo encontrar la mayor cantidad de duplicados posible.

Acompañando a las heurísticas se pueden usar otros métodos para acelerar las comparaciones entre las identidades de cada Clase de Preselección. Por ejemplo, el uso de programación paralela, donde distintos CPs puedan ser procesados en simultáneo, permite acelerar un poco las comparaciones totales, aunque no disminuye el orden de las comparaciones. Por ejemplo, si cada CP tiene 250 identidades, y cada comparación tarda 3 seg., las comparaciones para cada CP serán unas 250*250/2 = 31250 y tardarán unas 26 horas. Si se tienen 4 procesadores en paralelo, el tiempo total de ejecución bajará a unas 6,5 horas.

Espero que se haya entendido la idea, si no, comentan abajo y lo explicamos mejor.

Congreso Argentino de Informática y Salud - CAIS2010

2010-08-19T15:50:00.000-03:00

En este momento me encuentro preparando algunos trabajos para presentar en el CAIS (http://www.39jaiio.org.ar/cais). Quedan gratamente invitados a las charlas:

Miércoles 1 de setiembre de mañana:
Presentación de mi proyecto de grado de la carrera de Ingeniería en Computación
Traumagen, historia clínica electrónica de trauma, con acceso a estudios imagenológicos digitales.
Temas principales: aplicación de estándares a una HCE, OpenEHR, DICOM, HL7 CDA, CIE 10.

Jueves 2 de setiembre depués del mediodía:
Tutorial sobre OpenEHR
Temas principales: objetivos del estándar, OpenEHR como arquitectura de sistemas de HCE, modelo dual: el conocimiento clínico por fuera de la aplicación de software, el modelo de información clínica y los arquetipos. Será teórico-práctico, viendo primero algunos conceptos y luego probando herramientas.

Saludos y espero poder verlos por el congreso.

Aumento de calidad de datos patronimicos

2010-03-26T22:36:00.004-03:00

En el 2009 estuve trabajando sobre un algoritmo para realizar búsquedas de pacientes en un base de datos. Si bien esto es una tarea más que resuelta en muchas instituciones, el objetivo del algoritmo era no solo obtener una lista de datos de personas que se correspondieran con un criterio dado, si no detectar en cuanto se corresponden, de forma de encontrar los registros que más se parezcan a lo que buscamos.

Si bien se logró un algoritmo junto al Subcomité Técnico de Identificación de Personas (STID) de SUEIIDISS (HL7 Uruguay), del que participé en el 2009, yo me concentré en otro problema, el de la calidad de los datos. Si bien podemos pensar en cómo resolver las búsquedas de la mejor forma, si la calidad de los datos en nuestra base de datos es pobre, el resultado de la búsqueda será de poca utilidad, y si se llevara la calidad a niveles óptimos, cualquier mecanismo simple de búsqueda nos ayudaría a encontrar lo que necesitamos, por eso el cambio de enfoque. Dicho sea de paso, aquí se puede obtener una copia del documento logrado en el STID.

El resultado de mi investigación fue un algoritmo que sirve para comparar dos identidades, formadas por los atributos: nombres, apellidos, fecha de nacimiento y sexo de una persona. Cualquier tipo de identificador de la persona no forma parte de su identidad, por eso no se consideran números de documentos nacionales ni otros tipos de identificadores en las identidades. El resultado del algoritmo es un número entre 0 y 1 donde 0 indica coincidencia nula y 1 coincidencia total. Un resultado de 0.85 indica que las identidades coinciden en un 85%.

Este algoritmo fue probado en bases de datos con miles de registros, y los resultados obtenidos son óptimos. Según estos experimentos, las identidades cuya coincidencia supera el 95% corresponden a la misma persona, y la diferencia se debe a que hay errores en los datos, por ejemplo un nombre mal escrito, que en base a mis experimentos, es uno de los casos más frecuentes en los de fuentes de error, por ejemplo una letra faltante o la transposición de letras son de los errores más comunes.

Detrás del algoritmo hay tres ideas muy intuitivas:

Distintos datos de la identidad de una persona pesan distinto en la identificación de la misma. Nuestra identidad es lo que nos diferencia de las demás personas, pero distintas partes de esta identidad puede diferenciarnos en mayor o menor medida. No es lo mismo diferenciarse por los nombres que por la fecha de nacimiento, seguramente hayan muchas más personas que nacieron el mismo día que uno, que personas que se llaman igual. Entonces cada atributo de la identidad tiene un peso asociado.
No solo pasa que cada atributo pesa distinto en la identificación de la persona, si no que este peso en realidad debería variar dependiendo del valor de los atributos. Por ejemplo, si un apellido es muy común, el peso debería ser menor, y si es un apellido poco usual, su peso debería ser mayor. El algoritmo que considera esta afirmación se llamará "Algoritmo de Verificación de Identidades Avanzado" o "AVI-a", y no será descrito en este artículo.
El algoritmo debe comportarse bien ante casos de errores en los datos, es decir que si se comparan dos identidades, y una tiene errores en los datos, el algoritmo debería igualmente detectar la similitud entre las identidades. Es por esto que condiciones de igualdad o igualdad parcial no son útiles para el cálculo del índice de coincidencia porque consideran a los datos como un todo o lo divide en grandes partes, es necesario llegar a un nivel de comparación con granularidad suficiente para que los errores no afecten tanto a las comparaciones.

Descripción del Algoritmo de Verificación de Identidades Básico (AVI-b):

Aquí voy a bajar a un nivel muy técnico, igualmente voy a ir explicando los detalles para que nadie pierda el hilo.

La identidad mínima de una persona, como mencioné antes, está formada por los atributos: nombres, apellidos, sexo y fecha de nacimiento. Vamos a tomar dos identidades id1 e id2 para compararlas según el AVI-b.

// Tipo que define la Identidad

Identidad {

String nom1

String nom2

String ap1

String ap2

CodigoSexo sexo

Fecha fecha_nac

}

// Tipo que define la el código para el sexo según la

// codificación utilizada en HL7 que se puede ver aquí:

//
http://web.his.uvic.ca/Research/HTG/vocabulary/Terminologies/HL7/Browse.php?Section=Browse&CodeSystem=2.16.840.1.113883.5.1

CodigoSexo {
  const String MASCULINO = "M"
  const String FEMENINO = "F"
  const String IDENFINIDO = "UN"

  // Debe ser alguna de las constantes definidas previamente
  String codigo
}

// Identidades a comparar, con respectivos sus valores para cada atributo

Identidad id1 = { nom11, nom12, ap11, ap12, sexo1, fecha_nac1 }

Identidad id2 = { nom21, nom22, ap21, ap22, sexo2, fecha_nac2 }

Como se mencionó, una de las ideas detrás del algoritmo es que, cada atributo de la identidad tiene un peso distinto en cuanto a la identificación de la persona. A continuación se especifica el peso de cada atributo en la identificación, donde la regla que deben cumplir estos valores es que deben sumar 1, porque si se tienen todos los atributos de la identidad, estos sirven para identificar a la persona en un 100%. Esto se traduce a que si el peso del primer nombre es 0.175, quiere decir que el primer nombre identifica a una persona en un 17,5%. Los valores aquí propuestos son valores encontrados empíricamente, para los cuales se obtuvo un buen funcionamiento del algoritmo (AVI-b).

// Los pesos deben sumar 1

pesos[nom1] = 0.175

pesos[nom2] = 0.175

pesos[ap1] = 0.175

pesos[ap2] = 0.175

pesos[sexo] = 0.1

pesos[fecha_nac] = 0.2

No está de más comentar que si bien los pesos planteados para el algoritmo básico (AVI-b) son constantes, por lo expresado en las ideas que están detrás del algoritmo, para el algoritmo avanzado (AVI-a), estos pesos serían funciones que dependen del valor de cada atributo.

A continuación se especifican los algoritmos de comparación de atributos simples que se utilizan para calcular el índice de coincidencia, que es el resultado del AVI-b. Se plantean dos algoritmos distintos para la comparación de nombres y apellidos, uno para el sexo y otro para la fecha de nacimiento. El primer algoritmo para comparar nombres hace la cuenta de cuantos caracteres coinciden en valor y posición y retorna esta cantidad dividida el largo de la palabra más larga, por lo que se obtiene un resultado en el rango 0..1, con valor 1 cuando los nombres y apellidos coinciden completamente. El segundo algoritmo de comparación de nombres está basado en la distancia de Levenshtein, que calcula cuantos caracteres se le deben agregar a una palabra para hacerla coincidir con otra, por lo tanto si el resultado de Levenshtein es 0 las palabras son la misma. La el índice basado en Levenshtein va a dar resultados más altos cuando haya errores de transposición u omisión de caracteres en alguno de los nombres que se están comparando, mientras que el primer algoritmo va a dar más bajo cuando uno de los nombres que se compara tiene alguna letra de menos. Luego voy a mostrar un ejemplo de esto, así que si no se entendió, luego lo retomaremos.

// Case Insensitive Char by Char:
// comparacion de palabras utilizando indice basado en
// comparacion caracter a caracter.

coin_ci_cbc( String a, String b)

{
   // Se pasa todo a minusculas para comparar
   a = pasar_a_minusculas( a )
   b = pasar_a_minusculas( b )

int max_len = maxLargo(a, b) // Largo del string mas largo

int min_len = minLargo(a, b) // Largo de string mas corto

int coincidencias = 0

for (i = 0..min_len)

{

if ( a[i] == b[i] ) coincidencias ++

}

return coincidencias / max_len

}

// Case Insensitive Levenshtein:
// comparacion de palabras utilizando indice basado en distancia de Levenshtein
// Mas info>
// - http://www.levenshtein.net/
// - http://es.wikipedia.org/wiki/Distancia_de_Levenshtein

coin_ci_levens( String a, String b)

{

// Se pasa todo a minusculas para comparar

a = pasar_a_minusculas( a )

b = pasar_a_minusculas( b )

   // Largo del string mas largo
   int max_len = maxLargo(a, b)

   // Calcula el indice basado en la distancia de levenshtein
   return 1 - ( levenshtein(a, b) / max_len )

}

coinSEXO(CodigoSexo s1, CodigoSexo s2)

{

if (s1.codigo == s2.codigo) return 1

return 0

}

coinFECHA (Fecha f1, Fecha f2)

{

if (f1 == f2) return 1

return 0

}

Por último, el cálculo del Índice de Coincidencia que será resultado del AVI-b, como vemos usamos los pesos y los algoritmos para calcular la comparación de atributos simples. En el ejemplo se utiliza coin_ci_cbc como comparador de nombres, éste se podría cambiar por coin_ci_levens.

IC( id1, id2 ) = pesos[nom1] * coin_ci_cbc(id1.nom1, id2.nom1) +

pesos[nom2] * coin_ci_cbc(id1.nom2, id2.nom2) +

pesos[ap1] * coin_ci_cbc(id1.ap1, id2.ap1) +

pesos[ap2] * coin_ci_cbc(id1.ap2, id2.ap2) +

pesos[sezo] * coinSEXO(id1.sexo, id2.sexo) +

pesos[fecha_nac] * coinFECHA(id1.fecha_nac, id2.fecha_nac)

En la siguiente tabla se puede ver el comportamiento del algoritmo básico (AVI-b) probando con algunos casos donde se toma una identidad y se varía algún dato para verificar cómo esta modificación afecta al Índice de Coincidencia (IC) que obtengo como resultado. Algunas aclaraciones para poder interpretar correctamente los resultados:

La identidad ID1 es siempre la misma, la que varía es ID2 en algunos valores.
Se hicieron 3 casos de comparación, probando con los dos algoritmos distintos para la comparación de nombres y apellidos.
Las filas de igual color corresponden a comparaciones de las mismas identidades pero utilizando algoritmos distintos para la comparación de nombres, es decir: ci_cbc o ci_levens.
En las filas 1 y 4, la variación de ID2 con respecto a ID1 es que en el segundo nombre se sacó una letra, la C.
En las filas 2 y 5, la variación de ID2 con respecto a ID1 es en la fecha de nacimiento.
En las filas 3 y 6, la variación de ID2 con respecto a ID1 es el primer nombre completo, manteniendo todos los otros datos. Este caso se podría dar en hermanos gemelos o mellizos, y el algoritmo debería ayudar a diferenciar entre ellos, si no es así, se debería utilizar la identidad extendida mediante los datos de "indicador de nacimiento múltiple" y "orden de nacimiento" que se describen en el documento del STID.

#	IC	Algor.	ID1	ID1 fecha	ID2	ID2 fecha
1	0.86	ci_cbc	Ana Jacqueline Gomez Rodriguez	1983-11-22 F	Ana Jaqueline Gomez Rodriguez	1983-11-22 F
2	0.8	ci_cbc	Ana Jacqueline Gomez Rodriguez	1983-11-22 F	Ana Jacqueline Gomez Rodriguez	1983-11-12 F
3	0.825	ci_cbc	Ana Jacqueline Gomez Rodriguez	1983-11-22 F	Carla Jacqueline Gomez Rodriguez	1983-11-22 F
4	0.9825	ci_levens	Ana Jacqueline Gomez Rodriguez	1983-11-22 F	Ana Jaqueline Gomez Rodriguez	1983-11-22 F
5	0.8	ci_levens	Ana Jacqueline Gomez Rodriguez	1983-11-22 F	Ana Jacqueline Gomez Rodriguez	1983-11-12 F
6	0.895	ci_levens	Ana Jacqueline Gomez Rodriguez	1983-11-22 F	Carla Jacqueline Gomez Rodriguez	1983-11-22 F

Tabla de resultados

Trabajo futuro:

Si bien se probó empíricamente el buen funcionamiento del Algoritmo de Verificación de Identidades Básico (AVI-b) creo que se podría ajustar aún más el resultado utilizando el algoritmo avanzado, donde los pesos se ajustan según los valores de los atributos de las identidades. Esto sería fácil de hacer si se tienen calculadas las frecuencias de nombres y apellidos de las identidades que se tienen en la base de datos donde están registradas las identidades a verificar, esto quiere decir, calcular cuántas personas tienen cada nombre (Pablo, Pedro, Juan, etc) y dividir cada una de esas cantidades entre el número total de identidades en la base. Luego esa frecuencia sería utilizada para aumentar el peso de un atributo (si es que hay poca frecuencia de ese nombre o apellido), o disminuir el peso de un atributo (si es que hay muchas personas que se llaman igual). Esta técnica ajustaría los valores resultantes de las comparaciones a un porcentaje más ajustado a la realidad. Como puede resultar obvio, los valores de frecuencias se deberían actualizar cada tanto, y con esto logramos un resultado que puede estar oculto a primera vista: el algoritmo se ajusta a las distintas frecuencias de nombres que se dan en distintos momentos. Es sabido que hay épocas donde un nombre se hace muy popular, y en algunos años el nombre más popular cambia, cambiando la frecuencia de personas que podemos encontrar con esos nombres en nuestras bases de datos. Con esto logramos un algoritmo que se adapta automáticamente (algoritmo adaptable) a cambios que se dan en la cultura de la sociedad. ¿Interesante no?

Conclusiones:

Cómo se puede apreciar en las filas 1 y 4 de la tabla de resultados, al cambiar una sola letra de un nombre o un apellido, el IC es mucho más alto usando el algoritmo ci_levens que el ci_cbc para comparar nombres, esto se debe a que el índice que se calcula en base a Levenshtein es más fuerte o se comporta mejor ante pequeños cambios. Este cambio se puede deber a un error humano en el registro, y es bueno tener un algoritmo que lo pueda detectar. Es decir que la detección de duplicados también ayuda a la detección de errores en el registro, y por lo tanto a mejorar la calidad del mismo, que es el objetivo planteado al inicio.

En las filas 2 y 5 no vemos cambio en el resultado del CI porque lo que es distinto entre las identidades es la fecha de nacimiento.

Por último, en las filas 3 y 6 vemos una pequeña diferencia en el CI, esto se debe a que el primer nombre es tan distinto entre ID1 e ID2 que tanto el índice basado en Levenshtein como el índice basado en la cuenta carácter a carácter detectan que ambos nombres son distintos, bajando el valor del CI en cantidades similares.

Espero que se hayan entendido las ideas detrás del algoritmo, cuáles eran los objetivos y que hayan quedado claras las conclusiones. Por cualquier consulta o comentario no duden en agregar un comentario.

Estandares que salvan vidas

2009-12-19T14:19:00.000-02:00

Ayer en el hipódromo de Maroñas se lanzó el número cero de la revista 1024, en la cual fue publicado un artículo de quien les escribe estas palabras. Gracias a Enrique González, editor de la revista, por confiar en mi para escribir este artículo y a todos los colegas que participaron y colaboraron en la creación de la misma.

Milveinticuatro, o simplemente 1024, es una revista de informática y tecnología para Uruguay, que viene a llenar un hueco en cuanto a la comunicación de los principales actores vinculados a las TICs el medio local.

Si bien "estándares que salvan vidas" es un título fuerte para un tema tan complicado y complejo como la informatización y estandarización aplicadas a la salud, creo que va a captar la atención del lector. Aquí les dejo el artículo publicado:

Hoy las instituciones de salud son sistemas caóticos, con pocos procesos definidos, con un modelo de registro sumamente heterogéneo y donde existe una enorme necesidad de información por parte de los médicos y los gestores de estas instituciones. Solo pensar en qué los médicos que nos atienden no disponen de toda nuestra información clínica en el momento de la atención, nos hace dudar de la calidad del cuidado que estamos recibiendo, no por los médicos, si no por la falta de información completa y precisa. La única solución a estos problemas es la informatización de la mano de la estandarización.

Los sistemas de información en el ámbito de la salud tienen varias diferencias con los sistemas en otros ámbitos. El dominio de la salud es complejo, cada acto médico es ejecutado por diversos roles, los procesos de atención se adaptan y varían caso a caso, y se manejan una inmensa cantidad de variables y registros.

La Historia Clínica Electrónica (HCE) de un paciente debe ser completa, por lo que debe tener la capacidad de registrar toda la información que surge de cada acto médico durante toda la vida del paciente. Para lograrlo se debe elegir cuidadosamente el modelo de información que se usará para almacenar toda la información clínica, se destacan tres modelos estándar: HL7 CDA [1], ISO/CEN 13606 [2] y OpenEHR [3]. En la figura 1 se muestra un esquema de la relaciones entre estándares, en el sitio de OpenEHR-ES [4] está el análisis de donde se derivan estas relaciones.

Figura 1. Relación entre estándares

HL7 es una organización que desarrolla estándares focalizados en el intercambio de información entre sistemas en salud. HL7 CDA (Clinical Document Architecture) es su estándar para modelar de documentos clínicos. CDA sirve tanto para la comunicación, como para el almacenamiento documental que compone la Historia Clínica Electrónica de un paciente.

ISO/CEN 13606 es un estándar nacido en la Comunidad Europea y hoy en día es estándar mundial ISO. Es también un estándar para modelar documentos clínicos. Existe una compatibilización con CDA haciéndolos intercambiables. El 13606 se basa en el modelo de OpenEHR, simplificándolo de forma sustancial para cumplir específicamente con el objetivo de comunicar de información clínica en formato electrónico.

El modelo de referencia de OpenEHR es uno de los modelos de información clínica más completos y genéricos que existe. Con similitudes al modelo de HL7 y al ISO 13606, OpenEHR define un modelo de información y una arquitectura que soporta la implementación de cualquier HCE, tal que sea completa, segura, única para cada paciente y longitudinal a la vida del paciente. Muchas de las características con las que cumple OpenEHR están definidas en la especificación técnica ISO/TS 18308. Cómo este estándar no es muy conocido en la región, estamos comenzando una comunidad en español sobre OpenEHR [4] para aportar a su difusión.

Las razones de por qué informatizar la Historia Clínica (HC) son varias, desde el logro de la eficacia en la gestión hasta salvar una vida, pasando por mejorar los procesos y la calidad de la atención médica, y por ende, la calidad de vida de la población. Las instituciones tienen serios problemas de gestión por no poder contar con la información completa y precisa de su principal actividad: la atención médica. Como ya sabemos, para gestionar hay que medir y para medir se necesitan datos.

Informatizando la HC y aplicando estándares resolvemos uno de los principales problemas: la fragmentación de la información clínica. Los sistemas informático-clínicos de hoy en día son verdaderas “islas” de información, donde se fragmenta la información del paciente atentando contra el decreto de 30/09/2003 de Historia Clínica Única para cada persona. La información clínica expresada en forma estándar permite que diversos servicios e instituciones de salud estén interconectados. Si en un accidente de tránsito se tiene una persona gravemente herida, el médico pide su HCE a la institución de la que es socio, accediendo a su información clínica, lo cual le permite dar una mejor atención. Por ejemplo, si el paciente accidentado es alérgico a un medicamento, el médico que lo atiende en la calle lo sabrá, evitándole administrar una droga que lo puede matar.

Algo no muy visto en sistemas de HCE en Uruguay es la geo-referenciación. Imaginemos que una institución tiene a todos sus pacientes ubicados geográficamente, con algunos datos clínicos asociados, como sus “problemas de salud” (diabetes, hipertensión, asma u obesidad), y a cada problema le asocia un color, el resultado es que se podrá ver un mapa con la distribución de problemas de salud de los pacientes de la institución, permitiendo que se tomen acciones de prevención a nivel poblacional, impactando directamente en la calidad de vida de las personas a largo plazo. Con algo tan simple como ver que el 30% de la población atendida es hipertensa, la institución podría lanzar una campaña de control de la presión, y a los pocos meses se puede ver si esa población de riesgo tiene su presión arterial dentro de los rangos normales, logrando prevenir futuros problemas cardíacos.

Con un sistema de este tipo, cuando ocurrió el problema de la plombemia en algunos barrios de Montevideo, se habría detectado de forma temprana las zonas de riesgo y tomado medidas en menor tiempo.

Actualmente en la Universidad de la República, en la carrera de Ingeniería en Computación, estamos trabajando en una tesis de grado: “Historia Clínica Electrónica de Trauma” [6].

Este trabajo lo estamos realizando junto al Dr. Fernando Machado y la encargada del centro de cómputos Lucía Grundel del Hospital Maciel, una de las principales puertas de emergencia con entrada de pacientes traumatizados del Uruguay. Adicionalmente se realizó un adelanto del proyecto final al que se lo denominó “MiniClin”[5].

MiniClin: la HCE minimal

Es un sistema de HCE completa, minimal y estándar. Es completa porque permite integrar todos los tipos de registros que forman la HCE. Minimal porque cuenta con las características mínimas de una HCE: poder registrar datos clínicos y guardarlos en un medio electrónico. Y es estándar porque para el repositorio de documentos clínicos se utiliza HL7 CDA. En octubre de 2009, en el Congreso de Informática Médica Normalizada realizado en Montevideo, se realizó la presentación del trabajo para el que se documentó MiniClin y su aplicación al mundo clínico. Este sistema de código abierto estará disponible en breve y de forma gratuita para todos los médicos de Uruguay.

HCE de Trauma

Es la implementación de la arquitectura propuesta por el estándar OpenEHR, en el cual, como salida hacia otros sistemas clínicos, se generan documentos clínicos CDA.

Junto al registro de información se implementa el proceso de atención del paciente traumatizado, así la aplicación sigue paso a paso las tareas que los médicos van realizando. La generación de CDA tiene dos objetivos, la comunicación de información clínica entre sistemas, y que los documentos clínicos puedan ser firmados electrónicamente, para darle a la HCE la validez legal que tiene un documento en papel.

Otras características de esta HCE es que clasificará los diagnósticos con el estándar internacional de enfermedades definido por al Organización Mundial de la Salud en la versión 10 (CIE10), también integrará el acceso a exámenes imagenológicos digitales adquiridos desde equipos que cumplan con la norma de imagen digital y comunicaciones en medicina (por siglas en inglés, DICOM).

Tanto MiniClin como la HCE de Trauma fueron pensados con la idea de que en el futuro sean los propios médicos quienes definan los formularios para registro en el sistema, así estos registros se adecuarán a las necesidades de los médicos, quitándole una pesada y tediosa tarea de análisis a los informáticos. Esto aporta también a disminuir la barrera cultural entre médicos e informáticos, haciendo a los médicos partícipes activos en el desarrollo de la HCE.

En conclusión, los sistemas que no sigan estándares, tanto en el modelado interno de la información clínica como en su representación para la comunicación, tenderán a desaparecen en los próximos años. Estos sistemas serán islas de información dentro de una institución e irá en contra de sus necesidades de integración interna entre sistemas y externa con otras instituciones. Además, quienes no adopten estándares estarán violando el decreto de Historia Clínica Electrónica única de cada persona, desde el registro perinatal hasta el fallecimiento.

A/C Pablo Pazos Gutiérrez

http://sites.google.com/site/pablopazosgutierrez/

[A] Tesis de grado en elaboración: “Historia Clínica Electrónica de Trauma” A/C Pablo Pazos, A/C Leandro Carrasco, Tutor: Prof. Franco Simini, Facultad de Ingeniería, UdelaR.

Referencias

[1] Health Level Seven, Inc

http://www.hl7.org/

[2] ISO/CEN 13606

http://www.iso.org/iso/catalogue_detail.htm?csnumber=40784

[3] OpenEHR, future-proof and flexible EHR System Architecture

http://www.openehr.org/home.html

[4] OpenEHR-ES: comunidad OpenEHR en español

http://code.google.com/p/miniclin/

[5] MiniClin

http://code.google.com/p/miniclin/downloads/list

Informática Clínica y Estándares

2009-12-18T01:04:00.002-02:00

Hace un tiempito hice un trabajo resumiendo algunos estándares, dando un poco de contexto, buscando complementariedades, y analizando qué lugar ocupan en el desarrollo de la Historia Clínica Electrónica. Aquí dejo la presentación que hice en las Jornadas de Informática e Investigación Operativa de la Facultad de Ingeniería de Montevideo, espero sea de su agrado.

¡Los comentarios son bienvenidos!

Pablo Pazos Gutierrez Informatica Clinica Y Estandares

View more documents from Pablo Pazos.

Super estandares en informatica medica

2009-12-05T23:11:00.001-02:00

De distintas charlas profesionales tanto informáticos cómo médicos acerca de los estándares en informática médica, sobre todo en HL7, he notado que varios conceptos no están del todo claros o literalmente no saben de lo que están hablando. Por ejemplo muchos piensan que HL7 es un solo estándar y que su aplicación es directa, cómo definir el estándar para una entrada de corriente: tanto el macho cómo la hembra son especificados de forma estándar y cuando son fabricados por distintos proveedores, si cumplen con el estándar, macho y hembra encajan a la perfección. En la informática médica este es un ideal que no podrá ser logrado mientras estos conceptos no estén claros. Y se podría afirmar que sería imposible que HL7 u otros estándares funcionen de esta manera.

Primero cabe aclarar que HL7 es una organización que crea estándares, y que si vemos a HL7 como estándar, es en realidad un gran conjunto de estándares dedicados sobre todo a resolver la comunicación entre sistemas clínicos y administrativos. Estos estándares aplican a áreas específicas o “dominios” dentro del ambiente de la salud.

Si por “estándar” pensamos en el ejemplo de la entrada de corriente la cual se conecta y encaja perfectamente, en realidad HL7 se comporta como un “súper estándar” porque no tiene esa capacidad, o sea que es un paso previo o superior a la aplicación de un estándar. En el mundo de HL7 para que cualquier estándar sea implementado es necesario definir las llamadas “guías de implementación”, las cuales especifican acuerdos entre distintos actores para definir cómo implementarán uno o varios estándares HL7, o sea que sin un acuerdo previo es prácticamente imposible que dos o más sistemas intercambien mensajes HL7 y lleguen a interoperar semánticamente.

Existe una organización llamada Integrating the Healthcare Enterprise o simplemente IHE que se encarga de definir especificaciones de cómo utilizar mensajería HL7 para cumplir con determinados propósitos, por ejemplo resolver toda la mensajería necesaria para tener informatizados los ciclos de pedido, reporte y consulta de exámenes imagenológicos. Estas especificaciones se llaman “perfiles” y cada perfil aplica a un dominio particular como ser: anatomía patológica, cardiología, oftalmología, laboratorio, coordinación de cuidado del paciente, oncología, radiología, etc. Si bien IHE no es un estándar, si no que es una forma de usar los estándares HL7 y DICOM (para radiología digital), es una orientación a las guías de implementación HL7 para definir acuerdos entre los actores, así que podría verse como un estándar complementario o de guía.

En definitiva logramos una relación cómo la descrita en la figura 1.

Figura 1.

HL7 no es el único “súper estándar”, existen otros como OpenEHR o DICOM, dos con una característica común: son estándares abiertos.

OpenEHR intenta resolver la forma en que se desarrollan los sistemas de información clínicos, que son los sistemas que forman la ya conocida Historia Clínica Electrónica. OpenEHR plantea una arquitectura con los distintos componentes del sistema, propone un completo modelo de información clínica y administrativa, y propone la “orientación al conocimiento” de los sistemas de información en salud, a través de sus Arquetipos. Los arquetipos son la forma de expresar conceptos médicos en un formato computable, y es la forma de bajar del “súper estándar” al estándar aplicable. Los arquetipos también son la forma de especificar los acuerdos entre los actores, es decir que si dos o más actores implementan su propia Historia Clínica Electrónica y se ponen de acuerdo en los arquetipos de los conceptos clínicos que manejarán en cada historia, luego podrán intercambiar información clínica sin problemas. Los conceptos pueden ser por ejemplo: “presión arterial”, “administración de medicamento”, “escala de coma de Glasgow”, etc.

Figura 2.

En el mundo de los exámenes imagenológicos digitales encontramos al estándar DICOM, otro súper estándar. DICOM propone un modelo de información y un conjunto de interacciones o transacciones entre sistemas los cuales se ejecutan para automatizar los procesos de: solicitud de un estudio, coordinación de un estudio, ejecución del estudio, elaboración del informe por el radiólogo, entrega del informe al médico solicitante. Cómo DICOM es un “súper estándar” es necesario llegar a un acuerdo previo para definir cómo será utilizado, en el mundo DICOM este acuerdo se llama “DICOM Conformance Statement” ó “Declaración de Conformidad DICOM”. Éste es un documento que especifica todas las decisiones particulares que un proveedor tomó al implementar la norma, el cual debe entregar cada vez que quiera conectar su producto con otros productos “DICOM compatibles”, o sea que esta declaración de conformidad en realidad no es un acuerdo entre actores, si no que es una forma de mostrarle a otros actores cómo es que un sistema implementa DICOM. El capítulo 2 de la norma DICOM define qué es la declaración de conformidad y cómo debe ser creada.

Figura 3.

En conclusión, los estándares propuestos en el área de la salud no son por sí mismos estándares aplicables, si no que son “súper estándares”, los cuales necesitan de acuerdos y decisiones previas que bajen la complejidad y generalidad de los mismos a algo implementable en un sistema de información clínica. Por lo tanto debemos tener cuidado al comprar productos que se ofrezcan como “compatibles HL7” o “compatibles OpenEHR” o “compatibles DICOM”, lo que necesitamos realmente son: las guías de implementación, los arquetipos o la declaración de conformidad, respectivamente.

Primer aproximacion a la Historia Clinica Electronica: los sistemas ADT

2009-11-29T21:52:00.004-02:00

Los sistemas de Historia Clínica Electrónica (HCE) pueden tener distinta granularidad en cuanto al registro de información. La granularidad más gruesa que tiene algo de valor para la institución que implementa la HCE es el sistema de Admisión/Ingreso, Alta y Transferencia (ADT por su sigla en inglés: Admission, Dicharge, Transfer).

Estos sistemas son los que tienen la granularidad más gruesa, en cuanto a la información que éstos son capaces de registrar, por que es donde se registran los grandes eventos en la atención de un paciente: cuando el paciente es admitido o ingresado, cuando es dado de alta o cuando es transferido a otra institución o a otro servicio dentro de la misma institución. También será posible registrar información sobre las interconsultas, que no son transferencias porque el responsable de la atención sigue siendo el mismo médico.

El registro del ADT es de suma importancia para la gestión, porque se marcan los momentos donde comienzan y terminan múltiples procesos: administrativos, contables y clínicos. Estos procesos son los que generan toda la información que deberá registrarse en la HCE de un paciente, y como debemos empezar la implementación de la HCE por alguna parte, como primer aproximación a la HCE completa es bueno empezar registrando cuando empiezan y terminan los procesos, y registrando la información básica asociada a esos eventos.

Si bien la información asociada a la Admisión, Alta o Transferencia de un paciente a simple vista puede verse como información meramente administrativa, ante un análisis más profundo veremos que en cada uno de esos eventos tienen asociados información clínica básica. En la Admisión se podría registrar un "motivo de consulta" o un "triage (*) administrativo o de enfermería". En el Alta se debe registrar un "motivo de alta", que en general es clínico y es registrado por un médico, además se registra el "diagnóstico", ya que un paciente no debería ser dado de alta sin diagnosticar. En la Transferencia también se debe registrar un "motivo clínico de la transferencia" y "el destino", el cual puede ser un servicio interno, un servicio externo u otra institución sanitaria. En cuanto a la Transferencia, se debería registrar un "diagnóstico" (aunque sea presuntivo) y pueden asociarse documentos clínicos como el "resumen de actuación sobre el paciente", que resume los procedimientos se le hicieron, que medicamentos se le dieron, que estudios se le realizaron, etc. Si se realizan interconsultas, se debería registrar a qué especialidades se consultaron.

Resumen de información mínima a registrar en el ADT: (actualizado 09-12-2010)

Admisión:

Día y hora de la adminisión
Motivo de consulta
Triage

Alta:

Día y hora del alta
Motivo del alta
Diagnóstico(s) definitivo
Resumen de actuación (procedimientos, medicamentos, estudios)

Transferencias:

Motivo de transferencia
Diagnóstico(s) (presuntivo o definitivo)
Resumen de actuación (procedimientos, medicamentos, estudios)
Destino (internación domiciliaria, otra institución, servicio de la misma institución, centro especializado, etc)

Interconsultas:

Día y hora de la interconsulta
Motivo de la interconsulta
Especialidad(es) consultada(s)

En definitiva, un buen sistema ADT no garantiza el éxito de un proyecto de Historia Clínica Electrónica, pero es una excelente base para la HCE. Además si se maneja correctamente el proyecto, el ADT puede mejorarse y expandirse paulatinamente hasta llegar a un sistema de HCE completo.

En próximos artículos intentaré abordar este tema y plantear mi opinión sobre cómo comenzar un proyecto de HCE desde el ADT hasta llegar a una HCE completa y al éxito en la implantación y el uso de los Sistemas de Información Clínicos.

(*) Triage es la evaluación de gravedad del paciente: http://es.wikipedia.org/wiki/Triaje

El tema cero en implementacion de Historias Clinicas Electronicas

2009-11-27T22:28:00.000-02:00

La identificación de las personas es el "tema cero" a resolver en cualquier implementación de un sistema de información en el ámbito de la salud. Una correcta identificación de las personas garantiza la correctitud y calidad de los registros electrónicos, por ejemplo: evita la fragmentación de la información clínica de un paciente y evita que se registre información de un paciente en la Historia Clínica de otro. Además evita que a un paciente se le den drogas o se le practiquen procedimientos que no son para él.

Por otro lado cuando decimos "personas" no hablamos solo de pacientes, es necesario identificar de forma unívoca e inequívoca a toda persona que participe en la atención médica de un paciente, desde el médico responsable de la atención, la enfermera que le toma la presión, el técnico que le hace una tomografía, el administrativo de admisión, etc.

No está de más aclarar que cuando se habla de "identificación de personas" no se está hablando de elegir un número o código que identifique a cada una de las personas, ya que estos identificadores por si solos no garantizan la correcta identificación de las personas. Un ejemplo real es que hay personas que tienen 2 documentos de identidad del mismo país y con números distintos, esto quiere decir que si la persona se atiende en una clínica y entrega uno de esos documentos, la información clínica registrada electrónicamente se asocia a dicho documento, luego si viene a atenderse de nuevo con el otro documento, para el sistema informático son 2 personas distintas, por lo que la información clínica de esa persona se fragmenta en 2 registros.

La clave no está en encontrar el mejor número o el mejor código, éstos siempre tendrán problemas, la solución es crear el mejor "servicio de identificación", y la identificación se debe basar en la identidad de las personas, no en un simple número, es por eso que los documentos de identidad no tienen solo un número, tienen el nombre completo, la fecha de nacimiento y la nacionalidad. En el ámbito de la salud estos datos, patronímicos o demográficos, más el dato del sexo (desde el punto de vista administrativo) son los datos mínimos que componen la identidad de la persona, y son los datos que deben usarse en el servicio de identificación de personas para verificar que una persona es quien dice ser.

Esta es una introducción al problema de identificación de personas en el contexto de la implementación de la Historia Clínica Electrónica única para cada persona. En artículos posteriores intentaré describir los distintos procesos involucrados en la identificación de las personas, cómo afectan estos procesos en la calidad de los datos, y la necesidad de un proceso de auditoria continua de datos patronímicos para que el servicio de identificación de personas funcione correctamente.

Presentación

2009-11-24T10:34:00.000-02:00

Este blog tratará de temas relacionados con la informática médica y los estándares en ese ámbito.

Me presento, mi nombre es Pablo Pazos Gutiérrez soy Uruguayo y vivo en Montevideo. Soy Analista en Computación de la FING UdelaR. Actualmente estoy llevando a cabo mi tesis de grado y me falta poco para recibirme de Ingeniero en Computación. Justamente mi tesis es la implementación de una Historia Clínica Electrónica (HCE) de atención en Trauma con acceso a exámenes imagenológicos utilizando OpenEHR y otros estándares como DICOM y HL7. Actualmente estoy trabajando en el proyecto de HCE de FEMI, uno de los proyectos de HCE más grandes del país.

Me estoy especializando en Informática Médica, en los estándares disponibles, y en las últimas tecnologías y herramientas disponibles. También he presentando trabajos en congresos locales y haciendo algunos cursos como el 10x10 de IMIA-LAC en el Hospital Italiano de Buenos Aires y recientemente el Taller de Interoperabilidad con HL7-CDA brindado por HL7 Argentina.

Sitio personal: pablo.swp.googlepages.com/

Perfil en LinkedIn: http://www.linkedin.com/in/pablopazosgutierrez