e-Prescription (e-Reçete) is part of a physician's everyday work in Türkiye. When choosing clinic software, the question "does the software support e-Prescription?" often merges two separate things into one sentence: the physician's clinical work during the examination and the transmission of the prescription to the official system. This article explains what e-Prescription is, at which layers a clinic software can take part in the process, and how a prescription draft works with the examination record in HekimBis.
What is e-Prescription?
e-Prescription means writing drug prescriptions electronically instead of on paper, recording them in a central system, and letting the pharmacy dispense from that record. The physician issues the prescription, it is stored in the system operated by the Ministry of Health, and the patient collects the medication at the pharmacy using their identity and prescription information. The official part of the process is the physician's identity verification, the transmission of the prescription to this central system, and the pharmacy's query.
From this point two separate surfaces appear:
- The physician's clinical work: the patient's history, diagnosis, medications in use, allergies, earlier prescriptions. This happens on the physician's examination screen.
- Official submission: sending the prescription to the central system. This requires a verified connection to the relevant official service and completed registration and test processes.
The everyday value of clinic software is measured by how orderly, traceable and safe it makes the physician's work on the first surface.
At which layer of the prescription process does clinic software take part?
When a software vendor says "e-Prescription compatible," they may mean one of three things:
- The software can edit and print prescription content (draft and printout).
- The software hands over to a separate physician tool that sends the prescription to the official system.
- The software connects directly to the official service and sends the prescription itself.
The three create different value and different responsibilities. Before buying, ask: "From the moment the prescription leaves the physician's screen, in which system and in what state is it?" Getting a written, concrete answer to this prevents a mismatch of expectations from the start.
The prescription flow in HekimBis
In HekimBis, the prescription is prepared as a draft inside the physician's examination flow. While writing the examination record, the physician enters the drugs, doses and instructions; the draft is linked to the patient's file and can be printed. The owner of the prescription draft is the physician; no record is finalized without physician approval. When the examination record is signed it is locked; if needed later, a correction record is opened and the old record is not deleted.
The physician's approval and signature are stored with the record. So the answer to "what was written that day?" is always clear, together with the correction trail. Prescription information follows the same access rules as the rest of the patient file: which user can see which record is decided by role, branch and care relationship.
The clinical value of a prescription draft
Preparing an orderly prescription draft during the examination brings real gains:
The patient's history on the prescription screen. While writing a new prescription, the physician sees earlier prescriptions, known allergies and chronic medications. This reduces the risk of overlooking a duplicate drug or a known allergy.
Frequently used templates. Physicians often write similar prescriptions for similar complaints. Personal templates save time, but every prescription is still subject to the physician's approval.
Record integrity. A signed prescription draft is locked together with the examination record. If a later dispute arises ("I didn't prescribe that drug" or "the dose was different"), the record stands with its correction trail.
Dictation and draft support. If an AI assistant is used, it can produce a structured note draft from a voice recording. The draft is not finalized until the physician edits and approves it, and its source, output and change trail are stored. See our AI article for details.
Correction (with reason, traced)
If there is an error, the correction record is kept with its reason and the previous version alongside.
- The process is complete here.
- Day 1 · 10:05SignedPhysician A
- Day 2AddendumPhysician A · new information
- Day 3CorrectionReason: wrong field
Names, times and records on the screen are examples.
All steps
- 01 Draft (Physician) The physician opens the examination record and begins writing. The record is a draft and freely editable.
- 02 Autosave (System) The system saves what is written automatically; the draft is kept even if the page is closed.
- 03 Physician review (Physician) The physician reviews the record: missing fields, inconsistencies, correct patient and date. If satisfied they go to signature; otherwise back to the draft.
- 04 Signature and lock (Physician) The physician signs; the record locks and is pinned to the form and specialty-pack version.
- 05 Addendum (Physician) If information needs to be added later, an addendum is opened without touching the signed record, with who and when.
- 06 Correction (with reason, traced) (Physician) If there is an error, the correction record is kept with its reason and the previous version alongside.
Alternative path from 03 Physician review; it returns to the main flow at 01 Draft.
- 03a Review: correction needed (Physician) The physician sees a missing or wrong field; the record stays open as a draft, is corrected and returns to review.
Alternative path from 04 Signature and lock; it returns to the main flow at 06 Correction (with reason, traced).
- 04a Attempt to edit a signed record (System) Someone tries to change the locked record directly. The system rejects it; a correction record with a stated reason is opened instead.
06 Correction (with reason, traced)
Questions to ask when buying
When evaluating e-Prescription scope in a clinic software, these questions help:
- Is the prescription sent to the official system by the software itself, or does the physician switch to a separate tool?
- At what stage are the registration and test processes required for official submission? Are the date and scope in writing?
- If submission fails, how does the physician find out, and is there a resubmission path?
- Can a prescription be finalized without physician approval?
- Can a signed prescription be changed afterward, and does the change leave a trail?
- In which country is prescription data kept, under which access rules?
- If the software gives drug-interaction or dose warnings, what source are they based on and who keeps them current?
- For the features named in the contract, are the date they become available and the responsibility in writing?
The last question is especially important. Making a purchase decision based on a feature that is not yet available can mislead both the physician and the clinic owner.
e-Prescription, e-Report and national data submission are different processes
Three concepts are often confused:
| Concept | What it does |
|---|---|
| e-Prescription | Sends the drug prescription to the central system |
| e-Report | Issues health reports electronically |
| USS / e-Nabız data submission | The facility sends minimum health data to the national system |
The third row concerns a mandatory obligation for facilities in scope. HekimBis runs this submission with versioned mapping, submission, receipt and a reconciliation queue; the steps of submission, error cases and retry logic are described on the USS data submission page. For the registration side (KTS, the Ministry's registration and listing system) and scope, see our KTS/MBYS guide.
For clinics that contract with SGK (the Social Security Institution), SGK-side processes are a separate area; you need to plan which obligations apply to you according to your clinic's relationship with SGK.
What physicians commonly get wrong when prescribing
Prescription errors usually arise from workload, not ignorance. Clinic software cannot prevent them entirely, but it can offer a setup that lowers the chance of their occurring.
Duplicate drugs. A patient forgets to tell the physician about a chronic medication, and the physician writes a second drug with the same active ingredient. Showing the patient's current medication list on the prescription screen reduces this risk. The list is built from the clinic's own records; drugs the patient obtained elsewhere are added when the patient or physician enters them.
A known allergy overlooked. Allergy information should sit in a separate field of the patient file and be easy to see on the prescription screen. A warning does not change the physician's decision; it only calls attention.
Missing instructions. Dose, duration and method of use can be standardized with templates. A template's purpose is to reduce the chance of omission; every prescription passes the physician's eyes.
A prescription written for the wrong patient. Files of two patients with the same name can be mixed up. Showing date of birth and ID information on screen and cleaning up duplicate records is an important safety measure.
Most of these errors shrink with a simple, orderly screen design. Every warning offered as decision support is subject to the physician's approval.
Record integrity and audit
A prescription is a medical and legal document, so the life cycle of the prescription record in the software should be taken seriously. In HekimBis the examination record starts as a draft, is saved automatically, and is signed and locked after physician review. A signed record cannot be silently edited; if a correction is needed, a correction record with a reason is opened and both versions remain traceable. This makes the answer to "what was written that day?" definitive in a possible dispute.
A note on signature type: components such as a biometric signature, a one-time code and a time stamp add evidentiary value to record integrity; HekimBis names them as record-integrity components. When choosing software, prefer vendors who name the signature type accurately.
Small clinic, large clinic: how expectations change
In a single-physician practice, e-Prescription is a process that runs on the physician's own identity verification, and the expectation of the software is a fast draft screen that fits the examination flow. In a multi-physician clinic the scale of the work changes: which physician wrote which prescription, for which patient, at which branch, who can see which record, and how a patient's whole prescription history is listed all matter. Role and permission structure becomes decisive: a front-desk employee should not see prescription content, and a physician should be able to open only the records of patients in their care relationship.
Remember when deciding scope: the type, specialty and SGK relationship of your facility change which official processes are mandatory. Ask the relevant authority and your health-law adviser which obligations apply to you. You can read about HekimBis's approach on the why HekimBis page.
Conclusion
e-Prescription is not a checkbox in clinic software but a defined chain of responsibility. HekimBis offers the prescription draft as a secure part of the examination record: the physician prepares, approves and signs it, the record is locked and the change trail is kept. When choosing software, ask "at which layer, with whose responsibility" instead of a yes/no question. For the physician's screen and specialty-specific examination structure see the doctor software page, and for record integrity see the clinical record page.
