Информационные системы для скорой медицинской помощи

[Евгений Викторович]

Обсуждение и информация об Информационных системах для скорой медицинской помощи в России (плюсы и минусы, проблемы и решения).

Список предлагаемых МИС для скорой медицинской помощи, найденных в сети Internet:
1. Программный Комплекс "АДИС" ООО «Новые системные технологии», г. Москва
2. АСУ «Скорая помощь» ООО "Фуджицу Сервисез" (ICL-КПО ВС Группа компаний Fujitsu) г. Казань
3. ПК «МИСС-03», Сидоров Александр Иванович г. Новосибирск
4. ООО «СофтМастер» АИДС "Скорая медицинская помощь", г. Москва
5. ДДС «ИСТОК-СМ», ЗАО НТЛ «Нэкст Техника», г. Владивосток

Желательно бы узнать отзывы о них от пользователей данных МИС.

[Сацкевич Александр Анатольевич]

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

[Евгений Викторович]

Мы используем программный продукт АСУ «Скорая помощь» ООО "Фуджицу Сервисез" (ICL-КПО ВС Группа компаний Fujitsu) г. Казань (Свидетельство об официальной регистрации программы для ЭВМ № 2006613222 от 13.09.2006 г.). На Ежегодном конкурсе разработок в области информатизации здравоохранения отмечена, как «Лучшая медицинская информационная система» в 2009 году. Особым решением конкурсной комиссии система АСУ "Скорая помощь" была отмечена дипломом 1 степени. Председателем Конкурсной комиссии был господин Лебедев Георгий Станиславович, заместитель директора по информационным технологиям ЦНИИ ОИЗ.
Администрация ССМП на это купилась, а теперь страдать приходится пользователям АСУ.
Система отличается НЕ стабильной функциональностью, НЕ гибкой настройкой параметров работы под нужды организации и НЕ простотой в эксплуатации. При этом параметры настройки функций разработчики оставили себе, а не администратору системы, т.е. если желаешь расширить функционал системы – плати разработчику дополнительно! Но в отличие от фирмы АДИС, прейскуранта цен на дополнительные функции на сайте производителя нет!
Первое впечатление, что при написании технического задания для АСУ, медицинские консультанты не привлекались. Взяв за основу приказ МЗСР РФ от 2 декабря 2009 г. № 942 «Об утверждении статистического инструментария станции (отделения), больницы скорой медицинской помощи», разработчики попытались на его основе создать коммерческий проект, и естественно заложили в него все неточности и разночтения приказа, добавив ещё и своих при формализации. Например, в системе присутствуют два алгоритма посыла на вызов – по поводу к вызову (оказание медицинской помощи) и особый - по диагнозу (при перевозках), что приводит к невозможности проводить учёт непрофильных перевозок (как в дальнейшем их выбрать, например, перевозки на томограф, если повод – диагноз?). Другой ляпсус – в списке травматизма – роды вне ЛПУ?! Или в списке диагнозов - повод к вызову (видимо для реализации особого алгоритма по диагнозам)?!
Часть ляпов, после указания на их нелепость, разработчики на нашей ССМП устранили, про другие станции сказать не могу.
Особо хочется отметить реализацию т.н. "подписки" - основного источника ошибок с персональным составом выездных бригад, без возможности исправления после окончания смены при выявлении!
И это только единичные примеры!
Из дополнительных недостатков: недостаточная информативность экранных форм для диспетчеров направления, отсутствует защита "от дурака" на правильность заполнения обязательных полей БД (например, вид травматизма с привязкой к классу «Травмы и отравления»), имеются ошибки в алгоритмах расчётов стандартных отчётных форм, представленных в АСУ, «зависание» Системы при потере связи с сервером, когда единственное решение проблемы – кнопка «Reset»!
При этом АСУ активно внедряется по регионам, поскольку нормальной сертификации программы для здравоохранения с привлечением специалистов скорой помощи никто не проводил!

[Сацкевич Александр Анатольевич]

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

[Евгений Викторович]

А вообще-то, интересно было бы узнать мнение о данном продукте у других пользователей АСУ, может быть моё мнение предвзятое или подобное только у нас? Разработчики утверждают, что другие города работают с данной АСУ без проблем и их (пользователей) всё устраивает. Кто-то лукавит!

