Clinical history infrastructure
See twenty years of a patient's history in seconds.
OpenClinicalHistory turns decades of letters, discharge summaries and reports into SNOMED CT-coded events on a timeline and a body map. Free, and it runs inside your own infrastructure.
Seven modules, running today: vocabulary · anatomy · ingestion · extraction · coding · review · patient history.
An add-on to your existing EHR or patient management system. Yours stays the system of record.
An overview of the OpenClinicalHistory framework. Click to watch it full size, with sound.
Why this exists
It started with Melissa.
I am Melissa's husband and carer. Every new specialist means explaining the same complex history again.
Three open-heart surgeries. A heart valve replacement. A major stroke. Breast cancer.
All of it is on record, across years of hospitals, specialists and systems. But at the start of an appointment, the complete picture still depends on how well I can reconstruct it from memory.
OpenClinicalHistory started with that problem. It is not a personal health-record app — it is a framework health organisations run alongside their existing clinical systems to make historical information structured, computable and readable at a glance.
What it is
An add-on clinical history framework, not another patient management system.
It provides one layer: terminology, ingestion, extraction, coding, provenance, anatomical mapping and longitudinal presentation. Your existing system keeps patient identity, workflow, access, security, consent, governance and the authoritative record.
What it is
- A free, source-available framework you self-host
- An add-on to existing patient management and EHR systems
- An end-to-end SNOMED CT clinical-history coding pipeline
- A way to turn unstructured records into structured events
- A source-auditable longitudinal clinical history
- An anatomical interface for reading complex histories quickly
- A webhook and queue you wire into your own workflows
- A foundation built to be adapted and extended locally
What it isn't
- A personal health-record app
- A replacement for an EHR or patient management system
- A system of record
- A hosted service that requires organisations to send me patient data
- A medical device
- A clinical decision-maker
The problem it solves
Health organisations already have the history. The problem is making it usable.
A history spread across correspondence, discharge summaries, specialist reports and decades of records. The information exists — but reading it means opening documents one by one.
Most of that history is trapped in free text. A human can read it. It cannot be queried, counted, exchanged, analysed or fed into a modern workflow.
OpenClinicalHistory solves both in one pass. Events are extracted from the source material, normalised against SNOMED CT, linked back to the text that produced them, mapped to anatomy, and assembled into a structured longitudinal history.
From raw records to structured clinical history
Terminology, ingestion, extraction, review, coding and anatomical presentation.
The clinical interface
What a clinician can see.
Nothing has to be taken on trust. Open any event and it shows its working: the passage it was extracted from, how the date was resolved, which structures it touched, the SNOMED CT concept it was bound to — and a plain statement that no clinician has verified it yet.
Synthetic demonstration data only. No real patient information is shown.
Under the visualisation
The important output is structured clinical data.
The visual history is the interface. Underneath it is a SNOMED CT-linked longitudinal clinical data set.
Every extracted event is normalised against SNOMED CT, mapped to anatomy, and kept alongside its supporting source text and provenance.
That makes this more than a visualisation layer. It is the transformation component between historical free text and the structured clinical ecosystem around your existing systems.
The resulting data feeds downstream integration — FHIR resources, analytics, registries, data platforms — under your governance, not mine.
For health organisations
Deploy it alongside the systems you already operate.
Built for health organisations, interoperability teams, researchers and clinical technology groups turning historical unstructured records into structured longitudinal data. It is designed to extend your clinical applications, not replace them.
Free under PolyForm Internal Use 1.0.0: deploy it, modify it and run it inside your own organisation at no cost, commercial or not. The code is in a private repository and implementers are invited into it, so you get releases and an issue tracker rather than a snapshot. Clinical validation, security, privacy, identity, access control, consent, retention, regulatory compliance and infrastructure remain yours.
You get the whole pipeline — terminology import, ingestion, extraction, human review, SNOMED CT coding, provenance and anatomical presentation — to integrate with what you already run.
Deploy it inside your own governed environment. Your EHR stays the system of record; this adds longitudinal history transformation and presentation beside it.
What comes next
What's missing is not the code.
The framework works. What it lacks is validation against real clinical records, terminology governance by people who do it professionally, anatomical coverage beyond what one non-illustrator could produce, and implementation experience outside one country. I can't build those alone — so I'm looking for six organisations to build them with.
Real correspondence archives, real governance, and the willingness to report what broke. Nothing sharpens a coding pipeline like a decade of discharge summaries it has never seen.
Review of the SNOMED CT resolution strategy and the local mapping index — the part where a technically valid concept can still be the wrong clinical interpretation.
Other national releases, other terminologies, other regulatory contexts. An international framework has to be proven somewhere other than where it was written.
The anatomical asset library needs someone who can actually draw, and the safety framework needs someone who assesses these things professionally.