# 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: ```text /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: ```text 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: ```text MRN-1001 Joanne Reacher b. 1967 Female 12 events 2 active peak: Major to 2023 ``` --- ## Record Number For example: ```text 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: ```text b. 1967 ``` This is derived from the patient's recorded date of birth. --- ## Sex For example: ```text 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: ```text 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: ```text 2 active ``` This counts clinical events whose current stored clinical status is: ```text active ``` or: ```text 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: ```text peak: Major ``` This displays the highest event severity currently recorded anywhere in the patient's history. The severity scale is:
LevelMeaning
NoneNo severity classification
MinorMinor clinical severity
ModerateModerate clinical severity
MajorMajor clinical severity
CriticalCritical 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text 21 April 1988 ``` but it might instead say: ```text 1988 ``` or: ```text in her twenties ``` or: ```text 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text AMBER = involved in this event ``` For example: ```text 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: ```text BLUE = ongoing from an earlier event ``` This lets the reviewer see both: ```text What happened at this point in the timeline? ``` and: ```text 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: ```text ● 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: ```text 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: ```text 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: ```text + 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: ```text 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: ```text 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: ```text 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: ```text Severe contusions to left shoulder and thorax ``` --- # Summary The event body contains the concise clinical summary extracted from the source record. For example: ```text 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: ```text 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: ```text 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: ```text ● 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: ```text 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: ```text 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: ```text 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: ```text SOURCE EVIDENCE Severe contusions to left shoulder and thorax ``` This is important because it lets the reviewer compare: ```text 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: ```text 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 ```text Recorded as ``` shows the timing information as represented by the source. --- # Resolves To ```text 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: ```text earliest date = latest date ``` For example: ```text 1988-04-21 → 1988-04-21 ``` An approximate event may instead be: ```text 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text Imported from history document ``` --- # Coded As For example: ```text 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: ```text 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: ```text 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: ```text 1988-04-21 → 1988-04-21 ``` For an approximate event these values may span months or years. --- # Outcome For example: ```text resolved ``` describes the recorded clinical outcome or status of the event. Other events may remain: ```text 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: ```text Provenance ``` For an imported event you may see: ```text 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text 21/04/1988 Severe contusions to left shoulder and thorax Resolved ``` The viewer may show the left shoulder highlighted. Opening **View details** reveals: ```text Summary Severe contusions to the left shoulder and thorax from a motor vehicle accident. ``` The reviewer can then establish: ### When did it happen? ```text 21/04/1988 ``` The Dating section confirms: ```text Exact day ``` and: ```text The source stated this date. ``` ### How old was the patient? ```text Age ~21 ``` calculated from the recorded DOB. ### What anatomy was involved? ```text Left shoulder joint ``` ### What was it coded as? ```text SNOMED CT 125667009 — Contusion (disorder) ``` ### What happened afterwards? ```text Outcome: resolved ``` ### Where did the information come from? ```text Extracted from source document — not clinician-verified ``` This is the intended review model: ```text 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: ```text 1988 ``` the interface does not silently turn that into: ```text 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: ```text 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: ```text WHEN did it happen? WHAT happened? WHERE in the body was involved? WHAT remained ongoing? HOW do we know? ``` These are represented through: ```text 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**.