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.

Here’s a query I received this week:

I have been reading about connectivity of medical devices, of which I know nothing, because I am a teacher and am having signal issues, while at work, with my wireless Omnipod Insulin Pump. The alarm sounds and it stops delivering insulin.  The support team at Insulet Corp. says that there is some sort of “fluck” going on.  This answer does not satisfy me.  My classroom has been known to have what our tech people call, “dead zones.”  If you don’t mind, can you, or others, offer some insight into this situation?  Thanks.  My doctor is at Tufts in Boston.  He’s just great.

Here’s my reply:

It is not possible to diagnose the root cause of your pump problem from your description. Also, to my knowledge, “fluck” is not a technical term, and I have no idea to what it refers. It is possible that the radio link between your sensor and the pump is hampering the pumps operation. It is also possible that the problem is one that is inherent in the pump itself (e.g., a software bug or component failure), or the sensor that detects your glucose level.

The manufacturer is best able to properly diagnose and fix the problem – and it is their responsibility to do so. If the manufacturer is not responsive, you can tell them that you will file a complaint with FDA – and you should indeed do that.

Typically the term “dead zone” refers to a lack of wireless signal coverage for a given area. This term can be applied to both Wi-Fi coverage in a building, or cell phone coverage anywhere. Since the radio link is between your sensor and pump, we’re not dealing with a lack of radio coverage – unless there’s a problem with the radios in either the sensor, pump or both.

The term, “dead zone” also implies an environmental condition within your classroom. It is possible that there is a source of radio frequency interference found in your classroom that is interfering with the radio link between your sensor and pump. If the interference is sufficiently strong, it could interfere with the operation of the senor and pump themselves.

Common causes of interference are defective florescent light ballasts, the failing brushes in electrical motors (paper shredders, blow dryers, elevators, etc.), and microwaves with defective seals (where the microwave energy leaks from the enclosure causing interference). The typical approach to determining if there is a problem with interference uses an RF spectrometer like these. As you can see, they’re not inexpensive and require some technical expertise to use properly.

The manufacturer is likely to want to do everything they can to rule out other causes before considering interference. From the manufacturer’s perspective it is not likely economically justified to send an engineer to a patient’s site to test for interference. In the event interference is found, determining the source and mitigating the interference can also be quite time consuming and expensive. If the manufacturer can rule out any other cause than interference, you may be able to try other room locations and if the problem goes away, ask your school to put you in a different room next year.

In any event, it is the manufacturer’s responsibility to resolve the situation to your and your physicians satisfaction within the responsibilities described in the product warranty.

While you’re happy with your doctor, he has considerably more leverage with the medical device manufacturer as someone who prescribes this pump to many patients than you as an individual patient. If you haven’t already, go see him and ask if other patients have had similar complaints. Express your frustration with the lack of suitable a outcome from the manufacturer and ask him to go to bat for you with the manufacturer. He too can use the same link above to lodge a complaint with FDA.

This response represents just the tip of the iceberg as far as probable causes, potential solutions and outcomes. I guess worst case, the patient will have to return the pump and go back to a conventional glucometer and injections.

What would your advice be to this patient?

If you’re a consumer with questions related to something you’ve read on this site, please do the following.

• If your comment is really a comment about a blog post, feel free to leave a comment.
• If you have questions or comments that don’t related directly to a blog post, then please use the form on the Contact page.
• Be sure to provide sufficient information and context so that I can provide a meaningful response.
• Remember that nothing you read here represents medical or legal advice on my part. I’m just an interested industry guy who knows some things and isn’t shy about spouting off.

[Photo used with permission.]

What is a Medical Device?

Let’s start with the first category; there is an astounding amount of misinformation and just plain wrong-headedness on the part of many vendors (and providers) who are outside the ranks of traditional medical device manufacturers. The first issue we need to address is the question, “What is a medical device?” Here’s the legal definition of a medical device, courtesy of FDA:

A device is:

• an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part, or accessory which is:
  • recognized in the official National Formulary, or the United States Pharmacopoeia, or any supplement to them,
  • intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals, or
  • intended to affect the structure or any function of the body of man or other animals, and which does not achieve any of it’s primary intended purposes through chemical action within or on the body of man or other animals and which is not dependent upon being metabolized for the achievement of any of its primary intended purposes.

If you look up the word contrivance, you’ll see that almost anything can be a medical device:  tongue depressor, superglue, software, even services – let your imagination run free. If it quacks like a duck – is intended for use in the diagnosis, cure, mitigation, treatment, or prevention of disease (or other health related conditions like injury), it is a duck. Calling it a chicken or even a turkey does not change a regulatory agency’s perception of the quacking product’s “duckness.”

There is also a new classification of medical device call a Medical Device Data System, or MDDS. An MDDS acquires data from one or more medical devices, stores it, can transform it per written specifications (e.g., change units of measurements or labels of data elements), display the data and make the data available to other applications. Thus if a product meets the definition of an MDDS it is a duck, and cannot claim to be something else because all their doing is automated record keeping.

Automated record keeping is generally held by regulators to not be a medical device – but the first step of acquiring data from the medical device does qualify as a medical device. The only way to acquire medical device data without being categorized as an MDDS is to get the data from another application that is an MDDS, or have users hand enter the data into your application.

I’ve heard the argument that, “we’re only storing the data, and that’s not a medical device.” This can be true, if what you’re doing with the data (besides storing it) does not meet the definition of a medical device, and if you’re not acquiring the data directly from the medical device (because that’s an MDDS).

The Regulatory Significance of Marketing Claims

Fierce Mobile Healthcare captured a great quote in a story the other day by Bakul Patel, a policy advisor in CDRH at FDA about the potential for smart phone app regulation,

Companies that make health claims in their marketing, or actually perform clinical operations on their mobile devices, may be the first targets.

So we’ve already dealt with the second part of Patel’s statement, about whether the product preforms clinical operations and thus meets the definition of a medical device. The first part, about marketing claims is next important regulatory concept. Claims are also referred to as “labeling” by FDA, and include a product’s positioning statement, brochures, advertisements, white papers, and what sales reps tell customers verbally, in email or PowerPoint presentations.

You can’t take a duck and call it a chicken in your marketing claims if its really a duck. Likewise, if there’s a likelihood customers will use it as a duck after purchase, regulators will treat it as a duck. For example, say you develop software to view DICOM images (xrays, CT scans, MRIs, maybe some sexy 3D reconstructions) on the iPhone and iPad – but you tell physicians they can’t use your product to render an actual diagnosis. What then are they to use the app for, a novelty? A similar product was identified as a duck by FDA a couple years ago, and just recently received FDA clearance for sale by the vendor.

Another important thing regarding claims about medical devices is that regulatory agencies will treat your product like a regulated medical device if you make claims that your product is a medical device. For example, Apple came perilously close to claiming the iPhone was a medical device during their iOS 3.0 intro event. Since then, Apple’s toned down their aggressive marketing of the iPhone (and iPad) as medical devices, though they still show examples of medical device applications in commercials, at events and on their web site. In another example, a few years ago Cisco produced a brochure that showed a patient monitor alarm message and associated waveform displayed on a Cisco VoIP handset. This quickly drew a visit by FDA and a “request” to withdraw the brochure, which they did.

The bottom line is whether your product is a medical device or not, if you make claims that give the impression that it is a medical device, you are likely to find yourself regulated – or claw back your claims.

Regulation of Off-the-Shelf Technologies

A similar topic that is rife with confusion is whether generic products like smartphones, wireless carriers or network equipment will be regulated. Currently available smartphones, by themselves, do not meet the definition of a medical device. There are three ways the smartphone itself could become regulated:

1. The smartphone manufacturer could make medical device claims – even though the product does not meet the definition of a medical device
2. The smartphone manufacturer could add features, say an interface to acquire data from sensors like glucometers, implanted pacemakers or some other medical device
3. A third party could develop a product, notably software that runs on the smartphone, and perhaps other components, that all together meet the definition of a medical device

Item one above relates to the Apple and Cisco examples used earlier. If your product is not a duck, don’t make claims that it is and you need not have to deal with FDA and their international brotherhood of regulators.

The second scenario above is really just as straightforward. If HCI built an Android smartphone with an interface for glucometers, and then promoted the product to diabetics like, “Hey, buy my smartphone to acquire data from your glucometer to better manage your diabetes,” they’ve transformed their product into a medical device. Another similar situation would be where the smartphone manufacturer creates a port on their phone to attach a blood pressure cuff, which they sell as an accessory to their smartphone. A generic equipment manufacturer who does something like this will likely see someone from FDA in the very near future.

Now what about a generic interface like Bluetooth? What if a third party uses that Bluetooth interface already built into the smartphone to connect a glucometer to help diabetics manage their disease? Then the third party becomes the regulated entity, and the smartphone is just another off-the-shelf component that goes into the overall medical device. In this case, the medical device is regulated – through the third party/manufacturer – and the smartphone maker never hears from FDA. From this example you see that which manufacturer ends up getting regulated is what’s important, and not the device itself.

Bottom line, general purpose smartphones, tablets, personal computers, wireless carrier’s networks, LAN equipment – none of these manufacturers will be regulated, with one exception. If the general purpose equipment manufacturer makes medical device claims, the general purpose equipment manufacturer will be regulated. If a third party uses general purpose equipment as off-the-shelf technology in their medical device, the third party gets regulated and not the general purpose equipment manufacturer. (Of course there’s a third possibility where the general purpose manufacturer adds specific features to their product transforming it into a medical device – which we’ve addressed above.)

So when people ask, “Is the FDA is going to regulate smartphones?” they are asking the wrong question. If the smartphones are components in a medical device, or transformed into a medical device themselves, the manufacturer of the medical device will be regulated. It is true that indirectly smartphones are regulated by FDA, but such a statement really distorts what’s actually going on.

Regulatory Agency Actions

