Jorge Grillo, CIO, Canton-Potsdam Hospital
For those following our Magic to 6.0 upgrade (reinstall) sojourn, last month’s cliff hanger was what we will do with the 6.0 ED module. Do we install or go to a different vendor? Well, the vote is in and it is definite that we are moving forward with something other than Meditech. The reasons, you ask? Simply that after several physician reviews of the Meditech ED product, the physicians and clinicians feel it is not competitive on the market and may be too immature a product. Also, the consensus on functionality is that the Meditech product would decrease ED throughput, not efficiently meet the physician workflow, and do little to generate revenue.
On the downside of this decision, we will lose integration ease and add cost, as well as support overhead. Also, Meditech has pointed out we may lose some clinical efficiency and integration of things like pre-existing conditions. When weighed against the opinion of the physicians on the overall product quality and ease of use, it was decided that going to a specialty vendor for ED was the way to go.
Other happenings this month are that we were assigned our Meditech Project Manager (PM) — or as they term it “Project Coordinator” — along with implementation specialists. If any of you are familiar with the project management model most best-of-breed vendors use, you should not expect that of the Meditech resource. Their model is not a Project Management Institute-based approach, rather a more generic, less structured one.
For instance, the PM is only scheduled to be onsite a few times during the whole project. Also the PM documentation is not necessarily tailored to your site and must be retrieved through the Meditech Web site and downloaded. The material is also lacking such useful information as consolidated training plans, risk assessments, project charters, etc. When asked about this, the Project Coordinated replied, “What can I say? I have to use the documents provided and can’t recreate the wheel.” (I asked if I can quote her and was told yes).
In other words, the bulk of the project management falls on the user side of the house. This is made more challenging by the fact that due to the vast number of simultaneous activities going on, Meditech strongly recommended the internal PM be a dedicated resource and not an executive (CIO?) or manager with other duties. This is also in line with what some other CIOs moving to 6.0 have pointed out. The problem is that if you don’t have a PM already employed, where do you get one? It is a huge and challenging project to develop a PM.
On the flip side, there are very few experienced 6.0 PMs on the market, and most of those come at a premium rate along with the risks of whether there will be a cultural fit. We have not yet decided how best to meet that challenge and are initially, at least, splitting PM duties between two executives, neither of whom has the bandwidth to take on the entire project.
Another surprise for us involved the overview of dictionary relationships on one another. Our Magic had been set up in 1994, so we thought it would be an injustice to simply copy over all the dictionaries in a migration-tool format. We knew we had not set our initial dictionaries up to take advantage of all the functionality or modules in the Meditech application. We asked if Meditech provided a consultant to walk us through all the dictionaries and discuss cause and effect a bit, especially as related to how what we might choose to do today could effect future modules, like CPOE or ED. We were told they have application specialists who do that per module, but only with regard to that module and not the whole application set. To us, this was a “not being able to see the forest for the trees” approach.
The recommendation again was that we go external to a Meditech consultant to get that information. Again, with so few 6.0 installs out there, it is a difficult and costly resource to find. More importantly, it seemed very disheartening that Meditech, as a corporation, would not provide an implementation consultant with the skill set to make recommendations in a more holistic manner as to the setup and configuration of their product set. One would think they would attempt to advise the client on every conceivable way to get the most out of their product, especially if several components contracted for would not be installed until after the base configuration is completed. Even if at a cost, it would seem that information would be better if provided from Meditech than outside vendors whose advice might negatively affect the outcome and satisfaction of the Meditech products.
On the plus side, Meditech did offer us an extra seat in the initial analyst training course at no extra charge. Now the challenge for us is trying to decide what resource to send. In the past, the Magic product was fairly independent of the Microsoft /Active Directory (A/D) environment. Since in 6.0 user rights and printing is managed in an AD environment, it is recommended that you send at least one Microsoft Administration-type resource to the base analyst training.
The problem is that, when questioned, the Meditech resource was not very knowledgeable on the training provided, so it was difficult to know how much crossover of Microsoft-to-Meditech training would be provided, or the level of Microsoft skills needed. That meant we didn’t want to assume one of our Magic systems analysts would have enough Microsoft knowledge to get the most out of the training. Also, if we sent a Meditech-centric analyst, they would have to come back and do a train-the-trainer approach with the Microsoft-centric staff. The converse also applied, and if a Microsoft analyst was sent, would they be of maximum value to the project and use the Meditech-centric information to assist others during the migration. Not having more knowledge about the training classes and future tasks aligned to resources, it would seem that these should be separate classes or handled in other ways.
We did, however, make significant progress with the hardware for the project. The Dell/Perot group kept things on track and quickly worked through their tasks. We had five days scheduled for the Perot-EMC SAN install to take place and only needed one. This did not really surprise us — the extra time in the project plan was more related to dealing with any problems that might arise.
One interesting hardware item was around the Cisco 2901 Integrated Services Router which Meditech requires you purchase. When I asked about that (since we already have a VPN appliance), I was given a lot of information about how that is part of Meditech’s support model and that it is intended to reduce management overhead for us. In deeper discussion, I found that the real reason is that it is simpler for Meditech to manage their staff tunneling into customer sites because it ties to their internal access lists. When I asked why we, as the customer, were required to purchase something which arguably provides a greater benefit to Meditech than us, something that is ultimately a redundant network component, I was told it is just part of their support model and, if I have concerns, “I should get with the sales guy to make it right.” How is that for a customer-focused approach?
Well, that is the bulk of this month’s efforts and progress. Next month should be a slow month as we await software delivery and have the onsite kick-off. I will report on what is presented to the core teams as deliverable and how software delivery goes. Stay tuned!
Will Weider says
I really love the fact that you are sharing this journey and being so open about it. I cannot thank you enough.
In that same spirit, I want to share some thoughts about project management. A really good project manager should not be burdened by product knowledge. They should focus on managing the project schedule, keeping everyone one task, making sure deliverables are written and of sufficient quality; and managing key project controls like the issues list and the software defect list. This should not be someone from the vendor or a product expert.
Jorge Grillo says
Will, I could not agree more. I have always been big on Project Management Institute (PMI) methodology and you are right that it is less about the product knowledge than the project tasks. On the other hand, with Meditech not providing in depth product knowledge tie in, lesson’s learned, or other value-add information it would make sense that if a small organization (like most rural entities are) were to invest in a costly external PM, that there would be enormous benefit if the person had previous 6.0 experience, especially in the lessons learned area and steering you around the pitfalls. Also it seems to get a PMP certified PM with a good track record of on-time & on-budget it is costly and just as difficult to find as a 6.0 PM, due to all the meaningful use projects vying for resources. This is made even more difficult for us in the North Country as we are so rural we don’t even have an true airport less than 2 hours away and are a 3+ hour drive from anywhere with a larger population.