Статья: Разработка АРМ регистратуры учреждения здравоохранения ООО Меридиан
Данная пояснительная записка содержит описание процесса проектирования автоматизированного рабочего места регистратуры медицинского учреждения ООО «Меридиан».
Приложение содержит техническое задание и автоматизированную систему работы регистратуры поликлиники.
Цель курсового проекта – изучение стадий разработки автоматизированных систем и закрепление навыков проектирования автоматизированных систем.
Результатом должна стать информационная система, предназначенная для автоматизации работы регистратуры поликлиникии создание функционирующей БД. Разработка информационной системы необходима для облегчения работы регистратора и удобств пациента, так как пациенту не придется долго стоять в очередях, а получить своевременную медицинскую помощь. Применение информационной системы поднимет качество обслуживания поликлиники на более высокий уровень, что заметно скажется на посещаемости поликлиники.
Автором проекта было решено использовать для проектирования систему управления базами данных MSAccess.
Содержание
Введение. 5
1. Предпроектное обследование медицинского учреждения. 6
2. Разработка технического задания. 7
Заключение. 9
Список использованных источников. 10
Приложение А. Техническое задание на проектирование АРМ регистратуры учреждения здравоохранения ООО «Меридиан»….11
Целью данного курсового проекта является закрепление теоретических знаний и приобретение практических навыков по проектированию информационных систем.
Достижение данной цели предполагается посредством автоматизации работы поликлиники, а именно – автоматизации процесса регистрации пациента на приём к врачу поликлиники ООО «Меридиан», а также сокращение ручного труда работника регистратуры при поиске информации о враче.
Разрабатываемая информационная система предназначена для автоматизации работы персонала поликлиники, включая лечащих врачей, руководящего аппарата, сотрудников диспетчерской, регистратуры и других подразделений.
1. Предпроектное обследование предприятия
1. При проведении обследования ставятся следующие цели:
— исследование условий деятельности объекта автоматизации (поликлиники);
— выявление взаимодействующих объектов и характера существующих информационных потоков;
— изучение бизнес-процессов, протекающих в рамках объекта;
— определение информационных нужд объекта;
— установление организационных, технических и технологических предпосылок к внедрению информационной системы.
2. Основными этапами проведения обследования являются:
1. Сбор материала;
2. Анализ материалов обследования и разработка концепции информационной системы.
Анализ материалов обследования был проведен на основе построения таблиц (операции бизнес-процессов) и схем (организационная структура регистратуры, схема взаимодействия регистратуры с другими структурными подразделениями поликлиники).
В результате проведенной на данной стадии работы выяснилось, что требуется замена существующей информационной системы.
2. Разработка технического задания
Техническое задание разрабатывается на основании материалов предпроектного обследования в соответствии с ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы».
Техническое задание (ТЗ) — исходный документ для разработки информационных систем, который содержит основные технические требования, предъявляемые к ней и исходные данные для разработки. В ТЗ указываются назначение объекта, область егоприменения, стадии разработки документации, её состав, сроки исполнения и т. д., а также особые требования, обусловленные спецификой самого объекта либо условиями его эксплуатации.
Как инструмент коммуникации в связке общения заказчик-исполнитель, техническое задание позволяет:
1. обеим сторонам
· представить готовый продукт;
· выполнить попунктную проверку готового продукта (приёмочное тестирование — проведение испытаний);
· уменьшить число ошибок, связанных с изменением требований в результате их неполноты или ошибочности (на всех стадиях и этапах создания, за исключением испытаний).
2. заказчику
· осознать, что именно ему нужно;
· требовать от исполнителя соответствия продукта всем условиям, оговорённым в ТЗ.
3. исполнителю
· понять суть задачи, показать заказчику «технический облик» будущей автоматизированной системы;
· спланировать выполнение проекта и работать по намеченному плану;
· отказаться от выполнения работ, не указанных в ТЗ.
При разработке технического задания необходимо решить следующие задачи:
- установить общую цель создания ИС, определить состав подсистем и функциональных задач;
- разработать и обосновать требования, предъявляемые к подсистемам;
- разработать и обосновать требования, предъявляемые к информационной базе, математическому и программному обеспечению, комплексу технических средств (включая средства связи и передачи данных);
- установить общие требования к проектируемой системе;
- определить перечень задач создания системы и исполнителей;
- определить этапы создания системы и сроки их выполнения;
- провести предварительный расчет затрат на создание системы и определить уровень экономической эффективности ее внедрения.
Таким образом, техническое задание — исходный документ определяющий порядок и условия проведения работ по Договору, содержащий цель, задачи, принципы выполнения, ожидаемые результаты и сроки выполнения работ.
В данном курсовом проекте были изучены и описаны основные стадии создания информационных систем, такие как:- описание предметной области;- разработка технического задания;Результатом курсового проекта явилось расширение, углубление и систематизация теоретических знаний и практических навыков, полученных в процессе изучения дисциплины «Проектирование информационных систем», развитие умения разрабатывать и читать технические документы, составлять и технически грамотно оформлять результаты проделанной работы.
Список использованных источников
1. ГОСТ 34.003-90 «Автоматизированные системы. Термины и определения».2. ГОСТ 34.602-89 «Техническое задание на создание АС».3. Вендров А.М. Проектирование программного обеспечения экономических информационных систем М: «Финансы и статистика», 2005
4.ГОСТ 34.003-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения. ИПК издательство стандартов. 1997
5.ГОСТ 34.201-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем. ИПК издательство стандартов. 1997
6.ГОСТ 34.601-90. Автоматизированные Системы Стадии создания. Комплекс стандартов на автоматизированные системы. ИПК издательство стандартов. 1997
7.Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя: Пер. с англ. М.: ДМК Пресс, 2000
8.Буч Г. Объектно-ориентированное проектирование с примерами применения М.: Конкорд, 1992
9.Козленко Л. Проектирование информационных систем. //КомпьютерПресс. — №9. 2001.
Приложение А
| УТВЕРЖДАЮ | УТВЕРЖДАЮ |
Главный бухгалтер ООО « Меридиан» | Директор ООО «КОРУС Консалтинг» |
| _______________Н.Л. Замбрицкий | _____________С.Л. Дроздов |
| «__»_______2009 г. | «__»_______2009 г. |
| СОГЛАСОВАНО |
Генеральный директор ООО «Меридиан» |
| _______________ М.И. Семаков |
| «__»_______2009 г. |
МИНСК, 2009
Содержание
1.Общие сведения…………………………………………………………..15 1.1.Полное наименование учреждения здравоохранения…………………
Краткая характеристика учреждения здравоохранения……………...15
1.2. Полное наименование системы и ее условное обозначение………...21
1.3. Наименование предприятий заказчика и разработчика системы...21
1.4. Перечень документов, на основании которых создается система..21
1.5. Плановые сроки сдачи проекта……………………………………….21
1.6.Финансирование проекта………………………………………………21
2. Назначение и цели создания (развития) системы……………………...22
2.1. Вид автоматизируемой деятельности………………………………22
2.2. Перечень объектов, на которых предполагается использование…….
системы……………………………………………………………………..22
2.3. Наименования и требуемые значения технических, технологических,
производственно-экономических и др. показателей объекта, которые
должны быть достигнуты при внедрении ИС…………………………..22
3.Характеристика объекта автоматизации………………………………...24
4.Требования к системе «Учёт поликлинических услуг»………………...25
4.1.Общие требования к выполняемым работам по проекту……………25
4.2. Требования к функциям устанавливаемых модулей………………….25
4.2.1. Требования к функциям модуля «Электронная регистратура»….25
4.2.2. Требования к функциям модуль “Электронная медицинская………
карта”………………………………………………………………….…...26
4.2.3. Требования к функциям модуля “Администратор
системы”…………………………………………………………………....27
4.2.4. Требования к функциям модуля “Статистика и аналитика…….
(генератор отчетов)”…………………........................................................27
4.2.5. Требования к функциям модуля «Система управления очередью и доступом »…………………………………………………………………...28
4.3. Требования к обеспечению защиты информации от …………………
несанкционированного доступа…………………………………………….28
5. Требования к работам по технической поддержке…………………......29
5.1. Обеспечение технической поддержки пользователей……………… 29
5.2.Обеспечение контроля работоспособности модернизированной……
системы……………………………………………………………………...29
5.3.Проведение регламентных работ по обслуживанию АИС …………..29
5.4. Информирование пользователей об изменениях в работе АИС ..…..29
5.5. Обеспечение восстановления работоспособности АИС…………….30
6. Требования к программному обеспечению…………………………......30
6.1.Требования к режимам функционирования системы…………………30
6.2.Требования по диагностированию системы ………………………....30
6.3. Перспективы развития, модернизации системы……………………31
6.4.Требования по эргономике и технической эстетике…………………31
6.6.Требования по стандартизации и унификации……………………….32
7.Требования к численности персонала…………………………………...32
8.Состав и содержание работ по созданию системы……………………...33
9. Требования к документации………………………………………………34
10. Проектирование базы данных в MSAccess……………………………35
1.Общие сведения
1.1 Полное наименование учреждения здравоохранения.
Объектом автоматизации является учреждение здравоохранения
ООО «Меридиан», регистратура данной поликлиники в частности.
Краткая характеристика учреждения здравоохранения.
ООО «Меридиан» получило лицензию на медицинскую деятельность 10.03.2000 г. Поликлиника ООО «Меридиан» является многопрофильной, оказывает услуг и по различным медицинским направлениям, что дает возможность в рамках одного учреждения всесторонне и квалифицированно выявлять и проводить лечение различных заболеваний.
Поликлиника ООО «Меридиан» в соответствии с лицензиями осуществляет следующий спектр услуг:
•Прием врача специалиста;
• Консультация врача специалиста;
• Диагностика;
• Лечение;
• Комплекс стоматологических услуг;
• Эндоскопическое обследование;
• Лабораторные анализы;
• Физиотерапевтические процедуры;
• Рентгенологические процедуры;
• Услуги невропатолога;
• Услуги нарколога.
• Мануальная терапия.
Поликлиника проводит большую профилактическую работу, противоэпидемические мероприятия, санитарно-просветительную работу среди населения обслуживаемого района и изучает здоровье прикрепленного контингента населения, выявляет раннюю заболеваемость, организует статистический учет и анализ показателей состояния здоровья населения, изучает заболеваемость с временной утратой трудоспособности на прикрепленных промышленных предприятиях.
Высший орган управления поликлиникой – общее собрание участников (общее собрание может быть очередным или внеочередным). Собрание участников проходит не реже одного раза в год. В компетенции собрания акционеров: решение об изменении или утверждении устава, отчета о прибылях и убытках, распределение доходов поликлиники, избрание совета директоров, а также решение вопросов о создании филиалов.
Уставом общество предусмотрено образование совета директоров (наблюдательного совета). Порядок образования и деятельности совета директоров (наблюдательного совета) общества, а также порядок прекращения полномочий членов совета директоров (наблюдательного совета) общества и компетенция председателя совета директоров (наблюдательного совета) определяются уставом общества. Совет осуществляет стратегическое управление: определяет цели и политику поликлиники на основании данных экономического анализа и бухгалтерской отчетности, рассматривает проекты планов поликлиники, осуществляет контроль проводимой поликлиники политики.
Руководство текущей деятельностью общества осуществляется единоличным исполнительным органом общества или единоличным исполнительным органом общества и коллегиальным исполнительным органом общества. Исполнительные органы общества подотчетны общему собранию участников общества и совету директоров (наблюдательному совету) общества. Руководитель несет ответственность перед общим собранием акционеров и советом директоров. Правление состоит из председателя правления, его заместителей и других членов. Правление действует на основании Устава общества, в котором установлены сроки и порядок проведения его заседаний и принятия решений.
Заседания правления проводятся регулярно, решения принимаются большинством голосов. При равенстве голосов голос председателя правления является решающим. Если члены правления или председатель не согласны с решением правления, то они могут, сообщит свое решение совету директоров или общему собранию акционеров. В этом случае окончательный голос будет за советом директоров. Реализация решения правления приводится в жизнь приказом председателя правления поликлиники.
В состав правления входят органы исполнительной власти, которые предваряют в жизнь проекты, подписанные правлением поликлиники.
Отдел кадров – занимается подбором кадров для поликлиники. Так же в обязанности отдела входит: направление на курсы повышения квалификации, предоставления отпусков сотрудникам, поощрения, выговоры и т.д.
Централизованная бухгалтерия – в обязанности бухгалтерии входит: начисление заработной платы, предоставление материальной помощи, оплата отпусков и т.д.
Отдел информационного обеспечения – в обязанности отдела входит контроль, отладка или замена ПЭВМ поликлиники. Так же установка новых информационных систем и обновление программного обеспечение поликлиники и т.д.
Планово – экономический отдел – занимается вопросами планирования закупок и распределение средств и другими вопросами, связанными с финансами.
Отдел по вводу и обработке данных выполненных объемов медицинской помощи – в состав этого отдела входят операторы (регистратура) который создает БД поликлиники, где регистрируются все обращения к врачам в целом и к каждому отдельно.
Службы непосредственной медицинской помощи:
• Амбулаторно-поликлиническая служба. В состав этой службы входят поликлиники
o Терапевтическое отделение – прием больных, назначение консультаций других специалистов, назначение обследования и лечения. Проведение диагностики заболеваний и другие мероприятия.
o Хирургическое отделение – приём, лечение и консультации по вопросам хирургии. Прием ведут так же травматологи и онкологи.
o Отоларингологическое отделение – прием больных, назначение обследований и необходимых процедур, связанных с Лор – заболеваниями.
o Офтальмологическое отделение – прием пациентов, обследование. Проведение коррекции зрения и лечение заболеваний.
o Неврологическое отделение – прием, консультация и лечение неврологических заболеваний. А так же проведение дополнительных обследований.
o Гинекологическое отделение – прием, обследование и консультации гинекологов. Назначение обследований и проведение операций. Ведение беременности.
o Стоматологическое отделение – прием пациентов и лечение. Протезирование и удаление. Косметологические процедуры.
o Детское отделение – прием и консультации детских специалистов.
o Рентгенологическое отделение
o Физиотерапевтическое отделение
o Лабораторная служба
o Эндоскопическое отделение
Структура поликлиники:
Рис.1. Структура поликлиники ООО «Меридиан»Краткая характеристика отдела по вводу и обработке данных выполненных объемов медицинской помощи.
Для приема и регистрации медицинских услуг в поликлинике имеется отдел по вводу и обработке данных выполненных объемов медицинской помощи, возглавляемый начальником, который осуществляет контроль над работой отдела обработки данных и вместе с руководителем медицинского учреждения несет ответственность за правильную организацию работы, а также четкое медицинское обслуживание клиентов поликлиники.
Регистратура медицинской поликлиники сталкивается с необходимостью работать с большим количеством информации. В обязанности регистратора входит:
• ввод пациентов в БД медицинской поликлиники;
• регистрация услуг оказываемых пациенту;
• составление отчета об оказанных услугах за день по отделениям, пациентам, организациям;
При работе с предприятиями регистратор обязан:
• Отслеживать обращения сотрудников за медицинской помощью (с учетом еще не закрытых больничных листов) для своевременных управленческих и административных решений.
• Обеспечение сотрудникам возможности обращаться за медицинской помощью в любое удобное для них время;
• Жесткий контроль объема качества оказанной медицинской помощи, а также расходование средств предприятия.
В обязанности начальника отдела по вводу и обработке данных входит составление договоров с организациями, которые хотели получать квалифицированную медицинскую помощь частной медицинской поликлиники ООО «Меридиан». Предоставление ежемесячного отчета организациям, с которыми заключены договора, о сумме, на которую в этом месяце были произведены услуги сотрудникам этой организации, также расторжение договоров с организациями.
1.2. Полное наименование системы и ее условное обозначение
Полное наименование системы: Автоматизированная информационная система «Учёт поликлинических услуг» для учреждения здравоохранения
ООО «Меридиан».
Условные обозначения системы: ИС «Учёт поликлинических услуг», Система.
1.3. Наименование предприятий заказчика и разработчика системы
Заказчик – ООО «Меридиан».
Адрес: 220100, г.Минск, ул. Лермонтова, д.4, тел.8(029)2867543
Разработчик – ООО «КОРУС Консалтинг».
Адрес: 220360, г. Минск, ул. Руссиянова, д.3, оф.231, тел.8(029)67500451.4. Перечень документов, на основании которых создается система
ИС «Учёт поликлинических услуг» создается на основании Договора
№ 3296432_1 от 14 марта 2009 г. между ООО «КОРУС Консалтинг» и
ООО «Меридиан».
1.5. Плановые сроки сдачи проекта
Начало проекта – 1 июля 2009 года.
Окончание проекта — 1 декабря 2009 года.
1.6.Финансирование проекта
Финансирование проекта производится полностью за счет медицинского учреждения-заказчика, оплата взимается по предоставлении компанией-разработчиком функционирующей информационной системы на основании акта-приемки.
2. Назначение и цели создания (развития) системы
2.1. Вид автоматизируемой деятельности
Автоматизация работы регистратуры ООО «Меридиан».
2.2.Перечень объектов, на которых предполагается использование системы
Отдел по вводу и обработке данных выполненных объемов медицинской помощи – в состав этого отдела входят операторы (регистратура), где регистрируются все обращения к врачам в целом и к каждому отдельно.
2.3.Наименования и требуемые значения технических, технологических, производственно-экономических и др. показателей объекта, которые должны быть достигнуты при внедрении ИС
За свой рабочий день регистратор старается обслужить как можно больше пациентов, но это не совсем удается, так как его основное время уходит на заполнение медицинской документации. Применение в его работе вычислительной техники облегчит его работу и в результате увеличится скорость принятия пациентов.
С каждым днем за медицинской помощью в клинику обращается все больше пациентов. На регистратора возлагается большой груз обязанностей. В связи с этим возрастает и вероятность ошибок, на исправление которых у регистратора уходит драгоценное время. Ошибки также негативно сказываются на отчетности.
Целью создания информационной системы «Учет поликлинических услуг» – является повышение трудоспособности регистратора за счет сокращения временных и трудовых затрат и повышение качества его работы.
Создание информационной системы «Учет поликлинических услуг» предоставит работникам отдела по вводу и обработке данных следующие возможности:
•Уделять время пациенту, которого раньше не хватало;
• Поднять качество обслуживания пациентов на более высокий уровень;
• Избавить регистратора от возможных ошибок, на исправление которых у него уходит много времени.
Можно проанализировать, сколько регистратор затрачивает времени на каждого пациента, делая это вручную без использования информационной системы «Учет поликлинических услуг».
• На прием пациентов и заполнение всей медицинской документации, при отсутствии непредсказуемых факторов, регистратор тратит от 5 до 15 минут.
• Заполнение карточки пациента, куда включаются все медицинские услуги с фамилией врача и ценой за одну услугу и полную сумму, у регистратора уходит около 5 – 10 минут. Однако надо учесть, что данная процедура выполняется не однократно в течение всего премного дня.
• Составление отчета в конце каждого приемного дня по принятым пациентам и оказанным им услугам, включая суммы за каждую услугу – уходит от 10 до 20 минут, при этом не допускаются исправления и ошибки, и в случае их совершения оператор должен обязательно переписать документы, что опять же требует дополнительного времени.
• Ежемесячные отчеты для организаций об оказанных услугах, на сумму договора и остаток в конце каждого месяца требует очень сосредоточенной работы и занимает достаточно много времени около 1-ого, а иногда составление отчета затягивает до 3 часов.
В результате, на обслуживание одного клиента у оператора уходит от 11 минут до 18 минут, что зависит от количества услуг, которые хочет пройти клиент. Перечислив все действия, которые совершает регистратор в течение дня и, подсчитав примерное время можно сказать, что за восьми часовой день регистратор обслуживает от 26 до 43 человек.
При внедрении системы «Учет поликлинических услуг», работать регистратору станет легче, заполнение медицинской документации будет занимать намного меньше времени и в результате регистратор сможет обслужить гораздо большее число пациентов, и им не придется долгие часы ждать в очереди.
В результате, разработка информационной системы для учета поликлинических услуг увеличит производительность труда регистратора отдела по вводу и обработке данных на 14 %, а также создаст благоприятные условия для повышения эффективности и качества работы отдела.
3. Характеристика объекта автоматизации
Актуальность создания информационной системы в медицинских учреждениях обусловлена сегодня необходимостью использования больших, и постоянно растущих, объемов информации при решении диагностических, терапевтических, статистических, управленческих и других задач.
Информатизация деятельности учреждений здравоохранения уже давно стала насущной необходимостью. Обработка все время растущих массивов информации стала возможна только с использованием современных компьютерных технологий.
Большая часть приема уходит не на решение клинических вопросов, а на сопроводительную и далеко не самую основную работу – оформление поликлинических талонов и другой отчетной документации, записей в амбулаторной карте или истории болезни, назначений консультаций или обследования и т.д. Уже не вызывает сомнений, что наиболее эффективным инструментов для облегчения труда медицинских сотрудников и повышения его эффективности являются компьютерные технологии. Автоматизация способна не просто облегчить работу, она должна освободить персонал от рутины и дать ему принципиально новый инструмент, который прямо или косвенно, но приведет к сокращению нецелевого расхода интеллектуального багажа, реализации желания работать и заниматься именно медициной.
4.Требования к системе «Учёт поликлинических услуг»
4.1.Общие требования к выполняемым работам по проекту
В ходе выполнения проекта должны быть проведены следующие работы:
· разработка и установка модуля «Электронная регистратура»;
· разработка и установка модуля «Электронная медицинская карта»;
· разработка и установка модуля «Администратор системы»;
· разработка и установка модуля «Статистика и аналитика (генератор отчетов)»;
· разработка и установка модуля «Система управления доступом и очередью»;
· ввод в эксплуатацию автоматизированной информационной системы.
4.2. Требования к функциям устанавливаемых модулей.
4.2.1. Требования к функциям модуля «Электронная регистратура».
Модуль «Электронная регистратура» должен выполнять следующие функции:
· Формирование и ведение расписания приема врачей
· Запись на прием
· Предварительная удаленная запись
· Поиск пациентов (по ФИО, номеру полиса, номеру карты, штрих-коду)
· Регистрация нового пациента (вручную, по штрих-коду)
Реализация функции “Предварительная запись” должна обеспечить предварительную запись больных удаленно через Интернет. Функция реализуется по технологии тонкого клиента, связь должна осуществляться через Интернет с применением протокола HTTPS и сертификатов подлинности на скорости не ниже 56кбит/сек, для работы клиента необходимо использовать один из наиболее распространенных браузеров Интернет.
При реализации функции “Предварительная запись” должны быть предусмотрены:
· Авторизация пользователей для входа в систему
· Обязательное заполнение ФИО, даты рождения, паспорта либо документа удостоверяющего личность, полиса и страховой компании,
· Выбор необходимых специалистов из перечня врачебных специальностей
· Автоматическое построение расписания из выбранных ранее специалистов с указанием даты, времени, количества свободных для записи мест (талонов).
· Печать бланка направления с указанием специалистов, даты, времени, места приема, штрих кодом пациента (номером направления, кода пациента,)
· Запись всех направлений в журнал
· Вывод на печать журнала направлений по выбранному лечебно-профилактическому учреждению
· Отображение предварительной записи пациента в модуле «Электронная регистратура» с занесением в базу данныхполиклиники следующих данных:
— ФИО,
— дата рождения,
— реквизиты паспорта либо документа, удостоверяющего личность,
— реквизиты полиса обязательного медицинского страхования.
4.2.2. Требования к функциям модуль “Электронная медицинская карта”.
Модуль “Электронная медицинская карта” должен выполнять следующие функции:
· ведение паспорта участка
· запись на приём к специалистам поликлиники
· поиск и ведение амбулаторных карт находящихся в базе данных
· использование текстовых и диалоговых шаблонов для быстрого заполнения
· направление на анализы, обследования и консультации специалистов с рабочего места
· постановка на диспансерный учет, редактирование и ввод диспансерных карт, отслеживание движения пациента по карте
4.2.3. Требования к функциям модуля “Администратор системы”.
Подсистема “Администратор системы” должна выполнять следующие функции:
· Контроль целостности системы
· Регистрация и учет пользователей
· Настройка АРМ под пользователя
· Настройка ролей и прав доступа
· Подключение новых модулей к системе и к выбранным пользователям
При реализации функций подсистемы должно быть предусмотрено:
· Создание учетных записей пользователей при принятии сотрудника на работу, определение набора функций, выполняемых им в системе в соответствии с должностными обязанностями.
· Блокирование учётной записи пользователя при увольнении работника.
· Создание в установленном порядке учетных записей пользователей в системе при развертывании системы на новых рабочих местах
· Определение для каждого пользователя индивидуального набора функций, выполняемых им в системе в соответствии с должностными полномочиями в установленном порядке при развертывании системы на новых рабочих местах .
4.2.4. Требования к функциям модуля “Статистика и аналитика (генератор отчетов)”.
Модуль “Статистика и аналитика (генератор отчетов)” должна выполнять следующие функции:
· Построение произвольных оперативных отчетов
· Построение произвольных многомерных сводных отчетов
· Вывод результатов отчетов в форматы MSWord, MSExcel, HTML, TXT, XML.
· Установка прав на использование созданного отчета
· Выбор механизма построения отчетов по атрибутам или по заданным группам.
· Формирование счетов реестров согласно приказа №343 от
26.03.2008 Министерства здравоохранения, дополнений и изменений №1029 от 10.08.2008 Министерства здравоохранения
· Отчеты статистические
4.2.5. Требования к функциям модуля «Система управления очередью и доступом »
Модуль «Система управления очередью и доступом » должен выполнять следующие функции:
Присвоение номера очереди
Вызов записанного пациента
Отмена очереди
Распределение потоков первичных и повторных пациентов
Допуск в помещение
4.3. Требования к обеспечению защиты информации от
несанкционированного доступа
· реализация аутентификации и авторизации пользователей в системе с использованием аппаратного ключа строгой аутентификации USB
Е-Token.
· Применение политики блокировки учетных записей пользователей
· Реализация модуля безопасности (доступа к данным и модулям системы) на базе ролевой модели
· Введение службы протоколирования, аудита действий и доступа пользователей системы
5. Требования к работам по технической поддержке
5.1. Обеспечение технической поддержки пользователей
Служба технической поддержки пользователей должна обеспечивать взаимодействие пользователей и операторов с помощью телефонной связи, осуществлять учет обращений, предоставлять отчетность по статистике обращений.
Техническая поддержка пользователей должна обеспечиваться в рабочие дни — с 8:00 до 20:00; по субботам — с 8:00 до 14:00; в предпраздничные дни- с 8:00 до 17:00.
5.2.Обеспечение контроля работоспособности модернизированной системы.
Контроль работоспособности модернизированных в соответствии с данным техническим заданием подсистем АИС должен осуществляться на регулярной основе и обеспечивать периодический контроль основных функций системы.
5.3.Проведение регламентных работ по обслуживанию АИС
Проведение регламентных работ по обеспечению функционирования АИС должно осуществляться ежемесячно и включать в себя следующие работы:
· проверка корректности работы серверного программного обеспечения;
· контроль и управление web-сервисом;
· контроль нагрузки на базу данных, проведение оптимизации запросов к базе данных;
5.4. Информирование пользователей об изменениях в работе АИС
Информация обо всех важных событиях, приводящих к изменению порядка работы в системе (проведение регламентных работ и технического обслуживания, изменения в работе отдельных модулей АИС), должна доводиться до сведения пользователей АИС в соответствии с разработанным регламентом.
5.5. Обеспечение восстановления работоспособности АИС
При возникновении аварий или сбоев в работе программной или аппаратной частях АИС должны быть организованы работы по устранению последствий аварий или сбоев.
6. Требования к программному обеспечению.
Разработанные программные модули модернизируемых подсистем должны быть совместимы с имеющейся в ООО «Меридиан»информационной системой. Исполнитель обязан установить лицензионные программные продукты и передать лицензии Заказчику.
6.1.Требования к режимам функционирования системы
Режим функционирования — бесперебойно в часы работы регистратуры (за исключением согласованных периодов времени на выполнение регламентных работ по обслуживанию оборудования или программного обеспечения системы).
Обеспечение работоспособности серверного оборудования и сетевого оборудования производится силами ИТ-отдела ООО «Меридиан».
6.2.Требования по диагностированию системы
Система должна удовлетворять следующим требованиям по диагностированию:
автоматический контроль за нарушениями заложенных в систему правил;
выдача пользователю сообщений, содержащих адекватное описание нарушения работоспособности;
однозначное соответствие между нарушениями работоспособности и сообщениями Системы, т.е. Система должна выдавать одинаковые сообщения для одинаковых нарушений работоспособности;
защита от некорректного ввода данных пользователем.
6.3. Перспективы развития, модернизации системы
Система должна поддерживать обновление версий выбранного ПО, допускать модернизацию для учета возникающих изменений в информационных процессах отделения профилактики и законодательстве Республики Беларусь.
Система должна допускать расширение функциональных возможностей за счет создания дополнительных функциональных модулей и возможность интеграции в другие более масштабные информационные системы.
6.4.Требования по эргономике и технической эстетике
Система должна обеспечивать стандартный для Windows систем пользовательский интерфейс, отвечающий следующим требованиям:
— В части внешнего оформления:
· реализация в графическом оконном режиме;
· настраиваемость графических элементов интерфейса, в том числе цветового оформления, в пределах возможностей операционной системы;
· диалог с пользователем должен быть оптимизирован для выполнения типовых и часто используемых операций;
· взаимодействие пользователя с системой должно осуществляться на русском языке, за исключением отдельных системных сообщений;
· отображение на экране только тех возможностей, которые доступны конкретному пользователю;
· отображение на экране только необходимой для решения текущей прикладной задачи информации;
· для модулей с массовым вводом информации ориентация на использование клавиатуры с минимизацией количества нажатий для стандартных действий;
· использование визуальных подсказок;
· отображение на экране хода длительных процессов обработки;
· возможность использования справочников при работе с полями ввода информации.
6.6.Требования по стандартизации и унификации
Система должна обеспечивать формирование отчетности необходимых форм.
7.Требования к численности персонала
Количество сотрудников регистратуры поликлиники, использующей функциональные рабочие места системы АРМ определено и равно 7. При разработке системы необходимо учесть возможность увеличения количества АРМ.
8.Состав и содержание работ по созданию системы
| Наименование работ | Сроки выполнения | |
| 1 | Развитие автоматизированной информационной системы «Учёт поликлинических услуг» | 01.07.2009 – 1.12.2009 |
| 2 | Обследование, составление тех.проекта, внедрение, обучение персонала | 01.07.2009 – 30.07.2009 |
| 3 | разработка и установка модуля «Электронная регистратура»; | 30.09.2008 – 20.11.2009 |
| 4 | разработка и установка модуля «Электронная медицинская карта» | 30.09.2008 – 20.11.2009 |
| 5 | разработка и установка модуля «Администратор системы»; | 30.09.2008 – 20.11.2009 |
| 6 | разработка и установка модуля «Статистика и аналитика (генератор отчетов)»; | 30.09.2008 – 20.11.2009 |
| 7 | разработка и установка модуля «Система управления доступом и очередью»; | 30.09.2008 – 20.11.2009 |
| 8 | ввод в эксплуатацию автоматизированной информационной системы. | 20.11.2009-1.12.2009 |
9. Требования к документации
Исполнителем должны быть разработаны:
Описание структуры системы и подсистем с указанием разработанных программных модулей, входных и выходных данных каждого модуля, связей между модулями.
Описание структур данных с указанием имен данных, типа данных, смысловой характеристики данных, связей между данными.
Руководства пользователей для всех модернизируемых подсистем
Руководство системного администратора
10. Проектирование базы данных в MSAccess
Разработку информационного обеспечения АРМ регистратора проведем на базе системы управления базами данных (СУБД) Access XP из состава выбранного интегрированного пакета Microsoft Office XP.
СУБД Access предназначена для разработки баз данных реляционного типа для локального их использования на персональных компьютерах и для работы с этими базами.
При проектировании базы данных, в первую очередь, необходимо определить, что именно нужно хранить.
Данная СУБД была выбрана по следующим причинам:
§ простота средств реализации,
§ легкость освоения инструментарием разработчика (VBA),
§ наглядность визуализации информации.
Также «Microsoft Access» предоставляет большое количество внутренних средств по оптимизации работы проектируемого приложения. К ним относятся:
· загрузка модулей по требованию;
· оптимизация дерева вызовов;
· использование файлов MDE;
· автоматическая поддержка компилированного состояния;
· использование библиотек Windows API;
· индивидуальная настройка системы;
· эффективное использование индексов;
· встроенный оптимизатор запросов.
Прежде чем начинать проектирования БД, необходимо провести подробное словесное описание объектов предметной области и реальных связей, которые присутствуют между описываемыми объектами. Желательно, чтобы данное описание позволяло корректно определить все взаимосвязи между объектами предметной области.
Системный анализ должен заканчиваться подробным описанием информации об объектах предметной области, которая требуется для решения конкретных задач и которая должна храниться в БД, формулировкой конкретных задач, которые будут решаться с использованием данной БД с кратким описанием алгоритмов их решения, описанием выходных документов, которые должны генерироваться в системе, описанием входных документов, которые служат основанием для заполнения данными БД.
Инфологическая модель применяется на втором этапе проектирования БД, то есть после словесного описания предметной области. Процесс проектирования длительный и требует обсуждений с заказчиком и со специалистами в предметной области. Наконец, при разработке серьезных информационных систем проект базы данных является тем фундаментом, на котором строится вся система в целом. Следовательно, инфологическая модель должна включать такое формализованное описание предметной области, которое легко будет «читаться» не только специалистами по базам данных. И это описание должно быть настолько емким, чтобы можно было оценить глубину и корректность проработки проекта БД.
Цель инфологического моделирования — обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому инфологическую модель данных пытаются строить по аналогии с естественным языком (последний не может быть использован в чистом виде из-за сложности компьютерной обработки текстов и неоднозначности любого естественного языка). Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты).
Сущность — любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе.
Сущность имеет имя, уникальное в пределах модели. При этом имя сущности — это имя типа, а не конкретного экземпляра.
Сущности подразделяются на сильные и слабые. Сущность является слабой, если ее существование зависит от другой сущности — сильной по отношению к ней. Например, сущность «Подчиненный» является слабой по отношению к сущности «Сотрудник»: если будет удалена запись, соответствующая некоторому сотруднику, имеющему подчиненных, то сведения о подчинении также должны быть удалены.
Атрибут — поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей. Атрибуты используются для определения того, какая информация должна быть собрана о сущности.
Абсолютное различие между типами сущностей и атрибутами отсутствует. Атрибут является таковым только в связи с типом сущности. В другом контексте атрибут может выступать как самостоятельная сущность.
Ключ — минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся.
Связь — ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных — это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено более миллиона связей. Наличие такого множества связей и определяет сложность инфологических моделей.
Справочник врачей хранится в таблице VRACH, структура и правила поддержки целостности данных которой приводятся в таблицах.
Таблица 1
Таблица VRACH
| Название | Тип данных | Размер | Ограничения | Назначение |
| CODE_VRACH | Integer | Primary Key | Код врача | |
| FAM_VRACH | Char | 25 | Not NULL | Фамилия врача |
| IMYA_VRACH | Char | 25 | Not NULL | Имя врача |
| OTCH_VRACH | Char | 25 | Отчество врача | |
| CODE_DOLGN | Integer | Код специализации | ||
| CODE_KABINET | Integer | Код занимаемого кабинета | ||
| CODE_TIME | Integer | Код времени приема |
Справочник пациентов хранится в таблице PACIENT, структура и правила поддержки целостности данных которой приводятся в табл. 2.
Таблица 2
Таблица PACIENT
| Название | Тип данных | Размер | Ограничения | Назначение |
| CODE_ PACIENT | Integer | Primary Key | Код пациента | |
| FAM_ PACIENT | Char | 25 | Not NULL | Фамилия пациента |
| IMYA_ PACIENT | Char | 25 | Имя пациента | |
| OTCH_ PACIENT | Char | 25 | Отчество пациента | |
| CODE_VRACH | Integer | Not NULL | Код врача | |
| CODE_DATE | Integer | Код даты приема |
Данные о специализации врачей хранятся в таблице DOLGN, структура и правила поддержки целостности данных которой приводятся в табл. 3.
Таблица 3
Таблица DOLGN
| Название | Тип данных | Размер | Ограничения | Назначение |
| CODE_DOLGN | Integer | Primary Key | Код специализации | |
| DOLGN | Char | 25 | Название специализации |
Для хранения данных о номерах кабинетов заполняется таблица KABINET, структура и правила поддержки целостности данных которой приводятся в табл. 4.
Таблица 4
Таблица KABINET
| Название | Тип данных | Размер | Ограничения | Назначение |
| CODE_KABINET | Integer | Primary key | Код кабинета | |
| KABINET | Integer | Номер кабинета | ||
| SUMMATOR | Integer | Not NULL | Количество врачей в кабинете | |
| CODE_DOLGN | Integer | Код специализации | ||
| POLOJENIE | Char | 25 | Положение кабинета( свободен или занят) |
Для хранении данных о времени приема врача заполняется таблица TIME, структура и правила поддержки целостности данных которой приводятся в табл. 5.
Таблица 5
Таблица TIME
| Название | Тип данных | Размер | Ограничения | Назначение |
| CODE_TIME | Integer | Primary key | Код времени приема | |
| TIME | Char | 25 | Время приема |
Для хранения информации о дате приема к врачу создана таблица DATE_PRIEM, структура и правила поддержки целостности данных которой приводятся в табл. 6.
Таблица 6
Таблица DATE_PRIEM
| Название | Тип данных | Размер | Ограничения | Назначение |
| CODE_DATE | Integer | Primary Key | Код даты | |
| DATE_PRIEM | Date | Дата приема | ||
| CODE_VRACH | Integer | Not NULL | Код врача | |
| SUMMATOR | Integer | Количество пациентов |
Связи между таблицами инфологической модели
Система управления базами данных (СУБД) обычно поддерживает 4 основных типа отношений между таблицами:
— один-к-одному (одной записи в первой таблице соответствует одна запись во второй);
— один-ко-многим (одной записи в первой таблице соответствует много записей во второй);
— много-к-одному (многим записям в первой таблице соответствует одна запись во второй);
— много-ко-многим (одной записи в первой таблице соответствует много запией во второй и одной записи во второй таблице соответствует много записей в первой).
Инфологическая модель применяется после словесного описания предметной области.
Связи делятся на три типа по множественности: один-ко-одному (1:1), один-ко-многим (1: М), многие-ко-многим (М: М).
Связь один-ко-одному означает, что экземпляр одной сущности связан только с одним экземпляром другой сущности.
Связь один-ко-многим (1: М) означает, что один экземпляр сущности, расположенный слева по связи, может быть связан с несколькими экземплярами сущности, расположенными справа по связи.
Связь «многие-ко-многим (М: М) означает, что несколько экземпляров первой сущности могут быть связаны с несколькими экземплярами второй сущности, и наоборот. Между двумя сущностями может быть задано сколько угодно связей с разными смысловыми нагрузками.
Схема данных регистратуры поликлиники