A Decade of Physiological Data Research and Development in Trauma Intensive Care

SIMON (Signal Interpretation and MONitoring) continuously collects and processes bedside medical device data. As of December 2009, SIMON has monitored over 7,630 trauma intensive care unit (TICU) patients, representing approximately 731,000 hours of continuous monitoring, and is currently operational on all TICU beds at Vanderbilt University Medical Center. Parameters captured include heart rate, blood pressures, oxygen saturations, cardiac function variables, intracranial and cerebral perfusion pressures, and EKG waveforms. This repository supports research to identify “new vital signs” based on features of patient physiology observable through dense data capture and analysis, with the goal of improving predictions of patient status. SIMON’s alerting and reporting capabilities include web display, sentinel event notification, and daily summary reports of traditional and new vital sign statistics. This allows discoveries to be rapidly tested and implemented in a working clinical environment. The work details SIMON’s technology and corresponding design requirements to realize the value of dense physiologic data in critical care.


INTRODUCTION
Fundamental clinical approaches for assessing vital signs have changed little since 1903, when Cushing asserted the importance of periodically measuring a patient's heart rate and blood pressure [1].While physiologic parameters have been added to the milieu, patient assessment remains largely a manual, periodic process.Ephemeral measurements of flows, pressures, and electrical activity within the body are dutifully recorded by nursing staff, but only in the most urgent circumstances are data recorded, or even reviewed, more than once per hour.Given the vast quantities of physiological data that are simply discarded, the modern ICU remains one of the most potentially data-rich, yet information-poor, environments in modern healthcare.
A growing body of research suggests value in automated analysis of continuously sampled data.For example, heart rate variability (HRV) has been associated with onset of sepsis [2][3][4][5][6][7], multiple organ dysfunction syndrome [8,9], myocardial infarction [10][11][12], and elevated intracranial pressure [13], and has been studied extensively as a pre-hospital triage tool in trauma patients [14][15][16].Other examples include the study of arterial and intracranial pressure waveforms to predict loss of cerebral autoregulation [17,18], and detection of pulmonary emboli based on characteristics of the pulmonary artery pressure waveform [19].Despite convincing research results from animal experiments and small clinical studies, these and similar observations remain largely unrealized in patient care.
Clinical adoption of new technology requires not only compelling scientific evidence from relevant patient populations, but also affordable solutions that can be practically implemented at the bedside.To date, technical, economic, and social barriers have made such advances difficult.Commercial monitoring systems do not adequately analyze physiologic signals, or store data for extended periods of time for off-line analysis without extensive customization.As such, even relatively simple trends in vital signs clearly requiring clinical attention may go unnoticed due to human inability to process information in busy clinical settings [20], especially in the ICU where many automated alerts based on physiologic trends or thresholds are of dubious value [21].
A number of custom-built systems collect and process bedside medical device data with the ultimate goal of improving medical decision-making.Also, generic decisionsupport models and monitoring frameworks have been defined specifically with dense physiologic data in mind [22][23][24][25][26].However, few systems employing complex, generic decision support models have reached routine clinical use.Other systems, without extensive decision support models, have successfully delivered clinical alerts beyond those available via bedside physiologic monitors [27][28][29], sampled and archived dense physiologic data to support clinical research [30][31][32][33][34], or made medical monitor data available remotely [35,36].Gardner and colleagues demonstrated many of these advancements as early as 1972 with the University of Utah's HELP system [37], and commercial solutions are beginning to offer many of these capabilities.The Physionet project [38] provides a rich on-line collection of physiological datasets, algorithms, and other resources.Other large-scale public resources include the BrainIT [39] project, which amassed data, including continuous physiological signals, from brain injury patients.
Second, clinical physiologic data is subject to noise, dropouts, and other artifacts.Patient movement, care processes such as bathing, bedside procedures, trips to radiology or the operating room, sensor misplacement, transducer occlusion, and other events can result in erroneous or missing data.The extent to which noise must be filtered depends on signals in question and the particular application.All data collected by SIMON undergoes a range check to ensure that values are physiologically plausible.In addition, SIMON alert definitions can specify a duration component with hysteresis to avoid generating alerts in response to transient increases or decreases, as often occurs in pressure signals during zeroing or other catheter maintenance.For research purposes, depending on the signals and measurements involved, noise filtering may be important.For example, calculating durations of low blood pressures may require eliminating various artifacts in this particular signal [40].Finally, automated physiologic data collection systems require regular system monitoring to ensure sufficient reliability; both the technology and supporting human processes like patient identification and mobile device connection rates should be periodically assessed.SIMON automatically generates weekly email reports of various performance metrics for staff review.These system monitoring requirements are often overlooked, and are critical to fully realize the value of SIMON and similar automated, continuous physiologic data systems.

