Разработка информационной медицинской системы по модели SaaS: стартовая архитектура ядра SaaS

Характеристика ЕМИАС - государственной медицинской информационно-аналитической системы Москвы. Необходимость создания единой медицинской информационной системы. Преимущества и недостатки SaaS. Платформа для разработки прототипа серверной части и СУБД.

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 28.03.2013
Размер файла 75,0 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

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

Оглавление

  • Введение
  • 1. Описание проблемы и предметной области
    • 1.1 Постановка задач
    • 1.2 Актуальность проблемы
    • 1.3 Современное положение
  • 2. Существующие системы
    • 2.1 «Электронная регистратура» Новосибирска
    • 2.2 ЕМИАС
  • 3. Разработка системы. Наш взгляд
    • 3.1 Что хотят пациенты
    • 3.2 Что хотят врачи
    • 3.3 Отличия
  • 4. Облачные вычисления
    • 4.1 Общие понятия
    • 4.2 Характеристики
    • 4.3 Модель SaaS
    • 4.4 Преимущества SaaS
    • 4.5 Проблемы SaaS
    • 4.6 Оффлайн, новая тенденция облачных сервисов
  • 5. Технические решения
    • 5.1 Платформа для разработки клиентской части
    • 5.2 Платформа для разработки прототипа серверной части и СУБД
  • Список литературы

Введение

C развитием информационных технологий большое значение приобрели задачи автоматизации.Медицинская система также не является исключением. Была создана «электронная регистратура» со своими плюсами и минусами, потребителями которой являлись только граждане Российской Федерации.

"Городская регистратура Новосибирска" предназначена для повышения удобства и доступности получения медицинской помощи гражданами города Новосибирска за счет предоставления дополнительной возможности записи на прием к специалистам поликлиник посредством единого телефонного номера и через Web-сайт.

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

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

1. Описание проблемы и предметной области

1.1 Постановка задач

Задачи, что были поставлены нами перед собой для эффективного написания диплома:

· Описание актуальности исследуемой проблемы.

· Рассмотрение уже запущенного проекта «Единой Электронной Регистратуры». Анализ проблем проекта.

· Рассмотрение нового проекта Москвы ЕМИАС.

· Изучении модели SaaS.

· Свое представление того, как должна выглядеть МИС. Определение целей системы, которую мы описываем. Рассмотрение процессов, связывающих заинтересованные стороны.

· Описание программой реализации приложения.

· Отличия предлагаемой системы и уже существующей.

1.2 Актуальность проблемы

В связи с активным развитием информационных технологий в государстве рано или поздно возникает проблема автоматизации разных отраслей, в том числе медицинской системы. Сегодня как среди развитых, так и среди развивающихся стран не осталось ни одного государства, которое не объявило бы о реформе здравоохранения, однако причины пристального внимания к сфере здоровья и цели, преследуемые реформами, разные. Для наглядности рассмотрим несколько примеров проблем, возникающих в разных странах. В США в условиях дорогостоящей частной медицины около 30% населения не получают регулярного медицинского обслуживания. В Европе здравоохранение на 70% государственное, но при общественной схеме граждане вынуждены все больше и больше платить за медицинскую страховку. Кроме того, население Европы стареет, средняя продолжительность жизни увеличивается (в развитых европейских странах она достигает 76-80 лет), а пожилые люди нуждаются в интенсивном медицинском уходе.

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

Сегодня при существующем количестве врачей (от 2-4 на 1 тыс. человек) невозможно оказывать высококачественные медицинские услуги в рамках системы, ориентированной на стационарное лечение. Переход к действенной повсеместной медицине возможен только в том случае, когда медицинские услуги станут доступны широкому кругу людей при одновременном переносе акцента с клинической медицины на превентивные методы и раннюю диагностику. Одним из решений данной проблемы может послужить создание Медицинской Информационной Системы, которая должна быть направлена в первую очередь на удовлетворение потребностей пользователей данной системы, а именно граждан страны, которые обращаются за медицинскими услугами, и врачей, их оказывающих. Приоритеты государства должны ставиться не в первую очередь. Но этот подход актуален лишь с параллельным развитием информационной инфраструктуры в целом, чтобы электронные услуги были доступны не только жителям крупных городов, но и деревень в разных уголках страны.

1.3 Современное положение

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

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

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

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

2. Существующие системы

2.1 «Электронная регистратура» Новосибирска

Первые шаги в направлении информатизации лечебно-профилактических учреждений были сделаны в 2009 году. Все поликлиники города были дополнительно оснащены мини-АТС, телефонами, компьютерами, справочными системами и системами для записи телефонных разговоров. Реализация «Городская электронная регистратура», осуществлялась на базе Дзержинской подстанции скорой помощи. Там организован единый call-центр, оснащенный современной техникой, позволяющей осуществлять предварительную запись на прием к врачам с использованием всех возможных средств связи.

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

Сайт же «Городская электронная регистратура Новосибирска» был открыт осенью 2011 года. Подключить к ней все регионы планировалось до первого декабря 2012 г.

В настоящее время Минздравом России реализуется проект по созданию единой государственной информационной системы в здравоохранении на территории всей страны. Важной составляющей этого проекта является сервис «Запись на прием к врачу в электронном виде» или «Электронная регистратура».

Отдельные наработки в этом направлении есть во многих регионах. Вместе с тем, единая система только создается и первым регионом, который запустил сервис в полном объеме, стала Омская область.

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

2.2 ЕМИАС

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

Проект разработан и реализуется Департаментом информационных технологий города Москвы совместно с Департаментом здравоохранения города Москвы в рамках программы «Информационный город», на основании Постановления Правительства Москвы от 27 октября 2011 г. N 513-ПП.

В декабре 2011 года ДИТ приступил к массовому развертыванию сервиса. На сегодняшний день к ЕМИАС подключены все государственные поликлиники столицы, а также более десятка медицинский учреждений пилотной зоны внедрения - диспансеры, консультации, диагностические центры.

Функционал системы будет включать в себя:

· управление потоками пациентов;

· интегрированную медицинскую информацию;

· консолидированный управленческий учет;

· персонифицированный учет медицинской помощи;

· управление медицинскими регистрами.

Внедрение ЕМИАС переводит здравоохранение на новый уровень.
Процесс будет реализован в несколько этапов:

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

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

· организацию многопланового учета оказанной медицинской помощи для эффективного управления медицинскими учреждениями.

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

3. Разработка системы. Наш взгляд

3.1 Что хотят пациенты

Есть два принципиально разных вида услуг, оказываемых системой здравоохранения:

1. Плановое обследование (периодическое обследование, сбор справок на работу, диспансеризация) подразумевает обход нескольких врачей.

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

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

2. Внеплановое обследование (когда запись происходит по болезни)

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

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

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

Для достижения этой цели мы предлагаем автоматизировать следующие процессы:

1. запись на прием к конкретному специалисту.

2. запись на прием к конкретному врачу

3. направление пациентов при необходимости на сдачу анализов до первичного приема (оптимизация процесса приема)

4. выбор узкоспециализированного врача по симптомам.

5. сбор информации, которую пользователь может предоставить сам (температура, давление)

6. вывод информации из стандартов оказания медицинских услуг по запросу.

3.2 Что хотят врачи

Цели врачей:

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

2. возможность использования экспертной системы и проверки своих действий с ее помощью.

3. помощь коллег.

4. телемедицина.

5. возможность показать свой уровень профессионализма.

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

1. наличие карты пациентов перед приемом.

2. запись на прием в зависимости от того, когда будут локально доступны данные о пациенте.

3. наличие связей между историями болезней родственников.

4. реализация экспертной системы.

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

6. наличие метрик для оценки качества обслуживания конкретным врачом.

3.3 Отличия

