Файл: Составление перечня задач, подлежащих автоматизации.doc

Рисунок 3.1 – Форма для входа в программу

После проверки имени пользователя и пароля происходит вход пользователя в систему. В зависимости от типа загружаемого модуля на экране появляется соответствующая главная форма приложения.

1. 
   Результаты реализации подсистемы администрирования
   

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


Рисунок 3.2 – Форма модуля «Администратор»

2. 
   Результаты реализации подсистемы работы с расписанием
   

Подсистема работы с расписанием реализована в модуле «Расписание». Форма данного модуля изображена на рисунке 3.3.



Рисунок 3.3 – Форма модуля «Расписание»

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

В режиме формирования схем приема пользователь может создавать различные схемы приема врачей (шаблоны).

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

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

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

3. 
   Результаты реализации подсистемы регистрации пациентов
   

Подсистема регистрации пациентов реализована модуле «Регистратура». Форма данного модуля изображена на рисунке 3.4

---

Рисунок 3.4 – Форма модуля «Регистратура»

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

4. 
   Результаты реализации подсистемы работы с электронной амбулаторной картой
   

Элементы подсистемы работы с электронной амбулаторной картой расположены на главной форме АРМ врача поликлиники. Она изображена на рисунке 3.5.


Рисунок 3.5 – работа с электронной амбулаторной картой пациента

Работа с электронной лабораторной картой распределена на нескольких закладках главной формы АРМ врача поликлиники, а именно:

– «Карточка» – позволяет просматривать всю амбулаторную карту пациента, начиная с момента его регистрации в базе данных;

– «Методы» – позволяет врачу сделать новую запись в электронную карту по текущему осмотру;

– «Клинический диагноз» – позволяет врачу выставить клинический диагноз пациенту;

– «Назначения» – позволяет врачу записать назначения и рекомендации по обследованию;

– «МКБ10» и «Диагнозы» – позволяют врачу выставлять диагноз по международному классификатору болезней (МКБ-10) и описывать его свойства;

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

5. 
   Результаты реализации подсистемы выписки рецептов
   

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

---

Рисунок 3.6 – форма подсистемы выписки рецептов

6. 
   Результаты реализации подсистемы регистрации лабораторных анализов
   

Данная подсистема реализована в модуле «Лаборатория». Форма регистрации лабораторных анализов изображена на рисунке 3.7.



Рисунок 3.7 – форма подсистемы регистрации лабораторных анализов

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

3. 
   Тестирование программного обеспечения
   

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

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

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

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

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

---

Продолжение таблицы 2.25

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

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

4. 
   ЭКОНОМИЧЕСКАЯ ЧАСТЬ
   
   1. 
      Обоснование необходимости выведения на рынок
      

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

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

---

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

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

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

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

2. 
   Этапы работ по созданию программного обеспечения
   

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

Стадия разработки программного средства может быть разделена на следующие этапы:

• 
  оценка и анализ требований, предъявляемых к программному средству;
  
• 
  проектирование;
  
• 
  реализация;
  
• 
  тестирование и отладка.
  

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

---