浅谈应急信息系统的功能需求和规划(一)

一、前言

经过SARS等一系列公共卫生突发事件后,应急信息系统的建设受到了空前的重视。我国各级政府、各部门都把应急信息系统或应急指挥中心的建设提上了议事日程。例如,北京市公共卫生信息应用系统的建设,就是在以往的经验教训基础上,把应对公共卫生突发事件作为一个主要建设目标;卫生部应急指挥中心向社会公开招标,征集建设方案,等等。在政府推动下,应急信息系统建设已经进入一个高峰期。

应急信息系统的建设受到全社会范围的重视,这是一件好事。但同时也带来了问题:系统建设的目标到底是什么?多个相关项目如何统筹?怎样处理应急信息系统建设与业务处理系统的关系?应急信息系统的功能边界应该如何划分?等等。对这些问题如果没有一个正确的思路,应急信息系统建设的大规模投入就难以收到应有的社会效益,甚至象以前办公自动化和门户网站一样,变为一场“运动”。

本文试图对应急信息系统给出一个目标,描述“理想”情况下的系统模型和需求;在此基础上给出对整个应急信息系统规划的看法。

二、应急信息系统的目标和功能需求分析
应急信息系统的目标,就是配合危机管理的全过程,应用信息技术,实现大面积的、跨专业和部门的信息资源、处理资源和通讯资源的实时调度,使应急指挥过程更加科学化和可视化。

这里用到了一个超越“应急”的概念――危机管理,我们把支持危机管理作为应急信息系统的目标。这是因为,要最大限度减少各种突发或紧急事件带来的损失,不仅仅要求我们在事件发生后做出迅速、准确的应对和处理,还要求我们在事件前期进行预警和辨识、在后期进行常态恢复。“危机管理”的三阶段理论更能指导我们运用信息技术对突发或紧急事件全面、全程的支持。

显然,这一目标,不是一个单纯的信息系统可以达到的。它要依赖基础性的网络和多个专业化的应用系统,要依赖多种技术的支持。但是,越是复杂,我们就越应该分析清楚,那些是核心、哪些是基础、哪些是锦上添花;哪些应该先建,哪些可以后建。否则眉毛胡子一把抓,不利于复杂系统的建设和统一的规划。

我们用如下的三层逻辑模型表示应急信息系统及其支持系统的关系。

……

应急信息系统

信息处

理系统

通讯调

度系统

信息

采集

信息

调度

资源

调度

信息

表现

基本网络和通讯系统

辅助

决策

应用支持层

集成应用层

基础设施层

GIS

应急信息系统的三层逻辑模型

各层的关系如下:最高层即是应急信息系统的核心功能,它是一种集成式应用;专业化的信息处理系统和各种相对成熟的技术系统(如GIS和Call Center系统)是构建应急信息系统的支撑性应用,我们称之为应用支撑层;而基本网络和通信系统是以上所有应用的基础。相邻层次之间有着双向的信息供求关系。

我们从对信息的处理角度来分解应急信息系统的功能目标。

任何类型和目的的应急指挥系统,都具有以下功能特性:

1、信息汇聚:从应急事件现场或监测网络采集到的各种信息,将被传输到信息汇聚点(应急指挥中心)。这些信息可能是直接事件现场的视音频信息,也可能是来自传感设备、监控设备的信息或信号,还可能是来自相关的专业化信息处理系统的数字化信息。

2、信息表现:应急信息系统应该有直观而准确的信息表现形式,为指挥员进行指挥调度和辅助决策提供最大的帮助。GIS是一项广泛使用的技术,可以将危机管理所涉及的信息(如危机态势、应急指挥相关资源分布、应急方案等)在基础的空间地理图形上形象地表现出来,便于指挥和决策人员直观地进行形式判断、形成决策或进行资源调度;各种信息还可能要借助一定的显示设备和显示控制系统表现出来。

3、信息调度:所有信息在汇聚点被组合和集中呈现,供指挥中心的指挥决策人员作为决策和调度依据;有时还要将信息分发下级指挥中心(或分中心)的不同的专业化处理系统进行处理,或从这些系统收集处理结果。

4、通讯和物资资源调度:应急指挥最终都表现为通过一定的通讯手段,完成一定的人力、物力资源调度。例如警力的调度、救灾物资和设施调度、对事件现场的疏导和部署,等等。

5、辅助分析决策:在应急指挥过程中,提供一些逻辑分析模型、统计模型或预案,以及案例库中的参考案例,帮助指挥员进行理性决策;同时,应急信息系统还应记录下整个指挥调度的过程,形成完整案例,丰富案例库,为实现知识化、智能化的危机管理作积累。

以上是一个较为抽象的逻辑功能模型,它有助于我们把握应急信息系统的核心建设目标,合理运用各种技术和各种“物理的”系统。

三、应急信息系统与其它信息系统的周边关系
1、技术型应用系统与应急信息系统的关系

在应急信息系统建设领域的最大误区,在于信息系统功能需求分析的缺失――从需求的陈述(实质上是一种需求定义)直接跳到技术方案,甚至成为技术方案或产品的简单堆砌。以技术方案代替功能需求,这似乎已经成为了一种应急信息系统建设中的普遍现象。

例如,我们经常能在招标书或所谓规划中看到这样的做法:即直接把“数字录音系统”、“大屏幕显示系统”、“地理信息系统”等作为“需求”本身的内容,对具体的技术实施方案和产品型号进行招标,甚至还有的招标书把“数据库系统”也作为应急信息系统需求的一部份提出来。这里面缺少了对应急信息系统的实质内容和目标的把握,缺少了一个理性的论证和分析过程。这样的“需求”拿出来招标,多半会造成建设的混乱和失控。

并不是说以上的技术系统不能作为应急信息系统的一部分,相反,逻辑的功能最终都会落实为一系列“物理”的技术子系统。但是我们在进行技术子系统的划分和分包之前,有必要对有机信息系统的“原始”功能需求作一定义和陈述,为技术方案的展开提供理性的约束,而不会被技术牵着鼻子走。

例如,GIS是一种广泛使用的、成熟的技术,也已经形成相对独立运行的系统。独立运行的GIS甚至可能成为整个应急信息系统中最主要的操作平台。这也是一些项目直接把GIS作为一种“默认”的“需求”的原因。但是,应急信息系统是否要采纳GIS,还要看具体的应用领域是否具备了应用GIS的数据条件和环境。而且,即使有必要和有条件使用GIS,也要从整个应急信息系统的总体目标出发进行分析,提出技术应用需求: