IHE 02 IntroXDS 2014

IHE y la historia clínica electrónica
compartida: XDS
Paula de Toledo.
IHE España
Universidad Carlos III de
Madrid
2014
IHE España 2014
IHE y la HCE compartida: El perfil XDS
Contenido
 La propuesta de IHE para compartir documentos: el perfil Cross

Enterprise document sharing (XDS)
 Otros perfiles de infraestructura necesarios para poner en marcha un
proyecto XDS:
– Audit trail and node authentication (ATNA), Consistent time (CT),
– Identificadores únicos de usuario con Patient Identifier Cross-Referencing
(PIX)
 Versiones de XDS: XDS punto - punto (XDS Reliable) y XDS sobre medios
físicos (XDS Media)
 XCA: Cross community access: federación de registros XDS
 Perfiles de contenido:
– XDS Laboratorio
– XDS Imágenes
– XDS Scanned document
– Medical summary
IHE España 2014
PERFIL CROSS ENTERPRISE DOCUMENT SHARING (XDS)

IHE España 2014 XDS - Intro
Propuesta de IHE: Modelo registro – repositorio

Centro de
diagnóstico
por imagen
Centro de atención primaria
Repositorio
HL7
Repositorio
DICOM
Historia hospital Registro
Imagen
Hospital A
Registro
HL7 HL7
HL7
Administración Paciente
Laboratorio Hospital C Hospital B
Urgencias
Escenario: intercambio de documentos clínicos
 Objetivo : intercambio de documentos clínicos
La forma tradicional de compartir información clínica es basada en

documentos
¿Qué es un documento para XDS?
 Conjunto de información clínica (estructurada o no)

– Que ha sido firmada (attested clinical information)
– Que forma un elemento de información clínica de un paciente que va a ser
compartida
– legible para personas y aplicaciones
– Tiene un identificador único
 Otras características: Persistence, Stewardship, Potential for
Authentication, and Wholeness
 bien definidas en CDA de HL7, pero podría ser otro estándar
 Un documento debe estar asociado con unos metadatos para ser

registrado en el registro
 Los códigos de documento y vocabulario utilizado deben ser
consensuados en el dominio de afinidad
Escenario: Dominio de afinidad
 Objetivo : intercambio de documentos clínicos en un dominio de

afinidad
 Affinity domain:
– Conjunto de organizaciones que comparten un registro
– Trabajan en un un entorno de cooperación definido:
 Políticas comunes de seguridad
 Políticas comunes de confidencialidad
 Infraestructura común de comunicaciones
Hay bastante trabajo que hacer para poner en marcha el dominio de afinidad
Trabajo técnico, pero sobre todo organizativo
Muy útil el "white paper" Template for XDS Affinity Domain Deployment Planning
Algunos metadatos almacenados en el registro XDS

 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

Principios en los que se basa XDS -1
 Distribuido
– Cada organización sanitaria publica información para otros.
– Los documentos permanecen en el EHR-CR origen
 Escalable
– Modelo válido tanto para hospitales, centros de atención primaria,
pequeñas consultas privadas, clínicas, farmacias, el paciente,………. con
sistemas de información diferentes
 Centrado en los documentos

– La información publicada son documentos clínicos, que siguen estándares
– XDS es neutral en cuanto al contenido y tipo del documento: sólo la
fuente y el consumidor del documento procesan la información
Principios en los que se basa XDS -2
 Entre organizaciones
– El registro facilita un índice de información publicada a organizaciones
autorizadas, que pertenecen a un 'dominio de afinidad' sanitario (ej CCAA)
– La información publicada ‘pertenece’ a la organización origen
 Fácil acceso
– el proveedor sanitario tiene a su disposición una forma de consultar (query)
y recuperar (retrieve) documentos clínicos de interés
– las búsqueda documentos se basa en atributos normalizados (metadatos)
XDS : Concepto de Care delivery vs longitudinal Record
 EHR-CR : Care-delivery Record

– Información del paciente
– Gestionada por una organización sanitaria
– La custodia de la información contenida en un documento del registro
permanece en la fuente del EHR-CR
 EHR-LR : Longitudinal Record

– Documentos compartidos por los EHR-CR(s)
– Historia de salud de un paciente a largo plazo
– Registrada en el registro
IHE España 2014 XDS – Actores y transacciones
Perfil XDS: Diagrama de actores y transacciones
Identificación
de Pacientes
Asocia Identificación
con Documento
Consulta de
Registro de Documentos Cosumidor de
Documentos Documentos
Registro del
Conjunto de Documentos
Fuente de Repositorio de
Documentos Proporciona y Registra Documentos Recuperación de
el conjunto de Documentos Documentos
Perfil XDS: Diagrama de actores y transacciones (inglés)
Transacciones del perfil:

o Provide & register document set
o Register document set
o Retreive document
o Query documents
Infrastructure
Patient
o Patient Identity Feed Identity Source
Patient Identity
Feed
Query
Document Documents Document
Registry Consumer
Register
Document Set
Provide&Register Retrieve
Document Set Document
Document Document
Source Repository
Adaptado de Charles Parisot. GE

