Опубликовано: 22.09.2026 | Источник: CNews (новости)

МИС qMS 25.2 в ВКР: интерфейс, интеграция и метрики управления клиникой

25 марта 2026 года компания «СП.АРМ» выпустила релиз медицинской информационной системы qMS 25.2 — с переработанным интерфейсом и расширенным функционалом управления клиникой. Для выпускника направления «Прикладная информатика», «Программная инженерия» или «Информационные системы в здравоохранении» это не просто новость отрасли, а готовый полигон для исследования: релиз показывает, как требования клиник превращаются в модули, как обновляется интерфейс без остановки работы регистратуры и как измерять эффект от внедрения. Медицинские информационные системы (МИС) — один из немногих доменов, где ВКР автоматически получает и прикладную ценность, и строгие требования к защите персональных данных. Ниже — разбор того, что из этого кейса стоит перенести в диплом и как это оформить без пересдачи.

Частые вопросы студентов по теме МИС

Можно ли исследовать qMS, если система закрытая и доступа к ней нет?

Можно, и это нормальная практика. В главе 1 вы анализируете публичные материалы: релиз-ноты, обзоры рынка МИС, документацию вендора, отраслевые требования Минздрава. Объект исследования — класс систем и подходы к их построению, а не исходный код конкретного продукта. Практическую часть делайте на собственном прототипе модуля (расписание, карточка пациента, интеграционный шлюз) и честно опишите ограничения: «реализация выполнена в виде прототипа, покрывающего ключевой сценарий».

Какой стек выбрать для прототипа, чтобы комиссия не спросила «а почему это»?

Главное — обоснование, а не модность. Рабочая связка для МИС-прототипа: PostgreSQL (транзакции, целостность), backend на Django/Spring Boot/Laravel, REST API, JWT-аутентификация, ролевая модель доступа, фронтенд на Vue или React. В тексте ВКР добавьте подраздел «Обоснование выбора технологий» с таблицей сравнения по 3–4 критериям: скорость разработки, наличие готовых библиотек, требования к безопасности, порог входа в команде.

Где брать данные для расчёта эффективности внедрения?

Три законных источника: синтетические данные, сгенерированные по правилам предметной области; обезличенные выгрузки с предприятий-партнёров (без ФИО, полиса, адреса); хронометраж собственного прототипа по логам. Формула эффекта не обязана быть «настоящей» — она обязана быть прозрачной: N приёмов × Δt на операцию × стоимость минуты рабочего времени. Все допущения выносите в приложение.

Насколько глубоко нужно прорабатывать 152-ФЗ и защиту данных в дипломе?

Достаточно уровня проектных решений: классификация данных, разграничение доступа, журналирование действий пользователя, шифрование канала, регламент резервного копирования. Отсылки к 152-ФЗ обязательны, но аттестацию системы вы не проводите — прямо напишите это в разделе «Ограничения исследования».

Темы ВКР: три варианта на базе релиза 25.2

• Тема 1. «Разработка модуля управления потоком пациентов в медицинской информационной системе»

  Актуальность: в релизе qMS 25.2 заявлен обновлённый интерфейс и расширенные возможности управления клиникой — значит, меняются пользовательские сценарии регистратуры и приёма. Это прямой повод исследовать, как интерфейс влияет на время обслуживания.

  Цель: сократить время записи и маршрутизации пациента за счёт переработанного модуля расписания.

  Задачи: 1) проанализировать бизнес-процесс записи AS-IS; 2) сформулировать требования к модулю; 3) спроектировать модель данных и API; 4) реализовать прототип; 5) провести нагрузочное и юзабилити-тестирование.

  Структура: Глава 1 — анализ предметной области и аналогов; Глава 2 — проектирование и реализация модуля; Глава 3 — тестирование и оценка эффективности.

• Тема 2. «Проектирование интеграционного шлюза МИС с лабораторной и радиологической подсистемами»

  Актуальность: расширенный функционал управления клиникой почти всегда упирается в обмен данными с ЛИС и РИС. Обмен строится на HL7 FHIR и DICOM — сегодня это отраслевой стандарт.

  Цель: обеспечить автоматический обмен заказами и результатами между МИС и внешними подсистемами без ручного ввода.

  Задачи: 1) описать сценарии обмена; 2) выбрать формат сообщений; 3) спроектировать сервис-посредник; 4) реализовать обработку ошибок и повторную доставку; 5) измерить долю успешных обменов.

  Структура: Глава 1 — стандарты интероперабельности в здравоохранении; Глава 2 — архитектура шлюза и реализация; Глава 3 — отказоустойчивость и метрики интеграции.

• Тема 3. «Разграничение доступа и аудит действий пользователей в медицинской информационной системе»

  Актуальность: чем больше функций в релизе, тем шире поверхность нарушений доступа к персональным данным. МИС — классический объект для проверки ролевой модели.

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

  Задачи: 1) классифицировать данные и роли; 2) разработать матрицу доступа; 3) реализовать проверку прав и журналирование; 4) провести тесты на обход прав; 5) оценить накладные расходы на аудит.

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

Как встроить материал статьи в главы ВКР

Глава 1: аналитика, а не пересказ новости

Релиз 25.2 здесь — точка отсчёта. Схема подачи: фиксируете состояние рынка МИС, описываете типовые функции (регистратура, расписание, электронная карта, лаборатория, отчётность) и показываете, какие из них затронуты в обновлении. Диаграммы, которые ждёт комиссия: контекстная диаграмма по C4 (клиника, регистратура, врач, лаборатория, внешние сервисы) и BPMN-схема процесса «первичный приём пациента» в вариантах AS-IS и TO-BE. Стадии работ оформляйте по ГОСТ 34.601 — это снимает половину вопросов нормоконтроля. Критерии сравнения аналогов берите не «нравится/не нравится», а из ISO/IEC 25010: функциональная полнота, производительность, удобство использования, безопасность.

Контекст (C4, уровень 1) — текстовое представление:

[Пациент] --> (Регистратура) --> [МИС]
[Врач] --> (Рабочее место врача) --> [МИС]
[МИС] --> (Интеграционный шлюз) --> [ЛИС] : заказ/результат
[МИС] --> (Интеграционный шлюз) --> [РИС] : снимок/заключение
[МИС] --> (Подсистема отчётности) --> [Руководитель]
[МИС] --> (Журнал аудита) <-- (Администратор ИБ)

Глава 2: проектирование и реализация

Здесь отвечаете на вопрос «как это сделано». Минимальный набор артефактов: диаграмма компонентов (UML), схема базы данных в третьей нормальной форме, спецификация REST API, матрица ролей. Матрицу удобно показать таблицей: строки — роли (врач, медсестра, регистратор, заведующий отделением, администратор), столбцы — сущности (карточка пациента, расписание, результаты анализов, отчёты). Для проверки прав подойдёт декларативный подход — правила описываются отдельно от кода и легко демонстрируются на защите.

# policy/rbac.rego — доступ к карточке пациента
package mis.rbac

default allow = false

allow {
  input.action == "read"
  input.resource == "patient_card"
  input.role == "doctor"
  some dept in input.user.departments
  dept == input.patient.department
}

allow {
  input.action == "read"
  input.resource == "patient_card"
  input.role == "registrar"
}

Обмен с внешними системами описывайте через REST-профиль HL7 FHIR: ресурсы Patient, ServiceRequest, DiagnosticReport. Даже если в прототипе вы реализуете два-три ресурса, структура главы станет «взрослой», а в выводах появится корректная фраза о расширяемости подсистемы.

Глава 3: метрики, которые действительно защищаются

Слабое место почти всех ВКР по МИС — качественная оценка вместо количественной. Считайте измеримое. Ниже — набор метрик, который покрывает требования ISO/IEC 25010 и при этом собирается на прототипе.

Сбор метрик описывайте через OpenTelemetry: единый формат трассировки, метрик и логов избавляет от ручного сведения данных в Excel. Проверку безопасности стройте по чек-листу OWASP: контроль доступа на уровне объектов, инъекции, небезопасная конфигурация, недостатки журналирования.

-- Метрика P95 по времени отклика API за отчётный период
SELECT
  endpoint,
  percentile_cont(0.95) WITHIN GROUP (ORDER BY duration_ms) AS p95_ms,
  count(*) FILTER (WHERE status >= 500) * 100.0 / count(*) AS error_rate_pct
FROM api_spans
WHERE ts >= now() - interval '30 days'
GROUP BY endpoint
ORDER BY p95_ms DESC;

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

• Формализовать требования к медицинской системе и оформлять ТЗ по ГОСТ 34.602.
• Проектировать ролевую модель доступа с журналированием действий пользователя.
• Строить интеграцию с внешними подсистемами через FHIR/REST и обрабатывать сбои обмена.
• Собирать и защищать метрики производительности и надёжности, а не «оценивать на глаз».
• Считать эффект от внедрения в человеко-часах и рублях с прозрачными допущениями.

Источник: «СП.АРМ» выпустила МИС qMS 25.2 с новым интерфейсом и расширенным функционалом для управления клиникой (опубликовано 2026-03-25)