第一篇：山東省信息扶貧綜合服務平臺建設方案

山東省信息扶貧綜合服務平臺建設 建議

為貫徹落實《山東省扶貧開發領導小組關于印發<全省脫貧攻堅專項實施方案>的通知》（魯扶貧組發[2016]3 號）中《山東省信息化建設扶貧實施方案》提出的目標任務和工作措施，結合新形勢下的信息扶貧工作重點，我們提出建設山東省信息扶貧綜合服務平臺。

1.建設目標 當前扶貧工作進入新的攻堅期，扶貧工作存在著機制宣傳不到位、手段單一、監管效果不佳、資金監管落后、人員管理考核機制與激勵機制不足等問題。且貧困人群存在多種致貧原因，地區幫扶人員與信息員無法精準、有效的對貧困戶進行真實幫扶。

創新扶貧方式，加快推進特殊困難區域發展與扶貧攻堅，落實省信息扶貧工作，建議以網絡技術和大數據技術為支撐，建設山東省信息扶貧綜合服務平臺。

平臺覆蓋全省 17 地市，以各地基礎設施建設為基礎，運用互聯網+、大數據等手段，科學精準的統籌各地扶貧資源。在協助管理工作的基礎上，與公共信息平臺及民生服務平臺關聯，增加民生服務功能及電商功能，為貧困戶的生活提供幫助。

2.建設思路平臺對政府管理者、地區扶貧人員、信息員、社會其他扶貧力量的扶貧工作進行協助。建設過程中打造公共信息服務體系，按照市場機制整合個體工商戶以及互聯網平臺型企業線下服務站點等資源。

幫扶人員作為扶貧工作主心骨,按各自職責對特定貧困戶進行實際幫扶;信息員作為平臺運營的支撐人員，工作重心偏向于平臺電商維護、信息采集上傳和資源整理使用，從平臺角度為扶貧工作提供幫扶，協助政府推廣扶貧信息化。

在政府給予的大力支持下，實現每個重點扶貧村確定至少 1名信息員，擔任平臺站點的管理員，把各類信息發布到平臺，配合地方幫扶人員為貧困戶提供幫扶。

通過幫扶人員及信息員從各地實時、真實的搜集信息，上傳平臺，為政府管理者、幫扶人員及信息員提供信息協助。帶動貧困戶脫貧、消費，進而吸引商家入駐，擴大社會資源扶貧力度并為平臺建設運營點，實現平臺良性自循環并向貧困區提供區域個性化幫扶。

3.建設 內容 3.1.平臺搭建平臺建設概括為“一平臺、一張圖、六個庫、高精準、全周期”的特點。

一平臺是指“山東省信息扶貧綜合服務平臺”的搭建，平臺從多角度多場景為省信息扶貧工作的順利進行作網絡信息支撐，向政府管理者、各地扶貧管理員、各地信息員、社會其他扶貧力量、貧困戶提供有效協助。

一張圖是指“扶貧地理信息圖”，通過該圖可隨時隨地掌握省內各區貧困人口分布、構成、致貧原因、貧困現狀等。

六個庫是指人員檔案庫、扶貧資源庫、業務數據庫、公共信息平臺數據庫、地理信息庫及電商資源庫，通過對采集到的各類數據多維度分析，精準識別貧困人口，精確定位致貧因素為管理人員和各類信息員工作提供有力支撐。

高精準是指通過大數據分析，可以快速實現“各地信息員與貧困人員”、“扶貧措施與致貧原因”、“貧困村間資源供需”的高精度匹配，實現救助資源的精細化釋放。

全周期是指圍繞貧困戶，將各類幫扶進行跟蹤記錄，實現貧困人員脫貧的全過程留痕存檔，為今后扶貧工作提供指導。

3.2.平臺架構 服務器 存儲設備 網絡設備感知設備 安全設備人員檔案庫 扶貧資源庫 業務數據庫 地理信息庫電商數據庫 其他數據庫政府管理者 幫扶人員 幫扶對象任務對象信息幫扶措施指導推薦橫縱向交流互動致貧原因分析幫扶效果跟蹤回饋扶貧信息論壇扶貧對象管理數據管理分析扶貧資源管理社情民意采集Web app 微信平臺扶貧對象 信息員 管理隊伍 個體商戶社會資源設施層網絡層數據層應用服務 層門戶層用戶層扶貧政策與管理規范體系信息安全與運維支撐體系扶貧工作業績考評體系其他資源VPN專用網 互聯網 物聯網 移動通信公共信息平臺數據庫信息員電子檔案系統信息發布系統工作管理考核職業培訓課程業績考核

特色村淘網上跳蚤市場農產批量商戶采購信息整理上報商戶誠信建設農產電商零售地區特產推廣

政策宣傳導讀網貨下鄉人才服務政策資金種植養殖技術培訓服務機構介紹用品互換

支撐層一張圖 工作流 績效監管 3.3.應用建設 3.3.1.協助政府管理 信息資源整合，將數據搜集、分析、整理，幫助政府管理部門更加準確的鎖定貧困戶，找準致貧原因，區分貧困類型，制定扶貧措施，集中各方力量，改善貧困戶的生活條件。

3.3.2.協助扶貧人員 幫扶 為地區扶貧人員的工作提供便利，從平臺獲取一些較為實際、切實可行的信息，方便扶貧人員有效的運用在工作中。設立獎勵制度，對于個人扶貧方法也及時上傳分享，使平臺成為有效的扶貧輔助工具。

3.3.3.協助信息員 工作 信息員的工作偏向于信息宣傳、電商維護、數據信息采集上傳、資源整理使用。平臺運維收益可體現到信息員福利收益中。

以電商為基礎，搭建特色村淘模型，充分發揮電商優勢，突破物流、信息流的瓶頸，服務村民，創新農業，促進消費，實現“網貨下鄉”和“農產品進城”的雙向流通功能。構建網上的村間跳蚤市場，為重點貧困村的生活消費提供支持。

3.3.4.協助貧困戶脫貧 平臺采取多途徑為貧困戶提供生產生活類培訓素材，在信息員的協助下，部分貧困人員了解、使用新技術，村民間脫貧資源共享并建設優質教育資源。

通過政策傾斜、補助、特殊營銷模式、商戶資源等多種方式，增加貧困戶消費能力。貧困戶自主選擇優惠購買等方式，在不增加貧困戶消費負擔的前提下，保障生活個性化需求。

3.4.運營 思路平臺運營點分信息服務模塊、電商村淘模塊、推廣合作模塊。

信息服務模塊：信息員充分了解本村可以輸出的項目，比如勞動人員、土地、養殖畜牧等，把信息發布到平臺，把需求企業、項目引入地區，村民資訊互通、機會共享，扶持創業青年。

電商村淘模塊：信息員將當地采入產出需求發布電商模塊，吸引商家入駐實現交易，通過村淘功能協助區域資源互換，提供更多扶貧資源，促進區域經濟發展。協助特殊的貧困區實現生活生產用品輸入、農產輸出、物品互換、農技培訓，并在低價甚至公益模式基礎上確保貧困戶使用。

推廣合作模塊：通過與第三方機構合作，針對農戶開設特色、實際、方便的資金業務，為村民收益、就業、豐收保駕護航。

信息員通過搜集村用戶建議提交平臺，使平臺不斷完善功能目錄，滿足各類用戶需求，從而保障政府管理下幫扶工作的順利、有效進行。

4.建設模式 針對此服務平臺項目的特點，以及國家對信息扶貧工作的指導意見，此平臺可采用三種建設模式：

1、政府投資，企業建設，政府運營。

2、政府購買服務，企業建設、運營。企業負責平臺的建設和運營，政府按照管理者、信息員使用人數等采用購買服務的方式。

3、企業投資、建設、運營，政府給予運營保障。企業負責投資平臺建設和運營，政府授予企業運營權并提供運營保障措施，保障平臺能夠在全省范圍內推廣使用。

建設模式需企業與政府相關人員詳細協商，保障平臺使用效果和雙方受益。

5.建設計劃 省信息扶貧綜合服務平臺搭建。2016 年，上線省信息扶貧綜合服務平臺；2017 年上線 17 地市信息扶貧綜合服務平臺二級平臺；2018 年，上線省扶貧工作重點村信息扶貧綜合服務平臺三級平臺。

