Ämne 4.4 — Uppkopplade enheter, IoT och medicinsk teknik

Inom hälsa och vård är den uppkopplade enheten där programvara möter patientens kropp, så hur ni förvaltar flottan av pumpar, monitorer, skannrar och bärbar teknik är ett beslut om klinisk säkerhet, cybersäkerhet och allmänhetens förtroende, inte en post i fastighetsbudgeten.

Varför detta är viktigt inom hälsa och vård#

Ett modernt sjukhus drivs av maskiner som rör patienter direkt och ständigt talar med nätverket. Infusionspumpar doserar läkemedel i mikroliter, respiratorer håller människor andande, monitorer bevakar vitala tecken, bildskannrar avger joniserande strålning och byggnadsstyrningssystem håller temperaturen i vaccinkylskåpen. En växande andel av dessa är uppkopplade: de skickar data in i journaler, hämtar konfiguration från servrar och exponerar hanteringsgränssnitt. När en beter sig oväntat är felet inte ett obekvämt avbrott — det kan vara ett dosfel, ett missat larm eller en korrumperad bild som ändrar en diagnos.

Det är därför enhetshantering ligger i skärningspunkten mellan tre plikter ni redan bär. Det är en plikt för klinisk säkerhet, eftersom ett enhetsfel eller en dålig patch kan skada en patient (se Ämne 1.6 — Klinisk säkerhet och riskhantering). Det är en plikt för cybersäkerhet, eftersom uppkopplad klinisk utrustning är en av de största och minst styrda attackytorna i beståndet (se Ämne 1.7 — Informationsstyrning, dataskydd och cybersäkerhet). Och det är en rättslig plikt, eftersom medicintekniska produkter är reglerade produkter med skyldigheter efter marknadsintroduktion som delvis faller på er som användare.

Insatserna vidgas, de smalnar inte. Vården flyttar in i hemmet genom bärbar teknik och fjärrövervakning, så ”enhetsbeståndet” inkluderar nu utrustning ni inte äger på nätverk ni inte kontrollerar. Enheter lever långt längre än programvaran i dem, så en skanner köpt för ett femtonårigt kliniskt liv kan köra ett operativsystem som förlorade säkerhetsstöd efter fem. Utpressningsgrupper har lärt sig att klinisk teknik är bräcklig, opatchad och verksamhetskritisk — en lönsam kombination. Att behandla uppkopplade enheter som någon annans problem är hur organisationer mitt i en incident upptäcker att ingen äger dem.

Grundläggande begrepp#

En medicinteknisk produkt (medical device) är varje instrument, apparat eller programvara avsedd av sin tillverkare för ett medicinskt syfte — diagnos, övervakning, behandling eller förebyggande — som inte uppnår sin effekt genom farmakologi. En uppkopplad medicinteknisk produkt lägger till ett nätverksgränssnitt: den skickar eller tar emot data, eller kan hanteras på distans. Internet of Medical Things (IoMT) är den hälsorelaterade tillämpningen av det bredare Internet of Things (IoT) — populationen av sensorer och vardagsföremål som ansluter till nätverk och utbyter data. I en vårdmiljö spänner IoMT över sängkantsmonitorer, smarta pumpar, bärbar teknik, hemsensorer och den kliniska mellanvara som binder ihop dem.

Medicinsk teknik (clinical engineering) är den specialitet, som ingår i biomedicinsk teknik, som ansvarar för säker och effektiv användning av medicinsk teknologi i en vårdorganisation. Inom NHS kallas dessa team ofta medicinsk teknik, medicinsk fysik eller Electronic and Biomedical Engineering (EBME). Förvaltning av medicinteknisk utrustning (medical device management) är deras kärndisciplin: att föra en korrekt förteckning, planerat förebyggande underhåll, kalibrering, reparation, säkerhetsmeddelanden, utbildning och kontrollerad avveckling vid livets slut.

Operativ teknik (operational technology, OT) är den maskin- och programvara som övervakar eller styr fysiska processer och utrustning, till skillnad från konventionell informationsteknik (IT) som bearbetar affärsdata. Kliniska enheter och byggnadssystem är OT: de har verkliga fysiska effekter, långa livscykler och begränsningar (drifttid, certifiering, realtidsbeteende) som gör vanlig IT-praxis — starta om, patcha, ersätta — riskabel eller förbjuden utan tillverkarens välsignelse. Attackytan (attack surface) är summan av de punkter där en angripare kan ta sig in i eller påverka ett system; uppkopplade enheter förstorar den dramatiskt eftersom var och en är en liten, ofta ohärdad dator på ert nätverk.

Två kontroller återkommer genom hela detta ämne. Nätverkssegmentering (network segmentation) är praxis att dela upp ett nätverk i isolerade zoner så att ett intrång i en inte fritt kan spridas till andra — den enskilt mest effektiva mildringen för klinisk utrustning som inte kan patchas. Tillgångsinsyn (asset visibility) är helt enkelt att veta vad ni har: varje enhet, dess plats, firmware, ägarskap, nätverksbeteende och supportstatus. Ni kan inte skydda, patcha eller avveckla det ni inte kan se.

Slutligen den regulatoriska ramen. I Storbritannien reglerar Medicines and Healthcare products Regulatory Agency (MHRA) medicintekniska produkter, och marknadskontroll efter försäljning (postmarketing surveillance) — övervakning av säkerhet och prestanda efter att en produkt finns på marknaden — är en delad skyldighet mellan tillverkare och de användare som använder och rapporterar om enheterna. Bärbar teknik (wearable technology) och fjärrövervakning av patienter utvidgar alla dessa begrepp bortom byggnaden, in i patientens hem och ficka.

Bästa praxis#

1. Bygg och underhåll en auktoritativ enhetsförteckning. Ni kan inte förvalta, säkra eller avveckla det ni inte har räknat. Slå samman den medicintekniska avdelningens tillgångsdatabas med data från nätverksupptäckt så att förteckningen registrerar inte bara tillverkare, modell och plats utan firmwareversion, operativsystem, nätverksbeteende, dataflöden, ägarskap och supportstatus. Behandla förteckningen som ett levande säkerhetssystem med en namngiven ägare, kontinuerligt avstämt mot vad som faktiskt finns på kabeln, inte ett kalkylblad som uppdateras en gång om året inför revisionen.

2. För samman IT, medicinsk teknik och cybersäkerhet i ett styrforum. Dessa enheter faller mellan tre team, och glappen mellan dem är exakt där incidenter bor. Inrätta en gemensam grupp för säkerhet i medicintekniska produkter med tydliga beslutsrättigheter över introduktion, patchning, segmentering och avveckling, och ge den en stående koppling till funktionen för klinisk säkerhet. De medicintekniska ingenjörerna förstår enheten och patientrisken; säkerhetsteamet förstår nätverkshotet; ingen kan agera tryggt utan den andra.

3. Segmentera nätverket och utgå från minsta möjliga uppkoppling. De flesta kliniska enheter kan inte härdas eller patchas på er tidtabell, så begränsa dem i stället. Placera enheter i segmenterade zoner med tätt kontrollerade flöden, tillåt bara de anslutningar en enhet genuint behöver och neka resten, så att ett intrång inte kan korsa beståndet. Segmentering är den kontroll som låter er fortsätta driva en enhet som är kliniskt säker men digitalt svag — den köper tid som patchning ensam aldrig gör.

4. Behandla patchning som en klinisk säkerhetsändring, gemensamt ägd med tillverkaren. En patch på en reglerad enhet är en ändring av en säkerhetskritisk produkt, och att tillämpa en ovaliderad uppdatering kan vara lika farligt som att lämna ett hål öppet. Följ tillverkares säkerhetsmeddelanden och MHRA:s säkerhetsmeddelanden i fält (field safety notices), validera uppdateringar mot tillverkarens vägledning och schemalägg dem genom klinisk ändringskontroll med reservplaner. Där en enhet inte kan patchas, registrera den accepterade restrisken och de kompenserande kontrollerna i stället för att låtsas att glappet inte finns.