Неужели у пользователей АСУ нет проблем?
Похоже, данный ресурс во всех отношениях удобный для специалистов, организаторам здравоохранения мало известен?!

Набережные челны, Нижнекамск, Альметьевск, Бугульма, Зеленодольск, Азнакаево, Чебоксары, Октябрьский, Нальчик, Якутск, Ленск, Покровск, Архангельск, Коряжма, Котлас, Астрахань, Губкин, Старый Оскол, Чебоксары, Калининград, Мурманск, Красногорск, Чехов, Черноголовка, Звенигород, Электросталь, Королев, Пенза, Псков, Рязань, Северск, Алексин, Новый Уренгой, Когалым, Нягань, Снежинск отзовитесь! У вас нет проблем?

[Евгений Викторович]

Вот отзыв о программном продукте от МБЛПУ "ССМП" г. Томска
31 октября 2004 г. на нашей станции был внедрен ПК "АДИС" v 7.4 ООО "Новые Системные Технологии", г. Москва.
в 2006 г. перешли на версию 7.6, в которой были устранены некоторые недочеты и расширен функционал.
Связь с подстанциями осуществляется по выделенным линиям посредством модемов.
Программный комплекс "АДИС" обладает довольно высокой стабильностью и простотой обслуживания, удобством использования в оперативном отделе, основной функцией которого является прием и передача вызовов. Позволяет создавать и(или) редактировать порядок посыла бригад в зависимости от повода, места, возраста; справочники поводов, диагнозов, медикаментов и др.; отчеты и выборки за любой период времени. Имеется возможность редактирования шаблонов печати (в нашей практике создавали только карту вызова). Позволяет записывать и прослушивать телефонные разговоры.
Имея распределенную базу данных, позволяет быстро и безболезненно менять как АРМы, работающие в системе, так и сам сервер.
Однако в программном комплексе "АДИС" критическими являются два рабочих места - это АРМ старшего врача, АРМ диспетчера – эвакуатора и сам сервер. При сбоях или выходе из строя которых (хотя бы одного из них) система перестает функционировать. В этих случаях приходится заново запускать весь комплекс. Потерю данных в таких случаях не наблюдали.
Несмотря на удобства программы в работе оперативного отдела, ее использование в отделе статистики оказалось невозможным из-за ограниченного количества полей. В базе отсутствуют такие данные как отчество, регистрация по месту жительства, информация о передаче больного в другие учреждения. В карту вызова можно внести только 2 диагноза, на практике иногда требуется больше. Добавление же новых полей является платной опцией  разработчика. Кроме того,  база храниться в текстовых файлах, и работа с ней затруднительна.
Большим плюсом ПК "АДИС" является его кроссплатформенность и нетребовательность к аппаратным ресурсам.
За время работы рассматривали и другие программные продукты:
город Северск - АСУ "Скорая помощь", разработанная в г. Казани; 
город Барнаул - ПК МИС-03, разработанная в г. Новосибирске; 
рассматривали "Таганрогскую" программу.
Все программы имели свои особенности, но наиболее приемлемым вариантом мы посчитали ПК "АДИС". На сегодняшний день рассматриваем вопрос, о переходе на более свежую версию АДИС.

Об АСУ "Скорая помощь" - смотрели эту систему в городе Северске года два назад. Систему рассматривали в первую очередь для работы оперативного отдела (прием-обработка-передача адресов). В этом плане система показалась очень неудобной. Комплекс не предлагает бригаду в зависимости от повода, места, ..., срочности адреса, в "АДИС" существует алгоритм, предлагающий определенную бригаду на определенный адрес. Причем этот алгоритм можно корректировать.
Отчетов действительно много. Но опять же в самой системе не предусмотрено создание новых. Насколько я помню, они просят своих программистов, которые создают отчеты в сторонней программе, используя базу АСУ "Скорая помощь".

[Drago23]

А вообще-то, интересно было бы узнать мнение о данном продукте у других пользователей АСУ, может быть моё мнение предвзятое или подобное только у нас? Разработчики утверждают, что другие города работают с данной АСУ без проблем и их (пользователей) всё устраивает. Кто-то лукавит!

