OMOP CDM Ofte Stilte Spørsmål

1. JEG forstår at common data model (CDM) er en måte å organisere ulike datakilder i samme relasjonsdatabasedesign, men hvordan kan det være effektivt siden mange databaser bruker forskjellige kodingsordninger?

under uttrekk, transform, load (ETL) prosessen med å konvertere en datakilde til omop common data model, standardiserer vi strukturen (f. eks. tabeller, felt, datatyper), konvensjoner (f. eks. regler som styrer hvordan kildedata skal representeres) og innhold (f. eks. hvilke vanlige vokabular brukes til å snakke samme språk på tvers av kliniske domener). Common data model bevarer alle kildedata, inkludert de opprinnelige kilde vokabular koder, men legger til standardiserte vokabular for å tillate nettverk forskning på TVERS AV HELE OHDSI forskningsmiljø.

2. Hvordan blir dataene mine forvandlet til den vanlige datamodellen?

du eller noen i organisasjonen må opprette en prosess for å bygge DIN CDM. Ikke bekymre deg, du er ikke alene! Samfunnets åpne natur betyr at mye av koden som andre deltakere har skrevet for å transformere sine egne data, er tilgjengelig for deg å bruke. Hvis du har en datalisens for en stor administrativ kravdatabase som IBM MarketScan® eller Optums Clinformatics® Extended Data Mart, er sjansen stor for at noen allerede har gjort legarbeidet. Her er et eksempel på en fullbygger fritt tilgjengelig på github som er skrevet for en rekke datakilder.

fellesskapsforaene er også et flott sted å stille spørsmål hvis du sitter fast eller trenger veiledning om hvordan du representerer dataene dine i den vanlige datamodellen. Medlemmer er vanligvis svært responsive!

3. Er noen tabeller eller felt valgfrie?

det forventes at alle tabeller vil være til STEDE I EN CDM, selv om det ikke er et krav at de alle er fylt ut. De to obligatoriske tabellene er:

  • Person: inneholder poster som unikt identifiserer hver pasient i kildedataene som er i fare for å ha kliniske observasjoner registrert i kildesystemene.
  • Observation_period: Inneholder poster som unikt definerer tidsrom som En Person er i fare for å ha kliniske hendelser registrert i kildesystemene.

det er da opp til deg hvilke tabeller som skal fylles ut, selv om kjernehendelsestabellene generelt er enige om Å Være Condition_occurrence, Procedure_occurrence, Drug_exposure, Measurement og Observation. Hver tabell har visse obligatoriske felt, en fullstendig liste over disse finner du på Common Data Model wiki-siden.

4. Inneholder datamodellen avledet informasjon? Hvilke tabeller eller verdier er avledet?

common data model lagrer ordrett data fra kilden på tvers av ulike kliniske domener, for eksempel poster for forhold, narkotika, prosedyrer og målinger. I tillegg, for å hjelpe analytikeren, gir common data model også noen avledede tabeller, basert på vanlige analytiske prosedyrer. For eksempel Er Condition_era-tabellen avledet fra Condition_occurrence-tabellen, og Både Drug_era-og Dose_era-tabellene er avledet fra Drug_exposure-tabellen. En era er definert som et tidsrom når en pasient antas å ha en gitt tilstand eller eksponering for en bestemt aktiv ingrediens. Medlemmer av samfunnet har skrevet kode for å lage disse tabellene, og det er ute på github hvis du velger å bruke DEN I CDM-bygningen. Det er viktig å styrke, analytikeren har mulighet, men ikke plikt, til å bruke noen av de avledede tabellene, og alle kildedataene er fortsatt tilgjengelige for direkte bruk dersom analysen krever forskjellige forutsetninger.

5. Hvordan er alder fanget i modellen?

Year_of_birth, month_of_birth, day_of_birth og birth_datetime er alle felt I Persontabellen designet for å fange noen form for fødselsdato. Mens bare year_of_birth er nødvendig, tillater disse feltene maksimal fleksibilitet over et bredt spekter av datakilder.

6. Hvordan er kjønn, rase, og etnisitet fanget i modellen? Er de kodet ved hjelp av verdier en menneskelig leser kan forstå?

Standardkonsepter brukes til å betegne alle kliniske enheter gjennom omops felles datamodell, inkludert kjønn, rase og etnisitet. Kildeverdier er kartlagt Til Standard Konsepter under ekstrakt, transform, load (ETL) prosessen med å konvertere en database TIL Omop Common Data Model. Disse lagres deretter I feltene Gender_concept_id, Race_concept_id og Ethnicity_concept_id i Persontabellen. Fordi standardkonseptene spenner over alle kliniske domener, og i tråd med Ciminos ‘Desiderata For Controlled Medical Vocabularies in The Twenty-First Century’, er identifikatorene unike, vedvarende nonsematiske identifikatorer. Kjønn, for eksempel, lagres som enten 8532 (kvinne) eller 8507 (mann) i gender_concept_id mens den opprinnelige verdien fra kilden lagres i gender_source_value(m, mann, F, etc).

7. Er det forhold / prosedyrer / narkotika eller andre domener som skal maskeres eller skjules i CDM?

maskeringen av informasjon relatert til en person er avhengig av organisasjonens retningslinjer for personvern og kan variere etter dataressurs (themis issue #21).

8. Hvordan behandles tidsvarierende pasientinformasjon som bostedssted i modellen?

omops felles datamodell er pragmatisk definert basert på de ønskede analysetilfellene i fellesskapet, samt de tilgjengelige datatypene som fellesskapsmedlemmer har tilgang til. FØR CDM v6. 0 hadde hver personoppføring tilhørende demografiske attributter som antas å være konstante for pasienten i løpet av deres observasjonsperioder, som sted og primærhelsetjenesteleverandør. Med utgivelsen AV CDM v6.0 Er Location_History-tabellen nå tilgjengelig for å spore bevegelsene til mennesker, omsorgssteder og leverandører over tid. Bare den nyeste location_id skal lagres I Persontabellen for å eliminere duplisering, mens personens bevegelser lagres I Location_History.

noe som sivilstatus er litt annerledes da det anses å være en observasjon i stedet for en demografisk egenskap. Dette betyr at Den er plassert i Observasjonstabellen i stedet For Persontabellen, noe som gir mulighet til å lagre hver endring i status som en unik post.

hvis noen i samfunnet hadde en brukstilfelle for tidsvarierende bostedssted og også hadde kildedata som inneholder denne informasjonen, vil vi gjerne delta i CDM-arbeidsgruppen for å utvikle modellen videre.

9. Hvordan angir modellen tidsperioden hvor En Persons informasjon er gyldig?

Omops Felles Datamodell bruker noe som kalles observasjonsperioder (lagret I Observation_period-tabellen) som en måte å definere tidsperioden der en pasient er i fare for å få registrert en klinisk hendelse. I administrative kravdatabaser, for eksempel, er disse observasjonsperiodene ofte analoge med begrepet ‘innmelding’.

10. Hvordan modell fangst start og stopp datoer for forsikringsdekning? Hva om en persons dekning endres?

Payer_plan_period-tabellen fanger opp detaljer om tidsperioden som En Person kontinuerlig er registrert under en bestemt Helseplanfordelingsstruktur fra en gitt Betaler. Betalerplanperioder, i motsetning til observasjonsperioder, kan overlappe for å betegne tiden når En Person er registrert i flere planer samtidig, For Eksempel Medicare Part A og Medicare Part D.

11. Hva om JEG har EPJ-data? Hvordan oppretter jeg observasjonsperioder?

en observasjonsperiode regnes som tiden da en pasient er i fare for å få en klinisk hendelse registrert i kildesystemet. Bestemme riktig observasjonsperiode for hver kilde data kan variere, avhengig av hvilken informasjon kilden inneholder. Hvis en kilde ikke gir informasjon om pasientens inngang eller utgang fra et system, må rimelig heuristikk utvikles og brukes i ETL.

Vokabular Kartlegging

12. Må jeg tilordne kildekodene Mine Til Standardkonsepter selv? Er det vokabular kartlegginger som allerede eksisterer for meg å utnytte?

hvis dataene dine bruker noen av de 55 kildevokabularene som støttes, er tilordningene gjort for deg. Hele listen er tilgjengelig fra OPEN-source ATHENA-verktøyet under nedlastingsfanen (se nedenfor). Du kan velge å laste ned de ti ordforrådstabellene derfra også – du trenger en kopi i ditt miljø hvis du planlegger å bygge EN CDM.

ATHENA-verktøyet lar deg også utforske vokabularet før du laster det ned hvis du er nysgjerrig på mappingene, eller hvis du har en bestemt kode i tankene og ønsker å vite hvilket standardkonsept det er knyttet til; bare klikk på søkefanen og skriv inn et søkeord for å begynne å søke.

13. Hvis jeg vil bruke kartleggingene selv, kan jeg gjøre det? Er de gjennomsiktige for alle brukere?

ja, alle kartlegginger er tilgjengelige I Concept_relationship-tabellen (som kan lastes ned fra ATHENA). Hver verdi i en støttet kildeterminologi er tildelt En Concept_id(som anses som ikke-standard). Hver Source_concept_id vil ha en tilordning Til En Standard_concept_id. Eksempelvis:

I dette tilfellet vil STANDARD SNOMED concept 201826 for type 2 diabetes mellitus bli lagret I Condition_occurrence tabellen som Condition_concept_id OG ICD10CM concept 1567956 for type 2 diabetes mellitus bli lagret Som Condition_source_concept_id.

14. Kan rxnorm-koder lagres i modellen? Kan jeg lagre flere nivåer hvis jeg ønsker det? Hva om en samarbeidspartner bruker Et annet Nivå Av RXNorm enn jeg bruker når jeg omdanner databasen?

I Omops Felles Datamodell anses RXNorm som standardordforrådet for å representere legemiddeleksponeringer. En av de store tingene Om Standardisert Vokabular er At den hierarkiske natur RXNorm er bevart for å muliggjøre effektiv spørring. Det er avtalt beste praksis å lagre det laveste nivået RXNorm tilgjengelig og deretter bruke Vokabular for å utforske eventuelle relevante relasjoner. Narkotika ingredienser er forfedre på høyeste nivå, så en spørring for etterkommerne av en ingrediens bør slå opp alle legemidler (Klinisk Legemiddel eller Merket Stoff) som inneholder den ingrediensen. En spørring utformet på denne måten vil finne narkotika av interesse i NOEN CDM uavhengig Av Nivået Av rxnorm brukes.

15. Hva om vokabularet har en kartlegging jeg ikke er enig med? Kan det endres?

Ja, det er skjønnheten i samfunnet! Hvis du finner en kartlegging i vokabularet som ikke ser ut til å tilhøre eller som du tror kan være bedre, kan du skrive et notat på forumene eller på vokabularet github. Hvis samfunnet er enig med din vurdering vil det bli behandlet i neste vokabular versjon.

16. Hva om jeg har kildekoder som er spesifikke for nettstedet mitt? Hvordan skal disse kartlegges?

I Omops Ordforråd er det et tomt bord kalt Source_to_concept_map. Det er en enkel tabell struktur som lar deg etablere kartlegging (e) for hver kildekode med en standard konsept I Omop Vokabular (TARGET_CONCEPT_ID). DETTE arbeidet kan tilrettelegges AV OHDSI tool Usagi (bildet nedenfor) som søker etter tekstlikhet mellom kildekoden beskrivelser og Omop Vokabular og eksport kartlegginger i EN SOURCE_TO_CONCEPT_MAP tabellstruktur. Eksempel Source_to_concept_map filer kan bli funnet her. Disse genererte Source_to_concept_map filer blir deretter lastet inn I Omop Vokabular tomme Source_to_concept_map før behandling av innfødte data INN I CDM slik AT CDM builder kan bruke dem i en build.

hvis en kildekode ikke støttes AV Omop Vokabular, kan man opprette en ny poster I KONSEPTET tabellen, Men CONCEPT_IDs bør starte > 200000000, slik at det er lett å fortelle mellom Omop Vokabular konsepter og stedsspesifikke begreper. NÅR disse begrepene eksisterer CONCEPT_RELATIONSHIPS kan genereres for å tildele dem til en standard terminologier, KAN USAGI lette denne prosessen også (themis issue #22).

17. Hvordan brukes en-til-mange-kartlegginger?

hvis en kildekode tilordner To Standardkonsepter, lagres to rader i den tilsvarende kliniske hendelsestabellen.

18. Hva om jeg vil beholde mine opprinnelige data og de tilordnede verdiene? Er det en måte for meg å gjøre det?

Ja! Kildeverdier og Kildekonsepter er fullt vedlikeholdt innenfor OMOPS Felles Datamodell. Et Kildebegrep representerer koden i kildedataene. Hvert Kildekonsept er kartlagt til Ett Eller Flere Standardkonsepter under ETL-prosessen, og begge lagres i den tilsvarende kliniske hendelsestabellen. Hvis ingen tilordning er tilgjengelig, skrives Standardkonseptet med concept_id = 0 inn i * _concept_id-feltet (Condition_concept_id, Procedure_concept_id, Etc.) for å bevare posten fra de innfødte dataene.

Versjonskontroll Av Felles Datamodell

19. Hvem bestemmer når og hvordan man endrer datamodellen?

fellesskapet! Det er en arbeidsgruppe designet rundt oppdatering av modellen, og alt er gjort ved konsensus. Medlemmene sender forslag til endringer til github i form av saker og gruppen møtes en gang i måneden for å diskutere og stemme på endringene. Eventuelle ratifiserte forslag legges deretter til i køen for en fremtidig versjon Av Common Data Model.

20. Er endringer i modellen bakoverkompatibel?

vanligvis punktversjonsendringer (5.1 -> 5.2) er bakoverkompatible, og store versjonsendringer (4.0 -> 5.0) er kanskje ikke det. Alle oppdateringer av modellen er oppført i versjonsmerknadene for hver versjon, og alt som potensielt kan påvirke bakoverkompatibiliteten er tydelig merket.

21. Hvor ofte endres modellen?

gjeldende tidsplan er at hovedversjoner skal utgis hvert år, og punktversjoner skal utgis hvert kvartal, selv om det er underlagt samfunnets behov.

22. Hva er formidlingsplanen for endringer?

Endringer er først oppført i versjonsmerknadene på github og i common data model wiki. Nye versjoner blir også annonsert på de ukentlige fellesskapssamtalene og på fellesskapsfora.

OHDSI Verktøy

23. Hva er de tilgjengelige analyseverktøyene?

Mens det finnes en rekke verktøy fritt tilgjengelig fra samfunnet, er disse de mest brukte:

  • ACHILLES – et frittstående verktøy for databasekarakterisering
  • ATLAS-en integrert plattform for vokabularutforskning, kohortdefinisjon, saksgjennomgang, klinisk karakterisering, forekomstestimering, estimeringsdesign på populasjonsnivå og prediksjonsdesign på pasientnivå (lenke til github)
  • ARACHNE – et verktøy for å lette distribuerte nettverksanalyser
  • WhiteRabbit-et program som kan brukes til å analysere strukturen og innholdet i en database som forberedelse til Å DESIGNE en etl
  • rabbitinahat-EN SØKNAD om interaktiv design AV EN ETL TIL Omop Common Data Model ved hjelp av skanningsrapporten generert Av White Rabbit
  • Usagi-et program for å bidra til å lage kartlegginger mellom kodesystemer og Ordforrådets standardkonsepter.

24. Hvem er ansvarlig for å oppdatere verktøyene for å ta hensyn til datamodellendringer, feil og feil?

fellesskapet! Alle verktøyene er åpen kildekode, noe som betyr at alle kan sende inn et problem de har funnet, gi forslag og skrive kode for å fikse problemet.

25. Tillater de nåværende verktøyene en bruker å definere et behandlingsgap (persistensvindu) av noen verdi når man oppretter behandlingsepisoder?

ja-ATLAS-verktøyet lar deg angi et vedvarende vindu mellom legemiddeleksponeringer når du definerer en kohort (se bildet nedenfor).

26. Kan dagens verktøy identifisere bruk av medisiner under graviditet?

ja, du kan identifisere graviditetsmarkører fra ulike kliniske domener, inkludert tilstander og prosedyrer, for eksempel ‘levende fødsel’, og deretter definere tidsmessig logikk for å se etter legemiddeleksponeringsregistre i et visst intervall før graviditetens slutt. I tillegg har medlemmer av samfunnet bygget en avansert logikk for å definere graviditetsepisoder med alle graviditetsutfall representert, noe som kan være nyttig for denne typen forskning.

27. Kjører de gjeldende verktøyene mot de tilordnede verdiene eller kildeverdiene?

verktøyene kan utføres mot både kilde-og kartlagte verdier, men kartlagte verdier oppfordres sterkt. SIDEN ET AV MÅLENE MED OHDSI er å skape et distribuert datanettverk over hele verden for å drive forskningsstudier, unnlater bruken av kildeverdier å dra nytte av fordelene Med Den Felles Datamodellen.

Nettverk Forskningsstudier

28. Hvem kan generere forespørsler?

Alle i samfunnet! Eventuelle spørsmål som får nok interesse og deltakelse kan være et nettverk forskningsstudie.

29. Hvem skal utvikle spørringene for å distribuere til nettverket?

Vanligvis leder en hovedforsker utviklingen av en protokoll. PI kan også lede utviklingen av analyseprosedyren som svarer til protokollen. HVIS PI ikke har de tekniske ferdighetene som kreves for å skrive analyseprosedyren som implementerer protokollen, kan noen i samfunnet hjelpe dem med å sette den sammen.

30. Hvilket språk er spørsmålene skrevet på?

Spørringer er skrevet I R og SQL. SqlRender-pakken kan oversette alle spørringer skrevet i EN malbasert SQL Server-lignende dialekt til noen av DE støttede RDBMS-miljøene, inkludert Postgresql, Oracle, Redshift, Parallel Data Warehouse, Hadoop Impala, Google BigQuery og Netezza.

31. Hvordan kommer spørringene til datapartnerne og hvordan kjøres de en gang der?

OHDSI kjører som et distribuert datanettverk. Alle analyser er offentlig tilgjengelige og kan lastes ned for å kjøre på hvert nettsted. Pakkene kan kjøres lokalt, og etter datapartnerens skjønn kan aggregerte resultater deles med studiekoordinatoren.

datapartnere kan også benytte SEG AV ET AV OHDSIS open source-verktøy KALT ARACHNE, et verktøy for å lette distribuert nettverksanalyse mot OMOP CDM.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert.