采 购 需 求
一、项目背景
深入贯彻习近平总书记关于民政工作的重要指示批示精神,全面落实省市数字化改革工作决策部署和全省数字化改革重大应用“一本账S1”建设要求,以数字化改革撬动民政领域共同富裕、推动民政事业高质量发展为总体目标,重点聚焦养老服务、困境未成年人关爱保护、困难群体救助、移风易俗、公益慈善等五个领域,通过建设“善杭州”数智民政民生治理项目,推进数字民政体系建设,实现多跨协同、两端赋能,形成政府主导、居民共享、社会参与的“智共体”,积极助力杭州成为高质量发展建设共同富裕示范区的城市范例,为“数字社会”建设切实扛起民政担当。
通过打造“善杭州”数智民政民生治理,建设形成“善养”“善助”“善治”“善亲”“善举”五善数字治理。
本期项目根据其内容特点分成3个标项建设,具体如下:
标项一:数智养老、社救子系统
在善助方面,建设低收入人口监测系统主要是为了落实“一本账”省民政厅“浙里救助应用”平台低收入人口动态监测场景试点任务,打造统筹城乡、分层分级、上下联动、部门协同、定期更新的数字救助体系,实现对低收入人口的信息汇聚、常态监测、快速预警、主动发现,做到即时干预、精准救助、综合帮扶,切实织密兜牢困难群众基本生活保障底线,做到应救尽救、应帮尽帮,助力困难群众“杭向共富”。
在善养方面,深入贯彻习近平总书记关于民政工作的重要指示批示精神,全面落实省市数字化改革工作决策部署和全省数字化改革重大应用“一本账S1”建设要求,以数字化改革撬动民政领域共同富裕、推动民政事业高质量发展为总体目标,聚焦养老服务领域,通过建设“善杭州”数智养老项目,推进数字民政养老服务体系建设,实现多跨协同、两端赋能,形成政府主导、居民共享、社会参与的“智共体”,积极助力杭州成为高质量发展建设共同富裕示范区的城市范例,为“数字社会”建设切实扛起民政担当。落实“一本账”省民政厅“浙里养老综合服务应用”试点任务和数字社会“老有所养”应用场景建设任务,优化杭州特色的大养老服务体系,主要是迭代升级“互联网+养老”杭州平台,构建覆盖全域的“幸福颐养”智慧服务。
从管理角度来讲,坚持政府出资建设、纳入财政预算,整合资源、节约高效的建设原则,做好项目建设工作,对现有的系统资源进行资源共享整合,为将来的建设预留足够的发展空间。
从技术措施角度来讲,在系统的设计和实现中,严格遵守以下原则:
(1)先进性
基于快速协同响应技术,实现与横向部门的信息交换,方便的实现数据与业务集成的需求,各级部门必须优化调整自己的业务模式和再造自己的业务流程,同时,由于各级部门协同工作,实施难度大,因此业务流程的设计、优化和管理是成功实施信息平台的一个关键。
(2)开放性
即在遵循标准性原则的基础上,采用开放的技术、结构、系统组件、用户接口,采用开放的通信协议和技术标准,保障系统在互联或以后的扩展过程中能够稳定有效的运行,以满足业务应用需求。
(3)可靠性
对设计方案、应用技术和产品进行严格的可行性论证,把风险降至最低限度。采用的先进技术应是成熟的经过实践证明是成功的技术,保证系统运行稳定,有很强的防错、抗错能力;有很强的故障恢复和应急措施,保证日常事务不间断地正常运行。
(4)安全性
通过建立一套完整、合理的认证体系,实现系统分级分层授权,数据分级分层管理,保证业务信息安全和保密。采用岗位化(角色化)界面设计,保障工作人员“各司其职”防止执行超越权限的操作。在敏感信息的传送中采用加密技术,防止重要信息的泄漏。同时,对重要操作要进行日志记录,并可对这些操作日志进行审计和内容过滤。
(5)兼容性
系统的体系架构应具有兼容性,此次招标的技术偏向于国产化,促进我国在信息技术领域的发展。
(6)创新性
基于软件构件技术的开发平台,是运用J2EE技术基于构件开发模式而全新开发的一个软件平台,运用此平台,使得应用开发更直观、更简单、更方便。
3.1.1建设框架
整体架构以省大救助为基础,运用省大救助的云资源、安全防护等基础设施,数据资源层与省大救助系统数据同源,构建低收入人口库(在册对象库、持续监测对象库、主动发现对象库),应用支撑层沿用省大救助的账户体系、已建技术支撑体系等,业务应用层主要包含:低收入人口采集系统、低收入监测模型、在册对象监测、持续监测对象预警、主动发现对象处理等。
3.1.2建设清单
按照建设目标及业务需求,建设功能清单明细如下:
序号 |
一级功能 |
二级功能 |
三级功能 |
简要描述 |
1 |
低收入人口数据库 |
低收入人口资源库 |
低收入业务生产库 |
存放社会救助对象以及横向部门业务系统所产生的业务数据,包括低收入家庭信息、低收入人员信息、救助享受信息、资金发放信息等。用于支持各级行政单位的业务经办、业务联动。 |
2 |
低收入业务规则库 |
根据低收入对象的类别,整理和归集不同的监测指标、监测规则,便于各类救助对象进行动态预警。分为在册对象预警规则、持续监测对象预警规则、政策救助规则等。 |
||
3 |
低收入人口基础库 |
基于杭州本地特色,对民政局在使用系统或者在册的低收入人员名单等文件进行梳理,按照相应的字段进行数据收集、数据清洗、数据整理等步骤,完成低收入对象、人口基础库的建立。 |
||
4 |
多部门数据库 |
对接市住保房管局、市应急管理、市医保局、市人力社保局、市教育局、市建委补贴等基础内容。 |
||
5 |
在册对象库 |
低保在册对象 |
建设低保在册对象数据库,通过收集、清洗、整合等方式将杭州市当前低保在册人员信息进行管理,主要字段包括姓名、性别、身份证号码、低保类别、致贫原因、联系方式、家庭住址等。实现对杭州市低保在册人员信息的统一管理。 |
|
6 |
低边在册对象 |
建设低边在册对象数据库,通过收集、清洗、整合等方式将杭州市当前低边在册人员信息进行管理。实现对杭州市低边在册人员信息的统一管理。 |
||
7 |
特困在册对象 |
建设特困在册对象数据库,通过收集、清洗、整合等方式将杭州市当前特困在册人员信息进行管理,主要字段包括姓名、性别、身份证号码、申请类别、致贫原因、联系方式、家庭住址等。实现对杭州市特困在册人员信息的统一管理。 |
||
8 |
持续监测对象库 |
退出民政救助对象(近3年) |
建设退出民政救助对象(近3年)数据库,收集整合杭州市近3年已退出低保、低边、特困、临时救助对象等信息,主要字段包括姓名、性别、身份证号码、救助类别、退出时间等。实现对杭州市退出民政救助对象(近3年)信息的统一管理。 |
|
9 |
新申请未通过对象(上年度+本年度) |
建设新申请未通过对象(上年度+本年度)数据库,收集整合杭州市上年度+本年度新申请救助但未通过的对象信息,主要字段包括姓名、性别、身份证号码、申请救助类别、申请时间、致贫原因、联系方式、家庭住址等。实现对杭州市新申请未通过对象(上年度+本年度)信息的统一管理。 |
||
10 |
临时救助对象(近1年) |
建设临时救助对象(近1年)数据库,收集整合杭州市近1年的临时救助对象信息,主要字段包括姓名、性别、身份证号码、救助类别、申请时间、联系方式、家庭住址等。实现对杭州市临时救助对象(近1年)信息的统一管理。 |
||
11 |
其他部门救助对象(近1年) |
建设其他部门救助对象(近1年)数据库,收集整合杭州市近1年其他部门救助对象的信息,主要字段包括姓名、性别、身份证号码、救助类别、申请时间、来源部门、联系方式、家庭住址等。实现对杭州市其他部门救助对象(近1年)信息的统一管理。 |
||
12 |
主动发现对象(近1月) |
建设主动发现对象(近1月)数据库,收集整合杭州市近1个月主动发现对象(主要为高额医疗费用对象)的信息,主要字段包括姓名、性别、身份证号码、救助类别、发现时间、联系方式、家庭住址等。实现对杭州市主动发现对象(近1月)信息的统一管理。 |
||
13 |
数据交换支撑系统 |
数据采集整合系统 |
数据采集整合系统 |
数据采集整合系统是指采用图形化的数据处理软件(ETL工具),用以实现大数据资源池形成过程中数据抽取、转换、装载、清洗、比对等功能。用户从数据源抽取出所需的数据,经过数据加工处理平台的处理,最终按照预先定义好的数据模型,将数据加载到应用数据库中去。 |
14 |
共享交换系统 |
任务管理 |
调度参数维护,对调度的公共参数:期数、进程数、数据日期、本期开始日期和本期结束日期进行设置和修改。 调度异常处理,对调度过程中出现的异常情况进行处理,提供错误查找、出错重跑功能。 |
|
15 |
服务器管理 |
配置多个服务器,可根据服务器的运行的任务实例情况和空闲情况,自动将批量采集任务实例在空闲的服务器上运行,达到服务器的负载均衡。 |
||
16 |
业务配置 |
管理员在资源库配置中设置数据库表相关信息,如:数据库表名、实例名、服务器IP、用户名、密码等。 支持各类数据库的连接,如:Oracle、MySQL、SQLServer等,能够适应目前大数据的需求。 |
||
17 |
系统日志 |
系统支持查看用户的操作日志。 |
||
18 |
API服务接口系统 |
用户管理工具 |
实现基于角色的用户管理,可以增加、删除用户和设置用户的操作权限。 |
|
19 |
应用管理工具 |
实现对要连接到数据交换平台的应用系统信息的管理,这些信息包括应用ID、应用名称、应用类型、应用描述、应用连接的业务接口网关等信息。 |
||
20 |
业务注册中心 |
业务注册中心提供远程业务注册和查询服务,应用系统可以把自己的对外服务封装成业务单元和业务单元集并发布到业务注册中心。 |
||
21 |
权限管理中心 |
实现平台管理资源的访问权限分配和与业务接口系统之间的权限信息同步。 |
||
22 |
身份认证服务 |
根据登入应用的签名验证应用的身份,保证登入应用的合法性,拒绝非法应用的登入。 |
||
23 |
数据信息交换 |
应用系统的信息能够从源应用系统通过业务接口系统和信息交换机可靠地传送到目的应用系统。为每个连接到它上面的应用系统分配应用ID,信息交换机依据应用ID而非网络地址实现不同应用系统之间的信息交换。 |
||
24 |
应用服务接入 |
支持接入Web Service、Http 服务或把本地传统服务程序封装成服务发布出去,实现应用到服务的自动生成和标准化。 |
||
25 |
低收入人口采集系统 |
低收入人口采集助手 |
低收入人口采集助手 |
相关工作人员根据实际情况,去到实际家庭现场,打开低收入数据采集系统(移动端),根据相应需要填报的数据进行查看、询问、填写等操作,完成低收入助手的数据上报,返回给大数据比对。 |
26 |
移动端自主申报 |
移动端自主申报 |
按照低收入人员的自行意愿,低收入人员可以通过移动端进行低收入的上报,完成相应信息的填写后,自动上报到大数据比对。 |
|
27 |
低收入人口大数据比对 |
低收入人口大数据比对 |
根据低收入收集助手和低收入人员自行申请的内容,反馈到大数据数据库,根据医保、教育、人社等多方面的相关部门信息,根据指标体系进行识别判断,明确其可以享受的政策,然后反馈到民政工作人员处,进行预警处理等步骤。 |
|
28 |
梳理数据维度/规则/清单 |
基础指数 |
基础指数 |
对低收入人口监测的数据维度中基础指数的管理,主要包括户籍人口数量、劳动力情况分析、文化程度、赡抚养人情况等。实现对基础指数内容的管理。 |
29 |
动态指数 |
动态指数 |
对低收入人口监测的数据维度中动态指数的管理,主要包括婚姻状况变化、残疾等级变化、人口数量变化、年龄结构变化、支出变化(高额医疗费用支出)等。实现对动态指数内容的管理。 |
|
30 |
指标规则设计 |
监测基本模型 |
基于杭州市本地特色以及需要监测的内容,构建一套人员监测的模型,如人员状态、财产情况、支出情况、残疾情况、其它状况 |
|
31 |
对象数据预警规则 |
基于以上低收入人口监测的模型及赋分情况,根据人员状态、支出情况、残疾情况等方面进行多维度的评估,将不同的分值进行不同的预警分类。首先进行等级赋值,按照指定规则进行指标计算,最后根据指标进行预警。 |
||
32 |
对象预警规则库管理 |
基于监测指标体系的各类指标类别,分别进行监测规则设置并建立相应的模型,每个事项都需要进行单独的规则整理,模型创建。 |
||
33 |
监测对象数据智能分析 |
算法层包含规则引擎和算法模型两大块,其中规则引擎主要职责在于基于规则自动完成监测指标的计算。算法模型的主要职责在于挖掘返贫对象,完成对即将脱离救助和救助边缘的人群进行监测,并及时预警,做到提前预防,提早准备,主动发现,提升服务。 |
||
34 |
对接数据/设计监测模型 |
对接数据/设计监测模型 |
民生直达对接 |
实现与民生直达的对接功能,通过对接获取的低收入人口数据将纳入到主动发现类别中,进行统一监管。 |
35 |
需对接数据清单梳理 |
如教育局数据:家庭成员各阶段受教育信息、中等职业教育贫困生等。人社局数据:社保缴交信息、失业登记信息等。 |
||
36 |
对接ODPS |
主要为基于省大救助数据交互体系,对接ODPS,执行开放数据的处理服务。 |
||
37 |
在册对象监测系统 |
在册救助对象库 |
在册对象数据监测主要是面向根据现有系统存在低保低边情况以及其他有记录的最低生活保障人员、最低生活保障边缘人员、特困人员供养对象,这3类人员建库并进行管理。 |
|
38 |
持续监测对象预警系统 |
持续监测对象管理 |
持续监测对象主要是面向近三年退出的低保、低边、特困人员;上年度和本年度新申请未通过人员;本年度享受临时救助的非在册对象;非在册其他部门救助对象(近1年);近一个月主动发现填报、因灾和医疗预警后未纳入救助的主动发现对象等,这几类人员可能会因为疾病、残疾、受灾等各类原因导致返回贫困状态,这时就需要对其进行监测,明确是否返贫,以便于进行相关的应对措施。 |
|
39 |
转临时救助/救助一件事/取消预警 |
实现持续监测对象转临时救助/救助一件事/取消预警等功能,根据持续监测对象的实际情况,对需要转临时救助、救助一件事、取消预警等处理的事项进行处理,按照业务规范要求,系统支持查看、上传附件、上传等操作。 |
||
40 |
残疾等级变更预警 |
实现持续监测对象残疾等级变更预警的功能,根据持续监测对象的实际情况,如果因残疾等级变化导致收入同步变化的,根据残疾的程度及详细内容的数据监测,按照预警指标体系进行及时的预警关注。 |
||
41 |
婚姻状况变更预警 |
实现持续监测对象婚姻状况变更预警的功能,根据持续监测对象的实际情况,如果因婚姻状况发生变化导致收入发生同步变化的,根据婚姻状况变化与收入变化的监测,按照预警指标体系进行及时的预警关注。 |
||
42 |
死亡预警 |
实现持续监测对象死亡预警的功能,根据持续监测对象的实际情况,如果持续监测对象家庭出现人口死亡而导致收入发生变化的,根据公安、殡葬数据等方面的监测,按照预警指标体系进行及时的预警关注。 |
||
43 |
新生儿预警 |
实现持续监测对象新生儿预警,根据持续监测对象的实际情况,如果家庭出现人口新增而导致收入发生变化的,根据公安、卫健数据等方面的监测,按照预警指标体系进行及时的预警关注。 |
||
44 |
高额医疗费用支出预警 |
实现高额医疗费用支出预警的功能,根据持续监测对象的实际情况,如果因病情加重或者恶化导致收入发生变化的,根据卫健医疗支出数据等方面的监测,按照预警指标体系进行及时的预警关注。 |
||
45 |
数字驾驶舱 |
低收入数字驾驶舱 |
低收入数字领导驾驶舱是针对各级领导进行整体管理和综合分析的个性化管理系统,经授权后,可任意添加需要的查询、分析模块。各模块分布在一个统一的工作界面下,可进行综合对比分析。工作界面下,各查询分析子模块,实时自动刷新,保证数据的准确、真实。便于领导预测与决策。对于不同级别的管理者,只要有需求,经授权后,均可形成自身的驾驶舱管理。 |
|
46 |
低收入人口专题分析 |
基于低收入数据库数据,从预警监测、低收入人口监测、低收入人口地图三个方面,利用大数据技术构建数据挖掘模型,通过将各类数据进行多维度计算、统计、组合,以图表、表格、文字说明等作为分析结果的展示形式,直观、准确的展现分析结果。 |
||
47 |
数智救助融合数字社会 |
专题内容分析图例展示 |
对各个专题分析完成的内容进行展示决策的模块,主要是通过各类数据,进行分块展示提供辅助决策的内容,通过柱状图、饼状图等统计图以及统计表形式展现。 |
|
48 |
弱有所扶——核心业务 |
展示弱有所扶的核心业务专题分析内容,通过柱状图、折线图、气泡图、饼图等图文结合的形式,将幸福清单发放情况、救助事项增加情况、友爱服务完成情况等大类综合监管业务进行直观展现,为领导分析决策提供辅助依据。 |
||
49 |
弱有所扶——资源分配 |
展示弱有所扶的资源分配专题分析内容,通过柱状图、折线图、气泡图、饼图等图文结合的形式,在地图内容的信息基础上,按地区展示各类登记在册的救助机构、养老机构以及其他服务机构的所在地点,协助完成对整个地区资源分配的查看分析。 |
||
50 |
弱有所扶——民生保障 |
展示弱有所扶的民生保障专题分析内容,通过柱状图、折线图、气泡图、饼图等图文结合的形式,主要展示内容涉及政府救助部门对救助最低标准,包括地区救助事项的数量、救助保障最低标准等内容,对领导分析决策起到辅助作用。 |
||
51 |
弱有众扶——资金监管 |
展示弱有所扶的资金监管专题分析内容,通过柱状图、折线图、气泡图、饼图等图文结合的形式,将救助的资金以及友爱服务帮扶中的各类资金统一进行监督管理,明确流向,包括救助资金统计、救助资金标准、友爱服务资金统计等,协助领导完成资金救助方向的监督管理内容。 |
||
52 |
弱有众扶——人员分类 |
展示弱有所扶的人员分类专题分析内容,通过柱状图、折线图、气泡图、饼图等图文结合的形式,将社区的群众与工作人员各项指标进行系统地展示,包括社区群众统计、社区群众类型管理、社区工作人员统计等,协助完成人员的分类与统计决策。 |
项目采购清单如下:
子系统名称 |
一级功能模块 |
二级功能模块 |
说明 |
【服务端】居家助老 |
统一用户认证 |
统一用户认证 |
基于政务服务网的用户体系,实现各应用系统的用户集成和统一的用户身份验证 |
首页 |
首页 |
用户的场景化展台 |
|
找政策 |
找政策 |
输入老人基本信息,便可精准匹配能够享受到的各类养老政策 |
|
一键申请 |
家庭养老床位申请 |
一键在线发起申请“家庭养老床位服务”(联动省厅能力评估结果数据,实现对家庭床位申请对象资格的认定) |
|
入住养老服务机构护理补贴申请 |
一键在线发起申请“入住养老服务机构补贴”(联动省厅能力评估结果数据,实现对入住养老机构护理补贴申请对象资格的认定)。 |
||
智慧终端设备申领 |
为主城区政府认定保障的老年人提供呼叫终端设备的在线申领 |
||
康复辅助器具租赁申请 |
一键在线发起申请“康复辅助器具租赁” |
||
找活动 |
找活动 |
一键找活动 |
|
找服务 |
找服务 |
一键找服务 |
|
找美食 |
找美食 |
一键找美食 |
|
找辅具 |
找辅具 |
一键找辅具 |
|
家庭支持 |
家庭支持 |
为老人提供一些基础的情感陪伴的“家庭支持”服务 |
|
幸福清单 |
幸福清单 |
查询老年人在享受的养老补贴,同时也会显示老年人应该享受还未享受的养老政策 |
|
我的 |
我的 |
包括个人地址、居家服务清单等 |
|
【服务端】智慧养老院 |
软件基座功能 |
资源管理 |
包括基本信息管理、工作人员管理、入住老人管理及驾驶舱大屏 |
智慧服务 |
智慧服务 |
包括参观预约、探访预约、入住预约、住户管理、租赁管理、群众监督 |
|
智慧照护 |
智慧照护 |
包括能力评估、照护计划、床位使用、照护实施、服务响应、健康管理 |
|
智慧交流 |
智慧交流 |
包括健康资讯、健康宣教、活动管理、老友圈 |
|
智慧管理 |
智慧管理 |
包括数字化治理、护理员管理、服务管理、财务管理、收费管理、捐赠管理、物资管理、设备管理、系统管理 |
|
智慧安防 |
智慧安防 |
包括安全巡防、疫情防控、消防安全、食品安全 |
|
家属/老人移动端 |
家属/老人移动端 |
提供账单查询、预存缴费、探访预约、服务点单、健康监测、护理记录、服药提醒、租赁记录、远程探视、养老日历、养老地图、老友圈、老幼所学、消息推送、我的等多种业务场景下的移动端应用 |
|
与“浙里养”平台对接 |
与“浙里养”平台对接 |
包括用户体系对接和组件调用 |
|
【治理端】康养联合体 |
康养联合体 |
康养联合体 |
包括康养地图、康养对象画像、康养服务转介 |
【治理端】认知症长者照护数字化专区 |
认知症老人档案管理 |
认知症老人档案管理 |
通过归集全市认知症长者档案信息,平台实现对认知症长者信息的管理 |
基础设施数据 |
基础设施数据 |
通过归集全市基础设施数据信息,实现对院内各类智能定位、行为异常、呼叫和健康异常等情况报警的相关设施设备信息的管理 |
|
综合评估筛查 |
综合评估筛查 |
通过调用成熟的综合评估筛查工具,实现对部分老人的认知障碍初步筛查,并形成记录。 |
|
照护服务数据 |
照护服务数据 |
通过归集全市照护服务数据信息,实现认知照护记录的全市汇聚管理。 |
|
数据看板 |
数据看板 |
通过对认知症相关数据的汇聚对接,实现认知症长者照护数字化专区的门面 |
4.1技术规范
本项目应符合政务云部署规范要求,基于JAVA语言开发,MYSQL数据库,采用B/S结构,采用面向服务的组件化开发框架,可在IE11及以上版本的浏览器上正常运行,服务运行端支持Windows操作系统。
4.2与原系统无缝衔接要求
此次采购内容是对“浙江省大救助信息系统”和对“杭州市互联网+养老平台”的升级完善,实现本项目建设内容开发的同时,必须与原有系统完全兼容,并无缝集成,不影响原有业务操作。涉及与原系统承建单位的技术对接、改造的相关费用由成交单位自行承担,采购人可提供协助对接事宜。涉及数据迁移在非工作日晚上12小时内完成所有数据的迁移,且不影响现有业务操作,如造成系统瘫痪、数据丢失、功能不能正常使用的,承建单位必须承担相应的责任,甲方有权单方面终止合同。
深入贯彻习近平总书记关于民政工作的重要指示批示精神,全面落实省市数字化改革工作决策部署和全省数字化改革重大应用“一本账S1”建设要求,以数字化改革撬动民政领域共同富裕、推动民政事业高质量发展为总体目标,重点聚焦养老服务、困境未成年人关爱保护、困难群体救助、移风易俗、公益慈善等五个领域,通过建设“善杭州”数智民政民生治理项目,推进数字民政体系建设,实现多跨协同、两端赋能,形成政府主导、居民共享、社会参与的“智共体”,积极助力杭州成为高质量发展建设共同富裕示范区的城市范例,为“数字社会”建设切实扛起民政担当。
二、建设目标
落地“一本账”省民政厅“浙里逝安”应用场景建设任务,主要是深化杭州市数智殡综合应用场景。大力推行“全数字、全覆盖、全流程的”殡葬改革,按省民政厅统一标准迭代杭州市“数智殡”平台,完善浙里办服务端、浙政钉治理端的应用和多跨协同联办应用场景。
二、 建设内容要求
(一)完善杭州市已故人口主题数据库
1)完善标准:总结一期经验,完善杭州市已故人口主题数据库数据规范和杭州市已故人口主题数据库架构。
2)数据清洗:对历史数据进行清洗和碰撞。
3)数据对接:建立和杭州市联办系统对接,建立动态实时数源数据采集机制;
(二)建设杭州数智殡应用
建立统一的殡葬资源基础信息标准规则,实现网上协作,规范管理流程,提高运作效率;按省民政厅统一标准迭代杭州市“数智殡”平台,浙里办应用服务端建设浙政钉应用治理端建设。
1.标准规范编制
根据殡葬事项联办业务要求,在民政部《殡葬管理服务信息系统数据共享和交换规范》(MZ/T 141-2019)和浙江省民政厅《浙江省殡葬(殡仪服务)数据共享与交换编码》的基础上,增补相应的数据内容,确立合理的数据结构以及技术标准,制定《杭州市民政局逝者信息接口规范》、《杭州市“数智殡”数据归集接口规范》。
2.身后“一件事”数据库建设
按照《殡葬管理服务信息系统数据共享和交换规范》(MZ/T 141-2019)和《浙江省殡葬(殡仪服务)数据共享与交换编码》相关要求,进行数据资源设计和建设。
3、杭州市“数智殡”系统(基础平台)
受理居民死讯报告,民政协理员(网格代办员)、卫健专员、公安专员应在12个小时内上门进行丧情确认。民政协理员(网格代办员)采集死亡人员基本信息、骨灰安放、福利、出殡预约等报丧信息,登录联办信息平台在线填写报丧信息,将信息推送至卫健、公安部门。殡仪馆专员根据推送的报丧信息进行出殡预约,完成信息处理。殡仪馆按照预约时间接运遗体,根据死亡签章信息办理遗体火化手续,并将火化证明等办理结果上传联办信息平台。
1)系统维护
从实际使用来看,联办部门登录查询和数据调整确实有必要,从系统完整性角度考虑,按照单位(政府、民政局、公安局、卫健委、社保局、医保局、公积金、退役军人、残联)划分,分别赋予独立部门管理员和权限自主分配的模式重新构建用户体系。
1. 行政区划管理:对本市行政区划进行管理,系统建立行政区划数据库,具体到街道、村,对应到代办员、协办单位,便于逝者和代办员进行对应,便于系统协办任务的分发。
通过行政区划设置以及相关工作人员对应的区划,实现相关业务办理范围和业务数据的筛选和查询。
2. 角色管理:对角色进行管理,建立不同的角色使每个用户拥有不同的角色权限、角色名称、角色描述和选择角色功能。可以对角色进行新增,配置角色名称、角色描述等基本信息及角色所拥有权限;根据角色分配权限,可以对基本信息的修改和删除等操作。
3.权限管理:对使用本平台的用户和用户具备的操作权限进行管理。对用户的权限进行设置,可实现权限信息的维护、人员权限设置、菜单权限设置、按钮权限设置、角色权限设置。
4.用户管理:对用户进行管理,建立用户并选择相应的角色功能。可以对用户基本信息进行新增,配置登录名、用户名称、手机号、电话号码、部门编号、用户角色等基本信息及用户拥有的权限,根据用户分配权限,可以对用户基本信息进行修改、删除等操作。按照不同的单位(民政局、公安局、卫健委、社保局、医保局、公积金、退役军人、残联)、用户账户、密码登录该系统。可配置和修改用户登录的密码。
5、附件管理:优化证明材料的管理、对数据来源一致性管理:如果家属和死者身份证、死亡证明、联办单、非正常死亡处理意见书等。
2)死亡证明数字化
卫健委已经完成本系统内《居民死亡医学证明(推断)书》数字化改造,且医生驻馆开具死亡证明,可以确保火化前死亡证明和火化手续完成。(本次建设不包含电子签章费用)
公安部门需要签发非正常死者遗体处理意见书,但因为没有系统支持,长期以来都是纸质手写,为实现联办流程全程证明文件数字化的目标,专门为公安部门搭建了非正常死者遗体处理意见书的签发模块。(本次建设不包含电子签章费用)
3)联办登记模块
联办部门(民政局、公安局、卫健委)的业务专员登记逝者信息,并标记登记状态,分为填报中(卫健、公安已经在填写资料,但没有推送到殡仪馆;)、待审核(非正常死亡等待公安审核的死者列表)、已冻结(家属对正常死亡有疑议报公安部门处理,公安部门对已审核状态死者主动发起冻结,待调查到位后审核放行;)、已审核(火化手续齐全等待火化;)、已火化(死者已经火化,可以查看联办单和证明文件;)、已注销(公安已经注销逝者户口;)、已外运(逝者遗体已外运)等不同状态,可进行新增、附件上传、查看操作历史等操作。包括:联办新增、联办查询、联办修改、附件上传、联办提交、.联办审核、联办冻结、户口注销
4)联办办结模块
联办部门(社保、医保、公积金、退役军人、残联)业务专员进行联办办结事项管理。
1.联办详情:可按照逝者姓名、身份证号、业务编号、开始时间、结束时间、地址等信息搜索展示联办办结情况列表,可查看联办详情,包含基本信息、联办结果、附件信息。
2.联办结果,可查看办结时间、办结结果(火化证明已开具、死亡证明已开具)、办结状态、办结单位等信息;
5、 杭州市“数智殡”浙里应用办服务端
1)联办申报
联办申报分为家属本人办理和代为办理两种方式。逝者家属一站式预约,预约火化日期,系统会自动通知殡仪馆联系火化事宜、卫健委上门开具死亡证明、社区上门了解情况等;代办人员代为申报身后事一站式预约,系统会自动通知乡镇和医院办理。
2)联办进度
按省政府要求上报联办数据,实现基于浙江省政务服务网和浙里办查询联办进度功能,包含与逝者相关信息、联办信息、联办证明文件等附件信息。
3)部门信息
各联办部门介绍及联系方式查询、办事地点、办事指南等。
4)常见问题
整理常见问题,发布提示家属注意事项。包括更新模块。
6、 杭州市“数智殡”浙政钉应用治理端
1)用户登录
按照各联办部门(民政局、公安局、卫健委、社保局、医保局、公积金、退役军人、残联)所分配的用户账户和密码登录浙政钉手机端。
2)任务分发(后台)
公安、卫健委、殡仪馆等联办单位的业务人员按照所分配得权限,按照逝者所属乡镇进行任务分发和联办数据填报、变更和审核操作。
3)联办填报
采用初始填报人负责制,各相关的联办部门(民政、公安、卫健委)的业务人员基于浙政钉手机端申报联办数据,包含逝者信息、预约信息、家属信息,并支持身份证资料自动读取。
4)信息变更
卫健委的业务人员针对医院出具死亡证明推送出错的或选择殡仪馆出错的情况,可在浙政钉手机端进行独立操作修改逝者资料,实现申报信息取消、联办数据修改功能。
公安部门的业务人员还需针对非正常死亡的逝者信息进行审核或取消审核处理,针对家属报警的逝者信息进行冻结操作,对已通过联办数据审核的逝者进行户口注销等操作。
5)查询功能
各联办部门的业务人员可基于浙政钉手机端输入逝者姓名、身份证号码进行逝者信息查询,同时可提供异地查询功能。
(三) 建设杭州浙里逝安微场景
建立网上祭祀功能,建立完善的绿色生态安葬的闭环,开发祭扫网上预约功能,建立有序可控的节日密集型祭祀新次序。
1.浙里办-扫墓预约
每年的清明、冬至是我们中华民族缅怀英烈、悼念先人、扫墓祭祖的重要时段,也是森林火灾的高发风险期。加之当前新冠肺炎疫情的防控需要,为避免陵园祭扫引发的人流聚集,减少疫情传播风险,引导群众转变祭祀观念,“云祭祀”和陵园扫墓预约的倡导与推广,都符合倡导文明祭祀的宗旨。
扫墓预约系统,由公众浙里办预约应用、陵园入口刷卡验证插件和管理后台三部分组成。
1)预约入口
增加亲友预约扫墓邀请功能,主要是完善资料建立长期的人员关系库、非疫情期间可以去掉健康码比对。
2)入园验证(为防止意外可以增加电脑端读卡模式、扫预约手机端直接跳出通过的模式)
为减轻入园时安保人员的审验工作强度,供了专用信息终端提供刷卡(身份证)及读码(预约二维码)验证功能。专用APP来实现预约及健康码数据的验证。
符合预约时间,且健康码为绿色的人员,经验证可以入园,系统提示“绿码”。如果健康码为黄色或红色,设备将提示“红码”、“黄码”的语音。如果发现是不在预约时间段内,设备也会提示错误的语音。
如果扫墓人没有携带身份证,还可以通过刷预约码的方式进行机器验证。
3)管理后台
管理后台,是民政或陵园管理人员查看预约数据,管理预约活动的后端。
系统提供数据驾驶舱,让管理人员第一时间能看到扫墓预约活动的全部信息。通过地图,查看特定公墓、陵园的当日入园情况。
还提供报表导出功能,提供管理人员活动统计用。
2.浙里办-网上祭祀
1)基础数据获取工作
基础数据获取的目标,就是要将全市主要的公益性陵园、骨灰堂、殡仪馆寄存数据逝者落葬信息的数据按规则归集到平台上。
2)网上纪念馆
如果家属能提供墓穴证号与墓穴证持证人姓名进行验证,可以一步便捷建馆完毕,该纪念馆和实体墓对应。
纪念馆背景提供多种可选模板,比如古典、欧式、新中式、现代等多个风格,包括敬献的供品、鲜花等,都在美观度上做进一步提升。网上纪念馆只提供单人馆与双人馆功能。
3)网上祈福
亲友打开建馆人发来的地址链接的就是祈福操作画面。可以将纪念馆地址链接发到亲友群或朋友;为纪念馆上香、上烛;为纪念馆上献花与贡品,同时可选择滚动的祈福语录;可展示亲友祈福记录;可以看到亲友到访与拜祭记录;
4)礼敬专区
对骨灰撒散树葬海葬等生态葬逝者设立纪念专区,使逝者有所寄。入口进去是公共纪念页面,背景分别选用特定环境且有纪念意义的布景,相关逝者名字可在上方缓缓飘过,同时也提供公众或家属敬献鲜花的功能。即设立逝者信息滚动屏,纪念者拜祭记录滚动屏和鲜花摆放台。
5)浙里办-入葬查询
为便于家属可以确定入葬地点,提供就近公墓(骨灰堂)查询,包括:位置、基础情况、价格、墓区图片、是否有相关奖补政策等。
(三)系统接口
需与外部联办部门的数据共享,主要是联办信息交互的数据归集接口、事项联办接口和数据共享接口。
(1)数据归集接口,主要包括逝者申报数据归集接口、逝者受理数据归集接口、逝者火化数据归集接口、联办申报与办结数据归集接口;
(2)事项联办接口,主要包括登记受理(批量)数据获取接口、死亡证明资料获取接口、联办附件上传接口、联办附件获取接口、火化业务办结(仅殡仪馆使用)接口、其他业务联办办结接口、死亡信息查询接口;
(3)数据共享接口,与杭州市公共数据平台对接。
四、系统性能需求
(一)设计要求
1)易用性:软件设计研发使用的技术不对浏览者使用的浏览器有特殊要求,软件操作界面简洁,方便各类操作人员操作使用。
2)高效性:软件页面的设计大气、美观、简洁,尽可能地提高浏览速度,突出主要信息。软件导航层次清晰,方便浏览者对相关信息的访问。
3)结构合理:栏目设置合理,符合人们的浏览习惯。软件层次设计合理,让操作者可以通过尽可能少的点击次数即可找到需要的信息。
4)可扩展性:软件设计已考虑到业务未来发展的需要,同时考虑软件使用的阶段性,要尽可能地设计得简明,各个功能模块间的耦合度小,便于软件的扩展,平滑地与其它应用软件自动接口。
(二)技术要求
1)基于三层结构开发技术。
2)采用面向服务的体系结构。
3)通过跨平台设计,支持国产化操作系统,符合规范的各类应用服务器、主流数据库。
4)符合国家市场监督管理总局、浙江省民政厅相关技术标准、数据标准。
5)具备与其他业务系统进行信息交换的接口;具备多种开发工具接口,支持用户定制功能。
6)网站页面的布局开发完全按照W3C标准,兼容IE、Firefox、Chrome等主流和非主流浏览器访问以及WAP访问。
7)系统能提供优异的性能,提供集群功能,支持集群内垂直扩充和水平扩充,支持不同的异构操作系统之间的多机集群实现,方便部署时设备利用。
(三)性能要求
系统应能支持100个以上并发用户的访问;
在线查询信息的平均时间要求不超过3秒;
系统提供良好的业务响应时间、后台处理的匹配关系,每次业务处理时间应在 5秒内完成;
系统应能支持兆级规模数据的快速存储,其中,千条数据以内的数据加载和存储,平均响应时间在 2 秒之内;千条数据以内的统计,平均响应时间在 5 秒之内;
常用报表及汇总分析响应时间不超过5秒, 复杂报表及汇总分析响应时间不超过10秒;
运行时间要求:要保证能够在24小时×7天的时间内提供服务,系统的可用时间百分比不低于 99%;
系统故障率:系统能够稳定地运行,平均故障间隔时间不少于2个月;
平均修复时间:不超过6小时;
系统部署在杭州城市大脑,依托已有电子政务网络架构,遵循现行标准及相关要求,切实履行使用和管理职责。
(四)对接要求
1、各区县(市)在用联办系统数据(含过程数据)无缝移植到新系统;
2、能与省民政厅共享交换平台、联办数据、内外部共享、火化证明证照等结构化数据的完全对接;
3、能与浙江省民政厅现有省殡葬管理信息系统功能兼容;
数智慈善子系统建设将聚焦全市公益慈善组织、团体、个人为重点应用对象,以现代信息技术为支持,对公益慈善的组织方式、管理机制等进行系统性重塑,提升精细管理、高效服务的能力,从而更好地满足新时代公益发展的要求。打造数字捐赠应用和慈善资金监管体系;构建公益慈善资源互通模块,便利慈善组织、政府单位、企业、学校等群体之间的困难群体资源的共享;构建公益慈善的移动端门户,为广大的爱心群众提供线上捐赠便捷入口;初步构建公益码,提供积分落户等权益服务;构建资金监管体系,一图展示全市公益慈善的现状及场景运营情况;通过民生直达平台完成慈善资金的发放,让慈善资金的发放更标准、更统一、更规范。
建设的主要内容包含:
(1)公益慈善应用场景:市场项目板块、慈善组织管理、便捷捐赠管理、接入方管理、项目信息管理、公共需求对接管理等。
(2)基础功能模块建设:支付管理平台、用户管理中心、权限管理、消息管理 、日志管理、全文检索等。
(3)公益慈善移动端建设。
(4)民生直达平台对接。
(5)公益慈善驾驶舱建设。
(6)数据对接:省平台数据对接(慈善系统、救助系统等);市平台数据对接(一体化智能化公共数据平台);杭州银行对接;民生直达对接。
(7)数字捐赠应用。
序号 |
系统 |
一级模块 |
二级模块 |
功能介绍 |
1 |
功能组件板块 |
市场项目板块 |
建立市场项目 |
各街道(或者慈善组织)在公益慈善系统建立市场项目,根据不同的业务板块,设定多样化的模板 |
2 |
市场项目发布 |
对项目进行审核发布,项目发布后,该项目标记“认领中”状态。同时将项目发布到“公共需求对接(全市)”(场景PC管网) |
||
3 |
市场项目对接 |
街道在发布市场项目后,各慈善组织可以在该平台进行项目认领;慈善组织发布市场项目后,可以在该平台进行需求对接。系统设计各慈善组织可以认领其中一部分 |
||
4 |
市场项目审核 |
慈善机构认领项目后。需要对所有数据进行审核,人员资格的审核以各人员/清单提供方自行审核为主,慈善机构做二次审核;逐步实现智能化复核。 |
||
5 |
市场项目执行 |
根据审核后的项目待执行表单,慈善组织根据需求表单进行募捐、救助、志愿等工作(与其他模块打通) |
||
6 |
信息公开 |
线上流程形成闭环,对项目整体情况在管理端进行公开。同时会在用户端进行项目情况公布 |
||
7 |
公共需求对接 |
公共需求对接模块主要将慈善组织、街道、政府、需求者等多方的资源和需求对接提供一个公共的服务平台。资源方和需求方能够更好地利用资源流转通道。逐步对接省市救助业务平台。 |
||
8 |
慈善组织管理 |
组织信息管理 |
维护慈善组织的基本信息、人员信息(系统人员)等。通过一体化智能公共数据平台获取省市两级的数据(省公益平台、监管部门等),减少人为维护。本模块的信息主要应用于公益市场和移动端的信息展现 |
|
9 |
募捐方案信息 |
提供对慈善组织募捐方案的查看以及维护功能等。通过一体化智能公共数据平台获取省市两级的数据获取信息,减少人为维护工作。本模块的信息主要应用于移动端的展现。 |
||
10 |
慈善项目信息 |
提供对慈善组织慈善项目的查看以及维护功能等。充分考虑通过数据共享获取信息,减少人为维护工作。本模块的信息主要应用于移动端的展现。 |
||
11 |
慈善信托管理 |
慈善信托信息 |
慈善信托信息,慈善信托列表,查看所有备案的慈善信托。 |
|
12 |
慈善信托备案 |
慈善信托备案,新增慈善信托备案,删除,修改等操作。 |
||
13 |
慈善信托进度披露 |
慈善信托进度披露。 |
||
14 |
便捷捐赠管理 |
收款渠道维护 |
各慈善组织管理员可以维护支付宝/微信等快捷支付通道(前期由专业技术人员配置调试);默认对接杭州银行财资管理平台。完善接入方管理。 |
|
15 |
便捷捐赠项目绑定 |
慈善组织的系统管理员可以将支付渠道与慈善项目进行绑定 |
||
16 |
便捷捐赠流程 |
便捷捐赠流程主要指在移动端的信息公开到便捷支付的整套流程(捐赠项目发布;本地募捐发布;捐赠项目排序设置等) |
||
17 |
捐赠记录 |
捐赠信息主要展现慈善组织在该业务平台的捐赠记录。(组织管理员也可以通过手动的方式进行其他平台的捐赠记录维护) |
||
18 |
收入情况/支出情况 |
各慈善组织的便捷捐赠收入情况,通过时间、项目、区域等维度进行统计。结合财资管理平台实现收支情况管理。 |
||
19 |
基础功能板块 |
支付管理平台 |
公益慈善板块的支付管理平台;对接微信/支付宝等支付通道。提供财务对账中心和监控预警(个性化配置,短信预警)。默认对接杭州银行财资管理平台及提供技术服务。 |
|
20 |
用户管理中心 |
系统整体涉及的用户类型较多,涵盖不同功能版块的用户类型,实际场景中会与平台产生交互的用户,包括个人(捐赠人、权益人),政府管理人员(市县区),慈善组织人员,街道人员,开发人员,管理员等。 |
||
21 |
权限管理 |
权限中心负责向平台应用端提供统一的授权管理服务,市民端用户只能访问外部门户(移动端),政府端用户提供不同角色权限管理,按照权限划分可分为系统管理员、部门管理员和审批人员等 |
||
22 |
消息管理 |
消息管理中心为平台提供统一的消息处理能力,通知除具备系统内部弹窗消息提醒外,支持对接运营商短信或第三方即时消息App接口,根据业务场景需求自动发送或者自定义推送通知提醒消息。 |
||
23 |
日志管理 |
日志管理主要提供对用户操作日志、登录日志进行统一管理(多系统、多端) |
||
24 |
全文检索 |
全文检索为平台各用户端提供统一的全文检索服务 |
||
25 |
公益慈善管理平台 |
运营管理平台 |
登录/退出 |
慈善组织、政府管理(市县区)等用户群体操作使用的平台。其中街道等组织考虑以PC门户网站的形式单独开发访问。 |
26 |
组织信息 |
组织基本信息、人员管理、权限管理等相关的操作功能 |
||
27 |
募捐方案管理 |
募捐方案的相关功能;同时包括发布撤销等功能(管理员操作) |
||
28 |
慈善项目管理 |
慈善项目的相关功能; |
||
29 |
便捷捐赠管理 |
便捷捐赠管理的相关功能;包括支付渠道管理 |
||
30 |
市场项目管理 |
市场项目的相关功能;包括发布、审批、审核等功能 |
||
31 |
消息管理 |
消息管理的相关功能 |
||
32 |
审批流程 |
审批流程的相关功能 |
||
33 |
后台管理平台 |
埋点管理 |
基于统一开发平台的埋点管理,形成的埋点后台管理体系 |
|
34 |
统一用户管理 |
运营管理平台用户(慈善组织、政府、街道等)和乘客端用户 |
||
35 |
访问情况管理 |
为防止对信息系统的未经授权的访问,应当有正规的程序来控制对信息系统和服务的访问权限分配,按用户身份及其所归属的某项定义来限制用户对某些信息项的访问,或限制对某些控制功能的使用的过程就叫做访问管理 |
||
36 |
公益码管理 |
根据各级权重和算法,生成个人的公益码信息。公益码相关功能:算法规则、领取情况、更新情况等 |
||
37 |
权益管理 |
管理所有的权益信息,技术人员封装每个权益的算法,以判断用户是否符合权益规则。 |
||
38 |
发票管理 |
在线电子发票管理。记录管理、对接管理、运营管理等。 |
||
39 |
预留扩展性功能 |
预留扩展性功能通道。 |
||
40 |
公益慈善移动端 |
移动端开发 |
首页 |
移动端首页的设计开发。首页主要呈现功能模块的入口和募捐方案列表,智能推荐等信息。 |
41 |
公益活动/项目分类 |
公益活动包含各类公益项目发布的信息(含合作公益参与人员的要求等)、公益扶持的内容、专项公益信息如脱贫扶贫内容,已经各类公益活动中优秀的风采内容展示。多维度呈现设计开发。 |
||
42 |
慈善组织 |
慈善组织信息 |
||
43 |
公益爱心客 |
公益爱心客是展示各类积极参与公益事业组织和个人的窗口。各类公益大侠的风采展示,公益榜单的展示 |
||
44 |
我的 |
登录/登出;我的捐赠、发票记录、公益权益、公益码等 |
||
45 |
智能搜索引擎 |
搜索引擎功能 |
统一搜索引擎功能:捐赠项目、公益组织等 |
|
46 |
多渠道接入 |
多渠道接入 |
移动端系统接入城市客户端APP、浙里办、微信小程序、支付宝小程序。 |
|
47 |
公益慈善数字驾驶舱(善治) |
公益慈善数字驾驶舱 |
驾驶舱指数梳理 |
应用场景驾驶舱指数梳理,尽可能反映场景运行情况。逐步梳理全市公益慈善情况的业务型驾驶舱指数。 |
48 |
驾驶舱UI设计 |
参考驾驶舱建设规范,结合指数进行UI设计。 |
||
49 |
驾驶舱开发PC端 |
驾驶舱开发PC端 |
||
50 |
驾驶舱开发移动端 |
驾驶舱开发移动端 |
||
51 |
民生直达公益慈善接入 |
民生直达公益慈善接入 |
民生直达公益慈善接入 |
慈善资金的发放以市县区统一牵头,各市县区在民生直达平台接入公益慈善的资金兑付入口,通过民生直达兑付平台,可以完成慈善资金的发放 |
52 |
慈善杭州门户 |
慈善杭州门户框架 |
慈善杭州门户框架 |
慈善杭州门户包括:登录、认证、搜索、个人中心、bannner、消息和公告、场景管理等模型 |
53 |
浙里办对接 |
浙里办对接 |
根据“浙里办”的接入规范,进行场景的接入适配。系统上架“浙里办”应用市场。 |
具体见招标文件