19 de diciembre de 2009

Estandares que salvan vidas

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

[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

[2] ISO/CEN 13606

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

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

[5] MiniClin





18 de diciembre de 2009

Informática Clínica y Estándares

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!

5 de diciembre de 2009

Super estandares en informatica medica


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.



29 de noviembre de 2009

Primer aproximacion a la Historia Clinica Electronica: los sistemas ADT

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

27 de noviembre de 2009

El tema cero en implementacion de Historias Clinicas Electronicas

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.

24 de noviembre de 2009

Presentación

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