The use of the product in question was given as:

• a networked solution system used to monitor a patient’s vital signs and therapy, control alarms, review Web-based diagnostic images, and access patient records. The number of monitored vital signs can be increased or decreased based on the patient’s needs

Curiously only one customer was identified as having received the product, or at least this particular version of the product. While the manufacturer and product in question is a matter of public record, and available at the link, I chose not to include it here because my objective is not to repeat the recall information, but to suggest the reasons for the recall, an associated labeling issue, and offer some general lessons.

The reason given for the recall had two seemingly separate parts. The first is that “The weight-based drug dosage calculation may indicate incorrect recommended values, including a drug dosage up to ten times the indicated dosage”. This sounds like a software problem yet the fix was not to “upgrade” the software but to suggest a workaround. (I love the term upgrade to when applied to fixing something that doesn’t actually work!)  According to the FDA the firm’s letter stated that “users should enter the patient’s weight by way of the admin/demographics screen to ensure the drug dosage is calculated as intended.” (I did not find the firm’s letter on its website, but it might be one of those hidden page situations since I did find, with a struggle, two other recalls, though using the search term “recall” produced no results). Again speculating, the workaround sounds like a user dependent way to do something that was supposed to happen automatically. At least part of the value of automation is largely diminished, and opportunities for use error increased, when such additional demands are placed on the user.

The second reason given for the recall was that there may be a 5-10 second delay between the electrocardiogram and blood pressure curves (waveforms) at the central station.   This is an interesting technical issue that may be related to software and/or communication protocols. In either case it illustrates that multiple data streams may only be useful if they are properly timed stamped, and then properly aligned at the receiver. Out-of-sync data when subsequently processed either by eye, or automatically, can give erroneous and misleading results that might appear to be correct, i.e. the results could be in the category of erroneous but believable.

For one or both reasons the FDA found that, “This product may cause serious adverse health consequences, including death.” Yet it should be noted that this was a voluntary recall, as most recalls are, despite the fact that people who surely know better reported this as “FDA recalls…”

The FDA announcement goes on to say that the company pointed out that the instructions for use state that: ”For primary monitoring and diagnosis of bedside patients, use the bedside monitor. Use the…Central Station only for remote assessment of a patient’s status.” This sentence seems to be illustrative of the fundamental problem of remote information receivers and integrators that carry a disclaimer that in sum says that you shouldn’t rely on them. But isn’t the ability to rely on it exactly why you bought it? Moreover, promotional materials available on the web do not appear to echo this disclaimer. For example it is stated that ”Applications…enhance patient care management by providing rapid assessment, decision support and clinical reporting.” Does that sound like it isn’t for primary diagnosis? Or does “Data accessible from the…Central Station includes real-time waveforms” sound like those waveforms shouldn’t be used for primary monitoring? For one more example it is said that “arrhythmia events are detected with an unprecedented degree of accuracy.” Accuracy is certainly a good thing, but detecting arrhythmias at the central station when only the beside monitor is to be used for “primary monitoring and diagnosis” appears to be less than highly useful.

Furthermore the statement that the central station is only for remote assessment seems both definitional and contradictory. It is obviously for remote assessment–because it is a central station and thus remote! But then what does “assessment of the patient’s status” mean if not monitoring and diagnosis?

The disclaimer game has been addressed in these pages before. Here it seems to involve a product that is being marketed, sold and bought for exactly the reasons that the manufacturer is saying it shouldn’t be used. I didn’t spot the disclaimer language in any of the promotional materials, but maybe it is there somewhere.

So, we have here an apparent example of software driven miscalculations, network transported data that is not time synchornized, and a reminder not to use the central station for primary assessment. Important examples to remember as we charge ahead with software driven networked solutions.

[The products in the photo with this post above are not associated with the recall discussed, and are for illustrative purposes only.]

William Hyman is Professor Emeritus of the Department of Biomedical Engineering at Texas A&M University. He recently retired and has moved to New York City where he continues his professional activities.

Health IT Risks

The potential for health IT to improve both the quality and efficiency of medical care has been much noted to include more complete and timely records, ready exchange of information between providers, clinical decision support, and in turn a reduction in errors associated with the quality and availability of patient information. Efficiencies may arise from electronic capture of data which would eliminate manual entry, and time savings in accessing and reviewing patient information, and perhaps in passing information to third party payers. Additional public health value might accrue from the enhanced searchability of electronic records with respects to trends, treatments and outcomes. These benefits assume well designed, user friendly, compatible systems not withstanding that the U.S. model is to allow for numerous independent products that may or may not be able to exchange information nor display it in a consistent manner. Not surprisingly the report notes that the IT imperative will likely not be fruitful without associated attention to the people and the clinical system they work in.

However there is also the potential for health IT to add to, rather then reduce complexity; misplace, lose or garble patient information, and to provide clinical decision support that is incorrect or unreliable. Thus health IT itself has risks that the IOM found have not yet been adequately addressed or monitored. The IOM also cites the lack of an effective health IT problem reporting system compounded by contractual language that may actually impede such reporting. In addition some vendors include disclaimers as to their responsibilities even for software defects and errors. The latter suggests the all purpose liability disclaimer language: “Notice-this product may be badly designed and therefore not suitable for its intended purpose.” Alternatively one could try: “Due to software defects the information in this EHR may or may not be complete and/or may not pertain to  the patient of interest. Do not use this information for medical treatment”. The value of such disclaimers will no doubt be tested.

