Stream: questionnaire
Topic: Markdown
Paul Lynch (May 01 2019 at 17:21):
https://www.hl7.org/fhir/extension-rendering-markdown.html says it applies to "Element ID string". Does that mean any string field in the Questionnaire resource definition could potentially use this markdown extension? We could not find a direct reference to this extension in SDC, except via rendering-styleSensitive.
Lloyd McKenzie (May 01 2019 at 17:29):
The extension can show up on any string in any resource. We haven't referenced it in SDC because we chose to use HTML exclusively if you want to add markup cababilities. That said, there's also a proposal for R5 to change item.text from string to markdown in the core spec - which would eliminate the need for that extension on Questionnaire entirely.
Brian Postlethwaite (Oct 06 2021 at 20:58):
Have we considered answers in markdown format for rich content?
Could we use the markdown or html extension on the string answer value there?
And maybe an item-control value(s) for rich-text-md and rich-text-rtfand/or rich-text-html
Brian Postlethwaite (Oct 06 2021 at 20:59):
I don't like the idea of the item.text being markdown outside the extension, as that implies more processing on every item which may not be intended/needed - I missed this change - don't like it.
Makes additional effort for all uses - and the QR.text would also need to change, which is hasn't
Brian Postlethwaite (Oct 07 2021 at 22:28):
This was the original tracker issue for changing Questionnaire.item.text to markdown was:
https://jira.hl7.org/browse/FHIR-20585
Was voted on in May 2019 (which I missed)
https://confluence.hl7.org/display/FHIRI/FHIR+SDC+Minutes+CC+20190523
and only applied in March 2021 and I've only just noticed it now (as I've been too deep in R4/SDC)
The original issue voters were @Grahame Grieve @Paul Lynch @Ye Wang @Liz Amos @Robinette Renner
My concern is that with this is the additional overhead it adds to processing for every single question while rendering on mobile devices, and specifically where HTML is not being used such as native apps - for every single question/label.
The existing R4 structure was equally as expressive, but had a clean way of knowing if you need to go to the complex rendering area.
Other parts of the core spec where markdown is used are not typically rendered in clinical contexts (conformance style resources with copyright/descriptions) or are a single field or 2, not every single item in the display.
Paul Lynch (Oct 08 2021 at 20:08):
I think support for markdown is still optional. It can be displayed as plain text. The documentation for data type markdown says, "A FHIR string ... that may contain markdown syntax for optional processing by a markdown presentation engine...." The important words there are "may" and "optional".
I do think the inconsistency between Questionnaire.item.text (markdown) and QuestionnaireResponse.item.text (string) should be fixed.
Brian Postlethwaite (Oct 09 2021 at 21:43):
The markdown processor that I use puts additional nodes around itself which messes with layout for just simple content. Which makes me want to pre pircess these questionnaires and put an extension with the plain text in it, which is painful.
Brian Postlethwaite (Oct 09 2021 at 21:44):
It's extra processing at usage time that shouldn't be needed for most items.
Last updated: Apr 12 2022 at 19:14 UTC
