Role of Montoring Techs in Alarm Notification

Role of Montoring Techs in Alarm Notification

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.

Share
Read More

Order Workflows

Order Workflows

Except for emergent situations, no medical device is used without an order. And if not an order written to accomplish a certain clinical task for a specific patient, then “standing” orders captured in written policies and procedures to handle frequent, routine situations. Consequently, orders are one of the first workflow steps in medical device connectivity. Orders are pervasive, used in all health care delivery environments from acute care hospitals to patient’s homes.

Principal ways connectivity can add value to medical device are enhancing patient safety, improving clinical efficacy and productivity. That the inappropriate use or misuse of medical devices can result in patient injury or death is not news. Proper use or misuse can start with the order. Well designed and implemented order workflow automation in a connectivity solution can impact patient safety, the efficacy and utilization of the medical device, and staff/unit productivity. Besides their own unique considerations, order workflows share many of the risks and potential benefits of other types of connectivity workflows.

Share
Read More

Scheduling Workflow

Scheduling Workflow

Scheduling is not a workflow one normally associates with medical device connectivity. In some applications, scheduling is handled by software separate from the connectivity solution. Sometimes, scheduling is not done at all. In other applications, as we shall see, scheduling is so much a part of the broader workflow, that it’s hard to recognize as a scheduling task. Two illustrative aspects of scheduling will be discussed, scheduling for diagnostic modalities and scheduling for routine patient care tasks. Because it’s less understood (and frankly more interesting) we will look at scheduling for routine patient care tasks first.

Patient Care Task Scheduling

Patient care tasks encompass routine activities carried out by caregivers and/or aids. Examples of these routine tasks include vital signs collection, medication administration, bed turns (to avoid hospital acquired pressure ulcers, or HAPU), and respiratory circuit flushing (to avoid ventilator acquired pneumonia, VAP). These tasks must be completed at a predetermined frequency on a reliable basis or adverse events – including patient death – can result.

Share
Read More

Patient Context Workflow

Patient Context Workflow

Connectivity enabled medical devices send patient data right out of the medical device to a network, be it a body area network, cellular broadband network, home or enterprise network. The network then conveys this medical device data to databases and applications that store, display and manipulate the data. When a medical device is directly attached to a patient, there is no question as to which patient the device data belongs. As soon as the data leaves the actual medical device via the serial port or a network connection, the association of that data with a particular patient is no longer obvious.

Much of the data used in establishing and maintaining patient association or patient context comes from, or is stored in, the patient management database. Patient management workflow is an important enabling component in the overall connectivity solution and key to patient context management.

It is critical to reliably know that the data from a medical device belongs to a particular patient. If the data is not associated with any patient it’s worthless; should the data be associated with the wrong patient it could be deadly. When patient data from patient A is misidentified as belonging to patient B, patient A can miss out on a life saving clinical intervention that is mistakenly applied to patient B. In this example, patient A may die due to a lack of care, and patient B may be injured or die as a consequence of receiving some clinical intervention that is not needed and could be contraindicated. Consequently, safe and reliable patient association or patient context management is a foundational capability for virtually any medical device connectivity or interoperability solution.

Share
Read More

Alarm Fatigue Plagues Hospitals. Again. Still.

Alarm Fatigue Plagues Hospitals. Again. Still.

On April 8, 2013, the Joint Commission published a Sentinel Event Alert on medical device alarm safety in hospitals. Once again, alarm hazards tops the ECRI Institute’s 2013 Top 10 Health Technology Hazards. Alarm fatigue is unfortunately a topic that is evergreen because it has plagued hospitals for many years and shows little sign of abating. A search of the literature will show the most common consequence of alarm fatigue is a failure to rescue adverse event (in which the vast majority 80% of patients die). A secondary consequence is on patient satisfaction; constant alarms audible throughout the unit make it difficult for patients to sleep.

Share
Read More

Lessons from a Recent Recall

Lessons from a Recent Recall

A recent Class I recall (not pictured) of a medical monitor with a hospital network connected central station stimulates some generalities about software, “fixes”, and connectivity. (Class I recalls are defined by the FDA as  a situation in which there is a reasonable probability that the use of, or exposure to, a violative product will cause serious adverse health consequences or death.)

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.

Share
Read More