Generički medicinski uređaji i sigurnost tipova: Nevidljivi temelj globalne zdravstvene tehnologije

Zamislite medicinsku sestru u prometnoj jedinici intenzivne njege. Monitor pacijenta, proizveden od strane tvrtke u Njemačkoj, spojen je na infuzijsku pumpu japanskog proizvođača, koja zauzvrat šalje podatke centralnom sustavu za upravljanje podacima o pacijentima (PDMS) razvijenom u Sjedinjenim Državama. U teoriji, ovo je obećanje moderne, modularne zdravstvene skrbi: fleksibilan, isplativ ekosustav uređaja koji rade u harmoniji. Ali što se događa kada pumpa, programirana da izvješćuje o brzini doziranja od '10.5' mL/hr, pošalje te podatke kao niz teksta, a PDMS, očekujući čisti broj, ili se sruši ili zaokruži na cijeli broj '10'? Posljedice ovog naizgled manjeg nepodudaranja podataka mogle bi biti katastrofalne. Ovo je kritični, često zanemareni, izazov sigurnosti tipova u svijetu generičkih i interoperabilnih medicinskih uređaja.

Kako se zdravstvena tehnologija udaljava od monolitnih sustava jednog dobavljača prema međusobno povezanom Internetu medicinskih stvari (IoMT), koncepti "generičkih" uređaja i interoperabilnosti softvera postaju najvažniji. Međutim, ovaj napredak uvodi novi sloj složenosti i rizika. Same veze koje obećavaju veću učinkovitost i bolje ishode za pacijente mogu postati vektori pogreške ako se njima ne upravlja s krajnjim oprezom. U središtu ovog izazova leži sigurnost tipova—temeljni koncept iz računalne znanosti koji ima implikacije života i smrti u kliničkom okruženju. Ovaj će se post baviti sjecištem generičkih medicinskih uređaja i sigurnosti tipova, istražujući rizike, globalni regulatorni krajolik i najbolje prakse koje proizvođači, zdravstvene organizacije i kliničari moraju usvojiti kako bi izgradili sigurniju, istinski povezanu zdravstvenu budućnost.

Razumijevanje pojma "generički" u kontekstu medicinskih uređaja

Kada čujemo riječ "generički", često pomislimo na generičke farmaceutske proizvode—kemijski identičnu, ali jeftiniju alternativu lijeku s robnom markom. U svijetu medicinskih uređaja, izraz "generički" ima drugačije, nijansiranije značenje. Manje se radi o brendiranju, a više o standardizaciji, modularnosti i funkcionalnoj ekvivalenciji.

Izvan robnih marki: Što definira "generičku" komponentu?

Generički medicinski uređaj ili komponenta je ona koja je dizajnirana za obavljanje standardne funkcije i sučelje s drugim sustavima, bez obzira na izvornog proizvođača. Radi se o razbijanju složenih medicinskih sustava na izmjenjive dijelove. Razmotrite ove primjere:

• Standardizirani konektori: Luer-Lok konektor je klasičan primjer. Omogućuje sigurno spajanje šprica, IV linija i katetera od bezbroj različitih proizvođača, stvarajući univerzalni standard.
• Modularni monitori pacijenata: Moderni sustav za praćenje pacijenata može imati središnju jedinicu zaslona s utorima za različite module (EKG, SpO2, NIBP, temperatura). Bolnica može kupiti SpO2 modul od dobavljača A i EKG modul od dobavljača B, priključujući ih na središnju stanicu od dobavljača C, pod pretpostavkom da se svi pridržavaju istih fizičkih standarda i standarda za razmjenu podataka.
• Softverske komponente: Generički algoritam za otkrivanje aritmije u EKG valnom obliku mogao bi se licencirati i integrirati u EKG uređaje različitih dobavljača.
• Komunikacijski protokoli: Uređaji koji "govore" standardiziranim jezicima kao što su HL7 (Health Level Seven) ili FHIR (Fast Healthcare Interoperability Resources) mogu se smatrati generičkima u svojoj sposobnosti komuniciranja, što im omogućuje da se integriraju u širi informacijski sustav bolnice.

Pokretačka snaga ovog trenda je potraga za fleksibilnijim, konkurentnijim i inovativnijim zdravstvenim ekosustavom. Bolnice žele izbjeći zaključavanje dobavljača, omogućujući im da odaberu uređaj najbolje u klasi za svaku specifičnu potrebu, umjesto da budu prisiljeni kupovati sve od jednog, vlasničkog dobavljača.

