Interoperability geeks

Grahame in a list of interoperability geeks.

well deserved.

The Architecture and the (FHIR) Message

So now that we’ve established how we intend to build our model from HL7 v2 messages, let’s turn our attention to architectural issues. We’ll need to look at how FHIR thinks about managing messages – both in terms of the structure and content of a FHIR message, and also how the server should process those messages.

Read more of this post

The FHIR burns brighter (Ewouts state of the FHIR-nation)

An interesting presentation from Ewout about changes in FHIR in the past year – circulated by Rene.

(I particularly liked the bus…)

enjoy!

DSTU-2 Ballot

Just in case you don’t follow Grahames blog – here’s a notice about the plans for the DSTU-2 ballot this year.

And if you don’t follow his blog, then you really should…

(I may have said that before)

cheers…

FHIR Messaging: Clinical data from ADT Messages

In the last post, we started to think about how we might be able to capture clinically useful information (naturally as FHIR resources) from the HL7 v2 messages that are used within many hospitals. These messages are used to move information between the various components of a hospital such as the PAS (Patient Administration System), the RIS (Radiology Information System), the LIS (Laboratory Information System) and so forth.

A common pattern is that the ‘downstream’ systems (LIS, RIS) ‘subscribe’ to these messages emitted from the PAS – generally via an Integration Engine. So all we’ll do is add ourselves to the list of interested parties, and we’ll get a copy of each message as well.

And actually, there’s no real reason why we should confine our attentions to just one hospital – if there are multiple co-operating hospitals then there’s no reason why we can’t receive messages from all of them, though we do need to be careful with identifiers (patient and visit) as these might overlap between providers.

Read more of this post

Canadian Connectathon

For those who don’t mind snow (though I’m told that by April 29 – the connectathon date – the snow has mostly gone).

Here’s the link to the registration site.

There doesn’t appear to be a website (yet) though there are details in a PDF that you can get from the organizers I’m sure. The tracks are listed as:

  1. Patient resource client
  2. SMART server or client
  3. Questionnaire
  4. Experimental

cheers…

BTW – Lloyd did offer to arrange for snow if I came, but alas…

FHIR metadata: DTSU-2 style

FHIR resources (and bundles) have always had metadata (ID, version, tags etc), but in DSTU-1 they were external to the resource, while in the DSTU-2 candidate they are within the resource (a not uncontroversial move). This post from Furore (one of the earliest supporters of FHIR) talks about some of changes that are coming…

Oh – any by the way, just looking at the picture that’s on the front page (at the moment) of the furore site, I’m so jealous that I wasn’t at the 2014 Amsterdam DevDays – I don’t suppose you could photoshop me in there?

More FHIR Messaging: ADT messages

We’ve previously talked about converting HL7 Version 2 messages (hereafter called ‘v2’) to FHIR bundles. Let’s take that a step further and dig into a bit more detail about processing messages in FHIR.

Read more of this post

Updating Observations in FHIR

Had an interesting question put to me yesterday. We’re developing functionality to store Observations sourced both from a User Interface and also personal devices like Blood Pressure monitors, Scales & Glucose meters; and then do interesting stuff with them – like render them as a chart in a UI, make available to mobile devices, perform analytics and so forth.

As part of the testing process, one of the developers asked (as developers do) – what should we do if we get an updated observation, and the Observation.name is different from the original? It’s not impossible that the user in a UI selected the wrong type of observation (which is Observation.name in DSTU-1) initially and then sent an update through.

Putting to one side the security aspects (are they allowed to make this kind of update) and the version history – what should the repository do?

Read more of this post

FHIR in the news…

A time is going to come when FHIR news is just going to be just plain ordinary (or not worth reporting on) – but until then, articles like this (sent to me by my son who isn’t even in health IT) are still exciting!

cheers…