Компьютер-Информ || Архив || Рубрики || Поиск || Подписка || Работа || О "КИ" || Карта
А. Бржезовский, Н. Витюк,
Для нормального функционирования КИС необходимо обеспечить правильное информационное взаимодействие компонентов системы.
Информационное взаимодействие в корпоративной системе касается двух основных моментов:
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.
╧ раздела | Наименование раздела | Наименование документа | Исполнитель документа |
1 | Паспортные данные пациента | Поликлиника | |
2 | Данные для поликлиники |
Выписной эпикриз госпиталя | Санаторий |
Выписной эпикриз санатория | Поликлиника | ||
Акт противопоказаний для санаторно-курортного лечения | Санаторий | ||
3 | Данные для госпиталя |
Эпикриз на госпитализацию | Поликлиника |
Переводной эпикриз из санатория |
Санаторий | ||
4 | Данные для санатория |
Переводной эпикриз из госпиталя |
Госпиталь |
Санаторно-курортная карта | Поликлиника |
Передача информации по корпоративной сети реализует концепцию единого информационного пространства, в которой предполагается, что в роли информационных ресурсов системы выступают не только данные, но и входящие в ее состав приложения. При таком способе организации взаимодействия двух информационных подсистем первая пользуется сервисами, предоставляемыми второй, и ≈═как результат═≈ получает уже обработанные данные, которые могут быть подвергнуты дальнейшей обработке компонентами первой.
Подход, при котором в системе реализуются множественные клиент-серверные взаимодействия и любые приложения из различных информационных подсистем, может выступать как в роли клиента, так и в роли сервера по отношению друг к другу, совместно решая те или иные задачи, получил название распределенной архитектуры взаимодействия.
Рисунок 3. Распределенная архитектура взаимодействия
К числу преимуществ данного подхода можно отнести:
1)═Минимизацию дублирования приложений.
2)═Эффективное использование информационных ресурсов системы в целом за счет распределения приложений по подсистемам КИС и достижения оптимального баланса загрузки программно-аппаратных средств.
3)═Устранение зависимости приложений от структуры базы данных. Знание схемы базы данных необходимо только тому приложению, которое обрабатывает данные из этой базы данных. Использование сервисов, предоставляемых информационной подсистемой-сервером и реализующих методы обработки данных, позволяет решить проблему изменения схемы удаленной базы данных. При этом статичность интерфейсов компонентов, предоставляющих серверу набор сервисов, достигается путем применения методологий объектно-ориентированного анализа и проектирования, распределенных объектных технологий (см. третью статью цикла).
4)═Уменьшение затрат на администрирование, сопровождение и модификацию за счет локализации в рамках конкретных информационных подсистем не только данных, но и методов их обработки.
Для обеспечения взаимодействия компонентов информационной системы, поддерживающей распределенную одноранговую архитектуру, необходимо создать промежуточный программный уровень (middleware), при помощи которого запросы принимаются от клиентов и направляются соответствующему серверу.
По результатам анализа решений, из числа предлагаемых в настоящее время производителями ПО для создания middleware, при реализации рассматриваемой системы был выбран введенный международным консорциумом OMG (Object Management Group) стандарт CORBA (Common Object Request Broker Architecture) и поддерживающее его семейство продуктов Sybase.
Анкета || Рубрики || Работа || Услуги || Поиск || Архив || Дни рождения
О "КИ" || График выхода || Карта сайта || Подписка
Главная страница
Сайт газеты "Компьютер-Информ" является зарегистрированным электронным СМИ.
Свидетельство Эл ╧ 77-4461 от 2 апреля 2021 г.
Перепечатка материалов без письменного согласия редакции запрещена.
При использовании материалов газеты в Интернет гиперссылка обязательна.
Телефон редакции (812) 118-6666, 118-6555.
Адрес: 196084, СПб, ул. Коли Томчака, д. 9
Пейджер 238-6931(аб.3365)
e-mail:
Для пресс-релизов и новостей