Data Contracts

What flows through DOSE

DOSE receives drug list update files from upstream clients and delivers individual records to RxClaim. Two contracts define what that data looks like at each end:

Contract	Direction	Owner
DOSEPayload.1.0	Upstream → DOSE	DOSE (schema validated)
BasePlanGpiApiRequestModel	DOSE → RxClaim	RxClaim CAT API

The field mapping between the two is maintained in a JOLT specification file in blob storage — not hard-coded.

---

Upstream payload — what clients send

Each file contains an envelope describing the submission, and a list of GPI plan records to process.

Submission envelope

Field	Description
upstreamApplicationId	Identifies the sending system (e.g. CLIC)
upstreamTaskId	Upstream task or work order reference
workOrderRequestId	Business work order identifier
submittingUser	User who initiated the submission
submissionTimestamp	When the file was submitted
batchRecordCount	Total number of records in the file

Each record

Record metadata (recordMeta) — all fields required:

Field	Type	Description
doseId	integer	Auto-assigned by DOSE — unique record identifier
requestId	string	Upstream request reference
requestRecordId	integer	Position of this record within the request
targetRxClaimEnv.server	enum	RxClaim server to target (see table below)
targetRxClaimEnv.schema	string	RxClaim schema name (paired with server)
action	enum	ADD (only supported action in Phase 1)

RxClaim environment routing — server and schema are validated as a pair:

Server	Schema	Environment
RXDV1	CLMV25FIL	Development
RXBK1UAT / RXBCHUAT	CLMPRDFIL	UAT
RXBK1 / RXBCH	CLMPRDFIL	Production
RXCL1TST	CLMHA4FIL or CLMQA6FIL	Test

Each record independently specifies its target environment. Records in the same file can route to different RxClaim environments.

Record data (recordData) — core drug details:

Field	Required	Description
gpi	Yes	14-character Generic Product Identifier
listId	Yes	GPI list name (1–10 chars)
fromDate	Yes	Effective date
msc	No	Multi-source code — *, B, M, N, O, Y (default *)
rxOtc	No	Rx/OTC indicator — *, N, O, P, R, S, Y (default *)
thruDate	No	Termination date
drugStatus	No	Drug status code — 50+ valid values (default F)
(50+ additional optional fields)	No	Dosing limits, pricing, contingent therapy, messages

Complex optional sub-objects:

Sub-object	What it captures
price	Pricing schedules — pharmacy, client, copay, tier
quantityLimitsOverride	Date-specific quantity/days supply overrides
drugStatusTable	Date-ranged drug status with group renewal
contingentTherapySchedule	Contingent therapy protocol and date range
bypassContingentTherapyConditions	Conditions under which contingent therapy is bypassed
message	Message codes shown at point of sale
note	Free-text note (up to 50 chars)

---

Field mapping — how DOSE fields become RxClaim fields

The mapping is JOLT-driven. Key mappings for Phase 1:

DOSE field	RxClaim field	Notes
targetRxClaimEnv.schema	rxclaimEnvironment	Top-level routing
action	pgoPlanGpiOptionsDtl.action
listId	gpiListName
gpi	genericProductId
msc	productMsc
rxOtc	productOtc
fromDate	currentEffDate AND intentProductEffDate	Maps to two fields
thruDate	currentTermDate
drugStatus	currentDrugStatus

Changing a field mapping requires updating the JOLT spec file in blob storage — not a code change or deployment.

---

RxClaim CAT API — what DOSE sends downstream

One HTTP call per record:

POST /v1/rxclaim/plan/gpi/

Rate limits: 75 calls/sec · 10,000/hour · 30,000/day · 2,100ms response SLA

---

Record and job status tracking

Upload job (upstream_job) — one per file:

Initiated → Uploaded → Processing → Completed
                                  → Partial Failed → (retry) → Processing
                                  → Error

Individual record (IntentRecord) — one per record in the file:

In Progress → Completed
            → Validation Failed   (never retried — upstream notified)
            → Failed              (RxClaim rejected — never retried)
            → Retry Pending → In Progress