Компьютер-Информ || Архив || Рубрики || Поиск || Подписка || Работа || О "КИ" || Карта

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

А. Бржезовский, Н. Витюк, nataly@eureca.ru

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

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

1)наличия корпоративной нормативно-справочной информации и единых корпоративных справочников;

2)программно-технической реализации передачи информации между территориально распределенными объектами.

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

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

* Колесников С.Н. Как организоватьпроектвнедрения http://www.citforum.ru/cfin/articles/organize.shtml

1)организационно-штатная структура предприятия;
2)бухгалтерские стандарты;
3)кодификатор и классификатор продукции и других товарно-материальных ценностей;
4)кодификатор и классификатор клиентов и партнеров;
5)стандарты процедур основных функциональных операций.

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

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

п. 5)стандарты стационарной и амбулаторной медицинской помощи.

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

В рассматриваемой системе можно выделить две основные категории справочников:
1)справочная информация, которая должна быть единой для всех территориально распределенных объектов автоматизации (п. 3, 4 и частично 1);
2)справочная информация, не выходящая за рамки объекта автоматизации (п. 5 и частично 1).
Состояние дел до инициализации рассматриваемого проекта характеризовалось следующим: были созданы отдельные базы данных объектов автоматизации и АРМы пользователей (файл серверная архитектура на основе СУБД FoxPro), работающие с общей (для объекта) или локальной (на рабочем месте) базой данных. Таким образом, не было справочников общих для объектов, да и на одном объекте автоматизации различные АРМ зачастую работали со своими версиями справочной информации.

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

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

•организационные единицы;
• штатное расписание;
•специализации должностных лиц и др.

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

Рисунок 1. Схематично состав справочников и структура ссылок

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

•lсервис классификации болезней;
•сервис диагностических исследований и лечебных воздействий;
•сервис лекарственных препаратов;
•сервис медицинских стандартов.

Для ведения реестра пациентов в системе предусмотрен сервис персональной информации, реализующий такие функции, как:

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

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

Рисунок 2. Структура обмена информацией между объектами автоматизации

Как следует из рис. в рассматриваемой системе можно выделить два класса взаимодействий:

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

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

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

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

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

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

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

Рисунок 3. Распределенная архитектура взаимодействия

К числу преимуществ данного подхода можно отнести:
1)Минимизацию дублирования приложений.

2)Эффективное использование информационных ресурсов системы в целом за счет распределения приложений по подсистемам КИС и достижения оптимального баланса загрузки программно-аппаратных средств.

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

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

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

По результатам анализа решений, из числа предлагаемых в настоящее время производителями ПО для создания middleware, при реализации рассматриваемой системы был выбран введенный международным консорциумом OMG (Object Management Group) стандарт CORBA (Common Object Request Broker Architecture) и поддерживающее его семейство продуктов Sybase.

       КОМПЬЮТЕР-ИНФОРМ 
          Главная страница || Статьи 19'2001 || Новости СПб || Новости России || Новости мира

Рубрики || Работа || Услуги || Поиск || Архив || Дни рождения
О "КИ" || График выхода || Карта сайта || Подписка

Рассылка анонсов газеты по электронной почте

Главная страница

Сайт газеты "Компьютер-Информ" является зарегистрированным электронным СМИ.
Свидетельство Эл 77-4461 от 2 апреля 2001 г.
Перепечатка материалов без письменного согласия редакции запрещена.
При использовании материалов газеты в Интернет гиперссылка обязательна.

Телефон редакции (812) 718-6666, 718-6555.
Адрес: 196084, СПб, ул.Заставская, д.23, БЦ "Авиатор", 3-й этаж, офис 307
e-mail: editor@ci.ru
Для пресс-релизов и новостей news@ci.ru