Sundhedsapp med IoT og AWS: Casestudie

Sundhedsindustrien oplever en hurtig vækst og transformation, drevet af teknologiske fremskridt og ændrede forbrugerpræferencer. Globale sundhedsudgifter oversteg 8 billioner dollars i 2020 og forventes at fortsætte med at stige. Digitale investeringer steg til 57 milliarder dollars i 2021, med et betydeligt fokus på telemedicin og mental sundhed. Desuden har der været en stigning i antallet af digitale sundheds-startups, med tech-giganter som Amazon, der udvider deres tilstedeværelse inden for sundhedssektoren.

En af drivkræfterne bag denne transformation er den skiftende adfærd og præferencer hos sundhedsforbrugerne. Patienter søger i stigende grad praktiske, tilgængelige og personaliserede sundhedsløsninger. Som følge heraf er brugen af telemedicin, bærbare enheder og sundhedsapps steget, hvilket giver enkeltpersoner mulighed for at overvåge deres helbred eksternt og tage proaktive foranstaltninger for at styre deres velbefindende.

Regeringer står i spidsen for initiativer til at modernisere sundhedssystemet med det formål at eliminere papirarbejde og øge brugen af digitale teknologier. Investeringer i digital IT, såsom IoT inden for medicin, er stigende og revolutionerer patientplejen gennem dataindsamling i realtid og fjernovervågning.

Efterhånden som sundhedsindustrien udvikler sig, spiller digital innovation en afgørende rolle i at forbedre adgangen til pleje, øge patientengagementet og fremme bedre sundhedsresultater verden over. Alt i alt er vi hos Jetbase stolte over at være en del af denne globale transformation ved at udvikle innovative IT-projekter inden for sundhedssektoren.

I denne artikel er vi glade for at dele vores casestudie – et projekt for udvikling af medicinske web- og mobilapps – i detaljer, hvor vi fremhæver opståede problemer, udviklingsløsninger, alt baseret på en serverløs arkitektur fra AWS. God læselyst, og tøv ikke med at dele, hvis det er nødvendigt.

Vores projekt integrerer en mobil og webbaseret sundhedsløsning med moduler såsom Remote Patient Monitoring (RPM) og Chronic Care Management (CCM).

RPM-løsningen giver klinikker en webplatform til næsten-realtidspatientovervågning og prædiktiv analyse. Den indsamler datamålinger fra sundhedsenheder forbundet til IoT.

CCM er et andet modul, hvor udbydere til klinikker kan ordinere medicin, sætte sundheds- og personlige mål, spore allergier og mere. Begge moduler strømliner administrative opgaver og lagrer data sikkert.

Fra et brugeroplevelsesperspektiv giver webplatformen læger og andre medicinske medarbejdere mulighed for at overvåge patienters helbred i realtid. Den sporer også lægers aktiviteter, gemmer alle datarapporter i systemet og letter betaling af regninger. I mellemtiden gør mobilappen patienter i stand til fjernovervåge deres helbred i realtid, og udvider dette til familiemedlemmer for effektiv pleje.

Sammen forbinder disse web- og mobiludviklingsløsninger sundhedsudbydere og patienter og forbedrer fjernstyret sundhedspleje. Læs videre for at lære, hvordan vi hos Jetbase lancerede projektet og fortsat har forbedret det til i dag.

Klienten er leverandør af sundhedsenheder til klinikker. De kontaktede os for omkring 3,5 år siden for at fortsætte arbejdet med eksisterende software forbundet til enheder dedikeret til at beregne fakturaer baseret på målinger.

Klientens mål var at skabe en mobilapplikation til patienter, der bruger disse enheder, og en webapplikation til medicinsk personale og klinikadministratorer for at spore patientforhold og personalets arbejde. Det var også vigtigt for klienten, at projektet kunne skaleres i fremtiden.

Pr. i dag er alle oprindeligt fastsatte mål nået – projektet er lanceret og fortsætter med at udvikle sig. Målet for fremtiden er at omdanne projektet til et Software as a Service (SaaS) produkt og frigive det til det åbne marked.

Først og fremmest skabte vi en MVP – minimum viable product. Derefter udførte vi test, rettede fejl. Alt dette tog omkring 7 måneder. Det var under testfasen, at produktet blev formet til dets nuværende form. Samlet set hjalp vi klienten med at skalere og lancere produktet, og vi fortsætter med at understøtte dets udvikling den dag i dag.

