Marco de trabajo genérico para crear sistemas de historia clínica electrónica basados en documentos clínicos hl7 cda
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Marco de trabajo genérico para crear sistemas de historia clínica electrónica basados en documentos clínicos hl7 cda

  • 4,393 views
Uploaded on

Trabajo de investigación sobre el desarrollo

Trabajo de investigación sobre el desarrollo

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
4,393
On Slideshare
4,317
From Embeds
76
Number of Embeds
2

Actions

Shares
Downloads
127
Comments
0
Likes
2

Embeds 76

http://cgallego.blogspot.com 46
http://www.linkedin.com 30

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 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: sistemas integrales, pseudo-monolíticos, donde no se hacen consideraciones de estandarización, y donde abunda el En la implementación de una Historia Clínica Electrónica desarrollo a medida y la falta de generalidad. Estos sistemas (HCE) en las instituciones prestadoras de servicios de salud, son aplicables en las instituciones donde son concebidos, pero las opciones en cuanto a la metodología de trabajo, los sesgan la aplicabilidad como un todo, o partes de este, en otras modelos de información a seguir y a la tecnología a utilizar instituciones prestadoras de servicios de salud, siendo enormes son muy variadas, y la elección de una u otra opción no los costos de adaptación de la solución a diversas realidades. garantiza el éxito del proyecto. El presente trabajo propone migrar del clásico desarrollo de sistemas orientados a la La estandarización y la independencia de la tecnología son gestión de datos, al desarrollo de sistemas orientados a la necesarias para permitir la aplicabilidad del mismo sistema a gestión del conocimiento clínico, proponiendo un marco de diversas realidades, para la integración de la HCE con otros trabajo que incluye metodología, una discusión fundamentada sistemas, y para garantizar la validez de los datos clínicos sobre la elección de modelos de información, y tecnologías a existentes en el sistema informático a lo largo del tiempo. Con utilizar. Implementando este marco se lograrían sistemas de este fin, se propone es un marco de trabajo donde los expertos HCE con fuertes características de estandarización, en el dominio de la salud son quienes especifican el generalidad, flexibilidad, accesibilidad, bajo costo de conocimiento clínico, para que un componente de software implementación, bajas necesidades en infraestructura, consuma ese conocimiento y genere automáticamente el perdurables en el tiempo e independientes al cambio de la sistema de información. Por otro lado, estos expertos podrían tecnología. Los resultados obtenidos fueron: la especificar los procesos de atención de los pacientes en las implementación de un marco de uso general para desarrollar distintas áreas y sectores de una institución prestadora de de sistemas de HCE y se creó una nueva sintaxis basada en servicios de salud. La definición de los procesos queda fuera XML para representar el conocimiento clínico mediante del alcance del presente trabajo, planteándose como trabajo plantillas CDA. 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 Palabras clave tradicional de desarrollo de un sistema de información en el ámbito de la salud. Este es claramente un trabajo a futuro ya Historia Clínica Electrónica, Información Médica que resultará de la aplicación y evaluación del marco de trabajo Normalizada, Repositorio Documental Clínico, planteado. Informatización del Conocimiento Clínico El presente documento está organizado en tres secciones. La Introducción primera explica los conceptos del marco de trabajo a un nivel general, repasando la problemática, los objetivos a cumplir, las Con la actual necesidad del país y la región de implementar la características deseables para un sistema de HCE, los roles Historia Clínica Electrónica (HCE) única para cada paciente, es necesarios y las decisiones a tomar. La segunda sección imprescindible buscar los procesos y mecanismos técnicos que muestra una implementación particular del marco propuesto, permitan realizar una implementación de HCE que garantice el donde se tomaron las decisiones planteadas en la primera cumplimiento de estándares, la capacidad de ser accesible en sección, argumentando y discutiendo cada una de ellas. Por cualquier momento y desde cualquier lugar, la independencia últimos se plantean algunas extensiones al marco de trabajo de la tecnología que varía año a año, entre otras características propuesto para trabajo futuro, se exponen casos de uso deseables. particular que se pueden implementar a partir del este, y se culmina con un resumen y la conclusión del presente trabajo. Si bien las características deseables en un sistema de HCE son bien conocidas, los desarrollos actuales siguen tendiendo a 1
  • 2. Historia Clínica Electrónica Los roles involucrados en el framework son: La Historia Clínica puede verse como una serie de documentos, • Profesional de la salud ordenados cronológicamente, donde uno o más miembros del • Profesional informático equipo de salud registran diversos datos, enmarcados en actos • Experto en el dominio clínicos, y referentes a un determinado paciente. La analogía al mundo informático se puede ver en que el papel se transforma Actualmente el profesional de la salud es parte del desarrollo de en un conjunto de formularios a llenar en pantalla, también en los sistemas de información clínica, participando como experto el contexto de un acto clínico y para un determinado paciente. en el dominio y como usuario del sistema informático resultado del desarrollo. En el enfoque actual los profesionales participan Dentro de una HCE los datos clínicos pueden ser almacenados de forma pasiva en la representación del conocimiento clínico de dos formas, mediante un repositorio de datos clínicos o un que será vertido en el sistema informático resultante, ya que son repositorio documental. En un repositorio de datos clínicos, se los profesionales informáticos quienes extraen el conocimiento almacenan los datos que generan y utilizan los distintos de los profesionales de la salud, y estos lo analizan y modelan sistemas informáticos que componen la HCE, es decir, son en términos informáticos. El enfoque de este trabajo es que el bases de datos operativas que sirven también para alimentar a profesional de la salud debe tener una participación activa en el otros sistemas, como los de soporte a las decisiones clínicas o modelado del conocimiento clínico, ya que él es el experto en gerenciales, sistemas para realizar estudios epidemiológicos, dicho dominio, aunque no todo profesional de la salud puede etc. En un repositorio documental, en lugar de contar con llevar a cabo esta tarea. Por lo tanto, se propone crear un nuevo registros en una base de datos, se tiene un conjunto de rol llamado “experto en el dominio”, el cual debe ser documentos que contienen datos clínicos de un paciente y el desempeñado por un profesional de la salud que a su vez esté contexto en el cual se obtuvieron. Al igual que los documentos capacitado en la utilización de herramientas que le permitan en papel son organizados en carpetas, los documentos clínicos especificar el conocimiento clínico en algún formato que pueda electrónicos pueden ser organizados en carpetas o directorios ser procesable de manera automática por una computadora. 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 Como el profesional informático no es experto en el dominio de que los profesionales utilizan una HCE no afectará su trabajo la salud, en el enfoque actual de desarrollo se corren riesgos de cotidiano por la familiaridad en el manejo de carpetas y mala interpretación del conocimiento clínico durante el análisis documentos. Este trabajo sigue el enfoque de repositorio informático, lo que puede provocar desfasajes en los tiempos documental, sin embargo los conceptos expuestos pueden ser planificados del proyecto, por tener que corregir una y otra vez aplicados para contar también con un repositorio de datos el análisis erróneo, siendo estos costos mayores a medida que clínicos. 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 Marco de trabajo propuesto pensaron que se estaba construyendo. Entonces se plantea que permitiendo que los mismos profesionales de la salud Se propone un marco de trabajo o “framework” para la especifiquen el conocimiento que manejan a diario, disminuye implementación de un sistema informático orientado a la la probabilidad de rechazo por sus pares o de fracaso del gestión del conocimiento clínico, formado por roles con tareas proyecto por exceso en el consumo de recursos o porque el bien definidas, artefactos en forma de insumos y productos del producto logrado no es el correcto. framework y un conjunto de servicios que este ofrece. Entonces la especificación del conocimiento clínico debe ser Este framework está orientado a la gestión del conocimiento, a llevada a cabo por el experto en el dominio, mientras que el diferencia de los desarrollos actuales que se centran profesional informático pasa de tener que realizar esta tarea, principalmente en la gestión de los datos. Actualmente se que está fuera de su dominio de conocimiento, a concentrarse utiliza mucho tiempo en la resolución de problemas rutinarios a en crear y mejorar componentes de software que permitan nivel de cómo se almacenan los datos en bases de datos o de utilizar de mejor forma el conocimiento clínico especificado presentación de los formularios a ser completados por los por el experto. Aplicando el principio de división del trabajo de usuarios. Estos temas no agregan valor a un sistema de Historia Taylor, podemos plantear la hipótesis de que separando las Clínica Electrónica, donde es necesario resolver problemas de tareas de definición del conocimiento y mantenimiento del más alto nivel y que sin inherentes al complejo dominio de la sistema informático, se optimizan los tiempos de salud. En el enfoque de este trabajo, los problemas a resolver implementación y se mejora la calidad de la Historia Clínica son los de modelado del conocimiento y procesamiento de ese Electrónica resultante. Del mismo modo que se separan estos conocimiento para generar automáticamente tanto la parte de roles y sus tareas, a nivel conceptual el sistema informático almacenamiento de la información, cómo la de presentación de resultante se separa en dos capas, una de conocimiento clínico y los formularios a ser completados por los profesionales de la la otra del sistema de información, y el nexo entre estas capas salud. 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
  • 3. Los productos de salida del framework son, por un lado, los más específicamente los expertos del dominio clínico, definan formularios electrónicos que componen la HCE, los cuales qué conceptos clínicos desean manejar y cual será la serán completados por profesionales de la salud en un acto información necesaria de ser registrada para cada tipo de acto clínico para un paciente determinado, y por otro lado, los médico. Estos conceptos pueden estar adaptados a la realidad documentos clínicos generados a partir de los datos que de la institución donde se quiera implementar la HCE, registran los miembros del equipo de salud. considerando sus necesidades particulares. A partir de las plantillas definidas, “miniClin” genera automáticamente el El framework debe ofrecer tres servicios básicos: formulario a ser llenado por el profesional en algún acto médico, y luego con esa información se genera un documento • Almacenamiento clínico CDA para un determinado paciente en dicho acto • Visualización médico. Luego, los documentos clínicos contenidos en el • Comunicación repositorio documental podrán ser vistos por otros miembros del equipo de salud, podrán ser comunicados a otros sistemas, Anteriormente se mencionó que este trabajo está basado en el podrán ser almacenados en medios ópticos o magnéticos, etc. enfoque de repositorio documental como método de Una característica de los documentos clínicos basados en XML almacenamiento de información clínica, sin embargo dicho [8], como es el caso de CDA, es que son fáciles de firmar almacenamiento puede realizarse en diversos medios. El digitalmente, lo que podrá garantizar la integridad y la autoría servicio de almacenamiento deberá proveer la capacidad de de cada documento. El esquema general del framework, que almacenar los documentos clínicos que sean generados por el muestra los elementos recién comentados puede verse en la equipo de salud, ya sea en la computadora personal de un figura 1. médico, una computadora local en un determinado sector de atención, en un servidor institucional centralizado, en un CD, Para poder implementar el framework propuesto fue necesario DVD, un pendrive, en dispositivos móviles, entre otros. definir algunos elementos, los cuales fueron escogidos pensando en las características deseables de las Historias El servicio de visualización debe ofrecer la capacidad de Clínicas Electrónicas que se implementarán sobre este. 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 Fig. 1: Esquema general del framework “miniClin” un componente de software llamado “miniClin”, el cual no es una Historia Clínica Electrónica, si no que es un framework Los elementos seleccionados fueron: general para implementar cualquier HCE basándose en el concepto de gestión del conocimiento clínico. Por lo tanto • Modelo de información para representar documentos “miniClin” no determina que información será ingresada por clínicos electrónicos. los profesionales de la salud para generar los documentos • Formato y sintaxis para especificación de clínicos, si no que permite que los profesionales de la salud, conocimiento clínico. • Tecnologías sobre las cuales desarrollar el framework. 3
  • 4. El modelo de información fue seleccionado considerando conocimiento clínico está basado en el estándar XML [8], principalmente características de estandarización y simplicidad, mediante la utilización de una sintaxis particular la cual es uno para poder garantizar una rápida implementación del de los resultados del presente trabajo. Más adelante se darán framework, por estos motivos fue seleccionado el estándar ejemplos de aplicación de esta sintaxis. CDA (Clinical Document Architecture) [4][5]. Dentro del conjunto de estándares HL7 [6] dedicados a la normalización Las tecnologías fueron seleccionadas por ser livianas y de la información en el ámbito de la salud, CDA es el estándar multiplataforma, por lo que “miniClin” no requiere de grandes propuesto para el modelado de cualquier documento clínico prestaciones de hardware para funcionar correctamente, por lo para el intercambio de información entre sistemas. Aunque este que cualquier computadora de escritorio puede transformarse es el objetivo con el cual CDA fue concebido, “...la comunidad en un sistema de HCE completo. La implementación de la de usuarios de CDA ha tendido a usarlo más como una prueba de concepto del framework “miniClin” se realizó especificación de persistencia.” [7]. principalmente utilizando Yupp PHP Framework [9], un framework de uso general para el desarrollo de aplicaciones Si bien CDA es más que suficiente para una primera web basadas en el lenguaje de programación PHP [10]. Cómo implementación, la elección del modelo de información clínica solución de persistencia del repositorio documental se realizó debería realizarse en función de las necesidades particulares del un híbrido entre documentos almacenados en el sistema de sistema de HCE de cada institución. Más adelante se propone archivos de una computadora e índices en una base de datos una discusión sobre qué modelos de información se podrían que permiten buscar documentos clínicos mediante criterios elegir como alternativa a CDA de ser necesario. determinados, como por ejemplo la fecha de creación del documento, el paciente para el cual se crea el documento, el El repositorio documental propuesto, y toda la información profesional que crea el documento, entre otros. Como solución clínica contenida en este, cumple con el estándar CDA con de base de datos relacional fue utilizado MySQL [11]. todas las ventajas que esto tiene para la HCE resultante. Discusión sobre modelos de información Características deseables que se tienen desde el inicio: El modelo de información CDA fue el elegido para representar • La información contenida en el documento clínico, los documentos clínicos que serán generados por el framework que es parte de la Historia Clínica Electrónica de un propuesto, esta elección se debió a su gran simplicidad y a que paciente, es legible por una persona. es un modelo estándar. Ahora, la pregunta que surge es: • Los documentos clínicos electrónicos pueden ser ¿alcanza con CDA para modelar cualquier HCE completa? La intercambiados entre sistemas (interoperabilidad respuesta no es independiente del contexto, es decir que sintáctica) y los sistemas pueden utilizar la depende de hasta qué nivel de implementación quiera llegar la información intercambiada (interoperabilidad institución prestadora de servicios de salud y de cuales son sus semántica). necesidades particulares en el modelado de información clínica. • CDA permite definir permisos de visualización, estableciendo la capacidad de que la información que Si por cada acto médico que se realice sobre un paciente se contiene el documento sea vista solo por quienes generara un documento CDA que contenga toda la información tienen privilegios suficientes para verla. clínica generada en dicho acto, y que a su vez contenga toda la • Incluye información de contexto básica que es útil información de contexto, se contaría con una HCE completa y para determinar en qué ámbito fue generado el única para cada paciente. La información de contexto documento. considerada como necesaria de registrar se debería definir a • Un documento clínico electrónico puede ser guardado priori para cada institución. en un Pen Drive, CD, DVD o ser enviado por email. Claramente, si se llegara a una instancia donde para representar alguna información particular se debe forzar el modelo También fue necesario definir la forma en la que el experto en saliéndose del estándar, estaríamos en presencia de una el dominio debe especificar el conocimiento clínico para limitación del mismo, por lo que se debería optar por otro alimentar con este al framework, lo cual es necesario para que modelo de información clínica que contemple el caso en el conocimiento clínico pueda ser procesado automáticamente cuestión sin salirse del estándar. Para la realización de la por una computadora. El conocimiento clínico deberá ser implementación de prueba de concepto en este trabajo, el especificado en un sistema informático como una estructura de modelo CDA fue más que suficiente. conceptos clínicos, los cuales están formados datos y restricciones que estos datos deben cumplir. Por ejemplo, un Existen algunas alternativas a CDA para el modelado de concepto clínico es la “presión arterial”, la cual está formada a documentos clínicos, por ejemplo el modelo de referencia del su vez por la “presión sistólica” y la “presión diastólica”. A su estándar CEN/ISO 13606 [12][13] o el modelo de referencia vez, ambas presiones se miden mmHg (milímetros de del estándar abierto OpenEHR [14]. 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 El estándar CEN/ISO 13606 fue concebido como una solución (si es que hay presión). El formato de especificación del para el intercambio de mensajes que contengan información clínica entre instituciones o sistemas, su modelo es sencillo e 4
  • 5. intenta emular electrónicamente la organización de los • ¿Qué tan compleja es la realidad particular que se registros en papel. En la figura 2 se muestran los bloques necesita modelar? lógicos que componen este modelo. • ¿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 Fig. 2: Bloques lógicos del modelo CEN/ISO 13606 [13] trabajo es la definición de una sintaxis capaz de representar el conocimiento médico para que una computadora lo pueda Existe una correspondencia entre el modelo de ISO 13606 y procesar de forma automática. Esta representación tomará el CDA, por lo que un sistema que implemente un modelo, nombre de plantilla CDA, ya que permite definir la forma que fácilmente puede interoperar con sistemas que implementen el tendrán los documentos clínicos CDA que formarán parte del otro [7]. repositorio documental de la HCE. OpenEHR partió del modelo de ISO 13606 y lo extendió para cumplir los requerimientos de una arquitectura genérica y Algunos ejemplos de estos documentos podrían ser: completa para implementar una Historia Clínica Electrónica longitudinal que pueda soportar los cambios en la tecnología a • Historia clínica de emergencia general través del tiempo, manteniendo la semántica de la información • Historia clínica de emergencia de trauma registrada. El gran aporte de OpenEHR son los arquetipos, los • Historia clínica de CTI cuales permiten especificar el conocimiento clínico dentro de • Historia clínica ambulatoria un sistema informático, este conocimiento puede utilizarse para • Historia clínica de internación domiciliaria que los sistemas interoperen de forma semántica a nivel de • Descripción operatoria conceptos clínicos [15]. También proponen una sintaxis para • Resumen de historia clínica definir arquetipos llamada Archetype Definition Language • Resumen de internación (ADL) [16], con la gran ventaja de que es genérica, y capaz de • Indicaciones terapéuticas ser utilizada para definir arquetipos sobre otros modelos de • Anotaciones de enfermería referencia aparte del modelo de OpenEHR, incluso permite definir arquetipos sobre los modelos CEN/ISO 13606 y CDA • Evaluación clínica [17]. • Evolución de signos vitales • Solicitud de exámenes de laboratorio Si bien el modelo de referencia de OpenEHR especifica gran • Resultados de exámenes de laboratorio cantidad de conceptos clínicos, también mantiene un gran nivel • Solicitud de exámenes imagenológicos de generalidad, de modo de poder aplicarlo en distintos • Informe de radiología (puede incluir imágenes) contextos dentro del dominio de la Informática Médica, por lo • y más... que es altamente flexible en su aplicación específica. Esta abundancia de conceptos pueden generar dudas sobre la La sintaxis propuesta para las plantillas CDA está basada en el posibilidad de aplicación del modelo a un caso concreto, estándar XML. Esta sintaxis fue concebida a partir de la debido a su complejidad, pero considerando la alta complejidad estructura de un documento clínico CDA a la cual se agregaron de la realidad médica, podemos intuir que cuanto más algunos conceptos presentes en los arquetipos de OpenEHR fielmente se represente esa realidad, más complejo debería ser [18][19][20]. Dicha sintaxis se centra en la estructura de el modelo. Esta visión ahora generaría dudas sobre los modelos secciones y entradas de CDA, donde la información clínica se inherentemente simples, donde por ejemplo, un experto puede estructura en secciones y se define mediante entradas. Las verse tentado a violar el estándar para resolver un caso entradas que pueden especificarse en una plantilla son del particular, sin pensar en las consecuencias que eso puede traer mismo tipo que las entradas que se definen en el estándar CDA: 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 • Observation son: • RegionOfInterest • ObservationMedia 5
  • 6. • SubstanceAdministration Ejemplo 2: definición de sección de presión arterial • Supply • Procedure <section> <title>Presión arterial</title> • Encounter <entries> • Act <observation> <code code="251076008" codeSystem="2.16.840.1.113883.6.96" El conocimiento clínico es especificado en forma de plantillas codeSystemName="SNOMED CT" CDA por el experto en el dominio, esta especificación se displayName="Presión de sangre"/> realiza mediante la definición de los conceptos clínicos que <entries> <observation> formen parte de la HCE que se está implementando en un <code code="271649006" sector o una institución particular. Los conceptos clínicos se codeSystem="2.16.840.1.113883.6.96" especifican mediante su estructura, sus datos y restricciones codeSystemName="SNOMED CT" sobre estos datos. displayName="Sistólica"/> <value type="PQ"> <value> Para la implementación de una HCE completa dentro de una <range min="0" max="30" /> institución, no es necesario crear a priori todas las plantillas </value> que se requerirán, en su lugar es posible crear la HCE completa <unit> <regexp>mm[Hg]</regexp> de forma iterativa e incremental, es decir que el framework </unit> permite comenzar a trabajar con pocas plantillas con la </value> posibilidad de crear nuevas plantillas y de modificar las </observation> <observation> plantillas actuales, sin la necesidad de bajar el sistema, y lo <code code="271650006" más importante aún, que los documentos clínicos ya creados en codeSystem="2.16.840.1.113883.6.96" la HCE siguen siendo válidos. Por esta razón se podrá agregar codeSystemName="SNOMED CT" indefinidamente conocimiento clínico a la aplicación, y displayName="Diastólica"/> <value type="PQ"> perfeccionar el conocimiento actual, sin necesidad de modificar <value> las bases de datos ni la interfaz de usuario porque estas se <range min="0" max="30" /> generan automáticamente a partir del nuevo conocimiento </value> vertido al framework. <unit> <regexp>mm[Hg]</regexp> </unit> A continuación se presentan dos ejemplos de aplicación de la </value> sintaxis propuesta. El ejemplo 1 especifica una sección donde </observation> </entries> se define el concepto de imagen, esta imagen puede ser </observation> obtenida por un médico, mediante una cámara digital, y luego </entries> adjuntada a la HCE del paciente, o podría ser una imagen </section> 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 Las plantillas permiten la definición de restricciones sobre los restricciones sobre las magnitudes medidas y las unidades de datos a registrar en la HCE. En el ejemplo 2 se definen medición. restricciones sobre los rangos de valores posibles en las magnitudes medidas para presiones sistólica y diastólica, en Ejemplo 1: definición de sección de exámenes imagenológicos este caso e mínimo valor es 0 y el máximo 30. Tanto los conceptos que se deben especificar mediante las plantillas, <section> como las restricciones sobre los datos, son parte del <title>Imágenes</title> conocimiento médico, no es conocimiento informático. <entries> <observationMedia occurrences="0..*"> <value mandatory="true"> Tipos básicos de restricciones que se pueden definir: <value> <regexp>*</regexp> </value> • listado: el valor debe ser una de las opciones dadas. <mediaType hidden="true"> • rango: el valor debe estar en el rango especificado. <list> <item>image/jpeg</item> • expresión regular: el valor debe corresponder con la <item>image/gif</item> expresión regular dada, * significa que no hay </list> restricción en cuanto a la forma del valor. </mediaType> <charset hidden="true"> <regexp>base64</regexp> </charset> Estas plantillas serán el principal insumo de “miniClin”, donde </value> se utilizan para generar los formularios electrónicos que serán </observationMedia> completados por los profesionales de la salud con datos clínicos </entries> de sus pacientes, y a partir de estos datos y de las mismas </section> plantillas se genera un nuevo documento clínico que se almacena en el repositorio documental CDA. 6
  • 7. Proceso de creación de documentos clínicos Cuando el profesional termina de ingresar los datos, estos se guardan en forma de un documento clínico en formato CDA. Cuando un profesional de la salud ingresa a “miniClin”, debe Como se comentó anteriormente, el almacenamiento de los seleccionar qué tipo de documento clínico desea crear. Las documentos estará dado por el servicio de almacenamiento, y opciones posibles son todas las plantillas que se hayan creado puede ser un repositorio en la computadora personal de un previamente. La selección de una plantilla entre las disponibles médico, en una computadora local a un sector de atención, o se muestra en la figura 3, donde se organizan por sector de un repositorio institucional centralizado. O también podrá atención. 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 Fig. 3: Selección de plantilla CDA 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 Cuando se selecciona el tipo de documento, “miniClin” genera confidencialidad. El nivel de confidencialidad de un automáticamente un formulario web para que el profesional determinado documento puede ser definido en la plantilla que pueda registrar la información necesaria. Un ejemplo de lo especifique. Esta sería la primera aproximación de seguridad formulario generado se muestra en la figura 4. 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 Fig. 4: Formulario generado a partir de plantilla CDA estándar hoy en día para representar este tipo de conocimiento 7
  • 8. son las herramientas de Workflow o herramientas de Business Comunicación interinstitucional Process Management (BPM). Si bien el repositorio documental donde se almacenan los documentos clínicos debe ubicarse a nivel personal (por Integración con PACS 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 Con el advenimiento de los exámenes radiológicos digitales y institucional centralizado), muchas veces es necesaria la los PACS (Picture Archiving and Communication System) la comunicación entre sistemas mediante el intercambio de integración con los sistemas de Historia Clínica Electrónica es documentos clínicos. De esta comunicación se debe encargar el sumamente necesaria, ya que agilita el proceso de orden de un servicio de comunicación de las instituciones que participan del estudio, realización del estudio, realización del informe por un intercambio. La base para que los sistemas de ambas radiólogo y la posterior devolución al médico que realizó la instituciones puedan “entender” estos mensajes que se orden. Esa disminución en el tiempo de atención el paciente la intercambian es que las instituciones compartan las plantillas percibe como una mejora en la calidad de atención. Para mediante las cuales se generaron los documentos, ya que estas realizar esta integración, se podrían definir en “miniClin” las contienen el conocimiento necesario para procesar los plantillas para las órdenes de exámenes imagenológicos y la conceptos contenidos en un documento clínico. Es decir, que plantilla de reporte de radiología, la cual podría generar para cualquier intercambio es necesario acceder a la plantilla documentos clínicos que además del propio reporte contengan que generó el documento, esto se realiza publicando las algunas imágenes seleccionadas por el médico radiólogo. Por plantillas disponibles mediante un servicio web. Por otro lado, otro lado, al servicio de visualización de documentos clínicos cada documento generado contiene la información de que se le podría agregar un componente de acceso a imágenes plantilla se utilizó para generarlo. directamente desde el PACS, y cualquier médico podría ver desde cualquier computadora los exámenes imagenológicos de sus pacientes. Resumen y conclusión Herramienta para definición del conocimiento clínico En el presente trabajo se propuso un marco de trabajo que propone una metodología para la definición de algunos puntos Una de las extensiones que agregarían más valor a la tarea del cruciales en toda implementación de un sistema de Historia experto en el dominio, es el uso de una herramienta que Clínica Electrónica. Estos elementos son: el modelo de permita especificar de forma gráfica el conocimiento clínico. información a utilizar, forma de especificar el conocimiento Esta herramienta se puede crear para ajustarse a las necesidades clínico y las tecnologías para desarrollar el sistema. También de las plantillas CDA propuestas, y podrá permitir que el plantea la necesidad de roles con tareas bien definidas: el experto acceda a la herramienta vía web. También existen profesional de la salud, el profesional informático y el experto algunas herramientas para realizar esta tarea, sobre todo en el en el dominio clínico. ámbito de la definición de arquetipos OpenEHR y CEN/ISO 13606, como por ejemplo el Ocean Archetype Editor [21], LiU Se logra una implementación particular de este marco de Archetype Editor [22] o LinkEHR ED [17]. Los expertos en el trabajo, en donde se muestran las bondades y posibilidades del dominio deberían ser usuarios expertos de este tipo de marco planteado. Esta implementación, llamada “miniClin”, herramientas. 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, Casos de uso generalidad, flexibilidad, accesibilidad, bajo costo de implementación, bajas necesidades en infraestructura, Historia clínica personal para viajes perdurables en el tiempo e independientes al cambio de la tecnología. El marco permite la informatización gradual los Una posible aplicación del framework propuesto es generar una distintos registros generados en la atención médica. Para lograr plantilla para el resumen de Historia Clínica de un paciente. esta implementación fue necesario proponer una sintaxis para Los documentos clínicos generados como resumen de HC, a representar el conocimiento clínico en forma de plantillas CDA. través del servicio de almacenamiento, pueden ser almacenados en un pendrive o un teléfono celular. Este resumen puede Al seleccionar el modelo estándar de información clínica incluir cualquier dato clínico como últimas medicaciones, CDA y utilizar plantillas para representar el conocimiento enfermedades crónicas, últimas enfermedades, alergias a clínico, se garantiza la interoperabilidad semántica con otros medicamentos, e inclusive imágenes obtenidas en exámenes de sistemas. Mediante estas plantillas de uso genérico es posible radiología digitales. Luego los pacientes que se vayan de viaje definir nuevos conceptos dentro del marco de trabajo que se llevarán este resumen en un pendrive o un teléfono celular, y agregarán a la HCE, aún cuando el sistema de HCE ya esté en caso de necesitar atención médica, los profesionales siendo utilizado por el equipo de salud. Por lo que se obtiene contarán con este resumen como entrada para lograr una mejor gran flexibilidad, por que el nuevo conocimiento es asimilado atención de ese paciente. Este podría ser un nuevo producto o inmediatamente por la aplicación informática. Esto permite que servicio que se ofrece a los socios de una mutualista o el sistema pueda extenderse y perfeccionarse indefinidamente. emergencia móvil. 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 [9] Yupp PHP Framework documentos CDA que se almacenarán en el repositorio http://www.simplewebportal.net/host/1018.htm documental, tanto el conocimiento como los datos clínicos son independientes del cambio en la tecnología, ya que pueden [10] PHP (Hypertext Preprocessor) ser consumidos por cualquier tecnología futura. http://www.php.net/ El contar con un Experto en el Dominio trabajando en paralelo [11] MySQL con el profesional informático, cada uno en su campo de http://www.mysql.com/ experticia, permite que ambos puedan trabajar más rápido porque no hay curva de aprendizaje de un nuevo conocimiento, [12] Electronic health record communication -- Part 1: optimizando los recursos disponibles y disminuyendo los Reference model http://www.iso.org/iso/catalogue_detail.htm?csnumber=40784 costos de implementación del sistema. La implementación utilizando tecnologías web livianas, [13] La semántica en la Historia Clínica, Adolfo Muñoz garantiza la accesibilidad al sistema desde cualquier lugar, en Carrero http://www.msc.es/organizacion/sns/planCalidadSNS/docs/MUNOZ_ cualquier momento, posibilitando el que la aplicación pueda CARRERO.pdf correr en una computadora de escritorio, o incluso en un dispositivo móvil, por no necesitar de grandes prestaciones de [14] OpenEHR, future-proof and flexible hardware, bajando costos en infraestructura. http://www.openehr.org/home.html Por último, el conocimiento volcado al framework, si bien la [15] Sebastian GARDE, Rong CHEN, Heather propuesta de este trabajo es utilizarlo para generar el sistema de LESLIE,Thomas BEALE, Ian McNICOLL, Sam HEARD, información clínico, puede ser utilizado con otros fines, los Archetype-Based Knowledge Management for Semantic usos a futuro de este conocimiento podrían ir desde la Interoperability of Electronic Health Records realización automática de análisis en la información contenida http://www.hst.aau.dk/~ska/MIE2009/papers/MIE2009p1007.pdf en la base de datos, hasta la generación automática de conocimiento derivado, por ejemplo el encontrar relación entre [16] Archetype Definition Language dos conceptos hasta ahora disjuntos. http://www.openehr.org/120-OE.html [17] LinkEHR ED, Editor de arquetipos genérico Referencias http://www.linkehr.com/ [1] What is the cost of a requirement error?, Tom King, [18] Archetypes for HL7 CDA documents, Eric Browne, HL7 Ravenflow Australia. http://www.stickyminds.com/pop_print.asp?ObjectId=12529&Object http://www.openehr.org/wiki/download/attachments/3440870/Archety Type=ART pes_in_CDA_4.pdf [2] Developing Functional Requirements for ITS Projects, [19] HL7 CDA, Clinical Modelling and openEHR, Thomas Mitretek Systems, Inc. Beale, NHS Scotland http://www.itsdocs.fhwa.dot.gov/jpodocs/repts_te/13621.html http://www.isdscotland.org/isd/servlet/FileBuffer?namedFile=tom%20 beale.pdf&pContentDispositionType=inline [3] IHE Cross-Enterprise Document Sharing (XDS) http://www.ihe.net/Profiles/index.cfm#IT [20] Preliminary Work on Building a User Friendly Adaptive Clinical Documents Repository, Enriko Aryanto, Yang Huang, [4] CDA, HL7book Standford University http://hl7book.net/index.php?title=CDA [21] Ocean Archetype Editor [5] Robert H. Dolin, MD, Liora Alschuler, HL7 Clinical https://wiki.oceaninformatics.com/confluence/display/TTL/Archetype Document Architecture, Release 2 +Editor+Releases http://www.jamia.org/cgi/content/full/13/1/30 [22] LiU Archetype Editor, Mattias Forss, Eric Sundvall, [6] Health Level Seven, Inc http://www.hl7.org/ Mikael Nyström, Institutionen för medicinsk teknik, Linköpings universitet http://www.imt.liu.se/mi/ehr/ [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/CAPITU LO7_0.pdf Contacto Pablo Pazos Gutiérrez [8] Extensible Markup Language email: pablo.swp@gmail.com http://www.w3.org/XML/ 9