第一篇:导诊--功能点分析
导诊—功能点分析
在以下的描述中,暂不考虑医生的身份(普诊、专家)变化、登陆点变化、信息去向的多样化等因素,仅从功能点的角度来描述,以期简单明了地说明问题;若糅合多个因素,将会导致说明复杂化,不容易说明清楚。
模式一:护士排队、医生一次呼叫
这是最简单的应用场景: 1.挂号不直接进入候诊排队队列
2.患者到达护士台后,由护士操作,将患者排进候诊排队队列 3.医生呼叫患者,患者直接进入对应诊室(诊台)就诊
在这个应用场景下,需要以下几个功能点: 1.护士端排队程序
患者信息:由患者提供,或从HIS获取,或从非HIS挂号表(比如我们或第三方做的挂号程序对应的表)获取
可能操作:在一个排队队列中增加、修改、删除排队者,将一个排队者从一个队列转移到另一个队列,清空队列,信息同步等。具体说明如下:
增加:在队首、队尾或指定位置增加一个排队者;结果:排队表中增加一条信息,护士端界面的某个队列的尾部、首部或指定位置增加一条信息,信息发布屏幕上某个队列中的相应位置增加一条信息
修改:修改一个排队者的信息;结果:排队表中对应记录的信息被修改,护士端界面的某个队列的显示信息被修改(可能只是一条信息改变、也可能排队顺序改变),信息发布屏幕上某个队列的显示信息被修改(可能只是一条信息改变、也可能排队顺序改变)
删除:删除一个排队者的信息;结果:排队表中对应记录被删除,护士端界面一个队列的对应节点被删除,信息发布屏幕上一个队列的对应节点被删除
转移:将一个排队者从一个队列转移到另一个队列;结果:排队表中对应记录的信息被修改(排队队列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,也不符合按照优先级+编号排序的规则
还有其它很多情况会导致显示顺序不符合按照优先级+编号排序的规则
是否绝对不会出现红色文字描述的情况?
不会:可采取优先级+编号排序的规则来处理护士端界面、信息发布屏幕的显示;若需要刷新界面,只需要在读取排队信息时增加用优先级+编号的order by字句即可
会:此时无法依赖优先级+编号来确定显示顺序,只能用一个顺序字段来确定显示顺序,这个字段的值需要有一个良好的策略来维护。
钟小明:信息显示是按照优先级+顺序号排序的。
根据这个规则,从排队表中读取信息时,增加用优先级+顺序号的oerder by子句即可。
关于顺序号字段,应注意以下事项:
顺序号应以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将更新排队表中对应记录;若成功,则发消息至护士端程序,并发消息至CS
删除:护士端程序提供排队者信息,TQS将从排队表中删除对应记录;若成功,则发消息至护士端程序,并发消息至CS
转移:护士端程序提供排队者信息及目标队列信息,TQS修改排队表中对应记录的信息;若成功,则发消息至护士端程序,并发消息至CS(两条消息)
清空:护士端提供队列ID,TQS从排队表中删除该队列的所有记录;若成功,则发消息至护士端程序,并发消息至CS
同步:护士端程序提供命令(是否需要制定仅同步某个播放器?),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=12 or deptid=16或queueid=16 or queueid=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控制程序
第二篇:APP测试功能点总结
APP测试功能点总结
1.功能性测试:
——根据产品需求文档编写测试用例。
——软件设计文档编写用例。
注意:就是根据产品需求文档编写测试用例而进行测试。
2.兼容性测试:
——android版本的兼容性
——手机分辨率兼容性
——网络的兼容性:2G3G4GWIFI,弱网下、断网时
——app跨版本的兼容性
1.适配性测试:
1>.手机不同分辨率支持:客户端支持的分辨率等
2>.手机不同版本的支持:2.34.04.4等;在测试计划中:需要安排单独的时间用于android不同系统的兼容性测试,包括2.0以下版本和4.0以上等
3>.手机不同厂家系统的支持:不同厂家会有不同android系统,例如:小米,华为,锤子对市面上主流手机的支持
4>.手机不同尺寸的支持:3.5到5.0屏幕在UI显示有区别,要支持最大到最小。
2.安装、卸载测试:
1>.生成apk文件在真机上可以安装及卸载;
2>.Android手机端通用安装工具。如:豌豆荚
3.在线升级测试:
1>.验证数字签名
2>.升级后可以正常使用。
3>.在线跨版本升级。
3.性能测试:
——压力测试:
——电量流量测试:
——cup、内存消耗:
——app启动时长
——crash率
——内存泄漏
4.网络测试:
1.外网测试主要现实模拟客户使用网络环境,检验客户单程序在实际网若环境中使用情况及进行业务操作。
2.外网测试主要覆盖到wifi2G3G4G,.netwap、电信移动联通、所有可能的组合进行测试。
原则:
1.尽可能全面覆盖用户的使用场景,测试用例中需要包含不同网络排列组合的各种可能。
2.还有模拟信号被屏蔽时候。客户端的影响等。还有做外包场景测试,在高山、丘陵、火车上等特殊环境下进行全面测试
5.接口性测试:
——client端和service端的交互
——client端的数据更新和service端的数据是否一致
——client端更新时断开了。
——client端更新时service端挂了。
6.业务逻辑测试:
1.业务逻辑测试:主要测试客户端业务能否正常完成。
2.功能点测试:主要测试客户端功能点是否正常使用
3.关联性测试:主要测试客户端与pc端的交互,客户端处理完后,pc端与客户端数据一致
7.异常测试:
1.交互异常性测试:客户端作为手机特性测试,包括被打扰的情况;如来电、来短信、低电量测试等,还要注意手机端硬件上,如:待机,插拔数据线、耳机等操作不会影响客户端。
2.异常性测试:主要包含了断网、断电、服务器异常等情况下,客户端能否正常处理,保证数据正确性。
客户端侧性能测试:
1.基准性能测试:主要通过压服务器端接口及客户端在不同网络环境下响应速度。
2.大数量的测试:主要在特定环境下,客户端一次性更新大量的数据及人员列表时,客户端能否正常处理,分为三种情况:
——客户端第一次使用,第一次就更新大量数据及人员列表。
——客户端在平时更新中,更新大量的数据
——客户端已经在手机本地下载很多数据后,再次更新大量
如果想要在测试方面获得进一步的提升,那么你就需要学会使用App测试工具。一方面,通过测试工具可以代替你做重复繁琐的部分工作,你节省出的是更多的学习时间,另一方面,这些工具还会为你提供大量的游戏运行数据和日志,有了这些数据你就能更方便的判断问题发生的原因,这写数据的解读能力将是你未来的最大竞争力。
第三篇:导诊便民措施
镇平县人民医院
导诊就医台便民服务措施
1、免费轮椅服务。
2、免费测血压、测体温。
3、为老、弱、残及危重患者提供全程导医服务。
4、免费小件物品寄存。
5、健康指导服务,免费发放健康教育处方。
6、失物招领,并负责电话联系。
7、提供针线包、老花镜、笔、纸。
8、免费为患者提供咨询,帮助患者选择医生。
9、免费提供开水。
第四篇:导诊工作制度
导诊工作制度
1、面带微笑,规范站姿,热情礼貌,耐心回答患者询问,正确引患者各科就诊。
2、随时观察门诊大厅及门口的人流动态,主动搀扶年老体弱的患者,为行动不便的患者提供轮椅、协助挂号、必要时协助就诊、取药、检查等。
3、勤动口勤动手,维持大厅门诊的良好秩序。
4、导医每日提前10分钟到岗,统一着导医服装,保持衣帽整齐,佩带胸卡。
5、病人进入大厅后:一张笑脸,一声问候,一份热情,引导病人挂号。
6、挂号分诊:站立式服务,询问病人挂号情况,做好初、复诊病人的登记工作,患者无特殊要求,根据病情按科室及相关规定分诊。
7、流动班:走动式服务,负责将病人带到医生诊室,询问病情介绍医生特长,协助病人交费,辅助病人做检查,取药,等全程优质服务。
8、遵守医院规章制度,按时上下班,不迟到,不早退。
9、导医的:“九不准”
不准吃零食、干私事。
不准闲聊、打闹、高声喧哗。
不准看书、看报、看电视、玩手机、玩游戏。
不准约会私人客人。
不准对病人不理不睬。
不准索取病人取礼物。
不准与病人顶撞吵架。
不准擅自离岗串岗。
不准迟到早退。
10、分诊导医每日负责所辖区域内一切物品的清洁卫生
11、对危重抢救患者及特殊情况病员,导医尽快送到相关科室就诊,协助医生护士做好抢救工作,对行走不方便病人上前搀扶。
12、科室要有团队精神,团结之心,相互帮助每日必需完成自己的工作,交接班要清楚。科室分配任务不得推辞,服从领导安排。
科左中旗人民医院护理部
第五篇:导诊工作制度
导医工作职责
1、面带微笑,规范站姿,热情礼貌,耐心回答患者询问,正确引患者各科就诊。
2、随时观察门诊大厅及门口的人流动态,主动搀扶年老体弱的患者,为行动不便的患者提供轮椅、协助挂号、必要时协助就诊、取药、检查等。
3、勤动口勤动手,维持大厅门诊的良好秩序。
4、导医每日7:20到岗,统一着导医服装,保持衣帽整齐,佩带胸卡。
5、病人进入大厅后:一张笑脸,一声问候,一份热情,引导病人挂号。
6、挂号分诊:站立式服务,询问病人挂号情况,做好初、复诊病人的登记忆工作,患者无特殊要求,根据病情按科室及相关规定分诊。
7、流动班:走动式服务,负责将病人带到医生诊室,询问病情介绍医生特长,协助病人交费,辅助病人做检查,取药,等全程优质服务。
8、遵守医院规章制度,按时上下班,不迟到,不早退。
9、导医的:“十不准” 不准吃零食、干私事; 不准闲聊、打闹、高声喧哗;
不准看书、看报、看电视、玩手机、玩游戏。不准约会私人客人; 不准对病人不理不睬; 不准索取病人取礼物; 不准与病人顶撞吵架; 不准擅自离岗串岗; 不准迟到早退;
10、分诊导医每日负责所辖区域内一切物品的清洁卫生
11、对危重抢救患者及特殊情况病员,导医尽快送到相关科室就诊,协助医生护士做好抢救工作,对行走不方便病人上前搀扶。
12、科室要有团队精神,团结之心,相互帮助每日必需完成自己的工作,交接班要清楚。科室分配任务不得推辞,服从领导安排。