WO2025174766A1 - Data, task, and form management system and method - Google Patents

Abstract

A data management system allows collaborative teams to input structured information about a planned or ongoing situation into a relational database in a time-series format to track the progression of the planned or ongoing event through time. The structured data can then be automatically input into an exportable data format, such as PDF, and the resultant document transmitted to a shared document repository for ongoing collaboration among team members. A shared database underlying the use of the forms allows the data to be searchable by text and date/time beyond the context of the usage of the data on the forms themselves. Automatically exporting finished PDF forms in a single document and sending them to a shared location saves time.

Description

DATA, TASK, AND FORM MANAGEMENT SYSTEM AND METHOD

RELATED APPLICATION DATA

[0001] This application claims the benefit of priority of U.S. Provisional Patent Application Serial No. 63/552,760, filed February 13, 2024, and titled “Team Task and Documents Management System,” which is incorporated by reference herein in its entirety.

FIELD OF THE DISCLOSURE

[0002] The present disclosure generally relates to the field of data processing and in particular is directed to team task and documents management system and method.

BACKGROUND

[0003] Organizations may need to monitor and respond to ongoing situations, in which case it can be important to make sure all the relevant information related to the situation is up to date and available to appropriate personnel. Current systems for data entry and management, including shared environments, require users to perform specific steps to manage the progression of documents through time to make sure out-of-date information isn’t being used, which can be time consuming and error prone.

SUMMARY OF THE DISCLOSURE

[0004] A computer-implemented method for controlling forms and information related to an event includes recognizing an occurrence of the event based on received user input or data from media sources, assigning an event identification for the event, selecting an event type for the event from a list of predetermined event types and linking the event identification and the event type, wherein the list of predetermined event types includes event characteristic values associated with each predetermined event type and the selecting the event type is based on matching event characteristic values with a set of values for the event derived from the user input or data from media sources, generating a set of roles to be assigned for the event based on the event type and one or more roles associated with the event type and linking each role of the set of roles to the event identification and the event type to form the set of roles for the event, assigning each of a plurality of users to at least one role of the set of roles based on information associated with each of the plurality of users, one or more role requirements for the at least one role, and the event type, selecting a task to be completed based on the event type, wherein the task is selected from a set of tasks in which each task in the set of tasks is associated with one or more event types, selecting a first form from a list of forms to be filled out based on an association between the first form and the event type and generating an event first form linked to the event identification, receiving data input for the event first form from a user of the plurality of users assigned to roles, determining whether a current time is within an allowable window for entering data into the event first form, wherein the window is determined based on an event start time and a window length for the event type, determining whether the user from the data was received is assigned to a role designated as being permitted to complete the first form based on an association between the first form and the user’s assigned role in a database containing a set of form rules, determining whether the first form requires supervisor approval in order to accept the data entered, wherein if the time is within the allowable window, if the role assigned to the user is designated as being permitted to complete the first form, and if the first form does not require supervisor approval, the data is accepted and saved in the event first form, and wherein if the time is not within the allowable window, if the role assigned to the user is not designated as being permitted to complete the first form, or if the first form does require supervisor approval, the data is designated as not accepted in the event first form, when the first form requires supervisor approval in order to accept the data entered, sending, after receiving data into the event first form during the time that is within the allowable window from users having roles designated as being permitted to complete the first form, a request for approval from a supervisory user of the one or more of the plurality of users assigned a role with permission to approve data into the first form based on an association between the first form and an assigned role of the supervisory user in the database containing the set of form rules, designating the data entered into the event first form as accepted and the event first form completed upon receiving approval from the supervisory user of the one or more of the plurality of users assigned a role with permission to approve data into the first form, and determining whether the first form is a prerequisite form for a second form associated with the event type based on a relationship designation between the first form and the second form maintained in the database, wherein the relationship designation depends in part on the event type.

[0005] Additionally or alternatively, further including, when the first form is a prerequisite for the second form and the second form is associated with the event type, generating an event second form and linking the event second form to the event identification, receiving data input for the event second form from one or more users of the plurality of users assigned to roles, determining whether the current time is within an allowable second form window for entering data into the event second form, determining whether the one or more users that input data is assigned to a role designated as being permitted to complete the second form, determining whether the second form requires supervisor approval in order to accept the data entered, wherein if the time is within the allowable second form window, if the roles assigned to the one or more users are designated as being permitted to complete the second form in the database containing the set of form rules, and if the second form does not require supervisor approval, the data is accepted and saved in the event second form, and wherein if the time is not within the allowable second form window, if the roles assigned to the one or more users are not designated as being permitted to complete the second form in a database containing a set of form rules, or if the second form does require supervisor approval, the data is designated as not accepted in the event second form. When the second form requires supervisor approval in order to accept the data entered, sending, after receiving data into the event second form during the time that is within the second form allowable window from users having roles designated as being permitted to complete the second form, a request for approval from a user of the one or more of the plurality of users assigned a role with permission to approve data into the second form, designating the data entered into the event first form as accepted and completed upon receiving approval from the user of the one or more of the plurality of users assigned a role with permission to approve data into the second form, and determining whether the second form is a prerequisite form for a third form associated with the event type based on a relationship designation between the second form and the third form maintained in the database.

