Mô hình dữ liệu để theo dõi tài sản quý giá nhất của bạn

Khỏe mạnh và phù hợp là một phong cách sống, không phải là mốt. Những người nhận ra giá trị của sức khỏe sẽ ưu tiên hàng đầu, lưu giữ hồ sơ về tất cả các dữ kiện liên quan đến sức khỏe của họ. Trong bài viết này, chúng tôi sẽ xem xét thiết kế của cơ sở dữ liệu đằng sau một ứng dụng sức khỏe và thể chất.

Có nhiều ứng dụng cho phép người dùng ghi lại thông tin sức khỏe và thể chất của họ. Một số ông lớn như Apple, Google và Microsoft đã tung ra các API phát triển của riêng họ dành riêng cho thị trường này. Ví dụ:Google có "Fit" và Microsoft có "HealthVault".

Trong bài viết này, tôi sẽ giải thích mô hình dữ liệu đằng sau ứng dụng hồ sơ sức khỏe. Trước tiên, hãy thảo luận chính xác những gì chúng ta mong đợi một ứng dụng như vậy sẽ làm được.

Yêu cầu của dự án đối với ứng dụng thông tin sức khỏe

Dưới đây là một số tính năng mà ứng dụng thông tin sức khỏe nên hỗ trợ:

• Người dùng có thể tạo tài khoản và lưu trữ thông tin sức khỏe cho nhiều hồ sơ, tức là một cá nhân có thể lưu trữ thông tin sức khỏe cho tất cả các thành viên trong gia đình của họ.
• Người dùng có thể ghi lại toàn bộ lịch sử sức khỏe của họ, bao gồm chủng ngừa, kết quả xét nghiệm trước đây, dị ứng và tiền sử y tế gia đình .
• Người dùng có thể lưu trữ các phép đo khác nhau về sức khỏe và thể chất, như mức đường huyết (đường huyết), huyết áp, thành phần cơ thể và kích thước bao gồm chỉ số khối cơ thể (BMI), cholesterol, chiều cao, cân nặng, sức khỏe sinh sản, v.v.
• Thông tin có thể được ghi lại bằng nhiều phương pháp và đơn vị đo lường khác nhau . Ví dụ:đường huyết có thể được đo bằng mg / dL hoặc mmol / L.
• Không có giới hạn về lượng thông tin mà người dùng có thể lưu trữ.
• Hệ thống cũng sẽ giữ các tiêu chuẩn sức khỏe được chấp nhận, chẳng hạn như huyết áp hoặc số BMI và sẽ cảnh báo người dùng nếu con số của họ nằm ngoài phạm vi "an toàn" hoặc "bình thường".
• Người dùng cũng có thể chọn thông tin (như đường huyết, chiều cao, cân nặng, v.v.) để hiển thị trên trang tổng quan cá nhân của họ. Bằng cách này, họ có thể giám sát bất cứ điều gì họ cần.

Thay vì chỉ giải thích những gì mỗi phần và bảng trong mô hình dữ liệu, hãy trả lời một số câu hỏi về nó. Chức năng của các bảng khác nhau sẽ trở nên rõ ràng khi chúng ta tiếp tục.

Trước tiên, bạn có thể xem mô hình dữ liệu hoàn chỉnh nếu muốn.

Mô hình dữ liệu

Trả lời các câu hỏi về Mô hình Dữ liệu Thông tin Y tế

Làm cách nào để Người dùng có thể Lưu trữ Thông tin Sức khỏe cho Cá nhân Tất cả Thành viên Gia đình của họ?

Đầu tiên, hãy nói về Quản lý tài khoản và hồ sơ . Điều này có thể đạt được bằng cách có hai bảng khác nhau; một (user_account ) để ghi lại chi tiết của những người đăng ký với ứng dụng và một (user_profile ) để ghi nhật ký chi tiết của tất cả các cấu hình khác nhau mà người dùng đã đăng ký tạo. Mọi người có thể tạo một số hồ sơ - ví dụ:một cho mỗi thành viên trong gia đình của họ.

