# TEFCA, SMART, and Individual Access :::info :bulb: **Status**: Early draft with no feedback :-) 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 ::: 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 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. (The details here are externalized from TEFCA into SOPs, which aren't yet published. Sequoia's stated intention is that individual access will be a "Required" purpose, but the devil is in the details) ## 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,<br/>check likeness,<br/>check liveness Note over IDV: Name: Josh Mandel<br/>DOB: 10/26/1982<br/>Phone: 617-000-0000<br/>IAL: 2<br/>Audience: MyApp<br/>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: Access data via 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 Provider->>Individual: Please log in or create an account Individual-->>Provider: Sure, I'll do this one-time setup Provider->>Individual: Perfect. Do you want to share with MyApp? Long term? Individual-->>Provider: Yes, I want to share.<br/>Keep the connection active indefinitely. Note over Provider: Access Token: xyz<br/>Refresh Token: abc<br/>Patient: 123 Provider-->>MyApp: You're approved, have a token end ``` ### 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.