HL7^® Reference Guide

DSR_Q03 is the later response in the older deferred query workflow. A requester sends a deferred query, the receiver acknowledges the request with QCK_Q02, and then DSR_Q03 arrives when the receiver has the answer ready.

In real interfaces, the awkward part is correlation. The data may arrive seconds, minutes, or batch cycles later. The echoed QRD and optional QRF are what let the requester prove which query this response satisfies.

A small DSR Q03 example

What systems do with it

The receiver sends DSR_Q03 when the deferred work has finished. The requester checks MSA, QAK, the QRD query ID, and the sender identity before it updates the waiting workflow.

Because the response can be delayed, the requester also needs timeout behavior. That may mean a user-facing "still pending" state, a retry window, or an operational alert when the expected DSR never arrives.

How to read the structure

MSH identifies the deferred response. MSA is optional in the local v2.5.1 structure but commonly present. ERR carries application errors. QAK reports query status. QRD is required and ties the response back to the original query.

The repeating DSP segments carry display data. DSC can continue large responses, but the continuation rules should be spelled out carefully because the original request is no longer on the same request-response turn.

Implementation traps

Do not match DSR_Q03 to a waiting request by patient alone. The same patient can have multiple outstanding queries. Match by query ID, message control IDs, sender and receiver, and any profile-specific tag your trading partner defines.

Also make sure the acknowledgment path is clear. If the DSR_Q03 itself fails, the sender needs to know whether to retry or mark the deferred query as failed.

Reference notes

HL7's deferred access discussion allows responses to be split across separate DSR messages and describes continuation behavior. The local v2.5.1 structure keeps that same QRD/QRF/DSP shape.