From Health 201FailSystems

how automated healthcare fails, how you'd know, and what to do at each tier — every claim sourced, reviewed continuously


Design principle

Degradation tiers

A safe automated system knows how to become a less automated one. Every clinical workflow needs a defined answer at each tier, decided before the failure.

Reviewed 26 September 2026Sources checked when written 26 September 2026

The tiers describe how much of the automation is still working and trusted, not how serious the incident is. A hospital can be at tier 1 for one layer (a sepsis model switched off) while every other layer runs at tier 0. The layer × tier matrix below is the design question FailSystems asks of every clinical workflow: for each layer, what must already be true if you drop to this tier today?FailSystems judgement

US rules already require practice. The CMS emergency preparedness rule and the Joint Commission's emergency management standards require two exercises a year with an after-action review, but neither requires the scenario to be an EHR downtime or an automation failure. ONC's SAFER guide goes further and recommends unannounced downtime drills at least once a year.[4,3]

The four tiers

0Full automation

The normal state of a digital hospital. Machines acquire and route data (monitors, interfaces, lab analysers with autoverification), analyse it (early-warning scores, results flags), recommend (CPOE decision support, sepsis or deterioration models) and in places act (barcode-gated administration, smart-pump limits, automated dispensing). Clinicians supervise and decide, but much of the checking has moved into software they no longer see. In levels-of-automation terms, most functions sit in the middle of the scale: the computer narrows or suggests and the human approves (Parasuraman, Sheridan and Wickens 2000). Tier 0 is only safe if you can tell when you have left it: the literature shows automation can fail silently while appearing to work (Wright 2016).[1,2,3,4,5,6,7]

What must be true

  • Power, network, EHR, interfaces and decision support are all up, and you have evidence they are working, not just the absence of complaints.
  • Measure EHR response time for key tasks continuously; ONC's target is under 2 seconds (SAFER Contingency Planning 3.1).
  • A read-only downtime viewer is refreshed at least hourly, tested at least weekly and can print (SAFER 1.4).
  • Backups are daily, off-site, encrypted, air-gapped from normal storage, and full restores are tested (SAFER 1.4).
  • Monitor decision-support alert firing rates so a rule that stops firing is noticed (Wright 2016).
  • Downtime plans, paper forms and staff training exist before they are needed; the CMS rule and Joint Commission EM chapter require exercised plans (42 CFR 482.15(d); EM.13.01.01, EM.16.01.01).

How you know you're here

  • Synthetic transactions (e.g., a test-patient order queried every minute) complete within target times (SAFER 3.2).
  • Interface queues are empty or draining; no lab, pharmacy or imaging messages are stuck in buffers (SAFER 2.5).
  • Alert volumes per rule stay within expected ranges; a sudden drop to zero is a failure, not good news (Wright 2016).
  • The downtime viewer's last-refresh time is current.

How you get back up

  • Re-enter tier 0 only after a formal uptime announcement sent through a channel independent of the EHR (SAFER 2.2).
  • Restart interfaces in a defined order, confirm buffers are empty, and check that no in-transit data was lost (SAFER 2.5).
  • Verify that decision-support rules fire on test patients before relying on them; an upgrade or code change can silently break or flood alerts (Wright 2016).
  • Confirm back-entered data from lower tiers is complete before automation acts on it (TJC SEA 67; ASPR TRACIE 2022).

1Assisted operation

The systems are still running, but you can no longer trust them to do their part unsupervised. The EHR is slow enough to cause errors, one interface has stopped, a model or alert is misfiring, or an upgrade changed behaviour. Automation is demoted to an advisory role: humans make each decision and add the checks the software used to do. This is the most dangerous tier to miss, because screens still look normal. Automation bias and complacency push people to keep trusting output that has become wrong (Goddard 2012; Parasuraman, Sheridan and Wickens 2000), and CDS failures often go undetected for long periods (Wright 2016).[8,1,2,3,9,10]

