A Workflow for Ensuring DICOM Compatibility During Radiography Device Software Development

Abstract

In medical devices, nonconformance with Digital Imaging and Communications in Medicine (DICOM) standard is a serious risk. DICOM nonconformance radiology devices could cause undetected image loss, increasing examination time, and costs in health centers and could even result in the wrong patient treatment. However, there is a rich literature on medical standards that identify the best practices for producing safe and effective medical software. However, these standards do not expressly provide tools to deal with all the relevant DICOM compatibility issues in a specific case. This study aims to introduce a systematic software development workflow that complies with medical standards and ensures DICOM conformance of a new or upgraded radiology software project. In this approach, DICOM conformance gets the highest priority, and the whole software project is organized around it. Software requirement analysis, risk evaluation, and test management tasks are arranged systematically to make the final device DICOM conformant. This conceptual framework was developed during the R&D work towards a novel radiography device, and it could be employed as a roadmap in other medical imaging software projects. The proposed methodology controls the DICOM compatibility risk of the final software, and its systematic evaluation complied with medical standards.

Introduction

Risk is intrinsic to medical devices and may negatively affect their expected operations. Medical risk is the point of concern for many medical standards: IEC 82,304 (General requirement for product safety) [1], ISO 14,971 (risk management) [2], and IEC 60,601/61010 (safety and performance) [3], which all encourage manufacturers to establish processes that commensurate with the risks of developing their medical devices and prove their safety and effectiveness.

Mathematically, multiplication of the probability of the occurrence of harm with its severity is equal to the risk associated with that harm [2]. For example, in radiology departments, there is a chance to assign acquired digital X-ray images to a different patient [4] or store them with incomplete credentials. In such circumstances, the examination outputs might be a loss, and the patients may require further examinations. Repeated exams would bring an extra burden on the healthcare centers and increase the harmful X-ray dose to the patients. These instances are not uncommon in daily clinical practice [5], or assigning to a wrong patient in radiology departments after finishing the examination has been reported to be relatively high [5, 6]. To reduce the risks related to the communication channels between medical devices and health center infrastructure or data storage, Digital Imaging and Communication in Medicine (DICOM) standard [7] was introduced.

Since the introduction of DICOM about 30 years ago, it became the driving force for standardizing medical imaging procedures’ workflows. During this time, DICOM evolved to address all aspects of digital image acquisition, transmission, presentation, and processing (Fig. 1). As a result, despite the recent advances in digital imaging, healthcare centers may lose their DICOM files, while some of these losses are going completely unnoticed [5]. One common reason for this problem is the scanner devices’ DICOM nonconformance.

Fig. 1.

DICOM evolved into many different aspects of medical imaging

DICOM part 2 [8] gives conformance requirements, templates, and examples. Each section of this document specifies the mandated device service classes, information objects, and supported communication protocols. This document formalizes the vendor’s claims but does not include methods for evaluating or testing them. For this purpose, the purchaser prepared DICOM user-conformance-profile is used to form the basis upon which the vendor’s claim could be validated [9]. Despite this, vendors still provide their implementations (and often interpretations) of DICOM in their image files, which might cause errors within the patient reports at the end [5].

The DICOM standard provides a collection of data elements (tags) to be interchanged and defines what they mean; it does not specify how they should be acquired or what should be done with them. On the other hand, standards like IEC 62,304 (Medical Device Software—Life Cycle Processes) [10, 11] and IEC 29,119 (software testing) family are available which provide a pathway for making a safe and effective medical device software—either as independent software or part of a device. Implementation of these standards was the subject of several studies. For example, formal methods and abstract state machine (ASM) were proposed to develop a medical device and applied in hemodialysis and optometric measurement devices’ software [12, 13]. Even though these approaches have a good performance in identifying and controlling a medical device’s risk, they still require an a priori model of the medical system. These analytical models are available for systems with limited complexity in the real world [14]. However, in complex systems, such as medical radiography scanners, and for issues like full DICOM conformance, more elaborate methods are needed.

