专项数据智慧管理及上报平台建设方案

专项数据智慧管理及上报平台建设方案

目录

1.项目建设背景....................................................3

2.建设标准与原则..................................................4

2.1.遵循的相关标准..............................................4

2.2.遵循的原则.................................................6

3.项目建设目标....................................................8

4.项目功能需求...................................................10

5.技术指标要求...................................................20

5.1.总体技术要求..............................................20

5.2.数据采集..................................................22

5.3.数据管理..................................................23

5.4.数据治理..................................................23

5.5.平台数据监控..............................................24

5.6.后台管理..................................................24

6.系统安全要求...................................................24

7.实施、培训、运行、售后及验收要求...............................30

7.1.系统实施要求...............................................30

7.2.培训要求...................................................31

7.3.运行要求...................................................32

7.4.售后服务要求...............................................32

7.5.验收要求...................................................33

7.6.其它要求...................................................33

1.项目建设背景

最近几年，无论是国家层面、省市层面，还是卫健委、医保局等

管理部门，都在强调加强大数据应用的建设，充分有效释放数据的价

值。国家、省市卫健委近年颁发的总体规划及相关规范或指导办法,

总体设计的目标是通过抓取基础信息化系统的过程数据，进行数据分

析和应用，从而通过数据来提升管理决策精准度。而随着医院信息化

向深度和广度发展，信息化系统所产生的数据越来越多，也越来越重

要。

在中山大学附属第一医院的日常管理过程中，需要面向各级管理

部门报送多种数据，但因为医疗数据涉及到用户的个人隐私，医院的

信息化系统和数据库基本都是部署在医院的局域网内，各自的对接上

报系统不尽相同，接口方式不统一，技术要求不统一等现存问题也为

医院的数据上报管理工作带来了诸多困难，需投入大量的人力物力来

支持；目前我院现有的数据上报系统，包括HQMS上报系统、不良事

件上报系统等，因建设时间不一、数据标准存在差异等诸多历史原因，

导致目前各类数据上报工作存在数据冗余、各自为战的情况；同时也

因医院基础信息化的建设比较完备，各个系统产生和留存的数据非常

之多，这些数据在给医院带来管理成本之余，其数据的强大价值也尚

待挖掘。

基于医院现有信息化建设的成果，以及面对医院数据上报面临的

难题，医院现拟规划建设一套全院级、松耦合、高内聚的标准上报数

据中心，并在此基础上打造一个能统一规划数据提取、治理和上报的

专项数据智慧管理及上报平台，用以全面高效科学管理和应用好医院

的数据资产，挖掘数据潜在价值，并为未来以数据驱动业务发展提供

切实可靠的抓手。

2.建设标准与原则

2.1.遵循的相关标准

由于本项目中需要从医院现有各个业务系统中抽取大量信息，而

这些信息来自各个业务系统，加之目前医疗信息领域的标准规范尚未

完善，因此，对于这些由不同厂商在不同时期建立的各个业务系统,

采用的数据结构、数据类型与数据尺度等各不相同，为信息集成带来

较大的麻烦。故，本项目建设应遵循国际、国内已经颁发的医疗信息

化建设标准，且可根据实际情况自定义数据标准，具体包括：

1.《关于促进“互联网+医疗健康”发展的意见》

2.《电子病历基本规范（试行）》

3.《健康档案共享文档规范》

4.《住院病案首页数据填写质量规范（暂行）》

5.ICD9

6.ICD10疾病诊断字典

7.XML输出标准

8.HL7

9.DICOM标准

10.《IS09000质量体系标准》

11.《国家电子政务标准体系》

12.《国家电子政务标准化指南》

13.《国家电子政务综合业务网总体技术要求》

14.《国家电子政务术语》

15.《国家电子政务信息安全标准体系指南》

16.《国家电子政务XML数据安全指南》

17.《电子政务业务流程设计方法通用指南》

18.《国家电子政务XML业务表示规范》

19.《GB8567—88计算机软件产品开发文件编制指南》

20.《GB8566—88计算机软件开发规范》

21.《GB/T12504—90计算机软件质量保证计划规范》

22.《GB/T12505—90计算机软件配置管理计划规范》

23.《GB9385—88计算机软件需求说明编制指南》

24.《GB9386—88计算机软件测试文件编制指南》

25.《GB/T11457—1995软件工程术语》

26.《GB/T8566—2007信息技术软件生存周期过程》

27.《GB/T16680—1996软件文档管理指南》

