DICOM Assist Software ASKCorp Alex Holt, Alex Wirt, Aaron Greenfield, Karina Kanjaria, Steven O’Neill

Problem Statement Field Service Engineers are not presently equipped with a tool to diagnose and repair network connectivity issues between ultrasound machines and their DICOM servers. Outside contractors or OEMs are often necessary to repair the machines, increasing downtime and cost to the client. We have been working with Philips Healthcare to develop a tool that can allow Field Service Engineers to diagnose and repair connectivity issues between untrasounds and hospital servers. Philips is one of the largest companies in the healthcare industry and their presence in imaging modalities is widespread. They have clients throughout the country and they are responsible for maintaining their machines, regardless of whether they were made by Philips, GE, Siemens, etc. So when one of these clients has a nonsimple issue, Philips sends an FSE to the client site to repair the machine. After running through the given protocols and not fixing the issue, the FSE concludes that there is a problem between the machine and the DICOM server, which Karina will talk more about. In some cases, the Philips FSE is not able to repair such an issue if the machine is from GE or Siemens, so they have to hire a contractor or someone from the OEM to fix the issue. This increases the downtime of the machine and also increases cost to the client. We want out program to eliminate these required outside sources and increase the effectiveness and efficiency of the FSEs.

Needs Assessment Compatible with DICOM server Compatible with a variety of ultrasound machines Diagnose connectivity issues Troubleshoot at individual network layers Identification process for DICOM errors Understand DICOM protocol Simple user interface Training program including repair, theory, and troubleshooting Portable & usable on site by trained FSEs Conforms to HIPAA standards Aaron- We came up with a list of needs for our product. It must be compatible with both the imaging equipment it will be connected to and the clients server. Its primary purpose is to diagnose the connectivity issues between these two entities, and it does this by troubleshooting at individual network layers which we will explain more in our design approach. In addition to diagnosing generic network errors, it should be able to identify errors specific to the DICOM server. Karina- In terms of developing this program, it is necessary for us to be able to understand how a DICOM server functions and the different protocols associated with it. The program should have a simple user interface so that even the most inexperienced FSEs can implement it successfully. It should also be portable and include a training course that encompasses repair, theory, and troubleshooting. Additionally, it should conform to HIPAA standards.

Background Digital Imaging and Communications in Medicine Handling, storing, printing, transmitting DICOM 3.0 Information in data sets File format definition and communications protocol TCP/IP DICOM stands for Digital Imaging and Communications in Medicine and it is a standard for handling, storing, printing, and transmitting information in medical imaging. It was created in the 80s because it was difficult for anyone other than manufacturers of CT or MRI devices to decode the images produced. The third version of this standard created was released in 1993 and it has been universally accepted since. DICOM differs from other data formats in that it groups information into data sets. It includes a file format definition and a network communications protocol. The network communications protocol used in DICOM is TCP/IP which is the standard for connecting two hosts and transmitting data. DICOM files can be exchanged between two entities that are capable of receiving image and patient data in DICOM format. This is one of the major benefits as well. Images can be sent from a modality to be printed by a DICOM compatible printer.

Background HIPAA Ultrasound Health Insurance Portability and Accountability Act Protects patient identifying information Covered in Philips agreements and protocols Ultrasound Portable and more accessible Wired and wireless connection http://health.state.tn.us/hipaa/ HIPAA stands for Health Insurance Portability and Accountability Act of 1996. The main purpose of this piece of federal legislation is to protect an individual’s health information and his or her demographic information. This protected information includes things such as the patient’s name, any dates associated with the patient, and different images taken of the patient. The primary concern is removing this information from the hospital without the consent of the patient. This is not a specific concern for us because Philips has assured us that their agreements with hospitals and the FSEs cover everything HIPAA related. This is the reason it would be difficult for us to design our program for machines like an MRI or CT because they’re primarily located in hospitals and our access would be very limited. We are choosing to focus on ultrasound because they are portable and Philips has said they can give us access to a number of different models of ultrasound machines. Up until a couple years ago, most ultrasound machines transmitted their data via a wired connection.

Proposed Solution We are creating a computer program, runnable on a low-end laptop, to help Field Service Engineers diagnose and solve connection and communications issues between ultrasound machines and DICOM servers, removing the need to involve OEMs or outside contractors.

Design Approach Troubleshooting Communication Issues Data Transmission between Networks OSI networking model Packet Structure header data trailer Communication problems within layers -network communication can be divided into 7 operational layers -each layer provides a service that prepares the data for delivery over the network to another computer -higher layers denote a more complex operation Application Layer: file transfer, database access, higher level of coding, DICOM protocol is used in this layer to overcome obstacles from multiple imaging modalities manufactured by different OEMs Presentation Layer: convert formating for transmission or reception, translates and encrypts data Session Layer: communication between hosts These layers have a higher level of complexity and to understand coding on the higher level we need to comprehend whats happens on the network protocol Transport Layer: splits long data messages into smaller packets when transmitted, combines small packets and puts them together when receiving Network Layer: addressing and routing for packets, translates logical software address to a physical address, manages congestion of data, determines the path data should take based on network conditions, reassembles data on the receiving end Data Link Layer: receives data packets from network layer and sends to physical layer, packages raw bits from physical layer to data packets in network layer, must be error-free for providing transfer of data packets Physical Layer: transmits raw bits, defines how long bits last, specific wiring used

Design Approach Interactive manual Determine Ultrasound model Include a DICOM viewer lets FSE’s laptop mimic server start a fake study if not: system would shut down connection Simplify layout of GUI DICOM Transport Network Interactive manual initially, there will be a screen prompting the FSE to select which ultrasound is being used based on the OEM and model consolidate protocol stacks laptop program would include interactive manual prompting FSE to use the Ultrasound in order for the laptop to receive vital information based on the suggested commands

Status Working directly with Field Service Engineer with specialty in ultrasound Setting times to directly work with ultrasound devices Beginning work on DICOM-level troubleshooting Using freely available DICOM viewer for diagnosis We decided recently to narrow our focus to only include ultrasound devices. This has made our project much more accessible - we have met with an ultrasound specialist with a background as a Field Service Engineer to discuss communication/connection issues that frequently affect ultrasound. He was also able to talk about how ultrasound devices send their data to DICOM servers, giving us an angle to work with. With that in mind, we are booking times to work directly with several models of ultrasound, and have begun to write code addressing DICOM troubleshooting.

Status

Questions?