5. Planera hela livscykeln, inklusive livets slut, innan ni köper. En enhets kliniska liv överlever rutinmässigt leverantörens programvarustöd, vilket skapar år av oskyddad, internetexponerad risk. Vid upphandling, kräv en programvaruförteckning (software bill of materials), ett angivet åtagande om support och patchning, funktioner för säker design (secure-by-design) och ett tydligt slutdatum för support, och budgetera för ersättning mot det datumet, inte det mekaniska (se Ämne 6.3 — Upphandling och kommersiella frågor). Avveckling är också ett kontrollerat steg: radera patientdata, återkalla inloggningsuppgifter och nätverksåtkomst och uppdatera förteckningen, eftersom en bortglömd monitor i ett förråd fortfarande är en levande väg in.

6. Få in enhetsdata i journalen tryggt och meningsfullt. Värdet av uppkopplade enheter realiseras när mätvärden flödar in i den kliniska journalen korrekt, med rätt patient, enheter och tidsstämplar och med tydlig proveniens. Använd erkända interoperabilitetsstandarder och integrationsmellanvara i stället för skräddarsydda punkt-till-punkt-länkar, och validera att ett enhetsmätvärde kopplas till rätt patient varje gång (se Ämne 4.3 — Interoperabilitet och datastandarder). Ett vitalt tecken tillskrivet fel patient, eller en tvetydig enhet, är en klinisk säkerhetsfara utklädd till integrationsbekvämlighet.

7. Designa distansövervakning och bärbar teknik för hemmet, inte avdelningen. När vården flyttar in i hemmet ärver ni enheter på hembredband, delade av familjer, laddade sporadiskt och använda av människor som är sjuka. Designa för glapp i uppkopplingen, tydlig eskalering när mätvärden bryter mot tröskelvärden, digital inkludering och uttryckligt samtycke om vad som samlas in och vem som agerar på det (se Ämne 1.9 — Digital inkludering och tillgänglighet och Ämne 3.3 — Digitala tjänster för patienter och medborgare). Var ärliga om kliniskt ansvar: en ström av hemmätvärden som ingen har resurser att titta på är en falsk trygghet, inte en tjänst.

8. Öva förlusten av era enheter, och rapportera fel uppåt. Anta att en klass av enheter en dag blir otillgänglig — genom utpressningsprogram, en återkallelse eller ett nätverksfel — och öva den kliniska reserven så att personal inte improviserar under en incident (se Ämne 3.9 — Kontinuitetsplanering och katastrofåterställning). Parallellt, mata in enhetsfel, tillbud och avvikelser i MHRA:s marknadskontroll efter försäljning genom Yellow Card-systemet, eftersom era rapporter är hur systemiska enhetsfel fångas innan de skadar någon annan.

Frågor att diskutera med ditt team#

1. Vem äger egentligen flottan av uppkopplade enheter under hela dess liv — och var finns glappen mellan IT, medicinsk teknik och cybersäkerhet i dag? Det spelar roll eftersom oägda enheter är de som förblir opatchade, obevakade och okartlagda tills en incident tvingar fram frågan. I de flesta organisationer äger medicinsk teknik tillgångsregistret, IT äger nätverket, säkerhet äger hotet och ingen äger enheten som en uppkopplad, reglerad, patientvänd helhet. Debattera var skarvarna finns: vem som avgör att en enhet får ansluta till nätverket, vem som validerar en patch, vem som godkänner avveckling och vem som är ansvarig när en enhet både är ett säkerhetskritiskt instrument och en sårbar dator. Beakta om ert styrforum har verkliga beslutsrättigheter och budget, eller är en pratstuga som eskalerar allt och löser ingenting. Ett gott, ärligt svar namnger den ansvariga ägaren för varje livscykelsteg, erkänner var svaret i dag är ”ingen” och förbinder sig att stänga specifika skarvar snarare än att upprepa att samarbete är viktigt.

