This blog post is based on a presentation given to the Welsh Medical Committee on 8th November 2019.

Many of the posts on this blog have focused on how we, as a clinical community in Wales, can use digital technology to drive improvements in our health and care services. The approach I have advocated, built on a foundation of open standards, interoperability with the provision of an open platform of data and computing services, has focused on the steps we need to take to improve the way we deliver technology in health and care.

Instead, this post is rather self-indulgent; it documents my own journey through health data science and the lessons I’ve learned, in building my own software systems.

The lessons are:

1. The importance of data in everything we do: whether that be in the direct care of individual patients, management of services and quality improvement and clinical research
2. That software and data services are best delivered by breaking up bigger problems into smaller ones, and understanding that components used like this are fractal, in which more complex, sophisticated problems can be solved by stitching together smaller components.
3. That the boundaries between direct care, service management and research are not the right boundaries to use when building software for health and care; instead model the legal and regulatory differences and modularise using domain-driven design principles.
4. That our health and care teams across Wales are excited and enthused by technology, and want to improve; technology leaders should not be seeking to command-and-control this work, but provide toolboxes of computing and data services that can be used to solve problems. We should be setting the standards and principles and empowering teams to deliver.
5. User problems (and needs) in health and care are usually about workflow and process, so once we have mechanisms for handling data and the way it is modelled, we can build software that works in different contexts. Think: not single applications giving views of different data (like we have now) but multiple applications giving views of the same data. This doesn’t mean you can’t have a style guide and user interface consistency via standards, and modular user-facing components so that users benefit from a toolbox of nationally-provided building blocks stitched together in different ways to suit their processes and workflows.
6. Software is our best way of acquiring, processing and making sense of data; that means being cognisant as to the architecture and governance that makes it possible for us to deliver safe, effective, high-quality software to users: that means needing agility, building mechanisms for rapid, automated testing and deployment of software at pace.
7. We need to build capabilities across health and care in software and data.
8. Purchase of a commercial electronic health record, such as Cerner or Epic, means you need greater capabilities in software and data; e.g. at the Wirral, their in-house developer team got larger after purchase of Cerner because of the need to integrate and customise - in essence these software products are themselves platforms, on which further valuable functionality can be built using the building blocks provided by that platform.
9. Many of the platform building blocks already exist in NHS Wales, and simply need modernisation. Platform components that don’t exist, such as off-the-shelf form designers, and components dealing with user interactions, can take advantage of modern generic technologic frameworks to build high-quality web-based and mobile-first applications.
10. We don’t have all of the answers; either in technology or in healthcare - we need to build systems with fast-feedback so that we plan to continuously improve.

1. I built a disease-specific research database.

My doctoral research, undertaken during my higher training in neurology, started in 2005 and was focused on understanding the clinical features and disease progression of a range of rare neurological disorders: the ataxias, and in some cases drawing phenotype-genotype correlations.

Such research requires bringing together disparate data for analysis. The graphs show the effect of genetic changes on the onset of disease of a rare disorder. I built an analytics pipeline that would run analyses automatically so that graphs and statistical tests would update immediately as I entered new data; that meant I was validating both the data and the software almost continuously, because errors would be evident immediately.

But there are significant problems with a disease-specific database:

• it usually exists alone; it creates a silo
• it might help to solve a specific problem but it doesn’t usually scale to solve new ones; it’s too specific.
• we can’t easily make those data available to others; there were few governance or technical off-the-shelf solutions that make that possible. If we want data to be shared, we would need to rely on researchers to set-up mechanisms to do so.

But amazingly, this is still the main way clinical research works - and single-disease charities continue to push “registries” as a solution in health and care. The typical approach for a registry is to build a web-based system that allows clinicians and researchers to submit data:

That’s not to say a registry is a bad thing - but we need to recognise that the actual user need is defining a population of patients by virtue of a characteristic - a cohort, and that might be diagnosis, symptom, clinical sign, procedure or intervention, and then usually collecting some specific additional information.

We clearly need to be able to stratify patients like this, building systems that allow us to understand cohorts but the current approach to building registries is not the right approach and we need to ask charities to stop funding this broken model that ends up creating silos of data, and a workflow that isn’t embedded into clinical workflows. That means a registry of the make and model of breast implants is best delivered by ensuring data systems capture such information at the point-of-care, and instead we derive a “registry” at runtime based on shared characteristics.

