Patient and physician data twins bring scattered records into a single view

The information is recorded but scattered across screens

When a hospital physician or an insurer's medical reviewer opens a new file, most of what they need is already recorded somewhere. The problem is that it is scattered. Lab results sit on one screen, earlier visits on another, and pre-authorization and billing records in Medula, the Social Security Institution's (SGK) provision and billing system, in yet another place. Discharge summaries and reports are mostly free text. Assembling them costs time and attention on every file. When a piece is missed, the decision rests on an incomplete picture; a repeated test or a later billing rejection can be the result.

The data twin approach moves that assembly work from the person to the system. There are two twins: the patient twin, which shows the patient as a whole, and the physician twin, which understands the physician's clinical practice. The first makes a recommendation fit the patient; the second presents it in a way that suits the physician reading it.

The patient twin builds one live profile

The patient twin's first job is to bring HBYS and Medula data together in one live profile. When a new test, prescription or visit arrives, the profile updates, so the physician is looking at the patient's current state rather than an old summary.

Discharge summaries and reports are also converted into structured fields within this profile. Diagnoses, procedures, medications and findings written in free text become fields that can be searched, compared and checked. The clinical summary, risk flags and SUT checks appear on the same screen (SUT is the SGK Healthcare Implementation Communiqué that sets reimbursement rules), so the physician no longer has to search separately for history, warning points and rule compliance.

What matters here is that the profile is live. A static patient summary is prepared once and soon goes out of date. The patient twin updates as the institution's records change. Clinical decisions and administrative processes such as pre-authorization and billing therefore rely on the same current view, and what the physician sees does not drift apart from what the billing team sees.

The physician twin fits recommendations to how the physician works

The same recommendation does not carry the same value for two different physicians. Which tests a physician orders and in what order, which codes they prefer and which treatment patterns they follow shape the support that will help them.

The physician twin is the layer that models this practice, tracking the physician's test-ordering patterns, coding preferences and treatment patterns. From this, a consent-based behavioral vector is built, and anonymous peer comparison allows the physician's practice to be read against the general pattern of colleagues whose identities are not shown. Personalized decision support and reasoned recommendations rest on this foundation.

The aim is not to rank physicians but to give each one a recommendation that fits the way they work and states its reasoning clearly. A test that is not part of a physician's routine but may be needed given the patient's profile can be brought forward with its rationale. Conversely, re-ordering a result already in the patient's history also becomes visible. The recommendation then reads in terms close to the physician's own clinical reasoning.

The two twins work together in one visit

A typical outpatient visit shows how the two twins work together:

1. When the patient arrives, the physician sees the patient twin's clinical summary instead of opening HBYS history, Medula records and earlier discharge summaries one by one. Previous diagnoses, procedures and risk flags are on the same page.
2. When tests or treatment are planned after the examination, the physician twin comes in. The recommendation is prepared according to the patient's profile and the physician's own practice, and each recommendation shows its reasoning and the source it relies on.
3. When the discharge summary is written, the text is split into structured fields. Diagnosis codes and procedures are checked against SUT rules, and missing or non-compliant fields are flagged before billing.
4. Where pre-authorization is required, the same clinical synthesis is carried over to the pre-authorization screen. The request starts from a ready clinical summary, not from a file assembled from scratch.
5. At every step, the final decision rests with the physician and the relevant specialist. The system shows the recommendation, its reasoning and its source, and every output can be audited later.

The data stays inside the institution

Building the twins does not require data to leave the institution. The system does not replace the existing HBYS; it is added on top of it as an intelligent layer. Patient and physician twins are built in the institution's own environment, and the institution itself is the data controller. The data the model sees passes through masking that complies with KVKK, Türkiye's personal data protection law. Opinion AI does not collect personal data.

The same principle applies to the physician twin: the behavioral vector is consent-based, and peer comparison is anonymous.

The physician makes the decision

A data twin is not a diagnostic machine. It brings the full picture of the patient and the physician to the moment of decision; the decision itself is made by a person. Every MINA recommendation shows its reasoning and its source, and every output can be audited. The physician sees why a recommendation was made and then accepts, changes or rejects it.

To assess together how patient and physician twins could be set up on your own HBYS environment, use the POC Request form.