Actores del perfil XDS

 Document source
– sistema de información que genera el documento
 Document registry
– registro, en el que se almacena
 Metadatos del documento
 Enlace al lugar donde se encuentra realmente el documento
– Responde a consultas (queries) de acuerdo con unos determinados metadata

 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)
 Document consumer
– Hace queries al registro, muestra listado de documentos disponibles
– Recupera los documentos elegidos por usuario
– utiliza los documentos, p.ej. para mostralos por pantalla
 Patient identity source
– fuente de identidad de pacientes
XDS: Registrar un documento
No se envía un documento solo, sino

como parte de un Submission Set Document
Document Consumer
Provide & Register Registry
Document Set
Register Document Set
Registrar documento en
proporcionar y registrar un el registro
conjunto de documentos en el
repositorio
Document Document
source Repository
Submission
Metadata
Codificación: soap with attachments
Document Transmisión: http

Document

XDS: Buscar y recuperar un documento
Búsqueda en el registro de un
listado de documentos (p.ej. por
paciente, fecha – es decir:
metadatos)
Query documents
Document Document
Registry Consumer
Document Document
source Repository
Retrieve
document
recuperar del repositorio
un documento concreto

Gestión de los metadatos

• Repositorio almacena contenido
• Registro almacena metadatos que describen el contenido
Almacena
Interpreta
Query documents
Document Document
Registry Consumer
Provide & Register
Document Set Register Document Set
Document Document
source Repository
Retrieve
document
Genera Añade
IHE España 2014 XDS – Estándares utilizados
Arquitectura Registro / Repositorio: ebXML
 IHE elige los estándares más adecuados para cada perfil

– ¿Qué estándar elegir para la arquitectura registro /
repositorio?
 ebXML
 estándar conjunto de Oasis y w3c
 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
ebRIM y ebRS - I
 ebXML son dos estándares:

– ebRIM – Registry Information Model
– ebRS – Registry services
 XDS sólo utiliza una pequeña parte de la funcionalidad de ebXML
 ebRIM – Registry Information Model

– Modelo de información del registro
– lenguaje para describir documentos
 construido por objetos y atributos de objetos
 Expresado en XML
– Los documentos XDS se representan como objetos ebRIM

 Ejemplos
– RegistryObject = top level class

– Association, para describir relaciones entre documentos
ebRIM y ebRS -II

 ebRS – Registry services
 Servicios y protocolos del registro
 Define métodos y requests
 Los queries y retreives de documentos se basan en ebRS
 Ejemplos
– Envíar un documento a un repositorio
 rs:SubmitObjectsRequest
– Recuperar un documento del repositorio
 rs:AdhocQueryRequest
IHE España 2014 XDS – Registro y Repositorio
Repositorio
 El repositorio recibe un documento, lo almacena y lo registra en el

registro
– Para ello genera la siguiente información:
 Tamaño
 URI
 Huella (Hash)
 Información de estado
 Luego debe ser capaz de servir el documento como respuesta a una

petición de la uri.
– La información del repositorio se puede recuperar por medios estándar (ej.
http o ftp)
– Debe comprobar que el tamaño y hash del documento coinciden con los
metadatos del registro
¿Cómo consultar el registro?: Consultas (Queries)

 Queries usando los metadatos de los documentos, folders y submission sets de
XDS, por ejemplo:
– recuperar documentos de un tipo específico para un determinado paciente y margen
temporal
– query por autor
– todos los documentos de un submission set
 Las queries
– están basadas en el modelo de registro ebXML (ebXML RIM)
– están escritas en un subconjunto de SQL
 Una query devuelve:

– metadatos de uno o más objetos del registro
– referencias a objetos del registro (UUIDs)
 UUID=Universally Unique Identifier=identificador único –Estandarizado por Open
Software Foundation (OSF)

XDS – Agrupación de documentos: envío y almacén

 XDS Submission Set
– Conjunto de documentos relacionados con Folder
un paciente que un médico (o equipo) del
sistema fuente han decidido publicar Folder
– Es lo que se envía al repositorio SubmissionSet
Folder
 XDS Folder - Carpeta
Document
– Modo de agrupar documentos almacenados Document
Document
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 Servidor de
técnico documentos
(registro y
– Se pueden añadir documentos a una
repositorio)
carpeta en cualquier momento siempre que
estén relacionados con el mismo paciente

Atributos de un SubmissionSet
 Autor
– persona, rol, especialidad (specialty), institución (institution)
 Título, comentarios, fecha de envío (submission time)
 Disponibilidad (Availability Status)
– Enviado (submitted) o aprobado (Approved)
 Elementos codificados
– contentType = Tipo de actividad clínica
 Identificadores
– Id del paciente, ID de la fuente (Source ID), ID único del documento (Unique
ID), UUID
Estados de un documento XDS en el registro
Enviado – Submitted
(registro en proceso)
Aprobado – Approved
(disponible para la atención al paciente)
Visibles para el usuario
(document consumer)
Desactualizado– Deprecated
(obsoleto)
Deleted – Eliminado
IHE España 2014
Uso de ebXML en XDS
Representación en ebRIM de los objetos XDS
 Usando los objetos y asociaciones definidas en el ebRIM

