1 Revision History

版次 負責人 日期 變更項目敘述 審查者 審查日期
0.1 盧子文 2024/05/27 建立SRS文件架構 全體組員 2024/06/01
1.0 盧子文 2024/06/07 建立Use Case Diaagram 全體組員 2024/06/15

2 Introduction 簡介

2.1 Document Purpose 系統目的

本系統旨在利用 R Shiny 開發一個安全的電子病歷 (EMR) 系統，以數位化方式儲存、管理病患醫療紀錄，並提供不同角色的使用者 (管理員、醫師、主管) 相應的功能。所有資料將儲存於 MongoDB 雲端資料庫，系統則託管於 shinyapps.io。

2.2 Product Scope 系統範圍

本系統包含以下主要功能模組： - 登入模組：提供不同角色(包含系統管理者、醫師、主管)登入功能。 - 使用者帳號管理模組 (包含新增、刪除、修改、查詢)：提供系統管理員管理使用者的登入帳號，包含新增、編輯和刪除帳號。 - 病歷查詢模組：提供系統管理員、醫師查詢病人的病歷記錄。 - 病歷新增模組：提供系統管理員、醫師新增病人的記錄。 - 統計報表模組：提供系統管理員、主管依據不同條件篩選資料、產生統計報表，並提供匯出CSV格式報表下載的功能。

2.3 目標使用者

  • 系統管理員： 負責系統帳號管理、病歷資料的新增與查詢、統計報表的檢視與匯出。
  • 醫師： 負責病歷資料的新增與查詢。
  • 主管： 負責統計報表的檢視與匯出。

圖 1: 系統架構圖

2.4 Definitions, Acronyms and Abbreviations 定義與縮寫

  • EMR: Electronic Medical Record (電子病歷)
  • SRS: Software Requirements Specification (軟體需求規格書)
  • UI: User Interface (使用者介面)
  • MongoDB: 一種 NoSQL的Database (資料庫)
  • R Shiny：一個使用 R 建立互動式網頁應用程式的套件。

2.5 References 參考文獻

  • IEEE System Requirements Specification Template
  • 國立臺灣大學 101 學年度第二學期軟體工程設計課程 SRS sample

3 Product Overview

3.1 Product Perspective 產品視角

  • 電子病歷系統是一個基於R Shiny所製作的一個獨立的web 應用程式，通過瀏覽器瀏覽。使用者可以根據其角色（管理員、醫師、主管或護理師）瀏覽並執行不同的功能。
  • 程式托管與shinyapps.io的網站，程式與MongoDB Atlas雲端資料庫交互並進行資料儲存與檢索。

3.2 Product Functions 產品功能

該系統提供以下功能： - 使用者管理：管理員可以建立、修改和刪除使用者帳號，並為其分配角色（管理員、醫師、主管）。 - 病歷管理：授權使用者可以建立、檢視、更新和刪除患者病歷。系統自動記錄新增記錄所需的時間。 - 報表系統：管理員和主管可以根據各種條件（例如科室、疾病、時間段、醫師）生成報告。報告可以涵蓋單個日期或日期範圍，並包括患者就診次數、疾病分佈、治療、住院時間和 APACHE II 評分等統計資料。報告可以 Excel（.csv）格式匯出。

3.3 Product Constraints 產品限制

  • Web端的病歷功能新增病歷之後，沒有刪除與編輯的功能，需要直接由後台資料庫管理來做刪除與編輯。
  • 使用者角色還缺乏護理師、物理治療師、呼吸治療師、藥師、營養師等其他職類。

3.4 User Characteristics 使用者類別和特徵

  • 管理員：具有最高權限，負責系統維護、管理所有使用者帳號、查詢病歷、新增病歷、查詢統計資料和報告。
  • 醫師：可以查詢病歷和新增病歷記錄。
  • 主管：可以查看病人的統計資料和報告。