IMPLEMENTATION 3.1. Component Architecture
SIMON's current implementation represents one of many possible solutions to the needs described above, and has been implemented in a working trauma intensive care unit (TICU) since 1998.Since the earliest UNIX-based versions of the system [41,42], modular design has been the hallmark of SIMON's architecture.Individual software components perform data capture, storage, analysis, and management functions.Modularity, combined with use of standard underlying communication protocols between components, enables: 1) Efficient distribution of system components over various computing platforms as the system grows; 2) Modification or addition of new components with minimal impact on existing functions; and 3) Robust operation, since failure of an individual component has minimal impact on other parts of the system.SIMON's current components, and their deployment over various computing systems, are shown in Figure 1.Detailed descriptions of architecture components follow.

Data Capture and Storage
SIMON achieves accurate, reliable data capture through independent software modules running on a remote central server.Data capture is complete and fully automatic with respect to numeric parameters; waveform capture is possible, but requires manual intervention to select waveform channels and start and stop the acquisition process.Bedside equipment connections are made via the institution's local area network, using devices at each bed to translate medical device (RS-232) formats to network (Ethernet) formats.Every physiologic monitor on our trauma unit is permanently connected to SIMON.Nurses connect mobile devices using color-coded, connector-specific cables.Data sampled through these connections is time-stamped by individual data collection modules, and then relayed to a central concentrator for relational database storage (see Figure 1).Individual data collection modules are continuously monitored by a "watchdog" program ("System Manager" in Figure 1).Each SIMON module is responsible for periodically writing a file if it is running without error, and the System Manager periodically checks the timestamp of these files.devices, and all restarts are logged.A high frequency of automatic restarts triggers email and alphanumeric pager alerts to technical staff.In this way, SIMON automatically and continuously captures all numeric parameters from bedside physiologic monitors, portable cardiac monitors, and ventilators over 14 TICU beds. Figure 1, a single component, the Data Concentrator, receives data from multiple individual data collection modules, then formats and stores it in the database.The Data Concentrator adapts sampling rate in response to database load, so not every sample is stored if the database system becomes busy with other tasks.Samples not immediately stored are queued to disk for later playback.The dynamic sampling rate ensures that recent data -albeit down-sampled -will always be available in the database to support time-critical tasks.Trend (second-by-second) data such as heart rate are stored in database tables with one record corresponding to each observation.Waveform data are stored in segments of approximately one-minute duration.Additional database tables associate individual patients with particular beds.SIMON accurately determines bed occupancy by monitoring census information from the hospital's admission-dischargetransfer (ADT) system, with manual verification by unit staff whenever data resumes from a particular bed following an interruption in data (indicating a possible change in bed occupancy).A dedicated panel displays bed occupancy at the nursing station, and prompts for confirmation when needed.Once identity is validated, all data since the interruption is associated with that patient.

