complexity reduction for cyber-physical-human medical systems

Low Complexity System Designs for

Medical Cyber-Physical-Human Systems

(CPHS)

Po-Liang Wu

University of Illinois at Urbana-Champaign

Ph.D. Preliminary Examination, May 2014 1

2

The size and complexity of cyber-physical systems have increased

significantly.

“These advances have not only made it possible to reach the

frontier faster; they have also increased by orders of magnitude the

levels of complexity open to exploration and experimentation.

Understanding complexity and learning how best to harness these

new capabilities are both a challenge and a responsibility.”

NSF Strategic Plan, September 2006

Control & Harnessing Complexity of

Cyber-physical Systems

Introduction

Medical systems are both safety-critical and highly complex and our

goal is to have a formally verifiable safe system in spite of the

complexity, using the approach recommended by National

Academic Science:

• “One key to achieving dependability at reasonable cost is a serious and

sustained commitment to simplicity, including simplicity of critical

functions and simplicity in system interactions. This commitment is often

the mark of true expertise”

Thus, we must understand the sources of complexity and their

interactions in medical systems.

3

Goal: reduce and control complexityComplexity control is to control the interactions between the system

components, for example, preventing the non-safety-critical components

propagates the faults to the safety-critical components and cause failure of

the whole system.

Motivation – Complexity and Interactions

4

High mental workload increases the likelihood of medical errors

The medical errors may cause severe complications.

The degradation of patient conditions further increases the cyber-physical complexity

Physical complexity: more medical devices must be added to

handle the complications, more treatments must be performed

Cyber complexity: more exception handling routines must be

performed, more device interactions must be checked, etc

Further increases the human mental workload.

Dimensions and Measurements of Complexity

From a computer science perspective, complexity reflects the workload of performing tasks by measuring number of steps or elapsed time.

Computational complexity• Worst-case time requirements as a function of the size of its input (most usefully, in

terms of the O-notation)

Verification complexity• Measures the state space to verify the system properties.

Cyber medical treatment complexity• Measures the number of steps to perform a treatment at run-time.

Mental workload complexity• Measures human memory and mental computation demand for performing tasks.• It can be measured by task completion time, accuracy, NASA-TLX, etc.

Other complexity

5

Major Sources of Complexity

Sources of verification complexity• Message interleaving due to asynchronous communication

• Inconsistency of distributed system states due to race conditions

Summary: The combinatorial possible execution sequences and message interleaving must be checked.

6

Communication Patterns (Remote Procedure Call)

Supervisor Child device

C1

Async

C2

R1


C1

Sync

C2

R1

R2

7

• Maximum flexibility

• Easily cause state space explosion

• Low complexity

• Too restrictive

State Space Explosion

8

msg queue size

1 2 3

# states 2336 122394N/A

(out of memory)

Model checking state space Count total number of states

Node A Node B

msg3 msg2 msg1

Channel objectFSM object FSM object

Size = 3

msgA msgB msgC

Channel object

The number of states is the Cartesian product of the states of node A,

node B, and the communication channels.

In our experiment, the state space quickly explodes as the more

message interleaving is allowed.


Sources of cyber medical treatment complexity

• Medical staff need to validate preconditions, monitor side effects, and check patient responses when performing a treatment

• Incorrectly performing a treatment may cause severe medical complications.

9

ActivateDefibrillator

Rhythm == Shockable

InjectEPI

BloodPH > 7.4

UrineFlow> 12 mL/s

Inject-SodiumBicarbonate

Airway & Breathing

Treatment

Preconditions


Sources of cyber medical treatment complexity

• Medical staff need to validate preconditions, monitor side effects, and check patient responses when performing a treatment

• Incorrectly performing a treatment may cause severe medical complications.

10

ActivateDefibrillator

Rhythm == Shockable

InjectEPI

BloodPH > 7.4

UrineFlow> 12 mL/s

Inject-SodiumBicarbonate

Airway & Breathing

AssistedVentilation

The side effect

of bicarbonate

may adversely

affect patient’s

breathing.

Urine flow rate

may become

lower than 12

due to kidney

function

degradation.

IncreaseIVFluid


Sources of mental workload complexity• Physicians and nurses are unable to mentally keep track of physiological

measurements minute by minute.

• Most physicians can mentally correlate a small number of variables at a time but unable to correlate many variables in depth.

• Unorganized and lack of context-dependent information» Context is a set of state variables, such as patient’s organ status and current medical

procedure.

» Context information is important for physicians and system to validate treatments and trigger alarms.

Summary: Physicians must memorize and correlate tremendous information, which significantly increases their mental workload.

State of the current medical practice

11

https://uofi.box.com/s/b4k7syjrf21h1v3qd7mh

Background – Existing Complexity Reduction Methodologies and Mechanisms

Verification complexity• Model checking techniques

» Abstraction» Partial-order reduction

• System design» Atomic Transaction/Serializability» Physically Asynchronous Logically Synchronous (PALS) architecture» Simplex Architecture

Cyber medical treatment complexity• Machine learning, expert systems• Closed-loop supervisory control

Mental workload complexity• Integrated display systems to improve situation awareness• GOMS(Goals, Operators, Methods, and Selection rules) model

12

Technical Challenges

Concurrency related complexity• C1. In CPHS, asynchronous communication is commonly used due to

interrupts and exceptions.» Ideas: Communication protocol to limit the possible message interleaving but still

provide adequate flexibility.

» Preliminary result: Interruptible Remote Procedure Call protocol

• C2. Concurrent control of distributed devices and controllers result in complicated race conditions.

» Ideas:

– Architecture design to separate the concerns of controllers

– Communication protocol to prevent conflict race conditions

» Preliminary result: Hierarchical organ-based architecture, Consistency protocol

• Summary: Proposing run-time control protocols to reduce unnecessary or inconsistent interleaving due to concurrency.

13


C3. Medical complications due to incorrectly performed treatments.• Ideas: Validate treatments in respect of preconditions, side effects,

and expected responses• Preliminary result: Treatment Validation Protocol

C4. Situation awareness improved display and assistance system.• Ideas:

» Integrated display of physiological measurements, treatment status, and medical records.

» Workflow-driven context information.

• Work in progress: Workflow navigation and guidance system

14

https://uofi.box.com/s/0g98lk528ctzh4kqfnk5


C5. Deviation from the best practice guidelines• Ideas:

• Work in progress: » A protocol to adapt the workflows when deviation is detected in

collaboration with medical staff.

» Source code verification of the developed protocol using CBMC, which is a Bounded Model Checker for C/C++ programs.

15

Hard (safe-critical) deviation Soft (non-safety-critical) deviation

System controllable Automatically forbid a. Stop onceb. Request for confirmation c. Adapt the workflow

Not system controllable Flag the deviation and disengage

a. Flag the deviationb. Adapt the workflow

REDUCING VERIFICATION COMPLEXITY: INTERRUPTIBLE RPC ARCHITECTURAL PATTERN

16

H. Yun, P.-L. Wu, M. Rahmaniheris, C. Kim, and L. Sha. A reduced complexity design pattern for distributed hierarchical command and control system. In Proceedings of the 1st ACM/IEEE ICCPS, pages 42-49. ACM, 2010.

Communication Patterns


C1

Async

C2

R1


C1

Sync

C2

R1

R2

Supervisor

C1

stop

Interruptible

R1partial

Child device

C2

stopR2

17

• Maximum flexibility

• Easily cause state explosion

• Maximum complexity reduction

• Too restrictive

• Control asynchronous interactions in terms of mesage passings.

• Allow bounded asynchronous interrupt and make the system back to synchronous

• The increase of state space is also bounded

Init

B1

Next

cmd!

F_Result?

Ready

Exe

cmd?F_Result!

stop?

B2stop!

stop?Supervisor Child Device

FSM Definition of Interruptible RPC Pattern (Normal Case)

18

P_Result!cmd

P_R

stop

Init

B1

Next

cmd!

F_Result?

Ready

Exe

cmd?F_Result!

stop?

B2stop!

stop?Supervisor Child Device

FSM Definition of Interruptible RPC Pattern (Interleaving Handling)

19

P_Result!

F_R

stop

Evaluation

Simplified distributed command & control system

• One manager and one or more child devices

• Modeling using Maude, a model checking tool

Evaluation Strategy

• Compared Maude models following different patterns: synchronous, interruptible, asynchronous RPC

• Varied number of child devices in the model

• For asynchronous RPC, we also varied maximum queue size.

20

Evaluation

