Database
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> Database

Mô hình dữ liệu cho ứng dụng đặt lịch hẹn khám bệnh

Đặt lịch hẹn với bác sĩ bằng ứng dụng trực tuyến là một sự đổi mới giúp đơn giản hóa toàn bộ quy trình. Hãy đi sâu vào mô hình dữ liệu đằng sau một ứng dụng đặt lịch hẹn.

Tại sao sử dụng một ứng dụng? Nó giúp mọi người dễ dàng tìm thấy bác sĩ mà họ lựa chọn hơn, cho phép họ xem hồ sơ chuyên môn của bác sĩ và đánh giá của bệnh nhân. Khi ai đó tìm được bác sĩ mà họ thích, họ có thể đặt lịch hẹn với họ mà không cần rời khỏi ứng dụng. Một ứng dụng cũng có thể giúp bác sĩ giữ thời gian chờ đợi của bệnh nhân càng ngắn càng tốt, giúp họ lên lịch cho bệnh nhân và cho phép họ theo dõi các đánh giá trực tuyến của bệnh nhân.

Yêu cầu đối với cuộc hẹn khám bệnh

Tóm lại, chúng tôi hy vọng rằng ứng dụng của chúng tôi sẽ:

  • Cho phép bệnh nhân tìm kiếm các bác sĩ thuộc nhiều chuyên môn khác nhau (bác sĩ gia đình, bác sĩ tim mạch, bác sĩ nhi khoa, v.v.) theo địa điểm.
  • Hiển thị danh sách bác sĩ được sắp xếp dựa trên số năm kinh nghiệm của họ, khoảng cách với vị trí của bệnh nhân, các khuyến nghị cho bệnh nhân và chỉ số đánh giá của họ (xếp hạng chung của bệnh nhân về cách thức giường bệnh, thời gian chờ đợi, nhân viên, v.v.)
  • Hiển thị phí tư vấn ban đầu và theo dõi của bác sĩ.
  • Chụp và hiển thị hồ sơ của các bác sĩ, bao gồm thông tin chi tiết về bằng cấp, chứng chỉ, thời gian thực tập cũng như các mối quan hệ trong quá khứ và hiện tại của họ với bệnh viện.
  • Ghi lại các bài đánh giá về bác sĩ từ người dùng ứng dụng. Bài đánh giá này sẽ cung cấp bản xem trước kỹ lưỡng về bác sĩ và nhân viên của họ cho những người dùng ứng dụng khác.

Và đừng quên điểm bán hàng độc đáo của ứng dụng: hiển thị các cuộc hẹn có sẵn sắp tới và cho phép người dùng đặt một .

Phân loại yêu cầu ứng dụng

Về cơ bản, chúng ta có thể chia các yêu cầu của ứng dụng thành 4 lĩnh vực sau:

  1. Quản lý dữ liệu của các bác sĩ - Các bác sĩ có thể đăng ký và nhập tất cả các thông tin chi tiết của họ.
  2. Quản lý OPD của Bác sĩ (Khoa Ngoại trú) và Chi tiết Phòng khám - Các bác sĩ (hoặc nhân viên của họ) có thể ghi thông tin chi tiết về lịch khám và tình trạng sẵn có của phòng khám hoặc OPD của họ.
  3. Quản lý Khách hàng và Đánh giá Dữ liệu - Người dùng có thể đăng ký và nhập các chi tiết cơ bản của họ. Họ cũng có thể đăng các bài đánh giá về bác sĩ.
  4. Quản lý Cuộc hẹn - Người dùng có thể tìm kiếm bác sĩ dựa trên các tiêu chí nhất định.

Hãy xem xét từng khu vực này.

Quản lý dữ liệu của bác sĩ

