Hospital Information System Integration in Turkey: What to Know

In Turkey, hospital information system integration means working with the hospital's HBYS (Hastane Bilgi Yönetim Sistemi), the hospital information system, usually built by a Turkish vendor, that runs admissions, clinical records, pharmacy and billing, and that already reports to the Ministry of Health and to SGK, the social security institution. The work goes through the hospital and its HBYS vendor, under a 2022 regulation that makes those vendors register with the Ministry and keeps health data inside the country. If your product is operational (rostering, HR, workforce analytics), much of the data you need sits in the hospital's HR and payroll systems, and that route is far easier.

Our experience is on that easier route. We're a small software company in Ankara and the engineering team for Oplist, a client of ours that makes hospital shift-scheduling software. Oplist exchanges data mostly with hospitals' HR and payroll systems. We have not built a clinical HBYS integration, and we say so below where it matters.

What an HBYS covers

HBYS is the Turkish term for a hospital information system. A typical one handles patient admission and appointments, outpatient and inpatient workflows, orders and results, operating theatre records, pharmacy and stock, billing, and management reports. Some products add personnel, leave and on-call modules.

It is rarely one product. The Ministry's registration system for health software vendors, KTS (Kayıt Tescil Sistemi), records 17 types of software, and HBYS is only one of them. Laboratory (LBYS), imaging (PACS/RIS), intensive care, dialysis and oncology systems are registered as separate types, so a large hospital can run several registered products from different vendors, with the HBYS in the middle. When someone says "the hospital system", ask which one they mean.

The national systems every HBYS feeds

A Turkish HBYS is wired into a set of government systems. You won't connect to these yourself, but they shape what the hospital's data looks like and what the HBYS vendor spends its time on.

The description of USS and e-Nabız comes from the Turkish Court of Accounts' audit of the e-Nabız project: health data created in every facility is collected online through web services, and citizens can see their own test results, images, visits and prescriptions in e-Nabız and share them with relatives and doctors they authorize.

Two consequences for an outside product. Keeping those feeds running is the HBYS vendor's legal duty, so expect your integration request to wait behind it. And coded fields follow national code lists, so ask for the SKRS code tables along with any data, or you will be guessing what a value means.

The rules you need to know

The SBYS regulation

The main text is the Regulation on Health Information Management Systems (Sağlık Bilgi Yönetim Sistemleri Hakkında Yönetmelik), published in the Official Gazette on 25 August 2022. An amendment on 3 July 2026 (Official Gazette no. 33299) changed only the KTS registration rules, dropping the ISO 27001 and SPICE/CMMI certificates the regulation used to require from applicants; the articles cited below are unchanged. The regulation calls these systems SBYS and defines them broadly: software that health service providers use for clinical, administrative or managerial purposes and that can exchange data with other systems. The provisions an integrator runs into:

• Vendors must be registered in KTS to operate in health facilities, and must keep their data submission services running (Article 5).
• Health data may be stored only in the facility's own environment, in the Ministry's central systems, or in environments approved by the Ministry's General Directorate of Health Information Systems after a remote or on-site audit, and only inside Turkey. The same article treats the vendor as a data processor (Article 16).
• The buyer keeps SAMİLOG logs (the Ministry's minimum logging standard for changes to records) for at least five years and other logs for at least two, protected against changes and signed with a qualified timestamp (Article 17).
• Backups get a restore test at least every six months, recorded in signed minutes (Article 15).
• A public hospital lists in its tender or contract every system and device the HBYS must integrate with. The vendor can't charge it for integrating with Ministry systems, and fees for other system and device integrations are capped by a points table (puantaj tablosu) that the directorate publishes and updates every six months (Article 12).

That last point is the one that affects you. Your product isn't a Ministry system, so connecting it is paid work for the HBYS vendor. If it isn't on the hospital's integration list, expect a separate quote for the vendor's side, check whether the points table covers that kind of integration, and agree who pays before anyone writes code.

Does the regulation cover your product? The definition includes administrative software, and some of the 17 registered types are administrative: asset management (DVYS), needs management (İYBS), decision support and business intelligence (KDS), and occupational health (İSBS). None is a rostering, HR or payroll tool. If your product runs BI over hospital data or keeps occupational health records, assume it may need registration. Otherwise we would raise the question with the hospital's IT department in the first meeting rather than guess, and get legal advice if your product will hold patient data.

KVKK, the data protection law

KVKK (Law No. 6698) lists health data as a special category (Article 6). The 2024 amendment rewrote the list of grounds on which special-category data may be processed. The one written for healthcare covers processing by people under a duty of confidentiality, or by authorized institutions, for diagnosis, treatment and care and for the planning, management and financing of health services; explicit consent is another. Whatever the ground, the adequate measures set by the Personal Data Protection Board apply on top. The same list has a ground for obligations in employment and social security, which becomes relevant when an HR record carries health information, such as a sick-leave report.

Sending personal data abroad falls under Article 9, rewritten in 2024. It needs an adequacy decision or one of the listed safeguards, such as the Board's standard contract, which has to be notified to the Board within five business days of signing; beyond that there are only a few narrow, occasional exceptions. For a foreign SaaS company the practical result is simple: plan Turkish hosting for anything that touches patient data, and set up the transfer paperwork before staff data leaves the country.

How the data actually moves

Don't open the first meeting with "do you have a FHIR API?". HL7 FHIR is the international standard for healthcare APIs (R5 is the current published release), but you can't assume a Turkish HBYS exposes it. Ask the vendor which of these it offers:

1. A documented API (REST or SOAP) with a test environment.
2. HL7 v2 messages, the older message standard that many lab and device interfaces use.
3. Read-only access to database views (in practice the VEM views described below) or a reporting replica.
4. Scheduled file exports (CSV or Excel) over SFTP.

The regulation already defines a read path. The Ministry publishes a minimum data model, VEM, and every SBYS vendor has to build database views that follow it; they are what a hospital's data moves through when it changes vendors. Article 14 says analytical queries, such as those of decision support systems, can run over VEM. The hospital isn't supposed to ask the vendor for views outside VEM; when access is needed, the vendor grants read-only access through VEM, and a public hospital can't ask it for a separate web service or data feed for analysis. Fields missing from VEM go to the Ministry as a request, and you wait for the next VEM version. So if what you need is already in VEM, start there: the regulation already provides for that access, which makes it the easiest thing to ask for.

Of the four options, a documented API is the best to build on, if the vendor has one. For non-clinical data that isn't in VEM, a scheduled file every hour or every night is often enough, and it keeps the HBYS vendor's share of the work small. Whatever you get, ask for the code tables, a test dataset with realistic volume, and the name of the person to call when a feed stops.

Permission and work come from different places. The hospital decides what may be shared; the HBYS vendor, as processor, does the technical work. Expect a data processing agreement with the hospital and a separate statement of work with the vendor.

Where scheduling fits: what we learned with Oplist

Oplist builds fair, rule-compliant rosters for hospital departments. It's used at 5–10 locations and has produced schedules for more than 2,000 people. The engine is an optimization model for the nurse rostering problem, solved with a MILP solver in Python; there is no machine learning in it. We have been its engineering team since November 2023 and moved it from Flutter Web and Flask to React and Node.js.

Oplist's integrations are mostly with hospitals' HR and payroll systems. That follows from what a roster needs: who works in which department, with what title and contract, and when they are on leave. Payroll, in turn, needs to know what was actually worked, including nights and on-call duty. None of this needs a diagnosis, a test result or a patient's name, so the integration can stay clear of clinical data entirely. We wrote about the product side in hospital shift scheduling with Oplist.

Keep health data out on purpose

Leave records are where health data slips in. A sick-leave entry backed by a medical report is health data under KVKK. A scheduler only needs to know that a person is unavailable between two times, so translate each leave type into availability at the boundary and leave the reason in the HR system. If you can, match people on the HR system's employee number rather than the national ID number. A stable key is all the matching needs.

Time and data integrity are the hard part

The hardest part of the Oplist migration was time and data integrity, and hospital rosters make both difficult. A 24-hour on-call shift starts on one calendar day and ends on the next, payroll has to decide which day those hours belong to, and managers change approved rosters after the fact. What we recommend for any rota integration:

• Store every shift as start and end timestamps with a time zone, never as a date plus a label like "night".
• Treat an approved roster as a version. A change creates a new version, so payroll can see what moved since it last read the data.
• Agree on one staff identifier across HR, payroll and the scheduler, and reject records that don't match instead of guessing.
• After each exchange, compare totals on both sides: people, shifts and hours.

For the wider HR side, see our post on HR software development.

If you need clinical data

That is a different kind of project, and we haven't done one, so read this as the checklist we would start from rather than a report from the field:

1. List the exact fields you need and the KVKK ground for each.
2. Find out whether your product counts as an SBYS and needs KTS registration.
3. Plan hosting inside Turkey from the first day.
4. Get the HBYS vendor's interface documentation, test environment and SKRS code tables, and check which of your fields exist in VEM, before you estimate anything.
5. Log every access to patient data (who, which record, when) and keep the logs at least as long as Article 17 requires.
6. Put the vendor's work and price in writing, and sign data processing terms with the hospital.

Frequently asked questions

Do Turkish hospitals support HL7 FHIR?

Don't assume it. Interfaces vary by vendor, and the one read path the regulation requires every HBYS to have is the Ministry's VEM data model, exposed as database views, which isn't FHIR. Ask for the vendor's documentation and a test environment before you design anything.

Can Turkish hospital data be hosted in an EU or US cloud?

Health data held in an SBYS can't. Article 16 of the regulation keeps it inside Turkey, in the facility's own systems, the Ministry's, or environments the Ministry approves. Other personal data, such as staff records, can leave Turkey only under KVKK Article 9.

What is e-Nabız?

The national personal health record. It is part of USS, which collects data from hospitals' systems, and patients use it to see their records and to decide which doctors and relatives can see them.

Does a foreign software vendor need to register with the Ministry of Health?

If the software is an SBYS used in Turkish health facilities, the vendor must be registered in KTS. That means sending the documents listed on the KTS site, signing a confidentiality agreement with the Ministry and passing an audit of the software before it goes on the active list (Article 6). Since July 2026 the regulation itself no longer asks for ISO 27001 or SPICE/CMMI certificates. Check whether your product fits one of the registered types, and ask the hospital how it treats products like yours.

If you're planning a hospital integration in Turkey on the HR, payroll or scheduling side, our backend and API team can look at it with you.