MZ T 090-2017 街道管理与服务的信息化.pdf

《MZ T 090-2017 街道管理与服务的信息化.pdf》由会员分享，可在线阅读，更多相关《MZ T 090-2017 街道管理与服务的信息化.pdf（60页珍藏版）》请在麦多课文档分享上搜索。

1、1 MZICS03.080.A16 1： 街道管理与服务的信息化Informationtechnologyformanagementandserviceofsubdistrict中华人民共和国民政行业标准MZ/T0902017 2017-09-21发布 2017-09-21实施中华人民共和国民政部 发 布 目 次前言.错误！未定义书签。街道管理与服务的信息化.11范围.12规范性引用文件.13术语和定义.14系统.25数据.66接口.87信息安全支撑.11 附 录 A 总体框架 .14附 录 B 系统运行模式.15附 录 C 最低生活保障金申请流程示例.16附 录 D 数据采集流程.18附 录

2、 E 数据类型.19附 录 F 数据元值表示格式中使用的字符含义.20附 录 G 数据元属性.21附 录 H 通用数据元 .22附 录 I 代码集.25附 录 J 数据共享交换平台接口结构 .48 附 录 K 数据接口模型构成.49附 录 L 数据结构.50附 录 M 数据集构成.51附 录 N 附件集构成.52附 录 O 社区低保信息数据格式示例.53 MZ/T0902017 IV 前 言本标准依据GB/T1.1-2009给出的规则起草。本标准由民政部基层政权和社区建设司提出并归口。本标准起草单位：民政部基层政权和社区建设司、南京市民政局、智汇神州信息发展有限公司、江苏鸿信系统集成有限公司、

3、南京标准化学会。本标准主要起草人：陈越良、汤晋苏、徐贻珠、吴凤祥、龚毅诚、陈骏、管宏、张爱萍、聂彦岭、郝海波、李振家、贺更行、李亚娟。本标准于2017年9月21日首次发布。 MZ/T0902017 1 街道管理与服务的信息化1 范围本标准规定了街道管理与服务的信息化的术语和定义、系统、数据、接口与信息安全。本标准适用于街道管理与服务的信息化技术开发。2 规范性引用文件下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。GB/T2260-2007 中华人民共和国行政区划代码 GB/T2261.

4、1-2003 个人基本信息分类与代码 第1部分:人的性别代码GB/T2261.2-2003 个人基本信息分类与代码 第2部分:婚姻状况代码GB/T2261.5-2003 个人基本信息分类与代码 第5部分:港澳台侨属代码GB2312-1980 信息交换用汉字编码字符集基本集GB3304-1991 中国各民族名称的罗马字母拼写法和代码GB/T4658-2006 学历代码GB/T4761-2008 家庭关系代码GB/T4762-1984 政治面貌代码GB/T7027-2002 信息分类和编码的基本原则与方法GB/T7408-2005 数据元和交换格式 信息交换 日期和时间表示法GB11643-199

5、9 公民身份号码GB/T21062.2 政务信息资源交换体系 第2部分:技术要求GB/T21062.3 政务信息资源交换体系 第3部分:数据接口规范GB/T21062.4 政务信息资源交换体系 第4部分:技术管理要求 GB/T21063.2 政务信息资源目录体系 第2部分:技术要求GA/T517-2004 常用证件代码MZ/T012-2014 民政业务数据共享与交换编码3 术语和定义下列界定的术语和定义适用于本文件。3.1 街道管理与服务 managementandserviceofsubdistrict为了维持社区居民的正常秩序，满足社区居民物质和文化活动等需要，街道办事处面向所辖社区居民而

6、进行的一系列的行政管理与公共服务活动。3.2 基础数据 based data描述街道及所辖社区的人口、房屋、地理位置和组成机构等基本属性的信息。 3.3 业务数据 Community businessdata描述街道事务、业务和服务等专题属性的信息。3.4 数据交换 dataexchange MZ/T 0902017 2 独立于具体应用，通过统一接口规范完成数据的可靠、安全传输，实现不同部门垂直系统与街道信息系统之间双向、异构、不同格式数据的获取、存储及应用的过程。3.5 交换域exchangedomain解决特定应用主题需求建立的系统环境，由多个交换管理中心和若干前置交换系统构成。3.6 交

