Critical Alarms in ICU Case Study
•
0 likes•81 views
Cognitive Ergonomics in Complex Systems: Communicate Information Efficiently while minimizing annoyance
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Critical Alarms in ICU Case Study
Similar to Critical Alarms in ICU Case Study (20)
More from RojinMoghadam
More from RojinMoghadam (20)
Recently uploaded
Recently uploaded (20)
Critical Alarms in ICU Case Study
- 1. ICU Annoyance Cognitive Ergonomics Assignment 5: Communicate information efficiently while minimizing annoyance Alexandra Maria Bartas - 5165369 Rojin Ghorbani Moghadam - 5088135 Jeroen Lieveloo - 4567382 Parastou Raeis Ghanavati - 5242568 Group 7
- 2. Research
- 3. Follow up of Patients After a Visit to Tourcoing Emergency Department for an Ankle Sprain. (2019). Case Medical Research. Published. https://doi.org/10.31525/ct1- nct04114552 Philips Case Study
- 4. Philips Case Study Follow up of Patients After a Visit to Tourcoing Emergency Department for an Ankle Sprain. (2019). Case Medical Research. Published. https://doi.org/10.31525/ct1- nct04114552
- 7. Hravnak, M., Pellathy, T., Chen, L., Dubrawski, A., Wertz, A., Clermont, G., & Pinsky, M. R. (2018). A call to alarms: Current state and future directions in the battle against alarm fatigue. Journal of Electrocardiology, 51(6), S44–S48. https://doi.org/10.1016/j.jelectrocard.2018.07.024
- 8. Automation in the ICU Reference Gholami, B., Haddad, W. M., & Bailey, J. M. (2018). AI in the ICU: In the intensive care unit, artificial intelligence can keep watch. IEEE Spectrum, 55(10), 31–35. https://doi.org/10.1109/mspec.2018.8482421
- 9. Ideation
- 10. Brainstorm
- 11. Clustering
- 12. Workflow
- 13. Idea overview
- 14. Alarm division
- 15. Workflow
- 18. Output
- 19. MAYA
- 20. Gradual Implementation Now Our Recommandation Future possibilities using Automation
- 21. Hardware
- 22. Just a nuisance?
- 23. UI
- 24. UI
- 25. UI
- 26. Scenario
- 27. Scenario
- 28. Various Devices
- 29. All centralized into one hub
- 30. Oximeter
- 31. Oximeter Detached (actionable - noncritical)
- 33. Oximeter Detached (time limit reached)
- 34. Critical Alarm
- 36. Conclusion
- 37. Conclusions ● When critical alarm goes on, non-critical alarms are still there but softer (prioritization). ● AI changes the alarm from Harmonic to Minor (more sad) when criticality level is increasing.
- 38. Thank You
- 40. ICU Sounds: Current ICU example
- 41. ICU Sounds: Different sounds
- 42. ICU Sounds: Different sounds on time in Cmaj
- 44. ICU Sounds: Critical alarm
Editor's Notes
- A case study from phillips that was done over the course of a week found that there are 237 alarms sounded per day per bed. This mean that there is an alarm every 5 minutes for one bed. This many alarms can become dangerous, as they can overwhelm the clinicians and even desensitize them and have them ignore important alarms. They can also prevent patients from resting. In response to this, the study tried to reduce inconsequential alarms, which included pausing the alarms when performing bedside procedures such as drawing blood and reducing the sensitivity of some of the monitors.They used prioritisation to choose which alarms to mute and which to play. After 6 months they found that 39% of the non - consequential alarms were reduced (making the alarms go from 237 - 173). Link: https://www.philips.com/c-dam/corporate/newscenter/global/case-studies/tourcoing/tourcoing-general-hospital-customer-partnership.pdf
- The nurses and doctors agreed that this helped them with doing their work more efficiently and it positively affected their wellbeing. Another quote from the study: “The alarms project has reduced noise pollution and improved patient care within the unit.” -Dr Delannoy, ICU doctor, Tourcoing General Hospital Link: https://www.philips.com/c-dam/corporate/newscenter/global/case-studies/tourcoing/tourcoing-general-hospital-customer-partnership.pdf
- This is a simplified method to show the process of the alarm, from generating the data (from the patient) to how the clinician receives and interprets the data. Based on this, failures of the systems can be encountered throughout the whole process. We focused mostly on the the issues starting from the processor (since before that, the system relies on the technical limitations of the devices used), for example calibrating the settings based on the patient case or reducing the sensitivity in the settings, so only meaningful alarms can run. Relevant examples that clinicians could have an effect o is how many alarms can run at ones, as they can turn some off if they need to focus on a specific task (which could potentially become dangerous). The clinician can choose to pot respond to an alarm at all by ignoring it. When they do not ignore it they have to acknowledge the alarm, investigate the cause (which could be time consuming), interpreting the information and judge is they need to proceed with an action. Literature review also shows that a large proportion (40-80%) of alarms are not actionable (some not being relevant to the patient case). Link: https://www.philips.nl/c-dam/b2bhc/us/whitepapers/alarm-systems-management/Just-a-Nuisance.pdf
- The same study interviewed 56 clinician on alarm fatigue. They found that an intense frequency of alarms can have serious consequences ”Consequences include: missing true positive alarms; breach of monitoring protocols; stress to patients, families and caregivers and poor use of nursing time”. An interesting outcome was that a lot of the machines make similar sounds which can make it difficult for the clinicians to identify the problem(where the alarm is coming from). Conclusions from the paper: 1. The absolute burden of alarms in the hospital environment is problematic 2. Half of all alarm signals are not clinically relevant 3. Excess alarms, particularly excess ‘nuisance’ alarms, are clinically harmful 4. A large number of false positive alarms is operationally inefficient 5. There is a clear mandate to improve the management of alarms Regrading conclusion 5, we proposed the centralisation of alarms Link: https://www.philips.nl/c-dam/b2bhc/us/whitepapers/alarm-systems-management/Just-a-Nuisance.pdf
- There are many cases for alarm fatigue in the system, starting from the patient, monitors and all the way to how the hospital operates (e.g. if they are understaffed and nurses have to take care of multiple patients or what systems they operate) This slide shows different causes for alarm fatigue and show what are current available solutions and what could be future solutions. Once again we see that some alarms might be inconsequential for a specific patient case. We can also see that due to understaffing a patient can have multiple clinicians assigned and every time they have to analyse what is going on, where an alarm is coming from. Current solutions include customizing the threshold settings for the alarms. One solution is targeting the alarms to who is available or giving the clinicians more resources to faster analyse a situation. (An example for the organisation: develop safety culture) Future solutions: Include more patient information, this can be very useful to avoid inconsequential alams. (System solutions include: Improving alarm reliability) The paper mentions that “Alarm suppression can be accomplished with a variety of suppression algorithms, including statistical metrics” Maybe an interesting way to do that would be machine learning. Link: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6263784/
- Possibilities of automation in the ICU: The two examples above show different levels of automation for 2 different cases: breathing easier and fluid movements. This paper talks about the having automation integrated in the medical field on a gradual scale. As a lot of medical professionals might distrust AI and would want just what is best for the user. Link: https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8482421 Other possibilities for automation in the medical field “Using recurrent neural network models for early detection of heart failure onset” https://pubmed.ncbi.nlm.nih.gov/27521897/ “Artificial intelligence and machine learning for predicting acute kidney injury in severely burned patients: A proof of concept” https://pubmed.ncbi.nlm.nih.gov/31230801/
- Based on the research we did in the previous page, we started the ideation process.
- We generated a lot of ideas that some were out of the box and even out of context. Here we did not refine or eliminate any design possibility.
- After a certain amount of ideas, we started the refinement process of the ideas and categorised them into bigger bubble. The most interesting ones for us were the automize, centralization, and criticality prioritization. With centralisation we mean connecting all the devices to a central hub, as opposed to designing the devices from scratch or proposing that the hospital buys new devices.
- From these ideas and our conclusion, we designed our workflow.
- The patient is connected to the devices that monitor its vitals. These vitals get send to the central hub which then informs the nurse if needed.
- What we call non actionable alarms is called monitoring. Which don't need to be heard until a certain threshold is exceeded.
- AI classifies the data to determine if it the situation is critical and how long before actionable tasks become critical.
- Here is the decision making algorithm of the AI done on the patient data. Al starts with the analysis and firstly checks of the alarm is actually actionable. If yes, it checks if the alarm is Critical, and if yes again, the alarm would be on. And if not critical, it constantly checks if the certain amount of time needed for this specific non critical alarm to become critical has reached or not. If yes, the alarm would go off. I the alarm is not indeed actionable it checks to see if the nurse is in range if yes, a monitoring sound would be plates, and if not, no sound would be played and the information would be stored in the data added to the checklist for the nurse to check at the end of the day.
- As mentioned, the output of the system would be the sounds coming off the speakers, and also being transmitted to the nurse’s personal device.
- We have to keep the acceptability of the system in mind. Gradual change in the ICU (from only feedback from the speaker to the earpiece and other forms of feedback) That's why we propose to have a step in between where it only uses the speaker system, and not the earpieces.
- Now: a lot of mostly unnecessary sounds that they don't know where those sounds are coming from. Our recommendation: Is to centralise all the devices to a single hub that can manage data and alarms and visualize the data. Future: personal wearables that guide the nurse.
- All the ICU devices connect to the connector which collects the data from the devices. This data is processed by the AI. The vitals are displayed on the left and the checklist is displayed on the right. Alarms are then send to the earpiece or the speaker, depending on the type of alarm and if the nurse if close.
- This system focuses of solving these three pain points from the paper mentioned before.
- Here you can see that there is an actionable task that the patient needs a bath. You can also see that there are some events that happened that should be reviewed.
- Oxygen meter fell off so it gets added to the actionable tasks and should be fixed the next time the nurse comes to check up on the patient. So when the nurse goes to visit this patient the nurse will get an alert in their earpiece.
- A cardiac arrest happened which is a critical actionable event and should be resolved as soon as possible. The speaker alarm goes of alerting all nearby nurses of this critical event in order to get them to respond.
- This scenario focuses on one line of situation as an example. When there is an actionable but noncritical situation, it goes on until the time limit is reached and becomes critical.
- As you know, there are a lot of devices and sounds in an ICU room.
- All information is represented in the centralized hub. At this point the system is only monitors the vitals so it doesn’t make any sound as all the vitals are within a normal range.
- The patient wears an oxygen sensor on his finger.
- But the oxygen sensor detaches.
- Oxygen meter fell off so it gets added to the actionable tasks and should be fixed the next time the nurse comes to check up on the patient. So now a non-critical alarm will sound if the nurse is closeby to notify them of this task.
- However, the nurse did not pass by, but the oxygen sensor had been detached for some time now. Enough time for the patient's oxygen levels to have dropped out of the safe range, potentially having lethal consequences. Therefore the critical alarm is triggered to make sure this task gets done as soon as possible.
- After a certain amount of time the non-critical task becomes critical if not yet fixed. For any non-critical task there is a point in time where it becomes critical. For instance after the oxygen sensor falls off, the oxygen level could be slowly decreasing to lethal levels without anyone knowing, but this takes a certain amount of time and it should be critical before that time is reached. This is also to minimise liability. Also there is a clear auditory distinction between non critical alarms and critical actionable alarms to distinguish between urgent and non urgent response.
- After the critical alarm notified the nearby nurses, one of the nurses reattaches the sensor and the critical alarm stops.