clinFHIR stock take

I’ve been asked to give a short talk about clinFHIR to a course at Johns Hopkins this month – what it is and what you’d use it for, so to organize my thoughts I decided to write a ‘stock take’ of clinFHIR modules. This is actually part of a project I’ve been working on for a little while – learning FHIR with clinFHIR – so it’s a perfect time to be doing it.

The idea for clinFHIR started shortly after FHIR started to gain prominence within HL7 – coming up to 10 years ago now. The technical folk understood what the developers were trying to do – utilize internet standards to share healthcare data – but it was harder for the clinical folk to gain that understanding and appreciate the significance.

clinFHIR (Clinical FHIR) was envisaged as a way to visualize FHIR – particularly resources and the references between them – so that the committees within HL7 responsible for authoring resources could advance their development. We worked closely with the members of the ‘Patient Care’ committee in particular – they had sessions at most Working Group Meetings called ‘Clinicians on FHIR’, and we developed clinFHIR as one of the main tools for them.

(And I’d like to recognize all the work they put into this – it was an on-going balance between evolving the application to meet identified needs, and dealing with the bugs that a rapid development cycle brings!)

In addition, it was also seen as a way to help test the servers that were being developed (and equally rapidly changed) as FHIR evolved. The application itself is developed as a number of ‘Single Page’ javascript applications that directly accesses those servers using the FHIR API which is both a strength and a weakness – a strength as you could choose which server you wanted to use for which purpose, and a weakness as there is a dependency on that server, so if it becomes unavailable – or if someone else replaces resources you are using – then you can get some weird errors. Trying to cope with this and the changing FHIR versions was certainly a challenge!

We considered 3 types of server, which could be selected on the launch page:

• Conformance – storing Profiles and Extension Definitions
• Terminology – exposing terminology operations like $expand
• Data – storing patient related data.

The app has a number of servers ‘hard coded’ that you can choose from, and you can also add other servers directly if you wish. All servers must support CORS – as clinFHIR is browser based.

ClinFHIR itself actually became a collection of different modules – apps with specific functionality to meet some specific need, some more widely used than others.

So here’s the list of the main modules. I’ve grouped them into those that are still (in my opinion) useful and used, and those that are no longer really used, as far as I am aware. Each module has a brief description only – and links to more information where available. Most can be started from the launch page, and I’ll indicate if they use the servers configured on that page.

I’ll also add a direct link to the module – if you follow that link, don’t forget that in many cases the servers are set on the launch page, and you generally need to go there to change them.

And before I go into details I’d like to acknowledge and thank firstly Orion Health and subsequently Lyniate for supporting me as I maintain and develop the clinFHIR  modules.

Patient Viewer

This is one of the original modules, and is intended to display existing resources for a given patient – it can also create a fixed set of resources for a new patient so there is something to see. In fact, my good friend Mark Braunstein uses this for his Georgia university based training course – and help create the sample data.

The module has a number of different views of the patient data, the main one being a graphical view that represents the resources as shapes, connected by the references  between them. You can move the resources around to get a better view, and selecting one of them displays the contents in a number of different formats, references to & from them and event different versions of the resource, if the server supports versioning

It uses the currently configured Data server. Here’s a screen shot showing an AllergyIntolerance with a reference from a List.

Server Query

Also one of the early modules, Server Query allows the user to make a query against the RESTful API of a server, and display the response in formats similar to Patient Viewer. Think of it as a FHIR aware version of a REST client like POSTMan.

It also displays the capabilities of the server, based on the CapabilityStatement that all FHIR servers must expose.

There’s a very basic assistant to help build the query, and you can select any of the pre-configured servers, or enter the url of any server

Bundle Visualizer

This is a relatively new module – it grew out of some work that we were doing with v2 -> FHIR conversion at a connectathon, and I wanted to be able to visualize the output of the conversion.

It takes a FHIR bundle (which can be directly pasted in), and displays the contents in much the same was as Patient Viewer. It also validates the contents of the bundle using the $validate endpoint.

Here’s a screenshot showing all the contents of a FHIR document – though the details tabs are likely more useful. The servers can be selected from the navbar.