– Algunos tipos de asociaciones predefinidas en: RelatedTo, HasMember,
ExternallyLinks, Contains, EquivalentTo, Extends
 Submission Set y documentos que contiene
Association Document
(HasMember) (ExtrinsicObject)
Submission Set
(registryPackage)
Document
Association
(HasMember)
(ExtrinsicObject)
IHE España 2014
Uso de ebXML en XDS
Gestión de versiones de un documento
Submission Set Association Document

Status=approved (HasMember) Status=approved
Association
(RPCL)

 Otros valores usados de association

– RPLC (Replace) - reemplaza
– APND (appends) - añade
– XFRM (transformation) - transforma
– Signs - firma
IHE España 2014
Uso de ebXML en XDS
Firma digital
 Documento almacenado en repositorio

– Indexado en el registro
 Firma digital es un documento: almacenada en el repositorio
– Indexado en el registro
 ¿Cómo se enlaza la firma digital se con el documento?

Association
(Signs)

IHE España 2014
XDS: Metadatos en detalle
Metadatos del documento - I
 Author
– persona, rol, especialidad (specialty), institución (institution)
 Legal authenticator
 Title, comments, creation time, service start/stop time
 Disponibilidad (Availability Status)
– enviado (submitted), aprobado (approved), derogado (deprecated)
 Identifiers
– Id de paciente, unique id, uuid
 Demographics
– Source patient id, patient demographics
IHE España 2014
Metadatos del documento - II

 Valores codificados
– Tipo de documento
 ClassCode
– Ejemplos: receta, informe de alta, informe de asistencia, resumen de

historia
– Estos códigos deben
 consensuarse en el domino de afinidad
 Venir de un sistema de codificación
 Tener un nivel de granularidad "gordo" de 10 a 100 valores
 type code
– Código para el tipo de documento pero más detallado
– Event code = evento clínico principal con el que se relaciona el documento

– Helthcare facility type = tipo de organización sanitaria
– Practice setting type
– Confidenciality code = nivel de confidencialidad del documento.
IHE España 2014
Metadatos del documento - III

 Datos técnicos
– mime type Tipo mime
– format code – más detalle sobre el formato, si es necesario
– size = tamaño
– hash = huella
– uri = localización del documento en un registro
– language = idioma
IHE España 2014
XDS: Notificaciones
 Notification of Availability (NAV)

– Envío de notificaciones cuando los documentos están disponibles (e.mail)
 Document Metadata Subscription (DSUB)

– Permite ‘lanzar’ intercambios de información cuando se producen ciertos
eventos en un entorno XDS
– Modelo publish/subscribe
– Basado en los metadatos
– The subscription allows for the matching of metadata during the publication
of a new document for a given patient, and results in the delivery of a
notification
IHE España 2014
OTRA INFRAESTRUCTURA NECESARIA PARA IMPLEMENTAR XDS

IHE España 2014
Perfiles de infraestructura necesarios
 Para implementar una infraestructura XDS se necesitan como base otros

perfiles del dominio ITI
– Seguridad y auditoría única en el dominio de afinidad

 Perfil ATNA audit trail and node authentication
– Fecha y hora consistente en el dominio de afinidad

 Perfil Consistent time
– Identificación única de pacientes en el dominio de afinidad

 Diferentes opciones (IHE y otras)
– Perfil Patient Identifier Cross Referencing (PIX)

– Alternativamente perfil PDQ
IHE España 2014
ATNA y CT
ATNA y CT en XDS
Autenticación de sistemas, no de usuarios
EHR System PMS
Physician Office ED Application
XDS
Document XDS
Repository Document
Registry PACS
XDS
Document
Repository
Query Document Register Document
PACS
Secured Messaging EHR System
Retrieve Document Provide & Register Docs
Lab Info. Maintain Time
System
Maintain Teaching Hospital
Record Audit
Community Clinic Maintain Time
Event
ATNA Audit Time
record repository CT Time server
Record Audit Record Audit
Event Event
Fuente; Karen Witting – IBM

IHE España 2014
PIX-PDQ
XDS Scenario + use of PIX & PDQ

PDQ Query
Patient Identity XRef Mgr
Patient Identity Feed
Patient Identity Feed
A87631
M8354673993
M8354673993 14355
M8354673993
L-716 L-716 A87631
Affinity Domain Patient

EHR System
Identity Source
M8354673993 ED Application
Physician Office
Patient Identity Feed Patient Identity Feed
PIX
XDS Document PACS
Document Query
Registry A87631
Repository
L-716
PIX
XDS
Query Document
Repository
EHR System
PACS Query Document (using Pt Id) Register (using Pt ID)
PACS Provide & Register Docs

Lab Info. Retrieve Document
System
Teaching Hospital
Community Clinic
ATNA Audit
record repository CT Time server
Fuente; Karen Witting – IBM

