Category: Uncategorized

What is working in the open?

Working in the open means showing people the work you are doing, as you’re doing it. At a minimum this should be people within your team and people across your organisation. Even better is sharing publicly, with stakeholders outside your organisation who have an interest.

Working in the open is not just about demonstrating progress, but also talking openly about mistakes, changes, and things you’ve learned. It’s partly to support communications, to help you build a movement for change. But it’s also about good governance. It gives stakeholders a window onto your work that drives up quality, helps unblock, and manages your dependencies. Work in the open by being open about the work.

Typical examples of working in the open are as follows.

Hosting ‘show-and-tell’ sessions. A show-and-tell is a regular (every 2 weeks, say) open invite event. The team does a short presentation about recent progress, and allows time for questions at the end. Importantly the team does not simply give a status update but “shows the thing”. Such as prototypes, designs, research, or other lightbulb moments.

Publishing regular updates on the team’s progress. For instance by writing and publishing weeknotes. Or writing regular posts about more specific things as they learn them. This could be a set of insights from user research sessions. Or the logic behind making a particular choice about a technology.

• NHS trust digital leaders Amy Freeman and Andy Callow both publish weeknotes.

• NHS Digital hosts a series of blogs on transformation, technology, and design.

• The Defra Future Farming programme blog.

Publishing code and documentation as open source. When a digital team is developing a digital service or piece of software they should code in the open wherever possible. Publishing code in public repositories helps teams focus on the quality of their code and documentation. It allows others to build or copy the work that has been done.

• GCHQ’s internal Boiling Frogs research paper on software development and organisational change. If GCHQ can work in the open, anyone can.

• NHS design and prototyping kit code repository.

• The Government Digital Services’s code repositories.

Using workplace messaging tools. This is one of the simplest things you can do to help your teams work in the open more. Posting information in a ‘chatroom’ rather than sending an email switches the default visibility of a message from closed (only the people copied get it) to open (everyone in the channel or room gets it). This helps all the team know what’s going on, and allows the team to discuss important topics together. It also allows discussion to happen asynchronously without the need for a meeting.

Richard Pope has published a brilliant thread on twitter of some of the things teams publish in the name of working in the open & transparency.

How does working in the open help

Traditional methods of project communication typically follow these patterns:

• Broadcast. The communications are one-way.

• Hierarchical. Only the most senior people are allowed to represent the project.

• Tightly controlled. Everything has to be cleared by a separate comms team.

• PR-oriented. The objective is to spin what you’re doing to show it in the best possible light.

• Big bang. One big press release when the work is ‘finished’.

These types of communications are often impersonal, inauthentic, and frankly boring.

Working in the open is typically low cost and has a number of advantages.

It supports better project communications because:

It builds momentum. Digital transformation is not only about technology. It’s also about changing culture, process and operating models. You won’t be able to do this in a silo. By working in the open, you can develop your narrative and bring people with you. It helps create momentum for change. Sharing what you’re doing little and often increases the chances people will engage, reaching wider audiences.

It’s 2-way. It allows your audience to interact and converse with you. It opens up a channel for you to receive feedback.

It is timely and relevant. Avoiding long comms clearance processes enables your communications to happen when the work does. This helps build momentum and keeps you on the radar of key stakeholders: decision makers or funders. Decision makers don’t like surprises.

It has more authenticity. Working in the open allows you to talk in the voice of the people who best understand the project. Helping people understand why you’ve made the decisions you have builds trust. Like your maths teacher used to say, show your working out.

It supports better project governance because:

It makes the service better. More eyes and earlier eyes on the service, product or project means it will get improved, more quickly and at lower cost/risk.

It is a window onto your world. It allows stakeholders a much clearer understanding of what the hell is going on than a Red/Amber/Green status report in 8pt Arial on a slide.

It manages dependencies. Legacy organisations tend to try and manage dependencies in large spreadsheets. This may allow one person (the owner of the spreadsheet) to understand dependencies. But this isn’t enough. Working in the open allows everyone to see what’s in flight, and identify and manage dependencies for themselves.

It helps you manage and persist knowledge. It enables you to build an open store of understanding and insight over time about how and why things have been done. This makes it easier for others to copy or pick up where you left off. It allows others to link to what you are doing and explain.

It supports capability building because:

It helps you hire. Digital professionals like to be able to work in the open. If your organisation can show that it works this way, you will attract more of the people you need. “I asked members of the audience to raise their hand if they wanted to work at GDS after reading one of its blog posts. 75 per cent of people put their hand up.”