Clinical Reports and Alerts
SIMON reports physiologic data in both graphical and text formats.Graphs of select parameters are accessible via a secure web site, and can be viewed from bedside terminals as well as from remote locations.Graphs are refreshed minute by minute to reflect the most recent data from each patient, and can be viewed at several resolutions ranging from a full day to a one-hour period.Figure 2 shows data graphs for a single patient over a 24-hour period.
In addition to the on-demand graphs of patient physiologic data, text reports are automatically generated at predefined intervals based on flexible templates stored in the database.These text reports contain a variety of summary statistics for one or more patients, formatted appropriately, as shown in Figures 3 and 4. Templates contain references to database stored procedures, small programs contained within SIMON's database, to generate individual numbers within the reports (e.g., patient mean heart rate).Certain text reports are regularly sent to the institutional electronic patient record, which can also be viewed remotely via secure web interfaces.The content or format of SIMON text reports can be changed by modifying the template or corresponding stored procedures, and new reports can be created by adding templates and new stored procedures if needed.Furthermore, templates for reports or alerts can incorporate patient-specific algorithms, to report parameters defined by individual patient characteristics.A simple example would be to change the critical threshold for heart rate based on the patient's age, body mass index, or other physiology.Text reports are triggered by events, which might be specified to occur at the same time each day, e.g., for reports used in morning rounds, or a specific change in patient physiology, and are stored in the SIMON database.
SIMON uses a combination of event, alert, and notification templates stored in the database to realize flexible, efficient alerting.Event templates specify a combination of one or more algorithms, implemented as database stored procedures.These in turn define a potential alert condition, e.g., "Intracranial pressure above 25  For each event, one or more alert templates define the duration that the event must occur before sending an alert, and the text of the alert message, e.g., "ICP > 25 and CPP < 60 for MRN 123123 at bed 10001".Finally, for each alert, one or more notification templates define the recipients of the alerts by alphanumeric pager number or other communication channels.Figure 5 shows one such notification on an alphanumeric pager.Individual alerts can be specifically disabled or enabled for one or more patients, and each communication channel can be disabled for any period of time.Finally, each communication channel can be set to group all alerts in a certain time period into a single notification, e.g., send an alphanumeric page for all alerts in a five minute period.Individual alerts can be configured to override this "batch" delivery to ensure timely notification of short-term and/or potentially highly critical alerts.All instances of events, alerts, and notifications are stored in the database.Mon.hrs.

Ventilator
Time  To ensure reliable operation, SIMON provides a number of automated alerts and reports.Network, database, institutional data links, and server status are constantly monitored, with redundant paging systems to alert technical staff to problems.Human processes, such as patient identification and mobile device connections are similarly monitored.For example, lack of a connected bedside cardiac monitor is automatically detected by sensing the pulmonary pressure signal from the physiologic monitor, because in our institution, all TICU patients with a pulmonary catheter receive additional cardiac monitoring.Corresponding alerts for disconnected devices are sent directly to unit staff.Each week, a number of reports are generated for review, including statistics of system uptime, network uptime, total number of patients monitored, bed occupancy and data collection rates.Staff performance is also reported for patient identification and mobile device connections, including any related alerts and the time until corrective action was taken.

CURRENT STATUS 4.1. Dataset
As of December 2009, SIMON's database contains data from more than 7630 TICU patients, representing approximately 14 billion vital sign data points (exclusive of waveform data) and 731,000 patient-hours of continuous monitoring.The corresponding database occupies 164 gigabyte of disk space, inclusive of indexes.In November of 2008 waveform data capture was added using a separate database, which now contains approximately 737 billion waveform samples in a database occupying just under one terabyte.Roughly 70 patients are added to SIMON's database each month, representing 5500 patient-hours of monitoring and 60 GB of database storage (vital signs and waveform data).Data accrues automatically, with manual interaction required only to confirm patient identity and to connect portable bedside devices to the system.Table 3 shows statistics for selected parameters in SIMON's database, aggregated over all trauma patients in 2008.

