Agree on what should stay.
Start with synthetic fixtures and explicit expectations. Define which changes are intentional before running the comparison.
A HypoForge experiment · early prototype
Your export changed.
Did its meaning?
A green pipeline doesn't tell you what survived the migration. Review unexpected changes in coverage, references, and provenance before your next release.
Synthetic example only. No file uploads. No production connections.
REVIEW NEEDEDSame count.
Same count.
Different content.
4 source resources → 4 destination resources
✓Resource count unchanged4 / 4
!Coverage status changed1 finding
Coverage/synthetic-coverage
−
status: "active"+
status: "cancelled"Built to explore a problem with
INTEROPERABILITY TEAMS / FHIR VENDORS / INTEGRATION CONSULTANCIES
THE QUESTION WE'RE TESTING
Not another validator.
A reviewable migration story.
JSON comparison tools already exist. Our proposed pilot would turn an agreed set of pipeline checks into a report your team can explain and repeat.
Separate drift from noise.
Surface missing references and changed values. Keep approved metadata changes out of the way, without hiding everything else.
Keep the evidence.
The proposed pilot would produce a repeatable release-review report, not an automated approval or a claim of clinical correctness.
TRY THE SYNTHETIC EXAMPLE
Four resources.
One change worth noticing.
This working demo checks a few predefined fixture fields. It is not a general FHIR comparator, conformance validator, or production product.
Choose a scenario and run the comparison.
The sample stays in your browser.
No patient records. No uploads. No remote comparison.
Example fields have stable synthetic IDs. Real migrations may change identities, coding, or profiles; those problems are outside this small demonstration.
A PRACTICAL FHIR REGRESSION CHECKLIST
What to inspect after
a mapping release.
A count check is a starting point, not an assurance result. Use synthetic fixtures and agree on expected changes before comparing a baseline and a new export.
1. Stabilize identity before comparing.
Match the same test object on both sides. This demo uses resourceType/id because its IDs are stable. Regenerated IDs, external references, contained resources and logical identifiers need an explicit matching policy; this demo does not solve them.
2. Check a specific expectation.
In the coverage scenario, Coverage.status changes from active to cancelled. Counts remain equal. The change should be reviewed against the test case; it is not automatically an error or a clinical judgment.
3. Define the reference boundary.
In the provenance scenario, a target is missing from the four-resource destination fixture. Real FHIR references may legitimately point outside a bundle. Treat this as a finding only when your agreed dataset boundary requires the target to be present.
4. Ignore only approved noise.
meta.versionId can change when a server updates a resource. Our metadata scenario explicitly ignores that one path. A broad ignore-list can hide real differences; don't turn “no finding” into “everything is correct.”
Does this replace a FHIR validator?
No. Profile validation, terminology, implementation-guide requirements and business expectations are different checks. Existing JSON/FHIR-aware diff tools are also useful; we're testing interest in a repeatable release-review workflow, not claiming to invent comparison.
Can I upload my patient exports?
No. There is no upload or paste input. Download the built-in synthetic inputs to understand the examples. Don't email patient records, confidential payloads, credentials or production endpoints.
Technical references: FHIR R4 Coverage · Provenance · References · An existing FHIR diff alternative
A SMALLER, HONEST FIRST STEP
Start outside production.
We're exploring a synthetic-fixture QA workflow — not a healthcare data platform.
- ✓ Only built-in synthetic data in this demo
- ✓ No clinical recommendations or automated release decisions
- ✓ No real patient data, credentials, or production API access
- ✓ No claims of HIPAA compliance or regulatory certification
HELP US DECIDE WHAT TO BUILD
Have a pipeline change
on your horizon?
If you review FHIR mapping or migration releases, we'd like to understand your current checks and whether a synthetic-only pilot would help.
Discuss a synthetic-only pilotOpens your email app. No signup, payment, or automatic enrollment.
Please do not send patient data, files, secrets, or production endpoints.
What this page measures
Our event counter stores daily aggregate counts of page loads, sample runs, example-file downloads, and email-link clicks by broad acquisition channel. It stores no cookies, visitor IDs, uploaded files, names, IP addresses, or patient records. Counts are not unique people, and a click is not a signup. We also use Cloudflare Web Analytics for aggregate traffic and performance data; it does not use analytics cookies. Cloudflare provides hosting and processes requests under its own policies. If you email us, your address and message are shared with our project Gmail account.
Questions or deletion requests for email correspondence: hypoforgelabs@gmail.com.