Чи можна застосувати "Agile" до ІТ-команд охорони здоров'я?

Чи можна Agile зайнятись у такій галузі, як ІТ-сфера охорони здоров’я, де стільки догляду за пацієнтами залежить від якості та своєчасної доставки систем?

Так, спритний розвиток абсолютно відіграє роль у розвитку ІТ в галузі охорони здоров'я. Ніхто, не кінцевий споживач, не пацієнт і, звичайно, не команда розробників, добре обслуговуються погано виконаним процесом розробки. Розглядаючи деякі принципи, які лежать в основі маніфесту "Agile" (список безсоромно вирваний з Вікіпедії з моїм коментарем):

• Задоволення клієнтів швидкою доставкою корисного програмного забезпечення . Коли це не мета?
• Ласкаво просимо змінити вимоги, навіть пізно в розробці . Здоров'я ІТ інтегрується у сферу, яка, хоча й абсолютно затоплена технологіями, не особливо орієнтована на ІТ. Потенціал для системи, яка розробляється для того, щоб "виправити її" відразу ж у миші, досить низька.
• Робоче програмне забезпечення постачається часто (тижні, а не місяці) . Я буду любити це як кінцевий користувач деяких цих речей. Швидкі, робочі зміни неоцінені, і те, що перетворює ІТ в галузі охорони здоров’я з "того, що нам потрібно зробити", до "тієї речі, яка змінює те, як я роблю свою роботу".
• Робоче програмне забезпечення - головний показник прогресу . Має сенс у більшості програм, тому насправді немає причин, щоб він не охопив HIT.
• Сталий розвиток, здатний підтримувати постійний темп . Ви бачите це в усьому галузі охорони здоров’я - від спостереження за інфекцією до ХІТ до закладів. Охорона здоров’я - це не цикл булінгу чи ударів, його постійний удар.
• Тісна, щоденна співпраця між діловими людьми та розробниками . Більшість HIT не є інструментом для розробників. Це інструмент, зроблений розробниками. Контакт з клієнтом є і повинен бути ключовим. Також набагато простіше отримати прийняту систему, якщо вона працює та інтегрується в робочий процес клієнтів, а не потребує їх прив'язки, виправлення тощо.
• Розмова віч-на-віч - найкраща форма спілкування (спільне розташування) . З мого взаємодії з лікарями, це спосіб легше отримати речі зроблено особисто, бажано з подушечками паперу, ніж будь-яким іншим способом.
• Проекти будуються навколо мотивованих людей, яким слід довіряти . Це те, що покращить ваше життя - так, так, його слід прийняти;)
• Постійна увага до технічної досконалості та гарного дизайну . Це знову одне з тих, "хто повинен робити це, так що, звичайно, слід". Але врахуйте складність HIT-систем і безліч способів їх використання, щоденних, вихідних. Кмітлива система не збирається її різати.
• Простота . Це повинно працювати поза коробкою. Це повинно працювати добре, весь час, і так, як це належить. Люди - ідіоти. Медичні працівники - це люди. Тому ... ви знаєте інше. Простота допомагає.
• Самоорганізуючі команди . Це може бути трохи більше розтягування для HIT. Чесно кажучи, я недостатньо впевнений, щоб сказати так чи інакше, добре чи самоорганізація в цій обстановці чи ні.
• Регулярне пристосування до мінливих обставин . HIT - активна, зростаюча галузь, що має складні, змінюються регуляторні тягарі. Можливість адаптуватися здається пристойною ідеєю.

Дискусії щодо використання розробки програмного забезпечення Agile Medical Device в умовах, регульованих FDA, тривалий час тривалий час і стосуються цього питання. Ось кілька причин, чому:

1. Плюси і мінуси водоспаду проти ітеративного розвитку по суті однакові, і їх потрібно враховувати для будь-якого проекту ІТ в галузі охорони здоров'я.
2. Системи якості FDA (див. Загальні принципи перевірки програмного забезпечення; Кінцеві рекомендації для промисловості та персоналу FDA ) для розробки програмного забезпечення для медичних пристроїв є галузевим золотим стандартом. Слід зазначити, що ці норми не диктують якоїсь конкретної методології розвитку. У будь-якому випадку якість програмного забезпечення в галузі охорони здоров'я ІТ значно покращиться, якби всі найкращі практики дотримувались усіх.
3. Більшість розробок ІТ-програмного забезпечення Heath наразі не працює за цими нормативними стандартами FDA. Оскільки бар'єри для інтероперабельності медичних пристроїв продовжують падати, зокрема для мобільних платформ, це, швидше за все, зміниться - див. FDA адреси для мобільних медичних додатків .
4. Крім того, якщо ви розробляєте комерційне програмне забезпечення для охорони здоров’я, вам слід запитати себе, чи створюєте ви систему даних про медичні пристрої (MDDS): чи мій продукт є MDDS?

Коротка відповідь - «Так». Більш довга, але точніша відповідь - "Якщо ви сприймете це серйозно".

