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

В настоящее время большие объемы медицинских данных собираются и хра­нятся в электронном виде. Хранение медицинских данных, таких как персональные данные, такие как снимки компьютерного томографа, может быть выполнено не­сколькими способами.

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

MeDIA (сокращение от Medical Data Integration Application) - название систе­мы управления медицинской базой данных, которая в настоящее время разрабаты­вается. Сенсорные данные, которые MeDIA может хранить, включают в себя ЭЭГ,

МРТ или КТ вместе с соответствующими метаданными, такими как информация о пациенте и аннотации. Основное преимущество MeDIA перед простым хранением двоичных данных заключается в том, что MeDIA обрабатывает происхождение, не­определенность, управление версиями и может комбинировать различные типы данных, например, ЭЭГ и МРТ.

Происхождение используется, чтобы показать, откуда происходит конкретный элемент данных. Например, если есть элементы данных a, b, с и с, определены как с = a + b, с выводится из а и b. Это может быть использовано, например, в диагности­ческой таблице. Каждый диагноз перечисляет сенсорные данные, на которых он ос­нован. Если по какой-то причине определенный набор сенсорных данных должен быть отклонен из-за неправильной записи, легко определить, какой диагноз необхо­димо пересмотреть.

Неопределенность в базе данных означает, что к элементам в базе данных прикреплена определенная вероятность.

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

MeDIA состоит из нескольких компонентов, таких как интерфейс прикладного программиста (API) и экстракторы функций. На рисунке 2.4 показан дизайн MeDIA. Программное обеспечение пользователя связывается с системой через API.

Рисунок 2.4 - Компоненты MeDIA

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

Топология базы данных и рабочих станций показана на рисунке 2.3. Больни­ца имеет внутреннюю сеть, которая обозначена на рисунке серым фоном. Брандмау­эр фильтрует весь трафик Интернета. Брандмауэр настроен таким образом, что он не разрешает входящие соединения из Интернета с базой данных. Поэтому доступ к базе данных ограничен любой рабочей станцией в сети больницы. Это может счи­таться хорошей практикой, поскольку это может смягчить некоторые атаки со сто­роны узлов вне сети, например, при атаке на уязвимое программное обеспечение, работающее на серверах больницы. Однако, поскольку в самой больничной сети много компьютеров, все еще есть возможность атаковать базу данных. Можно зара­зить рабочую станцию в сети вирусом, например, с помощью фишинг-атаки, полу­чив таким образом доступ к сети и, таким образом, минуя брандмауэр. Показания КТ, аннотации к этим показаниям и информация о пациенте были отправлены на запись КТ. База данных доступна только из сети больницы, и, как было указано ра­нее, брандмауэр применяет эту политику. Контроль доступа к базе данных осу­ществляется с использованием учетных данных. Эти учетные данные предоставля­ются только выбранной группе сотрудников. В этой ситуации есть системный адми­нистратор, который предоставляет доступ (другим) сотрудникам, поэтому сам ад­министратор может получить доступ к базе данных. В базе данных все данные, включая информацию о пациенте, хранятся без какой-либо формы шифрования. Контроль доступа, основанный на учетных данных, позволяет только определенным сотрудникам получать доступ к данным и обеспечивается только базой данных.

Рисунок 2.5 - Топология медицинской базы данных

Стоит отметить, есть две важные особенности, которые могут определять успех или неудачу информационной системы здравоохранения. Первый связан с существованием общего словаря общепринятых терминов для всех медицинских понятий или административных данных, используемых системой применительно к любому пациенту. Второе относится к способности системы предоставлять кон­кретную информацию для каждого приложения, не ставя под угрозу интеграцию центральной базы данных. Это требование действительно для любой системы пла­нирования ресурсов предприятия (то есть интегрированной системы деловой ин­формации), но в сфере здравоохранения оно имеет особое значение. Фактически, обилие неструктурированных и / или неинтегрированных данных, по -видимому, яв­ляется одной из наиболее важных проблем информационных систем здравоохране­ния. Трехуровневая архитектура ANSI / SPARC [8] обеспечивает хорошую иллю­страцию этого вопроса, выявляя три различных представления о данных: внутреннее

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

