Pemodelan Basis Data

Saya menulis lagu tentang benang gigi tetapi apakah gigi seseorang menjadi lebih bersih?

Frank Zappa

Ketika kita memikirkan kantor gigi, asosiasi pertama kita adalah latihan, rasa sakit, dan ketakutan. Oke, itu terdengar buruk. Selain merawat gigi, seorang dokter gigi memiliki banyak kewajiban lain yang bersifat profesional, legal, atau keduanya. Semuanya membutuhkan pengelolaan data yang tepat.

Untuk memenuhi persyaratan dokumentasi ini, banyak kantor gigi dan medis menggunakan catatan kertas. Perlahan tapi pasti, ada tren ke arah arsip dan manajemen digital abad ke-21.

Di dalam Kantor Kedokteran Gigi

Pergi ke dokter gigi bukanlah hal yang biasa kita ingat dengan suka cita. Jika kami beruntung, kami menghindari rasa sakit tetapi dompet kami mungkin sangat menderita. Setelah kita masuk ke kantor dokter gigi, prosedurnya biasanya sebagai berikut:

Kalian berdua terlibat dalam obrolan singkat. (Seringkali tidak menyenangkan karena Anda berjanji kepada dokter gigi Anda akan mengunjunginya minggu depan dan 2 tahun telah berlalu. Kemudian Anda mengatakan Anda lupa, dia setuju, dan semuanya baik-baik saja lagi.)
Anda duduk di kursi sementara dia melihat catatan perawatan Anda sebelumnya. Dia bertanya apakah ada sesuatu yang terjadi sejak kunjungan terakhir dan apakah ada pembaruan pada rekam medis Anda.
Dia memeriksa ke dalam mulut Anda untuk menentukan apa yang salah, dan memberi tahu Anda apa yang akan memperbaikinya.
Anda dapat menyetujui rencana perawatannya atau memilih opsi lain.
Beberapa bulan kemudian, senyum Hollywood muncul lagi di wajahmu. Itu akan lebih cepat, tetapi Anda tidak bisa tersenyum sampai akhirnya Anda membayar penuh tagihan untuk perawatan gigi Anda.

Pada titik ini, bahkan profesional database yang paling berdedikasi mungkin tidak berpikir, ‘Wow, saya berharap ada model data untuk pengalaman ini!’ . Tapi ada, dan itu layak untuk diperiksa. Jadi kami telah mencetaknya di bawah.

Memperkenalkan Model Database Kantor Gigi Kami

Ide di balik model ini adalah untuk mencakup setiap prosedur dari saat kita pertama kali masuk ke kantor dokter gigi sampai masalahnya terpecahkan. Bagian dari model ini (tabel berlabel user_account , status , user_has_status , role , user_has_role ) disajikan dan dijelaskan dalam artikel sebelumnya. Mungkin peran dan status terlihat tidak perlu di sini, tetapi ingat bahwa praktik ini juga dapat berisi perawat yang menangani anamnesis (pencatatan), resepsionis, mahasiswa kedokteran gigi, beberapa asisten dokter gigi terlatih, atau bahkan spesialis tamu atau ahli kebersihan. Namun, detail pembayaran tidak akan dipertimbangkan dalam artikel ini.

Tabel di Database Gigi

patient tabel adalah salah satu dari dua tabel yang paling penting dalam database. Ini menyimpan data pasien dan terhubung ke dokumen dan kunjungan pasien. Dengan pengecualian mail , semua atribut dalam tabel adalah wajib:

name – nama pasien
surname – nama belakang pasien
identification_number – kolom ini digunakan untuk menyimpan id unik klien yang digunakan di dunia nyata
address – alamat pasien
phone – nomor telepon pasien
mail – alamat surat pasien

Tabel terpenting kedua dalam database adalah visit . Saat digabungkan dengan tabel patient , ini menyimpan informasi tentang peristiwa yang memicu semua tindakan selanjutnya. Atribut dalam tabel adalah:

visit_date – berisi tanggal dan waktu aktual saat kunjungan terjadi
patient_id – apakah id pasien terkait dengan kunjungannya
dentist_id – adalah referensi ke user_has_role tabel, dengan asumsi bahwa perannya adalah dokter gigi

Selanjutnya adalah anamnesis meja. Dalam kedokteran, anamnesa adalah suatu prosedur dimana kami mengumpulkan dan menyimpan riwayat data medis, seperti kondisi pasien saat ini. anamnesis tabel menyimpan data ini. Karena ini terjadi segera setelah kami tiba di kantor, kami akan memiliki paling banyak satu anamnesis per acara. Atribut dalam tabel adalah:

anamnesis_id – adalah kunci utama dari anamnesis tabel, yang juga merujuk pada visit meja
user_anamnesis_id – ini berkaitan dengan user_has_role meja. Perhatikan bahwa tidak harus dokter gigi yang melakukan anamnesa.
notes – berisi catatan teks tentang anamnesis tertentu. Ini bukan bidang wajib.

anamnesis_type table adalah kamus sederhana yang digunakan untuk menyimpan semua kemungkinan nilai yang dirujuk dalam anamnesis_catalog . Satu-satunya atribut adalah type_name , dan dapat berisi nilai-nilai seperti "penyakit", "alergi", "obat yang digunakan". Tentu saja, satu-satunya atribut itu wajib.

anamnesis_catalog tabel adalah kamus yang memberikan informasi lebih spesifik daripada nilai yang disimpan dalam anamnesis_type meja. Kami akan menggunakannya untuk menyimpan data tentang penyakit tertentu, alergi, dan obat-obatan. Semua atribut bersifat wajib, dan meliputi:

catalog_name – adalah nama anamnesis_type subkategori
anamnesis_type_id – adalah referensi ke anamnesis_type meja

visit_anamnesis tabel digunakan untuk menghubungkan data kunjungan dengan nilai dari katalog anamnesis. Setiap atribut dalam tabel wajib diisi:

anamnesis_anamnesis_id – adalah referensi ke anamnesis meja
anamnesis_catalog_id – adalah referensi ke anamnesis_catalog meja

Perhatikan bahwa visit_anamnesis table adalah relasi many-to-many yang menghubungkan tabel-tabel yang diberi label anamnesis dan anamnesis_catalog . Tidak ada gunanya menyimpan pasangan ini (anamnesis_anamnesis_id &anamnesis_catalog_id ) dua kali. Kami akan menggunakan pasangan itu sebagai kunci utama.

document tabel adalah katalog sederhana yang berisi lokasi tempat kami menyimpan dokumen pasien. Contoh dokumen tersebut dapat berupa scan grafik pasien, sinar-X, dan faktur. Tentu saja kami tidak akan menyimpan dokumen-dokumen ini langsung ke dalam database. Ini adalah penyederhanaan kasar dari sistem manajemen dokumen. Atribut dalam document tabel adalah (semuanya wajib):

description – adalah deskripsi dokumen singkat
location – berisi lokasi dokumen yang tepat
patient_id – adalah referensi ke patient meja

tooth tabel adalah kamus sederhana yang digunakan kemudian ketika dokter gigi menentukan gigi mana yang bermasalah. Semua atribut dalam tabel ini wajib diisi. Mereka adalah:

is_baby_tooth – adalah nilai Boolean yang hanya menandai apakah sebuah gigi adalah gigi susu atau bukan. Tentu saja, kita akan memiliki nilai duplikat untuk gigi yang bisa menjadi keduanya. Hal ini penting karena suatu prosedur mungkin berbeda menurut jenis giginya.
tooth – adalah deskripsi yang digunakan untuk menyelesaikan pekerjaan gigi – umumnya, nilai tersebut akan ditampilkan di layar.

problem_catalog tabel adalah kamus sederhana lainnya. Ini berisi daftar semua kemungkinan masalah yang biasanya ditemukan pada gigi atau mulut. Contoh nilai yang mungkin untuk katalog ini adalah:“kerusakan gigi”, “erosi gigi”, “gingivitis”, “luka mulut” atau “senyum yang tidak menarik”. Hanya problem_name atribut adalah wajib.

problem_detected tabel menghubungkan data katalog kunjungan, gigi, dan masalah dengan treatment meja. Ini berisi referensi ke tooth , problem_catalog dan visit tabel. Semua atribut wajib kecuali tooth_id . Alasan pengecualian ini adalah bahwa beberapa masalah tidak hanya merujuk pada satu gigi (misalnya gingivitis mengacu pada gusi). Ketiga atribut ini bersama-sama membentuk kunci alternatif (UNIQUE). Dua atribut lainnya adalah:

suggested_treatment_id adalah referensi ke treatment meja (perawatan yang disarankan oleh dokter gigi). Ini bisa menjadi nilai NULL ketika semuanya baik-baik saja dan kita tidak memerlukan perawatan apa pun.
selected_treatment_id adalah referensi lain untuk treatment meja. Ini berisi data tentang perawatan dokter gigi dan pasien setuju untuk digunakan. Ini bisa menjadi NULL, mungkin karena pasien perlu waktu untuk memikirkan pengobatan yang disarankan dan kemungkinan lainnya.

