Santrauka

„Orthogonal“ neseniai surengė internetinį seminarą, kuriame dalyvavo „MedTech“ ekspertai iš AWS ir „Cepheid“, kad ištirtų augantį MedTech ir SaMD iššūkį:
Kai produktai tampa vis labiau susieti, net ir nedideli atnaujinimai pradeda sklisti visoje sistemoje. Tai, kas anksčiau buvo paprastas paleidimas, virsta koordinavimo problema. Komandos sulėtėja ne todėl, kad joms trūksta įgūdžių, o todėl, kad dėl sistemos sunku numatyti, ką paveiks pokytis.

Tai ne proceso problema. Tai architektūrinis.

Diskusija buvo sutelkta į tai, kas nutinka, kai tikimasi, kad glaudžiai susietos sistemos palaikys dažnus atnaujinimus, naujas integracijas ir nuolatinius pakeitimus po išleidimo. Priešingai, debesies savoji architektūra sistemas traktuoja kaip mažesnių, nepriklausomų paslaugų rinkinį, o ne kaip vieną vienetą. Komandos gali kurti, išbandyti ir įdiegti šias paslaugas atskirai, įvesdamos pakeitimus etapais ir patvirtindamos jas.

Tvirtai sujungtose sistemose kiekvienas atnaujinimas paliečia daugiau gaminio. Laikui bėgant, pakeitimus sunkiau keisti, išbandyti ir išleisti.

Tai sprendžiama naudojant debesies metodus, atskiriant sistemos dalis ir kontroliuojant, kaip įvedami pakeitimai. Užuot vertinę produktą kaip vieną vienetą, jie suskaido jį į mažesnes paslaugas su aiškiomis ribomis. Tai leidžia atnaujinti vieną dalį nedarant įtakos likusioms, suteikiant komandoms daugiau erdvės judėti nesukeliant nereikalingos rizikos.

„MedTech“ komandoms, kuriančioms prijungtus įrenginius ir SaMD, tai tampa konkurenciniu pranašumu ir netgi tik stalo statymais. Sistemos, kurias vis sunkiau pakeisti su kiekvienu leidimu, sulėtina komandų darbą, padidina koordinavimo sąnaudas ir sunkiau reaguoti į naudojimą realiame pasaulyje.

Kur sistemos pradeda lūžti

Dauguma komandų nekuria sistemų, kad žlugtų. Jie juos kuria neturėdami aiškaus plano, kaip jie pasikeis.

Ta spraga nepasirodo anksti. Jis pradeda ryškėti augant sistemai, ką grupė atkreipė dėmesį į internetinio seminaro pradžioje.

Komandoms pridedant funkcijų ir integracijų, sistemą tampa sunkiau modifikuoti. Poveikis pasireiškia keliais būdais:

• Sistemą pakeisti tampa sunkiau
• Net ir nedideliems atnaujinimams reikalingas kelių komandų derinimas
• Išleidimo ciklai išsitęsia
• Pridėjus daugiau inžinierių našumas nepadidėja ir netgi gali sulėtėti

Šis modelis dažnai pastebimas MedTech organizacijose, kuriančiose prijungtus įrenginius ir produktus, kuriuose palaikoma SaMD. Tai, kas prasideda kaip tikslinis produktas, virsta įrenginių, paslaugų ir duomenų srautų tinklu. Kai komandos laiko šias dalis glaudžiai sujungtos, maži pakeitimai pradeda paveikti daug didesnes sistemos dalis.

Tuo metu komandos praleidžia daugiau laiko valdydamos priklausomybes nei tobulindamos produktą.

„Cloud Adoption“ nėra tas pats, kas „Cloud-Native“.

Daugelis MedTech komandų kreipiasi į debesį, kai sistemas tampa sunku valdyti.

Kaip aptarta internetiniame seminare, šis žingsnis išsprendžia labai specifinę problemą.

