Orders in FHIR

One of the streams at the next FHIR Connectathon is Lab Order Services – a track designed to exercise the workflow components of FHIR. Up until now, most of the focus of the team has been on developing the base resources and supporting infrastructure, so now that that’s in a good shape, one of the next focuses will be workflow. There’s a lot of thinking going on right now –  there’s a specific workflow project looking at this, and Keith blogged about it quite recently so the current way in which FHIR manages workflow is very likely to change significantly – probably as part of the 2.1 version scheduled to be released towards the end of next year.

I was asked if we could use clinFHIR as a client for exercising workflow at the Connectathon, so have spent a bit of time just recently thinking about how we could do that.

Before getting into the details, a quick review on how workflow is currently organized in FHIR (and remembering that this will change as a result of the workflow project.)

There is a clear separation between the ‘action’ (or actions) that is being requested and the information about what is required to complete that action. The action parts are represented by 2 resources (Order and OrderResponse).

• The Order specifies who is initiating the order, when it should be done and who it should be done on. It has references to the actual resources that represent what is being requested – eg a MedicationOrder (for a prescription), a DiagnosticOrder (for a lab test) or a ReferralRequest (for a referral). A single order can refer to any number of ‘information’ resources – and they needn’t be the same type.
• The OrderResponse resource then indicates the outcome (or outcomes) as the order is processed by the recipient (a process sometimes called ‘fulfilling’ the order). It has references to the Order that it is fulfilling and to the resources that represent the outcomes of the order.

Take a look at the picture below.

In the yellow rectangle are the resources that were created when the order was established. These are:

• The Order resource itself
• A Practitioner representing the person who made the order
• A Patient representing the target of the order
• A DiagnosticOrder that has the details of which tests to perform.

Then there are other resources that are created during processing/fulfilling the order.

A couple of OrderResponse resources – the first maybe indicating that the order was accepted by the lab and the second being generated when the result is available and also containing references to the DiagnosticReport that was generated with the results.

(Not shown in the diagram is that all of the resources – with the exception of the OrderResponse – have a reference to the patient. )

You can use this pattern through any of the supported paradigms. If you were using REST it could go something like this:

1. The client gets a reference to the Patient.
2. It creates and stores the DiagnosticOrder. (For simplicity we’ll assume that everything is saved on the same server – though in practice you might have one on the Data Server as an ‘EHR’ reference in the patient record, and another on a ‘Workflow’ server where the action takes place). At this point the DiagnosticOrder is like any other resource.
3. It creates and saves the Order resource (referencing the DiagnosticOrder). This initiates the overall workflow.

We assume that the server (the ‘fulfiller’ of the order) is monitoring for the appearance of a new Order. The process that follows will depend entirely on how it is implemented, but could be something like this:

1. The server decides whether to accept the order (this may be automated or manual). It creates an OrderResponse to indicate this (setting the OrderResponse.status appropriately).
2. The order is actioned (eg blood is take from the patient and passed to the analyser which produces the DiagnosticReport/Observation resources). Potentially further OrderResponse resources are created at various steps so the client is aware of the progress of the workflow.
3. When the result is available, a final OrderResponse (with a status of ‘completed’) is created with references to the Order and to the DiagnosticReport.

So how does the client know when the process is complete, or when significant actions occur? Well, that depends (again) on the implementation – it could be a polling process (a bit inelegant) or maybe a subscription mechanism that notifies the client in real time – it’s up to you.

So with that background, how can clinFHIR help?

It already has the ability to create any resource (including from profiles – so long as they aren’t too complicated) so in theory it’s good to go. But it’s rather tedious to create all the relationship manually, so I decided that a specific orders interface to make it easier would be worthwhile.

If you load this page and select a patient and then the Orders tab, you’ll get this interface:

(Oh, as I was testing this I realized that clinFHIR doesn’t recognize when a patient has been deleted from the server, so if you get errors stating that the resource has been deleted, just try a different patient – or add a new one. I’ll tidy up that behavior soon).

There are 3 tabs:

• The Builder tab has the resource builder component – it’s the same one used in the main clinFHIR application
• Resources lists the resources for the current patient – again the same one as used elsewhere.
• The Orders tab is where you can manipulate orders, and looks like this:

The order display lists all orders for the current patient showing:

• The date the Order was created
• The current status. Technically, this is the status of the most recent OrderResponse associated with that Order as the Order itself doesn’t have a status. (If it did, then any process saving an OrderResponse would also need to update the Order – ie a transaction – that we try to avoid.
• The reason for the Order. This column actually has 2 items in it:
  • The reason itself (currently this is Order.reasonCodeableConcept.text – this needs to be improved as the reason can refer to an external resource)
  • A list of the detail resources associated with this order. Only the id of the resource is shown – we’ll see how to view the details in a minute…
• The ‘When’ column shows the order.when.text value – again, needs to be improved to show the timing element as well
• The responses column shows all the OrderResponse resources that reference this order. This has a sub-table in it showing the date, status and description of the response. If there are associated resources to the order (eg the DiagnosticReport) then they will be shown as well.
• The final column has a link that allows you to create a new OrderResponse against this order. In real life of course, this is created by the server processing the order – not the client, but it’s there so you can think about the full workflow process – and model the resources (or profiles) needed. Clicking on the link displays the following dialog:

From here you can create a new OrderResponse resource, specifying the following fields:

• The new status of the order
• A description
• Associated resources. You would use this when you want to ‘complete’ the order. Before doing this, create the ‘complete’ resource in the Builder (maybe a DiagnosticReport with associated Observations) and then link to it from here.

(and just a reminder that you can do all of this from the Builder as well – this is just to make it a bit easier).

This is all rather complicated (actually, workflow IS complicated) and visualizing the end result is not easy. You may have noticed that the date column of the order is actually a button. Clicking on the button will display the Order in the Resources tab – where you can view all the relationships of the order. Here’s an example – the order has a couple of OrderResponse resources that reference it, and it has references to the Patient and DiagnosticOrder resource.

Remember that selecting any resource in the references tab will put that resource ‘in focus’ allowing you to view its contents (as XML or JSON) and the references that it has.

To create a new order you need to first create and save the ‘Information’ resource/s (eg DiagnosticOrder or MedicationOrder) and then create the Order to action it.

Use the ‘Resources’ tab to create the resource in the usual way – oh, and note that the Builder UI has been simplified a bit – to select a profile (which includes the base profiles for the resources), click the ‘Load new profile’ link, then select the base profile from the dropdown in the dialog that appears. You can then select that base profile directly or look for other profiles on that base profile (it makes sense when you do it!). This just reflects that in FHIR all resource definitions are, in fact, profiles (or StructureDefinition resources to be precise).

To create the Order you can either use the builder, or create it from the orders tab. To do this, select the Orders tab then click the ‘New Order’ button to the left of the screen. Enter the reason for the order, the priority and the information resources, which will be in a dropdown to the upper right of the screen.

(To be honest, the UI is still a bit rough – it’ll be better by the Connectathon!).

Either approach achieves the same end – the Order resource, with links to information resources, is saved on the server, and will appear in the Orders list.

So that’s how clinFHIR can support the current orders workflow. It’s still a bit flaky – not all the components are properly set up, sometimes it doesn’t update correctly (just re-load the page if that happens) and remember that the whole workflow infrastructure in under review, so change is certain!

This is probably my last post before christmas, so I wish you all the compliments of the season and hope that you will enjoy the company of family and friends over the holiday break. Next year is going to be wild!