The HIMSS conference is so big, with so many different kinds of attendees and exhibitors that it’s almost impossible to have one big theme for any given year. Yet the question of theme for any given HIMSS is something we all talk about. The themes one perceives are at least partially defined by our own interests and area of focus. Consequently, the #HIMSS14 themes for me were:
Two of the market segments that I track with big shifts in value proposition were medical device data systems (MDDS) and messaging middleware. We’ll talk about specific shifts in a moment, but I think it worthwhile to consider why this change in value propositions has occurred. One obvious factor among MDDS vendors is acquisitions. Capsule Tech (registration required), Accent on Integration and iSirona have all been acquired. Acquisitions are major events when everything about a company is reevaluated in an effort to wring greater value from the acquired company. The other factor I think is the growing adoption of MDDS for clinical documentation into EMRs may have caused sales growth to temper a bit, causing vendors to look beyond clinical documentation and explore for ways to add value and differentiate. Let’s look at some examples.
Capsule Tech has released a new version of their Neuron device and transformed it into a vital signs monitor (pictured right). I’ve explored the virtualization of medical devices before in past conference presentations. This is where the core functionality of the traditional medical device is reduced to its essence and combined with an off the shelf computing platform. Imagine an ultrasound transducer, spirometer or EKG leads with a USB connector. Such products are delivered with software that runs on a laptop or desk top computer, tablet or smartphone. Simply install the software and plug in the sensors via the USB connector, and you have a fully functional medical device. (A more technical description of this may be found in this paper, from the Intel Technical Journal, published in 2006.)
Capsule has taken the general purpose computing functions that make up most of a conventional embedded system device and implemented them in the Neuron. Next they’ve taken sensors with miniaturized electronics that acquire and process the sensor data and convert it to a standard USB interface. Plug a temperature probe, SpO2 sensor, non invasive blood pressure module and similar sensors into the Neuron, and you have the new SmartLinx vital signs monitor, part of Capsule’s medical device information system. This new approach allows sensor vendors and Capsule both to add value at the expense of conventional vital signs monitor manufacturers.
In addition to SmartLinx, Capsule showed a new terminal server called Axon with power over Ethernet and Wi-Fi connectivity, and what they called “clinical analytics.” Capsule’s clinical analytics, really a clinical decision support system, is presently targeted at identifying patients with a deteriorating clinical condition and diagnosing patients with sepsis.
Accent on Integration (AoI) was acquired by Iatric Systems. AoI has extended their value proposition beyond MDDS and clinical documentation to include infusion pump interoperability whereby their software will be used to program infusion pumps based on orders from CPOE and pharmacy systems. This is one of the first pump interoperability solutions to come from a third party (i.e., not from a pump or EMR vendor). Iatrics is using Meditech’s proclivity to avoid systems integration to enter the pump interoperability market.
Nant Health is a health care IT and medical device company created by serial entrepreneur Dr. Patrick Soon-Shiong. The company’s atypical product portfolio ranges from mHealth to revenue cycle management. Since iSirona was acquired by Nandt Health, the company has received FDA clearance and brought to market an alarm notification solution for acute care. This pulls iSirona squarely into the messaging middleware space.
The company also showed HBox, a new terminal server and connectivity hub with a similar design and capabilities of Qualcomm’s 2net. The HBox includes wireless connectivity via Wi-Fi and a proprietary radio in the Sensium wireless sensor package from Toumaz (what they call a “sticking plaster” in the UK). It appears that Nant Health will be selling the Sensium into the acute care market as a means to identify patients with a deteriorating clinical condition. The HBox will be used as a gateway communicating with the Sensium device and connecting it to the enterprise network, and later HBox will be used to provide connectivity in patient homes.
Besides the changes at the MDDS acquisitions above, similar moves up the value chain away from conventional MDDS solutions are wide spread.
In the recent past the MDDS market was dominated by the acquisition of medical device data to populate flow sheets in EMRs – an important but basic enabling technology for higher value activities like alarm notification, clinical decision support systems and other tasks more directly related to patient care and outcomes. After just a few years – lightening speed for the health care market – the MDDS market is undergoing major changes.
Geoffrey Moore’s, Crossing the Chasm, is my favorite market adoption model because it fits health care technology markets so well. At this year’s HIMSS, I was struck by a parallel. Much like the bowling alley strategies described by Moore, what is called the messaging middleware market is driven by a variety of spot solutions. With Moore’s model, once sufficient bowling alley strategies have succeeded, the market enters the tornado where a brief period of rapid adoption occurs where buyers shift from the early adopters to the much larger early majority of the market. These spot markets for messaging middleware all revolve around facilitating communications and automating workflow. Examples of spot solutions include:
These spot solutions match a series of pain points for health care delivery organizations. Various messaging middleware vendors target one or more of these pain points with spot solutions. Since HIMSS14, I’m up to 25 companies that I track in messaging middleware. The product architecture and capabilities of these different company’s solutions are very similar, if not virtually identical. Yet few of these companies see more than a hand full of competitors in their sales efforts. This is because different companies are targeting different sets of pain points with spot solutions. These spot solutions can exist in customer sites as separate systems or they may be integrated to provide different capabilities to the same sets of users.
At some point the market is going to start to swing from spot solutions to enterprise solutions. Much like the transition experienced by Emergin years ago, buyers are going to wake up and recognize they’re buying multiple spot solutions that are technically very similar for their various pain points. The question will arise, “Why can’t we meet these various needs with one solution rather than having to buy one for each problem?” At this point, messaging middleware companies will start to recast themselves as enterprise solutions able to address a wider variety of pain points.
As manufacturers continue to draw outside the lines of conventional market segments, the challenges increase for buyers to select solutions that will serve them for more than the short term. Hospital buyers must complete rigorous requirements assessments to enable a meaningful assessment of competing solutions. And manufacturers will have to stay close to the pain points of buyers if they want to drive sales.
The best I could tell population health is something enabled by health information exchanges, or something. It seems vaguely like what the NSA does with our phone calls, smart phone apps, locations, email, webcams, Twitter, Skype, Facebook, Google, etc. Is there real value in all this? The NSA seems to think so. But I wonder if a panopticon of electronic health care data will be any more specific, sensitive or cost effective than conventional double blind clinical trials. Robust clinical trials are not cheap, but then extending the surveillance state to health care won’t be cheap either.
This blog post is part of the #HIMSS14 Blog Carnival #4, Looking Back at HIMSS14. Be sure to check out the carnival to see what other HIMSS14 Social Media Ambassadors though about this year’s event.
Finally, I’d like to thank the folks at HIMSS for letting me attend this year’s event as a Social Media Ambassador. I hope people got something from my tweets during the conference, and this wrap-up blog post.
I wrote in the beginning of 2012 that perhaps that year was the year for mHealth to ‘breakout. ‘ I cited several proclamations and organizational activities to support that claim. mHealth and the use of remote monitoring as an integrated healthcare offering is still not as prevalent as one would think it would be two years later. Even in the Telemedicine & E-Health LinkedIn Group, one sees angst at the low adoption rate of the use of telehealth solutions. Inevitably, when I speak with my colleagues and other people involved in healthcare, economic and clinical effectiveness questions prevail. Two specific conversations I had with clinicians stand out. In one, the cardiologist had not seen enough evidence that the quality of care and cost would justify a large addition or change to the existing healthcare offerings. In another, the clinician reminded me that with chronic diseases, one is attempting to get patients to change their behavior, which is very difficult, regardless of any technology involved.
With the above in mind, I’d like to offer the following results from the Renewing Health (RH) project in Europe, a randomized control trial which endeavored to compare the use of remote monitoring technologies and workflows with traditional workflows in the management of chronic disease in both economic and clinical terms. While the final results of the whole study are due out this summer, Veneto, Italy, has presented their findings for congestive heart failure (CHF) and they are fairly impressive.
Veneto, Italy, had to redesign their clinical workflow to accommodate a telehealth center which functioned as a data aggregation, filtering and analysis point for the data flowing from a patient home. This telehealth center then interacted with the patient, emergency services and clinical personnel based on a set of ‘clinical rules’ regarding the data received. This helped to alleviate data overflow and false alarms sent to the clinician and only ‘actionable’ information was forwarded when clinical intervention was needed. This also helped to gain the trust of all parties in the study; patients felt they were being monitored appropriately; clinicians were notified when it was truly necessary for them to intervene, and yet they could retrospectively review the data if required; and, emergency services were called appropriately and also were able to retrospectively review data if necessary.
After adopting this architecture and workflow, Veneto, Italy had the following results from their pilot study. Economically, their traditional healthcare model cost 4.72 Euro per day, whereas the remote monitoring healthcare model cost 3.47 Euro per day for a cost reduction of 16.5%. The clinical outcomes really improved with a 35% reduction in CHF hospital admissions, a 42% reduction in the number of specialist visits for CHF and a 32% reduction in specialist procedures for CHF. These are excellent results and Veneto will be using this model as their standard of care for future management of CHF patients. One of the main keys to attaining these results was the re-engineering of their workflow architecture to include the telehealth center in the middle of the data flow. For a more detailed view of these results, you may go here.
Additionally, the RH results will be forthcoming regarding Diabetes and Chronic Obstructive Pulmonary Disease (COPD). A follow-on project which is studying remote monitoring for chronic diseases called United4Health is requiring a standard system architecture of the pilot sites as well as ensuring remote monitoring workflows are part of the standard of care for the pilot site. It is not a randomized control trial, so the power of the results as compared to RH will probably not be as high, however, the insistence that the remote monitoring workflow be a part of the offered services and not a ‘one-off’ will be of value for the study of the ‘normalization’ of remote monitoring technologies in the standard of care for chronic diseases.
To contrast, the results above from RH are in complete contradiction to the general results from the Whole System Demonstrator (WSD) Project which finished up in early 2013. The conclusion of that study stated that “Telehealth does not seem to be a cost effective addition to standard support and treatment.” To be fair the WSD results were for all three chronic diseases of CHF, Diabetes and COPD. It remains to be seen if the RH combined results will be similar. Nevertheless, for CHF, it seems as though remote monitoring can be a better approach both clinically and economically for disease management as long as the system architecture and clinical workflows are designed to facilitate the proper interventions.
As an aside, from a clinical engineering viewpoint, it is interesting to note that Veneto outsourced both the telehealth center and home monitoring functions. If you drew a vertical line at the output of the telehealth center, that would be where the Veneto healthcare organizations interfaced with the rest of the remote monitoring architecture. With other pilot sites, they only outsourced the home monitoring function, so the healthcare organization provided the telehealth center functions of aggregating, filtering and analyzing the remote monitoring data. This interface point and function decision is important in the context of what parts of the telecommunication and function infrastructure does your healthcare enterprise wish to control and is a prime example of what was discussed in the previous blog post on mHealth.
Disclaimer, I am involved in the Renewing Health (RH) and United4Health projects as a technical manager of the industry advisory board. In that role, I worked with the pilot sites to document their system architectures and identify any issues with which industry could assist them. You can find details in the system architectures and technical issues at both the beginning and end of the RH study here. United4Health is in its beginning stages and the public documents have not yet been released. Nevertheless, the website listed above will contain those documents as they are released over the length of the study.
Introduced in the House back in October was the wittily named Sensible Oversight for Technology which Advances Regulatory Efficiency Act of 2013 which has the acronym SOFTWARE. Not to be outdone on the creation of legislative acronyms, now comes the Senate version with a bill entitled Preventing Regulatory Overreach To Enhance Care Technology, which of course gives us PROTECT. Both of these bills seek to define and sub-define medically related software, and then to take part of what they have defined away from the FDA, and do something else with it that has not yet been clearly identified.
The premise of these bills is that the FDA inhibits entrepreneurs by peskily requiring, at least in some cases, that the developer meet regulations that are supposed to provide some measure of safety and efficacy before these products are used for or by the public. These issues arise in part because the definition of a medical device does not explicitly include or exclude software. This has allowed the occasional debate about whether and what kind of software is or is not a medical device. The FDA’s position is to simply look at the function of the software and the definition, and then to say that if what the software does meets the definition then it is a medical device. Debating this with the FDA is typically not a fruitful endeavor. Some other countries have explicitly included software, presumably to try to end the discussion. For example the UK explicitly includes “software” in its list of the multiple categories of things that may be a medical device.
We have of course seen this theme played out before in the form of the FDA’s regulation of Medical Apps which is now manifested in the Medical Mobile Apps Guidance for Industry and Staff, and the associated mobile apps web presence. The FDA has sought to define what kinds of apps are or are not medical devices, and among the latter which the FDA would focus on using its regulatory discretion. It is worthwhile remembering here that Guidance Documents are not regulations but instead reflect the FDA’s “current thinking”, and that the FDA can adjust its thinking on these matters relatively easily. On the other hand, codifying such distinctions in legislation is a far more rigid and potentially slower enterprise, and if bills such as SOFTWARE and PROTECT are ever passed it would be relatively hard in today’s environment to modify or undo what they do if that proved necessary or desirable.
Both SOFTWARE and PROTECT offer definitions of ” clinical software” and “health software” that seek to distinguish them from other types, notably software that directly drives what is generally understood to be a medical device. The SOFTWARE bill also defined “medical software” as software that (1)(A) is intended to be marketed to directly change the structure or any function of the body of man or other animals; or (B) is intended to be marketed for use by consumers and makes recommendations for clinical action that (i) includes the use of a drug, device, or procedure to cure or treat a disease or other condition without requiring the involvement of a health care provider; and (ii) if followed, would change the structure or any function of the body of man or other animals; (2) is not software whose primary purpose is integral to the functioning of a drug or device; and (3) is not a component of a device. Having provided this definition the act removes such medical software from the definition of a device, but then assigns such software to CDRH to regulate it in the same manner as a device. Exactly what this accomplishes eludes me.
Focusing now on the more recent PROTECT bill, clinical software is defined as “decision support software or other software (including any associated hardware and process dependencies) intended for human or animal use that ‘‘(A) captures, analyzes, changes, or presents patient or population clinical data or information and may recommend courses of clinical action, but does not directly change the structure or any function of the body of man or other animals; and ‘‘(B) is intended to be marketed for use only by a health care provider in a health care setting”. One key factor here seems to be that it does not directly effect the body, presumably meaning that the effect is mediated through the human healthcare provider. This falls into the general category of software whose errors are not of direct consequence because the clinician is supposed to catch any such errors before they reach the patient. In standard risk management parlance this allows severity and frequency of the hazard to be offset by detectability, i.e., if the hazard manifests itself the clinician will prevent the hazard from causing harm. Of course the theoretical ability of the clinician to second guess the explicit or implied advice provided by the software is not the same as this actually occurring.
Heath software is defined as “software (including any associated hardware and process dependencies) that is not clinical software and ‘‘(A) that captures, analyzes, changes, or presents patient or population clinical data or information; ‘‘(B) that supports administrative or operational aspects of health care and is not used in the direct delivery of patient care; or ‘‘(C) whose primary purpose is to act as a platform for a secondary software, to run or act as a mechanism for connectivity, or to store data.” I find this definition more cryptic than the one above. A key exclusion here appears to be not used in the direct delivery of patient care, although this begs the question of how remote from patient care it has to be in order to qualify.
Both clinical and health software are further constrained by the limitation that they do “not include software ‘‘(A) that is intended to interpret patient-specific device data and directly diagnose a patient or user without the intervention of a health care provider; ‘‘(B) that conducts analysis of radiological or imaging data in order to provide patient-specific diagnostic and treatment advice to a health care provider; ‘‘(C) whose primary purpose is integral to the function of a drug or device; or ‘‘(D) that is a component of a device.’’. Clause A would appear to exclude patient used apps that provide diagnostic information based on information that the patient provides either manually or otherwise. The imaging limitation is interesting because it seems to distinguish imaging clinical decision support from other kinds of such support, implying that there is greater risk in the former than the latter. I do not know if there is any evidence for this.
Given all this, the PROTECT bill then removes clinical and health software from the purview of the FDA. One thing to be analyzed here is whether the new definitions draw clear and unequivocal lines within the medical software space. The answer is probably no. Secondly, even if it did, does deregulating what is defined here as to be deregulated serve the public health with respect to a reasonable level of assurance of well designed and reliable software. Assuming that FDA regulation has merit for medical devices in general, these exclusions are not likely to be fully rationale, or to improve upon the current regulatory flexibility that the FDA currently has and exercises.
Whether anything more is heard from these bills remains to be seen, especially since our current congress has not demonstrated its ability to consider and pass much legislation.
Pictured with this post is U.S. Representative Marsha Blackburn, sponsor of the SOFTWARE Act.
It’s useful to segment and analyze markets for developing company and product strategy or analyzing competitor’s actions. Such an exercise helps illuminate why companies and markets do what they do – and what they might do in the future. In getting ready for this year’s HIMSS in Orlando, I’ve been thinking about the point of care (PoC) market. At the first Medical Device Connectivity conference in 2009, I defined the PoC market as the workflow and data associated with direct patient care in nursing units, the ED, surgery and related areas. This contrasts with EMRs managing orders, diagnostics, capturing charges and generally documenting things for the medical/legal record. (You can download a PDF of the presentation here.)
Many devices and software applications used at the PoC are FDA regulated medical devices because they are directly used in the diagnosis or therapy of patients. Because the PoC is where direct patient care is delivered, most PoC solutions meet the FDA’s definition of a medical device. Imagine a layer cake:
The PoC market is bound on one side by medical device manufacturers, most of whom still think of themselves as box makers, and on the other side by EMR vendors who can get plenty clinical, but are repulsed by the prospect of being any more regulated by FDA than they already are (e.g., blood bank, PACS, LIS).
These days I would add clinical decision support systems for things like tight glycemic control or diagnosing sepsis. One could also argue that meds administration is also a part of the PoC market. This is far from a perfect model, and there are other messy details. For example, some part of a CPOE/infusion pump interoperable solution would fit as PoC software and (I’m expecting) will be FDA regulated.
These segments can be further divided into enabling technologies and workflow solutions. Enabling technologies are characterized by their specialized functions – RTLS for tracking locations, unified communications for voice or text communications, MDDS to acquire and manage medical device data for use by other systems, and nurse call for the call and response between patients and staff.
Enabling technology solutions tend to fall into two groups. The first group is made up of horizontal market vendors that sell enabling technology into a variety of markets – think RTLS and unified communications. These horizontal market vendors have no problem being commodity suppliers, competing on a narrow set of specifications and price. The next group is more focused on health care, e.g., MDDS and nurse call. While they may server other vertical markets (e.g., nurse call including corrections and education vertical markets) a critical mass of health care specialization limits horizontal market opportunities. In an effort to avoid the commodity status embraced by horizontal market enabling technologies, MDDS and nurse call are working to move up the value chain by extending their solutions to include workflow automation.
The workflow solution market segments facilitate the initiation and successful completion of certain tasks. Patient flow solutions aim to improve resource utilization in the ED, surgery or house wide. Emphasis may be placed on providing visibility, bed or room turn over, or more sophisticated resource planning or interfacility patient transfers. Data aggregation takes data from a variety of sources (EMR, diagnostic systems, medical devices, etc.), organizes and presents the data that often changes over time. Currently most of these systems are procedure based, like LiveData or Carrot Medical. Messaging middleware systems can leverage data on location, physiological data (diagnostic, therapy and monitoring), and care delivery data (nursing vigilance, orders to be fulfilled, coordination of care, etc.) to automate a wide variety of workflows. Some of the value propositions for messaging middleware include: alarm notification, critical test results reporting, clinical decision support to guide diagnosis or therapy, patient transport, patient flow… really, just about any workflow at the PoC can be addressed by messaging middleware.
Another interesting characteristic of the PoC market is the potential for a common architecture made up of the following components:
Not every product in the PoC market uses this architecture. Enabling technologies that don’t automate workflow may look completely different. Also, older workflow automation solutions may have purpose built workflow automation software.
A final shared trait among PoC products is their focus on things found at the point of care: patients, medical devices, caregivers, techs and clinicians. Because of this and the preceding characteristics, at some point in the future the market segments that make up the PoC market will start to collapse into one market and a new category of enterprise software will begin to emerge.
The PoC market is a crowded one. I’m presently tracking almost 100 PoC companies:
Challenges with alarm notification and fatigue have plagued the health care industry for decades. Long before alarm notification systems like Emergin (now Philips IntelliSpace Event Management) and GlobeStar Systems (ConnexAll) appeared, some hospitals addressed alarm issues with the original alarm notification system, monitoring techs. Monitoring techs remain an accepted and effective tool in the constant battle to reduce alarm fatigue and avoid failure-to-rescue events.
With the growing adoption of electronic alarm notification systems, is there still a role for monitoring techs? Are electronic alarm notification systems superior to flesh and bone monitoring techs? This blog post will explore monitoring techs as a solution and consider whether they might be a compliment to an alarm notification system, or whether an alarm notification system should take the place of monitor techs.
The role of monitoring techs is to observe waveforms and numeric data from monitored patients. Monitoring techs are also often aware of the patient’s clinical context, such as medications, that can influence resulting waveforms or readings. The key goals are two fold: to screen out nuisance alarms so that caregivers only have to respond to “real” alarms, and to ensure that alarms receive a timely and adequate response from caregivers.
Good alarms are those that are clinically significant and elicit an intervention from caregivers. These alarms are often referred to as “actionable” alarms. Nuisance alarms are “unactionable” alarms because the device and/or the patient’s condition does not warrant an intervention by the caregiver. Unactionable alarms result from poorly set default alarm limits, false positive alarms (e.g., arrhythmia or other types of alarms generated from motion artifact), and transient alarms where parameters exceed alarm thresholds for brief periods and then fall back to normal ranges.
In addition to providing vigilance for monitored patients, monitoring techs often are responsible for changing batteries on telemetry monitors, and can even be responsible for applying and removing patient monitors, and managing patient attached sensors (they are certainly the first ones to see artifacts attributable to poorly applied or “bad” sensors).
Depending on the technology used to notify caregivers of alarms, monitoring techs may have to keep track of the nurse to patient assignments on each shift they are supporting. Even when notification via multiple “bat phones” or a call to the nursing station is used, it is helpful for monitoring techs to know which caregiver is responsible for the alarming patient. This knowledge can help ensure timely alarm responses.
The components of a monitoring tech solution starts with a workspace for the monitoring techs and their central station displays. These central stations display the key waveforms and numerics for each monitored patient. A communications system is also required so monitoring techs can notify the caregiver for a timely alarm response. Communications systems can range from a series “bat phones” located throughout the unit and dedicated to calls from monitoring techs, to Vocera badges, wireless voice over IP handsets or smartphones using text or voice communications.
Monitoring techs can either be located in the unit with monitored patients, or centrally located where they monitor patients remotely. Sometimes called “war rooms,” these central monitoring departments can observe patients throughout a single hospital and scale up to provide surveillance for monitored patients in multiple hospitals throughout a metropolitan area.
Properly conceived and managed monitoring tech initiatives can be very good at reducing or eliminating alarm fatigue by screening out alarms that are not actionable. Such initiatives can also ensure timely and adequate response to alarms, minimizing or eliminating failure-to-rescue events with monitored patients. While this list of advantages is short, they are among the most important in the overall mission of a hospital. Secondary benefits from the foregoing advantages include increased staff and patient satisfaction due to reduced alarm fatigue and a more quiet care environment.
There really aren’t any inherent disadvantages to monitoring techs (except perhaps cost), but this approach is not without its challenges.
The use of monitoring techs can mask shortcomings in the clinical practice of alarms. This clinical practice includes:
Nuisance alarms can never be completely eliminated, even with top notch clinical practice of alarms. The alarm items above have a substantial impact on the ratio of nuisance to actionable alarms. Poor alarm clinical practice can be masked by good monitoring techs who will screen out all those nuisance alarms. But it should be kept in mind that alarm fatigue can impact monitoring techs as much as direct caregivers. For maximum effectiveness and reliability, adequate alarm clinical practice is a requirement.
Hospitals who have deployed monitoring techs must turn down alarm volumes in the unit and rely on their monitoring techs, otherwise the key advantages of monitoring techs will not be realized. The “belt and suspenders” approach – using monitoring techs and keeping alarm volumes loud enough to broadcast across the unit, just in case – will not reduce alarm fatigue or improve patient satisfaction.
Monitoring techs’ jobs are challenging. Besides the alarm fatigue risk mentioned above, the job offers a mix of chaotic stress-filled periods combined with extended periods where nothing happens and it become difficult to maintain adequate vigilance. Due to the stress, staff turn over can be an issue. Monitoring techs are required to complete an 8 to 12 week EKG recognition course. Typical positions require a high school diploma and it is not unusual for positions to be filled by paramedics and those with other technical medical experience. In some hospital markets it can be difficult to fill monitoring tech positions.
The number of patients that can be monitored or observed by a single monitoring tech can vary from 24 to 60. There is no standard or widely accepted “best practice” for the ratio of patient to monitor techs. The number of patients watched by a monitoring tech is influenced by the skill and experience of the individual techs, along with unit census. Patient acuity or their unique physiological condition can also drive the ratio of patients to monitoring tech. Due to an unknown perverse confluence of patient condition and arrhythmia analysis algorithms, an occasional patient will generate almost continual false/positive arrhythmia alarms. Finally, much of this variability depends on the patient monitoring system in use and how many patient’s can be displayed and viewed at a workstation. Workstations typically have from 4 to 6 displays.
Another challenge of monitoring tech solutions is management data. To manage something, it must be measured, and there is plenty to be measured and recorded when it comes to alarm generation, notification and response. Patient monitoring log files can provide some data on alarms generated (the ease of access and user friendliness of the log files in patient monitoring systems can range from impossible to barely understandable with a decoder ring). Any data on screened alarms (nuisance or false positive vs “good” alarms) and caregiver response times for alarm calls, must be manually logged during the shift to compile a historical record. Manual record keeping like this is time intensive, prone to human error, and requires considerable effort for a consistent long term execution.
The costs of a monitoring tech solution are mostly ongoing operating costs. For a 400 bed hospital costs will be in the low seven figures per year. Capital costs include remote patient monitoring central stations needed to cover the maximum number of monitored patient and for use by each monitoring tech. Based on monitoring tech costs, the return on investment for most alarm notification systems is one to two years.
It’s hard to beat the nuisance alarm screening capabilities of monitoring techs. I suppose that some day alarm notification systems will have artificial intelligence or clinical decision support sufficient to be able to screen nuisance alarms. Maybe. The present day best practice solution is to implement robust alarm clinical practice (whether for monitoring techs or an alarm notification system) to minimize nuisance alarms. For an alarm notification system to fully meet this screening requirement, the caregiver must be presented with the clinical context of an alarm, often a sample waveform, so that they can do the screening themselves. Without this contextual data associated with the alarm, the caregiver is forced to run to the bedside to screen those nuisance alarms, potentially contributing to alarm fatigue.
When it comes to the routing of alarms to the proper caregiver and ensuring an adequate alarm response, it’s hard to beat an alarm notification system. Both routing and escalation are tasks easily automated by today’s software applications. Sure, monitoring techs can route and escalate alarms, ensuring a proper response, but at a substantial operating cost.
And when it comes to capturing quantitative data on alarm generation, screening and response the clear winner is the alarm notification system. Alarm notification systems capture alarm events, messaging events, escalation and response events – basically everything from the medical device to the resolution of the alarm is captured. How accessible that information is and whether it’s presented in a meaningful way for reporting purposes varies from system to system.
Patient flow and the need to monitor a wider variety of patients in growing numbers have been impacting hospitals for many years. In response, a lot of hospitals have increased the number of telemetry monitors to cover many patients in addition to those found in their telemetry unit. Yes, there are some patients on other services (say oncology or orthopedics) with cardiac or arrhythmia conditions that need telemetry outside of the telemetry unit. However many of the patients outside the telemetry unit are being monitored with telemetry packs because they are at risk of a deteriorating clinical condition and the telemetry pack is relatively inexpensive and patient worn. I would guess half the telemetry packs sold are used on patients of this type, rather than cardiology patients.
Using telemetry packs to monitor non cardiac patients is a poor match to the application. Patients with a deteriorating clinical condition are usually awfully close to cardiac or respiratory arrest before they start throwing arrhythmias. The good news is that there are a growing number of low acuity monitors better suited for this application. For those many telemetry packs still being “misused,” this creates a false demand for monitoring techs in their most powerful role of screening out nuisance alarms.
Hospitals in this situation may find that good clinical alarm practice will reduce nuisance alarms sufficiently to obviate the need for monitoring techs. Some may not. The role of monitor techs in these hospital should be determined on a case by case basis.