Размещено на http://www.allbest.ru/

ВВЕДЕНИЕ

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

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

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

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

Во втором разделе пояснительной записки рассмотрены вопросы реализации информационной системы «Medic». При разработке базы данных этой информационной системы использовалось PostgreSQL, а сама информационная система была реализована в Perl с использованием HTML-шаблонов.

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

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

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

Библиографический список содержит перечень из 22 источников информации.

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

1. РЕЗУЛЬТАТЫ ПРЕДПРОЕКТНОГО ОБСЛЕДОВАНИЯ МЕДИЦИНСКОГО ЦЕНТРА СЕВЕРО-КАВКАЗСКОГО ГОСУДАРСТВЕННОГО ТЕХНИЧЕСКОГО УНИВЕРСИТЕТА. ФОРМУЛИРОВКА ЗАДАЧ ПРОЕКТИРОВАНИЯ

1.1 Результаты предпроектного обследования

1.1.1 Объекты и методы проведения предпроектного обследования

В рамках темы дипломного проекта объектами обследования являются:

- медицинский центр Северо-Кавказского государственного технического университета (СевКавГТУ);

- функциональная структура медицинского центра;

- состав процессов, протекающих в медицинском центре;

- процедуры, входящие в состав процессов.

Выбранные методы проведения обследования медицинского центра СевКавГТУ приведены в таблице 1.1.

Таблица 1.1 - Методы организации проведения обследования

Критерии классификации методов организации проведения обследования	Выбранный метод
По цели проектирования	Локальное обследование
По числу исполнителей	Индивидуальное обследование
По степени охвата объекта	Сплошное обследование
По отношению к этапам	Последовательное обследование

Характеристика методов сбора информации, использованной в ходе прохождения преддипломной практики в медицинском центре СевКаГТУ, представлена в таблице 1.2.

Таблица 1.2 - Характеристика методов сбора материалов обследования

Название методов сбора материалов обследования	Характеристика методов
Силами исполнителей	Метод анализа операций
По числу исполнителей	Личное наблюдение
По степени охвата объекта	Беседы и консультации с директором, кредитными инспекторами
По отношению к этапам	Опрос должностных лиц на рабочих местах

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

1.1.2 Программа проведения обследования

Программа обследования медицинского центра СевКавГТУ представлена в таблице 1.3.

Таблица 1.3 - Программа обследования предприятия

Наименование вопроса	Источник информации	Получатель информации
1	2	3
Общие сведения о предприятии	Главный врач	Проектировщик Прохоров К. Д.
Организационная структура	Аналогично	Аналогично
Цели функционирования	Аналогично	Аналогично
Функционирование области деятельности	Заведующая регистратурой	Аналогично
Документооборот	Аналогично	Аналогично
Формы документов	Аналогично	Аналогично
Порядок создания и хранения документов	Аналогично	Аналогично
Наличие средств вычислительной техники и программного обеспечения	Аналогично	Аналогично
Характеристики существующей информационной системы	Аналогично	Аналогично
Технологии, методы и технические средства преобразования информации	Аналогично	Аналогично
Проблемные ситуации в работе информационной системы	Аналогично	Аналогично

План-график выполнения работ на стадии сбора материалов обследования представлен в таблице 1.4. Он разделен на девять этапов. Работы проводились в срок прохождения преддипломной практики. Дата начала обследования - 10.01.11 г., дата завершения обследования - 20.03.11 г.

Таблица 1.4 - План-график выполнения работ на стадии сбора материалов обследования медицинского центра

Наименование вопроса	Код работы	Исполнитель	Дата начала	Кол-во дней	Дата окончания
1	2	3	4	5	6
Общие сведения о предприятии	001	Проектировщик Прохоров К. Д.	10.01.11	3	12.01.11
Организационная структура	002	Аналогично	13.01.11	6	18.01.11
Цели функционирования	003	Аналогично	19.01.11	3	21.01.11
Функциональные области деятельности	004	Аналогично	22.01.11	5	26.01.11
Документооборот	005	Аналогично	27.01.11	5	31.01.11
Формы документов	006	Аналогично	01.02.11	5	05.02.11
Порядок создания и хранения документов	007	Аналогично	06.02.11	9	14.02.11
Наличие средств вычислительной техники и ПО	008	Аналогично	15.02.11	5	19.02.11
Характеристики существующей информационной системы	009	Аналогично	20.02.11	5	24.02.11
Технологии, методы и технические средства преобразования информации	010	Аналогично	25.02.11	4	28.02.11
Проблемные ситуации в работе информационной системы	011	Аналогично	1.02.11	5	06.03.11
Всего затрачено дней	55

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

1.1.3 Результаты предпроектного обследования и их анализ

Общая характеристика. В 1971 году по приказу Совета Министров СССР в Ставрополе на базе филиала Краснодарского политехнического института образован Ставропольский политехнический институт, в состав которого вошли также Невинномысский и Черкесский УПК.

В начале 1992 года разработана программа перехода института в ранг технического университета, а в 1994 году приказом Комитета Российской Федерации по высшему образованию №524 от 26.05.94 Ставропольский политехнический институт преобразован в Ставропольский технический университет. Ввиду того, что Ставропольский технический университет являлся одним из ведущих вузов региона, единственным по своему профилю на Северном Кавказе, приказом Министерства высшего и профессионального образования Российской Федерации от 29.04.99 № 1180 он переименован в Северо-Кавказский государственный технический университет.

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

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

Место нахождения СевКавГТУ: Россия, Ставропольский край, г. Ставрополь, проспект Кулакова, дом 2. Почтовый адрес: Россия, 355029, г. Ставрополь, проспект Кулакова, дом 2.

Медицинский центр является подразделением СевКавГТУ и проводит прием студентов, преподавателей и сотрудников, нуждающихся в квалифицированной медицинской помощи, а так же проводит регулярные медицинские комиссии и вакцинации.

1.1.3.2 Организационная структура. Под организационной структурой управления понимается состав, взаимосвязь и соподчиненность совокупности организационных единиц, выполняющих различные функции по управлению организацией. Такая структура формируется исходя из состава, содержания и трудоемкости выполнения общих и специальных функций управления [15]. Организационно-управленческая структура СевКавГТУ имеет пирамидальное строение.

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

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

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

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

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

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

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

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



Рисунок 1.1 - Схема организационной структуры управления медицинского центра СевКавГТУ

Функциональные области деятельности. Функциональная структура предприятия. Управление в любой организации - это процесс взаимодействия между управляющей, управляемой системами (субъектом и объектом управления) и внешней средой. Управляющая система представляет собой совокупность тех органов и лиц, которые осуществляют целенаправленное воздействие с учетом информации о состоянии объекта управления и внешней среды. Управляемая система является тем объектом, на который направлены определенные управленческие воздействия с целью улучшения функционирования управляемого объекта, придания ему конкретных форм развития в интересах достижения намеченного результата [5].

Конкретная функциональная структура управления определяется в зависимости от сочетания двух основных типов руководства - линейного (генеральный директор, совет директоров) и функционального (специализация руководителей по отдельным функциям управления) [6].

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

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

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

Функциональные задачи и подзадачи предприятия представлены в виде таблицы (таблица 1.5).

Таблица 1.5 - Функциональные задачи и подзадачи СевКавГТУ

Номер и название функциональной области	Номер и содержание функциональной задачи
1. Управление планированием	1.1 Прогнозирование спроса на выпускаемых специалистов
	1.2 Внесение изменений в сроки, периоды обучения, графики проведения экзаменов и зачетов
	1.3 Составление требований к подготовке специалистов
2. Управление учебным процессом	2.1 Составление расписания занятий
	2.2 Качественный подбор професорско-преподавательского состава
3. Управление здравоохранением	3.1 Контроль за здоровьем сотрудников и студентов
	3.2 Оказание необходимой медицинской помощи сотрудникам и студентам
4. Управление обеспечением	4.1 Управление кадрами
	4.2 Управление материальными средствами
	4.3 Делопроизводство
5. Управление научной деятельностью	5.1 Организация и планирование научно-исследовательских работ по инновационной деятельности и проведения фундаментальных и поисковых исследований
	5.2 Организация семинаров, конференций
	5.3 Создание благоприятных условий при подготовке специалистов

Организационно-управленческая модель.

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

Х - полное участие в процессе;

/ - частичное участие в процессе;

0 - ответственность за выполнение процесса.

Таблица 1.6 - Организационно-управленческая модель СевКавГТУ

Структурные подразделения

Номера и наименование задач

1. Управление планированием

2. Управление учебным процессом

3. Управление здравоохранением

4. Управле-ние обеспечением

5. Управление научной деятельностью

1.1

1.2

1.3

2.1

2.2

3.1

3.2

4.1

4.2

4.3

5.1

5.2

5.3

УМУ

?,/

?,/

?,/

Деканаты

/

/

?,/

Кафедры

/

/

?,/

ИУП

/

?,/

Лаборатории

?,/

НТЦ

?,/

Бухгалтерия

?,/

Отдел кадров

?,/

ОЭОКК

/

/

Медицинский центр

0,?

