Databasmodellering

Jag skrev en låt om tandtråd men blev någons tänder renare?

Frank Zappa

När vi tänker på tandläkarmottagningen är våra första associationer borren, smärtan och rädslan. Okej, det låter illa. Förutom att ta hand om tänderna har en tandläkare många andra skyldigheter som är professionella, lagliga eller båda. Alla kräver korrekt datahantering.

För att uppfylla detta dokumentationskrav använder många tandläkar- och läkarmottagningar pappersjournaler. Men sakta men säkert finns det en trend mot 2000-talets digitala register och förvaltning.

Inte på tandläkarkontoret

Att gå till tandläkaren är inget vi brukar minnas med glädje. Om vi ​​hade tur undvek vi smärtan men vår plånbok led förmodligen hårt. Efter att vi kliver in på en tandläkarmottagning är proceduren vanligtvis som följer:

• Ni deltar båda i en kort chatt-chatt. (Ofta obehagligt för att du lovade din tandläkare att du ska besöka honom nästa vecka och det har gått två år. Då säger du att du glömt, han håller med och allt är ok igen.)
• Du sitter på stolen medan han tittar på dina tidigare behandlingsjournaler. Han frågar om något hänt sedan senaste besöket och om det finns någon uppdatering av din journal.
• Han tar en titt inuti din mun för att avgöra vad som gick fel och berättar vad som kommer att fixa det.
• Du kan komma överens med hans behandlingsplan eller välja något annat alternativ.
• Några månader senare kommer ett Hollywood-leende på läpparna igen. Det skulle ha varit tidigare, men du kunde inte le förrän du äntligen hade betalat hela räkningen för ditt tandvårdsarbete.

Vid det här laget tänker förmodligen inte ens den mest hängivna databasproffsen, "Wow, jag önskar att det fanns en datamodell för den här upplevelsen!" . Men det finns, och det är värt att undersöka. Så vi har skrivit ut det nedan.

Vi presenterar vår databasmodell för tandläkare

Tanken bakom denna modell är att täcka varje procedur från det ögonblick vi först kliver in på tandläkarmottagningen tills problemet är löst. En del av denna modell (tabellerna märkta user_account , status , user_has_status , role , user_has_role ) har presenterats och beskrivits i tidigare artiklar. Kanske ser roller och statuser onödiga ut här, men kom ihåg att praktiken även skulle kunna innehålla en sjuksköterska som sköter anamnesen (journaltagning), en receptionist, en tandläkarstudent, flera utbildade tandläkarassistenter eller till och med en besökande specialist eller en hygienist. Betalningsuppgifter kommer dock inte att beaktas i den här artikeln.

Tabell i tandläkardatabasen

patient table är en av två viktigaste tabeller i databasen. Den lagrar patientdata och är kopplad till patienters dokument och besök. Med undantag för mail , alla attribut i tabellen är obligatoriska:

• name – patientens namn
• surname – patientens efternamn
• identification_number – det här fältet används för att lagra en klients unika ID som används i den verkliga världen
• address – patientens adress
• phone – patientens telefonnummer
• mail – patientens e-postadress

Den näst viktigaste tabellen i databasen är visit . I kombination med tabellen patient lagrar den information om händelsen som utlöste alla efterföljande åtgärder. Attributen i tabellen är:

• visit_date – innehåller det faktiska datumet och tiden då besöket inträffade
• patient_id – är patientens id relaterat till hans besök
• dentist_id – är en referens till user_has_role tabell, förutsatt att rollen är tandläkare

Nästa upp är anamnesis tabell. Inom medicin är anamnes en procedur där vi samlar in och lagrar medicinsk datahistorik, såsom patientens nuvarande tillstånd. anamnesis tabellen lagrar dessa data. Eftersom detta händer strax efter vår ankomst till kontoret kommer vi att ha högst en anamnes per händelse. Attributen i tabellen är:

