HealthManagement, Volume 4 / Issue 2 / 2009

Author

Kirill Basikhin,

is Vice President of Softage

LLC, Novosibirsk, Russia.


A leading Netherlands-based hardware and software vendor required customized interfacing software to support data interchange between their own proprietary software, medical imaging devices and a Hospital Information System. They sought an external partner to develop customised software that would connect these different systems and fully support data interchange in DICOM (Digital Imaging and Communications in Medicine) and XML formats. Softage, a Russian firm finally selected for the job, won the order due to a proven technological track record in complex software development projects, quick responsiveness/turnaround times and attractive pricing. Along the way, there were lessons for everyone, as explained by the Vice President of Softage.

 

Project Overview

The interfacing software we were tasked with developing was meant to support five connections with external systems. All these connections, moreover, had to be compliant with industry standards.

 

In the first phase of the project, our customer needed to process only data transferred to and from X-ray devices, based on DICOM which covers handling, storage, printing and transmitting of information in medical imaging and includes a file format definition as well as a network communications protocol (see box).

 

C#.NET, MS SQL Server and DICOM

Our engineers, in cooperation with the customer, designed and implemented the first version of the interfacing software. We used C#.NET and MS SQL Server as the best technology choice for the Windows platform, which is common at hospitals in Europe. The interfacing software transforms procedure information data into DICOM standard and transfers it to the X-ray device. X-ray device information, on its part, is sent back to the interfacing software for further processing.

 

At the end of this process, complete patient information including demographic data and X-ray information can be easily obtained from the database. The software has been found to work well according to customer expectations. Further system development is likely to consist of adding HL7 compatibility and connection to HL7 data feeds.

 

Challenges of Customisation = Niche Opportunities

Why was there a need for such software?

The reality is that giant hardware manufacturers and healthcare software vendors such as Philips produce heavy large-scale systems which address only the major needs of hospitals, doctors and dentists for data storage, transmission and processing. This opens up opportunities for smaller players with state-of-the-art software/ hardware offerings in a panoply of niche application areas.

 

Our customer's existing product (combining hardware and software) was a Hemodynamic Monitor designed specially for Cardiologists. But the software originally could only output and process data in XML format. That's why there was a need for DICOM-to-XML and backward conversion capability, in order to connect it to other medical devices such as X-rays as well as Hospital Information System.

 

Potential Options, Advantages of DICOM

Why was DICOM necessary for our project's purposes?

 

DICOM is a wonderful technology that allows addressing technical interoperability issues in medical imaging. It connects different hardware systems produced by diverse vendors and heterogeneous software platforms. The fact that DICOM has been widely adopted by hospitals in Europe will significantly facilitate a market for the software. This is why DICOM compliance was an obvious requirement in our case.

 

In our project, we used a third party library which helped in transmitting DICOM data to the X-Ray device and backward. However, it did not provide all of the required functions, which had to be developed and implemented by our experts.

 

Specific Challenges and Technology Issues

The main project challenge consisted in remote development of a complex data processing software without having access to the customer's original medical equipment. Our company’s development centre is located in Novosibirsk, Russia, while the customer premises were located in the Netherlands, with a 5 hour difference in time zones.

 

So from the beginning we set up an efficient collaboration environment including bug tracking and version control software systems and set up regular daily communication with the customer's project manager using instant messenger to overcome the distance.

 

For the same reason we actively used special programs - emulators that helped us to work without direct access to the expensive and bulky medical hardware. Usage of emulators allows significant savings in development time and project budget. Another obvious advantage is that our project schedule was not dependent on hardware resources availability. The final tests were, however,completed on real equipment at a hospital.

 

Multiple Languages

Another challenge was the need to support multi-language processing of patient data. The system was aimed at recognition and processing of most European languages, beginning with English and Dutch given that the primary target for the software were Netherlands-based hospitals. We took this requirement into consideration and designed the system to fully support Unicode, allowing for the processing of data in any European language. While we worked on the project we faced several technology issues.

 

Tweaking Tools

The first of the issues was integration of a third party tool. We used Offis DICOM DCMTK tool to process queries from the Xray device to our software. In the early phase of the project, the tool did not manage to correctly process some important data. We investigated all available documentation for this tool, but there was lack of detailed documentation about its usage so these documents didn’t help us much. To solve the problem, we investigated the source files of the tool, read the internal source code comments, and tried to trace the execution of this tool. After in-depth research of the problem, and with the help of the vendor’s team, we managed to successfully fix problems in the third-party code.

 

Testing: Mixing and Matching, Harmonising

The second issue was the test environment mix on the development and customer side. Since we didn't have a real X-ray device at our lab, we decided to use Phillips DVT (DICOM Validation Tool) to ‘emulate’ DICOM requests from the X-Ray device. Meanwhile, the customer had been using the Witt Biomedical application to emulate such requests. As a result, at the customer end the software did not properly process the DICOM data coming from the emulator. Once we convinced the customer to use an identical testing environment, the problem  was solved. The final acceptance testing with a real X-ray device at a hospital was successfully completed by the customer's team.

 

Field Mapping

