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 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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

  1. the event originated from an imported source document;

  2. Open Clinical History extracted and structured the information; and

  3. 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:

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 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.

Revision #1
Created 2026-08-25 10:38:48 UTC by Admin
Updated 2026-08-25 10:39:03 UTC by Admin