Thoughts and comments on the HL7 FHIR standard, from a FHIR Evangelist
October 7, 2017 5 Comments
These are some notes written by Lloyd, Grahame & Eric about using Observation in practice. I’ve copied this directly, here so I always know where to find it. You should refer to the source for the most recent version.
September 30, 2016 2 Comments
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…)
February 18, 2016 3 Comments
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’?
August 7, 2015 4 Comments
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.
June 21, 2015 1 Comment
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.
June 20, 2015 7 Comments
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.
March 3, 2015 2 Comments
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!
March 2, 2015 Leave a comment
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.
March 2, 2015 2 Comments
When writing a server that can respond to FHIR queries, it may not be clear what to do when you get a search parameter that you don’t understand. Or, for that matter, which of the defined search parameters against each resource you do need to support.
February 24, 2015 8 Comments
I was approached by one of the Dev teams here at Orion Health for some help in ‘FHIR-enabling’ a patient selection service that they have been asked to build. My initial reaction was that we could model this directly as a restful query against /Patient, but after talking to them, the requirements were a bit more complex.
Recent Comments