Розробка портала для аптеки
Аптечний портал — спеціалізований ecommerce з жорсткими регуляторними обмеженнями. Продаж ліків онлайн регульований законодавством: Україні — Закон «Про лікарські засоби». Портал повинен не просто продавати, але й відповідати вимогам до маркування, рецептурних препаратів та інформації про склад.
Регуляторні обмеження — технічні наслідки
Рецептурні препарати (Rx) не можуть продаватися онлайн без верифікації рецепта:
- Товари повинні мати флаг
requires_prescription: boolean - Rx-препарати показуються в каталозі, але додавання в корзину заблоковано без завантаженого рецепта
- Завантажений рецепт верифікується фармацевтом до підтвердження замовлення
Маркування: портал повинен відображати інформацію про серії, строки придатності, перевіряти коди.
Інформація про препарат: закон вимагає відображення інструкції з застосування, протипоказань, умов зберігання. Це не маркетинговий текст — це фіксований регуляторний контент.
Каталог лікарських препаратів
Структура даних препарата складніша, ніж звичайного товару:
drugs (id, trade_name, inn, manufacturer, country_of_origin, atc_code, dosage_form, dosage, package_quantity, requires_prescription, storage_conditions, shelf_life_months, registration_number, is_vital)
drug_contraindications (drug_id, category, description)
drug_interactions (drug_id_a, drug_id_b, severity, description)
ATC-код (Anatomical Therapeutic Chemical Classification) — міжнародна система класифікації, за якою будується ієрархія каталога. Приклад: C09AA01 — каптоприл (інгібітори АПФ). Ключовий атрибут для навігації по терапевтичних групах.
Пошук по МНН та торговим назвам
Користувач може шукати препарат по торговій назві («Нурофен»), МНН («ібупрофен»), або діючій речовині. Каталог повинен зв'язувати всі три та показувати аналоги.
drug_synonyms (drug_id, synonym, type) -- trade_name | inn | popular_name
Пошук по аналогам: SELECT * FROM drugs WHERE inn = ... ORDER BY price. Стандартна функція — показати дешевші аналоги з тією ж діючою речовиною.
Elasticsearch-індекс з полями trade_name, inn, synonyms[], atc_code з буст-коефіцієнтами.
Наявність в аптеках
Типова модель: мережа аптек, у кожної свої залишки. Користувач вводить адресу або геолокацію, портал показує найближчі аптеки з наявністю товару та його ціною.
pharmacy_locations (id, network_id, address, lat, lng, phone, schedule JSONB)
pharmacy_stock (location_id, drug_id, quantity, price, updated_at)
Геопошук: PostGIS розширення для PostgreSQL, функція ST_DWithin. Або простіший варіант — Haversine formula при небольшому числі аптек.
Залишки оновлюються з аптечної облікової системи (1С:Аптека) через API або файловий імпорт. Частота: кожні 15–60 хвилин. Показувати з міткою часу оновлення — честно по відношенню до користувача.
Онлайн-бронювання vs. доставка
Два сценарії з різними юридичними наслідками:
Бронювання в аптеці (click-and-collect): користувач резервує товар, оплачує в аптеці. Юридично простіше — це резервування, а не дистанційна продаж ліків. Технічно: reservation з TTL (зазвичай 24–48 годин), декрементування резерву.
Доставка (тільки безрецептурні препарати, БАД): вимагає ліцензії на дистанційну торгівлю. Технічно — стандартний ecommerce-чекаут з жорсткою фільтрацією по requires_prescription = false.
Інтеграція з системами маркування
Для обов'язкового маркування кожна упаковка має QR/DataMatrix код з GTIN + серійним номером. Інтеграція з системою маркування:
- Верифікація кода при приймці товару:
GET /api/... - Інформація про препарат: виробник, дата випуску, строк придатності, статус
- Вибуття кода при продажу:
POST /api/...— сповіщення про реалізацію
Це backend-тільки інтеграція, користувач бачить тільки «товар перевірен» або інформацію про серію.
Аптечний кабінет для провізора
Персонал аптеки працює в окремому інтерфейсі:
- Верифікація рецептів: список замовлень з прикріпленими рецептами, статус перевірки
- Управління залишками: введення актуальних даних, якщо автоматична синхронізація недоступна
- Бронювання: підтвердження готівості, скасування при відсутності товару
- Логу видачі: історія виданих товарів по рецептам (вимога регулятора)
Особистий кабінет пацієнта
- Історія замовлень та покупок — важливо для хронічних пацієнтів (регулярні препарати)
- Рецепти — зберігання завантажених рецептів з датами виписування та строками дії
- Нагадування — сповіщення про закінчення курсу, про необхідність повторити замовлення
- Обране — швидкий доступ до регулярно купуємих препаратів
Нагадування реалізуються через push-сповіщення (PWA) або email.
SEO та контентна стратегія
Аптечні портали добре ранжуються по інформаційних запросах: «ібупрофен інструкція», «аналоги нурофена». Кожна сторінка препарата — потенційний SEO-трафік.
- Сторінка препарата: повна інструкція з застосування (офіційний текст)
- Сторінка МНН: всі торгові найменування та дженерики
- Сторінка АТХ-групи: препарати терапевтичної групи
Structured data: Drug Schema.org, MedicalCode для АТХ.
Терміни
- Базовий портал (каталог, геопошук аптек, бронювання, безрецептурні препарати): 6–10 тижнів
- Повноцінний портал (рецептурні з верифікацією, інтеграція з системами обліку, доставка, кабінет провізора): 14–20 тижнів
- Інтеграція з кожною додатковою облік
овою системою: 2–4 тижні
Регуляторна складова займає 30–40% часу проекту. Перед початком розробки необхідна юридична консультація по актуальних вимогам у країні роботи сервісу.