医療予約アプリのデータモデル

オンラインアプリを使用して医師の予約をすることは、プロセス全体を簡素化する革新です。予約予約アプリの背後にあるデータモデルを詳しく見ていきましょう。

なぜアプリを使うのですか？これにより、人々は自分が選んだ医師を見つけやすくなり、医師の専門的な記録や患者のレビューを見ることができます。誰かが好きな医者を見つけたら、アプリを離れることなく彼らとの約束を予約することができます。このアプリは、医師が患者の待ち時間をできるだけ短くし、患者のスケジュールを立て、患者のオンラインレビューを監視できるようにするのにも役立ちます。

医療予約アプリの要件

簡単に言うと、私たちのアプリは次のことを期待しています：

患者がさまざまな専門分野の医師（かかりつけ医、心臓専門医、足病医など）を場所で検索できるようにします。
医師の経験年数、患者のいる場所からの距離、患者の推奨事項、およびレビューインデックス（患者のベッドサイドマナー、待ち時間、スタッフなどの総合評価）に基づいて、順序付けられた医師のリストを表示します。
医師の初期およびフォローアップのコンサルティング料金を表示します。
医師の学位、認定、インターンシップ、過去および現在の病院との提携に関する詳細など、医師のプロフィールを取得して表示します。
アプリユーザーからの医師に関するレビューを記録します。このレビューでは、医師とそのスタッフの完全なプレビューを他のアプリユーザーに提供します。

また、アプリのユニークなセールスポイントを忘れないでください。今後利用可能な予定を表示し、ユーザーが予約できるようにする 。

アプリ要件の分類

基本的に、アプリの要件は次の4つの領域に分けることができます。

医師のデータの管理 –医師は登録してすべての詳細を入力できます。
医師のOPD（外来部門）と診療所の詳細の管理 –医師（またはそのスタッフ）は、診療所またはOPDのスケジュールと空き状況に関する詳細を記録できます。
クライアントとレビューデータの管理 –ユーザーは登録して基本的な詳細を入力できます。医師に関するレビューを投稿することもできます。
予定の管理 –ユーザーは特定の基準に基づいて医師を検索できます。

これらの領域を個別に見てみましょう。

医師のデータの管理

医師は特定の必須の詳細を入力することでアプリに登録できますが、予約機能は、完全なプロファイルを完了した後にのみ有効になります。これには、資格（専門職学位、認定/専門分野、インターンシップ）、および病院や医療サービスプロバイダーとの過去および現在の提携が含まれます。

以下の表は、この情報を管理しています。

doctor テーブルには、登録時に入力する医師に関する基本的な詳細が格納されます。この表の列は次のとおりです。

id –登録時にアプリが医師に割り当てる一意の番号。
first_name –医師の名。
last_name –医師の名前。
professional_statement –医師の資格、経験、専門的なモットーなどの詳細な概要。この情報は医師によって入力され、各医師のプロファイルページに表示されます。
practicing_from –医師が薬の練習を始めた日付。アプリはこの列の情報に基づいて各医師の経験評価を導き出すため、これは非常に重要です。

specialization 表には、整形外科、神経内科医、歯科医などの既存のすべての専門分野が含まれています。医師は複数の専門分野を持つことができます。実際、医師が関連分野を専門とすることはかなり一般的です。たとえば、神経内科医は精神科医になることもできます。産婦人科医は内分泌代謝科医になることができます。したがって、doctor_specialization テーブルを使用すると、doctor およびspecialization テーブル。これら2つのテーブルの属性は一目瞭然です。

qualification 表には、学位、認定、研究論文、セミナー、継続的なトレーニングなど、医師の教育と専門資格に関する詳細が格納されています。さまざまな種類の資格の詳細を容易にするために、これらのフィールドに非常に一般的な名前を付けました。

id –テーブルの主キー。
doctor_id – doctor 表を作成し、医師と資格を関連付けます。
qualification_name –学位、認定、研究論文などの名前を示します。
institute_name –医師に資格を発行した機関。これは、大学、医療機関、医療従事者の国際協会などです。
procurement_year –資格が取得または授与された日付。

hospital_affiliation 表には、病院や医療サービスプロバイダーとの医師の提携に関する情報が保持されています。このデータは医師のプロファイルに表示するためのものであり、予約機能では重要ではありません。 OPD（外来部門）の詳細は個別に入力され、この記事の後半で処理されます。

このテーブルの列は次のとおりです。