Hãy xem các bảng khác nhau giúp điều này có thể thực hiện được.

user_account bảng chứa thông tin chi tiết cơ bản về người đăng ký với ứng dụng. Các cột của nó là:

• id –Một cột khóa thay thế cho bảng này xác định từng người dùng duy nhất.
• login_name - Tên hoặc ID khác mà người dùng chọn làm tên đăng nhập của họ. Một ràng buộc duy nhất phải được áp dụng cho cột này để đảm bảo rằng mọi tên đăng nhập đều khác nhau.
• enc_password - Mật khẩu tài khoản do người dùng chọn, ở dạng được mã hóa.
• cột địa chỉ - Địa chỉ cửa hàng và chi tiết liên hệ cho người dùng tại thời điểm đăng ký. Các cột này bao gồm street_address , city , state , country và zip . Vì các trường này là tùy chọn trong quá trình đăng ký nên tôi đã giữ các cột này là không thể bỏ qua.
• contact_number và email - Lưu trữ số liên lạc của người dùng (tức là số điện thoại) và địa chỉ email của họ. Các trường này cũng là một phần của quá trình đăng ký, nhưng chúng không thể bị vô hiệu hóa.
• is_active - Giữ chữ ‘Y’ hoặc ‘N’ để cho biết tài khoản hiện đang hoạt động hay không.
• account_image - Người dùng được phép tải lên hình ảnh của chính họ. Vì người dùng có thể tải lên không hoặc (tối đa) một hình ảnh cho mỗi tài khoản nên đây là cột loại BLOB có thể vô hiệu hóa.

user_profile bảng lưu trữ thông tin chi tiết của tất cả các cấu hình được tạo bởi người dùng đã đă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 hồ sơ mới.
• user_account_id - Cho biết người dùng nào đã tạo hồ sơ.
• user_profile_name - Lưu trữ tên của người trong hồ sơ. (Chúng tôi sẽ gọi người này là “người tạo hồ sơ” và người dùng tạo hồ sơ là “chủ tài khoản”.)
• relationship_id - Cho biết mối quan hệ giữa chủ tài khoản và người trong hồ sơ. Cột này đề cập đến relationship bảng, chứa tất cả các loại mối quan hệ có thể có (như bản thân , mẹ , cha , chị , anh , con trai , con gái , thú cưng , v.v.).
• email - Cột này chứa địa chỉ email của người trong hồ sơ. Báo cáo hoặc thông tin khác sẽ được chia sẻ với họ qua email này; thông tin cũng sẽ được gửi đến chủ tài khoản. Ví dụ:nếu Melissa tạo hồ sơ cho con gái Eva, thông tin của Eva sẽ được gửi đến email của Melissa và có thể tới email của Eva - xem bên dưới.
• is_report_sharing_enabled - Các báo cáo luôn được chia sẻ với chủ tài khoản, nhưng việc chia sẻ dữ liệu này với người làm hồ sơ là tùy chọn. Cột này cho biết thông tin có được chia sẻ với người trong hồ sơ hay không.
• is_active - Xác định xem một hồ sơ hiện đang hoạt động. Đây là chức năng xóa mềm trong trường hợp hồ sơ vô tình bị xóa.
• profile_image - Lưu trữ hình ảnh của hồ sơ cá nhân. Thuộc tính này là tùy chọn và do đó có thể vô hiệu hóa.

characteristic_data bảng chứa chi tiết hồ sơ cá nhân (như nhóm máu) không bao giờ thay đổi theo thời gian. Tất cả các cột trong bảng này là tự giải thích ngoại trừ fitzpatrick_skin_type , phân loại tính chất của da bắt đầu từ I (luôn cháy, không bao giờ sạm) đến VI (không bao giờ bỏng, không thay đổi về ngoại hình khi rám nắng).

Tôi đã thêm hai cột cho giới tính; biological_gender biểu thị giới tính của một người tại thời điểm sinh và current_gender biểu thị giới tính hiện tại của người trong hồ sơ. Cột thứ hai này chỉ áp dụng cho người chuyển giới và do đó tôi đã giữ nó ở chế độ vô hiệu.

