Особливості в проектуванні і практичної розробки
медичної інформаційної системи
Гусєв А.В., член-кор. РАМН Дуданов І.П., Романов
Ф.А., Дмитриев А.Г., Карельський науково-медичний центр СЗО РАМН, Петрозаводськ
В
останні роки в Росії з'явився цілий ряд унікальних розробок в області
комплексних медичних інформаційних систем (МІС), призначених для
автоматизації роботи закладів охорони здоров'я. Одними з найцікавіших
є: Інформаційного система "Інтерін" (Інститут програмних
систем РАН), МІС "Артеміда", МІС "Амулет" та деяких
інші. Ці системи не тільки розроблені, але й активно раз-вива --
поширення і визнання в практичному впровадженні вони отримали за по-останню
2-3 роки. У літературі опубліковані позитивні відгуки колективів клінік
самого різного профілю та масштабів про досвід застосування інформаційних систем в
робо-ті [1, 3, 5, 10, 13, 14, 17-20]. З'явилася тенденція на комплексне
рішення різнобічних задач лікувального закладу, що особливо радує і
свідчить про якісне зростання вітчизняних розробників у галузі
медичної інформатики.
Однак
при більш глибокому вивченні цього процесу все сильніше виділяється сущест-жавна
проблема: незважаючи на наявність глибоко пророблених програмних рішень,
практично відсутній досвід повного переходу на електронний принцип зберігання і
оброб-лення інформації в лікувальному закладі [8, 11]. Є ряд серйозних
перешкод, через ко-торые не можуть переступити навіть сучасно оснащені клініки
в своєму прагненні від-здаватися від паперових носіїв інформації і підвищити
ефективність в організації сво-їй роботи. Всі вони можуть бути об'єднані в
кілька груп.
По-перше,
що існує у нас правова база не забезпечує належного рівня юридичної
захисту медичних працівників, що застосовують інформаційні технології в
повсякденній практиці. По-друге, фінансові ресурси більшості установ
Здра-воохраненія поки що не можуть дозволити їм придбати достатню кількість
комп'ютерної техніки і дорогого програмного забезпечення для комплексної
автоматизації. По-цьому цей процес протікає успішно лише в деяких,
часто далеких від медичної спрямованості, розділи роботи ЛПЗ:
статистика, бухгалтерія, автоматизація роботи ад-міністратівного ланки і т. д.
По-третє, в Росії практично відсутня школа, яка б готувала
професіоналів високого рівня в галузі розробки та впровадження саме комплексних
медичних інформаційних систем, людей за визначенням що працюють на стику
найскладніших наук - медицини та прикладної математики. Для становлення
вітчизняної школи в цій галузі творчим колективам необхідно
обмінюватися спостереження-нями і думками в розробці програмних продуктів,
накопичуючи тим самим спеціаль-ні знання і формуючи потенційно вигідні
напрямки в пошуку ефективних рі-ний розробки і впровадження комплексних
МДС.
Колектив
авторів має 5-річний досвід у розробці медичної інформаційної системи. За
цей час вивчена на практиці ефективність різних підходів. Застосовуючи-лись
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. Крім інструментарію, була
проведена робота з вивчення ефективності різних методик проектування
ба-зи даних МДС. У підсумку ми зупинилися на застосуванні принципу
об'єктно-реляційної парадигми в проектуванні БД МИС [4]. Резюме концепція
цього підходу виражається в тому, що в силу особливостей предметної області
необхідно розробляти інформаційні ву систему на базі синтезу двох,
різних за своєю природою, систем управління базами даних (СУБД) --
об'єктно-орієнтованої і реляційної. Тільки на основі цього синтезу вдається
виключити недоліки обох СУБД і використовувати їх гідності. В якості
ос-новних СУБД використовується Lotus Domino Server R6.0.3 для функціонування
об'єктної частини МДС і MySQL 4.0.17 для реляційної складовою системи.
Розробка програм-ного забезпечення ведеться в середовищі Lotus Designer R6.0.2 і
Borland Delphi 6 Professional SP3. У ході вивчення ефективних способів
створення додатків для системи знайдено декілька, на наш погляд, цікавих
знахідок.
По-перше,
однією з найбільш істотних причин збільшення вартості МДС ми вважаємо високу
вартість самої розробки. Вивчивши причини цього явища, ми прийшли до висновку,
що не останню роль у цьому відіграла традиція створення медичних
інформа-ційних систем на основі так званих АРМ-ов (автоматизованих
робочих місць). Причому найчастіше під АРМ-му розуміється саме клієнтське
програмне забезпечення, хоча спочатку цей термін мав більш широке
тлумачення [10]. Найчастіше розробка АРМ-ів ведеться за наступною методикою:
розробники вибирають деяку загальну завдання (наприклад, створення електронної
історії хвороби для стаціонару), проектують структуру бази даних,
розробляють програму для роботи з нею. Нерідко це додаток виконан-вується
у вигляді кількох версій - АРМ головного лікаря, АРМ реєстратора, АРМ лаборанта
і т. д. Розробка систем у 65% випадків ведеться на Borland Delphi. При цьому
навіть на випуск дуже сирий версії АРМа витрачається 4-8 місяців. Потім стільки ж
часу йде на Обкатился-ку. Разом з тим, за нашими оцінками, розробнику
припадає 10-20% часу витрачати на створення специфічного для медичної
області коду. Інша частина, причому сама тру-доемкая і відповідальна,
припадає на розробку механізмів, що забезпечують цілісність даних,
підсистему безпеки та адміністрування МИС, зв'язок з периферійним
медичним обладнанням і т. д.
Однак,
не викликає сумнівів, що ці рішення значно поступаються промисло-вим
рішень для корпоративного ринку, над якими працюють найкращі спеціалісти та
які пройшли багаторічну перевірку. У зв'язку з цим викликають подив
подібні спроби "винайти велосипед". На наш погляд, розробка МДС
не повинна здійснюватися створенням та подальшою інтеграцією окремих АРМов.
Для створення МІС необхідно застосовувати готові програмні платформи для
групової роботи, що вже мають у своєму арсеналі потужні засоби для
мультиплатформовий розробки програми, готові тех-нології для розгортання
та управління підсистемою безпеки. У своїй роботі ми ви-брали пакет
групової роботи Lotus Notes/Domino, що розробляється в даний час
корпорацією IBM. Ця платформа є за кордоном стандартом "де
факто "для створення потужних інформаційних систем, орієнтованих на
обробку електронних документів і ми вважаємо, що вона найбільш підходить для
створення медичних інформаційних сис-тем.
Робота
над створенням МІС "Кондопога" на основі Lotus Notes/Domino версії 4.6
на-чату у вересні 1999 року. Через 2 місяці МИС, що включає підсистеми роботи
лікаря, клінічної та біохімічної лабораторії, функціональної та
рентгенологічної діагно-стики, аптеки та планування робочого часу була
поставлена в експлуатацію. А ще че-рез 2 місяці лікувальний заклад,
використовує систему, повністю перейшло на елек-тронний спосіб зберігання
інформації, відмовившись від паперових носіїв.
Другим
важливим рішенням з'явився відмова від проектування бази даних МДС по
функціональному призначенню, коли для окремої завдання (наприклад, підсистема
лабора-торії, функціональної діагностики, консультаційна і т. д.) створювалася
своя база дан-них. Хоча такий підхід має низку переваг, головним з якого
є зниження вимог до апаратної потужності сервера за рахунок розділення
потоків для користувача запитів до окремих БД. Проте було обрано
проектування БД МДС в такий спосіб, що вся інформація збиралася навколо
пацієнта і зберігалася фізично в одній БД.
Однак
кількість таких БД в МДС є варіабельності і залежить від кількості
функціональних груп користувачів, що є в ЛПУ. Так, у стаціонарі це
може бути виділена БД для кожного відділення або корпусу. Для поліклініки --
це можуть бути БД, розділені по ділянках обслуговування. Крім того, у цих БД
спеціальним чином хра-нітся тільки актуальна інформація, а не використовуються
дані містяться в БД архіву. Для вирішення низки завдань може бути прийнята або
пов'язана з об'єктно-орієнтованим ядром реляційна БД, або спеціальний
чином сконструйовані уявлення, ко-торые ми називаємо регістрами (рис.
1).
Рис.
1. Укрупнена схема об'єктно-реляційної бази даних медичної
інформаційної системи
Проектування
структури БД, таким чином, дозволяє досягти стабільно малого обсягу БД МДС в
протягом практично всього терміну її експлуатації, а тим самим забезпе-чити
максимально можливу продуктивність роботи МДС. Так, починаючи з 1999 року
база даних історій хвороби пацієнтів, які проходять реабілітацію в медичному
центрі, має об'єм 26-29 Мбайт. При цьому вся інформація за час роботи центру
збережена, а швидкість роботи залишається стабільно високою. Складністю зазначеної
методики є те, що програмне забезпечення інформаційної системи має
підтримувати будь-яку кіль-кість фізичних баз даних в ядрі системи,
об'єднаних в одну логічну структуру.
Таким
чином, необхідно розробити алгоритми всіх програм МДС так, щоб вони
могли коректно працювати з базою даних поточних документів, що складається з однієї або
не-скількох частин. Це викликано тим, що в деяких випадках програмами
необхідно обра-ботати дані не тільки з окремої частини бази даних, а й по
всієї наявної в ній інформації. У зв'язку з цим необхідно перед кожним
зверненням до сервера виконувати ряд послідовних кроків:
визначити,
яка кількість фізичних баз даних та їх імен відповідно установ-лено на
сервер;
визначити
можливість доступу до кожної базі даних окремо;
виконати
відповідний запит до кожної базі даних, вказавши в правильному форматі повний
адреса, що включає ім'я сервера та ім'я бази даних на ньому;
обробити
і запам'ятати отриману відповідь;
повторити
кроки 2-4 для кожної бази даних;
скласти
накопичені відповіді та обробити їх, як єдиний пакет інформації.
Доведено
[5, 10, 16, 17, 19, 20, 22], що для ефективного вирішення такого завдання
необ-обхідно виключити в текстах програм МДС пряме звернення до баз даних.
Замість цього запропоновано використовувати спеціальне проміжне програмне
забезпечення, називає-майо сервісами middleware. Схема роботи МИС на базі
сервісів middleware показана на ри-Сунки 2. З метою визначення ефективності
розробки системи із застосуванням об'єктно-орієнтованої технології на
підставі використання сервісів middleware, авторами було виконано аналіз
роботи зі створення інформаційної системи в період 1999-2001 рр.. Були отримані
наступні дані (таблиця 1).
Таблиця
1
Використання
однотипного програмного коду в різних підсистемах МИС
Підсистема
Загальний код
Унікальний код
% від усього
% часу на розробку
% від усього
% часу на розробку
Документи ІБ і АК
45
10
55
90
Лабораторна підсистема
74
38
26
62
Статистика
17
9
83
91
Як
представлено в таблиці 1, в деяких видах ПО частка повторюваного коду
со-ставлять значну частину. Виключення його з етапу розробки нового
програми по-ристання донної набійки дозволило скоротити середній час створення нової програми з 3,8 до
2,9 тижнів (на 23,68%). Крім цього, використання перевірених бібліотек
дозволило значно, на 35-50%, з-крат кількість подальших виправлень
помилок. Фактично вся основна робота над помилками була пов'язана з виправленням
унікального коду програми, в рідкому випадку (в середньому 5-7 помилок на 100
виправлень) виправленням використовуваних middleware-сервісів.
Таблиця
2
Аналіз
помилок і виправлень у МИС
Підсистема
До застосування 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%. Нерідко
виправлення помилки проводилося вже до того, як користувач сповіщав про це
програмістам [10, 14].
Необхідно
зазначити, що застосування моделі програмного забезпечення системи на основі
використання загальних сервісів middleware дозволяє застосовувати еволюційний
ме-тод, який називається в літературі Spiral Model [12, 18]. При цьому можливо
впровадження нових версій інформаційної системи шляхом простого підміна базових
сервісів на нові вер-сии. Ці версії можуть працювати як зі старою
інформаційною системою, так і з новою, без необхідності повторного навчання
персоналу або виправлень у структурі існуючої бази даних.
Таким
чином, застосування сервісів middleware дозволило в середньому збільшити
появ-ня нових версій програм з 4 до 7 на місяць (на 75%), знизивши питому
вартість кожної нової версії на 22%. Застосування зазначених технологій дозволило
розробити систему зі значною економією. Так, розробка найбільшої
вітчизняної МИС "Інтерін" довгих-ся 9 років, штат розробників
налічує 25 чоловік. Розробка ІС, в якій беруть участь автори,
здійснюється 4 роки і тільки 2 останні з них в ній постійно учас-яття 2
програміста. Прийнявши, що дана МДС містить лише 50% від можливостей МДС
"Інтерін", зарплата одного програміста становить близько $ 300 (дол.
США), а робота ве-дется 11 місяців на рік, отримана економія в порівнянні з
традиційними технологіями близько $ 75900 на рік. Таким чином, за 4 роки роботи
вартість розробки МІС на основі об'єктно-реляційного підходу склала 5,3%
від суми, яка потрібна була б для створення МДС із застосуванням традиційного
підходу.
Рис.
2. Схема роботи проміжного програмного забезпечення і його місце в структурі
програм медичної інформаційної системи
На
етапі, коли ІС стає пакетом численних програм, гостро постає питання
їх підтримки. Актуальність її зростає разом зі строком експлуатації і зростанням
кількості користувачів. Поряд з початковими капітальними витратами,
адміністрування Інформаційним системи становить значну цифру в кошторисі
витрат ЛПУ [3, 5, 10, 14]. Застосування складних комплексних інформаційних
систем вимагає висококваліфікована-ного штату програмістів і адміністраторів
[12, 15]. Із зростанням кількості підключено-них до бази даних системи користувачів
зростає і складність її обслуговування. У таблиці 3 наведені середні щотижневі
витрати часу роботи адміністратора МДС, отримані в результаті
хронометрично досліджень в медичному центрі.
Таблиця
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
Використання
вбудованих в middleware-додатків глобальних обробників оші-пліч дозволяє
скоротити час за п. 3 (відправка звітів про помилки) практично до нуля, т.
к. вся ключові звіти система формує і відправляє автоматично.
Обслуговування викликів користувачів, виправлення локальних збоїв на комп'ютерах
користувачів і поза-сеніе виправлень в довідники системи є
практично некерованими факто-рами. Планове обслуговування комп'ютерів,
аналіз журналів роботи системи, читання спе-них літератури є
постійними величинами, стікаючи з функціональних обов'язків
адміністратора системи.
Отже,
керованими чинниками, які здатні скоротити (перерозподілити) трудовитрати
технічного персоналу на обслуговування системи є: установка при-ложении
системи, встановлення виправлень (у т. ч. самої ІВ і загальносистемного ПЗ), контроль
за новими версіями ПЗ. Причиною високих показників у цих категоріях є
тради-ційних спосіб установки прикладного ПО: адміністратор мережі запускає
інсталяційних-ні пакети на комп'ютерах користувачів, а потім у міру появи
і т. н. "латки" до них. З огляду на високі показники у виході нових
версій окремих програм МДС на ба-зе ООП, 1 адміністратор може обслуговувати
до 22-25 користувачів. З нашого досвіду, час від появи пакету виправлень
до її повної інсталяції на всіх комп'ютерах се-ти може становити від 2-3
діб при роботі 50 станцій до 4-7 діб при роботі 100-150 станцій. Цей факт
загрожує тим, що зловмисник може скористатися цим промежут-ком для
порушення системи безпеки або іншого завдання шкоди, якщо він знає
механізмів помилки, яку планується виправити "латкою".
Аналізуючи
ці проблеми, було запропоновано використовувати технологію установки та об-лення
програм [8, 11, 14]. Суть її роботи полягає в наступному: у системі є
виділена база даних дистрибутивів додатків. Всі команди на запуск
додатків використовують у своїй роботі спеціальний сервіс, що надається
системою. Їй передається команда на запуск програми, яка містить код програми
і параметри її запуску. Всю необхідну роботу виконує система, використовуючи
наступний алгоритм (рис. 3).
Визначається,
чи є опис програмного продукту з переданим кодом в цін-тре
програм. Якщо опис не знайдено, видається повідомлення про помилку.
обчислюються
з опису програми необхідні дані, зокрема: номер версії ПЗ, ім'я
файлу, що виконується і т. д.
Перевіряється,
чи є викликається ПЗ на комп'ютері користувача: якщо ні, провадиться
інсталяція програмного забезпечення - з бази даних витягуються необ-дімие
файли та налаштування, створюється програмна папка і виконується копіювання файлів
і т. д. Після закінчення процесу установки виконуваний файл запускається.
Якщо
викликається ПО є на комп'ютері користувача, перевіряється його версія і
порівнюється з версією в центрі програм. У випадку, якщо на локальному
комп'ютері з-тримається старою версією, проводиться оновлення програмних
файлів в залежно-сті від настройок одним із таких способів:
метод
перевстановлення. Він є найбільш простим рішенням. При його використан-панії,
проте, механізм синхронізації повинен оцінити такі фактори: доступність
оновленого дистрибутива, його обсяг і час копіювання на дану робочу
станцію, права доступу цього користувача до потрібного збірки, як можливі
обмеження, що накладаються адміністратором мережі на даний дистрибутив;
метод
оновлення. Він більш трудомісткий. Його суть у тому, що на даному комп'ютері
додаток не встановлювати заново цілком, а лише перезаписується його
виправлена частина. Цей метод має перевагу в тому, що обсяг даних для
виправлення значи-тельно менше в порівнянні з повним дистрибутивом.
метод
виправлення довідників. Застосовується, якщо програма сама не змінило свою
версію, проте його довідник застарів у порівнянні з еталоном системи.
Якщо
всі перевірки пройдено, виконуваний файл запускається.
Рис.
3. Алгоритм роботи підсистеми встановлення та оновлення програм
Застосування
даної технології дозволило скоротити час, необхідний на обновле-гом
клієнтського програмного забезпечення з 2-3 днів до 5-10 сек. (у середньому),
знизити за-ЛПУ витрати на адміністрування інформаційної системи на 47,8% за
рахунок зниження трудовитрат адміністратора системи та можливості суміщення
ставок програміста і адміністратора. Щорічна економія становить близько $ 72
на одного користувача.
Список літератури
Айламазян
А. К., Гулієв Я. І. Дані, документи та архітектура медичних Інформаційним
систем. http://interin.botik.ru
Айламазян
А. К., Гулієв Я. І., Матвєєв Г. Н., Турна І. А., Белова И. А. ІС КОТЕМ-2001:
Вимоги, проблеми, рішення. http://interin.botik.ru
Андерсон
К., Мінас М. Локальні мережі. Полное руководство: Пер. з англ. - К.: ВЕК +, ентропія,
Спб.: КОРОНА принт, 1999. - 624 с.
Андрєєв
А. М., Березкін Д. В., кантоністи Ю. А. Вибір СУБД для побудови
Інформаційним систем корпоративного рівня на основі об'єктної парадигми//
СУБД 1998. - № 4-5. - С.26-50.
Губин
И. М., Тарасов В. В., Антонов Р. А. та інші. Розробка і впровадження нової
авто-матізірованной інформаційної системи ЦКБ// Кремлівська медицина.
Клінічний вісник, 2000. - № 4. - С.51-54.
Гусєв
А. В., Романов Ф. А., Дуданов І. П.. Досвід розробки медичної
інфор-онной системи// Медичний академічний журнал, 2001 .- № 1 .-
Додаток 1 .- С.18.
Гусєв
А. В., Романов Ф. А., Осіік Т. А.. Застосування медичної інформаційної
системи в роботі клінічних лабораторій медичного центру// Медичний
ака-деміческій журнал, 2001. - № 1. - Додаток 1. - С.19.
Гусєв
А. В., Дуданов І. П. Оцінка 3-річного досвіду розробки і впровадження
інфор-онной системи: висновки та перспективи// Медичний академічний
журнал, 2002. - Том 2. - Додаток 2. - С.56-57.
Гусєв
А. В., Дуданов І. П., Романов Ф. А. Інформаційна система в медицині --
кон-цептуальная модель.http:// surgery.karelia.ru
Гусєв
А. В., Романов Ф. А., Дуданов І. П., Воронін А. В., Інформаційні системи в
охороні здоров'я. ПетрГУ. Петрозаводск, 2002. - 120 с.
Дуданов
І. П., Гусєв А. В., Романов Ф. А., Воронін А. В. і співавт .. Інформаційна
система в охороні здоров'я - концептуальна модель// Серцево-судинні
заболева-ня. Бюлетень НЦССХ ім. А. Н. Бакулева РАМН. Том 3. - № 11. - 2002. --
С.332.
Дуданов
І. П., Гусєв А. В., Романов Ф. А., Воронін А. В. Інформаційні системи в
охороні здоров'я// Медичний академічний журнал, 2002. - № 1 .- Том 2 .-
Стор.58-77.
Дуданов
І. П., Гусєв А. В., Романов Ф. А., Кемпи С. І. Регіональна інформаційна
система "Кондопога"// Серцево-судинні захворювання. Бюлетень
НЦССХ ім. А. Н. Бакулева РАМН. 2002. - Том 3. - № 11. - С.335.
Дуданов
І. П., Гусєв А. В., Романов Ф. А., Кемпи С. І. та співавт. Створення "паспорта
здо-ровья "хворих з серцево-судинними захворюваннями з використання
інформаційні ної системи// Медичний академічний журнал, 2003. - Том 3. - №
3. - С.125-133.
Ільмаст
А. В., Марусенко К. М., Моісеєв Є. В. Деякі питання технології разр-лення
МДС// Медичний академічний журнал, 2002. - Том 2. - Додаток 2. --
С.85-86.
Принципи
проектування та розробки програмного забезпечення. Навчальний курс MCSD: Пер. з
англ. - М.: Видавничо-торговий дім "Русская редакция", 2000. - 608
с.
Шеррер
Жан-Рауль. Інформаційні системи в охороні здоров'я: технологія та орга-нізація
//Кремлівська медицина. Клінічний вісник, 2000. - № 4. - С.15-17.
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
Ramamoorthy C. V., Prakash A., Tsai
W. T., Usuda Y. Software Engineering: problems and perspectives. Computer.
Outubro. 1984. - P.191-209.
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.
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.
Spahni S., Sherrer Jr. Sauquet D.,
Sottile PA. Consensual trends of optimizing the constitution of middleware. ACM
SIGCOMM Computer Communication. - 1998. - V.28, № 5. - P.76-90.
Для
підготовки даної роботи були використані матеріали з сайту http://www.citforum.ru/