Các bác sĩ có thể đăng ký với ứng dụng bằng cách điền vào một số chi tiết bắt buộc, nhưng tính năng đặt lịch hẹn chỉ được bật sau khi họ hoàn thành hồ sơ đầy đủ của mình. Điều này bao gồm bằng cấp của họ (bằng cấp chuyên môn, chứng chỉ / chuyên môn và thực tập) cũng như các mối quan hệ trong quá khứ và hiện tại của họ với các bệnh viện và nhà cung cấp dịch vụ chăm sóc sức khỏe.

Các bảng hiển thị bên dưới quản lý thông tin này.

doctor bảng lưu trữ thông tin chi tiết cơ bản về bác sĩ, mà họ nhập trong khi đăng ký. Các cột trong bảng này là:

  • id - Một số duy nhất mà ứng dụng chỉ định cho các bác sĩ khi đăng ký.
  • first_name - Tên của bác sĩ.
  • last_name - Họ của bác sĩ.
  • professional_statement - Thông tin tổng quan chi tiết về trình độ, kinh nghiệm của bác sĩ, phương châm làm việc của họ, v.v. Thông tin này do bác sĩ nhập và hiển thị trên trang hồ sơ của mỗi bác sĩ.
  • practicing_from - Ngày bác sĩ bắt đầu hành nghề y. Điều này có ý nghĩa sâu sắc vì ứng dụng sẽ lấy xếp hạng kinh nghiệm cho từng bác sĩ dựa trên thông tin trong cột này.

specialization bảng chứa tất cả các chuyên ngành y tế hiện có như chỉnh hình, bác sĩ thần kinh, nha sĩ, v.v. Một bác sĩ có thể có nhiều hơn một chuyên ngành; trên thực tế, việc một bác sĩ chuyên về các lĩnh vực liên quan là điều khá phổ biến. Ví dụ, một nhà thần kinh học cũng có thể là một bác sĩ tâm thần; bác sĩ phụ khoa có thể là bác sĩ nội tiết, v.v. Do đó, doctor_specialization bảng cho phép mối quan hệ nhiều-nhiều giữa doctorspecialization những cái bàn. Các thuộc tính trên hai bảng này là tự giải thích.

qualification bảng lưu trữ thông tin chi tiết về trình độ học vấn và chuyên môn của bác sĩ, bao gồm bằng cấp, chứng chỉ, tài liệu nghiên cứu, hội thảo, đào tạo liên tục, v.v. Để tạo điều kiện cho các loại thông tin chi tiết về bằng cấp, tôi đã đặt những tên khá chung chung cho các trường này:

  • id - Khóa chính của bảng.
  • doctor_id - Tham khảo doctor bảng và liên hệ bác sĩ với trình độ chuyên môn.
  • qualification_name - Ký tên bằng cấp, chứng chỉ, bài nghiên cứu, v.v.
  • institute_name - Cơ sở đã cấp chứng chỉ cho bác sĩ. Đây có thể là một trường đại học, một tổ chức y tế, một hiệp hội quốc tế của những người hành nghề y, v.v.
  • procurement_year - Ngày đạt được hoặc trao chứng chỉ.

hospital_affiliation bảng lưu trữ thông tin về mối quan hệ của bác sĩ với các bệnh viện và nhà cung cấp dịch vụ chăm sóc sức khỏe. Dữ liệu này chỉ để hiển thị trên hồ sơ của bác sĩ và không có ý nghĩa trong tính năng đặt lịch hẹn. Thông tin chi tiết về OPD (Khoa ngoại trú) được nhập riêng và sẽ được xử lý sau trong bài viết này.

Các cột của bảng này là:

  • id - Khóa chính của bảng.
  • doctor_id - Tham khảo doctor bảng và liên kết bác sĩ với bệnh viện liên kết.
  • hospital_name - Tên bệnh viện liên kết.
  • city and country - Thành phố và quốc gia nơi bệnh viện tọa lạc. Các cột địa chỉ này không đóng bất kỳ vai trò nào trong chức năng tìm kiếm của ứng dụng; chúng chỉ để hiển thị trên hồ sơ của bác sĩ.
  • start_date - Khi mối quan hệ của bác sĩ với bệnh viện bắt đầu.
  • end_date - Khi liên kết kết thúc. Nó là vô hiệu vì các đơn vị liên kết hiện tại sẽ không có ngày kết thúc.