Perėjus prie debesies nebereikia prižiūrėti infrastruktūros ir komandoms suteikiama prieiga prie labai patikimų, keičiamo dydžio paslaugų. Debesų paslaugų teikėjai veikia tokiu lygmeniu, kuriam dauguma organizacijų negali prilygti. Pavyzdžiui, standartinės saugojimo paslaugos automatiškai atkartoja duomenis keliuose duomenų centruose.

Tai leidžia inžinieriams sutelkti dėmesį į sritį, kurioje jie kuria vertę, nesvarbu, ar tai įrenginio veikimas, klinikinės darbo eigos ar SaMD funkcijos.

Tačiau glaudžiai susietos sistemos perkėlimas į debesį nesumažina koordinavimo, reikalingo pakeitimams atlikti.

Jei komandos išlaikys tokią architektūrą, sistema debesyje elgsis taip pat, kaip ir vietoje. Pakeitimai vis dar turi įtakos didelėms sistemos dalims. Išleidimams vis dar reikia derinti komandas.

Debesų savoji architektūra šią problemą sprendžia tiesiogiai. Sistema suskaidoma į mažesnes paslaugas su aiškiomis sąsajomis. Komandos gali atnaujinti šias paslaugas savarankiškai, todėl sumažėja kiekvieno pakeitimo apimtis ir lengviau tvarkomi leidimai.

Skaitmeninės ekosistemos padidina vertę ir padidina sudėtingumą

Sistemoms tobulėjant, jos retai būna viename įrenginyje.

Viso internetinio seminaro metu grupė grįžo prie klausimo, kaip greitai produktai plečiasi į platesnes ekosistemas.

Dauguma MedTech produktų dabar veikia skaitmeninėse ekosistemose, apimančiose mobiliąsias programas, debesies paslaugas, trečiųjų šalių sistemų integracijas ir nuolatinį keitimąsi duomenimis. Daugelis šių ekosistemų palaiko SaMD funkcijas, kurios priklauso nuo nuolatinio duomenų apdorojimo, algoritmų atnaujinimų ir gydytojų pateiktų įžvalgų.

Tai sukuria tikrą vertę. Tai taip pat suteikia sudėtingumo.

Priklausomybės auga. Sistemos sąveikauja taip, kaip komandos negali visiškai numatyti. Kai kurie komponentai, pvz., mobiliosios platformos ar trečiųjų šalių paslaugos, vystosi ne jūs.

Šiai aplinkai plečiantis, architektūra tampa svarbesnė.

Sistemoms, sukurtoms kaip griežtai kontroliuojami įrenginiai, sunku neatsilikti. Modulinės sistemos, sukurtos atsižvelgiant į pokyčius, efektyviau valdo šią sąveiką.

Projektavimas nuolatiniams pokyčiams

Kai sistemos veikia tokioje aplinkoje, komandos negali pokyčių traktuoti kaip išimties.

Tradiciniai metodai bando apriboti pokyčius, kad sumažintų riziką. Tai veikia, kai sistemos išlieka stabilios ir izoliuotos. Jis sugenda, kai sistemos palaiko prijungtus įrenginius ir besivystančias SaMD funkcijas.

Komandoms reikia kitokio požiūrio.

Debesyje naudojamos sistemos daro prielaidą, kad pokyčiai įvyks, ir į tai atsižvelgiama savo projekte.

Komandos tai atlieka taip:

• Komponentų izoliavimas, kad gedimai būtų apsaugoti
• Atnaujinimų išleidimas etapais
• Pakeitimų patvirtinimas nuolat, o ne laukimas iki pabaigos

Didelio masto platformos vadovaujasi šiuo modeliu. Jie prasideda mažoje aplinkoje, palaipsniui plečiasi ir kiekviename etape apima atšaukimo mechanizmus.

Šis metodas leidžia komandoms išleisti naujinimus nekeliant pavojaus visai sistemai.

Rizikos permąstymas prijungtoje sistemoje

