It’s possible that the last thing the federal government was thinking about when it mandated MDS 3.0 (changes to the minimum data set (MDS) to increase resident-centered care in nursing homes, as formulated by the Centers for Medicare and Medicaid Services), was the fact that so many long-term care facilities would actually be required to completely throw out the software they were already using.
After all, the major long-term care software developers appeared to be so adept at applying band-aids and duct tape to their legacy Disk Operating Systems (DOS) over the years. So there may have been a belief out there that their “clunkers” would never be completely eliminated.
Several years ago, I attended a number of meetings between a local user community and a nationally known software developer. The developer had recently purchased the software which was being used by the vast majority of nursing homes in Massachusetts. At the time, there was extreme consternation and frustration on the part of many facilities. I was actually quite skeptical as to whether this developer could actually keep its bold promises that appeared to be offered out of sheer desperation. But, in the end, this developer deserved a great deal of credit for keeping its promises and maintaining its system well beyond any reasonable time-frame expectations.
However, MDS 3.0 changes everything, and at some point there are both financial and foundational aspects that make it impossible for software developers to continue to apply workarounds to their legacy applications.
Ultimately, the discontinuance of older software is a practical, sensible and prudent decision as long as long-term facilities are given the opportunity to easily migrate to a more suitable replacement. But why wouldn’t we cling to the hope of new systems that wouldn’t require support for “DOS beasts,” their strange Central Processing Unit (CPU) workarounds, and endless printer driver conflict issues?
As an IT support firm, we’ve had to devote an inordinate amount of time to the maintenance of these legacy systems at the expense of more challenging and productive projects such as the implementation of hosting solutions which can more effectively move an organization into the “computing cloud.” (NOTE: Cloud computing is a style of computing in which dynamically scalable and often virtualized resources are provided as a service over the Internet.)
So where do we go from here?
Since many facilities have been presented with enticing offers that may expire soon, you will need to work fast if you want to consider other alternatives.
It wouldn’t be prudent to commit to any financial (i.e. general ledger and accounts payable) modules offered by just any software developer—unless you like being constrained by limited reporting and flexibility that inevitably results in mysterious and overly complex off-line spreadsheets that only one person in the organization knows how to use. Fortunately, most enterprises have already figured this out and have abandoned these mediocre systems in favor of financial applications from one of the big database players in the enterprise resource planning (ERP) software market.
At the other end of the spectrum, many small, free-standing facilities would probably be better off with one of the leading low-end systems—especially the inexpensive on-line versions which allow your accountant to work concurrently with you on your live system.
But if you fall in the middle, especially if you require audited financial statements, there’s hope and change available for you as well. Several mainstream ERP systems not only provide more reporting flexibility, these systems can also deliver industrial-grade budget, forecasting and Web-based distribution capability that may not even be on the drawing boards of many long-term care software developers.
If you are a not-for-profit, you can evaluate applications written specifically for your organization. But unless you produce monthly internal reports in compliance with FAS 117, or if you need to monitor a significant number of grants with different reporting periods and complex allocation requirements, a mainstream system will work just fine.
Finding a fit
Choosing the software was the easy part; now you need to figure out which clinical/billing software developer’s approach makes the most sense for your circumstances. Most people will probably be very impressed with the user interfaces available with the browser-based solutions. The key areas to focus on are the size of the existing installed base, the end-user customization alternatives available, and the developer’s approach to training and installation.
Browser-based systems represent a fundamental shift into “cloud computing,” the best part being that you don’t have to buy and support your own servers for these applications. But non-browser-based systems can also operate in a hosted environment, so this is actually not as significant a differentiator as it might initially seem to be.
Furthermore, the move to the cloud itself really isn’t as troublesome as some may fear. For example, in order to create a more highly available business continuity strategy, many companies have already moved their e-mail and backup functions into secure, redundant data centers. This makes sense operationally for a variety of reasons, not the least of which is the ability to potentially replace large capital investments in new hardware with more affordable and predictable monthly fees.
So with concerns regarding cloud computing out of the way, it’s the selection of the right software developer relationship that represents the most critical decision that you face.
Clinical, admissions and billing considerations
At the enterprise level, the prospect of using an extremely powerful system, even if it may have somewhat limited customization features, is very attractive—especially if you need to upgrade, migrate and roll out a solution to many facilities. If you represent a smaller group of nursing homes and want complete control over your clinical applications, then you may want to take a look at systems that provide ultimate flexibility in that area.
But be forewarned: If you want to design your own system, even if it does not require the services of outside programmers, make sure that you have staff with both the time and personal commitment to make the system work. Otherwise you’ve just wasted your money and you’ll be back looking for a new system very shortly.
If you are a free-standing facility or a very small group of homes, you will also want to be absolutely certain that you agree with the developer’s implementation approach, which could rely almost exclusively on remote training as opposed to on-site assistance. In other words, “Train the Trainer” makes sense unless your trainer is also responsible for several other duties like resident care, which always seem to get in the way.
The system selection process
First of all, a compelling purchase price alone is not a guarantee of a successful implementation; if it were, then open source software such as Linux would have obliterated Microsoft years ago.
Secondly, although data migration has always been a primary reason for remaining with the same developer in the past, that no longer has to be the case. Since everyone is required to submit the same standardized MDS data files, all of the developers have been able to design automated conversions of key resident information without having to get directly into the proprietary database of the existing applications in place.
Finally, always remember that the overarching key to a successful implementation remains competent and knowledgeable staff receiving meaningful, appropriate and customized training that is supplemented by timely and reliable ongoing support. This key to success simply can’t be translated into a “features comparison” formula or a quick comparison of bottom line numbers from the “Investment Summary” page.
With these fundamental principles in mind, before committing to any software developer’s system, it would be appropriate to at least take a quick look at some of the alternatives available before just signing up for the latest upgrade. There are some niche applications for organizations that provide a broader spectrum of care in areas such as continuing care retirement centers and home health care.
And, if you’re just not satisfied with the point-of-care systems bundled with the major clinical software systems, then you could consider a multi-developer strategy. But make sure that the developers involved can show you how the point-of-care system easily and seamlessly integrates with one centralized database of resident information.
If you have already made an internal investment in hardware that can operate in a self-hosted environment, or if you desire a more on-site implementation training approach, or even if you’re looking for the benefits of “cloud computing” but with more flexibility and control over your system, then don’t give up on the non-browser-based solutions. They may not be as pretty as the more flashy browser-based alternatives, but their systems are generally more mature and robust. What’s more, the software developers may be more willing to offer a more traditional on-site training approach at a reasonable price.
Time to get moving
In any case, you’ll need to act soon because regardless of the system you select, you will require time to plan and implement it before the MDS 3.0 deadline next fall. As for me, I will always look back fondly at those clunkers. It was a great ride, but now it’s time to get into line for a new and exciting trek with all the ups, downs, curves and breathtaking challenges that can be seen from up in the clouds.
John LoConte is a principal at KDSA Consulting, LLC, an information technology services firm located in North Andover, MA. LoConte has provided IT services to the elder care community for more than 25 years.