省扶貧特色互聯網+電商體系搭建。2016 年，省信息扶貧綜合服務平臺上線特色電商板塊；2017 年，依托村綜合信息服務站和17 地市信息扶貧綜合服務平臺二級平臺，每個省扶貧工作重點村建立當地特色的電商服務模式；2018 年，結合信息扶貧綜合服務平臺三級平臺搭建及信息員進駐村綜合信息服務站，省扶貧特色互聯網+電商初步搭建完成；2020 年，省扶貧特色互聯網+電商在農業生產、農民生活中的作用日益顯現。

打造信息化扶貧示范鎮。2017 年，在推廣實施省信息扶貧綜合服務平臺、扶貧工作重點村綜合信息服務站和省扶貧特色互聯網+電商體系的同時，全力打造信息化扶貧示范鎮，在基礎比較好的鄉鎮打造公共服務平臺，為農民提供基于互聯網的農資購買、農技推廣、醫療健康、農產品銷售等服服務，不斷優化；2020 年，將信息化扶貧示范鎮向全省推廣。

6.保障措施 6.1.村綜合信息服務站 設立 保證每個省扶貧工作重點村都設立至少一個綜合信息服務站。服務站由信息員管理、維護，為村民提供信息指導服務，引導村民應用信息技術解決生產、生活中的實際問題。

6.2.扶貧隊伍 建設 組織建設一支信息員隊伍，保證每個省扶貧工作重點村都由一位有文化、懂技術、能服務的信息員進駐村綜合信息服務站。

信息員的選拔、培訓、管理、考核均實現規范化。對信息員的工作可實行獎懲化，拿出補貼或系統盈利點中部分盈利為信息員工作提供獎勵。

6.3.政策支撐 發布整理相關政策，通過平臺宣傳或組織學習等方式，將政策的支撐效果切實落實到扶貧人員切實工作中。針對區域采取幫扶策略，扶貧困、促銷費、惠民生。

6.4.平臺使用保障 平臺建設后，需政府協助確保平臺的使用，或劃入政府扶貧工具，以保證平臺上的信息及時、真實、有效，切實的通過信息化提升扶貧工作效果。

信息錄入：扶貧人員、信息員須將工作中信息數據及時、完整、有效錄入，保證數據信息的完整性真實性，保障數據分析的有效性。

文件上傳：平臺內上傳信息需各級人員工作提供支撐，切實保障宣傳和文件使用的效果。

營銷模式：平臺將設計符合當地實際情況的營銷策略，企業優惠需配合傾斜策略、政府補貼等方式，為貧困戶提供幫助。

資源整合：平臺需整合個體商戶、線下服務站、各方社會資源，為扶貧工作提供支持。

第二篇：物流信息服務平臺項目建設方案

物流信息服務平臺項目建設方案3

一、焦作物流業現狀分析

經過多年的積聚和發展，焦作市已形成了較為完整的產業體系，由此帶動了物流業的較快發展，物流業已成為焦作市服務業發展的主導產業之一。從貨運量方面看，公路貨運量占全市貨運總量的80%以上，公路主要貨源為煤炭及制品、礦物性建筑材料、水泥、化工原料及制品。

二、焦作物流信息服務平臺系統分析

物流信息服務平臺是以信息技術、網絡技術、通信技術為支撐，以物流信息的共享和交換為手段，以“信息服務網站”為表現形式和紐帶，通過聯接物流企業、工商企業、政金融機構、物流設備供應商等各類物流主體，有效整合各類物流信息資源，最終建成集成化的物流信息展示查詢平臺和物流行業服務窗口，以及網上虛擬綜合物流市場。

(一)物流信息公共服務平臺建設的必要性

1、消除物流信息孤島，實現互聯互通，提升綜合效率

通過平臺將獨立的物流業務系統、企業系統、等聯系起來，信息的協同促進了業務流程的協同，從而提升了綜合效率。

2、物流信息分布廣泛，需要公共平臺來實現信息流轉

根據焦作市特點，中小企業在企業總數中所占比例較高，這就使得物流供需信息源分布廣泛，這些信息源的聯通和信息流轉需要由一個公共平臺來進行統一的管理、匹配和協調。

3、信息平臺的建設可以完善物流信息服務體系

目前，物流企業的信息化普及率不高，需要建設公共平臺的物流信息服務體系來為物流企業提供服務。

4、有利于焦作物流企業轉型升級。目前焦作物流總體信息化水平較低，通過該項目的實施可以有效提升焦作物流信息化水平和管理效率。

(二)焦作物流信息服務平臺建設基礎

1、焦作市物流企業正處于向現代物流企業轉型的關鍵階段，這些物流企業對信息化的需求已較為迫切。

2、在新一輪產業結構優化調整中，省市政府均把物流業作為引領現代服務業發展的重要力量。

三、焦作物流信息服務平臺規劃方案

焦作物流信息公共服務平臺將按照“2+4+5”的規劃方案進行建設，具體內容包括：兩個核心定位、五大業務功能、五項公共服務。

(一)兩個核心定位

(1)信息展示中心：物流行業各類信息的集中展示中心。

(2)數據交換中心：根據規范標準，為物流行業業務信息提供數據交換服務，支持不同主體之間的數據交換、并與省際平臺實現數據互通。

(二)五大業務功能

平臺提供門戶網站、信息發布、信息查詢、數據交換四大業務功能。

(三)五項公共服務

平臺提供數字語音服務、結算保險服務、GPS增值服務、誠信評價服務、四項公共服務。

平臺將形成如下功能模塊規劃：

(一)公共信息模塊：形成一個面向物流企業、工商企業、行業協會、主管部門等行業相關企業和機構的權威信息、新聞資訊、招商招標信息發布與展示的平臺。

內容包括政府主管部門發布的信息，行業協會發布的信息，國家、省、市行業相關政策信息，國家、省、市行業新聞資訊信息，招商、招標信息，以及政府、協會、企業等之間的在線交流平臺與行業論壇等。

(二)物流信息模塊：支持通過網站、手機等各種方式進行貨運、倉儲信息的發布、展示與查詢;

并通過系統設置的匹配規則，對物流信息進行自動撮合匹配，提高物流企業的業務成交效率。

(三)數據交換模塊：通過各種交換接口的設置，能夠與省際物流信息平臺、省際物流數據交換中心、物流企業信息系統、工商企業信息系統、物流園區信息系統、國際物流信息系統等實現數據交換。

重點整合徐州港區內重點港口企業、物流企業數據。

(四)商機信息模塊：以信息超市的形式集中展示包括物流設備、物流保險產品、物流地產租售等服務于物流行業的業務產品信息。

(五)企業商務室：企業可通過平臺帳號方式登錄，并根據自身需要對平臺功能進行配置，從而搭建企業個性化的信息平臺。

(六)平臺系統管理：平臺的后臺管理系統。

(七)數字語音服務：通過數字語音信息綜合服務將客戶通過電話、手機的語音通信和短信，發布的供求信息、查詢、咨詢等服務請求、投訴或建議等，與整個公共服務平臺系統整合。

(八)結算保險服務：為物流業務運作的供需雙方客戶提供交易金融結算、代收代繳款、運輸貨物擔保和物流保險服務。

并通過引入保證金管理制度，保障物流業務運作各方的利益。

(九)GPS增值服務：提供公共的GPS增值服務，客戶可通過服務租賃的方式使用平臺的GPS服務功能。

其中，GPS服務功能包括車輛定位、車輛在途實時跟蹤查詢、司機實時聯絡、運行線路預警等。

(十)誠信評價服務：建立物流企業誠信評價體系，通過對物流企業基本情況、業務運作情況、結算情況、其他社會信用等綜合分析，給出物流企業的誠信評價。

第三篇：湖南大學校友綜合服務信息平臺技術方案

湖南大學校友綜合服務信息平臺

技術方案

目錄

1.項目背景 2.項目概述 3.項目建設原則

3.1.1.易用性 3.1.2.可控性 3.1.3.高效性 3.1.4.安全性 3.1.5.可擴展性

4.項目軟件需求描述

4.1.用戶權限管理

4.1.1.用戶權限組/角色的創建與分配4.1.2.用戶認證

4.2.校友信息管理