Regulators have what’s called, “discretion,” whereby they decide if they want to ignore something they legally could pursue or not. This can be divided into regulatory discretion, where they chose not to regulate, and enforcement discretion where they do regulate.

It is common for regulators to observe the development of new medical device markets without enforcing regulations, provided there is no undue risk to patient safety. This action (or inaction) is called regulatory discretion. At some point, when the market has matured sufficiently, and/or FDA’s understanding of the new market matures, or risk to patient safety becomes to big to ignore, the regulator shifts from regulatory discretion to enforcement discretion. Regulators may signal this shift through a reclassification of the device category (as FDA recently did with MDDS), by publishing a guidance document (there’s one in the works by FDA on smartphones), or they may simply start enforcing regulations.

Regulatory discretion in no way limits a regulator’s future actions. Just because they chose to look the other way before doesn’t mean they can’t change their minds – at any time – and later pursue enforcement. This is true in relationship to past inaction and future regulatory actions, and the retroactive enforcement of actions that previously received regulator discretion.

Regulators rarely, if ever, publicly announce a policy of regulatory discretion regarding a medical device market or product. They only sometimes signal a shift to regulatory discretion. Nor do regulators clearly state that, “if you do x, we will not pursue enforcement, but if you do y we will pursue enforcement.” It is possible to infer such distinctions retroactively, but with nothing on the record either way this becomes an exercise in supposition.

What types of products meet the legal definition of a medical device is pretty black and white; what makes things confusing is all the products that meet the definition that aren’t actively regulated due to discretion. All of this discretion creates a lot of uncertainty for manufacturers. This uncertainty requires management to make judgement calls about how much regulatory risk they want to assume with a given product in a given market. Unlike mature markets like hospital patient monitors, emerging markets like smartphone apps have a lot of uncertainty.

Probably the biggest risks are having to incur unanticipated costs and time-to-market to become a regulated manufacturer and, if necessary, receive clearance from the regulatory agency to sell the product. The manufacturer of the smartphone app for viewing DICOM images mentioned above was delayed 2 years in getting their product to market, and they had to bear significant costs to bring company operations in to regulatory compliance and generate clinical data to demonstrate their products safety and effectiveness. If they’d had a regulatory strategy from the get-go, their costs would have been substantially less (but still more than an equivalent product that’s not a medical device) and probably gotten to market sooner. Eliminating regulatory uncertainty is all about getting informed and planing, rather than having to react to something you’d hoped to avoid.

What is a Manufacturer to Do?

The first thing is to pay attention! Actively track regulators to learn about any enforcement actions against vendors or products similar to yours. Seek access to informal or back channel communications with regulators. You can do this by attending meetings attended by regulators and building personal relationships with regulators through standards work and other means. If your company lacks the resources to do these things directly, engage with someone who can do them for you. Next, continuously apply your awareness of the regulatory environment around your product to your specific situation.

If you manufacture general purpose products or services (e.g., smart phones, cellular carrier networks, Ethernet or Wi-Fi equipment) and you know your products are being used in medical devices, you should probably have or develop a regulatory strategy to ensure you maintain your unregulated status. If you’re a general purpose manufacturer or service provider, know your stuff is used in medical devices, and want to encourage the medical device market for your products, you definitely need a regulatory strategy. Encouraging the use of your products or services in medical devices can cause you to become regulated, if you don’t do things in the right way.

If you are using off-the-shelf components and creating your own stuff (writing software, creating services or developing specialized hardware) for health care related activities, you too should have a regulatory strategy. If your product does not meet the definition of a medical device, you need a strategy that clearly demarcates what makes your product not a medical device, and the actions you will take to maintain those distinctions.

Most likely your product does meet the definition of a medical device, and in many nascent markets – like smartphone apps – enforcement discretion is not being pursued by regulators. In that case you need a more complex strategy. Your strategy should include:

• An attempt to discern what, if any, actions will cause regulatory discretion to shift to enforcement, and if or how to avoid those actions
• Judge the maturity of your market and any indicators (especially actions or comments by regulators) as to when regulators might shift from regulatory discretion to enforcement
• Evaluate the impact of being regulated on both your operations and external market factors like potential competitive advantage – it is common for some companies to voluntarily be regulated before the actual shift to enforcement discretion
• Develop your plan for when and how to become regulated

Like any evolving situation, the biggest challenge comes from not knowing what you don’t know. Hope is not a plan, and the worst thing you can do is nothing. Start turning over those rocks – you may find a few icky things, but there’s no monsters.

Related posts:

Charting Your Regulatory Course

Final MDDS Rule Signals FDA Shift to Enforcement

Comments on FDA Wireless Medical Device Guidance

Facing FDA Regulations for the First Time

The photo accompanying this post was taken at the 2010 mHealth Summit – this is definitely a medical device!

You see, I’m often asked by manufacturers about alternatives to Wi-Fi for wireless medical devices. And I’ve done a number of wireless technology surveys for manufacturers, looking for attractive alternatives. There are no attractive alternatives, at least for most medical device applications at this point in time.

Before we dive into this sordid tale of passion and betrayal, let’s frame the discussion. The wireless application I’m referring to is the connection between a portable or mobile medical device and the enterprise wired network. While the examples in this post come from hospitals, there is much here that is applicable to ambulatory settings. Applications that are not considered are cable replacement applications (Bluetooth or wireless USB) or wireless sensors in body area networks (BANs) that are, by their nature, low power and short range, are a different animal.

UPDATE: This post is intended to focus solely on networking issues around medical device connectivity. Issues about requirements, use cases, workflow or any issues dealing with medical device or application layer features are outside the scope of this post.

Love

Wi-Fi, how do we love thee? Let’s count the ways…

Off the Shelf Components

When contemplating the beauty that is Wi-Fi, where does the besotted medical device manufacturer start? Many manufacturers fist fall in love with Wi-Fi as an off the shelf (OTS) solution to a big problem. Those three magical words – off the shelf – can significantly reduce time-to-market and product development costs, and in this respect, Wi-Fi really delivers.

Imagine what a bleak and barren world it would be without Wi-Fi. A world where manufacturers have to design their own radios to wirelessly enable their medical devices. It can easily cost a few to several million dollars and three or four years to build a component radio around an existing radio chip from Freescale, Broadcom or some other supplier. GE got their WMTS technology through their acquisition of DataCritical. Philips chose to develop their own, based on Philips chips repurposed from DECT telephony applications.

If you make a radio, it’s got to have something to talk to on the other end, the end connected to the wired enterprise network. Without Wi-Fi, medical device makers would also have to design and manufacturer their own transceivers, much like how GE and Philips make their own proprietary WMTS access points.

Another OTS characteristic is that there are numerous potential suppliers, for both client radios and infrastructure. Wi-Fi suppliers compete on price, features, technical support and availability, and medical device makers can readily source parts from a second or third supplier if the need arises.

Economies of Scale

Another source of device maker’s infatuation is with economies of scale. Economies of scale results in lower unit costs and a richer feature set, compared to wireless technologies developed specifically for medical device wireless enablement. The thought of all the millions of Wi-Fi client radios made each year (and especially the ever falling cost per unit) quickens the pulse of any device maker contemplating wireless enablement. The broad market for Wi-Fi dramatically lowers the cost of radios, access points and related infrastructure. Even a large manufacturer with widely  deployed wireless devices, like CareFusion or Philips Medical, will only sell thousands of wireless devices in a year – practically a rounding error to Wi-Fi manufacturers who sell millions of units in a month or quarter.

Leveraging Planned or Existing Infrastructure

And Wi-Fi infrastructure, it’s pervasive, and growing in reach and depth every day – world-wide! What is the likelihood of going into a hospital (at least in the US) that doesn’t have Wi-Fi deployed somewhere – if not everywhere. Because Wi-Fi is a part of hospital’s IT infrastructure, medical device makers are able to share the infrastructure costs for wireless medical devices with other wireless enterprise applications. Even in cases where a hospital has to install the Wi-Fi network  to support a new wireless medical device, they don’t mind because it’s part of the enterprise IT infrastructure and will be used for bedside charting, meds administration, wireless voice over IP (VoIP) phones, or some other application.

In situations where the hospital’s already invested two or three million dollars in Wi-Fi, adding a wireless medical device application often represents a nominal incremental investment. A broadly deployed dedicated wireless infrastructure, like WMTS, 802.15.4 or ZigBee, can easily run an additional one million dollars or more to the cost of the medical device system. This puts manufacturers using Wi-Fi at a competitive advantage, which they love.

Single World Wide Product

Next in the pantheon of manufacturer’s love of Wi-Fi are standards. Standards enable medical device makers to create wireless products that can be sold world wide. Having a single world wide product lowers costs and time to market for manufacturers. The industrial, scientific and medical (ISM) bands are reserved internationally – one of very few frequency bands that are designated world wide. Consequently, a wireles medical device that uses the ISM band can be sold world wide. Yes there are a few tweaks required for certain nations, but those are built in to the OTS radios and infrastructure medical device makers already use. OTS, be still my beating heart!

The other set of standards are defined by the IEEE, called 802.11. Each different standard is a letter after the numbers, for example 802.11a/b/g/n are the four different standards that define the various communications protocols that are supported. There are also standards for security, quality of service, improved mobility performance, and much more. In fact the alphabetical identification of individual 802.11 standards has gone from a through z to double letters. The most recent double letter designation is “ai” for Fast Initial Link Setup.

Cross Medical Device Maker Coexistence

Coexistence is the magic that enables wireless devices from different manufacturers to work on the same network infrastructure, along with all the non-medical device Wi-Fi devices found in a hospital. The 802.11 standards, and especially 802.11a/b/g/n are what provide the framework for this coexistence. The vast majority of frequency allocations, for example WMTS, do not include standards that ensure coexistence. They rely on limiting users to specific applications and a first come/first serve registration basis. For example, there are frequencies allocated for broadcast television, mobile phones, radio astronomy, and aviation radar – those frequencies can only be used for the applications for which they were designated. The users of these types of frequencies must also register with the designated registrar (often a government agency) to become licensed. A potential user wishing to be licensed, can only qualify if there is sufficient capacity. Should the registrar determine the capacity for that frequency and location is already licensed by another, than the potential user is out of luck – hence the first come, first user nature of licensed frequencies.

The ISM band is unlicensed by design, and by using the rich standards available and how a wireless device is designed, many users can share the same frequency bands.

Hate

Hatred… loathing… abhorrence… enmity… revulsion… the emotional range for what medical device makers feel towards Wi-Fi is both deep and nuanced – and often for good reason.

Too Many Configuration Choices

Probably the first on any medical device maker’s list of reasons they dispise Wi-Fi is the wide range of configuration choices. There’s seemingly an 802.11 standard for everything. And for most standards there are a myriad of configuration choices. When managing a Wi-Fi infrastructure one must select the specific standards to be supported at your site, and how they are to be configured. In particular, one must chose how to authenticate devices that want to associate with your Wi-Fi network, how encryption will be configured to assure security, and how quality of service is defined. To medical device maker’s frustration, for every configuration choice, there are hospitals that have standardized on that configuration.

Medical device makers design highly regulated products that must be both safe and effective. To that end, manufacturers have traditionally designed products in a way that reduces variables and complexity in an effort to improve reliability and safety. The rational approach to Wi-Fi for a medical device maker is to select only those standards that are essential and specify the one way they will support their configuration. For example, take 802.11a/b/g/n and pick one. Hmm, 2.4GHz or 5GHz, pick one. Encryption and authentication methods? Pick one. Voila, fewer variables! This also serves to make their product less expensive to design and test, with a shorter time to market.

To their customer’s frustration, manufacturer’s choices are often different from the choices they made when designing their enterprise network. When this happens, providers have two choices: to reconfigure their network to accommodate the medical device their clinicians can’t live without, or tell their clinicians to pick another vendor who meets their network standards. Depending on the kinds of choices device manufacturer’s make, they can find themselves excluded from a substantial number of sales. At best, the device maker has a new customer that’s already dissatisfied with their product.

Demands to Support Multiple Wi-Fi Network Vendors

Due to the technical demands of their wireless application, their regulatory strategy, or both, medical device makers often design their products for use with a specific vendor’s infrastructure, e.g., Cisco, Aruba, Meru, Trapeze, etc. So what happens when a medical device maker designed their product for Cisco and their largest sales opportunity ever has Meru? Hate, rage, and seething animosity. And most likely a lost sales opportunity. In this case there are two choices: the provider can install a Cisco Wi-Fi network, in addition to their Meru installation, to run the wireless medical devices, or the device maker can redo their verification testing (and possibly some additional engineering work) to support the Meru network.

There is only one medical device maker that I know of that’s tested and certified more than one Wi-Fi vendor’s infrastructure for their wireless medical devices. Draeger has tested and certified Cisco, Aruba, Meru and Trapeze. This testing effort probably cost them a half a million to over one million dollars per vendor. That’s serious money that wasn’t invested in new clinical features.

In both these situations, configuration choices and the selection of a specific Wi-Fi infrastructure vendor to support, medical device makers have the choice of spending a lot more money on design and verification testing, or face a reduced number of hospitals in which to sell their wireless medical devices. Such a conundrum to make a manufacturer’s blood boil, their heart turn to stone.

Frequent Provider Network Remediation

Now let us shift to the Wi-Fi networks installed in hospitals, the fertile fields upon which device makers must sow their wireless medical devices. Even medical device makers with relatively undemanding wireless applications find the vast majority of hospital networks insufficient, sub par or inadequate to their needs. This loathsome deficiency results in frequent installation delays, while hospitals spend weeks or more often, months, whipping their Wi-Fi networks into shape. And while hospital networks are being rehabilitated, device makers face delays in revenue recognition and additional installation and support costs. Curse you, Wi-Fi!

Short Life Cycle of Wi-Fi Products

Yet another sling and arrow relentlessly tormenting device makers using Wi-Fi is change. When medical device systems were physically or logically separate networks, completely controlled by the device maker, they chose when to upgrade systems. Of course, since they were separate networks there will little or no need to upgrade anything – unless something broke and the original component was discontinued and had to be replaced by a new model. Even today, it is still possible to find medical device systems that were installed 5, 10 or 15 years ago, running on ThinNet or ThickNet Ethernet cable.  Those are days of innocence fondly remembered by more than a few manufacturers, before the dark and sultry sirens song of Wi-Fi.

Now when a wireless medical device is installed, it’s only weeks or a few months before the phone rings with an unrequited provider complaining that your wireless medical device system failed them after they upgraded all their Wi-Fi controllers to a new firmware release – that you failed to test. So now, when device makers aren’t spending resources on complaints generated by configurations they neither sold or tested, they’re feverishly testing new firmware for APs, controllers, switches, routers and testing new models of those same components when they are released. If you wondered why device makers only support one Wi-Fi infrastructure vendor, wonder no more. Imagine the scope of effort required to stay current with three or four Wi-Fi vendor’s product lines.

Costly Failure Mode Testing

The final outrage for some device makers is the lack of support or even disclosure from network vendors regarding latent defects in their products that impact the medical device system. Network manufacturers test their products for mission critical applications. Unfortunately, some medical device applications are life critical. Consequently, some manufacturers have to do their own failure mode testing of network components. These test results must be shared with the network vendor if they are to be expected to fix defects found in the testing. A common response from network vendors is, “oh ya, we knew about that. Thanks for the data.” Imagine the revulsion, the odium that device makers must feel.

Can Love Succeed?

As a technology, Wi-Fi is well proven. Yet, every new wireless application adopted by a hospital is almost always being implemented by that hospital for the first time. (Remember the saying, “You don’t know what you don’t know.”) How many times has a hospital attempted to implement a new wireless application – say indoor positioning or wireless VoIP – and had to go back, do another site survey, reengineering the network and install or move APs and other equipment?

Health care, and especially hospitals, are one of the most demanding Wi-Fi markets in existence. Few vertical markets include the high degree of mobility, high number of users, numerous advanced applications, and life critical safety demands of health care. Where else can you find a site with portability (computers on wheels for meds admin and charting), mobility (clinicians and caregivers), wireless VoIP, indoor positioning systems, and a thousand odd infusion pumps, a few hundred continuous patient monitors, and more? Sadly, nowhere. We are on the pointy end of the Wi-Fi stick, and medical device makers are not the only ones conflicted about this.

There are certainly things medical device makers can do to on their own to improve their relationship with Wi-Fi, and myself and others in the industry can help. Unfortately, there’s only so much individual device makers can do to mitigate the inevitably rocky relationship between them, Wi-Fi and their provider customers.

UPDATE: The ideas presented here are based on work that was started in 2008, when I developed the concept of an industry alliance to address network layer issues faced by manufacturers and providers. Over the years, I have presented this concept to many medical device and network manufacturers, several provider organizations, and in public venues like the FDA’s interoperability workshop.  For no good reason I have never written any blog posts on this topic. This is the first of probably 3 or 4 posts exploring network issues and potential solutions.

[Photo credit: Tarina Tarantino necklace available through kaboodle - get one for your favorite vendor/CIO today!]

…an intiative aimed to develop wireless medical monitoring systems, or body sensor networks (BSN), which would replace the traditional tangle of bedside caables used to capture a patient’s vital signs. GE’s vision for the systems would enable wireless monitoring from anywhere in the hospital — or even remotely at home.

For the past couple years, GE’s been pushing for the allocation of spectrum for MBANs. The press release notes that, “The FCC recently issued a notice of proposed rulemaking (NPRM), acting upon GE Healthcare’s petition to establish a new, vendor-neutral dedicated radio frequency band for low-power, short-range, wireless patient monitoring devices. This petition requested creation of a new Medical Body Area Network Service (MBANS), to support wireless sensors that monitor a patient’s health state, linked together in body sensor networks.”

Here’s David Davenport talking about their wireless sensor initiative:

Apparently, GE’s going after the cable replacement business for traditional multi parameter patient monitors. LifeSync has had a product replacing ECG cables (by far the most predominate type of cables in clinical use) for several years. LifeSync also controls the Besson patent (licensed to them exclusively by Motorola) that applies to wireless sensor based physiological monitoring.The FCC Notice of Proposed Rulemaking referenced is from June 29, 2009. Another “article” written by a law firm apparently engaged by GE was published March 20, 2009 and outlines:

Proposed Frequency Band:  ”identified the 2360-2400 MHz band as the preferred frequency band based on engineering studies showing that MBANS devices can successfully coexist with incumbent operators and users.” I would love to see that coexistence data. In a conversation with David Davenport of GE Global Research that, he told me that spectrum just outside 2.4 GHz was desired because it would enable the use of off the shelf 2.4 GHz components, with only minimal modifications.

Permitted Operations and Eligibility: ”the proposed rules limit the type of devices that will be permitted to operate within the spectrum to those involved in the monitoring, diagnosing or treatment of a patient.” No big deal here.
Authorized Locations: While only medical applications may use the spectrum, users “will be fully mobile, both inside and outside of healthcare facilities, without restriction.” This means purpose built MBANs just for health care. Imagine how long it took the networking industry to get Wi-Fi to be plug and play, fast and reliable (when deployed properly). Imagine all the money that those vendors spent getting their industry to this point. Now imagine what a half dozen medical device vendors can spend repurposing a bunch of Wi-Fi technology for MBANs. Think, “economy of scale” –  there won’t be any.

Spectrum Sharing Requirements: Here’s the big issue — “The proposed rules do not require the use of any specific standard protocol but GEHC anticipates that industry standardization efforts may occur. Currently, the proposed rules only require that all devices implement basic contention-based mechanisms to allow predictable and fair access to the spectrum.” The same vague promises of working out an industry standard after the fact were made when WMTS was created. Nothing ever came of that, and there were very serious coexistence problems with both GE’s and Philip’s WMTS the first several years they were on the market. This is another recipe for the creation of vendor specific proprietary systems, or at the very least erecting barriers to entry and higher switching costs. This is a great product strategy for GE (and Philips), but not so good for smaller competitors with not so large R&D budgets.

Emission Limits: This is low powered stuff, “MBANS devices be permitted to have fundamental emissions of up to 0 dBm EIRP for the proposed maximum 1 MHz emission bandwidth.”

Again, like WMTS, it appears that nothing will preclude medical device manufacturers from using other portions of the ISM band do develop and sell their own wireless sensor based systems (again, like Continua and others).

Here’s a great summary from mobihealthnews, written by Mintz Levin (another law firm engaged by GE?). More details are provided on the potential frequency allocations (a total of 3 bands), and specific issues the FCC is looking for comments on. Conspicuously absent are any instructions on how to submit your comments (except through Mintz Levin).

Here’s a pdf of the FCC’s press release on the proposed rule, and a pdf of the actual Notice of Proposed Rulemaking. More later.

Here’s a photo of LifeSync’s Wireless ECG rig. Note that each sensor (there can be as many as 12 of them) is not wireless.

I’m curious if anyone has been successful using their own vendors to pull cables for monitoring installations.  With the monitoring OEM we work with, they simply get a local subcontractor to do the cable pulls.

So this would involve breaking future monitoring packages up into two quotes:  one for the actual technology itself (and associated installation and implementation), and then one for just the cable pull work.  The latter would get bid out, and the OEM could compete against other vendors.

Of course, the OEM can just take the profit they would have made on the cable pull and add that to the cost of the equipment bid.  One would need to find a way to watch that carefully.

Which lead to a critical observation from Craig Muehling:

We have started pulling our own cable for monitoring installations. I have one happening now and I’m not exactly pleased how it’s working out. I won’t mention and names, [vendor name removed] but they make their equipment charges per drop whether you have any drops or not.

I would still like our [networking] vendor to do the networking, ie: install and configure switches and physically plug patch cables into the switches. Seems easy, but the way they [the patient monitoring vendor] charge it’s really not much less than if they did the whole job. I think from now on, we will have to take on the entire networking job.

I have learned a lesson from this last installation and will scrutinize the quotes closer from now on, but with their charging structure
(supposedly) there’s not a lot of options. Either we do the entire job, or they make lots and lots of money for relatively little work.

Here’s how they do it at the Mayo Clinic, from Steve May:

We have our own low voltage and high voltage contractors for all in-house cable pulling, to include data pulls and all project related work, so cable pulling and wiring costs are never part of an installation package, but an infrastructure cost which we earmark as Capital expenditures and plan/budget annually. Bids & labor costs are renewed by Purchasing every 2 years and our preferred contractors are all able to bid on both project services & time & material services.

It works well because the contractors get familiar with our electrical & system standards, building layouts, construction management staff and our bigger customers (at our project reviews, meetings etc.) whom have special requirements like radiology, surgery etc. All our monitoring projects are hardware only, we are even trying to separate the installation engineering, documentation (which is usually terrible) like red lines drawings and wire lists. We’re also trying to separate the go-live training, to manage train-the-trainer, in-service and certifications by the manufacturer after installation.

And according to Chris:

We do not use third parties to pull cable for monitoring systems.  We pull all of our own cable.   I have about 8 personnel who are Fluke certified to pull and terminate copper and fiber.  Of course any of the technologist on my team can pull the cable.  We have a Fluke DTX1800 as our primary cable certification tool.  We have other tools to validate cable pulls and termination, but the DTX1800 certifies each cable.  Our Information Services department likes our capabilities to certify our own cable.  The IS department “farms out” their cable pulls and terminations to a third-party vendor.

I like that we pull our own cables, this way my team knows exactly where all the runs are located, for each area, and they are confident that the job is done right.  We have had to work side-by-side on many projects with the outsourced vendor for the IS cable pulls.  Their technicians ave laughed a few times because we have pulled many cables at one time during an install and tested each one and they all passed the certification process.  They laughed because they said when they pull that many cables at once, they usually have around a 10% failure rate (bad termination or poor fiber signal).  I also think pulling our own cable makes us better at understanding networking.  It certainly aids in troubleshooting.

All of our UPS’s are networked [i.e., monitored] and that way we get paged and e-mails if a UPS is starting to fail or the room temperature where the UPS is located gets too high.  We have remote sensors that attach to the UPS for monitoring environmental conditions. Our Philips Monitoring Network uses Cisco routers and we have downloaded a very nice application that monitors all of the routers and switches in the network, again paging us if there are problems. 

I believe that pulling our own cable is just an extension of managing our networks for which we have responsibility (CCTV, Card Access, miniPACS, etc…). Last year we saved over $340,000  by pulling our own cable versus outsourcing including overtime labor for some of the larger projects.

And J. Scot Mackeil suggests the following best practice:

Have ALL the data cables that carry life critical monitoring data around the facility be a unique color per hospital policy.  When my hospital started installing spacelabs IP networked monitors and replacing the DEC net stuff, I insisted we adopt such a policy and stick to it. Every medical monitoring network run and patch panel from the servers to the local closets to the wall plates to the monitors is done in HOT PINK Cat 5 cables.

There is no way the IT or facilities guys can mistakenly disturb a life critical monitoring application as our cable color screams out loud and clear, “don’t mess with me!”  Our connections to the cloud are by VLAN and in the racks, we have 24 port ethernet hubs, installed so we could isolate from the network in the event of a major IT failure.

This approach works great for private networks like those required by patient monitoring systems. The industry trend, however, is to converge private medical device networks with the enterprise network. Medical device systems running on enterprise networks have a whole different set of best practices.

Jerry Messina noted that, “Some vendors will not certify the network if they or their contractor does not do the cable pulls.” And Ray Brown expanded on Jerry’s observation with the following:

I got a question or two about cable pulls. I was in a Biomed / IT meeting earlier today, and I wanted to see if the following was specific to just Missouri, or if it was USA-wide. Also, let’s pick two different types of data runs, and I’ll be specific – GE PACS, and
Philips Intellivue networks.

Is there a rule on the books that, “if you run wiring to any Biomed equipment that affects a patient or patient care, the FDA requires those lines have to have certification, and you must keep a copy of the certification for 25 years.”

I know Philips especially wants their lines certified before use, but keeping the certificate on hand for 25 years? This information came to my Director via the Missouri State Engineering Association, and I just wanted to see what else was on the books.

The FDA is a convenient lever for many situations, but one not always applied correctly. My response follows:

In general, FDA regs look at two things, 1) the processes a manufacturer follows to design and manufacture medical devices, and 2) the safety and efficacy of medical devices via the FDA’s classification related regulatory clearance/approval processes (Class I, II and III). As a health care provider, the FDA has no regulatory oversight over you unless you do things that meet the legal definition of a manufacturer.

Manufacturers submit entire medical device systems to the FDA. These systems are described by (among other things) marketing claims/intended use statements, product and system specifications, and resulting verification and validation testing. It is this totality of the product/system, as it is intended to be used, that is cleared or approved by the FDA.

Complex systems that include networks and interfaces to other devices and/or systems end up blurring the lines between what is and what is not a part of the regulated medical device. For example, if a medical device system runs on a network (physically separate or as a VLAN on your hospital enterprise network) the network is part of the medical device.

The buyer of these systems should maintain their systems within the specifications used by the manufacturer in the design and installation of the system. Not conforming to these specifications result in a medical device system that is different from what was designed and tested by the manufacturer, and different from what was cleared or approved by the FDA. It is those vendor defined specifications that received FDA clearance, that must be maintained over the useful life of the system.

Thus the principal reason to conform to manufacturer’s specifications is to ensure safe and effective operation of the system.

There is no FDA regulation that says customers can’t install systems themselves or change something in a system, but to do so in a way that fails to meet the manufacturers specifications would likely render the system an “off label” use. There is no legal “certification” process that hospitals must meet, nor are there any requirements to maintain “certification documentation” for 25 years.

When manufacturers install complex systems in a hospital they do (sometimes a considerable amount of) verification testing after the installation, to ensure that the system — and the broader network and IT environment in which it is installed — meets the specifications for that system defined in the design documents of that product. This process is sometimes referred to by the vendor as “certification”, but is not recognized as some kind of official or endorsed certification by the FDA or anyone else.

System specifications for any product change over time, usually because parts used in the system become unavailable and the manufacturer has to find replacements that change specifications. It is also possible for hospitals to go outside of specifications with relative safety, if they follow a risk management process similar to the one used by manufacturers. Such an effort is not a trivial task, and is rarely undertaken by hospitals. (Specifications are often unknowingly changed frequently by hospitals, but that’s another issue.)

Regarding your specific cabling example, the manufacturer writes a specification for that cable, perhaps something like, “shielded twisted pair Cat 6 cable”. There may also be specifications about physically routing the cable (distance from EMI sources) and/or specifications for testing the cable run after it is pulled for attenuation, noise, etc.

Provided the manufacturer gives you all those specifications, you can certainly pull cable and do other installation tasks yourself. By following the manufacturer’s specifications (including testing), you can remain fully in compliance with what was approved by the FDA. If the manufacturer choses not to share those specifications with customers, that is their choice and not something mandated by the FDA.

UPDATE: The title for this post was revised to better indicate the subject, which is the installation of patient monitoring system networks.

Fresh back from the MDC Conference in Boston last week – great inaugural event and a perfect venue at Harvard Medical School. Thanks to Tim and the conference organizers — I personally heard many very positive comments from a number of attendees.

As the healthcare market continues to evolve, so do solutions related to medical device connectivity. I would like to invite you to join me in a dialog over the next several weeks – perhaps even on an ongoing basis – that will explore the trends that are affecting the market of medical device connectivity.  The idea is to have an open and interactive discussion on where the technology is today, where it needs to go, and what is driving the market.  Remember that this is just my viewpoint as I see things based on my experiences. Perhaps your experiences and perspective are similar or maybe they are completely different.

So, let’s begin.  The first trend I’d like to talk about is wireless medical devices and the impact on connectivity.  We all know that more and more medical devices are becoming wireless and therefore more mobile, for example more and more smart IV pumps (smart pumps) are being implemented every day. One key aspect of wireless technology is the fact that wireless enables devices to become untethered, and therefore a mobile use case is enabled. Wireless medical devices such as smart IV pumps and patient monitors add to the list of connectivity challenges because, from a pure connectivity perspective, they have basically eliminated one problem (the use of a serial data cable) and often create others. Once a medical device is no longer connected to something that facilitates data integration (like a bedside terminal server for example), then part of the connectivity and integration problem often shifts onto the manufacturer of the medical device.

Enterprise applications need access to real-time device data and alarm data. Without physical connectivity to individual medical devices at each patient’s bedside, the enterprise application must access the data via a gateway (a central server) connected to the hospital network with an HL7 outbound data interface.

Many of the large patient monitoring vendors did not experience any problems with this shift to wireless devices – mainly because they had already developed and understood device gateways and methods for handling the identification and mapping of patient data. Most of the leading patient monitoring vendors have been integrating their devices to EMR’s for at least the past 10 or more years. Monitoring systems have developed methods to deal with data identification (ensuring the right data gets to the right patient’s record) through some collaboration with the EMR vendors. But this is a whole new arena when you consider IV pumps and many of the other common bedside devices. Dealing with the identification of wireless device data from mobile and transient medical devices brings a whole new set of challenges – and this is both a technical problem as well as a clinical workflow issue.

There are quite a few device manufacturers that offer wireless in their devices. However, there are really only a few vendors that have done wireless right. And by this, I mean taking into consideration all of the requirements to operate on the hospital’s enterprise WLAN and requirements for how the wireless device help facilitate integration to enterprise systems such a EMR’s and alarm notification systems.

So what do you think? Are wireless devices causing you to think about medical device connectivity differently?

During breakfast, I chatted with Michael Kurgan, CEO of start-up Service Wing Healthcare. They’re targeting the wireless gateway market to support body area networks. I mentioned a company I heard about yesterday, GainSpan and Michael had some great perspective on the challenges picking tech winners in immature markets. GainSpan has an ultra low power wireless SOC (system-on-chip) that includes an 802.11b radio and two ARM processors, one for the radio and one to drive whatever device the chip is enabling. In an immature market, just because a component comes from a big company does not mean that their component will have long term success. A much smaller competitor with a better solution may win, or the big company may acquire a better solution in order to be a big player in that market segment.

Rob McCray, chair of the Wireless-Life Sciences Alliance, kicked things off. Camille Sobrian was up next, touting San Diego as the biggest wireless hot spot in the world (perhaps for cellular wireless). She also mentioned the West Wireless Health Institute, and the upcoming TEDMED event. Dr. Paul Jacobs, CEO and chair of Qualcomm passed on introductory remarks and jumped right into things wireless.

Paul noted that what’s going on right now is convergence, and it’s those who understand both industries that can lead that convergence. He described the new mobile internet experience: networks, devices and applications in the cloud. Multiple air interfaces are a key enabling component. The newest radios are only a few percent more efficient, but they tend to support broader bandwidth to improve network performance. He mentioned a mobile WAN, and various wireless LANs and BANs. A future trend is where applications control the radio to optimize performance for that application.

In Europe, mobile broadband radio dongles for connecting laptops outsell all the 3G phones sold there. Paul defined convergence as the overlapping of computing devices, consumer electronics and wireless tech. Paul alluded to the Amazon Kindle, as a prototypical device for the future, where an embedded system includes a cell phone built in for connectivity. He also highlighted Snapdragon as a platform for mobile data processing, multimedia performance, 3G wireless connectivity and the low power consumption.

Another Qualcomm solution, eZone universal wireless charging tech, an induction-like recharging solution was touted. Something like this is the future of charging for reusable wireless sensors or patient worn gateways.

Paul wrapped things up by announcing Qualcomm’s contribution to a wireless innovation challenge for universities in southern California.  He equated this effort to past market development efforts of Qualcomm’s. Their approach to collaborate with wireless network operators (carriers), cell phone manufacturers, media/services and application providers, and web companies like eBay, Amazon and others.

Next up was Katherine Kalin, vice president of strategy, J&J Corporate Development. She bragged on her company (120k employees, $60 billion revenue, 250 operating companies, etc.) emphasizing their decentralized management structure. This allows each operating unit to get closer to their customers and better bend their operations to their specific market segment.

Katherine talked about how J&J is targeting what they call “white spaces” for new business opportunities. Wellness and prevention was designated a business platform, including two new acquisitions: HealthMedia and Human Performance Institute.

Part of the disruptive solution evolution she mentioned includes unusual partnerships: Intel/GE Healthcare, Walmart/Dell, and other cross-market alliances.

The first panel was up next: Dr. Eric Topol, Philip Low, MD, Jeff Augenstein, MD, and Stan Kachnowski, MD, moderated by David Gruber, MD.

Jeff started things off. He contrasted the promise of health care IT (HIT) and the reality. He noted a litany of very expensive, high profile HIT failures. He presented a scenario — a strawman of a sort — centered on trauma. Trauma is the most expensive disease, and it is almost always preventable.  This trauma example, self inflicted by the victim, offers examples of how current and soon to be available tech is applied to the situation.

In response to Jeff’s scenario, Stan Kachnowski noted that the type of innovation that is required must be low cost, small and easy to use. Stan went on to describe research he’s done looking at clinician workflows and how various communications methods impact workflow. His research has shown that workflow problems like process interruptions, can result in patient injury or death.

Philip Low described technology to provide feedback to the patient about their neurological state, whether they are intoxicated or falling asleep behind the wheel. He also suggested that we not confuse wellness with health care. Health care is delivered to patients by providers; wellness is a physiological condition attained by individuals.

Topol stated the health care delivery system in the US has already crashed. Anything you do can only improve the situation. He was not optimistic about EMR interoperability. Jeff’s genomic component of his trauma scenario was of interest. One fifth of the population has a gene that makes them more susceptible to brain swelling from head trauma. If you’ve not had your genome sequenced, you don’t know if you have that risk.

Dave asked the group about the current paradigm of research, randomized double-blind trials, and how that applies to evaluating software and other tech that impacts care delivery. Great question; manufacturers and physicians perennially tussle over this issue. The conventional scientific method is great for drugs and some devices like stents, pacemakers and heart valves, but worthless in evaluating workflow automation.

Jeff noted that the focus in this event is about how care is delivered rather than the basic science of diagnosis and therapy. The implication being that conventional randomized trials are not appropriate to evaluate improved workflows resulting from improved communications or software applications. Stan argued for a lower hurdle for the regulatory approval for new and innovative technologies to get them to market more often and in a shorter period of time. He suggested that post market surveillance might be a way to do that without compromising safety.

Jeff noted that we need to overcome the poor adoption of many purported trends in health care: he noted EMRs and patient self management as two examples. Stan observed that physician technology adoption can be very rapid — pagers, fax machines, new diagnostic technologies, etc. — if it works and delivers value, they will adopt. Philip noted that some physician resistance is the concern that new technologies will replace them rather than just make them more efficient. Eric noted that the administration of TPA (tissue plasminogen activator) for heart attacks and stroke took almost 10 years to become a standard of care, and a trial with 40,000 patients, suggesting that this is too long.

Wrap up comments captured an interesting dog/cat perspective: health care delivery (and providers) is transaction oriented, while patients look to form relationships with providers.

After the break, Andy Thompson, founder and CEO of Proteus Biomedical, talked about How can Wireless-Life Sciences Transform the (Broken) Economics of Global Healthcare? He suggested the acute care hospital is the “epicenter of economic distortion.” In the UK, they’ve built up a primary care network and moved the “becoming acutely sick” and the “chronically sick” patients out of the hospital. The promise of wireless convergence is to move the chronically sick out to “community and family care networks.” He defined the family care whole product solution to include therapy, monitoring, applications and community, and incentives. His company, Proteus, can deliver a highly profitable solution for $2 per day. Andy’s message was that the technology exists, what’s missing is the whole product solution combined with an alignment of incentives.

The next panel included Agnes Brzsenyi, general manager of GE’s home health business, Terry Hinsey, vice chair at Deloitte, and Jeff Goldsmith, blogger and president of Health Futures. Jeff Belk, principal of ITC 168 Capital moderated. Terry sees many companies focused on finishing a product, and missing things in regulatory and the “whole product solution” that will drive adoption. Agnes talked about recent CMS studies that showed cost increases or no meaningful cost savings using remote monitoring or Healthcare Unbound technologies. GE is heavily focused on value, which is what people require before they buy. Another issue was product design: usability and good workflow automation. She contrasted the group here lobbying for e-health with a conference she attended in Prague last week was attended by the ministers of health from many of the members of the European Union — who described how they’re adopting e-health. This contrasted with this conference where a bunch of providers and entrepreneurs are trying to drive adoption.

Jeff asked the question, how many of these products are we welling to adopt ourselves? He noted that he’s 60 and has no interest in going to a  retirement home and living with a bunch of other old people. Nor is he looking forward to getting calls from his daughter to put his smart shirt back on. He referenced Clint Eastwood’s character in Gran Torino as a model for the soon to be elderly. He suggested that the paternalistic bent of many of these solutions was a huge barrier to adoption.

Regarding reimbursement, Jeff noted that that really went out the window with capitated care. The trend is to disperse risk across the care delivery system. For example, CHF readmissions: a hospital that knows they won’t be reimbursed for the next frequent flyer admission will be motivated to manage that patient to avoid that readmission. Terry noted the list of CPT codes that vendors used to promote how providers could generate revenue with their products. Now cost avoidance and improved outcomes are an increasing factor due to shifts in incentives and reimbursement. Terry sees market incentives aligned to foster cross party interoperability — across providers, payors, technology solutions.

Jeff sees the hospital as a huge market for the technologies represented at this meeting. He noted the need to greatly increase productivity to enable the growing shortage of health care workers to serve the soon to explode number of elderly. Jeff Belk suggested that disruptive technologies will just as likely to come from developing country markets, and not necessarily the developed world as most people seem to expect. One of the factors here is that many emerging markets can’t afford the same technology adoption path followed by developed markets. Consequently, these emerging markets try completely different things by necessity, some of which will have applicability world wide. Agnes: technology itself is just technology, it is the people, workflow and importance of the information that comes out of it that is key. The secret sauce is figuring out how to leverage this to change behavior — especially important with chronic disease management.

There is a strong idealistic theme in wireless health care that we can save people from themselves. This seems true especially of the obese, smokers, substance abusers, and extends even to chronic diseases like diabetes, CHF, and COPD. A question from the audience asked about personal responsibility on the part of the patient. She suggested financial responsibility (i.e., consequences) are necessary.Terry agreed that, “stick beats carrot every time.”

Next up: part one of award finalist presentations. Presenters include GreatCall/Jitterbug, MedApps, CellTrak Technologies, BeWell Mobile, Diversinet/AllOne Mobile, and Epocrates. Each company CEO had 2 minutes each to tell their story. They failed miserably.

Lunch saw a presentation from Jay Parkinson, MD, founder of HelloHealth. HelloHealth supports a direct pay (cash) business model for patients and physicians. Like Amazon for resellers, HelloHeath handles payment transactions. Like Facebook, there is a rich environment for scheduling appointments (in office, text or video), rating providers, tracking health care information and supports messaging and activity feeds for patients and physicians. The software is effectively an electronic medical record and billing/payment system for both providers and patients. There’s also a social networking angle amongst physicians and patients. Potentially a game changing platform for health care. According to Jay, HelloHealth is ideal many relatively healthy people when combined with a high deductable health plan and health savings account. Jay pointed out that many people in the US are actually over insured.

After lunch Clint McClellan, Qualcomm, moderated a panel looking at international wireless health initiatives. Panel members included Karl Brown, Rockefeller Foundation, David Edelstein, Grameen Foundation, and Mitul Shah, United Nations Foundation. These groups are looking to leverage the low cost disruptive capabilities of wireless health to improve health care in developing countries.

Grameen is using a simple Java app deployed on a low cost cell phone to replace most of the current log books and statistics worksheets in clinics.  Mitul noted that many undeveloped markets have an advantage in that they don’t have the health care system baggage that countries like the US have. This could allow these countries to leapfrog developed countries in their utilization of wireless health and other technologies. The lack of legacy systems is a real advantage.

The agenda broke into two tracks, continuing the international focus and another applying Gameboy/Xbox like consumer electronics to wireless health. I picked the international track. The previous panel was expanded to include Shawn Covell, Qualcomm, Yuri Ostrovsky, Click Diagnostics, and Dr. Krishnan Ganapathy, Apollo Telemedicine Networking Foundation. Ashok Kual of ARCS Global moderated.

In environments where the population is uneducated, i.e., illiterate, an effective solution is to use a local proxy (who can at least read at a grade school level) to operate the technology and mediate the communications between the physician and patient. The general population in developing markets, while not formally educated, are intelligent. Properly designed products have been very successfully adopted in these markets. Shawn noted that, regardless of education, users need to be trained.

Cultural issues equates to local needs and how to address those needs in the local community. There’s a tension between the need for scalability and high-touch capabilities. The basic economics of wireless health technologies are of much greater importance — to the foundations and those in underdeveloped markets — are much more important than cultural issues.  A common mistake is to “dumb down” a product for developed markets, when you need to know what the market requirements are for those international markets. In every market the users are different, and this must be taken into account.

Karl noted that historically on a world wide basis the cost of health care always grows substantially faster than growth in GDP. For example, over the past 20 years, health care costs in China have grown 50 times — several times faster than their GDP. To a great extent, this makes sense to me — as a society gets more affluent, what better to spend your money on than health care? From a market opportunity perspective, diabetes represents a huge target market for developing countries.

In summary, developing countries represent a great opportunity to test products. Their receptivity to technological innovation, low regulatory hurdles, and the potential for demonstrating benefits makes them a great target for initial product releases.

Aaron Goldmuntz provided an update on CardioNet, the first wireless health application using a carrier network for communications. A big part of CardioNet’s success is based on research done to validate the clincal benefits of CardioNet over loop event cardiac monitoring. CardioNet is looking to extend their franchise to grow the business. They plan to leverage their service model, build share within their current market, and expand current technology to adjacent cardiac segments. Their new atrial fibrillation monitoring is both a diagnostic and management tool. They’re also getting in to the clinical trails business. CardioNet is also looking to expand outside the US to international markets. Finally, they’re looking beyond ECG and cardiac monitoring to look at new therapeutic and diagnostic modalities. Neurology (strokes, sleep disorders) are recent targets for CardioNet.

Part two of award finalist presentations include: IntelliDot, Triage Wireless, Tagnos, MicroCHIPS, PhiloMetron, and Proteus (which Andy talked about earlier today). Jim Sweeney with IntelliDot, noted that CMS’ list of never events, the adverse events that should never happen — which they won’t reimburse hospitals for — is now up to 27 items. This group of CEOs did worse than the previous one at limiting their comments to 2 minutes each.

Now for the Triple Tree aware in three categories: clinical applications using wireless tech, consumer oriented solution, operational effectiveness solution. (Oops, the actual award trophies are a few days late and will be sent to the winners.)

Proteus Biomedical wins the clincial applications using wireless technology solution.  Best consumer experience goes to Great Call/Jitterbug. Best operational effectiveness is IntelliDot. And thus ends the first day’s sessions.

Photo at top: Computational modules for wearable health monitors from Nyx. Very cool stuff.

Problems with Wireless

Those of us who are old enough, think back to the golden age of wireless medical devices — channelized analog telemetry. These systems were so basic and limited in scope (a couple dozen transmitters typically covering just a single 30 bed unit) that they had few problems and required little maintenance.  Today, larger hospitals are pushing the envelope with a few hundred patient monitors and a thousand or more wireless infusion pumps. These wireless devices are using sophisticated client radio/access point (AP) communications protocols to maximize capacity, whether using Wi-Fi or WMTS. We’ve since left the golden age far in the past.

Radio frequency (RF) spectrum is a shared resource. There’s no getting around that fact, even with “dedicated” spectrum. The ether in which wireless signals move is like gases in the atmosphere or chemicals in water. There are no ways to practically segregate RF signals to specific areas, except for a Faraday cage. In a health care facility, some shielded rooms in Radiology qualify as Faraday cages, but little else. Much of the rest of a health care facility consists of objects and structures that seem to perversely confound and obstruct RF communications in  ways like partially blocking and attenuating signals, creating multipath interference, and radiating both intentional and unintentional interference. Intentional interference is where two or more users of a portion of wireless spectrum get in each others way, disrupting or degrading the communications of one or both parties. When there are problems with two or more wireless devices using the same spectrum, this is intentional interference, often referred to as coexistence problems. Unintentional interference comes from electromechanical devices that accidentally spew RF signals as a consequence of some degradation or failure. Common sources of unintentional interference are florescent light balasts, blow dryers, paper shredders, elevator motors, or faulty microwaves. You can see a bunch of examples of RF interference on a spectrum analyzer (which everyone doing wireless medical devices should have, and know how to use) here.

Another common variable to wireless communications is capacity. Wireless capacity is measured by the number of transmitters and receivers that can use a given amount of bandwidth or spectrum, and the amount of information — be it data in bits, or modulated analog information — that can be reliably moved through an allocated frequency range. Capacity is determined by the amount of bandwidth (more is generally better) and technical tricks used to increase the efficiency of moving information. Channelized analog is the least efficient means to move information wirelessly. More efficient techniques entail digitizing the information, moving it more quickly (higher data rates), and using schemes to share bandwidth among users more efficiently (things like FHSS, ODFM and MIMO). Another important part is the definition and adoption of a common scheme that ensures coexistance between the various users.

Reliable wireless communications has three basic requirements: 1) the wireless application must detail the proper requirements and technical specifications necessary for proper operation, 2) the wireless system must be properly designed and tested to verify the resulting wireless infrastructure’s performance, and then 3) the wireless system must be managed and maintained to ensure ongoing operation within specifications. This is a lot of work. And if you want to use wireless stuff, there’s really no way to avoid this work — although some may suggest otherwise.

Blog Mobihealthnews picked up a press release from ERBI, an industry alliance of biotech firms in the U.K., that suggests that, “A dedicated frequency band for medical devices would boost confidence and stimulate uptake of wireless technology within a healthcare environment.” You can download your own copy of the report here (pdf).

The “study” is not really a study but a record of, “a facilitated workshop, which brought together experts from the fields of medical device development, wireless technology and healthcare” (i.e., members of ERBI). The usual wireless challenges were trotted out, like congested frequencies and problems of interoperability and coexistence. No data is presented to quantify or characterize these issues, and one is left to assume that there are no solutions — besides dedicated spectrum — to any problems that do exist.

Dedicated Medical Spectrum: Benefits and Costs

Yes, the list of devices using the 2.4GHz portion of the ISM band (where Wi-Fi is located) seems endless. But because applications of the ISM band are relatively short range, it is only the specific devices using 2.4GHz within a location that have to share the spectrum. In a hospital you might have computers on wheels (COWs), wireless VoIP handsets, smart pumps, patient monitors, maybe PDAs. Each of these devices associates with just one out of hundreds of APs in an enterprise. Is this such an overwhelming amount of devices?