[0006] Additionally or alternatively, further including, after the event first form is designated as completed, sending, when an update time is reached, an update request to the one or more users of the plurality of users assigned to roles, wherein the update time is determined based on the event start time or a form completion time and a predetermined time period and wherein the update request requests updated input for the event first form.

[0007] Additionally or alternatively, wherein the update request is sent to the one or more users of the plurality of users assigned to roles associated with the first event form.

[0008] Additionally or alternatively, wherein the update request is sent to the one or more users of the plurality of users assigned to roles from which data was previously received for the event first form.

[0009] Additionally or alternatively, further including determining whether the first form includes one or more prefillable fields and filling the prefillable fields with values based on the event type and incident state data associated with the event type stored in the database. [0010] Additionally or alternatively, further including assigning the task to one or more of the users based on an association between each assigned role, the event type, and the task, associating the event identification with the task, and sending a notification to the assigned one or more of the users about the task.

[0011] Additionally or alternatively the task is associated with the event first form.

[0012] Additionally or alternatively, further including opening a first form export form in a supporting format program, generating form fields on the first form export form corresponding to fields in the first form, assigning names to fields according to a schema, creating a schema JSON in an application programming interface that maps data inputs to the form fields, and adding the mapped data inputs to the form fields.

[0013] Additionally or alternatively, further including determining a set of forms and tasks that are required to be completed, and in what order, based on the event type and a set of form rules contained in the database.

[0014] Additionally or alternatively, further including determining an updated set of forms that are required to be completed based on a current state of completion of forms and tasks and prerequisite statuses for the respective forms and tasks.

[0015] A system for controlling forms and information related to an event is provided that includes a database including user module, a task module, a form rules module, an incident state module, a team module, a role module, and a role assignments module, wherein the user module includes a list of a plurality of users including values for notification level, team, organization, role, forms permissions, and approval permissions, wherein the values depend on associated event types, wherein the role module includes a list of roles, wherein each of the roles is associated one or more event types and includes permission levels based on roles, wherein the form rules module includes information related to which roles are permitted to enter data into which forms, which roles are permitted to approve complete forms for which forms, event types associated with which forms, and which forms require prior forms to be completed prior to data entry, wherein the role assignments module includes assignments of roles to one or more of the plurality of users for a given event, wherein the role module includes a list of roles required for each event type, wherein the team module includes sets of the plurality of users that constitute respective teams, and wherein the incident state module includes data related to a given event, including predetermined data based on event type, the predetermined data associated with one or more of one or more forms, a user interface in communication with the database, a notification system in communication with the user interface, an analysis module connected to the database and in communication with the user interface, a form module in communication with the notification system, the user interface, the analysis module and the database, the form module containing a plurality of forms, each of the plurality of forms being associated with one or more event types and including a prerequisite status, role filed by status, and role approval status, a server device having memory storing instructions, and a processor coupled to the memory that, when executing the instructions, performs acts comprising determining when the event is occurring based on received user input or data from media sources and generating an event identification the event, selecting an event type for the event from a list of predetermined event types and linking the event identification and the event type, generating a set of roles to be assigned for the event based on the event type and one or more roles associated with the event type and linking each role of the set of roles to the event identification and the event type, assigning each of a plurality of users to at least one role of the set of roles based on information associated with each of the plurality of users and the event type, selecting a task to be completed based on the event type, selecting a first form from a list of forms to be filled out based on an association between the first form and the event type and generating an event first form linked to the event identification, receiving data input for the event first form from one or more users of the plurality of users assigned to roles, determining whether a current time is within an allowable window for entering data into the event first form, wherein the window is determined based on an event start time and a window length for the event type, determining whether the one or more users that input data is assigned to a role designated as being permitted to complete the first form, determining whether the first form requires supervisor approval in order to accept the data entered, wherein if the time is within the allowable window, if the roles assigned to the one or more users are designated as being permitted to complete the first form in a database containing a set of form rules, and if the first form does not require supervisor approval, the data is accepted and saved in the event first form, and wherein if the time is not within the allowable window, if the roles assigned to the one or more users are not designated as being permitted to complete the first form in a database containing a set of form rules, or if the first form does require supervisor approval, the data is designated as not accepted in the event first form, when the first form requires supervisor approval in order to accept the data entered, sending, after receiving data into the event first form during the time that is within the allowable window from users having roles designated as being permitted to complete the first form, a request for approval from a user of the one or more of the plurality of users assigned a role with permission to approve data into the first form, designating the data entered into the event first form as accepted and completed upon receiving approval from the user of the one or more of the plurality of users assigned a role with permission to approve data into the first form, and determining whether the first form is a prerequisite form for a second form associated with the event type based on a relationship designation between the first form and the second form maintained in the database.

