In summary<\/p>\n
- \n
- In a clinic, stopped IT is a full waiting room.<\/strong> Fault tolerance is much lower than in an office.<\/li>\n
- Health data are a special category under the GDPR<\/strong> \u2014 require above-normal controls.<\/li>\n
- O clinical software conditions all decisions<\/strong> of infrastructure, and must be consulted before any change.<\/li>\n
- Network-connected medical equipment needs segmentation<\/strong>, not to share network with the administrative posts.<\/li>\n<\/ul>\n<\/div>\n
\nIn this article<\/p>\n
- \n
- What distinguishes a clinic<\/a><\/li>\n
- Clinical software rules<\/a><\/li>\n
- Network and medical equipment<\/a><\/li>\n
- Health data protection<\/a><\/li>\n
- Business continuity and backups<\/a><\/li>\n<\/ol>\n<\/div>\n
A clinic is not an office with white coats. The IT requirements of a healthcare facility \u2014 even a small one \u2014 differ in three ways that change everything: tolerance for downtime, data sensitivity, and the presence of equipment that is not IT equipment yet relies on the network.<\/p>\n
What distinguishes a clinic<\/h2>\n
In an office, a system down for an hour is a setback. In a clinic, it's a full waiting room, delayed appointments and a domino effect that drags on through the rest of the day \u2014 not to mention what it means for those waiting.<\/p>\n
Added to this is an operational detail: the peak usage is predictable and concentrated. If the system slows down at nine in the morning, it slows down precisely when all consultations begin.<\/p>\n
And there is the regulatory dimension. Clinical records are health data, and the GDPR treats them as a special category \u2014 with requirements above those that apply to ordinary data.<\/p>\n
![\"Person](\"https:\/\/www.redes-informatica.pt\/wp-content\/uploads\/2026\/08\/6346532cv19d-768x500.jpg\")
In a clinical setting, the workstation must be available by the time of the appointment \u2014 not afterwards.<\/figcaption><\/figure>\n Clinical software rules<\/h2>\n
This is the rule that prevents most failed projects: infrastructure is designed around the clinical software, and not the other way around<\/strong>.<\/p>\n
Clinical management, imaging and health subsystem billing systems have their own requirements, which are often rigid and not always well documented. Before deciding on servers, cloud or workstations, there are questions to ask the software vendor:<\/p>\n
- \n
- Which configurations are effectively supported? Working is not the same as being supported.<\/li>\n
- How does it behave with the server outside the local network?<\/li>\n
- What requirements are there for backup and restore?<\/li>\n
- What external connections does it require \u2014 subsystems, laboratories, portals?<\/li>\n<\/ul>\n\n
Confirm in writing before migrating.<\/strong> Many clinical applications were designed for local networks and perform unacceptably poorly in the cloud. Finding this out after migration is expensive and forces you to roll back the operational clinic.<\/p>\n<\/div>\n
Network and medical equipment<\/h2>\n
A typical clinic has far more than computers on its network: imaging equipment, analysers, call systems, label printers, payment terminals and, increasingly, connected devices that no-one has classified as IT equipment.<\/p>\n
Two principles organise this well.<\/p>\n
Segmentation.<\/strong> Medical equipment on a network separate from administrative workstations and the patient network. Many of these devices run legacy systems that cannot be updated for certification reasons \u2014 isolating them is the only realistic protection.<\/p>\n
Wireless coverage designed for the building.<\/strong> Concrete walls, shielded rooms and the need for access in all offices make it coverage study<\/a> more important than in other contexts. And the patient network must be completely isolated from the clinical network.<\/p>\n
All of this is based on certified structured cabling<\/a> \u2014 in a clinic, an intermittent connection in an office is not a nuisance, it is an interrupted consultation.<\/p>\n
Health data protection<\/h2>\n
Without entering into legal territory, there are controls that any healthcare facility must have implemented:<\/p>\n
- \n
- Nominal accounts<\/strong> for each professional. Shared accounts make it impossible to know who accessed what \u2014 and that traceability is required.<\/li>\n
- Least privilege access.<\/strong> Not everyone needs to see all the processes.<\/li>\n
- Access log<\/strong> to clinical data, kept and consultable.<\/li>\n
- Encryption<\/strong> of data at rest and in transit, including laptops and backups.<\/li>\n
- Two-step verification<\/strong> for remote access, without exceptions.<\/li>\n
- Subcontracting agreements<\/strong> with all suppliers that may access data, including the IT supplier.<\/li>\n<\/ul>\n
And a defined data breach procedure, with clear notification deadlines before you need to use them.<\/p>\n
Business continuity and backups<\/h2>\n
The question to answer before sizing anything whatsoever: what happens to the clinic if the system is down for two hours on a Monday morning?<\/strong><\/p>\n
If the answer is unacceptable \u2014 and it usually is \u2014 then the infrastructure needs proper redundancy: backup power, a second internet connection from a different operator, and a recovery capability in hours rather than days.<\/p>\n
As backups<\/a> at a clinic there are also two specific requirements: an off-site or air-gapped copy that survives ransomware, and restoration tests actually carried out<\/strong>. An unrestored backup does not protect clinical records \u2014 it only gives the feeling that it does.<\/p>\n
- Least privilege access.<\/strong> Not everyone needs to see all the processes.<\/li>\n
- Nominal accounts<\/strong> for each professional. Shared accounts make it impossible to know who accessed what \u2014 and that traceability is required.<\/li>\n
- Clinical software rules<\/a><\/li>\n
- Health data are a special category under the GDPR<\/strong> \u2014 require above-normal controls.<\/li>\n