Part 1: Overview
A great deal has changed since the July 1st 21st Century Cures patient access deadline, but before we talk about what's occurred and what's to come, let's start with a brief refresher on the Cures Act itself.
Patients and physicians alike shared numerous personal examples in several forums about frustrating experiences that included repeated medical tests and/or procedures to satisfy insurance requirements or simply to have access to the results. The Cures Act was signed in 2016 and included several provisions to improve patients' access to their own medical data, addressed specifically by section 4003 pertaining to interoperability. The rules impacted members enrolled in Medicare, Medicaid, CHIP or qualified health plans (QHPs) on the exchange.
The Office of the National Coordinator for Health Information Technology (ONC) had been tasked with defining rules and standards for how the 21st Century Cares Act will operate. The ONC released their final rule in March of 2020, publishing approximately 60 days later in May, starting the clock on the implementation and enforcement of the interoperability rules.
One key aspect of the rule impacting payers was the need to make the healthcare data captured available to the members on demand through a third-party application chosen by the member. The data needed to be exchanged using a new code standard called the United States Core Data for Interoperability (USCDI), and it had to be used through an Application Programming Interface (API) using the HL7 Fast Healthcare Interoperability Resources (FHIR) format.
Payers needed to include both medical and clinical datasets based on their relationship with the member, beginning with data from as early as January 2016. Since the rules were announced, many payers have gone through the exercise of reading the new regulations and reviewing the new code sets and the exchange parameters that are required. Some have elected to purchase solutions available in the marketplace, while others have made internal investments and developed their own APIs.
Regardless of the path chosen, all payers with impacted memberships began the process of identifying and mapping their data to the new USCDI data standard. Originally, the Cures Act had expected live enforcement in January of 2020, but in light of the COVID-19 pandemic, the enforcement date was shifted to July 1st to allow more time for payers to meet the requirement.
The July 1st deadline involved four main components within the Cures Act with impacts for payers.
The first two were APIs: the Provider Directory API and the Patient Access API, both of which represent the largest technical challenge for payers. Next were a series of mandated documents or communications. Finally, there were business operational impacts required to be addressed.
The purpose of the Provider Directory API is to provide the public with access to current and accurate directory information. The availability of provider data through the API is intended to enable third-party applications to access the information they may need to help their users find providers as well as help other providers better coordinate care for their patients. Key elements required in the directory include (but are not limited to), the provider specialty, practice address, office hours, languages spoken, contact numbers, network participation and whether they're accepting new patients. If the API is provided and maintained by the payer, they must also expose any electronic endpoints for communication specifically as it relates to the new interoperability transactions.
Many payers have grappled with maintaining the timeliness and accuracy of their Provider Directory. Once the Provider Directory API is operational, it's incumbent on the payer to ensure that any new provider additions or changes to any of the required data elements be made within 30 days of the change. As with all technology, routine testing of the API needs to be conducted regularly to ensure compliance with the rule.
The Patient Access API is the main vehicle for a member to gain access to the clinical and claim data as well as information on formulary medications. The Cures Act requires the Patient Access API be made available to members with coverage through Medicaid, CHIP, Medicare Advantage and qualified health plans through the government's health exchange.
The spirit of the rule per the ONC is to enable this capability for all members. Each payer can choose if they want to extend the features of the API to their broader population of members, but they are not required to do so. The Patient Access API represents the gateway to interoperability for the payer. The API serves as the front line to validate the member, their data access request, and to allow the payer to securely communicate with the member via the selected third-party app.
Per the Cures Act, payers are required to provide all claims and clinical data within one day of having the information available in their systems. Once again, this includes all claims data with dates of service from January 1st, 2016 and onward, provided the member is active with the plan and enrolled in an eligible line of business during that time. The same holds true for care management data — it has to be mapped to USCDI and sent via the HL7 FHIR transaction through the API.
The ruling states that there are documents expected to be published on the payer website to help both the third-party developers and members navigate through the new functionality. Some documents are required while other forms of communication are left at the discretion of the payer. The expectation is payers are required to provide clear instructions and support for both the developers and members.
Part 2: What we've seen
What was important to consider before July 1st were the operational impacts to the payers.
From consent management to the deployment of APIs, the introduction of HL7 FHIR through the mapping of data elements to the USCDI and other data standards focused mainly on the technological impacts of the regulation. Before going live, the payer needed to review the impacts to the varying operational teams that would support interoperability. While implementation teams had been living interoperability for months, operational teams had been focused on business as usual.
What they need to consider now is defining processes and writing scripts to support questions from third-party app developers or from members who might have issues with the data returned in their app. Within provider operations, teams have to be prepared to support everything from updates to practitioner demographics and network contracts to onboarding new providers and re-credentialing functions. They are now facing a clock with tighter turnaround expectations — 30 days for provider updates to make their way through the system and ultimately to the provider directory.
What we've seen since the July 1st deadline passed is that while payers have implemented the technology as required by the Cures Act, there is almost no usage across the payer industry.
One of the biggest struggles for broad solution utilization may be while insurers are aware of the regulations, they are currently limited in scope to Medicare, Medicaid, and qualified health care plans populations. As such, there's been very little commercial coverage communication or direct to member engagement from the health plans — or any other constituency for that matter — to promote third-party applications or interoperability data requests. Postings and notifications were placed on the payer websites as required, but they've done little to proactively engage their members toward accessing their member healthcare data.
This phenomenon points back to the lack of focus on the operational impacts of the Cures Act. As mentioned, there is much preparation needed to handle the questions and support that are required for members to have access to their information on demand. Information should flow out to the member, as per the rules, at great investment from payers, some who might be challenged to see the value in that investment. However, that viewpoint might change as May 1st, 2022, approaches, when the payer-to-payer (P2P) phase of the Cures Act is set to begin enforcement.
Part 3: Where we're headed
Both education and encouragement are needed for member adoption and to realize the potential of interoperability. As such, there are a few similarities between the patient access component and the P2P transactions component of the rule. Both are member-initiated transactions and both use the USCDI v.1 as the base sets for exchanging data. Both apply to data from as early as 2016, and they also share the requirements to support members in Medicare, Medicaid and QHPs.
However, that is where the similarities end. The patient access rule requires both clinical and claims data while the P2P data set only includes clinical data for the time being. Additionally, the patient access rule impacts only the member's current payer, whereas the P2P transactions target previous payers from the 2016 period moving forward.
Unlike the patient access rules, the ONC has been more ambiguous about how the P2P transactions will flow. What is clear is that the initial transaction will need to be a member-initiated request to the former payer to release their clinical data to their current payer.
Once initiated, the former payer will need to identify and validate their former member. New webpages may have to be created to capture the sign-on credentials of their former members as many systems don't enable their inactive members to access information from their sites. This may ultimately lead to an increase in customer service calls from members making these requests.
Once the former member has been identified and their current health plan has been confirmed, the member's data will be packaged and transmitted. Not wanting to create a burden on the former payers, the requested data is NOT required to be sent using HL7 FHIR transactions; it can be sent in any electronic format provided the data has been formatted into USCDI v.1 data.
When the ONC wrote their initial rules, they included the exchange framework and common agreement (TEFCA), which they had envisioned as the primary method of healthcare data exchange among stakeholders. This rollout was delayed, however, and the final rules for the technical framework are still being completed by ONC.
The ONC FAQs page recently posted that the P2P transaction standards will not be enforced until more details are finalized. As the industry awaits the finalization of the P2P interoperability rules, ONC is recommending the use of the CARIN Blue Button 2.0 standards for payer data exchange. More information on these standards is available here.
As a result of this delay, there are many acceptable methods payers can use to transmit member data. Once the current payer receives the member data, they must use member matching criteria to find the owner of the data and validate it. The payer can then use this data to help supplement — and in some cases, augment — the member's records.
P2P offers a proactive opportunity to engage in improved member healthcare as P2P brings together past and current member health data. Before the first claim is ever received, the payer has an opportunity to review data from a previous health plan that may identify an opportunity for the participation in a disease management or other health program, or at a minimum, address an earlier intervention. Even members that have had a relationship with a payer for a few years could see a benefit from having their prior information available to their current payer.
That said, it is important to remember there will be challenges and probable changes as new rules are being finalized. An infrastructure needed to support P2P transactions, but payers can leverage what was used in the patient access phase. Strategic messaging and communication will have a role in creating a return on the interoperability investment as driving members or stakeholders in their health is paramount to the success of interoperability. Payers along with care providers will need to play a larger role in helping members learn how to steward their own data.
What's next?
The availability of data can lead to quicker access to care, decrease its' overall cost, and ultimately improve the quality of care. Reaching this goal requires active participation in and the embrace of interoperability. We are just at the beginning of this journey, and over the next three years, we will see an expansion of interoperable health in a way that engages the member, the payer and the provider to change the way we interact with one another.
After investing considerable time and resources in building technical system level interoperability, is it worth considering expansion of the solution to all members? While not required in the regulation, once commercial members understand the opportunities inherent in having access to their data, we believe they will ask for it and expect it to be shared.
While those expectations might seem initially cumbersome, you don't have to tread those waters alone. Many solutions are available in the marketplace that can help payers meet the minimum compliance requirements. IQVIA Professional Service Teams can support your interoperability implementations now and into the future and will help you handle last-minute changes as rules are finalized.
Regardless of your approach to date, you can leverage technology and data to help shape the healthcare of tomorrow. Contact IQVIA today to learn more.