序号

功能名称

技术和性能参数需求

1

大数据存储与计算平台

1-1

首页概览

支持概括大数据存储与计算平台的组成结构与作用说明。

1-2

实时概况

支持以图表的方式可视化展示集群状态总览信息，展示内容包括集群主机、仪表盘、配置记录、重点关注服务和告警记录。

1、集群管理

系统支持多集群管理，通过切换集群可和管理不同集群环境中主机、仪表盘、配置记录、重点关注服务和告警记录等信息。提升用户基础环境运维效率

2、集群主机

集群主机包括主机信息、监控项数量、服务数量、告警数量和主机数量等，操作更多按钮，链接至集群主机管理界面，对集群主机进行管理操作。

3、仪表盘

仪表盘包括内存使用情况、集群负载情况、CPU使用情况、网络使用情况等信息，可通过时间选择指定时间范围内指标数据。点击各个图表可放到图表信息并支持保存为图片。

4、配置记录

支持以时间轴形式展示集群配置记录，支持全部折叠和全部展开，点击更多弹出各个组件配置信息列表。

5、重点关注服务

展示集群下组件的运行状态、告警数量等信息，组件包括FLINK、FLUME、HBASE、ELASTICSEARCH、HIVE、KAFKA、OOZIE、SQOOP、ZOOKEEPER等。点击更多，链接至服务组件界面。

6、告警记录

以时间轴形式展示集群告警记录，通过更多按钮链接至告警管理界面。

1-3

服务管理

可集群下已安装服务的运行指标，服务承载的主机。展示组件的主从服务状态和配置信息，并提供集群级服务参数统一修改和服务的启动、停止和重启操作。能适配低分辨率。

1、 HDFSHDFS是Hadoop的分布式文件系统，实现大规模数据可靠的分布式读写。HDFS针对的使用场景是数据读写具有“一次写，多次读”的特征，而数据“写”操作是顺序写，也就是在文件创建时的写入或者在现有文件之后的添加操作。HDFS保证一个文件在一个时刻只被一个调用者执行写操作，而可以被多个调用者执行读操作。

提供运行HDFS概览、热力图、配置能力，可对组件进行开始、停止、重启全部、重启DataNodes、重启JournalNodes、重启ZKFailoverControllers、移动NameNode、服务检查、开启维护模式、平衡HDFS、下载客户端配置、删除服务等操作。

2、 YARN

支持YARN运行概览、热力图、组件配置能力，可对组件进行开始、停止、刷新YARN、重启全部、重启NodeManagers、移动App Timeline Server、移动ResourceManager、激活ResourceManager HA、服务检查、开启维护模式、下载客户端配置、删除服务等操作。

3、 MapReduce2

MapReduce2是Hadoop的核心组件之一，可以通过MapReduce快速实现在Hadoop平台上进行分布式的计算编程。它主要用于大规模数据集（大于1TB）的并行计算。概念“Map”和“Reduce”，及他们的主要思想，都是从函数式编程语言借来的，还有从矢量编程语言借来的特性。

4、 Hive

Hive是基于Hadoop构建的一套数据仓库分析系统，它提供了丰富的SQL查询方式来分析存储在Hadoop分布式文件系统中的数据，可以将结构化的数据文件映射为一张数据库表，并提供完整的SQL查询功能，可以将SQL语句转换为MapReduce任务进行运行，通过自己的SQL去查询分析需要的内容，这套SQL简称Hive SQL。

5、HBase

分布式数据库HBase是一个面向列（Column-Oriented）、适合存储海量非结构化数据或半结构化数据的、具备高可靠性、高性能、可灵活扩展伸缩的、支持实时数据读写的分布式存储系统。

HBase的特点：

容量大：HBase单表可以达到百亿行、百万列，数据矩阵横向和纵向量级维度所支持的数据量级都非常具有弹性。

面向列：HBase是面向列的存储和权限控制，并支持独立检索。列式存储，其数据在表中是按照某列存储的，这样在查询只需要少数几个字段的时候，能大大减少读取的数据量。

多版本：HBase每列的数据存储有多个版本Version。

稀疏性：值为空的列并不占用存储空间，表可以设计的非常稀疏。

扩展性：底层依赖于HDFS，增加节点。

高可靠性：WAL机制保证了数据写入时不会因集群异常而导致写入数据丢失：Replication机制保证了在集群出现严重的问题时，数据不会发生丢失或损坏。

高性能：底层LSM数据结构和Rowkey有序排列等架构上的独特设计，使得HBase具有非常高的写入性能。Region切分、主键索引和缓存机制使得HBase在海量数据下具备一定的随机读取性能，该性能针对Rowkey的查询能达到毫秒级别。

6、Oozie

Oozie是一个基于工作流引擎的框架，它能够提供对Hadoop MapReduce和Pig Jobs的任务调度与协调。Oozie需要部署到Java Servlet容器中运行。

所谓工作流，即是指数据Import进HDFS，然后用Hive分析，然后将分析结果集Export，把不同的结果集合并成最终结果，将不同的业务进行编排。Oozie的工作流任务是DAG（有向无环图）。

所谓调度，即是指对作业或任务的定时执行，或者是事件的触发执行。触发执行的时机：在指定时间触发执行，或者当某目录下有数据集时触发执行。

Oozie集成了Hadoop的很多框架，如Java MapReduce、Streaming MapReduce、Pig、Hive、Sqoop、Distcp。一个Oozie Job也是一个MapReduce程序，仅仅只有Map任务的程序，是分布式可扩展的。针对不同类型的任务编写的Workflow，可以写成模板来直接套用。

7、Zookeeper

提供Zookeeper运行概览和组件配置功能，可对组件进行开始、停止、重启全部、服务检查、开启维护模式、添加Zookeeper Server、下载客户端配置、删除服务等操作。

8、Storm

Storm是分布式实时大数据处理框架。随着越来越多的场景对Hadoop的MapReduce高延迟无法容忍，比如网站统计、推荐系统、预警系统、金融系统(高频交易、股票)等等，大数据实时处理解决方案（流计算）的应用日趋广泛，目前已是分布式技术领域最新爆发点，而Storm更是流计算技术中的佼佼者和主流。

9、Flume

Flume是一个分布式，可靠且可用的系统，用于有效地从许多不同的源收集、聚合和移动大量日志数据到一个集中式的数据存储区。

Flume支持在日志系统中定制各类数据发送方，用于收集数据；同时，Flume提供对数据进行简单处理，并写到各种数据接受方（可定制）的能力。

Agent由Source、Channel、Sink三个模块组成，其中Source负责接收数据，Channel负责数据的传输，Sink则负责数据向下一端的发送。

（1）Source，消费由外部源（如Web服务器）传递给它的事件。外部源以一定的格式发送数据给 Flume，这个格式的定义由目标Flume Source 来确定。例如，一个 Avro Flume source 可以从 Avro（Avro是一个基于二进制数据传输的高性能中间件，是 hadoop 的一个子项目） 客户端接收 Avro 事件，也可以从其他 Flume agents（该Flume agents 有 Avro sink）接收 Avro 事件。 同样，我们可以定义一个 Thrift Flume Source 接收来自 Thrift Sink、Flume Thrift RPC 客户端或者其他任意客户端（该客户端可以使用任何语言编写，只要满足 Flume thrift 协议）的事件。

（2）Channel，可以理解为缓存区，用来保存从Source那拿到的数据，直到 Flume slink 将数据消费。file chanel 是一个例子，它将数据保存在文件系统中（当然你可以将数据放在内存中）。

（3）Sink，从channel消费完数据就会将数据从channel中清除，随后将数据放到外部存储系统例如 HDFS（使用 Flume HDFS sink）或发送到其他Flume agent的source中。不管是Source还是Sink 都是异步发送和消费数据。

10、Kafka

Kafka 是一个消息系统。现在它已被多家公司作为多种类型的数据管道和消息系统使用。活动流数据是几乎所有站点在对其网站使用情况做报表时都要用到的数据中最常规的部分。活动数据包括页面访问量（Page View）、被内容方面的信息以及搜索情况等内容。这种数据通常的处理方式是先把各种活动以日志的形式写入某种文件，然后周期性地对这些文件进行统计分析。运营数据指的是服务器的性能数据（CPU、IO 使用率、请求时间、服务日志等等数据)，总的来说，运营数据的统计方法种类繁多。

Kafka 是一个基于分布式的消息发布-订阅系统，它被设计成快速、可扩展的、持久的。与其他消息发布-订阅系统类似，Kafka 在主题当中保存消息的信息。生产者向主题写入数据，消费者从主题读取数据。由于 Kafka 的特性是支持分布式，同时也是基于分布式的，所以主题也是可以在多个节点上被分区和覆盖的。

消息是一个字节数组，程序员可以在这些字节数组中存储任何对象，支持的数据格式包括 String、JSON、Avro。Kafka 通过给每一个消息绑定一个键值的方式来保证生产者可以把所有的消息发送到指定位置。属于某一个消费者群组的消费者订阅了一个主题，通过该订阅消费者可以跨节点地接收所有与该主题相关的消息，每一个消息只会发送给群组中的一个消费者，所有拥有相同键值的消息都会被确保发给这一个消费者。

Kafka 设计中将每一个主题分区当作一个具有顺序排列的日志。同处于一个分区中的消息都被设置了一个唯一的偏移量。Kafka 只会保持跟踪未读消息，一旦消息被置为已读状态，Kafka 就不会再去管理它了。Kafka 的生产者负责在消息队列中对生产出来的消息保证一定时间的占有，消费者负责追踪每一个主题 (可以理解为一个日志通道) 的消息并及时获取它们。基于这样的设计，Kafka 可以在消息队列中保存大量的开销很小的数据，并且支持大量的消费者订阅。

11、Spark

Spark是专为大规模数据处理而设计的快速通用的计算引擎。Spark提供了一个快速的计算，写入，以及交互式查询的框架。相比于Hadoop，Spark拥有明显的性能优势。

Spark主要有以下3个特点:

（1）高级 API 剥离了对集群本身的关注，Spark 应用开发者可以专注于应用所要做的计算本身。

（2）Spark 速度很快，支持交互式计算和复杂算法。

（3）Spark 是一个通用引擎，可用它来完成各种各样的运算，包括 SQL 查询、文本处理、机器学习等，而在 Spark 出现之前，我们一般需要学习各种各样的引擎来分别处理这些需求。

Spark能够支持交互式的数据挖掘，由于Spark是基于内存的计算，很方便处理迭代计算，而数据挖掘的问题通常都是对同一份数据进行迭代计算。除此之外，Spark能够运行于安装Hadoop 2.0 Yarn的集群。之所以Spark能够在保留MapReduce容错性，数据本地化，可扩展性等特性的同时，能够保证性能的高效，并且避免繁忙的磁盘IO，主要原因是因为Spark创建了一种叫做RDD（Resilient Distributed Dataset）的内存抽象结构。

原有的分布式内存抽象，例如key-value store以及数据库，支持对于可变状态的细粒度更新，这一点要求集群需要对数据或者日志的更新进行备份来保障容错性。这样就会给数据密集型的工作流带来大量的IO开销。而对于RDD来说，它只有一套受限制的接口，仅仅支持粗粒度的更新，例如map，join等等。通过这种方式，Spark只需要简单的记录建立数据的转换操作的日志，而不是完整的数据集，就能够提供容错性。并且，Spark同时提供了操作允许用户显示的将数据转换过程持久化到硬盘。对于数据本地化，是通过允许用户能够基于每条记录的键值，控制数据分区实现的。（采用这种方式的一个明显好处是，能够保证两份需要进行关联的数据将会被同样的方式进行哈希）。如果内存的使用超过了物理限制，Spark将会把这些比较大的分区写入到硬盘，由此来保证可扩展性。

提供Spark运行概览和组件配置功能，可对组件进行开始、停止、重启全部、服务检查、开启维护模式、下载客户端配置、删除服务等操作。

12、Flink

Flink是一个批处理和流处理结合的统一计算框架，其核心是一个提供了数据分发以及并行化计算的流数据处理引擎。它的最大亮点是流处理，是业界最顶级的流处理引擎。

Flink最适合的应用场景是低时延的数据处理（Data Processing）场景：高并发pipeline处理数据，时延毫秒级，且兼具可靠性。提供Flink运行概览和组件配置功能，可对组件进行开始、停止、重启全部、开启维护模式、删除服务等操作。

13、ElasticSearch

ElasticSearch 是一个分布式、高扩展、高实时的搜索与数据分析引擎。它能很方便的使大量数据具有搜索、分析和探索的能力。充分利用ElasticSearch的水平伸缩性，能使数据在生产环境变得更有价值。添加ElasticSearch后，可以接入ElasticSearch集群开始使用ElasticSearch引擎，如定义索引数据、加载数据或搜索数据等。ElasticSearch集群可以包含多个索引(indices)（数据库），一个索引包含一个类型(types)（表），每一个类型包含多个文档(documents)（行），然后每个文档包含多个字段(Fields)（列）。

提供ElasticSearch运行概览和组件配置功能，可对组件进行开始、停止、重启全部、重启ElasticSearch Slave、服务检查、开启维护模式、删除服务等操作。

1-4

集群主机

集群主机可添加主机和删除主机。可主机指标CPU使用、内存使用、磁盘使用、网络使用、加载量和进程数。展示主机上的组件服务，并提供本机上组件服务的启动、停止和重启操作。

通过名称链接，可以主机已安装组件信息、主机运行指标、配置主机组件、告警信息和版本号。

1、概要-组件：提供已安装组件启停操作和可安装组件的向导式安装。

2、概要-主机指标：内存使用情况、Load、CPU使用情况、网络使用情况、进程等信息，可通过时间选择指定时间范围内指标数据。点击各个图表可放到图表信息并支持保存为图片。

3、 配置：可主机已安装组件的配置信息。

4、 告警：展示当前主机告警信息，内容同告警管理。

1-5

告警管理

告警管理模块用于展示集群下各个组件的告警信息，包括提示名称、状态、服务、上次状态改变、阶段，用于跟踪集群组件运行状态、管理报警组、管理通知、激活集群组件的告警项。通过提示名称链接，可告警定义、检查间隔和告警级别阈值。

1-6

组件管理

组件管理模块用于展示大数据存储与计算平台组件库包含的组件以及组件版本、描述、状态等信息，并对可选择组件进行实例化。

选择状态为添加服务的组件，进入向导式安装界面，根据向导提示分配进行选择服务、分配主机、分配服务和客户端、定制服务、配置身份、检查、安装，启动和测试后完成组件安装。

满足信创要求：

基于统信操作系统UOS、ARM64架构安装部署：

1、Hadoop核心组件高可用部署支持满足信创要求。

2、Ambari-server高可用部署支持满足信创要求。

3、Ranger高可用部署支持满足信创要求。

4、集群容灾支持满足信创要求。

满足信创要求适配环境：

服务器/芯片支持类型：基于ARM64架构芯片，如：龙芯、飞腾

操作系统支持类型：国产操作系统，如：统信UOS-20

组件支持满足信创要求：Hadoop核心组件、Ambari-server、Ranger、集群容灾AZ。

1-7

集群容灾

1.集群容灾实现了单集群跨AZ高可用方案，将平台管理节点与数据节点部署在多个AZ中，即使某一AZ不可用，也不会影响整体集群功能，保障构建在大数据存储与计算平台管理的集群之上的客户业务系统的稳定运行，进而达到高可用的目的。

2.实现物理机架信息维护，将集群节点分配到具体机架中。用户可以开启AZ容灾，将物理机架分配到具体的AZ域中进行容灾配置

1-8

租户管理

1.多租户管理主要管理组件底层用户资源权限访问策略，实现平台底层各组件用户的统一管理、数据的有效隔离，保障数据使用安全。

2.当前版本实现：HDFS、Hive、HBase、ElasticSearch,Kafka六种数据组件的租户管理。

3.租户管理分为用户管理、权限管理、资源管理三个子模块。

4.用户管理包含 用户和用户组的管理，实现用户信息的添加删除，编辑等操作权限管理包含实现组件的权限配置

2

数据安全管理平台

2-1

应用管理

应用管理是各应用（系统）接入数据安全平台的入口，通过该功能对各应用（系统）进行注册。注册完成后，可已注册应用的详细信息，包括应用信息、授权码、主密钥信息、数据密钥信息、脱敏规则信息和数字水印信息。

2-2

安全能力管理

2-2-1

主密钥管理

密钥支持根据其不同用途分为数据加密密钥和主密钥两种类型，主密钥是密钥层次体系中的最高级密钥，用密钥加密密钥保护数据密钥的传输。目前主密钥长度支持512位（bit）、1024位（bit）、2048位（bit）、4096位（bit）等。

2-2-2

数据密钥

1.数据的加密和解密算法的操作通常都是在一组密钥的控制下进行的，分别称为加密密钥(Encryption Key) 和解密密钥(Decryption Key)。常见的加密算法包括对称加密算法和非对称加密算法。对于对称性加密算法，信息接收双方都需事先知道密钥和加解密算法且其密钥是相同的，之后便是对数据进行加解密了。非对称算法与之不同，发送双方A,B事先均生成一堆密钥，然后A将自己的公有密钥发送给B，B将自己的公有密钥发送给A，如果A要给B发送消息，则先需要用B的公有密钥进行消息加密，然后发送给B端，此时B端再用自己的私有密钥进行消息解密，B向A发送消息时为同样的道理。

2.目前支持的对称密钥算法为AES、SM4；非对称密钥算法为RSA、SM2。

对称加密算法的密钥管理是一个复杂的过程，密钥的管理直接决定着他的安全性，因此当数据量很小时，我们可以考虑采用非对称加密算法。

非对称加密是通过两个密钥（公钥-私钥）来实现对数据的加密和解密的。公钥用于加密，私钥用于解密。

3.平台内置了多种数据加密算法，应用可根据具体场景，选择相关算法。

2-2-3

数据脱敏

1.随着大数据时代的到来,数据中蕴藏的巨大商业价值被逐步挖掘出来,但是同时也带来了巨大的挑战,即敏感信息的保护。

2.数据脱敏(Data Masking),又称数据漂白、数据去隐私化或数据变形。百度百科对数据脱敏的定义为：指对某些敏感信息通过脱敏规则进行数据的变形，实现敏感隐私数据的可靠保护。这样，就可以在开发、测试和其它非生产环境以及外包环境中安全地使用脱敏后的真实数据集。

3.根据不同数据特征，平台需内置丰富高效的脱敏算法，可对常见数据如姓名、证件号、银行账户、金额、日期、电话号码等敏感数据进行脱敏，内置脱敏算法如下：

3.1替换：将数据替换成一个常量，对内部人员可以完全保持信息完整性。

3.2重排：按照一定的顺序进行打乱，很像“替换”， 可以在需要时方便还原信息。

3.3截断：舍弃必要信息来保证数据的模糊性，是比较常用的脱敏方法。

掩码：保留了部分信息，并且保证了信息的长度不变性，对信息持有者更易辨别。

3.4日期偏移取整：舍弃精度来保证原始数据的安全性，一般此种方法可以保护数据的时间分布密度。

3.5平台支持脱敏规则的管理功能，可将内置的各种脱敏规则，授权给各应用（系统），应用可根据具体场景，选择相关脱敏规则。脱敏方案确定后，可被重复利用与该场景下不同批次数据的脱敏需求。

2-2-4

数字水印

1.数字水印技术是将标识信息（即数字水印）直接嵌入数字载体（包括多媒体、文档、数据库等）中，但不影响使用价值。数字水印不限制正常的数据存取，而是保证隐藏的信息不引起攻击者的注意，从而减少被侵犯的可能性。在此基础上再结合数据加密，来增强隐藏信息的安全性和抗攻击性能力。

2.数字水印在使用过程主要涉及到两个过程：

2.1水印嵌入过程：

数据提供部门的数据共享给数据使用方，共享平台在数据中加入使用方

水印信息，其主要过程如下：水印提取过程，从泄漏数据中提取水印信息，达到确认泄露源的目的。

2.1.1平台支持的数字水印包括数据水印和可视化水印；其中数据水印包括数值型和签名型水印；可视化水印为文本（页面）水印。

2.1.2签名型水印：这是较为简易的一种水印方式，即在数据库中增加一个字段，在字段中对数据资源需求方进行标记，并通过加密算法生成的水印信息（可采用对称加密算法加密），数据泄露可溯源。

2.1.3数值型水印：利用一定失真范围内的数据变形来嵌入水印。通过在某些数值型属性值中引入少量误差，对其最低有效位（LSB算法）进行操作，实现水印信息的嵌入。该方法允许存在一定的数值误差。

文本水印：在页面浏览时，增加文本类型的水印信息。

平台提供数字水印的管理功能，可将内置的各种水印，授权给各应用（系统），应用可根据具体场景，选择相关水印。

2-2-5

数字签名

目前的数据加密、数字签名、消息摘要等技术都是以密码技术作为基础设计出来的。随着信息化的高速发展，密码学理论的研究和应用越来越受到重视。数字签名的设计思想等同于手写签名，即将签名者的身份与其签署的消息绑定，表示某人已对某消息进行了签字。任何的验证者均能验证消息确实为签名者所签署，而伪造一个合法用户的签名却是困难的。数字签名是实现数字通信中可认证性、完整性和不可否认性的重要密码技术，是应用最为广泛的公钥密码技术之一。

数字签名的应用范围相当广泛，而数字签名最重要的应用之一就是数字版权管理系统的应用。随着网络和数字技术的快速发展，以数字形式存在的产品在人们的日常工作、学习和生活中占据越来越重要的地位。如何通过技术手段来保护数字内容的版权己成为近年来工业界和学术界研究的热点问题。随着数字签名与普通签名有同等效力的法规出台，数字签名技术的研究与应用进入一个新的阶段。

数字签名技术是只有信息的发送者才能产生的别人无法伪造的一段数字串，这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明。一套数字签名通常定义两种互补的运算，一个用于签名，另一个用于验证。

数字签名的目的是保证信息传输的完整性、发送者的身份认证、防止交易中的抵赖发生。

数字签名原理

数字签名是加密的过程，数字签名验证是解密的过程。

将摘要信息用发送者的私钥加密，与原文一起传送给接收者。接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与解密的摘要信息对比。相同，则信息是完整的，在传输过程中没有被修改；不相同，则信息被修改过。

因此，数字签名能够验证信息的完整性。

数字签名特征

签名是不可伪造的：除了合法的签名者之外，任何其他人伪造其签名是困 难的。

签名是不可抵赖的：签名者事后不能否认自己的签名。

签名是可信的：任何人都可以验证签名的有效性。

签名是不可复制的：对一个消息的签名不能通过复制变为另一个消息的签名。如果对一个消息的签名是从别处复制得到的，则任何人都可以发现消息与签名之间的不一致性，从而可以拒绝签名的消息。

签名的消息是不可篡改的：经签名的消息不能被篡改。一旦签名的消息被篡改，则任何人都可以发现消息与签名之间的不一致性。

数字签名设计要求

签名必须依赖于被签名消息的比特模式 (签名与消息应该是一个不可分割的整体)；

签名必须使用某些对发送者是唯一的信息，以防止伪造和抵赖；

数字签名的产生、识别和验证应该相对容易；

伪造一个数字签名在计算上是不可行的；(无论是通过对已有的数字签名来构造新报文，还是对给定的报文伪造一个数字签名)

平台支持数字签名的新增、删除、启用、禁用、授权、编辑、详情等功能。数字签名算法类型包括RSA系列、DSA系列、ECDSA系列；

数字签名使用场景

假设现在有通信双方A和B，两者之间使用两套非对称加密机制；

那么，如果在发送过程中，有人修改了里面密文消息，B拿到的密文，解密之后得到明文，并非A所发送的，信息不正确。

要解决两个问题：1. A的身份认证 2. A发送的消息完整性 那么就要用到上面所讲的基础知识。

过程说明：

A：将明文进行摘要运算后得到摘要（消息完整性），再将摘要用A的私钥加密（身份认证），得到数字签名，将密文和数字签名一块发给B。

B：收到A的消息后，先将密文用自己的私钥解密，得到明文。将数字签名用A的公钥进行解密后，得到正确的摘要（解密成功说明A的身份被认证了）。

对明文进行摘要运算，得到实际收到的摘要，将两份摘要进行对比，如果一致，说明消息没有被篡改（消息完整性）。

2-2-6

SDK管理

1.各集成平台需要使用安全平台的能力，需要从平台下载SDK，然后以jar依赖的方式嵌入客户程序。这种方式特别适合大批量数据加密的场景，会更加快速高效。

2.平台支持密钥、脱敏和水印安全能力的SDK版本管理以及集中分发控制。各个能力独自构建独立的SDK包，从而方便进行精准的安全能力授权控制。

3.SDK安全能力提供几种在线和离线方式提供能力，适合各种实际的调用场景。其中在线模式适合紧耦合平台，通过在线方式集中管理密钥及授权，安全级别更高。同时，SDK也提供离线工作方式，适合客户程序不能和平台同网部署的场景。

2-3

安全监控

1.安全监控，是对平台的安全能力使用过程中产生的日志和数据进行记录的过程。包括安全洞察、安全处理数据量和日志详情。

2.安全洞察，主要展示安全监控指标、安全动态。

3.安全处理数据量是记录外部应用（系统）使用安全能力处理的数据量。

4.日志详情是记录外部应用（系统）使用安全能力产生的日志信息，包括基本信息和运行信息。基本信息主要是对象名称、对象类型、能力名称、能力类型、应用平台、用途等；运行信息主要是运行时间、运行时长、数据量、成功数据量、异常数据量等。

2-4

盲水印

盲水印（Blinding Watermark）是指人感知不到的水印，简单来说就是一个图片水印加密技术，就是将字符串转换成图片格式，再将这个图片形式的字符串隐藏在另一张图片中，从而达到隐藏信息的作用，最后也可用特定的程序将信息还原。虽然在普通人看来图片本身并没有任何变化，但是实际上图片已经拥有了自己的唯一标识。其主要应用于音像作品、数字图书等，目的是在不破坏原始作品的情况下，实现版权的防护与追踪。

平台支持盲水印的配置，以及水印检测与提取任务。盲水印配置，是对原始图片处理为水印图片，提供盲水印的新增、删除和预览等功能。水印检测与提取任务，是用于对已泄露的水印图片进行检测与提取，提供盲水印任务的新增和。

序号

功能名称

技术和性能参数需求

1

权限管理

用户登录用户名、密码需与HIS系统保持一致；

登录后需根据用户权限选择相对应的病区。

2

条码管理

需提供护士工牌的二维码管理功能，护士可自助打印用于扫描登录系统的二维码工牌。

3

病区患者管理

需病区患者列表；

需根据情况设置自己的关注患者，通过关注患者筛选患者列表；

需显示患者的姓名、性别、护理等级、患者状态、年龄、诊断、医保类型；

患者状态需包括：是否新患者、是否是危重患者、是否手术患者、是否过敏患者、是否正在输液、是否欠费；

需根据患者的基本信息筛选患者列表；

需通过扫描患者的腕带，快速选中目标患者。

4

医嘱执行

可执行的长期医嘱需包括输液医嘱、注射医嘱、口服药医嘱、雾化医嘱；

可执行的临时医嘱需包括输液医嘱、注射医嘱、口服药医嘱、雾化医嘱、检验医嘱；

需通过扫描患者腕带及医嘱执行单条码完成患者身份确认及医嘱执行工作；

需记录医嘱执行信息，信息包括：医嘱名称、医嘱状态、执行人、执行时间、执行单编号、执行类别。

医嘱的执行记录需支持选择是否同步到患者的护理记录中；

高危药品、特殊药品需支持在扫描执行时进行提醒。

5

皮试管理

需扫码执行患者的皮试医嘱；

需支持执行后设定皮试的结果时间；

需支持皮试到时PDA自动提醒；

需支持皮试结果双签确认，特殊情况下，复核确认支持由医生代签；

皮试结果需回写HIS系统。

6

体征信息录入

需支持在患者床边通过PDA录入患者体征数据，包括体温、呼吸、脉搏、血压等体征信息；

PDA录入的体征信息需实时同步到患者体温单中，并自动生成相应的体征曲线。

7

床旁入院

评估

需通过PDA完成患者入院首次护理评估，评估结果实时同步至患者入院首次护理评估记录单中。

8

病区配药

管理

需支持护士在病区治疗室配药操作的核对和记录；

需包含摆药、核对、配置的操作记录；

记录信息需包括药品信息、操作时间、操作人；

需通过报表查询药品配置全流程信息。

9

巡回管理

需支持记录常规护理巡回和输液巡回过程；

需支持记录输液药品的输液通畅情况、输液滴速及单位、输液剩余量信息、巡视时间、巡视人、巡视病区、巡视患者；

需提供巡回记录报表。

10

用血管理

需支持通过使用PDA扫描血袋条码记录血袋病区签收记录信息；

输血执行时，需通过核对（ABO血型核对、RH血型核对、有效时间核对等），保证输血过程的安全和可靠。

11

待办任务

管理

需支持显示护士关注的待办任务清单，包括：尚未确认结果的皮试、尚未完成的输血，手术流转中的患者；

需支持待办任务按照护士的关注患者进行推送；

需通过待办任务列表直达任务执行界面执行任务。

12

医嘱查询

需支持院期间全部医嘱的浏览和；

需按照医嘱类别过滤分类医嘱数据；

需按照条件过滤相关医嘱数据；

需支持醒目区别临时医嘱和长期医嘱；

医嘱状态需通过颜色区分。

13

患者信息

查询

需支持查询患者信息，包含姓名、性别、年龄、入院日期、过敏药物等信息；

需支持查询费用信息、及时对未付清费用，或超过警戒线患者费用进行警示。

14

检验结果查询

需支持查询患者最新及历史检验结果；

需支持按照时间段过滤患者所作的检验信息；

需支持显示患者各项检验的异常项目数量；

超出参考值范围项目需通过特殊标识列出。

15

关注患者设置

需支持护士自定义自己的关注患者名单；

需支持患者列表在关注患者与全科患者两种模式间切换。

序号

功能名称

技术和性能参数需求

1

护理人员档案管理

护理人员档案管理主要用于护理管理人员对全院护理人员、进修护士、实习护士的人事档案管理，需要包括人员基本档案、技术档案、科研论文情况、奖惩情况等信息。

1-1

护理人员档案管理

系统应支持对全院护理人员档案的精细化管理，管理内容应包括基本信息、人事信息、教育经历、职称、职务、执业资质、社会兼职、培训经历、学术研究、带教管理、专利情况、科研立项、获奖情况、奖惩记录等。系统应支持批量导入和导出人员档案信息，支持单人调动和批量调动功能，能够对人员档案信息进行编辑和审核，应对护理人员的新增和注销。

1-2

进修护士档案管理

系统应支持对全院进修护士档案的管理，管理内容应包括基本信息、联系方式、职称变动记录、教育经历、其他信息等。系统应批量导入和导出进修护士的档案信息，支持单人调动和批量调动功能，能够对进修护士档案信息进行编辑和审核，应对进修护士的新增和注销。

1-3

实习护士档案管理

系统应支持对全院实习护士档案的管理，管理内容应包括基本信息、联系方式、教育经历、其他信息等。系统应批量导入和导出实习护士的档案信息，支持单人调动和批量调动功能，能够对实习护士档案信息进行编辑和审核，应对实习护士的新增和注销。

1-4

人员调动管理

系统应支持对全院护理人员调动信息的管理，能够支持信息查询。

应支持对护理人员、进修人员、实习护士进行批量调动，支持调动信息的编辑和撤销，支持导出调动信息。

1-5

人员统计数据

系统应支持统计全部护理单元的护患比、床护比、离职率信息，并要求进行图表对比展示。应多维度的人员分布展示，包括层级、职称、学历、工作年限等。

1-6

个人档案

系统应支持个人档案的功能，支持对个人档案的修改和审核，应上传个人照片和护士执业证书照片功能。

2

护士长排班管理

护士长排班主要用于护士长对病区护士进行排班管理，护理部可通过系统各个病区排班情况，系统需帮助护士长快速排班，并自动统计排班数据，提高病区护士工作管理效率。

2-1

全院班次管理

系统应支持维护全院共享的班次，包括班次类别、班次归属、班次时长等信息，应班次信息的批量导入和导出功能，实现排班数据结构化存储。

2-2

病区班次管理

系统应支持维护各个病区个性化班次，包括班次类别、班次归属、班次时长等信息，应班次信息的批量导入和导出功能，能够设置病区排班的常用班次，帮助护士长快速排班。

2-3

节假日管理

系统应支持对法定节假日维护功能，支持快速生成双休日信息，并能够将节假日信息自动带入护士长排班功能中。

2-4

护理组管理

系统应支持对护理单元人员进行分组，如责任组、管理组、实习生组等，能够设置组长，应维护各组成员，能够调整人员和护理组顺序，帮助建立人员分组管理机制。

2-5

护士长排班

系统应支持护士长排班供。支持按照病区护士分组情况为护士进行排班，能够录入排班备注信息和病区排班备注信息。排班过程中能够护士的排班期望信息作为排班参考，应支持复制上周排班信息进行快速排班，支持设置加班、欠班情况。排班过程中需支持工时、夜时、存假、公休数据的实时统计功能，便于对护士上班时长进行调整。应支持批量复制粘贴，方便护士长快速完成排班工作。系统应支持护士长进行调班，能够记录和统计调班信息。应支持排班表的导出和打印。

2-6

护士排班期望

系统应支持护士录入个人排班期望，能够指定日期和期望班次，护士长在排班页面能够到护士的排班期望作为排班的参考。护士能够自己的排班期望满足情况。

2-7

病区休假管理

系统应支持对护士休假信息进行维护，并具备将休假信息自动带入护士长排班功能。应支持查询病区护士休假信息，支持休假信息的导出和打印。

2-8

排班查询统计

系统需提供排班相关数据的统计信息，包括人员班次统计、排班人员统计、班次类别时间统计、班次归类统计、护士期望统计等，按照多个维度进行排班的数据统计和查询，帮助管理者了解排班的全局信息。应支持调班数据的查询和导出。

3

护理质量检查管理

护理质量检查管理主要用于护理部、片区、护理单元三个层级的管理者对各个护理单元护理操作情况进行质量检查，根据统一的检查标准，能够对不符合标准的情况进行扣分，应进行质量检查结果进行统计和排名，应进行质控会议的记录，帮助提升护理质量。

3-1

质控权限管理

系统应支持维护各级质控人员权限，包括护理部质控人员、片区质控人员和各个护理单元质控人员，满足医院三级质量管理要求。

3-2

质控标准管理

系统应支持维护基础的护理质控指标评分标准，支持分类制定质控项目和扣分标准，支持设置项目分值，支持设定标准的及格线和目标合格率，帮助建立医院统一的质量检查约束规范。

3-3

质控计划管理

系统应支持维护各层级的质量检查计划，可以制定年计划、季度计划、月计划等，维护计划检查的具体标准内容，设定检查的护理单元以及评分对象，并能够自动分解为质控评分任务。

3-4

质控评分

系统应支持各层级质控人员按照计划对护理单元或者护士进行质量问题检查评分，检查科室质量达标情况，提出需要改进的项目。应对历史评分的和编辑。

3-5

质控评分结果

系统应支持质量评分扣分结果的汇总展示，支持按照护理单元和质控标准进行显示，显示内容包括扣分项、备注、考核得分、院平均分等，应支持将质控结果进行下发，通知各个护理单元进行问题的整改。

系统应支持自动生成追踪查检表，支持对质控问题的整改情况进行追踪查检。

3-6

质控追踪查检结果

系统应支持质控追踪查检结果的展示和查询功能，显示各个护理单元的缺陷问题追踪查检的整改率统计情况。

3-7

评分排名

系统应支持应按照不同标准组合全院各病区质量合格排名，支持按照质控标准，应图表对比展示。

3-8

质控会议

系统应支持质控会议记录，帮助管理者快速科学的分析质控问题。系统需支持自动提取质控会议所要讨论的质控问题，并汇总扣分和发生例次进行排序，帮助管理者选择主要问题。在原因分析过程中，系统应支持按照人、机、料、法、环五个方面分层分析问题产生的原因，并自动生成原因分析鱼骨图。应支持制定整改措施，帮助医院避免质控问题的再次发生。

4

护士长工作手册

护士长工作手册主要用于护理部安排科护士长和病区护士长填写相应的工作手册，并按时上报，科护士长和护理部需要对上报的工作手册进行审核，需超时未提交的工作手册，帮助进行护士长的工作管理。

4-1

工作手册制定

系统应支持护士长手册工作项目的维护，支持设定工作项目的填写角色、上报周期、预警时间、填报范围等，实现对护士长手册工作项目的灵活管理。

4-2

工作手册填报

系统应支持科护士长和病区护士长填报护士长手册，应按月所需填报的工作任务，支持按照结构化模板填报工作项目，能够审核状态和审核流程信息，系统对超时未填报的手册能够进行提醒，避免护士长工作任务的遗漏。

4-3

工作手册审核

系统应支持对护士长上报手册的审核，支持二级审核，能够按月上报的手册及审核状态，应手册详细内容，支持跟踪审核流程信息。

4-4

工作手册授权

系统应支持对超时的护士长手册进行统计管理，支持批量授权并指定新的预警时间，应对各个护士长手册填报超时情况进行数据统计。

序号

功能名称

技术和性能参数需求

1

护理计划知识库

护理计划知识库主要用于提供护理计划系统的数据支持，在制定护理计划过程中，通过知识库数据能够自动匹配适合的护理诊断和护理计划，护士可以通过知识库进行护理计划内容的学习。

1-1

护理诊断知识库

系统需提供护理诊断知识库以及护理诊断树形结构维护功能，支持护诊断术语维护，内容包括诊断定义、诊断描述、主要次要依据，支持护理诊断知识库维护，内容包括诊断与各相关术语的关联关系，应支持诊断的层级管理，可以根据实际需要进行护理诊断知识库的维护管理。

1-2

相关因素术语库

系统应支持相关因素术语库，同时也支持用户根据实际需要进行护理相关因素结构及相关术语的定义。

1-3

护理措施术语库

系统应支持护理措施术语库，同时也支持用户根据实际需要进行护理措施标准化结构及相关术语的定义。

1-4

预期目标术语管理

系统应支持预期目标术语库，同时也支持用户根据实际需要进行护理预期目标标准化结构及相关术语的定义。

1-5

护理评价管理

系统应支持标准化护理评价，同时也支持用户根据实际需要进行预期目标的完成情况及标准化定义的维护管理。

1-6

规则管理

系统应支持护理评估与诊断逻辑关系运算，包括常用的护理风险评估及其护理诊断，同时也支持护士根据实际需要进行修改和完善。系统应支持重复诊断的逻辑处理、相似诊断的互斥管理等逻辑规则，也可进行修改维护。系统应支持对诊断、相关因素、措施、评价等的运算规则管理。

2

患者护理诊断管理

患者护理诊断管理主要用于对患者制定护理诊断，支持根据患者的评估结果自动产生护理诊断推荐，也支持护士根据患者情况主动创建患者的护理诊断。

2-1

护理诊断优先级设置

系统应支持诊断优先级管理，能够为诊断设置默认优先级。

2-2

历史护理诊断管理

系统需显示患者在院期间所有的护理诊断历史信息，显示内容包括创建时间、提交时间、执行开始时间、操作人、操作时间，保证信息可追溯可管理。

2-3

患者护理诊断开立

系统应支持通过评估结果自动产生建议护理诊断，护士可以依据临床知识进行诊断确认，护士也可以根据需要手动添加系统中现有的护理诊断，确认后的护理诊断信息包括创建人、创建时间、诊断开始时间、结束时间、诊断状态。

3

患者护理计划管理

患者护理计划管理用于对患者制定护理计划，根据制定的护理诊断，系统需自动匹配所需要执行的护理措施计划以及对应的预期目标，护士可以根据患者实际情况进行调整，应支持对患者护理计划的和追踪。

3-1

护理计划创建

系统应支持依据诊断知识库的关联自动产生患者诊断的建议护理措施，护士可以依据临床经验和知识对措施进行增改，针对可选的措施可以进行删除操作，针对系统自动产生的诊断所属预期目标，护士可以进行维护。

3-2

护理计划管理追踪

系统应支持显示患者当前最新的护理计划信息，能够各护理诊断对应的执行措施项目，能够各护理诊断的最终预期目标。

4

患者护理措施管理

患者护理措施管理主要用于对患者制定的护理措施进行执行，支持护理措施的执行信息，支持批量执行护理措施。

4-1

护理措施浏览

系统应支持按照护理诊断当前患者所有需执行的护理措施，也可以通过措施一览表展现当前所有待执行的护理措施。

4-2

护理措施校验规则

系统应支持为护理措施制定规则校验，用于护理措施制定必选项目判断进行选择。

4-3

措施执行管理

系统应支持在PC进行执行措施的操作，系统能够记录措施执行时间和执行人信息，系统应支持对措施进行执行状态标记，显示措施执行时间、次数、执行人。系统应支持措施的批量执行操作。

5

护理目标评价管理

护理目标评价主要用于对患者的预期目标进行评价，护理措施执行完成后，护士需要评价是否达成预期目标，从而判断是否需要调整护理计划。护士也需要对诊断的结局进行评价。

5-1

护理评价录入

系统应支持依据预期目标的达成情况进行预期目标的评价，系统需提供预期目标待评价提醒功能，护士可以通过评价结果来进行诊断计划的中止。系统应支持对评价原因的录入。

6

系统智能检索服务

系统智能检索主要用于对护理常用诊断和计划进行数据统计和检索，便于各个科室患者的整体护理情况。

6-1

护理常用诊断查询

系统应支持对科室内经常使用的护理诊断进行查询，能够对护理诊断的使用频次进行汇总和分析。

6-2

患者执行计划查询

系统应支持对科室内患者的护理计划执行情况进行查询，能够对科室内的护理计划执行情况进行跟踪管理。

7

无纸化支持

主要用于护理计划制定和执行后，能够自动生成患者的护理计划单和执行记录单，并支持无纸化归档。

7-1

护理PIO计划单

系统应支持患者的PIO护理计划单的自动生成和展示功能。

7-2

护理PIO记录单

系统应支持患者的PIO护理记录单的自动生成和展示功能。

8

EMR系统智能支持

EMR系统智能支持主要用于通过EMR系统录入患者的体温单、护理记录、评估数据后，能够自动产生护理诊断和护理计划。

8-1

体温单数据支持

系统应支持根据患者体温单录入的生命体征数据进行护理诊断和护理计划制定的功能。

8-2

护理评估单数据支持

系统应支持根据患者护理评估单的评估内容进行护理诊断和护理计划制定的功能。

8-3

护理记录单数据支持

系统应支持在填写护理记录单时，能够自动同步已经制定的护理诊断和护理计划和已经执行的护理措施情况的功能。

序号

功能名称

技术和性能参数需求

1

模板配置

模板配置主要用于配置人员对护理病历填写模板进行配置管理，需具有进行模板元素和样式配置的功能，可以按照科室进行分配模板，实现医院按护理病历的科室定制化管理。

1-1

元素维护

系统应支持病历元素结构化定义和存储。

应支持多途径录入和统一数据管理。

1-2

模板维护

参照纸质病历的样式，通过系统进行病历模板的自定义和可视化维护。系统应支持模板中设置元素、元素组以及元素区域。

1-3

模板分配

系统需具备模板分配功能。支持将病历模板分配到指定的科室，对应科室下的护理人员就能够使用该模板进行病历的书写。

2

权限配置

系统应支持权限配置，权限配置主要用于配置人员对护理病历的操作权限进行配置管理。具有按照角色对人员操作护理病历的权限进行指定的功能，支持对护士电子签名进行维护。

2-1

角色维护

应支持角色配置，不同角色具有不同的权限组合。

2-2

权限维护

应支持精细化的权限配置。

2-3

图章签名维护

系统需具备维护护理人员手写体签名图片的功能。

3

患者信息一览

患者信息一览用于对住院患者进行整体展示。展示方式要具有应支持卡片和列表展现等多种模式。

患者信息一览中要显示患者的常用信息和详细信息。

患者列表要有分类显示功能，支持显示在院患者、出院患者和转科患者，实现护士对住院患者的快捷过滤。

3-1

在院患者一览

系统应支持以卡片和列表两种展现方式显示病区全部在院患者，以满足不同用户使用习惯。

系统应支持对患者多种标识。标志信息包括但不限于特级护理、一级护理、二级护理、三级护理、病危、病重、新入、高温、手术、过敏、风险（疼痛、压疮、血栓、跌倒、非计划性拔管等）。患者一览要显示患者数量、显示相应的特殊标识，并支持进行条件的筛选。

系统要以清晰的方式显示患者重点信息。包括但不限于：病历号、姓名、年龄、诊断、费用、入院时间、护理等级。

在院患者一览支持扩展信息显示，比如患者联系电话、住院医生、责任护士等。

3-2

出院患者一览

系统应支持以列表形式显示出院患者。系统需具备按照出院日期、病历归档状态、住院医生、责任护士进行筛选以及精准定位患者（住院号、床号、姓名）的功能。

系统应支持显示患者住院号、姓名、性别、年龄、诊断、出院时间、住院医生、责任护士、病案归档状态等重要信息。

3-3

转科患者一览

系统应支持以列表形式显示转科患者，可以按照转科日期、病历归档状态、住院医生、责任护士进行筛选以及精准定位患者（住院号、床号、姓名）。

系统应支持显示患者住院号、姓名、性别、年龄、诊断、转科时间、住院医生、责任护士等信息。

4

统一护理病历管理

护理病历应实现统一管理。护理病历主要用于对住院患者的护理病历进行智能化书写，应支持对体温单、护理记录单、血糖单等护理文书进行和编辑。

系统应支持对患者的检查检验结果进行和对医生书写的病历进行。

系统应具有支持护理病历快速录入模式，帮助提高护士工作效率。

4-1

集成式护理病历工作台（患者首页）

系统应支持展开单个患者的详细信息，包括患者的基本信息、费用信息、最新的身高、体重、BMI信息、各类风险标识等重点信息。

系统应支持过敏史统一管理，支持对过敏信息的录入和展示。

系统应支持通过树形列表直观展示患者当次住院的所有病历信息，具备基于护士的常用病历及使用习惯配置病历展现形式。

4-2

体温单管理

系统应支持体温单样式维护，支持自定义体温单样式。

系统应支持依据医院文书要求，定制体温单数据提取规则，自动提取数据显示到体温单。

系统应支持体温单录入，可实现录入生命体征信息和特殊项目信息。

系统应具备录入后系统会自动绘制体征曲线的功能。

系统应支持体温单单页打印、全部打印。

系统需提供体温单数据录入接口，供外部系统（如移动护理、重症）将患者体征数据写入体温单。

系统需提供患者体征数据接口，供其他业务系统调取患者体征数据。

4-3

婴儿体温单

系统应支持婴儿相关病历。包括体温单模板维护、体温单书写等相关功能。

4-4

护理记录单管理

系统应支持护理记录单样式维护，护理项目设置，特殊符号，护理记录备注项等功能，实现护理记录样式自定义维护。

系统应支持护理记录单结构化录入，可自定义列头，支持插入评估、插入护理常用组套、插入护理措施、插入医嘱、插入检查检验结果、插入特殊符号等，便于护士书写护理记录。

系统应支持对已签名的护理记录单历史的功能，便于护士追溯历史更改信息。

系统应支持将护理记录信息同步至体温单，也支持将护理记录总结的入出量数据自动同步至体温单，形成护理数据一元化管理。

系统应支持多种形式的护理记录单打印，支持当前页打印、全部打印、续打功能。系统应支持护理记录电子签名。

系统应支持护士长对护理记录进行审核签名。

系统应支持护理记录录入接口，供其他系统（如移动护理）写入护理记录数据。

系统应支持提供护理记录数据查询接口，供外部系统获取护理记录数据。

4-5

护理文书智能引擎

系统应支持护理文书数据统一管理，支持文书之间相同数据共享。

系统应支持护理文书自然语言规则算法管理，可进行语言规则维护，实现将结构化数据自动生成自然语言并同步至护理文书。

系统应支持护理记录引用内容自动生成，护理评估可自动生成结果，患者体征可自动导入，可自动生成护理问题列表，可自动生成护理措施执行记录单，可自动同步医嘱执行信息。

系统应支持护理文书数据统一管理，支持文书之间相同数据共享。

系统应支持护理文书自然语言规则算法管理，可进行语言规则维护，实现将结构化数据自动生成自然语言并同步至护理文书。

系统应支持护理记录引用内容自动生成，护理评估可自动生成结果，患者体征可自动导入，可自动生成护理问题列表，可自动生成护理措施执行记录单，可自动同步医嘱执行信息。

4-6

生命体征管理

系统应具有批量录入患者当日生命体征功能。

系统需提供体温待测提醒功能。支持待测量患者的体征批量录入。

体温待测规则应可配置，支持本地化配置。

4-7

入院评估单

系统应具备患者入院首次护理评估单的显示、录入和打印功能。

4-8

血糖单

系统应具备患者的血糖单整体显示、录入和打印功能。

4-9

护理知情同意书

系统应具备护理相关知情同意书显示、签名及打印功能。

4-10

医生病历

通过系统，可以医生病历，包括但不限于入院大病历、病程记录、手术记录、出院小结等。

4-11

检验检查结果

通过系统，可以患者的检验检查结果报告。

4-12

既往病历

通过系统，可以患者既往病历信息。

4-13

其他护理病历

系统应支持提供产时、产后记录等其它护理模板维护、录入功能。

4-14

病历快速录入模式

系统应支持多患者体征录入、单患者体征快速录入、单患者护理记录快速录入。系统应支持从患者信息一览快速进入以上录入功能。

5

护理评估管理

护理评估管理主要用于对住院患者的评估录入、和分析，应支持智能化的评估模型管理，根据患者智能推荐护理评估工具，支持自动生成评估风险等级并进行提醒，帮助护士关注风险患者，保障患者安全。

5-1

患者评估管理

系统应支持多种评估量表用使用评估模型方法对患者进行评估，包括入院评估和出院评估。

支持根据患者年龄自动分配符合患者使用的评估量表。

未了实现同质化管理,系统应具备护理评估套餐功能。通过评估套餐，根据实际需要选择对应套餐对患者进行评估。

系统应支持智能评估功能。依据评估结果，可推算下一次评估的时间，产生评估提醒，评估结果可自动生成患者风险标识。

系统应支持护理评估追溯，可按照评估时间患者的历史评估内容。

系统需提供评估接口，供外部系统将护理评估信息同步到患者护理评估系统。

系统需提供评估结果查询接口，供外部系统调用以获取患者评估结果。

系统需提供评估风险信息，供外部系统调用以获取患者各类风险等级。

5-2

病区评估风险分析

系统应支持以图形化的方式直观展示病区风险。包括但不限于压疮风险、拔管风险、跌倒风险、隔离风险、过敏风险、预警风险、疼痛风险、血栓风险患者的评估结果。支持按照低危、中危、高危分别显示风险患者在病区中的占比情况。

5-3

患者评估量表分析

系统应支持以表格的方式展示患者的评估量表数据。包括但不限于以下评估表：日常生活自理能力（Barthel指数）评估量表分析、Morse跌倒坠床风险评估量表分析、Braden评估量表分析、非计划拔管评估量表分析、Caprini风险评估量表分析、NRS2002营养风险筛查量表分析等。

应支持对患者的护理评估量表进行定制打印。

5-4

患者评估趋势分析

系统应支持以图形化的方式直观展示患者的评估趋势。包括带不限于：血糖结果分析、血压结果分析、NRS自评分析、Morse跌倒评估分析等。

5-5

护理评估知识库

系统应支持护理评估术语库管理，提供评估模型中所用护理评估的标准化术语，支持本地化扩展维护。

系统应支持提供护理评估模型库管理，提供专项、专科相关护理评估模型。

系统应支持提供护理评估标准化工具库，提供相关的护理评估标准化工具。

5-6

护理评估知识库本地化管理

系统应提供的护理评估模型库，我院护理评估模型管理可基于知识库进行增减。

系统应支持各种体征规则维护，包括但不限于对体温，血压，脉搏，呼吸等体征值的上下限阈值的维护。

系统应支持对护理评估套餐的管理。支持按全院和科室的定制化维护。

5-7

评估任务分解

系统应具备任务分解功能。支持评估任务分解算法管理，可根据评估结果制定评估计划，自动分解待执行评估任务。

系统需具有支持根据评估结果的动态变化动态更新评估任务的能力。

序号

功能名称

技术和性能参数需求

1

权限管理

应支持多病区管理。

支持统一身份验证。支持与核心系统用户名和密码一致。

2

住院患者管理

住院患者管理功能应支持病人的基本信息查询，基本信息包含床号、姓名、性别、年龄、住院号、护理、饮食、诊断、入院时间、过敏记录。

应支持病人住院基本信息查询，入院基本信息包含病情、入院科室等。

应支持病人的诊断信息查询。应支持病人的费用、总费用、自费金额、统筹金额、余额等信息查询。

应支持病人手术后天数查询。

应支持根据医生身份管理患者列表。主治医生和主任医生的患者列表包含组内所有床位医生的患者总列表。应支持由医生自定义关注患者列表。

3

医嘱查询

医嘱查询功能应支持和浏览病人在院期间的全部医嘱，

应支持按照医嘱类别过滤分类医嘱数据，应支持按照条件过滤医嘱，支持醒目地区别临时医嘱和长期医嘱，应支持通过颜色区分医嘱状态，应支持医嘱显示时按照时间倒序排列，默认显示近一周的医嘱，应支持显示医嘱的关键信息，包括医嘱名称，用法用量，频次，起止时间。

4

入院记录

应支持病人的入院记录内容。

支持多种类型入院记录。包括入院记录，24小时内入出院记录，24小时内入院死亡记录。

5

病程记录

应支持患者的病程记录信息，病程记录的类型与内容与电子病历系统中的病程记录保持一致。

6

体温单

应支持患者的体温单信息。

7

检验报告

应支持查询浏览患者的检验报告信息。

检验报告可以按照报告类别，报告时间进行分类显示。支持看检验报告的结果信息。

应支持检验结果的检验项目、项目结果值及单位、参考范围、提示，对于结果超标的项目需支持通过颜色区分。

8

检查报告

应支持浏览和查询病人检查报告和放射影像图片，支持检查结果报告。

9

便签记录

应支持医生在查房过程中随时记录查房记录，应支持查房功能界面的截屏和标记。

10

录音记录

录音记录应支持医生在查房过程中随时录音，方便医生记录查房过程。

11

拍照记录

拍照记录应支持医生在查房过程中随时拍照，方便医生记录查房过程。

序号

功能名称

技术和性能参数需求

1

输液患者管理

当前输液患者列表，需支持通过患者姓名，门诊号过滤患者。

2

配药管理

需对药品配置流程进行管理，记录摆药、配药流程。扫描药品标签核对药品信息，患者信息，需记录配药流程摆药人、配药人、核对人信息，及对应操作时间。

3

输液管理

护士需扫描病人条码和输液贴条码完成输液核对；

需通过扫描输液瓶签二维码完成输液开始操作记录；

需实时记录操作人和操作时间等信息；

输液结束时，扫描输液瓶签二维码执行输液结束操作，系统需记录结束输液操作者及操作时间信息，完成输液操作。

输液开始后2分钟内，需通过再次扫描输液贴二维码进行输液撤销操作，以便撤销误操作。

4

皮试管理

护士需扫描病人条码和皮试贴条码完成皮试核对；

期间需完成皮试的开始和结束的操作记录；

需实时记录操作人和操作时间等关键数据。

5

肌注执行

护士需扫描病人条码和肌注贴条码完成肌注核对；

期间需完成肌注的操作记录；

需实时记录操作人和操作时间等关键数据。

6

雾化执行

护士需扫描病人条码和肌注贴条码完成雾化核对；

期间需完成雾化的操作记录；

需实时记录操作人和操作时间等关键数据。

7

输液巡回

需对输液时患者情况进行巡回及记录；

需记录输液时管路畅通情况及患者输液不良反应。

8

统计报表

需查询门诊输液工作量；

需查询输液异常记录；

需按时间段方式进行查询统计。

序号

功能名称

技术和性能参数需求

1

数据挖掘平台

依托大数据+人工智能技术，把医院信息系统中各个业务系统的数据库的信息抽取形成文档库，实现患者临床数据的集中管理，为用户提供一个统一的视图入口，实现全院临床信息整合有效管理，同时为基于大数据的决策分析方面提供临床决策支持的数据来源。解决传统信息化患者的临床信息无序、分散、断层的存储在不同的业务系统中，临床医务人员难以全面了解患者完整的医疗活动情况和历史诊疗信息的情况。

1-1

数据资源管理

1-1-1

自定义数据资源

支持本地数据资源和自定义数据资源。

本地数据资源管理支持从格式化文本文件中读取数据。

支持用户根据实际需求添加的目录信息、数据源信息，主要包含Oracle, MySQL ,Hive, RocketMQ,DaMeng五种类型，通过配置数据源信息建立获取数据方式。

支持用户根据实际需求，通过已创建的数据源同步具体资源信息，用于后续数据分析使用。

支持自定义数据资源同步存入hive或者mysql。

1-1-2

资产数据资源

支持对数据仓库中共享数据集以及开放脱敏数据集的同步管理，系统支持将对应数据目录信息同步到挖掘平台数据资源管理模块并展示，用户可根据需要同步具体需要进一步分析的数据资源到挖掘平台，用于后续数据分析使用。

1-2

预处理控件库

支持对数据进行预处理，提供常用的预处理组件14种，包括数据过滤、SQL脚本处理、归一化、数据转换、随机抽样、UNION拼接、标准化、缺失值填充、JOIN、类型转换、分层抽样、特征离散、数据拆分、正则化等，并对组件功能进行说明。

1-3

机器学习算法库

平台需自带机器学习算法库，包括但不限于朴素贝叶斯算法、决策树算法、逻辑回归二分类算法、线性回归算法、随机森林算法、隐马尔可夫算法、SVM二分类算法、广义线性模型算法、梯度提升决策算法、Kmeans算法、Apriori算法、MinHash聚类算法、PageRank算法、FP-Growth算法、DBSCAN算法、高斯混合模型算法、PICDbscan算法、幂迭代聚类算法等，并对功能算法进行说明。

1-4

算法模型训练

1-4-1

模型训练编辑器

训练任务主要包含以下功能：

节点面板：选中节点并在流程编辑区域单击鼠标。

流程编辑区域：根据业务需要将节点连线，完成流程的配置。

节点配置区域：拖拽节点后，需配置相关节点参数，保存相关配置。

数据预览和结果展示区：任务运行后展示模型评估结果和计算结果。

1-4-2

数据源组件

数据源组件需支持本地数据资源、自定义数据资源、数据资产目录三种方式。支持选择所需数据源组件直接拖动到编辑器画布里，即可实现机器学习训练模型数据集选取。

数据集的准备上需区分训练数据集和验证数据集，训练数据集用于模型训练，验证数据集用在计算模型管理中计算任务中。

1-4-3

自定义算法库

支持已创建的自定义算法组件列表，可在创建训练模型中根据需要选择自定义算法组件。

1-4-4

数据输出

支持把训练的模型保存为文件，便于后续对模型进行管理、复用等，通过选取数据输出组件来设置模型名称等基本信息。

1-4-5

训练任务管理

支持训练任务列表管理当前开发的全部训练任务，提供任务的运行、停止、编辑、提交、日志、删除和查询等操作。

1-4-6

算法模型管理

支持对训练好的算法模型进行管理，支持模型信息，上线、下线、删除等功能。

1-4-7

自定义训练算法

系统支持自定义算法，支持用户上传并保存的自定义训练算法模型信息。支持自定义算法详情、删除等功能。

1-5

计算模型管理

业务模型管理根据业务流程创建计算任务，基于训练好的算法模型和创建好的规则模型完成业务计算任务创建和维护。

1-5-1

模型计算编辑器

模型计算编辑器需支持 spark,python两种计算框架

模型计算编辑界面主要包含以下功能：

节点面板：选中节点并在流程编辑区域单击鼠标。

流程编辑区域：根据业务需要将节点连线，完成流程的配置。

节点配置区域：拖拽节点后，需配置相关节点参数，保存相关配置。

数据预览和结果展示区：任务运行后展示模型评估结果和计算结果。

1-5-1-1

数据源组件

数据源组件支持本地数据资源、自定义数据资源、数据资产目录三种方式。支持选择所需数据源组件直接拖动到编辑器画布里，即可实现机器学习训练模型数据集选取。

1-5-1-2

预处理控件库

展示所支持的预处理控件，支持选择所需预处理组件直接拖动到编辑器画布里，即可实现对机器学习训练模型数据集进行相关预处理操作。

1-5-1-3

机器学习组件库

展示所支持的机器学习算法组件，支持选择所需机器学习算法组件直接拖动到编辑器画布里，即可实现对机器学习算法的选取。支持算法库。

1-5-1-4

统计分析组件

1、支持层次分析法节点

层次分析法根据问题的性质和要达到的总目标，将问题分解为不同的组成因素，并按照因素间的相互关联影响以及隶属关系将因素按不同层次聚集组合，形成一个多层次的分析结构模型，从而最终使问题归结为最低层(供决策的方案、措施等)相对于最高层(总目标)的相对重要权值的确定或相对优劣次序的排定。

2、支持分布统计节点

可以根据设置的数据精度，自动计算数据分档区间（默认五个），引擎会根据区间分段生成直方图，最大最小值、十分位数、方差统计数据。

使用限制：特征分析列只能选择一列，且必须是数值类型；输出精度必须与选择的特征列精度保持一致；区间分段设置时必须在源数据区间范围，且最少一个区间档位。

1-5-1-5

自定义算法组件

支持已创建的自定义算法组件列表，可在创建训练模型中根据需要选择自定义算法组件。

1-5-1-6

数据输出

支持把模型计算结果保存为文件，便于后续对结果进行、使用等，通过选取数据输出组件来设置模型名称等基本信息。

1-5-2

计算任务管理

计算任务管理管理当前开发的全部计算任务，支持任务的运行，停止，编辑，提交，日志，删除和查询操作。

1-5-3

自定义计算算法

自定义计算算法模块管理当前用户上传并保存的自定义计算算法模型信息。提供上传自定义算法，详情，删除自定义算法等功能。

1-6

规则模型管理

1-6-1

规则变量管理

规则变量管理模块主要管理系统会用变量信息。首先需要添加变量的分类，然后再添加具体的变量字段。

1-6-2

规则模型编辑器

规则模型编辑器主要包含规则文件目录和文件编辑区两个模块，可实现决策表和评分卡文件的创建。

决策表是一种以表格形式表现规则的工具，它非常适用于描述处理判断条件较多，各条件又相互组合、有多种决策方案的情况，决策表提供精确而简洁描述复杂逻辑的方式，可将多个条件及与这些条件满足后要执行动作以图形化形式进行对应，对于决策表的定义，提供全可视化、图形化的操作方式，通过简单的鼠标点击就可以快速定义出与业务相匹配的决策表。

评分是对个人或机构的相关信息进行分析之后的一种数值表达，表示此人或此机构由于信用活动的拒付行为所造成损失风险的可能性，评分通常用于对个人或机构的风险管理与评估。

规则模型中的评分卡就是用来计算评分的，它使用二维表形式展示目标对象的各个属性，针对不同属性设置不同区段的条件，每个区段条件对应不同的分值，运行任务会根据定义的区段条件自动计算目标对象的评分。

1-6-3

规则模型管理

支持用户点击添加规则模型后弹出配置规则模型名称和ID对话框，完成后，点击该模型进行对应规则文件添加，配置完成点击保存后，该模型可用于业务计算任务中。

1-7

服务管理

1-7-1

服务任务管理

对于计算结果，支持以页面服务和数据服务的形式对外提供，服务任务列表管理当前开发的全部服务任务，支持服务任务的编辑和删除。

1-7-2

服务任务编辑器

提供了服务任务的编辑器，用于编辑页面服务和数据服务。

1.数据服务节点

功能要求:

数据服务节点，主要是将计算结果生成数据服务，通过数据服务的方式为第三方应用系统进行使用。在设置数据服务时，系统自动会在服务总线上注册一个未激活服务，同时会将服务的对应服务名称，账号密码等信息显示。当整个计算模型运行时，服务总线将会自动启动服务任务，为第三方系统提供数据服务。

2.页面服务节点

功能要求:

页面服务节点，主要是将计算结果生成页面服务，通过页面服务的方式为第三方应用系统进行使用。在设置页面服务时，系统自动会在服务总线上注册一个未激活服务，同时会将服务的对应服务名称，账号密码等信息显示。当整个计算模型运行时，服务总线将会自动启动服务任务，为第三方系统提供页面服务。

1-7-3

服务管理

服务列表支持管理当前开发的全部服务任务包含页面服务和数据服务两种类型，支持服务详情和删除。

1-8

应用管理

1-8-1

业务场景管理

在用户的使用过程中，支持一个业务需求对应了若干个计算任务，创建业务模型对这些计算任务进行管理，可以更好的展示任务与任务间存在的关联关系，任务运行状态等，可以对业务需求有一个清晰的认识，同时方便后续的维护。业务模型列表支持业务模型的编辑，，删除和查询操作。

1-8-2

业务场景编辑器

业务场景编辑器支持创建业务流程构建业务模型同时将规划或者已创建好的计算训练任务进行映射，清晰的展示业务数据分析的整体逻辑，将后台复杂的数据分析流程清晰的展示到页面，帮助用户有效监控数据分析过程。

1-8-3

业务模型托管

支持模型托管功能，实现模型上传，模型编辑，运行参数配置等功能，保障已有模型可在开发平台管理运行。

1-9

应用案例

应用案例主要用于对面向业务的计算任务转换为应用案例，实现应用案例的累计沉淀，帮助在其他相似需求快速复制使用。

通过应用案例可快速复制当前应用案例的算法节点配置情况。支持应用案例的导入、导出和删除操作。

序号

功能名称

技术和性能参数需求

1

审核科室与不良事件关系维护

需完成系统定义的审核科室角色与现场实际科室的对照，以及不良事件类型与审核科室角色的对照。

2

医疗争议上报

需完成医疗争议不良事件的填报及未审核前的修改功能。

3

护理问题上报

需完成患者管路滑脱不良事件的填报及未审核前的修改功能。

需完成院内发生压疮不良事件的填报及未审核前的修改功能。

患者跌倒坠床登记：完成患者跌倒坠床不良事件的填报及未审核前的修改功能。

需完成护理缺陷不良事件的填报及未审核前的修改功能。

需完成护理其他问题不良事件的填报及未审核前的修改功能。

4

药品问题上报

需完成药品不良反应个案不良事件的填报及未审核前的修改功能。

需完成疑似药品质量问题不良事件的填报及未审核前的修改功能。

需完成药房调配问题事件的填报及未审核前的修改功能。

需完成群体性药品不良反应事件的填报及未审核前的修改功能。

需完成医院药品质量问题网络填报及未审核前的修改功能。

5

器械及耗材问题上报

需完成器械及耗材问题事件的填报及未审核前的修改功能。需完成器械及耗材问题事件的填报及未审核前的修改功能。

6

输血反应上报

需完成输血反应事件的填报及未审核前的修改功能。

7

不良事件审核

需完成医患办对不良事件的审核反馈操作。

需完成医务处对不良事件的审核反馈操作。

需完成护理部对不良事件的审核反馈操作。

需完成药学部对不良事件的审核反馈操作。

需完成输血科对不良事件的审核反馈操作。

序号

功能名称

技术和性能参数需求

1

病历归档

1-1

医生病历提交

需要支持在患者诊疗结束后，医生确认医疗病历书写完毕后，在信息系统中进行标识。

1-2

数字文件自动采集

需要支持病历提交后，归档系统将电子病历、医嘱单、病案首页、体温单、检验结果报告、检查结果报告等电子诊疗相关信息单据自动转换并传输至病案归档系统中。

1-3

数字文件自动分类

需要支持将电子诊疗相关记录传输至病案归档系统时，依据归档系统中约束好的类别，将电子诊疗记录自动分类到对应类别中。

1-4

异常信息校验

需要支持将电子诊疗相关记录传输至病案归档系统时，若过程中出现程序异常信息，用户可在系统中到异常信息再针对性处理。

1-5

医生病案核对

需要支持在归档系统在处理完医疗病历后，医生再次核对医疗电子病案内容。

1-6

病案室病案核对

需要支持对已经提交的电子病案，病案室进行二次核对工作。

1-7

病案驳回

需要支持对已经完成收录的不合格病历进行驳回，需医护修改后重新提交。

1-8

病案归档

病案室核对完电子病案后，患者的电子病历正式归档，之后便可进行复印、借阅等操作。

1-9

电子病案解归档

需要支持对已经归档的病案，若发现问题则进行解归档，解归档后，医生便可修改病历再次进行归档。

1-10

病案完整性校验

需要支持其他系统接口对病案归档是否缺少报告及病历进行校验及信息展示。

2

病历打印

2-1

病案打印登记

需要支持通过身份证、姓名、住院号等患者基本信息定位已归档的病历。选择患者需要打印的病历组套 ，并自动计算出打印费用，生成打印小票。

2-2

病案打印代办人证件翻拍

需要支持打印登记时翻拍办理打印人员的相关证件。

2-3

病案批量打印

需要支持将收费后生成在打印队列中病历依次打印。提供对打印的单独操作，如补打、选打等。系统提供单个病历打印预览。

2-4

病案套餐打印

需要支持病历复印工作人员可根据患者复印病历的用途选择套餐，按照套餐中维护的病历类型选择病历。

2-5

病案打印套餐设置

需要支持病历打印套餐维护功能，可修改、添加套餐中的病历类别。

3

病案借阅

3-1

电子病案借阅申请

需要支持申请查阅所需要的病案，以及借阅期限。可通过使用不同条件如：诊断名称，手术名称等，筛选出不同类型的电子病案。

3-2

电子病案借阅审批

需要支持病案室人员审批或拒绝医生借阅申请。

3-3

电子病案借阅查阅

需要支持查阅患者完整的电子病案信息。

3-4

超时自动回收

需要支持自动回收查阅病案权限。

3-5

申请记录查阅

需要支持病案借阅申请、审批、借阅时间记录。

4

诊间高拍

4-1

诊间高拍上传

需要支持医/护人员在诊疗过程中通过高拍仪设备将纸质病历高拍。

4-2

诊间高拍分类

需要支持将病历进行分类，方便以后进行查阅及归档使用。

4-3

诊间高拍文件浏览

需要支持查阅到当前患者本次住院期间高拍的所有电子化的病历。

序号

功能名称

技术和性能参数需求

1

危急值过程管理

需支持接收医技系统（LIS、PACS、心电、病理）危急值、接收各医技系统危急值，并发送到相关医生护士。

需支持护士接收危急值，一般具有权限。

需支持医生接收危急值，一般具有、处理权限。

需支持医生或护士回复后，反馈到各医技系统。

2

危急值管控管理

危急值平台接收到业务系统危急值后，通过消息机制，需自动提醒医生护士。

危急值一定时间无回复后，需自动发送到上级医生。

需支持收到危急值后，如果不回复，弹窗将不能关闭。

医生护士只安装一个危急值平台，避免安装各个业务系统客户端。

3

接口管理

需支持与各医技系统（LIS、PACS、心电、病理）两种接口模式：平台接口、系统直连。

4

危急值统计分析

需支持跨医技业务系统分析、处置率统计分析、临床排名统计、闭环耗时统计、分布统计。

序号

功能名称

技术和性能参数需求

1

医疗质量

1-1

功能定位

需支持展现医院分级诊疗和特需医疗服务的占比情况，便于更好地促进优质医疗资源下沉、有序就医和满足不同患者的需求。

具体指标包括：门诊人次数与出院人次数比、下转患者人次数、出院患者手术占比和特需医疗服务占比四个指标。其中特需医疗服务占比包括特需医疗服务量占比和特需医疗服务收入占比。

1-2

手术分析

需支持对手术不同维度的数据进行统计和计算，展示手术的工作量和工作效率，使管理者更好地了解医院的手术情况，多指标多维度的展示手术完成情况。

具体指标包括：日间手术占择期手术比例、出院患者手术占比、出院患者微创手术占比、出院患者四级手术比例。

1-3

手术质量

需支持统计手术情况以及手术结果，更好地保证患者的手术安全和质量。

具体指标包括：手术患者并发症发生率、I 类切口手术部位感染率、优质护理服务病房覆盖率。

1-4

单病种分析

需支持以特定的病种为单位，通过对疾病诊疗全过程，包括诊断、检查、治疗、治疗效果以及医疗费用等，实施标准化控制，达到提高医疗质量和促进医疗资源合理利用的目的。

主要病种包括急性心肌梗死、心力衰竭、肺炎（住院、成人）、肺炎（住院、儿童）、脑梗死、髋关节置换术、膝关节置换术、冠状动脉旁路移植术、剖宫产、慢性阻塞性肺疾病。

每个病种统计的指标为：平均住院日、平均费用、次均药费、次均手术治疗费、次均材料费、出院人次、死亡人数。

1-5

设备阳性率

需支持统计不同大型设备的检查报告阳性结果数与同期大型医用设备检查数的比值以及不同科室的检查报告阳性结果数与该科室同期大型医用设备检查数的比值。多角度多方面的给出设备阳性率监测指标的变化情况，使管理者更好地掌握各个设备的检查结果。以此促进大型医用设备科学配置和合理使用，充分发挥其在诊疗中的优势作用。

1-6

死亡情况统计

需支持统计医院总体出院患者死亡率以及低风险组死亡率，对各个科室的死亡人数统计，对低风险组的死亡人数统计，下钻到各死亡患者详细信息。统计分析医院的死亡情况，便于管理者更好地掌握死亡情况的变化趋势。

1-7

合理用药

需支持通过对处方使用比例、抗菌药使用强度、基药使用率、基要采购品种数和国家组织药品集中采购中标药品使用比例的统计分析，方便管理者监督药物的使用情况，及时统计用药数据以保证患者用药安全。逐步实现药学服务全覆盖，为患者提供个性化的合理用药指导。

具体分析的指标包括：点评处方占处方总数的比例、抗菌药物使用强度、门诊患者基本药物处方占比、住院患者基本药物使用率、基本药物采购品种数占比、国家组织药品集中采购中标药品使用比例。

1-8

服务流程

需支持通过对门诊患者预约诊疗率及预约后等候时长的统计，便于管理者及时掌握门急诊预约诊疗服务情况，更好地优化预约诊疗服务制度。

具体分析的指标包括：门诊患者平均预约诊疗率、门诊患者预约后平均等待时间。

2

运营效率

2-1

资源效率

需支持对医院床位数、各科室医务人员结构进行统计，更直观地了解医生劳动负荷及医院人力资源配备情况，方便后续进一步推进分级诊疗制度，改善医务人员的工作环境和后勤保障，为改善医疗服务创造条件。

具体分析的指标包括：卫生技术人员结构、医护比、每名执业医师日均住院工作负担、每百张病床药师人数。

2-2

收支结构

需支持展示医院门急诊和住院部分的收入占比情况以及各项支出情况。通过划分一系列二级指标直观反馈医院整体经济运营状况，引导医院提升精细化管理水平，降低潜在风险。

具体指标包括：

2-3

收入分析

需支持综合分析医院整体医疗收入、药品收入、检验收入、检查收入等各分项收入的构成比例和整体收入趋势。着重监测辅助用药收入占比和重点监控高值医用耗材收入占比两项指标。帮助管理者全面、快速的掌握医院收入的来源以及变化趋势，提前发现问题并有针对性的采取措施，进行合理的导向。规范医疗服务行为，控制医疗费用不合理增长。

具体指标包括：医疗服务收入占比、辅助用药收入占比、重点监控高值医用耗材收入占比。

2-4

费用监控

需支持通过对医疗收入的监控，引导医院主动控制成本，合理检查、合理用药、合理治疗，控制医疗费用不合理增长。

具体分析的指标包括：医疗收入增幅、门诊次均费用增幅、住院次均费用增幅、住院次均药品费用增幅。

3

持续发展

3-1

人才培养

需支持统计医院接受其他医院进修并返回原医院独立工作人数占比指标、医院承担培养医学人才的工作成效和学科建设三类指标数据，方便管理者横向比较人才培养的各项指标的标准值、实际值以及同期值，纵向对比各个指标与标准值之间的差距。方便管理者把握人才培养的方向以及有针对性地提高人才培养力度。

4

报表管理

需支持公立医院上报报表的数据查询统计，包括全部指标报表和可选指标上报报表，上报报表依据上报状态动态生成，支持报表下载。

5

指标维护

5-1

定量填报

需支持对一些不能通过系统获取的定量指标，可通过定量填报按年月的维度维护指标数据，由于指标的权限分配到不同科室，各科室可维护相应权限内需要填报的数据，保证绩效考核数据完整性。

5-2

定性填报

定性指标一般都不能从系统获取，需支持通过定性填报按年月的维度维护指标数据，由于指标的权限分配到不同科室，各科室可维护相应权限内需要填报的数据，保证绩效考核数据完整性。

5-3

权限分配

需支持对全部公立医院绩效考核指标进行权限设置，主要用于填报指标的数据填写及验证。

5-4

设置上报

需支持可设置指标的上报状态，管理者可通过设置指标上报状态，形成上报报表页面，更清晰看到需要上报的数据。

序号

功能名称

技术和性能参数需求

1

VTE患者管理

需针对在院患者病历自动进行风险评估，以VTE防治的早评估、早预防、早诊断和早治疗为目标，面向医护构建一体化VTE防治的患者管理系统。

需通过自动扫描在院病历，智能进行风险评估，识别高、中、低危风险患者，并把结果推送给医护，起到智能预警作用。医生基于预警提醒对病例进行充分的风险评估、出血评估、临床可能性评估等，系统会根据评估结果生成一套针对当前病例的有效的预防方案、治疗方案，辅助医生开展诊疗工作。

护士可基于VTE预警级别可以开展不同的健康宣教。

需支持展示在院患者列表，针对VTE风险患者醒目标识

需支持患者历次评估结果，按照时间轴的方式进行排序

需支持评分结果医护互通，医护任何一方评估后结果内容可提醒至另一方

2

基础数据治理

需以患者为中心进行VTE数据集成、处理、存储，同时基于人工智能技术将医院海量的临床数据进行结构化、标准化处理，构建VTE数据库，为后续临床路径，智能评估，运营分析及临床科研提供数据支撑。

2-1

数据集成

需从HIS、LIS、PACS、手麻、电子病历、护理病历等系统获取病例在院期间的全部有效诊疗数据，以患者为中心进行VTE数据集成。

需支持以服务接口方式实现数据集成，满足互联互通评级要求。

需支持数据实时采集，保证对生产系统数据库性能无影响。

2-2

医疗术语标准规范管理

对于结构化的医疗术语与国家标准、国际标准或行业标准需分别进行映射，从而实现结构化医疗术语的标准化、规范化。

需支持对国家、国际标准编码映射，如临床术语、疾病诊断编码ICD-10、药品名称等。

需支持国际标准临床术语SNOMED-CT、检验名称LOINC、ICD编码。

2-3

VTE数据标准化处理

针对临床VTE的应用场景，需支持基于人工智能技术将医院海量的临床数据进行结构化、标准化和归一化处理，在治理体系VTE数据流动过程中，涉及两种治理手段：非结构化数据提取和标准映射归一化，经过数据标准化处理后可直接被临床VTE应用。

需支持对非结构化数据的治理

需支持机器学习方法

需支持患者隐私信息脱敏技术

需支持对数据进行标准化治理

2-4

VTE数据库

需基于数据标准化处理，治理后的数据自动汇总形成VTE数据库，为后续临床路径，智能评估，运营分析及临床科研提供数据支撑。

3

AI智能引擎

需通过信息化、智能化技术对在院患者病历进行风险评估、出血评估、临床可能性评估。通过评估结果指导医护对患者进行预防、诊断、治疗、预后等规范化诊治。本模块包括VTE量表智能推荐、VTE量表智能推荐，VTE智能提醒等二级功能模块。

3-1

VTE量表智能推荐

需基于内置的VTE评估处理逻辑，即VTE管控阶段，DVT管控阶段，PTE管控阶段三个阶段，在不同阶段内根据内置的规则，自动提示相应关联的量表进行评估。同时需支持在特定的时间或事件节点自动提示相应的量表进行评估。

需支持对手术患者进行评估（Caprini评估量表），系统根据评估分值判断患者是否需要进行手术患者出血评估

需支持医生对非手术患者进行评估（Padua评估量表），根据评估分值判断患者是否需要进行非手术患者出血评估

需支持医生对产科患者进行评估（特异性产前Padua评估量表，特异性产后Caprini评估量表），根据评估分值判断患者是否需要进行响应出血评估

需支持医生对妇科患者进行评估（特异性Caprini评估量表），根据评估分值判断患者是否需要进行响应出血评估

需支持医生进行Caprini评分的中、高危患者必须进行手术患者出血评估

需支持医生进行Padua评分的中、高危患者必须进行非手术患者出血评估

需支持医生对肿瘤科患者进行评估(Khorana)、根据评估分值判断是否需要进行出血风险评估

需对患者入院24小时，转科，术前术后以及出院等时机提示Caprini、Padua量表。

3-2

VTE量表智能评估

需自动扫描在院患者病历，进行风险评估、出血评估、临床可能性评估。根据自然语言处理技术以及内置的规则演算方法，自动对VTE量表中的选项内容进行智能填充，同时自动计算评分结果并显示。

需支持评估条目和分值一对一显示

需支持智能填充部分，通过颜色块高光显示以便区分

需支持随时查询评估条目可溯源的评估依据

需支持评估依据来源包括患者病史信息、检查报告、检验报告等

3-3

VTE智能预警提醒

结合医院VTE的监管需求，需支持医院根据自身业务流程，合理设置风险评估、出血评估、临床可能性评估的患者在院风险评估结果的提醒方式，提醒强度需区分三级，以监测医生在患者住院期间病情变化的关键节点是否及时完成相关评估。

需支持提醒强度区分三级：1级仅提醒、2级弹出框主动展示提醒医生关注、3级弹出框主动展示提醒

医生开立预防医嘱时，根据患者病情，需自动校验预防措施合理性，判断不合理或需要完成相关检查、检验结果，智能提醒医生

3-4

机器学习与深度学习

需利用医学领域语料标注和深度学习模型，构建临床医疗术语的数据模型，支撑病历文书和检查报告的自然语言处理。

3-5

自然语言处理

需采用自然语言处理技术对病历和影像报告进行知识挖掘和后结构化，进而提取VTE评定所需的关键变量，需支持VTE智能评定。

3-6

VTE知识图谱

需基于知识图谱构建一种的自动规则抽取组件，该组件可以将非标准化的提及属性描述转化为标准化的实体属性描述，更加准确地支持VTE智能评定。

4

VTE量表评估

需基于内置的VTE风险评估流程相关量表，辅助医护人员对患者进行风险评估，提供多维评估结果视图，便于医护全方位了解患者当前病情，为患者制定更合理有效的治疗方案提供支持。

4-1

VTE量表评估工具

需覆盖VTE风险评估流程相关量表，全部评估项累积达160+，统一院内VTE评估标准，辅助医护人员进行风险评估，有效提升评估覆盖度。

需支持手术VTE风险评估（Caprini）

需支持非手术VTE风险评估（Padua）

需支持妇科VTE风险评估

需支持围产期VTE风险评估（产前）

需支持围产期VTE风险评估（产后）

需支持手术出血评估

需支持非手术出血评估

需支持DVT可能性评估

需支持PE可能性评估

4-2

VTE量表评估结果

需自动完成在院患者病历的风险评估、出血评估、临床可能性评估。在患者列表中展示评估结果及对应的风险等级。同时，主动提醒医生及时完成VTE量表评估结果确认。

需支持确认VTE量表自动评估结果后，提醒自动消失。

需支持评估项目、评估结果、风险等级回填至病历对应位置，提升医生书写病历效率。

4-3

VTE量表人机对照

需对量表的评估结果，实现人机VTE评估结果在同一界面显示，便于医生进行对比分析。在医生进行人机对照的过程中，可随时一键查询评估项目的评估依据，实现评估有源头，结果可溯源。

需支持人工修改功能，记录人工评分和机器评分，方便进行对比分析

需支持快捷查询评估依据，如病历文书、检查报告、检验报告

4-4

VTE量表评估总览

需以患者为中心，集中展示VTE量表评估结果，需以折线图的方式展示变化趋势，方便医生查历史变化趋势，全面了解患者病情变化情况。

需支持集中显示患者做过的可量化的各项评定结果

需支持以不同量表为单位展示其发展变化趋势

需支持快捷患者在做过的所有评估的详细报告

5

VTE辅助决策

需基于系统内置的规则算法，主动、智能推荐疾病的预防、治疗方案，推荐内容支持以医嘱的方式开立至医嘱界面。

5-1

VTE疾病方案推荐

需对不同的VTE评估结果，结合患者在院情况，主动、智能提醒疾病的预防方案或治疗方案。方案中，需要开立医嘱的部分，以医嘱组套的方式提供给医生，实现直接将医嘱开立至医嘱界面。

需支持根据内置的规则算法，主动、智能提醒医务人员进行相应的基础预防、物理预防、药物预防、联合预防等措施。

需支持推荐医嘱以组套的方式展示，提供已开立医嘱和未开立医嘱用不同颜色底色区分的功能，方便医生快速了解自己需要的医嘱。

需支持根据医院需求，自定义设置为强制的预防措施，有效尽早给予患者预防措施。

6

VTE质控管理

面向全院病例，需对终末病例进行相关终末指标的统计，需支持医务部门导出VTE的报表，同时提供支持院内病例查询功能，实现VTE精细化管理，为科室建设提供参考。

6-1

VTE相关指标统计

需针对终末病例进行相关终末指标的统计，主要包括风险评估、预防类、诊断类、治疗类、结局类、成本类指标。协助管理者由上至下精准管理，降低VTE的发生率和病死率。

需支持风险评估指标统计：包括VTE风险评估比率、出血风险评估比率。按照患者初始评估、术前及术后评估、出院前评估等不同节点，统计患者例数以及评估率，包含院内使用的所有评估表。

需支持预防类指标统计：采取VTE预防措施比率、VTE合理预防措施实施比率。按照院内各科室中危患者例数、药物预防例数、机械预防例数、药物联合机械预防例数统计预防类指标。

需支持诊断类指标统计：实施D-2聚体检查比率、实施静脉超声检查比率、实施肺动脉造影比率。按照院内各科室完成D-2聚体、静脉超声、肺动脉造影检查的患者例数及明细统计。

需支持治疗类指标统计：VTE患者实施抗凝治疗比率、VTE患者实施溶栓治疗比率。

需支持结局类指标统计：VTE发生率、VTE病死率。按照院内各科室PE、DVT、PE合并DVT患者发生数量、发病率统计。

需支持成本类指标统计：平均住院费用、平均住院天数。

6-2

VTE防治报表上报

需支持医务部门可以按照国家政策规定要求，以周、月、年等不同的时间粒度导出VTE的报表，同时基于数据进行统计分析和趋势分析，将反馈给各级管理者，实现VTE精细化管理。

需支持生成查询国家上报数据统计表格，包含任意时间段出院患者数、出院患者例数、出院患者初始VTE风险评估例数、接受VTE风险评估的住院患者例数。

需支持生成查询国家上报数据统计表格，包含任意时间段VTE风险为中/高危的患者例数、接受出血风险评估的住院患者例数、出血风险为高危的患者例数。

需支持生成查询国家上报数据统计表格，包含任意时间段预防措施实施例数、药物预防实施例数、机械预防实施例数。

需支持生成查询国家上报数据统计表格，包含任意时间段住院手术人次数、手术患者住院期间新发DVT例数、新发PE例数、新发DVT合并PE例数、新发DVT例数、新发PE例数、新发DVT合并PE例数。

需支持生成查询国家上报数据统计表格，包含任意时间段诊断为医院相关性VTE住院患者例数、肺栓塞住院患者死亡例数、VTE住院患者死亡例数。

6-3

VTE院内病例查询

需对院内病例的进行全面统计，在VTE评估、预警、确诊、预防、治疗等各个环节，系统按照科室分布、出院日期、VTE评估分层等维度，汇总患者明细，相关人员可定期审核。

需支持按时间段查询院内各科室VTE患者明细，包含患者信息、主管医师、量表评估结果、预防医嘱、治疗医嘱、检查情况等。

需支持按时间段查询院内各科室VTE死亡患者明细，包含患者信息、主管医师、量表评估结果、预防医嘱、治疗医嘱、检查情况等。

需支持按时间段查询院内各科室已实施预防措施后仍发生DVT、PE、DVT合并PE的患者明细，包含患者信息、主管医师、量表评估结果、预防医嘱、治疗医嘱、检查情况等。

需支持按时间段、患者评估结果查询院内各科室的中高危和确诊患者明细，包含患者信息、检查检验(D-2聚体、静脉超声、肺动脉造影)、治疗医嘱（溶栓药物、抗凝药物、滤器植入）。

7

临床一体化集成

VTE业务应用场景需与HIS、医生站、医嘱等系统深度集成，面向住院患者诊疗过程中的VTE 评估、预防、诊断、治疗和质控等核心环节，实现 VTE 防治的“全场景智能化的闭环管理”。

7-1

预防、治疗方案

需与HIS系统深度集成，在医生开立医嘱时，以弹窗形式针对患者有效特定的评估、预防、治疗方案提醒，用于辅助医生开展诊疗工作。

7-2

医生站集成

需与医生站深度集成，支持医院根据自身业务需求设置VTE质控标识，在医生站的患者列表界面内，对高危患者自动标识，提示医生重点关注这些患者，方便临床进行排查，减少漏诊。

7-3

护士站集成

需支持与护士站集成，实现护士端的预警与决策提醒。

7-4

系统数据集成

需支持医院的电子病历和互联互通评级要求，通过与医院集成平台，医生站和护士站对接，实现数据层面的集成，提供质控指标及临床数据供医院进行VTE的辅助决策、预警提醒。

序号

功能名称

技术和性能参数需求

1

路径配置管理功能

1-1

路径显示状态配置管理

需要支持对路径中各种项目状态颜色配置。需要支持对路径模板中各个阶段按不用颜色进行配置，便于医生直接观看。

1-2

路径执行流程配置

需要支持对关键节点功能的开放与关闭的配置。

1-3

系统操作权限配置

需要支持角色权限设置。不同角色有不同的能力。

1-4

系统关键数据配置

需要支持ICD诊断码与病种对照，一条路径可以匹配多条诊断。需要支持病种专业与实际科室对照。需要支持变异来源、变异原因、变异原因明细维护。

2

路径模板管理

2-1

模板创建

需要支持新建模版、模版基本信息维护、准入评估标准录入、准出评估标准录入、入径标准维护。

2-2

模板编辑

需要支持所见即所得的模版编辑模式。

需要支持路径模板自动对应所属病种专业。模板涵盖临床路径所包含的所有项目，如诊疗工作、医嘱、护理项目、标准住院天数以及住院费用。需要支持患者路径维护。

需要支持康复、心理项目维护。需要支持长、短期医嘱各种明细属性设置，所见即所得。

需要支持护理项目明细属性设置，所见即所得。

需要支持医嘱明细直接调取医嘱组套进行对照维护。模板内医嘱顺序所见即所得，执行过程按顺序显示。模版医嘱支持排序操作，可直接决定生成医嘱的顺序。

需要支持路径项目自定义设置为必选项或可选项。

需要支持模版多治疗阶段，每个治疗阶段可设置天数。路径模板维护时，同阶段可以维护分支备选阶段。

需要支持判断模版天数是否超过维护的最大天数。

需要支持急诊转住院模式模版维护。

需要支持模版“重做”功能。可以重做整个模版，以及重做长嘱，临嘱，诊疗，护理，患者，心理治疗，康复治疗、医嘱明细项目。模版编辑时，支持显示医嘱明细。

需要支持详细模式按钮展示详细模式。

需要支持路径项目整体拷贝、剪切、粘贴功能。

需要支持医嘱细项拷贝、粘贴功能。

需要支持导出Excel功能。

需要支持导出XML功能。

需要支持模版作废功能。

医嘱对应时，需要支持批量删除具体医嘱。

需要提供路径校验功能，校验医嘱项目与ICD诊断。

需要支持模版暂存功能。

需要支持模版提交功能。

需要支持等效药维护功能。

需要支持阶段合并功能。

需要提供阶段精简模式。

需要支持阶段评估维护。

需要支持模板打印。

需要支持使用其他模板覆盖当前模板功能。

需要入径标准。

2-3

模版审核

需要支持模版的审核需要单独的审核权限，未经审核模版，无法应用于患者。

需要支持模版审核驳回。

需要支持模版状态查询。

需要支持模板编辑痕迹监察。审核精度到每个数据，方便模板修改者和审核者快速定位不通过的数据。

2-4

版本管理

需要支持对路径模版进行管理。

需要支持模版维护后按版本管理，确保版本修正后不影响之前的路径患者。

需要支持A、B、C模版版本管理，即相同病种存在不同治疗方案的模版，且支持不同治疗方案的各个模版单独升级版本。

需要支持模板维护时修改版本名称。

2-5

权限管理

需要支持模板管理授权功能。

需要支持模版多级管理机制。

需要支持权限细分功能，同一角色可以具备不同权限。

2-6

医嘱项目维护

需要支持医嘱组合。

需要支持溶媒维护。自动与HIS医嘱项目进行对照，医嘱字典无需人工建立。

需要支持批量替换所有路径模版中的指定医嘱项目。

需要支持模糊匹配组合维护，需要支持从医嘱组套中维护，需要支持从（在院或出院）患者医嘱中维护，需要支持描述类医嘱维护关键词功能，并通过关键词进行匹配医嘱。

2-7

路径校验

需要支持规则的校验，未通过的医嘱项目支持按不同颜色标出。

ICD校验，以下两规则校验未通过的ICD会通过进行提示。

2-8

变异分析

需要支持定位每个元素的变异数量。以图表形式显示具体变异医嘱和变异原因。需要根据变异内容快捷改进模板。

2-9

模板复用

需要支持模板具备整体复制功能。模板需要支持以XML形式导出、导入。需要支持模版批量导入、导出。

需要提供1000张及以上卫生部标准模版。

3

路径执行

3-1

路径门户

需要支持根据患者诊断ICD10编码自动过滤出适合路径供医生选择。医生可根据情况，自主选择本科室内对应的路径。需要支持准入评估项目，如果该项目为必须符合的项目，则系统应该支持记录下不符合准入评估的标准后并自动退出；如果该项目为非必须符合的项目，则系统在记录下该项目后，继续登记路径操作。需要支持不入路径审核机制，避免医生无理由不使用路径。需要支持入径标准，为医生提供标准化的入径准则。

3-2

过程管理

需要支持任意阶段执行情况、显示完整的路径执行情况。

需要支持任务列表显示，提示未完成工作。

需要支持直接进入下一阶段，自由选择路径过程。

需要支持延长、缩短治疗阶段。

需要支持中途退出功能及对中途退出路径的权限以及流程进行控制。

需要支持中途治愈功能。

需要支持中途退出审核机制。

需要支持更改路径的执行日期。

需要支持自动对照长期医嘱执行天数。

需要支持医嘱闭环操作。

需要支持一键开立当日路径医嘱。

需要支持控制医嘱开立、停止、变更。

需要支持自定义路径变异标准，包括（非路径医嘱规定金额上限变异、必选项未执行变异、非路径医嘱是否填写变异信息、延长或缩短阶段是否填写变异、整体费用超过路径规定费用标准是否变异、执行天数超过路径规定的最大天数是否变异、非路径医嘱数量和超过设置数量是否变异），根据标准自动判断完成情况。需要支持变异项目按照自定义颜色进行显示。

需要支持路径显示医嘱明细和医嘱执行状态。

需要支持批量执行诊疗、护理项目。支持模版打印。

需要支持完成护理、诊疗、患者、心理、康复项目时后台记录操作人姓名。

需要支持按照频次、用法、用量完全匹配。

需要支持路径执行中添加医嘱细项。

需要支持在不维护医嘱细项情况下，同时执行当天的多个元素。

需要支持患者费用预估，提前预估整体费用，避免超标。

需要支持路径使用时，可以移动医嘱元素，使用中可以移动医嘱项目到任何阶段日。

需要支持当天可跳转多个阶段，手术日不固定情况适用。

需要支持显示阶段医嘱执行明细

需要支持药品医嘱按名称匹配

3-3

变异录入

需要支持变异原因直接录入与显示。需要支持批量录入医嘱变异信息。

需要支持非路径医嘱录入时选择归属项目，为变异分析改进模板质量提供支持。需要支持阶段变异录入及删除。

3-4

关联医嘱

需要支持对医嘱进行匹配。支持双向医嘱执行。支持作废医嘱提示替换药品开立功能。临时医嘱添加复查功能。

3-5

关联病历

需要支持自动关联病历系统，双向互动。

3-6

等效药

需要支持开立医嘱时，自动匹配等效药。

3-7

监控提醒

需要支持费用超标提醒。需要支持执行天数超标提醒。

3-8

退出路径医嘱

需要开立退出路径医嘱，则提示退出路径。

3-9

分支路径

路径模板使用时，需要支持根据患者病情情况选择分支阶段

3-10

变更路径

模版使用时，需要支持变更路径使用。

3-11

阶段评估

填写阶段评估内容，如果有评估项目未通过，则不能进入下阶段。

3-12

准出评估

填写准出评估内容，如果不符合出径标准，系统会自动记录不符合项目

3-13

告知单打印

需要支持与国家标准路径表单格式相同的告知单打印。

需要支持按照天进行打印

4

路径质量控制

4-1

可定制化评分规则

需要支持根据医院实际情况，自定义评分规则。

4-2

采用多级评分机制对路径中的各个操作项目进行评估

需要支持根据维护的评分规则，对医生进行路径使用情况质量监控。

生成医生综合评分表，医生单病种得分表，医生分管患者得分明细表。

5

统计分析

5-1

路径执行情况总览

需要支持统一路径平均费用、路径执行情况分析、平均住院日及变异原因的指标图形展示。

5-2

整体指标分析

需要支持整体横向指标，统一汇总各科室路径的执行情况。

5-3

路径执行趋势分析

需要支持分析路径中的关键数字，各科室横向对比。关键数字结果通过图形对比。

5-4

路径明细追溯

需要支持统计分析结果，可追溯到个人。

5-5

国家统计表单

需要支持国家上报数据所需要各种表单。

序号

功能名称

技术和性能参数需求

1

评级指导

为了保障评级工作有序及规范的开展，需结合评级标准及过程的理解、评级优秀项目案例的建设经验，为评级项目提供评级整体的指导工作，包括提供评级启动培训，差异分析及建设方案，评审过程指导，申报、文审、现场查验环节提交的证明材料审核，现场定量准备指导，现场定性准备指导。

2

代码审计

需结合院方需求，配合完成系统代码审计工作。