Автоматизированное рабочее место врача диплом

Автоматизированное рабочее место врача-реаниматолога по направлению токсикология

Содержание

Введение

Глава 1. Обзор существующих решений

.1      История развития медицинских информационных систем

.2      МИС «МЕДИАЛОГ»

.3      МИС «Эверест»

.4      МИС «Интерин PROMIS 7»

.5      МИС «Дока +»

.6 С.О.П.О.Р.

Глава 2. Разработка проекта

.1      Выбор сред разработки программного обеспечения

.2      Необходимые данные и структурная схема программного
обеспечения

.3      Разработка системы поддержки принятия решения

Глава 3. Разработка программного обеспечения

.1 Общее описание разработанного ПО

.2 Создание базы данных для ПО

.3 Реализация ПО в Microsoft Visual C# 2013

.3.2 Главная форма (InitialForm)

.3.3 Форма первичного осмотра (FirstView)

.3.4 Форма инструментальных исследований (InstrumentalSurvey)

.3.5 Форма лабораторных исследований (LaboratorySurvey)

.3.6 Форма ввода параметров состояния пациента (StatePatient)

.3.7 Форма назначения лекарств, процедур и рекомендаций
(Therapy)

.4 Дальнейшее развитие

Заключение

Список использованных источников

Введение

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

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

Главными причинами отравления на первом месте стоят суициды, это примерно
60-70% всех отравлений[1]. В аптеках продается довольно большой перечень
препаратов, чрезмерная дозировка которых приводит к тяжелым последствиям.
Зачастую такие препараты отпускаются только по рецепту врача, но ни для кого не
секрет, что данную преграду можно обойти. Причины суицида включают в себя
комплекс психических расстройств и возможную склонность к алкоголизму. Людям, с
психическими расстройствами, как правило, прописывают препараты, влияющие на
центральную нервную систему, например, антидепрессанты, которые содержат в себе
довольно вредные действующие вещества.

На втором месте причин отравлений стоят случайные отравления, примерно
16-20%.[2]. Случайные отравления возникают чаще всего в состоянии алкогольного
опьянения и встречаются в большинстве случаев у мужчин. Алкогольные отравления
— главная беда нашей страны. Они включают в себя не только чрезмерное
потребление алкогольной продукции, но и отравление некачественным алкоголем, а
так же его суррогатами. К примеру, отравление метиловым спиртом, которое в
большинстве случаев приводит к летальному исходу. По данным ведущего
российского эксперта в области проблем алкогольной смертности и алкогольной
политики, руководителя отдела информатики и системных исследований Московского
НИИ психиатрии Александра Немцова в абсолютном выражении смерти, связанные с
алкоголем, в среднем, составляли 351,7 тысячи мужчин и 135,1 тысячи женщин в
год. Т.е. из-за алкоголя в России умирает порядка полмиллиона человек в год[2].

Еще одной немаловажной причиной отравлений являются наркотические
средства. За 2013г. общее число отравлений наркотиками, на которые выезжали
бригады скорой помощи, в Омской, Новосибирской и Иркутской областях выросло на
50% [3]. Мощным фактором развития наркобизнеса является политическая и
экономическая нестабильность. Это связано с использованием значительных
финансовых ресурсов от производства и продажи наркотиков для достижения
политических целей. Основными местами распространения наркотиков становятся
ночные клубы, где чаще всего молодежь и пробует их в первый раз. И если
«натуральные» наркотики, такие как анаша, гашиш или марихуана, вызывают
небольшой перечень основных симптомов отравления, а губительным последствием их
приема в основном выделяют привыкание, то отравление «синтетическими»
наркотиками зачастую приводит к смертельному исходу. Примером «синтетических»
наркотиков может служить часто встречающаяся надпись на домах и заборах «Арома
соли», которые имеют нелегальное распространение на территории России.

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

В общем, ведущей причиной отравления являются прием лекарственных
препаратов (45-60%) [1]. Небольшой процент такого вида отравления занимают
ошибки медперсонала при назначении лекарственных средств, а так же имеется определенный
процент криминальных отравлений.

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

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

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

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

Глава 1. Обзор существующих решений

1.1    История
развития медицинских информационных систем

История развития Медицинских Информационных Систем (МИС) началась еще в
50-х годах XX века в Соединенных Штатах Америки, когда на рынке появились универсальные
компьютеры многоцелевого назначения. Первым проектом такой информационной
системы был MEDINET, разработанный фирмой “General Electric”.

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

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

Один из таких новаторских подходов стало применение компьютерных
технологий в клинической практике. В 70-х годах XX века развитие МИС
разделилось на два основных направления. Один из них — наличие одного мощного
компьютера (сервера) и терминалов на рабочих станциях, которые включали в себя
только монитор и клавиатуру. Другая часть разработок базировалась на создании
распределенных систем, которые поддерживали раздельную реализацию
специализированных приложений с помощью самостоятельных компьютеров. В обоих
направлениях действовал принцип единой базы данных, в которой хранится вся
информация о пациентах.

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

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

Свое дальнейшее развитие БИС получила в 1965 году в больнице Эль-Камино
калифорнийского города Маунтин-Вью. При поддержке ракетно-космической компании
Локхид была разработана медицинская информационная система Technicon. Первые
испытания этой системы были проведены в 1971 году в одном из отделений
стационара. На тот момент система обладала возможностью выполнять целый ряд
сложных функций, связанных с лечебной, вспомогательной и административной
деятельностью. Назначения врачей передавались вспомогательным службам, врачи
получали результаты анализов и данные рентгенологических исследований,
планировались мероприятия по уходу за больными и велась документация. Согласно
официальному заключения система Technicon эффективно поддерживала обработку
всей необходимой информации для медицинских сестер, врачей и персонала вспомогательных
служб, в том числе службы лечебного питания, медицинской документации, аптеки,
лаборатории, рентгенологии, респираторной терапии и канцелярии.

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

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

Системы компьютерной поддержки принятия решений (СППР) применяется для
принятия решений по оказанию медицинской помощи пациентам.

В 1999 году были выделены следующие четыре вида поддержки принятия
решений:

.        Предупреждение специалистов о возникновении угрожающей ситуации;

.        Критический анализ ранее принятых решений;

.        Предложения по лечебным мерам в ответ на запросы медиков;

.        Ретроспективные обзоры с целью обеспечения контроля за качеством
лечения.

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

И хотя ранние системы СППР предназначались для поддержки лечения больных,
велись работы и по созданию систем, ориентированных на поддержку ухода за
больными. Первой такой программой стала система Creighton Online Multiple
Modular Expert System, или сокращенно COMMES, разработанная в 70-е годы для
помощи медицинским сестрам при составлении планов проведения мероприятий по
уходу за больными.

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

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

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

В отечественной литературе первые сообщения о возможности использования
ЭВМ в здравоохранении появились в конце 50-х — начале 60-х годов XX века. В это
время широко известны были работы Н.М. Амосова, Р.М. Баевского, А.А.
Вишневского и других. В них обсуждались возможности применения достижений
кибернетики и математических методов в клинических, научно-исследовательских и
управленческих задачах.

В это же время при крупных научных медицинских центрах были созданы
первые лаборатории кибернетики и медицинской статистики. В 1967 году были
предприняты первые реализованные на практике шаги в направлении использования
вычислительных систем в здравоохранении России (СССР). Была создана
межведомственная комиссия «Медицинская кибернетика», которую возглавил Н.М.
Амосов. Создавались научно-исследовательские институты для разработки
медицинских компьютерных систем, среди которых была и медико-математическая
лаборатория Российского НИИ нейрохирургии им. А.Л. Поленова, создавшая
компьютерную консультативную систему для больных с различными формами
черепно-мозговой травмы. А в лаборатории кибернетики Института хирургии им.
А.В. Вишневского АМН СССР была создана система вычислительной диагностики
врожденных пороков сердца и магистральных сосудов.

Однако, эти системы не могли быть внедрены в широкую практику, поскольку
ЭВМ конца 60-х — начала 70-х годов представляли собой большие комплексы,
которые находились в больших помещениях, а так же большого штата обслуживающего
персонала.

В 1961 году в лаборатории медицинской кибернетики института хирургии им.
А.В. Вишневского была установлена первая в медицинских учреждениях СССР ЭВМ
первого поколения «Урал-2». Всего таких ЭВМ в стране было выпущено 139.

В этот же период людьми, способными предвидеть дальнейшее развитие
медицинских технологий, создавались и совершенствовались профильные лаборатории
в медицинских НИИ и кафедрах ВУЗов.

Решение медицинских задач с помощью ЭВМ осуществлялось и развивалось в
трех направлениях:

.        Обработка многочисленной медицинской статистической отчетности;

.        Создание формализованной истории болезни;

.        Создание диагностических систем, помогающих врачу решать сложные
диагностические задачи.

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

Больницы и их отделения получили возможность приобрести собственные
компьютеры, для самостоятельной разработки требуемых прикладных систем. В
начале 80-х годов XX века этой возможностью пользовались многие крупные
лечебные учреждения. Итогом стали разработки плохо тиражируемых и трудно
развиваемых систем.

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

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

В настоящее время существуют различные фирмы, производящие МИС,
включающие в себя не только АРМ врачей по профилю, но и системы
административного и бухгалтерского учета. Среди них наибольшее распространение
получили МЕДИАЛОГ, Эверест, Интерин, Барс, Гиппократ, Авицена, Амулет, Дока +,
внедренная в больницах Новосибирской области.

Ниже приведено описание некоторых из этих систем. Сводную таблицу по МИС
и реализованным в них системам можно посмотреть в приложении А.

1.2    МИС
«МЕДИАЛОГ»

«МЕДИАЛОГ» — система, предназначенная для комплексной автоматизации
работы медицинского учреждения. Она разработана компанией ООО «Пост Модерн
Технолоджи». За 1997-2000 год системой МЕДИАЛОГ оборудовано более 150
медицинских учреждений Франции. Так как данная программа имеет только
лицензионное распространение и не обладает общедоступностью, в обзоре данной
МИС можно руководствоваться только общими сведениями, предоставленными
производителем в презентации.

Система «МЕДИАЛОГ» развернута на базе СУБД Microsoft SQL Server.
Информационная система охватывает все аспекты медицинской деятельности ЛПУ, а
так же имеет систему класса ERP,
которая позволяет решать задачи управления и учета хозяйственно-экономической
деятельности ЛПУ.

Рисунок
1.2.1 МЕДИАЛОГ: схема функциональности

ЭМК — электронная медицинская карта пациента может быть экспортирована в
открытом формате (HTML), который
может быть прочтен на любом компьютере. Экспорт производится на нескольких
языках, например, на русском и на английском. ЭМК в HTML формате может быть записана на любой внешний носитель
и защищена от несанкционированного доступа.

Рисунок
1.2.2 ЭМК: центральный модуль системы

Лист назначений «МЕДИАЛОГ» обеспечивает врачу выбор лечения, используя
профессиональные справочники, а также предоставляет медсестрам удобный сервис
для выполнения назначений, интегрированный с аптекой. Имеется документирование
всех действий медперсонала по лечению больного и позволяет контролировать
динамику состояния больного на фоне проводимого лечения.

Рисунок
1.2.3 Лист назначений: функциональность

План лечения пациента имеет возможности:

поэтапной активации направлений на услуги;

планирования сроков выполнения мероприятий

возможность создания медицинских программ с прикрепленным планом лечения;

возможность выставления счетов на основе планов лечения;

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

Имеется справочник типовых планов лечения.

Рисунок 1.2.4 План лечения пациента

Также в системах «МЕДИАЛОГ» имеется радиологическая подсистема, которая
позволяет подключать DICOM
оборудование, сохранять файлы в форматах BMP, JPG, PNG, DICOM и прикреплять графические изображения к истории
болезни.

Рисунок
1.2.4 Радиологическая подсистема

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

1.3    МИС
«Эверест»

ЭВЕРЕСТ — это комплекс прикладных программ, предназначенных для
автоматизации лечебно-диагностического процесса и административно-хозяйственной
деятельности лечебно-профилактических учреждений.

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

