Маркетплейс электронных рецептов в ВКР: от FHIR-интеграции до метрик надёжности

25 марта 2026 года стартап VITL объявил о привлечении $7,5 млн. Продукт — маркетплейс электронного выписывания рецептов для клиник, работающих по модели прямой оплаты (cash-pay), то есть без страховых выплат: пациент платит сам. Драйвер роста — ажиотаж вокруг препаратов класса GLP-1. Для выпускника ИТ-направления это не просто новость из мира венчура, а готовый каркас темы ВКР: тут есть распределённая архитектура, интеграции по медицинским стандартам, юридически значимый документооборот, платежи и, главное, измеримая нагрузка. Разберём, как превратить этот сюжет в защищаемую работу с расчётами, схемами и выводами — а не в реферат «про цифровое здравоохранение».

Три темы ВКР, которые вырастают из этого кейса

Тема 1. Сервис-ориентированная платформа электронного рецепта для клиник с прямой оплатой

Актуальность. VITL строит именно маркетплейс, а не монолитную МИС: клиника, аптека и платёжный провайдер — независимые участники. Ровно такую декомпозицию можно обосновать в первой главе, опираясь на новость и на данные о росте сегмента cash-pay.

Цель: спроектировать и реализовать прототип платформы, обеспечивающей полный цикл «приём — назначение — выбор аптеки — оплата — выдача».

• проанализировать существующие модели выписывания рецептов и обосновать выбор микросервисной декомпозиции;
• разработать контракты взаимодействия сервисов на основе HL7 FHIR;
• реализовать маршрутизацию рецепта в аптеку с учётом цены, наличия и геолокации;
• оценить производительность и отказоустойчивость под нагрузкой.

Структура: Глава 1 — анализ рынка и стандартов (FHIR, SNOMED CT, RxNorm), обзор аналогов. Глава 2 — архитектура, диаграммы C4, схема данных, API-контракты. Глава 3 — нагрузочное тестирование, расчёт экономики внедрения.

Тема 2. Алгоритм маршрутизации рецепта в аптечную сеть

Актуальность. В модели cash-pay цена препарата критична: пациент сам выбирает, где забрать заказ. Маркетплейс без умной маршрутизации превращается в обычный справочник.

Цель: разработать и исследовать алгоритм выбора аптеки, минимизирующий стоимость и время получения препарата.

• формализовать критерии выбора и функцию полезности;
• сравнить жадный алгоритм, взвешенный скоринг и задачу о назначениях;
• реализовать сервис маршрутизации с кэшированием остатков;
• провести эксперименты на синтетическом наборе данных.

Структура: Глава 1 — теория оптимизации и предметная область. Глава 2 — математическая модель, псевдокод, реализация. Глава 3 — метрики качества маршрутизации, сравнение с baseline.

Тема 3. Наблюдаемость телемедицинской платформы: метрики, логи, трассировки

Актуальность. Когда спрос на GLP-1 подскакивает, платформа получает пиковую нагрузку за минуты. Без телеметрии инцидент диагностируется «на глаз», а в дипломе нечего защищать в третьей главе.

Цель: построить контур наблюдаемости и доказать его эффективность на метриках качества по ISO/IEC 25010.

• определить набор SLI/SLO для критичных сценариев;
• внедрить OpenTelemetry (трассировки, метрики, логи) и экспортёры;
• настроить дашборды и алерты по симптомам, а не по причинам;
• провести эксперимент «до/после» и посчитать MTTR.

Структура: Глава 1 — обзор подходов и стандартов. Глава 2 — архитектура сбора телеметрии. Глава 3 — эксперименты, метрики, экономический эффект от снижения простоя.

Аналитическая глава: как обосновать стек, а не перечислить его

Слабое место большинства работ — фраза «для реализации выбраны React, Node.js и PostgreSQL, потому что они популярны». Эксперт это читает как отсутствие анализа. Стройте сравнение вокруг требований, а требования выводите из специфики медицинского маркетплейса: юридическая значимость операции, разграничение доступа к персональным данным, пиковая нагрузка, аудит действий.

