養老信息化平臺

解決方案

目 錄

1. 項目背景 4

2. 現狀分析 4

3. 建設目標 5

4. 建設原則 5

4.1.1. 一體化原則 5

4.1.2. 先進性和成熟性原則 6

4.1.3. 標準化原則 6

4.1.4. 安全性原則 6

4.1.5. 易用性原則 6

4.1.6. 靈活性原則 6

4.1.7. 可擴展性原則 6

5. 總體設計 7

5.1. 業務架構 7

5.1.1. 面向養老機構的業務服務 7

5.1.2. 面向養老管理公司的管理服務 7

5.2. 技術架構 7

5.2.1. 技術選型 7

5.2.2. 軟件開發架構 8

5.2.3. 軟件部署架構 9

6. 系統建設內容 9

7. 系統展示 14

7.1. 客戶接待 14

7.2. 房態圖 15

7.3. 入住申請 16

7.4. 老人檔案管理 17

7.5. 評估管理 21

7.6. 合同管理 23

7.7. 入住登記 25

7.8. 費用結算 26

7.9. 護理工作站 27

7.9.1. 入住確認 28

7.9.2. 外出登記 29

7.9.3. 銷假 30

7.9.4. 護理執行 31

7.9.5. 退住登記 32

7.10. 主管工作臺 33

7.11. 排班管理 34

8. 項目開發及實施方案 36

8.1. 開發模式 36

8.2. 開發階段 36

8.2.1. 基本需求調研 36

8.2.2. 建立項目團隊 36

8.2.3. 產品設計 36

8.2.4. 產品開發 37

8.2.5. 系統測試 37

8.3. 實施階段 37

8.3.1. 核心用戶交流（項目實施啟動會議） 37

8.3.2. 基礎數據準備 37

8.3.3. 系統應用培訓 37

8.3.4. 系統試運行 37

8.3.5. 收集使用反饋 37

8.3.6. 系統推廣使用 38

8.3.7. 系統驗收 38

背景

目前，中國已經成為世界上老年人口最多的國家，據國家統計局最新數據，2017年60周歲及以上人口24090萬人，占總人口的17.3%，其中65周歲及以上人口15831萬人，占總人口的11.4%。當一個國家或地區60歲以上老年人口占人口總數的10%，或65歲以上老年人口占人口總數的7%，即意味著這個國家或地區的人口處于老齡化社會。中國老年人口比例顯然嚴重超標。

近幾年，中國60歲以上老年人口數量不斷增長，2013年突破2億，占比僅14.9%，2017年達到24090萬人，占比突破17%。隨著人口老齡化程度加深，未來中國老齡人口將進一步增加。

我國養老機構供給的主體是公辦養老機構，其他形式的養老機構供給主體發展不充分，床位數供給量小，不能填補公辦養老機構留下的供給缺口。2016年，我國養老服務機構2.85萬個，養老服務機構床位數達到780.0萬張，每千老年人口養老床位數33.8張。這與發達國家床位數相比有較大差距。我國老年人對養老機構的需求有較大的缺口，養老機構床位數供給遠小于需求，供需矛盾十分突出。預計到2018年我國養老服務機構數量將突破3萬個。

養老市場前景廣闊，但養老機構的信息化建設水平仍處于初級階段。很多養老機構仍以手工作業為主，部分機構簡單的應用系統達到計費要求，無法滿足養老機構業務的發展，所以需要開發一套適用于養老機構的信息系統平臺作為養老機構管理的信息化支撐。

現狀分析

目前國內養老機構的信息化建設水平較低，甚至部分機構仍處于手工作業階段。在如今的大數據、信息化時代背景下，養老機構的日常工作中存在諸多問題，不利于機構未來的發展，具體問題經過市場調研后總結如下：

• 手工臺賬繁多，工作量巨大

臺賬是各養老機構記錄日常工作、監督員工績效、應對監管機構檢查的重要手段。臺賬不但類型繁多，而且格式復雜。臺賬格式會隨著管理流程的變更不斷增加或調整。員工填寫臺賬的工作量巨大，甚至部分機構單獨安排人員進行臺賬的填寫及整理，效率低下，浪費人力。

