Creating a FHIR document

A FHIR Document is simply a collection of resources inside a Bundle, with a Composition resource to hold the ‘Document level’ information. clinFHIR has special functionality to support building a document, which is triggered by adding a Composition to the scenario. Here’s a scenario before adding the Composition (a couple of Lists and an encounter):

(Note that we’ve used the ‘hide selector’) to hide the left pane. And here’s the display after the Composition is added:

(Note the new ‘Document’ tab that has appeared next to the ‘Graph’ tab).

Select that tab, and click the ‘Add section’ link. A dialog appears that allows you to select the code for the section (from the valid LOINC codes) and also any text for that section. Here’s a screen shot:

Save the section and you are then able to add resources to that section. In the next screen shot, we’ve clicked the (+) symbol to the right of the Medication list to add it to the section. We don’t need the actual medications to the section (and we shouldn’t), as they are referred to by the medication List.

If we then display the Graph view, we can see that a reference from the Composition to the List has been made automatically. In the next screen shot we’ve added a link to the Problem List, plus a reference from Composition to Encounter. We’ve also hidden the Patient resource (There’s a link just above the graph) – as that can clutter the display.

To view the document structure, select the Tree View subtab (off the ‘Document’ tab, and click the ‘generate tree’ link. Here’s the result:

To view the actual bundle, display the ‘Description’ tab, then the ‘Bundle Json’ – like this.

You can continue to build up your document as you need to. At the time of writing this post, there isn’t a good way to generate the text – that’s coming!



Bundle Visualizer for Trans-Tasman Connectathon

So in the previous post about the upcoming Trans-Tasman connectathon I mentioned that I was going to work on a couple of applications in the IPS track – a way of visualizing IPS documents (actually any kind of FHIR document), and a ‘façade’ application that could produce an IPS document on demand from a back-end data source.

This post is an update of where I’ve got to.

Read more of this post

Managing the Medication List in SNapp, part 1.

So, in the last post we talked about setting up a FHIR server, and populating it with some sample data. Let’s turn our attention now to how we would interact with that server in the context of a ‘Medication List’, and we’ll use the STU-3 release candidate (as used at the recent Baltimore connectathon) as the basis of the discussion, though this should work just as well in older versions.

(Our discussion will generally apply to other lists – such as Allergies and Problem lists – though it’s not uncommon for there to be multiple Problem Lists for a patient that are ‘clinician focussed’ e.g. the list of significant problems from the perspective of a respiratory physician tends to be different to that from the perspective of an orthopedic surgeon. But I digress…)

Read more of this post

Supporting SNapp: Lists of medications

In this post we’re going to look at representing the Medication List using a List resource as part of supporting the SNapp event at the SNOMED conference in New Zealand next month. As we discussed in the last post – this is a preferable, albeit more complex way than just using queries against MedicationStatement resources.

To understand how this works, take a look at this image:


It’s a screen dump from clinFHIR that shows how the List resource in the middle of the graph refers to the individual MedicationStatement resources that are part of the List (as well as the patient). Yes, I know, I really need to work on those colours! Oh, and BTW take a look at this post to see how you can create your own sample patients on a FHIR server

What you can see is that you still need the individual MedicationStatement resources that represent each medication, but you now have an additional resource that adds the extra information about the list – e.g.

  • When the list was created, and by whom.
  • Type of list eg a comprehensive review of all mediations, or just updating it in the context of a specific event (an antibiotic for a fixed period)
  • Medications that have been stopped in this review (you can indicate why they were stopped using an extension)
  • Notes about the list

And we can be explicit about stating that the patient is not taking any medications (as far as we know), plus versioning of the list as it changes.

So lets see how we can do that.

Read more of this post

Accessing lab data via FHIR – part 2

In the previous post we took a look at the overall organization of the resources involved in representing Laboratory tests and what an API to retrieve them might look like.

But the queries that we discussed were rather ‘blunt’ – just retrieving results for a person with minimal filtering. While that’s often needed, being able to make more targeted queries can be a whole lot more useful (especially when we want to chart it or include data into Decision Support routines), and that brings us onto the topic of coding the data – the subject of this post.

Read more of this post

A sense of history with clinFHIR

I’m definitely going to finish off the series on building extensions (we have to cover coded extensions) but I must admit I’ve been a bit sidetracked in the last couple of days. You see we had a call with the ‘Clinicians on FHIR’ team talking about plans for the upcoming event at the WGM in Spain, and during the course of the discussion, Emma asked if clinFHIR could show versions of resources as she wanted to describe medication reconciliation.

At the time I said we could certainly do something like that (though I’ve not yet got that working in the Scenario Builder) but after the call I was thinking about it, and it occurred to me that what we really need is to be able to version scenarios – so we can show how they are built up, and potentially to model a workflow like fulfillment of an order or reconciliation.

So, may I present…

Read more of this post

FHIR Documents (and other stuff)

I had an email from a company which had a number of really good questions about exposing data through FHIR, so I thought I’d write a post about it rather than just replying directly as it may be of interest to others (and also gives others the opportunity to disagree with me 🙂 )

Read more of this post

Building a set of resources in FHIR

One of the primary goals for clinFHIR is to help people who are new to the standard understand how it works – and increasingly these are clinicians whose interest is less in the technology and more about how FHIR can be used to represent the clinical information they wish to exchange.

While the current app does allow this, it has been aimed more at the people actually developing the resources than the casual user, and so can be time consuming to develop sets of resource instances that represent real world scenarios.

The component described by this post (called a simple builder – though a better name is needed!) is intended to allow someone completely new to FHIR to build sets of resources that represent clinical scenarios, to help them understand how the resources can be linked together – rather like Lego is used to build a complete model.

Read more of this post

Supporting the SNOMED SNAPP hackathon

So there’s a ‘hackathon’ (I actually don’t like that word) associated with the SNOMED conference in Wellington next month. They’re calling it a ‘SNAPP’ event (SNOMED App) – which is much nicer!

As part of supporting this event, HL7 New Zealand is going to stand up a server that can be used for the ‘My List of Medicines’ challenge. (The other challenge – Machine Mapping – is a bit esoteric for me).

So there are a couple of things we need to do.

  • Stand up a FHIR server for participants to use that can respond to appropriate requests (we’ll talk about what they will be in the next post).
  • Populate that server with the sample data given on the web site

Read more of this post

Challenges with Lists

So one of the challenges we’re facing at work at the moment is Lists – more specifically ‘current’ lists – eg the medications a patient is taking right now, their problem list and set of allergies.

A bit of background.

Read more of this post