We do not replace your hospital information management system; we build an operations layer that runs alongside it. Appointments and resource utilisation, treatment plan tracking, reminders, consumable and implant stock, the patient journey in health tourism and the management dashboard all come together in this layer. The source code and the data stay with you.
In a hospital, or in a healthcare organisation with several units, patient records are already held in a system. The hospital information management system (HBYS) was built for admissions, medical records, billing and submitting data to public institutions, and it does those jobs. The gap usually opens up not on the clinical side but on the operations side: managing appointments and resource utilisation, following up treatment plans left unfinished, bringing the patient back, matching consumable and implant costs to the procedure, making productivity visible by unit and by clinician. In most organisations these are either never measured at all, or they run in individual Excel files, dependent on the effort of particular people. The main system is not defective for failing to do them; these jobs fall outside what it was designed for.
Once this gap is noticed, the first solution that comes to mind is usually the wrong one: replacing the existing system entirely. Yet the main patient record system carries the organisation's historical data, its billing structure and its obligations to submit data to external institutions; replacing it is both a major risk and, in most organisations, no solution to the real problem. At Pan Innovation House we do not write the HBYS itself. Main systems such as Akgün, Probel and Monad stay where they are; we build an operations layer that works alongside them. We state this boundary at the outset, because the most common disappointment in this field surfaces halfway through a project whose scope was stretched as far as the main system.
The second boundary is the regulated areas. Provision and invoicing transactions through Medula (the Turkish social security health claims system), data submission to e-Nabız (the national personal health record) and the MHRS (central physician appointment system) booking flow are subject to an authorisation regime; they are not areas any piece of software may connect to freely. For that reason we recommend that these transactions stay in your existing system, and we position the layer we build around them rather than in their place. We research what is possible at the start of the project, specific to your organisation and your current vendor, and we tell you in writing. We do not make promises based on guesswork, because here a promise that cannot be kept means not just a project delay but a real problem on the billing and regulatory side. The same cautious approach applies to diagnosis and clinical decisions: this layer does not produce medical decisions and does not stand in for the clinician's judgement.
What remains is a wide area, and it determines the organisation's operating performance directly. The layer we build reads the data it needs from the main system, holds the data it produces on its own side, and matches the two at patient record level. The connection method is determined by what your vendor permits: HL7 messaging, a FHIR interface, read-only database access or regular file transfer. Honesty is needed here: the timeline of these projects usually depends not on us but on how quickly your existing vendor responds on integration. We mark that in the plan as a separate dependency; we do not reduce it to a single date and promise it. If integration turns out to be impossible altogether, we would rather narrow the scope than build a project on a connection that does not exist.
Organisations running several outpatient clinics, operating theatres and imaging units. At this scale the main system handles records and billing, but capacity across units, where patient flow gets stuck and productivity by unit are usually not measured. The overview management needs is pieced together by hand from the main system's standard reports.
Businesses running several sites in fields such as dentistry, ophthalmology, aesthetics, physiotherapy or dialysis. The real problem is that sites cannot be compared: which site has low appointment utilisation, which clinician has a high rate of unfinished treatments, which site's consumable usage per procedure is out of line. For the sector-specific account, see our clinic software page.
Hospitals and clinics accepting patients from abroad. In this model the patient journey stretches from first contact to the flight, and from treatment to the follow-up period, and it is usually split across several people and channels. When nobody measures at which stage the patient was lost, or which channel genuinely pays once cancellations are deducted, the marketing budget is spread blind.
Organisations that are not satisfied with their existing patient record system but do not want to take on the risk of replacing it. In that case the right move is not to rip the system out but to build the missing operations side alongside it. Appointments, follow-up, stock and reporting are put right without taking on migration risk, and the decision on replacing the main system can then be made later on firmer ground.
The connection method is chosen according to what your existing vendor makes possible: HL7 messaging, a FHIR interface, read-only database access or regular file transfer. Patient, appointment and procedure records are matched to the identity held in the main system, so two separate patient records do not build up on the two sides. Writing back to the main system happens only where the vendor explicitly permits it; otherwise the layer only reads, and keeps its own data on its own side.
An appointment is planned not around the clinician alone but together with every resource involved: room, chair, device and support staff, so clashing resource use is prevented. Utilisation is measured by unit, by clinician and by time of day. The no-show rate is tracked separately, because most lost utilisation comes not from empty slots but from appointments that were filled and not attended.
In multi-session treatments the system automatically tracks which stage the plan has reached, which session is running late and which patient has dropped out of the process. Patients with no next step scheduled within a defined period are put in front of you as a list. That list both raises the treatment completion rate and makes visible the revenue that was planned but never realised.
Appointment reminders, recall calls and post-treatment follow-up messages are sent from the organisation's own channel according to defined rules. Every message sent and every reply received is logged to the patient record. The aim is not automation alone; moving communication off personal phones and into the organisation's records keeps follow-up from breaking when staff change, and stops health data accumulating on personal devices.
The consumables and implants used are tied to the procedure and to the patient by barcode; serial, lot and expiry date stay on record. In the event of a recall, which lot was used on which patient can be queried. The same record also produces the procedure cost: once you can see what a procedure actually costs, pricing and contract negotiations rest on your own data.
First contact, quotation, travel and accommodation plan, treatment and post-treatment follow-up all run on a single record, and the stage at which contact was lost is measured. For patients arriving through intermediaries and digital channels, the net contribution of the channel is calculated after deducting commission, cancellations and no-shows. The channel that sends the most patients is often not the channel that earns the most.
Health data is special-category personal data; access is defined by role and at record level, who accessed which record and when is written to the audit trail, and retention periods are set. The management dashboard runs on top of this permission structure: utilisation, completion rates, productivity by unit and clinician, consumable usage and channel contribution are gathered on a single screen.
The subject of the first meeting is not a feature list but the boundary: which areas are regulated and untouchable, and which are open. What your main patient record system does, and what it does not do, is set out. We do not quote before that distinction is clear, because in this sector the cost of scope ambiguity is heavier than in others.
A technical discussion is held with your existing vendor; which connection method is possible, and which data can be obtained at what frequency, are put in writing. This step usually takes 2-4 weeks, and its duration depends on the other party rather than on us. If the connection turns out to be limited, we narrow the scope accordingly; we do not build a plan on an integration that does not exist.
We start with a single unit or site rather than the whole organisation; appointment utilisation, reminders and unfinished treatment tracking are usually the three that deliver results fastest. The system is developed in short stages, with a working piece shown at each stage. Keeping the scope narrow is the most reliable way to get results in healthcare organisations.
The new layer is run alongside the existing arrangement for a period; the figures on both sides are compared and records that do not match are examined one by one. Access permissions and the audit trail are tested separately. With health data this test is not skipped; a permissions error is not a detail to be corrected after go-live.
The other units and sites are added in turn and the management dashboard is opened up. User training is delivered; source code, database and handover documentation are provided. A written definition of access permissions and retention rules is part of that package too. Maintenance and further development then run under a separate agreement whose scope is written down in advance.
No. We do not write the hospital information management system itself; main systems such as Akgün, Probel and Monad stay where they are. The layer we build works alongside them and takes on the operations side: appointments and capacity, treatment plan tracking, reminders, consumable and implant management, reporting. We set this boundary at the outset. For the sector-specific account of the same work at clinic and outpatient scale, see our clinic software page; this page describes the relationship with the main system and the integration layer.
These interfaces are subject to an authorisation regime and are not areas any piece of software may connect to freely. For that reason we recommend that provision, invoice submission and the public appointment flow stay in your existing system. We research what is possible at the start of the project, specific to your organisation and your current vendor, and share the outcome in writing. We do not make promises based on guesswork on this subject; a promise that cannot be kept means not just a delay but a real problem on the billing side.
We plan for that possibility from the start. Some vendors are open to integration, some are reluctant, and with some the technical scope is limited. If a connection is not possible, two routes remain: obtaining the data regularly through export files, or narrowing the scope to areas that do not require data from the main system. If neither is possible we say so plainly and do not force the project through. A plan built on an integration that does not exist is the most expensive disappointment in this field.
No. Diagnosis, clinical decision support and medical image interpretation are outside the scope of this layer; those areas are subject to medical device regulation and are a separate specialism. The system we build does not enter into the clinician's decision, it manages operational processes. If you have a need on the imaging side, the work we do is integration with your existing PACS and the workflow around it; we treat that as a separate topic.
Preferably on your own servers, or in an environment under your own control. Because health data is special-category personal data, the architecture is built accordingly: role-based access, record-level permissions, an audit trail of who accessed which record and when, defined retention periods and regular backups. Legal assessment is your legal adviser's area; we build the technical counterpart of those decisions and produce the evidence to be shown in an audit.
An integration with your main system whose method has been documented in writing; resource-based appointment and utilisation management; treatment plans and unfinished-course lists; reminders and patient communication logged to the organisation's records; barcoded consumable, implant and lot tracking with procedure cost; a health tourism journey and channel contribution report; a management dashboard running on top of the permission and audit trail structure. The source code, the database and the documentation are yours.
In a 30-minute discovery call we listen to what you need and tell you honestly whether custom development or an off-the-shelf product is the better answer.
We take the company's paperwork out of folders and personal computers and move it into a single archive. Every document's version, who may see it, which approval it passed through and how long it will be kept are defined in the system; the document you are looking for is found in seconds rather than minutes, and its history can be evidenced in an audit. A DMS manages the document itself; ECM covers the process and the content that flow with it.
Details →We build a system that produces a contract from a template, puts it through approval and signature, and — once it is signed — tracks effectivity, renewal, the notice period for termination and the parties' commitments. Contract lifecycle management (CLM) is exactly that: not storing a file, but managing the contract's lifetime. A contract whose term has run out does not quietly extend itself because nobody noticed.
Details →We build an arrangement in which faults and requests arrive through a single record rather than through a messaging app, a corridor conversation or a phone call. Every request is prioritised, has a clear owner and a measured resolution time. We run the same structure not only in IT but also for human resources, administrative affairs and maintenance requests. That is what enterprise service management (ESM) means.
Details →Who is using which computer, phone, server and network device, which licence expires when, which subscription quietly renews itself: we gather all of it into a single record system. Assignment, warranty, the renewal calendar and decommissioning run in the same system; the inventory moves out of personal memory and into the organisation's records.
Details →We tie risks to their owners and place a control, and the evidence for that control, against each risk. Policies run under version control, audit findings are tracked to a deadline, and a regulatory change lands with the right person. Work on personal data, occupational safety and the environment is read from a single dashboard under the same roof.
Details →We break projects down into a work breakdown structure, make resources and capacity visible, and put budget and actuals side by side. Milestones, risks and decisions sit in the same record; management reads the whole portfolio from a single dashboard and discusses which work comes first by looking at data.
Details →
