The document provides an overview of the Integrating the Healthcare Enterprise (IHE) Integration Profile called Cross-Enterprise Document Sharing (XDS). XDS allows for the registration, distribution and access of patient electronic health records across different healthcare organizations. It defines standards for managing the sharing of clinical documents between any healthcare enterprise, regardless of where the documents or systems reside. The document describes the main XDS actors, transactions, use cases and technical standards involved in cross-enterprise clinical document sharing using XDS.

1. September, 2005 What IHE Delivers
XDS, XDM / XDR
Point-to-Point Push of
Documents
Understanding IHEUnderstanding IHE
By Raghu KodumuriBy Raghu Kodumuri
112-12-201312-12-2013

2. 2
Outline
XDS
Introduction to XDM/XDR
XDM
XDR
Summary
References

3. XDS
Cross-Enterprise Document Sharing

4. What is XDS ?
The Cross-Enterprise Document Sharing (XDS)
IHE Integration Profile facilitates the registration, distribution
and access across health enterprises of patient electronic
health records
It provides a standards-based specification for managing the
sharing of documents between any healthcare enterprise
44

5. XDS Affinity Domain
PMS
Physician Office
EHR System
Teaching Hospital
Community Clinic
Lab Info.
System
PACS
PACS
Retrieve Document
Provide &
Register
Register Document
(using Patient ID)
Query Document
(using Patient ID)
Document
RegistryDocument
Repository
Document
Repository
ED Application
PIX or PDQ
Query
PIX or
PDQ
Query
ATN
A
CT
Audit record repository Time server
Patient Demographics Supplier
Record Audit Event
Maintain
Time
Maintain
Time
Maintain
Time
XDS Workflow
Health Information Exchange Network
14355M8354673993
L-716
A87631
M8354673993
A8763114355L-716
Patient Identity XRef Mgr
Record Audit
Event
55

6. XDS Affinity Domains
Group of healthcare enterprises that have agreed to work together using a
common set of policies and XDS-based infrastructures for sharing patient
clinical documents. Some examples are:
•Regional community of care
•Nationwide EHR
•Specialized or disease-oriented (cardio, diabetes, oncology)
•Government-sponsored or federation of enterprises
•Insurance provider supported communities
XDS profile is designed to accommodate a wide range of policies on:
•Patient identification and consent
•Controlling access to information
•Format, content, structure, and representation of clinical information
66

7. Use Cases
• Patient Care Summary (e.g. within a region)
– Publishing of Care Summaries by providers
– Access to patient’s Care Summary in an emergency
• eReferral between primary and secondary care providers
• Sharing of radiology reports and images between facilities
• Sharing of laboratory reports by clinical laboratories with
ordering physicians and other care providers
• ePharmacy between community pharmacy and
ambulatory physicians
77

8. Main Systems and Responsibilities
• A document Repository is responsible for storing documents in
a transparent, secure, reliable and persistent manner and
responding to document retrieval requests.
• A document Registry is responsible for storing information or
metadata about those documents so that the documents of
interest for the care of a patient may be easily found, selected
and retrieved irrespective of the repository where they are
actually stored.
• Any IT system (e.g. point of care) may act as a Document
Sources or Document Consumers submitting documents for
registration, or querying/retrieving relevant documents.
Notes:
• Analogous to a library (book repository) and catalog/index
• The Registry does not have access to the documents – an important
separation from security and privacy perspective
• Multiple Repositories can be linked to one Registry
88

9. ConsumerConsumerRegistryRegistry
RepositoryRepository
11. Sources post. Sources post
document packagesdocument packages
to the Repositoryto the Repository
22. Repository registers. Repository registers
the documentsthe documents
metadata and pointermetadata and pointer
with the Registrywith the Registry
33. Consumers search. Consumers search
for documents withfor documents with
specific informationspecific information
44. Consumers retrieve. Consumers retrieve
selected documentsselected documents
from Repository (-ies)from Repository (-ies)
XDS Document
(Metadata):
Class
Patient Id
Author
Facility
Date of Service
…
XDS Document
(Metadata):
Class
Patient Id
Author
Facility
Date of Service
…
SourceSource ofof
DocumentsDocuments
XDS Flow and Interactions
99

10. XDS Transaction Diagram
Patient IdentityPatient Identity
SourceSource
DocumentDocument
RegistryRegistry
DocumentDocument
RepositoryRepository
DocumentDocument
SourceSource
DocumentDocument
ConsumerConsumer
Patient Identity Feed [ITI-8]Patient Identity Feed [ITI-8]
Patient Identity Feed HL7v3 [ITI-44]Patient Identity Feed HL7v3 [ITI-44]
Provide&RegisterProvide&Register
Document Set-b [ITI-41]Document Set-b [ITI-41]
Retrieve Document Set [ITI-43]Retrieve Document Set [ITI-43]
Registry Stored Query [ITI-18]Registry Stored Query [ITI-18]
Register Document Set-b [ITI-42]Register Document Set-b [ITI-42]
Integrated Document Source/RepositoryIntegrated Document Source/Repository
1010

11. XDS Actors
• Document Source – producer and publisher of documents, responsible for
sending documents and their metadata to a Document Repository actor
• Document Repository is responsible for both the persistent storage of these
documents as well as for their registration with the appropriate Document Registry
• Document Registry maintains metadata about each registered document and a
link to the Document in the Repository where it is stored. Responds to queries from
Document Consumer actors about documents meeting specific criteria.
• Document Consumer queries a Document Registry for documents meeting
certain criteria, and retrieves selected documents from one or more Document
Repository actors
• Patient Identity Source provides unique identifier for each patient and maintaining
a collection of identity traits. This facilitates the validation of patient identifiers by
the Registry Actor in its interactions with other actors
• Integrated Document Source/Repository combines the functionality of the
Document Source and Document Repository actors into a single actor that does not
expose the Provide and Register Document Set transaction
1111

12. XDS Transactions (1)
• Provide and Register Document Set – For each
document in the submitted set, the Document Source Actor
provides both the documents as an opaque octet stream
and the corresponding metadata to the Document
Repository. The Document Repository is responsible to
persistently store these documents, and to register them in
the Document Registry using the Register Documents
transaction.
• Register Document Set allows a Document Repository
Actor to register one or more documents with a Document
Registry, by supplying metadata about each document to
be registered. This document metadata will be used to
create an XDS Document Entry in the registry.
1212

13. XDS Transactions (2)
• Patient Identity Feed conveys the patient identifier and
corroborating demographic data, in order to populate the
Document Registry with patient identifiers that have been
registered for the XDS Affinity Domain. (At least one of the
options [ITI-8] or [ITI-44] must be supported.)
• Registry Stored Query is issued by the Document Consumer
Actor to a Document Registry. It will return registry metadata
containing a list of document entries found to meet the specified
criteria including the locations and identifier of each
corresponding document in one or more Document
Repositories.
• Retrieve Document Set – initiated by a Document Consumer.
The Document Repository shall return the document set that
was specified by the Document Consumer.
1313

14. XDS Document Content Types
XDS profile is content agnostic – it can be used with a variety
of document types, including:
•XDS-SD: Scanned document, plain text or PDF/A, in HL7
CDA R2 format
•XDS-MS: Medical summary in HL7 CDA format
•XDS-I: Radiology report in plain text of PDF format, or
reference to a collection of DICOM SOP Instances in a
manifest document in the DICOM Key Object Selection
format
Also supported are many other document content profiles
specified by the IHE Patient Care Coordination, Laboratory,
Cardiology, Pharmacy Technical Frameworks
1414

15. XDS – Actors and Options
ActorsActors OptionsOptions ReferenceReference
Document Source
Document Replacement ITI TF-1: 10.2.1
Document Addendum ITI TF-1: 10.2.2
Document Transformation ITI TF-1: 10.2.3
Folder Management ITI TF-1: 10.2.4
Basic Patient Privacy Enforcement ITI TF-2b:3.41.4.1.3.1
Document Repository
Document Registry
Patient Identity Source
Patient Identity Feed ITI TF-2a: 3.8
Patient Identity Feed HL7v3 ITI TF-2b: 3.44
Document Consumer
Basic Patient Privacy Enforcement
ITI TF-2a: 3.18.4.1.3.5
ITI TF-2b: 3.43.4.1.3.1
Basic Patient Privacy Proof ITI TF-2a: 3.18.4.1.3.6
1515

16. Standards Used
• ebRIM OASIS/ebXML Registry Information Model v3.0
• ebRS OASIS/ebXML Registry Services Specifications v3.0
• ITI TF-2x: Appendix V
– WS-I Profiles BP 1.1, BSP 1.0
– WS-* Specifications (SOAP 1.2, MTOM/XOP)
1616

17. Security and Privacy Considerations
• All actors be grouped with a ATNA Secure Node Actor or
Secure Application Actor resulting in each node (systems
supporting XDS actors) of the XDS Affinity Domain should
have audit and security mechanisms in place
• Transactions between different secure nodes that use
ATNA are encrypted
• Each XDS Transaction will result in an audit event record
sent to an ATNA Audit Record Repository Actor from each
XDS actor
• Timestamp consistency is provided by Consistent Time
(CT) profile
1717

18. 18
Introduction to XDM/XDR
Point-to-Point Push of Documents refers to:
 Cross-Enterprise Document Media Interchange (XDM)
 Cross-Enterprise Document Reliable Interchange (XDR)
Based on XDS
 XDM = push of XDS metadata and documents on media/email
 XDR = push of XDS metadata and documents over SOAP
 Maximal re-use of XDS objects & meta-data
As with XDS both are “document content agnostic”
 Provides a framework for use of content profiles (e.g., XDS-MS, XD-
Lab, XPHR, etc.)
When to use
 When document sharing infrastructure not in place
 Where XDS is not desirable or available to one of the participants
 Complementary to sharing documents via XDS

19. Use Cases XDM / XDR
19
SpecialistPrimary Care
Extended Care
Hospital
11 Primary refers patient to specialist (XDR)
Specialist sends summary report back (XDR)
22
Primary refers patient to hospital (XDR)
33
Remote
advice
(XDM
using
Email)
44
55
Hospital sends discharge summary back (XDR)
66
Patient Transfer to Extended Care Facility
(XDM using media) 77
Summary
report to
Primary
(XDM
using
media)
88

20. 20
XDM
Cross-Enterprise Document Media Interchange

21. 21
XDM
Documents and metadata shared using standard
media types (e.g., email, CD, USB)
Intended to be easy to implement using:
 Existing email clients
 CD burners
 USB ports
Meant for person-to-person communication
 In pocket media
 Send via email
Imposes common file and directory structure

22. 22
XDM
Supports transfer of data about multiple patients
within one exchange
 Multiple submission sets
Requires recipient to support human intervention
to control importing of data
 Manual operation
Works with XDS
 XDS Query/Retrieve can feed XDM transmission
 Point-to-point push via XDM can feed XDS submission

23. 23
XDM
Use Cases
Physician to Patient to Specialist
• Test result and referral information given to patient on
CD-R to be taken to specialist of his choice.
Patient Visiting ED
• Patient maintains copy of his EHR at home and brings
a memory stick with him to the ED.
Physician to Physician
• Primary physician emails zip file attachment about his
patient to specialist

24. 24
XDM
Actors & Transaction
Portable Media Creator
• Assemble the media content and store it on the media
to be distributed
Portable Media Importer
• Read the Document Submission Set content in order to
access the document(s) and metadata; and perform
import of the documents. This actor may have to create
or convert metadata that was not included on the
media.

25. 25
XDM
Options
• Note 1: At least one of these options is required. To enable better
interoperability, it is highly recommended that the actors support all the
options
• Note 2: This requires the ZIP over Email option.

26. XDM
26
XDM Push of Health Information
Physician
Office
Hospital
Discharge summary
+Lab report
Write
Read
Interchange
Media Discharge summary
+ Lab report
Read
Home
Including Email

27. 27
XDM
Standards
 DICOM PS 3.10 Media Storage and File Format for Data Interchange
(DICOM file format). http://dicom.nema.org/
 DICOM PS 3.12 Media Formats and Physical Media for Data
Interchange, Annex F - 120mm CD-R media, Annex R - USB Connected
Removable Devices, Annex V - ZIP File Over Media, and Annex W -
Email Media. http://dicom.nema.org/
 XHTML™ 1.0 The Extensible HyperText Markup Language (Second
Edition). A Reformulation of HTML 4 in XML 1.0. W3C Recommendation
26 January 2000, revised 1 August 2002. http://www.w3.org/TR/xhtml1.
 XHTML™ Basic. W3C Recommendation 19 December 2000.
http://www.w3.org/TR/xhtm-basic.
 MDN: RFC 3798 Message Disposition Notification. http://www.rfc-
editor.org/rfc/rfc3798.txt

28. 28
XDM
Security & Privacy
 The Portable Media Importer should check the hash value and size as
found in the XDS metadata to detect corruption within the metadata or
media.
 Basic Patient Privacy Enforcement Option
 In the case the media used is the ZIP file over Email, the transaction
should be secured by S/MIME (see IHE ATNA) and comply with the
security process as defined in the DICOM Part 15 Appendix (Secure Use
of ZIP File Media over Email)
 Portable Media Importers/Exporters that import/export media should
generate one or more ATNA “Import”/”Export” events into the audit trail to
describe the media event.
 Document Encryption Supplement includes both Document encryption
and XDM media encryption.

29. XDM References
Primary
ITI TF-1 Section 16 Cross-Enterprise
Document Media Interchange (XDM)
Underlying Technical Framework Content
 ITI TF-2b
• Section 3.32 Distribute Document Set on Media
 ITI TF-2x
• Appendix T Use of eMail (Informative)
 ITI TF-3
