Contracts Review Checklist

Checklists are an essential tool to assist in the successful selection, contracts review, and implementation of dental software. We have developed these checklists over a 15 year period of successfully assisting practices in these areas.

Note: The following items are meant only as a guideline to some of the contractual items to be aware of depending on your individual situation. This is not an exhaustive list and is not meant as a substitute for professional consultation on contractual matters.

Click on any below to display detailed descriptions and associated recommendations…

Warranties and Guarantees

Meaningful Use (If applicable) Eligible professionals who wish to attest for meaningful use need to write guarantees into the contract that the vendor will provide necessary functionality. In particular, certification is crucial to receiving the incentive and reimbursement, and that is a vendor responsibility. Vendors are rarely responsible for the receipt or actual payment of reimbursements, but ensuring that the software is eligible can be their responsibility. Each customer is responsible for accurate and complete reporting, communication and follow-through with the government program. In particular, practices should consider what stage or stages of meaningful use are included in the vendor’s contract for ongoing eligibility. If guarantees are only present for some of the stages, the software may not allow the dentist to be eligible for all stages. One question customers must ask is whether the clinical software (or EDR) is meaningful use compliant, or if additional modules are needed to attest. Some vendors offer separate meaningful use reporting tools or package EDRs with meaningful use software that is separate from the clinical software.

Vendors can agree to document and share changes to the meaningful use reporting across updates and upgrades, which can be helpful to practices. Then a user can quickly discern changes and functionality across versions. The timeframe and scope of revisions to the software should be specified, along with timeline for eligibility.

Key Points:
  • Functionality commitment
  • Timing and information around upgrades
  • Certification commitment, and which stages are included
  • Remedies and steps for non-compliance
  • Eligible professional responsibilities and vendor responsibilities
  • Are additional software modules necessary to attest for meaningful use? (Some certified EHR products are not complete EHRs, and the vendors are charging for modules that have been certified to meet MU criteria.)

Recommendation: The contract should include steps and remedies for non-compliance both for present and future stages of meaningful use. Remedies can include such provisions as service credits, financial penalties, or refund of the cost of software.

Functionality means that the software works as it should, in accordance with what the user documentation specifies for performance. This is usually guaranteed for a period of time after go-live. If bugs, errors or problems occur, the contract needs to include specific timeframes and steps for communication and fixes.

Key Points:
  • Functionality commitment across changes such as versions, regulatory requirements and software interfaces
  • The standard for functionality, which may be in the help files, reference materials or other documentation
  • Timeframes for fixing functionality, and remedies if timeframes are not met
  • Who can install the software under the warranty, including whether a practice member can install or if an authorized/certified representative must install
  • Eligible professional responsibility
  • Warranties about performance. Not all vendors will guarantee ongoing performance, due to interactions and complexity, but dental practices should ask about such warranties

Recommendation: If a vendor cannot repair functionality after the timeframe has elapsed, remedies should be spelled out.

In addition to meaningful use, many other regulations are critical for dental software. Regulatory conditions change over time, as rules and circumstances alter. Regulatory compliance in a contract is a commitment by the vendor to address and meet future regulations, such as changes to HIPAA or other regulations. A key question for practices to ask is whether that compliance upgrade is free to the practice, or if there will be additional costs or fees. The timeline for vendors to reach compliance should also be specified.

Recommendation: Ensure that vendor commits to regulatory compliance in a specified period of time, preferably at no extra cost.

Standards refer to specific kinds of functionality, for instance, interoperability or the ability to export to registries or accept input from device interfaces. Contracts usually spell out compliance for existing standards, and specify which standards are met by the software. In addition, the practice may want the vendor to commit to meeting new or revised standards. That may be difficult, particularly if the standards have not yet been completed. However, understanding how the vendor will work to remain in compliance with industry standards over time as well as government and certification standards, is key to ongoing software functionality. Practices should ask if standards compliance is included in regular upgrades or if there are additional fees. If a practice has unusual interfaces, the contract should specify any charges for a specific interface that does not meet an industry standard.

Key Points:
  • Health information exchange requirements
  • Evolving standards for interoperability
  • Data exchange for referrals, dental laboratories and to physicians
  • State registries for clinical research, if applicable
  • Imaging equipment and devices

