A Turning Point: Interoperability 101 Course FAQs

Curious how this all plays into research use and getting patient consent for data sharing…

EMRs will not respond to any query other than Treatment today, even with a patient’s signed HIPAA authorization request.

‍

Why do you need to request data from hospitals/health systems? Are there other entities you can request data from? HIEs? Payers? Patients?

Most clinical data lives in EMRs. HIEs and other types of stakeholders are part of the networks and we do get data from them too, but the vast majority of the data comes from EMRs across the networks.

‍

What is defined as a healthcare organization? (subject to TEFCA)?

Covered Entities.

‍

Is there a high likelihood of government regulation forcing out fax machines?

No, fax will always be an option but the cost is high to manage data exchange from fax. Organically, however, health systems will be moving away from paper to digital exchange of information.

‍

How much information never makes it out of the point of care typically even if you get a “whole take” via fax or, if it differs dramatically, using an HIE or EPIC path? Or is it pretty reliably everything?

Good question - different methods will yield different datasets. Fax gets everything, while HIEs will yield a CCD under the USCDI V3 requirement.

‍

Relate to the above question, doctors frequently complain that they’re really adding in billing data vs. useful clinical data. When this information is extracted, is it a dump of everything mixed together, or separated clinical and billing, or something else?

CCD requests yield a set of records, all mixed with different types of data. Converting those CCDs to a FHIR dataset allows for the parsed data to be categorized, making it easy to ‘grab’ just what you want.

‍

Would it be considered 'treatment' if the organization is using the data for 'health care operations' purposes for quality measurement/improvement?

Healthcare Operations is defined differently than Treatment. Quality falls under the Operations Purpose of Use (PoU). The best way to think of it: if you’re querying for a single ‘step’ — i.e. patient is coming in for an appointment — then it’s Treatment. If you’re querying for multiple ‘steps’ — i.e. pulling data on a cohort to decide who needs to come in for an encounter — then it’s Operations.

‍

Why would home visits/post-discharge visits not be considered treatment?

If the organization is not a covered entity or a BAA of a covered entity, it is not Treatment. It is possible for a home visit to be Treatment under this definition.

‍

When electronically requesting the data from a network centralized repository is the data organized as discrete data fields or PDFs, or both?

Networks are federated — not centralized. The data is returned from each endpoint independently, and when aggregated, may be thousands of CCDs for one patient. The data is not organized when retrieved. Particle can consolidate and parse CCDs into a single, unified record in FHIR. At this point, it is now organized.

‍

Have you seen Research as "treatment" purpose of use?

It is possible for research to be considered Treatment, but only if the patient is receiving care and it ‘just so happens’ that they’re also enrolled in a trial/study.

‍

For those that are not technical, is C-CDA vs. FHIR kind of like Word vs. PDF?

CCD vs. FHIR is kind of like Crude Oil vs. Gasoline. Crude Oil contains all the energy required to run your car, but Gasoline is distilled and organized such that it’s ready to be used in a real-world setting. We actually have an article written about these different data formats – check it out here.

‍

Any suggestions regarding large-scale, realistic sample FHIR datasets to experiment with? I see MIMIC was translated to FHIR. But what about things happening outside the ICU?

Sythesia is a great, free tool to generate synthetic data in multiple formats. While it doesn’t quite reflect the nuances of real-world HIN data, it’s close enough to get started.

‍

What are the differences/similarities between what is contained within ADT data vs. C-CDA?

ADT (Admission, Discharge, Transfer) notifications are meta-data rich, real-time pings that an event has occurred. These messages don’t contain meaningful information on ‘what’ happened, but rather ‘where’ and ‘when’.C-CDA, on the other hand, is clinical-rich data. It is not oriented towards ‘live notifications’ but contains the information on the ‘what’.

‍

Does HIN data become available in real (or close to real) time? How long after an appointment is the data typically available via the network?

HIN data becomes available on an EMR by EMR basis. Some EMRs make it available very quickly (hours) while others can take up to a day.

‍

How quickly is HIN data retrieved (for example, in a high-acuity use case?) Can you repeat the # or % of health systems that participate in a HIN?

It takes between 30 seconds and 1 minute to query, download, pull, and parse a patient's record on average. This can take more time if there’s more data. Some patients have 10,000+ documents.

‍

What’s the approximate cost of an integration with an HIN? i.e. how long will it take?

HIN fees are different depending on which HIN you’re integrating with. Most have ‘set up fees’ and ‘testing fees’. HINs also have variable, yearly fees based on either (a) how many transactions you conduct or (b) how much total revenue you generate. Costs on a per HIN basis range from $20,000/yr to $500,000/yr.

