KTS and MBYS Registration Guide for Practices and Clinics

Everyone who selects software for a practice or private health facility meets the same abbreviations at some point: KTS, MBYS, USS, e-Nabız, SKRS. Some vendors mix these abbreviations up, and some sell with statements that do not match the real situation. This article explains what the abbreviations mean, where the responsibilities of the software company and the clinic divide, and which questions you should ask a software vendor. It is not legal advice; verify which obligation applies to you from Ministry of Health sources and your adviser.

The abbreviations: who is who?

KTS (Registration and Listing System): the system through which the Ministry of Health carries out registration of information systems used in health. Software producers put their products through application and evaluation via this system; registered software appears in published lists. For official information see the KTS registration stages(opens in a new tab) page.

MBYS (Practice Information Management System): the category of information management software used by practice-scale health businesses. The Ministry announces registration information for this category on a separate page: MBYS registration(opens in a new tab).

USBS (Remote Health Information System): the software category used in remote healthcare. It is subject to a separate registration process; for details see our telehealth article.

USS / e-Nabız data submission: the facility sending the defined minimum health data to the national system. The format, coding and timing of submission follow the data definitions the Ministry publishes.

SKRS: the Health Coding Reference Server; the source of the standard codes used in data submission.

The difference between these categories matters: software being registered as an MBYS does not mean it is registered as a USBS, and being able to submit data does not mean being registered. Each is a separate qualification and verification matter.

Where does the obligation start for a clinic?

The regulation on private health facilities providing outpatient diagnosis and treatment, together with the regulations on health information management systems, foresee that certain facilities use an information management system registered by the Ministry and send defined data to the national system. How these provisions apply to your facility depends on its type (practice, polyclinic, medical center, diagnostic center, etc.), its operating permit and current regulation.

The practical approach: have it confirmed in writing that the software you will use is registered for your facility type and able to submit data, and also check this from the Ministry's official sources. The vendor's verbal statement is not enough.

What must a software company accomplish?

The jobs a software company meets in the registration process are, in general terms:

Preliminary assessment. Clarifying which registration category the product falls under, the audit scope and the required documents.
Corporate documents. Company information, authorized-signatory records, confidentiality and security undertakings.
Information security and process capability documents. Evidence of capability described in the current guide, such as an information security management certificate and software process maturity documents. Which ones are required for which category depends on the current guide.
Requirement-evidence traceability. Linking each item of the guide to design, test and operations evidence.
Integration and standards tests. Tests on data submission to national services, error cases and conformance to data definitions.
Closing audit findings. Fixing the points seen as deficient.
Entry to the active list and continuity. Renewed conformance for version changes and regulatory updates after registration.

Because there is no end-to-end time guarantee or pre-announced fixed fee for software registration in official sources, a software company should not be expected to commit to a firm registration date. Be wary of a vendor who gives a firm date.

"Application submitted" is not the same as "registered"

This is the most frequent misrepresentation in the software market. A company may have applied; the application process may be ongoing; the product may not be on the list yet. That does not mean the product is registered. Questions to ask as a customer:

In which category and with which version is the product registered? Is it on the active list?
Can the registration document or a Ministry letter be shown?
What are the registration date and validity conditions?
If re-verification is needed after version changes, who manages it?
Is the registration status written in the contract; what are the customer's rights if registration is lost?

Getting the answers to these questions in writing bases a purchase decision on the real situation. You can find HekimBis's USS/e-Nabız approach on the e-Nabız integrated software page.

Reconciliation06End

Reconciled

The sent package, the receipt and the source record match; the submission closes.

The process is complete here.

6 / 19

Reconciliation queue

P-0044Error code E-17 · missing fieldTo resolve
P-0045CorrectedSend again

Names, times and records on the screen are examples.

How does data submission work in practice?

A registered software's national data submission works with this logic:

Clinical event. A signed examination or procedure record creates an event subject to submission.
Mapping. The record's fields are mapped to the versioned data definitions and codes the Ministry publishes. When the definitions change, the mapping is updated.
Packaging. The data package to be sent is created and stored in a way that shows which record it rests on.
Submission. The package is delivered to the service. Re-sending the same package must not create a duplicate record.
Receipt. When the service accepts, a receipt returns and is linked to the record.
Reconciliation. The clinic's record and the submitted record are compared; missing or rejected submissions are presented to the user in a queue to be resolved.

If the service is temporarily unavailable, submission waits in a queue, is retried and, if it finally fails, drops into a state visible to the user. This logic is described in HekimBis's USS data submission feature; the integration approach is on the e-Nabız and USS integration page.

Registration, e-Prescription and other national processes: do not confuse them

KTS registration and data submission are handled separately from e-Prescription, e-Report, SGK processes and e-documents. Each has its own conformance requirement and test process. HekimBis runs mandatory minimum USS/e-Nabız data submission with versioned mapping, submission and a reconciliation queue. For the e-Prescription topic see our e-Prescription guide.

Common misunderstandings

"Software with a KTS registration meets all obligations." No. Registration shows that the software meets certain technical and security requirements; the clinic's own obligations (privacy notice, permission management, correct record keeping, staff training) continue. Software is a tool; compliance comes with the way you use the tool.

"Cloud software cannot register in KTS." Registration depends on the category and requirements, not on how the software is deployed. For cloud software, extra questions arise such as data location, audit acceptance of multi-tenant architecture and assessment of subprocessors. The written answers to these are part of the registration process.

"Data submission is set up once and then forgotten." Data definitions and coding versions change over time. If the submission logic does not adapt, rejected submissions pile up. The software provider needs someone who follows regulation and data-definition changes and an emergency adaptation procedure.

"If submission fails, there is nothing the physician can do." On the contrary, most solvable errors (missing identity information, an empty required field, an invalid code) can be corrected at user level. So the reconciliation queue should be open to the user with understandable error messages.

A short timeline: a newly opened practice

For a physician opening a new practice, the software and registration side can go like this:

Operating permit process. The institution's own permit and license procedures; this is independent of the software and the first step.
Software selection. Choosing a registered software able to submit data; asking for registration evidence.
Setup and definitions. Physician, service, room and user definitions; identity verification and authorization settings.
Trial day. Playing a day with synthetic or test data; verifying data submission in the test environment.
Move to production. The contract, the activation gate and entering real patient data.
Monitoring. Regular monitoring of the submission queue and reconciliation.

In HekimBis the trial period works with synthetic data; real patient data and live national service connection are used once production activation is completed. That way live health data is not reached before registration and verification steps are done. The steps are described on the how it works page.

Extra topics for multi-physician and multi-branch structures

In a polyclinic, medical center or multi-branch structure, data submission requires the correct mapping of physician, branch and facility identities. If a physician works at more than one branch, it must be clear which branch and which institution a submitted record belongs to. Branch-level operations screens show which branch's submission is accumulating. In addition, the legal entity, facility and branch structure of the organization must match the Ministry's records and the structure in the software; a mismatch is a common cause of rejected submissions. Appoint someone responsible for these matters and have the structure mapping confirmed in writing with your software provider.

Ten questions before buying

Is the software registered in KTS for my facility type? What is the evidence?
Is the registration on the active list, from what date and with which version?
Does it perform the mandatory data submission? For which data packages?
What happens if submission fails? Is there a resubmission path?
Can the receipt and the reconciliation queue be shown?
When data definitions change, who updates and how quickly?
Where is patient data kept during and after submission?
Do submission records and error logs expose sensitive data?
Is the registration status in the contract, and what rights does the customer have if registration is lost?
For separate processes such as e-Prescription, e-Report and SGK, is it clear and in writing which of them the software covers?

Preparation on the clinic side

Even if the software is registered, the quality of submission depends on the clinic's record discipline. A missing diagnosis code, an empty required field or wrong identity information leads to rejection. So: inform physicians about the use of diagnosis and procedure codes, make sure required fields are not left blank, appoint a person to regularly watch the queue of rejected submissions, and review submission status monthly. Queue management is a small job; if neglected, it grows into a large backlog.

Conclusion

KTS, MBYS and data submission are not a software "feature" but a matter of regulation and verification. When choosing software, settle the category, registration status, data submission, error handling and scope limit in writing; never overlook the difference between "application submitted" and "registered." For practice scale see the practice software page, and for multi-physician structures the polyclinic software page for the scope notes.