Human authority
A qualified clinician reviews the case, verifies evidence and remains responsible for decisions and documentation.
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.
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.
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 require concrete service terms.
Before entering clinical information, users and organisations should confirm that the authorised environment, deployment agreement and local policy permit it. Do not submit identifiable patient data to a demonstration or evaluation environment unless that use has been explicitly approved.
Public-documentation status: this page does not yet provide a complete security white paper, data-processing agreement, subprocessor register, regional retention schedule or independent security certification. These records should be reviewed before clinical data are sent to the service.
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?
Dedicated API environments
Private deployment needs contract-backed boundaries.
For approved organisations, Diagnify may provide a dedicated, single-tenant model endpoint and customer-specific retrieval environment. Availability, deployment region, level of isolation, data retention, logging, support access and security controls are defined in the applicable deployment agreement; they are not universal promises made by this page.
Customer separation
The agreement should state how prompts, outputs, uploaded documents, retrieval indexes, customer-specific adapters and logs are separated from those of other customers.
Model and infrastructure boundary
A dedicated endpoint does not by itself mean customer ownership of the model weights or dedicated physical hardware. The agreement must distinguish logical tenancy, compute isolation, weight access and customer-specific components.
Authorised processing
Authorised Diagnify personnel and named subprocessors may need to process data to operate, secure, support or meet legal obligations for the service. Those roles, purposes and access controls should be disclosed.
No absolute “no sharing” claim: where a deployment agreement includes customer isolation and no-training terms, customer content should not be used to train a shared Diagnify model or be exposed to another customer. That restriction does not remove disclosed processing by authorised personnel or subprocessors needed to provide the service.
Deployment record
What each customer should receive in writing.
- Logical or physical tenancy and network boundary
- Model, adapter, retrieval-index and data-store isolation
- Encryption in transit and at rest, including key ownership
- Deployment region and cross-border data transfers
- Logging, retention, backup and verified deletion schedules
- Role-based support access and customer-visible audit records
- Named subprocessors and incident-notification terms
- API versions, model changes, rollback and deprecation policy
Training use and data rights
The agreement should say whether prompts, outputs, uploaded documents or feedback can be used for service improvement or model training. A no-training restriction should be explicit rather than inferred from the word “private.”
It should also distinguish API access from access to model weights, identify the applicable base-model licence, and define ownership and permitted use of inputs, outputs and customer-specific adaptations.
API access does not expand the product’s current intended use. Each integration requires its own clinical validation, governance and regulatory assessment and must not be treated as clearance for autonomous diagnosis or treatment.
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.
Inspect further
Follow the evidence trail.
Use with oversight
Assess the system before it influences care.
Start with intended use, evidence, local risk and a clear stop rule.