Uspon interoperabilnosti i Interneta medicinskih stvari (IoMT)

Ovaj prijelaz prema generičkim komponentama je temeljno načelo Interneta medicinskih stvari (IoMT). IoMT zamišlja mrežu međusobno povezanih uređaja—od nosivih senzora i pametnih infuzijskih pumpi do ventilatora i kirurških robota—koji kontinuirano prikupljaju, dijele i analiziraju podatke kako bi pružili holistički pogled na zdravlje pacijenta. Prednosti su duboke:

• Poboljšano praćenje pacijenata: Podaci u stvarnom vremenu iz više izvora mogu se agregirati kako bi se ranije otkrilo pogoršanje stanja pacijenta.
• Poboljšani klinički tijekovi rada: Automatizacija može smanjiti ručni unos podataka, minimizirajući ljudske pogreške i oslobađajući kliničko osoblje.
• Odluke temeljene na podacima: Analiza podataka velikih razmjera može dovesti do boljih protokola liječenja i prediktivne dijagnostike.
• Troškovna učinkovitost: Konkurencija među proizvođačima komponenti i mogućnost nadogradnje dijelova sustava umjesto cijele stvari može dovesti do značajnih ušteda troškova.

Međutim, ova povezanost je mač s dvije oštrice. Svaka točka povezivanja, svaka razmjena podataka između uređaja različitih proizvođača, potencijalna je točka kvara. Pretpostavka da će dva uređaja 'jednostavno raditi' zajedno jer dijele zajednički utikač ili protokol opasno je pojednostavljenje. Ovdje se apstraktni svijet softverskog inženjerstva i sigurnosti tipova sudara s fizičkom stvarnošću skrbi za pacijente.

Sigurnost tipova: Koncept računalne znanosti s posljedicama života ili smrti

Da bismo istinski shvatili rizike u našem međusobno povezanom medicinskom svijetu, moramo razumjeti temeljno načelo razvoja softvera: sigurnost tipova. Za mnoge zdravstvene djelatnike ovo se može činiti kao ezoterični IT izraz, ali njegove su implikacije nevjerojatno praktične i izravno povezane sa sigurnošću pacijenata.

Što je sigurnost tipova? Početnica za zdravstvene djelatnike

U najjednostavnijem smislu, sigurnost tipova je sposobnost programskog jezika ili sustava da spriječi pogreške koje proizlaze iz miješanja nekompatibilnih tipova podataka. 'Tip podataka' je samo način klasificiranja informacija. Uobičajeni primjeri uključuju:

• Cijeli broj: Cijeli broj (npr. 10, -5, 150).
• Broj s pomičnim zarezom (Float): Broj s decimalnim zarezom (npr. 37.5, 98.6, 0.5).
• Niz: Niz tekstualnih znakova (npr. "Ime pacijenta", "Primijeniti lijek", "10.5 mg").
• Boolean: Vrijednost koja može biti samo istinita ili lažna.

Zamislite to kao jedinice u medicini. Ne možete zbrojiti 5 miligrama i 10 litara i dobiti smislen rezultat. Jedinice (tipovi) su nekompatibilne. U softveru, pokušaj izvođenja matematičke operacije na nizu teksta ili unos decimalne vrijednosti u funkciju koja prihvaća samo cijele brojeve može uzrokovati nepredvidivo ponašanje. Sustav siguran za tipove dizajniran je da uhvati te nepodudarnosti i spriječi da uzrokuju štetu.

Kritični medicinski primjer: Infuzijska pumpa mora isporučiti dozu od 12.5 mg/hr. Softverska funkcija koja upravlja motorom očekuje ovu vrijednost kao broj s pomičnim zarezom. Povezani elektronički zdravstveni karton (EHR), zbog pogreške lokalizacije (npr. korištenje zareza kao decimalnog separatora u Europi), šalje vrijednost kao tekstualni niz "12,5".

• U sustavu koji nije siguran za tipove: Sustav bi mogao pokušati 'prisiliti' niz u broj. Mogao bi vidjeti zarez i skratiti niz, tumačeći ga kao cijeli broj '12'. Pacijent prima dozu od 12 mg/hr umjesto 12.5. U drugim scenarijima, to bi moglo u potpunosti srušiti softver pumpe, zaustavljajući infuziju bez alarma.
• U sustavu sigurnom za tipove: Sustav bi odmah prepoznao da niz ("12,5") nije isti tip kao očekivani broj s pomičnim zarezom. Odbacio bi nevažeće podatke i pokrenuo specifičan alarm visokog prioriteta, upozoravajući kliničara na pogrešku nepodudaranja podataka prije nego što se dogodi bilo kakva šteta.

Statičko naspram dinamičkog tipkanja: Prevencija naspram otkrivanja

Bez ulaska u previše tehničkih detalja, korisno je znati da postoje dva glavna pristupa osiguravanju sigurnosti tipova:

1. Statičko tipkanje: Provjere tipova izvode se tijekom faze razvoja (kompilacije), prije nego što se softver pokrene. Ovo je kao da ljekarnik provjerava ispravnost recepta prije nego što se uopće ispuni. To je preventivni pristup i općenito se smatra sigurnijim za sustave od kritične važnosti kao što je firmver medicinskih uređaja jer eliminira cijele klase pogrešaka od samog početka. Jezici kao što su C++, Rust i Ada statički su tipkani.
2. Dinamičko tipkanje: Provjere tipova izvode se dok se program izvodi (u vrijeme izvođenja). Ovo je kao da medicinska sestra dvaput provjerava lijek i dozu uz krevet pacijenta neposredno prije primjene. Nudi više fleksibilnosti, ali nosi rizik da se pogreška tipa može otkriti samo u određenoj, rijetkoj situaciji, potencijalno dugo nakon što je uređaj raspoređen. Jezici kao što su Python i JavaScript dinamički su tipkani.

Medicinski uređaji često koriste kombinaciju oba. Osnovne funkcije koje održavaju život obično su izgrađene sa statički tipkanim jezicima za maksimalnu sigurnost, dok manje kritična korisnička sučelja ili nadzorne ploče za analizu podataka mogu koristiti dinamički tipkane jezike za brži razvoj i fleksibilnost.

Sjecište: Gdje se generički uređaji susreću s rizicima sigurnosti tipova

Središnja teza ove rasprave je da je sama interoperabilnost koja generičke uređaje čini tako privlačnima ujedno i njihov najveći izvor rizika povezanog s tipovima. Kada jedan proizvođač kontrolira cijeli sustav (pumpu, monitor i središnji softver), oni mogu osigurati da su tipovi podataka dosljedni u cijelom njihovom ekosustavu. Ali u okruženju s više dobavljača, ta jamstva isparavaju.

Scenarij "uključi i moli se": Noćne more interoperabilnosti

Vratimo se našem međunarodnom ICU scenariju. Bolnica spaja novi uređaj na svoju postojeću mrežu. Što može poći po zlu na razini podataka?

• Nepodudarnosti jedinica: Vaga iz SAD-a šalje težinu pacijenta u funtama (lbs). Povezani softver za izračun doze, razvijen u Europi, očekuje kilograme (kg). Bez eksplicitnog polja jedinice i sustava koji ga provjerava, softver bi mogao tretirati '150' lbs kao '150' kg, što bi dovelo do potencijalno smrtonosnog predoziranja. Ovo nije strogo pogreška tipa (oba su brojevi), ali je blisko povezana semantička pogreška koju robusni sustavi tipova mogu pomoći u sprječavanju zahtijevajući da podaci budu upareni s njihovim tipom jedinice.
• Nepodudarnosti formata podataka: Uređaj u SAD-u bilježi datum kao MM/DD/GGGG (npr. 04/10/2023 za 10. travnja). Europski sustav očekuje DD/MM/GGGG. Kada primi '04/10/2023', tumači ga kao 4. listopada, što dovodi do netočnih zapisa o pacijentima, pogrešaka u vremenu primjene lijekova i pogrešne analize trendova.
• Implicitna prisila tipa: Ovo je jedna od najpodmuklijih pogrešaka. Sustav, pokušavajući biti 'koristan', automatski pretvara podatke iz jednog tipa u drugi. Na primjer, monitor glukoze u krvi izvješćuje o vrijednosti "85.0". Sustavu koji prima podatke potreban je cijeli broj, pa izostavlja decimalu i pohranjuje '85'. Ovo se čini u redu. Ali što ako monitor izvješćuje o "85.7"? Sustav bi ga mogao skratiti na '85', gubeći preciznost. Drugi sustav bi ga mogao zaokružiti na '86'. Ova nedosljednost može imati ozbiljne kliničke implikacije, osobito kada se podaci agregiraju tijekom vremena.
• Rukovanje nultim ili neočekivanim vrijednostima: Senzor krvnog tlaka privremeno ne radi i šalje `null` vrijednost (koja predstavlja 'nema podataka') umjesto broja. Kako reagira središnji sustav za praćenje? Podiže li alarm? Prikazuje li '0'? Prikazuje li jednostavno zadnje valjano očitanje, dovodeći kliničara u zabludu da misli da je pacijent stabilan? Robusni dizajn siguran za tipove predviđa ove rubne slučajeve i definira sigurno, eksplicitno ponašanje za svaki od njih.

