1. 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. 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

3. 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 complexity
Complexity 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.

4. 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.

5. 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

6. 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

7. Communication Patterns (Remote Procedure Call)
Supervisor Child device
C1
Async
C2
R1
Supervisor Child device
C1
Sync
C2
R1
R2
7
• Maximum flexibility
• Easily cause state space explosion
• Low complexity
• Too restrictive

8. State Space Explosion
8
msg queue
size
1 2 3
# states 2336 122394 N/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.

9. Major Sources of Complexity
 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

10. Major Sources of Complexity
 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

11. Major Sources of Complexity
 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

12. 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

13. 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

14. Technical Challenges
 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

15. Technical Challenges
 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 once
b. Request for confirmation
c. Adapt the workflow
Not system controllable Flag the deviation and
disengage
a. Flag the deviation
b. Adapt the workflow

16. 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.

17. Communication Patterns
Supervisor Child device
C1
Async
C2
R1
Supervisor Child device
C1
Sync
C2
R1
R2
Supervisor
C1
stop
Interruptible
R1partial
Child device
C2
stop
R2
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

18. Init
B1
Next
cmd!
F_Result?
Ready
Exe
cmd?F_Result!
stop?
B2
stop!
stop?
Supervisor Child Device
FSM Definition of Interruptible RPC Pattern
(Normal Case)
18
P_Result!cmd
P_R
stop

19. Init
B1
Next
cmd!
F_Result?
Ready
Exe
cmd?F_Result!
stop?
B2
stop!
stop?
Supervisor Child Device
FSM Definition of Interruptible RPC Pattern
(Interleaving Handling)
19
P_Result!
F_R
stop

20. 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

21. 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

22. 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

23. 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.

24. 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/

25. 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

26. 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
Pump
SpO2
Sensor
Oxygen
Saturation
Low
Decrease
Pressure
Video
Camera
Operating
Space
Safety
Hazard

27. Complexity of Asynchronous
Interaction
Hierarchical 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.

28. 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

29. Hierarchical Organ-system
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

30. Hierarchical Organ-system
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

31. 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.

32. Consistent View Generation and
Coordination (CVGC) Protocol
 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

33. Consistent View Generation and
Coordination (CVGC) Protocol
 The CVGC protocol has
three phases
• PAE propagation phase
• Locking and consistent
view generating phase
• Command execution and
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.

34. Consistent View Generation and
Coordination (CVGC) Protocol
 The CVGC protocol has
three phases
• PAE propagation phase
• Locking and consistent
view generating phase
• Command execution and
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.

35. 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
Cc
PAE2&CV&
LockSet
lockAndReport

36. Consistent View Generation and
Coordination (CVGC) Protocol
 The CVGC protocol has
three phases
• PAE propagation phase
• Locking and consistent
view generating phase
• Command execution and
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.

37. 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

38. 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

39. 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

40. 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

41. 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.

42. Cardiac Arrest Resuscitation –
State of the Art Practice
42

43. 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
preconditions
4-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

44. 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

45. 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

46. 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

47. OUR FUTURE PLAN
47

48. REDUCING MENTAL WORKLOAD
COMPLEXITY:
WORKFLOW NAVIGATION AND GUIDANCE
DISPLAY SYSTEM FOR IMPROVING
SITUATION AWARENESS
48

49. 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

50. 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. 51
Drug
guidelines
Treatment
workflow

52. 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

53. 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

54. 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

55. 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.

56. 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

57. 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

58. 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

59. Additional Slides
59

60. 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

61. 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. 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
waypoint
pattern
targetting
airscan
airscan
airtrackairtrack
off
airscan airscan
inconsistency
scanAir
scan_air
track
track scanAir
off
stop
stop

63. UPPAAL Model for Pulmonary
Controller
63

64. UPPAAL Model for Pulmonary
Controller
64
PAE propagating
Cmd executing and unlocking
Locking and consistent view generating
phase

65. 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

66. 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

67. 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

68. 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

69. 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

70. 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

71. Situation Awareness Monitor Layout
Sensor readings
Confirm rhythm
Treatments
EKG signal
Treatment timelines
Medication
Messages
Log
Current Workflow
71