Перейти к содержанию

Kanban Backlog

Оценка — Fibonacci (1, 2, 3, 5, 8, 13, 21). Приоритет: P0 — без этого система не работает по назначению; P1 — нужно для полноты; P2 — улучшение.

Тип: spike — исследование, результат которого меняет решения (оценка = коробка времени, не объём работы).

Сводка по эпикам

# Эпик Подсистема SP Приоритет
E1 Платформа и инфраструктура общая 49 P0
E2 Шлюз приёма от СМП Триаж 66 P0
E3 Регистр направлений и центральный пульт Триаж 61 P0
E4 Координаты карет Триаж 29 P0
E5 Интеграция с МИС «Медик» общая 47 P0
E6 Сортировка ТРИАЖ Триаж 70 P0
E7 Очередь, оформление, выбытие Триаж 34 P0

| E10 | Терминалы, печать, табло | Триаж | 36 | P0 | | E11 | Безопасность и отказоустойчивость | общая | 65 | P0 | | E12 | Соответствие и аттестация | общая | 71 | P0 | | E13 | Отчётность и КПЭ | общая | 21 | P0 | | | Итого | | 549 | |

flowchart LR
  E12["E12 · Соответствие<br/>71 SP"] -.->|"блокирует ввод"| PROD["Промышленная<br/>эксплуатация"]
  E1["E1 · Платформа<br/>49"] --> E2["E2 · Шлюз СМП<br/>66"]
  E1 --> E5["E5 · МИС<br/>47"]
  E1 --> E11["E11 · Безопасность<br/>65"]
  E2 --> E3["E3 · Пульт<br/>61"]
  E3 --> E4["E4 · Координаты<br/>29"]
  E3 --> E6["E6 · Сортировка<br/>70"]
  E6 --> E7["E7 · Очередь<br/>34"]
  E7 --> E10["E10 · Терминалы<br/>36"]
  E7 --> E13["E13 · КПЭ<br/>21"]
  E3 & E6 & E7 --> PROD

Пять spike-задач должны быть выполнены первыми

Каждая из них может изменить архитектуру или состав закупки. Выполнять их после начала разработки означает переделывать сделанное.

Задача Что решает Крайний срок
E5-1 Исследование API МИС «Медик» Доступность необходимых операций до проектирования
E6-1 Сверка со «светофором» Пост. МЗ № 62 Совпадает ли цветовая модель до реализации движка правил
E13-3 Определение КПЭ «время ожидания» Как измеряется приёмочный показатель до начала измерений

E1 — Платформа и инфраструктура · 49 SP

Общее основание (ADR-8).

ID Задача SP Приор. Зависит Критерий готовности
E1-1 Каркас проекта, структура репозитория, CI, линт, тесты 3 P0 Пайплайн зелёный, шаблон сервиса запускается
E1-2 Базовая схема БД + миграции TypeORM 5 P0 E1-1 Миграции применяются и откатываются
E1-3 Партиционирование по времени + автосоздание партиций 5 P0 E1-2 Партиции создаются на 3 мес вперёд; отцепление по политике таблицы
E1-4 Аутентификация, сессии, блокировка по бездействию 5 P0 E1-2 Требование ОАЦ по блокировке выполняется, время настраивается
E1-5 RBAC: роли, права, проверка на всех эндпоинтах 5 P0 E1-4 Все 9 ролей работают; security не видит ПДн, admin не пишет в журналы
E1-6 Каталог пациентов: сопоставление, шифрование ПДн, HMAC-поиск 8 P0 E1-2 Поиск по личному номеру работает без расшифровки таблицы
E1-7 Реестр провайдеров + динамическая загрузка ACL из БД 5 P0 E1-2 Новый провайдер подключается без пересборки
E1-8 Шина уведомлений (RabbitMQ) + WebSocket-хаб 5 P0 E1-1 Событие доходит до клиента; переживает перезапуск сервиса
E1-9 Docker Compose, конфигурация инсталляции 3 P0 E1-1 Развёртывание в чистом окружении по инструкции
E1-10 Наблюдаемость: Prometheus, метрики, дашборды 5 P1 E1-9 Метрики из NFR собираются

E2 — Шлюз приёма от СМП · 66 SP

