Reviewing and Understanding a Patient History

Open Clinical History presents a patient's medical history as a longitudinal timeline combined with an anatomical visualisation.
The aim is to make a large clinical history easier to scan while preserving access to:
the chronological sequence
the original source evidence
SNOMED CT coding
anatomical involvement
date uncertainty
clinical status
provenance
The patient-history viewer is:
/patient.php
A history is opened by selecting a patient from the patient search screen.
1. Select a Patient
The Home page displays the patients currently stored in Open Clinical History.
You can search using either:
patient record number
patient name
Leave the search field blank to display all patients.
For example:
MRN-1001
Joanne Reacher
Selecting the main part of a patient card opens that patient's Health History Review.
Understanding the Patient Cards
Each patient card provides a quick summary before the full history is opened.
For example:
MRN-1001
Joanne Reacher
b. 1967
Female
12 events
2 active
peak: Major
to 2023
Record Number
For example:
MRN-1001
This is the patient's record number used by Open Clinical History to identify the patient.
Patient Name
The patient's stored display name.
If no name has been recorded, the record number is used instead.
Birth Year
For example:
b. 1967
This is derived from the patient's recorded date of birth.
Sex
For example:
Female
This is the patient's recorded sex at birth.
It also determines which anatomical asset set Open Clinical History uses where sex-specific artwork is available.
Events
For example:
12 events
This is the number of committed clinical events currently stored in the patient's longitudinal history.
An event may represent something such as:
diagnosis
injury
procedure
investigation
clinical episode
significant symptom
treatment-related event
A source document can produce multiple independent clinical events.
Active
For example:
2 active
This counts clinical events whose current stored clinical status is:
active
or:
ongoing
It provides a quick indication that the history contains conditions that have not been recorded as resolved.
It should not be interpreted as a complete assessment of the patient's current health.
Peak Severity
For example:
peak: Major
This displays the highest event severity currently recorded anywhere in the patient's history.
The severity scale is:
Level
Meaning
None
No severity classification
Minor
Minor clinical severity
Moderate
Moderate clinical severity
Major
Major clinical severity
Critical
Critical clinical severity
An important distinction is:
Severity describes the event at the time it occurred.
It does not necessarily represent the patient's current condition.
For example, a patient may have had a Critical event twenty years ago that is now completely resolved.
to YYYY
For example:
to 2023
This provides a quick indication of how far the dated history currently extends.
It is a summary aid rather than a substitute for reviewing the complete timeline.
Import Summary
The:
Import summary
button opens processing and import information for that patient.
It is useful when investigating:
imported documents
extraction results
terminology resolution
unmatched events
learning-queue activity
It is not the normal clinical-history viewing screen.
Delete Patient
Delete patient permanently removes the patient and associated history records.
This is a destructive administrative operation and should not be used as part of normal history review.
2. Open the Health History Review
Selecting the patient opens the main:
Health History Review
screen.
The page is divided into three principal areas:
Patient + time navigation
           |
           v
+-------------------+---+----------------------+
| Anatomical viewer |   | Clinical timeline    |
|                   |   |                      |
| Body visual       | | | Chronological events |
|                   | | |                      |
+-------------------+---+----------------------+
                      ^
                 Timeline scrubber
The anatomical viewer and clinical timeline remain synchronised.
As you move through the patient's history:
the active clinical event changes
the anatomical image changes
the relevant body structures are highlighted
ongoing anatomical involvement is carried forward
the year axis updates
3. Patient Header
The top of the viewer identifies the patient and summarises the record.
For example:
History Review
Record  MRN-1001
DOB     14 Jun 1967
Sex     Female
Events  12
Undated 1
Source  history_import
Record
The patient record number.
DOB
The patient's recorded date of birth.
Sex
The recorded sex at birth.
Events
The total number of clinical events shown in this history.
Undated
If present:
Undated 1
means one or more genuine clinical events were extracted for which the source did not provide enough information to place them reliably on the chronological timeline.
Open Clinical History does not invent a date simply so these events can be positioned.
Source
For imported patients you may see:
Source history_import
This identifies the system or workflow through which the patient record was created.
4. The Year Axis
Across the top of the screen is a compressed view of the patient's entire clinical history.
For example:
1967      1970      1980      1990      2000      2010      2020
  ●                     ●          ●           ●        2       ●
Each marker represents a clinical event or a group of events.
This allows a long history spanning decades to be scanned very quickly.
Selecting an Event from the Axis
Click a marker to jump directly to that part of the history.
If several events occurred very close together, they may be combined into one marker containing a number.
For example:
2
means that two events occupy approximately the same position on the year axis.
Click the marker repeatedly to step through the events in that group.
The events remain separate clinical records.
They are grouped only for display.
Jump to the Beginning or End
The buttons on either end of the year axis jump directly to:
the earliest event
the latest event
This is useful for very long histories.
5. Date Precision Matters
Clinical records do not always provide exact dates.
A source might say:
21 April 1988
but it might instead say:
1988
or:
in her twenties
or:
approximately 10 years ago
or provide no date at all.
Open Clinical History deliberately preserves that uncertainty.
It does not turn every event into an artificial exact date.
Exact Dates
An event for which the source provides an exact day is represented as a normal filled marker.
For example:
21/04/1988
means the source actually supplied that date.
Approximate Dates
An event whose exact date is not known is visually different.
Approximate or derived timing uses a violet uncertainty style rather than the confident event marker.
A hollow marker means:
The event belongs approximately here, but the source did not provide an exact day.
Date Ranges
Where the source describes a period rather than a precise date, the year axis can display a horizontal uncertainty span.
Conceptually:
1980             1990
      |----------|
        event
        sometime
        in here
The width of the span represents how uncertain the timing is.
The midpoint may be used internally to position the event visually, but:
The midpoint is not presented as the event's clinical date.
Source Wording Is Preserved
Where possible, the viewer displays the source's own description of the timing.
For example:
aged 12
is more informative than silently converting it to an apparently exact calendar date.
The viewer may additionally calculate the corresponding approximate age or year range.
6. Undated Events
Sometimes the source establishes that an event happened but gives no meaningful indication of when.
For example:
Previous appendicectomy.
with no date, age or relative timing.
Open Clinical History does not position this event at an arbitrary point in the patient's life.
Instead, undated events are placed in a separate:
Undated
section.
The year axis also provides an undated indicator when these events exist.
This distinction is deliberate:
Not knowing when something happened is not the same as the event not happening.
Why Undated Events Are Not Carried Forward
An undated event may be marked as an ongoing condition, but Open Clinical History cannot safely determine where it belongs relative to other events.
It therefore does not use an undated event to infer:
this condition was already active at this later event
because doing so would invent a sequence that the source did not provide.
7. The Anatomical Viewer
The left side of the screen displays the patient anatomy relevant to the selected event.
The base anatomical image provides context.
Clinical structures are then layered over it.
For example, an event affecting the left shoulder may highlight:
Left shoulder joint
on the anatomical model.
Amber: This Event
Amber/orange highlighting represents anatomy directly associated with the currently selected clinical event.
The highlighted layer may pulse to draw attention to the relevant anatomical area.
Conceptually:
AMBER
=
involved in this event
For example:
Severe contusions to left shoulder and thorax
             |
             v
        LEFT SHOULDER
        highlighted
