Diagnosis & Problem List

A diagnosis and problem list is the clinical “index” of the record: it summarises a patient’s current and past health problems, supports continuity across providers, and enables structured, auditable documentation - especially when implemented in an episode-oriented model.

Summary

Context and purpose

In outpatient care, documentation must remain clinically useful over long time horizons—often across decades—and must support shared understanding across changing teams and settings. The diagnosis and problem list is therefore a core element of the Electronic Medical Record: it provides a patient-centred overview, supports clinical reasoning and planning, and improves communication and continuity.

Documentation approaches

The document frames requirements within an episode-oriented methodology (Solon et al.) while acknowledging that outpatient systems must also accommodate problem-oriented (Weed/POMR), consultation-oriented, and document-oriented styles. The episode-oriented model is treated as a modelling “superset”: it can represent multiple documentation approaches consistently and enables analysis at episode level.

Problems, diagnoses, and lifecycle

A key conceptual distinction is made between problems and diagnoses. Early in the diagnostic process, symptoms, findings, or uninterpreted test results are captured as problems. Over time, problems may be refined into diagnoses and coded using classifications and terminologies (e.g., ICD, ICPC-2, SNOMED CT), or they may remain unresolved as problems. The model emphasises lifecycle traceability: labels evolve, suspected diagnoses may be confirmed or excluded, resolved conditions can be closed and transferred to past history, while chronic conditions require ongoing management. Complications and recurrences are represented as separate episodes to preserve a clean audit trail and enable meaningful longitudinal analysis.

Episode of Care and SOAP documentation

The Episode of Care is the fundamental organising unit: it groups all documentation related to a single health problem across encounters, spanning from the first to the last relevant contact. Within each contact, documentation is organised per episode using SOAP (Subjective, Objective, Assessment, Plan). Crucially, episode naming is historised so that the diagnostic journey remains visible over time.

Core requirements for the diagnosis and problem list

From a functional perspective, the document specifies three complementary representations derived from the same underlying data:

• Health problem / episode attributes as the atomic data object, including type (problem/diagnosis), subtype (main/secondary), status (active/inactive/closed), condition (suspected/confirmed/excluded), acute/chronic progression, localisation, name, coding, start date with configurable precision, and treatment goals/timeframes. Governance metadata (authorship, validation, timestamps, versioning, and provenance) is required for accountability and auditability.

• Linear lists generated from episodes: episode list, diagnosis list, problem list, and past history—supporting filtering, sorting, grouping, and persistence of user/user-group views.

• A hierarchical, user-curated tree as the diagnosis and problem list: numbered main nodes with sub-nodes acting as an index into the record. Nodes link to episodes, past history entries, or structured EMR data (e.g., vitals, labs, medications, procedures) and may include free text. The tree must support reordering (including moving branches), static vs dynamic links to values, and full historisation of structural changes.

Context-specific views and implementation examples

Clinical practice requires specialised representations derived from the master list (e.g., specialty subsets, reporting views for referrals, problem-specific checklists), while maintaining a single patient-centred source of truth. Implementation examples from Swiss outpatient systems (curaMED and triaMED©) illustrate how these requirements can be implemented in practice.