1. Creating the Form

In order for a form to be used consistently across the healthcare enterprise it must be defined and then stored in a repository.

The US National Laboratory of Medicine - FHIR Tools has several tools to support the curation of forms and a repository of forms.

The NLM Form Builder provides an web app which can be used to generate FHIR Questionnaires. For example:

1. Open the form NLM Form Builder
2. Select Start with an existing form
3. Then select Import from LOINC, enter Vital Signs and select the entry with 74728-7 LOINC code.
4. When the top form is displayed, click on Edit Questions which displays the questions the forms contains.

This can then be stored on a central server to be shared with users. In the NLM Form Builder this can be done by using the export function. The address of the UKCore Hackathon Server is

https://3cdzg7kbj4.execute-api.eu-west-2.amazonaws.com/poc/events/FHIR/R4

This server will make a few alterations to the submitted Questionnaire for technical reasons. The most important change is it will create a Questionnaire.url if one is not supplied from the Questionnaire.code. For the Vital signs, weight, height, head circumference, oximetry, BMI, and BSA panel - HL7.CCDAr1.1 from the LOINC server, it will use the code 74728-7 and create a url of:

https://example.fhir.nhs.uk/Questionnaire/74728-7

This url is used in FHIR QuestionnaireResponse and Validation.

To find, update, add or delete the Questionnaire please see Demonstration Server

This Questionnaire can now be used by FHIR Validation to check FHIR QuestionnaireResponse resources.

2. Completing the Form

FHIR does not define or dictate how an application should store it's completed forms. It does suggest methods of sharing the completed forms with others providers and applications. The idea here is standardising the API so that the persisted forms can be shared (at scale) within the NHS and Social Services.

The common format of the completed forms in FHIR is a FHIR QuestionnaireResponse.

UKCore-QuestionnaireResponse

The XML and JSON schema for this is the same as international FHIR QuestionnaireResponse. Note: UKCore is not a schema, it is data rules which build on top of HL7 FHIR schema.

These QuestionnaireResponses SHOULD follow the definition of the forms in a FHIR Questionnaire. In Structured Data Capture, the management of these definitions is called Form Manager and this has been partly discussed in 1. Creating the Form

To see what the QuestionnaireResponse looks like we will use another application from NLM LHC FHIR Tools.

1. Under Featured Forms
2. Select Vital Signs Panel
3. Enter some data into the form
4. Click on Show Form Data As and select SDC QuestionnaireResponse
5. Copy the JSON response.

Note: This step is simulating a practitioner or patient completing the form and then the application converting the response to FHIR.

We need to make some changes to this so that it can be stored on the UKCore Hackathon server.

1. Open up the FHIR Validator
2. Click 'Try it out`
3. Remove the profile entry, we are going to use the default profile configured in the validator.
4. Paste in the JSON from the earlier steps and click execute.

The result should look something like this

{
  "resourceType": "OperationOutcome",
  "issue": [
    {
      "severity": "error",
      "code": "processing",
      "details": {
        "coding": [
          {
            "system": "http://hl7.org/fhir/java-core-messageId",
            "code": "Validation_VAL_Profile_Minimum"
          }
        ]
      },
      "diagnostics": "QuestionnaireResponse.questionnaire: minimum required = 1, but only found 0 (from https://fhir.nhs.uk/StructureDefinition/NHSDigital-QuestionnaireResponse)",
      "location": [
        "QuestionnaireResponse",
        "Line 1, Col 2"
      ]
    },
    {
      "severity": "information",
      "code": "processing",
      "details": {
        "coding": [
          {
            "system": "http://hl7.org/fhir/java-core-messageId",
            "code": "Questionnaire_QR_Q_None"
          }
        ]
      },
      "diagnostics": "No questionnaire is identified, so no validation can be performed against the base questionnaire",
      "location": [
        "QuestionnaireResponse",
        "Line 1, Col 2"
      ]
    }
  ]
}

This says we need to supply a QuestionnaireResponse.questionnaire entry. From earlier steps when we added the Questionnaire to the server, this is entry is https://example.fhir.nhs.uk/Questionnaire/74728-7 If we amend the JSON (see below) and try validating again this time it passes.

