John Zaleski, Ph.D., CPHIMS

Those individuals who have been following my blog for a while now know of my penchant for technology in healthcare, particularly as relates to the use of data for promoting patient safety, monitoring, and managing patient state. Recently, I purchased the iHealth dock, made by iHealthlabs, shown in the figure below, to evaluate as I do with many other healthcare related technologies. One of my interests is in the use of smartphones for monitoring and managing personal health and well being.

iHealth Docking Station

The iHealth unit provides a docking station-based automatic sphygmomanometer for either an iPad or iPhone to facilitate blood pressure monitoring and management. The unit (i.e., docking station)
prices out around $100, although I have seen some deals on Amazon.com as low as $35 or so.

Upon purchasing the unit you then download the app from the Apple App Store for free. This is all you need, in essence, to begin self-monitoring blood pressure and heart rate through the unit.

Chart created automatically by Visual Basic application created within Excel spreadsheet. Written by John Zaleski. (c) 2013. All Rights Reserved.

The following linkis my latest course charts on medical device connectivity / medical device interoperability given at the Baltimore Smart Tech Conference in November 2012. I decided to post an abridged version of this document based upon popular demand. The document contains some references and information from my earlier books on medical device connectivity and the EHR.

IEEE Smart Tech is coming to Baltimore this November. Early Bird Registration ends 9 September 2012. IEEE Member cost is $129 and Non-Member cost is $159. Regular registration begins September 10th and the cost goes up 50$ for both Member and Non-Member registration. Reservations and a copy of the workshop agendas can be found at http://www.ieee.org/metroevents.

I am giving a workshop entitled “Biomedical Device Connectivity in Electronic Medical Record Integration” on Saturday, November 3rd. This will be an all-day affair. Topics include:

1. Electronic health records and how medical device data are integrated

2. What it means to integrate data into health information systems–from technical details to workflow implications.

3. Standards in healthcare surrounding medical device data integration.

4. Examples of integration.

5. Future of medical device data integration, including uses of these data to facilitate clinical decision making.

Hope to see you there.

Biomedical device connectivity challenges are being addressed at Virtua by Nuvon, Inc.:

“About three months ago, Virtua went live with a middleware solution (supplied by Nuvon, Inc…. that streamlines the collection of data and eliminates the need to record the data manually from the device…Its first implementation was in the hospital system’s Ors–one of the tougher environments because of the large amount of data being pulled from many devices.”

I received a ping to a new comment on an old post I had written on Tim Gee’s site regarding medical device connectivity. The title of the post was Medical Device Open Source Frameworks and in this post I had written about creating ubiquitous connectivity to medical devices through standardized connectivity, similar to the way USB devices operate: plug into a port and they are recognized.

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.

Day 1 of the 22nd Annual AAMI/FDA International Conference on Medical Device Standards and Regulation in Herndon, VA is concluded and a lot of good material to report on. Key first item is the  AAMI SW87 document which aims to focus the FDA Quality System Regulations (QSR) on the  development of MDDS. A training webinar is scheduled for April 12th, 2012. For particulars, visit the AAMI web site.

The SW87 document was produced in 1 year and is focused on MDDS development. The SW87 defines MDDS as follows:

Per 21 CFR 880.6310, “a medical device data system (MDDS) is a device intended to providde one or more of the following uses, without controlling or altering the functions or parameters of any connected medical devices

(i) The electronic transfer of medical device data

(ii) The electronic storage of medical device data

(iii) The electronic conversion of medical device data from one format to another format in aaccordance with a preset specification; or

(iv) The electronic display of medical device data

An MDDS may include software, electronic or eletrical hardware such as a physical communnications medium (including wireless hardware), modems, interfaces, and a commmunications protocol. This identifiation does not include devicess intended to be used in connection with ‘active patient monitoring.’”

I intend to cover other aspects of the meeting, including a medical device interoperability taxonomy, in tomorrow’s blog entry.

Page from EMBS publication on modeling post-operative respiratory state

Back in 1998 I wrote my first scholarly article on the topic of modeling as it relates to human body systems. The focus of the article was to demonstrate how data collected from bedside medical devices could be used to model specific behaviors and trends that could then be used for predicting future state in critical care patients. This paper was published in IEEE’s EMBS magazine.

Throughout the years I have kept a close eye on the subject of data and clinical decisions based upon data. This is what led to the writing of my second book.

As electronic medical record (EMR) systems have advanced and evolved, the subject of data and clinical decisions has evolved as well, and for good reason. Many illnesses can be better managed or even detected through the collection and management of data, both form durable medical devices and laboratory instruments. A key illness among them is sepsis. Going back to 2008, Health Data Management described the use of bedside data that fed physiologic monitor based models for detecting sepsis in near real time.

Sepsis, or septicemia, is a leading cause of death in ICUs, especially among the elderly. The CDC reported in 2008 that the cost of sepsis management alone broached $14.6B (source: HealthLeaders Media). According to the same source, “[h]ospitalizations for … sepsis as a [primary] diagnosis grew from 326,000 in the [year] 2000 to 727,000 in 2008.” The number is not declining in 2012.

A key element in the management of sepsis is data. Data and clinical decisions surrounding changes in body temperature, heart rate, elevated white blood cell count OR lower-than-average temperature are also signs. Elevated pulse, highe respiratory rate in combination with these and other parameters such as end tidal CO2 changes are all measurable quantities. When combined these data are instructive as to cause. Many elements can be retrieved from the physiologic monitoring equipment, laboratory information systems and other devices (mechanical ventilators) that reside at the bedside of the patient.

It is important to realize that the completeness of the electronic medical record is not just in the notes that are recorded by the clinician at the bedside of the patient, but also in terms of the availability of all information recorded on the patient. Together, this information provides a powerfully instructive set that, when properly mined and properly analyzed, can lead to prospective assessments and early diagnoses of potentially life-threatening ailments…and the source of this rich information is data.

The HIMSS 2012 Daily Insider on Tuesday, February 21st included an article entitled “Agility Through Regulation,” discussing the incentive the final FDA ruling on Medical Device Data Systems (MDDS) has had on enterprise-wide medical device connectivity. This article by Mary Carr discussed the motivation that the MDDS ruling, made by the FDA in February 2011, had on hospitals to begin their migration away from piecemeal, home-grown connectivity solutions and to align on enterprise-wide solutions. The objective in aligning on system-level integration is to foster homogeneous interoperability and connectivity, both at the durable medical device level and informationally through the various healthcare information systems throughout the hospital.

The MDDS ruling by the FDA reads in part:

“…This regulation classifies as class I MDDS only data systems with specific intended uses and functions. Those device data systems that include any uses beyond, or that are for intended uses different from, those identified for an MDDS will remain class III devices. FDA has determined that MDDSs can be regulated as class I devices because general controls provide a reasonable assurance of safety and effectiveness for this device type. In making this determination, FDA has considered that the risks associated with MDDSs are generally from inadequate software quality and incorrect functioning of the device itself. These failures can lead to inaccurate or incomplete data transfer, storage, conversion according to preset specifications, or display of medical device data, resulting in incorrect treatment or diagnosis of the patient. Based on FDA’s knowledge of, and experience with, MDDSs, FDA has determined that general controls will provide a reasonable assurance of safety and effectiveness of MDDSs, such that special controls and premarket approval are not necessary to provide such assurance.

“…Based on the preamble to the proposed rule, and the comments received in response to the proposed rule, FDA is now finalizing the reclassification of medical device data systems from class III to class I. This classification will be codified at 21 CFR 880.6310. To meet the definition of an MDDS under § 880.6310, a data system must be intended for the ‘‘transfer,’’ ‘‘storage,’’ ‘‘electronic conversion * * * in accordance with a preset specification,’’ or ‘‘electronic display’’ of medical device data, ‘‘without controlling or altering the functions or parameters of any connected devices.’’ This classification excludes any data systems with intended uses outside the scope of this rule …

“…an MDDS only communicates medical device data. For purposes of this rule, data that is manually entered into a medical device is not considered medical device data. However, if manually entered data is subsequently transmitted from a medical device as electronic data it will be considered medical device data. A device that then transmits that data or is intended to provide one of the other MDDS functions with regard to that data may be an MDDS. In response to requests for clarification, the use of ‘‘real time, active, or online patient monitoring’’ in the proposed rule has been replaced to indicate that an MDDS is not ‘‘intended to be used in connection with active patient monitoring.’’

Ms. Carr identified several key and salient points related to the FDA’s position on the integration of durable medical device data:

1) Piecemeal integration leads to silos and organic separation of information. My comment: piecemeal separation is anathema to large enterprises interoperability in which patients need to be transferred around the hospital. This makes for difficulty in sharing of patient information as needed as they roam or are moved from department to department.

2) Silos are often unable to deliver real-time patient data reliably to centralized information systems. My comment: data synchronization to ensure the latest time-aligned data may be absent.

