Helseapp med IoT og AWS: Casestudie

Helseindustrien opplever rask vekst og transformasjon, drevet av teknologiske fremskritt og endrede forbrukerpreferanser. Globale helseutgifter oversteg 8 billioner dollar i 2020 og forventes å fortsette å stige. Digitale investeringer skjøt i været til 57 milliarder dollar i 2021, med et betydelig fokus på telehelse og psykisk helse. Dessuten har det vært en økning i antall digitale helsestartups, med teknologigiganter som Amazon som utvider sin tilstedeværelse innen helsevesenet.En av drivkreftene bak denne transformasjonen er endrede atferd og preferanser blant helsebrukere. Pasienter søker i økende grad praktiske, tilgjengelige og personaliserte helseløsninger. Som et resultat har det vært en økning i bruken av telemedisin, bærbare enheter og helseapper, noe som lar enkeltpersoner overvåke helsen sin eksternt og ta proaktive tiltak for å håndtere velværet sitt.Regjeringer leder initiativer for å modernisere helsevesenet, med sikte på å eliminere papirarbeid og øke bruken av digitale teknologier. Investeringer i digital IT, som IoT i medisin, er på vei opp, og revolusjonerer pasientbehandling gjennom sanntids datainnsamling og fjernovervåking.Etter hvert som helseindustrien utvikler seg, spiller digital innovasjon en avgjørende rolle i å forbedre tilgangen til omsorg, øke pasientengasjementet og drive bedre helseresultater globalt. Alt i alt er vi i Jetbase stolte over å være en del av denne globale transformasjonen ved å utvikle innovative IT-prosjekter innen helsevesenet.I denne artikkelen er vi glade for å dele vår casestudie – et utviklingsprosjekt for medisinske nett- og mobilapper – i detalj, og fremheve utfordringer vi møtte, utviklingsløsninger, alt basert på en serverløs arkitektur fra AWS. Vennligst, nyt lesningen og ikke nøl med å dele om nødvendig.Om prosjektetProsjektet vårt integrerer en mobil og webbasert helseløsning med moduler som fjernpasientovervåking (RPM) og kronisk omsorgsbehandling (CCM).RPM-løsningen gir klinikker en webplattform for nær sanntids pasientovervåking og prediktiv analyse. Den samler inn dataavlesninger fra helseenheter koblet til IoT.CCM er en annen modul hvor leverandører for klinikker kan foreskrive medisiner, sette helse- og personlige mål, spore allergier og mer. Begge modulene strømlinjeformer administrative oppgaver og lagrer data sikkert.Fra brukerperspektivet lar webplattformen leger og annet medisinsk personell overvåke pasientenes helse i sanntid. Den sporer også legenes aktiviteter, lagrer alle datarapporter i systemet, og forenkler regningsbetaling. Samtidig gjør mobilappen pasienter i stand til å fjernovervåke helsen sin i sanntid, og utvider dette til familiemedlemmer for effektiv omsorg.Sammen bygger disse nett- og mobilutviklingsløsningene bro mellom helsepersonell og pasienter, og forbedrer fjernstyrt helsebehandling. Fortsett å lese for å lære hvordan vi i Jetbase lanserte prosjektet og har fortsatt å forbedre det frem til i dag.Kundens innspill og målKunden er en leverandør av helseenheter til klinikker. De kontaktet oss for omtrent 3,5 år siden for å fortsette arbeidet med eksisterende programvare koblet til enheter dedikert til å beregne fakturaer basert på avlesninger.Kundens mål var å lage en mobilapplikasjon for pasienter som bruker disse enhetene, og en nettapplikasjon for medisinsk personell og klinikkadministratorer for å spore pasientforhold og ansattes arbeid. Det var også viktig for kunden at prosjektet kunne skaleres i fremtiden.Per i dag er alle de opprinnelig satte målene oppnådd – prosjektet er lansert og fortsetter å utvikle seg. Målet for fremtiden er å transformere prosjektet til et Software as a Service (SaaS)-produkt og lansere det på det åpne markedet.Vårt prosjektengasjement (Hva gjorde vi – trinn for trinn)Først og fremst laget vi en MVP – et minimum levedyktig produkt. Deretter utførte vi testing, fikset feil. Alt dette tok omtrent 7 måneder. Det var under testfasen at produktet tok sin nåværende form. Totalt sett hjalp vi kunden med å skalere og lansere produktet, og vi fortsetter å støtte utviklingen frem til i dag.Sammen med kunden fortsetter vi å forbedre produktet. En av forbedringene inkluderer implementering av AI. For eksempel, i en situasjon der kritiske data mottas og rask respons er påkrevd, tillater vår tilkoblede tjeneste forhåndsskriving av et tekstsvar.Dette innebærer bruk av tilgjengelige data i systemet, som fullt navn og klinisk situasjon, samt malfraser for hilsener og avskjeder. Den viktigste informasjonen blir imidlertid alltid verifisert av legen før den sendes til pasienten. Dermed jobber AI og mennesker sammen.Nylig la vi også til en funksjon for å sende SMS-meldinger, og vi forbedrer den for tiden. Spesifikt lager vi et dashbord som lar legen få tilgang til pasientdata og, om nødvendig, sende en melding uten å forlate nettleseren (se illustrasjonen ovenfor).Det er en annen AI-tjeneste vi implementerte på kundens forespørsel. Dette er en tjeneste for å evaluere stemmetonen i meldinger. Det er viktig å vurdere kvaliteten på kommunikasjonen mellom medisinsk personell og pasienter.Hvilke funksjoner ble implementertVi er fortsatt i ferd med å implementere nye funksjoner, men her er en liste over de som allerede er implementert og testet:Hvorfor vi har valgt AWS Serverless Lambda-tjenester for dette helseprosjektetValget av AWS Lambda var åpenbart fordi du i dette tilfellet kun betaler for sekundene og megabytene du bruker. Og hvis det ikke er aktivitet, betaler du ikke. Dessuten trenger du ikke å betale for serveren, så du slipper å bekymre deg for den fordi AWS kontrollerer den automatisk. Den er lite krevende og kan håndtere mer enn hundre forespørsler. På grunn av AWS Serverless' on-demand-funksjon, trenger vi ikke å tenke på belastninger. Selvfølgelig, etter et visst punkt, kan vi nå grensene, men det vil være en annen historie.Det er også ulemper. Her er hva vår Jetbase-ekspert sier om dem og om valget av AWS Serverless generelt:“På den valgte veien vil det alltid være fordeler og ulemper. Så, ulempene med den serverløse AWS Lambda er dens begrensninger. For eksempel har den en grense på 15 minutter for kjøring, noe som betyr at hvis du har en prosess som kjører lenger enn 15 minutter, så sitter du fast. Du må tenke og finne en løsning, for eksempel å dele opp prosessen hvis mulig, eller du kan vurdere å bruke AWS Fargate, som også er en serverløs databehandlingsmotor, eller andre løsninger. En annen ulempe er at AWS Lambda også har begrensninger på minne. Så, avhengig av funksjonen du skal implementere, bør du kjenne disse grensene og håndtere dem…“ Shuhrat B. Full Stack Developer, Team Lead at JetbasePå vår reise møtte vi flere utfordringer, hvorav en var behandlingen av rapporter. Med et stort antall aktive brukere som genererte og sendte rapporter, ble prosessen tidkrevende og overskred 15-minuttersgrensen. For å overvinne denne hindringen vendte vi oss til Amazons Simple Queue Service (SQS), et kraftig verktøy som viste seg å være en game-changer.Løsningen vår involverte å dele opp rapportene og opprette en melding i SQS for hver aktiv bruker. I den andre enden av køen implementerte vi en håndterer som ville behandle og sende rapporter for individuelle brukere. Denne tilnærmingen reduserte behandlingstiden for rapportgenerering for brukere betydelig, noe som sikret at ingen rapport tok lengre tid enn 15 minutter å generere og sende. Da vi ikke hadde en streng tidsramme for sending av disse rapportene, tilfredsstilte denne valgte metoden oss og vår klient.Ved å utnytte SQS klarte vi å strømlinjeforme vår arbeidsflyt for rapportbehandling og forbedre den generelle effektiviteten i systemet vårt. Denne erfaringen fremhevet viktigheten av å utforske og utnytte de ulike tjenestene som tilbys av Amazon Web Services for å overvinne utfordringer og optimalisere ytelsen i våre prosjekter.Noen fordeler og ulemper med AWS serverløs server for ditt helse-IT-prosjektAWS serverløse tjenester er gunstige for ditt helse-nettutviklingsprosjekt fordi:Det er kostnadseffektivt – du betaler kun for ressursene som brukes, målt i sekunder og megabyte.Det er skalerbart – skjønnheten i automatisert skalerbarhet kan ikke overvurderes, da ressurser tildeles basert på etterspørsel, noe som sikrer optimal bruk.Infrastruktur kan administreres – AWS håndterer servervedlikehold og skalering, noe som reduserer driftsbelastningen.Det er imidlertid faktorer å vurdere når du bruker AWS serverløse tjenester for ditt helse-IT-prosjekt:Ressursbegrensninger – enkelte oppgaver har tidsbegrensninger, noe som potensielt kan begrense kontinuerlige eller langvarige prosesser.Latensproblemer – komplekse operasjoner eller storskala databehandlingsoppgaver kan oppleve forsinkelser.Avhengighet av AWS-systemer globalt – Avhengighet av AWS-tjenester kan føre til leverandørlåsning og begrenset fleksibilitet på lang sikt.Til tross for ulempene foretrekker vi å velge AWS serverløse løsninger for helse-IT-prosjekter fordi mange års erfaring har vist dens effektivitet og stabilitet.Hvordan infrastrukturbyggingsprosessen ble gjennomførtI begynnelsen av prosjektet skisserte kunden flere nøkkelkrav. For eksempel uttrykte de behovet for umiddelbare varsler når en pasient registrerer seg – noe som muliggjør rask utsendelse av enheter.Når det gjelder valg av arkitektur, kunne kunden gi innspill, men vi foreslo vår egen versjon. For eksempel, for å håndtere store mengder avlesninger og handlinger (som anrop og kommentarer), foreslo vi impleSom vist i diagrammet, kan leger starte telefonsamtaler fra dashbordet – i dette tilfellet vil Amazon Connect SDK bli lansert for å koble pasienter med medisinske spesialister. Det er avgjørende for oss å spore samtaledetaljer som varighet for fakturaberegninger og samtaletranskripsjon for å analysere pasienttilfredshet.Systemet vårt må nøyaktig spore og registrere samtaler, og oppnå nær 100 % nøyaktighet, da dette er en kritisk funksjon. Derfor, som et team, anbefalte vi å bruke en kø-tilnærming for å få kontroll over systemet, noe som muliggjør funksjoner som forsøk på nytt ved feil eller lagring av mislykkede meldinger for senere handling.Hvilke tjenester ble integrert i prosjektetI prosjektet er det så mange integrasjoner med andre tjenester at det er umulig å liste opp alle. Her er bare noen av dem:Twilio — en SMS-tjeneste som brukes til å sende meldinger til brukere. Monday — en brukerregistreringstjeneste. Tray — brukes til å automatisere arbeidsflyter, som for eksempel sending av rapporter. Stitch — en ETL-tjeneste (Extract, Transform, Load) for integrering og behandling av Big Data. Mens vi tilrettelegger for integrasjon med Stitch, tilbyr de også sitt eget verktøy for datainnhenting og analyse. Azure ChatGPT — en tjeneste som brukes til å analysere avlesninger og gi kommentarer. Auth0 — en autorisasjons- og autentiseringstjeneste. Files.com — en tjeneste for fillagring og rapportering.Hvordan vi jobbet med helse-IoT-enheter for datasporingEssensen i prosjektet dreier seg om å overføre data fra helseenheter via serveren til applikasjonene. Disse filtrerte dataene er deretter tilgjengelige for både leger og pasienter, samt klinikkagenter og forsikringsselskaper, som trenger å ha oversikt og motta rapporter.Dataoverføring skjer nesten i sanntid, noe som gjør at medisinsk personell kan gripe inn raskt i nødstilfeller. Det hjelper også pasienter med å spare tid og penger de vanligvis ville brukt på å reise til klinikker og medisinske fasiliteter.I vårt tilfelle ble ulike enheter koblet til, som for eksempel:— Fjernpasientovervåking — Blodglukosemålere — Falldeteksjonsenheter — Pulsoksymetre — Blodtrykksmålere — Smarte termometre — Treningsmålere — Vekt — SøvnmatterVi møtte ingen problemer med integreringen av dem, bortsett fra kanskje med synkroniseringen av tidspunktene for datainnsamling. For eksempel sendte noen enheter data i henhold til pasientenes tidssoner, mens andre brukte UTC. Vi måtte løse dette problemet for å sikre datanøyaktighet.Når det gjelder organisering og lagring av data, brukte vi Amazon DynamoDB, som skalerer i henhold til datavolumet, enten det er mindre eller mer, uten å kompromittere systemeffektiviteten. Det er ingen ventetid for tilpasning. Hele flyten og arkitekturen er demonstrert i diagrammet.En annen tjeneste vi integrerte for praktisk databehandling er Elasticsearch, som hjelper til med raskt å finne spesifikke avlesninger eller andre data. Tjenesten hjelper også med å analysere data intelligent og raskt.IoT tilbyr sanntids dataovervåkings- og sporingsmuligheter, noe som gjør at helseapper kan gi rettidige innsikter i pasienters helsetilstander. Ved å integrere IoT-teknologi kan helseapper forbedre fjernpasientovervåking, forbedre behandlingsetterlevelse og forenkle tidlig oppdagelse av helseproblemer, noe som til syvende og sist fører til bedre pasientresultaterHvilke problemer var det på utviklerens sideVi møtte absolutt noen utfordringer. Vi er ikke redde for å diskutere dem fordi de alle er løst. For eksempel, som nevnt tidligere, møtte vi vanskeligheter med synkroniseringen av tidspunktene for datainnsamling. Det var avgjørende å løse dette problemet for å sikre datanøyaktighet.— Forsinkelse i avlesningsfangstVidere, på grunn av enhetslatens, begynte vi å motta noen avlesninger svært sent, noen ganger til og med avlesninger fra forrige uke. Dette skapte forvirring blant både leger og pasienter, da avlesninger mottatt i dag ble vist som dagens avlesninger, til tross for at de ble tatt en uke tidligere.— Problemer med innkommende anropVi møtte problemer med innkommende anrop fra ukjente telefonnumre (dvs. telefonnumre som ikke er registrert i systemet vårt). I slike tilfeller utviklet vi en løsning for å spore disse anropene etter pasient-ID, som leger eller agenter kan implementere under samtalen. Følgelig har vi etablert en semi-automatisert prosess for å spore anrop fra ukjente numre og jobber fortsatt med å løse problemet.— Problemer med datatap Etter hvert som antall aktive pasienter økte, møtte vi problemer med å miste noen avlesninger. Uventede feil oppsto, noe som hindret oss i å transformere avlesningsdataene og vise dem i brukergrensesnittet.— Problemer med rapportdistribusjonVi møtte også utfordringer med rapportdistribusjon. Opprinnelig mottok bare 30-50 av 500 klinikker rapporter. Vi har imidlertid siden løst dette problemet, og nå distribueres alle rapporter den 1. i hver måned. Selv om denne prosessen fortsatt tar tid – fra tidlig morgen til klokken 18.00, omtrent 4-5 timer – blir den fullført innenfor en enkelt arbeidsdag. Hvis antall klinikker overstiger 500, vil vi håndtere situasjonen deretter.Når det gjelder pasienter, er det titusenvis, og vi har lykkes med å sende rapporter til alle innen en enkelt dag. Videre er vår klient fornøyd selv om det er flere dagers forsinkelse.KonklusjonerVi håper vår casestudieartikkel har vært nyttig for deg. Vi ønsket å gi transparent informasjon om opprettelsen av vår digitale helseløsning for IoT-systemet, og detaljere utfordringene vi møtte og hvordan vi overvant dem. I tillegg skisserte vi tjenestene vi brukte og forklarte hvorfor vi valgte AWS Lambda serverløse tjenester for vårt medisinske nettutviklingsprosjekt.Med mange års erfaring innen helseutvikling forstår vi finessene og kompleksiteten ved å bygge robuste og skalerbare løsninger. Hvis du vurderer å starte et medisinsk prosjekt eller trenger hjelp med programvareutvikling for helsevesenet, er vi godt rustet til å tilby vår ekspertise og støtte. Ta gjerne kontakt med oss for konsultasjon og samarbeid om din neste helseinnovasjonsreise.Og hvis du trenger ytterligere veiledning om helseutvikling, vær oppmerksom på at vi har en spesiallaget guide, 'Helseutviklingskostnader 2025', som vil hjelpe deg med å få innsikt i budsjettering og investeringer.

Helseapp med IoT og AWS: Casestudie

Våre Caser

Siste Artikler

En komplett guide til implementering av mikrotjenester på AWS

Outsourcing av programvareutvikling i 2025: En komplett guide

Legetime-app utviklingsguide (2025)