Основные подсистемы и их назначение:

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

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

. Подсистема «Медицинская статистика». Применяется для обработки и
подготовки медико-статистической информации по результатам стационарного,
амбулаторного и параклинического обслуживания в соответствии с федеральными и
территориальными нормативами. Здесь формируется отчетная информация о
результатах деятельности лечебного учреждения, сигнальные донесения главному
врачу и его заместителям, произвольные сводки и отчеты. Используется в
кабинетах медицинской статистики и в аппарате управления ЛПУ.

. Подсистема «Учет лекарственных средств». Применяется для учета лекарственных
средств в подразделениях и учреждении в целом. Модуль обеспечивает выполнение
всего комплекса учётных, отчетных и производственных задач в аптеке ЛПУ и в
отделениях, включая учёт назначенных и применённых медикаментов — персонально
для каждого больного. Обеспечивается автоматизированное планирование
потребности и управление запасами медикаментов в отделениях. Предусмотрен учет
лекарственных средств на уровне отделений, медицинских постов и отдельных
кабинетов. Используется в аптеке и лечебно-диагностических подразделениях.

. Подсистема «Лабораторные исследования». Применяется для организации,
учета результатов и контроля качества лабораторных исследований, управления
лабораторным оборудованием. B модуле оформляются направления пациентов и
направления на санитарные исследования, процедурные, заборные и обходные листы,
программы исследований, регистрируются результаты лабораторных анализов по всем
заданным видам исследований, обеспечивается взаимодействие с лабораторным
оборудованием для автоматического ввода результатов исследований в систему.
Используется в лабораторных и лечебно-диагностических подразделениях.

. Подсистема «Управление питанием». Применяется для управлением
пищеблоком и лечебным питанием пациентов и персонала учреждения. Модуль обеспечивает
автоматизацию большинства процессов по организации диетического питания:
формирование меню на основе расчетов характеристик рациона по энергохимическому
составу, оформление заявок отделений на «диетические столы», выполнение
расчетов по расходу продуктов (с учетом вновь поступивших, выбывших или
временно отсутствующих больных). В модуле формируется необходимая бухгалтерская
и отчетная документация, регистрируются счета и контролируется расход
продуктов. Используется в пищеблоке, бухгалтерии и лечебно-диагностических
подразделениях.

. Подсистема «Управление применением медикаментов». Применяется для
контроля использования медикаментов с регламентированным доступом, контроля
полипрагмазии. Модуль поддерживает ведение формуляра применяемых медицинских препаратов
и определение правил их применения, в том числе: определение категорий
профильных и дорогостоящих медикаментов; определение случаев и правил
согласования врачебных назначений. Модуль обеспечивает возможность планирования
и контроля финансовых расходов на медикаменты по отделениям. Используется в
лечебно-диагностических подразделениях, экономической службе и в аппарате
управления ЛПУ.

. Подсистема «Учет трансфузионных сред». Применяется для учета
трансфузионных сред в подразделениях и учреждении в целом. Модуль решает
комплекс задач по регистрации прихода, расхода и списания трансфузионных сред,
забора аутокрови; перемещению трансфузионных сред в кабинетах переливания
крови; инвентаризации и учета остатков. Используется в подразделениях переливания
крови и лечебно-диагностических подразделениях.

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

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

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

. Подсистема «Анализ деятельности учреждения». Применяется для
функционального анализа деятельности учреждения. Модуль обеспечивает
формирование отчетов и анализ данных о результатах стационарного, амбулаторного
и параклинического обслуживания, финансовой и административно-хозяйственной
деятельности учреждения за любой период времени. Используется аппаратом
управления ЛПУ.

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

1.4    МИС
«Интерин PROMIS
7»

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

Система Интерин PROMIS ориентирована на совместную работу с несколькими
учреждениями — возможно, разного типа — и может стать основой при формировании
единого информационного пространства комплекса ЛПУ.

Основные подсистемы и их назначение:

.        Подсистема учета контингента. Включает в себя:

.1.     «Ведение контингента». Учет бюджетного контингента. Учет
договорного контингента по ОМС и ДМС. АРМ оператора по ведению контингента.

.2.     «Работа с реестрами и списками контингента». Загрузка списков от
страховых компаний и фондов ОМС. Контроль принадлежности пациентов к спискам
обслуживания.

.        Клиническая подсистема. Включает в себя:

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

.2.     «Лечебное отделение». Движение пациентов по стационару, переводы
и выписка. Планирование выписки из отделения. Назначение лечащего врача.
Расселение пациентов. Ввод данных температурного листа. Оформление медицинских
документов. Врачебная комиссия. Оформление юридических документов. Назначение и
консультации, диагностики и лечения. Врачебные манипуляции. Инструментальная
диагностика в отделении. Статистическая карта выбывшего из стационара.
Оперативные пособия. Средства контроля лечебно-диагностического процесса. Лист
назначений отделения. Подготовка выдачи и отметка об исполнении медикаментозных
назначений. Лист назначений отделения. Диспетчеризация консультаций и
назначений инструментальной диагностики. Лист назначений отделения. Исполнение
процедур и сестринских манипуляций. Лист назначений отделения, забор материала
для лабораторных исследований. Учет услуг. Материальный учет, аптечка
отделения, аптечка поста, списание товарно-материальных ценностей по акту,
списание на пациента, нормативное списание на пациента по услугам. Питание
пациентов, заказ питания. АРМ врача отделения терапевтического профиля. АРМ
врача хирургического профиля. АРМ заведующего отделением. АРМ постовой
медицинской сестры. АРМ процедурной медицинской сестры. АРМ старшей медицинской
сестры.

.3.     «Управление коечным фондом». Ведение справочника коечного фонда.
Визуальный контроль и планирование занятости коечного фонда. Формирование
документов по движению коечного фонда. Администрирование коечного фонда. АРМ
заведующего отделением стационара (в части управления коечным фондом). АРМ
старшей медицинской сестры стационара (в части управления коечным фондом). АРМ
администратора (в части управления коечным фондом).

.        Поликлиническая подсистема. Включает в себя:

.1.     «Регистратура». Графики и расписания. Оперативное
администрирование талонов. Предварительная запись на прием. Создание
амбулаторной карты пациента. Публикация расписаний на информационных панелях.
Информационные киоски с просмотром расписаний и записью на прием. Запись на
прием через Интернет на сайте ЛПУ. Интеграция с Электронной регистратурой ЕГИСЗ
Росминздрава. Регистрация вызова врача на дом. Анализ загруженности ресурсов.
АРМ старшего регистратора. АРМ регистратора.

.2.     «Лечебное отделение. Смены. Сигнальная информация. Случаи
обращений. Специализированные врачебные осмотры. Лист заключительных диагнозов.
Лечебно-диагностические назначения. Учет временной нетрудоспособности.
Диспансерное динамическое наблюдение. Профилактические осмотры.
Вакцинопрофилактика. Направления на госпитализацию. Санаторно-курортное
лечение. Врачебная комиссия. Эпикризы. Экстренные извещения. Предварительная
запись на прием. Инструментальная диагностика в отделении. Справки. Учет
льготных рецептов. Учет услуг на приеме. Материальный учет, аптечка отделения,
аптечка кабинета, списание товарно-материальных ценностей по акту, списание на
пациента, нормативное списание на пациента по услугам. АРМ врача-специалиста
терапевтического профиля. АРМ врача-специалиста хирургического профиля. АРМ
участкового терапевта (врача общей практики). АРМ заведующего отделением. АРМ
медицинской сестры. АРМ старшей медицинской сестры.

.3.     «Стоматологическое отделение». Специализированные осмотры.
Стоматологическая отчетность. Учет услуг. Материальный учет, аптечка отделения,
аптечка кабинета, списание товарно-материальных ценностей по акту, списание на
пациента, нормативное списание на пациента по услугам. АРМ стоматолога. АРМ
заведующего стоматологическим отделением. АРМ медицинской сестры стоматологического
отделения. АРМ старшей медицинской сестры стоматологического отделения.

.4.     «Кабинеты сестринских манипуляций». Рабочий лист забора
биоматериала, учета прививок, учета процедур. АРМ процедурного кабинета.

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

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

.2.     «Лабораторная диагностика». Забор и маркировка материала.
Регистрация материала. Операторный ввод данных лабораторных исследований.
Подключение лабораторного оборудования и обработка результатов исследований.
Контроль качества результатов исследований. Учет услуг. Подсистема интеграции с
внешней ЛИС. Материальный учет, аптечка отделения, аптечка кабинета, списание
товарно-материальных ценностей по акту, списание на пациента, нормативное списание
на пациента по услугам. АРМ процедурной медсестры. АРМ регистратора материала.
АРМ операторного ввода данных лабораторных исследований. АРМ врача отделения
лабораторной диагностики. АРМ заведующего отделением. АРМ старшей медсестры
(старшего лаборанта). АРМ статистика. АРМ ведения справочников. АРМ контроля
качества.

.3.     «Консультативное отделение». Диспетчеризация консультаций
специалистов. Оформление протокола консультации. Учет услуг. Материальный учет,
аптечка отделения, аптечка кабинета, списание товарно-материальных ценностей по
акту, списание на пациента, нормативное списание на пациента по услугам. АРМ
диспетчера консультаций. АРМ заведующего отделением. АРМ врача-консультанта.
АРМ медицинской сестры.

.4.     «Отделение восстановительного лечения». Исполнение консультаций
врачом отделения ВЛ. Назначение курса реабилитационных процедур. Исполнение
процедур. Учет услуг. Материальный учет, аптечка отделения, аптечка кабинета,
списание товарно-материальных ценностей по акту, списание на пациента, нормативное
списание на пациента по услугам. АРМ врача отделения ВЛ. АРМ заведующего
отделением. АРМ старшей медицинской сестры.

.        Подсистема дневного стационара. Включает в себя:

.1.     «Дневной стационар». Оказание медицинской помощи в дневном
стационаре. АРМ врача дневного стационара.

.        Финансово-экономическая подсистема. Включает в себя:

.1.     «Экономика лечения». Справочник услуг и прейскурантов. Ведение
контрагентов и договоров. Формирование счетов и учет платежей. Взаимодействие с
СК ОМС. Операторный ввод услуг с бумажных носителей. Медицинские услуги за
наличный расчет. Касса. Аналитическая отчетность по выполненным услугам. Расчет
себестоимости. Контроль исполнения контрактов внешними исполнителями. АРМ
планового отдела. АРМ договорного отдела. АРМ платного кабинета. АРМ кассира.

.2.     «Учет медицинского оборудования». Учет и контроль использования
медицинского оборудования.

.        Аналитическая подсистема. Включает в себя:

.1.     «Отделение медицинской статистики стационара». Операторный ввод
данных по движению пациентов, выписке пациента. Блок стандартной
государственной отчетности медицинской статистики стационара. Анализ
деятельности ЛПУ. Архив бумажных историй болезни. АРМ оператора ввода данных
медицинской статистики. АРМ врача медицинской статистики. АРМ заведующего
отделением. АРМ архивариуса бумажных историй болезни.

.3.     «Руководитель ЛПУ». Блок отчетов управленческого учета.
Информационно-аналитическая панель «Ключевые показатели деятельности». АРМ
главного врача. АРМ зам. главврача по медицинской части. АРМ зам. главврача по
клинико-экспертной работе. АРМ зам. главврача по хирургической работе. АРМ
главной медсестры.

.4.     «Конструирование отчетов и произвольных запросов». Произвольные
запросы. Конструктор отчетов.

.        Подсистема материального учета. Включает в себя:

.1.     «Центр материального учета». Учет движения товарно-материальных
ценностей в центре материального учета. Инвентаризация в центре материального
учета. АРМ материально-ответственного лица Центра материального учета.

.2.     «Персонифицированный материальный учет». Персонифицированный учет
расхода товарно-материальных ценностей. Ведение нормативов расхода
товарно-материальных ценностей. Обусловленный персонифицированный учет расхода
товарно-материальных ценностей. Контроль и верификация данных обусловленного
персонифицированного учета расхода по прецедентам. АРМ
материально-ответственного лица подразделения.

