Why we are withdrawing the NHS Common User Interface | Hacker News Reader

Why we are withdrawing the NHS Common User Interface

digital.nhs.uk

77 pointsDanBC27 comments

I've responded to their email address about what would come next - in short I think they should publish high level requirements and principles that should be met by each platform. Rather than trying to create everything first party, they should allow a mechanism for taking on board permissively licensed assets (or pull requests to their requirements and principles) as effectively donations.

The NHS has a lot of good will in the UK and they would be an ideal, if not THE ideal, co-ordinators of an open source health programme. Creating a unified look and feel for web services would be a good proof of concept, but I believe this could be extended to other libraries, components or even full systems/solutions in time.

What exactly do you mean? Have you seen the new service manual? They welcome contributions from outside NHS Digital, anyone can contribute to it in theory, so long as you can show there's a real need [1].

The NHS are doing more in-house, where it's sensible. For example the NHS Business Service Authority are building a replacement for https://www.jobs.nhs.uk whereas before it was basically entirely out sourced to the private sector.

[0] https://beta.nhs.uk/service-manual/ [1] https://github.com/nhsuk/nhsuk-service-manual-backlog/blob/m...

Is this not what is being withdrawn?

But still, just going by the link you have a list of principles:

https://beta.nhs.uk/service-manual/design-principles

Which are all well and good, but are more akin to a 'vision' than technical design principles (especially with regard to preference of tradeoffs, data management, priority of platforms etc).

The rest of it seems to be strongly geared towards the web. It may well be that the NHS only wants to collaborate on public-facing web services, much like GOV.UK and the Government Digital Service, but this would need to be either extended or abstracted to be applicable to, say, administrative systems.

> Is this not what is being withdrawn?

What's being withdrawn is their original CUI, linked in the article [0]. From what I can tell, this is very distinct from their new digital service manual, which seems to be replacing the old CUI.

> ...but this would need to be either extended or abstracted to be applicable to, say, administrative systems.

Based on nothing more than a rough skim of the CUI, admittedly, it seems like the original was a very web/interface-oriented design system in the first place. A focus on web components makes sense, since administrative systems can be implemented with a web-based frontend, and web design systems can be adapted to other user interfaces, because they provide a set of baseline, expected behaviours to replicate.

[0]: https://webarchive.nationalarchives.gov.uk/20160921140920/ht...

I spent quite a bit of time implementing the medicines management parts of this for a product that I don't think ever shipped (I, and the majority of the dev team left at around the same time due to concerns around management direction). I definitely thought that side of things seemed well thought out, and there was a lot of value in having consistent display of medication details and dosing across systems to try to make it as clear as possible for the users.

I can't tell you how bad UI design is in existing EMRs.

Last night I spent 15 minutes trying to get FirstNet (a Cerner system) to accept a medication order so I could discharge a patient.

The problem? Inconsistent UI.

  - Firstly, the patient had incorrectly had a medication allergy to codeine recorded; and I was trying to prescribe a medication containing codeine. The patient had had nausea and vomiting in response to previous morphine administration, which is a drug side effect (Mild), not a drug allergy. So this was the information I was trying to encode.
  - So, I removed the codeine drug allergy.
  - But then, because there were no allergies recorded, it wouldn't let me prescribe a drug unless the drug allegies had been reviewed.
  - So I entered the allergy recording section; which has a UI which is not only totally inconsistent with the hodge-podge of the rest of the application, but *inconsistent within itself*
  -

This is the screen for adding a drug allergy. https://ibb.co/Y7gs85h Guess what bit I have to fill out first?

Hint: It is not what you think.

I must fill out the right side of the screen first, because as soon as I either double-click on Morphine on the left hand side, or Hit the 'select' button left-of-middle, it considers that I have completed the details I need to enter, and closes out of this screen. So the 1. at the top is a lie!

So, now I am trying to start by completing the right side of the screen, from 2 down. https://ibb.co/kcgYJw2

  - Note that I have changed the reaction type in 2. from 'Allergy' to 'Side effect'.
  - Now I have to select the side effect; in the search pane on the left.
  - It's vomiting, so I select it once. I can now double click on Vomiting! Horray!
  -

So, now to fill out the remaining details. Be careful not to click ahead, or it will close out; forcing you to have to restart the process all over again.

Now, I have 2 more steps to complete. I need to confirm that this is the correct set of allergies and I have reviewed it. https://ibb.co/nM1fXtB

  - In a UI change, I now need to click the green tick in the top left to proceed.

