CC BY
91
Информационные системы
муниципального здравоохранения www.idmz.ru
Материалы конференции «Информатизация здравоохранения 2007, № 4
и социальной сферы в регионах России:
проблемы координации и информационного обмана»
А.В.ГУСЕВ,
к.т.н., ст. инженер-программист ОАО «Кондопога», Петрозаводск—Кондопога
СОЗДАНИЕ ЕДИНОГО ИНФОРМАЦИОННОГО ПРОСТРАНСТВА МЕДИЦИНСКИХ УЧРЕЖДЕНИЙ С ПРИМЕНЕНИЕМ МУЛЬТИСЕРВЕРНОЙ РАСПРЕДЕЛЕННОЙ АРХИТЕКТУРЫ В КОМПЛЕКСНОЙ МЕДИЦИНСКОЙ ИНФОРМАЦИОННОЙ СИСТЕМЕ
В статье дается описание мультисерверной архитектуры комплексной медицинской информационной системы (МИС). Предусматриваются 2 режима работы: распределение нагрузки на несколько серверов за счет физического разделения баз данных и повышение доступности и производительности работы МИС за счет поддержки технологии репликации. Приведено описание поддержки территориально-распределенной базы данных МИС, возможностей для повышения производительности системы, предоставления off-line-доступа к БД МИС.
ВВЕДЕНИЕ
Текущее состояние системы здравоохранение, наличие множества учреждений, различных по специализации, объему оказываемой медицинской помощи и источникам финансирования, привели к неизбежному выводу о необходимости автоматизации процессов информационного обмена как внутри этих учреждений, так и между ними. На фоне этой тенденции все большее внимание уделяется интегрированным (некоторые авторы называют их комплексными) медицинским информационным системам (МИС). Интегрированные МИС отличаются от других информационных систем главным образом тем, что они нацелены на максимально полную, если не тотальную, автоматизацию лечебно-профилактического учреждения (ЛПУ) едиными программными средствами.
Несмотря на повышение интереса к таким системы, случаи действительно полной и эффективной автоматизации за счет их внедрения все еще достаточно редки, а поэтому изучение требований и особенностей функционирования МИС в условиях полного электронного документооборота внутри ЛПУ является актуальной задачей медицинской информатики.
Наш Медицинский центр, расположенный в городе Кондопоге Республики Карелия, включает в себя несколько ЛПУ и работает в таких условиях с 2000 г. За это время система прошла этап развития от автоматизации отдельных задач внутри клиники до решения проблемы объединения нескольких ЛПУ в единое информационное пространство и предоставление доступа к медицинским электронным документам в любом месте города и в любое время. Центр включает в себя санаторий-профилакторий, многопрофильную поликлинику и открытый на ее базе Центр амбулаторной хирургии, а также распределенную по территории города сеть здравпунктов (рис. 1).
© А.В.Гусев, 2007 г.
■ ■■ ■ ■ ■ ■■ ■ ■ 1 1 1 1 1 1 1 1 , 1 1 1 1 1 1 1 1 1 1 1 1 ■■■ ■ ■■ ■■ ■ ■ ■■■ ■ ■ лллллл^Л 27f ^ , 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 11
'■ и информационные
технологии
Информационные системы муниципального здравоохранения
Материалы конференции «Информатизация здравоохранения
и социальной сферы в регионах России:
проблемы координации и информационного обмана»
■ _i t
Рис. J. Структура Медицинского центра и основные информационные потоки между его службами
Система базируется на принципе объектно-реляционного подхода [1]. Большая часть системы создана в среде Lotus Notes/Domino. Некоторые подсистемы, такие как статистика, бухгалтерия или аптека, разработаны для Microsoft SQL Server. Обе эти СУБД тесно связаны друг с другом логическими и интерфейсными средствами системы и работают как единый программный комплекс.
Во время своего развития постоянно совершенствовалась архитектура системы, которая должна была позволять эффективно работать с данными всему пласту пользователей: от медсестер и бухгалтеров до главного врача. При этом, пройдя путь от автоматизации отдельных бизнес-процессов до задачи объединения и тесной интеграции территориально и функционально разобщенных пользователей, родилась потребность предоставлять доступ по принципу «всегда и везде».
ОПИСАНИЕ МЕТОДИКИ
Одним из основных технологических решений, востребованных вследствие расширения возможностей системы и объема ее использования, является мультисерверная архитектура базы данных (БД) МИС. Под термином мультисерверная архитектура мы понимаем возможности системы использовать для обслуживания ее БД 2 и более серверов, в том числе территориально удаленных серверов.
Предпосылками для разработки мультисерверной архитектуры явились:
♦ высокая нагрузка на сервер в случае комплексной автоматизации ЛПУ средствами МИС;
♦ потребность в объединении информационных потоков между территориально-распределенными подразделениями ЛПУ;
♦ потребность в снижении расходов на аппаратное обеспечение МИС, включая серверы, коммуникационное оборудование и
' 28 ! ! ! ! ! : 1 1 1 1 1 1 ■ ■ ■ ■ ■■ ■ ■ ■ й- ■ !!■!!!!!!!!!!! 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 ■■■ ■ ■ ■ III!!!!! ■■ ■ ■ ■■■ ■ ■ ■ ■ ■ 1 1 1 , 1 , . 1 , , 1 , 1 1 , . , 1
Информационные системы муниципального здравоохранения
Материалы конференции «Информвтизвция здревоохренения
и социельной сферы в регионех России:
проблемы координеции и информеционного обмене»
www.idmz.nu 2007, № 4
оплату трафика по открытым каналам связи в случае территориально распределенного ЛПУ;
♦ потребность в обеспечении off-line-доступа к базам данных МИС в случае разрывов каналов связи между подразделением ЛПУ и центром обработки данных или в случае использования портативных компьютеров;
♦ задача повышения производительности МИС за счет консолидации вычислительной мощности нескольких серверов.
В общем случае все указанные проблемы и задачи могут быть успешно решены за счет реализации идеи мультисерверной архитектуры МИС. Суть этой идеи в том, что система должна сохранять полную работоспособность и прозрачность функционирования для пользователя в случае, если физически ее базы данных распределены по нескольким серверам. При этом важнейшее требование — это обеспечивать 2 возможных режима работы:
1. Разделение нагрузки на несколько серверов за счет физического распределения баз данных отдельных подсистем между этими серверами.
2. Поддержка работы с репликами системы, в том числе и селективной репликой баз данных системы.
Режим разделения нагрузки предназначен в первую очередь для снижения общей вычислительной нагрузки на центральный сервер системы. Например, работа врачей или медицинских сестер с системой характерна частыми обращениями (на чтение или запись) сразу к нескольким базам данных, при этом каждое такое обращение генерирует незначительный по объему, но достаточно интенсивный в единицу времени, трафик между сервером и клиентским компьютером. Кроме этого, распределение областей памяти в базе данных, к которым осуществляется обращение, у этих пользователей имеет случайный характер. Такой режим работы, достаточно типичный для большинства медицинских сотрудников ЛПУ, вызывает значительную нагрузку на сервер, который должен поддерживать одновременно в рамках
одной пользовательской сессии открытие сразу нескольких баз данных и их интенсивное обслуживание: обновление индексов, в том числе гипертекстового, или обновление представлений данных, а также выполнение хранимых на сервере программных модулей (агентов, хранимых процедур, триггеров). Характеристика этой нагрузки достаточно хорошо изучена [1], и в соответствии с ее параметрами осуществляется проектирование внутренней архитектуры баз данных и системы в целом, например, за счет реализации внутренней декомпозиции на подсистемы и отдельные БД и их последующего логического объединения [3]. Вместе с этим в ЛПУ имеется ряд задач и пользователей, имеющих принципиально другую природу запросов. Это в первую очередь задачи обеспечения статистических расчетов, материальный и финансовый учет, аналитические исследования. Эти задачи востребованы административным аппаратом ЛПУ, бюро статистики, бухгалтерией. Их эффективная реализация требует иных подходов к проектированию внутренней архитектуры системы, иногда — прямо противоречащих подходам, целесообразным с точки зрения автоматизации работы врачей. В результате этого возникает конфликт интересов различных слоев пользователей ЛПУ с позиции архитектуры системы. И хотя в последнее время различные научные школы уже фактически доказали высокую эффективность и прямую необходимость проектирования МИС в первую очередь с целью решения клинических задач и достижения цели повышения качества и доступности медицинской помощи [1, 3, 4], этот принцип все еще не является доминирующим. На рынке имеется большое количество разработок, реализованных для решения административных, статистических или финансовых задач [1, 5]. Решением этой проблемы как для приверженцев клинически ориентированного подхода, так и для приверженцев традиционного административноориентированного подхода может выступать именно мультисерверная архитектура системы в режиме разделения нагрузки. Ее реализация
■ ■■ ■ ■ ■ ■■ ■ ■ 1 1 1 1 1 1 1 1 , 1 1 1 1 1 1 1 1 1 1 1 1 ■■■ ■ ■■ ■■ ■ ■ ■■■ ■ ___ ■ , 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
'■ и информационные
технологии
Информационные системы муниципального здравоохранения
Материалы конференции «Информатизация здравоохранения
и социальной сферы в регионах России:
проблемы координации и информационного обмана»
подразумевает анализ задач, решаемых системой, и их разделение на 2 или более групп. Признаком принадлежности к той или иной группе может быть либо приоритетность решаемой задачи (например, высокая производительность у врачей является более приоритетной задачей по сравнению с производительностью работы отдела статистики), либо характеристика трафика, генерируемого пользователями данной задачи (например, трафик у лечащих врачей имеет значительные отличия от трафика главного врача или бухгалтера). В ходе анализа разработчик МИС может сформировать однородные по выбранному признаку группы и предусмотреть возможность физического разделения баз данных этих групп по разным серверам. В таком случае решается главная проблема конфликта подходов к проектированию баз данных соответствующих подсистем, так как сервер физически обрабатывает достаточно однородный объем информации и трафик от соответствующих приложений МИС. Клинически ориентированные подсистемы могут проектироваться с точки зрения глубокой внутренней декомпозии, а подсистемы статистики или финансового учета, наоборот, могут разрабатываться в архитектуре, наиболее подходящей
для массовой обработки информации и интенсивных расчетов. Кроме этого, существенным дополнительным стимулом к использованию этого подхода является физическое разделение нагрузки между несколькими серверами: трафик и нагрузка врачей никак не зависят и не снижаются в силу, например, высокой вычислительной нагрузки, вызванной работой отдела статистики. Сохраняется своеобразная автономия вычислительных ресурсов: производительность административного аппарата зависит только от мощности их сервера и генерируемой ими нагрузки, а производительность врачей и медсестер — соответственно от их нагрузки. Это преимущество эффективно именно для основного медицинского состава ЛПУ, так как, например, отдел статистики хоть и обращается одномоментно к небольшому числу БД, однако расчет достаточно сложного и объемного статистического отчета может вызвать значительную нагрузку сервера (рис. 2а, б). В результате этого получается, что работа всего одного пользователя (сотрудника отдела статистики) потенциально может вызвать серьезные задержки в работе многих других пользователей, к тому же имеющих больший приоритет для ЛПУ (например, лечащих врачей).
Рис. 2. Разделение информационных потоков на примере группы медицинских сотрудников и группы статистиков за счет возможностей мультисерверной архитектуры
• 30 ! ! ! ! ! : 1 1 1 1 1 1 В В В В ВВ В В в В. в !!■!!!!!!!!!!! 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 ■■■ ■ ■ ■ III!!!!! ■■ ■ ■ ■■■ ■ ■ ■ ■ ■ 1 1 1 , 1 , . 1 , , 1 , 1 1 , . , 1
Информационные системы муниципального здравоохранения
Материалы конференции «Информвтизвция здревоохренения
и социельной сферы в регионех России:
проблемы координеции и информеционного обмене»
www.idmz.nu 2007, № 4
В ходе наших исследований, моделирующих такой вариант работы, мы выявили и еще один стимул — экономический. В ходе эксперимента, при котором один мощный сервер ЛПУ был заменен двумя, менее мощными серверами. Один из них предназначался для обслуживания медицинских сотрудников, а второй (собранный из компонентов рабочей станции) — для обслуживания статистических расчетов. При этом мы выявили, что суммарная стоимость аппаратного обеспечения для такой мультисерверной архитектуры была ниже, чем приобретение одного, но мощного сервера. Вместе с этим показатели производительности МИС только возросли [1].
Таким образом, теоретически обоснованная идея мультисерверной архитектуры была в первую очередь вызвана потребностью в эффективной реализации всего комплекса задач по автоматизации ЛПУ (клинических, статистических, финансовых) и вместе с этим обеспечении достаточной производительности работы этих служб. На практике эта задача впервые была реализована нами для медицинской информационной системы «Кондопога» в 2002 году. Тогда мы в первую очередь реализовали возможность физического выделения подсистемы статистики. В дальнейшем поддержка мультисерверной архитектуры была реализована для финансово-экономической подсистемы, аптеки, модуля автоматизации службы питания и подсистемы гостиничного комплекса. При этом в ходе экспериментов мы выяснили, что реализация этих подсистем на базе основной платформы системы — Lotus Notes/Domino — имела недостаточную, с точки зрения производительности, эффективность. Однако реализованная поддержка мультисерверной архитектуры позволила фактически без изменений основной части системы перенести реализацию указанных систем из Lotus Notes/Domino в реляционную СУБД. Вначале это была MySQL, затем — Microsoft SQL Server 7, а потом постепенный переход к версии Microsoft SQL Server 2000 и, наконец,
в 2006 г. — к версии Microsoft SQL Server 2005. В настоящее время задача повышения производительности отдельных служб решается администраторами системы достаточно просто: нужные БД соответствующей службы могут быть физически перенесены с общего сервера на свой выделенный. При этом в системе при помощи всего нескольких настроек вносятся соответствующие изменения, а работа пользователей никак не меняется: все приложения системы функционируют в едином информационном пространстве. Зачастую пользователи и не знают, что одновременно для них задействовано сразу несколько серверов, осуществляющих обслуживание БД нескольких подсистем.
Реализация этого подхода позволила нам сосредоточиться над совершенствованием и повышением производительности важнейшей для нас части системы — модулей работы врачей и медсестер. Разработанные ранее технологические решения, такие как вариабельное ядро, сервис-ориентированная архитектура на основе middleware, технология регистров и некоторые другие [1], позволили обеспечить достаточные возможности масштабирования системы и ее высокую производительность практически на всем сроке эксплуатации системы. Эти технологии в своей большей массе были направлены на достижение единой цели — возможности полного перехода медицинских сотрудников на электронный документооборот. Для поликлиник была реализована полноценная электронная амбулаторная карта, для санаториев и стационаров — электронная история болезни. За период разработки и внедрения этих технологий (2000-2006 г.г.) сразу несколько ЛПУ осуществили комплексное внедрение системы и полный переход на электронную документацию, при этом самый большой по длительности опыт составил 6 лет (санаторийпрофилакторий «Бумажник» перешел на электронные истории болезни с 01.01.2000, более подробно — http://iskondopoga.snw.ru).
и ■■ ■ ■ ■ ■■ ■ ■ 1 1 1 1 1 1 1 1 , 1 1 1 1 1 1 1 1 1 1 1 1 лллллл.,Л '.лллл-Тлллл- 31 , 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 11
'■ и информационные
технологии
Информационные системы муниципального здравоохранения
Материалы конференции «Информатизация здравоохранения
и социальной сферы в регионах России:
проблемы координации и информационного обмана»
Многолетний опыт использования системы привел к появлению принципиально новой задачи — реализации принципа «Доступ всегда и везде». До этого момента врачи и другие сотрудники ЛПУ имели доступ к полной электронной медицинской документации только в своем рабочем кабинете. Однако с определенного момента этого доступа уже оказывалось недостаточно. С одной стороны, инсталляции системы в нескольких ЛПУ города привели к возникновению потребности либо их соединения и обмена информацией между БД отдельных инсталляций, либо к их подключению к одной единой БД. С другой стороны, доступ к МИС только со своего рабочего места тоже перестал быть достаточным — возникла потребность в сохранении этого доступа и в других местах обслуживания пациентов, например, при выезде к пациенту на дом, в офис или за территорию ЛПУ и даже города. Кроме этого, часть работы с документацией врачи могли бы выполнять и дома, так как у многих имелись домашние компьютеры и возможность подключения к внутригородским сетям или Internet. Все это привело к реализации второго режима работы мультисерверной архитектуры — использованию механизма репликации. Как известно, реплика базы данных — это фактически ее копия, в которую средствами механизма репликации передаются изменения основной БД. При этом существуют несколько возможностей поддержки реплики, в том числе селективная реплика (когда в копию передаются не все данные из основной БД, а лишь ее часть, определяемая сервером по некоторым правилам). Существует несколько методов работы репликации, например, pull или push. Также технологии репликации предусматривают множество настроек, например, передача вместе с данными и дизайна приложений к БД, настроек подсистемы безопасности или возможность разрешения в передаче удаленных данных [2]. Столь гибкие возможности, реализованные в платформе Lotus
Notes/Domino в виде готовой для использования технологии, позволили усовершенствовать внутреннюю архитектуру МИС таким образом, что стали возможными инсталляция нескольких дополнительных серверов и репликация уже установленной и настроенной системы между ними. При этом определенная часть пользователей подключается к дополнительную серверу и осуществляет работу именно за счет его вычислительных мощностей. Администратор системы может очень гибко настраивать расписание репликации. Учитывая, что вероятность одновременного обслуживания одного и того же пациента сразу же в нескольких ЛПУ или подразделениях одного и того же ЛПУ очень низка, репликация (а значит, взаимный обмен изменениями в БД между серверами) может осуществляться достаточно редко. Например, в ходе экспериментов мы выявили, что репликация между сервером поликлиники и сервером удаленного здравпункта может производиться не чаще, чем 1 раз в 15-30 минут. При этом в случае поликлиники, рассчитанной на 800 посещений в день, длительность репликации по ISDN-каналу связи составляет всего 1.5-3 минуты, а по оптоволоконному кабелю — 30-50 сек. Вместе с этим разделение запросов пользователей отдельных подразделений между серверами положительно сказывается на производительности работы всех пользователей в целом. Это происходит за счет, во-первых, снижения числа открытых БД и поддерживаемых сервером сессий, а это в свою очередь приводит к более быстрому обслуживанию запросов, поступаемых от пользователей. Кроме этого, физическое разделение БД между серверами (например, за счет технологии вариабельного ядра) приводит к тому, что объемы этих БД сокращаются, но без потери информации, которая просто разделяется по нескольким БД. В результате на сервере сокращается не только число открытых БД или поступающих от пользователей запросов, но и объем
' 32 III!!: 1 1 1 1 1 1 ■ ■ ■ ■ ■■ ■ ■ ■ й- ■ ! I SI 1 1 1 1 1 1 1 1 1 1 1 1 1 i i i i i i i i i i i i i i ■■■ ■ ■ ■ III!!!!! ■■ ■ ■ ■■■ ■ ■ ■ ■ ■ 1 1 1 , 1 , . 1 , , 1 , 1 1 , . , 1
Информационные системы муниципального здравоохранения
Материалы конференции «Информатизация здревоохренения
и социельной сферы в регионех России:
проблемы координеции и информеционного обмене»
www.idmz.nu 2007, № 4
информации, который нужно обработать серверу. Все это приводит к повышению производительности системы, которое может быть использовано двояко: можно либо подключать дополнительных пользователей, либо снизить требования к вычислительной мощности применяемого сервера, а это в свою очередь является экономическим эффектом. Вместе с этим применение сразу нескольких серверов позволяет обеспечить следующие решения:
♦ Поддержку работы удаленных подразделений ЛПУ в едином информационном пространстве (рис. 3);
♦ Снижение требований к пропускной способности каналов связи между ЛПУ. Так, без применения мультисерверной архитектуры для удаленного подразделения, насчитывающего 10 и более рабочих мест, потребовалась бы прокладка оптоволоконного кабеля, чтобы обеспечивать их высокую производительность работы. Использование мультисерверной архитектуры позволяет ЛПУ установить в таком подразделении свой сервер, при этом обладающий не очень высокой производительностью, а его соединение с центральным сервером организовать по ADSL, ISDN или даже коммутируемой линии. При этом затраты на установку дополнительного сервера по сравнению с затратами на прокладку оптоволоконного кабеля могут быть значительно ниже, особенно на дальних расстояниях или в условиях густо населенного города;
♦ Повышение сохранности данных за счет реализованной технологии многократного дублирования информации между несколькими серверами. В этом случае возможно полное и достаточно быстрое восстановление всех данных систем с дополнительных серверов даже в случае полного разрушения здания, где располагался основной сервер. Не секрет, что чаще всего администраторы если и выполняют резервное копирование БД системы, то делают это либо недостаточно часто, либо хранят резервные копии в том же
Рис. 3. Организация автономной работы удаленного офиса ЛПУ за счет средств мультисерверной архитектуры
здании, где располагается и сервер, что в случае катастрофы (пожар, наводнение, подрыв здания) не позволяет выполнить восстановление данных;
♦ Возможность off-line-доступа к системе.
Эта возможность реализована, с технологической точки зрения, достаточно просто и эффективно: на ноутбук может быть установлен точно такой же дополнительный сервер Lotus Domino, а работа клиентского ПО Lotus Notes настроена на использование реплик с локального сервера. При этом настройка репликации может быть выполнена в достаточно интенсивном режиме, например, каждые 5 минут. Если ноутбук эксплуатируется в здании ЛПУ, то за счет подключения к сети ЛПУ, например, за счет средств беспроводного доступа, пользователь почти с точно такой же по наполнению БД, что и на основном сервере. Если пользователь покидает здание ЛПУ и у него нет более возможности подключиться к центральному серверу, то работоспособность системы все равно полностью сохраняется, так как обслуживание задач осуществляется локальным сервером [3].
■ ■■ ■ ■ ■ ■■ ■ ■ 1 1 1 1 1 1 1 1 , 1 1 1 1 1 1 1 1 1 1 1 1 ■■■ ■ ■■ ■■ ■ ■ ■■■ ■ ■ лллллл^Л 33f _ , 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
'■ и информационные
технологии
Информационные системы муниципального здравоохранения
Материалы конференции «Информатизация здравоохранения
и социальной сферы в регионах России:
проблемы координации и информационного обмана»
ЗАКЛЮЧЕНИЕ
Описанные преимущества мультисерверной архитектуры, на наш взгляд, позволяют обеспечивать достаточный запас масштабирования и обеспечения высокой производительности МИС как для ЛПУ различного уровня, так и для внедрений на уровне горо-
да или региона. За счет реализации такой архитектуры становится возможным действительное предоставление пользователям доступа «Всегда и везде», что является уже другим качеством в разработке и использовании комплексных медицинских информационных систем.
ЛИТЕРАТУРА
1. Гусев А.В. Медицинские информационные системы: Монография/Ред.
А.В.Гусев, Ф.А.Романов, И.П.Дуданов, А.В.Воронин. — ПетрГУ. — Петрозаводск, 2005. — 404 с.
2. Линд Д. Lotus Notes и Domino R5. Энциклопедия пользователя/Ред. Д.Линд. Киев: DiaSoft, 2002. — 523 с.
3. Лапрун И. Возможности off-line-доступа к базам медицинских данных/ZPCWe-ek Mobile. — №5. — С.12-15. http://pcweek.ru/?ID=610425
4. Назаренко Г.И, Гулиев Я.И, Ермаков Д.Е. Медицинские информационные системы: Теория и практика/Под ред. Г.И.Назаренко, Г.С.Осипова. М.: ФИЗМАТЛИТ, 2005. — 320 с.
5. Рот Е.З. Четырехлетний опыт использования компьютерной истории болезни (вопросы повышения качества). Обеспечение качества оказания медицинской помощи в лечебно-профилактических учреждениях/Ред. Г.З.Рот, В.А.Миронов, Е.И.Шульман. Барнаул, 1996. — С.31-37
6. Эльянов М.М. Медицинские информационные технологии: цивилизованный рынок или «зоопарк»/Ред. М.М.Эльянов//В кн. Информационные технологии в медицине — 2002: Сб. тезисов. М.: ВК ВВЦ «Наука и образование», 2002. — С.54-58.
' 34 III!!: 1 1 1 1 1 1 ■ ■ ■ ■ ■■ ■ ■ ■ й- ■ ! I SI 1 1 1 1 1 1 1 1 1 1 1 1 1 i i i i i i i i i i i i i i ■■■ ■ ■ ■ III!!!!! ■■ ■ ■ ■■■ ■ ■ ■ ■ ■ 1 1 1 , 1 , . 1 , , 1 , 1 1 , . , 1
