DICONDE Interoperability Acceptance Test for NDT Buyers
DICONDE support is valuable when the required information survives the actual path between your systems. Ask vendors for their conformance statements, then test the specific acquisition, review, archive and retrieval functions the purchase must deliver.
For: U.S. NDT equipment coordinators, quality staff and inspection business owners
Define the imaging chain you are buying
Begin with the systems that must exchange information. Name the acquisition workstation, analysis software, customer viewer, archive and any intermediate transfer service. Identify the version and role of each one. A supplier can demonstrate successful exchange between two products while the buyer's real workflow includes three others. The purchasing requirement should describe the complete path and the functions needed at each destination, not simply request DICONDE compatible software. That makes the claimed capability concrete enough to test and price.
Separate essential functions from desirable ones. One customer may require readable image files with their technique information, while another needs network search and retrieval from an archive. A reviewer may need presentation annotations that a simple viewer cannot reproduce. Write those needs as observable outcomes. This guide offers a purchasing worksheet and original trial structure; it does not reproduce a standard's full conformance procedure or certify a product. Formal requirements and acceptance criteria remain with the applicable documents and authorized parties.
Understand what the base standard does and does not promise
The public scope of ASTM E2339-21 describes DICONDE as a framework for exchanging NDE images and related information, used with modality-specific practices and DICOM. It also distinguishes that framework from implementation details and a complete integrated system's feature set. This matters because the word conformant does not tell a buyer every function a particular product implements. Ask for the supported scope in a document tied to the actual software version being quoted.
The public scope of ASTM E3147-25 addresses evaluation of interoperability and leaves the required parameters and acceptance expectations to the using parties. Use that as a reason to define your own required outcomes through the appropriate technical process. Do not present this article's trial examples as a substitute for a contractually required standards evaluation. A useful purchasing test can expose missing functionality, but its result should be described at the level actually demonstrated rather than promoted into blanket certification.
Read conformance statements as scope documents
Request the conformance statement for each participating product and version. Ask the supplier to identify the sections relevant to your intended exchange. North Star Imaging's DICONDE overview explains that these statements document the supported portions of the standard and discusses metadata, presentation and communication as distinct interoperability topics. Those distinctions help organize a buyer's questions. A statement for a related product family or older release should not be accepted without confirming its applicability to the quoted configuration.
Have the appropriate technical reviewer compare the stated capabilities across the actual source and destination systems. Record apparent gaps and the vendor's response. Procurement does not need to infer every implementation detail from specialist terminology; it needs an accountable answer for the required workflow. If the vendor says a capability is optional, identify the module and license. If it is planned for a later release, mark it as undelivered. A roadmap should not be scored as a demonstrated capability of the current purchase.
Build a representative nonproduction sample set
Select sample records that reflect the modalities and data structures the organization will exchange. Use approved nonproduction or appropriately sanitized material, with technical review of any changes needed for the trial. A single uncomplicated image can prove that something opens while leaving important relationships untested. Include the image groupings, identifiers, technique information and presentation features required by the actual workflow. Record why each sample is in the trial so later reviewers can see what the evaluation covered and what it did not.
Create a sample manifest with a stable identifier, source system, file reference, expected related records and test purpose. Preserve an unchanged baseline copy. If the vendor modifies a sample to troubleshoot compatibility, retain the modified version separately and document what changed. Otherwise the final successful test may depend on an undocumented conversion that the production workflow cannot reproduce. The purpose is to evaluate an implementable exchange, not merely obtain a file that can be made to open through one-time manual intervention.
Check component identity and image relationships first
Start with the information that tells the receiver what the images belong to. Verify the required component or part identifier, examination grouping and relationships among images. Ask the receiving reviewer to locate a specified fictional component without help from the person who transferred the files. If the images appear under the wrong grouping or with an ambiguous identifier, a technically successful transfer can still fail the business requirement. Record that outcome as an identity issue rather than accepting the exchange because the pixel image is visible.
Include two components with similar names and a repeated examination of one component in the sample set. Check that the destination preserves the required distinction. Do not assume that folder names or file order will restore missing relationships. The system should retain the identity information required by your process, and the trial should show how a user retrieves it. If an internal naming convention remains necessary, document it as part of the workflow and test it rather than leaving the dependency implicit.
Verify technique metadata against a defined list
Ask the technical owner to identify the technique and acquisition information that must survive the exchange. Build a field-level comparison for those requirements instead of checking an undefined all metadata box. Record the source value, destination value and evidence location for each selected field. A missing optional field may have little consequence for one workflow and make another record inadequate. The importance of the field comes from the applicable requirement, not from whether the destination viewer happens to display it prominently.
Check units and meaning as well as text presence. A field that arrives as an unexplained number can be misleading even if its characters match the source. If the source and destination use different labels, ask vendors to explain the mapping and have the reviewer confirm it. Do not invent an attribute mapping from a screenshot. Preserve the agreed mapping in the acceptance record, including any limitations. The goal is understandable information at the receiving end, not merely a file that passes through a network connection.
Distinguish image data from presentation settings
A reviewer may need to see annotations, viewing conditions or other presentation information associated with an image. Ask which of those elements the proposed exchange supports and how they are represented. Demonstrate the required features individually. Do not treat a flattened screenshot containing an arrow as equivalent to a transferable annotation that remains separately identifiable in the receiving software. Both can communicate information, but they support different review and editing tasks. The purchasing requirement should specify which behavior is needed.
Use a sample with an intentional annotation and a defined viewing presentation, then inspect the result at the destination. Record whether the image, annotation and presentation can be distinguished and whether the original source remains available. If the destination does not support a required feature, ask whether an approved supplementary deliverable can close the gap. Do not silently drop the feature from the test because the underlying image looks acceptable. A limitation should be visible to the customer or technical owner who determines its consequence.
Test file exchange and network services separately
Opening a file copied through an approved transfer mechanism and searching a remote archive are different functions. Define which ones the organization actually requires. A successful file import does not demonstrate network query, retrieval or receipt behavior. Conversely, establishing a network connection does not prove that the destination can interpret every required record. Create separate acceptance rows so a success in one area cannot conceal an unresolved problem in another. Have the vendors identify any configuration or license dependencies for each function.
Coordinate network-related trials with the responsible system owners and use the approved environment. This guide does not prescribe connection settings or security controls. Record the participating systems, versions and tested route, along with the outcome visible to users. If an intermediary service changes files or creates another representation, include it in the trial. Testing a direct vendor-to-vendor path is useful only if that path matches or adequately represents the workflow the organization intends to deploy.
Include retrieval after storage, not just initial arrival
After a sample reaches the archive, retrieve it using the method the organization expects to use later. Confirm that the required identity, relationships, metadata and presentation remain available. Ask a reviewer who did not perform the import to complete the task from the recorded identifiers. This checks whether the record is practically findable, not merely stored somewhere. A transfer confirmation can establish arrival while leaving indexing or access problems undiscovered until a customer requests the historical data.
Record the archive configuration and any retention or reader dependencies relevant to the purchase. If the software offers both a managed database and ordinary file storage, clarify which arrangement is being evaluated. Do not assume the same retrieval functions apply to both. Where an export is required for customer handover or future migration, test that export and subsequent opening as another path. A readable archive today is useful, but the buyer also needs an explicit plan for obtaining its records outside the initial workstation when required.
Evaluate corrections without losing the original association
Use a fictional sample with an intentionally incorrect administrative identifier and ask the vendor to demonstrate the supported correction process. The technical and records owners should decide what history and controls the workflow requires. Observe how the corrected record is associated with the original image and what the destination receives after an updated transfer. The test should not require changing actual inspection evidence or altering technical results. Its purpose is to understand how the system handles a realistic metadata correction.
Also ask what happens when the same record is transferred twice. Determine whether the destination recognizes it, creates a duplicate, replaces information or presents a conflict for review. Record the demonstrated behavior rather than assuming one universal implementation. If the organization's procedure needs a particular outcome, make that requirement explicit in acceptance. Duplicate handling can affect whether users retrieve the correct record even when each individual file is readable, so it deserves its own trial row.
Work through a fictional partial-success exchange
A hypothetical radiography business transfers a demonstration dataset from an acquisition system to a customer's review workstation. The images open, component identifiers are correct and required technique fields remain available. However, a presentation annotation does not appear at the destination. The team records separate passes for the demonstrated image and metadata requirements and a failure for the annotation requirement. It does not label the entire chain fully interoperable merely because the pictures are visible.
The vendors then identify a supported export option that preserves the required presentation information. The buyer repeats the affected test and retains both the original issue and the successful resolution. If the option requires an additional license, its cost becomes part of the purchase. If the limitation cannot be resolved, the customer decides whether a documented alternative is acceptable. This fictional example shows how specific evidence leads to a concrete decision without making unsupported claims about any named vendor's implementation.
Tie acceptance to the versions actually tested
Record source and destination software versions, relevant modules, configuration references and the date of the trial. A later upgrade can require review of the affected exchange even if both products retain the same brand names. Ask vendors what changes may affect compatibility and how they communicate them. Maintain the acceptance sample set so the organization can repeat meaningful checks after a relevant change. Do not present an old successful trial as proof that every future combination will behave identically.
Price ongoing reader access, required modules and migration support alongside the initial license. A purchasing decision that excludes the archive viewer or export capability may create a future dependency that was invisible in the headline quote. Ask what remains available when subscriptions or support arrangements change and retain the written response. These commercial details matter because interoperability is useful only while the organization can access the participating functions. The technical claim and the license entitlement should describe the same delivered package.
Use the acceptance matrix as evidence of a defined trial
The downloadable matrix provides columns for business requirement, source and destination versions, sample reference, transfer route, expected outcome, observed outcome, evidence and disposition. Its example row is explicitly fictional and untested. Replace it with your approved requirements and actual observations. A pass should point to evidence; a limitation should identify an owner and accepted resolution. Do not mark every row complete from a vendor's general declaration. The matrix records your trial and does not issue a DICONDE certification or replace a required standards assessment.
NDT Connect's free equipment tracker can record acquisition equipment details, due dates, status and notes, but it does not ingest DICONDE records, operate an image archive or validate interoperability. Keep the conformance statements, sample files and acceptance matrix in your selected document system. Use a concise reference in the asset notes if appropriate. Close procurement when the required exchange functions have a documented disposition across the actual systems and versions. That gives the buyer a clear evidence basis for the promised workflow and a useful starting point for later changes.
Frequently Asked Questions
Does opening one DICONDE file prove complete interoperability?
No. Evaluate the required metadata, relationships, presentation, transfer and retrieval functions across the actual systems and versions.
What should a purchaser request from vendors?
Request version-specific conformance statements, required modules and licenses, representative sample files and support for a defined interoperability trial.
Is the downloadable matrix a formal DICONDE certificate?
No. It records a purchaser-defined trial. Apply the contractual standards and authorized acceptance process where a formal evaluation is required.
References & Standards Cited
- ASTM E2339-21 public scope: DICONDE information exchange View source ↗
- ASTM E3147-25 public scope: evaluating DICONDE interoperability View source ↗
- North Star Imaging: DICONDE conformance and interoperability concepts View source ↗
Related on NDT Connect
Join NDT Connect — free
The free marketplace for the NDT industry — connect inspectors and the companies that need them.
Free to join · Compare provider qualifications and confirm availability directly · Browse providers
By NDT Connect Editorial · Updated
Source-based editorial guidance. Read our editorial policy and disclosures.