How cloud patient tracking differs from a desktop program
Cloud patient tracking software is not an application installed on your computer but a service you reach from a browser and a mobile app. You do not buy a server, you do not have to remember backups, and you do not call anyone in for updates. The sections below explain what this difference really means for a clinic.

A desktop program and a cloud program side by side
The decision is often reduced to which one is more modern, but the real matter is who carries the daily chores. The table below sets the two approaches side by side on ten points.
| Topic | Desktop program | Cloud-based (HekimBis) |
|---|---|---|
| Installation | Installed on every computer, plus a server computer | Nothing to install; a browser is enough |
| Access | From the computer in the clinic | From a browser and the mobile app, by permission |
| Backup | The user's responsibility | Automatic, run by the system |
| Updates | By hand, sometimes with a service visit | Central, with no action from the user |
| Several users and branches | Needs a network and server setup | Ready with role and branch permissions |
| Security patches | Tied to each user's computer | Central and continuous |
| Device data | Local record and file transfer | A local bridge that stores data during outages and resends it |
| Failure | Data at risk if the computer breaks | Independent of any device; restore from backup |
| Cost structure | License, hardware and service | Subscription; hardware is the clinic's own devices |
| Data ownership and exit | The file is yours, but moving it can be hard | Authorized full export is the same in every package |
Installation
- Desktop program
- Installed on every computer, plus a server computer
- Cloud-based (HekimBis)
- Nothing to install; a browser is enough
Access
- Desktop program
- From the computer in the clinic
- Cloud-based (HekimBis)
- From a browser and the mobile app, by permission
Backup
- Desktop program
- The user's responsibility
- Cloud-based (HekimBis)
- Automatic, run by the system
Updates
- Desktop program
- By hand, sometimes with a service visit
- Cloud-based (HekimBis)
- Central, with no action from the user
Several users and branches
- Desktop program
- Needs a network and server setup
- Cloud-based (HekimBis)
- Ready with role and branch permissions
Security patches
- Desktop program
- Tied to each user's computer
- Cloud-based (HekimBis)
- Central and continuous
Device data
- Desktop program
- Local record and file transfer
- Cloud-based (HekimBis)
- A local bridge that stores data during outages and resends it
Failure
- Desktop program
- Data at risk if the computer breaks
- Cloud-based (HekimBis)
- Independent of any device; restore from backup
Cost structure
- Desktop program
- License, hardware and service
- Cloud-based (HekimBis)
- Subscription; hardware is the clinic's own devices
Data ownership and exit
- Desktop program
- The file is yours, but moving it can be hard
- Cloud-based (HekimBis)
- Authorized full export is the same in every package
Desktop programs have strengths too: they do not depend on an internet connection, and they can be simple for a practice with one computer. As soon as backup, security patches, remote access, a second user and a second branch come in, that simplicity fades. The counterpart of a cloud solution is the internet connection, and how that connection is managed is explained below.
When you compare cost, do not stop at the purchase price. The cost of a desktop program also builds up in the server computer, the backup disk, backup maintenance, patches and service visits, and the working hours lost when a computer breaks. A subscription cost is known from the start and covers most of these. Make the comparison over at least a two-year period.
Where the data sits and who can reach it
The word cloud can hide the real question for health data: where exactly is your data, and who can see it? In HekimBis, health data in the production environment is hosted in Türkiye. Sending data abroad requires a separate legal regime and transfer conditions; for that reason even sub-services that do not touch health data are not connected without a separate data flow and risk decision. The hosting approach is described on the Technology page.
Who can reach it matters even more. The checklist is as follows.

- Role-based accessEach user sees only the screen and record their role needs. See Roles and permissions.
- Care relationship and branch boundaryThe clinical record of another branch opens only through membership and a duty relationship.
- Audit trailSensitive reads, writes, downloads and exports are recorded.
- No permanent super-administratorHekimBis staff access to your data is granted temporarily and traceably, with a ticket number, a reason, customer approval, a narrow scope, a time limit, masking, multi-factor verification and revocability.
- Emergency access with a reasonEmergency access by staff without a care relationship needs a reason and a time limit and leaves a separate audit record.
- No sensitive data in logsPatient content is not carried into general logs, monitoring or analytics tools.
See Security and KVKK-compliant patient tracking for details.
What happens if the internet drops
The most frequent question about cloud systems is an internet outage. The question has two separate parts: access to the screen and device data.
On the screen side, a physician can use a narrow flow offline in the mobile app, encrypted and for a limited time; when the connection returns it syncs, and if there is a conflict nothing is merged silently and the physician decides. A backup mobile line is the most practical precaution for a clinic.
On the device side, no data should be lost. A message from an X-ray, ultrasound, laboratory device or PACS reaches the Edge Connector on the clinic's local network. The bridge writes it to an encrypted local queue and opens only outbound connections; no inbound connection to the clinic is opened. If the internet is down, data is kept in the queue, and disk quota and alarms are monitored. When the connection returns, packages are sent in order, and resending creates no copies. Data whose patient identity does not match is quarantined and checked by a person. A warning is given before the bridge's certificate expires. See Edge Connector and Device connections for device and bridge details.
The question to ask when deciding is whether depending on the internet or managing your own backup and security is the riskier choice. For most clinics the second is the bigger risk, because an internet outage is temporary and a lost patient file is not. For clinics that need constantly high availability, a second internet line and a mobile connection are a normal part of working in the cloud.
In a clinic with an internet connection, two small habits make things easier: at the start of the day the connection and mobile app sign-in are tested together, and when the connection drops during the day the physician switches to the mobile offline flow and the front desk follows the patient list from the previous day's printout. These habits often turn an outage into an event that goes unnoticed.

