Separation of Concerns

IETF/transactional authorizations/SSI Standards

​

HEART

Three clinical use-cases

• Mandated PDMP Access in EHR
• Curated Current Medication List
• Homeless Health Record

All three use-cases are really the same

• Each has a single, patient-centered source of truth (RS)
• The source of truth is authoritative, not patient edited (not CARIN)
• Each is accessible by a credentialed provider (RqP) in their institutional EHR (Client)
• The patient directly or indirectly decides the source of truth (Points the Client to the AS or RS)
• The patient explicitly or implicitly and provides consent for access (Scopes are based on FHIR and CDS Hooks data model)

Gaps in the Cures Reg’s, TEFCA, and CARIN

• SMART on FHIR Apps don’t write from one EHR to another
• The introduction of a CARIN-style data broker app breaks authenticity
• Direct Messages are underspecified compared to FHIR
• Patient has no standard way to specify the source of truth
• Patient has no standard way to specify consent for access

HEART on FHIR Profiles to Fill the Gaps

• SMART on FHIR Apps don’t write from one EHR to another
• HEART Apps are UMA-Aware
• The introduction of a CARIN-style data broker app breaks authenticity
• Patient-directed sharing does not introduce any intermediary
• Direct Messages are underspecified compared to FHIR
• Build on top of FHIR and CDS Hooks data models
• Patient has no standard way to specify the source of truth
• Patient specifies the Authorization Server to EHR Client
• Patient has no standard way to specify consent for access
• AS manages access authorization to Resource Server

​

Separation of Concerns

• Neither the data holder (Source of truth, RS) nor the Client is a data controller
• The Authorization Server does not see the data
• The Authorization Server assumes a subset of FHIR for scoping
• The Requesting Party credentials are separate and distinct from the Client credentials (can be federated or SSI, per AS policy)
• Authorization is based on RqP and / or Client credentials
• The RS can issue a warning to the Patient (RO) but cannot block Client registration
• Patient identity proofing or matching is unnecessary and out of scope. RS and Client access credentials are sufficient.

References

• Separation of Concerns Operators - https://docs.google.com/document/d/1GqLpLEdb0RKtMqZIHO6zryifkan0H6OPrBnZE7gpT9Q/edit
• Operators Alliance - MoU - https://docs.google.com/document/d/17ESp9cGy_AYM9PlKSb4K8bkjxhnbl_e1Yk6Q_VpDJ2o/edit
• MyData Operators - https://mydataglobal.slack.com/files/U7KSE0QF8/F010L4S3XU6/operator_in_context_of_human_centric_data_governance.pdf
• Delegated Authorization - The Alice to Bob Use Case - https://github.com/WebOfTrustInfo/rwot10-buenosaires/blob/master/topics-and-advance-readings/delegated-authorization.md

​

HIE of One Trustee

Needs HEART!

Trustee

• Implements (Emory) Homeless Health Record
• Demonstrates Separation of Concerns
• Highlights gaps in the standards
• Implements both federated and SSI authentication and professional credentials
• Demonstrates Decentralized Governance

​

Trustee Components

• Personal Authorization Server (Trustee)
• Community Support Server (Trustee Directory)
• Direct Primary Care EHR for One Patient (NOSH)

​

All three are Free / Open Source Software

Trustee Demonstrates

• A patient-owned UMA Authorization Server
• A Directory operator separate from the AS
• Policy bundle initializes the AS policies
• Supports patients with hosting / tech support
• Responsible party for CMS (BB2) or Open Epic client registration
• An UMA-aware FHIR EHR as Resource Server (NOSH)

Trustee needs HEART

• To be a voice for patients and patient communities as Directory operators
• A patient-focused alternative or supplement to SMART
• An open alternative to CARIN Alliance
• An interoperability demonstration
• A showcase for SSI alongside federated identity
• HEART to support community open source software