Trekk ut ikke-PHI-data fra Amazon HealthLake, reduser kompleksiteten og øk kostnadseffektiviteten med Amazon Athena og Amazon SageMaker Canvas

Trekk ut ikke-PHI-data fra Amazon HealthLake, reduser kompleksiteten og øk kostnadseffektiviteten med Amazon Athena og Amazon SageMaker Canvas

I dagens svært konkurranseutsatte marked har det blitt en nødvendighet for organisasjoner å utføre dataanalyse ved hjelp av maskinlæringsmodeller (ML). Det gjør dem i stand til å låse opp verdien av dataene deres, identifisere trender, mønstre og spådommer og skille seg fra konkurrentene. For eksempel, i helsesektoren kan ML-drevet analyse brukes til diagnostisk assistanse og personlig medisin, mens det i helseforsikring kan brukes til prediktiv omsorgsbehandling.

Organisasjoner og brukere i bransjer der det finnes potensielle helsedata, som i helsevesenet eller i helseforsikring, må imidlertid prioritere å beskytte personvernet til mennesker og overholde regelverket. De står også overfor utfordringer med å bruke ML-drevet analyse for et økende antall brukstilfeller. Disse utfordringene inkluderer et begrenset antall datavitenskapseksperter, kompleksiteten til ML og det lave datavolumet på grunn av begrenset beskyttet helseinformasjon (PHI) og infrastrukturkapasitet.

Organisasjoner innen helsevesenet, klinisk og biovitenskap står overfor flere utfordringer med å bruke ML for dataanalyse:

  • Lavt datavolum – På grunn av restriksjoner på privat, beskyttet og sensitiv helseinformasjon, er volumet av brukbare data ofte begrenset, noe som reduserer nøyaktigheten til ML-modeller
  • Begrenset talent – Å ansette ML-talenter er vanskelig nok, men å ansette talenter som ikke bare har ML-erfaring, men også dyp medisinsk kunnskap er enda vanskeligere
  • Infrastrukturstyring – Å levere infrastruktur spesialisert for ML er en vanskelig og tidkrevende oppgave, og bedrifter vil heller fokusere på sin kjernekompetanse enn å administrere kompleks teknisk infrastruktur
  • Forutsigelse av multimodale problemer – Når man forutsier sannsynligheten for mangefasetterte medisinske hendelser, som hjerneslag, må ulike faktorer som sykehistorie, livsstil og demografisk informasjon kombineres

Et mulig scenario er at du er et helseteknologiselskap med et team på 30 ikke-kliniske leger som forsker på og undersøker medisinske tilfeller. Dette teamet har kunnskapen og intuisjonen innen helsevesenet, men ikke ML-ferdighetene til å bygge modeller og generere spådommer. Hvordan kan du distribuere et selvbetjeningsmiljø som lar disse klinikerne generere spådommer selv for multivariate spørsmål som, "Hvordan kan jeg få tilgang til nyttige data samtidig som jeg er i samsvar med helseforskriftene og uten å kompromittere personvernet?" Og hvordan kan du gjøre det uten å eksplodere antallet servere SysOps-folkene trenger å administrere?

Dette innlegget tar for seg alle disse problemene samtidig i én løsning. For det første anonymiserer den automatisk dataene fra Amazon HealthLake. Deretter bruker den disse dataene med serverløse komponenter og kodefrie selvbetjeningsløsninger som Amazon SageMaker Canvas å eliminere ML-modelleringskompleksiteten og abstrahere bort den underliggende infrastrukturen.

En moderne datastrategi gir deg en omfattende plan for å administrere, få tilgang til, analysere og handle på data. AWS tilbyr det mest komplette settet med tjenester for hele datareisen fra ende til ende for alle arbeidsbelastninger, alle typer data og alle ønskede forretningsresultater.

Løsningsoversikt

Dette innlegget viser at ved å anonymisere sensitive data fra Amazon HealthLake og gjøre dem tilgjengelige for SageMaker Canvas, kan organisasjoner gi flere interessenter mulighet til å bruke ML-modeller som kan generere spådommer for multimodale problemer, for eksempel slagprediksjon, uten å skrive ML-kode, samtidig som de begrenser tilgang til sensitive data. Og vi ønsker å automatisere den anonymiseringen for å gjøre dette så skalerbart og tilgjengelig for selvbetjening som mulig. Automatisering lar deg også iterere anonymiseringslogikken for å oppfylle dine samsvarskrav, og gir deg muligheten til å kjøre pipelinen på nytt etter hvert som befolkningens helsedata endres.

Datasettet som brukes i denne løsningen er generert av Synthea™, en syntetisk pasientpopulasjonssimulator og åpen kildekode-prosjekt under Apache lisens 2.0.

Arbeidsflyten inkluderer en hand-off mellom skyingeniører og domeneeksperter. Førstnevnte kan utplassere rørledningen. Sistnevnte kan verifisere om rørledningen anonymiserer dataene korrekt og deretter generere spådommer uten kode. På slutten av innlegget ser vi på tilleggstjenester for å bekrefte anonymiseringen.

Trinnene på høyt nivå som er involvert i løsningen er som følger:

  1. Bruk AWS trinnfunksjoner å orkestrere rørledningen for anonymisering av helsedata.
  2. Bruk Amazonas Athena spørsmål for følgende:
    1. Trekk ut ikke-sensitive strukturerte data fra Amazon HealthLake.
    2. Bruk naturlig språkbehandling (NLP) i Amazon HealthLake for å trekke ut ikke-sensitive data fra ustrukturerte blobs.
  3. Utfør one-hot-koding med Amazon SageMaker Data Wrangler.
  4. Bruk SageMaker Canvas for analyser og spådommer.

Følgende diagram illustrerer løsningsarkitekturen.

Arkitektur diagram

Forbered dataene

Først genererer vi en fiktiv pasientpopulasjon ved å bruke Synthea™ og importerer disse dataene til en nyopprettet Amazon HealthLake-databutikk. Resultatet er en simulering av utgangspunktet hvor et helseteknologiselskap kunne kjøre rørledningen og løsningen beskrevet i dette innlegget.

Når Amazon HealthLake inntar data, trekker den automatisk ut mening fra ustrukturerte data, for eksempel legenotater, til separate strukturerte felt, for eksempel pasientnavn og medisinske tilstander. For å oppnå dette på de ustrukturerte dataene i DocumentReference FHIR-ressurser, utløser Amazon HealthLake transparent Amazon Comprehend Medical, der enheter, ontologier og deres relasjoner trekkes ut og legges tilbake til Amazon HealthLake som diskrete data innenfor utvidelsessegmentet av poster.

We kan bruke trinnfunksjoner å effektivisere innsamlingen og utarbeidelsen av dataene. Hele arbeidsflyten er synlig på ett sted, med eventuelle feil eller unntak uthevet, noe som muliggjør en repeterbar, reviderbar og utvidbar prosess.

Spør dataene ved hjelp av Athena

Ved å kjøre Athena SQL-spørringer direkte på Amazon HealthLake, kan vi velge bare de feltene som ikke identifiserer personlig; for eksempel å ikke velge navn og pasient-ID, og ​​redusere fødselsdato til fødselsår. Og ved å bruke Amazon HealthLake, våre ustrukturerte data (tekstfeltet i DocumentReference) kommer automatisk med en liste over oppdagede PHI, som vi kan bruke til å maskere PHI i de ustrukturerte dataene. I tillegg, fordi genererte Amazon HealthLake-tabeller er integrert med AWS Lake formasjon, kan du kontrollere hvem som får tilgang ned til feltnivå.

Følgende er et utdrag fra et eksempel på ustrukturerte data funnet i en syntetisk DocumentReference ta opp:

# Historie om nåværende sykdom
marquis
er en 45 år gammel. Pasienten har en historie med hypertensjon, viral bihulebetennelse (lidelse), kronisk obstruktiv bronkitt (lidelse), stress (funn), sosial isolasjon (funn).
# Sosial historie
Pasienten er gift. Pasienten sluttet å røyke i en alder av 16.
Pasienten har for tiden UnitedHealthcare.
# Allergier
Ingen kjente allergier.
# Medisiner
albuterol 5 mg/ml inhalasjonsløsning; amlodipin 2.5 mg oral tablett; 60 aktuat flutikasonpropionat 0.25 mg/aktuat / salmeterol 0.05 mg/aktuat tørrpulverinhalator
# Vurdering og plan
Pasienten har slag.

Vi kan se at Amazon HeathLake NLP tolker dette som å inneholde tilstanden «slag» ved å spørre etter tilstandsposten som har samme pasient-ID og viser «slag». Og vi kan dra nytte av det faktum at enheter som finnes i DocumentReference automatisk merkes SYSTEM_GENERATED:

SELECT code.coding[1].code, code.coding[1].display
FROM condition
WHERE split(subject.reference, '/')[2] = 'fbfe46b4-70b1-8f61-c343-d241538ebb9b'
AND meta.tag[1].display = 'SYSTEM_GENERATED'
AND regexp_like(code.coding[1].display, 'Cerebellar stroke syndrome')

Resultatet er som følger:

G46.4, Cerebellar stroke syndrome

Dataene som samles inn i Amazon HealthLake kan nå effektivt brukes til analyser takket være muligheten til å velge spesifikke tilstandskoder, for eksempel G46.4, i stedet for å måtte tolke hele notater. Disse dataene lagres deretter som en CSV-fil i Amazon enkel lagringstjeneste (Amazon S3).

OBS: Følg med når du implementerer denne løsningen instruksjonene på å slå på HealthLakes integrerte NLP-funksjon via et støttetilfelle før data tas inn i HealthLake-datalageret.

Utfør one-hot-koding

For å låse opp det fulle potensialet til dataene bruker vi en teknikk som kalles one-hot encoding for å konvertere kategoriske kolonner, som tilstandskolonnen, til numeriske data.

En av utfordringene med å jobbe med kategoriske data er at de ikke er like tilgjengelige for bruk i mange maskinlæringsalgoritmer. For å overvinne dette bruker vi one-hot encoding, som konverterer hver kategori i en kolonne til en separat binær kolonne, noe som gjør dataene egnet for et bredere spekter av algoritmer. Dette gjøres ved hjelp av Data Wrangler, som har innebygde funksjoner for dette:

Den innebygde funksjonen for one-hot-koding i SageMaker Data Wrangler

Den innebygde funksjonen for one-hot-koding i SageMaker Data Wrangler

One-hot-koding forvandler hver unike verdi i den kategoriske kolonnen til en binær representasjon, noe som resulterer i et nytt sett med kolonner for hver unike verdi. I eksemplet nedenfor er tilstandskolonnen transformert til seks kolonner, som hver representerer én unik verdi. Etter én varm koding, ville de samme radene bli til en binær representasjon.

Before_and_After_One-hot_encoding_tables

Med dataene som nå er kodet, kan vi gå videre til å bruke SageMaker Canvas for analyser og spådommer.

Bruk SageMaker Canvas for analyser og spådommer

Den endelige CSV-filen blir deretter input for SageMaker Canvas, som helseanalytikere (bedriftsbrukere) kan bruke til å generere spådommer for multivariate problemer som slagprediksjon uten å måtte ha ekspertise på ML. Ingen spesielle tillatelser kreves fordi dataene ikke inneholder noen sensitiv informasjon.

I eksemplet med slagprediksjon var SageMaker Canvas i stand til å oppnå en nøyaktighetsgrad på 99.829 % ved bruk av avanserte ML-modeller, som vist i følgende skjermbilde.

Analyseskjermen i SageMaker Canvas viser 99.829 % som hvor ofte modellen riktig forutsier slag

I neste skjermbilde kan du se at denne pasienten ifølge modellens prediksjon har 53 % sjanse for ikke å få hjerneslag.

SageMaker Canvas Forutsig-skjerm som viser at spådommen er Ingen slag basert på input fra ikke i arbeidsstyrke blant andre input.

Du kan påstå at du kan lage denne prediksjonen ved å bruke regelbasert logikk i et regneark. Men forteller disse reglene deg viktigheten av funksjonen – for eksempel at 4.9 % av spådommen er basert på hvorvidt de noen gang har røykt tobakk eller ikke? Og hva om du, i tillegg til gjeldende kolonner som røykestatus og blodtrykk, legger til 900 flere kolonner (funksjoner)? Ville du fortsatt kunne bruke et regneark til å vedlikeholde og administrere kombinasjonene av alle disse dimensjonene? Scenarier i det virkelige liv fører til mange kombinasjoner, og utfordringen er å håndtere dette i skala med riktig innsatsnivå.

Nå som vi har denne modellen, kan vi begynne å lage batch- eller enkeltspådommer, og stille hva-hvis-spørsmål. For eksempel, hva om denne personen holder alle variablene like, men som i de to foregående møtene med det medisinske systemet, er klassifisert som Heltidsansettelse istedenfor Ikke i arbeidsstyrken?

I henhold til modellen vår, og de syntetiske dataene vi matet den fra Synthea, har personen 62 % risiko for å få hjerneslag.

SageMaker Canvas prediksjonsskjerm som viser Ja som prediksjon og heltidsansettelser som input.

Som vi kan se fra de omringede 12 % og 10 % har betydningen av tilstandene fra de to siste møtene med det medisinske systemet, om de er heltidsansatte eller ikke har stor innvirkning på risikoen for hjerneslag. Utover funnene av denne modellen, er det forskning som viser en lignende kobling:

Disse studiene har brukt store populasjonsbaserte prøver og kontrollert for andre risikofaktorer, men det er viktig å merke seg at de er observasjonsbaserte og ikke etablerer årsakssammenheng. Ytterligere forskning er nødvendig for å forstå sammenhengen mellom heltidsarbeid og hjerneslagrisiko.

Forbedringer og alternative metoder

For ytterligere å validere samsvar, kan vi bruke tjenester som Amazon Macie, som vil skanne CSV-filene i S3-bøtten og varsle oss hvis det er noen sensitive data. Dette bidrar til å øke konfidensnivået til de anonymiserte dataene.

I dette innlegget brukte vi Amazon S3 som inndatakilde for SageMaker Canvas. Vi kan imidlertid også importere data til SageMaker Canvas direkte fra Amazon RedShift og Snowflake – populære datavarehustjenester for bedrifter som brukes av mange kunder for å organisere dataene deres og populære tredjepartsløsninger. Dette er spesielt viktig for kunder som allerede har dataene sine i enten Snowflake eller Amazon Redshift som brukes til annen BI-analyse.

Ved å bruke Step Functions til å orkestrere løsningen, er løsningen mer utvidbar. I stedet for en separat trigger for å påkalle Macie, kan du legge til et nytt trinn på slutten av pipelinen for å ringe Macie for å dobbeltsjekke for PHI. Hvis du vil legge til regler for å overvåke datapipelinens kvalitet over tid, kan du legge til et trinn for AWS limdatakvalitet.

Og hvis du vil legge til flere skreddersydde integrasjoner, lar Step Functions deg skalere ut for å håndtere så mye data eller så lite data du trenger parallelt og kun betale for det du bruker. Parallelliseringsaspektet er nyttig når du behandler hundrevis av GB med data, fordi du ikke vil prøve å blokkere alt dette i én funksjon. I stedet vil du bryte den opp og kjøre den parallelt, slik at du ikke venter på at den skal behandles i en enkelt kø. Dette ligner på en utsjekkingslinje i butikken - du vil ikke ha en eneste kasserer.

Rydd opp

For å unngå fremtidige øktkostnader, logg ut av SageMaker Canvas.

Logg ut-knapp i SageMaker Canvas

konklusjonen

I dette innlegget viste vi at spådommer for kritiske helseproblemer som hjerneslag kan gjøres av medisinske fagfolk som bruker komplekse ML-modeller, men uten behov for koding. Dette vil øke ressursmassen betydelig ved å inkludere personer som har spesialisert domenekunnskap, men ingen ML-erfaring. Ved å bruke serverløse og administrerte tjenester kan eksisterende IT-folk også håndtere infrastrukturutfordringer som tilgjengelighet, robusthet og skalerbarhet med mindre innsats.

Du kan bruke dette innlegget som et utgangspunkt for å undersøke andre komplekse multimodale spådommer, som er nøkkelen til å veilede helseindustrien mot bedre pasientbehandling. Snart vil vi ha et GitHub-depot for å hjelpe ingeniører raskere å lansere den typen ideer vi presenterte i dette innlegget.

Opplev kraften til SageMaker Canvas i dag, og bygg modellene dine ved hjelp av et brukervennlig grafisk grensesnitt, med 2-måneders gratis nivå som SageMaker Canvas tilbyr. Du trenger ingen kodekunnskap for å komme i gang, og du kan eksperimentere med forskjellige alternativer for å se hvordan modellene dine presterer.

Ressurser

For å lære mer om SageMaker Canvas, se følgende:

For å lære mer om andre brukstilfeller som du kan løse med SageMaker Canvas, sjekk ut følgende:

For å lære mer om Amazon HealthLake, se følgende:


Om forfatterne

Yann Stoneman hodeskudd -- hvit mann i 30-årene med lett skjegg og smilende brillerYann Stoneman er en løsningsarkitekt ved AWS basert i Boston, MA og er medlem av AI/ML Technical Field Community (TFC). Yann fikk sin bachelorgrad ved The Juilliard School. Når han ikke moderniserer arbeidsmengder for globale bedrifter, spiller Yann piano, tuller i React og Python, og jevnlig på YouTube om skyreisen sin.

Ramesh Dwarakanath hodeskuddRamesh Dwarakanath er en hovedløsningsarkitekt ved AWS basert i Boston, MA. Han jobber med bedrifter i Nordøst-området på deres Cloud-reise. Hans interesseområder er containere og DevOps. På fritiden liker Ramesh tennis og racquetball.

Bakha Nurzhanovs hodeskudd med mørkt hår og litt smilendeBakha Nurzhanov er en Interoperability Solutions Architect ved AWS, og er medlem av Healthcare and Life Sciences tekniske feltfellesskap ved AWS. Bakha tok sin mastergrad i informatikk fra University of Washington, og på fritiden liker Bakha å tilbringe tid med familien, lese, sykle og utforske nye steder.

Scott Schreckengausts hodeskuddScott Schreckengaust har en grad i biomedisinsk ingeniørfag og har funnet opp enheter sammen med forskere på benken siden begynnelsen av karrieren. Han elsker vitenskap, teknologi og ingeniørfag med flere tiår med erfaring fra oppstart for store multinasjonale organisasjoner innen helsevesen og biovitenskap. Scott er komfortabel med å skripte robotiske væskebehandlere, programmere instrumenter, integrere hjemmelagde systemer i bedriftssystemer og utvikle komplette programvaredistribusjoner fra bunnen av i regulatoriske miljøer. I tillegg til å hjelpe folk, trives han med å bygge – nyter reisen med å hash ut kundens vitenskapelige arbeidsflyter og deres problemer og deretter konvertere disse til levedyktige løsninger.

Tidstempel:

Mer fra AWS maskinlæring