How CohortLoom builds synthetic patients
A cohort description goes in. Out comes a dataset of longitudinal synthetic patients, the clinical documents written across their visits, and the keys that say exactly what each document contains.
The steps
You describe the cohort
Conditions, age range, sex mix, number of visits, document types and the labels you want. Starter datasets use our catalogue cohorts; custom orders use your own spec.
We simulate each patient's history
An open-source population simulator generates a life course for each patient: encounters, diagnoses, medications, vitals and labs. Only patients that match your spec are kept.
Rules keep the history consistent
Rule-based checks catch problems such as impossible sequences, invalid code combinations and complications that appear from nowhere. Labs trend with the conditions that drive them.
We freeze the chart at each visit
For every visit we take a snapshot of what was known at that moment. A document written at visit 2 can't mention a result from visit 4.
Each document is designed before it is written
We choose the author's role and style, the EHR layout, the length, and which facts go where. That plan becomes the document's answer key, so the truth exists before the text does.
Language models write the document
Open-weight models that we run ourselves write progress notes, nurse notes, lab reports and other documents from the plan. Some documents get scan-style noise so they look like OCR output.
Every document is checked
Each document is checked against its answer key: the right facts present, the offsets pointing at the right text, nothing outside the chart, no contradictions, and no patterns that look like real-world identifiers. A separate reviewer re-reads the labels independently. A document that fails is revised; if it still fails, it is left out.
We package the dataset
The patients, documents and keys go into a versioned dataset folder with a validation report, a dataset card and a manifest of checksums.
What's in a dataset
| Part | What it is |
|---|---|
| Patient records | Each patient's structured history: encounters, conditions, medications, observations and labs. |
| FHIR R4 export | The same patients as HL7 FHIR R4 using the US Core 6.1.0 profiles, delivered both as one transaction Bundle per patient and as Bulk Data NDJSON (one file per resource type). Each note is a DocumentReference linked to its encounter, and lab reports are DiagnosticReports. Answer keys are linked through Provenance resources and a checksum extension, and every resource is tagged as keyed or context. The export is checked against the answer keys (it is refused on any mismatch) and with the official HL7 FHIR Validator. |
| Documents | Multi-visit clinical documents in plain text, written in the style of different authors and EHR layouts. |
| Answer keys | One per document: labels, ICD-10-CM codes, facts and evidence spans with character offsets. See an example. |
| Master keys | One per patient, linking every document to the visit and chart state it came from. |
| Validation report | The results of the checks above for that dataset. |
| Dataset card | Generation parameters, cohort description, known limits and intended uses. |
| Provenance and manifest | For each file, how it was made and by which model version, plus a SHA-256 checksum for every file. |
| License | Commercial use, synthetic data, no PHI. Summary. |
Why it's built this way
Truth first, text second
Labelling documents after they are written is slow and error-prone. Writing them from a known plan means the labels are right by design, and the checks confirm it.
Time matters
Real charts change over visits. Testing on single, isolated notes misses the hard cases: trends, follow-ups and facts that are only true at one point in time.
No real data to protect
Nothing in the pipeline starts from a real patient. You can share, publish excerpts from and test with the data without privacy reviews of the content.
Clean model lineage
Our writing models are open-weight models. We never train them on Claude or Gemini outputs, and every file records which model wrote it.
Quality figures will be published with the validation report. Until then: validation report and sample available on request. Request a sample.