• 業務流程沒有固化到系統中，部分細節流程不明確

各機構在運營中都有自己的管理流程，例如老人入住流程、老人退住流程等。流程顆粒度大，缺少日常管理中的細節流程，例如老人在院消費、護理項目執行等。流程執行的記錄及監督工作都通過人工完成，及時性、規范性差。

• 一線人員操作系統不便

系統操作不便存在多種情況：傳統系統基于PC端進行應用，一線護理人員辦公環境不支持使用電腦，無法操作系統；部分養老機構不允許工作人員在上班時間使用手機，所以系統無法在移動端使用；部分一線員工電腦操作水平較差，無法完成系統操作。系統設計要考慮操作的簡便性，并且系統的運行載體要適合養老機構的實際環境，可考慮使用觸摸式大屏幕，通過點擊屏幕完成操作。

• 工作頁面不分明

院內業務角色分工不明確，經常出現一人兼多職的情況。一個人操作多個功能界面，完成多個角色的工作，系統錄入人員并不是實際完成工作的人員，導致數據不準確、可用價值低。

• 數據沒有標準化、無法統計

由于養老信息化建設處于初級階段，沒有明確的數據標準依據，很多數據沒有標準化，大量自然語言摻雜其中，數據存儲顆粒度粗糙。各機構疏于對標準數據集的梳理，系統存儲的數據無法滿足深度挖掘的需要，無法進行決策性、趨向性的深度分析。

• 醫養分家，數據無法共享

部分護養院同時具有養老資質和醫療資質，但同時做到醫養結合的系統很少，所以大部分護養院都是同時采購養老信息管理系統和醫院信息管理系統（HIS），但是系統間的數據共享的實現需要投入較大的改造成本，養老機構難以承擔，導致大部分機構的醫養數據是無法互通的，對管理及系統的應用具有很大的影響。

建設目標

• 實現養老機構的信息化管理

以老人為核心，將借用其他行業流程化的概念與養老服務業務進行結合，確認業務流程、業務范圍、規劃系統功能。打造一套業務專業、功能全面、技術先進、簡單易用的養老智慧平臺系統。

• 提高養老機構管理部門的決策管理能力

通過對養老機構運營情況的統一管理，將機構的運營信息進行信息化、標準化的存儲，管理部門可對這些信息進行分析、統計，為管理部門的決策提供數據支持。

• 醫養結合、一體化應用

一套系統中既包含醫也包含養，養老系統內部集成小型醫院信息系統（HIS），可對在院老人進行診療服務，養老數據與診療數據同庫同源，真正實現醫養結合，滿足養老機構內設醫療機構或護養院類型的養老機構的需求。

建設原則

一體化原則

保證數據由采集、存儲、整理、分析到提取、應用的一體化，實現數據由發生地一次性錄入，然后可被所有對該數據有需求的單位多次重復且不同層次使用，整個系統各模塊之間要實現數據共享，互聯互通，清晰體現內在邏輯聯系，并且數據之間必須相互關聯，相互制約。

先進性和成熟性原則

在實用、可靠的前提下，應用系統設計盡可能地跟蹤國內外先進的軟件開發平臺和軟件開發技術，使設計系統能夠最大限度地適應技術發展變化的需要，以確保系統的先進性。

標準化原則

雖然養老行業尚未發布信息化建設相關標準，但系統在設計中會參考醫療相關標準進行設計，并協助養老機構梳理相關標準。

安全性原則

（1）系統級安全：系統設計時應闡明用何種方式保證系統安全。有足夠的防護措施，防止非法用戶侵入；網絡傳輸加密，防止信息外泄等。

（2）應用級安全：系統管理應可以根據員工的職務和所承擔的工作進行角色劃分等，通過角色劃分等進行權限分配。保證不因操作人員的誤操作導致系統的崩潰。

（3）數據加密：系統應采取對某些關鍵數據（如用戶名、密碼、證件號、電話）進行加密存儲等方法提高安全性。

