Описание процессов, обеспечивающих поддержание жизненного цикла программного обеспечения

Программное обеспечение MedApp. Правообладатель — ООО «ВИСМУТ».

1. Общие положения

Настоящий документ определяет порядок и процессы, обеспечивающие поддержание жизненного цикла программного обеспечения «MedApp» (далее — ПО) в период его коммерческой эксплуатации, включая устранение неисправностей, выпуск обновлений, техническое сопровождение конечных пользователей (медицинских организаций) и совершенствование функциональных возможностей продукта.

2. Порядок устранения неисправностей, выявленных в ходе эксплуатации (техническая поддержка)

2.1. Порядок приема и регистрации обращений

Устранение несоответствий и техническая поддержка конечных пользователей осуществляются специализированным Сервисным центром правообладателя (ООО «ВИСМУТ»).

• Каналы связи: Заявки принимаются от уполномоченных представителей пользователей по телефону горячей линии или по электронной почте.
• Время обслуживания: Прием экстренных обращений по телефону ведется круглосуточно в режиме 24х7, обработка писем по электронной почте и консультации осуществляются в режиме 12х7 (с 08:00 до 18:00 по часовому поясу UTC+5).
• Автоматизация: Каждому обращению в автоматизированной информационной системе (АИС) правообладателя присваивается уникальный номер, а пользователю отправляется email-уведомление.

2.2. Регламентные сроки устранения неисправностей (SLA)

Все поступающие заявки классифицируются по четырем уровням приоритета в зависимости от степени влияния на работоспособность ПО. ООО «ВИСМУТ» гарантирует соблюдение следующих нормативных сроков реакции и исправления:

Способы обработки и устранения дефектов осуществляются специалистами Сервисного центра дистанционно (по телефону) или удаленно (с использованием защищенных каналов удаленного доступа к компонентам API-шлюза).

3. Порядок совершенствования и модернизации ПО

Правообладатель осуществляет непрерывное развитие ПО с целью расширения его функциональных возможностей, оптимизации быстродействия и адаптации под изменяющиеся требования нормативно-правовых актов Минздрава РФ.

3.1. Этапы выпуска релизов и обновлений

Процесс модернизации софта является циклическим итерационным процессом, контролируемым руководителем проекта ООО «ВИСМУТ». Каждый цикл включает:

1.Сбор требований и проектирование: Формирование списка высокоуровневых задач (User Story) на основании анализа запросов от медицинских учреждений.

2.Разработка и сквозное тестирование: В процессе написания обновлений программный код проходит обязательный многоступенчатый контроль качества в автоматическом и ручном режимах:

• Автоматическое модульное (Unit) тестирование с покрытием публичных методов класса.
• Функциональное и интеграционное тестирование на выделенных тестовых стендах для проверки взаимодействия модулей со смежными МИС.
• Нагрузочное тестирование (с использованием инструментов Apache JMeter) перед непосредственным формированием выпуска.

3.2. Классификация и нумерация версий ПО

Все выпускаемые обновления разделяются на три типа в зависимости от масштаба изменений:

• Значимый релиз: Выпуск новой версии продукта при появлении крупных функциональных блоков или полной переработке интерфейса.
• Малый релиз: Плановое развитие текущих функций, рефакторинг кода и плановые исправления.
• Оперативный релиз (Hotfix): Срочный выпуск пакета исправлений при обнаружении критических дефектов.

Каждому обновлению присваивается уникальный сквозной идентификатор формата XXX.YYY.ZZZ.DDD (где XXX — номер значимого релиза, YYY — малого, ZZZ — оперативного, DDD — код промежуточной сборки).

4. Порядок распространения обновлений и информирования пользователей

4.1. Автоматизация сборки артефактов

Все дистрибутивы, инсталляционные пакеты серверных шлюзов и сборки мобильных приложений подготавливаются в ООО «ВИСМУТ» автоматически с использованием сервера непрерывной интеграции, что исключает человеческий фактор и гарантирует повторяемость результатов.

4.2. Порядок доставки обновлений

• Обновление серверной части (API-шлюза): Развертывание обновлений структуры базы данных PostgreSQL и модулей MedApp.Gateway на серверах медицинских организаций производится ИТ-специалистами ООО «ВИСМУТ» в рамках регламентного обслуживания.
• Обновление клиентской части: Новые версии мобильного приложения для смартфонов и планшетов публикуются правообладателем в магазинах приложений RuStore, Google Play и App Store, откуда пользователи скачивают и устанавливают их автоматически или в ручном режиме.

4.3. Информирование пользователей

После публикации новой версии софта Исполнитель производит обязательную email-рассылку уполномоченным представителям медицинских организаций. К письму прикладывается Сопроводительный документ релиза, содержащий номер и дату выхода версии, цели обновления, полный список добавленных функций и исправленных ошибок, а также дополнительные инструкции по настройке.

Регламент процесса проведения тестирования программного обеспечения

Программное обеспечение MedApp. Правообладатель — ООО «ВИСМУТ».

1. Общие сведения

1.1. Термины и определения

1.2. Цель процесса проведения тестирования ПО

Целью процесса проведения тестирования ПО является обеспечение стабильно высокого качества новых версий программных продуктов, за счет проведения тестирования выпускаемых версий ПО, выполняемого в автоматическом и ручном режимах.

1.3. Область действия Регламента

Действие регламента распространяется на все программные продукты, выпускаемые компанией.

1.4. Основные принципы регулирования Регламента

Для достижения целей процесса управления разработкой ПО должны соблюдаться следующие базовые принципы:

• Следование требованиям, определенным данным регламентом, на каждом этапе процесса.
• Информированность сотрудников подразделения разработки компании о наличии регламента, а также о внесении в него изменений.
• Регулярный пересмотр и внесение изменений в регламент, направленных на оптимизацию работы процесса.

1.5. Участники процесса

В процессе проведения тестирования участвуют следующие специалисты:

• тестировщики, специалисты группы тестирования – специализированного подразделения, в задачи которого входит разработка методики, технологии и собственно проведение тестирования с целью контроля качества, разрабатываемого ПО;
• разработчики и аналитики в составе группы разработки выполняют тестирование в рамках выполнения своих непосредственных обязанностей;
• аналитики, специалисты предметной области, привлекаются к тестированию с целью определения корректности работы прикладных модулей.

2. Режимы и виды тестирования ПО

В рамках работ по выпуску релизов ПО тестирование выполняется в следующих режимах:

• автоматическое Unit-тестирование, выполняется на основании разработанных Unit-тестов в процессе автоматической сборки;
• автоматическое функциональное тестирование, выполняющееся сервером автоматической сборки с заданной периодичностью;
• ручное регрессионное функциональное тестирование выполняется однократно с использованием актуальной Программы и методике испытаний (ПМИ) перед выпуском релиза;
• нагрузочное тестирование, выполняется однократно перед выпуском релиза.

Функциональное тестирование проводится при добавлении новой или изменении существующей функциональности, с целью проверки доработанного программного обеспечения новым или измененным функциональным требованиям. Функциональное тестирование может проводиться как в ручном, так и в автоматическом режиме.

Нагрузочное тестирование проводится с целью выявить соответствие ПО требованиям производительности, определения пиковой и средней нагрузки, стабильности системы в целом.

Регрессионное тестирование проводится с целью проверки устойчивой работы обновленной версии с учетом новой функциональности и/или исправления дефектов. Регрессионное тестирование может проводиться как в ручном, так и в автоматическом режиме.

Интеграционное тестирование проводится в случае необходимости провести проверку корректности взаимодействия смежных систем друг с другом.

Регрессионное и интеграционное тестирование выполняются в ходе проведения функционального тестирования в автоматическом и ручном режимах.

Работы по проведению функционального, интеграционного и регрессионного тестирования осуществляют специалисты группы тестирования или группы разработки.

3. Порядок проведения тестирования

3.1. Автоматическое Unit-тестирование

Для проведения Unit-тестирования разработчики создают Unit-тесты с использованием специализированных фреймворков (JUnit, NUnit и т.д.). Unit-тесты создаются по факту внесения любых изменений в программный код, с целью подтверждения корректности работы выполненных изменений, а также отсутствия негативного влияния сделанных изменений на другие модули программной системы.

Как минимум, Unit-тесты должны покрывать все публичные методы модуля (класса).

Unit-тест запускается разработчиком для проверки корректности разработанного программного кода.

Все разработанные Unit-тесты запускаются в пакетном режиме сервером непрерывной интеграции в процессе выполнения сборки, после размещения изменений программного кода в системе управления версиями ПО. Сборка считается выполненной успешно только после успешного выполнения полного пакета Unit-тестов.

3.2. Автоматическое функциональное тестирование

Для проведения автоматического функционального тестирования специалистами группы тестирования создаются тесты с использованием специализированных средств для разработки функциональных тестов.

В рамках функционального тестирования выполняется проверка корректности работы функций пользователя, как каждой в отдельности, так и при их совместной работе, например, в рамках автоматизации бизнес-процесса.

В рамках автоматического функционального тестирования также проводится проверка корректности работы интерфейса пользователя.

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

3.3. Ручное функциональное тестирование

Ручное функциональное тестирование выполняется в целях, аналогичных автоматическому, но тестирование проводят специалисты группы тестирования на основании ПМИ.

К ручному функциональному тестированию, также могут быть привлечены аналитики группы разработки и бизнес-аналитики в рамках проверки корректности работы прикладных модулей.

3.4. Нагрузочное тестирование

Нагрузочное тестирование выполняется с целью проверки соответствия выпускаемой версии ПО показателям назначения, определенным в Техническом задании, в части производительности и устойчивости к нагрузкам.

Нагрузочное тестирование выполняется с использованием нагрузочных тестов, разработанных с использованием специализированного программного обеспечения (Apache JMeter и т.д.) специалистами группы тестирования.

Запуск тестов может выполняться в ручном режиме, в ходе мероприятий по выпуску релизов, а также в автоматическом режиме по расписанию с использованием сервера непрерывной интеграции.

4. Разработка и актуализация Программы и методики испытаний

Разработку и/или актуализацию ПМИ при выпуске очередного релиза инициирует руководитель проекта. Доработка ПМИ выполняется аналитиком группы разработки.

Актуализация ПМИ проводится аналитиком группы разработки по результатам внесения изменений в ПО перед выпуском новой версии ПО.

В состав ПМИ должны входить задачи, выполненные на момент завершения работы над текущей версией ПО.

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

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

Программное обеспечение MedApp. Правообладатель — ООО «ВИСМУТ».

