A three-layer model architecture for Turkish clinical language and 14 specialties
A general-purpose language model can speak Turkish. Reading a discharge summary, a consultation note or a SUT clause the way a physician does is a different task. MINA’s architecture builds that difference in three layers: base model, adaptation and orchestration.
Discussions about AI in healthcare often focus on how large a model is. In clinical practice, what matters more is which language, which terminology and which rules the model knows. A note written by a physician in Türkiye, the abbreviations a hospital uses, the SUT clause a payment decision rests on: these take up limited space in the texts general-purpose models are trained on. That is why MINA was built on Turkish clinical language.
The particular difficulties of Turkish clinical language
Turkish is an agglutinative language; a single word can carry negation, tense and person through its root and suffixes. Clinical notes add Latin and English terms, specialty-specific abbreviations and institution-specific writing habits. The same finding appears as an abbreviation on one ward and spelled out on another. Missing that a statement is negated means treating an absent finding as present, or a present one as absent.
A consultation note, for instance, can contain a Latin term, an English abbreviation and a Turkish negation suffix in the same sentence. A physician resolves this without noticing; for a model, it is the detail that determines what the sentence means.
Then there is the language of local systems: HBYS (hospital information system) records, Medula processes, SUT reimbursement rules and ICD-10 coding practice. A model that does not know this context can summarize a text fluently and still miss the detail that determines the outcome.
The base model was adapted to Turkish and the clinical language of 14 specialties
The first layer of MINA is an open-weight base model. This model was adapted to Turkish and the clinical language of 14 specialties through continued pre-training (CPT). Continued pre-training means continuing to train a model on the texts of a new language and domain while preserving its general language ability. The aim is not to teach the model a specific task but to have it read clinical Turkish as its native language.
This layer is the foundation for everything built on top of it. A system that has learned the terminology, abbreviations and clinical writing style in its base model does not have to relearn them in the layers above.
LoRA adapters add specialty, institution and task expertise
The second layer is specialization. The base model’s weights are kept fixed, and small, separately trained layers called LoRA adapters are added on top. Each adapter carries a specific expertise. Specialty adapters learn the clinical logic of a field, institution adapters an institution’s own writing and process habits, and task adapters specific jobs such as ICD-10 coding, SUT compliance or discharge summary analysis.
This structure has a practical benefit. Adding a new task or a new institution does not require retraining the whole model; the relevant adapter is added. When a request comes in, the adapter the job requires is brought in. The base model stays shared, and expertise is added on top layer by layer.
This separation also makes review easier. When unexpected behavior appears in a task, the issue can be examined at the level of the relevant adapter rather than across the whole base model.
Agentic orchestration works over a clinical knowledge graph
The third layer is orchestration. MINA accesses knowledge through an agentic architecture that works over a clinical knowledge graph (GraphRAG). Clinical concepts, the relationships between them and the sources that support them are held in a graph structure. Instead of producing an answer in a single pass, the model runs the steps a question requires in sequence: it searches the graph for relevant information, compares the sources it finds and grounds its answer in those sources.
The architecture covers 14 specialties and 30M+ sources. The sources include PubMed, The Lancet, JAMA, BMJ, UK Biobank, MIMIC-IV and ClinicalTrials. Because each answer is grounded in these sources, the document and the inference are shown separately every time: what comes from a source and what is the model’s interpretation are clearly distinguished.
Grounding in sources is a precondition for trust in clinical AI. For a physician to assess a suggestion, they need to see which guideline, study or rule it rests on. An answer that does not show its source cannot support a clinical decision, however fluent it is. Keeping the three layers separate is a deliberate choice for the same reason: language knowledge sits in the base model, expertise in the adapters and current knowledge in the knowledge graph. A new publication does not require retraining the model; adding it to the knowledge graph is enough.
Oversight by the Physician Ethics and Advisory Board
Technical architecture alone is not enough. MINA’s clinical accuracy and ethical boundaries are regularly reviewed by the Physician Ethics and Advisory Board, made up of physicians from 15 specialties. The board looks with a clinical eye at what the model says in which situation, and at what it should not say. The review is not a one-off approval; it is repeated on a regular basis.
This oversight works together with the system’s core principle: MINA does not make decisions; it supports them. People make the decision; AI shows its rationale and source, and every output can be audited. Data stays inside the institution, personal data is protected with KVKK-compliant masking, and the institution remains the data controller.
In practice, the three layers mean that the same core can be adapted to different work in hospital and insurance processes. ICD-10 suggestions and discharge summary analysis in TIS, and pre-authorization and reimbursement checks in SIT-I, run on the same base model and knowledge graph. To see how MINA behaves in your own workflow, you can submit a POC request.