BRIEF DESCRIPTION OF THE DRAWINGS

[0016] For the purpose of illustrating the disclosure, the drawings show aspects of one or more embodiments of the disclosure. However, it should be understood that the present disclosure is not limited to the precise arrangements and instrumentalities shown in the drawings, wherein:

FIG. l is a schematic diagram of components of a team task and form management system in accordance with an embodiment of the present disclosure;

FIG. 2 is a process diagram providing an overview of interactions among components of the team, task, and form management system during an event in accordance with an embodiment of the present disclosure;

FIG. 3 is an example of relational status and permission information for a given user with respect to event type;

FIG. 4 is a table of form rules for example forms;

FIG. 5 is a process diagram providing an overview of a form and task selection, completion, and updating during an event for that event in accordance with an embodiment of the present disclosure;

FIG. 6 is a process diagram summarizing data entry; and

FIG. 7 is a process diagram summarizing steps of form filling and distribution in accordance with an embodiment of the present disclosure.

DETAILED DESCRIPTION

[0017] A data, form, and task management system allows members of collaborative teams to input structured information about a planned or ongoing situation into a relational database in a timeseries format to track the progression of the planned or ongoing event through time. The structured data can then be automatically input into an exportable data format, such as PDF, and the resultant document transmitted to a shared document repository for ongoing collaboration among team members. [0018] A shared database underlying the use of the forms allows the data to be searchable by text and date/time beyond the context of the usage of the data on the forms themselves. Finished forms can be compiled in a single document and automatically exported to certain users or locations.

[0019] Controlling data entry and altering permissions as well as access to information and forms can be essential for planning, monitoring, and/or responding to situations or events to ensure that accurate and timely information is received by and available to the appropriate personnel. The team task and documents management system implements role-based access control in which roles are defined in a database and each role corresponds to a set of permitted actions throughout the system. Some roles may also confer the ability to assign roles to other users. Restricted actions are cross-checked between the roles that are allowed to perform an action and the actions themselves, such as data entry or approval of certain forms.

[0020] The system may also restrict permission to perform task management via data entry into a particular database table at a given time or during certain time periods, which may be determined by time or by stages of the event. Certain data entry activities are associated with forms that are used as the basis for operations and tasks to be performed during a specified time period, or operational period. Certain tasks can only be completed in a sequence, for example, one task, e.g., Task A, may have to be completed before another task, e.g., Task B, which must be completed before a third task, e.g., Task C. Certain tasks may include or involve one or more forms. Certain forms may likewise need to be completed before other forms, and the forms that require one or more prior forms to be completed are made unavailable for filling out until the required prior forms have been determined to be completed. Additionally, only users whose role allows them to fill out a particular form at a particular time are able to do so in the system. For example, the system may be configured such that only a user designated to fulfill a particular role, e.g., Role A, is permitted to fill out an associated form, e.g., Form A, and similarly only a user designated to fulfill Role B can fill out Form B.

[0021] Furthermore, not only can users be prevented from performing data entry for data entries that the role the user is assigned to does not have permission to input, users may also be prevented from retroactively changing data in all or a subset of data entries past a specified time period or an operational period.

[0022] The forms may correspond to certain tasks, and the system also governs task management. For example, some forms require a user with a specific role to approve a finished task or completed form. In this way, a sequence of actions within a particular task or form may require input or actions from users with multiple roles to be initiated, altered, or completed.

[0023] Because the process of filling out the forms via data entry operates in a sequence, the system notifies users who are needed to perform their tasks based on role those users have been assigned to. To ensure timely task completion (e.g., data entry) by all necessary users, each user who is required to perform data entry based on their role is notified as soon as the task is available to be completed.

[0024] Furthermore, the information from the various tasks, including forms, is ingested into an analysis module, such as a language model Al system, that summarizes the information and allows for question-answering sessions with users to provide context and/or information about the event. This allows users to gain an understanding of a situation without having to go through each of the forms themselves, such that in the case of a very large event involving many people, tasks, and forms being processed, the large volumes of data can be distilled to return the important and relevant information to the user based on their query. Because the data is obtained from the forms in the manner described, its reliability is improved, resulting in more accurate summaries.

[0025] In FIG. 1 a schematic diagram of components for a system for structuring teams, data, and documents related to a planned or an ongoing event is shown. A database includes information about users, including the users’ association with one or more roles, teams, and organizations. The database also includes current teams, roles, and organizations, and maintains the relationships among them. Information about role assignments is included, along with the rules for tasks and forms, such as which roles can enter data or complete them and when, which require approval, and which require the completion of another form before they can be accessed. Incident state data is included, which informs which roles are needed, which tasks must be completed and when, and which forms are required for a given incident or event type.