1. Общие сведения

1.1. Термины и определения

1.2. Цель процесса управления разработкой ПО

Целью процесса управления разработкой ПО является обеспечение стабильно высокого качества новых версий программных продуктов, за счет применения организационных и технических мер, определенных данным регламентом.

1.3. Область действия Регламента

Действие регламента распространяется на все программные продукты, выпускаемые компанией.

1.4. Основные принципы регулирования Регламента

Для достижения целей процесса управления разработкой ПО должны соблюдаться следующие базовые принципы:

• Следование требованиям, определенным данным регламентом, на каждом этапе процесса.
• Информированность сотрудников подразделения разработки компании о наличии регламента, а также о внесении в него изменений.
• Регулярный пересмотр и внесение изменений в регламент, направленных на оптимизацию работы процесса управления релизами.

2. Стадии (этапы) процесса разработки

Процесс разработки является итерационным процессом. Результатом каждой итерации должна являться готовая, отделяемая от разработчиков, версия продукта. Каждая итерация включает следующие этапы работы:

• определение требований,
• проектирование,
• разработка и тестирование,
• выпуск релиза (версии, продукта).

3. Общий порядок действий в ходе выполнения фазы (этапа) проекта

3.1. Определение требований

На этапе определения требований представители команды разработки выполняют обследование объекта автоматизации при взаимодействии с представителями заказчика – специалистами предметной области.

Собранные в результате обследования сведения об объекте автоматизации должны быть формализованы с использованием средств моделирования, используемых командой разработки.

Результатом этапа определения требований должны являться следующие документы:

1.Протоколы проведения обследования объекта автоматизации. Протоколы должны быть согласованы с представителями заказчика.

2.Формализованное описание результатов обследования. Примером формализованного описания является представление требований в виде диаграммы прецедентов (Use Case) языка UML.

3.Техническое задание (разделы технического задания), согласованные с представителями заказчика.

На этом этапе должны быть определены цели и задачи, которые должно выполнять разрабатываемое программное обеспечение (ПО), а также запланированы способы проверки выполняемых ПО функций.

Формы согласования с заказчиком должны обеспечивать впоследствии возможность доказательства достигнутых договоренностей (подписанные бумажные документы, электронная почта и пр.).

На этапе определения требований должны использоваться следующие средства автоматизации процесса разработки:

• система управления задачами, для фиксации задач по обследованию и определению требований,
• система внутреннего документирования проекта, для хранения полученных требований в формализованном виде.

3.2. Проектирование

На этапе проектирования командой разработки разрабатываются проектные решения, реализующие требования, определенные на предыдущем этапе.

Разработка проектных решений выполняется в следующей последовательности:

1.Разработка высокоуровневого описания постановки задачи, которое должно содержать описание поведения, разрабатываемого ПО, описание бизнес- процессов и бизнес-ролей, состав функций, которые необходимо реализовать и т.д. Формальное описание алгоритмов и функций может быть выполнено в виде нотации BPMN, IDEF, диаграмм активностей, последовательности и состояний языка UML.

2.Разработка архитектуры ПО: состав компонентов, определение информационных потоков и т.д.

3.Определение состава задач для разработки. Задачи для разработки должны удовлетворять следующим требованиям:

a.Являться результатом декомпозиции высокоуровневых остановок задач.

b.Должны содержать конкретные постановки для реализации нового функционала разработчиками.

c.Задачи должны быть распределены на итерации, составляющие план выполнения разработки ПО, его версии или релиза.

4.Определение программных платформ, языков программирования, необходимость использования дополнительных сторонних библиотек.

5.Проведение подготовки к этапу разработки.

На этапе проектирования решения вырабатываются и принимаются архитектором системы, ведущими разработчиками, а также в результате совместных обсуждений с участием всех участников разработки. Результаты решений обязательно фиксируются в системе внутреннего документирования и системе управления задачами.

Результатом этапа определения требований должны являться следующие документы:

1.Общие постановки задач, включая схемы и диаграммы в перечисленных выше нотациях в системе внутреннего документирования.

2.Задачи для разработки создаются в системе управления задачами.

3.Необходимый набор документов Технического проекта согласно ГОСТ 34. Разработка документации Технического проекта должна проводиться на основании заранее подготовленных шаблонов документов. При необходимости документация Технического проекта согласуется с заказчиком ПО.

На этапе определения требований должны использоваться следующие средства автоматизации процесса разработки:

• система управления задачами, для создания задач разработчикам, проведения планирования итераций,
• система внутреннего документирования проекта, для хранения результатов проектирования ПО.

При проведении подготовки к этапу разработки должны быть подготовлены:

• проект в системе управления задачами,
• проект в системе управления версиями,
• базовая инфраструктура среды разработки, включая необходимый набор проектов, классов, стандартных и общих библиотек и других компонент, позволяющих осуществить сборку приложения, инфраструктура должна быть размещена в системе управления версиями,
• проект в системе непрерывной интеграции,
• стенды для тестирования разработанного ПО, моделирующие ИТ-инфраструктуру заказчика.

3.3. Разработка и тестирование

Процесс разработки должен быть дискретным и поделен на итерации длительностью от двух до четырех недель. Каждый этап должен заканчиваться выпуском следующей версии. Каждая версия должна содержать набор работоспособных компонент, которые могут быть представлены заказчику в качестве прототипа системы.

Для программных компонентов, вошедших в выпускаемую версию, должны выполняться следующие правила:

• компоненты должны корректно выполнять определенные в описании версии функции;
• программный код, реализующий указанные компоненты, должен иметь 100% покрытие тестами (т.е. все публичные методы должны иметь тесты, проверяющие работоспособность, как с корректными, так и с некорректными данными);
• тесты должны быть пригодны для автоматического тестирования и выполнены согласно технологии JUnit, NUnit;
• программный код должен иметь комментарии. Как минимум должны быть комментарии классов и публичных методов. Синтаксис комментария должен соответствовать правилам формирования комментария для систем автоматической сборки документации, характерной для платформы программирования;
• все задачи, запланированные в данной версии, должны быть зафиксированы в системе управления задачами, при этом для завершенных задач должен присутствовать подробный комментарий с описанием внесенных изменений;
• весь программный код должен быть размещен в системе управления версиями;
• результат сборки должен быть доступен из системы непрерывной интеграции;
• новая версия должна быть развернута на тестовом стенде.

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

3.4. Выпуск релиза (версии, продукта)

Процедура выпуска релизов подробно описана в документе «Регламент управления релизами».

4. Средства автоматизации процесса разработки

Основной целью внедрения средств автоматизации процесса разработки является обеспечение высокого качества результатов разработки программного обеспечения и повышение эффективности работы команды разработки.

Внедрение средств автоматизации процесса разработки обеспечивает выполнение следующих показателей качества результатов работы команды разработки:

• стабильность и устойчивость работы выпускаемых программных продуктов,
• соблюдение сроков разработки,
• повторяемость результатов (возможность повторного использования компонент в других проектах),
• полнота документирования (информации в документах достаточно для самостоятельного изучения).

Средства автоматизации процесса разработки должны удовлетворять следующим требованиям:

• Должна быть возможность интеграции средств автоматизации процесса разработки с системами разработки (IDE).
• Внедрение средств автоматизации процесса разработки должно обеспечивать:
• исключение многократной отчетности участников проекта,
• автоматизацию рутинных процессов,
• документирование всех этапов и артефактов проекта,
• унификацию подходов к выполнению критичных этапов проекта (сборка, тестирование, контроль и т.д.),
• реализацию эффективных методов оценки результативности команды и ее членов

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

Программное обеспечение MedApp. Правообладатель — ООО «ВИСМУТ».

1. Общие сведения

1.1. Термины и определения

1.2. Цель процесса управления разработкой ПО

Целью процесса управления разработкой ПО является обеспечение стабильно высокого качества новых версий программных продуктов, за счет применения организационных и технических мер, определенных данным регламентом.

1.3. Область действия Регламента

Действие регламента распространяется на все программные продукты, выпускаемые компанией.

1.4. Основные принципы регулирования Регламента

Для достижения целей процесса управления разработкой ПО должны соблюдаться следующие базовые принципы:

• Следование требованиям, определенным данным регламентом, на каждом этапе процесса.
• Информированность сотрудников подразделения разработки компании о наличии регламента, а также о внесении в него изменений.
• Регулярный пересмотр и внесение изменений в регламент, направленных на оптимизацию работы процесса управления релизами.

2. Стадии (этапы) процесса разработки

Процесс разработки является итерационным процессом. Результатом каждой итерации должна являться готовая, отделяемая от разработчиков, версия продукта. Каждая итерация включает следующие этапы работы:

• определение требований,
• проектирование,
• разработка и тестирование,
• выпуск релиза (версии, продукта).

3. Общий порядок действий в ходе выполнения фазы (этапа) проекта

3.1. Определение требований

На этапе определения требований представители команды разработки выполняют обследование объекта автоматизации при взаимодействии с представителями заказчика – специалистами предметной области.

Собранные в результате обследования сведения об объекте автоматизации должны быть формализованы с использованием средств моделирования, используемых командой разработки.

Результатом этапа определения требований должны являться следующие документы:

1.Протоколы проведения обследования объекта автоматизации. Протоколы должны быть согласованы с представителями заказчика.

2.Формализованное описание результатов обследования. Примером формализованного описания является представление требований в виде диаграммы прецедентов (Use Case) языка UML.

3.Техническое задание (разделы технического задания), согласованные с представителями заказчика.

На этом этапе должны быть определены цели и задачи, которые должно выполнять разрабатываемое программное обеспечение (ПО), а также запланированы способы проверки выполняемых ПО функций.

Формы согласования с заказчиком должны обеспечивать впоследствии возможность доказательства достигнутых договоренностей (подписанные бумажные документы, электронная почта и пр.).

На этапе определения требований должны использоваться следующие средства автоматизации процесса разработки:

• система управления задачами, для фиксации задач по обследованию и определению требований,
• система внутреннего документирования проекта, для хранения полученных требований в формализованном виде.

3.2. Проектирование

На этапе проектирования командой разработки разрабатываются проектные решения, реализующие требования, определенные на предыдущем этапе.

Разработка проектных решений выполняется в следующей последовательности:

1.Разработка высокоуровневого описания постановки задачи, которое должно содержать описание поведения, разрабатываемого ПО, описание бизнес- процессов и бизнес-ролей, состав функций, которые необходимо реализовать и т.д. Формальное описание алгоритмов и функций может быть выполнено в виде нотации BPMN, IDEF, диаграмм активностей, последовательности и состояний языка UML.

