Can also be referred to as forms.

Questionnaires is a structure that contains a list of questions that are intended to be answered about a resource. Questionnaires can be about patients, doctors, about clinical procedures or anything that has a unique identity in the application.

Questionnaires are used to generalize data collection because the requirements of data changes across types of facilities and regions, requirements emerge all the time and creating revisions for each type of data is impossible. Questionnaires seemed like the logical next step in building a competent HIS.

What makes a Questionnaire ?

Questionnaires are inspired from FHIR HL7 Questionnaires, but they are heavily modified to adapt to product requirements.

The current requirements for Questionnaires are :

• Ability to add questions and group them together.
• Support different type of responses, and units ( Only units that are defined based on a system will be allowed )
• Support creating observations or Questionnaires Results ( Medical observations are written as observations while non-clinical observations are stored as responses )
• Support connecting a code system as response options to a question, In some cases a section of the code system can only be used, that also needs to be supported. Either through the systems capability of grouping via some concept or through manually selecting options from a system.
• Support multiple results from the same question ( multi select )
• Support option to store all results in the same observation or split into multiple observations
• Support ability to add metadata as per HL7 FHIR to questions : These include meta questions for groups like if you check the Blood pressure, where it was performed is a meta question.
• Support calculated fields from existing data to create calculated data. Examples are BMI, Glasgow Coma Score etc..
• Support notes for all question responses. This should be configurable at a question level.
• Support formatting metadata, formatting could be used by different clients as they need them, design for multiple clients should be supported.
• Basic security around the forms should be ensured, this includes forms cannot be created by non admins, form entry should be visible to certain accounts, all operations should be based on permission on the resource the form is created on.

Request/Response Architecture

The actual Questionnaire spec would just be a json structure because its not actively queried on. Questionnaires can be stored in a dedicated table with some metadata stored as table columns.

Each Questionnaire would have a name, description and status.

The possible status for Questionnaires would be these, once a Questionnaire is moved to the active status, it cannot be edited or deleted, it can only be retired . This is done to ensure that the Questionnaires data integrity is not compromised. Retired **is the same as archived, but the forms with data are still rendered to keep the data visible.

Questionnaires can have a subject attribute that specifies what type of resource this form is about.

Metadata about Questionnaires will be maintained, this includes the created user, update time, created date.

Questionnaire Structure

Version 0.1

{
  "version": "str", // Semver can be maintained when the schema changes to support more features
  "code": [{ "system": "uri", "code": "code", "text": "str" }], // List of codes to link to multiple systems : Not Required
  "stylingMetadata": { "care": "" }, // Styling requirements as required can be dumped here -- No Validations are performed for this attribute
  "questions": [
    {
      "link_id": "str", // This is a unique human readable id added to every question, used when linking to other questions, can be replaced with FE magic
      "id": "<uuid4>", // unique machine provided id to the question
      "code": [{ "system": "uri", "code": "code", "display": "str" }], // This is required if observations are to be created.
      "collectTime": "bool", // If this is enabled, we can also collect an additional timestamp per question or group to maintain an observation captured time.
      "collectPerformer": "bool" // If this is enabled, the source of truth also needs to be entered in the form
      /* Performer is stored in the following structure.
      {"performerType" : "", // options from <https://hl7.org/fhir/observation-definitions.html#Observation.performer>
		      "performerId" : "", // Id of the reference
		      "text" : "" // Use text if there is no hard reference. 
      }
      */
      "text": "str",
      "type": "options", // Refer to <https://build.fhir.org/valueset-item-type.html> , "Group" should be used if this is a group
      "enableWhen": [
        {
          "question": "linkId", // Link Id of the question to check against
          "operator": "option" // Refer to <https://build.fhir.org/valueset-questionnaire-enable-operator.html>
          "answer" : "" // Value for operator, store value based on type of question
        }
      ],
      "enableBehavior": "all|any", // Should we enable for if all or any of the conditions are met : Refer <https://build.fhir.org/valueset-questionnaire-enable-behavior.html>
			"disabledDisplay": "hidden|protected", // Display hidden options or not : Refer <https://build.fhir.org/valueset-questionnaire-disabled-display.html>
			"collectBodySite" : "bool", /* Nullable, if enabled a field should be added to capture where the observation was captured : 
			Refer to <https://build.fhir.org/valueset-body-site.html> for options */
			"collectMethod" : "bool" /* Nullable, if enabled a field should be added to capture how the observation was captured : 
			Refer to <https://build.fhir.org/valueset-observation-methods.html> for options */ // Might need to support valuesets here
			"required" : "bool", // Is this item required? 
			"repeats" : "bool", // Should multiple choices be selected?
			"readOnly" : "bool", // Should this field be Human Editable? Used for autocalculated fields
			"maxLength" : "int", // Max length for string based fields
			"answerConstraint" : "options", // Can we support something not from options, Refer to <https://build.fhir.org/valueset-questionnaire-answer-constraint.html>
			"answerOption" : [
				{
					"value" : "value" // Based on the type of the question
					"initialSelected" : "bool" // Is initially selected? 
				}
			],
			"answerValueSet" : "slug_of_valueset", // Create Valueset in care and mention the slug of the valueset here.
			"answerUnit" : {
					// Code, can be fetched from the unit valueset, this will checked against the allowed units if code in LOINC has mapping
				},
			"isObservation" : "bool" // Should this item be stored as an observation, if not specified, defaults to parents value
      "questions": [
        // More Questions or empty
      ]
      "formula" : "formula" /* Formula that uses eval() in js to evaluate to a value. 
      use linkId and replace when calcualting, Data is always readonly and not sent to the backend */
      
      // We are not supporting initial values in this version -- Too complicated and can be enhanced in forms later on. 
    }
  ]
}

Questionnaire Submit Schema