Izazov komunikacijskih protokola: HL7, FHIR i semantički jaz

Moglo bi se pretpostaviti da standardizirani protokoli kao što su HL7 i FHIR rješavaju ove probleme. Iako su ogroman korak u pravom smjeru, oni nisu srebrni metak. Ovi protokoli definiraju strukturu i sintaksu za razmjenu zdravstvenih informacija—'gramatiku' razgovora. Međutim, oni ne nameću uvijek kruto 'značenje' (semantiku) ili specifične tipove podataka unutar te strukture.

Na primjer, FHIR resurs za 'Promatranje' može imati polje nazvano `valueQuantity`. FHIR standard specificira da ovo polje treba sadržavati brojčanu vrijednost i jedinicu. Ali nepravilno implementiran uređaj mogao bi staviti tekstualni niz kao što je "Previsoko za mjerenje" u polje bilješki umjesto da koristi odgovarajući kod u polju vrijednosti. Loše dizajniran sustav koji prima podatke možda neće znati kako se nositi s ovim odstupanjem od norme, što dovodi do gubitka podataka ili nestabilnosti sustava.

Ovo je izazov 'semantičke interoperabilnosti': dva sustava mogu uspješno razmijeniti poruku, ali mogu različito tumačiti njezino značenje. Istinska sigurnost tipova na razini sustava ne uključuje samo provjeru valjanosti strukture podataka, već i njegovog sadržaja i konteksta.

Regulatorni krajolik: Globalna perspektiva o sigurnosti softvera

Prepoznajući te rizike, regulatorna tijela diljem svijeta sve više naglašavaju validaciju softvera, upravljanje rizicima i interoperabilnost. Globalni proizvođač ne može se usredotočiti na propise samo jedne zemlje; oni moraju upravljati složenom mrežom međunarodnih standarda.

Ključna regulatorna tijela i njihovo stajalište

• Američka agencija za hranu i lijekove (FDA): FDA ima opsežne smjernice o softveru medicinskih uređaja, uključujući "Softver kao medicinski uređaj" (SaMD). Oni naglašavaju pristup temeljen na riziku i zahtijevaju od proizvođača da dostave detaljnu dokumentaciju o svom dizajnu softvera, validaciji i postupcima provjere. Njihov fokus na kibernetičku sigurnost također je vrlo relevantan, jer mnoge sigurnosne ranjivosti proizlaze iz lošeg rukovanja neočekivanim unosima podataka—problem usko povezan sa sigurnošću tipova.
• Uredba Europske unije o medicinskim uređajima (EU MDR): EU MDR, koja je zamijenila prethodnu Direktivu o medicinskim uređajima (MDD), stavlja snažan naglasak na cijeli životni ciklus proizvoda, uključujući nadzor nakon stavljanja na tržište. Zahtijeva od proizvođača da pruže mnogo rigoroznije kliničke dokaze i tehničku dokumentaciju. Za softver, to znači dokazati da je uređaj siguran i radi kako je predviđeno, osobito kada je spojen na druge uređaje.
• Međunarodni forum regulatora medicinskih uređaja (IMDRF): Ovo je dobrovoljna skupina regulatora iz cijelog svijeta (uključujući SAD, EU, Kanadu, Japan, Brazil i druge) koji rade na usklađivanju propisa o medicinskim uređajima. Njihovi dokumenti sa smjernicama o temama kao što je kategorizacija rizika SaMD utjecajni su u postavljanju globalne osnovice za očekivanja u pogledu sigurnosti i performansi.

Standardi u pomoć: ISO, IEC i AAMI

Kako bi ispunili te regulatorne zahtjeve, proizvođači se oslanjaju na skup međunarodnih standarda. Za softver, najvažniji je IEC 62304.

