Referat Глава Обзор существующих решений. 1 История развития медицинских информационных систем. 2 Мис

2.3

Разработка системы поддержки принятия решения

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

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

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

В данной работе используется метод поиска знаний в базах данных. Для осуществления системы принятия решения была разработана дополнительная таблица в СУБД Microsoft Access, которая включила в себя данные о типах токсинов и свойственных им симптомах. При выборе необходимых симптомов, программа самостоятельно собирает сведения о токсинах, связанных с ними. Следующим этапом происходит отбор нескольких видов ядов, которые охватывают все или большинство отмеченных симптомов, которые и будут в дальнейшем выведены на экран пользователя.

В целом реализацию системы поддержки принятия решения можно отобразить следующим способом:

Таблица 2.3 Табличная реализация системы поддержки принятия решения

Симптом/ Яд	1	2	3
1	-	+	-
2	+	+	+
3	-	-	-

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

Таким образом, на основе данной таблицы, можно сказать, что наиболее вероятным видом токсина, вызвавшим отравление, послужил яд под номером 2.

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

Глава 3. Разработка программного обеспечения

.1 Общее описание разработанного ПО

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

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

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

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

.2 Создание базы данных для ПО

Для реализации программного обеспечения, которое бы представляло собой АРМ врача-токсиколога реаниматолога, необходимо было создать базу данных, хранящую в себе всю занесенную информацию. Для создания такой БД в данной бакалаврской работе была выбрана среда Microsoft Access.

Основными предметно-значимыми сущностями создаваемой БД являются: Пациент (DataBase_Patient), Врач (DataBase_Doctor), Первичный осмотр (DataBase_FirstView), Инструментальные исследования (DataBase_InstrumentalSurvey), Лабораторные исследования (DataBase_LaboratorySurvey), Состояние пациента (DataBase_StatePatient) и Лечение пациента (DataBase_Therapy).

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

Пациент: код пациента, фамилия, имя отчество, дата рождения, телефон, место жительства, код лечащего врача;

Врач: код врача, фамилия, имя, отчество, контактный телефон, логин, пароль;

Первичный осмотр: код пациента, симптомы, вредные привычки, аллергический анамнез, детские заболевания, хронические заболевания, дата и время.

Инструментальные исследования: код записи, код пациента, УЗИ почек, УЗИ мочевого пузыря, ЭКГ, дата и время.

Лабораторные исследования: код записи, код, пациента, анализ крови, анализ мочи, дата и время.

Состояние пациента: код записи, код пациента, общее состояние, состояние сердца, легких, желудка, почек, наличие симптома Пастернацкого, состояние при мочеиспускании, стуле, дата и время.

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

Между таблицами DataBase_Doctor и DataBase_Patient необходимо установить связь «один-ко-многим», т.к. один доктор может лечить нескольких пациентов.

Между таблицами DataBase_FirstView и DataBase_Patient устанавливается связь «один-ко-одному», т.к. каждому пациенту проводят один первичный осмотр.

Между таблицами DataBase_Patient и DataBase_InstrumentalSurvey, DataBase_StatePatient, DataBase_LaboratorySurvey, DataBase_Therapy необходимо установить связь «один-ко-многим», т.к. каждому пациенту несколько раз проводят исследования, назначают лечение и описывают его состояние.

Ниже приведена диаграмма, отображающая отношения «Сущность-Связь».

Рисунок 3.2.1 Диаграмма «Сущность-связь»

Проведем нормализацию отношений.

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

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

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

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

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

Рисунок 3.2.2 Схема данных в Microsoft Access