Display Modes

Most of the focus in SDC around the 'display' of QuestionnaireResponses is during the form completion stage. This is the phase when questions, display, and other items are presented to a user for the purpose of collecting information. Population happens either prior to or during this phase, all of the Form Behavior functionality occurs during this phase, and the vast majority of the Form Rendering structures are also used during this process.

However, there is a second phase to the QuestionnaireResponse's lifespan that also involves rendering - displaying a completed form to an end user to allow the captured data to be visually consumed. This representation serves a different purpose. It is no longer trying to capture data in an efficient manner. Instead, it is trying to allow users to consume information in an efficient manner. For this reason, the rendering requirements may differ. This rendering can either be driven by the system consuming the QuestionnaireResponse (by handling the discrete data elements and displaying them on screen in a specific manner), or by the system producing the Questionnaire Response (by determining how the narrative is produced).

In SDC, these two different focuses are referred to as 'usage modes' - `capture` and `display`.

Display rendering approaches

There are four approaches to rendering completed forms defined by SDC: Default, Answers only, Item-controlled, CQL, and Custom-Liquid. These approaches and their pros and cons are described below.

Default Display

The default approach to rendering a completed form is to display it in exactly the same manner as is used for data capture. This is the mechanism most users are familiar with because it is a given for paper forms.

• All groups, display items, and questions are rendered
• Answers appear within the associated entry control structure (selected radio buttons or check boxes, selected items within drop-downs, filled in text-boxes, etc.)
• Where multiple answer choices were available, all permitted choices are exposed, with those that were and were not selected being made visually evident as appropriate based on the control type used.

Depending on the tool performing the rendering, the controls allowing data capture might or might not be 'locked' as read-only. (Note that some read-only controls (e.g. a multi-item dropdown) might not allow a user to see all selected items.)

The benefit of this display mode is that a Form Filler does not need to support more than one rendering approach. It renders completed forms and in-progress questionnaires exactly the same way. Also, if the reader of the QuestionnaireResponse is not familiar with the design of the Questionnaire, they may be interested in knowing what answer choices were available but not selected and what questions were available but not answered.

However, this approach is quite verbose. Displaying user instructions, non-selected answers, and non-answered questions may mean a great deal of scrolling will be necessary to read all answers. This approach can also create confusion about whether the user is in a mode of "form static display" or "form data entry", and there is the possibility the user will unintentionally change data when reviewing the form. Finally, this approach does not support any customization of the display to optimize it for data consumption, such as displaying different items on data review than were visible on data capture, or displaying content with different formatting, text, or order.

This mechanism cannot work for narrative-based rendering because FHIR narrative does not permit the inclusion of active data controls.

Answers Only

In this approach the display of the completed form is more limited. Questions continue to be displayed in order, however only answers provided by the user are visible. Answer choices not selected by the user are not included and questions not answered are omitted. Display items are also omitted. Answers are usually rendered as text strings rather than as item controls such as checkboxes or drop-downs.

This approach is considerably more concise and allows readers to consume all entered information in a more efficient manner. However, as a middle ground, it suffers from two sets of issues. For users who aren't familiar with the Questionnaire design and find the decision to not answer questions or not select particular choices to be as informative as seeing what the user did select, this approach does not display sufficient information. And for users who want a display that is more optimized for consumption, this approach can still result in a presentation that is more verbose and less optimized than other rendering modes. This approach doesn't allow customizing which items are displayed, the item text, item order, or other rendering.

Item controlled

This approach leverages the usageMode extension. This allows a Questionnaire designer to designate whether items should be visible when capturing data, when displaying a completed form, or both. With this approach, it is possible to have display items that govern data capture only appear when performing data capture, but not display when a user is reviewing a completed form. On the other hand, display items that explain how to interpret a completed form might only display when in 'display' mode. The same can be done with question items, or even whole sections. A score calculated based on a set of answers might not be displayed during user-entry to prevent influencing the user's choices, however it could be made available once the form is complete. Calculated answers might allow determining a 'summary' of certain answers for more efficient rendering, while the fine-grained questions covered by the summary might be suppressed.

This approach provides more control over the appearance of items, and with calculated values, can produce relatively compact presentations which may even change the order of the elements or even display assertions dealing with un-answered questions. However, there are still limitations to the compactness of the view as information will still be presented as questions, answers, and display items 'in order'. If there is a desire for custom control of formatting, such as the use of tables or lists that does not rely on attempting to stitch together HTML tags using FHIRPath or CQL expressions, this mechanism may not be sufficiently powerful. Also, this approach means that additional items must be defined in the Questionnaire to handle the custom display. Any additional questions or groups will be included in the QuestionnaireResponse. This may not be desirable if building off a 'standard' Questionnaire with the intention that the resulting QuestionnaireResponses will remain valid against the original base Questionnaire.

Library-driven

​ HL7 defines a generic instance-rendering extension that can be used on certain 'definitional' artifacts that can be instantiated by other resources (e.g. Questionnaires, PlanDefinitions, Measures, etc.) that allows conveying a computable syntax that defines how the content of those resources should be rendered - including the ability to specify what the narrative of instances of those definitions should look like. Examples of potential functionality include:

• Embedding complex rendering structures such as lists, tables, hyperlinks, etc.
• Overriding the text and/or formatting of item text and answer values
• Including conditional logic around what content to expose in what circumstances
• Adjusting the order in which content appears
• Choosing separators when presenting lists of elements
• Controlling whether to display the question text, the answer text, or both
• Displaying different text depending on the value of a boolean element
• Displaying different text based on the sum of a 'score' value
• Choosing when content should appear on separate lines or the same line
• Combining, splitting, injecting prefixes or suffixes, or otherwise manipulating string content

Most importantly, all of these steps can be performed without injecting any additional items into the Questionnaire.

The extension supports any language. However, for Questionnaires, the safest and most appropriate languages for use are either FHIRPath Liquid or CQL.

This approach can produce the most concise and user-friendly rendering of completed forms. Any information about omitted answers or items that is relevant to the consumer can be rendered, while information not relevant can be suppressed. The order and formatting of presentation can be completely tuned to what makes the most sense for a reader. The downsides of this approach are:

1. The form renderer must be able to process the specified language (Liquid, CQL, etc.) or have access to a third party module that can do so
2. The form author either needs to hand-create the code to go with their form or need to embed sufficient metadata in their form to allow custom generation of the algorithm

NOTE: The extension supports other rendering mechanisms as well, so if there were a desire for different renderings for different purposes (e.g. patient consumption, summary, print view, etc.), the extension supports that as well. As well, the Library resource allows for multiple representations of the content, so if a Questionnaire author were unsure which languages downstream Form Fillers could support, it is theoretically possible to convey rendering algorithms in multiple languages.