用于紧急调度的中风诊断和干预工具的制作方法

专利名称：用于紧急调度的中风诊断和干预工具的制作方法
技术领域：
本发明涉及用于提供医疗方案询问、指令和紧急调度的计算机系统和方法。更具体地，本发明针对用来在询问和指示紧急呼叫者期间协助调度员的计算机实现的工具。


参考附图描述了本公开的非限制和非穷尽实施例，包括本公开的各种实施例，在附图中图1是根据一个实施例的紧急调度系统的框图；图2图示了根据一个实施例的紧急医疗调度方案的用户界面；以及图3A-3F图示了中风识别工具的用户界面；图4是中风识别工具的方案向调度员提供指令和问题的流程图；图5是中风识别工具的特定方案500的流程图；以及图6A-6D是中风识别工具识别患者是否已患有中风的流程图。
具体实施例方式紧急调度员处理报告各种各样的紧急情况的紧急呼叫。在计算机上潜在实现的自动紧急调度系统可以辅助调度员对呼叫确定优先级并且对呼叫进行处理以生成恰当的紧急调度响应。尽管存在可能随呼叫的不同而报告的多样化的紧急情况方面，除其他外，包括体征、症状、状况和环境，不考虑调度员的经验或技能水平，自动紧急调度系统可以启用一致和可预见的紧急调度响应。尽管自动紧急调度系统可以启用大相径庭的紧急情况方面的收集和处理，但是所报告的紧急情况和/或方面中的一些应当在其被报告时被更深入地探究。该进一步探究可能需要调度员更深入地探查以采集更多的描述性细节。此外，一些紧急情况可以由更详细的指令来改善。另外其他紧急情况可能涉及不容易被诊断的状况的临床表现，但是其如果被恰当诊断则可能更改适当的调度响应。具有很少或没有医疗训练或经验的调度员很可能不能适当地探究情况和/或方面或诊断医疗状况，更不用说指令呼叫者那样做。此外，自动紧急调度系统没有被配备成协助或使调度员能够更深入地探究情况，以提供进一步指令，也不能诊断状况。因此，本公开针对以下的诊断工具，该诊断工具对自动紧急调度系统进行补充以试图解决自动紧急调度系统的这些和其他缺点。
参考附图将最佳理解本公开的实施例，其中自始至终相同的部分由相同的数字标明。将容易理解的是，如在此在附图中一般描述和图示的、所公开的实施例的组件能够在各种各样的不同配置中来布置和设计。因此，本公开的系统和方法的实施例的下面的详细描述并不意在限制如所要求的本公开的范围，而是仅仅表示本公开的可能实施例。另外，除非另外明确说明，方法的步骤并不一定需要以任何特定顺序乃至依次地来执行，步骤也不必仅执行一次。在一些情况下，没有详细示出或描述众所周知的特征、结构或操作。此外，所描述的特征、结构或操作可以以任何适当的方式被组合成一个或多个实施例。还将容易理解的是，如在此在附图中一般描述和图示的实施例的组件可以在各种各样的不同配置中来布置和设计。所描述的实施例的若干方面将作为软件模块或组件来说明。如在此所使用的，软件模块或组件可以包括位于存储器设备和/或计算机可读存储介质内的任何类型的计算机指令或计算机可执行代码。例如，软件模块可以包括一个或多个计算机指令的物理或逻辑块，其可以被组织为执行一个或多个任务或实现特定抽象数据类型的例程、程序、对象、 组件、数据结构等。在某些实施例中，特定软件模块可以包括存储在存储器设备的不同位置中的不同指令，其一起实现所描述的模块的功能。确实，模块可以包括单个指令或许多指令，以及可以在若干不同的代码段上、在不同程序当中以及跨若干存储器设备分布。一些实施例可以在分布式计算环境中实施，其中任务由通过通信网络链接的远程处理设备来执行。在分布式计算环境中，软件模块可以位于本地和/或远程存储器存储设备中。另外，在数据库记录中被捆绑或呈现在一起的数据可以驻留于同一存储器设备中或跨若干存储器设备驻留，以及可以跨网络在数据库中的记录的字段中被链接在一起。协助实现本发明的适当软件由相关领域的技术人员使用在此提供的教导以及诸如Java、Pascal, C++、C、数据库语言、API、SDK、汇编、固件、微代码和/或其他语言和工具的编程语言和工具来容易地提供。适当的信号格式可以以模拟或数字形式具体化，带有或不带错误检测和/或校正比特、分组头部、特定格式的网络地址、和/或相关领域的技术人员容易提供的其他支持数据。如在此公开的紧急调度系统可以全部或部分在数字计算机上计算机实现。数字计算机包括执行所需的计算的处理器。计算机进一步包括与处理器电子通信、用于存储计算机操作系统的存储器。计算机操作系统可以包括MS-DOS、Windows、Unix、AIX、CLIX、QNX, OS/2以及Apple。替选地，预期的是，未来的实施例将适于在其他未来的操作系统上执行。 存储器还存储应用程序，包括计算机辅助调度(CAD)程序、自动紧急调度方案、用户接口程序；以及数据存储。计算机可以进一步包括用于查看所显示的指令和问询的输出设备，诸如显示单元，以及用于输入响应数据的用户输入设备。图1是根据一个实施例的紧急调度系统100。在调度中心102处，调度员104操作计算机106。计算机可以包括用来存储方案、模块、工具、数据等的存储器107。计算机可以被配置成执行紧急医疗调度方案108来使调度员能够迅速和一致地应对如呼叫者118所报告的患者117的医疗紧急事件。紧急医疗调度方案108提供具有来自呼叫者118的问题、 可能响应和对呼叫者118的指令的逻辑树。响应可以路由到对呼叫者的随后问题和/或指令。响应根据预定的逻辑被处理以(例如，由受过训练的紧急响应者)向调度员104提供正确的紧急医疗调度响应和适当的医生核准的调度后的指令以在专业帮助到达现场之前向呼叫者118转达两者。紧急医疗调度系统100还可以辅助调度员确定紧急呼叫的适当优先级，包括但不限于该紧急呼叫相对于其他紧急呼叫的优先级。尽管在此公开并描述了紧急医疗调度系统100和紧急医疗调度方案108，但是普通技术人员可以理解的是，其他紧急调度系统和紧急调度方案也是预期的，包括但不限于紧急火灾调度系统和方案以及紧急警方调度系统和方案。在美国专利No. 5，857，966、 5，989，187,6，004，266,6，010，451,6，053，864,6，076，065,6，078，894,6，106，459, 6，607，481,7, 106，835和7，428，301中公开了这样的紧急调度系统和方案的示例性实施例，通过引用的方式将其合并于此。计算机106还可以操作决定性值计算器110以从呼叫者118对方案问题的响应来计算决定性值。计算机106提供决定性值以生成适当的紧急调度响应和/或建立紧急呼叫的优先级。响应可以包括将专业紧急响应者调度到紧急事件的现场。因为所问的问题和提供的建议直接涉及生死抉择，所以所使用的方案应当通过专攻急诊医学的医生和EMS公共安全专家小组的严格医学审查。决定性值计算器110可以被存储在计算机的存储器107上。要求医疗服务的许多呼叫并不是真正的医疗紧急事件，因此重要的是，以若干方式对呼叫确定优先级。首先，是真正的紧急事件的呼叫应当被最先调度。其次，如果机构有具有不同能力的单位，则更高级的单位应当被派遣给更严重的医疗问题。以及最后，如果从医疗立场，警灯和警报器是不需要的，则其应当不被使用，从而增加在路上和在急救车辆中的所有那些的安全性。虽然许多医疗呼叫不是真正的紧急事件，但是所有情况都可以从医疗评估和指令受益。在专业帮助到达现场之前，紧急医疗调度方案108向调度员104提供对呼叫者118的适于呼叫的类型，从具有轻微割伤的患者117到没有呼吸的患者117的指令。决定性值提供了事件的类型和级别的分类代码。该代码可以被提供给计算机辅助调度(CAD)系统112，CAD系统112是调度员104用来跟踪并分配紧急响应资源、用于进行处理的工具。CAD系统112可以全部或部分在与计算机106通信的独立计算机上操作。在另一个实施例中，CAD系统112在计算机106上操作。CAD系统112所使用的主要信息是事件和单位两者的位置信息、单位可用性以及事件的类型。CAD系统112可以使用用于使定位和可用性任务自动化的第三方解决方案，诸如E-911、车辆位置应答器和MDT。计算机106还可以包括报告模块114，其用来统计上地测量个体工作人员的绩效和调度中心102的整体绩效。这些统计包括达标率、呼叫处理统计和同级测量。报告模块 114可以被存储在计算机106的存储器107上。计算机106可以进一步包括输入设备，诸如键盘、鼠标或其他输入设备，以及还包括输出设备，诸如显示监视器。输入设备从用户(通常调度员)接收输入，并且将其提供给紧急医疗调度系统100。该输入可以被提供给计算机106、紧急方案108、诊断工具120和/ 或CAD系统112。输出设备从紧急医疗调度系统100接收输出，并且向用户显示或另外呈现该输出。在另一个实施例中，输入设备和输出设备由CAD系统112提供。在又一个实施例中，CAD系统112在计算机106上运行。调度中心102包括用来应答紧急呼叫的电话设备116。从呼叫者118进入调度中心102的呼叫发起对医疗呼叫事件的创建。调度员104将该呼叫识别为要求紧急医疗调度， 并且紧急医疗调度方案108被访问。方案108可以提供被熟练抽调来协助新手呼叫者118 诊断患者117的状况的指令。方案108还可以提供熟练抽调的第一辅助指令来在受过训练的紧急响应者到达之前协助患者117。指令可以由调度员104通过电话设备116用口头转达给呼叫者118。一些方案问题可以由呼叫者118容易地回答，而其他的更难以回答。某些诊断问询对未受训练的呼叫者来说可能很难确定或在紧急情况的压力下可能很难回答。因此，除指令之外，紧急医疗调度系统100可以提供一个或多个计算机实现的诊断工具120。诊断工具120可以极大地改善对紧急医疗响应情况的信息收集和干预以及辅助挽救生命。诊断工具120可以(经由来自调度员的指令)辅助调度员和/或呼叫者诊断患者 104的状况。诊断工具120还可以是干预工具，其提供指引呼叫者干预、或采取措施来治疗患者104，或另外改变紧急情况的环境或状况的指令。为清晰起见，诊断工具和干预工具两者在此一般被称为诊断工具。因此，如在此所提及的诊断工具120可以提供诊断指令、干预指令或诊断和干预指令两者。无论诊断工具120仅仅提供诊断指令、仅仅提供干预指令还是提供诊断和干预指令两者，诊断工具都可以为特定紧急情况提供一致和可靠的指令、信息采集和/或定时。诊断工具120是计算机实现的软件模块，其使调度员104能够关于诸如确定生命体征的紧急情况的特定方面提供一致、专家的建议来协助呼叫者。诊断工具120的一个益处是确定生命体征的计算机辅助定时技术。在高度紧张的状况下，诊断工具120将必需资源提供给读取关键性体征。诊断工具120可以被存储在计算机106的存储器107中，并且视需要被起动并执行。诊断工具120可以被具体化为计算机可执行的软件应用和关联的数据。紧急医疗调度方案108可以访问诊断工具120以例如协助询问，以及可以在需要时路由到适当的诊断工具120。当根据紧急调度方案108指引时，紧急医疗调度系统100 可以自动地，即在没有调度员干预的情况下，起动调度中心计算机106上的适当诊断工具 120。这可以在紧急医疗调度方案108到达方案中的诊断步骤并且起动对应的诊断工具120 时发生。紧急调度系统100还可以给予调度员104如期望的手动访问诊断工具120的选项。图标和/或按钮可以在工具栏或用户界面上的其他便利的位置中显示，以允许调度员 104起动对应的诊断工具120。在另一个实施例中，紧急医疗调度方案108可以仅仅在需要时提示调度员启动中风识别工具122。在此论述的诊断工具120包括中风识别工具122。中风识别工具122被配置成协助调度员104指导呼叫者118诊断患者117是否已患有中风。紧急医疗调度方案108可以当接收到指示患者可能已患有中风的信息时自动直接路由到中风识别工具122。紧急医疗调度方案108还可以使调度员能够手动启动中风识别工具。参考例示某些实施例的图形用户界面的图论述了中风识别工具122。本领域技术人员将理解的是，这样的界面可以以各种方式来实现和设计，并且仍然在本发明的范围内。图2图示了根据一个实施例的紧急医疗调度方案的用户界面200。紧急医疗调度方案用户界面200允许调度员与紧急医疗调度方案对接。紧急医疗调度方案可以经由紧急医疗调度方案用户界面200呈现询问202，。询问202被提供，以供调度员指引呼叫者采集关于患者的医疗紧急事件的信息。调度员和/或紧急医疗调度系统可以以对询问202的呼叫者响应的形式来采集该信息。调度员可以将呼叫者对询问的响应输入到用户界面200所提供的响应域204中。响应域204可以包括例如熟悉的用户界面组件，包括但不限于文本域、文本框、菜单、下拉菜单、下拉选择框、列表、按钮、复选框和单选按钮。响应域204可以对应于指示呼叫者对询问202的一个或多个响应的信息。从呼叫者转达给调度员并且输入到系统中的呼叫者响应和其中的信息可以由紧急医疗方案用来确定向调度员呈现的随后询问202和指令。呼叫者响应和其中的信息可以指示呼叫者对患者的医疗状况的体征和症状的观察。从呼叫者响应采集到的信息可以由紧急医疗调度系统用来生成由受过训练的紧急响应者的紧急医疗调度响应。从呼叫者响应采集到的信息可以由决定性值计算器用来计算可以被通信给紧急响应者的决定性值。在较早引用的美国专利中可以找到紧急医疗调度方案和与紧急医疗调度方案交互的用户界面的进一步细节。紧急医疗调度方案用户界面200还可以提供一个或多个诊断工具启动输入206。 如所图示，一个或多个按钮可以在用户界面上被提供为诊断工具启动输入206。诊断工具启动输入206使调度员能够启动特定诊断工具。尽管紧急医疗调度方案可以基于指示呼叫者的一个或多个响应的调度员输入的输入来自动起动诊断工具，但是诊断工具启动输入206 为调度员提供了手动(即，任何时间，由调度员的自行决定)起动诊断工具的方式。在图2 中，提供了中风识别工具启动输入208。中风识别工具启动输入208可以包括在紧急医疗调度方案用户界面200上的具有其中嘴一侧下垂的脸部的图标的按钮。该图标可以指示该按钮启动中风识别工具。如普通技术人员将理解的，诊断工具启动输入206可以包括除按钮外的组件，包括熟悉的用户界面组件，诸如下拉菜单、下拉选择框、列表、复选框、文本域和单选按钮。图3A-3F图示了根据一个实施例的中风识别工具的用户界面300的实施例。所图示的实施例的用户界面300提供了指令302、304、306、308、开始输入310、问题312、314、 316、318、输入域320、322、324、完成输入326、建议域3 和关闭输入330。用户界面300辅助调度员指导呼叫者获取能够由中风识别工具用来诊断患者是否已患有中风的信息。指令 304、306、308、问题312、314、316和输入域320、322、3M可以被聚组成一个或多个脚本化交互(例如，至少一个指令、至少一个问题和至少一个输入域)。脚本化交互指导调度员指导呼叫者识别患者可能已患有中风的体征和症状。用户界面300可以进一步提供回答域334、 336,338,以显示与可能在每一个输入域320、322、324中选择的患者响应相对应的回答数字(即，调度员提供给用户界面的、与呼叫者对问题312、314、316的回答相对应以及还与患者对指令302、304、306、308的响应相对应的输入)。用户界面300还可以提供确认呼叫者的状态的一个或多个确认指令332和仅为调度员准备的作为与呼叫者交互的指导的一个或多个交互指令；340、；342、；344、；346。指令302、304、306、308可以指引调度员指导呼叫者。初始指令302可以指引调度员使呼叫者对随后诊断指令304、306、308和/或问题312、314、316、318做好准备。例如，初始指令 302 可以提供“I want you to get close enough to ask her/him three questions.(我想要你足够接近以询问她/他三个问题)”。初始指令302还可以使呼叫者做好准备以便于诊断患者是否可能已患有中风。确认指令332可以被提供，诸如“Tell mewhen you are ready (当你准备好时告诉我)”，以使调度员能够知道呼叫者何时对另外的诊断指令304、306、308做好准备。开始输入310可以被提供以激活中风识别工具的诊断功能。图3A图示了在开始输入310激活中风识别工具的诊断功能之前的用户界面300。在图3A的实施例中，开始输入310是按钮。开始输入310用术语“Ready (准备就绪)”标记，以直观方式向调度员指示当呼叫者对确认指令332作出呼叫者准备就绪的响应时调度员应当点击该按钮。在开始输入310被点击之前，用户界面300的组件可以是不活动的。例如，在所描绘的实施例中，输入域320、322、3M是变暗和/或变灰的(即，以较淡灰色而不是黑色或彩色显示，以指示其当前不能由用户操作)，因为其是不活动的。回答域334、336、338也是空白的，指示其是不活动的。本领域普通技术人员将理解的是，在开始输入310被点击之前，诸如诊断指令304、 306、308、完成输入326、建议域3 和关闭输入330的其他组件也可以是不活动的和/或变灰的。在开始输入310被点击之后，这些组件可以被激活。在另一个实施例中，这些组件可以在诊断工具的方案内的各种进展阶段被激活。所图示的实施例的输入域320、322、324作为单选按钮组被提供。如可以理解的， 输入域320、322、3M可以作为多种用户界面组件中的任何组件被提供，包括但不限于文本域、文本框、菜单、下拉菜单、下拉选择框、列表、按钮和复选框或其组合。在下面参考图 3C-3E更详细论述输入域。图;3B图示了在开始输入310已被点击以激活中风识别工具的诊断功能之后的用户界面300。在开始输入310被点击之后，输入域320、322、3M不再是变暗的，指示其被激活。回答域334、336、338现在也是活动的，并且示出回答数字“0”以指示尚未提供输入。一旦开始输入310已被点击，则也可以激活先前处于不活动状态的其他组件，诸如完成输入 3 和关闭输入330。以这种方式，能够以直观方式控制中风识别工具的方案的进展。直到呼叫者对诊断指令304、306、308做好准备为止，指导调度员等待。此外，通过在接收开始输入310之前提供处于不活动状态的输入域320、322、324、完成输入326以及关闭输入330， 用户界面300避免调度员非故意输入不是指示呼叫者对患者的观察的输入。提供对诊断工具的方案的进展的直观控制可以便于对紧急呼叫的一致和可预见的处理。尽管有可能涉及处理紧急呼叫的潜在压力以及尽管调度员的技能水平和/或经验如此，但是直观进展生成调度员的可预见行为。诊断工具使具有很少或没有经验和/或医疗训练的调度员能够在合理的概率成功地确定患者是否已患有中风。在紧急调度情况下，阻止对不是指示呼叫者观察的输入的非故意输入也可以是重要的。例如，调度员可能在大致同时接收多个呼叫，并且从而被迫处理多个呼叫。调度员可能已向第一呼叫者提供了多个指令，并且实质上沿着诊断工具的方案前进，不料竟由于呼叫被中断而断线。与中断的呼叫相关联的情况可能持续，以及紧急医疗调度系统可以允许调度员暂停该病例的进行，以等待从第一呼叫者回来的呼叫。调度员然后可能应答呼叫，预期其是第一呼叫者的，而发现第二呼叫者正报告紧急事件。因此，调度员可以发起新的病例 (即，紧急医疗调度方案的会话或实例)，并且开始处理第二呼叫。短时间后，第一呼叫者可能回电，以及调度员将希望在呼叫被中断之前方案所处的在中风识别工具中的大致点处重新开始对紧急呼叫的处理，而不是从头开始。在没有来自用户界面300的指示方案的进展中的点的指导的情况下，处理紧急呼叫的压力和/或强度可能促使调度员忘记呼叫被中断时在方案中何处。此外，当调度员在与第一呼叫相关联的用户界面和与第二呼叫相关联的用户界面之间切换时，可能有相当大的风险调度员可能点击用户界面的区域，并且非故意地选择不是指示与该用户界面相关联的特定呼叫者的观察的响应。调度员可能未能意识到该非故意的输入或未能认识到该非故意的输入不是指示呼叫者的观察。将用户界面300的某些部分和组件提供为最初不活动的可以帮助提供对在中风识别工具的方案上的进展的点的直观理解，并且可以避免调度员非故意地提供不准确的输入。在点击开始输入310之后，用户界面300向调度员提供调度员能够转达给呼叫者的诊断指令304。诊断指令可以针对以便于以识别患者已患有中风的体征或症状的方式指导呼叫者。例如，中风患者通常可能在身体一侧遭受麻木或虚弱。麻木或虚弱能够促使中风患者拥有在一侧下垂或下倾的微笑。在所描绘的实施例中，诊断指令304可以指引呼叫者例如“Ask her/him to smile (要求她/他微笑)”，作为呼叫者识别患者是否可能正经历任何麻木或虚弱的潜在方式。当调度员将该诊断指令304转达给呼叫者时，指导呼叫者要求患者微笑。诸如“Wait (等待)”的交互指令340可以被提供以指导调度员与呼叫者交互。交互指令342 “Wait”指示调度员给予呼叫者执行诊断指令304并且观察患者的响应的时间。 交互指令340可以通过提示调度员要冷静并耐心，尽管有处理紧急呼叫的潜在压力，来增强对紧急呼叫的一致处理。交互指令340可以在圆括号中被提供以指示其仅为调度员准备，并且不被转达给呼叫者。用户界面300可以进一步提供供调度员询问呼叫者的问题312，以辅助呼叫者评估患者对诊断指令304的响应。问题312还可以辅助调度员采集关于呼叫者对患者的对诊断指令304的响应的观察的信息。所采集到的信息可以是关于中风的潜在体征或症状的信息。例如，由用户界面300提供的问题312可以是“Was the smile equal on both sides of his/her mouth ？(微笑在他/她的嘴两侧同样吗？)”，以采集关于患者是否可能正经历任何麻木或虚弱的信息。如果患者不能微笑或在他/她的嘴两侧不能同样地微笑，则患者可能正遭受通常由中风引起的麻木或虚弱。呼叫者通过电话用口头对该问题作出响应。由用户界面提供的输入域320允许调度员输入指示在呼叫者对问题312的响应中表达的呼叫者转达的信息的输入。换句话说，输入域320可以为调度员提供向中风识别工具提供来自呼叫者对问题312的响应的信息的方式。呼叫者转达的信息可以指示呼叫者对患者的对诊断指令304的响应的观察。在所描绘的实施例中，用户界面300将输入域 320提供为单选按钮组。四个单选按钮被提供，每一个按钮具有提供呼叫者的潜在响应的关联标签，诸如 “Normal smile (正常微笑)”、“Slight difference in smile (possible difference)(微笑的细微差异(可能差异))”、“0nly one side of mouth or face shows a smile (obvious difference)(只有嘴或脸的一侧显示微笑(明显差异))”以及“Cannot complete request at all (根本无法完成请求)”。患者的潜在响应可以与患者可能已患有中风的潜在体征或症状相关。例如，患者对充分微笑的无能力能够指示该患者可能正经历麻木或虚弱，其通常伴随中风发生。图3C图示了在完成第一脚本化交互之后，并且在调度员已使用用户界面300的输入域320来提供了输入之后的用户界面300。事先，调度员可能已向呼叫者转达了诊断指令304 “Ask her/him to smile”，调度员可能已按照交互指令340等待，并且然后向呼叫者询问了问题 312“Was the smile equal on both sides ofhis/her mouth ”。如图 3C 中所示，呼叫者可能已对该问题作出响应，通过电话向调度员转达回“Yes，the patient' s smile was equal on both sides (是的，患者的微笑在两侧是同样的)”，并且调度员利用了输入域320来输入患者的微笑是“Normal smile”。如图3C中所示，调度员已点击了输入域320的与“Normal smile”相对应的单选按钮。用户界面300可以进一步提供回答域334以向调度员提供对提供给输入域320的输入的快速指示。例如，回答域可以提供回答数字来指示调度员在输入域320中选择了哪个潜在患者响应。例如，如果输入域320的第一潜在响应被选择，则回答域334可以呈现数字“1”，以及如果输入域320的第二潜在响应被选择，则回答域334可以呈现数字“2”，等等。在回答域334中提供的回答数字向调度员提供在输入域320中选择的潜在患者响应的快速指示。回答数字比单选按钮的选择更容易识别和区别，其减少了非故意和/或错误的输入。如图3C中所示，回答域334提供“1”来指示调度员已选择了如由呼叫者对问题 312的回答所提供的、对诊断指令304的第一潜在响应“Normal smile”。相比之下，在图 3D中，调度员已将输入域320改变成指示患者用“Slight difference in smile (possible difference) ”作出响应，并且回答域334提供“2”来指示第二潜在响应被选择。在另一个实施例中，回答域334、336、338提供分值来向调度员指示对患者响应的特定呼叫者观察的重要性，因为其与诊断中风有关。所呈现的分值指示患者对诊断指令的响应可以指示该患者已潜在患有中风的显著程度。诊断工具可以计算该分值或另外为给出的患者响应确定适当的分值。在所描绘的实施例中，在分值域334中提供的较低分值可以指示患者的响应指示该患者尚未患有中风，或存在该患者已患有中风的较低概率，而在分值域中提供的较高分值可以指示患者的响应指示该患者已患有中风的较高可能性。一系列分值可以指示患者的响应指示该患者可能已患有中风的不同程度的可能性。例如，分值“1” 可以指示患者的响应指示该患者已患有中风的较低概率，分值“2”可以指示稍微更高的概率，分值“3”可以指示适度更高的概率，以及分值“4”可以指示患者的响应指示该患者可能已患有中风的较高概率。如说明性示例，考虑图3C中的回答域334，其提供“1”作为调度员输入患者响应于诊断指令304提供了“Normal smile”的结果。分值“ 1”可以指示该患者已患有中风的较低可能性。类似地，图3D图示了调度员已将输入域320改变成该患者用“Slight difference in smile (possible difference) ”作出响应的输入，并且回答域334提供了“2”。分值“2” 可以指示该响应指示该患者可能已患有中风的稍微更高的概率。如可以理解的，其他范围的数字可以被提供作为分值域334中的分值。在另一个实施例中，所提供的分值可以与患者已患有中风的概率成反比，使得较高分值指示中风的较低概率，以及较低分值指示患者已患有中风的较高概率。在又一个实施例中，分值可以被大于或小于1的增量分隔。例如，小数值是可能的，或从“1”至“3”的步进可以指示渐增的概率。此外，分隔不同分值的增量可以变化，使得没有可预见或一致的增加(例如，1、2.2、 3. 8、6)。在又一个实施例中，患者响应的重要性级别可以在回答域334中由诸如色彩、计量器或条形图的视觉指示器来指示。例如，患者响应“Normal smile”可以在回答域334中由诸如黑色的色彩来指示，以指示这样的响应指示患者可能已患有中风的较低概率。患者响应"Slight difference in smile (possible difference)，，可以在回答域 334 中由诸如蓝色的色彩来指示，以指示患者可能已患有中风的稍微更高的概率。患者响应“Only once side of mouth or face shows a smile (obvious difference)，可以在回答域 334 中由诸如橙色的色彩来指示，以指示患者可能已患有中风的适度更高的概率。患者响应“Cannot complete the request at all”可以在回答域334中由诸如蓝色的色彩来指示，指示患者可能已患有中风的稍微更高的概率。其他色彩可以用来显示患者响应指示患者可能已患有中风的进一步增加的概率。再次参考图3C的实施例，在调度员已利用了输入域320来输入呼叫者对问题312 的响应之后，用户界面300可以向调度员提供第二脚本化交互，包括调度员能够转达给呼叫者的第二诊断指令306。例如，用户界面300可以提供诸如“Ask her/him to raise both arms above her/his head.(要求她/他把双臂高举过她/他的头部)”的第二指令306。 该第二诊断指令306可以以便于识别能够被用来诊断患者是否可能已患有中风的体征或症状的方式来指导呼叫者。例如，第二诊断指令可以指导调度员进一步评估患者是否可能正经历可能通常伴随中风发生的任何麻木或虚弱。当调度员将该第二诊断指令306转达给呼叫者时，指导呼叫者要求患者把她/他的手臂高举过她/他的头部。诸如“Wait”的第二交互指令342可以被提供以通过提示调度员给予呼叫者执行指令并且观察患者的响应的时间，来指导调度员与呼叫者交互。第二交互指令342可以在圆括号中被提供，以区别于意在被转达给呼叫者的指令，并且从而指示交互指令342仅为调度员准备。用户界面300进一步提供供调度员询问呼叫者的第二问题314，以辅助呼叫者评估患者对第二诊断指令306的响应。调度员可以询问呼叫者第二问题314以采集关于呼叫者对患者的响应的观察的信息。所采集到的信息可以是关于中风的潜在体征或症状的信息。例如，由用户界面300提供的第二问题314可以是“Was s/he able to do it (她 /他能够做到吗？)”(即，患者能够把她/他的手臂高举过她/他的头部吗？)，指导呼叫者识别患者是否已患有通常随中风患者出现的任何麻木或虚弱。第二输入域320可以由用户界面300提供以使调度员能够向中风识别工具提供指示呼叫者对第二问题314的响应的输入。第二输入域322可以为调度员提供输入如在呼叫者对第二问题314的响应中表达的、呼叫者对患者的对第二诊断指令306的响应的观察的方式。用户界面300将第二输入域322提供为单选按钮组，类似于输入域320。在所描绘的实施例中的第二输入域322可以具有四个单选按钮，以及每一个单选按钮可以具有提供呼叫者的潜在响应的关联标签，诸如“Both arms raised equally (双臂举得一样高)”、“0ne arm raised higher than the other (both raised unequally)(——只手If 举得比另——只手臂高(两只举得不一样高))”、“0nly one arm raised (只有一只手臂举起)”以及“Cannot complete request at all (根本无法完成请求)”。潜在响应可以与患者可能已患有中风的潜在体征或症状相关。例如，患者对同样举起双臂的无能力能够指示该患者可能已患有中风。图3D图示了在完成第二脚本化交互之后、在调度员已使用第二输入域322提供了输入之后的用户界面300。(而且，如前参考图3C所描述的，调度员可能已改变输入域320 的输入，并且因此，如图3D中所示的输入域320并不对应于图3C)。事先，调度员可能已向呼叫者提供了第二指令306，并且询问呼叫者第二问题314。呼叫者可能已对第二问题314 作出响应，通过电话向调度员转达回患者仅能够把一只手臂高举过她/他的头部。因此，如图3D中所示，调度员已点击了第二输入域322的与潜在患者响应“Only one arm raised" 相对应的单选按钮。回答域336提供回答数字“3”，指示调度员已经输入了第三潜在患者响应。在调度员利用第二输入域322来输入呼叫者对第二问题314的响应之后，用户界面300向调度员提供第三脚本化交互，其具有调度员能够转达给呼叫者的第三诊断指令 308。第三诊断指令可以进一步以便于确定患者是否可能已患有中风的方式来指导呼叫者。 例如，用户界面 300 可以提供诸如“Ask her/him to say, ‘ The early bird catches the worm.‘(要求她/他说，“早起的鸟儿有虫吃”。)”的第三指令308。中风患者常常表现出言语含糊不清，或甚至是言语混乱或不能被理解，以及第三诊断指令指导呼叫者识别该体征或症状。诸如“Wait”的第三交互指令344可以在圆括号中被提供以通过提示调度员给予呼叫者执行指令并且观察患者的响应的时间，来指导调度员与呼叫者交互。用户界面300 还可以提供供调度员询问呼叫者的第三问题316，以辅助呼叫者评估患者对第三诊断指令 308的响应。例如，由用户界面300提供的第三问题316可以是“Was s/he able to repeat it correctly ？(她/他能够正确复述吗？)”(即，患者能够正确说出“早起的鸟儿有虫吃”吗 )。用户界面300还可以提供诸如“Clarify(明晰)，，的第四交互指令346，以提示调度员询问另外的问题，来使呼叫者对患者的对第三诊断指令308的响应的观察变明晰。第四交互指令346可以在圆括号中被提供，以将其区别为仅为调度员准备，并且并不转达给呼叫者的交互指令。用户界面300进一步提供供调度员询问呼叫者的第四问题318，以使呼叫者对患者的对第三诊断指令308的响应的观察变明晰。例如，在所描绘的实施例中，用户界面 300 可以提供第四问题 318 "Was it slurred, garbled, or not understandable ？ (它是含糊不清、混乱或不可理解的吗？)”因此，第四问题318使患者对第三诊断指令308 的响应是否表现出如通常随中风患者出现的、言语含糊不清或混乱变明晰。用户界面300还可以提供第三输入域324，通过第三输入域3 调度员能够向中风识别工具提供指示呼叫者对第二问题314的响应的输入。第三输入域3M可以为调度员提供输入如在呼叫者对第三问题316和第四问题318的响应中表达的、呼叫者对患者的对第三诊断指令308的响应的观察的方式。第三输入域3M可以由用户界面300提供为单选按钮组。第三输入域3M可以被提供为四个单选按钮，以及单选按钮中的每一个可以具有提供呼叫者的潜在响应的关联标签，诸如“Said correctly(正确说出)”、“SlUrred speech (言语含糊不清)，，、"Garbled or not understandable speech (言语混舌L或不可理解)”以及"Cannot complete request at all (根本无法完成请求)”。这些潜在响应可以与患者可能已患有中风的潜在体征或症状相关。图3E是在完成第三脚本化交互之后、在调度员已使用第三输入域3M提供了输入之后的用户界面300。调度员可能先前已将第三诊断指令308提供给呼叫者，并且呼叫者已对第三问题316和第四问题318作出响应，通过电话向调度员转达回患者根本无法完成请求。因此，如图3E中所示，调度员已点击了第三输入域324的与潜在患者响应“Cannot complete request at all ”相对应的单选按钮。第三回答域338提供回答数字“4”，指示调度员选择了输入域3M上的第四潜在患者响应。在调度员完成了所有脚本化交互、将输入提供到所有输入域320、322、324中之后，用户界面300可以提供能够被点击来完成和/或终止中风识别工具的诊断功能的完成输入326。完成输入3 可以被提供为按钮。调度员能够点击完成输入3 按钮来向诊断工具指示调度员已完成转达诊断指令并且输入如由问题所采集的关于患者的响应的信息。 完成输入326当被点击时还可以向诊断工具发信号来对输入进行处理，并且提供关于患者是否可能已患有中风的确定或建议。如果调度员改变提供给输入域320、322、324的输入， 则调度员可以再次点击完成输入3 来促使中风识别工具再次对输入进行处理并且提供关于患者是否可能已患有中风的确定或建议。更进一步，点击完成输入3 还可以向诊断工具发信号来将经由输入域320、322、324接收到的输入通信给紧急医疗调度方案和/或决定性值计算器。如所图示的实施例所示，用户界面300可以通过自动预先选择完成输入326 来呈现完成输入326，使得调度员能够例如按回车键来完成(替代点击完成输入326)。在另一个实施例中，完成输入3 在适当的输入已被提供给输入域320、322、3M之前可以是不活动的。图3F是在调度员已使用完成输入3 来提供输入之后的用户界面300。中风识别工具对经由输入域320、322、3M提供的输入进行处理，并且生成建议以在建议域328中显示。图5A-5F图示了根据一个实施例的用于生成建议的流程图。建议可以是患者已患有中风的概率的指示。建议还可以包括对调度员和/或呼叫者的另外指令和/或建议做法。在所描绘的实施例中，诊断工具对与“Slight difference in smile (possible difference)，，、"Only one arm raised，，禾口"Cannot complete request at all，，相关联的输入进行处理，以生成有“Clear evidence of a stroke (2，3，4)(明显的中风迹象(2、3、 4)) ”的建议。回答数字“(2、3、4) ”也被包括以向调度员提供被选择并且在确定建议时使用的问题回答(即，患者响应)的精确组合的快速指示。向调度员呈现建议以提供对诊断工具的处理(或分析)的指示。诊断工具作出患者是否可能已患有中风的确定。调度员被免除执行任何诊断功能，并且不需要具有任何医疗训练或经验来提供与紧急呼叫者表达的情况一致、可靠的响应。在另一个实施例中，诊断工具可以对生成以用于在每一个回答域中显示的分值进行处理，其中已对输入进行预处理以生成每一个分值。替选地，诊断工具可以独立于并不同于生成分值来处理输入。建议可以包括关于患者是否可能已患有中风的中风识别工具确定的结果。关于患者对诊断指令的响应提供的建议和/或信息还可以被通信给紧急医疗调度系统100(参见图1)的紧急医疗调度方案108和/或决定性值计算器110。建议和/或信息可以由紧急医疗调度方案108和/或决定性值计算器110用来生成能够被传送给紧急响应者的适当紧急医疗响应和/或决定性值。建议和/或信息还可以由紧急医疗调度系统 100用来为呼叫建立优先级。用户界面300还提供关闭输入330以关闭诊断工具和/或诊断工具界面300。在所描绘的实施例中，关闭输入330被提供为用户能够点击的按钮。调度员点击关闭输入330 按钮来关闭中风识别工具。在另一个实施例中，关闭输入330还可以在诊断工具关闭之前向诊断工具发信号以将提供的关于患者的诊断指令响应的建议和/或信息转送给紧急医疗调度方案和/或决定性值计算器。所描绘的实施例具有三个脚本化交互集合(每一个脚本化交互具有例如至少一个诊断指令、至少一个交互指令、关于患者对诊断指令的响应的至少一个问题以及至少一个输入域)。尽管提供了三个脚本化交互，但是其他布置和配置是可能的。如将理解的，在另一个实施例中，可以提供更多的脚本化交互(或更少的脚本化交互)。在又一个实施例中，脚本化交互可以具有变化数量的诊断指令、交互指令和问题(如第三脚本化交互所指示的)。此外，尽管所描绘的实施例的脚本化交互还具有回答域和/或交互指令，但是其他实施例可以提供没有这些元件的脚本化交互。如还可以理解的，脚本化交互的顺序可以变化。例如，包括指令306、问题342和输入域322的第二脚本化交互可以被呈现在第一脚本化交互(即，指令304、问题340和输入域320)之前。此外，如还可以理解的，调度员可以以任何顺序进行脚本化交互。尽管脚本化交互的呈现暗含顺序，但是调度员可以以任何顺序来应对每一个脚本化交互。例如，调度员可以首先应对第三脚本化交互。在图3A-3F中描绘的第三脚本化交互包括诸如 "Ask her/him to say, ‘ The early bird gets the worm' ” 的指令 308、诸如"Was s/ he able to repeat it correctly ？，，的问题 316 禾口诸如"Was it slurred, garbled, or not understandable ？”的问题318。调度员可以选择在应对第一脚本化交互之前应对该第三脚本化交互。类似地，调度员可以选择在第一脚本化交互之后并且在第二脚本化交互之前应对第三脚本化交互。类似地，调度员可以选择在第三脚本化交互之前应对第二脚本化交互。此外，图3A-3F的实施例将所有的脚本化交互一起呈现在中风识别工具的用户界面300的单个屏幕上。然而，如可以由普通技术人员理解的，脚本化交互可以被呈现在单独屏幕上，提供了应当应对脚本化交互的明确排序。更进一步，每一个脚本化交互的指令和问题也可以被呈现在单独屏幕上。图4是根据一个实施例的由中风识别工具的方案400呈现脚本化交互的流程图。 中风识别工具从紧急调度方案内启动。紧急调度方案可以基于紧急调度方案所接收到的指示患者可能已患有中风的输入来自动启动该工具。中风识别工具还可以由调度员视需要手动启动。当中风识别工具被启动时，逻辑流从紧急调度方案转到中风识别工具的逻辑流，如中风识别工具方案400的流程图中所图示。方案400提供402调度员能够转达给呼叫者的指令。方案400还可以提供404交互指令来指引调度员与呼叫者交互。方案然后提供406问题来便于呼叫者获得并转达关于患者对指令的响应的信息。方案400还呈现408输入域以使调度员能够向方案提供与患者对指令的响应相对应的输入，以及方案接收410调度员输入的输入。方案然后可以提供另外的脚本化交互，跳回到提供402指令的步骤。替选地，方案400可以基于所接收410的输入来作出关于患者是否可能已患有中风的确定412。在作出确定412之后，方案400的逻辑流结束，并且控制被转移回到紧急调度方案。图5是根据一个实施例的中风识别工具的特定方案500向调度员提供指令和问题的流程图。如前所述，中风识别工具方案可以呈现包括指令和问题的一系列脚本化交互。尽管在图5中未描绘，但是方案500可以包括另外的步骤，诸如提供交互指令、呈现输入域以及接收输入，如图4的方案400所图示的。在图5的实施例中，中风识别工具的方案500提供502诸如“Ask her/him to smile” 的第一指令。方案 500 然后提供 504 诸如 “Was the smile equal on both sides of her/his mouth ”的第一问题，以获得关于患者对第一指令的响应的信息。方案然后提供 506 诸如 “Ask her/him to raise both arms above her/his head，，的第二指令，并且提供508诸如“What was s/he able to do (她/他能够做什么？)”的第二问题。方案然后提供 510 诸如"Ask her/him to say, ‘ The early bird catches the worm'，，的第三指令并且提供512诸如“Was s/he able to repeat it correctly ？”的第三问题。与提供问题504、508、512协同，方案500还提供如在图3A-3F和4中所描绘并且参考图3A-3F和4所描述的输入域。输入域使调度员能够提供与表达患者对指令的响应的、 呼叫者对问题的回答相对应的输入。方案500接收该输入以用于作出关于患者是否可能已患有中风的确定514。确定516基于调度员所提供的输入，如在下面参考图6A-6D更详细论述的。方案500然后返回到紧急调度方案。确定的结果和/或调度员输入的输入也可以被返回给紧急调度方案。图6A-6D是根据一个实施例的中风识别工具的方案600确定患者是否可能已患有中风的流程图。该确定的逻辑路径取决于所提供的输入。在图6A-6D中，对输入的接收被表示为在问题框外的路径。具体参考图6A，在从紧急调度方案内被起动之后，中风识别工具方案600提供602诸如"Ask her/him to smile，，的指令。方案600然后提供604诸如 "Was the smile equal on both sides of her/his mouth ？”的第一问题。取决于所提供的输入(其指示关于患者对指令的响应的呼叫者对问题的响应)，方案600沿着不同的路径前进。如果所接收到的输入指示“only one side of mouth or face shows a smile”，则作出有明显的中风迹象的确定614。在图6B中图示了当输入指示“Slight difference in smile”时方案600的逻辑路径。在图6C中示出了当输入指示“Cannot complete request” 时方案600的逻辑路径。如果输入指示“Normalsmile”，则方案600提供606诸如“Ask her/him to raise both arms above head”的指令。方案 600 提供 608 诸如“What was s/he able to do ？” 的第二问题来从呼叫者查明患者对指令的响应。再次，取决于响应于该问题而提供的输入， 方案600沿着不同的路径前进。如果所接收到的输入指示“Only one arm raised”，则作出有明显的中风迹象的确定614。如果所接收到的输入指示“Both arms raised equally" 或患者“Cannot complete request”，则逻辑流沿着与当所接收到的输入指示“One arm higher than other”时的路径不同的路径前进。不管逻辑流沿着哪条路径前进，方案600提供610、618诸如“Ask her/him to say, ‘ The early bird catches the worm' ”的指令，并且提供 612、620 诸如“Was s/he able to repeat it correctly ？ ”的第三问题。此外，不管逻辑流沿着哪条路径前进，如果响应于所提供612、620的第三问题而接收到的输入指示“Slurred speech”或“Garbled or not understandable speech”，则作出有明显的中风迹象的确定614。然而，如果对所提供 608 的第二问题的响应是“Both arms raised equally，，或"Cannot complete request，，，并且对所提供612的第三问题的响应是“Mid correctly”或“Cannot complete the request”，则作出没有中风迹象的确定616。如果对所提供608的第二问题的响应是“One arm higher than other”，并且对所提供620的第三问题的响应是“Mid correctly”或 "Cannot complete the request”，则作出有部分中风迹象的确定。在作出确定614、616、 622之后，方案600结束，并且控制转回到紧急调度方案。图6B图示了如果响应于第一问题而提供的输入指示“Slight difference in smile”，方案600的逻辑流。图6C图示了如果响应于第一问题而提供的输入指示“Cannot complete request”，方案600的逻辑流。图6D图示了如果响应于第二问题而提供的输入指示“Cannot complete request”，方案600的逻辑流。如所图示，方案600的这些替选分支提供624、628、638、644、648、658、664指令，并且提供 626、632、640、646、652、660、666 问题。除响应于问题而提供的输入可能导致可能不同的确定634、638、642、654、656、662、668、670、 672外，逻辑流有点类似于图6A的逻辑流。例如，所提供的输入可以指示“No evidence of a stroke (没有中风迹象)”、“Partial evidence of a stroke (部分中风迹象)”、“Mrong evidence of a stroke (弓虽*力的中，，、“ Cl ear evidence of a stroke(明 H 的中风迹象)”或 “Unable to complete diagnostic (不能完成诊断)”。如图6A-6D中所示的方案600的逻辑路径图示了一些响应可能是明显的中风迹象，而单独的其他响应可能仅仅是部分中风迹象或强有力的中风迹象。例如，输入“Only one side of mouth shows a smile，，、“0nly one arm raised，，、"Slurred speech，，以及 "Garbled or not understandable speech，，可能导致石角定"Clear evidence of stroke，，。 相比之下，输入"Slight difference in smile，，或"One arm higher than the other，，可能导致确定 “Partial evidence of stroke，，或 “Strong evidence of stroke，，。如可以理解的，随着获得关于中风的体征和症状的另外研究和信息，所提供的输入(以及隐含地患者响应)可以变化并且在确定中的重要性可以改变。所图示的方案600的逻辑路径说明了输入可以如何被不同地内部加权，并且然后被处理来生成患者是否可能已患有中风的确定。如前所述，上述实施例结束并且将控制转移给紧急调度方案(或另外允许紧急调度方案恢复)。如可以理解的，实施例可以将关于患者是否可能已患有中风的确定或建议和/或经由输入域接收到的输入转送或另外通信给紧急调度方案和/或决定性值计算器， 并且可以辅助确定调度响应的优先级。确定的结果可以被并入紧急调度方案的逻辑树的遍历中。例如，关于紧急调度方案如何沿着逻辑树前进的随后确定可以至少部分基于中风识别工具的确定。普通技术人员能够理解的是，建议和输入还可以被通信给紧急医疗调度系统100的其他组件。此外，其他信息也可以被通信。由工具取得的所有信息可以由系统100 存储并且传送给决定性值计算器110、报告模块114、CAD系统112和/或受过训练的紧急响应者。该信息可以被用来在到达之前协助紧急响应者。诊断工具120，包括中风识别工具 122，极大改善了对紧急医疗响应情况的信息收集和干预，并且将是挽救生命的辅助物。虽然已经图示并描述了本公开的具体实施例和应用，但是将理解的是，本公开并不限于在此公开的精确配置和组件。在不背离本公开的精神和范围的情况下，在本公开的方法和系统的布置、操作和细节方面，可以进行对本领域技术人员而言是显而易见的各种修改、改变和变化。
权利要求
1.一种用来当经由电话与呼叫者进行关于患者的医疗紧急事件的通信时协助调度员的计算机实现的方法，包括调度中心计算机系统提供紧急调度方案来协助所述调度员，所述方案呈现供所述调度员询问所述呼叫者的多个预先脚本化的询问，以采集关于所述紧急事件的信息并且由紧急响应者生成紧急调度响应；所述调度中心计算机系统起动所述调度中心计算机系统上的诊断工具，所述诊断工具被配置成协助所述调度员指导所述呼叫者获得能够由所述诊断工具用来诊断所述患者是否已患有中风的信息；所述诊断工具向所述调度员呈现用户界面；所述诊断工具经由所述用户界面提供供所述调度员通过所述电话用口头转达给所述呼叫者的指令，以协助所述呼叫者识别患者可能已患有中风的体征和症状；所述诊断工具接收指示与呼叫者对所述患者的响应的观察有关的呼叫者转达的信息的调度员输入的输入，包括指示所述患者是否已患有中风的体征和症状，其中所述呼叫者的观察通过所述电话用口头转达给所述调度员；以及所述诊断工具基于指示所述呼叫者转达的信息的所述调度员输入的输入来确定所述患者已患有中风的可能性。
2.根据权利要求1所述的计算机实现的方法，进一步包括所述诊断工具经由所述用户界面向所述调度员指示所述患者是否已患有中风的所述确定的结果。
3.根据权利要求1所述的计算机实现的方法，进一步包括所述诊断工具基于所述患者是否已患有中风的所述确定来生成能够被转达给所述紧急响应者的建议；以及所述诊断工具的所述用户界面向所述调度员显示所述建议。
4.根据权利要求1所述的计算机实现的方法，其中，所述调度中心计算机系统基于指示所述呼叫者对由所述方案向所述调度员呈现的所述询问的一个或多个响应的调度员输入的输入，来起动所述诊断工具。
5.根据权利要求1所述的计算机实现的方法，进一步包括所述调度中心计算机系统向所述调度员呈现具有用来起动所述诊断工具的诊断工具启动输入的紧急调度方案用户界面，其中所述调度中心计算机系统响应于所述诊断工具启动输入而起动所述诊断工具。
6.根据权利要求1所述的计算机实现的方法，进一步包括所述调度中心计算机系统基于所述诊断工具确定所述患者是否已患有中风来为所述紧急调度响应确定优先级。
7.根据权利要求6所述的计算机实现的方法，其中，所述调度中心计算机系统确定所述优先级进一步包括确定决定性值。
8.根据权利要求1所述的计算机实现的方法，其中，所述诊断工具经由所述用户界面提供指令包括提供指引所述呼叫者来要求所述患者执行动作的指令，以及其中所述计算机实现的方法进一步包括所述诊断工具向所述调度员提供问题以关于所述呼叫者对所述患者执行所述动作的观察对所述呼叫者进行指引。
9.根据权利要求8所述的计算机实现的方法，其中，所述诊断工具提供指引所述呼叫者来要求所述患者执行动作的指令包括提供指引所述呼叫者来要求所述患者微笑的指令，以及其中所述诊断工具向所述调度员提供问题以关于所述呼叫者的观察对所述呼叫者进行指引包括询问所述呼叫者所述患者的微笑在所述患者的嘴两侧是否是同样的。
10.根据权利要求8所述的计算机实现的方法，其中，所述诊断工具提供指引所述呼叫者来要求所述患者执行动作的指令包括提供指引所述呼叫者来要求所述患者把双臂高举过所述患者的头部的指令，以及其中所述诊断工具向所述调度员提供问题以关于所述呼叫者的观察对所述呼叫者进行指引包括询问所述呼叫者所述患者是否能够把双臂高举过所述患者的头部。
11.根据权利要求8所述的计算机实现的方法，其中，所述诊断工具提供指引所述呼叫者来要求所述患者执行动作的指令包括提供指引所述呼叫者来要求所述患者说出词句的指令，以及其中所述诊断工具向所述调度员提供问题以关于所述呼叫者的观察对所述呼叫者进行指引包括询问所述呼叫者所述患者是否能够正确复述所述词句。
12.根据权利要求1所述的计算机实现的方法，进一步包括所述诊断工具经由所述用户界面提供输入域，通过所述输入域，所述调度员能够输入指示与所述呼叫者对中风的体征和症状的观察有关的呼叫者转达的信息的输入。
13.根据权利要求12所述的计算机实现的方法，其中，所述输入域包括与潜在呼叫者观察相关联的单选按钮。
14.根据权利要求12所述的计算机实现的方法，进一步包括所述诊断工具经由所述用户界面向所述调度员指示与指示所述呼叫者观察的调度员输入的输入相对应的答案号码。
15.根据权利要求1所述的计算机实现的方法，进一步包括所述诊断工具经由所述用户界面提供完成输入，其中所述诊断工具响应于所述完成输入而作出所述患者是否已患有中风的确定。
16.根据权利要求1所述的计算机实现的方法，进一步包括所述诊断工具的所述用户界面提供关闭输入；以及所述诊断工具响应于所述关闭输入而终止操作。
17.根据权利要求1所述的计算机实现的方法，进一步包括所述诊断工具向所述紧急调度方案提供所述患者是否已患有中风的所述诊断工具确定的结果。
18.根据权利要求1所述的计算机实现的方法，其中，所述紧急调度方案包括紧急医疗调度方案。
19.一种包括计算机可读指令代码的计算机可读存储介质，所述计算机可读指令代码用于执行用来当经由电话与呼叫者进行关于患者的医疗紧急事件的通信时协助调度员的方法，所述方法包括提供紧急调度方案来协助所述调度员，所述方案呈现供所述调度员询问所述呼叫者的多个预先脚本化的询问，以采集关于所述紧急事件的信息并且生成紧急调度响应；起动调度中心计算机上的诊断工具，所述诊断工具被配置成协助所述调度员指导所述呼叫者获得能够由所述诊断工具用来诊断所述患者是否已患有中风的信息；所述诊断工具向所述调度员呈现用户界面；所述诊断工具经由所述用户界面提供供所述调度员通过所述电话用口头转达给所述呼叫者的指令，以协助所述呼叫者识别患者可能已患有中风的体征和症状；所述诊断工具接收指示与呼叫者对指示所述患者是否已患有中风的体征和症状的观察有关的呼叫者转达的信息的调度员输入的输入，其中所述呼叫者的观察通过所述电话用口头转达给所述调度员；以及所述诊断工具基于指示所述呼叫者转达的信息的所述调度员输入的输入来确定所述患者是否可能已患有中风。
20.根据权利要求19所述的计算机可读存储介质，进一步包括所述诊断工具经由所述用户界面向所述调度员指示对所述患者是否已患有中风的所述确定的结果。
21.根据权利要求19所述的计算机可读存储介质，其中，所述诊断工具基于指示所述呼叫者对由所述紧急调度方案向所述调度员呈现的所述询问的一个或多个响应的调度员输入的输入来起动。
22.根据权利要求19所述的计算机可读存储介质，其中，所述方法进一步包括向所述调度员呈现具有用来起动所述诊断工具的诊断工具启动输入的紧急调度方案用户界面，其中所述诊断工具响应于所述诊断工具启动输入而起动。
23.根据权利要求19所述的计算机可读存储介质，其中，所述方法进一步包括基于所述诊断工具确定所述患者已患有中风来为所述紧急调度响应确定优先级。
24.根据权利要求19所述的计算机可读存储介质，其中，所述方法进一步包括所述诊断工具经由所述用户界面提供输入域，通过所述输入域，所述调度员能够输入指示与所述呼叫者对中风的体征和症状的观察有关的呼叫者转达的信息的输入。
25.一种用来执行用来当经由电话与呼叫者进行关于患者的医疗紧急事件的通信时协助调度员的方法的计算机系统，所述计算机系统包括处理器；与所述处理器电通信的输入设备；与所述处理器电通信的输出设备；以及与所述处理器电通信并且在其上存储有以下的存储器紧急调度方案，所述紧急调度方案包括供调度员询问呼叫者的多个预先脚本化的询问，以生成紧急调度响应；以及诊断工具，所述诊断工具用于协助所述调度员指导所述呼叫者获得能够由所述诊断工具用来诊断所述患者是否已患有中风的信息，其中所述诊断工具被配置成在所述输出设备上向所述调度员呈现用户界面，包括供所述调度员通过所述电话用口头转达给所述呼叫者的指令，以协助所述呼叫者识别所述患者已患有中风的体征和症状；接收指示与所述呼叫者对指示所述患者可能已患有中风的体征和症状的观察有关的呼叫者转达的信息的调度员输入的输入，其中所述呼叫者的观察通过所述电话用口头转达给所述调度员；以及基于指示所述呼叫者转达的信息的所述调度员输入的输入来确定所述患者是否可能已患有中风。
26.根据权利要求25所述的计算机系统，其中，所述诊断工具进一步被配置成向所述调度员指示确定所述患者是否可能已患有中风的结果。
27.根据权利要求25所述的计算机系统，其中，所述诊断工具进一步被配置成向所述紧急调度方案提供确定所述患者是否已患有中风的结果。
28.根据权利要求25所述的计算机系统，进一步包括决定性值计算器，所述决定性值计算器存储在所述存储器上、用来计算决定性值以对紧急响应确定优先级，其中所述诊断工具被配置成向所述决定性值计算器提供确定所述患者是否已患有中风的结果。
29.根据权利要求25所述的计算机系统，进一步包括报告模块，所述报告模块存储在所述存储器上、用来测量调度员的绩效，其中所述诊断工具被配置成向所述报告模块提供确定所述患者是否已患有中风的结果。
全文摘要
用来协助紧急医疗调度员对紧急呼叫作出响应的系统和方法。计算机实现的紧急调度方案包括询问，以供调度员询问呼叫者来生成适当的响应。提供诊断工具以对关于患者是否可能已患有中风进行诊断。诊断工具基于呼叫者转达的关于患者的信息来确定患者是否可能已患有中风。诊断工具可以由紧急调度方案自动启动，或由调度员手动启动。诊断工具呈现提供指令、问题和输入域等的用户界面。
文档编号G06Q50/00GK102576449SQ201080040259
公开日2012年7月11日 申请日期2010年7月27日 优先权日2009年9月11日
发明者杰弗里·J·克劳森 申请人:杰弗里·J·克劳森