In this work, a new software development methodology is introduced as a systematic workflow for developing radiography scanner software to fill the gap between DICOM and other medical software development standards. This method initiates and organizes the software development tasks following relevant medical standards and DICOM requirements. The workflow was developed during an open-source digital radiography workstation software project named iBEX [15]. This software is an open-source radiology workstation for digital X-ray scanners designed to be a generic workstation software suitable for developing various digital radiography components (e.g., X-ray detector, power generator, etc.) of different vendors and integrate them into its core module during boot up.

The focus of this work is to provide a general framework for DICOM conformant radiography devices. The proposed methodology could be applied to customize and extend the iBEX platform itself or develop a new radiography workstation software.

Background

Software Model

A medical radiography scanner consists of a set of electrical devices (e.g., alarm, power generator, image receptor, etc.), mechanical devices (e.g., patient table), and mechatronics devices (e.g., positioning robotics). These devices are connected through electronic interfaces to a central workstation machine, which executes control software. Except for special cases like portable scanners, this software tool is responsible for providing data acquisition procedures, local storage management, data processing, and communicating with healthcare infrastructure for transmitting medical records to local or remote places.

A 3-tier architecture [16] of a workstation software is shown in Fig. 2. In this design, the data organization tier encapsulates data-centric issues like local storage and backup policy management. The business logic tier covers a variety of components. These components are burdened with public and private services, which together constitute the device functionality. Hardware abstraction component unifies the communications with peripheral devices, security component implements authorization, and authentication mechanisms; process-management implements usage processes (e.g., image acquisition process, patient preparation process, etc.); extension manager handles loading, validating, and integrating the extension plugins; communication manager means to provide data and control flow in between modality and environment; service manager facilitates systemic services (e.g., fault control, system calibration monitoring, etc.); resource manager organizes logical and physical resources like memory and processing power consumption; history management component tracks the logs of events and interactions; and finally, the customization component provides the device localization. These components interactively collaborate, but these connections are not shown in Fig. 2 to simplify the diagram. The presentation tier includes presentation components and modules like language localization, themes, and skins.

Fig. 2.

Software architecture of a radiology workstation software

System Environment

Modern radiology scanners are needed to operate in a network of devices. This network potentially eases the data flow. For example, health centers are usually interested in scanners that are compliant with their radiology information system (RIS) to automate the worklist transfer to the scanners [17].

Integrability of a radiography scanner to network infrastructure is contingent on-device software implementation and network infrastructure. Medical modalities apply the DICOM standard; however, RIS and Health Information Systems (HIS) are based on HL7 protocol [18]. Brokers bridge in between these protocols and route the messages in between DICOM and RIS/HIS (Fig. 3). Message flow from RIS to modality is a one-way path. Modality performed procedure step (MPPS) provides feedback. Typically, acquired images are first stored inside the workstation storage; then, it is sent to a local or remote picture archiving and communication system (PACS). The communication channel between modality and the server could pass over a remote web-based link or local TCP/IP ethernet. However, cloud infrastructure’s proliferation provides new reliable, scalable, and cost-effective alternative solutions for the health centers with enormous annual data transfer size [19].

Fig. 3.

Medical health information technology includes variety of protocols and mediators

Device-Environment Integrabrility and Interoperability

Integrating the Healthcare Enterprise (IHE) provides the foundation of health information technology (HIT) interoperability. IHE initiative provides profiles based on existing standards (e.g., HL7, ASTM, DICOM, ISO, etc.) to leverage the integration capabilities and effective use of electronic health records (EHRs). This initiative also develops a simulator [20], releases technical frameworks, and regularly holds Connectathon test events [21].

The IHE radiology technical framework [22] contains specifications of profiles that establish data integrity and consistency in radiology departments. For example, scheduled workflow (SWF) describes activities starting from ordering a study to viewing the results at the end of the examination [23] such that the patient and examination information integrity is maintained. Patient information reconciliation (PIR) profile offers the means to match the patient with misidentified or unidentified (e.g., trauma patient) acquired records [24]. Image object change management (IOCM) profile specifies mechanisms for informing changes on the local copy of an imaging object to the other actors. The changes could result from image rejection due to patient safety or quality reasons, corrections in modality worklist, or expiration of imaging. In these situations, IOCM promotes data integrity [25].

Medical Software Standards

Developing a medical workstation software should follow a systematic approach that is consistent with standards; otherwise, it could end in failure [26]. IEC 62,304 proposes a V-model software development life cycle (SDLC). In this model, software development steps are arranged in three: system level, component level, and implementation level. Each level was followed by validation-and-verification of that level. Whenever a level finished, and before the next level got started, its validation-and-verification routine was conducted. SDLC activities are discussed and expanded in more detail by the other standards. Specifically, four aspects, requirement management, validation and verification, and risk management, and software planning are more focused on.

Requirement Management

A medical software project’s requirement management standard depends on the software role, either software-only device or software as a part of the device and the executing platform, a generic computing device or specifically designed device [1, 27]. IEC 82,304 outlines software-only products’ safety and security requirements, and IEC 62,304 standardizes these requirements for software running on generic computing devices. IEC 60,601 family of standards discusses safety and essential effectiveness requirements of different medical and health equipment. Specifically, IEC 60,601–2-28 [28], 60,601–2-43 [29], 60,601–2-44 [30], and 60,601–2-45 [31] explain the safety requirements of radiology scanner modalities and components. In addition to safety and security requirements, the other types of requirements are also standardized, such as IEC 62,366–1, which provides a process to establish usability requirements [32].

Software testing is one of many verification activities intended to confirm that software development output meets its input requirements. Other verification activities include various static and dynamic analysis, code and document inspections, and walkthroughs [33]. However, DICOM software’s verification and simulation tools abound: dciodvfy and dcentvfy are utilities for validating the contents of a DICOM file against the DICOM standard [34, 35], dcm4che library [36]; DVTk emulates RIS environment [37]; and IHE Gazelle provides IHE actor functionalities.

Validation and Verification

Software validation is “confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled” [33]. Software verification looks for consistency, completeness, and correctness of the software and its supporting documentation as it is being developed [38]. In other words, validation tries to find an answer for “Whether the right product is under construction or not?”, and verification answers, “Whether the construction is right or not?”

Software testing is a commonly used verification method in which a system or component is examined under a specific condition, and the results are evaluated. Many standards address testing; for example, IEC 29,119 part 2 [39] standardizes the test processes. IEC 25,010 [40] provides a quality model for designing useful tests that include functional and nonfunctional specifications. IEC 24,748–3 discusses the role of testing activity in SDLC. The IEC 29,119–5 [41] explains keyword-driven testing (KDT) method as a practical testing approach. KDT applies to all testing levels (e.g., component testing, system testing, etc.) and various types of testing (e.g., functional testing, reliability testing, etc.). The primary idea of the KDT is to collect and arrange a dictionary of keywords in different levels of abstraction, then execute manual or automated test scenarios based on these keywords. The keywords should be comprehensive enough so that most, if not all, test cases can be entirely composed out of them.

Risk Management

IEC 62,304, IEC 14,971, and Food and Drug Administration (FDA) Current Good Manufacturing Practice (CGMP) [33] require manufacturers to make risk management as the core competency of their development life cycle. The insistence on risk is to prove the safety–critical properties are held and guarantee conformance to abstract specification of a safe device operation. These guidelines are also employed by the other standards like IEC 80,001 [42] family, which specifically concentrate on risk management in medical IT networks.

In medical standards, risks are classified according to the severity of potential harms; “class A” harms can cause no damage to health; “class B” harms cause nonserious injury; and “class C” harms could end up in death or a serious injury. Risk analysis and classification should be done hierarchically through all internal subsystems and external packages. This effort is dynamic and depends on thoroughness—higher risks need more action [2, 43]. The variety of medical projects reaches this goal in various approaches, and there is no “one size solution to fit all.”

Radiology Workstation Software Planning

Effective planning requires good knowledge about the project in the first place. The American College of Radiology (ACR), the American Association of Physicists in Medicine (AAPM), and the Society for Imaging Informatics in Medicine (SIIM) provide a set of technical guidelines for practitioners which can be used as a source for getting introduced to radiography scanner workflows and systematic requirements.

ACR-AAPM-SIIM practice guideline for digital radiography [44, 45] explains flexible equipment, data manipulation and management, quality control (QC), and quality improvement procedures. It includes guidelines for any digital image relevant medical system, from a single-modality or single-use system to a complete PACS infrastructure. It defines goals, qualifications of personnel, equipment guidelines, data manipulation and management specifications, quality control, and quality improvement procedures that should result in high-quality radiological care.

ACR-AAPM-SIIM practice parameter for electronic medical information privacy and security [46] recommends actions for the protection, privacy, security, and integrity of recorded patient information while allowing appropriate access to care and patient management. Policy and procedure recommendations are provided, and the available tools to ensure privacy and security are described.

The other potential source for planning is the DICOM standard. This standard contains thousands of tags which are logically modeled into objects and relationships in between them. The details related to this model are documented in part three of the DICOM standard—under the title “The Information Object Definition” [47]. This model provides a list of essential and optional data within DICOM conformant modalities. The project manager could inspire the DICOM model to understand the essence of the significant data flows within the project. However, this will not be a complete one and the other system workflows are inspired from the other sources.

Material and Methods

A new work plan for developing workstation software is proposed (Fig. 4). The new method’s rationale is to bring requirement analysis, risk management, and test management activities under the same umbrella and raise them at the same pace. The other trait of this work plan is its inception point. DICOM Information Object Definitions (IODs), Service Object Pair (SOP) accompanied with modality worklist, DICOM conformance template, IHE, IEC, ACR, and HL7 constitute central pillars of the requirement analysis.

Fig. 4.

New methodology. DICOM, HL7, ACR, and IHE profiles are used to identify use cases. For each, use case, risk analysis, and test design are accomplished in accordance with IEC standards. The output is use case, risk analysis, and test report documents

Each data and relation within these resources is a potential use case (requirement). For each identified use case, two tasks are started simultaneously:

1. Design tests

   Testers select the test design technique, and it depends on the team’s experiences and preferences. However, as proposed in IEC 29119-5, the keyword-driven testing method could be a potential standardized option. In this method, tests are categorized in multiple abstraction levels, and each of them targets a sub-unit (e.g., API, user interface) in the system. The designed tests are executed by an automated testing tool or evaluated manually. 

• 2.Risk management

  The risk-class associated with the use-case is evaluated first, and methods for risk reduction are contemplated. Generally, there are three techniques to manage risks: a) avoid risk by safe design, b) protective alternatives inside the device, c) safety information and warning on the device. After applying the selected strategy (or combination of them), the residual risk is reevaluated. If it is not acceptable, further information is gathered to determine if the medical benefits outweigh the residual risk. Suppose this evidence does not support the conclusion that the medical benefits outweigh the residual risk. In that case, the risk remains unacceptable, and the project is terminated (which is not the case for radiography scanners). The applied strategy for controlling risk has the chance of arising new risks or affect others. In that case, the same steps repeat for those risks one more time- till all the risks associated with all use-cases are revisited.

