Разработка информационной системы учета медикаментов для пансионата

Введение

Автоматизация учета медикаментов в пансионате имеет прикладное значение, поскольку сотруднику необходимо одновременно контролировать наличие препаратов, индивидуальные назначения проживающих и своевременность пополнения запасов. В разработанной ВКР исходной проблемой является разрозненное ведение сведений, при котором связь «постоялец – препарат – остаток – заказ» требует повторного ручного ввода и пересчета. Цель проекта состоит в создании прикладного настольного средства, которое объединяет карточки проживающих, назначения препаратов, регистрацию приходов, расчет запаса в днях, прайс-лист и формирование закупочных заказов. Техническое задание предусматривает авторизацию, разграничение доступа по пансионатам и работу на ПК под управлением Windows [1].

Предметная область и требования

В отличие от обычного складского учета, центральной сущностью в рассматриваемой системе выступает проживающий. Один человек может иметь несколько назначений, причем одинаковое название препарата может использоваться для разных людей в различных дозировках и с разным суточным расходом. Поэтому сущность medications связана с residents через resident_id, а характеристики dose, per_day_dose и stock относятся к конкретному назначению. Такое построение соответствует реальному рабочему сценарию: сотрудник сначала выбирает проживающего, затем просматривает его назначения и принимает решение о пополнении или заказе.

Функциональные требования

К основным функциональным требованиям отнесены авторизация пользователя, разграничение доступа по ролям и пансионатам, поиск и редактирование карточек проживающих, ведение списка препаратов, расчет остатка с учетом суточного расхода, регистрация приходов, формирование заказов и ведение прайс-листа. Нефункциональные требования включают понятность интерфейса, защиту учетных данных, возможность восстановления соединения с БД, настольный запуск в Windows и модульность программного кода. Сформулированные требования связаны с конкретными компонентами проекта: авторизация реализована в AuthMixin, работа с проживающими и назначениями вынесена в ResidentsMixin и MedicationsMixin, а операции заказов, приходов и цен – в отдельные модули API.

Архитектура решения

Разработанное приложение построено как настольная программа на Python с использованием pywebview. Пользователь взаимодействует с HTML/CSS/JavaScript-интерфейсом, отображаемым в оконной оболочке, а JavaScript вызывает методы Python API через window.pywebview.api. Серверная часть представлена единым объектом Api в backend.py, который собирает специализированные mixin-классы. В системе выделены слои интерфейса, прикладного API и хранения данных. Такой подход позволяет разделить ответственность и не помещать логику всех предметных операций в один монолитный модуль. Выбор Python обусловлен простотой разработки и возможностью собрать программу в исполняемый файл; MySQL используется как реляционная СУБД, поддерживающая внешние ключи, индексы и транзакции [3, 4, 5, 6].

Структура данных

База данных построена по реляционной модели. В ней используются таблицы users, residents, medications, arrivals, prices, med_orders, med_order_patients и med_order_items. Таблица users содержит логин, хэш пароля, роль и доступ к пансионату. Таблица residents хранит ФИО, телефон, комнату, дату рождения и служебные сведения. Таблица medications содержит ссылку на проживающего, название препарата, дозировку, суточный расход и текущий остаток. История поставок отделена в arrivals, а цены хранятся в prices по сочетанию названия и дозировки. Заказ нормализован на три уровня, что позволяет сохранить связь между документом, проживающими и конкретными позициями [15, 16].

Поддержка нескольких пансионатов

Для поддержки нескольких пансионатов в текущей реализации используются префиксы таблиц. Общая таблица пользователей определяет доступ, а обычный пользователь работает только с назначенным объектом; администратор может переключаться между доступными пансионатами. Дополнительную целостность обеспечивают внешние ключи и каскадное удаление зависимых записей. Индексы предусмотрены для часто используемых поисковых полей – ФИО, телефона, названия препарата и дат приходов. Нормализованное поле телефона повышает устойчивость поиска к различиям в форматах записи.

