Attendance Current Work/Announcements Updated build; Keith to work with David on git workflow back to IG publisher infrastructure Value sets being developed for COVID, currently in VSAC -- MITRE developing content. Hot Topics Testing Updates Testing for connectathon: Joe at Meditch still trying to determine level of participation. [Workflow discussion]

@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

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).

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

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

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).

# Subscriptions for public health Use case: get notified when data about a reportable condition is entered into an EHR (e.g., diagnosis of Zika is made, or a Zika lab test arrives). Today there's a CDA IG that requires custom coding to implementation. Today, a PHINVADS valueset is provided that EHR vendors can use to trigger reporting logic: * https://phinvads.cdc.gov/vads/SearchVocab.action (click "RCTC" to get spreadsheets like [this](https://phinvads.cdc.gov/vads/DownloadHotTopicDetailFil