Clinical Use
SIMON's daily vital sign summaries are the most frequently used tools.The attending physicians, ICU medical director, and nurse managers use the unit summary reports (Figures 3 and 4) regularly to provide a picture of overall patient acuity.In most cases, Journal of Healthcare Engineering • Vol.these numbers confirm observations made in the course of daily care.Occasionally, unexpected derangements in individual patient physiology are noted, prompting closer review of the patient, sometimes resulting in additional therapy or diagnostic procedures.The daily reports may act as a "safety net" to bring attention to the individual patient, in the event that unexpected deterioration over 24 hours is missed.
In addition, care providers on other services sometimes use single-patient summary reports sent to the institutional medical record to evaluate a patient's physiology prior to transfer or operative procedures.Providing effective "safety net" functionality on a time scale shorter than the daily reports has proved challenging.Currently, SIMON's ability to send alerts to alphanumeric pagers (Figure 5) is no longer used on a regular basis.Given our current ICU work processes, lack of pagers for individual bedside nurses, skilled providers, and existing monitoring systems, the benefit of alerting based solely on existing measures of patient physiology has been marginal.In the TICU, many physiological changes are closely tracked by staff or detected by existing monitor alerts (although these generally result in a high number of false-positives).Furthermore, some physiological derangements are accepted because all therapeutic options have been attempted or because trade-offs are necessary to balance deteriorating physiology and organ system function.SIMON can incorporate other data such as laboratory results and medication administration, which may result in more clinically effective alerts in the future.
SIMON's data graphs (Figure 2) are occasionally reviewed by clinicians in the course of patient care, but have proven more useful in their support of clinical research.Many studies use physiologic criteria for patient enrollment, and our research staff views these graphs remotely to ascertain patient eligibility for particular studies.This has reduced the need for research staff to communicate with care providers or travel to the ICU to evaluate patients.

Research Applications
New measurements of patient physiology available from densely captured data will define future monitoring strategies, decision support algorithms, and clinical processes.We have only begun to explore how these "new vital signs" might efficiently stratify groups of patients by acuity, outcome, and need for particular therapy, or identify clinical deterioration or improvement in the individual patient.Our work has described the relationship of patient outcome to heart rate and blood pressure mean, ranges, and variability over the ICU stay [43], and some of the challenges associated with filtering non-physiologic artifacts [40].We have investigated short-term heart rate variability (HRV) derived from integer heart rate.Within the first 24 hours of ICU admission, HRV predicts trauma patient death occurring in a median of 5 days after admission, with a sensitivity of 70% and specificity of 80% [44].Patient triage, in both civilian and military environments, is one application of this and other new measurements based on dense physiologic data [45].More recently, we have examined heart rate complexity (using multiscale entropy [46] and its role as an early predictor of trauma patient mortality [47], the effects of injury type and severity on this relationship [48], and the concomitant role of specific genetic variations in the autonomic nervous system [49].Continuous physiological data is well suited to recent complex systems approaches to understanding the pathophysiology of critical illness [50][51][52].
Heart rate represents one of many parameters available for study; variability and complexity are one group of possible analyses; and early triage represents a single application in a multitude of clinical decision support needs.Practically speaking, a wealth of clinical data remains inaccessible or lost due to inadequate capture -data that might inform future continuous monitoring applications.Timing of medication administration, bedside procedures, and other interventions will be important to record in a format more accurate and accessible than the paper charts still in use at many institutions.We have begun to utilize such electronic systems at our hospital, and look forward to exploring the relationships between a number of clinical events and changes in patient physiology.
Our current work constitutes early steps to bringing new vital signs, based on a continuum of patient physiology, to the bedside.Developing new decision support tools based on dense physiologic data will require: 1) New methods of representing data, information, and knowledge; 2) Provider training and new clinical workflows to optimize utility; and 3) Rigorous evaluation of costs and benefits of clinical deployment.To date, we have only informally explored these medical informatics research opportunities [53].

DISCUSSION
We have learned many lessons pertaining to designing, building, and maintaining SIMON over the past decade.The following have been selected for their significance in constructing and using a reliable, automated, physiologic data capture and analysis system.

