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.

Medical Device Connectivity in the Middle East

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.

Tim Gee is Principal of Medical Connectivity Consulting. He is a master connectologist, technologist and strategist working for medical device and IT companies and various provider organizations. You can learn more about Tim here.

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:

• Properly setting alarm limits,
• Buying quality physiological sensors, proper prep and placement of physiological sensors, and
• Making sure alarms from all monitored patients are audible in the nursing unit.

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 Need for Alarm Notification

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.)

Monitoring Tech “War Rooms”

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.

Background Info

Here are some additional links that may be of interest:

• ACCE page on alarm fatigue
• The ECRI Institute’s Alarm Safety Resource page
• Mainstream news stories on the consequences of alarm fatigue, here and here
• A great story on alarm notification written by Jim Welch
• Another alarm notification story from the same magazine written by yours truly
• Philips Issues Alarm Notification Warning Letter: a surprising letter to customers in reaction to continued adverse events associated with alarm fatigue

UPDATE:

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.

Tim Gee is Principal of Medical Connectivity Consulting. He is a master connectologist, technologist and strategist working for medical device and IT companies and various provider organizations. You can learn more about Tim here.

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.

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.

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.

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.

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.

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.

USA and FCC

Just this week the FCC released its task force findings on mHealth.  The overarching goal given to the task force was:  “By 2017 mHealth, wireless health and e-Care solutions will be routinely available as part of best practices for medical care.”  They were to produce actionable recommendations that could be taken by the FCC, other regulatory agencies and industry to reach this goal.  The FCC committed to implementing five specific actions in the list produced by the task force:

a)  Immediately recruit for an FCC Medical Director position

b)  Develop and execute a health care stakeholder outreach plan to promote greater collaboration between the FCC and the health care sector on policies at the intersection of communications and health.

c)  Direct the International Bureau to work with FCC counterparts in other countries to encourage them to make spectrum available for MBANs and to discuss possible spectrum harmonization to allow for medically safe cross-border patient travel and better economies of scale for device makers.

d)  Consider an Order by the end of this year to comprehensively reform and modernize the Rural Health Care Program, and

e)  Consider an Order by the end of this year to streamline our experimental licensing rules to promote and encourage the creation of wireless health “test beds” to permit easier testing of mHealth devices.

More information regarding the findings can be found here.

So in addition to the FDA and FTC, the FCC is signaling a significant re-direction and involvement in the mHealth industry.  What does this mean to those in the healthcare industry?  One would hope that the patchwork of regulations that cover this gray are become more integrated and clear for those who wish to delve into this part of the healthcare industry.  In the case of the USA, this does signal that the FCC understands that access to a communications infrastructure is a requirement to increase access to healthcare and other industries in remote areas.  Moreover, the FCC recognizes that the healthcare industry is large enough and relies and will continually rely more upon the telecommunications infrastructure to be viable.  Lastly, the FCC Chairman stated that another goal is for the USA to be the country were mHealth is the standard and sets the standard for the world.

Certification of Mobile Medical Applications

In the mobile medical applications realm, there is an organization that is working to make evaluating, purchasing and possibly developing Mobile Medical Apps easier:  Happtique.  According to the FAQs, Happtique is “mobile application store developed by healthcare professionals for healthcare professionals. Happtique offers healthcare enterprises—like hospitals, continuing care facilities, and physician practices—the ability to create individually branded, secure substores that support employee and patient mobile technology use.”

What is novel about this particular organization is that in order to be able to market an application on Happtique, the vendor must certify (and Happtique will verify) that they meet specific standards as per the Happtique guidelines.  These guidelines range from networkability, to protection of privacy to use of medical interoperability data standards.

To get an idea of what mHealth applications are currently available throughout the world, GSMA offers a mHealth tracker on their website which had listed the day this was written 707 mHealth products and services available around the world.  Not all of these are certified by Happtique, but perhaps in the future, the list of applications on these two website will converge.

Danish Telemedicine Action Plan based on Continua Guidelines

In news from across the pond, the government of Denmark has decided that their National Telemedicine Action Plan will be built on Continua Health Alliance Design Guidelines for personal connected health devices.  What is interesting about this is Denmark happens to be one of the countries in Europe who has adopted data and other interface standards for healthcare for over 20 years.  In fact, their current ‘medical device interface data’ standard is based on Electronic Data Interchange (EDI).  They will need to somehow work on a harmonization or convergence of HL7 and EDI for this effort to be effective; however, it should be interesting to see this progress. HL7 and EDI are messaging standards, so using the underlying data standards in the Continua Design Guidelines will definitely bring even more stringency in their standards-based approach.  The Danish Medcom site is a great website to see their 20 year progress on Health IT and interoperability and highlights the information in English.

