Skip to content

Create an account

Sign in
HekimBis home

e-Nabız integrated software follows submission end to end

e-Nabız integrated software makes sure the record signed in the clinic reaches the Ministry of Health's central system correctly and traceably. In HekimBis, submission is a working part of the product, with versioned data mapping, receipt tracking, resubmission and a reconciliation queue. It is designed for the KTS and MBYS process of facilities in scope.

Try it free for 7 daysRequest a demo
  • A calm staff member at a compliance desk beside a binder of forms
  • A calm physician listening to the chest of a patient seated on an examination couch
  • A medical secretary at a desk comparing two closed patient folders side by side

How submission moves from a signed record to a receipt

The quality of submission is measured not only by data going out but by what happens when it cannot. The flow below shows both the main path and the error branches.

An exam, procedure or other clinical event becomes final with the physician's signature. Submission arises from a signed record; a draft or partial record is never sent. The record is mapped to the Ministry's current data definitions, meaning the SKRS and USVS codes. The mapping is versioned: when definitions change a new version is published, and it is always clear which record was sent with which version.

Which clinical event produces which data package is an explicit rule. A link to the source record is added to the package, so the connection between what was sent and its source does not change. The package is designed so that even if the same one is sent again, no second record is created on the Ministry side. The receipt returned by the Ministry service is attached to the record; a package without a receipt is not counted as complete. In the last step the source record, the sent package and the receipt are matched and shown as reconciled on screen.

Because submission arises from a signed record and not from a draft, the data sent to the national system is clinically final. Changes made before the physician signs do not affect submission; corrections made after the signature are sent separately as a traceable additional record.

Three branches represent real life. If the Ministry service is down, the package waits in an encrypted queue and the clinical record is not lost; when the service returns, packages are sent in order. If the service returns an error code, the package falls into the reconciliation queue, the user solves the problem and the package is sent again. If a record is later corrected or canceled, the source record is not changed silently; a new submission is made as a version or cancellation chain.

Reconciliation06End

Reconciled

  • The process is complete here.
6 / 17

All steps

  1. 01 Clinical event (signed record) (Clinical record)
  2. 02 Versioned SKRS/USVS mapping (Mapping)
  3. 03 Data package with provenance (Mapping)
  4. 04 Idempotent submission (Submission)
  5. 05 Receipt (Ministry service)
  6. 06 Reconciled (Reconciliation)

Alternative path from 04 Idempotent submission; it returns to the main flow at 05 Receipt.

  1. 04a Service outage: encrypted queue, nothing lost (Submission)
  2. 04b Service is back: ordered resend (Submission)

Alternative path from 05 Receipt; it returns to the main flow at 04 Idempotent submission.

  1. 05a Error code: lands in the reconciliation queue, the user resolves it, resubmission follows (Reconciliation)
  2. 05b The user fixes it and the package is resubmitted (Submission)

Alternative path from 01 Clinical event (signed record); it returns to the main flow at 04 Idempotent submission.

  1. 01a Correction or cancellation: a version or cancellation chain is sent (Clinical record)

06 Reconciled

Who the requirement covers

The summary below is for information and is not legal advice. Whether your facility is in scope depends on the type of facility, your activity and the regulations in force; consult your health law adviser and the relevant authority. Official sources: KTS Registration(opens in a new tab) and T.C. Ministry of Health(opens in a new tab).

A clinic manager filing receipts into a folder in a quiet office.

  • Basis

    The statutory basis for processing personal health data and for the Ministry's central system is in Additional Article 19 of Law No. 3359. Article 24 of the regulation on private health facilities providing outpatient diagnosis and treatment requires facilities in scope to use a system registered in KTS and to transmit data to the central system.

  • Usually in scope

    Private practices, dental practices, oral and dental health centers, polyclinics and medical centers. The Ministry's MBYS application may also cover the practices of professionals such as psychologists, dietitians and physiotherapists.

  • What your facility does

    Completing your own KTS registration, having the software you use appear on the Ministry's current list, and keeping submission running regularly. Details are in the KTS guides.

  • Penalties and applicability

    These need a legal opinion by customer and activity; consult your legal adviser for a definite answer.

Regardless of scope, you can find the separate privacy notice and explicit consent records that KVKK expects, and role-based access, on the KVKK-compliant patient tracking page.

If you are not sure whether you are within scope, ask the relevant authority in writing about your type of facility and activity, and choose the software according to that answer. If you are within scope, put mandatory submission at the top of your buying criteria, because submission being inside the software means no separate tool and no extra workload.

Errors, retries and the queue