The outputs of the workflow include risks, use cases, and test charts. The format and the content of the documentation are determined by the project manager and compatible with IEC 62,304. A sample use-case chart is shown in Table 1. In this chart, each use case has a unique ID. Besides the use-case description, activation condition, successful situations, actors, and failure mode states are also noted. Not all fields are required to be available on all use cases; however, recording this information eases tracking the project's requirements. Details of the provisioned risks are recorded in the risk list document. A template of risk tracking is shown in Table 2. In this figure, plans to mitigate risk and matrices to measure the risks (if available) should be provided. Risks summary should be available at the end of the risk analysis report. In this summary, all risks before and after mitigation are summarized in the failure mode and effects analysis (FMEA) matrix [48] (Fig. 5). These matrices facilitate the project members to monitor the efficiency of risk management techniques. In this matrix, the upper red zones class C risks and require more in-depth consideration. For example, an operator may select a wrong X-ray power parameter, leading to over or underexposure on the patient. Orange blocks are class B risks (e.g., invalid lookup table (LUT) values). Most of these risks are avoidable by design and using accurate tools (e.g., DICOM library). Finally, the lower green boxes stand for class A risks like “invalid field of view shape.” The majority of these risks are informative and considered optional attributes.

Table 1.

Template use-case report. Use cases are required to be uniquely identified and relations in between them should be traceable

Use case
Use-case ID	US_PAT_IE_01
Related requirement	Connect RIS, analyze modality worklist
Description	Patient demographic information is extracted from the worklist
Precondition	RIS connection is established
Success condition	patient demographic information is extracted correctly
Failed condition	Patient demography is not available, or it is wrong
Actors	Radiology technician, RIS operator
Flow of activity	MWL fetch, MWL analyze
Alternate flow	Local patient registration

Table 2.

Risk ID template. Each risk should be uniquely identified, impact, mitigation plan, and its impact should be collected

Risk
Risk ID	RIS_PAT_IE_101
description	Incorrect patient name format. The patient name should comply with the following format FamilyName^GivenName^MiddleName^NamePrefix^NameSuffix
Impact	High
Indicator	The name parser rejects the data
Mitigation plan	Provide suggestion to the operator, to correct the format
Alternate solution	Reject the data

Fig. 5.

Failure mode and effect analysis: a summery of risk is reposted in this table. Red zones are class C, orange blocks are class B, and green zones are class A risks

Test report’s structure depends on the test tool, tested unit, and test tool. There is no unique test report format. Even IEC 29,119–5 does not offer a test template for KDT. Modern development tools generate automatic test-result tables. Nonetheless, having a documented test plan could help the team members to stay tuned regarding targeted criteria—a sample test plan document is available at [49].

System Analysis and Design

The system data model has the DICOM IODs in its core and wraps it with different data objects (e.g., authentication, logging, and local storage object models) to realize the functional requirements. A summary of DICOM IODs for digital X-ray scanner is enlisted in Table 3. Each information entity (IE) has one or more modules. Some of these modules are mandatory, while the others are optional. An example DICOM attribute of each module is shown in this table, and the complete list is available at [50].

Table 3.

Digital X-ray IOD elements

Information entity (IE)	Module	Usage	Example attribute
Patient	Patient	Mandatory	Patient’s name
	Clinical trial subject	Optional	Clinical trial site ID
Study	General study	Mandatory	Study date
	Patient study	Optional	Patient’s size
	Clinical trial study	Optional	Clinical trial time point ID
Series	General series	Mandatory	Modality
	Clinical trial series	Optional	Clinical trial series description
	DX series	Mandatory	Modality
