architecture principles and certification approaches for medical

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


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


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







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


Device Attachment

MAP Functional View

Map Supervisor

MAP App Library

Active Apps

App Launcher

Pulse Ox

PCA Pump


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


MAP Functional View

Map Supervisor

MAP App Library

Active Apps

App Launcher

Bus

Pulse Ox

PCA Pump


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.


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








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


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


I1


Native EI-Compliant

Physical Device


I3

EI Adapter

Physical Device

EI Adapter

Physical Device

App A1

App An

App A2

…

Supervisor



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


I1


Native EI-Compliant

Physical Device


I3

EI Adapter

Physical Device

EI Adapter

Physical Device

App A1

App An

App A2

…

Supervisor



Note: several manufacturers are using RTI DDS in the Network Controller. See Joe Schlesselman’s (RTI) talk this afternoon.

Device Interfacing Technology


I1


Native EI-Compliant

Physical Device


I3

EI Adapter

Physical Device

EI Adapter

Physical Device

App A1

App An

App A2

…

Supervisor



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


I1


Native EI-Compliant

Physical Device


I3

EI Adapter

Physical Device

EI Adapter

Physical Device

App A1

App An

App A2

…

Supervisor



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…


Supervisor

Authentication Service


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


Supervisor

Device Model Interpreter


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

…





Device Model

Clinical Data Control Functions QoS / RT Constraints Safety Modes Hazards Generated Access & Security Constraints



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


Trust via Staged Checking

…





Device Capabilities

Clinical Data Control Functions QoS / RT Constraints Safety Modes Hazards Generated Access & Security Constraints



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


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








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


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


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


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








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








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


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


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.


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


(ICE)




2800-2-1 PCA Infusion Monitoring

2800-2 Process for introducing

clinical scenarios 2800-2-2


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


(ICE)




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)



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.



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)

architecture principles and certification approaches for medical

Documents