‍

One of the key challenges to obtaining medical records is understanding a company’s problem statement and use case. What are the best uses of this data? What are the regulations here? For example, can you use this data to screen for new patients for your services and reach out to them?

Anything under the Treatment PoU is fair game. Interestingly, secondary use of the data is also fair game, so long as it fits under HIPAA. We see a lot of use cases fall under the “managing risk” theme; e.g. identifying unknown conditions, lab results, gaps in care, etc.

‍

What is the difference between HIE/HIN — keep hearing those terms used interchangeably — is that the case?

There is no official difference — however — the industry typically uses HIE for state exchange and HIN for national exchange.

‍

How does HIE/Networks resolve the issue that Integrations (i.e. Redox) run into with having to get a BAA from each individual entity?

Large HINs have standardized the BAA across all their participants. The BAAs are non-negotiable. This type of agreement is what TEFCA is formalizing into the “Common Agreement”.

‍

Any thoughts on work cloud providers are doing to support interoperability? I.e. Azure FHIR services, AWS Health Lake, GCP Healthcare Data Engine?

Interestingly, cloud providers do not (and seemingly will not) build their own HINs, connect directly to HINs, etc.

‍

I’m interested in the bi-directional nature of these networks in networks. You spoke a lot about getting data, but what about use cases where we are trying to notify providers about recent healthcare events for a given patient?

The networks today are ‘pull’ based, in that you must query for a record. There exists technology today to offer ENS, or Event Notification Services, however, it is currently optional and the vast majority of the network participants don’t support it.

‍

Who judges the legitimacy of the PoU when requesting from networks?

Each healthcare organization is liable and accountable for determining its use case and legitimacy. While HINs and Particle can provide guidance, we do not know the intricacies of your product, workflows, and use case, nor do we have control of what is really happening behind the scenes.

‍

How did you at Particle determine if interoperability was really what a customer needed because, of course, everyone would like to have the ability to share data more easily? And as a result, that it was worth it to go through the expensive process of integrating with their EHR.

Value is created by making better, faster decisions. Interoperability allows for the seamless acquisition of net new data such that it can enable better, faster decisions. Most organizations in value-based care (VBC) settings need as much data as they can get to manage the risk of their population. Intervening with that one patient that otherwise will go to the ER next week can save tens of thousands of dollars. 

‍

When looking at Network of Networks, you said that providers see a very high hit rate in getting access to records whereas payers and something like Homecare will not. I work for a PACE program that operates as all of these within one organization — what would access look like when as an organization we are both the provider and payer?

Organizations that run Treatment, Payment, and Operations Use Cases can still connect and leverage network data. Their initial purpose of use must be Treatment, but subsequently, the data can be used secondarily for other Purposes of Use (PoUs).

‍

Can I use clinical records obtained via Particle Health to do a compatibility score for the patient and a clinical trial, then delete the patient data without having to be HIPAA compliant, the app would only retain a qualification score.

The reason we call it “Purpose of Use” or “PoU” is to indicate the reason or intent as to why we are requesting PHI. If the purpose is for trial matching, then the PoU cannot be for Treatment. You can request data for trial matching, however, it will need to be under a different PoU — like Individual Access.

‍

What is the latest on “Direct Protocol”? I heard about it a few years ago but not much since.

Direct Trust (or Direct Messaging) is an older, but still widely used, method of data transfer. It’s very similar to HIPAA-compliant email where you need the address to send the data. There hasn't been a lot of innovation with Direct Messaging in a while, but it’s not a bad option if you know the address of the recipient provider.

‍

Going back to your (digital) information-sharing modalities, how would you rank in order of decreasing completeness of exchanged info: integration engines, networks, and EHR portals?

Generally speaking, fax is most complete, then networks followed by portals.

‍

When you get access to an EHR’s data via a network, does it automatically include all provider’s data or does the provider need to subscribe?

Most EHRs natively opt-in to a HIN under the Treatment PoU. It’s taken years for EHRs to all opt in, but we are now well past substantial coverage.

‍

By 'Portal & EHR path' are you referring to something similar to Epic MyChart?

Yes! Either through an EHR, like App Orchard, or via OAuth/SMARTonFHIR Integrations like MyChart.

‍

What’s the role of interoperability in insurance admin like prior auth?

Interoperability should begin to impact more use cases outside of Treatment as TEFCA rolls out. Prior Auth is a good example where a diagnosis can be pulled via API granting authorization for a certain medication to be filled and covered by a payer.

‍

