John Moore III published a post on LinkedIn where he commented on CMS’s moves to modernize the digital health ecosystem. You can find the post here: https://www.linkedin.com/posts/johnmoore3_cms-is-working-to-advance-health-technology-activity-7336779570106310656-N7VE/?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAABGJoB1Za9PMjaa4O61h0nEu4nUfoq4p8
I wanted to comment on his post, but LinkedIn limits the size of a response, hence posting my response here.
National Directory
I am in complete agreement that a National Directory (including endpoints!) is a vital national resource for all healthcare stakeholders. The challenge will be in delivering the directory as a manageable service. It needs to be a dependable source of truth, such that providers, in particular, will be incentivised to keep their data up to date in the directory, rather than having to update 20+ different payers.
Digital Identity
If Medicare adopts a standards-based, portable digital identity that is simply step one. It then needs to encourage the regulated plans and providers to accept portable digital identities. When consumers can create one identity and use it across healthcare it will go a long way to reducing consumer friction.
Digital Insurance Cards
CMS Blue Button should add Digital Insurance Card capability. CARIN has an implementation Guide for that, I know – I helped update the latest version of the guide. While CMS is implementing a Digital Insurance Card for Medicare Fee For Service (FFS), they should loosen the requirement on Medicaid agencies having to ship physical insurance cards to beneficiaries. This can happen multiple times a year as beneficiaries move in and out of Medicaid. Let Medicaid beneficiaries choose to have a digital coverage card on their phone. While going digital could reduce card mailing costs, a digital card could enable agencies to stay connected with Beneficiaries. This could make it easier to perform outreach to confirm eligibility.
CMS Blue Button 2.0
I was involved in building the CMS Blue Button 2.0 API. At the time I advocated against the API providing the claims information from Medicare Advantage plans, primarily because of the delay in receiving claims data from regulated plans. I still maintain that position. This would provide Payers with a reason to opt-out of providing their own Patient Access API, as required under the CMS-9115 Rule. The net effect would be a delay in patient’s being able to access their claims information. Instead, the CMS-0057 Rule requires the gathering of Patient Access API metrics. CMS has said this data won’t be published, bur CMS could choose to publish the Patient Access API endpoint information for each regulated payer. That would go a long way to making it easier to find those APIs and access them. Rather than trying to consolidate information into one central API, let’s make it easier for Medicare beneficiaries to find and connect to the Patient Access API of their Medicare Advantage Plan. This ties back to the importance of a national healthcare directory that enables API endpoint discovery.
FHIR is for Interoperability
CMS needs to double down on the adoption of FHIR standards for Prior Authorization, Provider Access and Payer-to-Payer APIs. However, for these APIs to be effective we need to solve the challenge of registering to access these secure APIs at scale. CMS needs to promote the use of FAST Security’s Unified Data Access Protocol (UDAP) to enable automated secure registration.
And this brings us full circle… Automated registration for secure API access requires an endpoint directory to enable the registration endpoint to be discovered. Being able to find a FHIR endpoint and to then be able to register for secure access immediately and with no manual intervention, then we will have taken enormous steps towards breaking down the major roadblocks to achieving real interoperability.