uz:V1.0.0-alpha.1 FHIR OBC

This FHIR IG is currently under development and can not be considered stable and ready for use. For questions and change requests regarding this IG, please create a ticket in BITS.

1 Introduction

This implementation guide (IG) functions as the initial draft for the pilot phase of a new information standard, Outcome-Based Care (OBC, Dutch: Uitkomstgerichte zorg), version 1.0.0-alpha.1. This IG is developed using HL7 FHIR R4. It assumes that the reader is familiar with this version of FHIR. This information standard is inspired by the international Structured Data Capture (SDC) implementation guide and tries to follow it where possible.

Apart from this document, the guidelines as specified in the general FHIR Implementation Guide apply. In particular, the reader should take note of the Overarching principles and the use of FHIR packages.

This IG first describes the boundaries and relationships in place, after which the implementation of PROMs in FHIR is described.

2 Boundaries and relationships

2.1 Boundaries

As mentioned in the introduction, this IG serves as a precursor for the pilot phase of the new information standard OBC. This version of the IG focuses solely on the manifestation of PROM questionnaires and their corresponding answers in FHIR. It does not include clinical data or use cases for data exchange, as the primary goal of the pilot is to evaluate the feasibility of implementing FHIR in this context. It is the intention to expand the scope in future versions of the IG to include clinical data and data exchange use cases, ultimately aiming to develop OBC into a comprehensive information standard.

2.2 FHIR resources and building blocks

The PROM questionnaires and response data building blocks within OBC version 1.0.0-alpha.1 are not based on any publication of the Dutch Health and Care Information Models (Dutch: "zorginformatiebouwstenen" or "zibs"), as there are no zibs that represent these building blocks. Therefore, there is no dependency on corresponding nl-core profiles, and mappings to zib concepts are not defined. Currently, there are no plans to create more general nl-core profiles, as no corresponding zibs exist.

2.2.1 Questionnaire

Each PROM questionnaire is represented through a dedicated FHIR Questionnaire instance. A FHIR Questionnaire is a definitional artifact, which means it defines the questions to be asked, how these should be structured and rendered, and what answers are allowed. More information on structure and rendering of the FHIR Questionnaire instances can be found in section 2.4. The answer options to each question are represented through terminology resources using ValueSets and CodeSystems.

The Questionnaire resource isn't strictly necessary to create a QuestionnaireResponse. However, using FHIR Questionnaire instances for PROMs provides significant benefits through standardized and structured formatting. Each question is included in the Questionnaire as a separate .item and has a unique identifier in the corresponding .item.linkId element. Additionally, the terminology used in PROMs is represented in FHIR ValueSet and CodeSystem resources and is correctly linked to the questions in the Questionnaire, ensuring all definitions are easily accessible for implementers.

2.2.2 QuestionnaireResponse

The collection of outcomes and scores of a PROM is represented in a FHIR QuestionnaireResponse profile. For every completed PROM, an instance conforming to the obc-ResponseData profile is created. This profile features a structured set of answers with linked ids to the answered questions. The QuestionnaireResponse also includes the completion date and the language of the completed form.

The QuestionnaireResponse contains enough information about the questions asked that it can be interpreted somewhat independently from the Questionnaire it is based on. In other words, no access to the Questionnaire is necessary in order to extract basic information from a QuestionnaireResponse.

2.2.3 Main building blocks

Building block (EN)	Building block (NL)	FHIR resource	FHIR profile
ResponseData	Antwoordgegevens	QuestionnaireResponse	http://nictiz.nl/fhir/StructureDefinition/obc-ResponseData

Note that each PROM questionnaire building block in the functional data set is represented by a separate Questionnaire instance. However, these are not listed here, but are instead added as MISSING instances to the FHIR package.

2.3 Mappings between profiles and data set

2.3.1 Questionnaire instances

Each FHIR Questionnaire instance includes specific elements that correspond to functional definitions in the ART-DECOR dataset. This dataset offers a concise overview of the content and structure of each questionnaire. The actual mapping of FHIR elements to these functional definitions occurs at the "Scenario" and "Rules" levels within ART-DECOR. However, the following table presents the dataset's structure, independent of the mappings to the "Scenario" and "Rules" levels:

Concept in Dataset	Mapping	Type	Remark
Metadata
Vragenlijstcode	Questionnaire.code	string
Naam vragenlijst	Questionnaire.title	string
Eigenaar/Uitgever	Questionnaire.copyright	string
Versie	Questionnaire.version	string
Taal	Questionnaire.meta.language	code
Domein	Questionnaire.useContext.valueCodeableConcept	coding	Questionnaire.useContext.code must be populated with the code focus
Licentie-informatie	Questionnaire.copyright	markdown (string)
Content Questionnaire
Instructie	Questionnaire.item.text	string	Questionnaire.item.readOnly must be set to true
Question	Questionnaire.item.text	string
Totaalscore	Questionnaire.item.text	string	Questionnaire.item.extension:hidden must be set to true
Rekenregels
Scorerichting item	Questionnaire.item	string	Questionnaire.item.extension:hidden must be set to true
Scoreberekening	Questionnaire.item	string	Questionnaire.item.extension:hidden must be set to true
Interpretatie score	Questionnaire.item	string	Questionnaire.item.extension:hidden must be set to true