Майте на увазі кілька тем, які я хотів би розділити на питання, пов'язані з (a) безпекою пацієнтів та якістю продукції та (b) галузевим регулюванням.

Що стосується безпеки та якості, майте на увазі, що зробити безпечне програмне забезпечення важко. Кілька хороших програмістів з деякими знаннями домену можуть вивернути надзвичайно корисне програмне забезпечення, яке досить безпечно. Якщо вони є частиною розгортання в локальній клінічній обстановці і можуть продовжувати реагувати і коригувати події під час розгортання та використання програмного забезпечення, програмне забезпечення може забезпечити цінність, врятувати або покращити життя лише з кількома травмами або смертьми пов'язана з помилками використання або програмні помилки. Але програмне забезпечення вимагатиме від програмістів бути там постійно, реагуючи, спільно розвиваючи програмне забезпечення в міру розвитку програмного забезпечення. Це не масштабований процес, і коли програмісти помирають або нудьгують, система може дуже швидко стати дуже небезпечною. Щоб покращити ці результати та зробити безпечне програмне забезпечення, є важливі кроки процесу розробки, які необхідно вжити під час розробки програмного забезпечення. Хороший вступ до цього "не в коробці" можна знайти в міжнародному стандарті на розробку програмного забезпечення медичного обладнання ISO / IEC 62304. Основна концепція - це управління ризиками для безпеки на всіх етапах - під час аналізу випадків використання та розробки історії, вимог з'ясування, системне та архітектурне проектування, впровадження, тестування блоків та інтеграції. Якщо бути спритним, це не призведе до того, що будь-яка з цих робіт не піде або буде менш складною, але зосередившись на створенні цінностей та усуненні роботи (наприклад, непотрібних функцій або надмірних циклів перевірки / виправлення), що не створює цінності, спритний розвиток може дозволяють команді інтегрувати цю роботу в розробку, в результаті чого в той же час було розроблено більш безпечне програмне забезпечення. Ітеративні практики розробки, що зазвичай використовуються спритними командами, дуже добре підходять для виконання роботи з управління ризиками безпеки, що розвиваються протягом усього життя проекту, а не є продуманими. І після того, як програмне забезпечення функціонує, відгуки користувачів та будь-які події, які потенційно можуть призвести до травм, повинні розглядатися індивідуально та в сукупності, щоб програмне забезпечення було безпечним у використанні. Тут Agile може допомогти, якщо він забезпечує швидкий, безпечний процес для внесення змін, не порушуючи інших частин системи - що, в свою чергу, ще раз вимагає гарної архітектури та добре зрозумілих дизайнерських взаємодій, які були створені при розробці програмного забезпечення. еволюціонувати протягом усього життя проекту, а не бути думкою. І після того, як програмне забезпечення функціонує, відгуки користувачів та будь-які події, які потенційно можуть призвести до травм, повинні розглядатися індивідуально та в сукупності, щоб програмне забезпечення було безпечним у використанні. Тут Agile може допомогти, якщо він забезпечує швидкий, безпечний процес для внесення змін, не порушуючи інших частин системи - що, в свою чергу, ще раз вимагає гарної архітектури та добре зрозумілих дизайнерських взаємодій, які були створені при розробці програмного забезпечення. еволюціонувати протягом усього життя проекту, а не бути думкою. І після того, як програмне забезпечення буде функціонувати, відгуки користувачів та будь-які події, які потенційно можуть призвести до травм, повинні розглядатися індивідуально та в сукупності, щоб програмне забезпечення було безпечним для використання. Тут Agile може допомогти, якщо він забезпечує швидкий, безпечний процес для внесення змін, не порушуючи інших частин системи - що, в свою чергу, ще раз вимагає гарної архітектури та добре зрозумілих дизайнерських взаємодій, які були створені при розробці програмного забезпечення.

Друге питання - регулятивне. В ідеальному світі правила безпеки застосовуватимуться до всіх продуктів, які можуть бути досить небезпечними, і постачальник зможе дотримуватися, виконуючи прості речі, як тільки вони почнуть перетинати лінію. На практиці глобальні норми є складними і швидкозмінними в цій галузі, це означає, що одного дня ви можете розробляти невеликий додаток для iPhone, який показує деякі медичні дані, а наступного, як очікується, ви будете відповідати стандартам ISO та FDA для "управління якістю система "або СМЯ. Це може бути страшно для компаній, які раніше не мали офіційної СМК. А спритний може посилити це, тому що ви можете почати з продуктової концепції, і через еволюційну розробку мимоволі вступите в регульоване призначення (наприклад, показ даних клінічної діагностики користувачеві). Це жовтень 2011 року; Моя порада будь-якій компанії, що розглядає маркетинг товару, що має назву категорії "здоров'я", "медичне", "охорона здоров'я", полягає в тому, щоб у них був план, коли продукт, який вони виготовляють, регулюється одним або декількома регуляторами медичних виробів у всьому світі. Тут знову спритний може допомогти, оскільки спритна практика, як правило, виробляє (або легко може виробляти) сумісні продукти, щоб задовольнити регуляторних клієнтів як для подання заявок на передринок (наприклад FDA 510k), сертифікації (як ISO 13485), так і після ринкових операцій. Тестова розробка вписується прямо в медичне програмне забезпечення. Постійна інтеграція, автоматизоване тестування одиниць та метадані спринту SCRUM можуть забезпечити повне об'єктивне підтвердження того, що управління ризиками та належна перевірка виконуються не просто як задумливі, а підготовлені до процесу розробки. У більшості випадків я думаю, що Agile створює більше артефактів, ніж "водоспад", можливо, не в тому ж вигляді. Але перетворення результатів у щось, що задовольняє регулятори, є порівняно невеликою проблемою, яку можна вирішити.

Отже, підсумовуючи ... так, Вірджинія, існує гнучка розробка програмного забезпечення для ІТ (та інших медичних пристроїв). Як і всі спритні речі, потрібно займатися процесами, підтримкою бізнесу та сміливістю.

Так, одним із умов спритного розвитку є залучення клієнтів. Це критично важливо в ІТ-системах та процесах охорони здоров'я. ІТ-відділи охорони здоров'я приймуть кращі рішення, якщо буде залучений представник замовника та надасть інформацію про те, як рішення впливатимуть на допомогу пацієнтам.

Я думаю, що це можливо, але галузь потребує величезної зміни парадигми. Я на другому курсі як розробник охорони здоров’я, і довіра та самоорганізація ніде не виявляються. Охорона здоров’я отримала б велику користь від формального сприйняття спритних, оскільки це в основному хаос у будь-якому випадку, ітеративна розробка, яка називається "треш", та вимоги, що змінюються пізно, тому що, ну, великий дизайн наперед не працює.

Я розумію ваше запитання. Хороший приклад розвитку Agile - це створення веб-сайту для когось. Зазвичай клієнт точно не знає, чого він / вона хоче, тому існує велика взаємодія з клієнтом.

ІТ в галузі охорони здоров'я може здатися дуже заздалегідь заданою галуззю інформатики; з його суворими стандартами (DICOM, HL7), схоже, існує лише один спосіб їх реалізації, але також є багато переваг та прийняття рішень.

На мою думку, який би продукт ви не робили, ви не в змозі визначити ВСІ вимоги достроково, тому спритний метод розробки програмного забезпечення працює дуже добре.

Як зазначалося, відповідь - так.

При застосуванні Agile до регульованих або з високим рівнем ризику ви повинні визначати "Готово" під час кожної ітерації таким чином, щоб було включено відповідність законодавству та інші стратегії зменшення ризику. Наприклад, для цього може знадобитися документація щодо забезпечення якості, відстеження вимог, аудит безпеки та інші дії для кожної ітерації.

Наприклад, є добре мистецтво та практика, наприклад, для застосування Agile підходів до регульованих середовищ FDA.

Коротка відповідь: Так. Є хороший блог про Agile у середовищах з високою надійністю, який дає кілька порад.

Однак є деякі компроміси, які потрібно зробити. Розглянемо маніфест Agile :

Індивіди та взаємодія над процесами та інструментами

Працює програмне забезпечення над всеосяжною документацією

Співпраця з клієнтами щодо укладання договорів

Відповідаючи на зміни протягом наступного плану

Регулюючі органи цінують лівий бік стільки ж, скільки і спритні команди, але вони вимагають більше уваги на правій частині, ніж типова спритна команда. Наприклад, FDA вимагає підтвердити свої процеси та інструменти, вимагає досить всебічної проектної та тестової документації, і, безумовно, вимагає багато планування.

З іншого боку, багато спритних принципів дуже добре вписуються у світ охорони здоров'я, включаючи:

• TDD та парне програмування - підвищення якості
• Щільні петлі зворотного зв’язку з клієнтами - рання перевірка чудова
• Ітераційне планування - регулюючі органи все стосуються планування

Деякі дисципліни мають вже спритний характер. Наприклад, медсестра спирається на цикли "оцінка-оцінка-планування-втручання", що залежить від багаторазових ітерацій діагностики / прогнозу для поступового досягнення кінцевих результатів.

Однак, було б фатальним зв’язком намагатися припустити, що медичні послуги, що надаються таким чином, спеціально підходять для застосування по суті одноразової розробки програмного забезпечення Agile щодо програмного інструменту або системи для використання в зазначеній наданні послуг.

ААМІ активно працює над технічним інформаційним звітом під назвою:
AAMI TIR SW1, Посібник із використання спритних практик при розробці програмного забезпечення медичного обладнання.

Я чув, що це може бути опубліковано у 2012 році.

У ньому обговорюється узгодження принципів Agile Manifesto (див. Відповідь EpiGrads) з ​​нормативними вимогами, типовими процесами та іншими практичними засобами, пов'язаними з програмним забезпеченням медичних пристроїв.