2.Разработка архитектуры ПО: состав компонентов, определение информационных потоков и т.д.

3.Определение состава задач для разработки. Задачи для разработки должны удовлетворять следующим требованиям:

a.Являться результатом декомпозиции высокоуровневых остановок задач.

b.Должны содержать конкретные постановки для реализации нового функционала разработчиками.

c.Задачи должны быть распределены на итерации, составляющие план выполнения разработки ПО, его версии или релиза.

4.Определение программных платформ, языков программирования, необходимость использования дополнительных сторонних библиотек.

5.Проведение подготовки к этапу разработки.

На этапе проектирования решения вырабатываются и принимаются архитектором системы, ведущими разработчиками, а также в результате совместных обсуждений с участием всех участников разработки. Результаты решений обязательно фиксируются в системе внутреннего документирования и системе управления задачами.

Результатом этапа определения требований должны являться следующие документы:

1.Общие постановки задач, включая схемы и диаграммы в перечисленных выше нотациях в системе внутреннего документирования.

2.Задачи для разработки создаются в системе управления задачами.

3.Необходимый набор документов Технического проекта согласно ГОСТ 34. Разработка документации Технического проекта должна проводиться на основании заранее подготовленных шаблонов документов. При необходимости документация Технического проекта согласуется с заказчиком ПО.

На этапе определения требований должны использоваться следующие средства автоматизации процесса разработки:

• система управления задачами, для создания задач разработчикам, проведения планирования итераций,
• система внутреннего документирования проекта, для хранения результатов проектирования ПО.

При проведении подготовки к этапу разработки должны быть подготовлены:

• проект в системе управления задачами,
• проект в системе управления версиями,
• базовая инфраструктура среды разработки, включая необходимый набор проектов, классов, стандартных и общих библиотек и других компонент, позволяющих осуществить сборку приложения, инфраструктура должна быть размещена в системе управления версиями,
• проект в системе непрерывной интеграции,
• стенды для тестирования разработанного ПО, моделирующие ИТ-инфраструктуру заказчика.

3.3. Разработка и тестирование

Процесс разработки должен быть дискретным и поделен на итерации длительностью от двух до четырех недель. Каждый этап должен заканчиваться выпуском следующей версии. Каждая версия должна содержать набор работоспособных компонент, которые могут быть представлены заказчику в качестве прототипа системы.

Для программных компонентов, вошедших в выпускаемую версию, должны выполняться следующие правила:

• компоненты должны корректно выполнять определенные в описании версии функции;
• программный код, реализующий указанные компоненты, должен иметь 100% покрытие тестами (т.е. все публичные методы должны иметь тесты, проверяющие работоспособность, как с корректными, так и с некорректными данными);
• тесты должны быть пригодны для автоматического тестирования и выполнены согласно технологии JUnit, NUnit;
• программный код должен иметь комментарии. Как минимум должны быть комментарии классов и публичных методов. Синтаксис комментария должен соответствовать правилам формирования комментария для систем автоматической сборки документации, характерной для платформы программирования;
• все задачи, запланированные в данной версии, должны быть зафиксированы в системе управления задачами, при этом для завершенных задач должен присутствовать подробный комментарий с описанием внесенных изменений;
• весь программный код должен быть размещен в системе управления версиями;
• результат сборки должен быть доступен из системы непрерывной интеграции;
• новая версия должна быть развернута на тестовом стенде.

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

3.4. Выпуск релиза (версии, продукта)

Процедура выпуска релизов подробно описана в документе «Регламент управления релизами».

4. Средства автоматизации процесса разработки

Основной целью внедрения средств автоматизации процесса разработки является обеспечение высокого качества результатов разработки программного обеспечения и повышение эффективности работы команды разработки.

Внедрение средств автоматизации процесса разработки обеспечивает выполнение следующих показателей качества результатов работы команды разработки:

• стабильность и устойчивость работы выпускаемых программных продуктов,
• соблюдение сроков разработки,
• повторяемость результатов (возможность повторного использования компонент в других проектах),
• полнота документирования (информации в документах достаточно для самостоятельного изучения).

Средства автоматизации процесса разработки должны удовлетворять следующим требованиям:

• Должна быть возможность интеграции средств автоматизации процесса разработки с системами разработки (IDE).
• Внедрение средств автоматизации процесса разработки должно обеспечивать:
• исключение многократной отчетности участников проекта,
• автоматизацию рутинных процессов,
• документирование всех этапов и артефактов проекта,
• унификацию подходов к выполнению критичных этапов проекта (сборка, тестирование, контроль и т.д.),
• реализацию эффективных методов оценки результативности команды и ее членов

Регламент устранения несоответствий в ходе эксплуатации мобильного приложения «MedApp»

Программное обеспечение MedApp. Правообладатель — ООО «ВИСМУТ».

1. Список терминов и определений

1.1.ПО – Мобильное приложение MedApp.

1.2.Конечный пользователь – Юридическое лицо, которое на законных основаниях владеет неисключительными правами на использование MedApp.

1.3.Исполнитель – ООО «Висмут».

1.4.АИС – автоматизированная информационная система Исполнителя.

1.5.БД – база данных.

1.6.Сервисный центр – служба технической поддержки Исполнителя.

1.7.Услуга – перечень предоставляемых услуг в объеме, установленном Программой технической поддержки (Приложение 1).

1.8.Заявка – сообщение, направляемое уполномоченным представителем Конечного пользователя из утвержденного перечня Исполнителю в электронной или устной форме, в котором фиксируется возникшая проблема или вопрос, подлежащие решению.

1.9.Ответственный – специалист Исполнителя, назначенный для решения Заявки.

1.10.Рабочий день – промежуток времени с понедельника по пятницу с 08:00 до 18:00 (UTC +5:00), за исключением выходных и праздничных дней, согласно законодательству Российской федерации.

1.11.Рабочий час – астрономический час в пределах Рабочего дня.

1.12.Нерабочее время – промежуток времени с понедельника по пятницу с 18:00 до 08:00 (UTC +5:00), а также выходные и праздничные дни, согласно законодательству Российской Федерации.

1.13.Работоспособность – ПО считается работоспособным при его работе с сохранением основных технических параметров, указанных в технической документации, выполнение которых обеспечивает нормальное применение ПО по назначению и использование для выполнения необходимых функций.

1.14.Время обслуживания – режим времени, в рамках которого Исполнитель предоставляет Услуги. Варианты времени обслуживания: работа над Заявкой ведется в режиме 12х7 в рабочие дни с 08:00 до 18:00 (UTC +5:00), за исключением выходных дней и общероссийских праздников; 24х7 – работа над Заявкой ведется круглосуточно.

1.15.Время реакции – время, в течение которого ответственный специалист начнет работу над Заявкой и, в случае необходимости, свяжется с представителем Конечного пользователя для выдачи рекомендаций или запроса дополнительной информации. Отсчет времени реакции начинается с момента получения Заявки. Время реакции определяется заказанной Услугой. Для Времени обслуживания 12х7 при поступлении запроса позже 18:00 (UTC +5:00) Заявка считается полученной на следующий рабочий день в 08:00 (UTC +5:00).

1.16.Время в работе – время, в течение которого ответственный специалист выполняет работу над Заявкой, т.е. общее время с момента регистрации Заявки до момента ее закрытия.

1.17.Время восстановления – период времени с момента регистрации Заявки до момента восстановления работоспособности ПО.

1.18.Периодичность выполнения устанавливает периодичность оказания услуг. Конкретная дата проведения работ устанавливается по согласованию с Конечным пользователем.

1.19.Приоритет – параметр, отражающий важность проблемы для бизнеса и пользователя. Приоритет определяется представителем Конечного пользователя путем оценки влияния проблемы на работоспособность ПО при подаче Заявки в соответствии со следующим описанием:

• Критичный приоритет – ПО не работает, что приводит к остановке всех или одной из обслуживаемых систем.
• Высокий приоритет – частично нарушена работоспособность, либо значительно снижена отказоустойчивость или производительность ПО Конечного пользователя, но при этом создается критическая ситуация, при которой полная потеря работоспособности всего технологического процесса Конечного пользователя может произойти в любой момент.
• Средний приоритет – незначительно нарушена работоспособность, либо производительность ПО, что не оказывает влияния на бизнес Конечного пользователя.
• Низкий приоритет – ошибка, которая несущественно ограничивает использование ПО для выполнения необходимых функций, либо требуется консультация специалиста по техническим вопросам, связанным с эксплуатацией, конфигурированием, управлением исправным ПО, поиском причины возникновения неисправности.

ПРИМЕЧАНИЕ: заявленный Конечным пользователем при открытии Заявки приоритет может быть изменен специалистом Исполнителя в случае уточнения в ходе выполнения Заявки фактического влияния заявленной проблемы на работоспособность ПО, а также в случае снижения влияния проблемы на работоспособность ПО.

1.20.Способ взаимодействия – возможные способы коммуникации между Конечным пользователем и ответственным специалистом Исполнителя. Услугой предусмотрены следующие способы взаимодействия:

• Отправка сообщения на электронную почту;
• Звонок на горячую линию

Контактная информация указана в п.3.1.

1.21.Способ обработки Заявок – возможные способы обработки Заявок определяются заказанной Услугой. В случае, если Услугой предусмотрено несколько способов обработки Заявок, то способ выбирается ответственным специалистом Исполнителя:

• Дистанционно – при данном способе работы над Заявкой взаимодействие Исполнителя и Конечного пользователя осуществляется по электронной почте и телефону.
• Удаленно – при данном способе работа над Заявкой осуществляется с помощью удаленного доступа к ресурсам Конечного пользователя.

2. Общие положения

2.1.Настоящий документ определяет регламент оказания услуг технической поддержки (далее – Регламент).

2.2.Основной целью Регламента является установление порядка взаимодействия специалистов Конечного пользователя со специалистами Исполнителя.

3. Контактная информация

3.1.Контакты Сервисного центра:

• Электронная почта: info@vismuth.ru
• Телефон: +7 922 610-55-31
• Фактический адрес: 620078, Свердловская область, г. Екатеринбург, пер. Автоматики, стр. 1, офис 219

3.2.В случае изменения Исполнителем контактной информации, указанной в Регламенте, Исполнитель должен сообщить Конечному пользователю новую контактную информацию по электронной почте либо по телефону с обязательным дублированием информации электронным сообщением.

