towards a systematic software architecture for acute care
TRANSCRIPT
Towards a Systematic Software Architecture for Acute Care Support
Mu Sun, Maryam Rahmaniheris, Cheolgi Kim, Lui ShaDept. of Computer Science
University of Illinois at Urbana-ChampaignUrbana, IL
{musun, rahmani1, cheolgi, lrs}@illinois.edu
Richard B. Berlin Jr.Dept. of Surgery,
College of Medicine andDept. of Computer Science
University of IllinoisUrbana, IL
Julian M. GoldmanMass. General Hospital
and CIMITCambridge, MA
Abstract—According to the Institute of Medicine (IOM)close to 100,000 safety-related medical incidents happens eachyear in US due to preventable medical errors [1]. Thesepreventable medical errors are caused by lack of timely andcomprehensive information about the patient that makes theproper and efficient application of best available knowledgedifficult rather than lack of such knowledge. The preventablemedical errors often occur due to slips and lapses in settingswhere the staff are overloaded and under stress. Our focus ison acute care scenarios where medical staff must make quickdecisions based on the best available evidence. In this paper, wepropose an acute care support system (MACMS) that aids thephysician with monitoring and making decisions given the bestavailable knowledge to decrease preventable medical errors.Such a system is possible due to the opportunity presentedto us by Medical Device Plug-and-Play (MDPnP) to integrateinformation from different devices in an integrated clinicalenvironment [2], [3]. In this paper, we also present a modeldriven approach for designing these acute care support systemsby developing models that correspond closely to medical mentalprocesses and a system architecture to support execution fromthese models.
Keywords-medical systems; architecture; model driven de-sign; model validation
I. INTRODUCTION
Medical Device ”Plug-and-Play” (MDPnP) interoperabil-ity opens the door to significantly mitigating the preventablemedical errors [3]. According to the Institute of Medicine(IOM) at least 44,000 and perhaps as many as 98,000 Amer-icans die in hospitals each year as a result of preventablemedical errors [1]. These preventable medical errors arecaused by improper application of best available medicalknowledge rather than lack of such knowledge. Accordingto ”To Err is Human”, a report published by IOM in 1999[1], the preventable medical errors often occur due to slipsand lapses in settings where the staff are overloaded andunder stress such as emergency rooms and intensive careunits. These slips and lapses include, but are not limited toerror in diagnosis, error in administering a treatment andinadequate monitoring or followup of treatments.
One of the main contributing factors to slips and lapses inclinical environments is the lack of integrated information.
According to a study from a Canadian group performed at2008 the care of critically ill patients generates a medianof 1348 individual data points/day and that this quantityhas increased 26% over five years [4]. Medical staff mustmentally correlate the individual data points they observefrom standalone devices. This is an error-prone process dueto the limitations of human memory and realtime processingcapability. Our goal is to facilitate and improve medical prac-tice by reducing slips and lapses. We propose a monitoringsystem which exploit the benefits provided by safe MDPnPto combine and fuse information from different devices inan integrated clinical environment.
In this paper, we focus on the acute care environmentwhere medical staff must make quick decisions based on thebest available evidence. We created an acute care supportmodeling language as well as an executable support system,the Medical Acute Care Monitoring System (MACMS), thataids the physician to monitor and making decisions giventhe best available knowledge to reduce medical errors.MACMS tries to bring medical practice close to best practiceby encoding well-accepted medical knowledge and medicalcommunity consensus. Furthermore, MACMS uses this en-coded information to make suggestions for medical staff andnotifies them of potential conflicts by:
Monitoring: using patient measurements (patient recordsand real-time patient physiological measures) to monitorcorrectness of a diagnosis and effectiveness of a treatment,
Suggesting: using patient measurements to suggest diag-nosis and treatments according to best practice,
Adapting: changing the mode of operation of the systemto be best suited for a current situation by selecting theappropriate set of patient physiologic signals to measure andusing new measurements whenever they become available(medical device plug-and-play) to increase or decrease con-fidence in current diagnoses and treatments.
Integrated monitoring, suggesting, and adapting systemsstill have not made their way into safety-critical hospitalenvironments. Medical information is considerably vast andcomplex. Even narrowing our focus to acute care settingswith basic physiology (e.g. blood pressure, heart rate, etc.),
still calls for a systematic approach to collect and process theavailable information in a timely manner. Inter-operability ofmedical devices is critical for designing such monitoring sys-tem. MDPnP makes it possible for us to integrate informa-tion from different sources and coordinate medical actionsby providing an integrated clinical environment (ICE) [2],[3]. There exist other safety-critical industries (e.g. chemicaland material manufacturing and defense) that already haveextensive experiences in designing monitoring systems [1].It is common for safety-critical systems to process a largeamount of information and data streaming from differenttypes of sensors and act upon them [5], [6], [7]. However,there are unique features in medical systems that makes thetraditional software architecture used to design monitoringsystems inadequate:
Uncertainty Human physiology for acute care is foundedon vital signs. This results in oversimplified and impre-cise physiological models. Understanding the limitations ofavailable models is critical for designing safe and efficientmedical systems.
Procedure Flexibility Medical decisions are based onavailable information. The complexity and uncertainty ofmedicine makes definitive decisions difficult. Medicine mustfrequently err on the side of action and must make rea-sonable choices according to the best available knowledge.Furthermore, actions must be readily modified according toa patient’s response.
Configuration Flexibility Medical systems need to in-herently be run-time configurable. Different patients requiredifferent sensors and monitors. The set of medical devicesincluding medical sensors required for a medical procedurecan change throughout the procedure. Such dynamic config-uration is not seen in other monitoring systems.
The MACMS software architecture addresses these chal-lenges in medicine by using the following design principles.In order to deal with uncertainty, our system is reactive andis not predictive. The core of MACMS lies in continuousmonitoring of vital signs through sensor signals becausepredicting patient physiology is difficult but detecting that atreatment is not working (based on expected physiologicalchange) is simple. To allow flexible procedures and deci-sions, we let physicians override the system with reason.Furthermore, for all decisions of diagnosis and treatmentmade by the doctors, the system will monitor them forvalidity, consistency and effectiveness. Finally for config-uration flexibility, as new medical sensors are plugged intothe system and additional information becomes available,the system should check their consistency with the currentinformation and use the new data to confirm or modify thecurrent plan.
In the following sections, we will first describe theessential medical knowledge, core requirements, and ourdomain specific model (Section II). We then proceed todiscuss the MACMS system architecture, how it executes the
Context (Physician Entry): Patient with Pneumonia
Patient Measurements:Blood Pressure Low
Heart Rate High
Patient Condition:Dehydration
Possible Treatment:Administer IV Fluid
Patient Measurements:BUN High
Creatinine HighUrine Output Low
Available Patient Info.
Diagnosis Confirmation Checks
Patient Measurements:Blood Pressure Increasing
Hear Rate Decreasing
Expected Treatment Effect
Patient Condition:Fluid Inadequacy/
Overload
Potential Side Effect
Patient Condition:Congestive Heart
Failure
Associated Complications
Possible Treatment:Reduce IV Rate
Possible Treatment
Patient Measurements:Blood Pressure Increasing
Hear Rate Decreasing
Expected Treatment Effect
Triggers
Figure 1. Simple Dehydration Example
high level models, and how it interfaces with the physicalworld through real devices and input patient records (SectionIII). Afterwards, we provide a detailed case study, furtherillustrating all the pieces of MACMS operates with a smallbut complex acute care scenario (Section IV). Finally, wewrap up this paper by discussing related work (Section V)and conclusion (Section VI).
II. MEDICAL DOMAIN KNOWLEDGE AND SYSTEMSPECIFICATION
We now describe the necessary background for our ar-chitecture. We start by discussing some relevant points fromthe IOM and general medical community consensus. We willeventually describe some important principles of acute carepractice and present our domain specific models that capturethese principles.
A. Guiding Requirements of the IOM
Many of our major clinical requirements originate froman important subset of IOM recommendations [1], [8]. Wehighlight some of the most relevant and important ones.
1) Avoid reliance on memory and vigilance (p.170 [1]).Our system needs to be able to encode and retrieveclinical knowledge so less reliance is placed on humanmemory. According to a study from a Canadian groupperformed at 2008 the care of critically ill patientsgenerates a median of 1348 individual data points/dayand that this quantity has increased 26% over fiveyears [4]. Fusion and processing of many partialinformation by the physician is an error-prone processdue to the limitations of human memory and realtimeprocessing capability. Our system should help supportvigilance by automatically integrating the available
data, providing realtime processing of the informationand continuous monitoring of patient.
2) Improve access to accurate, timely information (p.174[1]). Our system needs to collect necessary informa-tion and react upon them in real time.
3) Use simulations whenever possible (p.178 [1]). Oursystem needs to be able to encode concrete casestudies, so that we may study how well the systemwould perform with doctors by simulations.
B. Current Clinical Practice
Figure 1 shows a simple but common acute care scenario.A patient is admitted into intensive care. Basic vital signmeasures are added, the blood pressure is low and the heartrate is high. This is most likely an indication of dehydration.Medical staff immediately proceed with this assumption, andIV saline fluid is given to the patient. While this scenariostarts simply, the complexity immediately grows with pos-sibilities. What if the patient wasn’t actually dehydrated?What if additional measurements contradict the dehydrationhypothesis? What if it is dehydration, but IV fluid doesnot improve the patient? What if it is not dehydration, butthe IV fluid improves the patient anyway? At first glancethrough this limited case a clinical environment is verycomplex with many interactions between different decisionsand many exceptions for every rule. Over the years, themedical community has developed an effective procedureto deal with this seemingly overwhelming complexity:
1) Always proceed with the best available information.Short term low-risk trial treatments may yield impor-tant information even if the trial does not succeed.
2) Always keep in the mind that current diagnoses maybe wrong. Continue to validate diagnoses while pro-ceeding with actions.
3) If it works, it is good. Patient condition improvementis the goal. The system assists the medical personnelby checking the physiological parameters of the pa-tient with diagnosis for consistency.
This means that there may be intermediate reasoning stepsto come up with diagnoses that lead to a treatment, but itis improvement that matters at the end. As long as we seethat the patient is improving, one may proceed.
When a patient’s condition worsens and without sufficientdata to pinpoint the diagnosis, physicians often perform atrial treatment based on the available information and theirexperience and intuition. The top choice is often lower riskand reversible treatment that can be stopped, if patient’s con-dition does not improve as expected. Close monitoring thatintegrates all the data in real time is particularly importantduring trials.
These principles provide a good model of the medicaldecision making. Figure 2 shows how the uncertainty de-cision process is reflected in the medical domain. Initially,the available set of patient information indicates an anomaly.
Patient Condition
Patient Information (abnormality detected)
Possible Treatments
Abnormality Corrected(treatment effective)
Expected Reactions to Treatments
Additional Sensors and Lab Tests
Confirmation
Invalidate
Augment Information
Diagnosis InvalidDiagnosis
Treatment Ineffective
Treatment Option
Confirmation
Invalidate
Figure 2. Iterative Medical Process for Dealing with Uncertainty
Condition Treatment
Check
Critically HighHighNormalLow Critically Low
Rapid IncreaseSlow IncreaseConstantSlow DecreaseRapid Decrease
Threshold MapChange Rate Map
Measurement
Provide
Request
MonitorTriggerMonitor
Define Define
Figure 3. Encoding Medical Knowledge (Metamodel and DiagramLegend)
A likely diagnosis is made by the physician and a possibletreatment is administered. In order to strengthen or invalidatea diagnosis, additional sensors and lab tests are ordered.These additional information actually augment the initialpatient information allowing further diagnosis. In order tovalidate the effectiveness of treatment, the expected patientreactions and trends are monitored. In any uncertain stageof diagnosis or treatment, the physician is alerted as soon asphysiological parameters of the patient show deteriorationor failure to improve. In such case, the prior chain isreevaluated by the physician to consider other possibilities. Ifthere was enough time, systematically, all known potentiallyeffective treatments would have been tried until one is foundthat works. Essentially an exhaustive search.
C. Towards a Representative Model
We have just described a likely mental model used bymany doctors. It is desirable to have a software architecturethat operates and matches this closely to best aid doctors.To effectively use this mental model in software, we needto encode this medical knowledge. We have identified themain elements of the system to consist of (1) availablepatient information (measurements), (2) diagnosed patientconditions, and (3) provided treatments. Figure 3 shows themetamodel based on the relations between these three mainelements. We now dive into the individual model elements.
1) Patient Information: Patient information should de-scribe all relevant information needed to make a diagnosis.Currently, we just consider patient information as the setof available measurements, which are numerical values.Examples of measurements include sensor readings (e.g.blood pressure, heart rate), lab values (e.g. creatinine, bloodurea nitrate (BUN)), and other information (e.g. urine output,pain level). Normally, when diagnosing patient conditions,the exact measurements of blood pressure and heart rate arenot required to make a diagnosis but just how much theydeviate from normal. For each measurement, many times,the conditional checks on these measurements are basedon ranges and normally do not require exact values. Thismeans that for each measurement, there is a definition ofcritically high, high, low, critically low, which are abstractionsof the ranges. A range map maps a range abstraction to aconcrete measured value. For example, with heart rate, highmay be mapped to 100 bpm, which defines the heart rate tobe high if it exceeds 100 bpm. Similarly, we may not justneed to reason about the thresholds of a measurement, butalso about how fast it changes which is defined by a rategranularity (rapid increase, slow decrease, etc.).
Measurements are used by the system through Checkblocks. These contain boolean clauses that can be used forvarious decisions in conditions and treatments. Normally,the Check statements are conjunctions of comparisons. Acomparison could be a threshold comparison or a ratecomparison. A comparison consists of a measurement froma plugged-in device and a range of either a threshold or arate.
2) Diagnosed Patient Conditions: After we have modeledmedical measurements and the statements that can be used toreason about them, we are ready to model patient conditions.Each Condition describes the initial measurements that triggera diagnosis, the follow up monitoring logic that continues toconfirm the diagnosis, and a possible set of treatments thatcan be used to treat this diagnosis. A condition is uniquelyidentified by its name. The trigger statement describes thechecks that need to pass in order to have enough confidenceto diagnose this patient condition. The monitor statementdescribes the continuous monitoring checks that need to beevaluated in order to validate a triggered condition diag-
BUN
Creatinine
Urine Output
Heart Rate
Blood Pressure
Heart Rate
Blood Pressure
BUN
Creatinine
Urine Output
Heart Rate
Blood Pressure
Dehydration IV Fluid
Heart Rate Critically High&&
Blood Pressure Critically Low
Trigger
Request
Heart Rate…Blood Pressure... &&
Urine Output Critically Low&&...
Heart Rate Decrease &&
Blood Pressure Increase &&...
MonitorMonitor
Heart Rate
Rapid Increase: 20 bpm/minSlow Increase: 5 bpm/minSlow Decrease: 5 bpm/minRapid Decrease: 20 bpm/min
Critically High: 160 bpmHigh: 100 bpmLow: 60 bpmCritically Low: 40 bpm
BUN
Urine Output
Blood Pressure
Creatinine
Figure 4. Model Instantiation (of metamodel form Fig. 3) for theDehydration Example
nosis. Furthermore, each Condition lists the set of requestedtreatments which can potentially be administered in order tocorrect the patient condition.
3) Provided Treatments: Once a treatment is requested, itbecomes decoupled of any conditions that requested it. Thereasoning is that a diagnosis may change, but its requestedtreatments may continue as long as they improve patientvital signs. This means that a treatment has its own monitorthat will continue to check vital sign trends to make surethe patient is responding as expected to the treatment.Furthermore, a treatment has a stop condition to suggest apotential stopping point of the treatment.
An example instantiation of our model for the dehydrationscenario is shown in Figure 4. The measurements consideredare heart rate and blood pressure. After it is diagnosed,additional measurements may be requested and used by thesystem once available such as BUN and urine output toconfirm the diagnosis. The treatment of IV infusion also usesthe heart rate and blood pressure to monitor its effectiveness.
D. Functional Requirements
For any system to use this model effectively, the followingrequirements summarizes the basic assumptions made on themodel elements:
Measurement Updates Patient conditions should bechecked when measurements exceed a set threshold
Measurement Additions The system should support theability to incorporate new measurements from new plugged-in devices during run-time using the capabilities provided byMDPnP
Misdiagnosis / Change Diagnosis When the diagnosischanges, then these changes should be propagated to as-sociated treatments so they can be properly modified afternotifying medical personnel
Continuous Monitoring System should continue to mon-itor treatments and diagnoses as time elapses or as newmeasurements from new plugged-in devices or other sources(vital signs, lab results,...) become available, and report anycontradictions to current prognosis
Prioritizing Conditions When conflicting conditions maybe diagnosed there should be some method of decidingwhich one to proceed with first
Contraindicative Treatment All known treatment con-traindications should be detected, notified, and stopped un-less explicitly overwritten by medical personnel
III. DESIGN ARCHITECTURE
We have discussed the domain models, which are staticdescriptions of patient conditions and treatments and neces-sary logical checks on the measurements to monitor themover time. However, since the model describes when wecan make diagnosis and how to monitor, the informationcontained in the model can be directly used to direct systemexecution for an acute care support system. We implementedthe system in Java using Eclipse Modeling Framework(EMF) to manage the models.
A. Models as Execution Parameters
We used EMF to specify the information shown in themetamodel in Figure 3. EMF generates code that allows usto specify the acute care instance models (e.g. Figure 4) in anXMI format. Furthermore, EMF generates code that allowsfor the XMI model files to be deserialized into objects, sothat we may directly access these object attributes to obtainmodel information during run-time.
Figure 5 shows how the deserialized objects of the modelare used during system execution. Deserialized objects ofthe model are static, i.e. they only have attributes withoutany methods. Thus, to modularly define execution semanticsusing the information from these static objects, genericwrapper objects are defined. For example, in Figure 5, thedescription of dehydration (with trigger logic and monitoringlogic) is deserialized into objects in the system, and a genericcondition wrapper object manages all the subscriptions tothe necessary measurements during execution. Also, thegeneric condition wrapper object has methods that areperiodically invoked to check the trigger and monitoringconditions. Semantics of a Check is defined by a predicatethat compares a current measurement with the correspondingthreshold. For example, the statement HeartRate HIGH
with HIGH:100bpm, will mean to check the latest heartrate measurement against 100 bpm. In summary, the keywrapper objects perform the following:
1) Measurement Wrappers:: For each type of measure-ment defined in a model instance, its measurement wrapperwill subscribe to all the relevant devices (e.g. the heart ratemeasurement may subscribe to EKG Monitor, Pulse Oxime-ter, and Blood Pressure Cuff). Thus, a measurement wrapperhas the ability to provide an aggregated measurement forthis type. Furthermore, it will also contain the thresholddefinitions for high, low, rapid increase, decrease, etc. fromthe model, so it can also be directly queried for the whethera measurement is in a predefined range.
2) Condition Wrappers:: For each patient condition de-fined in a model instance, a condition wrapper will subscribeto all measurements required to evaluate trigger checks andmonitor checks. It will also request appropriate treatmentsthrough the treatment manager (described later in subsectionIII-B). For each check statement, it will be evaluated byquerying the appropriate measurement wrapper for whethera value is within a range. Condition wrappers also keepstrack of when a condition becomes active (i.e. the triggercheck evaluates to true).
3) Treatment Wrappers:: For each treatment option de-fined in a model instance, a treatment wrapper will subscribeto all required measurements, and perform the checks de-fined by the monitoring statement. It also keeps referencesto all conditions that requested to change the parameters ofthe treatment.
B. System Architecture
We have described the domain models and the wrappersthat are used to give them appropriate semantics duringexecution. However, there still needs to be an overall archi-tecture to manage these objects and their interactions, andultimately, provide an interface to the real-world throughphysical devices. As we walk through the architecture, wewill also discuss how the functional requirements describedin Section II-D are met.
1) Managing Devices: Diagnosis and monitoring of treat-ment are all driven by medical measurements. Some mea-surements such as observations of the patient and lab testsmay be input through a user interface or obtained through theelectronic medical records (EMR). However, the most im-portant real-time measurements are obtained through sensordevices. Normally only a small subset of critical sensors areconnected to the patient in the beginning (e.g. oximeters,ECG, blood pressure monitor, etc.). But more sensors maybe added depending on the current state of the patient (e.g.CVP sensor when heart failure is suspected). This means thatwe must support a plug-and-play system (Req. MeasurementAdditions). ICE standard provided by MDPnP group helpsus reach this objective [2], [3]. In MACMS, we used Javafront-end interfaces to medical devices. Most sensor devices
Heart Rate(HR)
HR Definition
Trigger Logic Monitor Logic
Condition Wrapper(Dehydration Block)
Dehydration
Trigger Monitor
Creatinine
Creat. Definition
Urine Output
(UO)
UO Definition
BUN
BUN Definition
Monitor Logic
Monitor
IV Fluid
Treatment Wrapper(IV Fluid Block)
Dehydration IV Fluid
Trigger Logic
Trigger
Request
Monitor Logic Monitor Logic
Monitor Monitor
Creat.
BUNUrine
OutputBlood PressureHeart Rate
Model Deserialization & Wrapping
Request
Blood Pressure
(BP)
BP Definition
Figure 5. Using Models as Parameters for Execution
we use have standard external RS-232 interfaces, such asPulse Oximeter and Infusion pump, and these can be easilyinterfaced to our system with standard serial communication.
Figure 6 shows the path from hardware sensors to theactual software measurements obtained in the system. Thething to note is that there is a many-to-many relation betweensensors and measurements. For example, a pulse oximeterprovides both heart rate and SpO2 measures, and a bloodpressure cuff provides both blood pressure and heart rate.Here, each devices provide two measurements, and heartrate is independently measured by two devices.
When a device plugs into the system, this will trigger anevent to create a proxy object. Each hardware device storeinternally a model for its interface (i.e. the measurements itprovides, and control parameters), and this interface modelis sent to the system when the device is plugged in. Forexample, when an oximeter device plugs into the system,it will create a proxy oximeter object. The interface modelwill describe that the oximeter provides measurements forheart rate (HR) and SpO2. The oximeter will then createseparate measurement objects for the HR and SpO2 thatit provides. Each individual measured value such as HRwill then register through the Measurement Manager to thecorresponding measurement. This adds the HR measuredvalue as a possible source of the HR measurement. TheHR measurement manages the HR measured values frommultiple sensors and combines them into one aggregate HR.For example, if two HR measured values comes indepen-dently from an oximeter and a blood pressure cuff, the HRMeasurement interface will have either some prioritizationor averaging algorithm to determine the reported HR.
2) Managing Conditions: The main component at theheart of our system are the diagnoses of patient conditions.The patient conditions provide the context of operations andmonitoring. Figure 6 show the relations between the patientconditions and measurements. Each diagnosed patient con-dition is driven by a set of measurements. This means thateach patient condition object references all of its dependentmeasurements. A new patient condition such as dehydrationneeds to subscribe to a set of required measurements forinitial diagnosis: heart rate, blood pressure, etc., and thecondition also needs to subscribe to a set of additional mea-surements for confirmation: urine output, BUN, etc. In thesystem once the dehydration object is created, it subscribesthrough the Measurement Manager to its list of requiredand additional measurements. The Measurement Managerthen provides the dehydration object with the correspondingreferences to its requested measurements (Req. MeasurementUpdate).
Each individual patient condition is kept track of by adedicated Condition Wrapper object (described in Subsec-tion III-A). Once the a Condition object such as dehydrationhas the references to its required measurements, the object’strigger logic will be rechecked whenever a measurementchanges passed a threshold. When a measurement is updated,the object’s trigger logic runs and checks all the triggerconditions (Req. Measurement Updates). For dehydrationthe trigger conditions are blood pressure low and heart ratehigh. This means that whenever the blood pressure drop andthe heart rate increases, the dehydration trigger should berechecked. Once a trigger condition passes, the Conditionobject becomes active.
The Condition Manager is responsible for keeping track
Device Manager
EKG Monitor Proxy
BP Cuff Proxy
Ventilator Proxy
Infusion Pump Proxy
Surgical Cautery Proxy
EKG Monitor
Device Model
BP Cuff
Device Model
Oximeter
Device Model
Ventilator
Device Model
Infusion Pump
Device Model
Surgical Cautery
Device Model
Treatment Manager
IV Infusion
Antibiotics
Ventilation
Catheterization
Measurement Manager
Heart Rate
Blood PressureBUN
Creatinine
Condition Manager Dehydration
Fluid Overload
Kidney Insufficiency
Heart Failure
Readings
Commands
Control Updates
Updates
UpdatesRequests
User Interface
Condition Model
Database
Measurement Model
Database
Treatment Model
Database
Notify Confirm
Confirm
Notify
Clinical Data
Patient Record
Readings
Commands
Oximeter ProxyHR SpO2
Figure 6. Overall MACMS Architecture
of all active Conditions. The Condition Manger is responsi-ble for prioritizing active Conditions in terms of likelihood,criticality, and urgency (Req. Prioritizing Conditions). Fur-thermore, each active diagnosed Condition may indicate thatother Conditions are likely to become active in the future,and the Condition Manager is also responsible for keepingtrack of potentially active Conditions in the future.
When a Condition object becomes active, it also sets upmonitoring and requests treatment. Once a Condition setsup monitoring, it becomes time triggered and checks itsvitals signs for inconsistencies on a periodic basis (Req.Continuous Monitoring). Monitoring for a newly activatedcondition may require additional sensors and additional labtests. For dehydration, once the condition is activated, then itwill request medical personnel to provide urine output, BUNsamples, etc. The monitoring will use these measurements toensure consistency of diagnosis when these sensors valueschange (requirement Measurement Updates in Section II).Aside from monitoring and checking, the conditions arealso responsible for requesting the proper treatment throughthe Treatment Manager. If a continuous monitor detectsan inconsistency when validating a condition based onmeasurements, it will notify medical staff of the potentialinconsistency, and it will also notify associated conditionsand dependent treatments (Req. Misdiagnosis).
3) Managing Treatment: Once a patient condition isdiagnosed and confirmed by doctors it should also requestappropriate treatments. As shown in Figure 6, the Conditionsends a request to the Treatment Manager upon activationfor the treatments to correct the condition. The Condition
Manager keeps a list of references to the requested treat-ments for each condition. The TreatmentManager will grantthe request if there is no contradiction between the requestedtreatment and the treatments already being administered(requirement Contraindicative Treatment). The Treatment-Manager maintains the list of all the active treatments. Therequested Treatment is triggered by the Treatment Managerand becomes active. The Treatment must subscribe to theMeasurements through the Measurements Manager requiredto evaluate the patient progress in response to the treatment.The Treatment notifies the User Interface of any anomaliesdetected in the treatment.
IV. DISCUSSION
In this section, we describe a detailed case study illus-trating the potential complexities of the acute care process.The case study illustrates how a simple treatment for de-hydration can slowly evolve into other conditions of fluidoverload, heart failure, etc. We describe how the diagnosisand treatment knowledge in this medical process may becaptured in our model, and furthermore, we describe howthese models are used by MACMS during execution to adaptto the changing medical contexts.
A. Case Study Description
A 60 year old male, with history of mild heart disease isadmitted to the emergency room with dehydration, relatedto pneumonia. Our system monitors patient vital signscontinuously. When blood pressure and heart rate exceedthe safe threshold the system should display dehydration as
BUN
Creat.
Urine Output
Urine OutputChest x-ray
Resp. Rate
Chest x-ray
Request
BUN Creat.Urine Output
Heart Rate
SpO2Blood Pressure
Basic Vital Signs Organ FunctionsMedical Personnel Input
Dehydration
Dehydration Trigger Logic
Trigger
Dehydration Monitor Logic
Monitor
BUNCreatini
neUrine
OutputHR
BP
HR
BP
IV Fluid
IV fluid Monitor Logic
Monitor
BUNCreatini
neUrine
OutputHR
BP
Fluid Overload
Fluid OverloadTrigger Logic
Trigger
Fluid Overload Monitor Logic
Monitor
BUNCreatini
neUrine
OutputHR
BP
HR
BP
Potential Complication
Kidney Failure
Kidney Failure Trigger Logic
Trigger
Kidney Failure Monitor Logic
Monitor
HR
BP
Request
Heart Failure
Heart Failure Trigger Logic
Trigger
Heart Failure Monitor Logic
Monitor
HR
BP
HR
BP
Blood Flow Increasing Drug Monitor Logic
Monitor
Blood Flow Increasing Drug
Request
Associated Condition
Central IV Line Monitor Logic
Monitor
Resp. Rate
Pulse CVPMyoglobinChest x-ray
Pneumothorax
Pneumothorax Trigger Logic
Trigger
Pneumothorax Monitor Logic
Monitor
Chest Intubation Monitor Logic
Monitor
Potential Complication
Pain Level
Urine OutputChest x-ray
Resp. Rate
HR
BP
Resp. Rate
HR
BP
Physical ExamResp. Rate
HR
BP
Chest x-ray
Physical ExamResp. Rate
HR
BP
Chest x-ray
Physical ExamResp. Rate
HR
BP
Urine Increasing Drug Monitor Logic
Monitor
BUNCreatini
neUrine
OutputHR
BP
Urine Increasing Drug
Urine Increasing Drug Monitor Logic
Monitor
BUN
Creat.
Urine OutputHR
BP
Urine Increasing Drug
Associated Condition
Chest Intubation
Central IV Line
A1
HR
BP
Request
Request
A2 A3
B1 B2 C2C1 G1 G2
D2D1 E2E2 F
Figure 7. Use Case Scenario Model
one possible diagnosis for this patient who has a historyof pneumonia. The system must confirm this diagnosis byrequesting additional required measurements. In this sce-nario urine output and BUN measurements are requiredfor confirmation. The patient is given intravenous fluid tocorrect the dehydration. However, due to a lapse of caution,he develops fluid overload. High pulse and low blood pres-sure indicates the condition which is detected by the system.The system should attend to the new condition by reducingthe fluid rate and suggesting medication to increase urineoutput. After medical personnel modifies the treatment, arequest for new urine output and BUN measurements shouldbe issued by the system. When these measurements becomeavailable, the system should check their consistency withfluid overload diagnosis. The patient must be monitored forhis physiological response to the new treatment. If the fluidoverload leads to kidney insufficiency and congestive heartfailure, the system should recognize their criticality andattend to them before continuing with the current diagnosis.In this scenario, there is no inconsistency between thetreatments plans of the active condition due to the causalityrelation between them. In general, inconsistency in treatmentplans should be detected and notified by the system.
Later, a central IV line is inserted to measure CVP (Cen-tral Venous Pressure) by the physician. Small pneumothorax
(air in chest compressing lung) from insertion procedureoccurs. The patient develops an acute cough, shortness ofbreath worsens, and has new chest pain, and little changein pulse and blood pressure suggests the condition. Thesystem will request chest x-ray to confirm the diagnosis. Theinspired oxygen level is increased by the medical staff but donot result in improvement of patient respiratory function. Achest tube is inserted by the physician for pneumothorax tocorrect respiratory function. However, chest tube becomesclogged and tension pneumothorax develops. Changes inboth respiratory and pulse/blood pressure measures indi-cates the diagnosis which is displayed by the system. Medi-cal staff and system work together to resolve the condition.Unfortunately, changes in IV rate and ventilator settingsare not effective. Medical staff are alerted and directedby the system to unclog the tube. Tension pneumothorax isrelieved after the tube is unclogged and patient physiologicalmeasurements return toward normal. Pneumonia remainsprimary problem, as pneumonia resolves, the ventilator feed-back supplies less ventilator function, allowing patient tobreathe more on own. Pneumonia resolves, patient is takenoff the ventilator. The respiratory function and pulse/bloodpressure measurement should be monitored afterward toensure that the condition has resolved completely. It shouldbe mentioned that all suggestions should be verified by the
medical staff before the system can move forward with theplan. Anytime the physician decides to overrides the systemsuggestion, the event should be recorded by the system foroff-line analysis.
B. Modeling Elements of the Case Study
We introduced a metamodel for MACMS in section II toabstract the acute care process into elements necessary fora support system that can operate in a way that matches themental model of a physician (see Figure 3). As mentionedbefore. The main elements of our model are availablepatient information (measurements), diagnosed patient con-dition, and provided treatments. This model is based onthe interaction of these elements which is according to themedical process in acute care. In the scenario describedabove, patient information includes the information enteredby the medical personnel, his existing chronic condition(Pneumonia), the vital signs including blood pressure andheart rate. This information will be augmented with addi-tional measurements representing organ functions as theybecome available. In this scenario BUN and Creatinine testand urine output measure are requested by the system andtheir values are added to the patient information when theybecome available. The patient information model is dividedinto three main categories: vital signs (Figure 7-A1), medicalstaff entry (Figure 7-A2), and organ function measurements(Figure 7-A3).
Dehydration, Fluid Overload, Congestive Heart Failureand Kidney Failure models shown in Figure 7 are among themodels required for our case scenario. The associated treat-ment models for each condition are also specified. IV Fluid,Urine Increasing and Blood Flow increasing medications areamong the treatment models present in this scenario. Thecondition and treatment models specify the measurementsrequired by the trigger logic and additional measurementsrequired for monitor logic to confirm the condition andmonitor the effect of treatment. For example accordingto Dehydration model (Figure 7-B1) BUN, Creatinine andurine output are the additional measurement needed formonitoring logic of this condition. As shown in Figure 7-B2, the IV fluid is the associated treatment for Dehydrationcondition. The same set of measurements are also used tomonitor the treatment. Fluid Overload (Figure 7-C1) as oneof the potential complications of IV Fluid treatment.
Congestive Heart Failure model (Figure 7-D1) is associ-ated to Fluid Overload model (Figure 7-C1) and Kidney Fail-ure model (Figure 7-E1) is associated to Heart Failure model(Figure 7-D1). This relations between models represent thecausality relation between these conditions. Central IV Linemodel (Figure 7-F) describes the measurements that mustbe monitored when Cental IV Line is used in the scenarioto measure CVP (Central Venus Pressure). Pneumothoraxmodel (Figure 7-G1) is specified as a potential complicationof the Cental IV Line model. As shown in Pneumothorax
model blood pressure, heart rate, respiratory rate, chest x-ray and physical exam are required by Trigger and MonitorLogics of the condition. The Chest Intubation treatmentmodel (Figure 7-G2) is associated with the Pneumothoraxmodel. According to the Chest Intubation model, bloodpressure, heart rate, respiratory rate, and physical exam isused by the treatment Monitor Logic.
The above set of models are selectively loaded into thesystem based on the current medical context. Furthermore,relations of potential complications of treatments and associ-ated conditions are dynamically loaded into the system whenthe condition is diagnosed or the treatment is administered.The following subsection describes how the dynamic use ofthe models can be used to drive execution of an adaptivesystem.
C. Illustration of System Adaptation
When the system is initialized, the basic sensors such asblood pressure and pulse oximeter are plugged in. Theseprovide the basic measurements of BP, HR, and SpO2.Furthermore, because the patient has pneumonia, the dehy-dration condition object is loaded from the correspondingmodel (with the wrapper method described in SubsectionIII-B). This initial configuration is shown on the left ofFigure 8(a).
Once dehydration is detected, the system will ask fordoctors to confirm or ignore the diagnosis. If it is confirmed,then the system will also request that additional measure-ments and devices to be provided. The right of Figure 8(a)shows the system configuration after these doctor confirmedchanges. An infusion pump is connected to the system toadminister the saline fluid, and the corresponding treatmentmodel is loaded with the necessary control parameters.Three additional measurements of BUN, Urine Output, andCreatinine are added. The treatment for IV fluid is addedto provide support. A fluid overload condition (associatedas a complication of giving IV fluid) is also loaded into thesystem as a potential complication to monitor.
Through what we just described, the system has gonethrough a mode change. Before, there was only one mon-itor for dehydration using three measurements, but aftera diagnosis confirmation and addition of more devicesand measurements, the system loop now operates on fivemeasurements with two conditions being monitored andalso providing treatment. This means that the system hasessentially gone through a doctor-confirmed mode changethat adapts to better matches and supports the current contextof the operation.
The system mode change to diagnose dehydration and toadminister IV treatment was completely anticipated, and theonly uncertain part is the doctor’s confirmation. However,there are also instances where the doctors may do thingsoutside of the limited medical knowledge of the system. Forexample, in Figure 8(b), the initial system was setup with
Treatment
Devices
Pulse Oximeter
Blood Pressure Cuff
Condition
Dehydration?
Load Appropriate Models
Devices
Pulse Oximeter
Blood Pressure Cuff Treatment
Devices
Pulse Oximeter
Blood Pressure Cuff
Condition
Pneumothorax?
Treatment
Initial State: Load for Pneumonia
IV Fluid
Congestive Heart Failure
Possible Dehydration
DehydrationConfirmed
Request AdditionalMeasurements
Measurements Entered Measurements
SpO2Condition
Dehydration
Fluid Overload ?
Measurements
SpO2
HRBP
HR
BUN Creat
UOBP
...
Measurements
SpO2 HR
Resp. CXR
UOBP
Urine Increasing drug
Blood Flow Increasing Drug
Central IV Line
Load Appropriate Models
Condition
Congestive Heart Failure
Treatments
Urine Increasing drug
Blood Flow Increasing Drug
Measurements
SpO2 HR
Resp. CXR
UOBP
Devices
Pulse Oximeter
Blood Pressure Cuff
Infusion Pump
Model Repository
...
(a)
(b)
Insert Central IV Line
Request AdditionalMeasurements
Measurements Entered
Unanticipated
Model Repository
Figure 8. System Mode Adaptation Example with Reactions to Anticipated Events (a) and Unanticipated Events (b)
a continuous monitoring loop for congestive heart failure.The doctor decides to insert a central IV line to measurethe central venous pressure (CVP). This is an unanticipatedevent since it is an asynchronous interruption from doctors.However, the system will similarly load in correspondingmodels for CVP and request additional measurements tocheck its safety. Furthermore, the likely complications ofthe central IV such as pneumothorax is also loaded intothe system. In this example, the system was able to load innecessary elements to monitor the necessary measurementsto best support a doctor’s decision.
Of course, there is always the case when a doctor need toperform an action that has no support in the system. In thiscase, when things get too complex, the system can alwaysfall back to a basic mode of operation. This basic mode willjust monitor the most basic vital signs (heart rate, bloodpressure, etc.) and provide notifications at signs of patientdegradation and anomalies.
V. RELATED WORK
The challenges of design of systems of interoperable med-ical devices are even harder to overcome compared to stand-alone devices. However, high confidence medical systemsare necessary to avoid medical errors. The authors in [9]focus on the necessity of proper infrastructures on which net-works of efficient and fully functioning interoperable plug-
and-play medical devices can be built. According to [10]having a systems of interconnected plug-and-play medicaldevices in the ICU can provide the clinical staff with a moreprecise assessment of patient state. In [11] the authors alsodiscuss the benefits of interoperable medical devices. Theauthors present the prototype of an interoperable medicalsystem including a PCA pump and multiple monitoringdevices to discuss the existing challenges and also thebenefits of such systems. [12] and [13] present a frameworkto improve the flexibility and reconfigurability of prototypemulti-device medical systems. In [14] the authors report theirexperience with a prototype plug-and-play synchronizedmedical system that includes the interconnection of an x-ray and anesthesia machine ventilator. In [15] the authorsdefine the system safety properties in terms of patient stateusing an existing patient model.
Medical expert systems and clinical decision supportsystems assist medical staff with analysis of patient dataand decision making process. These systems mostly useartificial intelligence, fuzzy logic and to deduction to makediagnoses and often do not go beyond making diagnosis.In some cases the system predict the future events basedon the current diagnosis [16], [17], [18], [19] and [20].In our system the main focus is monitoring the patientprogress after an initial diagnosis is made by the physician.Fuzzy logic uses complex algorithms to essentially rank
diagnoses. Most of the time these are one shot and forchronic diagnoses. However, these ranking algorithms offuzzy logic can be used later to improve the quality ofprioritization schemes in our system [21], [22], [23]. Thereare many paper about modeling and verification for themedical domain [24], [25]. However, much of the focus hasbeen on device level modeling, and not on capturing thephysiological responses and monitoring for the patient. Thisbuilds upon the current modeling work for devices becausethis type of monitoring can be seamlessly integrated intoexisting systems to provide more robustness.
VI. CONCLUSION
We presented a software architecture for a support systemfor acute care, MACMS, that aims at reducing preventablemedical errors specified in IOM reports. MACMS aids thephysician to confirm diagnoses and monitor treatments giventhe available patient information. The system is based onthe representation of medical process that closely matchesmental model of physicians. The system collects and in-tegrates all the measurements and patient data as theybecome available with simultaneous matching to the patientcondition and expected physiological response of the patient.MACMS provides the medical personnel with realtime alertwhich are based on integrated patient data. We demonstratethe applicability of our model and execution frameworkusing an acute care scenario.
The long term goals of our project is to provide asoftware architecture that is adaptive, dynamic, real-time,and provides the depth needed in a field of expandingcriticality.
REFERENCES
[1] L. T. Kohn, J. M. Corrigan, and M. S. Donaldson, “To err ishuman, building a safer health system,” 1999.
[2] “ASTM F2761-09: Essential safety requirements forequipment comprising the patient-centric integratedclinical environment (ICE) Part 1: General requirementsand conceptual model,” 2009. [Online]. Available:http://www.mdpnp.org/uploads/F2761 completed committee draft.pdf
[3] http://www.mdpnp.org.
[4] B. Pickering, V. Herasevich, A. Ahmed, and O. Gajic,“Novel representation of clinical information in theicu,” pp. 116–131, April 2010. [Online]. Available:http://dx.doi.org/10.4338/ACI-2009-12-CR-0027
[5] C. M. Belcastro and S. R. Jacobson, “Future IntegratedSystems Concept for Preventing Aircraft LOss-of-ControlAccidents,” AIAA Guidance Navigation and ControlConference, no. August, pp. 1–16, 2010. [Online]. Available:http://hdl.handle.net/2060/20100031283
[6] C. M. Belcastro and J. V. Foster, “Aircraft Loss-of-ContolAccident,” Control, no. August, pp. 1–39, 2010. [Online].Available: http://ntrs.nasa.gov/details.jsp?R=526827
[7] C. M. Belcastro, “Validation and Verification of Future Inte-grated Safety Critical Systems Operating Under Off-NominalConditions,” AIAA Guidance Navigation and Control Confer-ence, 2010.
[8] “Crossing the quality chasm: A new health system for the21st century,” 2001.
[9] I. Lee, G. J. Pappas, R. Cleavland, J. Hatcliff, B. H. Krogh,P. Lee, H. Rubin, and L. Sha, “High-Confidence MedicalDevice Software and Systems,” IEEE Computer, vol. 39, pp.33–38, April 2006.
[10] K. Grifantini, “Plug-and-Play Hospitals: Medical devices thatexchange data could make hospitals safer,” MIT TechnologyReview, July 2008.
[11] D. Arney, S. Fischmeister, J. M. Goldman, I. Lee, andR. Trausmuth, “Plug-and-Play for Medical Devices: Expe-riences from a Case Study,” Biomedical Instrumentation &Technology, vol. 43, no. 4, pp. 313–317, 2009.
[12] A. King, D. Arney, I. Lee, O. Sokolsky, J. Hatcliff, andS. Procter, “Prototyping Closed Loop Physiologic Controlwith the Medical Device Coordination Framework,” in Pro-ceedings of the 2010 ICSE Workshop on Software Engineeringin Health Care. ACM Special Interest Group on SoftwareEngineering, 2010, pp. 1–11.
[13] A. King, S. Procter, D. Andresen, J. Hatcliff, S. Warren,W. Spees, R. Jetley, P. Jones, and S. Weininger, “An OpenTest Bed for Medical Device Integration and Coordination,”in Proceedings of the 2009 International Conference onSoftware Engineering (ICSE), 2009, pp. 141–151.
[14] D. Arney, J. M. Goldman, S. F. Whitehead, and I. Lee,“Synchronizing an X-ray and Anesthesia Machine Ventilator:A Medical Device Interoperability Case Study,” in Proceed-ings of the 2009 International Conference on BiomedicalElectronics and Devices (BioDevices), 2009, pp. 52–60.
[15] D. Arney, M. Pajic, J. M. Goldman, I. Lee, R. Mangharam,and O. Sokolsky, “Toward patient safety in closed-loop med-ical device systems,” in Proceedings of the 1st ACM/IEEEInternational Conference on Cyber-Physical Systems, ser.ICCPS ’10. New York, NY, USA: ACM, 2010, pp. 139–148.
[16] P. Durieux, R. Nizard, P. Ravaud, N. Mounier, and E. Lep-age, “A Clinical Decision Support System for Preventionof Venous Thromboembolism,” JAMA: The Journal of theAmerican Medical Association, vol. 283, no. 21, pp. 2816–2821, 2000.
[17] A. A. Montgomery, T. Fahey, T. J. Peters, C. MacIntosh, andD. J. Sharp, “Evaluation of computer based clinical decisionsupport system and risk chart for management of hypertensionin primary care: randomised controlled trial,” BMJ, vol. 320,no. 7236, pp. 686–690, 2000.
[18] D. L. Hunt, R. B. Haynes, S. E. Hanna, and K. Smith, “Effectsof Computer-Based Clinical Decision Support Systems onPhysician Performance and Patient Outcomes,” JAMA: TheJournal of the American Medical Association, vol. 280,no. 15, pp. 1339–1346, 1998.
[19] K. Kawamoto, C. A. Houlihan, E. A. Balas, and D. F. Lobach,“Improving clinical practice using clinical decision supportsystems: a systematic review of trials to identify featurescritical to success,” BMJ, vol. 330, no. 7494, p. 765, 2005.
[20] D. W. Bates, G. J. Kuperman, S. Wang, T. Gandhi, A. Kittler,L. Volk, C. Spurr, R. Khorasani, M. Tanasijevic, and B. Mid-dleton, “Ten commandments for effective clinical decisionsupport: making the practice of evidence-based medicine areality,” Journal of the American Medical Informatics Asso-ciation, vol. 10, no. 6, pp. 523 – 530, 2003.
[21] J. Warren, G. Beliakov, and B. van der Zwaag, “Fuzzy logic inclinical practice decision support systems,” in Proceedings ofthe 33rd Annual Hawaii International Conference on SystemSciences, 2000.
[22] R. John and P. Innocent, “Modeling uncertainty in clinicaldiagnosis using fuzzy logic,” IEEE Transactions on Systems,Man, and Cybernetics, Part B: Cybernetics, vol. 35, no. 6,2005.
[23] G. Beliakov and J. Warren, “Appropriate choice of aggre-gation operators in fuzzy decision support systems,” IEEETransactions on Fuzzy Systems, 2001.
[24] I. Lee, G. Pappas, R. Cleaveland, J. Hatcliff, B. Krogh,P. Lee, H. Rubin, and L. Sha, “High-confidence medicaldevice software and systems,” Computer, vol. 39, no. 4, pp.33 – 38, april 2006.
[25] R. P. Jetley, C. Carlos, and S. P. Iyer, “A case study onapplying formal methods to medical devices: computer-aidedresuscitation algorithm,” International Journal on SoftwareTools for Technology Transfer (STTT), vol. 5, pp. 320–330,2004.