Moving Beyond Compliance to API-First Data Governance
Although the Centers for Medicare & Medicaid Services (CMS) has signaled it will delay enforcement, many healthcare organizations, including insurers, face a daunting challenge to meet federal deadlines for the CMS Interoperability and Patient Access final rule, including creating a patient access application programming interface (API).
Aneesh Chopra, president of analytics firm CareJourney and co-chairman of the CARIN Alliance, argues that payers should be thinking about building a data governance strategy so that they are not just complying with the CMS Patient Access Mandate, but actually seeing it as an opportunity to create a strategic advantage and improve member outcomes. “If you are only complying with the rule, you are missing an opportunity to put in place the data governance principles that will drive the successful strategies for your plan for the coming years,” said Chopra, who also served as the first U.S. Chief Technology Officer.
Chopra was speaking during a webinar put on by Onyx Technology, a company that provides interoperability solutions. He noted that many payers are hard at work preparing to comply with these rules. On the plan side, that means building a patient-access API. “I would like to encourage people to establish more of a data governance framework, of which compliance with the rule is simply one item on a menu of items you might contemplate moving forward,” he said. “I refer to this as API-first data governance.”
Today many health plans have business units that connect to clinical information for multiple business cases, such as prior authorization, risk adjustment, quality measurement, and care coordination. To do those things, they are ingesting clinical data.
CMS is putting a stake in the ground by saying clinical data maintained in your systems will be required to be transformed into the the FHIR Release 4 standard, the clinical data standard. Chopra notes that it is a bit funny that the payers are going to be publishing an R4 FHIR server by regulation sooner than the requirement (two years from now) on the provider side. “In a weird way, the newest participant in the API community is going first on the more advanced standard, which I think is fascinating.”
Today there are often data-sharing provisions that highlight the need to share data without getting into the weeds of the how. “My view is that in this CMS rule, by specifying the how —clinical data, FHIR R4 to consumer-designated apps — there is a chance for you to connect that requirement all up and down your supply chain,” Chopra said. “If you contract with a PBM [pharmacy benefits manager], you may demand they provide data in the FHIR R4 format. If you contract with another clinically integrated network, you can ask for application access to the EHR. As the providers move to bulk FHIR, you will have the ability to plug your apps directly on top of that EHR infrastructure. That may be an aspiration over the next two years, but in the interim there is a lot of opportunity for experimentation and creativity.”
If you are interested in this idea of API-first governance, Chopra noted that many payers have the ability to build FHIR applications today because CMS is live not only on their beneficiary-facing FHIR service, Blue Button 2.0, but also with bulk FHIR services. “Some payers sponsor Medicare ACOs. They have a ‘payvider’ relationship," he said. "Every Medicare shared saving ACO today can access a bulk FHIR server to pull CMS claims data exactly in the manner bulk FHIR will allow any stakeholder to participate in two years. About a week and a half ago, CMS announced that every stand-alone prescription drug plans with the click of a button can request Part A and B data to complement their Part D claims, so you can build a much more sophisticated program for medication adherence and care coordination.”
So Chopra’s advice to health plans is that there should be concurrent with the compliance strategy a set of application investments that allow you to ingest FHIR-based data, just as you will be obligated to make it available to third-party apps.
The more you build these applications with a must-share regulatory foundation, the easier it is to understand what the possibilities are and the principles are for improving overall patient care, he said. Here is an example he gave: You will have third-party apps such as Apple Health knocking on your door. “You can encourage them to come to your development portal and onboard them, or you may build your own or partner for a consumer-designated app that you are sponsoring,” he explained. This app would not only pre-configure out of your own patient-access API, but it can connect to any doctor’s EHR in your clinically integrated network. “Even the process of doing the last-mile work of connecting those apps to every doctor’s EHR on your network is itself an opportunity that you want to work on today and that is built on a must-share foundation.”
If you envision a fuller set of use cases now and build the infrastructure, he concluded, you can organize it now for better optionality down the road.
