Synchronising patient records across a rural veterinary group
Four veterinary clinics in a rural county share one cloud practice-management system hosted in Manchester. Each clinic has 5–6 staff and sees about 120 animals a week. The clinics upload about 200 GB of X-ray and ultrasound images weekly and need appointment and prescription records to open in under 2 seconds. Their current ADSL lines provide 8 Mbps down and 1 Mbps up; the overnight image sync takes 14 hours and sometimes fails. When two clinics edit the same patient record, the last save overwrites the other. Satellite broadband offers 20/5 Mbps with 650 ms round-trip time for £180 per month. Fibre offers 100/100 Mbps with 12 ms for £420 per month but is only available at two clinics. 4G offers 40/20 Mbps with 40–80 ms for £65 per month, subject to a 300 GB fair-use cap. The group can spend £1,000 per month on connectivity and wants 99.5% availability.
1. Recommend a connectivity plan for the four clinics. Support it with calculations and explain why both latency and bandwidth matter.
Read the worked answer
Fibre at the two clinics with the highest imaging volume and 4G at the other two costs 2 × £420 + 2 × £65 = £970 per month, leaving £30. Satellite is rejected despite its £180 price because 650 ms round-trip time makes interactive record opening slow: each TLS handshake and database query adds at least 0.65 s, so a page needing several round trips can exceed the 2-second target. Bandwidth matters too: 200 GB per week is about 28.6 GB per day, or 2.6 Mbps average, but a single 1 Mbps ADSL uplink needs over 60 hours to upload 28.6 GB, which is why the overnight sync takes 14 hours and fails. Fibre gives 100 Mbps upload and 12 ms latency; 4G gives 20 Mbps upload and 40–80 ms, enough if image uploads are scheduled overnight. The 300 GB fair-use cap is a risk: 200 GB per week is about 870 GB per month across the group, around 217 GB per clinic, so each 4G clinic must monitor usage and avoid sending raw image sets during clinic hours. Keep ADSL as a backup link at the two 4G clinics, not as the primary.
2. Propose a synchronisation and conflict strategy for patient records, and explain how it would prevent the overwrite problem.
Read the worked answer
Use a central cloud database as the single source of truth, not multi-master replication. Each patient record gets a version number and a server-assigned update sequence. When a clinician opens a record, the client stores the version. On save, the server checks that the version still matches; if it does not, the save is rejected and the clinician sees both versions with changed fields highlighted, then chooses or merges. This prevents last-save-wins overwrites. For images, use write-once object storage with unique study IDs; uploads go into a queue and are retried, and the local clinic keeps a read-only cache of recent images. Appointment slots need stronger consistency: allocate them with a short server-side lock or an atomic conditional update, so two clinics cannot book the same slot. Record an audit trail of who changed what and when. Timestamps alone are unsafe because clinic clocks can drift; the server sequence is the authority. Clinics should also have an offline mode that queues changes and marks them as pending, rather than pretending the record is current.
3. Explain how QoS or VLANs could protect appointment booking from image uploads.
Read the worked answer
Put appointment and prescription traffic on a separate VLAN from imaging uploads. On the router, mark appointment traffic as high priority (for example DSCP EF or a vendor priority queue) and give it a guaranteed share of the uplink; put image uploads in a lower-priority queue with a bandwidth cap, such as 60% of the 4G or fibre upload, and schedule bulk transfers outside clinic hours. A VLAN alone isolates broadcast traffic and improves security, but it does not guarantee bandwidth unless QoS is configured on the link. The practical test is to saturate the link with an image upload and measure appointment open time; if it stays under 2 seconds, the policy works. Also reserve some capacity for VoIP if the clinics use it, and monitor latency and packet loss per queue.