[0026] For a given team, which may include various personnel from several different organizations or only individuals from within a particular organization (as may be determined by incident state data), the database includes a set of users that are part of the team and a set of roles that may be preset for a given team and/or situation, or may be adjusted as needed as teams and situations evolve. For a given situation or event, roles are defined and role assignments are created based on the required and expected role assignments for that event or situation. From the set of users in the database, users are assigned to particular role assignments associated with the event. Such role assignments may be pre-assigned for a given incident type or based on user information, such as experience, knowledge, and availability, which may be included in the database or entered or updated as needed and/or assigned by users designated to have management roles by the system administrators during platform onboarding. In this way, personnel at the top of an organizational chart are able to assign roles and delegate as needed, which may be wholly or partially completed before an incident occurs. The role-based access controls provided by the system can accommodate various hierarchical organizational charts, including the Incident Command System (ICS).

[0027] For a given incident, one or more tasks or forms may be required. Each task or form, such as Task/Form 1 up to Task/Form n, has fields for user data entry and approved data which has been entered by a user assigned to a role with permission to enter data for the form and approved by a user assigned to a role with permission to approve the data or form, if required. Each task/form also includes a status, which may include whether it is available for data entry, whether it has been completed, and whether it has been approved. In addition, rules are associated with each particular form, such as whether a prior form is required before it can be filled out or whether it must be completed before other forms can be completed.

[0028] As used herein, forms may refer to the creation, assignment, performance, and approval of tasks. Tasks involve the carrying out of projects, assignments, goals or jobs, such as the sourcing and delivering of supplies like potable water or diesel fuel. To proceed with a task in the system, a task would have to be created, assigned, performed, and then approved by a user with appropriate permissions to mark completion of the task. In many organizational structures, such as ICS, standardized forms are used to track the progress of the actions related to a task.

[0029] A user interface, which may include one or more interfaces accessible to users, is in communication with the database, the one or more forms, a notification system, and an analysis module. The user interface allows users to access the database to view or enter information, as permitted based on assigned roles, to view and enter data into forms as permitted based on assigned roles and form prerequisites, receive and respond to notifications from the notification system, and query and receive information from the analysis module. The analysis module acquires input from the database and the forms. The notification system also receives inputs from the tasks/forms that may result in notifications being sent to users regarding the need to complete a form or whether a form or task has been completed. [0030] Once users have been assigned to roles, users perform tasks and enter data for a task, such as Task A. Data entry and task performance is only permitted if a user has permission to perform a particular task or enter or change a data entry field or value (and at the time at which the entry is made or attempted to be made). Therefore, before a user is granted access to perform a task or enter data, the system validates the required permissions based on the user’s role assignment. As users enter data and/or perform tasks, or at such point as a certain amount of data is entered or tasks performed, the occurrence of the tasks performed and/or data entered is reported to a notifications system, along with a current status, such as “awaiting approval,” if appropriate. The notifications system then provides notifications to appropriate users based on their role assignments as needed for status updates and to make sure that any tasks, data entry, or forms that require additional user input/approval from other users based on their roles are sent to those users in a timely manner.

[0031] Notifications are sent for supervisor approval for any data entry or tasks performed by a user for which supervisor approval is required. When such data entries and/or tasks are approved by a supervisor having the appropriate role, a report of the approval is sent to the notifications system (which causes any pending notices regarding the need for approval or reminders related to those notices to be discontinued). In addition, certain data entry and/or tasks related to certain tasks/forms cannot be made or performed unless another associated prerequisite task/form has been completed and approved. For example, as shown in FIG. 1, approval for Task A enables data entry to be performed for Task B.

[0032] Task B, as with other tasks/forms, additionally allows data entry to be performed by users with role assignments with permission to perform such tasks. Further, upon entry of data or the performance of tasks associated with Task B, supervisor approval may be required. In that case, when data is entered or a task performed, a report of the task being performed or data entered is sent to the notifications system in order to provide notice to an appropriate user that approval is now required. Once a supervisor approves the data entry or task performed for Task B, the approval is reported to the notifications system.

[0033] Once a task or form is completed, the notifications system will notify users that the form/task has been completed. At this point, if the completed task or form enables another task or form to be initiated, the notifications system will send notices to appropriate users based on their roles to begin data entry and tasks for that form/task. [0034] In an embodiment, incident state data may be saved in a system database. Incident state data may include any or all data related to or associated with an identified incident. Once an incident is identified, an incident file is created in the database and associated with the incident. Some state data may be automatically imported into the incident state file initially, and other data, such as validated data entered by a user with appropriate permissions, is added to the incident state file during the incident response process. Further, such data can also be used to populate forms automatically as forms are generated during the process.

[0035] The system determines which forms and tasks are required to be completed, and in what order, based on the incident type and the current state of progress of completion of forms/tasks that are prerequisites for those forms/tasks.

[0036] Some form fields may be completed automatically by the system based on the incident state data. For example, an identifier for an incident, such as an incident name, will typically be the same for every form, and so in this way does not need to be manually entered for every form or entry. Other data, such as the current actions, objectives, or resources, may be managed by the system database, and this type of information can be automatically brought into the forms, rather than such information being manually entered by a user. This prevents duplication of efforts and streamlines tasks.

[0037] In addition, the data from any task (such as a form) that is completed is sent to an Al analysis module where it is available for processing in response to inquiries from users requesting updates, summaries, or other information regarding the event or situation. Preferably, the Al analysis is formed based on only approved data entries and forms, and, moreover, is based on the most current such data from approved tasks, unless a request specifically refers to a previous time period.

[0038] The information from the various tasks is ingested into a language model Al system that summarizes the information and allows for question-answering sessions with users to provide context. This allows users to gain an understanding of a situation (ongoing or previous) without having to go through each of the forms themselves, such that in the case of a very large event involving many individuals, tasks, and forms being processed, the Al system can read through the large volumes of data to return the important and relevant information to a user based on the user’s query. [0039] In this system, data can only be entered by users that have been roles that have permission to enter that data, and data is approved by supervisors with appropriate roles, who are given notices that such approval is required on an ongoing basis so that bottlenecks can be avoided. Likewise, tasks may not be permitted to be accessed until a prerequisite task is already completed and approved. This process provides the control and organization required to improve the speed and accuracy of information gathering and dissemination during an ongoing event or situation.

[0040] FIG. 2 provides an overview of the components and interactions during an event. When an event is detected or initiated, required roles for the event are selected and users are assigned to the required roles, which may also be assigned by users with roles that allows for the assignment of roles to other users. Based on the event type, tasks and/or forms are selected that are associated with the event type. The selected forms are sent to users with role assignments that permit and require data entry to be performed by users with such roles. When those users enter data into the assigned or available form, the data may be sent to an analysis module. Also, if approval is required from a user with an associated permission to approve the form for completion, the status of the form will be sent to the notification system, which will in turn send a notification to review and approve the filled form to one or more users with assigned roles that permit approval of that form, and the form will be given an awaiting approval status. Once such approval is received, the completed form has approved status and the data, marked as such, may be sent to the analysis module and the approved status will also be reported to the notifications system, which may then 1) discontinue sending notices/reminders regarding approval of the completed form and/or 2) send a notice to users with certain assigned roles that the form is approved.

[0041] In addition, once a form is completed and approved, it is determined whether any forms required for the event type can only be completed upon completion of the completed form. If so, the prior-form dependent forms are sent to users with role assignments that permit and require data entry to be performed by users with such roles. When those users enter data into the assigned or available form, the data may be sent to an analysis module. Also, if approval is required from a user with an associated permission to approve the form for completion, the status of the form will be sent to the notification system, which will in turn send a notification to review and approve the filled form to one or more users with assigned roles that permit approval of that form, and the form will be given an awaiting approval status. Once such approval is received, the completed form has approved status and the data, marked as such, may be sent to the analysis module and the approved status will also be reported to the notifications system, which may then 1) discontinue sending notices/reminders regarding approval of the completed form and/or 2) send a notice to users with certain assigned roles that the form is approved. The system will then determine whether any other prior-form dependent forms are required for that form for the event type and the process continues until all forms required for the event type are completed.

[0042] Users may also request summaries and direct questions to the analysis module, which will return information and answers based on the data received from the forms as well as other information, such as incident state data.

[0043] FIG. 3 is a table of relational information for an example user of the system with respect to different event types. For each user, there will be associated information establishing the possible roles that can be assigned, teams and organizations that the user is part of, a notification level (i.e., a status that determines which notifications will be sent to this user and when), which forms the user is permitted to fill and/or required to approve, which roles the user can assign to other users, and which tasks, if any, the user would be permitted or required to complete if determined to be necessary based on the event type and stage of the event. For example, for the user record of FIG. 3, if the event type is A, the user would be assigned to Role a and be permitted to enter data for forms A, B, C, and D, could not approve any forms, and would be part of Team alpha. All of these conditions are established based on the information in the system and are thus enforced by the system.

[0044] FIG. 4 is a table with a summary of example form rules that are used to determine which forms are required for various event types and how. Rules for a form may include which roles can enter data into the form, which roles can approve a filled form for completion, the event types the forms is required for, which users based on roles the data and/or form is sent to upon completion, what tasks if any are associated with the form, whether the form is a prerequisite form for any other forms and if so, which forms, which users based on roles are required to receive approval notifications/reminders, where data entered is to be sent upon completion and approval, whether updates are required and when, and which roles are permitted to modify data in completed forms.

[0045] FIG. 5 is a process diagram that provides an overview of a method of processing data entry, task completion, and role assignments. When an event or situation is detected or initiated, an event ID is created to be associated with all data, tasks, including related forms and communications, for the event. A set of roles is generated based on the event (e.g., type, size), where each role has associated permissions and qualifications for users that can be assigned to the particular role. Based on the event, a set of users is compiled. The set of users may be preexisting and associated with the detected or initiated event type, location, and/or size, or may be complied based on a larger set of users that are associated with one or more organizations. Each user may have an associated set of qualifications that are used to assign users to the roles that are required for the given event, but the assignment of roles is determined by and made by personnel of a participating organization with the access/permissions to do so. A task, such as a form as used and shown in this example, is selected based on the event, and the data required for the selected form is determined. Data input (which may include attempts to input data) from users is received and the date/time is checked against the date/time range associated with the data field. If the date/time is not within the allowable date/time, the data is not entered or is redirected to another form. If the date/time is within the allowable range, it is determined whether the user has permission to enter this data (e.g., based on assigned role). If not, the data is not entered. If the user does have the correct permissions, it is determined whether supervisor approval is required for recording this data entry. If not, the data is recorded. If approval is required, a notice is sent to one or more users that have the required role for approving the data entry, along with information necessary for reviewing and approving the pending data entry.

[0046] One approval is received, the data entry is recorded, at which point it is determined whether the form that the data entry is associated with has been completed or sufficiently completed. If the form is not completed, more data input is received from users as described above. If the form is complete (which may require approval from a user with a role allowing the user to approve the completeness of a form), it is determined whether the form is a prerequisite form for another form. If the form is a prerequisite form, another form for which the completed form is a prerequisite form is selected, and the data required to complete the selected form is determined and filled out as described above.

[0047] In some embodiments, users can export incident information in selected or predetermined formats without having to proceed through an intermediary step of filling out data for those formats. Because the system already captures all of the relevant information for an identified incident, the necessary data can be aggregated by the platform and then exported in a required format.

[0048] Many forms may share data between them, or have common data references. These data are collected through the system as described herein. However, some forms may have certain fields not planned or built. Additionally, the forms, typically after completion, may be prepared for export. The process, summarized in FIG. 6, for setup includes adding data inputs for the identified incident to account for the form inputs and opening a form in the supporting format program. A form is then generated with corresponding form fields on the form. The fields are then assigned names according to a schema. A corresponding schema JSON is created in the API (application programming interface) that maps the data inputs to the form fields.

[0049] After planning work for a given operational period has concluded, the data will be ready for export. The user can specify which forms to export, or to have collections of forms collated together. The process for export is outlined in FIG. 7 and includes users completing necessary data inputs for the operational period (or for the initial incident brief). Users can then choose to export, such as by selecting an “Export” option. This may include a dialogue with options (e.g., single form vs full incident report; download to computer vs share to a collaboration application; format type).

[0050] If a given data input has not been provided, the UI will warn the user that the export will not function until the prerequisites are complete. After configuring and confirming all data inputs are provided, the user selects submit to download or send the forms. The request is sent to the API which combines the form specifications, the form JSON schemas, the incident data, and the form document to create the filled-out form or spreadsheet. The fonns/spreadsheets are then downloaded to the user’s computer or sent to the collaboration application, depending on the request specifications.

[0051] In a preferred embodiment, the forms are exportable based on a time range or operational period. In addition, all data in the forms may be required to be retained in a time series. Data in the forms may also be retained for each operational period for incident documentation. If a given input exceeds the space in the form, additional pages of the same input may be generated and combined together in the final export output.

[0052] Any one or more of the aspects and embodiments described herein may be implemented using one or more machines (e.g., one or more computing devices that are utilized as a user computing device for an electronic document, one or more server devices, such as a document server, etc.) programmed according to the teachings of the present specification.

[0053] Such software may be a computer program product that employs a machine-readable storage medium. A machine-readable storage medium may be any medium that is capable of storing and/or encoding a sequence of instructions for execution by a machine and that causes the machine to perform any one of the methodologies and/or embodiments described herein. Examples of a machine-readable storage medium include, but are not limited to, a magnetic disk, an optical disc (e. ., CD, CD-R, DVD, DVD-R, etc.), a magneto-optical disk, a read-only memory “ROM” device, a random access memory “RAM” device, a magnetic card, an optical card, a solid-state memory device, an EPROM, an EEPROM, and any combinations thereof. As used herein, a machine- readable storage medium does not include transitory forms of signal transmission.

[0054] Such software may also include information (e.g., data) carried as a data signal on a data carrier, such as a carrier wave. For example, machine-executable information may be included as a data-carrying signal embodied in a data carrier in which the signal encodes a sequence of instruction, or portion thereof, for execution by a machine (e.g., a computing device) and any related information (e.g., data structures and data) that causes the machine to perform any one of the methodologies and/or embodiments described herein.

[0055] Examples of a computing device include, but are not limited to, an electronic book reading device, a computer workstation, a terminal computer, a server computer, a handheld device (e.g., a tablet computer, a smartphone, etc.), a web appliance, a network router, a network switch, a network bridge, any machine capable of executing a sequence of instructions that specify an action to be taken by that machine, and any combinations thereof. In one example, a computing device may include and/or be included in a kiosk.

[0056] Memory may include various components (e.g., machine-readable media) including, but not limited to, a random access memory component, a read only component, and any combinations thereof. In one example, a basic input/output system (BIOS), including basic routines that help to transfer information between elements within computer system, such as during start-up, may be stored in memory. Memory may also include (e.g., stored on one or more machine-readable media) instructions (e.g., software) embodying any one or more of the aspects and/or methodologies of the present disclosure. In another example, memory may further include any number of program modules including, but not limited to, an operating system, one or more application programs, other program modules, program data, and any combinations thereof.

[0057] Various modifications and additions can be made without departing from the spirit and scope of this disclosure. Features of each of the various embodiments described above may be combined with features of other described embodiments as appropriate in order to provide a multiplicity of feature combinations in associated new embodiments. Furthermore, while the foregoing describes a number of separate embodiments, what has been described herein is merely illustrative of the application of the principles of the present disclosure. Additionally, although particular methods herein may be illustrated and/or described as being performed in a specific order, the ordering is highly variable within ordinary skill to achieve aspects of the present disclosure. Accordingly, this description is meant to be taken only by way of example, and not to otherwise limit the scope of this disclosure.

[0058] Exemplary embodiments have been disclosed above and illustrated in the accompanying drawings. It will be understood by those skilled in the art that various changes, omissions and additions may be made to that which is specifically disclosed herein without departing from the spirit and scope of the present disclosure.

Claims

What is claimed is:

1 . A computer-implemented method for controlling forms and information related to an event, the method comprising: recognizing an occurrence of the event based on received user input or data from media sources; assigning an event identification for the event; selecting an event type for the event from a list of predetermined event types and linking the event identification and the event type, wherein the list of predetermined event types includes event characteristic values associated with each predetermined event type and the selecting the event type is based on matching event characteristic values with a set of values for the event derived from the user input or data from media sources; generating a set of roles to be assigned for the event based on the event type and one or more roles associated with the event type and linking each role of the set of roles to the event identification and the event type to form the set of roles for the event; assigning each of a plurality of users to at least one role of the set of roles based on information associated with each of the plurality of users, one or more role requirements for the at least one role, and the event type; selecting a task to be completed based on the event type, wherein the task is selected from a set of tasks in which each task in the set of tasks is associated with one or more event types; selecting a first form from a list of forms to be filled out based on an association between the first form and the event type and generating an event first form linked to the event identification; receiving data input for the event first form from a user of the plurality of users assigned to roles; determining whether a current time is within an allowable window for entering data into the event first form, wherein the window is determined based on an event start time and a window length for the event type; determining whether the user from the data was received is assigned to a role designated as being permitted to complete the first form based on an association between the first form and the user’s assigned role in a database containing a set of form rules; determining whether the first form requires supervisor approval in order to accept the data entered, wherein if the time is within the allowable window, if the role assigned to the user is designated as being permitted to complete the first form, and if the first form does not require supervisor approval, the data is accepted and saved in the event first form, and wherein if the time is not within the allowable window, if the role assigned to the user is not designated as being permitted to complete the first form, or if the first form does require supervisor approval, the data is designated as not accepted in the event first form; when the first form requires supervisor approval in order to accept the data entered, sending, after receiving data into the event first form during the time that is within the allowable window from users having roles designated as being permitted to complete the first form, a request for approval from a supervisory user of the one or more of the plurality of users assigned a role with permission to approve data into the first form based on an association between the first form and an assigned role of the supervisory user in the database containing the set of form rules; designating the data entered into the event first form as accepted and the event first form completed upon receiving approval from the supervisory user of the one or more of the plurality of users assigned a role with permission to approve data into the first form; and determining whether the first form is a prerequisite form for a second form associated with the event type based on a relationship designation between the first form and the second form maintained in the database, wherein the relationship designation depends in part on the event type.

2. The method of claim 1, further including, when the first form is a prerequisite for the second form and the second form is associated with the event type: generating an event second form and linking the event second form to the event identification; receiving data input for the event second form from one or more users of the plurality of users assigned to roles; determining whether the current time is within an allowable second form window for entering data into the event second form; determining whether the one or more users that input data is assigned to a role designated as being permitted to complete the second form; determining whether the second form requires supervisor approval in order to accept the data entered, wherein if the time is within the allowable second form window, if the roles assigned to the one or more users are designated as being permitted to complete the second form in the database containing the set of form rules, and if the second form does not require supervisor approval, the data is accepted and saved in the event second form, and wherein if the time is not within the allowable second form window, if the roles assigned to the one or more users are not designated as being permitted to complete the second form in a database containing a set of form rules, or if the second form does require supervisor approval, the data is designated as not accepted in the event second form; when the second form requires supervisor approval in order to accept the data entered, sending, after receiving data into the event second form during the time that is within the second form allowable window from users having roles designated as being permitted to complete the second form, a request for approval from a user of the one or more of the plurality of users assigned a role with permission to approve data into the second form; designating the data entered into the event first form as accepted and completed upon receiving approval from the user of the one or more of the plurality of users assigned a role with permission to approve data into the second form; and determining whether the second form is a prerequisite form for a third form associated with the event type based on a relationship designation between the second form and the third form maintained in the database.

