Artificial intelligence can remove enormous amounts of administrative friction from a telehealth service. It can organise an intake, summarise approved information, route an exception, prepare a clinician’s work queue and help a patient understand what happens next.
But healthcare software operates inside a tighter boundary than ordinary business automation. In Australia, two different regulatory questions may apply:
These are related governance questions, but they are not interchangeable. A telehealth provider can create risk by treating them as one broad “AI compliance” issue—or by assuming that adding a human reviewer automatically removes the software from scope.
This article provides a practical starting point for Australian telehealth operators designing portals, workflows and AI agents. It is general operational guidance, not legal, clinical or regulatory advice.
On 16 October 2026, the TGA published updated guidance explaining how clinical decision support system software is regulated and when some software may be exempt from inclusion in the Australian Register of Therapeutic Goods (ARTG). The guidance also notes that it is under review to align with amendments taking effect on 1 November 2026.
Separately, updated Australian Privacy Principle guidance introduces additional transparency obligations from 10 December 2026. Covered APP entities will need to describe relevant automated decisions in their privacy policies, including the kinds of personal information used and the kinds of decisions made or substantially supported by computer programs.
For telehealth businesses, the practical lesson is simple: the controls need to be designed into the operating model before an AI feature goes live. They should not be added as a disclaimer after the workflow has already been built.
The TGA places significant weight on a product’s intended purpose. A workflow that schedules an appointment is not performing the same function as software intended to analyse clinical information and recommend treatment.
Start by writing down the intended purpose of every automated function in plain language.
The wording used in product pages, onboarding material, prompts and user interfaces matters. If a system is marketed as diagnosing, predicting or recommending treatment, its regulatory position may be different from a system designed only to organise and prepare administrative work.
The TGA’s guidance provides a staged way to think about clinical decision support system software:
A product can contain several functions with different intended purposes. A patient portal may include low-risk appointment booking, regulated decision support and ordinary communications in the same experience. Each function should therefore be mapped separately rather than assigning one label to the entire platform.
The OAIC’s automated decision-making transparency obligation is concerned with the use of personal information in decisions that could significantly affect an individual’s rights or interests.
Importantly, a computer program does not necessarily need to make the final decision by itself. The OAIC’s guidance says a program may still be substantially and directly related to a decision where its output is advisory or subject to human review. The strength and substance of that human oversight matter.
For a telehealth operation, the privacy review should ask:
A nominal approval button is not necessarily meaningful human oversight. If staff routinely accept an output without understanding its basis, the process may remain effectively automated in practice.
DigiKat uses four principles when designing AI-enabled operations around HubSpot.
HubSpot acts as the trusted operational context layer. Patient-facing communications, administrative statuses, tasks, bookings, documents and exceptions should reference a governed record rather than disconnected spreadsheets and inboxes.
This does not mean every piece of clinical data belongs in HubSpot. The data architecture should define what HubSpot is permitted to hold, what remains in a clinical system and how identifiers, permissions and integrations connect the two.
An authenticated portal should let patients complete permitted routine actions, see administrative status and understand what happens next. Good self-service reduces avoidable contact without pretending to replace clinical care.
An agent should receive a narrow job description, approved data sources and explicit prohibited actions. For example:
Named people retain consequential decisions. The system should make the approval step visible, record who approved it and provide enough context for a genuine review.
A practical pre-launch checklist should include:
Telehealth providers do not need to automate the entire patient journey at once. The safer commercial and operational approach is to begin with one visible bottleneck, such as incomplete intake, status enquiries, document routing or staff follow-up.
An AI Opportunity Sprint can map the current process, information boundaries, decision points and exceptions. From there, the organisation can decide whether the smallest credible next step is a self-service portal improvement, a bounded agent pilot or a broader one-record transformation.
The objective is not maximum automation. It is a measurable improvement in patient flow with clear accountability.
Useful healthcare automation should help the right person act with better context. It should not disguise a clinical decision inside an administrative workflow.
That means designing around one trusted record, useful self-service, bounded agents and real human approval. It also means treating TGA product regulation and OAIC privacy transparency as distinct design inputs—not as paperwork to consider after launch.
If your telehealth service is introducing AI, expanding a patient portal or trying to connect intake, pathology, pharmacy and staff workflows, DigiKat can help map a safe first step.
Book an AI Opportunity Sprint to identify one operational bottleneck, define the system and human boundaries, and develop a practical transformation pathway around HubSpot.