Информатизация > МИС и другие вопросы информатизации
Информационные системы для скорой медицинской помощи
Сорокин Олег:
Вопрос о том что пограмма создавалась под нас, я озвучил для того что-бы объяснить логику событий. На том уровне который имеется сейчас эта программа тоже является типовым решением для работы станции СМП или отделения, по крайней мере есть реальные результаты успешной реализации в вопросах приёма вызова отслеживания и оперативного руководства бригадами в процессе выполнения, навигации и взаимодействия эктсренных служб. Все последующие задачи решаются по мере нарастания требуемых функций и идут как дополнительные настройки конкретизирующие выполнение поставленных задач. Данные вводятся в режиме реального времени по мере выполнения вызова, дополнительные по мере обработки карт, а из этой базы получаем всю статистику какая требуется. Вопрос в том что стандарта устанавливающего определённый порядок нет, вот и действуем как считаем нужным. Будет стандарт без проблем будем исполять техонологически это и исполняется просто. Потенциально заложены неограниченные возможности главное определиться с задачами. Но это не требует преобразований системы. А по поводу уведомления логично оставить карту как учётный бумажный носитель только заполнять его по унифицированной схеме и хранить по правилам.
Евгений Викторович:
--- Цитата: Сорокин Олег от 24 Сентября 2012, 05:33:06 ---...На том уровне который имеется сейчас эта программа тоже является типовым решением для работы станции СМП или отделения...
--- Конец цитаты ---
Уважаемый коллега, "типовое решение" подразумевает, как минимум, соответствие утверждённым стандартам, регламентам и протоколам (единые справочники типа КЛАДР, МКБ10, единые протоколы обмена данными и т.п.). В вашей системе ещё очень много "авторизмов", поскольку единых требований к комплексной МИС для ССМП на Федеральном уровне пока нет!
--- Цитата: Сорокин Олег от 24 Сентября 2012, 05:33:06 ---... А по поводу уведомления логично оставить карту как учётный бумажный носитель только заполнять его по унифицированной схеме и хранить по правилам.
--- Конец цитаты ---
... после предварительной распечатки из МИС для СМП!
Из карты вызова, возможно, данные о различных отказах и согласиях пациента можно будет удалить, освободив место для других данных, т.к. Минздрав России разрабатывает единые формы согласия (отказа) пациента: Проект приказа Минздрава России от 31 августа 2012 г. "Об утверждении порядка дачи информированного добровольного согласия на медицинское вмешательство и отказа от медицинского вмешательства в отношении определенных видов медицинского вмешательства, формы информированного добровольного согласия на медицинское вмешательство и формы отказа от медицинского вмешательства"
Сорокин Олег:
Я поэтому и хочу пообщаться и обсудить все вопросы связанные с автоматизацией работы. Мне кажется лучше попробовать и сделать нечто жизнеспособное на этапе разработки и которое устроит всех, а затем это совершенствовать, чем придумать нечто трудноисполнимое и пытаться любой ценой его внедрить. Тем более, как Вы правильно заметили что единых стандартов нет и кто нам в таком случае мешает их для себя определить и выработатать разумное решение устраивающее всех. По поводу позиции НЭКСТ ТЕХНИКИ как разработчика, могу пояснить мы предложили им вариант решения медицинского фрагмента (конкретно службы СМП) по схеме нашей работы с возможностью решения задач на современном уровне и способностью развития. Важно что можно работать как в системе так и самостоятельно используя все положительные качества единой системы. Мне кажется логичным работать в едином блоке как самостоятельный фрагмент чем иметь уникальную самостоятельность и пытаться ей сооединить с другими подобными системами, а суть та же, выполнение своих задач, но более сложным способом. По поводу карты вызова если её вести в электронном виде то не важно сколько там места, хотя тот вариант который есть реально мелковат и имеет много лишнего вернее неудобного для заполения и обработки.
Евгений Викторович:
--- Цитата: Сорокин Олег от 25 Сентября 2012, 03:15:29 ---... Мне кажется лучше попробовать и сделать нечто жизнеспособное на этапе разработки и которое устроит всех, а затем это совершенствовать, чем придумать нечто трудноисполнимое и пытаться любой ценой его внедрить...
--- Конец цитаты ---
Не вдаваясь в технические вопросы реализации, т.к. это уже разработка технического задания для МИС, думаю что обозначить круг задач и основные требования к комплексной МИС для СМП на Федеральном уровне, обязательные для разработчиков - задача вполне решаемая.
Попытаюсь это пояснить.
Любая комплексная МИС для СМП должна поддерживать весь технологический цикл работы: от приема и распределения вызовов до статистической обработки информации, а также формирование графика нарядов, учет медикаментов, автоматизацию вспомогательных участков, деятельность которых обеспечивает решение основных задач СМП.
Комплексная МИС для СМП должна иметь функции контроля качества и анализа деятельности станции и её подразделений за любой промежуток времени, формировать данные для ответов на запросы учреждений и населения по поводу оказания скорой помощи, интеграция с ФОМС.
В рамках комплексной МИС для СМП должны решаться следующие основные задачи:
1. Формирование единой персонифицированной базы данных пациентов, обратившихся за оказанием скорой медицинской помощи; (требования приказа МЗСР РФ №179)
2. Прием и регистрация поступающих от населения вызовов (скорая и неотложная помощь, плановая и экстренная перевозки) с записью телефонных переговоров и автоматическим определением номера телефона, интегрированные с основной системой, используемые при приёме вызовов ; (требования приказа МЗСР РФ №179)
3. Автоматическая расстановка принятых вызовов в порядке приоритетности их обслуживания;
4. Оперативное диспетчирование всех принятых вызовов в режиме реального времени;
5. Слежение за местоположением и состоянием подвижного состава в режиме реального времени с использованием современных навигационных систем, контроль по времени (ГЛОНАС/GPS);
6. Учет заполненных карт вызова;
7. Учет персонала, формирование графика нарядов и регистрация отклонений от графика;
8. Учет поступления и расхода медикаментов и перевязочных материалов;
9. Ведение специальных журналов (журнал учёта вызовов специализированных бригад, журнал учёта повторных вызовов, журнал учёта вызовов с задержкой обслуживания вызова, журналы специального учёта (ЧС, ДТП и др.), журнал учёта использования наркотических средств, журнал вызовов к хроническим больным и т.п.);
10. Учет путевых листов, прихода и расхода ГСМ;
11. Формирование и выдача регламентированных статистических отчетов;
12. Формирование произвольных аналитических отчетов для задач планирования, управления и взаиморасчётов с ФОМС за любой временной интервал.
13. В целях повышения оперативности межведомственного взаимодействия, как в повседневном режиме, так и в режиме ЧС, должна обеспечиваться интеграция с информационными системами служб экстренного реагирования («ЕДДС-112» и т.д.).
В МИС для станции СМП должна обеспечивать получение конкретные данные о работе каждого врача, бригады, смены, подстанции и станции в целом, в любой временной промежуток.
В МИС для станции СМП должны быть предусмотрены следующие типовые автоматизированные рабочие места (АРМ):
1. АРМ администратора системы (уровень доступа, справочники системы и т.п.)
2. АРМ диспетчера приема вызовов;
3. АРМ диспетчера направления бригад;
4. АРМ диспетчера подстанции;
5. АРМ старшего врача дежурной смены;
6. АРМ врача (фельдшера) выездной бригады;
7. АРМ учёта персонала, формирования графика нарядов;
8. АРМ заведующего аптекой;
9. АРМ заправочной;
10. АРМ руководителя (главный врач, начмед, заведующий подстанцией (отделением) и др.);
11. АРМ стола справок и медицинской статистики;
12. АРМ учёта госпитализаций и анализа расхождений диагнозов
Примечание: число АРМов зависит от мощности ССМП.
Это именно то, что могут обозначить в нормативном акте (приказе) врачи-организаторы здравоохранения МЗ РФ, а вопросы технической реализации поставленных задач (техническое задание, протоколы обмена данными, общие справочники и регламенты и т.п.) - компетенция профильного Департамента МЗ РФ!
Сорокин Олег:
Совершенно с Вами согласен в части что технически и технологически всё реализуемо в одном блоке единой программы, но есть ряд моментов чисто практического свойства. Реализацию с 1 по 5 и 13 из вашего списка относятся к оперативной работе в режиме реального времени и требуют от системы мгновенного быстродействия и надёжности в работе (защита от дураков для корректоного ввода данных, отсутствие зависания и сбоев), возможность быстрого перехода между различными параметрами оперативной работы. Навешивание дополнительных функций в этом режиме работы в реальном времени ведёт к замедлению системы и иногда зависанию и сбоям (из-за перегруженности оперативной памяти сервера, а наращивание её мощности до бесконечности неоправдано, так как из-за сбоя может вылететь всё) и это не дефект программы а свойство оборудования. Именно поэтому на практике оперативный блок работы программы должен работать обособленно от остальных, при этом функция контроля сохранена в полном объёме. Все остальные задачи решаются в распеределённой системе и в рабочем режиме без нагрузки на оперативный блок, в процессе работы каждого подразделения выводятся данные связанные с базой для единого учёта результатов работы, это уже отработка технологии работы каждого подразделения и здесь тоже нет проблем. По поводу АРМ думаю что нет смысла так детально их разделять по своим возможностям, реально выделить большие блоки: АРМ администратора системы, АРМ оперативного отдела где есть возможность с любого рабочего места выполнять функции как в самом оперативном отделе так и на местах диспетчера подстанции и старшего врача подстанции на удалении. Номинально расставить таблички какое из рабочих мест как называется и рассадить сотрудников по этим местам каждого со своим функционалом, которые входят в систему под своим паролем и имеют разрешение выполнять свои функции. Смысл в том что все видят одну и ту же картинку в процессе работы, реально производить контроль, для примера называя оператору номер вызова или адрес можно обратить его внимание именно на этот вызов и проконтролировать процесс его выполнения не вмешиваясь в работу системы. Это уже АРМ руководителя любого уровня. АРМ ввода данных и статистики тоже универсален. Рабочие места реализуются для работы в связи с уже сформированной базой данных обратившихся за помощью и выполненных вызовов, этот блок нек влияет на скорость работы системы. Своей работой они дополняют имеющиеся данные для формирования отчётов в той форме которая может потребоваться.
Навигация
Перейти к полной версии