Sammen med klienten fortsætter vi med at forbedre produktet. En af forbedringerne inkluderer implementering af AI. For eksempel, i en situation hvor kritiske data modtages, og et hurtigt svar er påkrævet, tillader vores tilsluttede service en forudskrivning af et tekstsvar.

Dette involverer brug af tilgængelige data inden for systemet, såsom fulde navn og klinisk situation, samt standardsætninger til hilsner og afskeder. Dog verificeres den væsentlige information altid af lægen, før den sendes til patienten. Således arbejder AI og mennesker sammen.

For nylig tilføjede vi også en funktion til at sende SMS-beskeder, og vi forbedrer den i øjeblikket. Specifikt er vi ved at oprette et dashboard, der giver lægen adgang til patientdata og, om nødvendigt, sende en besked uden at forlade browseren (se illustrationen ovenfor).

Der er en anden AI-tjeneste, som vi implementerede på klientens anmodning. Dette er en tjeneste til evaluering af stemmelejet i beskeder. Det er vigtigt at vurdere kvaliteten af kommunikationen mellem medicinske fagfolk og patienter.

Vi er stadig i gang med at implementere nye funktioner, men her er en liste over dem, der allerede er implementeret og testet:

Hvorfor vi har valgt AWS Serverless Lambda-tjenester til dette sundhedsprojekt

Valget af AWS Lambda var indlysende, fordi du i dette tilfælde kun betaler for de sekunder og megabytes, du bruger. Og hvis der ikke er nogen aktivitet, betaler du ikke. Du behøver heller ikke at betale for serveren, så du behøver ikke bekymre dig om det, fordi AWS styrer det automatisk. Det er undemanding og kan håndtere mere end hundrede anmodninger. På grund af den on-demand-funktion i AWS Serverless behøver vi ikke at tænke på belastninger. Selvfølgelig, efter et vist punkt, kan vi ramme grænserne, men det er en anden historie.

Der er også ulemper. Her er, hvad vores Jetbase-ekspert siger om dem og om valget af AWS Serverless generelt:

“På den valgte vej vil der altid være fordele og ulemper. Så ulemperne ved serverløs AWS Lambda er dens grænser. For eksempel har den en grænse på 15 minutter for kørsel, hvilket betyder, at hvis du har en proces, der kører mere end 15 minutter, så sidder du fast. Du skal tænke og finde en løsning, såsom at opdele processen, hvis det er muligt, eller du kan overveje at bruge AWS Fargate, som også er en serverløs computing-motor, eller andre løsninger. En anden ulempe er, at AWS Lambda også har grænser for hukommelse. Så afhængigt af den funktion, du skal implementere, bør du kende disse grænser og tackle dem…“ Shuhrat B. Full Stack Developer, Team Lead hos Jetbase

På vores rejse stødte vi på flere udfordringer, hvoraf en var behandlingen af rapporter. Med et stort antal aktive brugere, der genererede og sendte rapporter, blev processen tidskrævende og overskred den 15-minutters grænse. For at overvinde denne hindring vendte vi os mod Amazons Simple Queue Service (SQS), et stærkt værktøj, der viste sig at være en game-changer.

Vores løsning involverede at opdele rapporterne og oprette en meddelelse i SQS for hver aktiv bruger. I den anden ende af køen implementerede vi en handler, der ville behandle og sende rapporter for individuelle brugere. Denne tilgang reducerede behandlings tiden for rapportgenerering til brugere betydeligt, hvilket sikrede, at ingen rapport tog længere end 15 minutter at generere og sende. Da vi ikke havde en streng tidsramme for afsendelse af disse rapporter, tilfredsstillede denne valgte metode os og vores klient.

Ved at udnytte SQS var vi i stand til at strømline vores arbejdsgang for rapportbehandling og forbedre systemets overordnede effektivitet. Denne oplevelse fremhævede vigtigheden af at udforske og udnytte de forskellige tjenester, der tilbydes af Amazon Web Services, for at overvinde udfordringer og optimere ydeevnen i vores projekter.

Nogle fordele og ulemper ved AWS serverløs server til dit sundheds-IT-projekt

