Skip to content

Create an account

HekimBis home

National data submission

e-Nabız and USS integration

Submission is a by-product of the clinical record and creates no separate data entry work. A signed record is mapped to the fields the current data set requires, submitted, awaited for a receipt and reconciled. No record is lost when the Ministry service is down.

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

A submission goes through a recorded life cycle

Submission is managed within a separate national data boundary outside the clinical record. The core clinical record is not built into the national data model.

  • Versioned mapping

    Versioned mapping follows current data definitions and national codes. When the mapping changes, backward compatibility and migration are managed.

  • Explicit rule

    Which clinical event produces which data package is shown by an explicit rule.

  • Duplicate-safe submission

    Even if the same package is sent again, no duplicate record is created.

  • Receipt, error and retry

    Every submission has a life cycle of receipt, error code, retry, dead letter and replay.

  • Correction and cancellation

    Corrections and cancellations are sent through a version and cancellation chain, and the source record is never changed silently.

  • Traceability

    The link between a submitted package and its source record is stored immutably.

  • Queue during a service outage

    When the Ministry service is down, the submission waits in an encrypted, observable queue; the clinical record is unaffected, and once the service returns the submission continues without duplicates.

  • Masking

    Submission content is masked by default in general logs, monitoring and support screens.

  • Visibility by organization and branch

    Platform operations track the service version, and success and error state, by organization and branch.

From submission to reconciliation, lossless even in an outage

A signed clinical record becomes ready for submission, and the submission, the receipt and the reconciliation are tracked step by step.

Reconciliation05End

Reconciliation

Sent and received records are matched.

  • The process is complete here.
5 / 16

All steps

  1. 01 Clinical event (Clinical record) A signed record becomes ready for submission.
  2. 02 Versioned mapping (Mapping) Fields are mapped to the current dataset.
  3. 03 Submission (Submission) A duplicate-protected submission is made.
  4. 04 Receipt (Ministry service) The Ministry service returns a receipt.
  5. 05 Reconciliation (Reconciliation) Sent and received records are matched.

Alternative path from 03 Submission; it returns to the main flow at 03 Submission.

  1. 03a Service outage (Submission) The submission waits in an encrypted queue; no record is lost.
  2. 03b Retry (Submission) Sent without duplication once the service returns.

Alternative path from 04 Receipt; it returns to the main flow at 03 Submission.

  1. 04a Error code (Reconciliation) The receipt returned an error.
  2. 04b Reconciliation queue (Reconciliation) The user resolves the cause and resubmits.

Alternative path from 01 Clinical event; it returns to the main flow at 02 Versioned mapping.

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

05 Reconciliation

A clinic manager and a physician compare submission records in a shared folder at a table

A submission that returns an error is resolved in the reconciliation queue

When the Ministry service rejects a submission or a record is left incomplete, the submission lands in a reconciliation queue that a user can work through. The user fixes the cause of the error and restarts the submission.

During a service outage, submissions wait in an encrypted queue and are sent without duplicates when the service returns. Submission content is masked by default in general logs, monitoring and support screens.

Successful submission, error scenarios and receipt reconciliation are tested in a test environment. Only the verified clinical fields the current data set requires are sent; raw image pixels and device data are not copied.

e-Nabız and USS reporting

Which data goes into the national package?

Submission is limited to the verified clinical fields the current data set requires. These fields are produced from the signed record through versioned mapping and the SKRS and USVS codes, and the source record of each field is tracked with the submitted package.

Raw image pixels and device data do not go into the national package, only verified clinical fields. A result from a device joins the package as the relevant field once it has been clinically verified.

The same rule applies to diagnostic results: a corrected or withdrawn result is matched on the national side with the right version and cancellation chain and a receipt, so the result shown at the clinic and the record at the Ministry stay the same.

The KTS process and submission are followed on the same platform

For practices and polyclinics, registration runs through the Ministry of Health KTS system. HekimBis keeps the versions, documents, certificates and audit information this process needs as an inventory.

Platform operations track the service version, success and error rate and active list status by organization and branch.

When a physician signs the examination record, the submission is prepared automatically; its status is followed on the reconciliation screen, and no extra data entry is needed.

Frequently asked questions about e-Nabız and USS submission

FAQ
What is e-Nabız and USS submission?

It is the transmission of the clinical fields the current data set requires, for a health service, to the Ministry service. HekimBis sends only verified clinical fields, through versioned mapping.

Is data lost if the Ministry service goes down?

No. The submission waits in an encrypted queue and is sent again without duplicates when the service returns.

What happens if a submission returns an error code?

The record goes to the reconciliation queue; the user resolves the cause and resends. Corrections and cancellations are sent through the version and cancellation chain.

Can I correct a record that was already submitted?

Yes. A correction or cancellation is resent through the version and cancellation chain and reconciled against the receipt.

Which data is sent?

The verified clinical fields the current data set requires, through versioned mapping.

Are diagnostic results submitted too?

Where the data set requires it, the verified clinical fields of laboratory and imaging results are submitted under the same rule. A corrected or withdrawn result is sent through the version and cancellation chain.

Who follows the submissions?

The organization's administrator and authorized users follow the status of submissions on the reconciliation screen. Platform operations track the service version, and success and error state, by organization and branch.

Can I see the submission flow before I commit?

The seven-day trial runs on sample data, and you can look at the submission flow and the reconciliation queue in the test environment.