We currently advise referrers to re-request rejected studies but this is the source of some frustration by some referrers. Reinstating them on Cris does not reactivate them on our requests system (ICM) so advising re-requesting ensures that ICM reflects the current situation.
Does anyone have two way messaging between their requesting system (we use ICM) and RIS (Cris), allowing more information flow than simply reject and re-request?
I suspect this is something that won’t be possible without significant upgrades
Just curious, wasn’t “bi-direction HL7 interfacing” a requirement in you tender for the RIS/ICM? This is usual in tenders I think? It means you have a path to require this from your supplier.
I’m asking if it is possible, not whether retrospectively our (very historical) tender was appropriately specced but I will make enquiries to clarify our position on this, thanks.
I would be interested to hear if anyone is successfully using Cris and ICM (both of which are not the most modern applications) with bi-direction HL7 interfacing.
Thanks Mark - I am not meaning to rattle the cage too much - but forgotten promises and “tenders in draws” are a bit of a plague in our Radiology world. I understand you want to focus on the ‘practical’.
Yes, I agree. Even if specced in the tender with (otherwise) well performing suppliers who have developed software using modern software development methodology, ensuring features are all working as imagined by the customer can be very difficult to enforce.
It’s easier to progress something if it’s known working at another site and I am always very impressed with the body of knowledge that we are lucky enough to benefit from on this forum, hence the post.
Hi Mark, we have CRIS and Careflow EPR with bi-direction HL7 interface and stumbled on the same workflow issue. A rejected event on CRIS is cancelled on Careflow and requires the clinician to place a new order from scratch. Although we’ve not gone “life” yet with the system, this is not going to be popular, not efficient or even mimic the paper workflow that we are replacing.
I wasn’t involved in the detail but I understand we have worked out a work around by putting the request on hold, contact the clinician for additional information, and continue the order once detail has been clarified. Would that work in your situation?
Hi Mark,
We use Cerner, not ICM, so sorry if this info isn’t helpful.
CRIS sends both a cancellation and a status message for each of the request cancellation types. What we’ve done is to separate the cancellations into two groups - reschedule and cancel. Then in the TIE, we’ve blocked the cancelation messages for the reschedules, so the EPR just reflects the status update message instead.
For example, if there’s staff sickness or equipment failure, this now appears as a status update alone and the same event in CRIS can be used to rebook for another date, meaning the original order in the EPR is preserved rather than needing a new request.
If the request turns out to be a duplicate, we mark it as such and the cancellation message reaches the EPR, cancelling the order. It would need to be re-requested if still needed for some reason.
This stopped the issue where rebooking an appointment would cause the original EPR order to be cancelled, which then stopped the EPR from handling the result properly (without the original order, the EPR has no idea where to send the result for endorsement).
That’s really useful. It seems like EPR isn’t a magic bullet for this issue so I will have to manage expectations. I get the impression that this functionality simply isn’t possible with Cris.
Has anyone better experience with other RIS providers?
Hi Mark. We have had to thrash out a lot of scenarios as we look towards ordercomms requesting. Our best idea was for the TIE to exclude certain codes that output from the vetting module. If we need further info from the requester, because on first glance it appears unjustified, we use vetting status ‘VH’ instead of cancelling. The TIE ignores this, and it still appears as ‘Order Received by Department’ in ordercomms.
If our question is answered satisfactorily , then we accept the order (vetting status VC). If not we reject it (vetting status VJU).
This way we should (hopefully) avoid the referrers frustrations of duplicated requests.