The Yellow Pages of Healthcare: Registries

Bill Klaver compares an XDS registry to the yellow pages
In our last post we learned how the PIX/PDQ manager is responsible for resolving all patient identity issues within the XDS solution. (That is, the PIX/PDQ Manager is responsible for accepting all patient identities from all creation systems via HL7 messaging and linking those identities to a higher order identity or global identifier and answering questions about those identities).
Now within the XDS, solution we will begin to understand the role of the XDS Registry.
I like to make the analogy that the XDS Registry is the yellow pages of the XDS Solution. For example, if you where visiting Chicago and sitting in your hotel room, you might decide that you wanted pizza for dinner. Where do you go to find all the pizza places in Chicago? You could go to the yellow pages in your room and look up pizza.
The yellow pages will list all pizza places in Chicago with their name, address and phone number. You then can choose the one you want and either go there or order in.
Well, instead of pizza what if we looked up a patient and found the location of all of that patient’s documents and images that were available to be retrieved? That is exactly what the XDS Registry does for us. It is our yellow pages or Document Location Service for patient information.
It's important to understand that the XDS Registry works in concert with both the PIX/PDQ Manager and the XDS Repository but, is primarily responsible for managing what content is available to be shared and where to get that content.
Keep in mind we don't want the XDS Registry to be overburdened with unnecessary tasks that are performed by others, so the XDS Registry must receive the higher order identifier (the Global ID) from the PIX/PDQ Manager for each patient via HL7 Messaging.
Why? The PIX/PDQ Manager already resolves all the ways Bill Klaver can be represented across all our systems and has the higher order ID linking these identities together. The registry needs to have a high level, unique way to quickly find the patient information that is being shared (i.e. the specific pizza joint named Bill Klaver at the address ID 12345).
This also means that when content is stored and is to be made available to be shared, that content must have the higher level or Global ID on it before it can be registered as shareable with the XDS Registry.
The registry expects the patient’s ID and the location information for where that content is stored. So, in effect, we can have various content about a patient stored either within the four walls of our hospital or stored at other locations within our HIE as long as that content has the Global ID and is registered with our XDS Registry with its location information.
This means that if someone queried the PIX/PDQ Manager for Bill Klaver and got his Global ID they could then take that Global ID and ask our Document Registry what content has been made shareable for Bill Klaver and where is it stored.
Next week we will talk about a secure and reliable storage unit called the XDS Repository and its relationship to the XDS Registry and PIX/PDQ Manager.
This is part of Bill Klaver's series, Building a Health Information Exchange Through International Standards. For other posts in the series, visit the Table of Contents.
1 Responses »
Trackbacks
Leave a Response







Entries(RSS)