AWS serverløse tjenester er gavnlige for dit webudviklingsprojekt inden for sundhedspleje, fordi:

• Det er omkostningseffektivt – behøver kun at betale for anvendte ressourcer, målt i sekunder og megabytes.
• Det er skalerbart – skønheden ved automatiseret skalerbarhed kan ikke overvurderes, da ressourcer allokeres baseret på efterspørgsel, hvilket sikrer optimal brug.
• Infrastruktur kan administreres – AWS håndterer servervedligeholdelse og skalering, hvilket reducerer den operationelle byrde.

Der er dog faktorer at overveje, når du bruger AWS serverløse tjenester til dit sundheds-IT-projekt:

• Ressourcebegrænsninger – nogle opgaver har tidsbegrænsninger, hvilket potentielt begrænser kontinuerlige eller langvarige processer.
• Latensbekymringer – komplekse operationer eller store databehandlingsopgaver kan opleve visse forsinkelser.
• Afhængighed af AWS-systemer globalt – Afhængighed af AWS-tjenester kan føre til vendor lock-in og begrænset fleksibilitet på lang sigt.

På trods af ulemperne foretrækker vi at vælge AWS serverløs til sundheds-IT-projekter, fordi års erfaring har vist dens effektivitet og stabilitet.

Ved projektets start skitserede klienten flere nøglekrav. For eksempel udtrykte de behovet for øjeblikkelige notifikationer, når en patient registrerer sig – hvilket muliggør hurtig afsendelse af enheder.

Vedrørende valg af arkitektur kunne klienten give input, men vi foreslog vores egen version. For eksempel, for at håndtere store mængder af målinger og handlinger (såsom opkald og kommentarer), foreslog vi imple

Som vist i diagrammet kan læger starte telefonopkald fra dashboardet – i dette tilfælde vil Amazon Connect SDK blive lanceret for at forbinde patienter med medicinske specialister. Det er afgørende for os at spore opkaldsdetaljer såsom varighed for faktureringsberegninger og opkaldstranskription for at analysere patienttilfredshed.

Vores system skal nøjagtigt spore og registrere opkald og opnå næsten 100 % nøjagtighed, da dette er en kritisk funktion. Derfor anbefalede vi som team at anvende en køtilgang for at få kontrol over systemet, hvilket muliggør funktioner som genforsøg ved fejl eller lagring af mislykkede meddelelser til senere handling.

Hvilke tjenester blev integreret i projektet

I projektet er der så mange integrationer med andre tjenester, at det er umuligt at liste dem alle. Her er blot et par af dem:

Twilio — en SMS-tjeneste, der bruges til at sende beskeder til brugere. Monday — en brugerregistreringstjeneste. Tray — bruges til at automatisere arbejdsgange, såsom afsendelse af rapporter. Stitch — en ETL (Extract, Transform, Load) tjeneste til integration og behandling af Big Data. Mens vi letter integrationen med Stitch, leverer de også deres eget værktøj til datahentning og analyse. Azure ChatGPT — en tjeneste, der bruges til at analysere aflæsninger og give kommentarer. Auth0 — en autorisation- og autentificeringstjeneste. Files.com — en tjeneste til fillagring og rapportering.

Essensen af projektet drejer sig om at transmittere data fra sundhedsenheder via serveren til applikationerne. Disse filtrerede data er derefter tilgængelige for både læger og patienter, samt klinikagenter og forsikringsselskaber, der har brug for et overblik og modtage rapporter.

Datatransmission sker tæt på realtid, hvilket gør det muligt for medicinsk personale at gribe hurtigt ind i nødsituationer. Det hjælper også patienter med at spare tid og penge, de typisk ville bruge på at rejse til klinikker og medicinske faciliteter.

I vores tilfælde blev forskellige enheder tilsluttet, såsom:

— Fjernovervågning af patienter — Blodsukkermålere — Faldregistrering — Pulsoximetre — Blodtryksmålere — Smarte termometre — Fitness-trackere — Vægt — Søvnmåtte

Vi stødte ikke på problemer med deres integration, bortset fra måske med synkroniseringen af aflæsningsindsamlingstider. For eksempel sendte nogle enheder data i henhold til patienternes tidszoner, mens andre brugte UTC. Vi måtte løse dette problem for at sikre datanøjagtighed.

