Aneesh Chopra on the Evolution Toward a ‘Must Share’ Interoperability Framework

The answer to interoperability from a policy perspective, in my view, [has been] staring us in the face since the origins of HIPAA. It's imagining that technical, political, and operational fork in the road. HIPAA had two provisions: the first is the path of HIPAA-covered minimum data necessary B2B transaction governance, which is 99.9 percent of where all the tech, operations and policy had been for the last 20 years.

So that's one fork, and the other in HIPAA was the patient's right of access, which would have taken the data at permission request out of the HIPAA-covered framework and into their own possession. And as we know, broadly speaking, in their own possession is either unregulated if it's a printed copy, or if it’s a shared through a digital service, like a consumer internet service, then it's subject to FTC traditional internet-based regulations. So that fork in the road, policy-wise, was actually created in HIPAA, and what had been missing over the years was the policy, technology, and operational focus on establishing the mechanisms by which that that fork in the road works. That's where we are today.

We've spent the last three to five years building up the technical, governance, and operational muscles for how to exercise your right of access in the digital era. And thankfully, we have a fairly clear runway for health plans, health systems and physician practices to turn on this capability on a common standard over the next 12 to 24 months. So that's the part that's exciting for me. In some degree, it’s taking a step back and asking ourselves, how much do we want to fix the “may share” world? You'll see improvement there with TEFCA as that proceeds, but it also is about how to move the “must share” framework? And by the way, we've introduced a third option, which is the FHIR-based framework for B2B applications.

What’s your view of the final interoperability/patient access regulations? What are some things you’re hearing on the ground in terms of stakeholder challenges?

Chopra: The U.S. has a very specific policy framework for standards regulation. In the U.S., the government may only regulate standards that have met industry consensus. So, among the frustrations, if you were taking my job as U.S. CTO, you would take a look at the industries that that need standardization in terms of consumer access to data. You would look at the energy sector and ask, how easy is it to get your real-time, energy data from a smart meter that's been installed in your home? The technology standards for that were largely agreed upon by the smart meter manufacturers a decade ago. There wasn't the concept of information blocking, per se. So we've had light-touch regulation and largely industry consensus on standards development and deployment. Ditto for the banking sector. If you wanted a standard to access to your checking account information through a third-party app like PayPal, there's been largely industry consensus. There's been a regulatory path, in the sense that Congress gave the government the ability to regulate, but note in the decades since we've been thinking about Fintech, utility access and healthcare access, the only industry that did not self-organize to make this process work better for consumers has been healthcare. It is a stain on the industry's failure to self-organize.

So the CARIN Alliance was an attempt to accelerate industry consensus through forming a coalition of the willing. Unlike a traditional standards body—we have had HL7 for a generation, and it works well and we love it, but it only does the job its members ask it to do. The membership at HL7 candidly had not been prioritizing consumer API access over and above other priorities. Like any standards body, it does the work that its membership wants to do. So we created a standards accelerator before that was an official term, and said that we need to get a group of folks from the tech community, the patient advocacy community, the payers the providers, cloud platforms, big tech, etc., and let's put everybody in a room and let's try to build consensus.

In the beginning, it was [about] taking the nascent technical standards from the Argonaut Project and testing out if they work, [while] solving for the operations, the policy and everything else. As the policy debate shifted towards health plans, and Medicare as a leader unto itself launching Blue Button 2.0 by itself in the plan community, we took the reins on filling a gap in the standards process where there really hadn't been a claims equivalent of what was going on in the Argonaut Project. Fast forward, the CARIN Alliance today has, I believe, successfully forged a multi-stakeholder, standards consensus process that runs the gamut of technology, governance, and operations, so we can move much faster together. And buoyed by regulations that set firm deadlines, we've had a great deal of energetic and enthusiastic industry participation. So, this has been an example of a public-private collaboration that strengthens interoperability, on the consumer “must share” foundation that's been the bedrock of HIPAA since its founding.