Неужели у пользователей АСУ нет проблем?
Похоже, данный ресурс во всех отношениях удобный для специалистов, организаторам здравоохранения мало известен?!

Набережные челны, Нижнекамск, Альметьевск, Бугульма, Зеленодольск, Азнакаево, Чебоксары, Октябрьский, Нальчик, Якутск, Ленск, Покровск, Архангельск, Коряжма, Котлас, Астрахань, Губкин, Старый Оскол, Чебоксары, Калининград, Мурманск, Красногорск, Чехов, Черноголовка, Звенигород, Электросталь, Королев, Пенза, Псков, Рязань, Северск, Алексин, Новый Уренгой, Когалым, Нягань, Снежинск отзовитесь! У вас нет проблем?

Я работаю в Пскове - начальник технического отдела Псковской СМП. У нас как раз используется казанская АСУ "Скорая помощь".  Существенные недостатки данной системы - мгновенное зависание клиента при потере связи с сервером, отсутствие синхронизации времени клиентской машины с сервером, из-за чего в отчетности идут задержки в выезде бригады, таинственные сбои в работе серверной части, из-за чего наблюдались такие вещи, как печать девятикратно уменьшеной карты вызова, исчезновение всех отчетов - просто голые поля, загадочное слетание системы печати, вылечено путем переустановки МС Оффис. Кроме того, крайне не понравились некоторые, не отраженные ни в каких документах нюансы при переустановке клинтской части: необходимо вручную прописывать язык ввода в одном из полей алиаса serv1b, иначе невозможен вход в подсистему "администратор" и "справочник", при запуске подсистемы "справочник" ПК автоматически переключается на русский язык ввода, причем совершенно непонятно зачем - ведь пароль вводится исключительно латиницей.

Надо отдать должное казанцам - проблемы решают достаточно оперативно, но при этом отдай за годовое обслуживание 100 тысяч рубликов. В данный момент нами обдумывается вопрос о переходе  на пензенский комплекс АПК "Управление станциями скорой медпомощи", интегрированый с навигационным комплексом ГИТ "СМП". Очень интересные решения используются, при этом формы для ввода данных позаимствованы из казанской АСУ, что должно обблегчить освоение нового ПО персоналом.

Если кого заинтересует, сайт разработчика: http://www.lotsman.net/Pages/default.aspx

[Евгений Викторович]

Уважаемый Drago23
Спасибо за Ваш комментарий к АСУ "Скорая помощь"
У меня имеется к Вам, как пользователю АСУ, один вопрос, который не можем разрешить с разработчиками.
Если Вы помните, на форме "Критерии поиска" имеется флажок "Не заполнен талон", по выбору которого в окне Журнал отображаются данные, в которых отрывной талон к сопроводительному листу не заполнен!
Данная информация никак не может относиться к разряду оперативной информации и я предложил разработчикам данный переключатель изменить на обратный, т.е. на "Заполнен талон", но получил ответ, что подобный переключатель устраивает всех пользователей АСУ.
Вопрос: Что для Вас важнее, чтобы выводились в Журнале данные о заполненных отрывных талонах к сопроводительным листам, или данные о незаполненных талонах?

[Евгений Викторович]

Недавно познакомился с АИДС "Скорая медицинская помощь", ООО «СофтМастер» г. Москва
Разработчики предоставили возможность реально поработать в системе на примере ССМП г. Ростов, за что им большое спасибо!
Есть у разработчиков очень хорошие решения, например Администрирование по правам доступа.
В отличие от АСУ "Скорая помощь", разработчики пошли по пути не самим разрешать/запрещать что либо в системе, а предоставить эти полномочия администратору системы. Кроме того, система предусматривает возможность ввода комбинированных диагнозов (как реально возможно в медицинской практике до 4х вариантов), есть другие хорошие решения (подписки, как  в АСУ "Скорая помощь", – у них нет). Имеется встроенный генератор произвольных отчётов!
В целом можно отметить, что это перспективная разработка для ССМП с большим потенциалом.
Но при этом требуется доработка (первое, что бросилось в глаза):
1. Блок диспетчеров приёма-передачи вызова:
- немасштабируемость экранной формы ввода данных о вызове (шрифт на ней желательно увеличить для снижения нагрузки на глаза пользователей);
- не удобен ввод времени работы на вызове(через список).
- не совсем понятна в системе градация поводов по срочности обслуживания(обратил внимание, что на улицу отметка выставляется сразу "экстренный")
- не понятная работа с дубликатами вызовов(т.е. просто удаление и списка?) без указания дубликата какого вызова.
2. Ввод диагнозов позволяет заполнять поле классами и блоками МКБ-10 или вводить диагноз вообще без кодов МКБ-10, что неправильно и нарушает статистику!
3. Модуль "Список бригад": Привязка персонала к конкретной машине и бригаде не во всех случаях оправдана
4. Не нашёл возможности преждевременного завершения работы сотрудником(например, заболел).
Выставить время фактического начала/окончания работы сотруднику не смог - ошибка интервала!
5. Заполнение карты вызова ограничено значениями из списков, где отражены не все возможные варианты.
Возможно, это можно сделать через редактирование справочников, не проверял.