4.2.1.校友數據批量導入 4.2.2.校友走訪記錄管理 4.2.3.個人消息管理 4.2.4.消息發送和接收 4.2.5.人脈搜索 4.2.6.信息群發功能 4.2.7.校友信息查詢 4.2.8.校友信息去重 4.2.9.校友信息統計 4.2.10.數據標記功能 4.2.11.模板設計 4.2.12.校友信息卡面板 4.2.13.個人空間

4.3.校友組織管理 1 2 2 2 2 3 3 4 6 6 7 8 9 9 9 10 11

錯誤！未定義書簽。11 12 12 12

4.3.1.組織結構 4.3.2.組織管理員 4.3.3.地方校友會空間 4.3.4.學院校友會空間 4.3.5.班級空間

4.4.校友活動管理

4.4.1.活動組織 4.4.2.活動參與 4.4.3.活動分享 4.4.4.投票活動

4.5.校友服務

4.5.1.校友卡申請服務

4.6.后臺管理

4.6.1.日志管理 4.6.2.權限管理 4.6.3.數據備份管理 4.6.4.動態數據庫管理 4.6.5.系統字典管理

4.7.校友門戶頁面與欄目

4.7.1.網站首頁 4.7.2.部門概況 4.7.3.新聞中心 4.7.4.岳麓之星

4.7.5.合作辦學（產學研合作）4.7.6.校友組織（與社區數據同步）4.7.7.校友活動 4.7.8.校友刊物 4.7.9.校友愛心 4.7.10.校友服務

5.項目主機與軟件配置要求

5.1.主機硬件

5.2.WEB服務器的軟件布署環境 13 13 13 14 14 14 14 15 15 16 16 16 16 16 16 17 17 17 17 18 18 18 18 18 19 19 19 19 20

5.3.C/S《校友實名信息數據庫》軟件布署環境 20

6.6.1.6.2.非功能需求

性能需求 安全需求 21

1.項目背景

校友，從狹義上說，是同在一個學校學習、工作過的人；廣義上說，還可以包括為學校做出過貢獻的人。校友對母校會有一種天然的認同感，為我們稱為學緣聯系。而正是這種認同感與感情聯系使校友資源如同一座座寶藏，對高校的發展建設有著不可替代的重要作用。是高校工作的重要組成部分，有效的把校友資源整合起來，對高校的建設與發展具有重要的意義。而校友的人數是與年俱增的，是一種可持續發展的資源。

而學校總是處于“培養一批學子，丟失一批校友”的窘況之中，所以建設一個由全校統一、共享的校友信息數據庫與相關的網站、校友社區的校友綜合服務平臺用來管理、收集、聯絡校友資源是十分有必要的。

2.項目概述

湖南大學校友綜合服務信息平臺（以下簡稱平臺）將是一個全功能的信息平臺，將校友綜合服務與管理、門戶網站、交流社區有機的結合在一起。能過新一代信息技術充分發揮學校校友總會、各類校友組織以及校友個人等多方的能動作用，共同收集整理校友詳細信息，為學校提供一套完整的、動態的校友信息庫。并提供專業的校友網站、社區為校友服務，供世界各地的校友獲取母校信息、分享相關資訊，同時加強校友與母校之間、校友與校友之間的互動交流，增加校友對母校與校友組織的信賴度、活躍度，樹立學校品牌形象，提高社區認知。

3.項目建設原則

3.1.1.易用性

針對校友工作流程與數據特點，提供多種復雜邏輯智能模塊：校友智能認證、校友智能查重去重、校友關系自動查詢等。

系統提供高一致性的界面UI，用戶只需簡單培訓，甚至不培訓就能使用操作系統。

3.1.2.可控性

在系統中建立各類控制點，管理員可隨時進行戰略性調控。如：開放或關閉注冊功能、設置自動審核或人工審核等等。

3.1.3.高效性

提供多種數據導入收集手段，數據采集效率高；提供批量發送郵件、批量發送短信、數據批量模板打印等功能，系統應用效率高；采用動態數據庫技術，數據表、數據字段可自我維護，數據維護效率高。

3.1.4.安全性

數據庫備份機制、數據加密機制、言論過濾機制、數據操作歷史痕跡查詢等等。從最大程度上保證系統數據及言論的安全性及被泄漏的可能。

3.1.5.可擴展性

系統提供數據庫設計功能，能讓管理員即時進行數據庫基本信息升級，避免系統使用使用壽命超不過三年、有新需求就要重新開發的局面。

系統設計時預留對外接口，可與學校相關系統進行對接開發，為學校一體化信息建設提供支持。

4.項目軟件需求描述

湖南大學校友綜合服務平臺應由《校友實名信息數據庫》、《校友實名SNS社區》、《校友門戶網站》三個部分組成。

《校友實名信息數據庫》要求采用CS模式，方便學校控制客戶端的使用數量，防止校友實名數據流失；支持動態數據庫技術，適應信息時態性特性，延長系統的生命周期，確保學校投資價值。

《校友實名SNS社區》要求采用BS模式，方便校友認證登錄使用。校友數據要求與《校友實名信息數據庫》實時同步，達到一庫多系統的要求，方便學校統計采集校友數據。方便校友與母校，校友與校友之間的資訊共享，互助合作。

《校友門戶網站》要求設計風格簡約，排版層次清晰，界面友好人性。并能充分體現湖南大學千年學府的文脈傳承與人文特色。

4.1.用戶權限管理

4.1.1.用戶權限組/角色的創建與分配

系統提供可定制的，粒度可控的用戶權限管理功能。可以自定義用戶角色，為每一位系統用戶分配不同的角色權限。

權限組功能通過對系統菜單的使用權限與數據內容的瀏覽操作權限的劃分形成不同的系統權限組（用戶角色），在通過對用戶的角色分配產生不同級別的使用人員，比如：系統管理員、內容管理員、地方校友會數據管理員、班級管理員等。

不同的用戶權限可以對不同的數據集進行管理，比如： ? 工程學院數據管理員只能看到并管理工程學院的校友數據 ? 珠洲校友會信息管理員只能看到并管理珠洲校友會校友的數據信息

4.1.2.用戶認證

系統管理員先在社區后臺按不同時間段設定不同的注冊認證條件，比如：2000起入校的校友或在校教職工：使用學校統一身份認證注冊，輸入學（工）號、證件號碼(身份證號等)完成注冊。

2000年之前的校友用戶通過填寫自己的入學時間，學院、專業、班級、學歷信息與系統已有人員信息庫進行比對后智能認證。

其他或無法智能認證的校友：

1，用戶在社區中點擊注冊新用戶鏈接；

2，用戶進入注冊信息填寫頁面，頁面上需要用戶填寫的內容最少包括：用戶名，用戶注冊郵箱，用戶密碼，用戶密碼重新輸入。

3，社區后臺生成用戶審核信息，管理員審核后社區后臺自動生成激活鏈接，并將該鏈接通過Email發送到用戶注冊郵箱；

4，用戶接收激活郵件，并點擊激活鏈接完成激活，完成注冊； 5，在激活頁面，用戶輸入用戶名和密碼，完成激活。

4.2.校友信息管理 4.2.1.校友數據批量導入

系統支持批量導入校友信息數據，支持EXCEL、MySQL、MSSQL等格式的數據源。支持同名列名自動/手動匹配。

在導入時還提供查重功能，即通過用戶指定的多個字段進行智能比對，提示可能重復的校友信息數據。并支持一鍵合并功能，保證每一位校友在系統中的數

據唯一性。

4.2.2.與學校其它數據庫交換數據

系統具備與學校其它數據庫對接，交換數據的功能。系統可以將校友數據導出EXCEL，共享給其它系統使用。

系統提供可以和其它數據對接的數據讀取程序，學校需要對接的數據庫比如：迎新庫、學工庫、教務庫可提供數據庫權限或數據中間表，支持EXCEL、MySQL、MSSQL等格式的數據源。通過用戶指定的多個字段進行智能比對，提示可能重復的校友信息數據。并支持一鍵合并功能，保證每一位校友在系統中的數據唯一性。

4.2.3.校友走訪記錄管理

? 管理員記錄校友走訪信息，這些信息包括：時間，地點，目標校友，走訪類型等。走訪類型包括：校友來訪、出訪管理、參與育人信息管理、捐贈

與接收捐贈管理、校友活動管理、雜志訂閱、紀念品信息管理、電話聯絡管理、校友活動管理、生日祝福郵件。

? 管理員可以通過時間、關鍵詞、校友姓名等多種條件對走訪記錄信息查詢，這些查詢條件可以以邏輯運算符號（或，非，與）組合起來進行查詢。? 系統提供統一的管理查詢界面，使得管理員可以統一查詢管理用戶的走訪活動信息，這些活動信息由管理員手動輸入

4.2.4.個人消息管理

用戶可以對自己的發送信息和接收信息進行搜索和刪除等操作，前者的搜索條件包括：時間，發件人，收件人，關鍵字等；后者的操作只影響用戶個人信息頁面的顯示，真正的信息內容將一直保存，只有管理員才能進行刪除等操作。

4.2.4.1.說說

? 校友發布自己的動態與留言，并相互交流。? 說說需要支持發布表情 ? 支持相互評論與@功能。

4.2.5.消息發送和接收

? 用戶登錄后可以接收和發送消息；

? 可發送的消息包括：認證請求；加入校友分會組織的請求；將別的校友加為好友的請求；獲取校友服務請求；活動相關消息等，系統通知等。? 同時也可以接收相關消息。

? 用戶可以對消息進行搜索，分類，刪除等操作。

4.2.6.人脈搜索

? 通過校友名稱尋找搜索認識的校友 ? 能自定義校友分組

? 能查看我的關注與關注我的校友列表

4.2.7.信息群發功能

? 系統管理員可以選擇對多個用戶進行信息群發，發送媒介包括Email和短消息；

? 在Email與短消息群發中，支持標記功能，即管理員可以編寫一個單一內容的主文檔，然后系統可以自動插入標記代表的用戶信息（email地址，姓名等）生成最終的email或短消息發送給不同用戶。

? 已發送過的內容可以被保存為對應的模板以供用戶下次選擇使用。? 為了防止大量發送Email的行為被標記為垃圾郵件發送，因此系統需要合理安排Email發送的數量和頻度，并用多個郵件地址發送的方法規避風險。

4.2.8.校友信息查詢

? 系統提供校友信息庫查詢與管理功能。

? 管理員可以查詢校友的基本信息與附屬信息，前者是學校保存的基本校友信息，后者是校友在使用校友信息系統過程中增加的新信息，包括：履歷信息，活動參與信息，交往信息，捐贈信息等。

? 管理員可以使用組合關鍵字對校友信息庫進行查詢，也可以使用多個字段的組合條件（等于，小于，大于）進行查詢；查詢結果以表格格式導出。? 支持多色分類顯示查詢結果

? 支持動態列表功能，查詢列表的標題可以拖動分類與統計。列表標題用戶可自定義個數。

4.2.9.校友信息去重

系統可通過指定的一條或多條校友信息進行智能對比來進行校友信息查重功能，并可將重復的兩條或多條校友信息合并為一條。

4.2.10.校友信息統計圖

? 系統需支持自動將主信息中的字典字段生成統計圖表。比如按照校友所在城市生成校友城市分布統計圖、按照校友所在行業生成校友所在行業比例圖等。? 需支持餅圖，柱狀圖等多種統計圖表形式。? 生成好的圖表的可以被作為圖片導出

4.2.11.數據標記功能

系統可以對校友數據進行顏色標記，支持所有字典型字段，通過顏色標記，可以快速找到需要的信息。

4.2.12.模板設計

系統提供模板設計功能，可以設計校友胸卡、桌臺、簽到表等校友活動常用標簽與表格格式，并能與數據庫中校友信息相結合并進行套打。

模板設計支持標簽功能，在打印時可以自動帶入標簽所關聯的校友信息，比如校友頭像、名稱、單位、職位等。

設計并保存好的模板能通過模板文件進行共享。

4.2.13.校友信息卡面板

? 校友信息卡面板可以將列表形式的校友信息以卡片的形式展示 ? 卡片的版面布局可以由用戶按照工作習慣自己排版 ? 卡片的布局可以用布局文件進行共享

? 拖上卡片的列表字段的字段名可以由用戶按自己的習慣自定義命名

4.2.14.個人空間

校友的個人空間，校友間可以相互訪問。

內容包括個人相冊、文章、說說、創建或參加過的活動信息、組織信息、個人檔案、消息、所獲勛章、榮譽、積分值、最近訪客等。

個人檔案相關的私密信息默認為非公開，校友可以設置對校友、好友或所有人公開。

個人檔案以外的信息都是對校友公開的。

4.3.校友組織管理 4.3.1.組織結構

用戶按照學校的實際情況自定義學院、專業、班級、地方校友會，并可關聯學院、專業、班級之間的關系。

4.3.2.組織管理員

為每個組織指定一位或多位管理員（與社區配合使用）

4.3.3.地方校友會空間

提供各地方校友會的介紹性展示頁面，提供接口與地方校友會網站互連。系統后臺可以對地方校友會進行管理。

支持自定義LOGO功能，地方校友會空間管理人員可以自定義空間的LOGO，體現當地特色

支持聯系方式，地方校友會空間管理人員可以自己編輯發布地方校友會的主要聯系方式，方便當地校友聯系組織

支持地方校友會活動，地方校友會空間管理人員能發布本地的校友活動，無需主站管理員審批、發布。

4.3.4.學院校友會空間

提供各學院的介紹性展示頁面，提供接口與學院網站互連。系統后臺可以對學院進行管理。

支持自定義LOGO功能，學院校友會空間管理人員可以自定義空間的LOGO，體現當地特色

支持聯系方式，學院校友會空間管理人員可以自己編輯發布學院校友會的主要聯系方式，方校友聯系。

支持本院校友會活動，學院校友會空間管理人員能發布本院的校友活動，無需主站管理員審批、發布。

4.3.5.班級空間

班級按學院、年級進行自動分類列表，并能通過條件快速檢索；提供各班級的介紹性展示頁面。功能要求同地方校友會空間與學院校友會空間。

4.4.校友活動管理 4.4.1.活動組織

? 校友組織管理員或班級管理員可以活動本組織的活動。并由后臺管理員審核后才能發布并推薦到首頁顯示

? 普通校友可以自由申請活動，并由社區管理員審核后發布。

? 活動發起人可以發起活動，設定活動類型、活動主題/名稱、并設定活動時間，預定地點，活動簡介，報名截止時間等。? 活動發起人可以設定活動的日程安排信息。? 活動缺省都是需要報名參加。

? 活動發起人查看活動報名情況，并可以進行后續操作如向活動參與人發送相關消息提醒。

? 活動發起人可以對已經發起的活動進行修改，包括時間，地點等。也可以暫停或取消活動。活動信息修改后，告知總會，推送給用戶的活動通知 ? 活動管理員可以設置推薦或置頂某項已發起的活動。

4.4.2.活動參與

? 校友可以對某個活動設置報名。? 普通校友可以報名參加活動。

? 用戶報名參與活動，并得到審批后，可以在個人信息頁面接收活動發起人發送的相關消息和通知。

4.4.3.活動分享

? 參與活動的用戶可以針對活動發布評論。? 評論包括文字和圖片格式。? 用戶所發布的評論可以被回復。? 活動發起人可以進行活動圖片批量上傳。

? 活動發起人對活動評論擁有管理權限，可以修改和刪除評論信息。? 相關信息可以分享到公共社交平臺。

4.4.4.投票活動

活動了線下活動還可以是線上的投票，由系統管理員發起投票項目，投票可以定制不同的問題與答案類型（單選、多選、問答）。

投票可以在后臺進行管控與統計。

4.5.校友服務 4.5.1.校友卡申請服務

? 申請服務可以由普通校友或校友分會組織管理員發起。? 申請服務請求由系統管理員進行審批。? 審批結果作為信息發送給申請人。

4.6.后臺管理 4.6.1.日志管理

? 校友信息系統中所有用戶的所有操作都必須被記錄在日志系統中。? 后臺系統管理員可以對日志進行檢索和數據分析。

? 系統應該保留或開放基于用戶操作日志的數據挖掘功能接口。

4.6.2.權限管理

? 后臺系統管理員具備用戶權限分配和管理的最高權利。

? 后臺系統管理員負載系統管理員賬號的分配和管理，包括新賬號的分配，權限管理和賬號撤銷。

