Last month I spoke at the first CIS Qatar International Conference in Doha Qatar. My topic was the Importance of Enterprise Wide Medical Device Integration in CIS workflow. You can download a copy of my presentation here.
This was the first such conference in Qatar with over 1,500 people attending. The ballroom only had capacity for 1,200 so they had remote screens and audio for the 300 overflow attendees. Several hospitals in Qatar are in the process of implementing Cerner’s EMR, so there is a lot of keen interest in all things EMR.
The conference program was focused on implementation issues and what it takes to realize the benefits of EMR adoption. My presentation provided an overview to medical device connectivity and clinical documentation and introduced use cases as a way to assess current and future workflows to ensure effective workflow automation from medical device connectivity.
There were a lot of great HIT and health care thought leaders from the Middle East at the conference. Not surprisingly, the intersection of IT and biomed came up in a number of conversations. In many Middle Eastern countries, numerous hospitals are in development or being constructed. These health ministries that are building hospitals have found ready access to experts to specify and help select HIT solutions and to specify the numbers and types of medical devices needed for the expected patient populations to be served by the hospitals. What is missing is any recognition and resulting planning for HIT and medical device systems to work together smoothly by opening day of a new hospital.
There are two challenges presented by medical device connectivity for new hospital construction. Between conventional HIT and medical device systems lie connectivity workflow automation systems for clinical documentation, alarm notification, clinical decision support systems for things like tight glycemic control, and numerous other such systems. Many of these are rapidly emerging product categories that may be missed by those specifying new hospitals. When specifying connectivity for new hospitals, buyers must be presented with the key workflow automation trade-offs and connectivity specifications to ensure the best possible connectivity solutions are selected.
The the other challenge is the operational gap that occurs when IT shifts from mission-critical to safety-critical operations. Like those the US market, hospitals in the Middle East are still grappling with the convergence of IT and biomed and the fact that what was once a mission-critical IT infrastructure becomes a safety-critical infrastructure with the introduction of medical device systems. Elsewhere, I’ve referred to this gap as the “governance gap” where current HIT operations must become more rigorous to safely support life-critical medical device systems.
After the new hospital is built and opened, a much bigger challenge arises. Everything pretty much works as specified when it’s first installed. But as IT and medical device components and systems are upgraded, discontinued and replaced, and as the physical plant undergoes the inevitable renovation and new construction, a lot of things change – a lot. And the skill sets of personnel and the policies and procedures used to manage HIT operations must be revised to a safety-critical level to maintain adequate levels of productivity and patient safety.
Patient safety is something for which CIOs and hospital IT departments have never been directly responsible. When medical device systems, like patient monitors and infusion pumps, communicate over the enterprise IT infrastructure and are integrated – perhaps interoperable – with HIT applications, patient safety is on the line.
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.
The root causes of alarm fatigue can be divided into two areas: 1) nuisance alarms caused by false positive alarms, leads-off alarms (most often due to motion artifact, poor lead prep and/or low quality sensors), and alarms that are not clinically actionable (i.e., the alarm goes off and the nurse responds, but there’s nothing for them to do), and 2) noise pollution resulting from annunciating all the alarms in a busy high acuity unit at sufficient sound levels to be heard throughout the unit.
Effectively managing alarm fatigue requires hospitals to do a number of somewhat complicated of things well. The Joint Commission Sentinel Event Alert, and AAMI’s efforts on alarms tend to focus on these basics:
These clinical and operational best practices will reduce but never eliminate alarm fatigue, especially on busy high acuity units – to do that you need to mitigate the incessant noise from alarms going off across the unit – 24/7.
The patients in a typical high acuity unit generate a lot of alarms; the (thankfully) rare patient generates alarms continuously. Making sure all medical device alarms are audible throughout the nursing unit becomes a big part of the problem. The noise from all these device alarms is broadcast across the unit for everyone to hear and quickly becomes overwhelming, desensitizing caregivers and resulting in alarm fatigue.
In these situations, the ability to route alarms from the medical device directly to the responsible caregiver, and notifying them without exposing the rest of the nursing unit staff to every alarm, can have a huge impact on reducing alarm fatigue to a manageable level. (I currently track around 17 messaging middleware vendors who provide alarm alarm notification features.)
Some hospitals utilize monitoring techs to pre-screen alarms for caregivers in an effort to filter out false/positive nuisance alarms and to enable a reduction of alarm annunciation volumes in the unit. When this approach is used, monitoring techs watch remote central stations and notify the responsible caregiver when they see an actionable true/positive alarm. Monitoring techs are either gathered in a central location, often called a “bunker” or “war room,” or placed within the unit they are supporting.
Using monitoring techs allows the nurses on the units to turn down alarm volumes and await notification from monitoring techs of alarms via “bat phones” placed around the units, Vocera badges or wireless handsets carried by the nurses. The problem with monitoring techs is that they’re expensive. A 500 bed hospital can spend $2-3 million in operating costs annually on this approach. In many markets, finding and keeping these monitoring techs can be very difficult.
Compared to monitoring techs, an alarm notification solution automatically routes alarms to the caregiver responsible for the patient generating the alarm. These systems also automatically escalate notifications to backup caregivers ensuring a timely response to all alarms. One weakness of alarm notification solutions is that they cannot filter out false/positive nuisance alarms the way a trained and certified monitoring tech can. In the past, products like DataCritical’s StatView, and similar products from Spacelabs and a few others – all now discontinued – displayed physiological waveforms of the alarming parameter associated with the alarm. This would enable the caregiver to quickly rule out false/positives and other nuisance alarms by looking at the same waveforms a monitoring tech would see. However, other than Welch Allyn’s AcuityLink Clinician Notifier, none of the currently available alarm notification solutions include physiological waveforms.
When comparing the use of monitoring techs to purchasing an alarm notification solution, monitoring techs continue to have the advantage of being able to see the physiological waveforms associated with an alarm and make a determination as to whether the alarm is a false/positive alarm or not. Once alarm notification vendors implement support for waveforms (it’s been done before, and cleared by FDA) this advantage of monitoring techs will be neutralized.
Given the ever present and increasing pressures on hospitals to control costs, I expect alarm notification systems to replace monitoring techs in the mid to long term.
Here are some additional links that may be of interest:
The Joint Commission has published an infographic about medical device alarm safety that reinforces the root causes and consequences of alarm fatigue.
Sadly their recommendations/solutions in the infographic are totally inadequate. I would estimate that virtually 100% of hospitals and nursing units have already undertaken the activities on the Joint Commission’s infographic list. In fact, their recommendations are just that, a list of activities, without the context of specific goals or objectives that must be accomplished to reduce alarm fatigue.
Eliminating alarm fatigue requires accomplishing three objectives: 1) greatly reduce nuisance alarms, 2) screen out false/positive alarms, and 3) route and manage alarms electronically to reduce noise pollution and ensure a timely alarm response. The 5 recommendations in the Joint Commission infographic are really just some of the activities required to implement the three objectives above.
And be sure to check out this ongoing discussion on alarm fatigue here under the Healthcare Technology Safety Institute’s group page on LinkedIn.
There are currently several private entities that seek to certify medical apps, connectivity solutions, EHR record exchange, and other products, services and people in our sphere of interest. Given the ongoing proliferation of private certifications, there is a growing need to evaluate them, judge their relative costs and benefits, and determine which – if any – are worth adopting as either the one certified or as the consumer of certified products or services.
These private activities are usually distinct from governmental requirements (e.g. FDA or FTC compliance, or state licensing), although in the case of EHR Meaningful Use (MU) certification, private entities function on behalf of the federal government to certify compliant EHRs. Note here that compliant EHRs are those that are capable of achieving MU. Purchasing a product that is thus certified is a prerequisite for a provider then achieving MU.
Government/private interaction is also relevant to some Class II FDA device regulation which are eligible under third party review. Internationally, private notified bodies are part of the CE process necessary to meet EU requirements. Private efforts can also become public when an authority having jurisdiction (AHJ) adopts or cites compliance with a non-governmental standard or certification as required by law or regulation. Private certifications can also have secondary private impacts such as when a third party requires compliance with a certification or standard. For example a seller of a product might require that it be certified, or an insurance company might be interested in whether or not their client is producing or using certified systems. Similarly, a hospital accreditation organization might cite standards of the National Fire Protection Association (NFPA), although the NFPA does not itself provide certification of compliance.
Private certification efforts share a number of common questions. The first is who is the certifying entity, and what is their stated purpose? This might include some general public value, e.g. assured capability, safety, or some enhancement of commerce resulting from interoperability. However it might be necessary to look beyond the stated purpose to other purposes such as deriving fee income or limiting access to a market or profession. There may also be questions about related products or services associated with the certification process. For example, are consulting services or training available from the same entities that created the requirements? Or does a group of certification supporters make products or have other interests that are met by their self-created requirements, while creating a barrier to others?
The second broad question is what are the criteria for certification, i.e what measurable and subjective criteria must be met in order for an applicant’s product or a person to become certified? Typically there will be specified technical attributes and associated test methods. The certifying entity might conduct such tests, or have the applicant submit or attest to test results. In addition to more-or-less easily measurable features, there may also be softer criteria such as human factors (usability) considerations, or oral interviews for individual certification, for which truly objective tests might not be available. It is also good if there is feedback from testing to criteria development. If everyone passes the test or answers a question correctly, the assessment may be too easy. If few pass, the test may be too difficult, and/or irrelevant. In this regard an interesting process in careful multiple choice written testing is the post-test identification of questions for which there were a large number of wrong answers. This allows the wrongness to be re-assessed, or ambiguity of the question to be resolved.
A related question is how broad is the scope of the requirements, i.e. do they broadly or narrowly define the necessary attributes of the product/person? Overly narrow requirements can result in a system/person passing a test when that test is not by itself sufficiently indicative of actual real world performance requirements. For example a connectivity solution may be too limited in its performance scope to assure easy and reliable usefulness. It might for example measure A to B connectivity but not A to C, or it might include data string definition but not patient identification. A related issue is how open was the requirements development process, and were the requirements written to benefit only one segment of the industry. Of course public disclosure of the requirements is also necessary if compliance with them is to have any external meaning. Here clarity is also a factor. When the developers of a standard offer consulting services that are necessary to explain it, that might be cause for suspicion.
Once the requirements are known the next question is how rigorous, independent and fair is the testing? The answer here may be clearer for objective tests than for subjective ones. More to the point is the issue of whether a product passing the test is the result of a fair and unbiased assessment, or do the people doing the assessment have a self interest in the outcome. Fully public testing is attractive in this regard. In other cases testing results and other assessments have, at a minimum, to be fully available to the applicant. There would be heightened transparency if these results were also made publicly available, at least for systems that were deemed to have passed.
There are two ultimate questions related to whether the value of the certification is itself valuable. One is whether or not customers and other interested parties care whether or not certification has been obtained. This is the case for both product and personal skill certification. For the latter, other than self-satisfaction, there is the question of whether anyone else (e.g. employers) cares if one is certified. Thus it could easily be the case that there is a product or skill certification that is fair and meaningful but for which there is no consumer demand that the products being bought, or people being hired, have that certification. Lack of demand can in turn diminish the desire to be certified, and reduce compliance even when such compliance would actually be desirable.
The second value issue is that it could be the case that customers would seek out a certification that is not in fact meaningful, presumably based on some level of promotion that has convinced them that it is meaningful. Sometimes this promotion comes from the same entities that have created the certification in the first place. Or, even if not actually meaningful, the consumer might value a certification if they can gain some advantage from being able to claim that they use certified products or people. This would be a secondary marketing consideration aimed at the customers/clients of the original certified entity.
As private certifications multiply and seek their foothold in the doors of e-health commerce, there is reason to remember the old droll adage: Standards are wonderful, that is why there are so many of them. This could be amended here to state: Certification is wonderful, that is why so many organizations want to provide it.
The medical app and regulatory pot is being stirred as products continue to appear, including those with questionable FDA credentials, or lack of credentials.
As discussed in our earlier posts on apps regulation (here and here), an app is a medical device if its meets the congressionally mandated and FDA enforced definition of a medical device as something whose intended use “is for the diagnosis of disease or other conditions, or the cure, mitigation, treatment, or prevention of disease, or is intended to affect the structure or any function of the body of man”. As stated in the FDA’s Draft Guidance, omitted from this definition, and therefore not medical devices, are apps “that are solely used to log, record, track, evaluate, or make decisions or suggestions related to developing or maintaining general health and wellness.”
Some manufacturers have identified this health and wellness exception as fertile ground for asserting that their product falls within this exception, and therefore is free of FDA before-market scrutiny. In some cases this ground is plowed in the form of an express disclaimer, even though such a disclaimer may not be particularly credible. For example Brad Thompson, in a post for MD&DI cites the example of a urinalysis phone app and hardware system that includes the disclaimer that the device “is intended to be used for health and wellness information purposes and as a demonstration of technology. It is not intended to be used for diagnosis of disease or other conditions, or the cure, mitigation, treatment or prevention of disease and should not be used as a medical device.” In other words, the manufacturer expressly disclaims the very definition of a medical device. (And, no, you do not urinate directly on the phone.)
This disclaimer might be fine if it made sense that you would do self urinalysis just for wellness purposes, and if the company did not also make assertions on its website that appear to be to the contrary, e.g. ”can help you analyse, interpret and trend your urinalysis data to help you understand and manage diseases like diabetes and its, urinary tract infections and pre-eclampsia.” If the device is being used to manage disease it pretty much sounds like a medical device, despite the disclaimer. We, and presumably the FDA, then have the issue of whether claims can be offset by disclaimers, i.e. is it a balancing act in which the greater weight prevails, or do claims establish intended use regardless of disclaimers.
An interesting thing about an express disclaimer based on the very definition of a medical device is that it demonstrates that the manufacturer was fully aware of FDA requirements and was actively trying to avoid falling within the regulatory framework. This is different from those app developers who remain ignorant of FDA regulation (or so they may claim). Avoidance and or ignorance of FDA regulation is not limited to the app arena. I recently attended a talk by a company that aggregated and moved around medical data over the hospital network and that appeared to me to be in the MDDS space, if not of an even higher classification. When asked about their FDA status (and not even by me), the response was a shrug and general denial that they were covered.
If disclaimers actually are enough to free oneself from engaging with the FDA, there is no reason why their efficacy would be limited to mobile apps. For example we have discussed the disclaimer that a VoIP hospital phone system was not intended for primary communication, and that Clinical Decision Support (CDS) systems might carry a disclaimer to the effect that the advice provided by the CDS should not be relied on. This leads to one form of the ultimate disclaimer: “This product may or may not do what we have claimed it can do. Therefore it should only be used for personal entertainment, or as an adjunct to the use of other devices that can confirm that this device actually works.” Or going one step further: “Do not use this product.”
In this more general regard I recently had occasion to review a device’s direct-to-patient brochure where it was alleged that the information in the brochure was misleading if not not outright false. Part of the manufacture’s defense of this allegation was the asserted expectation that the patient’s discussion with their physician would offset the lack of being forthcoming in the brochure. One might characterize this as asserting that it was OK to be misleading in one document if you told the truth elsewhere. i.e. you had to add up (and maybe weight) the misinformation and the correct information across multiple platforms and assess the net weight to determine net truth or falsity.
By the way, medical apps are/were the subject of House hearings on 3/19-21 following a March 1 letter to the FDA by house Republicans asking about both regulation and taxation under the Medical Device Tax. In part the letter asked what I thought the FDA had already answered, e.g. does running a medical app on an off-the-shelf general purpose platform make that platform a medical device? Answer: No. More on these hearings to come.
In preparing for my presentation on Stage 2 Meaningful Use (MU) requirements for the November, 2012 Fourth Annual Medical Connectivity Conference I had the opportunity to delve further into the question of what had to be connected to what, and interoperable with what, in order for providers seeking EHR incentive payments to satisfy their MU obligations. (I ended up making this presentation by phone from New York to Boston because of the lack of transportation out of New York post hurricane Sandy.)
Stage 2 of the federally defined Meaningful Use (MU) is now upon us (details here), and a recurring theme is clearly interoperability. But what this means, and to whom, has not always been clearly presented. In this regard there has been occasional talk from the medical device engineering side of the room that MU requires that a variety of “traditional” medical devices must be able to send data to the EHR. (I introduce the term traditional here to distinguish common bedside medical devices from new players such as Clinical Decision Support systems (CDS) and perhaps EHRs themselves.) However, with a few exceptions, these traditional devices are not part of the MU requirements, and an actual reading of the Stage 2 regulations, and the means to test EHRs for certification, shows that there is no required call for such direct communication. This does preclude that some elements of the Stage 2 requirements might be enabled by connectivity of traditional medical devices, but might is clearly not the same as must. In this regard the official definition of MU must be separated from the general notion of in some way using an EHR for some meaningful end. It might also be noted that some parts of required MU might in fact not be very meaningful.
What medical devices do require connectivity for MU? The answer is imaging and lab, from which diagnostic results must both be accessible from or within the EHR. And the lab results must be “structured data” which presumably precludes sending a fax and then scanning it in. Another medical device arena is the requirement for multiple CDS functionality within the EHR, where each CDS application must operate automatically on information already in the EHR, i.e. the CDS must automatically do its assessment and notification alert without further intervention by the user. Of course the user will then have to determine what to do with the information provided. To the degree that a CDS is a medical device (and the FDA has certainly acted in a way that shows that at least some of them are), then a CDS that is part of MU of a EHR is a connected medical device, albeit not a traditional one.
The vital signs component of Stage 2 MU is a good example of an element that might use connectivity, but which doesn’t have to. On a recent medical encounter of my own, various vital sign data was observed by the technician and then typed into the nearby desktop without first writing it down (on cuff, palm or scrap of paper). MU does not require that the vital sign data arrive in the EHR automatically via a connected solution. It only requires that the data be entered and available, and manual entry is fully acceptable. So while an automatic data delivery vital signs solution might be attractive, there is no requirement that this be the approach taken. In this regard the MU certification test method for vital signs appears to be written for manual entry, and an auto-only implementation would require some talking around the test method.
We might recall why auto-vital signs is thought by some to be desirable (other than the medical device vendors). The usual reasons are it is faster (more timely and efficient), correspondingly frees the care giver from the task, and there would be an elimination of transcription errors. More-or-less continuous (or regularly sampled) vital signs data might also be enabled, addressing the problem of the only data that is available being old data. However there are few positive things in life without a potential downside. Here the possible downsides are incorrect association of data and patient, unreliable success of transmission, and the loss of an active human filter on whether the data seems correct or not. Note that here the human does not determine if the data is actually correct because they typically don’t have an alternative measurement. Instead they can only determine if the data seems reasonable. In this regard unreasonable data, assuming it can be well defined, is a fine candidate for automatic detection.
There are no current MU requirements for other patient specific medical devices (e.g. infusion pumps, monitors, ventilators, etc.) to communicate with the EHR, and little place in the MU elements for the use of such data, even if it were available. While there may be uses for such data other than MU, and these uses might be meaningful in a more general sense, I have seen more articulation of how it was being done than why it was being done. At a minimum it does create a historical record, but one that is likely never to be looked at unless there is an untoward outcome. MU has much more of an emphasis on immediate/point-of-care value.
So that covers medical devices. Yet there is much talk of interoperability in the context of EHRs, but in general it means the exchange of data from one EHR to another, to a Health Information Exchange (HIE), to public health data bases, or to and from the patient. This type of on line data exchange is an important part of the promise of EHRs to actually have a positive impact on individual care and public health, and these exchanges are required (although how it is going to happen is an ongoing struggle). But these exchanges do not involve traditional medical devices. However if an EHR is a medical device (which is yet to be fully vetted), then the interoperability requirements become applicable to them as medical devices, and then one could say that there is an MU requirement for interoperability of medical devices. But this line of semantic, if not circular reasoning, still doesn’t mean that other devices need connectivity for MU purposes. There are also other connectivity functions that are required such as Computerized Physician Order Entry (CPOE), but again this does not involve a traditional medical device.
Another MU term that caught my engineering ear was the discussion of feedback in medication delivery. Further reading showed that this did not mean that the drug delivery mechanism was being automatically controlled after a drug was ordered and made available, e,g, a closed loop infusion pump. Instead it meant only that a human was providing feedback that the final stage of the drug delivery process had been executed.
The bottom line is that MU for the most part does not require the connectivity of medical devices and the associated direct receipt of medical device data by an EHR. If someone tells you there is such a requirement, ask them to show you the specific associated MU data element and its explanation. While I am not from Missouri, “show me” is always a good request when there is an assertion that something is required. And the answer has to be specific (e.g. by CFR cite), not generic (e.g. its in the MU requirements).
A word about Stage 3. In general Stage 3 is a discussion at this point so that there are no requirements that have been agreed to. However there is a draft requirement (SGRP 204B) that some home medical device data be made available by patients to an EHR. An early draft of this element alluded to this happening automatically through a device connectivity solution. However the current draft does not suggest this. Instead patient entered data would suffice without a requirement that the device be the direct communicator. But automatic is certainly not precluded. Another general lesson here is that early discussions and drafts are not requirements, and might not ever be requirements. Pay attention–yes. Say, you have to–premature.