Method and apparatus for reporting emergency incidents

0001[0001] This application claims priority from U.S. application Ser. No. 09/152,837, filed Sep. 14, 1998, the entire content of which is incorporated herein by reference

FIELD OF THE INVENTION

[0002] This invention generally relates to a method and apparatus for allowing a trained emergency service provider to report emergency incidents and, more specifically, a method and apparatus for allowing an emergency service provider to electronically collect and record information regarding an emergency incident and generate a meaningful report of such data.

BACKGROUND OF THE INVENTION

[0003] Emergency care is commonly delivered to a patient at the scene of an incident by trained emergency service providers such as paramedics, police officers, emergency medical technicians (EMTs), etc. These providers work within a community-based Emergency Medical System (EMS) under the supervision of a medical director who establishes operating protocols, oversees training, and monitors the system's effectiveness. System effectiveness is assessed primarily by evaluating patient outcomes, often through secondary measures that are closely associated with long-term survival such as response time, protocol adherence, and time to delivery of effective therapy. Typically, such information is recorded manually by the emergency service provider in a paper run report including a patient information portion for recording personal patient data, a narrative portion for recording the emergency service provider's clinical narrative, and an event log portion for recording each of the treatment events that take place during the incident and their associated times of occurrence. Consequently, the report captures the time interval for the EMS to respond to the call for help, the patient's presenting signs and symptoms, the delay until therapy is applied, etc. The run report can then be later used to produce statistical summaries of overall EMS response characteristics. One example of a statistical analysis report based on a run report is the Utstein Style report for measuring response effectiveness in cases where the patient has suffered cardiac arrest.

[0004] In order to generate incident run reports and statistical summaries such as the ones specified by the Utstein Style, raw event data must reliably collected, coded, and entered into a database. Often, the sources of raw event data are widely dispersed. Dispatch event information is provided by a Computer-Aided Dispatch (CAD) system, while vital signs and therapeutic information events are found in medical devices used on-scene during patient treatment. Emergency service provider narratives are often written into run reports produced after the incident is concluded. It is difficult for any EMS system to collate these disparate pieces of information into a single database. Often the sequence of events and their exact times can only be approximated from the records. The event log recorded in the run report can be especially inaccurate, since it is often compiled after-the-fact, perhaps days later, from memory and written notes. Efforts to introduce electronic versions of paper run reports for on-scene event capture have not been successful because the equipment is bulky and expensive, its use interferes with patient care, and the menu-driven database interface fails to capture the full range of essential events needed. A particular failing is that the accurate event times are not recorded along with the events themselves, making calculation of response intervals inaccurate.

[0005] In order to more accurately record information critical to reconstructing incident events accurately, a more versatile, focused approach to electronic data collection for run reports is needed. The approach should provide for recordation of simple background information, such as the patient's name and the incident location, as well as a summary of each event that occurred during the emergency incident and the particular time of the event. To be useful, the associated time should be accurate to within one minute. Finally, the approach should provide for capture of a clinical narrative by the emergency service provider which is the provider's account of the incident, including the provider's subjective appraisal, objective findings, and the assessments performed, and the provider's planned therapies and procedures. The approach should collect all of this information, and merge the information with CAD and medical device data to populate the database needed for incident reporting and assessment of system effectiveness.

SUMMARY OF THE INVENTION

[0006] The present invention provides a computer-readable medium having computer-executable components for recording and reporting an emergency incident comprising a plurality of events associated with treatment of a patient during the incident. The computer executable components include an event recording component and a post-processing component. The event recording component records events as they occur during the incident, while the post-processing component further processes the events recorded by the event recording component once the incident has concluded.

[0007] The event recording component records events by enabling a emergency service provider to input a plurality of event records, wherein each event record identifies an event which occurred during the incident and a time at which the event occurred. The event recording component also records events input by the emergency service provider as a predefined treatment protocol for the patient, wherein the predefined treatment protocol comprises a plurality of predefined event records and wherein each predefined event record identifies an event which is expected to occur during the incident and a time at which the event is expected to occur during the incident. Finally, the event recording component includes at least one subcomponent for providing information regarding the incident in addition to the event records recorded by the event recording component. The subcomponent may be an address book component, a drug guideline component, a medication identification component, a narrative story component, a stop watch component or a drug dosage/infusion component.

[0008] The post-processing component, on the other hand, enables the user to modify the event records previously recorded by the event recording component, as well as record additional information regarding the incident. In addition, the post-processing component incorporates event records recorded by an external source, such as a remote computer or medical electronic device, with the event records previously recorded by the event recording component. The post-processing component also exports event records to external devices, such as a remote computer, for further processing and record-keeping. Finally, the post-processing component generates a run report containing event records and related information recorded and processed by the event recording component and the post-processing component.

[0009] In accordance with yet other aspects of the present invention, the event recording component and the post-processing component enable the user to verbally input event records and related information.

[0010] A method and apparatus capable of performing actions generally consistent with the event recording component and the post-processing component described above represent further aspects of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS

0011[0011] The foregoing aspects and many of the attendant advantages of this invention will become more readily appreciated as the same becomes better understood by reference to the following detailed description, when taken in conjunction with the accompanying drawings, wherein:

0012[0012]FIG. 1 is an isometric view of a hand-held computer that is installed with an event reporting program formed in accordance with the present invention to record and report an emergency incident;

0013[0013]FIG. 2 is a schematic block diagram of the several components of the hand-held computer shown in FIG. 1, that are used to implement the event reporting program and record and report emergency incidents in accordance with the present invention;

0014[0014]FIG. 3 is a flow chart illustrating the logic used by the event reporting program to record and report emergency incidents;

0015[0015]FIG. 4 depicts an initial incident reporting window produced by the event reporting program for recording incident identification information;

0016[0016]FIG. 5 is a flowchart illustrating the logic used by the event reporting program to record events and related information during the emergency incident;

0017[0017] FIGS. <b>6</b>A-<b>6</b>L are various windows produced by the event reporting program for recording events and related information during the emergency incident;

0018[0018]FIG. 7 is a flowchart illustrating the logic used by the event reporting program to further process events and related information after the occurrence of the emergency incident;

0019[0019] FIGS. <b>8</b>A-<b>8</b>F are various windows produced by the event reporting program for further processing events and related information after the occurrence of the emergency incident; and

0020[0020]FIG. 9 is a flowchart illustrating the logic used to parse a clinical narrative previously recorded by the emergency provider for certain pertinent information.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

