慢病管理系統的製作方法
2024-04-15 20:29:05
1.本發明涉及醫療服務技術領域，具體為慢病管理系統。
背景技術：
2.慢病管理系統(crm)針對疾病以及患者的生命周期過程管理，主要由服務對象管理、人群幹預、個體追蹤管理、效果評價等若干有機結合的功能組成，系統可以通過個案發現或人群篩查後自動建立慢病專案，對專案對象進行診療、健康教育、追蹤管理。該系統體現生物—心理—社會三個層次幹預措施數碼化和實用化，有利於達到降低病殘率、併發症、降低病死率以及提高慢病病人生活質量的慢病管理目標。
3.現有慢病管理系統，
4.1、多偏向單一的病種管理，缺乏多科室常見慢病病種管理；
5.2、患者信息來源入口窄,沒有形成醫院線下線上的場景閉環；
6.3、缺少以家庭為單位的建檔、病史早篩和預防。
7.因此，設計實用性強的慢病管理系統是很有必要的。
技術實現要素：
8.本發明的目的在於提供慢病管理系統，以解決上述背景技術中提出的問題。
9.為了解決上述技術問題，本發明提供如下技術方案：
10.慢病管理系統，包括總服務中心，所述總服務中心內置應用伺服器、業務服務中心與存儲單元，所述應用伺服器採用負載均衡進行任務分發，所述業務服務中心基於消息隊列方式調用任務，所述應用伺服器設置geteway網關與搜尋引擎，所述搜尋引擎採用elasticsearch，所述存儲單元的數據存儲採用mysql、mongodb、oss；
11.所述消息隊列採用rocketmq，由producer、broker、consumer三部分組成，所述producer負責生產消息，所述consumer負責消費消息，所述broker負責存儲消息，所述broker在部署過程中與應用伺服器一一對應，每個broker可以存儲多個topic的消息，每個topic的消息劃分為若干片，且每片獨立存儲於broker內，每個topic內的消息地址轉化為物理地址冗餘存儲於多個messagequeue內。
12.根據上述技術方案，所述隊列信息的調用過程中採用redis緩存，所述redis緩存保持數據的持久化，並將內存中的數據保存在磁碟中，重啟的時候可以再次加載進行使用，支持多格式結構數據存儲與數據備份，
13.根據上述技術方案，所述負載均衡採用slb負載均衡方式，其是一種對流量進行按需分發的服務，通過將流量分發到不同的後端伺服器來擴展應用系統的吞吐能力，並且可以消除系統中的單點故障，提升應用系統的可用性，可支撐多協議支持、多層次容災、更安全可靠、超強性能保障、靈活的調度策略。
14.根據上述技術方案，所述總服務中心設置動態配重服務、服務發現及管理、動態dns服務：
15.動態配重服務：當配重項需要更新時，通過管理系統進行操作的過程；
16.服務發現及管理：基於微服務集群構建管理系統系統，該系統對任一集群提供服務時該群內ip列表進行管理，並對提供服務的集群內的無法工作的ip進行去除，剩餘集群對提供服務集群基於剩餘可用的ip進行消費；
17.動態dns服務：基於nacos充當這個dns域名伺服器的角色，通過控制臺對新增域名進行配置，同時進行域名的權重分配、健康檢查與屬性分辨，
18.根據上述技術方案，所述geteway網關為客戶端與應用伺服器之間的中間層，提供路由請求、鑑權、監控、緩存、限流非業務處理功能；
19.基於非業務處理功能，合併客戶端的多服務進行合併，避免跨越請求，以及避免帶來的多個獨立認證需求，易以重構。
20.根據上述技術方案，所述業務服務中心，採用了feign調用服務，所述feign調用服務底層通過jdk的java.net.httpurlconnection實現了feign.client接口類，在每次發送請求的時候，都會創建新的httpurlconnection連結，具體步驟如下：
21.s100：通過拓展該接口，使用apachehttpclient或者okhttp3等基於連接池的高性能http客戶端；
22.s101：基於面向接口的動態代理方式生成實現類；
23.s102：根據contract協議規則，解析接口類的註解信息，解析成內部表現；
24.s103：基於requestbean，動態生成request，根據傳入的bean對象和註解信息，從中提取出相應的值，來構造httprequest對象；
25.s104：使用encoder將bean轉換成http報文正文；
26.s105：攔截器負責對請求和返回進行裝飾處理；
27.s106：基於重試器發送http請求，內置了一個重試器，當http請求出現io異常時，feign會有一個最大嘗試次數發送請求。
28.根據上述技術方案，所述rocketmq內組成的具體包括如下：
29.message：消息系統所傳輸信息的物理載體，生產和消費數據的最小單位，每條消息必須屬於一個主題，rocketmq中每個消息擁有唯一的messageid，且可以攜帶具有業務標識的key，系統具有通過messageid和key查詢消息的功能；
30.tag：為消息設置的標誌，用於同一主題下區分不同類型的消息，來自同一業務單元的消息，可以根據不同業務目的在同一主題下設置不同標籤，標籤能夠有效地保持代碼的清晰度和連貫性，並優化rocketmq提供的查詢系統，消費者可以根據tag實現對不同子主題的不同消費邏輯，實現更好的擴展性。
31.producer：負責生產消息，由業務系統負責生產消息，一個消息生產者會把業務應用系統裡產生的消息發送到broker伺服器，rocketmq提供同步發送、異步發送、順序發送與單向發送，同步發送與異步發送需要broker返回確認信息，單向發送不需要broker返回確認信息；
32.consumer：負責消費消息，是後臺系統負責異步消費，一個消息消費者會從broker伺服器拉取消息、並將其提供給應用程式，從用戶應用的角度而言提供了兩種消費形式：拉取式消費、推動式消費：
33.topic：表示一類消息的集合，每個主題包含若干條消息，每條消息只能屬於一個
主題，是rocketmq進行消息訂閱的基本單位；
34.brokerserver：代理伺服器消息中轉角色，負責存儲消息、轉發消息，代理伺服器在rocketmq系統中負責接收從生產者發送來的消息並存儲、同時為消費者的拉取請求作準備，代理伺服器也存儲消息相關的元數據，包括消費者組、消費進度偏移和主題和隊列消息等；
35.nameserver：名稱服務充當路由消息的提供者，生產者或消費者能夠通過名字服務查找各主題相應的brokerip列表，多個namesrv實例組成集群，但相互獨立，沒有信息交換；
36.拉取式消費：consumer消費的一種類型，應用通常主動調用consumer的拉消息方法從broker伺服器拉消息、主動權由應用控制，一旦獲取了批量消息，應用就會啟動消費過程；
37.推動式消費：consumer消費的一種類型，該模式下broker收到數據後會主動推送給消費端，該消費模式一般實時性較高；
38.生產者組：同一類producer的集合，這類producer發送同一類消息且發送邏輯一致，如果發送的是事務消息且原始生產者在發送之後崩潰，則broker伺服器會聯繫同一生產者組的其他生產者實例以提交或回溯消費；
39.消費者組：同一類consumer的集合，這類consumer通常消費同一類消息且消費邏輯一致，消費者組使得在消息消費方面，實現負載均衡和容錯的目標變得非常容易，消費者組的消費者實例必須訂閱完全相同的topic，rocketmq支持兩種消息模式：集群消費和廣播消費；
40.集群消費：集群消費模式下,相同消費者組的每個consumer實例平均分攤消息；
41.廣播消費：廣播消費模式下，相同消費者組的每個consumer實例都接收全量的消息；
42.順序消息：順序消息可分為普通順序消息和嚴格順序消息；普通順序消費模式下，消費者通過同一個消費隊列收到的消息是有順序的，不同消息隊列收到的消息則可能是無順序的；而嚴格順序消息模式下，消費者收到的所有消息均是有順序的。
43.根據上述技術方案，所述elasticsearch為實時的分布式搜索和分析引擎，主要用於全文搜索，結構化搜索以及分析，同時實現以下功能：
44.1)分布式實時文件存儲，並將每一個欄位都編入索引，使其可以被搜索；
45.2)實時分析的分布式搜尋引擎；
46.3)可以擴展到上百臺伺服器，處理pb級別的結構化或非結構化數據。
47.根據上述技術方案，所述據存儲採用的mysql、mongodb、oss具體如下：
48.mysql：
49.1)連接器管理：首先是資料庫連接器，主要負責和客戶端建立連接、權限獲取、管理連接等，由於整個建連的過程比較複雜，所以儘量使用長連接，如果資料庫發生異常後為了快速恢復，可重啟系統重新建立連接；
50.2)mysql緩存：mysql請求首先看緩存數據，key為sql語句value為查詢的結果，如果存在則直接返回，如果沒有則直接往下走；
51.3)分析器：對你執行的sql語句進行解析，首先是詞法分析包括一些關鍵字識別，
然後語法分析，查看這條語句是否符合mysql語句；
52.4)優化器：通過你的語句分析，發現那些查詢命中索引，還有表之間的連接順序等；
53.5)執行器：通過上面一系列的驗證，使用引擎提供的接口，經過不斷的執行將查詢的結果存放在結果集中，通過explain可以看到執行器具體掃描了多少行；
54.mongodb：基於分布式文件存儲的資料庫，包括架構模式與持久化模式：
55.架構模式包括replicaset與shardingcluster，所述replicaset為複製集，通常是三個對等的節點構成一個「複製集」集群，有「primary」和secondary等多中角色，其中primary負責讀寫請求，secondary可以負責讀請求，這有配置決定，其中secondary緊跟primary並應用write操作；如果primay失效，則集群進行「多數派」選舉，選舉出新的primary，即failover機制，即ha架構，是mongodb垂直擴展的最小部署單位；所述shardingcluster為分片集群，其中每個shard節點也可以使用replicaset提高數據可用性，數據水平擴展的手段之一，即將整個collection的數據將根據shardingkey被sharding到多個mongod節點上，即每個節點持有collection的一部分數據，這個分片集群持有全部數據；
56.持久化模式：初始化一個線程不斷循環，從defer隊列中獲取要持久化的數據，並將數據寫入磁碟的journal處和mongofile處；
57.oss：存儲數據的基本單元，也被稱為oss文件對象的屬性，包括元信息，用戶數據和文件名組成，對象由存儲空間內部唯一的文件名，即key來標識,對象元信息是一個鍵值對，表示了對象的屬性。
58.與現有技術相比，本發明所達到的有益效果是：
59.1)重視患者的長期跟蹤監測,根據患者的體測報告、飲食習慣及用藥情況進行多維度的記錄、分析、標記,並及時調整該患者的隨訪計劃及其他幹預計劃；
60.2)支持家庭健康信息建檔,分析家庭健康水平並對隱藏家族病史進行預測和早篩；
61.3)支持鄉縣鎮級居民健康檔案收集建檔,多維度分析鄉鎮居民健康水平,助力政府搭建健康工程；
62.4)重視人文關懷,系統支持服務人員話術培訓,提高服務人員專業素養,為和患者建立良好的溝通機制,降低患者的心理、情緒壓力；
63.5)聯動線上網際網路醫院、線下實體醫療機構、藥房以及智能檢測相關電子設備,多方位監測患者病程信息,並為相關機構提供患者就醫用藥等相關數據記錄,將線下診後患者引導至線上在線複診，通過網際網路醫院提供智能診後管理服務，形成醫院線下線上私域流量閉環；
64.6)重視慢病科普；
65.7)低投入、廣覆蓋、個性化的實現保險患者疾病管理，降低疾病理賠風險。
附圖說明
66.附圖用來提供對本發明的進一步理解，並且構成說明書的一部分，與本發明的實施例一起用於解釋本發明，並不構成對本發明的限制。在附圖中：
67.圖1是本發明的系統結構示意圖。
具體實施方式
68.下面將結合本發明實施例中的附圖，對本發明實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本發明一部分實施例，而不是全部的實施例。基於本發明中的實施例，本領域普通技術人員在沒有做出創造性勞動前提下所獲得的所有其他實施例，都屬於本發明保護的範圍。
69.請參閱圖1，本發明提供技術方案：慢病管理系統，包括總服務中心，所述總服務中心內置應用伺服器、業務服務中心與存儲單元，所述應用伺服器採用負載均衡進行任務分發，所述業務服務中心基於消息隊列方式調用任務，所述應用伺服器設置geteway網關與搜尋引擎，所述搜尋引擎採用elasticsearch，所述存儲單元的數據存儲採用mysql、mongodb、oss；
70.所述消息隊列採用rocketmq，由producer、broker、consumer三部分組成，所述producer負責生產消息，所述consumer負責消費消息，所述broker負責存儲消息，所述broker在部署過程中與應用伺服器一一對應，每個broker可以存儲多個topic的消息，每個topic的消息劃分為若干片，且每片獨立存儲於broker內，每個topic內的消息地址轉化為物理地址冗餘存儲於多個messagequeue內。
71.具體而言，所述隊列信息的調用過程中採用redis緩存，所述redis緩存保持數據的持久化，並將內存中的數據保存在磁碟中，重啟的時候可以再次加載進行使用，支持多格式結構數據存儲與數據備份。
72.具體而言，所述負載均衡採用slb負載均衡方式，其是一種對流量進行按需分發的服務，通過將流量分發到不同的後端伺服器來擴展應用系統的吞吐能力，並且可以消除系統中的單點故障，提升應用系統的可用性，可支撐多協議支持、多層次容災、更安全可靠、超強性能保障、靈活的調度策略。
73.具體而言，所述總服務中心設置動態配重服務、服務發現及管理、動態dns服務：
74.動態配重服務：當配重項需要更新時，通過管理系統進行操作的過程；
75.服務發現及管理：基於微服務集群構建管理系統系統，該系統對任一集群提供服務時該群內ip列表進行管理，並對提供服務的集群內的無法工作的ip進行去除，剩餘集群對提供服務集群基於剩餘可用的ip進行消費；
76.動態dns服務：基於nacos充當這個dns域名伺服器的角色，通過控制臺對新增域名進行配置，同時進行域名的權重分配、健康檢查與屬性分辨。
77.具體而言，所述geteway網關為客戶端與應用伺服器之間的中間層，提供路由請求、鑑權、監控、緩存、限流非業務處理功能；
78.基於非業務處理功能，合併客戶端的多服務進行合併，避免跨越請求，以及避免帶來的多個獨立認證需求，易以重構。
79.具體而言，所述業務服務中心，採用了feign調用服務，所述feign調用服務底層通過jdk的java.net.httpurlconnection實現了feign.client接口類，在每次發送請求的時候，都會創建新的httpurlconnection連結，具體步驟如下：
80.s100：通過拓展該接口，使用apachehttpclient或者okhttp3等基於連接池的高性
能http客戶端；
81.s101：基於面向接口的動態代理方式生成實現類；
82.s102：根據contract協議規則，解析接口類的註解信息，解析成內部表現；
83.s103：基於requestbean，動態生成request，根據傳入的bean對象和註解信息，從中提取出相應的值，來構造httprequest對象；
84.s104：使用encoder將bean轉換成http報文正文；
85.s105：攔截器負責對請求和返回進行裝飾處理；
86.s106：基於重試器發送http請求，內置了一個重試器，當http請求出現io異常時，feign會有一個最大嘗試次數發送請求。
87.具體而言，所述rocketmq內組成的具體包括如下：
88.message：消息系統所傳輸信息的物理載體，生產和消費數據的最小單位，每條消息必須屬於一個主題，rocketmq中每個消息擁有唯一的messageid，且可以攜帶具有業務標識的key，系統具有通過messageid和key查詢消息的功能；
89.tag：為消息設置的標誌，用於同一主題下區分不同類型的消息，來自同一業務單元的消息，可以根據不同業務目的在同一主題下設置不同標籤，標籤能夠有效地保持代碼的清晰度和連貫性，並優化rocketmq提供的查詢系統，消費者可以根據tag實現對不同子主題的不同消費邏輯，實現更好的擴展性。
90.producer：負責生產消息，由業務系統負責生產消息，一個消息生產者會把業務應用系統裡產生的消息發送到broker伺服器，rocketmq提供同步發送、異步發送、順序發送與單向發送，同步發送與異步發送需要broker返回確認信息，單向發送不需要broker返回確認信息；
91.consumer：負責消費消息，是後臺系統負責異步消費，一個消息消費者會從broker伺服器拉取消息、並將其提供給應用程式，從用戶應用的角度而言提供了兩種消費形式：拉取式消費、推動式消費：
92.topic：表示一類消息的集合，每個主題包含若干條消息，每條消息只能屬於一個主題，是rocketmq進行消息訂閱的基本單位；
93.brokerserver：代理伺服器消息中轉角色，負責存儲消息、轉發消息，代理伺服器在rocketmq系統中負責接收從生產者發送來的消息並存儲、同時為消費者的拉取請求作準備，代理伺服器也存儲消息相關的元數據，包括消費者組、消費進度偏移和主題和隊列消息等；
94.nameserver：名稱服務充當路由消息的提供者，生產者或消費者能夠通過名字服務查找各主題相應的brokerip列表，多個namesrv實例組成集群，但相互獨立，沒有信息交換；
95.拉取式消費：consumer消費的一種類型，應用通常主動調用consumer的拉消息方法從broker伺服器拉消息、主動權由應用控制，一旦獲取了批量消息，應用就會啟動消費過程；
96.推動式消費：consumer消費的一種類型，該模式下broker收到數據後會主動推送給消費端，該消費模式一般實時性較高；
97.生產者組：同一類producer的集合，這類producer發送同一類消息且發送邏輯一
致，如果發送的是事務消息且原始生產者在發送之後崩潰，則broker伺服器會聯繫同一生產者組的其他生產者實例以提交或回溯消費；
98.消費者組：同一類consumer的集合，這類consumer通常消費同一類消息且消費邏輯一致，消費者組使得在消息消費方面，實現負載均衡和容錯的目標變得非常容易，消費者組的消費者實例必須訂閱完全相同的topic，rocketmq支持兩種消息模式：集群消費和廣播消費；
99.集群消費：集群消費模式下,相同消費者組的每個consumer實例平均分攤消息；
100.廣播消費：廣播消費模式下，相同消費者組的每個consumer實例都接收全量的消息；
101.順序消息：順序消息可分為普通順序消息和嚴格順序消息；普通順序消費模式下，消費者通過同一個消費隊列收到的消息是有順序的，不同消息隊列收到的消息則可能是無順序的；而嚴格順序消息模式下，消費者收到的所有消息均是有順序的。
102.具體而言，所述elasticsearch為實時的分布式搜索和分析引擎，主要用於全文搜索，結構化搜索以及分析，同時實現以下功能：
103.1)分布式實時文件存儲，並將每一個欄位都編入索引，使其可以被搜索；
104.2)實時分析的分布式搜尋引擎；
105.3)可以擴展到上百臺伺服器，處理pb級別的結構化或非結構化數據。
106.具體而言，所述據存儲採用的mysql、mongodb、oss具體如下：
107.mysql：
108.1)連接器管理：首先是資料庫連接器，主要負責和客戶端建立連接、權限獲取、管理連接等，由於整個建連的過程比較複雜，所以儘量使用長連接，如果資料庫發生異常後為了快速恢復，可重啟系統重新建立連接；
109.2)mysql緩存：mysql請求首先看緩存數據，key為sql語句value為查詢的結果，如果存在則直接返回，如果沒有則直接往下走；
110.3)分析器：對你執行的sql語句進行解析，首先是詞法分析包括一些關鍵字識別，然後語法分析，查看這條語句是否符合mysql語句；
111.4)優化器：通過你的語句分析，發現那些查詢命中索引，還有表之間的連接順序等；
112.5)執行器：通過上面一系列的驗證，使用引擎提供的接口，經過不斷的執行將查詢的結果存放在結果集中，通過explain可以看到執行器具體掃描了多少行；
113.mongodb：基於分布式文件存儲的資料庫，包括架構模式與持久化模式：
114.架構模式包括replicaset與shardingcluster，所述replicaset為複製集，通常是三個對等的節點構成一個「複製集」集群，有「primary」和secondary等多中角色，其中primary負責讀寫請求，secondary可以負責讀請求，這有配置決定，其中secondary緊跟primary並應用write操作；如果primay失效，則集群進行「多數派」選舉，選舉出新的primary，即failover機制，即ha架構，是mongodb垂直擴展的最小部署單位；所述shardingcluster為分片集群，其中每個shard節點也可以使用replicaset提高數據可用性，數據水平擴展的手段之一，即將整個collection的數據將根據shardingkey被sharding到多個mongod節點上，即每個節點持有collection的一部分數據，這個分片集群持有全部
數據；
115.持久化模式：初始化一個線程不斷循環，從defer隊列中獲取要持久化的數據，並將數據寫入磁碟的journal處和mongofile處；
116.oss：存儲數據的基本單元，也被稱為oss文件對象的屬性，包括元信息，用戶數據和文件名組成，對象由存儲空間內部唯一的文件名，即key來標識,對象元信息是一個鍵值對，表示了對象的屬性。
117.需要說明的是，在本文中，諸如第一和第二等之類的關係術語僅僅用來將一個實體或者操作與另一個實體或操作區分開來，而不一定要求或者暗示這些實體或操作之間存在任何這種實際的關係或者順序。而且，術語「包括」、「包含」或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、物品或者設備所固有的要素。
118.最後應說明的是：以上所述僅為本發明的優選實施例而已，並不用於限制本發明，儘管參照前述實施例對本發明進行了詳細的說明，對於本領域的技術人員來說，其依然可以對前述各實施例所記載的技術方案進行修改，或者對其中部分技術特徵進行等同替換。凡在本發明的精神和原則之內，所作的任何修改、等同替換、改進等，均應包含在本發明的保護範圍之內。