Ultrasound Images Sent Successfully: Has the Archive Accepted Responsibility?

What does a successful C-STORE response actually guarantee?

An ultrasound system says “Sent Successfully.” Before a drive replacement or operating-system reload, a service engineer needs to know whether that means all required records are protected elsewhere. The first task is to identify the destination and the individual objects behind the status. A cart’s summary icon may represent a job, a series or an examination; its meaning comes from that product’s documentation.

DICOM (Digital Imaging and Communications in Medicine) defines separate Storage and Storage Commitment Service Classes. C-STORE success is an application-level storage response, not merely a TCP delivery acknowledgment. PS3.4 B.1.2 defines successful completion as storage of the information in some medium with access for a period; the access method and storage duration depend on the implementation and its conformance statement. Query/retrieve support is not implied. ¹³ Annex J explains that the Storage Service Class does not itself make an explicit safekeeping commitment. Do not turn that distinction into a claim that C-STORE imposes no requirements, or that every receiver uses a volatile cache. Storage behavior and supported storage levels also have conformance requirements. ^{1 12}

A receiver may persist an instance before acknowledging it. That can be useful evidence, particularly when its conformance statement describes the behavior. The remaining question is what the sender can establish about retention and later retrieval. A success response from a gateway also needs to be distinguished from evidence about the downstream archive. Identify the AE—the DICOM application entity—that actually accepted the operation.

• Destination: Was the operation accepted by the final PACS/VNA, a router or a temporary receiver? PACS means picture archiving and communication system; VNA means vendor-neutral archive.
• Coverage: Which SOP (Service-Object Pair) instances were sent? A SOP Instance UID—a unique identifier—identifies one DICOM object; a multiframe clip is not counted once per frame.
• Exceptions: Were any instances left pending, rejected or accepted with warnings? Preserve the actual responses rather than inferring completeness from a study-level label.
• Next evidence: Is there a commitment result, a documented alternative retention arrangement, or only a send log? These are different records.

One successful operation also does not establish continuous network or hardware health. When the problem is failure to send, use the separate guide to ultrasound DICOM and PACS output fault isolation. This article starts with an apparently successful send and examines the evidence still missing.

What is storage commitment—and what is the archive promising?

Under Annex J, the Storage Commitment SCU (Service Class User) requests safekeeping from the Storage Commitment SCP (Service Class Provider). These roles describe a particular service, not a general client/server identity for every operation on a device. The SCP’s conformance statement explains duration, retrieval capabilities, latency and capacity. It may promise limited storage rather than permanent archiving. The retrieval location can also differ from the AE that accepted commitment. ¹

For the DIMSE (DICOM Message Service Element) Push Model, SOP Class UID 1.2.840.10008.1.20.1, the N-ACTION request carries a Transaction UID (0008,1195) and a Referenced SOP Sequence (0008,1199). Each entry identifies a SOP Class and SOP Instance. A successful N-ACTION response establishes receipt of the request; the later result establishes its outcome. The request may contain one object or a set, so an accepted request is not proof that the complete examination was included. ²

The N-EVENT-REPORT result carries the matching Transaction UID. Event Type 1 reports success for all requested instances. Event Type 2 reports that failures exist and identifies both successful and failed instances, with a reason for each failure. The complete requested set must be accounted for. An acknowledgment of the N-EVENT-REPORT is yet another response: do not confuse its success status with the outcome contained in the event. ³

Committed instances must be stored at Storage Level 2 (Full), including private attributes. Annex J also requires the full pixel data rather than only a link to it. These requirements do not prescribe RAID, a checksum algorithm, a database commit sequence or a particular storage medium. Storage Level 2 is not a universal claim of bit-for-bit preservation; the Storage Service Class also describes permitted attribute handling. ¹² A positive event is the SCP’s declared commitment; it is not an independent audit of the archive’s implementation or disaster-recovery arrangements. ^{1 3}

