View
225
Download
2
Category
Preview:
Citation preview
Architecture Principles and Certification Approaches for Medical Application Platforms
Support:
Funding provided by US National Science Foundation awards 0734204, 0930647, 0932289, 1065887 (Cyber-Physical Systems and FDA Scholar-in-Residence programs) and the NIH/NIBIB Quantum program
http://people.cis.ksu.edu/~hatcliff
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
Acknowledgements:
Health Care Involves A Variety of System Components
Information Systems
Sensors
Actuators
Sensor Data Displays
Clinical Protocols
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.
Clinicians
Patient !
Safety
Security
This Talk
! Clinical motivation for Medical Application Platforms (MAP)
! See also talks from Dr. Julian Goldman
! MAP Concept of Operations ! Integrated Clinical Environment – an
architectural standard for MAPs ! Regulatory paradigms for MAPs ! Challenging attributes of the MAP
vision ! AAMI/UL 2800 family of standards
for safety/security of interoperable medical systems
Challenges in enabling the concept of medical application platform – technical, standards, regulatory
Recent Commercial Systems
Devices Data Consumers
Display Gadgets
Medical Device Data Systems (MDDS) -- Data only flows from producers to consumers; data must be faithfully re-presented
EMR Databases
Integrating Data Streams
Devices Data Consumers
iAware Gadgets
Moving forward: aggregating data streams to create “smart alarms” that reduce nuisance alarms by triggering alarms only when multiple physiological parameters are in agreement, e.g., agreement in trends on ET CO2 as well as pulse ox SpO2
Fully leverage device data streams
Data Stream 1
Alarm Info
Data Stream 2 Nurse Station
Smart Alarm Logic
“Medical Device
Integration Platform
application (app)”
Why is it so hard to do this in the
health care space?
Safety Interlocks
Devices Data Consumers
Display Gadgets
Moving forward: aggregating data streams to solve systems problems by making devices context aware.
Fully leverage device data streams and the ability to control devices
Alarm Info
O2 Conc. Data
Laser Activation Data
Tracheal tube fire hazard -- caused by failure to reduce O2 concentration during tracheal laser surgery
Surgical Team
Laser Disable Command
Proposed and published by Sem Lampotang, PhD, Univ. of Florida -- not commercially available. Device coordination systems can provide a solution.
Safety Interlock
Logic
Disable laser if inspired O2 is > 25%.
From Dr. Julian Goldman -- MDPnP.
Just enforcing a system invariant!
Closed Loop Safety Interlock Example Use-Case: PCA Monitoring
! Patients are commonly given patient-controlled analgesics after surgery
! Crucial to care, but numerous issues related to safety
A 49-year old woman underwent an uneventful operation (total abdominal hysterectomy and bilateral salpingo-oophorectomy). Postoperatively, the patient complained of severe pain and received intravenous morphine sulfate in small increments. She began receiving a continuous infusion of morphine via a patient controlled analgesia (PCA) pump. A few hours after leaving the PACU [post anethesia care unit] and arriving on the flow, she was found pale with shallow breathing, a faint pulse, and pinpoint pupils. The nursing staff called a "code", and the patient was resuscitated and transferred to the intensive care unit on a respirator. Based on family wishes, life support was withdrawn and the patient died. Review of the case implicated a PCA overdose. Delayed detection of respiratory compromise in patients undergoing PCA therapy is not uncommon because monitoring of respiratory status has been confounded by excessive nuisance alarms.
Simple Closed Loop Control Motivating Clinical Problem: PCA Overdose
! “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.
! 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.“
Closed Loop Safety Interlock
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
Respiratory Rate Monitor
Pulse Oximeter
Monitoring Data + Alarm Information
Monitoring Data + Alarm Information
Aggregated Monitoring Status
Status Display for PCA Monitoring
Application
Clinician / Monitoring
See the paper for a number of other examples, many drawn from the ASTM Integrated Clinical Environment standard.
This Talk
! Clinical motivation for Medical Application Platforms (MAP)
! See also talks from Dr. Julian Goldman
! MAP Concept of Operations ! Integrated Clinical Environment – an
architectural standard for MAPs ! Regulatory paradigms for MAPs ! Challenging attributes of the MAP
vision ! AAMI/UL 2800 family of standards
for safety/security of interoperable medical systems
High-level presentation of issues related to architecture/regulation/standards – not specific technology solutions
Medical Application Platforms
! A Medical Application Platform is a safety- and security- critical real-time computing platform for… ! Integrating heterogeneous devices, medical IT systems, and
information displays via communications infrastructure, and ! Hosting applications (“apps”) that provide medical utility via the
ability to acquire information from and update/control integrated devices, IT systems, and displays
Bus EMR
Databases
Devices Displays Clinician Console
Computational Platform
Apps
Medical Application Platforms
…
An app with its connection topology (interfacing) to service components on the network.
App
Service Components
Logical interfacing between the app and services that it uses
Logical View -- Primary concepts in the programming model for the app developer
MAP Functional View
Network
A platform-based app for implementing a safety interlock by coordinating monitoring of vitals with pump control…
Pulse ox, respiratory rate monitor, infusion pump with hand-held control are connected to the patient.
Pulse Ox
PCA Pump
Respiratory Rate Monitor
Device Attachment
MAP Functional View
Map Supervisor
MAP App Library
Active Apps
App Launcher
Pulse Ox
PCA Pump
Respiratory Rate Monitor
Device Attachment
Map Manager
An app library holds apps that automate a variety of workflows including “closed loop” scenarios
“Begin monitored PCA infusion”
MAP Clinician Console
Clinician uses MAP Clinician console to select apps, and to interact with app during its execution
Network
A platform-based app for implementing a safety interlock by coordinating monitoring of vitals with pump control…
MAP Functional View
Map Supervisor
MAP App Library
Active Apps
App Launcher
Bus
Pulse Ox
PCA Pump
Respiratory Rate Monitor
Device Attachment
Map Manager
“Begin monitored PCA infusion”
MAP Clinician Console
An app may acquire exclusive access to relevant devices and sends/receives information to those devices during execution.
Acquired Devices
A MAP Supervisor module calls the app launcher to create instance of app classes and make pub/sub connections to the bus.
App is launched and added to the set of currently running apps.
A platform-based app for implementing a safety interlock by coordinating monitoring of vitals with pump control…
Variety of Applications
! Medical data display and storage
! Derived / Smart alarms ! Clinical decision support ! Workflow automation ! Safety interlocks ! Closed loop control
! Different degrees of regulatory scrutiny
! Possible determining factors… ! Intended use ! Devices read only ! Devices controlled…
! Only patient data set ! Static configuration of
monitoring/treatment parameters
! Dynamic configuration of monitoring/treatment parameters
Apps may provide a variety of clinical functions
Apps can be categorized according to criticality/risk
This Talk
! Clinical motivation for Medical Application Platforms (MAP)
! See also talks from Dr. Julian Goldman
! MAP Concept of Operations ! Integrated Clinical Environment – an
architectural standard for MAPs ! Regulatory paradigms for MAPs ! Challenging attributes of the MAP
vision ! AAMI/UL 2800 family of standards
for safety/security of interoperable medical systems
High-level presentation of issues related to architecture/regulation/standards – not specific technology solutions
Integrated Clinical Environment
! ASTM Standard F2761-2009 for ICE defines a high-level architecture and functional concept
! Subsequent standards are intended to provide specific functional and interfacing requirements for components
! ASTM F2761 is one of a collection of standards related to interoperability recognized by the FDA, and the only one of the collection that address architectural concerns
! ICE architecture standard is the focal point of multiple standards development effort in the medical device community (AAMI, UL)
Ice Equipment Interface (EI)
I1
Network Controller (NC)
Native EI-Compliant
Physical Device
Ice Equipment Interface (EI)
I3
EI Adapter
Physical Device
EI Adapter
Physical Device
App A1
App An
App A2
…
Supervisor
ICE EI Interface Description Language
ICE App Code Language / Virtual Machine
Supervisor Concept/Goals ! Provides virtual machine functionality
to host apps ! Application Program Interfaces (APIs)
for… ! clinical displays
! determining what devices are available on the network for apps to use
! exchanging data between apps/devices ! exchanging data between apps and EMR
and other health IT systems
! Services that allow apps to be notified when important system faults occur such as…
! unanticipated device disconnected ! failed or slow delivery of messages
between devices / apps
! Run-time checking to ensure that apps …
! are “well-behaved” ! don’t interfere with each other in
unanticipated ways
Ice Equipment Interface (EI)
I1
Network Controller (NC)
Native EI-Compliant
Physical Device
Ice Equipment Interface (EI)
I3
EI Adapter
Physical Device
EI Adapter
Physical Device
App A1
App An
App A2
…
Supervisor
ICE EI Interface Description Language
ICE App Code Language / Virtual Machine
Compare
Network Controller Concept/Goals ! High assurance network & services to
support communication between apps, devices, and health IT systems
! Often built using “publish/subscribe” middleware that provides virtual “information channels” with configurable security and performance
! Exposes the ICE interfaces of attached devices to apps
! Handles app requests to read/write to device interfaces with appropriate access/concurrency control
! Keeps track of devices on network and device connections and notifies associated apps when problems occur
! Manages the discovery and connection protocol of devices that desire to connect to the ICE
! Authentication ensures that only devices that have been previously certified as ICE compliant can connect/associate
Ice Equipment Interface (EI)
I1
Network Controller (NC)
Native EI-Compliant
Physical Device
Ice Equipment Interface (EI)
I3
EI Adapter
Physical Device
EI Adapter
Physical Device
App A1
App An
App A2
…
Supervisor
ICE EI Interface Description Language
ICE App Code Language / Virtual Machine
Note: several manufacturers are using RTI DDS in the Network Controller. See Joe Schlesselman’s (RTI) talk this afternoon.
Device Interfacing Technology
Ice Equipment Interface (EI)
I1
Network Controller (NC)
Native EI-Compliant
Physical Device
Ice Equipment Interface (EI)
I3
EI Adapter
Physical Device
EI Adapter
Physical Device
App A1
App An
App A2
…
Supervisor
ICE EI Interface Description Language
ICE App Code Language / Virtual Machine
Forensic Data Logger
“Meta-model”/ grammar for Device Interfaces (somewhat analogous to 11073 DIM)
Service Capability Description
! Physiological parameters (e.g., Pulse Rate, SpO2, etc.)
! Alarms/Alerts ! Device settings ! Device control functions
The Service Capability Description is a declarative machine-readable description of a service’s capabilities that are exposed over its network interface. Essentially, this is the description of the “logical” APIs that a service can offer to apps.
Capability description is
communicated to the Platform and when the service
associates
Pulse Oximeter as a Service
Domain Information
Technical Information (domain independent)
! Communication Patterns for accessing above info (e.g., pub/sub, request response)
! Quality of service and real-time constraints ! Role-based security controls ! Etc.
Application Hosting
Service Capability
Description
Medical Service Capability Description A declarative (ontology-oriented) description of a devices capabilities that will be exposed to platform-based medical apps
Model declares sensors and actuators of the device
Sensors provide one or more physiological data values
Source: “Modeling Medical Devices for Plug-and-Play Interoperability”, MS Thesis -- Robert Matthew Hofmann
ICE Device Model Concepts
For each data value, declare the communication idiom (e.g., poll, or periodic push)
Device Model provides a declarative (ontology-oriented) description of a devices capabilities that will be exposed to apps
Source: “Modeling Medical Devices for Plug-and-Play Interoperability”, MS Thesis -- Robert Matthew Hofmann
Data Logger Concept/Goals
Ice Equipment Interface (EI)
I1
Network Controller (NC)
Native EI-Compliant
Physical Device
Ice Equipment Interface (EI)
I3
EI Adapter
Physical Device
EI Adapter
Physical Device
App A1
App An
App A2
…
Supervisor
ICE EI Interface Description Language
ICE App Code Language / Virtual Machine
Forensic Data Logger
! As system executes, log… ! Data/commands exchanged between devices
and apps ! Important state changes in the system (e.g.,
device connect/disconnect, app launch) ! Faults/exceptional conditions
! Support forensic analysis of adverse events, security breaches, etc. via querying, replay, …
Note: standard for the data logger is being drafted over the next six months. Relates to concepts from the “Security Audit” in the MILS Platform Protection Profile (R. DeLong)
Authentication Framework
• Is the manufacturer valid?
• Has the service been tested to be platform-compliant?
• (if relevant) Has the service received regulatory approval for use within the platform?
• Does the service have a valid UDI and other appropriate credentials?
Before a service fully connects to the platform, we need to know…
Network Controller (NC)
Supervisor
Authentication Service
ICE App Code Language / Virtual Machine
App A1
App A2
App An
…
Device with Improper or no
credentials
Nellcor Pulse Ox
We need some automatic and irrefutable way to determine if
these conditions hold at the time of dynamic integration.
Service Authentication Framework
• When a service connects to platform, it provides proof that it is cleared for use in this context because:
• It is a instance of an certified model of service…
• …that was manufactured by an approved company…
• … which is the same company that received certification for the capability description, and…
• …the source of all of these assertions is an entity (root), already trusted by the system due to facility policies
Root Certificate
Manufacturer Certificate
Device Model Certificate
Device Instance Certificate
This concept is immediately and simply achievable using existing digital certificate technology, and is domain-independent. The challenge lies more in enforcing adoption by ecosystem/regulatory agencies.
Key Partitioning Properties
App A1
App An
App A2
…
Supervisor
A primary concept needed to support component-wise reasoning is partitioning – specifically, the platform/architecture needs to provide guarantees that there ALL interactions between hosted resources are limited to explicitly declared interfaces. This allows us to reason about the safety, e.g., of one app without having to worry about the actions of another apps.
Network Controller
Partitioning enables Composition
Network Controller (NC)
Supervisor
Device Model Interpreter
ICE App Code Language / Virtual Machine
Flexible / Dynamic partitioning provides foundations of non-interfering dynamic composition
GE Ventilator
WalkMed PCA
App A1
App An
…
…
Nellcor Pulse Ox
+ +
Non-critical Hospital IT
Traffic
Additional declarative policies for access control to shared devices
MIDAS – RT Middleware for MDCF
! Control low-level packet forwarding rules ! Install per-flow rate-limiters. ! Differentiate traffic in the
network. ! Learn physical location of
nodes in the network at runtime.
! Implement complex routing and QoS frameworks in a high level language
! Now a standard feature in many enterprise switches
! HP, NetGear, Juniper, Pronto, Brocade...
U Penn -- MIDdlware Assurance Substrate (MIDAS) – Andrew King PhD Work
! Provides timing guarantees and isolation in an open network built from COTS components
! A publish / subscribe middleware integrated with OpenFlow
King A., Chen S, Lee I. The MIDdleware Assurance
Substrate: Enabling Strong Real-Time Guarantees in
Open Systems with OpenFlow. ISORC 2014.
MIDAS – RT Middleware for MDCF
“I’llpublishECG@60hz” “IwantECG@>50Hzwithmaxlatencyof2ms”
MalfuncConingdevicetransmiHngoutofspec
Rate-limited@srcResourceManager
Formal Capability Description Language
! Domain-based description of capabilities
! E.g., using ontology-based organization
! Real-time / quality of service contracts
! Per-operation role-based security ! Formal behavioral specifications
! Pre/post-conditions ! Important service states/modes ! Constraints on temporal ordering of
operations
! Risk-related information ! Risk classification of parameters,
declaration of error propagation, fault mitigation
Needed: An appropriate formal capability description language is a linchpin technology for supporting virtual integration and CoD systems
Key Challenge: Capability language must be rich enough to support compositional reasoning about system function, safety, security but also be amenable to rapid/trustable verification of capability matching during run-time integration.
Technical Aspects of Composition-on-Demand Integration
…
App declares its requirements for devices, communication, execution. A Priori third-Party certification evaluates safety/correctness of app wrt those declarations.
App’s Supervisor Requirements
Scheduling Units Unit Periods, etc. Memory Requirements
App’s Network Controller Requirements (derived)
Bandwidth Latency, etc.
Clinical Data Control Functions QoS / RT Constraints Safety Modes Hazards Handled Access & Security Constraints
App’s Device Requirements
ICE Supervisor
ICE Network Controller
Technical Aspects of Composition-on-Demand Integration
…
App’s Supervisor Requirements
Scheduling Units Unit Periods, etc. Memory Requirements
Clinical Data Control Functions QoS / RT Constraints Safety Modes Hazards Handled Access & Security Constraints
App’s Device Requirements
Device Model
Clinical Data Control Functions QoS / RT Constraints Safety Modes Hazards Generated Access & Security Constraints
App’s Network Controller Requirements (derived)
Bandwidth Latency, etc.
Device declares its capabilities for supplying clinical data control functions, safety modes, QoS/RT properties. A priori third-party certification evaluates safety/correctness of device wrt those declarations.
ICE Supervisor
ICE Network Controller
Trust via Staged Checking
…
App’s Supervisor Requirements
Scheduling Units Unit Periods, etc. Memory Requirements
Clinical Data Control Functions QoS / RT Constraints Safety Modes Hazards Handled Access & Security Constraints
App’s Device Requirements
Device Capabilities
Clinical Data Control Functions QoS / RT Constraints Safety Modes Hazards Generated Access & Security Constraints
App’s Network Controller Requirements (derived)
Bandwidth Latency, etc.
At app launch time, platform services check to see whether platform and attached devices can satisfy requirements stated by the app. If so, app is launched. If not, app is not allowed to run.
Platform services provide dynamic checks/enforcement of interoperability and QoS constraints
ICE Supervisor
ICE Network Controller
Vision
FDA Evaluators
Assurance Case
3rd Party Certifiers
Risk Assessment
Hazard Analysis
Requirements
Clinical Use Case / Workflow Description
3rd Party ICE Conformance
& Safety Certification Submission Package
FDA 510K Submission Package
App Deployment
Medical Application Platform
Integrated Development and Verification Environment for Platform Apps
App Developer
Component-Based App Development in AADL
App Logic
Our current work is building an integrated development / certification environment for medical apps in Architecture and Analysis Definition Language (AADL) – originally from avionics community (heavily targeted to Integrated Modular Avionics (ARINC 653))
Heart Rate Trend
SpO2 Trend Rapid Decline Smart Alarm Logic
Supplementary Oxygen Smart Alarm Logic
See Peter Feiler: Virtual and Incremental Assurance of Critical Systems and also use of AADL on D-MILS (Rance DeLong)
AADL Formal Modeling of Error Sources, States, and Propagation
! AADL includes an Error Modeling language dedicated to modeling errors and propagation leading to hazards
! Provides the core of formal architecture-integrated risk management activities from which steps in common hazard analysis such as FEMA, FTA, can be automatically derived.
! Allows engineers to compositionally model aspects of system as it is experiencing faults failures.
! Necessary for supporting compositional approaches to system safety
Current risk management activities are highly manual and not well-integrated with formal development artifacts. CPS modeling environments need to provide automated formal support for risk management activities.
Error Source
Error State Machine (Failure modes)
Error Propagation
…leading to hazard
This Talk
! Clinical motivation for Medical Application Platforms (MAP)
! See also talks from Dr. Julian Goldman
! MAP Concept of Operations ! Integrated Clinical Environment – an
architectural standard for MAPs ! Regulatory paradigms for MAPs ! Challenging attributes of the MAP
vision ! AAMI/UL 2800 family of standards
for safety/security of interoperable medical systems
High-level presentation of issues related to architecture/regulation/standards – not specific technology solutions
Needed: New Regulatory Approach Current regulation of integrated systems (e.g., central station monitors) typically requires “pair-wise” clearance: whenever a new type of device is added to the monitoring platform, the entire infrastructure must be re-cleared.
X Y
+ Z
In current regulatory approach, adding a new type of device (e.g., Z) typically causes the entire system to be re-submitted for regulatory clearance.
Regulatory Clearance
Assume monitoring system was originally developed, verified, and received regulatory clearance for devices of type X & Y.
Needed: New Regulatory Paradigms
! In the current “pair-wise” regulatory approach, when adding a new app… ! …the scope of regulation would be the entire platform and
collection of service devices ! …i.e., set of all MAP instances and app would need to be
submitted for regulatory approval
Bus
Devices
Computational Platform
New App
Scope of regulation in a pair-
wise approach
Needed: New Regulatory Paradigms
! In the current “pair-wise” regulatory approach, when adding a new device… ! …the scope of regulation would be the entire platform and
collection of service devices ! …i.e., set of all MAP instances and device would need to be
submitted for regulatory approval
Bus
Devices
Computational Platform
Scope of regulation in a pair-
wise approach
New Device
Envisioned Compositional Paradigm
! In an envisioned “component-wise” regulatory approach, when adding a new device… ! …the scope of regulation would be the device and its MAP
interface ! Does it appropriately declare its capabilities? ! Does it appropriately declare hazards, safety-states? ! Does it appropriately implement the MAP networking protocols?
Bus
Devices
Computational Platform New Device
Scope of regulation
in a component-
wise approach
Envisioned Compositional Paradigm
! In an envisioned “component-wise” regulatory approach, when adding a new app… ! …the scope of regulation would be the just the app ! …the app specifies its requirements for devices and platform
capabilities (which would be checked by the platform at launch time) ! …the app regulatory submission provides an overall argument for
safety of the constituted device
Bus
Devices
Computational Platform
New App Scope of regulation
in a component-
wise approach
Component-Wise: Limits?
! FDA currently permits some notions of component-wise review ! Decisions made on an ad hoc basis ! No explicit statement of safety principles that justify when such an approach
can be taken ! Creates uncertainty in vendor space
! “Could I apply this to my product?” ! “What steps do I have to take to allow my product to be reviewed in this way?”
! Creates uncertainty for the regulator ! “What exactly do I look for in this submission?” ! “On what technical basis should I grant approval or deny approval?”
! Our research and activities in standards work are aiming to systematically enumerate the architecture, interface, risk management, V&V principles necessary to support component-wise review in interoperable systems
! …clarify when component-wise review should be allowed and when it should not be allowed
Currently the safety and engineering principles for determine when component-wise review can be applied (and when it should not be applied) are unclear
This Talk
! Clinical motivation for Medical Application Platforms (MAP)
! See also talks from Dr. Julian Goldman
! MAP Concept of Operations ! Integrated Clinical Environment – an
architectural standard for MAPs ! Regulatory paradigms for MAPs ! Challenging attributes of the MAP
vision ! AAMI/UL 2800 family of standards
for safety/security of interoperable medical systems
High-level presentation of issues related to architecture/regulation/standards – not specific technology solutions
Current Products Current connectivity products use proprietary interfacing and many limit components to those from a single vendor or limited collection of vendors
For example, Philips MP90 networked monitoring solution integrates with other Philips products in the IntelliVue line, or pulse oximeters from Masimo and Nellcor. Note: IntelliVue is not a MAP; it does not support app-based behavioral configuration.
MAP System Characteristics
! MAP should support components produced by different vendors ! Different quality management
systems ! Tension between accessible risk
management file and proprietary information
! Success of the MAP approach depends on individual vendors being willing to… ! Pursue interoperability as a business
strategy ! Conform to (envisioned) open
interfacing & safety standards
! Note: These goals may be scaled back to a smaller ecosystem, e.g., managed by a single vendor
MAPs should support interoperability with heterogeneous components
Bus
NellCor Pulse Ox
WalkMed PCA Pump
GE Respiratory Rate Monitor
Device Attachment
Dialing Back the Complexity
! Must scale back ! Reducing variability – Examples…
! App only runs on one platform implementation
! App only runs with “white listed” devices
! Limit the categories of devices supported
! Coarser-grained “pre-reviewed” interfaces, e.g., a standardized Pulse Oximeter interface
! Limit the set of manufacturers that provide devices for the platform
Implication: Emerging interoperability standards must acknowledge this complexity and provide engineering principles that help manufacturers constrain their systems to a point where current assurance techniques can provide sufficient assurance
! Manufacturers need to… ! Explicitly define their interoperability
architectures ! Describe where the “variabilities”
occur in their architecture/systems ! Describe how those variabilities are
managed in their quality/risk management and assurance approaches
This Talk
! Clinical motivation for Medical Application Platforms (MAP)
! See also talks from Dr. Julian Goldman
! MAP Concept of Operations ! Integrated Clinical Environment – an
architectural standard for MAPs ! Regulatory paradigms for MAPs ! Challenging attributes of the MAP
vision ! AAMI/UL 2800 family of standards
for safety/security of interoperable medical systems
High-level presentation of issues related to architecture/regulation/standards – not specific technology solutions
AAMI/UL 2800 Standards for Interoperable Medical Systems
! 2800 provides a framework of safety and security requirements that guide the design, risk management, and assurance of integrated clinical systems.
! 2800 establishes the framework of a minimum set of safety and security requirements for
! component interfaces and their implementations, ! safe/secure middleware and networking
infrastructure that facilitates integration, ! architectures that constrain the interactions between
components, and ! systems engineering for apps and component-
based systems built from platforms and interoperable components.
The Association for the Advancement of Medical Instrumentation (AAMI) and Underwriters Laboratories (UL) are developing the AAMI/UL 2800 family of standards to support the development and assurance of safe and secure interoperable medical systems.
Goals of AAMI / UL 2800
! Component safety claims in the context of system safety claims
! Components assembled within ! an architectural
framework that constrains interactions
! an organized ecosystem of stakeholders and processes that govern
! interactions between stakeholders
! contributions to systems
Safety / Security Requirements for Multi-vendor Interoperability Platforms
Safety and Security Requirements
Interoperability Ecosystem Interoperability safety standards must address ecosystems -- Supporting development of platform-based systems requires an ecosystem of cooperating stakeholders. Standards must provide frameworks for specifying and placing requirements on ecosystems including roles, responsibilities, processes, and allocation of assurance tasks across the ecosystem
Third-Party Testing/Certification Organization
Regulatory Authority
Service Suppliers Deployment Organizations (“Customers”)
App Developers
Platform Providers
Ecosystem Consortium
Ecosystem Concepts
! Stakeholder organizations develop and contribute components (along with assurance and risk management artifacts)
! Following processes coordinated with Ecosystem
! Requirements ! Design ! Implementation ! V & V ! Safety / Risk
Management ! Quality Management
Infrastructure/Technology Component Providers
Application Logic
Component Providers
Medical Equipment Component Providers
IT System Component Providers
Platform/Architecture Component Providers
Stakeholders contribute to and use artifacts from the Ecosystem
System Integrators
Stakeholders follow coordinated processes when developing artifacts / consuming artifacts from the Ecosystem
Concepts
Ecosystem Concepts
! Ecosystem Management can be a conventional business or a consortium
! Designs and manages the Ecosystem
! Development Processes ! Quality Management
Processes ! Risk Management Processes ! Architecture ! Interfaces
! Certifies that contributed artifacts are compliant with interfaces/architecture
! Certification tasks may be carried out by a third-party testing organization
! Establishes that Ecosphere components are trustworthy
! Gate-keeper role – prevents components that can’t interoperate correctly (and safely/securely) within Ecosystem
Infrastructure/Technology Component Providers
Application Logic
Component Providers
Medical Equipment Component Providers
IT System Component Providers
Platform/Architecture Component Providers
Stakeholders contribute to and use artifacts from the Ecosystem
System Integrators
Stakeholders follow coordinated processes when developing artifacts / consuming artifacts from the Ecosystem
Concepts Ecosystem Management
Organization
Ecosystem is managed by an collection of overarching processes, and artifacts contributed conform to reference architectures and interfaces
Architecture
Certification Organization
System Integration Process In other safety critical domains, there is a typically a prime contractor that is responsible for integration and system-level verification and validation.
! Integration is performed before deployment with full knowledge and behavior of components being integrated
! Integrator has expert-level technical knowledge of components & system behavior
! Responsible for overall system ! Verification & Validation ! Safety arguments ! Certification
System Integration Process
ConOps
Requirements
Design
Subsystems Implementation
Integration
Systems V & V
Deployment
In other safety critical domains, there is a typically a prime contractor that is responsible for integration and system-level verification and validation.
End to end process
managed by prime
contractor.
System integration and V & V is done before system is delivered to the customer.
Process-Driven Organization of Safety Standards
ISO 26262 (Automotive Safety) family of standards organized around the system development processes
Safety standards are often organized around the primary system development processes. The organization should lead to the accumulation of evidence for assurance of system safety
Implication: Over-arching efforts that address reference architectures supporting Composition-on-Demand systems must identify process structures for CoD ecosystems and describe how assurance responsibilities are allocated across those processes.
Development & Assembly
ConOps
Requirements
Design
Impl / V & V
App Developer Platform
Manufacturer
Service Component Manufacturer
Market
Deployment
System Assembly Performed by
deployment organizational (e.g., clinical staff)
App Execution (dynamic formation of
MAP constituted device) Performed by runtime environment of platform
Implication: Development and assurance process structures must be reworked to consider the different structure of MAP system construction (consider the difference in structure below).
Development & Assembly
Deployment
System Assembly
App Execution (dynamic formation of
MAP constituted device)
This is why the automatic integration performed by platform must be part of trusted computing base
Important Note: In contrast to conventional development, the people/organizations that put the physical pieces of the system together cannot/should not be considered “system integrators”
! Assembly is performed after deployment, e.g., at hospital ! Assembler does not have expert-level technical knowledge of
components & system behavior ! Distinguish between assembly and integration ! Integration is specified and assured a priori by app developer ! Integration is performed and integration constraints are enforced
automatically by the platform. ! Integration is a regulated activity; assembly should not be a
regulated activity (e.g. a hospital should not be considered a medical device manufacture just because they plugged components together)
Application/System Engineering
Integrated Clinical Systems
Use Assets to Build System – Develop application logic, select/configure components and interfaces, integrate into system, system-level risk management & assurance, regulatory submission
Clinical / System Requirements & Use Cases
Integrated Clinical System
Application Logic
Regulatory Artifacts
(“510(k)”)
Tests (Objective Evidence of Correctness)
Assurance Case
Domain and Application Engineering Two primary categories of development
Ecosystem Development Organizations engage in two distinct types of activities (concepts from Software Product Lines)
Domain Engineering
Reusable Assets
Engineered with reuse in mind -- Interface specifications, architectures, platform implementations, components, with associated risk management and assurance templates (partially instantiated)
Interfaces Specs
(Domain Info Model)
Architecture
Reusable Components
w/ Risk Management + Assurance
Test Suites
Assurance Case
Templates
Regulatory Templates
(“Master File”)
Motivation for 2800 Family Structure
! Generality -- Provide safety/security requirements that accommodate and are effective for
! Multiple architectures
! A wide variety of clinical scenarios/applications
! Architecture Specificity ! Component-wise review of safety-related properties in heterogeneous interoperable
systems cannot be achieved without defining the architecture within which components interoperate
! The architecture itself plays a key role in controlling potentially hazardous emergent properties by
! Constraining interactions between components ! Providing safety-related services that are used in the mitigation of common faults
! Application Specificity
! Hazards and top-level system safety constraints which typically drive the risk management process are application specific
! 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:
Example of Standard Refinement 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 override) general criteria
Collateral Standards call out specific aspects such as Usability, Alarms, etc. That can be applied when needed to specific devices (feature-oriented).
Proposed 2800 Structure
! Safety/Security and Essential Performance Objectives for interoperable systems
! Common vocabulary for referring to elements of interoperable systems
! General construction and architecture/interface specification requirements
! General risk management approach for interoperable systems
! Common fault types ! General requirements for
testing, verification and establishing compliance
! General approach for compositional assurance case construction for interoperable systems
2800-0 General
Requirements
Generality -- Capturing Architecture and Application Independent Safety/Security Requirements
Proposed 2800 Structure
2800-0 General
Requirements
! Components assembled within 2800 is set up to allow specific 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 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
Architecture Definition 2800 is currently using IEC/ISO 10746 – Reference Model for Open Distributed Processing (RM-ODP) to describe architectures. No existing framework is a perfect fit for this type of task. More work is needed in this area.
Proposed 2800 Structure
2800-0 General
Requirements
! Clinical scenario-specific standards capture architecture-independent ! clinical process safety requirements ! Safety-related data, control, state
requirements ! hazards ! recommended risk mitigations
! 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
Proposed 2800 Structure
2800-0 General
Requirements
! Safety/security requirements for a particular application on a particular architecture are derived from clinical scenario requirements and architecture requirements
! 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
Composition in MILS Architecture
The slide above is an excerpt from Rance Delong, John Rushby “A Common Criteria Authoring Environment”
The most prominent MILS goals have much in common with vision of 2800 – composition enabled by strong architecture, heterogeneous components, component requirements defined by specializations (protection profiles = 2800 particular requirements for architecture/components) of general requirements (Common Criteria = 2800 General Requirements)
Composition in MILS Architecture
The slide above is an excerpt from Rance Delong, John Rushby “A Common Criteria Authoring Environment”
The most prominent MILS goals have much in common with vision of 2800 – composition enabled by strong architecture, heterogeneous components, component requirements defined by specializations (protection profiles = 2800 particular requirements for architecture/components) of general requirements (Common Criteria = 2800 General Requirements)
Defines architectural constraints – analogous to ICE Architecture 2800 Particular Requirements.
Defines requirements for application hosting – analogous to ICE Supervisor 2800 Particular Requirements.
Defines requirements for real-time network communication – analogous to ICE Network Controller 2800 Particular Requirements.
Composition in MILS Architecture
The slide above is an excerpt from Rance Delong, John Rushby “A Common Criteria Authoring Environment”
The graphic below illustrates the instantiation structure (moving from concepts analogous to General Requirements, to Particular Requirements, to specific products to be evaluated) from MILS/CC that would be very similar to what is envisioned for 2800.
Composition of a system (safe interoperability) with components from different vendors
CC = 2800 General Requirements
CC Protection Profiles = 2800 Particular Requirements, e.g., for different ICE components
CC Security Target = 2800 submission for evaluation describing how a particular vendor’s component satisfies 2800 Particular Requirements.
CC SK1 = ICE Supervisor implementation from a particular vendor.
Conclusion ! Medical Application Platforms provide an approach for building
interoperable medical systems ! Potential to significantly impact the way that medical systems are built and
deployed ! Broader technology arena is gravitating toward platform approaches (e.g.,
consumer telephony, automotive, industrial internet, etc., etc.)
! New component-wise and re-use oriented risk management, assurance, and regulatory reviews processes are needed to support this paradigm
! Clearly specified and illustrated system engineering principles are needed to judge what should be allowed and disallowed
! The LAW community is developing concepts that can apply here, and a multi-domain collaboration and vision would be beneficial to all
! AAMI/UL 2800 is attempting to set up a certification framework for these types of systems, and there is significant overlap with directions in the CC/MILS space
References ! "Certifiably Safe Software-Dependent Systems: Challenges and Directions", John
Hatcliff, Alan Wassyng, Tim Kelly, Cyrille Comar, and Paul Jones. Future of Software Engineering, 2014 International Conference on Software Engineering (ICSE 2014)
! "Rationale and Architecture Principles for Medical Application Platforms”, John Hatcliff, Andrew King, Insup Lee, Alisdair Macdonald, Anura Fernando, Michael Robkin, Eugene Vasserman, Sandy Weininger, Julian Goldman., Proceedings of the 2012 International Conference on Cyber-Physical Systems, pp. 3-12, April, 2012
! "Ecosphere Principles for Medical Application Platforms", Yu Jin Kim, Sam Procter, John Hatcliff, Venkatesh-Prasad Ranganath, Robby, Proceeedings of the 2015 International Conference on Healthcare Informatics (ICHI) pp. 193-198, October 2015
! “An Architecturally-Integrated, Systems-Based Hazard Analysis for Medical Applications.” Sam Procter, John Hatcliff. Proceedings of the International Conference on Formal Methods and Models for System Design (MEMOCODE 2014), October 2014
! “Architectural and Assurance Principles for Safety-Critical Composition-on-Demand Systems”, John Hatcliff et al. (forthcoming)
Recommended