Every clinical AI project has a moment where the interesting work stops and the real work starts. The model is validated, the interface is designed, the clinicians are willing — and then someone asks how it will read the patient's medication list out of the HBYS.
That question has ended more healthcare AI projects than any accuracy metric ever has.
What the HBYS actually is
The hospital information system (HBYS in Türkiye) is the system of record: admissions, orders, results, encounters, billing. It is usually old, usually customised per institution, and usually the single source of truth that everything else has to agree with.
Two properties make it hard to work with, and both are worth respecting rather than resenting.
It is critical. If the HBYS is slow, the hospital is slow. Nobody will let a pilot project add load to it during clinic hours, and they are right not to.
It is particular. "HBYS" is a category, not a product. Two hospitals running the same vendor's software will have different order codes, different department structures, and different local conventions inside the same standard fields.
HL7 v2, FHIR, and which one you will actually get
Standards discussions in healthcare integration tend to be aspirational. The deployed reality in most Turkish hospitals is this:
- HL7 v2 messaging is what exists today — ADT feeds for admissions and transfers, ORM for orders, ORU for results. It is pipe-delimited, it is quirky, and it works.
- FHIR is where things are heading, and increasingly what new modules expose.
Patient,Encounter,Observation,DiagnosticReportcover most of what clinical AI needs. - Direct database access is what someone will eventually offer you when the interface engine is backlogged. Decline it. Reading a vendor's schema directly makes you responsible for their next migration, and it bypasses every access control the institution has.
The realistic answer is usually both: consume the HL7 v2 feed that already exists, expose your own surface as FHIR, and let the integration engine translate.
The details that cost you months
Patient identity. Merges happen. Two records become one, and every downstream system needs to cope. If your AI stores its own patient key without honouring merge messages, your results will eventually attach to the wrong person.
Local codes. The order code for a chest X-ray is not a universal constant. Expect a mapping table between local codes and whatever vocabulary you standardised on, expect it to be wrong initially, and build it so a hospital IT team can fix it without a deployment.
Free text. A great deal of Turkish clinical documentation lives in free-text fields with local abbreviations and inconsistent diacritics. Any pipeline that assumes clean structured input will meet reality quickly.
Test environments. Ask for one on day one. A project that can only be tested against production will be tested rarely, late, and nervously.
The integration layer is not plumbing you route around. In healthcare software it is most of the product.
Design for the institution you are actually in
The systems that get deployed share a shape. They read from the feeds the hospital already emits rather than demanding new ones. They keep mappings in configuration rather than in code. They degrade gracefully when the HBYS is unreachable, because it will be. They log every read and write, because someone will eventually ask. And they run where the institution's data governance says they must — which, for most hospitals we work with, means on-premise.
None of this is the part of a healthcare AI company that looks impressive in a pitch deck. It is, reliably, the part that determines whether anything reaches a patient.