4. Открытие заявки

4.1. Способы и время подачи Заявок

• Заявки в Сервисный центр принимаются по электронной почте, телефону (пункт 3.1.) от уполномоченного представителя Конечного пользователя.
• По телефону: круглосуточно.
• По электронной почте: в рабочий день.

4.2. Содержание Заявки

Заявка подается по установленной форме (Приложение № 2), при заполнении которой указываются следующие сведения:

• Номер договора, номер лицензии, сертификата технической поддержки.
• Название организации Конечного пользователя.
• Контактная информация (ФИО, телефон, электронный адрес) обратившегося.
• Содержание обращения.

4.3. Регистрация Заявки

• Регистрация Заявки начинается с момента получения Заявки.
• При регистрации АИС автоматически присваивает Заявке номер и отправляет уведомление о регистрации на указанный контактный электронный адрес Конечного пользователя.

5. Работа над заявкой

5.1.Ответственный берет Заявку в работу только во время обслуживания (п. 1.13) и в срок не более обозначенного в Программе технической поддержки. Отсчет Времени реакции начинается с получения всей информации в соответствии с содержанием Заявки (пункт 4.2.).

5.2.Ответственный на основании предоставленных данных производит диагностирование проблемы, либо запрашивает у инициатора Заявки (при необходимости) дополнительную информацию.

5.3.Производится уведомление инициатора Заявки по указанным в Заявке контактным данным о возможных вариантах решения.

5.4.При необходимости выполнения работ способом «Выезд» производится согласование с инициатором Заявки возможности, даты и времени допуска на место эксплуатации (если предусмотрено Программой технической поддержки).

5.5.Организуется прибытие специалистов исполнителя на место эксплуатации ПО в согласованное время (если предусмотрено Программой технической поддержки).

5.6.Производятся работы по устранению неисправности.

5.7.Количество персонала, задействованного в процессе сопровождения: 1 человек, являющийся гражданином Российской Федерации и находящихся на территории РФ.

6. Взаимодействие с конечным пользователем

