Business Continuity & Disaster Recovery Plan

1. Purpose and scope

Patients and clinics depend on DocGini to know who is booked, who is next in the queue, and what happened at earlier visits. This Business Continuity & Disaster Recovery Plan ("Plan") explains how MEDCONS prepares for disruption, keeps essential services running, and recovers when something goes wrong. It covers the DocGini website, mobile application, portals and the systems and people behind them. It supports Section 20 of our Terms of Service.

2. What could disrupt the service

• server, hosting or network failure;
• power, internet or mobile network outages, including local outages in areas we serve;
• a security incident, such as malware or unauthorised access;
• failure of a vendor, such as an email, SMS or payment provider;
• loss or corruption of data, including through human error;
• natural disasters, floods, civil unrest, or loss of access to our offices.

3. Priorities

When services are disrupted, we restore them in this order:

1. protecting data and stopping any security threat;
2. access to patient records and today's bookings and queues for Providers;
3. patient access to their bookings and records;
4. new bookings and notifications;
5. everything else, such as reports and marketing pages.

4. Recovery targets

• Recovery time: we aim to restore core services within 8 hours of a major failure.
• Data loss: we aim to lose no more than 24 hours of data in the worst case, and much less in ordinary failures.

These are targets, not guarantees, and events outside our control may take longer.

5. How we prepare

• Backups: the database is backed up at least daily, and backups are kept separately from the live servers, protected like live data and retained on a rolling cycle.
• Restore testing: we test restoring from backup at least twice a year.
• Rebuildable systems: DocGini can be redeployed from version-controlled code and documented configuration, so a failed server can be replaced.
• Monitoring: we monitor availability and errors so problems are noticed quickly.
• Vendor resilience: critical vendors are assessed under our Vendor & Third-Party Risk Management Policy, and alternatives are identified where practical.
• People: more than one person knows how to run and recover each critical system, and contact details are kept up to date.

6. When something goes wrong

1. Detect and assess: confirm the problem, its cause and its impact.
2. Decide: a named lead takes charge and decides whether to invoke this Plan.
3. Communicate: tell affected Providers and patients what is happening and what to do, through the channels still working, and keep them updated.
4. Recover: restore services in the priority order above, from backup where needed, and check that data is complete and correct.
5. Review: after serious disruption, review what happened and improve this Plan.

If the disruption involves a security incident, our Data Security & Incident Response Policy also applies.

7. Working while DocGini is unavailable

Clinics should keep a simple fallback so patients can still be seen during an outage, for example a printed or offline list of the day's bookings and a paper token system. Entries made on paper should be added to DocGini once it is back, so records stay complete. Patients should keep their booking confirmation email, which shows their token, time and MRN.

DocGini is never the right route in an emergency. Call 1122 or go to the nearest hospital.

8. Events beyond our control

We are not liable for failure or delay caused by events beyond our reasonable control, as set out in the Terms of Service, but we will always work to limit the impact and restore the service as quickly as we can.

9. Review

This Plan is reviewed at least once a year, after any major disruption, and when the platform changes significantly. Material changes will be notified in the same way as changes to the Terms of Service.

Contact Us