0,?

/

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

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

График документооборота - это график или схема, которые описывают движение первичных документов на предприятии от момента их создания до момента передачи на хранение [10].

Унифицированной формы графика документооборота нет. Каждое предприятие составляет график самостоятельно, исходя из особенностей деятельности[11].

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

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

Схема движения документов в медицинском центре отражена в таблице 1.7.

Таблица 1.7 - Схема документооборота медицинского центра СевКавГТУ

Документ	Деканат	Студент или сотрудник	Регистратура	Врач	Главный врач	Проректор по экономике	Проректор по науке информатизации и инновационной деятельности	Начальник ОЭОКК
Медицинская карта
Справка о прохождении флюорографии
Отчет о проделанной работе врача
Заявление на перемещение техники
Заявление на приобретение техники

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

1. Системный блок Intel Celeron D 2.66ГГц /512Мбайт /80Гбайт /HDD /CDRW /Video /Sound /Lan /ATX 250 Вт.

2. Системный блок Intel Pentium 4 2.4 ГГц /512 Мбайт /320 Гбайт /DVD+CDRW /Video /Sound /Lan /ATX 400 Вт.

3. Маршрутизатор D-Link.

4. Принтер HP Laser Jet 1300.

5. Принтер HP Laser Jet 1200.

6. Копир Canon FC 228.

Так же имеется сеть топологии звезда, показанная на рисунке 1.2. Где связующим звеном является маршрутизатор D-Link, к которому подключены все компьютеры подразделения. Это дает возможность реализовать программный продукт в клиент-серверной технологии, что избавит от ряда проблем, крупнейшими из которых является разрозненность и актуальность данных.



Рисунок 1.2 - Схема локальной вычислительной сети медицинского центра СевКавГТУ

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

- операционная система - Windows XP;

- офисный пакет приложений, в стандартной комплектации - Microsoft Office 2003;

? архиватор WinRARv3.62;

- антивирусные средства NOD32.

1.1.4 Анализ проблемных ситуаций и обоснование путей их решения

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

Таблица 1.8 - Проблемные ситуации и способы их разрешения

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

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

1.2 Формулировка задач проектирования

1.2.1 Общие сведения

Полное наименование проекта - «Система управления данными медицинского центра».

Код системы - «Medic».

Наименование организации-разработчика - Северо-Кавказский государственный технический университет, факультет ИТТ, кафедра прикладной информатики, студент группы ПИ-061 Прохоров Константин Дмитриевич

Наименование организации-заказчика - медицинский центр Северо-Кавказского государственного технического университета.

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

Источники финансирования - работы проводятся без оплаты.

1.2.2 Назначение и цели создания информационной системы

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

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

- время на доступ к требуемой информации уменьшается до минимума;

- снижается вероятность ошибки при вводе информации и формировании отчетности;

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

1.2.3 Характеристика объекта автоматизации

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

- прием студентов или сотрудников;

- уточнение данных медицинских карт;

- прием справок о прохождении флюорографии;

- составление отчетности.

1.2.4 Требования к системе

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

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

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

1.2.5 Состав и содержание работ по созданию системы

Предусмотрен следующий состав и содержание работ по созданию информационной системы:

– изучение предметной области и составление технического задания с 10 января по 8 февраля 2011 г.;

– кодирование с 8 по 20 февраля 2011 г.;

– отладка и тестирование с 20 по 28 февраля 2011 г.;

– подготовка технической документации с 28 февраля по 4 марта 2011 г.;

– сдача проекта заказчику с 4 по 6 марта 2011 г.

1.2.6 Порядок контроля приемки системы

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

1.2.7 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

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

1. Установить следующее программное обеспечение на сервер:

- PostgreSQL версии 8.4.2 или выше;

- Apache не ниже 2.0;

- Perl версии 5.8.9 и модули Template, CGI, DBI, Spreadsheet::WriteExcel, utf8, Encode, POSIX, CGI::Session, DBI::PgPP.

2. Произвести обучение системного администратора.

3. Произвести обучение пользователей работе с разработанной системой.

1.2.8 Требование к документированию

Разработчик предоставляет файлы информационной системы «Medic» в электронном формате на CD-ROM вместе с результатами тестирования и краткими инструкциями для администратора и врачей.

1.2.9 Источники разработки

Источниками разработки являются:

заказ на разработку информационной системы;

материалы и отчеты по преддипломной практике;

медицинские карты студентов;

отчеты по флюорографии студентов;

прививочные журналы.

Выводы

1. Медицинский центр СевКавГТУ является подразделением Северо-Кавказского государственного технического университета и его основная задача оказание необходимой медицинской помощи студентам и сотрудникам университета.

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

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

2. РЕАЛИЗАЦИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ «MEDIC»

2.1 Обоснование выбора среды разработки

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

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

1. О разработке базы данных на основе PostgreSQL, что обусловлено ее современностью, бесплатностью и конкурентоспобностью, в сравнении с аналогичными продуктами. В PostgreSQL реализованы многие возможности, обычно присутствующие только в коммерческих СУБД, таких как DB2 и Oracle. Простота расширения - в PostgreSQL поддерживаются пользовательские операторы, функции, методы доступа и типы данных. Процедурные языки - предусмотрена поддержка внутренних процедурных языков, в том числе специализированного языка PL/pgSQL, являющегося аналогом PL/SQL, процедурного языка Oracle. Одним из преимуществ PostgreSQL является возможность использования Perl, Python и TCL в качестве внутренних процедурных языков.

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

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

2.2 Реализация информационной системы «Medic»

2.2.1 Концептуальное проектирование системы «Medic»

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

В ходе концептуального проектирования было решено создать 29 страниц, описанных в таблице 2.1.

Таблица 2.1 - Страницы и их описание

Страница	Назначение
1	2
Start page	Страница приветствия, которая появляется при самом первом входе пользователя в систему, дальше он ее не видит, так как после выхода пользователя, запоминается последняя посещенная страница, с которой он и начинает
Права пользователей	Является страницей-подменю, где пользователь может выбрать, с чем ему работать: группа, принадлежность пользователей и пользователи
Группы	На этой странице предлагается работа с группами: создание, удаление и редактирование группы
Принадлежность пользователей	На этой странице предлагается работа с группами прав пользователей, что значительно ускоряет процесс назначения прав, так как достаточно выбрать пользователя и отметить группы к которым он должен относиться, после чего система автоматически даст необходимые права, которые соответствуют этой группе, при этом пользователь может относиться к нескольким группам
1	2
Пользователи	Предлагается работать именно с пользователем: создание нового пользователя, редактирование личных данных или редактирование прав заданного пользователя
Окна и функции	Является страницей-подменю, где пользователь может выбрать с чем ему работать: окна или функции
Окна	Предлагает работать с окнами: создать новое окно (страницу), отредактировать название или имя файла уже существующей страницы и удалить не нужную страницы
Функции	Предлагается работать с функциями, о которых уже было сказано выше, пользователь может создать новые функции если это требуется (например дальнейшая разработка системы), редактирование названия функции и удаление ее, в случае если она потеряет актуальность
Редактор населенных пунктов	Является страницей-подменю, где пользователь может выбрать, с чем ему работать: регион, район и город
Регион	Позволяет работать со списком регионов: создание, редактирование и удаление
Район	Позволяет работать со списком районов: создание, редактирование и удаление
Город	Позволяет работать со списком городов: создание, редактирование и удаление
Должности сотрудников	Позволяет работать со списком должностей сотрудников: создание, редактирование и удаление
Журнал прививок	Позволяет работать со списком прививок. Создание, редактирование и удаление
Тип диагноза	Позволяет работать со списком диагнозов: создание, редактирование и удаление
Журнал диагнозов	Позволяет работать со списком диагнозов: создание, редактирование и удаление
Контингент	Является страницей-подменю, где пользователь может выбрать, с чем ему работать: факультеты, группы или студенты
Факультеты	Позволяет работать со списком факультетов: создание, редактирование и удаление
Группы	Позволяет работать со списком групп: создание, редактирование и удаление
1	2
Студенты	Позволяет работать со списком студентов: создание, редактирование и удаление
Карты	Является страницей-подменю, где пользователь может выбрать, с чем ему работать: добавление карты и редактирование карты
Добавление карты	Позволяет создать карту для студента, процесс аналогичный заведению новой карты в бумажной форме
Редактирование карты	Позволяет видеть общую информацию о медицинской карте и редактировать ее в случае необходимости
Диагнозы	Является страницей-подменю, где пользователь может выбрать, с чем ему работать: история болезней и прием больного
История болезней	Отображает общую информацию о всех посещениях и в случае необходимости просмотр подробностей
Прием больного	Служит для внесения информации о посещении студентом врача
Флюорография	Отображает списки флюорографии, в которых указывается статус прохождения (пройдена или не пройдена), а так вносить дату последнего прохождения. Так же формирует отчеты по группе и факультету
Прививки	Отображает список сделанных прививок с полной информацией, а так же позволяет вносить запись о новой прививке
Справка	Отображает справку по системе, при нажатии на кнопку справки, отображается справка по окну из которого она была вызвана, но так же пользователь может перейти в содержание справки, где будет список всех доступных ему окон

Схема расположения станиц представлена на рисунке 2.1.

Рисунок 2.1 - Концептуальная схема расположения страниц системы «Medic»

Концептуальная схема позволяет наглядно показать расположение всех страниц системы «Medic».

2.2.2 Создание логической модели базы данных информационной системы

Определение сущностей модели. В процессе проектирования базы данных вся требуемая информация была разделена на 28 сущностей (таблиц):

- area (далее как район) - содержит в себе список район, из которых прибыли студенты на обучение в университете;

- card (далее как карта) - содержит в себе информацию о медицинской карте;

- comments (далее как комментарии) - комментарии к диагнозу;

- diagnosis (далее как диагнозы) - история диагнозов студента ;

- employees (далее как информация_сотруднике) - информация о сотрудниках;

- faculty (далее как факультет) - список факультетов;

- fluorography (далее как флюорография) - история прохождения флюорографии студентом ;

- func (далее как функции) - список функций работы с системой;

- group_fac (далее как группа_факультета) - список групп в факультете;

- grp (далее как группа) - список групп для работы с правами доступа к системе;

- grp_func (далее как группа_функция) - служит для реализации связи М:М между таблицами группа и функция;

- history_connections (далее как история_соединений) - история всех соединений к базе данных, служит для мониторинга;

- history_session (далее как история_сессий) - история всех сессий, служит для мониторинга всех посещений сотрудника;

- jornal_diagnosis (далее как журнал_диагнозов) - журнал диагнозов;

- jornal_vaccin (далее как журнал_прививок) - журнал прививок;

- post (далее как должность) - должность сотрудников;

- region (далее как регион) - список регионов;

- sesion (далее как сессия) - список последних сессий сотрудников;

- sot (далее как сотрудник) - список сотрудников;

- sot_func (далее как сотрудник_функции) - служит для реализации связи М:М между таблицами сотрудник и функции;

- sot_grp (далее как сотрудник_группа) - служит для реализации связи М:М между таблицами сотрудник и группа;

- students (далее как студенты) - список студентов;

- town (далее как город) - список городов;

- transaction_history (далее как история_транзакций) - история транзакций, служит для мониторинга действий пользователя по вносимым изменениям;

- treatment (далее как лечение) - назначенное лечение к диагнозу;

- type_diagnosis (далее как тип_диагноза) - список диагнозов;

- vaccine (далее как прививки) - история всех прививок студента;

- wnd (далее как окна) - список окон приложения для управления;

Инфологическое проектирование. Цель инфологического моделирования - обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в созданной БД. Поэтому инфологическую модель пытаются строить по аналогии с естественным языком. Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства [14]. Модель «сущность - связь» спроектированной базы данных приведена на рисунке 2.2.

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

Таблица 2.2 - Отношения между сущностями

Номер связи	Родительская сущность	Дочерняя сущность	Тип связи
1	2	3	4
1	Сотрудник	Функции	М:М
2	Группа	Функции	М:М
3	Окна	Функции	М:М
4	Окна	группа	М:М
5	Сотрудник	Группа	М:М
6	Сотрудник	Информация_сотруднике	1:М
7	Сотрудник	Должность	1:М
8	Сотрудник	Диагнозы	1:М
9	Сотрудник	Прививки	1:М
10	Сотрудник	Сессия	1:М
11	Факультет	Группа	1:М
12	Группа	Студент	1:М
13	Студент	Карта	1:М
14	Карта	Регион	1:М
15	Карта	Район	1:М
16	Карта	Город	1:М
17	Регион	Район	1:М
18	Район	Город	1:М
19	Карта	Флюорография	1:М
20	Карта	Диагнозы	1:М
21	Карта	Прививки	1:М
22	Диагнозы	Комментарий	1:М
23	диагнозы	лечение	1:М
24	диагнозы	журнал_диагнозов	1:М
25	диагнозы	тип_диагноза	1:М
26	прививки	журнал_прививок	1:М

Инфологическая модель представлена на рисунке 2.2



Рисунок 2.2 - Инфологическая модель БД

Как видно из рисунка 2.2 и таблицы 2.2 между таблицами связи 1, 2, 3, 4, 5 являются связями «многие ко многим», а все остальные «один ко многим».

Задание первичных ключей сущностей. Ключ - это минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Это одно из основных понятий баз данных, используемых при контроле целостности информации. Разделяют первичные и внешние ключи. Первичный ключ - это уникальное поле (или несколько полей), однозначно определяющее записи таблицы базы данных. Внешние ключи - это поля таблицы, которые, как правило, соответствуют первичным ключам из других таблиц. Первичный ключ не может принимать неопределённые значения [17].

