Managing the Medication List in SNapp, part 1.

So, in the last post we talked about setting up a FHIR server, and populating it with some sample data. Let’s turn our attention now to how we would interact with that server in the context of a ‘Medication List’, and we’ll use the STU-3 release candidate (as used at the recent Baltimore connectathon) as the basis of the discussion, though this should work just as well in older versions.

(Our discussion will generally apply to other lists – such as Allergies and Problem lists – though it’s not uncommon for there to be multiple Problem Lists for a patient that are ‘clinician focussed’ e.g. the list of significant problems from the perspective of a respiratory physician tends to be different to that from the perspective of an orthopedic surgeon. But I digress…)

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

Follow-up questions from FHIR & Ice

At our recent ‘FHIR & Ice‘ seminar, we tried to answer as many question as we could, but we did ask people who attended if there were outstanding ones that we could have covered. Here is our attempt to answer them, I did the FHIR ones and my colleague Alastair Kenworthy the SNOMED ones.

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

FHIR DSTU-2 Profiles

A couple of posts on Profiles in the DSTU-2 candidate from the guys at Furore:

These guys have been involved with – and supported – FHIR from the very beginning, are the maintainers of one of the FHIR test servers (Spark) and are also the authors of the reference profile editor (forge) so they know their stuff!

FHIR Searching using POST

Another little thing that has some up as we implement our FHIR services is what HTTP verbs you can use when submitting a query. The ‘usual’ way to do this is with the GET verb, but the spec states that it is also legitimate to use a POST to the _search endpoint, with the parameters as an x-multi-part-form submission in the POST body.

Read more of this post