Физически AI в здравеопазването: разработка на медицински устройства и работни процеси

Какво означава физически AI в медицината?

Помислете за лабораторен инструмент, който наблюдава носител на проба, прототип за рехабилитация, който измерва движението, или роботизиран асистент, който реагира на сензорна обратна връзка. Всеки съчетава физически наблюдения с изчисления и изход, който някой може да използва. Резултатът може да ръководи оператор, да организира задача или да допринесе за функция на устройството.

Започнете, като напишете предвидената цел на ясен език. Кой ще използва системата? В коя среда? Какво наблюдава? Какъв резултат предоставя и кой решава какво ще се случи след това? Система, която премества консумативи в болница, не трябва да наследява претенциите или предположенията на устройство, използвано в грижите за пациентите.

За медицински устройства с активиран изкуствен интелект в Съединените щати FDA описва подход, който отчита предвидената употреба и технологичните характеристики. Пазарният път на дадено устройство не може да бъде изведен от неговия процесор или от етикета „AI“. Вижте Преглед на медицинското устройство с активиран AI на FDA. Изискванията на други пазари се нуждаят от собствена оценка с отговорния производител и регулаторни специалисти.

Области на приложение, които си струва да бъдат оценени

Тези примери описват възможни инженерни проекти. Те не твърдят, че Alvexis в момента доставя одобрени медицински устройства или клинично валидирани AI алгоритми.

Полезно кратко описание на проекта разграничава сензорната подсистема, AI функцията и крайния продукт. Успешната интеграция на камерата сама по себе си не потвърждава клиничната интерпретация. Демонстрацията на работещ модел сама по себе си не установява електрическа, механична или работна годност.

Проектирайте пътя на измерване и пътя на вземане на решение заедно

Определете интерфейса между тези етапи. За сензорен прототип запишете единици, честоти на вземане на проби, параметри на калибриране и всички трансформации, приложени преди съхранение. За конвейер за изображения включете експозиция, оптика и осветление в конфигурацията. Промените в придобиването могат да променят значението на входа на алгоритъма.

Посочете как изглежда невалидно наблюдение. Прекъснат сензор, лош контакт, затъмнен изглед или сигнал извън обхват не трябва тихо да се превръщат в обикновен резултат. Включете изрично недостъпно или несигурно състояние, когато е подходящо, и решете как ще реагира потребителят или функцията надолу по веригата.

Локалната обработка може да намали количеството необработени данни, които трябва да напуснат устройството, и може да помогне на работния процес да работи по време на прекъсване на мрежата. Това не прави автоматично даден продукт личен или защитен. Дефинирайте интерфейси за запазени данни, оторизиран достъп, предаване, изтриване и поддръжка за конкретната инсталация.

Какво се променя, когато прототипът стане физически продукт?

Опаковането и монтажът са част от обхвата на разработката. Обсъдете със собственика на продукта условията за контакт, методите за почистване, монтажа, достъпа до конекторите, температурните граници и сервизните процедури. Отговорният екип трябва да определи кои електрически, механични, използваеми и регулаторни оценки се отнасят за планираното устройство.

Изградете енергийния и топлинния план около пълното работно натоварване. Придобиването, обработката, показването, комуникациите и регистрирането могат да работят заедно. Измерете устойчивото поведение в рамките на предложения корпус и по време на планирания работен цикъл. Пиковата спецификация на ускорителя не е пълен резултат от производителността на продукта.

Планирайте достъп за калибриране, производствени тестове и разследване на грешки. Персонализираният превозвач може да осигури необходимите интерфейси и напасване, но също така създава отговорности за наличност на компоненти, проверка на платката и контрол на конфигурацията. The персонализирано ръководство за носеща платка обяснява тези зависимости на проекта.

Разграничете инженерната проверка и клиничните доказателства

Инженерната проверка може да установи, че дадена подсистема измерва, обработва и комуникира според своите спецификации. Клиничната оценка пита дали крайната функция изпълнява подходящо за предвидената медицинска цел. Нито едното не трябва да се замества с другото.

The FDA, Health Canada и MHRA принципи на прозрачност подчертават ясната предназначена употреба, потребители, популации, работен процес, производителност и ограничения. Те също така обсъждат комуникирането на промените и мониторинга на ефективността. За екип по проекта това са полезни указания за уточняване на какви доказателства и потребителска информация се нуждае продуктът.

FDA's GMLP ресурс посочва принципите на IMDRF, обхващащи жизнения цикъл на медицинското устройство. Планирането на разработката трябва да включва внедрения продукт и неговите промени, вместо да приключва, когато моделът бъде обучен.

Един от начините за организиране на проекта е таблица за проследяване: за всяка заявена функция запишете необходимите входни условия, изход, метод на проверка, собственик и доказателства за приемане. Включете случаи на неуспех и човешки преглед. Замразете хардуера, софтуера, модела и конфигурацията, използвани за всяка оценка, така че резултатите да могат да бъдат интерпретирани и възпроизведени.

Практичен първи пилотен проект

1. Съгласете се относно предназначението и собствеността. Идентифицирайте производителя, предвидените потребители, клиничните партньори, когато е приложимо, и екипа, отговорен за приемането.
2. Изберете тесен въпрос. Примерите включват повторяемост на измерването, наблюдение на позицията на пробата или откриване на състоянието на оборудването при определени условия.
3. Дефинирайте препратката. Посочете процеса на измерване или преглед, използван за оценка на резултатите. Съгласете се с разрешенията за данни, преди да събирате информация, свързана с пациента.
4. Инструментирайте прототипа. Време за запис, качество на входа, състояние на обработка и конфигурация на устройството заедно с резултата.
5. Прегледайте доказателствата преди разширяване. Решете какво демонстрира прототипът, какво остава несигурно и каква допълнителна оценка е необходима за планирания продукт.

Поддържайте изрично границите на изследователска или инженерна демонстрация в споразумението пилотен проект. Разширяването от наблюдение до решение за грижа или физическо действие променя това, което трябва да се установи преди употреба.

Където Alvexis се вписва в програмата за развитие

Alvexis може да обсъди персонализиран електронен дизайн, сензорни интерфейси, вграден софтуер поддръжка и механична интеграция с медицински OEM производители, изследователски екипи и системни интегратори. Първият разговор трябва да идентифицира инженерната подсистема и доказателствата, които по-широката продуктова програма ще изисква.

За съгласувания проект трябва да бъдат установени всякакви медицински специфични пригодности, отговорности за системата за качество, клинични претенции и разрешение за пускане на пазара. Тази статия описва инженерен подход; не е твърдение, че съществуваща Alvexis платформа е медицински сертифицирана или одобрена за диагностика или лечение.

За по-широк контекст прочетете Физически AI в индустриите. За границите на движението, възприятието и вградения контрол продължете с Ръководство за AI роботика.

вградени системи и компютърно зрение в разработването на медицински устройства

Инженерното описание на медицинското устройство трябва да отделя получаването на изображение, обработката на компютърното зрение и действието, предприето от резултата. Всяка част има свои собствени интерфейси и доказателства за проверка. Определете планираната настройка, конфигурация на сензора, проверки на качеството на данните и обработка на недостъпни или ненадеждни резултати, преди да изберете вградена платформа.

Edge AI може да намали необходимостта от предаване на необработени сензорни данни, но локалната обработка сама по себе си не установява поверителност, клинично представяне или годност за медицинска употреба. Тези изисквания се отнасят за цялото устройство и предназначението му. Тази дискусия за архитектурата е рамка за разработка, а не доказателство, че компонент или алгоритъм е клинично валидиран.

Обсъдете обхвата на вградения хардуер