Ниже, в таблице 2.3, приведены ключи для каждой сущности.

Таблица 2.3 - Ключи

Таблица	Ключ	Тип ключа
1	2	3
район	id_area	primary
	id_region	regular
карта	id_card	primary
	id_stud	regular
	id_region	regular
	id_area	regular
	id_town	regular
комментарии	id_comments	primary
	id_comments	regular
диагнозы	id_diag	primary
	id_card	regular
	id_sot	regular
	id_type_diag	regular
	id_comments	regular
диагнозы	id_treatment	regular
	id_jornal_diag	regular
информация_сотруднике	id_empl	primary
	id_sot	regular
факультет	id_fac	primary
флюорография	id_fluor	primary
	id_card	regular
функции	func_id	primary
группа_факультета	id_gr	primary
	id_fac	regular
группа	id	primary
группа_функция	id	primary
	func_id	regular
	wnd_id	regular
	grp_id	regular
история_соединений	id_connect	primary
история_сессий	id_ses	primary
журнал_диагнозов	id_jornal_diag	primary
журнал_прививок	id_jornal_vaccin	primary
должность	id_post	primary
	id_sot	regular
регион	id_region	primary
сессия	sesion	primary
	id_sot	regular
сотрудник	id_sot	primary
сотрудник_функции	id	primary
	sot_id	regular
	func_id	regular
	wnd_id	regular
сотрудник_группа	id_sg	primary
	grp_id	regular
	sot_id	regular
студенты	id_stud	primary
	id_gr	regular
город	id_town	primary
	id_area	regular
история_транзакций	id_tran	primary
лечение	id_treatment	primary
тип_диагноза	id_type_diag	primary
прививки	id_vaccin	primary
прививки	id_card	regular
	id_sot	regular
	id_jornal_vaccin	regular
окна	id_wnd	primary

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

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

Для даталогических моделей определена методология построения диаграмм, IDEF.

IDEF - методологии семейства ICAM (Integrated Computer-Aided Manufacturing) для решения задач моделирования сложных систем, позволяет отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. При этом широта и глубина обследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными[19].

На рисунке 2.3 показана даталогическая модель базы данных с использование методологии IDEF1X.

IDEF1X (IDEF1 Extended) - методология построения реляционных структур (баз данных), относится к типу методологий «Сущность-взаимосвязь» и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе[19].

Рисунок 2.3 - Даталогическая модель БД

Из рисунка 2.2 видны все реализованные сущности в таблицы и атрибуты сущностей в поля таблицы с заданными типами данных.

2.2.3 Реализация серверной части приложения

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

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

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

Разработанная система содержит в себе модули:

- index.cgi - выполняет все проверки и подключает необходимый модуль окна и шаблон этого окна;

- Templete.pm - отвечает за генерацию меню;

- ConnectDB.pm - отвечает за соединение с базой данных;

- exel.pm - модуль генерации отчетов по флюорографии и привочному журналу;

- exel_card.pm - модуль генерации титульного листа медицинской карты;

- kernel.pm - отвечает за проверку логина и пароля, получения сессии, получения номера последнего окна;

- ses.pm - отвечает за проверку номера сессии;

- и модули окон с шаблонами, отвечающие за поведение окон клиентской части описанных в таблице 2.4.

Таблица 2.4 - Файлы модулей и шаблоны окон

Страница	Файл шаблона	Файл модуля
1	2
Start page	page_0.tt	page_0.pm
Права пользователей	page_1.tt	page_1.pm
Группы	page_2.tt	page_2.pm
Принадлежность пользователей	page_3.tt	page_3.pm
Пользователи	page_3.tt	page_3.pm
Окна и функции	WndAndFunc.tt	WndAndFunc.pm
Окна	Wnds.tt	Wnds.pm
Функции	Func.tt	Func.pm
Редактор населенных пунктов	EditorATR.tt	EditorATR.pm
Регион	EditRegion.tt	EditRegion.pm
Район	EditArea.tt	EditArea.pm
Город	EditTown.tt	EditTown.pm
Должности сотрудников	Post_sot.tt	Post_sot.pm
Журнал прививок	Jornal_vaccin.tt	Jornal_vacc.pm in
Тип диагноза	Type_diag.tt	Type_diag.pm
Журнал диагнозов	Jornal_diag.tt	Jornal_diag.pm
Контингент	Contingent.tt	Contingent.pm
Факультеты	Faculty.tt	Faculty.pm
Группы	Groups.tt	Groups.pm
Студенты	Students.tt	Students.pm
Карты	Kard.tt	Kard.pm
Добавление карты	AddCard.tt	AddCard.pm
Редактирование карты	EditCard.tt	EditCard.pm
Диагнозы	Diagnosis.tt	Diagnosis.pm
История болезней	History_diagnosis.tt	History_diagnosis.pm
Прием больного	Add_diagnosis.tt	Add_diagnosis.pm
Флюорография	Fluoragraphy.tt	Fluoragraphy.pm
Прививки	Vaccin.tt	Vaccin.pm
Справка	Helper.tt	Helper.pm

