The questions below are meant to help you with digital record retrieval or our other Carequality offerings.
We're a certified Carequality implementer. Implementers are approved by Carequality to help their partner organizations connect to the Carequality Interoperability Framework. Basically, we can serve as your on-ramp to the Framework. With us as your implementer, you can start exchanging data across the Framework in a matter of days rather than months.
As your implementer, we complete the following steps for you:
If you want to test this arrangement out, sign up for our digital record retrieval to get a jumpstart.
Being a Carequality participant can entail high incoming request volumes. These volumes are influenced by factors such as the geographic location or total number of your facilities. Many Carequality participants use automated workflow triggers to send outbound requests using algorithms with radius-based searching around the patient’s address. Rural areas may receive 10K–25K of these requests daily, whereas geographic areas with high population density—such as the San Francisco Bay Area or New York metropolitan area—may see daily request volumes of up to 200K per location.
As your responder, we can shield you from this traffic to simplify your flow so that you only need to send new or updated information to us, and we take care of the rest with the data you already have.
If you prefer to respond to incoming traffic yourself, you won't qualify for digital record retrieval pricing. Contact a Redoxer to discuss options and pricing.
Digital record retrieval is a low-cost way for you to start your Redox journey by integrating with the Carequality Interoperability Framework. To see if you qualify, check if your organization can answer the following questions like this:
If you don’t qualify for the starter package, there’s no need to worry—we can still help you connect to the Framework. Contact a Redoxer to discuss options and pricing.
One easy-to-use Redox configuration can connect you to Carequality, as well as healthcare organizations, EHR systems, and other integration partners you may have. You can use the same requests to search for patients and clinical documents, allowing you to send data either directly to an individual EHR system or nationwide over the DirectTrust network.
Contact a Redoxer if you have questions about connecting to these types of organizations.
Learn more about data models we support, including fields, requirements, and details for each one.
When using digital records retrieval, you have a limit on the number of API calls you can initiate per day and per site to the Carequality Interoperability Framework.
An API call is defined as sending a request via Redox that results in a response from the Framework—this includes searches for patients that do not return matches.
For digital records retrieval, your API limit is 25K API calls.
These requests are included in your total allowable amount per day:
To locate a patient and retrieve their documents, you need two API requests at a minimum (PatientSearch.Query and ClinicalSummary.PatientQuery). This means that you can locate up to 12.5K patients per day at most with digital records retrieval—so long as you don’t use any other requests. Given this, you can calculate whether that limit is sufficient depending on whether a patient may exist at multiple healthcare organizations within your geography.
Some API requests are excluded from your API call limit:
The PatientSearch.LocationQuery is excluded from API limits since you may need to poll the endpoint a few times while waiting for it to reach a success state.
Requests to create or update patient data also don’t count toward your total API calls, since Carequality requires that you provide data about your patients to other participants.
The Carequality Interoperability Framework comprises over 600K physicians, 50K clinics, and over 4,200 hospitals. Explore our network and the Carequality participants or you can use the Carequality search to see if your partners participate in the Framework.
Commonwell and eHealth Exchange are two of the nation’s largest centralized health information exchanges. Both are certified Carequality implementers with thousands of live sites, meaning that many of their sites can be queried through the Framework.
Pulling data is powerful for various use cases (e.g., emergency care), but it doesn’t solve all problems. Pushing data can be useful for provider-to-provider messaging, event notification, diagnostic test ordering, and referrals. While Carequality and Commonwell don’t currently support push notifications, we have other options to help you accomplish your goals. We can help you push data through the DirectTrust network and other technical means. Contact a Redoxer to learn more.
Carequality has two main requirements for participation:
These two foundational principles are what make Carequality so successful. They ensure that a patient’s entire clinical history is available nationwide to retrieve.
An organization is exempt from mutual exchange if they meet the following exceptions:
If your organization doesn't meet these exceptions, you're required to respond to incoming requests with your unique clinical data. We can make it simple for you to respond to all of these requests.
An OID is a globally unique ISO (International Organization for Standardization) identifier. They are important in the context of Carequality in that they uniquely identify participating organizations. To create your organization and facilities, you must use an OID as the primary identifier. Learn more about OIDs.
As a registration authority, we have a base OID, so you will have an OID branch assigned for your use. This is typically a branch off the base OID
We provide three OID types for you when you connect to Carequality, which you can see below. If you believe you need additional OIDs, contact a Redoxer to discuss options and pricing.
|OID type||Definition||OID structure|
|Organization||This identifier corresponds to your organization on the Framework. For digital record retrieval, this OID type is used only for one organization and facility.|
|Patient||This identifier corresponds one-to-one with your MPI(s). We create the first one for you, but if you have multiple MPIs, you should create as many patient OIDs to equal the number of MPIs.|
|Document||Every document requires a globally unique ID to be exchanged on the Framework. This can be either a version 4 UUID or the Redox-generated OID followed by your ID (e.g. |
Your organization is likely part of the Redox gateway OID (
If you're responding to Carequality on your own—or if you have a valid exception to mutual exchange—your OID is different (
Digital record retrieval pricing requires that you use an OID that we provide. If you would rather use an existing OID, you can contact a Redoxer to discuss your needs and get more information about pricing.
You may need to register multiple organizations if you meet one of the following criteria:
If you need to register multiple organizations in the directory, you won’t qualify for our digital record retrieving pricing. Contact a Redoxer to discuss your needs and get more information about pricing.
To improve the robustness of our test system, we currently isolate it from the data that you push to Redox as a responder. This ensures the integrity and consistency of our test system, but comes at the cost of you not being able to find your own patients that you add to the Framework.
If you truly need to find your own patients/documents, you can search your data on demand repository using PatientSearch.Query, Clinical Summary.DocumentQuery, or ClinicalSummary.DocumentGet. In your request, just switch the
destination.ID of the Framework to the
In this case, your IDs match exactly what you sent. Just note that this isn't the ID that appears on the Framework.
To guarantee uniqueness on the Framework, Redox assigns new IDs to all patients and documents that you send. So if you send a patient with ID 1234 or a document with ID 5678, you won't be able to find your own data on the Framework with those IDs.
If you want to retrieve the Framework-assigned IDs, you must perform a search with demographics to Redox, then find the documents for that patient. This also allows you to find data from other Carequality participants (that are connected via Redox) that may be for the same patient.
To locate an exact match, you must include all of these fields:
And at least one of the additional data points below:
As a best practice, we recommend that you include as much information as possible. Most responding systems use advanced matching algorithms that have higher success rates when more information is included.
If you receive a successful response to your PatientSearch.Query without any results, it typically means that there were no matching patients found. You may want to search with a smaller set of demographics or verify that the patient’s information is correct.
You can search for a patient with an identifier if you have the specific patient ID and the matching OID that the organization uses to represent a patient OID type. For example, if using an MRN, you must have the OID that the organization uses to represent MRN. However, these OIDs are not typically known. Organizations often have a specific identifier for Carequality responses, so we recommend starting with a demographics search, even if you do already have an identifier.
When you use the PatientSearch.LocationQuery, our Record Locator Service runs the search for you. However, it may take awhile to return all the results because Record Locator Service has to send the request to each connection individually. You can always check the status of your search by looking for the value of the
Meta.Extensions.task-status.string field, which contains a status of either Active or Success.
|The process is asynchronously collecting locations.||The |
|The process has completed and all possible locations were found.||Any available results have been returned. If the |
The response waits up to 10 seconds to reach a Success state. If unable to reach Success in that time, the response retains an Active status. You can retry the exact request repeatedly until it reaches a Success state.
To review the results of your search again later, you can provide the value returned in
Meta.Extensions.task-id.string on subsequent requests.
If you run a new search with the same patient demographics within a 24-hour period, you see the same results. Record Locator Service doesn't trigger a new search to your connections unless you have new or modified patient demographics.
The Framework supports the exchange of C-CDA documents, which is an industry-standard for exchanging patient and visit information. The two primary types of supported documents are patient summaries and visit summaries. Patient summaries represent a current—or nearly current—snapshot of the patient’s chart while visit summaries contain a patient’s chart for a specific visit and should be treated as accurate as of the visit date.
The list below contains a summary of rules for returned data. Learn more details about HL7 standards.
nullif there is no relevant data or a participant doesn’t have the ability to include data):
ClinicalSummary.DocumentQuery has a number of useful parameters you can use to limit the number of documents returned or to find the documents that are relevant for you. However, not all parameters are supported by all vendors. When supported, you can use the
Visit.StartDate parameter to help you pull documents after a given date of service. Learn more about which fields are supported for this request.
Some customers have pre-built capabilities to render XML C-CDA documents. Additionally, there are many available open source CDA renderers that can be useful in viewing the document. We offer the option to return the XML document for this reason.
Check out these options for an open source C-CDA renderer:
Yes, you could respond to requests from Carequality participants yourself, but you won't qualify for digital record retrieval. Contact a Redoxer to discuss options.
We store all requests to and from the Framework per our standard data retention policy. Learn more about our data retention policy.
In order to respond on your behalf to incoming requests, we store all of the data you push to our database for the life of your contract. This way, we have complete information with which to respond to incoming requests.
We require that you push data (via ClinicalSummary.VisitPush) to our database for every instance in which you treat a patient—but don’t worry, you don’t have to push data immediately after every treatment. For example, you're welcome to push a daily batch to us instead.
We also require any and all patient demographic updates so that we can keep your patient demographics current. This enables us to provide accurate responses to other Carequality participants when they send a request to find out whether a patient has been seen at your location.
Carequality requires that you respond to requests for patients that are known to you, but they don’t specify a definite period for providing historical information. We recommend that you begin pushing data once you register your organization in production and build your historical data from that point forward.
If you want to send historical data, you may not qualify for digital record retrieval. Contact a Redoxer to discuss your needs.
Got trouble? Here’s a list of resolutions and insights for common errors.
If you receive the error below, it means that the correct ID is missing in the
No subscriptions. Meta.Destinations needs to contain a destination from existing subscription.
In other words, we don’t recognize a valid connection, so you need to populate the ID in
Meta.Destinations to indicate where you intend to send your request. The table below lists the correct destination IDs based on the request purpose for both staging and production environments:
|Request purpose||Staging ID||Production ID|
|Query for/create/update/delete an organization|
|Search for a patient within the entire Framework|
|Search for a patient within a specific organization|
|Search for a clinical summary/document|
|Save patient details and documents to your repository||This is specific to your org—you can find the correct ID in the digital record retrieval wizard.||This is specific to your org—you can find the correct ID in the digital record retrieval wizard.|
We work to ensure first-in, first-out (FIFO) order so that data arrives in its intended order. Receiving the error below indicates that there was an error processing an incoming message.
Cannot process messages for Data Chateau environment 'environment', the environment is in a 'error' state.
At this point, we pause future messages from filing to ensure that data is not missed or corrupted. Contact our Help Desk to reset the environment.
We follow Carequality’s Technical Trust Policy in order to connect to the Framework. This includes provisions like which certificates to exchange to participate in the Framework.
The “unable to get local issuer certificate” error means that the certificate issuers in the sandbox (i.e., staging) environment changed, and one or more of the Carequality participants hasn't updated to this new certificate chain.
To avoid this error, we recommend using the Redox test patients and Postman examples to test with since they should always work. We keep them current and working correctly on our end so that you can just focus on testing.