• IEC 62304 - Softver medicinskih uređaja – Procesi životnog ciklusa softvera: Ovo je zlatni standard za razvoj softvera medicinskih uređaja. Ne propisuje *kako* pisati kod, ali definira rigorozan okvir za cijeli proces: planiranje, analiza zahtjeva, arhitektonski dizajn, kodiranje, testiranje, izdavanje i održavanje. Pridržavanje IEC 62304 prisiljava razvojne timove da razmišljaju o rizicima, uključujući one od interoperabilnosti i nepodudaranja podataka, od samog početka.
• ISO 14971 - Primjena upravljanja rizikom na medicinske uređaje: Ovaj standard zahtijeva od proizvođača da identificiraju, analiziraju i kontroliraju rizike povezane s njihovim uređajima tijekom cijelog njihovog životnog ciklusa. Nepodudarnost tipa koja uzrokuje pogrešku u doziranju klasična je opasnost koja se mora identificirati u analizi rizika. Proizvođač tada mora implementirati mjere ublažavanja (kao što su robusna validacija podataka i provjera tipova) i dokazati da te mjere smanjuju rizik na prihvatljivu razinu.

Ovi standardi prebacuju odgovornost izravno na proizvođača da dokaže da je njihov uređaj siguran, ne samo sam po sebi, već u kontekstu njegove namjeravane uporabe—što sve više znači biti povezan s drugim sustavima.

Najbolje prakse za osiguravanje sigurnosti tipova u zdravstvenoj tehnologiji

Osiguravanje sigurnosti pacijenata u međusobno povezanom svijetu zajednička je odgovornost. Zahtijeva marljivost od inženjera koji pišu kod, bolnica koje implementiraju tehnologiju i kliničara koji je koriste uz krevet.

Za proizvođače medicinskih uređaja

1. Usvojite filozofiju dizajna "Sigurnost na prvom mjestu": Koristite programski jezici s jakim tipovima (npr. Rust, Ada, C++, Swift) za komponente od kritične važnosti za sigurnost. Ovi jezici čine pogreškom u vrijeme kompilacije miješanje nekompatibilnih tipova, eliminirajući cijele kategorije pogrešaka prije nego što se softver uopće testira.
2. Vježbajte obrambeno programiranje: Tretirajte sve podatke koji dolaze s vanjskog uređaja ili sustava kao potencijalno zlonamjerne ili neispravne dok se ne provjere valjanost. Nikada ne vjerujte dolaznim podacima. Provjerite tip, raspon, format i jedinice prije obrade.
3. Implementirajte rigorozno testiranje: Idite dalje od testiranja 'sretnog puta'. Jedinični testovi i integracijski testovi moraju uključivati rubne slučajeve: unošenje pogrešnih tipova podataka, vrijednosti izvan raspona, nulte unose i netočno formatirane nizove u svako sučelje kako bi se osiguralo da sustav sigurno otkaže (tj. podizanjem alarma i odbijanjem podataka).
4. Pružite kristalno jasnu dokumentaciju: Dokumentacija sučelja za programiranje aplikacija (API) za uređaj mora biti nedvosmislena. Za svaku podatkovnu točku koja se može razmjenjivati, mora se izričito navesti potrebni tip podataka, jedinice (npr. "kg", a ne samo "težina"), očekivani raspon i format (npr. ISO 8601 za datume).
5. Koristite sheme podataka: Na svakom elektroničkom sučelju koristite formalnu shemu (kao što je JSON Schema ili XML Schema Definition) za programsko provjeravanje valjanosti strukture i tipova podataka dolaznih informacija. Ovo automatizira proces validacije.

Za zdravstvene organizacije i IT odjele