Build Modular Systems
G. Octo Barnett and his colleagues detailed the benefits of modular design in clinical information systems nearly four decades ago [54].We have realized a number of these advantages in SIMON's component-based architecture.Flexibility in modifying, fixing, or augmenting functionality has been paramount, as some of the components shown in Figure 1 have undergone more than 30 revisions since their initial implementation.SIMON's modular design allows individual components to be developed, debugged, and tested on separate systems, then deployed with minimal interruption to other functionality.This relative ease of modification allowed SIMON to grow from a simple data collection tool storing physiologic parameters in text files, to a physiologic data management solution supporting diverse clinical and research applications.
Reliability is also enhanced by SIMON's modular architecture.Individual component failures are rapidly detected and, in most cases, automatically fixed by restarting the failing module.Automatic component restart allows SIMON to promptly resume operation following network or power failures.The most notable of these rare incidents was failure of our institution's network for 12 hours as a result of the "SQL Slammer" worm in January, 2003.Individual SIMON components resumed operation as network connectivity was restored, without manual intervention.SIMON's modular design also enhances reliability in that components can be rapidly moved between systems in the event of failure.During the most severe internally-caused failure in SIMON's history, where an operating system patch temporarily disabled the Data Capture and Management Server (Figure 1), essential components were migrated to a spare system and core functionality was restored within two hours.
Finally, SIMON's scalability results, in large part, from modular design.The system has grown from two beds in September, 1998, running on a single 300Mhz Pentium-II system, to 14 beds running on two dual-processor servers without significant change in architecture.New components are easily added to capture data from additional beds, or to implement new functionality.However, scalability and reliability do not arise from modular design alone.The following section describes our strategy for building individual components to fully realize these and other benefits of modular design.

Use Simple, Observable, Portable Components
Modularity affords little advantage if the individual system components are complex "black boxes" tied to specific computing hardware.Components should be as simple as possible in terms of functionality, configuration, internal design, and operation.We found state flow diagrams to be a useful way to assess complexity of system components.A component's functionality is diagramed to a level of detail sufficient to represent individual subroutines.If the state flow diagram cannot be easily represented without crossing lines on a single page, the component is considered for redesign, perhaps by dividing into sub-components.
Component operation should also be observable, to allow monitoring and troubleshooting as the system runs.Each component should, at a minimum, periodically report that it is operating normally.Ideally, internal state, history of operation and error conditions can be queried as well.All SIMON components periodically write a "lifetick" file, in addition to logging events and errors to text files.Select components store additional state information, updated in real-time, in a database.This allows for watchdog functionality described above and for evaluating reliability in the long-term, over component modifications and other system changes.
Finally, components should be portable, allowing for distribution across physical systems, perhaps even running different operating systems.SIMON achieves a degree of portability by using a single database for storing all persistent system information, and by using common protocols for communication between components.These protocols (ODBC, TCP/IP) are widely supported across operating systems and programming languages, allowing a great deal of flexibility in choosing development and implementation technology.

Develop Work Processes Alongside Technology
SIMON's successful operation, even though highly automated, requires human involvement.On a day-to-day basis, people must monitor the system to ensure proper operation.Patient identity must be confirmed, and portable bedside devices must be connected promptly to avoid loss of data.Occasional maintenance must be completed, as described above.Initially, we underestimated the difficulty in getting staff to perform these tasks reliably as part of their existing duties, and to maintain this reliability over 1. Staff feedback is sought during periods of change (even relatively small change); 2. Performance is regularly evaluated, sometimes with the aid of automated reports; and 3. Positive and negative incentives are used if performance wanes.Most of these processes were defined and implemented not by technical staff, but by the trauma unit assistant nurse manager.Continued success requires a greater degree of strategic planning.The cost/benefit of SIMON and similar endeavors should be regularly evaluated.In the long-term either external research funding must be secured, or the work must be funded as part of operational costs.We have only begun to formalize work processes to assess SIMON's cost and benefit on a regular basis, and to organize our efforts to seek collaborators, secure external funding, and otherwise leverage SIMON's value over the long-term.

