Разработка типовой ИТ/ИС архитектуры медицинского центра

Размещено на http://www.allbest.ru/

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ

«НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ

«ВЫСШАЯ ШКОЛА ЭКОНОМИКИ»

Факультет бизнеса и менеджмента

Выпускная квалификационная работа

по направлению подготовки 38.04.05 «Бизнес-информатика»

образовательная программа «Бизнес-информатика»

Разработка типовой ИТ/ИС архитектуры медицинского центра

Абалмасова Татьяна Сергеевна

Научный руководитель

доктор технических наук, профессорЮ.А. Зеленков

Москва, 2020



ВВЕДЕНИЕ

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

Так количество пользователей сети Интернет в 2020 году в мире стало больше на 7 % по сравнению со значениями на январь 2019 года, а это 4,54 миллиарда человек[2], прирост составил порядка 300 миллионов человек.

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

Возможность использования больших данных в сфере здравоохранения подтверждается тем фактом, что к 2020 году мировое здравоохранение имеет в своем арсенале данных на 2 314 ЭБ [3]. Стоит отметить, что в количество медицинских данных с каждым годом удваивается [4].

С помощью реферативной базы данных Scopus был произведен анализ публикаций. Поиск производился по ключевым словам “medicalbigdata”, были исключены публикации, основная тема которых значится как “medicine”. Исключение явно медицинских статей сделано с целью ясного видения картины развития медицинских данных. На рисунке 1 представлен результат анализа. Это свидетельствует об актуальности работы в области больших данных в здравоохранении. Из графика видно, что рост числа публикаций начался с середины 1980-х годов. И за последние 10 лет наблюдается стабильный рост публикаций на интересующую тему. Важность темы в Scopus у статей по подобным темам находится на уровне выше 90 процентиль.

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

Беря во внимание статистику по росту объемов медицинских данных, а также факт жизненной важности правильной их интерпретации, очевидно, что существует потребность в разработке типовой ИТ/ИС архитектуры медицинского центра. Ввиду того, что архитектура будет составлена с учетом максимально широких исполнительных функций, будет поддерживаться ее типовой формат.

Рисунок 1 -- Публикационная активность в базе данных Scopus

Зарубежными авторами написано немалое количество работ, посвященных описанию ИТ/ИС архитектур медицинского центра (учреждения). Например, в [5] рассматривается создание архитектуры, удовлетворяющей требованиям системы здравоохранения Южной Африки. Созданная структура опирается на две точки зрения, а именно на инженерную и экономическую перспективы для обеспечения целостного понимания. Однако интерес российских авторов замечен не в столь яркой форме (26 публикаций против лидеров данной тематики -- США, 1 041 публикация; и Германии, 281 публикация).

Согласно классификации DesignScience выпускная квалификационная работа будет решать проблему отсутствия универсального решения ИТ/ИС архитектуры медицинского центра [45]. В результате выполнения выпускной квалификационной работы будет создан артефакт -- ИТ/ИС архитектура медицинского центра. Данный артефакт согласно стратегии организационного дизайна, будет классифицирован, как ИС, способствующая повышению способности обрабатывать информацию[46].

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

1. Выявление теоретических основ проблемы.

2. Определение архитектуры предприятия, ИТ/ИС архитектуры предприятия.

3. Определение типовой ИТ/ИС архитектуры медицинского центра.

4. Описание общепринятых методик, используемых при разработке архитектуры предприятий.

5. Выбор одной методики для достижения цели работы и описание ее основных компонентов.

6. Разработка типовой ИТ/ИС архитектуры медицинского центра.

Для полного и точного погружения в тему исследования планируется дать определения основным терминам, используемым в работе. Для разработки ИТ/ИС архитектуры медицинского центра будет необходимо рассмотреть общепринятые методики для этого подходящие. Выбрать одну наиболее удовлетворяющую работе с особенностью медицинских данных методику. На данном этапе предполагается, что разработка будет производиться с использованием методики TOGAF с применением языка проектирования ArchiMate. После окончательного выбора удовлетворяющей методики будет необходимо описать структуру и компоненты методики, правила ее использования. Затем можно будет приступать к разработке типовой ИТ/ИС архитектуры медицинского центра.

