TEFCA, SMART, and Individual Access

# TEFCA, SMART, and Individual Access :::info :bulb: **Status**: Draft with for comment. Please share notes [@JoshCMandel](https://twitter.com/JoshCMandel) * Updated Feb 2022 to put QHINs in charge of hosting a SMART on FHIR endpoint for record location * Updated Oct 2022 to * include `login_hint` in sequence diagram in Step 2 * add "Basic" and "Advanced" approaches for Step 2 ::: Today's EHR Certification rules enable individual API access where: * An app registers with an EHR vendor * An individual approves access for an app, after authenticating to a data holder * access can be scoped (granting permissions to see subsets of the record) * access can be persistent (allowing long-term "set and forget" connections) **An outstanding challenge is that individuals don't always know where their data live, and it's not easy to find out.** Meanwhile, TEFCA proposes a distinct set of capabilities for individual access, spanning from record location to retrieval -- but the proposed agreements and technical standards are ill-suited for real-world adoption. Specifically TEFCA v1 Common Agreement: * leaves HIPAA covered entities facing risk of disclosure in the case that matching algorithms produce false positives * assumes that consumer-facing apps must be "deeply trusted" by all network participants (such that a compromised app could unilaterally retrieve clinical data on any patient in the USA) * might not in practice obligate data providers to share information for individual access, or might allow data providers to establish a different (read: higher) bar for privacy/security/identity (compared with the policies set for clinical use or other purposes) -- all while falling within ONC's allowable exemptions for Information Blocking. This thread from ONC explains the problems clearly: https://twitter.com/ONC_HealthIT/status/1574489666119688192 . ## Proposal: QHINs support SMART on FHIR for Record *Location* (at least), and providers support SMART on FHIR for Record *Access* We don't need TEFCA to provide an end-to-end path for individual access. An "onramp" is good enough, which means we can decompose the "individual access" problem and focus TEFCA on **record location** instead of access. (To be clear: if QHINs are able to provide record access *as well as location* services, that would be preferable and compatible with the proposal below -- but I don't want to assume too much in the context of a "minimum viable architecture".) Roughly speaking, that means a two-step process for individual access, expanding upon (rather than recapitulating!) today's widely deployed SMART on FHIR protocols. ### Step 1: Locate Records via TEFCA QHINs This is a new data flow leveraging SMART on FHIR, where a QHIN manages user sign-in (typically relying on a trusted ID Verification service, but that's the QHIN's choice) and exposes a narrow RLS-oriented FHIR API to apps that a patient chooses to authorize. The API returns a list of SMART on FHIR endpoints where this person *probably* has records. ```mermaid sequenceDiagram Participant MyApp Participant Individual Participant IDV Participant QHIN Individual ->> MyApp: Help me find my records! rect rgba(0,100,0,.1) MyApp->>QHIN: Can I access your record locations API? Please ask the user for me. QHIN-->>IDV: Can you verify the ID of this patient for me? IDV->>Individual: Please upload your license, take a selfie, etc. Individual-->>IDV: Of course, here you go. Hope it's not too blurry. IDV->>IDV: Verify documents, check likeness, check liveness Note over IDV: Name: Josh Mandel DOB: 10/26/1982 Phone: 617-000-0000 IAL: 2 Audience: MyApp Signed: IDV IDV-->>QHIN: Your user is Josh! See attached claims for details. QHIN-->>Individual: Hi Josh! Do you want MyApp to see where your EHR records are located? Individual-->>QHIN: Yes please QHIN->>MyApp: Here's an access token end rect rgba(100, 100, 100, .2) MyApp->>QHIN: Thanks! Please tell me where Josh's records live QHIN->>MyApp: Here's a FHIR Bundle of SMART-enabled patient access endpoints you'll want to connect with end ``` ### Step 2 ("Basic" approach): User connects to EHR with SMART on FHIR This leverages a standard SMART on FHIR flow ```mermaid sequenceDiagram Participant MyApp Participant Individual Individual ->> MyApp: Now help me collect my records! loop For each endpoint returned by the Record Locator MyApp->>Provider: Please connect via SMART on FHIR alt "login_hint" suggests IDV Provider->>Individual: You've got a credential from IDs-R-Us? You can sign in with that :-) Individual->>Provider: OK, that's easy! else No "longin_hint" available Provider->>Individual: Welcome! please log in or create an account Individual->>Provider: Sure, I'll do this one-time setup end Provider->>Individual: Perfect. Do you want to share with MyApp? Long term? Individual-->>Provider: Yes, I want to share. Keep the connection active indefinitely. Note over Provider: Access Token: xyz Refresh Token: abc Patient: 123 Provider-->>MyApp: You're approved, have a token end ``` ### Step 2 ("Advanced" approach): Automated SMART on FHIR connection In an "Advanced" version of step 2, the QHIN might return not just a set of endpoints but could also gather and return a set of sharing choices pertaining to those endpoints. For example, the QHIN might collect and return a pile of single-use signed JWTs, each with with claims like: > Dear {FHIR Server at Provider A}, the user {Josh, DoB=....} has requested that {full clinical data} be shared with {MyApp} until {March 1 2023}. Signed, {QHIN B}. This authorization grant could be submitted to the EHR's token endpoint, combined with an authentication JWT signed by the app, to allow for automated issuance of an access token without end-user interaction. ### Design considerations A nice thing about this design is that it re-uses existing SMART on FHIR authorization building blocks for connecting a third-party app to a provider endpoint. This provides an incremental path for apps like Apple Health Records or Common Health to gather a more complete and accurate clincal history, building on widely adopted real-world protocols for individual access. In practice there are a few aspects of the UX that need to come together for this to work smoothly: * **Role for ID Verifiers.** ID Verification Providers are directly focused on the consumer experience and compliance requirements for determining who a person is. If TEFCA QHINs can determine which IDVs they consider trustworthy, there's no need to instill deep trust in consumer apps. * **Limited trust in consumer apps.** The consumer needs to trust MyApp in this architecture, but the other parties (namely, the QHIN and the Provider) do not. This ensures that the ecosystem isn't granting consumer apps the "keys to the kingdom", and a compromised consumer app can't automatically fetch data about any patient in the USA. * **Long-term access.** At the end of this workflow, MyApp should have long-term access to the patient's records from all sources where the patient has approved such access. The provisioning process might be lenghty, but it's a one-time investment -- and many optimizations can be applied over time to reduce the friction of this process, once the framework is in place. * **Inline account provisioning.** If the individual doesn't yet have an account with a healthcare provider, there needs to be a simple way to create an account (or otherwise authenticate) inline, so people don't get stuck partway through this workflow. Ultimately a provider gets to control how this process works, but in the ideal case, MyApp would send along a `login_hint` including verified claims from the QHIN, to help the provider streamline this process. The provider might review these claims and simply decide to verify the user's phone number or email address (by sending a one-time code) rather than making the user go through a whole set of ID proofing steps at this point. Or they might sent the user to a QHIN-managed screen for re-authentication. But even if there are additional steps required, as long they're a one-time effort and the result is a long-term connection, this works out OK.