7、换中心 exchangecenter街道信息化平台的交换管理中枢，管理交换数据和交换流程，实现街道及所辖社区信息资源的交换及监控管理。3.7 数据交换平台 dataexchangeplatform为互相之间联网的不同计算机系统集中分发、中转、传输、接收数据的计算机网络信息系统。 4 系统定位街道管理与服务信息化应面向街道及所辖社区工作者，服务辖区居民和企业，辅助政府部门进行街道、社区综合管理与服务。框架总体框架应体现各个子系统、功能以及相互关系，其框架图参见附录A。4.2.1 用户层互联网门户互联网门户可在市级集中建设，成为全市所辖街道门户网站群的统一入口，集中展现部署在互联网 上街道管理与服

8、务的重要信息和应用，其具体要求包括但不限于：围绕街道服务对象的需求，梳理政务公开、网上办事、公众参与等内容，提供个性化服务；提供用户管理、运行监控、服务受理、办理状态查询、办理结果反馈、服务投诉等功能，支撑街道管理与服务整合；按照一点受理、抄告相关、限时反馈的模式，实现网上办事统一入口受理；其他公共及商业服务网站经核准后可实现与街道服务网站的对接，面向居民提供服务;街道服务机构可通过信息亭、办事服务大厅、社区服务站等渠道为用户提供信息服务；支持用户通过个人电脑、手机、平板、电话、数字电视等终端设备获取街道及所辖社区信息服务；可通过专用网关等方式实现呼叫中心、广电媒体、移动服务平台与门户网站的信

9、息交互。4.2.2 政务网门户政务网门户应对政府部门发布的信息资源目录以及跨部门、跨层级应用系统实现统一入口和集中展 现，其具体要求包括但不限于：依托共享交换平台，整合各类街道、社区管理与服务信息资源目录、应用系统等，为各级政府部门和街道工作人员提供资源共享、业务协同、决策支持等服务；提供用户管理、单点登录、内容管理、个性化定制、查询检索、目录导航、服务导航、运行监控等功能，支撑资源整合和业务协同; MZ/T0902017 3 街道服务机构可通过信息亭、办事服务大厅、社区服务站等渠道为用户提供信息服务；支持用户通过个人电脑、手机、平板、电话、数字电视等终端设备获取街道及所辖社区信息服务；可通过

10、专用网关等方式实现呼叫中心、广电媒体、移动服务平台与门户网站的信息交互。4.2.3 应用层应用层应面向居民提供公共服务事项办理、面向政府部门提供数据上报以及其它管理服务工作。4.2.4 支撑层4.2.4.1 基础支撑应支持汇集人口、组织、房屋、设施等基础信息资源，并为政府部门或第三方提供街道及所辖社区信息资源；为街道各类应用系统提供可复用的身份认证、单点登录、表单管理、查询检索、统计分析等 基础功能组件。4.2.4.2业务支撑应封装特定业务应用共性功能和特征，提供可扩展、可定制、可复用的业务组件和服务，其具体要求包括但不限于： 应根据业务模型的分析设计，提炼业务领域通用组件； 应具备服务整合功

11、能，为上层应用提供粗粒度的服务，并将封装后的粗粒度构件和服务进行注册，实行统一管理； 应充分利用信息资源共享交换服务、构件管理服务和安全服务提供的公共组件和服务实现。4.2.5 数据资源层数据资源层应提供街道、社区业务应用所涉及的各种基础数据库、专题数据库和交换数据库。4.2.6 基础设施层 基础设施层应提供信息化系统正常运行所必需的各类物理保障。包括网络、服务器、存储备份等一系列硬件设施和操作系统、数据库、中间件等一系列基础软件设施。4.2.7 部门接入层部门接入层宜接入涉及居民的公共服务的政府部门业务系统。4.2.8 标准规范体系标准规范体系应建立信息化系统顺利运行所需的标准规范和制度。4

