HIMSS 09 Preview
Everything’s almost set for this year’s HIMSS conference in Chicago. News of exhibitors, big and small, that have chosen to pull out of the exhibition has gotten a lot of play. Of the vendors that have pulled out that I follow, all are coming to the conference as attendees. HIMSS reports that the number of total exhibitors is up a bit over last year. So it looks like HIMSS remains as relevant as ever — not that I had any doubts.
As always, I’ll be blogging from the conference, and writing a HIMSS wrap-up story for Canon Communications. If you’re interested in a story for your publication, let me know (contact info here).
Some Interesting Exhibitors
There seem to be an increase in new and interesting vendors this year. Just a few of the exhibitors that I’ll be seeing for the first time include: point of care communications vendor Voalte, wireless sensor company KAI Sensors — wireless and no-contact sounds intriguing, CaraFlow with an interesting in-room nurse automation solution, workflow automation vendor Mobile Matrix, some new distributed antenna system (DAS) vendors (Tri-Power, Cellular Specialties, and Cell Antenna – okay they only sort of qualify as a DAS, but interesting none the less), and a bunch of new wireless networking vendors — from services (Scientel Wireless, Wantering WiFi and Presidio Networked Solutions) to infrastructure (Aerohive Networks, Fatpipe Networks and Ruckus Wireless).
If I’ve missed anyone you think I should check out, you can drop me a line (my contact info is on the About page).
Meetings & Communication During the Conference
If you want to meet up at HIMSS, you have two options. First, you can look at my calendar and request a meeting in advance. Be sure to note the timezones displayed on the left when proposing times — on my calendar page, both Pacific (where I live) and Central times (the meeting location) are shown. Confirm which timezones are displayed on your page (you may see Central and your own time zone displayed).
Can We Fix Wireless in Health Care?
Awareness is growing about the challenges of developing and maintaining safe and effective wireless medical devices. What with IEC80001 moving forward (due to be finalized next year) and the recent series of wireless medical device workshops, people in hospitals and among vendors are asking more of the hard questions about wireless. Amongst the turmoil, participants are jostling for position. This post looks at common problems with Wi-Fi, a report from U.K. alliance ERBI, and some alternatives to Wi-Fi.
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.
Apple Targets Health Care with iPhone 3.0 OS
On March 17, Apple announced iPhone OS (operating system) 3.0 software and a new iPhone software development kit (SDK) for developers. The 3.0 software expected to be released this summer. The SDK is in beta form and can be downloaded now. (You can watch the event here. I got better performance after doing a save-as of the video and playing it in QuickTime rather than the browser.) For a general overview of the announcement, I recommend Gizmodo’s coverage, here and here. Gizmodo also has a nice overview of the top 5 smart phone platforms (iPhone, Android, Windows Mobile, Blackberry, Palm Pre) here. Also note that the iPod Touch offers most all the functionality of the iPhone, except for mobile phone features. The iPod Touch would make an attractive alternative to the iPhone (smaller, less expensive) in many health care applications.
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
Facing FDA Regulations for the First Time
A growing number of organizations — large and small, within health care and outside of it — are facing regulation by the FDA. Those potentially affected fall into 3 camps. All of the examples I’m going to talk about deal with multi vendor systems (or systems using lots of off the shelf components) that become the regulated medical device.
Just what is a medical device? The legal definition of a medical 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, [i.e., a drug]
- 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.
According to the New Oxford American Dictionary, a contrivance is “a thing that is created skillfully and inventively to serve a particular purpose.” So a medical device can be made out of anything, as long as it falls under at least one of the three bullets above.
Who Is Impacted?
Requirements, Trade-offs and Sales Objections
This is another installment of a series on selling connectivity. You can read the first installment, with links to subsequent posts, here.
There is no one product that best fits every customer’s requirements, yet the goal of product management is to develop product requirements that addresses the greatest portion of the market possible. Of course, it is neigh impossible to create a solution that is optimal for every customer. This raises a couple interesting questions. For any given project, how much of the addressable market’s requirements can be met? How are such trade-offs made, and what is the role of sales in all this?
Security As a Requirements Trade-off Example
A good frame of reference for requirements trade-offs is wireless security for medical devices. There is a plethora of security standards, and the target is always moving; new standards are implemented, some of which have varying degrees of reverse compatibility with previous generations of hardware, and some require upgrades or replacements to work. Likewise, different markets have different requirements. For example health care has HIPAA, the credit card industry has the PCI data security standard, and other industries have their own requirements. Next, individual customers make security choices based on the infrastructure installed, how current their infrastructure is (is it currently sold by the vendor, is no longer sold but still supported, or is it discontinued), and what security standards they chose to adopt and enforce (sometimes chosen capriciously, often enforced vociferously) in their enterprise.
Like the workflow automation that wireless connectivity enables and the necessary security required to support it, there is a finite degree of requirements variability that can be practically implemented — systems can’t be everything to everyone. Creating a product that address 100 percent of the target market is virtually impossible. Trade-offs must be made so that a product can also reach cost of goods, design budget and time to market objectives.