Алгоритмы обработки

Ключевым расчетным механизмом является автоматическое списание суточного расхода. Для препарата хранится дата последнего списания. Если между ней и текущей датой прошло несколько дней, остаток уменьшается на произведение суточной дозы и количества прошедших дней. Значение stock не допускается ниже нуля. Если суточный расход не задан, препарат не участвует в автоматическом списании. Такой механизм позволяет переводить количество препарата в понятный сотруднику показатель запаса в днях и заранее выделять позиции, требующие закупки.

Приходы и формирование заказа

Поступления обрабатываются отдельно от текущего остатка. В таблице arrivals хранится дата, количество и признак применения is_applied. Заранее внесенный приход применяется только тогда, когда наступает соответствующая дата. Перед увеличением stock выполняется обновление с условием is_applied = 0, после чего количество прибавляется к остатку. Это предотвращает двойное применение одной поставки. Формирование заказа начинается с выбора проживающих, после чего система получает связанные назначения, создает шапку заказа, строки по людям и позиции препаратов, сопоставляет их с прайс-листом и сохраняет черновик. Пользователь может отредактировать количество перед печатью или дальнейшим внесением на склад.

Практическая реализация

Интерфейс разделен на устойчивые функциональные области: экран авторизации, список проживающих, панель подробностей, формы медикаментов, приходов, заказов и прайс-листа. Модуль app.core.js содержит общие функции вызова API, debounce, форматирования дат, маски телефона, уведомлений и подтверждений. Отдельные JavaScript-модули обслуживают авторизацию, проживающих, медикаменты, приходы, заказы и цены. Такая организация соответствует разделению Python API на предметные mixin-классы и упрощает сопровождение программы [11, 12, 13, 14].

Информационная безопасность

Защита реализуется на нескольких уровнях. Доступ к системе начинается с авторизации, после которой определяется роль и доступный пансионат. Пароли не должны храниться в открытом виде; в проекте предусмотрено хранение хэша. SQL-запросы выполняются с параметрами, что снижает риск SQL-инъекций при обработке пользовательского ввода. Разделение данных по пансионатам и ограничение доступных действий уменьшают риск случайного смешения записей. При эксплуатации дополнительно необходимы резервное копирование базы, разделение тестовой и рабочей среды и контроль учетных записей. Такие меры согласуются с общими принципами проверки безопасности прикладных систем [10].

Тестирование

В приложении проверялись как отдельные операции, так и последовательности действий пользователя. Тестовые сценарии включали успешный вход и обработку неверного пароля, добавление и редактирование проживающего, удаление карточки вместе с зависимыми препаратами, добавление назначения, расчет дефицита, массовый приход, создание и редактирование заказа, изменение цены и переключение пансионата. По материалам ВКР ожидаемые результаты этих сценариев подтверждают корректность основных рабочих цепочек. Для интерфейса также предусмотрены проверки с mock-api, а для оценки нагрузки использовался Locust; указанные инструменты входят в перечень средств тестирования проекта [7, 8, 9].

Заключение

Разработанная информационная система объединяет основные операции учета медикаментов в пансионате в единый программный контур. Использование связи «проживающий – назначение – остаток – заказ» позволяет учитывать индивидуальные особенности лекарственной терапии, а автоматическое списание и расчет запаса в днях снижают объем ручных операций. Архитектура на базе Python, pywebview, HTML/CSS/JavaScript и MySQL обеспечивает настольный сценарий работы и одновременно сохраняет модульность программного решения. Результаты ВКР показывают возможность дальнейшего расширения системы за счет отчетности, более детальной ролевой модели, загрузки прайс-листов поставщиков и интеграции с внешними информационными системами. Таким образом, поставленная цель – создание прикладного средства для автоматизации учета медикаментов – достигнута [1, 16].

Таблица

Основные функции разработанной системы