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.

1. HIMSS 2012 is focusing on mHealth with several sessions and will have a kiosk on the vendor floor which features speakers on the mobile aspect of healthcare
2. AAMI has published in their IT World column a synopsis of mHealth (requires login credentials)
3. Here in Europe, the Mobile World Congress, Barcelona Feb 2012, sponsored by the GSM Association, has a track devoted to mHealth (filter for Mobile Health), a day of demonstrations and a specific plan on embedded mobile medical functionality.
4. Additionally, the FDA has come out with draft guidance and has promised final guidance regarding mobile medical apps.  The European Commission has entered into an MOU with the HHS to work together on the regulatory aspects of healthcare.  I wouldn’t be surprised if they come out with similar regulatory guidance regarding mHealth as that promulgated by the FDA.
5. Lastly, from a market perspective, “The mobile health market has a year-over-year growth rate of around 17% since 2010 and is estimated to be worth $2.1 billion at the end of 2011. The report also said the mobile health market is expected to grow …. nearly 22% from 2012 to 2014.”

One might ask, what is mHealth?  It has many different definitions and from a product offering perspective could range from texting information on a mobile phone to a provider and/or specifying a provider geographical location to a patient to bi-directional interaction with a medical device to/from an electronic medical record application via mobile phone or telecommunications frequencies (or the medical device could be embedded with the mobile telecommunication appliance).  As with the traditional Healthcare industry, as one progresses up the interaction functionality chain, the design and interoperability gets more complex.  Most of the latest news items I read about successful mHealth applications describe the ‘easier’ applications:  texting, scheduling, location, etc.  There is still growth and development in the marketplace for interactive medical-device integrated/connected products.  Additionally, from a market perspective, most of the current product offerings are proprietary in nature and vertically integrated.

Mobile telecommunication vendors are keenly interested in providing for the healthcare market.  They are closely watching as well as working to influence the regulatory environment.  From a provider perspective, this means adding another large player to the mix.  You may already provide some internal mobile telecommunications support, but providing healthcare monitoring over that infrastructure changes the rules of the game.  In addition, the mobile telecommunications market plays to the consumer market, which has faster turnaround times, and higher customer expectations.  The consumer market expects the ability to smoothly transition service when changing a ‘product provider.’  In addition, with social media, the pressures are higher; witness the recent policy and product turnaround of Verizon to a charge for customers using a specific billing mechanism.  The healthcare provider is not used to this type of oversight or pressure yet.

Down in the healthcare provider trenches, testing remote monitoring and the use of mobile telecommunications offerings continues.  Here in Europe there are two larger projects that are interested in demonstrating the efficacy of remote monitoring.  One, the Whole System Demonstrator based in England and their National Health System (NHS),  has just published its preliminary results.  Another, Renewing Health, is based on a nine European country pilot for remote monitoring of chronic diseases. In the case of the Whole System Demonstrator, initial results have been very positive for the clinical outcomes regarding the use of remote monitoring models for chronic disease management with a “15% reduction in A&E visits, a 20% reduction in emergency admissions, a 14% reduction in elective admissions, a 14% reduction in bed days and an 8% reduction in tariff costs” along with a “45% reduction in mortality rates.”

Renewing Health is still in its trial period, however, the initial technical results have been published.  A basic summary of the technical aspects of the nine solutions follows:

1. All pilots sites used proprietary solutions,
2. The most widely used standards were protocol and telecommunication standards, but even with some of those standards, there were issues with product development and rol-lout.  This has resulted in some technology system re-design as well increased expenditure on patient education.
3. Moreover, the market has dealt some variables, by either not continuing distribution of a mobile phone model or changing the implementation of a medical device transport protocol.  Additionally, intermittent wireless coverage and/or limited bandwidth for a teleconferencing function have led to design changes or required infrastructure upgrades.
4. The market has a dearth of standards-based products for purchase.  In Europe this is complicated by language requirements (most of the countries have healthcare systems which specify that products be purchased which have markings and documentation in their national language – this is for ease of use as well as cultural preservation goals).
5. Another big issue is system ergonomics with respect to patient cohort.  Mobile phones with small screens and small input interfaces (small mobile phone keyboards) don’t work well with more elderly patients.

This project will be ongoing until 2013 and at the end the results are hoped to strengthen the hypothesis that well designed remote monitoring programs for chronic disease management is as or more effective than care delivered in the traditional manner.  There should also be some interesting results from a technical perspective.  The market is slowly moving towards providing more standards-based products, however, for the purposes of this project, timing did not allow more adoption of those types of products.

So, with all of the activity described above what should healthcare providers do?  I suggest the following:

1. Keep current on the mobile telecommunications arena both in product offerings and regulatory oversight.  With the MDDS and the draft mobile medical apps guidance, the FDA has signaled they will be interested in regulating some aspects of healthcare delivery.   If you as a healthcare provider adopt mHealth solutions, this will increase the complexity of providing and servicing/maintaining healthcare products from the provider.  You control your enterprise, but as the information goes outside the enterprise to the shared infrastructures, you lose that control.  Therefore, you may not be able to guarantee the types of performance or response that may be the norm within your enterprise.  Agreements with the third party infrastructure entities will become paramount to ensure good performance and in the end good relationships with your customers:  the patients and clinicians.  Moreover, in light of the recent FDA guidance, understanding the infrastructure path of your mHealth solutions so that you meet any regulatory burden will become even more important as you embark outside of your enterprise.
2. Consider specifying standards for data and communication across each interface (example: Continua Guidelines, IHE-PCD) in your acquisition documents.  As with traditional medical device connectivity in your enterprise, the more you can decouple the medical device choice from the other parts of a connectivity solution, the more flexibility you have to make decisions based on the quality of the different parts of the system.  In the future, this may avert having to redesign, augment and/or replace the whole system from medical device to electronic medical record application due to a technology refresh of one of the manufacturers in the system.
3. Providers are under a lot of pressure to control healthcare costs in all parts of the world.  As remote monitoring pilot results become more prevalent, it will be expected that providers adopt some of these mobile health solutions.  Timing of your adoption will become very important as this is a fast moving train.  The product cycles for mHealth can be 6 months to 1 year.  This is much faster than your usual IT infrastructure refresh cycle which is already faster than your medical device/technology refresh cycle.  Although many of the traditional medical device companies are migrating to a software based solution and a refresh cycle similar to that in the IT industry, they may not be as ready for the mHealth refresh frequency cycle.  This may slow down in the US and Europe due to more regulatory oversight, however, the development outside those areas of the world does not have as much regulatory oversight, so some of the more interesting products may be developed outside of the geographical areas we’ve become accustomed to in the US and Europe.  If you have a ‘wandering clinician’ or patient, they may be the one who introduces or demands a specific functionality to your enterprise from their wanderings.
4. If your mHealth solution implementation is successful, be prepared to expand.  It is estimated that 80% of healthcare costs are borne by 20% of the population and most of this is due to the management of chronic diseases.    Remember, as with most endeavors, more is demanded of you once you succeed.

So is 2012 the year of mHealth?  Perhaps.  If anything, it will be another exciting year for mobile technology and the convergence of the consumer and healthcare industries.  It will be bumpy, but in the end, it should be better for the consumer who usually also happens to be the patient.

Bridget A. Moorman, CCE, is president of BMoorman Consulting, LLC, providing consulting to healthcare providers, standards promulgation organizations and medical device and information technology companies regarding their medical device integration strategies.  She can be reached via email  or at her website.

The use of the product in question was given as:

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

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

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

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

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

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

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

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

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

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

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

Health IT Risks

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

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

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

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

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

IOM Report Recommendations

The report has several specific recommendations:

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

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

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

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

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

Smart phones have a prior history of  overwhelming cell phone networks, such that in dense environments someone can’t make a phone call because too many other people are watching reality show reruns and bad movies. Now some cellular devices have been looking at switching to Wi-Fi when it is available, as explained here. This leads to the conflict ridden situation of cellular wanting to use Wi-Fi to solve its capacity problems at the same time that Wi-Fi is being over loaded by other devices.   Cellular resistant building structures, which are increasing, also can create a desire to shift to Wi-Fi.

Now think about hospitals. Tablets are surely making inroads here as well, along with smart phones and in house wireless VoIP. Medical devices are also increasingly wireless as has been noted in these pages before here and here. There is also the smart phone wireless app arena (which may or may not be regulated medical devices) as discussed here and here.

Certainly the public access side of a hospital’s wireless network can be limited and segregated. However prioritizing between multiple medical applications is far more challenging both clinically and technically. It must also be remembered of course that lost medical data or lack of clinical telephony can be life threatening, as opposed to merely annoying.

In this demanding arena few wireless medical systems are at least initially tested in a fully functioning environment. Yet there is a vast difference between whether the wireless capability (as well as the wired) is able to function when tested alone, and whether it is capable of functioning around the clock and throughout the year in an actual hospital when static and when roaming. In the latter case when roaming across access points, drop-outs may result in data loss and may not respond well when access is restored. While the link may recover critical information such as which patient is involved may not be available.

In addition it may be possible to add one wireless application today that works in the current environment, but which may not work when the next one or ten or 100 other wireless applications are added later, and perhaps not much later. In this regard vendor assurance, if ever fully believable, cannot be accepted outside the context of the wireless system and devices  currently deployed. (By way of bad analogy, such an assurance are like a car salesperson telling you that with this car you won’t have to worry about highway traffic.)

In this regard the effective hospital application has been summarized as requiring  ”assurance” which includes coverage, signal strength, capacity, and certainty. The “utility” analogy is often used here, i.e. the wireless service  should operate in the background and  be something I don’t ever have to think about, just give me more and more wireless devices and they will all play nicely together. (Those who have been through electrical blackouts and brownouts may have a different perspective than others on the reassurance provided by the utility analogy.)

It is clear that wireless and wired capacity have to both be actively controlled and monitored. Besides being totally logical, this is consistent with IEC 80001 (discussed here) which addresses hospital network risk management. This active control requires a centralized coordinator who has the authority, knowledge and system resources to not allow any new wireless application to be deployed without specific consent based on appropriately rigorous tests. There must also be complete  inventory of all approved wireless users so there is a record of who is using the system. New systems or upgrade designs must also take capacity seriously (see here for example).

Certainly wireless, using Wi-Fi or otherwise, offers advantages in health care, although perhaps not, wireless will need to be limited to those applications that really need it. In any case, capacity is a challenge that is likely to get worse before it gets better.

Pictured above are Philips’ Intelliview Cableless Measurements wireless SpO2 sensors that use the same ISM band frequencies as Wi-Fi. This photo was taken at the Philips booth at HIMSS 2010 with their permission.

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.

We’ve been fortunate to have a number of terrific contributing authors over the years, and some of them have written posts that continue to be popular to this day. On the About This Site page is a long standing open invitation to anyone who wants to climb up on the soap box and spout off contribute to the conversation about medical device connectivity. I’ve also made contributing author offers personally to many folks on both the provider and vendor sides of the table. There are so many people who have incredible knowledge and experience to share. And most of these people don’t have the time or inclination to create their own blog. Now you have an outlet.

Increasingly companies are adopting social media policies that establish ground rules for employees posting to blogs, Twitter, Facebook, etc. Besides benefiting your employer, contributing posts also benefits the writer personally with increased awareness and respect among your peers. Contributors also get an author’s bio like this one for current contributor, William Hyman:

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.

Writers that want to remain anonymous can do so, to a degree. You can be anonymous like the blogger Tim at HIStalk. He doesn’t disclose his identity on his site, but he is not legally anonymous. This means that you can chose to not disclose who you are (or your employer), but if I’m legally compelled to disclose your identity I will. Some employers will appreciate this kind of anonymity because there’s little chance the writer’s opinions will be associated with the employer. Of course many employers, especially the smart ones, will want that employee-employer association to be known so that all the insight and intelligence the contributor demonstrates in their posts will rub off on them!

In the connectivity segment of the market, there are a lot of new entrants and many established companies flying under the radar of broad market awareness. Contributing blog posts about your experience or perspective (nothing too commercial please) is a great way to establish credibility and get the word out. The most effective use of blogging is engaging in a long term conversation with your readers. Most of my consulting business comes from this blog, in addition to the usual word of mouth and repeat projects. You put your content out in the blog, and readers come back with questions and requests for help with problems, advice, referrals to fill new positions, you name it. And I can’t tell you how rewarding it is to meet people at customer sites or events who are readers of this blog.

Unlike a magazine article, press release or white paper, contributing to a blog is typically not a one shot deal. A series of blog posts that address a body of topics or frames an issue gets read when it’s published – and after that – via search engine queries (that’s why it’s important to identify and use the right key words in your blog posts). Ideally, potential contributors will look at this as an extended conversation, or at least a series of posts that will span several months, if not indefinitely. Individual contributions are welcome, but they will have to be particularly thought provoking, entertaining and/or informative.

