Every few weeks, a clinician shows me something they have built. 

It might be an artificial intelligence (AI) scribe tailored to initial assessments, a dashboard that identifies patients drifting away from their exercise program or a tool that helps triage a growing waitlist. 

Five years ago, these ideas might have required a software team and a six-figure budget. 

Today, a clinician with a laptop and an AI subscription can build a convincing prototype over a weekend. 

I think this is a wonderful development. Nobody understands healthcare’s problems better than the people working inside treatment rooms. 

Some of the most useful clinical software ideas that I see have come from clinicians who were tired of typing notes at 9 pm, chasing forms or watching patients fall through the gaps in an outdated system. 

But the demo is the easy part. The same conversation usually follows. Colleagues love the prototype. Someone suggests selling it. Perhaps another clinic wants to try it. 

Then the harder questions begin. What happens when 100 clinicians use it every day? 

Where does the patient information go? 

What happens when the AI is wrong? 

Could the tool be considered a medical device? 

Who is responsible when another clinic relies on it? 

That is the point at which a clever prototype must become a trusted healthcare product.

When Canva gets the economics wrong 

Canva recently provided a useful lesson in the cost of scaling AI. 

In August 2026, the Australian technology company reduced its expected annual revenue growth from 30 per cent to approximately 20 per cent after slowing the wider rollout of its new AI products. The issue was not a lack of demand. 

Instead, the cost of delivering each AI task was too high. 

Canva rebuilt parts of its architecture, developed more of its own models and reduced the cost of serving an AI task by nearly 90 per cent before accelerating the rollout again. 

This is a company valued at approximately USD $42 billion, with specialist AI teams and significant financial resources. 

Yet even Canva discovered that a product can work brilliantly while its economics do not. 

During a demonstration, a few cents per task barely registers. 

Multiply that cost across thousands of users, longer consultations, repeated generations, data storage, transcription and customer support, and the calculation changes quickly. 

Healthcare products face the same mathematics, with privacy, safety and professional accountability added on top. 

Follow the patient data 

Health information is treated as sensitive information under Australian privacy law. Health service providers are also generally covered by the Privacy Act 1988, even when they are small businesses. 

For clinician-builders, privacy obligations can apply from the moment real patient information enters the product – not only after the business becomes successful. 

The most important first step is simple: draw the complete journey of the patient data. 

Where does it go after the clinician presses submit? 

Where is it processed and stored? 

Does it leave Australia? 

Can the AI provider retain it? 

Can it be used to train future models? 

Which employees, contractors or other technology providers can access it? 

How long is it kept and how is it permanently deleted? 

Australian data residency and zero-retention arrangements may reduce risk but they do not replace proper due diligence. 

Offshore processing is not automatically prohibited, although it can create additional obligations and accountability under the Australian Privacy Principles. 

Ask for the answers in writing. 

Review the provider’s contracts, retention policies, security controls and breach-response process. State and territory laws, such as Victoria’s Health Records Act 2001, may also apply. 

Not every security incident must be reported publicly. 

However, organisations covered by the Privacy Act must notify affected individuals and the Office of the Australian Information Commissioner when an eligible data breach is likely to result in serious harm. 

Privacy cannot be added as a paragraph in the terms and conditions the night before launch. 

It needs to be designed into the product. 

The clinician still owns the output 

Ahpra and the National Boards’ guidance on AI makes the central principle clear: using technology does not transfer the practitioner’s professional responsibilities to the technology. 

Practitioners remain accountable for the care they provide and the records they create. 

They must understand the capabilities and limitations of the AI, apply professional judgement, be transparent about its use and consider informed consent – particularly when a tool records or processes a private clinical consultation. 

‘The AI wrote it’ will not excuse an inaccurate clinical note or an unsafe recommendation. 

This should influence how products are designed. 

A clinician must be able to review, correct and override every important output. 

The source information should remain available where appropriate. 

Uncertainty should be visible rather than hidden behind confident language. 

Important actions should be traceable. 

A review button alone is not meaningful human oversight if the output is so long, unclear or difficult to check that clinicians simply accept it. 

The product should make safe review easier, not merely make review technically possible. 

Know your intended purpose 

This is the regulatory question many clinician-builders do not ask early enough. 

The Therapeutic Goods Administration regulates software according to its intended purpose, not simply because it contains AI. Software intended to diagnose, prevent, monitor, predict, prognose or treat a disease, injury or disability may meet the definition of a medical device. 

If it does, it will generally need to be included in the Australian Register of Therapeutic Goods – unless it is excluded or exempt. Some basic clinical decision-support software may be exempt from register inclusion but exempt software can still be a regulated medical device. 

The important point is that the category can change as the product develops. Imagine a clinician builds a dashboard showing which patients have missed an appointment or have not opened their exercise program. That may be an administrative workflow tool. 

Then the clinician adds a feature that predicts which patients are deteriorating and recommends who should be contacted first. The product may now have a different intended purpose – and a different regulatory position. 

The Therapeutic Goods Administration gives a similar example involving an AI scribe. A tool that records and summarises a consultation may initially sit outside the medical-device definition. 

If it later begins suggesting diagnoses or treatments that were not discussed, its intended purpose changes and it may become classified as a medical device. 

The feature that makes the product more valuable may also be the feature that changes its regulatory category. Ask the question before launching the feature, not after signing the first clinic. 

Do not assume your insurance follows you 

A clinician’s professional indemnity policy covers the activities described in that policy. It should not be assumed that the same cover extends to software development, product liability, cyber incidents or claims involving another clinic’s use of a commercial product. 

Contact the insurer, describe exactly what the product does and obtain the response in writing. 

Depending on the product and business model, additional technology, cyber or product liability cover may be required. One phone call now is better than discovering an exclusion after a claim. 

Five questions before another clinic uses it 

Before moving beyond the prototype, answer these five questions clearly. 

What does one active user cost each month? 

Include AI processing, transcription, storage, integrations, support and heavy usage – not only the cost of a quiet test account.

Can you draw the complete data journey? 

Know where the information travels, who can access it, how long it remains and how it is deleted. 

What is the product’s intended purpose? 

Do not assume that calling it a ‘support tool’ keeps it outside the medical-device framework. 

Can the clinician genuinely review and override the output? 

Human oversight needs to be practical, informed and visible – not a check box buried in the interface. 

Who carries the risk when the product is wrong? 

Understand the professional, contractual and insurance position before another clinic depends on it. 

Keep building 

None of this is a reason for clinicians to stop creating. It is the opposite. Healthcare needs products designed by people who understand the work. 

Clinicians see workflow failures, administrative burdens and gaps in care that outsiders often miss. But the prototype proves only that something can be built. 

A trusted product proves that it can be used safely, sustainably and responsibly. In many industries, privacy, infrastructure and compliance are treated as overhead. 

In healthcare, they are part of the value offered to the clinician and the patient. 

Trust is not something added after the product succeeds. 

Trust is the product. Build the weekend demo. 

Show it to colleagues. 

Test whether it solves a real problem. 

Then do the slower work. Map the data. Test the economics. 

Understand the intended purpose. 

Design meaningful human oversight. 

Insure the risks. 

Do what Canva did: get the economics right before scaling. 

Do what healthcare demands and get the obligations right too. 

>>Barry Nguyen APAM is a physiotherapist, practice owner and software developer. 

He is the founder of CliniScribe AI, one of Australia’s fastest-growing AI scribe platforms for allied health, and advises on and invests in earlystage allied health technology. 

Disclosure: Barry Nguyen is the founder of CliniScribe AI, a commercial healthcare technology company operating in an area discussed in this article. This article provides general information only and does not constitute legal, regulatory, privacy, insurance or clinical advice. Requirements vary according to a product’s intended purpose, functionality, data flows, jurisdiction and insurance arrangements. Clinicians and developers should review current guidance from Ahpra, the Office of the Australian Information Commissioner and the Therapeutic Goods Administration and obtain independent professional advice where appropriate. The views expressed are the author’s own.