OMOP CDM Ofte Stillede Spørgsmål

1. Jeg forstår, at den fælles datamodel (CDM) er en måde at organisere forskellige datakilder på i samme relationsdatabasedesign, men hvordan kan det være effektivt, da mange databaser bruger forskellige kodningsordninger?

under ETL-processen med at konvertere en datakilde til omop fælles datamodel standardiserer vi strukturen (f. eks. tabeller, felter, datatyper), konventioner (f. eks. regler, der styrer, hvordan kildedata skal repræsenteres) og indhold (f. eks. hvad almindelige ordforråd bruges til at tale det samme sprog på tværs af kliniske domæner). Den fælles datamodel bevarer alle kildedata, inklusive de originale kildeordforrådskoder, men tilføjer de standardiserede ordforråd for at give mulighed for netværksforskning på tværs af hele OHDSI-forskningsmiljøet.

2. Hvordan bliver mine data omdannet til den fælles datamodel?

du eller nogen i din organisation skal oprette en proces for at opbygge din CDM. Bare rolig, du er ikke alene! Samfundets åbne karakter betyder, at meget af den kode, som andre deltagere har skrevet for at transformere deres egne data, er tilgængelig for dig at bruge. Hvis du har en datalicens til en stor administrativ fordringsdatabase som IBM MarketScan pristi eller Optums Clinformatics Pristi udvidet Datamart, er chancerne for, at nogen allerede har gjort benarbejdet. Her er et eksempel på en fuld builder frit tilgængelig på github, der er skrevet til en række datakilder.

fællesskabsfora er også et godt sted at stille spørgsmål, hvis du sidder fast eller har brug for vejledning i, hvordan du repræsenterer dine data i den fælles datamodel. Medlemmer er normalt meget lydhøre!

3. Er nogen tabeller eller felter valgfri?

det forventes, at alle tabeller vil være til stede i en CDM, selvom det ikke er et krav, at de alle er befolket. De to obligatoriske tabeller er:

  • Person: indeholder optegnelser, der entydigt identificerer hver patient i kildedataene, som er i fare for at få kliniske observationer registreret i kildesystemerne.
  • Observation_period: indeholder optegnelser, der entydigt definerer de tidsrum, som en Person er i fare for at få kliniske hændelser registreret i kildesystemerne.

det er så op til dig, hvilke tabeller der skal udfyldes, selvom kernehændelsestabellerne generelt er enige om at være Condition_occurrence, Procedure_occurrence, Drug_eksponering, måling og Observation. Hver tabel har visse krævede felter, hvoraf en komplet liste findes på siden Common Data Model.

4. Indeholder datamodellen afledte oplysninger? Hvilke tabeller eller værdier er afledt?

den fælles datamodel gemmer ordrette data fra kilden på tværs af forskellige kliniske domæner, såsom poster for tilstande, lægemidler, procedurer og målinger. For at hjælpe analytikeren indeholder den fælles datamodel også nogle afledte tabeller baseret på almindeligt anvendte analytiske procedurer. For eksempel er Condition_era-tabellen afledt af Condition_occurrence-tabellen, og både Drug_era-og Dose_era-tabellerne er afledt af Drug_eksponeringstabellen. En era defineres som et tidsrum, hvor en patient antages at have en given tilstand eller eksponering for en bestemt aktiv ingrediens. Medlemmer af samfundet har skrevet kode for at oprette disse tabeller, og det er ude på github, hvis du vælger at bruge det i din CDM-build. Det er vigtigt at styrke, analytikeren har mulighed for, men ikke forpligtelsen, at bruge nogen af de afledte tabeller, og alle kildedata er stadig tilgængelige til direkte brug, hvis analysen kræver forskellige antagelser.

5. Hvordan er alder fanget i modellen?

Year_of_birth, month_of_birth, day_of_birth og birth_datetime er alle felter i Persontabellen designet til at fange en eller anden form for fødselsdato. Mens kun year_of_birth er påkrævet, giver disse felter maksimal fleksibilitet over en lang række datakilder.

6. Hvordan er køn, race og etnicitet fanget i modellen? Er de kodet ved hjælp af værdier, som en menneskelig læser kan forstå?

Standardkoncepter bruges til at betegne alle kliniske enheder i hele omop fælles datamodel, herunder køn, race og etnicitet. Kildeværdier kortlægges til Standardkoncepter under uddrag, transform, load (ETL) processen med at konvertere en database til Omop Common Data Model. Disse gemmes derefter i felterne Gender_concept_id, Race_concept_id og Ethnicity_concept_id i Persontabellen. Fordi standardkoncepterne spænder over alle kliniske domæner og i overensstemmelse med Ciminos ‘Desiderata for kontrollerede medicinske ordforråd i det enogtyvende århundrede’, er identifikatorerne unikke, vedvarende ikke-sematiske identifikatorer. Køn gemmes for eksempel som enten 8532 (kvinde) eller 8507 (mand) i gender_concept_id, mens den oprindelige værdi fra kilden er gemt i gender_source_value (M, mand, F osv.).

7. Er der betingelser/procedurer / stoffer eller andre domæner, der skal maskeres eller skjules i CDM?

maskeringen af oplysninger relateret til en person er afhængig af organisationens privatlivspolitikker og kan variere efter dataaktiv (Themis issue #21).

8. Hvordan behandles tidsvarierende patientoplysninger såsom bopælssted i modellen?

omop common data-modellen er pragmatisk defineret ud fra de ønskede analytiske brugssager i samfundet såvel som de tilgængelige typer data, som medlemmer af samfundet har adgang til. Før CDM v6.0 havde hver personrekord tilknyttede demografiske attributter, som antages at være konstante for patienten i løbet af deres observationsperioder, som placering og primærplejeudbyder. Med udgivelsen af CDM v6.0 er tabellen Location_History nu tilgængelig til at spore bevægelser af mennesker, plejesider og udbydere over tid. Kun den seneste location_id skal gemmes i Persontabellen for at eliminere duplikering, mens personens bevægelser gemmes i Location_History.

noget som civilstand er lidt anderledes, da det anses for at være en observation snarere end en demografisk attribut. Dette betyder, at det er anbragt i Observationstabellen snarere end Persontabellen, hvilket giver mulighed for at gemme hver ændring i status som en unik post.

hvis nogen i samfundet havde en brugssag til tidsvarierende bopæl og også havde kildedata, der indeholder disse oplysninger, ville vi gerne deltage i CDM-arbejdsgruppen for at udvikle modellen yderligere.

9. Hvordan angiver modellen den tidsperiode, hvor en persons oplysninger er gyldige?

Omop Common Data Model bruger noget kaldet observationsperioder (gemt i Observation_period-tabellen) som en måde at definere det tidsrum, hvor en patient er i fare for at få registreret en klinisk begivenhed. I administrative kravdatabaser er disse observationsperioder for eksempel ofte analoge med begrebet ’tilmelding’.

10. Hvordan registrerer modellen start-og stopdatoer for forsikringsdækning? Hvad hvis en persons dækning ændres?

tabellen Payer_plan_period indeholder oplysninger om den tidsperiode, hvor en Person løbende er tilmeldt en specifik sundhedsplanfordelstruktur fra en given betaler. Betalerplanperioder, i modsætning til observationsperioder, kan overlappe hinanden for at angive det tidspunkt, hvor en Person er tilmeldt flere planer på samme tid, såsom Medicare Del A og Medicare del D.

11. Hvad hvis jeg har EPJ-data? Hvordan opretter jeg observationsperioder?

en observationsperiode betragtes som det tidspunkt, hvor en patient er i fare for at få registreret en klinisk hændelse i kildesystemet. Bestemmelse af den passende observationsperiode for hver kildedata kan variere afhængigt af hvilke oplysninger kilden indeholder. Hvis en kilde ikke giver oplysninger om en patients indrejse eller udgang fra et system, skal der udvikles og anvendes rimelig heuristik inden for ETL.

Kortlægning Af Ordforråd

12. Skal jeg selv kortlægge mine kildekoder til Standardkoncepter? Er der ordforråd kortlægninger, der allerede findes for mig at udnytte?

hvis dine data bruger nogen af de 55 kildeordbøger, der aktuelt understøttes, er tilknytningerne blevet udført for dig. Den fulde liste er tilgængelig fra Open source ATHENA-værktøjet under fanen Hent (se nedenfor). Du kan også vælge at hente de ti ordforrådstabeller derfra – du skal bruge en kopi i dit miljø, hvis du planlægger at opbygge en CDM.

ATHENA-værktøjet giver dig også mulighed for at udforske ordforrådet, før du henter det, hvis du er nysgerrig efter kortlægningerne, eller hvis du har en bestemt kode i tankerne og gerne vil vide, hvilket standardkoncept det er forbundet med; bare klik på fanen Søg og skriv et nøgleord for at begynde at søge.

13. Hvis jeg selv vil anvende kortlægningerne, kan jeg gøre det? Er de gennemsigtige for alle brugere?

ja, alle tilknytninger er tilgængelige i Concept_relationship-tabellen (som kan hentes fra ATHENA). Hver værdi i en understøttet kildeterminologi tildeles et Concept_id (som betragtes som ikke-standard). Hver Source_concept_id vil have en kortlægning til en Standard_concept_id. Eksempel:

i dette tilfælde vil standard SNOMED concept 201826 for type 2-diabetes mellitus blive opbevaret i Condition_occurrence-tabellen, da Condition_concept_id og ICD10CM concept 1567956 for type 2-diabetes mellitus ville blive gemt som Condition_source_concept_id.

14. Kan koderne gemmes i modellen? Kan jeg gemme flere niveauer, hvis jeg vælger det? Hvad hvis en samarbejdspartner bruger et andet niveau end jeg bruger, når jeg transformerer deres database?

i Omop ‘ s fælles datamodel betragtes Rksnorm som standardordforråd for repræsentation af lægemiddeleksponeringer. En af de store ting ved det standardiserede ordforråd er, at den hierarkiske karakter af Rksnorm bevares for at muliggøre effektiv forespørgsel. Det er aftalt bedste praksis at gemme det laveste tilgængelige niveau og derefter bruge ordforrådet til at udforske eventuelle relevante forhold. Lægemiddelingredienser er forfædre på højeste niveau, så en forespørgsel til efterkommerne af en ingrediens skal vise alle lægemiddelprodukter (klinisk lægemiddel eller mærket lægemiddel), der indeholder denne ingrediens. En forespørgsel designet på denne måde vil finde stoffer af interesse i enhver CDM uanset niveauet af Rksnorm anvendt.

15. Hvad hvis Ordforrådet har en kortlægning, jeg ikke er enig i? Kan det ændres?

ja, det er skønheden i samfundet! Hvis du finder en kortlægning i ordforrådet, der ikke ser ud til at høre hjemme, eller som du synes kunne være bedre, er du velkommen til at skrive en note på fora eller på ordforrådet github. Hvis samfundet er enig i din vurdering, vil det blive behandlet i den næste ordforrådsversion.

16. Hvad hvis jeg har kildekoder, der er specifikke for min hjemmeside? Hvordan skal disse kortlægges?

i Omop-Ordforrådet er der en tom tabel kaldet Source_to_concept_map. Det er en simpel tabelstruktur, der giver dig mulighed for at etablere kortlægning(er) for hver kildekode med et standardkoncept i Omop-ordforrådet (TARGET_CONCEPT_ID). Dette arbejde kan lettes ved hjælp af OHDSI-værktøjet Usagi (billedet nedenfor), der søger efter tekstlighed mellem dine kildekodebeskrivelser og Omop-ordforrådet og eksportkortlægninger i en SOURCE_TO_CONCEPT_MAP-tabelstruktur. Eksempel Source_to_concept_map filer kan findes her. Disse genererede Source_to_concept_map-filer indlæses derefter i Omop-ordforrådets tomme Source_to_concept_map, inden de oprindelige data behandles i CDM, så CDM-bygherren kan bruge dem i en build.

hvis en kildekode ikke understøttes af Omop-ordforrådet, kan man oprette en ny post i KONCEPTTABELLEN, men CONCEPT_IDs skal starte >2000000000, så det er let at fortælle mellem Omop-Ordforrådskoncepterne og de stedspecifikke begreber. Når disse begreber eksisterer CONCEPT_RELATIONSHIPS kan genereres for at tildele dem til en standard terminologier, USAGI kan lette denne proces samt (Themis problem #22).

17. Hvordan anvendes en-til-mange kortlægninger?

hvis en kildekode kortlægges til to Standardkoncepter, gemmes to rækker i den tilsvarende kliniske hændelsestabel.

18. Hvad hvis jeg vil beholde mine originale data såvel som de kortlagte værdier? Er der en måde for mig at gøre det?

Ja! Kildeværdier og Kildekoncepter opretholdes fuldt ud inden for Omop Common Data Model. Et Kildekoncept repræsenterer koden i kildedataene. Hvert Kildekoncept er kortlagt til et eller flere Standardkoncepter under ETL-processen, og begge gemmes i den tilsvarende kliniske hændelsestabel. Hvis ingen kortlægning er tilgængelig, skrives Standardkonceptet med concept_id = 0 i feltet * _concept_id (Condition_concept_id, Procedure_concept_id osv.) for at bevare posten fra de oprindelige data.

Fælles Datamodel Versionsstyring

19. Hvem bestemmer hvornår og hvordan datamodellen skal ændres?

fællesskabet! Der er en arbejdsgruppe designet omkring opdatering af modellen, og alt gøres ved konsensus. Medlemmer indsender foreslåede ændringer til github i form af spørgsmål, og gruppen mødes en gang om måneden for at diskutere og stemme om ændringerne. Eventuelle ratificerede forslag føjes derefter til køen for en fremtidig version af den fælles datamodel.

20. Er ændringer i modellen bagudkompatibel?

generelt er punktversionsændringer (5.1- > 5.2) bagudkompatible, og større Versionsændringer (4.0 – > 5.0) er muligvis ikke. Alle opdateringer til modellen er angivet i udgivelsesnotaterne for hver version, og alt, hvad der potentielt kan påvirke bagudkompatibilitet, er tydeligt mærket.

21. Hvor ofte ændres modellen?

den nuværende tidsplan er, at større versioner frigives hvert år, og at pointversioner frigives hvert kvartal, selvom det er underlagt samfundets behov.

22. Hvad er formidlingsplanen for ændringer?

ændringer vises først i udgivelsesnotaterne på github og i den fælles datamodel. Nye versioner annonceres også på de ugentlige community-opkald og på community-fora.

OHDSI værktøjer

23. Hvad er de aktuelt tilgængelige analytiske værktøjer?

mens der er en række værktøjer, der er frit tilgængelige fra samfundet, er disse de mest anvendte:

  • ACHILLES – et enkeltstående værktøj til databasekarakterisering
  • ATLAS-en integreret platform til ordforrådsudforskning, kohortdefinition, sagsvurdering, klinisk karakterisering, incidensestimering, estimeringsdesign på befolkningsniveau og forudsigelsesdesign på patientniveau (link til github)
  • ARACHNE – et værktøj til at lette distribuerede netværksanalyser
  • Hviskerabbit-en applikation til analyse af der kan bruges til at analysere strukturen og indholdet af en database som forberedelse til at designe en ETL
  • rabbitinahat-en ansøgning om interaktivt design af en ETL til Omop fælles datamodel ved hjælp af scanningsrapporten genereret af hvid kanin
  • Usagi – et program til at hjælpe med at skabe kortlægninger mellem kodningssystemer og ordforrådets standardkoncepter.

24. Hvem er ansvarlig for at opdatere værktøjerne til at tage højde for datamodelændringer, fejl og fejl?

fællesskabet! Alle værktøjerne er open source, hvilket betyder, at alle kan indsende et problem, de har fundet, tilbyde forslag og skrive kode for at løse problemet.

25. Tillader de nuværende værktøjer en bruger at definere et behandlingsgab (persistensvindue) af enhver værdi, når der oprettes behandlingsepisoder?

Ja – ATLAS-værktøjet giver dig mulighed for at angive et persistensvindue mellem lægemiddeleksponeringer, når du definerer en kohorte (se billedet nedenfor).

26. Kan de nuværende værktøjer identificere medicinbrug under graviditet?

ja, du kan identificere graviditetsmarkører fra forskellige kliniske domæner, herunder betingelser og procedurer, for eksempel ‘levende fødsel’, og derefter definere tidsmæssig logik for at se efter lægemiddeleksponeringsregistre i et interval inden graviditetens afslutning. Derudover har medlemmer af samfundet opbygget en avanceret logik til at definere graviditetsepisoder med alle graviditetsresultater repræsenteret, hvilket kan være nyttigt til denne type forskning.

27. Udfører de nuværende værktøjer mod de kortlagte værdier eller kildeværdier?

værktøjerne kan udføres mod både kilde-og kortlagte værdier, selvom kortlagte værdier opfordres kraftigt. Da et af målene med OHDSI er at skabe et distribueret datanetværk over hele verden, hvor man kan køre forskningsundersøgelser, undlader brugen af kildeværdier at udnytte fordelene ved den fælles datamodel.

Netværk Forskning Undersøgelser

28. Hvem kan generere anmodninger?

nogen i Fællesskabet! Ethvert spørgsmål, der får nok interesse og deltagelse, kan være en netværksundersøgelsesundersøgelse.

29. Hvem vil udvikle forespørgsler til at distribuere til netværket?

typisk leder en hovedforsker udviklingen af en protokol. PI kan også føre udviklingen af analyseproceduren svarende til protokollen. Hvis PI ikke har de tekniske færdigheder, der kræves for at skrive analyseproceduren, der implementerer protokollen, kan nogen i samfundet hjælpe dem med at sammensætte den.

30. Hvilket sprog er forespørgslerne skrevet på?

forespørgsler er skrevet i R og kvm. Den kan oversætte enhver forespørgsel skrevet i en templated server-lignende dialekt til nogen af de understøttede RDBMS miljøer, herunder Postgraduate, Oracle, Redshift, Parallel data lager, Hadoop Impala, Google Storforespørgsel, og Net.

31. Hvordan kommer forespørgslerne til datapartnerne, og hvordan køres de en gang der?

OHDSI kører som et distribueret datanetværk. Alle analyser er offentligt tilgængelige og kan hentes til at køre på hvert sted. Pakkerne kan køres lokalt, og efter datapartnerens skøn kan de samlede resultater deles med studiekoordinatoren.

datapartnere kan også gøre brug af et af OHDSIS open source-værktøjer kaldet ARACHNE, et værktøj til at lette distribueret netværksanalyse mod OMOP CDM.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.