Evaluating Erasure Codes in Dicoogle PACS

DICOM (Digital Imaging and Communication in Medicine) is a standard for image and data transmission in medical purpose hardware and is commonly used for viewing, storing, printing and transmitting images. As a part of the way that DICOM transmits files, the PACS (Picture Archiving and Communication System) platform, Dicoogle, has become one of the most in-demand image processing and viewing platforms. However, the Dicoogle PACS architecture does not guarantee image information recovery in the case of information loss. Therefore, this paper proposes a file recovery solution in the Dicoogle architecture. The proposal consists of maximizing the encoding and decoding performance of medical images through computational parallelism. To validate the proposal, the Java programming language based on the Reed-Solomon algorithm is implemented in different performance tests. The experimental results show that the proposal is optimal in terms of image processing time for the Dicoogle PACS storage system.


I. INTRODUCTION
I In the medical field, it is necessary to establish norms or standards to share image formats between devices. Specifically, these standards cover aspects of messaging and communication between imaging equipment, such as fixed and portable X-ray equipment, ultrasound (US), single (CT) and multilayer computed tomography (MSCT), magnetic resonance imaging (MRI), positron tomography (PET), single photon emission tomography (SPET) and coronary angiography. In this regard, the National Electrical Manufacturers Association (NEMA) of the United States, along with the American College of Radiology (ACR) have contributed to the development of the norms and standards for medical image processing [1].
Transmission between medical image devices requires standards for reliable communication and storage. For this purpose, Digital Imaging and Communication in Medicine (DICOM) is a standard protocol for communication among information systems. In addition, DICOM is a medical image storage format that appears to be a solution for interoper-ability problems between various devices, including medical purpose hardware [2]. To determine the different applications or treatments of DICOM files, an analysis of the literature was carried out. As a result, several lines were found to, in some way, deal with DICOM files. In this sense, [3] and [4] focused on artificial intelligence (AI) and machine learning (ML), respectively. Likewise, [5], [6], [7] and [8] used deep learning (DL) techniques for to identify and process medical images. Regarding contrastive learning (CL), in [9] and [10], it was applied to medical image segmentation. Furthermore, in [11] and [13], the authors used a set of units called artificial neurons, which are connected and used to transmit signals to each other [13]. Finally, regarding high-quality image reconstruction, in [14], geometric parameters were applied to improve image quality. a part of Dicoogle PACS that enables the full recovery of any damaged, corrupted, or lost DICOM file. This plugin can recover the original file without errors and it is a faithful copy of the first one. Therefore, a hash certificate is issued stating that the faithful copy mentioned above is 100% identical to the original file. The originality check of the recovered file is performed through the application of SHA-512 (Secure Hashing Algorithm).
Based on the above, the main objective of the paper is to propose a solution to maximize the performance of the developed storage plugin. This solution is developed by applying parallel computing to the encoding and decoding techniques on DICOM files, considerably reducing the processing times. The DICOM standard integrates the Picture Archiving and Communication System (PACS), which has become the main storage approach for medical images, such as radiology, ultrasound imaging and nuclear medicine [15]. In this regard, the term medical information system arises, which refers to medical image communication and storage as a solution for the image processing technology management system of a hospital environment. An important advantage of PACS is that it substantially reduces both the radiation doses to patients and the operating costs of the radiology department [16].
A serious problem that exists in institutions performing diagnostic imaging (Dx) in the interconnection network or equipment is the blockage caused by the high data flow in the network. This flow is provided by the transfer of DICOM images to the devices that make up a DICOM network called Service Class Users (SCU) and Service Class Providers (SCP). In [17], the transactions of physicians with respect to DICOM archiving within a clinical image management system (CIMS) in support of patient care are described. In addition, the utilization of images in a neurosurgical oncology practice was audited, and there were 400 requests for 233 imaging studies during 297 sessions. Fifty percent were current studies, and 50% were historical studies. Every day, medical imaging modalities generate new data, and the growth in recent years has been exponential. The storage and distribution of the data is managed by PACS, but current technologies face new challenges, such as high availability. However, the massive amount of data requires a huge local infrastructure to handle the load and fault tolerance, which can be costly [18]. The system developed in our research offers features that fully match the DICOM standard in terms of data integrity [19], immutability and fault tolerance [20]. Moreover, an intelligent cache replacement policy suitable for PACS was proposed in [21]. This policy combines the logistic regression (LR) algorithm with the classical least recently used (LRU) cache replacement policy. Furthermore, in [21] the LRLRU algorithm is PACS-oriented and identifies variables affecting file access probabilities by mining medical data.
The PACS market is heterogeneous, with several PACS vendors having deployed installations in healthcare centers. The DICOM query and retrieval interfaces provided by PACS have multiple variations related to implemented SOP (service object pair) classes, transfer syntaxes, extended negotiations, attributes and match types. These variations can integrate a new DICOM consumer with a PACS complex and make it time consuming. Although most PACS products provide a DICOM conformance statement with a description of their query and retrieval capabilities, there is no collective analysis describing the various query, retrieval capabilities and variations of imaging systems [22]. Additionally, another important aspect concerns system security. With respect to this, from a practical perspective, PACS-specific security measures should be considered along with measures applicable to the Information Technology (IT) infrastructure. The purpose of this is to strengthen the security of PACS systems that are accessible from the internet [23].
In addition, in [24], a computer component was developed to detect renal carcinomas in abdominal tomography images based on the Watersheds Transform. This component supports the diagnosis of renal cell carcinoma (RCC) made by specialists in health centers where the Medical Image Storage, Transmission and Visualization System (XAVIA-PACS) was deployed. Additionally, in [24], an experiment was developed comparing the results with images from an international database (KiTS 2019), and the diagnostic value was analyzed by leading medical specialists. Perhaps the most difficult task for any new PACS administrator is to understand and gain experience with the DICOM standard. DICOM is a run-length encoded binary standard developed exclusively for medical imaging and may require hexadecimal editors to simply read it [25]. DICOM may be the most important area for a PACS administrator to master, and this mastery increases in difficulty as DICOM standards grow in number and complexity. The most effective way to learn DICOM is through a hands-on approach, which the open-source clinical image and object manager (DCM4CHEE) provide [25]. DCM4CHEE is a collection of open-source applications and utilities for healthcare institutions. These applications have been developed in the Java programming language for performance and portability, which supports implementation in the Java Development Kit (JDK) [25].
At this point, it is worth mentioning that in recent years, the increasing need for durability and efficiency in file storage has made erasure codes (ECs) a desirable new research target. To emphasize the importance of using erasure code algorithms, implementations of these algorithms in distributed file systems are mentioned below. For example, the Reed-Solomon (RS) erasure code (n; k) algorithm [26] stands out among the abovementioned algorithms. The RS algorithm performs the processes of encoding given n original data blocks and decoding to recover lost data from k redundant blocks. According to the above, it is important to mention that erasure coding-based distributed storage systems are increasingly used by storage vendors for big data. These offer the same reliability as data replication, with a considerable decrease in the amount of storage to maintain data reliability.
However, the problem arises when the storage system nodes are distributed over a geographically extensive area [27]. The storage systems with erasure codes are cost-effective and are deployed in large data centers to achieve high reliability with low storage cost [28], [29]. The Reed-Solomon erasure code [26] is part of a well-known family of erasure codes used in Google's ColossusFS [30], Hadoop Distributed File System (HDFS) [29], [31], and other storage systems [32], [33].
To highlight the importance of using erasure code algorithms, implementations of these algorithms in distributed file systems are mentioned below. An Erasure-Coded Data Archival System for Hadoop Clusters (aHDFS) leverages parallel and pipelined encoding processes. The encoding processes enable data acceleration of archival performance in the Hadoop Distributed File System (HDFS) on Hadoop clusters. aHDFS leverages three-way data replicas and MapReduce programming models in the Hadoop cluster to increase performance [34].
Furthermore, in [35], the authors evaluated the performance of the Jerasure [36] and GPU-accelerated Cauchy Reed-Solomon G-CRS [37] erasure code libraries. In the research presented in [38], algorithms combined with erasure codes and the Ant Colony Optimization-based Multiple Data Node Update (ACOUS) scheme were used. Moreover, [39] demonstrated that there is an increased demand for the scalability of the Bitcoin blockchain by applying erasure codes [39]. In addition, Facebook's HDFS-RAID system implements Reed-Solomon encoding and decoding [26] in the format of a distributed Redundant Array of Independent Disks (RAID) file system running on top of HDFS [31]. Moreover, previous versions of HDFS achieved fault tolerance by replicating multiple copies of data, such as RAID-1 on traditional storage arrays. Furthermore, the HDFS-EC (storage system implementing erasure code) system developed and implemented by Cloudera substantially reduces storage overhead while achieving similar or better fault tolerance by using parity cells such as RAID-5 [40].
Having exposed the above implementations and before the introduction to the erasure code algorithms, it is important to mention that HDFS exclusively used 3x replication for fault tolerance, which means that a 1 GB file uses 3 GB of storage space. With EC, the same level of fault tolerance for a 1 GB file can be achieved using only 1.5 GB of storage space. As a result, this feature is expected to considerably change the total cost of ownership for Hadoop usage [41], employing erasure coding to reduce storage cost compared to replication while maintaining high fault tolerance [42]. Moreover, there are technologies that can be exploited to improve performance and resource optimization in a medical imaging environment. For example, the plugin for faulttolerant storage uses the Reed-Solomon erasure code [26] [43] [44] [39] open source Backblaze library and the DICOM image files through the Dicoogle PACS system presented in this research.
Dicoogle is a PACS platform to develop new kinds of DICOM repositories, allowing us to make extensions such as storage in different technologies. It offers a full set of DICOM services and a web application to support the search, quick view and management of the PACS archive. Furthermore, some implementations using medical modalities are described in [45]. These implementations can receive patient data and they are related either to the study from the Hospital Information System (HIS) or to the Radiology Information System (RIS). The DICOM modality worklist [2] is the missing electronic link that transfers this critical information between the medical modalities and either to the HIS or the RIS.
For the development of this study, extensive research was carried out by locating the main contributions of Dicoogle PACS related to fault tolerance [20]. The results showed that this problem has not been widely studied, and the absence of studies applied to the Reed-Solomon erasure code was shown. The background described above is the basis for the motivation of this research. Specifically, our motivation is to guarantee the error-free retrieval of medical images in the Dicoogle PACS system in the shortest possible amount of time. In summary, in this research, a fusion of the technologies described above is performed, and for the encoding and decoding process, the Reed-Solomon erasure coding algorithm is used.
The organization of this paper is as follows. Section II presents a survey of the Dicoogle PACS architecture, Section III describes the Reed-Solomon erasure code algorithm, Section IV mentions the configuration of the proposal, Section V discusses the tests and experimental results, and finally, Section VI presents the conclusions.

