Bundle Visualizer for Trans-Tasman Connectathon

So in the previous post about the upcoming Trans-Tasman connectathon I mentioned that I was going to work on a couple of applications in the IPS track – a way of visualizing IPS documents (actually any kind of FHIR document), and a ‘façade’ application that could produce an IPS document on demand from a back-end data source.

This post is an update of where I’ve got to.

Read more of this post

Accessing lab data via FHIR – part 1

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:

  • Accessing data about a particular person – whether by the person themselves or an authorized clinician.
  • Accessing data from the perspective of the ordering clinician – e.g. all the tests they have ordered, but not yet reviewed. This would return the results belonging to multiple people.

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

Contained resources – MedicationStatement

Continuing our ‘mini-series’ on the SNapp event, one thing you may come across when consuming MedicationStatement resources are ‘Contained’ resources. We’ve talked about them before, but in the interest of having all the SNapp information in the same place let’s take a look at what they are.

Read more of this post

Thoughts about updating Registries

In New Zealand we are lucky enough to have had a national patient registry for some years which serves as a unique identifier of patients in New Zealand – the National Health Index or NHI. The Registry is an instance of an EMPI (Enterprise Master Patient Index) and currently  exposes a SOAP interface that can be accessed by clients across a protected network.

In order to make it available for more users we are working in a project to expose a FHIR API that will offer similar functionality to the existing SOAP one, be simpler to use, available across the public Internet and so accessible to a wider range of clients in support of the healthcare ecosystem. We’re also looking at similar work for Provider registries.

Read more of this post

Creating a resources model

This is the third post in a mini series on using the Logical modeler. In the first post we talked in generalities of models (admitting that this is very much a work in progress), and then we discussed the Information Model – a model that is used to capture clinical requirements for information exchange. Now, it’s time to think about how we can design real FHIR artifacts from the work so far.

Read more of this post

More about contained resources

So this is going to be a really short post.

There was a question on the Implementers chat about the ability for contained resources to reference each other (ie where there are multiple contained resources within the same parent.

Here’s the question (slightly paraphrased):

The FHIR spec states that Contained resources can’t contain other resource (understandable). But I thought I had seen references from those contained resources to other contained resources within the same parent. Is that valid?

eg: a Medication resource is contained within a MedicationStatemement resource. The Medication references other Medication and Substance resources, also contained within the MedicationStatemement.

Read more of this post

Responsibilities of a FHIR client

As we start to do more ‘real’ work implementing FHIR here at Orion Health, we wind up making a number of implementation decisions about the interfaces we develop, and these – of course – influence how clients will use the services we create. Naturally, we will use the Conformance resource to document these, but it got me thinking about the overall responsibilities of a FHIR client. Read more of this post

Supporting SNAPP: Accessing New Zealand Medicines Terminologies With FHIR Terminology Services

A guest post from Peter Jordan – author of the Patients First Terminology server that will be available for use at SNApp, and frequent HL7 FHIR Connectathon attender…

Take it away Peter…

As those developing healthcare applications for the local market are well aware, and overseas developers preparing for the ‘SNAPP’ event at the upcoming SNOMED conference in Wellington, are becoming aware, New Zealand has its own medicines terminology. Interacting with this terminology – broadly known at the NZ Universal List of Medicines (NZULM) – is one of the many challenges facing SNAPP participants.

Read more of this post

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