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 Sam Procter , John Hatcliff Anura Fernando Sandy Weininger SAnToS Lab Underwriters Laboratories Food and Drug Admin. 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 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 “A particularly attractive feature may be the ability to automatically terminate or reduce n 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. It is critical that any monitoring system be linked to a reliable process to summon a n 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 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

Me Medica ical l Ap Applica licatio ion Pla Platforms rms Clinician Console Displays Devices App Logic B u s EMR Computational Platform Databases 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

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 ICE Architecture (ASTM F2761-2009) 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)

Goals ls of AAMI AAMI / UL 2800 Safety / Security Requirements for Multi-vendor Plug-and-Play Interoperability n Component safety Safety and Security Requirements claims in the context of system safety claims n Components assembled within n an architectural framework that constrains interactions n an organized ecosphere of stakeholders and processes that govern n interactions between stakeholders n contributions to systems

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 A structure for the 2800 Family is required that accommodates the following (sometimes conflicting) goals: Generality -- Provide safety/security requirements that accommodate n and are effective for Multiple architectures n A wide variety of clinical scenarios/applications n Architecture Specificity n Component-wise review of safety-related properties in heterogeneous interoperable n systems cannot be achieved without defining the architecture within which components interoperate The architecture itself plays a key role in controlling potentially hazardous emergent n properties by 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 n management process are application specific Since we are ultimately interested in building safe systems, we need some way in n 2800 to talk about specific systems/applications.

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 Collateral Standards call out device classes (e.g., infusion specific aspects such as Usability, pumps) inherit, refine, (and even Alarms, etc. That can be applied override) general criteria 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 Generality -- Capturing Architecture n General construction and and Application Independent Safety/ architecture/interface Security Requirements specification requirements 2800-0 n General risk management General approach for interoperable Requirements systems n Common fault types n Safety/Security and Essential Performance n General requirements for Objectives for interoperable testing, verification and systems establishing compliance n Common vocabulary for n General approach for referring to elements of compositional assurance interoperable systems case construction for interoperable systems

Pro Propose sed 2800 St Stru ruct cture re Capturing 2800-1 Architecture Process / Reference Model Specificity for specifying interoperability architectures 2800-1-2 2800-1-1 2800-0 Architecture 2 Architecture 1 General (ICE) Requirements Components assembled within 2800 are set up to allow specific n architectures/ecospheres standards (2800-1-x) to be introduced, following guidelines for specifying interoperability architectures (2800-1) 2800-0 General Requirements are mapped to specific architectures n and extended/refined

Refin ineme ment by y Comp mponent Category ry Capturing Architecture Specificity n Example: ICE App Logic n Interacts with… n Physiological parameters n Control Actions

Refin ineme ment by y Comp mponent Category ry Capturing Architecture Specificity TimingRelatedError ServiceTimingError SequenceTimingError ItemTimingError LowRate EarlyService RateJitter LateDelivery EarlyDelivery DelayedService HighRate ControlActionLate ControlActionFlood MissedPhysioParamDeadline PhysioParamFlood PhysioParamLate MissedControlActionDeadline

Pro Propose sed 2800 St Stru ruct cture re Capturing 2800-1 Application Process / Reference Model for specifying interoperability architectures Specificity 2800-1-2 2800-1-1 2800-0 Architecture 2 Architecture 1 General (ICE) Requirements Clinical scenario-specific standards n capture architecture-independent 2800-2-1 clinical process safety requirements PCA Infusion 2800-2 n Monitoring Process for Safety-related data, control, state n introducing requirements clinical scenarios 2800-2-2 hazards n recommended risk mitigations n 2800-0 General Requirements are n mapped to specific clinical use cases