На данный момент нет единой медицинской информационной системы по Российской Федерации. В некоторых субъектах РФ уже существуют обособленные автономные системы. Если рассматривать медицинскую информационную систему по Новосибирской области, то можно убедиться в том, что она автоматизирует лишь процесс записи на прием. Это не оптимизирует время, затрачиваемое на прием. По нашему мнению, информационная система должна быть единой и позволять гражданам записываться на прием без привязки к месту жительства, тем самым реализуя конституционные права. Это решает ряд проблем с учетом оказанных услуг отдельным врачом и оплаты этих услуг.

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

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

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

1. запись на прием к конкретному специалисту.

2. запись на прием к конкретному врачу

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

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

5. сбор информации, которую пользователь может предоставить сам (температура, давление)

6. хранение и структуризация стандартов оказания медицинской помощи.

4. Облачные вычисления

4.1 Общие понятия

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

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

4.2 Характеристики

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

Самообслуживание по требованию (selfserviceondemand), потребитель самостоятельно определяет и изменяет вычислительные потребности, такие как серверное время, скорости доступа и обработки данных, объём хранимых данных без взаимодействия с представителем поставщика услуг;

Универсальный доступ по сети, услуги доступны потребителям по сети передачи данных вне зависимости от используемого терминального устройства;

Объединение ресурсов (resourcepooling), поставщик услуг объединяет ресурсы для обслуживания большого числа потребителей в единый пул для динамического перераспределения мощностей между потребителями в условиях постоянного изменения спроса на мощности; при этом потребители контролируют только основные параметры услуги (например, объём данных, скорость доступа), но фактическое распределение ресурсов, предоставляемых потребителю, осуществляет поставщик (в некоторых случаях потребители всё-таки могут управлять некоторыми физическими параметрами перераспределения, например, указывать желаемый центр обработки данных из соображений географической близости);

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

Учёт потребления, поставщик услуг автоматически исчисляет потреблённые ресурсы на определённом уровне абстракции (например, объём хранимых данных, пропускная способность, количество пользователей, количество транзакций), и на основе этих данных оценивает объём предоставленных потребителям услуг.

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

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

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

4.3 Модель SaaS

SaaS (англ. softwareasaservice -- программное обеспечение как услуга; также англ. softwareondemand -- программное обеспечение по требованию) -- бизнес-модель продажи и использования программного обеспечения, при которой поставщик разрабатывает веб-приложение и самостоятельно управляет им, предоставляя заказчику доступ к программному обеспечению через Интернет. Основное преимущество модели SaaS для потребителя услуги состоит в отсутствии затрат, связанных с установкой, обновлением и поддержкой работоспособности оборудования и работающего на нём программного обеспечения.

В модели SaaS:

· приложение приспособлено для удаленного использования;

· одним приложением пользуется несколько клиентов (приложение коммунально);

· техническая поддержка приложения включена в оплату;

· модернизация и обновление приложения происходит оперативно и прозрачно для клиентов.

В рамках модели SaaS заказчики платят не за владение программным обеспечением как таковым, а за его аренду (то есть за его использование через веб-интерфейс). Таким образом, в отличие от классической схемы лицензирования ПО, заказчик несет сравнительно небольшие периодические затраты, и ему не требуется инвестировать значительные средства в приобретение ПО и аппаратной платформы для его развертывания, а затем поддерживать его работоспособность. Схема периодической оплаты предполагает, что если необходимость в программном обеспечении временно отсутствует, то заказчик может приостановить его использование и заморозить выплаты разработчикуhttp://ru.wikipedia.org/wiki/SaaS - cite_note-1.

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

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

4.4 Преимущества SaaS

SaaS сейчас рассматривают как альтернативу стандартной схеме установки программного обеспечения на оборудовании заказчика. Отличий у этих двух моделей и впрямь много.

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

Второе отличие: в SaaS заказчик получает не само программное обеспечение, а лишь тот функционал, которое оно обеспечивает (в качестве веб-сервиса). А ведь именно реализация бизнес-функций и нужна заказчику.

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

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

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

4.5 Проблемы SaaS