2. Hur stor del av vårt uppkopplade bestånd kan vi faktiskt se, och hur säkra är vi på det talet? Ni kan inte segmentera, patcha eller avveckla enheter ni inte har räknat, men de flesta organisationer upptäcker under en incident att deras förteckning underskattar verkligheten med bred marginal — skuggenheter, leverantörsinstallerad utrustning, bortglömd utrustning i förråd och hemenheter ingen katalogiserat. Diskutera hur er förteckning byggs och stäms av: är det ett statiskt kalkylblad, eller matchas det kontinuerligt mot vad nätverksupptäckt ser på kabeln? Pröva ärligheten i teamets tillförsikt — ett till synes exakt tal utan avstämningsprocess är farligare än ett erkänt ”vi vet inte helt”, eftersom det föder falsk trygghet. Beakta de svåraste kategorierna: byggnadsstyrningssystem, utrustning förvaltad av tredje part och enheter i patienters hem. Ett bra svar anger en realistisk täckningssiffra, beskriver hur avvikelser hittas och stängs och behandlar förteckningen som ett säkerhetskritiskt system med en namngiven ägare snarare än en efterlevnadsartefakt.

3. Vad händer kliniskt när en klass av dessa enheter är otillgänglig, osäker eller komprometterad — och har vi någonsin övat det? Uppkopplade enheter havererar som en klass, inte en i taget: en utpressningshändelse, en firmwarebugg, en återkallelse eller ett nätverksavbrott kan ta ut varje pump eller monitor av en typ samtidigt. Diskutera vilka enhetsklasser som skulle orsaka mest skada om de förlorades, vad den manuella eller alternativa kliniska reserven är och om frontlinjepersonal faktiskt känner till den eller skulle improvisera under press. Lyft avvägningen mellan tillgänglighet och säkerhet: trycket att hålla en bräcklig enhet igång kliniskt kontra risken att lämna ett känt hål öppet, och vem som är bemyndigad att göra det avgörandet. Beakta om ni ens skulle upptäcka en komprometterad enhet som beter sig subtilt fel — en monitor som rapporterar rimliga men falska mätvärden är svårare att fånga än en som går mörk. Ett bra svar identifierar klasserna med störst skada, bekräftar att en övad och resursatt reserv finns för var och en och är uppriktigt om de blinda fläckar för upptäckt som återstår.

4. Köper och budgeterar vi för enhetens programvaruliv, eller bara dess mekaniska liv? En skanner kan ha ett femtonårigt kliniskt liv medan operativsystemet inuti förlorar säkerhetsstöd efter fem, så ett inköpsbeslut i dag förbinder er i tysthet till ett decennium av risk som inte kan patchas om inte någon planerar för det. Diskutera om er upphandlingsprocess behandlar en programvaruförteckning, ett angivet patchningsåtagande, funktioner för säker design och ett uttryckligt slutdatum för support som avtalsvillkor, eller som trevliga-att-ha som faller bort under prispress. Pröva vem som håller ersättningsbudgeten och mot vilket datum den sätts — den mekaniska haveripunkten, eller programvarans slut på support som inträffar år tidigare. Beakta de besvärliga fall som redan finns i beståndet: enheter köpta innan någon ställde dessa frågor, nu år förbi sitt stöd, utan ersättningsfinansiering i sikte. Lyft spänningen mellan kliniska team som vill ha den nyaste förmågan, ekonomi som vill utnyttja tillgångar hela deras fysiska liv och säkerhet som ser det växande ansvaret. Ett ärligt svar kopplar köpbeslutet till helhetslivskostnaden, namnger vem som äger ersättningsbudgeten och erkänner var beståndet redan bär ofinansierad risk för programvaruföråldrande.

5. För de enheter som flyttar in i patienters hem, vem tittar egentligen på mätvärdena — och har vi designat för de människor som använder dem? Fjärrövervakning och bärbar teknik flyttar enhetsbeståndet till hembredband, delat med familjer, laddat sporadiskt och använt av människor som är sjuka, så avdelningens antaganden om uppkoppling, kontroll och support gäller inte längre. Diskutera om ett namngivet, resursatt kliniskt team är ansvarigt för att agera på hemmätvärden, eller om data flödar in i en instrumentpanel ingen är finansierad att titta på — en falsk trygghet utklädd till tjänst. Lyft spänningen kring digital inkludering: ett hemövervakningsprogram kan i tysthet utesluta dem utan tillförlitligt bredband, en lämplig enhet eller tryggheten att använda en, och vidga just de ojämlikheter det var tänkt att minska (se Ämne 1.9 — Digital inkludering och tillgänglighet). Beakta samtycke och tydligt ansvar — patienter och anhöriga behöver veta vad som samlas in, vem som ser det och vad som händer när ett mätvärde bryter mot ett tröskelvärde. Väg draget att skala dessa program snabbt mot plikten att göra dem säkra och jämlika. Ett bra svar bekräftar vem som bevakar och eskalerar, är uppriktigt om inkluderingsriskerna och behandlar hemenheter som en styrd klinisk tjänst snarare än ett bekvämt dataflöde.

6. När ett enhetsmätvärde når den kliniska journalen, är vi säkra på att det är rätt värde, i rätt enheter, för rätt patient? Det kliniska värdet av en uppkopplad enhet realiseras först när dess data landar i journalen korrekt, men varje integration är också en ny chans att tillskriva ett vitalt tecken fel patient eller att förlora de enheter och den proveniens som ligger bakom ett tal. Diskutera om enhetsdata flödar genom validerade interoperabilitetsstandarder och integrationsmellanvara med uttryckliga patientmatchningskontroller, eller genom skräddarsydda punkt-till-punkt-länkar ingen helt förstår (se Ämne 4.3 — Interoperabilitet och datastandarder). Pröva de felmönster som ser ut som bekvämlighet men är säkerhetsfaror: en tvetydig enhet, ett felaktigt tidsatt mätvärde, ett värde skrivet till den föregående patient som fortfarande är inloggad vid sängkanten. Beakta hur ni ens skulle upptäcka ett sådant fel, givet att ett rimligt-men-fel tal är långt farligare än ett uppenbart glapp. Lyft avvägningen mellan hastigheten att ansluta en ny enhet och det kvalitetssäkringsarbete som gör dess data pålitliga. Ett ärligt svar beskriver hur patientmatchning och enhetsintegritet valideras från början till slut, namnger vem som äger den kvalitetssäkringen och behandlar ett felattribuerat mätvärde som den kliniska säkerhetsincident det är snarare än ett integrationsbesvär.

I praktiken: ett exempel från hälsa och vård#

Meadowfield NHS Foundation Trust driver ett medelstort akutsjukhus och, alltmer, en virtuell vårdavdelning som övervakar patienter hemma. Efter att ett systersjukhus drabbats av en utpressningsincident som spreds genom ohanterade kliniska enheter ställer Meadowfields styrelse en enkel fråga: hur många uppkopplade enheter har vi, och vem äger dem? Det ärliga svaret är att ingen kan säga. Medicinsk tekniks databas listar omkring 6 000 tillgångar; nätverksteamets passiva upptäcktsverktyg ser närmare 9 000 saker som beter sig som enheter. Glappet är problemet.

Sjukhuset inrättar en gemensam grupp för säkerhet i medicintekniska produkter med chefen för medicinsk teknik och chefen för informationssäkerhet (CISO) som gemensamma ordförande, med den kliniska säkerhetsansvarige som deltagare. Deras första leverans är en avstämd förteckning: de slår samman de två datakällorna, jagar avvikelserna och finner infusionspumpar på det allmänna nätverket, en CT-skanner som kör ett operativsystem tre versioner förbi slutet på supporten och en uppsättning byggnadsstyrningsenheter för apotekens kylskåp som IT aldrig katalogiserat. Varje fynd loggas med ett kliniskt riskbetyg snarare än ett rent tekniskt.

De kan inte ersätta skannern i år, så de begränsar den: den flyttas till en tätt segmenterad zon som endast tillåter flödena till dess bildarkiv och leverantörens supportgateway, och den accepterade restrisken registreras och godkänns genom klinisk styrning. Pumparna skrivs in i en förvaltad patchcykel validerad mot tillverkarens meddelanden och schemalagd genom ändringskontroll. För den virtuella vårdavdelningen insisterar gruppen på att hemövervakningsenheter rapporterar in i journalen genom validerad integrationsmellanvara med patientmatchningskontroller, och att ett namngivet kliniskt team är resursatt att bevaka och eskalera mätvärdena — inte en instrumentpanel ingen äger.

Sex månader senare utfärdar en leverantör ett säkerhetsmeddelande i fält om en firmwaredefekt i en monitor. Eftersom förteckningen nu är korrekt och avstämd identifierar Meadowfield varje berörd enhet inom en timme, tillämpar den validerade rättelsen genom ändringskontroll och rapporterar sitt eget relaterade tillbud till MHRA genom Yellow Card-systemet. Arbetet var oglamoröst — en förteckning, ett forum, ett segmenteringsprojekt — men det förvandlade en osynlig, oägd risk till en hanterad.

Sektorperspektiv#

Startup-företag#

Ett digitalt hälsoföretag som levererar en bärbar enhet eller en hemövervakningsenhet står på tillverkarsidan av den regulatoriska gränsen, och dess arbetssätt måste spegla det från dag ett. Bygg säker design: signerad firmware, en väg för uppdatering över luften, en programvaruförteckning och en plan för att patcha enheter som redan finns i fält — att eftermontera säkerhet efter en finansieringsrunda är långt svårare. Förstå att ni bär skyldigheter för marknadskontroll efter försäljning och MHRA-skyldigheter som inte skalas ned för ett litet team, och att en sjukhuskund kommer att bedöma er säkerhetsställning innan den släpper er enhet nära sitt nätverk. Er konkurrensfördel är inte bara enheten utan det trovärdiga, dokumenterade löftet att ni kommer att stödja och säkra den under hela dess kliniska liv.

Småföretag#

En etablerad liten vårdgivare — en läkarpraktik, ett närapotek, ett vårdhem eller en klinik på en enda ort — driver en blygsam men verklig flotta av uppkopplad utrustning: blodtrycksmätare, EKG-enheter, sensorer i vaccinkylskåp, spirometrar och det växande flödet av bärbar teknik för patienter, alla på ett nätverk ingen dedikerad IT-avdelning bevakar. Samma MHRA-, cybersäkerhets- och klinisk säkerhetsplikter gäller som för ett stort sjukhus, men det finns ingen medicinteknisk avdelning och ofta ingen intern IT alls, så börja med att helt enkelt veta vad ni har: en kort, ärlig förteckning med tillverkare, firmware och supportstatus slår ett avancerat system ni inte kan underhålla. Luta er hårt mot era leverantörer och förvaltade tjänstepartner — insistera på att underhållsavtal, patchningsansvar och slutdatum för support skrivs ned, eftersom ni förlitar er på dem för förmåga ni inte kan bemanna. Använd köptillfället som er främsta kontrollpunkt, eftersom att ersätta en föråldrad enhet ofta är mer realistiskt för er än att härda den på plats. Håll de mest skadekänsliga sakerna — ett kylskåp med vacciner i kylkedjan, en monitor en kliniker litar på — borta från det platta kontorsnätverket där ett intrång kunde nå allt, även om full segmentering ligger bortom er.

Storföretag#

