XX医院移动端电子签名项目技术规格及其它要求

合集下载

XX医院医技护患电子签名数字认证项目建设意见

XX医院医技护患电子签名数字认证项目建设意见

XX医院医技护患电子签名数字认证项目建设意见一、项目建设目标为实现全院无纸化的目标,保障我院电子病历系统、H1S系统、11S系统、PACS系统的业务信息安全,实现电子病历合法化,目前需依据《卫生系统电子认证服务管理办法(试行)》、《医疗机构病历管理规定(2013年版)》及相关标准规范要求,建立全院统一的电子认证云服务体系、患者签名体系,保证电子病历的真实可信和合法有效性。

项目建设目标有:D建立全院统一的医院工作电子认证云服务体系,面向我院工作人员,统一数字证书发放与管理,提供优质的、符合卫生行业规范的数字证书生命周期服务,满足医院的实际需要。

2)建立全院统一的患者签名体系,使用合理的、实用的患者及家属知情同意书无纸化电子签名解决方案,实现具有法律效力的患者及家属电子签名。

二、项目建设内容和要求2.1电子认证云服务体系建设要求根据我院的具体需求实现医院内的电子认证云服务体系建设,为医院中涉及医疗及相关信息系统解决行为人的身份凭证、电子签名及凭证认证问题。

具体满足以下要求:1)提供移动端数字证书服务,包括但不限于手机证书申请、下载,方便医院用户获取证书服务。

2)提供证书快速应急服务,满足医院对业务连续性的要求。

3)支持按照医院实际应用需要,灵活定制服务交付的业务流程。

4)支持手机(Ar1droid、IoS)的证书存储介质,满足医院对一证多用的特殊需求。

5)提供完善的医院工作人员电子签名模式:涵盖临床业务及相关系统中即时签名、批量签名、拒绝签名、作废签名等多种场景。

实现医疗等多种数据的PC端和移动端的分级确认和分级签批。

6)提供电子认证服务高可用机制,包括:断网业务连续性服务机制;远程接入和测试服务流程;服务监控。

7)提供预签名机制使电子签名与临床诊疗工作异步进行,支持医生不带手机时签名解决方案。

2.2 电子知情同意书可信化建设要求根据我院对知情同意书电子化的需求,设计行之有效的解决方案,保障知情同意书在实现电子化后的合法可信。

XX医院急救管理系统项目建设技术需求

XX医院急救管理系统项目建设技术需求

XX医院急救管理系统项目建设技术需求一、软件平台要求1)技术结构:采用前端、应用服务层及数据服务层的三层架构,支持在局域网运行医院信息系统。

2)操作系统:数据库层与应用服务层为WINDOWS SERVER 2012及以上/LINUX;客户端为WINDOWS XP、WINDOWS7、WINDOWS8、WINDOWS10等多种版本的主流操作系统;移动端采用安卓操作系统。

3)数据库软件:采用大型关系型数据库,如MS SQL SERVER2012及以上数据库或Oracle 11g数据库等。

二、系统设计原则(一)先进性本项目所采用的技术需要适度超前,选择具有技术领先优势,又有成功案例的技术方案,以保证建成项目使用周期长,性能指标高,在一定时期内具有技术上的先进性。

在应用系统的设计上,借鉴医院以往各类信息化项目的经验与教训,同时注重参考行业最佳实践;在技术上,采用行业上领先且成熟的技术,使得设计更加合理、更为先进。

充分考虑现阶段医院信息化的特点,在注重系统实用性的前提下,尽可能采用先进的计算机软、硬件环境;在软件的开发思想上,严格按照软件工程的标准和最新的面向服务(SOA)的理念进行设计,保证系统的先进性。

(二)成熟性本项目需要采用被实践证明为成熟和实用的技术和设备,纳入医院整体临床业务策略加以规划利用,满足医院当前和今后一段时间的临床业务需求;确保性能稳定,界面直观,具有易理解、易调试、易维护、易扩展、易复用的特点,最大限度地满足医院当前临床业务以及未来发展的需要,确保耐久实用。