Submission does not run without errors; what matters is that an error is visible, solvable and lossless. In HekimBis three mechanisms provide this.

  • Encrypted queue

    Packages that cannot be sent during a service outage or a connection problem wait in an encrypted queue. The clinical record is not affected; the physician keeps examining. When the connection returns, packages are sent in order, and resending creates no duplicates.

  • Reconciliation queue

    Missing or rejected submissions become a work list belonging to the user. Each row shows the error code, the related record and the suggested action. The user completes the missing field or fixes the mapping problem, then sends the package again. Who solved what, and when, is recorded.

  • Retry and dead letter

    For temporary errors the system retries automatically; after a set number of attempts a package that cannot be solved falls in front of the user and does not disappear silently. The user can then start a resend, and no copy is created.

The content of sent packages is not carried into general logs, support or analytics tools; sensitive content is hidden by default. For your facility's manager the submission screen is filtered by branch, physician and date. See e-Nabız and USS data submission and e-Nabız and USS connection for details.

Monitoring submission takes three checks. Daily, look at whether any package is waiting or has an error in the reconciliation queue; if the list is empty, submission is healthy. Weekly, review the distribution of successes and errors by branch, physician and date; a repeating error for a certain physician or service usually comes from a missing mandatory field and is solved with a form correction. When the Ministry's data definitions change, a new mapping version is published; earlier records stay as sent with the earlier version, backward compatibility is kept and a transition plan is applied if needed.

Mapping versions matter once more: when the Ministry changes its data definitions, it is not enough for the software to pick this up by itself; it must also know which record was sent with which version. In HekimBis each package is stored with the mapping version used, so in an audit or an error review it can be shown why an earlier submission was made the way it was.

What the submission screen shows and who sees it

The submission screen is the facility's daily operations panel; each user sees only the branch, physician and patient context they are authorized for. The screen counts successful, pending and failed packages separately. When you open a package you reach the source exam record, a summary of the data package sent, the receipt received and the error code if there is one. The raw content of a package is not carried into general logs, support or analytics tools; sensitive fields are hidden by default.

For the manager there are two separate needs: today's work and the proof of the past. Today's work is the packages in the reconciliation queue; each can be assigned to someone responsible and is recorded when solved. The proof of the past is which mapping version, on what date and with which receipt each record was sent. When an audit or a data subject request arrives, this chain can be shown from the source record to the receipt.

What your facility does before submission

A healthy start of submission depends on a few steps in order. Some belong to your facility and some to the software.

  1. KTS registrationYour facility completes its own KTS and MBYS registration according to the Ministry's guide; this belongs to the facility.
  2. Declaring the softwareThe software you use is stated in your KTS registration. The KTS guides explain which information and documents are requested for your type of facility.
  3. Users and permissionsPhysician, front-desk and manager roles are assigned. Who sees the submission screen and the reconciliation queue is set by role.
  4. TrialIn the trial workspace you walk through the submission screens and the reconciliation queue with sample records; the team learns in advance which error appears where.
  5. Live submissionThe real connection opens after production activation. In the first days the reconciliation queue is checked daily, and repeating errors are closed with form and mapping corrections.

When evaluating software, ask these four questions. When there are submission errors, is there a queue and resend screen, and can the user solve them alone? When mapping versions change, are earlier records preserved? In a service outage, is the clinical record affected? Does the contract state who is responsible for adapting to a change in regulation or service? HekimBis answers these live in the demo; repeat the same questions with any system whose answer is not clear.

Submission also depends on record quality. A missing mandatory field, a wrong code or a wrongly matched patient identity leads to a rejected package. That is why duplicate prevention and mandatory field checks run during patient registration, and the physician's signature also passes a missing-field check. Most submission errors are solved at this stage, at their source. See Patient registration software and Clinical record.

A compliance officer at a desk with a form binder and a blank wall calendar

Frequently asked questions

What is e-Nabız integration?

It is the transfer of the clinical record to the central system with the Ministry of Health's USS and e-Nabız services in scope, according to defined data definitions. In HekimBis it is a flow that starts from a signed record and ends with a receipt and reconciliation.

When is the submission made?

Submission arises from a signed record. When the physician signs the record, the data package is created, enters the queue and is sent to the Ministry service; when the receipt arrives the record shows as reconciled.

Is my practice in scope?

The scope depends on the type of facility and your activity; private practices, dental practices, polyclinics and medical centers are generally in scope. For a definite answer consult your health law adviser and the relevant authority.

Is data lost if the service goes down?

No. Packages that cannot be sent wait in an encrypted queue, are sent in order when the service returns, and resending creates no duplicates.

What should I do if a submission fails?

The package falls into the reconciliation queue; the screen shows the error code and the related record. You complete the missing field and send it again, and who solved what is recorded.

What happens if a record is corrected later?

A signed record is not changed silently. A correction or cancellation is sent as a new submission in a version and cancellation chain, and its link to the source record is kept.

Can I see submission in the trial?

In the trial workspace you can walk through the submission screens and the reconciliation queue with sample records. The real connection opens after production activation.

Who monitors submission?

Your facility's manager and the users they authorize follow the submission screen by branch, physician and date. Failed packages fall into the user's own work list.

Related pages

Features

Specialties

Solutions and process

Software guides

Guides