Technical Strategy

DHCW's technical landscape is characterised by fragmented systems that do not talk to each other, proprietary interfaces that lock Wales into specific vendors, legacy platforms running on unsupported technology, and an absence of the interoperability standards that enable modern healthcare digital infrastructure. The Royal Colleges warned that this fragmentation causes patients to "regularly experience delays that lead to worsening health." DHCW itself acknowledged it "increases the risk of harm to patients."

Reform requires adopting the interoperability standards that the rest of the UK and Europe are moving to, publishing open APIs, establishing shared platforms, and ring-fencing investment to remediate dangerous legacy systems.

1. HL7 FHIR UK Core Mandate

The problem: Healthcare data in Wales is locked in proprietary formats, siloed in individual systems, and exchanged through point-to-point interfaces that are brittle, expensive to maintain, and impossible to extend. When a GP refers a patient to a hospital, the data does not flow seamlessly — it is translated, re-keyed, or transmitted through systems built on technology unsupported for eight years.

The international standard for healthcare data exchange — HL7 FHIR (Fast Healthcare Interoperability Resources) — has been adopted as the mandatory standard by NHS England, mandated across Europe under the European Health Data Space regulation, and implemented nationally in Denmark, Finland, and the United States. Wales has not adopted it.

The proposal: Mandate HL7 FHIR UK Core as the sole interoperability standard for all DHCW systems, with a defined migration timeline.

Implementation:

• Immediate (0-6 months): All new system procurements and developments must require FHIR UK Core compliance. No new system may be purchased or built that uses proprietary data formats for patient data exchange.
• Year 1: DHCW publishes a FHIR Conformance Roadmap for every existing national system, identifying which data resources will be exposed as FHIR endpoints and by when.
• Year 2-3: All national systems expose at least their core clinical data (patient demographics, appointments, referrals, results, medications, allergies) as FHIR UK Core APIs.
• Year 3-5: Full FHIR UK Core compliance across the national platform, enabling any authorised system to query any other system using standard APIs.

Why this matters for patients: When a hospital doctor can see a patient's GP record, current medications, and recent test results through a standard interface — without logging into a separate system, phoning someone, or waiting for a fax — care is faster, safer, and cheaper. This is not futuristic. It is what Denmark does today through sundhed.dk.

Comparator: NHS England has mandated FHIR UK Core and published detailed implementation guidance. Denmark has built its entire national health data infrastructure on FHIR. Estonia exchanges health data across all providers through X-Road. Wales has no interoperability standard and no published timeline for adopting one.

2. Published API Catalogue

The problem: DHCW does not publish a catalogue of the APIs (Application Programming Interfaces) available for Health Boards, third-party systems, and clinical applications to use. If a Health Board wants to build a local clinical dashboard that draws on national data, or a GP system vendor wants to integrate with Welsh national services, they have no public documentation of what interfaces exist, what data they expose, or how to connect. Integration depends on personal relationships, bilateral negotiations, and reverse engineering.

The proposal: Publish a comprehensive API Catalogue covering all national DHCW systems.

Requirements:

• Discovery phase (3 months): Catalogue all existing APIs and interfaces across DHCW national systems — including undocumented, internal, and legacy interfaces.
• Publication (6 months): Publish the catalogue on a dedicated developer portal, including for each API: endpoint description, data model, authentication requirements, rate limits, availability SLA, versioning policy, and example requests/responses.
• Ongoing: All new APIs must be documented in the catalogue before going live. API usage metrics (call volumes, error rates, latency) published monthly.
• Developer sandbox: Provide a testing environment where Health Board technical teams and accredited third parties can develop against DHCW APIs without affecting production systems.

Comparator: NHS England operates the NHS Developer Hub with published APIs, documentation, and a sandbox environment. GDS publishes the GOV.UK API catalogue. DHCW has no equivalent.

3. Welsh Health Data Exchange

The problem: Wales needs a way to exchange health data securely between organisations — not just between DHCW systems, but between Health Boards, local authorities, social care providers, and the third sector. Currently, data exchange happens through ad hoc, bilateral, and often manual processes. There is no national data exchange layer.

The proposal: Build a Welsh Health Data Exchange modelled on Estonia's X-Road.

What X-Road does: X-Road is a distributed data exchange layer that allows any authorised organisation to query data from any other authorised organisation — securely, with full audit trails, without creating a central data store. Each organisation retains control of its own data but exposes defined data services through the exchange layer. Every query is logged, every access is traceable, and no data is copied or stored centrally.

How it would work for Wales:

• Architecture: Federated, not centralised. No single point of failure. Each Health Board and DHCW system connects through a local "security server" that handles authentication, authorisation, and audit logging.
• Standards: All data exchange through FHIR UK Core (see above). Authentication through NHS Wales Identity Service. Authorisation through role-based access control aligned with NHS Wales information governance frameworks.
• Governance: Data sharing agreements published. A Data Exchange Board — including Health Board representatives, patient representatives, and an independent information governance specialist — oversees access policies.
• Patient transparency: Every patient can see who has accessed their data through the exchange, when, and for what purpose — through the NHS Wales App (once it actually works).

