„MedTech“ įmonės nebekuria produktų su tvarkinga riba aplink vieną įrenginį. Jie kuria ekosistemas.

Prijungtas sveikatos produktas gali apimti programą mobiliesiems, debesies paslaugas, pacientui skirtas funkcijas, gydytojų prietaisų skydelius, duomenų perdavimo kanalus, analizę, DI įgalintas funkcijas ir būsimas integracijas su EHR arba partnerių platformomis. Dozavimo algoritmas, pacientų portalas ir debesijos paslauga gali būti glaudžiai kartu toje pačioje ekosistemoje, tačiau ne visi jie kelia tą pačią riziką pacientui ar reguliavimo naštą.

Bėdos prasideda tada, kai įmonės su jais elgiasi taip, tarsi elgiasi.

Iš pradžių toks požiūris gali atrodyti konservatyvus. Praktiškai tai dažnai sulėtina komandų darbą, nesuteikdama reikšmingos saugos ar kokybės. Mažos rizikos funkcijos įtraukiamos į labai griežtus procesus. Dokumentacija plečiasi. Peržiūros ciklai išsitęsia. Komandos praleidžia daugiau laiko įrodinėdami atitiktį nei tobulindamos produktą.

Tai yra problema, kurią „Orthogonal“ nagrinės būsimame internetiniame seminare „Ekosistemų projektavimo valdymas: greitesnis judėjimas su tinkamu atitikties lygiu“, trečiadienį, 2026 m. liepos 22 d., 11:00 val. CT.

Internetinio seminaro centre yra klausimas, su kuriuo jau kovoja daugelis SaMD, prijungtų įrenginių ir skaitmeninės sveikatos komandos:

Kaip pritaikyti tinkamą valdymo lygį tinkamoms sistemos dalims, nesulėtinant viso kito?

Tai prasideda nuo ribos

Pasak Megan Graham, „Orthogonal“ reguliavimo ir kokybės viceprezidentės, pirmasis žingsnis yra suprasti, ką iš tikrųjų daro kiekviena programinės įrangos dalis.

Reguliavimo įsipareigojimai yra susieti su funkcija ir rizika. Programinės įrangos funkcija, analizuojanti klinikinius duomenis ir teikianti diagnozę arba gydymo rekomendaciją, nebus vertinama taip pat, kaip į funkciją, kuri renka pagalbinę informaciją arba rodo nekritinius duomenis.

Šis skirtumas turėtų pasirodyti architektūroje.

Kai komandos aiškiai atskiria didesnės rizikos medicinos prietaiso funkcijas nuo mažesnės rizikos ar ne prietaiso funkcijų, jos dažnai gali sumažinti nereikalingą tolesnio proceso naštą. Mažesnės rizikos komponento pakeitimas gali nereikalauti tokio pat reguliavimo darbo kaip pagrindinės klinikinės funkcijos pakeitimas.

Tai nėra nuoroda į atitiktį. Tai būdas suderinti architektūrą su tuo, kaip gaminyje iš tikrųjų pasireiškia rizika.

Megan aiškiai pasakė, kad kai medicinos prietaiso funkcionalumas egzistuoja ekosistemoje, gamintojas vis tiek turi suprasti komponentų kokybę, priklausomybes ir diegimo aplinką. Komanda niekada nėra visiškai „nuo kablio“. Tačiau kai ribos yra apgalvotos, atitikties strategija tampa tikslesnė.

Daugiau dokumentų ne visada yra griežtesnis

Kai komandos apibrėžia šias ribas, kitas iššūkis yra tinkamo griežtumo taikymas.

Daugelis kompanijų projektavimo kontrolę vis dar laiko dokumentacija. Megan žvilgsnis yra daug aštresnis:

„Niekada nebuvo kalbama apie dokumentus. Dokumentai yra įrodymai.”

Projektavimo kontrolė turėtų atspindėti paties projektavimo darbo kokybę: architektūrą, rizikos mąstymą, patikros strategiją, patvirtinimo metodą, saugos pagrindą ir sprendimus, kuriuos komandos priima per visą kūrimą.

Kai komandos painioja dokumentaciją su griežtumu, jos gali pridėti procesą nesuteikdamos pridėtinės vertės.

Megan pasidalino pavyzdžiu, kai organizacija atlieka labai formalų techninės peržiūros procesą. Atliekant peržiūras reikėjo daug dokumentų ir mažiausiai dviejų savaičių peržiūros laikotarpio. Laikui bėgant šiose apžvalgose nebuvo rasta reikšmingų problemų, nes komanda jau buvo patobulinusi ankstesnes praktikas, kurios anksčiau pastebėjo defektus.

Šis procesas kažkada turėjo tikslą. Vėliau tai tapo papildomu darbu.

Esmė nėra ta, kad procesas visur būtų lengvesnis. Tai yra tam, kad procesas užsitarnautų savo vietą. Jei kontrolė neberanda rizikos, komanda turėtų tai žinoti ir prisitaikyti.

Sukurkite produktą, kurį kuriate toliau

Šis rizika pagrįstas požiūris tampa dar svarbesnis, kai komandos galvoja ne tik apie pirmąjį leidimą.

Įmonė gali pradėti nuo produkto, kuriame yra pagrindinė fiziologinė metrika. Vėliau ta pati metrika gali palaikyti išplėstines indikacijas, klinikinių sprendimų palaikymą arba pažangesnę analizę. Jei komanda kuria tik pirmąjį leidimą, vėliau gali susidaryti išvengiama trintis.

Megan rekomenduoja galvoti apie produktą kaip apie platesnės platformos ar portfelio dalį. Tai reiškia, kad reikia užduoti tokius klausimus:

• Kokios funkcijos laikui bėgant gali tapti kliniškai reikšmingesnės?
• Kokius duomenis turime rinkti dabar, kad pagrįstų būsimus įrodymus?
• Kurie komponentai turėtų būti moduliniai, kad būtų palaikomi būsimi produktai, integracijos ar jurisdikcijos?
• Kurios MVP dalys yra sąmoningai laikinos, o kurias reikia keisti?

MVP ne visada turi būti visiškai keičiamas. Tačiau komandos turėtų būti sąžiningos apie tai, ką jos kuria, ką vėliau gali pakeisti ir kaip šiandieninė reguliavimo strategija palaiko rytojaus planą.

Gerai atlikta dizaino valdymas padeda komandoms šiandien priimti sprendimus dėl gaminio, kuris nesukelia reguliavimo trukdžių po šešių mėnesių.

AI gali padėti, bet tik tuo atveju, jei pagrindas yra tvirtas

Tas pats principas taikomas dirbtinio intelekto palaikomam produktų kūrimui ir priežiūrai.

Megan pažymi, kad dirbtinis intelektas gali padėti komandoms valdyti didėjantį prijungtų medicinos prietaisų sudėtingumą, palaikydamas reikalavimų, rizikos, architektūros, patvirtinimo įrodymų ir produktų pakeitimų poveikio analizę. Pavyzdžiui, kai komanda atnaujina debesies paslaugą, pakeičia programinės įrangos komponentą arba prideda naują funkciją, dirbtinio intelekto palaikomi įrankiai gali padėti nustatyti, kurie reikalavimai, pavojai, bandymo atvejai, priklausomybės ir dokumentacija gali būti paveikti. Dėl to priežiūros darbai gali būti lengviau valdomi, ypač kai produktai vystomi įvairiose laidose, jurisdikcijose ir prijungtuose komponentuose.

Tačiau AI nepakeičia dizaino ar reguliavimo sprendimų.

Tinkami apsauginiai turėklai vis tiek svarbūs. Komandos turi patvirtinti, kad dirbtinio intelekto įrankiai sukuria reikiamus rezultatus ir nesukelia papildomos kokybės ar saugos rizikos.

Patyrę specialistai turėtų nuolat peržiūrėti AI palaikomas rekomendacijas, kol komandos nepasikliauja jomis priimdamos sprendimus, turinčius įtakos produktui arba jo atitikties strategijai.

AI tampa naudingesnis, kai produktas jau turi tvirtą architektūrą ir atsekamumą. Be šio pagrindo poveikio analizė tampa sunkesnė, nepaisant įrankio.

Prisijunkite prie webinaro

Jei jūsų organizacija kuria prijungtą įrenginį, SaMD produktą, programą mobiliesiems, platformą, palaikytą debesyje, arba dirbtinio intelekto palaikomą medicinos prietaisų ekosistemą, šiame internetiniame seminare bus praktiškai pažvelgta į tai, kaip greičiau pasiekti tinkamo atitikties lygio.

Sužinosite, kaip apibrėžti medicinos prietaisų ribas, griežtinti pagal riziką, sumažinti nereikalingą dokumentacijos naštą, palaikyti būsimą gaminio evoliuciją ir taikyti projektavimo valdiklius gaminant gaminį, o ne tik kaip jis dokumentuojamas.

Prisijunkite prie Orthogonal 2026 m. liepos 22 d., trečiadienis, 11.00 val. CT, skirtas „Ekosistemų projektavimo valdikliai: greitesnis judėjimas su tinkamu atitikties lygiu“.

Užsiregistruokite, kad sužinotumėte, kaip MedTech komandos gali tiksliau taikyti atitiktį, todėl didelės rizikos funkcijos įgyja reikiamą griežtumą, neverčiant visos ekosistemos per tą patį procesą.