{
    "resourceType": "QuestionnaireResponse",
    "status": "completed",
    "authored": "2023-02-24T07:29:15.300Z",
    "questionnaire": "https://example.fhir.nhs.uk/Questionnaire/74728-7",
    "item": [

The Demonstration Server will now accept this form and store it. If you wish to try this out use POST /QuestionnaireResponse

We have one big omission, it has not been linked to a Patient. To do this we need to add in a reference to the Patient or an identifier for the patient. For this example we are going to use the patients NHS Number which is an identifier. In addition to the patient identifier we add in an identifier for the form itself, the hackathon server uses this identifier to prevent duplicate entries.

{
  "resourceType": "QuestionnaireResponse",
  "status": "completed",
  "authored": "2023-02-24T07:29:15.300Z",
  "questionnaire": "https://example.fhir.nhs.uk/Questionnaire/74728-7",
  "identifier": {
    "system": "https://tools.ietf.org/html/rfc4122",
    "value": "56694b60-f3ba-4214-9868-d63d649f4bf0"
  },
  "subject": {
    "identifier": {
      "system": "https://fhir.nhs.uk/Id/nhs-number",
      "value": "9876543210"
    },
    "display": "R Kanfeld"
  },
  "item": [

This server is configured to accept NHS Number identifiers, an alternative (and common approach in FHIR) is the use references. This gives the following:

{
  "resourceType": "QuestionnaireResponse",
  "status": "completed",
  "authored": "2023-02-24T07:29:15.300Z",
  "questionnaire": "https://example.fhir.nhs.uk/Questionnaire/74728-7",
  "identifier": {
    "system": "https://tools.ietf.org/html/rfc4122",
    "value": "56694b60-f3ba-4214-9868-d63d649f4bf0"
  },
  "subject": {
    "reference" : "Patient/073eef49-81ee-4c2e-893b-bc2e4efd2630",
    "display": "R Kanfeld"
  },
  "item": [

Add the resource to the Demonstration Server via POST /QuestionnaireResponse

3. Existing data and FHIR Observations

The previous section described how a form was completed and then stored/sent to a FHIR Server or recipient. This capability will obviously reduce time spent completing forms.

For example: A Questionnaire which asks for the patients weight will query an EPR data source for the data via a query like GET /Observation?patient=073eef49-81ee-4c2e-893b-bc2e4efd2630&code=27113001&date=gt2022-02-15 This returns any body weight observations in the specified time period.

The person completing the form may enter in a new body weight, in this case a body weight Observation should be stored in the EPR so that it can be reused in the next form. This is done by calling POST /QuestionnaireResponse/$extract which will return a FHIR Transaction contain FHIR Observation which can then be used to add the Observations to an EPR server.

These two concepts are described in

• Form Population which uses a FHIR Questionnaire to automatically retrieving existing patient data as a pre-populated FHIR QuestionnaireResponse.
• Form Data Extraction which processes a completed FHIR QuestionnaireResponse into a FHIR Observations for storing on an EPR Server.

Demonstration Application

The US National Library of Medicine has produced a Structured Data Capture Demonstration of this process. This link is configured to use this UKCore Reference Implementation and can be configured to use other FHIR Servers. Servers will need to implement the following interactions

4. Render Form

A software supplier will normally build a form/application which implements this Questionnaire definition. It is useful to view what this would look like before this development takes place and this will allow feedback on the form.

The NLM/LHC has a useful application for doing this.

NLM LHC Questionnaire Viewer

You will need to supply the Questionnaire to this app. We will use a different version of the Vital Signs questionnaire which has been converted to use UK SNOMED CT Vital Signs Findings.

For this Questionnaire the url is:

https://3cdzg7kbj4.execute-api.eu-west-2.amazonaws.com/poc/events/FHIR/R4/Questionnaire/0d9fccea-9c98-4e61-b3e0-bc9b3a9db675

The id which is the last part of this url can be found in the stored Questionnaires on the Demonstration Server. E.g. When we searched for https://example.fhir.nhs.uk/Questionnaire/VitalSignsFinding the response contained an entry like

  "entry": [
    {
      "fullUrl": "https://3cdzg7kbj4.execute-api.eu-west-2.amazonaws.com/poc/events/FHIR/R4/Questionnaire/0d9fccea-9c98-4e61-b3e0-bc9b3a9db675",
      "resource": {
        "resourceType": "Questionnaire",
        "id": "0d9fccea-9c98-4e61-b3e0-bc9b3a9db675",

The id field is the id we need to use.

5. Sharing Completed Forms

1. Search for the patient by NHS Number GET /Patient. This is preconfigured to search for a Patient with a NHS Number of 9876543210
2. Find the id of the patient (e.g. 073eef49-81ee-4c2e-893b-bc2e4efd2630)
3. Search for patient forms. GET /QuestionnaireResponse
4. Enter in the id of the patient (e.g. 073eef49-81ee-4c2e-893b-bc2e4efd2630)
5. Click execute and the patients forms are returned.

Note: At the time of writing the support for paging a large number of results has only been implemented and use of the secure version of the FHIR may be required.

Ask for Form Completion

Is based on FHIR Workflow and FHIR Structured Data Capture Workflow

Overview

1. The organisation or practitioner who wishes a form to be completed, will first find the form on a registry called Form Manager. See GET /Questionnaire. If the forms does not exist see 1. Creating the Form
2. A request is made to the service, patient or practitioner to complete the form. This is assumed to be via a FHIR Task resource, see POST /Task
3. The form is completed and the results stored on a repository. See 2. Completing the Form
4. The FHIR Task is updated to be completed, see PUT /Task