Diagnify clinically fine-tunes a selected licensed open-weight model for defined medical tasks, then combines it with curated, source-linked evidence in a multi-agent clinical decision-support system. The clinician application is the first product built on this stack—and every output requires qualified human review.
Current research artefact Diagnify-14B v0.2-CoT Medical reasoning research model Clinically fine-tuned by Diagnify from a selected open-weight base Medical intelligence stack FINE-TUNE → RETRIEVE → GROUND → CHECK Designed for clinician review
The clinician-facing application powered by a Diagnify-clinically fine-tuned model and evidence grounding.
General-purpose models are optimised for breadth. Medicine requires domain adaptation, task-specific models, source-linked evidence and explicit controls. Diagnify develops the model variants, training pipelines, evidence infrastructure and clinical reasoning software as one system.
Diagnify selects and clinically fine-tunes a licensed open-weight base for defined medical tasks rather than relying solely on an undifferentiated general-purpose response. Diagnify-14B v0.2-CoT is the current access-gated research artefact.
Diagnify reports using clinically curated material and task-specific datasets. Detailed provenance, permissions, de-identification and coverage documentation remain pending in the research register.
A separate evidence layer retrieves source-linked material from a curated medical knowledge base for the case. The output therefore does not depend on model memory alone.
Red-flag, contraindication, citation and consistency checks are applied within the reasoning workflow. Every result remains decision support and requires review by a qualified clinician.
Clinical evidence does not arrive as text alone. Different signals require different models, so Diagnify is building modality-specific intelligence rather than asking one general-purpose LLM to perform every medical task.
A medical reasoning model fine-tuned for defined clinical tasks and connected to the evidence and clinician-review layers.
A continuing specialist-model programme that reconstructs 12-lead signals from images and applies structured classification as a clinician-reviewed second read.
Computer-vision research for structured recognition of dermatological morphology and skin-image findings. Dataset development and evaluation are in progress.
Models for defined visual examination tasks, initially distinguishing specified normal and abnormal findings and returning structured observations for review.
Evidence-based medicine integrates the best available research evidence with clinical expertise and each patient's values and circumstances. Diagnify is designed to support that process by retrieving and structuring evidence—not to replace professional judgement. This follows the foundational definition of evidence-based medicine.
The intended workflow grounds clinical findings, red flags and contraindications in a curated knowledge base with source provenance.
Findings update a ranked differential and work-up through explicit stages, helping clinicians examine how evidence changes the assessment.
Diagnify provides decision support for qualified health professionals. The clinician remains responsible for context, communication and every clinical decision.
DIAGNIFY isn't a search box you check after the fact — it works the case up with you, in real time. It reads the presentation, walks the reasoning section by section, and re-computes as each finding lands. Three ways to use it, one engine underneath.
Live decision support that works the case up with you — section by section, from red flags through to the plan — and re-ranks as new findings come in.
Have a voice conversation with the engine: ask it to reason out loud, challenge the differential, or talk through management — hands-free, mid-consult.
It listens and scribes the consult, then turns that transcript into structured decision support — auto-filling findings, surfacing red flags and driving the differential and plan. The scribe data itself powers the CDS.
Diagnify conducts retrospective testing, but a complete versioned comparative protocol and report are not public here. Until they are, the homepage does not make a universal performance or superiority claim.
The system combines a domain-specific model, multi-agent reasoning and retrieval from a clinician-curated knowledge base on one structured path. Its purpose is to make the work-up more explicit and reviewable for the clinician.
Diagnify reports using this clinically curated historical corpus to fine-tune selected open-weight model variants. Model training is a distinct layer from the evidence retrieved when a case is processed.
The evidence layer stores structured likelihood ratios, red flags and contraindications with source provenance, enabling relevant material to be retrieved independently of the model's learned parameters.
The knowledge base can be reviewed and updated without retraining the underlying model, reducing reliance on a fixed model-training cut-off while preserving an auditable separation between the two layers.
*Company-supplied corpus description; this does not mean 50 million unique patients. Counting, provenance, permissions, de-identification, deduplication and population coverage remain documented as pending in the research register.
A single reasoning path for a clinical presentation. An orchestrator dispatches specialist agents and routes material claims through retrieval, citation and consistency checks before presentation. The four stages:
Age-band priors, context flags and archetype detection frame the case; life-threatening possibilities are raised first.
Posteriors update with each finding using likelihood ratios drawn from the database rather than model memory.
Tests and imaging are selected for discriminating power, limiting unnecessary investigations.
Retrieved claims, doses, differential items and recommendations are subjected to automated evidence and consistency checks before presentation for clinician review.
The reasoning workflow can retrieve from a purpose-built, source-linked base of signs, symptoms, likelihood ratios, red flags and contraindications maintained as a separate, versioned evidence layer.
Diagnify uses internal retrospective testing during development. A citable versioned report must identify the exact model and base, test set, prompts, comparators, endpoints, grading process, uncertainty and limitations before any comparative result is presented as independently assessable.
Internal testing is not proof of patient benefit or autonomous clinical safety. Independent replication, prospective clinical validation, subgroup analysis and the applicable regulatory review are required before broader clinical claims can be made.
This research-stage pipeline reconstructs a 12-lead signal from a photograph or scan and classifies it with specialist components. Internal testing is continuing; no public evaluation report, prospective validation or regulatory review is currently available.
Four stages convert a photograph or scan of a printout into a structured cardiology read. Each stage performs one function; classification is performed by a trained model rather than a language model.
A specialist digitisation component is being developed to reconstruct a 12-lead waveform from a photograph or scan of a printout.
A specialist classification component is being trained for defined rhythm and morphology tasks using research datasets and held-out development tests.
A vision model produces a structured, human-readable report — rate, rhythm, axis, intervals, morphology — constrained to the classifier's findings, so it describes rather than introduces competing diagnoses.
The research workflow is designed to cross-reference structured findings against a separately maintained ECG evidence layer for clinician review.
A versioned protocol, frozen test set, uncertainty analysis and external replication are required before performance is presented as independently assessable. The system remains a research-stage second read, not a replacement for a clinician's interpretation.
Pipeline constraints are designed to reduce specific high-consequence errors and present uncertainty for clinician review; they do not guarantee that an error will be prevented.
The research design routes these patterns to explicit rule-based review and clinician interpretation.
Candidate criteria and discordant ST changes are presented for verification, not asserted as an autonomous diagnosis.
Interval and measurement estimates are labelled as estimates; any value failing a physiologic sanity check is suppressed rather than shown wrong.
The research workflow uses reconstructed signals and simulated image variation to test performance under non-ideal capture conditions. Dataset versions, inclusion criteria, split integrity, task definitions and release gates must be recorded in a public evaluation report before quantitative claims are promoted.
Most electrocardiograms exist only as paper or images and are not machine-readable. Reconstructing the signal from an image makes these tracings accessible for interpretation and research.
Large volumes of ECGs exist only on paper in institutional records and the published literature. Reconstructing them to signal makes historical cohorts machine-readable — enabling longitudinal studies, rare-arrhythmia datasets, and retrospective analyses not previously feasible.
The pipeline is being developed to accept a photograph or scan when a digital signal is unavailable. Input quality limits and clinical review requirements remain part of the evaluation.
The pipeline is being designed for scalable research deployment. Cost, latency and infrastructure claims require a defined production configuration and dated technical report.
The planned integration passes structured ECG findings into the reasoning engine as reviewable inputs. End-to-end integration evaluation remains pending; a photographed printout must not be treated as an autonomous diagnosis or a substitute for formal ECG interpretation.
Dr Diagnify is in testing as clinical decision support for qualified health professionals. It applies the same model, evidence and multi-agent reasoning architecture described above.
Clinician-entered or otherwise authorised inputs are structured into findings and red flags before discriminating questions are assembled for review.
Defined observations can be recorded for clinician interpretation. The system does not provide autonomous patient guidance, diagnosis or triage.
Diagnify is training computer-vision models for defined normal-versus-abnormal examination findings. This capability remains a research objective and is not currently available for clinical use.
The consultation runs on the reasoning architecture described above — full differential, work-up logic, and a structured assessment — not a reduced variant.
The system is intended to support qualified clinicians under human oversight—not to provide autonomous diagnosis, triage, treatment or direct-to-patient advice.
Only specialties currently represented in Diagnify testing are listed here. Inclusion does not imply autonomous use, regulatory clearance or validated performance across every presentation.
Diagnify is clinician decision support in testing. A qualified health professional must review and verify every output before it informs care.
The authorised compute region and applicable processing boundaries must be confirmed in the relevant deployment agreement.
Residency, retention, subprocessors and cross-border handling are deployment-specific and must be documented for each implementation.
Encryption and key-management controls must be specified in the applicable security terms and independently verified where required.
Decision support only, currently in testing. DIAGNIFY and Dr Diagnify are designed to support and, in time, extend the reach of qualified health professionals — not to replace a real consultation without one. Every output must be reviewed and verified by a registered practitioner before any clinical decision. Diagnify makes no claim of regulatory approval, clearance or authorisation for autonomous use. Intended purpose, obligations and regulatory pathway depend on jurisdiction and deployment. In an emergency, contact local emergency services.