Rationale and Architecture Principles for Medical Application Platforms

Transcription

1 Rationale and Architecture Principles for Medical Application Platforms Acknowledgements: MD PnP Project led by Dr. Julian Goldman at CIMIT NIBIB Quantum Health Care Intranet Team Medical Device Coordination Framework (MDCF) Teams at KSU and U Penn Support: Funding provided by US National Science Foundation awards , , , (Cyber-Physical Systems and FDA Scholar-in-Residence programs) and the NIH/NIBIB Quantum program

2 Health Care Involves A Variety of System Components Sensor Data Displays Clinical Protocols Clinicians Actuators Security Information Systems Patient! Sensors Together these elements form the precursor of a Cyber-Physical System of Systems. Unfortunately, these elements are largely un-integrated, and so appropriate automated systems solutions cannot be applied.

3 Integrated Clinical Environment Supervisor EI Adapter Physical Device App A 1 App A 2 Network Controller (NC) Ice Equipment Interface (EI) I 1 Native EI-Compliant Physical Device App A n ICE App Code Language / Virtual Machine ICE EI Interface Description Language Ice Equipment Interface (EI) I 3 EI Adapter Physical Device ASTM Standard F for ICE defines a high-level architecture and functional concept Subsequent standards are intended to provide specific functional and interfacing requirements for components The ICE architecture standard is the focal point for FDA s evaluation of MAP concepts in future medical systems A key element of this evaluation is moving from regulation of systems as a whole to component-wise regulation

4 AADL for MAP Standards Use of AADL in medical interoperability standards work AAMI / UL 2800 Family of safety standards for Medical Interoperability Architectures KSU is contributing an Informative Annex that will illustrate how AADL can be used to specify architecture, interfaces, and safety rationale.

5 AAMI / UL 2800 Structure Use AADL to specify medical device interoperability architecture to support 3 rd -party / regulatory review 2800 General Principles for Medical Device Interoperability 2800-X ICE Interoperability Architecture & Principles Define ICE Architecture in AADL and use Error Model to define common faults / errors for each component, propogation, and mitigation 2800-X-01 ICE Interface X-02 ICE Interface X-n ICE Interface n ICE Architecture

6 AAMI / UL 2800 Structure Use AADL to specify safety properties of architecture interfaces to support 3 rd -party / regulatory review 2800 General Principles for Medical Device Interoperability 2800-X ICE Interoperability Architecture & Principles 2800-X-01 ICE Interface X-02 ICE Interface X-n ICE Interface n Define each interface in AADL (in separate implementation standard) and use Requirements Annex and Error Model Annex to specify details related to safety goals of compositional evaluation ICE Architecture

7 AADL for Medical App Language Use AADL as basis of a standardized component-based app language, and AADL tools as an app development environment that provides plug-ins for regulatory, certification activities e.g., top-level architecture of a collection of smart alarms for pulse oximetry monitoring ICE Architecture

8 AADL for Medical App Language Use AADL as basis of a standardized component-based app language, and AADL tools as an app development environment that provides plug-ins for regulatory, certification activities The Vision e.g., top-level architecture of a collection of smart alarms for pulse oximetry monitoring AADL-based app development environment for certified/regulated apps AADL Requirements Annex used to capture requirements AADL Error Modeling Annex applied to support safety arguments Library of faults from utilized devices, platform services that app for which app must demonstrate safety Integrated assurance case tool used to organize overall safety / security argument Other plug-ins to support hazard analysis, regulatory submission preparation Libraries of pre-certified app components

9 Data Modeling SpO2 is a Percent as defined below. Representation Range constraint Semantic interpretation via Nomenclature

10 Real-time and QoS Specification RT and QoS information is specified using the AADL property mechanism. The property mechanism is extensible, but AADL s standard property libraries include almost all of the properties that we believe that we will need.

11 RT Threading Properties This is a periodic thread dispatched at a specific period (specified below) Worst-case execution time The period at which the thread is dispatched and, once the dispatch occurs, the time by which the thread should complete.