Stream: implementers
Topic: Clarification on Narrative
Vincent Goris (Nov 14 2019 at 08:40):
We are unsure on how to interpret the specification on the importance of the narrative. Here (https://www.hl7.org/fhir/STU3/narrative.html) is stated in the first sentence that a narrative ‘may’ be included, however later on it is mentioned that the narrative ‘should’ be included. Can anyone provide us with some clarity on this issue?
Lloyd McKenzie (Nov 14 2019 at 13:27):
There isn't a conformance requirement to send narrative, however, it's certainly good practice in most situations to send it. Narrative provides a fall-back for interpretation of the data when a receiving system doesn't recognize one or more of the extensions (or sometimes even core elements) in the instance. As data propagates from system to system and as systems evolve over time, there's a high likelihood that a resource will eventually reach a system that doesn't recognize all the discrete elements. Having narrative means that a human seeing the resource will still understand all of the key elements. Narrative also makes it easier for systems to evolve independently. If system A is transmitting data to B, C and D, system A can throw in a new discrete element without B, C and D performing a simultaneous (aka 'big bang') upgrade to recognize the element. Instead, they can just make the narrative available to their users in addition to the discrete data and upgrade to support exposing the new element if and when it makes sense for them to do so.
Narrative sometimes can't be transmitted. It creates challenges when anonymizing data. It can also be unnecessary overhead when transmitting to real-time decision support systems that will not involve humans looking at the data or the storage and potential eventual retransmission of the data to systems that might display the data to humans.
Last updated: Apr 12 2022 at 19:14 UTC