Another issue concerned a Field Mapping problem. This was related to the conversion of XML data field values coming from the customer's software into DICOM-compliant data. The original customer's equipment data output contained fields without direct equivalents in the DICOM standard. We intensively worked with the customer's team to resolve this issue and to create a working field mapping schema. At the end, we achieved full data compliance to DICOM standard.

 

Protection

The final problem was related to usage of hardware protection for the software. The customer decided to use a hardware HASP key to protect their application from improper usage. [HIT Note: HASP is a rights management solution to enable the use of either software- or hardware-based protection keys to enforce software protection and licensing].

 

The HASP key vendor released a master key for the customer's team and we got a supplemental test key for development purposes. At the late phase of the project the customer found that the program could not be started with their master HASP key. As our company did not have any previous experience with HASP technology, we contracted a third party professional familiar with this technology so that the team was able to get consultations when needed. After investigation, we found that both the customer and the contractor must have identical “vendor code” for both HASP keys that is supplied along within software package. This allows both a customer and his remote development team to stay on the same page.

 

Lessons learned
Interoperability and Third-Party Tools

Most of issues we faced and resolved were related to interoperability and third party technology usage. To resolve these issues, we investigated the third party components, available documentation and sometimes contacted manufacturer/vendor teams. Strong analytical skills and the creativity of our experts were key contributors to the success of the project.

 

Assigning right specialists to perform specific tasks is a critical success factor in outsourced projects. The usage of collaboration tools such as bug tracking and version control systems helps aligning the efforts of customers with a remote development team.


Appropriate Test Environment

Setting up a proper testing environment can have a strong impact on a project, especially in complex projects with specific hardware involved. Usage of software emulators significantly saves project time and budget and allows working independently from hardware resources availability.

 

During this project our specialists acquired valuable experience in such specific areas as DICOM and HL7 standards and interoperability solutions development for the Healthcare industry. Today, we are capable of delivering enterprise-scale Healthcare solutions which fully comply to the most stringent standards.

 

A Personal Touch – and the Long-Term

Open, honest and regular communication with customer, the discussion of all problems (including those just emerging) was also a critical factor to help in resolving issues.

 

Upon successful completion of the project, our top management was invited to the customer's premises to discuss further long-term cooperation. The next project will consist in development of powerful DICOM data processing software for the Hospital Information System. The software will work as a service that processes visual information in DICOM format coming from different hospital appliances and stores the information in the central database.

DICOM: Healthcare’s Must have IT Standard

Though the history of digitised medical images dates back to the 1970s, it was only in the early 1990s that standardised formats for their transmission came into being. The trailblazers for these efforts were the American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA), which sought to replace previous, proprietary formats for image storage and transmission.

 

The earliest versions of the ACR-NEMA initiative created a common terminology and information structures. However, a standard method of communicating the information was the ACR-NEMA version 3.0 Standard released in 1993. This soon saw its name changed, to Digital Imaging and Communications in Medicine (DICOM 3.0).

 

DICOM 3.0 not only allows for the transfer of medical images in a multi-vendor environment, but also interfaces with picture archiving and communication systems (PACS) and other medical information systems. It is considered as the standard for communication across the boundaries and margins of disparate applications and devices.

 

DICOM addresses multiple levels of the ISO OSI network model and provides support for information exchange on interchange media. It specifies a TCP/IP network protocol, defines service classes beyond simple image data transfer and has established a mechanism to uniquely identify Information Objects (images as well as patients, records, reports etc.), as they are acted upon across the network.

 

DICOM currently defines an upper layer proto(ULP) that is used over TCP/IP (independent of the physical network), messages, services, information objects and an association negotiation mechanism. These ensure that any two implementations of a compatible set of services and information objects can effectively communicate. In turn, independence from the underlying network allows DICOM to be deployed in many functional areas of application, such as single-site communication (e.g. through Ethernet), between sites over leased lines or virtual private networks (VPNs), and within wider regions – via DSL, Asynchronous Transfer Mode or satellite.

 

At the baseline, DICOM does not define architectures for an entire system or provide specifications for functional requirements, beyond their service-related behaviour. The storage of images (objects), for example, is defined in terms of what information must be stored or transmitted, not how they must be displayed.

 

In the application layer, the Information Objects address five main functionalities:

Ó Transmission and persistence of complete objects (such as images, waveforms and documents),

Ó Query and retrieval of such objects,

Ó Performance of specific actions (such as printing images on film),

Ó Workflow management (support of work lists and status information) and

Ó Quality and consistency of image appearance (both for display and print).

 

In a healthcare setting, DICOM’s scope is universal and encompasses every specialty that uses imaging, from cardiology and ophthalmology to pathology, radiology and surgery. DICOM also addresses integration of information (the DICOM Information Objects) from different specialty applications into a patient’s Electronic Health Record (EHR).

 

Organisationally, DICOM is an independent, international standards development organization. It is administered by NEMA’s Medical Imaging and Technology Alliance. Working groups perform the bulk of work on the extension of the standard and (when required) implement corrections and modifications. DICOM also has a strong relationship with IHE, the Integrating the Healthcare Enterprise initiative, which was profiled in the previous issue of Healthcare IT Management.

 

«« Healthcare IT Providers Need To Do More To Solicit User Feedback