WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

загрузка...
   Добро пожаловать!

Pages:     | 1 || 3 |

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

Первая глава посвящена разработке унифицированной модели обмена данными в распределённых телемедицинских системах.

В силу медицинской специфики – медицинские центры работают практически независимо друг от друга – информационные системы, развёрнутые этими медицинскими центрами сложно будет объединить в централизованную сеть, и если используемые ими информационные системы объединить в сеть, эта сеть будет одноранговой: без выделенного координирующего центра. В таких сетях встаёт проблема маршрутизации, и создание информационной системы, способной эффективно работать в таких условиях, является важным шагом в построении единого медицинского информационного пространства.

Модуль Модуль Клиент Клиент Модуль Модуль Модуль Модуль Модуль Рис. 1: Меняющаяся система Поскольку в одноранговых сетях нет выделенного центра, то информацию о маршрутизации надо хранить либо на узлах сети, либо на клиенте. Однако при задании топологии системы в клиенте, он не сможет адаптироваться к изменениям системы (см. рис.

1), поэтому для повышения гибкости системы была предложена следующая схема маршрутизации (рис. 2): при обращении к сервису системы клиенту передаётся информация о расположении связанных сервисов, таким образом клиент может поддерживать топологию системы и в то же время всегда обладает информацией, необходимой для работы с системой.

Модуль Таблица Модуль2 — (Адрес) адресов Модуль3 — (Адрес) Пакет данных Клиент Модуль Рис. 2: Получение информации о маршрутизации от модулей системы Для передачи информации о маршрутизации в пакетах с данными, которыми обмениваются модули, протокол должен поддерживать метаданные: информация о маршрутизации не является частью бизнес-логики системы и не должна конфликтовать с основным содержимым пакетов данных. Структура передаваемой информации представлена на рис. 3.

Модуль 1 Идентификатор Пакет данных модуля Модуль 2 Адрес Метаданные Модуль 3 Описание Идентификатор метода... Метод Описание Данные Метод бизнес-процесса...

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

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

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

Наиболее перспективный путь в построении информационных систем телемедицины, что отмечено также и консорциумом HL7, ориентирован на недавно появившиеся технологии Web-сервисов. В основе комплексной технологии Web-сервисов лежат средства XML, на основе которых в свою очередь разрабатываются логические стандарты сообщений, реализуемые SOAP-средствами (Simple Object Access Protocol), которые в свою очередь реализуются описаниями WSDL и UDDI (Web Services Description Language, Universal Description Discovery and Integration).

Основные принципы разработки Web-сервисов для информационных систем решают большинство имеющихся в этой области проблем, в том числе и для систем телемедицины, и характеризуются следующими чертами:

• Модульность и совместимость систем;

• Универсальность и гибкость систем;

• Равноправие составляющих систему подсистем;

• Web-сервисы основаны на уже действующих стандартах.

Модульность является основой для разработки специфичных для разных предметных областей телемедицины (например, онкологии, энцефалографии) протоколов обмена и хранения данных. Модульность реализуется на основе технологии SOAP, являющейся открытым стандартом (на базе XML синтаксиса) и подразумевает дальнейшие SOAP/WSDL расширения.

Особенности применения протокола SOAP:

Сериализация. Кодировать в XML структурированные данные с использованием SOAP так же легко, как и данные простых типов (скажем, целого или строкового).

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

Межплатформенность. Протокол SOAP лучше всего подходит для получения webуслуги на обычном клиенте. Имеются наборы инструментов SOAP для различных языков программирования. Основная идея стандарта SOAP заключается в том, что сообщения должны быть закодированы в стандартизированном XML-формате. Можно сказать, что формат SOAP идеально подходит для технологии RPC (Remote Procedure Call – вызов удалённой процедуры), т.к. SOAP-сообщение содержит направляемые клиентом параметры и отсылаемую службой возвращаемую величину.

В качестве платформы приложения была выбрана.Net, в качестве протокола передачи данных – SOAP, диалект XML, т.к. сейчас XML пользуется большой популярностью и поддерживается большим количеством платформ, что вместе с простотой протокола облегчит реализацию клиента на различных платформах, что важно для мобильных решений, которые характеризуются использованием широкого спектра оборудования.

SOAP – это открытый протокол, ориентированный на структурирование древовидной информации. Поскольку это текстовый протокол, в качестве транспортного протокола для обмена сообщений в формате SOAP обычно выбирается HTTP, доступный практически при любом интернет-соединении (другие протоколы могут быть запрещены провайдером интернет-услуг). Таким образом, выбор в пользу HTTP и SOAP повышает доступность сервиса телемедицинских консультаций.

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

Архитектура системы Уровень Уровень данных Уровень логики представления Модуль 1 Медицинские Интерфейс данные пользователя Подсистема Модуль безопасности Связь с системой Мультимедийные Модуль данные Рис. 4: Архитектура системы Архитектура системы – трёхзвенная. Система разделяется на три уровня (рис. 4):

уровень представления (клиент), уровень логики (сервер приложений) и уровень данных (база данных). Уровень логики – это связующее звено между уровнем представления и уровнем данных, в нашей системе выполнен с использованием веб-сервисов. В качестве сервера баз данных используется система управления базами данных MySQL Server 4.0.

В трёхуровневой модели сервер баз данных отвечает только за хранение данных и обработку запросов. Характерные для современных баз данных возможности по созданию хранимых процедур, как правило, не используются. С одной стороны это связано с тем, что на сегодняшний день язык описания хранимых процедур не стандартизован, а значит, использование хранимых процедур приведёт к зависимости от конкретного производителя СУБД. С другой стороны, использование хранимых процедур означает наличие бизнеслогики на стороне базы данных, что противоречит общему принципу выделения специального компонента, отвечающего за её выполнение. Клиент отвечает за сценарий общения пользователя с системой, за ввод данных пользователем и представление пользователю ответа сервера. Сервер приложений (веб-сервисы) реализует бизнес-логику работы с базой данных: добавление и удаление данных в базе, осуществляет разделение прав пользователей системы. Сервер баз данных только обрабатывает SQL-запросы от сервера приложений.

Структуры данных Для контроля прав доступа в заголовке SOAP-конверта передаётся информация о пользователе и сессии следующего вида:

class MessHeader { CUser User;

CSession Session;

string ProcInst;

CService[] Services;

} User и Session – отдельные структуры для данных о пользователе и сессии. ProcInst – ссылка на файл XSLT-преобразования, которое используется для представления пользователю полученных данных. Services – массив с описанием сервисов, предоставляемых системой, используется для обнаружения сервисов и навигации.

Данные о пользователе.

class CUser { int ID;

string Login, Pass;

} ID – численный идентификатор пользователя в системе. Login и Pass – имя пользователя и пароль соответственно для аутентификации пользователя по паролю.

Данные о сессии.

class CSession { int Role;

ulong ID;

} Role – численный идентификатор роли пользователя в системе; определяет уровень доступа пользователя. ID – идентификатор сессии.

Данные о сервисе, предоставляемом системой.

class CService { string Name, Desc, Href;

CMethod[] Methods;

} Name – строковый уникальный идентификатор сервиса, используемый в протоколе SOAP. Desc – описание назначения сервиса для пользователя. Href – адрес сервиса. Methods – массив описаний методов, предоставляемых сервисом.

Данные о методе, предоставляемом сервисом.

class CMethod { string Name, Desc;

} Name – имя метода. Desc – описание назначения метода.

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

