Healthcare software development in Australia: privacy, data residency, integrations and cost

Healthcare software development in Australia is ordinary software engineering plus four extra jobs: handling health information under the Privacy Act (and, in some states, health records laws), deciding where data lives and who can reach it, meeting a security baseline that stands up after an incident, and fitting the sector rules and systems you already work within. Settle those four early and cost comes down mostly to scope and integrations.

This guide covers who needs custom software, the regulatory map, data residency and offshore teams, security, integrations, accessibility, build versus buy, cost drivers and a vendor checklist. We are Inventure, a software company in Lalitpur, Nepal, so where offshore development comes up we have written from the inside.

This article is general information, not legal advice. Laws and programme rules change, so check the linked sources and get advice for your situation.

Who needs custom healthcare software?#

Most care organisations run on packaged software, and that is often the right call. Custom work tends to earn its place in five situations.

• NDIS providers whose service model does not fit a standard rostering-and-claiming platform, or who need several systems joined up. Our guide to choosing off-the-shelf or custom NDIS software covers that decision.
• Aged care and Support at Home providers adapting to the Aged Care Act 2024, quarterly budgets and new contribution rules. See what Support at Home providers need from software.
• Clinics and allied health practices, where practice management systems are mature but patient intake, referral portals, reporting and integrations are common gaps.
• Staffing and workforce businesses that manage credentials, agreements and onboarding. For Pro Team Group in Australia, for example, we built a website where nurses receive their agreements by email, sign them digitally and send them back.
• Health-tech start-ups building a product to sell, where the software is the business and questions such as "is this a medical device?" need answers before the first line of code.

If a mature product already covers most of your workflow, extending it is usually cheaper than replacing it. We come back to that under build versus buy.

The regulatory map for healthcare software development in Australia#

No single law covers "health software". Several regimes apply, depending on who you are, what the software does and which systems it touches.

The Privacy Act 1988 and the Australian Privacy Principles#

The Privacy Act covers organisations with annual turnover above A$3 million, and it also covers private sector health service providers whatever their size. If you provide a health service and hold health information, assume the Australian Privacy Principles (APPs) apply.

In software terms, the APPs become features and practices: a privacy policy and collection notices (APPs 1 and 5), limits on secondary use (APP 6), controls on overseas disclosure (APP 8), security (APP 11), and the ability to give people access to their information and correct it (APPs 12 and 13). Since 11 December 2024, APP 11 has made clear that reasonable security steps include technical and organisational measures. Our list of questions to ask a software vendor about health information turns these principles into a due-diligence table.

Health information is sensitive information#

Under the Act, health information is a category of sensitive information, which carries tighter rules. Under APP 6, you can generally use it for a secondary purpose only with consent, or where the purpose is directly related to why you collected it and the person would reasonably expect it, or where another exception applies. That matters the moment someone suggests reusing care notes for analytics, marketing or training an AI model.

State and territory health records laws#

The OAIC notes that in NSW, Victoria and the ACT, private sector health service providers must comply with both federal and state or territory privacy laws when handling health information. The laws are the Health Records and Information Privacy Act 2002 (NSW), the Health Records Act 2001 (Vic) and the Health Records (Privacy and Access) Act 1997 (ACT). Have your lawyer map which rules apply to you, then make retention periods and access-request workflows configurable rather than hard-coded.

The Notifiable Data Breaches scheme#

An eligible data breach is unauthorised access to, unauthorised disclosure of, or loss of personal information that is likely to result in serious harm, where remedial action has not prevented that risk. If you suspect one, you must take all reasonable steps to complete an assessment within 30 days, and the OAIC expects it to be much quicker where possible. Eligible breaches must be notified to the OAIC and affected individuals as soon as practicable. Our data breach response plan guide walks through the first hours, days and 30 days.

Your software decides how well you can respond: audit logs that show who viewed what, the ability to revoke access quickly, and backups you trust.

My Health Record, when it is relevant#

Many care and staffing systems never connect to My Health Record. If yours will, three things matter.

• Conformance. The Australian Digital Health Agency describes two kinds of testing: Notice of Connection testing of your software's web services interactions, and your own testing against the conformance profiles, finished with a Conformance Vendor Declaration. Some later changes mean retesting.
• Onshore rules. Section 77 of the My Health Records Act 2012 says the System Operator, registered repository operators, registered portal operators and registered contracted service providers must not hold or take My Health Record records outside Australia, or process or handle related information outside Australia, or cause or permit anyone else to. If your product will play one of those roles, offshore access to that information is off the table.
• Sharing by default. Under new rules from 1 July 2026, certain providers, starting with pathology and diagnostic imaging services, must upload key reports unless an exception or an approved extension applies, and Medicare benefits for certain services depend on it. Lab and imaging software needs to support that workflow and keep a record when an exception applies.

Once information is downloaded into a provider's local system, the OAIC says most My Health Records Act rules no longer apply to it; the Privacy Act, state and territory laws and professional obligations do.

NDIS rules#

All NDIS providers, registered or not, must follow the NDIS Code of Conduct. Registered providers are also audited against the NDIS Practice Standards and must have effective complaint and incident management systems and worker screening for certain roles. Registration is mandatory for some supports, and the NDIS Commission says that from 1 July 2026 it is also required for supported independent living and NDIS digital platform providers. Most reportable incidents must be notified to the Commission within 24 hours, so incident capture has to be quick and work on a phone.

The Aged Care Act 2024 and Support at Home#

The Aged Care Act 2024 started on 1 November 2025, alongside Support at Home, which replaced the Home Care Packages Program and the Short-Term Restorative Care Programme. The Act includes a Statement of Rights, and providers must show they have practices in place so their services are compatible with it. Providers register in one or more of six categories, and applications for categories 4, 5 and 6 involve an audit against the strengthened Aged Care Quality Standards. The Serious Incident Response Scheme covers home services, including Support at Home.

When software becomes a medical device#

The TGA regulates software that meets the legal definition of a medical device unless it is excluded or exempt, and that software must be included in the Australian Register of Therapeutic Goods (ARTG) before it is supplied. Deciding whether a product is a medical device is the manufacturer's responsibility, and one TGA example matters to anyone commissioning software: an organisation that outsources design and development, keeps responsibility for them and publishes the software under its own name is the manufacturer. For software that is a medical device, making it available here through an app store, website or cloud platform counts as supply in Australia, and the sponsor must be an Australian legal entity.

Some categories are excluded from regulation, including certain electronic health records, and some clinical decision support software is exempt. But in software with several functions, every feature must meet the exclusion criteria. A records system that gains a feature predicting deterioration may no longer be excluded, so check before you add it.

What is changing next#

Two changes are worth designing for now.

• Automated decisions. From 10 December 2026, privacy policies must describe the kinds of personal information used, and the kinds of decisions made, where a computer program makes, or does something substantially and directly related to making, a decision that could reasonably be expected to significantly affect someone's rights or interests. Automated eligibility checks, prioritisation and risk scores may be caught, so keep an inventory of them.
• Further privacy reform. On 31 August 2026 the Attorney-General's Department released an exposure draft of the Privacy Amendment (Personal Data Protection) Bill 2026, with consultation closing on 18 September 2026. Among other things, the draft proposes a "fair and reasonable" test for handling personal information, a 72-hour deadline to give the OAIC a statement about an eligible data breach, and an exception for "processors" acting on a "controller's" documented written instructions. It is a draft and may change.

Data residency and offshore teams (APP 8)#

Where your data is stored and who can reach it are separate questions. Hosting in an Australian region answers the first. APP 8 is about the second.

APP 8 requires you to take reasonable steps, usually an enforceable contract, before disclosing personal information to an overseas recipient, and section 16C generally makes you accountable for what that recipient does with it. The OAIC describes a disclosure as making information accessible to others outside your organisation and releasing it from your effective control. An overseas engineer who can read production health records therefore raises an APP 8 question, even if the database sits in Sydney. Your privacy policy must also say whether you are likely to disclose information overseas and, where practicable, name the countries.

The practical controls are straightforward:

• Keep production data in an Australian region, or in your own cloud account.
• Give offshore staff no standing access to production; grant time-limited, logged access with multi-factor authentication (MFA) when a task needs it.
• Build and test with synthetic data; the OAIC notes that synthetic data lets systems be tested realistically with less re-identification risk.
• Put APP-level obligations, breach notification and deletion into the contract.

Here is how we work. Inventure's engineers are in Nepal, and we have no Australian office or company. When data must stay in Australia, we host it in OVHcloud's Sydney region, and you can keep everything in your own cloud account (OVHcloud, AWS, Azure, Google Cloud or DigitalOcean) with us managing it. OVHcloud states that its ISO/IEC 27001, 27017 and 27018 certifications apply to services hosted in all its data centres except those in the US. Those certifications are OVHcloud's; Inventure itself holds no certification. There is more on how we work with Australian clients and on our trust and security page, and our APP 8 explainer for offshore development goes deeper.

