Database modellering

Jeg skrev en sang om tandtråd, men blev nogens tænder renere?

Frank Zappa

Når vi tænker på tandlægekontoret, er vores første associationer øvelsen, smerten og frygten. OK, det lyder dårligt. Udover at tage sig af tænder, har en tandlæge mange andre forpligtelser, som er professionelle, juridiske eller begge dele. Alle af dem kræver korrekt datahåndtering.

For at opfylde dette dokumentationskrav bruger mange tandlæge- og lægekontorer papirjournaler. Langsomt men sikkert er der dog en tendens til det 21. århundredes digitale optegnelser og forvaltning.

Inde på kontoret for tandmedicin

At gå til tandlæge er ikke noget, vi normalt husker med glæde. Hvis vi var heldige, undgik vi smerten, men vores pengepung led sandsynligvis hårdt. Efter vi træder ind på et tandlægekontor, er proceduren normalt som følger:

• I deltager begge i en kort omgang chat-chat. (Ofte ubehageligt, fordi du har lovet din tandlæge, at du vil besøge ham i næste uge, og der er gået 2 år. Så siger du, du har glemt det, han er enig, og alt er ok igen.)
• Du sidder på stolen, mens han ser på dine tidligere behandlingsjournaler. Han spørger, om der er sket noget siden sidste besøg, og om der er nogen opdatering af din journal.
• Han tager et kig ind i din mund for at finde ud af, hvad der gik galt, og fortæller dig, hvad der vil løse det.
• Du kan acceptere hans behandlingsplan eller vælge en anden mulighed.
• Et par måneder senere er der igen et Hollywood-smil på dit ansigt. Det ville have været før, men du kunne ikke smile, før du endelig havde betalt hele regningen for dit tandarbejde.

På dette tidspunkt tænker selv den mest dedikerede databasemedarbejder sandsynligvis ikke, 'Wow, jeg ville ønske, der var en datamodel for denne oplevelse!' . Men der er, og det er værd at undersøge. Så vi har udskrevet det nedenfor.

Vi præsenterer vores tandlægedatabasemodel

Ideen bag denne model er at dække enhver procedure fra det øjeblik, vi første gang træder ind på tandlægens kontor, indtil problemet er løst. En del af denne model (tabellerne mærket user_account , status , user_has_status , role , user_has_role ) blev præsenteret og beskrevet i tidligere artikler. Måske ser roller og statusser unødvendige ud her, men husk at praksis også kunne indeholde en sygeplejerske til at varetage anamnesen (journaloptagelsen), en receptionist, en tandlægestuderende, flere uddannede tandlægeassistenter eller endda en visiterende speciallæge eller en hygiejne. Betalingsoplysninger vil dog ikke blive taget i betragtning i denne artikel.

Tabeller i tandlægedatabasen

patient tabel er en af ​​de to vigtigste tabeller i databasen. Det gemmer patienternes data og er forbundet med patienternes dokumenter og besøg. Med undtagelse af mail , alle attributterne i tabellen er obligatoriske:

• name – patientens navn
• surname – patientens efternavn
• identification_number – dette felt bruges til at gemme en klients unikke id, der bruges i den virkelige verden
• address – patientens adresse
• phone – patientens telefonnummer
• mail – patientens mailadresse

Den næstvigtigste tabel i databasen er visit . Når det kombineres med tabellen patient , gemmer den information om hændelsen, der udløste alle de efterfølgende handlinger. Attributterne i tabellen er:

• visit_date – indeholder den faktiske dato og tidspunkt, hvor besøget har fundet sted
• patient_id – er patientens id relateret til hans besøg
• dentist_id – er en reference til user_has_role tabel, forudsat at rollen er tandlæge

Det næste er anamnesis bord. I medicin er anamnese en procedure, hvor vi indsamler og opbevarer medicinsk datahistorie, såsom patientens aktuelle tilstand. anamnesis tabel gemmer disse data. Da dette sker kort efter vores ankomst til kontoret, har vi højst én anamnese pr. begivenhed. Attributterne i tabellen er:

• anamnesis_id – er den primære nøgle til anamnesis tabel, som også refererer til visit tabel
• user_anamnesis_id – dette vedrører user_has_role bord. Bemærk, at tandlægen ikke behøver at være den, der lavede anamnese.
• notes – indeholder tekstnoter om specifik anamnese. Det er ikke et obligatorisk felt.

anamnesis_type tabel er en simpel ordbog, der bruges til at gemme alle mulige værdier, der henvises til i anamnesis_catalog . Den eneste attribut er type_name , og det kan indeholde værdier som "sygdom", "allergi", "brugt medicin". Selvfølgelig er den eneste egenskab obligatorisk.

anamnesis_catalog tabel er en ordbog, der giver mere specifik information end værdier gemt i anamnesis_type bord. Vi bruger det til at opbevare data om specifik sygdom, allergier og medicin. Attributterne er alle obligatoriske, og de inkluderer:

• catalog_name – er navnet på specifik anamnesis_type underkategori
• anamnesis_type_id – er en reference til anamnesis_type tabel

visit_anamnesis tabel bruges til at forbinde besøgsdata med værdier fra anamnesekataloget. Hver attribut i tabellen er påkrævet:

• anamnesis_anamnesis_id – er en henvisning til anamnesis tabel
• anamnesis_catalog_id – er en reference til anamnesis_catalog tabel

Bemærk, at visit_anamnesis tabel er en mange-til-mange-relation, der forbinder tabellerne mærket anamnesis og anamnesis_catalog . Det nytter ikke at gemme dette par (anamnesis_anamnesis_id &anamnesis_catalog_id ) to gange. Vi bruger det par som den primære nøgle.

document tabel er et simpelt katalog, der indeholder steder, hvor vi har gemt patienters dokumenter. Eksempler på sådanne dokumenter kan være scanninger af patienters diagrammer, røntgenbilleder og fakturaer. Vi gemmer naturligvis ikke disse dokumenter direkte i databasen. Dette er en uforskammet forenkling af dokumenthåndteringssystemet. Attributterne i document tabellen er (alle er obligatoriske):

• description – er en kort dokumentbeskrivelse
• location – indeholder nøjagtig dokumentplacering
• patient_id – er en reference til patient tabel

tooth tabel er en simpel ordbog, der bruges senere, når tandlægen specificerer, hvilken tand der var problemet. Alle attributter i denne tabel er påkrævet. De er:

• is_baby_tooth – er en boolsk værdi, der blot markerer, om en tand er en mælketand eller ej. Selvfølgelig har vi dublerede værdier for tænder, der kan være begge dele. Dette er vigtigt, fordi en procedure kan variere alt efter tandtypen.
• tooth – er en beskrivelse, der bruges til, at tanden får arbejdet udført – generelt vil denne værdi blive vist på skærmen.

problem_catalog tabel er en anden simpel ordbog. Den indeholder en liste over alle mulige problemer, der normalt findes på tænder eller i munden. Eksempler på mulige værdier for dette katalog er:"huller i tænderne", "tanderosion", "gingivitis", "mundsår" eller "uattraktivt smil". Kun problem_name attribut er obligatorisk.

problem_detected tabel forbinder besøgs-, tand- og problemkatalogdata med treatment bord. Den indeholder referencer til tooth , problem_catalog og visit tabeller. Alle attributter er obligatoriske undtagen tooth_id . Årsagen til denne undtagelse er, at nogle problemer ikke kun refererer til én tand (f.eks. tandkødsbetændelse refererer til tandkødet). Disse tre attributter danner tilsammen en alternativ nøgle (UNIQUE). De to andre attributter er:

• suggested_treatment_id er en reference til treatment tabel (den behandling foreslået af tandlægen). Det kan være en NULL-værdi, når alt er OK, og vi ikke har brug for nogen behandling.
• selected_treatment_id er en anden reference til treatment bord. Den indeholder data om den behandling, tandlæge og patient er blevet enige om at bruge. Dette kan være NULL, måske fordi patienten har brug for tid til at tænke over foreslået behandling og andre muligheder.