IHE España 2014
INTEGRACIÓN ENTRE DIFERENTES COMUNIDADES:

XCA CROSS COMMUNITY ACCESS
IHE España 2014
XCA
XCA: Cross community access
 Federación de instalaciones XDS o similares

– Community = grupo de organizaciones que han acordad trabajar
conjuntamente utilizando unas políticas comunes para compartir
información.
 Se identifican por su homeCommunity.id
 Pueden ser Affinity Domains XDS o tener cualquier otra estructura
interna
 Soporte para query y retreive de información de pacientes que está en
otras comunidades
 Primera versión agosto 2007, para implementación en prueba.
 Perfiles asociados
– Cross-Community Patient Discovery (XCPD)
 Soporte para la localización de comunidades en las que hay datos
relevantes del paciente

 Soporte para la ‘traducción’ de indentificadores de paciente entre
comunidades
IHE España 2014
XCA
Perfil Cross Community Access. Actores y Transacciones
Fuente: proyecto HIEOS

IHE España 2014
"VERSIONES" DE XDS: XDS RELIABLE Y XDS MEDIA
Opciones para implementar XDS sin registro centralizado: sobre medios

físicos o punto a punto
IHE España 2014
Versiones de XDS
XDS Other
INFRASTRUCTURE XCA INFRASTRUCTURE
M8354673993 M8354673993
L-716
14355
A87631 Query/Retrieve L-716
14355
A87631
Document
Document Consumers/
Sources XDS Recipients
XDS INFRASTRUCTURE
M8354673993
Publish L-716
14355
A87631 Query/Retrieve
XDR Existing Reliable
Send to Messaging System Receive
Interchange Media
XDM
Read
Write Including Email
IHE España 2014
XDR y XDM
Flexible Infrastructure:
Sharing, Sending and Interchanging
Health Information Exchange or RHIO
XDS Structured Pull

objects
Publish
Pull
XDR
Send to Switch Send to
Interchange
XDM
Write Media Read
Workflow Workflow
Mgr Transactions Mgr
Fuente: Emmanuel Cordonnier- Etiam

IHE España 2014
XDS Media
XDS Media
 transportar documentos XDS en diferentes media

– USB, CD-R, ZIP over email
 Casos de uso
– Entregar documentos al paciente
– Transferencia 'manual' de documentos
– Visualización local, basada en un fichero index.html
 Impone una estructura de directorios en el media
 Permite transportar muchos Submission sets
– Cada uno tendrá metadata y documentos
 Organización en directorios de acuerdo con la estructura XDS
IHE España 2014
XDS Media
XDS Media: actores y transacciones
Distribute Document Set on Media [ITI-32] 

Portable Media Portable Media
Creator Importer
Emmanuel Cordonnier- Etiam

IHE España 2014
XDS Media
XDS Media: Estructura
Entry for the web content
Entries for the content the submissions sets
Other content not covered by the profile
XDS Metadata
Other file ignored by the metadata
Simple part document
Multi part document
Start part (main file)

Other part (file)

IHE España 2014
IHE y la HCE compartida: El perfil XDS XDS Reliable
XDR reliable
 Transmisión punto a punto de contenido XDS (metadatos y documento)

utilizando protocolos seguras
 Simplemente especifica como usar transacciones 'Provide and Register'
(iti-15) de XDS para transmisiones punto a punto
 Orientada a transmisión asíncrona (online opcional)
– Al contrario que XDS, orientada a modo online (soporta offline opcional)
 Permite (como opción) identificar a los destinatarios
Provide and Register

Document Set [ITI-15] 
Document Source Document Recipient

IHE España 2014
XDS Y EL CONTENIDO DE LOS DOCUMENTOS

IHE España 2014
Perfiles de contenido relacionados con XDS

Perfiles relacionados con CONTENIDO de documentos: (Otros dominios)
Pre Consent Emergency Scanned Doc

Surgery
BPPC EDR XDS-SD
PPHP
Imaging Laboratory Discharge & PHR
Referrals Exchange
XDS-I XD*-Lab
XDS-MS XPHR
Doc Sharing Pt-Pt Doc Media

XDS Interchange Interchange
XDR XDM
Perfiles relacionados con INTERCAMBIO de documentos (Dominio ITI)
Tomado de Charles Parisot. GE
IHE España 2014
El contenido de los documentos
 Perfiles de contenido
– Dominio ITI
 XDS Scanned document: Documento escaneado (opción mínima)
– Dominio Radiología
 XDS Imaging: Imágenes DICOM
– Dominio Laboratorio
 XD LAB – Informes de laboratorio
– Dominio Patient Care Coordination

 XDS-MS: Resumen Historia: Medical Summaries
 EDR: Derivación a urgencias (Emergency Department Referral)
 XPHR: HCE personal (Exchange of Personal Health Record Content)
 PPHP: Pre-procedure History and Physical
 BPPC: Basic Patient Privacy Consents
 …..
IHE España 2014
Un documento CDA Release 2
<ClinicalDocument> El encabezado proporciona el