Frame of reference	Frame of reference	Optional	Frame of reference UID
Equipment	General equipment	Mandatory	Software versions
Image	General image	Mandatory	Patient orientation
	Image pixel	Mandatory	Pixel data
	Contrast/bolus	Optional	Contrast/bolus agent
	Display shutter	Optional	Shutter shape
	Device	Optional	Manufacturer
	Intervention	Optional	Intervention sequence
	Specimen	Optional	Specimen identifier
	DX anatomy imaged	Mandatory	Image laterality
	DX Image	Mandatory	Photometric interpretation
	DX detector	Mandatory	Field of view dimension(s)
	X-Ray collimator	Optional	Collimator shape
	DX positioning	Optional	Patient position
	X-Ray tomography acquisition	Optional	Tomography layer height
	X-Ray acquisition dose	Optional	Distance source to patient
	X-Ray generation	Optional	Exposure control mode
	X-Ray filtration	Optional	Filter type
	X-Ray grid	Optional	Grid
	Overlay plane	Conditional	Overlay description
	VOI LUT	Conditional	VOI LUT sequence
	Image histogram	Optional	Histogram sequence
	Acquisition context	Mandatory	Acquisition context description
	SOP common	Mandatory	SOP class UID

An attribute value has three sources: (1) scanner equipment itself, like “software version” and “manufacturer.” These attributes are usually hardcoded/hardwired within the system. Except for developers, the other users have limited access to make changes or update them. (2) Environment in which the device is installed. For example, “institution name” is available when the scanner is installed on the site. By changing the environmental conditions, these attributes may be updated by the technicians. (3) The third is information systems (e.g., HIS, RIS). When a new examination request is registered in RIS, the examination details such as “patient’s name,” “patient position,” “KVP,” and the other examination details are sent from the RIS to the scanner. These attributes are more vulnerable to human errors and transmission loss. The remote source is not the only provider of these attributes; in special situations like trauma patients or anonymized examinations, some attributes, like patient demographics, may be provided locally on the scanner.

DICOM conformance document suggests four categories: transfer, query/retrieve, workflow management, print management SOP categories, and provider or user roles for each of them. The project’s resources and the target interoperability level determine which subset of the DICOM SOPs from each category should be available. Nonetheless, implementations of these SOPs and the other system components (Fig. 4) are required to observe IOD's integrity and security.

Risk Management

All components of the business logic tier take the risk analysis, evaluation, and control steps. Sample risks, which are categorized based on the identification source, are shown in Table 4.

Table 4.

A list of common risks of a digital radiography scanner

Category	Risk
DICOM IOD and SOP, PACS	Information model inconsistency Patient-study-series-instance model is in consistent between application entities
	Invalid value in DICOM enumerable attributes (e.g., patient laterality)
	Nonconformant DICOM UID generator. DICOM UIDs such as patient ID and accession number are not valid
	Incorrect date/time format
	Incorrect demography data format
	Presentation look-up-table format
	Corrupted pixel description. Pixel metadata such as rows and columns are not valid
	The photometric interpretation of the image pixel is not valid or correct
	Vendor specific unrecognized private tags
	The display luminescent does not match grayscale functions
	The applied compression algorithm is not valid, or the archive does not support it
	Little Endian (LE)/Big Endian (BE) or implicit/explicit format is not consistent
	The presentation intent type ( ‘FOR PROCESSING’ or ‘FOR PRESENTATION’) is not correctly specified
	The coding scheme (e.g., SNOMED-CT) is not supported by Application Entity (AE)
	DICOM VR is not consistent with software value types
	The SOP class is not compatible with device modality or it is retired
	Incorrect overlay structure
	Inconsistent multi-frame images. The target PACS does not support multi-frame DICOM file
HL7, IHE	DICOM-HL7 incompatibility
	DICOM XDS-I incompatibility
Device, environment, ACR guidelines	Actuators and robotics failure
	Uncalibrated device
	The output radiation is not correct due to power source failure or losing calibration
	Misconfiguring the peripheral equipment
	Unergonomic design
	Radiation leakage and protection failure
	Safety and security interlock failure
	The detector technical details are not valid, or the detector does not work as expected
	Human errors during installation, calibration, and application steps
	Incompatible user interface. User interface regional specifications are not compatible or readable by the users
	Technical manual, DICOM conformance, installation guide, user manual, and developer guides are not available or inconsistent

The DICOM IOD/SOP and PACS-related risks are mitigated by applying risk control mechanisms in the software design. The device-environment risks are reduced by using protective and informative warnings on the device and analyzing the equipment specifications for detecting potential risks.