.3.     «Отпуск по рецептам». Отпуск товарно-материальных ценностей по
бумажным рецептам. Отпуск товарно-материальных ценностей по электронным
рецептам. Квотирование препаратов. АРМ фармацевта-провизора рецептурного
отдела. АРМ заведующего/зам. заведующего аптекой ЛПУ.

.4.     «Закупки». Заявки на закупку. Расчет и определение нормативов
запасов в центрах материального учета. Контракты на закупку. Формуляр
лекарственных средств. Оприходование товарно-материальных ценностей. АРМ
заведующего/зам. заведующего аптекой ЛПУ. АРМ материально-ответственного лица
подразделения.

.5.     «Отдел готовых лекарственных форм». Требования на готовые
лекарственные формы. Отпуск готовых лекарственных форм по требованиям. АРМ
фармацевта-провизора отдела ГЛФ. АРМ материально-ответственного лица
подразделения.

.6.     «Рецептурно-производственный отдел». Рецептурный справочник.
Формирование требований на рецептуру. Отпуск рецептурных форм по требованиям.
Производство внутриаптечной заготовки. Этикетки рецептурных форма. АРМ
фармацевта-провизора РПО. АРМ материально-ответственного лица подразделения.

.7.     «Аптечный пункт (розница)». Оприходование товарно-материальных
ценностей для реализации в розницу. Отпуск товарно-материальных ценностей в
розницу. Управление фискальными контрольно-кассовыми аппаратами. АРМ
фармацевта-кассира аптечного пункта.

.8.     «Материальный склад». Заявки на закупку. Контракты. Движение ТМЦ.
Инвентаризация. Анализ движения ТМЦ. АРМ заведующего материальным складом. АРМ
сотрудника материального склада. АРМ материально-ответственного лица
подразделения.

.9.     «Отчетно-аналитический модуль матучета». Отчеты по движению
товарно-материальных ценностей. Аналитические таблицы по движению
товарно-материальных ценностей. Добавление свойств аналитических объектов.
Фармако-экономический анализ. АРМ заведующего/зам. заведующего аптекой. АРМ фармацевта-провизора
отдела ГЛФ. АРМ фармацевта-провизора РПО.

.10.   «Интеграция с бухгалтерскими ИС». Ядро механизма интеграции.
Адаптер для интеграции с 1С. Адаптер для интеграции с ИС Парус. Выгрузка
данных/документов. Загрузка данных/документов. АРМ оператора интеграции.

.11.   «Настройка и конфигурирование матучета». Справочники матучета.
Справочная информация. Средства настройки матучета. АРМ администратора
подсистемы.

.        Подсистема организации питания. Включает в себя:

.1.     «Диетслужба». Рабочие меню и предварительные ординаторские
требования. Корректирующие ординаторские требования. Основное требование на
продукты. Корректирующее требование на получение и возврат продуктов. Заказные
диеты и дополнительное питание. Ординаторские требования на основе врачебных
назначений диет. Сводные ординаторские требования. АРМ диетврача/диетсестры.
АРМ постовой медсестры (заказ питания).

.2.     «Экономика питания». Расчет стоимости питания.
Персонифицированный учет стоимости питания пациентов. АРМ экономики питания.

.3.     «Пищевой склад». Движение продуктов на складе. Инвентаризация.
Отчетность по складу. АРМ кладовщика пищевого склада.

.4.     «Интеграция с бухгалтерскими ИС». Экспорт данных. Импорт данных.
АРМ бухгалтера.

.5.     «Настройки и конфигурирование». Справочники. АРМ администратора
подсистемы.

.        Подсистема помощи на дому и скорой помощи. Включает в себя:

.1.     «Помощь на дому». Оформление помощи на дому. АРМ диспетчера
помощи на дому. АРМ врача помощи на дому.

.2.     «Скорая помощь». Оформление вызовов скорой помощи. АРМ диспетчера
скорой помощи. АРМ врача скорой помощи. АРМ заведующего отделением скорой
помощи.

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

.1.     «Экспертиза временной нетрудоспособности». Оформление листков
нетрудоспособности. Учет бланков листков нетрудоспособности. АРМ оператора по
ведению листков нетрудоспособности.

.2.     «Врачебные комиссии». Направления и документы Врачебных комиссий.
Военно-врачебные комиссии. Учет работы врачебных комиссий. АРМ зам. главного
врача по КЭР.

.3.     «Управление качеством медицинской помощи». Ведение федеральных и
учрежденческих стандартов медицинской помощи. Контроль ЛДП по стандартам
медицинской помощи. Клинический аудит.

.        Подсистема учета высокотехнологичной помощи и связи с порталом
ВМП. Включает в себя:

.1.     «Высокотехнологичная медицинская помощь». Оказание
высокотехнологичной медицинской помощи. Взаимодействие с порталом ВМП. АРМ
регистратора ВМП.

.        Подсистема интеграции с внешними информационными системами.
Включает в себя:

.1.     «Интеграция с внешними информационными системами». Интеграция с
электронной регистратурой ЕГИСЗ. Интеграция с информационными системами
сторонних производителей. АРМ оператора интеграции.

.        Подсистема ведения административных сведений ЛПУ. Включает в
себя:

.1.     «Паспорт ЛПУ». Паспорт медицинской организации.

.        Подсистема управления доступом пациентов в ЛПУ. Включает в себя:

.1.     «Доступ пациентов в ЛПУ». Управление доступом пациентов в ЛПУ.

.        Подсистема защиты информации. Включает в себя:

.1.     «Конструирование прав доступа». Редактор прав доступа.

.2.     «Управление информационной безопасностью МИС». Модуль задания
политик безопасности. Модуль управления доступом. Модуль регистрации и учета.
Механизм обеспечения целостности. АРМ администратора информационной
безопасности.

.3.     «Деперсонификация данных». Механизм обезличивания электронных
медицинских карт.

.        Общесистемные компоненты. Включает в себя:

.1.     «Общесистемные механизмы». Ядро системы. Электронная медкарта.
Универсальное интерфейсное решение «Рабочий стол». Модуль ведения
нормативно-справочной информации.

.2.     «Модуль администрирования». Управление учетными записями.
Компоненты административной подсистемы. Модуль управления привилегиями
пользователей. Модуль контроля оборудования и системного программного
обеспечения серверов. Модуль установки обновлений. АРМ администратора системы.

.3.     «Средства настройки и адаптации». Конструктор информационных
объектов. Конструктор медицинских документов. Конструктор бланков.

1.5    МИС
«Дока +»

Система создана на базе интранет-технологии, это означает, что медикам,
имеющим хотя бы небольшой опыт использования Интернета, учиться использованию
МИС «ДОКА+» вообще не придется. Дело в том, что работа пользователей
с системой осуществляется через программу — браузер, которая служит и для
взаимодействия с Интернетом.

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

.        Ведение клинической документации (компьютерная история болезни).

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

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

.        Компьютерный заказ назначений на обследование и лечение.

МИС «ДОКА+» дает возможность врачам назначать в компьютере
лечение и обследования пациентов.

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

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

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

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

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

.        Встроенные механизмы поддержки принятия решений врача.

В клинической информационной системе «ДОКА+» при входе врача в
режим назначения препаратов выводится таблица с антропометрическими данными
пациента, осложнениями, сопутствующими диагнозами, текстом намеченного ранее
плана лечения.

Пример более сложного механизма поддержки решений врача, реализованного в
системе, — использование стандартных протоколов лечения и обследования. Пользователь
системы «ДОКА+» имеет возможность создать клинико-диагностические
группы, выбрать для каждой из них набор обследований, сформулировать план
лечения и критерий качества при выписке. Эта информация предъявляется врачам
при выполнении соответствующей работы.

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

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

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

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

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

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

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

«ДОКА+» создает стандартные для стационаров отчеты:
использование коечного фонда, работа отделений, журналы операций и т. д. Кроме
этого, персонал больницы может формировать и произвольные запросы к информации,
содержащейся в историях болезни. Важно, что у персонала есть возможность
расширять список атрибутов историй болезни, а потом использовать вновь
созданные атрибуты для включения их в отчеты.

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

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

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

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

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

.        Информатизация работы аптеки стационара.

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

с истекающим сроком годности;

меньше необходимого минимума;

по каждой из групп препаратов;

с признаком жизненно важных или экстренных препаратов и т. п.

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

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

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

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

.        Персонифицированное распределение и учет медикаментов

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

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

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

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

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

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

Единственное, что требуется для удаленного доступа — это защищенная связь
внутрибольничной локальной сети с сетью Интернет. Очевидно, что для доступа в
медицинскую информационную систему «ДОКА+» необходимо
зарегистрироваться в ней, то есть ввести имя и пароль пользователя системы.
После этого пользователь получает все привычные для него возможности работы с
информацией.

.        Информатизация работы санатория.

В системе ДОКА+ реализованы специально для врачей санаториев следующие
важные для них возможности:

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

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

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

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

.        Электронная регистратура.

В системе ДОКА+ реализованы возможности, необходимые для использования в
регистратуре поликлиники — «Электронная регистратура».

Они включают в себя:

ведение расписания приема врачей (участковых и узких специалистов);

запись пациента на прием к врачу в регистратуре поликлиники;

запись пациента на прием к врачу другим врачом поликлиники;

запись пациента на прием к врачу по телефону;

запись пациента на прием к врачу через интернет;

запись пациента на прием к врачу посредством инфомата (информационного
киоска).

Во всех перечисленных случаях для записи регистратор или пациент выбирает
любой день и удобное свободное время. Количество интервалов времени для записи
пациентов через интернет может быть ограничено администратором. При самозаписи
пациентов система осуществляет проверку действительности полиса медицинского
страхования либо непосредственно на сайте Территориального ФОМС, либо по
актуальной базе данных полисов в ЛПУ.

Электронная регистратура МИС ДОКА+ работает в настоящее время в ЛПУ
Приморского и Ставропольского краев, в Кемеровской и Новосибирской области.

1.6
С.О.П.О.Р.

медицинский информационный программный инструментальный

С.О.П.О.Р. — программа предназначена для создания и хранения медицинских
записей (дневников, первичных осмотров, эпикризов) врачами поликлиник и
стационаров. Главным образом данная программа ориентирована для использования
неврологами, терапевтами, кардиологами, реаниматологами, стоматологами,
медицинскими психологами.

С.О.П.О.Р. разработана Чернышковым Евгением — неврологом Регионального
сосудистого центра г. Курска и находится в общем доступе.

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

В настоящий момент реализованы следующие возможности:

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

Автоматическое создание статистической карты выбывшего из стационара (с
указанием кодов и шифров) при оформлении выписного эпикриза

Подробный осмотр медицинским психологом, стоматологом

Оформление бланков заявлений

Калькулятор для расчета доз нитроглицерина и дофамина

Прямая печать из программы

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

Изменение цветовой схемы приложения

Проверка обновлений программы с сайта

Полная совместимость с Windows XP, Windows Vista, Windows 7

Программа не нуждается в установке и может работать с флеш-карты: при
этом автоматически создается конфигурационный файл с настройками и информацией
о списке врачей, наименовании ЛПУ и прочее.

Рисунок 1.6.1 С.О.П.О.Р.: главная форма

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

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

Рисунок 1.6.2 С.О.П.О.Р.: выбор параметров общего состояния

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

Глава 2. Разработка проекта

2.1    Выбор
сред разработки программного обеспечения

В качестве среды разработки автоматизированного рабочего места выбрана Microsoft Visual C# 2013, которая позволяет создавать мощные,
высокопроизводительные приложения. Visual C# —
объектно-ориентированный язык программирования, который был разработан группой
инженеров в компании Microsoft как язык разработки приложений для платформы Microsoft .NET Framework.

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