Recommendation: Make sure vendor is committed to keeping up with evolving industry standards.

For software that stores, accesses and exchanges patient information, HIPAA compliance is key to legal and regulatory compliance. Controlling access to patient information and transmitting data securely should be the basis for healthcare IT.

Recommendation: Find out which software modules are HIPAA compliant and any processes that must be done to keep data secure.

Some software has remote disabling capability, allowing vendors to disable the software intentionally. This would be most likely during a dispute. If possible, a contract should specify that vendors will not include such mechanisms. If intentional disabling mechanisms are part of the software, the circumstances under which a vendor has the right to disable software functionality should be specified.

Recommendation: Vendor agrees they will not insert intentionally disabling mechanisms in their software. Disputes can be resolved through contract provisions, rather than disabling customer software.

Support and Maintenance: Addendums/Clauses

Vendors will assume various support and maintenance responsibilities for the software. This could include issue resolution, releasing updates, patches for bugs and new features or enhancements. Typically, vendors spell out their support and maintenance commitments.

Recommendation: Understand what items are included and excluded from vendor commitments.

Many aspects of hardware and software maintenance may fall to the client. The contract should specify client responsibilities for the software to function in the practice environment, including issue reporting responsibilities.

Recommendation: Understand and commit to client responsibilities to ensure the software will provide utility in the practice.

Components may be integrated into the software which are either licensed or purchased from 3rd parties. Examples are drug data bases, patient education databases, or electronic prescribing. The contract should specify the third party’s responsibilities and commitments, as well as methods for the client to report problems.

Recommendation: Understand any third party responsibilities and how to communicate if they are not met.

The duration of support must be specified in the contract. Often, the support term is an automatically renewing period of time, such as annual.

Recommendation: Know for how long your support coverage lasts, and if it renews automatically.

Make sure that you determine what the support hours are in your local time for each medium of interaction with a vendor.

Recommendation: Know your coverage times and how to reach the vendor for support.

Know when you can get support, and by what medium. Phone, email, discussion forum or portal and live technical troubleshooting are all options for vendor support. How do dentists report issues (online system, phone, email, etc.) and how does the vendor respond?

Recommendation: Keep a table of when and how you can reach support, and how the vendor will respond.

These clauses concern how long the vendor has to respond to an issue or support request and resolve the problem once reported. Response and resolution times can differ depending on the severity of the issue. Are there credits or reductions in cost associated with failure to meet response and resolution commitments.

How long it takes a vendor to fix an issue or respond to support request can affect a dental practice’s business and functionality. Resolution times can differ depending on the severity of the issue, and contracts may address these differences. For instance, a bug that causes opening a medication list to crash the system would be a more severe tier than one where printing could only be done landscape, instead of portrait.

  • Any additional support charges (for items not covered under support contract, such as hardware troubleshooting, fixes for data corruption, loss or deletion, custom feature requests, travel, etc.)
  • Time to resolution for different tiers of problems

Recommendation: Specify a timeframe that allows your practice to continue ongoing operations, and understand the severity tiers that dictate response time.

This is the process by which a customer can escalate an issue through the vendor organization if initial response is unsatisfactory. Typically, an escalation clause will define who the problem should escalate to within a certain period of time. The practice should keep a timeline of reported problems and if they have been resolved, so as to keep track of escalation.

Recommendation: In addition to reporting problems to the vendor, keep track of response time and know how to escalate if resolution does not occur in a timely fashion.

All software is upgraded and updated. However, different vendors support those upgrades in different ways. Dentists need to ask whether upgrades are included in vendor support, or if there are additional charges. In addition, dentists need to know if upgrades happen automatically, or if they need to take steps to implement those changes. The upgrade cycle and dates for communication from the vendor about changes to the software should also be clearly stated.

This type of provision is helpful to define what an update, enhancement, or new release is so there is no confusion, especially around additional charges. Also, it is typically specified how long a customer has to install an update. EHR vendors typically provide updates and feature enhancements based on their programming/release schedule. Ask a vendor for their general programming or version release roadmap to understand timing and available features/functionality. (Note: There may be various limits on vendor ability to provide or commit to detailed roadmaps.)

Updates may be included as part of a current, paid “maintenance/support” contract or may incur an additional fee, especially if focused on a specialty. Upgrades may include new or enhanced features, bug fixes, modifications, updates, and/or upgrades. Also find out steps to complete the upgrades, such as office closure, providing access to systems, etc. Generally, this information will only be available for the next release or two.

Recommendation: Understand how to ensure continued upgrades, if there are additional costs, and how often to expect them.

Any vendor-maintained support resources should be named and described in this portion of the contract. Examples include social networking sites, websites, manuals, help systems, user group meetings, webinars, videos, forums, etc.

Recommendation: Expect vendors to provide support resources beyond training.

Pricing and Payment Terms

For traditional software, often the cost is a fixed fee. However, the software payment may be broken up by various milestones. This can be defined in various ways, depending on the situation. For example, X% upon execution of contract, X% upon installation, X% upon Go Live, X% 30 days after Go Live. In this instance, the payment is directly tied to project milestones for accountability reasons—the vendor is not acting as a financing organization.

Recommendation: Always make sure there are logical payment milestones during the project. Payment should not be entirely up front.

This will depend on whether installation/implementation/training services are based on a fixed-fee or hourly model. A fixed fee might be typically broken up based on project milestones. An hourly model might be billed monthly or on some other frequency based on hours utilized. In this case, an updated time sheet is usually required by the dental practice.

Recommendation: Understand the payment terms for service during installation, implementation and training. Periodically audit hours billed if you are using an hourly model.

Often, payment occurs upon initiation of interface development and another payment upon interface completion. However, with lengthy projects, intermediate payment milestones may be established and required. The vendor should specify if there are additional charges for maintaining, upgrading and providing interfaces.

Recommendation: Make sure final payment doesn’t occur until the development of the interface is completed and can be demonstrated

Many contracts include planned price increases for ongoing services like maintenance or hosting. Some clauses provide for a period of time where the price is frozen before increases kick in. Sometimes there will be a cap on the amount these fees can increase for each period.

Vendor fee increases may be dictated by external factors, such as third party licensing. In those cases, vendors (and their clients) may be at the mercy of the third party vendors’ pricing policies. One potential standard for limiting fee increases on support/maintenance agreements is tied to economic indicators. This helps providers budget for recurring costs. For items that can have caps, increases may be based on an inflation index like the Consumer Price Index (CPI) or a multiple of the index.

Key Points:
  • Items that incur predictable increases
  • How often increases can occur
  • Basis and/or amount of increase and any caps

Recommendation: The initial pricing should be stable for a fixed period of time, and potential increases should have an annual cap.

Transition Assistance and Resources

Termination rights can be for a number of reasons, but are typically for breach of contract by either side. Generally, either party may terminate the agreement, although written notice is usually required within a specified timeframe. It is important to understand what fees might be refunded or retained by the vendor, as well as what items need to be provided/returned from the vendor to the client (data files) or from the client to the vendor (software documentation, CDs, etc.).

In most cases, the customer will be transitioning to another vendor. Upon termination or expiration of agreements, a vendor will usually provide read-only and/or print access to selected data as required by HIPAA. However, it is helpful for the vendor to agree to provide assistance in converting data to a new system (typically at a standard hourly rate). It may also be helpful to agree that the customer will be provided with structured data in an industry standard format. Recognize that this kind of system conversion does not begin until after termination, so confirm there is a time for customers to continue running the system for a defined period of time, and to receive support, for some period after termination

Key Points:
  • Scenarios where termination can occur
  • Notification method and timeline for termination
  • Access to data and format of data after termination
  • Transition time to cover software use and support after termination, during data migration
  • Vendor responsibilities regarding transition to a new system
  • Data conversion formats available

Recommendation: Assure that the vendor agrees to a transition plan.

All contracts should specify remedies for the customer if there is a breach of contract. Full and partial refunds can be written into the contract. Note that a contract provided by the vendor will many times emphasize customer breaches and associated remedies, but not what happens if he vendor is in default of the contract.

Customers need to consider and prepare for scenarios and remedies for their specific situations, in which the vendor might be in breach of contract. That may include items from data ownership, warranties or other items covered in this glossary.

Recommendation: Assure there are adequate remedies for vendor breach of contract and not just language regarding client breach.

Source code can be important to understanding and using the software, and source code escrow is particularly useful in the case that a vendor goes out of business or cannot adequately provide support for the product. The programs, databases and documentation necessary to operate and use the software in the absence of support are included in source code.

The cost of source code escrow should be spelled out, including who is responsible. Sometimes vendors are responsible for the cost, while other times customers are. The events around source code escrow, like scenarios of why it would be used, and the timeline for getting that information to the customer should be explicit.

Some elements to consider:
  • Who pays for escrow?
  • Under what circumstances would software escrow be invoked?
  • Specifically what code and programs are part of the software escrow?
  • How often is material in escrow updated?

Recommendation: Make sure that the vendor offers a source code escrow program.

At times, vendors will choose to “sunset” or retire particular software. The contract should provide specific responsibilities and steps if the vendor makes this choice. One common provision is that the vendor will replace the software with an equivalent system.

Customers will want to check the contract to see if they will incur fees, receive additional training, and what the timeline would be if the vendor does choose to sunset the product.

Key Points:
  • Replacement software, or “equivalent” software should be defined
  • Timeframe for replacement
  • Cost of replacement to customer

Recommendation: Customer needs to be notified of a sunset with enough forewarning to prepare for the transition. Customer should not incur cost of replacement software.

Data schema are representations of the underlying structure of data, detailing how information is organized in the database. When developing interfaces, transitioning systems or accessing information throughout the software, a data schema can be critical. Some vendors provide tools specifically for these purposes, but in some scenarios having direct knowledge of the underlying data schema is critical to ongoing operations and analytics. In particular, upgrades to the data schema that may occur behind the scenes of the user interface may alter functionality.

Customers should discuss with vendors whether data schemas are proprietary, and if so, whether or not they have access to the documentation. Some vendors will provide data schemas as long as customers assure confidentiality.

Key Points:
  • Definitions for data and schema elements
  • Scenarios when customers can view data schema; by request? As long as a licensed user?
  • Data schemas can be especially helpful during upgrades. How will the vendor communicate changes to the data schema?

Recommendation: Customer should request and try to obtain data schema.


If possible, the contract should define the types of data that can be transferred, the way the interface functions and any requirements for the interface to function. These definitions will be the first step in understanding interface problems. If the vendor supports particular interfaces, that should also be clear. Note that for health information exchange, further upgrades and development may be needed.

Recommendation: Define the data types and functionality of software interfaces. Request a list of all current interfaces.

Some interfaces may be to software within the practice, while others may be to national databases and registries. Interface functionality may be dependent upon compliance to particular standards.

Recommendation: Vendor needs to adhere to any national standards specified for interface or registry functionality.

If a customer requires a particular interface, the customer may pay to have it developed. In that instance, the question of who owns the interface may arise. If custom interfaces are possible, the contract should specify who would own those upon completion.

Recommendation: Intellectual property and ownership of custom interfaces should be clearly stated and, if the customer is paying for development, then the code should belong to customer.

Interfaces may not have the same upgrade and assurances as other parts of the software. Ask if there are assurances that interfaces will continue to work if either vendor changes or upgrades their portion of the interface. Will the vendor upgrade the interface as well? Will there be a cost?

Recommendation: Understand if the vendor will upgrade interfaces when the software on either side of the interface changes, and if upgrades and functionality are guaranteed.


If a customer’s assets are purchased, it is reasonable and customary for the software license to transfer to the purchaser. If license assignment changes, the vendor reasonably expects that the new licensee will adhere to all relevant terms and conditions for software use and maintenance. Upon transfer, the previous owner will stop using the software.

Key Points:
  • If vendor approval is necessary, then it should not be unreasonably withheld
  • The new assignee for the software license must adhere to the contract
  • Explicit scenarios where a client would assign the software license to a third party

Recommendation: Contract should include the ability to transfer the software license in the case of a purchase, acquisition or a merger.

