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.
Introduction
Health Information Exchange (HIE) allows the sharing of vital patient information to inform decision making at the point of care. There are two methods of HIE that can be used to electronically share information between care providers.
Directed Exchange: can be used by a referring provider to send patient information directly to another provider to coordinate patient care via Direct Messaging. This commonly used HIE method is mostly used to coordinate planned transitions of care.
Query-based Exchange: can be used by a provider to search for (query) and retrieve patient information that was made accessible by other care providers, public agencies, and other sources. This method can be used to obtain data for planned and unplanned care.
Query HIE uses the Query-based Exchange method to exchange information between care providers. As participation in Query HIE is rapidly expanding, this toolkit focuses on explaining the principles of Query HIE to exhange information from provider-to-provider.
To learn more about Directed Exchange, review the Direct Messaging page on the Mass HIway website. The last section on this page provides an overview of the differences between the two methods.
Query HIE
The principle of Query HIE is simple. This HIE method helps clinicians to Query, Select, and Retrieve information made accessible by other healthcare providers via a Query HIE Network.
QUERY
Locate a patient's records across different
EHR and other clinical systems
SELECT
View the list of available records and
select the relevant records to view
RETRIEVE
Securely access the selected clinical data
from within the provider's own EHR system
Using a query to search for information may result in patient records coming back from multiple sources. For instance, a query may result in records being found in the EHRs of a PCP, a specialist, and a clinic, and the clinical systems of a laboratory and pharmacy. Query HIE typically allows the receiving provider to select what information to actually retrieve.
Query HIE Networks
Conducting Query HIE requires that providers become a member of a Query HIE Network that supports the Query-based Exchange method. These networks enable providers to share their patient information.
For Query HIE to improve care, it is imperative that many providers participate in making their patient information accessible via these networks. After all, the more patient records are accessible, the more complete the view on the patients’ health status becomes.
The ”Query HIE Networks” tab explains these networks in more detail. This includes an overview of public initiatives that created networks that have been integrated by many EHR and other clinical system vendors. As the rapid spread of these networks makes Query HIE increasingly effective, consider connecting to them as well.
Query HIE Functionality
Query HIE requires key functionality to make it work. This functionality is typically provided by the EHR vendor in collaboration with the Query HIE Network. The capabilities enable the care providers on the network to:
- Make patient information accessible on the network for the purpose of supporting future care services by other providers.
- Track whether patients agreed to make their health information records accessible on the network.
- Make queries to find any relevant patient records accessible on the network, at the time care services are provided.
- Select, retrieve, and reconcile the patient information within the provider’s EHR system.
The “Functionality” tab provides a more detailed overview of the functionality needed to participate in Query HIE.
Information Storage
The health information is typically not stored on the Query HIE Network itself. The functionality works based on indexing, meaning that the network only knows on what EHRs and other clinical systems the information is accessible and for which patients. The information retrieval is done directly from the systems that hold the health records. Basically, the network mediates the exchange.
An advantage is that if a patient changes their mind, the provider can simply turn off access and then the patient’s information will no longer be accessible on the network. However, any information that other providers have already retrieved cannot be deleted so easily. That would require manual intervention by those providers.
Using Query HIE during Unplanned Care
Because of differing Electronic Health Record (EHR) systems used at hospitals and other care organizations, clinicians often struggle to locate and access relevant patient information when they provide unplanned care. Query HIE can assist these clinicians to find the needed information far more quickly via the Query, Select and Retrieve functionality.
There are many use case scenarios where a healthcare provider would want to know the health information available for their patients during unplanned care. Examples for when using Query HIE is effective are provided in the ”Use Cases” tab.
Using Query HIE during Planned Care - Referrals
When a referring provider sends a Summary of Care (SoC) record via HIE using Directed Exchange, the receiving provider cannot simply assume that a referring provider had all the available patient information. Critical information known by other providers who have seen the same patient might be missing.
Using Query HIE can therefore also be useful when treating referred patients during planned care. If the transition of care record received from a referring provider appears to be missing key elements, Query HIE can be used to try to obtain additional data from other sources. The same principles of Query, Select, and Retrieve apply as for using Query HIE during unplanned care.
Using Query HIE during Planned Care - New Patients
Query HIE is also particularly advantageous when accepting new patients who contacted the provider directly for health care services without a referral. In this case, the provider can use Query HIE to try to obtain information from the patient's prior care providers.
Getting the patient's health data ahead of time reduces the time the provider has to spend on interviewing the patient during the first visit, and decreases the potential errors and omissions due to things the patient can't remember, doesn't realize, or doesn't know.
Directed Exchange versus Query-based Exchange
The table below highlights the key differences between Directed Exchange versus Query-based Exchange (Query HIE).
| HIE - Directed Exchange | Query HIE - Query-based Exchange |
|---|---|
| With Directed Exchange, providers can use HIE to send messages with patient information, such as the medical history they recorded, to another health professional. | With Query HIE a health professional can use HIE to search and retrieve the accessible patients’ medical history recorded by other providers. |
| The sending provider can send referrals, laboratory results, discharge summaries, and patient care orders securely over the internet in encrypted and reliable messages. | The receiving provider can request any of the healthcare records that were made accessible on the Query HIE Network, including patient records, laboratory results, medication lists, etc. |
| The receiving provider will receive information from a single provider. | The receiving provider may receive information from zero to multiple providers. |
| Directed exchange is commonly used to coordinate planned transitions of care between two healthcare providers. | Query HIE is typically used when a patient sees a provider for unplanned care, but can also be used during planned care. |
| This HIE method uses Direct Messaging to send patient information from a sending provider to a receiving provider. | This HIE method relies on providers linking to a Query HIE Network to provide query access to their patient records. |
| A patient must provide consent before a provider can send the patient’s record to other providers via HIE. | A patient must provide consent before a provider can make the patient’s record accessible for Query HIE. |
| This is referred to as a push method, as the sending provider drives what information the other provider will receive. | This is referred to as a pull method, as the receiving provider drives the search, selection, and retrieval of the information. |
Query HIE Overview Webinar
Review the webinar below to learn more about Query HIE.
Use Cases
Query HIE enables providers to query (search) and retrieve specific information related to their patients from other providers who have previously seen the patients for treatment.
In addition, Query HIE can provide access to other sources of patient information, such as clinical laboratories, pharmacies, or public health agencies.
The Query HIE capability is useful for assisting clinicians in making more informed medical decisions for their patients, so they can improve their patient care.
View this use case video below and the descriptive example below to learn more about Query HIE.
Query HIE Use Case
Karen has made an appointment to see a Mental Health Specialist as she has been feeling more
depressed and anxious than normal. After talking with the Specialist, they agree to try using a
medication to manage the symptoms of Karen’s depression.
As Karen is a new patient, the Specialist sends a query through his Electronic Health Record
(EHR) system to gather information on Karen’s prior medical history. The query comes back
with several medical conditions she is currently being treated for by her Primary Care Physician
and a Neurologist. This includes the medications they prescribed for Karen.
In the notes from a prior visit to the Neurologist, the Specialist notices that Karen had been
prescribed medications from the tricyclic class of antidepressants to treat chronic migraines.
None of them had worked, and Karen experienced several unpleasant side effects before
she and her Neurologist decided to stop the medications and try injection treatments instead.
Based on the notes, the Specialist decides to avoid that class of antidepressants, and focus on
a different drug class. As he also notices Karen had been diagnosed with hypertension by her
Primary Care Physician, he narrows down his choice to a medication that should be effective
and will not cause the same negative side effects or interfere with the hypertension medication
her physician prescribed.
Because the Specialist was able to access Karen’s prior medical history, he can avoid giving
Karen a prescription for a medication she had already tried and had negative reactions to,
and focus his efforts on finding the right drug sooner. Now, Karen is feeling much better, and
is relieved that the prescription her Specialist gave her has been working with few side effects.
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
Query HIE Networks
To participate in Query HIE, a provider's EHR vendor first needs to incorporate a Query HIE Network that connects providers who are willing to exchange information via Query HIE.
A Query HIE Network offers the participating providers the functionality needed for Query-based Exchange of patient health information.
In recognition of the potential of Query HIE to improve healthcare, there are many private and public initiatives that work on making Query HIE functionality widely available. The most used public initiatives include Carequality and Commonwell, which are highlighted below.
The effectiveness of a Query HIE Network depends on how many providers participate in the network. The more providers that make information available on the network, the better the network works.
Some of the initiatives collaborate with each other to connect their Query HIE Networks together, as combining their networks will enable their participants to exchange health information with many more providers across both networks.
EHR and Clinical System Vendors
How you can participate in Query HIE depends on your EHR or other clinical system vendor. If the vendor has their own Query HIE Network, implemented Carequality, and/or is connected to Commonwell, you can quickly gain access to a large network.
If a connection to a Query HIE Network is not yet in place, you can consider working with the vendor to establish a connection. To make that work seamlessly, your vendor will have to conduct an integration project so the health information can be queried by and pulled from your system by the network.
Some vendors support Query HIE functionality but only in their more recent version release(s). If this is the case, you will have to conduct an upgrade project to get onto the latest release.
The “Vendor Status Directory” tab provides an overview of the EHR and clinical system vendors who have adopted Query HIE. This includes details on the functionality they provide and whether they are members of Carequality and/or Commonwell.
Public Initiatives
The two most commonly used and widespread public initiatives to create large Query HIE Networks include:
Carequality is an initiative that provides a framework of common standards and rules to Query HIE implementers. For instance, Epic has implemented its Query-based Exchange solution based on this framework, and its users have been able to conduct Query HIE within the Epic universe for several years.
Commonwell Health Alliance is a consortium that provides Query HIE services to users of other EHR products, including Cerner, Meditech, or Athenahealth, for example. Commonwell adopted the Carequality framework and its users can now exchange information with EHRs that have incorporated Carequality.
Both initiatives consisted of a wide network of members. With Commonwell’s adoption of the Carequality framework, they significantly increased the accessibility to patient information. Their members can now enable a connection to Carequality, allowing them to bilaterally exchange data with providers who implemented Carequality.
More detail on how these two initiatives operate follows below.
Carequality
Carequality is referred to as a network-to-network trust framework. The initiative is not a Query HIE Network and does not supply Query HIE capability. Instead, it provides a framework of standards and rules to implement Query HIE. Its members implement the standards and rules to exchange patient records via connected HIE networks. As such, these members make up Carequality’s Query HIE Network.
The framework can be used by EHR and other clinical system vendors to implement a standardized Query HIE solution, regardless of the HIE network they already belong to, including federal and state based government networks. A number of vendors have integrated the framework into their system.
The goal of the Carequality initiative is to link all the HIE networks in the same way the cellphone carrier networks are linked. Carequality’s framework creates a common legal structure that all members of the networks adhere to.
Carequality also provides and enforces the use of technical specifications and standards: message types, meta-data requirements, and data formatting and codeset rules. Epic and Commonwell Health Alliance are members.
Carequality’s Provider Directory
Carequality maintains a Provider Directory. Providers listed in Carequality’s Provider Directory can search the directory to request a patient record from any other provider listed in the directory. This directory includes all providers who use either:
- Carequality-enabled EHRs, or
- Commonwell-enabled EHRs with an activated Commonwell - Carequality Connection (explained below)
To learn more about Carequality, click here.
Commonwell
Commonwell Health Alliance is an actual Query HIE Network. The network was designed to simplify the exchange of patient records and to make the records available when they are needed. Commonwell provides Query HIE functionality that EHR vendors can integrate into their EHR systems. This consists of a Record Locator Service, a set of Patient Linking and Identification algorithms, and a document query and retrieval broker/accelerator service. This functionality includes the Query, Select, and Retrieve features required for Query HIE.
Providers must implement a patient enrollment workflow process to add a patient to the Record Locator database. This allows you to search for a patient by various demographic data. Once the patient is matched, you are shown the list of documents available for the patient. You can then review these documents and decide which to incorporate into your patient’s record.
Only patient records from providers who have also signed up for query service will be visible in the search. Furthermore, patients must consent to their records being made accessible for Query HIE.
Commonwell - Carequality Connection
In addition, Commonwell is a certified implementer of the Carequality framework for query-based document exchange. Commonwell offers providers the opportunity to opt-in to a service called Carequality Connection. This service allows Commonwell providers to connect and bilaterally exchange patient health data with Carequality-enabled healthcare provider sites.
Commonwell-enabled EHR Vendors who Participate in the Connection
Visit the Commonwell Members page and look for the “Connectivity to Carequality Available” flags to see the EHR vendors who participate. These EHR vendors include Brightree, Cerner, Evident, Greenway Health, and MEDITECH
The method of activation of the Commonwell - Carequality Connection will vary by EHR vendor. At a minimum, a provider organization must accept the Carequality terms and conditions agreement.
To learn more about Commonwell Health Alliance, click here.
Carequality and Commonwell RLS Services
A Record Locator Solution (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. See the Functionality tab of this toolkit for a description of RLS.
Both Carequality and Commonwell offer an RLS solution to assist EHR vendors, and other members of these initiatives, in offering RLS to their customers.
- Commonwell provides the Commonwell RLS, which is a service component included with Commonwell membership. Commonwell also offers its RLS as a subscription service to Carequality members. The RLS provides patient listings from all Commonwell members, as well as all Carequality members who subscribed to the Commonwell RLS.
What it means for providers who use a Commonwell-enabled EHR and have a Commonwell - Carequality Connection
They can use the Commonwell RLS to query patient data from providers who have either a Commonwell-enabled EHR, or a Carequality-enabled EHR with the Commonwell RLS.
- Carequality members have access to value-added services which are predominantly provided by the Surescripts National RLS (NRLS). Alternatively, their members can select another RLS, such as the Commonwell RLS, or can subscribe to multiple services such as the Surescripts NRLS and Commonwell RLS.
What it means for providers who use a Carequality-enabled EHR and both the Surescripts NRLS and Commonwell RLS
They can use the RLS to query patient data from providers who have either a Carequality-enabled EHR, or a Commonwell-enabled EHR with the Commonwell - Carequality Connection.
RLS Limitations
RLS solutions aren’t necessarily perfect in searching for patient records that might be accessible via the Query HIE Network without the utilization of RLS. RLS may not have access to all available records, and vice versa, an RLS may find records that aren’t retrievable via Query HIE. For instance:
Providers with a Commonwell-enabled EHR who enabled the Carequality Connection may encounter these search failures:
- Commonwell RLS doesn't include providers with a Carequality-enabled EHR who didn't subscribe to the Commonwell RLS
Providers with a Carequality-enabled EHR may encounter these search failures:
- Surescripts NRLS doesn't include providers with a Carequality-enabled EHR who didn't subscribe to Surescripts’ services
- Surescripts NRLS includes providers who subscribed to Surescripts’s services, but don’t have a Carequality-enabled EHR
- Commonwell RLS includes providers with a Commonwell-enabled EHR who didn’t activate the Carequality Connection
Vendor Status Directory
This directory lists the Query HIE implementation status of the various EHR and other vendors. Inclusion of products is not exhaustive and informational only, and is not an endorsement by MeHI of any kind. Use the filters to search for products with specific characteristics.
This directory is maintained by MeHI, the Massachusetts eHealth Institute in partnership with the Mass HIway. Vendors, click Add My Product Status to submit your products and product updates to MeHI.
Workflows
This tab presents workflow process maps and best practices for incorporating Query HIE functionality into the clinical and administrative processes. This content has been developed through the 2019 Query HIE Learning Collaborative.
For training in Process Mapping, review MeHI's Process Improvement Toolkit, which includes an overview of how process mapping works.
| Process Map | Description | ||
|---|---|---|---|
| Obtain Consent during Patient Visit to Make Patient Data Accessible and to Query Data | |||
 |
This map depicts the process to ask patients for consent to:
|
||
| PDF Map | Visio Map | ||
| Manual Query and Retrieve during Patient Visit | |||
 |
This map represents a process where the provider's practice management staff manually queries the Query HIE network for information on the patient. The provider subsequently manually retrieves and reconciles the data obtained via Query HIE at the start of the patient visit. |
||
| PDF Map | Visio Map | ||
| Automated Daily Query with Manual Retrieve during Patient Visit | |||
 |
This map shows a process where the provider's EHR automatically queries the Query HIE Network in the morning to gather information on patients scheduled to visit that day. The provider subsequently manually retrieves and reconciles the data obtained via Query HIE at the start of the patient visit. For patients who did not yet provide consent to query, the staff can use the manual query process listed above. |
||
| PDF Map | Visio Map | ||
Scenario Assumptions
The following scenario assumptions were made before the process maps were created:
- The EHR has been configured and the Query HIE functionality is available.
- The EHR is setup to require consent for both sides, i.e. making data accessible, and making a query.
- Consent for both sides can be captured in the EHR.
- Consent is based on the Opt-In approach for both sides.
- Consent for making data accessible and making a query is requested via a single Consent Form.
- The patients are established patients, so additional workflow activities may be required for new patients.
- The patient appointments have already been scheduled, so the maps don't address scheduling the appointments.
- The granularity of consent, i.e. the restrictions or limitations on what can be shared,
is captured in the Consent Form and saved accordingly, which is not shown in the map.
Factors That May Require Adaptations To These Workflows
- Does HIPAA allow for an Opt-Out approach for making data accessible and/or making a query?
- How to address consent regarding 42 CFR, HIV, genetic testing?
- How to capture electronic versus paper signature on the consent form?
Word of Caution
The value of process mapping comes mainly from the discussion of the team's own processes. Be careful not to force other people's processes on your team. Process maps created by one team rarely apply to other teams. Significant adaptation may be required to accommodate differences in business scope and objectives, management style, team makeup, patient base, and other factors.
Query HIE FAQs
What is Query HIE?
Query HIE allows providers to search for (query) and retrieve patient information that was made accessible by other care providers. Query HIE is often used to support unplanned care, but it is beneficial in many instances of planned care as well.
What is the difference between Query HIE and Query-based Exchange?
Query HIE uses the HIE method known as Query-based Exchange to exchange health information between healthcare providers.
Besides Query HIE, the Query-based Exchange method can also be used to obtain health information from other sources, such as data repositories of federal and state health agencies, or HIEs that centrally store health information.
This toolkit is focused on supporting providers in using Query HIE to exchange information from provider-to-provider. These other applications of Query-based Exchange fall outside the scope of, and are therefore not discussed in, this toolkit.
When do I conduct a query?
Queries can be conducted before, during, or after a patient visit.
Ideally, providers should conduct a query before the patient arrives, so they can review the information ahead of time. However, during a visit, a patient may tell a provider that there are more records available at other organizations, but that they have not yet given consent to share those records. For more information about consent, see the Patient Consent FAQ section below.
To learn more about who can conduct queries and how the query process works, see the Queries FAQ section below.
How many patient records will I receive?
That depends on whether the patient sees providers who are connected to the Query HIE Network. If none of the patient’s providers are on the network, you will receive no records. If all the patient’s providers are on the network, you will receive a record from each provider that received consent from the patient. For more information about consent, see the Patient Consent FAQ section below.
What is the patient record look back timeframe?
Only patients records maintained electronically are made available upon joining the Query HIE Network. As such, the timeframe and availability of past records depends on how many years of data the record-holding organization has maintained electronically.
How is Patient Health Information (PHI) protected?
The patient controls whether their health information can be made available for Query HIE access.
Providers must ask their patients for consent, and record the consent in their EHR system. For more information about consent, see the Patient Consent FAQ section below.
Is there a cost to Query HIE?
While most EHR vendors now include Query HIE in their product, there may be upgrade and/or implementation costs, fees to join a Query HIE network, or transaction charges. For more information, review the "Vendor Status Directory" tab in the Query HIE Toolkit, and contact your vendor.
If a provider organization participates in a Query HIE Network, will this count when attesting to the HIway Connection Requirement?
No. At this time, the use of Query HIE does not meet the HIway Connection Requirement.
What is a Query HIE Network?
Query HIE networks enable providers to exchange information via Query HIE. There are many private and public initiatives that work on making Query HIE functionality widely available. Some initiatives collaborate with each other to connect their networks together, as combining networks enables participants to exchange health information with more providers across multiple networks.
The effectiveness of a Query HIE Network depends on how many providers participate in the network. The more providers that make information available on the network, the better the network works.
How do I join a Query HIE network?
Individual providers cannot join a Query HIE Network on their own, because connections to these networks are dependent on the provider’s EHR vendor. For more information about the Query HIE Networks available to you, review the "Vendor Status Directory" tab in the Query HIE Toolkit, and contact your vendor.
What are commonly used Query HIE Networks?
The two most commonly used public initiatives are Carequality and Commonwell.
- Carequality is an initiative that provides a framework of common standards and rules to Query HIE implementers. For instance, Epic has implemented its Query-based Exchange solution based on this framework, and its users have been able to conduct Query HIE within the Epic universe for several years.
- Commonwell Health Alliance is a consortium that provides Query HIE services to users of other EHR products, including Cerner, Meditech, or Athenahealth, for example. Commonwell adopted the Carequality framework and its users can now exchange information with EHRs that have incorporated Carequality.
Do provider organizations need to become a member of Commonwell or Carequality?
No. Before a provider organization can use these networks, their EHR vendor must first become a member of the network. The providers that use the EHR then become recipients of the Query HIE services, but they nor their organization need to become members of the network.
How can you find which EHRs utilize the Commonwell or Carequality networks?
Both Commonwell and Carequality publish their member directories. These directories can be found on their respective websites. For the Commonwell member directory, click here. For Carequality, click here.
Alternatively select the "Vendor Status Directory" tab of the Query HIE Toolkit.
Who brokers the roles and standards for sharing information?
With Commonwell, they are doing the brokering. With Carequality, it is essentially the EHR vendor or the technical integrator that is doing the brokering.
Is nationwide Query HIE available?
Most EHR systems conduct queries based on a predetermined geographic location (i.e. a 50 mile radius). Many systems also allow providers to conduct targeted queries outside the preset geographic radius.
For example, if an Emergency Department provider in a Massachusetts hospital is treating a patient who is visiting from Colorado, the provider can conduct a query for any records within a certain radius of the patient’s hometown zip code.
Is a Master Patient Index (MPI) being built?
No. Commonwell, Carequality, and other Query HIE Networks use patient matching algorithms and in some cases default to organizational patient matching algorithms, but there is no centralized MPI.
Does a Query HIE Network store the health information?
The health information is typically not stored on the Query HIE Network itself. The functionality works based on indexing, meaning that the network only knows on what EHRs the information is accessible and for which patients.
The information retrieval is done directly from the systems that hold the health records. Basically, the network mediates the exchange.
What information should patients know about Query HIE?
The answer depends to an extent on the type of practice and the provided specialties. When defining the answer, it is good practice to consider that patients are your customers. They will want to know how participating in Query HIE is in their interest and outweighs any risks.
Patients will want to reasonably understand how it works. For instance:
- What data will other providers be able to see?
- Who would be able to query my data?
- When will they be able to see my data?
- Where can they retrieve my data?
Patients will want to understand the benefits. For instance:
- What are the advantages if other healthcare providers can query my data?
- When is it advantageous that they can query my data?
- What are the alternatives and how is this better than those alternatives?
They will consider the risks to their privacy. For instance:
- Can I decide to opt out again later, and what happens with information already shared?
- Can I limit who can see what information?
- Can I exclude pediatrics or specialist information I don't want included?
- Can I ask my doctor to exclude certain diagnosis, lab results, etc.?
- Can I ask my doctor to exclude his notes of sensitive conversations?
- Can I limit queries to emergency situations only?
- Can I tell other providers that they can't make a query?
How can this information be presented to the patients?
There are a number of ways to convey to patients the "who, what, when, and why" of Query HIE, and to communicate the benefits and risks of participation. For instance: a patient handout to read at home, a poster patients can scan while waiting for their visit, or information in the patient portal. Some patients will want to know more than others, so organizing the information will be important.
However, ultimately the information on Query HIE may be best presented verbally in a conversation with the patient. This can be done by an administrative person, but it is likely more effective if this is done by a clinical person the patient knows and trusts.
What is meaningful consent?
As per ONC, consent should not be a “check-the-box” exercise: Meaningful consent occurs when the patient makes an informed decision and the choice is properly recorded and maintained. Specifically, the meaningful consent decision has six aspects. The decision should be:
- made with full transparency and education,
- made only after the patient has had sufficient time to review educational material,
- commensurate with circumstances for why health information is exchanged (i.e. the further information-sharing strays from a reasonable patient expectation, the more time and education is required for the patient before he/she makes a decision),
- not used for discriminatory purposes or as a condition for receiving medical treatment,
- consistent with patient expectations, and
- revocable at any time.
How do patients provide consent for Query HIE?
To maximize privacy, a patient must grant consent, to make their health data accessible, to each provider they see. For instance, a patient may provide consent to a PCP, but may withhold consent from a Behavioral Health specialist. In this case only the PCP may make the patient’s records available for Query HIE access. Consent may work on an Opt-In or Opt-Out basis.
Some Query HIE implementations may require the receiving provider to separately ask each patient for consent to query and retrieve the patient's records. This step enables the patient to further limit who can query their health data. Check with your organization's EHR vendor and Query HIE Network provider whether and how this is addressed.
What are the differences between Opt-In and Opt-Out?
An Opt-In HIE policy means the provider cannot exchange a patient’s information via HIE until the patient gives specific consent to make their data available via HIE.
An Opt-Out HIE policy means the provider can exchange a patient’s information via HIE without the provider having to ask the patient for consent. Patients have to explicitly request that their information is not exchanged electronically.
Query HIE is typically Opt-In based, but check your state’s regulatory requirements, and verify with your Query HIE Network vendor how consent is handled. Organizations may also have their own opt-in/opt-out policies and procedures, above and beyond state regulations, so we recommend checking with your organization's legal/administration team as well.
To learn more, click here.
Is Massachusetts an Opt-in or Opt-out state for exchanging patient information?
The HIway regulations don't address Query HIE, but the state’s regulations allow for healthcare organizations to use a local opt-in or opt-out approach when it comes to HIEs. As such, provider organization can decide on Opt-In or Opt-Out for Query HIE, and the majority of EHR vendors leave it to the provider organizations to decide. Once the Carequality or Commonwell activation is complete, the next decision point is to choose the consent model.
Who asks the patient for consent?
For the purpose of Query HIE, the record-holding organization requests that their patients complete a prospective consent authorization, and records the consent in their EHR system. At most organizations, a receptionist, admin, or medical assistant requests consent as part of registration or intake process.
When a query comes in, the EHR system can then automatically determine whether it can share the patient’s record, and what information can be shared.
In some implementations, the receiving provider must first ask the patient for consent to make queries. In this case, the automated query process cannot be enabled for the patient until the patient has provided such consent.
How is patient consent documented?
Patient consent documentation protocols are organization-specific. In general, organizations require patients to sign a consent form and then document the patient’s consent decision in their EHR. Some organizations have added information about Query HIE to their general consent form. Many organizations review and confirm patient consent on an annual basis.
Who maintains patient consent?
Generally, the record-holding organization manages and maintains patient consent, because the consent relates to the disclosure of information for which that organization is responsible.
For Query HIE to work, the consent must be recorded in the EHR system, so that the Query HIE Network can automatically determine which records it can access.
What is prospective consent?
Prospective consent covers any potential information-sharing that may happen at some point in the future. Essentially these consent authorizations ask: “In the event another healthcare provider queries your record, can we make it available?” Prospective consent prevents the need to request the patient for consent each and every time a query is made.
Prospective consent is not necessarily indefinite. The patient may give consent for a restricted time period, e.g. a year. In this case, consent would have to be renewed when it expires.
What is one-time consent?
One-time consent covers a single event where information-sharing is necessary. This can be used when a patient declines to authorize prospective consent, but is okay with sending their information to a specific provider on a one-time basis, e.g. for a referral.
In Query HIE, one-time consent is typically not practical. The record-holding organization likely would not have immediate access to the patient when the query is made, and would therefore be unable to request consent.
Can a patient authorize partial consent?
Yes, when authorizing consent for HIE, patients may authorize only partial consent if they wish. Patients may be comfortable sharing their general health data, but may not want to openly share data that they deem sensitive.
In most EHR systems, custom rules can be applied based on the laws and requirements related to certain subsets of patients or data (e.g. behavioral health issues, substance use disorders, HIV testing or status, genetic testing, or notes designated as sensitive).
This functionality allows a provider to limit what information other providers can see and who can see it. This level of sophistication may vary by vendor and implementation.
Can a provider ask for consent on behalf of a record-holding organization?
During a visit a patient may inform a provider that there is a record at a specific organization where the patient did not yet give consent. To accommodate this scenario, some Query HIE networks allow providers to ask for consent on behalf of a record-holding organization. This allows the provider to make a query on the spot. For instance, this may work as follows:
- Dr. Smith requests a one-time consent form from a record-holding organization.
- Dr. Smith completes the form and has the patient sign the form.
- Dr. Smith submits the completed form back to the record-holding organization.
- Record-holding organization releases the record to Dr. Smith via the Query HIE Network.
In this case, the record-holding organization may restrict access to the patient’s record to just the requesting provider.
What are the pros of sharing data via Query HIE?
In general, sharing patient records using Health Information Exchange (HIE) enables providers to obtain the most complete picture of their patient’s health, and thereby deliver safer, better- informed, and more comprehensive care.
Specifically, Query HIE may allow providers access to important information that may have otherwise been missed. For instance, medication allergies that a patient had not mentioned, or test results that were not previously provided.
While some effort is required to establish Query HIE, it can ultimately reduce the burden on administrative staff. Query HIE reduces the number of phone calls and faxes necessary to obtain the same information via conventional means. It increases the reliability and accuracy of the information exchanged, and can largely eliminate having to enter the data into the EHR system manually.
What are the cons of sharing data via Query HIE?
There are a few potential concerns to keep in mind when using Query HIE to share data:
- “Echoing” of data may occur, which means that data that originated within a provider’s own organization comes back to the provider via a query (see FAQ section on data provenance below).
- In addition, healthcare organizations may find it challenging to integrate complex federal and state privacy regulations to ensure their system manages each specific patient’s situation appropriately. For instance, Massachusetts law imposes specific restrictions on sharing behavioral health information for MassHealth (Medicaid) patients.
Query HIE actually has the potential to help in this regard, because providers can customize their system settings so that sensitive information is segmented and protected, thereby reducing the likelihood that human error results in the release of sensitive information.
Keep in mind that these concerns are not unique to Query HIE. Echoing concerns also apply to Direct Messaging, and privacy and security regulations apply to all methods of Health Information Exchange.
How do I enable Query HIE and make my patient information accessible to other providers?
Connections to Query HIE networks are dependent on the provider’s EHR vendor, and the process of enabling Query HIE functionality varies by vendor. For more information about the Query HIE functionality available to you, and how to enable this functionality, review the "Vendor Status Directory" in the Query HIE Toolkit, and contact your vendor.
Who can make the queries for patient information?
Physicians, medical assistants, administrative staff, or others who work at a hospital or health center can make queries for patient information as long as they have this privilege authorized by heir office or department.
What is the recommended workflow for conducting a query?
The workflow may be dependent on your EHR system and the Query HIE Network(s) it can connect to. Example workflows are provided in the “Workflows” tab of the Query HIE Toolkit.
What data points are used by the Query HIE Networks to find patient matches?
Patient matching algorithms use a number of demographic data elements to identify the likelihood that a patient record corresponds to a certain patient. These elements include first and last name, date of birth, and social security number. To be successful, it has to match a certain number of those data elements.
What if a query returns multiple potential patient matches?
In all cases, there is a threshold for the quality of potential matches that are returned. The threshold and what the system does may vary depending on criteria defined by the EHR vendor and the policies in place at the provider’s organization. For instance, when a patient match is found:
- If there is a perfect match, the system may automatically “link” the patient and integrate their outside record.
- If a query found the right patient but the “high quality” threshold is not met, the record may not be shown at all.
- If there is no perfect match, the system may display the best potential match(es) and allow the provider to either confirm or reject the patient’s record(s).
- If there are multiple matches, the system may not show any patient record, or it may show all matches but the records won't link automatically.
For more information about how your EHR may handle the various scenarios, contact your EHR vendor.
What happens if a patient's providers are not all on the same network?
Unless the Query HIE Networks are connected, providers can only retrieve information from patients seen by providers on the same network.
If you are on Carequality, can you query Commonwell and vice versa?
That depends on whether your EHR vendor enabled the Commonwell–Carequality Connection. A provider with an EHR connected to Commonwell can query patient data from other providers connected to Commonwell. Likewise, a provider with an EHR connected to Carequality can query patient data from other providers connected to Carequality. However, if the provider’s EHR vendor enabled the Commonwell–Carequality Connection, the provider can also query patient data across the two networks, and most participating EHR vendors have enabled this connection.
What is the scope of the Record Locator Service (RLS) of Commonwell and Carequality?
An RLS establishes the patient-provider relationships for providers connected to the network. Providers can query and retrieve patient information from providers that are within this scope.
- Commonwell has an embedded RLS. The relationships are based on encounter information. The scope is the providers connected to Commonwell.
- Carequality does not have an embedded RLS, but uses the Surescripts NRLS. The relationships are based on Surescripts eligibility verification and prescription transactions. As such, the scope is the providers who use Surescripts, which includes providers connected to Carequality, but not all of them, and includes providers who aren’t connected.
- The Commonwell – Carequality Connection combines the scope of the RLS of each network, making the provider-patient relationships visible across the two networks.
Can a disease registry use Query HIE to obtain information such as A1C lab results of a diabetes patient?
Yes, a disease registry or other government department or agency can join a Query HIE Network. They would be listed as a separate type of organization and they would be bound by a separate set of minimum obligations.
In what format is the information made available?
Typically, the information is shared as a Consolidated Clinical Data Architecture (C-CDA) document. Sometimes information may be shared via PDF or other document types. Many EHR systems offer features that allow providers to select the information they consider relevant for reconciliation and integration.
Is manual manipulation of data still required during the reconciliation?
In some cases, providers may wish to specifically select certain data to integrate into their patient’s record.
The data reconciliation process may combine automated and manual elements.
For more information about the data reconciliation process, see the "Functionality" tab of the Query HIE Toolkit.
What is data provenance and how does it impact Query HIE?
Data provenance is defined as the "origin of data". In HIE, provenance indicates who originally sent the information stored in the patient’s record.
During HIE, “echoing” of data may occur, which means that data that was originally shared by a provider comes back to the same provider via HIE. The result is that the information may start to duplicate.
Query HIE Networks are working on solutions for tracking data provenance and minimizing echoing. By recording where the data originated, the Query HIE Network will be able to eliminate the echoing of query data.
Query HIE functionality may also minimize duplication by visually highlighting information that has already been accessed before, so providers can focus on only the data that is new.
1-855-MA-HIway