It is democratic. Everyone on the team is empowered to showcase their expertise about what they’re doing and why. This builds confidence in communications skills. It helps everyone feel like they are contributing.

If you want to build trust, confidence, and learning, we suggest you work in the open.

Further guides

More advice on agile communications from Giles Turnbull.

More advice on weeknotes from Giles and Ben.

More advice on running great show and tells.

More advice on doing presentations.

More advice on coding in the open.

This post was originally published on the Public Digital website on 21 January 2022.

The Department of Health and Social Care announced yesterday that NHS Digital and NHSX will be folded into NHS England. We have seen these kinds of reorganisations many times before, including in the NHS. All too often they are distracting, dispiriting and don’t deliver the intended benefits.

But that doesn’t have to be the case – providing you get off on the right foot. The reorganisation is not the story. What you do afterwards is.

We don’t know all the internal mechanics of the NHS. But based on what we do know, here are our suggestions for using this transition to build trust and continue the momentum gained during the pandemic.

1. Work in the open by default. Start by publishing the names of who’s in charge, and what they’re responsible for.

2. Make an unambiguous, technically literate statement explaining what this means for patient data.

3. Deploy expert multidisciplinary teams (design, technology, clinical, operations) at all levels of decision making and delivery. Make the most of NHS Digital’s specialist capability in design and technology.

4. Explain which platforms are needed across the NHS, based on a thorough look at what exists now.

5. Show how this organisation change is meaningful by delivering something quick, visible and helpful to the system as a truly joint team. Such as an MVP platform for ICS websites, or new clinical calculation APIs, by next April.

6. Use the practice of working in the open to manage dependencies and duplication, instead of relying on spreadsheets held by Programme Management Offices. Get senior leaders to publish weeknotes.

7. Fix corporate basics to reduce friction for staff: make the website clear, put everyone on the same email system and directory, modernise the most important internal tools.

8. Do less so you can deliver more. Use the change to stop doing what is no longer needed or isn’t delivering value.

Most important of all – don’t let this distract from the core mission of making the NHS better for everyone. We need it, especially this winter.

This post was originally published on the Public Digital website on 23 November 2022.

On 26 November NHSE/I published a paper on its plans for moving forward with Integrated Care Systems in England. Integrating Care: Next steps to building strong and effective integrated care systems across England.

For the uninitiated, this is the policy response to a challenge teams are navigating up and down the country. Some responsibilities for health and care fall to the NHS, and some things are done by local councils. This can create a mess of misaligned incentives, duplication, and fragmentation. Enter the Integrated Care System (or ICS for short) to help straighten things out.

“In an integrated care system, NHS organisations, in partnership with local councils and others, take collective responsibility for managing resources, delivering NHS care, and improving the health of the population they serve.” NHSE/I.

NHSE’s proposal aims to formalise the model, putting the ICS reforms on a statutory footing and give them responsibility for planning and buying services. This is an oversimplification, but the move would seemingly repeal aspects of the Health & Social Care Act 2012. For further reading NHS Providers has released a helpful primer.

What the paper says about digital

There are quite a few references to digital in the NHSE/I 40-pager. I’ve extracted them to save you a job.

Starting from the off, there’s a clear strategic intent to put digital & data at the heart of the change. It’s one of a handful of key themes.

“…we will need to devolve more functions and resources from national and regional levels to local systems, to develop effective models for joined-up working at “place”, ensure we are taking advantage of the transformative potential of digital and data, and to embed a central role for providers collaborating across bigger footprints for better and more efficient outcomes. The aim is a progressively deepening relationship between the NHS and local authorities, including on health improvement and wellbeing.”

In addition to this broad strategic intent there are more specific points on digital that are set out as follows:

• ICS’s will have an SRO for digital on their boards.
• ICS’s will need a digital transformation plan.
• There is a responsibility to build digital and data literacy of the whole workforce “as well as specific digital skills such as user research and service design”. And can we just pause for a round of applause for whichever official managed to squeeze that latter clause in. 👏
• Introduce shared contracts and platforms including shared EPRs.
• Develop or join a shared care record joining data safely across all health.
• Build the tools to allow collaborative working and frictionless movement of staff across organisational boundaries, including shared booking and referral management, task sharing, radiology reporting and pathology networks.
• Follow nationally defined standards for digital and data to enable integration and interoperability.
• Use digital to transform care pathways.
• Develop shared cross-system intelligence and analytical functions.
• Ensure transparency of information about interventions and the outcomes they produce.
• Develop a roadmap for citizen-centred digital channels. NB Not sure why this would be different to the digital transformation plan referenced above, but nevermind.
• Roll out remote monitoring to allow citizens to stay safe at home for longer.

