Upload
lewis-chadbourne
View
229
Download
0
Tags:
Embed Size (px)
Citation preview
Publication and DiscoveryXDS and DSUB
IHE IT Infrastructure Webinar Series
IT Infrastructure Planning Committee
XDSCross-Enterprise Document Sharing
IT Infrastructure Planning Committee
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
Currently only one XDS profile, based on Web Services - XDS.b (original XDS.a is now deprecated)
IT Infrastructure Planning Committee
XDS Affinity Domains
Group of healthcare enterprises that have agreed to work together using a common set of policies and standards-based infrastructures for sharing patient clinical documents, using XDS:• 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
IT Infrastructure Planning Committee
Some Common Scenarios
• 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
IT Infrastructure Planning Committee
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
IT Infrastructure Planning Committee
ConsumerRegistry
Repository
1. Sources post document packages to the Repository
2. Repository registers the documents metadata and pointer with the Registry
3. Consumers search for documents with specific information
4. Consumers retrieve selected documents from Repository (-ies)
XDS Document (Metadata):
ClassPatient IdAuthorFacilityDate of Service…
Source of Documents
XDS Flow and Interactions
IT Infrastructure Planning Committee
XDS TECHNICAL OVERVIEW
Cross-Enterprise Document Sharing ProfileActors and Transactions
IT Infrastructure Planning Committee
XDS.b Formal Diagram
Patient Identity Source
Document Registry
Document Repository
Document Source
Document Consumer
Patient Identity Feed [ITI-8]Patient Identity Feed HL7v3 [ITI-44]
Provide&RegisterDocument Set-b [ITI-41]
Retrieve Document Set [ITI-43]
Registry Stored Query [ITI-18]
Register Document Set-b [ITI-42]
Integrated Document Source/Repository
IT Infrastructure Planning Committee
XDS.b 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
IT Infrastructure Planning Committee
XDS.b 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.
IT Infrastructure Planning Committee
XDS.b 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 Domains. (At least one of the options [ITI-8] or [ITI-44] should 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.
IT Infrastructure Planning Committee
XDS Document Content Types
XDS profile is content agnostic – it can be used with a variety of document types, e.g.:• 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
IT Infrastructure Planning Committee
XDS.b – Actors and Options
Actors Options Reference
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.5
ITI TF-2b: 3.43.4.1.3.1
Basic Patient Privacy Proof ITI TF-2a: 3.18.4.1.3.6
IT Infrastructure Planning Committee
Security and Privacy Considerations
• All actors be grouped with a ATNA Secure Node Actor resulting in each node (systems supporting XDS actors) of the XDS Affinity Domain should have audit and security mechanisms in place
• Transactions used between different secure nodes (systems supporting XDS actors) shall use the ATNA Encryption Option
• Each XDS Transaction will result in audit event records sent to an ATNA audit Repository Actor
IT Infrastructure Planning Committee
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
IT Infrastructure Planning Committee
Relevant Standards
Infrastructure: use of Web Services Standards:• WS-* Specifications• WS-I Profiles• ITI TF-2x: Appendix V
Document content• HL7 CDA• CEN ENV 13606• ASTM 4400 CCR• DICOM
IT Infrastructure Planning Committee
Point-to-point Deployment Models
1 - Unknown partners, patient ID out-of-band, labelled document (with meta-data)
------------------------------------
2 - Known partners, patient ID out-of-band, labelled document (with meta-data)
------------------------------------
3 - Known partners, linked patient, labelled document (with meta-data)
IHE Cross-Enterprise Document Exchange - Media Option (XDM): CD or USB-Key
----------------------------------------------------------------
IHE Cross-Enterprise Document Exchange - Email Option (XDM-Email)
--------------------------------------------------------
IHE Cross-Enterprise Reliable Exchange (XDR) w Patient ID Reconciliation (PIX/PDQ)
Moving to the next level
IT Infrastructure Planning Committee
Health Information Sharing Deployment Models
4 - Community HIEMany potential partners, linked
patient, labelled (with metadata) documents
Centralized services (registry/EMPI)
------------------------------
5 – Region/Nation/cross-nation Health Information Network Exchange
IHE Cross-Enterprise Document Sharing (XDS) (On-Demand Document Option and Document Subscription / Notification (DSUB))
IHE Patient ID Cross-reference (PIX) and Patient Demographics Query (PDQ)
--------------------------------------------- IHE Cross-Community
Exchange (XCA) IHE Cross-community
Patient Discovery (XCPD)
IHE addresses 5 transport use cases !
IT Infrastructure Planning Committee
XDS Metadata
Light Client
Health Information Exchange and IHE Profiles
Application Client
IHE XDM (e-mail)
IHE XDR (Web Service)
IHE XCA (cross-HIE)
IHE XDS (Intra-HIE)
Pt-to-PtPush
Share& Pull
IT Infrastructure Planning Committee
Flexible Infrastructure
Health Information Exchange
Publish
PullStructuredobjects
Pull
Send to Switch Send to
Write ReadInterchange
Media
XDS
XDR
XDM
Replace with agreed new version of this slide
IT Infrastructure Planning Committee 23
IHE XDS adopted in National & Regional Projects (sample)
Quebec, Toronto,Alberta, British ColumbiaCanada Infoway
THINC- New YorkNCHICA – N. Carolina
Italy Conto CorrenteVenetto - Friuli
Boston Medical
Center - MA
Philadelphia HIE
CHINA-MoHLab results sharing
CHINA-ShanghaiImaging Info Sharing
JAPAN-NagoyaImaging Info Sharing,
Nationwide PDI guideline
South Africa
VITL-Vermont
CareSpark – TN & VA
NETHERLANDSFriesland
Natn’l Mamography
LowerAustria
Austria
FranceDMPWales
Imaging
BelgiumFlemish-Leuven
SuisseSt GallenLausane
Providence Health
System - OR
KeyHIE Pennsylvani
a
SHARP CA
France Imaging
IDF
23
For more complete list see: tinyurl.com/wwXDS
IT Infrastructure Planning Committee
Who Is Using XDS?
• Stable specification since 2009 (See IHE ITI Technical Framework)
• First implementation in clinical use in region of Genoa - Italy) since early 2006.
• Several since: Lower Austria region, State of Vermont, Nagoya city, South Africa region, Dutch regions, etc.
• Adopted by several national programs world-wide:
France, Canada, Switzerland, USA, Slovenia, China, etc.• Numerous product implementations world-wide:
Close to 100 EMR/Clinical Systems products shipping
More than 20 Infrastructure products shipping
IT Infrastructure Planning Committee
Open Source Implementation Tools
Open source implementations are available for XDS, XCA, XCPD, PIX, PDQ, ATNA, CT, and more:
– NIST under Source Forge http://sourceforge.net/projects/iheos/ – HIE-OS under Source Forge http://sourceforge.net/projects/hieos/
– Microsoft under codeplex http://ihe.codeplex.com/ – FHA CONNECT http://www.connectopensource.org
– OHT – IHE Profiles Charter https://iheprofiles.projects.openhealthtools.org
– OHT – Open Exchange Forge https://openexchange.projects.openhealthtools.org
– OHT – Model Driven Health Tools-Charter https://mdht.projects.openhealthtools.org
25
IT Infrastructure Planning Committee
DSUBDocument Metadata Subscription supplement
IT Infrastructure Planning Committee
DSUB Overview
The Document Metadata Subscription (DSUB) supplement contains two related parts:• Publish/Subscribe Infrastructure: General framework for
defining web-services based publish/subscribe interactions• Document Metadata Subscription (DSUB) Integration
Profile: Use of subscriptions within an XDS Affinity Domain or across communities
IT Infrastructure Planning Committee
Publish/Subscribe Infrastructure
• Presents a framework for building event-driven information exchange patterns using a publish/subscribe data exchange model (See ITI TF Volume 3 section 4.4
• Defines the transport of publish, subscribe and notify messages.
• Supports IHE profiles which define the use case specific content to be carried in the publish, subscribe and notify messages
Document Metadata Subscription (DSUB) first profile to use this framework.
IT Infrastructure Planning Committee
Publish/Subscribe Infrastructure Actors and Transactions
Publisher
Publish 4.4.2.3
Notification Broker
Notification Recipient
SubscriberSubscribe 4.4.2.1
Notify 4.4.2.2
IT Infrastructure Planning Committee
Possible Combined Actors
Publisher
Notification Broker
Notification Recipient
SubscriberSubscribe
Notify
Publish
Publisher
Notification Broker
Notification Recipient Subscriber
Subscribe
Notify
Notification Broker
Notification Recipient Subscriber
Subscribe
Notify
Publisher
IT Infrastructure Planning Committee
Document Metadata Subscription (DSUB) Integration Profile
• Defines a subscription which 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.
• Enabled within an XDS Affinity Domain or XCA environment
• Use Cases– Emergency Department: Notification of new document availability
during treatment– Primary Care Management: PCP receives notification when new
documents for patient are available
IT Infrastructure Planning Committee
DSUB Actors and Transactions
Document Metadata Publisher
Document Metadata Publish [ITI-54]
Document Metadata Notification Broker
Document Metadata Notification Recipient
Document Metadata Subscriber
Document Metadata Subscribe [ITI-52]
Document Metadata Notify [ITI-53]
XDS Registry
IT Infrastructure Planning Committee
Transactions
• Document Metadata Subscribe : start a subscription for a particular topic and filtering within that topic. Supports full and minimal notifications and where to send the notification.
• Document Metadata Notify : send a notification about the availability of a document or documents of interest, based on the subscribers' filters on selected topics
• Document Metadata Publish : notify that an event occurred for which there may be a subscription.
IT Infrastructure Planning Committee
DSUB Illustration of Use
Publisher Notification Broker
Notification Recipient
Subscriber
Subscribe
Publish
Publish
Notify
Notify
Unsubscribe
Publish
IT Infrastructure Planning Committee
DSUB Implementation
• DSUB topic tree– ihe:FullDocumentEntry : subscribes to Document Entry registration
events; the notification shall contain the full metadata describing each matching Document Entry
– ihe:MinimalDocumentEntry : subscribes to Document Entry registration events; the notification shall contain a minimal set of data (identifiers only) describing each matching Document Entry
• DSUB Standards– Web Services Standards
• WS-BaseNotification 1.3 OASIS Standard• WS-BrokeredNotification 1.3 OASIS Standard • WS-Topics 1.3 OASIS Standard• ITI TF-2x: Appendix V
– Filter expression• Registry Stored Query [ITI-18]