Marco de trabajo genérico para crear sistemas de Historia Clínica Electrónica basados en documentos clínicos HL7-CDA

A/C Pablo Pazos Gutiérrez

Resumen y objetivos: En la implementación de una Historia Clínica Electrónica (HCE) en las instituciones prestadoras de servicios de salud, las opciones en cuanto a la metodología de trabajo, los modelos de información a seguir y a la tecnología a utilizar son muy variadas, y la elección de una u otra opción no garantiza el éxito del proyecto. El presente trabajo propone migrar del clásico desarrollo de sistemas orientados a la gestión de datos, al desarrollo de sistemas orientados a la gestión del conocimiento clínico, proponiendo un marco de trabajo que incluye metodología, una discusión fundamentada sobre la elección de modelos de información, y tecnologías a utilizar. Implementando este marco se lograrían sistemas de HCE con fuertes características de estandarización, generalidad, flexibilidad, accesibilidad, bajo costo de implementación, bajas necesidades en infraestructura, perdurables en el tiempo e independientes al cambio de la tecnología. Los resultados obtenidos fueron: la implementación de un marco de uso general para desarrollar de sistemas de HCE y se creó una nueva sintaxis basada en XML para representar el conocimiento clínico mediante plantillas CDA. Palabras clave Historia Clínica Electrónica, Información Médica Normalizada, Repositorio Documental Clínico, Informatización del Conocimiento Clínico Introducción Con la actual necesidad del país y la región de implementar la Historia Clínica Electrónica (HCE) única para cada paciente, es imprescindible buscar los procesos y mecanismos técnicos que permitan realizar una implementación de HCE que garantice el cumplimiento de estándares, la capacidad de ser accesible en cualquier momento y desde cualquier lugar, la independencia de la tecnología que varía año a año, entre otras características deseables. Si bien las características deseables en un sistema de HCE son bien conocidas, los desarrollos actuales siguen tendiendo a

sistemas integrales, pseudo-monolíticos, donde no se hacen consideraciones de estandarización, y donde abunda el desarrollo a medida y la falta de generalidad. Estos sistemas son aplicables en las instituciones donde son concebidos, pero sesgan la aplicabilidad como un todo, o partes de este, en otras instituciones prestadoras de servicios de salud, siendo enormes los costos de adaptación de la solución a diversas realidades. La estandarización y la independencia de la tecnología son necesarias para permitir la aplicabilidad del mismo sistema a diversas realidades, para la integración de la HCE con otros sistemas, y para garantizar la validez de los datos clínicos existentes en el sistema informático a lo largo del tiempo. Con este fin, se propone es un marco de trabajo donde los expertos en el dominio de la salud son quienes especifican el conocimiento clínico, para que un componente de software consuma ese conocimiento y genere automáticamente el sistema de información. Por otro lado, estos expertos podrían especificar los procesos de atención de los pacientes en las distintas áreas y sectores de una institución prestadora de servicios de salud. La definición de los procesos queda fuera del alcance del presente trabajo, planteándose como trabajo futuro. Siguiendo un marco de trabajo de este tipo, una tesis a probar es que tanto los tiempos de desarrollo como las barreras tecnológicas y culturales serían menores que en el enfoque tradicional de desarrollo de un sistema de información en el ámbito de la salud. Este es claramente un trabajo a futuro ya que resultará de la aplicación y evaluación del marco de trabajo planteado. El presente documento está organizado en tres secciones. La primera explica los conceptos del marco de trabajo a un nivel general, repasando la problemática, los objetivos a cumplir, las características deseables para un sistema de HCE, los roles necesarios y las decisiones a tomar. La segunda sección muestra una implementación particular del marco propuesto, donde se tomaron las decisiones planteadas en la primera sección, argumentando y discutiendo cada una de ellas. Por últimos se plantean algunas extensiones al marco de trabajo propuesto para trabajo futuro, se exponen casos de uso particular que se pueden implementar a partir del este, y se culmina con un resumen y la conclusión del presente trabajo.

1

