Software Licence Terms For Health Tech Platforms

Anika runs a Wellington health tech startup that has built a platform for clinics to manage patient intake forms, care notes and follow-up reminders. A group of clinics is ready to sign, but their practice manager asks a fair question: what happens if the system goes down during a busy morning, or if patient data is sent to the wrong place?

That moment can feel confronting, especially when your product is still growing. The good news is that a well-drafted health tech software licence in New Zealand can answer those questions clearly, protect your business and give your customers confidence.

Health platforms sit at the intersection of software, privacy and clinical workflow. Your terms need to do more than grant access to your product. They need to deal with health information, integrations, uptime, support and who is responsible when clinical users rely on the software.

What Should Your Health Tech Software Licence Cover?

Your software licence agreement should clearly set out who can use your platform, what they can use it for, what you'll provide and what risks each party is taking on.

For most health tech platforms, your customer will be a clinic, allied health provider, medical practice, aged care provider or other health organisation. Your agreement should be written for that B2B relationship, even if individual patients also use parts of the product.

A strong health platform software agreement usually covers:

• Licence scope: who can access the software, how many users are included and whether contractors, locums or related clinics can use it.
• Permitted use: whether the platform can be used for administrative workflows, clinical notes, patient communication, triage, reporting or decision support.
• Restrictions: no copying, reverse engineering, unauthorised integrations, reselling or using the platform to build a competing product.
• Fees: subscription charges, usage-based fees, GST, payment timing and what happens if payment is late.
• Implementation: onboarding, training, configuration, migration support and customer responsibilities.
• Support: how users raise issues, response targets and what support is included.
• Service levels: uptime commitments, planned maintenance and exclusions.
• Data: ownership, access, privacy, backups, exports and deletion after the relationship ends.
• IP: ownership of your software, custom features, feedback and branding.
• Liability: limits on claims, exclusions and any indemnities.
• Termination: when either side can end the agreement and what happens to the customer data afterwards.

Templates often miss the details that matter for health tech. A generic SaaS agreement may be fine for simple business software, but it may not properly deal with clinical users, sensitive health information or the operational impact of downtime.

Who Owns The Health Data In Your Platform?

Your agreement should usually say that the clinic or provider owns, or remains responsible for, the health information they put into your platform.

In practice, you're often hosting, processing or displaying data on behalf of your customer. That might include names, dates of birth, NHI numbers, appointment notes, test results, images, referral letters, medication information or patient messages.

Your terms should separate the different types of data in your product:

• Customer data: patient information, clinic records and content uploaded by the customer.
• Your platform data: software code, interface design, workflows, templates and system documentation.
• Usage data: analytics about how the platform is used, such as logins, feature use and performance data.
• De-identified or aggregated data: data that no longer identifies an individual and may be used for product improvement or insights, if your terms and privacy practices allow it.

Be careful with de-identified health data. True de-identification means a person can't reasonably be identified from the data, including when it's combined with other information. If the data can still identify someone, it's personal information under the Privacy Act 2020.

Your software licence and any data licence terms should say what your business can do with data. For example, you might need permission to:

• host and process data to provide the platform;
• use backups and logs to maintain security;
• access data for support, troubleshooting or migration;
• use aggregated insights to improve your product; and
• delete or return data when the agreement ends.

You should also be clear about data export. If a clinic leaves your platform, they will usually expect a practical way to access or export their records. Your terms should explain the format, timing, fees if any, and how long you'll keep data before deletion.

How Should Your Terms Deal With Privacy And Health Information?

Your terms should explain how you handle personal information and health information, and they should support your customers' obligations under New Zealand privacy law.

The Privacy Act 2020 applies to personal information in New Zealand. Health information is often more sensitive in practice, and health providers may also have obligations under the Health Information Privacy Code 2020. Even if your business isn't the healthcare provider, your platform can still create privacy risk for both you and your customers.

Key Privacy Issues To Cover

Your software licence and privacy policy should deal with:

• Purpose: why you collect and use personal information through the platform.
• Security: the technical and organisational measures you use to protect data.
• Access controls: user permissions, role-based access and audit logs.
• Subprocessors: whether you use cloud hosting providers, support tools, analytics tools or overseas service providers.
• Overseas disclosures: whether personal information is stored or accessed outside New Zealand, which can raise issues under Information Privacy Principle 12.
• Privacy breaches: how you'll notify your customer if there's a breach.
• Patient rights: how access and correction requests are handled.
• Retention: how long data is kept and what happens when the customer leaves.

Under the Privacy Act 2020, a notifiable privacy breach generally needs to be notified to the Privacy Commissioner and affected individuals if it has caused, or is likely to cause, serious harm. Your contract should require both sides to notify each other quickly so the right party can assess and manage the breach.

For example, if your support team accidentally gives a clinic admin access to another clinic's patient records, your agreement should make it clear who investigates, who contacts whom, what information needs to be shared and who communicates with affected people.

Security Promises Need To Be Realistic

Clinics may ask for strong security warranties. You can give comfort without promising perfection.

For example, instead of saying your platform is completely secure, your terms could refer to reasonable security measures appropriate for the nature of the information, such as:

• encryption in transit and at rest;
• multi-factor authentication where supported;
• access logging and monitoring;
• staff confidentiality obligations;
• secure software development practices;
• regular backups; and
• incident response processes.