Johnson: The blessing and the curse of the FHIR data object model is that it’s heavily extensible and very highly customizable in how you can use it. As is true of pretty much most things in life, the devil is in the details [for] exactly how you look to implement that particular data object model for the business use case you're looking to solve. I think that’s where CARIN has shined; getting together the community stakeholders that are required to look at the business or consumer use cases, and what we’re looking to do as an ecosystem as a whole, for exactly how we are going to implement this FHIR standard. That’s where the value of CARIN lies—let's take this from ideological conversations down to brass tacks on how we actually implement this.

How to you view the app marketplace right now as developers look to demonstrate their APIs?

Chopra: Up until this point, the business model for consumer-mediated data sharing has largely been the cost of doing busines: you embed this in the cost of your portal, or maybe it’s a feature you extend. Maybe you think about value-added services like scheduling and other consumer conveniences, but by and large, they have been seen more as a compliance exercise than a core business proposition. I think two external factors have fundamentally changed that equation. And by luck, they have coincided with the regulatory requirements to be compliant. If you take a step back and look at the fuller picture, it is very clear; if you wanted an easy bet on the roulette wheel, you would bet that the quality of consumer-oriented data aggregation service apps will skyrocket.  There have been two [driving] forces for this. The first is the pandemic, and the demand signal for digital-first access that has awoken the traditional provider market.

I would argue that the other regulatory force—the value-based care and price transparency rules—may actually have a much stronger demand signal for higher-quality apps than complying with interoperability regulations. We’re about to move to the most ambitious capitation experiment in public-sector healthcare, which is the Medicare Direct Contracting program. This essentially allows a doctor to take upside-downside risk on 95 percent of the capitated premium for a Medicare patient. One of the most powerful use cases in that model is called voluntary alignment, where a doctor can recruit a brand-new patient that has not been in their practice before, and in effectively a digital DocuSign experience, can associate that new patient to the practice—not just for the office visit revenue, but the entire 95 percent of capitated premium risk. So, that idea of digital voluntary alignment is going to put another demand signal onto the higher-quality apps.

And if you take a look at the price transparency rule, CMS also put its thumb on the scale. If you gave consumers a discount, or a bonus—whatever the term is for choosing a higher-value, lower-cost provider for clinically comparable services—that discount is treated like a medical service; it is within the medical loss ratio (MLR). So from Jan. 1, 2021 onward, digital platforms will administer discounts for routing patients to higher-value doctors, imaging centers, and the like.

Related to the pandemic, what are some other ways that the public health informatics infrastructure has been shortchanged? How could the Biden administration could fill these gaps?

Chopra: We commingle a lot of comments around public health, and we need to peel the onion back to truly diagnose the problem. We built public health interoperability on the foundation of point-to-point HL7 interfaces—not migrating towards application access through the FHIR-based API infrastructure. The 21^st Century Cures Act in 2016 declared APIs, or application access to clinical data, will be the regulated default mechanism for data sharing. On that day, anyone that had a clinical application that was tethered to traditional HL7 interfaces should have started a project on what the modernization roadmap would look like to shift towards application access. This is because public health doesn't need a different version of the lab result; they need the same version of the lab result that goes to b.well [for instance]. The issue is application access; the way they were getting the lab result was through the HL7 V2 messaging framework, and thus a different data supply than what we were building on the regulated “must share” foundation infrastructure.

So really, the public health modernization problem dates back to 2016, and whether or not any partner in the public health IT infrastructure adopted the same roadmap to APIs as everyone else did. Sadly, I think we missed public health’s transition to APIs. We are trying to quickly close that gap. The CDC launched the native Smart on FHIR app called ECR [electronic case reporting] Now, but it was sort of jammed in there in the last few months, making it hard to gauge if it’s going to have an effect.

So, what do I expect to happen? Remember, in the Cures Act ONC regulations, not only have we regulated consumer API access, but we've introduced this idea of bulk FHIR for B2B exchange. Bulk FHIR will be delivered by December 2022, and we may get lucky with some folks shifting even earlier. So the number-one expectation I have for public health is that it will build bulk FHIR applications to ride the regulated rails that will ship over the next two years. That’s a guarantee, regardless of whether the Biden administration shifts course or continues on the current path of whatever the [current] CDC is doing. On this issue, it is bipartisan and unequivocal—build on the “must share” FHIR API rails, and in this case, the bulk FHIR rails which are designed for B2B.