Locating Patient Data
1. Proposed Profile: Locating Patient Data
- Proposal Editor: Karen Witting
- Profile Editor: Karen Witting
- Date: N/A (Wiki keeps history)
- Version: N/A (Wiki keeps history)
- Domain: ITI
2. The Problem
It is expected that network accessible patient health information will be distributed across more than one source of data with potentially many standards for accessing the data. IHE has introduced several profiles which support network based exchange of patient health information. XDS defines sharing within a XDS Affinity Domain. QED defines dynamic queries that are supported by repositories of information. The XCA profile defines query and retrieve of documents beyond the boundaries of the local community.
What is missing is a mechanism to tie all these, plus other mechanisms, together to make it easy to locate patient data. This profile would define a simple way to describe the location of data which could be carried by the patient, configured into the system or discovered through IHE or other transactions. The profile would include the mechanism to use the location to retrieve data as well as a service which would hold locations and support queries to retrieve location information related to a particular patient.
3. Key Use Case
Case 1:
Patient becomes a new patient of a clinician that has an EMR connected to the regional XDS Affinity Domain. This patient has records outside of the XDS Affinity Domain that the new clinician needs to access. Presently to accomplish this, the patient would need to communicate complex configuration and access information to the clinician. Most likely the patient will make copies of all the data and provide it to the new provider in paper or electronic form.
Under this profile the patient could provide a simple location identifier to the EMR application. The profile would define the mechanism for the EMR to translate the location into the necessary syntax to access the patient record. Alternatively, the EMR can save the location in a Location Service provided by the XDS Affinity Domain. By sharing it in a Location Service the EMR can make use of the location record later and other enterprises within the regional XDS Affinity Domain can also use it to retrieve data for that patient.
Case 2:
A patient’s medical insurance company maintains the patient’s current allergy list and medications within a QED Repository for access by clinicians. The insurance company, and the patient, want clinicians to find this information efficiently so that they always have the most up to date information when treating a patient. Presently each clinician must query the patient at each treatment regarding allergy and current medications.
Under this profile a regional community could define a Location Service where a QED Repository could insert location information for patients it is supporting. This Location Service could be used to query any existing QED Repository regarding allergy and medication lists prior to seeing a patient.
4. Standards & Systems
- Connecting for Health’s Record Locator Service
- HL7 SOA: Record Location and Update Service (RLUS)
- HL7 V2 or HL7 V3
- WS-I Basic Profile 1.2
- WS-I Basic Security Profile 1.0
- WS-I Reliable Secure Profile 1.0
- ebXML
5. Discussion
The XDS profile defines interoperable document sharing within a community or XDS Affinity Domain. The QED profile defines interoperable sharing of patient data by defining a series of transactions which can be used to retrieve specific kinds of information from different kinds of Data Repositories. An instance of a Data Repository has no way of registering itself for access by applications. And an application using this information has no way of retrieving a list of places to query for a specific information.
In 2006 a White Paper was developed by the ITI technical committee proposing a set of profiles that should be developed to allow cross community patient data access. This proposal is the Cross Community Location Service specified in the White Paper.
We expand the suggestions of the paper to allow for integration with non-document based repositories. We feel that restricting all patient data access to document transfer is too limiting and the existing system must be expanded to allow for other types of communication via QED and potentially others. Additionally, missing from the paper is the definition of a “location” and the use of that entity. Once defined, a location can be shared in many different ways and optionally stored within a location service actor.
Kboone 14:52, 1 October 2007 (CDT)
See also Health Record Locator which has a great deal of overlap, and could be merged with this proposal.