В корне директории cgi-bin располагаются файлы index.cgi и Templete.pm и директория modules, в которой хранятся модули ConnectDB.pm, exel.pm, exel_card.pm, kernel.pm и ses.pm. Модули окон хранятся в директории wnd, а шаблоны в директории tt, которые расположены в корне директории cgi-bin. Листинг модулей приведен в приложении Б.

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

2.4 Реализация клиентской части приложения

Клиентские страницы генерируются динамически с помощью шаблонов template toolkit.

Template toolkit (TT) - это мощная система обработки шаблонов, написана на perl. Использование шаблонов для генерации web-страниц позволяет убрать из cgi-скрипта весь html код в отдельный файл (шаблон), где его сможет редактировать дизайнер. Скрипт при этом становится более читабельным [17].

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

Для создания шаблона требуется создать файл cgi-скрипта, расположенного в директории wnd и файл шаблона, расположенного в директории tt. После чего необходимо реализовать необходимое поведение в коде скрипта шаблона.

Код cgi-скрипта index.cgi, который занимается определением какой модуль системы необходимо подключить и какие данные передать ему:

#!C:\www\Perl5.8.9\bin\perl

print "Content-Type: Text/HTML; charset=UTF-8\n\n";

use strict;

use warnings;

use CGI;

use Template

use Templete;

use modules::kernel;

my $co = CGI->new();

my $login = $co->param('login') || '';

my $pass = $co->param('pass') || '0';

my $wnd = $co->param('wnd') || modules::kernel->read_last_page($login, $pass);

my $ses = $co->param('ses') || '0';

my $id_s = modules::kernel->user_id($login, $pass, $ses);

my $CGISESSID = $ses || '0';

my $title ='Добро пожаловать!';

if($CGISESSID eq "Error" or $id_s eq "0"){

# вывод шаблона index #

$title = 'Не правильно введено имя или пароль!';

my $parser = Template->new (INCLUDE_PATH => './tt');

$parser->process('index.tt', {'title' => $title,

'login' => $login});

}

else {

if(!$ses){

($CGISESSID, $title, $id_s) = modules::kernel->check_login($login, $pass, $wnd);

}

else {

$CGISESSID = modules::kernel->get_session($wnd, $id_s);

}

$ses = $CGISESSID;

if($CGISESSID eq "Error" or $id_s eq "0"){

# вывод шаблона index #

my $parser = Template->new (INCLUDE_PATH => './tt');

$parser->process('index.tt', {'title' => $title,

'login' => $login});

}

else {

my $r_ses = modules::ses->check_ses($CGISESSID, $id_s);

if($r_ses == 1){

my $helper = $co->param('hlp') || '-1';

my $hlp_lst;

if($helper ne '-1'){

my $query = qq"SELECT helper FROM wnd WHERE id_button = '$wnd'";

$hlp_lst = modules::ConnectDB->SelectFromDB($query);

}

my $menu = Templete->gen_menu($id_s);

my $name_wnd = Templete->name_wnd($wnd);

my $file = modules::kernel->query_file($wnd);

$ENV{'ses'} = $ses;

require "wnds/".$file.".pm";

my @page;

@page= $file->print_page($CGISESSID);

my $query = qq"SELECT * FROM sot_func a

WHERE a.sot_id = (SELECT id_sot FROM sesion WHERE sesion = '$ses') AND a.wnd_id = '$wnd'";

my $rules = modules::ConnectDB->SelectFromDB($query);

my $parser = Template->new (INCLUDE_PATH => './tt');

$parser->process('start_page.tt', {'CGISESSID' => $CGISESSID,

'wnd' => $wnd,

'menu' => $menu,

'rules' => $rules,

'namewnd' => $name_wnd,

'ses' => $ses,

'id' => $id_s,

'helper' => $helper,

'hlp_lst' => $hlp_lst,

'file' => $file.'.tt',

'page' => @page});

}

elsif($r_ses == 0) {

$title = "У вас закончилась сессия.<br>Авторизуйтесь еще раз.";

my $parser = Template->new (INCLUDE_PATH => './tt');

$parser->process('index.tt', {'title' => $title,

'login' => $login});

}

elsif($r_ses == -1) {

print "По не понятным причинам произошел сбой. Сообщите об этом системному администратору.";

}

}

}

