Perfil XDS IHE para HCC

Cross-Enterprise Document Sharing (XDS) se enfoca en manejar y compartir documentos entre Organizaciones de Salud. El alcance va desde la consulta privada de un médico hasta un hospital de alta complejidad y sus sistemas de información. Esto se maneja a través de repositorios de documentos federados y un registro de documentos, de forma de poder crear un registro de información de pacientes longitudinal, dentro de un dominio especifico clínico. Las entidades que participan con diferentes responsabilidades son las siguientes:

1. Repositorio de Documentos: Es el responsable de guardar los documentos de manera transparente, segura y confiable, siendo persistentes y con respuesta a solicitudes de documento.
2. Registro de Documentos: Es el responsable de guardar información sobre los documentos, de manera que los documentos de interés para la atención de los pacientes, puede ser fácilmente encontrados, seleccionados y recuperados, independiente del repositorio en el cual se encuentren.
3. Documentos son generados por más de una Fuente de Documentos
4. Pueden ser accedidos por más de un Consumidor de Documentos

XDS VIENE A SER EL PERFIL QUE SE USA PARA EL INTERCAMBIO DE INFORMACION EN HCC

Detalles y Algo sobre Actores

Este perfil asume que las organizaciones pertenecen a más de un dominio de afinidad. Un dominio de afinidad es un grupo de organizaciones que han acordado trabajar juntos usando un set de políticas e infraestructura comunes

El concepto de un documento en XDS no se limita a información textual, y puede contener cualquier información clínica en el contexto que sea. Esto hace que XDS pueda manejar documentos en texto libre, con formato como CDA-R1, imágenes como DICOM o con estructuras y vocabulario codificado para información clínica como CDA-R2, CCR, etc.. Para garantizar la interoperabilidad necesaria entre las fuentes de documentos y los consumidores, se deben generar estándares en cuanto al formato del documento, su estructura y contenido

Cabe destacar que XDS tiene como fin último, el generar una base para mantener registros clínicos electrónicos, manejado a través de repositorios de información federados y un registro de documentos para crear un registro de información longitudinal sobre el paciente en un dominio de afinidad específico

Un dominio de afinidad es el conjunto específico del ecosistema que acuerda el generar un registro clínico sobre una materia en particular, por ejemplo clínicas dentales, o sistema de documentos oncológicos, etc. En el caso de Chile por ser un Registro Nacional, el Dominio de Afinidad será todos los prestadores de salud nacional, comenzando con los Públicos

Los sistemas involucrados en el intercambio de información en XDS se denominan ACTORES. Estos son la base de XDA y entre ellos interactúan transando información

El perfil se especifica en un documento denominado IHE IT Infrastructure Technical Framework Version 2 o superior

Este perfil se puede estudiar en 3 Volúmenes

1. Vol 1: Perfil XDS
1. Descripción técnica completa del perfil
2. Vol 2: PCC TF-2 Transacciones
1. Descripción de las transacciones y módulos de contenidos para XDS y diferentes tipos de casos de uso (referencia, resumen de alta, etc.)
3. Vol 3: ITI TF-3
1. Descripción de la Metadata asociada a las transacciones en XDS

Adicional a la especificación existen una serie de documentos de apoyo que permiten el apoyo en otros elementos como las transacciones especificadas para PDQ o el mapeo de CDA a la Metadata para transacciones.

Conjunto de información clínica (estructurada o no), que ha sido firmada (attested clinical information) y que un elemento de información clínica de un paciente que va a ser compartida de manera que sea legible para personas y aplicaciones. El documento tiene un identificador único.

Otras características son: Persistence, Stewardship, Potential for Authentication, and Wholeness, elementos bien definidos en CDA de HL7, pero perfectamente se podría usar otro estándar. Un documento debe estar asociado con unos metadatos para ser registrado en el registro de XDS. Los códigos de documento y vocabulario utilizado deben ser consensuados en el dominio de afinidad

Algunos Metadatos

Sobre el paciente (patient): Dominio de afinidad, Información demográfica (id, nombre, fecha nacimiento) "tal y como los ve la fuente de documentos"

Sobre el origen del documento (Origin): author, institution, legal authenticator

Identificación del documento (Identification):ID index, repository URI, unique id, dates of creation, date of start/end of medical act, title, size, hash, availability status, parent document

Clasificación del documento (Classification): – class, type, format, MIME type, type and specialty of institution and author, medical codes, confidentiality level – Obligatorio, Obligatorio si se conoce, Generado por el repositorio, Recomendado

Las transacciones XDS se detallan a continuación:

1. Provide y Register Document Set
2. Register Document Set
3. Retrive Document
4. Query Documents
5. Patient Identity Feed

La definición de los actores sería:

1. Document Source: Sistema de información que genera el documento
2. Document Registry: registro, en el que se almacena la metadata de los documentos para las consultas y adquisición de ellos
3. Document Repository: Acepta documentos y metadatos del 'document source' – Almacena el documento – Reenvía los metadata al registro – Reproduce el documento bajo petición (permite recuperación del documento)
4. Document Consumer: Hace queries al registro, muestra listado de documentos disponibles – Recupera los documentos elegidos por usuario – utiliza los documentos, p.ej. para mostrarlos por pantalla
5. Patient Identity Source: Sistema de identificación unívoca de los pacientes que tienen registrados sus documentos

Una transacción de Registro de Documento sería como se muestra en la siguiente figura (Fuente IHE España)

Una transacción de Enviar y Recuperar Documento sería como se muestra en la siguiente figura (Fuente IHE España)

En las transacciones para la gestión de metadatos es el repositorio el que almacena el contenido, pero el registro aquel que gestiona

Una transacción para el Registro y Almacenamiento sería como se muestra en la siguiente figura (Fuente IHE España)

Para que el documento pueda ser transportado en la transacción correspondiente, debe ser usado un estándar que corresponda a la arquitectura usada por XDS. Dentro de los estándares existentes para este perfil existen los siguientes:

ebXML: Electronic Business using eXtensible Markup Language

Estándar que especifica una arquitectura de registro/repositorio destinada a publicar y permitir el descubrimiento de productos y servicios en cualquier tipo de negocio. Contempla el envío (submission), consulta (query) y recuperación (retrieval) de los contenidos de dichos registros y repositorios

ebXML se compone de 2 estándares

ebRIM:

: es un modelo de información de registro, es decir es un lenguaje para describir documentos. Se construye en base a objetos y sus atributos. Se expresa por medio de XML. Lo anterior implica que los documentos en XDS se representan como objeto ebRIM

ebRS:

Se usa para servicios y protocolos del registro, definiendo los métodos y las solicitudes. Bajo este contexto los Queries y Request se hacen por medio de este protocolo

Objetos

Los Objetos en XDS, vendrían a ser los elementos que se transfieren, crean, borran y modifican en las transacciones de IHE

XDS Submission Set: Conjunto de documentos relacionados con un paciente que un médico (o equipo) del sistema fuente han decidido publicar. Es lo que se envía al repositorio

XDS Folder – Carpeta: Modo de agrupar documentos almacenados en el repositorio – Carpetas organizadas por razones episodio de cuidado, información importante en caso de emergencia. Las carpetas se especifican a nivel de dominio clínico (en el affinity domain), no técnico. Se pueden añadir documentos a una carpeta en cualquier momento siempre que estén relacionados con el mismo paciente

En el siguiente link podrá descargar el ejercicio para esta unidad: Ejercicio