Patient details header

[devansXD]

What

Patient header; a proposed addition to compliment the header component. This proposal is to create a version containing patient information for admin and GP users.

Contains briefly:

• Link to help site (also being redesigned)
• Link to system alerts
• Drop down menu displaying logged in clinician information
• a. Clinician's role
• b. Clinician organisation
• c. Preference
• d. Option to log off (may need changing to sign out)

Once logged in, patient details appear below the main header bar containing:

• Referral number
• Patient name with drop down containing patient record details and NHS number
• Gender
• Age

Example

Why

Current implementation on e-Referral service contains usability and accessibility flaws, as fed back through user research, and also when comparing to WCAG 2.1 color contrast ratios. Readability is key to understanding the correct patient details are being surfaced and to match this with patient referrals. Summary Care Record also require this component for their own service.

Research

We have tested this component with a number of clinical professionals in medical care settings. Feedback is very positive, and task completion for retrieving the information in the header is high. I have also used primary colours from the NHS service manual for accessibility: https://service-manual.nhs.uk/design-system/styles/colour

I'll be attaching the previous research to this when I have it.

Anything else

DWP are working on a key details bar which is a common component in case working systems https://github.com/dwp/design-examples/issues/7

[simon-davis-nhs]

Research update: This component was tested with a mix of clinical and admin professional users. This was split across both primary and secondary care settings. Research was conducted both face to face and via remote moderated usability sessions. Feedback was very positive and users were correctly able to identify what each part of the header would do. Users described it as providing clarity and being a familiar pattern. Users correctly identified that clicking the patient's name in the header would display more information about the patient, for example, address and contact details.

[davidhunter08]

Cheers @devansXD. Do you know of any other services that use a 'Patient details header'?

[devansXD]

@davidhunter08 this is Summary Care Record http://scra-redesign.herokuapp.com/

I'll ping you the details

[devansXD]

I think NHS login were also looking at an area in the header to store / display info once logged in.

[devansXD]

A further example from Alison Warren at Gloucestershire Hospitals Trust https://xd.adobe.com/view/741cd8ef-175c-4a96-5793-b9741b2c8017-022d/?fullscreen

[danjohnstonUX]

Service Summary Care Record application redesign

Screenshots Desktop

Tablet portrait

Phone portrait

Problem this design solves Our users are clinicians and other health staff, who need to ensure that the patient whose record they are currently viewing is the correct patient. The existing SCRa provides users with a patient banner, containing that patients details. We have sought to update this banner to sit within the NHS.UK framework which we have used as a foundation for our design work, whilst ensuring that the user has all the information they need to perform their role successfully and a patients care is not impacted.

Why have we changed it? The existing system was not designed for mobile use, so we are assessing each of our components to ensure that they work just as successfully on mobile as they do on a desktop device. Whilst our users will be using a variety of different devices, we are currently piloting with users on an iPad. We tested a number of variations of this banner and found that for various reasons, users didn't interact well with them - in some cases not even noticing the banner at all.

Research We have tested with a number of users in different healthcare settings. Feedback on the banner included:

• Users disliked initial versions as the name was too big (for confidentiality reasons) but that it also couldn't be too small
• Liked that the banner showed the patients age
• Users liked a blue patient banner with a lighter coloured tab navigation below it - it stood out more as a result
• Users wanted the banner to fill the page on smaller devices so that text would be easier to read
• "The look and feel is very much NHS"
• Majority of users claimed that "all the information is there", but:
• Users have expressed a desire to have phone number show in the banner for identification purposes (we will investigate this further)
• Some users have expressed a desire to show allergy information in the banner (we haven't been able to explore this further yet)
• Users have said that potentially the banner space could be utilised better
• Users have said that it would be helpful to see a preferred name in the banner, for instance if a patient preferred to be called 'Bill' instead of 'William'. Currently the banner only shows first and last name
• Users want more of the banner details that uniquely relate to an individual in bold (DoB, age, gender)

Anything else The design of our patient banner is loosely based on the aforementioned DWP Key details bar (https://github.com/dwp/design-examples/issues/7). An earlier version that we disproved as being useful:

[alison-warren]

A further example from Alison Warren at Gloucestershire Hospitals Trust https://xd.adobe.com/view/741cd8ef-175c-4a96-5793-b9741b2c8017-022d/?fullscreen

Our app is only just past prototype stage so we haven't done any moderated usability testing yet. However, initial research and prototype testing with a range of acute clinical colleagues, including emergency care, paediatrics, safeguarding and respiratory medicine, led us to the following:

• clinical staff need clear visibility of the patient in context to ensure safe care (ie so it's clear whose information they're reviewing). We've made the header sticky so it's always present when scrolling
• consistency is important. We kept the same patient demographic info in the header as is currently available in the EPR so they are familiar with what info is likely to be visible.
• they like the NHS look and feel which conveys trust and feel it's clearer than the current EPR which I believe was developed to conform to the old CUI standards
• but, when built, we need to test more thoroughly how the header behaves when used in real life context. Some users were concerned the NHS blue elements (including logo) were too big and, combined with the demographic info, were taking up too much of the page. So perhaps we need to slim down?

Happy to share more insights when we have them if useful?

[davidhunter08]

Nice work @alison-warren and @danjohnstonUX. Yes please, share all the insights you can, it's all really useful stuff.

[alison-warren]

Sorry, should also have said we also referred to the new Medical Examiner Service when designing. I know has also been shared on Slack: http://medex-ur.s3-website.eu-west-2.amazonaws.com/meo/patient-details/

[TJFDM]

Futher to @danjohnstonUX update I just want to add that usability testing has taken place with over 100 users, 80% of those were tasked specifically with interacting with the patient banner, the remaining 20% were focussed on other parts of the prototype but were also exposed to it. This testing took place during 1-1 and group sessions. Users were across the follow roles:

• Pharmacy
• Admin
• Management
• GPs
• A&E doctors and nurses
• Paramedics
• Community nurses
• Social worker
• Healthcare assistants
• Data Quality Analysts
• Finance and Costing Analysts It has also been tested in a variety of settings:
• Hospitals
• Prisons
• Ambulance service
• Community
• Trust back office

The current prototypes are being tested on various sized iPad devices and are scalable with desktop too.

[mikebainbridge]

Hi - Mike Bainbridge here. I found my way after seeing Matt Edgar's tweet about the deprecation of the CUI standards. I was the clinical lead on this programme from 2005 to 2011. I worried that some of the safety lessons are being lost. For example:

1. The examples above use different data formats. One uses spaces and one uses hyphens. The research we did was that the hyphens made the date more readable. I'm pleased to see that the format dd-Mmm-CCYY is used. This is unambiguous under all circumstances and languages (except French in June and July)
2. The name format changes radically in the two examples. We did a lot of work on ensuring that the Family and Given names as well as salutation and 'known as' were treated in a predictable way. The referral service example is closer to what I believe is safe:

• Family name in UPPER CASE separated by a comma and a space from;
• First Given name in Title case separated by a space from;
• Salutation in brackets (Mr) and separated by a space from;
• 'Known as' - we found many cases where people did not actually respond to or recognise themselves as their given name
  3. I'm worried about the use of the top left of the screen, the prime real estate, for branding. Here's one of many references I understand how providers are changing but don't agree that branding is more important than identification under any circumstance. I've attached a couple of the old standard quick guide here as there is a lot of detail - I"m not suggesting this is all still correct but some of the display decisions were made after considerable input around safety. This has not changed. I agree that mobile devices have changed since the palm pilot but I would hate the baby to go out with the bathwater in this laudable attempt to move forward with UI / UX in a standardised way.

Hoping this is viewed as helpful and not luddite.

Micro Patient Banner.pdf

Patient Name Input and Display QIG.pdf

Patient Banner QIG.pdf

[simon-davis-nhs]

Agree with the name format, the first and second names need to be clearly identified by the reader, some second names are close to first names and if the reader (like admin staff or reception staff) needs to contact the patient they want confidence that they address the correct person via the telephone. Some of the respondents in our user research quoted times when they had come across names where they were unclear from notes what the first or second name was for the patient. The example I always use is that one of my friends' second name is 'James'.

[devansXD]

@mikebainbridge I'm happy that the name convention on the eRS header meets the CUI standard you quote. Also happy to change our date format to include the hyphen.

[mikebainbridge]

Thanks @devansXD - I'll be interested in the thoughts of @danjohnstonUX on the Family and Given name issues. I completely agree with @simon-davis-nhs . This was the reasoning behind the original. It's also a matter of dignity as well as safety. The number of people with ambiguous names is higher than we first imagine and patients do get very upset when multiple people get it the wrong way round. It's also a little 'something' which undermines confidence.

[danjohnstonUX]

Hi @mikebainbridge - thanks for the input, it's helped us realise that we could do with committing to some further testing on the name within our patient banner. We've had a handful of users explain that "preferred name" would be beneficial to them as this is a field that exists within the existing SCRa. The other issues you've mentioned regarding name haven't really surfaced for us, but that is more owing to the fact we've not explicitly tested the name component (rather we tested the patient banner as a whole and the name was simply a facet of the banner). It's good to get some steer that there are not only clinical issues, but issues around dignity to also consider, and it's something I plan to raise with our team ASAP.

[sarawilcox]

Note that for public facing systems we've decided not to use truncated months (Jan, Feb etc) because screen readers can read them out in inconsistent and sometimes confusing ways. (See https://github.com/nhsuk/nhsuk-service-manual-backlog/issues/99). Often a screen reader will recognise that the truncated version is short for a month and will read out the name of the month in full. Sometimes, however, it will read out the truncation in which case it may or may not be obvious that it's a month (Dec or deck? Apr or A.P.R.?).

[mikebainbridge]

Thanks @sarawilcox - the screen reader challenge is always worth keeping uppermost in thinking. We did toy with the use of a label but this just used real estate - Is there no way of tagging a field to either expand for screen reader to to declare its use ? Real estate is less of a problem than it used to be on the big screens but a long month name is still a challenge on a mobile device or a syringe pump and can, by pushing things off vertically or (heaven forbid) horizontally add a new safety problem.

[mikebainbridge]

I've now had a look at @alison-warren 's image

1. Same issues with the Names
2. Date format ambiguous with US suppliers being notoriously bad at trapping localisation and insisting on using mm/dd (and imperial units and mg% but I digress)
3. NHS number chopped up oddly - I'd stick with 3[space]3[space]4 This is more readable
4. Sex - are you sure you want this and not Gender? We had day long meetings a decade ago on just this point. I didn't think it needed to come up again. It's all in the standard that's being withdrawn
5. Be very careful with a drop down on dates - that way leads to tumblers. Again - lots of advice on standardising this interaction available
6. Username - Should this not follow the same rules as the patient / client ? What about role ?
7. Branding once again surplants safety - why can't we put it down in the bottom left ? Bottom right should be used for alerts (cont p94..)

[mikebainbridge]

And on to the Medical Examiner Service and at risk of sounding like a broken record...

1. Name as above
2. Invalid NHS number wrongly formatted as 3-3-3 instead of 3 3 4
3. Date as above This looks exactly like a paper form which I suspect is what it is replacing. What's the actual purpose of this form? If it's just to capture statistics for a 3rd party then it may be acceptable but if it has other purposes then it needs a re-think.

I'm attaching the standards document items for sex / gender and date. Again not all to be taken as gospel but there are many issues addressed which I've not brought up.

Date and Time Display QIG.pdf Date and Time Input QIG.pdf Date and time input.pdf Date Display.pdf Sex and Current Gender Input and Display QIG.pdf Sex and Current Gender Input and Display.pdf

[mikebainbridge]

So, a couple of days after finding that the standards hundreds of clinicians patients and consumers worked on for 6 years over a decade ago are to be 'deprecated' as they are no longer current, I'm not sure I understand how this new world is better. I see well meaning but naïve approaches. Please take time to look and read what was done. Read them with the lens of new techniques and approaches but try to extract the concepts we addressed. Surely an update on these standards would be a better place to start than watching another thousand flowers bloom ? We are dealing with something VERY simple here. The banner which identifies a patient / data subject / client unambiguously. We took 3 years to produce the documents for even this standard. It was not done on a whim. It was done with careful and mature thought and guided by some of the world's UI / UX experts. Some of the other guidance around SNOMED and Medicines* is, unmatched in maturity of thinking even now. Sure, things have moved on and it was always the intention that the standard would evolve. This requires mature thinking, leadership and funding. CUI was a casualty of the 'everything that CFH did was bad' thinking. It wasn't bad and I hope I have shown you what the value is in having a UI / UX standard in place. Consigning CUI to the bin is both an act of hubris and vandalism (sorry). If we are going to re-cast the NHS and its software then this needs to serve as an early lesson in why the basics need to be got right NOW and QUICKLY. Diversity is fine where required but standardisation of some aspects is a basic safety issue.

*I have been lucky to have been allowed to continue some of the On-screen Medicines work for the Australian Commission for Safety and Quality in Healthcare - This is endorsed by all 8 of the ministries of health in Australia. Nothing in here is unique to Australia

National Guidelines for On-Screen Dis... - National Guidelines for On-Screen Display of Medicines Information - Safety and Quality.pdf

[alison-warren]

I've now had a look at @alison-warren 's image

1. Same issues with the Names
2. Date format ambiguous with US suppliers being notoriously bad at trapping localisation and insisting on using mm/dd (and imperial units and mg% but I digress)
3. NHS number chopped up oddly - I'd stick with 3[space]3[space]4 This is more readable
4. Sex - are you sure you want this and not Gender? We had day long meetings a decade ago on just this point. I didn't think it needed to come up again. It's all in the standard that's being withdrawn
5. Be very careful with a drop down on dates - that way leads to tumblers. Again - lots of advice on standardising this interaction available
6. Username - Should this not follow the same rules as the patient / client ? What about role ?
7. Branding once again surplants safety - why can't we put it down in the bottom left ? Bottom right should be used for alerts (cont p94..)

Thank you very much for this useful feedback @mikebainbridge . This was an early protoype and was shared here for the purpose of contributing to exactly these kinds of discussions, so your input is extremely valuable. The product in question has already evolved further and I'd be happy to share the version we'll launch once it's been through more testing with users.

[jwfone]

I applaud Mike's diplomacy, but I'm afraid I'll be more blunt.

From this thread it is apparent that obvious, crucial points that are clearly explained in the CUI guidance have been ignored. This is immensely frustrating as well as clinically unsafe.

Full disclosure - I worked on the CUI programme for several years. Though I wasn't an author, I was familiar with everything that was written. Was it perfect - certainly not. Did I agree with everything in there - no. Did it look nice - sometimes not. But for simple key points to have been ignored, and for then the whole body of work to be trash-talked and literally trashed, is hugely disappointing. The issue has got 'not invented here' written all over it.

The core data display guidance (name, date, etc) went through VAST scrutiny. How many clinical safety assessment workshops have the above examples been through?

The most glaring example - differentiation of Given & Family name - this is such an obvious basic thing - it's really one of the ONLY things about safe, consistent name display. To then see in this thread comments (from the project team I assume) like 'Oh I'd never really considered people's names could get mixed up' is just astonishing. This is about mis-identification of patients.

Other points based on examples shown here:

• The e-referrals and SCR examples (shown in the NHSD blog post) use different display formats for name and date, and show different core identifiers. The MES service then uses a different NHS number display. This obvious lack of consistency in the examples being shown as 'superior' to the CUI is breath-taking.
• The e-referral's design has no NHS number - 20 years after it was mandated in the NHS for safety reasons. A bit odd?
• E-Referrals tight underlining the patient name - the core id item. Surely a joke?
• The amount of vertical space used on the SCR mobile layout - clearly a non-starter - it takes up 1/3 of the screen?
• The Gloucestershire example date using DD/MM/YYYY - this should not be possible by any team with even a passing awareness of the issues with core data display. It's not ok to say 'this is just a prototype'.
• Not differentiating labels and data?
• Bolding labels rather than data?
• Prioritising age over DoB?
• Using 'Surname' rather than 'FAMILY name'?

The anecdotes in this thread from user research are revealing:

• 'People liked the banner to stand out' - I wonder if there is any CUI guidance on that? Yes there is.
• 'People wondered whether allergy info should be shown in the banner - we should look into this' Hmmm, anything in the CUI guidance? Yes, lots.
• 'People said sometimes it's handy to see a preferred name' If ONLY the CUI had covered this. Oh. It did.

In the NHS D blog post the entire CUI is dismissed out of hand, e.g. "wasn't meeting accessibility and usability standards" I would be very keen to see examples of where this was the case and indeed how the examples presented are deemed to be superior in this respect. It looks very much like the guidance hasn't been read at all, and the underlying safety issues it aimed to address have been ignored.

[jwfone]

@sarawilcox

From the CUI date display guidance:

The CUI guidance is to display the month in full on patient-facing materials. TBH I suspect the rationale behind this wasn't to cater for screenreaders, but it solves the issue in any case.

I do hope this issue wasn't the basis of the belief that the CUI 'doesn't meet accessibility standards'.

[sarawilcox]

Thanks @jwfone. That's helpful to know. I come at it from the patient-facing point of view.

[jwfone]

I've just noticed that the DoB display in the NHS e-Refferals 'improved' example also puts the DoB in brackets, with no leading 0.

The (4 is at risk of being misread as 14 and as such the DoB read incorrectly. This issue is usually seen with things like measurements e.g. (1mg/ml) = bad

The examples provided to show how the CUI was deficient ironically appear to be making the case for why it is needed.

[jwfone]

@sarawilcox So this would seem to confirm that a team at NHS Digital working on NHS guidance for date display have not read the existing NHS Date Display standard. A standard which the NHS went to considerable effort to produce.

It's stored in this same repository: https://github.com/nhsuk/nhsuk-service-manual-backlog/files/3370459/Date.and.Time.Display.QIG.pdf and the quick guide version would have taken 15 minutes to print out and read thoroughly.

Disagree with it - fair enough, but to not even read it?

[thomashallam]

@jwfone Apologies for the long reply.

I'm not going to go through each specific comment you raise as they can be considered by the teams involved. Clearly you have a passion for the CUI and it is helpful to have your reflection, however it is worth noting the processes of designing digital systems and testing things have changed significantly in the last 10 years and the standards are trying to further improve the best practice.

The standards propose best practice for designing whole journeys, with supporting components/patterns and content guidelines - for any product to be successful it needs to be adapted for the users and context of use, one size never fits all.

Most testing should be around end to end journeys, core tasks and consider factors like task success and user satisfaction. Teams are not going to be testing every possibility variation for every piece of text on a page. If the research was testing content at that level of detail across every journey the testing would take 3 years not a few weeks, this is why content, SME and clinical review are usually final steps before things is signed off.

The designs have been created following best practice user centered design. For this piece of work the team have already:

• identified needs based on discovery research evidence,
• conducted several design sprints,
• created multiple prototypes using NHS.uk prototype kit / gov patterns,
• incorporated critique from the design profession,
• conducted many rounds of usabilty testing (as mentioned earlier including hundreds of clinical and admin staff),
• involved clinical colleagues, stakeholders and SMEs throughout the process.

e-Referral Service (e-RS) is not a medications system it is for (mostly) managing transfer of care from GP surgeries to hospital outpatients. The proposed designs above are by far easier to comprehend than the existing system design that has been in place for well over 10 years; as far as I'm aware the "header" itself (despite being so difficult to read) has had no reported clinical safety incidents.

The e-RS design enhancements are likely to improve the clinical safety considerably mainly as the current design is so complex (UI throughout the system) many clinicians refuse to use the system at all. The issue then is they ask admin colleagues to print out ALL the patient and referral information, to either scan documents into another EPR system, or to triage the refarrals on paper risking it getting lost in a hospital. I hope you understand the main goal here is to make the system so easy and user friendly that those risks do not need to happen.

On a separate note, it would be much easier to have discussions like these issues by remote conference rather than through an really long comment thread.

[danjohnstonUX]

Hi @jwfone,

Apologies, you didn’t leave a name so I’m not sure who I’m directing this to. First of all thank you for the feedback - the reason we put this out in the open is so we can receive feedback that we might not have otherwise been afforded. Secondly, I apologise if any my previous posts have come across as “trash talking” or acting as though designs on the SCRa redesign were superior to those within the CUI - this was certainly not my intention.

I’d like to reiterate that all of the examples I’ve posted and referred to are still under development, and are in no way representative of a final product. We have used the CUI at all stages of the design process to help us guide our designs, and we iterate through any and all feedback we receive from our users (and other stakeholders) across a number of different medical professions. On top of this, our designs regularly come under scrutiny from our Clinical Lead on the project, and we would absolutely never release something into a live service that would potentially endanger, or even embarrass a patient.

With more specific reference to some of your points:

• The patient banner on the SCRa mobile layout is an initial view, this has been tested to ensure that upon loading a page it is immediately obvious to a user which patients record they are currently viewing. We intend to reduce the size of this banner on scroll and show an indicator at all times on the page which takes up less real estate. Users have reacted positively to this design and we continually amend based on the feedback we receive.

• I believe we are using the correct Date format on the SCRa redesign. This is something we followed from the CUI guidance.

• We have differentiated our labels and data by emboldening the data values. Again, this was taken from the example of correct usage within the CUI. We added colons because this helped to differentiate the labels and data and it has tested well with users. This has also been overseen by our clinical safety lead.

• We show age as well as Date of Birth, because our users told us that the majority of the time this helps them ensure the patient they’re speaking to or dealing with is the patient whose record is shown. Age would also help certain clinicians with decisions around certain medications and treatments but we provide the Date of Birth as well to ensure that users have access to this if and when it is needed.

• You’re right - the CUI does have guidance on the banner standing out. In fact we ensured our banner conformed with ID points PAB-009 - PAB-0015, we even tested versions that fell foul of these guidance points to further validate that these guidance points were still relevant. For this reason we opted for a blue patient banner because we wanted to “Apply visual styling such as a thick border or distinguishing background colour, to the Patient Banner in contrast to other elements of the application’s user interface”. We found that a blue background tested well because users related the colour directly to the NHS and this increased their trust in the product.

• You’re also right about the CUI giving us tons of information on allergies. It’s an optional, though recommended facet of the patient banner according to the CUI. However, our users access the SCRa for a plethora of reasons and some of those users would have more need to see allergies than others (for instance, a paramedic would be keen to ensure a patient wasn’t allergic to morphine before administering it but somebody working on an Overseas Visitors team would be less interested, and in fact would prefer to see something related to the patients chargeable status. Because we can’t be sure about all the potential use cases at the moment, we’ve omitted it until we can implement it successfully in accordance with feedback from our users. We are currently testing with a pilot ambulance site who have, in fact, successfully used the redesigned SCRa to check a patients allergies successfully.

• You’re right about the preferred name. It’s a recommended feature, it’s something we’re aware of and it’s come up in testing numerous times. We plan to keep iterating over this until we get it right as our various users have stated different needs to one another regarding this name - whether it be that they’d like to see actual/given names and preferred names or they’d prefer to only see the preferred name.

At no point have either myself, my team or (at the risk of speaking on their behalf) the other brilliant colleagues of mine at NHS Digital sought to undermine, dismiss or ignore the invaluable information provided to us by the CUI. We’re not flouting our designs to show how ‘superior’ we are, but rather to ‘Make things open. It makes things better’ - point 9 of our Design Principles. I can assure you that the CUI has been read numerous times to help us guide our position, but as alluded by others, things have changed in the past 10 years and we’re doing our best to ensure that we bring the excellent work that was put into the CUI into the future. The reason that some of these features deviate is because of the different use cases they find themselves in.

Finally, whilst I appreciate your bluntness - you’re clearly extremely passionate about this, which is to be applauded - that bluntness might dissuade others to be open about the work they’re doing, and we really don’t want that to happen. We’ll always welcome feedback, but constructive feedback helps us to make sure we do things correctly. If you’ve any questions about the work we’re doing on the SCRa redesign please don’t hesitate to get in touch with me. We really want to get this right.

Dan

[jwfone]

@thomashallam

"Teams are not going to be testing every possibility variation for every piece of text on a page. If the research was testing content at that level of detail across every journey the testing would take 3 years not a few weeks"

You know what could help with that - some clinical safety assured user interface guidance on common core data attributes found in clinical systems. Maybe someone should look into that?

Ok, so you followed a design process. Sounds good.

Can you explain to me the rationale behind not including the NHS number in the eRS patient banner. The core unique patient identifier that has been mandatory to use for 20 years. Why does the eRS context mean that it is not needed on immediate display?

Also, I was intrigued by this from Matt Edgar's blog post:

"the NHS e-Referrals team found that the patient banner from the CUI wasn’t meeting accessibility and usability standards".

This seemed to be the key trigger behind deprecating the CUI guidance. I.e. old eRS PAB = CUI, old eRS PAB = crap, therefore CUI crap.

So I think I've found an example of the old eRS PAB from a 2018 training guide:

Is this it?

It is quite obviously not even remotely CUI compliant. Not least because it has the most spectacularly poor choice of colour contrast.

So does this mean the rejection of the CUI is based on a false premise? (and not just the premise that in 2010 everyone was using CRTs....)

[thomashallam]

For sure @jwfone.

Can you explain to me the rationale behind not including the NHS number in the eRS patient banner

• Referrers usually identify the patient in a GP system before they reach the NHS referral service, it loads the patient in e-RS automatically. When they are inside the system it is far more important to display the UBRN (transaction number) as the NHS number is not required at all in any part of the referral process. It would also confuse users and be detrimental to the visual design to have two long numbers in the banner.

It is going rather off topic from the original Patient details header post above...

"So does this mean the rejection of the CUI is based on a false premise?"

• Seems unlikely that it is a single example more probably multiple issues, over many years, but I don't know.

"CUI guidance have been ignored. This is immensely frustrating as well as clinically unsafe."

Why is it frustrating?

Is there evidence it is clinically unsafe? I.e. examples where non-compliant interfaces causing harm or unacceptable risk?

I don't have any info on the how the CUI was formulated it would be helpful to know:

Were all of the proposals in CUI usability tested? How? Or are they based only on UI experts, clinical feedback and preference? Is there evidence introducing the CUI made things more clinically safe? i.e. reductions in issues occurring. What's the difference if you adopt CUI vs. not adopting it? Was the impact of CUI programme evaluated? What did this find?

Thanks, Tom

[jwfone]

@thomashallam @danjohnstonUX First of all, I believe this kind of designing in the open is exactly the right thing to do and likely to result in better clinical systems, which the whole point of all of this. Though I'd suggest going even more open - provide everything online, with sufficient context.

I applaud the courage of both the organisation for allowing it and the individuals contributing publically - it's not an easy thing to do. Open design was something that was discussed for the CUI, but at the time there wasn't sufficient will or the availability of the right platforms.

So kudos to everyone. It's the right thing to do.

[jwfone]

@thomashallam NHS number Use of the NHS number as the primary identifier for all patients across health and social care is a major goal of the DoH.

It is (literally) the top of the list of the standards being pushed for full adoption. It is Sarah Wilkinson's explicitly stated number 1 goal for NHS Digital.

It was an NPSA mandate in 2008 to address the "real danger" of serious harm or death of not using it.

It's an IGT requirement

It's an information standard

It's the law

A key part of the rationale for the NHS number even existing is to enable services like eRS and safe transfer of information & care between care settings. The number is mandatory to include in all referrals.

It is therefore quite surprising that NHS Digital's position is that on the actual eRS system patient banner: 'meh - no big deal, we don't like it's effect on the visual design of the page, so we aren't going to promote to the top line'.

I suspect any system supplier that took the position that the NHS's primary patient identifier didn't need to be prominently displayed would be excluded from the NHS.

At any point has someone said 'You know, I wonder if not including the NHS number is strategically a good idea?'

If a risk was raised regarding the UBRN, did no-one say 'Maybe if we include the NHS number with a label, multiple redundant visual cues, and put it on the opposite side of the screen to the UBRN in the exact spot and format that 100% of all other NHS patient information systems are required to do by standard, that might mitigate any potential confusion'? Then having done this design mitigation did you then run an evaluation to determine whether or not unfortunately confusion still existed and as such sadly the NHS number had to be removed?

Secondly, you've said

the NHS number is not required at all in any part of the referral process

Bearing in mind I know very little about referrals, the idea that accurate patient identification isn't important during the eRS process strikes me as odd.

Are you saying that at no point during the use of eRS does a user need to refer to information about that patient which is held outside of eRS? Because IF they did need to refer to such information, they would need to use the primary unique ID for that patient wouldn't they (i.e. the NHS number)?

Are you saying that during the eRS process users never need to look up; letters (whether paper or electronic), results, images, or medical notes? These may be held outside of the system eRS is embedded in, even if it's embedded in one at all - which it is presumably possible for it not to be.

For example, I believe it is very common for a referral letter to be attached as part of an e-Refferal, and I believe it is common that this letter or the content for it might be sourced from outside the core GP record e.g. a dictation system like Lexacom, DXS, a word document or PDF template stored on file share, etc. For a user to accurately pick up this additional letter and then correctly attach it to the right e-referral in eRS they are going to need accurate patient identification - which means as per DoH & NHSD strategy - the NHS number.

Have I misunderstood something?

Also, I believe the OLD version of eRS (i.e. as of Apr 2018) had an advice & guidance function, where provider clinicians might discuss a patient with an advice requestor. I assume that the very first thing a provider clinician would need to know about the request is the patient's NHS number, so that they can look them up on their own system to check any previous history with the provider organisation. But it maybe that this functionality has since been dropped not to return?

N.b. some clinical systems allow multiple patient records to be 'open' at the same time - either via internal tabs/windows, or allowing multiple instances of the application to run. In this case it would be extremely important for the user to know exactly which of the multiple open records they were looking at - and as such as per NHS policy require the NHS number.

[jwfone]

@thomashallam Process I appreciate you need to post-rationalise why as part of the thorough design assurance process it was ok for the eRS team to not even read the existing (mandatory) NHS standards on data display.

(As indicated by:

happy to change our date format to include the hyphen.

)

but I'm afraid you've not hit on a winner here.

Firstly, from one point of view, when something is a standard that has been ratified by the appropriate body (as is the case with the NHS data display standards) the default position should be to comply with those standards, and one would have to have an extremely good reason not to. Given that in large part the point of the data display standards is consistency between systems, from one point of view it doesn't matter what the display is - just that everyone uses the same one.

Secondly, if your comments are taken at face value you genuinely do not know the process by which the CUI guidance / standards were created and as such are not in a position to make a principled rejection of them on methodological grounds.

Had you ever read one of the guidance documents, you would have spotted this after the index page:

This might have hinted that something was going on, which brings me to the third point.

The 'Rationale' sections after each guidance section in each document lays out some of the rationale for that guidance, which includes references to user feedback etc. (TBH it would have been better for rationale to be recorded per guidance point, and I vaguely remember that this exists somewhere - perhaps online).

As far as I remember, you are completely correct that the 'core' data display item guidance (date, name, etc) did NOT undergo usability testing in the strict sense of task success %, time on task, etc. Some of the more transactional guidance like medications, graphing, and SNOMED coding did have more traditional user testing, but not the core display stuff.

Aha gotcha you say.

But. Usability testing while a useful tool, is not the correct methodology to evaluate and safety assess something like these data display elements.

As you see in the guidance documents, as well as drawing on existing conventions, and secondary research into known risks with various data display, the key thing is clinical safety assessment. Basically - what could go wrong, how likely is that, how bad could it be, and what can we do about it.

As you know, usability tests are sized using heuristics about what X% of usability errors one is likely to catch using Y tests. They are then highly artificial setups focused on a small number of identified key tasks. They cannot hope to replicate the circumstances of say an extremely tired junior doctor working under huge pressure in their second language having recently moved from another country which uses different data display conventions. This is kind of circumstance where data misreading happens - not in an air conditioned office with a mug of coffee having a nice chat.

I'm not sure what methods the NHSD clinical safety team are requiring for hazard elicitation these days, but I'm pretty sure it won't be only 'do some usability testing'.

Let's imagine eRS is used 50M times a year and each iteration is used for 5 years - so 250M uses in life. Then, how many times in each use does a user need to visually identify the patient IDs - maybe 2 let's say - so 500M instances where the patient ID has to be read 100% correctly otherwise an error might occur that could endanger life. Do you think it's sufficient to say 'we showed the date display to 20 clinicians and they could all read it fine'? Hence why instead one would use methods used to uncover as many logically possible errors then score them for risk and potential mitigation.

Putting it another way - you question the need for the CUI at all.

Imagine seeing these patient DoB displays on successive screens in an application (which are all the same date): 4-Oct-2010 4/10/10 2010-10-4 10/4/2010

Do you think that this a good idea? Do you think that until someone does a usability test or provides you 'evidence' there's just no way to say whether this is a good idea or not? Do you think there is any chance that this mix of formats might ever lead to an error and as such to patient harm?

You might say 'oh that variety would never happen'. This kind of thing is the norm. NHS users use a variety of patient info systems a day. Some systems may have other systems windowed in to them (like with eRS). Some systems (many large EPRs) may be the result of integration of multiple legacy systems. System's pages and modules are created by different teams at different times. The result is that core data display can easily vary constantly from an end-user point of view. It has been know for clinical systems to use the UK AND US date displays on the same screen.

You don't seem to think this kind of thing is an issue?

In 2007 the NHS felt it was an issue, and I bet it still does, even without a double-blind RTC.

[mikebainbridge]

So - if I read the discussions back that have so far ensued:

1. CUI is still (just) the only global standard designed to improve safety in clinical systems (I'm ignoring the Australian HB306 guidance because it is spectacularly bad in comparison with CUI.
2. CUI does not seem to have had wide readership and current vendors and programmers are not aware of the rigour and approach that CUI took over 5 years to deliver it.
3. From the evidence so far, letting 1000 flowers bloom without a set of standards in place seems 'brave' (In a Sir Humphrey sort of way)
4. Everyone wants to do a good job. Those of us who spent thousands of hours doing process, diligence and engagement so that it never had to be done from scratch again are puzzled by the need to start from scratch both with a set of standards which need updating but on the criticisms so far raised don't deserve to be scrapped. 5.It is good to see enthusiasm in the space again but building rather than demolishing would seem to be more appropriate than the suggested path. I have seen nothing presented so far to dissuade me of this

[mattedgar]

@mikebainbridge @jwfone Thank you both for your input here. Can we do better in terms of consistency and usability? Yes! That's why we're working in the open and placing a renewed focus on this work at NHS Digital. To reiterate what's said on the standards page, we recognise the value in some of the data elements within the CUI standards, and will identify the elements which remain relevant to ensuring patient safety. If you'd like to discuss further, please do get in touch via email at service-manual@nhs.net. I'd be pleased to set up a phone conversation if you prefer.

[mikebainbridge]

Thanks Matt - I'm in the process of getting some dates and times together.

[payneandy]

Like @mikebainbridge and @jwfone I too was slightly alarmed at the blog post regarding the deprecation of CUI guidance. However, having found this thread it would seem that both James and Mike have articulated a number of the concerns involving babies and bathwater. Having led a number of the workstreams of the CUI programme over it's 4 year lifetime working alongside @jwfone and @mikebainbridge to provide vendor and platform agnostic UI design guidance, I'm happy to provide some context to you @mattedgar. CUI guidance was the result of both review of historical patient safety errors which in some cases resulted in fatalities, and continuous involvement of NHS Clinical Safety Officers assessing and quantifying risks and mitigations. My fear is that institutional amnesia could result in these risks becoming actual hazards. I believe that somewhere there are still the original patient safety hazard logs that drove the scope of each guidance area. It would be good to review these and the proposed replacement guidance to CUI to ensure that the risks remain mitigated to the same level. There are also colleagues (only a few) within NHSX and NHSD who were also leading this work and I will connect you with them.

[jwfone]

@payneandy Hello there. I completely agree that if people could see the guidance points mapped against the safety hazards that they mitigate it would help understand their purpose - which is to be sure unclear at times. I may have a version of the hazard logs squirrelled away somewhere, though NHS Digital clinical safety or standards teams should have the official ones.

I believe I also have versions of the guidance with each point mapped to specific rationale (which include hazards) which helps understand why they exist. This may have been available on the two now-defunct CUI websites. You can still find the old toolkit controls - in WPF no less.

As @payneandy says, cancelling the current guidance will mean that these hazards are officially UNmitigated, with an increased risk of patient harm. I will be raising this with NHS D clinical safety.

@alison-warren great to see you've so quickly updated your patient banner, I have some comments that I'll try and post soon @danjohnstonUX sorry to not reply yet - but I will try to

[sarawilcox]

Note that for system date-times and time-stamps, e.g. for data exchange or data sorting, the NHS service standard refers to the GOV.UK guidance here: https://www.gov.uk/government/publications/open-standards-for-government/date-times-and-time-stamps-standard (Approved by NHSX)