Технологія «Клієнт-сервер» - технологія, що розділяє додаток-СУБД на дві частини: клієнтську (інтерактивний графічний інтерфейс, розташований на комп'ютері користувача) і сервер, власне здійснює управління даними, поділ інформації, адміністрування і безпека, що знаходиться на виділеному комп'ютері. Взаємодія «клієнт-сервер» здійснюється наступним чином: клієнтська частина програми формує запит до сервера баз даних, на якому виконуються всі команди, а результат виконання запиту відправляється клієнту для перегляду і використання. Ця технологія застосовується, коли розміри баз даних великі, коли великі розміри обчислювальної мережі, і продуктивність при обробці даних, що зберігаються не на комп'ютері користувача (у великому установі зазвичай має місце саме така ситуація). Якщо технологія «клієнт-сервер» на застосовується, то для обробки навіть кількох записів весь файл копіюється на комп'ютер користувача, а тільки потім обробляється. При цьому різко зростає навантаження на мережі, і знижується продуктивність праці багатьох співробітників.
Microsoft Access, Microsoft Visual FoxPro, Microsoft Visual Basic забезпечують засоби для створення клієнтських частин у додатках «клієнт-сервер», які поєднують в собі засоби перегляду, графічний інтерфейс і засоби побудови запитів, а Microsoft SQL Server є на сьогоднішній день одним з найпотужніших серверів баз даних.
OLE 2.0 (Object Linking and Embedding - зв'язування і впровадження об'єктів) - стандарт, що описує правила інтеграції прикладних програм. Застосовується для використання можливостей інших додатків. OLE 2.0 використовується для визначення та спільного використання об'єктів кількома додатками, які підтримують дану технологію. Наприклад, використання в середовищі Access таблиць Excel і його могутніх засобів побудови діаграм або використання даних, підготовлених Access, у звітах складених в редакторі текстів Word (зв'язування або включення об'єкта).
OLE Automation (Автоматизація OLE) - компонент OLE, дозволяє програмним шляхом встановлювати властивості і задавати команди для об'єктів іншої програми. Дозволяє без необхідності виходу або переходу до іншого вікна використовувати можливості потрібного додатку. Додаток, що дозволяє іншим прикладним програмам використовувати свої об'єкти називається OLE сервером. Додаток, який може управляти об'єктами OLE серверів називається OLE контролер або OLE клієнт. З розглянутих програмних засобів як OLE серверів можуть виступати Microsoft Access, а також Microsoft Excel, Word і Graph... Microsoft Visual FoxPro 3.0 і 5.0 може виступати тільки у вигляді OLE клієнта.
RAD (Rapid Application Development - швидка розробка додатків) - підхід до розробки додатків, що передбачає широке використання готових компонентів і / або програм і пакетів (в тому числі від різних виробників).
ODBC (Open Database Connectivity - відкритий доступ до баз даних) - технологія, що дозволяє використовувати бази даних, створені іншою програмою за допомогою SQL.
SQL (Structured Query Language - мова структурованих запитів) - універсальна мова, призначений для створення і виконання запитів, обробки даних як у власній базі даних програми, так і з базами даних, створених іншими додатками, що підтримують SQL. Також SQL застосовується для управління реляційними базами даних.
VBA (Visual Basic for Applications - Visual Basic для додатків) - різновид (діалект) об'єктно-орієнтованої мови програмування Visual Basic, вбудована в програмні пакети.
На сучасному етапі для медицини створено понад 800 різних програмних продуктів самого різного призначення, функціональних можливостей і виду. Серед цього ПЗ особливе місце займають комплексні медичні інформаційні системи, які характеризуються великим спектром можливостей і призначені головним чином для повної автоматизації лікувально -профілактичних закладів (ЛПЗ). При цьому велике значення має обрана система управління базами даних (СКБД)
За різними оцінками, в СНД тільки від 20 до 30 медичних інформаційних систем можуть претендувати на комплексний характер. Їх розробка займає в середньому від 2 до 5 років і являє собою складну задачу, що вимагає значних фінансових, інтелектуальних і часових ресурсів. Все це робить сегмент ринку комплексних медичних інформаційних систем досить ризикованим.
Разом з цим саме попит на промислові комплексні системи має останні роки стабільну позитивну динаміку - замовники від медицини потребують готових масштабованих рішеннях, що володіють високою захищеністю інвестицій, прийнятними термінами впровадження та гарантованої віддачею від реалізації ідеї автоматизації медицини. І тут саме комплексні рішення володіють тим необхідним запасом надійності та ефективності, який дозволяє все більшій кількості ЛПУ зважитися на настільки складний, дорогий і досить ризикований крок, як автоматизація свій діяльності.
Вибір конкретної СУБД являє собою складну багатопараметричну задачу і є одним з найважливіших етапів в розробці ІС. Програмний продукт повинен задовольняти як поточним, так і майбутнім потребам замовника, при цьому слід враховувати фінансові витрати на придбання необхідного обладнання, самої системи, розробку необхідного програмного забезпечення на її основі, а також навчання персоналу.
Очевидно, найбільш простий підхід при виборі СУБД заснований на оцінці того, якою мірою існуючі системи задовольняють основним вимогам створюваного проекту ІС. Більш складним і дорогим варіантом є створення випробувального проекту на основі кількох СУБД і подальший вибір найбільш підходящого з кандидатів. Але і в цьому випадку необхідно обмежувати коло можливих систем, спираючись на якісь критерії відбору. Однак подібний підхід є досить дорогим заходом, при цьому вельми схильним суб'єктивності й упередженості. Більш того, результати одного і того ж експерименту можуть бути інтерпретовані як на користь однієї СУБД, так і на користь іншої, залежно від розставлених пріоритетів вибору СУБД або особливостей конкретного розробника.
На противагу експериментальному підходу у виборі СУБД емпіричний аналіз хоч і не дає конкретних рекомендацій і, строго кажучи, не призначений для виявлення найбільш вдалою або навпаки, найгіршою для комплексної медичної інформаційної системи СУБД, зате дозволяє вести цей вибір на основі досить об'єктивних показниках, сформованих багаторічної практикою і спостереженнями ринку. Все вищесказане спонукало провести таке емпіричне дослідження з метою виявити тенденції і об'єктивні показники використання СУБД в сучасних медичних інформаційних системах.
Переважна більшість сучасних комплексних медичних інформаційних систем заснована на архітектурі "Клієнт -сервер". Практичним досвідом доведена неминучість такого рішення для створення комплексної інформаційної системи, так як настільні бази даних, у тому числі з використанням файл- сервера, здатні підтримувати тільки до 10 робочих станцій і невеликий обсяг бази даних. Крім того, значна частина існуючих вимог до медичних інформаційних систем вже реалізована в промислових СУБД, побудованих в архітектурі "клієнт - сервер", що дозволяє істотно скоротити час на створення системи.
Розподіл вітчизняних комплексних медичних інформаційних систем по застосовуваних СУБД
Для порівняння: якщо проаналізувати все медичне ПО, що використовує архітектуру " клієнт - сервер", частка СУБД Microsoft SQL Server складе 64 %. Деякі розробники (17 %) допускають використання декількох СУБД, найчастіше, це комбінація Microsoft SQL Server або Oracle. Дві системи (Карельська медична інформаційна система і " Парацельс -А") використовують кілька СУБД - Lotus Notes / Domino і реляційну СУБД (Microsoft SQL Sever і IBM DB2 відповідно).
Всі вживані СУБД діляться на два принципово різних типи: реляційні і постреляціонних (об'єктно - орієнтовані). При аналізі всього ПО для медицини ми з'ясували, що в даний час в Росії 92 % програмних продуктів засновані на реляційних СУБД. Серед медичних інформаційних систем перевага реляційних баз даних не таке безумовне - 70 %. Інші 30 % займають постреляціонних СУБД. При цьому в дану категорію ми включили Lotus Notes / Domino, яку лише умовно можна назвати постреляціонной - це скоріше документно -орієнтована платформа для групової роботи. Lotus Notes / Domino і Cache до 2005 р. займали паритетні позиції - обом належало по 50 % постреляціонних сегмента СУБД, проте останнім часом, мабуть в силу більш агресивної політики корпорації InterSystems (постачальник Cache) частка цієї СУБД збільшилася до 57%.
