SMART on FHIR: Part 1

With the 7th connectathon coming up, we’ve looked at the first scenario (Patient access) in a couple of posts and how we can use a couple of the libraries (.net and java) to make this almost trivial to achieve. (btw you don’t have to use these libraries of course – FHIR by itself uses standard technologies so there are a ton of different ways to do this if you already have the technology to do so, or use a different language).

In this post we’re going to take a look at the 3rd connectathon scenario – SMART on FHIR. There’s a lot of information about what this is trying to achieve (the connectathon site has links) so we won’t repeat that here – the ‘elevator pitch’ is that it establishes standards that enable the development of independent applications that can securely access data in any server supporting those standards – this could be an EHR, EMR, Portal or HIE.

Read more of this post

FHIR Connectathon 7 for Java Dummies

Last week we had a look at using the .net client to access a FHIR server as a lead up to the next connectathon. I thought it might be fun to do the same thing using the HAPI Java client (Now that it’s at release .5 – half way there!).

Now a disclaimer: I am not a Java developer – in fact I’m learning Java doing this work. In some ways I’d rather be in the .net world, but I’m a Mac user, and .net plays uneasily on that platform, so Java it is. (Yes, I know there’s Mono – it just doesn’t work for me for some reason).

Read more of this post

Clinical Scenarios in FHIR: Adverse reaction

The final scenario that is a candidate for the clinical connectathon is one that deals with allergies and Intolerance. Here are the details, but at a high level:

  • A patient is prescribed penicillin and 8 days into the course develops symptoms that are diagnosed as an allergy to penicillin, which is recorded in their allergy list, along with details of the nature of the allergy.
  • In addition, the patient (through a patient portal) updates their allergy list – adding an entry that is subsequently updated (or reconciled) by the clinician.

Read more of this post

Clinical Scenarios in FHIR

As you know (or should by now!), FHIR has from the outset been an implementer driven standard. The focus has always been on making healthcare interoperability as straightforward as possible, and regular connecathons have been an important part of that process (and we’re up to our 7th now).

However, it has to be admitted that thus far it has been the ‘techies’ – the ‘geeks’ – that are the main attenders at connectathon – and that’s kind of inevitable, given all the base work that’s needed to make FHIR a realistic standard for exchanging health information.

But FHIR is all about exchanging clinical information, and that means that it has to meet the needs of clinicians (which I use in the widest sense) as well as the technical folk. (And patients too – though that is another story).

At the last Working Group Meeting in Phoenix, we decided that it was time to think about a ‘Clinical Connectathon’ – where the emphasis was on meeting the needs of clinicians delivering care rather than the needs of technical people supporting them – can FHIR  do that?

So, at this WGM in September (held in Chicago) we’re going to have our first Clinical Connectathon (as well as the usual one – sigh). The focus of this event is to allow clinicians to focus on the “clinician to clinician connection” rather then the underlying technical resources that support those interactions.
Read more of this post

Connectathon 7: A Dummies Guide

As Grahame has said, the planning for the 7th FHIR connectathon to be held at the September Working Group Meeting in Chicago is well under way. This time we’ve got 4 separate tracks (you can check the link for the details), but in this post let’s have a look at track 1 – the Patient track.

This is intended to be a simple track for those new to FHIR – a way to get your feet wet (so to speak) and show just how simple basic interoperability with FHIR really is. You do need to write some code, but given the tools available these days, that’s not hard to do, so the barrier to entry is pretty low (and remember, the FHIR test servers are always available so you can do the basic learning in the privacy of your own home before you come!)

Using FHIR is actually made even easier by using one of the freely available client libraries. There are a number of them, but the 2 most well known are the .net library (from Furore – one of the earliest companies to support FHIR) and a Java one from the HAPI team – who have had a well regarded library for HL7 version 2 for many years.

In this post I’m going to use the .net libraries – but the java one will work just as well – in fact the two libraries (not co-incidentally) share a common approach.