What does that mean for local digital capability?

So far so lofty. But what does the team look like that has to be put in place to deliver all of this?

The challenge of doing cross-institution service design in health and care has long been a bugbear of mine and many others. How can you possibly design great services across such a fragmented system? The NHS must be the largest manifestation of Conway’s Law on the planet. So on the face of it I think this reform is A Good Thing. But it will only solve the digital mess if there is also investment in capability at the ICS level to be able to deliver it. The types of people you need to deliver all of the above amounts to really rather a lot of specialist skills. And there are, assuming the website is up to date, 21 ICS’s currently.

Individual trusts, councils, and others will also have their own digital and technology teams. Institutional fiefdoms will still need to be managed, so how to ensure all the relevant organisations have skin in the game and that the whole is greater than the sum of its parts? This will all also need to be executed in the context of national agencies delivering platforms, framework agreements, and inevitable ministerial pet projects.

What should an ICS Digital Team look like?

I guess a lot of this will need working out and no doubt people are on the case as we speak. But my starting points for an ICS digital transformation team would be the following:

• Multidisciplinary: it would contain designers (service, interaction, content); transformation experts; product and delivery people, user research; interoperability gurus; data scientists; IG experts (the ones that enable not block); and experts in the management of commercial IT contracts. It would also definitely have some technical architects (not armchair architects, ones that can still write code) and developers.
• Empowered, within some well understood and enforced guardrails delivery teams need to have clarity of purpose but freedom to act. There needs to be an agreed patch for sensible service design, and this feels most achievable at the ICS level. Teams should be autonomous to work within that. But there should also be some rules around what gets built or bought, based on the NHS design standard and use of common NHS platforms.
• Networked: the teams across the country should all be talking to each other. One of the most brilliant but little-talked-about innovations of the central government digital transformation movement was the cross-government Slack instance. All digital professions in the civil service across the country could instantaneously reach tens of thousands of other experts. A question like “does anyone have experience of translating services into Welsh” would attract multiple offers of help within seconds. Building on the curated communities that already exist like Digital Health Networks need to be turbocharged.

That’s my view at least. I am sure others will have alternatives and I’d really love to hear them.

First published on Medium on 10 December 2020.

There is a wide and occasionally bewildering array of software used by patients and clinicians in the NHS. This is a short, introductory reference guide to illustrate the range. It is by no means comprehensive so any critique or additions are well received. I hope it’s useful to some.

Clinical system: If you are new to healthcare, one of the immediate things you encounter is the primacy of the clinician and the concept of clinical safety. A clinician is someone with a medical qualification who treats people i.e. a doctor, nurse, paramedic, dentist, pharmacist, or midwife. ‘Clinical system’ is a broad term that is used to refer to the software that supports clinical activity i.e. the act of treating patients in a healthcare setting. When software is considered to be clinical it means it is subject to legislation such as clinical safety standards (as defined under the Health and Social Care Act 2012) or the Medical Device Regulations. This means clinical systems must be able to evidence their safety through testing and by explaining their approach to clinical risk management.

Clinical systems are the bread and butter of healthcare and this is where most of the health IT money goes. They can range from specific standalone systems for a specific purpose like a Radiology Information System/Picture Archiving and Communication System, to care pathway-specific dealing with, say, cancer. A care provider chooses these based on its needs then often integrates them into a core enterprise system, more on which below. There could be over 100 in a given hospital.

Patient administration system (PAS): used in hospitals, this describes the software that manages administration of patient interactions. This includes things like: the hospital’s patient index with patient demographic details, appointment booking functionality, checking patients in and out, scheduling and workflow type stuff, referral management, payments. Notably, PAS’s are distinct from being clinical i.e. they do not typically store or process clinical information about patients. Pretty much every care setting has something akin to a PAS, it’s just that the term is synonymous with hospitals. Because of the way PAS’s in acute settings have evolved to meet very specific NHS-y needs such as national data returns or payment processing, it makes it a niche market with higher barriers to entry.

Electronic Patient Record (EPR): self-explanatory in some respects, as this refers to the digital manifestation of the patient’s healthcare record. EPRs are everywhere, although the term itself is most closely associated with hospitals. This is mainly because in hospitals there is a historic distinction between the care record and the PAS, and because other care settings have EPRs that are already called other things. These days EPR systems often do heavy lifting for both the patient record and various jobs previously undertaken by the PAS, as part of the trend to enterprise approach. EPRs can also go by the name EHR, or EMR. Some of the well known names in the UK are Cerner and Epic. It is apparently not cheap to install an EPR. Leeds Teaching Hospitals built their own, starting in 2003. Many sensible people on all sides of the political divide think that the patient data layer should be separated from the enterprise applications, and more who suggest it should be nationally owned. This is not going to be easy.

