Med-Practic
Посвящается выдающемуся педагогу Григору Шагяну

События

Анонс

У нас в гостях

Aктуальная тема

Общественный ежемесячный отчет здравоохранения Армении 1-12.2007

Медицинские информационные системы.Информационная система для интегрального фармацевтического и здравоохранного мониторинга

Введение

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

 

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

 

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

 

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

 

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

 

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

 

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

 

Разрабатываемый нами интегральный мониторинг построен на взаимосвязанных группах индикаторов, которые отражают важнейшие направления:

 

  • индикаторы, характеризующие состояние здоровья населения,
  • индикаторы, характеризующие состояние служб здравоохранения;
  • индикаторы, характеризующие ресурсы;
  • индикаторы “развития”.

 

Данная разработка будет внедрена в систему здравоохранения Армении на национальном и марзовом уровнях; изучена ее эффективность и практическая целесообразность в системе интегрального здравоохранного и фармацевтического мониторинга.

 

Анализ рынка медицинских информационных систем

 

Мировой рынок медицинских информационных систем (МИС) в настоящее время представлен немалым количеством участников и решений. Вышедший в нынешнем году 0чередной выпуск каталога Михаила Эльянова [электронная версия доступна на сайте www.armit.ru] является наиболее полной и разносторонней систематизацией российских разработок в области медицинских информационных технологий (ИТ) и включает сведения о 826 системах и информационных ресурсах и о 347 организациях-разработчиках. Между тем специальной литературы, посвященной вопросам проектирования, разработки и внедрения МИС, выпущено немного. Отдельные аспекты МИС время от времени освещаются в периодической печати, однако обобщающих публикаций явно недостаточно.

 

Первое исследование рынка всего спектра програмного обеспечения (ПО) для медицины было проведено в 1998 г. В то время наибольшее распространение получили программы для автоматизации финансовых и административных служб лечебно-профилактических учреждений (ЛПУ), а системы, предназначенные непосредственно для лечебно-диагностического процесса, составляли лишь 9,6% от всего ПО для медицины. В 2000 г. ситуация несколько улучшилась, однако существенных изменений с тех пор не произошло. Такая стабильность связана с тем, что разработка МИС занимает длительный срок (не менее двух-трех лет), поэтому и количество новых систем в этой сфере растет медленно.

 

Основным  недостатком большинства МИС,  представленных на  рынке  в 2000—2002 гг., была их узкая специализация. Наиболее популярными были системы для отделений стоматологии, офтальмологии, рентгенологии, анестезиологии, реаниматологии и других областей. И сейчас есть несколько программ, предназначенных для автоматизации только регистратуры, целесообразность применения которых сомнительна в отрыве от автоматизации клинических отделений, отдела статистики и других основных служб ЛПУ. Современная МИС, считают авторы, должна быть универсальной и поддерживать различные виды ЛПУ, а не специализироваться, к примеру, только на автоматизации отдельной поликлиники.

 

Предметом этого анализа является состояние рынка только основных МИС,направленных на комплексную автоматизацию ЛПУ и объединяющих несколько взаимосвязанных подсистем, таких, как электронная история болезни (ЭИБ) или амбулаторная карта пациента, расписание рабочего времени персонала, бухгалтерия, статистика и др. (см. таблицу). Почти 80% из них могут применяться в многопрофильных стационарах и поликлиниках, в санаторно-курортных учреждениях.

 

МИС для комплексной автоматизации лечебно-профилактических учреждений

 

п/п

Название системы

Разработчик

Город

1

e-Hospital

"Курс", www.e-hospital.ru

Нижний Новгород

2

MedTrak

СП. АРМ (официальный представитель компании-

разработчика), www.sparm.com

Санкт-Петербург

3

Medwork

MasterLabs, www.medwork.ru

Москва

4

"Авиценна"

"Фирма КОСТА", www.kostasoft.ru

Санкт-Петербург

5

"Амулет"

"ЦентрИнвестСофт", www.amulet-med.ru

Москва

6

"Артемида"

"Конус-Медик", www.conus.ru

Курск

7

"Гиппократ"

"Ультрамед-1", www.ultramed.ru/as.htm

Москва

8

ДОКА+

Фонд развития и оказания специализированной медицинской помощи "Медсанчасть-168", www.docaplus.com

Новосибирск

9

"Интерин"

Институт программных систем (ИПС) РАН, www.interin.ru

Переславль-

Залесский

10

"Интрамед"

"Медкор-2000", www.medcore2000.ru

Москва

11

"Кондопога"

" Кондопога", http://iskondopoga.narod.ru

Кондопога

12

"МедИС-Т"

НПП "Дейманд"

Таганрог

13

"Медиалог"

"Пост Модерн Текнолоджи", www.pmtech.ru

Москва

14

"МедОфис"

SIAMS, http://siams.com

Екатеринбург

15

"Пациент"

"Медотрейд", www.medotrade.ru

Москва

16

"Тонлайн"

"Тонлайн", www.tonline.nikos.ru

Москва

17

"Торинс"

"Торинс", www.torins.ru

Красноярск

18

"Фобос"

"Фирма ФОБОС", www.mtu-net.ru/fobos

Москва

19

ФИРС АРМ

Новоусманская центральная районная больница Воронежской области http://web.vrn.ru/nusman/firrsarm.files/index1024.htm

Новая Усмань

20

"Эверест"

Научно-промышленная компания "АИТ-холдинг",

www.ait.ru

Москва

 

Технологии разработок МИС

 

В 1999 г. 47% МИС использовали локальные (настольные) БД (базы данных),  при  этом  в  подавляющем  большинстве  случаев  это  были  таблицы dBase. Такой подход характерен для начального периода разработок ПО для медицины и создания узкоспециализированных продуктов. С каждым годом количество отечественных систем на основе настольных БД уменьшается, в 2003- м, по нашим данным, эта цифра составляла уже всего 4%. На сегодня только некоторые  разработчики  используют  dBase  как  средство  хранения  данных  и FoxPro как программную среду. Учитывая, что Microsoft уже неоднократно делала заявления о планах прекращения развития линейки FoxPro, данное направление можно считать тупиковым.

 

Некоторые программные продукты используют собственный формат БД, нередко они применяются в электронных фармакологических справочниках. В настоящее время на отечественном рынке имеется МИС, построенная даже на собственной СУБД архитектуры “клиент — сервер”: e-Hospital. Трудно себе представить объективные причины для подобного решения. Как нам кажется, использование МИС, созданной на основе специально разработанной СУБД, сопряжено со значительными риском, вызванным слабыми возможностями масштабирования, наличием “черных ходов”, недостаточными мерами защиты информации и т. д.

 

Распределение внедрений МИС по типу ведомственных ЛПУ

 

 

Подавляющее большинство МИС построено в архитектуре “клиент — сервер”. Практическим опытом доказана неизбежность такого решения для создания комплексной МИС, так как файл-сервер способен поддерживать только до 10  рабочих станций и   небольшой объем базы данных. Кроме того, значительная часть существующих требований к МИС уже реализована в промышленных СУБД (система управления базой данных), построенных в архитектуре “клиент — сервер”, что позволяет существенно сократить время на создание системы.

 

При разработке, напимер российских, МИС в основном применяются следующие СУБД: Microsoft SQL Server (версия 7.0 или 2000) — 29,4%, Oracle —17,6%, Borland Interbase Server — 5,8%, Cache — 11,7%, Lotus Notes/Domino —11,8%. Для сравнения: если проанализировать все медицинское ПО, использующее архитектуру “клиент — сервер”, то доля СУБД Microsoft SQL Server составит 64%.

 

Все применяемые СУБД разделяются на два принципиально разных вида: реляционные (РБД) и постреляционные (объектно-ориентированные — ООБД). При анализе всего ПО для медицины мы выяснили, что в настоящее время в России 92% программных продуктов основаны на реляционных СУБД. Среди МИС преимущество РБД не такое безусловное — 75%. Остальные 25% занимают постреляционные СУБД. При этом в данную категорию мы включили Lotus Notes/Domino, которую лишь условно можно назвать постреляционной — это скорее документно-ориентированная платформа для групповой работы. Lotus Notes/Domino и Cache заняли паритетные позиции — обеим принадлежит по 50% постреляционного сегмента СУБД.

 

Фактически на всех рабочих местах установлены операционные системы Microsoft Windows, и вряд ли следует ожидать серьезной конкуренции со стороны других ОС, используемых в качестве базы рабочих станций, даже Linux. Это объясняется главным образом недостатком высококвалифицированных кадров по Linux, UNIX или FreeBSD в сфере здравоохранения. Кроме того, для медицинской среды характерен довольно активный обмен информацией между ЛПУ или их различными отделениями. И именно форматы Microsoft (Microsoft Word для документов или Microsoft Excel для таблиц и различных форм отчетности) имеют наибольшее распространение. Программные продукты Microsoft отличаются также простотой освоения и использования — в особенности Windows и Office, что определяет эффективность обучения пользователей и внедрения системы.

 

Среди серверов преимущество операционных систем Microsoft не является безоговорочным. Так, 31,3% из всех применяемых СУБД — кроссплатформенные и могут функционировать на Linux. Разработчики ДОКА+ вообще выбрали Linux

 

как предпочтительную операционную систему сервера (общеизвестным фактом является то, что Oracle и Lotus Domino значительно эффективнее работают под управлением Linux, а их производители — компании Oracle и IBM — считаются основными инвесторами в технологии Linux). Использование Linux в качестве операционной системы с экономической точки зрения более предпочтительно, так как стоимость самой операционной системы Linux значительно ниже, чем ПО Microsoft, и нет необходимости в оплате лицензий на подключение к серверу.

 

Среди МИС 20% поддерживают DOS-клиентов. Несмотря на все еще высокий процент устаревшей техники (на базе процессора Intel 486 и ниже) в ЛПУ, ценность поддержки DOS вызывает серьезные сомнения. Физический износ такой техники, а также недостаточное количество комплектующих деталей для ремонта платформы и экономическая нецелесообразность такого шага фактически приведут к ее исчезновению в ближайшие два-три года. Поэтому исследователям представляется, что поддержка DOS, наоборот, является преградой для развития МИС и в конечном итоге может стать причиной снижения их эффективности.

 

В качестве инструментария разработки используются самые разные продукты. ДОКА+ разрабатывается на PHP и JavaScript, e-Hospital — в среде Microsoft Visual C++, “Амулет” — в среде Microsoft Visual.NET. Примерно 40% разработчиков применяют встроенный в СУБД инструментарий. В качестве редактора отчетов 42% используют собственные разработки, 23% — средства, встроенные в СУБД. Так же распределяются и средства проектирования БД. Из средств автоматизации проектирования и тестирования программного кода 50% разработчиков применяют Visual Source Safe. В качестве ПО для создания документации 85% разработчиков используют продукцию Microsoft — текстовый редактор  Word  или,  как,  например,  создатели  e-Hospital, —  Microsoft  Help Workshop

 

Перспективы

 

Вне сомнений, 2004—2005 гг. можно назвать временем старта нового этапа в развитии и распространении МИС. Если до 1999 г. они представляли собой уникальное явление и были в значительной степени лишь модным атрибутом современного ЛПУ, то с 2000-го эта ситуация начала меняться, хотя в масштабах всей страны их внедрения — все еще единичные случаи. Накопленный за это время опыт показал, насколько эффективно могут применяться современные информационные технологии в практике работы ЛПУ, в организации их рациональной работы. А последние законодательные акты Минздравсоцразвития

(приказы №  255,  256  и  257,  например) вообще не  оставляют ЛПУ  выбора  и фактически заставляют их искать возможности для внедрения МИС.

 