Historia Clínica Electrónica La Historia Clínica puede verse como una serie de documentos, ordenados cronológicamente, donde uno o más miembros del equipo de salud registran diversos datos, enmarcados en actos clínicos, y referentes a un determinado paciente. La analogía al mundo informático se puede ver en que el papel se transforma en un conjunto de formularios a llenar en pantalla, también en el contexto de un acto clínico y para un determinado paciente. Dentro de una HCE los datos clínicos pueden ser almacenados de dos formas, mediante un repositorio de datos clínicos o un repositorio documental. En un repositorio de datos clínicos, se almacenan los datos que generan y utilizan los distintos sistemas informáticos que componen la HCE, es decir, son bases de datos operativas que sirven también para alimentar a otros sistemas, como los de soporte a las decisiones clínicas o gerenciales, sistemas para realizar estudios epidemiológicos, etc. En un repositorio documental, en lugar de contar con registros en una base de datos, se tiene un conjunto de documentos que contienen datos clínicos de un paciente y el contexto en el cual se obtuvieron. Al igual que los documentos en papel son organizados en carpetas, los documentos clínicos electrónicos pueden ser organizados en carpetas o directorios en el sistemas de archivos de una computadora, por lo que la analogía con el mundo real es directa, de modo que la forma en que los profesionales utilizan una HCE no afectará su trabajo cotidiano por la familiaridad en el manejo de carpetas y documentos. Este trabajo sigue el enfoque de repositorio documental, sin embargo los conceptos expuestos pueden ser aplicados para contar también con un repositorio de datos clínicos. Marco de trabajo propuesto Se propone un marco de trabajo o “framework” para la implementación de un sistema informático orientado a la gestión del conocimiento clínico, formado por roles con tareas bien definidas, artefactos en forma de insumos y productos del framework y un conjunto de servicios que este ofrece. Este framework está orientado a la gestión del conocimiento, a diferencia de los desarrollos actuales que se centran principalmente en la gestión de los datos. Actualmente se utiliza mucho tiempo en la resolución de problemas rutinarios a nivel de cómo se almacenan los datos en bases de datos o de presentación de los formularios a ser completados por los usuarios. Estos temas no agregan valor a un sistema de Historia Clínica Electrónica, donde es necesario resolver problemas de más alto nivel y que sin inherentes al complejo dominio de la salud. En el enfoque de este trabajo, los problemas a resolver son los de modelado del conocimiento y procesamiento de ese conocimiento para generar automáticamente tanto la parte de almacenamiento de la información, cómo la de presentación de los formularios a ser completados por los profesionales de la salud.

Los roles involucrados en el framework son:

• Profesional de la salud • Profesional informático • Experto en el dominio

Actualmente el profesional de la salud es parte del desarrollo de los sistemas de información clínica, participando como experto en el dominio y como usuario del sistema informático resultado del desarrollo. En el enfoque actual los profesionales participan de forma pasiva en la representación del conocimiento clínico que será vertido en el sistema informático resultante, ya que son los profesionales informáticos quienes extraen el conocimiento de los profesionales de la salud, y estos lo analizan y modelan en términos informáticos. El enfoque de este trabajo es que el profesional de la salud debe tener una participación activa en el modelado del conocimiento clínico, ya que él es el experto en dicho dominio, aunque no todo profesional de la salud puede llevar a cabo esta tarea. Por lo tanto, se propone crear un nuevo rol llamado “experto en el dominio”, el cual debe ser desempeñado por un profesional de la salud que a su vez esté capacitado en la utilización de herramientas que le permitan especificar el conocimiento clínico en algún formato que pueda ser procesable de manera automática por una computadora. Como el profesional informático no es experto en el dominio de la salud, en el enfoque actual de desarrollo se corren riesgos de mala interpretación del conocimiento clínico durante el análisis informático, lo que puede provocar desfasajes en los tiempos planificados del proyecto, por tener que corregir una y otra vez el análisis erróneo, siendo estos costos mayores a medida que avanzan las etapas del desarrollo del software [1][2]. Por otro lado, el resultado obtenido puede generar rechazo de los usuarios por no ser lo que ellos necesitan o no ser lo que pensaron que se estaba construyendo. Entonces se plantea que permitiendo que los mismos profesionales de la salud especifiquen el conocimiento que manejan a diario, disminuye la probabilidad de rechazo por sus pares o de fracaso del proyecto por exceso en el consumo de recursos o porque el producto logrado no es el correcto. Entonces la especificación del conocimiento clínico debe ser llevada a cabo por el experto en el dominio, mientras que el profesional informático pasa de tener que realizar esta tarea, que está fuera de su dominio de conocimiento, a concentrarse en crear y mejorar componentes de software que permitan utilizar de mejor forma el conocimiento clínico especificado por el experto. Aplicando el principio de división del trabajo de Taylor, podemos plantear la hipótesis de que separando las tareas de definición del conocimiento y mantenimiento del sistema informático, se optimizan los tiempos de implementación y se mejora la calidad de la Historia Clínica Electrónica resultante. Del mismo modo que se separan estos roles y sus tareas, a nivel conceptual el sistema informático resultante se separa en dos capas, una de conocimiento clínico y la otra del sistema de información, y el nexo entre estas capas es el framework propuesto. La especificación del conocimiento clínico es el principal insumo del framework, a partir del cual se genera sistema de información clínica que sustenta a la Historia Clínica Electrónica.

2

Los productos de salida del framework son, por un lado, los formularios electrónicos que componen la HCE, los cuales serán completados por profesionales de la salud en un acto clínico para un paciente determinado, y por otro lado, los documentos clínicos generados a partir de los datos que registran los miembros del equipo de salud. El framework debe ofrecer tres servicios básicos:

• Almacenamiento • Visualización • Comunicación

