An An Arch Archit itect ctura rally-I lly-Integra rated, Syst - PowerPoint PPT Presentation

An An Arch Archit itect ctura rally-I lly-Integra rated, Syst Systems-Ba ms-Base sed Haza zard rd An Analysis lysis for r Me Medica ical l Ap Applica licatio ions s http://cis.ksu.edu/~samprocter Sam Procter and John Hatcliff SAnToS Lab Kansas State University Support: This work is supported in part by the US National Science Foundation (NSF) (#1239543), the NSF US Food and Drug Administration Scholar- in-Residence Program (#1355778) and the National Institutes of Health / NIBIB Quantum Program.

Healt lth Care re Invo volve lves s A A Va Varie riety y of Syst System m Comp mponents s Sensor Data Displays Clinical Protocols Clinicians Actuators Information Systems Patient ! Sensors

Outlin line n Motivation n Report n Annotations n Generation n Language n Impacts

PC PCA A Interlo rlock ck Sce Scenario rio n Patients are commonly given patient-controlled analgesics after surgery n Crucial to care, but numerous issues related to safety n Data for disabling the pump exists now (just a system invariant) -- we just need to integrate it

PC PCA A Pu Pump mp Sa Safety y Interlo rlock ck Fully leverage device data streams and the ability to control devices Devices Clinician / Monitoring PCA Pump Enable Pump Enable bolus dose only for safe time window when ticket present Device Task controller Capnograph PCA Bolus “Enable” Monitoring Data + Ticket Alarm Information Combined Status Display Aggregated PCA Vitals for PCA Monitoring Monitoring Status Application Monitoring Pulse Oximeter Monitoring Data + Alarm Information

Visio Vision Analyses and Regulatory Artifacts Clinical Use Case / App Workflow Description Developer 3 rd Party Certifiers Assurance Case Requirements 3 rd Party ICE Conformance & Safety Certification Submission Package Medical Application Platform Hazard Analysis FDA 510K Submission Package FDA Evaluators App Deployment Risk Assessment

Language Language Model AADL System AADL Process: Logic AADL Process: Device2 Output rate: 1 Display sec .. 5 sec Thread1 Thread1 Thread3 Device1 Thread2 Thread2 Channel Delay: 50ms Period: 50ms WCET: 5ms

ST STPA PA Fundamentals Example n Fundamentals 1. An inadvertent “Pump Normally” n Accident Levels command is sent to the pump n Accidents [PatientHarmed] n System Boundaries 2. Commands are sent to the pump too quickly [PCADamage] n Hazards n Safety Constraints n Control Actions n Control Structure

STPA ST PA Fundamentals Example n Fundamentals 1. App -> Pump: Pump Normally n Accident Levels n Accidents 2. PulseOx -> App 1 : SpO 2 = 95 n System Boundaries 3. App -> Display: Patient = Ok n Hazards n Safety Constraints n Control Actions n Control Structure 1: Also referred to as “Feedback”

ST STPA PA Step 1: Identifying Potentially Hazardous Control Actions n Hazardous Control Actions n Cross-product of control actions and STPA guidewords Control Providing Not Applied Stopped Early Late Action Providing too Long too Soon App -> Pump: PH Not PH Not PH Not Pump Normally Hazardous Hazardous Hazardous App -> Disp: BID BID BID BID BID BID Patient Ok PulseOx->App: Not PH, BID Not PH, BID Not PH, BID Provide SpO 2 Hazardous Hazardous Hazardous PulseOx->App: Not PH, BID Not PH, BID Not PH, BID Provide Pulse Hazardous Hazardous Hazardous Rate

ST STPA PA Step 2: Determining How Unsafe Control Actions Could Occur Control Action: App -> Pump: Pump Normally n Providing : n Bad Data: n Cause: n Incorrect values are gathered from one of the physiological sensors n Compensation: n Rely on multiple sensed physiological parameters to provide redundancy n Not Providing: n Not hazardous

Haza zard rd An Analysis lysis Annotating our Architectural Model Feedback or control action is provided in an unsafe way How would the message be unsafe? What hazard would be caused? What constraint would be violated? What should the occurrence be named? What would cause this to occur? How can this occurrence be compensated for?

Haza zard rd An Analysis lysis Annotating our Architectural Model How would the message be unsafe? What hazard would be caused? What constraint would be violated? What should the occurrence be named? What would cause this to occur? How can this occurrence be compensated for? We’ll come back to these two in a moment.

Report rt Genera ratio ion Deve velo lopme ment n Development of AADL Component component architecture Architecture with Hazard using AADL / OSATE2 Annotations n Addition of Hazard Automatic Analysis Annotations report n Automatic generation of generation STPA-Styled Hazard Analysis Report Example “In Progress” Report Online at: http://santoslab.org/pub/mdcf-architect/HazardAnalysis.html

An Annotatin ing our r Arch Archit itect ctura ral l Mo Model l Inside the AADL System Component What channel will be affected? What specific fault will result? What can we do with our model + specific fault information?

Haza zard rd An Analysis lysis Annotating the Architectural Model The fault is traced to its source component / port

Haza zard rd An Analysis lysis Specification Step 1: Propagation Port the fault will propagate on Specific Fault Direction of the propagation

Haza zard rd An Analysis lysis Annotating the Architectural Model Anything missing? There are two missed error propagations!

Haza zard rd An Analysis lysis OSATE Remembers A Neglected Connection

Haza zard rd An Analysis lysis Interaction between Report and Model Bottom Up Top Down 4. Developer creates supporting 1. Report indicates analysis occurrence property, considers incomplete alternative impacts of hazard 2. Developer creates 3. Tool highlights unconsidered occurrence property and propagation paths supporting EMV2 annotations

Imp mpact cts s n Automation n Traditionally, analysts have to mine a system and maintain it – without tool support n Architectural integration n Faults can be “bound” to specific components and ports n Future: n Testing + Fault Injection n If a compensation is claimed, we can auto- generate a test

An An Arch Archit itect ctura rally-I lly-Integra rated, Syst Systems-Ba ms-Base sed Haza zard rd An Analysis lysis for r Me Medica ical l Ap Applica licatio ions s http://cis.ksu.edu/~samprocter Sam Procter and John Hatcliff SAnToS Lab Kansas State University Support: This work is supported in part by the US National Science Foundation (NSF) (#1239543), the NSF US Food and Drug Administration Scholar- in-Residence Program (#1355778) and the National Institutes of Health / NIBIB Quantum Program.