Why contribute posts to this site? Well, the site gets about 300 unique visits per day (less on weekends) and has  hundreds of subscribers to the RSS feed (the funny orange square icon on the right). Readership is evenly split between providers and manufacturers. As a contributor you will get access to the sites statistics where you can see how many times your post is accessed and by who (or at least their IP address or domain name).

So, if you’re interested in contributing, let me know. And if you’re a reader, here’s your chance to leave some feedback – what would you like to read more or less of on this site?

As an aside, if you’re interested in the blogs and news sites that I read, keep an eye on the Connectologist’s Shared Items box in the right hand bar. This is a list of shared items from my Google Reader. If you’ve got a blog or news site to suggest to me or your fellow readers, leave it in a comment to this post.

[Flickr photo of Selma by Netzanette]

The report in this instance came from Jay Radcliffe who hacked his own insulin delivery equipment. In this instance the hacking avenue was the wireless remote that was part of the device. Perhaps the idea that a wireless remote could be emulated is even at the ultra low end of surprise.  More generally, the multiple discussions of this report (e.g. here and here) have suggested that the technology being used by at least some medical device manufacturers does not offer an adequate array of security safeguards. Or the manufacturers haven’t fully utilized what is available in terms of alternate hardware, or they havn’t fully utilized the security features that were available even in the hardware that they were using.

Not surprisingly medical device manufacturers have downplayed the risks of hacking. The manufacturer of the pump in question, Medtronic, responded through a diabetes oriented web site, but apparently not through an actual press release of its own. The responses included that Medtronic does take device security seriously (would you expect them to say otherwise?), and that no real-life events have ever reported. Of course a problem with the later is that stealth hacking, as opposed to announced hacking, could cause harm while going unreported. This is to not say they have, but only to note that “reported” is a limiting case.

Medtronic is quoted further as saying “Our job is to incorporate information security measures into our designs, vigilantly monitor potential threats and to always be proactively finding ways to make our devices more secure for you. That is what we have done and what we will continue to do.”

A curious post in response to this expected response from Medtronic was “Security violations are caused by sloppy implementation. The systems themselves are very secure.”  I’m not sure how much better that is supposed to make us feel. Equally curious was that this response referenced RSA as a security authority, with other posters then pointing out that RSA was itself hacked.

Hypothetically (that means I made up the following) assorted glitches and could-not-duplicate service events could be the result of hacking, i.e. if the hacker hacked, and then stopped hacking, whatever the effect of the hacking was could well stop also, and therefore be un-findable. Which reminds me of a hospital wireless interference anecdote I heard about bursts of interference, almost always during the night, and almost always for one or two minutes. The culprit was an old leaky microwave being used in quick mode. And why only at night? Because the cafeteria was closed then and therefore the microwave was a primary food resource.

The bottom line is that security is an ongoing issue that must be rigorously addressed by manufacturers, and in turn by the FDA who has to at least ask the what-have-you-done-about-connectivity-security, and insist on a firm answer. Further, I will ask the question that I asked about the challenges of hospital networking at an AAMI session last June in San Antonio. My question was, “Is the problem getting easier or harder?” The answer was a laugh.

[Thumbnail photo above (used with permission) shows the various sites used to inject insulin over a period of time - one month if I recall correctly. In the lower right corner is the Medtronic insulin pump dangling from a tube. - Ed.]

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.

Since last year’s conference so much has come to pass:

• The FDA published their final rule for Medical Device Data Systems, and signaled their intent to regulate health care providers who develop their own MDDS solutions.
• The FDA also published the long anticipated draft guidance on mobile apps, clarifying the boundaries around what is and is not regulated medical device software, and laying out a bit of the FDA’s enforcement strategy.
• The transition of health care technology from the hospital to home health has also received some attention from the National Research Council in their report, Health Care Comes Home: The Human Factors.
• An FDA Workshop on Medical Device Interoperability was held a few months after last year’s Medical Device Connectivity conference. This event was just part of an effort to develop a regulatory framework tailored to plug and play medical device interoperability. The group behind this event has published a number of important papers this year on interoperability, risk management and other topics.
• Founded in July of 2010, the mHealth Regulatory Coalition has  contributed greatly to advancing a different set of regulatory policies for mobile apps and also published important papers this year on the optimal regulatory framework for mHealth medical devices.

On the standards front, IEC 80001 will mark its first year as a formal standard this September. And the Integrated Clinical Environment (ICE) standard (ASTM F2761-2009) has been advanced by a number of grants that will result in the creation of solutions that implement portions of the ICE standard. Both ICE and ongoing efforts by the IHE PCD have seen continued adoption of ISO/IEEE 11072.

This year’s conference will explore all of these topics, along with a number of case studies.

The Medical Device Connectivity conference remains the sole industry event dedicated to workflow automation through the integration of medical devices and information systems. And there is no other venue where clinicians, clinical engineers, medical device manufacturers and connectivity suppliers can all meet, learn and exchange ideas.

Thanks in advance to all of this year’s  speakers for their participation and support of the advancement of connectivity, and this conference. Both their expertise and efforts to share their connectivity experience will create an exceptional conference experience for all attendees.

Here are some of the conference agenda highlights:

• As principal investigator for the $10 million Quantum Grant for the “Development of a Prototype Healthcare Intranet for Improved Health Outcomes,” Julian Goldman MD will report on progress in patient centric care.
• With connectivity, medical devices are becoming information appliances. As medical devices become more connected and smarter, where will it all end? Glen Allmendinger, President of Harbor Research will answer those questions in his presentation on medical devices and the Internet of things.
• After Glen’s exploration of the broader industry trends impacting medical devices, yours truly will describe how medical devices themselves are evolving, and look at some likely outcomes.
• Few people have impacted medical device connectivity as much as the inventor of the “smart” infusion pump, Nat Sims MD. Since the birth of the smart pump, Nat has been quite busy and you will learn a bit of what he’s been up to when he presents a survey of 5 different connectivity applications implemented at Partners Healthcare.
• Medical device networking – both wired and wireless – continues to be a challenge for health care providers. As an independent nonprofit dedicated to the mission of lowering health care costs by accelerating the availability of wireless health, the West Wireless Health Institute has initiated a program to improve wireless networking for medical devices in hospitals. Ed Cantwell, will present his institute’s proposed solution to the vexing problem of harmonizing enterprise networks to wireless medical devices.
• The ECRI Institute has taken a leadership position on health care technology challenges for over 40 years. Jim Keller, leader of ECRI’s medical device evaluation program will present the Institute’s perspective on the challenges and potential solutions medical device connectivity presents to health care providers.
• The FDA Workshop on Medical Device Interoperability mentioned above, is one of the activities of the AAMI HIT and Interoperability Ad-Hoc Committee. Steering committee member, Michael Robking (and Principal of Anakena Solutions) will provide an update on the committees activities and how they may impact the future regulation of interoperable medical devices.
• The mHealth Regulatory Coalition, also mentioned above, is tackling a different set of interoperability regulatory challenges. Dane Stout, Director Connected Health and Biomedical Communication Practice, The Anson Group, is also a leader in the coalition. Dane will provide an update on the coalition’s efforts to assist the FDA in the development of draft guidance for mHealth products.

In addition to the above, there will be three tracks of presentations focused on topics for health care providers, medical device manufacturers and regulatory issues. These represent more than 16 additional presentations.

After the conference, attendees have the option to sign up for one of 3 post-conference workshops. These in depth 4 hour workshops provide meaty “deep dives” into each of their subjects. All workshop instructors are industry leaders.

• Vendor agnostic alarm design and performance metrics is the title of workshop from Kourtney Govro, CEO of Sphere3 Consulting. Kourtney will show how alerts and alarms from nurse call systems can be transformed into leading indicators of care, reflecting a hospital’s patient satisfaction levels and financial success. This workshop will describe how patient’s needs can be met more effectively by looking at numbers that are produced by technology used every day at the hospital.
• Distributed antenna systems in hospitals: best practices, is a topic that continues to vex health care providers. Between legal mandates to support public safety frequencies with the hospital, and dealing with integrating networked medical device systems on enterprise networks, few hospitals have resolved their networking issues. Distributed antenna systems are often mentioned as a potential solution to all or some of these problems. In this workshop, David Hoglund, Principal of Integra Systems will instruct attendees on what technologies are available, what works and what doesn’t, and how best to plan for, deploy and support distributed antenna systems in your enterprise.
• A practical design workshop for creating connected medical devices and gateways based on open source, and open architecture components is the follow up to last year’s workshop on a similar topic. Presented by Shahid Shah, CEO of Netspective will delve into medical device product architectures optimized for connectivity applications. He will show how these architectures, based on open source and open architecture components can result in reliable and feature rich devices with a significantly lower time-to-market and cost of goods sold.

Be sure to check TCBI’s web site for this conference for updates and the latest agenda.

David suggests that FDA regulation will stifle mobile app innovation, and observes that brand-name phone manufacturers are in a better position to shoulder FDA regulations than startups.  He further wonders why an App Store that takes a 30% cut of app revenue does not appear to draw any regulatory attention from FDA.

Nathan agrees that over-regulation could stifle innovation and suggests that the regulatory burden should vary based on the intended user. Nathan implies, I think, that apps for health care professionals should face greater regulatory scrutiny than apps for use by patients. He also laments that FDA has not designated specific standards that would facilitate cross-vendor interoperability in the mHealth ecosystem.

I don’t mean to pick on David and Nathan, it’s just that they raise some excellent points that I’ve seen repeatedly in other forms. The problem with many people’s constructive criticism of FDA’s draft guidance is that they are criticizing or suggesting things that lie outside FDA’s legal framework. Criticism that ignores this legal framework really barking up the wrong tree.

Suggestions that go beyond the FDA’s legal framework are not possible without Congress passing major new legislation. Unless the law empowering FDA changes, we have to consider mobile apps within the existing regulatory framework. What you’re seeing in the draft guidance is an expression of the FDA’s current framework applied to mobile apps.

The objective of this post is not to interpret the current draft guidance on mobile apps, but to describe some basic concepts of FDA regulations to better understand the perceived limitations or choices made by FDA in their draft guidance, and to enable more constructive criticism and suggestions that are consistent with FDA’s existing legal framework. FDA regulatory stuff is rather complicated, so please forgive me if I oversimplify some things in an effort to provide some basic explanations.

Limits on FDA’s Ability to Regulate

Legally, the FDA can’t distinguish between small business innovators and large market incumbents. Nor can they take different regulatory approaches solely based on the user of the medical device – at least in the way that it seems to be implied. The targets of FDA’s regulatory power, and how that power is applied are determined by different factors.

A key regulatory concept of the legal foundation for FDA regulations is that the FDA can only regulate manufacturers. An important corollary is that only one manufacturer may be regulated for a given medical device system, regardless of what (or how many) off-the-shelf technologies are incorporated in the overall medical device system.

Another important part of this regulatory framework is that manufacturers are regulated based on two primary things: the claims they make about their product, and the product’s inherent functionality.

Probably the most fundamental concept that underlies almost everything FDA does is patient safety or risk. The greater perceived risk, the higher the regulatory burden. As reinforced in this draft guidance, medical devices are divided into three classes based on risk, with the lowest risk being Class I and the highest being Class III.

Another important concept about  FDA regulations is that FDA ensures safe and effective medical devices by requiring manufacturers to follow a quality system process, rather than testing and certifying a particular product, standard or piece of technology. The FAA tests and certifies airframes, the FDA ensures manufacturers follow a quality system. The intent here is to promote innovation by defining the basic processes followed  by the manufacturer to create, manufacture, market and service the resulting device.

By freeing the manufacturer to chose what they think is the best way to implement a design (as long as they follow a quality system process) is supposed to encourage innovation. In many situations, I suppose this approach does promote innovation. Yet as automation transforms medical devices into information appliances, the lack of an agreed upon technical foundation (such as interoperability standards) stifles a different kind of innovation.

Applying FDA’s Framework to Mobile Apps

Who Gets Regulated

Whoever designs and markets (directly or indirectly) the mobile health medical device – be they a startup, a carrier or a mobile phone manufacturer – is the entity the FDA will regulate. In the case of a startup that bases their medical device on say the iPhone, how would FDA go about regulating Apple (solely or in conjunction with the startup)? Also, while FDA only regulates manufacturers, health care providers can meet the legal definition of a manufacturer if they create a medical device, or modify an existing medical device, and use it in clinical practice.

FDA regulations (the Quality System regulation) impose a basic quality system on the design, manufacture, sales and service of a medical device. In the LinkedIn discussion example, the manufacturer (the startup) does the design, marketing (defines the claims and intended use) and provides any service and support. Apple is simply an indirect distribution channel. Apple makes no additional or different claims for the product, nor do they provide any service other than distribution of the software that runs on their phone.

If the FDA were to regulate Apple, how would this improve the safety and effectiveness of the medical device? I can’t see how it would. I suspect that if FDA were to attempt to regulate Apple for their sale of medical device applications, Apple would kick all medical device apps out of the App Store – definitely impacting innovation.

The Intended User

The user of the medical device is an important consideration for FDA. When the user is a clinician, with all that implied knowledge and expertise, certain assumptions are often made by the manufacturer – and accepted by FDA – that in the event of a problem (e.g., a limitation of the product, a deterioration in the patient’s condition or an adverse event), the user has the wherewithal to “do the right thing,” rather than continue blindly down the path that may be indicated by the medical device.

When the user of a medical device is a patient of family member – what the FDA calls a “lay person” – the user lacks the broad and deep knowledge that a clinician brings to the use of a medical device. Thus the device must have a better user interface and a safer design to ensure an outcome on par with that obtained by a clinician user. This is not a new issue for FDA.

The past several years have seen a number of hospital products pushed for use in home health. From this experience, the industry and FDA have learned the lessons described above. Consequently, FDA considers medical devices designed for use by lay people to generally be higher risk than those whose intended user is a clinician.

The result is that FDA will likely bring a higher level scrutiny to devices intended for use by lay people, compared to devices intended for use by professionals. The result will not be a lowering of the regulatory bar for products targeting patients, but a higher regulatory hurdle.

Industry Standards Adoption

Many of the comments about the FDA’s draft rule on mobile apps lament the absence of industry standards to facilitate cross-vendor interoperability. The implied or explicit solution being that the FDA mandate a specific standard. While there is a great need for a minimal level of cross vendor interoperability to foster market adoption, the FDA has no legal foundation for placing a specific standard on industry. In short, great idea, but a complete waste of time. Instead, one should look to see how this problem has been solved in other industries.

There are plenty of standards bouncing around, some, like 11073 for more than 30 years. The challenge is picking a standard(s), getting a critical mass of vendors to adopt said standard(s), and providing a meaningful level of test and certification for compliance. Most any health care market can be divided between acute care (i.e., hospitals where the patient’s too sick to be walking araound) and ambulatory care (i.e., home health, chronic disease management, physician offices and clinics – where the patient’s sick but is still ambulatory).

Most mobile apps target ambulatory care markets. There is a test and certification alliance, the Continua Health Alliance, that exists for selecting standards and providing the necessary test and certification for the ambulatory market. There are admittedly several big holes in FDA’s regulatory famework when one considers mobile app products (that are all outside the scope of this blog post). While not a standards oriented group, the mHealth Regulatory Coalition, that is working to address shortcomings in FDA’s current regualtory framework for mobile apps. Be sure to check them out.

For acute care, there are a number of industry standard setting initiatives. The oldest is the IHE PCD domain. This group has been working since 2005 on medical device connectivity and interoperability. This test and certification group is mainly held back by the absence of a standard that’s been adopted by medical device manufacturers, and the resulting glacial pace of adoption – but they are making progress. Another hotbed of standards work comes from the Medical Device Plug and Play Interoperability Program at CIMIT and Partners Healthcare. They’re working on the Integrated Clinical Environment standard, MD Fire connectivity purchase contracting language and also working with FDA on dealing with developing a more effective interoperability regulatory framework.

International Markets and Quality Systems

Before I posted this, Dayle Kern added to the LinkedIn discussion asking, “What about mobile apps for developing countries?” My first thought is that as a market, mobile apps is still very much in the pilot stage. While there’s a perception that adoption is much greater outside the U.S. (especially in the third world), the reality is that there’s just a lot of pilots being run in other countries in addition to those in the U.S. My next thought is that while the regulatory burden may be lower outside the U.S. (and especially in the third world), why shouldn’t the patients in those countries get a product that’s as safe and effective as the ones intended for U.S. or European users?

I have clients doing clinical trials outside the U.S., and who launch products outside the U.S. first. The reasons behind those decisions have everything to do with time to market and costs – much of which are determined by relative regulatory burdens here and in other countries. But, without exception, they’re following appropriate quality systems to ensure a safe and effective product. The costs they’re saving are not on the design side, but on the regulatory side. And consequently, their products are as safe and effective as they would be if the U.S. was where they were doing trials or launching their product.