contexto: paciente, encounter,
autor, custodian, acto
documentado ..
<structuredBody>
El cuerpo puede estar
<section> estructurado como un arbol de
<section>
secciones anidadas
<text>
Una sección debe contener un
bloque narrativo para ser legible
<entry> para personas…
…y puede tener diferentes
entradas que contendrán datos
codificados para ser procesados
automáticamente
IHE España 2014
PERFILES DE CONTENIDO: XDS LABORATORIO

IHE España 2014
XDS Laboratorio
Caso de uso: Hospital lab report [CIS EHRs]
At discharge time, a hospital physician selects the most significant laboratory

reports produced during the patient stay, and issues these reports to an Affinity
Domain shared by a number of healthcare enterprises and primary care providers.
XD*
Hospital Lab Report Lab
Discharge Source Report
time Consumer
CIS Lab Reports

Any care setting
or care provider
IHE España 2014
XDS Laboratorio
Dependencies of otros
XDS LAB – relación con XD-LABperfilestowards other profiles
Share a CDA
Content
Creator
lab report Content
Consumer
XD-LAB
Document
XDS or XDR or XDM sharing
infrastructure
ATNA Security
infrastructure
CT
Francois Macary, Agfa HealthCare
IHE España 2014
XDS Laboratorio
Estructura de un informe de laboratorio CDA
 Los resultados se estructuran en

Header
secciones en función de la
especialidad 18767-4: Blood gas
Arterial blood gas
 Dentro de una especialidad los pO2 (mm Hg) 85
resultados se organizan en pCO2 (mm Hg) 35
secciones de tipo “reported
B
Mandatory <entry>
item” (battery, specimen study,
individual test). O
– La relación entre reported item 18719-5: Chemistry
y especialidad no está regulada, D
Electrolytes
se deja a extensiones
Na (mmol/l) 141
nacionales
 Al final de cada subsección (leaf
K (mmol/l) 4.4 Y
Mandatory <entry>
section) hay obligatoriamente
una <entry> que lleva los Glucose (g/L) 0.5
resultados estructurados y
Mandatory <entry>
codificados
IHE España 2014
XDS Laboratorio
Cuerpo
 seccion 'reported item'

 Hay cuatro templates para la
– Single specimen battery
– Individual test
– Challenge study (dynamic function test)
– Microbiology
 Cada sección 'reported item' debe contener
– Un bloque de texto
– Una entry
– Obligatoriamente el bloque de texto tiene que contener la información de
la entry
 Hay un único template de <entry>
IHE España 2014
XDS Laboratorio
Restricciones en el Body
 Vocabularios admitidos para las entries

– HL7 vocabulary domains (e.g. specimen type, patient gender …)
– SNOMED CT
– Para test codes:
 LOINC subset
 SNOMED CT
 National terminologies (p.ej. en Japón)

IHE España 2014
CONTENIDO: PATIENT CARE COORDINATION Y LOS MEDICAL SUMMARIES

IHE España 2014
IHE y la HCE compartida: El perfil XDS PCC - Introducción
Perfiles del dominio Patient care coordination (2009)
EMS Transfer Medical Summary

of Care XPHR
Exchanging Antepartum Antepartum Labor and
Contenido
EDR physical HR Care summary Record Delivery

Emergency content Record
Department
Referral
Emergency Functional Inmmunization

Patient Plan of Clinical
Department Status Registry
Care Research
Encounter Assessments Content
Record
Care Management Query for Existing 2005 2006

Data
2006 2007
Integración
Query for Clinical

Guidance 2007 2008
2008 2009
2008 2009
IHE España 2014
¿qué es un medical summary?
 Un documento clínico que

– contiene en forma resumida la información más importante de la historia de
un paciente
– se crea en un momento en el tiempo en el que se transfiere la atención del
paciente de un proveedor a otro
 Posibles orientaciones – transferencia atención
Transferir al paciente
Problem Scope
Broad Permanent
Care
Episode Resumir un episodio
Collaborative Care
Care
Focused Pedir ayuda para el manejo del paciente
Focused Broad
Intended Audience
IHE España 2014
IHE y la HCE compartida: El perfil XDS Medical summaries
Medical summaries
 El perfil define el formato de un documento resumen de historia

('medical summary')
– Cuando ese documento se comparte usando XDS se habla del perfil Cross
enterprise sharing of Medical summaries
 Contiene información esencial para el proveedor sanitario
 Como mínimo un Medical Summary debe contener
– Problemas
– Alergias
– Medicación
– Enlaces a otro material
 El marco técnico incluye una serie de plantillas (templates)

– Restricciones para codificar medicación, alergias y problemas (nivel 3)
IHE España 2014
Encabezado
Siempre estructurado y codificado
Paciente, Autor, Institución, Autenticador
(persona que firma el documento), etc.
El cuerpo tiene una estructura