What must be true

  • Someone has authority to declare that a specific system is untrusted, even while it is technically up, and to say which functions staff must now check manually.
  • Clinicians know which safety checks the software normally performs (dose ranges, interactions, allergy alerts, result routing) so they can perform them deliberately.
  • Pharmacists and lab staff have a rapid channel to flag results or orders that look wrong.
  • Users can report slow response easily, and IT treats slowness as a safety event (SAFER 3.2).

How you know you're here

  • Hourly mean response time above 5 seconds, or more than 3 standard deviations above the mean: ONC's definition of functional downtime (SAFER 3.2).
  • An alert that normally fires daily has gone quiet, or a rule starts firing on patients it should not (Wright 2016).
  • Results are missing, late or duplicated; clinicians report futile searches for results (Wang 2016).
  • A vendor, peer hospital or public source reports a fault in a component you use (e.g., the July 2024 CrowdStrike update took patient-facing services offline at about a third of scanned US hospitals; Tully 2025).
  • Clinicians find the software's advice is repeatedly contradicted by bedside findings.

How you get back up

  • Fix the root cause, then prove the fix: run the affected rule or interface against test patients and compare output with expected values before withdrawing manual checks.
  • Reconcile anything that passed through the degraded system during the window (orders, results, alerts that did or did not fire).
  • Announce the return to normal explicitly, naming the system and the time the manual checks stop.
  • Review the event: SAFER 3.1 asks that downtime events, including functional downtimes, be logged and reported to leadership.

2Manual operation

Electronics are up but the cognitive layer is down. Power, monitors, pumps, phones and devices work in standalone mode, but the EHR, CPOE, decision support, barcode verification or lab/pharmacy interfaces are unavailable. Care runs on paper forms, printouts from a read-only viewer, fax, runners and people's memory. This is the tier the downtime literature describes. It is slower and error-prone: lab result reporting was 62% slower on average during downtime in one study (Larsen 2019), a 17-minute results-system outage multiplied clinician read times several-fold (Wang 2016), and in 46% of downtime-related safety reports procedures were not followed or not in place (Larsen 2018). Ransomware can hold a hospital here for weeks. The Joint Commission tells hospitals to prepare for four weeks or longer (SEA 67).[11,9,12,6,3,13,7,14,15,16,17,18]

What must be true

  • Enough paper forms in every care area for at least 8 hours of orders, medication administration, lab and imaging (SAFER 1.3); ASPR TRACIE suggests pre-printing for a set period such as 48 hours.
  • Paper forms match the current electronic workflow, not forms retired years ago (TJC SEA 67).
  • A read-only downtime viewer or recent printed snapshot gives access to allergies, medications, problems and recent results (SAFER 1.4; ASPR TRACIE 2022).
  • A way to register new patients with unique temporary record numbers that can be reconciled later (SAFER 1.5).
  • Communication that does not depend on the EHR network: call trees, radios, overhead paging, runners (SAFER 2.2).
  • Manual double-checks for high-alert medications in place of barcode and CDS checks (TJC SEA 67).
  • Ordering is reduced to what is needed, because manual lab throughput is far below automated capacity (Larsen 2019).
  • HICS or an equivalent is activated for anything beyond a short outage, with separate IT and clinical branches (HICS 2014; ASPR TRACIE facility assessment).

How you know you're here

  • A designated person has declared downtime against pre-set thresholds, e.g., expected duration over two hours (ASPR TRACIE facility assessment); ONC advises activating the warm site before two hours of unplanned unavailability (SAFER 2.3).
  • Downtime is classified by expected duration so the response scales, e.g., 12 hours or less, over a day, over three days (ASPR TRACIE 2022).
  • When duration is unclear, the ASPR guidance says to assume the longer downtime (ASPR TRACIE 2022).
  • Workarounds appear before a declaration: staff printing, phoning results, keeping private lists. Treat these as a signal that you are already here.

