Choosing software for a practice or clinic usually begins with one question: will the program run on my computer, or over the internet? The answer shapes daily use, the backup routine, data security and the cost of moving years later. This article explains what cloud-based healthcare software really means, which problems it solves, and which questions it should answer before you buy.
What does "cloud-based" mean?
In a cloud-based patient management system, the application and the data do not sit on your computer. They live on infrastructure run by the software provider. You sign in from a browser or a phone. Installation, version updates, backups and infrastructure maintenance are the provider's responsibility. With desktop software, the application is installed on a computer in your clinic, and the data stays on that computer's disk or on a server in the clinic. Updates, backups and hardware failures are your job.
The difference between the two is not "modern versus old." It is a difference in who carries the responsibility. In a desktop setup you hold the control, and you also hold the entire burden. In the cloud the burden moves to the provider, and in return you have to choose the provider carefully. So the right question is not "cloud or desktop," but "which guarantees can I ask this provider to put in writing?"
The concrete gains of the cloud
No installation or maintenance burden. When you buy a new computer or open a second consulting room, you do not install anything. You sign in with your account. Version updates arrive without your involvement, and changes driven by regulation reach everyone at the same time.
Backup stops being a habit you must remember. On a desktop system, a backup is often something taken "when remembered" and written to an external disk in the same room. A fire, a theft, ransomware or a disk failure can take the data and the backup together. In the cloud, backup is continuous and part of the system. What matters is to ask whether restoring from backup is actually rehearsed on a regular basis.
Access from anywhere, on any device. A physician checking tomorrow's agenda from home, a multi-branch operation where the head office sees every branch calendar, or a doctor reviewing a critical result on a phone all come naturally in the cloud. This access is bound to permissions. "Access from anywhere" does not mean everyone sees everything.
Scale and team growth. When a one-physician practice adds a second doctor or a second branch, a desktop setup may force you to rebuild the server, the network and the licensing. In a cloud setup the same account simply grows, and existing data does not move. For how plan changes work, see the approach described on the pricing page.
The hard questions to ask
The advantages of the cloud are real only when the following questions get clear answers.
Where is the data kept?
Health data is special-category personal data under Türkiye's Personal Data Protection Law (KVKK). The country and conditions under which data is stored must be written into the contract. Ask the provider for three things: the country where production data is held, the country where backups are held, and the list of subprocessors that can touch health data. At HekimBis, production health data is kept in Türkiye, and this rule is handled at the contract and operations level. For details, see the security page.
Who can access which data?
Can the provider's support team see patient records? If so, under what condition, for how long, with whose approval, and with what trace left behind? In a well-built setup, support access is not permanently open. It is granted on request, for a limited time, and recorded. The same question applies inside your clinic: should the front-desk employee see a patient's diagnosis? The role and permission structure is described on the roles and permissions page.
What happens if the internet goes down?
This is the strongest and fairest objection to the cloud. The answer has two parts. The first is clinical continuity: how will you reach the appointment book and patient records when the connection drops? A common answer is a backup line (a second connection or phone tethering) and a short paper procedure. If the product offers a limited offline flow, its limits should be written down. The second is device data: the diagnostic devices in your clinic keep producing measurements when the internet is down. The device connection must hold that data locally and safely and deliver it when the connection returns. In HekimBis this is handled by the Edge Connector: device messages inside the clinic are placed in an encrypted local queue and delivered to the cloud in order once the connection is back.
Orders, images and results
Accepted data is linked to the right patient and order and appears on the clinic screen.
- The process is complete here.
- Message 1With sequence and checksumQueued
- Message 2With sequence and checksumQueued
Names, times and records on the screen are examples.
All steps
- 01 Pairing (Edge Connector) The setup wizard pairs the Edge Connector with the branch; the branch, connector and device each receive their own identity.
- 02 Connection test (Edge Connector) The connection to the device is tested (such as C-ECHO); the device health turns green.
- 03 Device message (Device / PACS / LIS) The device sends a result or image; the Edge Connector receives it.
- 04 Local encrypted queue (Edge Connector) The message is written to the encrypted local queue with a sequence number and checksum.
- 05 One-way outbound connection (Edge Connector) The connector connects to the cloud from the inside out, encrypted, and sends from the queue. The connection is always opened from the clinic outward.
- 06 Cloud acceptance (HekimBis cloud) The cloud verifies the message by checksum and sequence, prevents duplicates (idempotent) and accepts it.
- 07 Orders, images and results (Clinic screen) Accepted data is linked to the right patient and order and appears on the clinic screen.
Alternative path from 05 One-way outbound connection; it returns to the main flow at 06 Cloud acceptance.
- 05a Internet down: store and forward (Edge Connector) There is no connection. Data stays in the local queue (within the disk quota); an alarm is raised and the clinic screen shows a clear warning.
- 05b Connection back: replay (Edge Connector) The queue is drained in order; the cloud blocks duplicate records. No data is lost.
Alternative path from 06 Cloud acceptance; the process ends on this path.
- 06a Mismatched identity: quarantine (HekimBis cloud) The patient, order or specimen identity does not match. The record goes to quarantine and an authorized user decides; no automatic matching.
Alternative path from 01 Pairing; it returns to the main flow at 02 Connection test.
- 01a Certificate expired (Edge Connector) The connector certificate nears or reaches expiry; a rotation warning is raised and the connection is tested again after renewal.
07 Orders, images and results
Has restoring from backup been tested?
"We take backups" is not enough. Ask how often a restore drill is performed, how long a restore takes, and whether there is a control that prevents deleted or access-revoked data from reappearing after a restore. The answers summarize the provider's maturity.
Can you leave?
The ability to leave a software product is the least discussed selection criterion. At the end of the contract you should be able to export your records and files (images, documents) in a reasonable form, without fee pressure. Data not being held hostage is one of HekimBis's core principles. When a plan is downgraded, data is not deleted; only the capacity for new use changes.
Desktop versus cloud: comparison table
| Topic | Desktop / local server | Cloud-based |
|---|---|---|
| Installation | Install on each computer | Sign in from a browser |
| Updates | Your responsibility | Provider does it, for everyone at once |
| Backup | Manual or scheduled, often in the same place | Continuous, kept separately; ask about restore tests |
| Remote access | Extra setup and security risk | Permission-based, natural |
| Internet outage | Keeps working | Connection needed; plan limits and a backup line |
| Multiple branches | A server and network project | Add a branch in the same account |
| Hardware failure | Data-loss risk is yours | Infrastructure is the provider's |
| Ongoing cost | Looks low, hidden maintenance burden | Subscription; scope must be clear |
This table does not declare either approach superior. In a rural practice with a weak connection and a single computer, a local setup can make sense. For a two-physician clinic, a doctor who checks the agenda from home, or a business that wants to connect diagnostic devices to a central record, the cloud approach usually brings less operational burden.
How do you move from a desktop program?
The technical difficulty of a move is usually smaller than users expect; the difficulty of data quality is bigger. A healthy migration follows this order:
- Identify the export format of the old program (table files, backup, database output).
- Map the fields to the new system and preview them.
- Run a trial import without touching real records; list the errors in a report.
- Resolve duplicate patient records, using human approval instead of automatic merging.
- Run the real import and compare counts, totals and sample records against the old system.
In HekimBis this flow is described in the data migration feature: a trial import first, then an error report, then the real import and reconciliation. Keeping the old program read-only until the migration is confirmed is recommended.
Ten questions before you decide
When you talk to a cloud provider, tie these questions to written answers:
- In which country is production health data kept? The backups?
- Who are the subprocessors that can touch health data?
- Can the support team access patient records, and under what condition and for how long?
- How often are restore drills performed?
- What is recommended for an internet outage, and is device data protected?
- How is data exported at the end of the contract, and is there a fee?
- What happens to data when a plan is downgraded?
- Who updates the product for regulatory changes (national data submission, privacy notices), and by when?
- Are commitment periods, withdrawal and cancellation terms clear in the contract?
- Can I run the trial without real patient data?
The last question matters. At HekimBis the seven-day trial works only with synthetic data, and real patient data is not accepted at that stage. This lets you test the software with your team in a realistic day without putting personal data at risk. The starting process is described step by step on the how it works page.
Conclusion
Cloud-based healthcare software lightens a clinic's infrastructure burden and adapts to team growth, but that gain depends on the provider making firm commitments on data location, access, backup and exit. When choosing, look at these questions before the features on the showcase. For a more detailed comparison with desktop programs, the cloud-based patient tracking page includes a comparison table and an outage scenario. For the general framework, read the patient tracking software guide.
