Admin: Automated edit (via update-page on MediaWiki MCP Server)

2026-07-06T04:00:47Z

Automated edit (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 09:30, 6 July 2026
Line 78:		Line 78:

	Reads on an encounter-linked response are allowed if '''either''' <code>can_view_clinical_data</code> (patient) or <code>can_read_encounter_clinical_data</code> (encounter) is held; responses without an encounter fall back to <code>can_view_questionnaire_responses</code>. Updates are limited to marking a response <code>entered_in_error</code> within a short edit window and require the matching submit permission. Roles are granted through a user's organization, facility, or patient memberships, and permissions cascade down the organization tree — so access to a patient's responses follows from access to the patient.		Reads on an encounter-linked response are allowed if '''either''' <code>can_view_clinical_data</code> (patient) or <code>can_read_encounter_clinical_data</code> (encounter) is held; responses without an encounter fall back to <code>can_view_questionnaire_responses</code>. Updates are limited to marking a response <code>entered_in_error</code> within a short edit window and require the matching submit permission. Roles are granted through a user's organization, facility, or patient memberships, and permissions cascade down the organization tree — so access to a patient's responses follows from access to the patient.

			{{Navbox clinical}}

	{{Related}}		{{Related}}
			Wiki: ohcnwiki.tellmey.fyi

Admin: OHC identity seed

2026-07-04T22:43:16Z

OHC identity seed

New page

{{Doc header
|type=concept
|domain=clinical
|title=Questionnaire Response
|order=14
|introduced=3.0
|fhir=Questionnaire Response
|concept=Concepts/Patient
|reference=References/Questionnaire Response
}}

A '''questionnaire response''' is the set of answers a clinician or staff member records when they fill in a [[Concepts/Questionnaire|questionnaire]] for a patient. It turns a blank form — a triage screen, a vitals chart, an intake assessment — into a permanent, attributed piece of that patient's clinical record.

== What it represents ==

In Care's FHIR-aligned model, a questionnaire response maps to the '''QuestionnaireResponse''' resource. It captures:

* '''The answers''' — what was entered for each question, kept both as the raw submission and as an extracted, query-friendly form
* '''Who and what it is about''' — the patient, and the encounter it was recorded in when answered during a visit
* '''Which form was answered''' — a link back to the questionnaire definition that was filled in
* '''Provenance''' — who submitted it and when, maintained automatically by the platform

A questionnaire response is not the questionnaire itself. The questionnaire is the reusable template (the questions and their rules); the response is one patient's filled-in copy. Submitting the same form for ten patients produces ten responses against a single questionnaire.

== How a response is captured ==

Answers are not edited directly into a response record. They arrive through the '''submit flow''': one submission carries the questionnaire being answered, the patient, the encounter if there is one, and the answer to every question. Care validates that whole payload against the questionnaire definition — required questions, allowed values, coded options — and only then writes the response. A submission that fails validation produces no response at all.

This is why a response is best thought of as a snapshot. It records what was answered at the moment of submission, attributed to the person who submitted it, against the patient and encounter in scope at that time.

== Lifecycle ==

A response is finalised the moment it is submitted; it has no draft state of its own.

<syntaxhighlight lang="text">completed → entered_in_error</syntaxhighlight>
* '''completed''' — the response is finalised and part of the record (this is the default and normal state)
* '''entered_in_error''' — the response was recorded by mistake; rather than deleting it, it is flagged so the history stays auditable

Because answers are not re-edited after submission, the only change applied to an existing response is marking it <code>entered_in_error</code>. Drafts, where they exist, live one level up in the '''form submission''' envelope (<code>draft → submitted</code>) before a response is written — see the technical reference.

== How it connects ==

* '''Patient''' — every response belongs to a [[Concepts/Patient|patient]]; it is governed by that patient's permission set
* '''Encounter''' — when answered during a visit, the response is tied to that [[Concepts/Encounter|encounter]], giving the answers a clinical context and timestamp
* '''Questionnaire''' — the response points back to the [[Concepts/Questionnaire|questionnaire]] it answered; rendering the answers joins them against that definition so labels stay human-readable
* '''Structured data''' — alongside the raw answers, a response can hold an extracted, query-friendly copy of those values. This is what lets a vitals form become real observations, or an allergy form become allergy records, rather than leaving the data locked inside a form

== Permissions ==

Questionnaire responses have no permission slug of their own. The read-only-plus-update viewset gates each action through the '''patient''' and '''encounter''' permission sets, choosing which permission to check based on whether the response is tied to an encounter.

{| class="wikitable"
|-
! Permission
! Description
! System Roles
|-
| <code>can_view_questionnaire_responses</code>
| View the questionnaire responses on a patient when the response is not linked to an encounter
| Volunteer, Staff, Doctor, Nurse, Admin, Facility Admin, Administrator, Pharmacist
|-
| <code>can_view_clinical_data</code>
| View clinical data about a patient; satisfies viewing an encounter-linked response from the patient side
| Staff, Doctor, Nurse, Admin, Facility Admin
|-
| <code>can_read_encounter_clinical_data</code>
| Read an encounter's clinical data; alternatively satisfies viewing an encounter-linked response from the encounter side
| Admin, Doctor, Nurse, Facility Admin
|-
| <code>can_submit_patient_questionnaire</code>
| Submit a questionnaire about a patient; required to update (correct) a response not linked to an encounter
| Volunteer, Staff, Doctor, Nurse, Admin, Facility Admin, Administrator
|-
| <code>can_submit_encounter_questionnaire</code>
| Submit a questionnaire about a patient encounter; required to update (correct) an encounter-linked response
| Staff, Doctor, Nurse, Admin, Facility Admin
|}

Reads on an encounter-linked response are allowed if '''either''' <code>can_view_clinical_data</code> (patient) or <code>can_read_encounter_clinical_data</code> (encounter) is held; responses without an encounter fall back to <code>can_view_questionnaire_responses</code>. Updates are limited to marking a response <code>entered_in_error</code> within a short edit window and require the matching submit permission. Roles are granted through a user's organization, facility, or patient memberships, and permissions cascade down the organization tree — so access to a patient's responses follows from access to the patient.

{{Related}}

Concepts/Questionnaire Response - Revision history

Admin: Automated edit (via update-page on MediaWiki MCP Server)

Admin: OHC identity seed