Background See commenters Description: The commenter is referring to this Observation Profile: Resource Profile: US Core Screening Response Observation Profile ... This profile sets minimum expectations for the Observation resource to record, search, and fetch retrieve observations that represent the questions and responses to form/survey and assessment tools such as the Protocol for Responding to and Assessing Patients’ Assets, Risks, and Experiences (PRAPARE) Survey . This profile encompasses single, multipart, and derived responses. It identifies which core elements, extensions, vocabularies and value sets SHALL be present in the resource when using this profile. These observations are distinct from observations representing individual clinical assessments made by an individual about a patient’s social history and not derived from an assessment tool or survey. These types of observations should use the US Core Social History Assessment Observation Profile instead. ... Each Observation must have: a status a category code of ‘survey’ a LOINC code, if available, which tells you the survey question a patient Each Observation must support: a time indicating when survey was taken who answered the questions the answer or a reason why the data is absent* if the result value is a numeric quantity, a standard UCUM unit is required related questionnaire responses or observations that this observation is made from component results US Core is a jurisdictional Implementation Guide whose stated goal is to defines the minimum set of constraints on the FHIR resources to create the US Core Profiles. It also defines the minimum set of FHIR RESTful interactions for each of the US Core Profiles to access patient data. In line with those goals this profile represents the SDOH Assessment data element in part as responses to survey instruments such as a form or questionnaire like PRAPARE or Hunger Vital Signs and others as individual question/answer pair or question/multiselect answers. As the commenter correctly points out it * does not * retain the context or the form's structure via grouping elements such as `hasMember`. Additionally these design decisions were made after soliciting feedback from ONC, the Gravity project SDOH clinical Care IG development team, and feedback from EHR vendors and FindHelp.org, a provider of social service assistance tool used by several EHRs. Other options were considered. Prior Art Since 2016 the Structured Data Capture Implementation Guide is the authoritative guide on how to provide the infrastructure to standardize the capture and expanded use of patient-level data collected within an EHR using forms and questionnaires. It include detailed guidance on using Questionnaires and QuestionnaireAnswers and turning completed forms into a FHIR resource or Bundle of FHIR resources for subsequent analysis. The SDOH Clinical Care IG enables Enabling Survey Instruments by standardizing the capture, coding and output of SDOH risk surveys. This guide provide the necessary framework for preserving "the context for the individual parts of a single screening instrument." It leverages the SDC guide to extract the specific survey results into FHIR Observation and other resources. Reasoning We admit there is limited testing and real world experience is lacking so either approach is untested. Based on ONC’s objectives, The CGP WG decided these functional requirements are in scope: Every US Core system SHOULD be able to represent multi-question SDOH surveys (e.g., instruments like PRAPARE) Every US Core system SHOULD 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.”) ( https://confluence.hl7.org/pages/viewpage.action?pageId=90342002 ) Proposed Changes For US Core it was decided to represent surveys/assessments using Observations and optionally QuestionnaireResponse. Specifically For Observations to represent multi-question SDOH surveys and “check all that apply” questions by referencing individual response using the 'hasMember` element. (The full draft proposal can be seen is archived below as attachment)