Presentation is loading. Please wait.

Presentation is loading. Please wait.

Publication and Discovery XDS and DSUB

Similar presentations


Presentation on theme: "Publication and Discovery XDS and DSUB"— Presentation transcript:

1 Publication and Discovery XDS and DSUB
IHE IT Infrastructure Webinar Series

2 Cross-Enterprise Document Sharing
XDS

3 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)

4 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

5 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

6 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

7 XDS Flow and Interactions
XDS Document (Metadata): Class Patient Id Author Facility Date of Service Registry Consumer 3. Consumers search for documents with specific information 2. Repository registers the documents metadata and pointer with the Registry Source of Documents Repository 4. Consumers retrieve selected documents from Repository (-ies) Slide with animation: see in presentation mode. Note that multiple Repositories can be linked to one Registry. 1. Sources post document packages to the Repository

8 XDS Technical Overview
Cross-Enterprise Document Sharing Profile Actors and Transactions

9 Patient Identity Source
XDS.b Formal Diagram Patient Identity Source Patient Identity Feed [ITI-8] Patient Identity Feed HL7v3 [ITI-44] Registry Stored Query [ITI-18] Document Registry Document Consumer Register Document Set-b [ITI-42] Integrated Document Source/Repository Retrieve Document Set [ITI-43] Document Source Document Repository Provide&Register Document Set-b [ITI-41]

10 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 Document Source The Document Source Actor is the producer and publisher of documents. It is responsible for sending documents to a Document Repository Actor. It also supplies metadata to the Document Repository Actor for subsequent registration of the documents with the Document Registry Actor. Document Consumer The Document Consumer Actor queries a Document Registry Actor for documents meeting certain criteria, and retrieves selected documents from one or more Document Repository actors. Document Registry The Document Registry Actor maintains metadata about each registered document in a document entry. This includes a link to the Document in the Repository where it is stored. The Document Registry responds to queries from Document Consumer actors about documents meeting specific criteria. It also enforces some healthcare specific technical policies at the time of document registration. Document Repository The Document Repository is responsible for both the persistent storage of these documents as well as for their registration with the appropriate Document Registry. It assigns a uniqueId to documents for subsequent retrieval by a Document Consumer. Patient Identity Source The Patient Identity Source Actor is a provider of unique identifier for each patient and maintains a collection of identity traits. The Patient Identify Source facilitates the validation of patient identifiers by the Registry Actor in its interactions with other actors. Integrated Document Source/Repository The Integrated Document Source/Repository combines the functionality of the Document Source and Document Repository actors into a single actor that does not initiate nor accept the Provide and Register Document Set transaction. This actor may replace the Document Repository actor from the perspective of the Register Document Set or Retrieve Document transactions.

11 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. Provide and Register Document Set A Document Source Actor initiates the Provide and Register Document Set Transaction. 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 by forwarding the document metadata received from the Document Source Actor. Register Document Set A Document Repository Actor initiates the Register Document Set transaction. This transaction 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. The Document Registry Actor ensures that document metadata is valid before allowing documents to be registered. If one or more documents fail the metadata validation, the Register Document Set transaction fails as a whole. To support composite documents, an XDS Document may be a multipart document. The Document Repository must handle multi-part data sets as an ―opaque entity‖. The Document Repository does not need to analyze or process its multi-part structure nor the content of any parts in the context of the XDS Integration Profile. Registry Stored Query The Registry Stored Query transaction is issued by the Document Consumer Actor on behalf of a care provider (EHR-CR) to a Document Registry. The Document Registry Actor searches the registry to locate documents that meet the provider‘s specified query criteria. 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. In a Stored Query, the definition of the query is stored on the Registry actor. To invoke the query, an identifier associated with the query is transmitted along with parameters defined by the query. This has the following benefits: 1. Malicious SQL transactions cannot be introduced 2. Alternate database styles and schemas can be used to implement the Document Registry actor. This is because the style of SQL query statements is directly related to the table layout in a relational database. This profile does not define how Stored Queries are loaded into or implemented in the Document Registry actor. Patient Identity Feed The Patient Identity Feed Transaction conveys the patient identifier and corroborating demographic data, captured when a patient‘s identity is established, modified or merged or in cases where the key corroborating demographic data has been modified. Its purpose in the XDS Integration Profile is to populate the registry with patient identifiers that have been registered for the XDS Affinity Domains. The Patient Identify Feed Transaction defined in ITI TF-2a:3.8 for HL7v2 and in ITI TF-2b: 3.44 for HL7v3 uses standard HL7 encoding of Patient Identifiers. This is standard encoding for HL7 applications; receiving applications are expected to extract the required data for their use. When combined with the other XDS transactions, Document Registry actors and other actors that receive HL7 data with Patient Identifiers are required to map the data received in the HL7 message to the format specified in those other XDS transactions. In those transactions, the Patient ID is treated using ebXML encoding rules and not HL7 encoding rules. Specifically, the Patient ID will be treated as a string, and extra components entered in that string shall cause those transactions to fail. XDS actors are required to use the specified encoding for Patient ID values in other transactions and not merely copy the value received in an HL7 transaction. XDS.b implementations shall support either Patient Identity Feed (ITI TF-2a: 3.8) or Patient Identity Feed HL7v3 (ITI TF-2b: 3.44) or both. It is important to note that the version of HL7 implemented by XDS.b and Patient Identity Feed in a single domain or community need to match in order to allow interoperability. In the case of mixed scenarios, translation between Patient Identity Feed (ITI TF-2a:3.8) and Patient Identity Feed HL7v3 (ITI TF-2b: 3.44) will be required via a bridge or interface engine. Retrieve Document Set A Document Consumer Actor initiates the Retrieve Document Set transaction. The Document Repository shall return the document set that was specified by the Document Consumer.

12 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. Provide and Register Document Set A Document Source Actor initiates the Provide and Register Document Set Transaction. 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 by forwarding the document metadata received from the Document Source Actor. Register Document Set A Document Repository Actor initiates the Register Document Set transaction. This transaction 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. The Document Registry Actor ensures that document metadata is valid before allowing documents to be registered. If one or more documents fail the metadata validation, the Register Document Set transaction fails as a whole. To support composite documents, an XDS Document may be a multipart document. The Document Repository must handle multi-part data sets as an ―opaque entity‖. The Document Repository does not need to analyze or process its multi-part structure nor the content of any parts in the context of the XDS Integration Profile. Registry Stored Query The Registry Stored Query transaction is issued by the Document Consumer Actor on behalf of a care provider (EHR-CR) to a Document Registry. The Document Registry Actor searches the registry to locate documents that meet the provider‘s specified query criteria. 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. In a Stored Query, the definition of the query is stored on the Registry actor. To invoke the query, an identifier associated with the query is transmitted along with parameters defined by the query. This has the following benefits: 1. Malicious SQL transactions cannot be introduced 2. Alternate database styles and schemas can be used to implement the Document Registry actor. This is because the style of SQL query statements is directly related to the table layout in a relational database. This profile does not define how Stored Queries are loaded into or implemented in the Document Registry actor. Patient Identity Feed The Patient Identity Feed Transaction conveys the patient identifier and corroborating demographic data, captured when a patient‘s identity is established, modified or merged or in cases where the key corroborating demographic data has been modified. Its purpose in the XDS Integration Profile is to populate the registry with patient identifiers that have been registered for the XDS Affinity Domains. The Patient Identify Feed Transaction defined in ITI TF-2a:3.8 for HL7v2 and in ITI TF-2b: 3.44 for HL7v3 uses standard HL7 encoding of Patient Identifiers. This is standard encoding for HL7 applications; receiving applications are expected to extract the required data for their use. When combined with the other XDS transactions, Document Registry actors and other actors that receive HL7 data with Patient Identifiers are required to map the data received in the HL7 message to the format specified in those other XDS transactions. In those transactions, the Patient ID is treated using ebXML encoding rules and not HL7 encoding rules. Specifically, the Patient ID will be treated as a string, and extra components entered in that string shall cause those transactions to fail. XDS actors are required to use the specified encoding for Patient ID values in other transactions and not merely copy the value received in an HL7 transaction. XDS.b implementations shall support either Patient Identity Feed (ITI TF-2a: 3.8) or Patient Identity Feed HL7v3 (ITI TF-2b: 3.44) or both. It is important to note that the version of HL7 implemented by XDS.b and Patient Identity Feed in a single domain or community need to match in order to allow interoperability. In the case of mixed scenarios, translation between Patient Identity Feed (ITI TF-2a:3.8) and Patient Identity Feed HL7v3 (ITI TF-2b: 3.44) will be required via a bridge or interface engine. Retrieve Document Set A Document Consumer Actor initiates the Retrieve Document Set transaction. The Document Repository shall return the document set that was specified by the Document Consumer.

