导诊功能点分析Word格式文档下载.docx
- 文档编号:20417114
- 上传时间:2023-01-22
- 格式:DOCX
- 页数:10
- 大小:124.62KB
导诊功能点分析Word格式文档下载.docx
《导诊功能点分析Word格式文档下载.docx》由会员分享,可在线阅读,更多相关《导诊功能点分析Word格式文档下载.docx(10页珍藏版)》请在冰豆网上搜索。
删除一个排队者的信息;
排队表中对应记录被删除,护士端界面一个队列的对应节点被删除,信息发布屏幕上一个队列的对应节点被删除
转移:
将一个排队者从一个队列转移到另一个队列;
排队表中对应记录的信息被修改(排队队列ID被修改,排队位置也可能修改);
护士端界面中将排队者从原显示队列中删除,添加到目标队列中的合适位置;
信息发布屏幕上也有与护士端界面上相应的变化
清空:
清空一个排队队列;
排队表中一个队列的记录被删除,护士端界面中一个队列的信息被清空,信息发布屏幕上一个队列(或一部分信息,当多个排队队列在一个显示队列中显示时)被清空
同步:
指的是将信息发布屏幕内容与排队表信息同步。
通知TQServer将一个显示队列清空,再将该显示队列对应的多个排队队列的记录逐条发给TQServer,由TQServer转发给播放器;
需要区分是同步首次排队信息还是二次排队信息(要利用患者的状态);
排队表无变化,护士端界面显示无变化,信息发布屏幕上显示被更新、与排队表信息一致
程序重启:
护士端程序重启之后,需要重新读取信息;
对于两次呼叫、且需要区别显示首次等候队列、二次等候队列的(实际上是一个队列的患者的两种状态),需要根据患者状态自动为两个队列读取信息并在自己的屏幕上显示
操作分析:
以上每个操作对于数据库修改的预期结果,护士端程序是知道的;
每个操作完成后护士端的预期显示结果,护士端程序也是知道的。
钟小明:
此时的操作流程是:
护士端程序将信息交给TQServer,TQServer操作数据库,完成后会通知护士端程序重新读取排队表所有记录、更新界面,并通知播放器、LED控制程序、TTS控制程序等进行后续操作。
我认为:
在这种情况下,需要考虑重新读取排队表所有记录这个思路是否妥当?
若数据量不大,那么问题不大(读取效率、显示效率都可接受);
若数据量较大(比如一个队列100人甚至更多),那么读取效率、显示效率如何?
既然护士端程序对结果是完全知道的,可这样设计:
TQServer只是通知护士端程序,你所希望的操作是否已完成,若完成,则护士端就更新显示(数据是什么、怎么更新,护士端是完全知道的)
在界面中增加一个排队者时,关于其ViewID,有以下几个问题:
何时确定:
是在插入数据表之前就确定了,还是在插入排队表之后才确定?
从技术上来说都可以。
应该要求在插入前确定,否则不管是什么程序执行插入操作,它无法直接获取ViewID。
多点执行:
插入数据表的操作是在一个地方执行,还是可在多个地方执行?
若允许在多个地方执行,那么存在ViewID冲突或不连续之可能。
从单点执行的角度考虑,不能由护士端程序确定ViewID,应该由TQS确定ViewID,之后回传给护士端程序,护士端程序只需要根据队列ID+ViewID读取新增信息即可,无需读取所有信息
关于排队,一个队列的信息在三个地方的体现:
排队表中的信息
护士端排队界面,一个队列的排队人的排队顺序(即显示顺序)
信息发布屏幕:
显示顺序应与护士端显示顺序一致
一个关键问题:
护士端的显示顺序怎么决定?
显示顺序与排队表中的哪些信息有什么关系?
举例:
✓队列中已有两人:
两个平诊A001、A002,此时显示顺序为A001、A002
✓来个急诊,号码是A003,按照优先级+编号排队,此时显示顺序为A003、A001、A002
✓来个平诊,号码是A004,排队队尾。
此时显示顺序为A003、A001、A002、A004
✓来个急诊,号码是A005,按照优先级+编号排队,此时显示顺序为A003、A005、A001、A002、A004
✓直到此时,播放器端采取的策略是按照优先级+编号排序
✓急诊均已被呼叫,医生再呼叫时A001刚好不在现场,A002进去就诊,此时队列中只剩A004了;
过一会A001来了,若护士将其仍排在平诊的首位,那么此时显示顺序为A001、A004,仍然符合按照优先级+编号排序的规则;
若护士将其排在平诊的队尾,那么显示顺序为A004、A001,不符合按照优先级+编号排序的规则
✓若所有排队者均未被呼叫,护士强行将A004排到A002的前边(假设医院的规则允许这样做),此时显示顺序为A003、A005、A001、A004、A002,也不符合按照优先级+编号排序的规则
✓还有其它很多情况会导致显示顺序不符合按照优先级+编号排序的规则
是否绝对不会出现红色文字描述的情况?
✓不会:
可采取优先级+编号排序的规则来处理护士端界面、信息发布屏幕的显示;
若需要刷新界面,只需要在读取排队信息时增加用优先级+编号的orderby字句即可
✓会:
此时无法依赖优先级+编号来确定显示顺序,只能用一个顺序字段来确定显示顺序,这个字段的值需要有一个良好的策略来维护。
信息显示是按照优先级+顺序号排序的。
根据这个规则,从排队表中读取信息时,增加用优先级+顺序号的oerderby子句即可。
关于顺序号字段,应注意以下事项:
顺序号应以2的n次方做间隔,比如32,此时顺序号为32、64、96、…;
因为中间插入时可简单用上下两个节点的顺序号之和除2所得的数总是偶数,不用考虑四舍五入问题;
也因为是2的n次方的原因,不管出现何种插入情况,顺序号均有良好的规则
第一个顺序号不能为0,否则向第一个节点前边插入节点时就变成不可能了
向尾部增加一条记录时,应读取表中该队列的最大顺序号,将该顺序号+间隔数,即为新记录的顺序号
顺序号每天从头开始,不累积
建议间隔不要小于32;
当间隔为32时,在极端情况下,可在第一个节点之前用总是将节点插入在队列最前端的规则增加5个节点,顺序号分别为16、8、4、2、1,一般不会出现这种极端情况
在增加节点时,顺序号也有跟ViewID类似的问题:
何时确定、多点执行
2.医生端叫号程序(或硬件叫号器)
已在排队表中
顺呼、选呼、复呼。
顺呼:
按照规则呼叫下一位;
排队表中一条信息的状态被改变,护士端界面的某个队列的第一条信息被删除,信息发布屏幕上某个队列中第一条信息(多个专家的队列在一个队列中显示的,是呼叫专家的第一条信息)被删除,叫号信息被更新(LCD、LED,规则有多种),有弹出窗口显示呼叫信息,有TTS发呼叫语音
选呼:
选择呼叫排队队列中的某一位(硬件叫号器无此功能);
排队表中一条信息的状态被改变,护士端界面的某个队列的一条信息被删除,信息发布屏幕上某个队列中一条信息被删除,叫号信息被更新(LCD、LED,规则有多种),有弹出窗口显示呼叫信息,有TTS发呼叫语音
复呼:
再次呼叫刚才被呼叫的人;
排队表中信息无变化,护士端界面无变化,信息发布屏幕上某个队列中信息无变化,叫号信息无变化,有弹出窗口显示呼叫信息,有TTS发呼叫语音
3.TQServer
由护士端程序或叫号程序(硬件叫号器)提供
其操作与护士端功能、医生端功能均有对应关系。
护士端程序提供排队者信息,TQS将其插入到排队表;
若成功,则发消息至护士端程序,并发消息至CS
护士端程序提供排队者信息,TQS将更新排队表中对应记录;
护士端程序提供排队者信息,TQS将从排队表中删除对应记录;
护士端程序提供排队者信息及目标队列信息,TQS修改排队表中对应记录的信息;
若成功,则发消息至护士端程序,并发消息至CS(两条消息)
护士端提供队列ID,TQS从排队表中删除该队列的所有记录;
护士端程序提供命令(是否需要制定仅同步某个播放器?
),TQS发消息给CS(一条清空,若干条插入消息)
医生端提供设备号,TQS根据规则检索被呼叫者信息,修改该记录的状态,发信息至CS(CS转给播放器,从排队信息中删除对应节点、更新叫号信息、弹出窗口提示),发消息至LED控制程序(最终更新LED屏),发消息至TTS控制程序(最终播放呼叫语音)
医生端提供设备号及被呼叫者信息,TQS修改排队表中对应记录的状态,发信息至CS(CS转给播放器,从排队信息中删除对应节点、更新叫号信息、弹出窗口提示),发消息至LED控制程序(最终更新LED屏),发消息至TTS控制程序(最终播放呼叫语音)
医生端提供设备号,TQS发信息至CS(CS转给播放器,弹出窗口提示),发消息至LED控制程序(最终更新LED屏),发消息至TTS控制程序(最终播放呼叫语音)
4.CS(通讯服务)
接收TQServer发来的消息,转发给对应的播放器
5.目标程序(播放器程序、LED控制程序、TTS控制程序等)
播放器程序:
接收CS发来的信息,根据信息类型更新显示
LED控制程序:
接收TQS发来的消息,通过LED控制器更新LED屏的显示
TTS控制程序:
接收TQS发来的消息,通过TTS盒子+音箱播放呼叫语音
6.目标设备(播放器+LCD屏、LED控制器+屏、TTS盒子+音箱等)
播放器+LCD屏:
由播放器程序控制,显示多种内容
LED控制器+屏:
由LED控制器控制,显示叫号信息
TTS盒子+音箱:
由TTS控制程序控制,播放呼叫语音
模式一中的要点:
排队顺序机制。
⏹模式二:
挂号直接排队、医生一次呼叫
这个应用场景与模式1稍有不同:
挂号直接进入候诊排队队列。
此时可不需要护士端的排队增加功能,但在某些情况下还是需要的(比如关系户来了,不在挂号大厅挂号,护士直接排队;
或者70岁以上老人免挂号)。
此时最大的不同,在于挂号时自动进入排队队列,数据库无法触发护士端程序更新排队信息,也无法触发TQS发消息给CS(CS转发给播放器、更新排队显示)。
我们可要求挂号程序给TQS序发消息(增加排队节点),TQS收到消息后,发消息护士端程序(读取新增排队者信息、更新界面中排队信息),发消息给CS(CS转发给播放器、更新排队显示)。
如果这个要求没法满足(HIS厂家不愿意提供),那么在这个应用场景下,我们必须设计一个机制来感知通过挂号新增的排队者信息。
不仅要感知新增信息,还要知道新增信息在排队队列中的顺序。
模式二中的要点:
排队顺序机制、如何感知通过挂号新增的排队信息及顺序。
挂号扫描程序
1.本质上挂号信息不是直接进入排队表,而是保存在接口表(接口文件)中
2.导诊这边会编写接口程序,扫描接口表(接口文件)中的信息,将挂号信息转交TQS处理(写入排队表)
3.对于已被TQS成功处理(写入排队表)的挂号信息,会改变接口表中的标志或从接口文件中删除,这样再次扫描时不会读取已经处理的信息
那么有几个问题需要考虑:
1.读取数据表:
数据表需要设置大科室、排队队列ID之类的列,并为每个点的扫描程序定义deptid=12ordeptid=16或queueid=16orqueueid=17之类的条件
2.读取数据文件:
如何确定文件名、文件格式
仅一个文件:
文件名确定,但可能多个扫描程序扫描一个文件,存在读写效率、读写冲突等问题
多个文件:
按照什么模式规划文件及命名?
若按照大科室,那么对于一个点的扫描程序扫描一个或多个科室的排队队列比较合适,但需要定义每个点的扫描程序对应的多个文件名(直接或间接);
按照排队队列,那么需要为每个点的扫描程序定义多个队列文件名(直接或间接),一旦队列个数发生变化,就需要维护这个定义
文件格式:
…
3.需要考虑是否可直接呼叫的配置
⏹关于预约挂号
预约挂号可采用与挂号类似的方式:
编写预约挂号扫描程序,按照一定的规则将相应挂号信息转入排队队列。
⏹关于患者所处的阶段(状态)
这里所说的阶段,主要是患者在排队表中的状态;
状态的改变,涉及屏幕显示的变化。
以挂号、首次等候、二次等候、就诊(从患者角度)为例;
以下的步骤实际上是从导诊系统的操作角度来说明的。
1.挂号:
信息进入挂号表。
2.挂号扫描:
挂号扫描程序进行扫描,将患者信息转入排队表,并设置其状态为首次等候状态。
患者进入首次等候状态。
需要在首次等候区的屏幕上显示该患者信息。
3.分流呼叫:
此时患者退出首次等候状态,进入二次等候状态
退出首次等候状态:
需要在首次等候区的屏幕上删除该患者的排队信息、更新叫号列表信息、弹出呼叫提示、进行语音播报(蓝色部分也可算到进入二次等候状态的动作)
进入二次等候状态:
需要在二次等候区的屏幕上显示该患者信息
4.就诊呼叫(顺呼):
此时上一位患者退出就诊状态,进入完成状态;
下一位患者退出二次等候状态,进入就诊状态
退出就诊状态:
患者信息从屏幕的就诊去消失
退出二次等候状态:
需要在二次等候区的屏幕上删除该患者的排队信息、弹出呼叫提示、进行语音播报(蓝色部分也可算到进入就诊状态的动作)
进入就诊状态:
显示就诊信息
从上述说明中可看出,从系统角度的一个事件的触发,可能涉及对于患者的一个状态的退出,另一状态的进入。
或者我们可以把一个状态的退出、另一个状态的进入看做是状态的变更。
从程序设计的角度,我们可考虑两种方式:
1.设计每个状态的进入功能、退出功能,这些功能被合理的触发
优点:
从状态的角度看,很清晰;
当状态个数、状态间的逻辑关系不可预知时,程序组织比较方便
缺点:
编程难度大?
2.从操作事件角度出发,设计操作事件所涉及的所有功能
当状态个数、状态间的逻辑关系都已知时,可减少编程难度?
若状态个数、不可预知时,程序的重组很费劲
就目前的情况看来,即使考虑到分诊模式(一次分诊/二次分诊)、是否允许直接呼叫、一次呼叫/两次呼叫等模式,患者在各种模式下的状态个数及顺序是可知的,因此可采用第二种处理方式。
不过若第一种方式从程序角度来说并不难的话,应采用第一种方式。
不管如何,暂且为患者设置几种状态:
1.排队(未指定队列)
2.等候分流呼叫(排队、已指定队列、可直接呼叫)
3.等候就诊呼叫(排队、已指定队列、可直接呼叫)
4.就诊
5.结束
排队、已指定队列、不能直接呼叫这个状态不怎么需要
是用一个字段表示状态,还是用多个字段组合表示状态?
需要仔细琢磨。
⏹功能分布图一:
每个科室有独立的挂号扫描程序、TQS
医生端使用软件时,会有直接读写数据库的功能。
建议使用这种配置,其优点是:
1.各科室挂号扫描程序、TQS独立运行,一个科室程序故障不会影响其它科室的正常运行;
对于业务较少的多个科室,可集中使用一套(挂号扫描程序、TQS、护士台程序);
不建议一个科室使用两套(此时可从逻辑上设计两个科室)
2.每个挂号扫描程序、TQS工作量相对较小,不易导致响应延时
3.每个TQS处理不同的队列,队列的ViewID、顺序号应不会冲突
在这种配置下,必须注意的事项如下:
1.每个挂号扫描程序必须设置属性:
数据权限:
读取哪些队列(或用其它方式)的挂号记录
目标TQS:
读取记录后,发送给哪个TQS
2.每个TQS也必须设置属性:
读写哪些队列(或用其它方式)的排队记录,与对应的挂号扫描程序类似
信息目标:
包括护士端程序、CS、LED控制程序、TTS控制程序等;
若TQS是被其它程序连接,只需要为其它程序设置好自己对应的TQS即可
3.护士端程序:
读写哪些队列(或用其它方式)的排队记录,与对应的TQS程序类似
TQS:
设置对应的TQS
4.医生端程序:
设置对应的TQS
⏹功能分布图二:
整个医院只有一个挂号扫描程序、一个TQS
不建议使用这种配置,缺点很多:
1.挂号扫描程序、TQS只有一套,一旦出现故障,所有科室的业务均无法正常运行
2.挂号扫描程序、TQS负担较大,易导致响应延时
3.TQS逻辑复杂:
必须能区分每个科室对应的队列,能将不同科室的信息发送到对应科室的护士台、CS、LED控制程序、TTS控制程序
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 导诊 功能 分析