Updating a resource using patch

We’ve received a bit of pushback from the community regarding our proposal to use custom operations for updating the Patient in NHI upgrade project. But the development team really isn’t keen on using PUT updates of the complete resource – the main reason being that of ‘accidental’ data changes when the updater doesn’t return the parts of the resource that should remain unaltered. (Apparently, this is not uncommon with messaging based updates that are kind of similar).

I mentioned in that post that we didn’t really take a close look at PATCH updates – but a couple of days ago I saw this trail in the FHIR chat which is about a similar project (slightly different requirements) and thought I really should take a closer look at PATCH.

Read more of this post

Using prototypes in app design

I’ve always been fond of creating functional prototypes when designing apps. There are a number of advantages over simply documenting what the app should do:

  • It means that the users (e.g. clinicians) get to try out something that actually works (sort of) before ‘signing off’ on the requirements. This reduces the chance of delivering something that doesn’t quite meet their needs.
  • It helps significantly with the FHIR design. Assuming that the app actually communicates with a FHIR back end (which can be one of the freely available reference servers such as HAPI), then it validates the resource design (which resources are needed and their profiling) as well as the API’s that are going to be needed. This can be quite a tricky step to implement depending on what the real back end is going to be.
  • It’s much simpler and quicker to develop than anything that needs to be ‘production ready’. For example, you don’t generally need to implement any security or handle the errors that need to be allowed for in a real application.
  • It delivers solid requirements to the development team, as well as a test app that they can use as the API is developed.

Read more of this post

Creating a resources model

This is the third post in a mini series on using the Logical modeler. In the first post we talked in generalities of models (admitting that this is very much a work in progress), and then we discussed the Information Model – a model that is used to capture clinical requirements for information exchange. Now, it’s time to think about how we can design real FHIR artifacts from the work so far.

Read more of this post

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!

 

 

Creating documents in clinFHIR 

I did a demo of clinFHIR for the Clinicians on FHIR group that will be meeting at the Working Group Meeting next week, and completely forgot to talk about creating/viewing documents in clinFHIR using the scenario builder. This is functionality that has been around for a while, and allows you to create a FHIR document by adding a Composition resource to the scenario, and then linking up the other resource to it.

So I thought I’d do a post on it!

Read more of this post

FHIR Bundle Visualizer

So a little while back I wrote about an app I developed during the WGM Connectathon to send an HL7 v2 message to a converter app, and display the response (a FHIR Bundle) in a number of visualizations after validating it using the community supplied validation tool (actually, exposed by the reference servers via the $validate operation). It occurred to me that this visualization might be of use to implementers who are developing query applications – such as the CSIRO Primary Care project for example, so I pulled it out into a separate application.

Read more of this post

Thoughts about updating Registries

In New Zealand we are lucky enough to have had a national patient registry for some years which serves as a unique identifier of patients in New Zealand – the National Health Index or NHI. The Registry is an instance of an EMPI (Enterprise Master Patient Index) and currently  exposes a SOAP interface that can be accessed by clients across a protected network.

In order to make it available for more users we are working in a project to expose a FHIR API that will offer similar functionality to the existing SOAP one, be simpler to use, available across the public Internet and so accessible to a wider range of clients in support of the healthcare ecosystem. We’re also looking at similar work for Provider registries.

Read more of this post

Converting v2 to FHIR

At the recent Working Group Meeting in Montreal, I participated in the ‘v2 to FHIR’ stream – focused on how can the HL7 community give advice to implementers about converting v2 messages into FHIR bundles.

Broadly there are 2 approaches to this conversion:

  • The creation of a FHIR message bundle that mirrors the contents of the v2 message, and is intended to be an equivalent representation, behaving in the same way as v2 messages
  • Using the contents of the v2 message to update a FHIR server – perhaps extracting Encounter resources or creating a Bundle that is intended to act as a ‘transaction’ bundle against a FHIR server. I think this will be a much more common use case.

In either case, it’s desirable that HL7 should provide the mappings (insofar as that is possible in v2) from v2 to FHIR.

Read more of this post

Creating models with the Logical Modeler

It’s been a while since we talked about the clinFHIR Logical Modeler, and I’ve had a few questions about it, so I thought an update might be in order.

The term ‘Logical Model’ can be used in different ways (much like ‘Profile’) so let’s first define just what we are talking about. Basically, it’s just a hierarchical model of data – much like you see in any of the core FHIR resource types – with the exception that the model does not have to align with any of the core types. Other than the requirement that you must use the FHIR datatypes, there are no limits on the complexity of the model you create (though overly complex models can be hard to understand – or use).

In this post we’ll talk about the general aspects of using the modeler – subsequent posts will go into more detail about how to build them.

Read more of this post

Scenario Builder: Library and Documents

In the last post we talked about the new builder component that was developed to help people (especially clinicians) develop sets of resources to represent clinical scenarios. There are a couple of features we didn’t have time to discuss then – the Library and Documents – so let’s talk about them now.

Read more of this post