Difference between revisions of "Reporting Whitepaper - Section 6.3"

From IHE Wiki
Jump to navigation Jump to search
Line 1: Line 1:
 +
[[Reporting Whitepaper| <Return to the main Reporting Whitepaper page>]]
 +
__TOC__
 +
 
==6.3 Reading Service==
 
==6.3 Reading Service==
  

Revision as of 20:39, 8 May 2007

<Return to the main Reporting Whitepaper page>

6.3 Reading Service

<Define what we mean – i.e. an “outsourced”/3rd party reading service which is neither part of a hospital imaging department, nor part of an imaging center.>


<Need Author/Input>

<Chris will see if we can get input from Dr. Keith Dryer – Mass General, Dr. David Mendelsson – Institution perspective on Reading Services>

6.3.1 Service Provider Viewpoint

Jeff Davies, VP of Sales for Franklin & Seidelmann Subspecialty Radiology (F&S), a national subspecialty teleradiology interpretation provider in the U.S. (http://www.franklin-seidelmann.com/) took the time to document a relatively generic teleradiology reporting workflow. He is available for further discussion if needed:

<Issues when bringing in a new “client” each time>

<Issues of managing all the separate clients in one workflow>

<Different reading services may vary significantly in their workflows / architectures>

<Some will have a “distributed workforce” who may even be working out of their homes, others will look like an imaging center with no modalities>

<Technologies include integrated “normal” systems, and also “web-based” clients which in some cases may have reduced resolution/fidelity>

<Another issue is that they are often used to cover “night hours” so the workflow at the client institution needs to shift seamlessly from internal reading to external reading and back again, In theory, clients will over-read a percentage of the service reads as a quality control measure>

<Hard to imagine this involving film, which also means that often priors are not included in the read. Sometimes the client will supply priors as part of the study.>

To scale effectively and therefore to make money, any telerad business must have the radiologists sign into 1 system (the telerad’s “RIS,” whatever that means) vs. logging into the client’s systems. This inherently and automatically creates workflow issues. I will discuss the telerad component/telerad workloop but obviously there is a lot of work that goes into the pre and post telerad workloop for an imaging entity (imaging center, hospital, orthopedic practice, etc.) that is using the telerad service.

Imaging Facility tech scans patient and sends the study to their internal “PACS” and simultaneously via a VPN tunnel, to “Trad” (fictitious name of telerad vendor). Imaging Facility tech, or someone else at the imaging facility (IF) front desk, fills out Trad “order form” and faxes that over to Trad.

Trad receives the “order” and manually enters that “order” into Trad RIS. In our case, the order is sent to Trad routing cops known as Air Traffic Control. ATC is also the department that receives study images from IF and deposits them into the Trad PACS (ultimately this could and should be automated but today is too tricky so needs to be done manually).

ATC matches the study images to the order and then assigns and forwards that study to the right radiologists who has the respective subspecialty and who is licensed in that state.

<Routing considers worker Load balancing, client quality-of-service/turnaround time agreements, state licensing, and specialty knowledge/certification requirements>

Trad Radiologist receives the study in their RIS worklist and pulls up the matching images in the viewer (in this case eFilm).

Tradiologist picks up Dictation System and dictates the name, DOB, SSN and order and begins dictating the study.

Transcription listens to the dictation in the dictation systems and sorts through the Trad RIS worklist to find the respective study and then transcribes/types back into Trad RIS.

Once transcription is complete the study is routed back to the Tradiologists who electronically “signs” the report in Trad RIS triggering autofax or, in our case, the posting of that final report to a website from which IF can pull the reports. Signing the report also triggers an e-mail providing indication to the IF that the report is ready.

Notes: After the report is sent back to IF either by fax or FTP (perhaps text, Word or a PDF), IF must then find a way to get that report back into their internal RIS (assuming that is their requirement). This could potentially occur via HL 7 but see below.

<Workflow needs to differentiate between the service read as a preliminary report and then the client does their “normal” process to finalize the report. This fits well with the service as an “emergency” method of doing wet-reads>

<Issues also arise in terms of client preferred formats or templates.>

<Might be interesting to look at communicating site policies as well>

This workflow scenario is quite different from another Trad vendor who may be only providing preliminary results for after hours coverage or from another Trad which does not subspecialize eliminating the necessity for ATC routing decisions. In the preliminary read example, only a wet read is faxed over to IF and then the radiologist who covers the facility over reads and provides the final radiology report the next day. (In our view of the world, we categorize ourselves as a subspecialty radiology group that uses tele to deliver our product vs. a teleradiology company who provides commodity coverage.)

The advantage is a report/service that IF isn’t able to get otherwise.

The disadvantage is the “broken” workflow. As Trad is an “outside” entity from the IF and has many clients the workflow by nature can not be as “integrated” as in-house workflow can be. As soon as one IF client workflow is different from another IF client, it requires that Trad workflow be ubiquitous and therefore perhaps “dumbed down.” HL 7 Interfaces can and do exist but are complex and costly.

If automated inter company workflow via HL 7 were to occur, Trad would need a very robust and sophisticated HL 7 engine that accounts for 165 unique interfaces. Furthermore, if you start talking about DICOM Modality Worklist and other sophisticated workflow integrations, things even get more complex.