12、.2.9 安全支撑体系安全支撑体系应建立保障街道管理与服务信息化网络、硬件、信息和应用安全的规范、指南和评估体系。 系统基础功能4.3.1 数据采集数据采集应实现但不限于以下功能： MZ/T 0902017 4 采集信息项管理，通过定义，设置需要采集的信息项的元数据；采集模板管理，通过模板定制，设置所需采集信息项在人机交互界面上的布局位置；采集信息填报模块，用户可使用定制的采集模板进行信息填报。4.3.2 流程管理流程管理应由相关中间件（BPM）提供，对各种工作流程进行定制、执行、监控，应优先实现以下功能：工作流建模，进行流程定义，生成可执行的工作流模型；工作流引擎，为执行工作流模型提供支持。

13、4.3.3 报表与表单报表与表单服务应实现以下功能：为街道管理与服务报表定制和查询提供支持。 为街道管理与服务自定义表单提供支持。4.3.4 身份管理与访问控制身份管理与访问控制应为实现基于街道系统的各应用系统的统一身份认证与访问控制提供支持。身份认证服务应支持标准协议LDAP和数字证书。4.3.5 元数据服务元数据服务应提供标准的元数据服务接口，对系统中的元数据进行统一管理，实现元数据定义、元数据查询、元数据维护和元数据关联分析。4.3.6 资源目录服务资源目录服务应符合GB/T21063.2的要求，为街道系统与相关部门及其它外部系统之间的数据共享交换提供资源目录基础支撑。 4.3.7 数据

14、交换服务数据交换服务应符合GB/T21062.2的要求，为街道系统与相关部门及其它外部系统之间的数据共享交换提供基础支撑。系统对接4.4.1 民政系统对接应按照民政部门在街道业务处理或信息采集的需要，通过后台数据交换平台将信息与现有系统实行数据交换，并实现业务受理流程全过程跟踪。4.4.2 社会保障系统对接可采用网闸方式与社会保障系统进行准实时交互，迁移至统一界面进行办理。 4.4.3 卫生与计划生育系统对接应通过数据交换或信息采集与当前系统对接，迁移至统一界面进行办理，并实现业务受理流程全过程跟踪。 MZ/T0902017 5 4.4.4 残疾人保护事务系统对接应通过数据交换或信息采集与当前

15、系统对接，迁移至统一界面进行办理，并实现业务受理流程全过程跟踪。4.4.5 住建房产系统对接应通过数据交换或信息采集与当前系统对接，迁移至统一界面进行办理，并实现业务受理流程全过程跟踪。4.4.6 司法行政系统对接应通过数据交换或信息采集与当前系统对接，迁移至统一界面进行办理，并实现业务受理流程全过程跟踪。4.4.7 妇幼权益保护系统对接 应通过数据交换或信息采集与当前系统对接，迁移至统一界面进行办理，并实现业务受理流程全过程跟踪。运行模式街道管理与服务信息化系统所需数据和业务办理流程应通过数据交换接口实现。系统运行模式图参见附录B。业务流程4.6.1 图形符号业务流程图的图形符号应符合但不限

16、于表1所示的规定。 MZ/T 0902017 6 表1 业务流程图形符号规定 4.6.2 业务流程图业务流程示例图应体现但不限于：参加活动的角色主体；角色为完成其职责而执行的关键活动或角色之间发生件；伴随事件活动交互的业务信息；确保业务流程的活动链一环紧扣一环；每个业务流程图应完成一项明确的业务目标。4.6.3 业务流程图描述业务流程图描述应采用表格的形式描述，内容包括但不限于：明确参与业务流程图中业务环节；明确参与业务环节的角色；明确业务环节中角色之间交互的业务文书； 明确业务环节中交互的主要业务信息；明确业务环节完成的衡量指标。4.6.4 最低生活保障金申请流程最低生活保障金申请流程示例参

17、见附录C。5 数据 MZ/T0902017 7 采集规则数据采集应符合但不限于以下规则：街道管理与服务信息化系统涉及的数据项应源于街道及所辖社区实际情况或政府相关部门具有一定效力的文件，非权威数据不做采用；街道管理与服务信息化系统应提供统一的数据采集服务和交换接口服务，可按需定制数据采集模板，按需采集和交换数据；街道工作人员应直接使用街道管理与服务系统采集数据；街道管理与服务系统应以自身采集的数据为准，可参考但不依赖业务部门的业务数据。采集流程数据采集流程图参见附录D。具体采集流程如下：相关政府部门向街道或所辖社区提出数据采集要求； 系统管理人员根据数据采集要求类型做不同处理，常规性的数据采集

18、固化为常规采集任务，作为街道系统常用功能，临时性数据采集任务由系统管理人员使用街道系统定制功能临时采集；街道及所辖社区工作人员根据要求进行数据采集；采集的数据通过数据交换或导出等方式提供给相关部门。数据元5.3.1 组成要素5.3.1.1 数据项名称数据项名称应赋予数据项的单个或多个中文字词指称。5.3.1.2 数据类型数据类型应表示数据项类型的符号、字符，参见附录E。数据类型取值应包括但不限于表2所列。 表2 数据类型数据类型 说明字符型（string） 通过字符形式表达的值的类型数字型（number） 通过从“0”到“9”数字形式表达的值的类型日期型（date） 通过yyyymmdd 的形

19、式表达的值的类型日期时间型（datetime） 通过yyyymmddhhmmss 的形式表达的值的类型布尔型（boolean） 两个且只有两个表明条件的值，如：On/Off、True/False二进制（binary） 上述无法表示的其他数据类型，如图像、音频5.3.1.3 数据格式数据格式应规定数据项值的格式要求，包括允许的最大和最小字符长度、数据项值的表示格式。 如果“数据类型”是“二进制”，在属性中应标识出该数据类型的具体格式，如“JPEG”。数据格式中使用的字符含义见附录F。5.3.1.4 值域 MZ/T 0902017 8 值域应根据数据元属性中规定的数据类型、数据格式界定数据元的允许

20、值集合。数据元的属性参见附录G。5.3.1.5 数据项说明应对数据项的具体含义进行说明。5.3.1.6 数据来源应对数据项的来源给予判定。5.3.1.7 备注应对需要延伸解释的数据项给予附加注释。5.3.2 通用数据元街道管理与服务信息化数据元应符合通用数据元规定。通用数据元参见附录H。 代码5.4.1 编码规则应为每个业务信息的编码预留一定的扩展空间，以适应街道管理服务信息化建设与发展的需要。5.4.2 编码方法编码方法应符合以下要求：应依据 GB/T7027-2002的编码原则与方法，采用阿拉伯数字编码。应采用统一的数字编码。代码取值均为一位数时，将9作为其他或未说明项；取值均为两位数、三

21、位数、四位数等时，将99，999，9999等如此类推作为其他或未说明项预留，所有代码从1开始编码。数据项应参照各级主管部门已下发的相关政策文件、各类统计分析报表、调查问卷等文档，依照代码对象的产生时间先后、使用(出现)频率由高到低、重要程度由高到低等顺序编写。对于 没有顺序规则的代码对象按照其首字母顺序排列。涉及级别的代码，按照其级别由高到低的顺序排列。5.4.3 代码集街道管理与服务信息化涉及的代码在代码集中已有规定的应符合代码集的规定。代码集参见附录I。6 接口交换平台接口架构交换平台接口架构图参见附录J。其功能应包括但不限于：目录服务，支持对信息资源目录的统一管理，为用户提供信息资源的检

22、索和定位服务；交换服务，支持对信息资源交换功能和流程的统一管理，为跨部门层级信息交换提供服务；基础信息服务，支持汇集人口、组织、房屋、设施等基础信息资源，并为政府部门提供街道及所辖社区信息资源共享服务； 监管服务，支持对信息资源的跨部门、跨层级共享交换情况进行监管。6.1.1 交换网络 MZ/T0902017 9 交换网络应通过政务网或专网将街道管理与服务信息资源数据库与外部系统进行数据交换。其中，公安、人社部门的数据交换应通过专网接入，民政、卫生与计划生育、残联、住房、司法部门的数据交换应通过政务网进行。6.1.2 信息交换管理中心信息交换管理中心应提供对信息资源的统一管理及目录服务，具备流

23、量控制、优先级控制、独立队列处理、消息传输特性、交换任务和管理任务分离、异步传输机制、并发/串行处理功能，支持大规模并发处理以及数据传输的断点续传。6.1.3 业务协同管理中心业务协同管理中心应基于SOA定义整合流程，通过消息传递的松耦合方式，将不同平台、不同架构和不同功能的部门垂直业务系统有机连接，实现不同部门前置交换信息库之间的安全、可靠、稳定、高效的信息交换。 6.1.4 前置交换系统前置交换系统应实现中心平台与交换节点之间的部门业务职责、异构技术平台的合理分离以及标准化交互，增加整个体系的可扩展性、可维护性、可推广性。应在所有参与信息交换的部门内部署一个前置交换系统，根据部门业务应用系

24、统的业务和技术特点进行客户化设计和开发。信息交换接口与共享系统基本要求6.2.1 技术要求信息交换的接口与共享应符合以下要求：应支持数据双向同步；应支持各种主流操作系统；应支持国内外主流数据库； 应支持结构化及非结构化的数据；应支持文件大小4GB以上单个文件的传输；应支持单表记录2000万条以上的数据库数据的传输；应提供增量数据自动识别功能,在不修改数据库结构的情况下，能自动识别出需要交换的信息；应支持多个信息交换与共享任务或服务同时运行、远程部署；应提供管理与监控接口，支持远程管理功能；消息传送应支持超文本传输协议；应采用W3C的SOAP1.2作为消息封装格式；采用W3C的WSDL1.2作为

25、交换服务描述规范；提供消息寻址功能，支持信息路由功能；提供消息确认和消息选择性重发机制以实现安全可靠的消息传递功能；提供消息差错处理功能；应提供信息交换流程监控功能； 应提供系统状态及交换服务运行状态查询功能；应提供信息交换日志管理及日志查询的功能，能实时监视信息交换的情况；应具备良好的可扩展性，可根据交换与共享需求的变化实现系统的扩展部署； MZ/T 0902017 10 应具备与安全等级相应的安全防护措施，具备符合安全等级要求的快速恢复能力。6.2.2 管理要求信息交换与共享系统管理应符合GB/T21062.42007中相关管理的规定。数据接口模型数据接口模型应定义街道管理与服务信息化系统

26、与其他系统之间数据交换或数据共享时封装信息内容，可支持结构化的数据、非结构化数据的封装。数据接口模型构成图参见附录K。6.3.1 数据结构数据结构应描述交换信息内容的结构信息，宜为可选元素。其构成图参见附录L。6.3.2 数据集 数据集应封装结构化数据，宜为可选元素。其构成图参见附录M。6.3.3 附件集附件集应封装非结构化数据，宜为可选元素。其构成图参见附录N。技术实现方式6.4.1 数据库之间信息交换与共享街道与上级政府（区、市）信息系统之间数据抽取、转换、清洗、装载，达到数据交换的目的，其技术实现方式要求如下：应互通两个业务系统数据库的网络；应基于数据库的数据工具ETL；可按月/季度进行

27、数据交换； 应使系统管理员通过在“ETL数据抽取工具”中进行配置，可自动执行。应支持数据流向双向同步。6.4.2 共享文件信息交换与共享两个应用系统之间数据组装、数据传输、数据解析和数据使用，达到数据交换的目的，应通过共享文件实现。其技术实现方式要求如下：应使两个应用系统都能访问网络上的某个共享目录，或者两个应用系统都能访问同一个FTP服务器；应基于XML文件和FTP服务器技术；应使系统有单独的操作界面，手工触发完成数据交换；应支持数据流向双向同步。一旦数据交换失败，系统应通过消息报告，提醒用户手工重新操作，利用消息驱动来保障数据交换异常处理； 应把参与数据交换的数据文件存放前置机，应用系统应

28、完成数据交换文件的自动上传、下载与交换。6.4.3 服务信息交换与共享 MZ/T0902017 11 两个应用系统之间数据访问，数据传输，数据解析和数据使用，达到数据交换的目的，应通过系统接口实现。其技术实现方式要求如下：应使两个应用系统可直接相互访问，或者两个应用系统之间通过网络中转设备间接相互访问；应基于面向服务架构的技术；应实时交换数据；应将数据同步触发嵌套在应用系统中；应支持数据流向双向同步；一旦数据交换失败，系统应能自动识别并及时再次进行数据交换行为。服务调用数据交换服务模块应由数据提供方开放并提供中间数据服务，数据接收方通过这些数据服务来获取对方数据。 数据接口应符合GB/T210

29、62.3-2007中的接口模型定义，以“社区低保信息数据格式”为例进行描述。示例图参见附录O。7 信息安全支撑网络要求平台的部署应在满足需求的前提下，首先选择使用政务网络，并遵从网络管理制度。安全体系设计应符合GB17859-1999中二级的要求及其他相关标准的规定。7.2.1 风险评估与安全定级 进行风险评估与安全定级，实施等级保护。应符合GB17859-1999的规定。7.2.2 分域保护应根据各子系统功能、地域、信息属性的不同进行分域保护。7.2.3 用户身份鉴别应支持用户标识和用户鉴别。在对每一个用户注册到系统时，应采用用户名和用户标识符标识用户身份，并确保在系统整个生存周期用户标识的

30、唯一性；在每次用户登录系统时，应采用受控的口令或具有相应安全强度的其他机制进行用户身份鉴别，并对鉴别数据进行保密性和完整性保护。7.2.4 身份认证所有进入平台系统或使用系统提供的服务的用户都应进行身份认证，系统根据用户角色的不同分派不同的权限。当用户进入重要的服务器或以具有高级权限的身份登录到系统时，应使用基于数 字证书的认证方式。7.2.5 管理中心应通过系统管理员对系统的资源和运行进行配置、控制和管理。应对系统管理员进行身份鉴别， MZ/T 0902017 12 只允许其通过特定的命令或操作界面进行系统管理操作，并对这些操作进行审计。7.2.6 自主访问控制应在安全策略控制范围内，使用户

31、对其创建的客体具有相应的访问操作权限，并能将这些权限的部分或全部授予其他用户。访问控制主体的粒度为用户级，客体的粒度为文件或数据库表级。7.2.7 系统安全审计应提供安全审计机制，记录系统的相关安全事件，提供审计记录查询、分类和存储保护。7.2.8 审计管理应通过安全审计员对分布在系统各个组成部分的安全审计机制进行集中管理。应对安全审计员 进行身份鉴别，并只允许其通过特定的命令或操作界面进行安全审计操作。7.2.9 用户数据完整性保护可采用常规校验机制，检验存储的用户数据的完整性，以发现其完整性是否被破坏。7.2.10 用户数据保密性保护可采用密码等技术支持的保密性保护机制，对在安全计算环境中

32、存储和处理的用户数据进行保密性保护。7.2.11 客体安全重用 应采用具有安全客体复用功能的系统软件或具有相应功能的信息技术产品，对用户使用的客体资源原使用者的信息进行清除，以确保信息不被泄露。7.2.12 恶意代码防范应安装防恶意代码软件或配置具有相应安全功能的操作系统，并定期进行升级和更新，防范和清除恶意代码。7.2.13安全区域边界设计技术要求7.2.13.1 区域边界包过滤 应根据区域边界安全控制策略，通过检查数据包的源地址、目的地址、传输层协议和请求的服务，确定是否允许该数据包通过该区域边界。7.2.13.2 区域边界安全审计应在安全区域边界设置审计机制，并由安全管理中心统一管理。

33、MZ/T0902017 13 7.2.13.3 区域边界恶意代码防范应在安全区域边界设置防恶意代码网关，由安全管理中心管理。7.2.13.4 区域边界完整性保护应在区域边界设置探测器，探测非法外联等行为，并及时报告安全管理中心。7.2.14安全通信网络设计技术要求7.2.14.1 通信网络安全审计应在安全通信网络设置审计机制，由安全管理中心管理。7.2.14.2 通信网络数据传输完整性保护 应采用由密码等技术支持的完整性校验机制，实现通信网络数据传输完整性保护。7.2.14.3 通信网络数据传输保密性保护应采用由密码等技术支持的保密性保护机制，实现通信网络数据传输保密性保护。 MZ/T 090

34、2017 14 附 录 A(资料性附录）总体框架A.1 总体框架总体框架见图A.1。 图A.1 总体框架图 MZ/T0902017 15 附 录 B( 资 料 性 附 录 ）系统运行模式B.1 系统运行模式系统运行模式见图B.1。 说明：a) 相关部门的业务系统不下发到街道，街道工作人员使用街道管理与服务信息化系统完成相关工作；b) 常规信息采集和临时信息采集在街道系统实现，采集的数据通过数据交换提供给相关部门；c) 业务办理初审和业务流程流转中街道环节由街道系统实现，相关部门的业务系统与街道系统进行数据交换，有条件的可以进行业务流程整合；d) 街道系统相关部门提供信资源共享交换服务。图B.1

