The Seven Stages of FHIR Data Modeling
Subscribe to our newsletter
SubscribeAs a clinical informatician, you know your data inside and out. But translating that expertise into the world of FHIR can be a whole new ballgame. FHIR’s unique requirements and terminology, with its resources, profiles, and implementation guides, might feel unfamiliar at first.
But luckily the process can be broken down in comprehensible steps. Many will be familiar, like close collaboration with data providers and consumers to define the needs and getting their feedback at every turn. Others may be new, but FHIR modeling and documentation can be learned quickly with the right tool and continuous validation.
Whether you’re tackling FHIR modeling solo or leading a team, understanding the journey is key. Here’s a breakdown of the seven essential stages every FHIR specification project navigates on its path to enhancing healthcare interoperability.
1. Defining the Use Case
Having a single clear use case in mind is essential for ending up with a quality FHIR data model. Together with all stakeholders, define what interoperability problem you are looking to solve and what the intended outcomes are.
2. Defining the Logical Model
Now that it’s clear what the problem at hand is, it’s time to define what data needs to be captured, stored and transferred to address it.
Without being concerned with the FHIR data model yet, define which entities are involved, which attributes need to be captured and of what data type they are. This is also the moment to think about what possible values an element can have to be able to determine relevant terminologies.
Tooling-wise, the FHIR logical models can be used for this, but a good old spreadsheet will already get you a long way.
3. Build your FHIR resources
Taking the logical model, see what FHIR resources apply to your use case and how they map to each other. Using a graphical editor like Forge, or the text-based modeling language FHIR Shorthand, we start to constrain the top-level FHIR resources to the requirements of our data model.
Commonly your new FHIR model will not exist in a vacuum, but builds upon FHIR resources with wider applicability, like a national or disease specific FHIR model.
4. Validation and Quality Control
While building, it is important to continuously validate that your FHIR model is consistent with the core FHIR specification, any parent data models and your institutional agreements on modeling. Additionally, you want to generate plenty of example FHIR instances, to show how your data model should (or should not) be used in practice. These too should continuously be verified against your data model.
5. Documentation with an Implementation Guide
Around the machine-readable resource you have now created, you want to provide those who will implement your specification with clear and concise documentation. This is what is called a FHIR Implementation Guide, which in practice is a dedicated website showcasing your use case, the developed resources and any information that your consumers will need to correctly implement the data model.
6. Publish the FHIR release artifacts
Once your specification is ready for others to review, you will need to generate a stable version of both the guide and the resources. This will give your consumers a fixed version to work with during their review or implementation, while freeing your hands to already work on the next iteration.
A stable release of FHIR resources is called a FHIR package, which is nothing more than a fancy ZIP file including all the relevant resources as they are in that moment in time. FHIR packages get a name and a version number and will from then on never change and always be around, though you can mark them as deprecated when needed.
Once a package is published, an accompanying stable version of the Implementation Guide is released to go along with it.
7. Collect feedback
While input and communication with all involved parties is important in any part of this process, a balloting step is generally used for a formal approval or evaluation. Issues can be reported against the release for review, and, for approval, votes are cast on the readiness of the guide.
From here you continue again to step 3, enhancing your FHIR resources and Implementation Guide based on the collected feedback, and publishing new releases whenever needed.
Where to next?
I hope the above conceptual breakdown of the stages of any FHIR specification project helps you to get a better grasp of process and how to get started. For a more detailed breakdown, you can download the FHIR for Jurisdictions Handbook or reach out to our team if you have any questions.