Thông tin quan trọng nào có thể được lưu trữ trong hệ thống này? Nó được lưu trữ như thế nào?

Bây giờ chúng tôi đang chuyển sang Quản lý dữ liệu sức khỏe . Thành phần cơ thể, mức đường huyết và kích thước cơ thể được lưu trữ trong các bảng riêng biệt. Tuy nhiên, mọi người có thể nhập nhiều loại thông tin cùng một lúc, vì vậy chúng tôi sử dụng body_vitals_log bảng để theo dõi thông tin nào được đăng nhập vào hồ sơ và khi nào thông tin được nhập.

Tất cả các số liệu thống kê quan trọng được giữ trong các bảng sau:

• body_composition - Lưu trữ thông tin chi tiết về các tỷ lệ phần trăm thành phần cơ thể khác nhau như chất béo, khối lượng nạc, xương hoặc nước. Nó cũng giữ các giá trị BMI (chỉ số khối cơ thể) cho các cá nhân.
• blood_cholesterol - Giữ thông tin chi tiết về cholesterol như LDL, HDL, triglyceride và tổng số.
• body_dimension - Ghi lại kích thước của các vùng cơ thể khác nhau, chẳng hạn như số đo của eo hoặc ngực.
• body_weight - Lưu trữ các giá trị về trọng lượng cơ thể.
• body_height - Lưu giữ các giá trị về chiều cao của một người.
• blood_pressure - Giữ số huyết áp (tâm thu và tâm trương).
• blood_glucose - Ghi lại mức đường huyết.

Hầu hết các cột trong các bảng trên là tự giải thích, với một vài ngoại lệ. Bạn sẽ nhận thấy một số cột bổ sung như measurement_method_id , compare_to_normal_id , measurement_unit_id và measurement_context trong hầu hết các bảng này. Tôi sẽ giải thích các cột này sau.

body_vitals_log theo dõi thông tin nào được ghi vào một thời điểm nhất định cho một hồ sơ. Các cột trong bảng này là:

• user_profile_id - Hiển thị hồ sơ nào đang ghi thông tin.
• dt_created - Lưu trữ ngày và giờ khi thông tin được nhập.
• data_source_id - Biểu thị nguồn dữ liệu, chẳng hạn như sách hướng dẫn, thiết bị điện tử, v.v.
• I Ds của các số liệu thống kê quan trọng khác nhau - Tôi đã giữ cho tất cả các cột này không có giá trị, vì người dùng được phép ghi một hoặc nhiều mục cùng một lúc. Không phải tất cả người dùng đều muốn theo dõi cùng một số liệu thống kê về sức khỏe.

Làm cách nào để chúng ta có thể làm cho hệ thống hoạt động ở các khu vực khác nhau?

Một số thông tin được đo bằng các đơn vị khác nhau trong các lĩnh vực khác nhau. Ví dụ, trọng lượng cơ thể được đo bằng kilogam ở châu Á, nhưng nó được đo bằng pound ở Bắc Mỹ. Vì vậy, để làm cho điều này khả thi trong cơ sở dữ liệu của chúng tôi, chúng tôi cần một cách để theo dõi các đơn vị đo lường.

• id - Đóng vai trò là khóa chính của bảng này và là khóa mà các bảng khác tham chiếu đến.
• measurement_parameter - Biểu thị loại thông tin quan trọng (như cân nặng, chiều cao, huyết áp, v.v.) mà một đơn vị đo lường.
• unit_name - Lưu trữ tên của đơn vị. Hãy nghĩ về kilôgam và pound cho cân nặng, mg / dL và mmol / L cho đường huyết.

Làm thế nào mọi người sẽ biết nếu số của họ tốt?

Hệ thống của chúng tôi không giúp được gì nhiều trừ khi nó cảnh báo mọi người về các nguy cơ hoặc lỗ hổng về sức khỏe. Chúng tôi bật chức năng này bằng cách thêm compare_to_normal_id trong tất cả các bảng dữ liệu thông tin quan trọng.