0021[0021]FIG. 1 illustrates a hand-held computer <b>20</b> used to record and report emergency incidents in accordance with the present invention. More specifically, the hand-held computer <b>20</b> shown in FIG. 1 is installed with an event reporting program <b>48</b> formed in accordance with the present invention to electronically record and report emergency incidents. The hand-held computer <b>20</b> comprises a touch screen display <b>32</b> for displaying the windows produced by the event recording program <b>48</b> of the present invention to prompt an emergency service provider to record events and related information that occur during an emergency incident. In order to record information and events, the emergency service provider selects options provided by the displayed windows using a touch screen pen <b>22</b>. In addition, the emergency service provider may record information and events using a keyboard <b>30</b>. In yet other embodiments of the present invention, the hand-held computer <b>20</b> includes a speaker/microphone <b>24</b> and appropriate voice recognition software for recognizing voice commands and recording the voice input of events and information. Those of ordinary skill in the art will appreciate that such voice recognition software is readily available off-the-shelf and can be installed on the hand-held computer in addition to the event reporting program <b>48</b>. Further, the hand-held computer <b>20</b> may be equipped with a high quality digital data recorder and a noise canceling microphone in order to allow for better usage of the event reporting program in typically noisy and turbulent EMS field situations. Consequently, the emergency service provider can control the event reporting program <b>48</b> and record events and related information merely by speaking, rather than using a more traditional user input device such as a mouse, keypad, or touch screen/pen, etc. As a result, the emergency service provider has the free use of his or her hands to treat the patient at all times and need not interrupt treatment to operate the event reporting program <b>48</b>.

0022[0022] Those of ordinary skill in the art will recognize that although a hand-held computer <b>20</b> is depicted in FIG. 1, the event reporting software program <b>48</b> of the present invention can be installed and implemented on any type of portable data entry system, including but not limited to, a laptop computer, a personal device assistant, or even a medical electronic device such as a defibrillator. In addition, the portable data entry system may implement any type of user input device such as a mouse, keypad, touch screen, microphone, wireless headset, etc. to input events and related incident information. In yet other embodiments, the event reporting program <b>48</b> may be installed on a more stationary computer system, such as a personal computer or workstation.

0023[0023]FIG. 2 depicts several of the key components of the hand-held computer <b>20</b>. It will be appreciated by those of ordinary skill in the art that the hand-held computer <b>20</b> includes many more components than those shown in FIG. 2. However, a disclosure of an actual embodiment for practicing the present invention does not require that all of these generally conventional components be shown. The hand-held computer <b>20</b> includes a processing unit <b>34</b> coupled to the touch screen display <b>32</b> and a memory <b>44</b>. The memory <b>44</b> comprises a conventional disc, read-only memory, and a random access memory for storing the event report program <b>48</b> of the present invention, as well as a set of patient records <b>46</b> and a set of master tables <b>50</b>. The set of patient records <b>46</b> consist of a record <b>46</b> for each patient treated during an emergency incident. Each patient record <b>46</b> includes all of the events and related information recorded by the emergency service provider, including but not limited to personal and background information for the patient, a clinical narrative of the incident, and each event recorded during the incident. The master tables <b>50</b>, on the other hand, store patient independent information, such as address books, drug guidelines and other reference materials commonly used by emergency service providers in treatment of patients and made available by the event reporting program <b>48</b> as described in more detail below. In addition, the master tables <b>50</b> store various menus from which the emergency service provider may select predefined events and other information for recordation during the incident. Consequently, the emergency service provider need not manually input each event as it occurs.

0024[0024] Those of ordinary skill in the art will appreciate that due to the limited memory space in hand-held computer <b>20</b>, the patient records <b>46</b> containing the patient and incident information input by the emergency service provider, and the master tables <b>50</b> containing patient independent information are stored in simple tables in memory <b>44</b> of the hand-held computer <b>20</b>. If the event reporting program <b>48</b> were installed in a more sophisticated device, such as a personal computer or laptop computer, with greater memory capabilities, the patient records <b>46</b> and master tables <b>50</b> would be stored in a database capable of being accessed and manipulated by a wider variety of database tools. In some embodiments of the present invention, the database in which the patient records are stored comprises a relational database which can be more flexibly accessed and manipulated.

0025[0025] As also shown in FIG. 2, the processing unit <b>34</b> is coupled to a keyboard <b>30</b> and a microphone/speaker <b>40</b> which may be used in addition to or instead of the touch screen <b>32</b> and pen <b>22</b> to input events and related incident information and control the event reporting program <b>48</b>. As will be described in more detail below, each event input by an emergency service provider via the touch screen pen <b>22</b> and display <b>32</b>, the microphone/speaker <b>40</b>, and/or the keyboard <b>30</b> is stored in a patient record <b>46</b> in memory <b>44</b> with the time the event is input as provided by a clock <b>36</b> coupled to the processing unit <b>34</b>.

0026[0026] Finally, the hand-held computer <b>20</b> includes an external interface <b>42</b> through which the hand-held computer <b>20</b> may transfer recorded events and related information to and from the hand-held computer <b>20</b> and an external device. For example, in some embodiments of the present invention, the hand-held computer <b>20</b> may import events and related information through the external interface <b>42</b> from a remote Computer-Aided Dispatch (CAD) system or from another medical device such as a defibrillator. Conversely, the hand-held computer <b>20</b> may export events and related information stored in the patient records <b>46</b> and master tables <b>50</b> of the memory <b>44</b> through the external interface <b>42</b> to a remote device, such as a computer located at the hospital to which the patient will be admitted. In one actual embodiment of the present invention, the external interface <b>42</b> comprises a modem which will establish a communications link with the external device with which the hand-held computer is communicating. In yet other embodiments of the present invention, the external interface <b>42</b> comprises serial input and output ports directly connected to the external device with which the hand-held computer is communicating.

0027[0027] Now that the components of the hand-held computer <b>20</b> which are necessary for implementing the event reporting program <b>48</b> of the present invention have been described, the event report program <b>48</b> itself will be described in further detail. FIG. 3 illustrates the logic used by the event reporting program <b>48</b> to record and report an emergency incident. It will be appreciated that the event reporting program <b>48</b> will typically be started up by the emergency service provider on route to the emergency incident or soon after arriving. Accordingly, the event reporting program <b>48</b> begins in a block <b>200</b> and proceeds to a block <b>202</b> in which the emergency service provider uploads a user identification, e.g., the name of the emergency service provider, and an identification number for the incident. More specifically, the event reporting program <b>48</b> produces an open incident window <b>52</b> on the display <b>32</b> of the hand-held computer <b>20</b> as shown in FIG. 4 through which the emergency service provider enters his or her name in a user identification field <b>54</b>, as well as the incident identification number in an incident identification field <b>56</b>. It will be appreciated that the user's identification and the incident's identification number may be entered by the emergency service provider using the keyboard <b>30</b> of the hand-held computer <b>20</b> or voice prompting via the speaker/microphone <b>24</b>, or by selecting the provider identification and the incident identification from predefined menus. Once the necessary information has been input, the emergency service provider may continue with the event reporting program <b>48</b> by selecting a begin button <b>58</b>.

0028[0028] Returning to FIG. 3, the event reporting program <b>48</b> proceeds to a block <b>20</b> in which the emergency service provider begins recording events that occur during the emergency incident. As will be described in more detail below, the emergency service provider may record events which occur during the emergency incident using a series of windows produced by the event reporting program <b>48</b>. The emergency service provider may also input additional information regarding the incident and the patient being treated. Following the incident, the emergency service provider may further process the events and related information that were recorded during the incident in order to produce a more accurate run report regarding the entire incident. In this regard, the event reporting program <b>48</b> post-processes the events and related information in a block <b>206</b>. Once post-processing is complete, the event reporting program <b>48</b> ends in a block <b>208</b>.

0029[0029] Returning to block <b>204</b>, once the name of the service provider and the identification number for the incident have been uploaded via the open incident window <b>52</b>, the event recording component of the event reporting program <b>48</b> is instigated. The logic implemented by the event recording component of the program is shown in more detail in FIG. 5. The logic begins in a block <b>210</b> and proceeds to a block <b>212</b> where the “arrive patient” data for the incident is automatically stored in the patient's record <b>46</b>. In this regard, the event reporting program <b>48</b> generates an event recorder window <b>60</b> as shown in FIG. 6A. The event recorder window <b>60</b> includes an event summary <b>62</b> which displays an event record <b>68</b> for each event recorded by the emergency service provider during an incident. Each event record <b>68</b> essentially comprises an event/time pair, i.e., a description of the event itself and a time at which the event occurred. The description of the event itself can be broken down into a common descriptor for the event, e.g., “arrive patient” or “shock,” and additional detail for the event, e.g., “200J” for a shock event. Similarly, the time at which the event occurred may be broken down into a time as read by the clock <b>36</b> at which the event was input by the emergency service provider (which should approximate the time the actual event occurred within one minute if promptly input by the emergency service provider), and an expected time for the event to occur (which can be determined based on the time registered by the clock <b>36</b> and a time interval during which the event is expected to occur according to EMS and other accepted guidelines). As will be described in more detail below, the emergency service provider can input a treatment protocol comprising a collection of predefined events (wherein each predefined event is associated with an expected time of occurrence), rather than input events individually, one-by-one as they occur. It will be appreciated that each event record <b>68</b> and thus, each event/time pair, may include either an actual time, an expected time, or both. Each event/time pair must also include an event description, although additional detail is not always required. Each event record <b>68</b> comprising an event/time pair is represented in the event summary <b>62</b> with a time field <b>68</b><i>a </i>containing the time as registered by the clock <b>36</b> at which the emergency service provider input the event; an expected time field <b>68</b><i>b </i>containing an automatically logged time at which the event is expected to occur during the incident; an event field <b>68</b><i>c </i>containing a common descriptor for the event input by the emergency service provider; and a detail field <b>68</b><i>d </i>containing additional detail and information regarding the event. As will be described in more detail below, an event record <b>68</b> will be added to the event summary <b>62</b> contained in the event recorder window <b>60</b> as each event occurs and is input by the emergency service provider during the incident.

0030[0030] As mentioned above, there are a number of ways in which the emergency service provider may record events and related information via the event recorder window <b>60</b>. For example, the emergency service provider may add individual events and related detail by inputting an event descriptor in an event selection field <b>64</b> and inputting related information in a detail field <b>66</b> in the event recorder window <b>60</b>. In addition, the emergency service provider may select a treatment protocol, i.e., a predefined set of events, to the event summary window <b>62</b> from the protocol selection field <b>70</b>. Finally, the emergency service provider can initiate a variety of tools from the event recorder window <b>60</b> to aid in treatment of the patient during the incident. For example, the emergency service provider may initiate an address book tool by selecting an address book button <b>72</b><i>a; </i>a drug guide tool by selecting a drug guide tool button <b>72</b><i>b; </i>a medication tool by selecting a medication tool button <b>72</b><i>c; </i>a narrative tool by selecting a narrative tool button <b>72</b><i>d; </i>a stopwatch tool by selecting a stopwatch tool button <b>72</b><i>e; </i>and a dosage calculating tool by selecting dosage tool button <b>72</b><i>f. </i>

0031[0031] Returning to block <b>212</b> of FIG. 5 and the arrival of the emergency service provider to the emergency incident, it will be appreciated that the event reporting program <b>48</b> automatically adds an event record <b>68</b> to the event summary <b>62</b> to record the arrival of the emergency service provider to the patient. More specifically, an event record <b>68</b> is added to the event summary <b>62</b> as soon as the emergency service provider begins the event recordation component of the program from the open incident window <b>52</b>. The expected time for the arrive patient event is stored in the expected time field <b>68</b><i>b </i>of the event record <b>68</b>. It will be appreciated that the expected time entered in this field is the time calculated by the event reporting program <b>48</b> based on the actual time provided by the clock <b>36</b> and a time interval during which the emergency service provider is reasonably expected to arrive at the patient. It will be appreciated that the calculation of this time interval will depend on the acceptable emergency response intervals promulgated by the provider's supervisory EMS. The event descriptor, i.e., “arrive patient” is also automatically entered in the event field <b>68</b><i>c </i>of the event record <b>68</b>. The event record is correspondingly stored in the patient record <b>46</b> for the patient in memory <b>44</b>. As will be described in more detail below, event records <b>68</b> can be further modified, added or deleted by the emergency service provider as necessary to provide a more accurate run report for the emergency incident. In addition, event records <b>68</b> may be exported to other devices for further processing and record keeping.

0032[0032] Returning to FIG. 5, once the arrive patient event record has been stored and displayed as part of the event summary <b>62</b>, the emergency service provider is free to add additional events as they occur during the incident, add treatment protocols as the emergency service provider deems necessary, and initiate the various tools described above as appropriate. In this regard, the event recording program <b>48</b> proceeds to a decision block <b>214</b> where it determines if the emergency service provider has selected to add, modify or delete an event record <b>68</b> from the event recorder window <b>60</b>. If so, the emergency service provider may add, edit, or delete an entire event, the actual time associated with an event, or the detail associated with an event in a block <b>216</b>. The event recorder windows <b>60</b> associated with such actions are shown in more detail in FIGS. <b>6</b>B-<b>6</b>D.

0033[0033] Referring to FIG. 6B, the emergency service provider may open an event menu <b>76</b> by tapping the touch screen pen <b>22</b> on the arrow of the event selection field <b>64</b>. The emergency service provider may then highlight the desired event descriptor from the menu of events displayed in the event menu window <b>76</b> using the touch screen pen <b>22</b>. For example, if the next event in the incident that occurs is the measurement of the patient's blood pressure, the emergency service provider may select the blood pressure event descriptor, i.e., “BP,” from the event menu <b>76</b> by either manually using the touch screen pen <b>22</b> or via voice prompt using the speaker/microphone <b>24</b>. The blood pressure event descriptor, “BP”, will then appear in the event selection field <b>64</b> as shown in FIG. 6B. The emergency service provider then may input additional detail regarding the blood pressure event either via the keyboard <b>30</b> or the speaker/microphone <b>24</b>. More specifically, the emergency service provider may input the systolic and diastolic pressures measured from the patient in a detail entry field <b>66</b>. As noted above, the menu of events displayed in the event menu window <b>26</b> is stored in memory <b>44</b> in the master tables <b>50</b>. If the displayed menu of events does not include the event desired by the emergency service provider, it will be appreciated that the provider may simply input the desired event descriptor using the keyboard <b>30</b> or via voice prompt using the speaker/microphone <b>24</b>. If voice prompting is used, the actual voice recording may be stored in memory <b>44</b> for later retrieval, reference, and/or transcription.

0034[0034] As shown in FIG. 6C, once the event selection field <b>64</b> and perhaps also, the detail entry fields <b>66</b> have been completed by the emergency service provider, the event reporting program <b>48</b> automatically adds an event record <b>68</b> containing the corresponding event/time pair to the event summary <b>62</b> as shown in FIG. 6D. The event record <b>68</b> includes the time at which the blood pressure was measured, i.e., the time registered on the hand-held computer's clock <b>36</b> when the blood pressure event was selected, in the event time field <b>68</b><i>a </i>of the event record <b>68</b>. The event descriptor, “BP,” is inserted in the event field <b>68</b><i>c </i>of the event record <b>68</b>; and the event detail, i.e., the measured systolic and diastolic pressures, are inserted in the detail field <b>68</b><i>d </i>of the event record <b>68</b>. Those of ordinary skill in the art will appreciate that for every event descriptor selected by the emergency service provider from the event menu <b>76</b> or input manually by the provider, a similar event record <b>68</b> will be added to the event summary <b>62</b>. Further, it will be appreciated that the event record <b>68</b> is stored in the patient's record <b>46</b> in memory <b>44</b> of the hand-held computer <b>20</b> for post-processing or for export to another device.

0035[0035] Returning to block <b>216</b> of FIG. 5, in addition to adding an event record <b>68</b> to the event summary <b>62</b>, the emergency service provider can also edit or delete an event record <b>68</b>. More specifically, if the emergency service provider wishes to modify an already added event record <b>68</b>, the emergency service provider need merely highlight the appropriate field <b>68</b><i>a</i>-<b>68</b><i>d </i>of the event record using the touch screen pen <b>22</b> or using voice input via the speaker/microphone <b>24</b> in order to modify the data contained in that field. For example, if the emergency service provider wishes to add additional detail in the detail field <b>68</b>, the emergency service provider can merely tap the data entry field <b>68</b><i>d </i>with the touch screen pen <b>22</b> and then add, modify or delete the information contained therein using the keyboard <b>30</b> of the hand-held computer <b>20</b> or voice prompting via the speaker/microphone <b>24</b>. The same procedure can be followed to modify, add or delete any of the data stored in any of the other fields <b>68</b><i>a, </i><b>68</b><i>b, </i>and <b>68</b><i>c. </i>Further, if the emergency service provider wishes to delete an event record in its entirety, the emergency service provider must merely highlight the entire record and enter the delete key (not specifically shown) contained on the keyboard <b>30</b> of the hand-held computer. As will be described in more detail below, the emergency service provider also has the option of editing, modifying, or deleting event records after the incident during post-processing.

0036[0036] Referring once again to FIG. 5, once the emergency service provider has added, edited or deleted an event record <b>68</b>, the logic returns to decision block <b>214</b> where the emergency service provider is again given the opportunity to add, modify or delete an event and/or its associated time stamp and detail. Accordingly, as treatment of the patient progresses during an emergency incident, the emergency service provider can record each event which occurs during treatment using the event reporting program <b>48</b>. However, returning to decision block <b>214</b>, the emergency service provider may, in fact, choose not to add an individual event. Rather, the provider may choose to record an entire treatment protocol as previously mentioned. In this regard, the event reporting program <b>48</b> determines in a decision block <b>218</b> if the emergency service provider has selected a treatment protocol from the treatment protocol field <b>70</b> of the event recorder window <b>60</b>. If so, the event reporting program <b>48</b> automatically adds the treatment protocol to the event summary <b>62</b> in a block <b>220</b>.

0037[0037] The event recorder window <b>60</b> produced by the event recording program <b>48</b> when a treatment protocol is added is shown in more detail in FIGS. 6E and 6F. Referring to FIG. 6E, the emergency service provider may select a treatment protocol by opening a protocol menu <b>78</b> and highlighting the desired protocol. For example, if the patient is experiencing cardiac arrest, the provider may wish to record a treatment protocol for cardiac arrest which includes all of the events one would most likely expect to occur during treatment of such a condition, e.g., CPR, delivery of a therapeutic shock, etc., and the time at which each of these events are expected to occur. Consequently, the emergency service provider need not record each event associated with treatment of the cardiac arrest one-by-one, and is free to give his or her full attention to the patient. However, as will be described in more detail below, the provider does have the ability to modify and delete any of the events added by selecting a protocol as necessary to create a more accurate run report. In addition, it will be appreciated from the description above that the provider can also record additional events that may have occurred during treatment but were not included in the selected protocol.

0038[0038] As shown in more detail in FIG. 6F, once the desired protocol has been selected (e.g., “Cardiac Arrest”) a predefined collection of event records <b>68</b> associated with treatment in accordance with the selected protocol is entered in the event summary <b>62</b>. Again, using the cardiac arrest example, the first event that typically occurs in the treatment of cardiac arrest is the performance of CPR. Accordingly, the event reporting program <b>48</b> enters an event record <b>68</b>′ for CPR, wherein the event record includes the time at which the emergency service provider is expected to perform CPR in the expected time field <b>68</b><i>b. </i>In addition, the event reporting program will insert a descriptor for the event, i.e., “CPR”, in the event field <b>68</b><i>c. </i>As yet another example, subsequent to performing CPR and monitoring the patient, the provider is expected to deliver a therapeutic shock to the patient. Accordingly, the treatment protocol includes an event record <b>68</b>″ containing the expected time of the shock in expected time field <b>68</b><i>b, </i>an event descriptor for the shock in event field <b>68</b><i>c, </i>and additional detail regarding the shock, e.g., <b>200</b>J, in detail entry field <b>68</b><i>d. </i>In accordance with yet other aspects of the present invention, once the expected time stored in the expected time field <b>68</b><i>b </i>for each protocol related event record expires, the event reporting program issues an audible alarm via the speaker/microphone <b>24</b> and/or a visual alarm via the display <b>32</b> to notify the emergency service provider that the expected treatment event must be administered.

0039[0039] As is apparent from the logic illustrated in FIG. 5, once the treatment protocol has been added in a block <b>220</b>, the logic returns to decision block <b>214</b> where it determines if the emergency service provider has elected to add, edit or delete an event record <b>68</b>. It follows that once a treatment protocol has been added to the event summary <b>62</b>, the emergency service provider can continue to add additional event records <b>58</b> to the event summary <b>62</b>, or can modify or previously recorded event records, including those added in association with a treatment protocol. Thus, if the emergency service provider modifies the treatment of the patient in any way from that automatically defined by the protocol, the emergency service provider is capable of modifying or deleting the appropriate event records, thus making for a more accurate incident run report.

0040[0040] Returning to FIG. 5, in addition to adding, editing or deleting event records <b>68</b> individually and in groups by selection of a treatment protocol, the emergency service provider may also initiate tools from the event recorder window <b>60</b> to assist him or her in treatment of the patient. In this regard, the logic proceeds to a decision block <b>222</b> where it determines if the emergency service provider has initiated a tool by selecting one of the tool buttons <b>72</b><i>a</i>-<b>72</b><i>f </i>from the event recorder window <b>60</b>. If so, the selected tool is implemented by the event reporting program <b>48</b> in block <b>224</b>. The event recorder windows <b>60</b> associated with each tool are shown in more detail in FIGS. <b>6</b>G-<b>6</b>L.

0041[0041] As shown in FIG. 6G, if the emergency service provider selects the address book button <b>72</b><i>a, </i>an address book window <b>80</b> is generated by the event reporting program <b>48</b>. From the address book window <b>80</b>, the emergency service provider may open an address menu <b>84</b> and select a desired address or telephone number using the touch screen pen <b>22</b>. For example, if the emergency service provider needs the telephone number for a particular hospital, the emergency service provider may select the phone number for the desired hospital from the address menu <b>84</b>.

0042[0042] If the emergency service record <b>68</b> provider selects the drug tool button <b>72</b><i>b, </i>a drug guideline window <b>86</b> is generated by the event reporting program <b>48</b> as shown in FIG. 6H. The emergency service provider may then retrieve from the master tables <b>50</b> stored in memory <b>44</b> of the hand-held computer, the guidelines for any drug with which the emergency service provider desires to treat the patient. The emergency service provider merely selects the desired drug from a drug menu (not shown) opened by tapping an arrow in a drug identification field <b>88</b> of the drug guideline window <b>86</b> with the touch screen pen <b>22</b> or by voice command. The associated information is retrieved from the master tables <b>50</b> stored in memory <b>44</b> and displayed in the drug guideline window <b>88</b>. Once information regarding the desired drug has been retrieved and displayed, the emergency service provider may opt to calculate an appropriate dosage for the drug by selecting a dose button <b>89</b>. The dosage calculation tool and the dosage calculation window <b>118</b> generated by the event reporting program <b>48</b> will be described in more detail below.

0043[0043] If the emergency service provider selects the patient medications button <b>72</b><i>c </i>in the event recorder window <b>60</b>, a patient medications window <b>90</b> is generated by the event reporting program <b>48</b> as shown in FIG. 6I. The emergency service provider may then select any medication the patient is currently taking from a medication menu <b>94</b> (supplied by the master table <b>50</b>). This medication information is then stored in memory <b>44</b> in the patient's record <b>46</b>.

0044[0044] If the emergency server provider selects the narrative button <b>72</b><i>d, </i>the event reporting program <b>48</b> generates a narrative story window <b>96</b> on the display <b>32</b> of the hand-held computer <b>20</b> as shown in FIG. 6J. The narrative story window <b>96</b> includes a narrative field <b>98</b> into which the emergency service provider may directly input information in a narrative format. It will be appreciated that the emergency service provider may input the narrative using the keyboard <b>30</b> of the hand-held computer <b>20</b>. However, in other embodiments of the present invention, in which the hand-held computer is equipped with a speaker/microphone <b>24</b> and voice recognition software, the emergency service provider may simply speak into the microphone <b>24</b> in order to input the narrative. If voice prompting is used, the emergency service provider may simply select a record button <b>100</b> using the touch screen pen <b>22</b> to initiate recording of his voice via the speaker/microphone <b>24</b>. If the emergency service provider wishes to play back the recorded narrative, the emergency service provider may select the play button <b>102</b> and if the emergency service provider wishes to erase any of the narrative, the emergency service provider may select the erase button <b>104</b>. Once the narrative has been recorded, the emergency service provider may exit the narrative story window <b>96</b> by selecting the close button <b>103</b>. Once completed, the text of the narrative is stored in the patient's record <b>46</b> in memory <b>44</b> of the hand-held computer <b>20</b>.

0045[0045] If the emergency service provider selects the stop watch tool button <b>72</b><i>e, </i>a stop watch window <b>106</b> is generated by the event reporting program <b>48</b> as shown in FIG. 6K. The stop watch tool allows the emergency service provider to time events, e.g., to time a particular treatment measure. For example, if the patient's pulse must be taken for sixty seconds, the emergency service provider may reset the stop watch to sixty seconds using the reset button <b>108</b> and start the countdown of the stop watch from sixty seconds using the start button <b>110</b>. When the stop watch expires, the emergency event program generates an audible tone via the speaker/microphone <b>24</b> of the hand-held computer <b>20</b> and/or via a visible message generated on the display. The emergency service provider can stop the stop watch at any time using the stop button <b>112</b>.

0046[0046] Finally, if the emergency service provider selects the dosage calculation button <b>72</b><i>f </i>from the event recorder window <b>60</b>, the event reporting program <b>48</b> generates a dosage/infusion calculator window <b>114</b> as shown in FIG. 6L. Accordingly, the emergency service provider may select the desired medication from a medication menu (not shown) opened, for example, by tapping an arrow in a medication field <b>116</b> of the dosage/infusion calculator window <b>114</b>. The emergency service provider may then input the information necessary for calculating the appropriate dosage for the selected medication in a dosage window <b>118</b>. The provider may also calculate an infusion rate for the selected medication by inputting the necessary information in an infusion window <b>120</b>. Once the appropriate information for calculating the dosage and/or infusion has been input by the provider, the emergency service provider may select a calculate button <b>122</b> to initiate calculation of the appropriate dosage/infusion. Those of ordinary skill in the art will recognize that the appropriate formulas for calculating dosage/infusion are well known in the art and thus, need not be described in more detail herein. If the emergency service provider wishes to calculate the dosage/infusion for another medication, the emergency service provider need only select the clear button <b>124</b> in the dosage/infusion calculator window <b>114</b>. If the emergency service provider desires more information regarding the selected medication, the emergency service provider may select the information button <b>126</b> from the dosage/infusion calculator <b>114</b>. In response, the event reporting program <b>48</b> will generate a drug guideline window <b>86</b> as shown in FIG. 6H and as associated with the drug guideline button <b>72</b><i>b </i>for the selected medication. Finally, as noted above, the emergency service provider may proceed to the dosage/infusion calculator window <b>118</b> via the drug guideline window <b>86</b> shown in FIG. 6H by selection of the dose button <b>89</b> in the drug guideline window <b>86</b>.

0047[0047] Returning to FIG. 5, once the tool selected by the emergency service provider has been implemented in a block <b>224</b>, the logic returns to decision blocks <b>214</b>, <b>218</b> and <b>222</b> as appropriate depending on the selections made by the emergency service provider. It follows from the above discussion that the emergency service provider may add event records, add treatment protocols and initiate tools in whatever order he or she deems necessary until the incident comes to a conclusion. At that time, the emergency service provider may select an end incident button <b>74</b> from the event recorder window <b>60</b> and the event recording component of the event reporting program <b>48</b> will be terminated. Accordingly, the result of a decision block <b>226</b> in FIG. 5 is positive, and the logic ends in a block <b>228</b>.

0048[0048] Returning to FIG. 3, once the event recording component of the event reporting program <b>48</b> has been completed in a block <b>204</b>, the post-processing component of the event reporting program begins in a block <b>206</b>. It will be appreciated that the post-processing of the events and related information recorded during the incident may occur at any time. For example, post-processing may occur while the emergency service provider is still at the scene of the incident, or after the provider delivers the patient to an emergency care facility. As will be described in more detail below, regardless of when post-processing occurs, the emergency service provider is allowed by the event reporting program <b>48</b> to add, modify and delete previously recorded events; add events recorded by external devices; add, modify and delete information regarding the patient; edit the previously recorded narrative; generate a complete incident run report; and/or export events and related information to external devices.

0049[0049] The logic employed by the post-processing component of the event reporting program <b>48</b> to post-process events is shown in more detail in FIG. 7. The logic begins in a block <b>230</b> and proceeds to a block <b>232</b> where the event reporting program <b>48</b> generates a post-event window <b>128</b> on the display <b>32</b> of the hand-held computer <b>20</b>. The post-event window <b>128</b> generated by the event reporting program is shown in more detail in FIG. 8A. Similar to the event recorder window <b>60</b>, the post-event window <b>128</b> includes an event summary <b>130</b> which displays a post event record <b>148</b> corresponding to each event record <b>68</b> that was recorded by the emergency service provider during the incident. Accordingly, each post event record <b>148</b> includes a time field <b>148</b><i>a, </i>an expected time field <b>148</b><i>b, </i>an event field <b>148</b><i>c </i>and a detail entry field <b>148</b><i>d. </i>However, the post event record <b>148</b> also includes a source field <b>148</b><i>e </i>which identifies the source of the recorded event. For example, if the event was recorded by the emergency service provider, the event reporting program <b>48</b> automatically enters the user identification of the emergency service provider in the source field <b>148</b><i>e. </i>If the event was recorded by a CAD system and imported to the event reporting program <b>48</b>, “CAD,” is identified as the source of the post event record <b>148</b>. Similarly, if the event was imported from an external device, such as a LIFEPAK® 12 defibrillator manufactured by Physio-Control Manufacturing Corporation of Redmond, Wash., the source field would identify the external device, e.g., “LP12,” as the source of the post event record <b>148</b>.

0050[0050] In addition to the event summary <b>130</b>, the post-event window <b>128</b> also includes a device event button <b>132</b>, a CAD event button <b>134</b>, a narrative data button <b>136</b>, an additional data button <b>138</b>, a narrative edit button <b>140</b>, a run report button <b>142</b>, an export data button <b>143</b>, a new case button <b>144</b> (for post processing another incident), and an exit button <b>146</b>. The actions taken by the event reporting program <b>48</b> as each of these buttons are selected by the emergency service provider will now be described in more detail.

0051[0051] Returning to FIG. 7, once the post-event window <b>128</b> has been displayed by the event reporting program <b>48</b> in a block <b>232</b>, the logic proceeds to a decision block <b>234</b> where it determines if the emergency service provider has elected to edit a post event record <b>148</b> by highlighting a post event record <b>148</b> in the event summary <b>130</b>. If so, the emergency service provider is allowed to edit the post event record <b>148</b> in a block <b>236</b>. More specifically, the event reporting program <b>48</b> generates an event edit window <b>150</b> as shown in FIG. 8B. The emergency service provider can delete the highlighted post event record <b>48</b> by selecting a delete event button <b>15</b>; modify the highlighted post event record <b>148</b> by inputting the appropriate information in a modify event field <b>154</b>; or insert a new post event record <b>148</b> immediately preceding the highlighted record by inputting the appropriate information in an insert new event field <b>156</b>. When modifying an existing post event record, the provider may add or edit the time of the event, the descriptor for the event, and/or the detail associated with the event. The emergency service provider may then save the post event record <b>148</b> in the patient's record <b>46</b> in memory <b>48</b> by selecting the save button <b>151</b>. Simultaneously, the corresponding post event record <b>148</b> is either deleted from, modified in, or added to the event summary <b>130</b>.

0052[0052] Returning to FIG. 7, if the emergency service provider does not wish to edit a post event record <b>148</b> or selects this option and does so, the logic proceeds to a decision block <b>238</b> where it determines if the emergency service provider has opted to add Computer-Aided Dispatch, “CAD,” events to the event summary <b>130</b> by selecting the CAD event button <b>134</b> as shown in FIG. 8C. CAD events are those that are registered by an external CAD system, typically the CAD system that dispatched the emergency service provider to the incident. By establishing a communications link between the hand-held computer <b>20</b> and a remote CAD computer via the hand-held computer's external interface <b>42</b>, the emergency service provider can download CAD events from the remote CAD computer. Each CAD event consists of an event/time pair, which is formatted by the event reporting program as a post event record <b>148</b>. The event reporting program <b>48</b> inserts the corresponding post event record <b>148</b> in the event summary <b>130</b> in chronological order as shown in FIG. 8C. For example, when the emergency 911 call for the incident being reported is received by a remote CAD computer, the remote CAD computer stores the time of the phone call and an event descriptor for the phone call, i.e., “Call 911,” in its own memory. After the 911 event/time pair is downloaded (along with others) to the hand-held computer <b>20</b>, it is inserted in the event summary <b>130</b> as post event record <b>148</b>′. The time field <b>148</b><i>a </i>of the inserted post event record <b>148</b>′ includes the time recorded by the CAD computer for the 911 call; the event <b>148</b><i>c </i>includes a brief descriptor for the 911 event, i.e., “Call 911”; and the source field <b>148</b><i>e </i>indicates that the source of the post event record <b>148</b>′ is a CAD computer. It will be appreciated that whenever event/time pairs are imported from a CAD system or some other external device, the event reporting program <b>48</b> will synchronize the imported event times with the clock <b>36</b> of the hand-held computer so that imported event times are properly offset before added to the event summary <b>130</b>.

0053[0053] Returning to FIG. 7, once the downloaded CAD event/time pairs have been incorporated into the event summary <b>130</b> as post event records <b>148</b>, the logic proceeds to a decision block <b>242</b> where it determines if the emergency service provider has elected to add device events to the event summary <b>130</b> by selecting the device events button <b>132</b> as shown in FIG. 8D. More specifically, the event reporting program <b>48</b> detects whether the emergency service provider has selected the device event button <b>132</b> from the post-event window <b>128</b>. If so, the logic proceeds to a block <b>244</b> where the device events are incorporated in the event summary <b>130</b>. It will be appreciated that device events are similar to CAD events in that they are obtained from a remote device as an event/time pair and incorporated into the event summary <b>130</b> as post event records <b>148</b> in chronological order. Such devices may include medical electronic devices used by the emergency service provider to administer treatment to the patient during the incident, e.g., external defibrillators, non-invasive blood pressure instruments, etc., or other remote computer systems, such as a mainframe computer located at the hospital to which the patient will be delivered. By establishing a communication link with the external device via its external interface <b>42</b>, the hand-held computer <b>20</b> can download event/time pairs recorded by the external device and insert them as post event records <b>148</b> in the event summary <b>130</b>. For example, if the external device is a defibrillator, such as the LIFEPAK® 12 defibrillator, the defibrillator stores various event/time pairs relating to the treatment of the patient's cardiac condition. For example, a defibrillator typically stores an event/time pair including the measured heart rate for the treated patient and the time at which the heart rate was measured. When the device events button <b>132</b> is selected, the event/time pair for the measured heart rate is downloaded from the defibrillator to the hand-held computer <b>20</b> and inserted in the event summary <b>130</b> as a post event record <b>148</b>″. Accordingly, event field <b>148</b><i>a </i>includes the time at which the heart rate was measured; the event field <b>148</b><i>c </i>includes the common descriptor for the event, i.e., “Heart Rate,” measured by the defibrillator; the detail entry field <b>148</b><i>d </i>includes the measured heart rate, i.e., 92; and the source field <b>148</b><i>e </i>indicates that the source of the post event record <b>148</b>″ is a LIFEPAK® 12 defibrillator.

0054[0054] Returning to FIG. 7, once the downloaded device event/time pairs have been incorporated in the event summary <b>130</b> as post event records <b>148</b>, the logic proceeds to a decision block <b>246</b> where it determines if the emergency service provider has elected to add patient data to the patient's record <b>46</b> by selecting the additional data button <b>138</b> in the post-event window <b>128</b> as shown in FIG. 8E. If so, the emergency service provider further builds the patient's record <b>46</b> in a block <b>248</b> with information obtained via a patient information window <b>158</b> generated by the event reporting program <b>48</b>. The patient information window <b>158</b> includes patient information fields <b>160</b> in which the emergency service provider inserts personal information regarding the patient, such as name, age, weight, address, etc.; and incident information fields <b>164</b> in which the emergency service provider inputs information regarding the incident, such as its location and its outcome. It will be appreciated that the provider may input information in the patient information fields <b>160</b> and the incident information fields <b>160</b> using the keyboard <b>30</b> or the by speaking via the speaker/microphone <b>24</b>. The newly added patient information is stored in the patient's record <b>46</b> in memory when the emergency service provider selects a save button <b>165</b> in the patient information window <b>158</b>.

0055[0055] Once the new information has been stored in the patient's record <b>46</b>, the logic returns to a decision block <b>250</b> in FIG. 7 where it determines if the emergency service provider has elected to edit the narrative previously recorded by him or her during the incident by selecting the narrative edit button <b>140</b> in the post-event window <b>128</b>. If so, the emergency service provider is allowed to modify the narrative text in a block <b>256</b>. More specifically, the event reporting program <b>48</b> produces a narrative story window <b>96</b> as shown previously n FIG. 6J, which includes the text of the previously recorded narrative. Accordingly, the emergency service provider may edit the text narrative using the keyboard <b>30</b> or alternatively, by voice prompting via the speaker/microphone <b>24</b>.

0056[0056] Once the emergency service provider has modified the text of the narrative as desired, the logic returns in FIG. 7 to a decision block <b>254</b> where it determines if the emergency service provider has elected to add certain pieces of information from the narrative to the patient's record <b>46</b> by selecting the narrative data button <b>136</b> in the post-event window <b>128</b>. If so, the event reporting program <b>48</b> runs a narrative parsing routine shown in more detail in FIG. 9 to identify desirable pieces of information from the narrative and add them to the patient's record <b>46</b>.

0057[0057] The narrative parsing routine depicted in FIG. 9 examines the text of the narrative previously recorded and perhaps edited by the emergency service provider for pieces of data that are commonly expected to be recorded during an emergency incident, such as the age and/or sex of a patient, common symptoms for a patient, blood pressure of a patient, etc. By reviewing the text of the narrative for such information and automatically adding the information to the patient's record <b>46</b>, the emergency service provider eliminates the extra task of inputting such information into the patient's records <b>46</b> manually.

0058[0058] Returning to FIG. 7, the narrative parsing routine begins in FIG. 9 in a block <b>266</b> and proceeds to a block <b>268</b> in which the first word of the narrative text is read. In a decision block <b>270</b>, the routine determines if the read word is equal to a narrative keyword stored in a predefined list of narrative keywords found in the master tables <b>50</b>. A keyword for purposes of the present invention is a word or term that is commonly expected to appear in a clinical narrative, e.g., “years(s),” “male,” “female,” “pressure,” etc. If the first word read from the narrative is'not equal to one of the keywords in the predefined list, the logic proceeds to a decision block <b>271</b> in which it determines if the end of the narrative has been reached, i.e., if the last word of the narrative has been read. If so, the narrative edit routine ends in a block <b>272</b>. Otherwise, the next word in the narrative text is obtained in a block <b>273</b> and decision block <b>270</b> is repeated.

0059[0059] If the word obtained from the narrative is equal to one of the keywords stored in the list of keywords, a modifier template for the keyword is retrieved from the master tables <b>50</b> in a block <b>274</b>. Each keyword in the list of keywords has a corresponding modifier template stored in the master tables <b>50</b> which identifies a typical pattern in which a desired word, term, or number, i.e., “modifier,” is expected to appear in the text in association with the keyword. For example, if the keyword obtained from the narrative is “year(s),” the common term or modifier expected to appear with the keyword is an age for the patient. Consequently, the modifier template for the keyword identifies the following pattern for the modifier and keyword:

0060[0060] x w/5 year(s) or

0061[0061] year(s) w/5 x

0062[0062] wherein the modifier, i.e., the age of the patient denoted the by variable “x,” is expected to appear within the five words preceding the keyword “year(s)” or within five words following the keyword “year(s).”

0063[0063] Once the modifier template for the key word has been retrieved in a block <b>274</b>, the narrative text is scanned for the appropriate modifier that matches the modifier template in a block <b>276</b>. Using the above example, the narrative text is scanned for the variable “x,” i.e., age, falling within the five words preceding or following the word “year(s).” Once the modifier matching the modifier template is located, a validation rule is applied to the modifier in a block <b>278</b> to ensure that the modifier actually constitutes a desired or valid piece of information to be inserted in the patient's record <b>46</b>. Again, using the example above, if the keyword obtained from the text of the narrative is “years(s),” the located modifier, i.e., the age of the patient, is validated against a rule requiring that the age be less than a maximum age permitted, e.g., 110. Yet other validation rules may require that a located blood pressure modifier, e.g., 110/60, be less than a maximum systolic pressure and greater than a minimum diastolic pressure, or that a located sex modifier of a patient be either male or female. Once validated, the modifier is inserted into the patient's record <b>46</b> in memory in a block <b>280</b>. Those of ordinary skill in the art will recognize that modifier templates and validation rules of virtually any type or nature may be implemented by the event reporting program <b>48</b>.

0064[0064] Returning to FIG. 7, once the appropriate narrative data has been parsed and added to the record <b>46</b> for the patient, the logic proceeds to a decision block <b>258</b> where it determines if the emergency service provider has elected to run a complete report of the incident by selecting the run report button <b>142</b> in the post-event window <b>128</b>. If so, a full run report as shown in FIG. 8F will be generated on the display <b>32</b> of the hand-held computer from the information stored in the patient's record. It will be appreciated that the run report may also be printed, if desired. The full run report <b>164</b> includes an incident field <b>166</b> which identifies the incident by identification number, location, etc., as stored in the patient record <b>46</b> for the treated patient; a patient field <b>168</b> which includes the personal and background information stored in the patient record <b>46</b>; and a narrative field <b>170</b> which includes the narrative previously edited and recorded by the emergency service provider. Finally, the run report <b>164</b> includes a complete event summary <b>172</b> that shows each of the event records <b>68</b> recorded by the emergency service provider and any remote devices or CAD systems.

0065[0065] After the full run report <b>64</b> has been displayed, the logic returns to a decision block <b>260</b> in FIG. 7 where it determines if the emergency service provider has elected to export data recorded by the event reporting program <b>48</b> to an external destination by selecting the export data button <b>143</b> in the post-event window <b>128</b>. If so, the hand-held computer <b>20</b> transfers the patient records <b>46</b> stored in memory <b>44</b> to another device via its external interface <b>42</b> in a block <b>261</b>. In the alternative, the hand-held computer <b>20</b> stores patient records <b>46</b> to a portable storage medium, such as a diskette, for physical transfer to another device.

0066[0066] After export, the logic proceeds in FIG. 7 to a decision block <b>262</b> where it determines if an exit signal has been received. More specifically, the logic determines if the emergency service provider has selected the exit button <b>146</b> in the post-event window <b>128</b>. If so, the event reporting program ends in a block <b>264</b>. If not, the emergency service provider can continue post-processing of the incident by selecting any of the available post-processing options and repeating blocks <b>234</b> through <b>262</b>.

0067[0067] While the preferred embodiment of the invention has been illustrated and described, it will be appreciated that various changes can be made therein without departing from the spirit and scope of the invention. For example, although the event reporting program <b>48</b> of the present invention described herein is used by an emergency service provider in the context of medical treatment of a patient during an emergency incident, the present invention may be just as easily used in a multitude of other contexts. For example, the invention could be used by a police officer in the context of an emergency criminal incident. In this case, the events recorded and tools initiated would relate to the arrest of a suspect, rather than medical treatment of a patient. In accordance with yet other aspects of the invention, a separate log may be kept of all recorded, modified and deleted events for use in auditing the final event summary <b>172</b> for inaccuracies. Finally, in yet other embodiments of the present invention, a digital audio recorder may be used to record all of the emergency service provider's verbal inputs during the entire incident along with their associated time stamps as an audio event log. The audio event log could then be compiled and transcribed into an event summary and run report following completion of the incident.