13 XDS.b Actors & Transactions Requirements
Optionality Section Document Consumer Registry Stored Query [ITI-18] Retrieve Document Set [ITI-43] R ITI TF-2a: 3.18 ITI TF-2b: 3.43 Document Source Provide and Register Document Set-b [ITI-41] ITI TF-2b: 3.41 Document Repository Register Document Set-b [ITI-42] ITI TF-2b: 3.42 Document Registry Register Document Set-b [ITI-42] R Registry Stored Query [ITI-18] R Patient Identity Feed [ITI-8] Patient Identity Feed HL7v3 [ITI-44] O (Note 2) ITI TF-2a: 3.8 ITI TF-2b: 3.44 Integrated Document Source/Repository Patient Identity Source Patient Identity Feed [ITI-8] O (Note 1,2) ITI TF-2b :3.44 Note 1: If Assigning Authority of Patient ID presents in the Patient Identity Feed or Patient Identity Feed HL7v3 transaction, the Patient Identity Source is required to use an OID to identify the Assigning Authority. For technical details of the assigning authority information, see ITI TF-2a: 3.8. Note 2: Document Registry and Patient Identify Source shall implement at least one of Patient Identity Feed or Patient Identity Feed HL7v3.

14 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

15 XDS.b – Actors and Options
Reference Document Source Document Replacement ITI TF-1: Document Addendum ITI TF-1: Document Transformation ITI TF-1: Folder Management ITI TF-1: Basic Patient Privacy Enforcement ITI TF-2b: 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 ITI TF-2a: ITI TF-2b: Basic Patient Privacy Proof ITI TF-2a: Document Replacement Option - ability to submit a document as a replacement for another document already in the registry/repository Document Addendum Option – ability to submit a document as an addendum to another document already in the registry/repository Document Transformation Option – ability to submit a document as a transformation of another document already in the registry/repository Folder Management Option – ability to: Create a folder Add one or more documents to a folder Note 1: If Assigning Authority of Patient ID presents in the Patient Identity Feed or Patient Identity Feed HL7v3 transaction, the Patient Identity Source is required to use an OID to identify the Assigning Authority. For technical details of the assigning authority information, see ITI TF-2a: 3.8. Note 2: Document Registry and Patient Identify Source shall implement at least one of Patient Identity Feed or Patient Identity Feed HL7v3.

16 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 ATNA - Audit Trail and Node Authentication

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

18 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 The specific attributes of each entity in the above registry data model have been selected from document header attributes from several standards (see ITI TF-2x: Appendix L), including:  ANSI/HL7 CDA R1-2000  HL7 CDA Release 2 (draft) Document header definition (Dec 2003 Committee Ballot) 2290  Composition attributes from EHR ENV (draft). IHE strongly recommends that XDS Affinity Domains adopt rules that require documents to comply with widely accepted standards where possible (e.g., HL7 CDA, CEN ENV 13606, ASTM 4400 CCR, and DICOM Composite Object). The UID identification scheme is based on the OSI Object Identification (numeric form) as defined by the ISO 8824 standard. Even though the Web Services for IHE transactions will be based on SOAP 1.2, they will take advantage of the guidelines expressed in the WS-I Basic Profile 1.1 (BP 1.1) and Simple SOAP Binding Profile 1.0 (SSBP 1.0) where applicable. Some IHE transaction may also take advantage of the WS-I Basic Security Profile 1.0 (BSP 1.0).

19 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 - Option (XDM- ) IHE Cross-Enterprise Reliable Exchange (XDR) w Patient ID Reconciliation (PIX/PDQ) Moving to the next level 19

20 Health Information Sharing Deployment Models
4 - Community HIE Many 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 ! 20

21 Health Information Exchange and IHE Profiles
XDS Metadata Light Client IHE XDM ( ) Pt-to-Pt Push Application Client IHE XDR (Web Service) IHE XCA (cross-HIE) Share & Pull IHE XDS (Intra-HIE)

22 Flexible Infrastructure
Replace with agreed new version of this slide Health Information Exchange XDS Structured objects Pull Publish Pull Send to Switch XDR Write Read Interchange Media XDS is the base for a broader family of profiles XDR = Reliable Interchange (exchange of XDS metadata and documents over reliable protocols) XDM = Media Interchange (exchange of XDS metadata and documents on Media) XDR – Reliable asynchronous point-to-point transmission of XDS content (metadata and documents) over reliable communications Single Submission Set per transfer Optionally identify intended recipients Online = over direct TCP connection Offline = over SMTP Works with XDS XDS Query/Retrieve can feed XDR transmission Point-to-point transfer via XDR can feed XDS submission XDM – Media Interchange ( , CD, USB, etc.) Protocol structure of XDS imposed on File/Directory structure on the media Transport Multiple XDS Submission Sets – Each Submission Set has Metadata describing documents XDS Query/Retrieve can feed XDM transmission Point-to-point transfer via XDM can feed XDS submission XDM