В целом рынок МИС только начинает формироваться. Вероятно, основная причина  его  пока  еще  слабого  развития  —  отсутствие  достаточной “покупательной” способности большинства отечественных ЛПУ. В настоящее время количество предложений на рынке МИС явно превышает спрос. Существующие наработки в области МИС обеспечивают готовность рынка к расширению: наличие развитых технологий и небольшая, но уже видимая конкуренция среди производителей создают почву для обращения к сфере разработок и внедрения МИС крупных ИТ-компаний.

 

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

 

В связи сэтим следует скорее ожидать повышенного спроса на дистрибуцию уже готовых систем со стороны различных крупных компьютерных компаний, чем роста числа производителей и появления нового ПО для комплексной автоматизации ЛПУ. Вероятнее всего, начиная с 2005—2006 гг. увеличится спрос на доступные, легко настраиваемые и масштабируемые МИС. Уже сейчас ощущается повышение интереса к ним, растет число внедрений. Например, за 2003—2004 гг. количество внедрений “Медиалога” увеличилось в три с лишним раза, а MedWork — в два.

 

Анализируя динамику внедрений других МИС, а также собственный опыт,мы ожидаем как минимум двукратного прироста количества внедрений за 2006—2008 гг. Одновременно с этим возможно снижение стоимости систем в связи с обострением конкуренции.

 

Заключение

 

В различных странах делается немало для консолидации специалистов по МИС. Так, в России  в 2004 г. учреждена Ассоциация медицинской информатики, ранее была создана Ассоциация развития медицинских информационных технологий, несколько раз в год проходят крупные конференции и форумы, издается  специализированный  журнал  “Врач  и  информационные  технологии”.

 

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

 

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

 

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

 

Дальше — дело за государством, которое должно выработать соответствующую политику в области ИТ для здравоохранения и обеспечить современные ЛПУ достаточными финансовыми средствами и специалистами для массового внедрения МИС.

 

Моделирование и оценка эффективности функционирования медицинской информационной системы

 

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

 

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

 

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

 

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

 

С позиции  системного  похода  нами  проанализированы  данные отечественной и зарубежной литературы о современном состоянии в об-ласти создания и применения МИС. Для этого изучено множество разработок программных продуктов для медицины, разрабатываемых с начала 1991 г. Выделены наиболее важные требования и особенности комплексных МИС. Для рактической разработки МИС рекомендуется использовать объектно- ориентированную СУБД  (например, Lotus  Notes/Domino),  имеющую более высокую эффективность использования в медицинской области, чем реляционная СУБД, а также более низкую стоимость.

 

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

 

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

является постепенное падение производительности работы системы во время ее эксплуатации. В связи с этим необходима разработка новой структуры БД, позволяющая обеспечить тре-буемое время отклика МИС в течение всего срока эксплуатации. Кроме того, требуется определение оптимальной схемы внедрения МИС, в связи с чем необходима разработка математической модели информационной сети ЛПУ.

 

Описание разрабатываемой МИС должно включать общее описание архитектуры и используемых БД, а также отдельных подсистем и их взаимосвязь.

 

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

 

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

 

В качестве программной платформы для сервера может использоваться MS Windows NT/2000 (Intel или Alpha), MS Windows 95/98/Me/XP, OS/2, AIX, HP- UX, Solaris (SPARC или Intel), OS/400, OS/390, Linux (IA-32). Работа клиентской части поддерживается на платформе MS Windows 95/98/Me/2000/XP и Mac OS X. В качестве сервера объектно-ориентированной базы данных используется Lotus Domino R6.0.3 Enter-prise Server. В качестве реляционного сервера поддерживаются СУБД на основе архитектуры «клиент-сервер», обеспечивающие поддержку стан-дарта SQL-92, в частности – MySQL 4.0.18.

 

Система должна состоять из 2 основных частей. Основная часть – должна быть создана в среде объектно-ориентированного программирования Lotus Notes Designer R6.02 на мультиплатформенном языке Lotus Script 5. Применяется 46 баз данных, в которых хранятся 79 форм (электронных документов), имеющих 8760 связанных объектов (полей), 120 представлений, 59 программных агентов, 9 библиотек middleware. Реляционная часть создана в среде Borland Delphi 6 SP3, насчитывает 8 баз данных, содержащих в общей сложности 145 таблиц. Разработано 24 приложения, состоящих из при-мерно 115 000 строк кода.

 

С целью снижения затрат на обслуживание МИС, а также повы-шения устойчивости  работы  системы  применяется  специально разработанная подсистема автоматической установки и обновления программ. При этом все разрабатываемое программное обеспечение (ПО) системы выпускается не в виде дистрибутивов, а помещается в специальную БД, называемую «Центр программ». Клиентское программное обеспечение устанавливается и обновляется при необходимости в полностью автома-тическом режиме.

 

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

 

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

 

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

 

Изучение времени работы медицинского персонала с МИС показало, что основную группу пользователей составляют врачи общей практики, участковые врачи поликлиники, врачи узких специальностей и диагностическая служба. В среднем они 55-70% своего рабочего времени подключены к информационной системе, при этом от 50-60% этого времени используется непосредственно на диалог с системой. Наиболее эффективно работают пользователи служб, обслуживающих большие потоки пациентов – регистратура (92% от всего време- ни), функциональная диагностика. Низкий процент использования МИС отмечен у эндоскопической службы, лечебной физкультуры, старших медсестер, стоматологии. Это объясняется спецификой работы указанных пользователей, т.к. основное время расходуется на выполнение лечебно-диагностических мероприятий, а внесение информации в МИС требует незначительного времени.

 

Изучение нагрузки на информационную систему показало, что в среднем врач стационара обрабатывает 280 документов в день, из них изменяет или добавляет 83  документа. Врач  поликлиники за  день  обрабатывает 417 документов, записывает 179. За день для каждого врача стационара МИС анализирует 21177 Кбайт информации, что составляет 68,4% от всего объема БД. В поликлинике для каждого врача обрабатывается 37136 Кбайт, что составляет 6,2% от объема БД поликлиники. Таким образом, в год врач стационара ориентировочно использует 64465 документов, а врач поликлиники – 95936. Объемы обрабатываемой ин-формации за год при работе в единой информационной сети 20 пользователей составляют: для стационара 4,87 Гбайт, для поликлиники – 8,54 Гбайт.

 

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

 

Анализ данных о нагрузке на информационную сеть показал, что при планировании информационной сети ЛПУ необходимо учитывать специальность пользователя.  В  среднем  использование  канала  связи  с  пропу-скной способностью  100  Мбит/сек  не  превышает  1,5%,  однако  во  время  пиковых нагрузок использование у некоторых пользователей возрастает до 12,17%. Сравнение средних показателей в использовании каналов связи и сервера информационной  сети  с  рекомендациями,  встречающимися  в  научной литературе, показало, что эти значения находятся в допустимых пределах, а поэтому объективно не могут использоваться при анализе эффективности проектирования МИС.

 

Изучение использования БД МИС показало, что максимальное их ко- личество используется лечащими врачами. Практически все врачи используют архив системы. Редко используются архивы изображений, т.к. чаще всего врачу достаточно ознакомиться с заключением. В среднем при приеме 1 пациента участковый врач (или врач общей практики) выполняет подключение к БД текущих документов 2 раза. Это обусловлено тем, что на приеме пользователь переключается между календарями спе-циалистов, архивом, собственным календарем и другими приложениями.

 

Изучение эффективности работы серверов информационной сети по- казало,  что  время  подключения  к  БД  зависит  в  значительной  степени  от количества документов в ней, от мощности и загруженности сервера и времени на выполнение  программ  подключения  к  БД.  Изучена  эффективность  установки СУБД на несколько серверов. При выделении реляционной СУБД (РСУБД) на отдельный  сервер  время  открытия  документов  снизилось  на  8%  для ресурсоемкой БД амбулаторных карт и не изменилось для БД историй болезни с минимальным количеством документов. Среднее время поиска документов практически не менялось при применении нескольких серверов. Запись контрольной группы документов из объектноориентированной БД в реляционную БД в случае мультисерверной конфигурации сети удалось снизить на 23,7%. Среднее время открытия документа в наиболее загруженной БД амбулаторных карт изменилось незначительно, что подтверждает утверждение о независимости этого показателя от объема БД. В случае мультисерверной конфигурации сети отмечено снижение максимальной нагрузки на процессор сервера на 15,9%, средней на 43,2%, что свидетельствует о снижении за-трат вычислительных ресурсов сервера системы и положительно сказывается на общей производительности системы в целом.

 

Таким  образом,  на  основании  проведенного  анализа  функционирования МИС сделаны следующие выводы:

 

  1. При проектировании информационной сети ЛПУ необходимо учиты-вать специфику работы каждого пользователя в отдельности, т.к. она значительно изменяет характер работы с системой;
  2. 80-90% времени работы пользователя связано с использованием доку-ментов тех пациентов, которые в данный момент находятся на лечении в ЛПУ;
  3. Основным показателем, характеризующим эффективность структуры БД МИС,является время подключения к БД;
  4. Время подключения к БД в значительной степени зависит от объема БД и количества пользователей, использующих ее;
  5. Время сохранения и поиска документов в БД зависит от ее объема;
  6. Время чтения документов зависит от их внутренней архитектуры и объемов, и не зависит от объема самой БД;
  7. Специфика архитектуры комплексной МИС приводит к тому, что клю-чевые пользователи (лечащие врачи и другой персонал) во время работы часто переключаются между несколькими БД, т.е. часто выполняют опе-рацию подключения к БД;

 

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

 

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

 

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

 

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

 

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

«вариабельным ядром».

 

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

 

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

 

  • Применение традиционных методов повыше-ния эффективности БД.
  • Применение предложенной методики.
  • Наблюдение и анализ работы системы для уточнения результатов.

 

В результате экспериментов подтвердилось, что применение вариа- бельного ядра является более эффективной методикой, чем традиционные. В результате исследования выявлено сокращение времени подключения БД ТД с начального значения 10 сек. до 1,5 сек. Скорость работы с текущими документами возросла в 4,5 раза. Так, применение вариабельного ядра позволило сократить время создания выписок и эпикризов с 25-40 сек. до 2-5. При этом повышение эффективности БД позволило увеличить количество обращений пользователей к системе.

 

Проведенные исследования позволили сделать следующие выводы:

 

  1. Применение традиционных методов повышения эффективности МИС, созданной  на  базе  объектно-ориентированной технологии  либо  неприемлемо, либо имеет недостаточную эффективность;
  2. Основным фактором, влияющим на время подключения к БД, является ее объем. Эффективным способом достижения необходимого значения времени подключения к БД является обеспечение ее постоянного объема в течение всего срока эксплуатации МИС;
  3. В результате применения предложенной методики проектирования БД МИС становится возможным прогностический расчет времени подключения к БД при внедрении МИС в различных лечебных учреждениях. С учетом этого показана необходимость разработки математической модели информационной сети ЛПУ, позволяющей выбрать оптимальный вариант внедрения МИС.

 

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

 

  1. вид ЛПУ: здравпункт, поликлиника, санаторий-профилакторий,  мно-гопрофильный стационар, объединенный медицинский центр и др.;
  2. структура и объем лечебно-диагностической помощи, оказываемой ЛПУ;
  3. планируемый объем внедрения МИС.
  4. количество сотрудников, работающих с информационной системой;
  5. финансовые возможности, выраженные в максимально возможных средствах,выделяемых на внедрение и ежегодное техническое об-служивание системы.

 

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

 

Важнейшими критериями эффективности решения задачи являются:

 

  1. время подключения к базе данных текущих документов;
  2. стоимость внедрения МИС;
  3. стоимость эксплуатации информационной сети;
  4. полнота внедрения МИС.

 

Управляемыми факторами в данном случае являются:

 

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

 

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

 

