第一篇:山东省信息扶贫综合服务平台建设方案
山东省信息扶贫综合服务平台建设 建议
为贯彻落实《山东省扶贫开发领导小组关于印发<全省脱贫攻坚专项实施方案>的通知》(鲁扶贫组发[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等,传递和展现整个医疗过程中的相关信息。同时,集成信息平台为临床数据中心的数据来源提供了技术基础和保障,通过信息标准、交换原则的制定,对业务系统提供标准的信息交换服务,确保数据交换过程的安全性、可靠性,实现数据在系统平台范围内自由、可靠、可信的交换。
通过医院信息平台建设,一方面可以规避“点对点”式的信息共享与交换,并使得医院可以基于信息平台整体上进行业务流程优化与管理,对内提高管理水平,对外以统一的方式接入区域卫生协同网络,更好地为人民健康服务。另一方面利于医院信息系统建设的持续性发展,以适应未来的需求变化,避免信息化建设的大范围的推倒重来;另外,持续性发展还必须要有一套合适的实施和服务模式作支撑。