The Regional Chairman for RCR in the North-East (Dr. McAndrew) is keen on setting up a regional approach for Out-of-Hours CT reporting. Similar ideas are being considered in other regions at well--I have heard talks about such approaches being considere in London & North West too. Hence, I have written a short paper which I have also circulated to a many colleagues for views & opinions.
I would be interested in your views on the technological aspects to deliver this.
"The TECHNOLOGY required to deliver regional out-of-hours CT reporting collaborative is now straightforward. a. Regional OUT-OF-HOUR MiniPACS with a temporary archive & a reporting module available to all radiologists working from home for the collaborative. b. DICOM push links from each of CT scanner to the regional OOH PACS c. Inbound HL7 reports from the Reporting Module of the MiniPACS into the each hospital’s RIS from which the images originated. d. The inbound reports should change the status on RIS to “authorised” and report MUST be available on the local PACS of the originating hospital. The technology required is fairly standard & any large or medium PACS vendor will be able to provide a regional collaborative an off-the-shelf package for this."
I would also like to hear where this kind of collaboration for Out-of-Hours CT Reporting is already happening & their experiences.
Merge offers a PACS system that is being used by many practices to provide off hours as well as complete teleradiology services. One of our customers in the UK 4Ways Healthcare. I would be happy to share our experiences in this area with anyone would like to contact me about PACS solutions for teleradiology in the UK
All of the functionality described above is available in the system. We have also worked with Burnbank on a number of occasions. For example, the zero client viewer that Burnbank offers is from Merge.
Thanks Jon for posting on our forum. It is important that there is more than 1 suppliers capable of delivering the teleradiology package as we need in the NHS. I am very keen on a plug & play type of teleradiology solution which is NOT dependent on a RIS supplier/LSP who is responsible for RIS deciding to be difficult or charging enormous sums of money --UNLESS we choose their preferred supplier.
After talking to some people around there are 2 issues that are raised 1. What about the requests? ND view-- a. if there are electronic requests--HL7 messaging from RIS. b. paper requests--after hearing Dave Harvey's talk I would be interested in using XDR with encapsulted pdf 2. What about priors? ND Comment--Most of the scans done out of hours are neuro-surgical emergencies, stroke or head injury etc. Priors are unusual (I talk from experiance of doing emergency on-call for 15years). Radiographers completing the exam on RIS would be aware of any relevant priors & should push them from PACS. Radiologists who see something that looks like could be long standing should be able to ring up the radiographers to task. This should NOT obstruct progress towards a teleradiology solution for out-of-hours.
I am really keen on exploring XDR-I as a means of sending images & requests to the teleradiology package and reports back into RIS as a plug & play standard.
Jon, as a vendor I would be keen to know your thoughts on adoption of XDR for this purpose.
Hi The extraction of request forms from RIS is reasonably straight forward with the right expertise. Method will vary from RIS to RIS...XDS, SOAP, Web services, direct db query. Likewise download of HL-7 ORU and ORM messages and retrieval of priors is reasonably straight forward.
The biggest barrier Ive noticed (past experience with off-site reporting company) is not the technology but the cost that the LSPs and RIS vendors levy for interfacing. It can be hard to justify 10K+ when perhaps one or two reports are downloaded in a night.
"The biggest barrier Ive noticed (past experience with off-site reporting company) is not the technology but the cost that the LSPs and RIS vendors levy for interfacing. It can be hard to justify 10K+ when perhaps one or two reports are downloaded in a night."
I agree. Jon & Ross as vendors, do you think XDR/XDR-I would standardise these transfers: 1. Images from Hospital to Teleradiology System 2. Request card from hospital to Teleradiology system 3. Report from Teleradiology System to Hospital I would be really keen to hear vendor prespective on how we can achieve this in a multivendor enviornment.
Many of you will be aware ITK in UK is looking at using XD* metadata similar to XDR.
I do this this could be made possible by PACS & the teleradiology system vendor adopting 2 main standards 1. XDR/XDR-I 2. Displayable Report Profile I have updated the technology parts of the document to incorporate the following. If existing PACS vendors do not support these profiles, I still think by use of simple plug-ins standards support is possible. I would appreciate comments from PACS vendors (big or small)-public or privately.
TECHNOLOGY & SERVICE LEVEL REQUIRED—The technology required to deliver regional out-of-hours CT reporting collaborative is now straightforward & any medium or large PACS vendor will be able to put together a teleradiology package. The regional collaborative would simply need to tender for such a system.
"REGIONAL TELERADIOLOGY SYSTEM will need to incorporate the following components: a. Temporary DICOM archive b. DICOM Display & manipulation tools for CT reporting c. Workflow to support radiology reporting—typing, dicattaion & VR integrated d. Ability to receive & display image studies, request documents, & report documents (relevant prior reports) in standard format & ability to display them for the reporting radiologist. Very stringent service level agreements are required to deliver a business continuity model of service. No planned or unplanned downtime can be tolerated. Ability to drive into the hospital is no longer an option for the regional teleradiologist. There should be no downtime tolerance with a business continuity model for services.
TECHNICAL WORKFLOW SUPPORT: 1. Trusts must be able to send 2-3 items to the on-call teleradiology system with ease a. Image Study which needs reporting—this could be sent from the PACS (PACS is the preferred as the system –rather than the CT scanner, for transmitting studies, as radiographers can add last relevant when sending the images). Standards adoption will be discussed in the next section. b. Request card/ordercomms request information—This needs to be transmitted alongwith images. c. Relevant prior studies—As these are generally neuro-surgical, trauma emergencies done between 7am to 7pm, this is largely the 1st scan patients will have had. However, if there is a prior study the radiographer must be able to send the prior study to the on-call radiologist. 2. Once a report has been generated in the on-call teleradiology System, the report must be sent to the Hospital PACS & displayed there, so that the requesting team to see this automatically when they launch the study on PACS.
GLOBAL IT STANDARDS For such a regional teleradiology model to work, PACS vendors will be working in a multivendor environment for PACS, RIS, Ordercomms etc. Hence adoption of common integration global standards which are plug & play are key here. PACS vendors are global companies, so they would be interested in global standards rather than any national standards. Below are the global standards which MUST be incorporated both in the Trust PACS & Teleradiology System. XDR, XDR-I & DPRT are the key IHE Profile standards which will deliver the workflow needed: A. TRUST PACS Standards-- 1. XDR-I source compliant Trust PACS will be able to transmit the study/studies (including relevant priors) to the regional teleradiology system. 2. XDR-I source compliant PACS will also be able to incorporate a scanned pdf request card or a pdfed ordercomms request with the image study to send to teleradiology system. 3. XDR recipient PACS must be able to receive the radiology report sent to it from the teleradiology system. The report MUST be automatically displayed. 4. PACS must support document display for reports in document format—Displayable Report Profile of IHE—requires reports to be created/stored/managed in CDA or encapsulated pdf format. 5. If the Trust PACS is NOT XDR-I complaint then a simple XDR-I plug-in package should be incorporated into the PACS will be send the studies & also incorporate the scanned request card/pdfed ordercomms request.
B. TELERADIOLOGY SYSTEM 1. The Teleradiology System MUST be an XDR-I recipient for receiving & displaying the image studies, request document. & relevant prior reports 2. The Teleradiology Sytems MUST be XDR source for reports created within the system to be sent across to the Hospital PACS 3. Teleradiology System MUST support DPRT Profile of IHE with the ability to display documents—previous reports sent to it via XDR & also requests –scanned pdf"
Going forwards & those Trusts engaged in procurement of VNA with PACS (I think most Trusts are already doing this), I think it is important to future proof our systems by ensuring the VNA has XDR/XDR-I capabilities.
VNA that has XD* capabilities will store both images (DICOM) & documents (CDA or encapsulated pdf). By XD* capable VNA it could act as XDR-I source for sending current & relevant prior images with relevant prior report & request card to the teleradiology system & also be able to recieve reports back from the teleradiology system.
Updated document. There has been a lot of interest from radiologists in Northern Ireland who wish to consider a regional model for out-of-hours CT reporting. I am optimistic that other regions will also want to adopt a regional service model for out-of-hours.
I have updated the document after much discussion at RCR. I have tried to separate out the technology from the business modelling & clinical drivers.
11 to 14 % higher mortality rates for weekend admissions is a driver for delivering a 7day acute radiology services. With current level of radiologists vacancies in the NHS, I do think an alternative model which has technology at the heart of it is required.
NHS moving to a collaborative tele-radiology model for night-time emergency CT reporting is a cost effective way forward for NHS as a whole.
I have also made some amendments to technology to pragmatically support simple DICOM & HL7 (XDR-I as being the future technology).
I would be grateful for comments both on-line & off-line.
I was looking at the evolution of your document, and was struck by its initial focus on pushing from the modality, and was wondering why you are not just doing a PACS-to-PACS DICOM push (given that there are a lot more modalities than PACS and all images will be in the source PACS anyway, especially if reported, and managing multiple push targets at the modality console is a pain, both in terms of configuration management and operator burden/error/information governance).
I.e., for the images anyway, something more like the IHE MIMA (Multiple Image Manager/Archive) profile might be in order (with the NHS number being the primary patient identifier at the target). This would also work for DICOM encapsulated PDF reports (or any other DICOM form of report).
As we discussed at the Spring meeting, CDA should probably be avoided (at least until HL7 has absorbed the impact of the Oracle v. Google decision and stopped attempting to charge for the privilege of implementing it). PDF is nice, but burdensome if the source is just using plain text and not PDF in the first place (likewise on the receiving end, though I guess many PACS (but not so many RIS) can displayed DICOM encapsulated PDF these days). There is always DICOM Basic Text SR (et al, in IHE SINR) to encapsulate the plain text, but that is not very fashionable either.
I hate to say it, but every PACS can display text rendered as secondary capture images, and this could serve as a lowest common denominator solution for communicating the report content in a pinch. Now that I come to think of it, one could include the plain text report (or even the SR content tree) in the "header" of a secondary capture image so it is recoverable as well as displayable; indeed, one could even stuff a PDF and a CDA in the secondary capture image header as well, and have everything a body needs in one object.
Not that I am suggesting that you exclude the RIS, but as mentioned by someone earlier, interfacing to it (and in particular, importing externally supplied reports and distinguishing them) may be non-trivial/expensive and perhaps not strictly necessary for the use-case, even though highly desirable. Worst-case there should be a workaround for when the RIS is not interfaced.
As for tele-radiology system modality image display capabilities, the IHE Basic Image Review profile was designed for this sort of thing, and enumerates what should be sufficient features for most emergency scenarios. If not, let me know what you think is missing in it.
PS. Your most recent draft seems to have dropped DICOM push entirely and is dependent on XDR-I, the ink on which is not yet even dry, which may be a little impractical, inconsistent with the IEP experience, etc. I think you should include both, so that you have a solution that works now, as well as one that can leverage future XD* WS*-based push and pull infrastructures.
1. "Image Study which needs reporting—this could be sent from the PACS or CT scanner (PACS is the preferred as the system –rather than the CT scanner, for transmitting studies, as radiographers can add last relevant when sending the images).".
A. INTER-OPERABILITY STANDARDS USING DICOM & HL7 STANDARDS Existing standards using DICOM could be used to communicate between Trust PACS & Teleradiology Solutions The documents like Request card & previous reports could be DICOMised to include in the “send package” from The report would be sent back to Trust RIS & PACS via HL7 messaging standard. This is the current technology in use in most teleradiology solutions in use today
In my view radiology reports & requests must support the same document standard as other clinical documents. DPRT profile recognises encap pdf & CDA as the doc standard. These reports & requests must be able to to be sent to non-DICOM systems--GP systems, Ordercomms etc so we cannot impose DICOM on other document based systems is my view XDR/XDR-I support.
DICOM works for images,--- but does not work for documents--therefore the interest in XD* mechanism for push & pull sharing for both doc & images.
Teleradiology as described requires push method of transport between 1. PACS 2. RIS 3. Scanned doc/Ordercomms 4. Teleradiology System for both DICOM images & medical/scanned documents. XDR-I incorpoartes both doc & images & is suited for teleradiology. With all due respect simply DICOM will not work.
Ah, your right, I didn't read your document carefully enough, and missed the separate current technology bit.
As for reports, perhaps I misunderstand your use-case, but I got the impression that some of the folks who responded were also looking for a "RIS-less" solution to this problem, and I was just discussing how reports might be made viewable in a receiving PACS; I didn't realize this stuff was going back to GPs and the like (do they have PACS access in your world?); I also hadn't considered that perhaps the report in this use-case is intended to be the final report, and not something preliminary.
I assume you are aware that IHE DRPT is a Cardiology, not Radiology, profile, and while there is certainly nothing wrong with it and no reason it can't be used for radiology purposes, as far as I am aware, the focus on implementation and testing at Connectathons has been largely confined to cardiology vendors (and cardiology systems from generic vendors). Are your suppliers excited about DRPT?
One other aspect of this is that you are not proposing the use of XDS and XDS-I, with the Document Source and Imaging Document Source being at the imaging site, and the reader being remote and accessing the images via XDS*. Is there a reason for that (push rather than pull)?
Or for that matter, why don't the remote reporting radiologists just read in your RIS/PACS using a remote web interface in the normal manner?
I am presumably missing some context to this discussion that makes the establishment of a separate "outside" system to which the information is replicated necessary.
The use case is like this The following needs to be sent FROM Trust RIS & PACS TO Teleradiology 1. current images--DICOM 2. relevant prior images--DICOM 3. relevant prior report 4. request--ordercomms/scanned paper request Final report needs to be sent FROM teleradiology to Trust RIS & PACS
Whilst this can easily be achieved using DICOM & HL7 as is being done by most private teleradiology solutions today, a better plug & play standards based solution is XDR-I.
Pull solutions like XDS-I or web & VPN will not work as we are talking about multiple hospitals with multiple PACS & RISes. The night-time teleradiologists (who maybe working for an out-sourced company) must have a single user interface despite getting work from multiple hospital PACS & RIS solutions.
Medica, 4WaysHealthcare, Nighthawk & other telaradiology companies are already effectively delivering teleradiology solutions using DICOM & HL7 to connect multiple RIS & PACS. However, a better plug & play standard is required in the future. It is upto PACS vendors & standards bodies to understand the real world & develop these standards.
Whether we use old & proven technology like DICOM & HL7 or PACS vendors see business opportunity to support XDR-1 & DPRT, I do not think technology is the issue here.
There issue here is a clinical one 1. 7 day working is being pushed politically through evidence of higher mortality on weekends-11 to 14% 2. Huge numbers of radiologists vacancies NHS (in DGHs particularly)--as per RCR census 3. NHS must look at technology to deliver a cost effective, high quality night-time CT reporting solution. This must be properly funded though.
I have had another email from a DICOM & IHE expert who works for a major PACS vendor who makes some very valuable comments & highlights the deficiencies in XDR-I to support a teleradiology workflow as desired by us.
these are Interesting ideas.
However I think to really be able to tender such systems and have them interoperate across vendors additional specifications (and perhaps also Standardization) would be necessary. XDS/XDR has no direct supports for workflows. It’s for sending to archives/repositories.
The XDR-I content profile contains only DICOM SOP Instances, PDF Imaging Report, Text (CDA Wrapped) Imaging Report.
There is no natural place for the (scanned) order or other relevant information.
So additionally XDR will have to be used. Perhaps with the XDS-SD content profile.
There seems then to be the assumption that this data will be correlated and used to create one worklist entry for the teleradiologist. I guess this needs to be stated more explicitly since this is currently out of the scope of IHE.
Usually the report management is done in the RIS. But there is no standardized workflow for a RIS system to integrate an externally created report into the report workflow. (Proprietary solutions exists. But I do not think there are many RIS systems which allow that.)
Also, how is the reporting status updated/communicated?
Additionally the DRPT profile which you mentioned in your paper works on DICOM encapsulated PDF/CDA whereas with the XDR-I profile the ideas is to send the report directly as PDF and CDA files. So if the receiver is the PACS it would have to do some encapsulation unless the sending teleradiology reporting system is required to already do the encapsulation.
But the latter variant would render the PDF and CDA MIME types in XDR-I useless.
Guess the current standards leave quite some things to be specified in order to get a teleradiological workflow really going."
However, whilst we might not have a plug & play interoperabile workflow for teleradiology as desired, we know the existing methodlogy with use of "integration boxes" to support DICOM & HL7 standards to support a teleradiology workflow exists & works well--many private providers already use this.
By the way Neelam, what about access to previous images, previous reports and the rest of the patient history, lab results, etc., necessary to provide a new report of equal quality to what might be done locally rather than by teleradiology? You mention previous reports in your draft, but not the images.
This may be hard to replicate with a push rather than a pull model, if the teleradiologist does not have a complete replica of everything about the patient (which may be impractical in the absence of a regionally accessible PACS and EHR).
Are you going to push all "relevant" previous images, for example, and who (or what system) at the source is going to decide what is relevant?
We all know that a report made without review of previous images may be misleading or unhelpful, if not completely wrong (esp. with an inadequate/incomplete request, and even in the presence of previous reports, which may be incorrect, particularly in light of new images), and that a report enhanced by correlating intelligently with more clinical information than provided in the request can be made better still.
Also, I think you may be selling the "pull" concept short, as well as underestimating the ability of remote radiologists to adapt to different (proprietary web-based) user interfaces for the different hospitals they serve. Locums cope with this all the time.
That said, standardized communications interfaces for the pull model (XDS and XDS-I, or DICOM) do not define the user experience, only the access mechanism, so the teleradiologist using this form of "pull" (rather than a proprietary user interface) could use the tool of their choice locally to access what they needed, regardless of its source; returning the report could then be via XDR, XDR-I (or XDS, if the teleradiology facility was also a Document Source).
As for workflow management (reading worklists, etc.), this has not been successfully standardized inside the enterprise, much less between them. The IHE ITI Cross-Enterprise Document Workflow (XDW) is an interesting possibility, but it remains to be seen how it works in practice.
If I were building this, I might consider a combination of pushing the current study and request (which creates a de facto reading worklist), with pull access to previous information as the teleradiologist required (previous images, reports and EHR), possibly with automated pre-fetch rules for common patterns. Choices would depend a lot on on-demand transfer time. Then push the report back.
Anyway, I don't think you are going to achieve success just by enumerating a hodge-podge of profiles or standards; this really merits an entire profile (or "meta-profile") in its own right that specifies all the interoperability details, if you are going to mix and match "meta-actors" on different sides of the interoperability boundary (between the hospital and the teleradiology provider) each of which has a different (set of) vendor solutions for the various components. You need to specify transactions, sequencing, payloads, triggers and expected actions for the complete solution for all the variations on the use-case, or it is not going to work as effectively as a monolithic proprietary solution.
David, Thanks for your input. It seems that IHE, DICOM & PACS are unable to support a "document" standard for radiology reports. I think this is essential.
Private companies--Medica, 4wayshealthcare, Nighthawk etc are successfully delivering the workflow required by us the user community. So we will stick with HL7 messaging for the technology--until NHS adopts a document standard like CDA for all medical documentation--discahrge summaries, clinical letters etc.
I just wanted to tell you of the work we're doing for the AGWS Stroke Network that covers a rota of 15 consultants and 8 Trusts across Avon, Gloucestershire, Worcestershire and Somerset.
What happened in the past was that a consultant was called by the radiographer at 2am for example, had to fire up their Trust machine and, depending on where the exam originated from, the consultant had to dial in with VPN (having to remember the correct login details of the various systems they were going through) and this typically resulted in a 15-20 minute turnaround time. That's assuming they were able to get in at all (VPN dial-in failed at most Trusts).
We asked each Trust to install our Gateway software on a Windows machine they had available, and then to set up a rule on PACS to automatically forward a copy of stroke datasets when they arrive on PACS to the Gateway. The Gateway identifies itself as a new application entity on scanners and PACS and they used DICOM tags like "CT" + "head" to create the rule. It took most of the Trusts less than a day to set-up. In the 3Dnet system it took us 5 minutes to set the 15 consultants up with accounts.
What happens now is that as soon as a stroke patient is scanned, a copy of the DICOM data is automatically sent to the Gateway and routed to the cloud. The on-call consultant gets a phone call from the hospital as before and logs in at 3DnetMedical.com. They go through the exam and provide a decision over the phone.
It really has been that simple and now takes 3-5 minutes to visit a website, login once, review the exam pertinent to the consultant and for them to make a decision whether to thombolyse or not. They need a home internet connection and that's it.
There hasn't been a requirement for RIS interfacing for AGWS nor the stroke services we support around London, and I suspect this would be the same for most NHS Trusts. The radiographer calls them in the first place and waits on the line for the decision, so it's not like the consultant needs a notification to say there's a case waiting, or an order form to be sent with the exams, nor a report sent back to RIS. And, maybe I'm just far too removed from the clinical side, but there has never been a reason for the consultant to pull a study either.
TL;DR Push/pull models are inefficient in terms of bandwidth and time and also introduce an IG problem since they are sending patient data outside the hospital with no way of controlling it any more. The high speed DSL line and special Trust PC, plus all the software installed on it was just a waste of money in the end. Pushing it to a data centre/using a cloud model get's rid of these problems, makes exams available faster at a lower infrastructural cost.
This is a great example both of use of technology & standards.
To put this simplistically. 1. 15 stroke consultants in 8 Trusts on a rota. 2. Their requirement is simply to "review images" (They need to exclude a bleed before thrombolysis.) 3. With intelligent rules set in each hospital the PACS from each hospital automatically sends stroke scans to a central secure MiniPACS (call it a datacentre or cloud). All consultants on that network need to have log-in access to the central PACS. Rules can incorporate relevant priors too.
What system is required here-- A Central PACS
What standard is used here--DICOM
What set up is required here--log-in access for all consultant, writing up automatic rules for particular type of exam & DICOM push from each hospital PACS.
There is no requirement to review report, or write a report.
LESSON LEARNT--As long you tread in the DICOM & image world it is all fine. As soon as you start treading out in the world of clinical documents--like radiology report, whether creation or transport you are in big trouble.
Now my next comment will upset many vendors & DICOM experts, but I will say it anyway. To some extent I blame PACS & DICOM experts for this. They have not tried to adopt a standards based documents storage, transport & display for radiology requests & reports ---with all due respect these are documents not images.
When we had films, request cards, films & reports always stayed together. If we sent films copies to another hospital we always sent a report too. DICOM & PACS has severed a very important clinical relationship between reports & images. This is dis-service to patient care. DICOM may try to pin the blame on RIS vendors for not supporting DICOM SR. However, radiology reports are similar to other clinical documents--clinic letters, discharge summaries etc. The standards which will apply should be similar. CDA seems to be the most suitable standard format for clinical documents--Canada is also looking at it as the document standard. Radiology reports also need to be transported to GP systems, Results reporting systems, ordercomms ---all these are NON-DICOM systems.
Going forwards, I think this is what we need: 1. NHS to adopt a clinical document standard--whether CDA or other, which is global & future proof 2. PACS vendors to display the radiology reports & requests in the global standard agreed by NHS 3. RIS, GP systems etc also support the document standard 4. NHS agree a global vendor neutral transport for clinical documents--XDR or other--this will allow easy transport of clinical documents between Trusts & also between primary & secondary care. (DICOM & IEP works well for images)