Storage commitment does not itself decide legal custody, ownership, retention periods imposed on the facility, or permission to purge local media. DICOM leaves the SCU’s deletion behavior outside the service definition and requires that behavior to be documented. Facility policy, contracts and applicable obligations remain separate decisions. SIIM’s reference recommends the service as an addition to transfer, but that recommendation does not supply a facility retention policy. ^{1 9}

An evidence matrix for the local-retention decision

Use this matrix to label the evidence available in a service record. The action column is a proposed review boundary for the facility, not a deletion command or a DICOM-mandated workflow. A failure, pending response or incomplete source inventory should remain visible rather than being compressed into a single green status.

Consider a synthetic acceptance case with six objects: two stills, three multiframe clips and one structured report. A request covering the five image objects can receive Event Type 1 while the report was never requested. A study-level “committed” label would then overstate the available evidence. The missing object must be reconciled against the source inventory; repeatedly checking the same successful transaction will not widen its scope.

In a second synthetic case, the request includes all six objects but the result lists five successes and one failure. This is a partial result, not a fully committed examination. Record which object failed and its reason. Preserve the source while qualified staff resolve the exception. These examples illustrate set reconciliation; they are not patient cases or measured failure rates.

Where does the result arrive, and why might it be missing?

The standard requires capability for N-EVENT-REPORT delivery on a different association from N-ACTION; it also permits an attempt on the same association. A universal “three connections are always required” rule is therefore inaccurate. Orthanc documents a three-association implementation, and the Lumify R5.0 statement documents asynchronous result handling. Check both peers’ conformance statements before interpreting a missing callback. ^{3 5 10}

1. Was a request sent? Separate C-STORE success from N-ACTION acceptance. Confirm the correct commitment destination, supported SOP Class and permissions rather than assuming image transfer enables commitment.
2. Was the request accepted? Keep a failed operation distinct from an accepted request awaiting its result. Record the Transaction UID to correlate the two logs.
3. Was a result produced? Ask the archive owner to identify the result and the requested instance set. Server processing or a per-instance failure can explain the outcome without a network fault.
4. Could the result reach the sender? Where a separate association is used, qualified IT/PACS staff should compare the configured AE titles, address, listening port, approved network policy and device availability.
5. Was the result recorded? Compare sender status with the archive log. Product-specific timeout, retry and state-persistence behavior matters; do not assume all products retain or retry pending transactions identically.

Accepting an association does not automatically change a modality’s Storage Commitment service role to SCP. The archive remains the Storage Commitment SCP when it initiates the result association, with role negotiation as described in J.3.3. This matters when reading conformance tables that list the modality as SCU even though it listens for incoming results. ³

A firewall rule, a changed device address or an offline cart can interfere with a callback, but this guide has no dataset showing which cause is most common. Missing results do not prove that studies are lost, and successful sends do not prove the callback path works. Keep required copies protected and investigate with the archive owner; do not bypass network controls or infer a replacement-board requirement from this symptom alone.

What do the cited ultrasound documents establish?

The following examples establish specific documented behavior. They are not a compatibility matrix, a complete OEM survey, or proof that another release has the same feature. Obtain the matching document for the installed software and the receiving archive before an acceptance decision.

The historical LOGIQ7 statement makes queue interpretation especially important: under Rev 4.0, an unanswered commitment request is removed after two days without warning the user. A successful result also removes the request. An empty queue therefore cannot distinguish those outcomes on that revision; retain the transaction result and source inventory rather than treating the disappearance of a job as proof of commitment. This behavior must not be assumed for other models or releases. ⁴

The Lumify statement offers a useful reminder that retry behavior is product-specific: it describes retrying after 96 hours without the expected response and resending failed instances in its stated sequence. That is an implementation description, not a recommended waiting period for every scanner or permission to discard pending studies. Use the installed release’s own behavior when setting an escalation interval. ⁵

