Structuring the discharge summary for ICD-10 coding and SUT checks

Most of what is learned during a patient’s stay ends up in the discharge summary (epikriz): why the patient was admitted, which tests were done, which diagnoses were made, what treatment was given and with which recommendations the patient was discharged. The physician writes this document as a clinical narrative. A few steps later, the same document reaches the coding and billing teams for another purpose: they try to work out from it whether diagnoses were coded correctly, whether procedures comply with SUT (Türkiye’s reimbursement rules), and whether the invoice has a missing or inconsistent item.

Information locked in free text

Free text is natural for physicians; for systems it is a hard source to read. The same finding appears in different words, abbreviations or Latin terms depending on who is writing. A diagnosis sits in the middle of the text but never reaches the coding field. A procedure is described in the discharge summary but has no matching line on the invoice. Left unnoticed, these mismatches return at the payment stage as a rejection or a deduction, and fixing them then takes time and sends the file back.

The problem is not limited to billing. When the patient returns for the next visit, the physician who sees them reads the same free text again to reach a summary of the previous stay. The information is there, but it has to be extracted again every time.

The patient twin brings documents into a single live profile

The core structure of TIS on the patient side is the patient twin. HBYS (hospital information system) and Medula (the social security provision and billing system) data are combined in a single live patient profile. Discharge summaries and reports are not just attached as files; they become part of the profile as structured fields. The clinical summary, risk flags and the SUT check sit in the same view.

The profile grows richer over time. Every new application, report and discharge summary is added to the same profile; at the next visit, the physician finds previous stays in one view instead of separate files.

Different teams no longer need to read the same information over and over. The physician sees the clinical summary, the coding team the diagnosis and procedure fields, and the billing team the SUT check results, all from the same record. Pre-authorization and invoice preparation start from a ready clinical synthesis rather than a blank page.

The discharge summary is separated into structured fields

The conversion starts with reading: MINA reads the discharge summary and accompanying reports and separates diagnoses, procedures, medications and key findings into their respective fields. The abbreviations, spelling variations and mixed terminology of Turkish clinical language are handled at this step. Structuring does not alter the text; the physician’s discharge summary stays as written, and the fields sit beside it as a separate layer.

An important principle applies here: the document and the inference are kept apart. For every field, what it rests on in the document is visible. Users can go straight from a field to its source text. What the document states explicitly and what the system has interpreted are shown separately in every answer, which makes the output auditable.

ICD-10 suggestions and SUT checks

MINA suggests ICD-10 codes from the structured diagnosis fields. Each suggestion comes with its rationale, with the expression and finding it rests on shown alongside. A diagnosis that appears in the discharge summary but has not been coded, or a code with no support in the text, is flagged separately.

The SUT check runs on the same fields. Procedures, supplies and medications are compared against SUT rules. The decision here sits in the rule engine: the rule engine determines whether a procedure complies with SUT, and AI explains the result and the relevant rule. When a mismatch appears, the team sees not just a “non-compliant” warning but the reason behind it.

Consider an example. The discharge summary mentions a secondary diagnosis, but the coding field holds only the primary one. The system flags this diagnosis together with the relevant sentence in the text and offers an ICD-10 suggestion. The physician sees the sentence, decides whether the diagnosis should be coded and approves or corrects the suggestion. If a report required for a procedure is missing from the same file, the SUT check shows it together with the relevant rule, and the team completes the report before invoicing.

Gaps are flagged before payment

The real gain is in the timing. SGK/Medula billing errors (SGK is Türkiye’s Social Security Institution) and SUT mismatches are flagged before the invoice is issued and before the payment process begins. A missing report, an unsupported code or an invoice line that does not match the discharge summary becomes visible before the file leaves the institution. Rejection risk is handled when correction is easiest, not after the file comes back.

This changes how teams work, too. Coding and billing teams work from the same record rather than on the same gap separately. Questions and answers between the physician, coding and billing also run through that record, and everyone sees the same reason for a flagged gap.

Final approval rests with the physician

MINA does not make decisions; it supports them. An ICD-10 suggestion is not final until the physician approves it, and the SUT check result goes to the relevant team for review. People make the decision; AI shows its rationale and source, and every output can be audited. The physician is free to accept or change a suggestion.

Data stays inside the hospital. Discharge summaries and reports are processed within the institution’s own environment; personal data is protected with KVKK-compliant masking, and the institution remains the data controller. TIS does not replace the HBYS; it is added on top as an intelligent layer and can start with a single module and grow as needed.

To see this move to structured data in your own workflow, you can submit a POC request.

POC Request