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

Terminology Services in FHIR

I must admit I haven’t paid as much attention to Terminology as I should.

I do appreciate how important it is – most (if not all) resources in FHIR have multiple coded elements that refer to a terminology of some sort, and a common understanding of concepts is one of the key parts of interoperability, but until Grahame asked me to talk to this subject at the recent Brisbane Seminar & Connectathon, I’d regarded coded items as just another datatype.

But DSTU-2 brings a whole new set of possibilities to the picture, so let’s look at how that helps us.

Read more of this post

Mapping to ‘code’ datatype elements

So we’re providing a FHIR interface to our existing data repository. The repository is populated from v2 messages (among other sources).

One issue we’ve come across is when mapping to a code datatype with a fixed value set and you have a code that is not in the fixed set (Something I assume will be quite common). The ‘official’ way to manage this is to find the closest match from the fixed set and use that, and then create an extension to put the more specific code. The thinking is that anyone compliant with the specification will understand the fixed set value, and it shouldn’t matter if they don’t understand the more detailed one (you’d use modifierExtension if it did matter).

But what do you do when you can’t tell what the most appropriate mapping is? Suppose your system collects data from other sources and you don’t have control over what coding those sources use? (Now, I know you should, but this doesn’t always happen). And there are situations out there where only text is provided…

Read more of this post

Providing UI hints for FHIR queries

One of the requirements we were given when developing a patient based Observation query at Orion Health was that the response bundle needed to indicate that the user making the request was able to add new Observations for that patient. This was so that the User Interface (UI) could provide the appropriate link – or not, as the case may be.

Now this is a bit of a tricky one for a number of reasons.

Read more of this post

Transactions in DSTU-2

One of the many changes that occurred in DSTU-2 (at least in the candidate spec) was the way in which transactions are managed in REST. Not so much what a transaction is (that’s reasonably well defined) – but how it is implemented. For a start, a bundle (used for a number of purposes as well as a transaction) is now a resource in it’s own right (rather than an Atom feed).

But apart from this structural change, the transaction has become more closely aligned with the simpler REST interactions – it’s easier to see how a transaction can be thought of as a sequence of simple interactions that succeed or fail as a whole. Let’s start by taking a look at the Bundle from the perspective of Transactions, including some more tricky aspects to how IDs are managed when you want to create a resource that needs to be referenced by another within the same transaction.

Read more of this post