Error Type Refinement for Assurance of Families of Platform- Based - - PowerPoint PPT Presentation

Error Type Refinement for Assurance of Families of Platform- Based Systems

http://people.cis.ksu.edu/~samprocter

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.

Sam Procter, John Hatcliff SAnToS Lab Kansas State University Anura Fernando Underwriters Laboratories Sandy Weininger Food and Drug Admin.

Healt lth Care re Invo volve lves s A A Va Varie riety y of Syst System m Comp mponents s

Information Systems Sensors Actuators Sensor Data Displays Clinical Protocols Clinicians Patient!

Outlin line

n Background

n PCA Interlock Scenario n MAPs n ICE n UL 2800

n Context n Error Type Refinement n Conclusion

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

Clin linica ically lly Su Support rted

Motivating Clinical Problem: PCA Overdose

n

“A particularly attractive feature may be the ability to automatically terminate or reduce PCA (or PCEA) infusions when monitoring technology suggests the presence of opioid- induced respiratory depression. To facilitate such capabilities, we strongly endorse the efforts to develop international standards for device interoperability and device-device communication.

n

It is critical that any monitoring system be linked to a reliable process to summon a competent health care professional to the patient's bedside in a timely manner. ¡“ ¡

PC PCA A Pu Pump mp Sa Safety y Interlo rlock ck

Devices

Fully leverage device data streams and the ability to control devices

Enable Pump for safe time window

Device Task controller

Enable bolus dose only when ticket present

Combined PCA Vitals Monitoring

PCA Bolus “Enable” Ticket PCA Pump Capnograph Pulse Oximeter Monitoring Data + Alarm Information Monitoring Data + Alarm Information Aggregated Monitoring Status Status Display for PCA Monitoring Application Clinician / Monitoring

Me Medica ical l Ap Applica licatio ion Pla Platforms rms

n A Medical Application Platform is a safety- and security-

critical real-time computing platform for…

n Integrating heterogeneous devices, medical IT systems, and

information displays via communications infrastructure, and

n Hosting applications (“apps”) that provide medical utility via the

ability to acquire information from and update/control integrated devices, IT systems, and displays

B u s

EMR Databases Devices Displays Clinician Console Computational Platform App Logic

AAD AADL and MAPs MAPs

Why use AADL?

n History of successful safety-critical projects

n Avionics / Boeing (SAVI): “integrate-then-build”

approach

n Previously found that MAPs lend themselves

to pub-sub

n Device as publisher, apps as subscriber n Natural to model with AADL’s port connections

n Annexes support a number of regulatory and

verification artifacts

n Hazard Analysis (EMV2), Interface contracts

(BLESS), etc.

Erro Error r Typ ypes s / Commo mmon Haza zard rds s

Error Type Refinement (similar to object-oriented type refinement) in AADL’s Error Modeling Annex

The AADL EM Annex provides pre-declared error type hierarchies which are typically refined from General to Particular

Integra rated Clin linica ical l En Enviro vironme ment

n ASTM F2761-2009

defines a high-level architecture

n Recognized by US

FDA

n Focal point of other

standards development activities (e.g., AAMI)

ICE Architecture (ASTM F2761-2009)

Goals ls of AAMI AAMI / UL 2800

n Component safety

claims in the context of system safety claims

n Components assembled

within

n an architectural

framework that constrains interactions

n an organized ecosphere

• f stakeholders and

processes that govern

n interactions between

stakeholders

n contributions to systems

Safety / Security Requirements for Multi-vendor Plug-and-Play Interoperability

Safety and Security Requirements

Outlin line

n Background n Context

n Enumerating Error Types n Previous Approaches n Standard Refinement

n Error Type Refinement n Conclusion

Relia liabilit ility y An Analyse lyses s and Assu Assura rance ce

Feng-et al., A safety argument strategy for PCA closed-loop systems: A preliminary proposal. MCPS14

Fault lt Typ ypes s / Commo mmon Haza zard rds s

As an example, IEC 80001-1 has a short list of issues. We anticipate that a significantly expanded list will be necessary to support our work.

IEC 80001-1 -- Appendix A -- Common HAZARDS, HAZARDOUS SITUATIONS, and causes to consider in MEDICAL IT-NETWORKS

Mo Motiva ivatio ion for r 2800 Family mily St Stru ruct cture re

n

Generality -- Provide safety/security requirements that accommodate and are effective for

n

Multiple architectures

n

A wide variety of clinical scenarios/applications

n

Architecture Specificity

n

Component-wise review of safety-related properties in heterogeneous interoperable systems cannot be achieved without defining the architecture within which components interoperate

n

The architecture itself plays a key role in controlling potentially hazardous emergent properties by

n

Constraining interactions between components

n

Providing safety-related services that are used in the mitigation of common faults

n

Application Specificity

n

Hazards and top-level system safety constraints which typically drive the risk management process are application specific

n

Since we are ultimately interested in building safe systems, we need some way in 2800 to talk about specific systems/applications. A structure for the 2800 Family is required that accommodates the following (sometimes conflicting) goals:

Exa Examp mple le of St Standard rd Refin ineme ment

2800 structure follows the example of 60601 -- The 60601 family of medical device safety standards provides an example of standard refinement/aspect that allow more general requirements to be tailored to particular contexts…

Particular Standards for specific device classes (e.g., infusion pumps) inherit, refine, (and even

• verride) general criteria

Collateral Standards call out specific aspects such as Usability, Alarms, etc. That can be applied when needed to specific devices (feature-oriented).

Outlin line

n Background n Context n Refinement

n Error Type Refinement n Refinement by Architecture n Refinement by Scenario

