HL7® FHIR® is an established standard for significantly lowering the technical barriers to healthcare interoperability by building on concepts that are widely used in other domains such as the finance and travel industries. This provides concepts familiar to the implementer community and makes FHIR easier for organizations and people unfamiliar with healthcare to participate. It also allows them to bring forward their innovative ideas for the benefit of patients and providers.
But what about the healthcare providers themselves? How does FHIR help them participate? The issue is that healthcare is inherently more complex than other industries, partially due to the increased security needs around sensitive medical information. Healthcare is also a domain that we are learning about rather than defining – and these days with the advances in genomics and other disciplines it is becoming ever more so. We need clinicians deeply involved in healthcare projects – it’s well recognized that projects that are clinically led have a higher success rate than those that are technically led.
FHIR does help – but it’s not enough by itself. In the past few months, we’ve been working on a process to make it easier for clinicians to communicate their requirements to the technical people responsible for implementing them. This is being tested in a New Zealand project to capture Adverse Events and make that information available to those delivering medical care, as well as for reporting and other analytical purposes.
We started the project by firstly defining the requirements – what we wanted to achieve (as described above). This included a number of specific scenarios to cover off the range of use we were expecting.
Next, we described the high-level architecture within which the project would operate. This helped us define the nature of the exchanges needed to fulfill the requirements. In our case we wanted to capture Adverse Event data and store it in a common repository for sharing and analysis, respecting privacy of course.
To define the information needed, we used the clinFHIR Logical Modeler. This allowed us complete freedom in terms of the actual layout of the individual data elements but meant that we could take advantage of the datatypes defined by FHIR – which both saved time and will make the eventual transition to ‘real’ FHIR artifacts easier. In practice, we used a data projector to display the model as we were building it, and updated it in real-time during regular meetings. This saved time compared to sharing and reviewing documents that had been updated separately. Having created the first draft of the model, we used a new clinFHIR component – conMan (Connectathon Manager – a purpose-built tool for supporting FHIR connectathons) – to automatically create a Forms-based User Interface from the Logical Model into which we could enter the data required for each of the scenarios that we defined in the first step. This allowed us to validate that the model was fit for purpose – that it has ‘spaces’ for all the information that we require.
The next steps for the Adverse Event project will be:
- Define the real FHIR artifacts required – the Profiles, ValueSets, CodeSystems that will form the eventual Implementation Guide
- Publicize the work among the implementer and clinical communities, and invite feedback
- Then we’ll hold a FHIR connectathon involving both clinical and implementers for pseudo ‘real-world’ testing
- Finally, we will produce the implementation guide which will be available to educate and upskill clinicians wanting to understand how FHIR can improve the collection of Adverse Event data.
Read my white paper, FHIR for Clinicians, where I discuss what a clinician needs to know about FHIR to be able to knowledgeably participate in health IT projects.
