Trans Tasman Connectathon

So the first trans-tasman connectathon (at least in a little while) is going to be held in a few weeks. There are 3 main streams – 2 of them associated with SMART – that Grahame has written about  and the third one is the IPS – International Patient Summary Implementation Guide, which I’m going to attend.

For those unfamiliar with IPS, it defines a base summary (as a FHIR document) of key clinical data about a patient that was originally intended for patients travelling in different countries to be able to provide medical information to healthcare providers data if needed – but has grown a bit larger than that, and is being widely adopted globally.

The track itself defines a number of actors:

• The creator of an IPS document – for example an EHR (Electronic Health Record). This actor will supply the IPS document on request (there’s a specific operation – $summary – defined for it)
• The source of information for the IPS  (often, but not always the creator)
• The consumer of a document. This actor will make the request, and then do something with the response. What will they do? Well, they could:
  • Display the contents in some patient friendly way (eg a patient portal or mobile device)
  • Extract the contents and update their local store. This could be another EHR, or a mobile application. This use case brings the additional ‘merge’ requirements – comparing the information in the IPS document with existing data – no simple task! This is the ‘document process’ role in the track description
  • Store the document somewhere as a ‘point in time’ summary. Maybe using the contents to plot changes over time.
  • Let the producer know about any errors – there’s an IG being developed for that – the Patient Corrections IG that you may be interested in.

And there will be a number of specific use cases that people can participate in – refer to the track description for more info.

I’m going to be doing a number of things over the course of the event (a couple of days) – and the days leading up to it.

First I’m going to tidy up the clinFHIR Bundle Visualizer to more easily request an IPS document from a server and display the contents. It will also validate the contents to measure compliance with the IPS specification. This should be of value to servers implementing an IPS endpoint as well as useful to FHIR beginners as it has a number of useful visualizations.

I’m also going to use Node-RED to create an IPS document from a FHIR server using a ‘facade’ pattern. This will expose a ‘$summary’ endpoint, assemble an IPS document from a backend server that exposes individual resources and returns the assembled document. If you have a data source, but are not yet exposing FHIR data (and know that you need to), Node-RED is a great way to get started, before committing development resources to a more production ready (and secure) solution. 

If you’re in this category, then reach out to me and I’ll be happy to point you in the right direction – I’ve written about Node RED a few times on my blog site, and will write more about this use case when it’s ready.

This is also a rather good track for the ‘non-technical’ folk, or those unfamiliar with FHIR as it introduces you to the key FHIR concepts in a gentle way:

• Resources as the data models – the ‘molecules’ of information like an allergy, medication or condition (what we’d have called a ‘problem’ in the old days).
• Datatypes as the structure of the contents of the resources (the atoms in the molecules). 
• Connecting the resources together to  create a ‘graph’ or ‘web’ that represents a specific use case (in this case a clinical summary). This is done using a specific datatype – the Reference
• The importance (and complexity) of terminology – coding information so that it can be properly understood by participants – ‘semantic’ interoperability
• The Implementation Guide (IG) as the description of how to use FHIR for specific usages (or scenarios). The FHIR specification itself is a platform spec – it’s the underlying infrastructure to use for any healthcare interoperability and is very generic. IG’s are the ‘next big thing’ for FHIR

All you need to do is to use a REST client like POSTMan to make the requests and you can view the resources, and examine their connections. Of course, it’s way easier in clinFHIR – and the Bundle Visualizer has a number of different ways to view the resources (raw json/xml isn’t that user friendly)

The proposed API to retrieve the IPS document is currently:

GET [host]Patient/$summary?profile=http://hl7.org/fhir/uv/ips/StructureDefinition/Bundle-uv-ips&identifier={identifier}

You can specify the format (Json / XML) either using the standard headers or the _format search parameter.

Attending a connectathon is a great way to interact with the FHIR community – it’s a time when the experts are all working on the same thing, and a great learning opportunity to get started in understanding this important interoperability standard.

So, given that the event is free – and anyone can join – I look forward to seeing you there! Sign up details are here.