At the upcoming May HL7 Workgroup Meeting in Phoenix, we will organize the 6th FHIR Connectathon. Track 2 will focus on Questionnaires, so both client and server developers can test their skills at creating and supporting the Questionnaire resource. As well, David Hay has written additional information about it in his blog.
Basically, the Questionnaire can be used both as a medium to communicate filled-out Questionnaires, but it is conceivable -supported even- to exchange “empty” Questionnaires that don’t contain answers. In that case the Questionnaire contains just the questions, including their text, section headings etcetera. It matches the usual “paper” workflow where you send out an empty form, and get the same form back, but than filled with data.
Of course, electronic forms can do much more than their paper counterparts, so you can stuff additional design information about a form into an empty form. Examples are graphic make-up, rules about hiding/showing questions depending on answers given and all kinds of validations. In DSTU1 we went for a general approach where Questionnaire’s basic “core” elements focused on supporting the exchange of answers (adding a few extra elements to include headers and prompt texts), but most other “form design” matter was to go into extensions.
One such extension is “answerFormat“. You can use it on a Question component to indicate the kind of answer you’re expecting (string, number, multiplce choice, etc.), and it mirrors the list of “types” people make up when they build eForms systems like SurveyMonkey or Excelsheets with minimal datasets. This data can be used for basic validation and UI building. No doubt you can go more fancy than this, but it should serve as a start.
Another extension is “mayRepeat”, which is only allowed on Groups of questions. The suggestion was that if you look at forms, you’ll often see repeating groups of questions, often layed in tabular form (with the question text in the column header). On the implementers Skype however, the question rose about how you would go about if you’d like a user to give multiple answers to the same question. Are these repeating questions with a single answer? Or one question with multiple answers?
We concluded that, to stay aligned with the physical counterpart of a Questionnaire, it makes most sense to have multiple answers to a single question. You’re not repeating the question text, nor the header, instead you’re allowing multiple inputs to a question. Multiple answers, however, is not currently supported by Questionnaire’s Question component. To make this work, we are proposing to add an extension “additionalAnswer[x]” of type “decimal | integer | boolean | date | string | dateTime | instant to the “answer[x]” element. This extension works in the same manner as the current “answer[x]” element which, mostly for technical reasons, was limited to 0..1. This extension may repeat, so you can give multiple answers:
<!-- stuff left out -->
<text value="What are your favorite colors?"/>
<valueString value="yellow" />
<valueString value="blue" />
For multiple-choices, you won’t need to use this construction, this is simply done by using the choice element, which may repeat and which represents the coded choices the user made (e.g. one or more codes from LOINC).
Because you’d probably want to limit the number of answers (“name your top three pastimes”), we’ll also add two extension “minCardinality” and “maxCardinality” to Question, both [0..1] of type Integer.
We’ll use these extensions during the connectathon and DSTU1, and any feedback will be fed into the community process leading up to DSTU2.