Розробка сайту медичної клініки на 1С-Бітрікс

Розробка сайту медичної клініки на 1С-Бітрікс

Сайт медичної клініки — це одночасно точка входу для пацієнтів, інтерфейс запису на прийом та юридично значущий ресурс, до якого висуваються вимоги Роскомнагляду та пошукових систем. Google відносить медичні сайти до категорії YMYL (Your Money or Your Life), а отже, технічні помилки в структурі або контенті безпосередньо впливають на позиції у пошуку.

На 1С-Бітріксі клініка реалізується через поєднання інфоблоків (лікарі, послуги, відділення), модуля веб-форм або кастомного компонента запису, та інтеграції з медичною інформаційною системою. Розберемо детально два ключові блоки: онлайн-запис та інтеграцію з МІС.

Онлайн-запис на прийом та інтеграція з МІС

Це найбільш технічно складна частина проекту. Запис на прийом — це не просто форма зворотного зв'язку. Пацієнт повинен вибрати лікаря, спеціалізацію, дату й час із реально доступних слотів, а дані повинні потрапити в розклад клініки без ручного перенесення.

Архітектура запису

Компонент запису працює за такою схемою:

1. Пацієнт вибирає напрямок (терапевт, кардіолог, УЗД)
2. Система показує лікарів, які ведуть прийом за цим напрямком
3. Для вибраного лікаря підгружається розклад — вільні слоти
4. Пацієнт вибирає дату/час, заповнює дані (ПІБ, телефон, номер полісу — при необхідності)
5. Заявка фіксується локально у Бітріксі та надсилається в МІС

Розклад зберігається в Highload-блоці DoctorSchedule з полями:

Вільні слоти підгружаються AJAX-запитом. Компонент на фронтенді відмальовує календарну сітку на тиждень або місяць. При виборі слота — блокування на 5-10 хвилин (таймер резерву), щоб виключити подвійний запис.

Інтеграція з МІС: МЕДИАЛОГ, 1С:Медицина

МІС — це система, в якій живе реальний розклад клініки. Без інтеграції запис на сайті перетворюється на заявку, яку адміністратор вручну переносить в МІС. Це працює на потоці 10-20 записів на день, але не масштабується.

МЕДИАЛОГ надає REST API для роботи з розкладом. Типові ендпоінти:

• GET /schedule/free-slots — отримання вільних слотів за лікарем і періодом
• POST /appointment/create — створення запису
• GET /appointment/{id}/status — перевірка статусу

Інтеграція реалізується через кастомний модуль Бітрікса. Створюється клас-обгортка для HTTP-запитів до API МЕДИАЛОГ, який викликається з компонента запису. Розклад кешується в Highload-блоці з TTL 5-15 хвилин та оновлюється при кожному запиті вільних слотів.

1С:Медицина — обмін через COM-об'єкт або HTTP-сервіс на стороні 1С. Формат даних — JSON або XML, залежить від версії конфігурації. Для 1С:Медицина. Лікарня використовується стандарт HL7 FHIR для обміну ресурсами типу Appointment, Schedule, Slot.

Приклад структури FHIR-ресурсу Slot:

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

Критично важливий момент — обробка конфліктів. Пацієнт записався на сайті, але в МІС слот уже зайнято (адміністратор записав по телефону). Рішення — синхронна перевірка в момент підтвердження запису: перед фінальним POST робиться повторний GET вільних слотів. Якщо слот уже зайнято — пацієнту показується найближча альтернатива.

Уведомлення

Після запису — ланцюжок уведомлень:

• SMS пацієнту (через SMS-шлюз: SMS.ru, SMSC.ru) — підтвердження запису
• Email з деталями прийому
• Нагадування за 24 години та за 2 години — через \Bitrix\Main\Mail\Event або зовнішній сервіс
• Уведомлення лікарю/адміністратору — в CRM Бітрікса як активність

YMYL-контент та E-E-A-T

