The Cross-Enterprise Document Sharing-b (XDS.b) IHE Integration Profile focuses on providing a standards-based specification for managing the sharing of XDS documents across healthcare enterprises.
An XDS document is a composition of clinical information that complies with a published standard defining the document structure, content, and encoding. As a single unit for exchange in the repository, an XDS document is assigned with a globally unique identifier and is associated with its own metadata that reflects the content of the document. The metadata is not stored in the repository along with the document, but is registered in the Document Registry for subsequent queries and retrievals of the document.
Similar to any IHE Integration Profile in the IHE IT Infrastructure Technical Framework, the XDS profile is defined by the IHE actors involved and the set of transactions performed by these actors. To support a certain integration capability, the healthcare industry must have a product implementing the IHE actors and the corresponding transactions deployed.
This section contains the following topics:
The various actors in IHE XDS.b ITI integration profile are:
Actors in IHE XDS.b:
Document Source: Sends documents to a Document Repository and supplies metadata for registration.
Document Consumer: Queries the Document Registry for documents and retrieves documents from a document repository.
Document Registry: Validates and maintains metadata for each document and responds to document queries from the Document Consumer Actor.
Document Repository: Persists documents and registers the document metadata with appropriate Document Registry. It also assigns a uniqueId to documents for subsequent retrieval by a Document Consumer.
Patient Identity Source: Provides a unique identifier for each patient.
Integrated Document Source/Repository: Combines the functionality of the Document Source and Document Repository actors to provide and register document sets in the repository.
The HDR's IHE XDS.b solution implements the Document Repository actor and its supported transactions.
An Affinity Domain is an administrative structure containing various healthcare entities that have agreed to share clinical documents in the common infrastructure.
To ensure effective interoperability between the different entities, a Document Registry is identified, and a number of policies are established in an Affinity Domain that specify the document format, vocabulary value set, coding schemes, and the Patient Identification Domain used by the Document Registry.
To build your Affinity Domain, follow the guidelines specified in Template for XDS Affinity Domain Deployment Planning, which is available from, http://www.ihe.net/Technical_Framework/upload/IHE_ITI_White_Paper_XDS_Affinity_Domain_Template_TI_2008-12-02.pdf.
HDR provides IHE XDS.b implementation to help healthcare practitioners and clinical vendors implement medical information integration among clinical organizations. The IHE XDS Document Repository is built on top of Oracle Healthcare Data Repository (HDR) platform.
The topics below describe:
HDR implements the Document Repository Actor of the IHE XDS profile. It can be directly plugged into the IHE infrastructure and interact with the other Actors, such as the Document Registry, the Document Source, and the Document Consumer implemented by other entities.
HDR stores and manages XDS documents. The users accessing the repository can be clinical doctors, consultants, nurses, researchers, and patients.
HDR also implements the Time Client Actor in the Consistent Time (CT) profile, and the Secure Node Actor in Audit Trail and Node Authentication (ATNA) profile of IHE IT Infrastructure domain.
HDR supports the following transactions in the XDS workflow:
Provide And Register Document Set-b through synchronous Web services.
Retrieve Document Set through synchronous Web services.
Provide And Register Document Set-b through asynchronous Web services.
Retrieve Document Set through asynchronous Web services.
Before proceeding with the document sharing features, make sure that the profile options for Document Repository actor like Document Registry server URL, Syslog server details, and TLS configuration for secure mode communication are configured as per the Installation Guide instructions.
The processes of providing and registering documents are merged into a single task. This task is initiated from the Document Source Actor. It contains the following steps:
Generate the Patient ID for the documents. Obtain other optional entity IDs if necessary. An external partner outside of HDR implements the Patient Identity Actor.
Analyze the document content and generate the document metadata. For more information, refer to Section 4.2.3 Metadata Attributes in IHE_ITI_TF_Vol3.pdf.
Identify the URL to the HDR's Provide and Register Document Set-b. The URL is in the form: http://hostname:port/hdr/xdsrepositoryb_Soap12 or https://hostname:port/hdr/xdsrepositoryb_Soap12.
Wrap the document metadata and the document content in one or several HTTP/SOAP messages and submit the messages to the HDR.
There are many ways to implement the wrapping and submitting processes. The implementation is not mandated but the encoding and protocol must comply with the relevant specifications issued by OASIS/ebXML.
An acknowledgement of a successful registration and storing of the document will be received when the task is complete.
HDR provides two behavior modes for document storage, as follows:
Store mode: If the profile option CTB_XDS_DOCUMENT_IMPORT is set to N.
A document received in the store mode is stored in HDR as an entire object. HDR does not parse the elements contained in the document.
Import mode: If the profile option CTB_XDS_DOCUMENT_IMPORT is set to Y.
A document received in the import mode is parsed by HDR, which identifies the elements inside the document and stores them separately.
The retrieval of a registered document in the HDR is initiated from the Document Consumer. First query the Document Registry to get the document uniqueId, and then submit the request to the HDR to get the document.
The task generally consists of the following steps:
Obtain the Query Service URL and start the query for the target documents. The Query Service URL is in the form: http://hostname:port/hdr/xdsrepositoryb_Soap12 or https://hostname:port/hdr/xdsrepositoryb_Soap12.
Query the Document Registry for the list of documents meeting the specified criteria. The Query method varies but normally you should have the patient ID as the query input. For more information, refer to Section 3.18 Registry Stored Query in IHE_ITI_TF_Vol2a.pdf.
The Registry will return a list of documents along with their respective uniqueIds.
With the document uniqueIds of the selected documents from the list returned, the Document Consumer will send the Retrieve Document Set (ITI-43) requests to retrieve the documents. The documents are returned as entities in the response to the request. For more information, refer to Section 3.43 Retrieve Document Set in IHE_ITI_TF_Vol2b.pdf.
Configure the following as per the instructions in HDR Implementation and System Administrator Guide:
JMS queues to address reliable messaging in asynchronous transactions.
The profile option for identifying the Document Registry actor's asynchronous URL.
Asynchronous XDS.b (Provide and Register Document Set-b and Retrieve Document Set) transactions essentially accomplish the same set of tasks as their synchronous counterparts. However, the key aspects and differences in the asynchronous transactions are following:
To initiate an Asynchronous Provide and Register Document Set-b transaction with HDR, the Document Source actor should identify the URL to HDR's Asynchronous Provide and Register Document Set-b. This URL is in the form: http://hostname:port/hdr/xdsrepositorybAsync_Soap12 or https://hostname:port/hdr/xdsrepositorybAsync_Soap12.
Document Source must specify a valid callback endpoint URL using the WS-Addressing ReplyTo property in the SOAP header of its Asynchronous Provide and Register Document Set-b request message.
Upon successful receipt of an Asynchronous Provide and Register Document Set-b request message, a HTTP response status code of 202, which means that request has been accepted is sent back to the Document Source. After checking this status, the Document Source can unblock itself from the connection it initiated.
When an Asynchronous Provide and Register Document Set-b response is generated, HDR's Document Repository uses the callback endpoint specified in the SOAP request's ReplyTo property, to forward the response to the Document Source.
On receipt of an Asynchronous Provide and Register Document Set-b response message, the Document Source can use the SOAP response's RelatesTo property, to correlate the response with a request that it had sent out earlier.
The Document Source should finally respond with a HTTP response status code of 202, which means that request has been accepted to HDR's Doc Repository, marking the end of the transaction.
All IHE XDS.b transactions generate audit events that are forwarded to a configured Audit Server. The location of the audit log in the Audit Server varies depending on the configuration of the Audit Server. This audit logging will be in addition and processed by the HDR's native logging mechanism.