Interview of Charles PARISOT by Tie Tjee
Charles PARISOT is chair of IHE-Services Committee. He had been the chair of the IT infrastructure committee at the time those profiles were developed.
Tie Tjee is IHE Netherland vendor chair. The Netherlands would like to speed up the interconnection between regions and among them some have implemented XDS infrastructures. This has raised several questions about the use of XDS with XDM profile in the context of imaging.
Question:
Can you provide some prospective about the strength of each profile and where they fit best, and what are the consequences by deploying them both side by side?
Answer:
Those two profiles had been designed together but XDS was designed first and XDM was designed next. The intent was to allow a point to point push in XDM to feed an XDS sharing and pull environment. Combining the two is, if you implement them as it was specified, is possible on the technical side. However, we need to speak of the policy and the organizational side where they greatly differ.
Let me remind the strength of push. With the push, you know the destination and you will share the data between you and the destination. No one else knows about it and the privacy is a smaller problem. The big issue is how do I find the right target? Because sending data to one place, if it’s a wrong place, you have a privacy gap. So the simplification in policy of managing a directory of targets is a critical element in the push and discipline by the sender in selecting the targets is required. The strength of the sharing and pulling is that it is simple for the source: they apply one kind of policy and make sure the patient has given the necessary consent for sharing. The problem is on the pull side, where it has to be checked who is asking for the data and if they are allowed according to the sharing and consent policy: Consent on the pull side has to be established. One critical benefit here is that the one who shares does not need to worry about who needs the information: The one who gets the information is the one who needs it. Therefore, you have created a fundamental sharing paradigm, which is critical in healthcare because of many organizational factors. Knowing a priori where the patient will go next is not always easy. You may plan it, but it may never happen the way you planned it. Therefore, the push-and-pull is much more flexible in terms of workflow and makes the consumers of the information happier. Let’s remember that the big issue in the push is not the pushing to the right destination but the receiving – what do you do when you receive the data: will you send it to an individual, to an organization? So, the management on the receiving system is not an easy task. We are discovering that the policy issue around the push-only and the push-and-pull makes the difference although they can be technically connected. Therefore, if you deploy both is a question of scaling. The push-pull sharing can scale to large environments. The push cannot, because you have a complex directory problem to manage and to keep current with all changes in all of the targets. The receiver will rapidly suffer from the facts syndrome, meaning that paper falls on the floor, and someone has to sort this paper. When you receive data on the push someone has to decide where to put the data, so you often end up in a lot of manual work on the receiving side. So, push-only is difficult to scale to large environments. It is nice in smaller environments of sources and destinations but there is a challenge.
Last but not least, the metadata in the push is equally important as the metadata which is in the sharing that you put in the registry. If you want them to interconnect the two have to use the same metadata. If you push with one kind of metadata and want to share with another kind of metadata, you are in deep trouble because you will have to convert metadata.
So, in order for XDS and XDM to coexist, think of scaling and metadata harmonization. This is my quick analysis.
Question:
Do you have experiences where a document on an XDS network can be sent or retrieved by a recipient who only has an XDM gateway?
Answer:
On the sending side I answered this in the previous question. You can copy your email, push it to a gateway that feeds the XDS as long as consent is managed properly. On the receiving side that is not possible. In order to do that, you need to use a feature in XDS which creates point to point engagement which is using the internet recipient and the subscription notification, the profile. But you can use an internet recipient in XDS and the registry can have a notifier that sends a notification to the document consumer so that the document consumers know that they have a document for a specific patient to call for and they can pull the document out of the XDS environment. If you enable that feature in your XDS environment, you can have a gateway that receives the notification. A gateway having that notification goes into the XDS, pulls, retrieves the documents, reads the intended recipient in the metadata and forwards an XDM message to that intended recipient via XDM. Doing it this way is not useful because you receive point to point documents, and people often do not analyse the consequences until deployment. Receiving point to point things is complex in an organization. And then turning what could be a pull model into a force pushed into your organization is actually not seen as a progress by many people. So that case is technically possible, but I don’t think anyone has implemented it.