Trusting Health APIs
Mark Scrimshire is part of the Entrepreneur-in-Residence (EIR) program at the U.S. Department of Health and Human Services (HHS). The program brings together talent from within and outside government to tackle high priority issues in health, health care, and the delivery of human services.
In the Healthcare, world trust is the basis for all interactions. The Patient-Doctor relationship is the primary example of Trust and is probably the most important relationship in Health. As Health goes digital it is essential that we bring trust with us into the digital world. One of the big challenges is to do this without the trust process becoming either intrusive or limiting.
The issue of trust has been a critical component I have been focused on as we design the next generation of BlueButton for Medicare beneficiaries: BlueButtonOnFHIR.
As the Centers for Medicare and Medicaid Services (CMS) builds the BlueButtonOnFHIR API (Application Program Interface) Service we have to provide a way for beneficiaries to connect their data to the applications, services and research programs they trust. It is the beneficiaries data and they should have a right to choose how they use it. So how can we enable this to happen while CMS also discharges their responsibility to safeguard the data? A responsibility that is embraced with the utmost seriousness across the agency.
The traditional response would probably be to establish an organization to vet every entity that applies to gain access to a beneficiary’s data. Some of the many challenges with this approach is to work out what is the basis for trusting the applicant, particularly if a beneficiary has declared their intent and permission for an applicant to have access to their data.
There must be a better way…
What if we could leverage the incredible efforts that the health industry has already invested in so that millions of people (providers and patients) can already exchange information securely based on a network of trust?
What if we could tap into that network of trust to provide a baseline of trust as the starting point for enabling access to health API’s?
Building on the shoulders of giants
The HL7 Fast Health Interoperability Resources (FHIR) framework is fast becoming a cornerstone of health interoperability. FHIR has secure authorization protocols (OAuth) baked into the framework. However, a big challenge remains: who do you trust to receive a set of keys?
Before FHIR emerged onto the scene the health industry had invested in the Direct protocol.
This description does not do justice to the incredible efforts behind developing this protocol but it is basically a secure email that can be exchanged between parties who trust each other. This is being carried out today at increasing scale.
Two organizations deserve acknowledgement for advancing this network of trust:
- The National Association for Trusted Exchange (NATE)
Their trust bundles enable millions of people to securely exchange personal health information today.
Direct and FHIR: stronger together
I have approached DirectTrust and NATE with a proposal for a simple API that bridges the Direct and FHIR worlds and enables FHIR implementers, such as CMS, to leverage the Direct Trust bundles as a baseline for trusting entities that apply to access a FHIR API.
I am calling this API the Whitelist Health OAuth Trust (WHOT) API.
You can read the draft specification here.
How will the Whitelist API work?
CMS, or any other FHIR API publisher, would connect with the open source Whitelist API hosted by the trust administrators. When an entity creates a developer account, they would provide information about their entry in the appropriate trust bundle plus a shared secret that is known only to that registering organization that had been encrypted and stored with the trust administrator.
If all the information provided to the API is correct, the API would respond with an ”ok” message. If any information is wrong the API returns a 404, “Not Found”.
The API is designed to be simple and provide a baseline of trusts that validates that the person representing an entity requesting access is known to one of the trust administrators. It would be for the FHIR publisher to decide which trust administrators they will securely connect to. This is the same situation we see today with the direct protocol where an organization decides which trust bundles they add to their system.
We are developing the WHOT API as an open source solution and will offer it to the health industry. It is designed to be easy to implement. Anyone who operates a trusted community and seeks to validate identity could choose to embrace this API.