Cuerpo estandarizada, con secciones
predefinidas, cuyo nombre esta
Estructurado, con secciones codificadas
codificado
Motivo de consulta
Hay secciones cuyo título está codificado,
Signos vitales pero cuyo contenido no está estructurado ni
Medicación codificado (texto, listas, tablas)
Texto estructurado Las otras secciones (medicación, problemas

Sección
Sección codificada y alergias) deben obligatoriamente contener
Texto
Entry texto estructurado y codificado.
estructurado También están estandarizado a nivel más
Estudios Sección detallado, las secciones y entries
Alergias
Texto estructurado
Sección
Sección codificada
Historia socialEntry
Problemas
Texto estructurado
Sección
Sección codificada
Entry
Plan de cuidado
IHE España 2014
Marco técnico PCC

 PCC Technical Framework,
– Volume 3
 Contenido general del Medical summary
 Códigos LOINC para los títulos de sección
 Contenido estructurado para entries CDA Level 3.
– Extensiones Nacionales
 Títulos específicos de sección
 Elementos específicos Nivel 3 (p.ej. Diagnóstico/problemas)
 US (publicada), francesa e italiana (en desarrollo)
 Próximamente España
 IHE esta definiendo una librería de componentes reutilizables (templates)

– Tipos de documento
– Secciones (solo se codifica el título)
– Entries (clinical info semantically coded)
– Si existe algo equivalente en el Continuity of Care Document (CCD) de HL7/ASTM se
reutiliza
IHE España 2014
CONTENIDO: XDS SCANNED DOCUMENT

IHE España 2014
IHE y la HCE compartida: El perfil XDS XDS SD
XDS-SD Cross-sharing of scanned documents
 Mínima definición posible del conenido del documento

– Escenario: Intercambio de documentos escaneados
 Texto: escrito a mano, informes antiguos
 Gráficos
 Documentos electrónicos (pdf)
 Definición del contenido

– Documento CDA
– Encabezado
 Necesario para mantener la integridad y la información del contexto en
el que fue creado el documento.

– Contenido PDF o texto plano
IHE España 2014
XDS-SD Ejemplo de encabezado
<ClinicalDocument xmlns=“urn:hl7-org:v3”>
<typeId extension="POCD_HD000040"
root="2.16.840.1.113883.1.3"/>
<id root=“1.3.6.4.1.4.1.2835.2.7777”/>
<code code=“34133-9”
codeSystem=“2.16.840.1.113883.6.1”
codeSystemName=“LOINC”
displayName=“SUMMARIZATION OF EPISODE NOTE”/>
<title>Good Health Clinic Care Record Summary</title>
<effectiveTime value=“20050329224411+0500”/>
<confidentialityCode code="N"
codeSystem="2.16.840.1.113883.5.25"/>
<languageCode code=“en-US”/>

IHE España 2014
XDS-SD Ejemplo de cuerpo
<component>
<nonXMLBody>
<text mediaType=“application/pdf”
representation=“B64”>
JVBERi0xLjMKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdG
VyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nGWPMWsDMQyFd/8KjfJwqmVb
kr0GQqFbg7fQoSRNWuhB
...
RjRDQzdBRUI1NEIzNkZCMjgzQzVDMzI0NzlBRDI4M0Y+XQo+PgpzdGFydH
hyZWYKMzAx MgolJUVPRgo=
</text>
</nonXMLBody>
</component>
</ClinicalDocument>

IHE España 2014
CONTENIDO: XDS - IMÁGENES

IHE España 2014
IHE y la HCE compartida: El perfil XDS XDS Imaging
XDS Imaging
 Se utiliza la infraestructura XDS para compartir información de

imágenes entre diferentes organizaciones
 La información de imagen que se comparte incluye:

– Conjuntos de instancias DICOM, incluyendo la propia imagen, documentos
de evidencia y estados de presentación (presentation states)
– Informes diagnósticos en formato “para mostrar” (no para importar o
procesar)
– Selección de imágenes significativas desde el punto de vista diagnóstico
asociadas con el contenido de un informe
Ventajas: usar la misma infraestructura XDS ( registro y repositorio) para

acceder a cualquier información (p.ej. Informe de laboratorio) y la imagen
IHE España 2014
XDS-I: Dos implementaciones posibles
 Lo que clínicamente interesa compartir es el examen, no la imagen

 ¿Cómo compartir el examen?
– Sharing of extensive Dicom Instance set
 Serie de imágenes en formato Dicom
 Se comparte un Dicom Manifest
– Sharing of Imaging Report

 Se comparte un Informe (PDF, Texto) que puede incluir las imagenes
más relevantes del estudio (no toda la serie)

– Incrustadas en el informe
– Como una url (dicom wado)
IHE España 2014
Sharing of Extensive DICOM Instance Set

Document
Registry
Register Manifest
Query Registry
DICOM Manifest
Reference to image 1
Document Repository Retrieve Manifest
Manifest
Reference Manifest
to image 3 Manifest
Manifest
Retrieve Images DICOM Manifest
Manifest
ReferenceClinical
to imageIT 3
System
Clinical Encounter
IHE España 2014
Sharing of Extensive DICOM Instance Set
 El documento que se comparte es un “manifest”

– un documento con una lista de punteros a las imagenes que representa
– Técnicamente : una instancia del objeto DICOM Key Object Selection (KOS)
 Requisitos para el Image Manager/Image Archive

