The 21st Century Cures Act was signed in 2016 and covers various components of healthcare, including modernizing the FDA approval process. Another part of the law deals with interoperability.

While HIPAA was designed to safeguard data, the portability component of the HIPAA mandate became a huge issue. There was no standardized format or means to make moving data from one place to another possible, and data holders like EHR vendors believed they owned patient data.

With the 21st Century Cures Act, policymakers now have said no; health data belongs to individuals, and there needs to be an easy means for them to access it.

The Cures Act sought to make some fundamental rules around this for interoperability. Lawmakers thought there needed to be a very specific, well-articulated means by which data is moved from where it is held to where it needs to go.

The Interoperability and Patient Access final rule (CMS-9115-F), which came out in 2020, articulated the roadmap and data standards. The Cures Act includes provisions related to the information blocking rule, which relates more to providers and their IT vendors – for example, EHR vendors. These two rules have laid the groundwork for how interoperability is expected to look.

Jonathan Shannon is an expert in these laws and rules. He is senior director of healthcare strategy at LexisNexis Risk Solutions. We sat down with him to discuss the consumer application programming interfaces rule of the Cures Act and the need for interoperability without compromising data security.

Q. Please describe the consumer app API rule section of the Cures Act, and explain its goals.

A. When you think about who is using APIs, one example that many people relate to is customers of banks and financial services institutions accessing data from other entities to create a consolidated view of their financial profile. Using software that interfaces with their database, APIs make a connection.

This is game-changing for healthcare, where APIs are becoming more prevalent. Previously, interoperability could mean chart chasing by a nurse who would physically find the chart, digitize it and send the info to whoever needed it, an incredibly arduous and expensive process. API technology enables the querying of a database much more quickly.

The second thing to come out of this was the standards. HL7 came out with 4.0, called FHIR, which was also game-changing in terms of being able to get data in a standardized way. This is what we expect you to have; this is how we want the data to be organized and what we accept. This delivers a much easier ingestion capability which you can do through the machine, AI or machine learning, giving you a fundamental lift from the data.

Finally, there are now expectations around the completeness of the data and what kind of data needs to be available. The FHIR standard is critical, but health plans must make six years of claims available, presenting the clinical information they have on each patient.

Payers have to be fully open, saying, "This is all we have on you, this is what we've been collecting, and this is how we view you," and allow patients to share this with whomever they choose.

These mandates have created an opportunity to increase the speed of delivery via API, convert the data into digestible information by FHIR standards, and create a holistic patient profile due to the data that needs to be available.

Years ago, patients often felt they were not considered integral to decision making related to their care. Today, these mandates insert patients directly into it: It's their health, it's their data, and they have the right to do what they want with it, sharing it with wellness apps, providers, other health plans, really anyone an individual believes can support their healthcare journey.

Q. Regarding patient data access, how is the deployment of APIs going?

A. Under HIPAA, there has been this idea of provider-driven continuity of healthcare. For instance, when interacting with passive patients, a provider may say, "Can I share your data with a provider?" or "Can I request your data from another physician?" People respond "sure" because it is easy. They have come to rely on that without knowing about credentials or releases or anything operational about access.

The first part of this law required health plans to go live with these APIs in July of 2021. However, for some health plans, their APIs are difficult to find. You can search "health plan XYZ patient access API" with no results. Even if an app developer can connect to it, registering and facilitating data exchange can be challenging, requiring a lot of special effort for all parties.

The rulemaking, in fact, noted that this was to occur "without special effort." As you think about the amount of resources provider organizations have to chase down data, it is incredibly limited. Their core competency is treating, diagnosing and engaging with patients, not handling IT issues. Interoperability was supposed to be easy, but we are not there yet.

There is undoubtedly a role for enforcement and better articulation of understanding, not just the letter of the law but the spirit of the law.

Q. How does this rule impact payers?

A. It has had an enormous impact. I do not envy health plan CTOs and the amount of work they have to do related to making themselves "Interoperability Ready." After the March 2020 rulemaking, they had to orchestrate all this data based on the rules in about 18 months.

Luckily, payers have pretty savvy IT personnel who sprinted to get it done or engaged with third-party firms to support their efforts. However, some have struggled to respond to a law given the fact it was a massive undertaking.

Not only did they have to build an API, they also had to orchestrate all the data from all their different systems – claims, marketing, clinical and care management – so the longitudinal data is available when a patient requests it, all in FHIR format and available by API.

Payers also had to beef up security to account for people requesting data that would go outside their four walls. The Cures Act essentially established that once this occurs, HIPAA no longer applies but rather it's an FTC issue and the apps' responsibility to safeguard that data.

But you can imagine that a large health plan would not want its data compromised. This is friction on top of the robust data demands, compliance concerns and pandemic challenges. Logistical and technical challenges have proven too much for some payers, while others have done an outstanding job.

Q. How do we address the need for interoperability without compromising data security?

A. I think it is a carrot/stick situation. First, you must celebrate the people doing a good job. CMS and ONC can say publicly, "Great job, XYZ plan! This is what interoperability should look like." On the flip side, numerous health plans are not meeting the letter of the law or the spirit of the law.

The governing bodies must enforce this if they believe this is the future. There needs to be monetary and reputational harm to organizations not embracing this.

This was one of the most bipartisan bills ever passed. The data sharing provisions are vital: putting more power in the hands of the consumer. Suppose that happens at the stakeholder level – the health plans, the EHR vendors – where it is obvious that CMS is serious. In that case, you will start to see consumerism pick up as these technologies become available.

We also will see more precise definitions of what it looks like to be a good app and how to enforce data security more effectively. Traditional healthcare players (for example, health plans, providers) all understand HIPAA, but what does an app developer working in his basement do with all this sensitive data? What does this world look like?

There needs to be more transparency in terms of data security expectations. Once we understand the technology and consumer rights better, we will trust the technology and what the data can do.

Twitter: @SiwickiHealthIT
Email the writer: bsiwicki@himss.org
Healthcare IT News is a HIMSS Media publication.