Stream: implementers
Topic: Narrative and generated vs additional
Jenni Syed (Mar 08 2018 at 19:23):
We ran into this question internally and wanted to check with the group. When we build our Narratives, we have several that include fields that are simply "code" in FHIR. For these, most of the time we were looking up the display for that code/system in the Narrative. This isn't in the actual body of the FHIR resource anywhere, but we think this still matches the idea of "generated"
Jenni Syed (Mar 08 2018 at 19:25):
However, if we take that idea one step further... what happens if we pulled the display from our internal display? This would be equivalent to a .text field if the field was a codeableConcept, and it's often what matches how we would display it internally. Is this still "generated?"
Lloyd McKenzie (Mar 08 2018 at 19:39):
The question is - could a receiving system render the data itself and suppress the narrative and have the user safely informed of what's going on. Looking up an external display where the amount of information in the display isn't different than the default display should therefore be fine. On the other hand, looking something up and adding a bunch of extra information would count as "additional".
Lloyd McKenzie (Mar 08 2018 at 19:40):
So, for example, looking up a code and returning the drug name would be fine. But returning a list of the active ingredients and generic alternatives with prices would definitely be "additional"
Jenni Syed (Mar 08 2018 at 19:51):
The most common example of this for us is the resource status. So, taking MedicationRequest.status. If entered-in-error, the "standard" display is Entered in Error. In our System, this is usually displayed as "Voided with Results" or "Cancelled" (depending on workflow). It can be more specific as a display, but the underlying FHIR coded status is the same.
Jenni Syed (Mar 08 2018 at 19:52):
and since a "code" field can never provide a display within the body of the resource, this is a bit different than the example above - that's a codeable concept and the first part you mention may be a "display" while the second could conceivably (maybe not correctly?) be provided as text on the Medication.code field.
Lloyd McKenzie (Mar 08 2018 at 19:52):
Would seeing your display name cause an end-user to make a different decision than if they saw the standard FHIR display name?
Jenni Syed (Mar 08 2018 at 19:53):
code is a bit overloaded here...
Jenni Syed (Mar 08 2018 at 19:55):
If they would make a different decision, then we already have an issue with the status value set...
Jenni Syed (Mar 08 2018 at 19:55):
b/c that would indicate it isn't granular enough. The narrative is the fallback, not the primary way to show things to the user. Most of our apps don't use our narrative at all.
Lloyd McKenzie (Mar 08 2018 at 20:41):
If suppressing the narrative wouldn't cause an issue, then I wouldn't call it 'additional'
Brian Postlethwaite (Mar 08 2018 at 21:25):
If there is a finer granularity, we would select the closest, and have an extension for the more detailed status.
Jenni Syed (Mar 08 2018 at 22:27):
Agreed Brian.
Brian Postlethwaite (Mar 08 2018 at 23:39):
But I'm happy with what you're doing with Narrative, we'd probably do the same thing.
Jenni Syed (Mar 09 2018 at 00:22):
Ok, now one more question. What about when the narrative is in a different language than the resource itself? :)
Lloyd McKenzie (Mar 09 2018 at 02:02):
I think that's not a great idea. The language of the data and the narrative should be the same. We allow translations of strings. I don't know if we've explicitly provided for the notion of translations of Narrative - but I'd certainly be in favor of us allowing that. (And if we're going to make a major change like that, this is certainly the time to raise it...)
Jenni Syed (Mar 13 2018 at 20:47):
@Lloyd McKenzie We're doing this for narrative in limited situations. Following this: http://hl7.org/fhir/dstu2/narrative.html#id (right above this section)
"The narrative content SHOULD be in the language of the resource, but there is no reason to expect that HTML type tooling would understand the resource language element. For this reason, a lang attribute on the <div> SHOULD also be used (see the note in the HTML 5 specification about use of language )."
Jenni Syed (Mar 13 2018 at 20:48):
Reasoning: if the app doesn't understand the resource, the narrative should hopefully be in the end user's lang, assuming there is one provided. We assume that if the app understands the resource, they would be doing number formatting/translation of labels for their own display
Jenni Syed (Mar 13 2018 at 20:49):
Hopefully, most of the time the language of the resource and the narrative are the same... But I can see this being needed for consumer views of FHIR data. I saw the other thread on narrative translation
Jenni Syed (Mar 13 2018 at 20:49):
https://chat.fhir.org/#narrow/stream/conformance/subject/Translation.20of.20Narratives
Jenni Syed (Mar 13 2018 at 20:51):
But what do we do in the meantime, when we receive a different request via headers? It's the number and date formats I worry about most. I feel like words being in the wrong language is really less of an issue, honestly, because that's usually pretty obvious
Jenni Syed (Mar 13 2018 at 20:54):
But looking at just: Ibuprofen 100 mg 1-2-2010...
Jenni Syed (Mar 13 2018 at 20:54):
It's english...
Jenni Syed (Mar 13 2018 at 20:54):
or at least interpretable that way :)
Jenni Syed (Mar 13 2018 at 20:54):
But what exactly is that date? :)
Last updated: Apr 12 2022 at 19:14 UTC
