Infrastructure, Continuity and Data Protection for Dental and Medical Practices
A dental or medical practice runs on a set of systems that were rarely designed as a whole: practice-management software, imaging, a server or NAS, an internet line, the telephone, the payment terminal, and a backup that someone configured once.
When one of them stops, the day stops. Patients are waiting, the schedule is full, and the practice cannot simply pause for two days.
VODIS works on the environment around care — infrastructure, data, continuity and process. Not the clinical act.
The reality of a modern practice
Even a small practice now operates what is, in effect, a small critical IT estate — and usually without anyone whose job is to run it.
- practice-management software holding the patient record, schedule and billing
- imaging and intraoral acquisition, with their own workstations and storage
- a server or NAS that everything depends on
- connectivity carrying billing, secure exchanges and telephony
- payment terminals, printers, scanners, accounting interfaces
- remote access for the software vendor and for out-of-hours work
Nobody planned this as an architecture. It accumulated.
From patient journey to operating model
Technology only helps if the underlying process is clear. We follow the real journey — appointment, arrival, administrative verification, treatment, documents, payment, follow-up — and the internal flows around it: reception workflows, practitioner–assistant coordination, document handling, traceability, inventory, suppliers, equipment lifecycle and recurring controls.
The output is an operating model where each step has an owner, a system of record and a defined handover — described as process and information flow. Clinical protocol remains the practice’s own domain.
Single points of failure — where a practice actually stops
Before designing anything, it is worth knowing what the day rests on. A single point of failure is any component whose loss stops the practice, with no designed alternative:
- one internet line, one provider, one router, one switch
- one server, one NAS, one workstation no other machine can stand in for
- primary data and its backup living on the same physical system
- a backup reachable from the same environment a ransomware infection would own
- one power source, no UPS
- one privileged account, or an administrator password everybody shares
- vendor remote access left permanently open
- configuration nobody wrote down, and one person who knows how it all works
Not everything needs to be duplicated. We identify the critical dependencies, assess what their loss actually costs, agree how long the practice can tolerate being without each one — and then introduce resilience proportionate to that answer. A second independent fibre line may be the right answer in one practice; automatic 4G/5G failover may be entirely sufficient in another.
Connectivity, continuity and tested failover
A practice that cannot reach its systems cannot bill, transmit or, in many setups, consult a record.
- a primary fibre connection, and a genuinely independent second path where it is justified
- 4G/5G failover where a second fixed line is impractical or disproportionate
- automatic WAN failover, so the switch does not depend on someone noticing
- router/firewall, managed switches and a Wi-Fi design that separates what should be separate
- a defined behaviour when the primary provider fails
And then the part that is usually skipped: the failover is tested — both the switch away and the return — and the result is written down.
Protecting patient data and critical systems
Health data deserves the treatment its sensitivity implies.
- network segmentation separating clinical workstations, servers, imaging and equipment, VoIP, administration, staff Wi-Fi, guest Wi-Fi and connected devices — proportionate to the practice, not maximal for its own sake
- accounts that belong to people, least privilege, and no shared logins
- multi-factor authentication on remote access
- controlled, logged vendor remote support instead of a permanently open door
- patching, endpoint protection, monitoring, logging and an asset inventory
- a register of processing activities, and documentation that lets the practice show what it does
Two points of the French framework are worth stating precisely, because both are widely misunderstood.
On secure exchanges. The obligation is to secure exchanges of personal health data — not to use one particular service. MSSanté is the established French secure-messaging ecosystem for health exchanges and is the practical route for most practices, but its use is not itself universally mandatory; what matters is that the service actually used meets the obligations that fall on the practice.
On hosting. HDS certification is required of a provider that hosts health data, operates the health information system, or performs backups on a practice’s behalf — the obligation follows the act of hosting for someone else. A practice hosting its own data on its own premises is not itself required to be HDS-certified. That does not reduce its responsibilities by one step: the security and data-protection duties, the register, and the obligation to be able to demonstrate compliance apply exactly the same. The distinction simply decides which parts of an architecture need a certified provider and which do not.
Since the GDPR the CNIL requires no declaration of files, but a practice must be able to demonstrate its compliance at any time. The CNIL’s référentiel for private practices is the natural reference point, and it recommends encrypting disks and backup media. VODIS designs and documents the environment; legal interpretation stays with the practice’s own advisers.
Backup and recovery — and proving it works
A backup is only useful if it can actually be restored. Most practices discover the difference at the worst moment.
- a local copy for fast restore
- a second, independent copy
- an off-site or cloud copy where appropriate
- at least one copy that ransomware cannot reach — immutable or genuinely offline, where proportionate
- application- and database-aware backup, not just file copying
- retention that matches how the practice actually works
- monitoring, because a backup that has been failing silently is worse than none
- UPS and graceful shutdown, so a power cut does not corrupt a database
- a disaster-recovery document a stressed person can follow
And then: restore testing on a schedule, with the result written down. Server and NAS recovery tested, the shutdown behaviour tested, the recovery procedure walked through, and the whole set revisited periodically as the practice changes. Design, implement, test, document, re-test.
Applications, equipment and French digital-health workflows
Around the practice-management software sits an ecosystem that has to interoperate: patient records, appointments, billing and SESAM-Vitale workflows, document management, prescriptions, imaging and intraoral scanners, telephony, payment terminals, accounting interfaces and secure remote access.
The French digital-health framework adds specific requirements. Referencing health data with a qualified INS has been obligatory since January 2021, which in turn requires identity validation and an INSi lookup. Mon espace santé is to be fed systematically unless the informed patient objects for a legitimate reason. Digital prescription is a legal framework that covers dentists, with the national rollout still in progress and its timetable set nationally — worth planning for, not worth hard-dating. Ségur-referenced software is the practical route to these capabilities, and it conditions the associated funding where applicable and depending on the current programme and eligibility conditions.
We do not publish these systems. We make sure the practice’s environment can actually support them — identity, software selection, integration, network, and the workflow around them.
AI and automation, practical and governed
The realistic near-term value in a practice is administrative, not clinical.
- drafting and processing routine administrative correspondence
- document handling and internal knowledge lookup
- appointment and no-show analysis
- operational reporting and simple analytics
- workflow automation, inventory and recurring-task support
- staff training and process improvement
This only works with governance: patient data must not be pasted into public generative tools, “shadow AI” needs a usable policy rather than a ban nobody follows, data minimisation applies, access is controlled, and a human stays accountable for anything that reaches a patient or a record. Where clinical AI is involved it arrives as a regulated medical device through the vendor, with its own obligations — VODIS does not provide diagnosis, treatment decisions, clinical validation or device certification.
Growing, moving or modernising a practice
The moments where this pays back are the ones where everything changes at once: renovating, adding chairs or rooms, relocating, opening a second site, bringing in practitioners or staff, integrating another practice, replacing the practice-management software, refreshing the server and network, moving selected services to the cloud, or integrating new equipment.
VODIS can run that arc — assess → architect → select → plan → implement → migrate → secure → test → document → train → operate and improve — as much or as little of it as the practice needs.
How VODIS works, and what an engagement can produce
An independent transformation and technology partner: not a dentist, not a clinical consultancy, not a device manufacturer, not a software vendor, not a regulator or certification body, and not a substitute for legal advice.
What that independence buys is straightforward — advice on architecture and vendor selection that is not tied to a product, and someone who can hold a programme together between the software publisher, the equipment supplier, the telecom/network provider and the practice itself.
Depending on scope, an engagement can produce:
- a current-state assessment of infrastructure, data flows, single points of failure and risk
- a target architecture for network, server and continuity
- a backup and disaster-recovery design with a tested restore procedure
- a security and access model
- an operating-model and process review
- a technology roadmap with sequencing and dependencies
- vendor-selection criteria and support
- migration and implementation planning
- documentation the practice actually owns — network diagram, asset inventory, access model, backup design, recovery procedure, vendor and contact dependencies
- training and adoption support
These are possible outputs, not guarantees. What a given engagement achieves depends on scope, the existing environment and the practice’s starting point.