Security baseline: start with the Essential Eight#

The Australian Signals Directorate's Essential Eight is a sensible floor for any system holding health information, alongside APP 11. It was designed for internet-connected IT networks, so some strategies, such as Microsoft Office macro settings, apply to your staff's computers rather than your web app. For a hosted health application, expect to see these controls.

Our explainer on the Essential Eight for small and medium businesses covers maturity levels, and the web application security checklist covers the application layer.

Integrations: FHIR, My Health Record and business systems#

Integrations depend on other organisations' systems and timelines, so map them first.

• Clinical data exchange. HL7 Australia's AU Base (version 6.0.0) and AU Core (version 2.0.0) implementation guides are both based on FHIR R4 and both marked trial-use as at September 2026. AU Base defines Australian concepts such as the Medicare card number; AU Core sets minimum expectations for recording, updating, searching and retrieving core health and administrative information. Even if nobody needs a FHIR API on day one, modelling your data so it maps cleanly to these profiles saves rework.
• National infrastructure. My Health Record, the Healthcare Identifiers Service, the National Authentication Service for Health (NASH) and secure messaging each have their own technical documentation on the Australian Digital Health Agency's Implementer Hub. Start there, and allow time for testing.
• Business systems. Care providers typically also run accounting, payroll, CRM, SMS and email tools. Two rules help: send the minimum health detail in SMS and email, and check where each provider stores data, because every integration is another possible overseas disclosure.

If you need systems to talk to each other, our API integration service is built for that work.

Accessibility: aim for WCAG 2.2 AA#

Your users include people with disability, older people and support workers entering notes on a phone between visits. WCAG 2.2 level AA is a sensible target. It added nine success criteria to WCAG 2.1, including Target Size (Minimum), Accessible Authentication (Minimum) and Redundant Entry, which speak directly to small screens, login friction and forms that ask for the same thing twice. Test with real assistive technology as well as automated checkers.

Build, buy or extend?#

Many organisations end up with a mix: a packaged core, a few integrations and one custom component where they genuinely differ.

What drives the cost of healthcare software?#

We do not publish a single price for health projects because these drivers vary so much.

• Workflows and roles. Each user type (participant, family member, worker, coordinator, clinician, finance) adds screens, permissions and testing.
• Integrations. The number of systems and the quality of their APIs often matter more than the size of the app itself.
• Compliance features. Audit trails, consent records, access and correction exports, retention settings and incident capture are real work.
• Data migration. Cleaning and moving years of records from spreadsheets or a legacy system.
• Hosting and environments. An Australian region, staging, backups and monitoring; see current plans and prices.
• Testing. Security and accessibility testing before launch.
• Life after launch. Patching, support and changes as the law moves, such as the December 2026 automated decision rules. See our support and maintenance service.

For a broader breakdown, read how much it costs to build a web app.

How a healthcare software project usually runs#

1. Discovery and data mapping. List what you will collect, who needs it and where it flows, including integrations and support access. A privacy impact assessment fits here; the OAIC lists them among the practices that support APP 1.
2. Hosting and access model. Choose the region, whose cloud account it lives in, and who can reach production and how.
3. Build in short increments. Use synthetic data so real records stay out of development and test environments.
4. Test before go-live. Run security and accessibility testing, and rehearse a restore from backup.
5. Launch with support in place. Monitoring, alerting and a breach response plan should be ready on day one.
6. Maintain. Patch, review who has access, and revisit privacy settings as the rules change.

Vendor selection checklist#

Use this list when you compare development partners or platforms.

• Where will our data be stored, and from which countries can it be accessed?
• Can everything run in our own cloud account, and can we take it back if we leave?
• Who has standing access to production, and how is access approved, protected with MFA and logged?
• Is real health information ever used in development or testing?
• How quickly will you tell us about a suspected breach, and what will you hand over?
• Which certifications do you hold yourselves, and which belong to your infrastructure provider?
• What experience do you have with FHIR, My Health Record or our accounting and payroll systems?
• What accessibility standard do you design and test to?
• Who patches the system after launch, and how fast?
• Will you help us answer privacy, access and correction requests?

A good vendor answers these with specifics and evidence. Our vendor questions for health information explain why each one matters.

What to do next#

If you are scoping a health or care product, our healthcare page explains how we work with providers and start-ups. When you are ready, talk to our team about your project and we will help you decide whether to buy, extend or build.