GP IT Systems: these are the main software systems used by GPs, and are really an EPR for the GP setting. They have a whole range of features from appointment booking and management, prescription management, to generation of letters and storage of data. Crucially, they store your GP medical record, allowing GPs to code entries and enter free text information regarding your consultations, conditions or medications. The GP record is particularly important in NHS terms because the way the NHS is structured means it is de facto the main record for your healthcare. It stores correspondence between your GP and hospital or other provider. The systems also automatically pump data to NHS Digital for aggregate, statistical use. There are 4 GP system suppliers in England which are TPP, EMIS, Vision and Microtest.

Clinical decision support system: commonly abbreviated to CDSS, this is a tool that is often embedded as a feature within types of clinical systems. It typically forms a series of questions that can be asked of a patient in order to help a healthcare professional (either clinically trained or not) assess the patient’s condition. You can see a CDSS in action on 111.nhs.uk in which patients themselves access the NHS Pathways CDSS. Pathways’ underlying clinical information makes a risk assessment based on the combination of answers provided. It’s essentially a corpus of medical knowledge with the “one thing per page” design principle applied. CDSS’s can be either for diagnostics or triage. Diagnostics is where the tool is actively trying to suggest possible illnesses whereas triage simply assigns a level of risk to direct a patient to the appropriate clinician or care setting. The former is governed by stricter regulations, but this is a bit of a false distinction in my view as a triage system is still making some guess at what the problem might be, in order to assign a risk score. As well as online, CDSS is used by phone operators e.g. on 111, or at the front door of emergency departments. Very specific CDSS can also exist to support clinicians in highly specialist settings e.g. to help doctors select the right chemo dosage in cancer treatment.

Online consultation systems: these are relatively new on the scene, and are systems in primary care to enable GP-patient interaction to happen remotely. They comprise a number of features that support this. Online consultation is often conflated with video consultation. While the former does encompass video consultation, the terms are not wholly interchangeable because online consultation also encompasses things like form-based triage (i.e. the patient fills in a questionnaire about their symptoms and this is sent to the practice); 2-way messaging between the practice and patient; and symptom checking using a CDSS. Examples are eConsult, Ask my GP, Engage Consult.

Personal healthcare record (PHR): PHR is an umbrella term for a digital healthcare record that is owned and administered by the patient themselves. It’s not clear to me yet how much this term is understood beyond a core group of wonkish types like me who work in digital healthcare delivery and policy. A PHR may combine clinical information from various sources, but crucially they also allow the patient to submit information themselves either through manual data entry or via wearables. NHS Digital maintain a working definition of a PHR on their website. Some examples are Tiny Medical Apps, Patient Knows Best or Apple Health.

Computer Aided Dispatch (CAD): This is the system that supports 999 control centres in the management of telephone calls into the service and the coordination of staff and vehicles in support of the calls. It also supports CDSS modules to help triage calls. Ambulance services will also often have a separate EPR for their patients. As the urgent and emergency care sector evolved as its own sector through the advent of the 111 service, so too did the case management tooling. So now equivalent products are available in 111 to queue and manage calls, undertake referrals, update records and perform triage. And some are used across both 999 and 111. In NHSD we have broadly referred to these as Encounter Management Systems but this is not a widely used term. Examples are Cleric, Adastra.

Internet pharmacies: also known as ‘distance selling’ pharmacies in commissioner language. These are pharmacy services that fulfil prescriptions by delivering them to your house as opposed to requiring you to go to the pharmacist. They tend to have web or native apps that enable you to manage prescriptions accordingly. Examples are Echo, Pharmacy2U.

Patient portals: as much as it pains me to write this heading, this is nonetheless still a term that is oft used in the NHS. It refers to any application either browser-based progressive web app or native app that enables a patient to interact with an underlying clinical system. Usually this is so the patient can see their records, book and manage appointments, and manage their medication. There are a ton of these for both primary and secondary care.

Wellbeing: there is a massive market for wellbeing apps which support everything from diet, mental wellbeing, sleep. For a browse of some examples it’s worth a look at the NHS Apps library. I’ve not really given them the full treatment here because I know little about them and they aren’t typically transactional in the same way the other examples are.

Having set all of this out, a few thoughts on healthcare products.

