e-Nabız and USS data submission
Sending the mandatory minimum health data to the national system should be a by-product of clinical work, not a job of its own. HekimBis turns the signed clinical record into a national data package with versioned rules, sends each package once, waits for the receipt and never loses what could not be sent. Which event became which package, with which version and in which state, is always visible.
Mapping is versioned and every package has a known source
National data definitions (SKRS and USVS codes) change over time. HekimBis keeps its mapping rules versioned: which clinical event produces which data package is an explicit rule, and the version the rule ran with is recorded in the package.
When the Ministry changes the version of a service or a code, the mapping is updated, and backward compatibility and data migration for older records are managed separately.
There is a permanent link between a submitted package and the clinical record it came from. For every package you can answer which record produced it, under which rule and when. If a clinical record is corrected or cancelled, the source record is not changed silently, and a new submission is made as a version and cancellation chain.
- Versioned SKRS and USVS mapping
- Mapping rules are versioned, and which package was produced with which version is on record.
- A clear rule from event to package
- Which clinical event produces which package is a traceable rule.
- A link from package to source record
- Every package is linked to the signed clinical record it came from through a permanent link.
- A version chain for corrections and cancellations
- For a corrected or cancelled record, the correct version and cancellation chain are sent.
- Late submission
- An event that could not be sent on time is submitted later with its source and version.
Submission from the clinical event to the receipt
A signed clinical record is turned into a national data package and sent with a one-time key. When the receipt arrives from the Ministry's service, reconciliation is complete. During a service outage the package waits in an encrypted queue, and if an error code comes back the record enters a reconciliation queue where it can be resolved and is then resent without duplicates.
Reconciled
The sent package, the receipt and the source record match; the submission closes.
- The process is complete here.
- P-0044Error code E-17 · missing fieldTo resolve
- P-0045CorrectedSend again
The names, times and records on the screen are examples.
All steps
- 01 Clinical event (Clinical record) A signed examination or diagnostic result is marked as an event that creates a national data package.
- 02 Versioned mapping (Mapping) The event is mapped under the current SKRS/USVS rules; the mapping version is written to the record.
- 03 Data package and provenance (Mapping) The package is created; an immutable link (provenance) to the source record is made.
- 04 Once-only submission (Submission) The package is sent to the ministry service with a once-only key; the same key is not accepted twice.
- 05 Receipt (Ministry service) The ministry service accepts and returns a receipt. If an error returns, it enters the reconciliation queue.
- 06 Reconciled (Reconciliation) The sent package, the receipt and the source record match; the submission closes.
Alternative path from 04 Once-only submission; it returns to the main flow at 04 Once-only submission.
- 04a Service outage: encrypted queue (Submission) The ministry service does not respond. The package waits in an encrypted queue; the clinical record is unaffected and not lost.
- 04b Retry (Submission) When the service returns the queue is retried in order; the once-only key prevents a double record.
Alternative path from 05 Receipt; it returns to the main flow at 04 Once-only submission.
- 05a Error code (Ministry service) The service rejects the package with an error code (for example a missing or invalid field). The submission counts as failed.
- 05b Dead-letter (Submission) A package that will not heal by automatic retry is moved to the dead-letter queue; it is not lost and waits for a person.
- 05c Reconciliation queue (Reconciliation) An authorized user sees the error code and the field to correct, and fixes the record.
- 05d Send again (replay) (Submission) The corrected package is resent without duplication and a receipt is awaited.
Alternative path from 01 Clinical event; it returns to the main flow at 02 Versioned mapping.
- 01a Correction or cancellation (Clinical record) If the clinical record is corrected or cancelled later, the source is not changed; a new submission is prepared as a version and cancellation chain.
06 Reconciled
Daily operation runs on the queue, errors and reconciliation
An operations view for authorized users shows which submissions are pending, successful, failed or in need of reconciliation, in the context of the patient, branch and user.
The error code comes with the field that needs correcting, and a resolved record is resent without duplicates. During a service outage the package waits in an encrypted queue and the clinical record is unaffected.
The same information is also followed by the HekimBis operations team: the service version, success and error counts, the active list and compliance status by organization and branch. An inventory of versions, documents, certificates and audit findings that supports the KTS and MBYS registration process is maintained. When regulation or a service changes, a named owner and an emergency adaptation procedure allow a quick response.
Package content goes only to the national service
A national data package carries sensitive health data, so content and status are kept apart.
- Package content is passed only to the national service and is not written to general application logs or monitoring tools.
- On support screens the content is masked by default, while the status and error code stay visible.
- The validated clinical fields that the current dataset requires are sent, and raw device messages and image data are not copied into the package.
- The submission operations screen is authorized by patient, branch and user context, and pending packages are held in an encrypted queue during a service outage.
Frequently asked questions
Is e-Nabız and USS submission mandatory, and who does it cover?
The scope of the obligation depends on the type of your organization and current regulation, and we recommend confirming applicability with your health-law adviser and the relevant authority. HekimBis runs the mandatory minimum data submission, and it is switched on according to your organization's scope.
What happens if the internet or the service goes down during submission?
The package waits in an encrypted queue, and the clinical record is neither affected nor lost. When the service returns, it is retried automatically, and thanks to the one-time key the same record is never sent twice.
What do I do if an error code comes back?
The submission goes into a reconciliation queue where it can be resolved. The screen shows the error code and the field that needs to be corrected. After the correction the package is resent without duplicates and the receipt is awaited.
What happens to the data sent to the Ministry if I correct the record later?
The source clinical record is never changed silently. A correction or cancellation is passed on as a new submission with a version and cancellation chain, and it is reconciled with a receipt.
Which data is sent?
The validated clinical fields required by the current dataset are sent under versioned mapping rules. Clinical events such as visits, diagnoses and procedures are the source of a package, and raw device data or image pixels are not copied automatically.
Are diagnostic results sent too?
When the relevant national dataset is mandatory, laboratory and imaging results are sent as well, with their validated fields. For a corrected or withdrawn result, the correct version and cancellation chain are sent, and every submission is reconciled with a receipt.
Who follows the submission status?
An authorized user follows their own branch's submissions in the operations view, and the HekimBis operations team follows the service version, success and error counts and compliance status by organization and branch.
Can the support team see the submitted data?
Package content is not written to general logs, monitoring tools or support screens by default; support screens show the status and error code with the content masked. Support access opens only with a ticket, a reason and a time-limited approval, and with masking.
How do the KTS and MBYS process and the submission relate?
HekimBis keeps the inventory of versions, documents, certificates and audit findings that supports the KTS and MBYS registration process. Submission is the product's working regulatory layer, and when regulation or a service changes, a named owner adapts the mapping quickly.
Keep reading
Related pages
Features
Specialties
Software guides
Integrations
Guides
- e-Prescription in the Clinic and Where the Prescription Draft Sits in the Examination RecordWhat is e-Prescription, where does it sit in a physician's workflow, and what does clinic software do? How a prescription draft is prepared, approved and stored with the examination record.
- KTS and MBYS Registration Guide for Practices and ClinicsWhat are KTS, MBYS and USS/e-Nabız data submission? The registered-software obligation, the vendor's process and the questions a clinic should ask.