Связаться

Сложные системы

NDA

Система записи пациентов для частной клиники

Серверная система записи пациентов на Go с учетом реального расписания врачей, внутренних мероприятий, индивидуальной длительности приемов и событийного обмена через Kafka.

01

Задача

Для частной клиники требовалось разработать отдельный сервис записи пациентов как часть общей микросервисной архитектуры. Обычного календаря было недостаточно. Доступность врача зависела не только от его рабочего графика и уже существующих приемов, но и от внутренних мероприятий, собраний, перерывов и индивидуальной продолжительности работы конкретного специалиста. Кроме стандартной записи существовали и более сложные сценарии: перенос или отмена времени врачом, подбор альтернативного слота, а также запись с одновременным заполнением анамнеза. Задача заключалась в том, чтобы централизовать эту логику и корректно рассчитывать доступное время для разных врачей и сценариев.

02

Серверная часть

Сервис был разработан на Go и встроен в существующую микросервисную архитектуру клиники. Моя зона ответственности полностью находилась на серверной стороне проекта: логика записи, взаимодействие с другими сервисами и обработка событий. Пользовательский интерфейс разрабатывался отдельной командой. Сервис взаимодействовал с системами расписаний, квалификаций врачей и уведомлений, получая необходимые данные и передавая результаты другим компонентам платформы.

03

Расчет доступного времени

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

04

Несколько сценариев записи

Система должна была поддерживать не один линейный сценарий. Пациент мог выбрать желаемую дату, но в дальнейшем врач мог изменить свое расписание или отменить прием. В зависимости от конкретных условий сервис должен был корректно обработать изменение и передать новое состояние остальным частям системы. Также был предусмотрен сценарий, в котором запись пациента связана с заполнением анамнеза и другими этапами подготовки к приему. Логика была построена так, чтобы разные сценарии могли работать в рамках одной системы записи без создания отдельных независимых процессов.

05

Обработка событий

Для обмена событиями между сервисами использовалась Kafka. Операции записи и изменения расписания проходили через событийную архитектуру с обратной связью. Если в процессе возникал конфликт или запись больше не могла быть подтверждена, система передавала соответствующее событие, после чего пользовательская часть получала актуальное состояние. Такой подход позволял синхронизировать запись с другими компонентами клиники и корректно обрабатывать изменения расписания без рассинхронизации данных. Отдельно сервис взаимодействовал с системой уведомлений, передавая события для дальнейшей отправки сообщений пациентам.

06Ключевой результат

Результат

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

Изображения и внутренние интерфейсы проекта не публикуются по условиям NDA. В кейсе сохранены задача, технический подход и результат работы.

Оценка

Понравился материал?