1、导诊信息及去向分析导诊的每个业务，可产生多条信息；每条信息的目的地可只有一个，也可有多个。由于医生的身份、坐诊诊室（诊台）是可变的，其对应队列的信息目标也是动态的。基于以上原因，信息及去向就成了导诊系统必须重点考虑的问题。 业务信息每个业务均会产生一条或多条信息，具体说明如下：业务 信息挂号扫描 排队队列（每条记录增加一个节点），包括普通挂号扫描、预约挂号扫描排队增加 排队队列（增加一个节点）若有二次等候，则护士可选择进入一次等候队列还是二次等候队列（直接进入二次等候队列的，一般属于关系户）排队修改 排队队列（修改一个节点，或删除+增加、涉及两个队列）排队删除 排队队列（删除一个节点）排队转移
2、 排队队列（删除+增加、涉及两个队列）排队清空 排队队列（清空一个队列）顺呼 排队队列（删除一个节点）叫号列表或表格（增加或修改一个节点）弹出提示（LCD 屏），可能大屏、联动小屏均需要LED 叫号信息（用于诊室门楣）TTS 叫号语音复呼 弹出提示（LCD 屏），可能大屏、联动小屏均需要TTS 叫号语音首次呼叫 用于有二次呼叫（二次分诊）的情况首次排队队列（删除若干节点）二次排队队列（增加若干节点）每个业务能产生的信息是可以确定的，但实际应用中用到哪些信息，应根据用户需要来确定，尽管我们可推荐一些模式。 信息去向（多个）一个信息的去向可能不只一个，实际情况各种各样，仅举例如下：1. 排队信息：
3、同一队列的排队信息可能需要在多个屏上同时显示，但是这多个屏的其它内容不同。例如有二次等候区的，三个诊室属于一个小科室，每个诊室都有普诊，那么可能要在每个屏上都显示普诊公共队列2. 弹出提示：同上3. 叫号信息：我们不能默认叫号信息必须与排队信息在一个屏上显示，我们完全可设置两个屏，一个只显示排队，一个只显示叫号对于因人数较多，一个屏幕不能顾及所有等候者，用两个屏幕显示，但两个屏幕由一个播放器支持的情况，我们仍然视为一个点位，与上述的“一个信息的去向可能不只一个”这个问题无关。 信息去向（动态）由于医生身份、坐诊诊室（诊台）的可变性，导致业务触发的信息的目标位置是动态的，请参见导诊候诊队列分析。
4、 信息去向其它因素由于一个屏幕可分块显示内容，在同一块中还可能需要区分位置（比如需要指定排队队列对应显示队列的 listid），因此在信息去向中还需定义而外的参数。可能的参数如下： BizType：播放器程序用于区分块的核心参数是 BizType（每一块的 BizType不能相同，除非没有实时业务信息交互，无需区分 BizType）；对于LED、TTS 控制程序，BizType 可设置为 0 其它参数：对于排队队列，需要制定其对应显示队列的 listid 以上因素与分屏设计有紧密关系。 如何定义由于以上原因，需要有良好的设计，来定义排队队列、信息、触发位置、信息目标位置之间的逻辑关系。影响信息
5、去向的因素包括：排队队列、操作、信息、触发位置。这里的考虑以排队队列、信息为核心，触发位置的设备类型不是重点（因为每个触发位置的业务是已知的，其产生的信息也是已知的，无需考虑其设备类型）。最简单直观的方式是：排队队列-触发位置- 操作- 信息- 信息目标位置。以上定义中，若信息是排队队列，则还需要定义显示队列 ID；若信息是就诊信息，则可能需要定义其它辅助参数（比如多个医生的就诊信息使用一个块显示）。解释是：对于一个排队队列的每个信息，在某个位置触发时，其目标位置是什么（可多个），即由前三个参数确定最后一个参数（可多个）。应该增加以下参数： 业务：每个信息所属的业务，比如在诊台，排队信息属于叫
6、号业务 顺序：每个业务产生的多条信息，需要定义发送顺序 格式：信息格式，格式和次数属于目标位置，不可能为同一目标位置定义不同的格式和次数 次数：信息显示（播报）次数我们可将所有的可能性都定义在一个表中，这里的可能性指的是实际上的可能性，比如医生端不可能做排队业务，因此无需为诊台定义排队业务信息的目标位置。这种方式应该能定义出一切的可能性。队列 触发点位 操作 信息 目标点位 附加参数 信息格式 次数血液普诊 护士台 排队 601 大屏 2 listid添加 /修改 /删除ViewID姓名 11 诊室 1 台 叫号 601 大屏 2 listid、删除602 大屏 2 更新 请 到 就诊 170
7、1 TTS26 请 到 就诊 1501 1 诊外小屏 假设 501对应的是1 台对应的显示块大夫姓名、患者姓名 11 诊室 2 台 叫号 601 大屏 2 listid、删除602 大屏 2 更新 请 到 就诊 1701 TTS26 请 到 就诊 1502 1 诊外小屏 假设 502对应的是2 台对应的显示块大夫姓名、患者姓名 1注意： 操作：比如排队，叫号 信息：对应到 BizType 附加参数：比如对于队列，需要给定 listid，同时还有增加 /修改/删除标志等使用上述定义后，每个业务点的功能是否可行？回答：是。 挂号扫描程序的位置是确定的，其扫描的信息中包括排队队列 ID，用上述原则可
8、找到信息的目标位置（可多个） 对于一个排队队列来说，护士台的位置是确定的（不考虑一个排队队列可由两个护士台操作的情况），用上述原则可找到信息的目标位置（可多个） 医生登录时确定触发位置（坐诊位置）、排队队列（可根据身份确定），用上述原则可找到信息的目标位置（可多个）这个方式虽然简单明了，但其缺点也显而易见：如果排队队列多、诊室（诊台）多，目标位置也多，那么其定义记录条数将很多，且只要队列、诊室（诊台）、有变化，必须手工维护该表。可变通的方式是：0 表示所有。例如：26（排队队列 ID）101（排队）-0（所有触发位置）-13（目标位置），即 26 号排队队列的排队信息，不管在哪个位置触发，均发
9、送到 13 号目标位置。不过这样也会增加难度：所有与特定的结合。例如，对于一个规模不大的科室，只有为数不多的诊室、医生，一个大屏、一个TTS、多个小屏（小屏只显示就诊信息）：00013 所有排队队列的所有信息，不管在哪里触发，均发往 13 号目标（有播放器控制的大屏；可能播放器没有 TTS， TTS 信息发了播放器也会丢弃）0102015 所有排队队列的 TTS 信息，不管在哪里触发，均发往 15 号目标0105116 所有排队队列的就诊信息，在 1 号位置触发，发往 16 号目标（大小屏联动的小屏）不建议使用 0 参数方式：我们既要考虑定义的合理性，也要考虑编程的合理性。若 0 参数不影响编
10、程的合理性，则可使用。希望设计好信息目标之后，根据触发点位、队列、操作，用一个 SQL 语句就能检索出所有信息目标（即多条记录），根据每一条记录的数据来生成、发送信息。若加上多个科室的因素，必须在前边增加科室 ID（可能是大科室，也可能是小科室，或大、小科室均要）定义因子。 信息格式从目前已知的情况来看，主要有以下信息需要定义格式： 排队信息：可能的格式是 ViewID + 姓名 ViewID 姓名注意事项： 对于多个按姓名出现的专家排队队列共用同一个显示队列的，应在以上信息前面增加专家姓名-之类的信息 急诊的，尾部增加(急)；指定医生的，尾部增加()； 叫号信息：可能的格式是 请 ViewI
11、D 姓名 到 诊室( 诊台) 就诊 ViewID 姓名 请到 诊室 (诊台) 就诊 ViewID 姓名 诊室 (诊台)可仅用 ViewID 或姓名诊室(诊台 )的可能情况为：某诊室、某诊台、某诊室某诊台对于首次呼叫的，可设定每次显示的最多人数（比如三人），可能的格式如下 可确定诊室的：比如以姓名出现的专家，其坐诊诊室是确定的，格式为请 ViewID1姓名 1、 ViewID2姓名 2、 ViewID3姓名 3 到 某诊室门外 就诊ViewID1姓名 1、 ViewID2姓名 2、 ViewID3姓名 3 请到 某诊室门外 就诊ViewID1 姓名 1、ViewID2 姓名 2、ViewID3
12、姓名 3 某诊室门外 不能确定诊室的：比如一个科室有几个诊室，多个医生服务于普诊队列，格式为请 ViewID1 姓名 1、ViewID2 姓名 2、ViewID3 姓名 3 到 某候诊区 就诊ViewID1 姓名 1、ViewID2 姓名 2、ViewID3 姓名 3 请到 某候诊区 就诊ViewID1 姓名 1、ViewID2 姓名 2、ViewID3 姓名 3 某候诊区 TTS： 请 ViewID 姓名 到 诊室( 诊台) 就诊 ViewID 姓名 请到 诊室 (诊台) 就诊可仅用 ViewID 或姓名，且可重复多遍（比如：请 A001 王茂杰，A001 王茂杰 到 1 诊室 2 诊台 就
13、诊）诊室(诊台 )的可能情况为：某诊室、某诊台、某诊室某诊台对于首次呼叫的，可设定每次显示的最多人数（比如三人），可能的格式如下 可确定诊室的：比如以姓名出现的专家，其坐诊诊室是确定的，格式为请 ViewID1姓名 1、 ViewID2姓名 2、 ViewID3姓名 3 到 某诊室门外 就诊ViewID1姓名 1、 ViewID2姓名 2、 ViewID3姓名 3 请到 某诊室门外 就诊 不能确定诊室的：比如一个科室有几个诊室，多个医生服务于普诊队列，格式为请 ViewID1 姓名 1、ViewID2 姓名 2、ViewID3 姓名 3 到 某候诊区 就诊ViewID1 姓名 1、ViewID2 姓名 2、ViewID3 姓名 3 请到 某候诊区 就诊每个语音播报之前，可增加一个提示铃音，应根据实际应用环境和医院喜好确定是否用、用什么提示铃音。