Of course it is not only coding defects that can make heath IT less than effective. The well established issue of usability, or user friendliness, lives on, as does interoperability, training and workflow design. In this regard it might be noted that user friendly features such as pull down menus also facilitate quick but erroneous entries. Thus while an IT product might be theoretically capable of being used properly and effectively, whether it will achieve that goal in the real environment of use, when used by real people, is a separate matter. In this regard when faced with use issues and adverse events vendors will want to say that their product could have provided the correct functionality if only it had been used correctly–and don’t forget our disclaimer. The counter argument is that it was badly designed to the degree that “correct” use was predictably not likely to consistently occur. There are many anecdotes in this regard. A favorite of mine was an order entry system to which was added a physical sticky note on the monitor that read “Do not press Enter to Enter”.

Actual health IT hazards are at least in part separate from the questions of privacy, hacking and other mischief.

It must also be remembered that quantitative data (e.g. lab results and other medical device data), or reasonably well standardized data (e.g. images) are potentially much easier to capture, transmit and display than narrative information. The selection and arrangement of information on a display can also be a significant challenge with respect to density, utility and how many pages the clinician has to look at to get all the information needed–and you can’t spread those pages out. There is also a significant issue with the lack of standardization of “look and feel” factors. In this regard it must be remembered that clinicians of various types, working in multiple environments, might see multiple systems during even a single day. This is analogous to the reality of nurse use of infusion pumps. Ask the nurse if they know how to use an infusion pump and they will most likely say yes (and be insulted). But then ask them if they know how to use a particular infusion pump and they might say, no, I’ve never seen one of those before. In this regard a health IT application may be plug-and play, but that isn’t the same as plug-and-effectively-use.

IOM Report Recommendations

The report has several specific recommendations:

• A comprehensive effort to asses safety and risk
• Vendors should support the free exchange of information about health IT experiences and issues and not prohibit sharing of such information, including details (e.g., screenshots) related to patient safety
• HHS should make comparative user experiences publicly available
• A new Health IT Safety Council should be funded by HHS to evaluate criteria for assessing and monitoring the safe use of health IT and its ability to enhance safety
• The registration and listing of products from all vendors
• Specification of the quality and risk management process requirements that health IT vendors must adopt, with a particular focus on human factors, safety culture, and usability
• Establishment of a mechanism for both vendors and users to report health IT related deaths, serious injuries, or unsafe conditions
• Establishment of an independent federal entity for investigating patient safety deaths, serious injuries,or potentially unsafe conditions associated with health IT
• Regular monitoring and reporting of health IT safety by HHS, and the FDA should be charged with developing applicable regulations
• HHS should support usability research

Readers familiar with the FDA regulation of medical devices will recognize many of these items as standard fare. These include registration and listing, quality systems, and problem reporting. However since the FDA has not asserted that EHRs are medical devices, and the IOM elected not to make that specific recommendation.

Record-type health IT products remain in a regulatory vacuum–except with respect to acquisition funding subject to the meaningful use requirements. In this regard the report includes a dissenting statement from Richard Cook, MD (director of the Cognitive Technologies Laboratory at the University of Chicago) who asserts that health IT products should not only be declared to be medical devices, but that they should be Class III, the most stringently regulated device classification. In this regard he includes the following quote: “Medical and diagnostic devices have produced a therapeutic revolution, but in doing so they have also become more complex and less easily understood by those who use them. When well designed, well made, and properly used they support and lengthen life. If poorly designed, poorly made, and improperly used they can threaten and impair it.” While this quote could appear in nearly any one of the posts here, it actually dates to 1976 as part of President Gerald Ford’s signing statement for the Medical Device Amendments that ushered in the modern era of medical device regulation. While these amendments are often thought of as the beginning of  FDA medical device regulation, such regulation actually stems from the 1930′s. What did start in 1976 was before-marketing restraints as opposed to the FDA’s prior post market authority. (And no, 1976 is not ancient history. Some of us actually remember it.)

Health IT is caught in the corn maze of promise vs usability and hazards. With quality design and thoughtful implementation the exit may be found before nightfall. Without it someone is going to have to call 911.

William Hyman is Professor Emeritus of the Department of Biomedical Engineering at Texas A&M University. He recently retired and has moved to New York City where he continues his professional activities.

The precursor to the Times story had appeared earlier in a number of places including here on October 5^th. At that time the issue was reported as a loss of data service as opposed to a loss of data, although it was noted that a reset could cause loss of the user’s contacts and calendar. On the 11^th it was reported here that the data may be lost for good, but then on the 13^th it was said here that maybe not all of the lost data was permanently lost. Apparently Microsoft/Danger was being run on a single server.

While there is no direct association of this situation with medical information (unless your doctor’s contact information was among the stored data), it should serve as yet another reminder that the connected world, and its operational software and hardware, is not without its own issues. When new medical applications are being discussed there seems too often to be a suspension of reality with respect to system functionality, data reliability, and data availability. Whether it is “just” an EMR/EHR, or it is more direct functionality (e.g. an alarm or communication system), or even a single device, it must be remembered that software anomalies (a nice word meaning it sometimes doesn’t work) are more common than rare, and that reliance on “the network” to perform as imagined can often be a false reliance.

In case there was any doubt of this, software is a fairly common cause of FDA mediated medical device recalls.  The FDA’s recall datebase has a Simple Search function. Entering “software” without date limits brings up 500 hits, the systems maximum. Limiting the search to 2009 (through 10/21/09) on the Advanced Search produces 62 hits. The most recent of these involves a “software bug” cryptically reported as “The … flag is configured incorrectly. The flag is not generated according to system requirements.” A “software update” is said to be forthcoming.

As I have noted elsewhere, the software industry really needs to be congratulated for its use of the term “upgrade” to mean fixing something that was never right in the first place. The second most recent recall had an equally cryptic explanation: “There is a potential safety issue with … 3.0.x software where study split operations are not correctly replicated to a secondary ‘shadow’ archive”. Of course the software here will also be updated. And one more: “Software issue may result in unintended modifications to treatment.”  Mix-ups between patient identification and data or images are also well known.

So as connectivity and EMR/EHR’s continue to be heavily promoted, let’s always pause long enough to do some risk management thinking and reality checks, and not act as if we really believe that new products and systems will have flawless performance, or that their mal-performance cannot have serious consequences. A little failure modes and effects analysis can go a long way here: What can go wrong? What are the consequences of it going wrong? What are the risks associated with those consequences? And what preventive measures do such risks require in order to achieve an acceptable level of safety? And I would add, acceptable to who?  And don’t forget to back up your data.

The second trend I’d like to discuss is the shift towards patient safety as one of the key market drivers for connectivity. It is probably not news to anyone that patient safety has become one of the key drivers for many healthcare IT initiatives. But what is the relationship between patient safety and MDC? Ever since the often referenced IOM report, To Err is Human: Building A Safer Health System, hospitals and vendors alike have increased their focus on driving towards significant reductions in medical errors. The industry as a whole has made great strides, but still lots of work remains.

With device connectivity, my experience has been that for at least the past 15+ years, the key driver has been making the nurse more efficient by eliminating the manual transcription of device data into the patient’s chart. One of the related benefits is a more come complete and legible patient record. However, one could argue that the more legible patient record could be achieved if the vital signs from medical devices were simply typed into the charting application manually (something that many hospitals are actually doing today). So I believe that the nursing efficiency argument holds as the primary driver – but that is starting to be challenged by the focus on patient safety as it relates to connectivity.

Up to now, bedside patient monitors have been the priority medical device driver for connectivity. Multi-parameter patient monitors produce approximately three quarters of the total number of device parameters that need to be charted on a periodic basis. Other devices that make up the remaining one quarter of the data set includes ventilators, anesthesia machines (of course in the OR environment), standalone pulse oximeters, IV pumps, standalone cardiac output devices, and even beds (weight, angle of inclination, rail positions, etc.)  However with the increased drive for patient safety in recent years, we are starting to see hospitals discuss requirements for smart IV pumps to be interfaced as a priority over other devices.

One of the reasons for this shift is likely due to the high number of visible errors involved with high profile infused drugs such as Heparin.  Simply put, hospitals are focusing more on those devices that are directly related to patient safety and errors and IV pumps are often in the mix. Hospitals have been migrating to smart IV pump technology. One key market indicator is the rapid growth of smart pumps being purchased – now over 60% of US hospitals have made the switch to smart pumps.  For details – refer to this link.

Even though smart pumps are proliferating, challenges remain when it comes to the integration of smart pump data to the EMR and smart pump alarms to alarm management and notification systems. In reality, there are very few instances of IV pump connectivity to EMR or alarm systems. Not only is there the issue related to patient ID and association (for detailed discussion see this link). There are also the issues related to the unique nature of the data produced by an IV pump. But it is a bit ironic that just as patient safety is driving the adoption of smart pumps, the need to ensure safety is one of the factors holding back the end to end integration to the EMR. Vendors have been very cautious on all sides when determining how to integrate pump data. The stakes are high if the integration does not work 100% – patient safety is at risk.

What really needs to be charted into the EMR from an IV pump is the total volume infused (TVI), the infusion rate, and the drug dose. The problem is that EMR vendors have been working on how to accept automated data from pumps – but some EMR’s are not there yet.

One complexity is related to the fact that the EMR cannot just import the data values directly from the pump devices. The EMR needs to perform a calculation of volume infused taking into account what has already been infused over the last charting intervals. Also, don’t forget that most patients are infused by more than pump device at a time, especially in the ICU.

Another important challenge is related to bi-directional communication with an IV pump. Data must be able to flow seamlessly from the IV pump to the EMR for documentation purposes. But to really reduce administration errors and impact patient safety at the bedside, automating the programming of the pump is required. The order for the infused medication or fluid needs to be transmitted to the right pump at the bedside – and this requires a capability to communicate bi-directionally with the pump device. The workflow challenge for the nurse at the bedside is ensuring you have the right patient, the right pump, and that the order matches the patient before it gets to the pump.

I believe that the focus on patient safety will continue to drive vendors towards providing connectivity solutions that solve these types of complex problems.  IV pump connectivity and integration are the next big frontier in MDC. What do you think? Whether you are a care provider or a vendor – agree or disagree. Do you think I missed anything?

Has anybody wrestled with the idea of placing patient-care applications on the laptop COWs (Computers on Wheels) in Hospitals?

There is a new series of USB-connected Ultrasound transducers that can do many ultrasound procedures, including Bladder Scanner functions.  It operates on any laptop, when loaded with the manufacturer’s software.  I can foresee many other patient-care functions vying to share the computers already in the patient vicinity.

Any guidance on this subject?

Here’s my reply:

As others have pointed out, you are right to be concerned about the safety of mixing regulated medical device applications and applications from any other source on the same computer. Moving forward without the proper information does expose your hospital to additional risk. At minimum you may be using the device “off label” if you unwittingly fail to follow the manufacturer’s instructions. (Note that the FDA’s interest in “off label use” centers on patient safety, where manufacturers may promote products for uses they were not designed and tested, or when manufacturers make an application with an easily cleared intended use knowing the market will buy and use the product for a more difficult intended use.)

You will need some information from your medical device vendor with the USB scan head and associated software.

Questions on General Purpose Computers

How specific are their specifications for the computer (hardware configuration, operating system, any additional libraries or applications) that is used to run their medical device?