Is it correct that digital, non-physical (i.e. excluding fax and CD-ROM) health info sharing modalities arranged in order of decreasing detail are integration engine (e.g., Redox), HINs/HIEs, and patient EHR portal?

This order is essentially correct. From most data to least: HL7 Integration > HIE/HIN > Portal.

‍

When we talk about "data", what is the scope of this? For example, on top of PHI/patient data, does this include imaging or financial info/claims data?

See USCDI for info on what data is shared via networks.

‍

Are each of the "first six QHIN applicants" trying to create their own unique QHIN?

Yes. They will all be essentially the same, in terms of functionality.

‍

If participants in TEFCA can only choose a single QHIN, would a sub-participant (health system with possibly a dozen EHRs including both CommonWell members and Epic, and others) need to work with multiple participants/vendors? Does this just further complicate implementation?

Sub-Participants would only need to choose one Participant. This is because all QHINs must be fully interoperable with each other, thus making no difference where a Sub-Particpant decides to connect — at least in terms of coverage. It is my belief that Participants will be very differentiated, however, in terms of value props.

‍

Why is there the “only one QHIN” limit? If QHINs are connected to each other, perhaps integrating with one covers the whole ecosystem?

Correct. Connecting with one QHIN gets you full access to all QHINs. QHINs share a directory, so organizations can only be represented one time.

‍

Is it absurd to think today that a company like Particle could scale globally? Are there equivalent HIEs in other countries plugging into this network of networks?

Every country has a vastly different data interoperability landscape. Some are single-payer systems, some are government-run. The model is so different that Particle’s tech would likely need to change significantly to accommodate these nuances.

‍

I don’t understand how health system-owned data (i.e. patient data) can be shared via QHIN by an EMR (i.e. Epic). Can you explain? Why are provider CISOs not thinking about their data being shared via QHINs?

Health systems buy EMRs to manage their data. EMRs must also meet certain requirements to receive federal subsidies under CMS (See HITECH Act). One of these requirements is the ability to share medical data across different HCOs.

‍

What's the reasoning behind the creation of multiple QHINs? Isn't fewer better?

There will likely be a limit on how many QHINs the ONC permits. By having more QHINs in the beginning, we will get more competition and a faster race that should lower prices and promote the best QHINs to the top of the pack. We expect to see consolidation as QHINs compete, costs lower and QHINs become more of a utility than anything.

‍

What is the timeline around Bulk FHIR requirements? And what use cases do you foresee being supported/allowed? Will individual authentication/authorization be necessary?

Developers must certify any Health IT Module that is part of a product that electronically stores EHI to the § 170.315(b)(10) EHI export criterion, and it must be available to their customers by December 31, 2023.

‍

Is data extracted from QHINs identified/identifiable?

Yes, data from QHINs is identified. You must query for a patient’s records using identifying information (Name, DoB, Address, etc.).

‍

Do you get access to the entire QHIN network by connecting to one QHIN node? or do you need to connect to each QHIN?

Yes. The fundamental principle behind TEFCA is QHIN-to-QHIN interoperability. Connecting to one gets you full access to all QHINs.

‍

When do you expect the average doctor to be able to pull full medical records of their patients to inform clinical decision-making?

That exists today through organizations like Particle!

‍

The requirement for participants in the HIN to provide data (and not just consume it) really reduces the number of entities that can use this information — payers in particular are excluded, even though they would profit from having a longitudinal view of their members’ data. Is this a requirement you see being maintained?

The Treatment PoU is the only Use Case that requires reciprocity. Other PoUs, like Operations, which would cover the Payer use case, do not require reciprocity.

‍

Does the difference in the 'anatomy' between HINs lead to a difference in the output of data when it comes into an app via Particle depending on where the data is coming from? How does this impact clients?

All HINs must respond to queries with a minimum dataset, a set called the USCDI.

‍

Given the # of payers participating in HINs, why is it hard to find the payer associated with a patient in real time? When will finding these data accurately and in real-time be accessible?

While payers are connecting to HINs, their use case is often times Operations, not Treatment. As such, they are not leveraging the HINs currently.

‍

Any sense of what’s driving the geographic endpoint spread? Why low in NY and CA for example?

The biggest reason for state discrepancies is the Opt-in vs. Opt-out state policy. Some states, like New York, require patients to Opt-in to share their data via HIEs/HINs while other states require patients to Opt-out. The states that are Opt-out have many more accessible records.

‍

On eHealth networks (or any HIE) is there representation from DoD / active military or just the VA?

The DoD is connected to eHealth Exchange.

‍

