What Should Be Considered When Choosing HBYS? 500 Critical Control Items

Choosing an HBYS is a strategic decision that directly affects not only the hospital's IT infrastructure but also patient admission, clinical processes, SGK/Medula, billing, inventory, pharmacy, laboratory, radiology, quality, finance, reporting, and management decisions. Therefore, the selection process should not be limited to demo observation, price comparison, or reference hospital information.

A good HBYS should accelerate the hospital's daily operations, reduce revenue loss, prevent user errors, ensure regulatory compliance, support patient safety, and provide accurate data to management.

The following 500 items constitute a comprehensive control list that should be evaluated in terms of technical, clinical, financial, administrative, integration, security, and sustainability aspects. It can be prioritized and used according to your institution's needs.

1. Company Qualifications and Institutional Reliability

• It should be checked whether the HBYS manufacturer is registered in the Ministry of Health Registration System.
• The types of SBYS software the company is registered with should be examined.
• The product offered by the company must be operational, not in the development stage.
• There should be active references of the product in the field.
• The company should not only be a sales entity but also have a structure that develops products.
• The company's technical support team should be evaluated separately.
• The company's experience in the healthcare sector should be questioned.
• The company's experience with private hospitals, public hospitals, or group hospitals should be examined.
• The company's financial sustainability should be assessed.
• The financial structure of the last three years should be analyzed.
• The company should be evaluated for risks such as bankruptcy, transfer, or partnership changes.
• The company's product roadmap should be requested.
• The company's R&D capacity should be questioned.
• The size of the company's software development team should be learned.
• The location and working hours of the company's support team should be examined.
• The intervention time of the company in critical error situations should be documented.
• The SLA commitments specified in the contract should be clear.
• Reference hospitals of the company should be contacted directly.
• Live usage experience should be observed in reference hospitals.
• The company should be tested not in a demo environment but in a real scenario.

2. Documents, Regulations, and Registration

• The ISO/IEC 27001 Information Security Management System certificate should be requested.
• The validity date of the ISO 27001 certificate should be checked.
• The accreditation of the issuing organization should be verified.
• If there is a SPICE or CMMI certificate, its level should be examined.
• A software registration certificate should be requested.
• The company's trade registry records should be checked.
• The company's SGK workplace registration information should be requested.
• The company's personnel information and authorized persons should be clarified.
• A confidentiality agreement should be signed.
• KVKK obligations should be clearly stated in the contract.
• Data processor/data controller roles should be defined.
• Commitments regarding the processing of health data should be obtained.
• Compliance with Ministry of Health standards should be questioned.
• Compliance with SKRS and USVS should be checked.
• Compliance with e-Nabız submissions should be questioned.
• Health-Net data sets should be supported.
• Medula integration suitability should be examined.
• e-Prescription and e-Report processes should be supported.
• MHRS integration capability should be evaluated.
• The compliance period for regulatory changes should be written in the contract.

3. Product Scope and Modular Architecture

• HBYS should be modular.
• Modules should not operate independently.
• All modules should use common patient data.
• All modules should use common personnel data.
• All modules should use a common institution and branch structure.
• The system should support a multi-branch hospital structure.
• The system should support group hospital management.
• There should be centralized parameter management.
• There should be centralized authority management.
• There should be a centralized logging infrastructure.
• Clinical, financial, and administrative modules should work together.
• End-to-end flow from patient admission to billing should be supported.
• Request flow from outpatient clinics to laboratories should be supported.
• Request flow from outpatient clinics to radiology should be supported.
• Medication requests from inpatients to the pharmacy should be supported.
• The operating room should be integrated with the inventory system.
• Emergency service and billing processes should be integrated.
• Data duplication between modules should not be allowed.
• Each module should have a separate authority matrix.
• Modules should be configurable to be opened and closed.

4. Patient Registration and Patient Card

• The patient registration screen should open quickly.
• Patient search performance should be high.
• Patients should be able to be queried by their TC identification number.
• Patients should be able to be registered with their passport number.
• Scenarios for foreign patient registration should be supported.
• The newborn patient registration process should be supported.
• Mother-baby relationships should be established.
• Information about patient relatives should be recorded.
• Accompanying person information should be tracked.
• Guardian information should be managed.
• Patient contact information should be verified.
• Duplicate checks should be performed on mobile numbers.
• Email information should be verified.
• Address information should be kept in a standard format.
• City, district, and country codes should come from reference tables.
• Patient photos should be able to be added.
• Special notes for patients should be kept with access control.
• Patient confidentiality status should be marked.
• VIP patient management should be supported.
• There should be a blacklist or warning mechanism for patients.

5. KVKK, Consent, and Patient Permissions

• Explicit consent records should be kept in the system.
• Approval of the information text should be obtained.
• Communication consent should be managed separately.
• SMS consent should be tracked separately.
• Email consent should be tracked separately.
• Phone call consent should be kept separately.
• KVKK consent history should be stored.
• Consent cancellation should be tracked historically.
• Patient data masking should be possible.
• Unauthorized users should not be able to see sensitive information.
• Access to patient files should be logged.
• Confidential patient records should require special permissions.
• Data export permissions should be restricted.
• Excel export permissions should be granted separately.
• PDF output permissions should be granted separately.
• Patient data should not be deleted but deactivated.
• There should be a cancellation/correction mechanism instead of deletion.
• Scenarios for anonymizing patient data should be supported.
• KVKK reports should be obtainable.
• Data access requests should be recorded.

6. Application, Protocol, and Admission Management

• Protocol opening should be done quickly.
• Outpatient applications should be supported.
• Inpatient applications should be supported.
• Emergency applications should be supported.
• Day patient applications should be supported.
• Dental applications should be supported.
• The institution type should be able to determine the application.
• SGK applications should be separated.
• Paid patient applications should be separated.
• Private insurance applications should be separated.
• Applications from contracted institutions should be supported.
• Applications from foreign patients should be supported.
• Tourist health applications should be supported.
• Occupational accident applications should be supported.
• Judicial case applications should be supported.
• Traffic accident applications should be supported.
• There should be management for institution-referred patients.
• Selection of specialty, doctor, and department should be easy.
• Patient status should be monitored on the protocol.
• Protocol history should be easily viewable.

7. Appointment Management

• Doctor-based appointment management should be available.
• Department-based appointment management should be available.
• Device-based appointment management should be supported.
• Room-based appointment management should be supported.
• Operating room appointment scheduling should be supported.
• Endoscopy appointments should be supported.
• Radiology appointments should be supported.
• Special test appointments for the laboratory should be supported.
• FTR session appointments should be supported.
• Dialysis session appointments should be supported.
• Doctor work schedules should be definable.
• Doctor leaves should reflect in appointments.
• On-call schedules should be integrated into appointments.
• Appointment cancellation reasons should be recorded.
• Appointment rescheduling history should be kept.
• No-show patients should be tracked.
• Appointment reminder SMS should be sent.
• Mobile notifications should be supported.
• Online appointment infrastructure should be available.
• MHRS integration should be supported.

8. Outpatient Clinic and Physician Screen

• The physician screen should be simple and fast.
• The physician should easily view the patient list.
• The examination queue should be manageable.
• A patient calling system should be supported.
• Anamnesis records should be able to be made.
• Complaint records should be able to be made.
• Physical examination records should be able to be made.
• Personal history information should be viewable.
• Family history information should be viewable.
• Allergy information should be visible.
• Chronic disease information should be visible.
• Medications used should be viewable.
• Previous examinations should open easily.
• Previous tests should be easily trackable.
• Previous radiology reports should be accessible.
• ICD-10 diagnosis search should be fast.
• Frequently used diagnoses should be recordable.
• Specialty-specific examination templates should be available.
• Ready texts should be supported.
• The physician screen should not contain unnecessary clicks.

9. Order and Request Management

• Laboratory requests should be made from the physician screen.
• Radiology requests should be made from the physician screen.
• Pathology requests should be supported.
• Consultation requests should be supported.
• Medication orders should be able to be placed.
• Supply material orders should be able to be placed.
• Diet requests should be able to be made.
• Blood product requests should be able to be made.
• FTR requests should be able to be made.
• Surgery requests should be able to be made.
• Order sets should be definable.
• Specialty-specific order sets should be available.
• Order suggestions should be made according to diagnosis.
• Order cancellation reasons should be recorded.
• Order application status should be monitored.
• Nurses should be able to see order applications.
• The financial counterpart of requests should be generated automatically.
• The billing impact of requests should be monitored.
• Unnecessary request alerts should be present.
• An approval mechanism should be available for critical orders.

10. Emergency Service

• Emergency service triage management should be available.
• Triage color codes should be supported.
• Triage changes should be logged.
• The method of arrival should be recorded.
• 112 ambulance arrivals should be separated.
• Judicial case management should be supported.
• Traffic accident processes should be supported.
• Alcohol examination records should be able to be kept.
• Emergency observation process should be managed.
• Emergency bed status should be monitored.
• Emergency order screen should be fast.
• Emergency nurse monitoring screen should be available.
• Emergency consultation process should be supported.
• Green area examinations should be managed.
• Green area billing rules should be supported.
• Emergency patient LCD calling system should be supported.
• Emergency waiting times should be reported.
• Emergency density analysis should be possible.
• Emergency service performance reports should be obtained.
• Emergency records should be stored in compliance with regulations.

11. Inpatient and Service Management

• Admission decisions should be made from outpatient or emergency.
• Room and bed availability should be viewable.
• Bed occupancy rates should be monitored.
• Service transfers should be possible.
• Room changes should be recorded.
• Accompanying person management should be supported.
• Inpatient orders should be monitored.
• A nursing application plan should be available.
• Vital signs should be recorded.
• A care plan should be created.
• Fall risk assessments should be possible.
• Pressure ulcer assessments should be supported.
• Pain scales should be recordable.
• Patient education forms should be available.
• Discharge planning should be created.
• Epicrisis should be prepared.
• Referral processes should be managed.
• Exitus process should be managed.
• Length of stay should be reported.
• Bed turnover rates should be analyzed.

12. Nursing Processes

• A nurse patient list should be available.
• Nurses should be able to see the order list.
• Medication administration times should be tracked.
• Reasons for not administering medications should be recorded.
• Vital monitoring screens should be fast.
• Care plans should be standardized.
• Risk assessment forms should be available.
• Nurse observation notes should be kept.
• Patient education records should be maintained.
• Isolation information should be visible.
• Blood transfusion monitoring forms should be available.
• IV line monitoring forms should be available.
• Catheter monitoring forms should be supported.
• Fluid balance monitoring should be possible.
• Nutrition monitoring should be possible.
• Wound photos should be able to be added.
• Mobile nurse screens should be supported.
• Patient verification via barcode should be possible.
• Medication verification via barcode should be possible.
• Nursing records should be time-stamped.

13. Operating Room Management

• Surgical requests should be made electronically.
• There should be a surgical approval process.
• Operating room layout should be viewable.
• Room occupancy rates should be monitored.
• Clinics should be able to allocate rooms.
• Surgeon information should be recorded.
• Anesthesia doctor information should be recorded.
• Nursing team information should be recorded.
• Anesthesia types should be selectable.
• Start and end times of the surgery should be recorded.
• Entry and exit times for the room should be kept.
• Recovery room processes should be supported.
• Surgical notes should be able to be written.
• A safe surgical checklist should be available.
• Materials used should be recorded on the patient.
• Implant and serial number tracking should be done.
• Surgical package pricing should be supported.
• Reasons for surgery postponement should be recorded.
• Operating room statistics should be obtained.
• Operating room costs should be calculated.

14. Intensive Care

• Intensive care bed management should be available.
• Monitor data should be integrable.
• Ventilator data should be obtainable.
• Scoring systems should be supported.
• APACHE score should be supported.
• SOFA score should be supported.
• Glasgow coma scale should be supported.
• Fluid balance monitoring should be robust.
• Blood gas results should be easily trackable.
• Intensive care orders should be managed.
• Medication infusion monitoring should be done.
• Isolation and infection information should be visible.
• Nurse monitoring forms should be available.
• A physician daily evaluation screen should be available.
• Intensive care epicrisis should be prepared.
• Device integration logs should be maintained.
• Critical value alerts should be given.
• Patient transfers should be recorded.
• Intensive care occupancy reports should be obtained.
• Intensive care costs should be monitored.

15. Laboratory Information Management

• Laboratory requests should be taken electronically.
• Sample barcodes should be printable.
• Sample collection times should be recorded.
• Sample acceptance times should be recorded.
• Sample rejection reasons should be able to be entered.
• Device operational status should be monitored.
• Result written status should be monitored.
• Result approved status should be monitored.
• Result reported status should be monitored.
• Panic value definitions should be able to be made.
• Panic value notifications should be logged.
• Reference ranges should vary by age.
• Reference ranges should vary by gender.
• Reference ranges should vary by clinic.
• Previous reference ranges should be stored.
• External laboratory integration should be available.
• Laboratory device integrations should be supported.
• Results should automatically drop to the physician screen.
• Laboratory performance reports should be obtained.
• Laboratory income and cost analysis should be possible.

