IoT Platform til opkoblet medicinsk udstyr

Værdiskabelse:

Der er grundlæggende fire grunde til at opkoble medicinsk udstyr:

  • Aktivering af fjernovervågning af status eller position på jeres medicinske udstyr
  • Anvendelse af skyen til dataindsamling til analyse af brug og tilstand af jeres medicinske enheder
  • Udnyttelse af Azure’s IoT edge management til at enhedskonfigurere jeres medicinske udstyr
  • Brug integration til skyen og øvrig dataintegration til at adressere den tilsigtede anvendelse af medicinsk udstyr

Udfordring:

Hvor fjernovervågning, dataindsamling og enhedskonfiguration til medicinsk udstyr er meget lig de samme typer anvendelser man ser inden for generelle IoT-produkter, smartproduktion, er selve det at adressere den tilsigtede brug af medicinsk udstyr i kernearkitekturen på samme tid problematisk og attraktivt, fordi:

  • Hvad er bedste best practice for softwarearkitektur i medicinsk udstyr med skyintegration?
  • Hvordan sikres overholdelse af 62304 / 82304-1 i medicinsk udstyr med skyintegration?
  • Hvordan håndteres designkontrol og ændringskontrol i medicinsk udstyr med skyintegration?

Sådan passer Beacon Tower:

Beacon Tower-arkitekturen er baseret på mange års erfaring med at opbygge IoT-platforme. Den gør brug af velafprøvede Azure-tjenester, der sikrer en stabil, skalérbar og højt ydende løsning.

Ved at bruge Beacon Tower kan I fokusere på de unikke funktioner i jeres produktudvikling, mens vi sikrer, at jeres Beacon Tower Accelerator understøtter de ressourcer, der er defineret i softwaredesignet af jeres medicinske udstyr.

Best Practices

Her følger nogle typiske eksempler på skyintegration i et medicinsk apparat:

1. Udnyttelse af de ubegrænsede skyressourcer som supplement til de begrænsede ressourcer i medicinsk udstyr:

Medicinsk udstyr er systemets hovedcontroller. De målte data sendes til skyen til analyse og udvinding af data, vitale markører eller biomarkører, sendes tilbage til præsentation.

2. Brug af cloud-ressourcer som hovedcontroller for medicinsk udstyr:

Skyen kontrollerer systemets funktionalitet. Det medicinske udstyr leverer data til skyen. En smartphone- eller desktop-app fungerer som brugergrænseflade til systemet.

3. Brug af Cloud Data Management som grænseflade til Hospital / Laboratory Information Systems (HIS / LIS).

Vitale markører eller biomarkører sendes til skyen, der håndterer overførslen af disse til eksterne systemer.

4. Brug af skyen til kopibeskyttelse:

Hver enkelt brugsartikel skal godkendes af systemet i skyen baseret på det unikke ID til engangsartikler (RFID, stregkode eller lignende).

5. Brug skyen som væsentlig del af forretningsmodellen:

Forretningsmodellen er baseret på afregning pr. prøve/anvendelse. Brug af medicinsk udstyr rapporteres til forretningssystemet i skyen.

62304/82304-1 compliance:

Da Beacon Tower-komponenter er udviklet uden for brugen af jeres QMS (Quality Management System), betragtes de som SOUP (software of unknown provenance) i 62304 termer.

Når vi sammen designer det samlede system, er det en stor fordel at de anvendte komponenter i Beacon Tower har en allerede veldefineret funktionalitet og grænseflader. Dette giver en god basislinje for overholdelse af 62304/82304 klasse A og klasse B softwaresystemer.

Design- og ændringskontrol: :

I ethvert medicinsk udstyrsprojekt er det afgørende at etablere og kontrollere en stabil konfiguration af velprøvede komponenter. Verifikation og validering i henhold til 62304 og 82304-1 er tidskrævende.