• anamnesis_id – är den primära nyckeln i anamnesis tabell, som också refererar till visit tabell
• user_anamnesis_id – detta gäller user_has_role tabell. Lägg märke till att tandläkaren inte behöver vara den som gjorde anamnesen.
• notes – innehåller textanteckningar om specifik anamnes. Det är inte ett obligatoriskt fält.

anamnesis_type table är en enkel ordbok som används för att lagra alla möjliga värden som hänvisas till i anamnesis_catalog . Det enda attributet är type_name , och det kan innehålla värden som "sjukdom", "allergi", "använd medicin". Naturligtvis är det enda attributet obligatoriskt.

anamnesis_catalog Tabell är en ordbok som ger mer specifik information än värden som lagras i anamnesis_type tabell. Vi kommer att använda den för att lagra data om specifika sjukdomar, allergier och mediciner. Attributen är alla obligatoriska och de inkluderar:

• catalog_name – är namnet på specifik anamnesis_type underkategori
• anamnesis_type_id – är en referens till anamnesis_type tabell

visit_anamnesis Tabell används för att koppla samman besöksdata med värden från anamneskatalogen. Varje attribut i tabellen krävs:

• anamnesis_anamnesis_id – är en referens till anamnesis tabell
• anamnesis_catalog_id – är en referens till anamnesis_catalog tabell

Observera att visit_anamnesis tabell är en många-till-många-relation som förbinder tabellerna märkta anamnesis och anamnesis_catalog . Det är ingen idé att lagra detta par (anamnesis_anamnesis_id &anamnesis_catalog_id ) två gånger. Vi använder det paret som primärnyckel.

document tabellen är en enkel katalog som innehåller platser där vi har sparat patientdokument. Exempel på sådana dokument kan vara skanningar av patientdiagram, röntgenbilder och fakturor. Naturligtvis kommer vi inte att spara dessa dokument direkt i databasen. Detta är en oförskämd förenkling av dokumenthanteringssystemet. Attributen i document Tabeller är (alla är obligatoriska):

• description – är en kort dokumentbeskrivning
• location – innehåller exakt dokumentplacering
• patient_id – är en referens till patient tabell

tooth table är en enkel ordbok som används senare när tandläkaren anger vilken tand som var problemet. Alla attribut i denna tabell är obligatoriska. De är:

• is_baby_tooth – är ett booleskt värde som helt enkelt markerar om en tand är en mjölktand eller inte. Naturligtvis kommer vi att ha dubbla värden för tänder som kan vara båda. Detta är viktigt eftersom en procedur kan skilja sig åt beroende på tandtyp.
• tooth – är en beskrivning som används för att tanden får arbetet gjort – i allmänhet kommer det värdet att visas på skärmen.

problem_catalog tabellen är en annan enkel ordbok. Den innehåller en lista över alla möjliga problem som normalt finns på tänder eller i munnen. Exempel på möjliga värden för denna katalog är:"tandförfall", "tanderosion", "gingivit", "munsår" eller "otraktivt leende". Endast problem_name attribut är obligatoriskt.

problem_detected tabellen kopplar samman besöks-, tand- och problemkatalogdata med treatment tabell. Den innehåller referenser till tooth , problem_catalog och visit tabeller. Alla attribut är obligatoriska förutom tooth_id . Anledningen till detta undantag är att vissa problem inte bara avser en tand (t.ex. gingivit avser tandköttet). Dessa tre attribut bildar tillsammans en alternativ nyckel (UNIQUE). De andra två attributen är:

• suggested_treatment_id är en referens till treatment tabell (den behandling som tandläkaren föreslagit). Det kan vara ett NULL-värde när allt är OK och vi inte behöver någon behandling.
• selected_treatment_id är en annan referens till treatment tabell. Den innehåller data om den behandling tandläkaren och patienten kommit överens om att använda. Detta kan vara NULL, kanske för att patienten behöver tid att tänka på föreslagen behandling och andra möjligheter.

