OsiriX in the Enterprise:

Transcription

1 Page 1 OsiriX in the Enterprise: How Blackbird integrated the premier Open Source DICOM viewer into the distributed radiology practice. By Darryl Garth Vine, M.D.

2 Page 2 Contents Page 3 Executive Summary Page 4 The Ideal Workflow Page 6 Principles Page 7 Page 9 Page 10 Blackbird s OsiriX Integration Conclusion Addendum

3 Page 3 Executive Summary It would be hard to convince the radiologist who has used OsiriX that there is a better DICOM viewer. The fact that this wonderful tool is released under an open source license and is well maintained should make the decision to utilize OsiriX, and therefore the Apple platform, a formality. However, while this may be the case for smaller practices, there are some remaining issues that needed to be addressed to utilise OsiriX, to it s full potential, in the larger distributed radiology practice. Blackbird, the radiology solution from IntelMS (Pty) Ltd, has addressed many of these issues, and has developed a comprehensive solution that complements and extends OsiriX. The Blackbird solution comprises a RIS, archive, DICOM routers, an image and report distribution system, comprehensive support and maintenance and facilitates teleradiology. This document initially takes the reader through an ideal distributed practice workflow and then explains what we have designed to complement OsiriX.

4 Page 4 The ideal workflow in a large radiology practice (Enterprise) The patient is scheduled and subsequently arrives in the radiology reception (a sophisticated electronic scheduler should be an integral part of the RIS). Patient demographics were either sent electronically (from the ordering physician or the HIS) or are captured at the time of arrival. Any documents (typically requisition forms) are scanned into the system (without slowing down the reception staff i.e. no waiting for a slow scanner to finish before work can continue). Instant verification of insurance coverage is automated. This is one of the many reasons why the billing solution should be part of the RIS and not bolted on. Work lists are generated for techs, radiologists and transcriptionists and a flow sheet showing the patient s location in the practice is initiated. This flow sheet is very useful to automatically flag any patient who has been in the practice for longer than a set time period.

5 Page 5 To assist with load balancing (from a radiologist perspective), the doctor s work-list can be toggled to show only the local unit studies or all work in the enterprise awaiting interpretation. The patient demographics are available to the modalities (MWL) without the tech being required to re-key any information. Any priors for that patient are pre-fetched from the archive (which might be remote) and are instantly available to the reporting doctor. While doing the study the tech has access to relevant patient demographics as well as the patient requisition and can record (and code) what was done (including consumerables used). If required, instant messages can be sent to the reporting radiologist and again, information in the RIS should not need to be re-keyed into the IM. When the radiologist clicks on a work list item, the requisition is shown along with the billing codes and an opportunity exists to fine tune the invoice. If the patient has no insurance, the invoice can immediately be printed. OsiriX (running on the same computer as the RIS, but displayed on a second screen) displays the current study as well as relevant priors without any radiologist wait time. The radiologist does not need to waste time doing queries and waiting for images. The report is dictated and uploaded so that a transcriptionist can retrieve and type. The word processor is integrated into the RIS which allows the radiologist rapid access to typed reports. External word processors bolting onto the RIS (such as MS Word) tend to be slower to access and increase wait time. Other alternatives such as voice recognition or canned, structured reports should be available. The report and images are immediately available electronically to the referring doctor as Dictated not read. The typed report is added to the radiologist s work-list for sign off. A radiologist edits and signs off the report and the report and images are available to the referring doctor as Final. Electronic signatures and an audit trail guarantee non-repudiation. The billing is reviewed by the practice manager and submitted electronically. Ideally all facilities in the enterprise should work off the same RIS and billing system rather than a number of separate systems that replicate centrally. Load balancing is also problematic if the RIS depends upon periodic replication (ask any radiologist who has had the frustrating experience of completing a report, only to find that another radiologist has picked it up minutes before and already reported on the same study!). On call radiologists (even those with low bandwidth connections) have remote access to the RIS and diagnostic images and tools such as MPR are available and radiology wait time is minimized. These same DICOM viewing tools are available for referring technicians that require them, for the rest, compressed JPEGs are electronically available with the report via a web based system.

6 Page 6 Principles Besides the usability and cost advantage of OsiriX there are other important advantages (Please see Addendum #1 explaining why we preferred the OsiriX option to a central, web-based diagnostic reader). These are the important principles we attempted to get right: 1) The guiding principle behind the design of Blackbird and our OsiriX integration was that radiologist wait time should be minimized (without generating unacceptable network traffic). This means that: a. The radiologist s work list and access to the RIS must run natively on the Mac platform. Expecting technically challenged colleagues to manage virtual Windows machines and OsiriX installations not integrated into the RIS seemed unreasonable. b. The radiologists should not have to query OsiriX or DICOM nodes for current or prior images. They must instantly and automatically be displayed. c. Similarly, dictation, report review and billing needed to be instantly accessible to the radiologist. d. It would be unacceptable especially on a WAN, to send all the images to all the OsiriX workstations. 2) Radiologist load balancing across the enterprise (which might consist of many units) had to be facilitated. This means making it is easy for a remote radiologist to pick up any slack again with minimal (read no ) wait time. 3) Radiologists at home and referring doctors would not necessarily have Macs and it would be unreasonable not to offer them a multiplatform solution. 4) Radiologists at home might have low bandwidth and high latency connections, but they still need to scroll through image stacks and do MPR and some will want more 3D capabilities. 5) Security of confidential information is, of course, critical.

7 Page 7 Blackbird s OsiriX Integration. After experimenting with adding PDF DICOM requisitions to the PACS (so they would display in OsiriX) and having OsiriX generate the reports, it became increasingly clear that it was more efficient to have the RIS drive OsiriX. The RIS therefore needed to run natively on a Mac OsiriX workstation and clicking on the work list in the RIS should instantly bring up the corresponding study in OsiriX (as well as previous, pre-fetched studies available on the PACS archive). We utilized the RPC (remote procedure call) interface exposed by OsiriX to enable our RIS to drive OsiriX. We break up the enterprise into functional units (these might be different facilities, if the enterprise consists of different geographic units, or simply different modalities). Each functional unit has one Mac Pro that is dedicated as a shared OsiriX database and router and is not used as a workstation (no keyboard or screen). Thus far we have tested up to 5 radiologists working off one shared OsiriX database without difficulty because we are currently unsure of the upper limits that the SQLite DB will handle, we break up our units so that no more than 5 OsiriX workstations connect to the same shared database. The RIS, during the production of the MWL (modality work list) for the modalities also prefetches priors and routes them to the relevant shared OsiriX database ready for the radiologist to reference when he is reporting the current study. We expect the various functional units to have decent connectivity between them the faster the better, but request at least 20 Mbps and a max latency of 10ms. For the purpose of this discussion we will assume 6 geographic units dispersed around a city, but things just become easier if all units are on the same site (or in the same room!). The modalities are set to send to the shared OsiriX corresponding to their unit.

8 Page 8 Images sent to that Mac Pro are then compressed and routed to the remote archive. Note: DICOM is not ideal for this purpose, and security is important Blackbird therefore designed a HTTPS router that would run on the Mac Pro. This router also compresses images to save bandwidth. When the radiologist selects a work list item, the RIS changes the local OsiriX database (behind the scenes) to one corresponding to the appropriate shared OsiriX database. This is transparent to the radiologist who only sees that patient in the local OsiriX (even if the shared OsiriX database is actually across town). The unit router (running on the shared Mac Pro) also has a web interface which can be set to automatically route studies to any remote site if that site has a low bandwidth connection. This is necessary because using the shared OsiriX database (without frustration) requires a decent network speed. Typically this function is used to route studies to a radiologist on call from home the routed images are automatically moved either into his local DICOM viewer, typically OsiriX (if on a Mac) or Clear Canvas (if on Windows) but any DICOM reader could be used. The RIS will open the local images rather than the shared database images if the radiologist is at home. Again the intent is to ensure that the wait time for the radiologist is minimized. Some referring doctors will require access to diagnostic images (and perhaps sophisticated tools such as MPR) and again, they need that process to be completely transparent i.e. they open the electronic report and the images open in their chosen DICOM viewer. All referring doctors are able get their reports and compressed images electronically via our web-based platform agnostic reader (which also carries laboratory results and consultation and referral notes), but for those referring doctors that require diagnostic images, and especially, those requiring advanced imaging tools, Blackbird has designed a platform independent client router which will poll the archive (or the shared OsiriX if they are on the same network e.g. in the same hospital) for any DICOM images labeled with the referring doctor s routing code (which is inserted by the RIS) and securely retrieve them to his local DICOM reader (ideally OsiriX, but designed to be reader agnostic). The web-based report reader will (in a similar fashion to the system used by the reporting radiologist) automatically open the appropriate study in the local DICOM reader.

9 Page 9 Conclusion Blackbird s solution is effective and scalable because: a. Our technology is reliable and proven. b. Our RIS besides being fully integrated with OsiriX also does all the housework (billing, document scanning and archive, transcription, report and image distribution). c. Most studies are read locally = less bandwidth usage. d. Modalities only send to one local DICOM node = less bandwidth usage. e. Local workstations access that DICOM node using a protocol 5 x faster than the standard DICOM transmission protocol = shorter radiologist wait time. f. When load sharing is used, remote facilities access the remote database using a protocol 5 x faster than DICOM = shorter radiologist wait time. g. All local studies are moved to a single archive using compression and a protocol about 4 x more efficient than DICOM. = shorter radiologist wait time. h. Blackbird s routers allow images to be automatically routed to disparate locations by time, modality type, referring doctor or any number of DICOM tags (contrast with moving all images to a central server first). = less bandwidth usage. i. Because workstations receive images from the local modalities, Blackbird is fast. = shorter radiologist wait time. j. Blackbird s design means inherent hardware and data redundancy. It also means your practice can start small and grow with you (and at your pace). = extremely cost effective.

10 Page 10 Addendum #1 Discussion regarding the relative merits of web based diagnostic DICOM readers v/s Blackbird s implementation of OsiriX. Much of the information below was obtained from an excellent article Radiology Workload Sharing Many practices are distributed geographically with reporting radiologists (RR) scattered over different sites. If one RR is quiet it is very useful to move the images to that site this is what workload balancing means. The challenge is to ensure that remote images get to the reporting site as rapidly as possible. Two factors affect transmission speed: 1) Size of images. 2) Size of the pipe (network bandwidth). Data may be made smaller with compression. One type of compression is streaming, which is common in web based PACS systems (see below). Although this gives the impression of being faster this is not in fact true the initial (non diagnostic) image is painted on the screen and then the rest arrives, filling in the pixels. Things such as scrolling through the stack or reformatting cannot be done accurately until the whole image has arrived. Essentially there are 2 load-balancing models: 1) Web based With a Web Based PACS system, a PACS server is installed in a central site and images are routed directly to the main server over the network. If the web PACS goes down, the reporting stops! This extremely important to know - a poorly deployed Web PACS, without redundancy (read additional expense), can bring down an entire practice.

11 Page 11 Modalities are very simple in their image transmission rules. For example most cannot compress images. Thus, if required to send directly to a remote server, transmission will be slow. Once images are on the Web Server the radiologist pulls images to their local workstation. This may mean that the radiologist might be pulling images from a remote server in a distant location, for a CT study that was done in the next room! This is, of course, very inefficient and bandwidth extravagant. To address this, a Web PACS over a WAN should have image caching servers at each site with a master database at the main site. This allows images at each site to be locally cached, therefore making better use of bandwidth and significantly increasing speed. The image cache however, is another server, and adds cost, and one still needs a workstation. While load balancing is important, it is equally important to realize that most images are actually reported from the site at which they were generated. Therefore, sending uncompressed images from the remote site to the central server and then pulling most images back from the Web PACS is very inefficient. 2) Thick client typified by OsiriX. Blackbird s solution detailed in the body of this whitepaper is inherently faster and more bandwidth friendly than a web based solution.