Jonathon Page

Meet the Team

Discover the capabilities of the team: what skills do we have? What skills are we missing? Where are our strengths and weaknesses?

Meet the Management

• Basic Alignment

  What are your goals? What have we already committed to? Do you have early projects ready to pursue, or fixed ideas about the direction of the team?

• Critical Information

  Is there anything urgent or safety-related I should know from day one? Who are my key contacts for cyber security, infrastructure, and governance?

Meet Clinical and Operational Leads

Reach out and start booking time with the people closest to patient care and day-to-day operations — building these relationships early is where real project discovery begins.

Open the Door

Encourage people to reach out and chat. Advertise who I am and what I'm here to do, and be proactive in the search — anyone who wants to talk is welcome.

Start Looking, Not Just Listening

A first, light look at what applications and workarounds already exist — enough to start the deeper landscape review properly over the following weeks.

An Environment That Supports Best Practice

The right tooling and workflow from day one — a team working around missing infrastructure will quietly normalise cutting corners.

Version Control Is Non-Negotiable

Every change tracked, every release reproducible. This isn't a preference — it's the baseline that makes everything else in this section possible.

Coding Standards, Set Together

Created collaboratively by the team, not handed down — standards people helped write are standards people actually follow.

Peer Review as Habit

A second pair of eyes on every change, before it moves further — catching problems while they're still cheap to fix, and spreading knowledge across the team.

Information Governance, Addressed Early

Considered at design stage for every project, not raised as a question once something is already built.

Risk Assessments, Every Time

Carried out for any system we build or change, however small it looks — consistency here is what makes the assessment meaningful.

Audit What Exists

Map the current application estate: what's supported, what's end-of-life, what's shadow IT holding a service together quietly. You can't prioritise what you can't see.

Go Where the Work Happens

Sit with control room staff, crews, and corporate teams doing the work day to day. The best backlog comes from watching people work around a problem, not from a workshop.

Listen to What Already Complains

Incident reports, complaints, and audit findings often already contain the digital pain points — I'd mine what exists before asking people to repeat themselves.

Prioritise on Two Axes

Safety and risk on one axis, effort and deliverability on the other. This gives an honest, defensible shortlist rather than whoever asked most recently or most loudly.

Low Clinical Risk

A checklist or reporting improvement carries little risk of direct patient harm if something goes wrong early on — a safe place to learn as a new function.

High Visibility

Crews and managers feel the difference immediately: less paper, faster completion, better data. A clear before-and-after story to point to.

Genuinely Deliverable

Scoped to weeks, not months. The first release from a new function should be small enough to actually ship.

A Foundation, Not a One-Off

The same pattern — replacing paper or manual steps with a simple, well-tested digital equivalent — is repeatable across operational and corporate services.

Buy or Configure First

If it's a problem already solved elsewhere in the NHS, I default to buying or configuring — there's no credit in reinventing a solved problem.

Automate or Integrate

Where the gap is plumbing between existing systems — data moving manually that shouldn't be — automation or integration is usually faster and lower-risk than new software.

Build Only With a Reason

I'd only recommend building where there's a genuine, specific gap, and where we can commit to owning and supporting it long-term. Building without ownership is how technical debt starts.

Applied to the Example

For a checklist-style project, I'd expect to configure an existing form/workflow platform rather than build custom software — quick to deploy, easy to support, low long-term cost.

Test Before It's Trusted

Automated testing where practical, and real user acceptance testing with the clinical or operational staff who'll actually use it — not just the team who built it.

Release Safely, Not Silently

Staged rollout to a small group first, a clear rollback plan, and visible communication about what's changing and when.

Documentation as a Deliverable

Not an afterthought — if it isn't documented, it isn't finished. This protects the team and the Trust when I'm not in the room.

Bring Them In Early

Information governance and cyber security involved from the first design conversation, not asked to approve a finished product.

Procurement and Finance as Allies

Early, honest conversations about cost and route to market avoid late surprises and build a working relationship I'll need again on the next project.

Suppliers Held to the Same Standard

Clear expectations on support, security, and data handling — trust extends to anyone whose code touches our systems.

NHS Wales, Not WAST Alone

Early contact with Digital Health and Care Wales and peers in other health boards — to avoid duplicating work that already exists elsewhere in Wales.

Safety First, Always

Every system considered for its potential to affect patient or staff safety, with a clinical safety assessment where relevant.

Accessible by Design

Built to accessibility standards from the start, not retrofitted — this affects staff and members of the public alike.

Welsh Language, Built In

Meeting Welsh Language Standards and the Active Offer as a design requirement, not an afterthought bolted on before release.

Data Protection and Cyber Security

Privacy and security considered at design stage, aligned to NHS Wales standards — protecting patient and staff data is foundational, not a checkbox.

Business Continuity

Every system needs a fallback plan — paper or manual process included — for when it's unavailable. Digital should never become a single point of failure for care.

Train and Champion

Practical training and local champions on the ground — people trust colleagues who show them something works more than they trust an email announcement.

Roll Out in Stages

A phased rollout, learning from the first group before wider release, with a clear route for feedback to reach the team quickly.

Measure the Benefit, Not Just the Launch

Time saved, errors reduced, or experience improved — tracked against a baseline, so "delivered" and "delivering value" aren't treated as the same thing.

Support Doesn't Stop at Handover

Every product has a named owner and support path after launch — I won't be moving to the next project and leaving this one to fend for itself.

A Safety Incident Linked to a Digital System

Mitigated through clinical safety assessment, staged rollout, and always keeping a manual fallback available.

Poor Adoption After Launch

Mitigated by involving users from day one, choosing genuinely useful first projects, and having champions on the ground rather than relying on a single announcement.

Scope Creep on the First Project

Mitigated by a tightly agreed scope up front and the discipline to say "that's a good idea for phase two," protecting the credibility of an early win.

An Information Governance or Security Gap

Mitigated by involving IG and cyber security from the design stage, not as a late-stage checkpoint.