FHIRplace Interoperability Issue Classification Standard

Methodology and Integrity Controls for FHIRplace Interoperability Issue Identification

V1.0 – 2026
First Published: September 21, 2026

Purpose and Scope

This document defines the classification standard applied by the FHIRplace program to identify, categorize, and report interoperability issues uncovered during structured multi-party FHIR testing events. It is the authoritative reference for how every issue recorded in a FHIRplace testing report was produced, what each issue type means, and what controls ensure the integrity of every classification. Quarterly testing reports reference this document in lieu of republishing this methodology in full.

The standard applies to all FHIRplace testing events conducted under the HL7® Da Vinci Implementation Guide, including electronic prior authorization (ePA) interoperability testing. It will be extended by addendum as additional implementation guides and workflows are added to the FHIRplace program scope.

How Issues Are Captured

Each test case represents a structured exchange between a provider system and a payer system. The FHIRplace platform records every step of that exchange — capturing what was sent, what was returned, and whether each step passed or failed. Steps are grouped by test case to produce a single complete execution record: what the test required alongside what the system produced.

Each completed execution record is then classified using a deterministic two-pass process described below.

Two-Pass Classification Process

Pass One — Automated Rule Application

Where the cause of a result is unambiguous, a fixed rule applies directly with no interpretive judgment required.

Pass – No Issue. If all expected steps occurred and no failures were flagged, the execution passed with no issue recorded.
Platform Issue. If the FHIRplace platform’s own infrastructure prevented message delivery (e.g., proxy could not reach a partner server), the execution is classified as a platform issue — not an interoperability defect.
HTTP Error Code Mapping. If the exchange terminated early with a recognized HTTP error code, that code determines the category directly: 401 Unauthorized = authorization failure; 404 Not Found = endpoint resolution failure; timeout = payer system response delay.
Forward to Pass Two. Any execution that does not meet a clear-cut rule is forwarded for guided analytical review.

Pass Two — Guided Analytical Review

For ambiguous cases, an automated reviewer analyzes the full exchange record, including message content and evaluator failure notes.

Taxonomy-Constrained Selection. The reviewer selects the single best-fitting issue type from the official issue taxonomy. No category may be invented or inferred outside the documented taxonomy.
Evidence Citation. The reviewer is required to cite the specific evidence from the recorded exchange supporting the classification. Cited evidence must appear verbatim in the recorded messages.
Confidence Rating. A confidence rating is assigned. Classifications that do not meet the minimum threshold are escalated for manual review rather than assigned a category.
Taxonomy Disambiguation. The taxonomy descriptions explicitly define distinctions between adjacent issue types — such as a payer returning an incorrect coverage decision versus returning no decision, or a genuine data defect versus an infrastructure failure surfaced through the platform.

Integrity Controls

Before any classification is accepted, three conditions must be met:

Control 1 – Taxonomy Existence. The selected issue type must exist in the official taxonomy. An unrecognized category is not accepted; the case is set aside for manual review.

Control 2 – Evidence Traceability. The cited evidence must be traceable to and appear verbatim in the recorded exchange. An unverifiable citation is flagged and the case is escalated.

Control 3 – Minimum Confidence Threshold. Any classification that cannot be determined with sufficient confidence is escalated for manual review rather than assigned a category. An unverifiable assignment is not made.

Any classification that fails one or more controls is placed in a manual review queue. Results from that queue are resolved, reported, and incorporated into the taxonomy refinement cycle that follows each testing event.