Аннотация.
Анализируется эволюционное развитие информационных систем (ИС), приводящее к интеграции разнородных приложений и источников данных, и обсуждается значение различных источников информации для субъектов лечебно-диагностической деятельности и их интеграции в единую пользовательскую среду. Подвергаются критическому анализу современные методологии проектирования ИС с точки зрения задач здравоохранения. На примерах демонстрируется роль пространства Web, как среды отображения наиболее важных источников медицинской информации.
Введение
Развитие ИС отражает эволюцию взглядов пользователей на роль вычислительной техники в профессиональной деятельности. Прослеживаемое направление эволюции - от автоматизации решения отдельных, преимущественно вычислительных задач, к автоматизации работы с данными, и далее - к работе со всеми видами предметной и околопредметной информации. В стороне от этих эволюционных процессов не осталась и медицина, однако в медицине они идут с некоторым (примерно 5-8 лет) запаздыванием. До сих пор в очень многих ЛПУ, особенно на местах, приходится сталкиваться с мнением, что сферой применения информационных технологий может быть только бухгалтерский учёт и подготовка отчётности для страховых органов и ведомственной статистики.
Указанная ситуация в действительности характерна и для стран, которые в определённых кругах принято называть цивилизованными - в них больший исторический период автоматизации здравоохранения привёл к значительно большей нынешней разобщённости медицинских программных продуктов, чем в странах ex-СССР.
Ещё 15 лет назад термин <интегрированный пакет>, применялся в отношении нескольких офисных программ, запускаемых в общей среде [3]. Показательно, что одно из изданий тех лет относило тот или иной пакет программ к интегрированным просто на основании возможности обмена данными между отдельными программами, входящими в состав такого пакета [9]. Это означает, что несколькими годами ранее выхода в свет цитируемых публикаций, целесообразность объединения даже офисных приложений на персональных компьютерах была неочевидной.
Как ни странно, и в современных условиях заказчики, идеологи и исполнители проектов не всегда ясно представляют себе, что должно являться объектом автоматизации при создании ИС в здравоохранении. При рассмотрении этого вопроса в других отраслях в качестве такого объекта очевидным образом выбирается основная деятельность. В силу примущественно исторических причин в здравоохранении это не так. Возможно также, что помимо исторических причин, в медицине действует и фактор искажённого целеполагания, ранее обсуждавшийся в работе [8].
Проектирование: дивергенция или конвергенция?
При рассмотрении подходов к проектированию ИС часто используется рабочая классификация проектов, исходя из выбора базовых объектов в феноменологической модели предметной области. Как правило, в качестве таких объектов выделяются: 1) данные; 2) документы; 3) бизнес-процессы [1,2,10].
Современная литература содержит указания на успешное применение походов к проектированию ИС на основе любого из перечисленных объектов. При этом сторонники каждого из подходов часто подвергают критике все остальные [1,2,6].
В приведённом выше списке сущности в действительности неоднородны, поскольку с точки зрения реализации ИС, такой объект, как "бизнес-процессы", в свою очередь, представляет собой метод, применяемый в отношении объектов "данные" и "документы". Традиционно в качестве базового объекта при проектировании предлагается выбирать тот, свойства которого в наименьшей степени изменяются во времени. Данное положение служит своего рода наследованием принципов математического моделирования, в котором в качестве параметров модели выделяют не изменяющиеся в течение времени наблюдения за системой величины, и в качестве переменных - величины, значение которых изменяется за то же самое время. Легко предположить, что в качестве времени наблюдения за системой в прикладной информатике выступает жизненный цикл ИС. Однако следует иметь в виду, что в проекте ИС приходится иметь дело не с одной, а минимум с тремя базовыми моделями - моделью предметной области, моделью создаваемой ИС, и с собственно информационной системой. Практика показывает, что в общем случае понятия наиболее консервативных объектов для всех трёх моделей не совпадают.
Таким образом, адекватность каждого из подходов (от данных, от документов, от бизнес-процессов) зависит преимущественно от выбираемых заранее инструментальных средств, и наоборот. Если, например, инструментальное средство или среда исполнения ИС позволяет легко манипулировать документами, то проектирование целесообразно вести "от документов", даже если на уровне предметной области свойства документов часто меняются. Проекты на основе реляционных СУБД, в зависимости от вкусов и возможностей разработчика выделяют в качестве консервативной части бизнес-процессы, либо данные. В целом соответствующая закономерность может быть отражена в табл.1.
| Инструментальное средство | Предпочтительный базовый объект при проектировании | Пример инструментального средства |
| Реляционная СУБД | Данные | MS SQL |
| Объектная СУБД | Бизнес-процессы | InterSystems Cache |
| Документоориентированная СУБД |
Документы | IBM Lotus Domino |
Табл.1. Отношения между основными сущностями при проектировании ИС.
Информация, приведённая в таблице, адекватна с определённой степенью условности, поскольку на картину действительности решающий отпечаток может накладывать личность разработчика. Данное утверждение блестящим образом проиллюстрировано в известном мультипликационном фильме "Крылья, ноги и хвосты" [4].
Инструментальные средства эволюционируют параллельно с прикладными ИС. В этом виде эволюции прослеживается та же самая тенденция: конвергенция в сочетании с функциональной интеграцией. Та часть читателей, которая застала эпоху операционной системы DOS, ещё помнит разделение средств разработки на текстовые редакторы, трансляторы и компоновщики. Средства разработки ранее других пакетов прикладных программ прошли путь от взаимодействия приложений до их бесшовной интеграции. Сегодня интеграция инструментария вышла на новый уровень - реальностью стали средства взаимодействия программных средств предметного моделирования, прототипирования ИС и получения рабочего кода [7]. За то же самое время сделало причудливый виток развитие доступа пользователей к вычислительным ресурсам - от терминальных систем коллективного использования к персональным компьютерам и затем к локальным сетям и приложениям "клиент-сервер". В последних разделение доступа происходит уже не на уровне индивидуальной работы с частью общих аппаратных ресурсов, а на уровне коллективной работы индивидуальными аппаратными средствами с частью общих программных или информационных ресурсов. Конвергенция же инструментальных средств наглядно проявляется например в том, что современные версии промышленных РСУБД позволяют в известной мере работать с нереляционными объектами (Oracle, DB2, и др.), а нереляционные и постреляционные СУБД и средства разработки используют реляционные таблицы в качестве хранилища создаваемых объектов (Lotus Domino/Notes v.7, Cache).
Масштабирование интеграции: приложение следует
В отношении системного ПО понимание того, что акцент в использовании компьютера при коллективной работе смещается с обработки общих данных на осуществление коммуникаций, пришло примерно 30 лет назад. Именно этому пониманию мы обязаны нынешним существованием протокола TCP/IP, понятия хост-машины, могущей выступать как сервером, так и клиентом, а также Интернета в качестве объединяющей пользователей среды. К разработчикам прикладного ПО то же самое понимание пришло в середине 80-х годов. К этому периоду относится появление первого коммерческого продукта для коллективной работы, а именно Lotus Notes. Информационные системы для медицины подвергаются соответствующей трансформации на наших глазах.
В работе [8] ЛПУ рассматривается в качестве ремонтно-обрабатывающего предприятия, и основным бизнес-процессом в нём становится проводка пациента. На уровне модели ИС, использующей в качестве базового понятия рабочие потоки, основным бизнес-процессом ЛПУ становится проводка документа "История болезни". В терминах рассматриваемой модели понятие истории болезни не ограничивается рамками документа "Карта стационарного больного", но включает также амбулаторную карту и все сопутствующие случаю многочисленные документы [5]. Очевидно, что история болезни как в предметной области, так и в модели автоматизированной ИС служит тем объектом общего пользования, информационное наполнение которого по мере прохождения рабочего потока производится разнородными данными из различных источников (Рис.1). В модели МИС приведённая на иллюстрации структура не меняется; различия сводятся к несовпадающим именам объектов, преимущественно в верхней части диаграмм. Например, для модели МИС имя объекта "Диагностическое и лабораторное оборудование" будет заменено на "Программно-аппаратный комплекс интеграции оборудования", а объекта "Персонал" - на "Специализированные АРМы".
Рис.1. Ввод и вывод данных из разнородных источников, сопряжённый с проводкой пациента и документов, сопутствующих случаю.
Поскольку наиболее общей целью информатизации можно считать своевременное обеспечение субъектов деятельности всеми видами необходимой информации, основная задача информатизации деятельности ЛПУ при поддержке рабочих потоков сводится к интеграции разнородных источников данных в некоторую общую среду [5].
Общей средой уровня организации в модели медицинской ИС следует считать локальную вычислительную сеть. Интерфейсная часть специализированного ("толстого") клиента (электронная история болезни, ЭИБ) при этом рассматривается не как общая среда, а как единая точка входа в среду уровня ЛПУ. В современных условиях сами понятия "толстого" и "тонкого" клиента, как ни странно, вновь стали предметом дискуссии. Поэтому в настоящей статье мы придерживаемся терминов "универсальный клиент" (для Web-браузера), и "специализированный клиент" (для локально запускаемого специализированного пакета программ, реализующего значительную часть бизнес-логики на стороне клиентского компьютера). Отметим, что вопреки мнению многих пользователей, при использовании универсального клиента независимость от платформы обеспечивается серверной частью ИС, а само клиентское ПО оказывается платформозависимым, в то время как специализированный (толстый) клиент может быть как зависимым от платформы (например, созданный средствами Borland Delphi), так и независимым от неё (Java-клиент).
В условиях современного здравоохранения рабочие потоки часто выходят за пределы одного ЛПУ. Косвенным подтверждением этого обстоятельства служит приведённая на рис.1 диаграмма, на которой из семи источников данных, обрабатываемых в ЛПУ, четыре находятся за его пределами. Обозначенный выше подход правомерно оставить без изменений и при проектировании территориально-распределённых МИС, с той оговоркой, что ряд базовых объектов в модели проявляет полиморфизм. Общей средой уровня нескольких организаций становится Интернет, единой точкой входа в среду уровня нескольких организаций - Web-портал [5], средством доступа - универсальный ("тонкий") Web-клиент (табл.2).
| Уровень взаимодействия субъектов здравоохранения |
Общая среда | Узел сети | Единая точка входа | Общее средство доступа |
| ЛПУ | ЛВС | Сервер Рабочая станция |
Интерфейс ЭИБ | Специализированный клиент |
| Регион, территория | Интернет | Хост | Web-портал | Универсальный клиент |
Табл.2. Базовые объекты в моделях МИС при масштабировании.
Необходимость отображения конкретных объектов предметной области в среду Интернет [16], возникающая как следствие масштабирования модели интеграции источников на уровень территории, ставит разработчиков перед рядом традиционных проблем и ограничений, свойственных Web-технологиям [5,11,12]. По опыту авторов, ограничения, накладываемые Web, преодолеваются в большинстве упоминаемых в данном контексте частных задач создания МИС, а именно, интеграции с оборудованием (рис.2), обработки диагностических изображений (рис.3), извлечения информации из массивов данных [15], поддержки принятия решений [14], клинического моделирования и прогноза (рис.4). Однако в настоящее время практическое решение этих задач не носит системного характера, и тем более, не входит в область действия какого-либо принятого стандарта. Обсуждение путей и способов обхода ограничений Web-технологий выходит далеко за рамки настоящей статьи. В определённой части это является проблемой консорциума W3C и ведущих вендоров - разработчиков инструментальных средств для Web. Тем не менее, глубокое убеждение авторов состоит в том, что наблюдаемая сегодня тенденция [13] в последующие годы станет фактическим стартовым условием для разработчиков, а это уже сейчас требует приложения усилий в направлении смены парадигмы реализации медицинских приложений. С практической точки зрения это означает, что медицинские порталы должны создаваться, как распределённые высокотехнологичные корпоративные ИС, а территориальные МИС, в свою очередь - как системы специализированных порталов.
Рис.2. Интеграция медицинского оборудования (ультразвуковая допплерография) в Web-версии медицинской информационной системы.
Рис.3. Обработка диагностических изображений в среде Web.
Рис.4. Индивидуальный прогноз результатов лечения хронической почечной недостаточности на модели с Web-доступом.
Выводы
Задача интеграции различных источников медицинской информации в пользовательскую среду в современных условиях сводится к шлюзовой Web-интеграции путём организации регламентированного взаимодействия разнородных приложений и источников данных (рис.5). В рамках данной модели так называемая телемедицина становится просто подмножеством вариантов использования территориальной МИС (рис.6).
Рис.5. Интеграция разнородных медицинских приложений и источников данных в единую пользовательскую среду по принципу "одного окна".
Рис.6. Подмножество вариантов использования территориальной медицинской информационной системы для нужд телемедицины.