2. So instead I built a generic research database

I recognised that defining cohorts was critical, and started making SNOMED CT the lingua franca of my next system: a generic research database that went operational in 2007 - as far as I know the first system in the UK to use SNOMED CT in clinical operational use - it could combine generic and disease-specific outcome measures and permit multiple different “virtual” registries, derived at runtime by virtue of structured clinical data:

Here users can type in problems or diagnoses - each user interface control configured by a dynamic rules engine that is easy to change and modify. I can build forms dynamically without writing new code.

SNOMED CT is an ontology: so that if a user enters, for example, a diagnostic term of “multiple sclerosis”, then computationally we know that it is a type of “demyelinating disease” and so we can derive cohorts of patients easily at any suitable level of granularity, either very specific or much more general. This works not only for diagnoses, but clinical characteristics, procedures interventions and even characteristics such as country of birth and ethnicity:

Notice how by virtue of SNOMED CT, the chosen list is grouped by region - “Born in China” is grouped under “Born in Asia” automatically.

In all cases, users don’t know that they are entering SNOMED CT; its use is invisible as terms are entered through drop-downs, autocompletion text fields and even clicking on anatomical diagrams.

This approach to data is an important foundation in permitting the derivation of multiple “virtual” cohorts and understanding the meaning of outcome measures. After all, how can we interpret outcome measures without understanding the baseline characteristics such as diagnoses, co-morbidities, etc?

So here we see the longitudinal outcome of two patients, shown by the red line on each of the charts, drawn in real-time, potentially using data entered only moments before, overlaid onto the longitudinal outcomes of thousands of other patients with the same diagnosis, again derived dynamically, at runtime. The median progress of the group is shown by the dotted green line together with lines representing centiles. EDSS is a scale from 0 to 10, in which 0 represents a patient without any clinical signs of disease, and 10 is death. We see one patient doing worse than expected, and another doing better. We can also see that the patient not deteriorating as expected received alemtuzumab therapy, shown graphically along with the outcome data.

This approach shows the value of fast-feedback - making data valuable and useful in reducing the uncertainty around a clinical decision - patients and professionals, for example, can use these charts to support shared decision making as to whether to start a high-cost, high-risk, low frequency but highly aggressive new therapy. Users enter data when it is made useful to them, and that applies to both professionals and patients.

It is important to realise that we don’t yet know the best ways of presenting outcome data like this, either for professionals or patients, to support such decision making - some of our work is to understand what is helpful and what is not - our mission is to make information available at the right time to the right people and we need to learn how to do this effectively for lots of different types of data. If we knew all of the answers, we could take a different approach to our digital technological endeavours.

Foundational software and data services, combined with an enthusiastic and high-performing team have advanced our understanding of, for example, multiple sclerosis. We gain insights through combining different types of data such as clinical outcomes, treatments and interventions with other data such as indices of socioeconomic deprivation; we build a more detailed understanding of individual patients and groups of patients through these different perspectives.

So I ended up with a system to track outcomes and cohorts:

But such an approach, while clearly valuable, still risks being something outside of the routine day-to-day workflow of our services; how can we do this at scale, unless data - its acquisition, synthesis and use - is part of how we do our daily work?

In fact, general practitioners are years ahead of hospitals here: they’ve been collecting structured data and using that information to drive care; for instance, they have systems that ensure that patients with diabetes mellitus have an annual review.

3. So, I worked to embed data in workflows; it became an electronic health record

In moving from a generic research database to a system that supported the workflow and communication needs of our departments, I built an electronic health record. It now has over 50,000 patients and has tracked hundreds of thousands of patient contacts. It provides multiple interfaces: a web-based front-end, an iOS application and a FHIR based API.

But what do we mean by “health record”, and is this an opportunity to really start to think about what we mean by a health and care record?

This is Larry Weed in 1971:

Our health record supports our practice. “We’re a victim of it or a triumph because of it”. This record is not simply a way of documenting our work; it is inherently a tool with which we carry out the practise of health and care, and digital technologies should be transforming that, for both professional and patient, because so much more is possible when we shake off our assumptions made in the paper era.

Paper records are expensive, poorly maintained, poorly accessible, do not support team working; they contain lots of data but not in a useful format.

