Narrative in FHIR Document sections

At yesterday’s Accenture event in San Antonio we had an entertaining discussion on how to present narrative in sections of a FHIR document. It’s definitely not immediately obvious that FHIR is quite flexible about dealing with such text, so I’ll share the gist of yesterday’s discussion with you.

First and foremost, it’s important to realize all FHIR documents are built out of Resources, and every resource has support for a human-readable text describing (or augmenting) the structured data present in the resource. In fact, and this is less evident, Resources may contain only narrative when that’s applicable, e.g. when data about a prescription has only been dictated or input into a EMR as text. The fact that human narrative is the only available material for such a prescription doesn’t make the Resource you’d you choose to represent that text in any way less a true “MedicationPrescription”, you just don’t have the supporting structured representation.

Now, I am not saying that you should do natural language processing to analyze a written piece of text entered by a physician to derive the type of Resource you’d need to represent that narrative. In most cases, when text is input into a system, this is still done in a digital on-screen form or part of the application where it’s absolutely clear that the physician is entering a prescription. Failing even that basic premise we’d have to represent that text within FHIR’s catch all fallback resource “Other”. Which is entirely applicable when there’s no context available for such a piece of narrative.

It should by now become clear that when you’re filling out a prescription or careplan section in a FHIR CCD document,  and the only thing you have available is text, you won’t put this narrative in an element of a FHIR document section itself, you’ll put it into the appropriate Resource and make that resource the content of such a section. This aligns with FHIR’s principle that messages, documents and exchanges using REST are all based on and composed from the same Resources. Having this text on such a Prescription resource makes it possible to extract it from the document and (if applicable, of course), reuse that Prescription in a message. Vice versa, if such a text-only Prescription would arrive on a REST interface from the authoring system, you could compose it directly into your document. When we would have allowed you to put such text-only data on the section itself, it would not only be bound to just its document context, but we’d also lose the true nature (in this case: the data being a Prescription) of that text.

3 thoughts

  1. I think the key challenge is that the List structure is quite reusable for a lot of different cases where we need List, Bag, Organizer or Section. The challenge for narrative models is that when List is used as Section there is specific need to know that so that you can generate good HTML markup. That way a smart renderer could be created to generate HTML from the resource that properly handles section nesting. If we just use list to handle the section semantics, but list can also address other semantics, it isn’t clear how to handle the HTML generation from the resource.

  2. Lloyd McKenzie on said:

    Well, the rules for List already state that the narrative should include a rendering of the content of the list. So I don’t think it should matter whether the List is going to be used in a Section or not as to what the narrative should look like. We expect good HTML mark-up for all resources – whether in sections or not

  3. It is truly a nice and helpful piece of info. I am happy that you shared this helpful info with us. Please stay us informed like this. Thanks for sharing.

Post a comment

Your email address will not be published. Required fields are marked *

Want to stay on top of Interoperability and Health IT? 

Subscribe to our newsletter for the latest news on FHIR.