Cross-posted same comment to US Core; 

http://hl7.org/fhir/us/sdoh-clinicalcare/2022Jan/StructureDefinition-SDOHCC-ObservationScreeningResponse.html

and

http://build.fhir.org/ig/HL7/US-Core/StructureDefinition-us-core-observation-screening-response.html

... both propose an approach that decomposes SDOH responses into unordered bags of Question/Answer pairs, providing grouping only for “select-many” questions like “check all that apply”.
 
If we’re going to use Observations here, we might as well model a screening instrument with a top-level code for the instrument (e.g., Observation.code of https://loinc.org/93025-5 for PRAPARE), and use components for each question/repetition. That allows a full set of responses to be conveyed together as a unit, rather than breaking it up by question – this way you don’t have to guess or do timestamp-based matching to re-assemble the parts. Another benefit is we avoid confusion about whether to look at the top level vs “inside” for answers. Even if only a single question is used, this pattern allows search by top-level instrument that the question came from, or by component code for the specific question.

Alternatively we could follow the pattern in FHIR’s vital signs profiles and use a single grouping Observation with hasMember.

Either of these approaches would provide better context for the individual parts of a single screening instrument.