– Asegurar que las imagenes a las que se hace referencia desde un manifest
que ha sido publicado en un repositorio están disponibles para ser
recuperadas
 Requisitos para el Document Source

– Reemplazar un manifest enviado previamente cuando haya algun cambio
del contenido de dicho manifest (por ejemplo cambio de DICOM SOP
instances referenciadas dentro del manifest)
IHE España 2014
Sharing of Document
Imaging Report Registry
Register Report
Query Registry
Document Repository Retrieve Report
Report Report
Report
Header: Radiology Report
Report Type: OB / Gyn

…..
Radiology system
Report Source Findings: BPD
Clinical IT
...
System
…..
Impressions: Gestational Clinical Encounter

Age
...
IHE España 2014
Sharing of Imaging Report
 Cómo enlazar un informe con imagenes concretas seleccionadas
Header: Radiology Report
Report Type: OB / Gyn

…..
Findings: BPD
...
…..
Gestational
WADO URI
Age
Link
... to image
Relevant Image
Radiology system
Report Source
IHE España 2014
Sharing of Imaging Report
 Lo que se comparte es un informe, con alguno de los siguientes

formatos
– PDF, Text, or multipart PDF + Text
 El informe puede incluir imágenes:
– Una selección de imágenes significativas, no toda la serie
– Dos opciones
 Imágenes en el PDF
 Hiperlinks (fully resolved) sobre los que se pueda pinchar para
recuperar la imágen
 El Document Source es responsable de

– Formatear el hiperenlace para referenciar las imágenes como una URI
DICOM WADO
– Asegurar que las referencias a imágenes son enlaces válidos
IHE España 2014
XDS-I Actores y Transacciones
Patient
Identity Source
Patient Identity
Feed
Query
Document Documents Document
Registry Consumer
Register
Document Set
Provide & Register Retrieve

Document source Document Set Document
Document
Repository
Image Manager Retrieve Images
Image Archive Retrieve Presentation States
Retrieve Key Image Note
Retrieve Evidence Documents
WADO Retrieve
IHE España 2014
Requisitos para los actores XDS-I
 Adicionales con respecto a los actores XDS :

– Document Consumer
 Debe ser capaz de recuperar imagenes al menos de una de las dos
formas siguientes:
– C-Move (servicio C-Move de dicom)
– WADO (web access to dicom instances – Dicom Part 18): permite
recuperar jpgs para browsers sencillos o imágenes dicom
completas.
– Document Source
 Provide and Register Document Set
 Al menos una de las siguientes opciones
– Extensive Set of DICOM Instances, PDF Report, Text Report,

Multipart Text/PDF Report
 Adicionales con respecto a los actores de radiología
– Image Manager / Image Archive
 WADO Retrieve
IHE España 2014
Metadatos XDS-I
 Específicos de imagen
– Modalidad de adquisición (e.g. CT, MR)
– Region Anatómica (e.g. Arm, Elbow, Hand)
– Procedimiento petición (MRI de rodilla con contraste)
 Ejemplo de query
– Encontrar todas las CT de cabeza para el paciente Juan Pérez en los últimos
dos años
IHE España 2014
CONSENTIMIENTOS SOBRE PRIVACIDAD – BÁSICO

BASIC PATIENT PRIVACY CONSENTS (BPPC)
IHE España 2014
IHE y la HCE compartida: El perfil XDS BPPC
Basic Patient Privacy Consents
 Este perfil permite gestionar la privacidad de documentos en un

escenario XDS:
– Registrar el consentimiento de cada paciente en lo que respecta a la
privacidad de los documentos
– Marcar los documentos publicados en XDS con el consentimiento específico
que se usó para autorizar la publicación.
– Utilizar el consentimiento de privacidad apropiado al uso
 Aplicable a
– Document Sources y Document Consumers en un dominio de afinidad XDS
– Document Sources y Document Receivers usando XD Point-to-Point
Document Sharing
IHE España 2014
IHE y la HCE compartida: El perfil XDS Patient privacy consent
Perfil Basic Patient Privacy Consent
Consentimiento A
(restringido)
Consentimiento B
(abierto)
Profesional X.
Repositorio XDS Puede acceder a los
documentos
marcados con
Consentimieto A y
Informe Visita 1 – ginecología B
(Para acceder, es necesario
consentimiento A)
Informe Visita 2 – otorrino

