adhansen8 and Art Vandelay, you've both framed the issues nicely.
1. The types of hardware and software managed
Besides the differing requirements they're trying to meet, most device vendors lack the "ear" to select hardware and software that is in tune with what IT departments prefer.
However, the biggest issue that I see is medical device vendors propensity to implement minimal choice and flexibility in products using general purpose computing platforms. When designing an embedded system a key quality technique is to keep variables to an absolute minimum. In contrast, products that extend to a general purpose computing environment need a much broader scope of options and configurations. You can see the conflict, and it's little wonder that most medical device systems are woefully rigid and inflexible.
2. Regulatory expectations
The FDA has a draft ruling out for comment on MDDS, medical device data systems. You can read an explanation of the proposed rule
here.
Providers need to be aware of the regulatory status and the intended use of products they buy. Using a product outside of its intended use can leave you holding the bag, like
here.
Another big issue is networking medical devices. Your site is probably different, but the level of documentation in IT departments that I've been in is abysmal. At one site a single PowerPoint diagram was the sole documentation on all the interfaces between medical devices and their information systems.
This contrasts with biomedical engineering where they create a record of every single interaction they have with every single medical device in the hospital. They document when the device came into or left service, every problem, repair, firmware upgrade, PM -
everything. You can't just buy a network the vendor calls "medical grade" - you have to design and manage it like a medical grade network (something the vendor can't tell you how to do).
A new networking standard is in the works. The IEC 80001 draft standard for risk management of networked medical devices will impose a "voluntary" standard on providers for designing and managing hospital networks that include medical devices. The Joint Commission and other accrediting organizations will require providers to implement this standard once it's finalized.
3. Service levels expected
A perfect day for an IT person is to fix every problem that comes up from their desk, monitoring systems, rebooting servers, documenting support, etc. A perfect day for a biomed is to go to the point of care and work one on one with clinicians solving problems with training, problem diagnosis, and repairs. This is part of the "great divide" between biomeds and IT.
The best solution is a blend. No biomed wants to go up to a nursing unit to diagnose a device connectivity problem only to find that the serial connector came undone (they like things a little more intellectually challenging).
The other part of the divide is the difference between "mission critical" and "life critical." In the first, the institution suffers financial consequences and in the second, your customers die - the SLA for that is NOW.
4. Systems of systems
The complexity you note comes from unforeseen combinations of systems of systems. There are several issues here, the first of which is scalability.
Medical device vendors are pretty good at verification testing of embedded systems, but they are still catching up when it comes to medical device systems that extend beyond embedded devices to include devices, clients and servers running on networks. In fact, most large sales are really verified upon installation because vendors haven't invested in the means to verify the scalability of their systems. Large providers who know they're pushing the envelope are really rolling the dice (right along with the vendor) if they buy without insisting on a review of verification test plans and risk analysis done during the product's design phase. At the same time, providers can build a special relationship with a vendor where you are rewarded for taking the risk to verify the system at your site.
Part of the idea behind IEC 80001 is to create a risk management framework for the use of systems of systems in a networked environment. Various systems on the network can have unintended interactions. Middleware products or add-on products to medical devices also require risk analysis - by both vendors and the provider. Analysis should extend to the policies and procedures of the clinical departments using the products.
In a very real sense, the various medical device systems you purchase and combine on your infrastructure are unique configurations that the provider is creating and operating.
5. User expectations and training
Device training has traditionally been done in person, frequently by the rep who made the sale. Medical device systems, either diagnostic systems or patient monitoring/therapy delivery systems, by their nature are implemented like smaller information systems.
This brings to mind provider's efforts to standardize on one vendor for things like infusion pumps or patient monitors in an effort to minimize training requirements. There are few embedded devices as well designed as an iPod or iPhone.
Art, to your list I would add a couple:
6. Workflow analysis
Medical device connectivity is the automation of workflow through the integration of medical devices and information systems. A lot of vendors still don't fully appreciate this, nor do many providers. Any connectivity solution will be compared to the workflows it is intended to replace - if there are more steps, users won't be happy. Unhappy users are not good users.
Providers need to capture their own workflows, and carefully compare them to the workflows supported by the vendors they're considering. Complaints about current point of care diagnostics solutions, and the large percentage of results that never make it into the chart are examples of where both vendors and providers have dropped the ball. The use of IHE profiles in RFPs is a good step in the right direction. But IHE profiles are really only mature for cardiology and radiology. Medical connectivity outside those areas are dependent on you defining your workflow requirements to vendors.
This is a good time to encourage providers to get involved in the IHE, otherwise you'll end up stuck with what the vendors (who represent 95% of IHE participants) come up with. Art, certainly you institution has the wherewithal to participate in the IHE PCD.
7. Strategic Planning and Vendor Requirements
Perhaps things are different when buying big HIT systems, but in general providers are poor technology buyers in the space where devices and IT co-mingle. The fact that it was such a big deal that Kaiser adopted standard purchase contract language stipulating vendor connectivity responsibilities (and few if any vendors have followed suit) demonstrates providers passive/aggressive relationship with device vendors. Do you want SNMP support all the way to the medical device? (You should.) Vendors won't implement things like this until you
insist.
Just like vendors create technology roadmaps to align R&D projects, providers need to develop roadmaps. Just about anything you automate at the point of care impacts other things, be it wireless phones, point of care computing devices - everything is interrelated. Effective planning includes all the stake holders at the point of care and should look at a 5 year window. Make sure that wireless LAN you're installing now for meds administration doesn't have to be redesigned (and effectively reinstalled) to support wireless VoIP in 12 or 18 months.
Convergence of IT and Clinical Engineering Help Desk services
Linear Mode