#child

devices

sync Interrup

tible

async(2) async(3

)

async(4) async(5

)

1 5 29 70 121 195 275

2 11 133 1410 4426 11816 23732

3 22 701 28691 184418 782417 N/A(*)

21

State space (# states)

#child

devices

sync Interrup

tible

async(2) async(3

)

async(4) async(5

)

1 0 1 4 7 12 275

2 1 13 160 549 1571 23732

3 1 120 6586 49307 1096480 N/A(*)

Model checking time (msec)

(*) not finished in 12 hours

Summary

Distributed command & control system model• Interleaving problem

• State space explosion problem

Interruptible RPC design pattern • Allow asynchronous interruption

• Reduces state space for model checking

However, this work does not address exception handling issues.• Child devices may actively send exceptions due to unexpected events,

hardware failure, etc.

22

REDUCING VERIFICATION COMPLEXITY: A LOW COMPLEXITY COORDINATION ARCHITECTURE

23

P.-L. Wu, W. Kang, A. Al-Nayeem, L. Sha, R. B. Berlin Jr, and J. M. Goldman. A low complexity coordination architecture for networked supervisory medical systems. In Proceedings of the 4th ACM/IEEE ICCPS, pages 89-98. ACM, 2013.W. Kang, P.-L. Wu, M. Rahmaniheris, L. Sha, R. B. Berlin, and J. M. Goldman. Towards organ-centric compositional development of safe networked supervisory medical systems. In Computer-Based Medical Systems (CBMS), 2013 IEEE 26th International Symposium on, pages 143-148. IEEE, 2013.

State of the Art Medical Systems

Integrated Clinical Environment (ICE) infrastructure is logically

centralized control system.

• The medical devices are coordinated by a single ICE supervisor controller.

24

http://www.mdpnp.org/

Motivating Example –

A Laparoscopic Surgery A camera is inserted into the

patient’s abdomen and the CO2 is

pumped into the abdomen to create

a space for surgery.

The ventilator can be programmed

to compensate the SpO2 level

within the limits set by physicians

• Such as tidal volume, respiratory

rate, FiO2

Excessive CO2 pressure may

inhibit the breathing volume and

result in low SpO2 level.

25Extreme pressure would collapse the vena cava/hepatic vein and cause the shock.

CO2

pump

Monitor

scalpel

http://images.google.com

Inconsistent Views and Actions May

Cause Safety Hazard SpO2 sensor raises a patient

adverse events (PAE), caused by SpO2 level lower than the threshold set by the physicians

ICE supervisory controller requests to decrease CO2 pump pressure without knowing the status of the surgical process.

Decreasing CO2 pressure might cause insufficient operating space and a safety hazard.

Multiple devices coordination is essential to avoid safety hazards

26

Laparoscopic Surgery

ICE

Supervisory

Controller

CO2

PumpSpO2

Sensor

Oxygen

Saturation

Low

Decrease

Pressure

Video

Camera

Operating

Space

Safety

Hazard

Complexity of Asynchronous

InteractionHierarchical Layers Asynchronous Design

State space Time (s)

Two Layers 12084 3

Three Layers 603056 143

Four Layers Out of memory Out of memory

27

Complex interaction in medical systems can easily occur due to

patient adverse events (PAE) and cause state space explosion.

Hierarchical Organ-system

Architecture Medical Devices Layer

• Medical devices report the

physiological measurements

and raise PAEs

Organ System Control Layer

• It is responsible for stabilizing

an organ-system by

coordinating the devices.

• If a PAE can be locally

compensated, the organ-

system controller will handle it

• Otherwise, the PAE must be

propagated to the high-layer

controller.

28

SpO2 low

Cmd


Architecture Surgery and Anesthesia

Control Layer

• Surgical and anesthetic

controller are responsible for

inter-organ system

coordination.

• The anesthetic controller is the

primary controller for

anesthesia related events.

• The surgical controller focuses

on handling surgery related

events.

29

SpO2 low

Cmd


Architecture Benefits

• It naturally fits into the ICE infrastructure and enables localized PAE

handling. If PAEs can be handled by different subtrees, the higher level

controllers are not interfered.

• Capture human homeostasis. (An organ system can compensate

moderate abnormalities without interfering other organ systems)

Engineering challenges

• Localized PAE handling may introduce message races to the controllers

of different layers.

• A communication protocol is required to guarantee consistency.

30

Consistent View Generation and

Coordination (CVGC) Protocol

• Design goals: » The protocol ensures each controller has all its child nodes’ status.

» Avoid conflict race conditions

• The device setting is locked during the consistent view

generation to avoid inconsistency.» Each device and controller has a lock to protect its setting.

• A controller can send commands to change the device

settings if and only if it holds all its child devices’ locks.

31

Like traditional locking mechanisms, such as tree locking, the

proposed protocol aims to prevent race conditions that may cause

safety hazards.

Unlike traditional locking mechanisms, the system needs to handle

both top-down and bottom-up message races.



The CVGC protocol has

three phases

• PAE propagation phase

• Locking and consistent

view generating phase

• Command execution and

unlocking phase

32

Ca

Cb

PAE1&CV&

LockSet




three phases





unlocking phase

33

Ca

Cb

PAE1&CV&

LockSet

Cc

lockAndReport

lockAndReport

lockAndReport message is used for locking a subtree and

gathering the consistent view.

A controller can send a command to change device settings if

and only if the lockAndReport is processes and the controller

receives the locks and consistent view.




three phases





unlocking phase

34

Ca

Cb

PAE1&CV&

LockSet

Cc

CV&

LockSet

CV&

LockSet

After processing the lockAndReport message and gathering

consistent view and locks, Cb can send a command to change

its child devices’ settings.

Race Condition Handling

A race condition occurs when

lockAndReport message is propagated

downward while another PAE2 is

propagated upward.

When Cc receives PAE2, its child

devices’ settings have been locked.

Therefore, Cc does not need to further

propagate the lockAndReport message.

Cc sends PAE2&CV&LockSet to Cb.

Cb has the consistent view and all the

locks.

How to handle multiple PAEs is pre-

specified by the physicians.

35

Ca

Cb

PAE1&CV&

LockSet

CcPAE2&CV&

LockSet

lockAndReport




three phases





unlocking phase

36

Ca

Cb

Cc

Cmd

CmdCmd

Cmd

If Cb can handle PAE, it sends the command to change the

device settings and release the locks.

Correctness of the CVGC Protocol

Model checked architectural properties

• CVGC protocol is deadlock free.

• A controller can send a command iff it receives the consistent view and

the locks.

• The locking mechanism prevents multiple controllers command the

same device simultaneously.

Timing analysis

• µ: message transmission delay

• WCET: worst case execution time

37

Complexity Evaluation

Verified safety properties

• The pulmonary controller will increase the respiratory rate of the

ventilator when the SpO2_low PAE is received if the respiratory rate is

below the maximum rate. (Layer 2)

• If the surgery is at a critical point, the supervisory controller should not

allow a reduction of the laparoscopic CO2 pump pressure. Instead, an

alarm must be issued to the physicians. (Layer 4)

38

Hierarchical Layers Metrics Proposed Design Asynchronous

Two Layers Number of states 1887 12084

Checking time (s) <1 3

Three Layers Number of states 10651 603056

Checking time (s) 2 143

Four Layers Number of states 21888 Out of memory

Checking time (s) 8 Out of memory

Summary

Reducing verification complexity by proposing:

• Hierarchical organ-system architecture

» Capture human homeostasis

» Allow distributed patient adverse events handling

• Consistent view generation and coordination protocol

» Gather concise and comprehensive physiological information

» Low complexity compared to asynchronous design.

39

REDUCING CYBER MEDICAL TREATMENT

COMPLEXITY: A TREATMENT

VALIDATION PROTOCOL

P.-L. Wu, D. Raguraman, L. Sha, R. B. Berlin, and J. M. Goldman. A treatment validation

protocol for cyber-physical-human medical systems. To appear In Software Engineering and

Advanced Applications (SEAA), 2014 EUROMICRO Conference on.

40

Introduction and Technical Challenges

Timely and correctly perform treatments while monitoring patient

responses is critical for patient safety.

Treatment validation is essential and consists of three aspects

• Precondition

» A treatment can be performed only if the preconditions are satisfied

• Potential side effects

» The side effects of a treatment may adversely affect other treatments or

invalidate previously satisfied preconditions

• Expected patient responses

» The effectiveness of a treatment is non-deterministic

The purpose of this work is to assist medical staff to correctly

perform treatments rather than automatically performing treatments.

41

Like traditional cyber validation mechanisms, the proposed protocol

guarantees certain preconditions are satisfied before taking actions.

Unlike traditional cyber validation mechanisms, the proposed protocol

may not have the full control of physical components, such as patient

conditions.

Cardiac Arrest Resuscitation –

State of the Art Practice

42

Supervisory System

User Interface

Defibrillator

Airway Breathing

satisfactory

Rhythm Non-

Shockable

1. Activate defibrillator

2. Check Airway & EKG Rhythm

Epinephrine

BloodPH< 7.4

Urine < 12 mL/s

3. Inject epinephrine

4-a. Check preconditions4-b. Request corrective treatments

Performing Treatments

Sodium Bicarbonate

6. Post order execution

Sodium Bicarbonate

No Calcium Chloride

Increase IV Fluid

5. Sodium bicarbonate & Increase IV

Airway Breathing is affected

BloodPH < 7.4

Sodium Bicarbonate

No Calcium Chloride

7. Side effects adversely affect preconditions

8. Patient responses not as expected

9. Exceptions 10. Alternative Treatment

Assisted Ventilation

43

Correctness

Theorem 1. (Preconditions satisfaction) Under the proposed protocol, a treatment is performed only if all preconditions of the treatment are satisfied.

Definition: A tree is well-formed if each unsatisfied precondition have a tree node for correcting it.

Theorem 2. (Tree Traversal) The root node of a well-formed tree is reachable if the corrective treatments are effective and the preconditions are not invalidated by the side effects.

Theorem 3. (Dynamic adaptability) Suppose side effects of a treatment invalidate any precondition and make the tree become non-well-formed. The protocol updates the tree to be well-formed if the medical staff correctly specifies the corrective treatments.

44

Verification

Medical safety

properties

P1: Defibrillator is activated only if the rhythm is shockable and airway

and breathing is under control.

P2: Epinephrine is injected only if the blood pH value is larger than 7.4

and urine flow rate is higher than 12 mL/s.

P3: If the side effect of sodium bicarbonate adversely affects the

breathing, the tree is updated with a new treatment node for assisted

ventilation.

Protocol correct

ness properties

P4: There is no deadlock in the system.

P5: A treatment is performed only if all its preconditions are satisfied.

P6: If side effect does not occur, the root node of the tree is added to

the executing list

P7: If side effects invalidate a precondition, the tree is updated to be

well-formed.

45

Summary

In order to reduce cyber medical treatment complexity, a validation

protocol is proposed to

• Check preconditions

• Monitor potential side effects

• Check expected responses

We use a model checking tool to verify both safety and correctness

properties.

46

OUR FUTURE PLAN

47

REDUCING MENTAL WORKLOAD

COMPLEXITY:

WORKFLOW NAVIGATION AND GUIDANCE

DISPLAY SYSTEM FOR IMPROVING

SITUATION AWARENESS

48

State of Current Research

(Main focus) Lack of context-dependent information and lack of

adaption ability to the dynamic context changes

Context-dependent information

• Context is a set of state variables, such as patient’s organ status and

current medical procedure.

• Context information is important for physicians and system to validate

treatments and trigger alarms.

Our system organizes the context information and adapts to the

context changes according to the medical workflow

49

Medical Workflow

Medical workflow intends to capture the best practice to assist

medical staff to diagnose and treat patients.

American Heart Association (AHA) provides a family of resuscitation

workflows for different life-threatening heart rhythms, including

ventricular fibrillation, asystole and tachycardia, etc.

The purpose of the developed system is to assist medical staff to

synchronize the team actions to the workflow in real-time by

• codifying the best practice medical workflows

• keeping track of the workflow steps

• flagging deviation from the workflow

• highlighting the real-time progress of the treatments, the status of the

treatments, and the patient’s physiological responses

50

Organ system states

• Asystole

• Tachy.

• …

• Asystole WF

• Tachy WF

• …

Codified workflows

• HR

• BP

• ECG rhythm

• …

Physiological

measurements

51

Drug

guidelines

Treatment

workflow

Workflow Manager

Medical Device

Configuration Management

Resuscitation Monitoring System

Device Interoperability

Head Nurse

52

Situation Awareness Display

Treatment validation

Workflow Configuration

Physicians

The images are from http://www.pacificu.edu/pa/

Microsoft Surface

Evaluation: Comparison

Vital signs only display

Vital signs + workflow

Vital signs + workflow + treatment validation status

Compare to different iterations of our design

• Features added in iterations

» Automatically generate medical records

» Confirmation of drug order and given

53

Evaluation: Candidate Metrics

Response time to a simulated event

Accuracy(# of errors) of the performed actions

Memory demand

NASA-TLX

Other questionnaire

• Proper abstraction of workflows

• Usefulness of treatment validation

• Meaningfulness of the alarms

54

Deviation from the Workflow

Hard (safety-critical)

deviation

Soft (non-safety-

critical) deviation

System controllable Automatically forbid a. Stop once

b. Request for

confirmation

c. Adapt the workflow

Not system controllable Flag and disengage a. Flag the deviation

b. Adapt the workflow

55

• Adapt the workflow after the deviation is detected in collaboration

with physicians.• Simply switch to a new workflow may not work.

• For example, patient is injected certain drug that will cause severe

adverse interactions with another drug required in the new workflow.

Source Code Verification

In my previous work, verification is performed at model design level.

In order to guarantee correctness and safety of the developed

system, verification must also be performed at source code level.

We are currently re-engineering the system architecture to separate

safety-critical and non-safety-critical software components.

• For the safety-critical components and their interaction protocols, we will

use CBMC, which is a Bounded Model Checker for C/C++ programs, to

fully verify the safety and correctness properties.

• For the non-safety-critical components, we will develop test suites to

increase code coverage.

• The safety-critical components only use but not depend on the non-

safety-critical components.

56

Published Work and Future Plans

Published work

• P.-L. Wu, W. Kang, A. Al-Nayeem, L. Sha, R. B. Berlin Jr, and J. M. Goldman. ‘A low complexity coordination architecture for networked supervisory medical systems.” In: Proc. ICCPS’13.

• P.-L. Wu, D. Raguraman, L. Sha, R. B. Berlin, and J. M. Goldman. “A treatment validation protocol for cyber-physical-human medical systems.’ To appear in EUMIRCRO SEAA’14.

• H. Yun, P.-L. Wu, M. Rahmaniheris, C. Kim, and L. Sha. “A reduced complexity design pattern for distributed hierarchical command and control system.’ In: Proc. ICCPS’10.

• W. Kang, P.-L. Wu, M. Rahmaniheris, L. Sha, R. B. Berlin, and J. M. Goldman. “Towards organ-centric compositional development of safe networked supervisory medical systems.’ In: Proc. CBMS’13.

Plans for publication

• “A workflow navigation and guidance system for improving situation awareness”, targeting CHI’15

• “An adaptive protocol for handling deviations from the medical workflows”, targeting ICCPS’15

57

Conclusion

Reduce and control complexity in respect of

• Verification complexity

• Cyber medical treatment complexity

• Mental workload complexity

We have developed

• interruptible RPC and consistent coordination protocol to reduce

verification complexity.

• treatment validation protocol to reduce treatment complexity

We are developing workflow navigation and guidance system for

reducing mental workload complexity.

58

Additional Slides

59

Model-based Engineering

Model-based engineering is a system development methodology

which exploits the reusable models in order to reduce complexity.

However, reusing a model during system integration requires

• the assumptions or preconditions of each integrated model are fully

checked and satisfied

» For example, Ariane 5's accident was due to the violation of assumption of

maximum horizontal speed.

• the interactions of the models are thoroughly verified against potential

unsafe interactions

» For example, the surgical fire during an airway laser surgery is due to unsafe

interactions between laser scalpel and ventilator.

60

Design Patterns for Workflow

Navigation and Guidance Systems We identified several design patterns

• Real-time treatment: Certain treatments must be continued or separated

for a time interval

» For example: CPR must continue for at least 2 minutes and epinephrine

should be given every 3~5 minutes

• Physiological conditions: the preconditions, side effects, and patient’s

responses of the treatments can be described as physiological

conditions, such as blood pressure > 120

In addition, we provide verifications for both model design and C

code implementation levels using UPPAAL and CBMC (Bounded

Model Checker for C/C++).

61

62

Interleaving Problem Model ohecking

R: in case of no pending msg, MSMGR, SSMGR and SS must be in the same state

(track or scan)

Maude> search (init,off,off,none,none,none,none) =>+ (targeting,airscan,airscan,none,none,none,none ) .

Solution 1 (state 136)

states: 137 rewrites: 261

Maude> show path label 136 .

MM_takeoff

MM_takeoff_waypoint

MM_waypoint_patternsearch

SM_off_airscan

MM_patternsearch_abort

SS_off_airscan

SS_airscan_airtrack

SM_airscan_airtrack

SM_any_off

MM_abort_waypoint

MM_waypoint_patternsearch

MM_patternsearch_targeting

SS_any_off

SM_off_airscan

SS_off_airscan

MSMGR SSMGR SS

waypoint

abort

waypointpattern

targetting

airscan

airscanairtrackairtrack

off

airscan airscan

inconsistency

scanAir

scan_air

track

track scanAiroff

stop

stop

UPPAAL Model for Pulmonary

Controller

63

UPPAAL Model for Pulmonary

Controller

64

PAE propagating

Cmd executing and unlocking

Locking and consistent view generating

phase

System Models and Definitions

PhysiologicalCondition (PC) is defined as a tuple < Checker, PM, Operator, RV >, where

• Checker is the entity capable of checking the, Checker ∈{System, MedicalStaff},

• PM (physiological measurement) ∈ {EKGRhyhtm, HeartRate, BloodPressure...},

• Operator ∈ {>, <, =, ≤, ≥},

• RV is the reference value, which can be threshold, trend, or pattern of the physiological measurements.

A treatment is defined as a tuple < Agent, Action, PS, SS, ES, L >, where

• Agent is the entity that performs the treatment, Agent ∈ {MedicalDevices, MedicalStaff},

• Action is the set of executable instructions,

• PS is a set of preconditions that must be satisfied before preforming the Action

• SS is a set of potential side effects

• ES is a set of expected responses after performing the treatment

• L is the life cycle, which specifies the time interval between the treatment being performed and the treatment has no further effect on the patient

65

Major Mental Workload Complexity Sources – Using

Cardiac Arrest Resuscitation as a Case Study

Most of medical records taken during the procedures are paper-based and not electronically integrated with the Electronic Medical Records (EMR) in real-time.

• # of spoken words, questions raised

Medical staff must memorize the workflow

• # of medical errors (reviewed by an expert)

• Response time to a simulated event

No validated treatments information

• # of medical errors

Medication orders are verbally communicated

• # of spoken words, questions raised

Task completion time, NASA-TLX can serve as general metrics for mental workload complexity.

66

State of Current Practices

Single-Sensor-Single-Indicator is not enough: "State of the art"

medicine practices usually focus on one control loop (one

measurement, HR/BP, and one contributor, drug, disease, etc).

Lack of integrated and well-organized display: Related

information are usually scattered across multiple devices and

screens. This situation significantly increases medical staff's mental

workload and the chance of preventable medical errors.

Some research work has addressed the above problems by

providing integrated display.

67

Interactive Situation Awareness

Monitor for Physicians Reduce the large volume of

medical information to a

small set of concise and

comprehensive information

according to the chosen

workflow

68

Order Management Tablet

(Handheld) for Nurse in Charge Transform the concurrent, asynchronous

and chaotic order management environment into an orderly, safe, and fault-tolerant one. Ensure each issued order is

• consistent with the preconditions, the timing, workflow, patient physiological status

• consistent with the available equipment, and personnel (to be implemented)

• interoperable with hospital EMR (to be implemented)

The tablet interacts with our backend system and the situation awareness monitor

In the event of system or device failure, the order management tablet has specified safety functions.

69

Microsoft Surface

Virtual Patient Station for

Training and Evaluation To support pre-recorded data

mode

• The EKG signal data are obtained from PhysioNet.

• Different heart rhythms can be selected at anytime by the physician who is responsible for simulating patient responses.

• Patient vital signs, including heart rate, blood pressure, etc., can be selected as well.

• Physicians, residents, and nurses will “treat” the virtual patients as if they were real.

70

Situation Awareness Monitor LayoutSensor readings

Confirm rhythm

Treatments

EKG signal

Treatment timelines

Medication

Messages

Log

Current Workflow

71

complexity reduction for cyber-physical-human medical systems

Technology