NEWFree ROI Calculators — quantify what prior auth and siloed data are costing your organization.Prior Auth ROI Siloed Data ROI
HL7 v2Data Type⏱ 6 min read

HL7 OSP Data Type: Occurrence Span Code and Date

The OSP (Occurrence Span Code and Date) data type was introduced in HL7 v2.4 to carry an institutional-claim occurrence span — a coded billing event together with the start and end dates the event covers. It is one of the small family of UB-04-derived composites (OCE, OCD, OSP, VR) that exist solely to model the data UB-04 institutional claim forms exchange. OSP appears in UB1 and UB2 occurrence-span fields and maps cleanly to the UB-04 form locators that carry the same data.

Purpose

OSP exists because institutional billing distinguishes single-date occurrences (an accident date, a date of onset) from spans with a clear start and end (a qualifying inpatient stay before a SNF admission, a leave of absence, a non-covered stay). The single-date case is handled by OCD (Occurrence Code and Date); spans need two dates, which OSP provides. The coded span reason (OSP.1) draws from HL70351 (Occurrence Span Code), aligned with the NUBC UB-04 occurrence-span code set.

Components

Source: HAPI HL7v2 v2.8.1 javadoc (OSP). Length is not published in v2.8.1 javadocs (—).

CompNameSub-typeLengthReqDescription
OSP.1Occurrence Span Codecwe—RHL70351 (Occurrence Span Code) — the NUBC-aligned reason for the span. Examples: 70 Qualifying Stay Dates, 74 Non-Covered Level of Care, 76 Patient Liability.
OSP.2Occurrence Span Start Datedt—RFirst date of the span. Day-precision DT (YYYYMMDD).
OSP.3Occurrence Span End Datedt—RLast date of the span (inclusive). Day-precision DT (YYYYMMDD).

Most-used components

  • OSP.1 Occurrence Span Code — without it the span is meaningless; HL70351 codes are required for payer adjudication.
  • OSP.2 Occurrence Span Start Date — first day of the span, inclusive.
  • OSP.3 Occurrence Span End Date — last day of the span, inclusive. End-of-day semantics, not midnight-of-next-day.

All three components are required; OSP has no optional slots.

Where it's used

  • UB1-16 Occurrence Span Code/Dates — UB-92 era institutional claim, repeating field.
  • UB2-13 Occurrence Span Code/Dates — UB-92 era institutional claim variant.

UB1 and UB2 both allow the occurrence-span field to repeat, separated by ~, because a single claim commonly carries several spans (e.g. one span for the qualifying inpatient stay, another for a leave-of-absence period). UB1/UB2 themselves are deprecated by HL7 in favor of segments that carry full UB-04 data, but real-world payer interfaces still receive UB1 in v2.x feeds.

Version differences

  • v2.4 — OSP introduced as part of the UB-04 alignment effort. Initial 3 components: ID-typed code, DT, DT.
  • v2.5 — minor revision; field positions in UB1/UB2 unchanged.
  • v2.7 — OSP.1 widened from IS to CWE so payer-specific extension codes can travel with the standard HL70351 value set.
  • v2.8 / v2.8.1 — no structural changes; HAPI v2.8.1 javadoc shows the same 3 components.

Common mistakes

  • Emitting a single date in OSP.2 and leaving OSP.3 empty when the span is a single day. The correct form is the same date in both: 70^Qualifying Stay Dates^HL70351^20260601^20260601. An empty OSP.3 fails NUBC validation.
  • Treating OSP.3 as exclusive (the day after the last covered day). UB-04 occurrence spans are inclusive on both ends; OSP.3 is the last day, not the day after.
  • Sending an OSP where an OCD belongs. OCD (Occurrence Code and Date) is one date; OSP is two. Mixing them shifts every downstream date by one slot.
  • Coding OSP.1 against HL70350 (Occurrence Code) instead of HL70351 (Occurrence Span Code). The two value sets overlap numerically but are not interchangeable — payers reject mis-mapped codes.
  • Using DTM-precision timestamps in OSP.2 or OSP.3. Both are DT (day-precision); timestamps with time components are silently truncated by most engines and may fail strict validators.

Examples

Minimal value

70^Qualifying Stay Dates^HL70351^20260601^20260605

OSP.1 carries the HL70351 code 70 (Qualifying Stay Dates); OSP.2/OSP.3 carry the span boundaries.

Populated value with payer extension code in CWE

70^Qualifying Stay Dates^HL70351^20260601^20260605^^^^Qualifying SNF qualifying stay

The CWE structure of OSP.1 permits alternate text (CWE.9) for payer documentation, while the standard code stays in CWE.1.

Annotated breakdown

70                                             OSP.1.1  Identifier (HL70351 code)
^Qualifying Stay Dates                         OSP.1.2  Text
^HL70351                                       OSP.1.3  Coding System
^20260601                                      OSP.2    Span Start Date (DT)
^20260605                                      OSP.3    Span End Date (DT, inclusive)

In-context excerpt — UB1-16 carrying two occurrence spans

UB1|1||||||||||||||||70^Qualifying Stay Dates^HL70351^20260601^20260605~74^Non-Covered Level of Care^HL70351^20260606^20260608

Two repetitions separated by ~: the qualifying stay span, then the non-covered care span.

Common pitfall snippet

70^Qualifying Stay Dates^HL70351^20260601^

OSP.3 left empty. The receiver cannot compute the span duration; NUBC-aligned validators reject the line. If the span is one day, repeat the date in OSP.3 — do not leave it empty.

FHIR mapping

There is no per-datatype ConceptMap published in the v2-to-FHIR IG for OSP. In practice the type maps to Claim.supportingInfo (or ExplanationOfBenefit.supportingInfo) with category set to a code from http://terminology.hl7.org/CodeSystem/claiminformationcategory such as occurrence-span, code populated from OSP.1, and timingPeriod populated from OSP.2/OSP.3.

OSPFHIR (Claim.supportingInfo)
OSP.1supportingInfo.code (Coding from HL70351)
OSP.2supportingInfo.timingPeriod.start
OSP.3supportingInfo.timingPeriod.end

The supportingInfo.category is fixed to occurrence-span for OSP-derived entries; receivers distinguish OSP-derived spans from OCD-derived single dates by category and by whether timingPeriod or timingDate is populated.

Engine considerations

  • DT precision: OSP.2 and OSP.3 are DT, not DTM. Engines that auto-upgrade DT to DTM and append 000000 produce timestamps that some payer gateways reject.
  • Inclusive end semantics: OSP.3 is inclusive. Engines that compute duration = end - start must add one day, not zero, to get the covered-day count.
  • Repetition in UB1-16: the parent field repeats; engines that flatten the repetition to a single span lose the second, third, and subsequent spans on the claim.
  • CWE widening (v2.7): producers targeting pre-v2.7 receivers should emit OSP.1 with only the IS-style first three CWE components populated to avoid surprising legacy parsers.
  • Value-set drift: HL70351 has had codes retired and added across versions. Engines should not hard-code a closed value set; an unknown code from a newer revision should be passed through and logged rather than rejected.

How Vorro parses and produces OSP

On inbound, Vorro materializes each OSP repetition as a Claim.supportingInfo element with category occurrence-span, code from OSP.1 (mapped via the HL70351-to-claim-information ConceptMap), and timingPeriod from OSP.2/OSP.3. Inclusive-end semantics are preserved — we do not silently shift end by one day. Unknown HL70351 codes pass through with a provenance note.

On outbound, when emitting UB1 for a payer feed, Vorro produces one OSP per Claim.supportingInfo entry with category occurrence-span. We refuse to emit OSP when either date is missing; partial spans are dropped and logged rather than wired with empty OSP.3.

Sources

← Back to HL7 v2 Guide

Ready to Integrate This Into Your Workflow?

Talk to a Vorro expert about implementing HL7 v2 in your specific environment.

Browse HL7 v2 Guides
HL7 OSP Data Type: Occurrence Span Code and Date | Vorro Academy | Vorro