Рисунок 2.6 - Трехуровневая архитектура

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

деленные в каталоге «стандартный элемент данных» - рисунок 2.5. Наконец, факти­ческие файлы пациентов, которые фактически представляют собой транзакции си­стемы (т. е. записи данных в системе, которая документирует основные операции), генерируются динамически на основе их соответствующего определения «тип файла пациента».

Рисунок 2.7 - Диаграмма уровня сущностей базы данных

Изображение высокого уровня описанных сущностей представлено на рисунке

2.7. После заполнения сущности, идет взаимосвязь сущностей, которая представлена на рисунке 2.8.

83

Рисунок 2.8 - Диаграмма атрибутного уровня базы данных

Хотя имена атрибутов на диаграмме, как правило, не требуют пояснений, важно подчеркнуть компактный дизайн иерархической структуры стандартного файла пациента. Таблица «Std_Patient_File» позволяет определять любое количество древовидных структур, по одной на каждый «File_Type». Когда определенный файл должен быть заполнен для пациента, система автоматически сгенерирует его струк-

туру на основе стандартной структуры, найденной в таблице «Std_Patient_File», про­сто применяя фильтр к интересующему «File_Type_ID».

Другая сущность, для которой требуется краткое описание - это Item_Option_List. С помощью этой таблицы предлагается конечному пользователю (то есть врачу-специалисту) средства для объявления предварительно определенных значений для стандартного элемента данных. Таким образом, помимо чисел, текста, дат или рисунков, элемент данных может принимать в определенном файле пациен­та предопределенное значение из своего собственного «option_list». Это имеет осо­бое значение для статистического анализа исследований. Описанная схема базы данных обеспечивает гибкую модель для построения иерархических структур дан­ных, которые могут применяться не только для структурирования входных данных системы, но и для создания специальных данных, которые перегруппируют отчеты для исследовательских целей. Данные из разных стандартных входных файлов. Это представляет собой ценный инструмент для интеллектуального анализа историче­ских данных. Однако любой инструмент извлечения данных бесполезен, если общий словарный запас не обновляется с течением времени. Вот почему объект «Std_Item» нуждается в расширении, которое позволит связывать два или более элементов дан­ных, как разные термины, которые описывают одну и ту же концепцию. Таким об­разом, медицинские бригады смогут поддерживать семантическую линию данных терминов, содержащихся в общем словаре с течением времени. Это рассматривается как обязательное расширение предлагаемого шаблона проектирования, особенно для крупных интегрированных информационных систем здравоохранения. Другим возможным расширением в будущем может стать предоставление конечному поль­зователю более сложных запросов, т. е. возможность выражать условия фильтрации, связанные в любой последовательности с помощью AND и OR. Это может быть вы­полнено с использованием того же механизма структурирования, который использу­ется для стандартных файлов данных. Таким образом, один и тот же иерархический

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

1. Для указания содержимого отчета аналогично созданию стандартных вход­ных файлов;

2. Чтобы указать условия фильтрации отчета, в настраиваемой последователь­ности логических соединителей (например, и, или, нет). Это было бы возможно, например, путем определения стандартных типов элементов специального назначе­ния (в виде записей таблицы Std_item_type), по одному для каждого логического со­единителя. По соглашению, когда фильтр данных указывается в виде иерархической структуры, все дочерние элементы одного из этих узлов будут связаны соответ­ствующим логическим соединителем. Таким образом, пользователь сможет созда­вать сложные условные выражения, которые также могут быть сохранены в каче­стве пользовательских фильтров данных, просто сохранив их иерархическую струк­туру в таблице, как «Std_patient_file».

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