Projects in clinFHIR

One of the things that the Resource Builder in clinFHIR does is to allow you to use different servers for the various ‘roles‘ that are needed. These include:

  • The Conformance server – holds resources like StructureDefinition and NamingSystem
  • The Terminology server – ValueSets and the Terminology operations required by the different applications within clinFHIR
  • The Data server – where patient (and other) data is kept.

This isn’t an official part of the spec, but is a useful way to think about the main ‘components’ of a FHIR solution.

 

While flexible, this can make it somewhat more complicated to use, as you need to select the right combination of servers to suit a particular need.

Read more of this post

What is SMART and why should you care.

This was actually a summary of SMART that was intended to wrap up a series I wrote a few months back, but I forgot to post it! So, better late than never…

Read more of this post

Dev days in November

In the past I’ve talked about the FHIR Developer days hosted by our friends Furore in November in Amsterdam – generally with a slightly envious tone. This year – thanks to my employer Orion Health – I’m able to attend! (I’m going to get into the group picture at last :) )

Since I’m going to be there and I have a clinical background, the Furore folk suggested that I might want to lead a track specifically for Clinicians and Business Analysts who want to learn more about FHIR – so this post is all about putting some ideas out to get feedback.

Read more of this post

More FHIR on the pi…

So this is in the nature of the ‘I’m doing it this way just because I can!’

The background is that I want to create a series of time lapse pictures from a property overlooking a tidal river that doesn’t have internet access, and to be able to access those images remotely. (The property is in Waipu – rural New Zealand!)

Read more of this post

Resource reference visualization in clinFHIR


I was skyping with my colleague Viet Nguyen over the weekend about some improvements I was adding to clinFHIR – the resource viewer now generates a more ‘user friendly’ display for some of the resources (Encounter, Observation, Condition). I showed him what I had done, and asked him what else might be useful and he said:

This maybe pie in the sky – a network type diagram with different colored icons representing conditions, encounters, labs, etc. that allows the user to visualize the relationship between conditions and related resources. This is the type of “breaking out of the document paradigm” approach I’d like to pursue.

Read more of this post

ValueSet editor in clinFHIR

I’ve been working on the profiling abilities of clinFHIR recently. As I’ve said before, although there is the official tool for creating profiles – Forge – I think there is a place for a simple profiling tool primarily aimed at clinicians, with the goal to help them understand how FHIR profiling works.

One of the big things that keeps coming up is ValueSets – and how to create them.

As a short recap – recall that the purpose of profiling is to take the core resources and make them more suitable for real-world Use Cases by adding new elements (extensions) and removing the ones that are not needed. As part of this process you often want to specify a particular set of values for coded elements that is different to the one in the spec and the ValueSet is the mechanism that you use to specify those. The problem is that there isn’t currently any widely available tooling to create ValueSets (outside of the tooling used to build the specification itself) – especially ones for clinicians to use, so over the weekend I decided to write a simple ValueSet Editor.

Read more of this post

Modifier Extensions in versioning (maybe)

So I think I’ve come across my first real place where using a modifier extension makes sense. (actually, not quite – see the note at the bottom of the post, but the discussion is hopefully still interesting)

Before we get into that, a short recap on what a modifier extension is. As most people working with FHIR will be aware, the specification aims to keep the individual ‘packets’ of data (Resources) as small and simple as possible, by providing a fixed core of elements that ‘most’ people are currently sharing and an extension mechanism that allows individual implementers to add the extra elements that they may need for specific Use Cases – a process called Profiling.

Read more of this post

Follow

Get every new post delivered to your Inbox.

Join 593 other followers