We sometimes remember that there are also other government agencies that may have impact on what we do. For examples the role of  the FCC has been discussed here with respect to medical device wireless applications, and more recently the prospect of the FCC taking away part of the Wireless Medical Telemetry Spectrum (WMTS) has received attention in clinical engineering circles (while no one else seems to care). CMS is always of interest with respect to medical device reimbursement, and more recently with respect to meaningful use of electronic health records (EHR), which may or may not be medical devices. Advertising of medical devices is regulated by both the FDA and the FTC, and some over-the-counter devices bridge the FDA and Consumer Products Safety Commission divide. The FTC (but curiously not the FDA) has previously gone after smart phone  acne treatment apps because of their “baseless claims.”  When there is dual authority and a need for regulatory action I have wondered if having two responsible agencies is worse than having just one (leading to some new math such as 1+1 < 2, and might even be <1).

This month the FTC has weighed in on mobile apps in general with a brief guidance document entitled Marketing Your Mobile App: Getting it Right From the Start. This guidance is not aimed specifically at the medical arena, but such apps are not excluded. The broad topics covered by the FTC are truth-in-advertising and privacy. The specific topics are (1) truthfulness about what the app can do, (2) disclosing key information clearly and conspicuously, (3) built-in privacy protection, (4) transparency about data practices, (5) clear privacy choices, (6) actually following stated privacy practices, (7) attention to specific privacy practices for children as required by law, and (8) data security.

Certainly truthfulness about what an app can do (and not do) is an important issue for medically oriented products. When apps purport to  provide diagnostic results or “advice” it is important for the claims to be based on “competent and reliable evidence” and for the user to understand  the basis for asserting the claims including the underlying science and population to which it applies. Wrong advice can clearly be harmful if it leads the user to undertake an unnecessary treatment, or to forgo seeking medical attention. Apps that rely on user specific data rather than just being an electronic book are probably of greater concern  because of their perceived relevance and authority, but even simple look-up information can be dangerous if incorrect. These issues were the substance of the FDA’s mobile app actions cited above.

The second point on clear disclosure is the first cousin of truthfulness. Such disclosure takes on particular relevance when claims are made boldly but disclaimers (e.g. do not rely on this app) are hidden away. Hyperlinked disclaimers are of particular interest here in the sense that if the user has to virtually go somewhere else to get the information, has that information been adequately disclosed?

Data collection, data security and secondary data uses (e.g. marketing) also has particular resonance for medical apps in that the data may include personal medical information rather than the usual panoply of location, financial details, address book, etc. Here the FTC suggests that information collection be associated with an affirmative agreement and that what is collected, how it will be used, and how to opt out should be “clear and conspicuous”. This should include information that the user actively provides as well as information that the app can collect on its own.

While the FTC has addressed apps in general in this guidance, the principles are straightforward, and proper consideration of these principles must be added to concerns about whether an app is or is not a medical device subject to FDA regulation. Moreover, I can find a modernized version of the golden rule here: Don’t have your app do to others what you don’t want their app to do to you.

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.

…I am currently undertaking research into RFID technologies and WLAN to use within a hospital. In particular I am interested in implementing the use of patient/infant tracking tag, panic tag or status tag, asset tag and also temperature control tags, all of which are working with a WLAN.
Is there any information that you are able to share with me please.

While I don’t normally provide services for free (I have bills to pay like everyone else), I have no problem providing some initial information or value to get to a place where an actual project can be considered. So, in that spirit, here’s my reply:

I would be glad to share some info with you. From your email it appears you have a number of different indoor positioning applications which you want to undertake. The key to RFID is that there is no one best system or technology for all applications. You have to match the requirements of your positioning applications to the various capabilities of different systems, and many hospitals end up with more than one RFID system as a result.

You also mentioned Wi-Fi in conjunction with RFID. Many people mistakenly think that Wi-Fi is the only common sense solution for RFID. Sadly, this is not true. To get reasonable RFID performance from Wi-Fi you need a lot of access points. If your WLAN is already designed to support wireless VoIP, then you probably have enough APs to get decent RFID performance. If haven’t deployed wireless VoIP plan on at least doubling the APs you have installed for typical data applications like computers on wheels. The actual locations of APs also has a big influence on indoor positioning performance, and differs from where they would be sited for optimal data or wireless VoIP performance. As a result, you will likely have to move some of the APs you have. And even with a gob of APs, all in the most optimal positions, you still won’t get reliable room level accuracy – which is critical for some RFID applications.

