Conformance testing in healthcare interoperability
A practical guide to testing healthcare interfaces against specifications, including validation, peer testing, evidence, and limits of certification.
Published Updated
What is conformance testing in healthcare IT?
Conformance testing checks an implementation against the requirements of a named standard or implementation guide. It can validate messages, terminology, and required interactions; peer testing then checks whether two implementations exchange information as intended. A passing result is evidence for the tested scope and version, not a guarantee that every production workflow will work.
Start with a testable requirement
An interface can accept a valid message and still put the wrong value in a field. Conversely, two systems may each pass a syntax check and still disagree on when an event should be sent. Conformance testing gives teams a way to make those differences visible before deployment. It works best when a specification names the version, transaction or API operation, required fields, terminology bindings, error behavior, and expected result. An unqualified claim of “HL7 compliant” is too broad to test.
For example, a project exchanging laboratory results might require an Observation with a particular code system and a reference to the correct patient. A validator can check the required structure and codes. A scenario test must also check that the receiving system associates the result with the right patient and handles a missing or rejected result safely. HL7's FHIR profiling guidance explains how profiles express additional constraints for particular use cases.
The stages of a useful test programme
- Define the scope. Identify the standard and release, applicable implementation guide or IHE profile, system roles, use cases, and pass criteria. Record which requirements are mandatory and which are optional.
- Run isolated validation. Check examples and actual payloads for structure, cardinality, value sets, and any additional rules. For an API, test supported operations and error responses as well as successful exchanges.
- Test with another implementation. Run the complete workflow with a partner system, including negative cases, identity matching, authorization failures, and retries. IHE describes Connectathons as structured, supervised peer-to-peer testing against defined integration profiles.
- Keep reproducible evidence. Save the test plan, environment, version identifiers, results, defects, and retest record. State exactly which combinations of systems and scenarios passed.
The Gazelle interoperability platform provides tools used in interoperability testing and collaborative test events. Choosing a tool does not remove the need to define local requirements or review clinically meaningful outcomes.
What a pass does—and does not—mean
Passing a validator is not the same as passing an end-to-end workflow; passing a Connectathon is not by itself an official certification. IHE's conformity assessment programme has a distinct process for formal assessment. No limited test set can establish that every future message, configuration, or operational failure will be handled correctly.
Sponsors should ask for a traceable list of requirements and exceptions, not a single green badge. Retest after changes to profiles, terminology, application versions, or connected partners. Before go-live, include security, performance, support ownership, and clinical safety checks alongside conformance results.
Plan testing before procurement
Make the required version and implementation guide explicit in procurement documents. Ask vendors for a testable capability statement, reserve a shared test environment, and agree who resolves cross-system defects. Set acceptance criteria around named workflows and documented results rather than a generic “standards-compliant” promise. This keeps the decision to deploy tied to evidence from the actual integration.