Developing a medical clinic website using 1C-Bitrix

Medical Clinic Website Development on 1C-Bitrix

A medical clinic website is simultaneously an entry point for patients, an appointment scheduling interface, and a legally significant resource subject to requirements from Roskomnadzor and search engines. Google classifies medical websites as YMYL (Your Money or Your Life), meaning technical errors in structure or content directly impact search rankings.

On 1C-Bitrix, a clinic is implemented through a combination of infoBlocks (doctors, services, departments), a web-form module or custom appointment booking component, and integration with a medical information system. Let's examine in detail two key components: online booking and MIS integration.

Online Appointment Booking and MIS Integration

This is the most technically complex part of the project. Appointment booking is not simply a feedback form. The patient must select a doctor, specialty, date, and time from actually available slots, and the data must enter the clinic's schedule without manual transfer.

Booking Architecture

The booking component operates according to this scheme:

1. Patient selects a direction (therapist, cardiologist, ultrasound)
2. System shows doctors operating in this direction
3. For the selected doctor, the schedule is loaded—available time slots
4. Patient selects date/time, fills in data (name, phone, insurance number—if needed)
5. The booking is fixed locally in Bitrix and sent to the MIS

The schedule is stored in Highload block DoctorSchedule with fields:

Available slots are loaded via AJAX request. The frontend component renders a calendar grid by week or month. When a slot is selected—a 5-10 minute reservation lock (reservation timer) prevents double booking.

MIS Integration: MEDIALOG, 1C:Medicine

MIS is the system where the clinic's actual schedule lives. Without integration, website booking becomes a request that an administrator manually enters into the MIS. This works at a volume of 10-20 bookings per day but doesn't scale.

MEDIALOG provides a REST API for working with schedules. Typical endpoints:

• GET /schedule/free-slots — retrieve available slots by doctor and period
• POST /appointment/create — create a booking
• GET /appointment/{id}/status — check status

Integration is implemented through a custom Bitrix module. A wrapper class for HTTP requests to MEDIALOG API is created, called from the booking component. The schedule is cached in a Highload block with a 5-15 minute TTL and updated on each free slot request.

1C:Medicine—exchange via COM object or HTTP service on the 1C side. Data format—JSON or XML, depending on configuration version. For 1C:Medicine Hospital, the HL7 FHIR standard is used for exchanging resources like Appointment, Schedule, Slot.

Example FHIR Slot resource structure:

Slot: {status: "free", start: "2026-03-15T09:00:00", end: "2026-03-15T09:30:00", schedule: {reference: "Schedule/doctor-42"}}

A critically important moment is conflict handling. The patient booked online, but the slot is already taken in MIS (the receptionist booked by phone). The solution is synchronous checking at confirmation: before final POST, a repeat GET of available slots is performed. If the slot is already booked—the patient is shown the nearest alternative.

Notifications

After booking—a chain of notifications:

• SMS to patient (via SMS gateway: SMS.ru, SMSC.ru)—booking confirmation
• Email with appointment details
• Reminder 24 hours and 2 hours before—via \Bitrix\Main\Mail\Event or external service
• Notification to doctor/receptionist—in Bitrix CRM as an activity

YMYL Content and E-E-A-T

Google evaluates medical websites by Experience, Expertise, Authoritativeness, Trustworthiness criteria. These aren't abstract recommendations—clinic websites not conforming to E-E-A-T can lose up to 70% of organic traffic after algorithm updates.

Doctor Pages

InfoBlock Doctors with properties:

• Name, position, experience—text properties
• Specializations—multiple binding to reference book (Highload block Specializations)
• Education, diplomas—multiple property type "File" for scans + text for description
• Publications—binding to Publications infoBlock (title, journal, year, DOI)
• Certificates—files with issue and expiration dates

Each doctor page should contain structured Schema.org data type Physician:

{
  "@type": "Physician",
  "name": "Ivan Ivanov Petrovich",
  "medicalSpecialty": "Cardiology",
  "memberOf": {"@type": "MedicalOrganization", "name": "Clinic N"},
  "alumniOf": "Pirogov Russian National Research Medical University"
}

Embedded via component forming JSON-LD in page <head>.

Clinic Page

MedicalOrganization markup includes: name, address, phone, license, hours, coordinates. License is mandatory. License number, issuer, date—displayed in the footer of each page and marked up in Schema.org.

Service Catalog

InfoBlock Services with hierarchical sections: direction → category → service. Each service contains:

• Title and description (SEO-optimized text written by or under doctor's editing)
• Service code per clinic nomenclature
• Price—merchandise catalog property (if catalog module is enabled) or numeric infoBlock property
• Contraindications, procedure preparation—detailed description
• Binding to doctors providing the service

Medical service pricing is a separate topic. Price list is published per Government Resolution RF #1006 requirements. Implemented as a page with all services in table view (component catalog.section.list in table mode) with ability to download PDF price list version.

Compliance with Data Protection Law 152-FZ

Any form collecting patient personal data requires:

• Consent to personal data processing—checkbox with policy link
• Personal data processing policy—separate page accessible from each form
• SSL certificate—mandatory, no exceptions
• Data storage in RF territory—hosting in Russian data center
• Notification to Roskomnadzor of personal data processing commencement

In Bitrix, the main module supports personal data processing consent configuration through "Agreements" (Settings → Agreements section). Binding an agreement to a web form—via component parameter.

For medical data (diagnoses, examination results), requirements are stricter—this is a special category of personal data per 152-FZ. Storing such data on a clinic website is not recommended; a patient's personal account should display them from the MIS via API without saving locally.

Additional Modules

News and Articles—infoBlock with mandatory author-doctor indication (for E-E-A-T). Binding to Doctors infoBlock via property type E.

Reviews—infoBlock Reviews with moderation. Properties: text, rating, doctor binding, service binding, visit date. Publication only after administrator review (ACTIVE = N by default).

Promotions—infoBlock with activity dates (properties DATE_ACTIVE_FROM / DATE_ACTIVE_TO). Automatic hiding of expired promotions.

Implementation Timeline

The primary timeline risk is MIS integration. API documentation is sometimes incomplete, test environments are unstable. Build in a buffer.