Khi bất kỳ thông tin quan trọng mới nào được đăng nhập vào hệ thống, các bản ghi sẽ được so sánh với các giá trị điểm chuẩn tương ứng của chúng và cột này sẽ được đặt cho phù hợp.

Các giá trị có thể có cho bảng này là:

Người dùng có thể ghi lại khi thực hiện phép đo không?

Ví dụ:người dùng có thể cần cho biết thời điểm đo đường huyết - tức là trước hoặc sau bữa ăn. Hoặc họ có thể tự cân và ghi lại kết quả trước và sau khi tập. Để tạo điều kiện thuận lợi cho việc này, tôi đã thêm một cột, measurement_context , trong các bảng thông tin quan trọng có thể cần thông tin theo ngữ cảnh. Một số giá trị có thể có cho cột này được hiển thị bên dưới:

Điều gì sẽ xảy ra nếu một người bị tiểu đường và cần theo dõi mức đường huyết của họ?

Hệ thống mà tôi đang đề xuất sẽ có một bảng điều khiển có thể hiển thị các số liệu thống kê quan trọng ở định dạng đồ họa. Người dùng được phép chọn những gì họ muốn xem trên trang tổng quan hồ sơ của họ và mỗi hồ sơ có trang tổng quan riêng. Chủ tài khoản được phép xem tất cả các trang tổng quan tiểu sử mà họ đã tạo.

Tôi đã thêm một cột CHAR (1) cho mỗi thông số có thể được hiển thị trên trang tổng quan. Theo mặc định, tất cả các cột sẽ được điền bằng ‘N’ (hiển thị bị tắt) khi một cấu hình mới được tạo. Sau đó, người dùng có thể sửa đổi cấu hình trang tổng quan của họ từ một tùy chọn trong giao diện người dùng của ứng dụng.

Hệ thống này giúp mọi người khỏe mạnh như thế nào?

Nói cách khác, chúng ta đang nói về Lưu trữ dữ liệu thể dục . Bên cạnh thông tin sức khỏe, hệ thống cũng cho phép người dùng ghi lại thông tin về hoạt động thể dục và thói quen tập thể dục của họ.

activity_log bảng là bảng chính trong môn học này. Nó nắm bắt thông tin chi tiết về mọi loại hồ sơ hoạt động mà mọi người thực hiện.

Mọi hoạt động có thể được đo lường bằng một hoặc nhiều trong ba thông số sau:

• Thời gian bắt đầu và kết thúc - Các hoạt động như chơi thể thao hoặc trò chơi, xếp hàng, v.v. được tính theo thời gian bắt đầu và kết thúc. Điều này được thực hiện thông qua start_time và end_time các cột trong activity_log .
• Khoảng cách được bảo hiểm - Các hoạt động như chạy hoặc đi xe đạp được đo lường theo khoảng cách được bảo hiểm. Điều này được lưu trữ trong distance_covered cột.
• Đếm bước - Các hoạt động như đi bộ được đo bằng số bước và giá trị được lưu trữ trong steps_count cột.

Chắc hẳn bạn đang thắc mắc tại sao calories_burnt nằm trong activity_log bàn. Đúng như tên gọi của nó, cột này chứa giá trị của lượng calo mà người đó đốt cháy trong khi thực hiện một hoạt động cụ thể. Tôi sẽ giải thích cách chúng tôi có thể tính toán các giá trị này trong phần sau.

Tôi đã tạo một bảng có tên activity để giữ một danh sách tất cả các hoạt động có thể. Các cột trong bảng này là:

• id - Chỉ định một số ID duy nhất cho mỗi hoạt động.
• activity_name - Lưu trữ tên hoạt động.
• activity_multiplier - Cột này đóng vai trò quan trọng trong việc tính toán số lượng calo đốt cháy của những người theo đuổi các hoạt động.

