Bi-Directionality Policy

Background

The national networks, like CommonWell and Carequality, are formalizing into Federally mandated Qualified Health Information Networks.  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.  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 is doing the work to establish clear guidelines and policies to make sure there is no confusion about what is expected from the evolving TEFCA ecosystem.

  1. During the implementation process (pre launch):
    1. You are required to load 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)
  2. You may not go live with production query volume until the following criteria are met:
    1. Connectivity: Demonstrated ability to push data on a monthly basis to the Bi-directionality API
    2. Reciprocity: Patient records are queried & shared to a 1:1 ratio
      1. If you are going to query for Bob Smith’s records, the network expects you to load Bob Smith’s data
      2. If Bob Smith is a new patient, whom you have no data on, you can delay the load up to one month until after the patient’s encounter
      3. 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)
      4. If you have high sensitivity patients (e.g. high risk, post-discharge), you may query them more often (limit 2x/week)
    3. Dataset:  Patient data uploaded should be:
      1. Ideally, CCDA format
      2. PDF is also OK
      3. 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.
      4. The data should be as close to the USCDI V3 requirements as possible:
        1. Allergies & Intolerances
        2. Assessment and Plan of Treatment
        3. Care Team Members
        4. Clinical Notes
        5. Clinical Tests
        6. Diagnostic Imaging
        7. Encounter Information
        8. Goals
        9. Health Insurance Information
        10. Health Status
        11. Immunizations
        12. Laboratory
        13. Medications
        14. Patient Demographics
        15. Problems
        16. Procedures
        17. Provenance
        18. Vital Signs
    4. If the above dataset cannot be met, there is flexibility in limiting what is shared based on the organization's unique capabilities.
  3. 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:
    1. Connectivity: Not updating patient records in conjunction with querying
    2. Reciprocity: Query:Load ratio is moving beyond 1:1
    3. 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.