For Dynamic Health IT (DHIT), the recent FHIR DevDays virtual conference was a great opportunity for knowledge sharing. DevDays empowers us with its focus on current trends and future development in Healthcare IT. As usual, interoperability was center-stage as a problem area and also an opportunity, and FHIR is central to the most promising solutions.
In addition, FHIR will soon be mandated for ONC-certified healthcare IT products, along with SMART. FHIR intentionally omits addressing security and SMART helps fill that void by providing a framework for security and authorization. With the implementation of the 21st Century Cures Act, the ONC rolled out 170.315(g)(10) “Standardized API for patient and population services”, a required CEHRT criterion that specifies not only FHIR 4.01 but also SMART and the OpenID Connect standard,
With COVID-19 and its pervasive problems, it’s all-hands-on-deck as healthcare IT strives to support patient care and appropriate sharing of healthcare data. Multiple organizations have already adopted FHIR to solve specific problems. As healthcare data sharing becomes more pervasive, protecting personal information, privacy and security are critical components. This was an important discussion area at DevDays.
Decentralized Identifiers, Verifiable Credentials, & FHIR
As the deployment of FHIR expands across organizations, identity management is a critical challenge. Josh Mandel from Microsoft presented on this topic:
- Identity Proofing
- In-Person Identity Proofing (e.g. come into the office to receive a sign-up code)
- Cons: Slow, expensive and inconvenient
- Knowledge-based Identity proofing (e.g. What color is your Volkswagen?)
- Cons: Expensive for relying parties, “proof” data are guessable and are subject to breach. This also leads to data hoarding.
- Authentication
- Controls for data sharing
We were eager to absorb as much information as possible about data sharing, privacy, and transparency practices to apply to our own use cases. One DHIT use case involved implementing an authorization server to protect APIs. At the time, we considered whether to include a social login feature via OAuth 2.0 and OpenID Connect to access the user’s PHI. This feature would have allowed users to leverage their Facebook and Google logins to access their health information via our patient portal or a mobile app like Apple Health. Although it would have been convenient for users, we abandoned it due to security concerns.
At DevDays, we were very interested in hearing about the move towards Self-Owned Identity Standards and in getting informed about the emerging international standards for Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) from the World Wide Web Consortium. There’s a good write-up about VCs at ,https://w3c.github.io/vc-data-model/.
We were galvanized by the VC case study: “Health cards” for Covid-19 – which was demonstrated with an example from the laboratory domain to illustrate how these standards dovetail with FHIR to put users in control of managing their own results. The case study used a virtual wallet that can convey verifiable lab results. Microsoft provided an open-source project – ,https://github.com/microsoft-healthcare-madison/health-wallet-demo, ,https://c19.cards/. It’s worth checking out.
A couple of questions that came up during this discussion were:
- How to protect the private key that’s used for generating the DID
- How to protect against overloading our phones/mobile devices that hold these keys
The Microsoft team had feedback on 2), emphasizing secure and convenient key storage. For many people, this might mean a mobile phone, and the hardware capabilities have evolved to support this. For other people, it might mean dedicated hardware tokens, and that’s OK too!
Even though the risks and potential for misuse of Decentralized IDs are real and deserve careful attention, the development and adoption of the Decentralized Identity will rethink fundamental healthcare processes and catalyze the movement towards the world of decentralization.
Fine-Grained Security Policies
Since the inception of FHIR, access control has been of paramount importance. To enable FHIR open API and build powerful apps on top of it, we need fine-grained access control, which can go beyond role-based control and simple SMART on FHIR scopes. Let’s consider a few examples to get a better understanding:
- A practitioner must be able to view the records of his or her patients.
- A parent or guardian needs to manage the medical records of children or elderly parents.
- Some sensitive resources should be visible only upon explicit Consent.
When the actors in these use cases are external to the FHIR server, the difficulty is compounded. Knowing incoming users, their relation to other patients and providers, and matching their role to the FHIR Ecosystem can be tricky. In the past, these problems were typically solved with home-grown solutions.
The discussion panel in DevDays for this topic had CTO’s & Architects from Microsoft, Firefly & Health Samurai. The themes for discussion centered on these topics:
- Architecture: Where do policy definitions and enforcement live?
- Identity: Where do users and their permissions live?
- Resource-Level control: Thinking beyond FHIR compartments.
- Sub-Resource Control: Thinking beyond FHIR elements.
This brings our attention to some existing standards that can be used as a starting point.n
OAuth 2.0- Rich Authorization Requests and User Managed Access (UMA 2.0)
OAuth 2.0 features a “scope” that allows OAuth clients to specify the requested scope, i.e., the permission, of an access token but that scope lacks sufficient granularity for use cases like:
“Grant access to Sally Smith’s USCDI data except for medications and psych consult notes”
The extension introduces a new parameter “authorization_details” that allows clients to specify fine-grained authorization requirements using JSON. The Draft Spec can be viewed at ,https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-03
User Managed Access (UMA 2.0) defines a means for a client, representing a requesting party, to use a permission ticket to request an OAuth 2.0 access token. Token then allows access to a protected resource asynchronously from the time a resource owner authorizes access.n n UMA 2.0 could be a radical change when it comes to the authorization server concept. This brings the idea of putting the authorization server under the user’s control and extends the concept allowing for the requesting party to be different from the user. For example, a user could ask for a researcher to access de-identified data.
The Spec can be found at ,https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html
OAuth.xyz – Transactional Authorization
This is a proposal for a transactional authorization protocol called “XYZ” to address the things that OAuth 2 doesn’t handle well on its own. Optimizations and decisions that made sense in OAuth 2 don’t make as much sense today. The Oauth.xyz brings in a transactional model, which will be flexible enough to fit a variety of circumstances and use cases.
More details of the spec can be found at https://oauth.xyz/.
DHIT has been an enthusiastic proponent of FHIR since the early connect-a-thons and the latest DevDays was an excellent opportunity for us to immerse ourselves in the latest FHIR-related technology developments.