Blue: Ongoing from Earlier History
A cool blue highlight represents anatomical involvement that originated with an earlier event and has been recorded as ongoing.
Conceptually:
BLUE
=
ongoing from an earlier event
This lets the reviewer see both:
What happened at this point in the timeline?
and:
What relevant conditions were already ongoing?
without confusing the two.
Blue ongoing layers remain steady rather than pulsing.
Viewer Legend
At the bottom of the anatomical viewer you may see:
● 1 this event
● 2 ongoing
These counts apply to the currently visible anterior or posterior view.
They are the legend for the anatomical colour scheme.
8. Anterior and Posterior Views
Use:
ANTERIOR
POSTERIOR
to switch between the front and back anatomical views.
Some structures exist only on one view.
If relevant anatomy exists on the opposite side, the viewer displays an indicator such as:
2 on posterior →
Selecting it flips the model to the other view.
This avoids hiding clinically relevant anatomy simply because the current event initially opened on the opposite view.
9. Anatomical Hotspots
Relevant structures can have a 
+ hotspot positioned over the body image.
Hover over or select the hotspot to see the structure name.
For example:
+
Left shoulder joint
Selecting a structure opens additional information about that anatomical layer.
The body itself is intentionally kept visually uncluttered.
Structure names appear only when needed rather than permanently covering the anatomical image.
10. Moving Through the Timeline
The clinical timeline appears to the right of the anatomical viewer.
Scroll through the page normally to move through the patient's life.
As each event becomes active:
its card becomes brighter
the anatomy updates
the year-axis marker becomes active
the vertical scrubber moves
relevant structures are highlighted
This creates a synchronised view of:
WHEN
+
WHAT
+
WHERE
for each event.
Timeline Scrubber
The thin vertical control between the anatomy and clinical history provides rapid movement through the record.
Drag it up or down to move through a long patient history quickly.
The displayed date changes as you scrub.
Keyboard users can also use:
Arrow Up / Arrow Left     previous event
Arrow Down / Arrow Right  next event
Home                      first event
End                       last event
when the timeline scrubber has focus.
11. Reading an Event Card
A typical event card contains:
21/04/1988
Severe contusions to left shoulder and thorax
Severe contusions to the left shoulder and thorax
from a motor vehicle accident.
● Musculoskeletal 1
View details →
The card provides the concise clinical-history view.
Event Date
The date appears above the event title.
If timing is uncertain, an uncertainty badge or range accompanies it.
The viewer is designed so that an approximate date should not look like an exact date.
Event Title
The event title is the short clinical description.
For example:
Severe contusions to left shoulder and thorax
Summary
The event body contains the concise clinical summary extracted from the source record.
For example:
Severe contusions to the left shoulder and thorax
from a motor vehicle accident.
Severity
The coloured edge of the event card represents the severity assigned to the event.
The scale is:
Minor
Moderate
Major
Critical
Higher severity events become progressively warmer/redder.
Again:
Severity represents the event at the time, not necessarily the patient's current condition.
Same-Day Events
Several independent clinical events can occur on the same date.
For example:
21 April 1988
2 events
Open Clinical History may visually group them under the same date heading.
They are still separate events with their own:
clinical meaning
SNOMED coding
source evidence
anatomy
detail record
The grouping is only a presentation aid.
12. Body-System Indicators
Instead of displaying a large list of anatomical structures on every event card, Open Clinical History groups anatomy by body system.
For example:
● Skeletal 1
● Cardiovascular 2
● Neurological 3
Select a body-system indicator to display the individual structures.
This allows complex events to remain easy to scan.
Anatomy Colours in an Event
Within the anatomy list:
Amber means the structure belongs to the selected event.
Blue means the structure is ongoing from an earlier event.
A muted structure may belong to the opposite anterior/posterior view.
13. View Details
Select:
View details →
to open the full encounter record.
This is where the concise timeline event can be inspected in greater depth.
A typical detail panel contains:
ENCOUNTER DETAIL
Severe contusions to left shoulder and thorax
21/04/1988
Age ~21
Resolved
followed by expandable clinical sections.
Encounter Header
The top of the panel can show:
event title
event date or date range
approximate age
severity
clinical status
For example:
21/04/1988
Age ~21
Resolved
The approximate age is calculated using the patient's recorded date of birth.
The 
~ indicates that it should not be interpreted as greater precision than the available dates support.
14. Summary
The Summary section contains the concise description associated with the clinical event.
For example:
Severe contusions to the left shoulder and thorax
from a motor vehicle accident.
This is the structured summary used by the longitudinal history.
15. Source Evidence
Where available, the event retains evidence from the source document.
For example:
SOURCE EVIDENCE
Severe contusions to left shoulder and thorax
This is important because it lets the reviewer compare:
Structured clinical event
        against
