Some time ago, I wrote a blog post titled "Member as API", an idea that you should own your own healthcare data instead of trying to build complicated integrations and creating large databases with the data of millions of patients, creating a honeypot for hackers. You only need to look at the recent Change Healthcare debacle, where the data of 100 million americans were compromised. Prior to that, was a 78 million record hack at Anthem Inc., the list goes on. With the advent of AI and deep learning using artificial neural networks, the voracious appetite to aggregate data is only going to get worse, in a quest by Big Tech to build bigger and better models. There are a number of ethical issues to be addressed from who owns this data, what about monetary compensation, model data leakage etc.
CMS 9115 The Patient Access Final Rule
What if there is a new way to address this problem? As I noted in my previous blog post, the Interoperability and Patient Access Final Rule of 2021 by CMS mandates that patient be given access to their data via a portal as well as API's that support the HL7 FHIR standards. Here is an extract from CMS recommendations:
"The CMS Interoperability and Patient Access final rule provides app developers with an opportunity to find innovative ways to help patients access their health information and provider directory information."
[A lot of the ideas that I am going to discuss comes from my participation at the Internet Identity Workshop (IIW), where many of the experts in Self-Sovereign Identity, Verifiable Credentials and Personal Data Stores participate. I owe a lot to this group for educating me in these technologies.]
The Health Wallet App
Let me illustrate with an example as to how Alice might take advantage of CMS rule 9115. Alice suffers from chronic conditions, diabetes and heart disease. She routinely sees multiple doctors: a PCP, a Cardiologist and an Endocrinologist. As per CMS 9115, she can now create a profile in each provider's EHR system such that, a third party Health Wallet App can access those systems to download her clinical data. She will of course have to provide the login information to each EHR system to that Health Wallet App (CMS rule requires that the provider EHR system support OAuth for 3rd party apps), but once that is done the Health Wallet App can download her information and store it in her Health Wallet. In a similar fashion, the Health Wallet App can also interact with Alice's Continuous Glucose Monitor (CGM) app as well as her Smartwatch to download that data.
Now the Health Wallet App has all the data about Alice - her medications, her diagnosis, her test results, her CGM glucose data as well as other health data from her smartwatch. Even if a system does not have HL7/FHIR standard support such as in a CGM app or a Smartwatch app, as long as it can be downloaded as a CSV file, the Health Wallet App can cleanse and normalize the data and store it.
Technologies for a Health Wallet
We need to now think about some technologies to create the Health Wallet. The Health Wallet should be under the control of Alice or Alice's delegate; It should be available in the phone as well as have a duplicate copy in the cloud, so that it can facilitate communication with external systems, and it should be discoverable. This idea of Personal Data Stores has been talked about for a long time. The Solid Project has been around since the early days of the internet, and allows for agent controlled access. Ceramic is a decentralized data network and the infrastructure to build personal data stores is provided by Caramic ComposeDB. Similarly Atomic Data and Atomic Server offer similar capabilities. The Decentralized Id Foundation (DIF) hosts a specification called encrypted data vaults which could be used for this purpose.
There are also more traditional approaches using a database such as couchdb and containerization technology. One such approach is Health Information Exchange of ONE, and their project Nosh3, an open source Electronic Health Record that can be used by both a patient and a practice. Adrian Gropper, an active participant at IIW, has been an advocate for patient data sovereignty for many years and is a key contributor to HIE/Nosh3. Nosh3 is a node.js app built using Couchdb/Vue.js and can be easily deployed as a container. Moreover, it is fully FHIR compliant, making it easy to wire it up to EHR systems of providers.
Another technology that has gained a lot of popularity for personal data stores is Decentralized Web Nodes (DWN), incubated by the DIF. Here is a handy companion guide. Here is a good explanation from the companion guide.
Decentralized Web Nodes and KERI
"The DWN specification is designed to enable developers to build decentralized web applications and services that can operate independently of centralized infrastructure. This can help to improve the privacy, security, and resilience of the web, while also promoting greater user control over their data."
DWNs are personal data stores and peer-to-peer communication nodes that serve as the foundation for decentralized apps and protocols. They live on devices and can be replicated on hosted instances in the cloud. These data stores are a realization of true serverless applications in which developers can store app data without using centralized servers or an account with a centralized service. This empowers individuals to gain ownership and control of their data by hosting it themselves on DWNs, decoupled from apps that seek permission to read and access their data.
If Alice the patient wants to send a message to Bob the doctor (both of them running DWN nodes), then the communication happens as described above in the diagram. In this simple example, each actor has a remote (i.e a server) and local node (i.e a phone). Decentralized IDs use traditional public/private key cryptography with the public key (DID) is resolvable using a DID Resolver. The DID Resolver can use a blockchain to store the DID's of each party or it can even be a centralized service such as the Domain Name Service (DNS) coupled with X.509 certificates. The key security concept here is that Alice and Bob exercise control over their DID's because they securely store their private key corresponding to the public DID. This allows them to control the authentication and authorization protocols over the data they have in their respective DWNs.
A recent technology called KERI can be coupled with DWN's for the control of DIDs. KERI is an excellent alternative for decentralized key management, and in my opinion one of the most ingenious recent inventions. I listened to a youtube video of Dr. Sam Smith, the inventor of KERI, where someone asked (I am paraphrasing) "How come something as innovative as this has not been adopted widely?". To this, Dr. Smith replied simply "People don't read anymore - I published this paper many years ago". KERI is a decentralized protocol for the management of persistent self-certifying identifiers, specifically designed for building a decentralized digital identity system. A DID can be considered as a Self-Certifying Identifier (SCID) bound to a single key pair. With KERI, we can use a more robust Autonomic Identifier. It allows for pre-rotation of keys to prevent against accidental loss of private keys and compromise of DIDs. KERI allows us to also be ready to respond to quantum threats to current RSA/Elliptic Curve cryptography thanks to its key rotation feature. We can rotate the keys to use new post quantum cryptography, while still maintaining persistent Autonomic Identifiers (AID). The KERI white paper can be found here. KERI uses an Out-Of-Band Introduction (OOBI) protocol to provide a discovery mechanism that associates a given URI or URL with a given AID (Autonomic IDentifier). Everything in KERI or that depends on KERI is end-verifiable, therefore it has no security dependency nor does it rely on security guarantees that may or may not be provided by web or internet infrastructure. This provides the most secure alternative to centralized public key infrastructure.
Another advantage of KERI is that it support Multi-signatures. Simply put, this means a patient, Alice, can delegate access to her loved ones who will be able to access Alice's data in a DWN.
Verifiable Credentials and ZKP
DWN's can also be used to store Verifiable Credentials, such as medications, vaccine credentials and other such sensitive medical data that requires certification by an authority such as a doctor or a hospital. Verifiable Credentials are digitally signed documents that can be verified by a Verifier without having to "phone home" to the issuer of the credential. Verifiable Credentials, when combined with Zero Knowledge Proofs allows Alice to selectively disclose facts about her health, supporting the concept of data minimization.
Personal Health Data Uses
Now what can we do with the data that Alice has in her DWN?
Analytics applications can be written which will allow Alice to access her Health Wallet from her mobile and display clinical data, prescriptions, test results as well as trends to a doctor or healthcare professional.
A Natural Language Processing interface can be provided so that the data can be surfaced with spoken queries. "Wallet, can you show me a graph of the last 2 weeks of Alice's blood sugar levels?". "Wallet, can you tell me what is the time of day that her sugar levels tend to peak or go very low?". "Can you plot the HBA1C values of Alice over the last 2 years?".
Data is the new oil (You thought I was not going to get to it ? Here it is finally!), so if Machine Learning models need data, we can now provide them from Alice's DWN, maybe even be compensated for it?
Federated Learning with Differential Privacy
Using Federated Learning with Differential Privacy, it is possible to build ML models for healthcare use cases using data from the Health Wallets of patients like Alice. It will not only secure the models from leaking patient data, it is also possible to fine tune the model for Alice with her local data. Google's Gboard is a great example of how you can offer a personalized ML model while ensuring data privacy. The GIF animation above illustrates this technique.
Tensorflow Federated from Google is an open-source framework for machine learning and other computations on decentralized data. These frameworks can be used to ensure patient privacy without having the need to build giant data lakes of patient health data.
One could even think about using this patient data as a source of Universal Basic Income. For providing your data (using differential privacy or homomorphic encryption the data will be protected) you may be compensated with fiat or crypto. This allows Big Tech to still thrive, except now they have to provide just compensation in order to satisfy their voracious appetite for data!
Federated learning can utilize idle compute power in a phone or a small cloud container owned by the patient - When aggregated over 100's and 1000's of patients, it is an effective and efficient way to build models for healthcare as opposed to having massive central infrastructure to do the same. Only the very large LLMs consuming everything on the internet need the massive compute capabilities, the GPUs and the power to build their models. For most healthcare use cases, a smaller subset of carefully curated clinical data is all that is needed to build the models. Edge computing devices such as cell phones and IOT devices are capable of providing the power to work on data where it is created or gathered on an individual basis. One could even think about a small, inexpensive health device for an individual or a family that can act as a digital locker and edge compute device.
The Law
What about the legal landscape around this topic? we need some enlightened laws including modifications to the law of torts, which endows a person's health data with some rights. In their 1890 article, The Right to Privacy, Samuel Warren and Louis Brandeis argued that the common law should protect citizens from the unauthorized publication of their personal information. They called this protection the "right to privacy" and described it as the right "to be let alone". Their article was a response to technological developments like instant photography and audio recordings.
Warren and Brandeis's article had a major impact on the development of the common law. It led most states to recognize the right to recover damages for the wrongful public exposure of private information. The article's central thrust was to separate privacy from property, and it influenced courts to take cognizance of injuries even when no property or contract rights were involved.
I am not well versed in public policy or law, but I hope researchers in those areas take up this call to action. It is time to revisit Warren and Brandeis in the age of AI and enact some meaningful protections. This change, when coupled with CMS-9115 can go a long way in providing patients with better healthcare as well as a modicum of control and agency over their health data.
India's Digilocker
As a final thought, maybe this idea of building a digital locker makes most sense for people who are typically outside the normal, insured route. I am now working on a project for providing healthcare discounts to the uninsured (not in the United States). People who are uninsured also have to get healthcare and when they do, there is absolutely no opportunity for them to have a history of their diagnosis and medication. Refugees for example, fall into this category. If we can build a way for them to take at least a minimal amount of data with them, it would be of great value when they go back to another provider to seek help. This is especially true for those with chronic conditions like diabetes, high blood pressure and heart disease. Almost counter intuitively, with a little help from NGOs or governments, we could provide the digital infrastructure to allow them to do the same. This is not an entirely crazy idea - India for example, provisions a digilocker for every citizen. While its architecture may be more centralized, the core idea of providing such a service to a billion people is certainly inspiring.
Comments