(三)开放性系统采用开放性设计,在数据通信协议、数据标准、数据库系统、应用界面开发、接口设计等方面采用开放性设计,支持XML、SOAP、WebService、LDAP 等当前受到普遍支持的开放标准,这样一方面保证系统能够与其他平台的应用系统、数据库等相互交换数据并进行应用级的互操作和互连性,另一方面也便于将来改造、扩容和升级。

系统应能方便地扩展,可随着业务需求的变化而扩充;系统的配置也能相应地改变和延展,已实现业务上需要的新功能。

XX医院清廉医院信息平台建设意见

XX医院清廉医院信息平台建设意见

XX医院清廉医院信息平台建设意见一、总体要求1.1建设背景略。

1.2项目需求依托医院信息化建设情况,以及现阶段移动互联网技术、企业微信、阿里钉钉等互联网生态平台技术现状,重点对医院纪律建设体系,清廉教育建设体系,权力监督体系,权力运行公开透明机制建设体系,社会监督体系,职工满意度管理体系,医职人员医德医风建设体系等业务信息化建设的意义及方法进行了相应的阐述。

旨在通过信息化手段促进院内党风廉政建设和行风建设各项长效制度成熟稳定,医院采购和医疗服务中的不正之风得到有效治理,医疗服务行为规范有序,权力运行阳光高效,医院干部职工拒腐防变的思想和制度防线筑牢稳固,不敢腐、不能腐、不想腐的长效机制健全完善,用信息技术助力医院建设党风清正、院风清朗、医风清新的清廉医院。

清廉医院建设是医院建设与管理的重要内容,也是医院建设中的一项系统工程。

医院清廉文化是医院文化的组成部分,以清廉为思想内涵、以文化为表现形式,是清廉医院建设与文化建设相结合的产物。

它包括仁爱救人、赤诚济世的事业准则;清正廉明、不图钱财的道德品质;谨慎认真、不畏艰辛的医疗态度;不畏权势、忠于医业的献身精神;博采众长、严谨治学的优良学风;端庄宽和、平易近人的行医风格,其核心就是全心全意为人民服务,对医院发展和建设具有十分重要的意义。

二、建设内容2.1采购清单本次项目建设计划建设的XX医院清廉医院监管服务系统讲覆盖全员所有相关业务科室日常开展的数据流程和业务流程,建立一个平台+N个业务监管模式。

2.2总体目标基于现代医院管理制度的清廉医院建设各项长效制度成熟定型,医药购销领域和医疗服务中的不正之风治理,医疗服务行为规范有序,公权力运行阳光高效,医院干部职工拒腐防变的思想防线和制度防线筑牢稳固,不敢腐、不能腐、不想腐的体制机制健全完善,清廉文化深入人心,医院整体廉洁程度显著提升,逐步全面建成清廉医院建设工作。

(1)有效提高医院职工自我监督意识。

党风廉政和清廉行风建设信息平台的建设,让医院的各种权力公开透明,阳光运行,通过廉洁宣传警示教育,从思想上加以自我监督,逐步形成党风廉政和清廉行风建设管理长效机制。

XX市XX县公立医院运营管理项目需求说明

XX市XX县公立医院运营管理项目需求说明

XX市XX县公立医院运营管理项目需求说明一、主要建设内容本项目建设内容为XX市XX县公立医院运营管理系统,主要有智能报销管理、全面预算管理、成本管理、资金管理、绩效管理、综合运营分析及区域电子认证等功能。

本项目建设范围覆盖XX县卫生健康局、XX县人民医院健共体、XX县中医院健共体、XX县第三人民医院健共体、XX县妇幼保健院。