Ved hjælp af Beacon Tower Accelerator har I fuld kontrol over konfigurationen. Beacon Tower giver de nødvendige detaljer til planlægning af ændringerne. Men planlægningen af ændringer styres af jeres QMS.

Beacon Tower funktioner der understøtter opkoblet medicinsk udstyr

 

Ingen leverandør lock-in

Hardware lock-in i en medicinsk enhed er ikke noget nyt. I de tidlige stadier af udviklingen af et nyt medicinsk apparat vælges platformsarkitekturen. I denne proces identificeres nøglekomponenter, kritiske komponenter, såsom CPU’en, skærmen og strømforsyningen.
Af særlig interesse for dette valg er identifikationen af komponenter fra anden kilde (second source). Hvis produktionen af en kritisk komponent stopper, er det vigtigt at have en plan B – en anden kilde.
Lock-in via softwareleverandører er noget nyt, som I skal overveje, når I tillader skyintegration i jeres medicinske enhed. Som I ville gøre for jeres kritiske komponenter, bør I identificere en anden kilde til jeres cloud -software. Ved hjælp af Beacon Tower fra Glaze kan har I fuld adgang og kontrol over applikationen og miljøet. Dette gør det muligt at fortsætte med en anden leverandør – som kan være enhver virksomhed, der har erfaring med Microsoft Azure IoT og som findes i alle dele af kloden.

Adgangskontrol

Et typisk brugsscenarie er at gemme trenddata i skyen. Beacon Tower giver jer fuld kontrol over adgangen til trenddata for jeres systemaktører – brugere, organisationer eller eksterne systemkomponenter.
Via Beacon Towers fleksible adgangskontrol kan I ikke kun modellere jeres egen organisation, men også jeres kunders. I kan give dem direkte adgang til systemet og definere nøjagtigt, hvilke assets de kan se, og give dem rettigheder. Adgang kan indstilles til enkelt enheder eller grupper til f.eks. at give adgang til at læse data eller til at kunne kontrollere udvalgte IoT-enheder.

Telemetri i realtid

Realtids telemetri-behandling er kernen i Beacon Towers signalbehandling. Det giver jer mulighed for at oprette regler, der udløser alarmer eller handlinger inden for millisekunder fra modtagelse af signalet.

Virtuelle signaler

Identificér og udtræk vital indsigt fra jeres signaler, og kombinér dem, eller brug dem til alarmnotifikationer.
Beacon Tower giver en platform til kontrolleret dataanalyse, ekstraktion og aggregering.
Virtuelle signaler giver jer mulighed for at oprette nye signaler ved at anvende algoritmer på eksisterende signaler eller ved at kombinere flere signaler til et nyt. Det virtuelle signal sendes derefter den samme rute som alle andre signaler, hvilket betyder, at både det og kildesignalet lagres som telemetri, og I kan anvende regler og alarmer på det.

Regler og alarmer

Opret regler, der anvendes direkte på streaming realtidsdata. Reglerne kan enten være enkle tærskelværdier der udløser alarmer, når sensorværdier trigger reglen, eller komplekse regler baseret på flere forskellige sensorværdier og algoritmer.
Reglerne kan enten starte handlinger, udløse alarmer eller generere nye signaler. Alarmerne kan have varierende niveauer og kan underrette forskellige brugergrupper.

Visualisering

Brug Beacon Towers muligheder for datavisualisering for at diagnosticere patienter.
Visualisering af telemetri i grafer giver jer mulighed for at se tendenser, sammenligne signaler og forstå jeres medicinske apparater.

Hvordan kommer vi i gang med at opkoble medicinsk udstyr?

01

Start

I har en idé om jeres systemsoftwarearkitektur, og I er begyndt at lede efter kommercielt tilgængelige løsninger, der kan passe ind. I vil opdage, at I har to generelle muligheder:

1. Find en færdig løsning, der tilsluttes jeres arkitektur og opfylder alle krav. Hvis dette er muligt, er det langt den bedste løsning – det er hurtigt og nemt.Beacon Tower SaaS er en af mange muligheder, der kan levere dette.
2. Find en baseline, der kan integreres i jeres arkitektur og tilpasses til at imødekomme jeres krav. Dette er en mere realistisk tilgang og giver en stærk og robust arkitektonisk baseline for jeres produkts livscyklus
(SCL: Software Life Cycle).

Beacon Tower er unikt plositioneret til at tilbyde overgang mellem
1) SaaS og 2) Accelerator-løsningen med minimal indsats.

01

Hvordan vi kan hjælpe med den regulatoriske tilgang

Vi kan hjælpe jer med at etablere den rigtige systemarkitektur og korrekte regulatoriske tilgang for at opnå 62304/82304 overholdelse af jeres softwaresystemer. Dette er en af de vigtigste beslutninger i jeres projekt, da det vil have stor indflydelse på projektet og enhedens livscyklus i de kommende år. Beslutningerne er baseret på en analyse af tilsigtet anvendelse, vigtige funktioner, patientrisiko, projektrisiko og tilgængelige softwarekomponenter. Vi har mange års erfaring med dette og kan hjælpe jer med at finde den bedste løsning.

02

Pilot og indledende lancering

Når I kører det første Proof-of-Concept og pilotprojekt, vil I adressere tekniske eller patient-risici. Hvis I har en indledende vurdering af patient, brugervenlighed, software eller cyber-risici, er dette et godt udgangspunkt. I vil gerne etablere et basissystem, der
A) Opfylder jeres tilsigtede anvendelse
Den tilsigtede anvendelse er ofte baseret på ganske enkle algoritmer og er lette at integrere ved hjælp af standard Beacon Tower-konfiguration.
B) Adresserer uacceptable risici fra jeres indledende risikoanalyse
Det kan være nødvendigt at implementere løsninger der håndterer følsomme data eller algoritmer, vigtige brugergrænseflader eller særlig adgangskontrol eller kryptering.

Frem for alt tilbyder Beacon Tower tilpasningsmuligheder. Veldokumenterede API’er og ”managed” og fleksible komponenter med en åben platformstilgang gør at pilotprojekter og PoC’er er relativt lette at implementere.

02

Hvordan Beacon Tower sikrer en effektiv baseline

Overholdelse af regulativer er obligatorisk. Men alt for ofte ender teknologien med at være den kritiske del af det nye medicinske udstyr. Med Beacon Tower har I teknologi, der fungerer, og I kan hurtigt bygge en PoC. Integration med jeres systemer og nødvendige tilpasninger er lette at gennemføre, og vi vil altid have overholdelse af regulatoriske krav som en forudsætning i vores arbejde.

03

Designkontrol og compliance

Da Beacon Tower-komponenter er udviklet uden for brug af jeres QMS (Quality Management System), betragtes de som SOUP (software of unknown provenance) i 62304 termer.
Beacon Tower-komponenter har veldefinerede funktionaliteter og grænseflader. De er selvstændige testbare tjenester med fuld versionskontrol. Baseret på jeres patient-, brugervenlighed-, software- og cyber-risikovurderinger gør det det relativt ligetil at evaluere Beacon Tower SOUP-komponenter inden for risikoprocessen og dermed opfylde kravene til 62304/82304 klasse A og klasse B softwaresystemer.

03

Hvordan Beacon Tower hjælper jer med at skalere

Beacon Towers arkitektur, funktioner og infrastruktur er designet til at kunne skaleres fra nogle få enheder til flere tusinder. Ikke kun fra et kapacitetsmæssigt synspunkt, men også ved at levere funktionalitet, som I muligvis først har brug for i en storstilet udrulning. Vi har et stort sæt automatiserede tests, der verificerer funktionalitet. Vi overvåger alle komponenter og gør brug af Microsoft Azures funktioner for at opretholde kvaliteten ved skalering. Alt dette gør det muligt for Beacon Tower at være en oplagt skyplatform gennem hele jeres medicinske produkts livscyklus.