Our ability to adopt, deploy and improve technology is fundamental in our mission to build a health and care system that works seamlessly, for patients, families and staff.

That means building services that span organisational, disciplinary, geographical and care boundaries so that, for example, as a patient, you don’t receive an appointment for clinic at the same time as your appointment for an x-ray.

We must step back and re-imagine how health and care services can work with the technology now at our disposal, and that means focusing on the outcomes we wish to deliver. One unifying outcome must surely be to create a truly seamless service.

So what must be our priorities in order to create such a seamless services?

1. We need an unerring focus on user need, so that we design services that fundamentally put the patient at the centre and design through that perspective rather than one focused through the prism of an a single organisation or department.

2. We must improve our ability to adopt and deploy technology, by adopting best practices such as modularisation. Modularisation is the process in which a large problem is broken-up into smaller sized chunks, making it possible for a small team to fully understand the problem and fully own the solution to that problem, and permit rapid delivery by enabling parallel working and minimising the need for constant interaction and checking between those teams that would otherwise slow down our ability to continuously iterate and improve.

3. We must recognise the benefit of bringing diverse skills, experience and perspectives together to form cross-functional, multi-disciplinary teams who are trusted and empowered to understand and to solve these bite-sized problems. We need to avoid creating silos based on organisation, discipline or historic boundaries and instead understand ‘team-first’ boundaries aligned to business domains.

4. We must prioritise meaningful data, and regard data and the computing services that operate on those data as first-class products that, when combined together, form a cohesive open platform. Such work must be enabled by the adoption of open technical standards to define application programming interfaces (APIs) that act as technical contracts between those services.

Coherence: “Logical and consistent”

If we want our work in technology to be logical and consistent, we must have an overall strategic vision which sets out, openly and transparently, a set of high-level broad principles and the rules, guard-rails and design patterns that we will all use.

It’s very easy to think that consistency can only be achieved by managing complex technology programmes with a centralised command-and-control approach. Such an approach is naive.

Instead we must look to devolve power from the centre while maintaining overall coherence by setting the broad direction.

We should be:

“Crossing the river by feeling the stones”

Deng Xiaoping

And that means empowering teams, to deliver, at pace and incrementally, by a range of measures including

• being clear on overall strategic direction
• understanding that the most difficult part of technology is not the technology itself, but the management of change - in people, behaviour and the work itself that our best technology can empower
• deciding on appropriate modularisation and creating teams to deliver those products
• aligning our governance, architecture and standards into a cohesive whole.

Governance structures, technical architecture and technical standards are mutually dependent; for example it is not possible to define coherent governance without understanding the technical architecture to which we aspire.

A matrix of coherence

We need consistency across multiple domains. One way of thinking about structuring a coherent strategy is to consider two broad types of domain:

1. Business domains, aligning to business problems and their solutions.
2. Functional domains, aligning to technology problems and their solutions

A business domain is a specific, tangible business problem, such as citizen identity. That problem might be solved through the provisioning of a range of coherent products, some bought off-the-shelf such as an enterprise master patient index, and some developed in-house, such as a microservice that acts to cache identity updates and provide a canonical authoritative source of demographics information via a FHIR Patient resource. It makes no sense to procure or develop products or services that aren’t coherent with other products in this domain. ¹ Domain-driven design is about designing data and computing services based on models of the business domain itself, with bounded contexts a unit for breaking up a larger domain into smaller parts.

A functional domain is a specific, tangible technology domain, such as security engineering, system reliability engineering, infrastructure management, operations and user-centred design. Similarly, it will usually make little sense to not have a consistent approach to these core functional domains across a wider enterprise, although good judgement is needed to understand when to deviate in order to solve a specific problem.

This schematic shows business domains orientated vertically, and functional domains orientated horizontally as representing a set of coherent services providing an open platform on which applications can run, with the use of an API gateway and a coherent scheme for authentication and authorisation on a per-application, per-user basis:

This approach should make it obvious that building security and logging at an application-level, as is currently the case in Wales, is a mistake, and data and computing services should be first-class products exposing their data and functionality through open service interfaces, via APIs.

Towards technical excellence - and coherence within and across functional domains

Similarly, we need to aspire to technical excellence, with lead roles for experts in engineering and design, including security, software development, operations, infrastructure, standards and architecture, able to take a coherent “all-Wales” view and provide, openly and transparently, a set of guidelines and principles and design patterns that will shape our currently prioritised programmes of work.

That means we need a separate programme of work to build and reward technical capability within health and care in Wales; for too long, the only way experienced engineers could progress was in management, and we have too many engineering teams led by managers with no technical skills or experience. Part of the blame must lie with the pay-scales within Agenda for Change.

It is convenient to think of technical experts grouped into guilds or tribes, sharing good practice and helping to contribute, openly and transparently, to a range of principles, standards and design patterns for their specific domain; such work providing core principles, design blueprints and support for programmes and the teams working on solving domain problems.

Such an approach doesn’t mean top-down control or even homogeneity. We must recognise that experts will need to deviate and innovate in order to solve real-life problems, and use that experience to feedback, inform and improve the guiding principles which we can all use. Through this, we build a continuously learning approach to technology. It is unlikely that a single technology stack or programming language would be appropriate across a complex system such as health and care, but we must endeavour to share good practice and harmonise our general approach.

This matrix approach to governance is shown in the following schematic:

The important features are:

• Long-lived but small cross-functional product teams
• Multiple products grouped into dynamic and flexible programmes, created to meet our current and pending priorities.
• Data and computing services as first-class products, creating an open platform
• Functional domain experts providing all-Wales high-level principles, standards and design patterns on their domain, such as security, infrastructure, architecture and design as well as contributing to product teams when appropriate.
• High-level overview board providing core high-level principles and oversight as well as responsibility for redefining the dynamic programme structure based on present needs, with membership drawn from clinical, managerial and technical experts.

We’ve already started some of this work via the Welsh Technical Standards Board; we have adopted the GDS design principles, published our own working principles and have submitted our architectural principles for review. Through this, we want to inculcate debate, feedback and so transform our approach to health and care in Wales.

Mark

Footnotes

1: We currently have an example in Wales in which a re-procurement of a laboratory management system is in one programme of work, and re-procurement of a radiology information system is in another. Both are considering including “test requesting” functionality and yet, for end-users, we want a seamless system that, in clinic or on the ward, allows us to request multiple things including referrals, laboratory, radiology and other tests. We don’t want separate “systems” but instead what appears to be a streamlined “single system”. Therefore, programmes of work need to be framed with user need; one logical approach might be to consider “results and requests” as a business programme to manage a suite of products, that would include concierge services that take user requests and farm them to our different backend systems via APIs, as well as managing the re-procurement of laboratory and radiology services.