武汉大学公费医疗网上报销系统项目单一来源方式采购征集意见公示
武汉大学校医院拟采购公费医疗网上报销系统服务，申请单一来源方式采购，现予以公示。
一、采购内容：公费医疗网上报销系统定制软件开发服务
二、采购要求：
具体详见附件
三、采用单一来源采购方式的原因及相关说明
1、湖北博思软件信息技术有限公司是武汉大学三家附属医院医疗电子票据系统的供应商，且在武汉市电子票据系统领域市场占有率最高，武汉市绝大部分医院是其签约服务的医院。选择湖北博思软件信息技术有限公司作为公费医疗网上报销系统的开发商，方便采集电子票据信息，实现数据共享，为学校师生提供更便捷的服务。
2、本项目第一次公开采购时仅湖北博思软件信息技术有限公司一家供应商应标。
鉴于以上情况，拟以单一来源方式从湖北博思软件信息技术有限公司采购公费医疗网上报销系统服务。
四、拟定唯一供应商名称、地址
供 应 商：湖北博思软件信息技术有限公司
地 址：东湖新技术开发区花城大道8号
联 系 人：程成
联系电话：18507160521
五、公示期：
从2023年9月12日至2023年9月19日止
如有其他潜在供应商对本项目采用单一来源方式采购有异议，应在公示期内以书面形式以实名（盖单位公章、包括联系人、地址、联系电话）将意见反馈至武汉大学采购与招投标管理中心。
项目经办人：钟老师 027-68754585
技术负责人：殷老师 18207127650
地址：湖北省武汉市武昌区八一路299号
邮编：430072
武汉大学采购与招投标管理中心
2023年9月12日
附件：公费医疗网上报销系统服务技术要求
一、 面向系统的用户群
角色名称 | 所属单位 | 职责描述 |
管理员 | 校医院信管办 | 主要包括参数管理、用户管理、角色管理、权限管理。 |
业务员 | 校医院公医办 | 负责报销资料的审核、费用计算、报表统计等。 |
普通用户 | 武汉大学师生 | 通过移动设备提交报销材料。 |
表1 系统用户表
二、 功能需求
2.1 公费医疗网上报销系统
功能名称 | 子功能名称 | 功能描述 |
报销收单 | 线下收单 | 特殊人员可通过线下渠道，将报销资料提交给校医院业务人员。业务人员可在系统中选择对应的提报人，系统自动带出提报人的人员类型、学号/工号、其他信息等。业务人员也可在收单过程中对报销信息进行补充：就诊医院、等级、就诊日期、就诊类型等。 |
扫码收票 | 针对电子票据，业务人员可使用扫码枪扫描票据二维码，系统将自动进行电子票据验真、收票、解析。 |
高拍仪快速收单 | 填写完提报人的基本信息、就诊信息后，业务人员可将报销资料放入高拍仪中，系统将自动批量扫描票据、报销资料影像，并进行票据的识别、验真、解析。并将材料自动保存。 |
线上收单（移动端） | 报销人通过移动端归集票据，线上填写报销基本信息，报销系统接收到报销信息后，对接收到的票据自动验真、验重、整理、分类，以报销单的形式将信息提供给业务系统进行业务处理。 |
一键报销（附属医院）（移动端） | 师生在附属医院就诊后，可直接发起一键报销：平台通过与医院合作并得到授权，在附属医院就诊开票后，在平台发起报销申请，平台自动获取职工转诊、医疗票据、处方等就诊信息数据，并进行自动分类整理、目录匹配、费用计算，报销审批后进行记账登记。 |
费用计算 | 业务人员将报销相关资料收入到系统中后，系统将自动完成解析、核验、分类等操作，并根据人员情况自动进行票据金额计算、报销金额计算，业务人员可现场告知提报人报销详情。 |
报销审核 | 报销单列表展示 | 展示通过线上提报或者现场线下提报的所有报销单列表，业务人员可根据提报人姓名、提交时间、审核状态等进行筛选。 |
报销单详情展示 | 展示某一个报销单详细信息：报销基本信息（提报人信息、就诊信息）、票据金额信息（票据基本信息、明细项目信息、分类信息）、费用报销信息（详细的费用分类、计算详情）、报销资料查看（可查看报销单中收到的电子票据文件、纸质材料的影像等）。 |
报销单初审 | 业务人员可根据报销单详情中的票据金额、报销金额、该报销单费用计算详细规则进行审核，审核通过后，系统将自动将报销单的详细数据推送至财务系统中。如果是线上收单的报销单，系统会自动通知提报人提交报销材料。 |
报销单审核 | 根据不同类型的单据、当前登录人员权限进行报销单进度的过滤。业务人员、财务人员对应审核权限的报销单进行审核。 |
报销单修改 | 如果在审核过程中发现报销信息有误，或者特殊情况，可对报销单中的信息、金额等进行修改审核。 |
报销单导出 | 业务人员可将报销单进行导出、打印。 |
报销单打印 | 针对需要将查验结果作为附件依据使用的，支持查验结果打印。 |
费用审核计算 | 票据审核 | 门诊、急诊、住院电子票据自动核验验真、重复报销核验、票据信息预警。 |
票据信息解析整理 | 电子票据解析、纸质票据识别、清单整理。 |
公费医疗医保目录匹配 | 票据费用明细清单项目标准化、与公费医疗目录、医保目录匹配分类，用于费用计算时，根据分类扣减以及报销。 |
报销规则匹配 | 根据提报人员类别自动匹配对应的扣减规则、报销规则。 |
报销费用计算 | 根据提报人员类别、医院等级、类型自动匹配人员报销规则来计算对应报销单的报销金额。 |
匹配结果输出 | 将费用计算结果输出到报销单中。 |
费用汇总单 | 业务人员根据财务入账要求，通过不同的条件生成费用报销单，用于财务入账时使用。 |
报销规则设置 | 扣减规则管理 | 根据校医院报销政策，维护明细的扣减规则，如：特殊项目定额扣减、特殊项目比例扣减、根据医院等级扣减等。 |
报销规则管理 | 根据校医院报销政策，维护明细的报销规则，如：根据项目收费等级（甲、乙、丙），医疗机构等级、类型维护对应的报销比例。 |
人员报销规则 | 根据学校公费管理报销规则，将扣减规则和报销规则与人员类别进行挂接。 |
预警规则 | 可设置特殊项目预警、报销日期预警、费用超标预警等。 |
报销人员管理 | 在该模块维护提报人信息列表：姓名、学号/工号、部门、手机号、银行卡信息、人员类别等。用于线上报销校验、现场报销校验人员信息。可管理该人员是否可以报销。支持批量导入、导出。 |
医疗机构 | 维护单位对口医院，医院编码、名称、等级、类型（对口医院、专科医院、非对口医院等）。 |
数据字典 | 支持动态维护系统所使用的数据字典：报销类型、报销资料、报销人员类别等。 |
报表统计 | 收费项目报销统计 | 以医疗收费项目的维度，按照日期、人员等条件进行统计。 |
报销单统计 | 以报销单的维度进行分类统计，可按日期、部门、人员类别进行筛选。 |
报销人员统计 | 以报销人员的维度进行报销情况统计。 |
报表定制 | 根据业务需求，新增定制报表。提供导出pdf、word、excel等格式文件、打印功能。 |
系统管理 | 机构管理 | 上下级部门信息管理。 |
用户管理 | 业务人员管理维护，可批量导入。 |
角色管理 | 创建流程中经办人员角色，分配给业务人员用户。 |
授权管理 | 管理业务人员数据权限、审核权限、功能权限。 |
接口授权管理 | 外部系统对接授权，身份分配管理。 |
业务参数配置 | 单位报销预警配置、基础报销配置（报销周期等）、报销审批配置（审核机制，自动审核或者人工审核等）、单位绑定二维码生成、导出。 |
附属医院系统接口 | 获取诊疗信息 | 根据用户信息(手机号/身份证号)&就诊日期获取报销所需的就诊材料以及票据信息。 |
校医院His系统接口 | 获取转诊信息 | 根据用户信息(手机号/身份证号/学生编号/职工工号)获取实际转诊单情况。 |
月度汇总报销单推送 | 每月月初将上个月的报销单详情、分类汇总金额、报销汇总金额等报送给供料系统。 |
财务系统接口 | 付款申请单推送 | 提报人线上提交或者业务人员现场收单初审完成后，将报销单信息推送给财务系统进行复核。 |
付款信息同步 | 财务系统中付款流程完成后，通过该接口将付款状态、交易信息等同步至平台，平台将状态通知给提报人。 |
三、 技术要求
3.1 总体技术要求
3.1.1 SOA的架构
应用需满足可重用、松耦合、互操作的服务体系结构，通过服务的编排组合来实现业务的组合，通过服务的松耦合来满足业务变化和调整。
将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口采用中立的方式进行定义，它应该独立于实现服务的硬件平台、操作系统和编程语言。
3.1.2 服务接口
以Web Service技术作为SOA服务开发技术的首选技术，要求遵循Web Service成熟的开发标准及规范。
为了最大限度地复用现有应用系统的业务功能，在选择SOA技术标准规范时，必须考虑现有业务功能封装对技术标准规范的支持能力，Web Service服务接口应该支持通用的ESB总线。
业务系统提供Web Service服务地址、命名空间、调用方法、参数组（包含参数类型），返回值采用JSON或XML格式，并提供返回数据包格式描述，通过ESB工具对Web Service服务实现自动查询、调用、测试及管理。
3.1.3 J2EE平台或NodeJS平台
以Java技术作为Web Service开发的优先选择技术，各类组件、服务架构及技术层次均有共同的标准及规格，让各种依循J2EE架构的不同平台之间，存在良好的兼容性。中间件采用WebLogic或Node，应用及服务支持集群部署、负载均衡及故障转移。
3.1.4 数据库标准
数据库应当使用Oracle、MySql等，同时数据应符合武汉大学数据中心的数据标准。
3.1.5 移动端标准
移动端应当支持当前主流Android/IOS版本，支持微信平台。
3.2 系统兼容性要求
服务端支持目前主流操作系统（如Windows、Linux等）。
浏览器支持3种及以上目前主流浏览器（如IE、Firefox、Chrome、safari、360浏览器）。
系统在版本升级中保证接口协议、功能不发生变化。
3.3 系统性能要求
系统运行支持至少50万级注册用户量。
支持500以上用户同时使用。
支持100以上并发用户量。
系统保证7×24小时运行。
普通页面响应时间，小于1秒，最大不超过5秒。
查询页面响应时间，小于3秒，最大不超过30秒。
后台数据批处理时间应在二小时内完成。
支持负载均衡、可扩展性。
3.4 系统扩展性要求
支持与武汉大学的数据平台进行数据交换，满足数据交互的功能。
系统完全采用模块化的设计框架，模块之间遵循高内聚、低耦合的设计原则，具有灵活方便的添加新模块和变更模块的功能。
程序接口和数据接口清晰，便于二次开发，为新功能模块预留接口。
支持与武汉大学智慧珞珈APP进行对接，支持与智慧珞珈小程序进行集成（移动端应采用H5页面）。支持和校医院公众号对接。
支持与武汉大学的用户统一身份认证系统进行对接，将指定功能集成到武汉大学信息门户。
支持与武汉大学信息门户、智慧珞珈、短信平台等系统进行消息推送。
3.5 项目文档要求
1. 《需求调研报告》
2. 《需求规格说明书》
3. 《项目建设方案》
4. 《系统设计说明书》
5. 《数据库设计说明书》
6. 《项目编码规范》
7. 《项目计划》
8. 《开发进度月报》
9. 《测试计划及方案》
10. 《测试报告》
11. 《项目开发总结报告》
12. 《用户操作手册》
13. 《系统安装手册》
14. 《系统培训计划》
3.6 系统安全性要求
提供安全手段防止非授权用户的非法侵入、攻击，避免操作人员的越级操作。
软件自身具备网页防篡改、防注入式攻击、脚本过滤、防口令猜测、ip地址访问控制等安全措施。
采用分级管理模式，对不同级别用户的操作权限和数据访问范围有严格的限制，系统管理员可以根据学校情况灵活设置安全策略。
具备容灾能力，根据学校网站的特点能够记录系统访问日志及操作日志，备份和恢复系统数据，保证系统安全稳定运行。
对敏感性数据进行加密保存，支持标准主流加密算法，对安全性要求特别高的数据需进行物理隔离。
3.7 系统易用性要求
风格及使用习惯遵循武汉大学信息系统要求。
用户界面简单明了，布局合理，操作符合业务逻辑。
支持个人工作台，待办事项、通知信息显示。
3.8 系统维护性要求
系统为管理员提供丰富的系统设置和维护功能，包括用户和权限设置、字段维护、代码表维护、日志监控、数据批量处理、远程备份等等。
业务系统与数据库需分开部署。
系统升级和日常维护只需要在服务器进行即可。
系统出现异常时，7×24电话支持，2小时内到达现场提供服务支持。
四、 项目工期
自合同签订之日起3个月内完成项目实施，进行上线试运行，试运行6个月进行项目终验。
五、 项目管理
对项目的建设进行科学严格的管理，要通过系统计划、有序组织、科学指导和有效控制，促进项目全面顺利实施，投标方必须提供完整的项目管理方案，方案必须涵盖以下方面：
5.1 项目文档和程序管理
在项目的开发过程中以及交付使用后，会产生大量文档和程序，而且文档的版本在不断变迁和修改中，势必产生一个庞大、动态的集合，投标方必须提供合理的管理方法，对文档和程序进行版本化管理。
5.2 项目管理规范和手段
根据该项目的实施方案，在实施过程中，为了保证招标方能够对项目建设实施进行监控，及时发现和解决问题，投标方必须建立相应的项目管理规范，包括项目执行监控流程、执行监控的方法、执行监控的责任等，使管理和监控工作流程化、规范化，管理和监控工作责任明确。
5.3 项目管理控制
该项目的管理控制包含多个方面：项目范围、风险、进度、质量、变更管理控制，贯穿项目开发建设的始终，必须做到对项目建设范围准确定义，一旦范围发生变更，投标方要有相应的变更控制和应对措施。
5.4 风险管理
项目风险管理是对项目风险从识别到分析到应对措施的一个过程，包括风险识别、风险量化、风险对策、风险对策实施控制四个方面。项目在实施过程中会出现各种各样的风险，投标方必须做到充分、有效识别风险，应对风险和控制风险，在项目实施之初必须制定风险预测和规避风险的对策。
5.5 项目的开发管理
开发管理方案必须要按照软件工程的方法，开发过程满足软件生存期的要求，采用先进的软件开发方法和软件开发工具，科学的管理软件开发过程，降低软件开发风险和成本，使软件项目获得较高的经济效益和社会效益。
六、 培训要求
培训应贯穿于整个项目的实施过程中，包括在从项目准备、研发到项目运行的全过程中。投标方需提供详细的培训方案、培训内容、培训计划、软件使用、后期维护。需要提供以下几方面的培训：
6.1 运行管理培训
为了使招标方的相关人员掌握有关应用系统的使用、维护和管理方法，达到能独立进行管理、故障处理、日常测试和维护等工作的目的，应进行系统的技术培训，以保证所建设的系统能够正常、安全、平稳地运行。
6.2 培训要求
投标方派出的培训教师应具有丰富的同类课程教学经验和应用经验；
所有的培训教师必须用中文授课；
投标方必须为所有被培训人员提供培训用文字资料和讲义等相关材料，如果培训地点在外地，投标方还应为所有被培训人员提供食宿；投标方应按合同规定安排培训时间和培训名额。
6.3 培训方式
包括课堂讲解、上机操作和实际工作的参与。
6.4 培训工作的内容和对象描述
投标方进行的培训工作包括了培训方案的设计、培训制度的制定、培训开发、培训实施和培训效果评估，及时监控培训效果，保证培训课程符合招标方实际的需要。在系统运行（含试运行）的各个阶段提供相应的培训内容描述，培训阶段安排包括：系统开发人员培训、系统管理人员培训、系统维护人员培训和系统使用人员培训。各个阶段描述标题包括：培训内容、培训教师水平、参加对象、授课时间和上机操作时间。
七、 服务保障与承诺
投标方应承诺保证该项目按时正式稳定地运行，并承诺提供不少于3年免费维保期。
投标方应承诺根据对招标方相关业务运做的规律来有计划地制定服务保障体系。
该项目一旦运行起来，稍有差错就会引起各方面的反映和损失，所以系统的售后维护服务和技术支持工作也应有足够保障。投标方作为具有丰富信息化校园项目经验的系统集成和软件开发企业，针对招标方不同的系统需求，制定不同的运行保障方案，建立完善的本地售后服务体系，对招标方提供充分考虑使用者利益的技术支持及售后服务。
除了上述的有关承诺之外，投标方关于服务保障体系的描述应包括如下内容：
7.1 运行保障机构
主要描述投标方对本项目的运行保障能力。
7.2 保期内运行服务内容
售后维护服务，定期走访或实行远程维护：定期维护的时间区间、周期和详细规划，规划包括：方式、人员和详细的维护内容。
重大事项的及时响应：系统出现故障或意外情况导致系统不能正常运行时，根据投标方响应的情况描述，针对不同响应级别的即时响应包括：人员、时间和内容等。
服务请求的方式：在我方需要提供服务（包括即时的和非即时的）时，能够与投标方联系沟通的方式描述，应包括：服务热线电话和联系人、联系单位信息、信函/传真、电子邮件、服务网站。
服务请求的流程：投标方对用户的支持或维护请求处理流程的流程图和详细描述。
系统升级：提供应用平台的软件补丁版本的升级服务。
需求变更：在售后服务期内，因学校业务需求变化导致的非模块级功能需求变更、性能要求提升导致的部署结构变化，投标方应免费提供变更。
7.3 保期后运行服务内容
售后维护服务，定期走访或实行远程维护：收费服务的时间区间、周期、费用和详细规划，规划包括：方式、人员和详细的维护内容。
重大事项的即时响应：所需费用由双方协商。
7.4 运行服务的档案
运行服务的详细记载，可以用于分析总结。
7.5 用户投诉
投标方应设有用户投诉受理电话，对用户的意见做出反应。
如果有用户投诉受理电话，请描述以下内容：电话号码（或传真）、投诉中心负责人和受理答复时间。
八、 成果移交
8.1 交付成果和文档资料
在本期项目的开发过程中和交付使用后，要求将各个阶段产生的全面、规范的成果和文档资料交付给招标方，而且要提供明确的交付清单。同时，成果和文档资料必须符合软件工程的相关要求。要交付的成果和文档资料主要包括以下部分：
1. 可运行的系统。
2. 技术文档：包括项目开发中的各种技术文档，如开发环境配置说明、软件工具清单、需求分析说明、变更说明、系统设计说明、用户手册、测试用例、测试结果、系统维护说明、系统培训资料以及有关系统接口的技术说明等等。
3. 管理文档：包括项目开发中的一些工作文档，如，计划、报告、讨论纲要、会议记录等。
8.2 版权归属及使用要求
该系统的使用权为招标方完全拥有。
九、 项目验收与付款方式
合同签订后投标方提交需求分析报告及详细设计报告，由招标方组织需求分析报告和详细设计报告评审会，由招标方签字确认项目最终需求和设计。
由中标方根据详细设计说明书对信息系统进行软件开发，开发完成后向招标方申请上线前测试，并向招标方提交《测试报告说明书》，由招标方组织上线前测试及功能评审会，中标方需提前在招标方提供的测试环境中进行系统部署，评审时由中标方根据测试报告对其开发的系统进行演示。在测试环境下对系统测试成功后，中标方需向招标方提交《系统测试报告》和《安装部署手册》，由招标方签字确认系统测试成功。
由招标方根据安装部署手册在生产环境中安装部署信息系统，并组织技术人员根据测试报告对系统进行测试，确保系统能够正常运行，中标方依据项目合同的交付内容向招标方进行项目交付。系统正常运行六个月后，中标方须向招标方提交项目验收申请，招标方组织工作组验收，招标方在收到项目验收申请的5个工作日内，组织专家验收，并向中标方提供项目验收报告，验收通过后支付合同额90%。
质保期内，系统正常运行一年后，支付合同额10%。
