drug_concept_id - "... ETL to provide as much information as possible from the data" - where to cut off validity?

Aperta
  • Qualcosa non va?
#785 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Documentazione
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
html
Ambito
databases, documentation

Direzione di ricerca

Inizia dalla documentazione di CDM 5.4 drug_exposure collegata nell’issue, concentrandoti su drug_concept_id e sulle indicazioni di utilizzare quante più informazioni possibile. Esamina il paper su SICdb per gli esempi di validità, quindi determina quale cutoff e quale formulazione dovrebbe fornire la documentazione; il lavoro è completato quando è disponibile una raccomandazione concordata e documentata per gestire dettagli sui farmaci inaffidabili.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

I am an ICU dataset developer and publisher, with a research focus on data bias in routinely collected clinical data. When transforming the dataset to the OMOP CDM, I encountered the following issue.

Documentation notes, ETL should use "as much information as possible from the data" [1]. Nevertheless, it gives no guidance on data validity levels, although data that is not used in clinical practice is often highly invalid.

An example is the granularity of drug_concept_id.

Validity Estimation: (absolute numbers represent Salzburg University Hospital ICU Data (SICdb[2]) 2013-2021)

Ingredient: 3.8 % invalid entries (outliers etc.), (MAR estimated ~1%, MNAR probably insigificant)
Clinical Drug Component: Estimated 5-10% invalid data
Branded X: Estimated >50-80% invalid data

Example for invalidity Ingredient: 1 kg of paracetamole documented (wrong unit)
Example for Clinical Drug Component: 1.5 Units of Enoxaparin 40 mg applied (when changing dosage, product is not updated)

For Branded Drugs, as long as no closed-loop documentation is established, it is actually quite unlikely the exact product is applied. At least in Austria almost every branded drug changes regularily, different brands in same drawer. Without closed-loop it is not possible to document this.

At least at my units, the product information in templates is (almost at the point of setting up) outdated.

So, guidance would be needed. "...as much information as possible from the data" or "...as much reliable information as possible from the data", and where to cut of?

This may appliy to other topics too, but drug_concept_id is a good example.

  1. https://ohdsi.github.io/CommonDataModel/cdm54.html#drug_exposure
  2. https://doi.org/10.1038/s41597-024-03164-9
Lingua principale
HTML
Stelle
1.1k
Fork
515
Merge medio
8g 3h
PR unite (30g)
4

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di OHDSI/CommonDataModel

Tutte le issue di OHDSI/CommonDataModel

Issue simili

Altre issue su Databases

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.