（4）備份與恢復：對存儲的數據，應有冗余保護措施，保證用戶數據隨時可提取，對于容錯及冗余都有相應的安全保護機制，要根據項目實際情況，制定切實可行的自動化備份機制。

易用性原則

軟件系統應考慮實用性與先進性相結合，要體現出易于理解掌握、操作簡單、提示清晰、邏輯性強，操作界面簡潔、幫助信息豐富，而且要針對醫院輸入項目的特點對輸入順序專門進行合理定制，并可根據用戶工作習慣進行模板定制，保證操作人員以最快速度和最少的擊鍵次數完成日常工作。應用界面簡捷、直觀并提供聯機或脫機的幫助手段。針對養老行業特點，考慮多種設備終端實現應用，包括PC、移動端、可觸摸大屏幕、智能終端等。為了讓一線護理人員更方便的操作系統，系統設計遵循能圖片不文字，能點選不填寫的原則。

靈活性原則

系統可根據養老機構的具體工作流程定制、重組和改造，并為機構提供定制和改造的客戶化工具。系統應具有良好的可裁減性、可擴充性和可移植性；軟件設計模塊化、組件化，并提供配置模塊和客戶化工具。系統需求及流程變化、操作方式變化、機構人員變化、操作系統環境變化對系統應無影響。

可擴展性原則

充分考慮業務規模和結構的發展變化，系統有較強的擴展性，能夠滿足業務不斷擴充的需要，應用軟件系統能夠隨著系統規模同步增長，保持軟件體系結構的穩定，不需要對系統進行大的改動，保護前期投資。

總體設計

業務架構

**醫為養老平臺是一套基于SAAS（Software-as-a-Service）模式的新型養老機構信息管理系統，其主要服務于養老機構，并向養老管理公司及時提供透明化信息的軟件系統。

面向養老機構的業務服務

對于養老機構，系統首要解決的問題就是養老機構的基礎應用。目前國內的養老機構系統應用水平較差，只能滿足部分財務管理的功能，其他基礎業務仍然通過紙質單據和人工管理的方式運行，嚴重影響了養老機構的發展。系統要向各機構提供完善的業務應用服務，保證各機構的日常業務均可在系統中進行處理，提升工作效率及質量，記錄工作痕跡，優化工作流程，盡量實現無紙化辦公，降低運營及管理成本。

面向養老管理公司的管理服務

對于養老管理公司，系統應提供管理決策依據。管理者可實時的關注其管理的養老機構的運營情況、員工的工作績效情況等。系統可根據管理范圍將各養老機構進行分組，分配給養老管理公司進行管理。管理者可根據管理方式配置系統流程，達到不同的管理效果。系統可根據不同管理范圍的權限，整理相關機構的統計數據供管理者查詢、參考。

技術架構

技術選型

軟件開發架構

軟件整體技術架構采用**醫為互聯網應用系統架構體系：

• 底層是物理層、網絡、存儲。
• PAAS層：Kubernetes是Google開源的容器集群管理系統。它構建Docker（dao o）技術之上，為容器化的應用提供資源調度、部署運行、服務發現、擴容縮容等整一套功能，本質上可看作是基于容器技術的mini-PaaS平臺。docker 容器的監控和管理。容器里面就放的是微服務。
• Spring Cloud云服務平臺，負責服務治理、發布（有很多組件，提供微服務的大部分組件內容。比如服務注冊用的某個，也可以替換。）Spring Cloud 是Pivotal提供的用于簡化分布式系統構建的工具集。Spring Cloud引入了云平臺連接器(Cloud Connector)和服務連接器(Service Connector)的概念。云平臺連接器是一個接口，需要由云平臺提供者進行實現，以便庫中的其他模塊可以與該云平臺協同工作。Spring Cloud最重要的一點是它可以和Spring Boot一起工作，Spring Boot可以幫助開發者更容易地創建基于Spring的應用程序和服務。從Spring Boot項目名稱中的Boot就可以看出來，Spring Boot的作用在于創建和啟動新的基于Spring框架的項目。
• 離散式數據存儲也就是分布式數據存儲。不同的微服務對應不同的存儲。
• 兩側是安全、監控。服務的運維管理：服務治理、部署管理、持續集成等。
• 服務和服務之間的信息交互、事務，包括第三方的對接，通過MQ消息隊列來實現。
• 右邊是開放式的云平臺，第三方如何發布、注冊他的服務?；陂_放式的API開發第三方的應用。
• 最上面是面對終端的Nginx服務集群，實現服務的負載均衡。