Workstation software typically incorporates software and tools that are developed by unknown third parties. The software of unknown provenance (SOUP) is already used widely, but it is not created to integrate into the medical device. Test labs do not expect the development process of the SOUP or their risk analysis; however, it is required to identify how the project relies on SOUP to function and if SOUP contributes to a plan for handling SOUP risks.

Results

The proposed new workflow was developed in the course of iBEX open-source radiography scanner workstation project [15]. iBEX receives the modality worklist from RIS, processes the requested procedures, and then prepares the scanner. After finishing the examination, it sends the results to a local PACS server for archiving. For this environment, the following list of SOPs is selected:

• Verification SOP class (user and provider)

• Digital X-ray image storage—for Pres. SOP (user)

• Digital X-ray image storage—for Proc. SOP (user)

• Modality worklist information model—FIND SOP class (user)

Digital X-ray IODs are examined for risk evaluation and designing tests. iBEX provides IDevice and IAlgorithm extension mechanisms. IDevice unifies the communication channel between iBEX Core package and the device drivers (e.g., digital detector, power source, mechatronics). The IAlgorithm defines the communication channels between the IAlgorithm and custom image filtering extensions. These extension mechanisms brought up new business logic risks (e.g., malfunctioning drivers, unstable image processing modules, etc.), not related to SOPs or IODs. A summary of iBEX risks is shown in Table 5.

Table 5.

A risk matrix table before applying risk control. The risks within red zone are unacceptable and must be redeemed

During the risk analysis, design decisions are made and reported in the technical documents. For example, it has been assumed that the PACS system’s information model supports “each patient has one study, each study has only one series, and each series has one or more instances" information-model. It has also been assumed that no image compression is used, and all DICOM enumerable are hardcoded. So, the publicly exposed enumerable attributes are presented in multi-choice forms or combo boxes.

The assumptions and design decisions that are made during the risk analysis are reflected in iBEX architectural design. iBEX has a microkernel architecture (Fig. 6). The core package is responsible for basic workflows such as authentication, patient registration, and system monitoring. In this design, core communicates with the external infrastructure PACS and RIS networks through interpretation tools. These tools are responsible for translating and customizing messages. Changing the execution environment may require changing the interpreter’s configuration or replacing them with the new design.

Fig. 6.

iBEX architecture. The core package is responsible for main workflows; the other packages provide a specific functionality

The extension package manages the extensions loading, log package is responsible for tracking the system events, and storage package manages the local storage. All these packages are designed based on system requirements and follow the IEC test and development standards.

To increase the software quality, during the implementation phase of iBEX, the following guidelines are considered:

• Use common tools like DCMTK.

• Require the user to review and approve before critical operations.

• Design clean and self-explanatory user interface accompanied with measurement units’ designators to reduce the chance of misinterpretation.

• Enforce requirement for device vendors to thoroughly document every DICOM data element in their DICOM Conformance Statement

After applying these guidelines and design architecture assumptions, all the red zone risks are controlled (Table 6).

Table 6.

The residual risks after applying the risk control techniques. No risks remain in the red zone after risk control

The proposed method progresses through requirement analysis, test design, and risk assessment at the same pace. In this way, the traceability matrices are updated throughout the project timeline. A sample trace between the output user interface and DICOM attributes is shown in Fig. 7.

Fig. 7.

The new workflow provides a transparent pathway from design to the implementation

iBEX test design is based on KDT and formed based on ACR-AAPM-SIIM workflows, modality worklist, CGMP, DICOM IODs, DICOM SOPs, and IEC 29,119, the standards which are used in the requirement analysis. Keywords are categorized into two layers: the domain layer and the interface layer. Each noun in the IOD list is a candidate test term: “patient name” test, “image row” test, “generator KVP” test, and so on. Verbal phrases such as “patient registration,” “device calibration,” and “PACS communication” also constitute potential use cases; however, they may need one or more middle domain test layers. In the end, the output DICOM file is evaluated by dciodvfy to verify the DICOM conformance. Additionally, other software quality tests like memory leakage and runtime resource management are executed to measure the software’s efficiency and reliability. A more comprehensive discussion of these tests is available at [15].

