XDS or XDM: That’s the question here!

Anyone who wants to take standardized paths when it comes to the transport of medical data cannot ignore the IHE profiles XDS and XDM. Both of these profiles have moved far ahead in the showcase of technological communication methods in the healthcare sector. This is good, but it begs the question of which profile should be used and when. What is important to know: IHE XDM and IHE XDS can be used alternatively or additively, but not substitutionally. Which profile is better at serving which communication scenario is not a question of faith; rather, this can be determined using a simple and clear indicator: the recipient.

IHE XDS: The great uncertainty

IHE XDS is always suitable when the objective is to permanently archive data centrally because they must be available for undirected communication. The profile is ideal for business relationships, for example, to reach patients or an undefined number of other service providers. This is typically the case for file solutions such as ePA, ELGA or the electronic patient dossier (EPD). However, case-related files such as eFA are also candidates for IHE XDS. The infrastructure needed for this, depending on the expansion stage, is extremely complex and can be compared to a library. A central registry is necessary to even know which books are available and which shelf they are on. This is taken over by document registry in IHE XDS. The data themselves are located on “digital shelves,” comparable to the IHE XDS document repositories. Whether there is a centralized repository or several decentralized repositories is a logistical and organizational question which, however, has ultimately no influence on the fundamental principle.

Irrespective of where the repositories are located (whether centralized or decentralized), an XDS construct is complex. This is related on the one hand to the development and operation of the hardware and software infrastructure and on the other hand to the encryption and rights management. Systems involved must be equipped by means of digital certificates in order to enable a secure connection between them and establish a corresponding position of trust. Depending on the expansion stage, authorization systems of varying complexity come into play in IHE XDS.

If one wants to specify fine-grained rights, for example, on a document level and for individual persons, policy systems are generally needed which can work with XACML rules, for example. Sometimes rather simple checks are also sufficient, such as when smaller groups need to check whether the patient has given his/her general consent for the sharing of data with the companies involved. For case records such as the eFA, it becomes even more complicated, however, because the patient’s decision must be taken into account, although the patient him-/herself has no access to the file system and thus to rights management. If a patient decides to consult another doctor, this must also be supported by the file system, as was taken into account during configuration of the data. The right to be forgotten, that is, the deletion of personal data from such central infrastructures, should also not be neglected. IHE-XDS constructs rapidly reach a size beyond which it makes perfect sense to use a management company which deals with legal, organizational, and operational questions and serves as a central contact partner for questions.

IHE XDM: Practical instead of grandiose

The situation is totally different in the case of IHE XDM: the IHE-XDM profile was specially developed for direct communication. In the area of business relationships, this profile is ideally suited for the focused exchange between service providers. A complex superstructure consisting of registry, repositories, authorization systems, etc. is not necessary. With IHE XDM, two defined partners communicate by means of a focused transfer of information – provided that there is patient consent – with secure end-to-end encryption, for example, via email. As a result, IHE XDM is perfectly suited for scenarios in which only one recipient or a defined group of recipients is addressed. Of course, here as well, the necessary key material needs to be exchanged in advance and concepts for key management need to be drawn up.

Even large networks can communicate via IHE XDM – provided that the communication takes place in a pinpoint manner. An example of this is the Dutch project DVDExit. Within the framework of the project, the DVD is to be entirely eliminated as a means of transporting radiological image data. For this focused communication, permanently storing the data in an XDS infrastructure which is complicated to install and operate is unnecessary and thus excessive. The communication in this case takes place only temporarily between two defined parties and thus does not require any permanent data storage. This incidentally also applies to image data, which is why XDM is also advantageous for image data communication, because no additional systems as in the case of IHE XDS are needed.

Same structure, different transport route

In conclusion, the use of IHE XDM and IHE XDS depends on which route and to whom medical data are to be communicated. These profiles can likewise be assigned to common business relationships and thus facilitate the decision for or against one of these profiles. Incidentally: the transmission data of IHE XDM differs very little from that of IHE XDS in terms of content. The same metadata are used for both profiles and the same specifications apply. The data generated are thus comparable with each other and are even completely interchangeable. The difference is only in the transport of the data.