FHIR enabling an Immunization registry – part 3

March 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 post

Filed under Immunization, Uncategorized

FHIR enabling an immunization registry – part 2

March 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 post

Filed under Immunization, Uncategorized

FHIR enabling an immunization registry

March 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

Filed under Immunization, Messaging, version 2

Extending a required binding on ContactPoint

March 2, 2021 4 Comments

So we’ve got an interesting issue in New Zealand (from a FHIR perspective of course). We’re in the process of creating extensions to be used nationally, and one of the requirements we have is to be able to store the HealthLink EDI number – an ‘address’ used to send information electronically between healthcare providers.

Some background: in New Zealand we have a messaging service that is operated by a private company (HealthLink) which has national coverage that connects Primary care with Hospitals, Laboratories and other services such as eReferrals. It’s actually been running for a number of decades and has certainly helped with electronic sharing of information. The company provides vendors with client-side applications they they use to interact with the service.

Users of the service are assigned a unique code (the EDI number) that acts as a delivery address for the user (which can be an individual or an organization). For example, when a hospital wishes to send a Discharge Summary to the patient’s General Practitioner (their Primary / Ambulatory care provider) then they will send the summary to the service, asking for it to be delivered to that EDI account.

As we move into FHIR, the question is how do we represent that number? For the purposes of this discussion, we’ll assume that we wish to attach it to a Practitioner resource, though it will also need to be applied to others such as Organization or PractitionerRole.

Read more of this post

Filed under Uncategorized Tagged with

Using prototypes in app design

August 18, 2020 1 Comment

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

Filed under clinFHIR, development

Slicing with Sushi

May 1, 2020 10 Comments

As readers will know, I’m a big fan of FHIR Shorthand as a way of making it much easier to create Implementation Guides and examples in conjunction with the IG publisher. In fact, I’m coming to the conclusion that all systems that expose FHIR API’s should have an IG that describes it (along with the CapabilityStatement resource of course) – and unless you have experience with creating StructureDefinitions directly, then FSH – and SUSHI – is the way to go.

Of course, creating IG’s is still not easy (it’s just easier) so I thought it would be a good idea to write about common patterns that you might want to express – and serve as a reminder for me when I forget! Read more of this post

Filed under Profile, sushi, Uncategorized

Custom Implementation Guide templates

March 12, 2020 4 Comments

As you’ll likely be aware, FHIR uses Implementation Guides (IG) to describe how to use FHIR for specific scenarios or use cases. In the past it has been technically challenging to create these guides, but this is changing – in large part due to new tooling/approaches like shorthand and sushi, but also because the FHIR community (and especially Lloyd) have been working on a template based publisher.

The idea behind the template based publisher is that there are a number of standard templates for specific purposes such as an ‘official’ HL7 FHIR IG or a plain template, and these can then be adapted for specific purposes – such as a National IG or a vendor specific one describing a FHIR based implementation. The project is still relatively new, but becoming stable enough that people are able to use it. However, the newness means that the documentation is still catching up, so when my colleague Jose Costa Teixeira offered to write a ‘beginners guide to creating your very own template’ I said great!

He’s published it on his blog, but kindly allowed me to reproduce it here.

Without further ado, take it away Jose… Read more of this post

Filed under Uncategorized

Family FHIR – with sushi

February 10, 2020 6 Comments

I was trying to remember how to represent family relationships in FHIR – to record that one person is related to another, maybe a mother / daughter relationship, assuming that each person is already represented by a Patient resource. I asked my good friend Brian Postlethwaite who kindly didn’t say “I’ve told you this before”, but rather pointed me at the RelatedPerson resource and the example in the spec.

For example, to create a link from mother to child, what you do is to create the 2 Patient resources that represent the mother and the child, then create a RelatedPerson resource that directly references the child (the ‘to’ of the relationship) through the RelatedPerson.patient element, and then use the mothers Patient.link to refer to that RelatedPerson (the ‘from’). In effect both the mothers Patient and the RelatedPerson resources both have information about the mother (hopefully not contradictory) and it’s the RelatedPerson.patient &  RelatedPerson.relationship that provides the relationship to the child. The Patient.link then has a type of ‘seealso’ to the Related person.

Read more of this post

Filed under sushi Tagged with

Creating examples

January 31, 2020 3 Comments

Examples are probably one of the more useful things to an implementer – yet likely the least exciting part of building an Implementation Guide (IG) to the designer. And not only are they useful to the implementer, they are a good way to double check the actual IG – it’s surprising how often having to create an example finds issues with the artifacts within an IG.

But the tooling to create examples is not that great. Generally you’re using a generic JSON or XML tool which offers no editing support to ensure that the example is valid (you can use the $validate operation that I’ve discussed before, but the workflow is tedious). I’ve tried to use clinFHIR for that – and it does work, though chokes some of the more complex profiles, and is still quite slow to create the resource instance.

There is an alternative that I’m currently using that seems to resolve these issues – the shorthand spec (with associated sushi reference implementation) that I blogged about last week. As well as producing profiles, it can also create resource instances using the same syntax as for profiles, and even better – when you run sushi to generate the resources, it will pick up the more egregious errors.

Read more of this post

Filed under Uncategorized

Connectathon – with sushi

January 24, 2020 3 Comments

The 23rd FHIR connectathon in Sydney is almost upon us, and despite the trials and tribulations that the weather has thrown at us, it’s going to be a great event with over 150 people currently scheduled to attend. There are 15 tracks, a number of which are for local initiatives (like the Primary Care track or ePrescribing track) as well as the more general ones, so there’s plenty of choice for attendees. We do recommend that you choose one track as your primary track – perhaps observing others of particular interest – as that seems to bring the best benefit to attendees and the spec.

For myself, I’m going to participate in the FHIR shorthand  track. This is an initiative being driven by the Mitre Corporation in the US, which is a not-for-profit organization heavily involved in the FHIR community to create a simpler way to produce FHIR profiles.

Read more of this post

Filed under connectathon, Profile

← Older posts

Newer posts →