Datenbankmodellierung

Ich habe einen Song über Zahnseide geschrieben, aber wurden die Zähne von irgendjemandem sauberer?

Frank Zappa

Wenn wir an die Zahnarztpraxis denken, sind unsere ersten Assoziationen der Bohrer, der Schmerz und die Angst. Okay, das hört sich schlecht an. Neben der Pflege der Zähne hat ein Zahnarzt viele andere berufliche, gesetzliche oder beides Pflichten. Alle erfordern eine ordnungsgemäße Datenverwaltung.

Um diese Dokumentationspflicht zu erfüllen, verwenden viele Zahnarzt- und Arztpraxen Papierakten. Langsam aber sicher gibt es einen Trend zur digitalen Akte und Verwaltung des 21. Jahrhunderts.

In der Zahnarztpraxis

Der Besuch beim Zahnarzt ist nichts, woran wir uns normalerweise mit Freude erinnern. Wenn wir Glück hatten, wichen wir den Schmerzen aus, aber unser Portemonnaie hat wahrscheinlich stark gelitten. Nachdem wir eine Zahnarztpraxis betreten haben, ist der Ablauf normalerweise wie folgt:

• Sie unterhalten sich beide kurz. (Oft unangenehm, weil Sie Ihrem Zahnarzt versprochen haben, ihn nächste Woche zu besuchen und 2 Jahre vergangen sind. Dann sagen Sie, Sie hätten es vergessen, er stimmt zu und alles ist wieder in Ordnung.)
• Sie sitzen auf dem Stuhl, während er sich Ihre bisherigen Behandlungsunterlagen ansieht. Er fragt, ob seit dem letzten Besuch etwas passiert ist und ob es Neuigkeiten in Ihrer Krankenakte gibt.
• Er wirft einen Blick in Ihren Mund, um festzustellen, was schief gelaufen ist, und sagt Ihnen, wie es behoben werden kann.
• Sie können seinem Behandlungsplan zustimmen oder eine andere Option wählen.
• Ein paar Monate später ist wieder ein Hollywood-Lächeln auf Ihrem Gesicht. Es wäre früher gewesen, aber Sie konnten nicht lächeln, bis Sie die Rechnung für Ihre zahnärztliche Behandlung endlich vollständig bezahlt hatten.

An diesem Punkt denkt selbst der engagierteste Datenbankprofi wahrscheinlich nicht:„Wow, ich wünschte, es gäbe ein Datenmodell für diese Erfahrung!“ . Aber es gibt sie, und es lohnt sich, sie zu untersuchen. Deshalb haben wir es unten abgedruckt.

Wir stellen unser Datenbankmodell für Zahnarztpraxen vor

Die Idee hinter diesem Modell ist es, jeden Eingriff vom ersten Betreten der Zahnarztpraxis bis zur Lösung des Problems abzudecken. Ein Teil dieses Modells (die Tabellen mit der Bezeichnung user_account , status , user_has_status , role , user_has_role ) wurde in früheren Artikeln vorgestellt und beschrieben. Vielleicht erscheinen Rollen und Status hier unnötig, aber denken Sie daran, dass die Praxis auch eine Krankenschwester zur Bearbeitung der Anamnese (Aufzeichnung), eine Empfangsdame, einen Zahnmedizinstudenten, mehrere ausgebildete Zahnarzthelferinnen oder sogar einen Facharzt oder eine Hygienikerin enthalten könnte. Zahlungsdetails werden in diesem Artikel jedoch nicht berücksichtigt.

Tabellen in der Dentaldatenbank

Der patient Tabelle ist eine der zwei wichtigsten Tabellen in der Datenbank. Es speichert Patientendaten und ist mit Patientendokumenten und -besuchen verbunden. Mit Ausnahme von mail , alle Attribute in der Tabelle sind obligatorisch:

• name – Name des Patienten
• surname – den Nachnamen des Patienten
• identification_number – Dieses Feld wird verwendet, um die eindeutige ID eines Kunden zu speichern, die in der realen Welt verwendet wird
• address – die Adresse des Patienten
• phone – die Telefonnummer des Patienten
• mail – die E-Mail-Adresse des Patienten

Die zweitwichtigste Tabelle in der Datenbank ist visit . In Kombination mit der Tabelle patient , speichert es Informationen über das Ereignis, das alle nachfolgenden Aktionen ausgelöst hat. Die Attribute in der Tabelle sind:

• visit_date – enthält das tatsächliche Datum und die Uhrzeit des Besuchs
• patient_id – ist die Patienten-ID im Zusammenhang mit seinem Besuch
• dentist_id – ist ein Verweis auf user_has_role unter der Annahme, dass die Rolle Zahnarzt ist

Als nächstes folgt die anamnesis Tisch. In der Medizin ist die Anamnese ein Verfahren, bei dem wir medizinische Daten sammeln und speichern, beispielsweise den aktuellen Zustand des Patienten. Die anamnesis Tabelle speichert diese Daten. Da dies kurz nach unserer Ankunft im Büro geschieht, haben wir höchstens eine Anamnese pro Ereignis. Die Attribute in der Tabelle sind:

• anamnesis_id – ist der Primärschlüssel der anamnesis Tabelle, die auch auf visit Tabelle
• user_anamnesis_id – dies bezieht sich auf die user_has_role Tisch. Beachten Sie, dass der Zahnarzt nicht derjenige sein muss, der die Anamnese erstellt hat.
• notes – enthält Textnotizen zu einer bestimmten Anamnese. Es ist kein Pflichtfeld.

Der anamnesis_type table ist ein einfaches Wörterbuch, das verwendet wird, um alle möglichen Werte zu speichern, auf die in anamnesis_catalog . Das einzige Attribut ist type_name , und es kann Werte wie „Krankheit“, „Allergie“, „verwendetes Medikament“ enthalten. Natürlich ist dieses einzige Attribut obligatorisch.

Der anamnesis_catalog Tabelle ist ein Wörterbuch, das spezifischere Informationen liefert als die in anamnesis_type Tisch. Wir verwenden es, um Daten über bestimmte Krankheiten, Allergien und Medikamente zu speichern. Die Attribute sind alle obligatorisch und beinhalten:

• catalog_name – ist der Name eines bestimmten anamnesis_type Unterkategorie
• anamnesis_type_id – ist ein Verweis auf den anamnesis_type Tabelle

Die visit_anamnesis Tabelle dient dazu, Besuchsdaten mit Werten aus dem Anamnesekatalog zu verknüpfen. Jedes Attribut in der Tabelle ist erforderlich:

• anamnesis_anamnesis_id – ist ein Hinweis auf die anamnesis Tabelle
• anamnesis_catalog_id – ist ein Verweis auf den anamnesis_catalog Tabelle

Beachten Sie, dass die visit_anamnesis Tabelle ist eine Viele-zu-Viele-Beziehung, die die mit anamnesis und anamnesis_catalog . Es hat keinen Sinn, dieses Paar (anamnesis_anamnesis_id &anamnesis_catalog_id ) zweimal. Wir verwenden dieses Paar als Primärschlüssel.

Das document table ist ein einfacher Katalog mit Orten, an denen wir Patientendokumente gespeichert haben. Beispiele für solche Dokumente können Scans von Patientenakten, Röntgenbildern und Rechnungen sein. Natürlich speichern wir diese Dokumente nicht direkt in der Datenbank. Dies ist eine grobe Vereinfachung des Dokumentenverwaltungssystems. Die Attribute im document Tabelle sind (alle sind obligatorisch):

• description – ist eine kurze Dokumentenbeschreibung
• location – enthält den genauen Speicherort des Dokuments
• patient_id – ist ein Verweis auf den patient Tabelle

Der tooth Tabelle ist ein einfaches Wörterbuch, das später verwendet wird, wenn der Zahnarzt angibt, welcher Zahn das Problem war. Alle Attribute in dieser Tabelle sind erforderlich. Sie sind:

• is_baby_tooth – ist ein boolescher Wert, der einfach markiert, ob ein Zahn ein Milchzahn ist oder nicht. Natürlich haben wir doppelte Werte für Zähne, die beides sein können. Dies ist wichtig, da ein Verfahren je nach Zahntyp unterschiedlich sein kann.
• tooth – ist eine Beschreibung, die für den Zahn verwendet wird, der Arbeit erledigt – im Allgemeinen wird dieser Wert auf dem Bildschirm angezeigt.

Der problem_catalog table ist ein weiteres einfaches Wörterbuch. Es enthält eine Liste aller möglichen Probleme, die normalerweise an Zähnen oder im Mund auftreten. Beispiele für mögliche Werte für diesen Katalog sind:„Zahnkaries“, „Zahnerosion“, „Gingivitis“, „Wunde im Mund“ oder „unattraktives Lächeln“. Nur der problem_name Attribut ist obligatorisch.

Das problem_detected Tabelle verbindet Besuchs-, Zahn- und Problemkatalogdaten mit der treatment Tisch. Es enthält Verweise auf den tooth , problem_catalog und visit Tische. Alle Attribute sind obligatorisch, außer tooth_id . Der Grund für diese Ausnahme ist, dass sich einige Probleme nicht nur auf einen Zahn beziehen (z. B. bezieht sich Gingivitis auf das Zahnfleisch). Diese drei Attribute bilden zusammen einen alternativen Schlüssel (UNIQUE). Die anderen beiden Attribute sind:

• suggested_treatment_id ist ein Verweis auf die treatment Tisch (die vom Zahnarzt vorgeschlagene Behandlung). Es kann ein NULL-Wert sein, wenn alles in Ordnung ist und wir keine Behandlung benötigen.
• selected_treatment_id ist ein weiterer Hinweis auf die treatment Tisch. Es enthält Daten über den behandelnden Zahnarzt und den Patienten, deren Verwendung vereinbart wurde. Dies kann NULL sein, vielleicht weil der Patient Zeit braucht, um über die vorgeschlagene Behandlung und andere Möglichkeiten nachzudenken.

Beachten Sie, dass die Attribute suggested_treatment_id und selected_treatment_id beziehen sich beide auf die treatment Tisch. Wir können dies tun, weil wir nur höchstens zwei Werte speichern müssen. Wenn wir im Voraus nicht wissen, wie viele Werte wir speichern möchten, sollten wir hier natürlich eine Viele-zu-Viele-Beziehung verwenden.

Der step Tabelle ist ein einfaches Wörterbuch, das alle möglichen Schritte in allen Behandlungen enthält. Die Attribute (alle sind obligatorisch) in der Tabelle sind:

• step_name – ist ein kurzer Schrittname, der auf dem Bildschirm verwendet wird
• description – ist eine Beschreibung der während dieses Schritts durchgeführten Aktionen

Die treatment Tabelle ist in der Tat ein Wörterbuch aller Behandlungen, die die Zahnarztpraxis anbietet. Da die meisten Behandlungen in der Regel aus mehreren Schritten bestehen, müssen wir wissen, welcher Schritt der letzte ist. Die Attribute in der Tabelle sind alle erforderlich:

• treatment_name – ist der Name der Behandlung innerhalb des Systems
• description – ist eine kurze Behandlungsbeschreibung
• final_step_id – ist ein Verweis auf den step Tisch. Wir können diese Informationen verwenden, um festzustellen, ob die Behandlung beendet ist, und automatische Maßnahmen einleiten, oder wir können diese Informationen dem Benutzer einfach anzeigen und ihn die nächste Maßnahme auswählen lassen.

Die treatment_steps Tabelle ist eine Viele-zu-Viele-Beziehung, die Schritte mit Behandlungen verbindet. Die obligatorischen Attribute in der Tabelle sind:

• treatment_id – ist ein Verweis auf die treatment Tabelle
• step_id – ist ein Verweis auf den step Tabelle
• step_order – ist eine Zahl, die die Reihenfolge der Behandlungsschritte definiert

In dieser Tabelle sind zwei alternative Schlüssel (UNIQUE) definiert:

• Paar (treatment_id &step_id ) – dieser Schritt kann der Behandlung nur einmal zugeordnet werden
• Paar (treatment_id &step_order ) – die Behandlung kann nicht zwei Schritte mit der gleichen Auftragsnummer haben

Die visit_steps Tabelle ist eine Liste aller Schritte, die nach diesem Besuch tatsächlich durchgeführt wurden. Es gibt zwei Gründe, warum wir sie in separaten Tabellen speichern möchten:

1. Wir haben uns vielleicht für eine Behandlung entschieden, aber wir brauchen nicht alle dafür definierten Schritte, und
2. Auf diese Weise speichern wir die tatsächliche Zeit, zu der der Schritt ausgeführt wurde.

Die Attribute in der Tabelle (alle sind obligatorisch, außer problem_detected_id und notes ) lauten wie folgt:

• visit_id – ist ein Verweis auf den visit Tabelle
• treatment_steps_id – ist ein Verweis auf die treatment_steps Tabelle
• problem_detected_id – ist ein Verweis auf problem_detected Tisch. Diese Beziehung gibt uns Informationen darüber, welches Problem diese Aktion ausgelöst hat. Es kann NULL sein, wenn der Zahnarzt beschließt, Maßnahmen zu ergreifen, die nichts mit einem erkannten Problem zu tun haben.
• step_time – ist das Datum und/oder die Uhrzeit, zu der der Schritt tatsächlich durchgeführt wurde
• notes – sind Notizen für diesen Schritt, falls erforderlich

Der visit_status table ist ein einfaches Wörterbuch, das verwendet wird, um alle möglichen Status zu speichern, die ein Besuch haben könnte. Wir könnten Status wie „erster Besuch in der Praxis überhaupt“, „erster Besuch“, „Behandlung im Gange“, „Behandlung erfolgreich abgeschlossen“ verwenden. Es enthält nur ein Attribut, status_name , was obligatorisch ist.

Der visit_status_history Tabelle wird verwendet, um Daten über die Status zu speichern, die der Besuch durchlaufen hat. Der Gedanke ist, dass wir den Status manuell hinzufügen, nachdem bestimmte Aktionen abgeschlossen sind (z. B. nach der Anamnese, nach Abschluss einiger Behandlungsschritte). Die Attribute, die alle erforderlich sind, folgen:

• status_time – ist das Datum/die Uhrzeit, wann der Status eingefügt wurde
• visit_status_id – ist ein Verweis auf den visit_status Tabelle
• visit_id – ist ein Verweis auf den visit Tabelle

Mögliche Verbesserungen am Zahndatenbankmodell

Unser Modell hat einen guten Start hingelegt, könnte aber verbessert werden. Beispielsweise werden die folgenden Elemente nicht abgedeckt:

• Zahlungsmethoden und Rechnungen
• Termine planen (obwohl dies durch Einfügen von Daten in die visit_steps Tabelle für zukünftige Veranstaltungen)
• Verwaltung von Dokumenten

Trotzdem denken Sie anders über Ihre Zahnarztpraxis und ihre Verfahren, nicht wahr?