Thoughts and comments on the HL7 FHIR standard, from a FHIR Evangelist
May 27, 2021 1 Comment
So there have been a few comments on the series thus far (a good thing!) through a number of channels, so I thought I’d quickly address them before moving on to the implementation discussion.
May 26, 2021 5 Comments
In this post we’re going to take a look at more aspects of coding data. We spent a bit of time in the last post describing why we want to have data coded, how FHIR supports coded data – especially the external terminologies where the concepts are defined – and described some of the RESTful API calls that we could make to retrieve specific Observations and DiagnosticReports from the repository.
But in doing so, we make one key assumption – that all the data in the repository was properly coded with consistent codes – and this is actually not that common in the real world, especially for repositories that are collecting data from different sources. (It’s a bit easier when it is a single lab exposing their data and have complete control over the coding used)
So let’s think about how to manage the situation where there may be different codes that mean the same thing, a good example of which is where labs are using their own coding system rather than an external one such as LOINC.
Ideally what we want to be able to do is ‘map’ all of the codes that mean the same thing to a single concept – preferably a concept from a known codesystem which as LOINC or SNOMED.
We’ll focus on setting up the ‘definitional’ part of the mapping here – in the next post we’ll talk about implementing it.
May 25, 2021 4 Comments
In the previous post we took a look at the overall organization of the resources involved in representing Laboratory tests and what an API to retrieve them might look like.
But the queries that we discussed were rather ‘blunt’ – just retrieving results for a person with minimal filtering. While that’s often needed, being able to make more targeted queries can be a whole lot more useful (especially when we want to chart it or include data into Decision Support routines), and that brings us onto the topic of coding the data – the subject of this post.
May 23, 2021 4 Comments
This will be the first post in a short series that considers a very useful interaction – accessing Laboratory data such as blood tests from a repository of data via (of course) a FHIR API. The actual repository we use doesn’t really matter – it could be a part of an EHR, or an interface that the lab exposes or it could be a standalone data repository such as a regional or National store – it’s the API that counts.
There are a number of different perspectives that we can take, of which two are:
In this post we’ll take a look at the first perspective – accessing a single person’s data. We’ll consider the clinicians perspective in a subsequent post.
Read more of this postMay 11, 2021 1 Comment
When an Implementation Guide is built by the IG Publisher (and presumably other build applications like simplifier), one of the outputs is a zipped package (actually a tarball) that contains all the FHIR resources defined by the Implementation guide – profiles, extension definitions, terminology and conformance resources and such like. It’s based on the NPM package scheme as described on the HL7 Confluence page.
This package can then be saved in the International FHIR registry so that it can be discovered and downloaded by implementers. There’s a description of the registry on the HL7 confluence site, as well as from the registry itself.
While the package doesn’t contain the textual part of the IG, it does have all the computable artefacts that an implementer might need, as well as a manifest file (package.json) which contains a number of goodies about the IG – such as the canonical url, which can be used to view the full IG.
This post is to introduce a new clinFHIR module that can display the contents of a package. It works by downloading a copy of the package from the FHIR registry and saving it on the clinFHIR server. Subsequently, the contents can be displayed to the user. The download only needs to happen once, as a particular version of a package is immutable – it is guaranteed not to change.
April 12, 2021 7 Comments
I’ve been asked to give a short talk about clinFHIR to a course at Johns Hopkins this month – what it is and what you’d use it for, so to organize my thoughts I decided to write a ‘stock take’ of clinFHIR modules. This is actually part of a project I’ve been working on for a little while – learning FHIR with clinFHIR – so it’s a perfect time to be doing it.
The idea for clinFHIR started shortly after FHIR started to gain prominence within HL7 – coming up to 10 years ago now. The technical folk understood what the developers were trying to do – utilize internet standards to share healthcare data – but it was harder for the clinical folk to gain that understanding and appreciate the significance.
clinFHIR (Clinical FHIR) was envisaged as a way to visualize FHIR – particularly resources and the references between them – so that the committees within HL7 responsible for authoring resources could advance their development. We worked closely with the members of the ‘Patient Care’ committee in particular – they had sessions at most Working Group Meetings called ‘Clinicians on FHIR’, and we developed clinFHIR as one of the main tools for them.
(And I’d like to recognize all the work they put into this – it was an on-going balance between evolving the application to meet identified needs, and dealing with the bugs that a rapid development cycle brings!)
Read more of this postApril 6, 2021 1 Comment
So we’ve talked about how to represent an immunization program both in the abstract (the overall definition of a national plan) and the specific (the plan applied to an individual). In addition, we discussed how to submit the actual administrations to the registry.
What we haven’t really talked about is how to measure the performance of an individual against the plan.
Read more of this postMarch 30, 2021 6 Comments
So we’ve made a few proposals in the last couple of posts:
The next thing to think about is how to generate the ImmunizationRecommendation (IR) from the PlanDefinition.
This could be really complicated, depending on the circumstances around the generation. For example, if we just wanted the recommendation for a new born then it’s quite easy. If we wanted more ‘smarts’ – e.g. the recommendation for someone of a given age considering their immunization and clinical history, then it becomes rather more complicated. In this post we’ll keep it simple and not look at the patient’s history, focusing on the ‘mechanics’ of the generation.
As a background to the discussion, let’s think about how a client might use the registry API.
Read more of this postMarch 27, 2021 4 Comments
In the previous post we discussed how an immunization registry might receive Immunization resources documenting the administration of vaccines to an individual (complicated), and how to expose those resources to a client (easy).
But vaccine administrations don’t exist in a vacuum – they’re generally related to some particular plan consisting of multiple administrations of different vaccines over a period of time with the intent of providing the recipient with protection against specific diseases. (And, as COVID has emphasized, protection of the planetary population as a whole).
So we need a way to represent that general plan, customize it for an individual – and then a way to link individual vaccine administrations back to that plan so we can be sure that an individual is receiving the vaccinations they should be. And we want to be able to report on this administration at a population level as well as the individual.
That’s a bit more complicated than it might appear.
Read more of this postMarch 26, 2021 8 Comments
In New Zealand (and other places as well I expect) we’ve had a national registry for immunizations for a number of years – the National Immunization Register or NIR
It’s currently fed by HL7 version 2 messages and there’s a User Interface for authorized users, but there was always a plan to introduce a FHIR interface to some point – something that has been accelerated by the current COVID pandemic of course.
Read more of this post
Recent Comments