# TEFCA, SMART, and Individual Access :::info :bulb: **Status**: Early draft with no feedback :-) Please share notes [@JoshCMandel](https://twitter.com/JoshCMandel) ::: 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 Draft proposals: * leave HIPAA covered entities facing risk of disclosure in the case that matching algorithms produce false positives * assume that consumer-facing must be "deeply trusted" by all netwrok participants (such that a compromised app could unilaterally retrieve clinical data on any patient in the USA) * (to compensate for these deficiencies) do not actually obligate data providers to share data with consumer-facing applications (i.e., they can choose not to honor individual access requests coming from these apps, if the apps aren't representing HIPAA covered entities) ## Idea: TEFCA for Record Location, then SMART for 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. 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, where the inputs to a QHIN are a set of identity claims from a trusted ID Verifiacation service ("IDV"), and the outputs are 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->>IDV: Can you validate<br/>this user's identity? IDV-->>MyApp: Sure, coming right up 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-->>MyApp: Your user is Josh! See attached claims for details. end rect rgba(100, 100, 100, .2) MyApp->>QHIN: I've got Josh here.<br/>(Don't take my word, see IDV claims!)<br/>Help me find his records? QHIN->>QHIN: Check DB,<br/>query peers Note over QHIN: 1. https://mgb.example.org/fhir<br/>2. https://cedars.example.org/fhir<br/>3. https://uw.example.org/fhir QHIN-->>MyApp: Here are the endpoints you should follow up 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: * **Explicit 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 participants agree about which IDVs are 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[](https://) 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 IDV, 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. 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.