Trabajo de investigación sobre el desarrollo

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