16. Radiology and PACS

• Radiology requests should be made electronically.
• There should be a radiology appointment schedule.
• Modality-based worklists should be available.
• Emergency radiology requests should be separated.
• Inpatient requests should be separated.
• DICOM integration should be supported.
• HL7 integration should be supported.
• PACS connection should be robust.
• Image and report relationships should be established.
• Radiologist worklists should be available.
• Report templates should be definable.
• There should be a report approval process.
• Approved reports should not be changeable.
• There should be a report addition mechanism.
• e-Signature should be supported.
• Repeat imaging should be monitored.
• Patients who do not show up for appointments should be reported.
• Device-based imaging counts should be obtained.
• Radiology income analysis should be conducted.
• Radiology waiting times should be reported.

17. Pharmacy and Medication Management

• Medication definition cards should be available.
• Active ingredient information should be maintained.
• ATC codes should be supported.
• Medication barcode information should be maintained.
• QR code tracking should be done.
• ITS integration should be supported.
• Service medication requests should be possible.
• Patient-based medication exits should be possible.
• Medication returns should be managed.
• Expiry date tracking should be done.
• Critical medication stock alerts should be available.
• Cold chain products should be monitored.
• Narcotic medication tracking should be done.
• High-risk medication alerts should be present.
• Allergy-drug interaction alerts should be available.
• Dose control mechanisms should be available.
• Pharmacy inventory counts should be possible.
• Pharmacy stock transfers should be supported.
• Medication costs should be tracked on a patient basis.
• Pharmacy reports should be obtainable.

18. Stock, Warehouse, and Purchasing

• Material cards should be detailed.
• Warehouse definitions should be possible.
• Shelf definitions should be possible.
• Lot tracking should be done.
• Serial number tracking should be done.
• Expiry date tracking should be done.
• Stock movements should be done via barcode.
• Inter-warehouse transfers should be supported.
• Stock counts should be possible.
• Minimum stock alerts should be present.
• Maximum stock levels should be defined.
• Automatic purchase requests should be able to be generated.
• The purchasing request process should be available.
• The quotation collection process should be supported.
• Order management should be available.
• Goods acceptance processes should be supported.
• Delivery note registration should be done.
• Supplier management should be available.
• Patient-based consumable tracking should be monitored.
• Stock costs should be integrated with finance.

19. Service, Pricing, and Package Management

• Service cards should be managed centrally.
• SUT codes should be matched with services.
• TTB codes should be supported.
• Special service lists should be definable.
• Institution-based price lists should be created.
• Pricing based on patient groups should be supported.
• SGK prices should be managed separately.
• Paid patient prices should be managed separately.
• Private insurance prices should be managed separately.
• Foreign patient prices should be managed separately.
• Contracted institution prices should be supported.
• Package service definitions should be possible.
• Surgical package definitions should be possible.
• Check-up package definitions should be possible.
• Rules for services within packages should be definable.
• Services outside packages should be separated.
• Discount groups should be definable.
• Campaign prices should be supported.
• Historical prices should be stored.
• Price increase analyses should be possible.

20. SGK, Medula, and Billing

• Medula provision should be obtainable.
• Medula tracking should be able to be created.
• Medula service records should be able to be made.
• Medula prescription processes should be supported.
• Medula reporting processes should be supported.
• Medula billing processes should be managed.
• Medula error messages should be displayed understandably.
• Incorrect follow-ups should be listed.
• Missing document alerts should be given.
• SUT rule checks should be performed.
• Additional fee checks should be performed.
• Participation fees should be calculated.
• Package transaction rules should be applied.
• SGK deduction risks should be shown in advance.
• There should be a pre-billing control screen.
• Bulk billing creation should be supported.
• Institutional invoices should be manageable.
• Invoice cancellation and return processes should be available.
• Invoice reconciliation reports should be obtained.
• Deduction analysis reports should be created.

21. Cashier, Collection, and Finance

• Cash collection should be supported.
• Credit card collection should be supported.
• POS integration should be available.
• Installment payments should be supported.
• Advance collections should be possible.
• Deposit management should be available.
• Refund processes should be possible.
• Cash register opening and closing processes should be available.
• Cashier-based reports should be obtainable.
• End-of-day reports should be obtained.
• Patient debt balances should be monitored.
• Institutional receivables should be tracked.
• Private insurance receivables should be tracked.
• Current account integration should be available.
• Accounting vouchers should be able to be created.
• e-Invoice should be supported.
• e-Archive should be supported.
• e-Delivery note should be supported.
• Income reports should be obtainable.
• Profitability analysis should be possible.

22. Reporting, BI, and Decision Support

• An executive dashboard screen should be available.
• Daily patient numbers should be monitored.
• Outpatient application numbers should be monitored.
• Emergency application numbers should be monitored.
• Inpatient numbers should be monitored.
• Bed occupancy rates should be reported.
• Bed turnover rates should be calculated.
• Average length of stay should be calculated.
• Doctor performance should be reported.
• Specialty-based revenue reports should be obtained.
• Institution-based revenue reports should be obtained.
• Service-based income reports should be obtained.
• Patient-based profitability analysis should be conducted.
• Package profitability analysis should be conducted.
• Invoice waiting time reports should be generated.
• Medula error reports should be obtained.
• Laboratory performance reports should be obtained.
• Radiology performance reports should be obtained.
• Stock consumption reports should be obtained.
• Management reports should be accessible via mobile.

23. Security, Authorization, and Audit Trail

• Role-based authorization management should be available.
• User-based authorization should be possible.
• Branch-based authorization should be possible.
• Department-based authorization should be possible.
• Patient group-based authorization should be possible.
• Screen-based authorization management should be available.
• Button-based authorization management should be available.
• Report-based authorization management should be available.
• Data export permissions should be granted separately.
• Access to patient files should be logged.
• Critical data changes should be logged.
• Old and new values should be stored.
• Deletion processes should be restricted.
• Cancellation processes should be justified.
• User sessions should be monitored.
• Password policy should be strong.
• Two-factor authentication should be supported.
• LDAP/Active Directory integration should be available.
• Unauthorized access alerts should be present.
• Audit reports should be obtainable.

24. Technical Architecture, Performance, and Integration

• The system should have a scalable architecture.
• It should work under heavy load with multiple users.
• Critical screens should open quickly.
• Patient search performance should be high.
• Outpatient lists should load quickly.
• Billing screens should not slow down.
• Reports should not lock the live system.
• Database design should be robust.
• Unnecessary duplicate tables should be reduced.
• Reference tables should be managed centrally.
• API infrastructure should be available.
• Integrations should be done with an adapter logic.
• A queue system should be used.
• A retry mechanism should be available.
• An integration error panel should be present.
• HL7 should be supported.
• DICOM should be supported.
• REST API should be supported.
• Web service documentation should be available.
• Versioning management should be available.

25. Sustainability, Support, and Future Vision

• The product should be regularly updated.
• Updates should be tested in a staging environment.
• A return plan should be available.
• Release notes should be shared.
• User training should be provided.
• Training documents should be up to date.
• Video training content should be available.
• On-site support plans should be made.
• Remote support infrastructure should be available.
• A call recording system should be available.
• Support requests should be tracked with SLA.
• Critical issues should be prioritized.
• User satisfaction should be measured.
• Rapid compliance with new regulations should be ensured.
• Easy onboarding should be facilitated for new hospital openings.
• Data migration tools should be available.
• A transition plan from the old HBYS should be prepared.
• It should be open to AI-supported controls and analyses.
• Mobile use and remote access should be supported.
• HBYS should be designed to meet not only the current but also the digital transformation needs of the hospital for the next 5-10 years.

Conclusion

Choosing an HBYS is one of the most critical digital transformation decisions for hospital management. A well-chosen HBYS increases patient safety, enhances user satisfaction, reduces revenue losses, secures SGK/Medula processes, and provides accurate decision data to management.

Therefore, HBYS evaluation should not be based solely on price, demo, or reference. The product should be examined multidimensionally in terms of regulatory compliance, integration capacity, clinical workflows, financial accuracy, data security, performance, reporting, and sustainability.

You can adapt this checklist to your institution or check our HBYS Consulting page for an independent evaluation, or you can create a consultation request.