The PX guide distinguishes three study-selection options and warns that the choice must match the DICOM configuration. With a storage commit server configured, it calls for deleting only committed studies. It also describes an archive-only configuration that can use archived-study status. That latter option does not turn C-STORE into storage commitment: the facility still needs to assess its archive arrangement and records policy. This guide does not direct an administrator to enable either option. ⁶

What should the facility establish before changing local retention?

Treat storage pressure and retention authorization as separate tasks. A disk-space warning may reflect workload, a failed send, missing commitment results, storage trouble or policy settings. It does not establish which records can be discarded. Keep unresolved records protected and use the facility’s escalation process when capacity threatens workflow.

1. Name the accountable owner. Clinical engineering can collect the evidence, but the facility’s archive and records owners should approve the retention arrangement. Record who accepts unresolved exceptions and who can authorize a configuration change.
2. Reconcile the complete object set. Compare the source inventory with the request and result, including required reports and clips. Preserve failed or omitted instances; one successful image or series is not proof of a complete examination.
3. Read the archive’s commitment terms. Identify the responsible AE, retention duration, retrieval location and latency, capacity limits and relevant service arrangements. A limited-duration promise needs to fit the facility’s longer-term record plan. ¹
4. Determine local retention under policy. There is no universal grace period established by these sources. The PX guide’s selectable ages are product options, not evidence that 72 hours or seven days is safe for a particular facility. ⁶
5. Test with approved non-patient data. Before release, demonstrate the expected send, request, result and exception states under the OEM procedure. Record the settings reviewed and the facility sign-off; do not test deletion behavior on the only copy of a clinical record.

Routine local retention is also different from sanitization before equipment leaves a facility. Protecting the archive does not demonstrate that a drive has been sanitized. For that separate decision, use the patient-data export, preservation and erasure guide and agree the data handling plan before a repair shipment.

What if the archive does not support storage commitment?

Lack of the Storage Commitment SCP role does not establish that an archive is unsafe. Conversely, a product label saying “DICOM compatible” does not establish that it supports this service. Ask for the actual conformance statement and the facility’s documented retention arrangement. If there is no adequate approved alternative, preserve required local records and escalate rather than inventing an equivalence.

Independent query and retrieval can supply availability evidence for a facility-approved alternative. Use an authorized archive client and confirm that it is reading the destination rather than the scanner’s local cache. A separate workstation is a useful way to reduce that ambiguity; it is not a universal requirement specified by Annex J. Any patient-data checks must remain within the facility’s authorized environment.

• Identity: Match the relevant study, series, SOP Class and SOP Instance identifiers against the source inventory. Counts alone can conceal a missing object and an unexpected extra one.
• Completeness: Account for every required still, multiframe clip and report. An image-only viewer may not expose every object type; involve the archive owner when its inventory cannot establish coverage.
• Retrieval scope: Record precisely which objects were retrieved and checked. A sample can demonstrate a functioning path; it cannot prove the integrity or availability of all untested objects.
• Retention: Document who will keep the records, for how long, and how they can be retrieved. A successful retrieval establishes availability at that time, not a future storage promise.
• Disposition: Leave local copies protected until the responsible facility owner accepts the complete evidence and any exceptions under its policy. Retrieval alone is not authorization for deletion.

C-FIND and C-MOVE, or supported web-based query/retrieve services, are possible mechanisms; the appropriate choice depends on both endpoints. Do not assume that a study-level query offers instance-level completeness, or that a readable thumbnail proves the original multiframe content is intact. This article specifies the evidence question, not commands for a production archive.

Implementation evidence can also temper assumptions about commitment itself. Orthanc documents that its basic SCP checks database presence and SOP Class matching; custom checks can be added. Its SCU documentation also describes active reports held in RAM and lost on restart. These are Orthanc-specific details, but they illustrate why a protocol label is not a substitute for the receiver’s actual storage terms and the sender’s persistence behavior. ¹⁰

How does this fit drive work and return-to-service?

