消息提醒机制
需求说明书心医国际信息科技（西安）有限公司
修订历史记录
日期版本说明作者
2018-11-05 0.1 对于业务相关数据整合性、数据及时性、
准确性监控
吕永磊
目录
1. 引言 (1)
1.1. 编写目的 (1)
1.2. 项目背景 (1)
1.3. 定义 (1)
1.4. 参考资料 (1)
2. 任务概述 (1)
2.1. 目标 (1)
2.2. 用户的特点 (2)
2.3. 假定和约束 (2)
3. 需求规定 (3)
3.1. 对功能的规定 (3)
3.2. 对性能的规定 (3)
3.2.1. 精度 (3)
3.2.2. 时间特性要求 (3)
3.2.3. 灵活性 (3)
3.2.4. 输入输出要求 (3)
3.2.5. 数据管理能力要求 (4)
3.2.6. 故障处理要求 (4)
3.2.7. 其他专门要求 (4)
4. 运行环境规定 (4)
5. 附录（需求功能说明书） (5)
5.1. 数据校验工作站.......................................... 错误!未定义书签。

5.1.1. 自定义语句查询........................................ 错误!未定义书签。

5.1.2. 自定义筛选过滤........................................ 错误!未定义书签。

1.引言
1.1.编写目的
本说明书的编写目的，是为用户及分析人员充分理解本产品而设立的，它说明了本产品的各项功能和性能要求，明确标识各功能的实现过程，阐述实用范围及背景，提供客户解决问题或达到目标所需的条件或权能，提供一个度量和遵循的基准。

本说明书的预期读者为软件的管理人员、开发人员、维护人员、医疗机构信息科及其他相关人员。

1.2.项目背景
赤峰市医院电子病历评级小组解读标准时有关数据达标标准中，多个评审数据达标标准中要求知识库相关的提醒、危急值提醒、医嘱变更提醒、不合格标本拒签提醒、手术安排结果提醒、病案质控结果提醒、病案质控结果处理后提醒、处方评价结果提醒等内容。

系统委托单位：赤峰市医院
开发单位：心医国际信息科技（西安）有限公司
主管部门：赤峰市医院电子病历评级小组
1.3.定义
HIS：文中所指的HIS即为医院现使用医院信息化软件系统产品。

1.4.参考资料
a．电子病历评级标准；
2.任务概述
赤峰市医院电子病历评级小组解读标准时有关数据达标标准中，多个评审数据达标标准中要求知识库相关的提醒、危急值提醒、医嘱变更提醒、不合格标本拒签提醒、手术安排结果提醒、病案质控结果提醒、病案质控结果处理后提醒、处方评价结果提醒等内容。

a．与知识库相关的提醒都可以利用消息提醒平台实现，特别是非当前操作场景提醒类，如特殊检验结果出现时，需护士做相应评估的提醒，体征异常时，提醒护士做特殊护理操作的提醒等。

b．危急值的提醒：目前有独立危急值系统实现。

c．医嘱新开变更时的提醒：目前有护士站消息板。

d．检查、检验状态的提醒：检查检验中的关键闭环状态进行向医生、护士的反馈提醒。

e．不合格标本拒签的提醒：检验不合格标本拒签时向护士提醒。

f．手术安排结果提醒：手术安排结果向医生。

g．病案质控结果提醒：病历质控情况向医生提醒。

h．病案质控结果处理后的提醒：医生针对质控结果填写的修改情况向质控医生提醒。

i．处方评价结果提醒：处方点评结果向医生提醒。

2.1.目标
消息生产者将消息发送给消息传递服务，消息传递服务又将消息推给消息消费者。

2.2.用户的特点
本软件的最终用户有医生、护士、质控管理员、药师、技师、医务管理者、信息科专业管理人员等，主要是关键节点的消息推送，相关业务关联角色信息同步，所以整个系统除了考虑系统本身的设计，还需要顾及到相关人员信息传递及时性。

2.3.假定和约束
本系统的开发周期应控制在2周时间内完成设计，保证系统的按时交付，完成用户的全部需求，同时应发掘出的隐藏用户需求，并予以实现。

在开发这套软件时，我们假设用户已经熟悉基本的WINDOWS操作，管理人员能够对几种不同的数据库进行较为熟练的操作以便于在软件的日常维护中对较好的维护数据库系统。

3.需求规定
3.1.对功能的规定
本此需求功能不涉及其他业务模块，与其他系统完全独立，不会过度的提出这个系统的特殊需求。

附录部分为各模块的功能需求。

3.2.对性能的规定
3.2.1.精度
无。

3.2.2.时间特性要求
消息发送对于时间及时性要求特别高。

3.2.3.灵活性
a．HIS系统为一个不间断的24小时连续运行的系统，除了整个系统的正常运行以外，如果碰到系统出现大问题，还需要有一个应急方案来解决整个医院的运行。

3.2.
4.输入输出要求
无
3.2.5.数据管理能力要求
数据容量的限制取决了磁盘的容量和数据库的最大容量值，整个数据库的增长取决于系统上线以后，在正常的运行条件下，每个周期数据库的增长速度，在磁盘足够大的情况下，数据的存取不受限制。

在后期如果数据量增长过大或过快，可以采用报表和前台数据隔离的方式，或采用数据归档方式来对数据库的增量和速度进行管理。

3.2.6.故障处理要求
软件在升级过程，或由于操作不当可能会产生报错。

异常报错：系统出现异常错误时，程序会弹出对话框，写明错误代码及原因，用户可以依据此出错信息向公司方研发部报告。

操作错误：如果用户出现操作错误，如数据类型输入错误、缺乏必要字段等，系统会弹出对话框显示出错内容，并将光标设置出错位置上，由现场工程师指导或远程解决等。

3.2.7.其他专门要求
无。

4.运行环境规定
客户端操作系统： WindowXP/Win7
客户端数据库环境：oracle11.2.0.3客户端
5.附录（需求功能说明书）
5.1.消息提醒机制
5.1.1.消息服务端
消息发送者可以发送一个消息后消息服务端接收信息，将消息通过一条虚拟的通道（主题或队列）上发送给消息接收者。

一条信息可能最终转发给一个或多个消息接收者。

整个过程都是异步的。

5.1.2.消息客户端
消息发送者可以发送一个消息而无须等待响应。

消息发送者将消息发送到一条虚拟的通道（主题或队列）上，消息接收者则订阅或是监听该通道。

一条信息可能最终转发给一个或多个消息接收者，这些接收者都无需对消息发送者做出同步回应。

整个过程都是异步的。

方案一：独立系统
加载初始化：登录科室、登录工号、登录类型、登录IP
发送信息数据：类型、发送时间、发送科室、发送内容、患者ID、开单科室、开单医生
推送信息数据：登录IP、类型、发送时间、发送科室、发送内容、患者ID、开单科室、开单医生
注销释放：登录科室、登录工号、登录类型、登录IP
方案二：基于平台及单点登录。