Een gegevensmodel om uw kostbaarste bezit bij te houden

Gezond en fit zijn is een levensstijl, geen modegril. Mensen die de waarde van gezondheid beseffen, maken er een prioriteit van en houden al hun fitnessgerelateerde feiten bij. In dit artikel onderzoeken we het ontwerp van de database achter een gezondheids- en fitnesstoepassing.

Er zijn veel toepassingen waarmee gebruikers hun gezondheids- en fitnessinformatie kunnen loggen. Een aantal grote spelers zoals Apple, Google en Microsoft hebben hun eigen ontwikkel-API's speciaal voor deze markt gelanceerd. Google heeft bijvoorbeeld 'Fit' en Microsoft heeft 'HealthVault'.

In dit artikel leg ik het datamodel achter een applicatie voor patiëntendossiers uit. Laten we eerst bespreken wat we van zo'n app verwachten.

Projectvereisten voor een app voor gezondheidsinfo

Hieronder staan ​​enkele functies die een app voor gezondheidsinformatie zou moeten ondersteunen:

• Gebruikers kunnen een account aanmaken en gezondheidsinformatie opslaan voor meerdere profielen, d.w.z. een persoon kan gezondheidsinformatie opslaan voor al zijn gezinsleden.
• Gebruikers kunnen hun volledige gezondheidsgeschiedenis vastleggen, inclusief immunisaties, eerdere laboratoriumresultaten, allergieën en medische familiegeschiedenis .
• Gebruikers kunnen verschillende metingen van gezondheid en fitheid opslaan, zoals bloedglucose (bloedsuiker) niveaus, bloeddruk, lichaamssamenstelling en afmetingen inclusief body mass index (BMI), cholesterol, lengte, gewicht, reproductieve gezondheid, enz.
li>
• Informatie kan worden vastgelegd met behulp van verschillende methoden en meeteenheden . Bloedglucose kan bijvoorbeeld worden gemeten in mg/dL of mmol/L.
• Er zijn geen limieten voor de hoeveelheid informatie die gebruikers kunnen opslaan.
• Het systeem houdt ook geaccepteerde gezondheidsnormen vast, zoals bloeddruk- of BMI-nummers, en waarschuwt gebruikers als hun aantal buiten de "veilige" of "normale" waarden valt.
• Gebruikers kunnen ook informatie kiezen (zoals bloedglucose, lengte, gewicht, enz.) om op hun persoonlijke dashboard weer te geven. Op deze manier kunnen ze alles in de gaten houden.

Laten we, in plaats van eenvoudigweg uit te leggen wat elke sectie en tabel in het gegevensmodel doet, er enkele vragen over beantwoorden. De functie van de verschillende tabellen zal gaandeweg duidelijk worden.

Als u wilt, kunt u eerst het volledige gegevensmodel bekijken.

Het gegevensmodel

Vragen beantwoorden over het gezondheidsinformatiegegevensmodel

Hoe kunnen gebruikers gezondheidsinformatie voor al hun gezinsleden afzonderlijk opslaan?

Laten we het eerst hebben over Account- en profielbeheer . Dit kan worden bereikt door twee verschillende tabellen te hebben; één (user_account ) voor het loggen van de gegevens van mensen die zich registreren bij de applicatie, en één (user_profile ) voor het loggen van details van alle verschillende profielen die een geregistreerde gebruiker aanmaakt. Mensen kunnen een aantal profielen aanmaken – b.v. één voor elk van hun gezinsleden.

Laten we eens kijken naar de verschillende tabellen die dit mogelijk maken.

Het user_account tabel bevat basisgegevens over de persoon die zich registreert bij de toepassing. De kolommen zijn:

• id –Een surrogaatsleutelkolom voor deze tabel die elke gebruiker op unieke wijze identificeert.
• login_name – De naam of andere ID die de gebruiker kiest als inlognaam. Er moet een unieke beperking worden opgelegd aan deze kolom om ervoor te zorgen dat elke inlognaam anders is.
• enc_password – Het door de gebruiker geselecteerde accountwachtwoord, in versleutelde vorm.
• adreskolommen – Slaat adres- en contactgegevens op voor gebruikers op het moment van registratie. Deze kolommen bevatten street_address , city , state , country , en zip . Aangezien deze velden optioneel zijn in het registratieproces, heb ik deze kolommen als nullable gehouden.
• contact_number en email – Slaat het contactnummer van de gebruiker (d.w.z. telefoonnummer) en hun e-mailadres op. Deze velden maken ook deel uit van het registratieproces, maar ze zijn niet nullable.
• is_active – Bevat een 'Y' of een 'N' om aan te geven of een account momenteel actief is.
• account_image – Gebruikers mogen hun eigen afbeeldingen uploaden. Aangezien een gebruiker nul of (maximaal) één afbeelding per account kan uploaden, is dit een kolom van het BLOB-type met nulwaarden.

Het user_profile tabel slaat details op van alle profielen die zijn gemaakt door geregistreerde gebruikers. De kolommen in deze tabel zijn:

• id – Een uniek nummer toegewezen aan elk nieuw profiel.
• user_account_id – Geeft aan welke gebruiker het profiel heeft gemaakt.
• user_profile_name – Slaat de naam van de persoon op in het profiel. (We zullen deze persoon de "profielpersoon" noemen en de gebruiker die de profielen aanmaakt de "accounthouder".)
• relationship_id – Geeft de relatie aan tussen de rekeninghouder en de profielpersoon. Deze kolom verwijst naar de relationship tabel, die alle mogelijke soorten relaties bevat (zoals zelf , moeder , vader , zus , broer , zoon , dochter , huisdier , enz.).
• email – Deze kolom bevat het e-mailadres van de profielpersoon. Via deze e-mail worden rapporten of andere informatie met hen gedeeld; informatie zou ook naar de rekeninghouder worden gestuurd. Als Melissa bijvoorbeeld een profiel voor haar dochter Eva aanmaakte, zou Eva's informatie naar Melissa's e-mail en mogelijk naar Eva's e-mail worden gestuurd - zie hieronder.
• is_report_sharing_enabled – Rapportages worden altijd gedeeld met de accounthouder, maar het is optioneel om deze gegevens te delen met de profielpersoon. Deze kolom laat zien of er informatie wordt gedeeld met de profielpersoon.
• is_active – Geeft aan of een profiel momenteel actief is. Dit is een functie voor zacht verwijderen voor het geval profielen per ongeluk worden verwijderd.
• profile_image – Slaat een afbeelding van de profielpersoon op. Dit attribuut is optioneel en dus nullable.

De characteristic_data tabel bevat individuele profieldetails (zoals bloedgroep) die nooit veranderen in de tijd. Alle kolommen in deze tabel spreken voor zich, behalve fitzpatrick_skin_type , die de aard van iemands huid classificeert, beginnend van I (verbrandt altijd, wordt nooit bruin) tot VI (verbrandt nooit, verandert niet in uiterlijk bij bruin worden).

Ik heb twee kolommen toegevoegd voor geslacht; biological_gender staat voor iemands geslacht op het moment van geboorte, en current_gender geeft het huidige geslacht van de profielpersoon aan. Deze tweede kolom is alleen van toepassing op transgenders en daarom heb ik hem nullable gehouden.

Welke essentiële informatie kan in dit systeem worden opgeslagen? Hoe wordt het opgeslagen?

Nu gaan we verder met Gezondheidsgegevensbeheer . Lichaamssamenstelling, bloedglucosewaarden en lichaamsafmetingen worden in aparte tabellen opgeslagen. Mensen kunnen echter meer dan één type informatie tegelijk invoeren, daarom gebruiken we de body_vitals_log tabel om bij te houden welke informatie in een profiel is ingelogd en wanneer deze is ingevoerd.

Alle vitale statistieken worden bijgehouden in de volgende tabellen:

• body_composition - Slaat details op over verschillende percentages lichaamssamenstelling, zoals vet, magere massa, botten of water. Het bevat ook BMI-waarden (body mass index) voor individuen.
• blood_cholesterol – Bevat cholesteroldetails zoals LDL, HDL, triglyceriden en totaal.
• body_dimension – Registreert de afmetingen van verschillende lichaamsdelen, zoals de afmetingen van de taille of borst.
• body_weight – Slaat waarden voor lichaamsgewicht op.
• body_height - Bevat waarden voor de lengte van een persoon.
• blood_pressure – Houdt bloeddruknummers (systolisch en diastolisch).
• blood_glucose - Registreert bloedglucosewaarden.

De meeste kolommen in de bovenstaande tabellen spreken voor zich, op enkele uitzonderingen na. U zult enkele extra kolommen opmerken, zoals measurement_method_id , compare_to_normal_id , measurement_unit_id en measurement_context in bijna elk van deze tabellen. Ik zal deze kolommen later uitleggen.

De body_vitals_log houdt bij welke informatie op een bepaald moment wordt vastgelegd voor een profiel. De kolommen in deze tabel zijn:

• user_profile_id – Toont welk profiel de informatie registreert.
• dt_created – Slaat de datum en tijd op waarop de informatie is ingevoerd.
• data_source_id – Geeft de bron van de gegevens aan, zoals een handleiding, een elektronisch apparaat, enz.
• ID's van verschillende vitale statistieken - Ik heb al deze kolommen nullable gehouden, omdat gebruikers een of meer items tegelijk kunnen loggen. Niet alle gebruikers zullen dezelfde gezondheidsstatistieken willen bijhouden.

Hoe kunnen we het systeem in verschillende regio's laten werken?

Sommige informatie wordt gemeten in verschillende eenheden op verschillende gebieden. Het lichaamsgewicht wordt bijvoorbeeld gemeten in kilogrammen in Azië, maar het wordt gemeten in ponden in Noord-Amerika. Dus om dit werkbaar te maken in onze database, hebben we een manier nodig om meeteenheden te volgen.

• id – Dient als de primaire sleutel van deze tabel, en het is degene waarnaar andere tabellen verwijzen.
• measurement_parameter – Geeft het type vitale informatie aan (zoals gewicht, lengte, bloeddruk, enz.) die een eenheid meet.
• unit_name – Slaat de naam van het apparaat op. Denk aan kilogram en pond voor gewicht, mg/dL en mmol/L voor bloedglucose.

Hoe weten mensen of hun aantal goed is?

Ons systeem helpt niet, tenzij het mensen waarschuwt voor gezondheidsrisico's of kwetsbaarheden. We schakelen deze functie in door de comparison_to_normal_id . toe te voegen kolom in alle tabellen met essentiële informatiegegevens.

Wanneer nieuwe vitale informatie in het systeem wordt ingelogd, worden records vergeleken met hun overeenkomstige benchmarkwaarden en wordt deze kolom dienovereenkomstig ingesteld.

Mogelijke waarden voor deze tabel zijn:

Kunnen gebruikers registreren wanneer metingen zijn uitgevoerd?

Het kan bijvoorbeeld nodig zijn dat gebruikers aangeven wanneer hun bloedglucose is gemeten, d.w.z. voor of na een maaltijd. Of ze wegen zichzelf en noteren de resultaten voor en na het sporten. Om dit te vergemakkelijken, heb ik een kolom toegevoegd, measurement_context , in de tabellen met essentiële informatie die mogelijk contextuele informatie nodig hebben. Enkele mogelijke waarden voor deze kolom worden hieronder getoond:

Wat als een persoon diabetes heeft en zijn bloedglucosewaarden moet controleren?

Het systeem dat ik voorstel zal een dashboard hebben dat vitale statistieken in een grafisch formaat kan weergeven. Gebruikers kunnen kiezen wat ze willen zien op hun profieldashboard en elk profiel heeft zijn eigen dashboard. Accounthouders mogen alle profieldashboards zien die ze hebben gemaakt.

Ik heb een CHAR(1)-kolom toegevoegd voor elke parameter die op een dashboard kan worden weergegeven. Standaard worden alle kolommen gevuld met 'N' (weergave is uitgeschakeld) wanneer een nieuw profiel wordt gemaakt. Gebruikers kunnen hun dashboardconfiguratie later wijzigen via een optie in de gebruikersinterface van de app.

Hoe helpt dit systeem mensen fit te blijven?

Met andere woorden, we hebben het over Fitness Data Storage . Naast gezondheidsinformatie stelt het systeem hun gebruikers ook in staat om informatie over hun fitness- en trainingsroutines te loggen.

De activity_log table is de hoofdtabel in dit vakgebied. Het legt details vast over elk soort activiteitenprofiel dat personen uitvoeren.

Elke activiteit kan worden gemeten door een of meer van de volgende drie parameters:

• Begin- en eindtijd – Activiteiten zoals sporten of gamen, in de rij staan, etc. worden gemeten in begin- en eindtijd. Dit gebeurt via de start_time en end_time kolommen in activity_log .
• Afgelegde afstand – Activiteiten zoals hardlopen of fietsen worden gemeten in termen van afgelegde afstand. Dit wordt opgeslagen in de distance_covered kolom.
• Stappen tellen – Activiteiten zoals wandelen worden gemeten in termen van stappentellingen en de waarden worden opgeslagen in de steps_count kolom.

Je vraagt ​​je vast af waarom de calories_burnt kolom staat in de activity_log tafel. Zoals de naam al doet vermoeden, bevat deze kolom de waarde van de verbrande calorieën door de profielpersoon tijdens het uitvoeren van een bepaalde activiteit. Ik zal in een later gedeelte uitleggen hoe we deze waarden kunnen berekenen.

Ik heb een tabel gemaakt met de naam activity om een ​​lijst bij te houden van alle mogelijke activiteiten. De kolommen in deze tabel zijn:

• id – Wijst een uniek ID-nummer toe aan elke activiteit.
• activity_name – Slaat activiteitsnamen op.
• activity_multiplier – Deze kolom speelt een sleutelrol bij het berekenen van het aantal verbrande calorieën door mensen die activiteiten uitoefenen.

Hoe bereken je de verbrande calorieën voor elke activiteit?

Om te begrijpen hoe we calorieverbranding kunnen berekenen, moeten we eerst iemands BMR of basaal metabolisme begrijpen. Dit vertelt ons hoeveel calorieën een lichaam in rust verbrandt. De BMR van elke persoon hangt af van hun geslacht, leeftijd, gewicht en lengte. Vanuit het perspectief van datamodellering is een BMR een langzaam veranderende dimensie en als zodanig blijft deze met de tijd veranderen. We slaan de laatste individuele BMR-waarden op in de user_bmr tafel.

Er zijn verschillende methoden die worden gebruikt om BMR-waarden te berekenen:

Methode# 1:Harris-Benedict-methode

BMR mannen:66 + (6,23 X gewicht in ponden) + (12,7 X lengte in inches) – (6,8 X leeftijd)

BMR Dames:655 + (4,35 X gewicht in ponden) + (4,7 X lengte in inches) – (4,7 X leeftijd)

Methode #2 2:Katch-McArdle-methode

BMR (mannen + vrouwen):370 + (21,6 * Vetvrije massa in kilogram)

Lean Mass =gewicht in kilogram – (gewicht in kilogram * lichaamsvet %)

We kunnen de BMR van een persoon en de bovengenoemde activiteitenvermenigvuldiger gebruiken om erachter te komen hoeveel calorieën een persoon verbrandt bij het uitvoeren van een bepaalde activiteit. De formule is:

Verbrande calorieën =activiteitsvermenigvuldiger * BMR

Opmerking:Beide bovenstaande BMR-berekeningsmethoden gebruiken dezelfde vermenigvuldigingswaarden voor activiteiten. Zie dit artikel voor meer informatie.

Kunnen we de historische BMR-waarden van profielen behouden?

Ja. We kunnen BMR-waarden archiveren in het user_bmr_archive tafel.

We beginnen met het toevoegen van één kolom, id_version , naar de bestaande user_bmr tafel. We verhogen deze waarde met 1 telkens wanneer de BMR-waarde van een profielpersoon wordt bijgewerkt.

De user_bmr_archive tabel is bijna een replica van de user_bmr tafel. Het enige verschil is dat het een dt_expired . heeft kolom in plaats van de dt_created en dt_modified kolommen. De dt_expired kolom slaat de datum op waarop de versie ongeldig werd, d.w.z. wanneer de BMR-waarde is bijgewerkt in user_bmr .

Wat als gebruikers hun immunisaties, medische familiegeschiedenis en allergieën willen bijhouden?

Dit systeem maakt gebruik van de volgende tabellen om gebruikers de mogelijkheid te bieden aanvullende gezondheidsinformatie op te slaan.

De immunization tabel bevat details over vaccinaties die zijn ontvangen door profielmensen. Na het voorbeeld ziet u een korte beschrijving van de kolommen die deze tabel bevat:

Voorbeeld - John Soo ontving de tweede van drie doses van een hepatitis B-vaccin. Het werd toegediend door Dr. David Moore op 28 november 2016. De vaccinatie werd toegediend via een injectie in de linkerhand. Het wordt vervaardigd door Cipla (een farmaceutisch bedrijf).

• id – De primaire sleutel van deze tabel
• user_profile_id – Verwijst naar de user_profile_ID van John Soo
• vaccination_name – “Hepatitis B”
• dt_received – “28 nov 2016”
• number_in_sequence – “02”
• body_area_id – De ID van de linkerhand, verwezen vanuit het body_area tafel
• provider_name – “Dr. David Moore”
• how_administered – “Geïnjecteerd” (andere mogelijke waarden zijn neusspray, tablet, druppels, siroop )
• manufacturer – “Cipla”

De allergy tabel slaat details op over eventuele allergieën die door profielpersonen worden ervaren. Hieronder vindt u de lijst met kolommen, met de relevante waarden voor elk volgens het voorbeeld:

Voorbeeld - Alison D'Souza hoest wanneer ze yoghurt eet. Deze reactie kreeg ze voor het eerst toen ze 8 jaar oud was. Ze raadpleegt Dr. Bill Smith, die medicijnen voorschrijft en bepaalde voorzorgsmaatregelen adviseert. Deze allergie bestaat nog steeds, maar de intensiteit is nu lager.

• id – De primaire sleutel van de tabel
• user_profile_id – Rverwijst naar de user_profile_id van Alison D'Souza
• allergy_type_id – Verwijst naar de ID voor het allergietype 'Voedsel' in de allergy_type tafel. (De allergy_type tabel definieert verschillende soorten allergie zoals voedsel, medicatie, milieu, dier, plant, enz.)
• allergy_reaction_id – Verwijst naar de ID van de 'hoest'-allergiereactie in de allergy_reaction tafel.
• first_observed – De datum waarop deze reactie voor het eerst werd waargenomen, d.w.z. toen Alison 8 jaar oud was.
• consulting_doctor_name – “Dr. Bill Smith”
• treatment_brief – Een korte beschrijving van de voorgeschreven medicijnen en aanbevolen voorzorgsmaatregelen.
• does_treatment_cure_allergy – “Gedeeltelijk genezen. Verminderde intensiteit van de reactie.”

De family_history tabel slaat details op over de medische familiegeschiedenis van gebruikers. Nogmaals, we hebben de kolommen en het type informatie dat erin zou worden opgeslagen op een rijtje gezet op basis van het volgende voorbeeld.

Voorbeeld – Diana's moeder Lisa heeft de ziekte van Parkinson (een neurologische aandoening). Ze is onder behandeling geweest, maar heeft geen tastbare verbetering gekregen.

• id – de primaire sleutel van de tabel
• user_profile_id – Diana's user_profile_ID van het user_profile tafel
• Relationship_id – De 'moeder'-ID van de relationship tafel
• Relative_name – “Lisa”
• Date_of_birth – Lisa's geboortedatum
• Date_of_death – NULL (Lisa leeft nog en vecht hard tegen de ziekte.)
• Condition_brief – Een korte beschrijving van hoe, wanneer en waar de aandoening begon, consulten, eventuele hulp, enz.
• Current_status – ‘Huidige’ (Andere mogelijke statussen zijn ‘Intermitterend’ en ‘Verleden’.)
• How_it_ended – NULL

Wat zou u aan dit gegevensmodel toevoegen?

Het systeem laat mensen weten hoeveel calorieën ze verbranden tijdens het uitvoeren van verschillende activiteiten, maar het houdt niet bij hoeveel calorieën ze consumeren, of hoe voedzaam hun voedselkeuzes zijn. Het systeem stelt hen ook in staat om hun fitnessgegevens dagelijks vast te leggen, maar het stelt hen niet in staat een doel te stellen, een plan te formuleren en hun voortgang bij te houden, zodat ze gemotiveerd blijven.

Moeten we overwegen deze functies erin in te bouwen? Welke wijzigingen moeten worden aangebracht om deze functies toe te voegen?

Laat ons uw ideeën weten!