3) Vendor-dependent solutions lead to internal battlegrounds. My comment: this will be a challenge for some time to come. In my opinion, and based on the industry at-large, the right answer is to target enterprise-wide solutions that meet the scalable and flexible needs of the institution and allow for expansion and growth. Eventually, durable medical devices will speak in accordance with common physical and semantic standards, and this problem will go away (see the IHE PCD Wiki).

In both of my books I have written about the need for ubiquitous medical device data integration. It has taken a long time (decades) to reach the point of some commonality in terms of semantics and messaging since I started out in the field. It will take a while longer to achieve will interoperability of medical devices in the physical connection department. The focus will need to shift on the use of the data for clinical decision making. Some medical devices are beginning to make the shift to network connectivity as their primary physical mode of communication and transmitting HL7 transactions from the machine itself. Many medical devices will need to make this shift. Furthermore, the ability of medical devices to accept commands from external systems is an aspect that needs to happen to support higher-order command and control (C3I) type functions that make use of extended situational awareness around the device and the patient. Again, I believe this is beginning to happen and will continue to happen. It is a matter of time and continued proselytization. The era of data collection from durable medical equipment where I began my healthcare career some 20 years ago has changed some in this department and will change further. I believe we as an industry are on the verge of a breakthrough and great acceleration in this department.

When I began conducting my own research ~20 years ago, I envisioned interaction among large numbers of databases from which I could automatically draw needed information to assemble the models I required to verify performance of one patient in comparison with a population of patients having the same specific characteristics. The comparison of a test patient with a population was not only the basis for my predictive methodology but a basic tenet of Bayes’ Theorem and conditional probability. I envisioned back then a day would come when all the data I was attempting to cobble together by hand and by computer would be readily available… perhaps 10 years down the road.

Fast forward to today.

In the AHRQ’s opening FAQ about what comparative effectiveness research (CER) is, they state that, they state that “Comparative effectiveness research is designed to inform healthcare decisions by providing evidence on the effectiveness, benefits, and harms of different treatment options.”

Physicians rely on evidence, in the form of corroborating (and some contradictory) studies to validate and verify hypotheses related to treatment. Accepted treatments and approaches for care are those most usually associated with corroborating evidence–a great deal of corroborating evidence. Not all data arrive in the form of simple measurements. Data take on the form of studies, published research papers, laboratory results, films, guidelines, textbooks, and from bedside medical devices.

To a degree, the electronic health record (EHR) was seen as a key element in achieving the type of data richness that was necessary to support comparative effectiveness research. The EHR and its adoption are necessary but (yet) insufficient in terms of the CER enterprise. In “Optimizing Health Information Technology’s Role in Enabling Comparative Effectiveness Research“, Navathe and Conway note that “…[f]or CER to be conducted, …EHRs must be connected to data networks enabling access to at least portions of their captured data. It will be challenging to implement EHRs on a large scale and to develop electronic networks substantial enough to produce observational data that alter clinician, patient, and other decisions.”

As Navathe and Conway state, healthcare data is not just personal, it is a strategic asset upon which basic research depends. Despite visions of a unified, singular database “Borg” where all data would go to be mined endlessly by large mainframes, the facts most probably near term and into the future are that data will be federated. They will reside in many different pockets “owned” by many separate and disparate institutions large and small. The key, then, to my mind, is not figuring out how to assemble them into some common structure, but enabling their inter operative interaction, much the way the Internet operates today. When we type in a Google query, we are not interacting with some great big “WOPR” computer (references to the 1983 movie WarGames), we are interacting with millions of computers around the world.

What I did not realize 20 years ago that I have finally come to realize is that I thought then the “hard” problem was solving the predictive model for the patients I was monitoring, when the really hard problem was assembling all of the data together from the many disparate sources. Through all of the standards committees and claims of interoperability, we are really a long way off in terms of enabling the one thing that would allow us to do what I had started out almost 20 years ago doing: automating the data collection, from any source, that would allow us to focus on the real business of health care research, and would enable the vision of comparative effectiveness research.

Some months ago I meant to put this on the blog and it has been sitting in draft form wallowing.

In reference to the medical device alarms topic, there is a very good source for high frequency and fidelity monitoring data. The MIMIC-II database is an excellent source for waveform level modeling data taken from critical care patients and deidentified for use in research. A key reference for the scope of the data found in the database (which is generally available for access at no cost) can be found in the following paper:
Saeed et al:, Multi-parameter Intelligent Monitoring in Intensive Care II (MIMIC-II): A public-access intensive care unit database

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.