軟件部署架構

**醫為養老平臺將采用互聯網應用模式進行集中部署。系統架構支持部署在各類第三方云服務器平臺（阿里云、騰訊云、華為云、亞馬遜云等）及自建云服務器。

系統集中部署在云平臺中，各機構通過外網、專線、VPN接入等方式訪問系統并進行應用。各養老機構不需要建設機房，減少服務器硬件及運維技術人員的導入，降低信息化運營成本。

云服務器資源可隨應用機構數量的增加進行擴充，通過集群、負載均衡等技術手段保證系統整體運行的高速、穩定。

系統建設內容

系統展示

本章節將進行系統部分功能的展示，所展示功能是以老人入住養老院的整個周期為中心的核心業務功能。

客戶接待

• 功能描述

有入住意向的老人或老人家屬到養老機構進行咨詢，接待人員除了做好接待工作外還要通過信息系統記錄接待信息，包括到訪人員基本信息、聯系方式、要入住的老人信息、入住意向等，可定期回訪意向客戶。

• 角色描述

前臺接待人員（銷售/客服）

• 交互界面

【接待管理】

【接待登記-接待信息】

• 界面描述

【接待管理】界面可查詢所有接待記錄。表格上方為精準查詢，可對多種條件進行精準查詢。表格顯示符合條件的接待記錄。點擊【撤銷】可以刪除接待記錄；點擊【回訪】可以記錄回訪信息。

點擊【新建接待】按鈕，系統會彈出【接待登記】界面，在界面中可記錄接待信息，包括被接待人信息、老人信息、意向、參觀人數等關鍵信息。點擊【保存】按鈕即可完成記錄。

房態圖

• 功能描述

接待人員可通過房態圖實時掌握全院床位的入住情況，了解可入住房間的朝向、同屋老人的情況等，快速為客戶推薦合適的房間。

• 角色描述

前臺接待人員（銷售）

• 交互界面

【房態圖】

• 界面描述

【房態圖】界面左側為快速檢索條件，可根據床位狀態，房間狀態等條件查詢符合條件的信息。界面右側上方顯示全院床位的關鍵統計信息，包括入住率、空床率、床位數、房間數等。右側卡片展示個房間的信息，包括房間狀態，大小，金額，床位狀態，入住人員等。界面通過不同顏色的圖標顯示各種狀態，讓操作人員可快速定位到符合條件的房間。

入住申請

• 功能描述

有入住意向的客戶可以進行預約登記。如果機構存在空床，客戶可預約床位，預約的床位處于鎖定狀態，為預約人保留，不會讓其他人入住。如果機構沒有空床，預約人可排隊等待。

• 角色描述

前臺接待人員

• 交互界面

【入住申請列表】

【入住申請】

• 界面描述

【接待管理】界面可查詢所有接待及入住申請信息，通過【更多檢索】功能，可以組合條件進行查詢，篩選適合辦理入住的老人。

【入住申請】頁面可以為老人選擇預約的床位。如果沒有空床，可以登記老人的床位要求，待有床位時根據老人要求優先選擇床位。

老人檔案管理

• 功能描述

確認入住的老人首先應進行建檔工作，建立入住老人的詳細檔案，包括老人本人基本信息、生活習慣、健康情況以及家屬相關信息、聯系方式等。應支持老人全面信息的查看，包括在院期間的所有生活記錄等。

• 角色描述

銷售人員、護理員、護理主任、院長

• 交互界面

【老人檔案管理】

【新建老人檔案】

【生活及健康情況】

【登記緊急聯系人】

【登記家屬信息】

【360度長者瀏覽器】

【合同記錄】

• 界面描述

【老人檔案管理】界面可通過各種條件查詢老人檔案，點擊