Finally, in a world where it’s almost impossible to buy a hot water heater or air conditioner from a manufacturer who is not ISO9001 certified, it’s almost as impossible to buy an healthcare IT software application from a vendor following the same or similar basic quality system. From their resistance to adopt quality systems, one would almost think that vendors in health care consider quality and safety to be less important than do companies in the HVAC business.

Manufacturers in many other industries don’t seem to have a problem innovating or competing while broadly adopting quality systems – on a voluntary basis, I might add. Please explain to me how a similar quality system for medical devices – regulated or otherwise – is an unreasonable burden?

On July 19, 2011 the FDA announced its proposed official action in this regard, including defining “mobile medical applications”  that are the subject of this action. (I will use the acronym MMA, although the FDA did not.) . This includes a new FDA web page for mobile apps (here), with links to a new Draft Guidance, information for consumers, and a press release. This action by the FDA has a parallel to the recent final rule on Medical Device Data Systems (MDDS), discussed by Tim here, which also addressed what is it, what is it not, and how that which is will be regulated.

The Draft Guidance, dated July 21, 2011, defines an MMA as a ”software application that can be executed (run) on a mobile platform, or a web-based software application that is tailored to a mobile platform but is executed on a server”, where that software already meets the general definition of a medical device as found in 210(h)of the FD&C act. In brief, the relevant part of this definition is that a medical device is used in the diagnosis, treatment, cure, mitigation or prevention of disease.  If there was any prior doubt, this again establishes that software that is intended to do any of those things is a medical device, even in this case  if downloaded from the app store, and run on a smart phone. Intent here can  be a key issue in that general purpose software that might be used for a medical application is in general not regulated as a medical device, unless the software manufacturer promotes such applications. This guidance does not specifically address wireless safety considerations, classification and submission requirements related to clinical decision support software (once called expert systems), or the direct application of quality systems to software, all challenging issues.

That software can be a regulated medical device has been asserted by the FDA on a number of occasions, and they note in this guidance multiple examples of medical device software that has already been defined and classified. The FDA’s justification for doing this is also familiar; besides its congressional mandate, the FDA notes that “As is the case with traditional medical devices, mobile medical apps can pose potential risks to public health”. However the FDA makes clear here that the mobile device itself (the mobile platform) is not considered to be a medical device, even if it is running an MMA – unless the seller of the platform makes a corresponding claim for its medical use.

Among all mobile apps, the FDA in this guidance has defined the MMA subset that is the subject of the guidance. However we are reminded that other mobile apps may still be medical devices, and therefore potentially subject to regulation, but under the FDA’s “enforcement  discretion” they will not be actively regulated at this time. However manufacturers of even these devices are invited to register and list with the FDA, and it is suggested that they follow the FDA’s Quality Systems Regulations, even if they don’t register at this time. Enforcement discretion is one of my favorite regulatory categories because that discretion can end at any time, and that which was previously not being actively regulated can easily become actively regulated. A no doubt bad automotive analogy here is to the long alleged grace speed overage before being subject to a speeding ticket.  However true or not true this is, a ticket can still be issued for speeds over the limit but under the rumored true limit.

The guidance goes on to define the scope of regulated apps (MMA) , and who is a MMA manufacturer. I will not repeat this information here, except to note that the download store distributors, like the platform makers,  are defined as not being manufacturers. Further, it is the creator of the software concept and its specifications, not the code writer  who is on the regulatory hook. Good news for programmers who aren’t the originator of the device. Time here for some perhaps artificial humility in the form of, “Hey, I just wrote the code to make the software do what they said it should do.” Also of particular interest to some, devices that create alarms are expressly addressed as being included. This is consistent with the FDA’s attention to alarm issues, which will be the subject of a forthcoming multi-sponsored Alarms Summit.

The appropriate FDA classification for MMAs will vary depending on the actual intended use. Thus, there is no reclassification here as there was in the MDDS final rule.

This FDA action can be viewed as one of several efforts in which the FDA must address rapidly evolving technologies, and systems of technologies, that in some cases have been deployed ahead of the FDA’s ability to deal with them under existing regulatory frameworks. Or as perhaps in this case, where developers have charged ahead with product introductions with disregard for medical device regulatory requirements, either from not knowing these regulations, or intentionally ignoring them.

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.