Additionally, instances include concepts that are not directly represented in the dataset, such as formatting. Instead, these concepts are found within the "Rules" level in ART-DECOR:

Concept in Rules	Mapping	Type
Canonical URI	Questionnaire.url	uri
Content Questionnaire
Instructie	Questionnaire.item.extension:renderingMarkdown	string
Question	Questionnaire.item.extension:sensitivityFlag	coding
Question	Questionnaire.item.extension:renderingMarkdown	string

• For this project, it has been agreed to map all functional data elements to the operationalization fields in ART-DECOR.
• The publisher concept is mapped to .publisher. This concept is consistent across the project and remains unchanged for all Questionnaire instances.
• The concept of "Eigenaar/Uitgever" (English: Author/Publisher) is mapped to .copyright. This is because the concept encompasses author information, which lacks a dedicated field in the Questionnaire resource. The .copyright field addresses both author and license information for this project.
• For this pilot, "Content Questionnaire" includes the following content folders: Content NRS-pijn intensiteit, Content FACIT-F, IBD-control, Content Depressie SF 4a, and Content Global Health-10.
• The "Question" refers to each individual element within the Instructie folder.
• The "Instructie" data (English: Instruction) has been set to read-only, because it is intended for users to read, not to respond to. The "Rekenregels" data (English: Calculation rules) is hidden from users, as it is used for calculations, comparing results, and providing context on the scores.

2.3.2 QuestionnaireResponse profile

The QuestionnaireResponse profile is connected to the functional definitions in ART-DECOR. It includes mappings to all data elements within the functional data set (prefixed with "obc-dataelement-10-").

Each profile (implicitly; this will be explicitly added in a subsequent version) contains a Patient building block with cardinality 1..1 M. This patient is the subject of the PROM questionnaire, and is referenced from the ResponseData building block. Therefore, a reference to a Patient resource conforming to the nl-core-Patient profile is expected in QuestionnaireResponse.subject.

2.4 Questionnaire URL

The primary purpose of representing PROMs as Questionnaire instances is to establish a canonical identifier for each PROM in the form of a URI. This URI serves as a linkage point connecting every QuestionnaireResponse to their corresponding Questionnaire. A Questionnaire is referenced by other resources using its canonical URL, which is composed of a base URL followed by a UID generated by ART-DECOR:

http://decor.nictiz.nl/fhir/Questionnaire/2.16.840.8.113882.1.2.3.44.60.140.27.9--12345673145430

2.5 Questionnaire versioning

PROMs are subject to change over time, with alterations or additions made to their questions and answer options, as well as to the underlying algorithm used to calculate the scores. Any changes made to these PROMs are recorded and disseminated through ?Amigo?. Since PROMs might develop through time, it is crucial to determine which version of the PROM was filled out by the subject.

In FHIR, the version of a PROM can be registered in the Questionnaire.version element. A Questionnaire is referenced in a QuestionnaireResponse (and possibly other resources) by its canonical URL. To reference a particular version of a Questionnaire, users must combine the canonical URL and version using a pipe character in the format: [canonicalURL]|[version]. When users refer to a Questionnaire with just the .url, they automatically refer to the latest version.

However, the definition of "latest version" may vary for Amigo compared to what the PROMs provider may consider latest. Therefore, to ensure clarity about which version of the PROM is requested and collected, any references in the QuestionnaireResponse.questionnaire SHALL always include a specific version.

To note:

• The assumption is that all PROMs will be registered with a version number.
• Questionnaire Authors/Publishers will be responsible for assigning version numbers to maintain a consistent standard across the organization. Amigo will ensure that these versions are kept up to date.

2.6 Rendering

A PROM questionnaire may take the form of a straightforward flat list of questions, but may also be hierarchically organized in groups and subgroups including patient instructions. Likewise, it can contain a wide range of question types, varying from simple fill-out fields to multiple-choice questions, scales and questions with dependencies to previous answers. As a result, it might be necessary to render items in a questionnaire.

The FHIR base Questionnaire resource offers limited rendering capabilities, with item labels and text elements displayed sequentially, and choice options provided through renderer-determined controls. For more control, the core specification defines additional elements and extensions, including the rendering-markdown extension, which leverages GitHub Flavored Markdown (GFM) for text formatting, like adding emphasis. While systems aren't required to support markdown, strings should remain readable without markdown processing.

The JSON snippet below provides an example of a Questionnaire instance that uses the rendering-markdown extension to emphasize part of an item.

