How it works

How twenty years of letters becomes one screen.

Documents go in as they are. What comes out is a set of discrete clinical events, each bound to a SNOMED CT concept and, where the terminology supports it, resolved to a place on the body — a history a clinician can read in seconds, and a coded data set underneath it.

Seven modules do the work. Two are built once; five run for every record. They are named the same way everywhere on this site and in the code.

One document, from prose to coded events A discharge summary on the left. In the middle, three events proposed from it with their dates. On the right, the same events bound to SNOMED CT concepts with a body region, or flagged where no single region applies. SOURCE DOCUMENT PROPOSED CODED Discharge summary, 2014 Admitted 14 March following several weeks of upper abdominal pain. Underwent laparoscopic cholecystectomy with an uncomplicated recovery. Background of type 2 diabetes since 2009 and a myocardial infarction in 2001, both stable on current therapy. Follow-up with the general surgical team in six weeks… No template. No structure. Just the letter. Cholecystectomy procedure · 2014 Type 2 diabetes diagnosis · 2009 Myocardial infarction diagnosis · 2001 Each one carries the passage it came from. 38102005 Cholecystectomy upper abdomen · gallbladder 73211009 Type 2 diabetes no single site · flagged 22298006 Myocardial infarction chest · heart Dated, sited and traceable to source. One pass over the document produces both: the regions that light on the figure, and the coded rows underneath them. Where the terminology gives no single anatomical site, the event is still coded and the mapping is flagged for a decision. Synthetic example. Verify concept identifiers against your own imported release.
The same read produces the picture and the data. Anything the terminology can't place is flagged rather than guessed at.
01

Module 01 Vocabulary

The complete SNOMED CT release is imported into a structured database — concepts, descriptions and relationships — giving the system the full international clinical vocabulary to work against.

350,000+ concepts · findings · procedures · body structures
02

Module 02 Anatomy

The SNOMED CT body-structure hierarchy is mapped to a library of registered anatomical layers — male and female, front and back, with laterality declared per layer — so an anatomical concept can resolve to a precise place on the figure.

123037004 |Body structure| → layer · ~300 layers · see the library
03

Module 03 Ingestion

Discharge summaries, operation notes and specialist letters go in as they are. No templates, no forms to fill — the messy source documents themselves. The framework provides a webhook and a queuing process; you decide what flows through them and when.

webhook · queue · PDFs, letters, op notes → text
04

Module 04 Extraction

Two passes. The first divides the document into coherent clinical sections, so a dated presentation stays with its treatment instead of being split at an arbitrary line break. The second pulls discrete events out of those sections — a diagnosis, a procedure, a finding — each proposed with the passage it came from, so nothing lands in a record without something to check it against.

pass 1 segmentation · pass 2 events · proposed, not assumed
05

Module 05 Coding

Each event is bound to a SNOMED CT concept, and its anatomy resolved through SNOMED CT relationships where they are available. Anatomy that is ambiguous or unresolved is held for human review rather than guessed at.

Condition → 363698007 |Finding site| → body region
06

Module 06 Review

The gate, set where you choose. Events arrive proposed, scored and shown with their evidence. How much passes automatically and how much a person sees is your policy, not a decision baked into the framework. Anything the coding module could not resolve waits here rather than being guessed at.

your thresholds · evidence attached · audit trail
07

Module 07 Patient history

What a clinician actually opens: timeline, body map and events reading as one thing. The same approved events sit in your own database, coded and dated, ready for whatever you build next.

timeline · body map · coded rows
The same pass that draws the picture emits a fully coded history — structured, portable and standards-based.

See it

Sixty-four events, one screen.

A synthetic patient record taken through the pipeline. The timeline runs across the top, the body shows what is active at the selected point in the history, and the events sit beside it in order.

The health history review screen: a timeline of events from 1970 to the 2010s, an anatomical figure with the digestive system, shoulder and knee highlighted, and dated event cards listing diagnoses
Health history review. Scrub the timeline and the body updates with it. Every event resolves to a region, with body-system counts on each card. The event list continues past the right edge.
An encounter detail panel showing a 1969 viral croup admission with a plain-language summary and the source evidence it was extracted from
Every event keeps its evidence. The summary sits next to the passage it came from, so a reviewer can check the extraction against the original letter rather than trusting it.
The anatomical figure alone, with the brain, digestive organs, shoulder joint, knee and bladder lit in amber
The map itself. Several systems lit at once, each one an event resolved through its finding or procedure site.

Screens show a synthetic test record, not a real patient. No identifiable clinical data appears anywhere on this site.

A short walkthrough video is on the way — the screens above are the short version.

One line, all the way through

What a single sentence becomes.

A clause buried in a twenty-year-old letter, taken through the whole pipeline.

Source text
“Underwent laparoscopic cholecystectomy in 2014, uncomplicated recovery.”
Extracted event
Procedure · cholecystectomy · 2014 · held for review
SNOMED concept
38102005 |Cholecystectomy| (procedure)
Anatomy
363704007 |Procedure site| → 28231008 |Gallbladder structure|
Body region
Upper abdomen — the region lights on the figure. Where anatomy can't be resolved unambiguously, the event is still coded and the mapping goes to review.
Output
A coded, dated, anatomically located row — queryable, countable and exchangeable

What comes out

Two audiences, one pass.

At the bedside

A clinician opens the patient and sees the whole history at once: what has happened, where on the body, and in what order. No scrolling through correspondence, and no relying on the patient to narrate their own history correctly under pressure.

In the data warehouse

Historic free text stops being unreadable at scale. Every event leaves the pipeline as a SNOMED-coded row with a date, an anatomical site and a link back to the source document — the shape a health IT team needs before a data lake is worth loading. The load itself is yours to write.

Most of what an organisation knows about its patients was written before structured records existed, and it has stayed effectively unqueryable ever since. Coding it retrospectively is the whole point: once a history is bound to SNOMED CT, it can be counted and cohorted, and it becomes the raw material for a FHIR mapping or a warehouse load — those exports are your build, not something the framework ships today.

  • RetrospectiveDecades of letters, op notes and discharge summaries coded against the current release
  • PortableStandards-based output rather than a vendor-specific representation
  • TraceableEvery coded event keeps its provenance — the document and passage it came from
  • YoursSelf-hosted end to end; no patient data leaves the environment you run it in

Where the judgement sits

You set the policy. The framework enforces it.

Extraction proposes. What happens next is your call: how much is accepted automatically, what routes to a person, and where the threshold sits are configuration owned by the implementing organisation, not decisions baked into the framework. What the framework guarantees is that everything arrives with its source evidence attached and that it flags rather than guesses when it can't resolve something confidently.

The framework makes no clinical decision, offers no diagnosis and replaces no record of truth. It is a reading aid and a coding pipeline. How closely a human reads its output — and under what governance — is a decision for the organisation running it, and one worth making deliberately.