Style guide — Ways of Working for Digital Health & Care

This guide is shared by every topic author so the book reads as one coherent volume. Follow it exactly.

Audience#

Senior leaders, delivery leads, product managers, clinicians-turned-digital-leaders, and operational managers in digital health and care organizations — NHS bodies and trusts, integrated care systems (ICS/ICBs), social care organizations, arms-length bodies (e.g. NHS England, NHSX legacy, UKHSA), health-tech suppliers, and government digital units. Assume a UK/NHS and social-care centre of gravity, with internationally transferable principles (US HIPAA, EU/UK GDPR, HL7 FHIR context where relevant).

Voice & tone#

• Authoritative, practical, calm. Write for a busy director who wants to act, not admire.
• Prefer plain English. Expand every acronym on first use in each topic.
• Second person ("you", "your organization") when giving guidance; third person when describing practice.
• No hype. Name trade-offs honestly. Evidence over assertion.

Topic structure (use these headings)#

1. # Topic N — Title
2. In one sentence — a single bold sentence stating the topic's thesis.
3. ## Why this matters in health and care — the domain-specific stakes (safety, equity, statutory duties, public money).
4. ## Core concepts — the definitions and mental models.
5. ## Best practices — numbered, each a bold lead-in + 2–4 sentences. This is the heart of the topic.
6. ## Questions to discuss with your team — exactly six numbered questions for peer discussion, placed BEFORE the examples. Each is an open (non-yes/no) question in bold, followed by a comprehensive paragraph (4–8 sentences) that: explains why the question matters in a digital health/care setting, surfaces the tensions and trade-offs to debate, points to concrete angles and examples to consider, and describes what a good, honest answer looks like. Make the questions genuinely useful in a real team workshop.
7. ## In practice: a health & care example — a concrete worked scenario (fictional but realistic; e.g. an ICS rolling out a shared care record).
8. ## Sector lenses — the SAME topic applied in four different organizational contexts, as four ### subsections in this order: ### Startup (a small, fast, funding-constrained, usually pre-revenue digital-health company), ### Small business (an established small or independent provider/SME — a GP practice, a care home, a single-site provider, or a small health-tech supplier past the startup stage), ### Enterprise (a large, complex organization — an NHS trust, an ICS, or a big health-tech/pharma firm), ### Government (a national or local public body — NHS England, DHSC, a devolved government, UKHSA, a local authority). Each is 3–6 sentences, concrete and specific, showing how the topic's practice changes with organizational scale, funding model, risk appetite, and accountability.
9. ## Common failure modes — a short list of anti-patterns and how to avoid them.
10. ## Maturity model — a 5-level table (Initiate / Develop / Standardize / Manage / Orchestrate) with 3–5 rows of observable characteristics.
11. ## Checklist — 6–12 actionable checkbox items (- [ ]).
12. ## Key sources — bulleted, with real, verifiable references (NHS, GOV.UK, NICE, professional bodies, recognized frameworks). Cite frameworks by name (e.g. NHS Digital Service Standard, GDS Service Manual, MSP, PRINCE2, SAFe, Kotter, ADKAR, Spotify model, Team Topologies, OKRs).
13. ## References — a numbered list (1. …) of full references for the topic, combining (a) the Wikipedia articles for the key concepts named in the topic and (b) the authoritative sources. Each entry: title — publisher/author — URL. Wikipedia URLs use canonical English article titles (e.g. https://en.wikipedia.org/wiki/Kanban_(development)).

Wikipedia links (required)#

• On the first mention of a key named concept, framework, or method in ## Core concepts (and elsewhere where natural), hyperlink the term to its English Wikipedia article: [Cost of delay](https://en.wikipedia.org/wiki/Cost_of_delay).
• Verify each article exists before linking (a quick WebSearch/WebFetch for site:en.wikipedia.org <term>); never invent a slug. If no good article exists, don't force a link.
• Aim for 5–12 Wikipedia links per topic — enough to help a reader research, not so many the prose turns blue. Every Wikipedia article you link inline must also appear in ## References.

Formatting rules#

• Markdown only. Use tables for comparisons and maturity models.
• Keep paragraphs to 2–4 sentences.
• Bold the lead phrase of each best practice.
• Target ~2,500–3,500 words per topic (current topics run ~2,900–3,400). Be comprehensive but not padded.
• Use Oxford spelling (en-GB-oxendict): British English with -ize/-ization (organize, prioritize, standardize, realize, optimize, recognize), but keep all other British forms — -our (behaviour), -re (centre), -yse (analyse, not analyze), doubled l (modelling), licence/defence nouns, and -ae/-oe (paediatric). Keep "program" only for a computer program; use "programme" for the delivery construct (programme management, MSP). Full rules and the URL/citation-protection mechanics are in spec/oxford-spelling.md. Be consistent within a topic.
• Cross-reference sibling topics by number and title, e.g. "(see Topic 8.1 — Change Management)". The canonical topic numbering lives in spec/index.md §4 — check it before citing a number.

Grounding#

• Ground claims in recognized frameworks and public guidance. Real, checkable sources only — do not invent citations, URLs, statistics, or quotations. If unsure of a figure, describe the pattern qualitatively instead.
• Favour these canonical bodies of knowledge where they fit: NHS Digital Service Standard & Service Manual, GOV.UK Service Manual (GDS), NICE Evidence Standards Framework for Digital Health Technologies, MHRA, DTAC (Digital Technology Assessment Criteria), Team Topologies, Spotify/agile-at-scale, SAFe, PRINCE2, MSP (Managing Successful Programmes), Management of Portfolios (MoP), Kotter's 8 steps, ADKAR (Prosci), OKRs (Doerr), Lean/Toyota, Cynefin (Snowden), double-diamond discovery (Design Council).