Why standardise clinical pathways?
The problem is not that clinicians lack pathways. It is that pathway meaning is often scattered across guidance, local procedures, EPR configuration, referral forms and tacit knowledge, making cross-organisational care hard to compare and govern.
Different teams describe the same pathway differently
Responsibilities, information needs and escalation may be expressed inconsistently or remain implicit.
The pathway can become tied to today's systems
When care meaning is embedded in an EPR or local workflow, changing technology can unintentionally change the model of care.
Cross-organisational care is difficult to see as one whole
Frailty care can cross primary care, community services, social care, pharmacy, urgent response, virtual wards and hospitals.
A simple way to think about HPDS
A governed collection where definitions can be found, compared and maintained.
The intended model of care and the primary business artefact.
How particular organisations, services and technology realise the definition.
The actual course of care for an individual, held outside the HPDS definition.
Five minutes through a recognisable frailty scenario.
The example uses Deterioration identified at home or usual residence to show what the standard adds without requiring the reader to understand the technical model first.
Structure should reduce ambiguity without turning the pathway into a software specification.
WD 0.5 keeps business meaning primary. Greater formality is available where needed, but a higher conformance level is not inherently better.
Without a common representation
- Pathways are difficult to compare across services.
- Responsibilities and information dependencies may be implicit.
- Local system design can be confused with clinical intent.
- Evidence, authority and lifecycle can be conflated.
- Changing technology may require rediscovering the care model.
With a governed pathway definition
- Identity, version, lifecycle, authority and intended use are explicit.
- Population, entry, exit, activities, decisions, roles, outcomes and evidence can be inspected consistently.
- Local delivery stays in the implementation layer.
- Relationships can be represented progressively, from Level 1 catalogue links to a complete Level 2 graph.
- Evidence provenance remains separate from clinical approval.
Explore the neighbourhood-care catalogue.
The 35 care-pathway records are candidates for HPDS pathway definitions. Three governance-process records are retained as supporting material but are outside HPDS pathway-definition scope.
| Pathway or support record | Domain | Class | What is it for? |
|---|
One definition can have different local implementations.
Named provider organisations, sites, products, interfaces, local procedures and workflow configuration belong in a PathwayImplementation rather than in the care-model content of the pathway definition.
A shared record can support the pathway without becoming the pathway.
HPDS describes technology-neutral information requirements, products, constraints and interoperability dependencies. A shared care record, EPR or integration platform is part of local implementation architecture.
Evidence provenance is not clinical approval.
The source catalogue distinguishes material grounded directly in guidance from synthesis and professional inference. WD 0.5 separately records authority status, intended use and lifecycle state.
Why the distinction matters
An evidence description tells you where content came from and how it was derived. It does not make the pathway clinically approved, and technical HPDS conformance would not do so either.
These are implementation-authoring aids. WD 0.5 Appendix H confirms that they are outside the pathway definition.
| Topic | Question | Relevant pathways |
|---|
How the source catalogue maps to HPDS Release 1, Working Draft 0.5.
This view uses the WD 0.5 conceptual model and normative JSON property names. It does not claim that the 35 source records are conformant. Where the source catalogue lacks required semantics, the gap is shown rather than filled by inference.
| Required item | Source catalogue | Status |
|---|
| Item | Value | WD 0.5 target | Status |
|---|
| Source field | HPDS target | Handling | Layer |
|---|
The projection uses WD 0.5 property names and contains only information that can be derived transparently from the source record. Missing mandatory values are listed separately. The projection is therefore not a conformance claim and is not expected to validate until the authoring gaps are resolved.