| Message/Author |
|
|
|
|
I've uploaded the first draft SIG guidelines on electronic remote requesting (ordercomms). These cover
- Integration of Electronic Remote Requesting with Radiology Information Systems
- Planning and Implementing Electronic Remote Requesting Systems
- Remote Electronic Requesting and IR(ME)R
Again these are draft guidelines for public comment. I would appreciate any comments and advice from those of you that have you that have successfully implemented these systems.
|
|
|
 Eric Loveday
posted on Thursday, December 08, 2005 - 08:27 am
|
 
|
|
| In radiology ordercomms you need robust patient identifications systems. Many years of ordercomms have brought us undoubted benefits but we have had numerous incidents of the wrong patient being referred. The department, following all the correct identification procedures, unwittingly irradiates the "correct" patient as identified on the referral. This can even lead to diagnoses of cancer being given to the wrong patient. This is something to do with the GUI interface - a clinician may be distracted and assume Mr Jones' record is on the screen, but end up referring Mr Smith. When handwriting a form he is less likely to write "Smith" instead of "Jones". We have campaigned for years for a mugshot of the patient to be on screen at the point of referral but this was declined on grounds of complexity, privacy and cost. I would like to see something in the guidelines about this. Minor semantic issue: a "request" is the opposite of an "order" but has something of the supplicant about it. I recall College advice some yrs ago that classed a radiology request as a referral for a clinical opinion. The use of the term "referral" places the referrer and radiologist on an equal footing and sounds much more grown up. |
|
|
|
|
Thanks Eric, you make a very good point around patient identification. In the past we've had the same problem with the patient ID sticky labels that are stuck on request cards. We've not found an answer to this conundrum except to keep reminding clinicians and make sure any error gets followed up with the referring clinician.
I like the idea of a mugshot on the referral screen and I'll look into what the LSP reference solutions are planning in this respect. Does anyone know if current versions of Lorenzo, IDX or Cerner etc. include mugshots?
The other way ordercomms can help this issue is by prepopulating the coded patient diagnoses along with the request details the clinician adds at the time of referral. The clinician or radiology practitioner may then pick up that these don't tally.
Regarding the order/request/referral semantics, I felt obliged to mention this for the reason you mention. Order is an interesting term as it has a number of meanings, one being a request for a service, so they are no strictly opposites. The reason I said it was acceptable to use it in this way is because I think it is a distraction, and if you take the stance that we shouldn’t use the word then it makes the subsequent discussion on IHE much more difficult! |
|
|
| Richard Mann
posted on Thursday, December 08, 2005 - 10:07 am
|
|
|
I also used to be keen on the mugshot idea, and I think I remember seeing a lorenzo demo a few years back which included this. In iSoft-land "current version" probably means iP1R2 - and I'm fairly sure this doesn't include a mugshot. Given their difficulties in providing a PAS with an integrated A&E dept, this is hardly suprising....
As a practical matter, though - how do we get the mugshot in the first place? Trusts all have to have Registration Authority kit (including web-cam) in order to produce the NPfIT smartcards. Our experience to date with these has been pretty painful, and we've only produced a couple of hundred cards. If a similar process had to be set up to get an image for each referred patient we wouldn't cope. Do GP systems routinely keep mugshots? |
|
|
|
|
I know it is only semantics but our clinicians fill in a RADIOLOGY CONSULTATION REQUEST FORM on ordercomms.
Practical issue:system needs a mechanism to cancel a request and record reason why that radiology can input and communicate to clinician |
|
|
| John Pilling
posted on Thursday, December 08, 2005 - 01:07 pm
|
|
|
It may be of interest, although slightly peripheral to this thread, that the Norfolk & Norwich have pulled out of implementing P1R1 of the iSoft PAS offering because of a number of problems which have arisen over the last 2 years during which the project has run. There has been little progress and the snags were outnumbering the advantages in the end.
Has anyone successfully implemented the iSoft PAS yet? |
|
|
| Richard Mann
posted on Thursday, December 08, 2005 - 02:04 pm
|
|
|
I think a few Mental Health Trusts may have been able to implement it - their requirements being fairly minimal. I don't think an acute trust has gone live with it yet.
The deadline for a "Choose and Book - compliant" PAS is starting to loom, though. If P1R2 is not ready in time trusts will be under pressure to consider a backward step in PAS/A&E functionality just to meet the C&B target.
Don't remember that being part of the vision. |
|
|
| Ivan Brown
posted on Thursday, December 08, 2005 - 03:23 pm
|
|
|
| What about Verichip then? But Keith Foord has previously asked "is it MRI compatible"? |
|
|
| Neelam Dugar
posted on Thursday, December 08, 2005 - 10:03 pm
|
|
|
Rhidian
"IHE order communications transactions can be specified as follows: “The electronic remote requesting system and radiology scheduling system shall support the IHE scheduled workflow profile fulfilling the roles of the Order Placer and Order Filler actors, and including the Appointment Notification option.”"
For making integration between systems happen, IHE is very important, but is the LSP PAS IHE compliant for SWF/PIR profile as ADT actor? Is LSP RIS IHE complaint as DSS actor for SWF/PIR profiles? If the NPFIT had insisted on IHE as minimum standards for use in the NHS, maybe there would have been more systems being implemented than there are available today. However, I suppose we have to start somewhere and why not at the ordercomm level. |
|
|
|
|
Neelam, IHE it is in the OBS and contracts as a strategic goal.
114.40.2 The service shall support the Integrated Health Environment (IHE) standards being set at international, continental and national levels.
This was intended to be 115.1.1 due to its importance and apparently it was in an early draft but numbers somehow got transposed and it slipped back a page! The important thing is it is in there. The guidance prompts you to ask the questions - not that you need it. For example your LSP tells you their planned interface and you can ask when do you plan to introduce appointment notification? Sometimes these things only get put on the roadmap by lead clinicians asking the question so it is worth promoting the IHE goals.
Similarly it is worth concentrating on the functional aspects as well. Padhraic's comment above illustrates a point "Practical issue: system needs a mechanism to cancel a request and record reason why that radiology can input and communicate to clinician". IHE doesn't currently require putting a reason for cancellation in the cancellation message but I agree it is helpful, and we would want to push the LSPs to implement this and IHE-UK to include this in the specification. |
|
|
|
|
| The requirement to report Diagnostic Wait Times from 1 January this year means that - among other things - we do need a Reason for Cancellation field in the RIS. This indicates whether a study was cancelled by the patient (DNA or active cancellation) or whether the hospital cancelled (equipment failure, or whatever). If patient cancels, the stopwatch gets re-set, if hospital cancels, the clock keeps ticking. |
|
|
|
|
P.S I was away for a month after Rhidian posted the guidelines, and I have only just read them. I think it is a good, clear document. My main comment is on your point: "...the receiving system where the request is justified and booked is called an ‘Order Filler and Department System Scheduler’. In radiology the receiving system is typically a RIS, but it could be part of a larger enterprise wide appointment scheduling system."
Choose and Book is knocking on the PAS door now, but is also supposed to come to Radiology 'ere long. This pre-supposes a scheduling system which includes Radiology, but sits outside the RIS (either replacing the RIS scheduler or by duplication). So I am just underlining the point I believe you are making, that the Order Filler and the Department System Scheduler could be interfaced with one another rather than both being within the RIS. Or they could be two separate modules of the same system - as indeed the Order Placer would be.
By the way, on Eric's point (above) of a couple of months ago, we've been using electronic ordering for nearly 6 years and whilst we do get referrals (orders, requests) on the wrong patient, it is quite rare, fortunately. Requests for, say, the left knee when they mean the right, or using the wrong visit episode, are common though. Whilst doctors and clinic staff here CAN work off an electronic list of patients booked to their clinic; they usually request by barcoding in the patient number off a printed list of all the patient names for that clinic, which has the hospital number barcoded next to the patient's name. Maybe that has helped. But I think the Wards usually work off the electronic list of patients on that Ward. |
|
|
|
|
Thanks Margaret. The order filler and department system scheduler OF/DSS are fulfilled by the same actor in IHE, i.e. they are one and the same.
The point I make in the document, which I think is what you are supporting, is that this does not have to be a RIS, but could part of a wider clinical information scheduling system covering not just radiology. It could also be a radiology scheduling module within the EPR, but then it is still essentially a RIS.
What I do not mention in the document though is that if it is part of a wider appointment scheduling system, it should also perform the other scheduled workflow roles of an OF/DSS actor, including providing modality worklists, procedure scheduling transactions to PACS to enable prefetch etc. |
|
|
| Pete Marsh
posted on Monday, April 16, 2007 - 05:23 pm
|
|
|
A bit late, but I am in process of formulating a question and saw the document for comment.
I appreciate it aimed at trying to become a generic standard for order comms and appreciate the statement order comms for radiology are often part of a wider process of order comms for other departments.
Our experience in Wirral with Order comms over last 15 years has shown that tailoring in certain area's has many benefits;
1. Showing recent order activity on way into order pathway greatly reduces duplicate or unnecessary requesting.
2. Embedding Royal college of radiology and other guidelines into order pathways delivers best practice and most cost effective solutions. This is based on proactive decision support, not reactive so guides the order requestor down the pathway to most appropriate investigation.
3. Priority setting - routine, asap, urgent become overused, in fact routine is hardly ever used. Systems that collect relevant clinical indicators within the context and assign priority and consequential workflow are ways of delivering more with less or same resource.
4. The scheduling system must be enterprise wide including radiology, theatre, OPD, etc. Anything else will not allow NHS organisations to deliver a clear patient pathway and will allow smart linkages to events such as do not make next OPD appointment until MRI scan report ready, or don't give cytotoxics until blood results are ready and appropriate results, etc. |
|
|
|
|
We are in the process of implementing Order Comms at Bromley and are consulting widely with the future users. One issue which has been raised from more than one quarter is that of the provision of an annotatable diagram as part of the clinical details in a radiology order. With traditional paper requests this is obviously straightforward and current practice, either a scribbled outline to indicate the site of a possible foreign body, area of pain etc or, in the case of our breast clinics, a stamped proforma which can be annotated with the lesion or surgery site.
There is a clear demand for an equivalent facility in the order comms implementation, however HL7 (2.4) does not provide for this as it assumes a purely textual message between participating systems (PAS and RIS or whatever). My questions to the forum are: what is currently in use in other trusts with established Order Comms implementations? i.e workarounds, bespoke image transfer solutions etc, and in sites that are also contemplating order comms what is the feeling on the importance of this issue?
I suspect that with many order comms systems in current usage based on character mode PAS that there is no facility for an electronically transferable annotatable image - jpeg or whatever - is this a risk? Encouraging buy-in to order comms in the wider trust environment is not easy, probably on a par with voice recognition, but this facility may add to the user appeal if it was available. |
|
|
| |
|
Draft PACS SIG guidelines on Electronic Remote Requesting v1.0