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 post
Recent Comments