Declare the cases. Get the patients. See the evidence.
Test your healthcare software against the patients your sandbox doesn’t have. Tell us the situations it must handle: we build the synthetic patients, verify every one is there, and give you the evidence. Already have test data? We find what it’s missing.
Coverage
– met– short– not verifiable
- SCN-MEDSAFE-001Medication prescribed despite documented allergy to it110 / 50
- SCN-MEDSAFE-002Metformin active while the latest eGFR is below 3085 / 60
- SCN-MEDSAFE-003Potassium-raising drug with existing hyperkalaemia40 / 40
- SCN-MEDSAFE-007No allergy record of any kind exists150 / 60
- SCN-MEDSAFE-008Medication present with no supporting indication anywhereNot verifiable
- SCN-DATAINT-001Observation references an encounter that does not exist20 / 20
From a real 3,000-patient run. The tick marks the target.
25 of 27 scenarios met, 0 short and 2 not verifiable, 3,000 patients in about 7 seconds. Rebuilding from the manifest gave the identical dataset.
- FHIR R4 output
- 27 declared scenarios
- Independently verified
- A Data Passport per run
- Gap-fill for existing suites
- Exactly reproducible
A large test dataset is not automatically a useful one.
- Healthcare software and AI teams need specific patient situations for development, integration testing, QA, model evaluation and regression testing.
- If a required situation is absent from the test population, that situation is not being tested, and nobody can tell from the population alone what it covers.
- Rare, interacting, temporal, contradictory or deliberately malformed cases can be hard to obtain in the exact quantities needed.
- Learning-based synthetic data tools reproduce the patterns of their source, so rare situations stay rare.
- When software fails, reproducing the exact patient state and keeping it as a regression test can be hard.
Construct, then verify.
Tools that learn from existing data reproduce that data’s patterns, so rare situations stay rare. You cannot filter for something a generator never produces.
We construct patients to a specification instead of sampling them, then verify the result with separate code that does not know how the patients were made. We report the result as coverage of what you asked for, not as a single quality score.
Generation is the engine. Scenario control, verification and evidence are the product.
Seven steps from test plan to evidence
Each step works today. Pick one to see what it produces.
Step 1 of 7
Declare
The situations to test are written as a specification: each scenario, how many patients need it, and the checkable conditions that define it.
You getA versioned test plan
# One scenario, simplified
- id: SCN-MEDSAFE-002
situation: >
Metformin active while
the latest eGFR is below 30
severity: critical
target: 60
# plus the checkable
# conditions that define itTwo more ways in
Gap-fill your existing test suiteAvailable
- You share your existing FHIR test files.
- We show which of your situations they already contain and which they lack.
- We build only the missing patients and merge them in. Your files are not changed.
- You get a complete, verified suite and a Test Passport.
Failure to regressionBeta
- We run your system against the test patients and judge each answer.
- When your system fails, we pinpoint the smallest change to the record that causes the failure.
- We save it as a regression case that rebuilds exactly.
- After your fix, we rerun it and report whether the failure is fixed, still reproduced, or has changed.
What you receive
Five things with every dataset, and a sixth with gap-fill or when we test your system.
FHIR R4 data
Six resource types in a population bundle, checked against the FHIR R4 specification.
- Patient
- Encounter
- Condition
- Observation
- MedicationRequest
- AllergyIntolerance
Coverage report
Every situation marked met, short or not verifiable, with how many patients were built for it and how many occurred by chance.
Data Passport
What is in the data, what is missing, and what was not tested. Its “Not tested” section is never empty.
Test files
One per patient, ready for your test suite.
Reproducible manifest
Every input recorded; rebuilding from it gives the identical dataset.
Test Passport
New; with gap-fill, and when we test your system
Every record sent, every answer and how it was judged, failures pinpointed, and the regression case that reproduces each.
Why you can trust it
Each rule is enforced by an automated test, not by good intentions.
- 01
The checker cannot see how the data was made
Verification and evaluation code are forbidden from importing construction code.
- 02
No combined quality score, anywhere
One number would hide the trade we make on purpose: we change the population so it covers your cases, which makes it look less like any source.
- 03
Every measurement declares what it cannot detect
It is a required field with no default.
- 04
Unknown is never “none”
If a situation depends on a clinical fact nobody can stand behind, we report it as not verifiable, never as passed.
- 05
Every clinical fact names its source
Clinical rules live in versioned files a clinician can correct, and each Passport says whether a fact comes from an official source or a clinician’s review.
- 06
Nothing leaves your machine
No telemetry, and no network calls at runtime except to a system you name for testing.
- 07
Every run is reproducible
From its manifest. The run ID is derived from the inputs, not from a clock.
- 08
Our wording is tested
An automated check fails the build if our output makes any of the legal or safety claims our policy forbids.
By the numbers
- patient situations in the library, across medication safety and data integrity
- 27
- met in the quantities asked in a 3,000-patient run; the other 2 need an indication list we are building
- 25 of 27
- to build, verify and export 3,000 patients, on a laptop
- About 7 seconds
- FHIR R4 validation issues in a population built without deliberate defects
- 0
- rebuild any dataset exactly from its manifest
- Identical
Where this is going
In development The chart is not the patient. Test patients whose true state, record and care process can disagree on purpose, so you can test how your software behaves when the record is wrong.
Our standards
Every dataset comes with a Data Passport that says what is in it, what is missing and what was not tested. We make no clinical, safety or compliance claims, and we name the source of every clinical fact. Your data stays with you: no real patient data, no telemetry.
See the evidenceWays to work with us
Prices are agreed per pilot.
- 01Test data built to your test planYou list the situations; we build a synthetic FHIR R4 population that contains them, verified independently.
- 02Gap-fill your existing test suiteWe show which situations your FHIR test files lack, and build only the missing patients.
- 03Failure to regressionBetaWe run your system against the test patients and save every failure as a regression case.
- 04Custom scenarios and data-quality setsSituations written for your domain, and declared defects: missing values, duplicates, conflicts, broken references.
Questions
No. Every patient is constructed from a specification and stated distributions. No real patient record is used.
We do not describe it that way. It is built without real patient records, and the Data Passport reports what we measured about re-identification and what we did not test. Whether data counts as anonymous in your jurisdiction is for you and your counsel to decide.
Yes. We read your FHIR test files, show which of your situations they contain and which they lack, and build only what is missing. Your files are not changed.
Not yet; a clinical review is under way. Drug facts are taken from the WHO drug classification and US drug labels and checked against them, and every Passport says they have not been reviewed by a clinician. Situations that need clinical judgement stay marked as awaiting review.
No. It makes no network calls while running, except when you ask it to send test records to a system you name.
Bring the list of situations your software must handle.
We will turn it into a test specification and show you what a pilot would deliver. Already have FHIR test data? Send a sample and we will show you what it is missing. Or email us at [email protected].