What is Plaid?
If you have used a personal finance app in the last 15 years (like Robinhood, Personal Capital, Mint, Betterment, YNAB, SpendAbility … there are dozens of them), you have interacted with a service like Plaid.
Plaid gathers (from you) log-in credentials to your banking, credit card and brokerage accounts, then uses those credentials on your behalf for (read-only) access to those accounts when the associated financial app retrieves your financial records to build a consolidated view of your money, investing and spending. Tens of millions of people trust this mechanism to provide these apps access to their sensitive financial information, and it works pretty well. (But still: Another copy of our log-in credentials is out there. This does create some risk.)
Wait! What about APIs?
That’s a very good question. APIs (application programming interfaces) are used by millions of apps and systems (large and small) to talk to each other. Using APIs to share private information (like financial or health data) includes lots of security measures (like the SSL certificate mechanism our browsers use when we are logged into our bank or healthcare portal), so they are pretty safe. Given this, questioning why our financial apps don’t use APIs to consolidate our financial records is logical.
The answer is that (unlike in Europe, where banks have recently started allowing app access via secure APIs), U.S. financial institutions refuse to permit access to our accounts by any method other than our log-in credentials. From my experience in financial services, I know that financial institutions are understandably concerned about their liability when our financial information is compromised (like fraudulent charges on a credit card), and they are absolutely terrified of headline risk: “Another data breach by Bank of the Worst affects millions.”
But the reality is that millions of consumers use financial apps, and those apps need access to our financial data, so firms like Plaid stepped in to fill that need.
U.S. Banks’ refusal to allow access to our financial data via secure APIs has created a big business for firms like Plaid, who provide that API to our financial apps–and increase our risk in the process.
Hint to Healthcare: Banks are NOT the Model
As the US healthcare system grapples with how best to provide patients unfettered access to our medical records, EHR vendors are taking a page right out of the legacy banking playbook by refusing to grant our consumer healthcare apps access to our medical records by any other means than using our log-in credentials. This is especially ironic, because healthcare interoperability infrastructure is designed around (wait for it … ) highly secure APIs.
On the surface, EHR vendor logic is similar to that used by legacy banks: “If we disclose information to the wrong party, we have liability.” However, EHR vendors have that same liability when disclosing our healthcare information via API to something other than a patient app (which they do thousands of times each day), so this “avoiding liability” argument quickly loses credibility.
Financial services (banks, credit card companies, investment firms, etc.) are a big part of the economy, but they are dwarfed by Healthcare. It’s a pretty safe bet that at least as many consumers will embrace patient-facing apps for access to their medical records as the number of consumers who have embraced financial apps for access to their financial records.
Make no mistake: Someone (maybe Plaid) will create “Plaid for Healthcare” unless EHR vendors embrace using existing healthcare APIs to provide patient access.
The Information Blocking Freight Train
That it took congressional action to get us to the point where EHR vendors are now scrambling to make our own health records available to us is fodder for a Ph.D. dissertation. To summarize, the “teeth” behind this legislation (and accompanying rule-making by ONC and CMS) is liability for “information blocking” when a healthcare organization refuses to provide this access.
EHR vendors are blithely assuming that this liability is exclusively their customers’. There is a saying about “assume,” and it rings true in this situation.
The smart bet for EHR vendors is to avoid the inevitable Information Blocking headlines and litigation by providing patient apps the same level of access via secure API as is already provided to non-patient destinations.