Governance · safety · accountability

Trust should come from inspectable evidence and explicit limits.

Diagnify is a clinical decision support system in evaluation. This trust centre states what the product is intended to do, where it can fail, what users must verify and which claims are not being made.

In evaluationClinician oversight requiredNo autonomous use
Current status: Diagnify is not represented on this website as approved, cleared or authorised by any regulator. It is not intended for autonomous diagnosis, treatment, emergency triage or direct-to-patient advice. Regulatory obligations vary by intended use and jurisdiction and must be assessed before deployment.

Governance position

Clinical responsibility remains with qualified people and accountable organisations.

AI output is one input into care. A responsible implementation needs local ownership, defined scope, training, monitoring, escalation and a reliable way to stop use when risks exceed benefits.

Human authority

A qualified clinician reviews the case, verifies evidence and remains responsible for decisions and documentation.

Defined boundaries

Permitted users, tasks, populations, settings and escalation paths should be written before evaluation or deployment.

Ongoing surveillance

Safety depends on tracking failures, workflow effects, model changes and performance drift—not on a one-time benchmark.

Safety approach

Controls are designed around predictable AI failure modes.

Fluent output can still be clinically wrong. The workflow therefore needs to make checking easier and overconfidence harder.

  • Prominent evaluation and decision-support status
  • Red-flag prompts that still require clinician confirmation
  • Separation of supplied facts, inference and uncertainty
  • Evidence links that can be independently inspected
  • Change tracking and evaluation after material updates

Known limitations

What can go wrong.

The relevant risk is not only whether an answer is correct. It is whether the system changes attention, confidence, workload or action in a harmful way.

Clinical omission

The system may miss a diagnosis, red flag, contraindication, interaction, investigation or reason to escalate.

False confidence

Specific, well-written output may sound more certain than the evidence supports.

Evidence error

A source may be invented, outdated, misquoted, indirect or inapplicable to the individual patient.

Data and representation bias

Performance may vary across populations, languages, ages, conditions, settings and patterns under-represented in evaluation.

Context loss

Nuance from examination, trajectory, communication, family context or clinician intuition can be absent from the input.

Automation effects

Anchoring, deskilling, alert fatigue and workflow pressure can make a nominally advisory system more influential than intended.

Privacy and information governance

Use the minimum necessary information and verify the service terms.

Before entering clinical information, users and organisations should confirm that the authorised environment, contract and local policy permit it. Do not submit identifiable patient data to a demonstration or evaluation environment unless that use has been explicitly approved.

Questions an organisation should answer

  • What data are collected, processed and logged?
  • Where are data stored and for how long?
  • Who can access data and for what purpose?
  • Which service providers or subprocessors are involved?
  • How are access, deletion, incidents and breaches handled?
  • Are data used for model training or product improvement?

Commercial interests and conflicts

First-party evidence should be read as first-party evidence.

Diagnify has a commercial interest in the adoption of its product. Internal evaluations, product descriptions and benchmark reports may therefore be affected by selection, design, analysis and publication choices.

Results should identify who designed, ran, funded and analysed the work; which outcomes were pre-specified; what was excluded; and whether findings were independently reproduced.

Regulatory status

No claim of regulatory approval or clearance is being made.

Whether software is regulated—and under which pathway—depends on its intended purpose, claims, functionality, deployment and jurisdiction. Diagnify’s public material does not constitute a conformity statement, regulatory filing, certification or country-specific legal advice.

Before deployment

  • Define intended purpose and user population
  • Determine applicable classification and obligations
  • Complete clinical, technical and human-factors evaluation
  • Establish quality, incident and change-control processes
  • Confirm privacy, security and procurement requirements

Country content policy

Diagnify uses a globally neutral information architecture. Country sections will be added only when product availability, guidance or regulation is genuinely localised and maintained. This page does not provide jurisdiction-specific advice.

Illustrative authoritative reference points: the WHO guidance on ethics and governance of AI for health, the TGA overview of AI and medical-device software regulation, and the FDA clinical decision support software guidance. These links illustrate different governance and regulatory contexts; they do not describe Diagnify’s product status, confer approval or replace advice for the applicable jurisdiction.

Use with oversight

Assess the system before it influences care.

Start with intended use, evidence, local risk and a clear stop rule.

Open evaluation checklist