I’d like thank my colleague Peter Jordan from HL7 New Zealand  for the code snippets in this post – I’ve adapted them a bit so I’ll take responsibility for any errors!

You’ll probably want to start with a copy of Visual Studio Express (which is free), so down load the version that suits your purpose (ie whether you’re writing a web or a desktop application).

You’ll need to download the .net FHIR libraries – they are in github, but the easiest way to get them is by using NuGet and searching for the FHIR libraries there. (The github reference has more information including links to documentation and a NuGet reference)

Now, you can create a project in Visual Studio. (btw I’m not an expert in Visual Studio – and as I use a mac it’s a bit fiddly for me to use it so this is not a step by step guide – there are a ton of tutorials on the web so it should be easy to get more detailed instructions if you need them). An alternative you can use is Xamarin which does run on the Mac.

First you need to include references to the c# FHIR libraries (and a couple of others)

using System;
using System.Collections.Generic;
using System.Configuration;
using System.IO;
using Hl7.Fhir.Model;
using Hl7.Fhir.Rest;

In order to use the library, you first instantiate a new FhirClient object, passing in the base URL of the FHIR Server. Then, you can call the required methods on that library which will issue the required REST calls – and throwing exceptions when errors occur.

In the example below, the FhirClient is initialized against the Orion Health ‘Blaze’ server, and the Conformance resource read and saved to a file.

var client = new FhirClient(@"https:/");
var confStat = client.Read<Conformance>("metadata");
string TestFile = "c:\temp\" + Guid.NewGuid().ToString() + ".html";
File.WriteAllText(TestFile, confStat.Summary);

So how do you find a patient? Well…

var client = new FhirClient(@"https:/");
List<string> searchCriteria = new List<string>();
var bundle = client.Search<Patient>(searchCriteria.ToArray());
foreach (ResourceEntry entry in bundle.Entries) {
   // create a Patient Object from the Entry Resource
   Patient patient = (Patient)entry.Resource;
   // ... do something with patient, it's a c# object representing the patient resource ...

You want to create a new patient?

var client = new FhirClient(@"https:/");
// create new Patient object
Patient newPat = new Patient();

// create identifier list item and add it to the new patient
Uri uri = new Uri("")
Identifier id = new Identifier { System = uri, Value = "PRP1660", Label = "NHI" };
newPat.Identifier = new List<Identifier>();

// create a human name list item and add it to the new patient
List<string> famName = new List<string>();
List<string> givName = new List<string>();
HumanName hn = new HumanName { Family = famName, Given = givName };
newPat.Name = new List<HumanName>();

// add DOB and gender
newPat.BirthDate = "1955-12-16";
newPat.Gender = new CodeableConcept { Text = "M" };

So there you have it – that’s half of the scenario done for you! How hard can it be?

See you in Chicago…

FHIR Connectathon

Kai has done a neat video of the latest FHIR connectathon. Kinda weird to see yourself on camera though!

FHIR Questionnaires and exchanging information

I had an interesting conversation on the skype ‘Implementers chat’ last week.

Like many others who are attending the FHIR connectathon in a couple of weeks, I’ve been working on scenarios involving  the Questionnaire resource (I’m writing a ‘template designer’ as well as a ‘form renderer’), and it occurred to me that it would be good to be able to share completed Questionnaires with others. I saw a similarity with sharing documents, and so asked the question whether the DocumentReference resource should be extended to permit the discovery and sharing on questionnaires as well.

Lloyd commented that his view was that the Questionnaire should not be a primary means of data exchange – that other resources are intended for that purpose, and that the Questionnaire doesn’t have ‘primacy’ over other resources. Grahame also commented that if you did wish to share a completed Questionnaire, then do so as you would any other resource.

That got me thinking.

A few years ago in New Zealand we developed a standard called the ‘Forms Server’ standard. The basic idea was that we would have a standardized way of representing a form template that could be shared between those needing to complete a form, and those needing the structured data within the completed form. A good example of this (and the one we were working with at the time) was a referral: in most cases when referring a patient to a specialist, there is data that is specific to that specialty that needs to be collected – a referral to a cardiologist will have different elements than one to a dermatologist.

We envisaged a central server that held these templates, and a standard that described their structure, plus the completion and transmission of the completed form. Potential referral recipients would upload templates containing the information they needed, and people making referrals would select the appropriate template to make the referral with. (We weren’t thinking of service discovery – just the templates and forms, and the manner that they could be shared). There was an associated standard way of getting data from referring systems (in our case primary care system), and another standard way of representing the actual referral, so in summary 3 major components:

  • Template structure and discovery (local standard)
  • Template pre-population (local standard)
  • Referral form and workflow (based on HL7 v2).

In the end, although the standards were implemented, it didn’t go the way we hoped. It was more of an implementation architecture than a standard, and because they were local to New Zealand, they were only ever implemented by one vendor (though the primary care vendors who were creating the referrals hosted the components and made a local pre-population service available), and so the only way of creating and updating templates was through that vendors system – as was the dissemination of the referrals.

We had achieved the goals of a particular project, but not in a way that encouraged other vendors to join the market, nor established any kind of re-use for other purposes.

So, fast forward to FHIR.

With the Questionnaire resource (and the Referral resource that is being worked on at the moment), there are now the pieces need to fulfil our vision in a truly standardized way. (In the following discussion, do remember that the Questionnaire resource fills the purpose of both template and completed form, using the status property to distinguish between them).

Template Structure and discovery is, of course, the Questionnaire resource and the standard FHIR query mechanisms. I think that there need to be a couple of extra fields to support discoverability – so you can categorize Questionnaire templates and search for specific ‘types’ of template. There are some proposals that we’ll discuss in Phoenix, but we can always use extensions if we need to.

Pre-population needs a couple of things. First the template needs a coded way of describing what information is needed, and the ‘filling’ system needs to be able to locate that data within it’s own data stores.

Well, each question in the Questionnaire has a ‘name’ property of type CodeableConcept, so all that’s needed for that is a standardized terminology like SNOMED, and possibly agreement between users about which codes to use – SNOMED is vast, and not that easy to navigate after all. So, a ValueSet containing the common terms (like usual medications, conditions, allergies etc.) to use might make sense.

In fact, the Questionnaire also allows us to use ValueSets to directly define the options for a question.

We might also want to describe the relationship between entries in a Questionnaire, and other FHIR resources or CDA documents to make it easier for implementers to convert between the two.

And the Referral resource is the final piece for this particular use case.

So we can imagine a workflow like this:

  1. The user locates the Questionnaire Template they wish to use
  2. The system downloads the Questionnaire and pre-populates it from the local data store based on the individual entries.
  3. The user enters the remainder of the data described in the Questionnaire.
  4. When complete, the system constructs a Referral resource, and likely a number of other resources (like MedicationStatement, Observation, Condition) which are placed in a bundle and sent to the recipient using any of the described paradigms of exchange.

This workflow (and the implementing systems) is completely generic, and can be re-used in any other scenario where there is some standardized form of data collection and exchange – like routine assessments, progress notes, discharge summaries etc.

It’s important to appreciate that we’re using the Questionnaire as the interface between the user and the local system – not as the unit of exchange between systems, which would use resources specific to each purpose. In this case a Referral resource, but another example could be a Discharge Summary, which is a document. (I’ve glossed over some of the details of this exchange, which actually uses other resources like Order and OrderResponse, and of course there are security /privacy considerations as well.)

In fact, if we were half way clever we’d also re-use any appropriate FHIR server. For example, we’re currently looking at creating a ‘Record Locator Service’ (which could be a FHIR server hosting DocumentReference resources) – why not use the same infrastructure to store the Questionnaire templates?

So I’m starting to think that the Questionnaire could replace the List as my favourite FHIR resource.

Let’s see what happens in Phoenix…