其中,智能报销管理包括日常报销申请与审批、报销统计与分析、支持报销的移动端应用;全面预算管理包括基础设置、预算项目库、预算论证、预算任务、预算编制、预算调整、预算号管理、预算控制、预算执行分析、预算考核、权限管理;成本管理包括数据集成管理、科室成本管理、医疗服务项目成本管理;资金管理包括对账平台、现金管理、银医直联;绩效管理包括基础业务数据集成平台、绩效考核全流程管理体系、绩效考核结果管理应用;综合运营分析包括预算分析主题、综合经济运营分析主题;区域电子认证包括XX卫生监管平台、移动电子签名管理系统、移动电子签名SDK软件、微信/企业微信电子签名小程序/钉钉、时间戳服务系统、电子签名前置交换系统、患者手写签名系统、签名屏APP软件及授权服务采购等。

二、系统产品功能要求1、基础平台用于搭建医院信息系统的基础架构和基本信息。

具体包括如下的功能:1.1组织架构管理满足医院现在的多院区组织架构,以及未来不断机构扩展,以及组织管理关系变化的需求:(1)支持组织分级管理,以及虚拟管理组织,各层级组织数据相互独立,且能按照不同的层级汇总;(2)支持组织的增减变化,级次变更,形成版本化管理;(3)具备多组织模型,实现财务组织、预算组织、成本组织、资金组织、人力组织等体系管理。

(4)支持区别于法人组织的多专业管理领域的组织管理,按照业务领域形成多个组织层级管理,支持矩阵式业务管理。

1.2基础字典管理动态主数据建模,提供对基础数据、参数的统一管理对基础数据和业务参数进行统一管理,支持多业态多组织医疗机构基础数据的三级管控,管控模式(管理方式+可用性范围+唯一性范围)可配置。

医院电子签名系统技术方案

医院电子签名系统技术方案

3.1.2 系统紧急情况及应急处理流程
3.1.2.1 系统紧急情况
按照故障对业务影响程度将故障等级分三级:
一级故障:系统宕机或者数据丢失,以及其它对客户的业务运行有重大影响
的事件;
二级故障:系统的操作性能严重降低,或者系统不稳定,对客户的应用有重
要潜在影响的事件;
三级故障:系统操作正常,客户的业务运作不受影响,但所存在问题,如果
长期医嘱 401746 33479
1101 3273249
18
3.1、医院数字签名系统应急方案:
截止到2016年3月9日电子病历数量统计
序号 1 2 3 4
统计类型 年统计量 月统计量 日平均量 总量统计
电子病历 15050 1260 41 37651
19
3.1、医院数字签名系统应急方案:
3.1.1 方案概述 医院数字签名系统已经进入运行阶段。为防止意外情况下可能出现的系统运
在数据签名的用户,插入CA 证书后登录电子病历客户端,登录成功后进 去“人员管理”角色的画不下,选择左下角的“CA 证书管理”的页面,如图 3.2.1 所示:
图2.2.1.1 人员管理 界面
进入“CA 证书管理”界面后,选择当前KEY 的用户,进行CA 注册, 此处要保证当前KEY 用户的用户名和当前选择的电子病历的用户姓名一致, 否则读取KEY 信息失败。如下图2.2.2 所示:
HIS系统配置更改图
电子病历注销数字签名绑定
3.2、医院数字签名系统常见问题解决方法:
1、Q:HIS系统和电子病历无法读取UKEY物理介质。 A:检查UKEY指示灯是否点亮,红灯亮表示UKEY正常工作然后检查证书
助手是否正确安装。UKEY灯不亮初步判断为UKEY损坏,可按流程进行补办。 2、Q:HIS系统无法使用UKEY登录。

病历电子签名规范制度模板

病历电子签名规范制度模板

病历电子签名规范制度模板第一章总则第一条为了规范病历电子签名行为,保障医疗质量和医疗安全,根据《中华人民共和国执业医师法》、《医疗机构管理条例》、《医疗事故处理条例》、《电子签名法》等法律法规,制定本规范。

第二条本规范适用于在我国境内依法取得执业资格的医疗机构、医务人员和病历电子签名服务提供者。

第三条病历电子签名应当遵循合法、合规、真实、完整、安全的原则。

