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

Using prototypes in app design

I’ve always been fond of creating functional prototypes when designing apps. There are a number of advantages over simply documenting what the app should do:

  • It means that the users (e.g. clinicians) get to try out something that actually works (sort of) before ‘signing off’ on the requirements. This reduces the chance of delivering something that doesn’t quite meet their needs.
  • It helps significantly with the FHIR design. Assuming that the app actually communicates with a FHIR back end (which can be one of the freely available reference servers such as HAPI), then it validates the resource design (which resources are needed and their profiling) as well as the API’s that are going to be needed. This can be quite a tricky step to implement depending on what the real back end is going to be.
  • It’s much simpler and quicker to develop than anything that needs to be ‘production ready’. For example, you don’t generally need to implement any security or handle the errors that need to be allowed for in a real application.
  • It delivers solid requirements to the development team, as well as a test app that they can use as the API is developed.

Read more of this post

FHIR Bundle Visualizer

So a little while back I wrote about an app I developed during the WGM Connectathon to send an HL7 v2 message to a converter app, and display the response (a FHIR Bundle) in a number of visualizations after validating it using the community supplied validation tool (actually, exposed by the reference servers via the $validate operation). It occurred to me that this visualization might be of use to implementers who are developing query applications – such as the CSIRO Primary Care project for example, so I pulled it out into a separate application.

Read more of this post

What’s an API?

I was asked recently by a clinical colleague what an API is, and why it’s important.

Let’s start with the technical answer. ‘API’ stands for ‘Application Programming Interface’ – it’s a way that one application (or a component of an application) exposes its services (which could be just data, or some operation against data) in a way that allows another application (often called the client) to use it. By using an API, it’s possible to develop re-usable libraries – components that can be used by other applications to develop functionality.

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

Building an Information model.

As described in the previous post, an Information model is used to capture the data requirements for a use case in a structured way, using the FHIR datatypes, but not aligned with the core FHIR resource types. This means that you can’t create an instance of this model – it’s just for analysis – but it will inform the development of the real FHIR artifacts.

Read more of this post

Creating models with the Logical Modeler

It’s been a while since we talked about the clinFHIR Logical Modeler, and I’ve had a few questions about it, so I thought an update might be in order.

The term ‘Logical Model’ can be used in different ways (much like ‘Profile’) so let’s first define just what we are talking about. Basically, it’s just a hierarchical model of data – much like you see in any of the core FHIR resource types – with the exception that the model does not have to align with any of the core types. Other than the requirement that you must use the FHIR datatypes, there are no limits on the complexity of the model you create (though overly complex models can be hard to understand – or use).

In this post we’ll talk about the general aspects of using the modeler – subsequent posts will go into more detail about how to build them.

Read more of this post

Creating documents in clinFHIR 

I did a demo of clinFHIR for the Clinicians on FHIR group that will be meeting at the Working Group Meeting next week, and completely forgot to talk about creating/viewing documents in clinFHIR using the scenario builder. This is functionality that has been around for a while, and allows you to create a FHIR document by adding a Composition resource to the scenario, and then linking up the other resource to it.

So I thought I’d do a post on it!

Read more of this post

Creating Clinical and Analysis models

As you may know, one of the things that excites me about FHIR is the potential that it has to involve the clinician in the design of health IT systems (and I’m using ‘clinician’ in the widest sense – doctor, nurse allied health etc – anyone who delivers care to a patient).

So far a lot of my thoughts have been theory rather than practice, so it is great to try these ideas out on a real project – the reporting of Adverse Drug Reactions (ADR) by a clinician to a central service – such as a National EHR!

Read more of this post