Development of an Open-Source System for a Bone Age X-ray Language for Unaccompanied Foreign Minors

1. Introduction

Bone age (BA) is a critical biomarker of skeletal maturity, reflecting the complex interplay of biological, psychological, and social determinants that influence osseous development [1,2,3]. The assessment of BA is indispensable for monitoring growth trajectories in pediatric and adolescent populations, particularly in the context of growth disorders or endocrine abnormalities such as precocious puberty and growth delay [4,5,6]. Moreover, BA assessment is a relevant instrument in guiding clinical decisions regarding the administration of gonadotropin-releasing hormone analogues in transgender adolescents, as it provides insights into the timing of pubertal development and the potential for further growth [7,8]. A particularly remarkable application of BA assessment lies in its role in estimating the legal age of unaccompanied foreign minors (UFM) who may lack documentation or whose age is uncertain [9,10].

The classical "inspection" method for BA assessment involves comparing X-ray images to standardized reference atlases of posteroanterior hand and wrist (PA-HW) radiographs, such as Todd’s (1937) [11], Gilsanz-Ratib (2005) [12], and the widely used Greulich-Pyle (GP) atlas (1959) [13]. The GP method is preferred in clinical practice due to its speed, making it suitable for time-sensitive situations. However, it is not without its shortcomings, notably low intrarater and interrater reliability, which can lead to variability and inconsistencies between institutions [14,15]. In contrast, the "scoring" method, exemplified by Acheson (1954) [16] and the Tanner-Whitehouse (TW, 1962) system [17], assigns specific values to ossification centers. The TW method is renowned for its high inter-rater concordance, offering superior accuracy. Yet, its complexity and time-intensive nature render it less practical in high-pressure environments [18,19,20,21]. Beyond these methodological nuances, traditional BA assessment methods face broader limitations. Predominantly based on North American and English samples, they fail to adequately represent ethnically diverse populations, such as Africans or Asians. Furthermore, these techniques often involve children from higher socioeconomic backgrounds, whose maturation rates may differ. They also overlook the global impact of improved childhood nutrition. Additionally, these methods remain labor-intensive and costly [15,18,22,23,24,25].

To address the weakness of manual radiograph readings, several automated tools have been developed. HANDX®, a semi-automated tool from the University of Southern California, was designed to reduce variability in detecting skeletal growth abnormalities [26]. Automated scoring systems like the Computer-Assisted Skeletal Age Scoring System (CASAS®) from the United Kingdom [27] and the PROI-based system® from Hong Kong Polytechnic University [28] are recognized for their precision and consistency. More recently, BoneExpert® (Visiana Aps, Denmark) has gained recognition for its accuracy and reliability across diverse ethnic groups [29,30,31]. However, key limitations of most automated BA assessment systems include their reliance on proprietary algorithms and closed-source code, which can be costly due to variable demand, raising concerns about cost-effectiveness. This dependence also restricts flexibility and customization options, thereby hindering the validity and generalizability of the systems across diverse populations and contexts, particularly among vulnerable groups [32], such as Unaccompanied Foreign Minors (UFM).

Moreover, despite significant advancements in both Open-source and proprietary software, many contemporary experiment builders primarily rely on graphical user interfaces (GUIs) or require proficiency in general-purpose programming languages. This creates barriers for users with limited programming skills [34,35]. Consequently, practitioners aiming to develop BA assessment tests without extensive technical expertise encounter significant challenges, underscoring the urgent need for more accessible solutions in this field. To address this challenge, it is essential to bridge the gap between flexibility and accuracy in BA assessment tools by advocating for a domain-specific language (DSL) as a viable solution [36]. A DSL is a specialized programming language designed for a specific application domain, offering optimized solutions through custom syntax and semantics tailored to particular tasks [37]. In the context of BA assessments, a DSL would facilitate the automation of radiograph reading by providing a standardized framework [38,39]. This approach would streamline the process and reduce the variability and errors typically associated with manual assessments.

Although a systematic review conducted following the Preferred Reporting Items for Systematic reviews and Meta-Analyses (PRISMA) [40] published in July 2023 [41], and updated in September 2024, identified the lack of a DSL for BA assessment, this study address this gap by developing an Open-source solution specifically designed for determining BA in UFM. By combining the flexibility of Open-source platforms with the accuracy typically found in proprietary systems, this innovative DSL would aim to streamline the development and automation of BA estimation. Furthermore, it would be particularly beneficial for professionals without programming expertise, significantly improving accessibility and usability in both clinical and research environments. Additionally, this tool would be of great importance to forensic physicians, providing them with a reliable and customizable system to aid in the accurate determination of BA in legal and forensic contexts.

2. Materials and Methods

2.1. Basics

The proposed approach provided a comprehensive description of the elements involved in BA assessment, utilizing an Open-Source System that incorporated the target radiograph as the primary image for analysis, along with reference radiographs from well-established atlases. These atlases offered standardized PA-HW radiographs for comparison, facilitating an accurate assessment of skeletal development. In addition, the system integrated essential demographic data, such as the individual's age and sex, which played a crucial role in determining skeletal maturation rates.

The regions of interest within each PA-HW radiograph were precisely outlined and assigned individual scores according to predefined criteria. Each radiograph underwent careful analysis, with detailed bone measurements meticulously recorded. Key parameters, captured using ImageJ (NIH, United States) [42], included: (a) radius length and width, (b) ulnar length and width, and (c) metacarpal length for digits 2, 3, and 4. In addition, essential metrics such as (d) intersesamoid distance and (e) epiphyseal width of metacarpals 2, 3, and 4 were systematically documented. These measurements, stored as pairs of bone descriptors and their corresponding numerical values, served as the foundation for the bone age estimation process. See more details in Figure 1.

Once all the required data had been entered into the designated files, the Open-Source System was executed. The input files, containing the location of the radiographic data and associated measurements, were processed to generate an estimated BA. This streamlined workflow enhanced the accuracy and reproducibility of the BA assessment by leveraging objective quantitative data to support clinical decision-making.

2.2. Sintaxis

The DSL is designed around strict word sequences, with optional terms that enhance both readability and semantic clarity. For instance, a word sequence such as DEFINE A <name> ATLAS or COMPARE RADIOGRAPHY USING THE <name> ATLAS, where <name> represents any alphanumeric string and denotes an arbitrary name, initiates a system instruction. This sequence mandates the inclusion of specific information to form a valid instruction. It is important to note that whitespace and line breaks are ignored, meaning that multiple consecutive spaces are treated as a single whitespace. However, instructions must have a space at the end to differentiate between separate commands. This syntax is an evolution of a previously established system [41], although the previous version remains recognized by the system.

Figure 1. PA-HW radiographs ROIs for BA assessment. (a) Radius length and width, (b) Ulnar length and width, (c) metacarpal length 2, 3, 4, (d) inter-sesamoid distance and (e) metacarpal epiphysis width 2, 3, 4 were systematically recorded. Source: Own work.

Figure 1. PA-HW radiographs ROIs for BA assessment. (a) Radius length and width, (b) Ulnar length and width, (c) metacarpal length 2, 3, 4, (d) inter-sesamoid distance and (e) metacarpal epiphysis width 2, 3, 4 were systematically recorded. Source: Own work.

A typical use case for this DSL is the estimation of BA using an atlas. For example, given a target radiograph of a radius bone and a single length measurement, the radiograph can be described in the system using a COMPARE instruction as follows in Table 1.

Table 1. Example of declarative syntax for a BA test using the basicatlas and a described target radiograph.

Declarative Syntax
COMPARE THE RADIOGRAPHY USING THE basicatlas ATLAS STARTING WITH GENDER male DEFINED BY A radius BONE OF MEASUREMENTS length = 2.813

Table 1. Example of declarative syntax for a BA test using the basicatlas and a described target radiograph.

Declarative Syntax
COMPARE THE RADIOGRAPHY USING THE basicatlas ATLAS STARTING WITH GENDER male DEFINED BY A radius BONE OF MEASUREMENTS length = 2.813

The COMPARE instruction requires at least one bone description and one corresponding measurement, with no upper limit on the number of bones or measurements. Other instructions, such as DEFINE, follow a similar structure. Optional terms can be introduced to improve readability. For example, one could write COMPARE THE RADIOGRAPHY instead of COMPARE RADIOGRAPHY or USING THE ATLAS instead of USING ATLAS. As mentioned previously, whitespace-like character sequences are ignored. More details in Table 2.

Table 2. Two equivalent instructions with different whitespace amount in between keywords.

Declarative Syntax
COMPARE THE RADIOGRAPHY (...) COMPARE THE RADIOGRAPHY (...)

Table 2. Two equivalent instructions with different whitespace amount in between keywords.

Declarative Syntax
COMPARE THE RADIOGRAPHY (...) COMPARE THE RADIOGRAPHY (...)

The rule also applies to line breaks. However, after a measurement pair like length = 2.813, in the latest line of Table 1, at least one whitespace is required to mark the end of the COMPARE instruction.

2.3. Semantic

The Open-system software integrates two well-established BA assessment methodologies: GP Atlas and the TW method. This framework enables precise radiographic analysis by clearly identifying each bone by name and correlating it with specific quantitative parameters, such as length and width. Furthermore, the software extends its functionality by generating synthetic bone models derived from the measurements of other bones, thereby significantly enhancing the system's adaptability and complexity in accurately modeling skeletal maturity.

This capability allows the DSL to address diverse clinical scenarios, improving the accuracy of BA assessments by utilizing available radiographic data in a structured and flexible format. In the GP Atlas approach, an exhaustive atlas with labeled reference radiographs, organized by age and sex, is essential for accurate comparison. BA is determined by identifying the closest match between the patient’s radiograph and the standardized reference atlases of PA-HW radiographs. For example, a target radiograph is compared to the atlas, ensuring that both bone structures and their corresponding measurements are aligned, as shown in Table 3.

Table 3. GP Atlas’s Declarative Syntax.

Declarative Syntax
DEFINE A greulichPyle ATLAS NAMED basicatlas WITH THE FOLLOWING RADIOGRAPHIES ONE FOR GENDER male AGE 8 WITH A radius BONE OF MEASUREMENTS length = 2.813 ONE FOR GENDER male AGE 9 WITH A radius BONE OF MEASUREMENTS length = 2.9

Table 3. GP Atlas’s Declarative Syntax.

Declarative Syntax
DEFINE A greulichPyle ATLAS NAMED basicatlas WITH THE FOLLOWING RADIOGRAPHIES ONE FOR GENDER male AGE 8 WITH A radius BONE OF MEASUREMENTS length = 2.813 ONE FOR GENDER male AGE 9 WITH A radius BONE OF MEASUREMENTS length = 2.9

Example of declarative syntax for defining a GP atlas with specific radiographic data for BA estimation. The syntax describes the creation of an atlas named basicatlas and includes radiographs for male subjects aged 8 and 9, along with radius bone measurements.

Conversely, the TW method uses a scoring system that assigns scores to predefined regions of interest (ROIs) on the patient's radiograph. The cumulative score serves as the BA indicator, eliminating the need for an atlas. However, this method requires careful assignment of scores to specific areas of the radiograph before the final computation. Each bone in the target radiograph must be mapped to a corresponding region of interest. Table 4 illustrates the declarative syntax for defining a basic scoring system in TW’s approach.

Table 4. TW’s Declarative Syntax.

Declarative Syntax
DEFINE A basicScoringSystem SCORING SYSTEM NAMED basicAssignment WITH ONE ROI DESCRIBED AS roiA WITH SCORE 5 COMPOSED OF radius ONE ROI DESCRIBED AS roiB WITH SCORE 3 COMPOSED OF ulna

Table 4. TW’s Declarative Syntax.

Declarative Syntax
DEFINE A basicScoringSystem SCORING SYSTEM NAMED basicAssignment WITH ONE ROI DESCRIBED AS roiA WITH SCORE 5 COMPOSED OF radius ONE ROI DESCRIBED AS roiB WITH SCORE 3 COMPOSED OF ulna

Example of declarative syntax for defining a TW scoring system. The syntax creates a scoring system named basicAssignment, assigning the radius to ROI roiA with a score of 5, and the ulna to ROI roiB with a score of 3.