23 IHE XDS adopted in National & Regional Projects (sample)
Lower Austria NETHERLANDS Friesland Natn’l Mamography Italy Conto Corrente Venetto - Friuli France DMP VITL-Vermont Austria Suisse St Gallen Lausane Quebec, Toronto, Alberta, British Columbia Canada Infoway Wales Imaging France Imaging IDF Boston Medical Center - MA For more complete list see: tinyurl.com/wwXDS Philadelphia HIE Belgium Flemish-Leuven KeyHIE Pennsylvania South Shore Hospital, NY Boston Medical Center, MA Vermont Information Technology Leaders, VT KeyHIE/Geisinger Health System, PA Lower Austria Region (near Vienna) Friesland Cardiology Network North Carolina Healthcare Information and Communications Alliance,NC CareSpark, TN Azienda Sanitaria Locale n. 4 Chiavarese USA - NHIN Austria-ELGA France-DMP Providence Health System, OR South-Africa-Gauteng Montreal McGill - Quebec Toronto East Network - Ontario British Columbia Alberta Project Doge Italy Friuli Region Ireland - National PACS Japan-Nagoya Shanghai Kobe-Stroke Mgt Cardiology Network Groningen Amsterdam Radiology Network Rotterdam HIE Flemish Hospital Network Dutch Mammo Screening Mayo Clinic, MN New York Presbyterian, NY Italy-Health Optimum IHE North American Connectathon, USA CareSpark – TN & VA SHARP CA South Africa THINC- New York NCHICA – N. Carolina Providence Health System - OR CHINA-Shanghai Imaging Info Sharing CHINA-MoH Lab results sharing JAPAN-Nagoya Imaging Info Sharing, Nationwide PDI guideline 2323 23 23

24 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

25 Open Source Implementation Tools
Open source implementations are available for XDS, XCA, XCPD, PIX, PDQ, ATNA, CT, and more: NIST under Source Forge HIE-OS under Source Forge Microsoft under codeplex FHA CONNECT OHT – IHE Profiles Charter OHT – Open Exchange Forge OHT – Model Driven Health Tools-Charter 25

26 Document Metadata Subscription supplement
DSUB

27 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

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

29 Publish/Subscribe Infrastructure Actors and Transactions
Publisher Publish Notification Broker Subscribe Subscriber Notify Publisher - source of the information to which there may be a subscription. Sends Publish transaction and when the publish/subscribe pattern is applied to an existing IHE profile, in most cases it will be grouped with an existing IHE actor. Notification Broker – keeps track of all subscriptions, and based on the information received in a Publish transaction it sends notifications to the appropriate Notification Recipients. Receives Subscribe transaction, which represents subscription requests, modifications, and cancellations. It also keeps track of the time limits of subscriptions. Subscriber - initiates, modifies, and terminates subscriptions on behalf of a Notification Recipient. It is the sender of the Subscribe transaction, and it may be servicing any number of Notification Recipients. Notification Recipient - receives the notification about a published event, when the subscription filters specified for this Notification Recipient are satisfied. Notification Recipient 29

30 Possible Combined Actors
Publisher Notification Broker Notification Recipient Subscriber Subscribe Notify Publish Publisher Notification Broker Notification Recipient Subscriber Subscribe Notify Notification Broker Notification Recipient Subscriber Subscribe Notify Publisher Various combinations of actors are possible It is also possible to chain these groups to achieve cascading notifications 30

31 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

32 DSUB Actors and Transactions
XDS Registry Document Metadata Publisher Document Metadata Subscriber Document Metadata Publish [ITI-54] Document Metadata Subscribe [ITI-52] Document Metadata Notification Broker Document Metadata Notify [ITI-53] Document Metadata Notification Recipient 32

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

34 DSUB Illustration of Use
Publisher Subscriber Notification Broker Notification Recipient Subscribe Publish Notify Publish Notify Unsubscribe Publish

35 DSUB Implementation DSUB topic tree DSUB Standards
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]

36


Download ppt "Publication and Discovery XDS and DSUB"

Similar presentations


Ads by Google