Код шаблона index.tt, который предоставляет форму для ввода пароля:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//RU"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<meta name="Medic" content="Text/HTML; charset=UTF-8" />

<title>Medic</title>

<link rel="stylesheet" type="text/css" href="http://medic/style/main.css" />

<link rel="shortcut icon" href="http://medic/images/medic.ico">

</head>

<body>

<div id="m1">

<center>

<h1>[% title %]</h1>

<form name='main' method='post' action='/cgi-bin/index.cgi' id="main">

Имя: <input type='text' name='login' value='[%login%]' />

Пароль: <input type='password' name='pass' value='' /><br />

<br />

<input type='submit' value='Вход' /> <input type='button' value='Выход' onclick='window.close()' />

</form>

</center>

</div>

</body>

</html>

Как видно из кода шаблона, он написан на html со вставками вида [% title %] и так далее. Эти вставки язык Perl переводит в нужные действия при обработке шаблона, например, данная команда подставляет вместо этой вставки значения переменной, которая задается в скрипте. Результат работы шаблона index.tt представлен на рисунке 2.4, в данном случае был введен не правильный пароль. Таким же образом осуществляются циклы и условия.

Рисунок 2.4 - Отображение шаблона index.tt

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

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

Рисунок 2.5 - Динамическое меню системы

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

Для создания меню использовались стили CSS, подключаемые в шаблоне.

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

Код стиля для меню:

body {margin:25px; font:11px Verdana,Arial; background:#eee}

ul.menu {list-style:none; margin:0; padding:0}

ul.menu * {margin:0; padding:0}

ul.menu a {display:block; color:#000; text-decoration:none}

ul.menu li {position:relative; float:left; margin-right:2px}

ul.menu ul {position:absolute; top:26px; left:0; background:#d1d1d1; display:none; opacity:0; list-style:none}

ul.menu ul li {position:relative; border:1px solid #aaa; border-top:none; width:148px; margin:0}

ul.menu ul li a {display:block; padding:3px 7px 5px; background-color:#d1d1d1}

ul.menu ul li a:hover {background-color:#c5c5c5}

ul.menu ul ul {left:148px; top:-1px}

ul.menu .menulink {border:1px solid #aaa; padding:5px 7px 7px; font-weight:bold; background:url(images/header.gif); width:134px}

ul.menu .menulink:hover, ul.menu .menuhover {background:url(images/header_over.gif)}

ul.menu .sub {background:#d1d1d1 url(images/arrow.gif) 136px 8px no-repeat}

ul.menu .topline {border-top:1px solid #aaa}

Между тегами <head> и </head> вставляем строчку вида <link rel='stylesheet' type='text/css' href='../style/menu.css'>, которая говорит о том, что мы собираемся использовать стили и какой файл необходимо подключить.

После чего мы вставляем нижеуказанные строчки кода:

<ul class="menu" id="menu">

<li><a class="menulink">Меню</a>

<ul>

[% FOREACH key IN menu %]

[%IF key.t_f == 1%]<li><a href='javascript:load([%key.wnd_id%])'>[%key.name_wnd%]</a></li>[%END%]

[% END %]

</ul>

</li>

<li><a href='http://medic' class="menulink">Выход</a></li>

[%IF helper == -1 AND wnd != 31%]<li><a class="menulink" href="javascript:LoadHelp([%wnd%])">Справка</a></li>[%END%]

</ul>

Они говорят, что мы создаем список и тэгам <ul class="menu" id="menu"> и <a class="menulink"> присваиваем классы menu и menulink соответственно. Из кода стиля для меню видно какие параметры задаются для каждого класса и тега.

Далее идут вставки кода Perl, которые говорят о том, что необходимо выполнить цикл от оператора [% FOREACH key IN menu %] до оператора [% END %], все что находится между ними повторяется до конца массива данных переменной menu, которая вычисляется в скрипте index.cgi.

Внутри цикла так же встречается оператор условия ([%IF key.t_f == 1%]), который говорит о том, что все содержимое необходимо выполнить в случае если переменная key.t_f равна 1, в противном случае все содержимое пропускается. Переменная key.t_f, и все подобного вида в данном цикле, выбираются из массива menu. Таким образом формируется меню, определяя его содержимое для каждого пользователя, рисунок 2.4. Так же реализованы все 29 страниц для работы системы.