Be the Life of the (Third) Party

Choosing your new core vendor and starting the implementation of an access and revenue, clinical and ancillary platform is an exciting event in any healthcare organization. Choose well and your organization has a solid foundation to build upon for many years. But what sometimes gets overlooked in the excitement of the new system is the heavy lifting that the non-core vendor technologies and applications do, and will continue to perform as your new foundational system is brought live. Your core vendor will typically refer to these as Third Party products; technology components that are required to complete the vision of the integrated system but not included in the core vendor offering. Now, it is likely the big-ticket items (think PACS, or Encoders, for example) will be identified during the core vendor selection process. It’s often the more granular components that aren’t discovered until late in the implementation which can create real problems!

Fortunately, a comprehensive review of necessary third-party products lends itself well to a Plan-Do-Check-Act (PDCA) cycle, and by broadening that analysis to areas outside traditional Information Services (IS), you can capture more of the potential needs than you were originally aware.

Therefore, here are some suggestions on where to start (I’ll assume you’ve already documented the big-ticket items):

Plan:
There is usually a ton of information within the organization about what third-party products are being used. The challenge is that it is often scattered throughout the organization. This is a great time to pull it all together by reaching out to a few key groups and pick their brain. Here are a few places to start:

• Accounting/Accounts Payable: What items that even remotely sound like hardware or software had a payment made to them in the last 12 months? This review often gets to content vendors that may be taken for granted in existing systems, but may or may not be supported on the future platforms.
• Contracting/Materials Management: What items are being negotiated, which have just been renewed, and which ones are coming up for renewal? These are all rich sources of information and possibly cost avoidance if the new functionality overlaps or eliminates the need for some of these existing products.
• Biomedical: Often an area of specific-use networking and hardware, it is good to understand the special requirements that is not uncommonly on the fringes of the IS ecosystem. More complete integration of biomedical and clinical systems is a significant win for an organization. Often it takes identifying the model/serial number of these products to determine compatibility with the clinical and ancillary systems being installed; and early knowledge can prevent costly surprises later in the project during testing.
• Analytics and Reporting: It can be amazing and little frightening (:/) how much overlap can exist among each third-party vendor’s reporting and extract structures. And at the risk of introducing scope creep, there may be no better time that this project to move to a robust data warehousing and analytics platform than now. This group also has astonishing knowledge of where data goes externally from the organization, often via third-party connections that have seemingly run forever in the background.

Do:
Assign a Project Manager for third-party products, someone who wakes up every morning thinking about third-party products. The work this person does will be greater than the sum of individual contributors. She or he is your air traffic controller who will know all the work in progress and will ultimately move the business-related work forward with the vendors so that the technical teams can focus their expertise where it is most valuable.

Once the third-party products are identified and the technical teams are fully engaged, this Project Manager can often provide leadership to other aspect of the project such as testing, training coordination, and activation planning.

Check:
Collect, quantify and present the status of the third-party products as visibly and frequently as you do the core vendor project updates. By definition, these third-party items are in your scope, but for many reasons they seem to slip under the radar unless they have a pre-planned seat at the project governance level. Often is the mechanics of contracting and negotiation that consumes valuable project time, and a few well-placed calls from organizational leadership can move slow moving processes forward much more rapidly.

Act:
Take the conservative approach and operate under the assumption that a one-week delay to a third-party project will result in a one-week delay to the overall project. The sense of urgency around third-party timelines needs to be as great as they are for the core vendor products being implemented. It’s helpful to remember that while a technology or system is third-party product to the overall implementation, these same items may be the core system to a good number of users!

Sum:
Make your critical path less critical, pay daily attention to your third-party products.