This commit is contained in:
nik
2025-10-17 17:54:44 +03:00
parent f986767c8b
commit 3e1aa3f134
8 changed files with 119 additions and 110 deletions

Binary file not shown.

View File

@@ -49,150 +49,147 @@
=== Цель работы. === Цель работы.
Изучение требований к информационной системе и использование методов их выявления для разработки проекта системы регистрации пациента в больнице. Изучение и формализация функциональных и нефункциональных требований к ИС, использование методов выявления требований и оформление их в виде глоссария, концепции и дополнительных спецификаций в соответствии с положениями ГОСТ 19.201-78 и ГОСТ 34.602-89.
=== Результаты. === Краткая концепция системы
==== 1. Общие сведения о требованиях Назначение системы: автоматизация процессов регистрации пациентов и учета их статуса в больнице, учёта платных услуг и ведения архива выписанных пациентов; формирование управленческих отчётов.
Требование к системе это условие или свойство, которому должна удовлетворять информационная система, чтобы удовлетворить потребности пользователей и соответствовать стандартам и техническим спецификациям. Цели создания: cнизить время регистрации пациента и нагрузку на регистратуру; исключить бумажный учёт, обеспечить быстрый поиск и хранение истории пациентов; обеспечить возможность формирования отчётов и печати необходимых документов; повысить точность учёта платных услуг и операций.
Стандарты для работы с требованиями: Пользователи: регистратура, лечащий врач, заведующий отделением, бухгалтер, администратор системы, медицинский архивариус.
- ГОСТ 19.201-78: Единая система программной документации. Техническое задание. Требования к содержанию и оформлению. === Глоссарий
- ГОСТ 34.602-89: Информационная технология. Техническое задание на создание автоматизированной системы. - Пациент физическое лицо, зарегистрированное в системе для получения медицинских услуг.
- Регистратура сотрудник, выполняющий первичную регистрацию и распределение пациентов.
- Отделение структурное подразделение больницы (кардиология, хирургия и т. п.).
- Палата место размещения пациента в отделении; имеет пол, количество коек.
- Выписной эпикриз документ, формируемый при выписке пациента, содержащий краткое описание лечения и результатов.
- Диагноз код/наименование диагноза, назначаемое врачом.
- Статус больного текущее состояние.
- Платная услуга услуга за отдельную плату.
- Операция хирургическое вмешательство; имеет дату/время, статус и осложнения.
- Отчёт данные по заданным метрикам.
- Архив данные о выписанных пациентах, сохраняемые для поиска и анализа.
Типы требований: === Методы выявления требований
- Функциональные описывают действия и поведение системы при обработке информации (что система должна уметь делать). Для построения требований рекомендуется использовать сочетание методов:
- Нефункциональные определяют атрибуты системы или её окружения: - Интервью с сотрудниками регистратуры, врачами, заведующими.
- Анкетирование персонала для сбора пожеланий по отчётности и интерфейсу.
- Моделирование и анализ текущих бизнес-процессов (регистрация, перевод, выписка).
- Сессии по выявлению требований (мозговой штурм с ключевыми стейкхолдерами).
- Прототипирование (демонстрация работающих прототипов экранных форм и отчётов пользователям) быстрая валидация интерфейса.
- требования к применению (качество ПО, документации), === Функциональные требования
- требования к производительности (время отклика, пропускная способность), ==== Общие функции системы
- требования к реализации (стандарты, языки программирования, операционная среда), - Учет и хранение данных пациентов.
- Поиск пациента по различным критериям.
- Журнал действий пользователей.
- Печать стандартных форм.
- Экспорт/импорт данных в стандартизованных форматах для обмена с другими системами.
- требования к надежности (частота сбоев, возможности восстановления), ==== Функции для регистратуры
- требования к интерфейсу (взаимодействие с внешними сущностями и регламент этого взаимодействия). - Зарегистрировать нового пациента.
- Определить пациента в отделение.
- Перевести пациента в другое отделение.
- Закрепить пациента в палате / койке.
- Выставить счет за платные услуги.
- Просмотр наличия свободных мест в палатах с возможностью фильтрации по отделению и дате.
- Распечатать документы регистрации и направления.
Методы выявления требований: ==== Функции для лечащего врача
- Собеседование (интервьюирование) - Назначить диагноз пациенту.
- Изменить/установить статус больного.
- Назначить лечение.
- Назначить процедуры.
- Назначить дату и время процедур.
- Назначить операцию.
- Назначить дату и время операции.
- Проставить статус операции.
- Назначить платные услуги.
- Выписать лекарственные средства.
- Выписать пациента.
- Создать выписной эпикриз.
- Анкетирование ==== Функции для заведующего отделением / администратора
- Моделирование и анализ бизнес-процессов - Сформировать отчёт о пропускной способности больницы.
- Сформировать отчёт по среднему времени пребывания больных в стационаре.
- Сформировать отчёт по операциям с осложнениями.
- Просмотр загрузки палат/коек и прогноз заполнения.
- Управление списком отделений, палат, типов процедур и платных услуг.
- Права доступа: назначение ролей и прав пользователей.
- Сессии по выявлению требований (мозговой штурм) ==== Функции для бухгалтера / платёжной подсистемы
- Создание и демонстрация работающих прототипов приложений - Вести учёт платных услуг, генерация счетов и историй оплат.
- Экспорт данных по начислениям для бухгалтерии.
- Маркировать оплату как оплачено/частично оплачено/отменено.
Документы для оформления требований: ==== Архив и отчётность
- Словарь предметной области (глоссарий) - Перенос выписанных пациентов в архив с возможностью поиска и восстановления.
- Формирование стандартных и настраиваемых отчётов.
- Сохранение истории изменений медицинской карты и назначений.
- Концепция системы === Нефункциональные требования
- Дополнительные спецификации (технические требования) ==== Требования к применению
==== 2. Глоссарий - Интерфейс должен быть доступен с минимальным обучением: обучение одного сотрудника не более 4 часов базового курса.
- Все основные операции не более 5 кликов/шагов.
- Формы ввода должны иметь валидацию и подсказки.
- Пациент человек, обращающийся в больницу за медицинской помощью. ==== Требования к производительности
- Регистратор сотрудник, оформляющий приём и регистрацию пациента. - Время отклика на основные операции не более 1.5 секунды при нагрузке до 50 одновременных пользователей.
- Поддержка одновременной работы до 200 пользователей в масштабируемой конфигурации при условии горизонтального масштабирования сервера.
- Формирование отчёта по пропускной способности за период до года не более 10 секунд.
- Врач медицинский работник, назначающий лечение и процедуры. ==== Требования к надёжности и доступности
- Заведующий отделением руководитель подразделения, контролирующий пропускную способность и отчёты. - Доступность системы 99.5%.
- Время восстановления после отказа не более 2 часов при наличии резервного оборудования/контейнеров.
- Потеря данных не более 15 минут.
- Логирование всех критических событий и операций.
- Бухгалтерия отдел финансового учёта больницы. ==== Требования к безопасности и конфиденциальности
- Отделение структурная единица больницы с палатами и койками. - Аутентификация пользователей по логину/паролю; поддержка двухфакторной аутентификации для администраторов.
- Ролевой доступ: разграничение прав.
- Шифрование данных в покое и при передаче.
- Соответствие требованиям защиты персональных данных: журналы доступа, удаление персональных данных по запросу, хранение истории изменений.
- Регулярное применение обновлений безопасности и патчей.
- Палата помещение для размещения одного или нескольких пациентов. ==== Требования к интерфейсу и совместимости
- Эпикриз выписной документ о состоянии пациента и проведённом лечении. - Веб-интерфейс, совместимый с современными браузерами последние 2 версии.
- API для интеграции с лабораторией, учетной системой и электронным архивом.
- Экспорт/импорт данных в CSV/XML/JSON.
==== 3. Концепция системы ==== Требования к эксплуатации и поддержке
Цель проекта: Создать информационную систему регистрации и сопровождения пациентов в больнице, обеспечивающую автоматизацию процесса приёма, размещения, лечения и выписки пациентов, а также ведение отчётности. - Документация: пользовательская инструкция, инструкция администратора, инструкция по резервному копированию/восстановлению.
- Система должна поддерживаться командой с 1 системным администратором и 1-2 разработчиками для сопровождения.
Основные возможности системы:
- Регистрация нового пациента === Cтадии разработки
- Определение отделения и палаты для пациента 1. Подготовительный этап / ТЗ сбор требований, разработка ТЗ, согласование.
2. Проектирование архитектура системы, модель данных, UX/UI прототипы.
3. Разработка разработка модулей регистрации, врачебных функций, отчётов, платёжной подсистемы.
4. Тестирование модульное, интеграционное, приёмочное тестирование с участием пользователей.
5. Внедрение и обучение развертывание в продуктиве, обучение персонала.
6. Сопровождение поддержка, исправление ошибок, доработка по результатам эксплуатации.
- Перевод пациента в другое отделение === Выводы:
- Выставление счета за услуги Проведён анализ предметной области и описание назначение ИC. Сформирован глоссарий терминов, определены роли пользователей. Составлены детальные функциональные требования по ролям. Описаны нефункциональные требования с конкретными метриками. Подготовлены дополнительные технические спецификации. Разработан план стадий разработки и критерии приёмки в соответствии с ГОСТ 19.201-78 и ГОСТ 34.602-89.
- Просмотр наличия свободных мест
- Назначение диагноза, статуса, лечения, процедур и операций
- Назначение платных услуг и выписка лекарств
- Создание выписного эпикриза
- Формирование отчётов по пропускной способности, среднему времени пребывания, осложнениям при операциях
==== 4. Функциональные требования
- Регистратура:
- Зарегистрировать нового пациента
- Определить пациента в отделение
- Перевести пациента в другое отделение
- Закрепить пациента в палате
- Выставить счет за услуги
- Просматривать наличие свободных мест (мужские/женские)
- Врач:
- Назначить диагноз
- Проставить статус больного
- Назначить лечение
- Назначить процедуры
- Назначить дату и время процедур
- Назначить операцию
- Проставить статус операции
- Назначить платные услуги
- Выписать лекарственные средства
- Выписать пациента
- Создать выписной эпикриз
- Заведующий отделением:
- Формировать отчёты о пропускной способности
- Формировать отчёты по среднему времени пребывания
- Формировать отчёты по операциям с осложнениями
==== 5. Нефункциональные требования
Производительность: Время отклика системы при регистрации не более 2 секунд; пропускная способность до 100 регистраций в день.
Надёжность: Система должна иметь резервное копирование данных; допускается не более 1 сбоя в месяц.
Юзабилити: Интерфейс должен быть удобен для быстрого ввода данных регистратором и врачом.
Документация: Система сопровождается руководством пользователя и технической документацией.
Интерфейс: Возможность взаимодействия с внешними системами (например, финансовый учёт, склад лекарств).
==== 6. Дополнительные спецификации
Система реализуется в виде веб-приложения.
Используемая СУБД PostgreSQL.
Язык программирования: Python (backend) и JavaScript (frontend).
Поддержка многопользовательского режима с разграничением прав доступа.
=== Выводы
В ходе выполнения работы были изучены методы выявления требований к информационной системе, разработан глоссарий предметной области, концепция и функциональные/нефункциональные требования для проекта «Система регистрации пациента в больнице».
В результате проделанной работы получен полный набор требований, позволяющий строить дальнейшие модели системы, проектировать интерфейсы и готовить техническое задание для реализации.

