Når man ser på de regler og standarder, der skal følges, når man designer et medicinsk udstyr, kan det virke umuligt at bruge Cloud Services og IoT til dette. Når alt kommer til alt, er IEC 62304, IEC 82304-1 og ISO 13485 alle meget rigide, når det kommer til konfigurationsstyring, versionskontrol, styring og en række andre områder. Hele konceptet bag softwarestandarderne 62304/82304-1 er en enkeltstående enhed med eksplicit funktionalitet begrænset til måling af noget, f.eks. en vital parameter, såsom EKG. Desuden dækker standarderne ikke kun funktionaliteten af ​​det medicinske udstyr, men også design- og udviklingsprocessen.

Og ja, det er virkelig en udfordring at bruge Cloud Services og IoT i et medicinsk udstyr.

Men hvad indebærer en medicinsk edge-enhed nøjagtigt?

Der er mindst 3 mulige scenarier for en Medical Edge Device.

Det må:

  • Bruge skyen som en enhedsadministrationsplatform
  • Bruge skyen som et dataindsamlingssystem
  • Bruge skyen som en integreret del af softwaresystemet

Lad mig forklare dette nærmere.

Brugen af skyen som enhedsstyringsplatform

Arkitekturen til det der bruger Microsoft Azure IoT, kaldes eksempelvis Azure IoT Edge. Microsoft bruger mange ressourcer på dette og har et system, der fungerer rigtig godt (og ja, vi har det kørende).

Selvfølgelig skal du opbygge din infrastruktur til at understøtte den, men det er muligt selv på små indlejrede enheder, der kører varianter af Linux.

Fordelen ved dette er primært tre ting:

  • Du har en husholdningsinfrastruktur til softwareopdateringer, programrettelser og tilbagekaldelser
  • Du har adgang til din Medical Edge Devic´s brug og ydeevne (del af din post-marketing overvågning)
  • Analyse af indsamlede data fra Edge giver indsigt i, hvordan man forbedrer softwaren

På den anden side skal du primært kontrollere to ting:

  • Konfigurationskontrol af udviklingsværktøjer
  • Konfigurationskontrol af SOUP-komponenter

Kontrol af din konfiguration af SOUP-komponenter kræver fokus. Din arkitektur og adskillelsesstrategi skal understøtte dette.

Og du har også nye udfordringer, som ikke bør undervurderes:

  • Registrering og klargøring af nye Medical Edge-enheder på Cloud-platformen
  • Sikre data fra måling på enheden til sletning i skyen

Selvfølgelig har alle større Cloud IoT-udbydere løsninger til klargøring – nogle mere modne end andre. Azure IoT Hub Device Provisioning Service er et eksempel på en stærk løsning.

Afhængigt af volumen på dine Medical Edge Devices og sikkerhedsniveauet, kræver sikring af data forskellige, etablerede og gennemprøvede strategier. For eksempel har sikring af sikker transmission fra sensor til sky velkendte løsninger fra industriområdet.

Brug af skyen som dataindsamlingssystem

Indsamling af resultater i en Cloud-database er ikke særlig interessant i forbindelse med denne artikel, da den “tilsigtede anvendelse” af denne typisk ikke falder ind under definitionen af ​​et medicinsk udstyr.

Brug af skyen som en integreret del af softwaresystemet

Det er her, det bliver svært. Men hvorfor vil du gerne gøre dette alligevel?

  • Du har muligvis en analysealgoritme, der kræver flere ressourcer, end din enhed leverer
  • Du tænker det kan være en god idé at bruge grænsefladerne fra Cloud Architecture
  • Du har muligvis en forretningsmodel, der kræver onlineadgang

I en verden af ​​realtidsenheder som EKG- og SpO2-skærme, pacemakere, kardiopulmonale bypass-maskiner (hjerte-lungemaskiner) eller anæstesi-arbejdsstationer, giver dette ingen mening. Hastigheden og pålideligheden af ​​internetadgang til skyen garanteres ikke. Mulige forsinkelser er i konflikt med behovet for hurtig responstid.

For enheder, der måler, analyserer og rapporterer (diagnosticerer) i en sekvens, der tager minutter, giver Cloud Architecture dog nogle åbenlyse fordele. Eksempler på dette er blodanalyseapparater til detektering af hjerte- og lungeabnormiteter. Typisk falder IVD’er (In vitro Diagnostics) enheder i denne kategori.

Men er du i stand til at flytte hjertet af denne diagnostiske enhed til skyen. Er det muligt? Er det blevet gjort?

Ja – det ser ud til at være muligt. Og ja – det er gjort.

Figur 1, Overvågning ved hjælp af Azure IoT, klik for info.

Microsoft henviser til en overvågningssag (digilog), hvor Azure IoT bruges som grundlag for offline-analysen.

Figur 2, spektrometer ved hjælp af AWS, klik for info.

RND Group refererer til en spektrometerløsning ved hjælp af Amazon Web Services.

Figur 3, Flex- og Google-samarbejde, klik her info.

Selv Google har en reference med en Medical Edge Device (eller i det mindste arkitekturen til den). Det store udvalg af sundhedsapps kan argumenterer for at falde inden for dette interval (selvom de fleste af dem ikke er blevet registreret som medicinsk udstyr).

Og ja, det er muligt at få en Cloud Based Architecture FDA godkendt.

Figur 4, Cloud DX, klik for info.

“Pulsewave er en unik pulsopsamlingsenhed, der registrerer op til 4.000 datapunkter fra din radiale arteriepuls, og derefter transmitterer det rå pulssignal sikkert til vores Cloud Diagnostics-servere, som viser næsten øjeblikkelige resultater: Puls, Blodtryk, Pulsvariation, Gennemsnitlig vejrtrækningshastighed*”.

At have de grundlæggende problemer vedrørende konfigurationskontrol af udviklingsværktøjer og SOUP-komponenter og klargøring af Medical Edge-enheder, kan de resterende problemer relateres til risikostyring. Eksempler på disse problemer er:

  • Hvilken offline-funktionalitet er påkrævet?
  • Hvordan sikrer vi dataintegritet i kommunikation af resultatet?
  • Hvordan mindsker vi ukendt opførsel af Cloud-platformen?

Det vil være interessant at følge, hvor godt Medical Device Community vil tilpasse alle de nye spændende muligheder, og hvordan dette vil påvirke den traditionelle forretning på markedet for medicinsk udstyr.

For mere information:

Partner Flemming von Holck, flemming.von.holck@glaze.dk, +45 30 66 30 61

Læs mere om hvordan generelle industrielle produkter og tilhørende cloud-tilkobling laves.