3. The method of claim 1, further including, after the event first form is designated as completed, sending, when an update time is reached, an update request to the one or more users of the plurality of users assigned to roles, wherein the update time is determined based on the event start time or a form completion time and a predetermined time period and wherein the update request requests updated input for the event first form.

4. The method of claim 3, wherein the update request is sent to the one or more users of the plurality of users assigned to roles associated with the first event form.

5. The method of claim 3, wherein the update request is sent to the one or more users of the plurality of users assigned to roles from which data was previously received for the event first form.

6. The method of claim 1, further including: determining whether the first form includes one or more prefillable fields and filling the prefillable fields with values based on the event type and incident state data associated with the event type stored in the database.

7. The method of claim 1, further including assigning the task to one or more of the users based on an association between each assigned role, the event type, and the task, associating the event identification with the task, and sending a notification to the assigned one or more of the users about the task.

8. The method of claim 7, wherein the task is associated with the event first form.

9. The method of claim 1, further including: opening a first form export form in a supporting format program; generating form fields on the first form export form corresponding to fields in the first form; assigning names to fields according to a schema; creating a schema JSON in an application programming interface that maps data inputs to the form fields; and adding the mapped data inputs to the form fields.

10. The method of claim 1, further including determining a set of forms and tasks that are required to be completed, and in what order, based on the event type and a set of form rules contained in the database.

11. The method of claim 10, further including determining an updated set of forms that are required to be completed based on a current state of completion of forms and tasks and prerequisite statuses for the respective forms and tasks.

12. A system for controlling forms and information related to an event comprising: a database including user module, a task module, a form rules module, an incident state module, a team module, a role module, and a role assignments module, wherein the user module includes a list of a plurality of users including values for notification level, team, organization, role, forms permissions, and approval permissions, wherein the values depend on associated event types, wherein the role module includes a list of roles, wherein each of the roles is associated one or more event types and includes permission levels based on roles, wherein the form rules module includes information related to which roles are permitted to enter data into which forms, which roles are permitted to approve complete forms for which forms, event types associated with which forms, and which forms require prior forms to be completed prior to data entry, wherein the role assignments module includes assignments of roles to one or more of the plurality of users for a given event, wherein the role module includes a list of roles required for each event type, wherein the team module includes sets of the plurality of users that constitute respective teams, and wherein the incident state module includes data related to a given event, including predetermined data based on event type, the predetermined data associated with one or more of one or more forms; a user interface in communication with the database; a notification system in communication with the user interface; an analysis module connected to the database and in communication with the user interface; a form module in communication with the notification system, the user interface, the analysis module and the database, the form module containing a plurality of forms, each of the plurality of forms being associated with one or more event types and including a prerequisite status, role filed by status, and role approval status; a server device having memory storing instructions; and a processor coupled to the memory that, when executing the instructions, performs acts comprising: determining when the event is occurring based on received user input or data from media sources and generating an event identification the event; selecting an event type for the event from a list of predetermined event types and linking the event identification and the event type; generating a set of roles to be assigned for the event based on the event type and one or more roles associated with the event type and linking each role of the set of roles to the event identification and the event type; assigning each of a plurality of users to at least one role of the set of roles based on information associated with each of the plurality of users and the event type; selecting a task to be completed based on the event type; selecting a first form from a list of forms to be filled out based on an association between the first form and the event type and generating an event first form linked to the event identification; receiving data input for the event first form from one or more users of the plurality of users assigned to roles; determining whether a current time is within an allowable window for entering data into the event first form, wherein the window is determined based on an event start time and a window length for the event type; determining whether the one or more users that input data is assigned to a role designated as being permitted to complete the first form; determining whether the first form requires supervisor approval in order to accept the data entered, wherein if the time is within the allowable window, if the roles assigned to the one or more users are designated as being permitted to complete the first form in a database containing a set of form rules, and if the first form does not require supervisor approval, the data is accepted and saved in the event first form, and wherein if the time is not within the allowable window, if the roles assigned to the one or more users are not designated as being permitted to complete the first form in a database containing a set of form rules, or if the first form does require supervisor approval, the data is designated as not accepted in the event first form; when the first form requires supervisor approval in order to accept the data entered, sending, after receiving data into the event first form during the time that is within the allowable window from users having roles designated as being permitted to complete the first form, a request for approval from a user of the one or more of the plurality of users assigned a role with permission to approve data into the first form; designating the data entered into the event first form as accepted and completed upon receiving approval from the user of the one or more of the plurality of users assigned a role with permission to approve data into the first form; and determining whether the first form is a prerequisite form for a second form associated with the event type based on a relationship designation between the first form and the second form maintained in the database.