Content migrated to: Website: https://docs.smarthealthit.org/smart-health-links GitHub Repo: https://github.com/smart-on-fhir/smart-health-links

Content migrated to: Website: https://docs.smarthealthit.org/smart-health-links GitHub Repo: https://github.com/smart-on-fhir/smart-health-links

Background and Design goals See https://hackmd.io/kvyVFD5cQK2Bg1_vnXSh_Q See https://datatracker.ietf.org/doc/draft-ietf-gnap-core-protocol/ protocol for reference Design Sketch #3: GNAP Method GNAP Method: Software components Resource Server. Hosts static files (which can be updated over time). These files are (may be?) encrypted so the resource server can't read them. Authorization Server. Manages access control for files in the Resource Server. The Authorization Server is also blind to the contents of encrypted static files.

Older design sketches below... See historical archive. Protocol Ideas OAuth Method. Using extension on OAuth 2.0, where client registrations can be tied to a specific data access policyy Pros: Leverages existing healthcar domain expertise with OAuth 2.0 (SMART on FHIR) Cons: Requires new extension parameters, requires a flavor of dynamic registration

Background and Design goals See https://hackmd.io/kvyVFD5cQK2Bg1_vnXSh_Q Design Sketch #2: Redirect Method Redirect Method: Protocol & Workflow Upload Shared File(s). Data Sharer chooses or creates files to share; encrypts them (see details under "Decryption" below); uploads them to the resource server. If there is more than one file to share, the resource server creates a Sharing Manifest JSON file with an array of high-entropy shared file URLs: { "type": "shclink-read",

Background and Design goals See https://hackmd.io/kvyVFD5cQK2Bg1_vnXSh_Q Design Sketch #: OAuth 2.0 Method Software Components Resource Server. Hosts static files (which can be updated over time) or a live FHIR API endpoint (such as the endpoints hosted by Certified EHR Technology in the US market). Authorization Server. Manages access control for files in the Resource Server. If the files are encrypted, the Authorization Server cannot read them. Notes: These servers can be packaged together into a single software release, but they don't need to be. Files may be encrypted so the resource server and authorization server are unable to read them.

2/28/2022 Meeting notes (AIRA, MITRE, AINQ) Applicable scenarios include where records are requested by a third-party entity that is not a vaccinator who submits data to the IIS or has a DUA in place: schools, camps, out of state providers Current pathways for third-party access ~30 IISs have consumer access, all one-off solutions provided by vendors. Consumer can display or print a PDF version of vaccination records from portal or app. Some jurisdictions allow schools to register as IIS users and get access to records for a specific cohort of students Audit requirement, schools may need to provide proof that they checked students vaccine records (ie copies of student records)

Migrated to http://docs.smarthealthit.org/health-cards/

Migrated to http://docs.smarthealthit.org/health-cards/