Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Особливості розробки 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-рішення.
  • Врегульованість галузі, на перший погляд, може відлякати когось, але мій досвід показує, що це, навпаки, є сильною стороною. За час роботи я відчутно покращив навички писати якісний продакшен-код.
  • Враховуючи комплексність і складність завдань, на проєкті я отримую можливість працювати із сучасними технологіями та системами, зокрема мікросервісною інфраструктурою, та розвиватись у предметно-орієнтованому проєктуванні.

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

👍ПодобаєтьсяСподобалось20
До обраногоВ обраному7
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
я рекомендую використовувати cloud-сервіси Amazon (S3, RDS) або Azure (Blob Storage, SQL Database), адже вони підтримують середовища, сумісні з HIPAA.

це якась дічь, cloud-сервіси це платформа, «будівельні блоки», воно по дефолту (магічно) НЕ зробить ваш код HIPAA сумісним.
автор мабуть має на увазі що ці клауд провайдери мають необхідні фічі щоб будувати більшменьш захищені рішення? такі як encryption at rest, key rotation, secure connection...
то це теж херня — багато хто крім AWS та Azure все це має, той же Google чи OCI.

В частині, про порівняння з минулим проектом...

Для цього потрібно окремо укладати договори з провайдерами цих інструментів

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

Ну і виходить що причина чому це «level-up» це тому що специфіка предметної області примушує дотримуватись певної якості продукту і на цьому окремо взятому проекті технології новіші ніж на попередніх гівно-проектах, яких бачив автор. я звичайно радий за автора, але узагальнювати що всі healthcare проекти кращі (нехай навіть більшість) ну це якесь дуже брутальне натягування сови на глобус.

healthcare-технологій

це просто смішно коли людина пише систему документо-обліку і scheduler під медиків і називає це healthcare-технології, які тут нахер healthcare-технології???
healthcare-технології це системи керування MRI, іншою мед технікою, ШІ для аналізу знімків чи результатів аналізів...
ви якщо будете робити форму для резюме для HR в SpaceX то будете писати що займаєтесь «космічними технологіями»?

це продукти Microsoft, що активно розвиваються та, на мою думку, домінуватимуть у майбутньому

ха-ха

1. Про HIPAA та обов’язковість або необов’язковість тих вимог, які вона накладає на софт, можно почитати отут — www.hhs.gov/...​urity/guidance/index.html, дивіться pdf у секції Security Rule Educational Paper Series. Список наведений у статті розбирається отут — www.hhs.gov/...​afeguards.pdf?language=es

2. Не всі вимоги HIPAA продукт, частиною якого є якийсь софт, зобов’язаний виконувати. У деяких випадках те, що сприймається як жорсткі вимоги, може виявитися addressable implementation specification, а не required implementation specification. Проте це лиш моє розуміння того, шо я читав на цю тему. На жаль (або на щастя), я не маю досвіду у тому, які правозастосовні практики існують навколо HIPAA

спостереженнями, чим проєкти цього типу відмінні

Раптово було, що навіть круті лікарі в компʼютерах часто не розуміються зовсім, тикаються як сліпі кошенята, плутаються в двох кнопках і жмакають куди попало, прям як середньостатистичні юзери звичайних проектів

Перш ніж наша команда береться до роботи на healthcare-проєкті, розробники проходять навчання

Працював колись на одному проекті в healthcare, заради нього аутстаф компанія отримувала всякі сертифікації і дозволи щоб мати змогу співпрацювати з замовником

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

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

Телемедицина

На цьому ж проекті я побачив що у деяких американських клініках просто жахливий інтернет, навіть ADSL від Укртелекома був би для них даром богів, відповідно телемедицина у них буває так собі

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

Тут я не побачив нічого близького до своєї першої роботи, фактично як adtech тільки для медичних журналів. Найчастішою critical issue було що в опублікованих статтях замінювали діючого на той момент президента Donald Trumpʼа на Circus Clown, Supreme Shitlord і інші варіації :D

Саме цікаве не розкрито: чи є в Нealthcare принцип «платять мало, зате робота складна»? Бо наприклад, у ембеддеді залежність чітко зворотня, чим ближче до заліза, жорсткіший ріалтайм і баги можуть спричинити більшу матеріальну шкоду на столі у девелопера, тим гірше воно оплачується і нервовіша постановка процесів.

Платять рівно стільки — за скільки Ви себе продасте, є охочі працювати за 3 копійки їх візьмуть

за скільки Ви себе продасте

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

частково так, але від Вас залежить чи по низу вилки будете отримувати чи по верху