Yesterday I attended an NSF grant status review at the University of Pennsylvania. I had a chance to visit with some old friends of mine and to reacquaint with some new friends. It is striking to me the energy in the area of systems engineering in the medical field that has taken place since I was a student there some 16-20 years ago. When I was a student at PENN, the notion of applying systems engineering to medicine was not even a field: it was the study of one lone student in the department. I am happy to see such growth.

While I cannot get into the specifics of the discussions of the various projects, I will lend my overall impressions vis a vis the types of concepts that are being focused on, and that are a major focus in healthcare and medicine today.

Useful use (as opposed to Meaningful Use) of data within the enterprise is a huge objective in the treatment of patients:

1) using past information and history to assist in reducing the likelihood of readmissions;

2) better management of those patients, particularly in critical care who are likely to suffer from sepsis, ventilator acquired pneumonia, etc.;

3) reduction in the number of medical device alarms that bombard the clinicians;

4) better use of integrated information through application of interoperability standards.

All of these areas are of high value. As I noted in my “outbrief” at the end of the meeting, my views, while highly motivated by pure research, are more governed by the pragmatic from the perspective that I live with customers and their problems, and this motivates me to write on areas that are both pragmatic but motivated by research interests of my own.

The term “Big Data” has often been used, and by itself is nothing more than marketing tripe. To my mind, systems engineering and the various concepts related to it, from situational awareness to systems of systems engineering, has been around a long, long time, primarily as related to the aerospace/defense industry (a former industry of my own). What is becoming more and more clear is that the effective use of data–not just mining it for whatever trend falls out of the net–is the real value. Combining specific information associated with diagnoses and then determining from that which patients are likely to be readmitted; which patients are likely to respond favorably from a certain course of treatment, etc. are outcomes assessments that carry with them great value but also great responsibility.

Pragmatically, most hospital systems that I have been involved with professionally are still at the stage of connecting the dots: getting information from point A to point B. As is typically the case, large academic research institutions are out in front looking at the why and wherefore of what to do with the information–the futuristic. Once something becomes generally accepted in clinical practice, that is when the futuristic becomes commonplace.

Yet, something else is happening now: I see even smaller community hospitals beginning to look at the futuristic from the perspective of how it can assist in the commonplace practice of medicine. It is not just the matter of connecting the dots of how data gets from one point to another; or how certain functions (e.g.: CPOE, eMAR) need to be rolled out into the institution, but what happens with the information after that. Interestingly, a motivation for this is the care and management of patients with chronic ailments and/or co-morbidities. Managing the patient once he or she leaves the hospital is of much more interest, regardless of the size of the institution.

Assisting in this management is the effective study of past history and increasing situational awareness surrounding patients in their home environments as well as in the hospital and how they compare with respect to peers. This is the focus and benefit of big data–where it is going. And we are at the beginning.

Healthcare IT News has just published a piece on the 5 ways in which IT can manage chronic diseases. The top three are:

1. Patient monitoring tools/medical devices.

2. Mobile applications

3. Clinical decision support systems

These should come as no surprise. Patient monitoring of glucose levels and weight through medical devices in the home enables a patient to manage quantitatively what these values are and to communicate effectively without vagueness as to the levels measured. Furthermore, management through objective, quantitative approaches remove the ambiguity with which patients report to their primary care physicians and reduces the possibility of “hedging” or underestimating (overestimating) what these values might be. Getting into the habit of recording (automatically or manually) the measured values also is an activity and behavior that patients can get into and can look forward to as part of their daily activities. Measurement of the values also provides a measure of “connectedness” from the perspective of communicating to their care providers.

Mobile applications logically accompany the above medical device measurements but also provide a way to record behavior related to diabetes, asthma, weight, diet, etc. Their ease of use on mobile devices such as iPhones also make them close at hand (no pun intended). Ease of use and making part of the daily activities (phone use, internet accessibility) is a key to adherence.

Clinical decision support systems can provide remote alerts and notifications both to the patient and to the provider through vehicles such as email and can provide needed information at various stages of the care management process, whether ailments are chronic or not. While the primary focus of decision support systems has been assisting the care provider in diagnoses and treatment, they can also serve to provide reminders to patients to perform functions that otherwise might be overlooked: glucose measurement, weight measurement, medication administration, for example. Simple alerts to remind a patient that it is time for a measurement or time for a medication can be invaluable to compliance.

For related discussions on clinical decision support, medical devices integration, mobile applications, or chronic disease management, see these links.

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.

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: