系統分析工作是軟件系統項目成功的基礎，對于醫療系統軟件也是如此。在開始系列文章撰寫之前，筆者特意將系統分析作為一個議題撰文與同行交流研討。

　　1 什么是系統分析？為什么要進行系統分析？

　　應用軟件開發過程中，系統分析是非常重要的環節。那么什么是系統分析，為什么要進行系統分析呢？一個企業系統中的應用軟件為企業業務和管理發展提供支撐和服務，隨著企業組織的快速發展，原有的應用軟件系統會出現了新的問題。例如工作效率低下、流程繁瑣、業務產出質量差等，企業用戶對此感到難以忍受，會提出了一些新的預期。例如在醫療機構的發展過程中，當醫院內出現流程繁瑣、患者就醫體驗不佳、醫療業務效率低差錯率高、業務效率低下等問題時，就需要開展系統分析工作，找出問題原因和改進方案。系統分析是隨著問題的產生以及用戶對系統和業務的改造愿望而產生的，系統分析最終將產生系統問題分析說明文檔等資料，這些文檔資料是后續系統開發工作的設計依據和驗收依據。

　　2 怎樣進行系統分析？系統分析的方法有哪些？

　　系統分析最主要的目的是讓軟件開發人員理解軟件要解決的業務問題是什么，從而確定針對這些問題的解決方案。系統分析有多種方法，比較常見的有結構化分析方法、信息工程法、面向對象分析方法和原型分析法等。

　　結構化分析方法是最早使用的系統分析方法之一，目前仍然在廣泛使用。結構化分析方法是面向數據流進行需求分析的方法，采用自頂向下、逐層分解，建立系統的處理流程，以數據流圖和數據字典為主要工具，建立系統內在的邏輯模型。

　　信息工程法關注系統中存儲的數據結構，而不是過程，是一種以數據為中心的方法。實體關系圖是信息工程法中進行數據建模的常用工具。

　　面向對象法不把信息系統看作數據和過程的集合，而是一組封裝了數據和過程的對象。對象可以包含很多屬性，創建、讀取、修改和刪除對象的數據的唯一方式是通過嵌入對象中的過程（或稱方法）來實現，統一建模語言（UML）是面向對象系統分析方法常用的工具。

　　原型分析法是一種快速迭代的系統分析方法，當用戶或者系統分析人員對系統缺少直觀認知時，通過構建一個小規模、不完整但可以使用的實例作為原型。原型分析法的思想，主要是源于“當我看到它時，我才知道我想要什么”的思維方式。因而原先分析法更有利于用戶表述自己的應用需求。

　　3 系統分析環節和步驟？

　　根據系統分析的主要任務是對當前系統進行調查研究，得到當前系統的詳細資料，對醫療機構內部整體業務管理狀況和信息處理過程進行分析，為系統開發提供所需要的資料，并提交系統方案說明書。通常情況下，系統分析步驟包括范圍定義、問題分析、需求分析、邏輯設計、決策分析等階段。

（1）定義分析范圍

　　系統的研發必須要有一個明確的任務目標，即明確系統應該解決哪些問題，提供哪些功能。大型醫院進行系統研發，往往是“眾口難調”，可能每個人都有自己的需求和想法。在范圍定義時，要重點關注系統所有者視圖，也就是醫院重要管理人員的需求和預期。這些重要管理人員，大都是醫院領導，對系統決策、方案確定、驗收等環節起著決定性作用。在范圍定義階段，需要完成的工作包括列出問題和機會、確定項目范圍等。

　　列出問題和機會：確定觸發系統開發的問題和機會，是業務開展需要、管理變革還是外部政策法規驅使，并且對每個問題的緊急程度、實現難度和優先級進行初步評估。可采用現場實地調研或召開研討會，并制定問題描述文檔，問題描述文檔包括問題簡要描述、緊急程度、優先級、建議采用的方案、問題提出人、聯系方式等內容。

　　確定項目初步范圍：在系統開發過程中，用戶方很容易提出新的需求和想法。但是，在系統分析階段依然有必要確定項目的范圍，并以文檔的形式保留下來。這樣，之后如果項目范圍發生了變化，院方用戶就能明白為什么項目開發的進度和經費投入也要相應變化。

　　（2）理解用戶要求階段

　　問題分析階段的主要任務是，充分研究和理解問題領域，了解用戶的要求，并分析其中存在的問題、機會和約束條件。在醫療系統軟件研發時，一般要達到兩個要求：對系統范圍和問題相關內容精確化；為系統定義一個工作術語表。主要包括三方面工作：研究問題領域、分析業務流程、制定系統改進目標和計劃工作。

　　研究問題領域：對問題和專業術語進行理解，通常借助于系統上下圖文工具，下圖是門診掛號系統上下圖文。在上下文中，可以比較清楚地了解系統必須響應哪些輸入、生成哪些輸出。對于列出的問題，不能僅停留在表面認識，而應該詳盡分析問題的原因和結果。

　　業務流程分析：對于關鍵醫療業務流程進行分析，例如掛號流程、急診分診流程、檢查預約流程等，需要注意的是業務流程分析主要依賴于問題領域知識，不易涉及太多技術細節。業務流程分析結果，通常用數據流程圖來展示，如下圖所示：

　　制定系統改進目標和計劃：系統目標和項目計劃的制定，要基于對系統范圍、問題和機會的正確理解認識。系統目標是制定一個評估準則，對系統的任何改動都按照該準則來度量，包括預期和約束條件。

　　舉例如下。

　　第一，系統預期：

　　高峰期門診問診響應時間低于1分鐘；

　　系統年宕機次數不高于兩次且宕機恢復時間期限在10分鐘內；

　　系統支持市醫保和跨省醫保結算；

　　……

　　第二，約束條件：

　　系統必須要2022年12月28日之前上線運行；

　　系統總研發成本少于500萬；

　　系統必須與其他系統實現數據互通；

　　系統按照電子病歷五級標準；

　　……

　　根據系統目標和約束條件來制定和調整項目計劃，始終堅持以系統目標為項目計劃導向原則。最終，可以生成一個簡要的系統改進和建議報告如下圖所示：

　　（3）需求分析階段

　　用戶需求分析是在分析存在的問題基礎上，確定哪些是希望通過開發新的軟件所要解決的問題，其目的是明確軟件開發的目的和工作任務。

　　需求分析是非常重要的工作，需求分析的主要工作是將系統開發工作的目標轉化為系統的功能需求和非功能需求：功能需求是軟件開發人員，提供什么樣的功能，滿足用戶的業務需求；非功能需求是軟件系統提供的應用軟件的質量上的要求，保護應用響應時間，用戶界面友好性，以及信息保護和安全等方面的需求。

　　需求分析不是記錄下用戶對需求的描述，而是從用戶業務需求中，抽象出軟件實現應用目標，應用程序所實現的輸入、輸出、過程和存儲的數據的形式定義。比如患者建檔輸入為患者基本信息，輸出為患者檔案信息。通常在需求分析時，采用用例建模工具來描述業務需求。關于系統需求分析，是一個非常復雜的工程，后續將專門撰文介紹。

　　（4）軟件邏輯設計

　　系統分析需要創建一個系統模型，也就是系統建模。邏輯設計階段采用系統模型進一步記錄業務需求，系統模型包含了數據結構、業務流程和用戶接口等內容。邏輯設計從系統的角度，驗證了需求和系統目標的正確性。關于邏輯設計，后續將撰文詳細介紹。邏輯設計階段，最終可生產一個系統業務需求陳述文檔。

　　（5）方案選擇決策階段

　　關于系統問題和需求目標，可能有多個解決方案。決策分析的主要任務是，分析候選方案，并根據分析結果推薦最佳方案。在分析候選方案時，盡可能的要求系統關鍵確定人員（比如分管院長、業務科室主任）參與。系統分析人員向醫院相關領導詳細介紹和描述各方案優缺點，然后聽取醫院方人員建議。必要時，系統分析人員可發表指導性和建設性意見。

　　在系統分析時，有必要做價值評估工作。特別是要注意項目所代理的機會有哪些，在哪些技術方面可能會有創造性的突破，能否展現公司或者醫院信息部門的技術實力，對于醫院信息部門后續的發展規劃，有哪些積極和消極的影響。

　　4 醫療系統分析的特點和難點

　　醫療行業與其他行業相比，有其特殊性，如業務的復雜性和業務管理高標準要求等。系統分析需要搞清楚系統需要提供的功能和解決的問題是比較困難的，主要體現在下述幾個方面：

　　（1）臨床醫學與IT技術是兩個差距非常大的專業，因而系統分析工程師在與醫院用戶進行調研溝通過程中，容易出現理解和溝通障礙。醫院用戶可能很難理解系統涉及的復雜流程，導致系統分析工作面臨很大的困難。

　　（2）醫療業務的復雜性，是醫療系統分析工作的另一個巨大挑戰。特別是在目前國內醫療機構在管理上尚未嚴格的統一標準，特別是大型醫院，有很多個性化特色需求，這些因素極大地增加了醫療系統分析工作的復雜性。在醫院內部，日常業務開展非常繁忙。特別是大型醫院，其工作人員同時兼臨床、科研和管理工作，能夠參與系統分析調研工作的時間有限。因而，系統分析工程師在開展工作時，要特別注意方式技巧，根據用戶的工作狀況，合理的安排時間規劃。

　　（3）醫療行業的封閉性，是醫療系統分析工作面臨的一個非常嚴重的困難。通常情況下，非醫療行業從業人員，甚至非本醫療機構工作人員，很難對醫療機構內部業務管理流程有了解和認識，導致在開展系統分析工作時，很難有前置資料了解問題和用戶需求，只能一步步事無巨細進行實地用戶調研。

　　當前，醫院信息系統軟考開發依然存在很多問題，比如技術實力欠缺、開發過程簡陋等。為確保醫院信息系統軟考項目的成功，有必要開展系統分析工作。在具體項目開展時，不一定嚴格按照文中所述步驟，但基本的范圍定義和問題分析等工作還是做扎實。

　　作者簡介

　　吳坤，計算機專業碩士，華中科技大學同濟醫學院附屬同濟醫院信息中心軟件工程師。專業計算機程序員，國內在醫療行業積極推廣IT技術的青年工程師和技術踐行者，熱衷于以信息技術提高醫療行業服務質量和改善患者就醫體驗。