A third party may claim that the dental vendor infringed upon or used previously developed code or software. In the case of such an infringement, legal action can be taken against the software vendor. This affects customers, and a contract should cover the effects and protections a customer has in this scenario. In this case, it is possible that customers could be banned from using a portion or all of the software.

Vendor remedies need to include securing the right to use the system, altering the software if it does infringe and/or issuing a refund or replacement software in a timely manner.

Key Points:
  • Warranty that software will be non-infringing
  • Options to allow clients to continue to use software
  • Remedies for non-compliance

Recommendation: Customers need to get a guarantee that software does not infringe, and steps for ensuring ongoing operations need to be clearly detailed in case a claim is made.

The vendor should not have the right to store or use patient data except to meet customer needs. Templates and custom forms developed by the customer may contain intellectual property that the practice should own. In that instance, vendors must be prohibited from sharing that information unless permission is provided by the owner. However, all basic and underlying forms and tables will be owned by the vendor and customers must not distribute them without permission. Customers are responsible for accuracy and validation of data, including managing data according to regulations and standards.

Key Points:
  • When clients produce custom or individualized content, who owns those solutions
  • If a client funds development projects that the vendor implements, who owns the created content?
  • What data is owned by the customer?
  • Can the vendor use patient or practice data, de-identified or not, for any purpose?
  • Steps and remedies for transgressions

Recommendation: Patient and practice data, as well as client developed intellectual property such as clinical templates, should be owned by the client.

The vendor and the customer will both most likely have access to confidential data about each other over the course of the relationship. A confidentiality clause ensures that both parties agree to protect confidential information and not share or disclose it. This confidentiality only applies to information acquired that is not generally public knowledge. In addition, a HIPAA BAA should be executed that addresses protected health information (PHI).

A business associate is someone who is not a member of the organization, but does work for them (for instance, a subcontractor). A BAA extends the confidentiality clause to include anyone with access to the data.

Recommendation: Ensure that there is a confidentiality provision addressing the fact that, through the life of the business relationship, each party will potentially have access to confidential information of the other. Also, a BAA needs to address potential HIPAA breaches based on the vendor/client relationship

A limitation of liability specifies a cap on financial penalties that the vendor can be held accountable for if significant problems occur. All software vendors work to limit their liability. Usually this is calculated based on multiples of system costs, or has to do with the payment schedule.

Recommendation: There should not be a cap on gross negligence or willful misconduct.

Travel expenses usually involve training and may include flight, hotel, selected expenses, etc. Expenses could be by the trainer coming to the site, or by the client visiting the vendor’s site. Whether travel expenses are included in hourly rates or are separate fees should be explicit. It is also reasonable for the client to ask to approve major travel expenses ahead of time so there are no surprises.

Recommendation: Bundled or separate travel expenses should be defined and clients may ask for pre-approval of those costs.

SAAS/Cloud Hosting

For web-based systems, software-as-a-service (SAAS) and cloud hosting, uptime is a very important metric. Uptime is the amount of time the software or program is accessible and usable. The contract should guarantee a specific amount of time over a defined time period that the product will be available, giving a particular uptime guarantee.

If a vendor does not meet the uptime guarantee, there should be penalties. For instance, when the guaranteed availability is compared to the actual availability over a month, are there any financial penalties to the vendor to compensate the client? Are credits offered to the client? In addition, if the vendor does not meet the uptime guarantee on numerous occasions or has chronic issues, the client should be able to terminate the agreement at no charge.

Recommendation: Uptime should be guaranteed, and clients should receive compensation if guarantees are not met, including the ability to terminate the agreement.

If data resides off-site, in cloud-hosted storage, vendors need to be responsible for ensuring access to and quality of those data backups. This clause should specify the process, method and timing for backups, including if more than one backup is stored.

If data corruption should occur, and there is no clean and error-free backup available, the vendor should have financial penalties.

Recommendation: Ensure that backup guarantees are matched by penalties for backup failures.

When data are stored off-site, the vendor becomes responsible for data breaches. This provision needs to specify how breaches are handled. The policies, remediation and data validation steps need to be spelled out.

Recommendation: Know how a vendor will handle a data breach, and what steps the practice may need to take.