id –テーブルの主キー。
doctor_id – doctor 表を作成し、医師を提携病院にリンクします。
hospital_name –提携病院の名前。
city and country –病院が所在する都市と国。これらのアドレス列は、アプリの検索機能では何の役割も果たしません。医師のプロフィールに表示するためだけのものです。
start_date –医師の病院との提携が開始されたとき。
end_date –所属が終了したとき。現在の所属には終了日がないため、null可能です。

医師のOPD/クリニックの詳細の管理

このセクションの情報は、医師（またはそのスタッフ）によって入力され、アプリの検索および予約機能で重要な役割を果たします。

office 表には、医師が所属する病院の外来部門と、自身の診療所（つまり、オフィスや外科）に関する情報が含まれています。この表の列は次のとおりです。

id –このテーブルの主キー。
doctor_id – doctor 表と関連する医師を示します。
hospital_affiliation_id –医師がOPDを利用できる病院を示します。この列はOPDには適用できますが、診療所には適用できないため、null可能です。
time_slot_per_client_in_min –相談に割り当てられた時間（分単位）を保存します。分数は、医師の経験に基づいて入力されます。この列は、アプリが次に使用可能なスロットを決定するのに役立ちます。この数は予約の長さを保証するものではありませんが、アプリを使用して予約する場合、患者の待ち時間を最小限に抑えるのに役立ちます。
first_consultation_fee –最初の訪問に対して医師が請求する料金。これは重要ではないように思われるかもしれませんが、検索機能にとっては非常に重要です。料金は非常に一般的なフィルター基準です。
followup_consultation_fee –多くの医師は、最初の診察よりもフォローアップ訪問の料金が安くなります。この列には、フォローアップの相談費用が格納されます。
street_address –病院のOPDまたはクリニックの住所。
city 、state およびcountry –病院または診療所が所在する市、州、国。
zip –診療所または病院が所在する郵便番号。多くの場合、人々は郵便番号を使用して近くの地域の医師を検索するため、このフィールドはアプリの検索機能にとって重要になります。

OPDの詳細を「hospital_affiliation」テーブルで簡単に追跡できるのに、なぜ別個の「オフィス」テーブルがあるのですか？

3つの理由：

医師は、仕事の1つの側面（つまり、手術の実施）については病院と提携している場合がありますが、他の側面（つまり、持ち込み患者の診察）については提携していない場合があります。 hospital_affiliation テーブルのみ。
多くの医師は病院と提携していませんが、独自の診療所や事務所を持っています。これらの医師の情報も保存する必要があります。
医師は、さまざまな場所に複数のオフィスを持っている場合もあれば、病院の複数の支店で働いている場合もあります。医師が1つの病院の場所に所属していると表示された場合、一部の情報が失われる可能性があります。これが、個別の住所の詳細を維持する理由です。

office_doctor_availability テーブルには、医師のOPD /診療所の空き状況が時間枠（たとえば、朝2時間、夕方4時間）で保存されます。この方法で1日を分割することは非常に一般的であるため、可用性スロットを格納するための追加のテーブルを用意することは理にかなっています。さらに、医師は複数のOPDシフトを行うことができます。このテーブルの列は次のとおりです。

id –テーブルの主キー。
office_id –「オフィス」テーブルを参照します。
day_of_week –曜日、つまり月曜日、火曜日など。これにより、医師はさまざまな曜日（たとえば、週末と平日）でさまざまな可用性を利用できます。
start_time –医師が最初の患者の準備ができたとき。
end_time –最終的な予定またはシフトが終了する予定の場合。
is_available –医師が特定の日または時間帯の空き状況をマークできるようにします。この列はデフォルトで「Y」で初期化され、医師が利用できないとマークすると「N」に更新されます。
reason_of_unavailablity –多くの医師は、なぜ彼らが利用できないのか、または予約をキャンセルしなければならないのかを明らかにすることを好みます。これは、医師とその患者の間に透明な関係を構築するのに役立ちます。オプションなので、これをnull許容列として保持しました。

in_network_insurance テーブルには保険情報が格納されます。多くの国では、医療サービスは非常に費用がかかり、健康保険は義務付けられています。このような場合、この表には、病院のOPDまたはクリニックで完全に受け入れられている保険会社の詳細が含まれています。

クライアントとレビューデータの管理

患者にとって、アプリへの登録に必要な情報はごくわずかです。これからは、「ユーザー」や「患者」ではなく「クライアント」を使用します。

