Australian Governance, Privacy, and SaMD

A healthcare agent release in Australia is rarely governed by one document. Teams need to think across privacy obligations, professional accountability, platform-specific data-sharing constraints, and the point where intended purpose moves the system toward medical-device regulation.

In practice, release teams need a written intended-use statement, a local interoperability surface, and a retention policy for agent traces. Those design artifacts decide which governance obligations apply to the real system rather than the marketing description.

A system described as administrative support can cross into a more regulated category if it starts making or strongly shaping clinical decisions. Teams should decide early where the product sits and what behavior is explicitly out of scope for the first release.

A vague “administrative assistant” label is not enough. Teams need an intended-use statement that names what the system will and will not influence, which data surface it touches, and which actions always remain human-authorized.

A clinician or reviewer still needs to understand what the tool did, where the information came from, and whether the output is safe to act on. At the same time, the system design has to justify why it accessed health information, where it stored traces, and how much PHI was retained after the task finished.

Australian teams also need to anchor national-data workflows in the actual My Health Record FHIR gateway artifacts that are currently active. That keeps the design tied to the real local exchange surface instead of assuming a generic FHIR environment that might not match My Health Record request, response, and mapping behavior.

That operating model should also decide what notice is given to clinicians or patients when AI contributes to a workflow and how long PHI-bearing traces are kept. Trace retention, access logs, and patient-facing notice are governance choices, not afterthoughts.