Quản lý OPD / Chi tiết Phòng khám của Bác sĩ

Thông tin trong phần này được nhập bởi các bác sĩ (hoặc nhân viên của họ) và đóng một vai trò quan trọng trong chức năng tìm kiếm và đặt phòng của ứng dụng.

office bảng chứa thông tin về Khoa Ngoại trú của các bệnh viện mà bác sĩ liên kết cũng như các phòng khám của chính họ (tức là văn phòng hoặc phòng phẫu thuật). Các cột trong bảng này là:

  • id - Khóa chính của bảng này.
  • doctor_id - Tham khảo doctor bảng và chỉ ra bác sĩ có liên quan.
  • hospital_affiliation_id – Thông báo bệnh viện nơi bác sĩ sẵn sàng cho OPD. Vì cột này có thể áp dụng cho OPD chứ không phải phòng khám, nên nó có thể bị vô hiệu hóa.
  • time_slot_per_client_in_min - Lưu trữ một lượng thời gian (tính bằng phút) được phân bổ cho các cuộc tham vấn. Số phút được nhập bởi các bác sĩ dựa trên kinh nghiệm của họ. Cột này giúp ứng dụng xác định vị trí khả dụng tiếp theo. Lưu ý rằng con số này không đảm bảo về thời lượng cuộc hẹn nhưng nó giúp giảm thiểu thời gian chờ đợi của bệnh nhân nếu họ sử dụng ứng dụng để đặt lịch hẹn.
  • first_consultation_fee - Phí bác sĩ tính cho lần khám ban đầu. Điều này có vẻ không quan trọng, nhưng nó rất quan trọng đối với chức năng tìm kiếm; phí là một tiêu chí lọc rất phổ biến.
  • followup_consultation_fee - Nhiều bác sĩ tính phí tái khám thấp hơn so với tư vấn ban đầu. Cột này lưu trữ chi phí tư vấn tiếp theo.
  • street_address - Địa chỉ của OPD bệnh viện hoặc phòng khám.
  • city , statecountry –Thành phố, tiểu bang và quốc gia nơi đặt bệnh viện hoặc phòng khám.
  • zip - Mã bưu điện nơi đặt phòng khám hoặc bệnh viện. Thông thường, mọi người tìm kiếm bác sĩ ở các khu vực lân cận bằng mã bưu điện, vì vậy trường này sẽ rất quan trọng đối với chức năng tìm kiếm của ứng dụng.

Tại sao Có một Bảng “văn phòng” riêng biệt Khi Thông tin chi tiết về OPD có thể dễ dàng được theo dõi trong Bảng “bệnh viện_ nhân viên”?

Ba lý do:

  • Một bác sĩ có thể liên kết với bệnh viện về một khía cạnh công việc của họ (tức là thực hiện phẫu thuật) nhưng không liên kết với những người khác (tức là khám bệnh nhân tự túc). Chúng tôi có thể mất các liên kết như vậy nếu chúng tôi cố gắng duy trì thông tin chi tiết về văn phòng trong hospital_affiliation chỉ bảng.
  • Nhiều bác sĩ không liên kết với bệnh viện nhưng có phòng khám hoặc văn phòng riêng. Chúng tôi cũng cần lưu trữ thông tin về những bác sĩ này.
  • Một bác sĩ có thể có nhiều văn phòng ở các địa điểm khác nhau hoặc có thể làm việc tại một số chi nhánh của bệnh viện. Nếu bác sĩ chỉ được hiển thị là được liên kết với một địa điểm bệnh viện, chúng tôi có thể mất một số thông tin. Đó là lý do chúng tôi duy trì các chi tiết địa chỉ riêng biệt.

