Download Especial: La Informática de la Salud en Europa

I+S - 68 ABRIL'08
3/4/08 15:32
Página 17
Especial: La Informática de la Salud en Europa
Los estándares en Sistemas
de Información Sanitarios en
Europa: la visión de IHE
Interoperabilidad historia clínica electrónica
Paula de Toledo1, José Carmelo Albillos2, Javier Quiles3
1. Universidad Carlos III de Madrid. Departamento de Informática.
2. Hospital Infanta Sofía. Servicio de Radiodiagnóstico. Unidad Central de Radiodiagnóstico de la Comunidad de Madrid.
3. Subdirección de Información y Servicios Tecnológicos. Consellería de Sanidade, Xunta de Galicia
RESUMEN
Integrating the Healthcare Enterprise (IHE) es una organización cuyo objetivo es promover la adopción coordinada de estándares para ofrecer soluciones a problemas de interoperabilidad en equipos y sistemas de
información para la salud. De los diferentes dominios
abordados por IHE, la interoperabilidad de la Historia
Clínica Electrónica es de mayor repercusión potencial
en el ámbito Europeo, como paso imprescindible para
garantizar el objetivo de una atención sanitaria transnacional dentro de los países de la Unión. IHE propone
el perfil de integración 'Compartir documentos entre
organizaciones' (Cross-enterprise document sharing,
XDS) como primera aproximación hacia la Historia
Clínica interoperable. Esta especificación está basada
en un modelo registro / repositorio (concretamente
ebXML) en el que se comparten documentos clínicos de
diferente tipo. Dichos documentos deben ser conformes
a la norma CDA de HL7 lo que permite integrar desde
documentos escaneados procedentes de papel, hasta
documentos CDA nivel 3, alcanzándose en este último
caso un alto grado de interoperabilidad semántica. El
perfil XDS utiliza otras especificaciones de IHE para resolver aspectos como la identificación cruzada de pacientes, la autenticación de nodos o el registro de eventos
para auditoría. En lo que respecta al contenido de los
documentos clínicos, IHE ha trabajado en la especificación de la estructura básica de diferentes documentos, como los informes de alta o derivación (perfil
'Resúmenes médicos' XDS-MS). Próximamente se prevé
la creación de un grupo de trabajo en IHE Europa que
estudie los aspectos de interés específico para Europa
en lo que a respecta a resúmenes médicos.
PALABRAS CLAVE
Interoperabilidad, Historia Clínica Electrónica, Estándares, Integrating the healthcare enterprise (IHE), Clinical Document
Arquitecture (CDA)
INTRODUCCIÓN
La atención sanitaria a la población se ha convertido en
un objetivo prioritario en la sociedad actual y a ella se
dedican gran cantidad de recursos, tanto humanos
como materiales. Todo ello en su doble vertiente: la
cobertura para la promoción de la salud y la asistencia
en caso de enfermedad. Las organizaciones sanitarias
emplean a personal cada vez mejor formado, y también abundantes medios tecnológicos que facilitan su
trabajo.
En este contexto, la interoperabilidad entre los diferentes sistemas de información y otros equipos (electromedicina,..) utilizados en la atención de la salud de los
ciudadanos es reconocida unánimemente como una
de las claves para aumentar la calidad de dicha atención. En unas organizaciones sanitarias donde la automatización y digitalización es cada día mayor, la integración de todos los sistemas ofrece innumerables ventajas a todos los actores implicados. Por un lado, mejorando la atención a los pacientes, facilitando el trabajo
de los profesionales y permitiéndoles desarrollarlo con
17
I+S - 68 ABRIL'08
3/4/08 15:33
Página 18
Especial: La Informática de la Salud en Europa
mayor calidad al tomar sus decisiones disponiendo de
toda la información necesaria. Por otro, reduciendo los
costes que esta atención supone para la sociedad en su
conjunto.
El término “interoperabilidad” no está recogido en la
última actualización (Octubre 2007) del diccionario de
la Real Academia Española de la Lengua pero se utiliza como traducción directa de la palabra anglosajona
“interoperability”, cuya definición de acuerdo con a
asociación americana IEEE [1] es la siguiente: “La capacidad de dos o más sistemas o componentes para intercambiar información y utilizar la información que ha
sido intercambiada”.
En el momento actual, después de muchos años de trabajo en este campo, se puede decir que las organizaciones sanitarias han alcanzado un grado de desarrollo
considerable de sus sistemas, y en algunos casos una
aceptable interoperabilidad dentro de un mismo centro
(hospital, ..). Podemos considerar que estamos entonces en condiciones de afrontar el siguiente gran reto:
alcanzar la interoperabilidad entre los sistemas de distintas organizaciones que operan en un mismo ámbito
regional, nacional o supranacional.
En este artículo vamos a presentar el enfoque de IHE en
lo que respecta a la interoperabilidad de sistemas de
información sanitarios, centrándonos por su gran repercusión en el ámbito Europeo, en la Historia Clínica
Electrónica (HCE) como paso imprescindible para garantizar la atención sanitaria transnacional y por consiguiente el derecho a la libre circulación de personas
dentro de los países de la Unión.
1. IHE: INTEGRATING THE HEALTHCARE ENTERPRISE.
18
IHE es una organización sin ánimo de lucro, participada
por empresas, sociedades científicas, administraciones,
hospitales y usuarios en general, cuyo objetivo es desarrollar y promover la adopción coordinada de estándares ya existentes, para ofrecer soluciones a los problemas de interoperabilidad en el ámbito de la salud.
Para los lectores que no estén familiarizados con el proceso de creación de especificaciones de IHE y la terminología utilizada, se ofrece a continuación un breve
resumen. Se puede encontrar una descripción más
detallada en castellano en [1].
Los Marcos Técnicos de IHE son documentos de especificación que proponen formas concretas de utilizar uno o
varios estándares para acometer en el corto plazo objetivos de interoperabilidad identificados por los profesionales sanitarios en dominios de aplicación concretos.
El perfil de integración es el elemento básico de definición de un escenario de interoperabilidad de IHE. Un
Marco Técnico puede describir uno o más perfiles de
integración. Para cada perfil, se especifica la forma de
interactuar de los distintos sistemas que participan en
un escenario dado. El perfil comienza con una identificación de los roles de los diferentes sistemas implicados,
a los que se denomina actores. Posteriormente define
los diferentes intercambios de información (transacciones) entre dichos actores, utilizando estándares ya existentes, fundamentalmente HL7, Dicom y estándares del
W3C como SOAP. Los perfiles de integración y todas las
especificaciones de IHE son siempre públicas y se recogen en el Marco Técnico. Las empresas del sector aplican los perfiles definidos en el mismo a sus productos.
Anualmente se celebra un evento, denominado
Connectathon, en el que estas empresas se reúnen y
prueban de manera conjunta y en un entorno casi-real
la interoperabilidad de sus sistemas. En el Connectathon europeo de 2007 participaron 72 empresas con
120 productos.
IHE contempla las particularidades de cada territorio a
la hora de la estandarización mediante las extensiones
nacionales de cada marco técnico, que contienen
aspectos específicos de cada país. La extensión
nacional española del Marco Técnico de radiología contempla aspectos como el uso de un segundo apellido o
los identificadores más comunes en nuestro país.
Los perfiles de IHE se agrupan en torno a diferentes
dominios clínicos, como son Radiología, Cardiología,
Laboratorio, Anatomía Patológica, Salud Ocular y
Radioterapia Oncológica, además de otros dominios
que podríamos denominar transversales, entre los que
destacan las Infraestructuras de Tecnologías de la información, la Atención Coordinada al Paciente, la
Calidad, y los Dispositivos de Monitorización.
2. HE Y EL RESUMEN DE HISTORIA CLÍNICA COMPARTIDA EN EUROPA
De los diferentes enfoques posibles a la creación de una
historia clínica electrónica interoperable, IHE ha tomado
la decisión de comenzar con una aproximación basada
en documentos y orientada a compartir información en
un ámbito organizativo concreto. Como ocurre con
todas las especificaciones de IHE, se trabaja con estándares existentes y estables para que pueda ser implementada inmediatamente.
2.1. Orientación a documentos
El flujo de trabajo convencional (no digital) del intercambio de información médica entre profesionales se
organiza normalmente en forma de documentos. Estos
documentos reúnen unidades básicas de información
I+S - 68 ABRIL'08
3/4/08 15:33
Página 19
Especial: La Informática de la Salud en Europa
de diferentes tipos como datos demográficos de
paciente, anamnesis, exploración clínica, evolución,
informes de pruebas complementarias, diagnósticos,
tratamiento y recomendaciones y autor del documento
para formar con ellas un documento complejo como
puede ser un informe de alta. Esta organización tradicional de la información no viene dada sólo por el
modo usual de intercambiarla (correo postal,..), sino
también por los requisitos médico-legales: alguien tiene
que asumir la responsabilidad legal sobre un documento, normalmente firmándolo. Frente a esta organización está la de los sistemas de información sanitarios,
que suelen almacenar la información en una base de
datos estructurada, donde cada unidad básica de información se mantiene de forma independiente.
porque los estándares necesarios ya son muy estables y
por otro por la similitud con el escenario habitual de la
historia clínica en papel, ya basada en documentos.
Este paralelismo facilita la transición, no en el aspecto
técnico, sino el organizativo que es la verdadera barrera hacia una historia de salud accesible sin comprometer su confidencialidad.
Al igual que otras normas en el área de la historia clínica electrónica, IHE separa la especificación del contenido (en este caso la arquitectura del documento clínico
CDA de HL7), de la forma en la que se transporta y se
comparte dicho contenido (el modelo registro/repositorio
del perfil 'Cross enterprise document sharing'). A continuación se describen cada uno de estos dos elementos.
3. LA ESTRUCTURA DEL DOCUMENTO: CDA DE HL7
2.2. El dominio de afinidad
IHE ha definido su propuesta para una historia clínica
electrónica compartida basándose en el concepto de
'dominio de afinidad' (affinity domain). Se trata del
ámbito en el que se comparte la historia, por ejemplo
una región o país, y dentro del cual las organizaciones
tienen una infraestructura de comunicaciones y seguridad, así como unas políticas de confidencialidad comunes. La necesidad de disponer de dichas políticas comunes es fácilmente comprensible si se considera que los
requisitos de acceso a un documento en la organización donde fue creado y en aquella con la que ha sido
compartido deben ser coherentes.
2.3. Principales ventajas del enfoque de IHE
La principal ventaja del enfoque elegido es que puede
ser puesto en práctica inmediatamente, por un lado
IHE ha seleccionado la norma CDA (Clinical Document
Arquitecture) Release 2 [2] de HL7 como referencia
para el contenido y arquitectura de los documentos clínicos que son compartidos. El estándar CDA está basado en el Modelo de Información de Referencia
(Reference Information Model, RIM) de HL7 y define la
arquitectura genérica de un documento clínico que se
quiere intercambiar. Utiliza XML y soporta el uso de
vocabularios controlados (SNOMED, LOINC, CIE-9-MC,..)
CDA contempla las características definitorias de un documento clínico como que es persistente por el periodo de
retención legal, que identifica la organización encargada
de su administración y custodia (stewardship), que puede
ser firmado y autenticado, que es completo, que se establece su contexto y que es legible por seres humanos.
La estructura de un documento CDA es sobradamente
19
I+S - 68 ABRIL'08
3/4/08 15:33
Página 20
Especial: La Informática de la Salud en Europa
Tabla 1. Los tres niveles de CDA
conocida (Figura 1): consta de un encabezado que proporciona información de contexto del documento y lo
identifica unívocamente, y un cuerpo que contiene la
información clínica que se desea compartir.
Entre la información contemplada en el encabezado está
el identificador único del documento (por ejemplo un OID),
el paciente al que hace referencia, el acto clínico (encounter) en el que se ha generado, los proveedores sanitarios
(profesionales y organizaciones) involucrados, el responsable legal del documento y su grado de confidencialidad.
El cuerpo está formado por diferentes componentes,
estructurados o no. Los componentes no estructurados
pueden ser texto o información en un formato estándar
determinado (pdf, jpg,..). A su vez, los componentes
estructurados están formados por secciones. Cada sección se identifica por un código que se expresa tanto en
un texto descriptivo (por ejemplo 'motivo de ingreso')
legible para una persona, como en un código tomado
de una codificación estándar ('motivo de ingreso'
29299-5 de LOINC). El contenido de cada sección debe
estar en formato texto y puede estarlo también en
20
Figura 2: Documento CDA en el Perfil Medical Summaries.
forma de entradas (entry), datos codificados que reproducen toda o parte de la información proporcionada en
con el texto y destinados a su procesado automático.
La norma CDA no especifica el contenido del documento, sino simplemente a la estructura y semántica
necesaria para su intercambio. Sin embargo, existe una
forma directa de crear normas que regulen el contenido, a partir de la generación de plantillas (templates),
que restringen la norma CDA particularizando la especificación genérica para un determinado contenido. En
función del tipo de restricciones empleadas, se suele
hablar de tres niveles de CDA (Tabla 1)
El grado de confidencialidad de un documento CDA se
establece de forma general en el encabezado, pero
también a nivel de sección, de forma que puede haber
secciones con información más sensible que tengan un
nivel de confidencialidad mayor que el resto del documento. Una plantilla estará representada por un schematron y/o una hoja de estilo XML de validación.
4. EL CONTENIDO DEL DOCUMENTO: MEDICAL
SUMMARIES
Dentro del dominio de IHE 'Atención Coordinada al
Paciente' se encuentran varios perfiles que sí especifican el contenido de determinados documentos clínicos
que van a ser compartidos. Entre estos perfiles se
encuentra el informe de atención de urgencias
(Emergency Department Encounter Record, EDER) o el
de valoración funcional (Funcional Status Assesment,
FS), pero el más significativo es el perfil 'Medical
Summaries, MS' o Resumen de Historia [3]. Este perfil
define el contenido de un resumen de Historia Clínica
del paciente, para ser consultado en aquellos momentos en los que la atención del paciente se transfiere de
un escenario a otro (como el alta hospitalaria, o la asistencia en desplazamientos o emergencias). La especificación se orienta especialmente a los informes de alta
y de derivación.
Para ello se parte del estándar CDA Release 2, que se
restringe a una codificación de nivel 3 (Tabla 1), incluyendo secciones como medicaciones, alergias y lista de
problemas. (Figura 2).
I+S - 68 ABRIL'08
3/4/08 15:33
Página 21
Especial: La Informática de la Salud en Europa
Al tratarse de un perfil muy ligado al contenido del
documento, es previsible y deseable que se publiquen
extensiones nacionales, y algunos países como Francia
ya están trabajando en ello. También está en marcha
una iniciativa dentro de IHE para generar una extensión
de ámbito europeo para este perfil.
5. EL MODELO DE REGISTRO Y REPOSITORIO: XDS
El modelo propuesto por IHE para compartir información de historia clínica electrónica está especificado en
el perfil 'Compartir Documentos entre Organizaciones,
XDS' (Cross enterprise document sharing) [4]. Este
modelo permite que una serie de organizaciones sanitarias, agrupadas en un dominio de afinidad, cooperen
en la prestación de atención a un paciente al compartir la historia clínica en forma de documentos CDA.
Un caso de uso típico de XDS (Figura 3) sería el de un
hospital A que ha tratado un paciente y le va a dar el
alta. El médico responsable del ingreso reúne y firma
una serie de documentos (como informe de alta y últimas pruebas de laboratorio), y los selecciona para ser
publicados en un almacén de documentos (repositorio
en la nomenclatura IHE) y que puedan ser consultados
cuando el paciente acuda a otro centro.
El informe en sí permanece en un repositorio del hospital A, pero será registrado en un registro centralizado,
para que pueda ser localizado cuando sea necesario. Si
más tarde el paciente ingresa en otro centro, el médico que lo atienda, a través de su aplicación informática, puede pedir al registro centralizado la información
disponible sobre ese paciente. Esa consulta puede
hacerse especificando algunos metadatos del documento, como fecha de emisión, tipo de documento (p.
ej. Informe de alta) o centro de origen. El médico
puede entonces elegir los documentos que desea consultar, y el sistema los recuperará del repositorio del hospital A.
En un sistema de Historia Clínica Compartida a nivel
nacional, se podría entender la historia de un paciente
como formada por dos vistas: por un lado estaría el EHRCR (Care-delivery Record, historia para la prestación de
atención) que contiene la información del paciente
gestionada por una organización sanitaria, que es la
responsable de su custodia, y por otro el EHR-LR (Historia
longitudinal) que contendría los documentos generados por diferentes EHR-CR, y que podría verse como una
historia de salud a largo plazo. Sería esta segunda historia la que estaría registrada en el registro.
Como se puede ver se trata de una arquitectura distribuida y escalable: cada organización sanitaria publica información para que sea consultada por otras dentro de su
dominio de afinidad, pero los documentos permanecen
en el sistema de información origen. El registro facilita un
Figura 3. Arquitectura de registro y repositorio para compartir documentos
21
I+S - 68 ABRIL'08
3/4/08 15:33
Página 22
Especial: La Informática de la Salud en Europa
Tabla 2. Metadatos almacenados en el registro
22
índice de la información publicada a todas las organizaciones dentro del dominio de afinidad.
El acceso a los documentos es sencillo: se establece una
forma de consultar (query) y recuperar (retrieve) documentos clínicos de interés, basada en unos atributos estándar, los
metadatos, que coinciden en buena parte con los atributos
del encabezado del documento CDA (Tabla 2).
Desde el punto de vista técnico, el modelo de registro y
repositorio adoptado es el Registry Information Model
(RIM) v2.1 de ebXML (Electronic Business using
eXtensible Markup Language) de Oasis (Organization
for Advancement of Structured Information Standards
ref), un modelo de destinado a publicar y permitir el
descubrimiento de productos y servicios en cualquier
tipo de negocio.
En la figura 4 se muestran los actores (sistemas de información participantes) y transacciones definidas en el
perfil XDS. Los principales actores son la 'fuente de documentos' (document source), sistema de información
que genera el documento; el 'consumidor de documentos' (document consumer), sistema que consulta
los documentos; el 'registro de documentos' (document
registry), en el que se almacenan los metadatos que
describen cada documento y un enlace al lugar donde
se encuentra almacenado; y finalmente el 'repositorio
(almacén) de documentos' (document repository), que
acepta documentos y metadatos de los orígenes de
documentos, almacena los documentos, reenvía los
metadata al registro y reproduce el documento bajo
petición.
Para localizar un documento en el registro es posible
hacer consultas basadas en los metadatos de interés
(Tabla 2). Entre estos metadatos está el estado del
documento (Figura 5) que sustenta el versionado y
borrado.
Las transacciones especificadas en el perfil XDS se realizan utilizando Simple Object Access Protocol 1.1 (SOAP,
W3C), SOAP with attachments y HTTP. Existe una especificación para implementación en pruebas, XDS.b, en
la que se utiliza ebXML RIM 3.01, SOAP 1.2 y, sustituyendo a SOAP with attachments, MTOM (W3C Message
Transmission Optimization Mechanism).
5.1. Perfiles sobre los que se apoya XDS
El perfil XDS se apoya en otros perfiles definidos previamente por IHE para resolver asuntos como la gestión de
identificadores de paciente, la autenticación de nodos
o la auditoria. El hecho de utilizar los mismos perfiles
que otros escenarios facilita la implementación en el
seno de una organización.
• El perfil Consistent Time (CT) Asegura que los relojes y
'time stamps' de los ordenadores en una red están sincronizados.
• El perfil 'Rastro para auditoria y autenticación de
nodos' (ATNA: Audit Trail and Node Authentication)
describe un sistema de autenticación basado en el
I+S - 68 ABRIL'08
3/4/08 15:33
Página 23
Especial: La Informática de la Salud en Europa
Figura 4. Transacciones en el perfil XDS 'cross enterprise document sharing' de IHE
uso de certificados, y la transmisión de eventos de auditoria relacionados con información personal de salud a
un repositorio común, de manera que todos los accesos
a la HCE de un paciente queden registrados.
• El perfil 'Referencia Cruzada de Identificadores de
Paciente' (PIX: Patient Identifier Cross Referencing,
posibilita el acceso a distintos identificadores del
paciente utilizados en distintos ámbitos o diferentes
organizaciones (hospitales, atención primaria,…)
5.2. Perfiles que amplían el alcance de XDS:
XDS Laboratorio y XDS Imagen Médica
Estos dos perfiles añaden al perfil XDS especificaciones
propias del dominio de aplicación. Es importante señalar que se diferencian de los perfiles de flujo de trabajo
(LSWF, Flujo de trabajo programado de Laboratorio y
SWF, Flujo de trabajo programado de Radiología) en
que no hacen referencia al flujo de petición de una
orden ni de obtención de resultados, sino que se limitan a especificar como se pueden compartir informes
finales con organizaciones independientes de aquella
en la que se generaron.
XDS Imágenes (Cross Enterprise Document Sharing for
Imaging - XDS-I:) define la forma de compartir imágenes
e informes basados en imágenes. Se establecen dos formas básicas: imágenes en formato Dicom e imágenes en
otros formatos estándar. En el primer caso el documento
que se comparte es un 'Dicom manifest', es decir un puntero a una imagen en un archivo de imágenes Dicom. En
el segundo caso el documento que se comparte contiene
las imágenes (puede ser un pdf por ejemplo) o enlaces al
lugar donde están las imágenes en un servidor Web.
XDS Laboratorio (Sharing Laboratory Reports XDS-LAB)
particulariza el formato del documento CDA para compartir informes de pruebas de laboratorio.
5.3. Privacidad y acceso a los documentos
del repositorio.
IHE ha previsto un mecanismo para registrar y gestionar
el consentimiento de cada paciente en lo que respecta
a la privacidad de los diferentes documentos publicados en un repositorio. Se trata del perfil Basic Patient
Privacy Consents BPPC (Figura 6), que permite marcar
los documentos publicados en un repositorio XDS con el
Figura 5. Posibles estados de un documento en el registro
23
I+S - 68 ABRIL'08
3/4/08 15:33
Página 24
Especial: La Informática de la Salud en Europa
consentimiento específico que se utilizó para autorizar
dicha publicación, gestionando quién y bajo qué circunstancias puede acceder a cada documento.
6. IMPLANTACIÓN EN EUROPA
24
El modelo de resumen de historia clínica interoperable
basado en XDS y CDA se está utilizando en diferentes
proyectos en Europa, Estados Unidos y Canadá.
El gobierno francés está trabajando en un proyecto de
ámbito nacional denominado DMP (Dossier médicale
personnel, Historia clínica personal) cuyo objetivo es
crear una HCE gestionada por el paciente y accesible a
los profesionales. Fue iniciado en el año 2004 y actualmente ha pasado la fase piloto y avanza hacia lo que
denominan fase de generalización. Sus destinatarios
son todos los beneficiarios del sistema de seguridad
social francés. Este proyecto ha adoptado formalmente
como arquitectura el modelo registro-repositorio propuesto por el perfil XDS de IHE, concretamente un único
registro a nivel nacional y repositorios compartidos a
nivel regional. Los perfiles implementados inicialmente,
además de XDS son PIX, CT y ATNA (neutrales respecto
al contenido del documento), pero existe una hoja de
ruta para incluir progresivamente especificaciones a
nivel de documento (XDS-SD, XDS Imágenes, XDSMedical summary y XDS Laboratorio). El paciente puede
gestionar la privacidad de los distintos documentos (por
ejemplo ocultando documentos a un tipo concreto de
profesional), para lo que se utiliza el perfil Basic Patient
Privacy Consent (BPCC). Se utiliza también el perfil DGS
(digital signature, firma digital), para la firma de documentos por parte de los profesionales.
En Italia hay actualmente en marcha tres proyectos que
utilizan el perfil XDS. El proyecto de la región de
Génova, Conto Corrente Salute, está en servicio desde
Enero de 2006 y en él participan 4 hospitales y 500 consultas médicas. La infraestructura incluye un único repositorio y registro a nivel regional, y se implementan también los perfiles PIX y ATNA. Los documentos CDA son
actualmente nivel 1, siendo el cuerpo un documento
pdf, y se planea en el futuro ampliarlos a nivel 2 (contenido estructurado) comenzando por los informes de
laboratorio (XDS LAB). Es obviamente un proyecto que
incluye sistemas de diferentes proveedores, a los que se
invitó a tomar parte en el connectathon europeo de
2005 para garantizar su interoperabilidad. Otro de los
proyectos tiene como ámbito el Hospital de Verona y
como objetivo inicial el compartir informes clínicos con
imágenes (utilizando el perfil XDS-Imagen), que se
ampliará para incluir informes de laboratorio, cardiología y anatomía patológica. En esta instalación, el regis-
tro y el repositorio son tecnología de código abierto [6].
De los proyectos basados en XDS, el más ambicioso es
el canadiense Health Infoway, lanzado en 2001 con el
objetivo de crear un sistema de historia clínica de ámbito nacional. Infoway es una organización sin ánimo de
lucro formado por las consejerías de sanidad de las 14
regiones canadienses. En Febrero de 2007 el sistema
incluía ya a uno de cada tres canadienses, y se prevé
que llegue al 50% de la población en 2009 y al 100%
en 2020. Se ha lanzado también un proyecto de telemedicina (teleconsulta) basado en XDS.
7. IHE FARMACIA
De los trabajos en curso a nivel europeo destaca la creación de un comité de Farmacia, que publicará en Julio
de 2008 un 'white paper' con la visión de los casos de
uso tanto para farmacia hospitalaria como para farmacia comunitaria. Este trabajo llevará a la publicación de
un perfil de e-farmacia durante el ciclo de desarrollo
anual 2008-2009. El hecho de que éste dominio esté
liderado desde Europa está relacionado con las diferencias entre el modelo europeo y el americano, y con la
importancia de que los diferentes sistemas de receta
electrónica de ámbito europeo estén integrados en el
futuro.
8. CONCLUSIONES
El enfoque propuesto por IHE para la interoperabilidad
de la Historia Clínica Electrónica ha sido adoptado en
diversos proyectos en Europa, Estados Unidos y Canadá.
Se trata de un enfoque flexible e integrador, que permite comunicar sistemas con diferente nivel de complejidad sin que eso suponga una barrera de entrada
para hospitales u otras organizaciones con un grado de
digitalización menor. Es posible compartir desde simples
documentos escaneados dotados de contexto a través
de los encabezados CDA y de los metadatos almacenados en el registro, hasta documentos mucho más
complejos, compuestos de entradas codificadas conforme a una determinada plantilla (template) y un vocabulario como SNOMED, LOINC o CIE.
De esta forma, se permite ir avanzando progresivamente hacia la interoperabilidad semántica de los sistemas, entendida como la posibilidad de que la información compartida entre ellos sea comprendida en
función de una serie de conceptos del dominio definidos formalmente, de manera que la información sea
procesable automáticamente por el sistema receptor, y
no como una simple traducción de conceptos de un
idioma a otro o de un vocabulario de referencia a otro.
Gracias a especificaciones como XDS Imágenes o XDS
I+S - 68 ABRIL'08
3/4/08 15:33
Página 25
Especial: La Informática de la Salud en Europa
Figura 6. gestión de la privacidad de los documentos con el perfil BPPC
Laboratorio, es posible utilizar la infraestructura genérica para compartir todo tipo de documentos, incluyendo
informes con imágenes médicas.
La Historia clínica electrónica utilizando los perfiles XDS
es ya una realidad como demuestra el hecho de que
en el connectathon europeo del año 2007 se probaran
con éxito 15 registros XDS, 30 repositorios y casi 60 sistemas que podían actuar como fuente y/o consumidor
de documentos. Existen además diferentes distribuciones de código abierto [6,7] para todos o varios de esos
actores.
En el futuro inmediato está prevista la creación de un
grupo de trabajo en 'Atención Coordinada al Paciente'
a nivel Europeo que preparará una extensión del perfil
'Resúmenes Médicos' adaptada a las necesidades de
los países de la Unión y que, junto con los proyectos en
curso, nos acercará más a la creación de una historia de
salud disponible para la atención sanitaria de pacientes
en todo el ámbito europeo.
9. REFERENCIAS
[1] Institute of Electrical and Electronics Engineers. IEEE
Standard Computer Dictionary: A Compilation of IEEE
Standard Computer Glossaries. New York, NY: 1990.
[2] Dolin RH, Alschuler L, Boyer S, Beebe C, Behlen FM,
Biron PV, Shabo Shvo A. HL7 Clinical Document
Architecture, Release 2. J Am Med Inform Assoc. 2006
Jan-Feb;13(1):30-9.
[3] Marco Técnico del dominio Atención Coordinada al
Paciente de IHE (Patient Care Coordination
Technical Framework). Revisión 3.0. Agosto 2008.
Disponible en http://www.ihe.net/ Technical_Framework/index.cfm#PCC (consultado Marzo 2008)
[4] Marco Técnico del dominio Infraestructura de
Tecnologías de la Información de IHE (IT Infrastructure Technical Framework). Revisión 4.0. Agosto
2007. Disponible en http://www.ihe.net/ Technical_Framework/index.cfm#IT (consultado Marzo 2008)
[5] Grupo de Interés público “Dossier médicale personnel” Gobierno de Francia. http://www.d-m-p.org/
(consultado Marzo 2008)
[6] Proyecto MARiS: Radiological OpenSource. Disponible
en http://sourceforge.net/projects/maris/ (consultado
Marzo 2008)
[7] Proyecto IHEOS IHE Open Source. Disponible en
http://sourceforge.net/projects/iheOS/ (consultado
Marzo 2008)
25