Особливості розробки healthcare-технологій: чому це level-up для девелопера

Вітаю, я — Валерій Бобровський, .NET-девелопер у Glorium Technologies, сервісній компанії, яка займається повним циклом розробки software-продуктів. Одним з наших фокусів є healthcare-домен: ми розробляємо різні типи продуктів — від систем управління для госпіталів і ПЗ для перетворення даних медичних зображень у 3D-моделі — до застосунку для лікування заїкання.

На початку кар’єри я працював у геймдеві, потім були корпоративні проєкти (розробляв рішення щодо збору статистики для рітейлера Catepillar). У 2016 році прийшов у Glorium Technologies саме на healthcare-проєкт, на якому виріс як розробник і вийшов на новий професійний рівень.

У цій статті поділюся досвідом переходу у healthcare-домен та спостереженнями, чим проєкти цього типу відмінні від тих, які я робив раніше, і у чому полягають особливості розробки технологій саме для галузі охорони здоров’я. Ця стаття підготовлена у співавторстві з Dmitriy Stepanov, CTO у Glorium Technologies.

Які бувають healthcare-проєкти

Healthtech розвивається дуже стрімко і охоплює безліч різних напрямків. З власного досвіду можу зробити висновок, що найперспективнішими й такими, що мають найбільший попит серед клієнтів, є:

1. Мобільні технології та застосунки:

• дистанційний моніторинг і керування переносними девайсами;
• розробка інструментів для вивільнення часу медичного персоналу й оптимізації графіку;
• синхронізація даних при лікуванні у стаціонарі, наприклад, для контролю доступності і менеджменту лікарняних ліжок, так званих Mobile Computer Carts або Workstation.

2. Автоматизація даних і збір аналітики:

• робота над алгоритмами, які через аналіз великої кількості документації сприяють точнішим прогнозам та ефективному розподілу ресурсів;
• скорочення часу працівників лікарень і лабораторій на паперову роботу;
• автоматизована аналітика для допомоги лікарям у розробці індивідуальних планів догляду за пацієнтами.

3. Хмарні ІТ-проєкти & Data Security:

• тісний зв’язок з електронними медичними картами;
• необмежене за терміном та обсягом безпечне зберігання медичних даних та швидкий доступ до них;
• впровадження різних методів шифрування даних і способів автентифікації.

4. Електронні медичні карти (Electronic health records — EHR):

• альтернатива паперовим медичним документам: їх легко вести, оновлювати, майже неможливо втратити або підробити;
• доступ 24/7 з будь-якої точки світу для лікарів і пацієнтів, плюс вбудований пошук та фільтри з метою швидкого збору інфо для анамнезу;
• більш точні плани лікування завдяки інтеграції зі сторонніми рішеннями Apple та Google.

5. Телемедицина:

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

Про обмеження галузі

Сама собою індустрія охорони здоров’я є консервативною і чітко врегульованою. Що логічно, адже наші рішення хоч і різною мірою, але впливають на здоров’я людей. Це накладає певні обмеження на розробників програмного забезпечення. Є чіткі регуляції, що ми можемо, а чого не можемо робити, а ціна помилки зависока щодо відповідальності перед кінцевими користувачами наших розробок.

Якщо говорити про регуляторні обмеження, їх визначає Міжнародний форум регуляторів медичних пристроїв (IMDRF), який включає програмне забезпечення у категорію медичних пристроїв (Software as a Medical Device — SaMD). Це пов’язано з тим, що таке ПЗ (подібне до того, в розробці якого беру участь і я) використовуватиметься в медичних цілях — навіть у тому випадку, коли воно не є частиною меддевайсу.

Згідно з класифікацією IMDRF є 3 типи Software as a Medical Device:

• ПЗ, яке саме собою є медичним пристроєм;
• ПЗ, вбудоване в медичний пристрій;
• ПЗ, що використовується під час виробництва або обслуговування медичного пристрою.

Міжнародний форум регуляторів медичних девайсів представлений в США організацією FDA. Під головуванням FDA у 2013 році робочою групою IMDRF були узгоджені ключові визначення програмного забезпечення як медичного пристрою, структура класифікації ризиків, система управління якістю та клінічна оцінка.

У результаті було виведено класифікацію медичних пристроїв FDA, що включає 3 класи:

I — медвироби з ризиком від низького до середнього, що потребують загального контролю;
II — девайси з ризиком від помірного до високого, що потребують особливого контролю;
III — медпристрої з високим ризиком, які дуже важливі для здоров’я або підтримки життя.

Усі класи пристроїв підлягають загальному контролю, а отже, мають відповідати базовим вимогам Закону про харчові продукти, ліки та косметику (FD&C), які застосовуються до всіх медичних пристроїв класів І, ІІ та ІІІ. Класифікація залежить від можливого використання пристрою. Клас, до якого належить пристрій, визначає тип передпродажної подачі/ заявки, необхідної для допуску FDA до виходу на ринок.

Крім того, класифікація заснована на ризику, тобто ризик, який пристрій представляє для пацієнта, є основним фактором класу, що присвоюється йому. Клас I включає пристрої з найменшим ризиком, клас III — з найбільшим.

Відповідно, суворість регуляторних норм безпосередньо залежить від класу, до якого належить програмне забезпечення, яке ви розробляєте. Це своєю чергою впливає на весь цикл розробки та процес управління цим циклом, що виходить далеко за межі перевірки коду.

Про стандарти безпеки

При розробці healthcare-проєктів потрібно дотримуватися HIPAA і GDPR. Це основні стандарти, що регулюють розробку софта для галузі. Їхнє вивчення є першим кроком до переходу у healthcare для девелоперів.

Що потрібно знати розробнику про HIPAА

Це закон США про перенесення та підзвітність медичного страхування, який захищає від розголошення (без згоди чи відома пацієнтів) конфіденційність їхніх даних та медичні записи щодо їх здоров’я.

Якщо ви розробляєте продукт для healthcare, програмне забезпечення має відповідати правилам HIPAA за такими параметрами:

• авторизація користувача;
• контроль доступу до даних;
• моніторинг авторизації;
• резервне копіювання;
• план виправлення помилок;
• надзвичайний режим;
• автоматичний вихід із системи;
• шифрування та дешифрування даних

і ще низці подібних пунктів.

Перш ніж наша команда береться до роботи на healthcare-проєкті, розробники проходять навчання за HIPAA Compliance. Для цього використовується Drata Agent, де ще на етапі онбордингу співробітник має скласти тест на засвоєння вимог та правил HIPAA щодо поводження з конфіденційною інформацією.

Програма навчання включає 35 розділів, серед них:

• правила конфіденційності, безпеки та сповіщення про порушення;
• кого стосуються ці правила;
• умови співпраці з постачальниками хмарних послуг;
• угода про ділове партнерство;
• що таке PHI, або захищена медична інформація;
• що включає розширений захист даних;
• застосування багатофакторної ідентифікації;
• як співробітнику слід захищати інформацію.

Що потрібно знати розробнику про GDPR

General Data Protection Regulation — це загальний регламент захисту інформації, прийнятий Євросоюзом, як порядок обробки організаціями персональних даних користувачів.

Мова про sensitive information. Це може бути ваше ім’я, номер паспорта, ID посвідчення, логін, нікнейм, адреса електронної пошти, номер телефону, IP-адреса, дані банківської карти — тобто ті дані, за якими вас можна ідентифікувати.

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

Опишу простий приклад того, чи дотримується компанія міжнародних стандартів безпеки:

❌ якщо ви заходите до свого акаунту, вводите помилковий пароль, і система пише, що він неправильний, то це вже є порушенням правил конфіденційності, адже це означає, що система розпізнає ваш пароль;
✅ ваші дані захищені, якщо ви побачите повідомлення на кшталт того, що ваші credentials некоректні, тобто у вас недостатньо повноважень для входу в систему.

Healthcare-розробка vs. інші типи проєктів

Тепер перейду від теорії до практики і поділюся спостереженнями, як регуляції, які ми розглянули вище, впливають на розробку.

Коротко розкажу про свій проєкт, на якому я і здобув досвід healthcare-розробки. Ми з командою розвиваємо стартап, що існує вже 11 років. Його ідея в тому, щоб надавати всі медичні сервіси в межах однієї платформи. Працює як у вебверсії, так і через застосунок. Пацієнти бачать доступні часові «віконця» та бронюють зустрічі з лікарем через календар, який ми інтегрували з картами Google.

Наша система дозволяє дуже точно розрахувати, скільки потрібно часу на консультацію включно з дорогою до пацієнта і назад. Завдяки гнучкому прорахунку завантаженості у лікарів є можливість ефективніше планувати свої робочі години. Ми також максимально автоматизували рішення щодо доставки та оплати послуг і товарів — замовлення обробляються швидко і зручно.

Якщо порівнювати мою роботу на попередньому проєкті у корпоративному секторі з цим, то ми постійно стикаємося з обмеженнями через роботу з особистими даними пацієнта. Відповідно, весь софт, яким ми користуємося (Redmine, GitLab, Jira, Gmail, Amazon Web Services тощо), має відповідати низці вимог щодо безпеки даних разом із шифруванням, двофакторною ідентифікацією та ін. Для цього потрібно окремо укладати договори з провайдерами цих інструментів щодо відповідності HIPAA, оскільки за замовчуванням вони такими не є.

Варто зазначити, що одностороннього дотримання правил безпеки недостатньо. Ми на своїй стороні також маємо слідувати переліку процедур, покликаних забезпечити цілісне задоволення вимог HIPAA, таких як Breach Policy, Disastor Recovery, Risk Management, Incedent Response та інших.

Лише після укладання договору можна завантажувати у ці сервіси/ пересилати через них будь-який контент (скриншоти, текстові файли тощо), що містить персональні дані пацієнтів.

Вимоги стосуються не тільки софту. Hardware-обладнання розробника повинне також відповідати зазначеним правилам: має бути включене шифрування для диска та подвійна авторизація. Крім того, важливі наявність антивірусів, правильне налаштування screensaver і дотримання низки інших вимог щодо захисту персональної інформації.

Розробка потребує більше часу

По-перше, потрібно бути набагато уважнішим і обережнішим під час написання коду. Створюючи software-продукт, ми несемо відповідальність за здоров’я інших людей і можемо покращити їх стан, тому якість коду важлива — він має бути дійсно добре написаний. По-друге, кожна нова фіча повинна суміщатися з HIPAA та GDPR.

Тут є два сценарії:

• відповідність регуляціям залишається за клієнтом; тоді команда отримує запит, який можна одразу брати в роботу;
• за дотримання регуляцій відповідають розробники. У таких випадках необхідно додатково залучати експерта, який встановлюватиме та контролюватиме процеси, що гарантують відповідність правилам HIPAA та GDPR.

Проєкт, на якому працюю я, стосується другого випадку. Клієнт сфокусований на функціональних вимогах до рішення, решта — за нами. Тому має бути той, хто виступає внутрішнім регулятором. У нашому випадку це СТО компанії. Він контролює будь-які зміни та політики обробки медичних даних, верифікує процеси і функціонал продукту з точки зору відповідності вимогам HIPAA й GDPR.

Стек, який підходить для Healthtech

Говорячи про стек технологій для Healthtech, я рекомендую використовувати cloud-сервіси Amazon (S3, RDS) або Azure (Blob Storage, SQL Database), адже вони підтримують середовища, сумісні з HIPAA.

Що стосується власне розробки, для back-end це буде .NET або Java, для front-end — Angular або React, оскільки це продукти Microsoft, що активно розвиваються та, на мою думку, домінуватимуть у майбутньому. Для мобільної кросплатформної розробки актуальні зараз Unity 3D, Flutter, Ionic.

Ключовими підходами та інструментами, якими має володіти розробник в цьому домені, я вважаю DDD, SOLID, MVC, MVVM, Microservices, Saga, RabbitMQ, MassTransit, Mediatr. Зараз це must have, якщо ви хочете бути затребувані у професії та створювати софт на роки.

Замість висновків

Наостанок хочу поділитися, чим мені подобається працювати на healthcare-проєкті. Я бачу в цьому такі можливості:

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

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