ID Задача SP Приор. Зависит Критерий готовности
E2-1 HTTP-листенер на выделенном порту, mTLS, IP allowlist 5 P0 E1-7 Соединение без валидного сертификата отклоняется
E2-2 Симулятор вендора СМП (поставляемый артефакт) 8 P0 Воспроизводит все 5 типов сообщений, включая ошибочные
E2-3 Валидация FHIR R4 5 P0 E2-1 Невалидный Bundle → OperationOutcome
E2-4 Идемпотентность + хранение сырого Bundle в JSONB 3 P0 E2-3 Повтор не создаёт дубль, возвращает тот же результат
E2-5 Диспетчер пяти типов сообщений 3 P0 E2-4 Тип определяется из MessageHeader.event и явного маршрута
E2-6 ACL: интерфейс SmpAdapter, нормализация единиц/кодов/времени 13 P0 E2-5 Единицы → UCUM; неизвестный код → normalization_issues, не null
E2-7 Адаптер ИС «МРМ бригады СМП» 13 P0 E2-6, E2-2 Все фикстуры вендора разбираются в каноническую модель
E2-8 CapabilityStatement на /fhir/metadata 2 P0 E2-1 Отдаётся валидный ресурс
E2-9 Обработка ошибок, коды ответов, OperationOutcome 3 P0 E2-3 2xx только после записи в БД
E2-10 Контрактные тесты на фикстурах вендора 8 P0 E2-7 Покрыты все поля набора данных СМП
E2-11 Отчёт по normalization_issues 3 P1 E2-6 Метрика на дашборде с порогом оповещения

E3 — Регистр направлений и центральный пульт · 61 SP

ID Задача SP Приор. Зависит Критерий готовности
E3-1 transport_request: приём, решение, синхронный ответ, журнал 8 P0 E2-5 Ответ за < 3 с; таймаут 30 с → conditional
E3-2 transport_notification: регистрация направления 8 P0 E2-7, E1-6 Все поля набора данных сохранены
E3-3 transport_health_status: поток наблюдений, дедупликация 5 P0 E3-2 Повтор измерения не создаёт дубль
E3-4 transport_cancel: отмена, освобождение резерва 3 P0 E3-2 Карточка снята, опрос координат остановлен
E3-5 transport_complete: доставка, отсечка времени 5 P0 E3-2 delivered_at зафиксирован
E3-6 Центральный пульт: борд направляющихся (Angular + WS) 13 P0 E1-8, E3-2 Направление на пульте < 5 с от приёма
E3-7 Карта карет на пульте 8 P1 E3-6, E4-3 Положение отображается, устаревание индицируется
E3-8 Индикация ухудшения состояния, тренды показателей 5 P0 E3-3, E3-6 Переход через порог заметен визуально и звуково
E3-9 Детектор тишины по активным направлениям 3 P1 E3-6 Карточка помечается «нет обновлений N мин»
E3-10 Подтверждение приёма пациента медработником 3 P0 E3-5 accepted_at, accepted_by зафиксированы

E4 — Координаты карет · 29 SP

ID Задача SP Приор. Зависит Критерий готовности
E4-1 Интерфейс GeoAdapter + планировщик опроса 5 P0 E1-7 Период опроса настраивается на провайдера
E4-2 Лог запросов location_requests 3 P0 E4-1 Пишется на каждый запрос, включая неуспешные
E4-3 Адаптер источника координат № 1 8 P0 E4-1 Позиции получаются, source_time сохраняется
E4-4 Адаптер источника координат № 2 (другой тип) 5 P1 E4-3 Два источника работают одновременно
E4-5 Деградация: устаревшие координаты, проверка доступности 3 P0 E4-3 Недоступность источника не влияет на приём медданных
E4-6 Расчёт ETA 5 P1 E4-3 ETA отображается на карточке

E5 — Интеграция с МИС «Медик» · 47 SP

ID Задача SP Приор. Зависит Критерий готовности
E5-1 spike: исследование API АИС «Медик» 3 P0 Задокументировано, какие операции доступны; получен ответ по get_patient_summary
E5-2 Интерфейс MisAdapter 5 P0 E5-1 Контракт зафиксирован
E5-3 Адаптер «Медик»: push_appeal 13 P0 E5-2 Обращение создаётся в МИС
E5-4 Ручная передача в МИС: request_team 5 P0 E5-3 Только по действию оператора; initiated_by и причина сохранены
E5-5 Уведомление об отмене после сбора бригады 3 P0 E5-4, E3-4 Отмена доходит до МИС, бригада распускается
E5-6 Очередь повторов с backoff, неблокирующая работа 5 P0 E5-3 Недоступность МИС не останавливает приём пациентов

