GraphQL

Following my post yesterday, someone who shall remain nameless (you know who you are Brian) suggested that it would also be good to be able to make GraphQL queries from clinFHIR. I know even less about GraphQL than I did about FHIRPath, but as Grahame has an implementation on his server, it was a reasonably straightforward matter to put a simple UI in so you can experiment with that against a Patient resource. (GraphQL can do a lot more than that, but this is a start).

Read more of this post

FHIRPath

 

I’ve known about FHIRPath for some time, though I must admit I haven’t paid a lot of attention to it.

Put briefly, FHIRPath is a specification that describes how to identify (and potentially extract) data from a resource using a path based syntax. From the spec:

Of particular importance is the ability to easily and precisely express conditions of basic logic, such as those found in requirements constraints (e.g. Patients must have a name), decision support (e.g. if the patient has diabetes and has not had a recent comprehensive foot exam), cohort definitions (e.g. All male patients aged 60-75), protocol descriptions (e.g. if the specimen has tested positive for the presence of sodium), and numerous other environments.

with these features:

  • Graph-traversal: FHIRPath is a graph-traversal language; authors can clearly and concisely express graph traversal on hierarchical information models (e.g. HL7 V3, FHIR, vMR, CIMI, and QDM).
  • Fluent: FHIRPath has a syntax based on the Fluent Interface pattern
  • Collection-centric: FHIRPath deals with all values as collections, allowing it to easily deal with information models with repeating elements.
  • Platform-independent: FHIRPath is a conceptual and logical specification that can be implemented in any platform.
  • Model-independent: FHIRPath deals with data as an abstract model, allowing it to be used with any information model.

Read more of this post

Implementation Guide viewer

Just a short post to describe some updates to the Implementation Guide viewer (which I’ve renamed from ‘profile viewer’ as it was described in this post.) Thanks to some comments in the FHIR chat from my friend John Moehrke I’ve done some work on the ‘Graph visualizer’ component of the viewer.

The idea is to make it easier to understand the contents of an Implementation Guide, and the relationships between them. Currently limited to Profiles, Extensions & ValueSets – but no reason why it couldn’t be extended (or won’t be 🙂 ).

Read more of this post

clinFHIR profile viewer

Over the years I’ve made a number of attempts to build a profile viewer – to a mixed amount of success. The issue is becoming more urgent though, as profiles (as part of Implementation Guides) start to become published, and vendors such as Orion Health need to think about how we are to support them.

The issue is even more important for vendors in the international space, as our solutions are going to have to support different profiles in different countries, and we cannot assume that the profiles will be in alignment even for the same concept.

We’re not going to solve that issue right now (though it does highlight that the developers of profiles need to be aware of it and ideally working to avoid it as much as possible), but the ability to view profiles from different jurisdictions and analyse them in a common way is going to be important. Read more of this post

Viewing resource instances in clinFHIR

One thing you need to do quite frequently in the FHIR world is to look at resource instances (whether in XML or JSON), and this can be quite complex.

A little trick I use quite frequently is to use the clinFHIR scenario builder to create a hierarchical “tree view” of the resource, which I find easier to review than the raw format.

To do this, follow these steps.

Read more of this post

Using Scenario Builder for developing Resources

I had an email this morning from the organizers of the ‘Clinicians On FHIR’ event at the upcoming Working Group Meeting asking if it was possible to use the Scenario Builder to examine a resource type that had been altered after publication (i.e. one that was being worked on for the next release of FHIR – R4). As it turns out, this is quite straightforward to do – albeit with some limitations.

Read more of this post

A sense of history with clinFHIR

I’m definitely going to finish off the series on building extensions (we have to cover coded extensions) but I must admit I’ve been a bit sidetracked in the last couple of days. You see we had a call with the ‘Clinicians on FHIR’ team talking about plans for the upcoming event at the WGM in Spain, and during the course of the discussion, Emma asked if clinFHIR could show versions of resources as she wanted to describe medication reconciliation.

At the time I said we could certainly do something like that (though I’ve not yet got that working in the Scenario Builder) but after the call I was thinking about it, and it occurred to me that what we really need is to be able to version scenarios – so we can show how they are built up, and potentially to model a workflow like fulfillment of an order or reconciliation.

So, may I present…

Read more of this post