Aiuto nella progettazione del database con un sottoinsieme di dati clinici rigoroso e strutturato

Question

Aiuto nella progettazione del database con un sottoinsieme di dati clinici rigoroso e strutturato

#1 da (2 voti)
#2 da (0 voti)
#3 da (-1 voti)

0

Sto sviluppando un'applicazione per mantenere alcuni dei dati in pazienti cronici, i dati provengono da un sottoinsieme molto rigido di dati, segni vitali, esami, ecc.

A prima vista ho pensato di creare un modello Patient con has_many incontri, e di inserire tutte le informazioni in un campo diverso come (età, altezza, peso, ecc), ma si tradurrebbe in un grande modello. Quindi mi sono interrogato sull'immersione per rendere più semplice la manutenzione e la scalabilità se in un paio di mesi ho bisogno di registrare un nuovo esame, in questo momento ho pensato a qualcosa di simile:

paziente

name: string,
address: string,
phone: integer,
diagnose: string,
etc...

Incontri

patient_id: ObjectID,
age: Integer,
vital_signs: [ { height, weight, bmi, systolic_pressure, diastolic_pressure } ],
exams: [ { creatinine, total cholesterol... } ],
next_encounter: Date

Avrò comunque bisogno di accedere a bmi per esempio se voglio ottenere quante persone nella comunità sono obese (suggerimento: un sacco di cose), quindi incorporare magari non è una buona idea. In ogni caso, tutte le "analisi" saranno effettuate solo mensilmente (o meno).

Ho scelto mongodb, perché temo che i requisiti per questo database cambino di volta in volta, quindi la flessibilità è importante.

Forse in questo caso poiché i dati sono strutturati, ogni documento avrà gli stessi tipi di campi, un database relazionale potrebbe essere migliore? Non penso che abbia senso usare un database nosql in un modo sql, giusto?

PS.- Ho letto questo articolo dal blog di mongodb, e sono più confuso se questo sia davvero l'approccio migliore.

database-design mongodb

posta Pablo Olmos de Aguilera C. 12.07.2014 - 22:45

fonte

3 risposte

Leggi altre domande sui tag database-design mongodb

Refactoring di un modello Single Rails con metodi di grandi dimensioni e lunghe query di join che cercano di fare tutto Diminuisce la probabilità di scegliere l'elemento di una lista in base al suo indice

score 2 · Answer 1

Maybe in this case since data is structured, every document will have the same types of fields, a relational database could be better?

Molto probabilmente.

I don't think it makes sense using a nosql database in a sql way, right?

No. Per esitare a indovinare, le persone inizieranno a farti domande come:

A che età era Bob Smith al terzo esame?
Quando il peso di john doe è sceso sotto i 90 kg?
Quanti esami abbiamo fatto su persone con ipertensione?

Quindi, leggi la modellazione dei dati, guarda alcuni altri schemi di esempio e vai a farlo.

score 0 · Answer 2

Pensieri -

Decisamente migliore in un RDBMS.
Verifica gli schemi standard esistenti per i dati medici. (HL7)
Commenti sulla struttura della tabella suggerita: -

paziente

name: string,
address: string,
phone: integer,
diagnose: string,
DOB Date (Date of Birth)
etc...

Incontri

patient_id: ObjectID,
Date_of_Examination: Date,

(Con Paziente Paziente, l'età del paziente può essere calcolata per l'Incontro)

vital_signs: [ { height, weight, bmi, systolic_pressure, diastolic_pressure } ],

(forse meglio scomporlo in due tabelle: tipi di segni vitali, segni vitali Encounter in caso di aggiunta di un nuovo tipo di osservazione)

exams: [ { creatinine, total cholesterol... } ],

(DEFINITAMENTE rompere questo in tipi di esame, esami di esame)

next_encounter: Date

score -1 · Answer 3

Qual è il caso d'uso dei dati, che riporta o semplicemente serve la funzionalità dell'app?

I database relazionali sono ottimi per strutturare i dati per la creazione di report, ma è possibile svilupparli più rapidamente con NoSQL perché se mancano i vincoli dello schema.