With computer systems ever more important and influential in our business and personal lives, its important to make sure a dental practice’s systems are adequately protected in every possible way. Gill Hall of law firm Hempsons has some legal guidance
Having the right IT systems can bring enormous benefits to any organisation, and purchasing a new software package can transform the way your practice collects, stores and uses data, carries out administrative tasks and processes workflows. As users become more competent and confident and use of the software becomes established as part of the daily routine, the IT system, and the data held on it, can develop into key assets with a significant value to the practice.
What is therefore surprising is how often practices overlook the terms on which these systems are purchased. This is particularly worrying as often the terms are the supplier’s standard form and are highly onerous, passing all the liability to the customer with no comfort or assurances being given by the supplier. There are some key issues that must be addressed. These include:
To licence or not?
Are you acquiring the software and installing it on your own servers or are you using the internet to access the software on your supplier’s servers? If it is the former, you will need a software licence; if it is the latter you may not, and may only need a services agreement. You may be taking a hybrid approach whereby you purchase the software but the supplier provides hosting services for you. Whatever form your software purchase takes, the legal documentation must reflect the right model – quite often it does not.
Additional services
Are any additional services required? For example, the installation or configuration of the software, training of users, further development work or support, data migration, maintenance or hosting services? Don’t just focus on the software, it is often the quality of the services that are the ‘make or break’ of an IT project’s success. All should be documented, and the charges and timescales for delivery clearly set out in the contract.
Expectations
How do you know the software will do as you expect? It is usual for there to be a period of acceptance testing, during which time the software’s function and performance are tested against key criteria agreed between the customer and the supplier. You should only be obliged to accept the software once the criteria have been met satisfactorily. There should also be a detailed technical specification, and the supplier should be willing to provide a warranty that the software will function and perform in accordance with that specification for a period after acceptance – usually between 90 days and a year. If the software fails in the warranty period then the contract should clearly set out what your remedies are: for example, to require repair, a replacement or a refund.
Ironing out problems
Significant errors should be ironed out in the warranty period. If you do encounter problems after that period, typically you will have a support arrangement to deal with user support enquiries (‘How do I do this?’) and faults (‘Help! It won’t work!’). It is important that the levels of service that are expected from the supplier are documented. It is usual to have a set of response times (how quickly they will come back to you if you report an error) and fix times (how quickly they will put it right).
Faults should be categorised by severity, and the response and fix times appropriate for the disruption potentially caused. Suppliers are often reluctant to commit to fix times as it may not be within their control to fix an error, so if you cannot negotiate minimum fix times, you should ensure it is clear what you can do if target response and fix times are not met. Often service credits are offered giving discounts off future support fees or additional support time.
Data protection
Often software systems facilitate the processing of personal data of individuals. For example, they may be used to store and manage HR information or to carry out payroll processing. The practice owning the data on the system is usually the data controller under the Data Protection Act 1998 and ultimately responsible for that data, including its accuracy, integrity and security. It is vital that the supplier and the software system provide adequate levels of security for the data, particularly if the software is to be hosted by the supplier or a third party.
Liabilities
The supplier will want to ensure it manages the risk under the contract by limiting its liability to you. Typically liability is excluded for consequential losses and things like loss of profits or reputation. Watch out for exclusions for loss of data, particularly where your system is to be hosted by the supplier. These are rarely acceptable, but commonly found. Liability is also often capped to a financial value. Check that the proposed value is adequate to cover the extent of losses that you might suffer if the supplier fails to abide by the contract. A cap at the value of the contract is quite common, but can often be negotiated upwards to a greater value or to the supplier’s insurance limit.
Intellectual property
Is the software an ‘off the shelf’ package or a bespoke product being developed for you, or is it an existing piece of software being modified to meet your needs? If there is any bespoke element, consider whether you should own any of the intellectual property in it. It may have value which you can exploit or you may simply want to ensure that your competitors can’t access it. You will also need access to the source code behind the software to be able to modify or develop it yourself. If you cannot negotiate full ownership of all aspects of the software, you may take a licence from the supplier but consider carefully its terms. What do you want to be able to do with the software in the future – adapt it, develop it further, or sell it? And what do you want to restrict the supplier from doing? For example, selling it to your competitors?
The ties that bind
Check whether you are tied to your supplier for support and maintenance and, where relevant, hosting of the software. Do you need the ability to keep the software but take the services elsewhere? Often contract terms prevent this, so you are tied to the supplier. If the supplier is hosting the software, ensure that the contract spells out what happens if that hosting arrangement ends. How do you get your valuable data back?
This article gives a flavour of just some of the legal and contractual issues you might encounter when buying a software package. A comprehensive review to fully understand the legal and commercial risks and to enable you to adequately protect your investment is always advisable. If in doubt… there’s an IT lawyer about!