Regardless of how specific their specifications may be, you must use and maintain your system (the USB scan head heads, application software and general purpose PC) in accordance with the vendor’s directions for use, or you will be using the system “off label.” The actual specifications can be high level, indicating a PC of any make or model as long as it includes a specific processor class and minimum speed, and meets minimum required memory and disk space, and a minimum version for the operating system. Alternatively, the vendor may be obsessively specific, calling out computer manufacturer and model, the specific CPU, the required version of BIOS, and even specific versions of operating system components.

Neither approach, generalized or detailed specifications, is inherently superior. Generalized specifications provide a lot more flexibility in what computers to buy — and important consideration given the product life cycle for a PC is about 18 months. Detailed specifications limit you to buying a particular make and model that will soon be discontinued, forcing your manufacturer to complete verification testing on new models and possibly making “last time buys” of discontinued models to sell to their customers (until the verification testing is successfully completed).

Coexistence Issues Beyond the Computer

The above information is typically readily available. The trickier part in all this is to determine how accommodating their product development approach was regarding coexisting with other applications on the same computer. These are general purpose computers, and one should not be surprised when a customer wants to use it for more than one thing. Some medical device manufacturers anticipate this need, while some don’t. The framework for software specifications and coexistence is similar to the systems specifications above.

Don’t neglect to consider networking issues. Is the medical device in question intended to operate only on a standalone computer? Can the product “tolerate” a computer that’s part of a network? And if the medical device is a system that actively uses a network, there’s a similar (but more complicated) set of considerations regarding coexistence.

Start with the vendor’s service department (or sales if you’ve not yet bought), and ask for a written document detailing any restrictions there may be regarding installing other software applications on the same computer as the medical device.  Also inquire about possible restrictions on running other third party applications at the same time as the medical device. Don’t be surprised if your vendor has a hard time understanding your questions, let alone digging up the answers. Some manufacturers haven’t quite come to grips with the fact that medical devices are becoming information appliances, and not black boxes that they exclusively design and control.

The ability to support third party apps on a PC that’s a medical device is highly dependent on the design approach and verification testing used by the manufacturer. The verification test lab is a frequent bottleneck in R&D departments, so designing products that need to be retested any time Microsoft or Dell make a product change — or a customer wants to run some third party application — is a recipe for disaster.

“It’s the FDA’s Fault”

Don’t be surprised if the FDA comes up as an excuse somewhere along these discussions with device manufacturers — much like it has regarding operating system patches. The FDA does not define how manufacturers must or should specify or design their products. If a manufacturer wants to sell you a discontinued PC because that’s the way they specified it when the product was first developed (and they haven’t gotten around to doing the verification test for a new model), that was the vendor’s decision not the FDA’s. If the vendor chose that route, they can’t just do something else later because they now realize it would be easier — the FDA does insist that vendors follow their own processes. (That’s not to say the vendor can’t make a change like that, they just have to follow their quality system to plan and implement that change.)

In summary, if the medical device manufacturer anticipated customers running third party applications along with theirs, you are free to do so. But you may have to poke and prod and dig to get this answer with some vendors. Those vendors who are obsessively specific and design their products to run on their own dedicated computers may represent a hidden cost if you would like to run them on other computers available at the point of care. This hidden cost can manifest in 2 ways, the incremental cost to buy a dedicated computer, or the added costs to support discontinued PCs and/or running behind on OS patches as part of your enterprise IT infrastructure.

Acquiring Medical Device Data is Key to Clinical Decision Making

Medical device connectivity in the ICU is essential to supporting a complete clinical decision support framework. While electronic medical records in and of themselves offer enormous workflow benefits, the documentation and charting systems are only as good as the data they convey.

Due diligence by care providers can be augmented by automated and validated data collection, achieved through a seamless form of medical device connectivity and interoperability that is supported both inside and outside the enterprise, and follows the patient from the home to the hospital. Yet, as we know, human beings are complex systems of systems.

Decision making in the healthcare enterprise is often made on the basis of multiple parameters and in the context of the patient presentation, setting, and specific conditions relating to the reason for hospitalization and procedures. The data used in clinical decision- making originates from many sources: devices in and around the patient, laboratory and blood tests, films, and ancillary information available both prior to and during the encounter. How often should data be collected? The assessment of clinical needs change depending on the acuity of the patient and conditions present at the point of care.

Updates per care unit drive the quantity of data captured within the bedside documentation, either through flow sheets or paper records. But, the team supporting the patient ultimately must define what is acceptable and required. To support clinical decision making it will also be necessary to include other data from the electronic health record. These include fluid intake and patient output, demographic data, laboratory blood draw assessments, films, etc. Clinical decision-making must be made with data measurements obtained from devices at the bedside and from the ancillary data taken from the electronic medical record.

An Acute Care Scenario

We can learn something of what is required to manage patients effectively by following them through several key departments within the hospital enterprise—a “day in the life” of a patient. In laying out the details of such a scenario, I will draw upon my own experiences at the point of care.

Perhaps there is no better place to consider than the intensive care unit (ICU). The ICU environment cares for the sickest of acutely ill patients. Many patients within ICU environments, and particularly surgical intensive care units (SICU), are technologically dependent on the life-sustaining devices that surround them. Some of these patients are indeed dependent for their very survival on such technologies as infusion pumps, mechanical ventilators, and intra-arterial balloon pumps.

Consider a patient who enters the hospital for a coronary arterial bypass graft, and the workflow and environment surrounding a typical encounter. To this end, I will refer to a former patient, Mr. A. It was determined by Mr. A.’s cardiologist that he had 90% occlusion, or blockage, of three of the coronary arteries supplying his heart muscles with nutrients. As a result, Mr. A was recommended for immediate coronary bypass surgery the following morning.