Значения переменных для определения времени подключения к БД

 

 

Количество пользователей

 

Коэф. корреляции

Значени е

 

Значение

От 2 до 5

0,992

0,701

0,0076

От 5 до 10

0,989

0,752

0,0079

От 10 до 17

0,991

0,865

0,012

От 17 до 25

0,984

0,915

0,046

От 25 до 30

0,989

0,982

0,073

От 30 до 50

0,993

1,258

0,101

От 50 до 55

0,950

1,458

0,124

 

После завершения тестирования всех выбранных серверов  в  программе для расчета математической модели, исходя из выбранной целевой функции и введенных ограничений, производится определение оптимальной схемы внедрения МИС, в том числе определяется опти-мальное количество серверов с выбором конкретной модели и оптималь-ная структура БД МИС.

 

При внедрении разработанной МИС в поликлинике к. Кондопога выполнена проверка адекватности предложенного подхода, в ходе которой выполнены расчеты методом направленного перебора и методом ветвей и границ. Показано, что решение задачи методом ветвей и границ позволя-ет получить результат с допустимой погрешностью за значительно меньшее время. В результате выбора оптимальной схемы внедрения стоимость необходимого компьютерного оборудования была снижена с 26 250$ до 12 640$ (на 48,15%), что составило экономию 226,8$ на 1 пользователя.

 

В  литературе  делаются  следующие  выводы  и  даются  рекомендации, полезные при проектировании и разработке МИС:

 

  1. Основными недостатками традиционных технологий создания МИС является снижение производительности работы системы во время ее эксплуатации, низкая эффективность применения реляционных БД в предметной области, а также высокая стоимость существующих СУБД.
  2. Наиболее  эффективной  методологией  проектирования  МИС  является объектно-реляционный подход.
  3. Созданная МИС имеет опыт эксплуатации с полным переходом на электронный документооборот и, таким образом, доказывает высокую эффективность предложенных методик проектирования БД МИС.
  4. Основными факторами, оказывающими влияние на производительность работы МИС, являются объем ее БД, количество подключенных пользователей и мощность серверного и сетевого оборудования.
  5. В качестве основного критерия эффективности принятой структуры БД МИС рекомендуется рассматривать время подключения к БД.
  6. При проектировании БД МИС рекомендуется применять методо вариабельного ядра, который позволяет добиться высокой скорости доступа к наиболее важной информации системы на длительном сроке эксплуатации МИС, и, в тоже время, хранить значительные ее объемы с целью ретроспективного анализа.
  7. Разработанная математическая модель информационной сети ЛПУ позволяет определять эффективную схему внедрения МИС с использованием различных целевых функций.
  8. При имеющихся в настоящее время технических характеристиках серверов и системном программном обеспечении, которые могут использоваться в большинстве ЛПУ, рекомендуется планировать работу с МИС таким образом, чтобы к одному серверу было подключено не более 20-25 пользователей, т.к. при большем количестве наблюдается падение эффек-тивности работы системы.

 

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

 

Особенности в проектировании и практической разработке медицинской информационной системы

 

В последние годы в литературе появился целый ряд уникальных разработок в области комплексных медицинских информационных систем (МИС), предназначенных для автоматизации работы учреждений здравоохранения. Одними из самых интересных являются: информационная система «Интерин» (Институт программных систем РАН), МИС «Артемида», МИС «Амулет» и некоторые  другие.  Эти  системы  не  только  разработаны,  но  и  активно  развиваются - распространения и признания в практическом внедрении они получили за последние 2-3 года. В литературе опубликованы положительные отзывы коллективов клиник самого разного профиля и масштабов об опыте применения информационных систем в рабо-те. Наметилась тенденция на комплексное решение разносторонних задач лечебного учреждения, что особенно радует и свидетельствует о качественном росте отечественных разработчиков в области медицинской информатики.

 

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

 

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

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

МИС.

 

Ряд коллективов авторов имеет многолетний опыт в разработке медицинской информационной системы. За это время изучена на практике эффективность различных подходов. Применя-лись Microsoft FoxPro разных версий, CA Clipper, Lotus Notes, начиная с версии 4.6, СУБД Microsoft SQL Server, Microsoft Access, Borland Paradox, MySQL и IBM DB2. Апробирован вариант написания программного обеспечения на Borland Delphi, сервлеты на Java, применя-лись Lotus Designer и мультиплатформенный Lotus Script и некоторые другие технологии. Серверная часть системы работала под управлением Microsoft Windows NT Server, Microsoft Windows 2000 Server и Red Hat Linux 6.0. В качестве клиентской операционной системы применялись все версии Windows, начиная с Microsoft Windows  95. Кроме  инструментария, была проведена  работа   по изучению эффективности различных методик проектирования ба-зы данных МИС. В итоге мноие авторы остановились на применении принципа объектно- реляционной парадигмы в проектировании БД МИС. Кратко концепция этого подхода выражается в том, что в силу особенностей предметной области необходимо разрабатывать информацион-ную систему на базе синтеза двух, различных по своей природе, систем управления базами данных (СУБД) – объектно-ориентированной и реляционной. Только на основе этого синтеза удается исключить недостатки обоих СУБД и использовать их достоинства. В качестве ос-новной СУБД используется Lotus Domino Server R6.0.3 для функционирования объектной части МИС и MySQL 4.0.17 для реляционной составляющей системы. Разработка программного обеспечения ведется в среде Lotus Designer R6.0.2 и Borland Delphi 6 Professional SP3. В ходе изучения эффективных способов создания приложений для системы найдено несколько, на наш взгляд, интересных находок.

 

Во-первых, одной из самых существенных причин увеличения стоимости МИС считается высокая стоимость самой разработки. Изучив причины этого явления,  ученые  пришли  к  выводу,  что  не  последнюю  роль  в  этом  сыграла традиция создания медицинских информационных систем на основе так называемых АРМ-ов (автоматизированных рабочих мест). Причем зачастую под АРМ-ом понимается именно клиентское программное обеспечение, хотя изначально этот термин имел более широкое толкование. Чаще всего разработка АРМ-ов ведется по следующей методике: разработчики выбирают некоторую общую  задачу  (например,  создание  электронной  истории  болезни  для стационара), проектируют структуру  базы  данных,  разрабатывают приложение для работы с ней. Нередко это приложение выпол-няется в виде нескольких версий – АРМ главного врача, АРМ регистратора, АРМ лаборанта и т. д. Разработка систем в 65% случаев ведется на Borland Delphi. При этом даже на выпуск  очень  сырой  версии  АРМа  тратится  4-8  месяцев.  Затем  столько  же времени уходит на обкатку. Вместе с тем, по нашим оценкам, разработчику приходится 10-20% времени тратить на создание специфичного для медицинской области кода. Остальная часть, причем самая трудоемкая и ответственная, приходится на разработку механизмов, обеспечивающих целостность данных, подсистему безопасности и администрирования МИС, связь с периферийным медицинским оборудованием и т. д.

 

Однако, не вызывает сомнений, что эти решения значительно уступают промышлен-ным решениям для корпоративного рынка, над которыми трудятся лучшие специалисты и которые прошли многолетнюю проверку. В связи с этим вызывают недоумение подобные попытки «изобрести велосипед». На наш взгляд, разработка  МИС  не  должна  осуществляться  созданием  и  дальнейшей интеграцией  отдельных  АРМов.  Для  создания  МИС  необходимо  применять готовые программные платформы для групповой работы, уже имеющие в своем арсенале мощные средства для мультиплатформенной разработки программы, готовые технологии для развертывания и управления подсистемой безопасности. Многие разработчики выбирают пакет групповой работы Lotus Notes/Domino, разрабатываемый в настоящее время корпорацией IBM. Эта платформа является за рубежом стандартом «де факто» для создания мощных информационных систем, ориентированных на обработку электронных документов и мы считаем, что она наиболее подходит для создания медицинских информационных систем.

 

Работа над созданием МИС «Кондопога» на основе Lotus Notes/Domino версии 4.6 начата в сентябре 1999 года. Через 2 месяца МИС, включающая подсистемы работы врача, клинической и биохимической лаборатории, функциональной и рентгенологической  диагностики,  аптеки  и  планирования рабочего времени была поставлена в эксплуатацию. А еще через 2 месяца лечебное учреждение, использующее систему, полностью перешло на элек- тронный способ хранения информации, отказавшись от бумажных носителей.

 

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

 

Однако количество таких БД в МИС является вариабельным и зависит от количества функциональных групп пользователей, имеющихся в ЛПУ. Так, в стационаре это может быть выделенная БД для каждого отделения или корпуса. Для поликлиники – это могут быть БД, разделенные по участкам обслуживания. Кроме того, в этих БД специальным образом хранится только актуальная информация, а неиспользуемые данные помещаются в БД архива. Для решения ряда задач может быть принята либо связанная с объектно-ориентированным ядром реляционная БД, либо специальным образом сконструированные представления, ко-торые называют регистрами.

 

Проектирование  структуры  БД,  таким  образом,  позволяет  достичь стабильно малого объема БД МИС в течение практически всего срока ее эксплуатации, а тем самым обеспе-чить максимально возможную производительность работы МИС. Так, начиная с 1999 года база данных историй болезни пациентов, проходящих реабилитацию в медицинском центре, имеет объем  26-29  Мбайт.  При  этом  вся  информация  за  время  работы  центра сохранена,   а   скорость   работы   остается   стабильно   высокой.   Сложностью указанной методики является то, что программное обеспечение информационной системы должно поддерживать любое количество физических баз данных в ядре системы, объединенных в одну логическую структуру.

 

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

 

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

 

Доказано, что для эффективного решения такой задачи необходимо исключить в текстах программ МИС прямое обращение к базам данных. Взамен этого предложено использовать специальное промежуточное программное обеспечение, называе-мое сервисами middleware. С целью определения эффективности разработки системы с применением объектно-ориентированной технологии на основании использования сервисов middleware, авторами был выполнен анализ работы по созданию информационной системы в период 1999-2001 гг. Были получены следующие данные.

 

Использование однотипного программного кода в различных подсистемах МИС

 

Подсистема

Общий код

Уникальный код

 

% от всего

% времени

 

на разработку

% от всего

% времени

 

на разработку

 

% от всего

Документы ИБ и АК

45 10

55

90

 

Лабораторная подсистема

74

38

26

62

Статистика

17 9

83

91

 

 

Как представлено в таблице, в некоторых видах ПО доля повторяющегося кода со-ставляет значительную часть. Исключение его из этапа разработки нового приложения по-зволило сократить среднее время создания новой программы с 3,8 до 2,9 недель (на 23,68%).

 

Кроме этого, использование проверенных библиотек позволило значительно,  на   35-50%, сократить количество последующих  исправлений ошибок. Фактически вся основная работа над ошибками была связана с исправлением уникального кода приложения, в редком случае (в среднем 5-7 ошибок на 100 исправлений) исправлением используемых middleware-сервисов.

 

Анализ ошибок и исправлений в МИС

 

 

Подсистема

 

До применения middleware

 

После применения middleware

Количество ошибок

в неделю

Время ис- правления ч/неделю

Количество

ошибок

в неделю

Время исправления ч/неделю

 

Количество ошибок в неделю

Микроядро

системы

 

26

 

4,5

 

2,9

 

3,5

Статистика

8 6,2

1,3

0,8

 

Лабораторная

подсистема

 

1,2

 

3,4

 

0,2

 

1,2

Внешние

программы

 

13

 

14,2

 

2,5

 

6,5

Календари

3 4,4

0,4

1,2

 

 

