Custom terminology pops up in most FHIR projects.
No matter how well intentioned the team, it’s almost impossible to build a solution involving healthcare data without needing to define some of your own terminology.
Here’s a common scenario.
A new project starts up using a managed FHIR server as its primary data store. The project leads are determined to do everything the “right way.”
They understand that custom terminology is not easily shareable, not “interoperable.” As such, they consider it bad by default.
But the problem begins when the team are unable to map every value their solution uses to a corresponding value in a common code system such as SNOMED or LOINC.
The terminology expert on the team comes up with close matches, but close is never good enough.
Precision is required. A correct and meaningful value is required.
So they bite the bullet and begin documenting their own code system listing all the custom values they need to use.
A FHIR CodeSystem resource is created to act as the master list. Its URL uniquely identifies the new code system.
ValueSets are updated to include a combination of the preferred SNOMED codes along with the one or two custom codes needed to complete the list of allowed codes.
Most FHIR projects reach this point at some stage in their development process. It often feels wrong, as if a degree of interoperability is being sacrificed.
This is true, but there’s often no alternative.
SNOMED, LOINC and other code systems are incomplete. Their update processes are slow.
Sometimes there’s no escaping a degree of custom terminology.
If you find yourself in the situation where custom terminology is required, you should strive to formalize that terminology as early as possible.
Here are the steps to follow to properly define your new terminology: https://darrendevitt.com/defining-custom-terminology-in-fhir/
---
Download my “FHIR Architecture Decisions” book
FHIR Weekly
Join 1,100+ business and technical leaders.