the digital imaging and communication in medicine ( dicom ) standard   has been commonly used for storing , viewing , and transmitting information in medical imaging . because of its structure and open character dicom was developed to ease the exchange of data between different manufacturers , but it also enables data sharing between institutions or enterprises for clinical research or clinical practice . a dicom file not only contains a viewable image that holds all of the pixel values but it also contains a header with a large variety of data elements . each data element is represented by a unique tag with specific values and data types . the tag of an element is written with two hexadecimal numbers indicating its group and element number . these meta - data elements include identifiable information about the patient , the study , and the institution . sharing such sensitive data demands proper protection to ensure data safety and maintain patient privacy . there are two methods to de - identify patient - related information in a dicom header . the first method is anonymization which removes information carried by header elements or replaces the information with random data such that the remaining information can not be used to reveal the patient identity at all . the other method , pseudonymization , is implemented by replacing the most identifying fields within a data record using one or more artificial identifiers that could be used by authorized personnel to track down the real identity of the patient . this method is most frequently used in clinical analysis , processing , and research [ 46 ] since good clinical practice requires that , should additional findings be encountered that are essential for the well - being of the patient , it should be possible to somehow track the real identity of the patient in order to inform him or her about these findings . numerous tools have been built to perform the task of dicom data de - identification in order to fulfil the requirements of patient data protection . each tool introduces its own de - identification profiles to remove or replace a selection of header elements and , therefore , produces its own specific outcomes from the data de - identification process . in this work , ten non - commercial ( free ) dicom toolkits were selected and tested for their de - identification effectiveness and completeness to determine the tools ability to remove a patient 's personal health information ( phi ) from the dicom header . this work also provides further consideration of dicom toolkits that could perform data de - identification to meet regulatory requirements . various applications , libraries , and frameworks have been developed for handling , viewing , transmitting , and processing dicom data . these toolkits offer many features useful for clinical practice or clinical research purposes such as dicom data validation , image viewing and analysis , pacs server , and converting and modifying , including de - identifying , dicom data . similar work examining seven free dicom software toolkits and their ability to de - identify 38 tags that contain patient or study information using their default and modified configurations has been previously presented [ 7 , 8 ] . the candidates were gathered through an internet search to obtain as many free toolkits as possible using a number of dedicated information sources on the web [ 912 ] and also through a web search engine with the search term main inclusion criteria were the ability of the applications or frameworks to perform de - identification and availability as freeware or an open source tool that can be downloaded and installed or is accessible as an on - line , web - based , anonymization service . other inclusion criteria were based on how commonly the toolkits were used in practice , by noting practitioner toolkit preferences via direct discussion or via answers posted in online discussion forums or the like . the continuity of a toolkits development was also considered as inclusion criteria ; it was determined by the update history of the software and active communication about the software . selected toolkits were not only end - user applications but also several frameworks , providing features allowing users to perform de - identification directly . all selected tools were evaluated on a workstation running microsoft windows xp service pack 3 and tested to de - identify the elements of a fifty header elements were chosen to be de - identified since they contained data that could be used to reconstruct a patient s real identity individually or in combination with other elements ( table  1).table 1fields in the dicom header defined to be de - identifiedtag idtag name0008,0020studydate0008,0021seriesdate0008,0022acquisitiondate0008,0023contentdate0008,0024overlaydate0008,0025curvedate0008,002aacquisitiondatetime0008,0030studytime0008,0031seriestime0008,0032acquisitiontime0008,0033contenttime0008,0034overlaytime0008,0035curvetime0008,0050accessionnumber0008,0080institutionname0008,0081institutionaddress0008,0090referringphysiciansname0008,0092referringphysiciansaddress0008,0094referringphysicianstelephonenumber0008,0096referringphysicianidsequence0008,1040institutionaldepartmentname0008,1048physicianofrecord0008,1049physicianofrecordidsequence0008,1050performingphysiciansname0008,1052performingphysicianidsequence0008,1060nameofphysicianreadingstudy0008,1062physicianreadingstudyidsequence0008,1070operatorsname0010,0010patientsname0010,0020patientid0010,0021issuerofpatientid0010,0030patientsbirthdate0010,0032patientsbirthtime0010,0040patientssex0010,1000otherpatientids0010,1001otherpatientnames0010,1005patientsbirthname0010,1010patientsage0010,1040patientsaddress0010,1060patientsmothersbirthname0010,2150countryofresidence0010,2152regionofresidence0010,2154patientstelephonenumbers0020,0010studyid0038,0300currentpatientlocation0038,0400patientsinstitutionresidence0040,a120datetime0040,a121date0040,a122time0040,a123personname fields in the dicom header defined to be de - identified two scenarios were defined to perform the de - identification . first , the default setting of the tools were used , meaning that the installed tools were used to perform the process as is , without any customization . then , customized settings were defined to obtain the best possible configuration to perform the de - identification process . for each test , the unchanged elements were observed to determine whether any of the potential identifying information was retained . the test was performed using a dummy dicom image ( fig . the 50 tag elements to be de - identified by various selected dicom toolkits were filled with dummy information or the string  should be anonymized  dummy dicom image . the 50 tag elements to be de - identified by various selected dicom toolkits were filled with dummy information or the string  should be anonymized  the dicom header elements of the dummy dicom file were filled with the string should anonymized  when possible , except for those containing date or time values . using this dummy dicom file , the de - identified dicom files were checked to determine whether they still contained elements as listed above with the original value or the given string . 2flowchart of the method to test dicom de - identification tools flowchart of the method to test dicom de - identification tools ten tools were selected , namely conquest dicom software , rsna clinical trial processor ( ctp ) , dicom library , dicomworks , dvtk dicom anonymizer , gdcm , k - pacs , pixelmed dicomcleaner , tudordicom , and yakami dicom tools . table  2 shows the general features offered by the selected tools . several of them have been previously introduced , implemented and reported on individually in the literature [ 2326 ] . there are also several frameworks which have features to perform the de - identification but which were not included in this comparison since they can not be used directly as a stand - alone application.table 2selected dicom toolkitsnameplatformtype of distributionuser interfacefunctionsource avail.programming languageyear updaterequirementsdoc/ user manualdicomworkswindowsfreewareguiapplicationnn / a2007*os : microsoft windows systemsykpacswindowsfreewareguidisplay , pacs client , servernn / a2009 * os : windows 2000/xp * processor : >  =  pentium iii ( 800  mhz ) * monitor with 1024x768 pixel resolutionyconquest dicom serverwindows , linuxopen sourceguilibrary , pacs serveryc / c++2010 * os : windows nt/2000/xp / vista / win7/ linux * 1024x768x256 display . * tcp / ip functioningydvtk dicom anonymizerwindowsopen sourceguilibrary , applicationyc#2011 * os : microsoft windows xp / vista / windows7 * .net 2.0 frameworkydicom librarywindows , macintosh , linuxfree onlineguilibrarynn / a2013n / aypixelmed dicomcleanerwindows , macintosh , linuxopen sourcecommand - line utilitydisplay , library , utilityyjava2013 * java runtime ( jre ) 1.5 or newer * microsoft windows xp/2000/windows 7/linux / mac os xytudordicomwindows , macintosh , linuxopen sourceguiutility/ application , processoryjava2013 * java runtime ( jre ) 1.5 or newer * java imageioyctpwindows , macintosh , linuxopen sourceguiutility/ application , processoryjava2013 * java runtime ( jre ) 1.5 or newer * java advanced imaging imageio toolsygdcmwindows , macintosh , linuxopen sourcecommand - line utilityutility , libraryyc # , c++ , python2013 * opensslyyakami dicom toolswindowsfreewareguiutility/ application , pacs clientnn / a2013 * os : windows7/ vista / xp/2000 * .net 2.0 framework * directxy selected dicom toolkits all selected tools are easy to install by following a step - by - step installation wizard . additionally , some require other supporting applications , frameworks , or runtime environments to be pre - installed , depending on what type of programming language in which they were developed . toolkits developed using java will need a java runtime to be pre - installed . a net framework is needed for applications that are developed using c#. some toolkits require other , more specific , applications to be pre - installed to support the complete process of reading or processing the dicom files . for example , tudordicom and ctp also require additional java imageio tools   to be present on the system to be able to read and process the compressed dicom files . the gdcm installation under microsoft windows requires a win32 openssl   to be pre - installed , while yakami needs directx to be present . all required pre - installations are available freely from the web from their respective manufacturers . a modifiable setting , in this case the ability to adjust the de - identification profiles , is important for an application to meet a user s more specific needs . dvtk provides two profile selections to perform the de - identification , in a simple or complete way . in the other five tools , customization can be done using the gui provided by the applications , inserting scripts into text file , or using command - line arguments . however , not all toolkits provide customizable de - identification profiles . conquest , dicom library , dicomworks , and kpacs have a fixed profile for the de - identification process . using both default and customized configurations , two scenarios were performed to determine to what extent the profiles could provide a secure de - identification by observing the remaining original values of the defined 50 elements . these elements were selected based on their likelihood of being the cause of a data breach when exposed to a third party , either by the element itself or combination with other elements . from the tested applications , only dicom library can de - identify all of the defined elements using its default setting , while another four can perform this task using user - customized profiles . these four tools are ctp , gdcm , tudordicom , and yakami dicom tools . in addition to the header de - identification , yakami dicom tools , pixelmed dicom cleaner and ctp provide the ability of removing information  burned in  into the image pixels by blacking out a certain region of the image . the success rate in de - identifying the dicom header using the default setting provided by the toolkits is shown in fig .  3 , while fig . 4 shows the success rate using the advance setting.table 3summary of comparison of the de - identification toolkitnamede - identification profilesde - identification featuresde - identify 50 elementscustomizableprofilesconfigurationmultiple filesautomaticpixel blackoutdefaultcustomizedconquest dicom servernfixedn / ay , study / seriesnnnn / actpydefined , element or group selectiongui or text file inputy , directoryyynydicom librarynfixedn / ay , directoryynyn / adicomworksnfixedn / ay , study / seriesynnndvtk dicom anonymizeryfixed profiles selectionguiy , directoryynnngdcmydefined , element selectioncommand options/ argumentsy , directoryynnykpacs anonymizernfixedn / ay , directoryynnn / apixelmed dicomcleanerygroup selectionguiy , files / study / seriesnynntudordicomyelement selectionguiy , directoryynnyyakami dicom toolsyelement selectiongui or text file inputy , files or directoryyynytable 4the results of dicom header element de - identification by ten dicom toolkitsfields / tagstag nameconquestctpdicom librarydicom worksdvtkgdcmkpacspixelmedtudoryakami0008 , 0020study datenyynnnnnnn0008 , 0021series datenyynnnnnnn0008 , 0022acquisitiondatenyynnnnnnn0008 , 0023contentdatenyynnnnnnn0008 , 0024overlaydateyyyyyyyyyy0008 , 0025curvedateyyyyyyyyyy0008 , 002aacquisitiondatetimeyyynnnnnnn0008 , 0030studytimenyynnnnnnn0008 , 0031seriestimenyynnnnnnn0008 , 0032acquisitiontimenyynnnnnnn0008 , 0033content timenyynnnnnnn0008 , 0034overlay timeyyyyyyyyyy0008 , 0035curvetimeyyyyyyyyyy0008 , 0050accession numbernyynyynynn0008 , 0080institution namenyyyyynnyn0008 , 0081institution addressnyynyynnyn0008 , 0090referring physicians nameyyyyyyyyyy0008 , 0092referring physicians addressnyynyynyyn0008 , 0094referring physicians telephone numbernyynyynyyn0008 , 0096referring physicianidsequencenyynnnnyyn0008 , 1040institutionaldepartmentnamenyynyynnyn0008 , 1048physicianofrecordnyynyynyyn0008 , 1049physicianofrecordid sequencenyynnnnyyn0008 , 1050performing physicians namenyynyynyyn0008 , 1052performing physicianid sequencenyynnnnyyn0008 , 1060nameof physician reading studynyynyynyyn0008 , 1062physician reading studyid sequencenyynnnnyyn0008 , 1070operators namenyynyynyyn0010 , 0010patients nameyyyyyynyyn0010 , 0020patientidyyyyyynyyn0010 , 0021issuerof patientidnyynnnnynn0010 , 0030patients birthdateyyynnynynn0010 , 0032patients birthtimenyynyynyyn0010 , 0040patientssexnyynyynnyn0010 , 1000otherpatientidsnyynyynyyn0010 , 1001otherpatientnamesnyynyynyyn0010 , 1005patients birthnamenyynnnnyyn0010 , 1010patientsagenyynyynnyn0010 , 1040patients addressnyynnnnyyn0010 , 1060patients mothers birthnamenyynnnnyyn0010 , 2150countryof residencenyynnnnynn0010 , 2152regionof residencenyynnnnynn0010 , 2154patients telephone numbersnyynnnnyyn0020 , 0010studyidnyyynynynn0038 , 0300current patient locationnyynnnnynn0038 , 0400patients institution residencenyynnnnnyn0040 , a120datetimeyyynnnnnnn0040 , a121dateyyynnnnnnn0040 , a122timeynynnnnnnn0040 , a123personnameyyynnnnyynfig . 3success rate of the toolkit to de - identify fifty dicom header elements using the default settings . the numbers presented in the bars are the total score using the default de - identification settingfig . 4success rate of the toolkit to de - identify fifty dicom header elements using the advanced settings . the numbers presented in the bars are the maximum success rate obtained after customization of the de - identification settings summary of comparison of the de - identification toolkit the results of dicom header element de - identification by ten dicom toolkits success rate of the toolkit to de - identify fifty dicom header elements using the default settings . the numbers presented in the bars are the total score using the default de - identification setting success rate of the toolkit to de - identify fifty dicom header elements using the advanced settings . the numbers presented in the bars are the maximum success rate obtained after customization of the de - identification settings only two toolkits provided a high success rate of de - identification when using the default setting ( ctp and dicom library ) , while an additional four achieved a high success rate after careful customization ( gdcm , pixelmed , tudordicom , and yakami dicom tool ) . dicom library is the only tool that achieves a 100  % success rate at its default setting . the success rate of the ctp to de - identify the dicom header using its default profile is 98  % , which increases to a complete de - identification of the specified elements under custom settings . pixelmed could deliver a high success rate of 98  % using its advance setting while it failed to do so in its default setting ( only 64  % ) . meanwhile , dvtk provided less than a 44  % success rate using its default setting and the optimization capabilities did not allow much improvement , resulting in a success rate of 48  % . only five out of ten selected free dicom toolkits could de - identify all of the defined dicom elements properly with a 100  % success rate . four of them could only achieve this after improvement using advance settings with user controlled de - identification protocols . one toolkit achieved a 98  % success rate after manual improvement of the de - identification settings . only two out of ten toolkits were able to give a success rate above 90  % using the default setting , with all remaining tools performing at less than 65  % , of which four even achieved success rates of 26  % or less . various toolkits have been built to de - identify dicom data , either as free or paid applications . paid toolkits have advantages such as customer support and development updates , while free versions less likely to have consistent updates . however , the free versions are not necessarily of poorer quality . many of the free toolkits are provided in an open source version , which means that the tools are open for improvements either by users or related communities . the elements to be de - identified in this work were chosen based on their potential for being the cause of a data breach when exposed to a third party , either by the element itself or in combination with other elements . even though all of those elements will not be filled in a daily routine , a recommendation for removal or modification of those elements is still required due to the possibility of practitioners giving values to the elements , as determined via our observation of several cases where those elements contained certain values . the values are most likely the appropriate values required by the elements and could possibly reveal a patient s identity . the selection of 50 dicom tags was made based on a careful inspection of possible fields containing sensitive information in combination with the information of supplement 142 of the dicom standard . this selection was , therefore , based on experience of the authors which could influence the quality score . the selection of software packages included in this work was based on a number of parameters . . however , to obtain the most relevant results , software packages were selected on criteria that would identify their frequency of download and use . based on these criteria , the software packages most frequently used and , thus , probably with the highest impact in daily practice , were selected . a default configuration of a de - identification profile allows users to quickly run a required task as intended without in - depth knowledge of the tool itself . nevertheless , the default configuration does not always provide de - identification of sensitive patient - related information within the dicom data for a specific research project or for educational purposes . the customizable settings will provide more flexibility and improved tool performance , especially if the image data are needed for a specific research project or for educational purposes . the selection of element tags was done by considering two kinds of elements , direct and indirect patient information fields , consisting of 17 and 33 elements , respectively . direct patient information fields have information that directly points to patient identity , including patientsname , patientid , issuerofpatientid , patientsbirthdate , patientsbirthtime , patientssex , otherpatientids , otherpatientnames , patientsbirthname , patientsage , patientsaddress , patientsmothersbirthname , countryofresidence , regionofresidence , patientstelephonenumbers , currentpatientlocation , patientsinstitutionresidence . the elements listed above are recommended for de - identification to prevent the elements containing date or time related to patients , data acquisition , or other process being used , alone or in combination with others , to reveal the real patient identity that may lead to the breach of a patient s important data . in order to de - identify the elements , dummy date or time values the support of configurable profiles should provide options to the user to perform a specific de - identification process more freely . several methods were introduced by the different toolkits , such as adding , modifying or removing header elements one element at a time or using a list of actions , defined by the tools or manually , to be conducted on several elements simultaneously . some tools require script files to be manually written or adapted using a text file editor or employ a user interface to generate these script files from within the application . the ability of a tool to de - identify multiple files automatically can be a significant advantage . this feature will ease the de - identification process for a set of images which is usually required when de - identifying data from cross - section - based modalities such as computed tomography ( ct ) and magnetic resonance imaging ( mri ) . tools lacking this capability would require one to manually perform the task one file at a time , resulting in a more time consuming method which is cumbersome for the user and more prone to errors . customizable or user - defined selection of de - identification profiles will be a major advantage when compared to standard settings , because otherwise nobody will check which of these dicom tags will be de - identified . supplement 142 in the dicom standards provides a profile within clinical trials de - identification that has become the standard of dicom data security . nevertheless , to have the full list of the tags in supplement 142 to be de - identified would still be difficult to do manually . instead , we provided 50 elements considered to be the minimum requirements for a third party to reveal the identity of a patient . furthermore , the recommended software has also provided a configuration claiming to conform to supplement 142 in the dicom standard . the ability to blackout the embedded information written on the images is an advantage in identity protection . in some cases , information , for example , in the case of storage of secondary capture images or with frame - grabbed ultrasound examinations . a de - identification of the dicom header could become meaningless when such information is still present within the image itself . this feature is only supported by yakami dicom tools , pixelmed dicom cleaner and ctp . these private tags can be used by the manufacturer to provide additional , proprietary information within the dicom header . unless the tags contain important information for further processing , it is recommended that those elements should be removed . private tags are typically documented to provide additional information related to the device / manufacturer . however , the additional data which may contain patient related information can also be added manually or automatically , for example , when private tags are not displayed in the dicom viewer . however , as mentioned above , private dicom tags may also provide sensitive patient data . although these data are not visible through the dicom viewer , they are available for viewing using the tag reader and may be used by other parties to reveal the patients identity . the utilization of a framework or of library tools such as gdcm is limited since those tools are intended to be used for advanced purposes , integrated into another application as a toolkit . however , the provided functionality is sufficient for practical use . other known frameworks that provide a de - identification process are dcm4che [ 29 , 30 ] and dcmtk . dcm4che is a framework developed using the java programming language that is claimed to have better functionality compared to the others . however , this framework is not directly suitable for practical use , but can be used by a software developer to be integrated into new software tools . the rsna clinical trial processor ( ctp ) tested in this study is one of the toolkits that use this framework as part of the software . the low de - identification performance of several applications might be caused by the main role of the application itself . for example , the tools that were intended to be an image viewer are likely to have low priority for development and implementation of the image de - identification process . on the other hand , an application that is addressed as a dicom data processor will have more advanced options to perform the de - identification task since that is one of its intended uses . however , the uploading of images to be de - identified by the service should be considered further since the process is done outside the domain of the sender . this means that even though the source files are claimed to be de - identified at the client side , the implementation of an unsupervised process involving uploading to a third party should be utilized with care and checked with hospital security regulations . using this kind of service may cause a security breach due to the possibility that unmodified parts of data still contain sensitive information . it might , thus , not be allowed according to the security policies of most institutions since it is unknown what exactly happens with the uploaded files at the server side . furthermore , the files could be retained at the server for some unknown period of time without the uploading party being aware of this storage . even though online , web - based anonymization services are not ideal for the transfer of such confidential data using standard transfer protocols , there are still possibilities to make such methods acceptable , either by moving the services to a more secure line or transfer only data without burnt - in information within the images . however , although the transfer is claimed to be secure , information that is not processed by such service , i.e. , burnt - in information within the images themselves , can still reveal patient identity . we suggest that the use of online services without full control from the user should be avoided as much as possible . the challenge with the blackout of regions is that it is a fully manual process . when annotations are made on the image , e.g. , in ultrasound , the location of this information will vary and in some cases manually entered annotations could be positioned at several places or on top of the actual image this calls for extra attention when ultrasound images are involved and instructing imagers involved in studies not to include annotations that are only two out of ten free available dicom de - identification toolkits had a success rate of de - identification higher than 90  % using the default setting . all remaining tools performed with a success rate lower than 65  % , of which four only achieved a success rate of 25  % or less . free dicom toolkits should , therefore , be used with extreme care when de - identifying sensitive data since they have a high risk of disclosing personal health information , especially when using the default configuration . four out of ten tools are not recommended to be used in de - identifying dicom data since they could cause serious threats to patient privacy . in case optimal security is required , rsna ctp is recommended for its high level of customization to perform de - identification to exactly meet the regulatory requirements .
purposeto compare non - commercial dicom toolkits for their de - identification ability in removing a patient 's personal health information ( phi ) from a dicom header.materials and methodsten dicom toolkits were selected for de - identification tests . 
 tests were performed by using the system s default de - identification profile and , subsequently , the tools ' best adjusted settings . 
 we aimed to eliminate fifty elements considered to contain identifying patient information . 
 the tools were also examined for their respective methods of customization.resultsonly one tool was able to de - identify all required elements with the default setting . 
 not all of the toolkits provide a customizable de - identification profile . 
 six tools allowed changes by selecting the provided profiles , giving input through a graphical user interface ( gui ) or configuration text file , or providing the appropriate command - line arguments . using adjusted settings , 
 four of those six toolkits were able to perform full de-identification.conclusiononly five tools could properly de - identify the defined dicom elements , and in four cases , only after careful customization . 
 therefore , free dicom toolkits should be used with extreme care to prevent the risk of disclosing phi , especially when using the default configuration . in case optimal security 
 is required , one of the five toolkits is proposed.key points free dicom toolkits should be carefully used to prevent patient identity disclosure. each dicom tool produces its own specific outcomes from the de - identification process. in case optimal security is required , using one dicom toolkit is proposed .