II. DICOOGLE PACS
PACS have been widely developed and implemented in hospitals and are now a commodity for healthcare professionals. However, their installation, maintenance and utilization remain challenging due to their heavy structures, which are usually supported by centralized computational solutions [46].
Dicoogle [46] is an open source PACS image storage and communications system; the code is free access and can be downloaded from [47], as developed primarily by UA. PT BIOINFORMATICS [48] and BMD Software [49]. Dicoogle can be used to support three different usage scenarios: production, research, and teaching. Its modular architecture enables the rapid development of new functionalities due to the availability of a Software Development Kit (SDK) [50]. Specifically, the Dicoogle SDK was created to simplify the development of new functionalities of specific use modules that are developed by other researchers. These researchers are known as the Third Party, and the goal is to ensure the compatibility of new SDK developments with the Dicoogle platform.
In a nutshell, to develop a new functional module, developers must move the package they build to the Dicoogle plugin directory (see Fig. 1). After this process, Dicoogle automatically loads the new modules at startup. Next, the VOLUME 4, 2016 Dicoogle SDK makes all operations related to storage, querying, and indexing immediately available through its internal application programming interface (API) [50]. The overall architecture of Dicoogle (see Fig. 1) replaces the traditional relational database with a more agile process in the indexing and retrieval mechanism. Dicoogle was designed to extract, index, and store all metadata presented in DICOM files from patient studies, including private labels [50].
The paradigm introduced by the Dicoogle project empowers queries over a set of distributed repositories, which are logically indexed as a single agile unit. In [51], the authors described a cloud-based relay service [52] that acts as a communication bridge between different institutions, allowing the community to access, share and discover image records [51]. Dicoogle was proposed in [53] as an architecture for cloud [52]-based PACS archives that provides data privacy, integrity and availability. The solution proposed in [53] is independent of the cloud [52] provider and core modules. Operational metrics for various medical image modalities were tabulated and compared for Google Storage, Amazon S3 and LAN PACS [53]. In [54], the development and validation process of the Dicoogle system in two healthcare centers is described. This system represents a new approach capable of collecting and indexing information from different PACS archives, developed on top of Dicoogle, which allows the construction of multiple views on data repositories according to the DICOM standard in a flexible and fast way. The methodology developed in [54] can contribute to improving the use of DICOM metadata stored in the scattered PACS of radiology departments. If this improvement were not introduced, DICOM metadata would not be used in productivity, efficiency, and quality initiatives in radiology departments [54].
Another implementation based on Dicoogle is concerning [55], where the architecture and implementation of a query-based profiled content-based image retrieval (CBIR) system is proposed. In this solution, CBIR profiles allow the specification of both a distance function and the set of features that must be present for that function to operate. The CBIR retrieval system has been implemented as a mechanism to cope with increasing volumes of information present in medical image repositories [56].
A case study is presented in [57], which describes a process applied to the metadata held by 19 storage units of a PACS of a Portuguese Hospital Center composed of three sites. In total, more than 36 million images were collected in [57], coming from more than ten modalities. The fusion and reconciliation procedure presented in [57] has proven to be robust and efficient. It demonstrates that it is possible to merge metadata collected from multiple PACSs into a single unified view, preserving the relationship among patients, studies, and images, which is essential for analyses performed on a large scale of medical image repositories from multiple institutions [57].
Recent research [56] describes Dicoogle as a software framework that has enabled developers and researchers to prototype and nimbly implement new functionality, leveraging integrated digital imaging and communications services in DICOM medicine. This complete implementation of a PACS archive is highly extensible due to its plug-in-based architecture and out-of-the-box functionality, thus enabling the exploration of large DICOM datasets and associated metadata. Clearly, these features make the proposed solution very interesting for prototyping, experimentation and bridging functionality with implemented applications [56].
In [58], the software architecture of Dicoogle based on different plugins is presented, which includes a storage plugin with two approaches, one aimed at local storage and the other at storage in the cloud [52]. Additionally, the Dicoogle software architecture is supported by a documentbased indexing system and peer-to-peer (P2P) protocols. Furthermore, an architecture of a web pathology PACS fully compatible with DICOM standard data and communication formats is proposed in [59]. The solution includes a PACS archive responsible for storing whole slide image data in DICOM format for whole slide imaging (WSI) and provides a communication interface based on the latest DICOM web services. The other component is a zero-footprint viewer that runs in any web browser. It consumes data using standard PACS archiving web services [59].
In [60], the secure registry mechanism for medical image repositories was designed and instantiated as an extension of a well-known open-source archive. A new web services layer was implemented to provide a solution for DICOM Web protocols for storing, searching and retrieving medical image data.
In [61], the Dicoogle environment is described, with particular emphasis on its learning package, available resources, and the impact of the platform on research and academia. In [61], the authors began by presenting an overview of its architectural concept, the most recent research supported by Dicoogle, some observations obtained from its use in teaching, and statistics on the use of the software worldwide. Additionally, a comparison between the Dicoogle platform and the most popular open source PACS on the market is presented in [61]. Furthermore, current solutions to the problem of medical image storage and management are discussed. Moreover, a solution based on a private network of nodes is presented to overcome problems such as privacy, redundancy, and high availability.
The main problem of data storage in DICOM format is that a radiological examination can have a data volume of more than one gigabyte and consists of thousands of images [62]. In Moldova, in 2015, the DICOM Network project was launched [62], which aims at providing access to radiological studies to medical staff with appropriate access rights, as well as giving patients access to their personal radiological examinations. The system now collects and processes more than 500 gigabytes of data each month [62].
In [63], an overview of the current state of the art of nonrelational databases was also studied, discussing the strengths and weaknesses of this type of database in our use cases. In addition, the authors of [63] focused on some implementations of this type of database in the medical imaging use case. Furthermore, in [63], these implementations were presented in such a way that they were integrated into the Dicoogle open source PACS.
Finally, in [64], a framework for the integration of multiple microscopy image modalities into the PACS-DICOM universe, including numerous metadata elements, was proposed. In [64], the authors developed a proof-of-concept system for validation purposes that, integrated with the open source PACS Dicoogle, provides image storage, metadata indexing, and visualization.

