Using conMan to collaboratively build a Use case



When a graph is created in conMan, the resource instances are actually saved in a database on the server (not a FHIR server) keyed to the user – ie one user has one graph per scenario. To actually save it to the server, you use the ‘Server Interaction’ tab to copy the resource to the FHIR server that is specified in the Track definition. So it’s quite normal to have information displayed in the graph that is not in the server.

Here’s a picture:

Currently, it is not possible to do the resource – i.e. to pull an existing resource instance from the FHIR server down to the Graph.

However, it is (now) possible to create a link from an existing resource to a graph. The ‘copy’ in the graph will be read-only – it can only be updated by the graph (and thus a specific user). This makes it possible for multiple users (ie graphs) to interact with the same patient. Specifically, where users wish to ‘collaborate’ on building parts of a complex use case (eg multiple tracks/scenarios)

The last piece of the puzzle is the need to see the ‘combined’ data – ie all the resources that were created by any graph ‘against’ that patient. For this we can use the clinFHIR Patient Viewe app.


Before working on the Use Case, make sure that everything is set up correctly. This largely involves setting up the servers correctly. There are 3 servers to consider.

  • The terminology server for ValueSet expansion. Unless there is a good reason, use Ontoserver
  • The conformance and data servers. Though separate in functionality, generally it’s a good idea to have both the same. I suggest using the clinFHIR R3 server, (which is an instance of the hapi server) as the current test system seems to have some issues with validation.

The places where you need to make sure the servers are correct (and the same) are:

  • The track definition in ConMan
  • The servers in clinFHIR


The following process should work. The assumption is that there are 3 people working on different aspects of the Use Case.

  1. One participant should create the common patient that will be used. They add the Patient to  graph (any track/scenario), give them a name that is easy to find (and a little unusual) and then save the graph to the server (will be the data server). It doesn’t matter if there are other resource instances in the graph.
  2. The other participants then create a link to the patient in their graphs. There must only be one Patient resource instance in the graph – and it must be the linked one. There’s a new tab where resource types are selected called ‘Select Patient’ – enter the name, and choose the correct patient. The patient cannot be edited, but other resources in the graph can reference it. The Json of the patient will be displayed in the editor.
  3. Each participant can then add other resource instances to their graph and save them to the server. It pays to validate before saving (though I have noticed sometimes the validation does not succeed.
  4. It is possible to create links to other server based resources as well (these must have a reference to the selected patient). To do this, there is a link in the ‘Core resource types’ tab called ‘>Select from Patient<’ that appears when a patient has been linked in a graph. Clicking that link will produce a dialog of resource instances for that patient that can be linked to.

To see all the resources of the patient, use the clinFHIR Patient viewer. This will show all the resources for a patient (and the references between them) regardless of who created them. Use the ‘Resource references graph’ – second tab – to see all of them. By default, the viewer doesn’t show the patient resource – there’s a link underneath the graph on the right that will show the patient as well.


Final thoughts

  • Resources must be saved to the server before they are available for linking (or viewing in the clinFHIR viewer)
  • If you create a resource in a graph which is subsequently a link target, and then remove it from the graph, it will still be available as a link, but won’t be able to be changed.
  • The way that the patient viewer shows the resources is likely to vary according to the use case – no guarantees as to whether it will look nice! If a graph has a ‘central’ resource (like an encounter) that other resources can hang off, then it may be possible to have ways to manipulate the view.
  • This will only work for core models – not Logical Models