computer-implemented method to assist a dispatcher when communicating with a caller over the phone,

专利摘要:
INTERVENTION TOOL AND DIAGNOSIS OF CEREBRAL VASCULAR ACCIDENT FOR EMERGENCY DISPATCH. It is a system and method to assist an emergency medical dispatcher in responding to emergency calls. A computer-implemented emergency dispatch protocol includes interrogations for a dispatcher to ask a caller to generate an appropriate response. A diagnostic tool is provided to diagnose whether a patient has likely suffered a stroke. The diagnostic tool determines whether the patient has likely suffered a stroke based on information relayed by the caller about the patient. The diagnostic tool can be started automatically by the emergency dispatch protocol, or manually by a dispatcher. The diagnostic tool features a user interface that provides, among other things, instructions, questions and input fields.
公开号:BR112012002351B1
申请号:R112012002351-9
申请日:2010-07-27
公开日:2020-12-08
发明作者:Jeffrey J. Clawson
申请人:Jeffrey J. Clawson；
IPC主号:

专利说明:

Copyright notice
[001] © 2010 Priority Dispatch Corp. Part of the description in this patent document contains material that is subject to copyright protection. The copyright owner has no objection to facsimile reproduction by anyone within the patent document or patent description, as it appears in the patent and trademark department patent records or file, but otherwise reserves all copyrights whatever they may be. 37 CFR $ 1.71 (d). Technique field
[002] This invention relates to computer systems and methods for providing medical protocol interrogation, instruction and emergency dispatch. More specifically, the invention is directed to tools implanted by computer to assist a dispatcher during an interrogation and instruction by an emergency caller. Brief description of the drawings
[003] Non-limiting and non-exhaustive description modalities are described, which include several description modalities with reference to figures, in which:
[004] Figure 1 is a block diagram of an emergency dispatch system, according to one modality;
[005] Figure 2 illustrates a user interface for an emergency medical release protocol, according to one modality; and
[006] Figures 3A-3F illustrate a user interface for a stroke identification tool;
[007] Figure 4 is a flow chart of a protocol for a stroke identification tool that provides instructions and questions for a dispatcher;
[008] Figure 5 is a flow chart of a particular protocol 500 of a stroke identification tool; and
[009] Figures 6A-6D are flowcharts of a stroke identification tool that identifies whether a patient has suffered a stroke. Detailed Description
[010] Emergency dispatchers handle emergency calls that report on a wide variety of emergency situations. An automated emergency dispatch system, potentially implemented on a computer, can assist a dispatcher in prioritizing calls and processing calls to generate an appropriate emergency dispatch response. Regardless of the dispatcher's experience or level of knowledge, automated emergency dispatch systems can enable a consistent and predictable emergency dispatch response, despite various aspects of emergency situations, which include, among other things , signs, symptoms, conditions and circumstances, which can be reported from a call to the following.
[011] Although an automated emergency dispatch system may enable the collection and processing of widely divergent aspects of emergency situations, some of the emergency situations and / or reported aspects should be explored in greater depth as they are reported. This additional exploration may require the dispatcher to investigate further to gather more descriptive details. In addition, some emergency situations can be improved by more detailed instructions. More other emergency situations may involve a clinical presentation of a condition that is not easily diagnosed, but which could alter the appropriate dispatch response if properly diagnosed.
[012] A dispatcher with little or no medical training or experience is unlikely to adequately explore situations and / or aspects or diagnose medical conditions, let alone instruct a caller to do so. In addition, automated emergency dispatch systems are not equipped to assist or enable a dispatcher to explore situations in greater depth, provide additional instruction or diagnose conditions. Consequently, the present description is directed to tools that supplement an automated emergency dispatch system to try to cover these and other disadvantages of self-emergency emergency dispatch systems.
[013] The modalities of the description will be better understood by referring to the drawings, in which similar parts are designated by similar numerals. It will be readily understood that the components of the modalities presented, as generally described and illustrated in the figures in the present document, could be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of the systems and methods of the description is not intended to limit the scope of the description as claimed, but is merely representative of possible description modalities. In addition, the steps of a method need not necessarily be performed in any specific order, or even sequentially, nor do they need to be performed only once, unless otherwise specified.
[014] In some cases, well-known features, structures or operations are not shown or described in detail. In addition, the characteristics, structures or operations described can be combined in any appropriate way in one or more modalities. It will also be readily understood that the components of the modalities, as generally described and illustrated in the figures in this document, could be arranged and designed in a wide variety of different configurations.
[015] Several aspects of the described modalities will be illustrated as modules or software components. For use in the present invention, a software module or component may include any type of computer instruction or computer executable code located within a computer-readable memory device and / or storage medium. A software module can, for example, comprise one or more physical or logical blocks of computer instructions, which can be organized as a routine, program, object, component, data structure, etc., that perform one or more tasks or deploy the particular abstract data types.
[016] In certain modalities, a particular software module may comprise discrepant instructions stored in different locations on a memory device, which together implement the described functionality of the module. In fact, a module can comprise a single instruction or many instructions, and can be distributed over several different code segments, between different programs, and across multiple memory devices. Some modalities can be practiced in a distributed computing environment where tasks are performed by a remote processing device connected through a communications network. In a distributed computing environment, software modules can be located on local and / or remote memory devices. In addition, data that is linked or rendered together in a database record can be resident on the same memory device, or across multiple memory devices, and can be linked together in fields in a base record data over a network.
[017] The appropriate software to assist in the implementation of the invention is promptly provided by the elements versed in the relevant technique (s) using the instructions presented here and programming tools and languages, such as Java, Pascal, C ++, C, database languages, APIs, SDKs, assembly, firmware, microcode and / or other languages and tools. Suitable signal formats can be incorporated in analogue or digital form, with or without correction and / or error detection bits, packet headers, network addresses in a specific format and / or other supporting data readily provided by the versed elements in the relevant technique (s).
[018] An emergency dispatch system, as presented in this document, can be fully implemented by computer or in part on a digital computer. The digital computer includes a processor that performs the required computations. The computer additionally includes a memory in electronic communication with the processor for the storage of a computer operating system. Computer operating systems may include MS-DOS, Windows, Unix, AIX, CLIX, QNX, OS / 2 and Apple. Alternatively, it is expected that future modalities will be applied to execute other future operating systems. The memory also stores application programs that include a computer-assisted dispatch (CAD) program, an automated emergency dispatch protocol, a user interface program, and data storage. The computer may additionally include an output device, such as a display unit, for viewing displayed instructions and inquiries and a user input device for entering response data.
[019] Figure 1 is an emergency dispatch system 100, according to one modality. At a dispatch center 102, a dispatcher 104 operates a computer 106. The computer may include memory 107 to store protocols, modules, tools, data, etc. The computer can be configured to run an emergency medical dispatch protocol 108 to enable the dispatcher to quickly and consistently address a patient's medical emergency 117 as reported by a caller 118. The emergency medical dispatch protocol 108 provides a logical tree with questions, possible answers from a caller 118, and instructions for the caller 118. Answers can lead to subsequent questions and / or instructions for the caller. Responses are processed according to predetermined logic both to provide dispatcher 104 with the correct emergency medical dispatch response (for example, by trained emergency responders) and appropriate physician-approved post-dispatch instructions to relay to the caller 118 before professional help arrives on the scene. The emergency medical dispatch system 100 can also assist the dispatcher in determining an emergency call priority, which includes, but is not limited to, an emergency call priority over other emergency calls.
[020] Although an emergency medical dispatch system 100 and emergency medical dispatch protocol 108 are presented and described in this document, one skilled in the art may note that other emergency dispatch systems and emergency dispatch protocols emergencies are considered, which include, but are not limited to, emergency fire protection protocols and systems and emergency police dispatch protocols and systems. Exemplary modalities of such emergency dispatch systems and protocols are presented in U.S. patents nos. 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 and 7,428,301, which are hereby incorporated into reference title.
[021] Computer 106 can also operate a determinant value calculator 110 to calculate a determinant value from the responses of caller 118 to protocol questions. Computer 106 displays the determining value for generating an appropriate emergency dispatch response and / or establishing the priority of the emergency call. The answer may include dispatching professional emergency responders to the emergency scene. Due to the questions asked and the recommendations that deal directly with life and death decisions, the protocols used must have passed through a rigorous medical review by a board of doctors and EMS public safety specialists who specialize in emergency medicine. The determinant calculator 110 can be stored in memory 107 of the computer.
[022] Many calls for medical services do not consist of real medical emergencies, so it is important to prioritize calls in several ways. First, calls that consist of real emergencies should be dispatched first. Second, if an agency has units with different capacities, the most advanced units should be dispatched for the most severe medical problems. And finally, if lights and sirens are not needed from a medical point of view, they should not be used, thus increasing the safety of everyone on the road and in emergency vehicles. While many medical calls do not consist of real emergencies, all situations can benefit from medical assessment and instruction. Before professional help arrives on the scene, the emergency medical dispatch protocol 108 provides dispatcher 104 with instructions for caller 118 that are appropriate for the type of call, from a patient 117 with minor lacerations to a patient 117 who is not breathing.
[023] The determining value provides a categorization code for the type and level of the incident. The code can be provided for a computer-assisted dispatch (CAD) system 112, which consists of a tool used by a dispatcher 104 to track and allocate emergency response resources for processing. The CAD system 112 can operate completely or in part on a separate computer in communication with computer 106. In another embodiment, the CAD system 112 operates on computer 106. The primary information used by the CAD system 112 consists of location information both the incident and the units, the availability of the unit and the type of incident. The CAD 112 system can use third-party solutions, such as E-911, vehicle location transponders and MDT's to automate availability and location tasks.
[024] Computer 106 can also include a reporting module 114 to statistically measure the performance of the individual team and the overall performance of the dispatch center 102. These statistics include compliance rates, process processing statistics call and pair measurements. Report module 114 can be stored in memory 107 of computer 106.
[025] Computer 106 may additionally comprise an input device, such as a keyboard, mouse, or other input device and also an output device, such as a display screen. The input device receives input from a user (usually a dispatcher) and supplies it to the emergency medical dispatch system 100. Input can be provided to computer 106, emergency protocol 108, the tools 120 and / or the CAD system 112. The output device receives the output from the emergency medical dispatch system 100 and displays or otherwise presents the output to the user. In another embodiment, the input device and the output device are provided by the CAD system 112. In yet another embodiment, the CAD system 112 works on computer 106.
[026] Dispatch center 102 includes telephony equipment 116 to answer emergency calls. A call at dispatch center 102 from a caller 118 initiates the creation of a medical call incident. Dispatcher 104 identifies the call as demanding an emergency medical dispatch and emergency medical dispatch protocol 108 is accessed. Protocol 108 can provide instructions that are expertly plotted to assist a novice caller 118 in diagnosing a patient's condition 117. Protocol 108 can also provide expertly designed first aid instructions to assist a patient 117 before attendants arrive. trained emergency responders. The instructions can be relayed vocally by dispatcher 104 to caller 118 over telephone equipment 116.
[027] Some questions in the protocol can be readily answered by the caller 118, while others are more difficult to answer. Certain diagnostic inquiries can be difficult for the untrained caller to determine or they can be difficult to respond under the stress of an emergency. Consequently, in addition to the instructions, the emergency medical dispatch system 100 can provide one or more computer-implemented tools 120. Tools 120 can greatly improve the collection of information and intervention for emergency medical response situations and help in saving lives.
[028] A tool 120 can assist the dispatcher and / or the caller (through instructions from the dispatcher) in diagnosing a patient's condition 104. A tool 120 can also consist of an intervention tool, which provides instructions that direct a caller to intervene, or take action, to treat a patient 104, or otherwise change the circumstances or conditions of an emergency. For the sake of clarity, both the tools and the intervention tools are mentioned in this document generally as tools. Consequently, a tool 120, as mentioned in this document, can provide diagnostic instructions, intervention instructions, or both intervention and diagnostic instructions. If a tool 120 provides only diagnostic instructions, only intervention instructions, or both intervention and diagnostic instructions, the tool can provide reliable and consistent instruction, information gathering and / or timing for an emergency situation particular.
[029] Tools 120 consist of computer-implemented software modules that enable a dispatcher 104 to provide specific and consistent guidance to assist a caller in a particular aspect of an emergency situation, such as determining a vital sign . A benefit of the tools 120 consists of computer-aided timing of techniques for determining vital signs. In highly stressed conditions, tools 120 provide a necessary resource for reading critical signals. Tools 120 can be stored in memory 107 of computer 106 and started and executed as required. The tools 120 can be incorporated as software applications executable by computer and associated data.
[030] Emergency medical dispatch protocol 108 may request a tool 120, for example, to assist with an interrogation, and may refer to the appropriate tool 120 when necessary. When directed according to protocol 108, the emergency medical dispatch system 100 can start automatically, that is, without the dispatcher intervention, the appropriate tool 120 on the dispatch center computer 106. This can occur when the emergency medical dispatch protocol 108 arrives at a diagnostic step in the protocol and starts a corresponding tool 120. The emergency dispatch system 100 may also allow dispatcher 104 the option of manually ordering a tool 120 as desired. Icons and / or buttons can be displayed on a toolbar, or other convenient location on a user interface to allow dispatcher 104 to start a corresponding tool 120. In another embodiment, the emergency medical dispatch protocol 108 can simply induce the dispatcher to initialize the stroke identification tool 122 when necessary.
[031] The tool 120 discussed in this document comprises a stroke identification tool 122. The stroke identification tool 122 is configured to assist dispatch 104 in guiding caller 118 to diagnose whether the patient 117 may have suffered a stroke. The emergency medical dispatch protocol 108 can automatically forward directly to the stroke identification tool 122 upon receipt of information indicating that the patient may have suffered a stroke. The Emergency Medical Dispatch Protocol 108 can also enable a wiper to manually start the stroke identification tool. The stroke identification tool 122 is discussed in reference to the graphical user interface figures that exemplify certain modalities. One skilled in the art will note that such interfaces can be deployed and designed in various ways and still fall within the scope of the invention.
[032] Figure 2 illustrates a user interface 200 of an emergency medical dispatch protocol, according to one modality. The emergency medical dispatch protocol user interface 200 allows a dispatcher to interface with the emergency medical dispatch protocol. The emergency medical dispatch protocol can display interrogations 202 through the emergency medical dispatch protocol user interface 200. Interrogations 202 are provided for the dispatcher to direct to the caller to gather information regarding the patient's medical emergency. The dispatcher and / or the emergency medical dispatch system can gather the information in the form of the caller's responses to interrogations 202. The dispatcher can enter the caller's responses to interrogations in response fields 204 provided by the interface 200. Response fields 204 may include, for example, familiar user interface components, which include, but are not limited to, text fields, text boxes, menus, drop-down menus, drop-down boxes, lists , buttons, control boxes and radio buttons. Response fields 204 may correspond to information indicative of one or more responses by the caller for interrogations 202.
[033] The caller's responses, and the information therein, relayed from the caller to the dispatcher, and entered into the system, can be used by the emergency medical protocol to determine interrogations 202 and subsequent instructions to be submitted to the forwarding agent. The caller's responses, and the information therein, may indicate the caller's observations of signs and symptoms of the patient's medical condition. The information gathered from the caller's responses can be used by the emergency medical dispatch system to generate an emergency medical dispatch response by trained emergency responders. The information gathered from the caller's responses can be used by the determinant calculator to calculate a determinant value that can be communicated to emergency responders. Additional details of emergency medical dispatch protocols and user interfaces for interacting with them can be found in the aforementioned U.S. patents.
[034] The Emergency Medical Dispatch Protocol User Interface 200 can also provide one or more tool initialization entries 206. As illustrated, one or more buttons can be provided on the user interface as tool initialization entries 206. Tool initialization entries 206 enable the dispatcher to initialize a particular tool. Although the emergency medical dispatch protocol can automatically start a tool based on an entry entered by dispatcher indicative of one or more responses from the caller, tool initialization entries 206 provide a way for the dispatcher to initiate manually (ie at any time, at the dispatcher's discretion) a tool. In Figure 2, a stroke identification tool boot entry 208 is provided. The stroke identification tool boot entry 208 can comprise a button on the emergency medical dispatch protocol user interface 200 with a face icon with the mouth falling on one side. The icon may indicate that the button launches the stroke identification tool. As will be seen by a person skilled in the art, tool initialization entries 206 may comprise a component in addition to a button, which includes familiar user interface components, such as a drop-down menu, a drop-down box, a list, a control box, a text field and a radio button.
[035] Figures 3A-3F illustrate a modality of a user interface 300 of a stroke identification tool, according to a modality. User interface 300 of the illustrated embodiment provides instructions 302, 304, 306, 308, a start entry 310, questions 312, 314, 316, 318, input fields 320, 322, 324, an end entry 326, a recommendation field 328 and a closing entry 330. User interface 300 assists a dispatcher in guiding a caller in obtaining information that can be used by the cerebrovascular accident identification tool to diagnose whether a patient has suffered an accident cerebral vascular system. Instructions 304, 306, 308, questions 312, 314, 316 and input fields 320, 322, 324 can be grouped into one or more written interactions (for example, at least one statement, at least one question and at least one input field). A written interaction guides the dispatcher in guiding the caller to identify the signs and symptoms that a patient may have suffered from a cerebrovascular accident. User interface 300 can additionally provide response fields 334, 336, 338 to display a response number that corresponds to a patient response that can be selected in each input field 320, 322, 324 (ie , the entry provided to the user interface by the dispatcher who responds to the caller's responses to questions 312, 314, 316 and also the patient's responses to instructions 302, 304, 306, 308). User interface 300 may also provide one or more confirmation instructions 332 to confirm the caller's status and one or more interaction instructions 340, 342, 344, 346 intended only for the dispatcher as a guide in interaction with the caller.
[036] Instructions 302, 304, 306, 308 can direct the dispatcher in the orientation of the caller. An initial instruction 302 can direct the dispatcher to prepare the caller for subsequent diagnostic instructions 304, 306, 308 and / or questions 312, 314, 316, 318. For example, the initial instruction 302 can provide "I want you to come close enough to ask him three questions." The initial instruction 302 can also prepare the caller to facilitate the diagnosis of whether the patient may have suffered a stroke. A 332 confirmation instruction can be provided, such as "Talk to me when you're ready," to enable the dispatcher to know when the caller is ready for additional 304, 306, 308 diagnostic instructions.
[037] Start input 310 can be provided to activate the diagnostic function of the stroke identification tool. Figure 3A illustrates user interface 300 before a start input 310 activates the diagnostic function of the stroke identification tool. In the embodiment of Figure 3A, the start input 310 consists of a button. Start entry 310 is labeled with the term "Ready", which indicates to the dispatcher in an intuitive way that the dispatcher should click the button when the caller responds to confirmation instruction 332 that the caller is ready. Before start entry 310 is clicked, components of user interface 300 may be inactive. For example, in the mode described, input fields 320, 322, 324 are darkened and / or grayed out (ie, displayed with a lighter shade of gray instead of black or colors, to indicate that they cannot currently be operated by the user) due to the fact that they are inactive. Response fields 334, 336, 338 are also empty, which indicates that they are inactive. One skilled in the art will note that, before the start input 310 is clicked, other components, such as diagnostic instructions 304, 306, 308, end input 326, recommendation field 328 and closing input 330 , can also be inactive and / or grayed out. After the start input 310 is clicked, these components can be activated. In another mode, these components can be activated at different stages of progress within the tool protocol.
[038] The input fields 320, 322, 324 of the illustrated mode are provided as groups of radio buttons. As can be seen, input fields 320, 322, 324 can be provided as any one of a variety of user interface components, which include, but are not limited to, text fields, text boxes, menus , drop-down menus, suspense checkboxes, lists, buttons and control boxes, or combinations thereof. The input fields are discussed in greater detail below with reference to Figures 3C-3E.
[039] Figure 3B illustrates user interface 300 after start input 310 has been clicked to activate the diagnostic function of the stroke identification tool. After the start entry 310 is clicked, the input fields 320, 322, 324 are no longer darkened, which indicates that they are enabled. Response fields 334, 336, 338 are also now active and show a response number of "0" to indicate that no input has been provided. Other components, such as end input 326 and end input 330, which were previously in an inactive state can also be activated once start input 310 has been clicked. In this way, the progress of the stroke identification tool protocol can be controlled in an intuitive way. The dispatcher is guided to wait until the caller is prepared for diagnostic instructions 304, 306, 308. In addition, by supplying input fields 320, 322, 324, end input 326 and closing input 330 in an inactive state before receipt of start entry 310, user interface 300 protects against the dispatcher's inadvertent insertion of an entry that is not indicative of the patient's caller's observations.
[040] Providing intuitive control of tool protocol progress can facilitate predictable and consistent emergency call processing. Intuitive progress generates predictable actions by the dispatcher despite the potential stress that may be involved with emergency call processing and despite the dispatcher's level of knowledge and / or experience. The tool allows a dispatcher with little or no experience and / or medical training to successfully determine, at a reasonable probability, whether a patient may have suffered a stroke.
[041] Preventing the inadvertent insertion of an entry that is not indicative of a caller's observation can also be important in emergency dispatch scenarios. For example, a dispatcher can receive and be forced, therefore, to process multiple calls at substantially the same time. The dispatcher may have provided multiple first caller's instructions and progressed substantially throughout the tool protocol, only to be disconnected due to the call being missed. The situation associated with the missed call may be in progress and the emergency medical dispatch system may allow the dispatcher to place the case on hold to await a call again from the first caller. The dispatcher can then answer a call that is expected to be the first caller and, on the contrary, discover that a second caller is reporting an emergency. Consequently, the dispatcher can initiate a new case (that is, session or emergency medical dispatch protocol case) and begin processing the second call. Shortly thereafter, the first caller can call again, and instead of starting over, the dispatcher will want to select the emergency call processing substantially at the point on the stroke identification tool where the protocol was before the call was missed. .
[042] Without guidance from user interface 300 to indicate the point in the progress of the protocol, the stress and / or intensity of emergency call processing may cause the dispatcher to forget where in the proctor the call was missed . In addition, as the dispatcher switches between the user interface associated with the first call and the user interface associated with the second call, there may be a substantial risk that the dispatcher could click an area of the user interface and select inadvertently a response that does not indicate a note from the particular caller associated with that user interface. The dispatcher may fail to recognize the inadvertent entry or fail to realize that this inadvertent entry is not indicative of an observation by the caller. Providing certain parts and components of user interface 300, as initially inactive, can help provide an intuitive understanding of the progress point in the stroke identification tool protocol and can inadvertently protect against delivery inaccurate entry of the dispatcher.
[043] After clicking the start entry 310, the user interface 300 provides the dispatcher with a diagnostic instruction 304 that the dispatcher can re-transmit to the caller. The diagnostic instruction can be directed to guide the caller in a way that facilitates the identification of a sign or symptom that the patient has suffered a stroke. For example, stroke victims may commonly suffer from numbness or weakness on one side of the body. Numbness or weakness can cause a stroke victim to have a smile that loosens or leans on one side. In the described modality, the diagnostic instruction 304 can direct the caller, for example, to "Ask him to smile", as a potential way for the caller to identify whether the patient may be experiencing any numbness or weakness. When the dispatcher relays this 304 diagnostic instruction to the caller, the caller is instructed to ask the patient to smile.
[044] An interaction instruction 340, such as "Wait", can be provided to guide the dispatcher in interacting with the caller. Interaction instruction 342 "Wait" instructs the dispatcher to allow time for the caller to execute diagnostic instruction 304 and observe the patient's response. Interaction instruction 340 can optimize consistent emergency call processing by prompting the dispatcher to remain calm and patient despite the potential stress of emergency call processing. The interaction instruction 340 can be provided in parentheses to indicate that it is intended only for the dispatcher and should not be relayed to the caller.
[045] User interface 300 can additionally provide a dispatcher question 312 to ask the caller to assist the caller in assessing the patient's response to diagnostic instruction 304. Question 312 can also assist the dispatcher in the meeting. information about the caller's observations of the patient's response to the 304 diagnostic instruction. The information gathered may consist of information concerning a potential sign or symptom of a stroke. For example, question 312 provided by user interface 300 may consist of "Did the smile look the same on both sides of your mouth " to gather information about whether the patient may be experiencing any numbness or weakness. If the patient is unable to smile, or unable to smile equally on both sides of his mouth, the patient may be suffering from the numbness or weakness that results commonly from a stroke. The caller answers the question vocally on the phone.
[046] An input field 320 provided by the user interface allows the dispatcher to enter the input that is indicative of the information relayed by the caller conducted in the caller's response to question 312. Mentioned differently, the input field 320 can provide a form for the despa-chante to provide the stroke identification tool with information from the caller's response to question 312. The information retransmitted by caller may indicate the caller's observations of the patient's response to the instruction diagnosis 304. In the described mode, user interface 300 provides input field 320 as a group of radio buttons. Four radio buttons are provided, each button having an associated label that provides a potential caller's response, such as "normal smile", "slight difference in smile (possible difference)", "only one side of the mouth or face shows a smile (obvious difference) "and" cannot complete the entire request ". The patient's potential responses may correlate with a potential sign or symptom that the patient may have suffered a stroke. For example, the patient's inability to complete the smile may indicate that the patient may be experiencing numbness or weakness, which often accompanies a stroke.
[047] Figure 3C illustrates user interface 300 after a first written interaction is complete and after the dispatcher has provided input using the input field 320 of user interface 300. Previously, the dispatcher may have retransmitted for the caller the diagnostic instruction 304, "Ask him to smile", the dispatcher may have waited according to interaction instruction 340 and then asked the caller question 312, "The smile was the same on both the sides of your mouth ”As shown in Figure 3C, the caller may have answered the question, transmitting back to the dispatcher on the phone that," Yes, the patient's smile was the same on both sides ", and the des -pachante used input field 320 to insert that the patient's smile was a “normal smile.” As shown in Figure 3C, the dispatcher has clicked the radio button for input field 320 that corresponds to “normal smile”.
[048] User interface 300 can additionally provide a response field 334 to provide quick dispatch to the dispatcher of the input provided for input field 320. For example, the response field can provide a response number for indicate which response of the potential patient is selected in input field 320 by the dispatcher. For example, if the first potential response from input field 320 is selected, response field 334 can display the number "1" and if the second potential response from input field 320 is selected, response field 334 can display the number "2" and so on. The response number provided in response field 334 provides the dispatcher with a quick indication of the potential patient's response selected in input field 320. The response number is more readily identifiable and distinguishable than selecting the radio button, the which reduces inadvertent and / or erroneous entry.
[049] As shown in Figure 3C, response field 334 provides a "1" to indicate that the dispatcher has selected the first potential response "Normal smile" for diagnostic instruction 304 as provided by the caller's response to question 312. In In contrast, in Figure 3D, the dispatcher has changed input field 320 to indicate that the patient responded with a "Slight difference in smile (possible difference)" and response field 334 provides a "2" to indicate that the second response potential has been selected.
[050] In another embodiment, response fields 334, 336, 338 provide a score to indicate to the dispatcher the importance of observing the particular caller of a patient's response, as it relates to the diagnosis of a stroke cerebral. The score shown indicates how significantly a patient's response to the diagnostic instruction can indicate that the patient has potentially suffered a stroke. The tool can calculate the score or otherwise determine the appropriate score for a given patient's response. In the modality described, a low score provided in the score field 334 may indicate that the patient's response suggests that the patient has not had a stroke, or that there is a low probability that the patient has had a stroke, whereas a High scores provided in the score field may indicate that the patient's response suggests a high probability that the patient has suffered a stroke. A range of scores may be possible to indicate varying degrees of probability that the patient's response suggests that the patient may have suffered a stroke. For example, a score of "1" may indicate that the patient's response suggests a low probability that the patient has suffered a stroke, a score of "2" may indicate a slightly higher probability, a score of "3" may indicating a moderately higher probability and a score of "4" may indicate that the patient's response suggests a high probability that the patient may have suffered a stroke.
[051] As an illustrative example, we consider response field 334 in Figure 3C, which provides a "1" as a consequence of a dispatcher who inserts that a patient provided a "normal smile" in response to the 304 diagnostic instruction A score of "1" may suggest a low probability that the patient has suffered a stroke. Similarly, Figure 3D illustrates that the dispatcher has altered input field 320 to insert that the patient responded with "Slight difference in smile (possible difference)" and response field 334 provides a "2". A score of "2 "may indicate that the answer suggests a slightly higher probability that the patient may have suffered a stroke.
[052] As can be seen, other ranges of numbers may be provided as scores in the score field 334. In another embodiment, the scores provided may be inversely proportional to the probability that the patient has suffered a stroke, such that a high score indicates a low probability of stroke and a low score indicates a high probability that the patient has suffered a stroke. In yet another modality, the scores can be separated by an increase greater or less than 1. For example, fractional values are possible, or the step from "1" to "3" can indicate the increasing probability. In addition, the additions that separate the different scores may vary in such a way that there is no predictable or consistent increase (for example, 1, 2.2, 3.8, 6).
[053] In yet another modality, the level of importance of a patient's response can be indicated in the response field 334 by a visual indicator, such as a color, a counter or a bar graph. For example, the patient's response "Normal smile" can be indicated in response field 334 by a color, such as black, to indicate that such a response suggests a low probability that the patient may have suffered a stroke. The patient's response "Slight difference in smile (possible difference)" can be indicated in the response field 334 by a color, such as blue, to indicate a slightly higher probability that the patient may have suffered a stroke. The patient's response "only one side of the mouth or face shows a smile (obvious difference)" can be indicated in response field 334 by a color, such as orange, to indicate a moderately greater probability that the patient may have suffered a stroke. The patient's response "cannot complete the entire request" can be indicated in response field 334 by a color, such as blue, which indicates a slightly higher probability that the patient may have suffered a stroke. Other colors can be used to further show the increasing likelihood that a patient's response suggests that the patient may have suffered a stroke.
[054] Again with reference to the modality of Figure 3C, after the dispatcher has used input field 320 to enter the caller's response to question 312, user interface 300 can provide the dispatcher with a second written interaction, which includes a second diagnostic instruction 306 that the dispatcher can transmit to the caller. For example, user interface 300 may provide a second instruction 306, such as "Ask the individual to raise both arms above their head". This second diagnostic instruction 306 can guide the caller in a way that facilitates the identification of a sign or symptom that can be used to diagnose whether the patient may have suffered a stroke. For example, the second diagnostic instruction can guide the dispatcher in the additional assessment if the patient may be experiencing any numbness or weakness as can commonly accompany a stroke. When the dispatcher transmits this second diagnostic instruction 306 to the caller, the caller is instructed to ask the patient to raise their arms above their head.
[055] A second 342 interaction instruction, such as "Wait", can be provided to guide the dispatcher in interacting with the caller by prompting the dispatcher to allow time for the caller to execute the instruction and observe the patient's response. The second interaction instruction 342 can be provided in parentheses to distinguish it from instructions intended to be re-transmitted to the caller and thus indicate that the interaction instruction 342 is intended only for the dispatcher.
[056] User interface 300 additionally provides a second question 314 for the dispatcher to ask the caller to assist the caller in assessing the patient's response to the second diagnostic instruction 306. The dispatcher can ask the caller the second question 314 to gather information about the caller's observations of the patient's response. The information gathered may consist of information concerning a potential sign or symptom of a stroke. For example, the second question 314 provided by user interface 300 may consist of "Was he able to do this " (ie, was the patient able to raise his arms above his head ), guiding the caller to identify whether the patient suffered any numbness or weakness that commonly occurs with stroke victims.
[057] A second input field 322 can be provided via user interface 300 to enable the dispatcher to provide the stroke identification tool with an input that is indicative of the caller's response to second question 314. The second input field input 322 can provide a way for the dispatcher to insert the caller's observations of the patient's response to the second diagnostic instruction 306 as communicated in the caller's response to second question 314. The second input field 322 is provided by the user 300 as a group of radio buttons, similar to input field 320. The second input field 322 in the described mode can have four radio buttons, and each radio button can have an associated label that provides a potential caller response , such as "Both arms raised equally", "One arm raised more than the other" (both raised unevenly), "Only one arm raised" and "You cannot complete the entire request". Potential responses may correlate with a potential sign or symptom that the patient may have suffered a stroke. For example, the patient's inability to raise both arms equally may indicate that the patient may have suffered a stroke.
[058] Figure 3D illustrates user interface 300 after the second written interaction is complete, after the dispatcher has provided input using the second input field 322. (In addition, as previously described with reference to Figure 3C, the dispatcher may have altered the input field input 320 and, consequently, the input field 320, as shown in Figure 3D, does not correspond to Figure 3C.) Previously, the dispatcher may have provided the caller the second instruction 306 and asked the caller the second question 314. The caller may have answered the second question 314 by transmitting back to the dispatcher on the phone that the patient was only able to raise an arm above his head . Consequently, as shown in Figure 3D, the dispatcher has clicked the radio button for the second input field 322 that corresponds to the potential patient's response "Only one arm raised". A response field 336 provides a response number "3", which indicates that the dispatcher has entered the potential patient's third response.
[059] After the dispatcher has used the second input field 322 to enter the caller's response to the second question 314, user interface 300 provides the dispatcher with a third written interaction, which has a third diagnostic instruction 308 that the dispatcher can transmit to the caller. The third diagnostic instruction can additionally guide the pain-caller in a way that facilitates determining whether the patient may have suffered a stroke. For example, user interface 300 can provide a third instruction 308, such as "Asking him to say, God helps early risers." Stroke victims often display unintelligible speech or even speech that is confused or cannot be understood, and the third diagnostic instruction guides the caller in identifying this sign or symptom.
[060] A third 344 interaction instruction, such as "Wait", can be provided in parentheses to guide the dispatcher in interacting with the caller by prompting the dispatcher to allow time for the caller to execute the instruction and observe the patient's response . User interface 300 can also provide a third question 316 for the dispatcher to ask the caller to assist the caller in assessing the patient's response to third diagnostic instruction 308. For example, the third question 316 provided by user interface 300 can be "Was he able to repeat this correctly " (that is, the patient was able to correctly say "God helps early risers").
[061] User interface 300 can also provide a fourth 346 interaction instruction, such as "Clarify", to prompt the dispatcher to ask an additional question to clarify the caller's observations of the patient's response to the third diagnostic instruction. 308. The fourth interaction instruction 346 can be provided in parentheses to distinguish it as an interaction instruction intended only for the dispatcher, and should not be relayed to the caller. User interface 300 additionally provides a fourth question 318 for the dispatcher to ask the caller to clarify the caller's observations of the patient's response to third diagnostic instruction 308. For example, in the mode described, user interface 300 can provide the fourth question 318, "Was this unintelligible, confusing or not understandable ”. Thus, the fourth question 318 clarifies whether the patient's response to the third diagnostic instruction 308 exhibited unintelligible or confused speech, as is commonly the case. with stroke victims.
[062] User interface 300 can also provide a third input field 324 by which the dispatcher can provide the stroke identification tool with an input that is indicative of the caller's response to second question 314. The third input field 324 can provide a way for the dispatcher to insert the caller's observations of the patient's response to third diagnostic instruction 308, as communicated in the caller's responses to third question 316 and fourth question 318. the third Input 324 can be provided by user interface 300 as a group of radio buttons. The third input field 324 can be provided as four radio buttons, and each radio button can have an associated label that provides a potential caller's response, such as "Spoken correctly", "Unintelligible speech", "Confused speech or not understandable "and" Cannot complete the entire request ". These potential responses may correlate with a potential signal or sin-take that the patient may have suffered a stroke.
[063] Figure 3E is user interface 300 after the third written interaction is complete, after the dispatcher has provided input using the third input field 324. The dispatcher may have previously provided the third instruction Diagnostic 308 for the caller and the caller may have answered question 3 316 and question 4 318 by transmitting back to the dispatcher over the phone that the patient was unable to complete the entire request. Consequently, as shown in Figure 3E, the dispatcher has clicked the radio button for the third input field 324 that corresponds to the potential patient's response "Cannot complete the entire request." A third response field 338 provides a response number " 4 "which indicates that the fourth response of the potential patient in the input field 324 was selected by the desiccant.
[064] After the dispatcher has completed all written interactions, providing input in all input fields 320, 322, 324, user interface 300 can provide a terminating input 326 that can be clicked to complete and / or terminate the diagnostic function of the stroke identification tool. End input 326 can be provided as a button. The dispatcher can click on the finish input button 326 to indicate to the tool that the dispatcher has completed, transmitting the diagnostic instructions and entering the information regarding the patient's responses as assembled by the questions. Termination input 326 can, when clicked, also signal to the tool to process the input and provide a determination or recommendation as to whether the patient may have suffered a stroke. If the dispatcher changes the input provided to an input field 320, 322, 324, the dispatcher can click on end input 326 again to have the stroke identification tool reprocess the input and provide a determination or recommendation about whether the patient may have suffered a stroke. In addition, clicking on the end input 326 can also signal the tool to communicate the input received through input fields 320, 322, 324 for the emergency medical dispatch protocol and / or determinant value calculator. As shown by the illustrated modality, the user interface 300 can present the end input 326 by automatically pre-selecting it, such that the dispatcher can, for example, press enter to finish (instead of clicking the end input 326). In another embodiment, end input 326 may be inactive until appropriate input has been provided for input fields 320, 322, 324.
[065] Figure 3F is user interface 300 after the dispatcher has provided input using end input 326. The stroke identification tool processes the input provided through input fields 320, 322, 324 and generates a recommendation to be displayed in the recommendation field 328. Figures 5A-5F illustrate a flow chart for generating a recommendation, according to a modality. The recommendation may consist of an indication of the likelihood that the patient has suffered a stroke. The recommendation may also comprise additional instructions and / or a suggested course of action for the dispatcher and / or the caller.
[066] In the described mode, the tool processes the entry associated with "Slight difference in smile (possible difference)", "Only one arm raised" and "Cannot complete the entire request" to generate a recommendation that there is "Clear evidence of stroke (2, 3,4) ". The number of responses "(2, 3,4)" are also included to provide the dispatcher with a quick indication of the precise combination of question responses (ie, the patient's responses) that have been selected and used in determining the recommendation. The recommendation is presented to the dispatcher to provide an indication of the processing (or analysis) of the tool. The tool makes the determination if the patient has probably suffered a stroke. The dispatcher is relieved to perform any diagnostic function and does not need to have any medical training or experience to provide a consistent reliable response to the scenario, as communicated by the emergency caller.
[067] In another mode, the tool can process the generated scores for display in each response field, which has pre-processed the input to generate each score. Alternatively, the tool can process input separately and distinctly from the generation of scores. The recommendation may include the results of determining the stroke identification tool on whether the patient may have suffered a stroke.
[068] The recommendation and / or information provided regarding the patient's responses to the diagnostic instructions can also be communicated to the emergency medical dispatch protocol 108 and / or the determinant value calculator 110 of the medical dispatch system. emergency 100 (see Figure 1). The recommendation and / or information can be used by the emergency medical dispatch protocol 108 and / or determinant value calculator 110 to generate an appropriate emergency medical response and / or determinant value that can be transmitted to emergency responders. The recommendation and / or information can also be used by the emergency medical dispatch system 100 to establish a priority for the call.
[069] A closure input 330 is also provided by user interface 300 to close the tool and / or interface diagnostic tool 300. In the described mode, closure input 330 is provided as a button that the user can click. The dispatcher clicks the shutdown entry button 330 to close the stroke identification tool. In another modality, the closing input 330 can also signal to the tool to transfer the recommendation and / or the information provided regarding the responses of the patient's diagnostic instruction to the emergency medical dispatch protocol and / or determinant value calculator, before closing the tool.
[070] The described mode has three sets of written interactions (each written interaction with, for example, at least one diagnostic instruction, at least one interaction instruction, at least one question concerning the patient's response to the diagnostic instruction and at least one input field). Although the three written interactions are provided, other arrangements and configurations are possible. As will be noted, in another modality, more written interactions (or less written interactions) can be provided. In yet another modality, a written interaction can have a varied number of diagnostic instructions, interaction instructions and questions (as evidenced by the third written interaction). In addition, although the written interactions of the described modality have a response field and / or an interaction instruction, other modalities can provide written interactions without these elements.
[071] As can also be seen, the order of written interactions may vary. For example, the second written interaction that includes instruction 306, question 342 and input field 322 can be presented before the first written interaction (i.e., instruction 304, question 340 and input field 320). In addition, as can also be seen, a dispatcher can proceed through written interactions in any order. Although the presentation of written interactions implies an order, the dispatcher can address each written interaction in any order. For example, the dispatcher may address the third written interaction first. The third written interaction described in Figures 3A-3F that includes an instruction 308, such as "Asking him to say, God helps early risers", a question 316, such as "He was able to repeat this correctly ", and a question 318, such as" Was this unintelligible, confusing or not comprehensible ". The dispatcher may choose to address this third written interaction before proceeding to the first written interaction. Similarly, the dispatcher may choose to address the third written interaction after the first written interaction and before the second written interaction. Similarly, the dispatcher may choose to address the second written interaction before the third written interaction.
[072] Additionally, the modality of Figures 3A-3F presents all interactions written together, on a single user interface screen 300 of the stroke identification tool. However, as can be seen by an element versed in the technique, written interactions can be presented on separate screens, providing a defined order in which written interactions should be addressed. In addition, the instruction and question for each written interaction can also be presented on separate screens.
[073] Figure 4 is a flowchart of a written interaction presented by a 400 protocol for a stroke identification tool, according to one modality. The stroke identification tool is started from within the emergency dispatch protocol. The emergency dispatch protocol can automatically start the tool based on the input received by the emergency dispatch protocol which indicates that the patient may have suffered a stroke. The stroke identification tool can also be started manually, as desired, by the dispatcher. When the stroke identification tool is initialized, the logical flow passes from the emergency dispatch protocol to the logical flow of the stroke identification tool, as illustrated in the tool protocol flowchart stroke identification number 400.
[074] Protocol 400 provides 402 an instruction that a dispatcher can transmit to the caller. Protocol 400 can also provide 404 an interaction instruction to direct the dispatcher to interact with the caller. The protocol then provides 406 a question to facilitate the caller who obtains and transmits information about the patient's response to the instruction. Protocol 400 also features 408 an entry field to enable the dispatcher to provide the protocol with the entry that corresponds to the patient's response to the instruction and the protocol receives 410 input entered by the dispatcher. The protocol can then provide additional written interactions, going back to the step that provides an instruction. Alternatively, protocol 400 can make a determination 412 on whether the patient is likely to have a stroke based on input received 410. After determination 412 is made, the logical flow of protocol 400 ends and control is transferred from back to the emergency dispatch protocol.
[075] Figure 5 is a flow chart of a particular protocol 500 of a stroke identification tool that provides instructions and questions for a dispatcher, according to a modality. As explained earlier, the stroke identification tool protocol can feature a series of written interactions that comprise an instruction and a question. Although not described in Figure FIG 5, protocol 500 can include additional steps, such as providing an interaction instruction, presenting an input field, and receiving input, as illustrated by protocol 4 in Figure 4.
[076] In the form of Figure 5, protocol 500 of the stroke identification tool provides 502 a first instruction, such as "Ask him to smile". Protocol 500 then provides 504 a first question, such as "Was the smile the same on both sides of your mouth ", To obtain information about the patient's response to the first instruction. The protocol then provides 506 a second instruction, such as "Ask him to raise both arms above his head", and provides 508 a second question, such as "What was he able to do " 510, then, a third instruction, such as "Asking him to say, God helps early risers", and provides 512 a third question, such as "Was he able to repeat this correctly "
[077] In conjunction with providing questions 504, 508, 512, proto-colo 500 also provides input fields, as described in Figures 3A-3F and 4, and described with reference to it. The input fields allow a dispatcher to provide input that corresponds to the caller's response to the question that communicates the patient's response to the instruction. Protocol 500 receives input to make a determination 514 on whether the patient has likely suffered a stroke. Determination 516 is based on the input provided by the dispatcher, as discussed in greater detail below with reference to Figures 6A-6D. Protocol 500 then returns to the emergency dispatch protocol. The results of the determination and / or the entry entered by the dispatcher can also be returned to the emergency dispatch protocol.
[078] Figures 6A-6D are a flow chart of a 600 protocol for a stroke identification tool that determines whether a patient has probably suffered a stroke, according to one modality. The logical path for the determination depends on the input provided. In Figures 6A-6D, the incoming receipt is represented as the paths outside the question blocks. Referring specifically to Figure 6A, after being initiated from within the emergency dispatch protocol, the stroke identification tool protocol 600 provides 602 an instruction, such as "Ask him to smile". Protocol 600, then, provides 604 a first question, such as "Was the smile the same on both sides of your mouth " Depending on the input provided (which indicates the caller's response to the question about the patient's response to the instruction), protocol 600 proceeds along different paths. If the input received indicates "only one side of the mouth or face shows a smile", determination 614 is made that there is clear evidence of a stroke. The logical path of protocol 600 when the entry indicates "Slight smile difference" is illustrated in Figure 6B. The logic path of the pro-tocolo 600 when the entry indicates "Cannot complete request" is shown in Figure 6C.
[079] If the entry says "Normal smile", protocol 600 provides 606 an instruction, such as "Ask him to raise both arms above his head". Protocol 600 provides 608 with a second question, such as "What was he able to do " to ascertain from the caller the patient's response to the instruction. Again, depending on the input provided in response to this question, protocol 600 proceeds along different paths. If the entry received indicates "Only one arm raised", determination 614 is made that there is a clear evidence of a stroke. If the incoming input indicates "Both arms raised equally" or the patient "Cannot complete the request", the logical flow continues along a path that is different from the path when the incoming input indicates "An arm higher than the other".
[080] Regardless of which path the logical flow proceeds along, protocol 600 provides 610, 618 an instruction, such as "Asking him to say, God helps early risers" and provides 612, 620 with a third question, such like "Was he able to repeat that correctly ". In addition, regardless of which path the logical flow proceeds along, if the input received in the answer to the third question provided 612, 620 indicates "Unintelligible speech" or "Confusing or not understandable speech", then the determination is made 614 that there is clear evidence of a stroke. However, if the answer to the second question is provided 608 consists of "Both arms raised equally" or "Cannot complete the request", and the answer to the third question provided 612 consists of "Spoken correctly" or "No can complete the request ", then 616 is terminated that there is no evidence of a stroke. If the answer to the second question provided 608 consists of "One arm higher than the other" and the answer to the third question provided 620 consists of "You spoke correctly" or "You cannot complete the request", then the determination that there is partial evidence of a stroke. After determination 614, 616, 622 is made, protocol 600 ends and control passes back to the emergency dispatch protocol.
[081] Figure 6B illustrates the logical flow of protocol 600 if the input provided in response to the first question indicates "Slight difference in smile". Figure 6C illustrates the logical flow of protocol 600 if the input provided in response to the first question indicates "Cannot complete request". Figure 6D illustrates the logical flow of protocol 600 if the input provided in response to the second question indicates "Cannot complete request". As illustrated, these alternate branches of protocol 600 provide 624, 628, 638, 644, 648, 658, 664 instructions and provide 626, 632, 640, 646, 652, 660, 666 questions. The logic flow is somewhat similar to the logic flow in Figure 6A, except that the input provided in response to the questions can lead to determinations 634, 638, 642, 654, 656, 662, 668, 670, 672 that can be many different. For example, the entry provided may suggest "No evidence of a stroke", "Partial evidence of a stroke", "Strong evidence of a stroke", "Clear evidence of a stroke" or "Unable to complete the diagnosis ".
[082] The protocol 600 logic paths, as shown in Figures 6A-6D, illustrate that some responses may consist of clear evidence of a stroke, while other responses alone may consist of only partial or strong evidence of a stroke. For example, the entry "Only one side of the mouth shows a smile", "Only one arm raised", "Speech unintelligible" and "Speech confused or not understandable" can lead to a determination "Clear evidence of stroke" . In contrast, the entry "Slight difference in smile" or "One arm higher than the other" can lead to a determination "Partial evidence of stroke" or "Strong evidence of stroke". As can be seen, the input provided (and implicitly the patient's responses) may vary and may change in importance in the determination as further research and information is acquired regarding the signs and symptoms of a stroke. The illustrated logic paths of the 600 protocol demonstrate how the input can be internally weighted differently and then processed to generate a determination as to whether a patient has likely suffered a stroke.
[083] The modalities described above, as explained above, terminate and transfer control to the emergency dispatch protocol (or otherwise allow the emergency dispatch protocol to restart). Con-form can be observed, the modalities can transfer or otherwise communicate the determination or recommendation on whether the patient may have suffered a stroke and / or the input received through entry fields for the dispatch protocol. emergency and / or the determinant value calculator, and can assist in determining the priority of the dispatch response. The result of the determination can be incorporated in the crossing of the logic tree of the emergency dispatch protocol. For example, subsequent determinations of how the emergency dispatch protocol proceeds along the logical tree may be based, at least in part, on the determination of the stroke identification tool. One skilled in the art may note that the recommendation and entry can be communicated to other components of the emergency medical dispatch system 100 as well. In addition, other information can also be communicated. All the information taken by the tools can be stored by the system 100 and transported to the determinant value calculator 110, the report module 114, the CAD system 112 and / or to trained emergency responders. This information can be used to assist emergency responders prior to arrival. The tools 120, which includes the stroke identification tool 122, considerably improve the collection of information and intervention for emergency medical response situations and will consist of an aid in saving lives.
[084] Although the specific modalities and applications of the description have been illustrated and described, it should be understood that the description is not limited to the precise configuration and components presented in this document. Various modifications, alterations and evident variations for the elements versed in the technique can be made in the arrangement, operation and details of the methods and systems of the description, without deviating from the spirit and scope of the description.

权利要求:
Claims (19)
[0001]
1. Computer-implemented method to assist a dispatcher (104) when communicating with a caller (118) over the telephone (116), in connection with a patient's medical emergency (117), FEATURED by the fact that he understands: a dispatch center computer system (106) providing an emergency dispatch protocol (108) to assist the dispatcher, in which the protocol presents a plurality of pre-written interrogations for the dispatcher to ask the caller to gather information regarding the emergency and generate an emergency dispatch response by emergency responders; the dispatch center computer system that starts a tool (120) on the dispatch center computer, the tool configured to assist the dispatcher in guiding the caller to obtain information that can be used by the tool to diagnose whether the patient has suffered an accident cerebral vascular; the tool presenting the dispatcher with a user interface (200,300); the tool providing a diagnostic instruction (502, 504, 506; 602, 606, 610, 618, 624, 628, 638, 644 648, 658, 664) through the user interface for the dispatcher to transmit vocally to the caller over the phone , to assist the caller in identifying signs and symptoms that the patient has suffered a stroke; the tool providing input fields (320, 322, 324) through the user interface through which the dispatcher can insert indicative input of information relayed by the caller about the caller's observations of signs and symptoms of a stroke, in which the fields input buttons comprise a plurality of radio buttons associated each with a potential observation of the caller; the tool receiving the entry inserted by the dispatcher through radio buttons indicating the information relayed by the caller in relation to the caller's observations on the patient's responses to the diagnostic instructions, in which the caller's observations are vocally relayed on the phone for the dispatcher; the tool determining a score based on the entry entered by the dispatcher for each patient's response, where each score is associated with one of the radio buttons and is indicative of the importance of the patient's response in indicating that the patient has suffered a stroke; the tool providing, through the user interface, an indicator of the level of importance of each patient's response in a plurality of response fields; and the tool determining (514, 614, 616, 622, 634, 636, 642, 654, 656, 662, 668, 670, 672) the probability that the patient has suffered a stroke based on the entry entered by the dispatcher indicative of information relayed by caller.
[0002]
2. Method implemented by computer, according to claim 1, CHARACTERIZED by the fact that the indicators are visual indicators that comprise a color, a counter or a bar graph.
[0003]
3. Method implemented by computer, according to claim 1, CHARACTERIZED by the fact that indicators comprise said scores.
[0004]
4. Method implemented by computer, according to claim 1, CHARACTERIZED by the fact that it additionally comprises the tool indicating to the dispatcher, through the user interface, the results of determining whether the patient has suffered a stroke.
[0005]
5. Method implemented by computer, according to claim 1, CHARACTERIZED by the fact that it additionally comprises: the tool generating a recommendation (328) that can be relayed to emergency responders based on the determination if the patient has suffered a stroke ; and the user interface of the tool that displays the recommendation for the dispatcher.
[0006]
6. Method implemented by computer, according to claim 1, CHARACTERIZED by the fact that the dispatch center computer system starts the tool based on the input entered by the dispatcher indicative of one or more responses from the caller to the interrogations presented to the dispatcher by the protocol.
[0007]
7. Computer implemented method, according to claim 1, CHARACTERIZED by the fact that it additionally comprises the dispatch center computer system which presents the dispatcher with an emergency dispatch protocol user interface that has an input tool initialization to start the tool, where the dispatch center computer system starts the tool in response to the tool initialization input.
[0008]
8. Computer implemented method according to claim 1, CHARACTERIZED by the fact that it additionally comprises the dispatch center computer system that determines a priority for the emergency dispatch response based on the tool determining whether the patient has suffered a stroke.
[0009]
9. Method implemented by computer, according to claim 8, CHARACTERIZED by the fact that the dispatch center computer system that determines the priority additionally comprises determining a determining value.
[0010]
10. Method implemented by computer, according to claim 1, CHARACTERIZED by the fact that the tool that provides instructions through the user interface includes providing instructions that direct the caller to ask the patient to perform an action, and in that the method implemented by computer additionally comprises, the tool providing the questions to the dispatcher to direct the caller in relation to the caller's observations regarding the patient performing the action.
[0011]
11. Method implemented by computer, according to claim 10, CHARACTERIZED by the fact that the tool that provides instructions that direct the caller to ask the patient to perform an action comprises the provision of an instruction that directs the caller to ask the patient smile (304), and in which the tool that provides the dispatcher with questions (340) to direct the caller in relation to the caller's observations comprises asking the caller if the patient's smile was the same on both sides of the patient's mouth .
[0012]
12. Method implemented by computer, according to claim 10, CHARACTERIZED by the fact that the tool that provides the instructions that direct the caller to ask the patient to perform an action comprises the provision of an instruction that directs the caller to ask the patient who raises both arms above the patient's head (306), and where the tool that provides the dispatcher with the questions (342) to direct the caller to the caller's observations comprises asking the caller if the patient was able to raise both arms above the patient's head.
[0013]
13. Method implemented by computer, according to claim 10, CHARACTERIZED by the fact that the tool that provides instructions that direct the caller to ask the patient to perform an action comprises the provision of an instruction that directs the caller to ask the patient that speaks a phrase (308), and that the tool that provides the dispatcher with questions (344,346) to direct the caller in relation to the caller's observations comprises asking the caller if the patient was able to repeat the phrase correctly.
[0014]
14. Method implemented by computer, according to claim 1, CHARACTERIZED by the fact that it additionally comprises, the tool providing an end entry through the user interface, in which the tool determines whether the patient has suffered a stroke in response to the termination entry.
[0015]
15. Method implemented by computer, according to claim 1, CHARACTERIZED by the fact that it additionally comprises: the user interface of the tool that provides a closure input; and the tool terminating the operation in response to the shutdown input.
[0016]
16. Method implemented by computer, according to claim 1, CHARACTERIZED by the fact that it additionally comprises, the tool providing for the emergency dispatch protocol the results of determining the tool if the patient has suffered a stroke.
[0017]
17. Method implemented by computer, according to claim 1, CHARACTERIZED by the fact that the emergency dispatch protocol comprises an emergency medical dispatch protocol.
[0018]
18. Computer-readable storage medium CHARACTERIZED for including computer-readable instruction code for executing a method to assist a dispatcher (104) when communicating with a caller (118) over the telephone (116), in relation to an emergency medical condition of a patient (117) as defined in any one of claims 1 to 17.
[0019]
19. Computer system (106) to perform a method to assist a dispatcher (104) when communicating with a caller (118) over the phone (116), in connection with a patient's medical emergency (117), FEATURED by fact that the computer system comprises: a processor; an input device in electrical communication with the processor; an output device in electrical communication with the processor; and a memory in electrical communication with the processor, and which has a computer-readable instruction code stored therein to execute a method to assist a dispatcher when communicating with a caller over the telephone in connection with a medical emergency for a patient as defined in any one of claims 1 to 17.

类似技术:

---

公开号 | 公开日 | 专利标题

---

BR112012002351B1|2020-12-08|computer-implemented method to assist a dispatcher when communicating with a caller over the phone, computer-readable means and computer system to execute that method

---

AU2018223049B2|2020-05-14|Burn diagnostic and intervention tool for emergency dispatch

---

US8488748B2|2013-07-16|Meningitis diagnostic and intervention tool for emergency dispatch

---

US8066638B2|2011-11-29|Diagnostic and intervention tools for emergency medical dispatch

---

US8103523B2|2012-01-24|Diagnostic and intervention tools for emergency medical dispatch

---

AU2010292883B2|2016-09-08|Pandemic diagnostic and intervention tool for emergency dispatch

---

CN108886550B|2021-10-01|Picture/video message emergency response system

---

NZ611173B2|2015-03-25|Meningitis diagnostic and intervention tool for emergency dispatch

---

AU2013251273A1|2013-11-21|Diagnostic and intervention tools for emergency medical dispatch

同族专利:

---

公开号 | 公开日

---

EP2476092B1|2018-10-10|

---

EP2476092A1|2012-07-18|

---

AU2010292882B2|2015-10-29|

---

US8355483B2|2013-01-15|

---

BR112012002351A2|2016-06-07|

---

CA2768689A1|2011-03-17|

---

CA2768689C|2018-09-11|

---

GB2482741A8|2012-02-29|

---

EP2476092A4|2013-06-26|

---

SG177729A1|2012-02-28|

---

NZ597631A|2013-03-28|

---

CN102576449A|2012-07-11|

---

GB2482741A|2012-02-15|

---

US20110064204A1|2011-03-17|

---

WO2011031382A1|2011-03-17|

---

AU2010292882A1|2012-02-02|

---

GB201016097D0|2010-11-10|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

---

US4130881A|1971-07-21|1978-12-19|Searle Medidata, Inc.|System and technique for automated medical history taking|

---

US3799147A|1972-03-23|1974-03-26|Directors University Cincinnat|Method and apparatus for diagnosing myocardial infarction in human heart|

---

US4164320A|1974-09-26|1979-08-14|Medical Laboratory Automation, Inc.|Patient and specimen identification means and system employing same|

---

US4290114A|1976-07-01|1981-09-15|Sinay Hanon S|Medical diagnostic computer|

---

US4237344A|1979-04-20|1980-12-02|Hospital Communication Systems, Inc.|Rapid response health care communications system|

---

NL178633C|1979-06-27|1986-04-16|Siemens Nederland|COMMUNICATION SYSTEM FOR MONITORING A NUMBER OF SUB-ITEMS FROM A MAIN POST AND THROUGH A TRANSMISSION CHANNEL.|

---

US4360345A|1980-07-14|1982-11-23|American Heart Association, Inc.|Health education system|

---

US4455548A|1981-01-26|1984-06-19|Burnett Dorothy K|Call system and methods and apparatus for operating same|

---

JPH0380496B2|1981-06-24|1991-12-25|Tokyo Shibaura Electric Co|

---

US4489387A|1981-08-20|1984-12-18|Lamb David E|Method and apparatus for coordinating medical procedures|

---

US4926495A|1986-12-11|1990-05-15|Motorola, Inc.|Computer aided dispatch system|

---

US4858121A|1986-12-12|1989-08-15|Medical Payment Systems, Incorporated|Medical payment system|

---

US4839822A|1987-08-13|1989-06-13|501 Synthes |Computer system and method for suggesting treatments for physical trauma|

---

US4945476A|1988-02-26|1990-07-31|Elsevier Science Publishing Company, Inc.|Interactive system and method for creating and editing a knowledge base for use as a computerized aid to the cognitive process of diagnosis|

---

US5063522A|1988-03-15|1991-11-05|Intellisystems, Inc.|Multi-user, artificial intelligent expert system|

---

US4865549A|1988-04-14|1989-09-12|Kristicare, Inc.|Medical documentation and assessment apparatus|

---

IT1219379B|1988-06-15|1990-05-11|Hospal Dasco Spa|METHOD AND EQUIPMENT FOR THE PREDICTION OF THE SIDE EFFECTS WHICH MANIFEST IN A PATIENT DURING A DIALYSIS TREATMENT|

---

US5253164A|1988-09-30|1993-10-12|Hpr, Inc.|System and method for detecting fraudulent medical claims via examination of service codes|

---

US5122959A|1988-10-28|1992-06-16|Automated Dispatch Services, Inc.|Transportation dispatch and delivery tracking system|

---

US5077666A|1988-11-07|1991-12-31|Emtek Health Care Systems, Inc.|Medical information system with automatic updating of task list in response to charting interventions on task list window into an associated form|

---

US5072383A|1988-11-19|1991-12-10|Emtek Health Care Systems, Inc.|Medical information system with automatic updating of task list in response to entering orders and charting interventions on associated forms|

---

US4922514A|1988-12-29|1990-05-01|Dictaphone Corporation|Method and apparatus for dispatching services|

---

US5193855A|1989-01-25|1993-03-16|Shamos Morris H|Patient and healthcare provider identification system|

---

US5086391A|1989-02-24|1992-02-04|Chambers Bryan R|Remote controller for activating speech messages and for contacting emergency services|

---

US5109399A|1989-08-18|1992-04-28|Alamo City Technologies, Inc.|Emergency call locating system|

---

US5065315A|1989-10-24|1991-11-12|Garcia Angela M|System and method for scheduling and reporting patient related services including prioritizing services|

---

US5759044A|1990-02-22|1998-06-02|Redmond Productions|Methods and apparatus for generating and processing synthetic and absolute real time environments|

---

US5255187A|1990-04-03|1993-10-19|Sorensen Mark C|Computer aided medical diagnostic method and apparatus|

---

US5761493A|1990-04-30|1998-06-02|Texas Instruments Incorporated|Apparatus and method for adding an associative query capability to a programming language|

---

US5822544A|1990-07-27|1998-10-13|Executone Information Systems, Inc.|Patient care and communication system|

---

US5594786A|1990-07-27|1997-01-14|Executone Information Systems, Inc.|Patient care and communication system|

---

US5291399A|1990-07-27|1994-03-01|Executone Information Systems, Inc.|Method and apparatus for accessing a portable personal database as for a hospital environment|

---

US5228449A|1991-01-22|1993-07-20|Athanasios G. Christ|System and method for detecting out-of-hospital cardiac emergencies and summoning emergency assistance|

---

US5754960A|1991-02-22|1998-05-19|Ericsson Inc.|Display console and user interface for multisite RF trunked system|

---

US5323444A|1991-08-16|1994-06-21|U S West Advanced Technologies, Inc.|Emergency call system with call capacity/last chance routing feature|

---

US5379337A|1991-08-16|1995-01-03|U S West Advanced Technologies, Inc.|Method and system for providing emergency call service|

---

EP0531889B1|1991-09-11|1998-11-11|Hewlett-Packard Company|Data processing system and method for automatically performing prioritized nursing diagnoses from patient assessment data|

---

US5516702A|1991-11-06|1996-05-14|Adeza Biomedical Corporation|Screening method for identifying women at increased risk for imminent delivery|

---

US5353793A|1991-11-25|1994-10-11|Oishi-Kogyo Company|Sensor apparatus|

---

US5502726A|1992-01-31|1996-03-26|Nellcor Incorporated|Serial layered medical network|

---

JP3144030B2|1992-02-24|2001-03-07|東陶機器株式会社|Health management network system|

---

US5745532A|1992-03-12|1998-04-28|Ntp Incorporated|System for wireless transmission and receiving of information and method of operation thereof|

---

US5544649A|1992-03-25|1996-08-13|Cardiomedix, Inc.|Ambulatory patient health monitoring techniques utilizing interactive visual communication|

---

US5441047A|1992-03-25|1995-08-15|David; Daniel|Ambulatory patient health monitoring techniques utilizing interactive visual communication|

---

US5339351A|1992-06-02|1994-08-16|Hoskinson John D|Emergency response system|

---

IT1264320B|1992-12-01|1996-09-23|SYSTEM FOR AUTOMATICALLY DISTRIBUTING CALLS TO RADIOTAXI|

---

US5912818A|1993-01-25|1999-06-15|Diebold, Incorporated|System for tracking and dispensing medical items|

---

US5423061A|1993-06-01|1995-06-06|Motorola, Inc.|Method for providing dispatch services to communication groups and multiple communication groups|

---

US5377258A|1993-08-30|1994-12-27|National Medical Research Council|Method and apparatus for an automated and interactive behavioral guidance system|

---

US5748907A|1993-10-25|1998-05-05|Crane; Harold E.|Medical facility and business: automatic interactive dynamic real-time management|

---

US5557254A|1993-11-16|1996-09-17|Mobile Security Communications, Inc.|Programmable vehicle monitoring and security system having multiple access verification devices|

---

AU1187495A|1993-11-29|1995-06-13|Greater Harris County 9-1-1 Emergency Network|Integrated data collection and transmission for emergency calls|

---

US6022315A|1993-12-29|2000-02-08|First Opinion Corporation|Computerized medical diagnostic and treatment advice system including network access|

---

US5660176A|1993-12-29|1997-08-26|First Opinion Corporation|Computerized medical diagnostic and treatment advice system|

---

US5594638A|1993-12-29|1997-01-14|First Opinion Corporation|Computerized medical diagnostic system including re-enter function and sensitivity factors|

---

US5471382A|1994-01-10|1995-11-28|Informed Access Systems, Inc.|Medical network management system and process|

---

US5590269A|1994-04-22|1996-12-31|Minnesota Mining & Manufacturing Company|Resource assignment system providing mixed-initiative user interface updates|

---

US5521812A|1994-05-06|1996-05-28|David L. Feder|Emergency information apparatus and method|

---

US5536084A|1994-05-09|1996-07-16|Grandview Hospital And Medical Center|Mobile nursing unit and system therefor|

---

US5630125A|1994-05-23|1997-05-13|Zellweger; Paul|Method and apparatus for information management using an open hierarchical data structure|

---

US5724983A|1994-08-01|1998-03-10|New England Center Hospitals, Inc.|Continuous monitoring using a predictive instrument|

---

US5513993A|1994-08-29|1996-05-07|Cathy R. Lindley|Educational 911 training device|

---

US5462051A|1994-08-31|1995-10-31|Colin Corporation|Medical communication system|

---

US5438996A|1994-10-12|1995-08-08|Triton Technology, Inc.|Ambulatory, ultrasonic transit time, real-time, cervical effacement and dilatation monitor with disposable probes|

---

US5842173A|1994-10-14|1998-11-24|Strum; David P.|Computer-based surgical services management system|

---

US5959580A|1994-11-03|1999-09-28|Ksi Inc.|Communications localization system|

---

US5636873A|1994-11-28|1997-06-10|Kristi L. Sonsteby|Medical documentation and assessment apparatus|

---

US5682419A|1995-01-26|1997-10-28|Grube; Gary W.|Method and apparatus for providing infrastructure call support|

---

CA2212574C|1995-02-13|2010-02-02|Electronic Publishing Resources, Inc.|Systems and methods for secure transaction management and electronic rights protection|

---

US5555015A|1995-03-20|1996-09-10|Intrinzix Technologies, Inc.|Wireless two way transmission between center and user stations via a relay|

---

AU5522396A|1995-03-29|1996-10-16|Ericsson Inc.|Console dispatch in an extended multisite radio communicatio ns network|

---

US5554031A|1995-04-20|1996-09-10|Retina Systems, Inc.|Training system for reporting 911 emergencies|

---

US5719918A|1995-07-06|1998-02-17|Newnet, Inc.|Short message transaction handling system|

---

US5734706A|1995-07-27|1998-03-31|Windsor; Victoria Brein|Caller identification and data retrieval system|

---

US5844817A|1995-09-08|1998-12-01|Arlington Software Corporation|Decision support system, method and article of manufacture|

---

JP3431367B2|1995-10-03|2003-07-28|東芝マイクロエレクトロニクス株式会社|Manufacturing method of nonvolatile semiconductor memory device|

---

US5961446A|1995-10-06|1999-10-05|Tevital Incorporated|Patient terminal for home health care system|

---

US5832187A|1995-11-03|1998-11-03|Lemelson Medical, Education & Research Foundation, L.P.|Fire detection systems and methods|

---

US5809493A|1995-12-14|1998-09-15|Lucent Technologies Inc.|Knowledge processing system employing confidence levels|

---

US5926526A|1995-12-29|1999-07-20|Seymour A. Rapaport|Method and apparatus for automated patient information retrieval|

---

US5805670A|1996-03-19|1998-09-08|Life Safety Solutions, Inc.|Private notification system for communicating 9-1-1 information|

---

US6112083A|1996-03-27|2000-08-29|Amsc Subsidiary Corporation|Full service dispatcher for satellite trunked radio service system|

---

US6106459A|1996-03-29|2000-08-22|Clawson; Jeffrey J.|Method and system for the entry protocol of an emergency medical dispatch system|

---

US5989187A|1996-03-29|1999-11-23|Medical Priority Consultants, Inc.|Method and system for giving remote emergency medical counseling for childbirth patients|

---

US6004266A|1996-03-29|1999-12-21|Clawson; Jeffrey J.|Method and system for the heart problem protocol of an emergency medical dispatch system|

---

US6010451A|1996-03-29|2000-01-04|Clawson; Jeffrey J.|Method and system for giving remote emergency medical counsel to choking patients|

---

US5857966A|1996-03-29|1999-01-12|Clawson; Jeffrey J.|Method and system for the unconscious or fainting protocol of an emergency medical dispatch system|

---

US6053864A|1996-03-29|2000-04-25|Clawson; Jeffrey J.|Method and system for giving remote emergency medical counsel to arrest patients|

---

US5901214A|1996-06-10|1999-05-04|Murex Securities, Ltd.|One number intelligent call processing system|

---

US5787429A|1996-07-03|1998-07-28|Nikolin, Jr.; Michael A.|Potential hazard and risk-assessment data communication network|

---

US5823948A|1996-07-08|1998-10-20|Rlis, Inc.|Medical records, documentation, tracking and order entry system|

---

US6035187A|1996-10-30|2000-03-07|Comarco Wireless Technologies, Inc.|Apparatus and method for improved emergency call box|

---

US7016856B1|1996-12-13|2006-03-21|Blue Cross Blue Shield Of South Carolina|Automated system and method for health care administration|

---

US5933780A|1997-02-21|1999-08-03|Connor; James M.|Method and apparatus for enhanced logged supergroup/multigroup call retrieval|

---

US6076065A|1997-03-28|2000-06-13|Clawson; Jeffrey J.|Method and system for the pregnancy condition protocol of an emergency medical dispatch system|

---

US6078894A|1997-03-28|2000-06-20|Clawson; Jeffrey J.|Method and system for evaluating the performance of emergency medical dispatchers|

---

US6968375B1|1997-03-28|2005-11-22|Health Hero Network, Inc.|Networked system for interactive communication and remote monitoring of individuals|

---

US5902234A|1997-04-10|1999-05-11|Webb; Nicholas J.|Medical communication system for ambulatory home-care patients|

---

US5991751A|1997-06-02|1999-11-23|Smartpatents, Inc.|System, method, and computer program product for patent-centric and group-oriented data processing|

---

US6040770A|1997-09-05|2000-03-21|Britton; Rick A.|Communication path integrity supervision in a network system for automatic alarm data communication|

---

US5991730A|1997-10-08|1999-11-23|Queue Corporation|Methods and systems for automated patient tracking and data acquisition|

---

US5850611A|1997-11-07|1998-12-15|Motorola, Inc.|Method and apparatus for communicating in a dispatch communication system|

---

US6115646A|1997-12-18|2000-09-05|Nortel Networks Limited|Dynamic and generic process automation system|

---

US6134105A|1998-01-06|2000-10-17|Lueker; Mark David|Portable command center|

---

US6117073A|1998-03-02|2000-09-12|Jones; Scott J.|Integrated emergency medical transportation database system|

---

US20020106059A1|1998-06-16|2002-08-08|Kroll Mark W.|Public service answering point with automatic triage capability|

---

US6370234B1|1998-06-16|2002-04-09|Kroll Family Trust|Public service answering point with automatic triage capability|

---

US6052574A|1998-06-22|2000-04-18|Lucent Technologies Inc.|Auxiliary monitoring of emergency access calls|

---

US6118866A|1998-08-03|2000-09-12|Geneys Telecommunications Laboratories, Inc.|Emergency call load management for call centers|

---

US6594634B1|1998-09-14|2003-07-15|Medtronic Physio-Control Corp.|Method and apparatus for reporting emergency incidents|

---

US6074345A|1998-10-27|2000-06-13|University Of Florida|Patient data acquisition and control system|

---

US6901397B1|1999-02-05|2005-05-31|Gte Service Corporation|Method and apparatus for providing web-based assistance to customers and service representatives|

---

US6535121B2|1999-04-09|2003-03-18|Richard K. Matheny|Fire department station zoned alerting control system|

---

US20100198755A1|1999-04-09|2010-08-05|Soll Andrew H|Enhanced medical treatment|

---

WO2000068913A1|1999-05-10|2000-11-16|Junji Uchida|Emergency dispatching system|

---

US20020007285A1|1999-06-18|2002-01-17|Rappaport Alain T.|Method, apparatus and system for providing targeted information in relation to laboratory and other medical services|

---

US6292542B1|1999-08-11|2001-09-18|At&T Corp.|Method and apparatus for handling an in-call request for emergency services|

---

US7194395B2|2000-02-23|2007-03-20|The United States Of America As Represented By The Secretary Of The Army|System and method for hazardous incident decision support and training|

---

US6610012B2|2000-04-10|2003-08-26|Healthetech, Inc.|System and method for remote pregnancy monitoring|

---

US20020004729A1|2000-04-26|2002-01-10|Christopher Zak|Electronic data gathering for emergency medical services|

---

US6931112B1|2000-06-12|2005-08-16|Aspect Communications Corporation|User invoked directed outdial method and apparatus|

---

US8043224B2|2000-07-12|2011-10-25|Dimicine Research It, Llc|Telemedicine system|

---

US7428301B1|2000-10-09|2008-09-23|Clawson Jeffrey J|Method and system for the exit protocol of an emergency medical dispatch system|

---

US6607481B1|2000-10-10|2003-08-19|Jeffrey J. Clawson|Method and system for an improved entry process of an emergency medical dispatch system|

---

US20030028536A1|2001-02-27|2003-02-06|Singh Hartej P.|Proactive emergency response system|

---

US20030050538A1|2001-05-29|2003-03-13|Morteza Naghavi|System and method for medical observation system located away from a hospital|

---

US6879819B2|2001-06-25|2005-04-12|Denso Corporation|Control and messaging during emergency calls|

---

US8417533B2|2001-09-25|2013-04-09|Jeffrey J. Clawson|Method and system for the fire response dispatch protocol of an emergency dispatch system|

---

US7436937B2|2001-09-26|2008-10-14|Clawson Jeffrey J|Method and system for the police response dispatch protocol of an emergency dispatch system|

---

JP4936094B2|2001-09-28|2012-05-23|株式会社エクォス・リサーチ|Agent device|

---

JP2003187003A|2001-12-20|2003-07-04|Hikari Ishii|Emergency medical treatment providing method|

---

JP2003256963A|2002-03-04|2003-09-12|Hitachi Ltd|Fire fighting emergency information system and its processing program|

---

US7024370B2|2002-03-26|2006-04-04|P) Cis, Inc.|Methods and apparatus for early detection of health-related events in a population|

---

US7106835B2|2002-04-16|2006-09-12|Medical Priority Consultants, Inc.|Method and system for integrating a computer aided dispatch system with an emergency medical dispatch protocol|

---

US8494868B2|2002-05-07|2013-07-23|Priority Dispatch Corporation|Method and system for a seamless interface between an emergency medical dispatch system and a nurse triage system|

---

US20060026035A1|2004-07-28|2006-02-02|William Younkes|Computer aided interactive medical management information and control system and method|

---

US7764769B2|2004-08-06|2010-07-27|Powerphone, Inc.|Integrated call handler and email systems and methods|

---

US7646858B2|2004-08-06|2010-01-12|Powerphone, Inc.|Protocol builder for a call handling system|

---

US20060059423A1|2004-09-13|2006-03-16|Stefan Lehmann|Apparatus, system, and method for creating customized workflow documentation|

---

US20060122520A1|2004-12-07|2006-06-08|Dr. Matthew Banet|Vital sign-monitoring system with multiple optical modules|

---

US7805191B2|2005-01-31|2010-09-28|Physio-Control, Inc.|CPR time indicator for a defibrillator data management system|

---

US20070112275A1|2005-08-15|2007-05-17|Cooke William H|Medical Intervention Indicator Methods and Systems|

---

KR100759916B1|2005-10-21|2007-09-18|연세대학교 산학협력단|Emergency medical information system for transferring patient to the medical institute by triage-result|

---

US7703020B2|2006-03-31|2010-04-20|General Electric Company|Medical diagnostic system interface|

---

US20100004710A1|2006-07-26|2010-01-07|Scientific Pathways International, LLC.|Cpr analysis system and method|

---

CN101169840B|2006-10-26|2016-09-28|杰弗里·J·克劳森|Method and system for the exit protocol of emergent medical condition scheduling system|

---

US7783586B2|2007-02-26|2010-08-24|International Business Machines Corporation|System and method for deriving a hierarchical event based database optimized for analysis of biological systems|

---

US8630867B2|2007-04-23|2014-01-14|Samsung Electronics Co., Ltd.|Remote-medical-diagnosis system method|

---

US7645234B2|2007-06-13|2010-01-12|Clawson Jeffrey J|Diagnostic and intervention tools for emergency medical dispatch|

---

US8066638B2|2007-06-13|2011-11-29|Clawson Jeffrey J|Diagnostic and intervention tools for emergency medical dispatch|

---

US20090191529A1|2008-01-24|2009-07-30|Mozingo David W|Video game-based, immersive, advanced burn care educational module|

---

JP5120557B2|2008-07-25|2013-01-16|勲 齋藤|Emergency response system for home care recipients|US8335298B2|2009-09-14|2012-12-18|Clawson Jeffrey J|Pandemic diagnostic and intervention tool for emergency dispatch|

---

US8294570B2|2010-02-24|2012-10-23|Clawson Jeffrey J|Burn diagnostic and intervention tool for emergency dispatch|

---

GB2489875A|2011-01-19|2012-10-10|Jeffrey Johnson Clawson|Meningitis diagnostic and intervention tool for emergency dispatch|

---

US8670526B2|2011-02-11|2014-03-11|Jeffrey J. Clawson|Hate crime diagnostic and intervention tool for emergency dispatch|

---

GB2501680A|2011-02-11|2013-11-06|Jeffrey Johnson Clawson|Anti-social protocol for emergency dispatch|

---

US8396191B2|2011-02-11|2013-03-12|Jeffrey J. Clawson|Anti-social protocol for emergency dispatch|

---

US8712020B2|2012-09-06|2014-04-29|Jeffrey J. Clawson|Pandemic protocol for emergency dispatch|

---

SG11201505146RA|2013-01-31|2015-07-30|Jeffrey J Clawson|System and method for text messaging for emergency response|

---

US8873719B2|2013-01-31|2014-10-28|Jeffrey J. Clawson|Active assailant protocol for emergency dispatch|

---

US20140314212A1|2013-04-22|2014-10-23|Avaya Inc.|Providing advisory information associated with detected auditory and visual signs in a psap environment|

---

GB2513643B|2013-05-02|2017-03-22|CantelLtd|Medical accessory holder|

---

US9307383B1|2013-06-12|2016-04-05|Google Inc.|Request apparatus for delivery of medical support implement by UAV|

---

JP6336252B2|2013-07-17|2018-06-06|キヤノン株式会社|Report creation support apparatus, control method thereof, and program|

---

US9516166B1|2015-05-28|2016-12-06|Jeffrey J. Clawson|Chemical suicide protocol for emergency response|

---

US10657614B2|2015-12-23|2020-05-19|Jeffrey J. Clawson|Locator diagnostic system for emergency dispatch|

---

EP3393386B1|2015-12-24|2020-06-24|CantelLimited|Medical accessory holder|

---

US9877171B2|2016-04-08|2018-01-23|Jeffrey J. Clawson|Picture/video messaging protocol for emergency response|

---

US10623555B2|2016-09-27|2020-04-14|Hartford Fire Insurance Company|Controlling a graphical user interface for workflow|

---

US20190318290A1|2018-04-13|2019-10-17|Jeffrey Clawson|Medical transfer protocol system and method|

---

EP3782357A4|2018-04-19|2022-01-05|Jeffrey J Clawson|Expedited dispatch protocol system and method|

法律状态:
2019-01-15| B06F| Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]|

---

2019-07-23| B06U| Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]|

---

2020-07-14| B06A| Patent application procedure suspended [chapter 6.1 patent gazette]|

---

2020-10-13| B09A| Decision: intention to grant [chapter 9.1 patent gazette]|

---

2020-12-08| B16A| Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]|Free format text: PRAZO DE VALIDADE: 10 (DEZ) ANOS CONTADOS A PARTIR DE 08/12/2020, OBSERVADAS AS CONDICOES LEGAIS. |

优先权:

---

申请号 | 申请日 | 专利标题

---

US12/558,045|2009-09-11|

---

US12/558,045|US8355483B2|2009-09-11|2009-09-11|Stroke diagnostic and intervention tool for emergency dispatch|

---

PCT/US2010/043308|WO2011031382A1|2009-09-11|2010-07-27|Stroke diagnostic and intervention tool for emergency dispatch|

---