Project Champions Are Crucial
SIMON and similar efforts involve individuals with diverse skills, interests, and commitments.Project champions are important to bridge cultural barriers, secure resources, establish vision and long-term goals, and to motivate the team especially through short-term setbacks.Ideally, project champions are well-respected both within and outside their disciplines of expertise, have substantial time and energy to devote to the project, and have access to resources needed to "seed" new research or development efforts.
Over the years, SIMON's project champions have helped achieve consistent reliable operation in the face of practical problems.One such challenge was in reliably identifying patients.Early in SIMON's implementation, our institution did not have a consistent real-time electronic source of bed occupancy data.A web-based patient identification system was developed, and its continued regular use by unit staff would not have occurred without project champions emphasizing its importance.A similar challenge occurs with connecting portable bedside devices to SIMON; without project champions to underscore the importance of these tasks and to lead by example, even relatively straightforward practical issues can bring the project to a halt.

Future
Moving forward, we envision a number of new applications supporting both research and clinical use of dense physiologic data.Routine, high-fidelity capture and real-time analysis of physiologic waveforms will become commonplace.A formal data repository for research purposes will be constructed to routinely merge and de-identify data from SIMON and other clinical information systems.Such a repository facilitates making data available to other researchers both within and outside our institution.As we discover new algorithms to stratify patients based on acuity, mortality, and/or type of injury, we expect to deliver this information using our existing reporting and alerting mechanisms, as appropriate.The next generation of algorithms will likely be much more patient-specific, dynamically adjusting critical thresholds and other parameters based on individual patient attributes and clinical course.In the long-term, controlled clinical trials will be needed to assess the value of new physiologic measurements and the decision-support tools used to bring them to the clinical bedside.

CONCLUSION
SIMON's value to date arises primarily from its large repository of physiological data supporting research analyses.Furthermore, the system's real-time, automatic, and reliable operation facilitates data display, reports, and alerts that potentially enhance clinical decision-making.However, the clinical value of SIMON and similar systems in terms of improved outcomes, process efficiency, or other beneficial changes in practice remains largely undocumented in a rigorous fashion.Results from future trials, and the foundational work we and our colleagues elsewhere are now undertaking, will define new patient monitoring strategies and establish the value of dense physiologic data capture, analysis, and decision support in caring for the critically ill.

Figure 1 .
Figure 1.SIMON Components and Architecture.Grey arrows show communication paths between components.Bedside devices (left) interface to data collection modules via RS-232 over TCP/IP (Digi International, Minnetonka, MN).The Data Concentrator stores all data to the SIMON Database via an Open Database Connectivity (ODBC) interface.Numerous other system components then access this data via ODBC to perform analysis and system management functions.Notifications are sent to alphanumeric pagers and email via Simple Network Paging Protocol (SNPP) and Simple Mail Transport Protocol (SMTP), respectively.Interfaces to the institution's (Vanderbilt University Medical Center, VUMC) admission-discharge-transfer (ADT) tracking system and electronic medical record (EMR) are implemented via secure file transport protocol (sFTP).

Figure 2 .Figure 3 .
Figure 2. SIMON Data Graphs Over 24 Hours.Parameters shown on upper graph: heart rate (red), arterial pressure (blue, with mean in dark blue), pulmonary arterial pressure (green), end diastolic volume index (magenta), cardiac index (scaled × 10, purple).Parameters shown on lower graph: arterial O 2 saturation (dark green), venous O 2 saturation (light green), intracranial pressure (blue), cerebral perfusion pressure (orange).Several signals do not span the entire period due to pulmonary and intracranial catheters being removed from the patient.

Figure 4 .
Figure 4. Portion of SIMON Daily Unit Ventilator Report (8/14 beds shown).Bold indicates critical value, plus and minus signs indicate recent trend in values (minus = decreasing, double minus = acute decrease, and reciprocally for plus signs).
328 SIMON: A Decade of Physiological Data Research and Development in Trauma Intensive Care 330 SIMON: A Decade of Physiological Data Research and Development in Trauma Intensive Care time.These issues were addressed by defining administrative processes by which: