John R. Zaleski, PhD, CPHIMS

Check out this graphic on Frugaldad.This shows the evolution of technologies over the past several decades. Very interesting.

Attending Day 2 of the 22nd Annual AAMI/FDA Summit on Medical Devices.

The importance of medical device connectivity and the medical device data system, or MDDS, ruling taken together with electronic medical record (EMR) technology is, in my mind, driving toward the ultimate goal: how to integrate medical devices as part of the system architecture within the healthcare enterprise to support clinical use cases. The MDDS ruling has, in my mind, had the effect of codifying the methods and mechanisms that relate to communicating durable medical device data to the electronic medical record. Similarly, this has raised the awareness of integrating such information into the EMR charting system. Yet, this is really only the first step in the process.

The interaction of the many systems that clinicians use as part of the care and management of the patient involve interoperability among many verticals in the healthcare environment, to include medical device connectivity. The interaction of data from durable medical devices with the more information-based and clinically specific systems make up the larger medical device data system architecture.

The following figure, referenced from Wikipedia, is one source of the “Interoperability Taxonomy” adapted for presentation during the medical device interoperability presentations.

Levels of Conceptual Interoperability Model (LCIM). Source: Tolk, A. and Muguira, J.A. (2003). The Levels of Conceptual Interoperability Model (LCIM). Proceedings IEEE Fall Simulation Interoperability Workshop, IEEE CS Press

The hierarchy presented in the figure above maps well to medical device connectivity. The first three levels, that is level 0 – level 2, correspond, respectively, to medical devices that are not connected; medical devices that have some form of physical connectivity; and, medical devices that support the ability to syntactically communicate data with other medical devices as well as with information systems using methods such as HL7 messaging. Many hospital systems today that feature medical device connectivity are in the Level 0 to Level 2 range.

Higher levels of interoperability, such as semantic interoperability, are works in progress and organizations such as IHE are engaged in areas of syntactic, semantic and pragmatic interoperability.

The definitions offered per the LCIM model are as follows:

• Level 0: Stand-alone systems have No Interoperability.
• Level 1: On the level of Technical Interoperability, a communication protocol exists for exchanging data between participating systems. On this level, a communication infrastructure is established allowing systems to exchange bits and bytes, and the underlying networks and protocols are unambiguously defined.
• Level 2: The Syntactic Interoperability level introduces a common structure to exchange information; i.e., a common data format is applied. On this level, a common protocol to structure the data is used; the format of the information exchange is unambiguously defined. This layer defines structure.
• Level 3: If a common information exchange reference model is used, the level of Semantic Interoperability is reached. On this level, the meaning of the data is shared; the content of the information exchange requests are unambiguously defined. This layer defines (word) meaning. There is a related but slightly different interpretation of the phrase semantic interoperability, which is closer to what is here termed Conceptual Interoperability, i.e. information in a form whose meaning is independent of the application generating or using it.
• Level 4: Pragmatic Interoperability is reached when the interoperating systems are aware of the methods and procedures that each system is employing. In other words, the use of the data – or the context of its application – is understood by the participating systems; the context in which the information is exchanged is unambiguously defined. This layer puts the (word) meaning into context.
• Level 5: As a system operates on data over time, the state of that system will change, and this includes the assumptions and constraints that affect its data interchange. If systems have attained Dynamic Interoperability, they are able to comprehend the state changes that occur in the assumptions and constraints that each is making over time, and they are able to take advantage of those changes. When interested specifically in the effects of operations, this becomes increasingly important; the effect of the information exchange within the participating systems is unambiguously defined.
• Level 6: Finally, if the conceptual model – i.e. the assumptions and constraints of the meaningful abstraction of reality – are aligned, the highest level of interoperability is reached: Conceptual Interoperability. This requires that conceptual models are documented based on engineering methods enabling their interpretation and evaluation by other engineers. In essence, this requires a “fully specified, but implementation independent model” as requested by Davis and Anderson; this is not simply text describing the conceptual idea.

Months ago I wrote about the AAMI Summit on Clinical Alarms. This prompts some ideas for research to mitigate nuisance and general patient medical device alarm problems:

1. improving signal to noise (specifically, sensitivity / specificity): reducing data overload / information underload would limit “nuisance” alarms;
2. need for device intelligence: for example, the medical device alarm has context for which awareness and the ability to adapt to a specific situation would reduce the occurrence of artifact;
3. human-machine interfaces: improved usability through refined/redesigned human / machine sensory interface;
4. multisource data fusion: integration of data from multiple devices in a manner that provides for a fusion of knowledge and situational awareness that would not be available from these devices separately; and,
5. historic and prospective trending: deterioration trending of patients over time using historic data as well as models of prospective evolution.

Historic information provides some notion of what is risky for patient: events and information from multiple sources can establish an a prior assessment of whether a patient is experiencing distress. These conditions are not unique and have been seen previously by multiple clinicians over time. Hence, the historical information can be a great filter for establishing what is real and what is not real in terms of alarms and medical device alarm management. Just as automatic feedback control systems provide a feedback to the plant model as to deviations from expected performance, such is analogous with medical device alarms.

Part of the challenge is how to combine the information from multiple sources. This combination of information is not simply co-displaying them in a common format or user interface. It is presenting the data intelligently to the end user, possibly in a processed manner that determines, based on their combination, whether the result is a bona fide alarm condition. This rather cerebral aspect of the processing is the dilemma. Leaving out even the regulatory aspects of the situation, understanding what the processing is actually doing–the “plant” part of the automatic feedback control system–must be represented accurately.

A medical device alarm from a single device provides an indicator with respect to the sensors that are being measured for that one device. For instance, a physiologic monitor that is only measuring pulse and ECG cannot report an alarm on End Tidal CO2 or respiratory rate. On the other hand, a mechanical ventilator cannot report an alarm on heart rate or on ST segment elevation. The two devices report medical device alarms according to their particular sensors and objectives. However, the combination of the two devices can provide corroborating evidence. For instance, an ASYS alarm could be caused bya lead disconnecting from the physiologic monitor or from the patient. But, an ASYS alarm occurring at the same time as an APNEA alarm would provide corroborating evidence. This is rather a tragic example, but one that demonstrates the correlation of two events.

The fusion of multi-source devices can also provide a mechanism for reducing data overload while at the same time increasing useful information is one that I find to be very interesting. There are many research efforts surrounding modeling. Yet, integrated system modeling (multi system integrated assessments) has really yet to be shown (publicly) as viable in medicine–and generally accepted in operational use, not to mention for medical device alarms.

I would like to leave this here for now and follow-up in more detail on these areas. The medical device alarm field is fertile ground for integrated systems engineering application.

My recent participation in an NSF Grant review at PENN on Tuesday and, in particular, Dr. C. William Hanson’s overview briefing during that event, brought to mind some things that he and I had worked on back in the early to mid 1990s. During the course of the presentations, which I found to be very fine and informative, it had occurred to me that basic research is still being conducted in areas that remain relatively untouched or unresolved today, some 16 years later. At the tail end of my dissertation it had been requested by my committee (Dr. Hanson in particular) to lay out key areas of future research that could stand upon what we had done and, in particular, focus on the problem of automation.

Extracts from that long-ago written conclusion read as follows:

“Develop… a larger database of spontaneous minute volume data to verify that it is possible to achieve a more accurate interpolation methodology…”

“Develop…a database of respiratory state data that can be easily recalled for real-time diagnosis and analysis by the critical care staff…by providing an easy way to download this information for…processing would permit the storage of each patient’s data, along with information on patient condition, to be used to classify each patient according to surgery.”

“[A]utomate the weaning process…motivated in part by the need to safely reduce costs and instill more uniformity in the respiratory weaning process across a larger patient population. Moreover, one desirable quality of such an automated methodology is that is would not require the input of such information as patient mass, gender, …anesthetic dosages…to operate effectively. The control system responsible for regulating patient respiratory support should use only that information available through the ventilator…Evidence and trends in patient care exist to suggest that automating post-operative weaning in patients who are not problematic is not only possible, but inevitable as hospitals strive to streamline and reduce the costs associated with critical care medicine.”

The conclusion then goes into the specific algorithm for reducing the support automatically. Undoubtedly, another research focus altogether. Nonetheless, this was written in 1996. Evidence-based medicine is a key objective in the application of treatment today. Furthermore, the databases that were referred to in the research do not (yet) exist today. There are clinical information systems, electronic health records (EHRs) and electronic medical records (EMRs), and varying levels of discrete data that comprise them. But, the level of data richness described in that conclusion still does not exist today.

The one key reason I focused so heavily in my career on medical device connectivity has been because of the inability to uniformly collect the information at the bedside so necessary to support these types of research (and, ultimately, to support the care models related to automated management). While there certainly exist safety concerns surrounding the automated aspect of any process in healthcare, the objective at that time was to provide more uniformity around the process of weaning. Furthermore, respiratory weaning was merely an exemplar to serve as an expression of the larger application of predictive methodologies based upon data normally collected at the bedside.

In order to improve situational awareness it is necessary to have access to the latest information. Part of that situational awareness relates to the observations collected from the patient. Observations in the high acuity spaces comprise the visual, audible and sensory based set that every clinician is familiar with. These are further augmented by historical information, patient demographic, and the training that each clinician receives. Integrate, fuse, or otherwise combine these data together and the situational awareness increases greatly. It is this situational awareness that was sought to be demonstrated through the research at that time and remains an important focus of future research.

Much has happened in the span of time since I graduated from PENN. The IHE, IEEE standards, and interoperability in general have advanced greatly. The research I had begun in the 90s that related to automation and data integration provides potential graduate and undergraduate students seeking to advance their knowledge through the pursuit of both Ph.D.s and Masters degrees with a great opportunity to advance the areas of automation, automated feedback control, and modeling far beyond its current state. While much has been done in the field since I was a student–almost 20 years ago–much remains and I believe the field is on the verge of really taking off, given the advances in interoperability that have occurred to date and the energy and focus on integration of data from various disparate sources within the healthcare domain.

Note: Links to external sites are not to be taken as an endorsement by the author.

Medical Device Alarms Summit

The AAMI Medical Device Alarms Summit was held October 4th & 5th in Herndon, VA at the Hyatt. There will be much published on the AAMI web site in this regard, and much in the way of out-briefs and collateral so I will leave the complete minutes and summary of activities and goings-on to those charged with doing so. However, I am compelled to focus on a few related themes that were referred to by several of the speakers and to which I voiced my opinion publicly during the meeting. I will do so relative to two specific speakers and provide the input that I shared at the conference during the public question and answer forums.

Medical Device Alarms Keynote Presentation

The keynote speaker  on medical devices was given between 8:45 and 9:15 by George Blike, MD of the Dartmouth-Hitchcock Medical Center. Early in his presentation, Dr. Blike discussed that not much has changed since the 1999 Institute of Medicine Report To Err is Human was published. In that report, the IOM concluded, based on two studies, that between 44000 and 98000 Americans were killed each year due to preventable medical errors. While the options to diagnose and treat have increased measurably since that time, the complexity of the treatment process undermines the benefits. This is also the case of information complexity, in which the amount of information that is now available in electronic form exceeds the environmental space limitations surrounding the patient.

Medical device alarms, Dr. Blike continued, as a way to redirect attention, about redirecting attention “from something that is less important to something that is more important.”

However, uncertainty plays a large role in medicine, and the uncertainty about the meaning of alarms requires knowing much more than just whether a parameter is outside some norm or threshold. It is about knowing the context surrounding the patient. It is more than managing alarms as “nuisances” in the clinical space. While it is true that clinical staff can become “snow blind” to the continuing cacophony of alarms within the environment, the reason for reducing the alarms is not to reduce the cacophony, but to focus the alarms to redirect attention in a way that truly helps the patient.

Dr. Blike referenced Lucian Leape, MD: “Anesthesia is the only system in healtchare that begins to approach the vaunted six sigma level of perfection that other industries strive for.”

The management of a patient becomes more like a feedback control problem, in which the process blocks of Detect, Diagnose, Treat and Monitor are key to the closed loop system. In an environment where upwards of 40 parameters must be monitored over time (ICU), it becomes a multi-dimensional, multi-parameter feedback control system exercise. In environments such as the ICU where nursing:patient ratios may be 1:2 or 1:1, the care team must be able to detect problems, diagnose cause, treat, and then monitor. As part of this process, the medical device alarms identify deviations of the system state of the patient from the expected state.

Medical Device Alarms: Defining the Problem

The keynote address of Dr. Blike was followed by a panel titled “Defining the Problem: It’s More Than a Nuisance.” James Blum, MD of the University of Michigan Health System and Barbara Drew, RN, PhD of the University of California, San Francisco were the members of this panel. With no disrespect to Dr. Drew, who had an impressive and extremely interesting and informative presentation, I wish to focus on the comments of Dr. Blum because of the message he communicated in terms of systems integration and data management. I resonated most definitely with Dr. Blum’s presentation as it has been a rallying call of my own now for almost 20 years (indeed, a large reason for my entry into the field).

I took some photos of slides, and there are three that speak strongly to me. The first of these is the slide on physiologic monitors, shown below. The key point is that alarms, in general are not “smart”, and this is especially true of physiologic monitoring where, in which there is no “penalty for high sensitivity with low specificity,” and a general lack of data integration. However, the historic and retrospective data is not readily available nor can prospective analysis and projection be performed with the data. Moreover, these data are not integrated with the wealth of other information that provides context on the patient. While it is true that alarms that are of a critical nature (e.g.: ventricular tachycardia or asystole need no other context, there are situations which do (e.g.: O2 Saturation changes, respiratory function changes) and thus it is important to incorporate the context surrounding the patient into medical device alarms.

The second of these charts from Dr. Blum is one that resonates very strongly with me: Electronic Medical Records may be good charting instruments, but in terms of their clinical decision support capacity relative to real-time data, they are very mediocre. The reason I say this is because of  the last two bullets on his slides: the data resolution can be limited (critical care charting ~ 15 minute intervals) and suffer from garbage-in:garbage:out. Because modeling of physiological systems often requires high fidelity and high resolution information, sparsely collected data will often miss crucial events that may be seconds in duration or less. For example, assessments of heart rate and respiratory rate variability can be quite important and predictive as to patient stability, as well as critical medical device alarms related to V-TACH or ASYSTOLE. The EMR is simply not equipped to capture these data trends based on the rate of data collection: the likelihood of missing these events all together is simply higher than capturing them at all.

The third and final of these slides is the following titled “Integration.” The essence of the problem with medical device alarms is that they are fairly “one-dimensional” in nature: they typically are associated with the patient care device (PCD) and its function (e.g.: physiologic monitor, infusion pump, mechanical ventilator, etc.) This does not mean that they are univariate, but rather they do not take into account the entire context of the patient and environs, as well as patient history, chemistry, etc. The Integration slide makes the point that multiple systems must be taken together–or fused–to provide an intelligent assessment of what is important versus that which is not.

Medical Device Alarms from a Systems Integration Perspective

The last of the three photos above defines to me the essence of effectively managing medical device alarms is through the application of systems engineering and systems integration disciplines. First, complete and unfettered integration of data, from medical devices through ancillary information systems (lab, PACS, EMR, etc.) are required. Next, laying out the use cases and scenarios related to the types of problems and conditions a patient can experience needs to be done in a holistic way that ignores vendor and device boundaries. This may involve integrating data, user interfaces, and creating methods that “feed” on the data available from multiple sources and assimilate it to produce integrated outputs. The display mechanisms are important but are secondary at this point: dashboards that allow singular access to information (much akin to avionics design) may be appropriate here. However, more important is the overall integration of information to provide predictive modeling, retrospective trending, and for evaluating scenarios on the fly. This takes a longitudinal look at the patient state in terms of everything about the patient. As Dr. Blum identified, there may be 40 parameters (give or take) that form the basic state of the patient.

Medical Device Alarms as a State Space Problem

When I began my career it was in the aerospace field and I focused on state space modeling of complex systems. This state space modeling often involved various forms of filtering, including Kalman and Batch Least Squares filters. The systems integration aspect of this modeling involved evaluating the trend or future state with respect to the current state based upon a system model representation of the entity being modeled. From this model, a projection could be made into the future. As was stated by Dr. Blike and others during the conference, medicine is one field where uncertainty plays a large part, it is perhaps naive to think that one could model the human being in ways that many in the aerospace industry do. However, 20+ years ago when I began my studies at the University of Pennsylvania and began my research into prediction and modeling at the University of Pennsylvania Medical Center, that is precisely what I was doing on a smaller scale with a specific class of patients. The subject of my dissertation was predicting the post-operative respiratory behavior of coronary artery bypass grafting patients, a unique class of patient in surgical intensive care units. Many of the concepts brought up during the Medical Device Alarms Summit resonated with me from the early days of my dissertation. One in particular was the idea of taking multi-source, multi-variate data and massaging into an assessment of outcome. As I did when I conducted my research, multi-source data from laboratory, patient record (history, demographics, etc.) were incorporated into the overall assessment of outcome. I know that as I followed patients from surgery through endotracheal extubation afterwards that I found many interesting relationships once all the data were laid out before me: relationships between re-warming time and patient’s anesthetic dosing; relationships time to begin breathing and time to extubate. The approach took into account the fact that there were uncertainties in the modeling. The objective was to establish a gross, coarse model of behavior by looking at the patient as a “black box.” Higher fidelity warranted more accurate modeling. However, approaching the patient as a system and taking into account all information is one approach I believe is the key to effective medical device alarms management.

 Haar Wavelets

From time to time I have been asked to provide explicit details on the mechanics and methods behind Haar wavelet transforms. The purpose of this post is to walk through two simple examples that demonstrate the use of the Haar transform relative to two one-dimensional signals (time signals). The details of the Haar basis and Haar wavelet transform are available elsewhere. The purpose here is to provide a simple example of how the Haar basis is computed using a simple tool such as an Excel spreadsheet.

 4×4 Wavelet Calculation

Let’s begin with the end product: the following is a 4×4 Haar matrix computed using Microsoft Excel:

Excel calculation of 4x4 Haar Matrix

The Haar Matrix, which we will denote Hn, is given as follows for the case of 4 data elements, denoted as Vn:

Haar Matrix 4x4 Definition

This computes to that shown in the figure above. The Haar wavelet coefficients are computed by first inverting the Haar matrix and multiplying by the output signal vector, Vn:

Definition of Haar Wavelet

Haar matrix inverse is calculated using Excel and the result is shown in the following figure:

Excel calculation of 4x4 Haar Matrix Inverse

Each cell in the Excel spreadsheet is computed using the following cell entry:

= INDEX(MINVERSE($B$2:$E$5),1,1)

Where $B$2 corresponds the cell corresponding to the first row and column of the original Haar matrix and $E$5 corresponds to the last row and column of the original Haar matrix. The elements (1,1) at the end of the expression must include the components of each cell. So, in the example above, (1,1) represents the element in the first row and column of the matrix inverse. This is place in the first cell of the Excel spreadsheet corresponding to this element. The last row and column element would be (4,4).  So, for example, the cells would be populated as such:

Time and signal vector chosen arbitrarily for this example is as follows:

Sample 4 element signal vector

A plot of this signal is shown in the next figure:

Signal vector plot versus time

The wavelet coefficients are computed using the follow expression:

Equation for 4 dimensional Haar wavelet coefficients

Excel spreadsheet calculation of Haar wavelet coefficients

It is possible to cull coefficients on some basis, such as their magnitude with respect to the largest coefficient. We can arbitrarily impose a threshold with respect to the largest coefficient (-4.9497) and remove those coefficients (set to zero) that are at or below this magnitude. Suppose we set a threshold of 30%. The wavelet coefficients with 30% threshold imposed result in the removal of the second coefficient:

Haar wavelet coefficients with 30% value threshold applied

The signal can be recomputed using this culled set of coefficients. They are calculated using the following expression:

Equation for signal reconstruction

Excel spreadsheet calculation:

Excel calculation of signal reconstruction with 30% threshold applied on Haar wavelet values.

A plot of the signal with an overlay plot of the recreated signal using 30% threshold on the wavelet coefficients is displayed in the figure below. Note the comparison between the two signals, indicating some loss of fidelity owing to the removal of the wavelet coefficient. This is a crude representation of the effects of destructive compression on the reconstruction of signals:

Signal overlay plot showing original, complete signal and reconstructed signal based upon signal "compression" achieved by applying 30% signal threshold on Haar wavelet values.

 8×8 Wavelet Calculation

The method can be extended easily to any dimension. Let us consider an application of the Haar wavelet transform to an 8×8 Haar matrix:

8x8 Haar wavelet matrix

The inverse of this matrix is as follows:

Matrix inverse of the 8x8 Haar matrix

The base signal is defined as follows:

Arbitrarily chosen 8 element, one-dimensional signal for testing

A plot of this signal provides a convenient visual rendering of the data:

Time series plot of data from base signal

The wavelet coefficients are calculated in precisely the same way as the 4×4 example shown previously:

Haar wavelet coefficients calculated using MS Excel

Finally, the imposition of signal thresholds (20% and 30%) is shown and the signal is reconstructed in the manner previously described, only extended to an 8×8 Haar matrix. The resulting plot with the wavelet threshold impositions are plotted as overlays in the following figure:

Plot of original 8 element base signal with overlay plots of reconstructed signal with both 20% and 30% of wavelet coefficients removed based on threshold calculation.

 Links to wavelet and other analytical calculations on this site

My book on modeling medical device data may be found here . Other links, such as the paper on modeling of re-awakening time are also available on this site, for the interested reader. I’ve also included a PDF version of this blog entry for download.

Medical Device Alarms Summit

The impending Medical Device Alarms Summit has caused me to do some research into the area of medical device alarms in general, and has also caused me to go back and review old papers and research of mine that are related. The conference coordinators provided links to some research material, and this research material also caused me to dig up some references to papers by one of my former advisors, CW Hanson, and colleague Bryan Marshall of PENN. Their paper, “Artificial intelligence applications in the intensive care unit,” (Crit Care Med 2001 Vol. 29, No. 2) is referenced within one of the recommended research articles co-authored by Michael Imhoff and Silvia Kuhls, titled “Alarm Algorithms in Critical Care Monitoring,” (International Anesthesia Research Society, 2006, 0003-2999/06).

Critical Care Medical Device Alarms

Imhoff describes the three classes of medical devices responsible for alarms can be classified into the categories of monitoring, therapeutic to “support or replace failing organs,” and therapeutic to “administer medications and/or fluids to the patient.” While medical devices have evolved in the area of providing closed-loop control in the form of feedback from the patient through sensors, Imhoff describes two key issues that remain in the area of medical device alarms. These are:

1) Identifying conditions for which an alarm needs “to be thrown”, and

2) the consistent and unambiguous annunciation of the alarm in a manner that makes it clear to the end-user that a critical event has occurred and can be differentiated from other such events.

 Classes of medical device alarms

In my work and my experiences, the types of medical device alarms have been legion. Imhoff describes several classes of alarms, and I will further characterize these as clinical versus technical. I view technical alarms as those that identify conditions within the device itself. For example, if a device disconnects from a patient (e.g.: a probe falls off, or a cable disconnects, or the device ceases to communicate with the middleware or interfacing system). These types of alarms, Imhoff explains, can have clinical impact. This, of course makes sense for somewhat obvious reasons.

The second class of alarms are those that are clinical: identifying conditions based on measurements made from the monitoring or therapeutic devices of danger or impending danger (e.g.: heart rate too low or too high, blood pressure too low or too high, O2 saturation too low, etc.). These types of conditions are those for which one expects alarm to be “thrown.” However, as Imhoff puts it, the failure of the technical architecture can result in the inability to detect the clinical conditions. Again, this is quite obvious. Ergo, it is necessary to notify of both technical as well as clinical failure since the failure of the technical will result in the inability to detect the clinical, especially when considering remote monitoring environments.

Medical Device Alarms and False Alarms: Detection & Modeling

Imhoff & Hanson both describe and discuss modeling and prediction techniques for identifying conditions, monitoring and modeling approaches for predicting future trajectory, that involve many different types of techniques. Key among these are artificial neural networks, fuzzy logic, Kalman filtering, Bayesian estimation, least squares filtering, and others.

In my dissertation, “Modeling post-operative respiratory state in coronary artery bypass grafting patients,”  and in the EMBS paper that followed it, found in the EMBS paper “Modeling Spontaneous Minute Volume in Coronary Artery Bypass Graft Patients,” I describe a template-based approach for predicting viability for spontaneous breathing trials. The key points being that, from a regulatory and a predictability perspective, most methods require large amounts of patient data in order to develop reliable and predictable outcomes. Deterministic behavior is required, especially for FDA approval of such methods. Hence, many methods have remained in the realm of research and clinical trials because of this. Nonetheless, the ability to reduce the overall effects of alarm fatigue and better predictability as well as improved forecasting of patient outcome remains a fertile area. I intend to report on the outcome of this workshop and am quite interested in the discussions that will ensue.

For further reading, I will (of course), point the reader to one or both of my books:

Integrating Medical Device Data into the Electronic Medical Record: A Developer’s Guide to Design and a Practitioner’s Guide to Application

John Zaleski -- Book I

and, Medical Device Data and Modeling for Clinical Decision Making:

John Zaleski -- Book II

Time synchronization of medical device data: a straightforward example

The following slides were generated by this author and presented at the FDA Workshop on Interoperable Medical Devices in January 2010. Perhaps an esoteric but important challenge in patient care management and clinical research is the time alignment of data streams automatically collected from patient care devices (PCDs). Data collected from individual patient care devices may contain (1) local time stamps from the devices themselves that are not synchronized with common clocks; and, (2) queries of these patient care devices for their data may not be synchronized with independent queries for similar data from other patient care devices, resulting in data that are not synchronized with one another.

This case is illustrated in Figure 1 below in which a sampling of multi-parameter data collected from a patient who has undergone coronary artery bypass grafting surgery is being monitored in time. As can be seen the plots of individual parameters (again, only a small subset shown) describe the evolution over time.

Figure 1: Continuously monitored data from multiple patient care devices collected on coronary artery bypass grafting patient

Discrete data points show lack of time synchronization

In Figure 2, the individual data points from the separate patient care devices are overlaid on the continuous data, illustrating that these discrete points are not time synchronized in terms of their query or resulting output.

Figure 2: Time synchronization of individual data points from patient care devices not enforced

Data reporting at any particular instant illustrates time synchronization need for patient care device data

the plot of Figure 3 illustrates the need for time synchronization of patient care device data. Should a data request from all devices be made at a particular instant, certain data may be “stale.” That is, lack of time synchronization can result in data that are old or not current. If the query frequency of data associated with a patient care device not be aligned in time, then should a request for data be issued, the data that are available may be that which is valid at a previous time stamp.

Figure 3: Example data reporting time showing the lack of alignment of data availability for multi-parameter devices that may occur due to lack of time synchronization

Lack of time synchronization may impact clinical decision making

Figure 4 illustrates further the possible implication of lack of time synchronization: data staleness associated with misaligned or non existent data.

Figure 4: lack of time synchronization of patient care device data may impact clinical decision making

Alignment with absolute time also impacts time synchronization as each patient care device may not be using standard time clocks

Figure 5 illustrates a further complication to time synchronization: the lack of a common time clock. Should patient care devices not use or synchronize to common time standards (such as network time services within the enterprise), then the very real and common problem of time offsets will exist. The net effect of this is to cause a bias or shift offset of time in terms of data collection, making the process of time synchronization impossible to solve.

Figure 5: bias shift or offset in terms of non-standard clock usage by patient care devices

Hazards and risks associated with patient care devices whose data are not time synchronized

Figure 6 summarizes the potential hazards of receiving and using data from patient care devices whose data are not synchronized in time.

Figure 6: time synchronization -- hazards

Clinical Decision Support impacts on non-time-synchronized patient care device data

Figure 7 summarizes the impacts of time synchronization on real-time clinical decision making.

Figure 7: time synchronization impacts on clinical decision support

The end state: time synchronization of patient care device data

Figure 8 illustrates the objective: when data from patient care devices are not available at a particular reporting time, provide the capability to “fill in the gaps” by querying for these data.

Figure 8: time synchronization end state showing gap-filling of patient care device data

 Time synchronization summary

As a result of this workshop and other efforts, IHE (Integrating the Healthcare Environment) created a workgroup to begin to address what became known as Asynchronous Data Query (ADQ). The work of this group is to establish a common transaction for retrieving time-synchronized device data from patient care devices.

Other resources on this topic include my research at other locations on this site. Thanks for visiting http://www.medicinfotech.com.

Medical Device Connectivity for Mechanical Ventilators

Included here is a trackback to Tim Gee’s MedicalConnectivity Consulting web log on mechanical ventilator connectivity. This refers to the Remote Mechanical Ventilation Manager that was developed several years back. That link is actually provided here that I first presented at the Northeast Biomedical Device Conference some years back, and the essence of which is described in Book I:

VP Engineering? CTO? What’s in a Name?

I recently ran across an interesting piece that compared the VP of Engineering with the CTO. I’ll provide the link here so that proper attribution is made right away.

VP Engineering | CTO Working Definitions?

The two positions oftentimes morph together, especially in a smaller company where it is necessary to where multiple hats. In my role at CTO and VP of Clinical Applications Engineering, I find that the visionary and the operational aspects of management are almost inseparable. Being an engineering manager requires a firm technical grasp, but does not require a complete understanding of the explicit implementation–although I prefer this level of understanding. Some would say this borders on micromanagement of the engineering organization.

The CTO in contrast is more visionary. The author of the reference link included above states the following, which I find to be very true:

“…CTO’s usually can’t manage their way out of a paper bag, but have huge vision, the ability to pull an all-nighter and crank out a rough prototype of the thing they are thinking about, have the unique ability to translate complex / abstract thoughts into simple English that a non-technical end-user can understand, and a willingness (or even desire) to get up in front of 1,000 people and talk about the latest greatest thing they are working on / thinking about.  They are also perfectly happy to work collaboratively with the VP Eng while leaving the engineering team completely alone.”

This is an aspect of my personality that is true. However, I also require structure: I need to know that the engineering team is operating in accordance with a strict development process; that the technology are properly documented; that the system is well managed and maintained. In other words, once I know that the operational development organization that IS the engineering staff are working like a well-oiled engine, then I feel free to pursue the visionary aspects of the role.

Just as I provided the quoted reference for the CTO, I provide from the same source a reference in regard to key attributes associated with that of the VP of Engineering:

“They are process / management gods (and goddesses) – totally focused on building and shipping products.  Most of them are “medium technical” – strong enough to stand up to the engineers they manage, but not necessarily the best coders on the team.  A few were rock star developers; a few were non-programmers (although I think that’s more like me saying I can’t program – where the key word that is missing is “anymore” which implies I could if I didn’t have other things to do.)”

Medicinfotech Home