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

Outline

XDS

Introduction to XDM/XDR

XDM

XDR

Summary

References

XDSCross-Enterprise Document Sharing

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

XDS Affinity Domain

PMS

Physician Office

EHR System

Teaching HospitalCommunity

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

ATNA

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

A87631M8354673993

A8763114355L-716

Patient Identity XRef Mgr

Record AuditEvent

55

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

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

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

ConsumerConsumerRegistryRegistry

RepositoryRepository

11. Sources post . Sources post document packages document packages to the Repositoryto the Repository

22. Repository registers . Repository registers the documents the documents metadata and pointer metadata and pointer with the Registrywith the Registry

33. Consumers search . Consumers search for documents with for documents with specific informationspecific information

44. Consumers retrieve . Consumers retrieve selected documents selected documents from Repository (-ies)from Repository (-ies)

XDS Document (Metadata):

ClassPatient IdAuthorFacilityDate of Service…

XDS Document (Metadata):

ClassPatient IdAuthorFacilityDate of Service…

Source Source of of DocumentsDocuments

XDS Flow and Interactions

99

XDS Transaction Diagram

Patient Identity Patient Identity SourceSource

Document Document RegistryRegistry

Document Document RepositoryRepository

Document Document SourceSource

Document Document 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&RegisterDocument 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

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

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

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

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

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 ConsumerBasic Patient Privacy Enforcement

ITI TF-2a: 3.18.4.1.3.5ITI TF-2b: 3.43.4.1.3.1

Basic Patient Privacy Proof ITI TF-2a: 3.18.4.1.3.6

1515

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

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

Introduction to XDM/XDRPoint-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

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

XDMCross-Enterprise Document Media Interchange

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

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

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

XDMActors & 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

XDMOptions

• 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.

XDM

26

XDM Push of Health Information

PhysicianOffice

Hospital

Discharge summary +Lab report

Write

Read

InterchangeMedia Discharge summary

+ Lab report

Read

Home

Including Email

27

XDMStandards 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

XDMSecurity & 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.

XDM ReferencesPrimary 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

XDRCross-Enterprise Document Reliable Interchange

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

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

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

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

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

XDR

36

Send Over Web Services Receive

A referral summary A referral summary

SpecialistOffice

PhysicianOffice

XDR Exchange of Health Information

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

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

XDR ReferencesPrimary 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

XDM

XDR

XDS

40

Publish Query/Retrieve

Send to

Existing Reliable

Messaging System Receive

WriteRead

Interchange Media

M8354673993

A8763114355L-716

XDS INFRASTRUCTUR

E

XCAQuery/Retrieve

Including Email

M8354673993

A8763114355L-716

XDS INFRASTRUCTUR

E M8354673993

A8763114355L-716

Other INFRASTRUCTUR

E

Document Document SourcesSources

Document Document Consumers/ Consumers/

RecipientsRecipients

Health Document Exchange OptionsFlexible Infrastructure

More Information

41

IHE Web site: www.ihe.net IHE official materialTechnical 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/committeesAt the bottom of the page is a place to join the mailing list

42

THANK YOUTHANK YOU