The current documentation of Narrative seems to lack two kinds of safety-related information:

1. While the spec clearly states that narratives must include all relevant information so that can be safely displayed alone, there is no discussion of the considerations when ignoring the narrative and using only the structured information (as is common in e.g. focussed health apps).
2. The spec strongly encourages the inclusion of narratives ("SHOULD") and requires them to be "human-readable". Yet it does not discuss the significant difficulties in generating such narratives fore generic structured data in a clinically safe way (for the typical case where no hand-written narrative is available).

For background and discussion, see this Zulip thread.

The request here is therefore to extend the "Clinical Safety Concerns" of the Narrative documentation to briefly discuss

• Considerations when automatically generating narratives (e.g. simplification for readability vs. clinical safety)
• Considerations for when to make narratives displayable (specifically also the dependence on Narrative.status)

As a starting point, here one possible draft for how this text might look (based on my understanding of the points made in the Zulip thread linked above):

The automatic generation of human-readable narratives based on the core elements in a resource is a complex task. Any narrative generation algorithm must be able to safely handle completely generic resource instances. Mechanisms to optimize readability (e.g. by layout or by combinations of individual element values) must not compromise clinical safety and must be able to deal with all "corner cases".

If safe handling can be guaranteed, systems may choose to work only with the core resource elements and not use the narrative. Attention should be paid to Narrative.status which indicates whether the narrative may contain extra details not captured by the core elements.