Source information that supported it
The event should not be considered independent of its provenance.
16. Dating
Open the Dating section to understand exactly how Open Clinical History decided where the event belongs in time.
For an exact date you may see:
DATING  exact day
Recorded as  21/04/1988
Resolves to  21/04/1988
1988-04-21 ───────────── 1988-04-21
The source stated this date.
Recorded As
Recorded as
shows the timing information as represented by the source.
Resolves To
Resolves to
shows how Open Clinical History represents that information internally.
For an exact day these will usually be identical.
For an uncertain date, the result may instead be a range.
Dating Interval
Every event is treated conceptually as a time interval.
An exact date has:
earliest date = latest date
For example:
1988-04-21 → 1988-04-21
An approximate event may instead be:
1988-01-01 → 1988-12-31
or a wider interval derived from the information available in the source.
This prevents the system from pretending that uncertain clinical timing is more precise than it really is.
Date Derivation
The detail panel also explains why the date has that range.
Examples include:
The source stated this date.
The source gave part of a date.
Derived from an age given in the source.
Derived from a life stage described in the source.
Stated relative to the date of the source document.
No dating information was recorded.
This makes derived chronology inspectable rather than opaque.
17. Anatomy
The Anatomy section lists the structures associated with the event.
For example:
ANATOMY  1 this event
INVOLVED IN THIS EVENT
● Left shoulder joint
Selecting a structure allows it to be inspected on the anatomical viewer.
If relevant structures from earlier ongoing conditions also exist, they appear separately as:
Ongoing elsewhere
This prevents an old ongoing condition from being mistaken for anatomy caused by the current encounter.
No Structures Recorded
Some valid clinical events do not have a useful anatomical representation.
For example:
systemic conditions
administrative clinical events
some investigations
some disorders without a useful local anatomical layer
In these cases the viewer may show:
No structures recorded
This does not mean the event itself is invalid.
The anatomical visualisation is supplementary to the clinical record.
18. Record
The Record section exposes the structured information behind the event.
For example:
Encounter ID      EV-3045
Setting           Imported from history document
Coded as          SNOMED CT 125667009
                  Contusion (disorder)
Date precision    Exact day
Date derivation   explicit
Interval          1988-04-21 → 1988-04-21
Outcome           resolved
Provenance        Extracted from source document
                  — not clinician-verified
This is particularly useful when reviewing how Open Clinical History interpreted an imported record.
Encounter ID
For example:
EV-3045
is the Open Clinical History identifier for the individual clinical event.
Setting
This describes the context known for the event.
For imported historical information you may see:
Imported from history document
Coded As
For example:
SNOMED CT 125667009 — Contusion (disorder)
This is the structured clinical terminology associated with the event.
Open Clinical History resolves terminology against its local SNOMED CT database.
Date Precision
This explains the precision actually supported by the source.
Examples include:
Exact day
Month
Year
Approximate
Not recorded
Do not interpret an approximate event as though its displayed timeline position were an exact clinical date.
Date Derivation
This is the machine-readable explanation of how the date was obtained.
For example:
explicit
means the source directly supplied the date.
Other values indicate that the date or range was derived from less precise information.
Interval
The stored lower and upper temporal bounds.
For an exact event:
1988-04-21 → 1988-04-21
For an approximate event these values may span months or years.
Outcome
For example:
resolved
describes the recorded clinical outcome or status of the event.
Other events may remain:
active
ongoing
depending on the information present in the clinical history.
Severity at Presentation
Where recorded, the detail view may also display the severity of the event.
Remember:
This describes severity at that clinical episode, not necessarily present-day severity.
19. Provenance
One of the most important fields in the viewer is:
Provenance
For an imported event you may see:
Extracted from source document — not clinician-verified
This is deliberate.
It tells the reviewer that:
the event originated from an imported source document;
Open Clinical History extracted and structured the information; and
a clinician has not subsequently confirmed that structured representation.
If an event is later verified, the provenance can identify that verification instead.
What "Not Clinician-Verified" Means
It does not mean the original source information is false.
It means:
The transformation from the source material into this structured Open Clinical History event has not been independently confirmed by a clinician.
That distinction matters.
For example:
Original medical letter
        |
        v
Open Clinical History extraction
        |
        v
SNOMED classification
        |
        v
Anatomical mapping
        |
        v
Displayed clinical event
Until a human clinical verification step occurs, the resulting structured representation should retain that provenance.
20. Clinical Components
Some encounters contain several clinically meaningful components.
Where available, the detail panel can display them separately under:
Clinical components
For example, one encounter may contain:
Diagnosis
Procedure
Investigation
Complication
Each component can retain its own:
title
summary
terminology coding
anatomical structures
This allows the timeline to remain readable without losing the internal complexity of a clinical encounter.
21. Clinical Threads
Where explicit relationships exist between events, the detail panel can show a Clinical thread.
Conceptually:
Earlier event
      |
      | caused by
      v
Current event
      |
      | led to
      v
Later event
This allows related events to be navigated as a clinical sequence rather than merely by calendar date.
This section appears only where those relationships have been recorded.
22. Understanding the Anatomical Visualisation
The anatomy should be interpreted as a visual index into the clinical history, not as a diagnostic image.
A highlighted shoulder means:
This event has been mapped to an installed anatomical layer representing the shoulder.
It does not mean:
the PNG shows the precise lesion
the highlighted area represents lesion size
the brightness represents tissue damage
the system has interpreted radiology
the anatomy replaces the underlying clinical evidence
The clinical event and source evidence remain authoritative context.
23. Understanding Ongoing Anatomy
When an earlier event has anatomical structures marked as chronic or ongoing, those structures can remain visible while later events are reviewed.
For example:
2010
Chronic left knee condition
        |
        v
2015
Unrelated respiratory event
        |
        +--> respiratory anatomy in amber
        |
        +--> left knee remains blue
The visualisation therefore provides context about what was already part of the patient's ongoing history at that point.
It should not be interpreted as evidence that the earlier condition was actively symptomatic on every later date.
24. A Useful Way to Read a History
For a long patient record, a practical review sequence is:
1. Scan the patient summary
        |
        v
2. Look across the year axis
        |
        v
3. Identify major/critical periods
        |
        v
4. Scroll through the clinical timeline
        |
        v
5. Watch anatomical changes
        |
        v
6. Note ongoing conditions
        |
        v
7. Open important encounters
        |
        v
8. Check source evidence
        |
        v
9. Check dating precision
        |
        v
10. Check SNOMED coding and provenance
This provides both a rapid overview and a route into the underlying detail.
25. Example Review
Consider the following event:
21/04/1988
Severe contusions to left shoulder and thorax
Resolved
The viewer may show the left shoulder highlighted.
Opening View details reveals:
Summary
Severe contusions to the left shoulder and thorax
from a motor vehicle accident.
The reviewer can then establish:
When did it happen?
21/04/1988
The Dating section confirms:
Exact day
and:
The source stated this date.
How old was the patient?
Age ~21
calculated from the recorded DOB.
What anatomy was involved?
Left shoulder joint
What was it coded as?
SNOMED CT 125667009 — Contusion (disorder)
What happened afterwards?
Outcome: resolved
Where did the information come from?
Extracted from source document — not clinician-verified
This is the intended review model:
EVENT
+
TIME
+
ANATOMY
+
CODING
+
SOURCE
+
PROVENANCE
rather than simply presenting an AI-generated summary.
26. What the Viewer Deliberately Does Not Do
The patient-history viewer deliberately avoids several potentially misleading behaviours.
It does not invent exact dates
If the source says only:
1988
the interface does not silently turn that into:
01/01/1988
and present it as fact.
It does not hide undated events
An event without a known date remains visible.
It is simply kept outside the dated chronology.
It does not pretend ongoing anatomy belongs to the current event
Current-event anatomy and carried-forward anatomy use different visual treatments.
It does not hide provenance
Imported structured information can explicitly state that it has not been clinician-verified.
It does not require an anatomical image for every event
A clinically valid event can exist without a body-layer mapping.
It does not treat the body image as the clinical record
The anatomy is a navigation and comprehension aid.
The clinical event, evidence, terminology and provenance remain accessible separately.
27. Important Interpretation Notes
When reviewing an Open Clinical History timeline:
A timeline position is not always an exact date
Check the Dating section when precision matters.
A highlighted body structure is a mapping
It represents the anatomy associated with the clinical concept, not a diagnostic image.
Blue does not mean a new event
Blue indicates relevant anatomy carried forward from an earlier ongoing condition.
Severity is historical
A Critical event may be decades old and resolved.
"Active" is based on the structured record
It reflects what has been recorded as active or ongoing, not a new clinical assessment.
An AI-extracted event should retain its provenance
If the detail says:
not clinician-verified
that should be considered when relying on the structured representation.
Source evidence matters
Where something appears surprising, open View details and compare the event against its source evidence and dating information.
Summary
The Open Clinical History viewer is designed around five questions:
WHEN did it happen?
WHAT happened?
WHERE in the body was involved?
WHAT remained ongoing?
HOW do we know?
These are represented through:
WHEN
Timeline and dating intervals
WHAT
Clinical event cards
WHERE
Anatomical visualisation
ONGOING
Carried-forward anatomical context
HOW DO WE KNOW?
Source evidence, SNOMED coding and provenance
The aim is not merely to make a health record visually attractive.
It is to make a complex longitudinal history quick to scan while preserving the uncertainty, evidence and provenance needed to understand what the visualisation actually means.