Ett stort NHS-sjukhus (trust) eller en sjukhusgrupp förvaltar tusentals enheter från dussintals leverantörer över ett vidsträckt, långlivat bestånd, och dess utmaning är samordning och skala. Det realistiska målet är en avstämd förteckning, disciplinerad segmentering och ett gemensamt styrforum som spänner över medicinsk teknik, IT och säkerhet med verklig befogenhet — inte perfekt patchning överallt, vilket leverantörsbegränsningarna gör omöjligt. Bädda in enhetssäkerhet i upphandlingen så att supportåtaganden, funktioner för säker design och slutdatum för support är avtalsvillkor, och anpassa ersättningsbudgeten till programvarulivet, inte det mekaniska (se Ämne 4.0 — Teknisk arkitektur, moln och äldre system). I denna skala kommer de största vinsterna från ett litet antal beståndsomfattande kontroller som görs konsekvent, inte hjältemod på enskilda enheter.

Staten#

Ett nationellt eller regionalt organ — NHS England, en decentraliserad hälsoförvaltning, MHRA — formar den miljö varje användare arbetar i. Det sätter standarder för enhetssäkerhet och ramverk för upphandling, driver nationell hotunderrättelse och larm så att en sårbarhet som hittas på ett sjukhus skyddar alla, och reglerar enheter och deras marknadskontroll efter försäljning. Dess hävstång är att göra säker design och livscykelsupport till marknadens standard genom standarder och köpkraft, så att enskilda sjukhus inte var och en förhandlar säkerhet från en svag position. Staten bär också jämlikhetsplikten: att säkerställa att program för hemövervakning och bärbar teknik inte vidgar den digitala klyftan, och att säkerhetsrapportering flödar uppåt så att systemiska enhetsfel fångas nationellt snarare än återupptäcks sjukhus för sjukhus (se Ämne 9.1 — Samarbete med lokala och nationella myndigheter).

Vanliga felmönster#

• Förteckningen som ljuger. Ett prydligt kalkylblad som senast stämdes av för ett år sedan ger falsk tillförsikt; de enheter som skadar er är de den aldrig listade. Stäm av kontinuerligt mot nätverksupptäckt.
• Enheter i ingenmansland mellan team. När IT säger att det är medicinsk tekniks utrustning och medicinsk teknik säger att det är IT:s nätverk är det ingen som patchar, segmenterar eller övervakar den. Tilldela ägarskap från början till slut.
• Patchningsförlamning eller patchningsvårdslöshet. Båda ytterligheterna skadar patienter — att aldrig uppdatera lämnar kända hål öppna; att tillämpa ovaliderade uppdateringar kan förstöra en säkerhetskritisk enhet. Dirigera patchar genom gemensam klinisk ändringskontroll.
• Att köpa för det mekaniska livet och glömma programvarulivet. En femtonårig skanner på ett femårigt operativsystem med support blir ett ansvar som inte kan patchas. Budgetera ersättning mot slutet på programvarustödet.
• Platta nätverk. Uppkopplade enheter på det allmänna nätverket låter ett enda intrång nå allt. Segmentera som standard.
• Hemövervakning utan någon som tittar. En ström av mätvärden från bärbar teknik som ingen kliniker är resursatt att agera på är en falsk trygghet och en styrningsrisk, inte en tjänst.
• Avveckling som inte är det. En pensionerad enhet kvar på nätverket med gamla inloggningsuppgifter och patientdata är en levande attackväg. Radera, återkalla, koppla från och uppdatera förteckningen.

Mognadsmodell#

Checklista#