• Section 4.1 XDS Metadata Model
Supplement supporting Limited Metadata
 Support for Metadata-Limited Document Sources
29

30. 30
XDR
Cross-Enterprise Document Reliable Interchange

31. 31
Documents and metadata pushed using a SOAP protocol
Permits directed push between EHRs, PHRs, and other health
IT systems in the absence of XDS or XCA infrastructure
Allows for transfer of documents for a single patient (one
submission set)
Supports the reuse of the Provide and Register Document set
(ITI-41) with web services as transport
Complementary to XCA’s point-to-point query infrastructure by
providing directed push mechanism using the same underlying
standard.
XDR

32. 32
More like XDS than XDM
 Direct transfer between source and recipient
 No registry or repository actors involved
Works with XDS
 XDS Query/Retrieve can feed XDR transmission
 Point-to-point push via XDR can feed XDS submission
XDR

33. 33
Use Cases
 Primary Physician to Specialist
• Referral information for patient sent to specialist
ahead of visit
 Hospital to Long-term Care
• Patient summary information sent to long-term care
facility upon patient transfer from hospital
 Physician to Physician
• Patient MRI test results sent from physician in
specialized care facility to another specialist for
consultation
XDR

34. 34
Document Source
 A system that submits documents and associated metadata to a Document
Recipient
Metadata Limited Document Source
 A system that submits documents and associated metadata similar to a Document
Source but is limited in the quantity of metadata it is able to provide.
Document Recipient
 A system that receives a set of documents and makes it available to the intended
recipient (who can choose to view it or integrated it into the EHR)
XDR – Actors & Transactions

35. 35
XDR - Options
Actor Options Vol & Section
Document Source Basic Patient Privacy
Enforcement
ITI-TF-2b: 3.41.4.1.3.1
Metadata-Limited
Document Source
Basic Patient Privacy
Enforcement
ITI-TF-2b: 3.41.4.1.3.1
Document Recipient Basic Patient Privacy
Enforcement
Accepts Limited
Metadata
ITI-TF-2b: 3.41.4.1.3.1
ITI TF-1:15.2.3

36. XDR
36
Send Over Web Services Receive
A referral summary A referral summary
Specialist
Office
Physician
Office
XDR Exchange of Health Information

37. 37
Standards
 ebRIM - OASIS/ebXML Registry Information Model v3.0
 ebRS- OASIS/ebXML Registry Services Specifications v3.0
 ITI TF-2x: Appendix V Web Services for IHE Transactions.
Contains references to all Web Services standards and
requirements of use
 MTOM - SOAP Message Transmission Optimization
Mechanism http://www.w3.org/TR/soap12-mtom/
 XOP - XML-binary Optimized Packaging
http://www.w3.org/TR/2005/REC-xop10-20050125/
XDR

38. 38
Security & Privacy
 Basic Patient Privacy Enforcement Option
 ATNA Secure Node required for both actors
 Management of patient identification in order to perform
patient reconciliation correctly upon importation of
documents.
 Relevant XDS Affinity Domain security considerations are
discussed in the XDS Security Considerations Section
(see ITI TF-1: 10.7)
XDR

39. XDR References
Primary
 ITI TF-1
• Section 15 Cross-Enterprise Document Reliable Interchange (XDR)
Underlying Technical Framework Content
 ITI TF-1
• Appendix J Content and Format of XDS Documents
• Appendix K XDS Concept Details
 ITI TF-2b
• Section 3.41 Provide and Register Document Set-b
 ITI TF-2x
• Appendix V “Web Services for IHE Transactions”
 ITI TF-3
• Section 4.1 XDS Metadata Model
Supplement supporting Metadata-Limited Document
Sources
 Support for Metadata-Limited Document Sources
39

40. XDM
XDR
XDS
40
Publish Query/Retrieve
Send to
Existing Reliable
Messaging System Receive
Write
Read
Interchange Media
M8354673993
A8763114355L-716
XDS
INFRASTRUCTURE
XCA
Query/Retrieve
Including Email
M8354673993
A8763114355L-716
XDS
INFRASTRUCTURE
M8354673993
A8763114355L-716
Other
INFRASTRUCTURE
DocumentDocument
SourcesSources
DocumentDocument
Consumers/Consumers/
RecipientsRecipients
Health Document Exchange Options
Flexible Infrastructure

41. More Information
41
IHE Web site: www.ihe.net
 IHE official material
Technical Framework documents
IHE Wiki site: wiki.ihe.net
 IHE committee pages
 Implementation Notes
 Ongoing committee work
IHE ITI technical committee mailing list
 http://www.ihe.net/IT_infra/committees
At the bottom of the page is a place to join the mailing list

42. 42
THANK YOUTHANK YOU