During the admission process, he is assigned an electronic medical record number along with account and related personal and payer identifying information so as to enable charting and tracking his progress throughout the hospital. As Mr. A. is prepared for surgery, he is moved to a pre-operative waiting area. He receives drugs to reduce the workload on his heart and to prepare him for the anesthesia. He receives sedation and is wheeled to the operating room where his anesthesia and surgical teams prepare him for the procedure. The anesthesiologist manages the patient’s airway, sedation, and monitors vital signs.

In the case of patients receiving coronary bypass grafting in which the heart is stopped, the patient is also placed on a bypass machine that oxygenates the blood and returns it to the body. Vital signs are documented, either automatically or through a paper record, and all drug infusions are recorded by dose, time, rate, and titration. Mechanical ventilators breathe for the patient and replace the exhaled CO2 with oxygen. Upon completion of surgery, the patient is wheeled to surgical intensive care, whereupon mechanical ventilation is continued, vital signs are monitored, and drug infusions are administered.

These devices all create measurements that are used to govern, maintain, and document the status and trajectory of the patient as Mr. A. recovers. Gradually, as the effects of the anesthesia wear off and as heart function becomes more stable and strong, the patient begins to breathe spontaneously. Gradually at first, but increasing over time, measurements documenting the trajectory of spontaneous breathing are captured and used to evaluate patient state and recovery. Laboratory blood gas tests are used to affirm proper physiological, renal, neurological, cardiovascular, and pulmonary function over time. All measurements are recorded within Mr. A.’s medical record.

Physicians write orders guided in part by the patient’s recovering state. These measurements, if recorded automatically from the medical devices, can serve to greatly increase the charting process at the bedside. However, as importantly, they can also serve to guide in clinical decision making by providing the Intensivist, and other attending clinicians, with key information on the state and systemic health of the patient in regard to this immediate procedure.

Data taken from bedside devices can also assist in determining whether the patient is at added risk due to co-morbidities or ailments that can be acquired while in the hospital, such as ventilator- or community-acquired pneumonia or sepsis. The ability to assist the bedside clinician is enhanced greatly through the added benefit of complete, dense, and thoroughly documented information. Charting (or “flow sheeting,” to which it is sometimes referred) involves the documenting of all information relevant to the care of the patient, including vital signs, fluid intake and output, laboratory values, ventilator and respiratory information, and other non-numeric data that provide insight into the care and progress of the patient.

Yet, despite the inordinate amount of data collected at the bedside, these are but a shadow of the patient—an approximation of the state of the individual and this state changes with time. For example, tools and methods that can assist or guide in the weaning of the patient from mechanical ventilation; determine whether the patient is at risk for myocardial infarction or provide insight as to whether the patient is likely to experience other complications, can greatly enhance patient care management and clinical workflow within the intensive care unit, and can result in more homogeneous and stable outcomes for patients. Let’s consider the process of weaning patients from post-operative mechanical ventilation as an example.

Weaning the Patient from Post-Operative Mechanical Ventilation

To assist in visualizing this scenario, refer to the diagram of Figure 1, which illustrates the intra-operative (OR) and post-operative (SICU) processes. Data are collected through a number of sources. As shown, an anesthesia machine is employed to assist in the electronic charting and capture of patient vital signs into the electronic medical or electronic health record. Once surgery is completed, the patient is moved to ICU in which further monitoring and management of the patient continue. Shown are a Swan-Ganz catheter and a mechanical ventilator. These two modalities are used to collect key information required for weaning our patient post-operatively: cardiac output, temperature, cardiovascular function, and respiratory state.

Figure 1: Diagram illustrating high-level intra- and post-operative timeline and key medical devices employed in support of the patient.

The process of weaning a patient from post-operative mechanical ventilation is an important one that consumes a fair amount of time and resources within the SICU environment. Patients are typically weaned according to specific protocols that involve monitoring their spontaneous lung performance and cardiovascular systems to determine whether, during this weaning process, they are receiving sufficient support. While the process is well defined, individual patients can behave differently depending on many factors including physiology, anesthesia dosing, general health of the pulmonary and cardiovascular systems, co-morbidities, etc.

Patients being weaned from mechanical ventilation post-operatively must meet specific physiological criteria prior to being weaned and must be managed closely during the weaning process to ensure that physiological parameters and other data are always maintained within safe and approved thresholds. Examples of such thresholds include chest bleeding less than 100 CCs per hour, warming to normothermia (normal core body temperature), normal blood gas oxygenations in excess of 95%, normal ranges on cardiac output and perfusion ratios, and normal blood gas results.

Data collected both during the post operative weaning process from bedside devices can be compared with data from similar patients so as to provide for an a priori assessment of whether the patient state is evolving normally during the process. Because a patient’s lung function has been compromised due to the strong paralytic drugs administered during surgery, patients tend to arrive dependent on the mechanical ventilator for breathing.

Most (if not all) mechanical ventilators used in the intensive care unit support the capability to communicate data through standard RS-232 ports. The type and quantity of data relate to the settings, mandatory support levels, and patient (or spontaneous) levels. As patients begin to recuperate, their spontaneous support levels evolve from zero to some final value related to full spontaneous support. This is illustrated notionally in Figure 2, which shows patient spontaneous minute volume (that is, the volume of air breathed in a minute’s time) as a function of time after arrival from surgery. The time at which a patient begins to breathe is related to many factors, as stated above. The ability to metabolize the anesthesia is one of these. A patient will begin to breathe slowly and will gain his or her strength over time, as illustrated in this figure. The time at which the patient begins to breathe on his or her own is loosely tied to several factors, including their body mass and core body temperature. Of course, the assumption is that the patient is not being maintained in a sedated state post-operatively. This can be the case and for a variety of reasons. However, we will assume the most typical of cases, in which a patient is being weaned gradually over time.