office_doctor_availability bảng lưu trữ tình trạng sẵn có của OPD / phòng khám của bác sĩ về các khung thời gian (giả sử 2 giờ vào buổi sáng và 4 giờ vào buổi tối). Việc chia nhỏ ngày theo cách này khá phổ biến, vì vậy việc có thêm một bàn để lưu trữ các vị trí còn trống là rất hợp lý. Ngoài ra, bác sĩ có thể làm việc nhiều hơn một ca OPD. Các cột cho bảng này là:

  • id - Khóa chính của bảng.
  • office_id - Tham khảo bảng “văn phòng”.
  • day_of_week - Ngày trong tuần, tức là Thứ Hai, Thứ Ba, v.v. Điều này cho phép các bác sĩ có những thời lượng khác nhau cho các ngày khác nhau (ví dụ:cuối tuần so với ngày trong tuần).
  • start_time - Khi bác sĩ sẵn sàng cho bệnh nhân đầu tiên.
  • end_time - Khi cuộc hẹn hoặc ca làm việc cuối cùng được lên lịch kết thúc.
  • is_available - Cho phép bác sĩ đánh dấu tình trạng sẵn có của họ cho những ngày hoặc khoảng thời gian cụ thể. Cột này được khởi tạo bằng chữ ‘Y’ làm mặc định và được cập nhật thành chữ ‘N’ khi bác sĩ đánh giá là không có.
  • reason_of_unavailablity - Nhiều bác sĩ thích tiết lộ lý do tại sao họ không có mặt hoặc phải hủy cuộc hẹn. Điều này giúp xây dựng mối quan hệ minh bạch giữa bác sĩ và bệnh nhân của họ. Vì nó là tùy chọn, tôi đã giữ đây là cột có thể vô hiệu hóa.

in_network_insurance bảng lưu trữ thông tin bảo hiểm. Ở nhiều nước, các dịch vụ y tế rất tốn kém và bảo hiểm y tế là bắt buộc. Trong những trường hợp như vậy, bảng này chứa thông tin chi tiết về những công ty bảo hiểm nào được chấp nhận hoàn toàn tại bệnh viện OPD hoặc phòng khám.

Quản lý Khách hàng và Đánh giá Dữ liệu

Đối với một bệnh nhân, đăng ký ứng dụng yêu cầu rất ít thông tin. Kể từ đây, tôi sẽ sử dụng ‘client’ thay vì ‘user’ hoặc ‘BN’.

client_account bảng lưu trữ các chi tiết cơ bản cho khách hàng. Những chi tiết này được ghi lại tại thời điểm đăng ký. Các cột trong bảng này là:

  • id - Một số duy nhất được chỉ định cho mỗi khách hàng.
  • first_name - Tên của khách hàng.
  • last_name - Họ của khách hàng.
  • contact_number - Số điện thoại của khách hàng, tốt nhất là số di động, có thể gửi thông tin cuộc hẹn. Đây cũng là số để nhân viên văn phòng bác sĩ có thể liên hệ với khách hàng.
  • email - Địa chỉ email của khách hàng. Ứng dụng có thể gửi lời nhắc cuộc hẹn cho khách hàng.

client_review bảng không chỉ cung cấp phản hồi (tức là đánh giá của khách hàng) cho bác sĩ mà còn giúp khách hàng tiềm năng lựa chọn bác sĩ. Nó là một thành phần không thể thiếu của ứng dụng này. Các cột cho bảng này là:

  • id - Khóa chính của bảng này.
  • user_account_id - Cho biết người dùng nào đang gửi bài đánh giá.
  • doctor_id - Bác sĩ đang được xem xét.
  • is_review_anonymous - Nếu tên của khách hàng sẽ được công bố cùng với bài đánh giá hay không. Đây là một tính năng bảo mật dành cho khách hàng.
  • wait_time_rating - Cột số này có xếp hạng từ 1 (kém nhất) đến 10 (tốt nhất). Nó phản ánh quan điểm của khách hàng về việc họ đã đợi gặp bác sĩ trong bao lâu.
  • bedside_manner_rating –Lưu trữ ý kiến ​​của khách hàng về cách thức bên giường bệnh của bác sĩ (tức là bác sĩ có tử tế, nhân ái, giao tiếp tốt, v.v.)
  • overall_rating - Đánh giá của khách hàng về trải nghiệm chung của họ với bác sĩ.
  • review - Khách hàng có thể đưa ra phản hồi chi tiết của họ tại đây.
  • is_doctor_recommended - Cột chỉ số này cho biết liệu khách hàng có giới thiệu bác sĩ hay không.
  • review_date - Khi bài đánh giá được gửi.