III. REED SOLOMON ERASURE CODE
The Reed-Solomon (RS) erasure code [43] [44] [39] is an erasure code algorithm with properties necessary for reliable file storage and retrieval. It is simple to implement while being a reliable technique. This guarantees the recovery of a complete data item, even when part or parts of the original stored data file are lost or unavailable.
In [65], a study of the operation of the encoding and decoding processes of the erasure code algorithm is carried out. In short, [65] proposed an erasure code storage system that encodes k data blocks or disks into m blocks or disks when up to m data blocks or disks fail. Their contents are decoded from the available blocks or disks to recover the total information (see. Fig. 2).
RS algorithms are used in distributed storage systems and provide efficient implementation and high fault tolerance capability for a given level of redundancy [66]. Storage systems have grown to the point where failures are inevitable, and those who design the systems must plan in advance so that information is not lost when failures occur. The main technology for protecting data from failure is erasure coding, which has a history of more than 50 years [65]. In [67], an analysis of erasure code replication is performed, and they define some situations where full file replication is preferred. In addition, in [67], the switching point of preferring full file replication or erasure code replication is studied and characterized. Furthermore, considerations in building erasure code replication systems are also discussed in [67]. VOLUME 4, 2016 5 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2022.3187119 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ As mentioned in [68], several versions of RAID technology have been used in recent years aimed at providing file redundancy as well as reliability. Erasure coding is standard practice for systems that reliably store data, and many of them use Reed-Solomon erasure code [43] [44] [39]. Based on the above, centralized and networked storage systems have grown to the point where the fault tolerance provided by RAID-5 is no longer sufficient. In addition, RAID-6 storage systems protect k data disks with two parity disks so that the k + 2 disk system can tolerate the failure of any two disks [69]. On the other hand, RAID [68] embedded in Linux uses Reed-Solomon erasure code and has a carefully tuned Reed-Solomon implementation in a high-level C language that is part of the RAID module. Additionally, the cloud computing service, Microsoft Azure and the Facebook storage system use Reed-Solomon [70].
In [71] and [72], several proposals for hardware-based EC schemes have been found to take advantage of the advanced computational capabilities of modern data centers. The Backblaze Reed-Solomon erasure code library is an open source [73]. Url's available download [74] has a software license created at the Massachusetts Institute of Technology (MIT) [74], which is a free software license that can be used in free and commercial projects.

