Getting terminology wrong is almost a rite of passage on FHIR projects.
It’s shouldn’t be. SNOMED, LOINC and ICD all predate FHIR by many decades.
LOINC – 1994
SNOMED – 1965
ICD – 1860!
So what’s the problem? Why is it so hard?
FHIR projects tend to attract developers and sometimes product people with little or no working experience in healthcare data.
Many of them come from backgrounds where words and phrases are decided on by UX and marketing people. The idea that you can’t simply “make it up” is new to them.
This leads to projects being built using FHIR where terminology is not considered important at the outset. It only becomes important when the project has progressed to the stage where more knowledgable stakeholders get involved and start asking hard questions.
At which point the problem becomes costly to fix.
- New resources with expertise have to be brought in
- Deadlines get pushed back
- Expectations reduced
- Everyone is unhappy
How can this be fixed?
Terminology needs a big box of its own on every architectural diagram. The bigger the box the better, so it isn’t allowed to slip into the background.
Your project needs terminology expertise right at the start. Someone with enough knowledge and standing to push back against the rapid fire developers who want to make it up on the fly.
And everyone on the team needs to be educated.
- A basic understanding of terminology and code systems
- How to use it with FHIR
- What NOT to do!
Start with Grahame Grieve’s video from a 2022 FHIR meetup. It explains terminology from a FHIR perspective.
https://www.youtube.com/watch?v=1WalljTHuus&t=463s
Don’t accept that getting terminology wrong is expected and ok. Consider it a project failure and a leadership failure.
---