Profesional Y.
(Para acceder, basta con consentimiento B Sólo puede acceder a los documentos marcado
con Consentimieto B. Los otros no los ve e
el repositorio
IHE España 2014
IHE y la HCE compartida: El perfil XDS BPPC
Basic Patient Privacy Consents
 Un dominio de afinidad puede

– Desarrollar políticas de privacidad
– Implementar estas políticas con diferentes mecanismos de acceso (basados
en roles,…)
 Un paciente puede
– Ser informado de las políticas de privacidad de una institución
– Tener la opción de controlar el acceso a su información de salud de manera
selectiva
 Documentos de consentimiento
– Legibles para humanos
– Procesables por máquina
IHE España 2014
GRADO DE DIFUSIÓN ACTUAL DE XDS

IHE España 2014
Implementaciones de IHE en la actualidad
 Fuente Charles Parisot: Pre connectaton 2010 workshop

IHE España 2014
SOFTWARE PARA DESARROLLO Y PRUEBAS

IHE España 2014
Pruebas
 Software proporcionado a los participantes del connectathon

– Mesa tools
 Pruebas pre-connectathon
 http://ihe.univ-rennes1.fr/testing
– Gazelle
 Integra todas las pruebas
– Pre-connectathon, post-connecthaton y entre vendedores

 Puede ser usado por terceros para verificar
IHE España 2014
Pruebas
 Registro y repositorio XDS NIST Public Registry server

– Registro y repositorio público
– Alojado por NIST (National Institute of Standards -USA)
– Un document source puede enviar documentos al registro remoto (submit)
– Un documen consumer puede recuperar documentos (query and retrieve)
– Herramienta java para enviar datos y hacer queries
– Log browser para facilitar pruebas
– http://ihexds.nist.gov
IHE España 2014
Pruebas: validación del contenido del documento (CDA)
 NIST
– http://xreg2.nist.gov/cda-validation/validation.html
 Aschuler Associates
– http://www.alschulerassociates.com/validator/
Fuente: Presentation Majurski

IHE España 2014
Desarrollo: Software Open source XDS (Registro y repositorio) - Resumen
 (actualizado 2012)
 Proyecto ‘IheOs’ IHE open source
– Distintos actores, incluyendo todos los de xds: Registry, Repository, Source
and Consumer
– Es la implementación de NIST-Bill majurski
– Java
 Microsoft
– Document Repository and Document Registry
– Codeplex
 Ha pasado el CAT
 Eclipse Open Healthcare Framework (OHF) Project

– Código suplementario para eclipse, que implementa los actores y modelos
de datos de IHE
– Document Source and Document Consumer solamente
– Proyecto archivado en enero 2012

IHE 02 IntroXDS 2014

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

IHE 02 IntroXDS 2014

Cargado por

Copyright:

Formatos disponibles

IHE y la historia clínica electrónica

 La propuesta de IHE para compartir documentos: el perfil Cross

PERFIL CROSS ENTERPRISE DOCUMENT SHARING (XDS)

Propuesta de IHE: Modelo registro – repositorio

Escenario: intercambio de documentos clínicos

 Objetivo : intercambio de documentos clínicos

La forma tradicional de compartir información clínica es basada en

¿Qué es un documento para XDS?

 Conjunto de información clínica (estructurada o no)

 Un documento debe estar asociado con unos metadatos para ser

Escenario: Dominio de afinidad

 Objetivo : intercambio de documentos clínicos en un dominio de

 Políticas comunes de confidencialidad

 Infraestructura común de comunicaciones

Algunos metadatos almacenados en el registro XDS

 Sobre el origen del documento (Origin):

 Identificación del documento (Identification):

 Clasificación del documento (Classification):

– Obligatorio, Obligatorio si se conoce, Generado por el repositorio, Recomendado

Principios en los que se basa XDS -1

 Centrado en los documentos

Principios en los que se basa XDS -2

XDS : Concepto de Care delivery vs longitudinal Record

 EHR-CR : Care-delivery Record

 EHR-LR : Longitudinal Record

Perfil XDS: Diagrama de actores y transacciones

Perfil XDS: Diagrama de actores y transacciones (inglés)

Transacciones del perfil:

Adaptado de Charles Parisot. GE

Actores del perfil XDS

 Enlace al lugar donde se encuentra realmente el documento

– Responde a consultas (queries) de acuerdo con unos determinados metadata

XDS: Registrar un documento

No se envía un documento solo, sino

Document Transmisión: http

Adaptado de Charles Parisot. GE

XDS: Buscar y recuperar un documento

Adaptado de Charles Parisot. GE

Gestión de los metadatos

Arquitectura Registro / Repositorio: ebXML

 IHE elige los estándares más adecuados para cada perfil

 ebXML: Electronic Business using eXtensible Markup

 ebXML son dos estándares:

 XDS sólo utiliza una pequeña parte de la funcionalidad de ebXML

 ebRIM – Registry Information Model

– Los documentos XDS se representan como objetos ebRIM

– RegistryObject = top level class

ebRIM y ebRS -II

– Recuperar un documento del repositorio

 El repositorio recibe un documento, lo almacena y lo registra en el

 Luego debe ser capaz de servir el documento como respuesta a una

¿Cómo consultar el registro?: Consultas (Queries)

 Una query devuelve:

Software Foundation (OSF)

XDS – Agrupación de documentos: envío y almacén

Adaptado de Charles Parisot. GE

Estados de un documento XDS en el registro

Representación en ebRIM de los objetos XDS

 Usando los objetos y asociaciones definidas en el ebRIM

 Submission Set y documentos que contiene

Gestión de versiones de un documento

Submission Set Association Document

Submission Set Association Document