Figure 2: Notional representation of patient respiratory recovery as depicted by post-operative minute volume evolution over time.

Prior to weaning, a patient should achieve normal body temperature to ensure all bodily functions can operate at their optimal levels. The following graph, Figure 3, illustrates a normal re-warming profile of coronary bypass patients recovering from the effects of anesthesia [1]. The horizontal axis represents time from arrival in SICU from surgery. Thus, from the perspective of our patient, Mr. A., we should begin the weaning process as the patient approaches normal body temperature, around 37C.

Figure 3: Average time to achieve normal body temperature.

As the effects of the anesthesia wear off and the patient’s respiratory performance returns, the evidence of this improvement and strengthening is visible from the data collected through the ventilator. These data, when charted, provide a visible trend that reflects the patient’s pulmonary and cardiovascular performance. These data can be used to help guide the weaning process as well as confirm and feed back to the clinician the patient’s response to stimulus and treatment during the unconscious state.

The time to achieve spontaneous breathing at a rate of 1 liter per minute was determined in a study of bypass patients in SICU by the author, and is represented according to the plot of Figure 4. In this assessment, the author hypothesized that the time to re-awaken, defined as spontaneous breathing in excess of 1 liter per minute for a period of 10 seconds or longer, was related to the amount of analgesia / anesthesia administered during surgery. The typical anesthetics administered to patients include propothol and fentanyl. The author further hypothesized a linkage between the fentanyl dosing and the re-awakening time. The following plot illustrates a best-fit plot to the original data (r² = 0.61).

Figure 4: Time to achieve breathing level of 1 liter per minute post-operatively linked to analgesia and anesthetic dosing intra-operatively.

Thus, armed with information related to breathing (available from the mechanical ventilator), core body temperature (available through Swan-Ganz or similar core catheter), and intake & output information from surgery, the clinician can begin to develop an understanding for the expected relationships these may play in terms of guiding patient post-operative weaning. This information is available from previously charted information, from direct medical device connection, and from the surgical flow sheet.

Ultimately, the data collected through the mechanical ventilator are augmented by this information to assist the care provider in guiding patient weaning, in ordering procedures and changes to support that are consistent with the patient’s ability to respond, and help reduce the risk to the patient. The plot of Figure 5 illustrates the mandatory (set) value of respiratory rate and the spontaneous (patient) value of the same parameter during the post- operative weaning process of a coronary bypass graft (CABG) patient [2]. The spontaneous component of this plot is similar to the plot of Figure 2 in shape. As can be seen, the mandatory value of respiratory rate setting is reduced in steps over time. The spontaneous component shows growth to a final value near extubation time. Measurement and collection of these data were through a standard RS-232 serial adapter into a laptop computer.

Figure 5: Mandatory and spontaneous respiratory rate plots for patient in question.

We can illustrate with several diagrams where these data can be collected and compared for decision making purposes. Figure 6 illustrates the fentanyl dosing in comparison with the model developed from a larger sampling of patients to provide a rough guide as to viability to wean in terms of expected time after arrival from surgery.

Figure 6: Flow diagram illustrating comparison of patient-specific fentanyl dosing with larger model to indicate relative time to excrete effects of intra-operative drugs.

Figure 7: Comparison of patient temperature to illustrate approximate time required to achieve normothermia.

Figure 8: Patient spontaneous respiratory rate in comparison with mandatory settings to provide gauge on viability to wean.

Figure 7 and Figure 8 illustrate the time required to achieve normothermia and the patient respiratory rate performance over time, both collected from bedside monitor and mechanical ventilator, respectively. If we look at the time to reach normothermia and the time required to dissipate the effects of fentanyl in relation to this plot, we have the graph of Figure 9.

Figure 9: Spontaneous and mandatory respiratory rate with indicators as to when normothermia is achieved and drug effects have dissipated.

As we can see from Figure 9, viability to begin trials for respiratory weaning appears to be achieved after approximately 250 minutes. Of course, other data are also used to assist in making this decision and to determine viability, and expert or related systems cannot be used as a substitute for a bedside clinician. Yet, the possibility to assist and guide the clinician in determining whether it is advisable to proceed can indeed serve a positive end in guiding overall therapy.

Summary

As the patient re-awakens and approaches viability for extubation, it becomes even more important to acquire and analyze measurements from medical devices as these are used to determine whether the patient can be discontinued from mechanical ventilation. The re-awakening time model is a simple but useful tool to guide clinical decision making in the acute setting for a very specific class of patient. Thus, it facilitates the patient care management process in enabling the clinical staff to predict with some reliability when patients require attention during the normal course of care.

Medical device interoperability and integration with external systems becomes essential to clinical decision making ability. There are a number of commercial technologies that support basic interoperability and communication, and I have worked with a number of them. The end in itself is never the ability to merely communicate with a medical device, but, rather, to use the data as a means to assist in making clinical decisions.

Efforts to date in the electronic health record and health information technology areas have focused on documentation, clinical workflow, order entry, notes, and charting. These are all necessary enablers to assist the care provider as a “colleague.” However, clinical decisions are made on the basis of all data presented to the clinician, and involve both real-time and ad-hoc data presented in the form of reports, waveforms, trends, and even hunches based on prior experience. This is the key– all data, communicated intelligently, filtered and analyzed appropriately, presented clearly– so as to assist in diagnoses, interventions, therapies, and long-term trending of patient state and care.

