症狀檢查後端
症狀檢查應用程式後端模板
指導性評估調查、分診結果和決策樹評估
一個生產就緒的 症狀檢查後端 在 Back4app，擁有評估調查、臨床邏輯樹、分診結果、用戶檔案和審計記錄。包括 ER 圖、數據詞典、JSON 架構、API 遊樂場，還有一個 AI Agent 提示以便快速啟動。
關鍵要點
這個模板提供一個症狀檢查後端，包括調查、決策樹、結果、用戶和審計模型，使您的團隊能專注於臨床內容和用戶體驗。
- 主觀收集模型 — 跟踪調查定義、問題變體和用戶回應，以可靠地重建收集會話。
- 臨床邏輯節點 — 將決策樹表示為鏈接的DecisionNode記錄，以便評估邏輯與客戶端代碼解耦。
- 篩選結果 — 存儲確定性的篩選結果（建議、緊急程度、建議的下一步）以供後續分析和路由。
- 審計與可解釋性 — 捕捉決策路徑和用戶輸入，以便結果對臨床醫生和合規性審查可進行審計和解釋。
- 跨平台API — REST和GraphQL端點為移動和網絡客戶端提供一致的攝取和分診合同。
症狀檢查應用後端範本是什麼？
Back4app是一種後端即服務（BaaS），可快速交付產品。症狀檢查應用後端範本是一個為調查、決策節點、調查回應、分診結果、用戶配置文件和審計條目的預構建架構。連接您喜歡的前端（React、Flutter、Next.js等）並加快交付。
最佳用於：
面向患者的症狀分診臨床決策支持原型遠程健康接收工作流程診所內部分診工具數位分診產品的最小可行產品（MVP）使用 BaaS 的團隊以處理受規範內容
概覽
一個可靠的症狀檢查器需要結構化的接收數據、明確的決策邏輯和可審核的結果，以支持分診和分析。
此模板定義了調查、決策節點、用戶檔案、調查回應、分診結果和審計條目，並具備合理的擁有權和驗證規則，以支持臨床接收工作流程。
核心症狀檢查功能
此中心中的每張技術卡都使用相同的症狀檢查後端架構，包括調查、DecisionNode、UserProfile、SurveyResponse、TriageOutcome 和 AuditEntry.
調查定義和版本管理
調查類型存儲標題、版本、起始節點和元數據，以便編寫引導式入境流程。
決策節點樹
決策節點模型問題、分支邏輯、條件表達式和指向後續節點的指針。
調查回應追踪
調查回應儲存用戶答案、時間戳和通過決策樹評估的路徑。
分流結果記錄
分流結果捕捉評估的級別（自我護理、緊急、急診）、建議文字和推薦的後續步驟。
用戶資料管理
用戶資料將Back4app用戶帳戶鏈接到在分流過程中使用的人口統計和臨床元數據。
可解釋的審核條目
AuditEntry 記錄每次關鍵評估和結果的演員、動作、上下文和有效負載。
為什麼要使用 Back4app 構建您的症狀檢查後端？
Back4app 提供受管理的構建 Bloc ks，用於 intake、決策邏輯和分流，讓您的團隊可以專注於臨床內容、用戶體驗和整合。
- •調查和內容管理: 編寫調查並為其版本化，以便 intake 流程可以發展，同時保留早期會話以供審查。
- •確定性臨床邏輯: 將決策節點作為數據存儲，以便規則可以被審計、測試和編輯，而無需為客戶應用程序發布新版本。
- •靈活的 API + 審計: 使用 REST 和 GraphQL 進行客戶訪問並記錄詳細的審計條目，以捕獲輸入和決策路徑以便解釋。
快速組合、測試和部署症狀分流流程，使用支持多個前端的受管理後端合同。
核心優勢
一個症狀分流後端，幫助您快速迭代，同時保持決策邏輯可審核和以內容為驅動。
快速內容迭代
編寫和版本調查及決策節點，而無需為每次內容更改發佈客戶端版本。
可解釋的結果
保留決策路徑和輸入，以便臨床醫生和審計員能重建為什麼發出特定的分流建議。
一致的分流結果
使用確定性規則評估來確保相同的輸入在不同平台上產生可重複的結果。
授權內容編輯
控制誰可以根據角色的ACL和雲代碼檢查編寫或發布調查內容。
分析準備數據
捕獲結構化的回應和結果，以便產品和臨床團隊可以分析使用情況和安全信號。
AI輔助的啟動工作流程
快速填充調查、節點和範例分流結果，使用現成的AI代理提示。
準備好啟動你的症狀分類平台了嗎？
讓 Back4app AI 代理幫你搭建症狀檢查器後端，並從一個提示生成調查、決策節點、回應、結果和審核日誌。
免費開始 — 每月 50 次 AI 代理提示，無需信用卡
技術棧
此症狀檢查器後端模板中包含的一切。
前端
13+ 種技術
後端
Back4app
資料庫
MongoDB
身份驗證
內建身份驗證 + 會話
API
REST 和 GraphQL
實時
Live Queries
ER 圖
症狀檢查器後端架構的實體關係模型。
common.erDiagramPlaceholder
涵蓋調查、決策節點、用戶檔案、回應、分診結果和審計條目的架構。
檢視圖表來源
Mermaid
erDiagram
SymptomSurvey ||--o{ DecisionNode : "contains"
DecisionNode ||--o{ DecisionNode : "branches to"
DecisionNode }|..|{ Advice : "recommends"
PatientProfile ||--o{ Encounter : "starts"
SymptomSurvey ||--o{ Encounter : "used in"
Advice ||--o{ Encounter : "applies to"
SymptomSurvey {
String objectId PK
String title
String description
String version
Boolean isActive
Array nodes FK
Date createdAt
Date updatedAt
}
DecisionNode {
String objectId PK
String questionText
Array options FK
Object nextMap
Boolean isTerminal
Pointer advice FK
Date createdAt
Date updatedAt
}
Advice {
String objectId PK
String title
String description
String urgency
String followUp
Date createdAt
Date updatedAt
}
PatientProfile {
String objectId PK
Pointer user FK
String fullName
Date birthDate
String sex
String contact
Array medicalHistory FK
Date createdAt
Date updatedAt
}
Encounter {
String objectId PK
Pointer patient FK
Pointer survey FK
Object responses
Array decisionPath FK
Pointer recommendedAdvice FK
Number riskScore
String status
Date createdAt
Date updatedAt
}
AuditLog {
String objectId PK
Pointer actor FK
String entityType
String entityId
String action
String summary
Object metadata
Date createdAt
Date updatedAt
}
整合流程
身份驗證、指南式篩選、決策評估和分診持續性的典型執行流程。
common.erDiagramPlaceholder
查看圖示源
Mermaid
sequenceDiagram
participant User
participant App as Symptom Checker App
participant Back4app as Back4app Cloud
User->>App: Open app and Login
App->>Back4app: POST /login
Back4app-->>App: Session token and patient context
User->>App: Request active triage surveys
App->>Back4app: GET /classes/SymptomSurvey?where={"isActive":true}
Back4app-->>App: List of SymptomSurvey
User->>App: Start survey "Respiratory Triage"
App->>Back4app: POST /classes/Encounter (patient, survey, status: in_progress)
Back4app-->>App: Encounter objectId
User->>App: Answer node Q1 -> "Yes"
App->>Back4app: PUT /classes/Encounter/{id} (append responses, decisionPath)
Back4app-->>App: Updated Encounter
User->>App: Complete survey
App->>Back4app: PUT /classes/Encounter/{id} (status: completed) + POST /classes/AuditLog
Back4app-->>App: Encounter with recommendedAdvice (pointer) and riskScore
Back4app-->>App: LiveQuery event if urgency == high (real-time escalation)
App-->>User: Show advice and escalation instructions數據字典
症狀檢查器架構中每個類別的完整字段級參考。
| 字段 | 類型 | 描述 | 是否必需 |
|---|---|---|---|
| objectId | String | Auto-generated unique identifier | 自動 |
| title | String | Survey display title (e.g. Respiratory Triage) | |
| description | String | Short description or purpose of the survey | — |
| version | String | Semantic version for survey logic | |
| isActive | Boolean | Whether this survey is available to users | |
| nodes | Array<Pointer<DecisionNode>> | Ordered decision nodes that make the clinical tree | — |
| createdAt | Date | Auto-generated creation timestamp | 自動 |
| updatedAt | Date | Auto-generated last-update timestamp | 自動 |
8 欄位在 SymptomSurvey
安全性和權限
ACL 和 CLP 策略如何保護調查內容、決策邏輯和敏感回應數據。
基於角色的內容控制
僅允許臨床作者和管理員創建或發布調查和 DecisionNode 物件；查看者僅能查看已發布的版本。
受保護的用戶數據
SurveyResponse 和 UserProfile 記錄需要許可，因此用戶和臨床醫生僅可訪問授權的記錄；對於敏感數據，按需使用加密欄位。
僅附加審計
AuditEntry 寫入被限制在可信的後台流程中，以保留可追溯性並防止對歷史決策日誌的篡改。
模式 (JSON)
原始 JSON 模式定義已準備好可複製到 Back4app 或用作實現參考。
JSON
{
"classes": [
{
"className": "SymptomSurvey",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"title": {
"type": "String",
"required": true
},
"description": {
"type": "String",
"required": false
},
"version": {
"type": "String",
"required": true
},
"isActive": {
"type": "Boolean",
"required": true
},
"nodes": {
"type": "Array<Pointer>",
"required": false,
"targetClass": "DecisionNode"
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "DecisionNode",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"questionText": {
"type": "String",
"required": true
},
"options": {
"type": "Array",
"required": true
},
"nextMap": {
"type": "Object",
"required": false
},
"isTerminal": {
"type": "Boolean",
"required": true
},
"recommendedAdvice": {
"type": "Pointer",
"required": false,
"targetClass": "Advice"
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "Advice",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"title": {
"type": "String",
"required": true
},
"description": {
"type": "String",
"required": true
},
"urgency": {
"type": "String",
"required": true
},
"followUp": {
"type": "String",
"required": false
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "PatientProfile",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"user": {
"type": "Pointer",
"required": false,
"targetClass": "_User"
},
"fullName": {
"type": "String",
"required": false
},
"birthDate": {
"type": "Date",
"required": false
},
"sex": {
"type": "String",
"required": false
},
"contact": {
"type": "String",
"required": false
},
"medicalHistory": {
"type": "Array",
"required": false
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "Encounter",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"patient": {
"type": "Pointer",
"required": true,
"targetClass": "PatientProfile"
},
"survey": {
"type": "Pointer",
"required": true,
"targetClass": "SymptomSurvey"
},
"responses": {
"type": "Object",
"required": true
},
"decisionPath": {
"type": "Array<Pointer>",
"required": false,
"targetClass": "DecisionNode"
},
"recommendedAdvice": {
"type": "Pointer",
"required": false,
"targetClass": "Advice"
},
"riskScore": {
"type": "Number",
"required": false
},
"status": {
"type": "String",
"required": true
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
},
{
"className": "AuditLog",
"fields": {
"objectId": {
"type": "String",
"required": false
},
"actor": {
"type": "Pointer",
"required": false,
"targetClass": "_User"
},
"entityType": {
"type": "String",
"required": true
},
"entityId": {
"type": "String",
"required": true
},
"action": {
"type": "String",
"required": true
},
"summary": {
"type": "String",
"required": true
},
"metadata": {
"type": "Object",
"required": false
},
"createdAt": {
"type": "Date",
"required": false
},
"updatedAt": {
"type": "Date",
"required": false
}
}
}
]
}使用 AI 代理構建
使用 Back4app AI 代理從此模板生成症狀檢查應用程序，包括調查框架、決策樹、分流結果和 {tech} 的前端集成。
Back4app AI 代理
準備構建
在 Back4app 上使用這個確切的模式和行為創建一個症狀檢查後端。
模式:
1. 調查: 標題 (字串，必填)，版本 (字串，必填)，startNode (指向 DecisionNode 的指針，必填)，metadata (物件，選填)。
2. DecisionNode: 問題 (字串，必填)，inputType (字串: 單選、多選、數值、文本)，條件 (條件物件數組)，nextNode (指向 DecisionNode 的指針，選填)，outcome (指向 TriageOutcome 的指針，選填)，ruleType (字串: 確定性、可編寫腳本)。
3. UserProfile: 用戶 (指向 User 的指針，必填)，年齡範圍 (字串，選填)，慢性標誌 (數組，選填)，已給予同意 (布林，必填)。
4. SurveyResponse: 調查 (指向 Survey 的指針，必填)，用戶 (指向 User 的指針，選填)，答案 (物件: 以 nodeId 鍵控)，路徑 (DecisionNode 指針數組)，開始於 (日期)，完成於 (日期，選填)。
5. TriageOutcome: 回應 (指向 SurveyResponse 的指針，必填)，級別 (字串: 自我護理、初級護理、緊急、急診)，建議文本 (字串)，建議行動 (字串)，創建於 (系統)。
6. AuditEntry: 行為者 (指向 User 的指針，必填)，行動 (字串，必填)，上下文 (物件)，有效載荷 (物件，選填)。
安全性:
- 使用 ACL/CLP 限制調查創建以及保護 SurveyResponse 數據。非管理員的 AuditEntry 寫入應為追加式。
認證:
- 用戶和臨床醫生的註冊、登錄、登出；創作者和審查者的基於角色的權限。
行為:
- 獲取已發布的調查及 DecisionNode 樹，逐步評估節點，使用決策路徑持久化 SurveyResponse，計算或記錄 TriageOutcome，並為每次完成的評估創建 AuditEntry 記錄。
交付:
- 帶有模式、ACL、CLP 的 Back4app 應用程序；起始調查和決策節點； {tech} 的前端集成指南；API 遊樂場示例。按下面的按鈕打開代理，該模板提示已預填。
這是沒有技術後綴的基本提示。您可以在後面調整生成的前端堆疊。
幾分鐘內部署每月50個免費提示無需信用卡
API遊樂場
嘗試對症狀檢查器模式使用REST和GraphQL端點。響應使用模擬數據並且不需要Back4app帳戶。
common.loadingPlayground
使用與此模板相同的模式。
選擇您的技術
展開每個卡片以查看整合步驟、狀態模式、數據模型示例和離線註釋。
Flutter 症狀檢查器後端
React 症狀檢查器後端
React 原生 症狀檢查器後端
Next.js 症狀檢查器後端
JavaScript 症狀檢查器後端
Android 症狀檢查器後端
iOS 症狀檢查器後端
Vue 症狀檢查器後端
Angular 症狀檢查器後端
GraphQL 症狀檢查器後端
REST API 症狀檢查器後端
PHP 症狀檢查器後端
.NET 症狀檢查器後端
您可以獲得的每項技術
每個技術棧使用相同的症狀檢查後端架構和 API 合約。
統一的症狀檢查器數據結構
為症狀檢查器量身定制的調查和用戶檔案的凝聚架構。
即時的分診結果
對用戶症狀的即時反饋，為症狀檢查器提供動態決策節點。
安全的用戶數據管理
強大的訪問控制確保症狀檢查器用戶信息的機密性。
REST/GraphQL API訪問
通過靈活的API輕鬆與前端框架集成，為症狀檢查器。
可自定義的調查體驗
量身定制調查以滿足症狀檢查器用戶的特定需求以提高參與度。
分析和報告工具
從症狀檢查器應用程式中的用戶互動和結果中獲取見解。
症狀檢查器框架比較
比較所有支持的技術的設置速度、SDK風格和AI支持。
| 框架 | 設置時間 | 症狀檢查器的好處 | SDK 類型 | AI 支援 |
|---|---|---|---|---|
| 不到5分鐘 | 移動和網絡上的症狀檢查器單一代碼庫。 | Typed SDK | 全部 | |
| ~3–7分鐘 | 快速的症狀檢查器網頁儀表板。 | Typed SDK | 全部 | |
| 快速（5分鐘）設置 | 跨平台的症狀檢查器移動應用程式。 | Typed SDK | 全部 | |
| ~5分鐘 | 症狀檢查器的伺服器渲染網頁應用程式。 | Typed SDK | 全部 | |
| ~3–5分鐘 | 症狀檢查器的輕量級網頁整合。 | Typed SDK | 全部 | |
| 不到5分鐘 | 原生Android應用程式的症狀檢查器。 | Typed SDK | 全部 | |
| ~3–7分鐘 | 原生iOS應用程式的症狀檢查器。 | Typed SDK | 全部 | |
| 快速（5分鐘）設置 | React的網頁UI症狀檢查器。 | Typed SDK | 全部 | |
| ~5分鐘 | 企業網頁應用程式的症狀檢查器。 | Typed SDK | 全部 | |
| 不到2分鐘 | 靈活的GraphQL API症狀檢查器。 | GraphQL API | 全部 | |
| 快速（2分鐘）設置 | REST API的症狀檢查器整合。 | REST API | 全部 | |
| ~3分鐘 | 伺服器端PHP後端的症狀檢查器。 | REST API | 全部 | |
| 快速（5分鐘）設置 | .NET的症狀檢查器後端。 | Typed SDK | 全部 |
設置時間反映從項目啟動到使用此模板架構進行首次調查和決策評估的預期持續時間。
常見問題
有關使用此模板構建症狀檢查器後端的常見問題。
什麼是症狀檢查器後端？
這個模板包含什麼？
為什麼使用 Back4app 作為症狀分診應用程式？
我如何收集和重播放調查會話？
我如何在評估後創建 TriageOutcome？
我可以在移動設備上緩存 DecisionNode 樹以便離線使用嗎？
我如何審計為何給予某項建議？
更新臨床內容的推薦方式是什麼？
我應該怎麼處理監管合規性？
我如何防止惡意規則注入？