IV. IMPLEMENTATION
In this section, we describe two steps for the configuration process. First, the hardware configuration for the tests performed is described. Second, the software configuration of the native storage plugin implemented in Dicoogle PACS [60] is described.
In the software case, the Reed-Solomon erasure code algorithm from the Backblaze Library [73] was used, where values for k and m are assigned according to the encoding and decoding configuration (see Fig. 3). The following elements are observed: 1) Network Attached Storage (NAS) of the medical images, 2) Modality medical as the image generating element, and 3) Workstation A and Mobile Workstation A and B as devices for visualization of images generated by Modality medical and stored in the NAS. For the connectivity of the architecture, a Cisco Catalyst 2960-XR Gigabit Ethernet Switch was used, and for the wireless connectivity, a Cisco Aironet AIR-CAP1702I-A-K9 Access Point was used, applying the IEEE 802.11n protocol at the 2.4 GHz frequency.
On the other hand, tests were performed with DICOM files using FDR Smart X [75], which is the new Fujifilm  X-ray system. Likewise, in this research, a Toshiba Tomographer model TSX-031A, ActivionTM16, was used. This equipment uses a 16-slice helical computed tomography (CT) system that supports the exploration of the entire human body [76]. The system generates a minimum of 32 slices per 1.5 seconds using the selectable slice thickness multiwire detector (SSMD). Regarding the architecture shown in Fig. 3, Workstation A and Mobile workstation A and B correspond to devices for displaying DICOM images.

