The patient digital twin in clinical decision-making

What a digital twin means for a patient

In engineering, a digital twin is the virtual counterpart of a physical system, kept current with data from that system. In healthcare it is generally used in two ways. In some research it describes a simulation model that computes how an organ or a physiological process behaves. This guide covers the second meaning: a data twin, in which a patient's records at an institution come together in one live, structured profile.

The need arises because a patient's information does not sit in one place. Lab results, imaging reports, prescriptions and consultations live in different modules of the hospital information system, known in Türkiye as HBYS. Pre-authorization and billing records are held in Medula, SGK's pre-authorization and billing system. Discharge summaries and reports are mostly free text. In other health systems, the electronic health record and the payer's claims system play similar roles. On every file, the physician or the pre-authorization team assembles these pieces again. When one is missed, the decision rests on an incomplete picture; a test that was already done may be ordered again, or a claim may come back because of a missing document. Across the health system, physicians spend 35% of their working time on documentation rather than on patients, and assembling scattered records is part of that burden.

What the patient twin and the physician twin bring together

The patient twin merges HBYS and Medula data into one live profile. The profile holds the patient's chronic conditions, allergies, clinical notes, vital signs, lab results and past visits. Discharge summaries and reports are read, and the diagnoses, procedures, medications and findings in them become fields that can be searched, compared and checked.

What sets the twin apart from a static patient summary is that it is live. When a new test, prescription or discharge summary arrives, the profile updates. A well-built twin also records which document each field came from and shows which fields are missing, so the physician can see how much data a decision rests on.

The physician twin, by contrast, is built around the physician who will read the recommendation, not around the patient. It learns the physician's test-ordering patterns, coding preferences and treatment patterns; it is created with the physician's consent and compared against anonymized peers. Its purpose is not to rank physicians but to present each recommendation, with its rationale, in terms close to the physician's own practice.

Using the twin in clinical decisions

When the physician opens a patient's record, they do not search HBYS history, Medula records and earlier discharge summaries one by one; they see the twin's clinical summary. Previous diagnoses, procedures, allergies and risk flags are on the same page. Risk flags bring forward situations that need attention, such as a worsening trend in lab values or a repeat order for a test that has already been done.

The physician can also put a question to the system the way they would ask a colleague, for example “What should I not miss in this patient?” The answer draws on the records in the twin and on clinical sources. It shows which information comes from a document and which is the system's own inference. When tests or treatment are planned, the recommendation also arrives with its rationale and source.

When the discharge summary is written, the text is split into structured fields. ICD-10 diagnosis codes and procedures are checked against the rules of the SUT, the Healthcare Implementation Communiqué published by SGK, and missing or non-compliant fields are flagged before the invoice is issued. Where pre-authorization is needed, the same clinical summary carries over to the pre-authorization screen, and the request starts from a ready synthesis.

The role of AI in this flow is well defined. It reads free text and splits it into fields, summarizes scattered records and answers questions based on records and sources. It cannot know what is not in the record; if data is missing, the output is incomplete too. A good twin therefore shows missing fields, separates inference from documents and leaves the decision to the physician. The physician accepts, changes or rejects the recommendation, and every output can be audited later.

Steps to set up a patient digital twin in a hospital

These steps apply whatever technology you use to build the twin.

1. Choose the first task the twin will serve. Starting with a single task, such as a clinical summary in the outpatient clinic, coding checks on discharge summaries or a pre-authorization file, keeps the scope manageable.
2. Take an inventory of data sources. List the HBYS modules, Medula pre-authorization and billing records, and lab and imaging reports, and note which fields are structured and which are free text.
3. Write down the patient-matching rule. Decide at the outset which shared key links a patient's records across systems and which record prevails when two of them conflict.
4. Define the fields to extract from free text. For fields such as diagnosis, procedure, medication, finding, allergy and chronic condition, require that every value keeps track of the document and date it came from.
5. Make data quality visible. Use an indicator that flags missing or conflicting fields, and define how the profile updates; when a new record arrives, the physician should not be working from an old copy.
6. Set access and privacy rules. Make sure the data stays in the institution's environment, the model works on masked data and access to profiles is logged. Under KVKK, Türkiye's personal data protection law, health data is special-category personal data, and the GDPR in the EU likewise treats health data as a special category.
7. Talk to physicians before introducing the physician twin. Explain that the behavioral profile is created with their consent, that peer comparison stays anonymous and that the aim is not ranking.
8. Start with a limited POC. Try the chosen task in one unit within the real workflow, collect feedback from physicians and administrative staff, and then widen the scope.

