РУТИННЫЙ МОНИТОРИНГ В ПРОГРАММАХ ЗПТ Проблемы и оптимизация
План презентации Показатели рутинного мониторинга Предпосылки к созданию централизованной базы данных Проект централизованной базы данных Демонстрация работы прототипа Обсуждение
Какие данные собираются на регулярной основе (1) Первинне джерело Дані, що збираються Показники, що формуються Копія Журнал кейс- Дата допрограмного менеджера консультування Кількість проскрінованих Щомісячний звіт персоналу Амбулаторна карта Дата засідання МДК Кількість обстежених Щомісячний звіт персоналу, протокол засідання МДК Дата першого Кількість поступлень призначення препарату Кумулятивна кількість поступлень Звіт Альянс Дата виписки Кількість виписок Звіт УІПОЗ, звіт Альянс Причина виписки Розбивка виписок за причинами Звіт УІПОЗ, звіт Альянс Кумулятивна кількість виписок Звіт Альянс Кількість клієнтів у програмі Звіт УІПОЗ, звіт Альянс
Какие данные собираются на регулярной основе (2) Первинне джерело Дані, що збираються Показники, що формуються Копія Амбулаторна карта Демографічні та ін. характеристики Розбивка клієнтів за характеристиками Звіт УІПОЗ ВІЛ-статус, гепатити Відсоток ВІЛ, ВГС, ВГВ інфікованих Звіт УІПОЗ Дати медичних обстежень Кількість обстежень на 1 клієнта Дата, результат уриноконтролю Кількість позитивних тестів Журнал тестувань Журнал консультантів Дати консультацій Кількість консультацій Щомісячний звіт персоналу Дата призначення АРТ Кількість клієнтів, що почали Амб. карта, Звіт УІПОЗ АРТ під час проекту Дата припинення АРТ Кількість клієнтів, що препинили АРТ під час проекту Амб. карта, Звіт УІПОЗ
Какие данные собираются на регулярной основе (3) Первинне джерело Дані, що збираються Показники, що формуються Копія Форма 8, 9 Призначена доза по клієнтах Амб. карта, Форма 9, «Щоденник» Максимальна, мінімальна та середня доза Звіт УІПОЗ Журнал відділення Дати отримання Кількість отриманого препарату, кількість препарату Журнал видачі препарату Дати видачі Кількість пропущених днів по клієнтах Отримана доза Кількість спожитого препарату Звіт КМНКЛ, Звіт ВОНД Залишок препарату Звіт КМНКЛ, Звіт ВОНД «Щоденник» Звіт КМНКЛ, Звіт ВОНД
Итого: Большое количество информации, которая многократно дублируется, и труднодоступна для систематизации и обработки
Кроме этого: На национальном уровне Нет оперативного доступа к информации о пациентах (количество, основные характеристики); Есть возможность получения препарата на нескольких сайтах одновременно (станет более актуально с появлением новых сайтов); На локальном уровне Есть затруднения в подсчете препарата и его остатков; Ведение документации (и ее дублирование!) ОЧЕНЬ трудоемко.
Пути решения: 1. Изменение существующей нормативноправовой базы (приказ № 356) Поможет 2. уменьшить количество макулатуры Использование информационных технологий Поможет в любом случае
Задачи и планируемая функциональность (1) 1. Сбор информации о пациентах (потенциальных, текущих, выбывших): Оперативный доступ к информации о количестве пациентов, их основным характеристикам; Оперативный доступ к информации каждого отдельного пациента - личная информация, информация об участии в программах; Исключение возможности получения препарата в двух местах одновременно; Создание возможности «передачи» пациентов с сайта на сайт (например в случае командировок, поездок и т. п. ); Формирование списка ожидания
Задачи и планируемая функциональность (2) 2. Сбор информации по расходуемым препаратам: Прогнозирование расходов по отдельным сайтам; 3. Оперативный доступ к информации о количестве расходуемого препарата, средних/минимальных/максимальных дозировках; Прогнозирование расходов в целом по стране; Облегчение и стандартизация ведения документации: Создание электронных форм (рутинная документация); Автоматическое формирование отчетов
Задачи и планируемая функциональность (3) 4. Мониторинг и оценка эффективности терапии: 5. Подключение отдельных модулей – анкеты Addiction Severity Index, BBV -TRAQ с возможностью анализа данных; Сбор информации по инфицированности ВИЧ, ТБ, Гепатитами в реальном времени (мониторинг заболеваемости); Сбор информации о персонале программ ЗПТ, их квалификации, необходимости дополнительного обучения, участия в тренингах и т. п. Окончательный дизайн системы и необходимая функциональность будет определяться по ходу реализации проекта, в частности, по результатам проведения рабочих групп и консультаций с экспертами и персоналом проектов на местах. Система должна будет согласована и одобрена МОЗ!
Варианты имплементации (1) Технически самый простой вариант – полностью он-лайн база данных (просмотр и редактирование информации происходит только при подключении к Интернет);
Варианты имплементации (2) Но, поскольку в регионах нет постоянного и стабильного доступа к Интернет, то компромиссным вариантом может быть система с периодически обновляемыми данными и возможностью работы без доступа к Интернет, а именно: В режиме офф-лайн обеспечивается ввод данных, их редактирование, запросы к базе, формирование отчётов; При подключении к Интернет происходит обновление базы данных (обновление с сайта «уходит» на сервер, в каждый сайт получает с сервера обновления по пациентам остальных сайтов); Также планируется возможность создания файлов экспорта / импорта данных для передачи обновлений на флешке, диске и т. д.
Схема ЦЕНТРАЛЬНЫЙ СЕРВЕР Сайт 1 (областной хаб) Врач N Сайт 3 Сайт 2 (областной хаб) Врач M РАЙОНЫ Сайт 4 Врач E Врач P ПАЦИЕНТЫ Врач Z Врач К Сайт 5 Врач G
Ввод данных (1): При самостоятельном обращении или направлении пациента на него заводится карточка (профайл) Содержит основную информацию о пациенте (ФИО, номер паспорта, дата рождения, дата обращения на лечение, дата начала лечения, дата прерывания терапии с указанием причины); Изменения в профайл клиента вносятся только в случае изменения одного из основных параметров (не на ежедневной основе); Те сайты, которые не имеют компьютера с установленной базой, будут создавать профайлы на своих пациентов в областном центре, передавая информацию по телефону или другим способом
Ввод данных (2): При поступлении на лечение: В текущем режиме: Заполняются дополнительные поля (заместительный препарат, дозировка, данные первичного осмотра и т. д. ); Вводятся данные об изменениях дозировок, прохождении обследований, консультаций, участия в социальнопсихологической работе. Предполагается, что в базе данных будет заложена возможность создания необходимых форм (форма первичного осмотра, форма 8, форма 9, протокол МДК, журнал соц. работы, и т. д. ), которые будут автоматически брать имеющуюся информацию из БД, и дозаполняться с помощью простых элементов, и в потом распечатываться.
Доступ к данным (1): На сервере (при условии регулярного обновления всеми сайтами) хранятся полные данные по всем клиентам всех сайтов; На компьютерах сайтов хранятся полные данные по «своим» клиентам, а также по клиентам «дочерних» сайтов (в случае областного центра – все клиенты сайтов «нижних» уровней: районы, города области…); Каждый из авторизованных сайтов (операторов системы) имеет неограниченный доступ к информации (и её редактированию) только по «своим» пациентам; В процессе обмена обновлениями каждый сайт будет загружать с сервера профайлы (только базовую информацию) по всем клиентам в Украине;
Доступ к данным (2): При обращении на лечение, любой авторизованный сайт, сможет сделать запрос к системе по ФИО / номеру паспорта о том, состоит /состоял ли уже данный человек на лечении у другого врача / в другом сайте. Сайты не имеющие компьютера смогут сделать запрос по телефону, связавшись с областным центром. Ответы на запрос могут быть: Данных о таком пациенте в системе нет; Пациент находится на подготовительном этапе (состоит в «листе ожидания» ) – т. е. зарегистрирован в системе как обратившийся на лечение, но пока не принимает терапию; Пациент состоял на лечении ранее и выбыл (с указанием места предыдущего лечения, даты и причины выбывания); Пациент на данный момент состоит на лечении (с указанием даты начала такого лечения, сайта и лечащего врача).
Дополнительные возможности: Процедура «перехода» пациента от одного врача к другому (в том числе и пациентов из списка ожидания); Сохраняется вся «история пациента» (даты начала и прекращения участия в программах ЗПТ, лечащие врачи, сайты, сопутствующие заболевания и т. д. )
Возможные сложности (1) Наличие компьютеров и доступа в Интернет Минимум – телефон на дочерних сайтах Регулярность синхронизации
Возможные сложности (2) Техническая подготовка персонала сайтов, ответственного за ведение БД; Правильность ввода данных Оптимальная функциональность – с одной стороны не перегружать БД лишней информацией, с другой стороны обеспечить наличие всех функций, отвечающих потребностям как на уровне сайтов, так и на центральном уровне; Защита информации.
ВОПРОСЫ? ПРЕДЛОЖЕНИЯ?
Скачать презентацию РУТИННЫЙ МОНИТОРИНГ В ПРОГРАММАХ ЗПТ Проблемы и оптимизация
f6282ef6737cc086a45322e6f39cc940.ppt