How many of us have supervised or performed paper notes review for audit and quality improvement purposes? Collecting piles of notes and going through them, trying to find the information we need? Technology should be helping us build a system that can continuously improve, by virtue of making the information we already collect useful and valuable, and teaching us the measures that reduce our uncertainty about decisions, whether that be for an individual patient or for groups of patients:

And surely we already have lots of valuable data in health and care? Not really. Hospital episode statistics and most centrally collected data are collected outside of the process of clinical care:

The issues are not new. The Bristol heart enquiry, in 2001, looked at the significant issues with data between 1984-1995. How many of us can say that much has changed since then?

Why do we have arbitrary boundaries between the data we collect for administrative purposes, in the running of our hospitals and services, the data used in direct clinical care, the data for management of services and research data? There are legal and regulatory differences in how such data can be used, and those need to be modelled in our systems, but we need to step back and understand that meaningful, interpretable data is the core foundation of our services. That means modelling consent and ensuring that data can only be processed in line with the legal, regulatory frameworks, as an inherent feature of our data “system”. Likewise, we must move from data being collecting primarily for secondary uses (e.g. governmental data returns) to secondary use data being derived from prospectively collected, clinically-meaningful data captured at the point-of-care.

One of the ways that we can make the acquisition, processing and use of data possible is to improve the software and data services that we use, at the point-of-care.

Here we capture the current medications in an outpatient clinic. Behind the scenes, the drugs are mapped to the NHS dictionary of medicines and devices (dm+d) and the dosages parsed, automatically roundtripping between product-based and dose-based prescribing and allowing graphical display of total daily drug doses:

Such an approach makes one realise that we need living systems that work hand-in-hand with the processes and workflows of our services. Users now record over 5000 clinical encounters in my homegrown software:

And it quickly became apparent that users had other needs - users need to safely and securely communicate in order to orchestrate clinical care. So I added secure messaging so that users could easily send messages to one another, all linked to the electronic record, so any message sent about a patient appears in the record, as well as in the relevant users’ inbox/sent mail mailboxes:

Linking disparate data is powerful. How can we interpret step monitor counts, genomic data, patient-reported outcome measures, or anything else for that matter, without understanding the patient, their characteristics, their co-morbidities and the interventions they have received?

Rather than considering research and clinical data as separate, we should think of them as simply different levels of specificity and granularity - and model the legal and regulatory rules defining the purposes to which data may be used. Similarly, even in clinical services, we expect to have more phenotypic information on a patient about to undergo epilepsy surgery compared to a new patient with an idiopathic generalised epilepsy.

So the logical conclusion is that we must start to build a range of data capabilities: and that means building analytics and software expertise within health and care. We cannot afford to outsource this work. Our health and care systems must become data-driven, in partnership with academia, the third-sector and commercial partners, but we must ourselves, in health and care, truly make digital the way we do business. We shouldn’t only be attempting to describe what is happening right now (although in most outpatient departments, we can tell you how many patients are seen, but have little insight into what they are seen for or indeed how they fare!) but move towards much more advanced data capabilities such as predictive analytics.

4. A more integrated approach - and highlighting the need for a platform

In order to really embed data acquisition and use in the workflows of our departments, across all organisations in Wales, I realised that my electronic health record could not live in isolation - instead it needed to integrate closely with other software and data systems within NHS Wales.

But this work was really difficult. In fact, this has been and continues to be the most challenging aspect. Bespoke, proprietary integrations with different systems in Wales, with no cohesive platform and no consistency in underlying data or its structure. I started doing this work back in 2008, and quickly found I had to somehow make decisions about the “source of truth”. For example, as a system used across different organisations in Wales, I built integrations with different patient administrative systems, attempting to provide a unified view. But I soon found that one system might record a patient as deceased while another would have the patient recorded as alive!

The even bigger problem was not even being able to get access to the data available for direct care, even when teams had built scalable national services such as repositories for laboratory and radiology data, there was seemingly no transparent process for gaining access.

Irrespective of these limitations, being able to pull out patient information, clinic lists and write data back into document repositories has been sufficient to enable multiple workflows and create, I hope, valuable software.

For example, this is from our botulinum toxin clinic. We knew how many patients attended, but didn’t know who received this costly treatment or indeed have any insight into their outcomes. We suspected that many patients were receiving treatment without benefit.

The easiest way to help solve this problem was to build a solution focused on clinical workflow that made it easier in clinic - but as a side-effect allowed us to track what was done, who it was done to and combine that with postcode data mapped to organisational boundaries and calculate drug dose uses per local health board:

Users see a list of the patients for the clinic, pulled from the local patient administrative system, record data and then create a structured document, coded with SNOMED-CT procedures, diagnoses and indications together with a PDF version - which is sent into local and national document repositories automatically:

Similarly in our motor neurone disease service, we need to be able to valuably support professionals in our multi-disciplinary teams. One aspect of this is tracking weight to identify patients in need of nutritional support. Of course, these data are already recorded in clinic by nursing staff, but usually on post-it notes or copied into paper records.

The solution to this was two-fold. First, ensure that we had a mechanism to record body weight in the electronic record, and second, to use SNOMED CT to identify the cohort of patients with motor neurone disease or any subtype, and then provide a summary page that picked out the relevant information from the wider record to help clinical care:

I’m pleased to say that we won an award at the NHS Wales 2019 awards for our work across South Wales for this type of work.

While this looks simple, the software is determining baseline weight by determining the onset of the patient’s subtype of motor neurone disease and finding a recorded weight as close as possible to that date, and then calculating the percentage change for the most recently recorded weight: we usually need to have a conversation about intervention if you lose 10% of your baseline weight.

But integration remained too difficult, and I looked in envy at how other non health and care “platforms” provided a credible and cohesive set of data and software services, often cloud-based, that could be stitched together to create innovative solutions to solve user needs, hitherto not considered by the original developers of that “platform”.

At the same time, I was spending more time looking at how others were solving these issues: megasuite EHR vendors such as Cerner and Epic were heavily customisable, and provided their own “platform” facilities which meant internal developer teams could leverage their common data and software services to solve workflow problems for their users. Indeed, we heard from one site that their in-house developer team had to increase in size after the procurement of these products, highlighting the need for integration and customisation.

5. The active patient

The next part of the journey was an increasing awareness of how we were missing the patient in our work! Patients must not only have access to their records but also contribute. So in 2015, I released an iPad application, based on Apple’s ResearchKit framework, that my colleagues trialled in the Parkinson’s clinic. I am not aware of any other ResearchKit-based software deployed in the UK before this work:

The key was to ensure that the information was made available immediately for use in clinical care, but notice how the system can also ask the patient whether they are interested in research. In 2018, we successfully obtained ethical approval for a similar iPad application to be used to record consent, and so I can dynamically build consent forms in a web-based administrative interface and push it out to our iPads.

6. Strategy and complex adaptive systems

But I realised that this work, in isolation, could not have the impact that I wanted it to have.

I started to understand that I should try to spend more time influencing national and local information technology programmes within health and care in Wales, and start to advocate for a more modern approach to technology, trying to influence governance, team structures, architecture and encourage the adoption of open standards.

I started talking to people with experience from other public sector and commercial digital initiatives, such as GDS, and learned more about user needs, the value chain and the importance of delivery with the agile approach of fast-feedback resonating with my own experience of building a minimal viable product and getting early valuable feedback and iterating; after all, it was the only way I had been able to work for all of those years!

I presented at the inaugural Welsh digital health and care conference and pitched an approach based on user needs and an open technology platform made up of modular software and data services.

This is from the Informed Health and Care strategy:

This strategy is useful as a framework, useful to understand needs, but not something to define governance or architecture, because it is self-evident that some core architectural building blocks are useful across multiple workstreams.

The idea of an open platform, in which there is separation of the data and the applications that process those data, is not new. Indeed, we know health and care data will outlast the applications that operate upon them; applications are increasingly ephemeral and very easy to create if the hard work is performed by services within the platform itself.

You almost certainly access your email using a variety of applications; web-based, multiple mobile applications and applications running on desktop computers - normally whatever suits your current context - your workflow might be that you respond with short replies using your mobile application but perhaps write longer messages on your desktop. The key is that you are viewing the same data through different prisms.

There is danger in designing software through an application-centric perspective, because you make it much too easy to make the wrong design and architectural decisions and that builds technical debt.

This is what such a platform approach might look in NHS Wales:

For example, we’ve been discussing how the real-time analytics / data pipeline might be implemented via Apache Kafka or similar pub/sub streaming pathway, while more interactive applications principally use FHIR APIs to interact with software and data services built into the platform.

