Hälsovårdsapp med IoT & AWS: Fallstudie

Hälso- och sjukvårdsbranschen upplever en snabb tillväxt och omvandling, driven av tekniska framsteg och förändrade konsumentpreferenser. De globala utgifterna för hälso- och sjukvård översteg 8 biljoner dollar år 2020 och förväntas fortsätta att öka. Digitala investeringar ökade kraftigt till 57 miljarder dollar år 2021, med ett betydande fokus på telehälsa och mental hälsa. Dessutom har antalet digitala hälso-startups skjutit i höjden, med teknikjättar som Amazon som utökar sin närvaro inom hälso- och sjukvården.

En av de drivande krafterna bakom denna omvandling är hälso- och sjukvårdskonsumenternas förändrade beteende och preferenser. Patienter söker alltmer bekväma, tillgängliga och personliga hälso- och sjukvårdslösningar. Som ett resultat har användningen av telemedicin, bärbara enheter och hälsoappar ökat, vilket gör det möjligt för individer att övervaka sin hälsa på distans och vidta proaktiva åtgärder för att hantera sitt välbefinnande.

Regeringar leder initiativ för att modernisera hälso- och sjukvårdssystemet, med syfte att eliminera pappersarbete och öka användningen av digital teknik. Investeringar i digital IT, såsom IoT inom medicinen, är på uppgång och revolutionerar patientvården genom datainsamling i realtid och fjärrövervakning.

Allt eftersom hälso- och sjukvårdsbranschen utvecklas spelar digital innovation en avgörande roll för att förbättra tillgången till vård, öka patientengagemanget och driva bättre hälsoresultat globalt. Sammanfattningsvis är vi på Jetbase stolta över att vara en del av denna globala omvandling genom att utveckla innovativa IT-projekt inom hälso- och sjukvården.

I den här artikeln delar vi gärna med oss av vår fallstudie – ett projekt för utveckling av medicinska webb- och mobilappar – i detalj, där vi belyser problem som uppstått, utvecklingslösningar, allt baserat på en serverlös arkitektur från AWS. Vi hoppas att du gillar läsningen och tveka inte att dela den om du anser att det behövs.

Vårt projekt integrerar en mobil och webbaserad vårdlösning med moduler som Fjärrpatientövervakning (RPM) och Hantering av Kroniska Sjukdomar (CCM).

RPM-lösningen förser kliniker med en webbplattform för patientövervakning nära realtid och prediktiv analys. Den samlar in data från vårdenheter anslutna till IoT.

CCM är en annan modul där vårdgivare för kliniker kan ordinera medicin, sätta hälso- och personliga mål, spåra allergier och mer. Båda modulerna effektiviserar administrativa uppgifter och lagrar data säkert.

Ur ett användarupplevelseperspektiv gör webbplattformen det möjligt för läkare och annan medicinsk personal att övervaka patienternas hälsa i realtid. Den spårar också läkares aktiviteter, lagrar alla datarapporter i systemet och underlättar fakturabetalning. Samtidigt gör mobilappen det möjligt för patienter att fjärrövervaka sin hälsa i realtid, vilket även sträcker sig till familjemedlemmar för effektiv vård.

Tillsammans överbryggar dessa webb- och mobilutvecklingslösningar klyftan mellan vårdgivare och patienter, vilket förbättrar fjärrstyrd vårdhantering. Fortsätt läsa för att lära dig hur vi på Jetbase lanserade projektet och har fortsatt att förbättra det fram till idag.

Kunden är en leverantör av vårdenheter till kliniker. De kontaktade oss för cirka 3,5 år sedan för att fortsätta arbeta med befintlig programvara ansluten till enheter avsedda för att beräkna fakturor baserat på avläsningar.

Kundens mål var att skapa en mobilapplikation för patienter som använder dessa enheter och en webbapplikation för medicinsk personal och klinikadministratörer för att spåra patienttillstånd och personalens arbete. Det var också viktigt för kunden att projektet skulle kunna skalas i framtiden.

Idag har alla initialt uppsatta mål uppnåtts – projektet är i driftsatt tillstånd och fortsätter att utvecklas. Målet för framtiden är att överföra projektet till en Software as a Service (SaaS)-produkt och släppa det på den öppna marknaden.