GraphBuilder 2

If any module can be said to be the ‘flag ship’ for clinFHIR it would be GraphBuilder. This is actually the 2nd generation of modules (ScenarioBuilder being the first) that allows the user to create their own graphs by selecting resources, and setting the references between them to represent some scenario. The resources can then be exported to a FHIR server, where they can be viewed and queried by any FHIR client – including the clinFHIR ones.

It can be used for educational purposes, but also as a design tool when deciding how some specific use case can be represented in FHIR.

Here’s an example from early work being done on the Patient Correction Implementation Guide.

To build the content of the resources, the app uses FSH to represent it, and an API provided by the sushi app which generates the more familiar Json representation of the resource, that can subsequently be saved to a FHIR server. Creating the content using FHIR StructureDefinitions as templates is somewhat complicated, and I’m indebted to the MITRE folk for providing these capabilities. FSH / Sushi is definitely something that anyone working with FHIR should be familiar with.

Logical Modeler

Also one of the earlier modules, this app allows the user to create user-defined models of data. Its purpose is to support design work – for example we used it in the Australian CSIRO Primary Care data project to create a single model to represent the data we wanted to share. It uses the FHIR infrastructure (datatypes and StructureDefinitions), but the models are not the defined resource types – rather presenting the data in a way that is understandable to non-technical folk – clinicians and business analysts for example.

The idea is both to help in defining the data model, and also to assist the transition to FHIR profiles.

Here’s a picture from the model we created for the CSIRO project (actually Heather Leslie) did most of the work):

Resource Validator

A simple app – you paste in a resource and it uses the $validate operation to validate it. Its claim to fame is that you can set multiple servers to perform the validation and compare the results from each (kudos to Michael Lawley for this idea.

Not really much more to say about it.

conMan (Connectathon Manager)

This is a bit of an oddball in this series, as it’s intended to support FHIR connectathons rather than any aspect of FHIR itself. It has a number of tabs to describe the tracks on offer, people attending, Implementation guides being tested, servers available, results of testing and so forth.

There is a different url for each event. (The one in the link is for the latest event in May 2021).

I’m going to write a post shortly for those attending the connectathon so won’t say a lot more about it here – but here’s a quick screenshot of some of the IGs being tested in May, including links to the IG itself and the FHIR Package Registry:

And here is a list of modules that are still there, but not really being support (and may not work properly)

• Scenario Builder. The original version. Still works fine, but GraphBuilder2 is preferred. Does retrieve StructureDefinitions from the conformance server, so if they are deleted of changed then the app can break.
• Implementation Guide Browser. Displays Implementation Guides in a graphical way. Really needs to be updated to support the FHIR Package registry (at which point it won’t be deprecated no more!)
• ValueSet explorer. Displays the content of a ValueSet, and allows editing. Really only works for SNOMED, and a bit crusty around the edges.
• ExtensionDefinition builder. Creates StructureDefinitions that represent extensions. I’d use FSH / Sushi these days, but does have a UI so maybe worth a bit of attention.
• CodeSystem Builder. Builds simple codeSystems. Again, use FSH / Sushi if you need to do this.
• Concept mapper. Allows authoring on ConceptMap resources

And finally a note about future plans.

I definitely intend to continue to support and enhance the main apps – in particular GraphBuilder2 as an educational / design tool.

The Logical Modeler is quite a good UI for building logical models (hence the name) – I’d like to export models as FSH to better integrate with IGs. And maybe import FSH documents as well and display them as a tree…

Depending on how the next connectathon goes, conMan may come in line for more attention. The recent focus on helping to evaluate IGs could be helpful in a wider context.

I sometimes take a reasonably in-depth view at a particular topic – the recent set on immunization being an example – and it’s often helpful to write a small prototype to develop / illustrate the concepts being discussed.

And I really want to do something that better supports the FHIR Package registry. It’s going to be really important to the FHIR community to have this resource as accessible as possible so I’m thinking of updating the Implementation Guide Browser to access data in the registry (there’s an API to use – it’s just a matter of finding the time!)

Oh, and one last thing 🙂 – I recorded a video demoing some of the modules..