class CCase { int ID;

DateTime RegDate;

CUser Creator, Expert;

int Typ, Urgent, Status, ProfileID;

CPatient Patient;

CPhysData PhysData;

CAnamnes Anamnesis;

CSystems Systems;

CMaterial[] Materials;

CCure Cure;

} ID – идентификатор клинического случая. RegDate – дата регистрации запроса на консультацию в системе. Creator – пользователь-создатель запроса, Expert – консультант, отвечающий на запрос. Typ – поле, отражающее характер консультации; предусмотренные значения: простая, именная, предварительная. Urgent – срочность консультации (обычная, срочная, экстренная). Status – статус консультации, меняющийся в процессе её обсуждения:

черновик, опубликованная, приписанная эксперту, закрытая. ProfileID – профиль консультации, раздел медицины, к которому она относится. Patient – общие данные о пациенте. PhysData – физикальные данные. Anamnesis – анамнез (перенесённые заболевания). Systems – состояние систем организма. Materials – массив с данными о прикреплённых материалах с результатами медицинских исследований. Cure – получаемое пациентом лечение.

Данные о пациенте.

class CPatient { int ID;

string FName, MName, LName;

int Gender;

DateTime BirthDate;

string Oms, SocStatus, Profession, Address, InfoSrc;

} ID – уникальный идентификатор пациента в системе, FName, MName, LName – имя, отчество, фамилия пациента, Gender – пол пациента, BirthDate – дата рождения, Oms – номер полиса обязательного медицинского страхования, SocStatus – социальный статус (рабочий, учащийся, пенсионер), Profession – профессия, Address – место жительства, InfoSrc – место получения основной клинической информации.

Общефизикальные данные – базовая информация о состоянии организма пациента.

class CPhysData { int Pulse, Height, Weight, Freq, Pressure1, Pressure2;

float Temp;

} Пульс (Pulse), рост (Height), вес (Weight), частота сердцебиения (Freq), артериальное давление (Pressure1/Pressure2), температура (Temp).

Анамнез – информация о ранее перенесённых заболеваниях.

class CAnamnesis { string DAnamnesis, LAnamnesis, AAnamnesis, FAnamnesis, PAnamnesis;

string Complaints, SocDisease, Other;

} DAnamnesis – анамнез заболевания, LAnamnesis – анамнез жизни, AAnamnesis – аллергологический анамнез, FAnamnesis – семейный анамнез, PAnamnes – профессиональный анамнез, Complaints – жалобы пациента, SocDisease – социальные заболевания, Other – дополнительные примечания.

Состояние систем организма пациента.

class CSystems { string PresState, Nerv, Skin, Resp, Heart, Gastroint, Urogen, Locomotive;

string LocalStatus;

} PresState – объективный статус, Nerv – нервная система, Skin – кожа и видимые слизистые, Resp – дыхательная система, Heart – сердечно-сосудистая, Gastroint – желудочнокишечная, Urogen – урогенитальная система, Locomotive – опорно-двигательная, LocalStatus – локальный статус.

Уровень данных Указанные структуры данных поддерживаются на всех уровнях системы и практически без изменений представлены в базе данных (рис. 5). Таблицы WebServices и WebMethods отвечают за хранение информации о расположении модулей системы и о предоставляемых ими методах, таблицы Users, Sessions, Role отвечают за поддержку разделения прав пользователей.

Рис. 5: Структура базы данных Уровень логики Система состоит из следующих модулей, реализованных в виде веб-сервисов:

TMSCoreLib. В этой библиотеке собраны функции и типы данных, часто используемые в других сервисах. Эти типы данных (классы) инкапсулируют часто используемые структуры, такие как данные аутентификации (CUser, CSession), структура заголовка сообщений (MessHeader), структуры поддержки распределённости системы (CService, CMethod).

AccountManagement. Административный сервис, позволяющий администратору получать список зарегистрированных в системе пользователей (List), просматривать (Get), редактировать (Edit) и удалять (Delete) учётные записи пользователей.

Pages:     | 1 || 3 |






© 2011 www.dissers.ru - «Бесплатная электронная библиотека»