4.6.3.數據備份管理

? 系統可按管理員制定的備份計劃自動執行離線備份 ? 管理員可選擇完全備份或增量備份 ? 支持臨時的管理員手動備份

4.6.4.動態數據庫管理

動態數據庫管理功能可以讓用戶自定義數據庫上的表與字段，擴展信息對校友信息記錄的完整性。數據庫中的字段可以增刪。字段的長度、類型等只能在新增時設定，不能后期調整。調整后的庫表邏輯、數據庫完整性在用戶正確使用下是可以保證完整的。

? 需要支持新建一張數據表，并記錄為什么要建立這張數據表

? 需要支持在一張數據表中添加一個字段，并對這個字段的顯示名稱、類型、長度等屬性進行設置

? 需要支持刪除一張表，但已有字段的表在刪除前必須刪除所有的已有字段

? 新增的字段可以建立索引并排序

4.6.5.系統字典管理

系統管理員可以通過字典設計功能完善自定義系統中的數據字典。? 可以自定義字典的選項內容

? 選項內容可以通過編號進行索引排序

? 字典通過顯示名稱與數據表中的字典類型字段自動對應

4.7.校友門戶頁面與欄目 4.7.1.網站首頁

門戶首頁需要包括：新聞中心、湖大名師、校友之星、校友企業（產學研介紹）、愛心展示（跑馬燈）、捐贈感謝（字幕滾動）、友情鏈接（校友、校外）、校

友登錄、校友活動日歷推薦、校友卡介紹專欄、校友服務專欄、校友會官方微博、微信鏈接等來組成。

4.7.2.部門概況

部門介紹：介紹部門 機構設置：機構設置介紹 工作職責：工作職責描述

4.7.3.新聞中心

網站公告：校友會官方公告 校友新聞：校友相關新聞報道

4.7.4.岳麓之星

岳麓名師：介紹學校各學院的名師名導 岳麓之星：介紹湖大知名校友

4.7.5.合作辦學（產學研合作）

組織結構：介紹產學研平臺的組織結構

校友名企：介紹知名校友企業或與學校有產學研合作的企業 合作條件流程：介紹合作的參于條件與相關流程

4.7.6.校友組織（與社區數據同步）

地方校友會：各地方校友會的社區空間 學校校友會：各學校校友會的社區空間

班級校友會：各班級校友會的社區空間

4.7.7.校友活動

同步社區中的校友活動在網站中展示，校友可通過網站直接登錄社區并報名參與活動。

4.7.8.校友刊物

提供校友刊物的在線閱讀與在線下載服務

4.7.9.校友愛心

愛心展示：以圖片跑馬燈的方式來展示校友捐贈的實物

感恩回音：以文字+圖片的形式紀實報道校友的愛心感言或受捐人的感恩感言 捐助渠道：介紹校友捐助學校的渠道與方式

4.7.10.校友服務

學歷教育：介紹湖南大學本科、研究生、博士生教育

繼續教育：介紹湖南大學成人教育、自學考試、教育培訓、出國留學業務 校友福利：校友卡介紹（免費風景門票、校友設施租用優惠等等）、校友卡申請的條件與流程

湖大禮品：湖大校友紀念品訂購

校友資料異動服務：登錄社區，進入校友自己的個人空間，更新自己的個人信息

5.項目主機與軟件配置要求

5.1.主機硬件

處理器內存

Intel 8核處理器(2.7GHz, 20M L3緩存,130w)，16GB(2x8GB)1600MHz DDR3內存

硬盤

500G以上容量

5.2.WEB服務器的軟件布署環境

Windows Server 2000/2003操作系統

Apache Web服務器（支持Rewrite模塊和.htaccess）PHP版本5.1.6或更新的版本。MySQL(4.1+)Sendmail或者Postfix郵件服務器（可選）

5.3.C/S《校友實名信息數據庫》軟件布署環境

支持操作系統

Windows xp sp3/Windows vista/Windows 7 32bit 64bit/Windows 8 32bit 64bit操作系統.6.非功能需求

6.1.性能需求

系統容量：需支持50萬校友數據存儲，每個校友靜態數據5K字節；假設活躍校友比例10%，每個活躍校友每年新增5M字節數據量。在以上假設條件下，5年內數據庫容量需求：約1.5T

普通展示性用戶頁面加載時間小于2秒，后臺報表查詢頁面加載時間小于5秒。網絡帶寬需求：移動，聯通和電信的三網暢通訪問。

6.2.兼容性需求

校友門戶網站與SNS校友社區要求采用HTML5+PHP開發，并保證在IE7/8/

9、火狐國際版29.0.1/火狐中國版29.0.1以上版本、CHROME34.0.1847.137 m以上版本兼容運行，不會產生明顯的頁面變形或動態效果無效。

《校友實名信息數據庫》要求用C#.net語言開發，支持dotnet4.0。可以WIN XP/WIN 7/WIN 8操作系統上穩定運行。

6.3.安全需求

校友信息系統需要對常見的web攻擊手段進行防范，常見的Web攻擊分為兩類：一是利用Web服務器的漏洞進行攻擊，如CGI緩沖區溢出，目錄遍歷漏洞利用等攻擊；二是利用網頁自身的安全漏洞進行攻擊，如SQL注入，跨站腳本攻擊等。常見的針對Web應用的攻擊有：

緩沖區溢出——攻擊者利用超出緩沖區大小的請求和構造的二進制代碼讓服務器執行溢出堆棧中的惡意指令

Cookie假冒——精心修改cookie數據進行用戶假冒 認證逃避——攻擊者利用不安全的證書和身份管理

非法輸入——在動態網頁的輸入中使用各種非法數據，獲取服務器敏感數據 強制訪問——訪問未授權的網頁

隱藏變量篡改——對網頁中的隱藏變量進行修改，欺騙服務器程序

拒絕服務攻擊——構造大量的非法請求，使Web服務器不能相應正常用戶的訪問 跨站腳本攻擊——提交非法腳本，其他用戶瀏覽時盜取用戶帳號等信息 SQL注入——構造SQL代碼讓服務器執行，獲取敏感數據

第四篇：廣東社會扶貧信息平臺建設卓有成效

廣東社會扶貧信息平臺建設卓有成效

近期，在由國務院扶貧辦外資項目管理中心、華中師范大學減貧與鄉村治理研究中心組成的國務院扶貧辦專家組奔赴全國各省開展社會扶貧調研的過程中，廣東省扶貧開發協會探索實踐的社會扶貧參與機制及社會扶貧信息平臺建設引起了關注。

打造立體化扶貧信息平臺

“社會扶貧信息平臺能促進形成有效協調協作和監管機制，完善大扶貧工作格局，用新機制保障社會各界參與扶貧。它的建設是一項綜合性的系統工程，也是一個全方位、多角度、立體化建設的過程。”廣東省人民政府參事、省扶貧開發協會常務副理事長兼秘書長鐘韶彬介紹，從全省社會扶貧工作的實際需要和服務全省扶貧工作大局出發，省扶貧開發協會投入運作四年來，初步探索確立了以“廣東扶貧”為主題主線的立體化社會扶貧信息平臺建設。

鐘韶彬所介紹的立體化社會扶貧信息平臺，主要指“十個一”的社會扶貧信息平臺，即：建設一個廣東扶貧網，開通一條扶貧熱線，編發一份扶貧簡報，編輯一本扶貧專刊，出版一本扶貧圖書，編纂一套扶貧年鑒，制作一集扶貧電視專題片，拍攝一部扶貧電影，創作一組扶貧主題歌曲，配套一冊扶貧大事記，以此構建組織工作平臺，把政府和社會、國內和國外、東部和西部、生產和流通等方面的力量凝聚起來，共同致力于扶貧事業。同時，作為對外展示的窗口，全方位多角度集中反映廣東扶貧開發深入推進的新戰略、深化改革的新思路、全面發展的新局面、各項工作的新舉措及其所取得的重大成就。

至目前，廣東扶貧網和廣東扶貧熱線已經開通并持續發揮積極作用，廣東扶貧簡報按期編發，廣東扶貧文集第一卷《新時期扶貧開發百題問答》電子版已上傳廣東扶貧網，扶貧主題歌曲也已創作完成等待完善和后期制作。

