We do not build diagnostic imaging software; your existing PACS stays where it is. What we build is the layer that closes the gap between the device worklist, the patient record, the order, the report and sharing: the image is linked to the right patient, pending orders become visible, and the retention and backup status of the archive becomes auditable.
In almost every centre that carries out imaging, the same scene repeats itself. The scan is taken on the device, the image lands in PACS, but which order that image belongs to and what state its report is in are tracked somewhere else entirely. Because the patient details are typed into the device by hand, a single wrong letter produces two separate records; the examination order arrives by telephone or on paper; images are still handed to the patient on a CD, and that CD gets lost. Nobody can tell you the number of pending reports at any given moment, because that information is not in PACS but in the radiologist's head. The problem is not the image itself; more often than not the image is stored perfectly well. The problem is that the chain around the image — appointment, order, report, delivery and sharing — is not digitally connected. In small centres this gap is closed by the attentiveness of the staff; as patient numbers rise, attentiveness is not enough, and this is exactly where work is lost.
PACS does what its name says: it is a picture archiving and communication system. It takes the DICOM images the devices produce, stores them and shows them to authorised users. It generally does this job well, and it is not a system that needs moving. But PACS is not a business application. It does not know whether an appointment has been given, who raised the order, how many hours a report has been waiting, which examination has gone unbilled, or how a patient can reach their own images securely from outside. In most centres that information is scattered across the hospital information system, a spreadsheet and people's memories. Between the device and the administrative process there remains a gap that nobody quite owns. The subject of this page is precisely the layer that closes that gap.
It is worth saying at the outset what we do not do. Pan Innovation House does not build diagnostic imaging software. Software that takes measurements on an image, marks findings, contributes to a diagnosis or steers a clinician's decision falls under medical device legislation; in Türkiye the Medical Device Regulation (Tıbbi Cihaz Yönetmeliği) and in Europe the MDR (Medical Device Regulation) govern such products and require clinical evaluation and a conformity process. We do not enter this field, and we would advise you to treat any proposal that claims to do so with caution. Where we work is the administrative and operational chain after the image has been produced: raising the order, getting the right patient to the device, linking the image to the right record, tracking the report, recording every act of sharing and managing the archive in line with the retention rule. This boundary is put in writing at the very start of the project.
The way we work is to sit on top of the existing installation. Whatever product your PACS is, it stays in place; we speak to it over standard interfaces such as DICOM and, where required, DICOMweb and HL7. On the device side, once the modality worklist — the work list — is fed, typing the patient details into the device by hand disappears; that single step cuts out a significant share of mismatches at source. The layer we build for image access, sharing, report tracking and archive monitoring is software that belongs to you: the source code is yours, and you decide where the data sits. Nor do we set the scope in one go; we start with the step that wastes the most time and produces the most errors, and extend it as results appear. Because health data is involved, permissions, access logging and retention are part of the design from day one.
Centres running X-ray, ultrasound, CT and MRI devices together. The real difficulty here is not the archive but the inability to track the order-scan-report chain. Making the number of pending reports, repeat scans and wrong patient matches visible produces a measurable gain even before anything else is done.
Institutions with several imaging devices of different makes, running the hospital information system and PACS separately from one another. An order raised in the information system never reaching the device, an examination performed but not billed, and reports tracked by hand are the three most common points of loss in these set-ups.
Clinics that talk to their patients through images. Requesting images from a patient abroad before treatment, sharing the treatment plan with visuals, and doing so through a logged, time-limited and authorised channel rather than a CD or random file links is a matter of both speed and trust in these institutions.
Set-ups where the scan is taken at one branch and the report is written by a clinician somewhere else. When you cannot track which clinician the image went to, when it was handed over and how many hours it has been waiting, you cannot commit to a turnaround time; what is really needed is for that handover chain to be put on record.
When an appointment or an order is created, the patient and examination details are sent to the device over the DICOM Modality Worklist. The technician does not type a name at the device; they select from the list. Duplicate records caused by typing errors, blank patient numbers and wrong examination codes are thereby largely eliminated. If a device does not support worklist, we say so plainly at discovery.
Whether the incoming studies match the right patient and the right order is checked continuously. Records that do not match, or that look suspicious, drop into a correction queue; who made the correction, when and on what grounds is put on record. Cleaning up mismatches created in the past runs through the same flow.
For every examination, the steps and elapsed times from raising the order to approving the report are tracked. The pending report list, the workload spread by clinician and delay alerts are visible at a glance. A separate flagging and follow-up flow can be defined for priority situations such as critical finding notification; the system does not interfere with the content of the finding, it only tracks the flow.
The image and the report are opened to the patient, the referring clinician or a contracted institution over a time-limited, authorised link. Who accessed what and when is put on record. The burden of burning CDs and handing them over in person falls away; sharing methods where nobody knows where the file went are replaced by a traceable channel.
Archive capacity, the growth rate, the state of the second copy and studies whose retention period has expired are tracked on a dashboard. What matters is not that a backup was taken but that it can be restored; reminders and records are therefore kept for periodic restore tests. Deletion and de-archiving are carried out on a rule basis and on the record.
The existing hospital information system or clinic software stays where it is; appointment, order and report information flows both ways over HL7 v2 or an API. The aim is to end the entry of the same information into two systems separately. Whether integration is possible depends on the interface support of the other system and is clarified at discovery.
Health data is special category personal data. Which role may view which patient's images, what approval is required for sharing outside, and how long the records are kept are all defined. Viewing, downloading and sharing actions are written to the audit log, so that a retrospective answer can be given should an investigation arise.
Which devices are in place, which PACS is in use, where orders are raised and how reports are delivered: all of it is mapped on site. The DICOM conformance statements of the devices are reviewed. This step usually takes two to four weeks, and it is here that the real scope of the project is set.
A test environment is set up without touching the live system; worklist, image transfer and HL7 messaging are tried against the actual devices and systems. What works and what does not is put in writing. Skip this step and the problems surface in the live environment, with patients present.
The work list feed is switched on and manual entry at the device is removed. Match checking and the correction queue are opened. We start with a single device or a single examination group; once the result is visible, it is rolled out to the other devices.
Pending report tracking, time-limited sharing links and permission rules are switched on. A pilot is run with a limited team; the old method continues in parallel for a while. Throughout the pilot we measure which step genuinely saves time and simplify the flow accordingly.
The retention, backup and capacity monitoring dashboards are switched on. Handover to the team takes place; procedures such as correcting a mismatch, revoking a share and adding a new device are left in writing. After that, monitoring continues within the scope of maintenance and support.
No. Your installed PACS stays where it is and the image archive carries on living there. The layer we build does not replace it; it connects the workflow around it. That is why we work independently of brand; the only condition is that the PACS supports standard DICOM interfaces, which is true for the great majority of the systems in use today. Suitability is verified at discovery from the DICOM conformance statements of the devices.
No, that is outside our scope. Software that detects findings on an image, takes measurements or contributes to a clinician's diagnosis counts as a medical device; in Türkiye under the Medical Device Regulation and in Europe under the MDR, it requires clinical evaluation and a conformity process. We do not run that process and we do not pretend to. If you have such a need, the right route is to procure a certified product that complies with the legislation and to have us build the integration.
Most modern devices support DICOM Modality Worklist, but on some older devices the feature is either absent or licensed as an add-on module. At discovery we look at each device's conformance statement and write down one by one which of them can receive a worklist. On devices that do not support it, interim solutions such as barcode-based patient selection or controlled matching after the scan are put in place. We do not claim at the outset that all of them will connect automatically.
Health data is special category personal data, and the institution is obliged to establish the legal basis for sharing it. What we do is build the technical infrastructure that makes that basis workable: role-based permissions, links that expire, download and viewing logs, and the immediate revocation of access where needed. The legal assessment and the consent texts are prepared with the institution's own legal support; we do not write those texts, we fit the system to them.
It will not. The hospital information system manages the patient record, the appointment and the financial process; PACS stores the image. Our layer builds the transition between the two and takes on the steps nobody owns. We do not rewrite the existing system, we connect to it over HL7 or an API. For the broader administrative layer we build on the same logic, see our hospital and clinic information system side layer page.
A work list feed to the devices; match checking between the image and the patient record, together with a correction queue; time-based tracking of the order and report flow; a time-limited, logged sharing channel; an archive, retention and backup monitoring dashboard; an access and action audit log. The source code, the database and the documentation belong to you; you can continue with another team whenever you wish.
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 build student information systems that bring admissions, enrolment, class placement, timetabling, attendance registers, marks, report cards, parent communication and instalment tracking together on a single record. It is designed around your institution's own calendar and your own fee policy; you do not have to fit into the mould of an off-the-shelf package. The source code and the data belong to the institution.
Details →We build laboratory information management systems that run every step on a single record, from the moment a sample is received through to the certificate of analysis: barcoded sample tracking, a method library, instrument connections, specification checks, staged approval and an audit-ready record structure.
Details →We bring the chain of quote, project, time record, milestone claim and invoice together on a single record. In agencies, consultancies, engineering practices and software firms, who spent how long on which job, resource utilisation and project profitability become visible while the work is still running, not once it has finished.
Details →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.
Details →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 →
