Сучасні медики - народ досить просунутий, щоб в повній мірі усвідомити важливість впровадження інформаційних систем в роботу лікарень. Але їх очікування від автоматизації не завжди є адекватними, - стверджують автори статті. Детальніше про це читайте нижче.
зміст
Перш ніж говорити про розчарування, варто сказати кілька добрих слів про значний прогрес у відносинах керівників медичних організацій і лікарів з інформаційними технологіями за останні п'ять-сім років. Зараз створення кожної нової клініки вже важко уявити без IT-складової. Це вже свого роду стандарт. Важливість автоматизації вже усвідомлена в багатьох лікувально-профілактичних установах.
Особливо помітно визнання необхідності автоматизації при створенні комерційних медичних центрів. Будь-який приватний інвестор, плануючи створення окремої клініки і тим більше мережі медустанов, відразу закладає в інвестиційний бюджет їх оснащення сучасною інформаційною системою.
З іншого боку, переважна більшість державних медустанов або не автоматизовані зовсім, або практикують клаптикову, вірніше фрагментарну автоматизацію. І це при тому, що багато лікарів вже давно «на ти» з комп'ютером і приватним порядком активно користуються програмними додатками і інтернетом.
Незважаючи на низький рівень автоматизації в середньому по галузі охорони здоров'я, зараз цілком можна стверджувати, що психологічно медичне співтовариство готове до масового впровадження інформаційних технологій. Це видно, зокрема, за рівнем обізнаності лікарів. На відміну від ситуації п'яти-семирічної давності, якщо заходить розмова про медичні системах, то лікарям, як правило, не доводиться роз'яснювати що таке електронна медична карта - невід'ємний компонент будь-якої промислової медичної інформаційної системи.
Там же, де лікарі та управлінці на ділі познайомилися з перевагами комп'ютерних технологій, єдині інформаційні системи все більше стають хребтом інфраструктури всього лікувально-профілактичного закладу - через інтеграцію з обладнанням, через інформаційний обмін з іншими клініками та страховими компаніями.
Труднощі впровадження інформаційних систем в роботу медустанов
На жаль, впровадження інформаційних систем не завжди йде гладко. В цьому відношенні медицина - не виняток. І в інших галузях є безліч прикладів невдалих або важких впроваджень, які не приносять бажаних результатів покупцями системи. Важкі впровадження викликані безліччю причин. Тут же нам хотілося б зупинитися лише на деяких з них. Головним чином, на ті труднощі, які пов'язані з невірними очікуваннями медичних організацій при покупці інформаційної системи.
Звичайно, завжди існує розрив між об'єктивними результатами впровадження і властивостями складних програмних продуктів, з одного боку, і суб'єктивною оцінкою цих результатів учасниками впровадження, з іншого. Але, думається, одна з основних причин важких впроваджень - це хибні уявлення та очікування замовників при покупці IT-рішень.
Наприклад, не всі менеджери чітко усвідомлюють різницю між простим офісним додатком і розрахованої на багато користувачів системою. Але ж якщо в першому випадку мова йде про інструмент для окремої функції, виконуваної одним співробітником, то в другому - про інструмент, що підтримує роботу цілої організації з десятками або сотнями користувачів. При цьому найчастіше бізнес-процеси цієї організації не формалізовані, тобто не задокументовані і за великим рахунком невідомі у всіх деталях.
Буває, що керівництво медустанови, вже прийнявши рішення про покупку програмного продукту, не має уявлення про пересічних труднощі впровадження. Таких, наприклад, як неминучий стрес для персоналу, хвороблива ломка стереотипів і, як наслідок, саботаж нової технології.
Коли ж в ході проекту всі ці проблеми стають очевидними, то адміністрація лікувально-профілактичного закладу робить часом поспішні висновки і намагається суттєво обмежити сферу застосування інформаційних технологій. Це може бути, наприклад, відмова від обов'язкового використання системи лікарями і зведення впровадження до автоматизації бухгалтерії і обліку послуг.
Такі рішення можуть обґрунтовуватися тим, що лікарям доведеться витрачати більше часу на прийом пацієнта, якщо вони будуть заносити дані в систему. Практика показує, що на початкових етапах невеликі затримки дійсно можуть мати місце - люди вчаться, звикають, освоюють нові можливості. Але потім, у міру освоєння системи продуктивність праці лікарів зростає в порівнянні з «паперової» технологією.
Поспішний відмова від частини функцій системи не тільки обмежує окремі можливості, але знижує ефективність впровадження в цілому. Адже в комплексних медичних системах саме комплексність дає значні переваги в порівнянні з клаптикової автоматизацією. Таким чином, поспішні рішення, пов'язані з моральної неготовністю і необізнаністю, виявляються більш руйнівними, ніж природні труднощі освоєння нової технології.
Ще одне типове непорозуміння - ставлення до супроводу інформаційних систем. Причина в тій же необізнаності і нерозумінні того, наскільки різний рівень складності мають настільні програми і комплексні інформаційні системи. Трапляється, що адміністрація лікувально-профілактичного закладу не тільки не визнає потрібність і важливість технічного супроводу системи розробниками, але і не визнає корисність внутрішньої IT-служби. Хоча навіть один грамотний фахівець в штаті клініки може зняти багато проблем експлуатації системи і стабілізувати умови для нормальної роботи користувачів.
Внутрішня IT-служба замовника - це не розкіш, а гарантія стабільності і розвитку. Задумуючи автоматизацію, далеко не всі медичні установи зазирають у майбутнє. Далеко не всі усвідомлюють, що після впровадження системи, коли люди відчують нові можливості, життя не завмре на місці, а буде рухатися далі. Еволюціонують і потреби користувачів і організація в цілому.
Інша крайність - спроба деяких лікувально-профілактичних установ зробити комплексну систему своїми силами. Керівники, які вирішили йти цим шляхом, зазвичай призводять два простих аргументу. По-перше, що власна розробка дозволить автоматизувати важливі особливості, конкурентні переваги клініки. По-друге, свої програмісти будуть все робити набагато дешевше, ніж зовнішній підрядник.
Навіть якщо визнати, що в деяких випадках ці міркування можуть виявитися виправданими, важливо розуміти пов'язані з ними обмеження і, найголовніше, підсумкову ціну рішення. Автоматизація конкурентних переваг, звичайно, гідна завдання. Але яку частку становлять специфічні бізнес-процеси в загальному обсязі функцій медустанови? Їх може бути 5, 10, в крайньому випадку 20%, навряд чи більше. А між тим, якщо буде прийнято рішення робити в домашніх умовах інші 80-95%, то все особливості внутрішньої розробки поширяться і на них.
Що це за особливості? Вони особливо яскраво проявляються при тій самій прискореної розробки, яку прихильники «домашнього» програмного забезпечення призводять в якості другого аргументу «за» саморобну систему. Це швидкість і дешевизна. Бажання зробити все якомога швидше практично завжди обертається порушенням архітектурної цілісності системи і відмовою від планування і документування робіт. Причому виявляється відкинутою не тільки для користувача, але і технічна документація.
Чи варто пояснювати, чим це обертається при появі нових вимог до системи і необхідності внесення змін! Повсюдно саморобні системи відчувають також серйозні труднощі з підключенням складного медичного обладнання. В результаті забезпечується не швидкість, а ілюзія швидкості розвитку. Оскільки за фрагментарними успіхами слід, як правило, період фактично негативною продуктивності в розробці. Образно кажучи, система починає «сипатися». Мовою теорії проектного управління дана ситуація описується як поєднання високих ризиків і високу вартість володіння системою.
Зазвичай медустанови схильні тільки до однієї з двох крайнощів. Або живуть зовсім без IT-служби, або намагаються написати свою систему. Але бувають і такі випадки, коли спочатку приймаються одні рішення, а потім - діаметрально протилежні. Організація робить по дві, по три спроби почати все заново, йде від готового рішення до власної розробки і потім повертається назад.
Не можна сказати, що незалежні розробники зовсім непричетні до цих драматичних історій. На жаль, у замовника бувають вельми серйозні підстави для заміни колись обраного програмного продукту. Часто це буває пов'язано з надмірною жорсткістю продукту, його нездатністю слідувати за змінами в роботі організації. Інший типовий гріх розробників - незадовільна постановка процесу впровадження, що, втім, є проблемою для всього російського ринку комплексних інформаційних систем.
Неадекватні і завищені очікування, пов'язані з недостатньою обізнаністю, проявляються не тільки в недооцінці труднощів впровадження або завищену оцінку перспектив внутрішньої розробки. Ще одна поширена помилка - деяке перебільшення можливостей автоматизації як такої. Скажімо, на нинішньому етапі розвитку ще не доводиться говорити про повноцінні системах підтримки прийняття рішень, які забезпечили б лікарів корисними інтелектуальними підказками на всі випадки життя. Хоча в майбутньому, можливо в найближчому майбутньому, подібні функції неодмінно з'являться. По крайней мере, в серйозних, промислових системах.
В основному ж, два найбільш поширених помилки - це завищені очікування щодо термінів і уявлення про впровадження системи як про кінцевий процесі. Іноді від постачальників очікують, що впровадження буде швидким, майже миттєвим. Мається на увазі також, що з установкою системи всі турботи залишаться позаду. Про те, з якими труднощами пов'язана установка систем, ми вже сказали вище. Успішне подолання цих труднощів можливо тільки при тверезому розрахунку тимчасових і кадрових ресурсів: без гарячки і шапкозакидування.
Що стосується закінченості впровадження, то тут також не зайве повторити думку про безперервну еволюції вимог до системи. Звичайно, в кожному впровадженні треба підводити риску. Заявлений постачальником набір функцій повинен бути реалізований. Але потім, коли фахівці усвідомлюють всі відриваються можливості, апетити користувачів ростуть і робота над розвитком продукту триває. А це означає нові впровадження, нові проблеми і нові досягнення.