n Conclusion

Pro Propose sed 2800 St Stru ruct cture re

n Safety/Security and

Essential Performance Objectives for interoperable systems

n Common vocabulary for

referring to elements of interoperable systems

n General construction and

architecture/interface specification requirements

n General risk management

approach for interoperable systems

n Common fault types n General requirements for

testing, verification and establishing compliance

n General approach for

compositional assurance case construction for interoperable systems

2800-0

General Requirements

Generality -- Capturing Architecture and Application Independent Safety/ Security Requirements

Pro Propose sed 2800 St Stru ruct cture re

2800-0

General Requirements

n

Components assembled within 2800 are set up to allow specific architectures/ecospheres standards (2800-1-x) to be introduced, following guidelines for specifying interoperability architectures (2800-1)

n

2800-0 General Requirements are mapped to specific architectures and extended/refined

2800-1-1

Architecture 1

(ICE)

Capturing Architecture Specificity 2800-1

Process / Reference Model for specifying interoperability architectures

2800-1-2

Architecture 2

Refin ineme ment by y Comp mponent Category ry

n Example: ICE App

Logic

n Interacts with…

n Physiological

parameters

n Control Actions

Capturing Architecture Specificity

Refin ineme ment by y Comp mponent Category ry

TimingRelatedError SequenceTimingError ServiceTimingError ItemTimingError HighRate DelayedService LateDelivery EarlyDelivery EarlyService RateJitter LowRate MissedPhysioParamDeadline MissedControlActionDeadline PhysioParamLate ControlActionFlood PhysioParamFlood ControlActionLate

Capturing Architecture Specificity

Pro Propose sed 2800 St Stru ruct cture re

2800-0

General Requirements

n

Clinical scenario-specific standards capture architecture-independent

n

clinical process safety requirements

n

Safety-related data, control, state requirements

n

hazards

n

recommended risk mitigations

n

2800-0 General Requirements are mapped to specific clinical use cases

Capturing Application Specificity 2800-1-1

Architecture 1

(ICE)

2800-1-2

Architecture 2

2800-1

Process / Reference Model for specifying interoperability architectures

2800-2-1

PCA Infusion Monitoring

2800-2

Process for introducing clinical scenarios

2800-2-2

Pro Propose sed 2800 St Stru ruct cture re

2800-0

General Requirements

n

Safety/security requirements for a particular application on a particular architecture are derived from clinical scenario requirements and architecture requirements

n

E.g., Provides the type of requirements that would form the core of a regulatory submission 510(k) for an ICE app.

Capturing System/Component Properties via Architecture & Application Specificity 2800-3-1-1

PCA Infusion Monitoring for ICE

2800-2-1

PCA Infusion Monitoring

2800-2

Process for introducing clinical scenarios

2800-2-2 2800-1-1

Architecture 1

(ICE)

2800-1-2

Architecture 2

2800-1

Process / Reference Model for specifying interoperability architectures

Refin ineme ment by y Ap Applica licatio ion

n Example: PCA Interlock App Logic n Interacts with…

n SpO2 n EtCO2 n Respiratory Rate n Pump “Enable” Tickets

Capturing Application Specificity

Enable Pump for safe time window

Device Task controller

Combined PCA Vitals Monitoring

PCA Bolus “Enable” Ticket Monitoring Data + Alarm Information Monitoring Data + Alarm Information Aggregated Monitoring Status Status Display for App Clinician

Refin ineme ment by y Comp mponent Imp mple leme mentatio ion

TimingRelatedError SequenceTimingError ServiceTimingError ItemTimingError HighRate DelayedService LateDelivery EarlyDelivery EarlyService RateJitter LowRate MissedPhysioParamDeadline MissedControlActionDeadline PhysioParamLate ControlActionFlood ControlActionLate PhysioParamFlood RRLate PumpShutoffLate EtCO2Late SpO2Late RRFlood PumpShutoffFlood EtCO2Flood SpO2Flood

Capturing Application Specificity

Outlin line

n Background n Context n Refinement n Conclusion

n Using Refined Types n Future Work

Usin sing Refin ined Typ ypes s

n As part of an assurance

case

n In hazard analysis

n

Bottom-up: Seeded faults

n

Top-down: Guidewords

Function Failure Mode Fail Rate Causal Factors Effec t System Effect Detected by Current Control Hazard Risk Rec. Action Provide SpO2 Fails to Provide N/A Network

• r dev.

Failure No SpO2 data Unknow n patient state App Potential OD 3D Default to KVO Provides late N/A Network slownes s No SpO2 data Unknow n patient state App Potential OD 3C Default to KVO Provides too quickly N/A Device error App Logic Freez e System Lockup None Potential OD 1E Network should rate-limit Analyst: Sam Procter Date: September 26, 2014 Page 3/14 System: PCA Interlock Scenario Subsystem: Pulse Oximeter Device Mode/Phase: Execution

Too Large of Dose Allowed

G1

Bad Physiological Data Received Undetected Error Incorrect Physiological Reading Message Garbled by Network Software Encoding or Decoding Error

G3

Physiological Data within Max Range Internal Diagnostics Fail

G2

Future re Work rk

n How should multiple axes of refinement

work together?

n What about other valid axes of

refinement?

n Physical realization n System-theory roles

n Can we connect the error types to a fault-

injection framework?

Error Type Refinement for Assurance of Families of Platform- Based Systems

http://people.cis.ksu.edu/~samprocter

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.

Sam Procter, John Hatcliff SAnToS Lab Kansas State University Anura Fernando Underwriters Laboratories Sandy Weininger Food and Drug Admin.