28.《互联网信息服务管理办法》中华人民共和国国务院令（第

292号）

29.《互联网电子公告服务管理规定》中华人民共和国信息产业

部第三号令

30.《计算机信息网络国际联网安全保护管理办法》

31.《中华人民共和国计算机信息系统安全保护条例》

32.《IS013335信息技术安全管理指南》

33.《计算机信息系统安全等级保护管理要求》

34.《计算机信息系统安全等级保护网络技术要求》

35.《计算机信息系统安全等级保护数据库管理系统技术要求》

36.《计算机信息系统安全等级保护操作系统技术要求》

37.《计算机信息系统安全等级保护通用技术要求》

38.《计算机信息系统安全保护等级划分准则》（GB17859）

2.2.遵循的原则

2.2.1.创新性原则

1.系统严格遵循国际标准、国家标准和国内行业的规范要求；

2.符合行业的发展趋势，并确保采用当前成熟的产品技术；

3.系统采用最先进的技术，确保今后相当长的时间内技术上不会

落伍；

2.2.2.开放性原则

必须采用开放式标准设计•，确保可与其他厂家标准的产品有效互

通，保证其他系统的无缝接入。满足今后的发展，留有充分的扩充余

地；

2.2.3.可靠性原则

1.确保系统具有高度的安全性，不易感染软件病毒；

2.对工作环境要求较低，环境适应能力要强；

3.系统需要满足7义24小时无人职守方式稳定的工作；

2.2.4.安全性原则

1.系统必须保证与病人有关的信息私密性和安全性；

2.平台系统建设一方面要保障网络安全，另一方面要保障信息安

全，最后是保障系统可靠运行。网络安全首先要考虑技术层面的安全

性，同时考虑管理层面的安全性；信息安全主要是数据安全，保证数

据的原始性和完整性，包括数据不被非法修改和访问，数据的全面完

整，数据的访问和修改可追踪等等；同时，要制定并不断完善信息系

统应急预案和数据备份策略；可靠性是指平台系统应具备在硬件或网

络故障时的运行和修复能力，同时系统在设计时必须考虑大规模并发、

不断扩展条件下的运行可靠性；

2.2.5.统一规划、标准先行

统一标准是医疗信息化建设的基础工作，也是进行医疗信息交换

与共享的基本前提。在信息化建设中，必须强调“统一规划、统一标

准、统一建设、统一管理”原则，信息化主管部门要加强指导和组织

协调，规范各应用系统的基本功能、业务流程、数据模型和数据编码、

接口规范等信息标准。

2.2.6.系统标准化原则

1.数据标准化不仅是国家、卫生行业信息化的基本要求，也是保

证系统的开放性的基础。系统设计需全面支持国家、卫生部行业标准；

2.系统功能全部采用B/S架构，WEB浏览为核心的技术路线；

3.最大限度地应用医院现有的信息体系资源，尽可能少的更换医

院目前设备；

4.在卫生应用标准领域，通过使用国家标准、国际标准、地方标

准统一字典数据，以保证数据的可重复利用;

2.2.7.可扩展性原则

平台系统必须能够满足医院的业务需要，同时还需满足业务需求

的变化，预留足够灵活的数据和功能接口，便于今后扩展；

可扩展性包括；

1.数据中心和数据平台的系统可扩展性；

2.数据存储和计算能力的可扩展性；

3.网络支持能力的可扩展性；

2.2.8,易管理和易操作性

平台系统支持全面、完善、便捷、统一的系统管理和应急处理预

案，保证一旦发生问题能在最短的时间内处理解决。而且，系统应具

有良好的用户操作界面。集成完备的运行监视系统、良好的管理界面

工具或控制台，易于管理人员对其进行管理和维护，系统参数的维护

与管理通过操作界面实现。

3.项目建设目标

专项数据智慧管理及上报平台的建设目标是建设一个自动化程

度高，能够及时、完整、准确地完成数据对接，对数据治理全生命周

期可监控、可溯源、可管理的上报数据中心；基于上报数据中心，将

多种上报方式（前置机、http接口、web-service接口）组件化，实

现上报专题的自由组装；同时通过数据管理上报的全流程闭环管理,

提高数据管理上报的效能与医院精细化管理水平，在保障规范上报、

主动管理与反推源头质量提升的同时、实现数据的无缝对接、无感上

报、有异可察、有源可溯，有道可控，逐步打造一套支持全场景、多

模态的专项数据智慧管理及上报平台，为多院区数据整合上报奠定基

