Wanted: Rocket Scientist
A friend passed along this link to a job opening today. The reason I’m bringing it up is because I think it represents a job of increasing importance in health care – in both provider organizations and vendors.
The position requires, “a Bachelor’s degree in Biomedical or Clinical Engineering or related field and a minimum of 5 years of experience in clinical engineering and information systems. Master’s degree is preferred.” Here’s the description (emphasis is mine):
Successful applicants will possess previous project management and planning experience, strong communication and team building skills across functional areas. Following certifications are preferred: Certified Clinical Engineering (CCE); Certified Information Systems Security professional (CISSP) by (ISC)2; Cisco Certified Network Associate (CCNA) or Network Professional (CCNP); Microsoft Certified Systems Administrator (MCSA) or Engineer (MCSE).
Job Duties:
- Maintains current inventory of networked and integrated medical systems (including catalog of services, features, interconnections).
- Coordinates security management process including risk and vulnerability analysis and related documentation associated with interconnected/integrated medical systems.
- Coordinates with stakeholders a process to prioritize, develop and implement plan to manage mitigate identifies risks associated with interconnected/integrated medical systems by applying appropriate administrative, physical & technical safeguards.
- Maintains the integrity of FDA approval for interconnected/integrated medical systems.
- Works with stakeholders to insure effective deployment, integration, and support of new medical systems into legacy systems and non-medical elements of the organizations information structure.
- Identifies and manages appropriate software upgrades, security patches and anti-virus installs for interconnected/integrated medical systems according to industry best practices.
- Conducts Root Cause Analysis and Failure Mode Effects Analysis on incidents involving integrated medical systems and reports finings to appropriate stakeholders for follow up action.
- Monitors and adopts industry “Best Practices†to insure integrity, availability and confidentiality of data maintained and transmitted across interconnected and integrated medical systems.
- Educates stakeholders on security and other implications associated with the proliferation of interconnected and integrated medical technologies.
Wow. This is the first hospital job description that I’ve seen for a hard core connectologist. Note that the position is in the Clinical Engineering department, not IT. From experience, I can tell you that the third and fourth bullets above will be the most difficult of the duties listed. The only thing missing from the above requirements is any RF experience; they must have someone else who already covers wireless “networked and integrated medical systems.”
Someone with this skill set could easily work as a medical device or HIT product manager on the vendor side. If you’re interested in the position, I know the guy you’d be working for – he’s a nice guy. And between you and me, the position is easily worth $100,000+.
People with this kind of experience are few and far between – on both the hospital and vendor side – but I predict that more and more of these positions will be opening up in the future. If you’re looking for a connectologist, give me a call, I know quite a few.
Pictured right is a networked and integrated medical system at the hiring institution, a robotic operating room at Vanderbilt University Medical Center.
UPDATE: Fellow connectologist Dave Hoglund makes the following observations:
Tim, agree with you. However, what they are asking for (oh yes don’t forget RF), has a going rate of $150,000 a year, minimum. They would be better to outsource, as I do not think Clinical Engineering departments are financed to support this type of payroll. All the more reason to “inquire”, what is their business plan and requirements…hmm, strategic planning is perhaps what is needed.
Connectivity represents a mix of skills and experience that are in short supply (connectologists are brilliant and good looking too). Connectivity also pulls across traditional markets and employee categories. A vendor example would be the difference between a traditional medical device field service rep and one who can also do network integration. The person with network engineering skills throws the medical device service department’s pay ranges completely out of wack – just like the job above will do to hospital biomed departments.
Outsourcing some of this work could lower both the requirements for the position and the resulting pay required to, you know, actually get it filled. An alternative would be to push some of this onto vendors. Hospitals who don’t want to find themselves in the position of systems integrators of “networked and integrated medical systems” should negotiate those responsibilities up front – I know of one very large provider that’s doing this, and more are following suit.
Strategic planning can also help. Like most problems after the sale, many connectivity related issues are best resolved before the purchase order is cut. For this to really work though, you need to know what you’re doing – and with hospitals just getting into connectivity in a serious way (not to mention RFID, and anything that impacts the point of care) you hire the experience at a premium or rent it as needed.
Here’s one final thought. The transition from standalone embedded system medical devices to connected and interoperable medical device systems is just that, a transition. This transition necessitates modest but basic changes across provider and vendor organizations. In my experience, once the connectivity transition is complete, the same organization picks up and carries on without the need for specialized connectologists – the appropriate connectivity knowledge gets absorbed into the organization. The best connectologists can both do a job like the one above (or product manager on the vendor side) and help guide the organization’s changes in other areas as well. Facilitating this transition, including business planning, product strategy, sales/marketing, and human resources issues, is a top candidate for outsourcing.
The Future of Wireless SpO2 Monitors
There's a huge, mostly unmet, market requirement for low acuity patient monitoring. Much of this is driven by JCAHO's recent focus on pain management. A lot of hospitals were receiving poor patient evaluations regarding pain management on general nusing units. In response, hospitals have increased their administration of pain meds; but when you increase therapies you need to increase surveillance to ensure patient safety. Unfortunately in today's staffing environment (legally mandated nursing ratios aside) hospitals are not in a position to add more nurses to provide that additional surveillance. As a consequence there have been numerous sentinel and adverse events as a result of a failure to rescue.
Some hospitals have wisely decided that increased patient monitoring is the best way to increase surveillance for patients on some pain meds. And some of those hospitals want to provide this monitoring using SpO2. Unfortunately, current standalone SpO2 monitoring systems are not up to the challenge. Most devices offer no connectivity at all – just standalone devices with local alarms. Vendors with networked solutions, like Nellcor, have wired solutions that don't work well outside critical care areas where patients are moving in bed, going to the bathroom and walking around the units. Masimo has responded to this need by OEMing the MicroPaq and Acuity central station from Welch Allyn.
When hospitals think SpO2-only monitoring they're thinking “lower cost” and “easier to use” when compared to telemetry and patient worn monitors. They are wrong – currently available networked SpO2 systems with central stations are not significantly less expensive that ECG/SpO2 solutions. The resulting proliferation of different device workflows and duplicate central stations is a great example of what's wrong with proprietary end-to-end monitoring systems – a topic that we will have to save for another time.
On the Biomed listserv Douglas Back of Medical Concepts posted a comment about a wireless SpO2 R&D project that a vendor told him about. He was not impressed:
Here's my reply:
SpO2 monitors that plug into a wired network are fine for gorked out patients, but a hassle for patients on a med/surg unit. And what do you do when they ambulate? They can carry the monitor and rely on the local alarm, or more likely go off monitor until they return to bed – neither is an ideal solution.
When these devices go wireless, there are a couple of things to look for. First and foremost are all those false/positive alarms that many SpO2 monitors generate. Managing this problem is not really that tough, but it will add to the cost of a wireless solution, so look for some (most) vendors to “round corners” here. The other issue will be workflow – will the overall system (plus other devices on your units, and current policies and procedures) actually improve patient safety and caregiver productivity? This is a less simple requirement to meet, and must be understood and built into the system from the ground up.
Douglas, your concerns are not unfounded. Historically, the first generation of wireless devices is pretty lousy. However, I do expect to see good things from Masimo. [No, they're not a client - but they do have some key people who know what they're doing, and a load of cash from Nellcor.]
Douglas' response:
A reusable Spo2 probe with a cable attached will run average $ 250.00 each and a disposable Spo2 probe will run $ 6.00 each. You can replace it. If you had a probe with a built in transmitter you could be looking at a higher unit cost if you had to replace it. They would have to be dedicated to each monitor. You would have to keep spares. It is not like just replacing a Spo2 probe to a telemetry box.
This is the technology they are talking about releasing.
And my reply…
I would expect most first generation wireless SpO2 to have a WiFi radio in the monitor (with a cable attached sensor) that talks directly to the network – sort of like a patient worn monitor. The earlier telemetry/SpO2 example is like this, only smaller because SpO2 vendors don't do ECG (although maybe they should). Then all of your existing sensors would plug into the new monitor. Not having to rev the sensor assembly keeps the R&D project scope reasonable too.
Very few medical device vendors understand the importance of establishing patient context (let alone how to do it) in networked devices. If you add the complexity of associating one or more patient-connected sensors to a gateway (that could be in proximity with other gateway/sensors on other patients) the complexity goes up exponentially.
Most early efforts from medical device vendors who design world class “black box” embedded systems will have two likely outcomes. First, in an effort to minimize R&D cost and complexity, they will push tasks onto the user that should be done by the system – this will result in poor workflow. The other likely outcome is a tortured implementation of some poor off the shelf technology – tortured in that there will be little or no regard for a complete implementation of the technology that facilitates systems integration with your hospital IT infrastructure. An example of this might be network connectivity that can't be routed – thus requiring all devices connect to the same subnet or dedicated VLAN.
Most vendors don't realize that once they connect their products to a general purpose local area network they aren't in the “embedded systems” business anymore. Sadly, this is as much a problem for you guys as it is the hapless vendor who tries to support you.
Wireless sensors are the next big thing in patient monitoring – I've got a category of posts on my blog for wireless sensors. Here are two academic projects that have developed systems using wireless sensors:, the CodeBlue project at Harvard, and Aid-N at Johns Hopkins.
Pictured right is an old school Masimo SpO2 monitoring system.
Cardinal Health to Acquire Care Fusion
Cardinal Health today announced that they are acquiring Care Fusion. While terms of the deal were not announced, it highlights a number of interesting things going on in the industry. According to some folks I talked to at Cardinal, the purchase is intended to round out barcode validation at point of care, to support EMAR and other core Cardinal offerings.
Care Fusion has raised its profile in the industry lately with a VA contract for installing their system into 170 VA hospitals and 500 outpatient clinics. They're also installed in 50 hospitals – that's 1% of U.S. hospitals.
GE Healthcare must be gnashing their teeth as this appears to be the second time Cardinal Health has beaten them to the punch – the first was Cardinal's purchase of Alaris. GE Healthcare has been distributing Care Fusion for some time as a vital signs monitoring connectivity solution. GE customers who bought new Dynamaps with IrDA infrared data ports to use with Care Fusion might be gnashing their teeth as well.
IntelliDOT who recently won a big Amerinet GPO contract should be encouraged by the acquisition. IntelliDOT just closed a $13 million round of Series C funding, and announced some big sales recently. IntelliDOT is big on electronic meds admin, but lacks data acquisition support. Their proprietary wireless handheld has managed to squeeze 14 hours of battery life (a first!) by cutting all but the most necessary features – this will remain a single-task device until it's replaced by a general purpose point of care device that really works.
Another point of care vendor, Sensitron also thinks the Care Fusion acquisition is driven by meds admin rather than connectivity. Sensitron targets medical device connectivity workflows and EMR integration, using general purpose computing devices (mostly COWs) at the point of care. Sensitron is also getting market traction, Datascope OEMs the Sensitron solution for their vital signs data acquisition – which in old school fashion they did not mention when they announced the feature.
Pictured right is a Care Fusion shot of meds administration.
UPDATE: Rich Kosmala from Datascope sent in the following correction:
dated October 18th titled “Cardinal Health to Acquire Care Fusion.” The link at the end of this
article points to our Gateway product, which was developed by Datascope and has
nothing to do with Sensitron. The product that uses Sensitron's technology is
the AccuNet, and the link to that press release is here.
In addition, our relationship with
Sensitron was issued in a joint statement which can be found at the following
link (here).
Rich, thanks for the correction. I also want to say that I was not suggesting that Datascope was trying to dissemble in not disclosing their relationship with Sensitron in their press release – embedded systems vendors don't usually brag on technology like CPUs or LCD displays they use in their devices. When it comes to connectivity though, there is usually a greater degree of interest on the part of buyers and vendors. The vendor for embedded WiFi radios is commonly disclosed (although not in product release press releases).
Leveraging a third party for connectivity is a big deal and almost always a competitive advantage – both in getting to market and from the buyer's perspective. Unlike the aerospace industry where outsourcing and OEM deals involving high-reliability systems are actively promoted, medical device vendors tend to be shy about these types of relationships. Here's another example from Welch Allyn and their partnering with Wellogic.
What Makes The Perfect Mobile Computing Device?
What with all the posts this week on point of care devices and cell phones, I thought I’d do something besides complain about lousy point of care computing devices. So here are my must-have features for a point of care device that I think hospitals would actually buy. First let’s define the type of device.
There are currently two device classes required at the point of care. A nurse carried device supports urgent communications, access to frequently used data, support basic documentation chores, and nothing that would be hampered by a QVGA display and no keyboard. The other device class is a COW (computer on wheeles) that’s used for everything else, plus any applications that require a 1280×1024 display, mouse and/or keyboard.
The whole COW thing has gotten solid adoption with a number of good solutions on the market. The big issue is how blurred things are between medical devices and COWS. Solutions for vital signs data acquisition are all over the map – Sensitron and Care Fusion (and their OEM customers), you have vendor solutions like Welch Allyn’s, and then there’s Stinger Medical where the cart and the medical device are one. What a mess.
The nurse carried device is what gets me excited. So here’s what users need:
- Something they can drop – repeatedly
- Something that’s splash resistant and can be wipped with common hospital disinfectants
- A battery that lasts a 12 hour shift (although the market would probably settle for 8 hours if the battery could be easily changed)
- Something not much bigger than a smart phone
- A device that does VoIP and data (who wants to carry a phone and a PDA?)
- A fingerprint swipe bar for easy user authentication
- Wireless – both 802.11a/b/g and Bluetooth (for the VoIP phone feature)
- Security that meets HIPAA requirements
- Something that will support more than one vendor’s application
For vendors the ultimate includes:
- A standard operating system implementation so they don’t have to write code for specific vendor’s devices
- A good development environment – system level stuff for communications, watchdogs, user interface, scheduling, interrupts, queuing, etc.
- Standards and tools that off-load some of the heavy lifting at the application layer – industry or de facto standards for communications between HIT apps and other medical devices
- Low cost of goods
Most hospital automation problems encountered after go-live could have been solved before the sale. So if you’re thinking of a solution that includes a nurse carried point of care computing device (is there a smart acronym in there somewhere?) think beyond your current project. Think way beyond, or you’ll be buying replacements or duplicates for more than just the PoC computing devices.
Good luck! Pictured right is my current favorite, the OQO pocketable Windows PC. OQO has just lowered the price of their device to $1,199 – while not as droppable and wipeable as a Hand Held Products Dolphin or Symbol’s PPT 8800, the OQO is a serious contender.
UPDATE: Welcome Hand Held Products readers. Be sure to check out other posts by clicking the Weblog tab up top, or selecting from the categories in the left hand column. Enjoy!
Cell Phones in Hospitals – Really, It's Okay
Advance for Nurse Practitioners has a story on cell phone interference. The bottom line: cell phones are pretty okay, just keep them 3 feet away from a medical device.
Actually, it's not really that simple. The story goes on to recount the following horrors:
You don't need to imagine. Read “Don't Answer That Cell Phone!” in the June 2002 edition of the journal Nursing.
That article, penned by FDA officials, recounts how an ICU patient was
receiving epinephrine through an infusion pump when a visitor nearby
answered her cell phone. The pump suddenly increased the rate of its
drip, giving the patient “an unintended bolus of medication that led to
epinephrine toxicity.”
FDA officials have also received reports of interference affecting
powered wheel chairs, monitoring equipment, hemodialysis devices and
cardiac devices.
As recently as 2004, a study concluded that cell phones “placed in
close proximity to some commercially available intensive care
ventilators can cause malfunctions, including irrecoverable cessation
of ventilation.” Robert Kacmarek and colleagues found that
EMI is most likely to occur if a cellular phone is less than 30 cm from
a mechanical ventilator and is ringing.
The article goes on to describe all the new wireless technologies that are invading hospitals. The real bottom line is that there are many sources for electromagnetic interference. What's critical is that hospital staff is trained to recognize possible interference and know what to do in response.
Cell phones are here to stay, the genie's out of the bottle. Many hospitals have enacted policies that cell phones can be used anywhere as long as they stay 3 feet from a critical medical device. I've heard of many hospitals “holding the line” on cell phones, and some losening restrictions, but I've yet to hear about a hospital giving up more liberal policies for those that partially or completely ban cell phones.
UPDATE: Here's another cell-phone-in-hospitals story from the UK that says, “Hospital cell phone ban unnecessary” – previous story here.
