FHIR Implementation Guide OBC version

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, Outcomebased Care (OBC, Dutch: Uitkomstgerichte zorg), version . This IG is developed using HL7 FHIR R4. It assumes that the reader is familiar with both the functional specification [TO-ADD link] and this version of FHIR. This information standard is inspired by the international [Structured Data Capture (SDC)](http://hl7.org/fhir/us/sdc/index.html) 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 currently 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. The plan is 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 questionnaire and response data within the OBC pilot version is not based on any publication of the Dutch Health and Care Information Models (Dutch: ‘zorginformatiebouwstenen’ or ‘zibs’), as there are no zibs that represent the building blocks included in the pilot. 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

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

The primary purpose of representing PROMSs 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 QuestionnaireResponses to their corresponding Questionnaires.

The Questionnaire resource isn't strictly necessary to create a QuestionnaireResponse. However, using Questionnaire instances for PROMs provides significant benefits through standardized and structured formatting. Each question is included in the Questionnaire and uniquely identified by the Question Reference linked to the .item.linkId elements. 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 programmers.

Furthermore, the Questionnaire instances offer limited capabilities for rendering in the user interface of the PROMs provider platform. They primarily allow different formatting styles and specify how instructions should be displayed as read-only.

2.2.2 QuestionnaireResponse

The collection of outcomes and scores of PROMs is represented in a FHIR QuestionnaireResponse profile. For every completed PROM, an instance conforming to the obc-QuestionnaireResponse 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, you don't need access to the Questionnaire 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-QuestionnaireResponse

Note the following:

• Each Questionnaire profile is represented by a unique questionnaire and is not included as a building block or subsequent resource. Instead, these the FHIR Questionnaire instancesare added as MISSING instances to the FHIR package.

2.3 Mappings between profiles and data set

2.3.1 Questionnaire instance

Each instance of a FHIR Questionnaire contains the following elements:

Type	Concept	Mapping
uri	Questionnaire Coding system	Questionnaire.Coding.system
code	Questionnaire code	Questionnaire.Coding.code
string	Questionnaire code display	Questionnaire.Coding.display
string	Title of Questionnaire	Questionnaire.title
string	Publisher information	Questionnaire.publisher
string	Version of Questionnaire	Questionnaire.version
code	Language of Questionnaire	Questionnaire.meta.language
coding	Domain code of Questionnaire	Questionnaire.usageContext.code
any	Domain of Questionnaire	Questionnaire.usageContext.value
markdown (string)	License/Author information	Questionnaire.copyright
string	Instructions for a question or group of questions	Questionnaire.item.text
boolean	Read-only instructions for a question or group of questions	Questionnaire.item.readOnly
??coding	Instruction format	Questionnaire.item.extension:renderingStyle??
string	Question	Questionnaire.item.text
code	Value type of question	Questionnaire.item.type
coding	Flag for sensitive questions	Questionnaire.item.linkId.extension:sensitivityFlag
??coding	Question format	Questionnaire.item.extension:renderingStyle??
string	??Score rating for questionnaire??	Questionnaire.item
boolean	Read-only score rating	Questionnaire.item.readOnly
boolean	Hidden score rating	Questionnaire.item.extension:hidden
string	Total score for questionnaire	Questionnaire.item
boolean	Hidden total score	Questionnaire.item.extension:hidden
string	Score calculation rules for questionnaire	Questionnaire.item
boolean	Read-only score calculation rules	Questionnaire.item.readOnly
boolean	Hidden score calculation rules	Questionnaire.item.extension:hidden
string	Interpretation score calculation rules for questionnaire	Questionnaire.item
boolean	Read-only interpretation score calculation rules	Questionnaire.item.readOnly
boolean	Hidden interpretation score calculation rules	Questionnaire.item.extension:hidden

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-').

Type	Id	Concept	Cardinality	Profile	Mapping
	1405	Antwoordgegevens	0 .. *	obc-QuestionnaireResponse	QuestionnaireResponse
Any??	14??	Vraag	0 .. 1	obc-QuestionnaireResponse	QuestionnaireResponse.item??
Any	1404	Antwoord	0 .. 1	obc-QuestionnaireResponse	QuestionnaireResponse.answer.value[x]
dateTime	1406	InvulDatumTijd	0 .. 1	obc-QuestionnaireResponse	QuestionnaireResponse.authored
reference	1407	Onderwerp	0 .. 1	obc-QuestionnaireResponse	QuestionnaireResponse.subject
reference	1440	IngevuldeVragenlijst	0 .. 1	obc-QuestionnaireResponse	QuestionnaireResponse.questionnaire

2.4 Rendering

Every PROM may include instructions and questions with specific formatting to emphasize certain information. As a result, different styles can be rendered for particular items.

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-style extension. This extension allows the full capabilities of the HTML style attribute to be applied to items in a questionnaire, such as changing font or color, and adjusting font styles like bold, italics, or small caps. Conformant systems may ignore this extension unless the rendering-styleSensitive flag is set to true.

The JSON snippet below is an example of a Questionnaire instance that contains the rendering-style extension to make the item partially bold.

[INSERT SNIPPET]

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?. To accurately analyse PSOM (PROMs Standard Operating Model) data, it is crucial to determine which version of the PROM was filled out by the subject. This can be done by matching the PROM version with the Amigo reference number.

In FHIR, the version of a PROMs can be registered in the Questionnaire.version element. A Questionnaire is referenced from 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 PROMs 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.
• Amigo will be responsible for assigning version numbers to ensure these reflect a consistent standard approach for the organisation.

2.6 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.linkId.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.7 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, the plan is to incorporate dynamic calculation rules using structured data capture, making the Questionnaire more structured and flexible.