Дополнительно с широким применением базовых библиотек класса middleware, выпол-ненных в виде динамически подсоединяемых библиотек (dynamic link libraries - DLL), было предложено встроить во все основные функции единый обработчик ошибок. В случае фатального прекращения работы какой-то функции middleware он пересылал системе результат, переданный по умолчанию, и дополнительно отправлял максимально возможную информацию разработчику по e-mail. Это позволило сократить время, необходимое на анализ и исправление ошибки в среднем на 45-55%. Нередко исправление ошибки производилось уже до того, как пользователь сообщал об этом программистам.

 

Необходимо отметить, что применение модели программного обеспечения системы на основе использования общих сервисов middleware позволяет применять эволюционный ме-тод, называемый в литературе Spiral Model [12, 18]. При этом возможно внедрение новых версий информационной системы путем простого подмена базовых сервисов на новые вер-сии. Эти версии могут работать как со старой информационной системой, так и с новой, без необходимости повторного обучения персонала или исправлений в структуре существующей базы данных.

 

Таким образом, применение сервисов middleware позволило в среднем увеличить появ-ление новых версий программ с 4 до 7 в месяц (на 75%), снизив удельную стоимость каждой новой версии на 22%. Применение указанных технологий позволило разработать систему со значительной экономией. Так, разработка крупнейшей отечественной МИС «Интерин» длится 9 лет, штат разработчиков насчитывает 25 человек. Разработка ИС, в которой принимают участие авторы, осуществляется 4 года и только 2 последних из них в ней постоянно участ-вует 2 программиста. Приняв, что данная МИС содержит только 50% от возможностей МИС «Интерин», зарплата одного программиста составляет около $300 (долл. США), а работа ведется 11 месяцев в году, получена экономия по сравнению с традиционными технологиями около $75900 в год. Таким образом, за 4 года работы стоимость разработки МИС на основе объектно-реляционного подхода составила 5,3% от суммы, которая потребовалась бы для создания МИС с применением традиционного подхода.

 

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

 

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

 

Трудозатраты администратора МИС

 

 

Вид деятельности

% общего времени

Примечание

1

Обслуживание вызовов пользователей на местах

38

 

2

Установка пакетов исправлений

17

 

3

Отправка сообщений об ошибках разработчикам

системы

7,8

 

4

Плановое обслуживание клиентских ПК (дефраг-

ментация диска, проверка на вирусы)

6,9

 

5

Знакомство с литературой

5

 

6

Анализ журналов безопасности

4

 

7

Установка новых приложений

3,5..45,7

45,7%

при вне-

дрении

системы

8

Контроль за новыми версиями ПО и публикация-

ми исправлений

3,2

 

9

Исправление сбоев в клиентских операционных

системах

0,1-2,1

Максимум

при Windows

95/98

10

Внесение исправлений в системные справочники,

текущие изменения настроек приложений

0,3-8,6

Максимум

при внедрении

11

Прочие

14,2

 

 

Следовательно, управляемыми факторами, способными сократить (перераспределить) трудозатраты технического персонала на обслуживание системы являются: установка при-ложений системы, установка исправлений (в т. ч. самой ИС и общесистемного ПО), контроль за новыми версиями ПО. Причиной высоких показателей в этих категориях является традиционный способ установки прикладного ПО: администратор сети запускает инсталляцион-ные пакеты на компьютерах пользователей, а затем по мере появления и т. н. «заплатки» к ним. Учитывая высокие показатели в выходе новых версий отдельных программ МИС на базе ООП, 1 администратор может обслуживать до 22-25 пользователей. По опыту, время от появления пакета исправлений до его полной инсталляции на всех компьютерах се-ти может составлять от 2-3 суток при работе 50 станций до 4-7 суток при работе 100-150 станций. Этот факт чреват тем, что злоумышленник может воспользоваться этим промежутком для нарушения системы безопасности или другого нанесения вреда, если он знает механизм ошибки, которую планируется исправить «заплаткой».

 

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

 

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

 

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

 

Если все проверки пройдены, исполняемый файл запускается.

 

Применение данной технологии позволило сократить время, необходимое на обновле-ние клиентского программного обеспечения с 2-3 дней до 5-10 сек. (в среднем), снизить за-траты ЛПУ на администрирование информационной системы на 47,8% за счет снижения трудозатрат администратора системы и возможности совмещения ставок программиста и администратора. Ежегодная экономия составляет около $72 на одного пользователя.

 

Концептуальная модель мис

 

Историческая справка

 

Первые попытки использования вычислительных устройств в здравоохранении  для  создания  больничных  информационных  систем предприняты   в   середине   50-х   годов   в   Соединенных   Штатах   Америки   с появлением на рынке универсальных компьютеров многоцелевого назначения. Первым проектом больничной информационной системы в США был проект МЕDINET, разработанный фирмой "General Electric".

 

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

 

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

 

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

 

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

 

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

 

  • разработка специализированного программного обеспечения для помощи врачам в принятии решений (экспертные системы);
  • разработка автоматизированных рабочих мест (АРМ) отдельных специалистов;
  • создание автоматизированной истории болезни и амбулаторной карты.

 

С началом массового распространения персональных компьютеров (в России, это начало 90-х годов) процесс компьютеризации больниц и других лечебных учреждений приобрел неуправляемый характер. Такими же неконтролируемыми стали разработка и внедрение специализированных АРМов врачей. Практически во всех медицинских учреждениях для собственных нужд разрабатывались многочисленные АРМы диагностов, клиницистов, фармацевтов, медицинских регистраторов, статистиков и т. п., которые в дальнейшем попадали на рынок программных средств и предлагались к широкому распространению. Даже в одной и той же больнице для разных отделений создавались или приобретались разные, несовместимые между собой автоматизированные системы, которые, безусловно, облегчали труд отдельных специалистов, но не давали значимого эффекта для учреждения в целом. Некоторые из таких АРМов, в основном разработанные собственными программистами или врачами- энтузиастами, продолжают работать и по сей день. Использование других постепенно сошло на нет в связи с изменениями технологии работы и отсутствием поддержки со стороны разработчиков, что неизбежно сопровождалось большими финансовыми потерями. Этот период можно охарактеризовать как время «дикой» автоматизации.  Вместо  пользы,  она  больше  отпугивала,  мешала  работе  и  у людей начал складываться стереотип о медицинской информационной системе, как о громоздкой, очень сложной и малоэффективной куче компьютеров и программного обеспечения.

 

Лишь с конца 90-х годов и, особенно, в наши дни все актуальнее становится централизованный подход к автоматизации. Его принципиальными отличиями являются:

 

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

 

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

 

  1. Локальные БД. (47% систем). Такой подход характерен для систем начального уровня или узких специализированных программных продуктов.
  2. Общая БД, располагающаяся на файл-сервере (21%). Позволяет значительно сократить время на разработку и применяется при простых заданиях и ограниченном числе клиентов. Также такой подход характерен для специализированных баз данных. Примером удачного использования данного подхода   может   служить   норвежская  система   выполнения,  расшифровки  и хранения ЭКГ CardioConcept.
  3. Архитектура «клиент-сервер». По этому принципу построено 32% всех проанализированных нами информационных систем. Принципиальное отличие - две крупные программные части. Сервер устанавливается на выделенный компьютер сети и управляет базой данных, принимает, обрабатывает и отправляет ответы на запросы от клиентов. Задача клиента – обеспечение интерфейса между системой и пользователем, формирование и отправление запросов к серверу БД, получение и обработка ответов, вывод результатов на экран. Данный подход используется в подавляющем большинстве крупных медицинских информационных систем.

 

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

 

Принципиальная модель системы

 

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

 

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

 

Группа программ

Назначение

%

 

Медицинская деятельность

Управление движением медицинской информации. Сбор статистики.

 

62

 

Финансово-хозяйственная деятельность

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

 

23

Административная деятельность

 

Учет кадров, обучение сотрудников.

 

12

Научная работа

Сбор данных для научного анализа.

3

 

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

 

Название

%

Автоматизированные рабочие места врачей

38

Автоматизированные системы для медицинской статистики (в т.ч. учет движения больных)

 

31

Лабораторные информационные системы

13

Аптечные информационные системы

9

Системы архивирования и передачи диагностических данных

3

Телемедицинские системы

3

Другие

3

 

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

 

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

 

Выбор базы данных

 

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

 

  • переносимость;
  • масштабируемость;
  • простота администрирования;
  • минимальные требования к аппаратной части;
  • низкая стоимость ПО или возможность получить его бесплатно.

По нашему мнению, кроме перечисленных условий, современных сервер медицинской информационной системы должен:

 

  • соответствовать архитектуре – «клиент-сервер»;
  • иметь документно-ориентированный способ хранения информации;
  • иметь мультиплатформенность для увеличения гибкости развертывания системы и удешевления внедрения;
  • автоматически выполнять резервное копирование баз данных и основных приложений;
  • иметь надежную и проверенную временем систему безопасности.

 

При этом ключевым фактором остается вид базы данных. На сегодняшний день существуют 2 принципиально разных вида баз данных: реляционный и постреляционный (документно-ориентированный). К первому относится подавляющее большинство промышленных БД: MS SQL Server, Oracle, Inter Base и т. д. Ко второй группе можно отнести Lotus Notes/Domino и СУБД Cache.

 

Особенности реляционных баз данных

 

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

 

Особенности документно-ориентированных БД

 

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

 

При разработке ИС второй тип БД представляется наиболее эффективным по следующим причинам:

 

  • т.к. сложно предусмотреть все виды информации, которую необходимо будет хранить в БД, поэтому не исключены случаи, когда даже в работающий вариант необходимо будет добавлять новый признак или поле. Понятно, что при реляционном способе это вызовет больше трудозатрат программиста;
  • БД большой по масштабам ИС при реляционном способе представляет собой большое количество самых разных таблиц с множественными связями и индексами. Структуру такой БД графически трудно описать, а уж тем более спроектировать и оптимизировать ее;
  • особенность медицинской информации состоит в том, что ее очень трудно систематизировать и представить в табличном виде. При этом из-за разнообразия документов представление их в виде таблиц обречено на низкую эффективность использования дискового пространства. Этот недостаток особо отмечают многие авторы, говоря о содержании множества пустых полей в таблицах реляционных баз данных в случае их применения в медицине;
  • работа с таблицами для медицинского работника является существенным отличием от привычного способа работы с документами. Поэтому человеку психологически легче перейти от бумажной истории болезни к ее электронному аналогу, который выполнен в виде привычных документов.

 

Система безопасности сервера

 

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

 

  • протоколы (или порты в случае использования TCP/IP), по которым осуществляется доступ к БД, должны быть настраиваемыми. Если доступ к БД возможен при помощи специализированного клиента или через протокол http, то сервер должен предоставлять администратору системы возможность выбирать или запрещать доступ через определенный порт;
  • сервер должен иметь возможность разделения прав доступа на различных уровнях – от уровня конкретного поля (ячейки таблицы) до целой базы данных или всего сервера, включая и находящееся на нем прикладное программное обеспечение;
  • сервер должен быть снабжен системой протоколирования доступа, ведя так называемые журналы обращений к серверу. Кроме того, необходима возможность оценки успешных обращений к серверу, ошибок в его работе, случаев отказа в доступе или других нарушений политики безопасности;
  • сервер должен поддерживать современные средства шифрования данных и трафика, передающегося по сети, в том числе с поддержкой открытых ключей, SSL-сертификатов   и   других   технологий,   которые   уже   прошли   испытание временем и заслуживают доверия.

 

