Skip to content

QuestionnaireResponse Profile

Canonical../StructureDefinition/nexus-emr-core-questionnaireresponse
Statusdraft (experimental) · 1.26.0
BaseQuestionnaireResponse (constraint)
SourceFSH · JSON

Nexus EMR profile for QuestionnaireResponse -- completed intake, screening and consent forms, including those passed through from external eReferral partners. Appears in the patient chart's journey timeline. First pass: dating and form linkage; item structure is deliberately unconstrained.

Overview

Overview

The Nexus EMR Core QuestionnaireResponse profile represents a completed form for a patient: an intake questionnaire, a screening instrument, or a consent questionnaire. A response may be authored in this EMR or received from an external eReferral partner, and it surfaces in the patient chart's journey timeline as a questionnaire entry.

The profile is #draft and experimental = true. It is a first pass covering the skeleton, the dating rule, and the linkage back to the form definition. It is now reachable by a SMART on FHIR app for read, search, create and update: the profile declares smart-exposed -- this guide's positive flag for app reachability -- and the server capability statement lists it. Deletion is not granted; a response filed in error is marked entered-in-error rather than removed, which is what keeps a chart's history answerable.

status is 1..1 (in-progress | completed | amended | entered-in-error | stopped); chart surfaces should scope to completed and amended, since an in-progress response is a partially-filled form and rendering it as a chart fact overstates it. subject (0..1, NexusEmrCorePatient) is optional per R4, but anything appearing in a patient chart must carry it -- an unsubjected response can neither be scoped to a chart nor excluded from one. encounter is 0..1 (NexusEmrCoreEncounter). author (0..1) is who recorded the answers and source (0..1) is who supplied them: a patient-completed intake form has Patient as source, while author may be that same Patient on a self-serve portal or a staff member transcribing.

authored is the only date this resource has, and it is optional

THE effective date is authored, with no fallback. R4 makes it 0..1 and this profile leaves it optional, because pass-through responses from partners may genuinely lack it, but a warning-severity invariant (questionnaireresponse-has-authored) recommends it on every instance:

  • An undated response is silently invisible to any date-driven surface rather than visibly incomplete. The chart timeline dates entries by authored, so a response without it drops out instead of appearing as unknown.
  • Writers should always set it, even when transcribing a form completed earlier.
  • Readers should not substitute meta.lastUpdated or the linked encounter's date; neither is the form's completion date, and either would misplace it in the timeline.

identifier is 0..1 here, unlike most of this IG

R4 gives QuestionnaireResponse a singular identifier, not an array, and this profile does not change that. A consumer written against the 0..* shape found on nearly every other profile here will mis-read it. When present, identifier.system and identifier.value are both 1..1. The house identifier warning that used to be phrased against this single element, questionnaireresponse-has-raw-identifier, was removed in 1.21.0; nothing checks identifiers on this profile now.

This is the only governed way to link a response back to the form instance it came from in the originating EMR or partner system, so populating it matters more than the 0..1 cardinality suggests -- and because only one identifier fits, carry the source-system one.

item is deliberately unconstrained

item is 0..* and its structure is intentionally not constrained. External instruments define their own item trees, and constraining item here would make otherwise-conformant partner data non-conformant. That is a decision rather than an omission, and it is not expected to change. Consumers must treat the tree as open:

  • Recurse; do not index positionally. item[0] is not a stable question slot.
  • Tolerate nested item at any depth, including items carrying both answers and child items.
  • Expect answer.value[x] in any of its permitted R4 types, not only string and coding.

questionnaire (0..1) is the canonical URL of the definition being answered. For an EXTERNAL instrument it points at a definition this IG does not govern, and that is correct and permanent. For a form authored in this EMR it points at a Questionnaire, which this IG has profiled since 1.20.0 -- so a response to a Nexus form is now interpretable against a governed definition rather than against nothing. A response with no questionnaire still cannot be interpreted beyond its own display text, because nothing states what the items mean: treat such a response as human-readable only.

How an answer that is also a clinical fact (a blood pressure, a screening score) becomes an Observation is answered by the form, not by the response. A Nexus Questionnaire carries contained prototypes of what it produces and names them with SDC's templateExtract; extraction clones a prototype and fills it from the answer. So whether a corresponding Observation exists is a property of the definition you are holding, and is readable from it -- rather than a convention you have to know. For a response to a form this IG does not govern, the earlier advice stands: do not assume a corresponding Observation exists, and do not assume one does not.