В первой главе работы будут даны основные определения терминов, используемых в работе. А именно: архитектура предприятия, ИТ/ИС архитектура предприятия, типовая архитектура предприятия. Будут описаны основные общепринятые методики разработки архитектуры предприятия.

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

В третьей главе работыпланируется описание процесса разработки типовой ИТ/ИС архитектуры медицинского центра.

При написании выпускной квалификационной работы будут использованы различные источники литературы:

· энциклопедии -- для терминов;

· сайты вендор-разработчиков основных общепринятых методик разработки архитектуры предприятия;

· научные статьи зарубежных и российских авторов.

ГЛАВА 1. ТИПОВАЯ ИТ/ИС АРХИТЕКТУРА ПРЕДПРИЯТИЯ

1.1 Определение архитектуры предприятия

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

Консорциум SSC представляет архитектуру предприятия как связующее звено между миссией организации, целями и задачами, а также рабочими процессами, ИТ и ИС архитектурой, необходимой для выполнения бизнес-процессов предприятия [6]. Считается, что качественно составленная архитектура и соответствующая ей документация позволяют проводить эффективное внедрение и усовершенствование архитектуры. Для разработки архитектуры предприятия существует большое множество архитектурных моделей.С одной стороны может показаться, что каждая из представленных методологий описывает аналогичные структуры и элементы, однако, каждая методология отвечает своим нуждам и принципам.

Согласно международному стандартуISO/IEC/IEEE 42010 под «архитектурой предприятия» понимаются основополагающие понятия и свойства системы в условиях ее окружающей среды, воплощенные в ее элементах, отношениях, принципах ее проектирования и развития [7].

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

GEAO-- GlobalEnterpriseArchitectureOrganization -- Всемирная организация корпоративной архитектурыпредставляет термин «архитектура предприятия» как возможность изображения цельной картины деятельности предприятия. Благодаря различным уровням абстракции, на которых разрабатывается архитектура предприятия, удается получить и иметь возможность работать с моделями, руководствами и политиками, необходимыми для дальнейшей разработки уровней абстракции архитектуры предприятия [8].

Определение, данное TheOpenGroup: «архитектура предприятия -- это способ понимания различных элементов, которые в совокупности составляют предприятие, и то, как эти элементы взаимосвязаны».

META Group предлагает следующее определение: «архитектура является одновременно некоторым структурированным описанием информационных технологий предприятия и его информационных технологий (т.е. конечным результатом, включающим определенные артефакты -- стандарты, утверждения, касающиеся общего видения, архитектурные документы), процессом создания и обновления артефактов архитектуры и группами людей, вовлеченных в этот процесс» [9].

Все определения понятия «архитектуры предприятия» имеют общие черты, и могут быть объединены следующим образом. Это совокупность информационных составляющих, определяющих:

· структуру бизнеса;

· технологии, которые необходимы, чтобы поддерживать деловые операции;

· информацию, которая необходима для ведения этого бизнеса;

· связи между этими объектами;

· процессы преобразования.

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

1.2 Методологии разработки архитектуры предприятия

«Методология -- это учениео научном методе познания, принципы испособы организации теоретической и практической деятельности, совокупность методов, применяемых в какой-нибудь науке» [10]. Методология представляется словно подход, следуя которому удастся решить поставленную задачу. Отметим, что в данной области работы, а именно архитектура предприятия, методология представляется сводом инструкций. Они могут быть представлены в различном виде и служат поэтапным руководством для разработки чего-либо [11].

В исследовании [12] сравниваются наиболее распространенные методологии разработки архитектуры предприятия. В данной работе будут описаны три из них:

· TOGAF (The Open Group Architectural Framework);

· Gartner;

· EAP (EnterpriseArchitecturePlanning).

Некоторые методологии представляют собой метамодели, так называемые рамочные методологии. Пример такой методологии -- модель Захмана. Другой тип существующих методологий -- методологии, которые представляют подходы, целью которых является создание описания архитектуры предприятия. Также существуют методологии, описывающие способы и подходы к проектированию архитектурыпредприятия. Примером такой методологии -- TOGAF. При практическом применении методологий разработчики часто сталкиваются с тем, что один тип методологий не может в полной мере отвечать необходимым требованиям в виду высокой индивидуальности каждой работы. Под индивидуальностью каждой работы подразумевается конкретная отрасль работы предприятия, ее окружающая среда, внутренние и внешние ресурсы и другое. Из-за этого практикуется использования смешанного подхода с адаптацией его под фактические нужды разработки [8].

