• Головний бухгалтер
  • _______________ М.І. Семаков
  • 1.1 Повне найменування установи охорони здоровя.
  • Коротка характеристика установи охорони здоровя.
  • 1.2. Повне найменування системи та її умовне позначення
  • 1.3. Найменування підприємств замовника і розробника системи
  • 1.5. Планові терміни здачі проекту
  • 2. Призначення і цілі створення (розвитку) системи
  • 2.3.Наіменованія і необхідні значення технічних, технологічних, виробничо-економічних і ін. Показників обєкта, які повинні бути досягнуті при впровадженні ІС
  • 3. Характеристика обєкта автоматизації
  • 4.Требованія до системи «Облік поліклінічних послуг»
  • 5. Вимоги до робіт з технічної підтримки
  • 6. Вимоги до програмного забезпечення.
  • 8.Состав і зміст робіт зі створення системи
  • 9. Вимоги до документації
  • Розробка АРМ реєстратури установи охорони здоров'я ТОВ Меридіан




    Скачати 50.03 Kb.
    Дата конвертації19.03.2020
    Розмір50.03 Kb.
    Типреферат

    анотація

    Дана пояснювальна записка містить опис процесу проектування автоматизованого робочого місця реєстратури медичної установи ТОВ «Меридіан».

    Додаток містить технічне завдання і автоматизовану систему роботи реєстратури поліклініки.

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

    Результатом повинна стати інформаційна система, призначена для автоматизації роботи реєстратури поліклінік створення функціонуючої БД. Розробка інформаційної системи необхідна для полегшення роботи реєстратора і зручностей пацієнта, так як пацієнту не доведеться довго стояти в чергах, а отримати своєчасну медичну допомогу. Застосування інформаційної системи підніме якість обслуговування поліклініки на більш високий рівень, що помітно позначиться на відвідуваності поліклініки.

    Автором проекту було вирішено використовувати для проектування систему управління базами даних 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 Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Автоматизовані системи. Терміни та визначення. ІПК видавництво стандартів. одна тисяча дев'ятсот дев'яносто сім

    5.ГОСТ 34.201-89 Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Види, комплектність і позначення документів при створенні автоматизованих систем. ІПК видавництво стандартів. одна тисяча дев'ятсот дев'яносто сім

    6.ГОСТ 34.601-90. Автоматизовані Системи Стадії створення. Комплекс стандартів на автоматизовані системи. ІПК видавництво стандартів. одна тисяча дев'ятсот дев'яносто сім

    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) 6750045
    1.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: М) означає, що один екземпляр сутності, розташований зліва по зв'язку, може бути пов'язаний з декількома екземплярами сутності, розташованими праворуч по зв'язку.

    Зв'язок «багато-до-багатьох (М: М) означає, що кілька екземплярів першої сутності можуть бути пов'язані з декількома екземплярами другої суті, і навпаки. Між двома сутностями може бути задано скільки завгодно зв'язків з різними смисловими навантаженнями.

    Схема даних реєстратури поліклініки



    Скачати 50.03 Kb.