Резервное копирование

 

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

 

  • Основными причинами использования резервного копирования являются выход из строя компонентов сервера (например, жесткого диска) или программные ошибки,  которые  могут  привести  к  разрушению  базы  данных.  При  выборе решения о резервном копировании эти причины необходимо учитывать.
  • Резервное копирование целесообразно осуществлять на отдельный компьютер или, по крайней мере, на отдельной устройство на сервере. Возможно комбинирование, когда резервирование осуществляется и на рабочую станцию и на дополнительный жесткий диск.
  • Объектами резервного копирования в обязательном порядке должны быть: основные файлы операционной системы и ее настроек, основные файлы программного обеспечения сервера баз данных, файлы самих баз данных, журналы системы безопасности, программы медицинской информационной системы.
  • Частота резервного копирования должна зависеть от объекта, который копируется. Так, резервное копирование операционной системы целесообразно проводить перед внесением в нее серьезных изменений, например – установкой нового программного обеспечения. Резервное копирование баз данных должно осуществляться регулярно, автоматически и по расписанию. При планировании расписания следует выбирать оптимум между загрузкой сервера и частотой резервирования информации. С определенной периодичностью необходимо записывать резервные копии на внешние носители информации, например – CD или DVD диски и хранить этот архив в отдельном месте.
  • При осуществлении резервного копирования на рабочую станцию или резервный сервер их целесообразно размещать в отдельном помещении. При этом исключаются такие факторы, как пожар, разрушение помещения сервера и т.д.
  • Права на осуществление резервного копирования и восстановления файлов на сервер должны быть строго ограничены. В небольших учреждениях этим правом должен обладать только администратор системы. В крупных учреждениях этим правом могут дополнительно обладать несколько пользователей из числа технического персонала или программисты.
  • Для контроля над осуществлением резервного копирования необходимо вести специальный журнал, в котором отмечать факты резервирования операционной системы, баз данных и других файлов. Периодический контроль над резервированием должен осуществлять главный врач медицинского учреждения или другое ответственное лицо.

 

Репликация

 

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

 

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

 

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

 

Репликация – мощнейший инструмент, особенно ценный для медицинских информационных систем. Перечислим лишь основные преимущества от ее применения.

 

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

 

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

 

Масштабируемость и распределенность

 

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

 

Некоторые современные серверы БД (MS SQL Server 7.0 под управлением MS Windows 2000 Advanced Server или Lotus Domino Server R4.6 или R5) позволяют по другому решить проблему масштабирования. Несколько серверов объединяются в так называемый «кластер» - для пользователя такой кластер «видится» как один сервер. При определенной загрузке сервера работу продолжает (или берет часть нагрузки на себя) второй член кластера. Таким образом, происходит распределение нагрузки. Кроме этого,  объединение серверов в кластер позволяет добиться следующих существенных преимуществ:

 

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

 

Учитывая все вышесказанное, для ИС необходимо выбирать серверы БД,способные работать в кластере.

 

Одним из способов увеличения производительности системы служит принцип распределенной БД. Мы выделяем 2 основных подхода: распределенность программную, когда информация распределяется по нескольким БД, которые затем связываются. При этом могут быть выделены архивные  БД  и  БД  для  текущей  (оперативной)  работы.  Второй  подход  – аппаратное распределение БД.

 

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

 

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

 

  • Резервные серверы выполняют следующие задачи:
  • резервное копирование информации с основных серверов;
  • функционирование дополнительных служб – например, серверов DNS, DHCP, WINS, печати и т. д.;
  • файл-сервер для доступа к дистрибутивам ПО или архивам документов.

 

Мультиплатформенность

 

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

 

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

 

Бухгалтерские, статистические и  другие  не  основные  программные продукты выполняются под платформой Microsoft Windows, являясь тем самым частично мультиплатформенными продуктами. Кроме этого, мультиплатформенность может  стать существенным  (хотя  и  косвенным) фактором, удешевляющим внедрение системы, так как отпадает необходимость

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

 

Архитектура системы

 

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

 

Опишем назначение и особенности каждого уровня ИС.

 

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

    • список ОС, поддерживаемых ИС;
    • надежность;
    • доступность в использовании;
    • легкость в освоении;
    • цена;
    • удобство в администрировании (значимость этого фактора растет с числом клиентов в сети). 
     
  2. Уровень клиентского ПО системы - приложения системы, с которыми осуществляет свою работу пользователь. Здесь мы разделяем все клиентское ПО на 2 группы: основное и вспомогательное. При этом для функционирования вспомогательного ПО добавляется новая прослойка – программный интерфейс системы, т. е. набор специального ПО, которое принимает вызовы от вспомогательного приложения, транслирует его в запросы к серверу БД, и используя средства клиента, отправляет их серверу. Целями такого разделения явились следующие причины.
  • Уменьшение количества функций, которые встраиваются в ядро клиентского ПО. Суть этого требования состоит в том, что основное ПО клиента должно уметь делать только основные или наиболее часто востребованные функции. При этом качество разработки и трудозатраты программиста самые высокие.
  • Увеличение производительности работы  основного  ПО.  Это  требование совершенно логично. Самые востребованные функции клиент должен выполнять с самой высокой производительностью. За счет этого происходит экономия времени   работы с компьютером, повышение эффективности использования системы и т. д. Только с этой целью основное клиентское ПО может обращаться к серверу БД напрямую.
  • Увеличение  гибкости  системы.Не  секрет, что  адаптация ИС к нуждам конкретного лечебного учреждения требует     зачастую участия разработчиков самой системы. ПО сервера и клиента заказчик закупает и устанавливает сам. При инсталляции системы устанавливается основное ПО (которое изменить может только разработчик  системы), вспомогательное ПО и детальное описание интерфейса системы – вызовов библиотек, стандартных функций системы по поиску данных, доступу к историям болезни и т.д. Если заказчика не устраивает функциональность системы или    ему    требуются дополнительные возможности,  не предусмотренные разработчиком, он может либо заказать такое ПО у разработчика системы. Оно будет выполнено в виде дополнительного приложения и не потребует переустановки или настройки основного ПО, либо разработать его самому.
  • Уменьшение  трудозатрат   программиста  на   создание  нового   ПО   или внесение изменений в существующие приложения.
     

К основному ПО относим те приложения, которые врачи используют в своей работе для выполнения своих основных функциональных обязанностей. Так, для врача – это работа с амбулаторными картами и историями болезни.
К дополнительному ПО отнесены вспомогательные приложения для всех медицинских работников и остальное ПО прочих сотрудников, таких как бухгалтеры, специалисты по медицинской технике и т. д. Сюда же мы относим программы, которые могут использоваться специалистами в повседневной работе (например – справка о движении больных), но в силу специфичности задачи или невысоких требований к  производительности работы могут  быть  выполнены в виде дополнительных приложений.
К программному интерфейсу системы мы относим специальное ПО, инкапсулирующее в себе возможности клиента базы данных  и взаимодействующее уже не с сервером базы данных, а с системой. Например, в случае  распределенной  БД  поиск имеющихся в системе архивных  историй болезни является нетривиальной задачей. Конечно, можно встроить этот алгоритм в саму программу. А что, если ядро системы или архитектура ее будет изменена? Вносить изменения во все имеющиеся программы медицинской информационной системы? А если таких приложений десятки, а их инсталляций - сотни? Именно поэтому целесообразнее переносить все прямые запросы к БД в промежуточное ПО. В случае надобности только в программный интерфейс вносятся изменения, а готовые и установленные приложения не потребуют переделки и переустановки. Кроме этого, при использовании такого ПО значительно увеличивается скорость разработки новых программ. Не секрет, что значительное число функций даже нового приложения содержит однотипные действия - подключиться к серверу, осуществить поиск, обработать ответ и т. д. Используя уже готовые и отлаженные модули из программного интерфейса системы, программист экономит время. Примером эффективного способа для создания программного интерфейса является использование в среде Windows динамических подсоединяемых библиотек (dynamic link libraries - DLL).

 

   

3.

 

 

 

 

  Уровень клиента БД. Клиент БД осуществляет диалог с основным и дополнительным ПО, выполняет проверку пароля пользователя и, самое главное, формирует запросы к серверу БД, осуществляя с ним диалог. Работа основного ПО у некоторых БД осуществляется прямо в клиенте (Lotus Notes), обеспечивая интерфейс  пользователя, справку, дополнительные  возможности  типа электронной почты и т. д. Работа других клиентов (InterBase) состоит только в обеспечении программной возможности доступа к серверу БД.
         
   

4.

 

 

 

 

 

 


  Сеть и сетевой протокол. Клиент БД обращаясь с запросом к серверу, должен передать его по сети. При этом он должен поддерживать хотя бы один сетевой протокол. На этом уровне учитывается список поддерживаемых сетевых протоколов клиентов и сервера и решается вопрос об использовании конкретного или нескольких протоколов. Это решение влияет на производительность системы в целом, возможности ее масштабирования, простоту и надежность в работе и управлении. Наиболее распространенным на сегодня является протокол TCP/IP, используемый  в   сегментированных сетях и  Internet. Мы также  считаем  его предпочтительным  при  выборе.  Кроме  того,  этот уровень является  еще  и разделительным, – все последующие уровни относятся к серверу БД.
         
   

5.

 

 


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

6.


  Уровень текущих документов. Небольшие по объему БД, которые содержат только текущие документы, позволяют осуществлять максимально производительную работу системы.
         
   

7.

 

 

 

 

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

 

Безопасность информационной системы

 

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

 

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

 

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

 

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

 

Использование сетей передачи данных может быть применено с целью перехвата или модификации данных, заполнению сети ложными пакетами информации и другими действиями, направленными на выход из строя сетевого оборудования или серверов. Охрана территорий, на которых расположены средства связи (информационный кабель, усилители сигнала – репитеры и т. д.) имеет высокую важность. На это указывает Емельянов А. В. и соавт., для которых обеспечение безопасности передачи информации по распределенной на значительной территории сети Медицинского центра Управления делами Президента Российской Федерации стало серьезной проблемой.

 

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

 

  • средства распределения прав доступа гарантируют возможность получения доступа только к той информации и программам, которые необходима для выполнения  функциональных  обязанностей.  При  этом  во  всех  отношениях «Пользователь - Система – Информация» роль координатора выполняет администратор системы, имеющий максимально возможные права доступа. Главное из них – возможность предоставлять или ограничивать доступ всех остальных пользователей и других служащих к системе;
  • средства протоколирования использования БД позволяют четко контролировать доступ к ресурсам ИС, попытки несанкционированных действий или превышение пользователями своих прав;
  • средства шифрования БД и сетевого трафика позволяют гарантировать, что во время передачи информации по каналам связи в случае ее перехвата она не сможет быть прочитана «злоумышленником»;
  • средства сокрытия кода приложений ИС гарантируют, что попытка чтения кода приложений ИС   невозможна   или   крайне   затруднена. Эта  необходимость существует из соображений, что в случае анализа исходного кода могут быть обнаружены слабые места в системе безопасности, которыми злоумышленник сможет воспользоваться.

 

Распределение прав доступа

 

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

 

  1. Началом работы является аутентификация. При этом используется учетная запись пользователя, которая образуется открытым именем пользователя и зашифрованным паролем. Учетная запись каждого пользователя хранится в определенном виде в ИС. Например, Windows NT использует так называемую базу данных учетных записей, которые хранятся на контролерах домена NT. Lotus Notes хранит учетную запись пользователя в виде id-файла, который может помещаться на сервере, локально на рабочей станции пользователя или на дискете. При выполнении процедуры идентификации пользователь вводит свое имя и пароль, которые затем проверяются системой на правильность.
  2. В случае выполнения первого шага для пользователя открывается сеанс связи с сервером. Все последующие действия выполняются от имени учетной записи, для которой он успешно ввел пароль.
  3. При доступе к БД сервер проверяет, имеется ли у текущего пользователя права на ту информацию, которую он запрашивает. В случае положительного решения информация предоставляется пользователю. В случае отрицательного решения пользователю отказывается в доступе.

 

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

 

  • информация, хранящаяся в БД;
  • приложения, входящие в состав пакета программ системы;
  • команды и функции в приложениях, которые могут использоваться с различным уровнем доступа.

 