Perhatikan bahwa atribut suggested_treatment_id dan selected_treatment_id keduanya dirujuk ke treatment meja. Kita dapat melakukan ini karena kita hanya perlu menyimpan, paling banyak, dua nilai. Tentu saja, jika kita tidak tahu sebelumnya berapa banyak nilai yang ingin kita simpan, maka kita harus menggunakan hubungan banyak-ke-banyak di sini.

step tabel adalah kamus sederhana yang berisi semua langkah yang mungkin dalam semua perawatan. Atribut (semuanya wajib) dalam tabel adalah:

step_name – adalah nama langkah pendek yang digunakan di layar
description – adalah deskripsi tindakan yang diambil selama langkah ini

treatment tabel sebenarnya adalah kamus semua perawatan yang disediakan oleh kantor gigi. Karena kebanyakan perawatan biasanya terdiri dari beberapa langkah, kita harus tahu langkah mana yang terakhir. Semua atribut dalam tabel wajib diisi:

treatment_name – adalah nama perawatan dalam sistem
description – adalah deskripsi perawatan singkat
final_step_id – adalah referensi ke step meja. Kami dapat menggunakan informasi ini untuk mendeteksi apakah perawatan telah selesai dan memulai tindakan otomatis, atau kami dapat dengan mudah menunjukkan informasi tersebut kepada pengguna dan membiarkan dia memilih tindakan berikutnya.

treatment_steps tabel adalah relasi banyak ke banyak yang menghubungkan langkah dengan perlakuan. Atribut wajib dalam tabel adalah:

treatment_id – adalah referensi ke treatment meja
step_id – adalah referensi ke step meja
step_order – adalah angka yang menentukan urutan langkah dalam perawatan

Dalam tabel ini dua kunci alternatif (UNIQUE) didefinisikan:

pasangan (treatment_id &step_id ) – langkah ini hanya dapat ditetapkan ke perawatan sekali
pasangan (treatment_id &step_order ) – perlakuan tidak boleh memiliki dua langkah dengan nomor urut yang sama

visit_steps tabel adalah daftar semua langkah yang benar-benar dilakukan setelah kunjungan itu. Ada dua alasan mengapa kami ingin menyimpannya di tabel terpisah:

Kami mungkin telah memilih pengobatan, tetapi kami tidak memerlukan semua langkah yang ditentukan untuk itu, dan
Dengan cara ini, kami akan menyimpan waktu sebenarnya saat langkah tersebut dilakukan.

Atribut dalam tabel (semuanya wajib kecuali problem_detected_id dan notes ) adalah sebagai berikut:

visit_id – adalah referensi ke visit meja
treatment_steps_id – adalah referensi ke treatment_steps meja
problem_detected_id – adalah referensi ke problem_detected meja. Hubungan ini memberi kita informasi tentang masalah apa yang memulai tindakan itu. Ini bisa menjadi NULL ketika dokter gigi memutuskan untuk mengambil tindakan yang tidak terkait dengan masalah yang terdeteksi.
step_time – adalah tanggal dan/atau waktu saat langkah itu benar-benar dilakukan
notes – adalah catatan untuk langkah itu, jika diperlukan

visit_status table adalah kamus sederhana yang digunakan untuk menyimpan semua status yang mungkin dimiliki oleh sebuah kunjungan. Kita dapat menggunakan status seperti "kunjungan pertama ke kantor", "kunjungan pertama", "perawatan sedang berlangsung", "perawatan selesai dengan sukses". Ini hanya berisi satu atribut, status_name , yang wajib.

visit_status_history tabel digunakan untuk menyimpan data tentang status kunjungan. Pikirannya adalah bahwa kita menambahkan status secara manual setelah tindakan tertentu selesai (misalnya setelah anamnesis, setelah menyelesaikan beberapa langkah dari beberapa perawatan). Atribut, yang semuanya wajib, ikuti:

status_time – adalah tanggal/waktu saat status dimasukkan
visit_status_id – adalah referensi ke visit_status meja
visit_id – adalah referensi ke visit meja

Kemungkinan Perbaikan Model Database Gigi

Model kami dimulai dengan baik, tetapi dapat ditingkatkan. Misalnya, ini tidak mencakup item berikut:

metode pembayaran dan faktur
menjadwalkan rapat (walaupun ini dapat dilakukan dengan memasukkan data ke dalam visit_steps tabel untuk acara mendatang)
penanganan dokumen

Tetap saja, itu membuat Anda berpikir secara berbeda tentang kantor gigi Anda dan prosedurnya, bukan?