Discussion

Medical software development is tightly regulated, and successful projects must show evidence that proves the necessary standards that have been successfully applied during the project development. Specifically, medical imaging systems are required to comply with the DICOM standard. In this work, a new software development approach was proposed, aiming to bridge the gap between medical manufacturing standards and DICOM standards.

Emphasis on the DICOM at the beginning of the project reduces the chance of nonconformance risk at the end. Second, one should consider that the DICOM includes thousands of tags, and in some sections, it is hard to understand [51]; however, starting from the most relevant areas and the following, the IEC, HL7, ACR, and the other regulatory bodies could speed up the design process.

DICOM conformance of radiology scanners is a relative claim; there is no full DICOM conformance. Vendors usually implement subsections of the standards relevant to their product and formally announce it in the DICOM conformance template. The proposed workflow does not ensure the conformance of a scanner in all health sites. The scanners are designed based on specific assumptions in the health center’s information network structure and configurations. Changes in the network structure or the arrangements could violate the assumptions. For example, switching from a local PACS or RIS/HIS network to a cloud-based solution may require workflows described in IHE profiles like SWF, PIR, and XDS-I.

This workflow is not the only way to achieve a DICOM conformant scanner. DICOM conformant commercial products are made by vendors who already implement their workflows that mitigate the risk. A traditional manner like implementing requirements-driven waterfall SDLC with DICOM IOD selection and pre-specified data element setting could accomplish the DICOM Conformance. Indeed, this workflow stems from the practical experiences we had on developing workstation software tools for different modalities. We have created this workflow to share it with the open-source community, especially those with a limited medical software engineering background.

The release candidate version of the workstation software should be tested at multiple levels. First, to ensure that all DICOM IODs are available and the data format is correct, validator tools such as dciodvfy and dcentvfy, and dcm4che library should be used. Scanners are planned to be part of an enterprise system, and simulators such as IEC gazelle and DVTk could help detect some nonconformance issues. Finally, to evaluate the system in action, the workstation software should be evaluated for its interoperability capacities in Connectathon events.

iBEX is an open-source digital X-ray scanner workstation software [15] designed based on the proposed method. It is intended to be extensible and vendor neutral and has some RIS and PACS communication functionalities. These design inputs, accompanied by the DICOM model and ACR-AAPM-SIIM guidelines, were implemented within the software architecture document.

One of the significant sources of the DICOM nonconformance problem is differences in the health centers’ infrastructure implementation. Also, vendors use private DICOM to transfer customized messages. To mitigate the situation, iBEX architecture incorporates interpretation tools. Based on a configuration file (.conf), these tools act as a translator between PACS/RIS infrastructure and the core package. They fill up the missing DICOM tags with default values or change the values to suit the Core package.

Conclusion

DICOM conformance is a necessity for medical radiography scanners. Manufacturers are required to provide a conformance statement to show that their products are consistent with DICOM. The proposed methodological framework brings DICOM conformance into the focus during the design and implementation of a workstation software project. This workflow provides a guideline for open-source projects to reduce the DICOM nonconformance risk of the final product. Additionally, this framework would help software designers to start their project from the right point; otherwise, they may need to spend a lot of time and effort to find an inception point for entering DICOM and the other relevant medical standards. iBEX is the first software project that employed this methodology in-house, and both software and methodology are presented to the medical imaging research community for collective development in the future, within the spirit of democratization of medical imaging hardware/software development.

Funding

This project has been funded by TUBITAK 1003 — projects 116E738 and project 116E739.

Declarations

Conflict of Interest

The authors declare no competing interests.