Write down what must stay.
One check is a JSON path plus the expected value or allowed set. Agree that list before you compare anything, so a reviewer knows what “expected” means.
FHIR R4 · release-review checks
Your export changed.
Did its meaning?
Compare a baseline export with the new one and see which agreed field values and reference targets changed while the resource count stayed the same — for example Coverage.status flipping from active to cancelled in a four-resource synthetic fixture.
Runs in your browser. Nothing is uploaded and no production system is connected.
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"
Made for
INTEROPERABILITY TEAMS / FHIR VENDORS / INTEGRATION CONSULTANCIES
1 · What we're testing
Not another validator.
A reviewable migration story.
JSON comparison tools already exist. A “check” here means one JSON path plus the expected value or allowed set. A pilot is one agreed list of those checks, run against your fixtures, producing a report you can explain and repeat.
Separate drift from noise.
Changed values and missing reference targets surface for review, while approved metadata changes stay out of the way instead of burying the rest.
Keep the evidence.
The output is a report you can attach to a release review. It is not an approval, and it is not a clinical judgement about any patient.
2 · The demo
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.
Scope: FHIR R4 JSON only, using stable test IDs. No profile or invariant validation, no terminology binding, no extension semantics, and no R4B, R5 or STU3. Real migrations may change identities, coding or profiles; those problems are outside this demonstration. What the pilot is
3 · Checklist
What to inspect after
a mapping release.
A count check is a starting point, not an assurance result. Use test 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
4 · Scope
Start outside production.
We're exploring a synthetic-fixture QA workflow — no production connections, no patient data, no healthcare platform.
- Only the four built-in fixtures — there is no field for your own data.
- No clinical recommendation and no automated release decision.
- No real patient data, credentials, or production API access.
- No claim of HIPAA compliance or regulatory certification.
5 · The pilot
Send synthetic fixtures.
Get a review report.
You send two exports — a baseline and the new one — plus the list of changes you consider expected. You get back a repeatable review report, and the exact checks behind it, that you can attach to a release.
Start the conversationOpens your email app. A person replies — there is 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, script-run visits, sample runs, example-file downloads, and email-link clicks by broad acquisition channel. That counter 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.