Patent Application
20220375578
One embodiment is directed generally to a computer system, and in particular to an integrated computer system that manages healthcare product recalls.
A healthcare product recall is a request to locate and return, destroy or update, a healthcare product (e.g., a medical implant or pharmaceutical drug) after the discovery of safety issues or product defects that might endanger the consumer or put the maker/seller at risk of legal action.
Product recalls can occur at any time. It could be a low probability but high consequence situation. In addition, ever increasing and changing regulatory compliance applies added pressure to adopt an effective product recall management strategy and practices. Quick and effective tracking and communication of the product recall to all affected stakeholders within the supply chain is critical and challenging.
Embodiments manage the recall of a healthcare product that includes a plurality of healthcare parts. Embodiments capture a recall notice for the healthcare product. Embodiments initiate by a locate engine a background process for locating each of the healthcare parts. Embodiments locate each of the healthcare parts using product traceability, where each of the healthcare parts includes a traceability status of Periodic Automated Replenishment (“PAR”), in stock, expense, or inbound. Based on the product traceability, embodiments generate a sequence of tasks based on the traceability status, the tasks implementing a recall action. Embodiments monitor the completion of the tasks to verify that the recall notice can be closed.
Embodiments provide an integrated recall management system for the healthcare industry that uses novel interfaces to integrate third party applications and provides trace details for a specific item and/or location and trace details for tasks across all locations.
In addition to problems associated with product recalls in general, product recalls for healthcare products have differences that result in unique problems. For example, in healthcare, for healthcare products, the individual healthcare parts are typically not tracked using a lot number, serial number or internal item number within an inventory management system or enterprise resource planning (“ERP”) system. Instead, healthcare product parts are generally stocked in non-quantity tracked locations and therefore, merely using on-hand quantity tracking in an inventory management system will not help in tracing the recalled parts.
In the automotive industry, a product recall can be tracked by serial numbers using inventory on-hand balances as the parts would exist in quantity tracked locations and using install base records if the parts are already sold. In contrast, in the healthcare industry, parts generally exist in Periodic Automated Replenishment (“PAR”) locations, which are essentially non-quantity tracked locations or issued to expense locations which are the point of consumption in the respective departments without any serial or lot references within ERP that cannot be tracked using inventory on-hand balances. Therefore, embodiments include a “Locate Recalled Parts” engine that includes the capability of tracking the recalled parts lying in non-quantity tracked locations and parts that are not lot/serial controlled and not maintained with unique item number in an item master. Further, recalled parts that are in transit or available as a scheduled supply or lying-in receiving dock before getting shelved in the warehouse get tracked in embodiments and the respective stakeholders are alerted so that they do not receive those parts for consumption but instead would quarantine them.
A healthcare product recall is a request to quarantine and dispose a product after the discovery of any defects with the product, health hazards, or safety issues that might endanger the consumer or put the maker/seller at risk of legal action.
Managing the recall originating in the supply chain is a critical path for consumer safety. However, as discussed, there are multiple specialized needs in managing a product recall specific to healthcare products, including the following:
Automating receipt, handling, and processing of recall notices from multiple stakeholders: Untimely receipt of information about a product recall due to manual notification methods with multiple stakeholders involved in the supply chain such as manufacturer, distributor, regulatory authorities and third party solution providers who provide product alerts and recalls and internal stakeholders who consume those affected goods.
Technique for effective tracking and trace to ensure timely identification and locating affected goods: Limited visibility into what lots or serials were consumed or in which locations the affected goods could potentially exist. Delay in identification of affected goods increases the risk of consumption of those goods especially in the healthcare industry where the patient life is put at risk. Multiple execution systems are involved in the supply chain where product master, procurement of goods, inventory and order fulfilment is managed in ERP, drugs or devices issued to patients and products implanted on patients are tracked in the Point of Sale (“POS”) and the Electronic Health Record (“EHR”) respectively. Systems do not communicate with one another nor have a common value to allow tracing the recalls up to the end consumer
Monitoring disposition action: No visibility and control over what actions are taken on the recalled goods that are identified and hence no accountability on the disposition action to be carried out for the affected goods.
Known ERP systems require users to follow a large amount of complex manual processes in an attempt to address the above problems related to healthcare product recalls. Specifically, users of known ERP systems receive manual notification on recall from multiple sources and then need to inform the internal stakeholders manually. Users further need to verify whether the recalled lots or serials have been procured by the organization and identify the locations where these affected parts exist, which is a cumbersome and time-consuming activity. By the time all these locations are identified, there is a high possibility of the recalled parts getting consumed, putting the consumer at risk. Users need to then manually follow up with warehouse personnel to dispose the affected parts and keep track on the disposition details. If the affected product is not in stock, users then review POS and EHR or implant logs manually to identify whether any patient has adverse impact due to the recalled product and take corrective action.
In contrast to known solutions for implementing healthcare product recalls, including using existing functionality in an ERP system, such as an ERP system from Oracle Corp.®, embodiments provide the following novel functionality: (1) Capturing of product recalls from different sources that includes regulatory authority, manufacturers, distributors or any third-party solution providers; (2) Locating recalled parts based on on-hand inventory balances and historical purchases; (3) Assigning tasks and align resources to quarantine the affected goods; and (4) Monitoring disposal tasks to completion to ensure all impacted goods are disposed.
Reference will now be made in detail to the embodiments of the present disclosure, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. However, it will be apparent to one of ordinary skill in the art that the present disclosure may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the embodiments. Wherever possible, like reference numbers will be used for like elements.
In embodiments, a recall notice is always captured for a manufacturer part number which acts as a unique reference across different sources regardless of who initiates the recall, along with the lot and serial numbers that are recalled. Embodiments provide support for description-based items where the internal item number is not maintained in the product master.
In embodiments, product recalls captured from multiple sources are centrally managed through a work area which guides the user with appropriate actions to be taken on a recall notice based on its status and helps the user navigate to different user interfaces to manage the notices (details disclosed in
Specifically, embodiments include a workbench with advanced search capabilities with fuzzy match, auto suggestions, recent searches and filters that provides visibility on the recall notices that automatically get imported and notices progressing with different statuses. Embodiments further guide a user with appropriate actions to be taken on a recall notice based on its status and helps in navigating to different user interfaces to manage the notices. For example, if a recall notice is imported very recently as a “New” status, embodiments will suggest the user to review the notice and publish it. However, if the notice is already published and having the status as Open, embodiments will provide a suggestion to proceed with the next step of resolving the duplicates.
Embodiments use an elastic search technique where the recall notice attributes are ingested into a search server, also referred to as “Global Search” from Oracle Corp. The Global Search, for Oracle Enterprise Applications, allow each application having search requirements to define their searchable business objects and enable full-text, real-time search capabilities on them. It provides design-time capabilities to define search indexes and provides run-time capabilities to push these index payloads into an Elasticsearch search engine and query them via REST and Java APIs.
When a search is performed on the user interface, recall notices are retrieved based on the keywords that match with the indexed attributes. Guided navigation is provided in this user interface such that user can take appropriate action by navigating to the respective page as per the status of the recall notice.
Embodiments further locate recalled parts 103 and assign tasks 104.
Embodiments locate the recalled parts in the supply chain based on on-hand inventory balances for parts that can be stocked in quantity-tracked locations and based on historical purchases for parts that are received in non-quantity tracked locations. Recalled parts are traced by lot or serial if the item is lot or serial controlled, or traced by date range when the parts are not lot/serial controlled.
Embodiments include a locate recalled parts engine that is implemented as a background process which does the track and trace of recalled parts in the entire supply chain with different traceability statuses. Recalled parts that are in transit or available as a scheduled supply or lying-in receiving dock before getting shelved in the warehouse are traced as inbound. Recalled parts that exists in quantity tracked locations are identified based on stock availability and shown as in stock. Examples of transaction history include various transaction types, including Transfer Order Issue, Account Alias Issue, Movement Request Issue and User Defined Miscellaneous Issue, used to issue the material from stock to expense locations. Recalled parts that are issued to PAR locations are identified based on transaction history and shown as PAR with an estimated quantity. Recalled parts that are issued to expense locations as well gets identified based on transaction history and traced as expense with an estimated quantity.
Once the recalled parts are located at 103, embodiments assign a corresponding pre-defined set of tasks in a sequence based on traceability status and the replacement type captured in the recall notice at 104. Tasks include—Count, Deliver, Disposal, Debit Memo and Instructions. Count task refers to performing a recall count in the identified locations and move the counted parts to a quarantine location. Deliver task is meant to deliver the recalled parts to quarantine location. Disposal task refers to performing a return to vendor or scrap disposal. Debit memo task is meant for creating a debit note against the disposal performed for the recalled parts. Instructions task is meant to carry out the recall instructions like device correction or labelling changes.
Count tasks can be grouped by department represented by inventory organization or location or sub-inventory as per the configuration. Tasks get progressed automatically (e.g., marked as closed when completed) based on disposition details captured while performing the count and disposal activities. Embodiments allow a user to review the trace details for a specific item by selecting its different traceability statuses. Embodiments further allow a user to review the trace details across the recall notice for a specific task. For example, a user can see in which departments the count task is in progress and in which departments the task is completed. A user can also review the trace details for a specific inventory organization or sub-inventory.
Embodiments allow a user to configure business rules to send the notifications to respective stakeholders to carry out the recall tasks. Whenever a task becomes in progress, a notification will be sent to the user at 105 as defined in the rules so that they can start performing the required actions.
Embodiments monitor disposition details at 106 and the closure of the recall notice at 107. Based on the notifications received, users can start performing the recall count in all identified locations that include quantity tracked, PAR and expense locations. The recall count quantity can be reported through interfaces including an RF-SMART mobile inventory solution that utilizes mobile barcoding or through the “Oracle Visual Builder Plug-in” for Excel. Recall count can also be reported to an inventory management system such as “Oracle Inventory Management” through any third-party application by leveraging the Inventory Count REST API.
Reporting the count quantity automatically transfers the stock of counted parts to a quarantine location which is generally a non-reservable recall sub-inventory so that materials moved to this recall sub-inventory can no longer be consumed. Once the count quantity is reported in all identified sub-inventories or stock locators for all lots/serials, the corresponding task will get marked as completed automatically. Specifically, when the count quantity is reported, the count details get updated in the database against each identified stock-keeping unit (“SKU”) through a patch operation performed using the Inventory Count REST API. This in turn invokes the recall trace API to update the count quantity against the recall trace details stored in recall management schema based on which the count tasks move to closed status (shown below in
Recalled parts that are counted and quarantined can be scrapped at the facility or returned to the supplier depending on the replacement type. Disposition details get updated automatically and disposition tasks gets marked as completed when all the counted quantities are returned. On completion of the disposal task, a debit memo task gets initiated and users are notified to create a debit memo for the return of recalled parts. Once notified, the debit memo task will be marked as completed.
When all the tasks assigned to a recall notice line get marked as completed, the recall notice line gets closed automatically. This ensures that a recall line is closed only after all affected goods are quarantined and disposed. When all the lines in a recall notice get closed, the recall notice is marked as closed. Embodiments can use the recall notice REST services to integrate the EHR or the POS with an ERP to track recalled parts that are already consumed by the patients and take necessary corrective action.
System 10 includes a bus 12 or other communication mechanism for communicating information, and a processor 22 coupled to bus 12 for processing information. Processor 22 may be any type of general or specific purpose processor. System 10 further includes a memory 14 for storing information and instructions to be executed by processor 22. Memory 14 can be comprised of any combination of random access memory (“RAM”), read only memory (“ROM”), static storage such as a magnetic or optical disk, or any other type of computer readable media. System 10 further includes a communication device 20, such as a network interface card, to provide access to a network. Therefore, a user may interface with system 10 directly, or remotely through a network, or any other method.
Computer readable media may be any available media that can be accessed by processor 22 and includes both volatile and nonvolatile media, removable and non-removable media, and communication media. Communication media may include computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and includes any information delivery media.
Processor 22 is further coupled via bus 12 to a display 24, such as a Liquid Crystal Display (“LCD”) and includes a microphone for receiving user utterances. A keyboard 26 and a cursor control device 28, such as a computer mouse, are further coupled to bus 12 to enable a user to interface with system 10.
In one embodiment, memory 14 stores software modules that provide functionality when executed by processor 22. The modules include an operating system 15 that provides operating system functionality for system 10. The modules further include a healthcare product recall module 16 that implements healthcare product recall functionality, and all other functionality disclosed herein. System 10 can be part of a larger system. Therefore, system 10 can include one or more additional functional modules 18 to include the additional functionality. In one embodiment, module 18 implements an ERP, and module 16 is ether additional functionality integrated with the ERP, or interacts with the ERP functionality. In other embodiments, module 18 implements “Manufacturing and Supply Chain Materials Management” from Oracle Corp., and the functionality of module 16 is an added feature. A file storage device or database 17 is coupled to bus 12 to provide centralized storage for modules 16 and 18. In one embodiment, database 17 is a relational database management system (“RDBMS”) that can use Structured Query Language (“SQL”) to manage the stored data.
In one embodiment, particularly when there are a large number of distributed files at a single device, database 17 is implemented as an in-memory database (“IMDB”). An IMDB is a database management system that primarily relies on main memory for computer data storage. It is contrasted with database management systems that employ a disk storage mechanism. Main memory databases are faster than disk-optimized databases because disk access is slower than memory access, the internal optimization algorithms are simpler and execute fewer CPU instructions. Accessing data in memory eliminates seek time when querying the data, which provides faster and more predictable performance than disk.
In one embodiment, database 17, when implemented as an IMDB, is implemented based on a distributed data grid. A distributed data grid is a system in which a collection of computer servers work together in one or more clusters to manage information and related operations, such as computations, within a distributed or clustered environment. A distributed data grid can be used to manage application objects and data that are shared across the servers. A distributed data grid provides low response time, high throughput, predictable scalability, continuous availability, and information reliability. In particular examples, distributed data grids, such as, e.g., the “Oracle Coherence” data grid from Oracle Corp., store information in-memory to achieve higher performance, and employ redundancy in keeping copies of that information synchronized across multiple servers, thus ensuring resiliency of the system and continued availability of the data in the event of failure of a server.
In one embodiment, system 10 is a computing/data processing system including an application or collection of distributed applications for enterprise organizations, and may also implement logistics, manufacturing, and inventory management functionality. The applications and computing system 10 may be configured to operate with or be implemented as a cloud-based system, a software-as-a-service (“SaaS”) architecture, or other type of computing solution.
At 302, the recall notice is captured either through entering it in “Create Recall Notice” UI 301, File Based Data Import (“FBDI”) 303 as a mass upload through a macro enabled excel, or REST API 303. The recall notice includes a header and line section where the header includes a recall notice number, the source from where the recall notice was received, the initiation date, the closing date, manufacturer details, the recall notice type, classification based on severity of the impact that the recalled product has on consumers, potential risks and recall instructions and replacement type. The line section includes manufacturer part details, internal item details, lot and serial details.
There is a possibility that different sources can issue a recall notice for the same product. For example, a manufacturer of a particular product issues a recall notice once the manufacturer realizes that there is a product defect. A regulatory authority such as the FDA also can issue a recall notice for the same product based on complaints reported by consumers. In such a case, at 304 potential duplicate recall notices will be automatically suggested based on certain criteria, such as common product names, identifier numbers, manufacturer name, trading partner party number, source document reference, etc., after the recall notice is published. These potential duplicates will be marked as duplicate and no further action will be taken on those lines.
At 305, to identify the recalled parts in the supply chain, a “Locate” action will be initiated on the recall notices. This launches a scheduled job in the background which locates the recalled parts of the healthcare product with different product traceability statuses shown below depending on where those parts exist in the supply chain.
Product traceability details are displayed in the form of header and child structure when a drill down is done on the recall notice lines. Traceability status is stored in a database. In embodiments, depending on the transaction types used and the recalled parts that are transacted and the locations where the recalled parts could potentially reside, traceability statuses exists as pre-defined lookup values. The header section includes product traceability status, warehouse, location, sub-inventory (optionally based on configuration) and total transaction quantity. The child section includes sub-inventory, stock locator and transaction details such as the source transaction type, source transaction number, on hand quantity/transaction quantity against each transaction.
Once the traceability status is identified and corresponding source transaction details are retrieved (i.e., the transaction history), a sequence of tasks will get automatically assigned to the recall notice lines (307, 309, 312, 314). This task assignment is primarily determined based on the product traceability status and the replacement type. The recalled parts are identified with different traceability statuses that have been defined as standard lookup values based on the transaction history and the locations where those parts reside.
Once the tasks get assigned, at 315 notifications are routed to appropriate stakeholders within the enterprise to perform necessary actions based on the task initiated. A business process management (“BPM”) work list is used to route the notifications where users can configure the rules to route the notification to users or roles based on different attributes pertaining to recall management as per their business requirement.
As instructed in the notification, users can perform the relevant action which results in certain transactions such as physical count reporting, moving the material to quarantine location, return to vendor or perform a scrap and updates the task status as “Completed”. Transaction details are also captured and shown as a disposition summary at 316. Once the first task in the sequence gets closed, the subsequent tasks get initiated and trigger notifications. Once all the tasks get completed, the recall notice line is closed at 317 and finally the status at the recall notice header comes to a closure.
In embodiments, integration is implemented, at least in part, using “Service Oriented Architecture Cloud Service” (“SOA CS”) or Oracle Integration Cloud Service (“OIC”) from Oracle Corp. to automatically capture the recall notices 402 issued by regulatory authorities, manufacturers, suppliers or subscription services such as “RASMAS” into product recall management 100 using either file-based data import (“FBDI”) 412 or a Recall Notices REST API 413.
Product recall management 100 interacts with ERP modules. In connection with ERP from Oracle Corp., Oracle Product Information Management Cloud (“PIM”) 405 is used to get the inventory items and trading partner items for manufacturer part numbers. Oracle Procurement Cloud 406 is used to get the manufacturer part numbers from the blanket agreements. Once the recall parts are located at 420, the trace details 421 are sent to Oracle Inventory 407. The details of counting and disposal of the recalled parts are received from Oracle Inventory and Oracle Receiving in embodiments.
Product recall management 100 integrates with the RF-SMART 408 remote reader in embodiments, which enables recall count 422 and transfer of material to quarantine locations based on barcode scanning with a handheld device. This integration is implemented using Inventory Count Task REST services that supports interfacing the traceability details to RF-SMART and capturing the recall count details back to close the recall tasks after ensuring all the recalled parts are quarantined. These REST services in other embodiments can be used to perform recall count and disposition using any third-party warehouse execution systems 409 with an extension on the client side of warehouse management applications.
In embodiments, SOA CS or OIC is used to identify the recalled parts that are tracked in external applications such as EHR 403 and POS 404 once issued out of inventory in ERP, and take corrective actions required for disposal using Recall part/lot/serial REST services 413.
Embodiments implement multiple specialized REST web services that interface with 3rd parties and users via a REST API request. These REST web services in embodiments are listed below in Table 1:
At 1001, the locate action is initiated on the recall notice that includes the details shown at
In embodiments, parts that are captured in the recall notice can be either a lot/serial controlled item in an inventory management system such as “Oracle Inventory” or not a lot/serial enabled item regardless of whether the parts are lot/serial controlled in the manufacturer end. If the parts are lot/serial controlled in the inventory management system determined at 1003 and 1004, the process track the parts based on lot # and/or serial #1005. If the parts are not lot/serial controlled in the inventory management system, the process track the parts based on date range captured in the recall notice at 1011. If there is no date range captured in the recall notice, it can be externally provided.
A recall notice can have multiple lines with some parts that are lot/serial controlled in inventory management and some parts that are not. However, the locate action is initiated at the entire recall notice header level and a date range may still be requested. This date range has to be used only for parts that do not have lot/serial number in inventory management.
Table 3 below provides the determination of traceability methods based on lot and serial attributes of the recalled product:
Locate by Lot/Serial
With the derived lot/serial number for the recalled part in each inventory org, perform the tracing as follows by passing the parameters—Item ID, Lot #/Serial #,
Organization ID:
1. Verify whether there are any purchase receipts, Subinventory transfer,
Movement Request transfer, Direct Org transfer, In transit receipt, Transfer Order transfer, Transfer Order receipt into non quantity tracked subinventory for the item #, lot # and/or serial #. If this returns records, insert trace headers with the product traceability status as PAR.
2. Verify whether stock exists in quantity tracked subinventory for the item #, lot # and/or serial #. If this returns records, insert trace headers with the product traceability status as IN STOCK.
3. Verify whether there are any Transfer Order issue (Transfer order already received in destination), Movement Request issue, Miscellaneous issue, Account issue, Account Alias issue, User defined Miscellaneous issue for the item #, lot # and/or serial #. If this returns records, insert trace headers with the product traceability status as EXPENSE. All types of Misc. issues (user defined, account alias . . . ) should have the requester populated only based on which the issue transaction would be considered to stamp the traceability status as EXPENSE. Though the item is lot/serial controlled, when there is a direct purchase receipt of this item to expense location, it is not possible to capture the receipt based on lot/serial as the destination is EXPENSE. In such a scenario, the purchase receipts to expense location should be captured for the recalled item based on the date range provided while initiating the LOCATE action.
4. Verify whether there are receipts against in transit shipments, purchase orders or transfer orders which are yet to be delivered to the subinventory for the item #, lot # and/or serial #. If this returns records, insert trace headers with the product traceability status as INBOUND. When there are multiple lots or serials for the same shipment line which have a partial receipt against in transit shipment, it is not possible to identify which lot/serial is in transit and which one is received. In this case also, the traceability status should be stamped as INBOUND. Though the item is lot/serial controlled, when there is a purchase receipt to Receiving dock without any ASN, it is not possible to capture the receipt based on lot/serial. In such a scenario, the purchase receipts to Receiving destination should be captured for the recalled item based on the date range provided while initiating the LOCATE action.
5. Verify whether there are Advanced Shipment Notices (“ASN”) against purchase orders, in transit shipments, transfer orders for the item #, lot # and/or serial #. Also verify whether there are any open purchase orders for the item #. If both the validations return records, insert trace headers with the product traceability status as INBOUND.
Locate by Date Range
For the recalled parts that are not lot/serial controlled in each inventory org, perform the tracing as follows by passing the parameters—Item ID and recall track date range captured at the time of taking the ‘Locate’ action.
The recalled items can be non-lot/serial controlled in Oracle Inventory, but it can be lot/serial enabled from the manufacturer perspective. Therefore, there would be a manufacturer lot/serial number for which recall would have been initiated and captured in recall notice. It does not make sense to say that all the quantities that are received for the recalled item # during the recall date range are recalled parts and need to be disposed. Therefore, estimated recall quantity should be calculated only based on the material that is transacted through defective sub-inventories that will be identified prior to starting the trace of recalled parts.
1. Identification of defective subinventories.
2. Identify all quantity tracked subinventories and stock locators (if exist) across inventory organizations where purchase receipts are done during the recall period and mark them as defective subinventories and locators.
3. Identify all transfers to quantity tracked subinventories and locators (except Recall subinventory) from the defective subinventories and locators from recall track start date till date (Sub transfer with qty <0, Movement request transfer with qty <0, In transit shipment (already received), Direct org transfer with qty <0, TO Shipment (already received), TO Transfer with qty <0). This can be executed recursively for the resultant output till we get 0 records.
Note: Recall Subinventory is the final location where the identified recalled parts will be quarantined and then will get disposed from there. Hence this subinventory is bound to have the recalled parts and should not be considered as defective subinventories.
4. Insert trace headers with traceability status as IN STOCK when on hand quantity >0 for any of the defective subinventories already identified as per the steps above.
5. Insert trace headers with traceability status as PAR when there are purchase receipts into non quantity tracked subinventories during the recall period.
6. Insert trace headers with traceability status as PAR when there are transfer receipts (Sub transfer with qty >0, Movement request transfer with qty >0, In transit receipt, Direct org transfer with qty >0, TO Receipt, TO Transfer with qty >0) to non quantity tracked subinventories during recall track start date till date. But the transfer should have taken place from the defective subinventory already identified.
7. Insert trace headers with traceability status as EXPENSE if there are receipts against purchase orders of expense destination during the recall period for the recalled item #. In case of description based items, verify whether there are any purchase receipts for the Manufacturer part number. Get the BPA corresponding to recalled MPN and derive the standard po line that refers this BPA line. Verify whether there is any DELIVER transaction to expense location for this standard PO line in the receiving transaction history. Trace records should be populated for MPN as the item number is null for the recall notice having description based items.
8. Insert trace headers with traceability status as EXPENSE if there are issues (TO Issue against transfer order in received status, Misc. Issue, Account Issue, Account Alias Issue, Movement Request Issue, User Defined Misc. Issue) into expense location from the recall track start date till date from the defective subinventory already identified.
9. Insert trace headers with traceability status as INBOUND if there are receipts against purchase orders during the recall period which are yet to be delivered to the subinventory or location.
10. Insert trace headers with traceability status as INBOUND if there are transfer receipts (In transit receipt, TO receipt with inventory destination) from the defective subinventory, during the recall track start date till date which are yet to be delivered to the subinventory or location.
11. Insert trace headers with traceability status as INBOUND if there are ASN against purchase orders during the recall period.
12. Insert trace headers with traceability status as INBOUND if there are open purchase orders for the recalled parts.
13. Insert trace headers with traceability status as INBOUND if there are in transit shipments (interorg shipment, TO shipment and TO Issue) during the recall track start date till date from the defective subinventory already identified.
At 1006, once the trace headers and details are created, the “Locate Recalled Parts” process invokes an inventory count API to populate the trace records in the Inventory count table. Based on the records populated in inventory count table, the Inventory Count user interface will display the records with SKUs against which physical count quantity will be reported by the user. The sequence in which trace records were populated should be followed while populating the Inventory Count table by invoking the Inventory Count API so that the person doing the physical counting need not go around different sub-inventories in a random fashion to perform the counting.
At 1008, as an outcome of the “Locate” action on the recall notice, product traceability statuses are identified with the corresponding source transaction details by the ‘Locate Recalled Parts’ process as explained above. Based on this product traceability status and replacement type specified under Recall Instructions of the recall notice, a sequence of tasks get assigned by the same scheduled process ‘Locate Recalled Parts’ at 1009. These tasks are primarily meant to perform the physical count of recalled parts in the identified locations, quarantine them and subsequently take disposition action such as performing a return to vendor or destroy the parts. There can also be a situation where the action would be to just follow some instruction such as labeling change or device correction which is categorized with the replacement type in the recall notice as “Correction”. This task does not involve any inventory or financial transaction and it is just performing the task as instructed. Depending on the nature of the task, it will be either assigned to the product traceability header or to the disposition organization in which the recalled parts are located. Details of the tasks and the sequence in which they get assigned based on certain conditions are listed in Table 4 below:
These tasks are seeded and defined in the database level and not exposed to users through the configuration UI. The task sequence for each product traceability status is also seeded and defined in the database level and not exposed to users through the configuration UI. Gaps are provided in the task sequence numbering just to accommodate more seeded tasks in between the existing sequence if there is a business need in future. Based on the replacement type in the recall notice, the appropriate task for a product traceability status will be picked from the task assignment seed data.
As disclosed, healthcare product recall system 100 provides for an integration of an ERP system with a regulatory authority or any third-party applications in real time using REST APIs and file-based data imports to capture recall notices on-time rather than receiving the notifications manually from multiple sources which introduces delays. Embodiments include extensive traceability of recalled parts across different locations in the enterprise. The locate engine not only tracks the recalled parts in stock but also traces the parts lying in non-quantity tracked locations, thereby ensuring consumer safety. Embodiments automatically assign the appropriate recall tasks, segregate them based on departments and notify resources to dispose the affected parts. This avoids the need to locate the affected parts in the perpetual inventory locations and non-quantity tracked locations and then quarantine them for disposal.
Embodiments include automated notifications driven by flexible business rules that provide alerts to the stakeholders in various departments where the recalled parts are located so that they can carry out the assigned tasks required for disposal. Embodiments provide integration with devices such as RF-SMART, enabling a recall count using hand-held device. Any third-party logistics execution systems can leverage the recall count REST services to report the count quantity in identified locations and to quarantine them. Embodiments provide a magnified view on the traceability details and the tasks assigned, enabling a user to monitor the automatic tasks progression in different departments and locations. This in turn provides more visibility and control over what actions are taken on the recalled goods. There is no need of manual follow up with the warehouse personnel to perform the disposition tasks.
REST services provide by embodiments integrate an ERP system with EHR or POS to trace the patients affected by the recall and take corrective action rather than manually checking the implant logs or EHR.
Embodiments provide a magnified view on the traceability details and the tasks assigned, enabling the monitoring if the automatic tasks progression in different departments and locations. A user can review the trace details for a specific item or specific location with different traceability statuses. The user can also track the progress for a specific task across different locations. For example, a user can see in which all departments, the count task is in progress at a given point of time and in which departments the task is already completed. A predefined set of tasks get assigned automatically based on the traceability status and replacement type and those tasks automatically get progressed and closed based on certain validations. For example, a Count task will get closed only when the recall count quantity is reported in all identified locations. A Disposal task will get closed only when the disposition quantity matches with the count quantity for a given facility. There is no need of manual intervention to close the recall notice as it would automatically get closed when all the predefined set of tasks get closed based on the above-mentioned validations.
Several embodiments are specifically illustrated and/or described herein. However, it will be appreciated that modifications and variations of the disclosed embodiments are covered by the above teachings and within the purview of the appended claims without departing from the spirit and intended scope of the invention.
| Number | Date | Country | Kind |
|---|---|---|---|
| 202141022723 | May 2021 | IN | national |
