Databasemodellering

Ik heb een lied geschreven over flosdraad, maar zijn de tanden van iemand schoner geworden?

Frank Zappa

Als we aan de tandartspraktijk denken, zijn onze eerste associaties de boor, de pijn en de angst. Oké, dat klinkt slecht. Naast het verzorgen van het gebit, heeft een tandarts vele andere verplichtingen die professioneel, wettelijk of beide zijn. Ze vereisen allemaal goed gegevensbeheer.

Om aan deze documentatievereiste te voldoen, gebruiken veel tandheelkundige en medische kantoren papieren dossiers. Maar langzaam maar zeker is er een trend naar de digitale administratie en het beheer van de 21e eeuw.

In het kantoor van tandheelkundige geneeskunde

Naar de tandarts gaan is niet iets waar we normaal met plezier aan terugdenken. Als we geluk hadden, ontweken we de pijn, maar onze portemonnee heeft waarschijnlijk zwaar geleden. Nadat we een tandartspraktijk zijn binnengegaan, is de procedure meestal als volgt:

• Jullie houden allebei een kort praatje. (Vaak onaangenaam omdat je je tandarts hebt beloofd hem volgende week te bezoeken en er zijn 2 jaar verstreken. Dan zeg je dat je het vergeten bent, hij stemt toe, en alles is weer in orde.)
• U zit op de stoel terwijl hij uw eerdere behandelgegevens bekijkt. Hij vraagt ​​of er iets is gebeurd sinds het laatste bezoek en of er een update is in uw medisch dossier.
• Hij kijkt in je mond om te bepalen wat er mis is gegaan en vertelt je wat het zal oplossen.
• U kunt akkoord gaan met zijn behandelplan of een andere optie kiezen.
• Een paar maanden later staat er weer een Hollywood-glimlach op je gezicht. Het zou eerder zijn geweest, maar je kon pas glimlachen als je eindelijk de rekening voor je tandheelkundige werk volledig had betaald.

Op dit moment denkt zelfs de meest toegewijde databaseprofessional waarschijnlijk niet:'Wauw, ik wou dat er een datamodel was voor deze ervaring!' . Maar er is, en het is het onderzoeken waard. Daarom hebben we het hieronder afgedrukt.

Introductie van ons databasemodel voor tandartspraktijken

Het idee achter dit model is om elke procedure te dekken vanaf het moment dat we voor het eerst de tandartspraktijk binnenstappen totdat het probleem is opgelost. Onderdeel van dit model (de tabellen met het label user_account , status , user_has_status , role , user_has_role ) werd gepresenteerd en beschreven in eerdere artikelen. Misschien lijken rollen en statussen hier overbodig, maar onthoud dat de praktijk ook een verpleegkundige kan bevatten om de anamnese af te handelen, een receptioniste, een tandheelkundestudent, verschillende opgeleide tandartsassistenten, of zelfs een bezoekende specialist of een hygiënist. In dit artikel wordt echter geen rekening gehouden met betalingsgegevens.

Tabellen in de tandheelkundige database

De patient table is een van de twee belangrijkste tabellen in de database. Het slaat patiëntengegevens op en is gekoppeld aan patiëntendocumenten en bezoeken. Met uitzondering van mail , alle attributen in de tabel zijn verplicht:

• name – de naam van de patiënt
• surname – de achternaam van de patiënt
• identification_number - dit veld wordt gebruikt om de unieke id van een klant op te slaan die in de echte wereld wordt gebruikt
• address – het adres van de patiënt
• phone – het telefoonnummer van de patiënt
• mail – het e-mailadres van de patiënt

De op één na belangrijkste tabel in de database is visit . In combinatie met de tabel patient , slaat het informatie op over de gebeurtenis die alle volgende acties heeft geactiveerd. De attributen in de tabel zijn:

• visit_date - bevat de werkelijke datum en tijd waarop het bezoek heeft plaatsgevonden
• patient_id – is het ID van de patiënt gerelateerd aan zijn bezoek
• dentist_id – is een verwijzing naar user_has_role tafel, ervan uitgaande dat de rol tandarts is

De volgende is de anamnesis tafel. In de geneeskunde is anamnese een procedure waarbij we de geschiedenis van medische gegevens verzamelen en opslaan, zoals de huidige toestand van de patiënt. De anamnesis tabel slaat deze gegevens op. Aangezien dit snel na onze aankomst op kantoor gebeurt, hebben we maximaal één anamnese per gebeurtenis. De attributen in de tabel zijn:

• anamnesis_id – is de primaire sleutel van de anamnesis tabel, die ook verwijst naar de visit tafel
• user_anamnesis_id – dit heeft betrekking op de user_has_role tafel. Merk op dat de tandarts niet degene hoeft te zijn die de anamnese heeft gemaakt.
• notes – bevat tekstnotities over specifieke anamnese. Het is geen verplicht veld.

De anamnesis_type tabel is een eenvoudig woordenboek dat wordt gebruikt om alle mogelijke waarden op te slaan waarnaar wordt verwezen in anamnesis_catalog . Het enige kenmerk is type_name , en het kan waarden bevatten zoals "ziekte", "allergie", "gebruikte medicijnen". Natuurlijk is dat enige kenmerk verplicht.

De anamnesis_catalog tabel is een woordenboek dat meer specifieke informatie geeft dan de waarden die zijn opgeslagen in het anamnesis_type tafel. We gebruiken het om gegevens over specifieke ziekten, allergieën en medicijnen bij te houden. De attributen zijn allemaal verplicht en omvatten:

• catalog_name – is de naam van een specifiek anamnesis_type subcategorie
• anamnesis_type_id – is een verwijzing naar het anamnesis_type tafel

De visit_anamnesis tabel wordt gebruikt om bezoekgegevens te koppelen aan waarden uit de anamnesecatalogus. Elk attribuut in de tabel is vereist:

• anamnesis_anamnesis_id – is een verwijzing naar de anamnesis tafel
• anamnesis_catalog_id – is een verwijzing naar de anamnesis_catalog tafel

Merk op dat de visit_anamnesis tabel is een veel-op-veel-relatie die de tabellen met het label anamnesis en anamnesis_catalog . Het heeft geen zin om dit paar op te slaan (anamnesis_anamnesis_id &anamnesis_catalog_id ) tweemaal. We gebruiken dat paar als de primaire sleutel.

Het document table is een eenvoudige catalogus met locaties waar we patiëntendocumenten hebben opgeslagen. Voorbeelden van dergelijke documenten zijn scans van patiëntenkaarten, röntgenfoto's en facturen. Uiteraard slaan we deze documenten niet direct op in de database. Dit is een grove vereenvoudiging van het documentbeheersysteem. De attributen in het document tabel zijn (allemaal verplicht):

• description – is een korte documentbeschrijving
• location – bevat de exacte documentlocatie
• patient_id – is een verwijzing naar de patient tafel

De tooth table is een eenvoudig woordenboek dat later wordt gebruikt wanneer de tandarts aangeeft welke tand het probleem was. Alle attributen in deze tabel zijn vereist. Dit zijn:

• is_baby_tooth – is een Booleaanse waarde die eenvoudig aangeeft of een tand een melktand is of niet. Natuurlijk hebben we dubbele waarden voor tanden die beide kunnen zijn. Dit is belangrijk omdat een procedure per tandtype kan verschillen.
• tooth – is een beschrijving die wordt gebruikt voor de tand waarmee werk wordt gedaan – over het algemeen wordt die waarde op het scherm weergegeven.

De problem_catalog tabel is een ander eenvoudig woordenboek. Het bevat een lijst van alle mogelijke problemen die normaal gesproken op tanden of in de mond voorkomen. Voorbeelden van mogelijke waarden voor deze catalogus zijn:“tandbederf”, “tanderosie”, “gingivitis”, “zweertjes in de mond” of “onaantrekkelijke glimlach”. Alleen de problem_name kenmerk is verplicht.

De problem_detected tabel verbindt bezoek-, tand- en probleemcatalogusgegevens met de treatment tafel. Het bevat verwijzingen naar de tooth , problem_catalog en visit tafels. Alle attributen zijn verplicht behalve tooth_id . De reden voor deze uitzondering is dat sommige problemen niet naar slechts één tand verwijzen (bijv. gingivitis verwijst naar het tandvlees). Deze drie attributen vormen samen een alternatieve sleutel (UNIEK). De andere twee kenmerken zijn:

• suggested_treatment_id is een verwijzing naar de treatment tafel (de behandeling voorgesteld door de tandarts). Het kan een NULL-waarde zijn als alles in orde is en we geen behandeling nodig hebben.
• selected_treatment_id is een andere verwijzing naar de treatment tafel. Het bevat gegevens over de behandeling die tandarts en patiënt zijn overeengekomen. Dit kan NULL zijn, misschien omdat de patiënt tijd nodig heeft om na te denken over de voorgestelde behandeling en andere mogelijkheden.

Merk op dat de attributen suggested_treatment_id en selected_treatment_id beide verwijzen naar de treatment tafel. We kunnen dit doen omdat we maximaal twee waarden hoeven op te slaan. Als we niet van tevoren weten hoeveel waarden we willen opslaan, moeten we hier natuurlijk een veel-op-veel-relatie gebruiken.

De step tabel is een eenvoudig woordenboek met alle mogelijke stappen in alle behandelingen. De attributen (allemaal verplicht) in de tabel zijn:

• step_name – is een korte stapnaam die op het scherm wordt gebruikt
• description – is een beschrijving van de acties die tijdens deze stap zijn ondernomen

De treatment tabel is in feite een woordenboek van alle behandelingen die de tandartspraktijk biedt. Aangezien de meeste behandelingen meestal uit meerdere stappen bestaan, moeten we weten welke stap definitief is. De attributen in de tabel zijn allemaal vereist:

• treatment_name – is de naam van de behandeling binnen het systeem
• description – is een korte beschrijving van de behandeling
• final_step_id – is een verwijzing naar de step tafel. We kunnen deze informatie gebruiken om te detecteren of de behandeling voorbij is en automatische actie te starten, of we kunnen die informatie eenvoudig aan de gebruiker laten zien en hem de volgende actie laten kiezen.

De treatment_steps tabel is een veel-op-veel relatie die stappen verbindt met behandelingen. De verplichte attributen in de tabel zijn:

• treatment_id – is een verwijzing naar de treatment tafel
• step_id – is een verwijzing naar de step tafel
• step_order – is een getal dat de volgorde van de stappen in de behandeling bepaalt

In deze tabel zijn twee alternatieve sleutels (UNIEK) gedefinieerd:

• paar (treatment_id &step_id ) – deze stap kan slechts één keer aan de behandeling worden toegewezen
• paar (treatment_id &step_order ) – de behandeling mag geen twee stappen hebben met hetzelfde bestelnummer

De visit_steps tabel is een lijst van alle stappen die daadwerkelijk zijn uitgevoerd na dat bezoek. Er zijn twee redenen waarom we ze in aparte tabellen willen opslaan:

1. We hebben misschien een behandeling gekozen, maar we hebben niet alle stappen nodig die ervoor zijn gedefinieerd, en
2. Op deze manier slaan we de werkelijke tijd op waarop de stap werd uitgevoerd.

De attributen in de tabel (allemaal verplicht behalve problem_detected_id en notes ) zijn als volgt:

• visit_id – is een verwijzing naar de visit tafel
• treatment_steps_id – is een verwijzing naar de treatment_steps tafel
• problem_detected_id – is een verwijzing naar de problem_detected tafel. Deze relatie geeft ons informatie over welk probleem de actie heeft veroorzaakt. Het kan NULL zijn wanneer de tandarts besluit een actie te ondernemen die geen verband houdt met een gedetecteerd probleem.
• step_time – is de datum en/of tijd waarop de stap daadwerkelijk is uitgevoerd
• notes – zijn notities voor die stap, indien nodig

De visit_status table is een eenvoudig woordenboek dat wordt gebruikt om alle mogelijke statussen van een bezoek op te slaan. We kunnen statussen gebruiken zoals "eerste bezoek aan kantoor ooit", "eerste bezoek", "behandeling in uitvoering", "behandeling succesvol afgerond". Het bevat slechts één attribuut, status_name , wat verplicht is.

De visit_status_history tabel wordt gebruikt om gegevens op te slaan over de statussen die het bezoek heeft doorgemaakt. De gedachte is dat we de status handmatig toevoegen nadat bepaalde acties zijn voltooid (bijvoorbeeld na anamnese, na het voltooien van een paar stappen van een behandeling). De attributen, die allemaal vereist zijn, volgen:

• status_time – is de datum/tijd waarop de status werd ingevoegd
• visit_status_id – is een verwijzing naar de visit_status tafel
• visit_id – is een verwijzing naar de visit tafel

Mogelijke verbeteringen aan het tandheelkundige databasemodel

Ons model is goed van start gegaan, maar het kan voor verbetering vatbaar zijn. Het dekt bijvoorbeeld niet de volgende items:

• betaalmethoden en facturen
• vergaderingen plannen (hoewel dit kan worden gedaan door gegevens in te voeren in de visit_steps tabel voor toekomstige evenementen)
• documentafhandeling

Toch laat het je anders denken over je tandartspraktijk en de procedures, nietwaar?