3
labs/lab4/assets/5.svg Normal file

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 29 KiB

3
labs/lab4/assets/6.svg Normal file

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 37 KiB

3
labs/lab4/assets/7.svg Normal file

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 21 KiB

3
labs/lab4/assets/8.svg Normal file

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 26 KiB

Binary file not shown.

View File

@@ -63,7 +63,7 @@
Механизмы: персонал регистратуры, лечащие врачи, заведующий отделением, бухгалтерия, система. Механизмы: персонал регистратуры, лечащие врачи, заведующий отделением, бухгалтерия, система.
Управляющие воздействия: внутренние регламенты больницы, стандарты оформления, нормативные документы. Управляющие воздействия: внутренние регламенты больницы, стандарты оформления, нормативные документы.
#align(center)[#image("assets/1.png")] #align(center)[#image("assets/5.svg")]
2. Основные процессы проекта IDEF0. 2. Основные процессы проекта IDEF0.
@@ -101,7 +101,7 @@
- A4: Формирование отчетов - A4: Формирование отчетов
#align(center)[#image("assets/2.png")] #align(center)[#image("assets/6.svg")]
6. Декомпозиция уровня А-2 6. Декомпозиция уровня А-2
@@ -117,7 +117,7 @@
- A2.3: Выписка пациента - A2.3: Выписка пациента
#align(center)[#image("assets/3.png")] #align(center)[#image("assets/7.svg")]
==== Часть 2. Моделирование в нотации IDEF3. ==== Часть 2. Моделирование в нотации IDEF3.
@@ -131,7 +131,7 @@
- Взаимодействие с заведующим отделением для формирования отчетов - Взаимодействие с заведующим отделением для формирования отчетов
#align(center)[#image("assets/4.png")] #align(center)[#image("assets/8.svg")]
8. Основные информационные потоки и отношения 8. Основные информационные потоки и отношения