1.2.1 TOGAF

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

В методологии TOGAF архитектура предприятия представляется в четырех разрезах:

1) бизнес -- описывает бизнес-процессы предприятия, которые необходимы к выполнению для достижения бизнес-цели;

2) приложения -- представляет картину используемых бизнесом приложений, которые необходимы в процессе выполнения бизнес-процессов;

3) данные -- описывает строение хранилищ данных предприятия, необходимых для поддержания работы приложений, которые в свою очередь необходимы для осуществления протекания бизнес-процессов;

4) технологии -- представляет вид программных средств и оборудования, необходимых для поддержания эффективной работы бизнес-процессов для достижения бизнес-цели[13].

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

ADM представляет собой набор инструкций, который необходим во времяразработки и реализацииархитектуры предприятия.Разработка архитектуры предприятия включается в себя восемь фаз, составленных в цикл с блоком контроля (рисунок 2).

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

Рисунок 2 -- Метод разработки архитектуры предприятия ADM, методология TOGAF[12]



Следующий этап разработки архитектуры предприятия -- Фаза А, первая фаза из цикличной цепочки. На этом этапе формируется видение архитектуры предприятия (в английской литературе -- ArchitectureVision). Спомощью созданного артефактана основе стратегии бизнеса выделяются цели создания разрабатываемой архитектуры предприятия. Также создается описание первой базовой среды организации. Если у организации нет четкого видения задач, то команде разработчиков необходимо помочь бизнес обозначить основные задачи. На выходе с этой фазу формируется документ «Архитектурное задание», известный в английской литературе как StatementofArchitecturalWork. В нем описаны ограничения действия архитектуры предприятия, ее условия, а также план по разработке.

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

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

Завершающий этап проработки архитектуры метода ADM -- фаза D, создание технологической архитектуры. По аналогии с предыдущими фазами, работа производится на основе материалов, разработанных на фазе А.Технологическая архитектура служит основанием общего профиля информационных технологий организации, разделяя ответственность с архитектурой приложений, которая разрабатывается на предыдущем этапе. С помощью технологической архитектуры определяется набор структурных стандартов, требований, принципов, которые помогают поддерживать исправную работу ИТ сервисов, а именно информационных систем, операционных систем, электронной почты, взаимодействие внутренних баз и каталогов.

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

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

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

Следующий этап, фаза G -- переход к формированию системы по контролю преобразованиями. Выделяется и описывается связь между управляющей архитектурой (собственно TOGAF) и организацией, занимающейся управлением проекта (например, PMBOK). В результате выполнения фазы формируются решения по преобразованиям, которые являются совместимыми с архитектурой.

В течение фазы Н производится управление изменением архитектуры. Это происходит с помощью поставки ранее спроектированных решений.

1.2.2 Gartner

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

Согласно методологии Gartner проект по разработке архитектуры предприятия должен начинаться с формулирования основного вида деятельности предприятия. В то время как согласно другим методологиям первый этап -- это обозначение построение архитектуры предприятия в формате ASIS. Такой подход объясняется необходимостью определения плана развития предприятия и видения соответствия текущей деятельности предприятия поставленному плану.

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

1.2.3 EAP

EAP (EnterpriseArchitecturePlanning) -- это методология разработки архитектуры предприятия, в основе которой лежит два этапа.

1) Этап проектирования архитектуры предприятия, в ходе которого создается архитектура, способная обеспечить основу для работы бизнеса. Архитектура строится на основе полных данных о бизнесе.

2) Этап создания плана реализации архитектуры предприятия, который будет описывать процесс ее реализации.

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

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

1) Начальное планирование. Определение основных необходимых для проектирования компонентов, а именно: команда, методология и инструментарий, рабочий план, презентация заказчикам. Все эти компоненты определяются исходя из видения и целей организации.

2) Моделирование бизнес-структуры организации: организационная структура.

3) Разработка функционального профиля организации: составление бизнес-модели.

4) Представление существующих системных приложений и технологий.

5) Вырабатывание архитектуры существующих потоков данных.

