Why Refera never prioritises referrals

Who this page is for: a practice, integration partner or adviser checking exactly where Refera’s administrative role ends and clinical decision-making begins.

Refera’s current intended purpose

Refera tracks referral admin. It takes a referral from a connected inbox, keeps the source, shows the referrer’s exact words, prepares follow-up for staff to approve and records who did what. The complete original-document storage, retrieval and export checks must pass before real referrals. Refera does not interpret clinical content, compute acuity, recommend a priority or reorder the arrival queue using a clinical signal.

Refera tracks referral admin only. It does not triage patients.

That boundary is part of Refera’s intended purpose, product design, documentation and marketing. The TGA explains that software status and classification turn on the manufacturer’s intended purpose and functionality, including claims made in websites, advertising and technical documentation. A human making the final decision does not turn a clinical software function into an administrative one.

What HealthLink does not change

HealthLink is an inbound secure-messaging rail in Refera’s connector plan. A referral received through that rail is handled under the same rule as one received through a configured mailbox or fax-to-email path: Refera may carry the referrer’s stated urgency as attributed source content, but Refera does not turn it into a score, flag, ranking or recommendation.

Connecting HealthLink therefore does not add clinical prioritisation and does not change Refera’s intended purpose. It changes how a document arrives, not Refera’s administrative handling of it; Refera does not clinically assess patients.

Clinical prioritisation is not a Refera capability

Some practices will reasonably ask for AI to interpret referral content and recommend which patient should be reviewed first. That is not a hidden Refera feature or a connector setting. Any future AI clinical prioritisation capability would be run as a separate regulated-product program, with its own intended-purpose statement, claims, release boundary, evidence plan and regulatory decision. It would not inherit the current administrative posture merely because it shared an intake rail or a human reviewed its output.

Before development, pilot use or supply, that program would have to:

1. Define the exact intended purpose, users, inputs, outputs, clinical workflow and public claims.
2. Assess every function against the current TGA medical-device definition and software exclusions, and keep the conclusion as a controlled regulatory record.
3. If it is a medical device, determine the applicable risk classification from its intended purpose, the decisions it influences and the potential harm of an incorrect output.
4. Select and complete the lawful Australian pathway before supply, with regulatory evidence, validation and ongoing controls appropriate to the result.

The pathway is not predetermined:

Regulatory outcome	What the gate means
Excluded software	If every function meets an exclusion, the product is not regulated by the TGA and must not be included in the ARTG. The exclusion basis must be documented and reassessed when functionality, intended purpose or claims change.
Exempt medical device	An exempt device remains regulated but is not included in the ARTG. The program must document the applicable exemption and meet its conditions, including any notification, advertising and adverse-event obligations. The TGA currently states that AI-enabled CDSS will not meet the CDSS exemption criteria, so that exemption cannot be assumed for AI clinical prioritisation.
Medical device that is neither excluded nor exempt	The sponsor must obtain the evidence required for the applicable classification and secure ARTG inclusion before the product is supplied in Australia.

This is why Refera does not make a blanket claim that every clinical prioritisation function needs “TGA approval”. Similar workflow terms are used loosely in healthcare operations. The TGA assessment depends on the specific intended purpose, functions and claims. The precise gate is ARTG inclusion where required, or a documented exclusion or exemption where it applies.

If this boundary is ever reconsidered

AI clinical prioritisation is not part of Refera, has no release date and is not on Refera’s delivery path. It cannot enter the administrative product by feature creep. A future proposal must first have all of the following:

• a separately versioned intended-purpose and product-boundary document;
• a current, written TGA pathway assessment covering every function and claim;
• the applicable classification and conformity-evidence plan if it is a medical device;
• either ARTG inclusion before supply, or a controlled record establishing the applicable exclusion or exemption and its conditions;
• clinical validation, risk, human-factors, cybersecurity and post-market controls proportionate to the pathway; and
• TGA-experienced regulatory and legal review before any external pilot or marketing claim.

See Capability status for what Refera currently provides. The repository-level product roadmap records clinical prioritisation outside the current product rather than as a deferred Refera feature.

Official TGA guidance used for this page

• How the TGA regulates software-based medical devices
• Software-based medical device exclusions
• Exempt software as a medical device
• Clinical decision support system software regulation
• AI and medical device software regulation
• Classifying active and software-based medical devices
• Standards for software-based medical devices

This page describes Refera’s current product boundary. It is not legal or regulatory advice for another product.