"Member as API" - The Interoperability and Patient Access final rule and Verifiable Credentials
Updated: Jul 27, 2021
The Interoperability and Patient Access final rule (CMS-9115-F) delivers on the government's promise to put patients first, giving them access to their health information when they need it most and in a way they can best use it. As part of the MyHealthEData initiative, this final rule is focused on driving interoperability and patient access to health information by liberating patient data using CMS authority to regulate Medicare Advantage (MA), Medicaid, CHIP, and Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs). The deadline is now July 1st, 2021 which is already here!
Before I explain further, I want to acknowledge two sources for inspiring some of the ideas in this article - The first one is a blog by Andy Tobin of Evernym, titled "Your User Is Your API".
and the second one is a vlog "Zengo - The Keyless Crypto Wallet" by Omer Shlomovits & Ouriel Ohayon, the founders of Zengo Wallet.
A key part of CMS-9115-F is for Payers (such as HMO's and Health Insurance companies) to make available the "Patient Access API" such that they are "... required to implement and maintain a secure, standards-based (HL7 FHIR Release 4.0.1) API that allows patients to easily access their claims and encounter information, including cost, as well as a defined sub-set of their clinical information through third-party applications of their choice. Claims data, used in conjunction with clinical data, can offer a broader and more holistic understanding of an individual’s interactions with the healthcare system, leading to better decision-making and better health outcomes".
It makes a lot of sense that Patients should be given access to their health data. The idea is, the patient should be able to hold and carry this data to a provider (a doctor's office or clinic) so that the provider has accurate and holistic picture of the patient's clinical history, procedures and medications. As a matter of fact, another part of this rule called "Payer to Payer Data Exchange" stipulates "..CMS-regulated payers are required to exchange certain patient clinical data (specifically the U.S. Core Data for Interoperability (USCDI) version 1 data set) at the patient’s request, allowing the patient to take their information with them as they move from payer to payer over time to help create a cumulative health record with their current payer. Having a patient’s health information in one place will facilitate informed decision-making, efficient care, and ultimately can lead to better health outcomes. These payers are required to implement a process for this data exchange beginning January 1, 2022".
HL7 FHIR standards certainly make it easier for EHR systems operated by Payers and Providers to communicate, but what we do not want is an ever increasing mesh of federations to exchange a patients data with multiple systems. As a patient goes through multiple Payers and Providers this becomes a nightmare!
This is where the W3 Verifiable Credentials standard comes in - Instead of doing these point to point integrations, why not allow the Patient to carry their health data such as the elements specified in USCDI, as a Verifiable Credential ?
Patient Data Access
Here is the flow that would make this easy - A Patient logs into a Member Portal via a mobile app that retrieves Member clinical information using FHIR standards. This is the step that exploits the "Patient Access API" to retrieve the member information.
Imagine now that with the click of a button, the member is able to choose the items s/he
wishes to save to the "wallet" in the mobile App. For example, a FHIR bundle that contains the procedures that a patient has undergone would be a good one to save, if the patient is planning to visit with another provider (say a specialist) it makes a lot of sense that they carry the details of the procedures that they can share securely with the new provider. This is where the "Member as API" (to paraphrase what Andy Tobin from Evernym had written in his blog) concept comes in. The Patient/Member is the one that should be carrying the data from provider to provider and from payer to payer.
When patient information is stored in the mobile "Wallet", it is stored as a Verifiable Credential conforming to the Verifiable Credential W3C standard. A patient/member can present this credential as a QR code to a provider. A piece of software can read and verify the QR code and extract the credential details.
A more sophisticated technique, when the payload of data cannot fit into a single QR code would be to use the DID COMM protocol to extract one or more verifiable credentials from the mobile wallet. A piece of software can verify that these digital credentials have not been tampered with by using the public key of the issuer of the credential. For details of one such implementation, check out :
Once data is extracted, then the patient information can be converted into a FHIR bundle and it can be used to update the Patient's record in the destination provider's EHR. This is in line with the spirit of what the Interoperability and Patient Final Rule is trying to achieve.
Digital Wallets - Where are they headed ?
For this idea to take off, I really see some key advancements in technology that is happening today to take hold. This is where my reference to ZenGo and their podcast referenced above comes in. Let us face it, today, digital wallets are cumbersome to use when it comes to storage, backup and recovery. Most of the experience we have today is with Crypto Wallets where losing the private key is the end of story - or the alternative, having a cloud based custodian of your private key comes with all the attendant hacking risk. This is where, advancements in digital wallet technology being pioneered by companies like ZenGo is going to help, with Threshold Signatures, Homomorphic Encryption and Multi Party Computation making it possible to have a Keyless wallet that is secure and easy to use. I see the same technology helping us to get Health Credentials into the hands of patients.
I see a world of specialized devices emerging which will act as our digital wallet. You should be able to enable secure access to your health wallet using threshold signatures so that a provider's EHR can get access to the data you wish to share through these digital wallets. These specialized devices / cloud based wallets should be able to hold an enormous amount of patient information including scans, X-rays and other clinical information.
Computing with Edge Devices
We can foresee a world where Patient data should securely reside in these digital wallets which will act as edge devices. If a provider needs access to your data they will seek your permission and software agents will act on the data directly on these wallets whether it be an AI algorithm predicting your health outcome or a diabetes monitoring software that wants to look at your blood sugar history. These digital wallets can securely store data from the growing list of personal health devices such as continuous glucose monitors and the Apple watch with its inbuilt EKG and other health monitors. We really need to move away from a world of centralized data stores and moved to truly distributed data architectures. Techniques such as homomorphic encryption and zero knowledge proofs allow us to only share the information that is minimally needed while safely encrypting and securing your personal health data.
Where do we start ?
With Pravici PocketCred (https://www.pocketcred.com/),we are taking the first baby steps in this direction. We have the ability now to retrieve a patient's immunization, medication or procedure record and save it securely in a mobile application as a verifiable credential. On the flip side, we can present the credential as a QR code and a piece of software can not only verify the QR code presented but can also take the data presented and make it available as a FHIR bundle that an EHR system can consume. Let us start there on our journey to make patient data secure and portable.