Before a storage reload or drive replacement, separate preservation of required studies from restoration of the system software and configuration. Unresolved archive evidence should be recorded in the work authorization before destructive work. If the console will not boot, follow the drive-versus-motherboard decision path; do not assume that a failed drive contains no recoverable patient data.

After a backend, motherboard or network-interface change, qualified staff should compare the authorized connectivity configuration before and after service. Where the repair changes an address, AE title, adapter configuration or listener, a successful outbound test can coexist with a missing commitment result. Document observed changes rather than assuming that every board replacement changes network identity.

Acceptance should cover the services actually configured for that device and archive, using approved non-patient test data. Record the source object set, send responses, request identity, result and destination verification as applicable. Hardware testing and archive acceptance answer different questions. The real-machine board test evidence guide explains the limits of a repaired-board test record; it cannot certify the hospital archive’s retention arrangements.

A useful evidence handoff for an unresolved result

The following proposed record helps the scanner engineer and PACS owner investigate the same transaction. It is not an OEM-mandated form. Keep clinical identifiers, packet captures and network details inside approved facility systems; an external repair enquiry normally needs a sanitized symptom summary rather than patient studies.

Where Rongtao fits—and where it does not

Rongtao provides ultrasound board repair and tested replacement parts, with probe services available for the relevant fault. Typical board-repair turnaround is 5–8 business days, real-machine testing is 48 hours, and the standard warranty is typically 90 days; confirm the applicable product, service and terms in the quotation. Those service facts do not establish a PACS integration or archive-validation capability. ¹¹

The facility’s PACS, IT and records teams own archive configuration, network approvals and retention decisions. A pending commitment result should be investigated with those teams before a hardware purchase. Rongtao’s repair role begins where there is evidence of a serviceable hardware fault; a report that an examination was “sent but not committed” does not identify a failed board.

For a hardware assessment through ultrasound repair services or contact, provide the OEM, exact model, installed software where relevant, manufacturer part number, symptom/error text, quantity and destination country. Include existing label and both-side board photos when available from qualified service work; do not dismantle equipment just for an enquiry. Describe whether C-STORE, N-ACTION or the result is failing, using sanitized evidence. Do not send patient records in the quote packet.

Frequently asked questions

The scanner says sent successfully. Can we delete the exam?
The status alone is insufficient evidence for that decision. Reconcile the required object set and the applicable commitment or approved alternative evidence, then follow the facility’s retention policy. This guide does not authorize deletion. ¹

Is storage commitment a permanent or legal custody guarantee?
It is an explicit protocol commitment whose nature is defined by the implementation’s conformance statement. Duration can be limited. It does not by itself settle legal custody or prescribe the facility’s local-deletion policy. ¹

Our request was accepted but no result arrived. What should we check?
Correlate the Transaction UID at both peers, determine whether the archive produced a result, and check delivery and sender recording under the actual implementation. A separate callback can fail even when outbound transfer works. Avoid assuming one cause, a fixed retry interval or that a missing result proves data loss. ^{2 3}

What do the failure reasons tell us?
DICOM PS3.3 C.14.1.1 defines processing failure 0110H, unavailable SOP Instance 0112H, resource limitation 0213H, unsupported referenced SOP Class 0122H, Class/Instance conflict 0119H and a Transaction UID already in use 0131H. These narrow meanings do not identify a broken disk, a packet-loss cause or a board to replace. Preserve the failed set and investigate with the archive owner. ⁷

Does a successful result prove the whole exam is committed?
Only if the request included every required object and the result accounts for that set. A successful transaction for image instances does not cover a report that was never requested. Compare identities, not only totals. ^{2 3}

When should this evidence be rechecked?
Recheck after scanner software or connectivity changes, archive migrations, changes to retention terms, or revisions to the cited standard and OEM documents. Record the exact versions used in acceptance. Historical LOGIQ7 and S-Series examples should remain labeled as historical, even when the source review is recent.