Passing Item Cost to Surgical Systems

We currently have an interface that send data over including pricing when an item is added as new, or updated. Based on that, not all items are updated, so we are having to determine a way to get pricing over when received, to ensure that Cerner/Surginet is updated timely for case reporting...

It's not Clinical Bridge - we're using a sql through cloverleaf - and it's based on PO25.6 pricing, not last PO cost. There's no link patient to PO unless it's a bill only implant.

Kat, how do you handle items on multiple contracts?

Benefits of being a taxing authority. We have one price for all locations. The only exception is Arthrex that charges more for bill only delivered - Epic gets the lower direct pricing per Corporate Finance. We do not charge the patient more for a facility choosing not to load a consignment.

So if you have a group of items on two different Arthrex contracts, how does the interface know which cost to pass to Epic? We've hit a roadblock with capitated pricing for total joints. We have hundreds implants on 2 different contracts for Depuy, Biomet and Smith & Nephew. On the capitated contract there is a cost for the implant "system" and the cost for the actual items are set at $0. The cost of the system is less than the aggregate cost of the implants used for the case. For revisions we have another contract with discounted pricing on each item. My SQL query currently does not pull pricing from the base cost in POVAGRMTLN but rather from last received cost in ITEMLOC. Most of our cases are total joint so the last cost will be $0 for most joint implants. I've thought about pulling cost from the contract but I don't know how to write the query so it would pull the cost from the correct contract for specific items.

For capitated - there's an item built for the system - it's listed as an implant so the nurse in the room charts all the pieces. The individuals are there as well for revisions.

How the nurses are trained when to pull the system vs list individuals is not something I was involved in, but per my counterpart in Epic, they aren't having too many issues.

I don't know how I'd get the $0 system pricing off of yours other than putting the lines on hold? You have the system on the same PO25.6 - yes? You'd almost have to put that on a separate one and then put the old one on hold from PO25.1.

Our solution is to keep the non-capitated cost in a user field for these specific items and pass that to the interface which will use that field when populated, otherwise use last received cost. This means we'll have to manually update that field when the contract is updated. I don't like adding a manual process to this but unless contracts decides to stop using cap codes we're stuck.