FHIR Artifacts > Structure Definition: QuestionnaireResponse Profile

Structure Definition: QuestionnaireResponse Profile

Canonical URL:http://ehealthontario.ca/fhir/StructureDefinition/ca-on-eReferral-profile-QuestionnaireResponse

Simplifier project page:

Command 'link' could not render: Object reference not set to an instance of an object.

Derived from: QuestionnaireResponse (R4)

Formal Views of Profile Content

Description of Profiles, Differentials, Snapshots and how the different presentations work

Could not find subject. File was not found for tabs

Differential View

Command 'tree' could not render: File was not found for ca-on-eReferral-profile-QuestionnaireResponse

Hybrid View

Command 'tree' could not render: File was not found for ca-on-eReferral-profile-QuestionnaireResponse

Snapshot View

Command 'tree' could not render: File was not found for ca-on-eReferral-profile-QuestionnaireResponse

Table View

Command 'table' could not render: File was not found for ca-on-eReferral-profile-QuestionnaireResponse

JSON View

Command 'json' could not render: File was not found for ca-on-eReferral-profile-QuestionnaireResponse

Could not find subject. File was not found for script

Usage

In this IG, the QuestionnaireResponse resource is used in DirectMessaging integrations WITHOUT a corresponding Questionnaire resource to provide structured form data captured in a RMS Source as a list of questions and responses.

Notes

.id

  • used to uniquely identify the resource
  • if a persistent identity for the resource is not available to use when constructing a message Bundle for transmission via Direct Messaging, a UUID SHOULD be used in this element (with a corresponding value in Bundle.entry.fullUrl)

.meta.profile

  • used to declare conformance to this profile
  • populate with a fixed value: http://ehealthontario.ca/fhir/StructureDefinition/ca-on-eReferral-profile-QuestionnaireResponse|1.0.0

.subject

  • used to associate the QuestionnaireResponse with the Patient it is about
  • where .subject is populated, it SHALL reference the same Patient resource as ServiceRequest.subject
  • for DirectMessaging integrations, the Patient resource SHALL be included in the message as a Bundle.entry and, if a persistent resource is available, MAY also be resolvable at a RESTful FHIR endpoint

.author

  • SHOULD be populated with a reference to the PractitionerRole resource or, for self-referrals, a Patient resource who completed the form
  • if the ServiceRequest is being transmitted via messaging, the referenced resource SHALL be included in the message as a Bundle.entry
  • if this element is not populated, recipients MAY assume that the author = ServiceRequest.requester but this has limitations if supplimentary information added by a different author when submitting a referral or if additional data (such as assessments) are added AFTER the initial referral submission