[Drago23]

Уважаемый Drago23
Спасибо за Ваш комментарий к АСУ "Скорая помощь"
У меня имеется к Вам, как пользователю АСУ, один вопрос, который не могу разрешить с разработчиками.
Если Вы помните, на форме "Критерии поиска" имеется флажок "Не заполнен талон", по выбору которого в окне Журнал отображаются данные, в которых отрывной талон к сопроводительному листу не заполнен!
Данная информация никак не может относиться к разряду оперативной информации и я предложил разработчикам данный переключатель изменить на обратный, т.е. на "Заполнен талон", но получил ответ, что подобный переключатель устраивает всех пользователей АСУ.
Вопрос: Что для Вас важнее, чтобы выводились в Журнале данные о заполненных отрывных талонах к сопроводительным листам, или данные о незаполненных талонах?

Уважаемый Евгений Викторович! К сожалению (точнее, учитывая капризы системы, к счастью) я не пользователь АСУ "Скорая помощь". Я имею несчастье быть начальником тех. отдела - т.е. системный администратор + другие обязанности. Поэтому я поспрашивал персонал, который работает с АСУ, на что получил ответ, что им был бы предпочтительнее Ваш вариант. Просто потому, что незаполненных талонов всегда больше. Казанцы о наших предпочтениях в данном вопросе не спрашивали, потому знать, что нам удобнее им неоткуда. Полагаю, что и никого не спрашивали. Им проще ответить так и ничего не делать.  Вы бы знали, с каким скрипом они согласились изменить для нас форму карты вызова в связи с переименованием организации, а надо-то было изменить аббревиатуру "МУЗ" на "ГБУЗ"

[Drago23]

5 мая пензенцы провели для руководства нашей СМП и присутсвовавшего представителя областного комитета по здравоохранению видеопрезентацию своей системы АПК "Управление станциями скорой медпомощи". Сразу скажу о недостатках. Это, в первую очередь, цена вопроса (хотя, на мой взгляд, система того стоит и скупой платит дважды, но  деньги мы не печатаем), а во вторую - систему стоит использовать в городах, где у СМП есть подстанции. Иначе не получится полностью использовать ее потенциал. Ну, или, использовать сразу в масштабе области. Схема организации системы выглядит следующим образом:

трекер на а/м ---> ЦОД (центр обмена данными) <---> кластер (сервер системы на СМП или подстанции) <---> АРМ.

