An API is not interoperable until the codes agree. By January 2027, payers covered by CMS’s 2024 interoperability rule must run a set of FHIR APIs, as our review of the 2027 deadline described. The APIs will move data in a common structure. Whether the data means the same thing at both ends depends on the codes inside it.
Structure is the part the industry has learned to test. A message either fits the profile or it does not. Meaning is harder. A lab result can arrive in perfect FHIR with a local code that no receiving system recognizes, or with a standard code that names a slightly different test. The message passes every structural check and still says the wrong thing.
What the APIs guarantee
The FHIR profiles behind the payer APIs, chiefly US Core, set the shape of each resource. They also bind many elements to code systems. Lab results point to LOINC and medications to RxNorm, for example. The USCDI version 3 baseline, required in certified health IT since January 2026, names a vocabulary standard for each data element, as our review of the baseline described.
Many of those bindings are extensible. An extensible binding asks the sender to use a code from the named value set when one fits, and it lets the sender use another code when none does. That flexibility keeps data flowing. It also means a conformant message can carry codes the receiver has never seen.
There are good reasons for the flexibility. Standard code systems lag behind new tests and new drugs, and a lab cannot wait for a code to exist before it reports a result. The problem is not that local codes exist. It is that nothing in the exchange forces anyone to reconcile them.
Conformance testing reflects the same split. A test can confirm that a code is present and well formed. It cannot easily confirm that the code means what the sender intended.
Where meaning breaks
Even with a standard in place, codes drift. In a 2019 CAP Today report on laboratory standards, a researcher who studied a common clotting test found labs assigning different LOINC codes to it. Another expert noted that LOINC has more than 600 codes for serum glucose. Each choice can be defensible on its own and still break a comparison across labs.
The cost shows up downstream. A payer that looks for a diabetes test result by its LOINC codes will miss a result that arrives under a local code. It may then report a gap in care that the patient does not have, and ask a clinician to repeat a test that was already done.
Drugs show the same problem across benefits. Pharmacy claims identify a drug by its National Drug Code, while medical claims usually use a HCPCS billing code, as our analysis of drug prior authorization described. A payer that keys a rule to a single code set will miss requests that arrive in the other.
Prior authorization depends on codes more than most exchanges do. The Da Vinci guides look up coverage requirements from the codes on an order. When the order and the payer’s rule use different codes for the same service, the lookup can come back empty. The clinician may not learn about the requirement until a denial arrives.
A message can pass every structural test and still say the wrong thing.
Payers already feel the strain. In a Black Book Research survey of 118 payer IT leaders released in October 2025, half named data mapping and normalization as a blocker to FHIR adoption. Mapping is the work of reconciling codes, and it sits squarely on the critical path.
Test the codes, not only the structure
The fix is to treat terminology as part of conformance. Several steps would make codes agree in practice.
- Test terminology along with structure. Conformance tests between partners should check that codes come from the bound value sets. They should also check that the same concept carries the same code on both sides.
- Publish rules in standard codes. Payers should publish coverage rules keyed to standard codes, with the version of each value set they use. Our piece on publishing coverage criteria like code made the broader case.
- Use the mappings that already exist. CDC’s LIVD format lets test manufacturers publish the LOINC codes for their tests. Labs and payers can start from those files rather than mapping each test by hand.
- Measure code agreement. Each exchange partner could report the share of coded elements that match a required value set. A falling number is an early warning, long before a denial or a missed result.
None of these steps requires a new standard. Value sets are already published, and the terminology services that check them already exist. What is missing is the expectation that partners prove code agreement before they go live, the same way they prove structure today.
The work is not free. Mapping local codes takes clinical knowledge, and every new test or drug adds to it. That is an argument for doing it once at the source, rather than separately at every system that receives the data.
Codes matter to our work directly. Redlake builds tools that health plans use in utilization review, and every recommendation we make shows its reasons. A reason that cites a rule is only as good as the match between the code on the request and the code in the rule. When the codes do not agree, the honest answer is to send the request to a person rather than guess.
The 2027 deadline will be met on structure. Whether it is met on meaning depends on work that no structural test will check.