Skip to main content
← All articles

Healthcare Software SLA: What Australian Clinics Should Check

Hand-drawn SLA motifs frame clear title space

A healthcare software SLA is the part of your vendor contract that turns marketing promises into measurable commitments: how much of the time the system is available, how quickly the vendor responds when it fails, and what happens when it doesn’t. For an allied-health clinic, it decides whether a Monday-morning outage means a short delay or a day of lost referrals and cancelled appointments.

This guide is for clinic owners and practice managers. It explains what a good SLA contains, how to read the numbers, which Australian obligations sit behind it, and what to ask before you sign.

Meddle
Keep Referrals in One Place
Meddle helps allied-health clinics capture, triage and match incoming referrals, so fewer are lost when managing patient intake.
Visit Meddle

TL;DR

  • An SLA should state availability, response and resolution times, incident reporting, backup and recovery, and exit terms in measurable form.
  • A “4-hour SLA” usually means time to respond, not time to fix. Check whether it runs 24/7 or in business hours only.
  • You can’t outsource your privacy and security duties to a vendor. Use the SLA to verify, not just to trust.
  • Ask for data deletion and data export terms before you sign, not at termination.
  • Ask any vendor, including us, to put answers in writing.

Table of Contents

What a healthcare software SLA is

A service level agreement is a contract schedule that defines the service, the standard it must meet, and the remedy if it doesn’t. In software, it typically covers availability (uptime), support response, and sometimes resolution targets.

The Australian Cyber Security Centre’s guidance for executives says an SLA should document performance metrics, data ownership, availability levels and the vendor’s responsibilities for incident management and reporting. That is a useful checklist in itself. If your vendor’s SLA is silent on any of those, you have found a gap before it costs you.

Two things an SLA is not:

  • A guarantee that nothing will fail. It sets the standard and the consequence.
  • A transfer of responsibility. Your clinic still holds the duty to protect patient information.

The numbers that matter

Availability (uptime)

Uptime is usually quoted as a monthly percentage. The differences look small and are not. These figures are our own arithmetic for a 30-day month:

Monthly uptime Maximum downtime
99% About 7 hours 12 minutes
99.5% About 3 hours 36 minutes
99.9% About 43 minutes
99.95% About 22 minutes

For a clinic, the question is not only the percentage. Ask:

  • Is it measured monthly or annually? An annual figure can hide a bad week.
  • Which downtime is excluded? Scheduled maintenance is common. Check how much notice you get and whether it falls outside clinic hours.
  • Does the figure cover the whole service, or just the servers? A booking page that loads but can’t save a referral is still down for you.
  • How is it measured, and who reports it?

Response time versus resolution time

A time-bound metric like a “4-hour SLA” normally refers to the vendor’s commitment to acknowledge or begin investigating a critical issue, not to fix it. Resolution targets are a separate line, and many vendors only offer them as targets rather than commitments.

Read the priority definitions closely. A severity-one issue should describe the situation you care about, such as staff being unable to open patient records or referrals not arriving. Then check:

  • Does the response window run 24/7, or only during business hours?
  • Is the clock in your time zone? Support “hours” set in another country can leave a Sydney clinic waiting until the next morning.
  • What does “response” mean: an automated ticket receipt, or a person working the problem?
  • What are the update intervals while the issue stays open?

Service credits and break clauses

Most SLAs remedy a miss with a service credit, a discount on the next invoice. Credits are modest and rarely cover your real cost of an outage. What matters more is a break clause. Guidance on SLAs recommends that metrics be reviewed regularly and that repeated failure triggers a documented right to exit. Ask what pattern of misses lets you leave without penalty.

Incident response and breach reporting

An outage is an availability problem. A breach is a confidentiality problem. A good SLA covers both.

The Australian Signals Directorate’s cyber security centre notes that regulated entities may have mandatory reporting obligations within 12 to 72 hours of identifying a significant cyber security incident, depending on impact. Whether those specific obligations apply to your clinic depends on its circumstances, but the principle holds for every practice: you can only act quickly on an incident if your vendor tells you quickly.

Build these into the contract:

  1. A notification deadline. The vendor tells you of any incident affecting your data within a stated number of hours, not “as soon as practicable”.
  2. A named contact path. A real escalation route, including out of hours.
  3. Investigation support. The vendor helps you establish what data was affected and when.
  4. Containment and remediation duties. Who does what, and by when.
  5. Post-incident reporting. A written summary of cause and fixes.

Our own guide on meeting the Australian Privacy Principles in a clinic covers the internal side: what your team does once the vendor calls.

Your responsibility doesn’t transfer

The most common mistake we see described is assuming a cloud vendor is automatically secure. The Australian Cyber Security Centre is blunt about it: under the cloud shared responsibility model, you can’t outsource risk. The vendor manages some controls. You manage others, such as who in your clinic has access.

The OAIC’s guide to securing personal information explains that APP 11 requires entities to take active steps to protect personal information and to consider whether they still need to hold it. Health information is sensitive information, so your due diligence on a vendor should be proportionate to that.

In practice, this means your SLA should give you a way to check, not only a promise:

  • A right to receive regular service and security reporting.
  • A right to request evidence of the controls the vendor says it has.
  • Clear wording on who is responsible for what.

The Cyber Security Centre also advises that organisations ensure cloud providers hold appropriate security certifications and recent IRAP assessments. Ask for the current evidence and the date of it. A claim with no document behind it is marketing.

Backups, recovery and continuity

Uptime tells you how often the system is available. It doesn’t tell you how it comes back. Many SLAs promise a percentage and say nothing about recovery.

Ask the vendor to state in writing:

  • How often data is backed up and how long backups are kept.
  • The recovery time objective (how long until the service is restored) and recovery point objective (how much recent data could be lost).
  • When the recovery process was last tested.
  • What you can still do during an outage. Can your team access referral details or a patient list offline?

Your own continuity plan matters as much. Decide now how reception will take referrals and confirm appointments on paper or by phone if the system is down for half a day. The vendor’s SLA is the outer layer; your downtime procedure is the inner one.

Exit terms: data export and deletion

This is the clause practice managers skip and later wish they hadn’t read.

Export. Security guidance for government systems stresses being able to move data between platforms, so look for a commitment that your data can be exported in an open, documented format. Ask how long export takes and whether there is a fee. The Information Security Manual is the source for this type of control thinking.

Notice periods. Look for a minimum notice period for changes to the service or pricing. A month is a sensible floor.

Deletion. Data a vendor no longer needs is a liability. The OAIC’s investigation into a blood service data breach is a useful reminder: even an organisation with documented security policies and regular staff training was found to have gaps in how it handled personal information. Write into the contract that the vendor deletes or de-identifies data you no longer need, including backups, and confirms it in writing at termination.

Retention is a balance, because clinical records have minimum retention periods. Our data retention baseline for Australian clinics explains how to work that out before you ask a vendor to delete anything.

Four checks for ending a software contract

Where data is hosted

Ask where patient data is stored and processed, and ask for it in the contract. Be wary of vague phrases. A vendor should be able to say which region hosts production data, where backups sit, and whether support staff or subcontractors outside Australia can access it.

At Meddle, patient data is hosted in Sydney. We don’t make broader claims than that, and you should expect any vendor to be just as precise about what they will and won’t commit to.

Standards and conformance

If your software connects to national systems, ask for evidence of conformance. The Australian Digital Health Agency and the Department of Health publish conformance expectations for vendors, and the Department of Health notes that it is setting clear, consistent data standards and conformance requirements for technology vendors. The agency also publishes guidance on managing B2B software in production, which sets out how incidents and changes are communicated with the My Health Record system operator.

If My Health Record is part of your workflow, see our overview of My Health Record compliance for healthcare providers.

Our view: an SLA is a verification tool

We build referral intake, triage and matching software for allied-health clinics, so we think about what happens when a referral doesn’t arrive. A missed referral is a patient who waits longer, or never gets seen, and a clinic that loses work it earned.

That shapes how we think an SLA should be read.

  • Judge the SLA by the workflow it protects. For a clinic, the critical moments are receiving a referral, triaging it and allocating a practitioner. Ask a vendor which of your daily steps stop when the service is down.
  • Prefer plain terms to impressive percentages. A short SLA with a clear notification deadline, named support hours and an exit clause beats a long one full of exclusions.
  • Ask for evidence, not adjectives. If a vendor says “secure” or “compliant”, ask what document supports it and how old it is.
  • Put the answers in writing. Verbal assurances on deletion, hosting and support hours do not survive a change of account manager.

We would rather you ask us hard questions during a pilot than discover gaps after rollout. That’s why we offer a free 30-day pilot.

— Taylor

A checklist you can use this week

Use this when reviewing a current vendor or comparing new ones. Our longer healthcare software procurement checklist and security questionnaire for healthcare software go deeper.

Availability

  • Monthly uptime figure and how it is measured
  • Maintenance windows and notice period
  • Exclusions listed in full

Support

  • Severity definitions that match clinic scenarios
  • Response and resolution targets, and whether they are 24/7
  • Support hours in Australian time zones
  • Escalation contacts

Security and privacy

  • Incident notification deadline in hours
  • Hosting location for production data and backups
  • Evidence of independent assessment, with dates
  • Right to verify controls

Continuity

  • Backup frequency and retention
  • Recovery time and recovery point targets
  • Date of last recovery test

Exit

  • Break clause for repeated SLA failure
  • Export in an open format, with timeline and cost
  • Deletion and written confirmation, including backups
  • Notice period for changes

If you’re also tightening how your team shares documents, our 90-day plan for secure document sharing can run in parallel.

Try Meddle on your own referrals

Meddle captures referrals from GPs, NDIS support coordinators and other referrers in one place, triages them and matches each patient to the right practitioner. Pricing is AA$40 per practitioner per month ex GST, with a A$250 minimum, and the first 30 days are a free pilot. SMS notifications and CRM integration are optional add-ons at A$50 per month per practice each. See pricing or how it works.

Bring this checklist to the pilot and ask us the questions in it.

FAQ

What is an SLA in healthcare?

It is the part of a vendor contract that sets measurable service standards, such as availability, support response times and incident handling. In healthcare it also needs to cover privacy, data location and exit terms, because the data involved is sensitive.

What does a 4-hour SLA mean?

Usually it means the vendor will acknowledge and start investigating a critical issue within four hours. It rarely promises a fix in that time. Check whether it applies around the clock or in business hours only, and which issues count as critical.

What is an SLA for software?

A software SLA sets the level of service you can expect from a vendor: how often the product is available, how fast support responds and what remedy applies if the vendor misses the standard. It is usually a schedule attached to the main agreement.

Does an SLA make the vendor responsible for my patients’ data?

Not entirely. Under the shared responsibility model, you always keep some responsibility. An SLA defines the vendor’s part and gives you ways to verify it. Your own access controls, staff training and downtime procedures still matter.

Next step

If you’d like to see how Meddle handles referral intake and matching, and put your SLA questions to us directly, book a 30-minute demo.

Sources

This article is general information for healthcare businesses and isn’t legal, clinical or privacy advice. Check current requirements with the relevant regulator or a qualified adviser.