扶貧需要互聯網思維

據鐘韶彬介紹，在“十個一”的社會扶貧信息平臺建設中，協會尤其注重網絡的力量。緊密配合廣東新一輪扶貧“雙到”工作需要，協會更是依托廣東扶貧網開發建設“廣東扶貧開發項目庫”、輔之以《廣東企業參與新一輪產業扶貧開發意向摸底調查表》，實現線上登記和線下書面登記的緊密結合，促進扶貧與被扶貧雙方的直接對接，為社會愛心人士、企業和組織搭建扶貧濟困、開發協作的平臺，改變了機關投入的單一模式，一定程度上調動了社會各種力量參與，實現扶貧濟困和扶貧開發效果、效益最大化。

“廣東扶貧網致力打造成為產業扶貧項目庫、愛心企業和愛心人士網捐點及志愿服務申報點。”鐘韶彬表示，產業發展是貧困地區、欠發達地區脫貧致富奔康的根本途徑，推動產業開發扶貧是協會的重要任務。依托廣東扶貧網，各類大中型企業尤其是行業龍頭企業、扶貧龍頭企業可以進行產業扶貧項目登記，駐村工作隊和貧困村均可查詢“產業扶貧項目庫”信息。根據網絡登記信息，協會適時組織召開產業扶貧項目對接會，促成產業對接、促進扶貧領域交流與協作。與此同時，愛心企業和愛心人士均可通過廣東扶貧網實現網上捐贈，也可通過廣東扶貧網申請注冊成為扶貧志愿者或組建扶貧志愿者分隊，參與、開展志愿扶貧服務。

“廣東產業扶貧項目庫是社會扶貧信息平臺建設方面的重要探索。”國務院扶貧辦外資項目管理中心社會扶貧處處長范明對此做法表示了肯定，同時寄望廣東積極為全國社會扶貧工作探索積極有益的新鮮經驗。

著力探索電子商務扶貧

“貧困地區農民擁有良好的農產品資源，天然無污染食品，卻缺乏銷售渠道，而在電商的幫助下，能夠拓寬這些農產品的銷售渠道，幫助貧困地區農民增加收入。”鐘韶彬認為，在協會探索開辟的十大扶貧產品銷售渠道中，扶貧產品的移動電子商務平臺便是其中很關鍵的一條。

鐘韶彬說，信息閉塞和勞動者素質低下是地區貧窮落后的主要原因，而電子商務在解決信息閉塞和提高勞動者素質方面效應明顯，從而使得“電商扶貧”成為可能。目前，協會也往此方向作積極探索，嘗試通過資助貧困農戶開網店、建立廣東扶貧農產品交易網等形式試水電子商務扶貧。

據悉，省扶貧開發協會作為省級公益扶貧組織，成立5年來，共組織實施扶貧濟困項目5個，累計籌集扶貧資金物資達到6億元，受益人群達30萬人次；實施開發扶貧項目6個，直接或間接帶動貧困村100個，關聯貧困農戶20萬戶；其他扶貧宣傳調研、承接政府職能轉移與購買服務、服務全省扶貧“雙到”取得一批成果。

2013年，協會被農業廳確定為全省模范組織推薦單位；協會實施的產業扶貧工程、銀發溫暖工程分別獲省財政“三農”專項資金和省福彩公益金重點支持項目，開展的廣東健康扶貧工程走進貧困村項目被評為廣東扶貧濟困優秀項目，受到省委、省政府表彰。鐘韶彬同志也因此獲得省扶貧先進工作者和全省首批“五星志愿者”榮譽。

第五篇：醫院信息集成平臺建設方案

信息集成平臺建設方案 建設需求

一個完善的醫院信息系統通常由上百個子系統組成，牽涉眾多的專業領域。這么龐大的系統需要非常專業化的軟件開發分工，整合不同廠商有特色的專業系統是醫院信息系統的發展趨勢，醫院信息化能夠取得成功必須保證各個系統的有效集成和數據的高度共享。然而這些系統通常是隨著醫院的發展需求逐步建設的，它們來源于不同的廠家，基于不同的技術，缺乏統一的信息交換標準，這些系統的集成整合已經逐漸成為醫院數字化發展亟待解決的主要問題。

系統集成平臺的構建主要面向兩個核心問題：一個是為各種醫療應用提供統一的醫療數據訪問服務，從而消除各種醫療應用系統與醫療數據中心的直接耦合性；另一個是為各種臨床信息系統提供系統集成服務，系統集成服務基于系統集成模型，通過HL7和DICOM等標準通訊協議為各種醫療應用系統提供集成服務，確保各個臨床信息系統在工作流整合的基礎上實現交互協作，從而以數字化的形式完成各項醫療業務。建設目標

系統間的整合、集成和擴展一直都是制約醫院數字化發展的主要障礙，由于不同廠商之間的產品不兼容，使得醫院整體信息化步履維艱。通過建設一個規范的系統集成平臺，在IHE、DICOM、HL7等國際標準的基礎上，制定覆蓋醫療所有業務流程的系統集成規范，開發基于規范的系統集成平臺，為遺留的、當前的以及將來的系統提供了一個統一且標準的數據交換和工作流協同的平臺。信息集成方法

信息集成方法有三，即應用集成、數據集成、界面集成，這三種集成方式各解決不同方面的問題。應用集成指應用程序之間實時或異步交換信息和相互調用功能，可以采用HL7消息，Web Service，CORBA，EJB，DCOM，RPC等標準，采用消息中間件，BPM等中間件實現；數據集成是指應用系統的數據庫系統之間的數據交換和共享，以及數據之間的映射變換，常采用ETL（Extract-Transform-Load）工具實現；界面集成含義是應用程序界面之間相互關聯引用合成，采用技術包括ActiveX插件、Portlet、IFrame等。

協同應用從早期單純的點對點接口方式，發展到現如今的集成平臺方式。各種方式中：

? 點對點接口方式的復雜性在于要和不同的系統建立1：N的接口，假定有N個系統相互之間需要建立接口，則接口數為 N*(N-1)/2。

? 集成平臺方式中，在N個系統需要進行應用協同的情況下，只需要開發N個適配器接口即可，減少了集成平臺的系統負荷。

由于醫院信息系統復雜性，我們根據不同的需求和應用場景，設計分別采用上述三種不同集成方法和手段進行信息集成。應用集成

和醫技輔診科室信息系統（如PACS/RIS、LIS、MUSE等）的信息集成，這種場景，信息交互的數據量不大，實時性要求不高，且各信息系統各專業廠商實現方式相差較大，采用基于集成平臺的應用集成方式是最優選擇。

集成平臺體系結構如下圖所示，集成平臺對外提供支持多種方式的集成服務：包括WebService服務、TCP監聽服務、文件監測服務、FTP服務、SQL監控服務等方式。

醫院信息系統在國際、國內廣泛采用的有一套集成規范，即：醫療健康信息集成規范（IHE）規范。IHE規范未定義新的集成標準，而是采用了“標準協調”過程推動基于工業標準的醫療IT系統互操作性。在IHE中，消息傳遞采用的是HL7（2.x版本)標準，影像傳遞采用DICOM標準。本集成平臺的集成嚴格參照該規范進行：信息集成平臺在進行消息時采用HL72.4標準進行消息傳遞、在消息內部傳遞DICOM StudyUID，以滿足后續DICOM圖像應用時的需要。

臨床信息集成用于對各臨床信息系統進行信息層面的集成事務處理。事務的定義參照IHE規范執行，消息的交互標準參照HL7 2.4標準執行。

集成平臺內部引擎本身由Ensemble集成平臺基礎之上進行二次開發而來，依托Ensemble本身對各種適配器的支持，集成平臺對外能夠提供多種接入服務方式：TCP、文件夾監聽、FTP文件監聽、自定義WebService、SQL監聽等形式。以更多接入方式進行各種不同方式集成各業務系統。

集成流程以業務流程可視化、可編輯化對外提供工作流程的制定與使用。集成引擎基于標準的業務流程執行語言（Business Process Execution Language）進行擴展應用，以描述交互應用。4.1 信息集成模塊與示例

信息集成組件主要由以下幾部分組成Business Service業務服務、Business Process業務處理、Business Operation業務操作，這幾部分共同作用下，將集成事務與消息傳遞進行完成。其中，Business Service主要負責進行消息的監聽與接收；Business Process負責全局的消息路由轉發、事務流程處理、消息匹配映射等工作職責；Business Operation負責將轉換完成、最原子化的一個操作，發送/調用信息集成的目標端。同時在三者相互作用下，消息的反饋準確的返回到Business Process，由Process來講反饋消息控制返回到消息發送方。示意圖如下（后續對該示例進行說明）：

4.1.1 業務服務監聽與接收

在當今醫院中，存在各種各種的醫療業務系統，醫療業務系統的多樣性，就將導致與其集成時，接入方式的多樣性，如部分系統已實現TCP的發送傳遞；部分已實現文本輸出等。集成平臺作為醫院信息系統的中轉、適配角色，在接入方式的多樣性成為必要條件。如前所述，在這方面，集成平臺允許的接入方式有：TCP、FILE、FTP、SQL、SOAP(WebService)、HTTP、MAIL等多種方式與相應的適配器。

在多種方式的接入過程中，將不同來源的消息通過統一的出口轉交給業務處理部分，由其進行路由住轉發、消息匹配映射、業務流程處理等相關的工作。

在本示例中，EMRS通過WebService的服務監聽（BS.WS.EMRWS）方式將消息內容傳遞進集成平臺，在通過驗證后，將該消息轉發給了業務處理模塊中的路由模塊。

4.1.2 消息路由轉發

在一些應用場景中，如電子病歷系統、重癥監護系統、HIS系統三者進行信息傳遞時，部分信息是需要三者之間交互的，而部分信息僅僅需要兩者之間交互，這在消息轉發路由時，需要有一定的控制，起到閘門的作用。如：HIS系統進行入院登記時，需要將病人的信息發送到電子病歷系統與重癥監護系統；而在重癥監護系統采集到病人生命體征信息時，僅僅將此信息發送到電子病歷系統即可。因此，在集成平臺中，引入消息路由轉發的相關模塊就顯得比較重要。

在本示例中，EMRCTLRouter這個消息路由者在接受到BS.WS.EMRWS的消息時，可能會轉發至EMRPlaceOrder、EMROrderCA、BadMessageHandle三個相關的處理模塊。而具體轉發至何模塊，由消息頭定義中的相關信息具體定義。消息路由者起到解析與轉發的作用。

4.1.3 事務業務流程處理

即時消息路由已經正確路由轉發了消息到準確的端點，但是在對應的端點內，還會有一些業務流程需要進行處理。如在EMRS下達一個新的Order的時候，需要的一定的情況下產生不同的業務流程分支：如該病人為門診病人或者住院病人，則有必要產生HL7 消息中的住院病人登記信息與門診病人登記信息：ADTA01與ADTA04。

在本示例中，BPEMRPlaceOrder的內部業務流程如下，每一個結點代表著一次邏輯處理過程：

4.1.4 消息匹配映射

在一些情況下，消息的傳遞方并無必要產生HL7標準格式消息的情況下，如EMRS與集成平臺為內部互調時，雙方之間提供預定義的WebService的接口，以快速的開發與進行集成。此時便需要在WebService中定義的消息格式與標準HL7消息格式之間進行著匹配轉換的工作。而該轉換工作的處理調用是由事務業務流程處理模塊來發起調用的。

4.1.5 終端消息發送

在進行正確的消息格式轉換與業務邏輯處理，此時的消息已經成為一個符合終端系統需要的消息格式。在事務業務流程處理中，會將此消息投遞給相應的終端系統。

在投遞消息完成工，事務業務流程處理模塊會進入等待反饋的狀況，等待終端系統反饋一個應答消息，以表示該消息在終端系統中被準確的處理。事務處理模塊收到該應答消息，并組織成發送端系統需要的消息格式，并作為應答系統，反饋至發送端系統。

4.2 集成事務處理流程規劃

上述主要針對集成平臺中各個模塊作用于應用場景進行了闡述，下面將以IHE規范中醫囑下達方醫囑執行的完整業務流程為例，進行完整的集成事務流程描述。該流程反應了普遍的醫囑流程，多數院內的醫囑流程都可參照執行，為醫院的信息系統集成方式提供良好的參考。本示例中，目標系統以PACS為例。上層應用程序新開申請單集成平臺PACS住院病人：發送ADT^A01消息/門診病人：發送ADT^A04消息響應ADT^A01消息/響應ADT^A04消息發送ORM^O01消息(control code=NW)響應ORM^O01消息對檢查申請進行安排后，發送SIU^S12消息響應SIU^S12消息查詢申請安排情況開始檢查時，發送ORM^O01消息(control code=SC Order Status=SC)響應ORM^O01消息檢查完成后，發送ORM^O01消息(control code=SC Order Status=CM)響應ORM^O01消息有圖像數據（圖像匹配）后，發送ORM^O01消息(control code=SC Order Status=DA)響應ORM^O01消息發送DFT^P03消息響應DFT^P03消息通知收費系統進行收費查詢申請檢查信息報告完成后，發送ORU^R01消息(OBX.11=P，初步報告)響應ORM^O01消息查詢申請檢查報告報告審核后，發送ORU^R01消息(OBX.11=F，最終報告)響應ORM^O01消息查詢申請檢查報告

另外，在院內經常出現的是在IHE規范中描述的：執行者醫囑流程，即由醫囑執行者（PACS系統中，為檢查科室）進行醫囑下達的過程并執行的流程。如下圖所示： PACS發送ORM^O01(control code=SN)消息時，消息中必須包含病人號（PID.3），也就是說病人已經掛過號。上層應用程序集成平臺PACS急診檢查登錄時，發送ORM^O01消息(control code=SN)發送響應ORR^O02消息(control code=NA)開始檢查時，發送ORM^O01消息(control code=SC Order Status=SC)響應ORM^O01消息檢查完成后，發送ORM^O01消息(control code=SC Order Status=CM)響應ORM^O01消息發送DFT^P03消息響應DFT^P03消息通知收費系統進行收費查詢檢查信息報告完成后，發送ORU^R01消息(OBX.11=P，初步報告)響應ORU^R01消息查詢檢查報告報告審核后，發送ORU^R01消息(OBX.11=F，最終報告)響應ORU^R01消息查詢申請檢查報告更新或合并病人信息發送ADT^A08消息，更新病人信息/發送ADT^A40消息，合并病人號響應ADT^A08消息/響應ADT^A40消息 數據集成

在實際業務應用中，日常醫院的HIS庫與ERMS庫之間存在較多需要高頻率、高性能要求的交互，如計價信息與藥品庫存等信息的實時共享等。針對這樣的應用場景，我們采用了ETL工具(GoldenGate)在數據庫底層進行的DB層同步方式。目前，醫院已經存在比較完整的醫療信息系統，這些醫療信息是以JW1H系統為基礎，增加醫院自己的需求發展而來。ERMS電子病歷系統是一個完整的獨立產品，他有他自己完整一套的系統架構和數據中心結構，而在系統架構和數據中心結構上醫院現有醫療信息系統和EMRS電子病歷系統都存在較大差異，這就決定了現有系統和EMRS電子病歷系統很難共用一個數據庫。可另外一方面，EMRS電子病歷系統和醫院現有醫療信息系統都是醫院系統不可分割的一部分，他們即有自己工作的重點，又有相互聯系和配合，只有相互無間的結合，才能快速、高效和正確地完成日常工作。應用EMRS電子病歷系統之后，醫院現有醫療信息系統的主要工作就會變成傳統意義上的HIS業務工作，如經濟管理、人員管理和物資管理等，而EMRS電子病歷系統主要完成以患者為中心的診療行為業務工作。

兩者之間存在著千絲萬縷的關系，以醫囑業務舉例，如EMRS電子病歷系統下達、轉抄和校對醫囑之后，醫院現有醫療信息系統需要完成對應的業務操作，如醫囑擺藥和醫囑收費操作等，這就需要在這兩個系統之間同步數據信息，而涉及到同步的醫療業務往往涉及的醫療各個環節，如診療、藥房、收費、人員管理等，因此需要信息同步的數據量會比較大，而同時為了不造成醫療業務的延遲和脫節，也需要很高的實時性。

在這種應用場景下已不適宜采用基于集成平臺的，通過消息交互的應用集成方式。消息集成方式，往往需要一個發起方和接受方，而發起方和接受方往往需要一些額外的支持，如發起方需要調用接受方提供的接口等，期間可能還涉及到一些負責的來回交互，最主要的是，消息集成在數據量很大的情況下，處理速度不是很快，因此，我們將通過數據集成的方式來實現數據同步，數據庫集成工具采用Oracle GoldenGate。

醫院涉及到需要數據同步的包括兩個部分：HIS數據庫和EMRS數據庫。我們將采用GoldenGate實現HIS數據庫數據和EMRS數據庫之間的數據雙向同步。其基本結構圖如下圖所示： HIS數據庫服務器GoldenGate雙向復制PRIDE數據庫服務器 從上圖我們可以看到發生在HIS數據庫上的相關數據變化通過GoldenGate實時同步到EMRS數據庫，而發生在EMRS數據庫上的相關數據變化通過GoldenGate也會實時同步到EMRS數據庫。其中具體的實現過程如下圖所示：

從上圖我們可以看到數據同步的核心是GoldenGate，在HIS數據庫和EMRS數據庫上變化數據的捕獲、傳遞和復制都是通過他來完成的。當EMRS數據庫發生數據變化的時候，如EMRS下達、校對醫囑之后，此時運行在EMRS數據庫服務器上的GoldenGate將捕獲該功能業務對應的變化數據，并通過網絡傳遞到HIS數據庫，HIS數據庫接收到這些變化數據之后，運行在HIS數據庫服務器上的GoldenGate解析這些變化數據并應用到HIS數據庫，此時如擺藥程序就能看到相應的醫囑記錄并進行擺藥。反之HIS數據庫上的變化數據也是經過上述過程應用到EMRS數據庫。

通過GoldenGate我們可以很好地實現了HIS數據庫和EMRS數據庫的之間的獨立和聯系，使他們各盡其職，分工明確，一起很好地共同支撐整個醫院的正常運營。5.1 GoldenGate概述

Oracle GoldenGate軟件是一種基于日志的結構化數據復制軟件，它議決剖析源數據庫在線日志或歸檔日志取得數據的增量改變，再將這些改變運用到目標數據庫，從而完成源數據庫與目標數據庫同步。GoldenGate 能夠在異構的IT基本結構（包括幾乎一切常用操作系統平臺和數據庫平臺）之間完成大量數據亞秒一級的及時復制,從而在能夠在應急系統、在線報表、及時數據倉庫供應、買賣跟蹤、數據同步、集中/分發、容災等多個場景下運用，而我們采用的場景是數據雙向復制，GoldenGate雙向復制的工作原理如下圖所示：

如上所示，GoldenGate在實現數據同步的時候，主要涉及到三個重要進程：抽取進程、投遞進程和應用進程。

1.抽取進程：就是上圖Capture進程，該進程主要負責讀取數據庫對應的日志文件，將數據變化保存到隊列文件中；

2.投遞進程：也叫傳輸進程，該進程主要負責將源數據庫中產生的變化的隊列文件進過壓縮和加密等方式，通過網絡傳輸到目的數據庫； 3.應用進程：也叫接納進程，該進程主要負責將投遞進程傳遞過來的源數據庫的數據變化隊列文件解析出來，并應用到目的數據庫中。上述三個進程完成了從源數據庫到目的數據庫的單項同步，如果再加上從目的數據庫到源數據庫的相似的三個進程，就實現了源數據庫和目的數據庫之間的雙向同步。

5.2 GoldenGate的特性

1.基于日志的實時數據復制：相比傳統依賴數據庫觸發器和規則的方法來捕獲數據變化，GoldenGate采用讀取日志方式對源數據庫影響小很多，速度也快很多。

如上圖所示，GoldenGate是通過數據日志挖掘的方式實現的。2.事務完整性：GoldenGate只復制成功提交的事務，同時目標數據庫按照源數據庫的操作順序，而且，可以中斷可以自動恢復，這些保證了源和目標之間的事務完整性。

3.檢查點機制保障數據無丟失：GoldenGate的抽取和復制進程使用檢查點機制記錄完成復制的位臵。對于抽取進程，其檢查點記錄當前已經抽取日志的位臵和寫隊列文件的位臵；對于投遞進程，其檢查點記錄當前讀取隊列文件的位臵。

上圖中，Capture、Pump和Devlivery將傳遞狀態存儲至checkpoint file確保其恢復性，檢查點機制可以保證在系統、網絡或GoldenGate進程故

障重啟后數據無丟失。

可靠的數據傳輸機制：GoldenGate用應答機制傳輸交易數據，只有在得到確認消息后才認為數據傳輸完成，否則將自動重新傳輸數據，從而保證了抽取出的所有數據都能發送到目標端。數據傳輸過程中支持128位加密和數據壓縮功能。界面集成

對于醫學影像、心電圖波形數據，臨床醫生的需求是，不僅能瀏覽圖像和波形，還須有對其處理的要求，通常對應系統供應商提供了DICOM影像瀏覽器和心電圖瀏覽器，這些瀏覽器提供相應的工具來處理、管理、傳輸和轉換圖像和波形。針對這種帶專業處理功能的人機交互界面的應用程序，我們采用界面集成的方式，集成專業瀏覽器插件或應用程序。

針對這種方式的場景，EMRS系統將采用界面集成應用的方式集成數據綜合瀏覽視圖，在臨床數據中心一節中已提到，該視圖采用組件化方式進行開發，實質是各類專業瀏覽插件的容器，支持對各種醫學影像（X-Ray、CT、MRI、超聲、胃腸鏡）、心電圖、監護數據和麻醉監護數據等在內的多種醫療數據的綜合閱覽分析。

至于各專業瀏覽器插件內部的實現，可能又會采用應用集成的方式，但通常為了提高性能，和多媒體資料庫中心采用直連的方式獲取影像和波形。

以DICOM影像瀏覽器組件為例，其內部采用DICOM標準進行醫學影像格式定義與交互傳輸。該模塊以OCX控件的方式實現，同時提供給集成事務處理模塊和醫護工作站使用。EMRS醫護工作站使用DICOM引擎主要實現從影像中心查詢和獲取影像等功能。6.1 DICOM影像應用流程規劃

DICOM影像的顯示流程如上圖所示，主要由以下幾步組成：

醫護工作站通過調用DICOM引擎，設臵參數（Study UID或Study Type + Study ID，DICOM Server的IP、Port、AE）*，請求獲取一個檢查的影像；

DICOM引擎啟動DICOM Query服務，獲取檢查影像數，事件通知醫護工作站，醫護工作站可以根據返回的影像數啟動初始化進度條；

DICOM引擎啟動DICOM Move服務，向影像中心請求影像； 影像中心啟動DICOM Storage服務，向DICOM引擎發送影像；

DICOM引擎每接收到一個新文件，事件通知醫護工作站，醫護工作站可以在此事件的處理中打開并顯示此文件，同時改變進度條位臵；

DICOM引擎接收到DICOM Move響應，表明文件獲取已經結束，事件通知醫護工作站。核心價值

通過建立集成信息平臺，集成各類應用系統以及日常運營的業務，通過該平臺整合醫院內部業務應用系統，形成一個互聯互通的醫院業務協作網絡。醫院信息集成平臺可以很好支持不同系統之間的醫療數據整合、業務整合與數據共享，快速實施應用程序節點部署以及各醫療子系統之間的協同通訊。在醫院信息系統中的各子系統中，比如HIS,LIS,RIS,OA等，傳遞和展現整個醫療過程中的相關信息。同時，集成信息平臺為臨床數據中心的數據來源提供了技術基礎和保障，通過信息標準、交換原則的制定，對業務系統提供標準的信息交換服務，確保數據交換過程的安全性、可靠性，實現數據在系統平臺范圍內自由、可靠、可信的交換。

通過醫院信息平臺建設，一方面可以規避“點對點”式的信息共享與交換，并使得醫院可以基于信息平臺整體上進行業務流程優化與管理，對內提高管理水平，對外以統一的方式接入區域衛生協同網絡，更好地為人民健康服務。另一方面利于醫院信息系統建設的持續性發展，以適應未來的需求變化，避免信息化建設的大范圍的推倒重來；另外，持續性發展還必須要有一套合適的實施和服務模式作支撐。