1. Razvijte sveobuhvatnu strategiju integracije: Ne dopuštajte ad-hoc povezivanje uređaja. Imajte formalnu strategiju koja uključuje temeljitu procjenu rizika za svaki novi uređaj koji se dodaje mreži.
2. Zahtijevajte izjave o sukladnosti od dobavljača: Tijekom nabave, zahtijevajte od dobavljača da dostave detaljne izjave o sukladnosti specificirajući koje protokole podržavaju i kako ih implementiraju. Postavljajte usmjerena pitanja o tome kako njihov uređaj rukuje validacijom podataka i uvjetima pogreške.
3. Stvorite testno okruženje: Održavajte izolirano, nekliničko mrežno okruženje ('testno okruženje') za testiranje novih uređaja i ažuriranja softvera. U ovom testnom okruženju simulirajte cijeli klinički protok podataka od kraja do kraja kako biste otkrili probleme interoperabilnosti prije nego što se uređaj koristi s pacijentima.
4. Uložite u međuprogramsku opremu: Koristite motore za integraciju ili međuprogramsku opremu kao središnje čvorište za komunikaciju uređaja. Ovi sustavi mogu djelovati kao 'univerzalni prevoditelj' i 'sigurnosni pristupnik', provjeravajući valjanost, transformirajući i normalizirajući podatke s različitih uređaja prije nego što ih proslijede EHR-u ili drugim kritičnim sustavima.
5. Promovirajte kulturu suradnje: Klinički inženjering (biomedicinski) timovi i IT odjeli moraju blisko surađivati. Ljudi koji razumiju kliničke tijekove rada moraju surađivati s ljudima koji razumiju protok podataka kako bi identificirali i ublažili rizike.

Za kliničare i krajnje korisnike

1. Zalažite se za obuku: Kliničari moraju biti obučeni ne samo o tome kako koristiti uređaj, već i o osnovama njegove povezanosti. Trebali bi razumjeti koje podatke šalje i prima, te što znače uobičajene poruke o pogreškama ili upozorenja.
2. Budite oprezni i prijavite anomalije: Kliničari su posljednja linija obrane. Ako uređaj prikazuje neočekivane podatke, ako brojevi ne izgledaju u redu ili ako se sustav ponaša sporo nakon što je spojen novi uređaj, to se mora odmah prijaviti kliničkom inženjeringu i IT-u. Ova povratna informacija nakon stavljanja na tržište neprocjenjiva je za hvatanje suptilnih pogrešaka koje su propuštene tijekom testiranja.

Budućnost: Umjetna inteligencija, strojno učenje i sljedeća granica sigurnosti tipova

Izazovi sigurnosti tipova postat će samo akutniji s pojavom umjetne inteligencije (UI) i strojnog učenja (SU) u medicini. Algoritam UI dizajniran za predviđanje sepse mogao bi se obučavati na masivnom skupu podataka s određenog skupa monitora pacijenata. Što se događa kada mu bolnica unese podatke s nove, različite marke monitora? Ako novi monitor mjeri parametar u malo drugačijim jedinicama ili ima drugačiju razinu preciznosti, to bi moglo suptilno iskriviti unos UI, što bi dovelo do opasne pogrešne dijagnoze.

Priroda 'crne kutije' nekih složenih SU modela čini ove probleme još težima za otklanjanje pogrešaka. Potrebni su nam novi standardi i tehnike validacije posebno dizajnirane za medicinske uređaje s UI, osiguravajući da su robusni i da se ponašaju predvidljivo čak i kada se suoče s podacima iz raznolikog i razvijajućeg se ekosustava generičkih uređaja.

Zaključak: Izgradnja sigurnije, međusobno povezane zdravstvene budućnosti

Prijelaz prema modularnom, interoperabilnom zdravstvenom ekosustavu izgrađenom na 'generičkim' medicinskim uređajima nije samo neizbježan, već je i poželjan. Obećava inovativniju, učinkovitiju i isplativiju budućnost za globalnu zdravstvenu skrb. Međutim, ovaj napredak ne može doći na uštrb sigurnosti pacijenata.

Sigurnost tipova nije samo apstraktna briga za softverske inženjere; to je nevidljivi temelj na kojem se gradi pouzdana i sigurna interoperabilnost medicinskih uređaja. Neuspjeh u poštivanju važnosti tipova podataka, jedinica i formata može dovesti do korupcije podataka, dijagnostičkih pogrešaka i netočnog isporučivanja liječenja. Osiguravanje ove sigurnosti je zajednička odgovornost. Proizvođači moraju dizajnirati i graditi obrambeno. Regulatori moraju nastaviti unapređivati globalne standarde. A zdravstvene organizacije moraju implementirati i upravljati tim tehnologijama rigoroznom, metodologijom svjesnom sigurnosti.

Dajući prioritet robusnoj validaciji podataka i potičući kulturu suradnje, možemo iskoristiti nevjerojatnu moć povezane tehnologije za poboljšanje ishoda pacijenata, uvjereni da sustavi koje gradimo nisu samo pametni, već su, iznad svega, sigurni.