Риски и открытые вопросы¶
Два раздела: риски — то, что может пойти не так; открытые вопросы — то, на что нужен ответ до реализации.
Карта рисков¶
quadrantChart
title Риски: вероятность × влияние
x-axis "Низкая вероятность" --> "Высокая вероятность"
y-axis "Низкое влияние" --> "Критическое влияние"
quadrant-1 "Управлять активно"
quadrant-2 "Держать под наблюдением"
quadrant-3 "Принять"
quadrant-4 "Планировать смягчение"
"R-1 вендор СМП": [0.75, 0.9]
"R-2 клинические правила": [0.8, 0.85]
"R-4 API МИС": [0.65, 0.9]
"R-8 один сервер": [0.4, 0.95]
"R-3 профиль FHIR РБ": [0.6, 0.55]
"R-5 КВОИ": [0.5, 0.5]
"R-6 учёт мест": [0.6, 0.45]
"R-7 определение КПЭ": [0.7, 0.5]
"R-12 сроки закупок": [0.6, 0.65]
"R-13 сопротивление персонала": [0.6, 0.8]Реестр рисков¶
| # | Риск | В | П | Смягчение | Задача |
|---|---|---|---|---|---|
| R-1 | Вендор МРМ СМП недоступен на стадии разработки. Паспорт помещает интеграцию с МРМ СМП в этап 3, а разработку «Триажа» — в этап 1. Без доступа к протоколу этап 1 нельзя ни завершить, ни протестировать | В | К | Симулятор вендора как поставляемый артефакт; сбор фикстур и контрактные тесты не требуют доступности вендора; раннее письменное согласование формата | E2-2, E2-10 |
| R-2 | Клинические правила сортировки не утверждены. Пороговые значения, нормативы времени выбытия по цветам и схема нумерации талонов не выводятся из документов и не могут быть определены разработчиком | В | К | Правила декларативны и версионируются (ADR-7) — систему можно строить до утверждения; но ввод в эксплуатацию без подписанных правил невозможен. Инициировать согласование с медперсоналом в первом квартале | E6-2, E12-6 |
| R-3 | Профиль HL7 FHIR Минздрава РБ не изучен. Образец сообщения использует российские OID (1.2.643); системы идентификации для РБ (1.2.112) должны браться из профиля по приказу МЗ РБ № 1001, а не подставляться по аналогии |
С | С | Получить профиль до реализации ACL; регистрация в FHIR-регистре подтвердит конформность | E2-6, E12-9 |
| R-4 | API МИС «Медик» может не покрывать нужные операции. Паспорт фиксирует, что доработка МИС не требуется, но передача обращения в МИС и справочные данные зависят от её API | В | К | Spike-исследование API до проектирования; при отсутствии — эскалация заказчику как изменение объёма | E5-1 |
| R-5 | Отнесение к КВОИ не выполнено. От результата зависит объём требований по защите информации | С | С | Проектировать по более строгому варианту: снизить требования дешевле, чем добавить после аттестации | E12-1 |
| R-6 | Источник данных о свободных местах не определён. Для ответа на transport_request нужен учёт коечного фонда: собственный в 3H или запрос в МИС |
С | С | Реализовать как решение оператора с подсказкой; таймаут → conditional. Автоматизировать после уточнения |
E3-1 |
| R-7 | Определение КПЭ «время ожидания» не зафиксировано. Разные трактовки дают разные числа при одинаковой работе, а показатель приёмочный | В | С | Согласовать определение и зафиксировать в частном ТЗ до начала измерений | E13-3 |
| R-8 | Одна серверная платформа. Отказ означает потерю приёма от СМП | Н | К | Проверяемый регламент восстановления | E11-10 |
| R-9 | Целевой браузер для 44 АРМ не зафиксирован. Терминалы поставляются с Windows 10 Pro; несовместимость всплывёт на приёмке | С | Н | Зафиксировать браузер и минимальную версию в частном ТЗ | E12-6 |
| R-10 | Задержка поставок оборудования и работ по разработке ПО. Названа в паспорте как наиболее существенный риск закупки | С | С | Разработка против симуляторов не блокируется поставкой; критический путь этапа 3 сокращён за счёт готовности интеграций | E2-2 |
| R-11 | Сопротивление персонала и недостаточная подготовка кадров. Прямо названа паспортом как причина неудачи предыдущих внедрений «Триажа» в РБ, включая пилот в ГКБСМП Минска | С | К | Программа изменений паспорта: регламентация, обучение, мотивация. Требование к UI: цикл сортировки выполняется без инструкции. Обучение — не остаточная задача | E12-12, E6-6 |
| R-12 | Потеря сообщения от СМП при недоступности 3H. Push-модель без гарантий доставки: если вендор не ретраит, данные о едущем пациенте теряются безвозвратно | С | В | 2xx только после записи в БД; согласовать с вендором политику повторов; детектор тишины на пульте |
E2-9, E3-9 |
В — вероятность, П — последствия. Н — низкая, С — средняя, В — высокая, К — критическая.
Риски, требующие решения раньше остальных¶
R-4 нужно закрыть до госзакупки этапа 2
R-4 (API МИС) — если API «Медик» не покрывает нужные операции, после закупки смягчение становится невозможным.
Открытые вопросы¶
К разработчикам ИС «МРМ бригады СМП»¶
| # | Вопрос | Блокирует |
|---|---|---|
| 1 | Какие поля п. 21.x передаются кодами справочника, а какие свободным текстом? | Использование поля в правилах сортировки |
| 2 | Какие справочники используются для «общего состояния», «сознания», «неврологического статуса»? | Нормализация в ACL |
| 3 | Передаётся ли аллергоанамнез структурно (AllergyIntolerance)? |
Безопасность назначений |
| 4 | Есть ли стабильный идентификатор сообщения для идемпотентности? | ADR-3 |
| 5 | Частота transport_health_status — фиксированная или по изменению? |
Ёмкость БД, партиционирование |
| 6 | ЭКГ (п. 21.18) — файл/изображение или текстовое заключение? | Схема хранения, Media |
| 7 | Какие системы идентификации (OID) используются для личного номера, бригады, медработника? | R-3 |
| 8 | Тип Bundle: transaction или message с MessageHeader? |
Маршрутизация обработки |
| 9 | Политика повторов при недоступности приёмной стороны | R-14 |
К заказчику и медицинскому персоналу УЗ¶
| # | Вопрос | Блокирует |
|---|---|---|
| 10 | Пороговые значения витальных показателей для красного и жёлтого | R-2, движок правил |
| 11 | Нормативное время выбытия из приёмника по каждому цвету | R-2, контроль SLA |
| 12 | Правило генерации номеров талонов К43 / В34 / П45 | Нумерация |
| 13 | Кто принимает решение по запросу госпитализации: система или оператор? | R-6 |
| 14 | Что считается «средним временем ожидания оказания медицинской помощи»? | R-7, приёмка |
| 15 | Время блокировки сессии по бездействию для разных типов рабочих мест | Требование ОАЦ vs. удобство |
| 16 | Сроки хранения медицинских данных по регламенту УЗ | Политики ретеншна |
К разработчикам АИС «Меди껶
| # | Вопрос | Блокирует |
|---|---|---|
| 19 | Как создаётся обращение в приёмный покой через API? | E5-3 |
| 20 | Как передаётся запрос на сбор бригады и её роспуск? | E5-4, E5-5 |
| 21 | Как МИС отдаёт структуру отделений, палат, коек? | Справочники |
К регулятору и службе ИБ¶
| # | Вопрос | Блокирует |
|---|---|---|
| 24 | Отнесена ли создаваемая ИС к КВОИ? | R-5, объём требований |
| 25 | К какому классу типовых ИС относится система? | E12-2 |
| 26 | Какие методы обезличивания ПДн признаются достаточными? | E11-6 |
| 27 | Требования ЕТТ, применимые к подсистемам ПАК | E12-8 |
| 28 | Требования профиля HL7 FHIR по приказу МЗ РБ № 1001 | R-3, E12-9 |
Расхождения между источниками¶
Обнаружены при сверке технического паспорта с операционными требованиями. Требуют разрешения, а не выбора «на усмотрение разработчика».
| # | Расхождение | Предлагаемое разрешение |
|---|---|---|
| 1 | Температура входит в набор оценки самообращений (операционные требования), но отсутствует в обязательном перечне данных СМП (паспорт) | Обязательна для самообращений, необязательна для СМП; правила должны работать при её отсутствии |
| 2 | AllergyIntolerance входит в обязательный набор данных СМП (п. 20 «Аллергия»), но отсутствует в перечне ресурсов обмена с ЦИСЗ |
Уточнить: добавить ресурс либо передавать в составе Composition |
| 3 | Паспорт называет вендора СМП — ИС «МРМ бригады СМП»; операционные требования говорят о нескольких поставщиках (Эрикполь, МАП, Лекарь) | Не противоречие: МРМ СМП — первый интегрируемый, мультивендорность — требование расширяемости для тиражирования |
| 4 | Паспорт фиксирует «доработка МИС не требуется», но работа системы зависит от её API | R-4; проверить и при необходимости эскалировать как изменение объёма |
| 5 | Интеграция с МРМ СМП отнесена к этапу 3, разработка «Триажа» — к этапу 1 | R-1; разработка на симуляторе |
Расхождения — не дефекты документов
Технический паспорт и операционные требования писались для разных целей: паспорт — для обоснования финансирования, операционные требования — для описания работы приёмного отделения. Разный уровень детализации закономерен. Проблема возникает только тогда, когда расхождение остаётся незамеченным и каждая сторона считает, что её понимание согласовано.