So that means that we can start to build partnerships and collaborations, not only within health and care services but with partners across academia, the third-sector and commercial entities; partners may provide some of the architectural building blocks for us, but such an approach, predicated upon the adoption of open technical standards, will allow us to build a thriving ecosystem, test innovation and scale solutions when proven, but taking steps to continuously evaluate and improve at a system-level.

We move from this:

to this:

We simply do not need multiple portals but we must recognise that we have a complex suite of different software products in different organisations - rather than top-down diktat, we need a convergence strategy that means that working systems across Wales can incrementally adopt nationally provided modular building blocks of functionality and yet still also be able to access the meaningful structured data that sits behind any modular user interface component if needed to solve user problems.

Such an approach is simply good software engineering practice. The NHS Wales “WCP” product has “logging” built into the application so that all access to patient records is logged by the application itself. This should always have been something at the API level; we have too much business logic within this application and that simply makes ongoing work more difficult.

The benefit of APIs is that they are an abstraction. I don’t need to know how my car works; my interactions with my car are to use a key, steering-wheel and pedals. It’s the same in software - and that means we can provide a simple-to-use open standards-based “platform” of different APIs that hide the underlying complexity of our wider enterprise.

Vendors such as Cerner and Epic recognise the benefit of a platform approach: they each provide a set of FHIR APIs that mean that third-party applications can interact with the software and data services provided.

We have three options in Wales: the status quo, the purchase of a megasuite EPR or the development of our own “platform” using a lot of the good work already done within Wales, but simply not (yet) exposed as first-class API products.

Here’s how it could look for us:

Becoming data-driven - building capabilities

In essence, our health and care services must become data-driven. Data are an essential ingredient of a prudent health and care service.

But data aren’t only valuable in supporting our health and care services. We should be looking to use data to support our work in improving our software design, development, testing and deployment lifecycle, and we need to look at how the highest performing software teams develop safe and effective software in the modern age.

That doesn’t only mean real-time dashboards of performance metrics, of live service status updates and numbers of mouse clicks for a specific process, but changing the way we design and build software systems in a much more agile and responsive way - with fast-feedback and continuous improvement.

I was fortunate to work with Lee Waters and others on the “System Reboot” report for Welsh Government, which identified some of the capabilities we need to develop across the public sector - and we need to work hard to share experiences and look at what platform components might be shared - much like the Gov.uk Notify service permits organisations to send notifications to users via email or SMS.

For example, my approach to SNOMED CT was to deliver the software and get fast-feedback on its utility and functionality and improve, building in processes to ensure clinical safety at the outset. I saw instead national programmes looking to get consultancy and spending time planning instead of getting real-life feedback to shape progress. Fundamentally, we need to move away from thinking we can do waterfall planning and procurement for healthcare technology.

The importance of expertise in data and software

Finally, we need to recognise that we cannot outsource data and software expertise, because we are still at the “beginning of the digital revolution” - this is what Bill Gates said in 2017!

Digital technology offers us the tools to transform our health and care services and design a more seamless, prudent, and continuously improving system for citizens.

We need to

• be focused on solving problems
• encourage fast-feedback, for health and care services and the software that supports those services
• become data-driven
• build partnerships and foster collaboration
• be open, transparent and honest about our successes and our failures;
• adopt open standards and encourage interoperability
• adopt approaches from outside of health and care
• inculcate an inquisitive, searching and curious learning culture.

Thank you,

Mark Wardle

Further reading

On health technology and digital transformation

• Digital transformation
• A manifesto for digital health in Wales

On “Once for Wales”

• Once for Wales : a debate

On trust and innovation

• The paradox of ambition
• The paradox of control
• The 5 Os of healthcare IT - objectives, ownership, openness, optimise, organic

On platforms:

• An open platform for Wales

• Data-driven healthcare

• Platforms 1/3. Standards and interoperability
• Platforms 2/3. An API-first approach
• Platforms 3/3. What we need to do next

On focus:

• Focus 1/3. The importance of strategy : focus
• Focus 2/3. The challenges we face in delivering the vision
• Focus 3/3. Pragmatic solutions to those challenges

On data:

• Health data - start with a problem
• Data-driven healthcare

On development standards and ecosystems

• Creative 1/3: creative destruction in health IT
• Creative 2/3: the value of software for healthcare: quality improvement and service transformation underpinned by software, and software underpinning by quality improvement
• Creative 3/3: ecosystems and the platform