# FHIR AuthZ Meetup: SMART, TEFCA, & Beyond [@JoshCMandel](https://twitter.com/JoshCMandel) #### Outline * Granular scopes in SMARTv2 * Focused sharing with SMART Health Links * Patient rights vis-a-vis B2B sharing in TEFCA --- ## Granular Scope Capabilities ### FHIR Resource Scope Syntax - `[level]/[Resource].[cruds]?param=value&param=value` - Example: `patient/Observation.rs?category=vital-signs` --- ### Bucketing permissions by level - `patient/` Allow access to specific data about a single patient - `user/` Allow access to all data that the authorizing user can access - `system/` Allow access to all data that the client is authorized to access --- #### Examples - `patient/Observation.rs?category=vital-signs` - Read and search all vitals for a patient - Allows an app to view a patient's vital signs, lab results, etc. - `user/Immunization.rs` - Read and search all observations that the user can access - Allows a parent to coordinate family's immunizations - `system/Observation.c` - Create observations from a backend service - Allows B2B integration that can submit new observations - Allows an app to record new vital signs, lab results, etc. for a patient ### Challenges with Custom Operations - No standardized scopes for custom operations like... - `/Patient/$export` - `/Patient/:id/$purge` - `/Patient/$update-name` - Difficult to standardize a scope for operations given - Attachment point types (`/`, `/:type`, `/:type/:instance`) - Attachment point instances (any? any visible?) - Input parameter restrictions? #### Suggestions TL;DR Define custom scopes for now. Start with your operation URL for transparency, e.g. `https://myo.example.org/OperationDefinition/locate-patient` Looking ahead, SMART might focus on standardizing data element-level permissions (example syntax only): * Read `Patient.name` - `patient/Patient.r{{name}}` * Write `Patient.address` or `Patient.photo` - `patient/Patient.u{{address | photo}}` --- ## End-User Authorization with SMART Health Links - Simple way for patients to share data directly with apps/individuals - Example: Sharing glucose measurements via a SMART Health Link - Patient generates [a link](https://joshuamandel.com/cgm/#shlink:/eyJ1cmwiOiJodHRwczovL2pvc2h1YW1hbmRlbC5jb20vY2dtL3NobC8xMjBkYXlfYWdwX2J1bmRsZV91bmd1ZXNzYWJsZV9zaGxfaWQwMDAwMDAwIiwiZmxhZyI6IkxVIiwia2V5IjoiYWdwX29ic191bmd1ZXNzYWJsZV9yYW5kb21fa2V5MDAwMDAwMDAwMDAwMCIsImxhYmVsIjoiSm9zaCdzIENHTSBEYXRhIn0) that provides access to their glucose data ![image](https://hackmd.io/_uploads/Hy4OVZnW0.png) - Can share this link with a coach, family member, or trusted app - Recipient can view/download the patient's glucose measurements - Straightforward way to grant targeted data access without complex policies --- ## TEFCA and Network-Based Exchange - Organizational-level authorization decisions with broad impact - Example: All TEFCA participants support "treatment" PoU - Participants can query *everywhere* for treatment - But what if the query seems unrelated to treatment? - Recent issues in the tech news, perceived misuse - Highlights grey areas & need for transparency - Transparency **for individuals** - 3 Principles: https://www.jmir.org/2022/11/e41750/ - See my own data - Know when/why my data are queried - Opt out of sharing
Last changed by  
 
Josh Mandel
154

Read more

SDOH Assessments in FHIR

Design goals (functional requirements) From recent discussion on Jan 2022 US Core ballot content for SDOH assessments, it's important to reach agreement on functional requirements. That is, based on ONC's objectives, we need to decide whether the following are requirements, or nice-to-haves, or out of scope entirely. Scope Questions Should every US Core system be able to represent multi-question SDOH surveys (e.g., instruments like PRAPARE)? I'll take it for granted that no specific instruments are going to be required, so this question is just about the capability to represent multi-question surveys in general. Should every US Core system be able to represent "check all that apply" SDOH questions (e.g., "In the past year, have you or any family members you live with been unable to get any of the following when it was really needed? Check all that apply.") I think the answer to both questions should be "yes". This would require a slight expansion to the US Core ballot content as part of reconciliation, since the ballot content stops shy of (1).

2/15/2022
Untitled

WGM Scratchpad Change the identified text to say: If an operation has exactly one input parameter whose type is a FHIR Resource, a client MAY invoke the operation via POST with the input resource as the request body. Additional simple input parameters, if supplied, SHALL be expressed as query parameters. if it can supply its additional parameters as query parameters When invoking the operation, if there is exactly one input parameter of type Resource (irrespective of whether other possible parameters are defined), then instead of supplying a Parameters resource as the request body, the client MAY execute the operation by a POST with the input resource as the request body. Any additional parameters that can be expressed as query parameters MAY be supplied as query parameters. Discussion: Intent is that an operation with

1/21/2022
Turning lab reb results (etc) into risk scores

Considerations Privacy Identity captured by input VCs --> Identity constraints on output VCs How much can be automated?

5/27/2020
(Draft Blog Post) Verifiable Health Records: Setting [W3C] Verifiable Credentials on [HL7] FHIR

Background: Health data APIs are here With widespread adoption of Electronic Health Records, patients have increasingly reliable access to summary healthcare records through online portals. Many provider-hosted portals today also offer API access through HL7 FHIR; and given this year's expanded requirements from the Office of the National Coordination for Health IT, all certified EHR vendors will offer FHIR APIs by 2022. Convenient API access paves the way for patients to aggregate their own health data and share these data downstream -- making it easier to seek a second opinion, share vaccination records, or send health history to a new care team. As API access expands, we have a critical opportunity to improve API functionality in tandem. In this post, we'll explore functionality that helps patients act as trusted intermediaries. Patients as trusted intermediaries With today's FHIR implementations, data that land in a consumer-controlled app can be shared, but it's hard to achieve any guarantee of authenticity. For example, when a patient saves records from a onehealthcare provider and forwards these records to a new provider for a second opinion, there's no way to tell if the data provided are complete, or whether specific details have been omitted or altered. This model works just fine for most healthcare scenarios, where despite any technical conrtrols, a foundation of social trust must exist between patient and provider. But in some use cases, like a parent storing a child's vaccination records and sending them along to a school, there's a stronger societal need to pass along not just healthcare records, but authenticated, tamper-proof records -- in other words, verifiable data that a recipient can tell is genuine. (Similar to proof of vaccination for participation in school activities, there's growing societal interest in how patients can share history of COVID-19 infection, recovery, and immunity with various people and organizations. Given the rapidly evolving scientific and social perspecties, we won't discuss these issues further in this blog post, but we wanted to highlight the relevance of COVID-19 use cases for patient-mediated exchange of verifiable healthcare data.) Making clinical data "verifiable" One common way to make data "verifiable" is to have the author of the data provide a digital signature alongside the data, computed using the private portion of an asymmetric (public/private) keypair. Verifying parties can establish the authenticity of the data by checking the signature against the author's public key. The nice thing about such signature schemes is that the data can pass through any number of intermediaries without interfering with the recipient's ability to validate the signature. For such schemes to work, the recipient does need some reliable way to determine a sender's public key, and many protocols exist for key "discovery" (e.g., in healthcare, the Direct Project defines a secure e-mail protocol where a sender's keys can be discovered via DNS query on the sender's domain).

5/6/2020
Read more from Josh Mandel
Published on HackMD