Retrieving and rendering a FHIR document

This post is going to be a bit of an anticlimax.

Once we’ve created the FHIR document and saved it via the /mailbox entry point, then we probably want to be able to find it again at some stage (assuming that the reason we saved it was to make it available to others of course). Well, because the server created DocumentReference resources during processing, then we just need to follow the same process that we used when discussing how to retrieve CDA documents using XDS principles – i.e. query the DocumentReference end point, and then get the document using the location property of the individual DocumentReference resource.

Easy. (Though implementing privacy will add wrinkles to that)

And rendering the document? Well, the spec has the rules for that. To quote:

When the document is presented for human consumption, applications must present the collated narrative portions of following resources in order:

1. The Composition resource
2. The Subject resource
3. Resources referenced in the section.content

The composition narrative should summarize the important parts of the document header that are required to establish clinical context for the document (other than the subject, which is displayed in its own right). To actually build the combined narrative, simply append all the narrative <div> fragments together.

The attested content of the document is the composition, the subject, and the resources referenced in the sections. Additional resources can be included in the bundle, but these are not attested content. Specifically, the attester attests to the presented form of the document.

Note that there are some style rules about rendering the Narrative (which is a subset of XHTML) – though these can be over-written of course by the rendering system using a local stylesheet, and it is also possible for the sender to specify a style sheet to use – this is all mentioned in the spec, so I won’t repeat it here.

Note also that it is requirement that all resources references by the composition are physically within the bundle.

I suspect that document rendering is something that will probably receive further attention post-DSTU when effort turns to converting between CDA and FHIR documents. For example:

• Consider the medication list which has both a List resource and multiple MedicationPrescription resources. All of these resources have narrative properties – how much should be in each to avoid duplicated rendering?
• What if sections are nested, or have List resources referencing other List resources – how do we render that (and does it make sense)?

In the longer term (say next year – this is FHIR-time remember!) there’s a possible future that has FHIR documents and CDA effectively merging, with CDA release 3 being CDA content expressed as profiles on FHIR resources – that way we keep the huge business knowledge represented by CDA, with the simplicity of representation and implementation that FHIR brings.

We can only hope…