[1] Source: J. Zaleski, based on study conducted by author in surgical intensive care unit of major teaching hospital. [2] Source: J. Zaleski

Software designed to support the application of clinical protocols has been in the works from various vendors. Patient monitoring examples include Philips Protocol Watch, soft-launched back in February 2007, and . These applications automate what are otherwise onerous manual calculations with data acquired from medical devices and integrated with data from other information systems. This is workflow automation of the most important kind, diagnosis and therapy delivery. These applications are typically regulated as Class II medical devices.

Last week I spoke with Philip Settimi, MD, vice president of global strategic marketing for Hospira. According to Settimi, “EndoTool replaces spreadsheets of physician preferences and worksheets full of manual calculations for managing patient glucose levels.” Such manual methods are obviously inefficient, but also susceptible to human error. This approach provides an effective tool to impose a controlled and centralized tool for managing tight glycemic control (TGC). Endo Tool comes with a specific protocol based on sophisticated algorithms to support glucose management. The key: taking all that complexity (the calcs) at the point of care and automating those 33 different non-linear equations.

In a typical use model, the end user selects the patient to establish patient context, enters one or two blood glucose data points, the software recommends dosing and when to test glucose again. The system, after a couple data points, creates a mathematical model of the patient’s physiology (physiological curve) and allows for the more effective and more rapid zeroing of the patient into the ideal zone. Thus the system constantly adjusting up and down the physiological curve.

It is easy to automate part of a workflow process with some computer software. To fully automate a workflow beyond calculations – to include patient demographics, orders, charting and reporting – that requires integration with bedside medical devices (sometimes more than one) and other information systems. Surprisingly, EndoTool already has interfaces with ADT (admission, discharge and transfer) for patient demographics. Currently the user has to manually enter glucometer test results.

System architecture is always a point of interest in products like this. EndoTool works on any standalone or networked PC in hospital and uses existing enterprise networks. In network configurations, clients communicate with a server. Unlike a product that automates a paper process, this system scales up to support a large patient population, and interfaces.The server runs a centralized database. Client applications can be installed remotely for lower operating costs. Hospira provides on site installation and training.

Moving the software to the pump is also a possibility. Settemi noted that he sees value in integrating EndoTool with MedNet and possibly the pumps themselves. “The notion of having decision support technology like this, embedded in the pump, is a potential productivity and patient safety enhancement,” said Settimi. One big caveat is the resulting user experience. Hospira’s new Symbiq pump’s large touch screen is well suited for an application like this. He expects to see a hybrid model like patient monitoring, where the user interface is on the device at bedside with some or all of the software running on a server somewhere on the network.

Infusion pumps are used to deliver many high risk meds; many of these are titrated and could benefit from both automated workflow for managing the titration, and medical device interoperability between the pump and protocol software.  Settimi noted that Hospira sees an opportunity to offer a more expanded menu of protocols in the future. The system manages a broad range of patients with their current protocol: peds, adult diabetic, non diabetic, DKA, etc. There’s an opportunity from a technology perspective, yet from a user perspective there’s a big benefit in a common approach. Hospira believes that Endo Tool represents a technology platform, beyond TGC, to include narcotics, coagulation therapy, and a broad array of infusion therapy administration.

I mentioned Philips’ Protocol Watch earlier as another example of automating protocols used in patient care. Another example is Visensia from OBS Medical. Visensia applies a proprietary algorithm for analyzing the physiological parameters from a patient monitor to identify patients with a deteriorating clinical condition. Unlike TGC protocols that are peer reviewed and published, the algorithm in Visensia is a trade secret – sort of like a black box.

Vendors and entrepreneurs are working on lots of different systems to support protocols of various types. Many of these vendors are approaching the problem from a specific diagnosis or other clinical domain. The protocol automation market will probably evolve like many others, where various solutions come to market targeting specific clinical applications. Over time, solutions will broaden in scope in an effort to apply their architecture to a broader array of tasks. Eventually there will emerge generalized protocol support systems that are used throughout a hospital.

Some protocol solutions will come from vendors, looking to extend their proprietary end-to-end solutions. Many new protocol systems will also come from software companies. Who knows, maybe even some existing health care IT vendors will bite the FDA bullet and enter the protocol automation market with their own regulated “medical devices.” In any event, this will be an interesting market segment to watch, and one with significant clinical value and impact on patient safety.

Besides patient safety, patient context also greatly impacts medical device workflow. (Medical device connectivity is workflow automation through the integration of medical devices and information systems.) How a vendor implements patient context can have a big impact on usability and customer acceptance.

Patient context requirements can vary, based on the type of medical device in question. What is not variable is the requirement to reliably establish and maintain context. Mobile applications (like smart pumps or patient monitoring) where the device may go in and out of network coverage while constantly in use present special challenges. This compares to a fixed or portable medical device, like a dialysis machine or diagnostic ultrasound, with an episodic use case during which neither the device or patient is moved. Another variable is whether the application is life-critical. Continuous patient monitoring and many alarms (e.g., smart pumps and ventilators) are life-critical applications with a higher threshold of requirements. This contrasts with connectivity for documentation like with point of care testing or spot vital signs capture. In all cases though, patient context must be safe and reliable. The above issues just help define how many hoops you have to jump through to be safe and reliable.

In the past few years, medical device vendors have seemingly chosen barcoding as the consensus method for implementing patient context. This approach has two advantages for vendors, it has been implemented by other vendors and represents a no-brainer default solution, and is relatively quick and easy to design (especially compared to alternatives). The problem is that users don’t like most barcoding solutions.

Barcoding solutions can have the following problems:

1. The resulting workflow is really bad and customers don’t want to use it,
2. Customers don’t want to buy more than one barcode system, and
3. Barcode technology is finicky – you have to have the right barcode, printers, ink and labels for a certain application if you want a reasonably reliable read rate.

To be fair, the workflow around barcoding is not inherently bad. Besides challenges reading barcodes, there is the question of how barcodes are generated, an issue that gets too little attention. System-generated barcodes from a database are a great way to generate barcodes for automated data capture. Barcodes generated from data keyed in by a user is subject to typos, transpositions, and “right data, wrong entry” errors than render the resulting barcode little better than any other manually entered data. Of course, accurately reading bad data doesn’t improve patient safety.

A relatively recent connectivity and patient context application is smart pumps. These systems can illustrate some of the problems, both inherent to barcodes and design short comings, around patient context and workflow.

The word “smart” in the term smart pump is relative; as the market matures, expectations for intelligence increase. Infusion pumps with site specific formularies and software that returns an alert when the user possibly mis-configures the pump is really barely sentient. A pump that also captures patient and user context resulting in a much more meaningful CQI (continuous quality improvement) database is more intelligent. But the summa cum laude of smart pumps is one that integrates with an EMAR (electronic meds administration record) and pharmacy departmental system to provide closed-loop meds administration for the highest risk drug category in the hospital – those that are infused.

This state of connectivity bliss is a ways off for the vast majority of hospitals (who just aren’t ready yet) and many pump vendors (who are still struggling with lower forms of smartness), but smart pump installations continue to grow. According to Pharmacy Purchasing & Products, 43% of facilities in the U.S. have adopted smart pumps. Smart pumps linked to bar coded meds administration systems represent a mere 11.5% of installed IV pumps. Of the smart pumps installed, only 26.9% include wireless connectivity.

Not surprisingly, user satisfaction with systems that are not wireless (I’m assuming no network connectivity at all) is low – only 14.3% rate data collection as excellent or good, 26.2% rate it as satisfactory, and a dismal 59.5% of users rate data collection as less than satisfactory or poor. In contrast wireless data collection is rated excellent to good by 75% of users, and satisfactory was chosen by another 18.8% leaving 6.2% of users dissatisfied. But wireless connectivity is only half the story.

A key challenge with workflow and barcoding is that there are many factors that impact usability. Assuming you get barcodes that are reliably scanned the first time, you need a device that’s easy to use and can be positioned properly. If a barcode reader is mounted to the infusion pump or a cart, the entire assembly must be easily moved into position for scanning.Refer to the latest Spyglass Consulting report on Point of Care Computing for Nursing for examples of barcoding gone wrong – tape on the floor showing where to stand, wrist labels cut off patients and taped to folders at the nursing unit, duplicate drug barcodes printed and taped to folders at the nursing unit, and others. Besides poor wireless network converage, the accessibility of barcodes on patients and drugs is a very common problem. Obviously, poor system configuration and implementation can torpedo even an excellent barcode workflow.

In the fall of 2006, Cardinal Health acquired CareFusion to use as their own meds administration and barcoding system. I recall Cardinal’s CareFusion demo at the HIMSS in New Orleans where the poor demo person had to scan each barcode repeatedly while a group of us watched her struggle. This is not an example of a poor implementation of barcode technology, but an example of how finicky barcodes can be and how it can impact usability. Nurses aren’t marketing people, they won’t put up with it.

The bottom line in all this is that the percentage of smart pumps installed in the U.S. that establish patient context for CQI databases or EMR documentation is surprisingly small. One reason is the prevalence of wireless LANs that don’t cover all patient care areas or cover them unreliably. I suspect though, that the real reason is that pump vendors have yet to come up with a quick, convenient and reliable way for users to establish patient context.

Vendors, when designing a system with patient context think about alternatives to barcoding. Regardless of your technical solution, carefully model and evaluate the resulting workflows so users have to go through the same or few steps when using the device. I was looking at the 2008 HIMSS Leadership Survey today and noted under technology adoption (next 2 years) that barcode technology fell from 74% last year, to 35% for 2008. That percentage did not fall because almost everyone’s doing point of care barcoding. While most hospitals fiddle with barcodes somewhere, those using them at the point of care are still in the minority. Don’t assume that buyers are willing to implement your barcoding stuff – especially if it’s not open standards and compatible with all the other point of care barcoding they want to do.

Providers, when you’re looking at medical device connectivity look closely at the workflow – all of it, not just for patient context. Make sure the automated workflow is, you know, better than your existing manual workflow. Be sure to look for similarities and differences between product demos, how site visits may have implemented the system, and how you plan to implement it.

[...] Gregoire said she expects full public access to hospitals’ track
records to be done without extra cost to the state treasury. She said
she will introduce legislation giving consumers information about
“adverse events,” such as infections or patient deaths, at each
hospital.”With full disclosure, the health care system can
learn from its mistakes and prevent new ones,” Gregoire said in a
policy paper released by her office.

Such reporting could motivate hospitals to undertake difficult cultural changes and invest in products that will improve patient safety. The best run hospitals, with the appropriate technologies, could better compete with hospitals in their markets if prospective patients knew hospitals’ adverse event track records.

I’ve mentioned before (here, here and here for 3 recent examples) how transparency pressures will shine a bright light on adverse events through increased reporting. This won’t be an easy transition, but the industry will be better for it. I mean we’re here to save lives, right?

With the U.S. market in the midst of a hospital building boom, the environment at the point of care is changing. Variable acuity units (aka, universal beds or rooms), distributed nursing units, and other big changes are being adopted now. These changes will impact market requirements for both medical devices and health care IT.

You have been warned.