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.