Obamacare: Meeting Implementation Challenges with Contracting Best Practices

Posted
By

The Affordable Care Act of 2010 mandated the creation of health care exchanges (“Exchanges”) which will enable individuals to shop on-line for health insurance beginning October 1, 2013. Creating and configuring the software, databases and interfaces that comprise the technology platforms for these Exchanges has created huge challenges for the fifteen States and the District of Columbia that have decided to build their own Exchange rather than rely on the Exchange being developed by the federal government, as well as for the health insurance companies planning to market and sell their insurance through these consumer portals.

The Exchange mandate has generated a massive amount of IT work and required more technological change than possibly any other federal law to date. To provide an idea of the complexity of building these platforms:

  • Software must be developed that permits multiple health insurers to offer multiple insurance products through a single government-run portal with a common look and feel.
  • The Exchange systems must interface with federal government databases for purposes of determining whether buyers are U.S. citizens or legal residents, and whether they are eligible for government subsidies.
  • Health insurers must integrate their enrollment and membership systems with the Exchanges in order to enroll new members and include them in their membership records, as well as put in place functionality for individuals to pay for their new insurance on the Exchange via credit card and ACH transactions.

Adding to the challenge of developing and implementing these new systems is the political uncertainty created by continuing efforts by opponents of health law reform to overturn the legislation.

To meet their Exchange objectives, health insurance companies have been confronted with the choice of whether to “build or buy” the necessary software functionality and technology necessary to get them up and running on the Exchanges. Given the looming October 1st deadline, many have elected to license the software from third parties and have the third parties integrate the software with existing systems. Relying on a third party to get this done presents its own set of risks. These risks can be mitigated however, by using certain “best practices” utilized when contracting with a third party to install and integrate a new software platform with existing systems. Those best practices include:

  • Implementation Project Plan – In connection with any system implementation project, the supplier will generally prepare an implementation project plan describing the steps to be taken to implement and integrate the software and the timing of those steps. This is important because there are generally multiple parties involved in a system implementation. In addition to the customer and the party licensing and implementing the software (which may be two separate parties), there may be one or more outsourcing suppliers who may be responsible for maintaining and operating existing systems which must be integrated with the new software, or a company providing staff augmentation services. The project plan helps to align all interested parties so that each party may have the proper resources available at the proper time, and deliverables completed as needed, in order for the project to stay on track. The project plan should therefore be included as contractual obligations of the impacted parties, and any changes should require the consent of the customer.
  • Critical Milestones – The customer and the supplier should identify key points in the implementation process (sometimes known as “Critical Milestones”) which reflect the achievement of important steps in the overall process, such as (1) functional and technical design documents completed; (2) configure, build, deploy and test the integration with the customer; (3) build, deploy and test the integration with the Exchange; (4) end to end testing complete, and (5) user acceptance testing complete. These Critical Milestones, along with the dates by which each of these must be achieved, should be included in the contract. The Critical Milestones can then be used as clear, bright line tests which, if they are not met on time, will entitle the health insurance company to terminate the contract if it chooses.
  • Financial ramifications for failing to achieve Critical Milestone on time. There is no better mechanism for incenting prompt performance by the supplier than to establish financial ramifications to the supplier that are triggered when the supplier either meets the Critical Milestone on time or fails to do so. One such approach is to allocate the implementation charge among the Critical Milestones, and state in the contract that the portion of the implementation charge associated with the Critical Milestone will only be paid when the supplier achieves that milestone. Another approach is for the parties to agree on an amount that the supplier will pay or credit to the customer if supplier fails to meet one of the Critical Milestones on the applicable date.
  • Acceptance Criteria – In order to avoid disputes, it is important for the parties to agree upon and document objective “acceptance criteria” which must be met before a Critical Milestone will be deemed to be achieved. This will ensure that the parties are aligned on what constitutes achievement of a particular milestone. The Acceptance Criteria should be agreed upon up front and included in the contract. If it is not possible to establish these criteria up front, it should done as soon as possible after contract execution. The parties should not wait until the Critical Milestone is ready for acceptance testing, since at that point it may be too late to address differences of opinion about what needs to be completed in order for a particular milestone to be achieved.
  • Key Supplier Positions. If there are particular supplier employees whose knowledge and/or skills are important to the success of an implementation, they should be designated as occupying key supplier positions. Such a designation generally means that the supplier will not remove that individual from the customer’s account for some designated period of time. This helps ensure that the key people will remain committed to the customer’s project and will not be transferred off of the customer’s project should a bigger client come along.
  • Software Escrow Agreement. For transactions in which the supplier is hosting or operating the software after it is implemented, health insurance companies and other customers should consider asking the supplier to establish an escrow for the software so that it may be accessed in the event that there is a serious with the supplier, such as a material breach of the agreement by supplier, or a supplier goes into bankruptcy. The escrow should include both the object and source code if the customer does not otherwise have access to the software, or just the source code if customer already has access to the object code. The negotiation here is generally around what the “trigger events” are that will trigger a release of the software from escrow.

Utilizing the foregoing contracting best practices will protect health insurance companies involved in system implementations to better meet their objectives regarding the new Exchanges, and will also benefit any other companies involved in system implementation transactions.