One of my projects is to support the FAST NDH directory IG development in HL7. As part of this, I was asked to create computable mappings from HL7 FHIR Plan-Net Implementation Guide to the HL7 FHIR National Directory of Healthcare Providers and Services (NDH) Implementation Guide. Both describe healthcare directory information. They look similar, but their representations differ: extensions, vocabulary, and profiles are not interchangeable. Similar-looking data is not necessarily conformant data.
FHIR Mapping Language (FML) expresses explicit rules for transforming source data into target data, including copying fields, translating codes, and mapping extensions.
I have been using Visual Studio Code and GitHub Copilot to author and update these maps.
AI is helping write the rules. AI is not translating the data.
The translation is performed by explicit FML rules, executed using the FHIR Validator's transformation capability. There is no language model deciding what a field means each time a resource is processed.
VS Code + Copilot
|
v
FML rules
|
Source samples --> FHIR Validator transform --> NDH output
|
v
Validate NDH profilesFaster Authoring, Not Automatic Trust
Copilot made authoring and updating the FML much quicker. It helped work through repetitive mapping rules and revise them as testing exposed problems.
That is useful. It is not evidence that the resulting maps are correct.
The rules remain inspectable, editable, and testable without AI. The translation behavior belongs in those rules, not in a prompt.
Samples Are Part of the Work
I use source-conformant examples to exercise the maps continually. The samples include both:
- Data reflecting how implementations currently use Plan-Net.
- Comprehensive examples exercising more of what the source format supports.
These serve different purposes. Implementation data shows what is happening. Comprehensive examples exercise fields and extensions that everyday data might never populate.
A map tested only against sparse data can look complete while doing very little.
Multiple sample sources help expose assumptions that a single dataset would hide. Downloaded implementation data also needs scrutiny; being returned by a FHIR server does not establish conformance.
Transform, Validate, Inspect, Repeat
Scripts repeat the transformations and validate the resulting resources against the target NDH profiles. They retain outputs, logs, and per-input results so failures can be investigated.
I also use AI to spot-check source and transformed resources for lost information. Automated checks supplement that inspection, including checks that extensions intended to be preserved actually survive.
These checks answer different questions:
- Did the transformation execute?
- Does the output conform to NDH?
- Was the source information preserved or intentionally translated?
Passing profile validation does not prove that nothing was lost. AI spot inspection does not prove it either. Both are useful, but neither replaces explicit preservation checks and broader test coverage.
The Point
This is a practical use of AI: accelerate development of deterministic, reviewable transformations, then test them repeatedly.
Use AI to help write the translation. Do not confuse that with trusting AI to perform—or certify—the translation.
For a deeper discussion of this approach, see Firely's Language Models Should Write Your FHIR Mappings.