Skip to content

Multiple versions

It's possible to represent the state of a resource over time using multiple versions. An example showing how the status and references resources of a Task changed as the task is created , accepted and completed over the lifecycle of the task processing. (This example was inspired by on the Patient Corrections IG).

Process

The basic process is as follows:

  • Create a project that has a server associated with it
  • Create a graph representing the initial state (including structured data). In particular, be sure to add the patients name as structured data so it can easily be found later on the server
  • Save the project to the server
  • Update the graph to represent the next state - either as a new view or just change the existing one. Again, adding / removing references and structured data
  • Save the resources again
  • Repeat as required

To view the resources use the clinFHIR Patient Viewer

  • Set the clinFHIR data server to the same one as in the project
  • Load the Patient Viewer, and select the patient
  • Select the resource of interest (eg the Task) and you can then view the details of the Task
  • including the previous versions.

Details

Create the project

The only thing you need to be sure of is that there is a server associated with the project - that will be where the resources are saved. If needed, you can select an IG to use, or just use the base resource types.

The server does need to support the Transaction operation, and preferably the Validate operation as well. (Most of the reference servers - HAPI, Vonk, FHIR do this).

Create the initial graph

Add the resources that represent the initial state - eg a Task created by a patient to correct an error their clinical records. Be sure to add all the structured data needed (using FSH). It's important that this is complete before the graph is saved, as it's not possible to alter resource versions on the server once they have been saved.

It can be helpful to use the validation capabilities as the resources are being created. There are 2 'levels' of validation

  • When you build the json from the FSH by clicking the refresh icon at the top right, sushi will perform basic validation - mostly that element names, data types and multiplicities are correct.
  • The tab showing the JSON also has a link to call the Validate operation. THis is performed by the FHIR server and can check invariants as well.

And a reminder that it is the FSH that is the 'source of truth' for creating the resources - it's quite OK to edit it directly, and sometimes that's the only way to set resource content.

add image of initial graph

Save the initial graph on the FHIR server

Save the graph to the server using the link at the top left. It's a 2 stage process, an initial validation (prepare) followed by the actual save. This is quite a good screen to check all the resources as there are links from the list of resources to the FSH editor so that it's easy to check that they are all correct (and complete)

Once saved to the server, any further changes to a resource will result in a new version of that resource on the server.

Update the graph

To represent the 'next step' in the process, the cleanest way is to create a new view in the project. Click the 'new view' link in the views panel to the left, and select the 'copy from previous view' checkbox. This will create a new view that is a copy of the previous one. You can edit it as required using the same techniques as before.

Save the updated graph

When ready, save the updated graph to the server.

It's important to realize that each view is a 'perspective' on the overall project graph, and that it's the complete graph that is saved to the server. For this reason, you have to create the process steps in order - you can't go back to a previous step and make changes and then save them. The view in GB2 will be correct - but the versions on the FHIR server will always be in the order that they were saved.