client_account テーブルには、クライアントの基本的な詳細が格納されます。これらの詳細は、登録時に取得されます。この表の列は次のとおりです。

id –各クライアントに割り当てられた一意の番号。
first_name –クライアントの名。
last_name –クライアントの名前。
contact_number –予約情報を送信できるクライアントの電話番号（できれば携帯電話番号）。これは、診療所のスタッフがクライアントに連絡できる番号でもあります。
email –クライアントのメールアドレス。アプリはクライアントに予定のリマインダーを送信する場合があります。

client_review 表は、医師へのフィードバック（つまり、クライアントのレビュー）を提供するだけでなく、潜在的なクライアントが医師を選択するのにも役立ちます。これは、このアプリの不可欠なコンポーネントです。このテーブルの列は次のとおりです。

id –このテーブルの主キー。
user_account_id –レビューを送信しているユーザーを示します。
doctor_id –レビュー中の医師。
is_review_anonymous –クライアントの名前がレビューとともに公開されるかどうか。これはクライアントのセキュリティ機能です。
wait_time_rating –この数値列には、1（最低）から10（最高）の範囲の評価が含まれます。これは、医師の診察をどのくらい待ったかについてのクライアントの意見を反映しています。
bedside_manner_rating –医師のベッドサイドマナーに関するクライアントの意見を保存します（つまり、医師が親切、思いやり、コミュニケーションが良好かどうかなど）
overall_rating –医師との一般的な経験に対するクライアントの評価。
review –クライアントはここで詳細なフィードバックを提供できます。
is_doctor_recommended –このインジケーター列は、クライアントが医師を推薦するかどうかを示します。
review_date –レビューが送信されたとき。

予定の管理

このセクションは、クライアントがさまざまな医師の空き状況を確認して予約できるため、このアプリの最も重要なUSP（Unique Selling Point）です。

appointment テーブルには、クライアントの予定の詳細が保持されます。その列は次のとおりです。

id –各予定には一意の番号が割り当てられます。この番号は他の場所で参照されています。
user_account_id –どのクライアントが予定を予約していますか。
office_id –どの医師とどの病院のOPDまたはクリニックが予約に関与しているかを示します。
probable_start_time –これは、予定の開始予定時刻を保持するタイムスタンプ列です。医療の予約の開始時間は、通常、絶対的なものではなく、可能性が高いものです。
actual_end_time –コンサルテーションの実際の終了時間。予定がいつ終了するかには多くの要因が影響する可能性があるため、最初はこの列は空白です。したがって、これはnull許容列です。
appointment_status_id –これはappointment_status テーブル、およびそれは予定の現在のステータスを示します。ステータスに指定できる値は、「アクティブ」、「キャンセル済み」、および「完了」です。最初は、ステータスは「アクティブ」になります。予約が完了すると、「完了」になります。クライアントが予約をキャンセルすると、「キャンセル」されます。
appointment_taken_date –予約が行われた日付。
app_booking_channel_id –予定が予約されたチャネル。予約を行うための複数のチャネルがあります。アプリ、病院への電話、医師またはそのオフィスへの電話などです。

完全なデータモデルを見る

実行中の検索機能

63101の郵便番号で眼科医を検索してみましょう。検索結果は、次の基準で並べ替える必要があります。

ほとんどの経験
最高のクライアント推奨評価
最低の初期相談料金

コードは次のとおりです：

SELECT doctor_name, hospital_name, practicing_from, first_consultation_fee, recomm_count FROM
(SELECT d.doctor_id, d.first_name || ‘ ‘ || d.last_name as doctor_name, 
ha.hospital_name, d.practicing_from, o.first_consultation_fee 
FROM office o, doctor d, doctor_specialization ds, specialization s, hospital_affiliation ha 
WHERE o.doctor_id = d.id AND d.id = ds.doctor_id 
AND s.id = ds.specialization_id AND s.specialization_name = ‘Ophthalmologist’
AND o.hospital_affiliation_id = ha.id (+)
AND o.zip = ‘63101’) doctor_detail, 
(SELECT doctor_id, count(1) as recomm_count FROM client_review 
WHERE is_doctor_recommended = ‘Y’ GROUP BY doctor_id) review_count
WHERE doctor_detail.doctor_id = review_count.doctor_id
ORDER BY doctor_detail.practicing_from DESC, review_count.recomm_count DESC doctor_detail.first_consultation_fee ASC;

何を追加しますか？

このアプリとこのデータモデルに他に何を追加できますか？コメントであなたの意見を共有してください。