6) Вырабатывание архитектуры существующих приложений.

7) Вырабатывание существующей технологической архитектуры.

8) Разработка плана по реализации разработанной архитектуры предприятия: возможности, перспективы, факторы успеха, пошаговый план перехода.

9) Составление отчета о выполненной работе, презентации.

10) Реализация разработанной архитектуры предприятия согласно выработанному плану [15].

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

1.3 Определение ИТ/ИС архитектуры предприятия

Согласно ЮНЕСКО, понятие информационные технологии формируются следующим образом. «Это комплекс взаимосвязанных, научных, технологических, инженерных дисциплин, изучающих методы эффективной организации труда людей, занятых обработкой и хранением информации; вычислительную технику и методы организации и взаимодействия с людьми и производственным оборудованием, их практические приложения, а также связанные со всем этим социальные, экономические и культурные проблемы» [16].

Соответственно, под ИТ архитектурой предприятия понимается комплекс методов и способов для разработки, реализации элементов ИТ-инфраструктуры организации, а также поддержание их совместной бесперебойной работы [17]. В настоящее время дляописание бизнес-деятельности предприятия в литературе описываются следующие архитектуры: технология «клиент-сервер», Intranet-технология, CASE-технология[18].

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

Intranet-технология была разработана из-за недостатка клиент-серверной технологии, а именно недостаточная скорость передачи данных. В Intranet-технологии эта проблема решается путем использования определенных стандартов [20]:

· HTTP -- для обмена данными;

· FTP -- для передачи файлов;

· HTML -- дляразметки гипертекста.

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

В [16] дается следующее определение понятия информационная система. Это «комплекс вычислительного и коммуникационного оборудования, программного обеспечения, лингвистических средств и информационных ресурсов, который обеспечивает их сбор, хранение, актуализацию, распространение и обработку в целях поддержки какого-либо вида деятельности».

Соответственно, под ИС архитектурой будет пониматься концепция, которая определяет бизнес-модель, общую структуру бизнеса, функции, выполняемые бизнесом, и отношения между каждым из компонентов системы [19].

ИС архитектура является основой и подходящим способом для разработки различных систем автоматизации предприятия. Комплекс возможности централизации в хранении информации и распределения связей создает перспективы для разработки корпоративных ИС [18].



1.4 Типовая ИТ/ИС архитектура медицинского центра

Для выполнения поставленной задачи данной работы, а именно разработки типовой ИТ/ИС архитектуры медицинского центра, следует определить на начальном этапе, что же значит понятие «типовой». Согласно словарю Ожеговаприлагательное «типовой -- соответствующий определенному образцу, типу, стандартный»[21]. Иными словами, объект считается типовым, если он удовлетворяет заранее определенным правилам, стандартам и нормам.

Ввиду того, что разрабатываемая архитектура планируется в среде личных данных о пациентах, их медицинских обследованиях и диагнозов, чрезвычайно важно, чтобы архитектура удовлетворяла требованиям безопасности, передачи данных. Медицинские данные, генерируемые высокотехнологичным оборудованием в результате проведения анализов и исследований, имеют разную структуру. Это могут быть графики (ЭКГ исследование), изображения (УЗИ и рентгеновские снимки), численные значения (результаты анализов крови) и многое другое. С целью формализации введения, хранения, передачи и использования медицинской информации были разработаны и введены международные стандарты: DICOM, HL 7, IHE; а также ГОСТы, например: «ГОСТ Р ИСО 12052-2009 Информатизация здоровья. Цифровые изображения и связь в медицине (DICOM), включая управление документооборотом и данными. Описана структура стандарта DICOM, даны определения основным понятиям.ГОСТ Р ИСО 17432-2009 Информатизация здоровья. Сообщения и обмен информацией. Веб-доступ к постоянным объектам DICOM. Определяет принципы доступа к DICOM объектам при помощи интернет соединения. ГОСТ Р 56849-2015/ISO/TR 17791:2013 «Информатизация здоровья. Руководство по стандартам безопасности медицинского программного обеспечения».



1.4.1 Стандарт электронного обмена текстовыми медицинскими документами HealthLevelSeven

«HealthLevelSeven (HL7) -- это стандарт обмена, управления и интеграции электронной медицинской информации. Стандарт HL7 по форме работы аналогичен открытым системам (opensystemsinterconnection - OSI) с их семью уровнями взаимодействия» [38]. Благодаря использованию модели передачи медицинскими документами HL7 медицинские и офисные устройства, которые локализуются в больничной одной сети, могут взаимодействовать друг с другом. Модель HL7 дифференцирует уровнивзаимодействия устройств, каждый из которых выполняет свои функции.

«Стандарт HL7 поддерживает выполнение таких задач как [38]:

· структурирование передаваемых данных;

· возможности проектирования систем;

· достижение согласованности передач;

· безопасность;

· идентификация участников;

· доступность».

1.4.2 Стандарт электронного обмена диагностическими изображениями DigitalImagingandCommunicationinMedicine

В 1980-хгодахбылразработанстандарт DICOM (Digital Imaging and Communication in Medicine).Данный стандарт призван стандартизировать процессы создания, хранения и передачи диагностических изображений. Современной медициной генерируется огромное количество информации в результате выполнения диагностических исследований. К таким видам исследований относятся все исследования на высокотехнологичном оборудовании: МРТ, КТ, маммограф, рентген и другие.

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

1.4.3 Интеграция ведомственного здравоохраненияIntegratingtheHealthcareEnterprise

Благодаря IHE обеспечивается полный консолидированный сбор медицинской информации, который позволяет совершать обмен полученной информацией между устройствами в сети медицинского центра. Для интеграции разнообразных ИС, которые в своей основе имеют различные стандарты, используют разные типы информации, профили стандарта IHE внедряются в программное обеспечение устройств[22]. Данные профили внедряют и фиксируют правила для описанных выше стандартов DICOM и HL7, а также многих других протоколов передачи данных, медиа и информации в медицине. Таким способом делается возможным создание типовых процессов по работе с разрозненными ИС.

Согласно методическим рекомендациям, разработанным Департаментом Здравоохранения Москвы, выделяются следующие требования, необходимые к соблюдению при создании ИТ архитектуры [22]:

· применение только зарегистрированных, как медицинское изделие, по Законодательству РФпрограммных средств;

· применение программного обеспечения, с возможностью поддержки международных стандартов по передаче, хранению и использованию медицинских данных (стандарты DICOM, HL7, IHE);

· соответствие требований Законодательства в аспекте информационной безопасности.

Как было сказано ранее в п. 1.2.3, в результате анализа существующих методологий разработки архитектуры предприятия, для достижения задач выпускной квалификационной работы была выбрана методология TOGAF, разработанная консорциумом TheOpenGroup.Данный выбор так же подтверждается исследованием [23], согласно которому методология TOGAF позволяет лучше всего разрабатыватьоснованную на медицинских знаниях архитектуру предприятия. Это связано с четким делением в TOGAF деления архитектуры на четыре уровня, которые обеспечивают прогрессивный процесс разработки модели. Эти слои отображают поведение всех компонентов и отношения между ними. Четырехуровневая модель обеспечивает лучшее понимание элементов ИТ архитектуры и бизнес-процессов. TOGAF также предоставляет проверенные методы, общий словарный запас для понимания информации в организации, знания об организации или фирме, позволяющие менеджерам или системе принимать более обоснованные решения. Это также улучшает качество обмена данными, повышает надежность решений и упрощает обслуживание.

В первой главе выпускной квалификационной работы были подробно рассмотрены основные определения, связанные с работой, а именно архитектуры предприятия, методологии, ИТ архитектуры и ИС архитектуры. Были тщательно рассмотрены широко распространенные методики для разработки архитектуры предприятия (TOGAF, Gartner, EAP). Для каждой методики приведено поэтапное описание разработки архитектуры предприятия. Также в первой главе работы было дано определение типовой ИТ/ИС архитектуры медицинского центра, что является чрезвычайно важным для данной работы. Т.к. будет сигнализировать об эффективности достигнутого результата. Одним из критериев универсальности архитектуры медицинского центра выдвинуто требование соответствия международным стандартам по работе с медицинскими данными (DICOM, HL7, IHE). Также приведена их краткая характеристика. Для дальнейшей работы над разработкой ИТ/ИС архитектуры медицинского центра была выбрана методология TOGAF.



ГЛАВА 2. РАЗРАБОТКАИТ/ИС АРХИТЕКТУРЫ С ПОМОЩЬЮ МОДЕЛИ TOGAF

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

2.1 Обзор слоев, необходимыхдля создания ИТ/ИС архитектуры

Бизнес

На данном этапе используетсяпредварительная фаза и фаза видения архитектуры методологии TOGAF. На предварительном этапе объясняются архитектурные принципы, которые будут реализованы при проектировании архитектуры предприятия в информационных системах медицинского центра. Архитектурное видение объясняется разработкой высокоуровневого видения желаемых возможностей и ценностей для бизнеса, которые могут быть движущей силой разработки дизайна корпоративной архитектуры в информационных системах медицинского центра. Для выполнения этого этапа должны выполняться следующие шаги[24]:

1) определение заинтересованных сторон и их требований к бизнесу;

2) описание бизнес-целей и драйверов бизнеса;

3) оценка объема и возможностей;

4) разработка архитектурных принципов и видения.

Бизнес-процессы

На этапе построения бизнес-архитектуры проводится согласование между бизнес-архитектурой, которая будет построена, и целями больничного бизнеса. Это можно сделать, следуя по данным шагам [24]:

1) выбор эталонной модели и инструментов;

2) описание существующей бизнес-архитектуры;

3) описание целевой бизнес-архитектур.

Приложения и данные

На данном этапе необходимо описать, какие требуются информационные средства и какие потоки данных им сопутствуют для достижения бизнес цели медицинского центра. Происходит интеграция между данными, которые должны быть достигнуты, и приложением, которое будет построено так, чтобы оно могло соответствовать принципам и видению архитектуры и обеспечивать представление бизнес-архитектуры. Необходимо выполнение следующих шагов [24]:

1) выбор эталонной модели и инструментов;

2) описание имеющейся архитектуры данных;

3) описание целевой архитектуры данных;

4) описание имеющейся архитектуры приложений;

5) описание целевой архитектуры приложений.

Технологические решения

На этапе Архитектуры технологий, как будет развиваться архитектура технологий при выполнении бизнес-процессов в информационной системе больницы. Это можно сделать, следуя по данным шагам [24]:

1) Выберите эталонные модели и инструменты

2) Опишите базовую технологию архитектуры

3) Опишите целевую технологию архитектуры

2.2 Язык моделирования ArchiMate для разработки ИТ/ИС архитектуры

Стандарт ArchiMate -- это международный графический язык для моделирования корпоративных архитектур. Этот язык визуализации предлагает единый и целостный метод описания, анализа и визуализации архитектур. Он отличается от других языков моделирования, таких как UML или BPMN, тем, что он более концептуален и менее сфокусирован на деталях. Это позволяет понять структуры и взаимосвязи бизнес-процессов, организационных структур, информационных потоков и технической инфраструктуры.

В ArchiMate существует два базовых понятия: «элемент» и «отношение». Именно на использовании этих блоков строится архитектура предприятия или его частей. Основные понятия наглядно представлены на рисунке 3.Важный нюанс, который необходимо отметить в первую очередь -- это особенность языка, заключающаяся в следующем. При описании архитектуры предприятия в обязательном порядке используется три элемента:

· активная структура;

· поведение, совершаемое активнойструктурой;

· пассивнаяструктура, над которой собственно совершается действие активной структурой.

Данные понятия представлены на рисунке 4 в качестве аспектов. В рамках взаимодействия со слоями добавляется аспект мотивации.

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

Поведение: представляет поведение, осуществляемое субъектами (процессами, функциями, событиями и услугами).

Активная структура: представляет структурные элементы, связанас бизнес-субъектами, компонентами приложений и устройствами, которые на самом деле показывают поведение; т.е. субъекты деятельности.

Пассивная структура: представляет объекты, на которых основано поведение. Обычно это информационные объекты на бизнес-уровне и объекты данных на прикладном уровне. Но они также могут быть использованы для отображения физических объектов.



Рисунок 3 -- Элементы и отношения фреймворкаArchiMate[25]

Язык моделирования ArchiMate состоит из трех основных уровней: уровня бизнеса, приложений и технологий. Поддерживающими слоями, необходимыми для разработки трех основных являются слои описания стратегии, производства (мотивации) и реализации и миграции. Таким образом стандарт ArchiMateв общем случае включает в себя 6 слоев (рисунок 4).

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

Слой «Стратегия» описывает бизнес-стратегию организации. Проектирование данного слоя буде словно отвечать на вопрос «Как мне справиться с этим, какие люди и ресурсы необходимы для осуществления изменений?».

Слой «Бизнес» отображает бизнес-услуги, предлагаемые клиентам. Они реализуются в организации через бизнес-процессы, которые выполняются деловыми партнерами.

Слой «Приложение» отображает службы приложений, которые поддерживает компания, и приложения.



Рисунок 4 -- СлоиArchiMate[25]

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

Слой «Производство»: физические элементы могут быть добавлены к технологии моделирования физических устройств, материалов и распределительных сетей.

Слой «Реализация и миграция» позволяет моделировать управление проектами и портфелями, анализировать разрывы, а также планировать переход и миграцию.

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

2.3 Соответствие ArchiMate методологии TOGAF

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

И TOGAF, и ArchiMateсоответствуют базовым концепциям архитектуры предприятия, определенным в стандарте ISO / IEC 42010. Этот стандарт описывает такие понятия, как заинтересованная сторона, проблемы, точки зрения и вид. Это элементы, которые важны как для TOGAF, так и для ArchiMate.

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

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

В компонентах, описанных в TOGAF, и компонентах, включенных в ArchiMate, довольно много совпадений и сходств. На высоком уровне, оба делят архитектуру предприятия на уровни: в TOGAF есть бизнес, информационные системы (данные и приложения) и технологические архитектуры, в то время как в ArchiMate -- бизнес, прикладной и технологический уровни (уровень приложений включает в себя данные и домен приложения).

Архитектурному процессу TOGAF полностью соответствует язык проектирования ArchiMate (рисунок 5).

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

Элементы стратегии и мотивации языка моделирования ArchiMate могут использоваться для поддержки этапов TOGAF ADM «Управление требованиями», «Предварительное представление и архитектура», которые определяют бизнес-цели высокого уровня, архитектурные принципы и первые бизнес-требования. Они также имеют отношение к этапу управления изменениями архитектуры TOGAF ADM, поскольку этот этап связан с изменением требований.

Рисунок 5 -- Метод разработки архитектуры предприятия ADM, методология TOGAF[26]

Элементы реализации и миграции языка моделирования ArchiMate поддерживают внедрение и миграцию архитектур на этапах «Возможности и решения», «Планирование миграции» и «Управление внедрением» TOGAFADM.

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

Особое внимание было уделено четырем слоям: бизнеса, бизнес-процессов, архитектура приложений и технологическая архитектура. Это сделано для того, чтобы углубиться в область знаний, необходимой для дальнейшей разработки типовой ИТ/ИС архитектуры медицинского центра -- выполнения поставленной цели выпускной квалификационной работы.

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

Стоит дополнительно отметить, что слои ArchiMate предельно точно соответствуют слоям TOGAF. Это сделает возможным точное следование методологии TOGAF при использования данного языка моделирования.

В виду этого, было решено, что дальнейшая работа над разработкой ИТ/ИС архитектуры медицинского центра будет производиться с помощью инструмента ArchiMate, который также находится в свободном скачиваемом доступе в сети Интернет с официального сайта разработчика.



ГЛАВА 3. ТИПОВАЯ ИТ/ИС АРХИТЕКТУРА МЕДИЦИНСКОГО ЦЕНТРА

TOGAF охватывает четыре основных уровня архитектуры предприятия, как показано ниже [27]:

Первый уровень -- бизнес архитектурный слой: считается высшим уровнем архитектору предприятия. Целью этой архитектуры является распознавание и описание областей деятельности, направлений деятельности и обязанностей предприятия.

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

Третий уровень -- уровень архитектуры информационной системы (данных): он отвечает за описание потоков информации, логических моделей данных и физических моделей.

Четвертый уровень --технологическая инфраструктура архитектурного слоя: техническое задание и технические стандарты моделей, которые следует учитывать на предприятии.

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

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

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

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

3.1 Описание результатов деятельности медицинского центра

