Sep26:Medical Software Licensing – Tips from the Trenches

By Eric Stevens

Medical offices are adopting complex software products such as electronic health record (EHR) systems and practice management systems in increasing numbers. While the ultimate hope is to improve patient care and practice efficiencies (and qualify for governmental incentives), short-term results for many practices do not meet expectations.  A 2013 survey by the American College of Physicians, for instance, found that user satisfaction with EHR systems fell by 12 percentage points between 2010 and 2012. In some cases medical practices have discontinued use of unsatisfactory software systems and even initiated lawsuits against vendors, alleging that the software was defective or the vendors misled them about its capabilities.

Any medical practice that has terminated an unsatisfactory software license and then fought a litigation battle with the vendor will tell you that the experience was quite debilitating (regardless of the outcome of the lawsuit). The disappointment of a failed effort to adopt new software would be bad enough even if not compounded by the expense, distraction, and uncertainty of litigation and the need to find replacement software. Fortunately, though all major software projects have their share of hiccups, few result in failure and litigation. Our experience as litigation counsel for software customers against their vendors has shown that  failed software implementations tend to result from a common pattern of errors in the software selection, contract negotiation, and software installation phases of a project.  Avoid these common errors and your practice will be much more likely to find satisfaction in your new software package.

Software Selection Mistakes

Medical practices and their IT staff are typically savvy enough to pursue a deliberate software selection process that includes a detailed request for proposals, careful scoring of request for proposal (RFP)responses, hands-on demonstrations, and careful consultation of references. Despite this, software project failures often occur simply because the customer selects the wrong software. Here are a few common software selection errors that customers make.

1. Selecting Untested Software. Given a choice between a cutting-edge product with enticing new features and a mature product with more basic features offered by an established vendor, it can be tempting to choose the newer product with more features.  The companies that end up in litigation, however, tend to be the ones that select the untested product. Even mature software can be risky if you are counting on new features that have not been widely tested and used. At a minimum, if you select unproven software or software with untested features (or designed to satisfy new governmental standards such as “meaningful use” of EHR systems), seek robust warranties and plan to be patient while the vendor addresses the inevitable bugs and issues that accompany untested software and software features.
2. Selecting Software That Requires Building New Interfaces.  New software systems often must seamlessly share data with existing information systems.  For instance, a new EHR system should be able to exchange patient information with your existing practice management system.  Despite industry and governmental standardization efforts, however, health care software products are not as compatible with one another as they ought to be, and many failed software projects were bedeviled by difficulties in building interfaces.  The safest course is to seek confirmation that the systems you want to connect are already successfully speaking to one another, using the same interface your practice will employ, at several other medical practices similar to yours.  If this is not possible and it will be necessary to build a new interface, be sure to include ample time in the project schedule to complete the task and be sure that the vendors of all affected software will cooperate as necessary.
3. Excessive Reliance on Sales Promises. Software litigation often turns on the customer’s claim that the vendor—whose sales representatives operate on commission—made misleading representations about the capabilities or features of the software.  These claims are usually complicated, at a minimum, by disclaimer language in the license agreement.  Generally, your practice should not expect software to satisfy any metric or include any feature unless that capability or feature is identified as fully operational in the written contract (e.g., through an RFP response incorporated into the agreement).  If the vendor’s sales representative promises to add a new feature or capability to your software or claims that the software can be configured to satisfy your need, this claim should be memorialized in the agreement, which should also specify: (a) when the feature or function or configuration will be ready; (b) how much it will cost, if anything; (c) that the new feature will not adversely affect the other operations of the software; and (d) that the vendor will provide full support for the new feature consistent with its support for the entire software product.

Contract Negotiation Errors

After selecting the wrong software, customers often fail to protect their interests during contract negotiations. Contract negotiations should be handled by qualified legal counsel, and this article does not provide a comprehensive checklist of necessary license provisions. Here, though, are three common contract drafting errors that software customers make.

1. Failure to Demand Adequate Warranties.  When you are spending substantial time and money on new software, it is inexcusable not to insist that the vendor fully stand behind its product. Warranty language will depend on many factors but at a minimum should provide:  (a) that, for a reasonable period of time following acceptance of the software, all material features of the software (identified in detail in writing), including any custom features and interfaces, will operate properly without defect; (b) that hardware provided by the vendor will operate without defect for a reasonable time; and (c) that all services provided by the vendor will be provided in a timely, skillful, professional, and workmanlike manner by qualified and experienced personnel in accordance with industry standards. If you expect the software to satisfy particular requirements—for instance EHR “meaningful use” requirements or HIPAA or HITECH privacy and security standards—the written warranty should adequately cover these and provide satisfactory remedies in the event of a breach. Of course the contract also must provide adequate levels of support after implementation.
2. Failure to Secure Adequate Leverage. A good contract should build in multiple leverage points to keep the vendor – which may be apt to lose focus after locking you into the agreement — on track. The contract price should be payable in installments tied to specific project milestones rather than paid in advance.  The final payment should not be due until after you accept the software. Acceptance should not occur until the software is installed and operating in your practice and you have fully tested all of its features and found them satisfactory. There should be a formal “notice and cure” procedure to address defects or bugs that arise during the installation period. A written project schedule should specify realistic deadlines for completion of major milestones and the contract should provide that “time is of the essence,” thus giving those deadlines teeth. Finally, the contract should provide that the vendor cannot hold you in breach for withholding any payment if you dispute whether payment is due in good faith, give notice of the basis for the dispute, and place disputed payments in escrow until the dispute can be resolved.
3. Failure to Demand Qualified Support Personnel. Software implementation failures can often be attributed to incompetent or inexperienced vendor support personnel who fail to respond adequately to issues that arise in the course of a project. Customers should demand contractual assurance that the project manager assigned by the vendor is qualified and has substantial experience implementing your software and should ask to speak to a representative of another practice who worked with the same person. Customers should also push for the right, at least once during the implementation phase of the project, to require the vendor to replace an unsatisfactory project manager.

Software Implementation Errors

A smart selection process and a good contract do not by themselves guarantee a successful software project. There are plenty of errors to be made after the contract is signed. Here are three to avoid.

1. Failure to Fully Commit.  Busy medical practices sometimes enter into software projects without planning properly and devoting adequate resources to the task. You must assign appropriate personnel to the project and ensure they have the time, tools, and institutional support to complete the work. Everyone in the organization must participate in training and make the effort needed to properly use the software once installed.
2. Failure to Communicate Clearly with the Vendor. Issues inevitably arise during any software implementation, but the vendor can only address concerns you clearly and promptly articulate.  Problems allowed to fester are much more difficult to solve. Comply with the vendor’s reporting procedures and be mindful of any contractual notification requirements. Consider suggestions and work-arounds offered by the vendor with an open mind, but be firm in expecting the vendor to deliver what you bargained for in a timely manner. Keep clear records of all vendor communications. Document all agreements and understandings you reach with the vendor during implementation.
3. Failure to Use Your Leverage.  A well-negotiated contract is only useful if you take advantage of the tools it provides. If the software is defective or the vendor’s performance is inadequate, use the leverage at your disposal. Withhold interim payments until you are satisfied that the vendor has reached the associated milepost. Do not accept the software until it is fully operational and all features have been tested. Use your right to place disputed payments in escrow. Demand that unsatisfactory or inexperienced support personnel be replaced.

So long as you are careful to avoid these common errors that can lead to vendor disputes, the odds are great that your practice will successfully adopt and reap the benefits of your new software.

Source