If you’ve used clinFHIR in the last 24 hours then you’ll have noticed a new User Interface. This is a recognition that clinFHIR is now really a number of ‘co-operating’ modules rather than a single application, so the previous UI wasn’t really the best any more.
In this post I’ll describe the UI (Actually I call it a ‘Launcher’ as it’s really a start point for the various modules).
Here’s a screen dump of the new UI:
The main parts of the UI are as follows.
At the top right is the log in icon. If you’re already logged in then mousing over will show the email, otherwise click to log in. The only purpose of logging in is to help manage updating of FHIR artifacts – for example only the author of a scenario is able to update it. This is a work in progress (as is the whole app actually 🙂 ) but will be rolled out across all modules eventually.
To the left is a list of all the modules in clinFHIR – I’ll describe them in a minute.
To the top right is a list of the 3 server roles that clinFHIR recognizes. Clicking the edit button will allow you to change them, and clicking the question mark will test that the server is on-line and available. By default, I tend to use the HAPI server for all server roles.
To the bottom right is a list of helpful links – I’ll likely add to this list as time goes on – ping me if you have a suggestion. There’s also a link to the previous version of clinFHIR if you need it.
So, now a description of the modules.
The Scenario Builder lets you assemble a collection of the resources that shows how FHIR represents given scenarios. It can use the core resource types and logical models as the basis of creating these scenarios, and I’m working on supporting profiles. There are still some gaps in functionality, but this is the main ‘builder’ app moving forwards, and will replace the current resource builder.
The Logical Modeler is used to create a model that represents some clinical ‘thing’ and is intended to be used when interacting with clinicians to capture clinical requirements. It can be used in 2 main ways:
- You can build a model that is based on an existing resource type and will become a FHIR profile. The plan is that eventually this will be an automated process – create the model, enter mappings to the core resource and Extension Definitions, and the Profile can be directly created
- You can build a model that is not based on an existing resource, but rather just captures requirements. The thinking is that you can use this during analysis, and then create the actual profiles as a secondary action.
The CodeSystem builder is new, and allows you to build – well – CodeSystem resources. These are new in STU-3 (they were split off from the ValueSet resource). I think that these will be very useful when building logical models in particular, and will do a post of them shortly.
The Extension Definition builder is used to create the definitions for Extensions (actually StructureDefinition resources of course). These are ‘extra’ elements that are added to resource types to represent data specific to your Use Case.
The ValueSet builder will build simple ValueSets. I’m not sure how important this component will be for clinFHIR now that the CodeSystem builder has been developed – the ValueSets are quite simple and there are much more comprehensive tools available (or becoming available). Note that the CodeSystem builder will automatically create the ValueSet that is needed when binding between a coded element in a resource and the CodeSystem.
The Query tool allows you to make ad-hoc queries on any FHIR server. It will display the servers’ conformance (now called CapabilityStatement) and also a pick list of the search parameters supported by that server.
The Profile Builder builds simple profiles. I’m not sure about the future of this component – once I get the bugs ironed out of the Logical Modeler to the point where it can generate profiles, then it may become deprecated. In any case, the Forge tool is much more comprehensive.
So there you go – I hope you continue to find it useful and welcome any feedback!