Kai komandos kuria sistemas, kurios palaiko nuolatinius pokyčius, turi pasikeisti ir jų požiūris į riziką.

MedTech organizacijos tradiciškai bandė sumažinti riziką kontroliuodamos sistemos ribas ir ribodamos priklausomybes. Tai tampa sunkiau, nes sistemos prisijungia prie išorinių paslaugų ir veikia realioje aplinkoje, ypač kai palaiko SaMD funkcijas.

Keičiasi išorinės paslaugos. Platformų atnaujinimas. Vartotojai elgiasi taip, kaip komandos visiškai nenumato.

Bandymas pašalinti tą neapibrėžtumą lėtina vystymąsi ir veda į standžias sistemas. Vietoj to, komandos sutelkia dėmesį į problemų nustatymą anksti, poveikio ribojimą ir greitą atsigavimą. Tai galite pamatyti, kaip komandos išleidžia ir valdo savo sistemas. Jie naudoja tokius metodus kaip laipsniškas diegimas, automatizuotas testavimas ir tvirti išleidimo vamzdynai, kad galėtų valdyti pokyčius.

Diskusija taip pat ginčijo idėją, kad MedTech veikia išskirtinai didelėje rizikoje. Kitos pramonės šakos susiduria su panašiomis akcijomis. Didelio masto prekybos sistemos gedimas (pvz., nustojus veikti Amazon.com atsiskaitymo funkcijai) gali turėti tiesioginių ir rimtų pasekmių, net jei negresia pavojus žmonių gyvybėms.

Skirtumas yra tas, kaip šios organizacijos reaguoja. Jie kuria sistemas, kurios gerai valdo pokyčius, o ne bando jų išvengti.

Valdymas per architektūrą, o ne visapusiška priežiūra

Jei komandos negali užkirsti kelio kiekvienai problemai, kyla klausimas, kaip jos išlaiko kontrolę sistemoms tobulėjant. Sistemoms tampant dinamiškesnėmis, tradiciniai valdymo modeliai pradeda nykti.

Grupė pabrėžė, kaip tai tampa ypač aišku debesų aplinkoje.

Pagrindinės paslaugos nuolat keičiasi. Komandos negali sekti ir patvirtinti kiekvieno pakeitimo rankiniu būdu, ypač kai jų sistemos priklauso nuo išorinių komponentų.

Valdymas kyla iš to, kaip sistema suprojektuota.

Komandos apibrėžia aiškias ribas tarp komponentų ir apriboja, kaip pokyčiai plinta sistemoje.

Jie taip pat nusprendžia, kur reikia peržiūrėti, o kur pakanka automatizavimo.

Didelės rizikos pakeitimai kruopščiai peržiūrimi. Įprasti atnaujinimai perduodami automatizuotais vamzdynais.

Tai leidžia komandoms išlaikyti kontrolę nesulėtinant vystymosi. Sistema sugeria didžiąją dalį sudėtingumo, o ne perkelia ją į komandą, kuri ją valdo.

Stebėjimas kaip pagrindinė galimybė

Kai komandos nustoja bandyti valdyti kiekvieną sistemos dalį, joms reikia aiškiai matyti, kaip ji elgiasi.

Tai apima sistemos veikimo stebėjimą, anomalijų aptikimą ir elgesio pokyčių nustatymą. Tai taip pat reiškia, kad reikia suprasti, kaip vartotojai sąveikauja su produktu realiomis sąlygomis.

Komandos dažnai daugiausiai mokosi iš to, kaip sistema elgiasi už kontroliuojamos aplinkos ribų. Vidinis bandymas niekaip negali užfiksuoti kiekvieno scenarijaus.

Tai tampa dar svarbiau tokiose aplinkose kaip Bring Your Own Device (BYOD), kur vartotojai pasiekia sistemą savo telefonuose, planšetiniuose kompiuteriuose ar kompiuteriuose, kurių kiekviena turi skirtingą operacinę sistemą, konfigūraciją ir atnaujinimo ciklus.

