Storing All That Data: Repositories
Print This Post
Share this Post
Where should you store your data? Bill Klaver explains how an XDS repository works
As we’ve been discussing, a good health information exchange needs secure, reliable, scalable and interchangeable components. For the greater good of the exchange, each must perform the individual task they were designed for, in a commonly known and predictable way, using a common set of international standards.
A PIX/PDQ manager best resolves patient identities and answers questions about those identities. An XDS registry, sort of the yellow pages of the solution, tracks and maintains the location of all shared information about a given patient.
But where is that information actually stored in an exchange? And is it secure, reliable, and easily accessed? Do I have to move all my data into the exchange? Am I creating duplicate storage of the information? Do I have to push around all these huge images and studies to make this work?
The answers lie in what is called an XDS repository. A XDS repository is used to collect, store and secure content. However, it is more than a simple database, disk or a san environment and can be deployed "close" to the creation system.
In fact, it would be appropriate to have multiple XDS repositories designed to control specific content like one repository for labs, one for images, and one for documents each installed at each hospital or constituent within the HIE.
An XDS repository has intelligence and establishes some common methods, using international standards, for both receiving the content from the creation systems and supplying content to consumer systems.
Each content creation system submits content to their designated repository with some very specific requirements, such as:
- The patient’s global or higher order identifier
- Date and time of content creation
- Type of content
- Other meta data information
Once the XDS repository receives this content from a creator, it will add additional meta data to the content (i.e. unique repository id, submission set information, etc.) and register it with the XDS registry.
What this means is that if we have established a lab repository in Hospital A and a lab repository in Hospital B, we can uniquely identify where patient Bill Klaver's lab result are stored, which is the latest set of labs, and who ordered these labs. We can also do this with other content like discharge summaries, medication summaries, allergies, treatment notes, etc.
Keep in mind that XDS repositories are primarily document-centric.
As a result, if we want to share images from a PACS system in the HIE to an EHR (for example), we are not moving or copying those images or studies from that PACS system into the XDS repository. Instead, the PACS system will submit a document like a KOS (Key Object Store) or manifest that describes to the consumer how to get and display the content from the PACS system.
Next week, we’ll dig into an issue near and dear to any health information exchange – privacy and security.
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.
Leave a Response
Entries(RSS)