There are two key variables in RFID performance, spacial accuracy and reliability. Spacial accuracy is the resolution or specificity with which an RFID system can place a tag in space, e.g., plus/minus 10 meters, 3 meters or 1 meter. Reliability is the RFID system’s ability to consistently indicate the correct location for a tag.

While RFID system performance can be thought of as a continuum, there are two common performance groupings – RFID that can resolve the general location of tags (e.g., the west wing) and those that provide room level accuracy. Most RFID technologies that are good at determining the general location of tags use some sort of RF triangulation between tags and multiple readers. Examples are Wi-Fi based systems from AeroScout and Ekahau and plug in readers from AwarePoint and Radianse. With RF triangulation systems, the greater the density of readers deployed the higher the spacial resolution. Even with a high density of readers, I’m not aware of any RF triangulation system that provides reliable room level accuracy. RFID systems that utilize ultrasound (Sonitor) or infrared (Versus or Centrak) are often the best at room level accuracy. It is also possible to use RF based RFID readers at choke points (in halls or doors) to provide room level accuracy.

Asset management applications for finding and generally tracking equipment like IV pumps and wheelchairs typically provide general locations. Room level accuracy is required for workflow automation such as ensuring medical devices are cleaned prior to being put back in service, or clearing a nurse call when a caregiver enters the patient’s room.

Infant abduction systems can be implemented using readers at the locations where people an enter or leave the unit, or systems that track infants from room to room. The latter systems are more expensive than the former due to the greater number of receivers or APs.

You should also be aware that the hidden cost of RFID systems is the cabling and installation costs of readers, The costs of receivers and tags themselves is pretty transparent. Tag replacement and maintenance (battery replacements) costs also tend to be hidden.

Application software – especially for specialized applications like infant abduction – are often tied to a specialized type of RFID system. An alternative is RFID application software that is RFID hardware agnostic; examples include Intelligent InSites and ConnexAll.

Tim Gee is Principal of Medical Connectivity Consulting. He is a master connectologist, technologist and strategist working for medical device and IT companies and various provider organizations. You can learn more about Tim here.

Unique Device Identifier

Two things in the FDASIA (pronounced “F-D-A sigh”) jumped out at me: unique device identifier and health information technology. Section 614 directs the Secretary of HHS to issue proposed unique device identifier (UDI) regulations by December 31, 2012, and to finalize the proposed regulations not later than 6 months after the close of the comment period.

In general, the UDI is a good thing in that it will likely contribute to improved supply chain efficiency. All the claims about improved post market surveillance, patient safety and quicker, more reliable recalls are considerably beyond the ability of what is really just a hopped up serial numbering scheme. To achieve the widely trumpeted safety benefits would require the wide adoption of an information system that does not yet exist. There are a lot of cool ways such an information system could come into being – the feds, some outfit like the ECRI Institute, or an open source software project driven by hospitals.  And of course, you’d have to get health care providers to, you know, actually use the software.

Needless to say, the easy part with be getting the UDI onto products (and that’s taken years).

The big news for many folks is that there is now a legislative mandate to regulate HIT.

Regulation of Health Information Technology

Based on the process laid out in the FDASIA, the time it will take to realize a medical device UDI will, in retrospect, probably seem like a blink of the eye. In short, the FDA, FCC and NCHIT are to get together, with a working group of external stakeholders, to create a report on how to regulate HIT. This is supposed to happen within 18 months of today. What happens after the report is not specified.

From the text, below, HIT appears to include EMR/EHRs, mHealth, and other information systems that pose a risk to patient safety.

SEC. 618. HEALTH INFORMATION TECHNOLOGY.

(a) REPORT.—Not later than 18 months after the date of enactment of this Act, the Secretary of Health and Human Services (referred to in this section as the ‘‘Secretary’’), acting through the Commissioner of Food and Drugs, and in consultation with the National Coordinator for Health Information Technology and the Chairman of the Federal Communications Commission, shall post on the Internet Web sites of the Food and Drug Administration, the Federal Communications Commission, and the Office of the National Coordinator for Health Information Technology, a report that contains a proposed strategy and recommendations on an appropriate, risk-based regulatory framework pertaining to health information technology, including mobile medical applications, that promotes innovation, protects patient safety, and avoids regulatory duplication.

(b) WORKING GROUP.—
(1) IN GENERAL.—In carrying out subsection (a), the Secretary may convene a working group of external stakeholders and experts to provide appropriate input on the strategy and recommendations required for the report under subsection (a).

(2) REPRESENTATIVES.—If the Secretary convenes the working group under paragraph (1), the Secretary, in consultation with the Commissioner of Food and Drugs, the National Coordinator for Health Information Technology, and the Chair- man of the Federal Communications Commission, shall deter- mine the number of representatives participating in the working group, and shall, to the extent practicable, ensure that the working group is geographically diverse and includes representatives of patients, consumers, health care providers, startup companies, health plans or other third-party payers, venture capital investors, information technology vendors, health information technology vendors, small businesses, purchasers, employers, and other stakeholders with relevant expertise, as determined by the Secretary.

The FDA has already published a draft guidance on mobile apps, and they’ve been waving a red flag about their patient safety concerns regarding clinical decision support systems (CDSS) specifically, and EMRs in general. Last year I attended a public workshop at FDA on mobile apps and CDSS where they received input and laid out their ideas about a way to evaluate patient safety risk in those areas. (If you’d like to know more about what was discussed, give me a call.)

I think it’s important to note that while identifying the key government stakeholders (FDA, FCC and NCHIT), the legislation does not change any of the stakeholders responsibilities or authority: the FDA is responsible for patient safety and effectiveness, the FCC remains responsible for RF spectrum allocation, and the NCHIT is responsible for ensuring that HIT solutions meet a minimum level of functionality. Which entity will loom largest over manufacturers? The FDA.

The interested readers should also note that there is nothing in the legislation to preclude FDA from regulating manufacturers as soon as they feel the need.

Implications for Industry

In a world where it is almost impossible to buy a home hot water heater or air conditioner from a manufacturer who does not follow a quality system (ISO9001), it would not seem to be a big hurdle for HIT manufacturers to follow a quality system too. For HIT vendors, the biggest hurdle will be adopting the FDA’s Quality System regulation (which is not that different than ISO9001). Some products may require pre-market approval, i.e., the submission of a 510(k) by the manufacturer and clearance by FDA before the product is sold. Very few – if any – HIT products will require PMAs and clinical trials like drug companies have to contend with.

So what should industry do now? The following are some questions that anyone (vendors or providers) developing HIT software or systems should ask:

• Do any of my products meet the legal definition of a medical device?
• Based on FDA’s recent actions, how likely is it that my company/market segment will become regulated?
• What does it mean to become a regulated manufacturer?
• How might my products be regulated?

You can find many posts on this blog that look at these issues:

• Facing FDA Regulations for the First Time
• Charting Your Regulatory Course
• Impact of Potential FDA Regulation of EMRs
• Navigating Regulatory Uncertainty for Smartphones
• FDA Addresses Mobile Medical Apps
• Mobile Apps Guidance Q&A

Tim Gee is Principal of Medical Connectivity Consulting. He is a master connectologist, technologist and strategist working for medical device and IT companies and various provider organizations. You can learn more about Tim here.

On February 22, 2012 the Centers for Medicare and Medicaid Services (CMS) released (in a mere 455 pages in manuscript form) a proposed rule for Stage 2 criteria for qualification of an EHR for the Medicare incentive program. Among many topics, the proposed rule includes some elaboration on the mandatory use of CDS’s as well as issues related to their design and utilization.

This mandate might be viewed in the context of AHRQ’s statement (here) that “Despite thoughtful efforts over the last three decades to translate clinical guidelines into CDS rules, there has not been widespread and successful use of such rules to improve patient care.” Of course limited success to date does not mean that CDS cannot be beneficial in the future. In addition there is a wide range of sophistication in systems that might be called CDS, and which would in part satisfy the MU requirements.

In general the CDS Stage 2 objective is to “Use clinical decision support to improve performance on high-priority health conditions.”  The associated Stage 2 measure as proposed is to, “Implement 5 clinical decision support interventions related to 5 or more clinical quality measures at a relevant point in patient care”, including enabling and implementing drug-drug and drug-allergy interaction checks.  The drug related functionality is intended to provide  information to “advise the provider’s decisions” in prescribing drugs to a patient.

The “advise” component of CDS is a challenging issue since the quality of the advice is a critical element in any CDS system. It is here that the degree to which the provider can and should rely on that advice becomes an important  part of how CDS should be used, and equally how it will actually be used. In this regard it is common for advice systems to have a variety of disclaimers and associated assertions that the professional must in effect second guess the advice given and make their own judgement.

