DICONDE and digital radiography in the equipment record

A radiographer finishes a weld shot at two in the morning. The digital detector array writes the exposure to a workstation in the RT truck. The interpreter reviews it there, marks the indication, and produces a report. Three weeks later, the report arrives as a PDF and is filed against the job number. The weld record in the inspection system says one word: accept. The image that supports that word is on a hard drive in a truck that has since moved to another site. This is the normal condition of digital radiography in most plants, and it is the problem DICONDE software is meant to fix. Fixing it is less about the viewer and more about where the image and its interpretation live.

What is DICONDE and why does it matter for the equipment record?

DICONDE is the NDE industry's adaptation of DICOM, the medical imaging standard that made it possible for a CT scan taken in one hospital to be read in another. ASTM E2339 defines the practice. The core idea carried over from medicine is simple: the image file is not a bare bitmap. It is a tagged object that carries its own context, including what was imaged, how, with what equipment, by whom, and under what technique.

For an inspection program, that changes the nature of the artifact. A TIFF named is only meaningful while someone remembers what W-114 was and which shot 3 this is. A DICONDE object carries the component identifier, the study and series structure, the acquisition parameters and the detector identity inside the file. Move it, copy it, archive it for fifteen years, and the context travels with it.

That matters for the equipment record because an equipment record is a long-lived thing. The weld inspected today may be evaluated for fitness-for-service in a decade, when a new indication appears nearby and the question becomes whether it was present before. Answering that requires the original exposure, the original technique, and the original interpretation, all of them locatable from the weld itself rather than from a job folder. DICONDE makes the image capable of carrying that context. It does not, on its own, put the image where the record can find it. That is the software problem.

What does ASTM E2339 actually standardize?

ASTM E2339 is a practice, not a file format in isolation. It specifies how DICOM's information object definitions, data dictionary and service classes are applied to NDE. In practical terms, a conformant system handles four things.

• A component-centred data model. Where DICOM has a patient, DICONDE has a component. The tags describing the object under examination (part identifier, material, drawing reference, owner) replace the demographic tags of medical imaging.
• Study, series and instance structure. An examination of a weld is a study; the exposures within it are organized into series and instances. This hierarchy is what lets a viewer show every shot from one examination together, and lets an archive answer "show me every study on this component."
• Acquisition and technique metadata. Source type, kilovoltage, exposure, source-to-detector distance, detector identity, image quality indicator placement and processing parameters are carried as tagged elements, so a technique can be reviewed and repeated.
• Network services and media storage. The same store, query and retrieve services that let medical archives interoperate apply to NDE archives, so images can move between acquisition systems, viewers and long-term stores without vendor-specific conversion.

Companion standards extend the base practice by modality. Digital radiography and computed radiography have their own, as do ultrasonic and computed tomography data. The important consequence for a buyer is that DICONDE conformance is a statement about a specific object type and a specific set of services, and a vendor claiming conformance should be able to produce a conformance statement saying which ones. A viewer that opens DICONDE files is not the same as an archive that stores, indexes and serves them.

Why do radiography images get separated from the asset record?

The separation is rarely a decision anyone made. It is the result of four ordinary pressures.

First, the acquisition system is owned by the RT contractor, not the owner-user. The images land on contractor hardware by default, and the contract deliverable is the report, not the image set.

Second, image files are large and the inspection system was not designed to hold them. A single DDA exposure at full bit depth is tens of megabytes. A turnaround with several hundred welds produces a volume that a form-based inspection system, or a shared network folder, handles badly. So the images stay in the RT archive and the record gets the PDF.

Third, the two systems have different identities for the same weld. The RT system knows the weld by the isometric and weld number written on the technique sheet. The inspection system knows it by an equipment tag, a component and a CML or weld identifier. Nothing joins them except a person.

Fourth, the interpretation is written as prose in the report rather than as fields on the record. Once the interpretation is prose in a PDF, the image becomes a supporting attachment to a document rather than evidence on a record, and the pressure to link it tightly disappears.

None of these are technical impossibilities. They are defaults. The purpose of specifying DICONDE software properly is to change the defaults so that the weld record, not the job folder, is the place the image is reached from.

What should the equipment record carry for each exposure?

A defensible radiography record on a weld or component carries five layers. The image is only one of them.

1. Identity. The equipment tag, the component, and the weld or CML identifier as the inspection system knows them, plus the identifiers the RT system used (isometric, weld number, study identifier) so the two can be reconciled without a person.
2. Technique. Source, energy, exposure, geometry, detector or film system class, image quality indicator type and placement, and the technique sheet itself. For DICONDE objects most of this is in the tags; the record should still surface it as fields so it can be checked without opening a viewer.
3. Image evidence. The DICONDE objects for every exposure, including rejects and retakes, stored or referenced from the record with a stable link. Retakes matter: a later question about why one exposure was retaken is answered by the rejected image, not by the accepted one.
4. Interpretation as structured data. Indication type, location along the weld, orientation, dimension, and disposition, with the acceptance standard and its relevant acceptance criterion named. This is the layer that gets queried, trended and audited. A free-text "accept" is not an interpretation; it is a conclusion with its reasoning missing.
5. Provenance. Who acquired, who interpreted, who reviewed, when, with what qualification, and any later amendment. The interpretation of a radiograph is a signed judgement and the record must show whose.

When these five layers sit on the weld record, the image is reachable from the asset, the interpretation is queryable, and the technique can be repeated. When only the PDF sits there, none of that is true regardless of how good the viewer was.

How do you evaluate DICONDE software against the record, not the viewer?

Most evaluations of DICONDE software are viewer evaluations: window and level tools, measurement, annotation, side-by-side comparison. Those matter to the interpreter and they are the easiest thing to demo. They are not the thing that fails. Evaluate from the record backwards.

• Reachability. Open a weld in the inspection system. Can a reviewer reach every DICONDE study on that weld from the record, in under a minute, without knowing a job number or contacting the RT contractor?
• Identity reconciliation. When the RT system identifies a weld one way and the inspection system another, where is the mapping held, who maintains it, and what happens when a weld is renumbered after a repair?
• Field capture of the interpretation. Does the interpreter enter the indication, location, size and disposition as fields, or as a paragraph? Can those fields be required before the study can be closed?
• Technique as data. Are the acquisition tags surfaced on the record so an engineer can see the energy and geometry without a viewer, and so a repeat shot can be specified from the record?
• Retention and export. Are images retained for the life of the component rather than the life of the contract? Can the owner-user export the full study set in DICONDE form at any time, without the RT vendor's cooperation?
• Offline behaviour. Interpretation often happens in the truck or the trailer with no network. Can the interpretation be captured offline against the correct weld and synchronized later, with any conflicts visible?
• Audit trail. Who viewed, who interpreted, who amended, and can the history of the interpretation be shown to an auditor without a database administrator?

A vendor who passes these questions may still have a worse viewer than one who fails them. Buy the one that passes. Viewers improve with releases; records that were never linked do not get linked retroactively.

What about legacy film and CR archives?

Every established plant has a film vault, and many have a first-generation CR archive in a proprietary format. Both raise the same question: how much of the past is worth converting?

Film can be digitized with a calibrated film digitizer and wrapped as DICONDE objects. The image quality is bounded by the film and the digitizer, and the metadata is only as good as the technique sheet stapled to the envelope, typed in by hand. Proprietary CR archives can often be exported to DICONDE by the original vendor's tools, if those tools still run and the licence is still valid.

The practical policy is triage rather than wholesale conversion.

• Convert what is still in service and still decision-relevant. Welds and components with active damage mechanisms, past repairs, or pending fitness-for-service questions. The value of a baseline radiograph rises sharply the moment a new indication appears near it.
• Index everything, even what you do not convert. A record entry that says "film exists, vault location, envelope reference, date, interpreter" is cheap and turns an unsearchable vault into a searchable one. The film itself can be pulled if the question ever arises.
• Capture the interpretation as fields during indexing. Reading the old report and entering disposition and indication fields costs a few minutes per weld and makes twenty years of results queryable even where the images stay on film.
• Retire the proprietary format deliberately. Export while the vendor tools still work. Waiting until they do not is how archives become unreadable.

The question is never whether an old radiograph might be useful. It is whether, when it becomes useful, anyone will be able to find it and read it.

How intelliSPEC handles it

intelliSPEC does not try to be the radiography acquisition system. It is the equipment record that the acquisition output must land against. intelliNDT records radiographic examinations as structured records on the asset graph, so a study is tied to the equipment node, the component and the weld rather than to a job folder. Because forms are configured through the form designer rather than code, a tenant can define the interpretation as fields (indication type, location, size, disposition, acceptance reference) and make them required, with the image files, technique sheets and annotated drawings attached to that record as evidence. Photos and PDFs can be annotated on the device, and CML points are detected automatically on uploaded drawings so the weld map and the record agree.

Because completed records pin the field configuration they were executed with, an interpretation recorded today renders the same way in ten years even if the RT form has since been revised. The field application works fully offline, with no time limit on the local store, so an interpreter in the truck can complete the record and synchronize later, and any field-level conflict shows the local value, the remote value, who resolved it and when.

Every read, write and export on the record is written to a hash-chained audit trail that carries actor, tenant, request identifier and device details, so the history of an interpretation can be shown without a database query. Data leaves through an open API and workbook or bulk export, so the owner-user holds the record and its evidence regardless of which contractor holds the truck. For a shared vocabulary of the terms used above, see the glossary; for how these records feed thickness and fitness-for-service work, see intelliINTEGRITY.