If your security documents say one thing and your product does another, that can create legal and trust issues. Keep your contracts aligned with how your platform actually works.

Do You Need Service Levels For A Health Platform?

Yes, you should usually include service levels if clinics rely on your software during day-to-day healthcare operations.

Service levels are especially useful for health platforms because downtime can affect appointments, patient communications, triage workflows and clinical administration. They help set expectations before something goes wrong.

Your support and maintenance terms might cover:

• Uptime: the percentage of time the platform should be available, excluding planned maintenance and agreed exclusions.
• Maintenance windows: when you can take the system offline for updates.
• Incident categories: critical, high, medium and low priority issues.
• Response times: how quickly your team will acknowledge an issue.
• Resolution targets: whether you commit to fix times or only work-around targets.
• Support channels: email, portal, phone or emergency contact processes.
• Customer responsibilities: internet access, supported browsers, device requirements and accurate issue reporting.

Be careful with hard uptime guarantees if you're still early stage or dependent on third-party infrastructure. It may be better to offer service credits for certain outages rather than open-ended compensation.

You should also think about suspension rights. Many SaaS terms allow suspension for non-payment or misuse. For a health platform, sudden suspension could affect patient care or clinic operations. Your terms can still protect you, but you may want notice periods, limited access for data export, or emergency exceptions where appropriate.

What Happens When Your Software Integrates With Clinical Systems?

Your terms should clearly allocate responsibility for integrations, because third-party systems are often outside your control.

Health tech platforms commonly connect with practice management systems, booking tools, payment providers, pathology systems, telehealth tools, email or SMS gateways, identity tools and reporting dashboards. These integrations can be valuable, but they also create risk.

Your agreement should explain:

• which integrations are included in the subscription and which cost extra;
• whether integration work is standard configuration or custom development;
• who is responsible for providing API keys, credentials and permissions;
• what happens if a third-party system changes, breaks or becomes unavailable;
• whether data syncing is instant, delayed or manual;
• who checks migrated or synced data for accuracy; and
• whether you can disable an integration for security, compliance or technical reasons.

Say MedLoop connects to a clinic's practice management system and pulls appointment data every 15 minutes. If the third-party provider changes its API overnight, appointments may stop syncing. Your licence should make it clear that you'll use reasonable efforts to restore the integration, but you aren't automatically responsible for every problem caused by the third-party provider.

If your software supports clinical decision-making, be even more precise. For example, if your tool displays alerts, flags missing information or suggests follow-up actions, your terms should explain whether the tool is administrative support, clinical decision support or something more regulated. The answer can affect your risk profile and the wording of your warranties and disclaimers.

How Should You Limit Liability For Clinical Users?

You should limit liability in a way that matches the role your software plays in the clinical workflow.

If your platform is used by healthcare professionals, your terms shouldn't pretend that clinical risk doesn't exist. Instead, they should clearly explain the boundaries.

Common liability clauses in SaaS terms include:

• a cap on your total liability, often linked to fees paid over a set period;
• exclusion of indirect or consequential loss, where appropriate;
• no liability for customer misuse, incorrect data entry or unauthorised access caused by the customer;
• no liability for third-party systems outside your control;
• customer responsibility for clinical decisions and professional judgement;
• indemnities for the customer's unlawful use of the platform or breach of privacy obligations; and
• separate treatment for confidentiality, privacy, IP infringement and payment obligations.

The right liability cap depends on your product, customers, insurance, revenue and the level of clinical reliance. A cap that's too low may be rejected by enterprise customers. A cap that's too high may create a risk your business can't carry.

Do Not Overstate What The Software Does

Your marketing, demos and contract should all match. Under the Fair Trading Act 1986, you shouldn't make misleading claims about what your platform can do.

If your website says your app detects urgent conditions, prevents medication errors or guarantees better patient outcomes, your contract can't quietly walk that back. Claims like that may also raise regulatory and product risk beyond a standard SaaS agreement.

If your product is for workflow support, say that clearly. If clinicians must review outputs before relying on them, say that too. Your terms should help customers use the product safely, not hide the ball.

What About The Consumer Guarantees Act?

If you supply software to a business in trade, you may be able to contract out of the Consumer Guarantees Act 1993 where the law allows and where it's fair and reasonable to do so.

That position can change if you provide an app or service directly to patients or consumers. If your platform has both clinic-facing terms and patient terms of use, you may need separate terms for each group. The clinic terms can deal with business risk, while patient terms should be written for the individual user experience.

Key Takeaways

• A health tech software licence should cover more than access to the platform. It should deal with data, support, uptime, integrations, IP and liability.
• Health information needs careful handling under the Privacy Act 2020, and your terms should support your customers' privacy obligations.
• Service levels help clinics understand what support and uptime they can expect, especially where your software supports daily healthcare operations.
• Integrations should be covered clearly, including third-party outages, data syncing, API changes and responsibility for checking migrated data.
• Liability clauses should reflect how your software is used in clinical workflows, without overstating or understating the risk.
• If your product is used by both clinics and patients, you may need separate B2B and user-facing terms.

If you'd like help with your health tech software licence, privacy terms, service levels or data protection clauses, you can reach us at 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.