When measuring success rate, what counts as success? For example, if your query returns a result but doesn’t find all the results, is that success?

We look at 2 factors: (1) did we find a patient match, successfully? And (2) how many records did we find in that match?

‍

Does Particle have sample data it can share of what’s returned?

You can create a free account in our Developer Portal to view synthetic sample data. Sign up today here.

‍

Could you go over how the 3 big HINs relate to the six QHIN applicants?

HINs today are separate from the incoming QHINs. While they’re built on the same principles, they are different ecosystems. QHINs will have more functionality than HINs, but they are different and do not interoperate. Some of the major HINs today will be QHINs (eHealth Exchange and CommonWell).

‍

How should companies think about which data to send back to HINs so they are sharing enough to comply but not so much that are flooding the network with too detailed data? Any checks in place to stop an organization (e.g., thinking the thousands of care startups) from sharing back just too much very low-value data?

We have guides around this question, but simply put the HINs ask to share as much of the USCDI as possible. The major question is: what data do you have that a provider somewhere else could use to better treat a patient?

‍

What qualifies as production access to Particle? (Does this barrier prevent smaller non-venture funded startups from leveraging this capability?)

Unfortunately, yes. It is costly to onboard a customer on Particle and so we must charge for production access.

‍

How would Particle or other NoNs learn what's useful to providers without a two-way link to the point of care (for feedback/dismissal/etc rates)?

Working directly with our customers for years has given us insight into how to deliver data products that target provider use cases. We get lots of feedback from our customers who oftentimes are providers themselves.

‍

For querying CareQuality or eHealth Exchange, what is stopping Particle or similar from just querying every zip code/health system in the US to find records vs. having to choose certain geographies or systems? Computing power?

While technically possible, the network traffic would be cumbersome and obvious. Network participants would complain about being queried by Particle over and over again.

‍

What does Particle do to validate the accuracy of the data? How broad and deep is the data validation (across all data elements and all health systems)? For example, if lab data is returned for a patient, what does Particle do to confirm that the lab data that is returned matches the data that a clinician would see in the UI of the EMR, if the clinician accessed the EMR directly?

Ultimately, Particle can’t confirm the data returned is 100% the correct data. This falls on the EMRs to ensure patient matching is accurate.

‍

How long does it take for a new version of USCDI to be implemented and the corresponding data returned in the network queries?

Hard question to answer since it is gradually adopted across the ecosystem. Technically, organizations have ~6 months to comply with the new USCDI requirements as they roll out.

‍

How is Particle’s work different from what Health Gorilla offers?

The biggest difference is the way we integrated with the three networks. Taking a look at our API docs vs. Health Gorilla’s API docs will show how Particle has consolidated the three networks into one API while Health Gorilla has three separate flows for each network. This has downstream implications about how to manage queries.

‍

Value-based care risk management is usually managed by payers (ACO plans aside), but my understanding is that they can’t participate in these data-sharing networks since they don’t have primary records to add. Am I misunderstanding that relationship?

Payors can use these networks if they have a valid Treatment PoU use case. Many payors do this in the form of technology their providers use.

‍

What constitutes a treatment PoU? Can EMS operating under the medical license of an MD call patient data under a treatment PoU?

EMS typically falls under Treatment. Ultimately, you’ll need to reference HHS’ definition of Treatment and confer with legal counsel to be sure!

‍

What are your thoughts on empowering and enabling patients/consumers to access, collect, and share their own CCDAs? how can we articulate the value added to the industry that seems to be focused on providers?

Anything to get Individual Access up and running I’m a huge fan of!

‍

Aneesh mentioned that 291 EHRs were certified, where can I find that list?

Here is a good starting place: https://chpl.healthit.gov/#/search

‍

How do small practices (like mine) fit into all of this? It seems a lot of these services would be too expensive for them (both hard cost and time to implement).

Small practices should look into HIN/QHIN connectivity via their EHR/EMR providers.

‍

Could you share a recommended "syllabus" of sorts (including books, newsletters, Coursera, etc.) for going deeper on health data interoperability standards and implications for the future of consumer-oriented care?

Unfortunately, there isn’t much ‘101’ material out there. I’d recommend checking out Carequality’s Implementation Guide and TEFCA’s TEF, QTF, and overview slides!

‍

Can I get copies of the course slides and where can I learn more about interoperability for my organization?

Please email us at go@particlehealth.com to request a copy of the course slides. You can also book an interoperability consultation for your organization by emailing us or submitting our contact form here.

‍

‍

Thanks for tuning into our course with Out-of-Pocket Health! Check out their site for more upcoming courses: www.outofpocket.health/course-library