Нефункциональные требования¶
[ТЗ] Этап 1 включает «тестирование созданной информационной системы на предмет быстродействия, уязвимости, отказоустойчивости». Значения ниже — целевые показатели для этих испытаний.
Все числа помечены источником: [ТЗ] — из паспорта; [ПР] — проектная оценка, подлежащая утверждению в частном ТЗ.
Профиль нагрузки¶
Выведен из фактических данных паспорта.
| Параметр | Значение | Источник |
|---|---|---|
| Обращений в приёмное отделение за год | 28 964 | [ТЗ] |
| Обращений в сутки (среднее) | ≈ 79 | расчёт |
| Обращений в час (пик, ×3 к среднему) | ≈ 10 | [ПР] |
| Коек / палат / постов | 560 / 208 / 20 | [ТЗ] |
| АРМ | 44 | [ТЗ] |
Режим массового поступления ломает средние значения
Профиль выше описывает штатную работу. Подсистема «Триаж» проектируется под массовое поступление — это её прямое назначение по паспорту. Нагрузочные испытания обязаны включать сценарий, на порядок превышающий пиковый штатный: одновременное поступление десятков пациентов, пакетная выдача талонов, всплеск сообщений от нескольких бригад.
[ПР] Целевой сценарий испытаний: 50 обращений за 30 минут.
Быстродействие¶
[ПР] Целевые значения для приёмочных испытаний.
| Операция | Цель | Почему такая |
|---|---|---|
Приём входящего сообщения СМП (до 2xx) |
p95 < 500 мс | Вендор не должен ждать; таймаут на его стороне обычно 2–5 с |
Ответ на transport_request |
p95 < 3 с, таймаут 30 с | Бригада стоит у пациента |
| Появление направления на пульте | < 5 с от приёма | Критерий приёмки «Триажа» |
| Обновление показателей на пульте | < 2 с от приёма | Ухудшение должно быть заметно сразу |
| Расчёт цвета движком правил | p95 < 200 мс | Не должен ощущаться при сортировке |
| Открытие карточки обращения | p95 < 1 с |
| Отображение данных монитора на панели | < 2 с | | | Отчёт по КПЭ за месяц | < 10 с | |
Ёмкость хранения¶
[ТЗ] Точный расчёт объёма вычислительных мощностей и дискового пространства выполняется на этапе 1. Оценка ниже — [ПР], вход в этот расчёт.
| Таблица | Оценка объёма/год | Допущения |
|---|---|---|
ambulance_locations |
~2–5 ГБ | ~30 активных карет × опрос раз в 15–30 с |
vital_observations |
~1–3 ГБ | 29 тыс. направлений × десятки наблюдений |
security_events + audit_log |
~10–20 ГБ | Все действия персонала и доступ к ПДн |
integration_log |
~5–10 ГБ | Каждый обмен с вендорами |
| Бизнес-данные (обращения, пациенты, сортировки) | < 1 ГБ | 29 тыс. обращений/год |
Ретеншн¶
[ПР] Политики различаются по таблицам — единый регламент нарушит требования ОАЦ.
| Данные | Срок | Основание |
|---|---|---|
security_events |
≥ 12 мес | [ТЗ] ОАЦ № 66: не менее одного года |
audit_log |
≥ 12 мес | Аналогично, доступ к ПДн |
integration_log |
3–6 мес | Достаточно для разбора инцидентов |
ambulance_locations |
3 мес, затем прореживание | Оперативная ценность быстро падает |
location_requests |
6 мес | Лог запросов — группа данных 4 |
vital_observations |
По регламенту медицинской документации | Часть эпизода |
inbound_messages.raw_body |
3 мес | Для разбора; нормализованные данные хранятся отдельно |
| ПДн пациентов | По регламенту УЗ и законодательству |
Срок хранения медицинских данных — не инженерное решение
Строки, помеченные «по регламенту медицинской документации», определяются нормативными требованиями к срокам хранения медицинских документов и решением УЗ, а не удобством эксплуатации. До получения регламента данные не удаляются.
Доступность¶
| Подсистема | Целевая доступность | Обоснование | |---|---|---|---| | «Триаж» — приём от СМП | 99,5 % | Потеря сообщения = пациент едет неожиданно | | «Триаж» — пульт и очередь | 99,5 % | Есть ручные обходные процедуры | | Отчётность | 99 % | Не влияет на оказание помощи |
| Параметр | Цель [ПР] |
|---|---|
| RTO (время восстановления) | < 2 ч |
| RPO (допустимая потеря данных) | < 5 мин (непрерывный WAL) |
| Проверка восстановления | Ежеквартально, с протоколом |
Масштабируемость¶
[ТЗ] Масштабирование на ≥ 6 УЗ Бреста и района, до 60 % организаций здравоохранения областного центра.
| Требование | Реализация |
|---|---|
| Развёртывание в новом УЗ без изменения кода | Конфигурация в facilities, providers, departments |
| Новый вендор СМП/координат/МИС без изменения ядра | ACL-адаптеры (ADR-2) |
| Разные правила сортировки по УЗ | triage_rules.facility_id |
| Разные нормативы времени | facilities.settings |
| Рост числа коек и палат | Справочники wards, beds, field_devices |
Один экземпляр на УЗ, а не мультитенантность
[ПР] Каждое УЗ получает собственную инсталляцию с собственной БД — так требуют изоляция ПДн, аттестация на конкретную ИС и автономность при отказе внешних каналов. Поле facility_id в схеме присутствует для корректности модели и возможного будущего объединения отчётности, но не означает, что в одной БД живут несколько учреждений.
Наблюдаемость¶
| Что | Метрика |
|---|---|
| Приём сообщений | Число по типам, задержка обработки, доля ошибок, доля дубликатов |
| Нормализация | Доля сообщений с normalization_issues — рост означает рассинхронизацию с вендором |
| Координаты | Доступность источника, доля неуспешных опросов, давность позиций |
| Правила сортировки | Доля обращений «не покрыто правилами» — рост означает отставание правил от практики |
| Расхождения | Доля случаев, где оператор переопределил рекомендацию — материал для настройки правил |
| Очередь | Длина по цветам, время ожидания, число нарушений норматива |
| МИС | Доля успешных передач, глубина очереди повторов, время ответа | | БД | Размер партиций, время запросов, глубина репликации |
Две метрики, которые показывают деградацию раньше остальных
Доля normalization_issues и доля «не покрыто правилами» — индикаторы того, что система тихо перестаёт работать по назначению, продолжая формально функционировать. Вендор изменил справочник, или клиническая практика ушла вперёд — ошибок нет, данные принимаются, но ценность падает. Обе метрики должны быть на дашборде с порогами оповещения, а не доступны только по запросу.
Удобство использования¶
[ПР] Требования, выводимые из условий работы приёмного отделения.
| Требование | Обоснование |
|---|---|
| Экран сортировки — не более 6 полей на первом экране | Оценка выполняется быстро, часто стоя |
| Крупные элементы управления, работа в перчатках | Медицинская среда |
| Цвет не единственный носитель информации — дублируется кодом талона и текстом | Дальтонизм; цветовая система критична для маршрутизации |
| Отсутствие модальных окон, блокирующих поток | Прерывания — норма в приёмнике |
| Терминал самообращения — одна кнопка | Пациент в стрессе, возможно пожилой |
| Табло очереди читается с 5–7 м | ТВ 55″ в зале ожидания |
| Явная индикация устаревших данных | Никогда не показывать старое как актуальное |
Обучаемость — фактор провала предыдущих внедрений
[ТЗ] Одной из двух причин неудачи предыдущих попыток внедрения «Триажа» в РБ названа недостаточная подготовка кадров для работы с алгоритмами сортировки. Сложный интерфейс воспроизведёт эту причину независимо от качества бэкенда.
Требование к приёмке: медсестра, прошедшая базовое обучение, выполняет полный цикл сортировки самостоятельно, без обращения к инструкции.