• Det finns en auktoritativ enhetsförteckning, kontinuerligt avstämd mot nätverksupptäckt, med en namngiven ägare.
• Ett gemensamt forum för IT, medicinsk teknik och cybersäkerhet har verkliga beslutsrättigheter över introduktion, patchning, segmentering och avveckling.
• Uppkopplade enheter sitter i segmenterade nätverkszoner som endast tillåter de flöden de genuint behöver.
• Patchar och firmwareuppdateringar för reglerade enheter valideras och dirigeras genom klinisk ändringskontroll, med reservplaner.
• Upphandlingsavtal kräver en programvaruförteckning, funktioner för säker design och ett angivet slutdatum för support.
• Ersättningsbudgetar är anpassade till programvarans supportliv, inte bara det mekaniska livet.
• Avveckling raderar patientdata, återkallar inloggningsuppgifter och nätverksåtkomst och uppdaterar förteckningen.
• Enhetsdata når den kliniska journalen genom validerad integration med patientmatchning och enhetskontroller.
• Program för hemövervakning och bärbar teknik har resursatt klinisk eskalering, uttryckligt samtycke och inkludering genom design.
• Klinisk reserv för förlusten av varje enhetsklass med hög skada är dokumenterad och övad.
• Enhetsfel, tillbud och avvikelser rapporteras till MHRA genom Yellow Card-systemet.

Viktiga källor#

• MHRA — Medical devices: guidance for manufacturers, operators and users, och Yellow Card-systemet för rapportering av avvikelser och säkerhetsmeddelanden i fält.
• NHS England / NHS Digital — Data Security and Protection Toolkit och vägledning om nätverks-/enhetssäkerhet för hälso- och vårdorganisationer.
• NCSC (National Cyber Security Centre) — vägledning om operativ teknik, nätverkssegmentering och säkring av uppkopplade enheter.
• NHS England / IEC-standarder — god praxis för medicinsk teknik och förvaltning av medicintekniska produkter (inklusive IEC 80001 för riskhantering av IT-nätverk som innehåller medicintekniska produkter).
• NICE — Evidence Standards Framework for Digital Health Technologies och vägledning om fjärrövervakning och bärbar teknik.
• Institute of Physics and Engineering in Medicine (IPEM) — professionell vägledning för klinisk och biomedicinsk teknik.

Referenser#

1. Medical device — Wikipedia — https://en.wikipedia.org/wiki/Medical_device
2. Internet of things — Wikipedia — https://en.wikipedia.org/wiki/Internet_of_things
3. Clinical engineering — Wikipedia — https://en.wikipedia.org/wiki/Clinical_engineering
4. Biomedical engineering — Wikipedia — https://en.wikipedia.org/wiki/Biomedical_engineering
5. Operational technology — Wikipedia — https://en.wikipedia.org/wiki/Operational_technology
6. Network segmentation — Wikipedia — https://en.wikipedia.org/wiki/Network_segmentation
7. Attack surface — Wikipedia — https://en.wikipedia.org/wiki/Attack_surface
8. Medicines and Healthcare products Regulatory Agency — Wikipedia — https://en.wikipedia.org/wiki/Medicines_and_Healthcare_products_Regulatory_Agency
9. Postmarketing surveillance — Wikipedia — https://en.wikipedia.org/wiki/Postmarketing_surveillance
10. Wearable technology — Wikipedia — https://en.wikipedia.org/wiki/Wearable_technology
11. Remote patient monitoring — Wikipedia — https://en.wikipedia.org/wiki/Remote_patient_monitoring
12. Infusion pump — Wikipedia — https://en.wikipedia.org/wiki/Infusion_pump
13. Medicines and Healthcare products Regulatory Agency — Medical devices: guidance and Yellow Card reporting — GOV.UK — https://www.gov.uk/government/organisations/medicines-and-healthcare-products-regulatory-agency
14. National Cyber Security Centre — Guidance on operational technology and device security — NCSC — https://www.ncsc.gov.uk/
15. NHS England — Data Security and Protection Toolkit — NHS England — https://www.dsptoolkit.nhs.uk/
16. National Institute for Health and Care Excellence — Evidence Standards Framework for Digital Health Technologies — NICE — https://www.nice.org.uk/about/what-we-do/our-programmes/evidence-standards-framework-for-digital-health-technologies
17. Institute of Physics and Engineering in Medicine — Clinical and biomedical engineering guidance — IPEM — https://www.ipem.ac.uk/