Hi, We have clinisys ICE and Wellbeing CRIS.
Currently, if a request is made in ICE that subsequently the referrer wishes to cancel, they are unable to do so within ICE and have to contact Radiology to cancel via CRIS.
I believe this was either a limitation of the functionality in ICE or lack of HL7 trigger to update CRIS.
Has anyone with clinisys ICE got a different workflow ? The ability to cancel or delete requests via ICE, which will subsequently update CRIS?
Thanks
Hi,
We use ICE and Soliton and our referrers are also unable to cancel requests in ICE, the referrer has to contact radiology to cancel the request in Soliton. I suspect this is setup nationally for all NHS trusts that use ICE for their OrderComms.
We have the ICE/Wellbeing setup too.
The ability to cancel requests on ICE depends on how far they’ve gone in the CRIS workflow (same for our EPR requests too). To prevent exams that are progressing through CRIS (even being performed) being cancelled without Radiology knowing.
Hi, you have described a very important problem.
I don’t really understand why we don’t have a digital workflow for it (that I know of).
Probably this workflow is missing from many (possibly all?) order-comms systems and not limited to Clinisys ICE.
Referrers should have the ability not only to cancel (at any point) but also to amand (prior to pre-defined state changes e.g. protocolled/justified) their requests, with appropriate authentication (so that not anyone can cancel/modify any request) and notification in RIS (so for example slots can be re-allocated). Two way communication against the request between the referees and the service provider (imaging/pathology) would be helpful.
I’d be very interested if there is an order-comms RIS (or pacs if it’s a RIS-less environment) that supports this workflow on the market or how this can be enabled.
—Marius Grima
(Pead Radiologist & DCIO @ UHNM, Digital Clinical Lead @ WMIN)
Hi,
We also use Clinisys ICE and Wellbeing CRIS.
We have found that ICE requests can be cancelled up to the point that the order changes status in CRIS i.e. if marked as received/accepted or put on waiting. Unhelpfully this “sucks back” the order from CRIS leaving no trail in CRIS at all. We have to check the audit trail on ICE to find out what happened if there is a query on it. Also ICE users can delete requests on ICE but that does not send a message through to CRIS.
Hi
We have Meditech EPR and Wellbeing CRIS, wellbeing have made a change to the interface between EPR- TIE- CRIS so that if a cancellation is made to the order in Meditech then this will cancel the CRIS request up to but not including Appointed status, we also have our TIE sending emails to a generic nhs mailbox when a cancellation is made in Meditech. Unfortunately requests still get through from the appointed status.
Hi
The argument about cancellation not being allowed once appointment has been made has historically been around responsibility of informing the patient of the cancellation and the risks about prep having been prescribed and taken before the patient turns up to to their cancelled appointment. Could be addressed, but needs a bit of thinking/dev.
We have an electronic workflow through our integrated EPR/ordercomms. It’s a different approach from those discussed above - using an integrated clinical messaging module.
The referrer or clinicial team can send a ‘Request Update’ or ‘Request Cancel’ message - linked to the original request. This is stored as part of the patient electronic record linked to the original request for IRMER purposes - and for anyone tracking the status of the request in the EPR.
This is creates a worklist for radiology - but does not automatically update or cancel the request in the RIS ( CRIS) for the reasons others have mentioned. The worklist tracks the messages as they are read and actioned.
It is part of the EPR integrated clinical messaging** and is bidirectional. It is also used by the department to contact the referrer about the request - eg to request clarification on vetting - or to confirm any update request. Again these are all recorded against the request for IRMER purposes and as part of the patient record.
Last time I checked we were receiving/sending over 800 clinical messages a year linked to radiology requests. The most common reasons were clinicians requesting a date change (e.g treatment deferred) and radiology requesting clarification or informing clinical teams of DNAs.
**The clinical messaging module covers more than radiology - it allows a message to be sent between any users/teams linked to either a patient or more granular - any patient event/result/note etc. Anyone with access to the patient record you can see if the messages have been read and actioned. Each clinical message is seen within the patient clinical notes/timeline - and is shown by each request/event it relates to.
In practice - a clinician would look at the patient radiology requests in the EPR - which shows the status they are at from CRIS (eg. received , waiting list, planned date, appointed with date etc.) The r clinician can then single click to open the message dialogue to send a message to radiology - automatically linked to the request.
Each team (and clinician) have a clinical message Inbox. We have one for ‘Radiology booking team’. Accessible by all in that team. This is the default recipient for all clinical request updates/cancel requests.
The same system can be used by clinicians to request clarification on radiology reports and receive replies etc. These are normally sent straight to the reporting radiologist - again pre-populated as the default recipient in these cases.
Thanks for that Rhydian. It appears to me this is a bit of a no-man’s land between 2 applications that serve a different set of clinicians. I started writing a fake specification for discussion but you’ve taken the wind out of the sails.
What is this magical Clinical Messaging Module you refer to?
I was thinking of 3 conditions a cancelled OC order might encounter:
- cancellation before appointment booking has taken place. The RIS should display the order as cancelled and not drop it.
- From appointed to attended status I would think it would require manual intervention by booking or an intelligent RIS manager.
- After attended you potentially have clinical IRMER incident and it needs another workflow to follow up.
Bear in mind these are the thoughts of someone who’s closest encounter with an OrderComms was its listing on a Christmas wish list and was never able to send results somewhere without the relaxing rattling sound of an printer.
We are currently in the early phase of implementing an EPR with Order Comms. Thanks for Mark Gardner to bring this up as I will take it to the implementation team.
Hi Frank
That’s right. The HL7 standards exist for ordercomms to both update and cancel ‘orders’. The challenge is what you would expect CRIS to do with that request, as you may have already sent out appointment information etc.
Even for cancelling a patient off a waiting list - you might want to record the reason, hospital cancel or patient cancel - that’s not part if the specification. Sometimes the referrer wants to cancel one part of an order - or reschedule. Neither are supported.
Updates to orders add more complexity I think that’s why you can’t change a request in HL7 2.3.1, the most widely implemented version. It would have to be a cancel and new order message.
It’s more flexible to have a clinical messaging system that supports communication between the clinician and department and vice versa - and that also meets IRMER requirements.
We have the same process for our inhouse OCS system requesters contact radiology by phone or email to cancel any order they create that is no longer needed
Probably archaic really in busy times
Rhidian sounds a good solution is the clinical messaging part of your COTS EPR or an inhouse developed piece of software that sits between CRIS & epr?
Hi Bonnie. I built it into the EPR - so it’s part of our in-house development. You can send a message linked to any ‘object’ in the EPR - eg a request/order, a result, a clinical note/letter/scanned doc, an appointment/event, a task etc.