3.5 操作環境

  • 客戶端：
    • 作業系統：Windows, MacOS, Linux
    • 網頁瀏覽器：Chrome, Firefox, Safari 等 (或同等產品)
  • 伺服器端：
    • 具有 Shiny 套件的 R（托管在 shinyapps.io 上）
    • MongoDB Atlas (雲端資料庫)

3.6 設計和實施限制

系統必須託管在 shinyapps.io 上。 系統必須使用 MongoDB Atlas 作為雲端資料庫。 敏感的患者資料（例如身份證號碼）必須加密。 系統必須遵守相關的醫療保健資料隱私法規（例如，如果適用，HIPAA）。

3.7 Assumptions and Dependencies 假設和依賴性

  • 使用者可以使用現代網路瀏覽器並具有可靠的網際網路連接。
  • shinyapps.io 託管環境和 MongoDB Atlas 資料庫服務將保持足夠的正常運行時間和性能。

4 Requirements 需求

4.1 Functional Requirements 功能性需求

####Front-end Functional Requirements ##### User Login Module使用者登入模組 - 使用者可輸入帳號與密碼，並根據帳號所在的不同組群，登入系統。

#####Users Management Module使用者帳號管理模組 - 系統管理員可查看所有帳號清單、建立新的使用者帳號(user_id)與修改暨存的使用使用者名稱(user_name)、密碼和組群(user_group)。

4.1.0.1 Medical Records Query Module 病歷查詢模組
  • 系統管理員、醫師輸入病人的病歷號碼或輸入主治醫師，及選擇查詢日期時間，可以查詢病人的病歷記錄。
  • 病歷記錄以互動式表格呈現，呈現病人的床號、姓名、病歷號、診斷、住院日數。
4.1.0.2 Medical Records Query Module病歷新增模組
  • 系統管理員、醫師可查詢全部病人清單，清單以互動式表格呈現。
  • 系統管理員、醫師可新增病人資料，資料分別輸入姓名、病歷號碼、性別、年齡、床號、診斷、APACHE_II_score，並選擇轉入日期時間與轉出日期時間，按下儲存之後可以繼續新增下一筆資料。
4.1.0.3 Statistical Reporting Module 統計報表模組
  • 系統管理員、主管科查詢統計資料。
  • 模組可切換單一日期或者日期區間作為統計的時間，並同時可選擇不同的統計指標，包含描述性統計指標、依嚴重程度分組、依醫師分類、住院病人總覽。

4.1.1 Back-end Functional Requirements

4.1.1.1 User Login Module使用者登入模組
  • 連線至 Mongodb資料庫的user資料庫，檢查輸入的使用者帳號密碼符不符合。
  • 密碼使用 SHA-256 和 bcrypt 雜湊演算加密。
4.1.1.2 Users Management Module使用者帳號管理模組
  • 查詢清單時，連線至Mongodb資料庫的user資料庫，並顯示所有結果。
  • 可以針對不同的使用者編輯帳號(id)、名稱(name)、密碼(passward)、組群(group)等。
4.1.1.3 Medical Records Query Module病歷新增模組
  • 連線至 Mongodb資料庫的patient資料庫，查詢所有結果並顯示與畫面。
  • 把前端輸入的資料，包含姓名、病歷號碼、性別、年齡、床號、診斷、APACHE_II_score、轉入日期時間、轉出日期時間，並記錄輸入的時間，儲存至patient成一筆新的資料。
  • 儲存資料後，自動清空輸入格，準備輸入下一筆資料。