E6 — Сортировка ТРИАЖ · 70 SP

ID Задача SP Приор. Зависит Критерий готовности
E6-1 spike: сверка цветовой модели с Пост. МЗ РБ № 62 2 P0 Подтверждено соответствие «светофору» либо зафиксированы отличия
E6-2 Модель правил: таблицы, версионирование, утверждение 8 P0 E1-2 Версия правила утверждается и вводится в действие раздельно
E6-3 Движок правил: интерпретация условий, порядок применения 13 P0 E6-2 Расчёт < 200 мс; результат содержит обоснование
E6-4 Недостающие данные, статус «не покрыто правилами» 5 P0 E6-3 Отсутствие показателя не даёт молчаливого зелёного
E6-5 Ограничение «пациент СМП не бывает зелёным» 2 P0 E6-3 Попытка отклоняется; исключение требует обоснования и протоколируется
E6-6 Экран сортировки 8 P0 E6-3 Не более 6 полей на первом экране, работа в перчатках
E6-7 Быстрая ручная сортировка (присвоение цвета) 3 P0 E6-6 mode='manual', автор зафиксирован
E6-8 Пересортировка при ухудшении 5 P0 E6-3 Новая запись оценки, талон перевыпускается
E6-9 Снимок входных значений оценки 3 P0 E6-3 Решение воспроизводимо спустя время
E6-10 UI редактирования правил + simulate 13 P1 E6-2 Прогон на исторических данных до активации
E6-11 Режим массового поступления 8 P1 E6-1, E6-7 Цвет одним касанием, браслет обязателен

E7 — Очередь, оформление, выбытие · 34 SP

ID Задача SP Приор. Зависит Критерий готовности
E7-1 Обращения: создание для СМП и самообращений 5 P0 E3-5 Самообращение без паспортной части
E7-2 Очередь, priority_rank, порядок вызова по цветам 5 P0 E6-3 Красные → жёлтые → зелёные
E7-3 Норматив выбытия + защита от голодания зелёных 5 P0 E7-2 Приближение к дедлайну повышает ранг; нарушение фиксируется
E7-4 Форма оформления + предзаполнение из данных СМП 8 P0 E7-1, E5-3 Для СМП-пациента паспортная часть предзаполнена
E7-5 Выбытие / выписка из приёмного отделения 3 P0 E7-4 closed_at, причина зафиксированы
E7-6 Красный минуя приёмник — сразу в отделение 3 P0 E7-2 Переход triaged → closed без блокировки на оформлении
E7-7 Экран очереди для регистратора 5 P0 E7-2 Вызов следующего и конкретного талона

E10 — Терминалы, печать, табло · 36 SP

ID Задача SP Приор. Зависит Критерий готовности
E10-1 Терминал самообращения (киоск) 8 P0 E7-1 Одна кнопка, работает без сессии
E10-2 Печать талона 5 P0 E6-6 Код и цвет читаемы
E10-3 Печать браслета со штрих-кодом и цветом приоритета 8 P0 E10-2 2D-код содержит идентификатор обращения, не ПДн
E10-4 Сканирование браслета для идентификации 5 P0 E10-3 Сканер на АРМ и планшете открывает карточку
E10-5 Табло очереди на ТВ 55″ 5 P1 E7-2 Читается с 5–7 м, ПДн не отображает
E10-6 Планшет обхода у койки 5 P1 E10-4, E5-7 Сканирование браслета → сводка пациента

E11 — Безопасность и отказоустойчивость · 65 SP

ID Задача SP Приор. Зависит Критерий готовности
E11-1 Журнал событий ИБ + ретеншн ≥ 12 мес 8 P0 E1-3 Партиции не отцепляются раньше года
E11-2 Аудит доступа к ПДн 5 P0 E1-6 Каждое чтение карточки пациента фиксируется
E11-3 Шифрование ПДн + внешнее секрет-хранилище 8 P0 E1-6 В БД только secret_ref; дамп не даёт доступа наружу
E11-4 ЭЦП: подписание документов 13 P0 E6-9, E7-4 Подписываются сортировка, обращение, передача, выписка
E11-5 Синхронизация времени и контроль расхождения 3 P0 E1-9 Расхождение фиксируется как событие ИБ
E11-6 Обезличивание для выгрузок 5 P0 E11-2 Метод соответствует определённому на этапе 1
E11-7 Резервное копирование + проверка восстановления 5 P0 E1-9 Восстановление проверено с протоколом, RPO < 5 мин
E11-8 Нагрузочное тестирование, включая массовое поступление 8 P0 E7-2 Сценарий 50 обращений за 30 мин пройден
E11-9 Тестирование уязвимостей 5 P0 E11-3 Отчёт, критичные findings закрыты
E11-10 Тестирование отказоустойчивости 5 P0

