Systems and Methods for Product Event Management

A system for processing and managing product events is disclosed. The system may include one or memories storing instructions and one or more processors configured to execute the instructions to perform certain operations. The operations performed by the processors may include receiving a first product alert corresponding to a product event, wherein the product event is one of a recall event, a field correction event, or a repair instructions event, and receiving a second product alert. The operations may also include determining that the second product alert also corresponds to the product event, and responsive to determining that the second product alert also corresponds to the product event, generating an event data entry that represents the product event and includes the first product alert and the second product alert.

DETAILED DESCRIPTION OF THE EMBODIMENTS

Reference will now be made in detail to exemplary disclosed embodiments, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts. While several exemplary embodiments and features are described herein, modifications, adaptations, and other implementations are possible, without departing from the spirit and scope of the disclosed embodiments. Accordingly, the following detailed description does not limit the disclosed embodiments. Instead, the proper scope of the disclosed embodiments is defined by the appended claims.

FIG. 1is a block diagram illustrating an exemplary system100for processing and managing product events. System100may include a product event manager110communicatively connected to an alert source120via a network150and communicatively connected to alert subscriber entities130and140via a network160. As discussed in greater detail with regard to the exemplary embodiments below, product event manager110may receive product alerts from alert source120, determine a plurality of product alerts that correspond to a single product event, generate an event data entry that represents the product event and includes the plurality of product alerts, and provide data to generate a GUI at computing devices of alert subscribing entities130and140. The GUI may display the event data entry and enable a user to interact with the event data entry to update workflows associated with each of the plurality of product alerts included in the event data entry. Product event manager110may also update various aspects of the event data entry based on the user's updates to the product alert workflows, as discussed in greater detail below. These updates to the events may also be displayed in the GUI. This way, the user may more effectively manage related product alerts at the product event level and may be presented with a clear picture, through the GUI, of the progress made and remaining steps required to process all product alerts associated with a product event.

In certain embodiments, alert source120represents a wide variety of geographically distributed sources that provide product alerts to product event manager110across a wide variety of formats. For example, alert source120may include one or more websites or databases that include product alerts and are managed by one or more alerting entities (e.g., product manufacturer, product distributor, governmental agency, consumer group, etc.). Alert source120may also include one or more communications received from an alerting entity, such as a product recall notice, that may be received by product event manager110in electronic or paper format.

Alert subscribing entities130and140may subscribe to system100for receiving product alert and product event information. Alert subscribing entities130and140may be any organization that may receive, manage, and/or respond to product alerts using system100. In one example, alert subscribing entities130and140may be hospitals or medical centers, and may receive product alerts related to products in various domains, such as biomedical devices, blood products, children's consumer products such as toys, food, laboratory products, medical supplies, pharmaceutical products, radiology products, tissues and organs, engineering and facilities related products and devices, and healthcare related hardware and software. Of course, the product alerts processed and managed by system100can be associated with any industry and are not limited to the medical industry. In certain embodiments, alert subscribing entities130and140may include a number of facilities, and each facility may receive product alerts and product events that may be relevant to its functions only. For example, a facility with a pharmacy department may be interested in receiving product recall alerts in pharmaceutical products while a facility without a pharmacy department may not.

Alert subscribing entities may receive the product alert and product event information from product event manager110via network160. To this end, product event manager110may generate and send data via network160for displaying a GUI at one or more electronic devices associated with alert subscribing entity130. The GUI may be embodied, for example, as a web page, as an application (e.g., an “app”) installed on one or more of the electronic devices, etc. As discussed in greater detail with regard to the embodiments below, the GUI may also enable a user to generate and send requests, commands, and other information related to one or more product alerts and/or product events to product event manager110. Responsive to receiving and processing this information, product event manager110may generate data for displaying the results of the processing via the GUI. Screen shots of exemplary GUIs are discussed below with respect to FIGS.3and5-8.

As shown inFIG. 1, product event manager110may include a processor111, a memory112, input/output devices113, and a storage114. Processor111may include one or more processing devices, such as a microprocessor, microcontroller, laptop computer, desktop computer, server, workstation, etc. Memory112may include one or more storage devices configured to store information that is used by processor111and/or other entities internal and external to product event manager110. For example, memory module112may store one or more programs that, when loaded from storage114and executed by processor111, enable processor111to receive and process product alerts, identify product alerts that correspond to a similar product event, and generate data for displaying a GUI that enables a user to manage product alerts at the product event level. Input/output devices113may be one or more devices that facilitate the transfer of information between product event manager110and external components, such as alert source120, alert subscription entities130and140, and/or one or more other devices or users associated with product event manager110. For example, input/output devices113may include an administrative interface for managing and maintaining product event manager110.

Storage114may include one or more programs or subprograms that, when executed by processor111(e.g., after being loaded into memory112), enable product event manager110to perform certain functions related to disclosed embodiments. For example, storage114may include one or more event generation programs115, one or more event management programs116, one or more interface management programs117, and other programs or subprograms that enable product event manager110to receive product alerts from alert source120, determine a plurality of product alerts that correspond to a single product event, generate an event data entry that represents the product event and includes the plurality of product alerts, and provide data to generate a GUI for alert subscribing entities130and140. The GUI may display the event data entry and enable a user to interact with the event data entry to update workflows associated with each of the plurality of product alerts included in the event data entry. These functions are discussed in greater detail below with regard toFIGS. 2-8.

Moreover, while product event manager110is shown inFIG. 1as a single device, this architecture is exemplary only. Those skilled in the art will appreciate that product event manager110may include any number of computing devices, such as one or more computers, servers, etc., that may cooperate to perform the functions described herein with respect to product event manager110. For example, product event manager110may be configured as a distributed system with a plurality of components distributed in remote locations and interconnected by communication paths, such as local area networks, wide area networks, and any other type of network that may facilitate communications and the exchange of information between the components.

Networks150and160may include any one of or combination of wired or wireless networks. For example, network150may include wired networks such as twisted pair wire, coaxial cable, optical fiber, and/or a digital network. Likewise, network150may include any wireless networks such as RFID, microwave or cellular networks or wireless networks employing, e.g., IEEE 802.11 protocols. Additionally, network150may be integrated into any local area network, wide area network, campus area network, or the Internet.

FIG. 2is a flow chart illustrating an exemplary method200for processing and managing product alerts and product events that may be performed by product event manager110, for example, by executing event generation program115and/or other programs associated with product event manager110. In method200, product event manager110may receive a product alert, e.g., from alert source120(Step210). For example, product event manager110may receive the product alert as information from a web page or database associated with an alerting entity, as a product recall issued and sent from a manufacturer or distributor of a product, or in any other format in which alert source120may include the product alert.

Upon receiving the product alert, product event manager110may process the product alert (Step220). Processing the product alert may include generating an alert data entry from the received data associated with the alert. The alert data entry may include a standard format so that all product alerts processed and managed by product event manager110are stored in the same format. For example, product event manager110may assign a product alert identifier to the received product alert. In certain embodiments, the product alert identifier may be a numeric identifier that includes an indication of the date that the product alert was received and/or issued. For example, a product alert received in August, 2012 may be assigned a product alert identifier of 201208####, where “201208” represents the month and year the alert was received and #### is a numeric sequence for all of the alerts received in that month. This format, of course, is exemplary only, and any format may be used for the product alert identifier.

Product event manager110may perform additional processing on the received product alert to determine and/or extract data from the received product alert. In certain embodiments, product event manager110may classify the product alert into one of a predetermined group of domains. For example, in the healthcare industry, product event manager110may classify the product alert into exemplary domains such as biomedical devices, blood products, children's consumer products, food, laboratory products, medical supplies, pharmaceutical products, radiology products, tissues and organs, engineering and facilities related products and devices, healthcare related hardware and software, etc. Product event manager110may also extract additional information when processing the product alert, such as the alert type (e.g., product recall, field correction, repair instructions, etc.), the release type (e.g., whether the alert is an original alert or an update to a previous alert), a description of the alert, an identification of the product's supply chain, whether the alert is an urgent alert, etc. This processed information may be stored at product event manager110or elsewhere as an alert data entry, which, as discussed above, may be represented in a standard format, so that all product alerts managed by product event manager110are represented in a similar manner.

Product event manager110may perform the processing described above automatically, e.g., by processing the data included in the product alert and referencing one or more relational or rules databases for identifying, determining, and extracting the information. In certain embodiments, product event manager110may process portions of the information discussed above automatically and other portions may be processed and/or confirmed by a human administrator of product event manager110, e.g., via input/output devices113.

Product event manager110may determine if there are previously received and processed product alerts and/or product events that correspond to the product alert that was processed in Step220. For example, in Step230, product event manager110may determine whether the product alert corresponds to an already existing product event represented by product event manager110as an event data entry. As discussed above, alerting entities may issue multiple product alerts for a single product event. Product event manager110enables a user to process and manage the multiple alerts together as a product event by generating and maintaining an event data entry for each product event. The generation of an event data entry is discussed in greater detail below with regard to Step260.

If product event manager110determines that the product alert corresponds to an already existing product event (Step230, Y), product event manager110may add the product alert to the product event, e.g., by associating the alert data entry with the event data entry. For example, consider a product recall of Brand X surgical gloves where two or more product alerts have been previously received by product event manager110regarding the product recall. A first original product alert may have been received and processed by product event manager110, and then a second alert updating the original product alert may have been received. Product event manager110may have previously determined (e.g., by method200) that these product alerts were related to the same product event (i.e., the recall of Brand X surgical gloves) and generated an event data entry representing the product event. If, at Step230, product event manager determines that the product alert received in step210is also related to the Brand X surgical glove product event, product event manager110adds the product alert to the existing event data entry, e.g., by associating the alert data entry corresponding to the product alert with the event data entry corresponding to the original recall of Brand X surgical gloves. This way, the user may view and manage all of the related product alerts that are part of the same product event at the product event level instead of the individual product alert level.

If product event manager110determines that the product alert does not correspond to an existing product event (Step230, N), product event manager110may determine whether the product alert corresponds to a previously received product alert for which an event data entry has not yet been created (Step250). Continuing with the Brand X surgical glove recall example, product event manager110may have previously received an original product alert regarding the recall. At Step250, product event manager110may determine that the product alert received at Step210is related to that original product alert (e.g., it is an update to the original product alert), even though product event manager110has not yet created an event data entry (Step250, Y). Responsive to this determination, product event manager110may generate a new event data entry representing the product event and add both product alerts to the new event data entry, e.g., by associating the alert data entries with the newly created event data entry.

Similar to an alert data entry, an event data entry may be represented in a standard format so that all product events processed and managed by product event manager110are stored in the same format. For example, product event manager110may assign a product event identifier to the event data entry. In certain embodiments, the product event identifier may be represented in a format of E####, where “E” represents that it is an event data entry instead of an alert data entry and “####” is a numeric sequence for all of the event data entries generated by event generator110. This format, of course, is exemplary only, and any format may be used for the product event identifier.

When creating the event data entry, product event manager110may generate data for fields similar to those included in the alert data entry, such as a domain, event type, release type, description of the event, identification of the product's supply chain, whether the event is urgent, etc. Product event manager110may use data from the alert data entries associated with the event data entry in order to propagate these fields. For example, if an event data entry is associated with three product alerts (one original alert and two alert updates) of the type “Recall,” then the event type may also be “Recall.” The event type may also include an indication of the number of different recall alerts included in the event, e.g., “Recall: 3” in the above example (see, e.g., alert type316inFIG. 3). Likewise, the release type associated with the event data entry may indicate that the event data entry includes an original alert and two updates, e.g. “Original: 1; Update: 2” (see, e.g., release type317inFIG. 3).

If product event manager110determines that the product alert does not correspond to a previously received product alert (Step250, N), product event manager110may maintain the product alert as a separate product alert, e.g., by storing the alert data entry unassociated with any event data entry (Step270).

Method200ofFIG. 2may be repeated for each product alert received by product event manager110. Moreover, product event manager110may use the data created by method200to generate instructions for displaying a GUI, such as those shown inFIGS. 3-4, that displays the generated alert data entries and/or event data entries.

For example,FIG. 3illustrates a screen shot of an exemplary GUI300athat may be generated for an electronic device associated with alert subscribing entity130to display product alerts and product events. GUI300adisplays three exemplary alert data entries305,310, and320as well as an exemplary event data entry315. As shown inFIG. 3, GUI300amay display data included in the alert data entries and event data entries such as: (1) the alert identifier or event identifier along with a release date of the alert or event in column320, (2) the assignment type of the alert or event (e.g., a category of personnel at alert subscribing entity130to which the alert should be assigned for resolution, such as a coordinator, a responder, etc.) in column321; (3) the determined domain (e.g., biomedical devices, blood products, children's consumer products, food, laboratory products, etc.), of the alert or event in column322; (4) the alert or event type (e.g., recall, repair, etc.) in column323; (5) the release type of the alert or event in column324; (6) information regarding a description of the product, the product's supply chain, and/or the reason for the alert or event in column325; (7) a stage of the alert or event (e.g., whether the alert has been assigned to a person at alert subscribing entity130for resolution) in column326; and (8) an alert or event status (e.g., whether the alert or event requires additional action and is therefore “open” or whether it has been resolved and is therefore “closed”) in column327.

GUI300amay also include options that enable the user to change how alerts and events are displayed. For example, a user may configure GUI300ato show only alerts or events that have been generated by one or more alerting entities and filter out alerts or events generated by other alerting entities, e.g., by making selections in drop down menu330. Likewise, a user may configure GUI300ato display only alerts and events that correspond to one or more particular domains and filter out alerts and events corresponding with other domains by making selections in drop down menu331. The user may also determine how many alerts and events should be displayed on each page by making selections in drop down menu332. Likewise, the user may choose how alerts and events should be sorted in GUI300a, e.g., by release date descending, release data ascending, manufacturer, alert or event type, or by any other field included in the alert and event data entries. After making the selections in drop down menus330-333, the user may select “Apply” icon334to apply the selections and refresh GUI300a.

GUI300amay also enable a user to search among the various alert and event data entries, e.g., by typing a search term in search field340and selecting “Search” icon345. GUI300amay then display the events and alerts that satisfy the search terms.

GUI300amay also include features that enable the user to modify and/or manage alerts and events. For example, the user may have the ability to upload a new alert to product event manager110by selecting “Upload New Alert” icon350and entering alert information to be used by product event manager110to generate a new alert data entry. For example, responsive to receiving a selection of “Upload New Alert” icon350, product event manager110may prompt the user via GUI300ato enter data corresponding to columns320-327, and/or any other information that may be stored as a part of an alert data entry. The user may also be able to change the status of one or more alert or event data entries to “closed” by selecting a check box in column328corresponding to the alert or event to be closed and then selecting “Close Checked” icon355. In certain embodiments, the system may only allow a user to close an alert or event after receiving confirmation that the user has reviewed the alert or event, as discussed in the exemplary embodiments below.

FIG. 4is a flow chart illustrating an exemplary method400for managing product events that may be performed by product event manager110, for example, by executing event management program116and/or other programs associated with product event manager110. In certain embodiments, method400may be performed in conjunction with method200ofFIG. 2, e.g., after a product alert is added to an event data entry in step240and/or after a new event data entry is created and associated with a new product alert and a previous product alert in step260.

Product event manager110may update the status (e.g., open or closed) of an event data entry based on the addition of a new product alert and by optionally referencing filtering rules associated with the new product alert (Step410). For example, the product event related to the recall of Brand X surgical gloves may previously have been assigned a “closed” status because all product alerts associated with the event data entry had been addressed and closed. However, if a new product alert is also associated with this product event, then product event manager110may update the status of the event data entry to be “open” because there is now a new alert associated with the event that has not yet been closed.

In some embodiments, product event manager110may also determine whether the new product alert meets a set of filtering criteria that may be determined by a user or administrator for filtering out a subset of product alerts. For example, a user may use the filtering criteria to filter out product alerts from a particular alerting entity or product alerts associated with one or more products or manufacturers. If filtering criteria have been established, then at Step410product event manager110may not update the status of the event data entry if the new product alert satisfies the filtering criteria. For example, if the filtering criteria instruct product event manager110to filter out all alerts received from Alerting Entity A, and the new alert is from Alerting Entity A, then product event manager110may maintain the event data entry's status as “closed” and not change it to “open.” Moreover, in certain embodiments, product event manager110may still associate the filtered out alert data entry with the corresponding event data entry without updating the status of the event data entry.

If the status of an event data entry has been changed in Step410, a GUI may display an indication of the change to the user. For example, as shown in GUI300bofFIG. 5, event data entry315may have been changed to an “open” status (see column327) and may be displayed in a manner to distinguish it from the other data entries, e.g., by highlighting or otherwise changing a color of the cells representing event data entry315, outlining the cells, representing the text within the cells in a different color or font, etc. This may alert the user to the changed status of event data entry315, prompting the user to select event data entry315via GUI300bto review the new product alert and/or update workflow associated with the new product alert.

If, product event manager110receives, via GUI300b, an indication that the user has selected event data entry315, e.g., by clicking on event data entry315(Step420), then product event manager110may generate data to request acknowledgment that the user has received and/or read the new product alert (Step430). For example, upon receiving the selection of event data entry315, product event manager110may generate data for displaying GUI600ashown inFIG. 6, which may provide additional data related to event data entry315, such as event overview information610and event activity information620. GUI600amay also include a list of the alert data entries631,632, and633associated with event data entry315and, in “Alert Detail” tab630, a request for the user to read information related to new alert data entry631and then select icon634to indicate that the user has reviewed the alert.

A user may select icon634via GUI600ato indicate that the user has reviewed the alert. Responsive to the user's selection, product event manager110may receive an acknowledgement receipt from the electronic device associated with the user, indicating that the user has reviewed the alert (Step440.)

After receiving the acknowledgement receipt, product event manager110may generate data to enable the user to update a workflow associated with the product alert or otherwise manage different aspects of the product alert (Step450). For example, returning toFIG. 6, GUI600amay display an Action Panel640that includes actions the user may take to update the workflow of the product alert such as assigning a responsive action associated with the product alert to a responder (e.g., remove a recalled product from shelves, repair a faulty product, etc.). Action Panel640may also enable a user to assign a coordinator who may be responsible for overseeing the product alert and ensuring that all responsive actions are taken. Further, Action Panel640may enable the user to close a product alert when all responsive actions are taken. In certain embodiments, Action Panel640may be inaccessible (e.g., not visible, grayed out, etc.) via GUI600auntil after the user selects icon634.

Communication Panel650may enable the user to manage other aspects of the product alert. For example, via Communication Panel650, the user may add a work note providing additional details associated with a responsive action, send an e-mail to a stakeholder associated with the product alert, add, delete, or modify one or more attachments associated with the alert (e.g., the original product recall notice from the manufacturer, etc.), initiate a forum discussion regarding the alert, or print the alert.

Product event manager110may also update the event data entry based on the user's update to the product alert workflow in Step450(Step460). For example, continuing with the Brand X surgical glove product event discussed above, at Step410product event manager110may have changed the corresponding event data entry status to “open” because it received a new product alert related to the product event. Subsequently, a user may select icon634in GUI600ato indicate that the user has read the new product alert, and then perform a variety of tasks such as assigning a responsive action via Action Panel640, tracking the status of the responsive action, and eventually closing the product alert via Action Panel640. Responsive to the user closing the product alert via Action Panel640, product event manager may determine that all of the product alerts associated with the Brand X surgical glove product event are now closed, and, in response, may update the status of the event data entry to “closed” (Step460).

The process discussed above may repeat for subsequently received product alerts associated with the same product event. For example, if a subsequent product alert is received, product event manager110may change the product event's status to “open” and enable the user to modify a workflow associated with the subsequent product alert. Then, upon receiving instructions from the user that the subsequent product alert is closed, product event manager110may update the event data entry to a “closed” status.

Product event manager110may use the process described above to update other aspects of the event data entry based on updates to the workflow associated with underlying alerts and is not merely limited to updating the status of the event data entry. For example, product event manager may also update any of the fields represented by columns320-327ofFIG. 3of an event data entry based on updates to underlying product alerts and alert data entries associated with a particular product event and event data entry.

FIGS. 7 and 8show additional exemplary screen shots of GUI600athat may be generated by product event manager110and displayed to the user to track the progress of various workflows and responsive actions associated with the product alerts, in order to ensure the product alerts included in a product event are properly handled. This may enable a user, such as a coordinator responsible for managing the responsive actions, to close out alerts in a timely and efficient manner.

For example,FIG. 7illustrates a GUI600bthat may be displayed when a user selects “Product Information” tab660. As shown inFIG. 7, “Product Information” tab660may display a list of the product alerts631-633included in the product event. Additionally, GUI600bshows that product alert632has been selected inFIG. 7, causing product event manager110to generate data to display, via GUI600b, product information that is related to the particular alert, such as a product description, model or product number, stock identifiers such as lot numbers and expiration dates, an amount or volume of the product implicated, and a recall identifier that may be issued by the alerting entity.

FIG. 8illustrates a GUI600cthat may be displayed for a particular product alert, such as product alert832, when “Workflow” tab670is selected for that product alert. For example, window672may include a summary of the workflow associated with the product alert, including, for each facility implicated by the product alert, a listing of the responsible responder and coordinator, and documentation of the steps that need to be taken to close the alert as well as the progress made toward completing each of these steps. A user may consult “Workflow” tab670to determine when a product alert can be closed, for example.

The foregoing descriptions have been presented for purposes of illustration and description. They are not exhaustive and do not limit the disclosed embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practicing the disclosed embodiments. For example, the described implementation includes software, but the disclosed embodiments may be implemented as a combination of hardware and software or in firmware. Examples of hardware include computing or processing systems, including personal computers, servers, laptops, mainframes, micro-processors, and the like. Additionally, although disclosed aspects are described as being stored in a memory on a computer, one skilled in the art will appreciate that these aspects can also be stored on other types of computer-readable storage devices, such as secondary storage devices, like hard disks, floppy disks, a CD-ROM, USB media, DVD, or other forms of RAM or ROM.

Other embodiments will be apparent to those skilled in the art from consideration of the specification and practice of the embodiments disclosed herein. The recitations in the claims are to be interpreted broadly based on the language employed in the claims and not limited to examples described in the present specification or during the prosecution of the application, which examples are to be construed non-exclusive. Further, the steps of the disclosed methods may be modified in any manner, including by reordering, combining, separating, inserting, and/or deleting steps. It is intended, therefore, that the specification and examples be considered as exemplary only, with a true scope and spirit being indicated by the following claims and their full scope equivalents.