{
  "item": [
    {
      "linkId": "1.2",
      "code": [
        {
          "system": "http://loinc.org",
          "code": "12345-6"
        }
      ],
      "text": "Little interest or pleasure in doing things",
      "extension": [
        {
          "url": "http://hl7.org/fhir/uv/rendering-markdown/StructureDefinition/rendering-markdown",
          "valueMarkdown": "**Little** interest or pleasure in doing things"
        }
      ],
      "type": "string",
      "required": true
    }
  ]
}

2.7 Sensitive questions

Every PROM may include sensitive questions, indicating that the answers might contain sensitive information. As a result, a specific level of authorization is required to read these answers.

The Data Segmentation for Privacy project defined the Inline Security Label extension. This extension enables flagging elements with a security label, for example indicating their sensitivity, and SHALL be added to all relevant .item elements as .item.extension:sensitivityFlag in both the Questionnaire and QuestionnaireResponse instances. The .valueCoding SHALL be populated with the code PDS from the InformationSensitivityPolicy ValueSet to indicate this data item contains sensitive information reported by the patient.

2.8 Scores and calculation rules

The Questionnaire definition includes information on how to calculate the total score, the weight for each question, and how to interpret the total score. Currently, this information is provided in .item elements, where the calculation rules are read-only instructions and hidden from users completing the forms through an extension.

In the next version of the Questionnaire definition, it is the intention to incorporate dynamic calculation rules using structured data capture, making the Questionnaire more structured and flexible.

3 Use cases

3.3 Use case: send questionnaire response

3.3.1 Client renders questionnaire form

The X should present the questions defined in the retrieved Questionnaire resource to the user, in accordance with their type, overall structure of the questionnaire, and restrictions on the answers. OBC defines the following minimal subset of Questionnaire item types that a X MUST support:

• Group
• Display
• Boolean
• Decimal
• Integer
• Date / dateTime / time
• String / text
• Choice / open-choice, where the possible answers are defined using option elements
• Quantity

The following elements of the Questionnaire.item element MUST be supported:

• Questionnaire.item.enableWhen
• Questionnaire.item.required
• Questionnaire.item.readOnly
• Questionnaire.item.option

In addition, the following extensions MUST be supported:

• translation
• hidden
• markdown
• itemControl
• minValue
• maxValue
• minLength
• maxDecimalPlaces
• unit

A X MAY support other Questionnaire item types as well. However, if a PHR is unable to process any one part in the Questionnaire, it MUST reject the Questionnaire altogether, see below. HIER GEBLEVEN Note: for known questionnaires, a PHR may choose to use hardcoded over generated forms. However:

• A PHR implementing this information standard should always be able to generate a form for the minimal Questionnaire requirements.
• Currently, no coding system exists to identify known questionnaires. Known questionnaires might be recognized by the reference in the QuestionnaireProvisioningTask or by the Questionnaire.url field, which presents the canonical URL for the Questionnaire resource (even if it served elsewhere). Although the URL in the XIS reference or Questionnaire.url MUST be version specific, the PHR MUST check whether the referenced Questionnaire resource matches the one it has hardcoded

3.3.2 Multiple-choice questions in FHIR

Unfortunately, the FHIR core documention for the Questionnaire and QuestionnaireResponse resources is somewhat confusing and actually contains an error in the topic of multiple-choice questions. This section is meant to clarify the use of multiple-choice type questions in FHIR STU3.

In FHIR STU3 there are two scenarios for multiple-choice questions: in the first scenario, the answer MUST come from a list of predefined options, while in the second scenario, the user MAY alternatively provide a custom answer. In a Questionnaire resource, to define a multiple-choice question, item.type MUST be set to "choice" for the first scenario, or "open-choice" for the second scenario. The answer options MUST be defined using either:

• The Questionnaire.item.options element, which contains a reference to a ValueSet with the possible answers. Note: support for this mechanism is not required for this information standard.
• Using one or more Questionnaire.item.option elements, with possible answers defined as valueCode. Note: although the Questionnaire resource defines item.option.value[x] as a polymorphic element with multiple types, only coding is actually allowed. In the relevant profile, this element is therefore restricted to the coding type.

Likewise, the QuestionnaireResponse resource should capture the answer using QuestionnaireResponse.item.answer.valueCode:

• If the user selects one of the predefined answers, it should be captured in the answer using the code (and if present, system) elements of the valueCode.
• If the question is of type "open-choice" and the user provides an alternative answer, it should be captured using the display element of the valueCode.

Questionnaire example:

<item>
    <linkId value="example"/>
    <text value="Example question"/>
    <type value="choice"/>
    <option>
        <valueCoding>
            <code value="EO1"/>
            <display value="Example option 1"/>
        </valueCoding>
    </option>
    <option>
        <valueCoding>
            <code value="EO2"/>
            <display value="Example option 2"/>
        </valueCoding>
    </option>
</item>

QuestionnaireResponse example:

<item>
    <linkId value="example"/>
    <answer>
        <valueCoding>
            <code value="EO1"/>
            <display value="Example option 1"/>
        </valueCoding>
    </answer>
</item>