圖標可調用【360度長者瀏覽器】界面查看老人全面信息，包括個人信息、體征信息、就診信息及所有在院產生的相關信息。

點擊【新建檔案】可進行建檔操作，檔案可收集老人的基本信息、興趣愛好、家庭情況、家屬資料、緊急聯系人等全面的信息。老人檔案會形成唯一的檔案編號，入院及在院所有信息化流程都以該檔案號作為關鍵信息進行串聯。

評估管理

• 功能描述

評估是老人入住前的重要步驟，已經建檔完畢的老人在簽訂合同前要對健康情況進行評估，確定老人的護理等級，以評估結果為依據確定合同費用。老人在院期間也需要定期進行各種類型的評估，關注并記錄老人的健康情況。

評估模板支持自定義，各機構可根據自身情況定制評估內容及樣式，自定義問題及分數等。

• 角色描述

醫生、護士、保健員

• 交互界面

【評估管理】

【選擇評估模板】

【填寫評估問卷】

• 界面描述

【評估管理】界面是對老人所有評估記錄的管理，界面左側是所有老人信息，可根據條件檢索?？刹榭礆v史記錄及分數。

點擊【新建】按鈕可選擇評估模板進行評估，選擇合適的模板點擊【確認】按鈕開始評估。評估問卷的樣式及問題、選項得分等內容均可以在模板編輯器中進行設置。

評估問卷界面點擊【保存】按鈕，系統會自動計算得分并記錄評估信息及評估意見。

合同管理

• 功能描述

評估完成后根據評估結果生成合同內容，包括護理等級、護理費用、護理項目等。入住老人簽訂合同后系統要記錄合同關鍵信息，包括合同日期、編號、類型等。合同到期應自動提醒。要支持合同的續簽、終止、變更等。

• 角色描述

前臺接待人員（銷售/客服）

• 交互界面

【合同管理】

【新建合同】

【服務內容選擇】

• 界面描述

【合同管理】界面可查詢所有合同，并自動提示將要到期的合同。支持合同的續簽、變更、終止等功能。

點擊【新建合同】按鈕可以創建新合同，合同內容分為基礎信息、服務內容、 附加條款、附件上傳四部分?；A信息包括合同有效期限以及服務費用等重要信息，是合同管理和每月繳費的依據；服務內容記錄老人在院享受的具體服務項目，系統會根據合同中的服務項目生成護理記錄，用于護理員的日常工作記錄； 附加條款支持自由錄入內容，記錄合同的附加條款；附件上傳支持上傳合同影印件或照片作為備份，可在電腦端查看紙質合同信息。

入住登記

• 功能描述

合同簽訂后老人正式入住養老機構時，需要在系統中進行入住登記操作，表示老人正式入住到養老院，系統自動通知相關人員或部分做好老人入住的相關工作。

• 角色描述

前臺接待人員

• 交互界面

【入住登記列表】

【入住登記】

• 界面描述

界面左側為步驟條，可顯示老人辦理入住過程中的各步驟完成情況?？筛鶕到y參數設定步驟順序及必要性。通過【調檔】按鈕可以調用已建檔的老人信息，未建檔的老人無法進行入住登記。點擊【評估報告】按鈕可查看老人的評估記錄。點擊【提交】按鈕完成入住登記，系統會通知相關部門或人員有老人入住，做好準備工作。

費用結算

• 功能描述

辦理入住登記后要繳納首月費用，入住后每月要繳納當月的相關費用。費用明細要條目化，系統可根據當月在住天數自動計算費用信息，產生費用清單。應支持各種方式的折扣，支持多種支付方式進行支付，支持費用項目內容、數量、金額的調整。

• 角色描述

出納

• 交互界面

【費用結算】

• 界面描述

界面右側為老人信息及結算信息，通過老人姓名、床號等條件可查詢并選擇老人信息，界面左側會顯示該老人的未結算費用。勾選要結算的費用項目，結算信息會顯示應收金額，按照系統提示進行收費并點擊【收費】按鈕完成收費動作。

系統支持發票明細管理，記錄每張發票編號及使用情況。

