Networking and Teleradiology

Transcription

1 Medical Informatics, PhD Networking and Teleradiology 1

2 Part 1: Networking standards Digital Hospital Digital Hospital Teleradiology & WWW HIS (Hospital Information System ) Integration PACS (Picture Archiving and Communication System) Text EVN A PID SA EVN A MPLE^JOE^^^^ PID M SA Lake Villa MPLE^JOE^^^^ 1 Dr^^Metairie^LA^ M ( Lake Villa Dr^^Metairie^LA^ ( Images HL7 (Health Level 7) DICOM (Digital Imaging and Communications in Medicine) 2

3 The Radio Doctor Maybe! The concept of remote data analysis is certainly not new, but it took a while to develop the best approaches and technology. The first Skype prototype 3

4 Why teleradiology Optimization 15% annual data growth vs. 2% annual radiology growth Access to remote areas Balance of knowledge Full use of digital formats Why teleradiology 4

5 Why teleradiology PACS: Picture Archiving and Communication System Modalities Archive Workstations Store Acquire - DICOM network View 5

6 DICOM Networking layout DICOM Software FTP client Web browser DICOM networking: High-level DICOM: DIMSE and SOP Low-level DICOM: association negotiation and PDU. Also known as DICOM Upper Layer protocol (SMTP) Web (HTTP) File transfer (FTP) Network application layer TCP/IP networking: basic standard for modern computer networks DICOM networking DICOM controls data exchange over computer networks (TCP/IP). AE Application Entity any DICOM-compatible device in DICOM network AEs can use DICOM networking commands to verify connectivity, search for data, and send data to each other. DICOM Conformance Statement - describes to what extent each AE supports DICOM (18 volumes!) Must have! DICOM is service-based standard: any two connected AEs provide services to each other. For instance, DICOM printer serves DICOM CT scanner, printing CT images. 6

7 Network service model SCP Service Class SCU DICOM networking is implemented with service rendering model: Service Class Providers (SCPs) provide services to Service Class Users (SCUs). Image storage SCU Image storage SCP Archive SCP/SCU role depends on the particular task Image storage SCP Image storage SCU Connecting DICOM AEs: IP, Port, AE Title. Configuration is easy, assuming you are in control of your DICOM devices. 7

8 DICOM services DICOM units (AEs) request and provide services to each other. Main DICOM services include: Echo (verification) - verifies in network partner (AE) is available Store - stores DICOM objects on specified AE Find - searches for DICOM objects on specified AE Get - retrieves DICOM objects from specified AE Move - moves DICOM objects from AE 1 to AE 2 Each service includes command (such as Find) and command data (such as Find parameters). Service and its data form Service-Object Pair (SOP) DICOM Message Service Elements (DIMSE) 8

9 C-Echo (Verification SOP) Client (Service Class User, SCU) is asking for a service. Server (Service Class Provider, SCP) is providing the service. SCU/SCP roles may change depending on the task. Verification SOP UID: C-Echo SCU (Example: Archive) Servers can be SCUs! Send DICOM verification Request Send DICOM verification Response Slang: DICOM-ping C-Echo SCP (Example: Modality) C-Find Client (Service Class User, SCU) is asking for a service. Server (Service Class Provider, SCP) is providing the service. SCU/SCP roles may change depending on the task. C-Find SCU (Example: Radiology workstation) Find all MR studies for patient J*son List of studies found Important: DICOM can search medical databases remotely. C-Find SCP (Example: Archive) 9

10 C-Store Store images to C-Store SCP CT Storage SCU (Example: CT scanner) Sends CT images to be stored (requests CT Storage service) Accepts CT images for storage (provides CT Storage service) Slang: DICOM-push CT Storage SCP (Example: Archive) C-Get Retrieve images from C-Get SCP (using the same connection) C-Get SCU (Example: Radiology workstation) Retrieve study (images) with Study UID Images (sent with C-Store) Slang: DICOM-pull C-Get SCP (Example: Archive) 10

11 C-Move Ask C-Move SCP to send images to third party destination C-Move SCU (Example: Radiology workstation) Retrieve study (images) with Study UID Images (sent with C-Store) Slang: DICOM-pull C-Store SCP (Example: Workstation) C-Move SCP / C-Store SCU (Example: Archive) MWL (Modality Worklist) Radiology Information System (RIS) MWL SCP (Example: Archive) MWL SCU (Example: Modality) C-Find-Rq: Find current scanning schedules for this modality Send current patient scanning schedules C-Find-Rsp: Provide current scanning schedules Fetching patient/schedule info from RIS into MWL SCP, converting it into DICOM MWL SOP, based on C- Find DIMSE 11

12 DICOM Services around us (!) DICOM & HL7 Networking Basics C-Echo, C-Find, C-Store, C-Get (C-Move) is all you need to run a medical imaging (DICOM) network. There are lots more in DICOM: printing (becoming extinct), encapsulating various formats (PDF, video MPEG, screenshots, reports). HL7 provides similar query/retrieve mechanism: messages.html browse HL7 pages, very informative Example: 12

13 Can I make my own PACS? Absolutely. The recipe: Make sure your modalities are on the hospital network (ping them). Find DICOM settings in their interfaces. Make sure your modalities speak DICOM (use C-Echo). Install DICOM software (trial or not) on any hospitalnetworked computer - your pilot server. Configure DICOM modalities to store data on the pilot server. Configure DICOM workstations to retrieve data from the pilot server (using DICOM software on the workstations). Let the pilot server run for two weeks to estimate your storage volume and bottlenecks. Then buy the real server accordingly. Can we build a DICOM Dropbox? DICOM Dropbox: Dropping DICOM file into a dropbox folder automatically forwards it to a preset PACS archive File drop DICOM upload PACS Archive Q: Which DICOM service will you need: C-Echo C-Find C-Store C-Get C-Move? 13

14 Part 2: Getting tele done (right) Getting tele done (right) Q: OK, we know that DICOM and HL7 work well on local hospital networks. Can they scale to WWW? 14

15 Hidden problems Conceptually, remote clinical networking is expected to use the same standards and protocols as local hospital networks, but In reality, making things work remotely calls for much more reliable, functional, integrated solutions, which cannot be found in a local, static environment. What about tele? Classical clinical standards such as DICOM have pros and cons: Pros: DICOM association establishment (handshake) mechanism ensures device/app compatibility. Default data format is always defined. Advanced functionality (such as remote searches far better than FTP!) Fast (although there are many myths about DICOM overheads ) 15

16 What about tele? Cons: No error recovery, no solid error-reporting mechanism (errors like reason-not-specified ) No idea of transmission progress Static IPs (DICOM AEs find each other by IP addresses) Cannot specify certain important parameters (such as image compression ratio) Heavyweight: you cannot run DICOM in a web browser Poor support for internationalization (localization) Teleradiology Online radiology Mobile workstation Hospital PACS Remote workstation Remote PACS 16

17 Teleradiology vs. PACS PACS Teleradiology = DICOM Network (data) + (connection) + Making the damn thing work!!! OR Teleradiology = Proprietary Important aspects of teleradiology Standardization (!!!) Image compression and quality Flexible data access clients (lightweight, OS- and browser-independent) Fault tolerance Prefetching and other methods to avoid slow networks Information protection and security Seamless integration into hospitals electronic records Use of consumer computers Staying away from simplistic models ( attachments, Dropbox, Skype, remote desktop, etc.) 17

18 Opening hospital network to WWW Remote viewing PACS server Telerad server Isolated clinical network Hospital Open PACS server WWW Never share your servers! Opening hospital network to WWW Remote viewing PACS server Telerad server Hospital RDP into hospital WWW 18

19 Data volume Image modality Nuclear medicine, NM Magnetic resonance, MR Computed tomography, CT Color ultrasound, US Computed radiography, CR Color 3D reconstructions Digital mammography, MG Typical sizes of digital images and studies. Typical image matrix (height width, bytes per pixel) Image size, kilobytes (KB) Typical number of images in a study Up to Typical study size, megabytes (MB) Dealing with volume: compression Illustrating excessive lossy compression with images and text patterns. Overdone JPEG creates highly-visible blocking artifacts; overdone JPEG2000 creates blur. 19

20 Dealing with volume: prefetching Remote viewing Slow network Prefetching server DICOM images Hospital PACS Fast network DICOM images Fast network Load balancing: thin and thick Thin client Thin client server Thick client server Thick client Computing on the server Sending the data Sending the results Computing the results Know how to balance your loads! 20

21 Web clients and their advantages Web-based, using wellknown web protocols Diagnostic images Cross-platform, crossbrowser Displaying full multimedia information: imaging, reports, charts, Diagnostic quality Zero footprint ensures confidentiality Patient reports Well, what about the disadvantages? Name a few problems with web clients: 21

22 Web clients: limitations Limited processing power Limited memory Universality limits functionality Require lighter (and often proprietary) versions of DICOM and HL7 Complex vs. universal More complex web technologies may not be widely supported. Failed to start 22

23 Implementation: facade Implementation: behind the facade Do your doctors have 15 minutes? 23

24 Implementation: facade Implementation: behind the facade Failed DICOM image display 24

25 Implementation: facade Implementation: behind the facade 25

26 Implementing web client ActiveX? Java? HTML5?.NET? True web-based client is the best way to go. Good for stealth radiology as well (leaving no traces on the client computer) Load-balancing should be considered in the context of your implementation technology. Example: adjusting image brightness interactively Can you do this on your client? Price for doing this on your server? Implementing web client Performance optimization is essential for web clients. Example: image compression Compress ahead of time, or on the fly? Hi-res, or thumbnails? Choice of algorithm: ZIP? JPEG? PNG? Choice of implementation: Multithreaded? DB-based? Separate server for compression? Separate PACS archive? Choice of hardware: GPU/CPU? Processor cores? Location? 26

27 Implementation Heavyweight teleradiology (inter-connected PACS) great for large imaging projects with well-defined boundaries. Example: Radiologists from hospital A assist radiologists from hospital B. Lightweight teleradiology is perfect for mobile, cloudy projects with many moving targets. Example: setting up a virtual radiology network business, to consult understaffed hospitals. Web-alternatives: PACS networks LAN PACS server Remote hospital VPN Connecting several PACS via VPN channels is used in large, static regional projects. WWW 27

28 Web-alternatives: peer-to-peer networking LAN WWW PACS server Remote viewing Isolated clinical LAN Peer-to-peer server connects remote to local using outgoing requests only Can be used for dynamic remote access Data-sharing channels DICOM (data and network) the best DICOM (Germany) FTP and such (file sharing) Proprietary formats Remote viewing clients Multimedia (JPEG, AVI, ) Hard copies (CD, DVD, ) 28

29 Data quality Early approach to teleradiology: transmit data by any means. Result: lost data, horrified medical community. Screenshots, scanned, copied DICOM (original) Viewing quality: image interpolation The goal of any interpolation algorithm is to preserve the frequency content (local details) of the original image. Linear Cubic ipad high-res display phenomenon? 29

30 DICOM over (the right way) DICOM Automatically wrapping DICOM images into MIME and ing to clients: WWW server PACS workstation (with DICOM ) at HospitalA Automatically checking mailboxes and retrieving DICOM images PACS workstation (with DICOM ) at ClinicB Ubiquitous and inexpensive fax machine Anything works, as long as it makes sense! The framework and its successful use are explained in [Rothpearl]. A special software plug-in can automatically register incoming DICOM studies, and receive faxes, related to them converting them into DICOM images, and storing them in the PACS to accompany the original image data from the modalities. If you add the simplicity of the fax machine (compared even to a flatbed scanner), that even the most computer-averse hospital staff can handle, you will certainly appreciate the efficiency of the fax-to- PACS interface. I can t wait for DICOM Twitter. [Rothpearl] Allen Rothpearl, Rafael Sanguinetti, John Killcommons, Development of a Fax-Based System for Incorporating Nondigital Paper-Based Data into DICOM Imaging Examinations, Journal of Digital Imaging, 2010 February; 23(1):

31 Multimedia Multimedia support is essential for robust implementation. Modality 1 PACS Server Multimedia Server Modality 2 Robustness is not about spare parts ; it s about functional alternatives! Data format: DICOM Multimedia DICOM for WWW: WADO and MINT WADO (DICOM Part 18) Web Access to DICOM persistent Objects MINT Medical Imaging Network Transport &studyuid= &seriesuid= &objectuid= &contenttype=image%2fjp2;level=1,image%2fjpeg;q=0.5 &annotation=patient,technique &columns=400 &rows=300 &region=0.3,0.4,0.5,0.5 &windowcenter=-1000 &windowwidth=

32 Working on any platform/environment Mobile modalities and workstations FDA approved if you do not have a workstation 32

33 Know your gadget! VS. Do not get fancy, get practical! Patients in charge Patients are getting more and more involved. Is your hospital ready? 33

34 Nationwide PACS Nationwide PACS does not mean single PACS provider! The most essential question is always the data, and not the implementation. For example, do you have a mechanism for nationwide Patient ID? Worldwide PACS: Parlez-vous Deutsch? (not yet) Start with planning for multilingual data. 34

35 Convenience Reading images remotely can be fun! Teleradiology in the US Percent of hospitals using teleradiology Hospital size (number of radiologists) From 2003 to

36 Predators or allies? There is one important item in any teleradiology project that has absolutely nothing to do with DICOM: personal relationships. Many hospitals tend to view expanding teleradiology practices as predators, threatening their business, jobs, and quality standards. Moreover, when patients and referring physicians learn that their images will be read somewhere else, they may get concerned as well. Therefore, the pros and cons of any teleradiology project should be weighed ahead of time, with very clear boundaries of responsibility defined for the local and remote radiology groups. If anything is questionable, prioritize the quality, and the quantity will follow. Starting your (teleradiology) project Estimate the required time to transmit your data (volume/speed). If necessary, use compression or prefetching to reduce data transfer delays. Decide on Pull (retrieving remote data on demand) vs. Push (having remote data sent to you) models. Pull is best if you need only a small fraction of all data, and if you want to be entirely mobile. Establish a local server to store your data (especially if the data is pushed to you). 36

37 Starting your project Choose viewing solution and software that accommodate the widest range of devices (smartphones included). Favor solutions with better multimedia support. Avoid hard-coded, impossible to change, static configurations. Favor inter-independent, modular solutions. Hire your own IT support (you may have it part-time, but you have to have it). Starting your project Integrate your solution into the other systems you and your doctors are using. The data should flow automatically. Always plan for scaling and growth. Have a fully functional plan B for your entire setup. 37