4.1.1.4 Statistical Reporting Module 統計報表模組
  • 選擇日期可切換單一日期或日期區間。
  • 指標可選擇不同的統計指標，包含描述性統計指標、依嚴重程度分組、依醫師分類、住院病人總覽。
  • 統計指標：分別計算今日總病人數、今日入院人數、今日出院人數、占床率、三班病人數(白班、小夜、大夜)，並提供匯出下載CSV檔。
  • 依嚴重程度分組：根據APACHE_II_score的分數，小於15為輕度，15-34為中度，大於34為重度來分組，依據分組的結果排序並以表格呈現分組、姓名、診斷、住院日數，並提供匯出下載CSV檔。
  • 依醫師分類：依主治醫師排序，並以表格呈現主治醫師、平均嚴重度、人數、平均住院日數，平均值取至小數下2位數，並提供匯出下載CSV檔。
  • 住院病人總覽：完整呈現單一日期或日期區間的所有病人表格。表格呈現姓名、病歷號碼、性別、年齡、床號、診斷、APACHE_II_score、轉入日期時間、轉出日期時間、住院日數，並提供匯出下載CSV檔。
  • 住院日數以選定日期與入院日期之差計算，或是在日期區間中，以轉出日期與入院日期之差計算。

4.2 Non-functional Requirements 非功能性需求

4.2.1 Security 安全性

  • 敏感的患者資料應在 MongoDB 資料庫中加密。
  • 對患者資料的存取應根據使用者角色進行嚴格控制。
  • 系統應記錄使用者對患者記錄的存取和修改。
  • 密碼應使用 SHA-256 和 bcrypt 加鹽進行雜湊處理。
  • shinyapps.io 和使用者之間的資料傳輸應通過 HTTPS 進行保護。

4.2.2 Usability 使用性

  • 使用者介面應直觀且易於瀏覽。
  • 工作流程應設計為最大程度地減少使用者工作量和學習曲線。

4.2.3 Performance 性能

  • 系統應及時回應使用者操作。
  • 系統應有效處理大量患者資料。

4.2.4 Reliability 可靠性

  • 系統應包括強大的錯誤處理，以防止資料丟失或損壞。
  • MongoDB 資料庫中的患者資料應定期備份並具有還原選項。

4.3 External Interface Requirements 外部介面需求

4.3.1 User Interfaces 使用者介面

  • 系統應提供可透過現代 Web 瀏覽器存取的基於 Web 的使用者介面。

4.3.2 Hardware Interfaces 硬體介面

  • 該系統應與用於存取 Web 應用程式的標準電腦硬體相容。

4.3.3 Software Interfaces 軟體介面

  • 系統將使用 MongoDB 作為數據庫，並使用 Shiny 和 ShinyDashboard 作為前端框架。

5 Database Design 資料庫設計

5.1 資料庫概述

  • 系統將使用 MongoDB 作為數據庫，存儲用戶信息、病歷信息和記錄信息。

5.2 資料庫表單設計

  • 使用者表單 (user)
  • _id: primary key
    • user_id: string
    • user_name: string
    • user_password: string
    • user_group: string
    • user_salt: string
  • 病歷記錄表單(patient)
    • _id: primary key
    • 姓名: string
    • 病歷號: string
    • 性別: string
    • 年齡: integer
    • 床號: integer
    • 轉入日期時間: datetime
    • APACHE_II_score: integer
    • 主治醫師: string
    • 診斷: string
    • 轉出日期: datetime

6 Use Case Diagram

6.1 活動圖 (Activity Diagram)

圖 2-1: 登入功能的活動圖

圖 2-2: 管理帳號的活動圖

圖 2-3: 查詢病歷的活動圖

圖 2-4: 新增病歷記錄功能的活動圖

圖 2-5: 查看統計數據功能的活動圖

6.2 類別圖 (Class Diagram)

圖 3: 類別圖

6.3 狀態圖 (State Diagram)

圖 4-1: 系統登入狀態圖 (Login State Diagram)

圖 4-2: 帳號管理狀態圖 (Account Management State Diagram)

圖 4-3: 病歷查詢狀態圖 (Patient Query State Diagram)

圖 4-4: 病歷新增狀態圖 (Add Medical Record State Diagram)

圖 4-5: 統計輸出狀態圖 (Statistics State Diagram)