Anteriormente se mencionó que este trabajo está basado en el enfoque de repositorio documental como método de almacenamiento de información clínica, sin embargo dicho almacenamiento puede realizarse en diversos medios. El servicio de almacenamiento deberá proveer la capacidad de almacenar los documentos clínicos que sean generados por el equipo de salud, ya sea en la computadora personal de un médico, una computadora local en un determinado sector de atención, en un servidor institucional centralizado, en un CD, DVD, un pendrive, en dispositivos móviles, entre otros. El servicio de visualización debe ofrecer la capacidad de navegación, búsqueda y visualización de documentos clínicos existentes en el repositorio documental. Este servicio es de suma importancia sobre todo en la atención ambulatoria, ya que los médicos necesitan una visión simple y ágil del historial de salud reciente del paciente que están atendiendo. Puede incluir la visualización desde diversos medios, por ejemplo dispositivos móviles como PDAs o Smart Phones (iPhone, BlackBerry, Omnia, etc). En cuanto al servicio de comunicación, cuenta con la responsabilidad de permitir la emisión y recepción de documentos clínicos entre distintos sistemas. Este servicio permite contar con una única historia clínica por paciente, aunque los distintos repositorios documentales estén distribuidos geográficamente entre varios sectores o instituciones. Para la implementación de un servicio de comunicación que integre los distintos documentos clínicos dispersos en una única Historia Clínica Electrónica de una paciente, es necesario contar con un índice centralizado de documentos clínicos, en el cual los distintos sistemas puedan consultar para averiguar donde están localizados los documentos clínicos de un determinado paciente. Este es el enfoque que sigue la especificación del perfil XDS de IHE [3]. Implementación del framework El resultado de la implementación de la prueba de concepto es un componente de software llamado “miniClin”, el cual no es una Historia Clínica Electrónica, si no que es un framework general para implementar cualquier HCE basándose en el concepto de gestión del conocimiento clínico. Por lo tanto “miniClin” no determina que información será ingresada por los profesionales de la salud para generar los documentos clínicos, si no que permite que los profesionales de la salud,

más específicamente los expertos del dominio clínico, definan qué conceptos clínicos desean manejar y cual será la información necesaria de ser registrada para cada tipo de acto médico. Estos conceptos pueden estar adaptados a la realidad de la institución donde se quiera implementar la HCE, considerando sus necesidades particulares. A partir de las plantillas definidas, “miniClin” genera automáticamente el formulario a ser llenado por el profesional en algún acto médico, y luego con esa información se genera un documento clínico CDA para un determinado paciente en dicho acto médico. Luego, los documentos clínicos contenidos en el repositorio documental podrán ser vistos por otros miembros del equipo de salud, podrán ser comunicados a otros sistemas, podrán ser almacenados en medios ópticos o magnéticos, etc. Una característica de los documentos clínicos basados en XML [8], como es el caso de CDA, es que son fáciles de firmar digitalmente, lo que podrá garantizar la integridad y la autoría de cada documento. El esquema general del framework, que muestra los elementos recién comentados puede verse en la figura 1. Para poder implementar el framework propuesto fue necesario definir algunos elementos, los cuales fueron escogidos pensando en las características deseables de las Historias Clínicas Electrónicas que se implementarán sobre este.

Fig. 1: Esquema general del framework “miniClin” Los elementos seleccionados fueron:

• Modelo de información para representar documentos clínicos electrónicos.

• Formato y sintaxis para especificación de conocimiento clínico.

• Tecnologías sobre las cuales desarrollar el framework.

3

El modelo de información fue seleccionado considerando principalmente características de estandarización y simplicidad, para poder garantizar una rápida implementación del framework, por estos motivos fue seleccionado el estándar CDA (Clinical Document Architecture) [4][5]. Dentro del conjunto de estándares HL7 [6] dedicados a la normalización de la información en el ámbito de la salud, CDA es el estándar propuesto para el modelado de cualquier documento clínico para el intercambio de información entre sistemas. Aunque este es el objetivo con el cual CDA fue concebido, “...la comunidad de usuarios de CDA ha tendido a usarlo más como una especificación de persistencia.” [7]. Si bien CDA es más que suficiente para una primera implementación, la elección del modelo de información clínica debería realizarse en función de las necesidades particulares del sistema de HCE de cada institución. Más adelante se propone una discusión sobre qué modelos de información se podrían elegir como alternativa a CDA de ser necesario. El repositorio documental propuesto, y toda la información clínica contenida en este, cumple con el estándar CDA con todas las ventajas que esto tiene para la HCE resultante. Características deseables que se tienen desde el inicio:

• La información contenida en el documento clínico, que es parte de la Historia Clínica Electrónica de un paciente, es legible por una persona.

• Los documentos clínicos electrónicos pueden ser intercambiados entre sistemas (interoperabilidad sintáctica) y los sistemas pueden utilizar la información intercambiada (interoperabilidad semántica).

