NOTE - This is more of a one-off rant from being a new stressed out parent and [hopefully] does not reflect my usual post approach. I add this foreword update even as the beeps are once again blaring loudly next to our ears… patience is a struggle in the ICU.
If you’re near a smoke detector in your home, go press the Test button now. Hear (or remember) that shrill tone that all but guarantees you wince in pain as soon as it starts going off? Now imagine that you’re a fragile, sick patient lying on a hospital bed (not to mention being a preterm baby) and are suddenly bombarded with that ear-piercing wail emanating mere feet from your head - that’s not detrimental to your recovery, no, not at all…
Today I cannot help but write what is basically a passive-aggressive demand for medical device designers to ensure they’re all seriously considering their recipient users’ contexts and ecosystems. This is because, as a parent sitting next to their child in the Newborn Intensive Care Unit (NICU), if my own ears are ringing after a machine’s alarm goes off, the patient is experiencing it far worse.
In our particular instance, there is a nitric oxide monitoring device next to my son’s bedside that does what most medical devices do, it beeps to alert the nursing staff of an issue that needs attention before causing harm to the patient - surely meeting one of it’s key functional requirements. High fives all around the team.
However, as painfully described above, the issue is not that it beeps, but that the sound selected, tested, and approved by more than one person along the design to manufacturing pipeline unintentionally causes it’s own harm to the patient (and everyone else in the room) with it’s volume and tone.
Now, not all things that beep in an ICU are pleasant by far, but most of the core systems around a patient’s bed use softer, melodic tones that still adequately alarm the staff (and as a bonus, have different patterns depending on what the criticality of the issue is). The sounds from this nitric oxide monitoring devlce though stand out like a headache, and this is why I emphasise that product designers need to not only consider the context of use for what they create (e.g. a hopistal ward for severe health issues), but the system ecosystem as a whole in how likely it is to fit in from sounds to settings and use.
As such, I cannot fathom that this particular product had a requirement (or user story, at best) to keep the decibels of the alarm under a fragile patient’s auditory pain threshhold or really any hearing-abled person’s tolerance (did they test this product out with protective earmuffs?). As for the ecosystem, the sound design requirement should have considered what other devices it’ll most often be used alongside to ensure its alarm tone does stay distinguished, but not interfering nor aggressively disruptive (i.e. one that makes the nurses have to drop whatever else they’re doing to mute the shrill instead of being able to prioritise what needs more attention).
There is a natural temptation to also blame the NICU ward itself for not considering the secondary impacts of the devices they use and it’s not invalid, however, when talking to the staff, you quickly recognise that they needed a special device, it was acquired (at an exorbitant price), and now staff and patients alike are left to suffer the results of poor human-centred product design.
So, for digital and physical products alike, this is my ask to all: get out from behind your desk and spend some time side-by-side with your end users, particularly those that aren’t in a position to make decisions as to what they need to rely on - there’s more than product sales at stake.
22/2/21Follow-up insights and responses
In a feedback conversation with David Birkas, a Design Manager for healthcare software products and unaffiliated with the specific device shown in the image above, he had the following insider insights (paraphrased) into similar manufacturing processes from the device design perspective:
'Harm' is a broad term, but there is a mandatory risk assessment where you make a list of use case scenarios, their probability/severity of patient harm, and have to document the risk mitigation. This is a long and tedious process because before the product can be released, you have to do summative testing with at least 15-25 participants from every user group (e.g. clinician, tech, nurse, etc) in a real-life environment or an accurate simulation of it. For example, for an x-ray or CT machine, there are simulation testing rooms because it might be technically impossible to bring them into a hospital and try them there.
The nature of the hospital environment is that it's impossible to test every scenario as there are number of devices in every room, they change even in one hospital. However, and this is the sad truth of the matter, if a hardware or software medical device is especially annoying, then there is almost surely almost surely a reason behind it, a so-called 'adverse event'. Somewhere that particular nitric oxide device was not loud enough and it caused an issue which led to an investigation, maybe a recall, and a re-testing of the device to make sure that this time it's doesn't fail in the same manner (e.g. failure to alert the nursing staff). Perhaps it was not loud enough in an ER room, and potential solutions like adding a setting to make the alarm quieter is not an option because it all but guarantees that someone will turn the volume down and eventually result in a negligent medical issue. So, as a manufacturer, what you can try to do is make a different version targeted for specific healthcare environments/wards, but that's quite an expensive option for all parties.
From this discussion, I recognised how he mentioned there being usability testing with the staff using the device, but what of the recipient patient's experience? In discussing this particular nitric oxide monitor, it'll be tested in different healthcare environments and wards and, as David noted, there's a very good chance that in at least one of those contexts such as a frantic emergency room it needed a very loud pitch and tone to be noticed by someone on the team, potentially someone even in another room.
However, this raises what I often see as linear thinking for lack of a better word, in that we all tend to go with the next obvious solution such as making the existing alarm louder which makes me wonder, what other solutions might exist to meet both staff and patient needs?
In the case of this screeching alarm, the staff couldn't miss it practically anywhere on that half of the building (I'm only half-joking). But, equally, if not more important, I believe that the patient's mental and physical health state must also be considered because what if the surprise and auditory pain received as a result of this alarm going off actually causes them to go into a form of bradycardia and oxygen desaturation shock which would defeat the entire purpose of what the nitric oxide mixture was attempting to help prevent?
I understand that too much nitric oxide can also easily lead to death, so this is a very tricky field to put it lightly. Yet, this why (other than getting some of my parental stress out through writing) I have simply a call to designers out there to ensure we're all thinking about the full picture of who may be impacted, to what degree, and what other options might be available to us that aren't the first ones we think of - in this case, sound designing a loud enough alarm for the staff to recognise a critical issue, yet being one that also doesn't negatively impact the patients in the meantime or perhaps not being as loud, but being able to digitally connect to other devices in other rooms to send a series of high alert notifications.
There's more than one way to solve almost any problem, it just takes a bit of co-designing ideation to find it.
David had a final follow-up insight (paraphrased):
Usually there's no usability testing with patients as they are not using the device. If it's used _on_ patients, then there is testing for that, but it's a process more more similar to a drug trial and not user experience. Another key aspect of this whole issue is that the summative testing process is very expensive, costing up to $100k+, which might be another reason why these devices are only tested with healthcare team who are actually using it.
Additionally, testing usually happens in a testing facility/room where you don't bring in "patients", only users similar to car crash safety tests. To get into a real hospital, even just for discovery research, it usually takes months and I have doubts that they'll ever let you in for testing the sound of a device in an actual environment. As for the loudness factor, I can imagine that the device was not loud enough in an already loud room (like ER) and it caused the death or injury of a patient. In this case, after the investigation, they make the device louder, not really considering (or potentially caring) about what happens in a quiet environment. Whether we like it or not, we device makers have to weigh up things like deafness and uncomfortability versus potential death - and it's mentally tasking for sure.
What can give us hope though is that healthcare providers have started to pay attention to patient experience, so things are moving slowly in the right direction. There will start to be more demands that PX is factored into the development of software and hardware products, and the manufacturers will have to start paying more attention to it.