Först och främst skapade vi en MVP — minsta gångbara produkt. Sedan genomförde vi tester och åtgärdade buggar. Allt detta tog cirka 7 månader. Det var under testfasen som produkten fick sin nuvarande form. Sammantaget hjälpte vi kunden att skala upp och lansera produkten, och vi fortsätter att stödja dess utveckling än idag.

Tillsammans med kunden fortsätter vi att förbättra produkten. En av förbättringarna inkluderar implementering av AI. Till exempel, i en situation där kritisk data tas emot och ett snabbt svar krävs, möjliggör vår anslutna tjänst förskrivning av ett textsvar.

Detta involverar användning av tillgängliga data inom systemet, såsom fullständigt namn och klinisk situation, samt mallfraser för hälsningar och avsked. Den väsentliga informationen verifieras dock alltid av läkaren innan den skickas till patienten. Således arbetar AI och människor tillsammans.

Nyligen lade vi även till en funktion för att skicka SMS-meddelanden, och vi håller för närvarande på att förbättra den. Specifikt skapar vi en instrumentpanel som gör det möjligt för läkaren att komma åt patientdata och, vid behov, skicka ett meddelande utan att lämna webbläsaren (se illustrationen ovan).

Det finns ytterligare en AI-tjänst som vi implementerade på kundens begäran. Detta är en tjänst för att utvärdera rösttonen i meddelanden. Det är viktigt att bedöma kvaliteten på kommunikationen mellan medicinsk personal och patienter.

Vi håller fortfarande på att implementera nya funktioner, men här är en lista över de som redan har implementerats och testats:

Varför Vi Valde AWS Serverless Lambda-tjänster för Detta Hälso- och Sjukvårdsprojekt

Valet av AWS Lambda var uppenbart eftersom du i det här fallet bara betalar för de sekunder och megabyte du använder. Och om det inte finns någon aktivitet betalar du inget. Du behöver inte heller betala för servern, så du behöver inte oroa dig för den eftersom AWS kontrollerar den automatiskt. Den är okrävande och kan hantera mer än hundra förfrågningar. Tack vare on-demand-funktionen i AWS Serverless behöver vi inte tänka på belastningar. Naturligtvis kan vi vid något tillfälle nå gränserna, men det blir en annan historia.

”På den valda vägen kommer det alltid att finnas för- och nackdelar. Nackdelarna med serverlös AWS Lambda är dess gränser. Till exempel har den en gräns på 15 minuter för körning, vilket innebär att om du har en process som körs längre än 15 minuter, så sitter du fast. Du måste tänka och hitta en lösning, till exempel att dela upp processen om möjligt, eller så kan du överväga att använda AWS Fargate, också en serverlös beräkningsmotor, eller några andra lösningar. En annan nackdel är att AWS Lambda även har minnesgränser. Så, beroende på vilken funktion du ska implementera, bör du känna till dessa gränser och hantera dem…” Shuhrat B. Full Stack Developer, Team Lead på Jetbase

Under vår resa stötte vi på flera utmaningar, varav en var hanteringen av rapporter. Med ett stort antal aktiva användare som genererade och skickade rapporter blev processen tidskrävande och överskred gränsen på 15 minuter. För att övervinna detta hinder vände vi oss till Amazons Simple Queue Service (SQS), ett kraftfullt verktyg som visade sig vara avgörande.

Vår lösning innebar att vi delade upp rapporterna och skapade ett meddelande i SQS för varje aktiv användare. I andra änden av kön implementerade vi en hanterare som skulle bearbeta och skicka rapporter för enskilda användare. Detta tillvägagångssätt minskade avsevärt behandlingstiden för rapportgenerering för användarna, vilket säkerställde att ingen rapport tog längre tid än 15 minuter att generera och skicka. Eftersom vi inte hade en strikt tidsram för att skicka dessa rapporter, tillfredsställde detta val oss och vår kund.

Genom att utnyttja SQS kunde vi effektivisera vårt arbetsflöde för rapportbehandling och förbättra systemets övergripande effektivitet. Denna erfarenhet underströk vikten av att utforska och använda de olika tjänster som erbjuds av Amazon Web Services för att övervinna utmaningar och optimera prestanda i våra projekt.

Några för- och nackdelar med AWS serverlös server för ditt IT-projekt inom hälso- och sjukvården

AWS serverlösa tjänster är fördelaktiga för ditt webbutvecklingsprojekt inom hälso- och sjukvården eftersom:

• Det är kostnadseffektivt – du behöver bara betala för de resurser som används, mätt i sekunder och megabyte.
• Det är skalbart – skönheten med automatiserad skalbarhet kan inte överskattas, då resurser allokeras baserat på efterfrågan, vilket säkerställer optimal användning.
• Infrastrukturen kan hanteras – AWS sköter serverunderhåll och skalning, vilket minskar den operativa bördan.

Det finns dock faktorer att överväga när du använder AWS serverlösa tjänster för ditt IT-projekt inom hälso- och sjukvården:

• Resursbegränsningar – vissa uppgifter har tidsbegränsningar, vilket potentiellt begränsar kontinuerliga eller långvariga processer.
• Latensproblem – komplexa operationer eller storskaliga databehandlingsuppgifter kan stöta på vissa fördröjningar.
• Beroende av AWS-system globalt – Förlitande på AWS-tjänster kan leda till leverantörsberoende och begränsad flexibilitet på lång sikt.

Trots nackdelarna föredrar vi att välja AWS serverlöst för IT-projekt inom hälso- och sjukvården eftersom års erfarenhet har visat dess effektivitet och stabilitet.

I början av projektet skisserade kunden flera nyckelkrav. Till exempel uttryckte de behovet av omedelbara meddelanden när en patient registrerar sig – vilket möjliggör snabb utskickning av enheter.

Angående valet av arkitektur kunde kunden ge input, men vi föreslog vår egen version. Till exempel, för att hantera stora volymer av avläsningar och åtgärder (som samtal och kommentarer), föreslog vi imple

Som visas i diagrammet kan läkare initiera telefonsamtal från instrumentpanelen – i detta fall kommer Amazon Connect SDK att lanseras för att koppla patienter med medicinska specialister. Det är avgörande för oss att spåra samtalsdetaljer som varaktighet för fakturaberäkningar och samtalstranskription för att analysera patientnöjdhet.

Vårt system måste noggrant spåra och registrera samtal, med nästan 100 % noggrannhet, eftersom detta är en kritisk funktion. Därför rekommenderade vi som team att använda en kö-metod för att få kontroll över systemet, vilket möjliggör funktioner som återförsök vid fel eller sparande av misslyckade meddelanden för senare åtgärder.

Vilka Tjänster Integrerades i Projektet

I projektet finns det så många integrationer med andra tjänster att det är omöjligt att lista dem alla. Här är bara några av dem:

Twilio — en SMS-tjänst som används för att skicka meddelanden till användare. Monday — en användarregistreringstjänst. Tray — används för att automatisera arbetsflöden, som att skicka rapporter. Stitch — en ETL-tjänst (Extract, Transform, Load) för att integrera och bearbeta Big Data. Medan vi underlättar integration med Stitch, tillhandahåller de också sitt eget verktyg för datahämtning och analys. Azure ChatGPT — en tjänst som används för att analysera avläsningar och ge kommentarer. Auth0 — en auktoriserings- och autentiseringstjänst. Files.com — en tjänst för fillagring och rapportering.

Projektets kärna kretsar kring att överföra data från vårdenheter via servern till applikationerna. Dessa filtrerade data är sedan tillgängliga för både läkare och patienter, samt klinikagenter och försäkringsbolag, som behöver ha en överblick och ta emot rapporter.

Dataöverföringen sker nära realtid, vilket gör det möjligt för medicinsk personal att ingripa omedelbart vid nödsituationer. Det hjälper också patienter att spara tid och pengar som de normalt skulle spendera på att resa till kliniker och medicinska anläggningar.

I vårt fall var olika enheter anslutna, såsom:

— Fjärrpatientövervakning — Blodsockermätare — Falldetektionsenheter — Pulsoximetrar — Blodtrycksmätare — Smarta Termometrar — Aktivitetsarmband — Vikt — Sovmatta

Vi stötte inte på några problem med integrationen, förutom kanske med synkroniseringen av tidsstämplar för avläsningar. Till exempel skickade vissa enheter data enligt patienternas tidszoner, medan andra använde UTC. Vi var tvungna att lösa detta problem för att säkerställa datanoggrannhet.

När det gäller att organisera och lagra data använde vi Amazon DynamoDB, som skalas efter datavolymen, oavsett om den är mindre eller större, utan att kompromissa med systemets effektivitet. Det finns ingen väntetid för anpassning. Hela flödet och arkitekturen demonstreras i diagrammet.

En annan tjänst vi integrerade för bekväm datahantering är Elasticsearch, som hjälper till att snabbt hitta specifika avläsningar eller annan data. Tjänsten hjälper också till att analysera data intelligent och snabbt.

IoT erbjuder funktioner för datamonitorering och spårning i realtid, vilket gör att vårdappar kan ge snabba insikter om patienters hälsotillstånd. Genom att integrera IoT-teknik kan vårdappar förbättra fjärrpatientövervakning, förbättra följsamheten till behandling och underlätta tidig upptäckt av hälsoproblem, vilket i slutändan leder till bättre patientresultat.

Vilka Var Problemen På Utvecklarnas Sida

Visst stötte vi på vissa utmaningar. Vi är inte rädda för att diskutera dem eftersom de alla har lösts. Till exempel, som nämnts tidigare, stötte vi på svårigheter med synkroniseringen av tidsstämplar för avläsningar. Det var absolut nödvändigt att lösa detta problem för att säkerställa datanoggrannhet.

— Fördröjning vid datainsamling

Dessutom, på grund av enhetslatens, började vi ta emot vissa avläsningar mycket sent, ibland till och med avläsningar från föregående vecka. Detta orsakade förvirring bland både läkare och patienter, eftersom avläsningar som mottogs idag visades som dagens avläsningar, trots att de tagits en vecka tidigare.

— Problem med inkommande samtal

Vi stötte på problem med inkommande samtal från okända telefonnummer (d.v.s. telefonnummer som inte är registrerade i vårt system). I sådana fall utvecklade vi en lösning för att spåra dessa samtal med patient-ID, vilket läkare eller agenter kan implementera under samtalet. Följaktligen har vi etablerat en semi-automatiserad process för att spåra samtal från okända nummer och arbetar fortfarande med att lösa problemet.

— Problem med dataförlust När antalet aktiva patienter ökade stötte vi på problem med att förlora vissa avläsningar. Oväntade fel uppstod, vilket hindrade oss från att transformera avläsningsdata och visa den i användargränssnittet.

— Problem med rapportdistribution

Vi stod även inför utmaningar med rapportdistribution. Ursprungligen fick endast 30-50 av 500 kliniker rapporter. Vi har dock sedan dess löst problemet, och nu distribueras alla rapporter den 1:a varje månad. Även om denna process fortfarande tar tid – från tidig morgon till klockan 18 på kvällen, cirka 4-5 timmar – slutförs den inom en enda arbetsdag. Om antalet kliniker överstiger 500 kommer vi att hantera situationen därefter.

När det gäller patienter är det tiotusentals, och vi har framgångsrikt lyckats skicka rapporter till alla inom en enda dag. Dessutom är vår klient nöjd även om det blir flera dagars fördröjning.

Vi hoppas att vår fallstudieartikel har varit till hjälp för dig. Vi syftade till att ge transparent information om skapandet av vår digitala vårdlösning för IoT-systemet, i detalj beskriva de utmaningar vi stötte på och hur vi övervann dem. Dessutom redogjorde vi för de tjänster vi använde och förklarade varför vi valde AWS Lambda serverlösa tjänster för vårt medicinska webbutvecklingsprojekt.

Med många års erfarenhet inom området för vårdutveckling förstår vi de intrikata detaljerna och komplexiteten i att bygga robusta och skalbara lösningar. Om du funderar på att påbörja ett medicinskt projekt eller behöver hjälp med programvaruutveckling inom hälso- och sjukvården, är vi väl rustade att erbjuda vår expertis och vårt stöd. Tveka inte att kontakta oss för konsultation och samarbete på din nästa innovationsresa inom hälso- och sjukvården.

Och om du behöver ytterligare vägledning om utveckling inom hälso- och sjukvården, notera att vi har en specialutformad guide 'Healthcare Development Cost 2025' som hjälper dig att få insikt i budgetering och investeringar.