Язык C# выбран в связи с расчетом на высокую скорость разработки, легкость
поддержки и возможность использовать Microsoft XNA для дальнейшей разработки
игровых приложений. Приложения, написанные на языке C# работают на программной
платформе Microsoft .NET Framework. Однажды написанное приложение под
актуальную версию .NET Framework будет точно так же выполняться и под
следующими версиями, независимо от аппаратной архитектуры и версии операционной
системы. Также платформа .NET Framework поддерживает JIT-компиляцию, что
дополнительно ускоряет выполнение кода в данной среде.

Для хранения данных в Visual C# 2013 была
интегрирована Microsoft Access 2010. Microsoft Access —
реляционная СУБД корпорации Microsoft. Она имеет широкий спектр функций,
включая связанные запросы, связь с внешними таблицами и базами данных.

Созданная в Microsoft Access 2010 база данных включает в себя
информацию о пациенте, дневник пациента и справочные материалы, такие как
лекарственные препараты, перечень токсических веществ, методики оказания
неотложной помощи или иных способов детоксикации.

Для подключения Microsoft Access к Visual C# использована технология доступа к данным ActiveX Data Object, именуемая в среде Visual C# как ADO.NET. ADO.NET — это набор классов,
предоставляющих службы доступа к данным программисту, работающему на платформе
.NET Framework. ADO.NET имеет богатый набор компонентов для создания
распределенных приложений, совместно использующих данные. Это неотъемлемая
часть платформы .NET Framework, которая предоставляет доступ к реляционным
данным, XML-данным и данным приложений. ADO.NET удовлетворяет различные
потребности разработчиков, включая создание клиентских приложений баз данных, а
также бизнес-объектов среднего уровня, используемых приложениями, средствами,
языками и браузерам..NET предоставляет согласованный доступ к таким источникам
данных, как SQL Server и XML, а также к источникам данных, предоставляемым при
помощи OLE DB и ODBC. Пользовательские приложения, использующие общие данные,
могут использовать ADO.NET для соединения с этими источниками данных и для
получения, обработки и обновления имеющихся в них данных..NET разделят доступ к
данным и обработку данных на дискретные компоненты, которые могут
использоваться отдельно или совместно. ADO.NET включает поставщиков данных .NET
Framework для соединения с базой данных, выполнения команд и получения
результатов. Эти результаты, помещенные в объект ADO.NET DataSet,
обрабатываются непосредственно, чтобы они могли быть предоставлены пользователю
нерегламентированным образом, объединенные с данными из многих источников или
передаваемые между уровнями.

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

Большинство манипуляций с данными базы осуществляются с помощью SQL — формального непроцедурного языка
программирования, применяемого для создания, модификации и управления данными в
произвольной реляционной базе данных, управляемой соответствующей СУБД.

2.2    Необходимые
данные и структурная схема программного обеспечения

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

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

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

Схема 2.2.1 Структурно-функциональная схема АРМ

Схема 2.2.2  Структурно-функциональная схема МИС

2.3   
Разработка системы поддержки принятия решения

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

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

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

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

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

Таблица 2.3 Табличная реализация системы поддержки принятия решения

Симптом/ Яд	1	2	3
1	—	+	—
2	+	+	+
3	—	—	—

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

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

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

Глава 3. Разработка программного обеспечения

.1 Общее
описание разработанного ПО

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

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

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

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

.2 Создание
базы данных для ПО

Для реализации программного обеспечения, которое бы представляло собой АРМ
врача-токсиколога реаниматолога, необходимо было создать базу данных, хранящую
в себе всю занесенную информацию. Для создания такой БД в данной бакалаврской
работе была выбрана среда Microsoft Access.

Основными предметно-значимыми сущностями создаваемой БД являются: Пациент
(DataBase_Patient), Врач (DataBase_Doctor), Первичный
осмотр (DataBase_FirstView), Инструментальные исследования (DataBase_InstrumentalSurvey), Лабораторные исследования (DataBase_LaboratorySurvey), Состояние пациента (DataBase_StatePatient) и Лечение пациента (DataBase_Therapy).

Основными предметно-значимыми атрибутами сущностей являются:

Пациент: код пациента, фамилия, имя отчество, дата рождения, телефон,
место жительства, код лечащего врача;

Врач: код врача, фамилия, имя, отчество, контактный телефон, логин,
пароль;

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

Инструментальные исследования: код записи, код пациента, УЗИ почек, УЗИ
мочевого пузыря, ЭКГ, дата и время.

Лабораторные исследования: код записи, код, пациента, анализ крови,
анализ мочи, дата и время.

Состояние пациента: код записи, код пациента, общее состояние, состояние
сердца, легких, желудка, почек, наличие симптома Пастернацкого, состояние при
мочеиспускании, стуле, дата и время.

Лечение пациента: код записи, код пациента, медикаментозное лечение,
усиление естественной детоксикации, хирургическая детоксикация, рекомендации,
дата и время.

Между таблицами DataBase_Doctor и DataBase_Patient необходимо установить связь «один-ко-многим», т.к.
один доктор может лечить нескольких пациентов.

Между таблицами DataBase_FirstView и DataBase_Patient устанавливается связь «один-ко-одному», т.к. каждому
пациенту проводят один первичный осмотр.

Между таблицами DataBase_Patient и DataBase_InstrumentalSurvey, DataBase_StatePatient, DataBase_LaboratorySurvey, DataBase_Therapy необходимо установить связь «один-ко-многим», т.к.
каждому пациенту несколько раз проводят исследования, назначают лечение и
описывают его состояние.

Ниже приведена диаграмма, отображающая отношения «Сущность-Связь».

Рисунок 3.2.1 Диаграмма «Сущность-связь»

Проведем нормализацию отношений.

Отношение находится в первой нормальной форме (1НФ), если все его
атрибуты простые, и оно не имеет повторяющихся записей (строк — дубликатов). Ключ
запрещает повторения записей. В созданной БД все таблицы имеют ключевое поле с
уникальным индексом, следовательно, условия 1НФ выполняются.

Отношение находится во второй нормальной форме (2НФ), если оно имеет 1НФ
и каждый его не ключевой атрибут зависит от полного ключа, но не от его
подмножества. Другими словами, в таком отношении не должно быть функциональных
зависимостей не ключевых атрибутов от части (подмножества) ключа. В созданной
БД нет таблиц с составным ключом.

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

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

Целостность данных обеспечивает защиту данных по полям связи,
предотвращает появление «висящих» записей (записей в подчиненной
таблице, не имеющих соответствующих записей в главной таблице).

Рисунок 3.2.2 Схема данных в Microsoft Access

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

DataBase_Preparation хранит перечень препаратов, выписываемых пациенту.
Имеет атрибуты: код препарата, название препарата, способ применения.

DataBase_SurgeryDetox хранит перечень методов хирургической детоксикации
пациента. Имеет атрибуты: код записи, вид хирургической детоксикации.

Для реализации системы поддержки принятия решения, были созданы таблицы:

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

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

DataBase_SymptomToxin хранит соответствие симптомов и токсинов. Имеет
атрибуты: код токсина, код симптома.

Рисунок 3.2.2 Схема данных для справочников

3.3
Реализация ПО в Microsoft Visual C# 2013

.3.1 Форма авторизации (Login)

Форма для входа в программу позволяет ввести имя пользователя и пароль.
Если проверка на совпадение данных пройдена, то осуществляется вход в систему.
Алгоритм работы приведен на блок-схеме:

Рисунок 3.3.1.1 Блок-схема алгоритма авторизации

Имя пользователя и пароль хранится в БД, при нажатии кнопки «Войти»
происходит проверка совпадения введенных данных при помощи SQL-запроса:

SELECT Count(*) FROM DataBase_Doctor WHERE Login=? and
[Пароль]=?

Данные для сравнения берутся из полей ввода. Если запрос возвращает хотя
бы одно совпадение, открывается главная форма. Если совпадений нет — появляется
сообщение об ошибке и пользователю предлагается еще раз ввести данные.

.3.2 Главная
форма (InitialForm)

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

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

Выборка пациентов для авторизовавшегося врача осуществляется с помощью SQL-запроса:

SELECT * FROM DataBase_Pacient where Лечащий_врач = » +
code_doctor

где code_doctor — полученный из формы Login код лечащего врача.

Данные о пациентах загружаются в компонент DataGridView.

Рисунок 3.3.2.1 Блок-схема алгоритма работы главной формы

Рисунок 3.3.2.2 Блок-схема алгоритма вывода информации для выбранного
пациента

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

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

При добавлении нового пациента в БД из программы используется SQL-запрос

