Setting up Surgery as an Inventory location.

We had out Cath Lab set up this way for a time. The Cath Lab system would generate a daily interface csv file that was used by ProcessFlow to convert to a req (they couldn't output the file in the RQ500 format). The req was processed to decrement the inventory and then IC140 was run to replenish the inventory. We had two areas (Cath Lab and Interventional Radiology) that shared two storage areas. They have since implemented a new system (Qsight) that has better inventory tracking so we converted the inventory in Lawson back to pars.

Positives: "Known" inventory value for the cath lab at any time; supplies expensed to the department as they were used

Negatives: Inaccurate SOH due to staff hording supplies in the procedure rooms and no control over supplies going out of the storage areas.

Thank you for your response, I am not quite understanding the set up you had(would generate a daily interface csv file that was used by ProcessFlow to convert to a req (they couldn't output the file in the RQ500 format). The req was processed to decrement the inventory and then IC140 was run to replenish the inventory).

Did you have the items set to order as NS's at all? We were thinking of setting it up like an inventory location, that 1. pulls product (from the main warehouse, in a stock transfer and 2. creates PO's for NS items based on the pars set.

The problem I think would be the same as you had, no control over supplies going out of the storage area, how to issue product when used in the surgery rooms. Thought would be to use the Cerner picks and issue product out that way, but it would take constant monitoring of stock being taken without recording/issuing out.

 

Thanks again, appreciate it.

I had several hospitals that created a separate inventory location for sterile processing (surgery) with some of the items in that location replenishing from storeroom and some items replenishing from vendors. We'd also setup our surgical consignment items (mainly ortho supplies) in that location. We also then implemented an interface so that the clinical system (cerner or epic) decremented inventory when we loaded the case (preference card based) and then returned to inventory anything that wasn't used in the case. Issues we had were mainly caused by staff pulling inventory during a case from SPD inventory and not issuing it out or documenting it in the clinical system. It all comes down to how much you can force the staff to operate in the manner that the system expects to happen.

I'll try to clarify. In our setup the Cath Lab clinical system (at that time it was Hi-IQ) would generate the file based on supplies used during the day. When each encounter was closed a file would be created with the Lawson item and quantity used. So there might be 10-15 files created every day. Overnight a batch program ran to combine all those files into one file that was transferred to Lawson where ProcessFlow would pick it up and convert it to a req. That req used a par location as the requesting location from which the other information (UOM, source: vendor/NS vs. inventory) would default. So all PF needed to plug into RQ10 was the item number and quantity.

We didn't replenish any Cath Lab inventory through transfers from main inventory. Anything that came out of main for them was ordered through a par and expensed to the Cath Lab at that time. We used IC140 to replenish the inventory just like main.

Thanks, that is interesting about the interface from Cerner which decremented inventory, another concern we have is that now that surgery would need to do their receiving into Lawson on the PO's they create. As you stated how much can we force the staff to operate in the manner the system needs.

 

Thanks!

 

 

Thanks Jon, that makes sense. So you had a lot of unique set up. We would try to keep it simple, maybe we could start with say Sutures, work out the bugs on that and then continue on with other item groups.

So you did not have any items that ordered directly from the Vendor when the reorder/min level was reached?

 

Yes we did. The items on the par used by PF to create the nightly req were mostly replenished from the Cath Lab inventory.  WH130 was run in the morning to decrement stock and later in the day IC140 was run to replenish the stock from the vendors.

For a long time we had both an OR perpetual inventory (ORP) and a sterile processing perpetual inventory. Last January we finally go the okay to convert the sterile processing inventory into one large par cart (owned by the OR). We had a slew of issues with it that mostly revolve around the human factor. People would come and take stuff without telling the inventory coordinator; we get a mountain of returns every day. The coordinator was basically going a par count of the entire room in order to know what to order for replenishment - we couldn't trust the counts in Lawson to generate the orders. Except for the fact that I can no longer report on the financial impact of the returns (it was at 25% of total issues), it has been an overwhelming success and staff satisfier.

For the ORP inventory, we will never be allowed to move away from the perpetual inventory model. We have about $6M total (owned and consigned) on the books. Every year we do a physical inventory and have adjustments of about $200-300 thousand. We have Omnicells in all of our OR rooms. The Omnicells send replenishment requests for vendor POs into Lawson and the OR Buyer manages the POs and orders what is needed. For items that are in sterile processing, the Omnicells physically print what is needed and the SPD staff pick it from the (now) par cart and refill the machines. Since the goods are already expensed to the OR's cost center when received for the SPD par cart, we had to set up a job that would credit that cost center and increment ORP inventory whenever they refill the machine from downstairs. It is honestly less complicated that it used to be.

Our Cath Lab and Surgicenters occasionally make noises about wanting to be perpetual inventories just like the OR and we tell them firmly....NO YOU DON'T.

We have our OR Supply(s) as their own inventory locations, and they have their PARs set from there. The inventory holds everything except the "patient specific" items (for example the Ortho Implants that the rep brings in just for that case) and the case carts are pulled and decremented from the inventory.

Consider a design that has the OR as a Par Location sitting on top of its own perpetual inventory. You will gain all the advantages of IC12 tracking as well as the advantage of maintaining your OR supplies via Par counting. Use "Pick for Par" on your MSCM app to decrement the inventory without the need of Res and Pick Tickets. Then just run a replenishment program to increment the stock back to it's Par level. You SOH will essentially be equal to what is in the Par and you'll have your financial value of inventory. This design is the least intrusive because you don't have to have to process adjustments, cycle counts, returns or any of the other transactions that are involved with typical inventories.

Note JonA's negative.

We've managed a few of these and the most difficult part is tracking the activity, removing and returning inventory. This seems to be an issue in locked areas that are under the control of Supply Chain and is much more difficult in a procedural area usually with many more bodies. If you cannot keep your counts correct having the right amount of product on hand can be very difficult.

Thanks all who weighed in on this most debated subject I have encountered here - very interesting.
We currently have several flavors of this in use throughout the enterprise with varying levels of success that I believe rely on the physical layout of the surgery rooms / cores and business process specifically in how cases are managed and billed.
PYXIS has been generally successful as Pyxis interfaces "bin" (Cabinet/drawer/slot) data to Epic which enables a accurate pick document, then it creates a RQ500 file what we process for replenishment. The Pyxis console shares a PAR setup so that sourcing can be controlled.
WAVEMARK is also pretty solid - clinical staff manages ordering in Wavemark and the system creates a "requisition" which we inerface to Lawson, create a PO, return PO number, and also receiving data when product is received in Lawson. This isa pretty expensive system though utilizing RFID tagging and so not appropriate for lower cost items.
EPIC has used a couple of iterations over the years - the most promising was a custom design we developed that took into account items that were pulled prior to a procedure from a storage area and those that were pulled from a surgical core during. The Achilles heel of this was the inability to indicate WHERE product needed to be delivered/stocked to when it was replenished.
Key Learnings:
- TIME - How long is your product tied up in process from the pick for case, until case is closed and net use can be determined. This can lead to more SOH than desired.
- CLINICAL INVOLVEMENT - Good/bad/or otherwise, data has to be collected - either from preference cards, scanning, or manual entry. You can't replenish what you don't know was used. Maintaining supply chain is not the priority during a patient procedure - it's a tricky balance and has to be virtually effortless for the clinical team.
- AUDIT- No system in the world will produce a "hands off" inventory. We use too many items, moving at a large volume. Someone has to putaway, double check, adjust SOH and order levels, move items to correct bins, etc. If you have staff doing this anyway, replenishment through MSCM is sometimes a far less expensive and efficient process which it's why that is the prevailing process here.

We did that at Mayo Clinic in Jacksonville using the surgical core as the location in the IC12. It worked just fine. The only down falls noted was that the conversion factors on the issue UOM and purchase UOM must be accurate. And that compliance with the surgical staff on maintaining an accurate count of stock on hand is very critical. Unless you have a complete buy in from the surgical staff to ensure that item counts are well maintained, I advise against the approach. Instead create locations based on procedural preferences and have them create reqs to purchase orders. A smaller item count to maintain. Lastly, break down your surgical core to multiple select IDs for inventory counts using the IC170 and do those in a round robin fashion on a monthly basis.

Hello.  I'm new to Lawson but have been an Epic Optime and Anesthesia analyst for many years.  Recently, I took a position back on the clinical side in an OR and we're in the process of becoming an affiliate of a larger institution using Epic.  We are not at go-live yet however our OR inventory has been added to Lawson in the Epic production environment.  After Logging in I expected to see only our OR's inventory however, I'm seeing  ALL inventory items of ALL locations (approx 16).  A vast majority of the items avaliable to us for use on preference cards and adding to patient records are not ours.  Epic has no way of discerning incorrect items via reporting workbench criteria because it see all items as ours. The managing IT department is not giving me any details of why this is built this way as it makes preference card build much more difficult and we are not sure of the downstream affects like charging, re-ordering, etc. when non-facility items make it to the charge router.

Does anyone know why Lawson would be set up this way?   Thank You in advance.

 

We send from Lawson to Epic: Optime, Cupid and Radiant.  We ended up building a custom sql - so I'm not sure how your interface was built, but that's not Lawson.  Epic mirrors Lawson's Item Master (IC11) with Sup Records and the Item Location (IC12) with BAL records.  Even though Lawson sends the interface telling Epic which BAL an item goes to, this does not prevent someone in any given location from seeing all items available.

You'd have to work with Epic to create a filter to not show items in the location or a security etc.