Сам АПК интегрирован  с системой контроля и слежения за а/м "ГИТ СМП". Собственно, именно в этом состоит "изюминка" пензенской разработки. Выглядит работа системы следующим образом: на экране диспетчера в левой части экрана форма приема вызова, в правой - карта. При приеме вызова происходит мгновенная автоматическая привязка адреса к карте. Если адреса нет, то диспетчер может назначить место вызова простым кликом мышки по карте. После чего вызов переходит к диспетчеру направления. Диспетчер направления видит на карте города обстановку в реальном времени: все работающие бригады с визуальным отображением статуса (свободен, на вызове, на обеде и т.д.), текущие вызовы и т.п. В соответствии с обстановкой диспетчер направления может назначить на вызов любую бригаду, как находящуюся на станции, так и возвращающуюся после обслуживания предыдущего вызова. В Пензе как правило назнается ближайшая к месту вызова бригада, хотя, в зависимости от диагноза, система может автоматически предложить бригаду по профилю (если такие имеются). Это делается простым кликом мыши по значку бригады. После чего система автоматически прокладывает кратчайший маршрут от места нахождения бригады до места вызова (естественно, по дорогам, срезать маршрут через дворы она не умеет).  Затем диспетчер направления передает всю информацию по вызову на АРМ бригады. Для этого у бригад имеются планшетники. Удобно то, что не надо тратить время на вызов по рации и объяснение ситуации, особенно если вызов не с адреса а с каких-нибудь задворок. Как говорится, легким движением руки... Получив вызов, врач бригады подтверждает прием, соответственно меняется статус бригады у диспетчера направления.
Из дополнительных удобств то, что система при приеме вызова старается получить дополнительную информацию из внешних источников - например, данные пациента из базы ФОМС, историю болезни (если оцифрована), историю предыдущих обращений. Все это так же поступает на АРМ бригады. Плюс планшетник позволяет документировать обстановку на вызове и, при необходимости, получить в реальном времени консультацию  старшего врача.

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

Предусмотрена и пробная работа в системе, но сейчас этот сервис у них что-то барахлит, так что сам не пробовал.

[Евгений Викторович]

Уважаемый Drago23
Спасибо за Ваш ответ по поводу переключателя для отрывного талона к сопроводительному листу в АСУ "Скорая помощь"
У меня имеется к пользователям Вашей версии АСУ, ещё вопрос, который не можем разрешить с разработчиками.
Как Вы относитесь к реализации в АСУ т.н. функционала подписки? В соответствие с ней, по утверждению разработчиков  «... фактом выхода сотрудника в смену является не данные наряда (время работы сотрудника в смену), а именно ... отметка факта его прихода диспетчером", т.е. компьютерное (системное) время, когда диспетчер отметит приход сотрудника. А если диспетчер, по какой-либо причине, не успел во-время подписать сотрудника - то время начала его работы будет не заявленое в наряде на смену, а именно то, которое система (компьютер) отметит при подписки! Решение проблем подписки, предлагаемое разработчиками - применение дисциплинарных взысканий к нерадивым работникам! Каково?!
Кто у вас в АСУ занимается подпиской? Имеются ли у Вас проблемы с подпиской?

5 мая пензенцы провели для руководства нашей СМП и присутсвовавшего представителя областного комитета по здравоохранению видеопрезентацию своей системы АПК "Управление станциями скорой медпомощи".

А где можно ознакомиться с презентацией системы АПК "Управление станциями скорой медпомощи"? На указанном Вами сайте http://www.lotsman.net/Pages/default.aspx я не нашёл ничего, связанного с информатизацией станции скорой помощи.

[Drago23]

Уважаемый Drago23
Спасибо за Ваш ответ по поводу переключателя для отрывного талона к сопроводительному листу в АСУ "Скорая помощь"
У меня имеется к пользователям Вашей версии АСУ, ещё вопрос, который не могу разрешить с разработчиками.
Как Вы относитесь к реализации в АСУ т.н. функционала подписки? В соответствие с ней, по утверждению разработчиков  «... фактом выхода сотрудника в смену является не данные наряда (время работы сотрудника в смену), а именно ... отметка факта его прихода диспетчером", т.е. компьютерное (системное) время, когда диспетчер отметит приход сотрудника. А если диспетчер, по какой-либо причине, не успел во-время подписать сотрудника - то время начала его работы будет не заявленое в наряде на смену, а именно то, которое система (компьютер) отметит при подписки! Решение проблем подписки, предлагаемое разработчиками - применение дисциплинарных взысканий к нерадивым работникам! Каково?!
Кто у вас в АСУ занимается подпиской? Имеются ли у Вас проблемы с подпиской?

Уважаемый Евгений Викторович!
Подпиской у нас занимается диспетчер направления. Да, это не очень удобно, но на данный момент другого приемлемого варианта не существует. Если руководствоваться только данными наряда, то можно оказаться в ситуации, когда сотрудник не вышел на работу, но система считает что он есть. Пока нет автоматизированной системы учета времени прихода сотрудников, от подписки, судя по всему, никуда не денешься.