информационный медицинский серверный

В различных источниках называется несколько причин развития SaaS:

· жесткие требования к качеству и бесперебойности канала связи;

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

· недостаточная скорость работы;

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

Главные проблемы, замедляющие развитие и распространение SaaS в России - этонедостаточное понимание бизнесом выгод от SaaS. Недостаточное развитие малого бизнеса вообще и слабое доверие к провайдерам SaaS услуг, а также сомнения по поводу сохранности корпоративных данных.

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

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

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

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

Остается только один минус -- это недостаточное понимание бизнесом преимуществ SaaS-решений, психологическая неготовность к SaaS. Эту проблему может решить только время.

У SaaS-модели есть целый ряд преимуществ перед "коробочными" решениями - и бизнес со временем заметит их. Неслучайно так активизировались в последнее время и российские разработчики SaaS-решений. Рынок SaaS в России растет.

4.6 Оффлайн, новая тенденция облачных сервисов

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

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

Локальная база данных. Локальное сохранение данных началось со стандарта ApplicationCache, суть которого лежит в сохранении логики приложения, а также его пользовательского интерфейса. Сегодня можно пойти еще дальше: захватить новые данные, генерируемые пользователем на его устройстве, и сохранить их локально. Существуют различные стандарты локальных баз данных, среди которых самым распространенным был Web SQL, пока от него не отказался Консорциум всемирной паутины (W3C), организация по разработке веб- стандартов.IndexedDB поддерживается браузерами Firefox, Chrome и InternetExplorer, начиная с 10-й версии.

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

5. Технические решения

5.1 Платформа для разработки клиентской части

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

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

Во-вторых, PHP распространяется свободно и поддерживается подавляющим большинством представителей сетевого хостинга.

В частности было уделено внимание тому, чтоодной из сильнейших сторон PHP является возможность расширения ядра, что дает возможность работать с огромным количеством баз данных, протоколов, поддерживать большое число API (applicationprogramminginterface- интерфейс программирования приложений).

Также PHP поддерживает ООП (деструкторы, открытые, закрытые и защищённые члены и методы, final-члены и методы, интерфейсы и клонирование объектов). PHP поддерживает XML.

5.2 Платформа для разработки прототипа серверной части и СУБД

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

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

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

Рассмотрим также объектно-реляционную систему управления базами данных OracleDate.

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

Большие базы данных. Максимальный размер экземпляра базы данных Oracle может достигать 8 экзабайт.

RealApplicationCluster (RAC) обеспечивает работу одного экземпляра базы данных на нескольких узлах grid, позволяя управлять нагрузкой и гибко масштабировать систему в случае необходимости.

AutomaticStorageManagement (ASM) позволяет автоматически распределять данные между имеющимися ресурсами систем хранения данных, что повышает отказоустойчивость системы и снижает общую стоимость владения (TCO).

Список литературы

1. АншинаМ. К. Как управлять облаками // М.: Вильямс, 2012. - №1 - 156 c.

2. Викин А.В. Архитектура компьютера: в 2-х т. / А.В. Викин; М: Вильямс, 2008 - 91 с. - 2 т.

3. Дмитриев А.М. О моделировании по системе SaaS. Практический подход // Вторая всероссийская научно-практическая конференция «Моделирование»: Сб. Докладов. - СПб; М., 2007.

4. Жилин А.А., Кон М.А. Классический подход к проблемам архитектуры // М.: Вильямс, 2008. - №1 - 721 c.

5. Прохоренок Н.А. Разработка Web-сайтов с помощью Perl и MySQL. - СПб.: БХВ-

Петербург, 2009. - 560 с.

6. Турчин С.А. Современный подход к организации групповой работы в проектной команде. / Управление проектами и развитие производства: Сб. научных статей. Под ред. В.А. Рач. - М., 2000.

7. ФаломеевК. К. Новые тенденции облачных сервисов// СПб.: Питер, 2012.- 102 c.

Размещено на Allbest.ru

...

Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.