• CDA permite definir permisos de visualización, estableciendo la capacidad de que la información que contiene el documento sea vista solo por quienes tienen privilegios suficientes para verla.

• Incluye información de contexto básica que es útil para determinar en qué ámbito fue generado el documento.

• Un documento clínico electrónico puede ser guardado en un Pen Drive, CD, DVD o ser enviado por email.

También fue necesario definir la forma en la que el experto en el dominio debe especificar el conocimiento clínico para alimentar con este al framework, lo cual es necesario para que el conocimiento clínico pueda ser procesado automáticamente por una computadora. El conocimiento clínico deberá ser especificado en un sistema informático como una estructura de conceptos clínicos, los cuales están formados datos y restricciones que estos datos deben cumplir. Por ejemplo, un concepto clínico es la “presión arterial”, la cual está formada a su vez por la “presión sistólica” y la “presión diastólica”. A su vez, ambas presiones se miden mmHg (milímetros de mercurio) y su magnitud es un número entero. Por otro lado se sabe que la presión sistólica debe ser mayor que la diastólica (si es que hay presión). El formato de especificación del

conocimiento clínico está basado en el estándar XML [8], mediante la utilización de una sintaxis particular la cual es uno de los resultados del presente trabajo. Más adelante se darán ejemplos de aplicación de esta sintaxis. Las tecnologías fueron seleccionadas por ser livianas y multiplataforma, por lo que “miniClin” no requiere de grandes prestaciones de hardware para funcionar correctamente, por lo que cualquier computadora de escritorio puede transformarse en un sistema de HCE completo. La implementación de la prueba de concepto del framework “miniClin” se realizó principalmente utilizando Yupp PHP Framework [9], un framework de uso general para el desarrollo de aplicaciones web basadas en el lenguaje de programación PHP [10]. Cómo solución de persistencia del repositorio documental se realizó un híbrido entre documentos almacenados en el sistema de archivos de una computadora e índices en una base de datos que permiten buscar documentos clínicos mediante criterios determinados, como por ejemplo la fecha de creación del documento, el paciente para el cual se crea el documento, el profesional que crea el documento, entre otros. Como solución de base de datos relacional fue utilizado MySQL [11]. Discusión sobre modelos de información El modelo de información CDA fue el elegido para representar los documentos clínicos que serán generados por el framework propuesto, esta elección se debió a su gran simplicidad y a que es un modelo estándar. Ahora, la pregunta que surge es: ¿alcanza con CDA para modelar cualquier HCE completa? La respuesta no es independiente del contexto, es decir que depende de hasta qué nivel de implementación quiera llegar la institución prestadora de servicios de salud y de cuales son sus necesidades particulares en el modelado de información clínica. Si por cada acto médico que se realice sobre un paciente se generara un documento CDA que contenga toda la información clínica generada en dicho acto, y que a su vez contenga toda la información de contexto, se contaría con una HCE completa y única para cada paciente. La información de contexto considerada como necesaria de registrar se debería definir a priori para cada institución. Claramente, si se llegara a una instancia donde para representar alguna información particular se debe forzar el modelo saliéndose del estándar, estaríamos en presencia de una limitación del mismo, por lo que se debería optar por otro modelo de información clínica que contemple el caso en cuestión sin salirse del estándar. Para la realización de la implementación de prueba de concepto en este trabajo, el modelo CDA fue más que suficiente. Existen algunas alternativas a CDA para el modelado de documentos clínicos, por ejemplo el modelo de referencia del estándar CEN/ISO 13606 [12][13] o el modelo de referencia del estándar abierto OpenEHR [14]. El estándar CEN/ISO 13606 fue concebido como una solución para el intercambio de mensajes que contengan información clínica entre instituciones o sistemas, su modelo es sencillo e

4

intenta emular electrónicamente la organización de los registros en papel. En la figura 2 se muestran los bloques lógicos que componen este modelo.

Fig. 2: Bloques lógicos del modelo CEN/ISO 13606 [13] Existe una correspondencia entre el modelo de ISO 13606 y CDA, por lo que un sistema que implemente un modelo, fácilmente puede interoperar con sistemas que implementen el otro [7]. OpenEHR partió del modelo de ISO 13606 y lo extendió para cumplir los requerimientos de una arquitectura genérica y completa para implementar una Historia Clínica Electrónica longitudinal que pueda soportar los cambios en la tecnología a través del tiempo, manteniendo la semántica de la información registrada. El gran aporte de OpenEHR son los arquetipos, los cuales permiten especificar el conocimiento clínico dentro de un sistema informático, este conocimiento puede utilizarse para que los sistemas interoperen de forma semántica a nivel de conceptos clínicos [15]. También proponen una sintaxis para definir arquetipos llamada Archetype Definition Language (ADL) [16], con la gran ventaja de que es genérica, y capaz de ser utilizada para definir arquetipos sobre otros modelos de referencia aparte del modelo de OpenEHR, incluso permite definir arquetipos sobre los modelos CEN/ISO 13606 y CDA [17]. Si bien el modelo de referencia de OpenEHR especifica gran cantidad de conceptos clínicos, también mantiene un gran nivel de generalidad, de modo de poder aplicarlo en distintos contextos dentro del dominio de la Informática Médica, por lo que es altamente flexible en su aplicación específica. Esta abundancia de conceptos pueden generar dudas sobre la posibilidad de aplicación del modelo a un caso concreto, debido a su complejidad, pero considerando la alta complejidad de la realidad médica, podemos intuir que cuanto más fielmente se represente esa realidad, más complejo debería ser el modelo. Esta visión ahora generaría dudas sobre los modelos inherentemente simples, donde por ejemplo, un experto puede verse tentado a violar el estándar para resolver un caso particular, sin pensar en las consecuencias que eso puede traer a futuro, como cuando se desee interoperar con otra institución que si sigue el estándar. Por lo tanto algunas de las preguntas que deberíamos responder antes de elegir uno u otro modelo son:

• ¿Qué tan compleja es la realidad particular que se necesita modelar?

• ¿Qué conceptos clínicos debe manejar la aplicación? • ¿Qué nivel de detalle se necesita en la información a

registrar? • ¿Con qué recursos cuento para implementar la HCE? • ¿El modelo abarca todos los conceptos clínicos que la

HCE debe manejar? La elección de uno u otro modelo debería realizarse por un experto en modelos en conjunto con el experto en el dominio, que conoce las necesidades de su institución. Sintaxis para especificación de plantillas CDA Uno de los principales resultados obtenidos en el presente trabajo es la definición de una sintaxis capaz de representar el conocimiento médico para que una computadora lo pueda procesar de forma automática. Esta representación tomará el nombre de plantilla CDA, ya que permite definir la forma que tendrán los documentos clínicos CDA que formarán parte del repositorio documental de la HCE. Algunos ejemplos de estos documentos podrían ser:

• Historia clínica de emergencia general • Historia clínica de emergencia de trauma • Historia clínica de CTI • Historia clínica ambulatoria • Historia clínica de internación domiciliaria • Descripción operatoria • Resumen de historia clínica • Resumen de internación • Indicaciones terapéuticas • Anotaciones de enfermería • Evaluación clínica • Evolución de signos vitales • Solicitud de exámenes de laboratorio • Resultados de exámenes de laboratorio • Solicitud de exámenes imagenológicos • Informe de radiología (puede incluir imágenes) • y más...

La sintaxis propuesta para las plantillas CDA está basada en el estándar XML. Esta sintaxis fue concebida a partir de la estructura de un documento clínico CDA a la cual se agregaron algunos conceptos presentes en los arquetipos de OpenEHR [18][19][20]. Dicha sintaxis se centra en la estructura de secciones y entradas de CDA, donde la información clínica se estructura en secciones y se define mediante entradas. Las entradas que pueden especificarse en una plantilla son del mismo tipo que las entradas que se definen en el estándar CDA:

• Observation • RegionOfInterest • ObservationMedia

5

• SubstanceAdministration • Supply • Procedure • Encounter • Act

El conocimiento clínico es especificado en forma de plantillas CDA por el experto en el dominio, esta especificación se realiza mediante la definición de los conceptos clínicos que formen parte de la HCE que se está implementando en un sector o una institución particular. Los conceptos clínicos se especifican mediante su estructura, sus datos y restricciones sobre estos datos. Para la implementación de una HCE completa dentro de una institución, no es necesario crear a priori todas las plantillas que se requerirán, en su lugar es posible crear la HCE completa de forma iterativa e incremental, es decir que el framework permite comenzar a trabajar con pocas plantillas con la posibilidad de crear nuevas plantillas y de modificar las plantillas actuales, sin la necesidad de bajar el sistema, y lo más importante aún, que los documentos clínicos ya creados en la HCE siguen siendo válidos. Por esta razón se podrá agregar indefinidamente conocimiento clínico a la aplicación, y perfeccionar el conocimiento actual, sin necesidad de modificar las bases de datos ni la interfaz de usuario porque estas se generan automáticamente a partir del nuevo conocimiento vertido al framework. A continuación se presentan dos ejemplos de aplicación de la sintaxis propuesta. El ejemplo 1 especifica una sección donde se define el concepto de imagen, esta imagen puede ser obtenida por un médico, mediante una cámara digital, y luego adjuntada a la HCE del paciente, o podría ser una imagen obtenida en un examen radiológico y extraída del servidor de imágenes médicas de la institución. El ejemplo 2 especifica el concepto de presión arterial mediante su estructura y restricciones sobre las magnitudes medidas y las unidades de medición. Ejemplo 1: definición de sección de exámenes imagenológicos <section> <title>Imágenes</title> <entries> <observationMedia occurrences="0..*"> <value mandatory="true"> <value> <regexp>*</regexp> </value> <mediaType hidden="true"> <list> <item>image/jpeg</item> <item>image/gif</item> </list> </mediaType> <charset hidden="true"> <regexp>base64</regexp> </charset> </value> </observationMedia> </entries> </section>

Ejemplo 2: definición de sección de presión arterial <section> <title>Presión arterial</title> <entries> <observation> <code code="251076008" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Presión de sangre"/> <entries> <observation> <code code="271649006" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Sistólica"/> <value type="PQ"> <value> <range min="0" max="30" /> </value> <unit> <regexp>mm[Hg]</regexp> </unit> </value> </observation> <observation> <code code="271650006" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Diastólica"/> <value type="PQ"> <value> <range min="0" max="30" /> </value> <unit> <regexp>mm[Hg]</regexp> </unit> </value> </observation> </entries> </observation> </entries> </section> Las plantillas permiten la definición de restricciones sobre los datos a registrar en la HCE. En el ejemplo 2 se definen restricciones sobre los rangos de valores posibles en las magnitudes medidas para presiones sistólica y diastólica, en este caso e mínimo valor es 0 y el máximo 30. Tanto los conceptos que se deben especificar mediante las plantillas, como las restricciones sobre los datos, son parte del conocimiento médico, no es conocimiento informático. Tipos básicos de restricciones que se pueden definir:

• listado: el valor debe ser una de las opciones dadas. • rango: el valor debe estar en el rango especificado. • expresión regular: el valor debe corresponder con la

expresión regular dada, * significa que no hay restricción en cuanto a la forma del valor.

Estas plantillas serán el principal insumo de “miniClin”, donde se utilizan para generar los formularios electrónicos que serán completados por los profesionales de la salud con datos clínicos de sus pacientes, y a partir de estos datos y de las mismas plantillas se genera un nuevo documento clínico que se almacena en el repositorio documental CDA.

6

Proceso de creación de documentos clínicos Cuando un profesional de la salud ingresa a “miniClin”, debe seleccionar qué tipo de documento clínico desea crear. Las opciones posibles son todas las plantillas que se hayan creado previamente. La selección de una plantilla entre las disponibles se muestra en la figura 3, donde se organizan por sector de atención.

Fig. 3: Selección de plantilla CDA Cuando se selecciona el tipo de documento, “miniClin” genera automáticamente un formulario web para que el profesional pueda registrar la información necesaria. Un ejemplo de formulario generado se muestra en la figura 4.

Fig. 4: Formulario generado a partir de plantilla CDA

Cuando el profesional termina de ingresar los datos, estos se guardan en forma de un documento clínico en formato CDA. Como se comentó anteriormente, el almacenamiento de los documentos estará dado por el servicio de almacenamiento, y puede ser un repositorio en la computadora personal de un médico, en una computadora local a un sector de atención, o un repositorio institucional centralizado. O también podrá almacenarse en medios externos como un CD o un pendrive, entre otras opciones. Extensiones al framework y trabajo futuro El framework propuesto es lo mínimo necesario para contar con un repositorio documental de información clínica, pero son necesarias más características para lograr una implementación completa de un sistema de Historia Clínica Electrónica. A continuación se exponen algunas de las extensiones útiles para completar dicha implementación. Definición de perfiles de acceso de usuarios en plantillas. Una extensión posible de realizar gracias a la capacidad de CDA de definir el nivel de confidencialidad de un documento clínico, es la de definir que perfiles de profesionales de la salud pueden acceder a documentos clínicos en función de su nivel de confidencialidad. El nivel de confidencialidad de un determinado documento puede ser definido en la plantilla que lo especifique. Esta sería la primera aproximación de seguridad sobre documentos clínicos CDA, luego otros mecanismos se podían aplicar también, como por ejemplo prohibir el acceso de los médicos a documentos que no pertenezcan a sus pacientes. Consumir servicios externos Una Historia Clínica Electrónica a nivel institucional no es un único componente de software, si no que es un conjunto de componentes que conforman un sistema. La HCE muchas veces necesita consumir servicios externos, o sea, servicios que ofrecen otros componentes de software, como por ejemplo servicios de identificación de personas, o servicios terminológicos para codificar entradas de información clínica que permitan el reuso de dichas entradas a posteriori. por otros sistemas informáticos, como puede ser un sistema estadístico o un sistema de facturación de procedimientos realizados sobre un paciente. Integración con flujos de trabajo en las instituciones Esta es quizás la principal extensión que es necesaria realizar sobre “miniClin”, ya que este se centra en el procesamiento de el conocimiento clínico para generar el sistema donde se registra la información clínica, pero el uso de este sistema de registro está atado a la forma en la que trabajan los profesionales de la salud en un sector o institución particulares. Por lo que es necesario también procesar el conocimiento sobre los flujos de trabajo de estos profesionales para adaptar el sistema lo mejor posible a su forma de trabajo. La solución estándar hoy en día para representar este tipo de conocimiento

7

son las herramientas de Workflow o herramientas de Business Process Management (BPM). Integración con PACS Con el advenimiento de los exámenes radiológicos digitales y los PACS (Picture Archiving and Communication System) la integración con los sistemas de Historia Clínica Electrónica es sumamente necesaria, ya que agilita el proceso de orden de un estudio, realización del estudio, realización del informe por un radiólogo y la posterior devolución al médico que realizó la orden. Esa disminución en el tiempo de atención el paciente la percibe como una mejora en la calidad de atención. Para realizar esta integración, se podrían definir en “miniClin” las plantillas para las órdenes de exámenes imagenológicos y la plantilla de reporte de radiología, la cual podría generar documentos clínicos que además del propio reporte contengan algunas imágenes seleccionadas por el médico radiólogo. Por otro lado, al servicio de visualización de documentos clínicos se le podría agregar un componente de acceso a imágenes directamente desde el PACS, y cualquier médico podría ver desde cualquier computadora los exámenes imagenológicos de sus pacientes. Herramienta para definición del conocimiento clínico Una de las extensiones que agregarían más valor a la tarea del experto en el dominio, es el uso de una herramienta que permita especificar de forma gráfica el conocimiento clínico. Esta herramienta se puede crear para ajustarse a las necesidades de las plantillas CDA propuestas, y podrá permitir que el experto acceda a la herramienta vía web. También existen algunas herramientas para realizar esta tarea, sobre todo en el ámbito de la definición de arquetipos OpenEHR y CEN/ISO 13606, como por ejemplo el Ocean Archetype Editor [21], LiU Archetype Editor [22] o LinkEHR ED [17]. Los expertos en el dominio deberían ser usuarios expertos de este tipo de herramientas. Casos de uso Historia clínica personal para viajes Una posible aplicación del framework propuesto es generar una plantilla para el resumen de Historia Clínica de un paciente. Los documentos clínicos generados como resumen de HC, a través del servicio de almacenamiento, pueden ser almacenados en un pendrive o un teléfono celular. Este resumen puede incluir cualquier dato clínico como últimas medicaciones, enfermedades crónicas, últimas enfermedades, alergias a medicamentos, e inclusive imágenes obtenidas en exámenes de radiología digitales. Luego los pacientes que se vayan de viaje llevarán este resumen en un pendrive o un teléfono celular, y en caso de necesitar atención médica, los profesionales contarán con este resumen como entrada para lograr una mejor atención de ese paciente. Este podría ser un nuevo producto o servicio que se ofrece a los socios de una mutualista o emergencia móvil.

Comunicación interinstitucional Si bien el repositorio documental donde se almacenan los documentos clínicos debe ubicarse a nivel personal (por ejemplo en la PC de un médico), a nivel de un sector (por ejemplo en una PC del CTI), o a nivel institucional (repositorio institucional centralizado), muchas veces es necesaria la comunicación entre sistemas mediante el intercambio de documentos clínicos. De esta comunicación se debe encargar el servicio de comunicación de las instituciones que participan del intercambio. La base para que los sistemas de ambas instituciones puedan “entender” estos mensajes que se intercambian es que las instituciones compartan las plantillas mediante las cuales se generaron los documentos, ya que estas contienen el conocimiento necesario para procesar los conceptos contenidos en un documento clínico. Es decir, que para cualquier intercambio es necesario acceder a la plantilla que generó el documento, esto se realiza publicando las plantillas disponibles mediante un servicio web. Por otro lado, cada documento generado contiene la información de que plantilla se utilizó para generarlo. Resumen y conclusión En el presente trabajo se propuso un marco de trabajo que propone una metodología para la definición de algunos puntos cruciales en toda implementación de un sistema de Historia Clínica Electrónica. Estos elementos son: el modelo de información a utilizar, forma de especificar el conocimiento clínico y las tecnologías para desarrollar el sistema. También plantea la necesidad de roles con tareas bien definidas: el profesional de la salud, el profesional informático y el experto en el dominio clínico. Se logra una implementación particular de este marco de trabajo, en donde se muestran las bondades y posibilidades del marco planteado. Esta implementación, llamada “miniClin”, permite la creación de cualquier sistema de HCE para cualquier sector de atención o institución. Logrando así una HCE completa y con fuertes características de estandarización, generalidad, flexibilidad, accesibilidad, bajo costo de implementación, bajas necesidades en infraestructura, perdurables en el tiempo e independientes al cambio de la tecnología. El marco permite la informatización gradual los distintos registros generados en la atención médica. Para lograr esta implementación fue necesario proponer una sintaxis para representar el conocimiento clínico en forma de plantillas CDA. Al seleccionar el modelo estándar de información clínica CDA y utilizar plantillas para representar el conocimiento clínico, se garantiza la interoperabilidad semántica con otros sistemas. Mediante estas plantillas de uso genérico es posible definir nuevos conceptos dentro del marco de trabajo que se agregarán a la HCE, aún cuando el sistema de HCE ya esté siendo utilizado por el equipo de salud. Por lo que se obtiene gran flexibilidad, por que el nuevo conocimiento es asimilado inmediatamente por la aplicación informática. Esto permite que el sistema pueda extenderse y perfeccionarse indefinidamente. Además de ser capaz de reutilizar entre distintas áreas de atención las plantillas ya definidas, disminuyendo el retrabajo.

