Інформаційна система обліку пацієнтів медичного закладу - Дипломная работа

бесплатно 0
4.5 105
Проект автоматизованої підсистеми для обліку результатів медичного обстеження студентів і співробітників ВНЗу. Розробка концептуальної моделі бази даних і додатків. Фізична реалізація системи "1С-АНАЛИТ: Медицинское учреждение", програмне забезпечення.


Аннотация к работе
1.10 Вихідна інформація.1 Огляд системи «1С-АНАЛИТ: Медицинское учреждение» 2.1.1 Функціональні можливості конфігурації, особливості обліку3.1 Проектування інформаційного забезпечення4.1 Вимоги до програмного забезпечення. Нефункціональні вимоги Вибір базового програмного забезпечення5.1 Призначення посібника користувача 5.3 Вимоги до конфігурації системи 5.4 Мінімальний состав програмних засобівПЕРЕЛІК ПОСИЛАНЬHTML-КОД САЙТА СПИСКА ПАЦІЄНТІВТематика роботи є актуальною, вона відповідає напрямкам, визначеним у Державній програмі інформатизації охорони здоровя України на 2006-2010 роки, пріоритетним напрямам розвитку науки і техніки, визначеним Міністерством освіти і науки України, технічному завданню на виконання кафедрою ПІТ ЕІДМУ "КПУ" науково-дослідного проекту за темою "Створення програмних засобів і технологій забезпечення компютерного інформаційного середовища". На даний момент в інституті процес обліку результатів медичного обстеження є автоматизованим, але результати не вносяться в загальну базу даних, також програма для даного обліку застаріла й не є WEB програма Раніше медичний облік вівся письмово, такі архіви займали величезний простір і не були зручними в плані додавання яких або змін, а так само більшим мінусом була трудомісткість пошуку необхідної інформації.UML (Unified Modeling Language) забезпечує підтримку всіх етапів життєвого циклу ІС та надає для цих цілей ряд графічних засобів - діаграм. На етапі створення концептуальної моделі для опису бізнес-діяльності використовуються моделі бізнес-прецедентів і діаграми видів діяльності, для опису бізнес-обєктів - моделі бізнес-обєктів і діаграми послідовностей. На етапі створення логічної моделі ІС опис вимог до системи задається у вигляді моделі та опису системних прецедентів, а попереднє проектування здійснюється з використанням діаграм класів, діаграм послідовностей і діаграм станів. Нижче наведено визначення і описується призначення перерахованих діаграм і моделей стосовно завдань проектування ІС (в дужках наведені альтернативні назви діаграм, що використовуються в сучасній літературі).Модель бізнес-прецедентів описує бізнес-процеси з точки зору зовнішнього користувача, тобто відображає погляд на діяльність організації ззовні. Виконавець (Діюча особа, Actor) - особистість, організація або система, що взаємодіє з ІС; розрізняють зовнішнього виконавця (який використовує або користовується системою, тобто породжує прецеденти діяльності) та внутрішнього виконавця (який забезпечує реалізацію прецедентів діяльності всередині системи). На діаграмі виконавець представляється стилізованою фігуркою людини. Прецедент - закінчена послідовність дій, ініційована зовнішнім обєктом (особистістю або системою), яка взаємодіє з ІС і отримує в результаті деяке повідомлення від ІС. На діаграмі представляється овалом з написом, що відображає зміст дії.Наступним етапом проектування ІС є розробка моделі бізнес-обєктів, що показує виконання бізнес-процесів організації її внутрішніми виконавцями. Основними компонентами моделей бізнес-обєктів є зовнішні і внутрішні виконавці, а також бізнес-сутності, що відображають все, що використовують внутрішні виконавці для реалізації бізнес-процесів. Приклад моделі бізнес-обєктів для прецеденту "Відповідь на запит" наведено на рис. Насправді ж, із запитом про стан пацієнта можуть звертатися в систему багато хто з дійових осіб: юрист, страхова компанія, технічний персонал і навіть сам пацієнт. Таким чином, поняття "Відправник запиту" служить для узагальненого представлення всіх цих дійових осіб при описі прецеденту "Відповідь на запит" (рис.Потім на основі інформації, виявленої на етапах бізнес-моделювання, виконується розробка концептуальної моделі даних, які будуть використовуватися в розроблюваній системі. Модель показує, що клінічні записи включають (агрегують) ряд блоків. При цьому "мінімальний набір даних" і "план лікування" можуть бути включені в кожен клінічний запис в єдиному екземплярі, а блоки "результати аналізів", "приписи лікаря", "хід лікування" можуть повторюватися необмежену кількість разів. Оскільки пацієнт може попередньо проходити лікування в інших установах, або кілька разів проходити лікування в центрі, зявляються додаткові різновиди (підкласи) клінічних записів: зовнішні, старі внутрішні, нові внутрішні.На етапі формування вимог, перш за все, необхідно визначити область дії системи, що розробляється, та отримати точне уявлення про бажані можливості системи. Основою розробки вимог є модель системних прецедентів, що відбиває виконання конкретних обовязків внутрішніми і зовнішніми виконавцями з використанням ІС. Однак при створенні моделі корисно заздалегідь скласти детальні описи прецедентів, які містять визначення використовуваних даних і точну послідовність їх виконання.

План
ЗМІСТ

ВСТУП

РОЗДІЛ 1. Аналіз предметної області

1.1 Розробка моделі бізнес-прецедентів

1.2 Розробка моделі бізнес-обєктів

1.3 Розробка концептуальної моделі даних

1.4 Розробка вимог до системи

1.5 Аналіз вимог і попереднє проектування системи

1.6 Розробка моделей бази даних і додатків

1.7 Проектування фізичної реалізації системи

1.8 Одержання прав доступу вхід у підсистему

Вывод
ПЕРЕЛІК ПОСИЛАНЬ

Додаток А. DFD-Діаграма
Заказать написание новой работы



Дисциплины научных работ



Хотите, перезвоним вам?