17
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 tam- bién abundantes medios tecnológicos que facilitan su trabajo.
En este contexto, la interoperabilidad entre los diferen- tes sistemas de información y otros equipos (electro- medicina,..) 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 aten- ción. En unas organizaciones sanitarias donde la auto- matización y digitalización es cada día mayor, la inte- gración de todos los sistemas ofrece innumerables ven- tajas a todos los actores implicados. Por un lado, mejo- rando la atención a los pacientes, facilitando el trabajo de los profesionales y permitiéndoles desarrollarlo con
Los estándares en Sistemas de Información Sanitarios en Europa: la visión de IHE
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
PALABRAS CLAVE
Interoperabilidad, Historia Clínica Electrónica, Estándares, Integrating the healthcare enterprise (IHE), Clinical Document Arquitecture (CDA)
Interoperabilidad historia clínica electrónica
RESUMEN
Integrating the Healthcare Enterprise (IHE) es una orga- nización cuyo objetivo es promover la adopción coordi- nada de estándares para ofrecer soluciones a proble- mas 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 trans- nacional 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 resol- ver aspectos como la identificación cruzada de pacien- tes, 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 especifi- cación de la estructura básica de diferentes documen- tos, 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.
18
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 utili- za 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 capa- cidad de dos o más sistemas o componentes para inter- cambiar información y utilizar la información que ha sido intercambiada”.
En el momento actual, después de muchos años de tra- bajo en este campo, se puede decir que las organiza- ciones 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 enton- ces en condiciones de afrontar el siguiente gran reto:
alcanzar la interoperabilidad entre los sistemas de dis- tintas 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 reper- cusión en el ámbito Europeo, en la Historia Clínica Electrónica (HCE) como paso imprescindible para garan- tizar la atención sanitaria transnacional y por consi- guiente el derecho a la libre circulación de personas dentro de los países de la Unión.
1. IHE: INTEGRATING THE HEALTHCARE ENTERPRISE.
IHE es una organización sin ánimo de lucro, participada por empresas, sociedades científicas, administraciones, hospitales y usuarios en general, cuyo objetivo es desa- rrollar y promover la adopción coordinada de estánda- res ya existentes, para ofrecer soluciones a los proble- mas de interoperabilidad en el ámbito de la salud.
Para los lectores que no estén familiarizados con el pro- ceso de creación de especificaciones de IHE y la termi- nologí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 especifi- cación que proponen formas concretas de utilizar uno o varios estándares para acometer en el corto plazo obje- tivos de interoperabilidad identificados por los profesio- nales sanitarios en dominios de aplicación concretos.
El perfil de integración es el elemento básico de defini- ció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 identifi- cación de los roles de los diferentes sistemas implicados, a los que se denomina actores. Posteriormente define los diferentes intercambios de información (transaccio- nes) entre dichos actores, utilizando estándares ya exis- tentes, 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 reco- gen en el Marco Técnico. Las empresas del sector apli- can 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 Connecta- thon 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 con- templa 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 infor- mación, la Atención Coordinada al Paciente, la Calidad, y los Dispositivos de Monitorización.
2. HE Y EL RESUMEN DE HISTORIA CLÍNICA COM- PARTIDA 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án- dares existentes y estables para que pueda ser imple- mentada inmediatamente.
2.1. Orientación a documentos
El flujo de trabajo convencional (no digital) del inter- cambio de información médica entre profesionales se organiza normalmente en forma de documentos. Estos documentos reúnen unidades básicas de información
19
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 tradi- cional 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 docu- mento, normalmente firmándolo. Frente a esta organi- zació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 infor- mación se mantiene de forma independiente.
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 seguri- dad, así como unas políticas de confidencialidad comu- nes. La necesidad de disponer de dichas políticas comu- nes es fácilmente comprensible si se considera que los requisitos de acceso a un documento en la organiza- ció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
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 barre- ra hacia una historia de salud accesible sin comprome- ter su confidencialidad.
Al igual que otras normas en el área de la historia clíni- ca electrónica, IHE separa la especificación del conteni- do (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 conti- nuación se describen cada uno de estos dos elementos.
3. LA ESTRUCTURA DEL DOCUMENTO: CDA DE HL7
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á basa- do 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 docu- mento 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 esta- blece su contexto y que es legible por seres humanos.
La estructura de un documento CDA es sobradamente
20
conocida (Figura 1): consta de un encabezado que pro- porciona 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 (encoun- ter) en el que se ha generado, los proveedores sanitarios (profesionales y organizaciones) involucrados, el responsa- ble 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 sec- ció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
forma de entradas (entry), datos codificados que repro- ducen 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 docu- mento, sino simplemente a la estructura y semántica necesaria para su intercambio. Sin embargo, existe una forma directa de crear normas que regulen el conteni- do, a partir de la generación de plantillas (templates), que restringen la norma CDA particularizando la espe- cificació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 docu- mento. Una plantilla estará representada por un sche- matron 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í especifi- can 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 momen- tos en los que la atención del paciente se transfiere de un escenario a otro (como el alta hospitalaria, o la asis- tencia en desplazamientos o emergencias). La especifi- cació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), inclu- yendo secciones como medicaciones, alergias y lista de problemas. (Figura 2).
Tabla 1. Los tres niveles de CDA
Figura 2: Documento CDA en el Perfil Medical Summaries.
21
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 informa- ció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 sani- tarias, agrupadas en un dominio de afinidad, cooperen en la prestación de atención a un paciente al compar- tir 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 últi- mas 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 hospi- tal 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édi- co que lo atienda, a través de su aplicación informáti- ca, puede pedir al registro centralizado la información disponible sobre ese paciente. Esa consulta puede hacerse especificando algunos metadatos del docu- mento, 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 con- sultar, y el sistema los recuperará del repositorio del hos- pital 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 EHR- CR (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 genera- dos por diferentes EHR-CR, y que podría verse como una historia de salud a largo plazo. Sería esta segunda his- toria la que estaría registrada en el registro.
Como se puede ver se trata de una arquitectura distribui- da y escalable: cada organización sanitaria publica infor- mació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
22
índice de la información publicada a todas las organiza- ciones dentro del dominio de afinidad.
El acceso a los documentos es sencillo: se establece una forma de consultar (query) y recuperar (retrieve) documen- tos 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 infor- mación participantes) y transacciones definidas en el perfil XDS. Los principales actores son la 'fuente de docu- mentos' (document source), sistema de información que genera el documento; el 'consumidor de docu- mentos' (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 reali- zan utilizando Simple Object Access Protocol 1.1 (SOAP, W3C), SOAP with attachments y HTTP. Existe una espe- cificación para implementación en pruebas, XDS.b, en la que se utiliza ebXML RIM 3.01, SOAP 1.2 y, sustitu- yendo 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 previa- mente 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 sin- cronizados.
• 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
Tabla 2. Metadatos almacenados en el registro
23
uso de certificados, y la transmisión de eventos de audi- toria 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ña- lar 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 limi- tan 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 for- mas 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 pun- tero 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 com- partir 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 publica- dos 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 4. Transacciones en el perfil XDS 'cross enterprise document sharing' de IHE
Figura 5. Posibles estados de un documento en el registro
24
consentimiento específico que se utilizó para autorizar dicha publicación, gestionando quién y bajo qué cir- cunstancias puede acceder a cada documento.
6. IMPLANTACIÓN EN EUROPA
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 actual- mente 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 pro- puesto 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, XDS- Medical 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 docu- mentos 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 con- sultas médicas. La infraestructura incluye un único repo- sitorio y registro a nivel regional, y se implementan tam- bié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 (con- tenido 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, cardiolo- gí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 ámbi- to 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 tele- medicina (teleconsulta) basado en XDS.
7. IHE FARMACIA
De los trabajos en curso a nivel europeo destaca la cre- ació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 farma- cia 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 diferen- cias 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 per- mite comunicar sistemas con diferente nivel de com- plejidad 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 almace- nados en el registro, hasta documentos mucho más complejos, compuestos de entradas codificadas confor- me a una determinada plantilla (template) y un voca- bulario como SNOMED, LOINC o CIE.
De esta forma, se permite ir avanzando progresiva- mente hacia la interoperabilidad semántica de los sis- temas, entendida como la posibilidad de que la infor- mación compartida entre ellos sea comprendida en función de una serie de conceptos del dominio defini- dos 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
25
Laboratorio, es posible utilizar la infraestructura genéri- ca 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 sis- temas que podían actuar como fuente y/o consumidor de documentos. Existen además diferentes distribucio- nes 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_Fra- mework/index.cfm#PCC (consultado Marzo 2008) [4] Marco Técnico del dominio Infraestructura de
Tecnologías de la Información de IHE (IT Infras- tructure Technical Framework). Revisión 4.0. Agosto 2007. Disponible en http://www.ihe.net/ Techni- cal_Framework/index.cfm#IT (consultado Marzo 2008) [5] Grupo de Interés público “Dossier médicale person- nel” 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)
Figura 6. gestión de la privacidad de los documentos con el perfil BPPC