Quản lý cuộc hẹn

Phần này là USP (Điểm bán hàng duy nhất) quan trọng nhất cho ứng dụng này, vì nó cho phép khách hàng kiểm tra sự sẵn có của các bác sĩ khác nhau và đặt lịch hẹn.

appointment bảng giữ chi tiết cuộc hẹn cho khách hàng. Các cột của nó bao gồm:

  • id - Một số duy nhất được chỉ định cho mỗi cuộc hẹn. Con số này được tham khảo ở nơi khác.
  • user_account_id - Khách hàng nào đang đặt lịch hẹn.
  • office_id - Thông báo cho bác sĩ nào và bệnh viện nào OPD hoặc phòng khám có liên quan đến cuộc hẹn.
  • probable_start_time - Đây là cột dấu thời gian chứa thời gian bắt đầu cuộc hẹn có thể xảy ra. Thời gian bắt đầu các cuộc hẹn khám bệnh thường có thể xảy ra thay vì tuyệt đối.
  • actual_end_time - Thời gian thực tế kết thúc cuộc tư vấn. Ban đầu, cột này để trống, vì nhiều yếu tố có thể ảnh hưởng khi cuộc hẹn kết thúc. Do đó, đây là cột có thể vô hiệu hóa.
  • appointment_status_id - Điều này được tham chiếu từ appointment_status và nó biểu thị trạng thái hiện tại của cuộc hẹn. Các giá trị có thể có cho trạng thái là “hoạt động”, “đã hủy” và “hoàn tất”. Ban đầu trạng thái sẽ là "hoạt động". Nó sẽ trở nên "hoàn tất" sau khi cuộc hẹn được thực hiện. Nó sẽ bị "hủy" nếu khách hàng hủy cuộc hẹn của họ.
  • appointment_taken_date - Ngày mà cuộc hẹn được thực hiện.
  • app_booking_channel_id - Kênh mà một cuộc hẹn đã được đặt trước. Có nhiều kênh để thực hiện cuộc hẹn:thông qua ứng dụng, gọi điện đến bệnh viện, gọi cho bác sĩ hoặc văn phòng của họ, v.v.

Xem Mô hình Dữ liệu Hoàn chỉnh




Chức năng tìm kiếm đang hoạt động

Hãy tìm kiếm bác sĩ nhãn khoa theo mã ZIP 63101. Kết quả tìm kiếm phải được sắp xếp theo các tiêu chí sau:

  • Nhiều kinh nghiệm nhất
  • Xếp hạng đề xuất của khách hàng cao nhất
  • Phí tư vấn ban đầu thấp nhất

Đây là mã:

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;

Bạn sẽ thêm gì?

Những gì khác có thể được thêm vào ứng dụng này và mô hình dữ liệu này? Chia sẻ quan điểm của bạn trong các bình luận.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Bất ngờ về hiệu suất và giả định:BẬT SỐ KHOẢN

  2. Kế hoạch khai thác:Không chỉ dành cho bộ nhớ cache của kế hoạch

  3. Ngôn ngữ Định nghĩa Dữ liệu SQL

  4. Toán tử SQL không bằng (! =) Cho người mới bắt đầu

  5. Khi khẩn cấp của nó