Standardizing imaging findings representation: harnessing Common Data Elements semantics and Fast Healthcare Interoperability Resources structures

Abstract

Objectives

Designing a framework representing radiology results in a standards-based data structure using joint Radiological Society of North America/American College of Radiology Common Data Elements (CDEs) as the semantic labels on standard structures. This allows radiologist-created report data to integrate with artificial intelligence-generated results for use throughout downstream systems.

Materials and Methods

We developed a framework modeling radiology findings as Health Level 7 (HL7) Fast Healthcare Interoperability Resources (FHIR) observations using CDE set/element identifiers as standardized semantic labels. This framework deploys CDE identifiers to specify radiology findings and attributes, providing consistent labels for radiology report concepts—diagnoses, recommendations, tabular/quantitative data—with built-in integration with RadLex, SNOMED CT, LOINC, and other ontologies. Observation structures fit within larger HL7 FHIR DiagnosticReport resources, providing output including both nuanced text and structured data.

Results

Labeling radiology findings as discrete data for interchange between systems requires two components: structure and semantics. CDE definitions provide semantic identifiers for findings and their component values. The FHIR observation resource specifies a structure for associating identifiers with radiology findings in the context of reports, with CDE-encoded observations referring to definitions for CDE identifiers in a central repository. The discussion includes an example of encoding pulmonary nodules on a chest CT as CDE-labeled observations, demonstrating the application of this framework to exchange findings throughout the imaging workflow, making imaging data available to downstream clinical systems.

Discussion

CDE-labeled observations establish a lingua franca for encoding, exchanging, and consuming radiology data at the level of individual findings, facilitating use throughout healthcare systems.

Importance

CDE-labeled FHIR observation objects can increase the value of radiology results by facilitating their use throughout patient care.

Background and significance

Radiology reports are an information-rich document, detailing complex imaging findings, assessments, and recommendations. However, integrating this information remains a challenge, owing to heterogeneous reporting styles and the absence of a uniformly accepted standard for structured data.^1,2 Previous integration efforts have included ontologies such as the Radiology Society of North America’s (RSNA) RadLex lexicon, which offers standardized terminology.^1,3–5 However, adoption remains inconsistent, and the vision of automatically driving clinical care from radiology reports remains elusive. No standard accepted framework yet exists that systematizes existing reporting standards to allow data from radiology reports to inform clinical care.

The joint RSNA/American College of Radiology (ACR) Common Data Element (CDE) project has established standard semantics for exchange between clinical, research, and quality improvement systems. CDEs define standard tags that specify and label clinical entities and their attributes. Essentially, CDE definitions establish standard descriptions of the properties of imaging findings, including the acceptable range of values, and provide standardized tags for labeling results describing them. CDE sets identify an overarching theme or specific finding and CDEs label the specific attributes of a finding identified by a CDE set. For example, a CDE set for liver lesions defines elements for anatomic location, shape, size, and texture, among other attributes. These definitions offer a standard terminology that could facilitate the structuring of imaging report data.³

The vision for the RSNA/ACR CDE project is consistent with the NIH CDE project.⁶ CDE definitions are limited to the context of observations derived from imaging studies. The published CDE schema has additional metadata fields that make the definitions useful for imaging (eg, specify applicable imaging modalities). Additionally, the project accepts CDE submissions from the entire radiology community internationally rather than being limited to NIH-recognized entities.⁷ The CDE project is overseen by a committee of members appointed from both major US radiology societies (RSNA and ACR). The CDE review process is modeled after journal peer review, with the standard being to reflect appropriate real-world usage rather than to establish a fixed benchmark of practice. Submission is open to all stakeholders—vendors, subspeciality societies, and individuals. Submitted sets first go through a staff check to ensure that our author and standardization guidelines have been followed. They are reviewed by a member of the committee and once approved are sent to the editor for publication. Draft sets are sent to the online repository at several steps throughout the process. Maintenance of CDE content runs similarly to open-source projects, where requests for modification can be submitted by members of the community, with a low threshold for appending to existing models and a higher threshold for changes that deprecate existing definitions.

CDE definitions integrate ontological information featuring predefined terminology such as that defined in the RadLex, SNOMED CT, and LOINC ontologies.^1,5,8,9 Because they are openly accessible, they can be deployed by reporting software and other radiology software tools to allow for structured descriptions of findings with common labels and values. Using natural language processing (NLP) to associate CDE identifiers with unstructured text can allow for standardized reporting “mini templates” that assist radiologists in providing complete, interchangeable descriptions of the findings they describe.⁴ The CDE project seeks to provide a semantic foundation for completeness and consistency in representing imaging findings. CDE definitions can also be used in any representational data model including FHIR, OMOP, and arbitrary databases that support key value pairs. The CDE schema and review process are compatible with the OHDSI vocabulary principles, especially in being use-case driven, enforcing persistence, and emphasizing openness.¹⁰

Leveraging CDE definitions in a data model for findings described in radiology reports requires a structure to associate data with semantic identifiers. The observation resource defined by the Health Level 7 (HL7) Fast Healthcare Interoperability Resources (FHIR) offers such a structure. Radiology reports describe a diagnostic service, including the radiologist-generated findings and impression.¹¹ The observation structure fits within the larger HL7 FHIR DiagnosticReport resource, which combines broader clinical context (ie, patient, order, and exam-level information) with structured individual findings, organized as concept/value pairs.^11–13 Therefore, radiology reports could be represented by FHIR DiagnosticReport resources containing observation resources detailing individual imaging findings. In this context, CDEs could provide consistent labels for the components of the report—findings, diagnoses, recommendations, tabular/quantitative data (eg, texture analysis, composition data, lesion dimensions)—allowing them to be identified, understood, and used by other clinical systems.

Accordingly, we propose a framework that models radiology findings as HL7 observation objects using RSNA/ACR CDE set and element identifiers as standardized semantic labels. This CDE-labeled observation structure is suitable for representing radiology findings from many sources: structured data input, artificial intelligence (AI) generation, or extraction from unstructured report text and paves the way for greater downstream utilization of radiology results.

Materials and methods

CDE as a data model for radiology findings

The CDE project standardizes radiology findings by specifying sets of discrete questions and corresponding possible answers, facilitating data exchange across studies and institutions.¹⁴ CDE identifiers function as computer-readable data labels, links to additional ontologies, and specifications of acceptable values to which labels can be attached.^15–17 The CDE project provides semantic identifiers without specifying how implementers might incorporate CDE tags into radiology workflows and their output. Real-world use of CDEs would require implementation software to translate radiologists’ decisions into CDE-labeled data for exchange and archiving.

The CDE model has 3 levels of organization: set, element, and value. Sets align with clinical scenarios, measurement groups, or individual findings (eg, typical head CT findings for acute stroke, body composition quantification, or full characterization of a pulmonary nodule, respectively) and can be of variable complexity, ranging from simple presence/absence to complete tumor/node/metastasis-level malignancy staging. Elements may belong to multiple sets and describe a single component of the finding/clinical scenario including especially constraints on acceptable values. Elements can label numeric values like size and quantity or refer to constrained categorical values like location, classification/grading, density/signal characteristics, or enhancement pattern. For numeric properties, the definition might include the specifications of units and minimum and/or maximum values. Categorical properties specify allowed responses (values). For example, a “margin” element could define values of “smooth,” “lobulated,” “ill-defined,” “spiculated,” and “unknown,” each with its own unique identifier. Definitions at each (set, element, value) level may also be associated with other ontologies (eg, SNOMED CT, RadLex, LOINC).

Each set, element, and value is identified by a unique string in the namespace centrally maintained at an open repository (https://radelement.org), where definitions are accessible via an application programming interface (API).¹⁸ The body of available CDEs grows over time governed by the ACR/RSNA committee with a model fashioned after peer review.

Structure of a set definition

In the centrally maintained repository, sets referring to a clinical scenario, finding, or measurement group specify an identifier (eg, RDES9865 for “radiology data element set”) and metadata including description, authorship, references to literature, and connections to external ontologies. Each set also lists member element definitions, each of which also has an identifier (RDE1234 for “radiology data element”), metadata, and a specification of acceptable values for numeric and categorical structures. Categorical elements specify a unique identifier for each valid answer. For example, a “Presence” element (RDE1234) could define values: “absent,” “present,” “unknown,” or “indeterminate” (with codes RDE1234.0, RDE1234.1, RDE1234.2, and RDE1234.3, respectively). Within the context of a single radiology report, 1 or more CDE sets would be applied, depending on the clinical context. For example, a CT chest report for lung tumor staging may include sets describing tumor characteristics, standard staging criteria, different types of metastatic disease, and lymphadenopathy in addition to other findings.

Uniting CDEs with FHIR observations

Encoding radiology findings as discrete data for interchange between systems requires 2 components: structure and semantics. CDE definitions have been designed to provide semantic identifiers for both a finding and its component values. The FHIR observation resource definition provides a structure for representing machine-readable results.

We propose coupling the FHIR observation structure with CDE semantics as a model for integrating discrete imaging findings.^18,19 First, a universally unique observation ID is stored under “Observation.identifier,” labeled with DICOM “observation-uid” to preserve specificity and consistency. Next, the set identifier is stored as “Observation.code.” If the set definition includes body parts, they map to“Observation.bodySite” and with RadLex or SNOMED CT identifiers. The data structure then uses “Observation.component” to contain the values associated with each element. Observation.component becomes an array of code-value pairs (“Observation.component.code” and “Observation.component.value”), where codes contain element IDs corresponding to individual finding attributes. The representation of the value depends on the element type: “valueInteger” for integer values, “valueString” for decimal values, and “valueCodeableConcept” set to the value ID for categorical values. Implementations can capture additional data, such as the series and image number, as additional code-value pairs within Observation.component using DICOM-standard identifiers rather than CDE identifiers.

Results

Anatomy of an observation: example coding structure

The proposed structure is illustrated by representing an observation of a pulmonary nodule using the observation resource (see Table 1). A UID of “urn: oid: 2.25.293638943492893970490299793280.5.9.114” is stored under the Observation.identifier structure (where the identifier is defined/labeled according to the DICOM standard). The applicable set (“Pulmonary Nodule”) is identified by code “RDES195” and stored under the Observation.code element.¹⁸ The anatomical location of the nodule is specified in the Observation.bodySite attribute—“lower lobe of the left lung,” indicated by the code “RID1338” from the RadLex/ACR Common Anatomic Locations systems. A radiology result containing such data structures (eg, as part of an FHIR DiagnosticReport) would enable external systems to reliably identify that the radiologist is describing pulmonary nodules in specific anatomic locations, each with a reliably unique identifier. Note that other coding systems can be integrated into this scheme as well—for example, the SNOMED CT code for pulmonary nodule will be included in the CDE set definition, and an encoding system could choose to include that associated code in the observation structure to further enhance interoperability. (Note that explicitly including the SNOMED CT code in the observation structure is optional since the code is available as part of the CDE set definition in the repository.) Using current technology, which lacks such a framework, radiology results are not readily accessible at the level of individual findings; NLP would be required to attempt to extract a subset of this information from the radiologist-generated free text.²⁰

Table 1.

Example FHIR Observation resource labeled with Common Data Element semantic identifiers.

Observation element	Value		Note
identifier	urn: oid: 2.25.293638943492893970490299793280.5.9.114		DICOM standard unique identifier for the finding of the pulmonary nodule using
code	RDES195 (“pulmonary nodule”)		CDE set identifier
bodySite	RID1338 (“lower lobe of the left lung”)		RadLex/ACR Common Anatomic Location identifier for finding location
focus	urn: 1.2.840.10008.434879483244		Tracking UID, used to associate observations representing the same lesion/scenario across exams
component	Code	Value
	RDE1717 (“Presence”)	RDE1717.1 (“present”)
	RDE1301 (“Composition”)	RDE1301.0 (“solid”)
	RDE1302 (“Size”)	“6.0”	Note that decimal values are indicated with strings in FHIR
	RDE1304 (“Location”)	RDE1304.4 (“left lower lobe”)

Abbreviations: CDE = Common Data Element; FHIR = Fast Healthcare Interoperability Resources.

The component section expresses values for specific lesion attributes as code-value pairs. The nodule’s presence is indicated with CDE ID RDE1717 and the value RDE1717.1 (“present”); its composition with RDE1301 and the value RDE1301.0 (“solid”); its size with RDE1302 and the value “6.0”; and its location with RDE1304 and the value RDE1304.4 (“left lower lobe”). Note that though RDES195 does not have a body site defined, the definition of location is supplemented with ontological links, in this case with reference to the “RID1315” RadLex/Common Anatomic Location code. Further, the SNOMED code for the lower lobe of the left lung will be included in the CDE’s value definition and could be explicitly included in the observation structure. This component data enables consumers of radiology results to recognize not only the presence of different kinds of radiology findings but also the specific properties of individual findings, which can then be recognized and used by downstream clinical systems.

This combination of structure and semantics can represent radiology findings from many sources. For example, as radiologists dictate findings into a report, an NLP tool may capture them and structure them in this format. Alternatively, a radiologist interacting with a structured reporting or decision-support tool, such as those from the ACR Assist project, could store outputs in the fashion described.²¹ AI tools that automatically detect findings in image data should also seek to represent their results using this format to promote interchange. Figure 1 demonstrates the spectrum of sources that might use such observations to represent a pulmonary nodule with a corresponding CDE structure and corresponding ID codes. Regardless of their source, CDE-labeled observations generated using this framework would share the same structure and semantics, facilitating interchange. Figure 2 shows an example representation of a pulmonary nodule using this framework. Figure S1 demonstrates an example of encoded information for a CDE set and observation represented by an FHIR JSON file.

Figure 1.

Framework for representing radiology findings as CDE-labeled Observations. CDE-labeled FHIR Observations can be a universal representation for exchanging and consuming content in radiology reports. Consider the example of a pulmonary nodule seen on a CT chest exam. CDE-labeled Observations may be generated de novo by a radiologist dictating a report for the CT Chest exam, populated by AI results tasked with detecting nodules, or extracted from current or prior report text (eg, if monitoring known nodules longitudinally). Observations (center box) represent the individual components in a radiology report with contained values, leveraging the observation resource defined by the HL7 FHIR standard. CDEs (right box) incorporating specific ontologies can represent findings, diagnoses, recommendations, quantitative data, and other elements. In this example, the set defines the finding “pulmonary nodule,” and elements of that set allow representation of its component descriptors such as the location, size, and composition. This framework uses the standard HL7 Observation structure as the “grammar” and CDE Set and Element definitions as the “vocabulary” for representing radiology findings. AI = artificial intelligence; CDEs = Common Data Elements; FHIR = Fast Healthcare Interoperability Resources; HL7 = Health Level 7.

Figure 2.

Expanded example CDE-labeled Observation encoding radiology findings for a pulmonary nodule. Detail is shown of both the JSON-based CDE set definition and the JSON-based FHIR observation object. An abbreviated version of the pulmonary nodule CDE set (https://radelement.org/home/sets/set/RDES195) and its component elements is shown, illustrating the basic structure of these definitions, including connections to other ontologies via index codes. The structure of a CDE-labeled FHIR Observation is also shown, demonstrating that the observation references the CDE set definition and has components with keys referring to CDE definitions. CDE = Common Data Element; FHIR = Fast Healthcare Interoperability Resources.

In addition, in the interest of tracking the progression or resolution of findings over sequential radiology studies, the Observation.focus can be used to attach a tracking identifier by referencing DICOM “tracking-uid” coding.²² A tracking UID uniquely identifies the observation as part of a series of snapshots of the imaging appearance of a specific clinical entity, allowing longitudinal tracking. For example, each time a patient has a liver MRI, the observation representing the hyper-enhancing liver lesion in segment 8 of the right lobe of the liver can be assigned the same tracking UID, which would allow comparison of its component values (size, enhancement dynamics) across time. Another example is shown in detail in Figure S1, which builds on the same example of an FHIR structure representing an observation of a pulmonary nodule using the observation resource, with the unique identifier noted as DICOM UID (eg, urn: oid: 2.25.293638943492893970490299793280.5.9.114), with the initial observation resource specifying pulmonary nodule size as 8 mm. A tracking UID (eg, urn: 1.2.840.10008.434879483244) assigned to the initial instance of finding would specify the initial size of the pulmonary nodule. If nodule size increases on subsequent radiology reports, observations are created reflecting the change in nodule size; the tracking UID remains the same (urn: 1.2.840.10008.434879483244), associating the observations across imaging exams. The tracking identifier allows multiple observations of the persistent entity to be associated as a sequence, enabling monitoring for changes in size or other pertinent information longitudinally over multiple radiology reports. This too would represent a significant improvement over current state tools which are hampered by the lack of a standard methodology for representing a clinical entity/finding across exams.

Case study: CDE-encoded findings in context of imaging workflow

CDE-labeled radiology findings represent 1 component in a framework for representing data associated with clinical radiology exams, integrating the inter-related information from the EHR, Picture Archiving, and Communication Systems (PACS—the system used by radiologists to view, archive, and exchange image data), third-party apps, and other software in radiology workflow. Consider the following example detailing the role of CDE-labeled radiology findings along the imaging workflow (corresponding workflow is shown in Figure 3; JSON representations are shown in Figures S1-S4).

Figure 3.

Workflow diagram demonstrating the role of CDE-encoded radiology findings. (1) A patient presents to the clinic and provides history of smoking, which is documented under “social history.” The history is formatted as an FHIR observation. (2) The patient undergoes a screening chest CT exam and an imaging study FHIR resource is created. (3) Images from the CT chest study are routed to the appropriate AI solution, which identifies a pulmonary nodule. AI results are formatted as an FHIR Observation, tagged with the appropriate CDE set and element identifiers for the nodule itself and its component attributes. (4) The radiologist opens the CT chest study and is presented with the clinical history of “smoking” and a representation of the AI pulmonary nodule result. (5) The radiologist marks a region of interest of the pulmonary nodule, confirming the finding, and provides additional descriptive characteristics (size, composition, location, etc.), which are integrated with the AI-based values and coded as a new CDE-tagged observation. The radiologist also assigns a LUNG-RADS score, documented as a second CDE-tagged observation referencing the initial pulmonary nodule observation. (6) The final DiagnosticReport resource references all patient and imaging study observations, and the radiology report is routed to the EHR. AI = artificial intelligence; CDE = Common Data Element; FHIR = Fast Healthcare Interoperability Resources.

• A patient presents to the clinic and reports a history of smoking, which is documented in the EHR under “social history” (Figure 3, step 1).

• The patient undergoes a screening CT chest based on the reported clinical history. An imaging study FHIR resource is created as the images are stored on PACS (Figure 3, step 2).²³

• The images are routed to the appropriate AI algorithm, which identifies a pulmonary nodule (Figure 3, step 3). The AI result is formatted as an FHIR observation tagged with appropriate CDE codes to identify the result as a pulmonary nodule and label its attributes (Figure S2). This differs from current practice, where no widely adopted standard format exists for formatting AI results. Also note that if other algorithms had also detected findings, those findings would be represented using the same schema.

• When the radiologist opens the CT chest study, any AI results are recognized and presented with the clinical history of “smoking” (Figure 3, step 4). Both components are integrated in the radiology report as observations. Unlike current state tools, general-purpose tools can handle the management of AI results at reporting time since they will use this new schema.

• As the radiologist reviews the images and marks a region of interest (ROI) at the pulmonary nodule (Figure 3, step 5), the nodule’s other characteristics (presence/absence, location, size, morphology) are integrated with the AI results and encoded as a new CDE-tagged observation. An instance identifier and a tracking UID are generated for future reference (Figure S1).

• The radiologist assigns a Lung-RADS score, which is documented as another CDE-tagged observation that references the initial observation created for the pulmonary nodule (Figure S3). Using this new approach, the radiologist-generated content and AI-generated content can be smoothly integrated together by general-purpose tools instead of by special-purpose plugins which must both parse radiologist results from text and account for differences among AI algorithms’ output formats.

• The final radiology report, represented by the HL7 FHIR DiagnosticReport Resource, includes observations from AI tools, clinical history, and the radiologist interpretation (Figure S4) (Figure 3, step 6). These structured data are in addition to the radiologist’s narrative report, though it would be readily possible to automatically generate appropriate natural language from the structured data (eg, using large language models).

Discussion

We have proposed and illustrated a framework for representing the contents of radiology reports using standardized semantics and structure. The framework combines semantic tags maintained in a central repository curated by national radiology organizations (ACR and RSNA) with a standard HL7 FHIR resource to allow data representing imaging clinical scenarios/findings from many sources in the imaging informatics pipeline to be exchanged in a single, common format. This facilitates the exchange of this information as structured data (as opposed to unstructured text) both within the imaging informatics ecosystem and to downstream clinical systems (such as the EHR). The structure allows other applications to use the data down to the level of individual attributes/components of findings, including allowing these to be tracked over time. We hope that makers of imaging informatics tools will adopt this standards-based approach to the representation of imaging results to unlock these potential benefits and create new possibilities for informatics tools leveraging imaging data.

Utility of CDE-labeled findings

By combining expert-crafted set definitions with the FHIR observation structure to provide a universal data model for representing radiology findings, new possibilities for using imaging data are created. This approach enhances interoperability, allowing findings to be easily identified and integrated across varied systems. The FHIR resources employed are already familiar to the healthcare community, which streamlines data transmission and makes versioning for context feasible. The model is adaptable and supports local customization and the integration of non-CDE data elements, allowing alignment with local practices. The standardization of imaging finding data will promote fluid data exchange across diverse imaging systems, including electronic health record (EHR) systems, AI applications, and the tools in the radiologist environment (workflow manager, image viewer, report editor).

The framework presented here can enhance clinical systems and improve patient care in several ways. The model allows for tracking identifiers (based on DICOM structures) so that observations can be individually followed longitudinally. The common representation framework could also aid in tracking changes in findings over time across patient cohorts, facilitating population-centric studies. It also serves as a solid foundation for research by establishing data quality standards across clinical scenarios.

Moreover, the framework can enable the creation of tailored clinical decision-support tools for both radiologists and the extended care team. The reliable encoding of specific finding values enabled by CDE-tagged FHIR observations can serve as the basis for triggers for downstream action, including alerting appropriate clinical response teams, prompting recommended therapeutic management, or facilitating subsequent care pathways, imaging, and more. This unified labeling strategy can ramify throughout the ecosystem, from enabling tools within the radiologist's workflow to offering varied data views for patients or providers, generalists, or specialists.

Further, the framework simplifies AI tool integration by providing AI developers with a standardized format for transmitting results via APIs. By adhering to this specialization of the observation resource, AI vendors can ensure their outputs seamlessly integrate into various clinical systems, balancing clarity with expert-driven detail without imposing extraneous requirements. The framework effectively defines an output specification for AI models, facilitating the integration of these tools into both the radiologist's workflow (both for viewing results on images and including in results) and downstream patient care, for example, via finding annotations in multimedia reports.²⁴

Addressing barriers to adoption

Previous attempts by organizations such as ACR and RSNA to encourage the use of CDE identifiers have seen limited success.²⁵ A significant hindrance stems from local disparities in representing findings (eg, site-specific requests from surgeons detailing the format of preoperative imaging results format).^26–29 Enhancing the flexibility of CDE set definitions to encompass a union of the elements prevalent in practice has reduced resistance. This adaptability ensures that differences in practice patterns can be suitably accommodated.

Compared to prior efforts, the CDE-labeled observation framework leverages the HL7 FHIR standard, allowing for simpler implementation of a standard with robust support from the developer and vendor community. Recent legislation from The Office of the National Coordinator for Health Information Technology mandating EHR implementation of FHIR has spurred the growth of a community of healthcare organizations, vendors, and developers who have created free resources, such as implementation libraries, reducing inertia to its adoption compared to less efficient or less flexible standards. Consequently, the CDE-labeled observation framework, by building on this work, will have decreased barriers to integrating with other clinical systems.

Encouraging vendor adoption on both the front and back ends continues to be a key component of the imaging informatics community’s support for this framework. At the back end, a growing array of image interpretive AI algorithms and use cases require extensive data modeling to accommodate generated CDE-labeled output. CDE sets will need to capture the breadth of findings reported by commercial AI algorithms (eg, intracranial hemorrhage, acute pulmonary embolism, pulmonary nodules, and spine fractures, among others) while providing a process for updating the repository of CDE sets to accommodate for new AI findings. Flexibility for adding elements encourages commercial adoption, allowing each vendor to suggest elements captured by their solution to join expert-derived elements set as a baseline expectation for all AI solutions addressing a given task. Interoperability demonstrations, such as the RSNA’s Imaging AI in Practice demonstrations, showcasing the utility, flexibility, and ease of implementation of CDEs represent an additional means of encouraging vendor adoption³⁰; these have already brought stakeholders together to highlight the integral role of CDEs for successful integration of AI, providing a model for wider adoption. As 1 example of clinical implementation, an AI vendor seeking to integrate the output of their tool into a clinical data pipeline (Microsoft + Nuance, Cambridge, MA) outputs structured data describing automatically detected breast abnormalities with identifiers from CDE sets for Breast Calcification (RDES241), Breast Mass (RDES246), Breast Asymmetry (RDES283), Breast Focal Asymmetry (RDES284), and Breast Architectural Distortion (RDES285) (H. Chase, personal communication, March 19, 2024).

On the front end, tools that help radiologists report their findings will need to create interfaces that allow radiologists to incorporate the CDE-labeled structured data generated by AI tools into the radiologist workflow. In addition, it will be important to assist radiologists in generating such data from their own reporting process to include with the unstructured text.

Our hope is that the proposed structure will form the basis for a lingua franca for the exchange of structured representations of radiology findings, allowing clinicians, informaticists, and vendors to unlock the value of a centrally maintained data element repository. Clearly, maintaining CDE-based data models requires ongoing governance and maintenance to ensure that CDE sets and elements reflect radiology reporting practice, respond to clinical questions posed by ordering clinicians, and enable capabilities supported by vendors. However, the network effects unlocked by the low-friction exchange of structured radiology finding data will bring new capabilities to imaging informatics in a way that will more than justify the energy required to create and maintain the central repository.

Author contributions

Ali S. Tejani, Brian Bialecki, Kevin O’Donnell, Teri S. Schmidt, Marc D. Kohli, and Tarik Alkasab provided substantial contributions to the conception of the work and contributed to drafting and reviewing the work for important intellectual content. All authors provide final approval of the version to be published. The corresponding author, Tarik Alkasab, agrees to be accountable for all aspects of the work.

Supplementary material

Supplementary material is available at Journal of the American Medical Informatics Association online.

Conflicts of interest

TKA’s department has a consulting agreement with Nuance Communications/Microsoft; TKA serves on an advisory board for Nuance Communications/Microsoft (travel expenses only). MDK receives consulting fees from Alara Imaging.

Data availability

Sample FHIR JSON files are available online at https://github.com/openimagingdata/FHIRSamples/tree/main/lung_ca_screening_example.