8

9

Como las plantillas están basadas en XML [8], al igual que los documentos CDA que se almacenarán en el repositorio documental, tanto el conocimiento como los datos clínicos son independientes del cambio en la tecnología, ya que pueden ser consumidos por cualquier tecnología futura. El contar con un Experto en el Dominio trabajando en paralelo con el profesional informático, cada uno en su campo de experticia, permite que ambos puedan trabajar más rápido porque no hay curva de aprendizaje de un nuevo conocimiento, optimizando los recursos disponibles y disminuyendo los costos de implementación del sistema. La implementación utilizando tecnologías web livianas, garantiza la accesibilidad al sistema desde cualquier lugar, en cualquier momento, posibilitando el que la aplicación pueda correr en una computadora de escritorio, o incluso en un dispositivo móvil, por no necesitar de grandes prestaciones de hardware, bajando costos en infraestructura. Por último, el conocimiento volcado al framework, si bien la propuesta de este trabajo es utilizarlo para generar el sistema de información clínico, puede ser utilizado con otros fines, los usos a futuro de este conocimiento podrían ir desde la realización automática de análisis en la información contenida en la base de datos, hasta la generación automática de conocimiento derivado, por ejemplo el encontrar relación entre dos conceptos hasta ahora disjuntos. Referencias [1] What is the cost of a requirement error?, Tom King, Ravenflow http://www.stickyminds.com/pop_print.asp?ObjectId=12529&ObjectType=ART [2] Developing Functional Requirements for ITS Projects, Mitretek Systems, Inc. http://www.itsdocs.fhwa.dot.gov/jpodocs/repts_te/13621.html [3] IHE Cross-Enterprise Document Sharing (XDS) http://www.ihe.net/Profiles/index.cfm#IT [4] CDA, HL7book http://hl7book.net/index.php?title=CDA [5] Robert H. Dolin, MD, Liora Alschuler, HL7 Clinical Document Architecture, Release 2 http://www.jamia.org/cgi/content/full/13/1/30 [6] Health Level Seven, Inc http://www.hl7.org/ [7] Estándares para la Historia Clínica Electrónica, J. L. Monteagudo y C. Hernández, Sociedad Española de Informática de la Salud (SEIS) http://www.seis.es/documentos/informes/secciones/adjunto1/CAPITULO7_0.pdf [8] Extensible Markup Language http://www.w3.org/XML/

[9] Yupp PHP Framework http://www.simplewebportal.net/host/1018.htm [10] PHP (Hypertext Preprocessor) http://www.php.net/ [11] MySQL http://www.mysql.com/ [12] Electronic health record communication -- Part 1: Reference model http://www.iso.org/iso/catalogue_detail.htm?csnumber=40784 [13] La semántica en la Historia Clínica, Adolfo Muñoz Carrero http://www.msc.es/organizacion/sns/planCalidadSNS/docs/MUNOZ_CARRERO.pdf [14] OpenEHR, future-proof and flexible http://www.openehr.org/home.html [15] Sebastian GARDE, Rong CHEN, Heather LESLIE,Thomas BEALE, Ian McNICOLL, Sam HEARD, Archetype-Based Knowledge Management for Semantic Interoperability of Electronic Health Records http://www.hst.aau.dk/~ska/MIE2009/papers/MIE2009p1007.pdf [16] Archetype Definition Language http://www.openehr.org/120-OE.html [17] LinkEHR ED, Editor de arquetipos genérico http://www.linkehr.com/ [18] Archetypes for HL7 CDA documents, Eric Browne, HL7 Australia. http://www.openehr.org/wiki/download/attachments/3440870/Archetypes_in_CDA_4.pdf [19] HL7 CDA, Clinical Modelling and openEHR, Thomas Beale, NHS Scotland http://www.isdscotland.org/isd/servlet/FileBuffer?namedFile=tom%20beale.pdf&pContentDispositionType=inline [20] Preliminary Work on Building a User Friendly Adaptive Clinical Documents Repository, Enriko Aryanto, Yang Huang, Standford University [21] Ocean Archetype Editor https://wiki.oceaninformatics.com/confluence/display/TTL/Archetype+Editor+Releases [22] LiU Archetype Editor, Mattias Forss, Eric Sundvall, Mikael Nyström, Institutionen för medicinsk teknik, Linköpings universitet http://www.imt.liu.se/mi/ehr/ Contacto Pablo Pazos Gutiérrez email: pablo.swp@gmail.com