Google оцінює медичні сайти за критеріями Experience, Expertise, Authoritativeness, Trustworthiness. Це не абстрактні рекомендації — сайти клінік, що не відповідають E-E-A-T, можуть втратити до 70% органічного трафіку після оновлень алгоритму.

Сторінки лікарів

Інфоблок Doctors з властивостями:

• ПІБ, посада, стаж — текстові властивості
• Спеціалізації — множественна привʼязка до довідника (Highload-блок Specializations)
• Освіта, дипломи — множественна властивість типу «Файл» для сканів + текстове для опису
• Публікації — привʼязка до інфоблока Publications (назва, журнал, рік, DOI)
• Сертифікати — файли з датами видачі та закінчення

Кожна сторінка лікаря повинна містити структуровані дані Schema.org типу Physician:

{
  "@type": "Physician",
  "name": "Іванов Іван Петрович",
  "medicalSpecialty": "Кардіологія",
  "memberOf": {"@type": "MedicalOrganization", "name": "Клініка N"},
  "alumniOf": "РНІМУ імені М.І. Пирогова"
}

Вбудовується через компонент, що формує JSON-LD у <head> сторінки.

Сторінка клініки

Розмітка MedicalOrganization включає: назву, адресу, телефон, ліцензію, часи роботи, геокоординати. Ліцензія — обов'язковий елемент. Номер ліцензії, ким видана, дата — виводяться в нижньому колонтитулі кожної сторінки та розмічаються в Schema.org.

Каталог послуг

Інфоблок Services з ієрархією розділів: напрямок → категорія → послуга. Кожна послуга містить:

• Назву та описання (SEO-оптимізований текст, написаний лікарем або під його редакцією)
• Код послуги за номенклатурою клініки
• Ціну — властивість торгового каталогу (якщо підключений модуль catalog) або числову властивість інфоблока
• Протипоказання, підготовку до процедури — детальний опис
• Привʼязку до лікарів, що надають послугу

Ціни на медичні послуги — окрема тема. Прейскурант публікується відповідно до вимог Постанови Уряду РФ №1006. Реалізується як сторінка з усіма послугами в табличному вигляді (компонент catalog.section.list в режимі таблиці) з можливістю завантажити PDF-версію прейскуранту.

Відповідність закону про захист персональних даних

Будь-яка форма, що збирає персональні дані пацієнтів, вимагає:

• Згоди на обробку персональних даних — чекбокс з посиланням на політику
• Політику обробки персональних даних — окремо сторінку, доступну з кожної форми
• SSL-сертифікат — обов'язково, без винятків
• Зберігання даних на території РФ — хостинг у російському дата-центрі
• Повідомлення Роскомнагляду про початок обробки персональних даних

У Бітріксі модуль main підтримує налаштування згоди на обробку персональних даних через «Угоди» (розділ «Налаштування» → «Угоди»). Привʼязка угоди до веб-форми — через параметр компонента.

Для медичних даних (діагнози, результати обстежень) вимоги жорсткіші — це спеціальна категорія персональних даних. На сайті клініки такі дані зберігати не рекомендується; особистий кабінет пацієнта повинен відображати їх з МІС по API, не зберігаючи локально.

Додаткові модулі

Новини та статті — інфоблок з обов'язковим указанням автора-лікаря (для E-E-A-T). Привʼязка до інфоблока Doctors через властивість типу E.

Відгуки — інфоблок Reviews з модерацією. Властивості: текст, оцінка, привʼязка до лікаря, привʼязка до послуги, дата візиту. Публікація тільки після перевірки адміністратором (ACTIVE = N за замовчуванням).

Акції — інфоблок з датами активності (властивості DATE_ACTIVE_FROM / DATE_ACTIVE_TO). Автоматичне приховування застарілих акцій.

Терміни реалізації

Основний ризик за термінами — інтеграція з МІС. Документація API буває неповною, тестові середовища — нестабільними. Закладайте буфер.