Be matomumo komandos problemas atranda pavėluotai. Su juo jie gali anksti reaguoti ir prisitaikyti, kol problemos neišplis.

Architektūra ir reguliavimo suderinimas

Sistemoms vis labiau paskirstant, komandos turi aiškiai apibrėžti, kokia medicinos prietaiso dalis yra ir kas yra už jos ribų.

Jie turi susieti priklausomybes ir parodyti, kaip išoriniai komponentai sąveikauja su sistema, ypač SaMD komponentams, kuriems taikoma teisinė priežiūra.

Be to aiškumo tampa sunku atsakyti į pagrindinius klausimus atliekant auditą ar pateikimą.

• Kur yra sistemos riba?
• Kas atsitinka, kai pasikeičia išorinė paslauga?
• Kaip kontroliuojama rizika?

Struktūrizuotas, rizika pagrįstas požiūris padeda komandoms tiesiogiai atsakyti į šiuos klausimus. Aiškios ribos leidžia lengviau paaiškinti, kaip veikia sistema, kaip komandos nustato problemas ir kaip reaguoja, kai kas nors nepavyksta.

Komandų derinimas pagal tai, kaip veikia sistemos

Vien technologija neišsprendžia šių sistemų kūrimo, valdymo ir paaiškinimo iššūkių.

Komandos turi suderinti inžineriją, kokybę ir reglamentavimą pagal tai, kaip sistema iš tikrųjų veikia.

Kai komandos sutelkia dėmesį tik į atitikties demonstravimą, atsiranda trintis. Atsiliepimai lėtai progresuoja. Darbas juda tarp funkcijų, o ne sprendžiamas komandoje.

Šis atjungimas tampa labiau matomas, kai sistemos auga ir palaiko prijungtus įrenginius bei SaMD funkcijas.

Kai komandos sutelkia dėmesį į aukštos kokybės sistemų kūrimą, atitiktis išplaukia iš jų jau atliekamo darbo.

Tam reikia pakeisti savininką. Inžinierių komandos prisiima atsakomybę už tai, kaip sistema veikia realiai naudojant. Kokybės ir reguliavimo komandos apibrėžia apribojimus, riziką ir lūkesčius, kurie formuoja tuos sprendimus.

Komandos dirba efektyviau, kai priima sprendimus kartu, o ne paskirsto darbą tarp funkcijų.

Kaip gali padėti stačiakampis

1. Kurkite architektūrą, kuri palaiko nuolatinius pokyčius

Padedame komandoms pereiti nuo glaudžiai susietų sistemų prie modulinių, debesies savųjų architektūrų, kurios sumažina pokyčių poveikį ir leidžia sistemoms vystytis nesulėtinant plėtros.

2. Į plėtrą įtraukite kokybę ir reguliavimą

Mes integruojame projektavimo kontrolę, rizikos valdymą ir įrodymų generavimą tiesiai į inžinerines darbo eigas, kad atitiktis būtų palaikoma plėtra, o ne vilkinama.

3. Padidinkite greitį nedidindami rizikos

Naudodami automatizuotą testavimą, laipsniško diegimo strategijas ir patikimą CI / CD praktiką, padedame komandoms anksti aptikti problemas ir greitai reaguoti į sistemos pakeitimus.

4. Padidinkite matomumą visose sudėtingose ​​sistemose

Diegiame stebimumo ir produktų analizės praktiką, kuri suteikia realiu laiku sistemos elgsenos ir naudotojo sąveikos įžvalgą, leidžiančią greičiau nustatyti diagnostiką ir priimti geresnius sprendimus.

5. Suderinkite inžinerines, kokybės ir produktų komandas

Dirbame įvairiose funkcijose, kad sukurtume bendrus psichikos modelius, sumažintume trintį ir užtikrintume, kad komandos galėtų priimti sprendimus užtikrintai laikantis aiškių sistemos ribų.