Список управления доступом к информации в БД ИС должен указываться для:

 

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

 

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

 

  1. Вычислением на основании политики доступа или иного алгоритма;
  2. Наследованием от его предка. Например, документ истории болезни может наследовать (копировать) ACL бланка истории болезни.

 

Изменение ACL возможно несколькими способами.

 

  1. Программным изменением, когда изменить ACL объекта может только приложение системы.
  2. Пользовательским изменением, когда пользователь вручную может корректировать ACL объекта.

 

Реакция системы на изменение ACL может быть различной. Изменение ACL сервера, каждой отдельно взятой БД или приложений, некоторых документов или отдельных полей должны протоколироваться в обязательном порядке. Администратор системы должен тщательно следить за протоколами этих изменений.

 

Реакция на проверку наличия текущего пользователя в ACL может быть в виде:

 

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

 

О поддержке стандартов

 

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

 

  • стандарт не утвержден de jure, а поэтому носит рекомендательный характер;
  • в стандарт постоянно вносятся изменения;

 

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

либо в уже имеющийся модуль.

 

Мобильный доступ

 

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

 

  • 25% сотрудников медицинских учреждений считают мобильный доступ к данными ИС ненужным;
  • 31% полагают, что такая возможность время от времени будет востребована;
  • 44% констатировали, что мобильный доступ является для них обязательной необходимостью.

 

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

 

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

 

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

 

  1. справочник препаратов, в т. ч. наркотиков (62% опрошенных);
  2. адресная или телефонная книга (56%);
  3. архивы медицинской документации пациентов (56%);
  4. паспортные данные пациентов (56%);
  5. текущие данные пациентов (50%);
  6. периодическая литература и справочная информация, в т.ч. кодировки болезней и т. д. (43%);
  7. доступ в Internet (37%);
  8. книги в электронном виде (30%).

 

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

 

  1. Ночные дежурства.
  2. Вызовы на дом.
  3. Скорая медицинская помощь.
  4. При хирургических вмешательствах.
  5. Консилиумы.
  6. Диалоги с пациентами.
  7. Врачебные практикумы.
  8. Врачебные круглые столы.

 

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

 

  • Доступ с переносного компьютера, такого как ноутбук. Средством связи может быть  мобильный  телефон.  Стоимость такого  решения,  однако,  является  на сегодня очень существенной. Кроме высоких цен на сами портативные компьютеры (сходный по конфигурации с настольным компьютером ноутбук стоит в среднем в 1,5 – 2 раза дороже). Дорогой пока остается и сотовая связь. В качестве альтернативы можно использовать радиодоступ через специальные передатчики, работающие как обыкновенная сетевая карта. Однако дальность такой связи ограничена. Преимуществом этого подхода является возможность полнофункциональной работы медицинского работника, как будто он работает со стационарной рабочей станцией у себя в кабинете.
  • Доступ при помощи карманных компьютеров, таких как, например, Apple Newton. Связь у них также используется через сотовые телефоны, однако стоимость их значительно ниже ноутбуков. Недостатком является то, что эти компьютеры используют собственные операционные системы, и для них необходимо разрабатывать  специальное  программное обеспечение. Кроме того, они снабжены маленькими дисплеями (в среднем, размером 20х12 см), небольшим объемом памяти. Они имеют невысокую производительность в работе. Однако такие устройства имеют небольшие размеры и вес (порядка 500 г) и очень быстро включаются.

 

Следует  отметить, что наряду с возможностью мобильного доступа, необходимой  является  также  и  возможность  удаленного  соединения  с  сетью медицинской информационной системы. Для этого она должна иметь специальные устройства или службы для соединения по телефонным линиям – Remote  Access  Server  (сервер  удаленного доступа). Подобную необходимость отмечают многие отечественные и зарубежные авторы. Так, Боцвинов А. Н. и соавторы в описании своей системы «Эверест», разработанной еще в 1993 году, отмечают,  что  любой пользователь при наличии соответствующих  прав и оборудования, должен иметь возможность получения удаленного доступа.

 

Поддержка телемедицины


Термин «телемедицина» был введен в медицинскую литературу R.G. Mark в 1974  году. В  настоящее  время можно найти множество ее определений.

Приведем некоторые из них.

 

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

 

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

 

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

 

  • диагностика и обеспечение консультаций на расстоянии. При этом, в основном,  между  специалистом  и  другим  медиком  (врачом  или медсестрой);
  • дистанционное обучение.

 

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

 

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

 

Отметим основные преимущества от внедрения телемедицинских функций в ИС:

 

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

 

Выделим основные телемедицинские задачи ИС:

 

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

    • Отложенная  консультация  –  это  процесс обмена информацией, когда пациент записывается на нее, при   необходимости формируется электронное описание его жалоб, анамнеза заболевания, проведенного лечения и обследования. Вся эта информация переносится в специальную базу данных удаленного консультанта. Время от времени консультант читает сформированный для него список записей, выполняет консультации.
    • При консультации в режиме реального времени консультанту по системе обмена сообщений (например, электронной  почте) отправляются необходимые данные о пациенте. Как только он получает их, немедленно отвечает на запрос. Такие возможности достаточно просто выполнить. Для этого в программу планирования рабочего времени необходимо добавить возможности работы через Internet, записи пациента с указанием анамнеза и других данных. В подсистемы врачей необходимо встроить поддержку отправки документов по электронной почте.
     
  2. Консилиумы и видеоконференции. В рамках ИС для этих целей должно применяться специальное программное обеспечение, т. к. существует реальная необходимость организации связи между врачами (с возможным участием пациента) и передачей видеоинформации. Примером может служить программа Microsoft NetMeeting, входящая в комплект поставки операционной системы Windows.
  3. Дистанционное обучение. Использование ресурсов сети Internet, таких как электронные библиотеки полнотекстовых статей, доступ к архивам интересных клинических случаев, записей редких видов патологии и т. д.

 

Разработка и внедрение информационной системы

 

Как отмечает G.A.Claudio с соавторами в своей статье «A Software Engineering Approach to the Development of Computer-Based Patient Record Systems», необходимо разделять следующие этапы разработки ИС.

 

  • Анализ требований и спецификация. Требования – это потребности пользователей. Это очень важно для полного понимания будущих возможностей программного  обеспечения.  Анализ  требований  должен  привести  к концептуальной модели всех данных, которые затем будут необходимы для обработки медицинской информации всеми подсистемами ИС. При этом должна быть составлена полная спецификация субъекта системы – т.е. медицинской информации. Как показывает практика, большинство ошибок, обнаруженных в период испытания или эксплуатации, вызвано ограниченным или плохими интерпретациями требований пользователей.
  • Создание проекта. Если основное назначение спецификации – это описание того, что система будет делать, то его цель – это описание, как система будет это делать.  При  этом  можно  выделить  три  этапа  проектирования.  Структурный проект, когда на основании спецификации описывается строение будущей базы данных. Затем – архитектурный проект, описывающий будущие подсистемы и их взаимосвязи. Последним идет процедурный проект, описывающий конкретные возможности и функции взаимодействия каждой из подсистем с базой данных и пользователем. Ключевой момент – проектирование интерфейса системы между программным обеспечением и пользователем. Следует учитывать возможности современного  ПО и  требований  эргономики.  Качественный,  удобный  и интуитивно-понятный интерфейс будет существенным образом определять успех системы.
  • Выполнение. Суть этой стадии – транскрипция проектов в код реального программного обеспечения. Выбираются средства разработки, конкретная платформа   операционной   системы   и   сервера   базы   данных.   Необходимо отметить, что  в  настоящее время  пакеты  для  разработки ПО  становятся все проще и мощнее. Уже обязательной возможностью считается визуальное проектирование, когда программист строит свои приложения, используя готовые модули, как кубики. Примером могут служить все современные пакеты для разработчиков – Borland Delphi, Microsoft Visual Fox Pro, Microsoft Visual Studio. Net и т.д.;
  • Испытание.  Цель  этого  этапа  –  гарантия  соответствия  спецификации  и отсутствия ошибок на момент внедрения программного обеспечения. Существует много видов испытаний - установка, приемные испытания и т.д. На этом этапе используется специальная группа пользователей – бета-тестеры. Они устанавливают программное обеспечение, производят его тестирование и сообщают команде разработчиков свои результаты и пожелания;
  • Внедрение и сопровождение занимает около 60-70% всего жизненного цикла ИС. При этом обязательно идет оценка качества программного продукта, рентабельности, надежности работы и безопасности. Группе программистов крайне необходимо протоколировать все вносимые изменения и их причины, а также свои наблюдения и мысли, которые затем могут пригодиться в дальнейшей работе.

 

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

 

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

 

В литературе мы можем встретить определение Spiral Model для эволюционного пути развития. Как отмечает G. A. Claudio, при этом на каждом цикле жизни ИС создаются новые функции и она развивается по спирали, не теряя связи с пользователем – т. е. эволюционирует.

 

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

 

  • наличие переходного периода, когда возрастает загруженность персонала, использующего систему. К  тому же, это  самый нестабильный период работы, когда из-за неполного использования старой и новой версий системы возможны различные сбои в работе программного обеспечения;
  • необходимость  радикально  переучивать  персонал,   т.к. при такой смене разработчики стараются использовать    самое современное    программное обеспечение и интерфейс;
  • большие расходы на замену устаревшего оборудования, покупку лицензионного программного обеспечения;
  • в крупных  учреждениях, таких  как,  например,  Центральная  клиническая больница Медицинского центра Управления делами Президента РФ, период перехода на новую версию системы занял значительное время - 4 года с 1995 по 1999 г.г.

 

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

 

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

 

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

 

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

 

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

 

Заключение

 

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

 

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

 

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

 

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

 

Ситуационный мониторинг. Регулярное получение определенной общей картины состояния проблемы среди населения республики (например, ежегодный теле- фонный опрос населения).

 

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

 

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

 

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

 

Литература

 

  1. Эльянов М М. Медицинские информационные технологии. Каталог. Вып. 5. —М.: Третья медицина, 2005. — 320 с.
  2. Назаренко Г.И., Гулиев Я.И., Ермаков Д.Е. Медицинские информационные системы: теория и практика. — М.: Физматлит, 2005. — 320 с.
  3. Гусев   А.В.,   Романов   Ф.А.,   Дуданов   И.П.,   Воронин   А.В.   Медицинские информационные системы. — Петрозаводск: Изд-во ПетрГУ, 2005. — 404 с.
  4. Рот   Г.З.,   Фихман   М.И.,   Шульман  Е.И.   Медицинские  информационные системы. Учебное пособие. — Новосибирск: Изд-во НГТУ, 2005. — 70 с.
  5. И. А. Красильников, Э.Р. Усеинов. Ресурсы информационных технологий в системе здравоохранения Санкт-Петербурга // Информационные технологии в здравоохранении: Доклады VI Санкт-Петербургской   международной конференции  “Региональная  информатика  —  98”.  СПб.,  1998.  С.  70-72 (доступ в нтернете:www.ctmed.ru/InfoServ/MedSci/health/index.html)
  6. Эльянов М М. Медицинские информационные технологии: цивилизованный рынок или “зоопарк” // Информационные технологии в медицине-2002: Сборник тезисов. М.: ВК ВВЦ “Наука и образование”, 2002. С. 54—58.
  7. Гусев  А.В.,  Романов  Ф.А.,  Дуданов  И.П..  Опыт  разработки  медицинской информационной системы //Медицинский академический журнал. – 2001. –№1. – С.18.
  8. Гусев    А.В.,    Романов    Ф.А.,    Осиик    Т.А..    Применение    медицинской информационной системы в работе клинических лабораторий медицинского центра //Медицинский академический журнал. – 2001. – №1. – С.19.
  9. 3. Гусев А.В., Дуданов И.П. Оценка 3-летнего опыта разработки и внедрения информационной системы:    выводы    и    перспективы.    //Медицинский академический журнал. – 2002. – Том 2, – С.56-57.
  10. 4. Гусев А.В., Романов Ф.А., Дуданов И.П., Воронин А.В. Информационные системы в здравоохранении. Петрозаводск: Изд-во ПетрГУ.– 2002. – 120с.
  11. Дуданов И.П., Гусев А.В., Романов Ф.А., Воронин А.В., Рузанова Н.С., Кемпи С.И. Информационная система в  здравоохранении – концептуальная модель //Сердечно-сосудистые заболевания. Бюлле-тень НЦССХ им. А.Н. Бакулева РАМН. – 2002. – №11. – С.332
  12. Дуданов  И.П.,  Гусев  А.В.,  Романов  Ф.А.,  Воронин  А.В.  Информационные системы в здравоохранении //Медицинский академический журнал. – 2002.№1. – С.58-77.
  13. Дуданов  И.П.,  Гусев А.В., Романов Ф.А., Кемпи С.И. Региональная информационная система «Кондопога» //Сердечно-сосудистые заболевания. Бюллетень НЦССХ им. А.Н. Бакулева РАМН. – 2002. – №11. – С.335.
  14. Дуданов И.П.,  Гусев  А.В.,  Романов  Ф.А.,  Кемпи  С.И.,  Цымлякова  Л.С., Дмитриев А.Г.  Создание «паспорта здоровья»   больных с сердечно- сосудистыми  заболеваниями  с  использования  информационной  системы.//Медицинский академический журнал. – 2003. – №3. – С.125-133.
  15. 15. Осиик Т.А., Дуданова О.П., Гусев А.В. Организация работы клинико-диагностической лаборатории в рамках информационной системы.//Медицинский академический журнал. – 2001. – Том 2. – С.52.
  16. 16. Романов Ф.А., Гусев А.В. Опыт использования больничной инфор-мационной системы в   санатории-профилактории  ОАО   «Кондопога»   //Медицинский академический журнал. – 2001. – №1. – С.54.
  17. Романов Ф.А., Гусев А.В. Применение электронной системы планирования рабочего  времени  при  организации  лечебно-диагностического  процесса.//Медицинский академический журнал. – 2001. – № 1. – С.54.
  18. Романов  Ф.А.,  Дуданов   И.П.,  Гусев  А.В.  Организация  работы  центра реабилитации и стационара с  использованием информационной системы.//Медицинский академический журнал. – 2001. – Том 2. – С.55.
  19. Романов  Ф.А.,  Дуданов  И.П.,  Гусев  А.В.,  Кемпи  С.И.,  Богданова  В.С.Диспансеризация больных  с  хирургической патологией  с  использованием информационной системы. //Медицинский академический журнал. – 2003. –№2. – С.149-50.
  20. Русских Н.В., Романов Ф.А., Дуданов И.П., Гусев А.В. Перспективы создания клинико-диагностического отделения в центре здоровья ОАО «Кондопога» с использованием информационных систем. //Медицинский академический журнал. – 2001. – Том 2. – С.53-54.
  21. Айламазян А.К., Гулиев Я И. Данные, документы и архитектура медицинских инфор-мационных систем. http://interin.botik.ru
  22. Айламазян А.К.,  Гулиев  Я.И.,  Матвеев  Г.Н.,  Турна  И.А.,  Белова  И.А.  ИС КОТЕМ-2001: Требования, проблемы, решения. http://interin.botik.ru
  23. Андерсон К., Минаси М. Локальные сети. Полное руководство: Пер. с англ. –К.: ВЕК+, ЭНТРОП, Спб.: КОРОНА принт, 1999. – 624 с., ил.
  24. Андреев А.М., Березкин Д.В., Кантонистов Ю.А. Выбор СУБД для построения инфор-мационных систем корпоративного уровня на основе объектной парадигмы // СУБД 1998. - № 4-5. - С. 26-50, — М: «Открытые системы»,1998.
  25. Губин И.М., Тарасов В.В., Антонов Р.А. и другие. Разработка и внедрение новой авто-матизированной информационной системы ЦКБ // Кремлевская медицина. Клинический вестник, 2000. - №4. - Стр. 51-54.
  26. Гусев  А.В.,  Романов  Ф.А.,  Дуданов  И.П..  Опыт  разработки  медицинской информаци-онной системы // Медицинский академический журнал, 2001. -№1. - Приложение 1. - Стр. 18.
  27. Гусев А.В.,  Романов Ф.А., Осиик Т.А.. Применение медицинской информационной системы в работе клинических лабораторий медицинского центра // Медицинский ака-демический журнал, 2001. - № 1. - Приложение 1.- Стр. 18.
  28. Гусев А.В., Дуданов И.П. Оценка 3-летнего опыта разработки и внедрения информаци-онной системы: выводы и перспективы // Медицинский академический журнал, 2002. - Том 2. - Приложение 2. - Стр. 56-57.
  29. Гусев  А.В.,  Дуданов   И.П.,  Романов  Ф.А.   Информационная  система  в медицине – кон-цептуальная модель. http://surgery.karelia.ru
  30. Гусев А.В., Романов Ф.А., Дуданов  И.П., Воронин А.В., Информационные системы в здравоохранении. ПетрГУ. Петрозаводск, 2002. - 120 с.
  31. Дуданов И.П., Гусев А.В., Романов Ф.А., Воронин А.В. и соавт..Информационная система в здравоохранении – концептуальная модель // Сердечно-сосудистые заболева-ния. Бюллетень НЦССХ им. А. Н. Бакулева РАМН. Том 3. - № 11. - 2002. - Стр.332.
  32. Дуданов  И.П.,  Гусев  А.В.,  Романов  Ф.А.,  Воронин  А.В.  Информационные системы в здравоохранении // Медицинский академический журнал, 2002. -№ 1. - Том 2. - Стр. 58-77.
  33. Дуданов   И.П.,   Гусев   А.В.,   Романов   Ф.А.,   Кемпи   С.И.   Региональная информационная система «Кондопога» // Сердечно-сосудистые заболевания. Бюллетень НЦССХ им. А. Н. Бакулева РАМН. 2002. - Том 3. - № 11. - Стр.335.
  34. Дуданов  И.П.,  Гусев  А.В.,  Романов  Ф.А.,  Кемпи  С.И.  и  соавт.  Создание «паспорта здо-ровья» больных с сердечно-сосудистыми заболеваниями с использования информацион-ной системы // Медицинский академический журнал, 2003. - Том 3. - № 3. - Стр. 125-133.
  35. Ильмаст А.В., Марусенко К.М., Моисеев Е. В. Некоторые вопросы технологии разра-ботки МИС // Медицинский академический журнал, 2002. - Том 2. - Приложение 2. - Стр. 85-86.
  36. Принципы проектирования и разработки программного обеспечения.Учебный курс MCSD: Пер. с англ. – М.: Издательско-торговый дом “Русская редакция”, 2000. – 608 стр.: ил.
  37. Шеррер Жан-Рауль. Информационные системы в здравоохранении:технология и орга-низация // Кремлевская медицина. Клинический вестник,2000. - № 4. - Стр. 15-17.
  38. Claudio  G.  A.  da-Costa,  MD,  Rodrigo  P.  Quaresma,  BE  and  Renato  M.  E.Sabbatini, PhD. A Software Engineering Approach to the Development of Computer-Based Patient Record Sys-tems. http://home.nib.unicamp.br/~ claudiog/slides/seandcpr/seandcpr.htm
  39. Ramamoorthy C. V., Prakash A., Tsai W. T., Usuda Y. Software Engineering:problems and perspectives. Computer. Outubro. 1984. - P. 191-209.
  40. Reidsema C., Szczerbicki E. A Blackboard database model of the design planning process in concurrent engineering. Cybernetics and Systems: An International Journal, 2001. - 32. - Р. 755-774.
  41. Sherrer J. R., Lovis C., Baund R., Borst F., Spahni S. Integrated Computerised Patient Records: The DIOGEN2 Distributed Architecture Paradigm with Special Emphasis on its Middleware Design. In User Acceptance of health Telematics Applications (I Iakovidis et al., Eds) IOS Press, Technology and Informatics 56. - P. 15-31.
  42. Spahni S., Sherrer Jr. Sauquet D., Sottile PA. Consensual trends of optimizing the constitution of middleware. ACM SIGCOMM Computer Communication. – 1998 – Vol. 28, №5. – P.76 - 90.
  43. Beverley Kane, Daniel Z. Sands. Guidelines for the Clinical Use of Electronic Mail with Patients. Journal of the American Medical Informatics Association. Volume 5, Number 1, Jan/Feb 1998.
  44. Claudio  G.  A.  da-Costa,  MD,  Rodrigo  P.  Quaresma,  BE  and  Renato  M.  E.Sabbatini,  PhD.  A  Software  Engineering  Approach  to  the  Development  of Computer-Based Patient Record Systems. http://home.nib.unicamp.br/~claudiog/ slides/seandcpr/seandcpr.htm
  45. John Oyston. Anesthesiologists' Responses to an Email Request for Advice from an Unknown Patient. Journal of Medical Internet Research 2000;(2).P 16-17.
  46. E.V. Morozov. Elements of Queueing Theory. Petrozavodsk. 1998.
  47. Edward H. Shortliffe, Leslie E. Perreault, Gio Wiederhold, Lawrence M. Fagan.Medical  Informatics:  Computer  Applications  in Health  Care  and  Biomedicine. Second Edition. Springer, 2000.
  48. Elske  Ammenwerth,  Anke  Buchauer,  Bernd  Bludau,  Reinhold  Haux  .Mobile information and communication tools in the hospital. International Journal of Medical Informatics. Volume (issue): 57 (1) 2000 Free Sample Issue. P. 21–40.
  49. Fridsma D, Ford P, Altman R. A survey of patient access to electronic mail:attitudes, harriers, and opportunities. Proc Annu Symp Comput App Med Care.1994; Р. 15-9.
  50. Gunther Eysenbach. Towards ethical guidelines for dealing with unsolicited patient emails and giving teleadvice in the absence of a pre-existing patient-physician relationship — systematic review and expert survey. J. of Medical Internet Research, 2000; (1). P 1-10.
  51. H. van Bemmel, Erasmus University, Rotterdam M.A. Musen, Stanford University, Stanford. Handbook of medical informatics.   1999.  Website Version. http://www.mieur.nl/mihandbook/r_3_3/handbook/home.htm
  52. Ira  J.  Haimowitz,  Ramesh  S.  Patil,  Peter  Szolovits.  Representing  Medical Knowledge in a Terminological Language is Difficult. Proc. Symp. Computer Applications in Medical Care, IEEE Computer Society Press, Washington, DC.1988. Р. 101-105.
  53. Margaret Bearman. Technology in Medical Education. Monash University 1997.http://www.med.monash.edu.au/informatics//techme/index.htm
  54. Patricia C. Kuszler. A Question of Duty: Common Law Legal Issues Resulting from Physician Response to Unsolicited Patient Email Inquiries. J. of Medical Internet Research 2000; (3). P. 17-19
  55. Peter  Szolovits.  Medical  Informatics:  Computer  Applications  in  Health Care.http://medg.lcs.mit.edu/people/psz/6.872/96/notes/Kohane
  56. R.Van de Velde. Framework for a clinical information system. International Journal of Medical Informatics. Volume (issue): 57 (1) 2000 Free Sample Issue. P. 57–72.
  57. Ramamoorthy, C.V., Prakash, A., Tsai, W.T., Usuda, Y. Software Engineering :problems and perspectives. Computer. Outubro 1984. P.191-209. (52).
  58. Telematics  Systems  for  Health  Care:AIM-92.-Luxemburg:  Office  for  Official Publications of the European Communities,1992. №213. Р. 11.
  59. Yu-Chuan Li, Li Liu, Wen-Ta Chiu, Wen-Shan Jian. Neural network modeling for surgical decisions on traumatic brain injury patients. International J. of Medical Informatics. V. (issue): 57 (1) 2000. P. 1-9.
  60. А.В.Емельянов, И.А.Платонов. Обеспечение безопасности территориальной сети Медицинского центра. Кремлевская медицина. Клинический вестник, № 2, 1998. (70).
  61. А.Н.Вахлаков,  И.В.Емелин.  Развитие   поликлинических  информационных систем. Кремлевская медицина. Клинический вестник. №4, 2000. Стр. 12-14.
  62. А.Прохоров. Тенденции на рынке операционных систем в мире и России.Компьютер-пресс. №9, 2001. Стр. 8-16
  63. А.П.Голубева. Информационные технологии в управлении лечебно-профилактических учреждениях, http://www.worldbank.org.ru/wbimo/medical /module1/index.html
  64. А.В.Гусев, Ф.А.Романов,   И.П.Дуданов. Опыт разработки  медицинской информационной системы. Медицинский   академический   журнал,   №1. Приложение 1. – 2001, стр. 18.
  65. А.В.Гусев, Ф.А.Романов,  Т.А.Осиик. Применениемедицинской информационной системы в работе клинических лабораторий медицинского центра. Медицинский академический журнал, №1. Приложение 1. – 2001, стр.18.
  66. А.В.Емельянов, Д.С.Злобин, Д.И.Мальков. Построение комплексной системы связи Медицинского центра Управления делами Президента Российской Федерации. Кремлевская медицина. Клинический вестник. № 2, 2000.
  67. А.И.Афиногенов,  П.В.Назаренко,  В.Н.Плетнева,   Ф.И.Попова,  И.У.Дехтяр, И.Н.Осадчая.  Автоматизация  системы  медицинского  снабжения. Кремлевская медицина. Клинический вестник. №4, 2000. Стр.39-43.
  68. А.Н.Боцвинов, Г.Ф.Зайцев, М.Л.Левая. Опыт эксплуатации АИС “Эверест” в госпитале для ветеранов войн и городской многопрофильной больнице №2. Региональная информатика-98, Санкт-Петербург.
  69. А.П.Николаев, Р.А.Эльчиян. Развитие больничных информационных систем.Кремлевская медицина. Клинический вестник. №4, 2000. Стр. 9-11.
  70. А.Вишневский.  Сетевые  технологии  Windows  2000  для  профессионалов.Питер. Санкт-Питербург, 2000. Стр. 556-581
  71. А.Колесов.  «1С:  Предприятие»  -  платформа  создания  информационных систем. Byte Россия. СКПресс, 2001 №9, Стр. 28-34
  72. В.А.Курбатов, Г.Ф.Ковалев. Автоматизированная система "Санаторий".Кремлевская медицина. Клинический вестник. № 1, 1998
  73. В. Митин. Медицинские информационные системы. PCWeek, №1 (223), 2001. (21)
  74. В.Г.Кудрина. Медицинская информатика. Российская медицинская академия последипломного образования, 1999. Стр.1-60.
  75. В. Г. Олифер, Н. А. Олифер. Компьютерные сети. Принципы, технологии,протоколы. Питер – Санкт-Петербург, 2001.
  76. В.Г.Шаповалов, Л.В.Архаров, Л.И.Бирюкова. Опыт внедрения и эксплуатации автоматизированной информационной системы резервирования  мест   в санаториях. Кремлевская медицина. Клинический вестник. №4, 2000. Стр. 48-50.
  77. В.Н.Плетнева, И.У.Дехтяр, В.В.Матюхов,  Д.Ф.Щиголь. Комплексная автоматизация работы Аптеки №1 Медицинского центра Управления делами Президента. Кремлевская медицина. Клинический вестник. №4, 2000. Стр.44-48.
  78. В.С.Дудник, А.М.Маслеников. Автоматизация назначений и  учета лекарственной терапии. Кремлевская медицина. Клинический вестник. №3.2000.
  79. Г.И.Рузайкин. Медицинские информационные системы, или МИС. «Мир ПК»,№3, 2001.
  80. Дебби   Линд,   Стив   Керн.   Lotus   Notes   и   Domino   R5.   Энциклопедия пользователя. DiaSoft, 2000.
  81. Е.В.Никушкин, В.В.Тарасов, Р.В.Антонов, О.В.Дзюбина. Автоматизированный заказ лабораторных исследований. Кремлевская медицина. Клинический вестник. № 4, 1998.
  82. И.В.Емелин, Ю.Л.Перов, Ю.С Серегин, Р.А.Эльчиян. Концепция построения открытых медицинских информационных систем. Кремлевская медицина. Клинический вестник. № 1, 1998.
  83. И.В.Емелин, В.А.Смирнов, Р.А.Эльчиян. Создание современных медицинских информационных систем – объединение опыта Медицинского центра Управления делами Президента Российской Федерации и корпорации IBM.«Кремлевская медицина. Клинический вестник», № 2 1999.
  84. И.В.Емелин, Ю.Л.Перов, Ю.С.Серегин, Р.А.Эльчиян. Концепция построения открытых медицинских информационных систем. «Кремлевская медицина. Клинический вестник», №1 январь-март, 1998.
  85. И.А.Красильников,  Э.РУсеинов.  Ресурсы  информационных  технологий  в системе здравоохранения Санкт-Петербурга. Региональная информатика-98, Санкт-Петербург.
  86. И.М.Губин, В.В.Тарасов, Р.А.Антонов, А.В.Зыско, О.В.Дзюбина. Разработка и внедрение новой   автоматизированной   информационной   системы   ЦКБ. Кремлевская медицина. Клинический вестник. №4, 2000. Стр.51-54.
  87. И.У.Дехтяр,   Ю.Н.Каллистов,   П.В.Назаренко.   Информационная   система аптечного учреждения. Кремлевская медицина. Клинический вестник. № 3,1998.
  88. Криста Андерсон, Марк Минаси. Локальные сети. Полное руководство. ВЕК+.Киев. 1999. Стр. 207.
  89. Курбатов  В.А., Ковалев  Г.Ф.,  Иванова  М.А.,  Белица  Е.И.,  Рогозов  Ю.И., Соловьев А.Б. Комплексная система   автоматизации  деятельности медицинского учреждения. Кремлевская медицина. Клинический вестник. № 4, 1999.
  90. Л.М.Аникина, Л.В.Архаров, Л.И.Бирюкова, В.Н.Лукин, Л.Н.Чернышов, В.ГШаповалов. Новая автоматизированная система "Санаторий". Кремлевская медицина. Клинический вестник. № 3, 1999.
  91. Михаэль Эбнер. Delphi. Руководство разработчика. BHV, Киев, 2000. Стр. 7-12.
  92. О.Ю.Богоявленская. Многоканальные системы доступа в Internet.Петрозаводский государственный университет. 1999.
  93. Приказ МЗ СССР от 30.05.74 г. №493 «О введении в действие «Перечня документов со сроками хранения МЗ СССР, органов, учреждений, организаций, предприятий системы здравоохранения». Юридическая база данных «Консультант-Плюс» «Медицина-Фармацевтика».
  94. Р Клейтон. Lotus Notes 5. Учебный курс. Питер. Санкт-Петербург, 2000 г.
  95. Р.В.Антонов.  Компьютеризированная  технология  оформления  записей  в истории болезни. Кремлевская медицина. Клинический вестник. № 3, 2001. Стр. 84-86
  96. Р.М.Юсупов,   Р.И.Полонников.   Телемедицина.   Новые   информационные технологии на пороге XXI века. С-Петербург, 1998.
  97. С.П.Миронов,    Р.А.Эльчиян,    И.В.Емелин.    Российско-японский    проект "Телемедицина". Кремлевская медицина. Клинический вестник. № 1, 2001. Стр. 89-92
  98. С.П.Миронов.  Медицинская  информатика  в  начале  нового  тысячелетия.Кремлевская медицина. Клинический вестник. №4, 2000. Стр. 7-8.
  99. Сетевые средства Microsoft Windows NT Server 4.0. Питер, Санкт-Петербург.1998.
  100. Ф.И.Попова, И.Н.Осадчая, А. В. Зыско. Автоматизированный заказ лекарств в Центральной клинической больнице. Кремлевская медицина. Клинический вестник. дополнительный номер, 1998.
  101. Ф.А.Романов, А.В.Гусев. Опыт использования больничной информационной системы в   санатории-профилактории   ОАО  «Кондопога». Медицинский академический журнал, №1. Приложение 1. – 2001, стр.54.
  102. Ф.А.Романов, А.В.Гусев. Применение электронной системы планирования рабочего времени при организации лечебно-диагностического процесса. Медицинский академический журнал, №1. Приложение 1. – 2001, стр. 54.
  103. Шеррер Жан-Рауль. Информационные системы в здравоохранении:технология и организация. Кремлевская медицина. Клинический вестник. №4,2000. Стр. 15-17.
  104. Электронная  история  болезни  НИИ  нейрохирургии  им.  академика  Н.  Н.Бурденко РАМН: концепция, разработка, внедрение. Доклад на конференции «Проблемы разработки и внедрения информационных систем в здравоохранении  и  ОМС». Красноярск,  19-21  декабря  2000. http://www.mml.ru/.
  105. 3.Ю.Перов, Р.А.Эльчиян, И.М.Губин, И.В.Емелин. Дальнейшее развитие информационных технологий в лечебно-профилактических учреждениях Медицинского центра  Управления делами  Президента  Российской Федерации. «Кремлевская медицина. Клинический вестник» №1, 2000.
  106. Ю.Е.Михайлов. Информационно-компьютерные технологии – актуальный и неизбежный шаг совершенствования лабораторной диагностики (на примере создания и использования автоматизированной рабочей группы «Гематология») (Лекция). Клиническая лабораторная диагностика. – 2001. -№7. Стр.25-32. (24).
  107. Ю.Л.Перов,  Ю.П.Грибунов,  А.М.Линкевич.  Некоторые  организационные аспекты применения телепатологии в современных условиях. Кремлевская медицина. Клинический вестник. №4, 2000. Стр. 17-19. Информационные системы в здравоохранении – Общее описание

 