Я встиг попрацювати і там і сям — і от що мене приголомшило у Нealthcare:
Нealthcare воно мені дещо нагадує СРСР: «без бумажки — ты букашка», тобто на кожну дію потрібен дозвол, довідка, підпис — усе таке. Через це якщо погодили якийсь версії софта: IDE, тулив, бібліотек — то погодити нові це бюрократична тягонина. Через це іноді краще написати свого велосипеда, чи затулити милицю, а ніж обновити версію чи застосувати стороннє рішення.
Здавалося б — це убезпечує безпеку, адже кожна версія проходить перевірку FDA і не впаде через якийсь новий, ще не перевірений, сторонній компонент.
Але! Біда в тому, що проблеми у бібліотеках знаходять постійно. І багато з них такі, які дозволяють зловмисникам робити щось погане. Отже як тільки проблему знайшли, виправили у новій версії і оголосили про це публічно — погані хлопці знають як ломати тих, хто не обновився!
Саме через це у не-Нealthcare компаніях (на кшталт MS) перевірка вразливостей уходить до білда! Тобто якщо у коді використовується Nuget чи NPM пакет з відомою вразливістю — білд не пройде.
Ось такий парадокс з безпекою: якщо беремо найсвіжіші версії — то бережемося від відомих вразливостей, але завжди є ризик несумісності чи ще невідомих багів. Якщо беремо старі, перевірені FDA версії — то ризикуємо відкрити шлях злодіям.
Ти більше що зараз для підбору відомих вразливостей не потрібен хакер — ИИ тули переберуть усе, що, знають — і якщо щось «вистрелить» — то всунуть трояна чи якийсь інший засіб злому.

Проблема з бiблiотеками вирiшується створенням лiсапетiв. В одному великому продуктi був власний persistence layer, доморобний. При переходi на 5-ту Джаву все почало дико гальмувати, вiдкотилися на 4-ту. Тут скiнчився перiод пiдтримки старого Йожика (апп контейнер WebLogic), який потребував нову 5-ту Джаву, почався ахтунг, нас стали бити ногами, потiм скорочувати.
Останню таску, яку я отримав — це переробити вкладеннiсть тестiв (аналiзiв), щоб система могла приймати ордери з HIS. Добре, що я перед цим кiлька рокiв попрацював в iншому мед проектi, i кiлька уточнюючих питать поховали цю таску на рiвнi реквайрментiв, тому що наша система не пiдтримувала те, що могли робити американськi.
Це було бiльше 10 рокiв тому.

ІТ-проекти для HealthCare дуже круто, особливо для сільської місцевості, де немає ні світла, ні інтернету (ні медиків, які пішли в кодери ;) ). Звичайно ж, це вина Федорова, що до цих пір не маємо 5G (а відповідно і телемедицини та роботів, що могли б замінити людей в екстремальних умовах )

Ви дивитесь на проблему лише з точки зору сервісної компанії, хелскер це коли ти балансуєш між регуляціями на медичні дані, збиранням дуже багато рікваєрметів від юзерів та дизайном цього всього, підписуєш дофіга різних угод, риєшся в дивних тулах, щоб закинути дані в бакет та даблчекаєш все це ще раз, щоб в компанії ліцензію не забрали і ті лижі хоч якось поїхали. Імплементація тут вже не складна справа. Хоча коли твій AWS аккаунт не під’єднаний до інтернету, то спроба додати необхідний пекедж стає челенджем. Попрацювати ззакордону? Ріквестай багато аппрувів та спеціальні доступи до тулів. Левелап тут якщо перейти в схожу компанію на схожу роль, то такий досвід цінується і дуже добре оплачується або якщо переходити в менеджмент.

Перечитал дважды — не нашел где левелап.
Уточните?

Разочарую — для хетлека тоже нужны лендинги и круды.

Разницы между крудами — ровно ноль. Разница — в хранении и аналитике таких данных. То есть если передан кривой номер, то оно вернет ошибку вместо сохранения. А если в базе поле удалено, то оно сделает запрос на резервную базу.
Нууу. Такой себе левелап. Скорее практика обработки ошибок.

Такой себе левелап. Скорее практика обработки ошибок.

Ну, справді, всього лише дрібна відмінність між програмою, що працює і програмою, що не працює :)

Не совсем. Я про обработку ошибок в случает отказа основного хранилища.

Разница — в хранении и аналитике таких данных.

Це ***єнно велика різниця, яка змушує приймати багато інших технічних рішень. Саме для того ж зберігання і аналітики.

Перечитал дважды — не нашел где левелап.

Level Up там горизонтальний.

Інший рівень технічної відповідальності, вимог. Нижче вже те саме написали

Я сделяль
const hl7 = require('hl7'); const json2hl7 = json => {     return hl7.JSON.stringify(json); }; const hl7ToJson = hl7 => {     return hl7.JSON.parse(hl7); }; module.exports = {     json2hl7,     hl7ToJson }

Підписатись на коментарі