2.3. DSL interpreter execution

The DSL interpretation process is handled by an executable program named boneage, which takes the path to the DSL file as its input argument. The instructions contained within the file are executed sequentially, following a top-to-bottom order. Upon encountering a DEFINE instruction, the system attempts to locate the file that contains the DSL definition of the atlas. If found, the atlas is loaded into the system. In cases where the scoring system method is used instead of the atlas, the system bypasses the search and directly loads the scoring system.

When a COMPARE instruction is reached, it triggers the method for BA estimation. This instruction initiates the computational process by comparing the input radiograph with either the predefined atlas or the assigned scoring system. The results of the estimation are outputted to the console. It is important to note that, at the time of execution, either the atlas or the scoring system referenced in the DSL file must already be loaded to ensure proper calculation and output of the results. See more details in Figure S1. Unified Modeling Language Class Diagram.

2.4. Software Architecture Diagram

A grammar is defined for the DSL syntax, enabling the transpilation of the DSL content [43] into legacy Ruby-based imperative syntax, or directly utilizing the Ruby programming language’s syntax [44] when appropriate. Then, the DSLBoneAge system instantiates objects that provide methods for generating radiographs, creating bone representations within those radiographs and implementing the context-switching mechanism described earlier.

As previously outlined, the system adopts a modular architecture, consisting of distinct components responsible for target radiography generation, atlas comparison, a scoring system, and radiography comparison representations. The executable, boneage,determines whether to invoke the parser for transpilation based on the file extension of the DSL input:.ae for the new syntax and.rb for the legacy Ruby syntax. Additionally, configuration files are also employed to enable or disable debugging information, as well as to manage internal file operations, such as determining the executable’s file path.

The system follows a hierarchical class structure, with the fundamental components being the representation of a bone (handled by the Bone class), which stores key-value pairs of measurements and a name, and radiographs (managed by the Radiography class), which contains pairs of bone names and corresponding Bone class instances. See Figure 2.

Figure 2. The Radiography class contains n instances of the Bone class.

Figure 2. The Radiography class contains n instances of the Bone class.

On top of the foundational layer, there are specialized classes designed for specific bone age estimation techniques, such as using an atlas or a scoring system. For the atlas technique, Atlas class includes two maps categorized by gender, each containing pairs of (age, radiography class instance) for comparison and atlas creation. It also maintains an active (age, gender) pair to facilitate radiographic comparisons. For the scoring system, the RegionOfInterest class required for the TW method, serves as a simple container of bones, each with an associated score. At last, the AtlasRadiography class holds a radiography class instance and allows for direct comparison with another radiography class instance. More details in Figure 3.

Figure 3. Classes utilized in specific BA estimation techniques: RegionOfInterest, Atlas and AtlasRadiography.

Figure 3. Classes utilized in specific BA estimation techniques: RegionOfInterest, Atlas and AtlasRadiography.

DSL-specific classes are required for the legacy syntax to ensure the correct sequence of method invocation, as outlined in the syntax and semantic sections. These include the ExtensionRadiography, ExtensionAtlas, ExtensionComparison, ExtensionScoreSystem classes. Since the new syntax transpiles into the legacy syntax, these classes are crucial. They track which keywords have been invoked and log errors in the terminal if a semantic error is detected. These classes also use lower-level classes to execute actions such as radiography creation, atlas generation, or comparison execution, each of which corresponds to its own context within the DSL. At the core of this level is the DSLBoneAge class, which maintains one instance per context and defines all the DSL methods, with their functionality varying based on the active context. See more details in Figure 5.

Figure 4. The four classes responsible of semantic behavior have the prefix Extension: ScoringSystem, Radiography, Atlas and Comparison.

Figure 4. The four classes responsible of semantic behavior have the prefix Extension: ScoringSystem, Radiography, Atlas and Comparison.

3. Results

The Open-Source system for a BA assessment language integrates an extensive suite of unit tests, developed in alignment with the Test-Driven Development (TDD) methodology [45,46]. Each class is accompanied by an expectation file that outlines the necessary tests to verify its correct functionality. This approach ensures that all classes are not only defined but also instantiable, which is essential for maintaining the overall integrity of the system.