INSERT INTO DataBase_Pacient (Фамилия, Имя, Отчество, Дата_рождения, Телефон,
Место_жительства) values (‘» + a_surname + «‘, ‘» + a_name +
«‘,'» + a_middlename + «‘,'» + a_date + «‘,'» + a_phone +
«‘,'» + a_sity + «‘)? где перечисленные
переменные хранят данные, внесенные в поля формы Add_Patient.

Рисунок 3.3.2.4 Блок-схема алгоритма работы функции «Добавить карту
пациента»

При редактировании карты пациента используется SQL-запросDataBase_Pacient SET Фамилия = ‘» +
AddPatient.tBSurname.Text + «‘, Имя = ‘» + AddPatient.tBName.Text +
«‘, Отчество = ‘» + AddPatient.tBMiddleName.Text + «‘,
Дата_рождения = ‘» + AddPatient.dTBirthDay.Value.Date + «‘, Телефон =
‘» + Convert.ToInt32(AddPatient.tBPhone.Text) + «‘, Место_жительства
= ‘» + AddPatient.tBSity.Text + «‘ WHERE Код_пациента = » +
code_patient

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

Рисунок 3.3.2.5 Блок-схема алгоритма работы функции «Редактировать
карту пациента»

Функция удаления карты пациента реализована с помощью SQL-кода* FROM DataBase_Pacient WHERE
(Код_Пациента =» + c_pacient_delete + «)

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

Рисунок 3.3.2.6 Блок-схема алгоритма работы функции «Удалить карту
пациента»

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

Рисунок 3.3.2.7 Блок-схема алгоритма работы функции «Поиск карты
пациента»

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

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

Рисунок 3.3.2.8 Блок-схема алгоритма обработчика двойного нажатия по полю
DataGridView

.3.3 Форма
первичного осмотра (FirstView)

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

Данные для заполнения формы первичного осмотра берутся из БД с помощью SQL-кода

SELECT * FROM DataBase_FirstView where Код_Пациента = »
+ _patientCode

где переменная передает значение кода выбранного пациента.

Рисунок 3.3.3.1 Блок-схема алгоритма работы формы FirstView

Функции importFromDB() и exportToDB() необходимы для загрузки данных из
БД и выгрузки данных в БД. На всех формах добавления или редактирования
дневника пациента они работают одинаково, отличие лишь в содержимом
передаваемых данных.

Для выгрузки данных в БД используется SQL-код

UPDATE DataBase_FirstView SET (Столбцы таблицы и передаваемые данные)

если данные редактируются иINTO DataBase_FirstView (Столбцы таблицы и
передаваемые данные)

если данные добавляются.

Рисунок 3.3.3.2 Блок-схема алгоритма работы функции importFromDB()

Рисунок 3.3.3.3 Блок-схема алгоритма работы функции exportToDB()

На форме шаблона ввода данных в поле «Выявленные симптомы» реализована
система поддержки принятия решения. Она заключается в выборе симптомов,
выявленных у пациента, которые заносятся в listBox, далее из БД берутся соответствующие выбранным
симптомам токсины и выводятся в порядке уменьшения количества симптомов для
каждого отравляющего вещества.

Выборка возможных видов токсина осуществляется с помощью SQL-кодаTOP 5 DataBase_Toxin.Название_яда FROM DataBase_Toxin INNER JOIN DataBase_SymptomToxin ON
DataBase_Toxin.Код_яда = DataBase_SymptomToxin.Код_яда(((DataBase_SymptomToxin.Код_симптома) In (» + list_sympt
+ «))) GROUP BY DataBase_Toxin.Название_ядаBY Count(DataBase_SymptomToxin.Код_яда) DESC

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

3.3.4 Форма
инструментальных исследований (InstrumentalSurvey)

Данная форма позволяет врачу внести данные по проведенным
инструментальным исследованиям пациента, таким как УЗИ почек, мочевого пузыря
или ЭКГ. Врач может как самостоятельно вписать необходимые данные, так и
воспользоваться шаблонами.

В данной форме так же используются функции загрузки из БД importFromDB() и выгрузки в БД exportToDB(), описанные ранее. Блок-схема
алгоритма работы формы InstrumentalSurvey.

.3.5 Форма
лабораторных исследований (LaboratorySurvey)

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

В данной форме используются функции загрузки из БД importFromDB() и выгрузки в БД exportToDB(), описанные ранее. Блок-схема
алгоритма работы формы.

3.3.6 Форма
ввода параметров состояния пациента (StatePatient)

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

В данной форме используются функции загрузки из БД importFromDB() и выгрузки в БД exportToDB(), описанные ранее. Блок-схема
алгоритма работы формы.

3.3.7 Форма
назначения лекарств, процедур и рекомендаций (Therapy)

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

В данной форме используются функции загрузки из БД importFromDB() и выгрузки в БД exportToDB(), описанные ранее. Блок-схема
алгоритма работы формы такая же, как в Рисунке 3.3.3.1

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

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

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

Данные для заполнения справочников взяты из учебника для
врачей-токсикологов [1].

.4 Дальнейшее
развитие

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

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

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

Дальнейшим развитием данного АРМ может стать его улучшение и внедрение в
существующие МИС.

Заключение

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

Чтобы решение было полным, необходимо непосредственное участие
врача-токсиколога, для более подробного добавления справочных материалов, базы
данных отравлений и симптоматики.

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

Список использованных источников

1.      Суворов,
А.В. Справочник по клинической токсикологии [Текст]: карманный справочник врача
— Нижний Новгород: НГМА, 1996. — 180 с.

2.      Главные новости дня —
Газета.Ru [Электронный ресурс] — Режим доступа
<http://www.gazeta.ru/health/2014/01/17_a_5852361.shtml> Дата обращения:
4.02.2014.

.        Интернет-журнал про
Сибирь — Сиб.Фм [Электронный ресурс] — Режим доступа
<http://sib.fm/news/2014/02/03> Дата обращения: 15.03.2014.

.        Елизарова, О.Н.
Пособие по токсикологии для лаборантов [Текст]: учеб. пособие / О.Н. Елизарова,
Л.В. Жидкова, Т.А. Кочеткова — Москва: «Медицина», 1974. — 168 с.

.        Прозоровский, В.И.
Судебная медицина [Текст]: учеб. пособие — Москва: «Юридическая литература»,
1968. — 368 с.

.        Веселовская, Н.В.
Наркотики. Свойства, действие, фармакокинетика, метаболизм [Текст]: учеб.
пособие / Н.В. Веселовская, А.Е. Коваленко — Москва: «Триада-Х», 2000. — 204 с.

.        Симонов, Е.А.
Наркотики. Методы анализа на коже, в ее придатках и выделениях [Текст]: учеб.
пособие / Е.А. Симонов, Б.Н. Изотов, А.В. Фесенко — Москва: изд. «Анахарсис»,
2000. — 130 с.

.        ИНТЕРИН —
Медицинские информационные системы [Электронный ресурс] — Режим доступа

<http://www.interin.ru/datas/documents/Interin.PROMIS.Structure.pdf>
Дата обращения: 3.05.2014.

9.      Научно-промышленная
компания АИТ — холдинг

[Электронный
ресурс] — Режим доступа://www.ait.ru/prod/everest.html Дата обращения:
3.05.2014.

.        Комплексные
медицинские информационные системы — КМИС [Электронный ресурс] — Режим
доступа://www.kmis.ru/site.nsf/pages/kmis_index.htm

Дата
обращения: 3.05.2014.

.        Медицинская
информационная система МЕДИАЛОГ

[Электронный
ресурс] — Режим доступа

<http://www.medialog.ru/?tree_id=36>
Дата обращения: 3.05.2014.

12.    БАРС Груп:
Облачные технологии управления [Электронный ресурс] — Режим доступа

<http://bars-open.ru/solution/zdravookhranenie/meditsinskaya-informatsionnaya-sistema>
Дата обращения: 3.05.2014.

13.    Медицинская
информационная система ДОКА+

[Электронный
ресурс] — Режим доступа://www.docaplus.com/russian/pages/pages.php?ir=12

Дата
обращения: 3.05.2014.

Подробности

Опубликовано: 10.07.2018 11:29

Автор: Деревнина Ангелина Михайловна

Просмотров: 4933

Аннотация: реализуется приложение на основе MS Access для автоматизированного рабочего места врача невролога на основе метода Agile Scrum. Проводится анализ требований позволяющий сформировать бэклог продукта, а также задать и определить бэклог спринтов. Идентифицированные ключевые бизнес-процессы врача невролога проектируются в нотации UML Activity Diagram с разным уровнем детализации, кроме того, ведется задание архитектуры данных. Смоделированные процессы и данные реализуются в среде MS Access. Проводятся функциональное и интеграционные виды испытаний разработанного приложения.
Скачать: PDF, PPT.
Ключевые слова: гибкая agile scrum, agile scrum проект, agile scrum разработка, арм врача невролога, рабочее место врача невролога, бизнес процессы врача невролога, обследование врача невролога, медико информационные системы, медицинские информационные системы, ЕГИСЗ, классификация медицинских информационных систем, информационная модель лечебно-диагностического процесса, автоматизация неврологии, диаграмма деятельности UML, диаграмма активности UML Actvity Diagram, диаграмма классов UML Class Diagram, осмотр врача невролога, неврологический осмотр пациента, осмотр невропатолога.

Введение

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

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

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

Объем профессиональных знаний, которые необходимы для успешной работы врача, сильно велик. Сейчас он увеличивается и продолжает постоянно расти. Поэтому на сегодняшний день автоматизация рабочего места врача является значимым фактором в оперативности доктора. Этого можно достигнуть за счет разработки приложения с помощью систем управления базами данных (СУБД), например, MS Access.  Данное приложение совместимо с операционной системой Microsoft Windows, которая используется на большинстве компьютеров медицинских учреждений, что важно для удобства использования. 

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

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

• описать и применить методологию внедрения ИС при помощи методологии Agile Scrum;
• идентифицировать требования, предъявляемые к приложению;
• спроектировать процессы, данные и программы;
• разработать приложение в среде MS Access;
• провести тестирование.

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

Раздел 1. Описание модели внедрения программных продуктов Agile Scrum

1.1. Гибкая методология разработки Agile

Разработка программного обеспечения – это труд, который требует своевременного принятия правильных решений. Но все принимаемые решения нужно как-то «упорядочить». Сегодня одним из ценных качеств руководителя при построении современного бизнес-процесса считается умение управлять командами, работающими над проектом в целом и над отдельными продуктами. Для этого требуется особый гибкий подход, доверие коллегам и готовность к изменениям рынка. Принципы гибкого управления включены в концепцию Srum и Agile, разработанную компаниями, занятыми в сфере IT.

Agile – это семейство «гибких» подходов к разработке программного обеспечения. Согласно данному подходу, проект разбивается не на последовательные фазы, а на маленькие подпроекты, которые затем «собираются» в готовый продукт. Таким образом, верхнеуровневое планирование проводятся для всего проекта, а последующие этапы: разработка, тестирование и прочие проводятся для каждого мини-проекта отдельно.  Agile возник в IT-среде, но затем распространился и в другие сферы – от промышленной инженерии до искусственного интеллекта. 

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

1.2. Методология Scrum

К отдельному Agile-подходу относится Scrum – «подход структуры».  То есть это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные и небольшие по времени циклы, называемые спринтами (Sprints), предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет. Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. При этом строго фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость. В основе методологии Scrum лежит простая идея. Когда бы ни был запущен проект, вам ничто не мешает регулярно проверять ход работ и последовательно выяснять: справляетесь ли вы с заданием; в нужном ли направлении движетесь; создаете ли именно то, что на самом деле хочет получить заказчик. Вам также ничто не мешает постоянно поднимать следующие вопросы: есть ли способы усовершенствовать методы разработки и выполнять работу наиболее качественно и быстро; существуют ли факторы, препятствующие вашим задачам [1].

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

• первым делом надо выбрать «Владельца продукта» (Product owner) – человека, способного видеть то, что вы собираетесь создать или достигнуть.  Он является связующим звеном между командой разработки и заказчиком. Его задачей является максимальное увеличение ценности разрабатываемого продукта и работы команды;
• затем нужно собрать «Команду разработки» (Development team), в которую войдут люди, непосредственно выполняющие работу. Они должны обладать навыками и знаниями, которые помогут воплотить идею владельца продукта в жизнь. А также следует иметь такие качества и характеристики, как самоорганизация и многофункциональность;
• далее необходимо выбрать «Скрам-мастера» (Scrum master) — того, кто будет следить за ходом реализации проекта и помогать команде устранять препятствия на пути достижения цели;
• приступая к работе, нужно создать максимально полный список всех требований, предъявляемых к продукту или цели, упорядоченный по их степени важности, подлежащих реализации. Пункты этого списка должны быть расставлены по приоритету. Список носит название «Бэклог продукта» (Product Backlog). Он может развиваться и изменяться на протяжении всего срока реализации проекта;
• участники команды должны оценить по своей системе оценок каждый пункт на предмет сложности и затрат, которые потребуются для его выполнения. Затем участники, скрам-мастер и владелец продукта должны провести первое скрам-собрание, на котором они запланируют спринт — определенное время для выполнения части заданий. Продолжительность его не должна превышать один месяц. Тем не менее, считается, что чем короче спринт, тем более гибким является процесс разработки, релизы выходят чаще, быстрее поступают отзывы от потребителя, меньше времени тратится на работу в неправильном направлении. С другой стороны, при более длительных спринтах команда имеет больше времени на решение возникших в процессе проблем, а владелец проекта уменьшает издержки на совещания, демонстрации продукта и т. п. Бывает такое, что приходится останавливать спринт, но это происходит в исключительных ситуациях. Спринт может быть остановлен до того, как закончатся отведенные дни, или его может остановить команда, если понимает, что не может достичь цели спринта в отведенное время. Спринт может остановить владелец продукта, если необходимость в достижении цели спринта исчезла;
• команда должна всё время стремиться к тому, чтобы превзойти в новом спринте свои собственные результаты за предыдущий спринт;
• по завершении спринта команда делает его обзор — проводит встречу, на которой участники рассказывают, что сделано за спринт;
• после показа результатов работы за спринт участники проводят ретроспективное собрание, на котором обсуждают, что команда делала хорошо, что можно сделать лучше, что можно улучшить прямо сейчас.

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

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

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

• быстрый запуск;
• быстрое реагирование на изменения — гибкость и адаптивность;
• связь в реальном времени между командой и клиентом,

а также минусы:

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

Раздел 2. Идентификация требований 

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

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

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

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

2.1. Пользовательские и функциональные требования, их приоритизация

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

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

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

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

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

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

• Must have this – это обязательно должно быть. «Must» требования не подлежат обсуждению и в любом случае должны быть реализованы. Если они не поставлены пользователю в ближайших релизах, тогда весь проект не имеет смысла.
• Should have this if at all possible – следует сделать, если это только возможно. Данные задачи также важны для пользователя иили заказчика, однако, сроки их поставки не так критичны, как для «Must». В эту категорию входят требования, которые критичны для функционала, но не для текущего релиза. 
• Could have this if it does not affect anything else – можно сделать, если это не повлияет на что-то другое. Эта категория требований, которую желательно включить, но она не влияет на релиз успеха.
• Will not have this time but would like in the future – сейчас на это нет времени, но хотелось бы сделать в будущем. Для этой категории ключевым моментом является то, что данные требования могут быть также важны (также, как и «Must»), однако, их можно оставить для более поздних поставок продукта. 

Используя этот метод, можно определить приоритеты:

• Must have this – требование 1. Поскольку именно это требование является основой ко всему ПО.
• Should have this if at all possible – требования 5-6. Это те требования, позволяющие производить непосредственно работу врача.
• Could have this if it does not affect anything else – требования 2-4. В MS Office Access можно создать формы, которые позволяют просматривать данные. Это выглядит удобнее и приятнее, но просмотреть данные можно и просто в таблицах, открыв окно редактирования.
• Will not have this time but would like in the future – требование 8. Это требование можно оставить на потом.

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

• база данных, содержащая таблицы «Личные данные пациентов», «Лечение пациентов», «Посещения», «Общий осмотр»;
• вывод на экран данные из таблицы «Личные данные пациентов»;
• вывод на экран данные из таблицы «Лечение пациента»;
• вывод на экран данные из таблицы «Общий осмотр»;
• вывод на экран данные из таблицы «Посещения»;
• добавление данных о пациенте; 
• редактирование данных о пациенте в таблице «Личные данные пациентов»; 
• редактирование данных о пациенте в таблице «Общий осмотр»; 
• редактирование данных о пациенте в таблице «Лечение пациента»;
• поиск конкретного пациента по ФИО;
• поиск конкретного пациента из таблицы «Посещения»;
• печать отчёта, содержащего личные данные пациента, общий осмотр и посещения;
• программа должна корректно работать на всех компьютерах медучреждения;
• данные хранятся непосредственно в создаваемом приложении;
• установление пароля на саму базу данных;
• доступность (легкость восприятия). 

2.2. Бэклог продукта

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

Таблица 2.1. Бэклог продукта

№	Пользовательское требование	Приоритет MuSCoW	Функциональное требование	Программный компонент
1	Хранение данных	Must have	Хранение информации о пациентах, их лечении, о посещениях врача, о типах обследования, о препаратах	Программы, работающие с базами данных «Личные данные пациента», «Лечение пациента», «Осмотр пациента», «Типы обследования», «Препараты», «Посещения»
2	Возможность поиска данных определенной информации о конкретном пациенте	Should have	Поиск конкретного пациента по ФИО	Программа для поиска
3	Возможность просмотра всех посещений конкретного пациента	Should have	Поиск конкретного пациента из таблицы «Посещения»	Программа для поиска
4	Редактирование данных о пациенте в таблице «Личные данные пациентов»	Should have	Функция изменения информации	Программа для изменения информации
5	Редактирование данных о пациенте в таблице «Общий осмотр»	Should have	Функция изменения информации	Программа для изменения информации
6	Возможность заводить информацию о пациентах	Should have	Функция добавления данных о пациенте	Программа для добавления информации
7	Возможность работы с приложением на любом компьютере медицинского учреждения	Should have	Программа должна корректно работать на всех компьютерах медучреждения	Среда разработки MS Access
8	Возможность вывода информации на бумажный носитель	Could have	Печать отчёта, содержащего личные данные пациента, общий осмотр и посещения	Программа для печати
9	Возможность просмотра личных данных пациента	Could have	Ведение таблицы данных «Личные данные пациента», содержащей информацию о пациенте	Программа по ведению личных данных пациента
10	Возможность просмотра данных о лечении пациента	Could have	Ведение таблицы «Лечение пациента», содержащей информацию о выписанных препаратах, типах обследования и диагнозе	Программа по ведению данных о лечении пациента
11	Возможность внесения изменения информации	Could have	Функция изменения информации	Программа для изменения информации
12	Защита информации от несанкционированного доступа	Could have	Установление пароля на саму базу данных	Программное обеспечение
13	Возможность просмотра всех посещений всех пациентов	Could have	Ведение таблицы «Посещения», содержащей информацию о дате посещения и времени посещения	Программа по ведению данных о посещениях
14	Простота и легкость интерфейса	Won`t have	Доступность (легкость восприятия)	Разрабатываемое ПО

 2.3. Задание циклов разработки согласно Agile Scrum

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

• Начало:
  • анализ требований;
  • моделирование ключевого бизнес-процесса с помощью нотации UML AD.
• Первый спринт:
  • хранение информации о пациентах, их лечении, о диагнозах, симптомах, о посещениях врача, о типах обследования, о препаратах. Для этого создадим нужные таблицы в определенной среде разработки;
  • тестирование реализованных возможностей программы;
  • демонстрация прототипа программы заказчику.
• Второй спринт:
  • возможность просмотра личных данных пациента, то есть ведение определенной таблицы (или таблиц), содержащей информацию об общем осмотре, о типах обследования; возможность изменения внесения информации; 
  • тестирование реализованных возможностей программы;
  • демонстрация прототипа программы заказчику.
• Третий спринт:
  • возможность поиска данных определенной информации о пациенте и возможность печати информации на бумажный носитель;
  • тестирование реализованных возможностей программы;
  • демонстрация прототипа программы заказчику.
• Четвертый спринт:
  • создание простого и легкого интерфейса; защита от несанкционированного входа;
  • исправление ошибок;
  • тестирование реализованных возможностей программы;
  • демонстрация прототипа программы заказчику.

Раздел 3. Проектирование ключевых бизнес-процессов

Главным принципом развития любого дела является управление, построенное на бизнес – процессах. При процессном управлении ключевые показатели эффективности кардинально улучшаются [2]. Бизнес-процесс – это устойчивая целенаправленная последовательность исполнения функций, направленная на создание результата, имеющего ценность для потребителя [3].

Модель бизнес-процесса формирует единую картину и видение ситуации сотрудников и руководства предприятия. Этот метод позволяет дать стоимостную оценку каждому отдельному процессу и всем бизнес-процессам организации в совокупности. При проектировании ключевых бизнес-процессов используют две модели: AS-IS (как есть) и TO-BE (как будет).

Прежде чем создать собственную информационную систему необходимо проанализировать, как работает система в настоящее время. Поэтому для описания работы проекта необходимо построить функциональную модель AS-IS. Анализ этой функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов. Детализация бизнес-процессов позволяет выявить недостатки. Построение модели AS-IS помогает точно зафиксировать, какие процессы осуществляются на предприятии в данный момент, какие информационные объекты используются при выполнении функций различного уровня конкретизации. Эта модель позволяет выяснить, «что» и «как» делать сейчас прежде, чем определить «что» и «как» будет делаться завтра.

Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ. Эта модель от предыдущей будет отличаться не кардинально, а только в небольшой своей части, то есть в каких-то нюансах. Модель ТО-ВЕ нужна для оценки последствий внедрения информационной системы и анализа альтернативных путей выполнения работы и документирования того, как система будет функционировать в будущем. По итогу прототип и потом конечный вариант информационной системы строится только на основе разработанной модели TO BE.

3.1. Проектирование на основе UML Activity Diagram

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

На схеме бизнес-процесса узлы процесса можно изображать различными образами. Способ изображения узлов и переходов важен, так как от этого зависит легкость или сложность понимания бизнес-процесса людьми. Согласованные наборы графических элементов, из которых строятся схемы бизнес-процессов, называются графическими нотациями изображения бизнес-процессов. В данной работе был выбран UML (Universal Modelling Language) – универсальный язык моделирования графического описания, предназначенный для объектного моделирования в области разработки программного обеспечения.

Для моделирования процесса выполнения операций в языке UML используются так называемые диаграммы деятельности (Activity diagram). Каждое состояние на диаграмме деятельности используются для представления действий, а переход в следующее состояние срабатывает только при завершении этой, операции в предыдущем состоянии. На диаграмме деятельности отображается логика или последовательность перехода от одной деятельности к другой, при этом внимание фиксируется на результате деятельности. Сам же результат может привести к изменению состояния системы или возвращению некоторого значения.

UML AD нотация проста для изучения неподготовленным пользователем, она интуитивно понятна. Данная нотация использует широко известные графические элементы. Например, в ней для выбора одного из нескольких направлений используется «ромбик». А параллельно выполняющиеся узлы-действия в этой нотации соединены с элементами – разделениями-слияниями параллельными линиями, что соответствует одновременно выполняющимся действиям. В UML AD нотации изображение процессов очень похоже на блок-схемы, то есть многим российским пользователям изображения в UML AD нотации сразу будут подсознательно ясны.

Таблица 3.1. Условные обозначения нотации

 

3.2. Проектирование процессов в модели AS-IS с помощью UML AD

На рис.3.1 рассматривается первый уровень проектирования процесса работы врача-невролога в аннотации UML AD модели «AS-IS», которая подразумевает под собой проектирование процессов в настоящий момент времени. На данном этапе проектирования описываются основной и вспомогательный бизнес-процессы врача-невролога. 

Рис. 3.1. Представление процесса в UML AD на первом уровне в модели «AS-IS»

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

В модели TO-BE, если сравнить рис.3.2 и рис.3.3, можно заметить, что вместо медицинской карты на бумажном носителе, направлений и справок, можно использовать электронную базу данных. В неё каждый сотрудник может вносить нужную информацию о пациенте: личную информацию, жалобы на состояние здоровья, результаты осмотра врачом. 

Рис. 3.2. Представление процесса в UML AD на втором уровне в модели «AS-IS»

Рис. 3.3. Представление процесса в UML AD на втором уровне в модели «TO-BE»

 

Рис. 3.4. Представление процесса в UML AD на третьем уровне в модели «AS-IS»

 

Рис. 3.5. Представление процесса в UML AD на третьем уровне в модели «TO-BE»

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

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

Раздел 4. Разработка приложения

4.1. Прототип программы (первый спринт)

Реализация программы на первом спринте представляет собой обычную таблицу с элементами управления самой среды разработки MS Access. Здесь нет никакого интерфейса, который мог бы облегчить работу пользователя с программой. Ниже представлен фрагмент таблицы «Личные данные пациента», созданной в программе MS Access. 

Рис. 4.1. Фрагмент таблицы «Личные данные пациента» базы данных

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

 

Рис. 4.2. Схема данных

4.2. Прототип программы (второй спринт)

На данном этапе реализовывается возможность просмотра данных, а также возможность изменения внесения информации. Для этого создаётся «Форма» – объект, с помощью которого пользователи могут добавлять, редактировать и отображать данные. Выпадающие списки, которые видны при нажатии на «стрелку», позволяют менять информацию.

Рис. 4.3. Форма «Общий осмотр» с возможностью выбора для изменения данных 

4.3. Прототип программы (третий спринт)

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

Рис. 4.4. Окно поиска посещений конкретного пациента

Рис. 4.5. Таблица с выданным запросом по поиску посещений на пациентку Ильченко

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

Рис. 4.6. Отчёт «Личные данные пациентов»

4.4. Конечная программа (четвертый спринт)

Четвертый спринт направлен на разработку интерфейса и навигацию. Конечный интерфейс разработанного приложения выглядит следующим образом (рис.4.7).

 

Рис. 4.7. Главное меню приложения 

Главное меню состоит из четырёх кнопок. Первая – «Личные данные пациента», при нажатии на нее появляются также четыре кнопки: «Просмотр личных данных пациентов», «Добавить нового пациента», «Найти пациента» и «Назад». При нажатии на «Добавить нового пациента» на экране появляется пустая форма, в которую можно добавить все личные данные нового пациента. 

Если нажать на «Лечение», то откроется интерфейс со следующими кнопками: «Общий осмотр», «Создать новую запись для общего осмотра», «Посмотреть назначенное лечение», «Назад». Далее были добавлены кнопки навигации. «Стрелки» влево и вправо позволяют переходить к предыдущей записи и следующей соответственно. Кнопка с изображением «Лупы» имеет функцию поиска, название кнопки «Выход» говорит само за себя.

 

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

 

Рис. 4.9. Таблица «Лечение пациентов» с возможностью выбора изменения данных и кнопками навигации

Последним пунктом разработки данного приложения была защита от несанкционированного доступа: при запуске приложения программа запрашивает пароль. Также были внесены исправления как функциональные, так и визуальные непосредственно в конечное меню интерфейса. В итоге получено приложение с главным меню для врача-невролога, содержащее 5 кнопок. Одна из кнопок – «Выход», позволяющая закрыть программу.

 

Рис. 4.10. Всплывающее окно при открытии базы данных

Раздел 5. Тестирование разработанного приложения

Тестирование является неотъемлемой частью разработки приложений. Это проверка соответствия между реальным и ожидаемым поведением программы, которая осуществляется на конечном наборе тестов, выбранном определённым образом. В данной работе при проектировании программного обеспечения была выбрана методология Agile Scrum, именно по этой причине невозможно не упомянуть об Agile-тестировании. Как было сказано в начале данной работы, Agile – гибкая методология, требующая командной работы со всеми участниками проекта. В этой методике каждый член команды несёт ответственность в соответствии со своей ролью и работой, также на протяжении всей разработки необходимы требования клиента и, самое главное, гибкий подход позволяет вносить изменения почти на любом этапе проектирования. Это значит, что в Agile Scrum тестировать необходимо в каждом итерации, что и было сделано в течение всей работы: тестирование проводилось в каждом спринте.

5.1. Функциональное тестирование

Тестирование программного обеспечения – процесс анализа программного продукта и сопутствующей документации с целью выявления недостатков в работе и повышения его качества [17]. Обычно для проверки работоспособности разработанного ПО проводят три вида тестирования: функциональное, интеграционное и нагрузочное. Функциональное тестирование (Functional testing) – вид тестирования, направленный на проверку корректности работы функциональности приложения (корректность реализации функциональных требований). 

Таблица 5.1. Функциональное тестирование

Функциональное требование	Программный компонент	Графическое представление
База данных, содержащая таблицы «Личные данные пациентов», «Лечение пациентов», «Посещения», «Общий осмотр»	Разрабатываемое ПО
Вывод на экран данные из таблицы «Личные данные пациентов»	Программа по выводу данных на экран о личных данных пациента
Вывод на экран данные из таблицы «Лечение пациента»	Программа по выводу данных на экран о лечении пациента
Вывод на экран данные из таблицы «Общий осмотр»	Программа по выводу на экран данных из таблицы «Общий осмотр»
Вывод на экран данные из таблицы «Посещения»	Программа по выводу данных на экран о посещениях пациентов
Добавление данных о новом пациенте	Программа по вводу данных о новом пациенте
Редактирование данных о пациенте в таблице «Общий осмотр»	Средство для изменения информации
Редактирование данных о пациенте в таблице «Личные данные пациентов»	Средство для изменения информации
Редактирование данных о пациенте в таблице «Лечение пациента»	Средство для изменения информации
Поиск конкретного пациента из таблицы «Посещения»	Программа по выводу на экран запрашиваемых данных
Поиск конкретного пациента по ФИО	Программа по выводу на экран запрашиваемых данных
Печать отчёта, содержащего личные данные пациента, общий осмотр и посещения программа должна корректно работать на всех компьютерах медучреждения	Средство для вывода информации
Данные хранятся непосредственно в создаваемом приложении	Разрабатываемое ПО
Установление пароля на саму базу данных	Разрабатываемое ПО

Таким образом, можно сказать, что функциональные требования были реализованы и функциональное тестирование прошло успешно. 

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

Любое программное обеспечение должно работать под нагрузкой длительное время. Сбои и отказы системы могут привести к убыткам, потере клиентов и другим неприятным последствиям. Нагрузочное тестирование позволяет определить, как и с какой скоростью работает программа под определенной нагрузкой. Посредством нагрузочного тестирования оценивается соответствие производительности продукта требованиям, сформулированным в задании. Для тестирования было выбрано следующее количество записей: 1, 10 и 100 (примерное количество пациентов за месяц). Данные по нагрузочному тестированию приведены в табл.5.2. На основе полученных результатов можно сказать, что нагрузочное тестирование прошло успешно.

Таблица 5.2. Результаты нагрузочного тестирования

Кол-во записей	Поиск имеющейся информации	Вывод на экран всей имеющейся информации
1	0,10 … 0,15 сек.	0,10 … 0,15 сек.
10	0,12 … 0,24 сек.	0,11 … 0,23 cек.
100	0,28 … 0,42 cек.	0,26 … 0,45 cек.

Заключение

Разработана медицинская информационная система. Возможности данной системы позволяют отражать данные о пациенте не только в виде традиционных разделов медицинской карты, но и представлять информацию в интересующих врача-невролога срезах. Доступ к базе данных происходит через интерфейс клиентского программного приложения врача-невролога [7].

Целью данной работы являлось создание автоматизированного рабочего места для врача-невролога. Необходимо было оптимизировать рабочий процесс с целью экономии времени сотрудника. Таким образом, в рамках данной работы была изучена и применена одна из самых популярных методологий гибкой разработки Scrum. В следующим пункте создания приложения были составлены модели AS-IS ключевого бизнес-процесса с помощью нотации UML Activity Diagram. Далее для реализации ПО были идентифицированы способы анализа требований и выявлены пользовательские и функциональные требования, а также создана матрица отслеживания требований. Еще в этой таблице был выявлен приоритет с помощью метода «MuSCoW». После этого был составлен план создания программного обеспечения, согласно методологии SCRUM. Всего получилось 4 спринта. 

Разработка приложения производилась в среде создания и обработки баз данных MS Access. Эта программа является простой и понятной в обращении; имеет возможность внесение данных из программы Microsoft Excel, в которой ранее велась часть баз данных; является полностью совместимой с системой Windows и обладает огромными возможностями по импорту и экспорту данных. По итогу были в MS Access были реализованы требования, выявлены недочеты и исправлены ошибки.

Список литературы

1. Джефф Сазерленд. Scrum. Революционный метод управления проектами Scrum. The art of doing twice the work in half the time. – Манн, Иванов и Фербер, 2016. – 288 с. 
2. Орел А.А., Ромакина О.М. Учебное пособие по курсу «Проектирование бизнес – процессов» для студентов механико-математического факультета, 2007. – 123 с.
3. А.В. Варзунов, Е.К. Торосян, Л.П. Сажнева. Анализ и управление бизнес-процессами .Учебное пособие, 2010 – 212 с.
4. Скоромец А.А., Скоромец А.П., Скоромец Т.А., Неврологический статус и его интерпретация.  Оформление, оригинал-макет. Издательство «МЕДпресс-информ», 2009. – 439 с.
5. Г.Н. Жданов. Схема истории болезни неврологического больного, 2008. – 128 с.
6. Лайза Криспин, Джанет Грегори. Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд Agile Testing: A Practical Guide for Testers and Agile Teams. –  М.: «Вильямс», 2010. –  464 с.
7. Назаренко Г. И., Гулиев Я. И., Ермаков Д. Е. Медицинские информационные системы: теория и практика. – М.: Физматлит, 2005. – 320 с.
8. Шеер А.В. Моделирование бизнес-процессов. – М.: Весть-МетаТехнология, 2000. – 224 c.
9. Буч Г, Рамбо Дж. Введение в UML от создателей языка. – 2015. – 493 c.
10. Карл И. Вигерс. Разработка требований к программному обеспечению. –  М.: Русская редакция, 2005. – 576 c.
11. Соммервилл И. Инженерия программного обеспечения. 2005. –   624 с.
12. Вендеров А.М. CASE технологии. Современные методы и средства проектирования информационных систем М.: Финансы и статистика, 2005. – 352 c.
13. Ульман, Дж. Основы систем баз данных / Дж. Ульман. – М.: Финансы и статистика, 2017. — 292 c.
14.  Дейт К.Дж. Введение в системы баз данных / пер. с англ. и ред. Птицына К.А. – М.: Вильямс – 2016. – 1327 с.
15. Королюк И.П. Медицинская информатика – Самара: Офорт, 2012. – 244 с.
16. Степанов Д.Ю. Анализ, проектирование и разработка корпоративных информационных систем: уровень приложений / МИРЭА. — М., 2017.
17. Епанешников А.М., Епанешников В.А. Практика создания приложений в Access. – 2009. – 440 с.
18. Бекаревич Ю., Пушкина Н. Самоучитель MS Office Access 2016. – 464 с.
19. Варзунов А. В., Торосян Е. К., Сажнева Л. П., Анализ и управление бизнес- процессами // Учебное пособие. – СПб: Университет ИТМО, 2016. – 112 с.
20. Федоров И.Г. Системный подход к выявлению бизнес-процессов методом «сверху вниз» // Прикладная информатика. — 2012. №5 (41), – C.5-13.
21. Криницкий, Н.А. Автоматизированные информационные системы / Н.А. Криницкий, Г.А. Миронов, Г.Д. Фролов. – М.: Наука, 2016. – 382 c.
22. Хаббард, Дж. Автоматизированное проектирование баз данных / Дж. Хаббард. – М.: Мир, 2014. – 296 c.
23. Малюк А.А. Введение в защиту информации в автоматизированных системах. Учебное пособие – М.: Горячая линия – Телеком, 2012. — 148 c.
24. Ларман Крэг. Применение UML и шаблонов проектирования. – М.: Вильямс, 2015. – 624 c.
25. Мюллер, Р.Дж. Базы данных и UML. Проектирование / Р.Дж. Мюллер. – М.: ЛОРИ, 2017. – 420 c.
26. Базы данных (MS Access, MySQL) / А.А. Аббакумов, В.Л. Акимов, А.И. Егунова, К.А. Лещанкин, В.М. Таланов. – Саранск: СВМО. – 2011. – 112 с.
27. Кузин, А.В. Базы данных: учеб. пособие для студ. высш. учеб. заведений / А.В. Кузин, С.В. Левонисова. – 2-е изд., стер. – М.: Академия. – 2008. – 320 с.
28. Гурвиц Г.А. Microsoft Access 2010. Разработка приложений на реальном примере. – СПб.: БХВ-Петербург, 2010. – 497 с.
29. Интернет-портал по MS Access (https://accesshelp.ru/).
30. Интернет-портал  по неврологии (http://www.neuroplus.ru/).

Выходные данные

Деревнина А.М. Разработка автоматизированного рабочего места врача-невролога с использованием метода Agile Scrum / МИРЭА. — М., 2018. — 44 с. – URL: http://stepanovd.com/training/20-vkr/66-vkrb-2018-3-derevnina.

Автоматизированное
рабочее место (АРМ) врача

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

По
назначению АРМ, используемые в ЛПУ
(лечебно-профилактических учреждений),
можно разделить на:

АРМ
работника регистратуры поликлиники;

АРМ
врача амбулаторного приема;

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

АРМ
врача стационара;

АРМ
узких специалистов (эндоскопист, уролог
и т. д.);

АРМ
врача диагностической лаборатории;

АРМ
врача-рентгенолога;

АРМ
аптечной службы;

АРМ
врача-эпидемиолога службы иммунопрофилактики;

АРМ
врача клинико-экспертной комиссии ЛПУ;

АРМ
работника административно-хозяйственной
службы.

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

АРМ
применяются не только на базовом уровне
здравоохранения – клиническом, но и
для автоматизации рабочих мест на уровне
управления ЛПУ.

АРМ
врача может функционировать как в
автономном режиме, так и входить в состав
информационных систем ЛПУ.

Кратко
рассмотрим отдельные автоматизированные
рабочие места:

АРМ
«Регистратура поликлиники»
Предназначено для регистрации пациентов
и ведения компьютерных историй болезни.

Позволяет
осуществлять:

ввод
паспортных данных пациента;

организовывать
выдачу талонов на прием к специалистам;

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

АРМ
«Средний медицинский персонал»
Система предназначена для информационного
обеспечения и оптимизации деятельности
среднего медицинского персонала.

Позволяет
осуществлять:

информирование
о назначениях и процедурах пациента;

учет
лекарственных средств;

контроль
заполнения койко-мест;

составление
графика работы персонала.

АРМ
«Главный врач» Система предназначена
для главных врачей. Позволяет планировать
лечебно-диагностические мероприятия,
автоматизировать отчетную деятельность.

Функциональные
возможности системы:

контроль
лечебного процесса и действий персонала;

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

АРМ
«Врач» Возможности системы:

ведение
электронной истории болезни пациента;

мониторинг
за больным в динамике;

учет
затрат на лечение;

составление
отчетной документации;

доступ
к справочной информации: препараты,
диагностические процедуры, заболевания
(с МК.Б).

АРМ
«Информационно-диагностическая
система» Система предназначена для
оснащения диагностических кабинетов
и лабораторий.

Функциональные
возможности системы:

ввод,
количественный и качественный анализ
изображений;

создание
архивов изображений с привязкой к
истории болезни, справочных атласов;

составление
текстовых комментариев и заключений.

Соседние файлы в папке Инфа

• #
• #
• #
• #
• #
• #

Некоторые тезисы из работы по теме Автоматизированное рабочее место лечещего врача в больничном стационаре + ТЗ
Введение

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

В данной работе будут рассмотрены основные вопросы автоматизации рабочего места лечащего врача в больничным стационаре на примере городской больницы № 12.

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

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

 провести анализ деятельности предприятия;

 выбрать задачи автоматизации из всего комплекса, существующих бизнес процессов;

 проанализировать существующие программные продукты с аналогичным функционалом;

 осуществить выбор системы управления базами данных и среды программирования приложения пользователя;

 проанализировать требования, предъявляемые к программному продукту, и выделить накладываемые ограничения;

 спроектировать базу данных;

 реализовать базу данных в выбранной системе управления базами данных;

 спроектировать приложения пользователя;

 реализовать приложение пользователя средствами среды программирования.

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

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

В третьей главе рассматривается непосредственное проектирование и разработка информационной системы. Также в данной главе выбор системы управления базами данных. Для хранения данных была выбрана система управлениями базами данных Microsoft Access 2003. Была выбрана именно данная СУБД, поскольку на сегодняшний день она уже приобретена на предприятии.

Для реализации приложения пользователя был выбран объектно-ориентированный язык программирования Borland Builder C++ версии 6.0. Данный язык программирования отличает высокая функциональность в плане работы с базами данных, а также позволяет реализовать работу приложения с операционной системой, что заметно повышает его функциональность.

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

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

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

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

Опытным C++ программистам понравится синтаксис и структура кода разрабатываемых на C++Builder программ, хотя его графическое обрамление заметно отличается от традиционных оболочек систем разработки. Благодаря графическим средствам интегрированной среды C++Builder, новички смогут быстрее освоить стиль объектно-ориентированного программирования на C++, чем при использовании традиционного программно-текстового интерфейса других систем.

Заключение

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

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

Для решения поставленной задачи были выполнены следующие задачи:

 анализ предметной области;

 анализ деятельности предприятия;

 анализ потоков информации на предприятии;

 расчет экономической эффективности программного продукта;

 проектирование базы данных;

 физическая реализация базы данных;

 разработка приложения пользователя;

 физическая реализация приложения пользователя.

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

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

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

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

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

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

Программный продукт был реализован с помощью СУБД Microsoft Access 2003, а также языка объектно-ориентированного программирования Borland Builder C++ 6.0. Оформление отчета осуществлялось с помощью интегрированного пакета Microsoft Office 2003.

При эксплуатации наличие языка программирования требуется, а Microsoft Access поставляется вместе с интегрированным пакетом офисных приложений Microsoft Office, что позволяет не сильно увеличивать затраты на приобретение специального программного обеспечения.

Список литературы

1. Баронов В.В., Калянов Г.Н., Попов Ю.И., Титовский И.Н. Информационные технологии и управление предприятием.- М.: БизнесПРО, 2004.

2. Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. – М.: Финансы и статистика, 2004.

3. Бондарева Г.А., Сахарова Е.В., Королькова Л.Н., Информатика. Ставрополь, СТИС, 2006

4. Вендров А. М. Проектирование программного обеспечения экономических информационных систем: Учебник. — 2-е изд., перераб. и доп. — М.: Финансы и статистика, 2005. — 544 с.

5. Гончаров А. Ю. Access 2003. Самоучитель с примерами. – М.: Инфра-М, 2004 – 385 с.

6. Горев А. Эффективная работа с СУБД. — СПб.: Питер, 1997. – 704с.: ил.

7. Каймин В.А. Информатика: Учебник. — 5-ое издание — М.: ИНФРА-М, 2007 – 244 с.

8. Карпова Т. С. Базы данных: модели, разработка, реализация: учеб. пособие для вузов — СПб.: Питер, 2001. –304с.: ил.

9. Козырев А.А. Информационные технологии в экономике и управлении. – СПб.: Изд-во Михайлова В.А., 2003

10. Лугачев М. И. и др. Экономическая информатика: введение в экономический анализ. — М.: Инфра-М, 2005. —569 с.

11. Маклаков С. В. ВРWin и ERWin. САSЕ-средства разработки информационных систем — М.: Диалог-МИФИ, 1999 — 455 с.: ил.

12. Мишенин А. И. Теория экономических информационных систем. — М.: Финансы и статистика, 2000. — 240 с.

13. Норенков И. П. Основы автоматизированного проектирования: Учебник для вузов. — М.: МГТУ им. Н. Э. Баумана, 2002. — 336 с.

14. Орлов С. Технологии разработки программного обеспечения. Учебное пособие. 2-е изд. — СПб.: Питер, 2003. — 480 с.

15. Петров, В. Н. Информационные системы: учеб. пособие для вузов — СПб.: Питер, 2002. – 688 с.

16. Савицкий Н. И. Экономическая информатика. — М.: Экономистъ, 2004. — 429 с.

17. Смирнова Г. Н. и др. Проектирование экономических информационных систем: Учебник / Под ред. Ю. Ф. Тельнова. — М.: Финансы и статистика, 2002. — 512 с.

18. Уткин В.Б., Балдин К.В. Информационные системы и технологии в экономике. – М.: ЮНИТИ, 2003

19. Холингворт Д., Сворт Б., Кэшмэн М., Густавсон П. Borland C++ Builder 6. Руководство разработчика. — М.: «Вильямс», 2004. — С. 976. — ISBN 0-672-32480-6

20. Холингворт Д., Сворт Б., Кэшмэн М., Густавсон П. C++ Builder 5. Руководство разработчика — М.: «Диалектика», 2001. — С. 884. — ISBN 0-672-31972-1

21. Хотинская Г.И. Информационные технологии управления. – М.: Дело и Сервис (ДИС), 2003.

Дипломная работа Автоматизированное рабочее место врача-терапевта поликлиники (пояснительная записка, программный продукт в 1С: Предприятие 8.2, презентация MS Power Point, защитная речь)

СОДЕРЖАНИЕ

Введение 6

1 Проблемы и тенденции развития информационных систем в здравоохранении 8

1.1 Экономическая сущность здравоохранения 8

1.2 Обоснование необходимости и цели использования информационных систем в здравоохранении 11

1.3 Анализ существующих разработок и обоснование выбора технологии проектирования 13

1.4 Проблемы развития информационных систем в здравоохранении 16

1.5 Тенденции развития информационных систем в здравоохранении 17

2 Характеристика и специфические особенности текущего состояния информационной системы 20

2.1 Технико-экономическая характеристика предметной области 20

2.1.1 Характеристика предприятия 20

2.1.2 Краткая характеристика деятельности врача-терапевта 22

2.2 Анализ текущего состояния информационной системы 24

2.2.1 Информационная модель и ее описание 24

2.2.2 SWOT-анализ 26

2.3 Мероприятия и рекомендации по совершенствованию организации информационного обмена 27

2.4 Постановка задачи 29

2.4.1 Цель и назначение проекта 29

2.4.2 Общая характеристика организации решения проекта 30

2.5 Обоснование проектных решений по видам обеспечения 32

2.5.1 Обоснование выбора программного обеспечения 32

2.5.2 Обоснование выбора технического обеспечения 33

3 Проектирование автоматизированного рабочего места врача-терапевта 34

3.1 Информационное обеспечение комплекса задач 34

3.1.1 Используемые классификаторы и системы кодирования 34

3.1.2 Характеристика нормативно-справочной и входной оперативной информации 35

3.1.3 Характеристика результатной информации 44

3.2 Программное обеспечение комплекса задач 46

3.2.1 Общие положения 46

3.2.2 Описание программных модулей 48

4 Оценка экономической эффективности автоматизированного рабочего

места 61

4.1 Оценка затрат на разработку программного продукта 61

4.1.1 Оценка новизны и сложности разработки 62

4.1.2 Оценка фактической трудоемкости разработки программного продукта 63

4.2 Затраты на создание прогр

1. 1С: Предприятие [Электронный ресурс] – Режим доступа: http://1c.ru/ (Дата обращения 10.10.13).

2. Алексеева В. М. Экономика здравоохранения / В. М. Алексеева, Е. Б. Галкин, С. А. Ефименко. – М.: ГЭОТАР-Медиа, 2010. – 272 с.

3. Балдин К.В. Информационные системы в экономике: Учебник / К.В. Балдин, В.Б. Уткин. – М.: Издательско-торговая корпорация «Дашков и Ко», 2008. – 218 с.

4. Гвоздева Т.В. Проектирование информационных систем / Т.В.Гвоздева. – М.: Феникс, 2009. – 688 с.

5. Гельман В.Я. Медицинская информатика / В.Я.Гельман. – СПб.: Питер, 2011. – 212 с.

6. Грекул В.И. Проектирование информационных систем / В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкина. – М.: Интернет-университет информационных технологий – ИНТУИТ.ру, 2008. – 304с.

7. Дуданов И. П. Информационная система в организации работы учреждений здравоохранения / И.П. Дуданов, Ф.А. Романов, А.В. Гусев. – Петрозаводск: Изд-во ПетрГУ, 2008. – 128 с.

8. Душин В.К. Теоретические основы информационных процессов и систем: Учебник / В.К. Душин. – М.: Издательско-торговая корпорация «Дашков и Ко», 2009. – 504 с.

9. Жихарев А.П. Автоматизированные информационные системы и ресурсы / А.П. Жихарев – Москва, Юнити-Дана, Закон и право, 2009. – 256 с.

10. Жмуров В.А. Большая энциклопедия по психиатрии / Жмуров В.А. – М.:Джангар, 2012. – 688 с.

11. Зекий О.Е. Автоматизация здравоохранения. / О.Е. Зекий – М.: Новости, 2008. – 400 с.

12. Избачков Ю.С. Информационные системы / Ю.С. Избачков, В.Н. Петров. – СПб.: Питер, 2008. – 656 с.

13. Исаев Г.В. Проектирование информационных систем. Учебное пособие / Г.В.Исаев. – М.:Омега-Л, 2013. – 464 с.

14. Козырев А.А. Информационные технологии в экономике и управлении. Учебник. 2-е издание. / А.А.Козырев. – СПб.: Издательство Михайлова В.А., 2009. – 360 с.

15. Колесов Ю.Б. Моделирование систем. Объектно-ориентированный подход. Учебное пособие / Ю.Б. Колесов, Ю.Б. Сениченков. – СПБ.: БХВ-Петербург, 2008. – 192 с.

16. Комплексные мед

Выполняется задача автоматизированного формирования графиков и табелей рабочего времени.Данные для заполнения справочников взяты из учебника для врачей-токсикологов [1] .В 70-х годах XX века развитие МИС разделилось на два основных направления.Это послужило стимулом для появления такого направления как анализ исходов лечения.Создание диагностических систем, помогающих врачу решать сложные диагностические задачи.Применяется для учета кадров, планирования и учета рабочего времени, расчета заработной платы.АРМ регистратора ПО, врача ПО, заведующего ПО, медицинской сестры ПО, старшей медицинской сестры ПО.Назначение лечащего врача.АРМ врача отделения терапевтического профиля.АРМ врача хирургического профиля.

Скачать Автоматизированное рабочее место врача-реаниматолога по направлению токсикология

Скачать документ

(Если ссылка на скачивание файла не доступна — дайте нам знать об этом в комментариях либо через форму обратной связи)