病理系统招标要求20170203.doc.doc

病理信息系统招标要求 产品技术要求 系统技术要求 系统成熟、稳定 ● 系统须保证“7天24小时”安全运行。 ● 产品成熟，并经过运行考验，最好有同等规模医院成功运行经验。 ● ★系统采用平台化设计，所有功能模块集成在同一平台下，一次登录可以操作所有权限内的所有功能模块，同一软件界面内所有功能模块以插件形式并列显示存在，避免不同软件模块单独程序的松散模式带来的维护与使用的不便。（提供平台软件界面截图证明） ● 保证各环节业务数据与统计报表数据准确。 ● 系统企业级大型数据库。 ● 运行平台应优先选择：UNIX、Windows。 ● 数据库应优先选择：Oracle， SQL Server 等大型关系型数据库。 ● 支持双机、集群工作模式。 系统安全 1）数据库的安全性 ● 数据库有完善备份功能。 ● 数据定期备份，并支持备份到独立的数据中心或磁带库，有备份记录。 ● 系统有完备的断点恢复功能。 ● 提供重要数据修改全程监控。 ● 对于重要数据，系统只能提供有痕迹的更正功能。 ● 提供错误日志。 ● ★系统具有直观全面的日志管理模块，对系统的运行进行全面的日志记录与管理，确保系统运行的安全性与可追溯性。（提供软件截图证明） 2）授权管理 ● 完善的用户权限管理与授权机制。 ● 不同权限进入不同层次、功能的菜单。 ● 系统提供操作权限管理工具，无需通过修改程序进行授权。 3）数据库登录用户权限管理 ● 提供不同权限的数据库用户和系统管理员登陆方式，保证系统安全。 应急系统 ● 对于全院各系统均需要有系统出问题后的应急方案与有效应急方法，不能影响医院的正常工作。 ● 当系统的主服务器或全院的网络出现异常时，有应急系统可以启动，提供网络和本地单机的切换方案，支持医院业务。（应急系统中的字典与主数据库的字典不一致性的时间差不超过24小时。） ● 切换到应急系统的时间不得超过5分钟。 ● 应急系统的启动要有特许，普通用户正常时不能启用。 ● 当系统恢复正常后，在应急系统中的数据可以迁移到主数据库中，保证数据的完整一致性 系统响应及时性 ● 系统不限并发用户数，因此整个系统后台应该设计足够强大的联机处理能力。 ● 每个门诊窗口操作应避免各环节按键后的明显等待时间。 ● 系统对海量事务处理数据表应该有实时（例如一周）、近线（例如一年）、离线的表结构设计，以使实时处理面对的是一个记录条数相对稳定的表。 ● 前台所有业务均应能方便地在实时、近线两个不同的数据集上实施操作。 ● 系统应该有专门服务于大数据量统计的数据库、表结构设计，使得此类操作不影响实时业务处理的响应时间。 系统主要功能全面 ● 具有包括科室业务全过程处理的整体的一体化的信息系统设计。 ● 能客户化修改实现符合本院的应用功能，扩展本院需求的功能模块与相关子系统。 操作方便性 ● 操作界面友善，操作清晰、方便、易于掌握，符合操作人员的工作习惯。 ● 提供录入模板，以提高操作员的录入速度。 ● 录入操作时提供各类字典提示功能。 ● 提供多种输入方式，以适应掌握不同输入方式的操作员操作。 ● 各个系统操作有联机帮助功能。 字典标准与维护 ● 采用标准字典体系（国家、国际、部颁标准）, 全面支持DICOM 3.0，CDA和HL7标准。 ● 各专业部门维护各自负责的字典，其他使用部门对字典仅有读的权限，无增、删、改权限。 ● 一类字典在一处一次维护，与它相关的字典保持数据的一致。 系统可维护 ● 系统的设计要方便维护。 ● 提供维护所需要的源程序代码。 ● 提供维护所需要的技术文档资料与培训，维护资料齐全（包括概要设计、详细设计、数据结构、框图、系统功能说明、用户操作手册、系统维护手册等）。 ● 对软件系统负责终身维护。 系统可升级 ● 系统可升级，并有统一、方便的升级方式。 现有数据继承 ● 系统