Comparator: Estonia built X-Road for a population of 1.3 million — almost exactly the population of Wales that uses digital health services. The technology is open source, production-proven, and already adapted for healthcare use. Finland and Iceland have deployed X-Road variants for health data exchange. Wales could adopt a proven solution rather than building from scratch.

4. Adopt NHS England Shared Components

The problem: DHCW attempts to build national digital services from scratch — then fails to deliver them. Meanwhile, NHS England has built production-proven shared components that solve the same problems: the NHS App, NHS Login, the NHS Design System, NHS Notify, the Personal Demographics Service, and more. Wales does not use any of them, instead attempting to recreate equivalent functionality independently — at far greater cost and with far worse outcomes.

The proposal: Adopt NHS England shared components wherever clinically and technically appropriate, adapted for Welsh language and Welsh legislative requirements.

Priority components for adoption:

• NHS Login — Secure patient identity verification. Already in production across England. Adaptable for Wales with Welsh language support.
• NHS Design System — Proven UI patterns for healthcare digital services. Adopting the design system (with Welsh language modifications) gives Welsh services consistent, tested, accessible interfaces without reinventing them.
• NHS Notify — Secure messaging service for patient communications. Would replace DHCW's multiple bespoke notification approaches.
• NHS Service Manual — Clinical safety, accessibility, and user experience guidance. Directly applicable to Welsh services.

Welsh language requirement: All adopted components must support Welsh language alongside English, meeting Welsh Language Standards. This requires investment in translation and localisation — but localising an existing, working component is dramatically cheaper and faster than building a failing one from scratch.

What DHCW should NOT adopt: Components where Welsh policy differs materially from English policy (e.g., where devolved legislation creates different clinical pathways) or where England's implementation is itself problematic. The goal is pragmatic reuse, not blind copying.

Comparator: Scotland's NES (NHS Education for Scotland) Digital Service selectively adopts and adapts shared UK components where appropriate, building bespoke only where Scottish requirements genuinely diverge. This is the pragmatic model Wales should follow.

5. Independent Cyber Security Assessment

The problem: DHCW's national systems include platforms running on technology that has been unsupported for eight years (WCCG), patient identity infrastructure that has already suffered a catastrophic outage causing record mix-ups (eMPI), and a patient administration system in every hospital that has been identified as a factor in at least one death (WPAS). The cyber security posture of these systems is unknown publicly. DHCW does not publish penetration test results, vulnerability assessments, or compliance status against any recognised cyber security framework.

The proposal: Commission an independent cyber security assessment of all DHCW national systems, conducted by the National Cyber Security Centre (NCSC) or an NCSC-approved provider.

Scope:

• All national systems: WPAS, WCCG, WCP, eMPI, GP systems connectivity, the NHS Wales App platform, and all supporting infrastructure.
• Assessment against: NCSC Cyber Assessment Framework (CAF), which is already used for assessing other NHS organisations and Critical National Infrastructure operators.
• Output: A published summary report (with appropriate redaction of specific vulnerabilities) covering: overall cyber resilience posture, critical vulnerabilities requiring immediate remediation, compliance status against NCSC CAF, and recommended remediation priorities.
• Follow-up: Quarterly progress reports on remediation, published until all critical and high-severity findings are resolved.

Comparator: NHS England conducts regular cyber assessments against the NCSC CAF and publishes aggregated results through the Data Security and Protection Toolkit (DSPT). DHCW participates in the DSPT but the depth and independence of its assessments are not publicly verifiable.

6. Ring-Fenced Legacy Remediation Budget

The problem: DHCW's legacy systems — WPAS, WCCG, and others — are ageing, unsupported, and in some cases dangerous. But investment in legacy remediation competes with investment in new programmes — and new programmes are more politically attractive. The result: legacy systems continue to deteriorate while new programmes consume all available budget and attention, then fail to deliver. The patient-facing systems that clinicians depend on every day are starved of the investment needed to keep them safe.

The proposal: Ring-fence a dedicated Legacy Remediation Budget, funded separately from the new programme portfolio.

Requirements:

• Minimum 25% of DHCW's annual technology budget ring-fenced for legacy systems — including security patching, platform upgrades, performance improvement, and migration planning.
• This budget cannot be raided to fund overruns on new programmes. It is a separate funding line with separate governance.
• Prioritisation based on the independent cyber security assessment (see above), with systems posing the greatest risk to patient safety addressed first.
• Published spend: Quarterly publication of legacy remediation spend by system, including work completed and residual risk assessment.
• Target: Within 3 years, no national DHCW system should be running on a platform that has been out of vendor support for more than 12 months. Within 5 years, all national systems should meet NCSC CAF baseline standards.

Comparator: NHS England's Transformation Directorate operates dedicated funding streams for legacy remediation separate from new service development. The distinction is critical — without it, legacy investment is always deprioritised in favour of shiny new programmes that are more politically visible but less operationally important.

These six reforms — FHIR mandate, API catalogue, data exchange layer, shared component adoption, cyber assessment, and legacy remediation — would transform DHCW's technical landscape from a fragmented, proprietary, insecure patchwork into a modern, interoperable, secure platform. Every one of these reforms has been implemented successfully by at least one comparable organisation. None requires invention. All require will.