Сравнение протоколов интеграции

В качестве иллюстрации — упрощённый ресурс назначения, который сервис отправляет в аптеку:

{
  "resourceType": "MedicationRequest",
  "status": "active",
  "intent": "order",
  "medicationCodeableConcept": {
    "coding": [{
      "system": "http://www.nlm.nih.gov/research/umls/rxnorm",
      "code": "2200650",
      "display": "semaglutide 1 mg"
    }]
  },
  "subject": { "reference": "Patient/1042" },
  "requester": { "reference": "Practitioner/77" },
  "dispenseRequest": {
    "performer": { "reference": "Organization/pharmacy-318" }
  }
}

Обратите внимание на кодирование препарата справочником, а не строкой. Это отдельный тезис для первой главы: текстовое название не позволяет автоматически проверять взаимодействия и подбирать аналоги.

Проектная часть: схемы, которые ждёт комиссия

Минимум, который стоит показать: контекстная диаграмма системы, диаграмма компонентов, последовательность выписывания рецепта и модель данных. Не рисуйте «просто прямоугольники» — подписывайте протоколы и направления вызовов, иначе архитектура выглядит декоративной.

• Контекст: клиника, врач, пациент, аптека, платёжный шлюз, сервис проверки взаимодействий.
• Компоненты: API Gateway, сервис идентификации, сервис назначений, сервис маршрутизации, сервис платежей, сервис уведомлений, хранилище аудита.
• Последовательность: авторизация врача → создание черновика назначения → проверка противопоказаний → подписание → передача в маршрутизатор → оплата → подтверждение выдачи.
• Данные: отдельное хранилище для аудит-лога с неизменяемыми записями.

Развёртывание и CI/CD

Если в работе фигурирует Kubernetes, опишите не только манифесты, но и стратегию релиза (rolling update или blue-green), а также политику ресурсов. Это даёт материал для расчёта стоимости инфраструктуры в третьей главе. Пайплайн сборки удобно представить как последовательность: статический анализ → unit-тесты → сборка образа → сканирование уязвимостей → деплой в staging → smoke-тесты → деплой в production.

Тестирование и метрики: то, что отличает работу с расчётами

Третья глава проваливается чаще всего. Студент пишет «система работает быстро», но не приводит ни одного числа. Исправляется это тремя наборами измерений.

Нагрузочное тестирование

Задайте профиль нагрузки, привязанный к сценарию: утро понедельника, массовая запись на консультацию, одновременная выписка сотен рецептов. Снимайте зависимость времени отклика от числа виртуальных пользователей, находите точку насыщения. Обязательно опишите стенд: число ядер, объём памяти, версии СУБД — иначе цифры невоспроизводимы.

Отказоустойчивость и восстановление

Для медицинского сервиса ключевые показатели — RTO (целевое время восстановления) и RPO (допустимая потеря данных). Проведите эксперимент: погасите один экземпляр сервиса, зафиксируйте время переключения трафика. Для хранилища аудита продемонстрируйте процедуру восстановления из резервной копии и посчитайте, сколько записей теряется при заданном интервале бэкапа.

Метрики качества по ISO/IEC 25010

Такой набор метрик закрывает сразу два запроса комиссии: «где данные для расчётов» и «почему выбран именно этот стек».

Чему вы научитесь на такой теме

• Проектировать распределённую систему с явными границами сервисов и контрактами.
• Работать с медицинскими стандартами обмена данными и справочниками кодирования.
• Обосновывать выбор технологий через требования, а не через популярность.
• Строить наблюдаемость и превращать телеметрию в защищаемые метрики.
• Оформлять техническую документацию по ГОСТ 34.602-89 и ГОСТ 19.201-78 без переписывания шаблонов.
• Считать экономику внедрения: стоимость инфраструктуры, срок окупаемости, эффект от снижения простоев.

FAQ: вопросы, которые задают чаще всего

Источник: Riding the GLP-1 boom, VITL lands $7.5M to overhaul cash-pay clinic prescribing (опубликовано 2026-03-25)