Questions, answered plainly
Answers are kept word for word, because a paraphrase is how a careful answer turns into a claim.
The data
No. Every patient is constructed from a specification and stated distributions. No real patient record is used to build populations.
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.
FHIR R4 JSON: a population bundle, and one bundle per patient as a test fixture. The internal format is JSON too.
Yes. Every run writes a manifest. Rebuilding from the manifest produces the same population, and the run ID is derived from the inputs.
The product
No. It makes no network calls while running. The one exception is when you ask it to send fixtures to a system you name.
A comparison methodology is being rebuilt. No result is currently quotable.
Not today. It runs from the command line. Other interfaces may follow if customer use calls for them.
Generating synthetic patients is not our focus on its own. We construct exactly the situations you declare, verify them independently and record what was and was not tested. In development: deliberate differences between clinical truth, the record and the workflow, and counterfactual twins.
The construction and verification core does not depend on one. We may use a self-hosted model for assisted tasks, such as drafting a scenario specification for human review, after benchmarking it on our workload.
Clinical content
Today, medication safety review (18 scenarios) and data integrity (3 scenarios). We add scenarios for your use case as part of a pilot.
Not yet. Clinical scenarios and drug knowledge are marked as awaiting review, the software will not count a scenario that depends on an unsigned clinical fact, and the Passport says so.
No. It produces test data and evidence about that data, for software development and testing. It gives no treatment advice and does not judge whether any record is clinically right.
No. We construct declared test trajectories, not prognosis. A scenario can say that a delayed action is followed by a declared deterioration branch; it never says what would happen to a real person.
Glossary
The terms used across this site.
- FHIR R4
- The widely used international standard for exchanging healthcare records as structured data (version 4.0.1).
- Scenario
- One declared situation to test, for example “medication prescribed despite a documented allergy”, with a target count.
- Specification
- The list of scenarios and population settings for one run.
- Coverage
- Which declared scenarios are present in the stated quantities.
- Met
- Present in the quantity asked.
- Short
- Present, but in fewer patients than asked.
- Not verifiable
- Could not be checked, because a clinical fact it needs has not been signed by a clinician.
- Constructed vs incidental
- How many patients were built for a scenario, and how many satisfy it by chance.
- Data Passport
- The evidence document delivered with every run.
- Manifest
- The machine-readable record of every input to a run, used to reproduce it.
- Seed
- The number that fixes every random choice, so a run can be repeated exactly.
- Fixture
- One patient’s data as a file your test suite can load.
- Mixed, valid, adversarial
- Population modes: deliberate defects included, none, or only defects.
- Clinical truth
- What is actually true about a synthetic patient, which the system under test may never see.
- Recorded state
- What the record shows, which can be missing, stale, delayed or wrong.
- Workflow state
- What people and systems actually did, such as ordering, reviewing or handing off.
- Counterfactual twin
- Two versions of one patient with identical history until exactly one declared divergence.
- Test world
- A constructed healthcare situation with known ground truth, used as a repeatable test asset.
- Synthea
- A well-known patient simulator from MITRE. We use it only as a point of comparison.
Did not find your question? Email hello@supermerco.com or write to us.
Bring the list of situations your software must handle.
We will turn it into a scenario specification and show you what a pilot would deliver. Or email us at hello@supermerco.com.