MINA, our AI model
adapted to Turkish clinical language

Clinical practice
differs from country to country

The patients a physician sees in Türkiye, the guidelines they follow, the discharge summaries they write and the SGK and SUT rules they work under are specific to this country. We developed MINA for these conditions.

We know that translating a general-purpose foreign model into Turkish is not enough. That is why we built MINA on an open-weight base model, in the three layers described below.

How MINA was built

A general-purpose language model can write Turkish. Reading a discharge summary in the language of Turkish clinical practice, suggesting the right ICD-10 code, checking whether an order complies with SUT (the SGK Healthcare Implementation Communiqué) and tying every answer to its source takes a different kind of preparation. We have spent five years doing that work to build MINA.

Below, we explain in seven stages how an open-weight foundation model became a decision-support model that works in Turkish clinical practice: preparing the data, splitting Turkish clinical text into tokens, continued pre-training, LoRA expertise adapters, knowledge retrieval with GraphRAG, agentic orchestration and clinical validation. MINA's three layers, the foundation model, adaptation and orchestration, are built across these stages.

The sources MINA draws on include PubMed, The Lancet, JAMA, BMJ, UK Biobank, MIMIC-IV and ClinicalTrials.

1. Data: collecting and preparing the sources

MINA learned from sources written in the language of Turkish clinical practice; institutions' patient data was not used to train MINA's shared model.

What a model can do, and how well, depends largely on the data it learns from. To teach MINA Turkish clinical language, we brought together Turkish medical terminology, clinical guidelines and anonymized clinical records. MINA's knowledge base draws on 30M+ sources across 14 specialties, led by international medical literature, clinical trial registries, open-access health datasets, evidence-based clinical guidelines, SUT and SGK regulations and international medical coding standards.

Institutions' patient data is not added to these sources. Institution-specific LoRA adapters are trained inside the institution's own environment on its own data and stay there; institutional data is never used to train MINA's shared model. We list the sources in detail, along with the terms under which we use them, further down this page under the data sources behind MINA's knowledge base.

When MINA is deployed at an institution, the data it reads is prepared through a layered pipeline as well. In a three-layer structure known as the medallion architecture, which runs inside the institution's own environment, raw data is first ingested into the Bronze layer. In the Silver layer it is cleaned and brought into a common format (normalized), and personal data is masked in line with the requirements of KVKK, Türkiye's personal data protection law. In the Gold layer, structured data is produced for clinical analytics, billing compliance checks and the patient digital twin. Data never leaves the institution, and the institution remains the data controller. For a hospital, this means MINA can work with its data without that data ever leaving its own environment.

2. Tokenization: splitting Turkish clinical text into tokens

MINA reads Turkish clinical text without getting lost among suffixes and Latin terms.

Language models do not read text letter by letter or word by word; they work with pieces called tokens. A token can be a whole word, the root of a word or a single suffix. A component called the tokenizer splits each sentence into these pieces and gives each one a number, its token ID. From then on, the model processes the text as a sequence of these numbers.

Turkish is an agglutinative language: a single word can carry several suffixes after its root. The word “şüphesiyle” (on suspicion of) has one root and two suffixes. Clinical terms, meanwhile, are mostly of Latin or Greek origin and appear rarely in general text. As a result, a clinical term can be split into several tokens; in the example shown, “enfarktüsü” (infarction) is split into “enfarkt” and “üsü”.

The model learns what these pieces mean together in the next stage, when it is trained on Turkish clinical text. For physicians, this means the sentence they write in a discharge summary is read for its clinical meaning, without getting lost among the suffixes.

3. Continued pre-training (CPT): teaching the model Turkish clinical language

MINA learned Turkish clinical language like a native speaker.

We did not train MINA from scratch. We started with an open-weight foundation model that had already learned general language. An open-weight model is one whose weights, the numerical parameters that hold what it has learned, are openly available, so its training can be picked up where it left off. We put this model through continued pre-training (CPT) on Turkish medical terminology, clinical guidelines and anonymized clinical records.

Continued pre-training is a repeating loop. The model reads the beginning of a sentence and predicts the next token; this is called the forward pass. In the example shown, the model gives the highest probability to “istendi” (was ordered) after “troponin”. How far the prediction is from the correct token in the text is measured as a number called the loss, calculated with a method called cross-entropy. The error is then traced backward through the model's layers (backpropagation), and each parameter's contribution to the error is calculated (the gradient). In the last step, the weights are updated by a small step in the direction that reduces the error.

As this loop is repeated again and again over Turkish clinical text, the model internalizes the terms, patterns and context of Turkish clinical language and comes to use it as if it were its native language. Training ran on high-performance GPU infrastructure. For physicians and hospitals, the result is that MINA reads a discharge summary, a test order or a report written in Turkish together with its clinical context, without needing translation.

4. LoRA adapters: specialty and task expertise

MINA gained separate expertise in four tasks and 14 clinical specialties.

Continued pre-training teaches the model the language; LoRA adapters teach it to do specific jobs like a specialist. LoRA (Low-Rank Adaptation) is a method that, instead of retraining an entire large model, attaches a small, removable layer of extra parameters to it. After CPT, the foundation model's weights are frozen, meaning they no longer change. Separate LoRA adapters are then trained, and they give the model specialty, institution and task expertise. Institution-specific adapters are trained inside the institution's own environment, as described in the first stage, and stay there.

MINA v3.7 has five main LoRA adapters: ICD-10 coding, discharge summary analysis, fraud and policy review, SUT compliance, and a specialty-based clinical decision adapter. The clinical decision adapter covers 14 specialties and subspecialties: General Surgery, Obstetrics and Gynecology, Cardiology, Pediatrics, Neurology, Medical Oncology, Orthopedics and Traumatology, Endocrinology, Gastroenterology, Nephrology, Hematology, Rheumatology, Pulmonology and Infectious Diseases. These adapters are joined by three cross-cutting capability layers that serve every task rather than a single one: Turkish understanding, safety and hallucination control, and operational optimization.

At run time, the adapter that fits the context is activated: when an ICD-10 code is suggested for a discharge summary, coding expertise comes to the fore; when a pre-authorization request is reviewed, SUT compliance expertise does, and when a cardiology case is assessed, the clinical decision adapter's cardiology expertise does. This way a single model works across multiple areas of expertise and compute costs go down. Because expertise is written to separate adapters rather than to the foundation model's weights, a new specialty, institution or task can be addressed without touching the foundation model.

5. GraphRAG: linking answers to sources

Every MINA answer can be traced back to the source it relies on.

What a language model learns in training is fixed the moment training ends, while in medicine guidelines are updated and new studies are published. That is why MINA does not rely only on what it learned in training when it answers; it finds the relevant source in its knowledge base and grounds its answer in it. This approach is called retrieval-augmented generation (RAG), and in MINA we built it in its graph-based form, GraphRAG (graph-based retrieval-augmented generation).

Biomedical literature is indexed in a graph database. The knowledge graph holds medical concepts and the relationships between them as connected nodes, so one concept leads to related concepts and sources. Medical textbooks are indexed in a vector search store. Vector search matches text by meaning rather than by exact words, so it also finds passages that say the same thing in different words. An ML (machine learning) routing layer directs each question between the two sources according to its clinical context.

For physicians, this means every MINA answer can be traced back to the source it relies on: a recommendation comes with the article, guideline or SUT provision behind it, and answers are grounded in current sources. We track developments in the medical literature and update the knowledge base, and a new guideline or study added to the knowledge base can be used as a source in answers.

6. Agentic orchestration: carrying out multi-step clinical tasks

MINA carries out multi-step work across the patient's digital twin and the institution's systems, and leaves the decision to the physician.

Clinical work rarely comes down to a single question. Assessing a pre-authorization request means looking at the patient's history, reading the discharge summary, finding the relevant SUT provision and bringing all of this together. MINA carries out multi-step tasks like these through agents. An agent is a software component that selects which tool to use and when, and runs the steps of a task in order.

At run time, agents move through the patient's digital twin and across tools. The digital twin is a single, live profile that brings together all of a patient's clinical encounters over time; HBYS (hospital information system) and Medula data are combined there. Agents read this profile, consult the knowledge base and run the rule engine that applies SUT rules.

Rule checks run in the rule engine; the AI explains the result and its rationale. The final decision always rests with the user: the physician, the insurance specialist or the hospital operator. Every answer shows separately which information comes from the patient's documents and which is MINA's inference, and every output can be audited afterwards.

7. Clinical validation and release

MINA was evaluated separately in 14 specialties; model updates go through the physician board's approval.

We measure MINA's releases on fixed test sets and compare them with one another. The test sets are made up of synthetic or anonymized cases and contain no real patient data; we evaluated MINA v3.7 separately in each of the 14 specialties. You can find task-level evaluation results for MINA v3.7 on the MINA v3.7 page.

Numerical measurement is not enough on its own; physicians review clinical accuracy as well. The Physician Ethics and Advisory Board, made up of physicians from 15 specialties, regularly reviews the model's clinical accuracy and ethical boundaries, assesses case scenarios and model outputs, and approves model updates.

An approved release is deployed on the institution's own servers or in an isolated cloud environment. The HBYS stays as it is, and MINA runs on top of the existing system. Behind this work is our 17-person technical, operations and partner team of AI researchers, data engineers, clinical domain experts and quality and regulatory specialists.

Why we chose this approach

There is more than one way to build an AI model for Turkish clinical practice. We weighed each of them; below, we explain why we settled on today's architecture.

The data sources behind
MINA's knowledge base

MINA's knowledge base is built from international medical literature, clinical trial registries, open-access health datasets, insurance and billing codes, and evidence-based clinical guidelines. MINA produces no output without a source, and every answer can be traced back to these sources.

We use all sources in line with copyright and usage rights. We access sources that require a license through institutional or academic agreements.

The shared core
of four platforms

MINA is the shared core of Opinion AI's four platforms: TIS serves physicians, hospitals and laboratories, SIT-I serves insurers, SIT-H supports hospitals' compliance processes and SIT-G serves public oversight. All four use the same clinical knowledge base; the role MINA plays and the permissions it has depend on the platform.

On these platforms, MINA works on tasks such as the patient digital twin, discharge summary analysis and ICD-10 coding, SGK pre-authorization and SUT compliance, missing documents and denial risk, interpreting lab results and radiology reports, fraud risk screening and invoice compliance. Each capability uses the relevant LoRA adapter, ties its result to a source through GraphRAG and runs inside the user's existing workflow. We describe the capabilities in detail on our pages for physicians, hospitals, insurers and laboratories.

Whatever the platform, the decision always rests with the user; MINA's suggestion comes with its rationale and the source it relies on. We explain this principle in detail on the Ethics and Compliance page.

Deployment follows KVKK and GDPR requirements and takes place on the institution's own servers or in an isolated cloud environment; you can find our compliance approach and management system certifications on the Ethics and Compliance and Information Security Policy pages.