As we saw above, there are inherent risks in the use of any wireless technology. If wireless medical devices received their own dedicated portion of the radio frequency (RF) spectrum it might make wireless communications better in some ways.

With dedicated spectrum it is possible that there would be less interference and fewer coexistence problems. But there is more to this than must having dedicated spectrum. Certainly there will be fewer devices trying to use the same spectrum. However, there still must be sufficient bandwidth available to medical devices so they all have sufficient “elbow room”. Current WMTS is a case in point. Users of WMTS get just 13MHz of bandwidth on 3 separate frequency bands (608-614 MHz, 1,395-1,400 MHz, and 1,429-1,432 MHz). Vendors only support two of the three bands, the 608 and 1,400 bands.

The creation of a dedicated frequency band would certainly increase the cost of wireless medical devices — which is no way to “stimulate [the] uptake of wireless technology” in health care. Most current devices leverage tremendous economies of scale from commercial and consumer technologies like Bluetooth and WiFi. This would be lost with a specialized band where units sold will be measured in tens of thousands, rather than hundreds of millions.

Some proponents of dedicated spectrum suggest using spectrum that’s close to the ISM band. This would potentially allow for the re purposing of existing ISM technologies to the new dedicated medical spectrum. This approach has some validity, if adjacent spectrum is available and existing technology can be re purposed for a reasonable cost. An example of this is Philips’ wireless patient monitors that use DECT as the underlying technology for their WMTS infrastructure.

The communications capabilities on a new dedicated frequency would be feature poor. Right now, health care leverages lots of important advanced features from horizontal market wireless technologies. Want to keep your advanced authentication and encryption? Out the window! Want quality of service or fast roaming with that? Forget it! How about special power save features for longer battery life? Sorry! These are features supported by the 802.11 standards and increasingly built in to today’s wireless medical devices. Again, some of these features may be available if re purposed Wi-Fi or other technology can be used.

The devil’s always in the details, and in any re purposed wireless technology, the question is how many capabilities can be simply ported over and how many must be re engineered in part or in whole.

What Dedicated Spectrum Won’t Fix

Dedicated spectrum for medical devices would not greatly reduce interference. Most interference comes from unintentional sources like faulty florescent light ballasts, blow dryers, paper shredders, microwaves and elevator motors. Only a small portion of interference comes from other intentional users in the same band. Yes, coexistence problems among devices in the ISM band do exist, but it is manageable. Oh, and because it’s a big market, we have lots of fancy tools built into the infrastructure for monitoring and fixing interference and coexistance — more features we’d likely loose with dedicated spectrum.

Getting wireless regulatory bodies and governments worldwide to select a frequency band for medical devices would take forever — if it is even possible. Note that portions of ISM used by WiFi aren’t even consistent world wide. Precious RF spectrum goes to national security (public safety, military) and serves major engines of the economy (broadcast, commercial data, etc.) While we can all agree that we spend a lot of money on health care, wireless spectrum devoted to health care won’t generate much economic activity or lower health care costs. It seems to this observer that it is unrealistic to think governments around the world will cough up spectrum for something that’s already working in established frequency allocations.

Health care will loose bandwidth with a new dedicated frequency allocation. Current bandwidth for 2.4GHz and 5GHz 802.11a/b/g is 383MHz (not including the 255MHz recently added to the 5GHz band). This compares to WMTS, which gets a measly 13MHz — barely enough for a few hundred wireless patient monitors in the same hospital. Current 802.11 bandwidth is 30 to 400 times bigger than WMTS. Another dedicated band is MICS, the Medical Implant Communications Service, that get’s just 3Mz of bandwidth (more on this below). Bandwidth is directly related to capacity; the more bandwidth, the greater the number of users that can be supported. Bandwidth also provides the elbow room to manage coexistence problems. To be safe and effective, wireless medical devices need bandwidth.

Once a new frequency allocation is dedicated to health care it will be time to develop standards so solutions from different vendors can coexist with the same spectrum. According to Wikipedia, the first 802.11 standard was released in 1997 after several years of work. What followed is over 10 years of further enhancements and refinements.  The alternative to time consuming standards development is a hodge-podge of proprietary products that don’t coexist, or do so poorly.

Remember the early days of WMTS? With the advent of digital television, medical device vendors went to the FCC and said they had to have RF spectrum to replace that lost to digital TV (for some reason, they didn’t want to use the ISM band). The FCC came up with 3 non-contiguous slices of spectrum and named medical as secondary users. Vendors informally agreed to 1) implement support for all 3 slices of spectrum and 2) work together to develop interoperable coexistance across all vendors using the frequency. Sadly, neither happened. Existing vendors just recrystaled their existing telemetry systems for 6o4MHz (they added 1.4GHz support later). No effort was made to develop any standard to ensure coexistance. In fact, for the first few years, WMTS based systems from two different vendors couldn’t be installed in the same hospital. Over time, GE and Philips worked out reasonable WMTS coexistence. Besides Philips and GE, only Spacelabs and Datascope released WMTS based systems. All other medical device vendors have looked to 802.11 for their wireless devices. Which brings us to the final issue with dedicated spectrum, currently installed products.

There is a large base of installed wireless medical devices. Most of these devices use Wi-Fi, and some WMTS. The typical life cycle for a medical device is 7 to 12+ years. Providers and their vendors will be managing these existing wireless devices for many years to come. Products based on any new dedicated spectrum won’t hit the market for at least 2 or 3 years, leaving the hard work of managing today’s wireless technology a requirement for a decade or more. That’s not to say new wireless technologies won’t be developed and come to market, they will. And when they provide tangible benefits, they should be adopted.

Alternatives to Wi-Fi

Given the increasingly well known issues with Wi-Fi networks, I frequently get questions about alternatives. In fact, there are alternatives, and for some applications, attractive alternatives. Wireless applications in health care are divided into short range cable replacement and  enterprise network “last 100 feet” cable replacement. Choices for connecting to the enterprise network are limited, and include WMTS and the ISM band. Short range cable replacement applies to wireless sensors in body area networks (BANs) and are limited to ISM and (due to a recent FCC announcement) MICS — or the Medical Implant Communications Service.

For connecting to the enterprise network using the ISM band your options are 802.15.4/ZigBee, the high powered Class I version of Bluetooth,  and components based on the now defunct standard HomeRF. Both ZigBee and Bluetooth have specific strengths and weaknesses that must be carefully matched to effective requirements. (Hint: eliciting good wireless requirements for those just getting into wireles is difficult.) While commercial products based on the HomeRF standard haven’t been manufactured for years, it is likely possible to license the technology or  even components, for the right price. Finally, you can roll your own custom or semi-custom protocol (a perennial favorite among some engineers).

Regardless of what wireless technology you choose, you must have good requirements, and do a good job matching technology with requirements to pick the best tech. Most wireless medical devices are deployed enterprise wide, so your Wi-Fi alternative must be cost competitive with the added burden of a duplicate enterprise-wide wireless network.

Presently, every dollar invested in improving the performance of the enterprise Wi-Fi network (whether driven by wireless medical device adoption, wireless VoIP phones, or COWs) is justified across multiple uses. A dedicated wireless medical device infrastructure — that’s not dedicated to all of a hospital’s medical devices, just one device type from one vendor — has to be cost justified based on that one medical device application.

Oh, and you still have to meet the three basic requirements for reliable wireless communications (there’s no getting out of that). This means having the human resources to provide the service and support necessary to develop, install and support wireless devices. These costs may be less when deploying a dedicated wireless infrastructure, but probably not a lot less.

Wireless sensors are really a short range cable replacement application. Wi-Fi is not an option here. Many of the issues discussed above are applicable to wireless sensors, and there are also many specialized issues and requirements. Unlike wireless enterprise networking applications, wireless sensor implementations vary considerably. Options range from commercially available proprietary radios like the ANT, to “science project” technology like NASA‘s Radio Frequency Health Node wireless sensor system, and academic projects like Matt Welsh’s CodeBlue.

Can We Fix Wireless in Health Care?

Hmm, I don’t think it’s broken. Do we know everything? No. Are we figuring some things out as we go? Sure, especially as technology evolves. Is there anything that indicates that existing technology is incapabile of supporting wireless medical devices, or is inherently unsafe? No. Are there some who have this mostly or completely figured out? Yes, on both the vendor and provider sides.

This is just like designing a medical device. There is no “one way” or even a “best way” to implement wireless. Like other areas of connectivity, the phrase, “you don’t know what you don’t know,” applies to wireless — requirements, enablement, deployment, management and support.

If you’re looking for something to chew on, be sure to check out the FDA’s Draft Guidance for Industry and FDA Staff – Radio-Frequency Wireless Technology in Medical Devices. If you’re a hospital biomed or IT network person, you should read this document too.

If you need help, call a connectologist.

The announcement started with some bragging. Apple has sold more than 30 million iPhones and iPod Touches since they were introduced in 2007 to the end of 2008. The market for third party applications, distributed through Apple’s App Store has likewise been phenomenally successful. With this new announcement, Apple signaled their intent to strengthen their hold on games and other consumer apps, and extend into vertical markets like the enterprise and health care.

There are many new features in the 3.0 iPhone software, but the announcement was really more about Apple’s new SDK  for the iPhone. The SDK is what third party developers use to design accessories and software for the iPhone. This new SDK exposes for the first time, about a thousand software features (what Apple calls APIs, for application programing interfaces) that can now be used by third party developers.

Key Features for Health Care

External Accessories:  Apple is going to allow external accessories to interface to the iPhone through a new framework called External Accessories (see 16:12 in the Apple announcement video). External hardware devices will be able to integrate with the iPhone via the dock connector or wirelessly over Bluetooth. This connectivity will support many of the standard protocols implemented on the iPhone in addition to proprietary protocols developed and implemented by third party accessory developers. At 17:40 in the video, Apple calls out medical devices as a target application for their External Accessories APIs, showing a blood pressure cuff.

An important external accessory with strong market demand in health care is the bar code reader. According to Trey Lauderdale, vice president of innovation at Voalte, Inc., “Lots of hospitals use barcodes and many ask us, can I use the iPhone to read barcodes? Now with the EA framework barcode readers can be integrated with the iPhone over Bluetooth or cable.”

Game Kit: A potential hidden gem for health care in the new SDK is a new framework called Game Kit. This framework includes a capability called a voice chat service — effectively wireless VoIP. This allows developers to establish a chat service between 2 points using Bluetooth or WiFi. While some may think this a threat to mobile carrier’s revenue models, a more important market for the iPhone is enterprise wireless VoIP.

Writing data oriented workflow applications for existing wireless VoIP handsets is time consuming and expensive. Each phone manufacturer has different sized displays, many of them very small. And each vendor has their own proprietary Java API for implementing apps on their phones. This means a third party vendor has to effectively rewrite a handset application (including user interface design) for each different phone manufacturer they want to support. There are several major vendors in health care: Cisco, Ascom, Spectralink/Polycom, Vocera, and Avaya. If the iPhone gets both traction in health care with applications, and Apple successfully enters the enterprise wireless VoIP market, they could be a real force in health care.

Voice Recording: There are currently numerous audio recording applications sold through the App Store. These are stand alone apps that do all the heavy lifting of acquiring, storing and managing voice recordings on the iPhone. In the new SDK, Apple makes it quick and easy for app developers to leverage the iPhone’s resources to much of this heavy lifting to add a voice/audio recording feature to any app. Given the interrupt-driven environment at the point of care, voice notes could be a real boon for busy caregivers.  With integration to platforms like Nuance, dictation and Vocera-like workflow automation features could also be more readily available to developers.

Potential iPhone Use Models

There are 3 ways to leverage the iPhone at the point of care, each targeting different needs, productization strategies, and markets. These use models are: virtualized medical device, sensor gateway, and point of care computing device.

Virtualized medical device:  The blood pressure example shown at the Apple introduction event is a virtualized medical device. Increasingly seen in the physician office market, virtualized medical devices shrink the embedded device down to its bare essentials and move the raw data produced by the sensor to a general purpose computing device, typically a laptop, for final processing and analysis. The sensor includes required front end electronics for first pass signal processing and amplification. The connection to the computer is done via cable or a wireless cable replacement like Bluetooth.

This link shows a conventional purpose-built embedded system spirometer, and here you can see a virtualized spirometer. Which type has lower product development and manufacturing costs? Which is probably easier to use? Intel has a white paper that offers a great explanation of virtualized medical devices, using multi parameter physiological patient monitors as an example (pdf white paper). Applying this use model to the iPhone is easy, just write the software for the iPhone instead of a laptop, PC or PDA.

The regulated medical device in this use model has 3 main components: the sensor package, software that is installed on the computer, and an off the shelf computer. Currently the vendor who makes the sensor writes the software, and these constitute the lion’s share of the regulated medical device. The computer is also part of the regulated medical device, but is utilized as an off the shelf component. A Dell laptop, or Apple iPhone aren’t regulated by the FDA or equivalent international agencies. Manufacturers providing off the shelf products used in regulated medical devices often have hoops to jump through, but these are specified by their medical device customers and how they choose to split the regulatory burden between them and their suppliers. (If you’re new to FDA regulations see this post, Facing FDA Regulations for the First Time).

A defining piece of medical device regulations are the marketing claims or intended use for the device. Apple’s description (intended use) of their prototypical blood pressure device started out as an unregulated device. This is one used solely by the patient for their own use for health and wellness (aka the fitness market). As soon as the Apple presenter mentioned that, “users could send their blood pressure data to a physician,” the system became a medical device — in this case, because the data is used for diagnosis.

The markets for virtualized medical devices are currently those with a high sensitivity to price and frequently lack specially trained techs (and thus need to be easier to use). There is nothing preventing virtualized medical devices from entering the acute care market, i.e., hospitals. This product strategy can also be extended to the Healthcare Unbound remote monitoring market. Such devices can and do find use by home health agencies and patients. The patient segment for an iPhone enabled medical device is almost all self-pay (there is no reimbursement for fancy automated solutions like this). Since these remote monitoring markets are extremely price sensitive, virtualized devices offer real potential.

Sensor Gateway:  Many use cases include one or more sensors that acquire patient data. This data must be consolidated and then sent on to an application that stores and manages the data. This use model differs from the virtualized device in that the sensor produces data in its final form, ready to be used by the patient or clinician, while the data from a sensor in a virtualized device must be further processed and analyzed before providing usable clinical data. For more on this check out Continua Health Alliance’s vision video.

The sensor gateway example was presented in the Apple event, a blood glucose meter the One Touch from LifeScan (go to 43:25 in the Apple video to see the demo). LifeScan was one of a small group of companies that were provided access to the SDK two weeks in advance of the announcement. Over that time, these early users implemented “proof of concept” applications. Dave Detmers, communications director at LifeScan told me, “Our goal is to make diabetes management as seamless as possible for patients, so that it’s easy to integrate into patient’s lifestyles.” The One Touch demo was a proof of concept showing the potential capabilities offered by the iPhone (which were pretty impressive). While LifeScan plans to have an offering for the iPhone in the future, Dave noted that, “the combination of the One Touch glucometer, software and the iPhone represent what the FDA defines as a medical device.” Further, he noted that an application of this kind would include electronic patient identifiable data, and would have to meet HIPAA requirements.

The One Touch demo represents a gateway dedicated to the sensor made by the vendor. A different business strategy for the gateway use model would have a company creating a multipurpose gateway intended to support sensors from different companies. Other companies like Nokia and Motorola are looking at this model for the remote monitoring. Chronic disease management is dependent on patient’s self management. Chronic diseases like COPD, CHF, and diabetes, need data from multiple sources: diet information, weight, blood pressure, SpO2, and other parameters.

As solution providers struggle to develop and refine systems for chronic disease management, reimbursement for most of these technology solutions has yet to appear. This means that for the foreseeable future, systems of this type will be bought and paid for by patients rather than insurance companies, thus limiting market potential.

Point of Care Computing Device:  The final use model for the iPhone is as a point of care computing device. Based on this latest Apple announcement, the iPhone could replace PDAs, tablet computers and wireless VoIP handsets. I’ve been ranting about the many short commings of point of care computing devices for quite some time. Here’s what I think is needed for the perfect point of care device. There have been many attempts, the C5 mobile clinical assistant, Philips ProScribe tablet, the Emano Tec MedTab, and the OQO UMPC. I’ve even looked at wireless VoIP handsets and PDAs. Both the market and I are still looking.

Besides the obvous limitations (insufficient battery life, small hard to read displays, size and weight), perhaps the biggest barrier for point of care compuating devices is selecting the right applications and designing a good user interface. Charting in the EMR is not a good application for a hand held device (this is why C5 tablets ride around as computers on wheels). But messaging like alarm notification is a great application, as is voice, and certain workflow automation applications like patient flow and perhaps meds administration.

There are no FDA regulatory requirements when an iPhone is used as a general purpose computing platform for unregulated software. An iPhone used for alarm notification meets the definition of a medical device. In fact the FDA has recently published a rule calling out alarm notification systems for regulatory enforcement. Any application that connects to a medical device using the announced External Accessory framework, would likely be regulated. But for the most part, this point of care computing is an unregulated market opportunity.

While not perfect, serveral features make the iPhone attractive for the point of care. Regulatory requirements and the way vendors design their products will require some degree of device duplication at the point of care. So far this has impacted PDAs and barcode readers. And over time, this duplication will likely subside and may even disappear. Until that happy day, users need devices that are light weight and easy to carry. Infection control and fluid ingress is always a concern with devices sporting keyboards. The iPhone’s touchscreen eliminates cracks and crevases where infections can hide on other devices. And the relatively large high resolution display (and underlying software tools) make designing a user interface that’s easy on today’s caregivers’ eyes.

But the iPhone is not perfect. The thousands of third party products designed for the iPhone were mentioned in the Apple announcement. Lauderdale with Voalte has found these vendors to be very accomodating in meeting the special needs of health care. “Case manufacturers have been very responsive in helping us improve the iPhone’s ability to withstand repeated drops, and stand up to harsh hospital disinfectants.” Battery life is addessed two ways, writing software to conserve power and through the use of external batter packs. Projects are underway to extend battery life to 12 hours and/or provide easily swappable battery packs with something closer to an 8 hour battery life.

At the HIMSS 09 exhibition next month, I expect to see at least one vendor with products based on the iPhone. Health care is not just another vertical where you can dress up a horizontal market product with some marketing and “partners” and watch the sales roll in. The core mission of health care is diagnosing and treating people — saving lives. If you sell light bulbs, that’s not an issue. If you’re targeting clinicians and the point of care, you’re going to end up having to meet some regulatory requirements and do some engineering to fine tune your product.

The iPhone’s ultimate success in health care will depend on how effectively Apple supports this vertical market and the smart developers and entrepreneaurs attracted to the iPhone. Hospitals alone could add several million additional iPhones to Apple’s sales, business they otherwise would not get.

UPDATE: Blog mobihealthnews has an interview with Dave Detmers of LifeScan, who I quote above. The last paragraph is the most interesting. At Chilmark Research, see John Moore’s consumer oriented slant on the iPhone 3.0 announcement.

UPDATE: Here’s an interesting discussion of iPhone apps as promotional vehicles. Remember the metal gestational age wheel from Corometrics? Useful, durable, and a pervasive branding message found in virtually every labor and delivery department. There are many valuable applications that could prove invaluable to caregivers and clinicians.