What Opinion AI does in this process

Opinion AI builds the patient digital twin within TIS, its clinical decision platform for hospitals. TIS does not replace the existing HBYS; it is added on top of it as an intelligent layer. HBYS and Medula data merge into one live patient profile; discharge summaries and reports become structured fields; and the clinical summary, risk flags and SUT checks appear in the same view. The physician twin is created on the same platform with the physician's consent. The For Hospitals and For Doctors pages have the details, and this article walks through how the two twins work together in a single visit.

The model that reads the twin is MINA. MINA was developed by adapting an open-weight foundation model to Turkish and to the clinical language of 14 specialties through continued pre-training (CPT). Specialty, institution and task expertise comes from LoRA adapters, and knowledge retrieval runs on agentic orchestration over a clinical knowledge graph (GraphRAG). Every answer shows its rationale and source, and when a patient is selected, the output is written to that patient's twin record. The MINA page describes the architecture in more detail.

The data stays inside the institution. The twin is built on the institution's own servers or in an isolated cloud environment; the institution is the data controller, and the data the model sees passes through KVKK-compliant masking. Opinion AI does not collect personal data. The same applies to the POC work that has started with hospital groups in Northern Europe, where the data stays in each institution's own environment. A person always makes the decision, and the Physician Ethics and Advisory Board, with physicians from 15 specialties, regularly reviews the model's clinical accuracy and ethical boundaries. On the insurance side, the same approach gives pre-authorization review on the SIT-I platform a complete view of patient data; there too, the final decision rests with the insurer's medical experts.

Frequently asked questions

What is a patient digital twin?

A patient digital twin is a virtual representation that brings a patient's scattered records at an institution into one current, structured profile. In a Turkish hospital it is fed by HBYS and Medula records, and discharge summaries and reports become searchable fields. When a new record arrives, the profile updates, so the physician works with the patient's current state.

How is a patient digital twin different from an electronic health record?

An electronic health record, or the HBYS in a Turkish hospital, stores data; the digital twin combines that data with records from other sources such as Medula into one profile and interprets it. It turns free text into structured fields and produces a clinical summary and risk flags. That is why the twin does not replace the HBYS but runs on top of it.

Does a digital twin make decisions instead of the physician?

No. The digital twin puts the full picture of the patient, a reasoned recommendation and its source in front of the physician. The physician accepts, changes or rejects the recommendation; the decision is always the physician's, and every output can be audited later.

What is a physician twin, and is it used to evaluate physicians?

A physician twin is the layer that learns a physician's test-ordering patterns, coding preferences and treatment patterns. It is created with the physician's consent and compared against anonymized peers. Its purpose is not to rank physicians but to present recommendations, with their rationale, in a way that fits the physician's own practice.

Does patient data leave the hospital when a digital twin is built?

It does not have to. The twin can be built on the institution's own servers or in an isolated cloud environment, and the model works on masked data. Under KVKK in Türkiye and the GDPR in the EU, health data is a special category of personal data, and the hospital is the data controller for its patients' records, so keeping the data in-house matters. In Opinion AI's setup the data stays inside the institution, and Opinion AI does not collect personal data.

Where should a hospital start with a patient digital twin?

The practical route is to start with a single task, such as a clinical summary in the outpatient clinic, coding checks on discharge summaries or a pre-authorization file. First take an inventory of data sources and settle the patient-matching rule, then test the task in the real workflow with a limited POC. Once the result has been assessed, the scope can be widened module by module.

To assess together which task a patient digital twin could start with in your own HBYS or electronic health record environment, use the POC Request form. For the principles of keeping data in-house, see Using AI without patient data leaving the institution; for discharge summary and billing checks, see Preventing SUT non-compliance in SGK hospital billing.