Many healthcare CIOs have argued for ages that Meditech’s large market-share has caused them to be a bit less than responsive to customer needs and somewhat rigid in their delivery of service, along with being more focused on their internal business drivers than their customer’s desires. I must admit to having been one of those CIOs, but a recent meeting with Meditech senior leadership has given me much cause for hope. And it seems that Meditech may truly be more interested in their customers than they have previously exhibited — at least from my perspective.
During the April Meditech CIO Forum, a group of 15 6.x CIOs met with Meditech President and CEO Howard Messing and six other Meditech senior and associate VPs to discuss concerns related to customer support, product quality, development, and strategic direction as relates to the 6.x product line. The meeting was very cordial and all parties exhibited professionalism in not just pointing out problems with 6.x and the associated services, but also successes.
As one of the attendees, I was particularly encouraged that Mr. Messing and the others really paid attention to our concerns and asked probing questions. He even made the statement that this meeting was very important for him to align what he is hearing internally around the adoption of the product and user satisfaction to what we as CIOs are really feeling. This was truly the first time that I ever sensed someone at Meditech was really interested in what we had to say, and not just presenting a “canned” corporate line or voicing a host of excuses.
Mr. Messing listened intently to our concerns and acknowledged that the product had some performance issues, past implementation challenges, and that Meditech leadership had underestimated the growth and adoption of the 6.x product, as well as overall resource needs. Additionally, he said that if they had to do it over again, they “would do it differently.” This message was refreshing, as it marked the first time I had ever heard anyone at Meditech admit that there were product issues and resource issues, and that there was a plan to actually address them.
In terms of service, we brought up the fact that there is a lack of qualified, experienced support resources, and that all too often problems need to be escalated to “development” for resolution. From the Meditech side, they indicated they increased staff in the 6.x area by 30 percent since last October. Interestingly, Mr. Messing stated that Meditech leadership fully realized the current on-boarding program, which gets staff up to speed is around one-plus years, was much too long. They are looking closely at how to shorten that timeframe, and he was open to suggestions. One of the CIOs suggested having new staffers spend a week at customer sites getting to understand their product flow, module interaction, and support challenges. That was very well received.
Meditech leaders also noted that they have restructured their development and support areas to provide a more holistic overview of issues and try to address problems more globally than the way they used to resolve individual customer tickets. The CIO group applauded their proactive approach to this, since that was one of our concerns. In the past, DTSs and fixes were made reactively to just individual customers, even though several customers may have noted similar, if not the same, issues.
In terms of product quality, stability, and downtimes, the group presented a laundry list of core issues including, but not limited to, how the 6.x product addresses medication reconciliation, CPOE and physician workflow, interoperability and data exchange with non-Meditech applications, system freezes, order-set instability, and others. Again, it was encouraging not to be fed the standard set of excuses heard so many times in the past but rather a plan as to how they are addressing the concerns. To start with, they have added more physicians to their staff, and will work with customers and development to help guide changes needed in the form of product enhancements, clinical workflow, CPOE, and other areas.
Secondly, there was a fair bit of discussion around their strategy for product stability. As previously mentioned, a restructuring of the development/support area was part of that. They stated that the version strategy is to get all the 6.05 customers to PP13 and the 6.06 customers up to PP03, which are considered to be their most stable versions. From there, they would like to keep customers reasonably aligned on the same version until the release of 6.07, which is planned to include most of the ARRA changes required for Stage 2. They also noted a development change which would use version testing tools to note changes between customization and standard code. There was also discussion from the CIO community that the older Meditech strategy of not keeping the test environment aligned with live environments more than once a year is no longer working as best practice, and that like with other vendors, more frequent refresh of the test environment to live is needed. That too seemed to be well received as a suggestion.
Meditech was asked by one CIO about the timing of the remaining 6.0 product line rewrite using the M-AT technology, postulating that this would also contribute to the overall stability of the product. No firm timeline was given; instead, Meditech stated that it would be more prudent and faster at this juncture to concentrate on making the connections between applications more efficient. Meditech also stated that any new product rewrites would be done using a web browser interface which will interact directly with the M-AT database and is using resources to concentrate on that effort.
From my perspective though, the importance of that issue for the customer community may have been missed or glossed over. During the sales cycle, many of us were led to believe that the code set was more homogenous or consolidated than what was delivered. On the face of things, any application that requires two different report writers to create reports and queries depending on where they are in the application is exceedingly inefficient, problematic, and less than elegant.
To address challenges in Meditech resources understanding hardware impacts of VMware, CITRIX, or even Microsoft OS, they have increased their hiring in that area too. Additionally, it was announced at the forum that a new role was created of technical account manager (TAM). The role of the TAM is to act as a knowledge bridge between the customer and Meditech to get problems escalated to the proper area. The TAM would not just be knowledgeable on the application overall but also have good understandings of hardware and technology to help facilitate problem resolution. They felt this was key to more quickly resolving any technical- and hardware-related issues. The real question though is how quickly will those newly hired TAMs be able to get up to speed on the Meditech product, culture, and challenges to be of real value to the customer?
As to strategic direction, time got away from us, and that was not really addressed. The question from the CIO side that was not asked was around their hardware relationship with Dell and Park Place, both now and into the future. Personally, I had a question I wanted to ask that previously wasn’t addressed by a Meditech salesperson: with the industry seeing a trend in mergers and acquisitions of rural hospitals with larger IDNs and tertiary providers, most of who are running Epic or a product that is not Meditech related, what is the overall strategy for Meditech to play in a market where five years from now they may see a very large erosion of their primary market segment? And if it is to drive sales in an IDN or multiple hospital environment, what will that product strategy be, as they are not capturing much of that market today?
In summary, along with others I spoke with, I feel very positive about the meeting and discussion. It was productive and, for the first time in any of my Meditech interactions, left me hopeful that Meditech is starting to really consider their customers’ challenges, desires, and processes, at least as it relates to 6.x. It was refreshing to hear them acknowledge problems and challenges voiced by the group and actually have already had ideas and plans on how to address at least some of them. It was also noteworthy that we had many of the same understandings of the state of 6.x products, and that there was not the usual Meditech-versus-customer disconnect. Maybe most importantly it was the first time in my dealing with Meditech that I truly felt like a customer whose concerns were taken seriously. Could this, along with the 6.x product, be the birth of a new Meditech?