The URS (Unsolicited Selection) segment refines the broad subscription declared in URD with detailed selection criteria. It expresses the "where" of the subscription — a list of predicates over arbitrary fields — and the "when" — a date/time window plus qualifiers that decide which dates and statuses trigger a push.
Purpose
URS turns a subscription from "anything matching the URD subjects" into a precisely scoped feed. URS-1 carries a repeating list of selection predicates (typically field-reference + operator + value tuples). URS-2 and URS-3 bound the data date/time range of interest. URS-4 through URS-8 narrow further on user qualifier, other-results context, and which date/time of the source result (collected, observed, reported, etc.) drives selection. URS-9 layers a timing/quantity qualifier on top.
URS is paired with URD, which carries the broader subject and routing definition.
Used in
URS appears in unsolicited results-update query messages, primarily:
- QRY^Q05 (and related Q-group event variants) — where a subscriber narrows an existing URD subscription with precise selectors.
These flow inside the general query framework documented on QRY messages. URS always follows a URD in the same message and, in newer query patterns, may be complemented by a QPD segment.
Field-by-field reference
Source: HAPI HL7v2 v2.5.1 javadocs (https://hapifhir.github.io/hapi-hl7v2/v251/apidocs/ca/uhn/hl7v2/model/v251/segment/URS.html) for sequence, name, data type, and repetition. Length is not published in the javadocs (—); Required and Table # are filled from the HL7 v2.5.1 standard where well-established.
| Seq | Name | Data Type | Length | Req | Repeat | Table # | Description |
|---|---|---|---|---|---|---|---|
| URS-1 | R/U Where Subject Definition | st | — | O | Y | — | Selection predicates over arbitrary fields. |
| URS-2 | R/U When Data Start Date/Time | ts | — | O | — | — | Start of the selection date/time window. |
| URS-3 | R/U When Data End Date/Time | ts | — | O | — | — | End of the selection date/time window. |
| URS-4 | R/U What User Qualifier | st | — | O | Y | — | User-defined refinement strings. |
| URS-5 | R/U Other Results Subject Definition | st | — | O | Y | — | Selectors for related-result inclusion. |
| URS-6 | R/U Which Date/Time Qualifier | id | — | O | Y | HL70156 | Which date/time of the result to apply the window to. |
| URS-7 | R/U Which Date/Time Status Qualifier | id | — | O | Y | HL70157 | Result-status time qualifier (e.g., last update). |
| URS-8 | R/U Date/Time Selection Qualifier | id | — | O | Y | HL70158 | Selection mode over the date/time window. |
| URS-9 | R/U Quantity/Timing Qualifier | tq | — | O | — | — | Quantity/timing qualifier across pushes. |
Most-used fields
- URS-1 R/U Where Subject Definition is the heart of the segment — a repeating list of predicate strings (commonly
@SEG.fld.cmp^OP^value) that the producer evaluates against candidate results. - URS-2 and URS-3 fence the data date/time window and are the most common reason a subscriber misses results (window too narrow, or wrong end-of-day).
- URS-6 disambiguates which date/time on the result is being filtered (observation time vs. report time vs. last update).
- URS-9 controls cadence when the subscription is for periodic pushes rather than event-driven ones.
Version differences (2.3 to 2.8.2)
- 2.3 introduced URS with the nine-field shape used throughout subsequent releases.
- 2.3.1 and 2.4 left the field set unchanged. The associated tables HL70156 / HL70157 / HL70158 were refined over time.
- 2.5 and 2.5.1 keep the nine-field structure verified in the HAPI v2.5.1 javadoc.
- 2.6, 2.7, 2.7.1, 2.8, and 2.8.2 retain URS unchanged for backward compatibility, even as HL7 has steered new subscription work toward QBP/RSP and FHIR
Subscription.
Common mistakes
- Treating URS-1 predicates as opaque free text instead of structured
@SEG.fld^OP^valueexpressions. Many engines silently drop predicates they cannot parse. - Building a window in URS-2/URS-3 without considering URS-6, then being surprised that "yesterday's" reports do not match because the qualifier is observation time, not report time.
- Mixing URS-7 and URS-8 in a way that contradicts URS-6. The three should be set together.
- Relying on URS-4 R/U What User Qualifier for cross-vendor selection. It is user-defined and rarely portable.
Examples
Minimal URS narrowing the subscription to two patient IDs over today's window:
URS|@PID.3.1^EQ^P10045~@PID.3.1^EQ^P10046|202606100000|202606102359
Fully-populated URS covering all nine fields:
URS|@PID.3.1^EQ^P10045~@OBR.4.1^EQ^CBC|202606100000|202606102359|VIP=Y|@PID.3.1^EQ^P10101|OBR^Observation Date|F^Final|EQ|1^^^202606100000^202606102359
Annotated breakdown:
URS Segment ID
|@PID.3.1^EQ^P10045~@OBR.4.1^EQ^CBC URS-1 R/U Where Subject Definition (two predicates)
|202606100000 URS-2 R/U When Data Start Date/Time
|202606102359 URS-3 R/U When Data End Date/Time
|VIP=Y URS-4 R/U What User Qualifier (site-defined)
|@PID.3.1^EQ^P10101 URS-5 R/U Other Results Subject Definition
|OBR^Observation Date URS-6 R/U Which Date/Time Qualifier
|F^Final URS-7 R/U Which Date/Time Status Qualifier
|EQ URS-8 R/U Date/Time Selection Qualifier
|1^^^202606100000^202606102359 URS-9 R/U Quantity/Timing Qualifier
In-context excerpt — QRY registering for stat lab pushes for two patients today:
MSH|^~&|EHR|MAIN|LIS|MAIN|20260610090500||QRY^Q05^QRY_Q05|MSG000361|P|2.5.1
QRD|20260610090500|R|I|QRY000361|||00010^RD|9988^House^Greg^^^DR|RES|T
URD|20260610090000|S|9988^House^Greg^^^DR|CBC^Complete Blood Count^L|LAB^Laboratory^L|WARD_3A|F
URS|@PID.3.1^EQ^P10045~@PID.3.1^EQ^P10046|202606100000|202606102359|||OBR^Observation Date|F^Final|EQ
In-context excerpt — QRY registering for final radiology reports across a date range:
MSH|^~&|EHR|MAIN|RIS|MAIN|20260610091000||QRY^Q05^QRY_Q05|MSG000362|P|2.5.1
QRD|20260610091000|R|I|QRY000362|||00010^RD|10044^Cuddy^Lisa^^^DR|RES|T
URD|20260601000000|R|10044^Cuddy^Lisa^^^DR|XR^X-Ray^L|RAD^Radiology^L|RAD_READING_ROOM|R
URS|@OBR.4.1^EQ^XR_CHEST|202606010000|202606102359|||OBR^Report Date|F^Final|BT
FHIR mapping
No segment-level ConceptMap is published in the v2-to-FHIR IG for URS. The closest FHIR analogue is the search/filter expression behind a Subscription (or SubscriptionTopic in R5): URS-1 predicates correspond to FHIR search parameters and modifiers, URS-2/URS-3 correspond to date-range search parameters, and URS-6/URS-7/URS-8 correspond to which date parameter is used and how the comparator is applied. URS-9 has no clean FHIR equivalent and is usually replaced by channel-level throttling.
Engine considerations
- Parse URS-1 predicates into structured form during routing rather than at evaluation time; the per-message cost is high otherwise.
- When URS-2/URS-3 are open-ended (one bound omitted), document the engine default explicitly. Some engines treat a missing end as "now" and others as "forever".
- Validate URS-6/7/8 codes against HL70156/HL70157/HL70158 on entry. Unknown codes cause silent overmatch.
- URS-9 timing qualifiers interact with engine-level rate limits. Keep both in one place to avoid contradictory cadences.
How Vorro parses and produces URS
Vorro parses URS by splitting URS-1 into structured predicate triples, binding the date window (URS-2/URS-3) to the qualifier triplet (URS-6/URS-7/URS-8) so the evaluator knows which date to compare and how. Producing URS is the inverse: Vorro renders the subscription's normalized selector expression into HL7 predicates, fills the date window and qualifiers from the configured profile, and emits URS-9 only when a cadence is explicitly required.