How you get back up

  • For cyber events, confirm the attacker has been removed before restoring; restoring services without eradication can re-infect the network (ASPR TRACIE 2022).
  • Restore in stages by clinical priority; systems will not come back at once (ASPR TRACIE 2022; Synnovis restored by clinical criticality over about five months).
  • Keep downtime procedures running on each unit until its systems are verified; treat recovery as part of downtime (ASPR TRACIE 2022).
  • Back-enter orders as coded data and scan other paper; authenticate every transcribed order (SAFER 1.3; TJC SEA 67).
  • Reconcile medications with doctor-pharmacist pairs; one district needed 2-3 hours in high-use areas after an 8-hour downtime (Lyon 2023).
  • Merge temporary patient IDs into permanent records (SAFER 1.5).
  • Add staff for data entry so bedside staff are not doing catch-up documentation on top of care (ASPR TRACIE 2022).

3Analog fallback

Power, the network or both are gone, or cannot be trusted. Generators have failed or do not cover the load, UPS batteries are running down, phones and paging may be out, and HVAC and lighting may be lost. What remains is paper, battery-powered devices while their charge lasts, manual techniques (bag-valve ventilation, gravity infusions, cylinder oxygen, direct observation instead of telemetry) and clinical judgement. At this tier the question is often whether to shelter in place or evacuate. NYU Langone evacuated 21 NICU patients in 4.5 hours after Hurricane Sandy's surge cut power in 2012 (Espiritu 2014).[19,13,3,5,4,6,7,20]

What must be true

  • Staff are trained for complete power failure: monitoring ventilator and device batteries, bagging, gravity drips, switching to cylinder oxygen, with paper checklists (ASPR TRACIE facility assessment).
  • Critical equipment on emergency power is known; equipment not on backup power (e.g., call buttons) has a monitoring plan (ASPR TRACIE facility assessment).
  • Emergency lighting and battery backups for key lights and access controls are in place (ASPR TRACIE facility assessment).
  • Generators and fuel meet the hospital's plan; ONC suggests 2 days of fuel on site and monthly testing (SAFER 1.2); the Joint Commission requires a 96-hour sustainability plan (EM.12.02.11).
  • Evacuation and transfer plans, and receiving-hospital agreements, exist and account for regional outages (42 CFR 482.15(b)(3),(b)(7); TJC SEA 67).
  • Printed contact lists, on-call lists and the downtime policy are available on each unit and off site (SAFER 2.3; ASPR TRACIE facility assessment).

How you know you're here

  • Loss of normal power with generator or transfer failure, or UPS alarms with no generator pickup.
  • Loss of both data and voice communications at once.
  • Loss of HVAC in areas that need temperature control (ORs, server rooms, pharmacy storage) (ASPR TRACIE facility assessment).
  • Pre-defined triggers for diversion, transfer or evacuation have been met (ASPR TRACIE facility assessment 1.13.1).

How you get back up

  • Before power returns, turn off and unplug unused equipment to prevent surge damage (ASPR TRACIE facility assessment).
  • Restore power and communications first, then climb to tier 2: run paper procedures while electronic systems are checked.
  • Check life-support devices and biomedical equipment before putting them back in service; recovery may require reloading software on capital equipment (ASPR TRACIE 2022).
  • If you evacuated, repatriate patients deliberately and rebuild their records from what travelled with them (ASPR TRACIE 2022; Espiritu 2014).
  • Run a full after-action review; CMS counts a real activation as an exercise only if it is documented and analysed (42 CFR 482.15(d)(2); SOM Appendix Z).

Layer × tier matrix

What must hold for each layer at each tier. Read a row to see how one layer degrades; read a column to see what a whole hospital needs at that tier. Each row links to the layer's full, sourced defenses; the cells are FailSystems' summary of them.

