Abstract

Abstract

Conceptual approaches to creation of an automated system for calculation of primary health care volumes in Tver region of the Russian Federation are considered and proved.

Full Text

Достижение высокого уровня доступности медицинской помощи, высокой эффективности использования ресурсов тесно связано с качеством планирования объемов и структуры медицинской помощи [8]. В качестве основы планирования обычно предлагается использовать показатели здоровья населения в целом и отдельных специфических групп [9]. Общепринято, что с количественной стороны здоровье населения определяется совокупностью взаимосвязанных статистических показателей, основными из них являются медикодемографические характеристики, заболеваемость и инвалидность [11]. Многие исследователи считают, что существующая в настоящее время нормативно рекомендованная система планирования, закрепленная алгоритмами разработки территориальных Программ государственных гарантий, полностью игнорирует динамические процессы (изменение возрастно-половой структуры населения, уровня заболеваемости, распространенности 60 факторов риска), что, ввиду временного разрыва между принятием решения и получением желаемых результатов от его реализации (консервативность системы), превращает процесс определения потребности в случайный, когда совпадение потребности и плановых показателей может быть достигнуто далеко не всегда. Кроме того, совершенствование среднесрочного планирования невозможно без учета региональных особенностей и факторов, влияющих на формирование потребности в объемах медицинской помощи [6]. Несмотря на большой интерес исследователей к проблеме планирования медицинской помощи, совершенствование подходов к планированию, как резерв повышения качества и эффективности медицинского обеспечения, требует дальнейших теоретических и практических изысканий [10]. На сегодняшний день уже абсолютно спокойно и уверенно можно говорить, что компьютер «вошел в повседневную практику» жизни и работы людей, в т.ч. и в практику работы врачей [1-3]. Согласно данным Gartner, в 2011 г. экспертную систему анализа данных имели 10% клиник, а в 2016 г. прогнозируется, что те или иные экспертные системы будут работать в 50% медицинских организаций. Основываясь на вышеизложенном, представляется актуальной задачей создание экспертной компьютерной системы для планирования объемов первичной медико-санитарной помощи. Она позволит, используя актуальные сведения о заболеваемости и обращаемости, планировать необходимые объемы первичной медикосанитарной помощи для территорий различных типов. Первый вопрос, на который необходимо ответить при создании такой экспертной системы, - это определение участников информационного взаимодействия в рамках рассматриваемой информационной модели. Оптимально включить следующих участников информационного взаимодействия: • орган управления здравоохранения (на территории Тверской области - это Министерство здравоохранения Тверской области); • медицинский информационно-аналитический центр; • медицинские организации. При этом орган управления здравоохранением является 61 потребителем результатов работы рассматриваемой экспертной системы, т.е. показатели, которые будут рассчитываться данной экспертной системой, важны и нужны именно ему. Медицинский информационный аналитический центр в данной информационной модели рассматривается как поставщик сведений отчетности, которые являются исходными данными для дальнейших расчетов, т.е. образуют базу данных создаваемой экспертной системы. Оптимально, если данная экспертная система будет работать на мощностях Центра обработки данных медицинского информационноаналитического центра. Безусловно, самым удобным режимом работы будет on-line получение содержания базы данных экспертной системы из работающего регионального фрагмента единой государственной информационной системы здравоохранения (концепция создания единой государственной системы в сфере здравоохранения (ЕГИСЗ) утверждена приказом Минздравсоцразвития от 28 апреля 2011 г. № 364). Медицинские организации в данной модели рассматриваются как поставщики исходных данных. Предоставление медицинскими организациями исходных данных в данной модели происходит автоматически при их работе в региональном сегменте ЕГИСЗ. Основными компонентами, из которых состоит большая часть экспертных систем по Р Форсайту [4] являются: • база знаний; • машина логического вывода; • модуль извлечения знаний; • система объяснения. База знаний содержит факты (или утверждения) и правила. Факты - это информация о каком-либо случае, являющемся предметом экспертизы. Обычно этот тип знаний собирается посредством диалога с пользователем, который указывает, какие факты следует считать справедливыми в настоящее время. Факты составляют базу данных экспертной системы. В нашей ситуации фактами являются сведения о заболеваемости и обращаемости, получаемые из регионального сегмента ЕГИСЗ. Правила (процедуры знания) представляют собой информацию о том, как порождать новые факты или гипотезы из известных фактов. 62 Они вырабатываются заранее путем опроса эксперта, на основании данных литературы. Правила являются ядром базы знаний. Способами представления знаний являются правила продукций в формате «Если - То», семантические сети и фреймы, наборы прецедентов, вероятности и др. Для данной экспертной системы мы предлагаем использовать правила продукций в формате «Если - То» с тремя уровнями иерархии. На первом уровне иерархии, мы классифицируем рассматриваемую территорию по типу населения. Причем для территорий с преимущественно городским типом населения осуществляется также классификация на подтипы по уровню заболеваемости. В рамках системы должен быть реализован классический алгоритм разделения на диапазоны по данному признаку. На втором уровне мы классифицируем население по полу. На третьем уровне внутри выделенных на первом и втором уровне групп осуществляется классификация по следующим возрастным группам: 20-24 года; 25-29 лет; 30-34 года; 35-39 лет; 40-44 года; 45-49 лет; 50-54 года; 55-59 лет; 60-64 года; 65-69 лет; 70 и старше. Далее для сформированных таким образом групп мы определяем планируемый объем первичной медико-санитарной помощи на основании сведений, полученных из ЕГИСЗ, по алгоритмам, которые будут выработаны в ходе медикодемографического анализа. Машина логического вывода (МЛВ) - это алгоритм, обеспечивающий выработку решения относительно обрабатываемых данных. Алгоритм МЛВ зависит от представления знаний в базе данных. В рассматриваемой экспертной системе предлагается использовать «прямую цепочку рассуждений» (связана с рассуждениями, ведущимися от данных к гипотезам). Модуль извлечения знаний в данной системе не нужен, т.к. необходимые алгоритмы будут построены в ходе специального исследования. Механизм объяснений в данной системе, построенный по типу 63 ретроспективного рассуждения, будет объяснять, как достигнуто текущее состояние, с предъявлением цепочки правил, приведших к полученному заключению. По мере возрастания сложности программных систем все более актуальным вопросом становится выбор подходов к технологии их создания. Грамотный процесс разработки - необходимое условие успешной работы над созданием программного обеспечения [7]. Так как медицина - особая область знаний, и, особенно, создание экспертных систем, то должна быть и своя методология создания экспертной системы планирования объемов медицинской помощи, позволяющая оптимизировать процесс создания системы, основанная на существующих в области информационных технологий методах, а также учитывающая особенности предметной области и решаемой задачи. Первый вопрос, который необходимо было решить - это определение модели процесса разработки комплексных АИС ЛПУ. Выделяют три возможных подхода к процессу разработки (http://www.microsoft.com): • модель «Водопад»; • модель «Спираль»; • гибрид моделей «Водопад» и «Спираль» - например, «MSF process Model». Модель «Водопад» представляет собой прохождение всего процесса разработки за один этап, без итераций. Данная модель хорошо работает в проектах в том случае, если существует возможность определить все требования в начале проекта. При этом процесс разработки разделяется контрольными точками. Соответственно, такая модель не подходит в больших, длительных проектах. Модель «Спираль» основана на итеративном подходе к разработке. Ее недостатком является то, что не предусмотрены контрольные точки. Соответственно, в больших проектах она лишена предсказуемости. Модель «MSF process model» сочетает лучшие черты обеих выше охарактеризованных моделей: предсказуемость процесса с контрольными точками из модели «Водопад» с итеративностью и 64 возможностью изменения требований из модели «Спираль». Согласно подходу MSF (Microsoft Solution Framework, корпорация Microsoft) разработка должна последовательно проходить стадии, которые состоят из следующих четырех фаз, заканчивающихся контрольной точкой: • представление; • планирование; • разработка; • стабилизация. На фазе представления формулируются бизнес-требования и общие цели проекта, описываются его риски. На фазе планирования определяется, что должно быть сделано, как и когда. Она завершается созданием и утверждением плана проекта. На фазе разработки создается непосредственно программный код и вся документация. К ее концу продукт становится готов для внешнего тестирования и стабилизации. На фазе стабилизации ликвидируются дефекты кода, а также осуществляется управление изменениями ожиданий. Она завершается выпуском версии, после чего команда готова к переходу на следующую стадию, состоящую из тех же самых фаз. Одним из подходов к контролю итеративного последовательного жизненного цикла системы является Rational Unified Process (RUP) - исчерпывающий набор правил, охватывающих технологические и организационные аспекты процесса разработки программного обеспечения и особым образом регламентирующих приемы анализа требований и дизайна. Согласно RUP, разработка системы представляет собой серию итераций, приводящих к получению окончательной версии продукта. Каждая итерация охватывает один или более компонентов процесса, предусматривающих конструирование бизнес-моделей, определение требований, анализ, проектирование, реализацию, тестирование и промышленное внедрение. При этом отнюдь не все требования могут быть известны в начале жизненного цикла - вполне реальна ситуация, когда те или иные изменения вносятся на любой из фаз. Подобный вариант развития системы позволяет снизить 65 уровень рисков. Технические риски оцениваются и классифицируются на ранних стадиях цикла, хотя позже прогнозы могут уточняться. С каждой итерацией связываются собственные оценки рисков, так что ее успешное завершение нивелирует и соответствующие риски. Итерации процесса разработки упорядочиваются во времени таким образом, чтобы наиболее рискованные решения принимались в самом начале [5]. Процесс, описываемый с помощью RUP, структурируется по двум измерениям: • время - расчленение жизненного цикла системы на фазы и итерации; • компоненты - выявление множеств сущностей с ясно определенными параметрами деятельности. Для достижения успеха проекта следует учитывать значения по обоим измерениям. Структура проекта, связанная с осью времени, включает следующие фазы: • начало - определение целей проекта и их обоснование; • планирование - обдумывание необходимых действий и уточнение потребности в ресурсах; спецификация условий и проектирование архитектуры; • создание - конструирование продукта в виде серии последовательных итераций; • внедрение - доставка продукта потребителю (установка, настройка и обучение пользователей). Упорядочение структуры проекта по множеству компонентов процесса предполагает осуществление следующих действий: • бизнес-моделирование - определение свойств системы с учетом пожеланий потребителя; • уточнение требований - сужение множества функций и качеств системы до необходимого и достаточного уровня; • анализ и дизайн - описание вариантов и способов реализации; • реализация - создание программного кода; • тестирование - проверка корректности функционирования; • передача в эксплуатацию и обучение пользователей. Так как в случае создания экспертной системы планирования объемов первичной медико-санитарной помощи существует 66 возможность определить все требования в начале проекта, то предлагается использовать модель «Водопад», которая представляет собой прохождение всего процесса разработки за один этап, без итераций. Использование итеративной модели в данном случае не имеет смысла. При использовании данной модели процесс разработки разделяется контрольными точками. Предлагается следующий состав контрольных точек: • функциональная декомпозиция; • создание исследовательского прототипа; • опытная эксплуатация исследовательского прототипа; • создание промышленного прототипа; • интеграция с ЕГИСЗ; • внедрение. При этом функциональная декомпозиция должна быть проведена до запуска модели «Водопад», что и было реализовано нами. В предлагаемой системе выделяем следующие группы функций: • интеграция с ЕГИСЗ; • построение решающих правил; • интерфейс организатора здравоохранения. В рамках группы «Интеграция с ЕГИСЗ» выделяются следующие функции: • получение сведений о поло-возрастной структуре населения территории; • получение сведений о заболеваемости; • получение сведений о посещаемости. В рамках группы «Построение решающих правил» выделяются следующие функции: • построение решающих правил для территорий с преобладанием городского населения; о построение решающих правил для территорий с преобладанием городского населения с высоким уровнем заболеваемости; о построение решающих правил для территорий с преобладанием городского населения с низким уровнем 67 заболеваемости; • построение решающих правил для территорий с преобладанием сельского населения. В рамках группы «Интерфейс организатора здравоохранения» мы выделяем следующие функции: • управление интеграцией с ЕГИСЗ; • типированиетерриторий; • управление выводом сведений; • управление машиной логического вывода; • управление механизмом объяснений. Таким образом, на сегодняшний день нами определена структура планируемой экспертной системы, модель ее создания, а также осуществлена ее функциональная декомпозиция. Литература