В процессе разработки ИТ/ИС архитектуры медицинского центра определилось несколько характерных для данной отрасли особенностей. Они повлияли на определение подходов к описанию процессов следующим образом.

1) Наличие пациентоориентированного подхода. Это порождает меж функциональную деятельность бизнес-процессов при ведении пациентов.

2) Матричная система управления. Проявляется подчинение двух типов: административного и функционального.

3) Чрезвычайно вариативный и высокий уровень гибкости бизнес-процессов. Это вызвано индивидуальным подходом к ведению каждого отдельного пациента.

4) Подчиненность установленным требованиям и регламентам в процессе осуществления основной деятельности (лечение пациентов) и документооборота.

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

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

Существует четыре вида медицинской помощи согласно Федеральному закону от 21.11.2011 №323-ФЗ «Об основах охраны здоровья граждан в Российской Федерации» [28]:

1) «первичная медико-санитарная помощь»;

2) «специализированная, в том числе высокотехнологичная, медицинская помощь»;

3) «скорая, в том числе скорая специализированная, медицинская помощь»;

4) «паллиативная медицинская помощь».

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

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

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

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

4) Круглосуточно в пределах физических границ медицинского центра.

Стоит отметить, что в [29] сказано, что для оказания медицинской помощи могут быть использованы телемедицинские технологии. Что чрезвычайно важно для развития ИТ/ИС архитектуры медицинского центра. Ведь именно в процессе использования телемедицинских технологий генерируется большое количество данных -- результатов исследований, которые требуют корректного ввода, хранения и передачи внутри и меж больничной сети.

В процессе анализа ряда разработок ученых по смежной области [30-33] было выделено пять основных видов деятельности:

· медицинская;

· фармацевтическая;

· научно-исследовательская и образовательная;

· управленческая;

· вспомогательная.

На рисунке 6 представлены основные виды деятельности медицинского центра. Данные виды деятельности могут быть адаптированы под потребности любой конкретной медицинской организации. При построении архитектуры бизнес-функций медицинского центра с помощью нотификации ArchiMate были использованы следующие элементы и инструменты: группировка объектов (grouping); бизнес-функция (businessfunction); объединяющий элемент с входными элементами соединен с помощью отношения композиции (compositionrelation).

Выделяется три основных группы деятельности:

· управленческая;

· основная;

· вспомогательная.

Из рисунка 6 видно, что управленческая деятельность медицинского центра схожа с управленческими деятельностями организации из других сфер бизнеса. А именно сочетают в себе функции управления персоналом, ведение и развитие маркетинга, управление областью информационных технологий, управление финансами и управление развитием. Основнаядеятельность является узкоспециализированной на профиле деятельности медицинского центра и включают в себя медицинскую, фармацевтическую и научно-исследовательскую и образовательную деятельности. Вспомогательнаядеятельность также выражает в себе специфику направленности центра и заключаются в поддержке медицинской деятельности, управлении закупками и активами, а также юридической поддержкой медицинской деятельности.

Рисунок 6 -- Архитектурабизнес-деятельностимедицинского центра

Таким образом, результатом деятельности медицинского центра являются:

· оказанная медицинская помощь пациенту;

· прибыль, полученная в результате выполнения коммерческих манипуляций;

· результаты научно-исследовательской и образовательной деятельностей.

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

· непосредственно медицинскую деятельность;

· фармацевтическую деятельность;

· образовательную деятельность.

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

На рисунке 7 представлен результат осуществления медицинской деятельности медицинским центром с указанием соответствующей бизнес-роли.

Рисунок 7 -- Результирующий продукт медицинского центра



Основным результирующим продуктом является лечение пациентов. Сопутствующими продукту бизнес-объектами являются рецепт врача и лекарственное средство. Данные объекты выбраны в виду того, что в результате осуществления лечения пациента ему предоставляются именно эти два объекта.

Для достижения получения результата необходимы следующие сервисы:

· сервис регистрации поступающих пациентов;

· сервис оказания медицинских услуг;

· сервис просвещения пациентов;

· сервис фармацевтики;

· сервис информирования;

· сервис платежей.

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

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

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

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

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

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

3.2 Описание основных бизнес-процессов медицинского центра

На основании выделенных в предыдущем пункте основных бизнес-сервисов были составлены бизнес-процессы, которые их реализуют.

...