I can't even bear the pain of going through the last step because once I had navigated all of the above, a final UX change on the page where I need to over-rule the Clinical Decision Support Dialogue that is trying to warn me that because there is a side-effect to Morphine and I am prescribing Codeine, would I like to proceed. A somewhat useful notice, as they are the same class; but really frustrating and since I had just coded it as a mild side-effect, not a severe allergy, I would hope that an intelligent CDSS would recognise this and stop giving me alert fatigue.

In my state of fatigue (14 hour shift after a 10 hour shift the day before), I inadvertently clicked the wrong UI elements and had to repeat the process so many times that I actually started documenting it because it was so fucking ridiculous. I was trying to use the system as it was intended; To actually record accurate information that would be of benefit in future patient encounters. The system actively worked against me achieving this aim.

EMR Designers should be first against the wall when the revolution comes.

To bring this a bit more back on topic, it would be lovely if there were consistent UI standards. But the horse has bolted so far. I can't see how we are going to get human centred design on more than a fraction of deployed EMRs at any point within the next 15 years; the infrastructure and licensing deals that have been done are too established and the inertia too slow.

The NHS actually does have an eMR that it has built itself - Leeds - https://www.digitalhealth.net/2018/01/leeds-teaching-hospita... Apparently it is pretty good (relatively speaking!)

> EMR Designers should be first against the wall when the revolution comes.

It's just so mind-boggling how this shit doesn't lead to more people dying. I swear, the more critical the thing, the shittier the UI.

>It's just so mind-boggling how this shit doesn't lead to more people dying.

Medical errors do cause a lot of deaths: https://www.npr.org/sections/health-shots/2016/05/03/4766361...

I don't know if any significant portion of that is linked to bad UI design in EMR software, but it wouldn't surprise me.

See https://khn.org/news/death-by-a-thousand-clicks/ for examples

>the more critical the thing, the shittier the UI

In my experience the more critical the thing, the larger the committee that is formed to "perfect" it or provide feedback that is then acted on to the letter.

I'm never sure if it's to spread the perceived liability for not getting it right across a larger number of people, or truly well-intentioned, but having been part of healthcare for 20 years (not EMRs) I can attest to the design-by-committee failures I've seen when anything clinical is involved.

Tangentially related to UI - reading those pre-formatted lists is incredibly difficult on mobile.

sure is. sorry, tried to make the best of a bad situation, alternative is weirdly spaced text

  It is fairly easy to guess at a small
  width that will work for most users,
  and manually wrap at it.
  That won’t work for all users, but
  should be an improvement for most on
  mobile.

At least it lets you list your favourite drugs, i should imagine you need plenty of those working with this nightmare.

Ha I accidentally clicked that and it destroyed all my entered information; I haven't used it properly yet, but it is of low utility as it currently stands!

This is really great. Please post more of these.

Do you have a blog? Or Twitter?

Thank you :) I’m not twitter active but am heading towards a blog, need to collect some more examples first!

I've worked on a system on the polar opposite end of the spectrum with electronic patient charts. The Doctors we worked with wanted to use one note as paper, they didn't want anything remotely like data entry, no form fields tables or anything, they just wanted to move their paper based system onto a digital canvas. There were so many opportunities for something like "Jupyter for patient charts" that went begging.

If I were making this decision, or the decision about what should come next, I would be trying to create quantative evidence about what works and doesn't work to inform the choice. I didn't see that in the article.

I wouldn't. That kind of user testing is extremely time consuming, and often pointless because it's obvious what works and what doesn't.

Google famously did silly amounts of AB testing on button colours and whatnot, but material design is much better than any of that achieved and that was just fine by getting some good graphic designers and thinking about it.

Material design sucks - it's like Communism - (not saying you do this) as soon as someone points out flaws in it, the argument is "that's not real material design" !

Typically known as the "no true Scotsman" fallacy.

But material design is garbage?

I think you're probably in the minority.

That kind of stuff would be in the digital service manual.

https://beta.nhs.uk/service-manual/

Design Principle Six says:

> Test your assumptions

> Design and test your work with real people. Observe behaviour and gather evidence. Work with subject experts and existing research. Do not rely on hunches.

The section on accessibility has this: https://beta.nhs.uk/service-manual/accessibility/user-resear...

People may also be interested in this:

"Researchers and innovators requiring access to data to help solve complex health and care challenges are invited to apply to participate in Health Data Research UK’s Sandbox."

https://www.hdruk.ac.uk/news/call-for-applications-to-test-3...

TLDR version: “it’s making it too hard to privatise services”

Reply on news.ycombinator.com