Author: Allison McCarthy, MBA
Most organizations begin efforts to implement a physician relations tracking system by first selecting the software. The unfortunate outcome is often that the organization quickly outgrows the selected software as it fulfills the immediate, but not the advancing program needs.
Establishing System Needs
The most effective approach is first constructing the system “wish list” — done by organizational representatives as part of the tracking system development team (described in the article, The Silver Bullet in Physician Relations Tracking — Creating the Right Team). This list then becomes the criteria for identifying the software that best meets those functional desires.
By asking team members to complete the sentence, “I know the tracking system is working effectively if it can ______________,” the full scope of needs and expectations are uncovered. Just be sure that as the team brainstorms their responses, you have some items that are objectively measurable. For example, if you want to reduce the issue resolution response time, ensure the system can track the number of days outstanding for each issue logged. Beyond functional desires, decisions also need to be made about how users will access the system— as a networked user, a remote user, etc… Does the system need to integrate with other organizational systems such as office tools (calendars, email, etc…), marketing applications (i.e. web site, call center) and decision support resources (to import referral volume data).
Prioritize the “wish list” since the organization may not be able to implement all desired capabilities immediately, or there may not be a software program that can meet 100 percent of the team’s desires. Consider a phased approach — starting with basic functions and progressing to more customized solutions as the system evolves.
Selecting the Software Product
With the “needs” ranking in place, project leaders can do an initial review of the software options. Once they have culled the list to three or four, team demo sessions can be arranged. Whether remote or on-site, it’s helpful to have as many team members included as possible. Team members should be asked to complete an evaluation tool following each software demo. In this way, each system is assessed equally and the team objectively identifies the option that will best meet the breadth and depth of organizational needs and desires.
Defining Work Processes
While this may feel tedious and unnecessary, it’s an important step to identify ways in which the system needs to be customized to comply with how the users do their work. For each user group working with the system, outline the distinct “activities” from beginning, middle and end that need to be captured. Physician relations examples can include:
- Scheduling and completing office appointments with physicians, office staff, etc…
- Arranging and implementing a CME session with a group of physicians
- Soliciting and connecting a physician practice to the hospital’s clinical information system
It’s also helpful to create a few “draft” reports with “dummy” data so there is an understanding of the details that needs to be collected so as to produce the desired documentation.
Managing Physician Data
Wherever your existing physician data resides, it is likely to be housed with several different systems throughout the organization. Some of this data will be duplicative across systems — and likely only some of it will be reliable. Sorting through the maze of physician data repositories is an arduous but necessary exercise for not only the initial data import but also managing ongoing data updates as well. The project team will need to define how the initial data will be identified and imported into the system, as well as from where and how frequently ongoing updates are added on an ongoingbasis.
Customization Review
Before installation, members of the team will need to review the customized screens and functions designed by the vendor within the software. This stage typically goes through a few iterations until the team and the vendor concur that the information and process needs have been met and the system is ready for installation and “go-live.”
User Training
It is best to have the system installed and ready to use in advance of user training. The staff can walk out of training and begin to apply what they have learned immediately.
The already defined work processes should drive the training agenda. Training is not just to orient the users to the software but to teach how the organization prefers the users track their activities and findings. Ideally, the training incorporates relevant case examples so users can practice how they will actually use the system in a typical work day.
So who is best equipped to conduct this training? Certainly the software vendor can be considered — but they need to be well versed in the user’s daily work activities to ensure they meet training expectations. If a consultant was retained to facilitate system development, he/she can do the training individually or in conjunction with the software vendor. In this way, you benefit from the consultant’s physician relations expertise and the vendor’s intimate knowledge of the software. Or if there is a member of the project team who is comfortable with the user’s tracking obligations, they can complement the vendor as another option.
It’s important to recognize that training is an ongoing need. So even if the initial training is conducted with the consultant and/or the vendor, it will eventually be most cost effective to have someone on the team who can perform ongoing training sessions to orient new team members to the system and provide refresher support to existing users as needed.
Project Review
It’s useful to do a project team “post-mortem” to clean up any lingering details, review lessons learned and determine the best approach for managing the system long term. The tracking system is never really finished — it is guaranteed to change and mold over time to meet the team’s continued reporting needs.