Provider registries in FHIR

So we’ve had some interest in New Zealand concerning Provider registries – locations where the details of providers and the services they provide can be maintained and discovered. There are a lot of potential uses for such a registry, but the two that we’ve been discussing are locating targets for referrals, and locating providers by specialty as part of Care Pathways.

Typical query use cases could include:

  • Find a Provider by name (or other personal detail)
  • Find a Provider by specialty – eg a physiotherapist
  • Locate a Service provided by a facility like a hospital

There are lots more of course, but these will get us started.

Read more of this post

Videos on clinFHIR Scenario Builder and Logical Modelers

So in a fit of enthusiasm I offered to do a short demo of clinFHIR at the CATonFHIR event in the UK in a couple of days. As it turns out, the reality of the timing is that this would be at 2am my time (New Zealand). Of course I’d be happy to do this to support FHIR (and have done it before), but when the organizer Philip Scott suggested I record a video that they could show instead of a live performance I jumped at the chance!

And having done one, a second wasn’t that hard…

Read more of this post

Building a set of resources in FHIR

One of the primary goals for clinFHIR is to help people who are new to the standard understand how it works – and increasingly these are clinicians whose interest is less in the technology and more about how FHIR can be used to represent the clinical information they wish to exchange.

While the current app does allow this, it has been aimed more at the people actually developing the resources than the casual user, and so can be time consuming to develop sets of resource instances that represent real world scenarios.

The component described by this post (called a simple builder – though a better name is needed!) is intended to allow someone completely new to FHIR to build sets of resources that represent clinical scenarios, to help them understand how the resources can be linked together – rather like Lego is used to build a complete model.

Read more of this post

Challenges with Lists

So one of the challenges we’re facing at work at the moment is Lists – more specifically ‘current’ lists – eg the medications a patient is taking right now, their problem list and set of allergies.

A bit of background.

Read more of this post

Basic Pregnancy Logical Model

So there was an interesting conversation in the FHIR chat just recently about representing maternity information in FHIR. It was pointed out by Lloyd that some elements that seem simple – like the LMP (Last Menstrual Period date) – are actually more complex than that, they are more properly Observations made by someone, at some date, with a degree of certainty etc.

So what this means is that a single logical model – like a summary of pregnancy – is going to wind up being represented in FHIR by a number of different resources, presumably ‘bound together’ in some way (eg  a bundle of some sort Document/Message – or just a Composition with appropriate references) and described by an Implementation Guide.

Given that I’m working on a logical modeler in clinFHIR, this seemed like something to address. Here’s where I’ve got to so far.

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

Montreal Connectathon

I would imagine that most readers of this blog are aware of the Connectathons that we hold at the beginning of each Working Group Meeting. These events are critical to the evolution of FHIR as an ‘implementer friendly’ standard, so we love to have as many people present as possible!

Read more of this post

Where did that data come from?

This post grew out of a question from one of the Analysts at Orion Health. We’re in the process of embedding FHIR pretty deeply into our product stack – and part of that involves creating FHIR interfaces to our existing data repositories.

This particular repository takes data feeds from a number of sources – mostly in the form of v2 messages, but also including CCDA documents – and from them extracts clinical data of interest such as encounters, procedures, problems and so forth. Because of the varied source of the data, one of the data items in the existing output that is displayed to the user is where it come from – ie which facility and possibly which application. (As much as we’d like to get the clinician, this data is not generally available in v2 messages).

So they question they asked me was – ‘where does this stuff go in FHIR’?

Read more of this post


Last week Brian Murphy (from Chilmark) and myself gave an Orion Health sponsored webinar entitled “The Future of Healthcare Integration: FHIR® and How It Supports an API-Based Ecosystem” – Brian spoke about the need for such an ecosystem, and I talked about how FHIR could support it.

The webinar appeared to go well (though it’s hard to tell from the presenter end!) but what was great was that we had a lot of questions – many more than we had time to address. So It thought it might be useful to give at least my answers to them – as detailed below. As always, these are my own opinions – feel free to agree or disagree in the comments below.

Oh, and here’s a link to the recording – currently you still need to register to view it – I’ll update the link if I get a direct one.

Read more of this post

Project Argonaut and FHIR

Most readers of this blog will be familiar with Project Argonaut – a project announced last year under the aegis of HL7 but funded by a number of US Vendors & Healthcare Providers to help accelerate the development of FHIR, and also the ‘SMART on FHIR‘ project.

Last week there was an on-line kick-off meeting attended by almost 100 people to describe the scope and purpose of the project, and to invite participation in the next phase. The project team were at pains to emphasise that the purpose of Argonaut is to accelerate the current work – it is not a ‘fork’ of the specification, or in competition with it in any way. All of the outputs remain fully open source – in fact they define it as a ‘code and documentation sprint’ – one that is time based and will finish once the objectives have been achieved (though, to my mind, follow-on projects are likely).

Read more of this post