Unit tests for the AtlasRadiography class focuses on accurately verifying the calculations of differences between reference radiographs and bone structures. These tests ensure that the comparison process produces correct results, which is critical for the system’s overall accuracy. Additionally, the test for the Atlas class assesses the functionality of comparison tracking methods and the correct handling of visited radiographs. They also validate the proper operation of age-and gender-specific functions, ensuring the robustness of these features within the system. Likewise, Bone class, the unit tests are designed to verify its correct instantiation from bone measurements relative to other bones to validate the methods for calculating length and width distances of radiological markers used. These tests are relevant for ensuring the accuracy and coherence of the measurements made by the system.

Furthermore, Radiography class undergoes extensive testing to ensure the proper functionality of critical methods, such as addBone, which must prevent the insertion of duplicate bones, and getMeasurements, which should return nil if the specified bone name is not present in the radiograph. These tests are essential for guaranteeing the class’s robustness and reliability across a range of usage scenarios. Finally, the unit tests for the DSLBoneAge class and other extension classes focus on verifying both the syntax and semantics of their methods, ensuring their correct functionality within the overall system. While these tests are extensive and involve numerous method invocations, they are essential for maintaining the stability of the system as it evolves and expands.

4. Discussion

An important aspect to consider is the inherent subjectivity in the user experience, particularly regarding system syntax [47]. Preferences for syntactic structures can vary significantly, for instance, some users prefer syntax based on delimiters such as braces or parentheses, while others may choose for more flexible approaches [48]. Ensuring clarity in the system’s intermediate steps is also critical, as transparent processes can increase user trust in the system’s results, specifically when dealing with complex data, such those derived from medical images.

Standardizing observations made from radiographs is another significant challenge. Variability in results often arises depending on the operator and the parameters used for analysis [49]. To address this, establishing a set of standard radiological measurements across different users would be important for ensuring consistency. This standardization would not only improve comparability between operators but also enhance interoperability across different medical systems, facilitating data exchange between institutions [50].

System performance is another key consideration, especially in terms of running time, which may vary based on the size of the datasets, such as the resolution of radiographs. As file sizes increase, so does the computational load, impacting the system's overall efficiency [51]. One solution could involve migrating the system to a compiled programming language, such as C++ [51,52] or Rust [53], which would allow for faster execution times by eliminating real-time instruction interpretation [54].

Finally, the lack of studies on how the system handles large datasets is a critical gap that needs to be addressed. In clinical environments, the volume of medical images processed daily can be substantial, and system bottlenecks in data loading and processing could hinder operational efficiency [55]. Simulations with datasets of varying sizes, from small images to large radiological studies, could help identify system limitations and potential optimizations, such as parallel processing or the integration of big data technologies to handle large volumes of information more efficiently [56].

The translation of a DSL should not only consider the language of the receiving country, such as Spanish, but also the languages of the emitting country, such as Wolof and Bambara [57]. This is particularly important in fields where English proficiency is not uniform among users, potentially limiting access to the benefits of these systems. By enabling interaction in the user's native language, productivity can be improved, and the likelihood of errors caused by misinterpretations can be reduced [58]. Furthermore, providing localized versions of programming interfaces or software, especially in technical areas like medical imaging, supports education and training by allowing users to focus on the technical content without the added complexity of a language barrier [59].

In the context of medical imaging, current software systems can automate measurements from radiographs using advanced image processing algorithms [60,61]. However, there is room for improvement in both precision and automation [62]. Techniques such as pattern recognition and artificial intelligence (AI) [63] could further enhance accuracy in bone structure identification and subsequent measurement extraction [64]. Additionally, deep learning models offer potential for automatically detecting injuries or malformations, optimizing clinical workflows by reducing human intervention [65,66,67].

5. Conclusions

In conclusion, the development of a DSL for BA assessment provides a streamlined, accessible solution for practitioners with limited programming expertise. This DSL simplifies the BA estimation process with a concise, user-friendly format while ensuring accuracy and reliability through a TDD approach. By enhancing accessibility and usability, this system has the potential to democratize BA assessment and significantly improve its application across clinical, forensic, and research settings, particularly for the assessment of UFM.