Làm thế nào để bạn tính toán lượng calo đốt cháy cho mỗi hoạt động?

Để hiểu cách tính lượng calo đốt cháy, trước tiên chúng ta phải hiểu BMR của một người, hoặc tỷ lệ trao đổi chất cơ bản. Điều này cho chúng ta biết cơ thể đốt cháy bao nhiêu calo khi nghỉ ngơi. BMR của mỗi người phụ thuộc vào giới tính, tuổi, cân nặng và chiều cao của họ. Từ góc độ mô hình hóa dữ liệu, BMR là một thứ nguyên thay đổi chậm và do đó nó liên tục thay đổi theo thời gian. Chúng tôi sẽ lưu trữ các giá trị BMR riêng lẻ mới nhất trong user_bmr bàn.

Có nhiều phương pháp khác nhau được sử dụng để tính toán các giá trị BMR:

Phương pháp # 1:Phương pháp Harris-Benedict

BMR Nam:66 + (6,23 X cân nặng) + (12,7 X chiều cao tính bằng inch) - (6,8 X tuổi)

BMR Nữ:655 + (4,35 X cân nặng) + (4,7 X chiều cao tính bằng inch) - (4,7 X tuổi)

Phương pháp # 2:Phương pháp Katch-McArdle

BMR (Nam + Nữ):370 + (21,6 * Khối lượng nạc tính theo kg)

Lean Mass =trọng lượng tính bằng kilôgam - (trọng lượng tính bằng kilôgam *% mỡ cơ thể)

Chúng tôi có thể sử dụng BMR của một người và hệ số hoạt động được đề cập ở trên để tìm ra lượng calo mà một người đốt cháy khi thực hiện một hoạt động nhất định. Công thức là:

Lượng calo bị đốt cháy =hệ số hoạt động * BMR

Lưu ý:Cả hai phương pháp tính BMR ở trên đều sử dụng cùng một giá trị hệ số nhân cho các hoạt động. Để biết thêm thông tin, hãy xem bài viết này.

Chúng tôi có thể giữ giá trị BMR lịch sử của tiểu sử không?

Đúng. Chúng tôi có thể lưu trữ các giá trị BMR trong user_bmr_archive bàn.

Chúng tôi bắt đầu bằng cách thêm một cột, id_version , cho user_bmr bàn. Chúng tôi tiếp tục tăng giá trị này lên 1 mỗi khi giá trị BMR của một người trong tiểu sử được cập nhật.

user_bmr_archive bảng gần như là bản sao của user_bmr bàn. Sự khác biệt duy nhất là nó có dt_expired thay vì cột dt_created và dt_modified cột. dt_expired cột lưu trữ ngày phiên bản trở nên không hợp lệ, tức là khi giá trị BMR được cập nhật trong user_bmr .

Điều gì sẽ xảy ra nếu người dùng muốn lưu hồ sơ về các trường hợp chủng ngừa, tiền sử bệnh gia đình và bệnh dị ứng của họ?

Hệ thống này tận dụng các bảng sau để cung cấp cho người dùng khả năng lưu trữ thông tin sức khỏe bổ sung.

immunization bảng lưu trữ thông tin chi tiết về việc chủng ngừa mà những người làm hồ sơ đã nhận được. Sau ví dụ, bạn sẽ thấy mô tả ngắn gọn về các cột mà bảng này chứa:

Ví dụ - John Soo đã tiêm mũi thứ hai trong số ba liều vắc xin Viêm gan B. Nó được tiến hành bởi Tiến sĩ David Moore vào ngày 28 tháng 11 năm 2016. Việc chủng ngừa được thực hiện bằng cách tiêm ở tay trái. Nó được sản xuất bởi Cipla (một công ty dược phẩm).

• id - Khóa chính của bảng này
• user_profile_id - Đề cập đến user_profile_ID của John Soo
• vaccination_name - “Viêm gan B”
• dt_received - “Ngày 28 tháng 11 năm 2016”
• number_in_sequence - “02”
• body_area_id - ID của bên trái, được tham chiếu từ body_area bảng
• provider_name - “Dr. David Moore ”
• how_administered - “Thuốc tiêm” ( các giá trị có thể có khác bao gồm thuốc xịt mũi, máy tính bảng, thuốc nhỏ, xi-rô )
• manufacturer - “Cipla”

allergy bảng lưu trữ thông tin chi tiết về bất kỳ trường hợp dị ứng nào mà những người làm hồ sơ phải trải qua. Dưới đây là danh sách các cột, với các giá trị liên quan được cung cấp cho mỗi cột theo ví dụ:

Ví dụ - Alison D’Souza bị ho khi ăn sữa chua. Cô có phản ứng này lần đầu tiên khi cô 8 tuổi. Cô ấy hỏi ý kiến ​​bác sĩ Bill Smith, người kê một số loại thuốc và tư vấn một số biện pháp phòng ngừa nhất định. Tình trạng dị ứng này vẫn còn, nhưng hiện tại cường độ của nó đã thấp hơn.

• id - Khóa chính của bảng
• user_profile_id - R ưa thích user_profile_id của Alison D’Souza
• allergy_type_id - Đề cập đến ID cho loại dị ứng 'Thực phẩm' trong allergy_type bàn. (allergy_type bảng xác định các loại dị ứng khác nhau như thực phẩm, thuốc, môi trường, động vật, thực vật, v.v.)
• allergy_reaction_id - Đề cập đến ID của phản ứng dị ứng 'Ho' trong allergy_reaction bảng.
• first_observed - Ngày lần đầu tiên quan sát thấy phản ứng này, tức là khi Alison 8 tuổi.
• consulting_doctor_name - “Dr. Bill Smith ”
• treatment_brief - Mô tả ngắn gọn về các loại thuốc được kê đơn và các biện pháp phòng ngừa được khuyến nghị.
• does_treatment_cure_allergy - “Đã chữa khỏi một phần. Giảm cường độ phản ứng. ”

family_history bảng lưu trữ thông tin chi tiết về lịch sử y tế gia đình của người dùng. Một lần nữa, chúng tôi đã liệt kê các cột và loại thông tin sẽ được lưu trữ trong chúng dựa trên ví dụ sau.

Ví dụ - Lisa của mẹ của Diana bị bệnh Parkinson (một chứng rối loạn thần kinh). Cô ấy đã được điều trị, nhưng không có cải thiện rõ ràng.

• id - khóa chính của bảng
• user_profile_id - user_profile_ID của Diana từ user_profile bảng
• Relationship_id - ID ‘mẹ’ từ relationship bảng
• Relative_name - “Lisa”
• Date_of_birth - Ngày sinh của Lisa
• Date_of_death - NULL (Lisa vẫn còn sống và đang chiến đấu hết mình với bệnh tật.)
• Condition_brief - Mô tả ngắn gọn về cách thức, thời điểm và nơi tình trạng bệnh bắt đầu, tham vấn, bất kỳ biện pháp cứu trợ nào, v.v.
• Current_status - ‘Hiện tại’ (Các trạng thái có thể có khác là ‘Không liên tục’ và ‘Quá khứ’.)
• How_it_ended - KHÔNG CÓ

Bạn sẽ thêm gì vào mô hình dữ liệu này?

Hệ thống cho phép mọi người biết họ đốt cháy bao nhiêu calo trong khi theo đuổi các hoạt động khác nhau, nhưng nó không theo dõi lượng calo họ tiêu thụ hoặc mức độ bổ dưỡng của lựa chọn thực phẩm của họ. Ngoài ra, hệ thống cho phép họ ghi lại dữ liệu thể dục của mình hàng ngày, nhưng nó không cho phép họ đặt mục tiêu, lập kế hoạch và theo dõi tiến trình của mình để họ luôn có động lực.

Chúng ta có nên xem xét việc xây dựng các tính năng này vào nó không? Những thay đổi nào cần được thực hiện để thêm các tính năng này?

Hãy cho chúng tôi biết ý tưởng của bạn!