DSC is the continuation-protocol segment. It appears at the very end of a message that is one fragment of a larger response, and it carries the pointer the requester echoes back to ask for the next fragment. DSC-1 holds that pointer; DSC-2 says which continuation style is in use — fragmentation of a single logical response, or interactive continuation across separate query/response pairs. DSC is an envelope-level control segment: it carries no clinical content, only the bookkeeping needed to walk through a paged result set. When DSC-1 is empty (or absent), the receiver knows it has reached the last fragment.
Purpose
DSC tells the receiver of a response whether more data is waiting and how to retrieve it. The responder sets DSC-1 to an opaque token; the requester sends that same token back on the next continuation request, and the responder resumes where it left off. DSC-2 declares whether the token refers to a fragmented single response (F) or an interactive continuation (I). An empty or absent DSC-1 signals the end of the data.
Used in
DSC is appended to query responses and to any continued (paged) message. It is most associated with query/response exchanges — the QBP query message and its responses (RSP) — but it can terminate any message segment grouping that a responder chooses to fragment. It does not appear in an initial query; it only appears in responses and in subsequent continuation requests. See the messages index for the message types that use the continuation protocol.
Field-by-field reference
Source: HL7 v2.5.1 standard DSC segment definition; DSC-2 values from HL7 table 0398 Continuation Style. No segment-level ConceptMap is published in the v2-to-FHIR IG for DSC. R = required (cardinality min ≥ 1), O = optional. Repeat = field may repeat. Length not specified here (—).
| Seq | Name | Data Type | Length | Req | Repeat | Table # | Description |
|---|---|---|---|---|---|---|---|
| DSC-1 | Continuation Pointer | ST | — | O | — | — | Opaque token identifying where to resume. Absent or empty in an initial query and on the final fragment; populated by the responder when more data remains. |
| DSC-2 | Continuation Style | ID | — | O | — | HL70398 | Whether the continuation is fragmentation of one response (F) or interactive continuation (I). Optional; many engines leave it empty and treat the exchange as fragmentation by default. |
Most-used fields
DSC-1 Continuation Pointer is the field that does the work. It is opaque by design — the requester must not parse or modify it, only echo it back verbatim on the next continuation request. Treating it as meaningful (for example, assuming it is a row offset) is a common interoperability error.
DSC-2 Continuation Style distinguishes the two protocols. F (fragmentation) means a single logical response was split because it was too large for one message; the fragments are reassembled by the receiver. I (interactive) means the requester explicitly asks for the next chunk with a fresh query carrying the pointer. When DSC-2 is empty, fragmentation is the usual assumption.
Version differences (2.3 to 2.8.2)
- 2.3: DSC present as the continuation-pointer segment; DSC-1 carries the pointer.
- 2.3.1 / 2.4: the continuation protocol is formalized alongside the query infrastructure; DSC-2 Continuation Style (table 0398) is defined to separate fragmentation from interactive continuation.
- 2.5 / 2.5.1: DSC stabilizes as a two-field control segment used with the QBP/RSP query framework; behavior of an empty DSC-1 as the end-of-data signal is clarified.
- 2.7 to 2.8.2: no material change to the two fields. The broader trend is that real-world systems increasingly prefer query parameters (result-count limits, anchors in QPD) over message-level continuation, so DSC is encountered less often in newer interfaces. Receivers built for older versions simply ignore a DSC-2 they do not recognize.
Common mistakes
- Parsing or mutating the DSC-1 pointer instead of echoing it back verbatim — the token is opaque and responder-owned.
- Sending DSC on an initial query. It belongs on responses and on follow-up continuation requests, not the first request.
- Treating a present-but-empty DSC-1 as "more data" — an empty pointer is the end-of-data signal.
- Confusing the fragmentation style (
F) with interactive continuation (I) and reassembling fragments that were meant to be fetched one query at a time. - Mixing up DSC with MSH-14 (also called Continuation Pointer): MSH-14 carries the pointer on the request header, while DSC carries it as a trailing segment on the response.
Examples
Minimal DSC (pointer only, fragmentation implied):
DSC|PTR000123
Fully-populated DSC (pointer plus explicit style):
DSC|PTR000123^^^|I
Annotated breakdown of the minimal example:
DSC ← segment ID
| ← field separator (from MSH-1)
PTR000123 ← DSC-1 Continuation Pointer (opaque token; more data remains)
← DSC-2 Continuation Style absent (fragmentation assumed)
In-context at the end of a continued query response (RSP) — more data remains, so DSC-1 is populated:
MSH|^~&|EMPI|HOSP_A|EHR|HOSP_B|20260609120000||RSP^K22^RSP_K21|RSP-0001|P|2.5.1
MSA|AA|QRY-0001
QAK|QRY-0001|OK
QPD|Q22^Find Candidates^HL7|QRY-0001|@PID.5.1^DOE
PID|1||100001^^^HOSP^MR||DOE^JANE||19850212|F
PID|2||100002^^^HOSP^MR||DOE^JOHN||19800101|M
DSC|PTR000123^^^|F
In-context on the final fragment of the same response — DSC-1 is empty to signal end-of-data:
MSH|^~&|EMPI|HOSP_A|EHR|HOSP_B|20260609120500||RSP^K22^RSP_K21|RSP-0002|P|2.5.1
MSA|AA|QRY-0002
QAK|QRY-0002|OK
QPD|Q22^Find Candidates^HL7|QRY-0002|@PID.5.1^DOE
PID|1||100003^^^HOSP^MR||DOE^JAMIE||19920704|F
DSC||F
FHIR mapping
Target: Not mapped at the segment level. No segment-level ConceptMap is published in the v2-to-FHIR IG for DSC. The segment maps index lists no DSC entry, because DSC carries transport/paging bookkeeping rather than data that lands in a FHIR resource.
The conceptual equivalent in FHIR is search-result paging on a Bundle of type searchset: the server returns Bundle.link entries with relations self, next, and previous, and the client follows the next URL to retrieve the following page. The opaque DSC-1 pointer corresponds, in spirit, to the opaque URL behind Bundle.link.url — both are responder-owned tokens the client echoes back without interpreting. There is no field-by-field table for DSC because neither DSC-1 nor DSC-2 maps to a discrete FHIR element.
Engine considerations
- DSC is meaningful only as part of the continuation protocol; an engine that does not implement continuation should treat DSC-1 as a no-op and never fabricate a pointer.
- Pointer lifetime is responder state: the token in DSC-1 usually references a server-side cursor or cached result set that can expire. An engine must handle a stale-pointer rejection on the next continuation request.
- Idempotency and dedup: continuation responses share the same logical query but carry distinct MSH-10 control ids per fragment. Correlate fragments by the query id (QPD/MSA echo), not by message control id.
- End-of-data detection: branch on an empty or absent DSC-1, not on the presence of the DSC segment itself — a final fragment may still include a DSC with an empty pointer.
- Watch the MSH-14 versus DSC distinction so request-side and response-side pointers are not crossed.
How Vorro parses and produces DSC
On the inbound side, Vorro reads DSC only within a continuation-aware channel: it captures DSC-1 as an opaque cursor, checks DSC-2 to decide between fragment reassembly and interactive fetch, and stops paging when DSC-1 comes back empty. On the produce side, when Vorro fragments a large response it mints a pointer into DSC-1 backed by a server-side cursor, sets DSC-2 to match the negotiated style, and emits an empty DSC-1 on the terminating fragment so downstream receivers get an unambiguous end-of-data signal. Vorro never reinterprets a pointer it did not generate; it echoes inbound DSC-1 values verbatim.
Related pages
- MSH — the header whose MSH-14 carries the request-side continuation pointer that pairs with DSC.
- QPD — the query parameter definition segment whose query id correlates the fragments DSC walks through.
- QBP messages — the query framework whose RSP responses are the typical home of DSC.