These are practices reported or recommended in the cited sources, gathered for reference. They are not a prescription for your organisation; judge what fits your setting, and check the current official text of any standard.

Layer0 · Full automation1 · Assisted operation2 · Manual operation3 · Analog fallback
PowerThe whole power chain (generators, fuel, transfer switches, cooling) is sited above flood level, and production and recovery IT do not share a cloud region or a grid.Partial outages have clinical triggers: slow labs or order entry open downtime command even while systems are technically up.Generators are load-tested, the EHR and downtime workstations ride on UPS, there is fuel for two days, and everyone knows which devices are on emergency outlets.Paper operation for weeks and evacuation without lifts have been rehearsed, and every evacuated patient leaves with a paper summary.
Connectivity & dataPhishing-resistant MFA on all remote and vendor access, air-gapped backups, redundant network paths, and contracts that commit third parties to notification and recovery times.A segmented network, a warm site that can take the whole EHR within hours, and a contracted alternate clearinghouse and reference lab.A read-only EHR refreshed hourly and printable on backed-up power, a communication channel off the EHR network, and a decision to call downtime within 2 hours.Current paper forms on every unit, runners to move orders and results, regional mutual aid for cyber incidents, and a planned recovery phase for back-entry.
DevicesAn inventory with firmware and support dates, SBOMs and patch timelines in contract, staged update rings, and accuracy data by skin tone for oximeters.Clinicians verify pumps against the current order and question readings that don't fit; clinical devices sit on their own network and can still monitor locally.Standalone monitors and pumps stocked on critical units, offline recovery kits for endpoints, and manual infusion programming with a double-check.Paper flowsheets, manual BP cuffs and gravity sets on hand, the skills to use them, and a decided list of what elective work stops.
Models & agentsEvery model is validated locally before go-live, has a named owner and monitoring plan, logs its version with each output, and agents act with least privilege.Someone is authorised to switch a model off on a defined trigger, a visible 'model off' banner shows it, and override is explicit and unpenalised.The pre-AI workflow is documented, staffed and rehearsed, and patients always have a non-AI route to care.Paper versions of the criteria models encode (sepsis screens, early-warning scores), and drills where the EHR is up but a model is known to be wrong.
Human handoffClinicians keep unaided performance measured, every alarm and alert has a named responder, and each AI tool's level of automation is written down.Every mode change is shown on screen and says what the clinician now owns, with takeover procedures for each known failure signature.Alarm limits are set per patient, and who may silence or widen them is written down and audited; critical alarms are audible wherever the responder is.Unannounced downtime drills on every unit each year, with every clinician trained on paper ordering and on finding the read-only EHR.
CascadesA dependency map from each clinical service to its suppliers, networks, devices and utilities, with primary and backup never sharing a single point of failure.Alternates are enrolled for every concentrated supplier, and disconnection criteria are agreed with partners before an incident.Neighbours and EMS hear early, services are restored in order of clinical criticality, and all staff (not only IT) can run an extended cyber downtime.Signed transfer agreements, plans for region-wide events where every neighbour is down, and space, power and oxygen for the community's electricity-dependent patients.

Rehearsal

US hospitals are required to exercise. Under the CMS emergency preparedness rule, a hospital must run two exercises a year: an annual full-scale community exercise or facility functional exercise, plus a second one that may be a facilitated tabletop. It must analyse every drill, tabletop and real event, and revise its plan (42 CFR 482.15(d)(2)). The Joint Commission's 2022 EM chapter mirrors this: two exercises a year, with after-action reports reviewed by a committee and sent to senior leaders (EM.16.01.01, EM.17.01.01). CMS guidance says not to test the same scenario every year (SOM Appendix Z). None of these rules names EHR downtime or automation failure as a required scenario. ONC's SAFER guide goes further: it recommends unannounced EHR downtime drills at least once a year, and the Joint Commission suggests drilling annually or quarterly depending on staff turnover (SAFER 2.1; SEA 67).

The evidence that drills work is thin and mostly descriptive. A systematic review of hospital mass-casualty training found drills helped staff learn procedures and exposed weak points in command, communications and patient flow, but study quality was poor and no included study evaluated tabletop exercises (Hsu 2004). A 2025 scoping review found tabletops were the most common hospital training method but could not identify a best one (Malek 2025). Studies of downtime drills are single-site reports: unit drills audited against a checklist (Kashiwagi 2016), a live PACS-offline drill (Dhamija 2022), a quarterly exercise tied to EHR upgrades (Bulson 2024), six-monthly random-unit drills (Lyon 2023), and a nurse escape room with self-reported gains (Rossley 2022). None measures patient outcomes.

Real downtimes show what drills should target. In Larsen 2018, 46% of downtime-related safety reports described procedures that were not followed or not in place. Clinicians kept ordering tests at normal rates during downtime (Larsen 2019). In a simulation, clinicians did not recognise that a patient's deterioration came from a compromised device (Dameff 2018). Staff surveyed after a well-planned downtime still did not know where to find resources (Lyon 2023). FailSystems' reading: exercises should test detection and the declaration decision, the recovery and back-entry phase, and tier 1, not only the switch to paper.

Coming back up

Coming back up is its own hazardous phase, and guidance treats it as part of downtime rather than its end. Restore systems in stages by clinical priority, keep downtime procedures running on each unit until its systems are verified, and for cyberattacks, confirm the attacker is gone before restoring, since restoring without eradication can leave the network compromised (ASPR TRACIE 2022). Restart interfaces in order with empty buffers, because in-transit data can be lost without warning (SAFER 2.5). Before you withdraw manual checks, check that automation behaves as expected. Wright 2016 found that CDS rules can silently stop firing, or fire spuriously after an upgrade. That is why FailSystems suggests running test patients through key rules before announcing uptime.

Back-loading paper is heavy, slow work and needs its own staff. SAFER asks for a process to enter orders as coded data and scan other paper after reactivation, and to merge temporary patient IDs (SAFER 1.3, 1.5). The Joint Commission says to authenticate every transcribed order and to assign staff for data entry (SEA 67). One district needed 2-3 hours of doctor-pharmacist medication reconciliation in high-use areas after an 8-hour planned downtime (Lyon 2023). Paper records made during real downtimes are often incomplete (Larsen 2019), and some manually recorded data may be deliberately left out of the EHR. ASPR advises documenting what that data is and where it is kept (ASPR TRACIE 2022). As early as 2000, LDS Hospital found that recovery from planned downtimes was not smooth, and it wrote down exactly which data had to be re-entered (Nelson 2007).[7,3,2,6,15,11,21,14,32]

How this relates to levels of automation

The four tiers are FailSystems' own operational framework, not an established standard. They borrow from the levels-of-automation literature. Sheridan and Verplank's 1978 ten-level scale runs from the human doing everything to the computer acting alone. Parasuraman, Sheridan and Wickens (2000) applied it separately to four functions: information acquisition, analysis, decision selection and action. A hospital at tier 0 runs different functions at different levels. Tiers 1-3 describe what happens when those levels are forced down in a failure, rather than chosen at design time. Tier 1 lowers decision and action automation while keeping information automation. Tier 2 removes analysis and decision automation but keeps device-level acquisition and action. Tier 3 also loses most acquisition and action. The same literature warns that high automation brings reduced situation awareness, complacency and skill loss, which matter most when automation fails (Parasuraman et al. 2000). Bainbridge's 'ironies of automation' makes the same point: automating a task can make the human's remaining job harder. Automation bias in clinical decision support is well documented (Goddard 2012). SAE J3016's driving levels 0-5 are a useful vocabulary analogue only. Its 'fallback' and 'minimal risk condition' concepts roughly match a planned drop to a lower tier, but J3016 has no status in healthcare.[33,1,34,8,35]

Sources cited on this page

  1. A Model for Types and Levels of Human Interaction with Automation. IEEE Transactions on Systems, Man, and Cybernetics Part A 30(3):286-297, May 2000. Primary Peer-reviewed · link checked 2026-09-26
  2. Analysis of clinical decision support system malfunctions: a case series and survey. J Am Med Inform Assoc 23(6):1068-1076, 28 March 2016. Primary Peer-reviewed · link checked 2026-09-26
  3. SAFER Guide: Contingency Planning (2025 edition). ASTP/ONC, US Department of Health and Human Services, 2025. Primary Guidance · link checked 2026-09-26
  4. 42 CFR 482.15 Condition of participation: Emergency preparedness (hospitals). eCFR / CMS. Primary Regulation · link checked 2026-09-26
  5. Reference Guide: Emergency Management Standards, effective July 1, 2022 (HAP & CAH). The Joint Commission, 2022. Primary Standard · link checked 2026-09-26
  6. Sentinel Event Alert Issue 67: Preserving patient safety after a cyberattack. The Joint Commission, 15 August 2023. Primary Guidance · link checked 2026-09-26
  7. Healthcare System Cybersecurity: Readiness & Response Considerations (updated October 2022). HHS ASPR TRACIE, October 2022. Primary Guidance · link checked 2026-09-26
  8. Automation bias: a systematic review of frequency, effect mediators, and mitigators. Journal of the American Medical Informatics Association 19(1):121-127, January 2012. Primary Peer-reviewed · link checked 2026-09-26
  9. Measuring the effects of computer downtime on hospital pathology processes. Journal of Biomedical Informatics 59:308-315, February 2016. Primary Peer-reviewed · link checked 2026-09-26
  10. Patient Care Technology Disruptions Associated With the CrowdStrike Outage. JAMA Network Open (Tully JL, ... Dameff CJ), 1 July 2025. Primary Peer-reviewed · link checked 2026-09-26
  11. Continuing Patient Care during Electronic Health Record Downtime. Applied Clinical Informatics (Larsen E, Hoffman D, Rivera C, Kleiner BM, Wernz C, Ratwani RM), May 2019. Primary Peer-reviewed · link checked 2026-09-26
  12. Implications of electronic health record downtime: an analysis of patient safety event reports. Journal of the American Medical Informatics Association 25(2):187 (Larsen E, Fong A, Wernz C, Ratwani RM), February 2018. Primary Peer-reviewed · link checked 2026-09-26
  13. Health Care Facility-Level Extended Downtime Assessment. HHS ASPR TRACIE, 2026. Primary Guidance · link checked 2026-09-26
  14. Hospital Incident Command System Guidebook, Fifth Edition. California Emergency Medical Services Authority, May 2014. Primary Guidance · link checked 2026-09-26
  15. What Goes Up, Must Come Down: A State-of-the-Art Electronic Health Record Downtime and Uptime Procedure in a Metropolitan Health Setting. Applied Clinical Informatics 14(3):513-520, 5 July 2023. Primary Peer-reviewed · link checked 2026-09-26
  16. Synnovis cyber update. Synnovis, 2025. Supporting Official report · link checked 2026-09-26
  17. Evaluation of causes and frequency of medication errors during information technology downtime. Am J Health-Syst Pharm 66(12):1119-1124, 15 June 2009. Primary Peer-reviewed · link checked 2026-09-26
  18. The effects and preventability of 2627 patient safety incidents related to health information technology failures. Lancet Digital Health 1(3):e127-e135, 27 June 2019. Primary Peer-reviewed · link checked 2026-09-26
  19. Evacuation of a neonatal intensive care unit in a disaster: lessons from Hurricane Sandy. Pediatrics (American Academy of Pediatrics), 2014. Primary Peer-reviewed · link checked 2026-09-26
  20. State Operations Manual Appendix Z: Emergency Preparedness for All Provider and Certified Supplier Types, Interpretive Guidance (Rev. 204). CMS, 16 April 2021. Primary Guidance · link checked 2026-09-26
  21. Downtime procedures for a clinical information system: a critical issue. Journal of Critical Care 22(1):45-50, March 2007. Primary Peer-reviewed · link checked 2026-09-26
  22. Clinical Cybersecurity Training Through Novel High-Fidelity Simulations. Journal of Emergency Medicine 56(2):233-238, December 2018. Primary Peer-reviewed · link checked 2026-09-26
  23. Ransomware Attack Associated With Disruptions at Adjacent Emergency Departments in the US. JAMA Network Open (Dameff C, Tully J, Chan TC, et al.), 8 May 2023. Primary Peer-reviewed · link checked 2026-09-26
  24. O Positive and O Negative donors asked to urgently book appointments to give blood following London hospitals IT incident. NHS Blood and Transplant, 10 June 2024. Primary Official report · link checked 2026-09-26
  25. Effectiveness of hospital staff mass-casualty incident training methods: a systematic literature review. Prehospital and Disaster Medicine 19(3):191-199, 2004. Primary Peer-reviewed · link checked 2026-09-26
  26. Effectiveness of CBRNE Event-Response Training in a Hospital Setting: A Scoping Review. Disaster Medicine and Public Health Preparedness 20:e2, 23 December 2025. Primary Peer-reviewed · link checked 2026-09-26
  27. All CLEAR? Preparing for IT Downtime. American Journal of Medical Quality 32(5):547-551, 30 August 2016. Primary Peer-reviewed · link checked 2026-09-26
  28. PACS downtime drill: testing departmental workflow with an enterprise imaging viewer and archive. Pediatric Radiology 52(7):1234-1241, 30 March 2022. Primary Peer-reviewed · link checked 2026-09-26
  29. Electronic health record downtime responses: One health system's process for ongoing readiness. Journal of Business Continuity & Emergency Planning 18(1):39-48, 2024. Primary Peer-reviewed · link checked 2026-09-26
  30. Implementing a Large-Scale Escape Room: An Intervention to Increase Electronic Health Record Downtime Competence. Journal for Nurses in Professional Development 39(6):316-321, 2022. Primary Peer-reviewed · link checked 2026-09-26
  31. Electronic Health Records and Downtime Procedures Topic Collection. HHS ASPR TRACIE, 2 December 2025. Primary Guidance · link checked 2026-09-26
  32. Operational Continuity - Cyber Incident (OCCI) Checklist, Version 1.1. Health Sector Coordinating Council Cybersecurity Working Group, May 2022. Secondary Guidance · link checked 2026-09-26
  33. Human and Computer Control of Undersea Teleoperators (MIT Man-Machine Systems Laboratory technical report). MIT / Office of Naval Research (DTIC AD-A057655), 1978. Primary Official report · link checked 2026-09-26
  34. Ironies of Automation. Automatica 19(6):775-779 (Pergamon / IFAC), November 1983. Primary Peer-reviewed · link checked 2026-09-26
  35. J3016_202104: Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles. SAE International, 30 April 2021. Primary Standard · link checked 2026-09-26

Cite this pageFailSystems. “Degradation tiers.” https://failsystems.health201.com/tiers/ (reviewed 2026-09-26). Health 201 / AstroNexus LLC. CC BY 4.0.

Information only, not advice. FailSystems is an aggregation and synthesis of published sources. It is not consulting, engineering, legal, regulatory or medical advice, and using it creates no professional relationship. Health systems are complex and no approach fits every organisation: anything you adopt is your own decision, at your own risk, and should be checked against the current official sources and by qualified people who know your setting. Full disclaimer.

Dealing with an incident right now? This site is a reference, not an incident-response service. Activate your organisation's emergency operations plan and incident command, and: