Pros and Cons on Equipment Standardisation

2 years 3 months ago - 2 years 3 months ago #23 by Luis E. Fernandez A.
Pros and Cons on Equipment Standardisation was created by Luis E. Fernandez A.
Adrian Richards:
Team, I would like to learn from your KP experiences around equipment standardisation. I am giving a conference presentation next week (to mainly accountants) on the benefits and pitfalls on equipment standardisation. Their interest is of course how this may save money, but I am going to give as many examples of I can as to why it can be a two-edged sword.

Do you have any good examples that I could quote on where standardisation has really reaped rewards (in any respect) and conversely where it may have exposed you to risk? The examples we have in the latter category are around where we have gone hard down a single supplier path where the devices have suffered recalls or withdrawals and really compromised clinical care at short notice (all the eggs in the same basket scenario). Did you ever apply principles of non-standardisation to avoid that?

Thanks,
Adrian


Fred Hosea:
Adrian, I agree that standardization at a manufacturer level inherently has risks as a single point of failure, so having multiple manufacturers hopefully divides that risk, assuming all vendors have roughly equivalent performance capabilities.

The point I would urge you to make, somehow, is that (assuming competent technology assessment has occurred) the total cost of ownership is probably less determined by manufacturer mix or recall management costs than by the myriad other non-standardized, in-house operational variables (data, processes) that CFOs rarely want to invest in. Too many finance people just look at purchase costs, cost of capital, and annual trends and ignore the other lifecycle costs of maintenance, service management, parts, overtime, unexpected recalls, upgrades, disruptive technologies, integration costs with IT, etc. that don't fit onto smooth curves or linear projections.

The absence of standardized infrastructure, data systems, and business processes cuts across departments and rarely has C-level champions who will take on the tedious and complicated work involved. I would argue that whatever risk is mitigated by focusing on multiple vendors may well be ultimately diluted, if not cancelled out, by the even more costly maze of behind-the-scenes, unstandardized inefficiencies I noted. Such un-sexy, operational tedium’s that require years of work to understand and improve don't get much attention in CFO school. I was lucky to have an IT CFO at Kaiser who gave us the support we needed to get started on the multi-year, multimillion-dollar initiatives that we needed to standardize business processes and data across the regions for asset and service management, but even so, it took 10 years to begin having the results we were aiming for.

Best wishes,
Fred


Adrian Richards:
Fred, Great collection of thoughts, many thanks. My audience is typically CFO’s that by default consider that standardisation is a way to reduce capital costs, my plan is to broaden their outlook a little. The most obvious recent example is the potential impact on a health service that had fully standardised on Enflow fluid warmers!!!

Regards,
Adrian


Fred Hosea:
This topic is enormously complex and tedious, to be sure, but I'll give a few observations from my work in asset and service management at Kaiser. I'm sure George, Mario and Tom will have good ideas to complement or correct mine.

1. In general, standardization is far better than none. In a sense, everything we bought was referenced to a standard managed by the National Products Council. So, depending on the technology, there could be more than one acceptable standard, and individual hospitals could select from a menu of options. So, standardizing can have different meanings and many different levels.

2. Recent WHO efforts at standardizing a UDI (unique device identifier GMCN, UMDNS, GUDID, etc) were somewhat helpful, but did little to advance standardization at the more granular levels of data and process management where the risks (clinical, operational) and benefits (efficiency, cost controls) more often lie.

3. We tended to be one-vendor dependent on big ticket items (CT, MRI), and have greater diversity of vendors and models in instrumentation.

4. The Kaiser service model was based much more on in-house techspertise than on outsourced services.

5. Quality of service depended on having qualified, experienced staff on duty and on call, with a dedicated biomed call center and after-hours answering service and paging system. This was eventually merged with the IT service center because medical devices were increasingly networked, and joint service models were needed.

6. Standardization of device types and models is only the topmost level of standardization that is needed to manage the medical device infrastructure safely and efficiently.

7. Often, different depts. developed their own terminological standards (location codes, barcode type, vendor codes, equipment characteristics, assigned owner (dept/individual), etc.) and these standards may not be harmonized or updated consistently across hospitals, regions, and national entities. One department's standard may or may not correspond accurately with another's, leading to miscounts and distorted analytics.

8. Vendor data feeds for purchased equipment are typically not standardized across vendors, so considerable rework may be needed to map incoming data into your enterprise data systems.

9. If you standardize asset tags, make sure they're standardized across regions if applicable, insuring enough digit space to accommodate future growth of the asset base, and include a clear identifier that distinguishes your regional or national tag from e.g., local facility property accounting tags, which may have other formats, standards, and usage conventions.

10. For hospital equipment, it's important to have tags that are resistant to disinfectants that may blur/erase tag data (so laser printed tags with a glossy finish are better than inkjet).

11. There are different levels of standardization that help or impede analysis. Facility location codes may be accurate at the level of street addresses, garage/delivery entrances, etc. but lose traction at the floor or cubicle level where equipment is typically located. Physical location of equipment can be critical when providing service or managing moves, recalls, upgrades.

12. Mobile equipment increasingly requires some kind of electronic tracking capability (such as AwarePoint) to provide real-time physical location, which can be very important for upgrades and recalls, when every device needs to be located within tight deployment schedules.

13. Most cubicles and offices do not have standardized, scannable barcode location tags, which means that inventories and services require manual location maps and manual data entry, which is tedious and more prone to error.

14. The absence of standardized service menus and detailed service codes makes service analysis and device performance analysis very difficult, if not impossible. Services should be rigorously defined by a multidisciplinary team to ensure that everybody is using codes consistently and accurately to define incidents, problems, cause codes, and resolutions codes. etc. in keeping with ITIL standards.

15. The more standardized granularity you have for "configurable devices," the better. That is, if a device has components that can be patched, upgraded, replaced, has memory limits, has software versions, etc., then you need to have standardized nomenclature and database fields for all those variables, and ways to keep the "configuration" up to date with automated or manual updates. The closer you can get to having a CMDB (configuration management database), the better --- although this will probably take YEARS to create, if you're in a big organization.

16. Everyone must understand that the ITIL process management model is a sine qua non for integrating and maintaining coherent data flows as technology and the organization evolve with time. At least one person on staff should have the basic 3-day training and certificate and become the process guru.

17. Having different service desks for biomedical and IT systems can create problems of service prioritization, classification, incident/problem analysis and service coding. Sorting out device vs. network problems can be complex and time consuming, requiring joint teams that may have to work overtime to restore critical clinical services. Service-level agreements (SLAs) and operational-level agreements (OLAs) can become areas of adversity, as departments may try to re-assign a service request to another entity, in order to keep their own statistics favourable. The SLAs and OLAs can therefore actually decrease collaboration and increase bogus service metrics that provide misleading data for error/fault analysis and process improvement.

18. Standardization of data and processes between biomed and IT was a critical success factor when we undertook a large-scale replacement of Baxter infusion pumps: 1) Overall costs of the recall depended on refund value of recalled pumps, so a uniform return process, accurate device count and return tally, with serial #s and an up to date spreadsheet was significant. 2) At one point, we discovered production defects in some new pumps that had already been deployed; but the defects were only in a specific production batch. So, we needed to be able to track which members of that batch had been deployed to which specific locations, so we could pull them out and replace them efficiently. The production batch isn't typically part of the asset data set that the vendor provides, so we had to get that info from the vendor ASAP and have a record of how that production batch matched up with serial numbers and deployment location. 3) Process standardization is as important as data standardization for device identification and tracking. Tracking medication errors depends on correct entry of who is giving the medication, but some departments entered the department code instead of the employee/nurse ID, making accurate and timely analysis difficult, requiring manual review of spreadsheets and employee logs.

19. Standardization also needs to incorporate a long-term view that feeds into next-generation design, upgrades and replacements. The organizational costs (money, time, efficiency) for failing to think forward in the operational lifecycle can be huge. "How is this technology likely to change in the next 2-5 years?" is an important question that can help you identify new standards that you use proactively to evaluate component upgrades and replacements and have asset management capabilities that allow you to incorporate new standards as they arise. The fact that we had a fairly mature national asset management and service management workforce and database in place made it much more manageable to coordinate efforts across hospitals and regions. A couple of examples of standards problems that cost us significant time and money:

1) When installing 10,000 wireless computer carts (over 3 yrs.) we discovered, too late, that the vendor standards were quite idiotic for indicating battery charge status. The status indicator light only turned on when the battery was charging. When it was charged, the light went off, which was also the case when the battery was fully discharged. So, we had hundreds of service calls complaining that the batteries were dead, when in fact they were fully charged. The vendor display "standard" was incompatible with common sense. Have a rigorous process to define requirements upfront and provide sufficient time for end users to compare finalists in real-world conditions before making a decision to purchase. 2)The laptop compartment on the cart was designed with a small portal at the back that allowed rebooting by nursing staff when necessary. But when the next generation of laptops was selected to replace the legacy units, the rebooting button didn't correspond with the port location in the compartment, so a lock-and-key modification was necessary, creating a cumbersome key management process that created security issues and extra work for the biomed techs.

20. Be very demanding in evaluating "enterprise solutions." They typically have been invented in one enterprise sector (finance, HR, database, fleet mgt) and gradually enlarged into other areas through amateur, in-house improvisations or acquisition of another company. These solutions have tended to be really good in one or two core areas and mediocre too bad in other functional areas. Involve true subject matter experts to evaluate all modules and make sure that all stakeholders are getting a tool that supports their professional standards and accountabilities.
These are my main thoughts for the moment.

I hope something in the mix is useful for your presentation. Feel free to set up a Zoom meeting if you'd like to discuss any further,

Best wishes,
Fred
The following user(s) said Thank You: Shija

Please Log in or Create an account to join the conversation.

Time to create page: 0.188 seconds
Powered by Kunena Forum