This toolkit provides an overview of Query HIE to assist providers in adopting this Health Information Exchange (HIE) method, which leverages the Query-based Exchange method to improve health care. The content was developed with input from the 2019 Query HIE Learning Collaborative.
Query HIE Functionality
To participate in Query HIE, you first need to obtain access to a Query HIE Network provided by your EHR vendor, which may incorporate its own network and/or an independent Query HIE Network such as Commonwell. To learn more, click here.
To conduct Query HIE, you will need to use the Query HIE functionality provided by your EHR vendor and/or the Query HIE Network. For an efficient experience, it is best if this functionality is integrated into your EHR user interface.
The discussion that follows below is a generalization of the commonly available Query HIE functionality. Your actual functionality will vary, because the implementations are both EHR and Query HIE Network dependent.
Sending Provider: Enable Information Access
You will need Query HIE functionality that allows you to enable the Query HIE features in your EHR system. As shown in the image below, this is likely a system wide setting that enables secure access to your patient records from the Query HIE Network.
Consider that providing access to your patient data is a critical component of making Query HIE work. The more information that is made accessible, the more complete the shared patient information becomes to all the providers who participate on the network.
Patients have to agree for providers to make their health records accessible on the Query HIE Network. So while enabling access makes your records accessible, what records other providers can actually see must be defined on a per patient basis with the functionality described in the next section.
Sending and Receiving Provider: Track Patient Consent
You will need functionality to track whether a patient provided consent for sending and receiving patient records via Query HIE. Consent will be used by the Query HIE Network to only include records from patients who agreed.
To maximize privacy, a patient must grant consent to each provider they see. For instance, a patient may provide consent to a PCP, but may withhold consent from a Behavioral Health specialist. As such, the consent is typically tracked on a provider basis.
This means that a query may result in access to records from one provider but not another, even though both providers on the network have seen the patient. In the example where only the PCP obtains consent, a query by another clinician would only show the records of the PCP. Unless, the patient tells the clinician that they also saw the Behavioral Health specialist, the clinician wouldn’t know.
The functionality may allow you to limit what information other providers can see and who can see it. This level of sophistication may vary by implementation. Advanced implementations will allow you to track consent directly in a patient’s record in your EHR system. This enables you to discuss consent with your patient while looking at the patient’s own record.
Receiving Provider: Query and Select
Providers who see a patient will need Query HIE functionality to execute the query (search) to review what patient information is available on the network. This query functionality will typically present a list of accessible records listed by high level index information such as provider name, organization name, and service date.
A critical component of this functionality is patient matching. The network will match the patient from one EHR system to another. To ensure patients aren’t mixed up, the list of available records will typically include patient identification data, so you can verify that the records indeed belong to the patient you are seeing.
The functionality will typically include features that allow you to select the records you deem relevant for reconciliation into your own patient record. This limits information overload, and stops you from incorrectly including information from other patients.
Advanced implementations will allow you to conveniently execute queries directly from a patient’s record in your EHR system. This eliminates the risk of entering the wrong patient information when making the query.
Receiving Provider: Retrieve and Reconcile
Finally, you also need Query HIE functionality to access the selected records to retrieve and reconcile the information. For this purpose, the Query HIE Network will reach out across the systems on the network to request the detailed information that was made accessible.
This functionality includes presentation features that show the information obtained. How this information is presented depends on the network. For instance, it may provide visualizations of C-CDAs or PDFs, and/or use other means to present the data.
Advanced implementations will allow you to directly reconcile the retrieved information into your own patient record.
Receiving Provider: Confirm Patient Consent
Some Query HIE implementations require the receiving provider to separately ask each patient for consent to query and retrieve the patient's records. Depending on the organization policy, this may be asked verbally or in writing, but in either case the consent would be recorded in the EHR so the query can be made. This step enables the patient to further limit who can query their health data.
In a case of a medical emergency, a patient's physical and/or mental state may inhibit the communication required for this purpose. If this occurs, the policy may or may not allow the medical staff to make the query and ask for consent retroactively. Check with your organization's EHR vendor and Query HIE Network provider how these various aspects may be addressed.
Integration of Query HIE into the EHR User Interface
To make the Query HIE functionality easy and convenient to use, it should be integrated into your EHR user interface. This avoids the need to switch back and forth between your EHR system and an independent Query HIE module.
Many EHR vendors have already integrated the functionality of Query HIE Networks like Commonwell, or based their implementation on Carequality. Enabling Query HIE may be as simple as buying a license and turning on this functionality. However, if you have an older EHR version, you may also have to upgrade your EHR to obtain the Query HIE functionality, which is a more involved process.
If your EHR vendor has not yet integrated Query HIE, you can request that the vendor completes an integration project. The vendor’s willingness may depend on which Query HIE Network you select. Due to the popularity of Commonwell and Carequality, you may find their strongest interest if you select one of these solutions.
Record Locator Service (RLS)
It may not be practical for a provider to query all organizations accessible via Query HIE to determine which ones have information about their patient. A Record Locator Service (RLS) is an add-on service that can assist in making more refined queries. RLS offers functionality to find records based on search criteria, such as geographic location, person’s ID, data type, and other information.
RLS can play an important role in facilitating Query HIE when a large number of potential exchange partners are involved. For instance, it can assist in limiting the scope of healthcare communities a requester needs to contact to find information about a patient.
When a provider conducts a query using an RLS, the RLS creates a virtual table or list of the providers who met the criteria entered into the RLS search and have patient information available.
An RLS does not provide visibility into the content of the information it seeks. For example, an RLS can determine where laboratory records exist for a particular patient, but it cannot locate only those results for a particular lab test that produced positive results.
Scope and Quality of an RLS
When requesting information from an RLS, understand the methods, scope and range of the RLS, and consider the following:
- An RLS can cover a specified geographic area and/or consist of a number of healthcare communities
- An RLS identifies candidate locations from which to retrieve data, but it is up to the user to select the applicable locations
- RLS interfaces and behaviors do not operate uniformly, nor do they guarantee the accuracy or completeness of results
- You can’t assume that the RLS asserts knowledge about the presence or absence of patient data outside of this scope
- RLS suppliers can differentiate their service by explaining and demonstrating how they ensure accurate results
- An RLS may report records that aren’t accessible via Query HIE and/or may not have access to all available records