Clinic Website and the MIS: How Online Booking Gets Into Your System

A patient picks a doctor in the evening, taps “Book” on the website, and the request goes by email or messenger to the receptionist. In the morning someone has to spot it, call back, find a free slot in the medical information system and enter it by hand. Some requests get lost, some are entered with mistakes, and you cannot see how many patients the website actually brings in. Let us look at how to make a booking from the website land in the clinic’s system straight away. For what else to check with a developer, see the article on 10 questions to ask before you hire a developer for a dentist’s website.

In plain wordsThe website is a reception desk that works around the clock. If it writes patients down on scraps of paper instead of the clinic’s register, someone has to copy it all out in the morning. And something will be lost.

A medical information system (MIS) is the software in which a clinic keeps its doctors’ schedules, patient appointments and medical records. In Ukraine, MIS are connected to the central database of the electronic healthcare system (eHealth). The list of connected systems is published by eHealth itself at ehealth.gov.ua, in the section “MIS connected to the central database of eHealth”.

The schedule lives in the MIS. So a booking made outside it is a duplicate that someone has to carry over by hand. The more bookings come from the website, the more this manual transfer costs: administrators’ time, mistakes in the time, and doctors booked twice into the same slot.

1. API integration. The website gets the doctors’ free slots from the MIS and shows them to the patient, and once the patient chooses, it creates the booking in the MIS. The receptionist sees it in the schedule at once, with nothing to carry over. This is the most convenient option for the patient and the clinic, but it is only possible when the MIS vendor gives programmatic access to booking. You need to find that out from them before work starts.

2. The MIS’s booking widget. Some systems have a ready-made booking module that embeds into a page. It is quick, but the widget lives by the vendor’s rules: design, wording, mobile version and analytics may not match the rest of the website. Check that it is easy to use from a phone and whether you can see which page or ad a booking came from.

3. A booking module on the website. If integration is not possible, the website takes the request itself: it stores it in the website’s database, notifies the receptionist at once and, if there is a CRM, passes the request there. The schedule is not synchronised this way, but the request does not get lost in an inbox and the receptionist handles it in one place.

The worst option is a form that simply sends an email. The email can end up in spam or never arrive, and nobody will know.

The booking source is what separates “how many visitors the website has” from “how many patients the website brought”. Without it, the advertising budget is spread at random. What you may write in the ads themselves and on the pages they lead to is covered in the article on advertising medical services.

The Law of Ukraine “On Personal Data Protection” (Article 7) places data concerning health in a special category: processing it is prohibited except in cases defined by law, including with the patient’s unambiguous consent or to provide medical services by a licensed institution whose staff are bound to keep medical confidentiality.

The practical conclusion for a booking form on a website: collect the minimum. Name, phone, doctor or service and preferred time are enough to book a patient. A “describe your symptoms” field in a website form is a reason to talk separately with your lawyer about how that data is stored and who can access it. And no patient data in analytics or ad accounts: only the “booking” event goes there, without name, phone or service. What else the law requires of the form and the policy is covered in the article on consent and the privacy policy.

• Is there programmatic access (an API) to create a booking and get free slots? Is there documentation and a test environment?
• Is there a ready-made booking widget? How does it look on a phone, and can the wording and colours be changed?
• Can the source (where the patient came from) be passed into the booking?
• Is access to the API or widget charged separately?
• Who is responsible if a booking is not created, and how does the receptionist find out?

At the analysis stage we check whether your MIS or CRM has programmatic access to booking or a widget. If it does, we connect booking from the website directly: free slots, doctors, booking and source. If integration is not possible, we build a booking module on the website that stores requests and passes them to the receptionists at once. We test everything on a copy of the site together with the receptionists, before launch.

Yes. You can embed the MIS’s widget, if there is one, or build a booking module on the website that stores requests and notifies the receptionist. The schedule is then not synchronised automatically, but requests do not get lost.

The MIS keeps the schedule and medical records. A CRM is more often needed for enquiries that have not yet become a booking: calls, messages, repeat contacts. If every enquiry ends in a booking in the MIS, a separate CRM may not be needed.

A template or website builder rarely lets you book a patient into your system. How to decide what your clinic needs is covered in the article on template and custom websites.

Yes. Online booking can be added to an existing website if it technically allows it. We decide what will have the biggest effect first at the consultation.

It depends on what the MIS vendor provides: documentation, a test environment, restrictions. We find this out at the analysis stage and fix the schedule before work starts.

• Integration. The booking is created in the MIS through the vendor’s API; free slots are cached only briefly and checked again before confirmation, so that two patients are not booked into the same time.
• Storage. Every request is stored in the website’s database before it is sent; if the MIS did not respond, retry and notify the receptionist.
• Data. The form collects the minimum, transfer only over HTTPS, access to requests by role, backups.
• Analytics. The booking event in GA4 and ad accounts carries no name, phone, service or doctor; the source (utm) is stored together with the request.
• Testing. A test booking on the copy of the site from a phone, a check that it appeared in the MIS and that the receptionist received the notification.

We build clinic websites on WordPress with online booking that passes into your MIS or CRM, a doctor directory, and a report of how many bookings each source brings. Work goes on a private copy of the site, and the code, access and instructions are handed over to the clinic. Tell us about your clinic: within two working days we send a structure review, an indicative timeline and a price, with no obligation. The price is fixed before work starts. See our clinic website page.