Clinic software contract checklist: the data-export and exit clauses to read first

The clauses to read first in a clinic software contract are the ones about your data, not the feature list: who owns it, whether you can export it yourself in a usable format at no charge, whether there is an exit-assistance window, what happens to your copy after termination, and the auto-renewal notice period. The demo sells the product. These clauses decide how the relationship ends.

This is a clause-by-clause read from the clinic's side. It assumes you already accept that your clinic owns its data and should never be locked in. If that argument is new, read who owns your clinic data and how lock-in happens first, then come back for the contract mechanics. A vendor can agree your data is yours in a sales call and still hand you a contract that says otherwise. The signed page is the one that binds.

The data-ownership clause

Find the clause that says, in plain words, that your clinic owns the patient and billing data and the vendor only processes it on your behalf. It is sometimes titled "Data Ownership", sometimes buried inside "Customer Data" or "Licence". What you do not want is the reverse: language granting the vendor ownership, or a broad, perpetual licence to use your patient data beyond running the service.

A normal contract needs a narrow licence so the vendor can host and display your data, and that is fine. The line to watch is scope. "To provide the service to you" is acceptable. "For any business purpose, including analytics, in perpetuity" over identifiable patient data is not something to sign without a lawyer. If ownership is vague, or reversed, that is a reason to walk.

The export clause: free, complete, and in a format you can open

This is the clause that decides whether you are ever trapped, so it has to do three jobs at once.

• Complete. It should cover the whole dataset: patients, appointments, clinical notes, invoices, and the original document files like scans and reports. Not a sample.
• Usable format. Tabular data as CSV or Excel, documents as their original files. A PDF dump of one screen at a time is a picture of your data, not your data, because the structure is gone.
• At no charge, any time. Export should be a standard feature you run yourself, not a billable service the vendor quotes when you give notice.

The trap is what the contract leaves out. If export is not named as your right, a vendor can later treat it as a paid favour, priced at the worst moment. So write it in: a right to export all of your data, in full, in a machine-readable format such as CSV, at any time during the term and the transition period, at no charge.

The transition or exit-assistance clause

This is the clause most clinics never think to ask for, and the one that hurts most when it is missing. It commits the vendor to a defined window after you give notice during which your account stays readable and you can get your data out before access is switched off.

Without it, the failure looks like this. You give notice, the term ends, and on that date your login simply stops working while your migration is still half done. The data may be exportable, but you can no longer reach it.

So ask for a transition window in writing: a stated number of days after termination during which you retain read and export access. Thirty days is a common ask, but the right length depends on how much you are moving, so a multi-branch clinic should ask for more. The actual migration of records into the new system is a separate project you run during exactly this window, which is why the window has to exist first.

The post-termination data clause: what happens to your copy

The mirror image of export is deletion. Once you have your data out, what does the vendor do with its copy? A serious contract says it deletes your data within a stated window after the transition period ends, and confirms it in writing on request.

Read this clause together with the export clause, because they have to be sequenced correctly. Deletion must come after your export window, never before it. A contract that lets the vendor purge your data the instant the term ends, with no transition window, can cost you everything on a technicality.

One honest caution: a vendor's routine backups may hold residual copies for a while even after deletion from the live system, so ask how long backups are kept. The clause to want is a clear deletion commitment with a stated timeline and written confirmation.

The auto-renewal and notice-period clause

This one is commercial, not technical, and it catches busy owner-doctors every year. Many SaaS contracts renew automatically unless you cancel within a notice window before the renewal date. Miss it by a day and you owe another term.

Read three things together. The renewal term: does it roll over yearly or for some other period. The notice period: how many days before renewal you must give notice to stop it, often thirty to ninety days. And the price-change rule: can the vendor raise the price on renewal, by how much, with how much warning.

The practical move is to put the cancellation-notice date in your clinic's compliance calendar the day you sign. An auto-renewal you forgot is the quiet way a clinic stays on a tool it has outgrown.

The DPDP role split: fiduciary versus processor

This clause ties the contract to the law, and it is the one to read most carefully, because it is easy to misread who carries the duty.

Under India's Digital Personal Data Protection Act, 2023, your clinic is the data fiduciary for your patients' data, the party that decides why and how the data is processed. Your software vendor is a data processor, processing that data on your instructions. The India Briefing summary of the DPDP Rules 2025 puts the principle simply: the fiduciary remains responsible for the processor's compliance. The Act provides that a fiduciary may engage a processor only under a valid contract, and stays responsible for protecting the data regardless of any agreement to the contrary.

Two things follow. One, expect a data-processing clause or addendum that names the vendor as your processor, limits it to processing on your instructions, and addresses security and how it helps you meet patient requests. Two, no clause can transfer your fiduciary duty to the vendor. A contract claiming to make the vendor responsible for your DPDP compliance describes something the law does not allow. The duty stays yours; the contract governs how the vendor supports you.

This is also why a contract cannot make you compliant, a point we make in our DPDP Act primer for clinics. The DPDP Rules are recent and rolling out in stages, so treat the role split as the durable principle and confirm current detail with a professional.

How to use this before you sign

You do not need to be a lawyer to read these six clauses, but you do need a lawyer to bless the final wording. Mark up the draft yourself first: ownership, export, transition window, deletion, renewal notice, and the processor terms. For any clause that is missing, vague, or reversed, ask the vendor to fix it in writing before signing, and watch how plainly they respond. A vendor that answers data questions clearly is showing you how it will behave the day you leave. The questions to ask a vendor list surfaces these answers in a demo.

One honest note on our side. Avinya Plus keeps patient records structured and exportable, which is what makes a clean export possible rather than a fight, and our own pricing is quoted on a demo rather than published. But the clauses above are not Avinya promises to recite back. They are the standard to hold any vendor to, including us. The features page lists what our platform does and does not claim, so you can run the checklist against it too.

This is general guidance for buying clinic software, not legal advice. A contract is a binding legal document, so have a qualified lawyer review the actual agreement, and confirm your data-protection duties, before signing.