Testing integrations without touching real patients

Every health data integration has to be tested before it carries real patient information. The difficulty is that good tests need realistic data, and realistic data is exactly what you are not supposed to use freely in development and test environments.

Synthetic patient data resolves that tension, if it is done properly.

Why a few test records are not enough

Most integration projects start with a handful of hand-built test patients. They are tidy: complete names, valid dates, one encounter, a couple of observations. They pass every check.

Real data is not like that. Real patients have multiple encounters, long medication histories, conditions that resolve and recur, and results reported in more than one unit. Interfaces that pass with five clean records routinely fail on the first day of production traffic.

What useful synthetic data looks like

A synthetic cohort worth testing against has four qualities:

• Clinical coherence. A patient with a diabetes diagnosis should have HbA1c and glucose observations that make sense over time, not random values.
• Correct terminology. Observations coded with LOINC, conditions with SNOMED CT, units expressed in UCUM. Otherwise you are testing your mappings against data that would never arrive.
• Profile conformance. Resources that conform to the profiles your partners expect, such as US Core, so that validation results mean something.
• Referential integrity. Every Observation points to a Patient and Encounter that actually exist in the same Bundle or server.

Open-source tools such as Synthea, from MITRE, are a strong starting point. Most projects then need targeted additions: the edge cases specific to their own systems, their local codes, and the failure scenarios they most need to rehearse.

Test the failures on purpose

The most valuable synthetic records are the deliberately broken ones: a missing identifier, an unmapped local code, an ambiguous timestamp, a unit that contradicts its code. Feeding those through a pipeline before go-live shows exactly where each one is caught, whether anyone is alerted, and whether the message can be replayed once fixed.

Where to start

Load a synthetic cohort into a test FHIR server, run your interface end to end, and validate what arrives on the other side. Then break it, on purpose, and see what happens.

Nomalix Scan, in the Lab, runs preliminary checks on a single FHIR resource in your browser. It is a quick first look, not a full conformance assessment, and it never needs real patient data.