А где можно ознакомиться с презентацией системы АПК "Управление станциями скорой медпомощи"? На указанном Вами сайте http://www.lotsman.net/Pages/default.aspx я не нашёл ничего, связанного с информатизацией станции скорой помощи.

М-м-м... О проведении презентации мы договаривались. Тел. (8412) 254051 Сергей Ягольницкий. А страничку о АПК "Управление станциями скорой медпомощи" надо было смотреть на сайте разработчиков в разделе "наши решения". Впрочем, для  экономии времени вот точный адрес страницы: http://www.lotsman.net/Pages/Проект-по-управлению-станциями-скорой-помощи.aspx

[Евгений Викторович]

Уважаемый Drago23

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

Своим ответом об отсутствии вариантов Вы прямо бальзам на душу разработчикам излили!   
Вопрос не стоит об отмене контроля за выходом персонала на работу, а именно об улучшении функционала этой подписки.
Имеется и другой, приемлемый вариант и разработчикам он неоднократно предлагался!
Суть его в том, чтобы оптимизировать ВЕСЬ функционал подписки, уменьшив влияние человеческого фактора и освободив диспетчеров от ненужной работы, на основных принципах:
1. Подписчику оставить возможность вносить только отклонения в наряде за текущую смену! При этом само время подписки не должно иметь решающего значения! Важными являются именно изменения во времени начала и окончания работы сотрудника, профиль бригады и другие изменяемые параметры, т.е. отклонения! Следовательно, если нет отклонений от наряда в смену – обработку нужно осуществлять по умолчанию!
2. Обработка умолчаний – если не заявлено иное (нет отклонения), провести подписку работника автоматически по данным наряда за рабочую смену (а не по времени подписки!).
3. Диспетчеров оперативного отдела избавить от необходимости вносить начало смены для бригад, оставив только функционал окончания смены в случаях, когда необходимо принудительно завершить смену для бригады.
Детали реализации можно было бы обсудить, было бы на то желание разработчиков!
Кстати, не пытались ли Вы провести подписку для бригады время начала работы которой меньше общей смены станции (у нас это с 08:00 до 08:00) например, с режимом работы 06:30 - 06:30? Не получится,  т.к. бригады почему-то ещё привязаны к этой общей смене станции, несмотря на то, что у каждой бригады свой режим работы, отличный от этой общей смены станции?! А у нас на ССМП есть такая бригада и она нужна именно на данный временной интервал.

[Drago23]

Уважаемый Drago23

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

Своим ответом об отсутствии вариантов Вы прямо бальзам на душу разработчикам излили!   
Вопрос не стоит об отмене контроля за выходом персонала на работу, а именно об улучшении функционала этой подписки.
Имеется и другой, приемлемый вариант и разработчикам он неоднократно предлагался!
Суть его в том, чтобы оптимизировать ВЕСЬ функционал подписки, уменьшив влияние человеческого фактора и освободив диспетчеров от ненужной работы, на основных принципах:
1. Подписчику оставить возможность вносить только отклонения в наряде за текущую смену! При этом само время подписки не должно иметь решающего значения! Важными являются именно изменения во времени начала и окончания работы сотрудника, профиль бригады и другие изменяемые параметры, т.е. отклонения! Следовательно, если нет отклонений от наряда в смену – обработку нужно осуществлять по умолчанию!
2. Обработка умолчаний – если не заявлено иное (нет отклонения), провести подписку работника автоматически по данным наряда за рабочую смену (а не по времени подписки!).
3. Диспетчеров оперативного отдела избавить от необходимости вносить начало смены для бригад, оставив только функционал окончания смены в случаях, когда необходимо принудительно завершить смену для бригады.
Детали реализации можно было бы обсудить, было бы на то желание разработчиков!
Кстати, не пытались ли Вы провести подписку для бригады время начала работы которой меньше общей смены станции (у нас это с 08:00 до 08:00) например, с режимом работы 06:30 - 06:30? Не получится,  т.к. бригады почему-то ещё привязаны к этой общей смене станции, несмотря на то, что у каждой бригады свой режим работы, отличный от этой общей смены станции?! А у нас на ССМП есть такая бригада и она нужна именно на данный временной интервал.

Уважаемый Виктор Евгеньевич!

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