Clinical Decision Support

Turkish-first decision support that starts where the exome stops — at the VUS itself.

This system applies the ACMG/AMP 2015 + ClinGen SVI + Tavtigian point framework deterministically, gathers nine evidence layers in parallel, and layers advisory mechanistic interpretation on top. The clinician enters the pre-diagnosis and patient findings in Turkish, receives the report in Turkish, and can question the result through a Turkish-language dialogue. It does not process raw sequencing data (FASTQ, BAM), call variants, or act as a filtering panel — it starts where the mature platforms that do that work leave off: with a variant of uncertain significance already in hand.

NM_000492.4:c.1521_1523delCTT
Turkish-first ACMG/AMP 2015 ClinGen SVI Tavtigian points gnomAD v4 ClinVar Turkish Variome
Product walkthrough (demo variant — not patient data).
How it works

Nine evidence layers, one deterministic decision

For every case, nine evidence layers are gathered in parallel → six interpretation modules evaluate that evidence in biological context → the deterministic ACMG engine produces the scores and the class → the findings are synthesized into a clinician-facing assessment → a source-cited report is generated in the Turkish medical-genetics standard (HTML / Word / PDF) → and you can question the result, in Turkish, through a citation-verified RAG clinical assistant that draws on eight sources.

 
01

Case input

Variant + Turkish pre-diagnosis + Turkish patient findings. Personal data (KVKK) is stripped on entry.

Rule
02

Nine evidence layers

From population to splice effect, collected in parallel from authoritative sources.

Rule
03

ACMG engine

Deterministic Tavtigian points & tier resolution. AI never touches the class.

LLM
04

Mechanism & phenotype

Six interpretation modules produce advisory reasoning; phenotype-match shows what it resolved Turkish findings to.

 
05

Turkish-standard report

Lab-letterhead HTML / Word / PDF.

LLM
06

Ask the assistant, in Turkish

Eight sources are retrieved for citations; an unverified citation never reaches the answer.

Deterministic (rule-based) LLM (advisory only)
AIstanbul VUS Pipeline data-input screen: variant entry, HGVS annotation and clinical phenotype fields
Data-input screen — variant & phenotype (demo data, no patient information).
AIstanbul VUS Pipeline results screen: ACMG decision, combined probability, evidence layers and source panels
Results screen — ACMG decision & evidence layers (demo variant).
Live capabilities

What the pipeline does today

Each card below reflects a real, live capability in the system. Two differentiators stand out: Turkish-first design and integrated Turkish population data.

Core · deterministic engine

ACMG / SVI classification engine

The class is set by a rule-based engine following the field's accepted Bayesian framework (Tavtigian) — not by AI.

  • Tavtigian Bayesian scoring & tier resolution
  • AI never touches classification; this is the system's most fundamental architectural decision
  • The calibrated pathogenicity probability is advisory, presented as a qualitative range
  • Expert-curation priority: the clinical authority can override the automated assessment; overrides are recorded with rationale
ACMG/AMP 2015 ClinGen SVI Tavtigian
Evidence architecture

Nine-layer evidence collection

Nine independent layers run in parallel; each answers a specific clinical question.

  • Population, clinical context, gene constraint, predictor ensemble, gene–disease relationship, therapeutic relevance, protein structure, inheritance resolution, splice effect
  • The population layer also asks "is this frequency reliable?" — quality filters, hard-genomic-region detection, an independent frequency check. Not standard in the literature.
  • Splice-effect integration is being completed; until then, the system explicitly flags these variants as "not evaluated for splice"
gnomAD v4 Turkish Variome ClinVar
Interpretation · 6 modules

Mechanism and phenotype interpretation

Advisory modules that place the collected evidence in biological context; they never change the class.

  • Evidence-gap analysis, mechanism assessment, structural impact, functional context, domain-phenotype relationship
  • Phenotype-match: resolves Turkish free-text findings to a phenotype ontology and shows the clinician what it resolved to — a deliberate safety design
advisory only human-in-the-loop
Case level

Case-level analysis

Real cases usually carry more than one variant.

  • Compound-heterozygote detection & phase inference
  • Gene isolation: a safety design that prevents the model from inventing a mechanistic link between unrelated genes
  • Flags conflicts between the inheritance model and observed zygosity
safety-by-design
Differentiator · Turkish-first

Pre-diagnosis → gene-set mapping

The clinician enters the pre-diagnosis in Turkish; the system resolves it to an international ontology through a controlled vocabulary of 10,572 Turkish disease names.

  • Genes are drawn from curated sources (ClinGen, GenCC)
  • Translation is not left to AI — a deterministic mapping is used
  • No variant is hidden: variants outside the pre-diagnosis are labelled, never suppressed
10,572 Turkish disease names ClinGen GenCC
RAG clinical assistant

Dialogue over the result

The clinician asks free-text questions; the answer is generated only from sources retrieved for that question — never from the model's own memory.

  • Retrieves from eight sources: the case's own analysis, PubMed/LitVar, OMIM, Orphanet, PharmGKB, ClinicalTrials.gov, Turkish Variome
  • Citation-verification gate: an unverifiable source claim cannot reach the answer
  • Streaming responses, session memory across the conversation
  • Cannot change the class or give direct clinical advice
RAG citation verification KVKK
Differentiator · Turkish population data

Turkish Variome integration

A local frequency database compiled at the aggregate level from 3,362 individuals, used alongside international data.

  • 5.2 GB / 46.4 million records, stored locally
  • The sample size is deliberately respected: the system does not claim rarity from local data alone
Turkish Variome 3,362 individuals
Reporting & operations

Report generation & case history

A report in the Turkish medical-genetics standard — lab-letterhead and customizable.

  • HTML / Word / PDF output
  • Case history and re-evaluation as databases update
  • KVKK consent flow and a live progress indicator during analysis
HTML/Word/PDF KVKK
Roadmap

Research & roadmap

The items below are not live yet; they are part of our research and productization roadmap. The system's current operation is complete without them.

Scientific / Academic In development

Splice

Splice-effect prediction integration

Canonical splice-site variants are already evaluated. A separate predictive model is being integrated for deep-intronic and exonic-regulatory variants; until then the system explicitly flags these as "not evaluated for splice."

Secondary findings

Pathogenicity-based filtering

A filter is in development to surface clinically meaningful secondary findings — by pathogenicity probability, not by pre-diagnosis. No variant is hidden today either.

Function-unknown genes

Protein-level evaluation of candidate genes

For variants in genes not yet linked to any disease, a component in development will reason from the protein level: type of change, regional importance, and stability impact.

Pathway analysis

Pathway & protein-complex interaction

A component in development will establish relationships between variants in different genes from curated pathway/complex databases — never assumed by AI. It does not compromise the current gene-isolation safety principle.

Institutional memory

Lab-specific evaluation memory

A component in development will let each lab accumulate its own anonymized evaluation history, improving within-lab consistency.

The most critical evidence gate

Clinical-utility study

50–100 real clinical cases, at least two independent reviewers, and a six-dimension rubric will compare the system-supported workflow against the current one. This is the project's most critical evidence gate.

Commercialization In planning

Architecture

Multi-user product architecture

The system currently runs on a single user. Making it multi-user — with role and permission separation, case handover, and shared review — is needed so that several specialists in the same lab can work at the same time.

Integration

Integration with laboratory information systems

Clinical labs manage variant data through their own information systems. Connecting the system to exchange data with those environments removes manual transfer and lets it fit inside the existing workflow.

Reporting

Report generation & lab-specific reporting

The evaluation output is planned to be produced in line with Turkey's medical-genetics reporting standard and in each lab's own letterhead format. The goal is to eliminate the time a specialist spends on report formatting.

Deployment

Production go-live

The system currently runs in production with its existing feature set.

Security

Multi-tenant data security

When multiple labs share the same infrastructure, each institution's data must be isolated from the others. Access control, data segregation, and per-institution audit trails are mandatory components of this architecture.

Regulation

Medical-device software determination

Whether clinical decision-support software falls under medical-device regulation depends on how far the system steers the clinical decision. Making this determination — and, if required, defining the conformity path — is a precondition for productization.

Licensing

Commercial-use licensing

The system draws on several third-party data sources and tools that are free for academic and research use (OMIM, FoldX, etc.). Offering the product commercially requires securing commercial-use licenses for these resources — one of the legal preconditions for productization.

Ethics

Ethics-committee process

The clinical-utility study to be run on real cases requires ethics-committee approval. The application will be submitted to the relevant board once the study design is finalized.

Commercial model

Pricing

How the product will be offered to labs — institutional subscription, per-case usage, or a combination — has not yet been decided. The model is planned to be structured around labs' existing cost structures and case volumes.

Pilot

Securing a pilot laboratory

The system has so far worked with a single clinical partner. Pilot use with labs of different sizes and workflows will both test the product's generalizability and build the case base for the clinical-utility study.

Deterministic core vs. advisory MIL

The engine classifies; the MIL only interprets.

The ACMG class is produced by a locked, rule-based engine. The mechanistic interpretation (MIL) layer reasons about mechanism alongside that class — it supplies the "why", never the verdict.

Deterministic core

Rule-based ACMG classification

ACMG/AMP criteria are scored and resolved into a class by a rule-based, deterministic engine following the field's accepted Bayesian framework (Tavtigian). The same input always yields the same class.

AI never touches this engine. Classification authority is entirely deterministic — this is the system's most fundamental architectural decision.

class = f(rules, evidence)
Advisory · MIL

Mechanistic interpretation (6 modules)

The interpretation modules summarize literature and mechanism for the clinician; phenotype-match resolves Turkish findings to an ontology and shows what it resolved to.

Its output is strictly advisory: even the calibrated pathogenicity probability is presented as a qualitative range and cannot set, shift, reclassify or override the class. This is not a prompt instruction — it is how the system is built to run.

MIL interprets · rules classify
Validation status

What's proven, what isn't

The distinction between proven and unproven is one of the project's core working principles.

Proven

  • Direction safety: automated regression testing runs on a 390-variant reference set; zero known-pathogenic variants have been mis-called benign, and this check is repeated on every code change.
  • End-to-end functionality: the system has run start to finish on a real clinical case at Yeditepe Medical Genetics, from Turkish-language intake to report output.
  • The safety architecture works in practice: structural safeguards have caught real errors more than once during development and led to fixes.
  • Scientific discipline: a protein-stability approach was added, measured, found not to deliver the expected contribution, and disabled. The negative result was recorded.

Not yet proven

  • Clinical utility: whether the system improves clinician decisions relative to the current workflow has not yet been measured — that is the subject of the planned utility study, the project's most critical evidence gate.
  • Scale: work to date has involved a single clinical partner and a limited number of real cases.
  • Multi-centre use: adaptation to different labs' workflows has not yet been tested.
Transparency & data integrity

Built for trust: transparent evidence, sound data

Evidence sources & data integrity

  • Live-queried: gnomAD, ClinVar, NCBI literature services, UniProt/AlphaFold, CIViC, Orphadata, HGNC, disease-ontology services.
  • Stored locally: Turkish Variome (5.2 GB, 46.4 million records, 3,362 individuals, aggregate level), ClinGen gene–disease validity tables, GenCC records, Turkish disease nomenclature, genome-build liftover chains.
  • Local storage is a deliberate choice: it reduces dependence on external services during case analysis, makes results reproducible, and lets the exact data version used be recorded.

Privacy, audit & KVKK

  • Personal data is stripped automatically at the point of entry (national ID, phone, email patterns); the interface has an explicit consent flow.
  • The pilot archive stores only age-band-level data, no identifying information.
  • Audit trail: every analysis records which engine version, which data sources, and on what date it was produced; expired records are cleaned up automatically.
  • Controlled kill-switch: every major feature can be disabled independently; a problem component can be isolated without stopping the whole system.

Contact us for demo access

The clinical application is currently in a limited pilot phase. To see the pipeline in action or request a demo, get in touch — we'll get back to you shortly.

or directly: [email protected]

Note. It's a clinical decision-support system, not a diagnostic tool.