35、 系统运行模式 MZ/T 0902017 16 附 录 C(资料性附录）最低生活保障金申请流程示例C.1 最低生活保障金申请流程图最低生活保障金申请流程图见图C.1。 图C.1 最低生活保障金申请流程图示例 MZ/T0902017 17 C.2 最低生活保障金申请流程最低生活保障金申请流程图见表C.1的规定。表C.1 最低生活保障金申请流程图参与角色 申请人、街道（社区）便民服务中心、乡镇（街道）、区社会救助科 业 务环 节 名称 角色 交互文书 衡量指标申请 申请人 1.居民最低生活保障申请书2.相关材料 无录入综合管理与服务平台 街道（社区）便民服务中心 无 无核查材料 街道（社区）便民服

36、务中心 无 无补齐补正材料 申请人 无 无同步申请信息到业务系统 街道（社区）便民服务中心 无 无乡镇入户调查 乡镇（街道） 居民最低生活保障调查审批表 无 现场评议 乡镇（街道） 无 无审核 乡镇（街道） 无 无一级公示 乡镇（街道） 无 无审查材料 区县社会救助科 无 无入户抽查 30% 区县社会救助科 无 无审批 区县社会救助科 无 无反馈审批结果到综合管理服务平台 救助系统自动同步 无 无二级公示 区县社会救助科 无 无保障金发放 区县社会救助科 无 无 注1：二级公示是长期公示，只要申请人还在领取救助金就需要一直公示。 MZ/T 0902017 18 附 录 D(资料性附录）数据采集

37、流程D.1 数据采集流程数据采集流程见图D.1。 图D.1 数据采集流程图 MZ/T0902017 19 附 录 E（ 资 料 性 附 录 ）数据类型E.1 数据类型数据类型见表E.1。 表E.1 数据类型表示符 数据类型 说 明 C 字符型 可以包含汉字、字母字符、数字字符（不进行数学运算）和符号等。（默认GB 2312 信息交换用汉字编码字符集基本集）N 数值型 用“0”到“9”数字形式表示的数值（包括整型数和实型数），可进行数学运算。D 日期型 采用GB/T7408 中规定的YYYYMMDD格式DT 日期时间型 采用GB/T7408 中规定的YYYYMMDDhhmmss格式T 时间型 采

38、用GB/T7408 中规定的hhmmss格式B 布尔型 有两个且只有两个表明条件的值，采用Y/N表示。BY 二进制流 图象、音频、WAN、RM、AVI、MPEG等二进制流文件格式。 MZ/T 0902017 20 附 录 F（ 资 料 性 附 录 ）数据元值表示格式中使用的字符含义F.1 数据元值表示格式中使用的字符含义数据元值表示格式中使用的字符含义见表F.1。表F.1 数据元值表示格式中使用的字符含义数据类型 字 符 含 义 字符型 C GB2312中的字符，包括中文字符、字母字符、数字字符等C6 固定6位字符（一个字母、数字占一个字符；一个汉字占2个字符）C.6 最长6个字符（一个字母、

39、数字占一个字符；一个汉字占2个字符）数值型 N 数值型N6 固定长度为6位数字，即6位数字的整型数。N6,2 最大长度为6位的十进制小数格式（包括小数点和小数点后面的数字），小 数点后保留2位数字。如：123.45、12.34。日期型 YYYYMMDD “YYYY”表示年份，“MM”表示月份，“DD”表示日期。如2006年3月7日， 应表示为20060307。日期时间型 YYYYMMDDhhmmss “hh”表示时，“mm”表示分，“ss”表示秒。如2006年3月7日12时12分12秒应表示为20060307121212。 MZ/T0902017 21 附 录 G（ 资 料 性 附 录 ）数据元属性G.1 数据元属性数据元属性见表G.1。 表G.1 数据元属性数据元属性名称 约束性符号中文名称 M 英文短名 M同义名称 O语 境 C说 明 M数据类型 M表示格式 M值 域 O计量单位 O备