Back in 2019, the Proposed Interoperability rules were released from ONC and CMS, and the final version of these rules were published in March 2020. While there were some changes implemented based on comments received, largely the new rules kept a lot of the original requirements along with the timelines for implementation. Some of those timelines have been pushed out due to the coronavirus pandemic, but the first payer deadline will be upon the industry before we know it.
Payers have their work cut out for them, although many have hired consultants and partnered with vendors to help implement the first phase of the rule: Patient Access Application Programming Interface (APIs) and Provider Directory. With a relatively short implementation window of January 2021 (with a 6-month grace period on enforcement), that’s not a lot of time to get ready for compliance.
Based on conversations with customers, prospects and industry organizations, there is still ambiguity in the interpretation of the rules, and operational impacts that payers may not be ready to address. Here are five bumps on the road ahead to implementing the CMS Rules, effective Jan. 1, and some ways health plans can mitigate those uncertainties.
Implementation Guides – Still in Flight
Although not required by CMS, use of the referenced Implementation Guides on the CMS web site is encouraged. The challenge here is that some of those implementation guides are still not finalized. For example, the CARIN Blue Button and CPCDS Implementation Guide still needs to reconcile comments to Standard for Trial Use ballots (STU1). Additionally, the HL7 Da Vinci Formulary and Provider Directory implementation guides (IGs) are likewise in the process of final updates. Both CARIN and Da Vinci are moving quickly, but it’s hard to implement when the target may still move. As such, it is critical that payers and their vendor partners participate in these workgroups and follow the updates to make sure that they have the latest technical specifications.
Clinical Data – What Counts
CMS finally has provided guidance on this, and the news is good for payers. Only clinical data elements listed in the United States Core Data for Interoperability (USCDI) that are structured data need to be shared for the Patient Access API. So, USCDI clinical data elements embedded in a fax or PDF don’t need to be shared. For payer-to-payer exchange, if data in a PDF sent to a payer contains USCDI, they do need to send it along to the next payer. Here’s the link to answers to some common questions from CMS:
Despite this reprieve, payers need to be aware they have plenty of structured clinical data that they manage, so locating that data and bringing it all together might be a challenge. Consider sources such as lab data, diagnosis and procedure codes contained in a claim, data entered into a case management system or disease management registry; they will count. Not to mention data that might come in through an Abstract Data Type (ADT) or a Consolidated Clinical Document Architecture (CCDA) directly from a provider. To avoid bumps, payers must ensure they’re working with a vendor that can easily ingest data, no matter what the source format.
Clean Data – Does it Matter What Payers Send to Members?
Not only does it matter what payers share, but also how payers share it. A lot of clinical data captured by a payer is not “clean data”. This means it might not be in the required coding, there may be multiple copies of the same data (i.e. lab results) stored or data might be in the wrong field when ingested. Cleaning that data before sharing it should be a key consideration. If members don’t understand what they are seeing, and can’t make sense of it, then the member service line might be ringing off the hook. The more payers can curate that clinical data, the easier it will be for third party applications to use and display it to members in a meaningful way. Having aggregated, normalized, and deduplicated data is key to enabling the ability to payers pass clean data to an API vendor.
It is important that members know the origin of their data. As part of the new USCDI standard, data provenance needs to be part of the data shared. Similarly, knowing the source of that data could help educate members about who to call when the data doesn’t look right. For example, if a medication that a patient is no longer taking appears in the application, knowing the source of that data can help the member follow up with their provider, not their health plan, to make the correction. Health plans need to make sure that they, or their vendor partners, capture and share the provenance data with the third-party apps. There should also be education on the payers’ website and as part of its member portal that provides clear information on what members should do if their information isn’t correct.
API Application Vendor Vetting
The CARIN Alliance is doing a lot of work to create framework and reference documents that help payers assure that the third-party apps are “vetted” prior to connecting to the payer’s infrastructure. Although a payer cannot deny access to an application, they can make sure that the vendor is who they say they are and that they are handing off credentials to a reputable app vendor. [Editor’s note: The author’s employers is a member of the CARIN Alliance.]
CARIN has also created a Code of Conduct, where app vendors can voluntarily attest to the Code. App vendors that have agreed to the code state that they plan to respect patient privacy and only use the data for member benefit. It’s important for payers to let their members know that third-party apps will not be sharing the data in ways the member didn’t intend (often because of language in the app End User Agreement).
While the new regulations come with many challenges, the end result of improved interoperability and providing members greater access to their health data makes it all worth it. For payers, it’s as important to focus on the operational impacts of the CMS rules as it is on the technology used to comply with them. To do this, payers should continue to monitor both feedback from CMS, chatter from the CARIN Alliance and the HL7 Da Vinci project as well as feedback from customers and prospects. By focusing on these non-technical considerations as they move to implementation, the process will become much more seamless.