點擊【計價】按鈕，可以手動調整收費項目，增加或沖抵收費項目。

護理工作站

• 功能描述

護理工作站是護理人員日常工作的輔助程序，護理員通過工作站軟件的操作可以記錄日常工作情況，實時了解老人日常護理情況。護理工作站記錄的相關信息是未來績效管理和決策支持的重要數據來源。

• 角色描述

護理員

• 交互界面

【護理工作站-主頁面】

• 界面描述

【護理工作站】是以護理員與老人關系為核心進行展示的，每位護理人員登錄界面首先顯示的是自己負責護理的老人信息，可時刻關注老人情況。界面功能進行集成，在主界面中可進行老人相關的所有業務操作。系統會根據老人待辦的項目進行提示，以紅色圓點表示。護理員通過系統提示及時完成工作，避免遺漏，從而提升工作效率及準確度。

除了自己負責的老人之外，護理人員也可查看其它老人情況，在替班的情況下可完成被替班護理員名下的老人的相關工作。

入住確認

• 功能描述

入住登記辦理完成，老人到指定的床位報道，護理組長要進行對接，了解老人情況，并在系統中進行入住確認操作，記錄老人實際入住的時間及相關準備工作的完成情況。

• 角色描述

護理員

• 交互界面

【入住確認】

• 界面描述

界面左側是入住老人的基本信息和服務項目，護理員可進行了解，點擊【詳情】按鈕可調用【360度長者瀏覽器】查看詳細信息。

界面右側表格是一次性代辦費中包含的待辦事項，護理員可根據實際情況勾選待辦情況。

界面右下方是入住的確認信息，核對無誤后點擊【確定】按鈕即可完成入住確認。

外出登記

• 功能描述

老人請假外出要通知護理員，護理組長要進行登記，記錄老人的外出信息，外出時的水電表讀書，用于計算當月費用。

• 角色描述

護理員

• 交互界面

【外出登記】

• 界面描述

在【護理工作站】界面點擊【外出】按鈕可進行外出登記操作，支持記錄外出時間、陪同人信息、水電表讀書等信息。

銷假

• 功能描述

銷假是老人回院時要進行記錄的內容，要記錄具體的回院時間以核算護理費用的退費金額。

• 角色描述

護理員

• 交互界面

【銷假】

• 界面描述

請假外出的老人回院后要進行銷假操作，否則老人一直處于外出狀態。銷假需要填寫回院時間，用于計算護理費、伙食費退費金額。確認相關信息填寫無誤點擊【確定】按鈕即可完成銷假操作。

護理執行

• 功能描述

護理員日常工作基本都是針對于負責的老人的日常照護，系統需要記錄護理員日常護理工作的執行情況，用于工作績效的統計及工作質量的監督。

• 角色描述

護理員

• 交互界面

【護理記錄】

• 界面描述

界面左側為護理員所負責的老人列表，右側為各類工作清單，包括護理記錄、服藥記錄、活動記錄、體征記錄等，工作內容可根據老人情況進行調整。勾選相應的項目點擊【執行】按鈕即可完成執行操作，系統會自動記錄執行人員及操作時間。支持護理人員自行調整執行時間。

退住登記

• 功能描述

老人退住需要通知護理人員，護理總監在系統中進行登記，系統自動通知相關部門或人員協助老人辦理離院手續。

• 角色描述

護理員

• 交互界面

【退住登記】

• 界面描述

界面上側顯示老人信息，填寫相關信息后點擊【確定】按鈕即可完成登記，系統會自動提示相關部門或人員進行離院審核及費用相關操作。

主管工作臺

• 功能描述

護理主任、院長等養老機構領導層可通過系統對老人的住宿進行管理，包括請假外出的審核、退住的審核、合同審核、排班管理、交班記錄管理、突發事件登記。其主要目的是讓領導層知道院內老人的最新動態，實時掌握院內運行方面的信息。

• 角色描述

院長、護理主任等領導層

• 交互界面

【入住管理】

• 界面描述