While logical, the value of a CDS that you can’t rely on is at least questionable, as is whether users will always mentally challenge the results. In this regard there are at least three ways in which CDS’s can go astray. One is when the underlying information upon which the advice is based is not strong. A second is that although the underlying data is strong the software is defective. Third, a patient’s individual condition may fall outside of the boundaries for which the information is reasonably correct even though the software is a reliable representation of that data. Moreover, the boundaries of the accuracy domain are often ill defined or not defined at all.

The Stage 2 proposed rule takes an interesting pass at these issues by requiring that each clinical decision support intervention must enable the provider to review all of the following attributes of the intervention:

• Developer of the intervention,
• Bibliographic citation,
• Funding source of the intervention, and
• Release/revision date of the intervention.

Thus instead of just a result (or ranked results perhaps) popping up, the user must be provided with the people and data behind the result, and how old that data is. The proposed rule states that “such information may be valuable so that providers can understand whether the clinical evidence that the intervention represents is current, and whether the development of that intervention was sponsored by an organization that may have conflicting business interests including, but not limited to, a pharmaceutical company, pharmacy benefits management company, or device manufacturer.”

This kind of disclosure is good, but it does not fully account for the degree of validation of the actual results that are generated. It is also proposed that the CDS suggested/advised/proposed interventions must be presented through Certified EHR Technology at a time relevant to direct patient care to a licensed healthcare professional. That professional is then expected to ”exercise clinical judgment.” Therefore it is clear that a CDS cannot be fully relied on, nor can it be a substitute for an appropriate healthcare professional.

The “presented through” requirement suggests that the CDS must be well integrated with the EHR, although this is short of requiring that the CDS actually be part of the EHR. This suggests that EHRs would have to have high flexibility to integrate with the required CDS’s, which conceivably come from different vendors, adding to the challenges of–dare I say it–connectivity itself.

Not all CDS systems will need to be particularly sophisticated. One example given in the proposed rule is a CDS that triggers a point-of-care alert from the EHR that prompts a licensed healthcare professional to ask about influenza immunizations when engaged with a patient 50 years old or older. This kind of little reminder is not fraught with the deeper issues of CDS reliability. More generally it is noted that family health history can be used to inform CDS and patient reminders and patient education. Another suggested CDS application is generic drug and insurance formulary information.

Those who believe that activity should not be confused with results will not find comfort in the observation that for Stage 2 CMS does “not propose to require the provider to demonstrate actual improvement in performance on clinical quality measures” through using a CDS, although improvement should be the provider’s goal.

This proposed rule has a 60 day comment period after which CMS will cogitate on the comments received and publish a final rule with any revisions deemed appropriate. Effected professionals and hospitals will have to watch for this final rule.

Unrelated to MU and CMS, but an interesting example of the intended use of CDS is the approval by the FDA of a software driven mammography pattern recognition system that analyzes the mammography images and marks suspicious areas consistent with breast cancer for review by a radiologist. Of particular interest to me is that the approved method of use is that the radiologist first reads each image in the conventional manner, and then re-examines each region marked by the software analysis before making a decision about the image.  The instructions for use, also posted by the FDA, include important warnings in this regard including that the marked images do not have the level of detail of the original mammogram and that their only purpose is to provide a reference for the location of the auto-generated marks. Further it is stated that the algorithm will not mark all regions that contain cancer and will mark regions that do not contain cancer. As a result the presence of a mark only indicates that a radiologist should review the marked region again to avoid a potential oversight, and the absence of a mark should not dissuade a radiologist from investigating their own suspicious findings.

 Thus the intended use clearly states that the automated read is not sufficiently reliable to be used as a primary analysis, or perhaps that the manufacturer doesn’t want to take on the responsibility of primary analysis, or that the FDA would not accept a claim of primary analysis. It is also possible that radiologists are able to protect their image reading turf by discouraging reliance on automated systems. In any case, the result is a CDS system that is not primary, and cannot be totally relied on.

The next questions then are how will it actually be used, and to the degree that it may be relied on, how good is it? An associated question of interest is whether radiologists would chose to not follow-up on a flagged region that they didn’t think was suspicious, or would they always pursue the next steps which may include biopsy. Since those next steps involve the potential for both physical and psychological adverse outcomes, pursuing that which doesn’t need to be pursued is not without consequence.

The experiences of radiologists using the system would also be of interest. Even doing what the instructions say, the radiologist may find that the system only finds what they have already found, and/or doesn’t find what they have already found, and/or finds things they didn’t find that are spurious, or really does find important things that they missed. Each possibility and their combination will inform how such systems actually come to be used, or not used.

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.