Upload
eugene-newton
View
227
Download
0
Tags:
Embed Size (px)
Citation preview
Publication and DiscoveryXDS and DSUB
IT Infrastructure Planning CommitteeIT Infrastructure Planning CommitteeIlia Fortunov Ilia Fortunov - Microsoft- Microsoft
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
3
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
4
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
5
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
6
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
7
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
8
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
9
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.
10
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.
11
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
12
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
13
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)
14
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
15
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
16
XDM
XDR
XDS
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 Sources
Document Consumers/
Recipients
Health Document Exchange OptionsFlexible Infrastructure
XDS References
• Primary– ITI TF-1 Section 10 Cross-Enterprise Document Sharing (XDS.b)
• Underlying Technical Framework Content– ITI TF-1
• Appendix J Content and Format of XDS Documents• Appendix K XDS Concept Details• Appendix M Cross-Enterprise Document Sharing and IHE Roadmap
– ITI TF-2a• Section 3.8 Patient Identity Feed• Section 3.18 Registry Stored query
– ITI TF-2b• Section 3.41 Provide and Register Document Set-b• Section 3.42 Register Document Set-b• Section 3.43 Retrieve Document Set
– ITI TF-2x• Appendix V “Web Services for IHE Transactions”
– ITI TF-3• Section 4.1 XDS Metadata Model
18
DSUBDocument Metadata Subscription supplement
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
20
Publish/Subscribe Infrastructure
• Presents a framework for building event-driven information exchange patterns using a publish/subscribe data exchange model
• 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.
21
Publish/Subscribe Infrastructure Actors and Transactions
PublisherPublisher
Publish 4.4.2.3Publish 4.4.2.3
NotificationNotification BrokerBroker
NotificationNotification RecipientRecipient
SubscriberSubscriberSubscribe 4.4.2.1Subscribe 4.4.2.1
Notify 4.4.2.2Notify 4.4.2.2
22
Possible Combined Actors
PublisherPublisher
NotificationNotification BrokerBroker
NotificationNotification RecipientRecipient
SubscriberSubscriberSubscribeSubscribe
Notify Notify
PublishPublish
PublisherPublisher
NotificationNotification BrokerBroker
NotificationNotification RecipientRecipient SubscriberSubscriber
SubscribeSubscribe
Notify Notify
NotificationNotification BrokerBroker
NotificationNotification RecipientRecipient SubscriberSubscriber
SubscribeSubscribe
Notify Notify
PublisherPublisher
23
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
24
DSUB Actors and Transactions
Document Metadata Document Metadata PublisherPublisher
Document Metadata Document Metadata Publish [ITI-54]Publish [ITI-54]
Document Metadata Document Metadata NotificationNotification BrokerBroker
Document Metadata Document Metadata NotificationNotification RecipientRecipient
Document Metadata Document Metadata SubscriberSubscriber
Document Metadata Document Metadata Subscribe [ITI-52]Subscribe [ITI-52]
Document Metadata Document Metadata Notify [ITI-53]Notify [ITI-53]
25
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.
26
XDS Document Consumer
XDS Document Registry
XDS Document Source
DSUB Process Flow
Publisher Notification Broker
Notification RecipientSubscriber
SubscribeSubscribe
PublishPublish
PublishPublish
NotifyNotify
NotifyNotify
UnsubscribeUnsubscribe
PublishPublish
27
DSUB Subscription Topics and Standards
• 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– OASIS Web Services Notification Family of 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]
28
Security and Privacy
• The risk assessment spreadsheet for DSUB profile is available from http://wiki.ihe.net/images/4/46/DSUB_risk_assesment.xls
• For general IHE risks and threats see ITI TF-1: Appendix L• Many risks cannot be mitigated by the IHE profile and instead
the responsibility for mitigation is transferred to the implementer:– A policy decision can be made during the Subscribe transaction,
whether the subscription is an authorized subscription and whether a notification/type of notification is authorized. (This could be based on the XUA identity, the consumer address value, etc.)
– This profile does not include the solution to changes of policy between the subscribe time and notify time (which can be substantial). The recommendation is that the policy is enforced conservatively (i.e. the length of subscription can be determined by the Document Metadata Notification Broker).
• Specific security considerations are presented in the security section of each transaction in Volume 2b.
29
DSUB References
• Primary– DSUB Supplement Rev 1.4 2010-08-10
• Underlying Technical Framework Content– ITI TF-2a
• Section 3.18 Registry Stored query
– ITI TF-2b• Section 3.42.4.1 Register Document Set-b Request
• Section 3.43.4.2.2 Message Semantics
– ITI TF-2x• Appendix V “Web Services for IHE Transactions”
30
31