第四条医疗机构应当建立健全病历电子签名管理制度,明确病历电子签名的责任人、流程、技术要求和监督管理措施。

第二章病历电子签名第五条病历电子签名是指医务人员在医疗活动中,使用电子签名工具对病历内容进行签名。

第六条医务人员应当在使用病历电子签名前,进行身份认证和授权。

第七条病历电子签名应当具备以下要素:(一)医务人员的姓名或者工号;(二)签名时间;(三)签名者的身份信息;(四)签名者的签名图像。

第八条病历电子签名应当符合以下要求:(一)签名图像应当清晰、可辨认;(二)签名时间应当准确、真实;(三)签名者的身份信息应当真实、有效;(四)签名过程应当有记录,记录应当保存至少三年。

第九条医务人员应当在病历中明确标识签名内容,确保签名内容真实、完整、准确。

第十条病历电子签名不得用于非法目的,不得侵犯他人合法权益。

第三章病历电子签名服务提供者第十一条病历电子签名服务提供者应当具备以下条件:(一)具有合法经营资格;(二)具有病历电子签名技术和服务能力;(三)具有安全、可靠、高效的病历电子签名系统;(四)具有完善的个人信息保护措施和保密制度。

第十二条病历电子签名服务提供者应当向医疗机构提供安全、可靠、高效的病历电子签名服务,并保障医务人员和患者的合法权益。

第十三条病历电子签名服务提供者应当对医务人员和患者的身份信息进行严格保密,不得泄露、出售或者非法使用。

第四章监督管理第十四条医疗机构应当加强对病历电子签名的管理,定期进行自查,确保病历电子签名的合法、合规、真实、完整、安全。

厦门第三医院数字证书系统

厦门第三医院数字证书系统

厦门市第三医院数字证书系统招标内容及要求一、招标项目项目名称:厦门市第三医院数字证书系统二、招标货物一览表三、供应商的资格要求(一)投标人必须是在中华人民共和国国家、省、市工商行政管理局注册的信息技术类企业公司,具有软件开发经营范围的企业法人(提供企业法人营业执照、税务登记证复印件,加盖单位公章,原件备查).(二)投标人应具有完善的售后服务机构和售后服务体系。

福建省以外的投标人,在福建应有能够提供售后服务的分公司及核心开发人员,能提供本地化技术服务,投标人需提供相应的证明材料.(三)数字证书系统的资质要求:a)投标人须提供所投产品具备电子签名服务系统产品软件著作权(四)投标人投标人资质要求a)投标产品制造商须是卫生部许可的卫生系统电子认证服务机构,具备电子认证服务许可证;b)投标人须提供所投产品的制造商授权书,投标文件正本须提供原件;四、综合评标法五、招标项目技术要求(一)项目简介目前厦门市第三医院已经建设了EMR系统、LIS系统、PACS系统、HIS临床业务系统以及移动OA、绩效工资查询APP、移动护理管理、掌上医院等多个移动应用系统。

作为医院的信息服务平台,现有院内系统承担着实现医院管理及服务职能、对内实现跨部门分工协作、信息资源共享等重要职能,因此,医院信息系统安全保障系统的建设尤为重要,特别是移动端的安全认证,将直接影响到网上办公,故本次项目拟引进无硬件U—key 的云电子签名解决方案。

本方案将依托厦门市第三医院信息系统,引入云数字签名基础设施,搭建医院移动信息化应用安全基础平台,从可信身份、可信行为、可信数据为医院信息化提供整体应用安全保障.(二)项目建设目标为提升医院所有人员工作效率,保障我院移动应用系统及电子病历系统、医学影像系统、实验室系统的业务信息安全,需依据《卫生系统电子认证服务管理办法(试行)》及相关标准规范要求,建立全院统一的云电子认证服务体系和业务应用安全支撑体系,实现“可信身份、可信数据、可信行为、可信时间”的目标,保证院内系统的真实可信和合法有效性.项目建设目标有:1)建立我院统一的云电子认证服务体系,面向我院医护工作人员,统一数字证书发放与管理,提供优质的、符合卫生行业规范的数字证书生命周期服务,满足医院的实际需要。

XXX医院电子签名解决方案

XXX医院电子签名解决方案

电子签名助推医院无纸化——XX医院电子签名解决方案XXXXX有限公司2018年04月目录1项目背景 (1)2现状及问题 (1)3电子签名认证需求分析 (2)4电子签名认证的必要性分析 (5)4.1电子认证服务是保障电子病历信息安全的基础 (5)4.2电子认证服务是满足法律需求的基础服务 (6)4.3选择合法的电子认证服务提供商 (7)5总体架构设计 (8)5.1设计思路 (8)5.2设计依据 (9)5.3总体架构 (10)6数字证书服务 (12)6.1证书申请(初次批量申请) (12)6.2证书申请(日常零散申请) (13)6.3证书产品及介质 (15)6.4证书更新服务 (16)7CA认证产品集成实施方案 (17)7.1CA认证产品 (17)7.1.1数字签名验证服务器 (17)7.1.2时间戳服务器 (18)7.1.3电子签章系统 (19)7.1.4移动证书中间件................................................................ 错误!未定义书签。

7.1.5信手书手写签名服务器 (20)7.2安全登录认证集成 (24)7.3医护人员数字签名和验证 (26)7.4电子病历可信时间戳 (27)7.5电子病历电子签章 (28)7.6患者知情同意电子签名 (29)7.7护士PDA移动签名解决方案 .................................................... 错误!未定义书签。

7.7.1移动PDA应用电子签名实现 ........................................... 错误!未定义书签。

7.7.2移动查房电子签名并形成可信电文................................ 错误!未定义书签。

8产品清单 . (31)1 项目背景为加强医疗机构电子病历管理和临床使用,促进医疗机构信息化,2010年2月22日,卫生部印发了《电子病历基本规范(试行)》的通知,并于4月1日开始实施。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
XX医院移动端电子签名项目技术规格及其它要求
序号
服务条款及其它要求
1
总体要求
1.1
系统部署一套电子签名系统需同时提供签名验签、时间戳、手写板签名、移动端签名、电子认证等服务以支持医院全场景签署需求。
2
服务要求及配置
2.1
技术规范
2.1.1
系统支持公有云、混合云、私有云等部署模式,满足用户多样化的部署需求。支持本地化部署或在医院指定的云服务上部署。
2.5.13
印章展现,要求印章透明,不遮挡下方的文字或图片。
2.5.14
签署页提交签署时显示倒计时,且倒计时可配置。
2.5.15
允许以CSR的方式生成证书请求,并导入第三方CA签发的服务器证书。
2.5.16
支持直接导入CER格式数字证书。
2.5.17
支持以接口方式,由第三方软件传入用户信息,实时连接第三方CA生成数字证书。
2.9.4
支持多种方式的告警功能,包括钉钉,邮件,短信等方式。
2.9.5
支持管理员及权限配置。
2.10
存证与法律服务
2.10.1
投标人应具备提供电子签名合法性的举证能力,应提供公证处、具有资质的司法鉴定中心合作证明材料。
2.10.2
支持司法区块链存证,支持对签约全流程证据数据进行实时上链,并能出具区块链全流程存证的证据报告,提供报告样例。
2.3
CA证书服务
2.3.1
支持U盾数字证书、云端数字证书;支持事件型数字证书。数字证书产品厂家具有国家密码管理局《电子认证服务使用密码许可证》和工业和信息化部《电子认证服务许可证》证书。
2.3.2
支持机构/个人数字证书的申请、延期、吊销、变更等生命流程;数字证书申请记录全流程管理;
2.3.3
支持机构/个人ukey的申请、吊销等生命流程;ukey申请记录全流程管理。
2.8.13
支持断网应急机制,支持对断网情况下产生的签署文书进行回溯查看,在网络恢复后以实现对断网情况下待签署的文书自动进行重新签署。
2.8.14
支持用户变更手机号的功能,变更行为需进行实名认证。
2.8.15
系统支持应用级配置,各个业务系统的登录、认证、签署设置,可单个系统停用,也可批量停用。
2.8.16
2.4.2
支持一个印章设定多个监印员,一个监印员管理多个印章。
2.4.3
支持模板印章、自定义图片印章、特殊印章,提供多种不同样式的印章模板。
2.4.4
模板印章支持横向文、下弦文自定义设置,支持设置印章形状、颜色、大者手绘章并自由设置默认章。
2.5
医护签
2.5.1
2.8.6
系统接入管理:系统接入需进行鉴权登录,提供API接口,支持其他业务系统调用实现电子签名等功能。
2.8.7
配置管理:支持实名方式、意愿方式可配置;支持个人模板章颜色、形状、大小自主配置。以上配置支持医院维度、科室维度和个人维度的灵活搭配;
2.8.8
支持签名意愿认证有效时间根据用户要求进行配置;
2.5.4
支持通过手机+短信、人脸识别、密码、Ukey等多种方式来实现身份意愿认证。支持用户自主切换认证方式并在下次使用时默认上次认证方式,同时支持多种认证方式并存。
2.5.5
单页签署,以鼠标形式定位签名位置,控制签名只能盖在PDF文档显示区域。
2.5.6
多页签署,能够对指定的页码指定位置,以1,3-4,8表达形式实现。
文件签署支持个人模板章签署,手绘签署。
2.6.4
支持通过给患者发送短信进行远程签署
2.6.5
支持手写签署图片和指纹图片大小和颜色的自主配置。
2.6.6
支持患者身份信息自动获取,并自动对身份证和姓名进行二要素校验
2.6.7
支持患者通过手写板签署。支持手写签署、指纹签署组合配置。
2.6.8
患者手写板签署需要患者实名证书。
系统支持个人级配置,针对用户使用业务系统的登录、认证、签署进行设置。
2.9
系统监控
2.9.1
自动获取100多种性能指标,包括响应时间、资源利用率、CPU/内存等;
2.9.2
支持分布式网络的资源集中监控,具有监控面板,数据大盘等等可视化页面。
2.9.3
快速发现性能瓶颈,节省分析问题的时间。根本原因分析使用层次化结构形式展现,并且可以方便的在Web界面中查看。
3.2.5
要求中标单位在各阶段及时提供相应的项目管理文档、开发类文档及实施类文档,以便业主方及时了解项目进展情况。
3.2.6
对上述安排投标人应列出详细实施方案,包括但不限于项目管理计划、项目进度计划、项目验收计划、项目组织结构(人员姓名、经验、学历和在本项目中的职责分工等。
3.3
安装、测试及系统集成要求
支持通过APP、WEB、H5、钉钉、X政钉、微信小程序等应用端完成签署,提供每种方式的系统截图。
2.5.2
支持在钉钉上通过人脸识别进行身份认证,提供系统截图。
2.5.3
支持与钉钉的深度集成,与钉钉组织架构深度对接。依托基于钉钉组织架构的审批流程,实现审批、签名环节的身份认证与电子签署,使审批内容和签名合法有效。
2.8.12
分类管理:支持对签署内容进行医嘱、病历文书、检查报告、检验报告、护理文书进行分类管理和统计。通过全院、科室、个人维度,当天、7天、30天维度,签署类型维度进行分类统计和可视化展现。支持门诊、急诊、住院、体检等不同场景的分类统计。支持电子病历系统、护理系统、检验系统、检查系统等不同临床业务系统的分类统计。
参与此项目的技术人员必须具有承担过相同类型软件开发、系统集成的经验,能够与用户进行良好的沟通,掌握相关领域的相关基础知识,具备相关产品集成、应用和开发的能力。
3.2.4
中标单位在项目合同签订后,需组织相关实施人员在该项目招标需求的基础上进行深入调研,编制需求规格说明书。需求规格说明经采购人、中标单位确认后作为项目验收的依据。
2.6.9
通过可视化界面实现手写板对接院内各业务系统配置,以支持实时接收各业务系统推送的签署任务。
2.6.10
通过可视化界面实现手写板根据业务发生场景(发起人、发起科室),智能匹配相关手写板以接收签署任务。
2.7
授权认证
2.7.1
支持通过钉钉、支付宝扫码登录医院业务系统,提供系统截图
2.7.2
支持提供人脸识别、短信等可信验证方式确保用户本人操作;根据业务需要自行选择签署服务。
2.5.18
支持原文沙箱保护技术:支持利用服务器上的数字证书对摘要值做数字签名,完成后回传在本地与原文结合生成签名后文件,确保签署过程原文不出本地。
2.6
患者签
2.6.1
支持患者通过微信、支付宝扫码签署,提供系统截图。
2.6.2
文件签署支持单页签、多页签、批量签,支持关键字签、固定位置签。
2.6.3
2.1.5
电子文件应采用符合ISO标准的PDF格式的版式文件,电子签名符合PDF的PAdES数字签名标准,能够被任何PDF标准浏览器识别并验证,同时支持国产的OFD版式文件签名。
2.1.6
支持ubuntu操作系统部署。
2.1.7
支持多CA证书的数字认证。
2.1.8
提供CRL的证书有效性验证,CRL更新配置可自动定时进行、动态更新,不需要重新启动服务。
2.5.11
签名验证,可以批量验证签名的真实性、查看证书、查看签章时间、文档完整性;可在Adobe Reader中验证;提供接口进行本地的签名验签。
2.5.12
时间戳签发机构标准时间应来源于国家授时中心,支持标准的RFC 3161时间戳,支持对字符串数据的时间戳;签名时生成的时间戳可在Adobe Reader中验证。
2.1.9
提供备份恢复功能,保证系统瘫痪时的快速恢复。
2.1.10
提供日志记录,可以记录证书、签署、打印相关的日志记录,支持日志的统计审计。
2.1.11
支持双机、负载均衡、性能扩展。
2.2
实名认证服务
2.2.1
个人实名认证:支持个人银行四要素认证,运营商三要素认证,支付宝刷脸认证和微信视频认证、微信小程序刷脸认证,提供系统截图。
2.7.3
支持和医院现有单点登录系统集成,为单点登录系统提供刷脸等授权方式,增强业务系统登录认证安全级别。
2.8
后台管理
2.8.1
用户和组织机构管理:支持用户和组织机构的新增、修改、删除等,支持用户自助注册,支持组织机构与用户信息的批量导入,支持通过接口从其他系统导入并管理。
2.8.2
权限设置:支持设置系统角色,通过角色,将用户与具体的功能和系统内资源关联起来,完成授权设置;支持医院、科室、普通医生多级权限管理。
3.3.1
该项目涉及到多个系统的应用集成,各应用系统之间要求按统一的数据交换标准进行数据交换。需要高标准进行整体规划,确保系统的稳定性、安全性、灵活性和扩展性。
3.3.2
系统集成包括本项目涉及到的相关应用软件系统安装部署和调试以及与第三方系统的对接。具体要求如下:
2.5.7
骑缝章,能够实现类似传统骑缝章的功能。
2.5.8
手写签批,支持手写屏,实现真迹签批。支持智能手写笔迹识别,识别书写内容与系统要求书写的内容是否一致。
2.5.9
批量签署,能够批量对多个文件指定相同位置一次性签署。
2.5.10
关键字签章,能够指定关键字,在文档中该关键字出现的地方一次性加盖多个印章。
3.2.2
本项目实施阶段要求驻场,要求投标单位明确各阶段的人员驻场安排,项目经理要求在项目建设各阶段在现场开展相关工作,并保证一定的到场率;项目小组团队成员在各阶段至少安排两人进驻现场开展各项工作。并在验收后的质量保证期内专人(该工程师需全程参与过本项目建设)定期或不定期参加日常维护工作。
相关文档
最新文档