B. SOFTWARE
The main proposal in this work lies in the implementation of a plugin for erasure code through the Reed-Solomon erasure code algorithm of the Backblaze library. In comparison with the Dicoogle PACS architecture [58], Fig. 4 shows the location of the plugin implemented in the proposal. Once the Backblaze Reed-Solomon erasure code library was evaluated, a native plugin was implemented in the Dicoogle PACS storage layer to guarantee fault tolerance. The main scheme of the algorithm is shown in Fig. 5. Java language was used for the development, and threads were used to improve the performance of the algorithm. The characteristics of the development are mentioned below: • The extension of the files used in the storage plugin was 6 VOLUME 4, 2016 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and  .dcm, which corresponds to the DICOM medical image format. These files are created by using the Fujifilm FDR Smart X-ray devices and the Toshiba Tomograph model TSX-031A. • Regarding services and add-ons, it is possible to start and/or stop running services in real time. For this reason, a port is defined for use in Dicoogle PACS. • For each DICOM file, a SHA512 hash function is used. This is done to perform SHA512 hash verification to avoid duplicity of information through a data structure. • The SHA512 hash is stored in a NoSQL DynamoDB database. The implementation of DynamoDB in the storage plugin was provided as a java executable.jar file. The proposal can run on different operating systems, such as Windows, Linux, macOS and other Java compatible platforms. • The protection provided by erasure coding can be represented in simple form by the following equation: n = k + m, where k is the original amount of data and m represents the redundant data added to provide protection against failures through erasure code. • Backblaze Reed-Solomon is an erasure coding library for calculating fault tolerance and then using it to reconstruct files. When a DICOM file has been stored in VOLUME 4, 2016 7 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2022.3187119 Dicoogle PACS, the storage plugin can split it into 4, 6 and 10 fragments of the same size for each DICOM file. This process is called encode. Subsequently, 2, 3 and 5 additional fragments are created, which maintain parity. This results in a total of 6, 9 and 15 fragments for each configuration (i.e., 4, 6, 10 fragments). With this configuration, it is possible to reconstruct the original file from 4, 6 and 10 fragments. This process is called the decode of the 6, 9 and 15 fragments.

