Un modello di dati per tenere traccia dei tuoi beni più preziosi

Essere sani e in forma è uno stile di vita, non una moda passeggera. Le persone che realizzano il valore della salute ne fanno una priorità, tenendo traccia di tutti i loro fatti relativi alla forma fisica. In questo articolo esamineremo la progettazione del database alla base di un'applicazione per la salute e il fitness.

Esistono molte applicazioni che consentono agli utenti di registrare le proprie informazioni su salute e fitness. Un paio di grandi attori come Apple, Google e Microsoft hanno lanciato le proprie API di sviluppo appositamente per questo mercato. Ad esempio, Google ha "Fit" e Microsoft ha "HealthVault".

In questo articolo, spiegherò il modello di dati alla base di un'applicazione di cartelle cliniche. Per prima cosa, discutiamo esattamente di cosa ci aspetteremmo da un'app del genere.

Requisiti del progetto per un'app di informazioni sanitarie

Di seguito sono elencate alcune funzionalità che un'app di informazioni sulla salute dovrebbe supportare:

• Gli utenti possono creare un account e archiviare informazioni sanitarie per più profili, ovvero un individuo può archiviare informazioni sanitarie per tutti i membri della sua famiglia.
• Gli utenti possono registrare la loro intera storia sanitaria, comprese immunizzazioni, risultati di laboratorio passati, allergie e anamnesi familiare .
• Gli utenti possono memorizzare varie misurazioni della salute e della forma fisica, come i livelli di glucosio nel sangue (glicemia), la pressione sanguigna, la composizione corporea e le dimensioni, inclusi l'indice di massa corporea (BMI), il colesterolo, l'altezza, il peso, la salute riproduttiva, ecc.
• Le informazioni possono essere registrate utilizzando vari metodi e unità di misura . Ad esempio, la glicemia può essere misurata in mg/dL o mmol/L.
• Non ci sono limiti alla quantità di informazioni che gli utenti possono archiviare.
• Il sistema conterrà anche gli standard sanitari accettati, come la pressione sanguigna o i numeri di BMI, e avviserà gli utenti se i loro numeri non rientrano negli intervalli "sicuri" o "normali".
• Gli utenti possono anche scegliere informazioni (come glicemia, altezza, peso, ecc.) da visualizzare sulla propria dashboard personale. In questo modo, possono monitorare tutto ciò di cui hanno bisogno.

Invece di spiegare semplicemente cosa fa ogni sezione e tabella nel modello di dati, rispondiamo ad alcune domande al riguardo. La funzione delle varie tabelle diventerà chiara man mano che procediamo.

Per prima cosa, se lo desideri, puoi guardare il modello di dati completo.

Il modello di dati

Rispondere alle domande sul modello di dati sulle informazioni sanitarie

In che modo gli utenti possono archiviare individualmente le informazioni sanitarie per tutti i membri della loro famiglia?

Innanzitutto, parliamo di Gestione account e profilo . Ciò può essere ottenuto disponendo di due tabelle diverse; uno (user_account ) per registrare i dettagli delle persone che si registrano con l'applicazione e uno (user_profile ) per la registrazione dei dettagli di tutti i diversi profili creati da un utente registrato. Le persone possono creare una serie di profili, ad es. uno per ciascuno dei suoi familiari.

Diamo un'occhiata alle varie tabelle che lo rendono possibile.

Il user_account la tabella contiene i dettagli di base sulla persona che si registra con l'applicazione. Le sue colonne sono:

• id –Una colonna chiave surrogata per questa tabella che identifica ogni utente in modo univoco.
• login_name – Il nome o altro ID scelto dall'utente come nome di accesso. È necessario imporre un vincolo univoco a questa colonna per garantire che ogni nome di accesso sia diverso.
• enc_password – La password dell'account selezionata dall'utente, in forma crittografata.
• colonne di indirizzi – Memorizza l'indirizzo e i dettagli di contatto degli utenti al momento della registrazione. Queste colonne includono street_address , city , state , country e zip . Poiché questi campi sono facoltativi nel processo di registrazione, ho mantenuto queste colonne come nullable.
• contact_number e email – Memorizza il numero di contatto dell'utente (ovvero il numero di telefono) e il suo indirizzo e-mail. Anche questi campi fanno parte del processo di registrazione, ma non sono annullabili.
• is_active – Contiene una "Y" o una "N" per indicare se un account è attualmente attivo.
• account_image – Gli utenti possono caricare le proprie immagini. Poiché un utente può caricare zero o (massimo) un'immagine per account, questa è una colonna di tipo BLOB nullable.

Il user_profile la tabella memorizza i dettagli di tutti i profili creati dagli utenti registrati. Le colonne di questa tabella sono:

• id – Un numero univoco assegnato a ogni nuovo profilo.
• user_account_id – Indica quale utente ha creato il profilo.
• user_profile_name – Memorizza il nome della persona nel profilo. (Chiameremo questa persona la "persona del profilo" e l'utente che crea i profili il "titolare del conto".)
• relationship_id – Indica la relazione tra il titolare del conto e la persona del profilo. Questa colonna fa riferimento alla relationship tabella, che contiene tutti i possibili tipi di relazioni (come self , madre , padre , sorella , fratello , figlio , figlia , animale domestico , ecc).
• email – Questa colonna contiene l'indirizzo email della persona del profilo. Rapporti o altre informazioni sarebbero stati condivisi con loro tramite questa e-mail; informazioni verrebbero inviate anche al titolare del conto. Ad esempio, se Melissa ha creato un profilo per sua figlia Eva, le informazioni di Eva verrebbero inviate all'e-mail di Melissa e possibilmente all'e-mail di Eva – vedi sotto.
• is_report_sharing_enabled – I rapporti sono sempre condivisi con il titolare dell'account, ma è facoltativo condividere questi dati con la persona del profilo. Questa colonna mostra se le informazioni verranno condivise con la persona del profilo.
• is_active – Identifica se un profilo è attualmente attivo. Questa è una funzione di eliminazione temporanea nel caso in cui i profili vengano eliminati accidentalmente.
• profile_image – Memorizza un'immagine della persona del profilo. Questo attributo è facoltativo e quindi annullabile.

I characteristic_data la tabella contiene i dettagli del profilo individuale (come il gruppo sanguigno) che non cambiano mai nel tempo. Tutte le colonne di questa tabella sono autoesplicative tranne fitzpatrick_skin_type , che classifica la natura della propria pelle partendo da I (si brucia sempre, non si abbronza mai) a VI (non si brucia mai, nessun cambiamento di aspetto quando si abbronza).

Ho aggiunto due colonne per genere; biological_gender indica il proprio sesso al momento della nascita e current_gender indica il sesso attuale della persona del profilo. Questa seconda colonna è applicabile solo alle persone transgender, e quindi l'ho mantenuta nullable.

Quali informazioni vitali possono essere memorizzate in questo sistema? Come viene memorizzato?

Ora passiamo a Gestione dei dati sanitari . La composizione corporea, i livelli di glucosio nel sangue e le dimensioni corporee sono memorizzati in tabelle separate. Tuttavia le persone possono inserire più di un tipo di informazioni alla volta, quindi utilizziamo il body_vitals_log tabella per tenere traccia di quali informazioni sono registrate in un profilo e quando vengono immesse.

Tutte le statistiche vitali sono conservate nelle seguenti tabelle:

• body_composition – Memorizza dettagli su varie percentuali di composizione corporea come grasso, massa magra, ossa o acqua. Contiene anche valori di BMI (indice di massa corporea) per gli individui.
• blood_cholesterol – Contiene dettagli sul colesterolo come LDL, HDL, trigliceridi e totale.
• body_dimension – Registra le dimensioni di varie zone del corpo, come le misure della vita o del torace.
• body_weight – Memorizza i valori per il peso corporeo.
• body_height – Contiene i valori per l'altezza di una persona.
• blood_pressure – Contiene i valori della pressione sanguigna (sistolica e diastolica).
• blood_glucose – Registra i livelli di glucosio nel sangue.

La maggior parte delle colonne nelle tabelle precedenti sono autoesplicative, con poche eccezioni. Noterai alcune colonne aggiuntive come measurement_method_id , compare_to_normal_id , measurement_unit_id e measurement_context in quasi tutte queste tabelle. Spiegherò queste colonne più avanti.

Il body_vitals_log tiene traccia di quali informazioni vengono registrate in un determinato momento per un profilo. Le colonne di questa tabella sono:

• user_profile_id – Mostra quale profilo sta registrando le informazioni.
• dt_created – Memorizza la data e l'ora in cui vengono immesse le informazioni.
• data_source_id – Indica la fonte dei dati, come un manuale, un dispositivo elettronico, ecc.
• ID di varie statistiche vitali – Ho mantenuto tutte queste colonne annullabili, poiché gli utenti possono registrare uno o più elementi alla volta. Non tutti gli utenti vorranno monitorare le stesse statistiche sulla salute.

Come possiamo far funzionare il sistema in diverse regioni?

Alcune informazioni sono misurate in diverse unità in varie aree. Ad esempio, il peso corporeo è misurato in chilogrammi in Asia, ma è misurato in libbre in Nord America. Quindi, per renderlo praticabile nel nostro database, abbiamo bisogno di un modo per tenere traccia delle unità di misura.

• id – Serve come chiave primaria di questa tabella ed è quella a cui fanno riferimento le altre tabelle.
• measurement_parameter – Indica il tipo di informazioni vitali (come peso, altezza, pressione sanguigna, ecc.) misurate da un'unità.
• unit_name – Memorizza il nome dell'unità. Pensa a chilogrammo e libbra per il peso, mg/dL e mmol/L per la glicemia.

Come faranno le persone a sapere se i loro numeri sono buoni?

Il nostro sistema non è di grande aiuto a meno che non avverta le persone di rischi o vulnerabilità per la salute. Abilitiamo questa funzione aggiungendo il comparison_to_normal_id colonna in tutte le tabelle di dati di informazioni vitali.

Quando qualsiasi nuova informazione vitale viene registrata nel sistema, i record verranno confrontati con i valori di riferimento corrispondenti e questa colonna verrà impostata di conseguenza.

I valori possibili per questa tabella sono:

Gli utenti possono registrare quando sono state effettuate le misurazioni?

Ad esempio, gli utenti potrebbero dover indicare quando è stata misurata la glicemia, ovvero prima o dopo un pasto. Oppure possono pesarsi e registrare i risultati prima e dopo l'esercizio. Per facilitare ciò, ho aggiunto una colonna, measurement_context , nelle tabelle delle informazioni vitali che potrebbero richiedere informazioni contestuali. Di seguito sono riportati alcuni possibili valori per questa colonna:

Cosa succede se una persona è diabetica e ha bisogno di monitorare i propri livelli di glucosio nel sangue?

Il sistema che sto proponendo avrà una dashboard in grado di visualizzare statistiche vitali in formato grafico. Gli utenti possono scegliere cosa vogliono vedere nella dashboard del proprio profilo e ogni profilo ha la propria dashboard. I titolari di account possono vedere tutte le dashboard dei profili che hanno creato.

Ho aggiunto una colonna CHAR(1) per ogni parametro che può essere mostrato su un dashboard. Per impostazione predefinita, tutte le colonne vengono popolate con "N" (la visualizzazione è disattivata) quando viene creato un nuovo profilo. Gli utenti possono successivamente modificare la configurazione della dashboard da un'opzione nell'interfaccia utente dell'app.

In che modo questo sistema aiuta le persone a mantenersi in forma?

In altre parole, stiamo parlando di Archiviazione dati fitness . Oltre alle informazioni sulla salute, il sistema consente anche ai propri utenti di registrare informazioni sulla propria forma fisica e sulle routine di allenamento.

Il activity_log table è la tabella principale in questa area tematica. Cattura i dettagli su ogni tipo di profilo di attività che le persone svolgono.

Ogni attività può essere misurata da uno o più dei seguenti tre parametri:

• Ora di inizio e fine – Attività come fare sport o giochi, stare in coda, ecc. vengono misurate in termini di ora di inizio e di fine. Questo viene fatto tramite start_time e end_time colonne in activity_log .
• Distanza percorsa – Attività come la corsa o il ciclismo sono misurate in termini di distanza percorsa. Questo è memorizzato nel distance_covered colonna.
• Conteggio passi – Attività come camminare sono misurate in termini di conteggi di passi e i valori sono memorizzati in steps_count colonna.

Ti starai chiedendo perché le calories_burnt la colonna si trova nel activity_log tavolo. Come suggerisce il nome, questa colonna contiene il valore delle calorie bruciate dalla persona del profilo mentre svolge una particolare attività. Spiegherò come possiamo calcolare questi valori in una sezione successiva.

Ho creato una tabella denominata activity per tenere un elenco di tutte le attività possibili. Le colonne di questa tabella sono:

• id – Assegna un numero ID univoco a ciascuna attività.
• activity_name – Memorizza i nomi delle attività.
• activity_multiplier – Questa colonna svolge un ruolo chiave nel calcolo del numero di calorie bruciate dalle persone che svolgono attività.

Come calcoli le calorie bruciate per ogni attività?

Per capire come calcolare il consumo calorico, dobbiamo prima capire il BMR di una persona, o metabolismo basale. Questo ci dice quante calorie brucia un corpo a riposo. Il BMR di ogni persona dipende dal sesso, dall'età, dal peso e dall'altezza. Dal punto di vista della modellazione dei dati, un BMR è una dimensione che cambia lentamente e, in quanto tale, continua a cambiare nel tempo. Conserveremo gli ultimi valori BMR individuali in user_bmr tavolo.

Esistono vari metodi utilizzati per calcolare i valori BMR:

Metodo n. 1:metodo Harris-Benedetto

BMR Uomini:66 + (6,23 X di peso in libbre) + (12,7 X di altezza in pollici) – (6,8 X di età)

BMR Donne:655 + (4,35 X di peso in libbre) + (4,7 X di altezza in pollici) – (4,7 X di età)

Metodo n. 2:metodo Katch-McArdle

BMR (uomini + donne):370 + (21,6 * massa magra in chilogrammo)

Massa magra =peso in chilogrammo – (peso in chilogrammo * grasso corporeo %)

Possiamo usare il BMR di una persona e il moltiplicatore di attività sopra menzionato per scoprire quante calorie brucia una persona quando fa una determinata attività. La formula è:

Calorie bruciate =moltiplicatore di attività * BMR

Nota:entrambi i metodi di calcolo del BMR sopra indicati utilizzano gli stessi valori moltiplicatori per le attività. Per ulteriori informazioni, vedere questo articolo.

Possiamo mantenere i valori BMR storici dei profili?

Sì. Possiamo archiviare i valori BMR in user_bmr_archive tavolo.

Iniziamo aggiungendo una colonna, id_version , al user_bmr tavolo. Continuiamo ad aumentare questo valore di 1 ogni volta che viene aggiornato il valore BMR di una persona del profilo.

Il user_bmr_archive table è quasi una replica di user_bmr tavolo. L'unica differenza è che ha un dt_expired colonna invece di dt_created e dt_modified colonne. Il dt_expired la colonna memorizza la data in cui la versione è diventata non valida, ovvero quando il valore BMR viene aggiornato in user_bmr .

Cosa succede se gli utenti vogliono tenere un registro delle loro vaccinazioni, anamnesi familiare e allergie?

Questo sistema sfrutta le seguenti tabelle per offrire agli utenti la possibilità di memorizzare ulteriori informazioni sulla salute.

Il immunization la tabella memorizza i dettagli sulle vaccinazioni ricevute dalle persone del profilo. Dopo l'esempio, vedrai una breve descrizione delle colonne che contiene questa tabella:

Esempio – John Soo ha ricevuto la seconda di tre dosi di un vaccino contro l'epatite B. È stato somministrato dal Dr. David Moore il 28 novembre 2016. La vaccinazione è stata somministrata mediante un'iniezione nella mano sinistra. È prodotto da Cipla (un'azienda farmaceutica).

• id – La chiave primaria di questa tabella
• user_profile_id – Fa riferimento a user_profile_ID di John Soo
• vaccination_name – “Epatite B”
• dt_received – “28 novembre 2016”
• number_in_sequence – “02”
• body_area_id – L'ID della mano sinistra, riferito da body_area tavola
• provider_name – “Dott. David Moore”
• how_administered – "Iniettato" (altri valori possibili includono spray nasale, compresse, gocce, sciroppo )
• manufacturer – “Cipla”

L'allergy la tabella memorizza i dettagli su eventuali allergie sperimentate dalle persone del profilo. Di seguito è riportato l'elenco delle colonne, con i relativi valori forniti per ciascuna come nell'esempio:

Esempio – Alison D'Souza ha la tosse quando mangia lo yogurt. Ha avuto questa reazione per la prima volta quando aveva 8 anni. Consulta il dottor Bill Smith, che prescrive alcune medicine e consiglia alcune precauzioni. Questa allergia persiste ancora, ma la sua intensità è ora più bassa.

• id – La chiave primaria della tabella
• user_profile_id – Rsi riferisce a user_profile_id di Alison D'Souza
• allergy_type_id – Fa riferimento all'ID del tipo di allergia "Cibo" nel allergy_type tavolo. (Il allergy_type la tabella definisce vari tipi di allergia come cibo, farmaci, ambientali, animali, vegetali, ecc.)
• allergy_reaction_id – Fa riferimento all'ID della reazione allergica "Tosse" nel allergy_reaction tabella.
• first_observed – La data in cui questa reazione è stata osservata per la prima volta, ovvero quando Alison aveva 8 anni.
• consulting_doctor_name – “Dott. Bill Smith”
• treatment_brief – Una breve descrizione dei medicinali prescritti e delle precauzioni raccomandate.
• does_treatment_cure_allergy – “Parzialmente guarito. Intensità di reazione ridotta."

Il family_history la tabella memorizza i dettagli sulla storia medica familiare degli utenti. Ancora una volta, abbiamo elencato le colonne e il tipo di informazioni che verrebbero archiviate in esse in base al seguente esempio.

Esempio – La madre di Diana, Lisa, ha il morbo di Parkinson (un disturbo neurologico). È stata sottoposta a cure, ma non ha ottenuto miglioramenti tangibili.

• id – la chiave primaria della tabella
• user_profile_id – L'user_profile_ID di Diana dal user_profile tavola
• Relationship_id – L'ID "madre" dalla relationship tavola
• Relative_name – “Lisa”
• Date_of_birth – Data di nascita di Lisa
• Date_of_death – NULL (Lisa è ancora viva e sta lottando duramente contro la malattia.)
• Condition_brief – Una breve descrizione di come, quando e dove è iniziata la condizione, consultazioni, eventuali soccorsi, ecc.
• Current_status – "Corrente" (Altri stati possibili sono "Intermittente" e "Passato").
• How_it_ended – NULLO

Cosa aggiungeresti a questo modello di dati?

Il sistema consente alle persone di sapere quante calorie bruciano mentre svolgono varie attività, ma non tiene traccia di quante calorie consumano o di quanto siano nutrienti le loro scelte alimentari. Inoltre, il sistema consente loro di registrare i propri dati di fitness su base giornaliera, ma non consente loro di fissare un obiettivo, formulare un piano e tenere traccia dei propri progressi in modo che rimangano motivati.

Dovremmo considerare di incorporare queste funzionalità in esso? Quali modifiche devono essere apportate per aggiungere queste funzionalità?

Facci sapere le tue idee!