"Integrating the Healthcare Enterprise" (IHE) is an organization that develops and introduces profiles aimed at improving interoperability in healthcare. The XDS-b profile was initiated by the IHE to provide a structure for a document-sharing environment through a trusted network. It describes the registration, query, retrieval, and publication of clinical documents.
XDS.b declares 4 types of actors: Document Source, Document Repository, Document Registry, and Document Consumer.
A Document Source is responsible for the document publishing and provides the clinical documents to a Document Consumer or the Document Repository.
A Document Consumer requests and retrieves documents from the XDS network, either from a Document Repository or a Document Source.
The Document Repository handles the document storage in a transparent, secure, reliable, and persistent manner. It is also responsible for delivering the requested documents to the Document Consumer.
The Document Registry manages and stores the metadata associated with the documents and allows Documents Consumers to perform various searches to identify the documents of interest and subsequently retrieve them from the Document Repository.
Xds.b is based upon ebXML Registry standards and SOAP. iCure acts as a Document Registry and a Document Repository and supports de following ITIs: iti-8, iti-18, iti-41, iti-42, iti-43, iti-44, iti-57, iti-61, iti-62, RAD-68.
This endpoint is used by a Patient Identity source to update the patient identity stored in the document Registry. The transaction is conducted by an HL7 ADT message.
The Document Registry will store only the patient identifiers of the patient identification domain designated by the XDS Affinity Domain for document sharing in the registry. If other patient identification domains are present in a received message, they will be ignored.
ℹITI TF-2a section 3.8 for the detailed definition of the transaction.
ITI-18 includes a series of queries that can be performed to find back documents in iCure. The supported query types are:
FindDocuments: Find all documents that match a set of criteria : the patient id, the creation date, ...
FindSubmissionSets: Find a specific submission set by patient id, author or date along with submitted documents
FindFolders: ITI-18 supports a hierarchical structure of folders that can be queried by patient, date, status or codes.
Get... requests: allow you to retrieve metadata of Folders, SubmissionSets, Documents identified by their ids.
ℹITI TF-2a section 3.18 for the detailed definition of the transaction.
ITI-41 is used to transmit a set of documents and associated metadata
When receiving the request the Repository:
Validates the received data
Adds the computed data
Store the received document and the meta-data
ℹITI TF-2b section 3.41 for the detailed definition of the transaction.
ITI-42 is used to register a set of document-associated metadata.
Upon receipt of a Register Document Set-b Request message, the Document Registry:
Performs metadata validations
Stores all IHE-defined metadata attributes
ℹITI TF-2b section 3.42 for the detailed definition of the transaction.
This transaction is used by a Document Consumer to retrieve a set of documents from the Document Repository.
When receiving a Retrieve Document Set Request, the Document Repository will generate a Retrieve Document Set Response containing the requested documents.
ℹITI TF-2b section 3.43 for the detailed definition of the transaction.
ITI-44 uses patient identifiers provided by Patient Identity Source to ensure that XDS Documents metadata registered is associated with a known patient and updates patient identity in document metadata by tracking identity change operations.
The Document Registry accepts Patient Registry Record Added and Patient Registry Record Revised messages.
The Document Registry stores only the patient identifiers of the patient identification domain designated by the Affinity Domain for document sharing in the registry. Patient identifiers of other patient identification domains, if present in a received message, will be ignored.
ℹITI TF-2b section 3.44 for the detailed definition of the transaction.
When receiving an Update Document Set Request message, the Document Registry parses the supplied metadata and makes the updates triggered by the metadata objects in the message. In general, each metadata object supplied triggers a separate metadata update.
The registry is capable of storing multiple versions of DocumentEntry and Folder metadata objects and makes them available through the ITI-18 transaction
ℹXDS Metadata Update section 3.57 for the detailed definition of the transaction.
ITI-61 allows the Registry to receive and store metadata about available on-demand documents.
An on-demand document is one that collects the latest, most recently available information at the time of retrieval. For more information about the on-demand document see ITI TF-3 section 4.1.1.
Upon receipt of a Register On-Demand Document Entry Request message, the Document Registry will:
Perform metadata validations
Store all IHE-defined metadata attributes
ℹITI TF-2b section 3.61 for the detailed definition of the transaction.
The Remove Metadata transaction is used by a Document Administrator to submit a list of entry UUID attributes identifying the metadata objects to be removed from the Document Registry including Submission Set, Document Entry, Folder, and Association objects.
ℹ RMD for the detailed definition of the transaction.
RAD-68 is very similar to the ITI-41 transaction, with different metadata.
ℹ IHE RAD TF-3 for the detailed definition of the transaction