础。

项目目标明细如下：

1）保障专项数据智慧管理及上报平台信息获取的便捷性、完整性

通过对数据获取的尽可能自动化，降低人工录入和审核工作量，

提高整个平台的数据获取效率，同时.，对数据采集过程进行监控，避

免数据漏抽、重复抽、错抽等操作；

2）保障专项数据智慧管理及上报平台信息的准确性，提高数据质

量

对整个平台的数据进行统一资产管理，对数据质量进行统一治理,

当出现数据错误时能够进行及时提醒，并通过数据质量报告展示整个

平台的数据质量管控效果；

3）保障专项数据智慧管理及上报平台信息的可控性，出现问题能

快速追根溯源

对整个平台的数据进行全生命周期管理，当出现问题时\能够快

速追根溯源，使管理人员可及时采取相关措施；

4）实现数据上报的灵活可配置

专项数据智慧管理及上报平台既可满足目前医院常见的数据上

报场景需求，如HQMS上报、公立医院绩效考核数据上报、重点单病

种数据上报等，也能够针对医院未来的数据上报场景通过灵活的可配

置方式，快速实现新上报场景；

5）实现上报专项的全流程闭环管理

对专项数据智慧管理及上报平台上具体的各项上报场景，实现全

流程管理闭环，即可自动配置规则自动生成上报数据，对待上报的数

据进行自检，只有通过自检的数据即可完成一键上报，否则将重新进

行调整直至通过审核方可。并对已上报数据进行归档、查询和统计分

析；

6）实现对所有数据改进过程留痕

支持对所有数据修正与补录过程都能进行留痕，方便对数据操作

进行追溯，当出现问题时，能够快速进行定位。

7）实现对无法直接获取的数据进行快速填报

对于无法直接通过自动获取的数据，平台支持人工填报的方式对

平台的缺失数据予以补充，同时，平台提供自动提醒、默认数据预定

等多项操作，辅助和提醒工作人员及时对数据进行补录；

8）实现通过集成平台门户单点登录本平台

本平台将与医院的集成平台进行对接，使得工作人员通过统一的

认证系统即可享用本平台上的各项应用服务。

4.项目功能需求

为达到较好的建设效果，采购人信息数据中心针对以上目标逐项

明确了需求细则，梳理了本项目的功能需求，如下：

序项目目对应项目功能需求与需求细则数

号标量

1保障专功能需求：对需要上报的信息的源数据尽可能自

项数据动获取，提高采集效率；1

智慧管需求细则：

理及上1.多种接口采集方式：系统应支持多种接口采集

报平台方式，包括通过http、web-service接口进行数

信息获据采集，并可对接口的参数进行设置；

取的便2.源数据库结构获取：通过可视化方式，在数据

捷性、采集前，应能够自动获取源数据库的模式、表、

完整性视图、字段信息；

3.源表数据质量分析：系统应能够快速计算抽取

的源表字段备注信息的填充率；

4.源表数据预览：一旦采集开始，工作人员可通

过界面直接对源表数据进行预览；

5.采集作业配置：系统应支持操作人员直接通过

界面设置采集作业的各项参数，如采集方式、增

量条件、采集时间、采集范围等；

6.表字典管理：对采集获取的表字段进行字典维

护，且当源表结构出现变动时，系统支持人工处

理和自动处理两种方式。

2保障专功能需求：对获取的源数据进行治理，保障平台

项数据信息的准确性和高质量；1

智慧管需求细则：

理及上L数据资产目录管理：系统应支持管理员对整个

报平台平台的数据资产目录进行维护；

信息的2.数据集结构定义：系统应支持管理员对整个平

准确台的表的标准结构进行定义；

性，提3.数据字典管理：系统应支持从数据治理脚本中

高数据自动生成数据集的结构；

质量4.数据治理脚本编写及即时查看：系统应支持可

视化方式，方便技术人员直接在页面上编写数据

治理脚本，在脚本编写完毕即可进行运行，查看

脚本运行的效果；

5.数据关系解析：系统应能自动展示平台上衍生

数据和报表的来源，图形化展示各表之间的血缘

关系，；

6.数据采集的准确性保障：平台需有机制确保采

集的数据与原始表中的一致；已采集数据若在原

始系统中发生变化，上报平台需及时监测到并更

新平台对应数据；

7.增量数据采集的完整性与时效性保障：数据源

产生新数据时，平台应在24小时内完整、准确

采集增量数据（T+1时效性）；

8.采集数据的复用：平台需确保采集后的数据可

供多个数据上报任务使用，无需从原始库多次采

集相同数据。

9.数据质量规则配置：平台应包含常见的数据质

量管理规则，如非空、常量、范围等，且支持工

作人员直接在系统中进行自定义设置质量规则

及规则权重；

10.数据质量报告：根据平台上数据的实际表现

对数据质量进行总结分析，生成详细的数据质量

报告，并可根据配置规则触发预警。

3保障专功能需求：

项数据对整个平台上的数据实现数据的全生命周期管1

智慧管理，当出现问题时，能够快速追根溯源，使管理

理及上人员可及时采取相关措施。

报平台需求细则：

信息的1.作业调度配置：系统应支持管理员通过可视化

可控页面编排作业的执行逻辑，先后顺序，一旦配置

性，出成功，系统将自动根据设置执行作业；

现问题2.作业监控：支持对作业明细日志进行实时查询

能快速与下载，且能够对运行中的工作流进度进行实时

追根溯查看；

源3.作业执行记录：通过关键指标，展示整个平台

作业执行的情况；

4.作业执行统计：系统对整个平台上执行的工作

流进行统计分析，并以图表方式予以展示。

4实现数功能需求：上报数据和上报专项的审核流程，以

据上报及上报数据的生成和输出方式都需可配置；1

的灵活需求细则：

可配置1.可配置全局审核流程，当开启上报数据审核流

程时，可配置数据审核员。上报数据自检报告生

成后，自动下发审核任务，通过站内信/短信通

知对应的人员对本次上报的数据进行审核，修

正、补录，完成上述工作后，对最终数据进行复

检，复检通过则进入下一流程（审批或上报）。

2.对上报专项，可配置该专项所有上报组件的全

局审批流程，当开启审批流程时，可对审批流程

进行配置。当数据审核流程结束后，自动下发审

批任务，通过站内信/短信的方式通知对应人员

对本次上报的数据进行审批，审批通过后，自动

进行数据上报。

3.系统可根据数据上报指标的计算规则及涉及

的数据元，利用数据库字段名、字段描述等信息

自动从多个数据库中检索出计算上报指标所需

的数据元；若一个数据元同时在多个库中被检索

到，应形成列表供用户选择用于计算；各数据元

列表应包含该项数据元的全部来源数据库及对

应字段的信息。用户完成选择后，系统可自动使

用选中的数据元计算上报指标，得出多个上报指

标的值供用户对比、选择。上报指标值列表应包

含计算该指标所用数据元的来源数据库；

4.各上报专项可配置上报数据的获取规则，根据

规则自动获取本次上报数据；

5.用户可在现有数据的基础上自由配置生成任

意衍生变量作为新上报项，院内任意现有上报项

及数据元均可作为用于生成衍生变量的数据元；

衍生方式支持任意常见的运算（包含加减乘除、

求余、逻辑运算与或非、字符串拼接等）及这些

运算的组合；生成衍生变量所用数据元及新配置

上报项可为任意数据类型（包含整型、浮点数、

字符串、布尔类型、日期/时间等）；

6.对于用户自主配置生成的新上报项（衍生变

量），系统需同样支持数据治理、补录、自检质

控、查询、统计等全部相关功能，用户能够配置

新上报项的自检质控规则；

7.当前7种上报专项（HQMS上报、流感/发热门

诊数据上报、抗肿瘤药物检测上报、三级公立医

院绩效考核上报、国家儿童肿瘤数据上报、医疗

数据质量抽样检查上报、委属（管）医院信息服

务与监管系统数据上报），涉及到的上报方式有

http协议的restful接口，web-service接口，

生成csv文件输出到前置机指定目录，需根据各

专项的上报方式配置输出规则。

5实现上功能需求：各上报专项需体现管理闭环

报专项需求细则：1

的全流1.系统根据配置规则自动生成上报数据。

程闭环2.系统自动根据自检规则对本次上报数据进行

管理自检，自检不通过的数据项，从当前上报组件对

应的结果集，找到数据治理平台中对应的DM表，

根据字段血缘关系，从DM表-->DW表一>ODS表，

逐层校验反推，判断出原因，由信息部门协调，

各系统厂商配合改造，纠正，提升医院数据质量；

自检通过则进入下一流程。

3.若专项配置时开启审核流程，则将审核任务推

送到指定的审核员，审核员根据自检报告对数据

进行审核，审核过程发生修正、补录的，完成后

可对数据再次进行自检，自检通过且审核通过

后，则进入下一流程；若专项配置时未开启审核

流程，则直接进入上报环节。

4.若自检或审批通过，则触发上报动作，根据配

置的输出方式进行数据上报。

5.对上报结果进行归档处理，并以报表的方式对

上报结果进行统计分析。

6.系统对历次上报的数据进行归档，通过批次号

（每次上报唯一）进行该次上报数据的查询。

7.在上报专项首页中，可查看本专项当前上报任

务状态、流程节点，以及数据概况，可从首页快

速进入到审核、自检、审批的页面，进行具体管

理流程环节的操作。

6提高数功能需求：能够动态生成填报页面，且对数据进

据填报行实时自检及定期自检。支持用户对自检规则进1

的智能行自行配置，规则的配置可在多种数据元的基础

性上配置完成

需求细则：

1.自动生成各类数据上报、补录页面；

2.基于生成的上报页面，系统将自动填充平台数

据中心已有的对应数据，提高数据的填报速度；

3基.于设置的数据自检规则进行自检；

4.数据的自检规则支持在多个数据元的基础上

建立、配置，允许用户在医院任意上报项及数据

元中自行选择数据元配置自检规则；跨数据元的

自检规则支持在常见运算的基础上配置（包括使

用各选中数据元进行加减乘除、求余、逻辑运算

与或非、字符串拼接等运算后的结果对目标数据

元的有效性进行检测、对目标数据元和其它数据

元进行上述运算等常见运算后的值进行范围检

测等）。

7实现对功能需求：所有数据修正与补录过程有留痕，方1

所有数便追溯

据改进需求细则：

过程留1.对工作人员每次修改、补录的操作留痕，生成

痕修正/补录日志；

2.支持对平台上所有修改、补录操作生成明细日

志，可查看每条记录历史修订版本的明细数据

项；

3.支持通过自检报告中显示的数据质量问题快

速定位、检索数据质量不过关的数据，快速进行

修正；

8实现对功能需求：无法直接获取的数据，需要提供人工

无法直填报功能，由指定人员将数据录入系统。1

接获取需求细则：

的数据1.对于无法直接通过业务系统进行抽取的指标，

快速填如三级公立医院绩效考核上报的部分指标，项目

报采用人工录入方式保证数据的完整性，由指标库

中设定的提供科室进行数据录入。

2.平台需先维护好需手工填报的指标库。

3.添加指标填报的任务下发配置，包含填报时间

频率、填报的指标项、填报的科室人员，该任务

以站内信的方式，通知相关人员进行数据填报。

4.提供科室可根据预先设定的出数频率及补录

方式，填入全院或考核科室的指标数据。保障了

数据录入的统一性和规范性，一定程度上也保证

了数据的安全。

9系统基功能需求：系统需提供相关基础信息管理功能,

础信息如：菜单、科室、用户、权限等。

管理需求细则：

系统的正常运行，依赖于基础数据的维护。系统

的持续运行会促使基础数据的完善。根据本项目

系统功能设计，将系统管理功能划分为以下方

面：

1.提供菜单管理功能，用户可以通过系统菜单向

系统发送指令，指示系统完成相应业务逻辑操

作。

2.提供科室管理功能，将院内科室机构信息单独

维护，而员工基本信息需要同步医院业务系统数

据。

3.提供用户管理功能，管理系统的登录账号，包

括账号的基本信息、所属权限组、是否正常状态、

对应的报表用户等。

4.提供权限组管理功能，用户的权限由权限组决

定，不同的权限组可以对不同的系统菜单进行访

问，用户、权限组、和菜单资源的多种组合，组

成用户对系统的不同访问权限。

10实现通功能需求：系统需提供集成平台单点登录功能。

过集成需求细则：专项数据智慧管理及上报平台需接入1

平台门医院集成平台的统一登录认证系统，通过集成平

户单点台门户进行单点登录。

登录本

平台

5.技术指标要求

5.1.总体技术要求

5.1.1,整体设计要求

1.整个系统自动化程度高，能够及时、完整、准确地完成数据对

接，当对接的业务系统或集成平台中的源表出现变动时，系统能够自

动识别和进行自动调整，保障平台的继续运行，并根据上报要求一键

式数据上报；

2.整个系统覆盖的上报范围广，能够满足医院常见的数据上报需

求，且支持接口、前置机、手工等各类方式的数据上报；

3.整个系统灵活度高，支持将多种上报方式组件化，可自由组装

上报专题，提高数据的利用率;

4.整个系统对数据实行全流程闭环管理，从数据抽取、清洗、转

换、分析、展示的整个环节中，每个关键节点提供可视化监控功能;

5.整个系统保持高数据质量，提供数据治理治理功能，除对常见

的数据错误，如缺失值、常值错误外，应支持自定义配置数据治理规

则，加强数据治理效果；

6.整个系统能够对数据管理进行可视化操作，包括数据的开发、

数据集标准定义、字段映射、值域转换、数据血缘管理等，方便管理

员对整个平台内的数据进行管控。

5.1.2,架构设计要求

整个项目的技术架构应具备可扩展性，在系统投入运行后，可按

照实施效果，集成和去除组件服务，即可达到扩展平台的存储空间、

扩展处理数据的吞吐量、增加功能模块的目的。

整个架构应能承载PB级数据处理，实现大容量、高通量、可扩

展、易维护的大数据系统，支撑对海量医疗数据的快速分析以及增量

数据的及时分析。

利用数据中台在数据底层完成数据的抽取、清洗、治理等各项操

作，使得医院能够一统各项上报数据，提高数据上报效率，不影响业

务系统的运行，且能够有利于数据的重复利用。

5.1.3.数据标准规范

本项目的所有数据上报数据，均应遵循国家、省市等颁发的各项

对应的上报数据标准，制订数据标准规范，建立统一的疾病诊断编码、

手术编码、临床医学术语、信息数据接口和传输协议等相关数据标准,

为保障上报数据的规范性，提高上报质量等奠定基础。

5.1.4.接口要求

要求创建标准数据接口，关联我院现有的业务系统，包括集成平

台、HIS、LIS、PACS、EMR等，从上述系统中读取上报相关的源数据，

统一存储至专项数据智慧管理及上报平台；

5.2.数据采集

1.支持对目前市面上各类数据库的数据源进行采集，包括Mysql、

PostgresqKOracle、Sqlserver>http、web-service接口等；

2.支持对数据源的创建，包括数据源类型、数据源名称、描述、

IP主机名、端口、用户名、数据库等；

3.支持对数据源进行统一展示与管理，包括新增、删除、修改的

设置等；

4.支持通过可视化界面方式设置工作流，通过拖拉的方式即可实

现从源数据中抽取，并进行清洗、转换等预处理后存储至分析库的整

个流程；

5.支持多种方式设计数据集成工作流的节点，包括离线同步、工

作表更新、Shell>存储过程、sql、http等；

6.支持工作流设置完毕后，对其进行保存和格式化，即可对其进

行进一步的处理，包括运行、编辑、下线等；

7.支持管理人员对已设置的工作流进行定时设置，包括起止时间、

定时、作业失败后的策略、通知策略等；

8.支持管理人员对容错条数的设置；

5.3.数据管理

1.支持对整个平台的信息进行总览，包括数据中心表ods、dw、

dm表数量、可查看各表每次作业写入的数据量、平均流量、读写失

败数量等统计信息；

2.支持管理人员能够对所有工作流进行总览，包括工作流的状态、

提交时间、开始时间、结束时间、运行时间等；

3.支持管理人员查看所有采集作业明细日志，当出现问题时能追

溯；

4.支持管理人员能够查看工作流执行的时间甘特图，便于优化编

排的作业执行逻辑，支持查看工作流中成功、失败的作业节点。

5.4.数据治理

1.支持对平台的数据字典进行统一管理，并实现源头字段与平台

字段之间的值域自动映射；

2.支持管理员直接在平台界面上进行数据处理脚本编写，实时查

看数据处理结果；

3.平台应能够自动解析平台数据表的血缘关系，辅助管理员对整

个平台上的数据关联进行了解；

4.系统后台应提供默认的常见数据质量规则，且支持管理员可视

化设置自定义规则。在规则设置成功后，平台应能够对不符合规则的

数据处理情况进行展示；

5.根据制订的数据质量校验规则，在每次抽取数据作业写入完成

后，系统将•自动进行数据质量验证，并生成数据质量报告;

5.5.平台数据监控

1.支持对整个数据处理过程形成的数据采集、治理、输出的链路,

进行总体、明细的日志监控。

2.当对接的业务系统或集成平台中的源表出现变动时一，系统能够

自动识别和进行自动调整，保障平台的继续运行

5.6.后台管理

1.提供认证中心服务，和院内集成平台认证中心对接，单点登录,

RBAC用户权限管理；

2.提供专项数据智慧管理及上报平台管理服务，包含上报专项、

组件、闭环管理服务；

3.提供上报组件执行器，对接不同上报方式，根据配置执行数据

上报。

6.系统安全要求

项目建设应满足《医院信息安全等级保护三级要求》。具体要求

如下：

1、账户安全管理要求

1.1面向互联网的应用，用户注册及登录均需要验证码。验证码

须在后端进行校验；

1.2系统支持用户凭验证码找回密码功能，验证码位数6位或以

上；

1.3强制用户首次登陆修改密码；

1.4输入密码时，默认在屏幕上不显示明文密码，可提供密码明

文显示按钮;

1.5首次输入密码可不用验证码，输入密码错误时强制弹出验证

码；

1.6通过手机短信接受验证码时，须要求事先校验手机号正确再

发送短信；

1.7限制单位时长内短信验证码发送次数，60秒1次，发送次数

在服务端校验；

1.8密码至少10位（含）以上，强制要求由数字、小写字母、

大写字母和特殊符号4类中至少3类组成，且支持使用键盘上的任意

特殊字符构成密码；

L9支持定期强制修改密码功能，定期改密的周期应可配置。（如:

可配置密码改密周期为一个月或一年不等），支持到期前一个星期提

醒用户更改密码的功能，并禁止使用原有密码；

1.10支持密码连续输错若干次将锁定账户的功能，次数可配置

（如：5次），设置定长时段后自动解锁账户（如10-30分钟）；

1.11账户密码必须以加密的形式存储或传输，采用md5+salt>

sha-256摘要算法，或国密算法，符合等保要求；

1.12密钥文件不得以明文方式存储在应用系统；

1.13禁止将密码（密钥）从服务器发往前端进行验证；

1.14应用系统中数据库配置文件中的连接字符串须加密（如实

例名、服务器IP、账户名、密码等）；

1.15支持会话空闲超时中断的功能，时长参数可配置（如，15

分钟);

1.16建议账户名由字母或字母加数字组合，建议6位以上。

1.17系统支持设置账户有效期，到期自动禁用。

1.18系统支持账户的停用、启用、注销功能，可限制用户对系

统的访问时段；

1.19系统支持账号名模糊匹配、创建时间、登录次数、账号状

态、末次登录时间、末次维护时间等条件查询功能，支持查询结果账

号列表批量停用功能，并预留解冻功能；

1.20可生成停用用户报表及系统用户权限明细表；

1.21系统用户支持双因子认证机制。

2、访问控制

2.1禁止产生越权访问漏洞；

2.2禁止产生未授权的访问漏洞；

2.3禁止产生目录遍历漏洞；

2.4传递参数的页面须使用身份鉴别的令牌机制，Token可以由

访问来源、访问对象、时间戳、有效期、随机数等信息组成；

2.5对于需要登录后才能访问的页面资源，系统应支持防重放攻

击，避免未授权的第三方伪造类似页面请求后成功获取页面资源；

2.6禁止注入漏洞，含SQL注入、LDAP注入、xpath注入等；

2.7开放接口安全

2.7.1接口以HTTP(S)方式开放；

2.7.2设计接口需要有身份认证，对来源授权，只允许授权的IP

访问;

2.8文件上传

2.8.1禁止存放上传文件的目录拥有执行的权限；

2.8.2上传文件类型限制，限制规则必须在服务器段校验，必须

使用白名单进行限制，禁止使用黑名单限制规则；

2.8.3存在图片上传时，对图片文件的文件头进行符合性校验；

2.8.4上传文件不可以存放在WEB服务器上，要存放到指定服务

器；

2.9组件的选择

2.9.1禁止使用有公开漏洞的中间件版本；

2.9.2数据库选择当前的主流版本，版本不能过低；

2.9.3禁止使用有公开漏洞的应用框架组件（如web报表、web

编辑器、办公组件、论坛、项目管理、日志等）；

3、数据安全

3.1需求敏感字段处理

3.1.1数据传输方式应满足数据敏感程度的要求，如传输敏感数

据，数据需加密或采用安全的传输协议与传输内容；敏感字段包括

a.真实姓名、b.身份证号、c.账户号、d.生日、e.手机号码、f.联系

电话、g.联系地址、h.单位名称、i.密码、j.银行账号、k.信用卡号

等；

3.1.2显示敏感字段时，应屏蔽部分字节。在服务端进行屏蔽。

身份证，银行帐号，信用卡号，密码不能明文在页面显示。

3.1.3对敏感字段的操作（新增、维护、删除）应有日志或报表

以供审核；

3.1.4一般用户的批量数据浏览界面可屏蔽敏感数据的部分字节;

3.1.5限制对敏感数据的复制功能。

3.2批量数据操作

3.2.1批量数据的导入应有校验；

3.2.2严格控制复制、下载、打印、浏览、导入/导出批量数据

的权限，对批量数据的任何操作都须产生报表或日志。

3.3数据保存

3.3.1应对批量导入的数据长度和数据大小进行校验，防止数据

长度过长或导入数据量过大等导致系统出现安全问题；

3.3.2系统自动备份数据，并能设置备份的周期。

3.4个人信息保护

3.4.1涉及个人信息采集和保存的系统，须对个人信息主体提供

个人信息的收集的授权同意功能；

3.4.2涉及个人信息采集和保存的系统,须对个人信息主体提供

个人信息的查询/更正/删除功能；

3.4.3涉及个人信息采集和保存的系统,须对个人信息主体提供

个人信息的撤回授权功能；

3.4.4如业务需要收集个人信息，系统需发布个人隐私政策。

3.5区分高、中、低等风险级别参数的数据类别，按照不同风险

等级设置不同操作界面，不同数据类别要可设置成不同的权限控制；

其中，用户密码表、个人信息表、权限配置表、系统操作日志属于高

安全级别数据。

4、故障预警要求

4.1提供系统故障、超过系统容量、数据出错合理性超出、操作

失误权限不匹配等的报警功能，以对话框或禁止下一步操作的方式报

警并记录在系统日志内。

5、日志和报表

5.1应开启网页访问日志与数据库访问日志；

5.2报表或日志文件不可修改或删除：存储在系统数据库的日志

表数据不可以被应用系统中的任何用户（管理员、审计员、操作员）

修改或删除；

5.3系统应提供单独的日志审核界面（权限）供审计人员使用；

须对任何日志文件进行保护；

5.4系统产生的所有日志应按增量规则生成到服务器指定目录生

成日志文件，或存储在系统数据库的日志表中。若使用数据库日志表

的存储模式，系统应支持syslog协议，本地存储同时外发给存储到

第三方日志服务器；

5.5系统运行日志

5.5.1需要能记录操作者、操作对象、时间、IP、事件、操作结

果（成功、失败）以及原因（如考虑性能，此功能可作为开关，必要

时提供）;

5.5.2系统模块组件状态变化，错误或警报的记录。

5.6权限维护日志

5.6.1需记录维护员ID、维护日期、时间；

5.6.2权限的新增、删除或变更的记录。

5.7系统操作日志

5.7.1用户ID；日期、时间和关键事件的细节，如登录或退出、

增删改事件、点击访问数据；

5.7.2系统提供用户的登录时长查询功能；

5.7.3记录单位时长内用户密码连续输错，导致账户被锁定的行

为(对应要求1.10)；

5.7.4成功的和被拒绝的对系统尝试访问的记录；

5.7.5成功的和被拒绝的对敏感数据以及其他批量资源尝试访问

的记录；

5.7.6应对系统特殊权限，包括系统管理员、配置管理员、审计

管理员的系统启停、账号建立和删除、权限分配和修改、日志查看等

行为进行审计特权的使用。

5.7.7系统字典维护、表单维护等配置参数维护与变更应记录。

7.实施、培训、运行、售后及验收要求

7.1.系统实施要求

(1)实施厂家需提供项目详尽的实施方案和进度表，并自项目

启动之日起9个月内完成本合同项内服务以及系统的开发、安装、调

试，并保证正常运行。

(2)实施厂家应在系统实施方案中描述具体的实施团队的组成、

工作的内容、投入人员、项目进程表及采购人的配合等内容。在所有

工作开展之前，实施人员应制定一套完整科学可行的实施方案，作为

工程实施的总体计划和步骤。实施方案内容包含但不限于：组织保障

安排：成立领导小组，领导小组中的责任分工等。

（3）制定具体的实施流程、实施内容。

（4）实施期间，至少派遣4名专业工程师驻扎医院内进行软件

开发、实施服务等工作。项目团队的人员组成结构需为具有信息系统

项目管理师或系统集成项目管理工程师或高级系统架构设计师或软

件设计师或项目管理专业人员资格认证PMP人员。

（5）系统运行前完成医院基础数据的收集整理、校对录