V. RESULTS
As part of the proposal put forward in this research, the built environment required the configuration of the Reed-Solomon erasure code storage plugin implemented in Dicoogle PACS. In this sense, two types of experiments were carried out using Encode and Decode. In the encoder process, settings regarding the original data block size k and the parity block size m were used for the recovery of any lost blocks. For the Decode process, data recovery is performed from the m parity blocks to ensure reliability. The main results for both processes are presented in Figs. 6, 7, 8, 9, 10, and 11. In all cases, the x-axis represents the data block size in MegaBytes (MB), and the y-axis represents the time consumption in milliseconds for each block size. To validate the recovery of lost blocks, we induced failures in the configuration to obtain the times and resource consumption (memory and processor) in the transmission/reception of DICOM images. Likewise, in all configurations from 1 to 8, threads are used. Having explained the above, different tests with respective configurations are presented below: Test 1.-In this test, DICOM files of various sizes (see. Table 1) containing part of the lower extremity of the human body were used. The results of this configuration are shown in Fig. 6. In this figure, the time consumed by each strand in a ratio of 4 data blocks and 2 parity blocks (i.e., RS (4,2)) for complete data recovery in the case of loss of 1 or 2 data blocks can be observed. In the case of encryption, a consumption of approximately 0.9 seconds was observed using 8 threads with the most significant group of files.
Test 2.-In Fig. 7, reference is made to the 2-fault tolerance results of the DICOM file group of Test 1. In this figure, it is observed that the Decode process consumes approximately 0.8 seconds when 8 threads are used for the recovery of 1 or 2 data blocks.  Test 3.-In this test, a second set of DICOM files was used (see. Table 2). Figure 8 shows the time consumed by the RS (6,3) configuration as a function of the number of threads for the encoder. In this case, it is observed that the time consumption is close to 1.5 seconds using 8 threads for the original maximum data block size of 1024 MB.
Test 4.-In Fig. 9, reference is made to the results of tolerance of up to 3 failures of the group of DICOM files of test 3. It is observed that the Decode process consumes approximately 1.2 seconds when 8 threads are used for the recovery of 1, 2 and 3 data blocks. This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2022.3187119  Test 5.-In this test, a third set of DICOM files was used (see Table 3). Figure 10 shows the time consumed by the RS configuration (10,5) as a function of the number of threads for Encode. This configuration allows loss of 1 and 5 data blocks of the complete DICOM file. In this case, it is observed that the time consumption is close to 2.5 seconds using 8 threads for the maximum block size of 1024 MB.
Test 6.-Finally, Fig. 11 shows the results of tolerance from 1 to 5 failures of the group of DICOM files of Test 5. It is observed that the Decode process consumes approximately 1.9 seconds when 8 threads are used for the recovery of up to 5 data blocks.   Before ending this section, it is important to highlight the research results. In this sense, first, the approaches presented in Test. 1 are taken as a reference. These allow us to reduce the data processing time for k = 4 and the redundancy m = 2, reaching reductions in both encoding of 0.9 seconds and decoding of 0.8 seconds. This shows that the research results of the developed storage plugin are optimal in terms of processing time. Moreover, the use of different threads with the same characteristics has been established for all cases (see Tests. 1-6, and Figs. 6, 7, 8, 9, 10 and 11) k = 4, 6, 10 and m = 2, 3, 5, revealing a storage efficiency of 66.66 %.
Second, the results of this research show that the Reed-Solomon erasure code algorithm can be successfully applied to Dicoogle PACS. In other research, the applications of Reed-Solomon erasure code are for environments other than the one in this paper, showing a gap in its applications to Dicoogle PACS. In this regard, it is worth mentioning that the study carried out in [77] used values of k = 2, 4, 8 and m = 2, 2, 2. Likewise, in [78], the authors used k = 6, 10 and m = 3, 4. Moreover, in [79], the authors used the following values: 1) k = 8, 9, 10 and m = 2, 2) k = 8, 9, 10 and m = 3, and 3) k = 8, 9, 10 and m = 4. Finally, in [80], the authors used k = 12 and m = 4. Until now, the use of the k = 10 and m = 5 techniques had not been considered. VOLUME 4, 2016 9 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2022.3187119 However, this paper does introduce its use to establish equal storage efficiency conditions for the developed plugin.

VI. CONCLUSIONS
The development of the research is based on parallelization through the use of threads in the execution of encoding and decoding. It is observed that the use of threads reduces the execution time in the encoding and decoding processes. In addition, the implementation of the Reed-Solomon algorithm in the different processing configurations in the Dicoogle PACS storage plugin is performed.
The main contribution of this research is that a considerable improvement in fault tolerance is achieved through erasure code algorithms in the Dicoogle PACS medical image storage system. This means supporting a fault tolerance configuration of m = 2, 3, 5, which is superior to the proposal made in the native FlexProtect technology of the OneFS operating system [81]. Simply put, the OneFS operating system uses Reed-Solomon coding to provide redundancy and data availability. FlexProtect technology supports data protection on up to four simultaneous failures of entire nodes or individual units of the configuration. This means that FlexProtect is more efficient than the RAID-6 commonly used today when the aim is to provide data availability [82]. This comparison is made in terms of the maximum level of RAID-6.
Furthermore, in the proposal presented in this paper, a hash function defined in [83] has been incorporated into the storage plugin, which is a method to generate keys to univocally represent a DICOM file or a set of data of a DICOM file. In this case, this process operates mathematically as a SHA-512 compression function that operates on a dataset of any length, and as a result, generates a digital key of a fixed size that is independent of the size of the original DICOM file.
As future research work, the current proposal inspires us to explore other implementations using dedicated graphics processing technologies such as GPUs [84] to take advantage of the GPUDirect technology supported by the Nvidia GPU [85].