【正文】 對影響突出的數(shù)據(jù)層進行從業(yè)務到理論的深入分析，從分論證，得到完整可行的數(shù)據(jù)層規(guī)劃，同時進行實施，實施時要充分考慮新老數(shù)據(jù)的交替，保證老系統(tǒng)的正常運行。同時，可以在多個數(shù)據(jù)標準之間進行術語的映射，以實現(xiàn)跨越不同標準的數(shù)據(jù)轉換。并且，數(shù)據(jù)綁定的實現(xiàn)方式使得系統(tǒng)可以適應數(shù)據(jù)標準的迅速變化。 能把衛(wèi)生部 EHR/EMR數(shù)據(jù)標準落地，同時兼容多種不同的數(shù)據(jù)標準 衛(wèi)生部發(fā)布的 EHR/EMR 數(shù)據(jù)標準是關于數(shù)據(jù)元的標準。 基于 HL7 V3 RIM 的數(shù)據(jù)建模，和基于 IHE的系統(tǒng)結構 系統(tǒng)應基于 HL7 V3 RIM來建立自己的核心模型。這使得系統(tǒng)之間的耦合足夠松散，同時易于集成。這樣，同樣的一份臨床數(shù)據(jù)，就可以按照不同的標準進行輸出，達到最終的區(qū)域共享的目的。結構化的存儲模型設計，應該支持將模型中的最小結構化單元直接綁定到各種標準。 E. 能夠將臨床數(shù)據(jù)中的最小結構單元直接綁定到各種國際標準或行業(yè)標準。 臨床數(shù)據(jù)滿足脫機使用才能很好的實現(xiàn)未來交換和傳輸?shù)男枨?，例如電子病歷可以脫離電子病歷系統(tǒng)環(huán)境獨立瀏覽，為將來電子病歷最終實現(xiàn)“數(shù)字病案室”、“區(qū)域醫(yī)療病案集中歸檔”、“個人健康記錄”奠定必要的信息轉移基礎。醫(yī)生日后的修改和補充都是在病歷上進行的，用于科研的內容很難再反饋到數(shù)據(jù)庫 中，導致大量的科研用的內容數(shù)據(jù)和真實的病歷數(shù)據(jù)不一致，從長遠的臨床數(shù)據(jù)應用來說是致命的，也就失去了科研的意義。例如電子病歷編輯器在制作模板時能夠設置病歷科研所需的數(shù)據(jù)項，保證這些數(shù)據(jù)能夠始終存在，同時按照 科研的要求只能做選擇、按格式錄入或對輸入的數(shù)據(jù)能做必要正確性檢查，滿足科研需求。 B. 能夠適應科研數(shù)據(jù)的要求。模型要能適 應這種結構上的變化，能夠支持新的結構類型并能保持歷史結構。 由于醫(yī)學技術的發(fā)展，會不斷地有新的內容結構增加到病歷中。 數(shù)據(jù)層 應 能支持臨床數(shù)據(jù)的結構化存儲。 而 LINQ（ Language INtegrated Query）則在 .NET語言中集成了查詢的 數(shù)據(jù)訪問模型，使得其對多種數(shù)據(jù)源的做到了一致性的訪問。 LINQ集成的數(shù)據(jù)訪問模型。 項目名稱： 普寧市人民醫(yī)院采購醫(yī)院信息系統(tǒng)招標項目（二期） 招標編號： 07241301D11N1544 24 再比如可維護性，假設出于性能優(yōu)化的考慮，需要對存儲模型進行更改（比如把大表分拆為小表等），也只需要修改存儲模型和映射層，而不需要對概念模型、數(shù)據(jù)類或應用程序代碼進行更改。 設計良好的軟件基礎架構可以采用這種方式來提高系統(tǒng)的可移植性、可擴展性、可維護性。同樣，一個概念模型 /邏輯模型可以映射到多個存儲模型。開發(fā)人員可以使用可映射到各種存儲模型（例如，可能在不同的數(shù)據(jù)庫管 理系統(tǒng)中實現(xiàn)）的一致的應用程序對象模型。對于從對象模型到關系模型的映射，稱之為 OR映射（ ObjectRelationship Mapping）。 在這種情況下，現(xiàn)有解決方案只能通過將面向對象的類和屬性映射到關系表和列來嘗試彌合這種通常稱為“阻抗不匹配”的差異。雖然類的組織通?？杀容^接近地反映出關系數(shù)據(jù)庫表的組織，但是擬合程度并不完美。 以絕大部分廠商所采用的關系存儲模型為例，其與作為對象模型的概念模型、邏輯模型之間往往存在巨大的差異。還具有良好的可擴展性、對象地址無關性，支持 HTTP、 SOAP、 TCP、 MSMQ、命名管道多種 endpoint。 WCF支持分布式事務，具有優(yōu)良的跨平臺交互性（支持強類型和無類型消息： .程序可以共享自定義類型；其他平臺的軟件可以使用松散類型的 XML流），采用基于特性的編程方式，廣泛支持WS*系列規(guī)范，它是在 SOA的基礎上構建，很多概念和 Web Service的概念直接對應。 新的軟件基礎架構需要基于 HL7 （ RIM， Reference Information Model）構建核心 的領域模型，因為其模型源自 HL7 V3 RIM，所以不但能很好地貼合醫(yī)療領域的內在規(guī)律，而且具有良好的抽象性，能夠適應軟件的不斷變化和發(fā)展。 邏輯層改變以前功能驅動的工作模式，轉而采用了模型驅動。對比而言，在很多傳統(tǒng)的程序設計中，很多地方需要用到患者信息的時候不管別的地方有沒有就訪問數(shù)據(jù)庫，不僅效率低下、代碼冗余，而且還頻繁地訪問數(shù)據(jù)庫服務器、降低了 系統(tǒng)性能。 在 HIS 內部的各個系統(tǒng)之間，某些場景使用 HIS Service，能提高系統(tǒng)的使用效率。并且，這種封裝是不需要對原有的 HIS系統(tǒng)做任何改動的。因為某個方法所需的全部數(shù)據(jù)都以參數(shù)形式傳入該方法中，所以這些方法都被視為獨立方法。粗粒度接口 公開一組相對較小的獨立方法。 如果使用公開細粒度接口的對象，則會大大影響應用程序的性能，這是由于細粒度接口要求跨進程和網絡邊界進行多次方法調用。 許多面向對象的設計做法通常傾向于設計帶有細粒度接口的對象，由于這種細粒度特性，必須調用大量方法才能實現(xiàn)所需的結果。在同一個應用程序內部，使用 DLL二進制方式調用的 HIS Service，而不是基于 SOAP和 XML的 Web Service，有利于提高程序的運 行效率和性能。而相互獨立的服務劃分，能夠降低系統(tǒng)的復雜性、提高系統(tǒng)的可維護性。 HISService是為了實現(xiàn) SOA架構而準備的，從邏輯上來看，它就是 SOA架構中所指的“服務”，而從實現(xiàn)技術上來看，把 HIS Service轉換為 Web Service也是一件非常容易的事情（很容易把服務對象的 DLL封裝成為 Web Service）。它有別于 Web Service以及與其相關的 SOAP、 WSDL、 WS*、XML 等一系列復雜技術， HIS Service 仍然是一個 DLL，但不是通過 SOAP而是通過二進制的方式調用。并且按照 IHE規(guī)范，構建可互操作的、易于進行異構系統(tǒng)集成的 HIS組件。而其中的 activity的概念和以 Act為核心的 HL7模型又是一脈相承的。 采用 WF（ Windows Workflow Foundation）工作流技術，適應應用流程的迅速變化。通過 XAML創(chuàng)建專業(yè)級的用戶界面，界面與邏輯代碼完全分離，系統(tǒng)可以象 WEB應用程序一樣按頁面構造，并在頁 面之間導航。 表示層應能創(chuàng)建想象得到的任何包含 2D/3D、視頻、音頻、動畫、富文檔視圖等內容的界面。隨著層次越分越多，各層的功能越來越單純，系統(tǒng)架構越來越靈活，不同模塊之間的耦合越來越松散、系統(tǒng)的可擴展性可維護性越來越好?？紤]到該項工程的風險，以及 用戶 實際存在的問題，該項目工程在設計規(guī)劃時依照完整方案設計，具體實施分為兩個周期進行，以最小風險 完成該項目。 五、 軟件基礎架構改造（ 1期） 軟件基礎架構系統(tǒng)升級的目的在于為醫(yī)院今后的應用系統(tǒng)開發(fā)搭建一個先進的、開放的、標準化的軟件基礎技術架構，以滿足基于該基礎架構所開發(fā)的應用軟件的靈活性、可維護性、可擴展性、標準化、規(guī)范化等方面的要求。 互聯(lián)互通及共享 電子病歷平臺全方位覆蓋醫(yī)院所有業(yè)務，使醫(yī)院內部信息得以互聯(lián)互通以及有關數(shù)據(jù)的共享和交換。 4. 實現(xiàn)結果： 集成度 建設一個以電子病歷為業(yè)務核心的醫(yī)院信息集成平臺。 改善電子病歷查詢管理功能，增加模糊查詢，能按條件查詢。 整合電子病歷外部數(shù)據(jù)接口、減少數(shù)據(jù)冗余，提高接口速度。 3. 升級要求： 參照衛(wèi)生部《醫(yī)院 信息系統(tǒng)基本功能規(guī)范》、《電子病歷系統(tǒng)功能規(guī)范（試行）》、相關行業(yè)標準等要求、結合本院實際使用需求對存在的主要問題進行改造。 查詢功能可用的條件較少，僅限于住院號碼、病人姓名等。這兩套系統(tǒng)沒有整合在一起，醫(yī)療信息無法有效交換、共享 數(shù)據(jù)接口繁雜；眾多的數(shù)據(jù)接口導致維護任務繁重，數(shù)據(jù)交換差錯較多。 根據(jù)臨床業(yè)務規(guī)范和實際應用需要，臨床信息中各業(yè)務域的信息內容分別由若干相關業(yè)務活動記錄有機組合、抽取而成，并具有一定的靈活性和可擴展性，以適應醫(yī)療服務改革發(fā)展的需要。 臨床信息的信息內容主要來源于醫(yī)療機構在為患者（或保健對象）提供臨床診療和指導干預過程中產生的各類醫(yī)療服務工作記錄（統(tǒng)稱為業(yè)務活動記錄）。主要包括：出生醫(yī)學證明、死亡醫(yī)學證明、傳染病報告、出生缺陷兒登記等。 轉診（院）記錄 指醫(yī)療機構之間進行患者轉診（轉入或轉 出）的主要工作記錄。 （ 9）知情告知信息：與門診知情告知信息相同。 （ 7）出院記錄：無子記錄。 （ 6）住院護理記錄：包括護理操作記錄和護理評估與計劃兩部分。 （ 5）住院治療處置記錄：包括一般治療處置記錄和助產記錄兩部分。 （ 3）住院病程記錄：包括首次病程記錄、日常病程記錄、上級查房記錄、疑難病例討論、交接班記錄、轉科記錄、階段小結、搶救記錄、會診記錄、術前小結、術前討論、術后首次病程記錄、出院小結、死亡記錄、死亡病例討論記錄等。其 中包括的子記錄分別為： （ 1）住院病案首頁：分為住院病案首頁和中醫(yī)住院病案首頁。 （ 6）知情告知信息：指醫(yī)療機構需主動告知患者和 /或其親屬，或需要患者（或患者親屬）簽署的各種知情同意書，包括手術同意書、特殊檢查及治療同意書、特殊藥品及材料使用同意書、輸血同意書、病重（危）通知書、麻醉同意書等。 項目名稱： 普寧市人民醫(yī)院采購醫(yī)院信息系統(tǒng)招標項目（二期） 招標編號： 07241301D11N1544 20 （ 5）檢查檢驗記錄：分為檢查記錄和檢驗記錄。 （ 3）門（急）診治療處置記錄：指一般治療處置記錄，包括治療記錄、手術記錄、麻醉記錄、輸血記錄等。其中包括的子記錄分別為： （ 1）門（急）診病歷：分為門（急）診病歷、急診留觀病歷。 （ 4）醫(yī)療費用記錄 指患者在醫(yī)療機構歷次就診所發(fā)生的醫(yī)療費用摘要信息。 （ 2）基本健康信息 包括現(xiàn)病史、既往病史（如疾病史、手術史、輸血史、用藥史）、免疫史、過敏史、月經史、生育史、家族史、職業(yè)病史、殘疾情況等。 根據(jù)臨床信息的基本概念和系統(tǒng)架構，結合衛(wèi)生部、國家中醫(yī)藥管理局關于《病歷書寫基本規(guī)范（試行）》和《中醫(yī)、中西醫(yī)結合病歷書寫基本規(guī)范（試行）》相關要求，臨床信息的基本內容由：病歷概要、門（急）診診療記錄、住院診療記錄、健康體檢記錄、轉診（院）記錄、法定醫(yī)學證明及報告、醫(yī)療機構信息等七個業(yè)務域的臨床信息記錄構成（注意這只是臨床信息各類記錄的最小集，實際醫(yī)療業(yè)務的輸出可以超出這個范圍）。 四、 電子病歷整合升級 電子病歷作為醫(yī)院的一種最常用的系統(tǒng)，為醫(yī)院管理病人病歷，規(guī)范醫(yī)生病歷書寫規(guī)范，快速調取病人歷史檔案提供了強有力的支持。 5. 服務器平臺 及客戶端平臺要求 : 系統(tǒng)支持在 Windows Server2020/2020/2020平臺上運行，要求采用當前主流的大型數(shù)據(jù)庫平臺，如 :SQL Server,Oracle,DB2等。采用如防火墻、路由器等網絡設備。 1) 保證數(shù)據(jù)上報的網絡通暢，數(shù)據(jù)及時上報。 4. 項目網絡要求： 數(shù)據(jù)上報軟件使用廣域網進行數(shù)據(jù)上報，同時又 應 連接醫(yī)院內部局域網，為抵御外部攻擊及病毒感染，內部信息外泄及其它網絡危害。 項目名稱： 普寧市人民醫(yī)院采購醫(yī)院信息系統(tǒng)招標項目（二期） 招標編號： 07241301D11N1544 19 3) 數(shù)據(jù) 接口準確可靠高效， HQMS 系統(tǒng)從醫(yī)院各信息系統(tǒng)抽取數(shù)據(jù)時應將對其它系統(tǒng)的影響降到最低。 3. 項目軟件要求： 1) 采用成熟可靠的大型關系型數(shù)據(jù)庫，避免因基礎系統(tǒng)缺陷引起額外風險。 4) 能夠準時、精確、快速的將數(shù)據(jù)導出成 CSV格式文件，以備上傳。在網絡環(huán)境下，需要使用多種技術手段保護中心數(shù)據(jù)庫的安全。 2. HQMS建設目標： 1) 數(shù)據(jù)的抽取、收集 應 完整、準確、快速，數(shù)據(jù)的編 碼 應 與 HQMS的技術接口要求的編碼標準相匹配。數(shù)據(jù)校驗規(guī)則 27條，數(shù)據(jù)對接考核標準 16項。為配合衛(wèi)生部醫(yī)管司的醫(yī)院質量監(jiān)測系統(tǒng)的運行要求，普寧市人民醫(yī)院將使用 HQMS系統(tǒng)將出院病人的電子病歷病案首頁內容進行上報。 目前現(xiàn)狀 :HIS結合手工統(tǒng)計所需要數(shù)據(jù)。 實施“陽光用藥監(jiān)管系統(tǒng)”，對規(guī)范醫(yī)生用藥，實施全方位監(jiān)督，特別對處內容、治療費用和藥品種類 (抗菌藥、基藥、針劑 )等重要信息做到適時監(jiān)管，有利于預防醫(yī)藥購銷領域商業(yè)賄賂，有效提高服務質量，降低患者醫(yī)藥費用。 二、 陽光用藥電子監(jiān)察系統(tǒng) 為貫徹落實《廣東省醫(yī)療機構陽光用藥制度實施意見（試行）》，實現(xiàn)醫(yī)生開方用藥、藥品使用的規(guī)范化、數(shù)據(jù)化和網絡化，對醫(yī)生處方用藥進行信息公開以及在線追蹤監(jiān)控，從而實現(xiàn)對醫(yī)療機構非常態(tài)化用藥現(xiàn)象的及時發(fā)現(xiàn)、預警提示、評價分析、糾正改進的全過程， 最大限度地對不合理用藥進行及時干預，促進醫(yī)務人員廉潔從業(yè)。 1疑似病歷搜索 。 1細菌耐藥性監(jiān)測： 根據(jù)衛(wèi)生部多重耐藥菌監(jiān)測規(guī)范要求，監(jiān)測微生物室各病原體檢出情況 。監(jiān)測的天數(shù)、同時發(fā)病的人數(shù)等都可以由用戶自己設置。相關報表有按科室匯總、按關聯(lián)操作匯總、接工別進行匯總等。相關報表有按科室匯總、按關聯(lián)操作匯總、接工別進行匯總，可以從多個角度分析職工針刺傷的情況。相應的報表有按科室匯總報表、按疾病系統(tǒng)分類匯總報表、按易感因素分類匯總報表、病原體與抗菌藥物情況統(tǒng)計、抗菌藥物使用情況、抗菌藥物使用劑統(tǒng)計等。 環(huán)境衛(wèi)生學監(jiān)測 ：由檢驗科人員或院感工作人員錄入醫(yī)院消毒衛(wèi)生學監(jiān)測的檢驗結果，軟件可對監(jiān)測結果自動評價，并打印監(jiān)測報告單和各類統(tǒng)計圖表和報表。 高危