Observera att attributen suggested_treatment_id och selected_treatment_id är båda refererade till treatment tabell. Vi kan göra detta eftersom vi bara behöver lagra högst två värden. Naturligtvis, om vi inte i förväg vet hur många värden vi vill lagra bör vi använda en många-till-många-relation här.

step table är en enkel ordbok som innehåller alla möjliga steg i alla behandlingar. Attributen (alla är obligatoriska) i tabellen är:

• step_name – är ett kort stegnamn som används på skärmen
• description – är en beskrivning av de åtgärder som vidtagits under detta steg

treatment table är i själva verket en ordbok över alla behandlingar som tandläkarmottagningen tillhandahåller. Eftersom de flesta behandlingar vanligtvis består av flera steg måste vi veta vilket steg som är slutgiltigt. Attributen i tabellen är alla obligatoriska:

• treatment_name – är namnet på behandlingen inom systemet
• description – är en kort behandlingsbeskrivning
• final_step_id – är en referens till step tabell. Vi kan använda denna information för att upptäcka om behandlingen är över och initiera automatisk åtgärd, eller så kan vi helt enkelt visa den informationen för användaren och låta honom välja nästa åtgärd.

treatment_steps bord är en många-till-många relation som kopplar samman steg med behandlingar. De obligatoriska attributen i tabellen är:

• treatment_id – är en referens till treatment tabell
• step_id – är en referens till step tabell
• step_order – är en siffra som definierar ordningen på stegen i behandlingen

I denna tabell är två alternativa nycklar (UNIQUE) definierade:

• par (treatment_id &step_id ) – detta steg kan endast tilldelas behandlingen en gång
• par (treatment_id &step_order ) – behandlingen kan inte ha två steg med samma ordernummer

visit_steps tabellen är en lista över alla steg som faktiskt utfördes efter det besöket. Det finns två anledningar till att vi vill lagra dem i separata tabeller:

1. Vi kan ha valt en behandling, men vi behöver inte alla steg som definierats för den, och
2. På detta sätt lagrar vi den faktiska tiden när steget utfördes.

Attributen i tabellen (alla är obligatoriska utom problem_detected_id). och notes ) är följande:

• visit_id – är en referens till visit tabell
• treatment_steps_id – är en referens till treatment_steps tabell
• problem_detected_id – är en referens till problem_detected tabell. Denna relation ger oss information om vilket problem som initierade den åtgärden. Den kan vara NULL när tandläkaren bestämmer sig för att vidta någon åtgärd som inte är relaterad till något upptäckt problem.
• step_time – är datumet och/eller tiden då steget faktiskt utfördes
• notes – är anteckningar för det steget, om det behövs

visit_status table är en enkel ordbok som används för att lagra alla möjliga statusar ett besök kan ha. Vi kan använda statusar som "första besök på kontoret någonsin", "första besök", "behandling pågår", "behandling avslutad framgångsrikt". Den innehåller bara ett attribut, status_name , vilket är obligatoriskt.

visit_status_history tabell används för att lagra data om de statusar som besöket gick igenom. Tanken är att vi lägger till status manuellt efter att vissa åtgärder har slutförts (t.ex. efter anamnes, efter att ha avslutat några steg av någon behandling). Attributen, som alla är obligatoriska, följer:

• status_time – är datum/tid då status infogades
• visit_status_id – är en referens till visit_status tabell
• visit_id – är en referens till visit tabell

Möjliga förbättringar av dentala databasmodellen

Vår modell har fått en bra start, men den kan förbättras. Till exempel täcker den inte följande artiklar:

• betalningsmetoder och fakturor
• schemalägga möten (även om detta kan göras genom att infoga data i visit_steps tabell för framtida evenemang)
• dokumenthantering

Ändå får det dig att tänka annorlunda om din tandläkare och dess procedurer, eller hur?