Bemærk, at attributterne suggested_treatment_id og selected_treatment_id er begge refereret til treatment bord. Vi kan gøre dette, fordi vi kun behøver at lagre højst to værdier. Selvfølgelig, hvis vi ikke på forhånd ved, hvor mange værdier vi vil gemme, skal vi bruge en mange-til-mange-relation her.

step tabel er en simpel ordbog, der indeholder alle mulige trin i alle behandlinger. Attributterne (alle er obligatoriske) i tabellen er:

• step_name – er et kort trinnavn, der bruges på skærmen
• description – er en beskrivelse af de handlinger, der er foretaget under dette trin

treatment tabel er faktisk en ordbog over alle behandlinger, som tandlægekontoret yder. Da de fleste behandlinger normalt består af flere trin, skal vi vide, hvilket trin der er endeligt. Attributterne i tabellen er alle påkrævet:

• treatment_name – er navnet på behandlingen i systemet
• description – er en kort behandlingsbeskrivelse
• final_step_id – er en reference til step bord. Vi kan bruge disse oplysninger til at opdage, om behandlingen er overstået, og starte automatisk handling, eller vi kan blot vise denne information til brugeren og lade ham vælge den næste handling.

treatment_steps bord er en mange-til-mange relation, der forbinder trin med behandlinger. De obligatoriske attributter i tabellen er:

• treatment_id – er en reference til treatment tabel
• step_id – er en reference til step tabel
• step_order – er et tal, der definerer rækkefølgen af ​​trin i behandlingen

I denne tabel er to alternative nøgler (UNIQUE) defineret:

• par (treatment_id &step_id ) – dette trin kan kun tildeles behandlingen én gang
• par (treatment_id &step_order ) – behandlingen kan ikke have to trin med samme ordrenummer

visit_steps tabel er en liste over alle trin, der faktisk blev udført efter det besøg. Der er to grunde til, at vi ønsker at gemme dem i separate tabeller:

1. Vi har muligvis valgt en behandling, men vi behøver ikke alle de trin, der er defineret for den, og
2. På denne måde gemmer vi det faktiske tidspunkt, hvor trinnet blev udført.

Attributterne i tabellen (alle er obligatoriske undtagen problem_detected_id). og notes ) er som følger:

• visit_id – er en reference til visit tabel
• treatment_steps_id – er en reference til treatment_steps tabel
• problem_detected_id – er en reference til problem_detected bord. Denne relation giver os information om, hvilket problem der startede den handling. Den kan være NULL, når tandlægen beslutter sig for at foretage en handling, der ikke er relateret til noget påvist problem.
• step_time – er datoen og/eller tidspunktet, hvor trinnet rent faktisk blev udført
• notes – er noter til det trin, hvis det er nødvendigt

visit_status table er en simpel ordbog, der bruges til at gemme alle mulige statusser et besøg kunne have. Vi kunne bruge statusser som "første besøg på kontoret nogensinde", "første besøg", "behandling i gang", "behandling afsluttet med succes". Den indeholder kun én attribut, status_name , hvilket er obligatorisk.

visit_status_history tabel bruges til at gemme data om de statusser, som besøget gik igennem. Tanken er, at vi tilføjer status manuelt, efter at visse handlinger er gennemført (f.eks. efter anamnese, efter at have afsluttet et par trin af en eller anden behandling). Attributterne, som alle er nødvendige, følger:

• status_time – er datoen/klokkeslættet, hvor status blev indsat
• visit_status_id – er en reference til visit_status tabel
• visit_id – er en reference til visit tabel

Mulige forbedringer af dentaldatabasemodellen

Vores model er kommet godt fra start, men den kunne forbedres. For eksempel dækker det ikke følgende elementer:

• betalingsmetoder og fakturaer
• planlægning af møder (selvom dette kunne gøres ved at indsætte data i visit_steps tabel til fremtidige begivenheder)
• dokumenthåndtering

Alligevel får det dig til at tænke anderledes om dit tandlægekontor og dets procedurer, ikke?