PROJECT MANAGEMENT: CHALLENGES WITH THE LATEST HEALTHCARE APPLICATIONS
By Ken Ryan
Healthcare providers continue following the trend towards using new applications over the internet, some
hosted by vendors and some running on-site at the provider’s location. Although we are in a very exciting
time with respect to leveraging new and powerful cutting edge technologies, it also presents new challenges
for the customer, vendor, and project manager. The following points address some of these concerns and
productive ways to mitigate them:
As vendors continue to develop software, the project may be faced with frequent or unexpected needs to
accept new software, test it, and implement it into the go-live (or post-live) version of software. The
software update process for older, established mainframe products should not be expected in the environment
of newer, web-based applications. This can impact the project, sometimes severely, from a time-management
perspective. It’s important to set an expectation early on that such events are possible, or even likely to
occur.
Possible solution strategies include:
1. Obtain a written schedule of software updates from all vendors
2. Provide vendors an email contact list, to include the PM, whenever a software update is being planned
outside that schedule
3. Ask vendors to provide a brief statement of work that lists software implementation steps; also request
a detailed list of software contents (the availability or non-availability of such documentation from the
vendor offers a good check on just how ready the given software is to be delivered in the first place)
4. Include known major software updates that will occur during the expected course of the implementation
project in the project work-plan and budget plan.
The customer’s IT department will have a need to ensure all users’ computers are maintained at the same
level of Internet Exporer, Java, and other related settings. This is necessary to ensure all users can
access the applications they need to perform their roles. Some facilities may already have a defined
process to control this, but many do not. As a new web-based application is introduced into the customer’s
IT suite, it is important to evaluate the technical underlying requirements of the new application to ensure
compatibility with the requirements of existing applications.
Possible solution strategies include:
1. Lock down end-users PC’s (do not grant administrator privileges to most users)
2. Prohibit software from being loaded onto hospital computers that are not on an approved list maintained
by your IT department
3. Verify vendor’s latest requirements regarding Windows, Internet Explorer, Java, and other settings, for
compatibility with your current suite of applications
A topic related to the one above is physician and other clinicians’ remote access. The customer needs a
sound access/security process to control remote access, and once again, the concept of managing the platform
of the computer that a physician may be using at home will definitely come into play. Will a physician need
to purchase a new computer? Will the provider pay for this and manage the software on such computers? Who
will address modern concerns about virus and spyware prevention on non-customer-owned computers? Where
will physicians be when accessing patient information remotely…will they be in compliance with HIPAA patient
confidentiality requirements?
Possible solution strategies include:
1. Develop a written policy for remote users PC requirements, via a joint meeting with IT (technology
management) and Finance (evaluation of cost to your enterprise, possible budgeting for a remote user support
process to supplement your existing help desk)
2. Weigh the cost of support of multiple platforms against the cost of providing a standard laptop package
to remote users
3. Start with a small group of physicians as a test; slowly expand to others…ensuring a positive
experience with the first group will help sell the concept of remote use to others
4. Ensure physician/clinician awareness of privacy requirements through education or group emails to remote
users
5. Perform spyware checking in background on a regular frequency, upon a remote user accessing the
network
Volume testing is a critical pre-live success factor. Web-based applications are dependent on a chain
of electronic communication steps remaining constant, and also must provide sufficient band-width to
accommodate the maximum number of concurrent users that can be expected.
Possible solution strategies include:
1. Plan a particular date/time on which a defined list of end-users representing as many departments as
possible agree to log on to the system at the same time. Include vendors that host applications in this
plan
2. Provide a simple document allowing each end user to document problems they experience when this test is
performed
3. Require end users to provide the specific patient example they were working with during the test, and a
description of exactly what they were doing when the error occurred
4. If a vendor has an issue or event tracking mechanism, open an issue or ticket number with them to
address major problems identified
5. Consider using your end-user training process to conduct a behind-the-scenes volume test as well.
Training sessions sometimes have a large number of people executing particular functions nearly
simultaneously. This can offer a way to monitor system performance (whether through the customer’s own
network for on-site applications or via the vendor for hosted applications) without general end-user close
involvement
Project managers may find a need to become more conversant with technology requirements, as an
ever-increasingly important part of an implementation project, from the perspectives of identifying network
or other upgrades that may be required, time to implement, and cost. These items are sometimes not apparent
at the beginning of a project involving new software applications
Possible solution strategies include:
1. As a PM, spend more time speaking with your interfaces or integration specialists. Use their
experience to try and anticipate technology issues
2. Include the identification of unexpected technology requirements as part of gathering historical data on
other similar projects, and also a part of lessons learned
3. The discovery phase of large projects needs to include a network readiness review (but note this usually
happens very early in a project life cycle, sometimes before the ins-and-outs of the various applications
being implemented are fully understood)
4. Ask the application vendor about their experiences at other customer sites…what have they found to be a
common need in terms of network or other upgrades that were required for their product(s) to operate
correctly?
5. Enroll in high-level technology overview courses to stay up to date
Decision Support, based on a data warehouse concept, will be impacted by newer applications being
implemented. New vendor applications imply new database elements that need to be understood, and melded
into the customer’s data warehouse strategy. Customers with a long history of data warehouse use and
reports customization can be strongly impacted by this. There can also be particular challenges with a
customer whose suite of applications involves some running on-site, and some hosted remotely by one or more
vendors. Allowing time in your implementation workplan for corporate reporting activities is important,
especially in a multi-entity situation.
Possible solution strategies include:
1. Discuss the degree of customization of reporting your customer has instituted over time
2. Conduct a high-level corporate reporting strategy meeting with customer and vendor representation early
in the project to determine if there are any known hurdles at the beginning of the project
3. Encourage the customer to attempt to run several corporate-level reports as early in the project as
possible, to determine how new data elements fit into the existing reporting strategy. Is the information
present on such reports what was expected? Are there data mapping issues (indicating a need to revisit how
data is mapped into the warehouse), or is it more a problem with a lack of understanding of the new
database(s) amongst report building resources?
4. Include report production as a part of integrated testing
New applications may also mean there is a less than desirable level of understanding amongst the
implementation resources. Factoring in a lot of education time may be required to ensure a successful
implementation. Since many applications are new, it can also be difficult to find resources with new skill
sets that may be required. This can apply both with vendor consultants and customer resources. The
project could be impacted more severely than expected by this…design decisions may need to be revisited
frequently as testing reveals unexpected issues.
Possible solution strategies include:
1. Use a readiness check-list to determine the experience and education level of implementation
consultants
2. Ask the vendor about any specific skill sets they expect the customer to have
3. Also ask the vendor about education trouble areas on similar projects elsewhere
4. Form your education plan early in the project
5. Get key customer end-users on the application(s) as soon as possible…don’t let knowledge they gain in
education atrophy for want of practical usage
Finally, while integrated testing has always been an important pre-live need, it is ever more crucial as
projects involving the implementation of new products are undertaken by healthcare providers. Several
rounds of such testing are likely to be required. The mapping of new database elements between
applications in the interface engine will be an area of particularly strong need for thorough testing.
Possible solution strategies include:
1. Conduct an early round of integrated testing using only 3 or 4 patient examples...do this quietly
even before formal “integrated testing” is set to occur…it will help teams identify problem areas and will
help keep your first formal round of testing more error-free
2. Large projects require a lot of testing; don’t try to do everything at once. Start with simple patient
examples and move towards more complex scenarios. An overly complex initial round of testing can create
frustration on the part of all participants, and can damage confidence in the new technologies being
implemented
3. Do however make sure to ultimately include scenarios where patients change status during their course of
treatment (i.e. ED>Observation>Inpatient). Ensure all applications can accurately track the patient and
identify the patient’s current status and location
4. Use the production of the insurance claim from your test scenarios as a major metric for success. If
the claim contains all the services that were rendered to the test patient, all the diagnosis and procedure
code data that was coded by Medical Records, etc, it’s a good indicator of the true readiness to go-live
and the general coherence and completeness of your project’s design and build phases
5. Require design decisions that have ripple effects outside of one application to be made with
representation from other applications. Think globally!
If you would like to discuss challenges facing implementation projects further, please feel free to
contact us at vcs@getvitalized.com.