Автор. В.A.Давидянц Д.A.Бишарян
Источник. Общественный ежемесячный отчет здравоохранения Армении 1-12.2007,УДК 61 (479.29) ББК 5 (2Ар) МММ 720
Информация. med-practic.com
Авторские права на статью (при отметке другого источника - электронной версии) принадлежат сайту www.med-practic.com
Share |

Вопросы, ответы, комментарии

Читайте также

Дорожно-транспортный травматизм как проблема общественного здоровья

Введение

Травмы, независимо от причин их возникновения, оказывают очень серьезное  воздействие  как на здоровье

человека, так и на службы, предоставляющие медицинскую помощь пострадавшим (Krug E., Sharma G., Lozanо R., 2000)...

Руководство по работе с компьютерной программой “Мониторинг за проблемой дорожно-транспортного травматизма”

Предисловие

Уважаемый коллега!

Представляем Вашему вниманию компьютерную про грамму  “Мониторинг за проблемой дорожнотранспортного травматизма”...

Организация лечебно-профилактической помощи населению высокогорных сельских районов Грузии в современных условиях

В условиях реформирования и реструктуризации системы здравоохранения  Грузии,  осуществляемых  на  фоне преобразований общественно-экономических отношений...

САМЫЕ ЧИТАЕМЫЕ СТАТЬИ