6.1.В случае необходимости получения дополнительной информации от Конечного пользователя для продолжения работы над Заявкой Ответственный обращается с запросом к специалисту Конечного пользователя. По своему усмотрению Ответственный может выбрать способ обращения: по телефону или с помощью отправки электронной почты с обязательной фиксацией факта обращения (запись телефонного разговора, подтверждение о получении запроса Конечным пользователем по электронной почте или телефону (с записью разговора).

6.2.При получении запроса о предоставлении дополнительной информации специалист Конечного пользователя обязан оказать содействие Ответственному в дистанционном решении проблемы и предоставить всю информацию, необходимую для осуществления технической поддержки, а также для определения подходящего уровня обслуживания, запустить тесты самодиагностики и/или установить и запустить другие диагностические средства и программы, в соответствии с инструкциями, предоставляемыми специалистом Исполнителя.

6.3.При отсутствии обратной связи от Конечного пользователя в течение суток Ответственный отправляет Конечному пользователю повторный запрос. При отсутствии ответа на повторный запрос по истечении 3 (Трех) дней с момента первого запроса Ответственный переводит Заявку в статус «Закрыта». При получении необходимой информации или обратной связи Конечного пользователя Заявка возвращается в работу.

7. Мониторинг и контроль качества

7.1.Контроль над исполнением обязательств осуществляется специалистами Сервисного центра с помощью АИС.

7.2.АИС обеспечивает своевременную эскалацию выполняемых заявок и запросов по техническому обслуживанию, которая позволяет контролировать сроки решения Заявок, предупреждая нарушение сроков, обозначенных в Программе технической поддержки.

8. Закрытие заявки

8.1.При решении Заявки специалист Исполнителя производит уведомление инициатора Заявки о решении.

8.2.АИС отправляет электронное письмо на подтверждение закрытия Заявки.

8.3.Закрытие Заявки по подтверждению. Закрытие Заявок по подтверждению производится специалистами Исполнителя: по факту поступления от Конечного пользователя подтверждения о закрытии Заявки.

8.4.Автоматическое закрытие Заявки. В случае если Конечный пользователь после получения уведомления от Исполнителя не выслал подтверждение или не сообщил о неисполнении Заявки в течение 3 (Трех) календарных дней, Заявка закрывается автоматически.

9. Отчетность

9.1.При способе обработки Заявок: «Выезд» Конечным пользователем и Исполнителем в обязательном порядке оформляется и подписывается акт выполненных работ по Заявке (Приложение № 3). Акт выполненных работ по Заявке подписывается Ответственным и представителем Конечного пользователя.

10. Дополнительные условия

10.1.Конечный пользователь обязан подавать заявки на функциональные модули ПО, которые были исправны на момент подписания Регламента.

10.2.Конечный пользователь обязан соблюдать условия правообладателя в отношении использования ПО, в том числе: наличие действующих лицензий и условия эксплуатации, указанные в техническом описании условий эксплуатации, поставляемом вместе с ПО, а также – на web-сайте производителей.

10.3.Обслуживание не предоставляется по Регламенту, но может быть предоставлено за отдельную плату в рамках отдельного договора, заключаемого с Исполнителем:

• при несоблюдении условий эксплуатации/использования ПО;
• при установлении факта выхода из строя ПО до момента подписания Регламента, в таких случаях предварительное восстановление работоспособности обслуживаемого ПО не предусмотрено условиями Регламента;
• при неработоспособности обслуживаемых компонентов, вызванной работой других, не обслуживаемых Исполнителем компонентов;
• при неработоспособности обслуживаемого ПО вследствие эксплуатации без электрического заземления, а при соединении нескольких устройств – без единого контура заземления;
• при неработоспособности обслуживаемого ПО вследствие механического повреждения оборудования;
• при неработоспособности вследствие внесения изменений в версию программного обеспечения и/или конфигурацию обслуживаемых систем без уведомления Исполнителя в порядке, установленном пунктом 10.4 Регламента;
• при обращении представителей Конечного пользователя вне утвержденного списка уполномоченных лиц;

10.4.при необходимости доработки ПО, вызванной изменением автоматизируемых процессов.

10.5.При желании Конечного пользователя внести какие-либо изменения в ПО, находящееся на обслуживании Исполнителя, Конечный пользователь обязан производить только изменения, рекомендованные правообладателем, и использовать только программное обеспечение, на которое у Конечного пользователя имеются надлежащим образом оформленные права с уведомлением Исполнителя за 1 (Один) рабочий день до проведения изменений. Изменения, необходимые для работы с новыми версиями других компонентов (не относящихся к ПО), производятся за счет Конечного пользователя.

10.6. Приложения

10.7.Приложение № 1. Программа технической поддержки на 1 л.

10.8.Приложение № 2. Форма заявки на 1 л.

10.9.Приложение № 3. Форма акта выполненных работ по Заявке на 2 л.

Приложение № 1. Программа технической поддержки

Приложение № 2. Форма заявки

Приложение № 3. Форма акта выполненных работ

г. _________________ «_____»___________ 202__г.

Стороны подтверждают достоверность приведенной в Акте информации по объему, длительности, трудоемкости работ, дополнительных замечаний не имеют.

Подписи Сторон

Руководство по установке и системно-технические требования

Программное обеспечение MedApp. Правообладатель — ООО «ВИСМУТ».

1. Общие сведения и архитектура ПО

Программное обеспечение «MedApp» (далее — ПО) разработано для комплексной автоматизации рабочих мест медицинского персонала медицинских организаций. ПО упрощает управление пациентами, планирование расписания, ведение электронных карт (в стационаре, поликлинике и на дому) и оперативно информирует о критических показателях здоровья.

Программный комплекс имеет клиент-серверную архитектуру и состоит из двух ключевых компонентов:

1.Серверная часть (Бэкэнд-инфраструктура): API-шлюз, состоящий из модулей MedApp.Gateway.WebApi (веб-интерфейс взаимодействия) и MedApp.Gateway.Scheduler (планировщик задач), разворачиваемый в корпоративной сети медицинской организации или на мощностях правообладателя.

2.Клиентская часть (Мобильные приложения): Мобильное приложение для мобильных устройств (смартфонов и планшетов) под управлением операционных систем Android и iOS.

2. Системно-технические требования

2.1. Требования к серверной инфраструктуре (для развертывания API-шлюза)

Для корректной установки и функционирования серверных компонентов MedApp.Gateway необходима инфраструктура со следующими параметрами:

• Среда выполнения: Наличие установленной среды выполнения ASP.NET Core Runtime 9.0.8 (для запуска) и .NET 9 SDK версии 9.0.304 (для компиляции и сборки проекта).
• Веб-сервер: Программные средства организации веб-сервера (например, IIS, Nginx, Apache) с поддержкой проксирования и развертывания ASP.NET Core приложений.
• Система управления базами данных (СУБД): Рекомендуется PostgreSQL версии 17.2 или выше. СУБД используется для хранения конфигураций, логов, данных авторизации и интеграции со смежными МИС.
• Сторонние сервисы: Для работы подсистемы авторизации по умолчанию требуется интеграция с СМС-шлюзами (поддерживаются МТС Omnichannel или МТС Exolve).

2.2. Требования к клиентским мобильным устройствам пользователей

Мобильные устройства конечных пользователей (врачей) должны соответствовать требованиям:

• Операционная система: Android версии 10.0 и выше или iOS версии 15.0 и выше.
• Процессор и память: 4-ядерный процессор (от 1.8 ГГц), оперативная память (RAM) не менее 3 Гб.
• Дисковое пространство: Не менее 150 Мб свободного места для дистрибутива и локального кэша.
• Каналы связи: Активное подключение к сети Интернет (Wi-Fi, 3G/4G/5G) со скоростью передачи данных не менее 512 Кбит/с, открытые порты 80 и 443 для HTTPS-трафика.

3. Порядок установки и развертывания ПО

3.1. Развертывание серверной части комплекса

Для развёртывания API необходимо выполнить следующие шаги:

• Собрать приложения MedApp.Gateway.WebApi и MedApp.Gateway.Scheduler
• Подготовить целевой хост для развертывания
• Подготовить базу данных PostgreSQL
• Настроить файлы конфигурации приложений
• Перенести приложение на целевой хост и проверить работоспособность

3.1.1. Сборка приложения

Для сборки приложения требуется наличие установленных пакетов .NET 9 SDK 9.0.304.

Для сборки проекта можно воспользоваться IDE c поддержкой среды разработки .NET, например, Visual Studio Code, Visual Studio 2022, Rider.

Для сборки через командную строку .NET Core CLI необходимо выполнить команды:

Таблица 1. MedApp.Gateway.WebApi

# Очистка
dotnet clean '[Путь до каталога с решением]/app.source/MedApp.Gateway.WebApi/MedApp.Gateway.WebApi.csproj'
 
# Восстановление зависимостей
dotnet restore --no-cache '[Путь до каталога с решением]/app.source/MedApp.Gateway.WebApi/MedApp.Gateway.WebApi.csproj'
 
# Публикация
dotnet publish '[Путь до каталога с решением]/app.source/MedApp.Gateway.WebApi/MedApp.Gateway.WebApi.csproj' -c Release -o [Путь до каталога публикации]/publish --no-restore

Таблица 2. MedApp.Gateway.Scheduler

# Очистка
dotnet clean '[Путь до каталога с решением]/app.source/MedApp.Gateway.Scheduler/MedApp.Gateway.Scheduler.csproj'
 
# Восстановление зависимостей
dotnet restore --no-cache '[Путь до каталога с решением]/app.source/MedApp.Gateway.Scheduler/MedApp.Gateway.Scheduler.csproj'
 
# Публикация
dotnet publish '[Путь до каталога с решением]/app.source/MedApp.Gateway.Scheduler/MedApp.Gateway.Scheduler.csproj' -c Release -o [Путь до каталога публикации]/publish --no-restore

3.1.2. Подготовка целевого хоста для развертывания

Для развертывания приложения на целевом хосте требуется:

1.Наличие установленной среды ASP.NET Core Runtime 9.0.8

2.Наличие программных средств организации веб-сервера с поддержкой развертывания ASP.NET Core приложений

3.Настроенные права пользователей для настройки и запуска приложения в качестве веб-службы

3.1.3. Подготовка базы данных PostgreSQL

Приложение использует в работе собственную базу данных для хранения данных авторизованных пользователей, конфигурации приложения и взаимодействия и интеграционными API.

Рекомендуемая версия PostgreSQL: 17.2 или выше.

База данных может быть развернута как на целевой машине, так и на отдельном хосте.

При создании базы данных под приложение рекомендуется так же создать отдельного пользователя и пароль, которые будут использованы при настройке конфигурации приложения:

Таблица 3. Создание пользователя и базы данных PostgreSQL через консоль

sudo -u postgres psql
CREATE USER имя_пользователя WITH PASSWORD 'ваш_пароль';
CREATE DATABASE имя_базы_данных WITH OWNER имя_пользователя;

Созданная база данных должна быть доступна с целевой машины, где будет развернуто приложение.

Структура базы данных будет создана при первом запуске MedApp.Gateway.WebApi с помощью миграций.

Внимание! Изменение вручную таблиц, созданных миграцией, может привести к ошибкам в работе приложения.

3.1.4. Настройка файлов конфигурации

При настройке конфигурации требуется:

1.Удалить файлы:

a.appsettings.Development.json

b.appsettings.Staging.json

2.Отредактировать файлы appsettings.json и appsettings.Production.json

Основные настройки

Основные настройки расположены в блоке AppSettings. Для инициализации приложения, нужно заполнить данные пользователя по умолчанию. В таблице ниже приведены поля, которые необходимо заполнить:

Настройки СМС

По умолчанию приложение настроено на авторизацию через СМС. На текущий момент реализована поддержка работы через сервисы рассылок МТС Omnichannel и МТС Exolve. Для настройки требуется заполнить блок SmsSettings

Настройки путей к файлам логов

Для возможности фиксации файлов логов требуется указать в файле конфигурации каталог, до которого у приложения будет доступ на запись.

Настройка пути производится в файле appsettings.Production.json.

Необходимо заполнить путь в блоке Serilog:WriteTo:1:Args:configure:1:Args:path

Настройки подключения к PostgreSQL

Заполните строку подключения к базе данных в файле appsettings.Production.json.

Строка подключения заполняется в блоке ConnectionStrings:PostgreSQL. Пример строки подключения:

"Host=host; Port=5432; Database=database; Username=user; Password=password; TrustServerCertificate=True; ApplicationName=medapp.gateway.webapi;"

3.1.5. Перенос приложения на целевой хост

Для настройки приложения на целевом хосте требуется:

1.Расположить файлы приложений MedApp.Gateway.WebApi и MedApp.Gateway.Scheduler на целевом хосте

2.Настроить приложение MedApp.Gateway.WebApi в качестве веб-приложения на веб сервере, в соответствии с документацией веб-сервера для развертывания ASP.NET Core приложения.

3.Настроить приложение MedApp.Gateway.Scheduler в качестве сервиса в соответствии с документацией по настройке приложений в качестве служб для ОС целевого хоста.

После развертывания приложений на целевом хосте необходимо:

1.Открыть swagger веб-приложения MedApp.Gateway.WebApi по адресу [ip адрес целевого хоста]/swagger

2.Выполнить метод первичной инициализации пользователя /api/initialization/initialize

3.Авторизоваться в методе /api/authorization/login используя логин и пароль указанные в файле конфигурации.

3.2. Установка мобильного клиента на устройства пользователей

Скачивание дистрибутива открыто и бесплатно в официальных магазинах приложений:

• Для устройств iOS: В магазине Apple App Store найдите приложение по запросу «MedApp LiteLink» или перейдите по прямой ссылке: https://apps.apple.com/ru/app/medapp-litelink/id6474684502. Нажмите «Установить».
• Для устройств Android:
  • В магазине RuStore (рекомендуется для РФ): перейдите по ссылке https://www.rustore.ru/catalog/app/ru.e2m.app или найдите через поиск и нажмите «Скачать».
  • В магазине Google Play: перейдите по ссылке https://play.google.com/store/apps/details?id=ru.e2m.app или найдите через поиск и нажмите «Установить».

3.2.1. Установка на устройствах iOS

3.2.1.1. Ссылка для скачивания из «App Store»

1.Перейдите по ссылке https://apps.apple.com/ru/app/medapp-litelink/id6474684502

2.Откроется страница в «App Store» с описанием приложения MedApp LiteLink, здесь нажмите «Установить», либо на кнопку с изображением облака со стрелочкой

Перед загрузкой приложения возможно появление запроса на разрешение выполнения действия.

3.После установки приложения появится кнопка «Открыть», нажмите ее, чтобы запустить приложение

3.2.1.2. Установка вручную из «App Store»

1.Запустите приложение «App Store»

2.Перейдите в раздел поиска, в строке поиска введите MedApp LiteLink и нажмите найти

3.В результатах поиска выберите приложение MedApp LiteLink

4.Откроется страница описания приложения, здесь нажмите «Установить», либо на кнопку с изображением облака со стрелочкой

Перед загрузкой приложения возможно появление запроса на разрешение выполнения действия.

5.После установки приложения появится кнопка «Открыть», нажмите ее, чтобы запустить приложение

3.2.2. Установка на устройствах Android

3.2.2.1. Ссылка для скачивания из «Google Play»

1.Перейдите по ссылке https://play.google.com/store/apps/details?id=ru.e2m.app

2.Откроется страница в «Google Play» с описания приложения MedApp LiteLink, здесь нажмите «Установить»

Перед загрузкой приложения возможно появление запроса на разрешение выполнения действия.

3.После установки приложения появится кнопка «Открыть», нажмите ее, чтобы запустить приложение

3.2.2.2. Ссылка для скачивания из «RuStore»

1.Перейдите по ссылке https://www.rustore.ru/catalog/app/ru.e2m.app

2.Откроется страница «RuStore» с описанием приложения MedApp LiteLink, здесь нажмите «Скачать»

3.После установки приложения появится кнопка «Открыть», нажмите ее, чтобы запустить приложение

3.2.2.3. Установка вручную из «Google Play»

1.Запустите приложение «Google Play» (магазин приложений)

2.Перейдите в раздел поиска, здесь в строке поиска введите MedApp LiteLink и нажмите найти

3.В результатах поиска выберите приложение MedApp LiteLink

4.Откроется страница описания приложения, здесь нажмите «Установить»

Перед загрузкой приложения возможно появление запроса на разрешение выполнения действия.

5.После установки приложения появится кнопка «Открыть», нажмите ее, чтобы запустить приложение

3.2.2.4. Установка вручную из «RuStore»

1.Запустите приложение «RuStore» (магазин приложений)

2.В поисковой строке введите MedApp LiteLink и нажмите найти

3.В результатах поиска выберите приложение MedApp LiteLink

4.Откроется страница описания приложения, здесь нажмите «Скачать»

5.После установки приложения появится кнопка «Открыть», нажмите ее, чтобы запустить приложение

4. Проверка правильности установки

1.Запустите приложение на мобильном устройстве с помощью ярлыка «MedApp».

2.При первом запуске на экране появится запрос ОС на разрешение отправки Push-уведомлений — необходимо выбрать «Разрешить» для корректного получения оперативных уведомлений о пациентах и расписании.

3.Отображение экрана авторизации (ввод телефона или пары логин/пароль) подтверждает успешную установку мобильного клиента и его стабильное сетевое соединение с развернутым API-шлюзом.

Руководство по установке и системно-технические требования

Программное обеспечение MedApp. Правообладатель — ООО «ВИСМУТ».

1. Общие сведения и архитектура ПО

Программное обеспечение «MedApp» (далее — ПО) разработано для комплексной автоматизации рабочих мест медицинского персонала медицинских организаций. ПО упрощает управление пациентами, планирование расписания, ведение электронных карт (в стационаре, поликлинике и на дому) и оперативно информирует о критических показателях здоровья.

Программный комплекс имеет клиент-серверную архитектуру и состоит из двух ключевых компонентов:

1.Серверная часть (Бэкэнд-инфраструктура): API-шлюз, состоящий из модулей MedApp.Gateway.WebApi (веб-интерфейс взаимодействия) и MedApp.Gateway.Scheduler (планировщик задач), разворачиваемый в корпоративной сети медицинской организации или на мощностях правообладателя.

2.Клиентская часть (Мобильные приложения): Мобильное приложение для мобильных устройств (смартфонов и планшетов) под управлением операционных систем Android и iOS.

2. Системно-технические требования

2.1. Требования к серверной инфраструктуре (для развертывания API-шлюза)

Для корректной установки и функционирования серверных компонентов MedApp.Gateway необходима инфраструктура со следующими параметрами:

• Среда выполнения: Наличие установленной среды выполнения ASP.NET Core Runtime 9.0.8 (для запуска) и .NET 9 SDK версии 9.0.304 (для компиляции и сборки проекта).
• Веб-сервер: Программные средства организации веб-сервера (например, IIS, Nginx, Apache) с поддержкой проксирования и развертывания ASP.NET Core приложений.
• Система управления базами данных (СУБД): Рекомендуется PostgreSQL версии 17.2 или выше. СУБД используется для хранения конфигураций, логов, данных авторизации и интеграции со смежными МИС.
• Сторонние сервисы: Для работы подсистемы авторизации по умолчанию требуется интеграция с СМС-шлюзами (поддерживаются МТС Omnichannel или МТС Exolve).

2.2. Требования к клиентским мобильным устройствам пользователей

Мобильные устройства конечных пользователей (врачей) должны соответствовать требованиям:

• Операционная система: Android версии 10.0 и выше или iOS версии 15.0 и выше.
• Процессор и память: 4-ядерный процессор (от 1.8 ГГц), оперативная память (RAM) не менее 3 Гб.
• Дисковое пространство: Не менее 150 Мб свободного места для дистрибутива и локального кэша.
• Каналы связи: Активное подключение к сети Интернет (Wi-Fi, 3G/4G/5G) со скоростью передачи данных не менее 512 Кбит/с, открытые порты 80 и 443 для HTTPS-трафика.

3. Порядок установки и развертывания ПО

3.1. Развертывание серверной части комплекса

Для развёртывания API необходимо выполнить следующие шаги:

• Собрать приложения MedApp.Gateway.WebApi и MedApp.Gateway.Scheduler
• Подготовить целевой хост для развертывания
• Подготовить базу данных PostgreSQL
• Настроить файлы конфигурации приложений
• Перенести приложение на целевой хост и проверить работоспособность

3.1.1. Сборка приложения

Для сборки приложения требуется наличие установленных пакетов .NET 9 SDK 9.0.304.

Для сборки проекта можно воспользоваться IDE c поддержкой среды разработки .NET, например, Visual Studio Code, Visual Studio 2022, Rider.

Для сборки через командную строку .NET Core CLI необходимо выполнить команды:

Таблица 1. MedApp.Gateway.WebApi

# Очистка
dotnet clean '[Путь до каталога с решением]/app.source/MedApp.Gateway.WebApi/MedApp.Gateway.WebApi.csproj'
 
# Восстановление зависимостей
dotnet restore --no-cache '[Путь до каталога с решением]/app.source/MedApp.Gateway.WebApi/MedApp.Gateway.WebApi.csproj'
 
# Публикация
dotnet publish '[Путь до каталога с решением]/app.source/MedApp.Gateway.WebApi/MedApp.Gateway.WebApi.csproj' -c Release -o [Путь до каталога публикации]/publish --no-restore

Таблица 2. MedApp.Gateway.Scheduler

# Очистка
dotnet clean '[Путь до каталога с решением]/app.source/MedApp.Gateway.Scheduler/MedApp.Gateway.Scheduler.csproj'
 
# Восстановление зависимостей
dotnet restore --no-cache '[Путь до каталога с решением]/app.source/MedApp.Gateway.Scheduler/MedApp.Gateway.Scheduler.csproj'
 
# Публикация
dotnet publish '[Путь до каталога с решением]/app.source/MedApp.Gateway.Scheduler/MedApp.Gateway.Scheduler.csproj' -c Release -o [Путь до каталога публикации]/publish --no-restore

3.1.2. Подготовка целевого хоста для развертывания

Для развертывания приложения на целевом хосте требуется:

1.Наличие установленной среды ASP.NET Core Runtime 9.0.8

2.Наличие программных средств организации веб-сервера с поддержкой развертывания ASP.NET Core приложений

3.Настроенные права пользователей для настройки и запуска приложения в качестве веб-службы

3.1.3. Подготовка базы данных PostgreSQL

Приложение использует в работе собственную базу данных для хранения данных авторизованных пользователей, конфигурации приложения и взаимодействия и интеграционными API.

Рекомендуемая версия PostgreSQL: 17.2 или выше.

База данных может быть развернута как на целевой машине, так и на отдельном хосте.

При создании базы данных под приложение рекомендуется так же создать отдельного пользователя и пароль, которые будут использованы при настройке конфигурации приложения:

Таблица 3. Создание пользователя и базы данных PostgreSQL через консоль

sudo -u postgres psql
CREATE USER имя_пользователя WITH PASSWORD 'ваш_пароль';
CREATE DATABASE имя_базы_данных WITH OWNER имя_пользователя;

Созданная база данных должна быть доступна с целевой машины, где будет развернуто приложение.

Структура базы данных будет создана при первом запуске MedApp.Gateway.WebApi с помощью миграций.

Внимание! Изменение вручную таблиц, созданных миграцией, может привести к ошибкам в работе приложения.

3.1.4. Настройка файлов конфигурации

При настройке конфигурации требуется:

1.Удалить файлы:

a.appsettings.Development.json

b.appsettings.Staging.json

2.Отредактировать файлы appsettings.json и appsettings.Production.json

Основные настройки

Основные настройки расположены в блоке AppSettings. Для инициализации приложения, нужно заполнить данные пользователя по умолчанию. В таблице ниже приведены поля, которые необходимо заполнить:

Настройки СМС

По умолчанию приложение настроено на авторизацию через СМС. На текущий момент реализована поддержка работы через сервисы рассылок МТС Omnichannel и МТС Exolve. Для настройки требуется заполнить блок SmsSettings

Настройки путей к файлам логов

Для возможности фиксации файлов логов требуется указать в файле конфигурации каталог, до которого у приложения будет доступ на запись.

Настройка пути производится в файле appsettings.Production.json.

Необходимо заполнить путь в блоке Serilog:WriteTo:1:Args:configure:1:Args:path

Настройки подключения к PostgreSQL

Заполните строку подключения к базе данных в файле appsettings.Production.json.

Строка подключения заполняется в блоке ConnectionStrings:PostgreSQL. Пример строки подключения:

"Host=host; Port=5432; Database=database; Username=user; Password=password; TrustServerCertificate=True; ApplicationName=medapp.gateway.webapi;"

3.1.5. Перенос приложения на целевой хост

Для настройки приложения на целевом хосте требуется:

1.Расположить файлы приложений MedApp.Gateway.WebApi и MedApp.Gateway.Scheduler на целевом хосте

2.Настроить приложение MedApp.Gateway.WebApi в качестве веб-приложения на веб сервере, в соответствии с документацией веб-сервера для развертывания ASP.NET Core приложения.

3.Настроить приложение MedApp.Gateway.Scheduler в качестве сервиса в соответствии с документацией по настройке приложений в качестве служб для ОС целевого хоста.

После развертывания приложений на целевом хосте необходимо:

1.Открыть swagger веб-приложения MedApp.Gateway.WebApi по адресу [ip адрес целевого хоста]/swagger

2.Выполнить метод первичной инициализации пользователя /api/initialization/initialize

3.Авторизоваться в методе /api/authorization/login используя логин и пароль указанные в файле конфигурации.

3.2. Установка мобильного клиента на устройства пользователей

Скачивание дистрибутива открыто и бесплатно в официальных магазинах приложений:

• Для устройств iOS: В магазине Apple App Store найдите приложение по запросу «MedApp LiteLink» или перейдите по прямой ссылке: https://apps.apple.com/ru/app/medapp-litelink/id6474684502. Нажмите «Установить».
• Для устройств Android:
  • В магазине RuStore (рекомендуется для РФ): перейдите по ссылке https://www.rustore.ru/catalog/app/ru.e2m.app или найдите через поиск и нажмите «Скачать».
  • В магазине Google Play: перейдите по ссылке https://play.google.com/store/apps/details?id=ru.e2m.app или найдите через поиск и нажмите «Установить».

3.2.1. Установка на устройствах iOS

3.2.1.1. Ссылка для скачивания из «App Store»

1.Перейдите по ссылке https://apps.apple.com/ru/app/medapp-litelink/id6474684502

2.Откроется страница в «App Store» с описанием приложения MedApp LiteLink, здесь нажмите «Установить», либо на кнопку с изображением облака со стрелочкой

Перед загрузкой приложения возможно появление запроса на разрешение выполнения действия.

3.После установки приложения появится кнопка «Открыть», нажмите ее, чтобы запустить приложение

3.2.1.2. Установка вручную из «App Store»

1.Запустите приложение «App Store»

2.Перейдите в раздел поиска, в строке поиска введите MedApp LiteLink и нажмите найти

3.В результатах поиска выберите приложение MedApp LiteLink

4.Откроется страница описания приложения, здесь нажмите «Установить», либо на кнопку с изображением облака со стрелочкой

Перед загрузкой приложения возможно появление запроса на разрешение выполнения действия.

5.После установки приложения появится кнопка «Открыть», нажмите ее, чтобы запустить приложение

3.2.2. Установка на устройствах Android

3.2.2.1. Ссылка для скачивания из «Google Play»

1.Перейдите по ссылке https://play.google.com/store/apps/details?id=ru.e2m.app

2.Откроется страница в «Google Play» с описания приложения MedApp LiteLink, здесь нажмите «Установить»

Перед загрузкой приложения возможно появление запроса на разрешение выполнения действия.

3.После установки приложения появится кнопка «Открыть», нажмите ее, чтобы запустить приложение

3.2.2.2. Ссылка для скачивания из «RuStore»

1.Перейдите по ссылке https://www.rustore.ru/catalog/app/ru.e2m.app

2.Откроется страница «RuStore» с описанием приложения MedApp LiteLink, здесь нажмите «Скачать»

3.После установки приложения появится кнопка «Открыть», нажмите ее, чтобы запустить приложение

3.2.2.3. Установка вручную из «Google Play»

1.Запустите приложение «Google Play» (магазин приложений)

2.Перейдите в раздел поиска, здесь в строке поиска введите MedApp LiteLink и нажмите найти

3.В результатах поиска выберите приложение MedApp LiteLink

4.Откроется страница описания приложения, здесь нажмите «Установить»

Перед загрузкой приложения возможно появление запроса на разрешение выполнения действия.

5.После установки приложения появится кнопка «Открыть», нажмите ее, чтобы запустить приложение

3.2.2.4. Установка вручную из «RuStore»

1.Запустите приложение «RuStore» (магазин приложений)

2.В поисковой строке введите MedApp LiteLink и нажмите найти

3.В результатах поиска выберите приложение MedApp LiteLink

4.Откроется страница описания приложения, здесь нажмите «Скачать»

5.После установки приложения появится кнопка «Открыть», нажмите ее, чтобы запустить приложение

4. Проверка правильности установки

1.Запустите приложение на мобильном устройстве с помощью ярлыка «MedApp».

2.При первом запуске на экране появится запрос ОС на разрешение отправки Push-уведомлений — необходимо выбрать «Разрешить» для корректного получения оперативных уведомлений о пациентах и расписании.

3.Отображение экрана авторизации (ввод телефона или пары логин/пароль) подтверждает успешную установку мобильного клиента и его стабильное сетевое соединение с развернутым API-шлюзом.

Требования к персоналу, необходимому для обеспечения эксплуатации

Программное обеспечение MedApp. Правообладатель — ООО «ВИСМУТ».

1. Общие положения

Настоящий документ определяет требования к квалификации, подготовке и компетенциям персонала, необходимого для обеспечения корректной, стабильной и безопасной эксплуатации клиент-серверного программного комплекса «MedApp» (далее — ПО) в медицинских организациях.

Требования разделены на три категории в зависимости от выполняемых ролей в процессе жизненного цикла софта:

1.Конечные пользователи — медицинский персонал, непосредственно работающий с мобильным интерфейсом приложения.

2.Технический персонал на стороне заказчика — специалисты ИТ-подразделений медицинских организаций, обеспечивающие инфраструктурную связанность.

3.Персонал правообладателя (Служба поддержки) — штатные специалисты ООО «ВИСМУТ», осуществляющие сопровождение, устранение дефектов и модернизацию ПО.

2. Требования к конечным пользователям (медицинский персонал)

Для эксплуатации функциональных модулей мобильного приложения (поликлиника, стационар, вызовы на дом, вакцинация, реабилитация) медицинские работники должны соответствовать следующим минимальным требованиям:

• Базовые навыки: Наличие навыков работы с персональным компьютером и мобильными устройствами (смартфонами, планшетами) под управлением операционных систем Android или iOS на уровне уверенного пользователя.
• Знание предметной области: Наличие профильного медицинского образования, знание внутренних медицинских регламентов организации по ведению учетных записей и оформлению электронных медицинских карт (ЭМК).
• Программная подготовка: Обязательное изучение актуального «Единого руководства пользователя ПО MedApp». Персонал должен уметь проходить авторизацию (по логину/паролю или СМС-коду), выбирать рабочее место (профиль), работать со списками пациентов и заполнять электронные протоколы осмотров.

3. Требования к техническому персоналу на стороне заказчика (ИТ-отдел медицинской организации)

Для обеспечения развертывания, сетевой связанности и локального мониторинга серверной части API-шлюза (MedApp.Gateway) специалисты ИТ-службы медицинской организации должны обладать следующими компетенциями:

• Администрирование ОС и веб-серверов: Понимание принципов функционирования среды выполнения .NET Core / ASP.NET Core Runtime 9, опыт настройки и администрирования веб-серверов (Nginx, Apache или IIS) в качестве инверсных прокси-серверов.
• Работа с базами данных: Базовые навыки работы с СУБД PostgreSQL (версии 17.2 или выше), умение создавать пользователей, пустые базы данных и предоставлять права доступа для автоматического наката системных миграций.
• Сетевое администрирование: Знание протоколов TCP/IP, HTTPS, принципов маршрутизации и настройки корпоративных брандмауэров для обеспечения беспрепятственного обмена трафиком между мобильными устройствами врачей и серверным API-шлюзом по портам 80 и 443.

4. Требования к персоналу службы поддержки правообладателя (ООО «ВИСМУТ»)

Техническое сопровождение, профилактическое обслуживание, прием заявок в рамках SLA и устранение неисправностей ПО осуществляются штатным персоналом Сервисного центра ООО «ВИСМУТ» в количестве 1 человек являющийся гражданином Российской Федерации и находящихся на территории РФ. Специалисты службы поддержки обязаны соответствовать следующим жестким критериям квалификации:

• Образование и квалификация: Наличие высшего или среднего профессионального технического образования в области информационных технологий, системного анализа, прикладной информатики или программной инженерии.
• Технологический стек: Свободное владение инструментами среды .NET 9, методами анализа конфигурационных файлов (appsettings.json) и логов системы, формируемых библиотекой Serilog.
• Специализированные знания:
  • Глубокое знание архитектуры программного комплекса MedApp, логики взаимодействия модулей WebApi и планировщика Scheduler.
  • Опыт администрирования реляционных баз данных PostgreSQL, управления индексами и оптимизации SQL-запросов.
  • Понимание механизмов интеграции со сторонними сервисами рассылок авторизационных СМС-сообщений (МТС Omnichannel, МТС Exolve).
• Регламентная подготовка: Четкое знание и соблюдение «Описания процессов, обеспечивающих поддержание жизненного цикла ПО MedApp», стандартов SLA по времени реакции на инциденты (от 2 до 8 часов) и максимальным срокам исправления ошибок программного кода.

Единое руководство пользователя

Программное обеспечение MedApp. Правообладатель — ООО «ВИСМУТ».

1. Введение

1.1. Общие сведения о ПО

MedApp (далее — «Приложение» или «ПО») — это мобильное программное обеспечение, разработанное специально для медицинских организаций. Приложение предназначено для использования медицинским персоналом (врачами, медицинскими сестрами, реабилитологами и другими специалистами) в процессе оказания медицинской помощи.

ПО позволяет вести электронную медицинскую документацию, управлять расписанием приема пациентов, отслеживать критические показатели здоровья, работать с выездными формами помощи (прием на дому, вакцинация), а также обеспечивает оперативное взаимодействие между сотрудниками медицинской организации.

1.2. Назначение и область применения

MedApp предназначен для:

• Врачей поликлиник — для просмотра расписания приема пациентов, ведения протоколов осмотра, работы с электронной медицинской картой.
• Врачей стационара — для создания протоколов осмотра и дневниковых записей, просмотра информации о пациентах отделения.
• Врачей выездных служб — для оказания медицинской помощи на дому, проведения вакцинации.
• Специалистов по реабилитации — для выполнения процедур, ведения протоколов реабилитационных мероприятий.
• Всех сотрудников МО — для обмена сообщениями через встроенный чат и просмотра структуры организации.

1.3. Основные функциональные возможности

ПО MedApp предоставляет следующие ключевые функции:

2. Установка мобильного приложения

Приложение MedApp LiteLink распространяется бесплатно через официальные магазины приложений.

2.1. Установка на устройства iOS

Для установки на устройствах под управлением iOS (версии 15.0 и выше):

Способ 1: По прямой ссылке

1.Перейдите по ссылке: https://apps.apple.com/ru/app/medapp-litelink/id6474684502

2.Откроется страница приложения в App Store

3.Нажмите кнопку «Установить» или кнопку с изображением облака со стрелкой

4.Дождитесь завершения загрузки и установки

5.Нажмите «Открыть» для запуска приложения

Способ 2: Через поиск в App Store

1.Запустите приложение «App Store» на устройстве

2.Перейдите в раздел поиска (вкладка «Поиск»)

3.В строке поиска введите «MedApp LiteLink»

4.В результатах поиска выберите приложение MedApp LiteLink

5.Нажмите «Установить»

6.Дождитесь завершения установки и нажмите «Открыть»

2.2. Установка на устройства Android

Для установки на устройствах под управлением Android (версии 10.0 и выше):

Через Google Play:

1.Запустите приложение «Google Play»

2.В строке поиска введите «MedApp LiteLink»

3.В результатах поиска выберите приложение MedApp LiteLink

4.Нажмите «Установить»

5.Дождитесь завершения установки и нажмите «Открыть»

Прямая ссылка в Google Play:

• Перейдите по ссылке: https://play.google.com/store/apps/details?id=ru.e2m.app

Через RuStore (рекомендуемый способ для РФ):

1.Запустите приложение «RuStore»

2.В поисковой строке введите «MedApp LiteLink»

3.В результатах поиска выберите приложение MedApp LiteLink

4.Нажмите «Скачать»

5.Дождитесь завершения установки и нажмите «Открыть»

Прямая ссылка в RuStore:

• Перейдите по ссылке: https://www.rustore.ru/catalog/app/ru.e2m.app

3. Авторизация в системе

Для входа в приложение предусмотрено два способа авторизации.

3.1. Вход по номеру телефона

1.Запустите приложение MedApp на устройстве

2.На экране авторизации выберите вкладку «Телефон»

3.Введите номер телефона в формате 7XXXXXXXXXX

4.Нажмите кнопку «Продолжить»

5.На указанный номер телефона придет SMS-сообщение с кодом доступа

6.Введите полученный код в соответствующее поле

7.При необходимости установите 4-значный код для быстрого входа в следующий раз, либо нажмите «Пропустить»

Важно! Нажав «Пропустить», последующий вход в приложение будет осуществляться автоматически без ввода кода.

3.2. Вход по логину и паролю

1.Запустите приложение MedApp на устройстве

2.На экране авторизации выберите вкладку «Логин»

3.Введите ваш логин и пароль, выданные администратором системы

4.Нажмите кнопку «Продолжить»

4. Начало работы

4.1. Выбор рабочего места

После успешной авторизации необходимо выбрать рабочее место (профиль), под которым вы будете работать в системе:

1.Перейдите на вкладку «Профиль» в нижней части экрана

2.Нажмите кнопку «Выбор профиля»

3.В открывшемся списке выберите нужное рабочее место

4.При необходимости воспользуйтесь поисковой строкой для быстрого поиска

5.Нажмите кнопку «Подтвердить»

Рабочее место выбрано. Теперь вы можете приступать к работе с соответствующим модулем.

4.2. Управление сменой (для модуля реабилитации)

Для специалистов по реабилитации предусмотрена функция включения смены:

1.Перейдите на вкладку «Профиль»

2.Передвиньте переключатель «На смене» в положение «Включено»

3.После этого вам станут доступны активные процедуры для выполнения

5. Модуль «Расписание приемов врача поликлиники»

5.1. Назначение модуля

Модуль предназначен для просмотра в режиме онлайн списка пациентов, записанных на прием, а также исключительных событий (отсутствие врача, технические перерывы и т.п.).

5.2. Просмотр расписания на сегодня

1.После авторизации и выбора рабочего места перейдите на вкладку «Главная»

2.На экране отобразятся все пациенты, записанные на прием на сегодняшний день

3.Для каждого пациента отображается время приема, ФИО и статус записи

5.3. Просмотр расписания на любую дату

1.В верхней части экрана найдите календарь

2.Нажмите на любую дату, чтобы посмотреть расписание на выбранный день

3.Система отобразит всех пациентов и события, запланированные на эту дату

5.4. Отображение статусов пациентов

• «Закрытый» — пациент уже был обслужен в медицинской информационной системе (МИС)
• «Открытый» — пациент еще не обслужен, прием предстоит

5.5. Отображение исключительных событий

Исключительные события (например, совещания, перерывы) отображаются в расписании:

• Если исключительное событие пересекается по времени с приемом, то время приема выделяется цветом, соответствующим событию

• Свободное время (когда нет записи) подписано как «Свободно» и выделено голубым цветом

6. Модуль «Прием на дому»

6.1. Назначение модуля

Модуль предназначен для врачей, оказывающих медицинскую помощь на дому. Позволяет просматривать вызовы, создавать записи о проведенных осмотрах и закрывать случаи.

6.2. Просмотр списка вызовов

1.Перейдите на вкладку «Мои пациенты»

2.Здесь отображаются все вызовы на текущий день в хронологическом порядке

3.При необходимости воспользуйтесь строкой поиска по ФИО пациента

6.3. Оказание услуги без шаблона

1.В списке выберите нужного пациента

2.Откроется подробная информация по вызову

3.Нажмите кнопку «Создать запись»

4.В открывшемся окне заполните все обязательные поля протокола осмотра

5.Нажмите кнопку «Отправить»

Информация по пациенту будет передана в медицинскую информационную систему.

6.4. Оказание услуги с использованием шаблона

1.При создании записи нажмите кнопку «Использовать шаблон»

2.В открывшемся списке выберите нужный шаблон

3.В текущую запись подставятся значения всех заполненных полей из шаблона

4.При желании вы можете отредактировать любые поля

5.Нажмите кнопку «Отправить»

Подробнее о создании шаблонов см. в разделе 10.

6.5. Завершение случая

Если в МИС необходимо передать закрытый случай:

1.При заполнении протокола осмотра переведите переключатель «Случай закрыт» в положение «Включено»

2.Заполните поля «Результат» и «Исход»

3.Нажмите кнопку «Отправить»

7. Модуль «Выездная вакцинация»

7.1. Назначение модуля

Модуль предназначен для медицинских работников, проводящих выездную вакцинацию. Позволяет управлять списком пациентов, отмечать прохождение вакцинации или неявку, заполнять протоколы осмотра.

7.2. Выбор организации для вакцинации

1.Перейдите на вкладку «Вакцинации»

2.В списке выберите организацию, с которой будете работать

3.Откроется информация по вакцинируемой организации

7.3. Фильтрация пациентов по статусам

На вкладке с информацией об организации отображаются разделы, фильтрующие пациентов по статусу:

• «К вакцинации» — количество пациентов, которые еще ожидают вакцинации
• «Вакцинированы» — количество уже вакцинированных пациентов
• «Не допущены» — количество пациентов, не допущенных к вакцинации
• «Отсутствуют» — количество пациентов, не пришедших на вакцинацию

При необходимости вы можете заполнить поле «Тип вакцины» и нажать «Сохранить».

7.4. Заполнение протокола осмотра

1.Нажмите на раздел «К вакцинации»

2.Отобразится список пациентов, которых нужно вакцинировать

3.Выберите нужного пациента (при необходимости воспользуйтесь поиском)

4.Нажмите «Статус вакцинации — К вакцинации» для заполнения протокола осмотра

5.Заполните все необходимые поля протокола

6.Нажмите кнопку «Отправить»

! Если пациент не был допущен по каким-то причинам, то перед отправкой переместите бегунок «Не допущен» в положение включено.

7.5. Отметка о неявке пациента

Если пациент не пришел на вакцинацию:

1.В карточке пациента нажмите «Пациент не явился»

2.Пациенту автоматически будет присвоен соответствующий статус

7.6. Завершение вакцинации

После завершения работы со всеми пациентами:

1.На вкладке с информацией об организации нажмите «Завершить вакцинацию»

2.Статус организации изменится на «Вакцинация завершена»

Важно! После завершения всем необработанным пациентам автоматически присваивается статус «Отсутствуют».

8. Модуль «Врач стационара»

8.1. Назначение модуля

Модуль предназначен для врачей стационара. Позволяет отправлять в МИС заполненные протоколы осмотров и дневниковые записи, а также просматривать информацию о пациентах, находящихся в отделении.

8.2. Просмотр списка пациентов отделения

1.Перейдите в раздел «Мои пациенты»

2.Здесь отображаются все пациенты, находящиеся в отделении

3.Для каждого пациента доступна информация: диагноз, палата, лечащий врач, протоколы осмотров, дневниковые записи

4.При необходимости воспользуйтесь строкой поиска по ФИО

8.3. Создание протокола осмотра

1.В списке пациентов выберите нужного

2.Откроется подробная информация по пациенту

3.Нажмите кнопку «Создать запись»

4.В открывшемся окне выберите тип записи «Протокол осмотра»

5.Заполните все необходимые поля

6.Укажите диагноз

7.Нажмите кнопку «Отправить»

8.4. Создание дневниковой записи

1.В карточке пациента нажмите «Создать запись»

2.Выберите тип записи «Дневниковая запись»

3.Заполните все необходимые поля

4.Нажмите кнопку «Отправить»

8.5. Просмотр электронной медицинской карты пациента

1.В карточке пациента перейдите на вкладку «ЭМК»

2.Здесь отображаются все протоколы осмотров и результаты диагностических исследований

3.Для каждой записи указаны: тип записи, дата создания, врач, создавший запись

4.Нажмите на нужную запись для просмотра полного протокола/дневниковой записи

9. Модуль «Реабилитация»

9.1. Назначение модуля

Модуль предназначен для специалистов по реабилитации. Позволяет просматривать список пациентов, записанных на процедуры, запускать и завершать процедуры, заполнять протоколы.

9.2. Управление сменой

Перед началом работы необходимо включить смену:

1.Перейдите на вкладку «Профиль»

2.Передвиньте переключатель «На смене» в положение «Включено»

9.3. Просмотр активных процедур

1.Перейдите в раздел «Мои пациенты»

2.Выберите пациента

3.Отобразится список процедур в статусе «Ожидает выполнения» (вкладка «Активные»)

9.4. Запуск и выполнение процедуры

1.Напротив нужной процедуры нажмите кнопку «Запуск»

2.У процедуры отобразится время начала

3.Статус процедуры изменится на «Выполняется»

Важно! В случае, если у пациента не созданы направление или талон, система выдаст соответствующую ошибку.

! Если необходимо отменить начало процедуры нажмите кнопку «✕»

9.5. Заполнение протокола процедуры

1.В процессе выполнения процедуры нажмите «Заполнить протокол»

2.В открывшемся окне заполните все обязательные поля

3.При необходимости используйте шаблон (см. раздел 10)

4.Нажмите кнопку «Отправить»

9.6. Завершение процедуры

1.После завершения процедуры нажмите кнопку завершения (стоп-кнопка)

2.Процедура отобразится на вкладке «Завершенные»

3.После этого процедура отобразится на вкладке «Завершенные»

10. Работа с шаблонами протоколов

10.1. Назначение шаблонов

Шаблоны позволяют быстро заполнять типовые протоколы осмотров, дневниковые записи и протоколы процедур, сокращая время на оформление документации.

10.2. Создание нового шаблона

1.Перейдите на вкладку «Профиль»

2.Выберите раздел «Шаблоны протоколов»

3.Нажмите кнопку «Создать шаблон или группу»

4.Выберите элемент «Новый шаблон»

5.Укажите название шаблона

6.При необходимости добавьте шаблон в группу (для удобства сортировки)

7.Выберите тип создаваемого шаблона:

• Для модуля «Врач стационара»: «Протокол осмотра» или «Дневниковая запись»
• Для других модулей: соответствующий тип записи

8.Заполните все необходимые поля создаваемого шаблона

9.Нажмите кнопку «Сохранить»

Шаблон создан и готов к использованию.

10.3. Создание шаблона на основе предыдущей записи

1.После заполнения всех обязательных полей протокола осмотра, дневниковой записи или протокола процедуры нажмите «Отправить»

2.В следующем окне выберите «Сохранить как шаблон»

3.Укажите название шаблона

4.При необходимости добавьте шаблон в группу

5.Нажмите «Сохранить»

Шаблон создан на основе заполненной записи.

10.4. Использование шаблона при оказании услуги

1.При создании записи или протокола нажмите кнопку «Использовать шаблон»

2.В открывшемся списке выберите нужный шаблон

3.В текущую запись подставляются значения всех заполненных полей из шаблона

4.При желании вы можете отредактировать любые поля

5.Нажмите кнопку «Отправить» (или «Завершить» для процедуры)

11. Встроенный чат для общения с коллегами

11.1. Переход в раздел «Чат»

1.Перейдите на вкладку «Профиль»

2.Выберите раздел «Чат»

11.2. Просмотр существующих чатов

В открывшемся окне отображаются все чаты, с которыми вы ранее взаимодействовали.

11.3. Создание нового чата

1.Нажмите кнопку «+» в правом верхнем углу

2.В списке найдите сотрудника, которому хотите написать

3.При необходимости воспользуйтесь строкой поиска

4.Нажмите на имя сотрудника для создания чата

11.4. Отправка сообщений

1.В открывшемся окне чата вы можете увидеть историю переписки

2.В поле ввода внизу экрана напишите сообщение

3.Нажмите кнопку отправки

12. Структура медицинской организации

12.1. Просмотр сотрудников

1.Перейдите на вкладку «Профиль»

2.Выберите раздел «Структура МО»

В этом разделе отображаются все сотрудники вашей медицинской организации, включая тех, кто не использует приложение MedApp.

13. Push-уведомления

13.1. Настройка уведомлений

1.В настройках вашего мобильного устройства разрешите отправку уведомлений для приложения MedApp

2.При первом запуске приложения система запросит разрешение на отправку Push-уведомлений — необходимо выбрать «Разрешить»

13.2. Получение уведомлений о вызовах

После настройки все новые вызовы будут приходить во всплывающих уведомлениях на экране телефона.

14. Техническая поддержка

При возникновении вопросов или проблем с работой приложения обращайтесь в службу технической поддержки:

• Телефон: 7 922 610 55 31
• Электронная почта: info@vismuth.ru
• Время работы: понедельник — пятница, 9:00–18:00 по МСК +2