E12 — Соответствие и аттестация · 71 SP

[ТЗ] Работы этапа 1 и условия ввода в эксплуатацию. Не пишется код, но без этого система не запускается.

ID Задача SP Приор. Зависит Критерий готовности
E12-1 Изучение отнесения ИС к КВОИ (приказ ОАЦ № 66) 3 P0 Получен ответ; объём требований зафиксирован
E12-2 Отнесение ИС к классу типовых информационных систем 2 P0 E12-1 Класс определён
E12-3 Определение методов обезличивания ПДн 3 P0 Методы утверждены, переданы в E11-6
E12-4 Требования к организации взаимодействия ИС 3 P0 E5-1 Документ согласован
E12-5 Расчёт вычислительных мощностей и дискового пространства 5 P0 E9-1 Проверено, что спецификация сервера покрывает оценку
E12-6 Частные ТЗ на три подсистемы 13 P0 E12-1 Разработаны, согласованы, утверждены
E12-7 Комплект проектной документации 13 P0 E12-6 Процессы, архитектура, функции, алгоритмы, структура БД, классификация и кодирование, функции персонала, состав ПО и техсредств
E12-8 Подготовка к аттестации по ЕТТ 8 P0 E11-9 Пакет документов подан
E12-9 Регистрация в Регистре HL7 FHIR-совместимого ПО 5 P0 E2-8 Заявка подана, конформность подтверждена
E12-10 Регистрация в ГРИС 3 P0 E12-8 ИС зарегистрирована
E12-11 Аудит ЛВС, серверного оборудования, ПО, кадрового состава 5 P0 Отчёт, план устранения
E12-12 Регламенты, инструкции, обучение персонала 8 P0 E6-6 Медсестра выполняет цикл сортировки без инструкции

E12-12 — задача, определяющая успех проекта

[ТЗ] Одной из двух причин неудачи предыдущих внедрений «Триажа» в Республике Беларусь названа недостаточная подготовка кадров. Эта задача закрывает причину, которую невозможно закрыть кодом. Она не должна быть остаточной строкой в конце плана.

E13 — Отчётность и КПЭ · 21 SP

ID Задача SP Приор. Зависит Критерий готовности
E13-3 spike: согласование определения «время ожидания» 2 P0 Определение зафиксировано в частном ТЗ
E13-1 Расчёт КПЭ: среднее время ожидания по категориям 5 P0 E13-3, E7-2 Отчёт за месяц < 10 с
E13-2 Расчёт КПЭ: пациентов в час 3 P0 E7-5 Достижение цели 1–4 в час подтверждается данными
E13-5 Дашборд деградации 5 P0 E2-11, E6-4 normalization_issues и «не покрыто правилами» с порогами

| E13-6 | Отчёт по нарушениям норматива выбытия | 3 | P1 | E7-3 | Список нарушений с разбивкой по цветам |

Колонки Kanban

[ПР]

Колонка Смысл Правило выхода
Backlog Не начата
Ready Уточнена, зависимости закрыты, критерий готовности сформулирован Задача понятна без автора
In Progress В работе WIP-лимит: 2 задачи на разработчика
Review Код-ревью Одобрение + зелёный CI
Testing Проверка критерия готовности Критерий подтверждён
Blocked Ожидает внешнего ответа (вендор, заказчик, поставка) Указана причина и ожидаемая дата
Done Готово Критерий выполнен, задача демонстрируема

Колонка Blocked нужна именно этому проекту

Значительная часть задач зависит от внешних сторон: ответов разработчиков МРМ СМП, возможностей API «Медик», сроков госзакупки оборудования, утверждения клинических правил медперсоналом. Без явной колонки такие задачи создают ложное впечатление прогресса, оставаясь в In Progress неделями.