Bi-Directionality Policy
Background
The national networks, like CommonWell, Carequality, and eHealthExchange, are formalizing into Federally mandated Qualified Health Information Networks under TEFCA. This is exciting progress that will solidify a robust and powerful ecosystem of data exchange across EMRs, labs, HIEs, payors, government and the digital health sectors. A major component of this is to ensure that actors practice reciprocity in the pulling and sharing of information. In other words, "give to get." The networks would not sustain themselves if organizations took data, but did not share. As these organizations formalize and build upon the foundational infrastructure already established, it will become more important to ensure that every connection is fully participating.
Guidelines
Particle's Bi-Directionality Policy is designed to ensure compliance with current networks rules, but is also working to ensure that they align with the evolving TEFCA ecosystem.
- During the implementation process (pre launch):
- You are required to submit historical and net new records for any patient that you query for the purposes of testing your integration flow; these records must be posted within 1 month of initial query(s)
- You may not go live with production query volume until the following criteria are met:
- Connectivity: Demonstrated ability to push data on a monthly basis (or more frequently) to the Bi-directionality API
- Query Responder Obligations:
- You are required to submit historical records for any patient that you create via the Particle Patients API, within 1 month of creating the patient
- From that point forward, you are required to submit any new data that you collect or generate on the patient, such that you continue to fully and completely represent the data and resources available in your systems for the patient. Any new data or resources must be posted within 1 month of when the data was collected or generated.
- For example:
- If you are going to query for Bob Smith’s records, or have subscribed to have Particle monitor Bob Smith, the network expects you to submit Bob Smith’s historical data.
- If Bob Smith is a new patient, whom you have no data on, you can delay the historical submit up to one month until after the patient’s encounter.
- If you have made Bob Smith’s data available to the network, you may query for Bob’s records multiple times (limit of 2x/month).
- If you have high sensitivity patients (e.g. high risk, post-discharge), you may query them more often (limit 2x/week).
- If you have subscribed to monitoring for Bob Smith, Particle will query the networks to identify new encounters and data for Bob Smith on an ongoing basis, adjusting the cadence depending on patient sensitivity, as determined by ADTs, network alerts, and utilization trends.
- If you have a new encounter with the patient - or made aware of a new patient encounter that has occurred - you must submit any data or resources associated with that encounter within 1 month of the encounter.
- If you collect or generate any other updates to the patient record, such as an update to treatment recommendations, potential care gaps, care plans, etc, you must submit any associated data or resources within 1 month of when they were collected or generated.
- Dataset: Patient data uploaded should be:
- Ideally, CCDA format
- PDF is OK for clients that utilize our core CareQuality & CommonWell integrations.
- For clients that are interested in leveraging our eHealthExchange (eHX) integration in addition to CareQuality and CommonWell, CCDA documents in XML format is preferred. Additionally, clients that leverage eHX must commit to fulfilling their requirements within 6 months of activation. Please speak with your Particle Health representative for more information.
- The data made available to the networks should be ‘Net New Data’ - i.e. data created in your system related to an event. Sharing the data previously pulled from the network back only creates duplicate data and an echo effect.
- The data should be as close to the USCDI V4 requirements as possible:
- Allergies & Intolerances
- Assessment and Plan of Treatment
- Care Team Members
- Clinical Notes
- Clinical Tests
- Diagnostic Imaging
- Encounter Information
- Goals
- Health Insurance Information
- Health Status
- Immunizations
- Laboratory
- Medications
- Patient Demographics
- Problems
- Procedures
- Provenance
- Vital Signs
- If the above dataset cannot be met, there is flexibility in limiting what is shared based on the organization's unique capabilities.
- Accountability: We are required to report the above metrics to Carequality and Particle is responsible to ensure our partners are participating according to the agreement. Because we are at risk of being suspended from the network (we have seen other implementers get suspended) we will be forced to turn off access to querying the network if the following are not met:
- Connectivity: Not updating patient records in conjunction with querying
- Query Responder Obligations: Historical records are not provided for all patients and/or any new data or resources available in a customer’s systems are not continuously made available in a timely fashion.
- Dataset: Data being shared is not helpful to a provider at the point of care
Our recommended procedure is to upload your entire patient population at the beginning of Implementation. Particle offers CRUD and List operations via our Bi-Directional API, allowing you to then just refresh/update or delete data as you begin running queries against your patient population.
Please do not hesitate to contact your Solutions Architect or Customer Success Manager with questions.
Updated 20 days ago