大连医科大学附属第二医院互联网医院随访系统采购项目采购公告
大连医科大学附属第二医院互联网医院随访系统采购项目采购公告
大连医科大学附属第二医院互联网医院随访系统采购项目招标项目的潜在供应商应在辽宁政府采购网获取招标文件,并于2020-12-18 13:30（北京时间）前递交投标文件。
建设目标
本次项目旨在打造医院信息化建设3.0。应以数据处理和使用为核心，搭建人工智能技术服务平台，应实现对诊疗全流程进行智能辅助、管理、监测、预警等功能。即：人工智能智慧服务生态（也称医疗AI大脑）。具体目标应实现以下四点：
1) 简化患者匹配流程
人工智能聊天机器人和虚拟助理应具备拓展医疗可及性，应尽量避免并减少患者不必要的现场就诊，如果患者需要医疗护理，人工智能应支持帮助患者更好的与医生进行交互。
2) 医疗专家的好帮手
人工智能技术服务平台应实现疾病辅助诊断治疗、个人健康管理、医院智能管理等服务，应发挥出人工智能智慧服务的优势和独特作用。
3) AI辅助医院降低医院人力成本
人工智能技术服务平台应，让人工智能辅助机器人来完成医生的部分工作，可以很好的减少医生的沟通时间，提高服务质量，节约医院人力成本。
4) 不仅快、准，还很“全面”
人工智能技术服务平台根据捕捉到的一些细微病症变化，应支持分析其背后的多维度信息，实现诊断预警。
1.4. 建设内容
本项目建设内容包括医院网页管理后台、医生移动端、患者移动端以及互联网医院接口对接等模块。
| 序号 | 建设内容 | 软件系统 | 备注 |
| 1. | 医院网页管理后台 | 医院网页管理后台软件建设 | |
| 2. | 医生移动端 | 医生移动端应用产品建设 | |
| 3. | 患者移动端 | 患者移动端应用产品建设 | |
| 4. | 互联网医院接口对接 | 互联网医院接口对接 |
二、 技术需求
2.1. 系统功能要求
具体建设需求以及配套功能如下：
| 功能模块 | 子模块 | 功能描述 | |
| 医院网页管理后台 | 登录 | 医生登录科室权限配置 | 以科室/专家团队为单位，科室内人员登录同一账号，浏览随访计划 |
| 医生多科室登录 | 支持医生同时登录多个科室 | ||
| 医生个人账号登录 | 支持医生个人账号登录，管理自己的患者 | ||
| 支持打通医院员工账号 | 支持打通院内账号登录 | ||
| 统计 | 统计 | 统计计划的添加人数及总数 | |
| 指标展示 | 支持根据业务科室需求，自定义展示关注的患者健康指标 | ||
| 患者管理 | 添加及批量添加患者 | 应支持微信扫码，患者手机号和批量导入功能 | |
| 自动加入患者 | 接入医院后，应支持自动加入患者 | ||
| ●患者视图 | 支持跟进院内外数据，自动提取患者档案，智能展示患者病情概况和院外康复概况，形成患者画像； | ||
| 随访计划监测 | 医生控制随访计划的开始及暂停 | ||
| 随访计划进度总览 | |||
| 患者监测 | 患者随访进度监测 | ||
| 患者查询 | 可接入HIS的多维度查询患者 | ||
| 可读取HIS中患者的详细信息 | |||
| 检索加入计划的患者 | |||
| 患者分组管理 | 应支持对患者进行分组，及删除、变更分组。分组可动态添加、删除。 | ||
| 支持设置关注的患者组 | |||
| 群发 | 支持给患者群发患教消息，推送到公众号、小程序等 | ||
| 患者和医生可以进行沟通 | 由医生设置是否开启患者沟通功能 | ||
| 医患进行文字、图片沟通 | |||
| 随访管理 | 已有随访方案管理 | 浏览随访计划详情 | |
| 医生自建随访计划 | |||
| 医生动态调整随访计划 | |||
| 随访方案库 | 系统自带多科室标准化随访模板，可选择使用和修改 | ||
| 随访知识库 | 支持自定义问卷、患教文章和嘱托提醒等内容 | ||
| 导出 | 分计划导出随访数据 | 导出数据 | |
| 其他 | 医生-打通患者院内就诊数据 | 应支持对接院内数据，展示院内患者就诊数据，并根据患者就诊数据，形成患者动态画像，自动随访和预警 | |
| ●支持嵌入医院已有医生工作站 | 支持已web端页面和api接口的方式，嵌入院内医生工作站中。 | ||
| ●支持患者详情跳转到院内系统 | 打通患者标识，支持从患者详情页，一键打开医院His、电子病历等信息系统 | ||
| 医生移动端 | 患者管理 | 医生-添加患者 | 应支持微信扫码，患者手机号添加患者功能 |
| 医生-患者查询及详情 | 应支持查看和添加患者的院内就诊信息，支持查看患者上传的病历 | ||
| 群发 | 支持给患者群发患教消息，推送到公众号、小程序等 | ||
| 管理患者分组 | 支持新增分组，维护分组内的患者列表 | ||
| 设置关注患者 | 支持在患者详情页关注患者，便于重点患者的病情监控和管理 | ||
| 登录 | 医生登录科室权限配置 | 以科室/专家团队为单位，科室内人员登录同一账号，浏览随访计划 | |
| 医生多科室登录 | 支持医生同时登录多个科室 | ||
| 医生个人账号登录 | 支持医生个人账号登录，管理自己的患者 | ||
| 支持打通医院员工账号 | 支持打通院内账号登录 | ||
| ●H5嵌入打通 | 支持以H5对接的形式嵌入医院已有的医生移动端中 | ||
| 进度监控 | 医生-随访进度监控 | 医生或科室跟踪自己随访项目的进行情况，观察并干预随访进度 | |
| 问答 | 医生-医患问答 | 接收患者线上提问，支持多次沟通回答患者问题 | |
| 智能入组 | 医生-智能自动分组 | 通过设置患者特征，自动实现患者分组管理 | |
| 预警 | 医生-预警推送 | 患者指标有异常时，会提醒医生关注，必要时进行线上沟通干预 | |
| 聊天 | 医生-随访聊天 | 应支持医生主动打开和关闭随访聊天，在线主动联系患者 | |
| ●扩展 | 支持从互联网医院在线问诊中添加患者 | 支持在互联网医院的问诊界面中，添加患者进入分组或者随访计划 | |
| 患者移动端 | 加入计划 | 患者-加入疾病管理 | 通过扫码、医院公众号或者短信，进入疾病管理 |
| 登录 | 患者-身份认证 | 应支持和医院线上患者账号体系打通，支持和医院系统内患者身份绑定，患者身份认证后，便于同步就诊关系和自动进入随访计划 | |
| H5嵌入 | 支持H5方式嵌入小程序和APP等医院已有应用 | ||
| 随访 | 患者-随访计划通知 | 患者在移动端，按照计划接收随访通知 | |
| 患者-AI机器人随访 | 患者在移动端，和医生机器人助理进行对话式Bot交互，帮助医生采集病情，同时为患者反馈病情评估和健康知识 | ||
| 患者-查看随访记录和指导结果 | 所有的随访行为都有记录，支持查看随访评估结果和随访进度 | ||
| 问答 | 患者-向医生提问 | 应支持患者向医生/科室提问，并获得医务人员回答 | |
| 聊天 | 患者-接收随访聊天 | 应支持患者被动接收医生的随访聊天消息 | |
| 我的 | 患者-我的病历 | 应支持展示院内病历查询和拍照上传病历 | |
| 用药管家 | 患者-用药管家 | 和医院系统对接后，支持展示用药指导交代 | |
| 管理工具 | 患者-专病/特殊人群自我管理工具。 | 应支持根据专病/特殊人群，个性化展示疾病自我管理工具，比如记录工具、指标评估工具、个性化患者知识、饮食运动管理等等 | |
2.2. 技术规格要求
随访系统需体现智能化的能力，应采用先进的自然语言处理、文本结构化等技术，分析病历和随访内容，具体需满足以下技术规格要求：
| 技术点 | 描述 |
| ●自动入组 | 系统需分析患者电子病历，并进行文本结构化，将患者结构化病历与医生设定的随访方案里的入组条件自动匹配，通过发送推送的方式自动邀请入组。(提供截图，未提供按负偏离处理) |
| ●对话式交互 | 随访过程应该采用先进的机器人对话式交互方式，减轻患者交互的成本。(提供截图，未提供按负偏离处理) |
| ●机器人随访 | 医生只需制定方案，随访过程由机器人自动触发，并引导患者完成随访过程。(提供截图，未提供按负偏离处理) |
| ●问卷结构化 | 系统需支持将问卷及患者的回答进行结构化表示，抽出去医学实体及其属性信息，支持后续的预警、科研、统计等需求。(提供截图，未提供按负偏离处理) |
| ●智能预警 | 当患者的病情（体温、血压、症状）等促发了某个紧急的情况时，应该内置预警、提醒的内容，警示患者。(提供截图，未提供按负偏离处理) |
| ●智能患教 | 能够根据患者的病历信息和随访回答内容，建立用户画像，自动推荐与患者最紧密相关的患教知识。(提供截图，未提供按负偏离处理) |
2.3. 系统配置要求
1） 服务器配置要求
数据库服务器应支持Linux、Windows等系统，应用服务器应能支持 CentOS、Windows等系统。
服务器架构采用集群化部署，支持集群和失效转移，提供良好的可扩展性和容错性。对于路由器、防火墙等关键设备应采用双机热备策略，支持出现单点故障后自动切换。应用程序应实现负载均衡，多机部署，提供7*24服务。应支持存储高可用，VSAN分布式存储提供共享存储服务，出现故障后可以无缝衔接。
2） 工作站操作系统要求
应支持Windows系列操作系统。
3） 移动端操作系统要求
应支持Android、iOS、小程序、公众号等系统。
2.4. 总体设计要求
2.4.1. 技术标准
2.4.1.1. 信息抽取、知识图谱
本项目建设应支持NLP信息抽取技术、知识图谱业务，根据“先学习再接受反馈”的算法模式，打造绝对领先开源式“先标注再学习”。应构建业界顶级医疗知识图谱，知识学习源应来自人民卫生出版社旗下人卫知识库、纸质说明书、论文摘要和副高及其以上专家共识。
2.4.1.2. 语义理解技术
本项目应基于医疗行业特征深度定制搜索应用场景，基于深度学习技术，应支持从医患对话中学习，并实现用户反馈行为自学习。
2.4.1.3. 知识推理
本项目应采用深度贝叶斯网络知识推理模型，极大化考虑病情的高维关联特征；医疗知识图谱为检索，应支持自动学习；就诊数据驱动推理，应实现疾病诊断、用药推荐等业务。
2.4.1.4. 智能交互
智能交互研发应采用对话交互技术，支持优质病历数据学习；在多样化应用场景中，应融合业务特征系统及打磨迭代。
2.4.1.5. 机器学习
应具备机器学习技术。通过对大量历史医疗数据的清洗、整理与训练，建立精准就医分类模型与知识库。
2.4.2. 技术要求
1） 应用架构的先进性
平台应将深度学习、大数据处理、语义理解、医疗交互式对话等领先的AI技术与医学相融合，通过AI 数据，赋能医疗健康行业各个环节，实现智慧医疗升级，提升医疗行业的效率和体验。
2） 整体架构设计要求
本项目建设的整体架构设计应以患者为中心，实现患者健康管理、疾病风险预测、疾病的诊断、治疗以及治疗后的康复管理、慢病管理的全流程医疗健康管理。同时通过精准医疗和医疗机器人等关键技术为整个全医疗健康流程进行赋能，平台应从医疗健康全流程角度出发，规划出具有针对性、具体性的健康建议，加强群体智能健康管理，有效利用健康大数据分析、物联网等关键技术。
平台应接受相关管理部门指导及监管，建立统一处方审核追溯机制，所接入互联网医院的服务及数据均应接受监管和指导。
3） 平台技术架构要求
平台体系架构应进行分层设计，应包括具体应用与功能应用的分层、应用与数据分层、不同类型数据的分层等，保证整体信息基础设施的灵活性、可扩展性、可维护性等要求。
应实现应用层的无缝对接，实现应用产品与互联网医院的统一性，保证应用产品入口的唯一性，提升用户体验感。
4） 符合SOA 的整体架构
系统应基于真正的SOA三层架构体系（用户界面层-业务逻辑层-数据库层），建设符合单体医院、区域医疗为单位的人工智能平台，对整个诊疗环节，应实现高质量的AI辅助决策、精准就医、数据监测、风险预警、个性化智能管理等功能，解决整体医疗人力资源缺失带来的各项问题。
2.4.3. 安全需求
1) 等保三级：应按照不低于网络安全三级等保的要求，做好网络安全等级保护备案和网络安全防护工作，对本项目的网络安全和数据安全负全部责任。
2) 源数据脱敏：源数据从医院传出时，针对姓名、电话、医生等隐私信息应做好脱敏处理，仅保留必要的年龄、药物等信息。
3) 患者授权：患者在使用过程中，获取用户知情授权。
4) 数据加密：应使用AES对称加密机制，对传输数据加密，同时应采用加密技术对存储在数据库的数据进行加密。
5) 网络隔离：应采用前置机双层转发机制，保证网络传输的安全。
|
招标
|
- 关注我们可获得更多采购需求 |
关注 |
最近搜索
无
热门搜索
无