Med hensyn til organisering og lagring af data anvendte vi Amazon DynamoDB, som skalerer i henhold til datavolumen, uanset om det er mindre eller mere, uden at kompromittere systemeffektiviteten. Der er ingen ventetid for tilpasning. Hele flowet og arkitekturen er demonstreret i diagrammet.

En anden tjeneste, vi integrerede for bekvem datastyring, er Elasticsearch, som hjælper med hurtigt at finde specifikke aflæsninger eller andre data. Tjenesten hjælper også med at analysere data intelligent og hurtigt.

IoT tilbyder realtidsdatamonitorering og sporingsmuligheder, hvilket gør det muligt for sundhedsapps at give rettidige indblik i patienters helbredstilstande. Ved at integrere IoT-teknologi kan sundhedsapps forbedre fjernovervågning af patienter, forbedre behandlingscompliance og lette tidlig opdagelse af sundhedsproblemer, hvilket i sidste ende fører til bedre patientresultater.

Hvad var problemerne fra udviklernes side

Ja, vi stod over for nogle udfordringer. Vi er ikke bange for at diskutere dem, fordi de alle er blevet løst. For eksempel stødte vi, som nævnt tidligere, på vanskeligheder med synkroniseringen af aflæsningsindsamlingstider. Det var bydende nødvendigt at løse dette problem for at sikre datanøjagtighed.

— Forsinkelse i aflæsningsopsamling

Desuden begyndte vi på grund af enhedens latenstid at modtage nogle aflæsninger meget sent, nogle gange endda aflæsninger fra den foregående uge. Dette forårsagede forvirring blandt både læger og patienter, da aflæsninger modtaget i dag blev vist som dagens aflæsninger, selvom de var taget en uge tidligere.

— Problemer med indgående opkald

Vi stødte på problemer med indgående opkald fra ukendte telefonnumre (dvs. telefonnumre, der ikke er registreret i vores system). I sådanne tilfælde udviklede vi en løsning til at spore disse opkald efter patient-ID, som læger eller agenter kan implementere under opkaldet. Følgelig har vi etableret en semi-automatiseret proces til sporing af opkald fra ukendte numre og arbejder stadig på at løse problemet.

— Problemer med datatab Efterhånden som antallet af aktive patienter steg, stødte vi på problemer med at miste nogle aflæsninger. Uventede fejl opstod, hvilket forhindrede os i at transformere aflæsningsdataene og vise dem i brugergrænsefladen.

— Problemer med rapportdistribution

Vi stod også over for udfordringer med rapportdistribution. I starten modtog kun 30-50 ud af 500 klinikker rapporter. Vi har dog siden løst dette problem, og nu distribueres alle rapporter den 1. i hver måned. Selvom denne proces stadig tager tid – fra tidlig morgen til kl. 18 om aftenen, omkring 4-5 timer – fuldføres den inden for en enkelt arbejdsdag. Hvis antallet af klinikker overstiger 500, vil vi håndtere situationen derefter.

Hvad angår patienter, er der titusindvis, og vi har med succes formået at sende rapporter til dem alle inden for en enkelt dag. Desuden er vores klient tilfreds, selvom der er flere dages forsinkelse.

Vi håber, at vores casestudieartikel har været nyttig for dig. Vi sigtede mod at give gennemsigtig information om oprettelsen af vores digitale sundhedsløsning til IoT-systemet, og detaljerer de udfordringer, vi stødte på, og hvordan vi overvandt dem. Derudover skitserede vi de tjenester, vi anvendte, og forklarede, hvorfor vi valgte AWS Lambda serverløse tjenester til vores medicinske webudviklingsprojekt.

Med mange års erfaring inden for sundhedsudvikling forstår vi de indviklede detaljer og kompleksiteten ved at bygge robuste og skalerbare løsninger. Hvis du overvejer at starte et medicinsk projekt eller har brug for assistance med udvikling af sundhedssoftware, er vi godt rustet til at tilbyde vores ekspertise og support. Du er velkommen til at kontakte os for konsultation og samarbejde om din næste rejse inden for sundhedsinnovation.

Og hvis du har brug for yderligere vejledning om sundhedsudvikling, bedes du bemærke, at vi har en specialfremstillet 'Healthcare Development Cost 2025'-guide, der hjælper dig med at få indsigt i budgettering og investeringer.