• The boundaries around the different types of products are very fuzzy. e.g you will get PHRs that have some features of online consultation tools; or EPRs that do the work of a PAS. This sometimes makes it hard to know what to buy, and exacerbates the challenge of ensuring interoperability between systems. i.e. it’s a bit confused, in a similar manner to the organisation of our health institutions as I have blogged before.
• Somewhat unlike central government departments (in my experience at least) the NHS and its staff are entirely comfortable with the concept of ‘services’. The clue is in the name I suppose. But there is very little discussion of services in the context of digital delivery, except at the national level with things like PDS and e-RS. You rarely hear the term ‘product’ compared to say ‘system’ or ‘tool’, and the closest you get to service is probably ‘digital care pathway’ which is kind of getting there but can miss the real fundamentals.
• This proliferation of product types means there are lots of places that patient data can be held, hence the massive focus on interoperability in the NHS, and the importance of point 6 in the Future of Healthcare.

Hopefully this is helpful to digital healthcare workers new and existing. As above, I welcome any additions or comments.

The views expressed here are all mine and not those of my employer. Thanks to Kate Gill for her fact checking and examples.

Originally published on Medium on 1 May 2020.

The prevalence of duplication, dependencies, and contradiction is not unusual in large, complex bureaucracies trying to undertake digital transformation. But, to me at least, it does feel particularly noticeable in healthcare. A behemoth of a system with approx 1.7m employees this is understandable but makes it even more urgent a problem to solve.

The Secretary of State at DHSC obviously thinks this challenge needs more drastic measures. The announcement of NHSX has made clear it is going to try and tackle the strategy challenge head on.

I’m particularly fascinated to see the organisational structure they bring to bear. In the past I’m not sure those of us in the relevant delivery agencies have always helped ourselves untangling the complexity challenge; and I’ve started to think that there is something around our organisational design tendencies that is holding us back.

When I started working in digital roles one of the first things I was taught about by a valued mentor was “Conway’s Law”. This is well known in digital circles but for the uninitiated, Conway’s Law states that:

“organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”

This was introduced to me during the development of a departmental intranet, where the content was organised by the various departments of the organisation in question, rather than say, something more useful like being organised around the tasks users wanted to complete.

In the world of digital, what Conway’s Law is saying is that if your organisational structure and approach to software development (which should de facto based on user needs) are not in alignment, expect problems.

In digital health, whether working at a national, local agency level or within a supplier market, there appears to be a number of different ways organisations, well… organise themselves and their departments and functions. They might:

1. Organise by the user. Is it a clinician using a particular technology, or the patient? Or a commissioner or provider? For example: empower the person; or enable clinicians.
2. Organise by the care setting. Primary care, acute care, or my own area urgent and emergency care? Or it could be around disciplines e.g. nursing, dental, or pharmacy.
3. Organise by function or capability. Enable users to undertake booking, get prescriptions, or access care records.
4. Organise by the care pathway or user journey. For example “maternity” or “cancer”.

There are probably more, and a fifth category specific to the NHS of ‘interoperability’, i.e. working on the plumbing between systems, merits an honourable mention as sometimes it’s on its own, and sometimes it’s within other buckets.

All of these are logical ways of slicing up the problems to be solved. But the problem is that we can often use all of these taxonomies all at the same time.

This then often means that perfectly skilled teams of well meaning people in each group set out to try to meet needs (sometimes user, sometimes business) in their area in a way which will then inevitably span all of the other categories.

So you might get, for example, primary care people trying to create patient facing services, and patient facing services teams trying to tackle primary care. Or urgent care people spinning up analytical teams to get the data they need, while the data infrastructure teams cast around for customers. The natural tendencies of “not invented here syndrome” and an understandable desire to reduce dependencies on other parts of the system can often make things worse. In such a mind bogglingly complex system it can often be more accident than design when these things link up.

This is further exacerbated by two other factors. First, the central agencies overall probably play quite a small role in actually delivering ‘stuff’ compared to organisations on the ground, which means the same contradictions may play out at Trust, Clinical Commissioning Group, or Integrated Care System level as well as across the national agencies.Second, there is the challenge that end-to-end user journeys will touch many settings and functions, and implicitly different provider organisations, rendering proper service design pretty challenging.

I’m not sure what the answer is, and I have no envy at all of the talented folks who have wrestled with this in the past and are probably doing so now. Maybe the response is a combination of the above: something like a top tasks strategy with a mix of user journey/care pathway teams, and capability teams. But if nothing else it underlines the need to go the extra mile to set a crystal clear strategy, including how markets should be managed, and the combination of ruthless spend control, and serious capability building. Sounds like a plan.

Originally published on 16 May 2019 on Medium.