界面集成了外出及退住兩種申請的審批，當有新的申請信息時，系統會自動進行提示。點擊老人姓名可查看詳細的信息。選中申請數據點擊【審核】按鈕可完成審核操作，系統會記錄審核人、審核時間。點擊【費用處理】按鈕可手動調整老人相關費用，結算時以手動調整后的費用信息進行計算。

退住流程只有審核通過后方可到會計處進行退住結算。

排班管理

• 功能描述

院領導要對當月護理人員出班進行規劃，合理安排出班，保證各區域有人在崗，并合理安排休息。通過系統的協助，保證排班的合理性及公平性。

• 角色描述

院長、護理主任

• 交互界面

【排班管理-列視圖】

【排班管理-周視圖】

【排班操作】

• 界面描述

護理員可通過【排班展示】界面了解本人的月排班情況，并進行調班申請。調班申請時選擇替班人員即可，通過上級領導的審核即可完成調班?？杀Ｕ显碌卓记谛畔⑴c排班表的一致性。

項目開發及實施方案

開發模式

本產品相關項目需求采用敏捷開發模式開發新產品，以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發。

根據具體的項目需求進行設計與開發，盡快形成可交付的產品通過客戶的評審并上線應用，及時收集反饋，總結新產品問題，進行迭代升級。可保障項目各階段的產品的完整性、準確性。將項目風險控制在最小范圍內。

開發階段

基本需求調研

乙方出技術人員同甲方人員一起對養老機構的現狀及系統需求進行深入的調研，了解養老機構的需求，規劃系統功能范圍、開發工作量及項目周期。為項目合同簽訂及系統詳細設計提供依據。

建立項目團隊

合同簽訂完畢后，乙方組織養老系統開發及實施團隊，團隊包括：產品經理、數據結構設計人員、UI設計人員、開發人員、測試人員、實施經理、實施工程師等。

產品設計

根據調研結果對產品進行設計，包括數據庫結構設計、UI界面設計、業務功能流程設計等，編寫并與甲方共享詳細設計文檔。甲方可參與設計。

產品開發

研發人員根據系統詳細設計說明書進行系統開發工作。在程序編碼中必須要制定統一、符合標準的編寫規范，以保證程序的可讀性、易維護性。提高程序的運行效率。

系統測試

測試是保證軟件運行正確性的重要手段。整個測試階段分為單元測試、系統測試、壓力測試三個階段，貫穿軟件開發的整個過程。測試過程中應制定測試計劃，編寫測試用例并記錄測試結果，形成完整的文字備案。

實施階段

核心用戶交流（項目實施啟動會議）

機構關鍵用戶與項目實施團隊人員進行溝通，明確各項事宜，包括：

• 確認雙方項目負責人
• 確認配合上線工作的各部門職責
• 確認整體上線方案及進度安排
• 梳理系統功能流程，確定上線具體功能點

基礎數據準備

機構用戶需要根據系統提供的基礎數據模板進行基礎數據整理，并提交給實施人員，實施人員進行數據導入。包括：機構基本信息，科室信息，用戶信息，用戶權限，系統使用流程信息，收費項目，基礎字典信息等。

系統應用培訓

實施人員在項目現場組織培訓，養老機構需配合準備培訓場地，召集系統使用人員參加培訓。原則上參加培訓人員需要通過最終考試后方可開通登錄賬號并使用系統，具體考核方式可以由客戶方制定。

系統試運行

培訓結束并且系統初始化數據測試通過后，系統會開放正式運行環境，進入系統試運行階段，試運行期間后臺維護人員會實時關注系統的使用情況及數據準確性。

收集使用反饋

實施人員收集用戶在使用系統過程中的問題反饋，提交給開發人員進行系統改造升級，通過快速迭代的方式不斷完善系統功能。

系統推廣使用

系統在試點機構成功上線后，推廣到其他機構進行使用。上線步驟與試點機構一致。

系統驗收

合同中包含的所有機構上線完畢并平穩運行30天后啟動驗收流程，客戶簽訂驗收單后，乙方技術人員對客戶方的系統維護人員進行技術培訓，移交使用說明，數據說明等相關技術手冊，保障客戶方的維護人員可以獨立維護系統。