Tim Gee Affiliates with Santa Rosa Consulting for Provider Consulting
This month marks the end my 5th year as an independent consultant. Over that time, I’ve had the opportunity to complete many great projects for a variety of clients, large and small. A basic objective has always been to provide services to both manufacturers and health care providers. The general knowledge gained — both current trends and the depths of complex issues — from working with providers has always benefited my manufacturer clients, the same holds true for providers based on the perspectives gained working for manufacturers.
While I’ve done projects for some great health care providers (Providence, RWJUH, Spectrum and Partners), most of my business has been on the vendor side. This past fall Marilyn Hailperin of Santa Rosa Consulting contacted me about working for their firm. We have entered into an agreement where all of my consulting for health care providers is done through Santa Rosa, while I continue to pursue consulting business with manufacturers as Medical Connectivity Consulting.
Santa Rosa Consulting was founded this year by Richard Helppie, the founder, Chair and CEO for Superior Consultant. One of the hospital consulting market segments Santa Rosa is targeting is point of care workflow automation and medical device integration. Here’s more from the press release:
As part of the Santa Rosa team, Mr. Gee will provide consulting services related to point-of-care technology strategy development, clinical workflow optimization, technology vendor selection, risk management of converged medical device/enterprise networks, and support for Santa Rosa’s PCDI [Patient Care Device Integration] implementation team.
Santa Rosa Associate Partner and National Practice Director for PCDI, Marilyn Hailperin, says, “We are pleased to have someone of Tim’s caliber on our team. He has long been an advocate and recognized authority on medical device connectivity. Tim brings essential real-world knowledge and expertise to our clients to maximize their investment in point-of-care technology, achieve the benefits of patient care device integration with information systems, and attain “meaningful use” certification with respect to medical device interoperability.”
While Santa Rosa gets to use me in their provider practice, my provider clients also benefit in a number of ways:
Market Trends Series #3: Shift from Dept to Enterprise Focus
From what I have observed over many years, Hospitals have historically approached medical device connectivity projects as a tactical issue to be dealt with. Up until relatively recently, technology alone could be used to solve the connectivity issue (i.e. getting data from point A to point B) with little to no negative impact on clinical workflow. Further, the scope of connectivity projects has been mainly departmentally focused and deployments have been relatively basic. By basic, I refer to projects that have focused on connecting one or two bedside medical devices to a single CIS application or EMR.
Evidence of all of this can be found by looking back at the past 10 or more years and examining typical implementations of biomedical device connectivity to information systems.
• Most implementations up to now have been in very specific care areas such as the ICU and OR.
• Most implementations are relatively small in scope, often in the area of about 20 to 50 beds. Incidentally, for most US hospitals this happens to be about the same number of ICU beds per facility.
• In the ICU, the key devices that are interfaced are typically multi-parameter patient monitors and sometimes ventilators – but vents to a much lesser degree than monitors.
• In the OR, the key devices are typically patient monitors and anesthesia/gas machines.
• Outside of high-acuity care areas, in the general ward there are some limited niche interface solutions for mobile vital signs data capture. Many of these are only semi-automated in terms of truly automating both the data capture and the clinical workflow.
• For virtually all of these implementations, the data collected from the devices is identified though a mapping of the medical device’s location – that is a bed or room location identifier is used to associate the data and alarms.
• The device workflow – that is the steps clinicians are required to perform at the bedside to interact with devices to establish connectivity – has been limited. This is because most of the devices are actually fixed to the location – i.e. the monitors in ICU are mounted to the wall and data is interface via a networked gateway with outbound HL7. Therefore few if any steps are required by clinicians because the devices are permanently tethered to a local PC or terminal server that facilitates the data collection.
But as discussed in some of my previous market trends postings – requirements for connectivity have been changing and in some not so subtle ways. Many hospitals are
Medical Device System Network Install Issues
Last week there was an interesting discussion on the Biomed Listserv about network installation for patient monitoring systems. Emphasis highlighting key issues and best practices are mine. The discussion started with a question from Scott Skinner:
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’s All About Workflow
Okay, it’s not all about workflow, just mostly, as you’ll see.
A while back Ann Farrell was nice enough to bring an interesting paper to my attention. Titled, “Workarounds to Barcode Medication Administration Systems: Their Occurrences, Causes, and Threats to Patient Safety” the paper is a fascinating read for several reasons. The authors studied barcode medication administration systems (BCMA) at 5 hospitals, and identified 15 types of workarounds and 31 types of causes of workarounds. This paper provides the most detailed and comprehensive description of product and implementation shortcomings centered on the point of care that I’ve ever seen. It’s devastating. Really.
So what’s this got to do with medical device connectivity? Two words: workflow and barcodes. Medical device connectivity is the automation of workflow through the integration of medical devices and information system. Likewise, BCMA is the automation of workflow through the use of auto ID (barcode labels and scanners) and information systems. With connectivity, attention centers on the connection; with BCMA, attention centers on the barcoding. Where should the attention be focused? Workflow.
Workflow is the Rodney Dangerfield of point of care systems. Everyone, manufacturers and clinicians both, focus on the tangible stuff, like serial cables and network connectivity or barcodes and readers. The invisible stuff, like water is to fish, is the workflow that occurs at the point of care. There are two key workflow data points that are required for a well designed product. First is capturing the complete workflow process in which the technology solution is to be used.
Framing the workflow should extend beyond the scope of the actual product, so that everything flows well at both the initiation and end of the workflow. Whether you’re a provider looking to define requirements for a vendor selection process, or a manufacturer developing a new product, use cases are an ideal tool for capturing workflow. Use cases are easy for non-engineers (product managers, application specialists, clinical analysts) to understand and use and can be structured to provide engineers with something that can easily be translated into software specifications.
Converging Medical Device and Enterprise Networks
On Thursday, May 21, 2009 WAV Distribution and and client Summit Data Communications are hosting a web seminar on Converging Medical Device and Enterprise Networks, with yours truly.
As automation converges ever closer to the point of care, medical device systems are increasingly coming to the attention of hospital IT departments. Applications like EMRs, alarm notification, and enterprise-wide deployments of medical device systems are all driving the convergence of private medical device networks with the hospital enterprise network.
Consolidating medical device networks onto the enterprise network eliminates “islands of information” and supports broad deployment of systems like smart infusion pumps and point of care diagnostic testing devices. Moving medical devices from private networks to enterprise networks, however, can prove challenging.
This webinar explores the special requirements medical device systems place on an enterprise networks and provides best practices for creating safe and effective converged networks. Topics covered include: regulatory issues, networking specifications, vendor selection, implementation and management for converged networks.
You can register for the webinar here. I’ll post links to the recorded webinar and a downloadable version after the event.
UPDATE: You can find the webinar listed at Wav Wireless Outfitter’s site, here, and view a stream of the recorded webinar here. You can also download a copy of just the presentation here (4.4Mb pdf).
Medical Device Networks Trouble Industry
Over the past few years, medical device networking has become increasingly problematic. There is a growing perception of declining service levels and network reliability. (I’ve not seen or heard about any quantitative data to back this up – let me know if you’ve got any – but these are substantive issues.) As medical devices, by way of connectivity and workflow automation, have been pulled into the sphere of the IT department risks to patient safety have increased.
These growing problems are a key factor in the creation of IEC 8001 – which will have a major impact on how hospital’s deploy and manage networked medical devices. The current situation provides a lot of the impetus behind a meeting this week at Villanova on wireless technology in health care. So what’s the big deal?
Private Medical Device Networks
In the good old days, all medical device systems operated on private networks that were designed, installed and supported by the medical device vendor. Vendors decided exactly how the would handle IP addressing (static or DHCP) and every other configuration option. This minimized vendor’s product development costs, shortened time to market, and made service and support easy (because the network was their sandbox). When they got the inevitable calls from customers that, “your system just brought down our network,” vendors could quickly and easily determine if that was the case – and just as importantly, quickly prove to hospital network administrators why their answer was correct.
Providers benefited from this approach in a number of ways. First, vendor system support was quick, efficient and reasonably priced. This approach also relieved hospitals of the need to assume responsibility for supporting life critical applications themselves.
Of course nothing’s perfect, and relying on private networks created a few problems of its own. As more medical devices evolved to become components in medical device systems connected by networks, these private networks proliferated. The IT department of a thousand bed hospital system on the east coast did a survey a couple years ago of their networked medical device systems, and “discovered” over 200 private networks. And unlike enterprise networks that must be kept up to date to ensure cross vendor interoperability and coexistence, private medical device networks are like time capsules. With the exception of occasional failures of a switch or router, medical device networks remain unchanged from the day they’re installed; the hospital mentioned earlier found numerous ThickNet and ThinNet Ethernet networks in their survey of medical device systems.
Over time, medical device vendors have given some ground by moving from physically separate private networks, to creating logically separate private networks through the use of network switches and routers.