Linked to the order and the patient record
- The process is complete here.
All steps
- 01 Device message received (Device / PACS / LIS)
- 02 Written to a local encrypted queue (Edge Connector)
- 03 Sent over an outbound-only connection (Edge Connector)
- 04 Cloud accepts (duplicate guard, integrity check) (Cloud)
- 05 Linked to the order and the patient record (Clinic screen)
Alternative path from 03 Sent over an outbound-only connection; it returns to the main flow at 04 Cloud accepts (duplicate guard, integrity check).
- 03a Internet down: stored in the queue, an alarm is raised (Edge Connector)
- 03b Connection back: ordered replay, no duplicates (Edge Connector)
Alternative path from 04 Cloud accepts (duplicate guard, integrity check); it returns to the main flow at 05 Linked to the order and the patient record.
- 04a Identity mismatch: quarantine, human review (Cloud)
05 Linked to the order and the patient record
Backup, restore and updates
Backup is part of the security baseline and is the same in every package.
Automatic backup
Backup does not depend on the user remembering; the system takes regular backups and stores them encrypted. The location and frequency of backups are written in the contract and security documents.
Restore
Recovering a record or all data is an operational procedure. As protection against accidental deletion, patient records are not deleted in a way that is hard to recover; a record is archived. Signed records do not change silently.
Secure export
An authorized user can export their data. Closing an account or downgrading a package does not delete data; at the end of the contract a data handover and deletion process is defined.
Data stays in the clinic's hands: the combination of backup, restore and export means the data is not held hostage. See Security.
The value of a backup is measured by whether it can be restored. In HekimBis backups are archived encrypted, it is possible to return to a specific point in time, and restore is tested regularly with a real drill. Not only taking a backup but proving that it works is part of the security baseline.
Release and update management follows the same principle. New features and security patches arrive centrally, without asking anything of the user. The plan definition is versioned; a published plan version is not changed silently for an existing customer, and changes are announced with a date and approval. Your clinic's manager sees maintenance notices and service status, and the corporate system status page shows this information publicly. See Technology.
Moving from a desktop program to the cloud
Moving from a desktop program to the cloud has three fears: data loss, duplicate records and work stopping. The data migration is built to answer all three.
The source file, meaning CSV, Excel or an export from the old program, first passes through a field-mapping preview. A trial import follows, and an error report is produced. If the same patient appears in several places, you make the matching decision. The import can be run again without creating copies. At the end, counts, totals, a sample and file integrity are reconciled, and records carry their source trail.
The seven-day trial workspace runs on sample data; the real move happens in the production environment after organization verification, the contract and payment. You do not have to close the old program at once; running both in parallel for a few weeks is a common choice. See Data migration and How it works for details.
Access security needs separate thought in a cloud system, because the system can be reached from anywhere. That is why multi-factor verification, session and trusted-device management, biometric sign-in on mobile and remote sign-out matter. When an employee leaves, access closes immediately and their past actions stay in the audit trail. On the patient side, portal access opens with identity verification and notifications carry no health information. Shared links are time-limited, single-use and logged; these controls exist to offer ease of access without giving up security.
Frequently asked questions
Is cloud patient tracking software secure?
Security comes less from being in the cloud or on the desktop than from controls: role-based access, an audit trail, encryption, isolated support access and backup. The details are on the Security page. A desktop program left without backup and patches can be riskier.
Is my data kept in Türkiye?
Health data in the production environment is hosted in Türkiye. Hosting information is on the Technology page.
How do I work when the internet drops?
A physician can use a narrow flow offline in the mobile app, encrypted and for a limited time. Device data is stored in the local bridge and sent without loss when the connection returns.
Is web-based patient tracking the same as cloud?
Usually yes: a system reached from a browser and run on servers operated by the vendor. HekimBis adds a mobile app and a local device bridge on top of it.
What happens to my data if I stop using the program?
Authorized full export is the same in every package; at the end of the contract a data handover and deletion process applies. Downgrading a package does not delete data.
Is the mobile app a separate program?
No. The mobile app connects to the same account and the same data; the physician's daily diary, patient summary and note drafts work on the phone too. Sign-in is protected by multi-factor verification and a biometric lock.
Can it be used across several branches?
Yes. Branches connect to the same system; role and branch permissions come ready, and the clinical record of another branch opens only through membership and a duty relationship. No separate server or network setup is needed.
Are installation and training needed?
No installation is needed. Role-based training paths and an expectations guide are part of onboarding. See How it works.
Related pages
Features
Specialties
Solutions and process
Software guides
- Patient tracking softwareWhat patient tracking software is, what it tracks, and how it works in HekimBis.
- KVKK-compliant patient softwarePrivacy notices, consent, role-based access, audit trail, and data subject requests.
- Medical tourism CRMMultilingual leads, agency and interpreter roles, currency quotes, reconciliation.
