The Royal College of Radiologists will shortly be publishing updated guidance on PACS and Electronic Records on the college website. This will incorporate the current published PACS & Teleradiology Group Guidance Documents developed by this group.
The college is also intending to update its guidance on Radiology Information Systems, and it has been agreed that this can be posted here for comment before submission for publication on the college website. Please can you feedback any comments to me on the document below before the end of the month if possible. Thank you.
posted on Tuesday, November 13, 2007 - 05:03 pm
An excellent document that will be a good basis for discussion but could I sound a note of caution to anyone who might be inclined to use it as a template for a Functional Specification. All "shoulds" will need to be changed to MUST in a Functional spec as vendors have a nasty habit of not providing the "shoulds"!
Thanks Ivan, that is an important point and I'll add a line to that effect. The draft guidance is much more detailed than the previous version in the college publication 'PACS & Electronic Records', but it is not intended to be draft contractual specification. The aim is to help guide those specifying and developing RIS as to the range of functionality, integration and coding support that is now expected.
I've tried to steer clear of absolutes as guidance is generally not absolute, and should be subject to local intepretation and assessment of the relative benefits and risks. I've also included the comment that "in an integrated solution, it is acceptable for other systems to provide this functionality providing the overall operational workflow and business analysis requirements are satisfied by the integrated solution". On that basis it is not absolute that the RIS must provide the functionality.
Neverthelss, as you say, if these are translated to contractual clauses then there should be no ambiguity. For contractual purposes I would also recommend Trusts define the terms MUST and SHOULD clearly, e.g. as described in RFC 2119.
• MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
• MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.
• SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
• SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behaviour is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behaviour described with this label.
A very informative document. Do you think that the lack of feedback in this thread is in part due to the fact that this document describes functionality those of us within the national programme can only dream of?
posted on Monday, November 19, 2007 - 04:13 pm
One hopes not given all Rhidian's hard work. Oddly it is very much the Functional and Tech Spec that Southampton wrote just prior to the NPfIT bar coming down.
Hopefully we can use this document to indicate where we should be aiming. I would agree that LSP reluctance or should that be "contractual intransigence" is a problem but let's not give up all hope.
Thanks Ivan. It is one of the drivers we can use to help steer and prioritise onging development of RIS within and outside the programme. I'm afraid I'm not well enough informed to comment on the position in London, although there is increasing recognition within the programme for the importance of RIS, and the limitations of this being an additional service in some areas of the country.
posted on Wednesday, November 21, 2007 - 12:35 pm
Rhidian, We have a very functionally rich RIS, and much cheaper than the LSP product. I do not agree with RIS being made core and therefore removing the good suppliers from the marketplace.
CFH should have come up with standards, for RIS/PACS suppliers to work towards, rather giving giving the contract to a single supllier. PACS as a core product has come at a huge cost to the public.
Thanks Neelam, but I'm not sure how I can include that in the college guidelines??
CFH RIS is an additional service, and was not part of the core delivery. Some Trusts took it, others opted not to and have integrated a non LSP RIS. It's not all black and white; some Trusts have shown significant benefits with the LSP provided RIS compared to their previous existing systems.
I left out the functionality that RIS should be able to show all radiology appointments and reports across a geographic healthcare community, although there would be a good argument for including this. Tony Corkett and others have spoken strongly in favour of the LSP shared instance RIS at previous group meetings. I have to agree that working in a tertiary referral centre we have found it a real bonus to be able to see the imaging history across the SHA. It has surprised me how often we weren't aware that the patient had had relevant imaging elsewhere!
posted on Wednesday, November 21, 2007 - 04:04 pm
CfH have used standards. In our cluster they've used the AGFA standard - i.e. this is how AGFA PACS works so change your RIS (and working practice) to suit the standard...
posted on Wednesday, November 21, 2007 - 09:06 pm
"CFH RIS" does not exisit as an entity. Nor is there an CFH PACS. These are LSP supplied products.
Our Non-LSP RIS already has the vast majority of the functionality described in your document. We are in discussion with our supplier about making our RIS, CFH smart-card compliant too. There is no reason for CFH smartcard compliance to be limited to LSP products (unless there is a vested interests to line the pockets of a single supplier by CFH).
"I have to agree that working in a tertiary referral centre we have found it a real bonus to be able to see the imaging history across the SHA." As a patient being seen at my local DGH, I would not wish for my entire imaging history to be available to the tertiary referal centre or the entire SHA/Cluster/nationally (unless I am being refered to the tertiary centre/to another hospital). Similarly, when I visit my GP, I do not wish for my GP notes to be available to other GP surgeries/in the region or nationally. Data sharing should be based on legitimate relationships through the spine(where my imaging history should lie as a patient) NOT through RIS where there is no access control. Data sharing should be possible but in a controlled way. As Clinicians let us not forget that we have an overriding responsibility to protect patient confidentiality.
posted on Thursday, November 29, 2007 - 04:20 pm
Rhidian, there are two issues which the Draft Guidelines on RIS do not seem to mention:-
Firstly, it should be possible to deauthorise a report and reauthorise it with modificaion when an error is realised (often the second after it is verbally authorised on a VR driven system). Also useful when further information arises (often at MDM).
Secondly, as soon as one radiologist starts a reporting episode (whether on worklist or not) all other radiologists should be locked out of that reporting episode.
If further information becomes evident at an MDT mtg or a change needs to be made to correct an error post verification, we use the addendum facility so as to maintain an audit trail along with the original report. No claim can then be made that information could have been added or removed from the report after treatment of a patient may have started without it being clear that a change has been made. Removing/changing a report without clear notification that a change has been made (ie. utilising the addendum facility) is dangerous IMHO .
I have to agree with Victoria that changing a report by anything other than an addendum is dangerous, because you can't guarantee the original report hasn't already got out into circulation.
I recall asking for changes in CRIS many years ago (for those that use CRIS) to provide the right click and unverify option when batch verifying reports, to solve the "premature authorisation syndrome" William describes. It works well, but I had assumed that the batch wasn't actually verified until you hit OK on the final screen (the one with the cartoon of the doc with feet on desk). Not so; the report goes out electronically very quickly, so the verify, unverify, reverify trick works OK if you are quick, but any delay and it generates two reports on the PACS system, original and altered. It would be nice if HSS could fix this. I think they may have put a short time delay in as a simple workaround.
We use TcRad (McKesson) and this has the extremely useful facility of being able to deauthorise a report at any time (audit trail in background of course) and change it when new information comes to light (use this all the time with breast screening assessment patients as and when new histology results/ MDM opinions arise so radiology record of radiologys patient is always current). The one essential proviso is that phrase "REAUTHORISED REPORT" heads subsequent reports. This has worked extremely well and commend it because clinician gets to most recent radiology report immediately without having to wade through outdated old report to get to "addendum".
I agree with Graham, Radiologists should have the capability to de-authorise and correct their incorrect reports as long as 1. PACS gets updated and the new report clearly states that there is a reauthorised report 2. If printed copies are sent, a new copy is generated 3. Other feeds : like GP systems/results reporting are also updated 4. There is an easy audit trail which documents when, and by whom the changes were made.
Supplementary/Addendums should also be allowed 1. to record discussions at the MDT 2. to record second opinions 3. RIS should allow supplemntary/addendum reports should be provided by a radiologist which may be different to the original reporter (ideally there should be a mechanism of informing the original reporter that a supplementary has been issued for their original report) 4. Workflow for provision of supplementary reports should be straightforward--find the exam on RIS--click on "add supplementary" which should like a new reporter to dictate a supplementary report. Ease of workflow will allow discussions in MDT/second opinions to be recorded within the patient history which can be vital for patient management.