The previous two parts discussed how XDS fits into the IHE technical framework and also its relationship with other ITI profiles that are needed to provide the infrastructure to make XDS work.
|Showing the 5 XDS actors|
The Cross Enterprise Document Sharing (XDS) profile facilitates the registration, distribution and access across healthcare enterprises of patient electronic health records. It is a standards based specification for sharing documents between healthcare enterprises. These documents could be a “view” into an electronic record, for example, specifying a certain episode of care or a summary. At a minimum, a consumer or receiver could add the received document (e.g. a pdf) to the patient record, but because of the electronic nature of the exchange, it is expected that the recipient would update its own electronic record (i.e. database records) with the relevant information from the document so it can be viewed and interpreted using the EMR user interface.
As explained in the earlier part, XDS has multiple actors, i.e. in addition to the document source/repository (which could be an enterprise archive such as a Vendor Neural Archive or VNA) and the document consumer, it relies on a document registry for the registration of the documents and to allow potential consumers to query them. A Health Information Exchange typically provides this registry, which can be public or private. The requirement for this HIE infrastructure is one of the implementation issues, i.e. what if we don’t have a HIE in place (yet)? Another problematic scenario is when the source is outside of the consumer domain, for example if it is not covered by the HIE reach. That is where the other “XDS variations” such as XDR and XCA come into play.
With regard to information sharing, one can recognize three different models, each with a specific workflow and corresponding XDS-like profile:
- Centralized discovery and retrieval, where a community uses a common infrastructure to push and query/retrieve content. This is where we use the XDS and its imaging counterpart XDS-I. A typical use case for this profile would be publishing patient summaries upon discharge from a hospital and allowing physicians to query and retrieve these. Other examples are referrals from primary physicians to specialists with the relevant information, sharing radiology reports and images from imaging centers, communicating lab results with ordering physicians, and relaying prescription information between physicians and pharmacies.
- Direct push, where the information is sent directly to a recipient, i.e. point-to-point. A registry is not used, and the profile to use is the Cross-Enterprise Reliable Interchange, aka XDR and XDR-I. Another option is to send a secure email, or simply use the “sneakernet” by copying the information onto a CD or flash drive and let the patient deliver it to the physician. These profiles are called XDM or Cross Enterprise Document Media Interchange. The use cases for these profiles are similar as for the centralized discovery and retrieval, for example, referral information from a physician to a specialist, or summary information from a hospital to a long-term care facility, with the difference that the information is directly sent to the recipient. This is typically only done between “trusted” partners who have a strong relationship, and established policies and procedures for information sharing using a secure semi-permanent infrastructure.
- The federated discovery and retrieval, which is used when the consumer and creator are not within the same domain and the information spans multiple communities. This is called the Cross Community Access (XCA and XCA-I) to documents and images. The consumer needs to know in which community the patient information is available. In case the particular community is unknown, one can use the XCPD or Cross Community Patient Discovery mechanism to find out. Typical use cases are when patients live in multiple residences, seek care in another community, move, or go on vacation.
As mentioned earlier, one of the issues with early XDS implementations is the lack of infrastructure, i.e. having either a public or private HIE available that can be used to register the information and provide query capability. Having the XDR and XDM option available should not deter a closer integration, similarly to being in another community, as we can use XCA and XCPD in those cases. Note that all of the XDS family profiles share the same transactions, therefore, to support either one or all of them should not be too big of a burden from a vendor implementation perspective. The same applies for the user community, i.e. there is no reason to NOT use any of these standard profiles instead of the many proprietary solutions that are currently used for information exchange and do little more than lock you into a single service provider. However, there are still some lingering issues with the metadata used to identify the objects (i.e. documents and images) that are exchanged, more about that in part 4 of these series.