UDDL v0.1: Unit Discount Dispositions & Lineage -

UDDL v0.1

Unit Discount Disposition & Lineage

A public technical profile for unit-level MFP / 340B / MDRP assertion lineage, nonduplication analysis, and reconciliation receipts

Status: Draft v0.1 Date: June 2026 draft Author: Andrew Vargas Intended license: CC BY 4.0 for specification text; Apache-2.0 for reference implementation and synthetic fixture suite Intended audience: manufacturers, covered entities, TPAs, PBMs, Part D operators, state Medicaid programs, standards participants, auditors, policy analysts, and regulated-informatics builders

UDDL is independent public work authored personally by Andrew Vargas. It is not affiliated with, sponsored by, or endorsed by any employer, client, manufacturer, covered entity, government agency, payer, PBM, TPA, or 340B platform vendor.

0. Draft notice

UDDL v0.1 is an independent public technical draft authored personally by Andrew Vargas. It is not affiliated with, sponsored by, or endorsed by any employer, client, manufacturer, covered entity, government agency, payer, PBM, TPA, or 340B platform vendor.

This draft is not legal advice. It is not an official implementation guide. It is not a determination that any stakeholder’s practice is compliant or noncompliant. It is a neutral data-contract and fixture profile for making unit-level discount disposition more legible, replayable, and auditable.

UDDL v0.1 uses only public policy materials, public standards concepts, synthetic fixtures, and independently developed registry design patterns. It does not rely on employer systems, customer data, proprietary client architecture, protected health information, non-public implementation details, or internal data-plane vocabulary.

UDDL v0.1 deliberately avoids prescribing disputed policy variables such as designation lookback windows, claims-submission windows, manufacturer denial standards, or covered-entity documentation obligations. It provides a way to declare those variables, test them against fixtures, and preserve receipts showing how they affected a unit-level outcome.

0.1 Reading guide

UDDL is written for a mixed policy, operations, and engineering audience.

For policy readers: Start with §§1–4, §14, §15, and §§19–21. These sections explain the problem, source lineage, the worked flow, the fixture suite, governance, and the conflicts policy.

For implementers: Start with §§5–13 and §§15–16. These sections define canonical hashing, the core schemas, evidence contracts, match profiles, the resolver, adapter bindings, fixtures, and conformance levels.

For covered-entity and manufacturer operations teams: Start with §§1–3, §8, §9, §11, and §§13–14. These sections explain assertions, evidence contracts, the payment clock, nonpayment notices, and the retroactive designation flow.

For reviewers: Focus on whether the fixture suite describes recognizable real-world failure modes, whether the evidence-contract model is neutral, and whether any field silently embeds a policy position.

0.2 Normative language

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as normative only when written in uppercase.

Lowercase uses of these words are descriptive.

1. Problem statement

The MFP / 340B / MDRP nonduplication problem is often described as a pricing, payment, audit, or policy dispute. UDDL treats it as a regulated data lineage problem.

A single dispensed drug unit may become relevant to multiple discount, rebate, or price-effectuation programs:

Medicare Maximum Fair Price under the Medicare Drug Price Negotiation Program
340B ceiling price eligibility
Medicaid Drug Rebate Program duplicate-discount exclusion
Other government or commercial rebate contexts in future profiles

The core difficulty is that the unit’s discount disposition is not a static field available at adjudication. It is a set of assertions made by different parties at different times, under different evidence standards, through transaction surfaces that lose meaning.

A Part D claim, PDE-derived record, MTF Data Module file, third-party 340B claims-designation CSV, TPA export, Medicaid invoice, manufacturer effectuation file, and credit/debit ledger entry are all projections.

None is automatically the governed source of truth.

UDDL v0.1 defines a minimal grammar for:

Representing a dispensed Part D unit.
Recording immutable discount assertions against that unit.
Evaluating assertions against evidence contracts.
Matching external records to dispense events using governed matcher profiles.
Resolving MFP / 340B nonduplication using versioned resolver profiles.
Preserving as-of replayability when late data changes the result.
Emitting receipts showing what was known, asserted, matched, lost, resolved, paid, not paid, credited, debited, or routed for review.

The thesis:

The MFP / 340B collision is not only a money problem. It is undeclared lossiness at every boundary. UDDL makes the lossiness declared, versioned, hashed, replayable, and auditable.

2. Scope of v0.1

2.1 In scope

UDDL v0.1 covers:

Medicare Part D dispense events
NDC-11 unit identification
MFP assertion space
340B assertion space
MDRP exposure assertion space
Program eligibility assertions
Program ineligibility assertions
Program exposure assertions
Late-arriving 340B designations
Re-resolution after new assertions
Credit/debit delta receipt generation after changed disposition
Nonpayment notice receipts when MFP is not paid due to a claimed exception
Hashed price-file references for lower-of comparison
Synthetic fixtures only
One fully worked generic consume binding: third-party 340B claims-designation CSV
Stub bindings for MTF Data Module, NCPDP N1 / 420-DK, PDE-derived records, TPA exports, Medicaid invoice rows, and manufacturer effectuation files

2.2 Out of scope for v0.1

UDDL v0.1 does not cover:

Medicare Part B buy-and-bill workflow
NDC-HCPCS crosswalk resolution
Medical claim line unit conversion
Provider-administered drug wastage, JW/JZ, or modifier logic
Live PHI ingestion
Covered-entity procurement replacement
Split-billing TPA replacement
Rebate contracting terms
Legal determinations of 340B eligibility
Clinical vocabulary, CRD, DTR, PAS, or payer PA workflow
Any employer-specific architecture, schema names, retrieval model, data plane, customer pattern, or internal implementation detail

2.3 v0.2 horizon

UDDL v0.2 should address Part B and medical-benefit unit disposition, including:

NDC-HCPCS crosswalks
HCPCS billing units versus NDC package units
Buy-and-bill acquisition evidence
Medical claim modifier surfaces
Site-of-care and provider-administered drug evidence
Part B selected-drug MFP effectuation and nonduplication fixtures
Cross-party deterministic hashing agreements
More formal multi-party dispute and appeal payloads

3. Design principles

3.1 Every external surface is a projection

A projection is any artifact that represents a unit, claim, assertion, payment, rebate, refund, designation, or denial without being the governed unit-disposition record itself.

Examples:

PDE-derived record
MTF Data Module transmission
third-party 340B claims-designation CSV
TPA export
NCPDP N1 / 420-DK transaction
Medicaid rebate invoice
covered-entity accumulator report
manufacturer effectuation file
nonpayment notice
credit/debit ledger output
dispute packet
remittance artifact

A projection MUST declare:

source artifact
binding profile
transformation version
known field loss
unknown field residue
correlation method
envelope hash
emitted timestamp
consumer obligations

No projection may silently become source of truth.

3.2 Declared lossiness

UDDL assumes every transaction surface loses meaning unless proven otherwise.

A consume binding MUST classify each incoming field as one of:

mapped
normalized
ignored_with_reason
quarantined
residue_preserved

A mapped field is used in a UDDL object.

A normalized field is transformed into canonical form.

An ignored field is not used, but the reason is explicit.

A quarantined field is preserved but cannot be trusted until reviewed.

A residue field is preserved in a residue hash so that “what did we not consume?” remains answerable later.

3.3 Bitemporal truth

UDDL distinguishes:

valid time: the real-world date or period the assertion refers to, usually date of service, date of dispense, date of acquisition, price-applicability period, or claim-level-data period
transaction time: when the assertion, file, evidence, match result, payment response, or receipt entered the governed record

Late-arriving 340B designations are not anomalies. They are expected transaction-time updates against earlier valid-time dispense events.

3.4 Assertions, not fields

UDDL does not treat “340B,” “MFP,” “MDRP,” or “dual eligible” as static claim fields.

They are assertions.

An assertion has:

a program
a polarity
an assertion type
an asserting party
evidence
lifecycle state
valid time
transaction time
source artifact lineage
evidence contract satisfaction

Missing information is not represented as a confidence score. Missing information is represented as missing evidence against a published evidence contract.

3.5 Immutability

DispenseEvent, DiscountAssertion, and UnitDispositionReceipt objects are immutable once canonicalized and hashed.

Objects MUST NOT be mutated to add late-arriving context.

Late-arriving context is represented as a new assertion, new adapter event, new match result, or new receipt that points back to prior immutable objects.

A response to an assertion is a new DiscountAssertion with in_response_to populated. It is not an updated field on the original assertion.

Derived states such as CONTESTED, SUPERSEDED_BY_LATER_RECEIPT, or DUPLICATE_DISCOUNT_RISK are produced by resolver logic and receipts. They are not mutable fields on the source event.

3.6 No bare confidence floats

UDDL does not use generic confidence scores for financial disposition.

A financial assertion is:

supported by a stated evidence contract
missing required evidence
contradicted by another active assertion
matched with declared skew
quarantined
rejected
or routed for review

Uncertainty is expressed through:

missing required facts
conflicting active assertions
lossy binding classification
matcher status
unresolved residue
review-required outcomes

3.7 Confidential price protection

UDDL supports lower-of MFP / 340B comparisons without exposing confidential price values in public receipts.

The resolver MAY reference:

mfp_price_file_ref
ceiling_price_file_ref
price_period_ref
price_comparison_method_hash

The receipt records that the comparison was performed against pinned price-file versions. It does not need to disclose the underlying price values.

3.8 As-of replayability

Every resolution MUST be replayable as of a point in transaction time.

A receipt should answer:

What did the resolver know when claim-level data elements were received from the MTF DM?
What did the resolver know within the 14-day prompt MFP payment window?
What evidence arrived later?
Which assertion changed the result?
Which prior receipt was superseded?
What delta was produced?
Which emitted artifacts followed from the delta?
Did review routing alter the payment action or deadline?

3.9 Payment-deadline neutrality

A resolution outcome and a payment action can diverge.

For example, a unit may be routed for review due to match skew, but the manufacturer may still need to transmit a payment or claim-level payment response within an applicable deadline.

UDDL receipts MUST distinguish:

resolution_outcome
payment_action
deadline_status
review_status

Routing to review does not automatically pause a payment obligation. UDDL does not define legal obligations; it preserves the data needed to show how a payment or nonpayment response was made under a declared policy clock.

3.10 Salt-boundary limitation

UDDL v0.1 permits hashed references for privacy-preserving correlation, but equality matching on hashed values only works within a shared salt or key boundary.

Therefore:

Matching on claim_ref_hash, pde_ref_hash, rx_ref_hash, or party reference hashes is valid within a single operator’s salt boundary.
Cross-party hash equality matching requires a shared deterministic hashing agreement, key governance model, or privacy-preserving record linkage mechanism.
Cross-party deterministic hashing agreements are explicitly out of scope for v0.1 and reserved for v0.2.

When no shared hash boundary exists, implementations MUST either:

degrade to structural matching with receipt disclosure,
quarantine the match,
route review,
or reject the match.

The matcher MUST disclose which path occurred.

3.11 Runtime PHI boundary

UDDL v0.1 public fixtures contain no PHI.

In production implementations, claims, patient identifiers, Rx numbers, prescribers, pharmacies, covered entities, and other sensitive records should be referenced by salted hashes, controlled runtime references, or protected-environment pointers.

UDDL public objects MUST NOT copy PHI into durable public payloads.

PHI and privacy posture are represented at the fixture, adapter, deployment, or runtime-policy layer, not as mutable fields on each core object.

4. Source artifact model

4.1 SourceArtifact

A SourceArtifact is a pinned public, observed, synthetic, or private-runtime artifact used to derive a rule, binding, fixture, evidence contract, match profile, or resolver profile.

Examples:

IRA statutory provision
CMS final guidance
HRSA RFI
Federal Register notice
selected-drug list
MFP price file
340B ceiling price file
PDE-derived synthetic record sample
third-party 340B claims-designation CSV sample
TPA export sample
Medicaid invoice sample
manufacturer effectuation file sample

Minimum fields:

json

{
  "source_artifact_id": "src_cms_ipay2027_final_guidance",
  "title": "CMS IPAY 2027 Final Guidance and Manufacturer Effectuation of MFP in 2026 and 2027",
  "source_class": "PUBLIC_AUTHORITY",
  "publisher": "CMS",
  "publication_date": "2024-10-02",
  "retrieved_at": "2026-06-10T00:00:00Z",
  "uri_ref": "<official-source-uri>",
  "content_hash": "sha256:<hash>",
  "version_label": "final",
  "supersedes": [],
  "superseded_by": [],
  "notes": "Used for MFP effectuation, lower-of logic, MTF DM claim-level data transmission, 14-day prompt MFP payment window, payment response, nonpayment explanation, and credit/debit ledger anchors."
}

4.2 Source classes

UDDL recognizes the following source classes:

json

[
  "PUBLIC_AUTHORITY",
  "PUBLIC_STANDARD",
  "PUBLISHED_GUIDANCE",
  "PUBLIC_COMMENT",
  "OBSERVED_FORMAT",
  "SYNTHETIC_FIXTURE",
  "PRIVATE_RUNTIME_REFERENCE"
]

OBSERVED_FORMAT is used when a format is not a formally published implementation guide but can be bound to a hashed observed sample with stated provenance.

An observed-format binding MUST NOT be based on vague field memory or unpinned “industry format” assumptions.

If a binding is modeled from publicly available data-element documentation, that documentation should be represented as PUBLIC_STANDARD, PUBLISHED_GUIDANCE, or PUBLIC_AUTHORITY, as applicable. The synthetic CSV used to test the binding should be represented separately as SYNTHETIC_FIXTURE.

4.3 ContextAnchor

A ContextAnchor is a specific cited span, paraphrased rule atom, or derived implementation implication from a SourceArtifact.

Minimum fields:

json

{
  "context_anchor_id": "ctx_mtf_claim_data_clock_001",
  "source_artifact_id": "src_cms_ipay2027_final_guidance",
  "anchor_type": "rule_atom",
  "statement_type": "PARAPHRASE",
  "locator": {
    "page": "<page>",
    "section": "40.4.2",
    "line_ref": "<local-extraction-ref>"
  },
  "statement": "The MTF DM transmission of claim-level data elements to the Primary Manufacturer starts the 14-day prompt MFP payment window; the date of transmission is day 0.",
  "content_hash": "sha256:<hash>"
}

statement_type MUST be one of:

json

[
  "EXCERPT",
  "PARAPHRASE",
  "DERIVED_IMPLEMENTATION_RULE"
]

A PARAPHRASE MUST NOT be represented as a direct quotation.

A DERIVED_IMPLEMENTATION_RULE MUST cite the source anchors used to derive it.

4.4 Required v0.1 source anchors

UDDL v0.1 should define anchors for at least:

MTF DM claim-level data elements sent to manufacturers.
14-day prompt MFP payment window clock start.
Claim-level payment elements due within the payment window.
Nonpayment explanation or documentation when no MFP refund is provided.
Lower-of MFP / 340B ceiling price logic.
Credit/debit ledger mechanism.
CMS position on not requiring a 340B modifier at this time.
CMS position on not assuming responsibility for MFP / 340B nonduplication at this time.
HRSA RFI questions about costs, cash flow, denials, data elements, privacy/security, duplicate discounts, timing mismatches, and minimum data elements.

5. Canonical serialization and hashing

5.1 Purpose

UDDL uses hashes to make object identity, fixture replay, residue preservation, and receipt validation deterministic.

Without canonical serialization, two implementations can produce different hashes for the same logical object. UDDL therefore defines a canonicalization rule.

5.2 Canonical JSON

All UDDL object hashes MUST be computed over JSON canonicalized according to RFC 8785, JSON Canonicalization Scheme (JCS), unless a later UDDL version explicitly replaces this rule.

The canonicalization profile requires:

UTF-8 generation
deterministic property sorting
no insignificant whitespace
preservation of array order
no duplicate property names
JSON values compatible with the I-JSON subset

5.3 Hash algorithm

UDDL v0.1 uses SHA-256.

Hash values MUST be represented as lowercase hexadecimal strings prefixed with sha256:.

Example:

json

{
  "dispense_event_hash": "sha256:8e4c..."
}

5.4 Hash exclusion rule

An object’s own hash field MUST be excluded from the canonicalization input used to compute that hash.

For example, dispense_event_hash is excluded when computing the hash of a DispenseEvent.

If an object contains multiple hashes, each hash definition MUST state which fields are included or excluded.

5.5 Envelope hashes

A receipt may include:

object hash
input envelope hash
output envelope hash
residue manifest hash
composition hash
fixture package hash

The input_envelope_hash is computed over the set of canonicalized input object hashes and profile hashes considered by the resolver.

The composition_hash is computed over the receipt body excluding receipt_hash.

6. Core object model

UDDL v0.1 adds three core immutable schemas:

DispenseEvent
DiscountAssertion
UnitDispositionReceipt

It also adapts profile and event families:

DesignationEvidenceContract
NonduplicationResolutionProfile
DiscountMatcherProfile
AdapterBinding
AdapterEvent

Only the first three are core schemas. The profile and adapter objects are supporting profile machinery.

7. Schema 1: DispenseEvent

7.1 Purpose

DispenseEvent represents the canonical unit-level dispense event against which discount assertions are made.

It is not a claim copy. It is a minimal, immutable, hashed event envelope.

7.2 Schema

json

{
  "schema": "uddl.dispense_event",
  "schema_version": "0.1.0",

  "dispense_event_id": "de_synth_0001",
  "dispense_event_hash": "sha256:<canonical-event-hash>",

  "drug": {
    "ndc11": "00000000000",
    "quantity_dispensed": "30",
    "quantity_unit": "tablet",
    "days_supply": 30
  },

  "service": {
    "date_of_service": "2026-01-15",
    "fill_number": 0
  },

  "entity_refs": {
    "dispensing_entity_ref_hash": "sha256:<salted-dispensing-entity-ref>",
    "prescriber_ref_hash": "sha256:<salted-prescriber-ref-or-null>"
  },

  "claim_refs": {
    "claim_ref_hash": "sha256:<salted-claim-ref-or-null>",
    "pde_ref_hash": "sha256:<salted-pde-ref-or-null>",
    "rx_number_ref_hash": "sha256:<salted-rx-ref-or-null>",
    "mtf_internal_claim_ref_hash": "sha256:<salted-mtf-ref-or-null>"
  },

  "program_refs": {
    "selected_drug_ref": {
      "source_artifact_id": "src_cms_selected_drug_list_ipay2026",
      "content_hash": "sha256:<selected-drug-list-hash>",
      "version_label": "IPAY-2026"
    },
    "price_period_ref": {
      "source_artifact_id": "src_price_period_2026_q1",
      "content_hash": "sha256:<price-period-hash>"
    }
  },

  "time": {
    "valid_time": {
      "start": "2026-01-15",
      "end": "2026-01-15"
    },
    "transaction_time": "2026-01-17T15:10:00Z"
  },

  "source_lineage": {
    "created_from_adapter_event_id": "ae_pde_derived_consume_0001",
    "source_artifact_ids": [
      "src_cms_ipay2027_final_guidance",
      "src_synthetic_pde_derived_fixture"
    ]
  }
}

7.3 Rules

A DispenseEvent MUST:

include NDC-11
include quantity dispensed
include date of service
include valid time
include transaction time
include source lineage
use hashed references for claims and sensitive entities
remain immutable after canonicalization

A DispenseEvent MUST NOT:

copy patient identifiers
copy raw Rx numbers
copy raw claim IDs
copy raw covered-entity identifiers into public fixture payloads
include benefit_context_refs
include links to assertions that may arrive later
mutate when later assertions are received

Benefit context is derived by querying active assertions that point at the event. The event does not point back to those assertions.

7.4 Quantity representation

quantity_dispensed is represented as a string to avoid floating-point canonicalization ambiguity.

Production implementations may validate it as a decimal string.

8. Schema 2: DiscountAssertion

8.1 Purpose

DiscountAssertion records that a party asserts a program-specific disposition about a DispenseEvent.

Examples:

A system asserts the unit is MFP eligible based on MTF DM claim-level data.
A covered entity asserts the unit is 340B eligible.
A TPA asserts a 340B designation based on accumulator decrement and replenishment linkage.
A manufacturer asserts the unit is 340B ineligible.
A state Medicaid process asserts MDRP rebate exposure.
A manufacturer responds to a covered-entity assertion by asserting denial rationale through in_response_to.

8.2 Schema

json

{
  "schema": "uddl.discount_assertion",
  "schema_version": "0.1.0",

  "assertion_id": "da_340b_eligible_0001",
  "assertion_hash": "sha256:<canonical-assertion-hash>",

  "subject": {
    "dispense_event_id": "de_synth_0001",
    "dispense_event_hash": "sha256:<canonical-event-hash>"
  },

  "program": "340B",
  "polarity": "ELIGIBLE",
  "assertion_type": "PROGRAM_DESIGNATION",

  "asserted_by": {
    "party_class": "COVERED_ENTITY",
    "party_ref_hash": "sha256:<salted-party-ref>"
  },

  "in_response_to": null,

  "lifecycle": {
    "state": "ACTIVE",
    "supersedes": [],
    "superseded_by": []
  },

  "evidence_contract_ref": {
    "contract_id": "ec_340b_designation_partd_v0_1",
    "contract_hash": "sha256:<contract-hash>"
  },

  "evidence_refs": [
    "ev_designation_csv_row_0001",
    "ev_accumulator_decrement_0001",
    "ev_replenishment_po_link_0001"
  ],

  "evidence_satisfaction": {
    "required_facts_met": [
      "ndc11_match",
      "date_of_service_present",
      "quantity_present",
      "designation_source_present"
    ],
    "required_facts_missing": [
      "covered_entity_ref_present"
    ],
    "optional_facts_present": [
      "accumulator_decrement"
    ],
    "residue_manifest_hash": "sha256:<residue-hash>",
    "result": "PARTIALLY_SATISFIED_ROUTE_REVIEW"
  },

  "time": {
    "valid_time": {
      "start": "2026-01-15",
      "end": "2026-01-15"
    },
    "transaction_time": "2026-02-03T09:40:00Z"
  },

  "source_lineage": {
    "source_artifact_ids": [
      "src_public_designation_csv_docs_001",
      "src_synthetic_designation_csv_fixture_001"
    ],
    "created_from_adapter_event_id": "ae_designation_csv_consume_0001"
  }
}

8.3 Immutability rule

A DiscountAssertion MUST NOT be mutated after hashing.

A counterparty response is represented as a new DiscountAssertion with in_response_to populated.

Example:

json

{
  "assertion_id": "da_mfr_340b_ineligible_response_0001",
  "program": "340B",
  "polarity": "INELIGIBLE",
  "assertion_type": "COUNTERPARTY_RESPONSE",
  "in_response_to": "da_340b_eligible_0001"
}

8.4 Program enumeration

json

[
  "340B",
  "MFP",
  "MDRP",
  "COMMERCIAL_REBATE",
  "TRICARE"
]

UDDL v0.1 implements 340B, MFP, and MDRP.

Other values are reserved for future expansion.

8.5 Polarity constraints by program

Polarity is constrained by program.

json

{
  "340B": [
    "ELIGIBLE",
    "INELIGIBLE"
  ],
  "MFP": [
    "ELIGIBLE",
    "INELIGIBLE"
  ],
  "MDRP": [
    "EXPOSED",
    "NOT_EXPOSED"
  ],
  "COMMERCIAL_REBATE": [
    "EXPOSED",
    "NOT_EXPOSED"
  ],
  "TRICARE": [
    "EXPOSED",
    "NOT_EXPOSED"
  ]
}

MDRP_ELIGIBLE is not a valid representation.

8.6 Assertion types

json

[
  "PROGRAM_DESIGNATION",
  "PROGRAM_INELIGIBILITY",
  "BENEFIT_CONTEXT",
  "PRICE_PERIOD",
  "CLAIM_LEVEL_DATA_RECEIVED",
  "PAYMENT_RESPONSE",
  "NONPAYMENT_RESPONSE",
  "COUNTERPARTY_RESPONSE",
  "MDRP_EXPOSURE",
  "CARVE_OUT_STATUS",
  "MATCH_RESULT"
]

8.7 Party classes

json

[
  "COVERED_ENTITY",
  "MANUFACTURER",
  "TPA",
  "MTF",
  "PAYER",
  "PART_D_SPONSOR",
  "STATE_MEDICAID_AGENCY",
  "PBM",
  "DISPENSING_ENTITY",
  "AUDITOR",
  "SYSTEM"
]

8.8 Lifecycle states

json

[
  "PROPOSED",
  "ACTIVE",
  "SUPERSEDED",
  "WITHDRAWN",
  "REJECTED",
  "RETIRED"
]

CONTESTED is not a lifecycle state. It is a derived state created when conflicting active assertions exist for the same dispense event, program, and valid-time interval.

DENIED is not a lifecycle state. A denial is represented as a new assertion or as a nonpayment response emitted through an AdapterEvent.

9. Adapted profile: DesignationEvidenceContract

9.1 Purpose

A DesignationEvidenceContract defines what evidence is required for a program assertion to be treated as resolvable under a profile.

It answers:

What counts as proof?
What evidence class is acceptable?
Which facts are required?
Which facts are optional?
What happens when evidence is missing?
Which evidence may be hashed rather than disclosed?
Which policy variables are declared by a profile rather than fixed by UDDL?

9.2 No default lookback window

UDDL v0.1 does not set a default lookback window.

Designation windows, submission windows, rebate windows, denial windows, correction windows, and lookback intervals are policy variables.

They MUST be declared by the relevant evidence contract, resolver profile, implementation profile, or legal/operational policy outside the core UDDL schema.

9.3 Schema

json

{
  "schema": "uddl.designation_evidence_contract",
  "schema_version": "0.1.0",

  "contract_id": "ec_340b_designation_partd_v0_1",
  "contract_hash": "sha256:<contract-hash>",

  "program": "340B",
  "assertion_type": "PROGRAM_DESIGNATION",
  "polarity_supported": [
    "ELIGIBLE",
    "INELIGIBLE"
  ],

  "policy_variables": {
    "lookback_window": {
      "declared_by_profile": true,
      "value": null,
      "unit": null,
      "notes": "UDDL v0.1 does not prescribe a default lookback window."
    },
    "submission_window": {
      "declared_by_profile": true,
      "value": null,
      "unit": null
    },
    "denial_response_window": {
      "declared_by_profile": true,
      "value": null,
      "unit": null
    }
  },

  "required_facts": [
    {
      "fact_id": "ndc11_match",
      "description": "The assertion must identify the same NDC-11 as the dispense event or a transformable equivalent under a declared binding.",
      "acceptable_evidence_classes": [
        "DESIGNATION_CSV_ROW",
        "TPA_EXPORT_ROW",
        "CLAIM_EXTRACT",
        "PDE_DERIVED_ROW"
      ],
      "on_missing": "REJECT_ASSERTION"
    },
    {
      "fact_id": "date_of_service_present",
      "description": "The assertion must reference a date of service or dispense date compatible with the dispense event.",
      "acceptable_evidence_classes": [
        "DESIGNATION_CSV_ROW",
        "TPA_EXPORT_ROW",
        "CLAIM_EXTRACT"
      ],
      "on_missing": "ROUTE_REVIEW"
    },
    {
      "fact_id": "quantity_present",
      "description": "The assertion must include quantity or a transformable quantity basis.",
      "acceptable_evidence_classes": [
        "DESIGNATION_CSV_ROW",
        "TPA_EXPORT_ROW",
        "CLAIM_EXTRACT"
      ],
      "on_missing": "ROUTE_REVIEW"
    },
    {
      "fact_id": "designation_source_present",
      "description": "The assertion must identify who made the designation and when.",
      "acceptable_evidence_classes": [
        "DESIGNATION_CSV_ROW",
        "TPA_EXPORT_ROW",
        "AUDIT_LOG_ENTRY"
      ],
      "on_missing": "REJECT_ASSERTION"
    }
  ],

  "optional_facts": [
    {
      "fact_id": "covered_entity_ref_present",
      "acceptable_evidence_classes": [
        "DESIGNATION_CSV_ROW",
        "TPA_EXPORT_ROW",
        "CE_REGISTRY_PIN"
      ]
    },
    {
      "fact_id": "accumulator_decrement",
      "acceptable_evidence_classes": [
        "ACCUMULATOR_REPORT"
      ]
    },
    {
      "fact_id": "replenishment_po_link",
      "acceptable_evidence_classes": [
        "PURCHASE_ORDER_LINK",
        "VIRTUAL_INVENTORY_REPORT"
      ]
    },
    {
      "fact_id": "contract_pharmacy_ref",
      "acceptable_evidence_classes": [
        "DESIGNATION_CSV_ROW",
        "TPA_EXPORT_ROW"
      ]
    }
  ],

  "privacy": {
    "raw_patient_identifiers_allowed": false,
    "salted_hash_refs_allowed": true,
    "runtime_pointer_allowed": true
  },

  "missing_behavior": {
    "missing_required_fact": "ROUTE_REVIEW_OR_REJECT_AS_DECLARED",
    "missing_optional_fact": "ALLOW_WITH_RECEIPT_NOTE",
    "unmapped_residue_present": "PRESERVE_RESIDUE_HASH"
  }
}

9.4 Evidence classes

json

[
  "CLAIM_EXTRACT",
  "PDE_DERIVED_ROW",
  "MTF_DM_ROW",
  "DESIGNATION_CSV_ROW",
  "TPA_EXPORT_ROW",
  "ACCUMULATOR_REPORT",
  "PURCHASE_ORDER_LINK",
  "VIRTUAL_INVENTORY_REPORT",
  "CE_REGISTRY_PIN",
  "MEDICAID_INVOICE_ROW",
  "STATE_CARVE_OUT_FILE",
  "MANUFACTURER_EFFECTUATION_FILE",
  "AUDIT_LOG_ENTRY",
  "PRICE_FILE_PIN",
  "PUBLIC_AUTHORITY_ANCHOR",
  "SYNTHETIC_FIXTURE"
]

10. Governed matcher: DiscountMatcherProfile

10.1 Purpose

A matcher is not an implementation detail. It is a governed object.

UDDL requires match logic to be versioned, declared, and included in receipts because correlation across PDE-derived records, MTF DM rows, designation CSV rows, TPA exports, and Medicaid invoice rows may depend on fall-through matching rather than perfect shared identifiers.

10.2 Illustrative profile values

Any tolerances shown in this document, including date skew or quantity tolerance, are illustrative only.

Production profiles MUST declare their own tolerances, units, transformations, and review behavior.

UDDL does not prescribe a default tolerance.

10.3 Salt-boundary disclosure

A matcher profile MUST disclose whether a correlation tier operates:

within a single operator salt boundary
across parties using a shared deterministic hashing agreement
through structural matching only
through privacy-preserving record linkage
or through manual review

10.4 Schema

json

{
  "schema": "uddl.discount_matcher_profile",
  "schema_version": "0.1.0",

  "matcher_profile_id": "mp_partd_unit_matcher_v0_1",
  "matcher_profile_hash": "sha256:<matcher-profile-hash>",
  "version": "0.1.0",

  "applies_to": [
    "PDE_DERIVED_ROW",
    "MTF_DM_ROW",
    "DESIGNATION_CSV_ROW",
    "TPA_EXPORT_ROW"
  ],

  "salt_boundary": {
    "scope": "SINGLE_OPERATOR",
    "cross_party_hash_matching_supported": false,
    "notes": "Hash equality tiers apply only when the compared artifacts were hashed under a shared salt or key boundary."
  },

  "correlation_hierarchy": [
    {
      "tier": 1,
      "name": "exact_claim_ref_within_salt_boundary",
      "required_keys": [
        "claim_ref_hash"
      ],
      "salt_boundary_required": true,
      "match_result": "MATCHED_EXACT"
    },
    {
      "tier": 2,
      "name": "mtf_or_pde_ref_within_salt_boundary",
      "required_keys": [
        "mtf_internal_claim_ref_hash",
        "pde_ref_hash"
      ],
      "salt_boundary_required": true,
      "match_result": "MATCHED_EXACT"
    },
    {
      "tier": 3,
      "name": "ndc_dos_qty_dispensing_entity",
      "required_keys": [
        "ndc11",
        "date_of_service",
        "quantity_dispensed",
        "dispensing_entity_ref_hash"
      ],
      "salt_boundary_required": false,
      "declared_tolerance_profile_ref": "tol_exact_structural_v0_1",
      "match_result": "MATCHED_STRUCTURAL"
    },
    {
      "tier": 4,
      "name": "ndc_dos_qty_with_declared_skew",
      "required_keys": [
        "ndc11",
        "date_of_service",
        "quantity_dispensed"
      ],
      "salt_boundary_required": false,
      "declared_tolerance_profile_ref": "tol_illustrative_skew_v0_1",
      "match_result": "MATCHED_WITH_SKEW"
    }
  ],

  "failure_modes": [
    "UNMATCHED_QUARANTINED",
    "MULTIPLE_CANDIDATES_ROUTE_REVIEW",
    "INSUFFICIENT_KEYS_REJECT_MATCH",
    "MATCHED_WITH_SKEW_ROUTE_REVIEW",
    "HASH_BOUNDARY_MISMATCH_DEGRADE_TO_STRUCTURAL"
  ],

  "receipt_requirements": {
    "include_matcher_profile_hash": true,
    "include_match_tier": true,
    "include_match_result": true,
    "include_skew_fields": true,
    "include_candidate_count": true,
    "include_salt_boundary_status": true
  }
}

10.5 Match results

json

[
  "MATCHED_EXACT",
  "MATCHED_STRUCTURAL",
  "MATCHED_WITH_SKEW",
  "UNMATCHED_QUARANTINED",
  "MULTIPLE_CANDIDATES_ROUTE_REVIEW",
  "INSUFFICIENT_KEYS_REJECT_MATCH",
  "HASH_BOUNDARY_MISMATCH_DEGRADE_TO_STRUCTURAL"
]

A MATCHED_WITH_SKEW result MUST NOT silently resolve as exact. It must either route review or produce a receipt with explicit skew rationale.

11. Adapted profile: NonduplicationResolutionProfile

11.1 Purpose

A NonduplicationResolutionProfile defines how active assertions are resolved into a unit-disposition outcome under a declared evidence state.

The resolver does not determine legal truth. It applies a declared profile to bounded evidence and emits an auditable receipt.

11.2 Payment clock

For MFP effectuation, UDDL v0.1 models the 14-day prompt MFP payment window as beginning when the MTF DM transmits claim-level data elements to the manufacturer.

The clock-starting event is represented as a consumed AdapterEvent.

The date of MTF DM transmission is day 0.

A receipt MUST distinguish:

clock_start_adapter_event_id
clock_start_transaction_time
deadline_at
resolution_time
payment_action
payment_action_due
deadline_status

11.3 Nonpayment notices

When a manufacturer does not transmit an MFP refund because it asserts that MFP is not required, UDDL represents the response as an emitted artifact:

json

"NONPAYMENT_NOTICE"

The nonpayment notice SHOULD carry:

claim or MTF reference
asserted exception basis
price-file references used
evidence contract references
documentation availability indicator
receipt hash
emitted timestamp

This makes denial, exception, or nonpayment symmetry auditable. UDDL treats payment and nonpayment as receipt-bearing actions.

11.4 Schema

json

{
  "schema": "uddl.nonduplication_resolution_profile",
  "schema_version": "0.1.0",

  "resolution_profile_id": "rp_mfp_340b_partd_lower_of_v0_1",
  "resolution_profile_hash": "sha256:<profile-hash>",
  "version": "0.1.0",

  "program_pair": [
    "MFP",
    "340B"
  ],

  "applies_to": {
    "benefit_context": "PART_D",
    "drug_identifier": "NDC11",
    "initial_price_applicability_years": [
      2026,
      2027
    ]
  },

  "payment_clock": {
    "clock_type": "PROMPT_MFP_PAYMENT_WINDOW",
    "clock_start_event": "MTF_DM_CLAIM_LEVEL_DATA_TRANSMITTED_TO_MANUFACTURER",
    "clock_start_day_label": "DAY_0",
    "duration_days": 14,
    "timezone_basis": "AS_DECLARED_BY_SOURCE_AUTHORITY",
    "routing_to_review_pauses_clock": false
  },

  "eligibility_inputs": {
    "required_assertions": [
      {
        "program": "MFP",
        "polarity": "ELIGIBLE",
        "evidence_contract_id": "ec_mfp_partd_eligible_v0_1"
      }
    ],
    "conditional_assertions": [
      {
        "program": "340B",
        "polarity": "ELIGIBLE",
        "evidence_contract_id": "ec_340b_designation_partd_v0_1"
      },
      {
        "program": "340B",
        "polarity": "INELIGIBLE",
        "evidence_contract_id": "ec_340b_ineligible_partd_v0_1"
      }
    ]
  },

  "price_inputs": {
    "mfp_price_file_ref": {
      "source_artifact_id": "src_mfp_price_file_runtime_ref",
      "content_hash": "sha256:<mfp-price-file-hash>",
      "disclose_price_values_in_receipt": false
    },
    "ceiling_price_file_ref": {
      "source_artifact_id": "src_340b_ceiling_price_file_runtime_ref",
      "content_hash": "sha256:<ceiling-price-file-hash>",
      "disclose_price_values_in_receipt": false
    },
    "comparison_period": "date_of_service",
    "operator": "LOWER_OF_MFP_OR_340B_CEILING"
  },

  "resolution_logic": [
    {
      "case_id": "mfp_only_no_active_340b",
      "when": [
        "active_mfp_eligible",
        "no_active_340b_eligible_assertion"
      ],
      "resolution_outcome": "MFP_PAYABLE_PENDING_LATE_340B_ASSERTION",
      "payment_action": "MFP_REFUND_INSTRUCTION"
    },
    {
      "case_id": "active_340b_and_340b_lower",
      "when": [
        "active_mfp_eligible",
        "active_340b_eligible",
        "340b_ceiling_price_lower_than_mfp"
      ],
      "resolution_outcome": "MFP_NOT_REQUIRED_340B_LOWER",
      "payment_action": "NONPAYMENT_NOTICE"
    },
    {
      "case_id": "active_340b_and_mfp_lower",
      "when": [
        "active_mfp_eligible",
        "active_340b_eligible",
        "mfp_lower_than_340b_ceiling_price"
      ],
      "resolution_outcome": "MFP_REQUIRED_NONDUPLICATED_AMOUNT",
      "payment_action": "MFP_REFUND_INSTRUCTION"
    },
    {
      "case_id": "conflicting_340b_assertions",
      "when": [
        "active_340b_eligible",
        "active_340b_ineligible"
      ],
      "resolution_outcome": "ROUTE_REVIEW_CONFLICTING_ASSERTIONS",
      "payment_action": "AS_DECLARED_BY_PROFILE_AND_DEADLINE"
    },
    {
      "case_id": "match_skew",
      "when": [
        "matched_with_skew"
      ],
      "resolution_outcome": "ROUTE_REVIEW_MATCH_SKEW",
      "payment_action": "AS_DECLARED_BY_PROFILE_AND_DEADLINE"
    }
  ],

  "as_of_replay": {
    "required": true,
    "first_resolution_trigger": "MTF_DM_CLAIM_LEVEL_DATA_RECEIVED",
    "re_resolution_triggers": [
      "new_discount_assertion",
      "superseded_discount_assertion",
      "new_price_file_pin",
      "new_match_result",
      "new_counterparty_response_assertion",
      "adapter_residue_reclassified"
    ],
    "delta_required_on_changed_outcome": true
  },

  "delta_behavior": {
    "prior_mfp_paid_later_340b_lower": "CREATE_CREDIT_DEBIT_DELTA_RECEIPT",
    "prior_mfp_not_paid_later_340b_reversed": "CREATE_REVIEW_RECEIPT",
    "prior_review_later_evidence_complete": "RERUN_AND_EMIT_FINAL_RECEIPT"
  },

  "missing_behavior": {
    "missing_mfp_assertion": "INSUFFICIENT_DATA",
    "missing_340b_assertion": "ALLOW_MFP_PENDING_LATE_ASSERTION",
    "missing_price_file_pin": "ROUTE_REVIEW",
    "missing_matcher_profile": "REJECT_RESOLUTION"
  }
}

11.5 Outcome vocabulary

json

[
  "MFP_PAYABLE_PENDING_LATE_340B_ASSERTION",
  "MFP_NOT_REQUIRED_340B_LOWER",
  "MFP_REQUIRED_NONDUPLICATED_AMOUNT",
  "DUPLICATE_DISCOUNT_RISK",
  "CREDIT_DEBIT_REQUIRED",
  "ROUTE_REVIEW_CONFLICTING_ASSERTIONS",
  "ROUTE_REVIEW_MATCH_SKEW",
  "INSUFFICIENT_DATA",
  "NO_ACTION"
]

11.6 Payment action vocabulary

json

[
  "MFP_REFUND_INSTRUCTION",
  "NONPAYMENT_NOTICE",
  "CREDIT_DEBIT_LEDGER_INSTRUCTION",
  "DISPUTE_PACKET",
  "REVIEW_QUEUE_ITEM",
  "NO_PAYMENT_ACTION",
  "AS_DECLARED_BY_PROFILE_AND_DEADLINE"
]

12. Schema 3: UnitDispositionReceipt

12.1 Purpose

UnitDispositionReceipt records the result of applying a resolver profile to a bounded evidence state.

It must be sufficient to answer:

Which unit was resolved?
Which assertions were considered?
Which evidence contracts were used?
Which matcher version was used?
Which price-file versions were used?
What was knowable as of the resolution time?
What outcome was emitted?
What payment action was emitted?
What deadline governed the action?
What changed from prior receipts?
What adapter events were consumed or emitted?
What residue was preserved?

12.2 Schema

json

{
  "schema": "uddl.unit_disposition_receipt",
  "schema_version": "0.1.0",

  "receipt_id": "udr_0001",
  "receipt_hash": "sha256:<canonical-receipt-hash>",

  "receipt_type": "RESOLUTION",

  "profile_hashes": {
    "resolution_profile_hash": "sha256:<resolution-profile-hash>",
    "matcher_profile_hash": "sha256:<matcher-profile-hash>",
    "evidence_contract_hashes": [
      "sha256:<mfp-evidence-contract-hash>",
      "sha256:<340b-evidence-contract-hash>"
    ]
  },

  "input_envelope": {
    "input_envelope_hash": "sha256:<input-envelope-hash>",
    "dispense_event_id": "de_synth_0001",
    "dispense_event_hash": "sha256:<dispense-event-hash>",
    "assertion_hashes": [
      "sha256:<mfp-assertion-hash>"
    ],
    "source_artifact_hashes": [
      "sha256:<source-artifact-hash>"
    ]
  },

  "as_of": {
    "valid_time": {
      "start": "2026-01-15",
      "end": "2026-01-15"
    },
    "transaction_time": "2026-01-29T23:59:59Z",
    "replay_label": "DAY_14_FROM_MTF_DM_CLAIM_LEVEL_DATA_TRANSMISSION"
  },

  "payment_clock": {
    "clock_type": "PROMPT_MFP_PAYMENT_WINDOW",
    "clock_start_adapter_event_id": "ae_mtf_dm_claim_data_consume_0001",
    "clock_start_transaction_time": "2026-01-15T11:32:00Z",
    "deadline_at": "2026-01-29T23:59:00Z",
    "deadline_basis_anchor_id": "ctx_mtf_claim_data_clock_001",
    "routing_to_review_pauses_clock": false,
    "deadline_status": "WITHIN_WINDOW"
  },

  "match": {
    "matcher_profile_id": "mp_partd_unit_matcher_v0_1",
    "matcher_version": "0.1.0",
    "match_result": "MATCHED_EXACT",
    "match_tier": 1,
    "candidate_count": 1,
    "salt_boundary_status": "WITHIN_SINGLE_OPERATOR_BOUNDARY",
    "skew": []
  },

  "evidence": {
    "evidence_satisfaction_summary": [
      {
        "assertion_id": "da_mfp_eligible_0001",
        "contract_id": "ec_mfp_partd_eligible_v0_1",
        "result": "SATISFIED"
      },
      {
        "assertion_id": null,
        "contract_id": "ec_340b_designation_partd_v0_1",
        "result": "NO_ACTIVE_ASSERTION_AS_OF"
      }
    ],
    "residue_manifest_hashes": [
      "sha256:<residue-hash>"
    ]
  },

  "price_comparison": {
    "operator": "LOWER_OF_MFP_OR_340B_CEILING",
    "mfp_price_file_ref": {
      "source_artifact_id": "src_mfp_price_file_runtime_ref",
      "content_hash": "sha256:<mfp-price-file-hash>"
    },
    "ceiling_price_file_ref": {
      "source_artifact_id": "src_340b_ceiling_price_file_runtime_ref",
      "content_hash": "sha256:<ceiling-price-file-hash>"
    },
    "price_values_disclosed": false,
    "comparison_result": "NO_ACTIVE_340B_ASSERTION_AS_OF"
  },

  "outcome": {
    "resolution_outcome": "MFP_PAYABLE_PENDING_LATE_340B_ASSERTION",
    "payment_action": "MFP_REFUND_INSTRUCTION",
    "review_required": false,
    "rationale_atoms": [
      "MFP eligibility assertion active as of transaction time",
      "No active 340B eligible assertion available as of transaction time",
      "Resolution profile allows MFP refund instruction pending late 340B assertion",
      "Payment clock remains active regardless of future re-resolution"
    ]
  },

  "delta": {
    "supersedes_receipt_id": null,
    "superseded_by_receipt_id": null,
    "changed_outcome": false,
    "delta_code": null
  },

  "adapter_events": {
    "consumed": [
      "ae_mtf_dm_claim_data_consume_0001"
    ],
    "emitted": [
      "ae_mfp_refund_instruction_emit_0001"
    ]
  },

  "integrity": {
    "composition_hash": "sha256:<composition-hash>",
    "receipt_envelope_hash": "sha256:<receipt-envelope-hash>",
    "created_at": "2026-01-29T23:59:59Z",
    "created_by": "uddl_reference_resolver_v0_1",
    "canonicalization": "RFC8785_JCS",
    "hash_algorithm": "SHA-256"
  }
}

12.3 Receipt types

json

[
  "RESOLUTION",
  "RERESOLUTION",
  "CREDIT_DEBIT_DELTA",
  "REVIEW_ROUTE",
  "ADAPTER_CONSUME",
  "ADAPTER_EMIT",
  "NONPAYMENT_NOTICE",
  "CONFORMANCE_TEST"
]

13. AdapterBinding and AdapterEvent

13.1 Purpose

Adapter bindings define how UDDL consumes or emits external projections.

UDDL v0.1 includes:

one worked consume binding: generic third-party 340B claims-designation CSV
stubs for MTF Data Module files
stubs for NCPDP N1 / 420-DK
stubs for PDE-derived records
stubs for TPA exports
stubs for Medicaid invoice rows
stubs for manufacturer effectuation files

13.2 Generic designation CSV binding

The v0.1 generic designation CSV binding is intentionally not named after any specific commercial platform.

A third-party 340B claims-designation CSV may be modeled using publicly available data-element documentation, observed samples with lawful provenance, or synthetic fixtures.

If public documentation is used, it should be represented as a pinned PUBLIC_STANDARD, PUBLISHED_GUIDANCE, or PUBLIC_AUTHORITY source artifact.

If a synthetic sample is used, it MUST be represented as SYNTHETIC_FIXTURE, not OBSERVED_FORMAT.

13.3 AdapterBinding schema

json

{
  "schema": "uddl.adapter_binding",
  "schema_version": "0.1.0",

  "adapter_binding_id": "ab_designation_csv_consume_v0_1",
  "adapter_binding_hash": "sha256:<binding-hash>",

  "direction": "CONSUME",
  "source_class": "SYNTHETIC_FIXTURE",

  "source_artifact_id": "src_synthetic_designation_csv_fixture_001",

  "format_basis": {
    "format_class": "THIRD_PARTY_340B_CLAIMS_DESIGNATION_CSV",
    "public_documentation_source_artifact_id": "src_public_designation_csv_docs_001",
    "synthetic_sample_hash": "sha256:<sample-file-hash>",
    "provenance_note": "Synthetic public fixture for testing a generic designation CSV binding. Not a vendor specification and not an endorsement of or claim about any specific platform."
  },

  "field_map": [
    {
      "source_field": "claim_id",
      "target_path": "claim_refs.claim_ref_hash",
      "transform": "salted_sha256",
      "required": false,
      "on_missing": "ALLOW_WITH_RECEIPT_NOTE"
    },
    {
      "source_field": "ndc",
      "target_path": "drug.ndc11",
      "transform": "normalize_ndc11",
      "required": true,
      "on_missing": "REJECT_ROW"
    },
    {
      "source_field": "date_of_service",
      "target_path": "service.date_of_service",
      "transform": "normalize_date",
      "required": true,
      "on_missing": "REJECT_ROW"
    },
    {
      "source_field": "quantity",
      "target_path": "drug.quantity_dispensed",
      "transform": "decimal_string",
      "required": true,
      "on_missing": "ROUTE_REVIEW"
    },
    {
      "source_field": "covered_entity_id",
      "target_path": "assertion.evidence_refs.covered_entity_ref_hash",
      "transform": "salted_sha256",
      "required": false,
      "on_missing": "ALLOW_WITH_RECEIPT_NOTE"
    },
    {
      "source_field": "designation_status",
      "target_path": "discount_assertion.polarity",
      "transform": "map_340b_designation_polarity",
      "required": true,
      "on_missing": "REJECT_ASSERTION"
    },
    {
      "source_field": "designation_timestamp",
      "target_path": "discount_assertion.time.transaction_time",
      "transform": "normalize_datetime",
      "required": true,
      "on_missing": "ROUTE_REVIEW"
    }
  ],

  "residue_policy": {
    "preserve_unmapped_fields": true,
    "residue_hash_required": true,
    "include_residue_manifest_in_receipt": true
  },

  "matcher_profile_id": "mp_partd_unit_matcher_v0_1"
}

13.4 AdapterEvent schema

json

{
  "schema": "uddl.adapter_event",
  "schema_version": "0.1.0",

  "adapter_event_id": "ae_designation_csv_consume_0001",
  "adapter_binding_id": "ab_designation_csv_consume_v0_1",
  "adapter_binding_hash": "sha256:<binding-hash>",

  "direction": "CONSUME",
  "event_type": "DESIGNATION_CSV_CONSUMED",
  "source_artifact_id": "src_synthetic_designation_csv_fixture_001",
  "source_payload_hash": "sha256:<payload-hash>",

  "input_row_count": 10,
  "mapped_row_count": 8,
  "rejected_row_count": 1,
  "quarantined_row_count": 1,

  "created_objects": [
    {
      "object_type": "DiscountAssertion",
      "object_id": "da_340b_eligible_0001",
      "object_hash": "sha256:<object-hash>"
    }
  ],

  "residue": {
    "residue_manifest_hash": "sha256:<residue-manifest-hash>",
    "unmapped_field_count": 3,
    "quarantined_field_count": 1
  },

  "created_at": "2026-02-03T09:40:00Z"
}

13.5 MTF DM claim-level data consume event

The MTF DM claim-level data transmission is the clock-starting event for the v0.1 MFP payment-window fixture.

json

{
  "schema": "uddl.adapter_event",
  "schema_version": "0.1.0",

  "adapter_event_id": "ae_mtf_dm_claim_data_consume_0001",
  "adapter_binding_id": "ab_mtf_dm_claim_data_consume_stub_v0_1",
  "adapter_binding_hash": "sha256:<binding-hash>",

  "direction": "CONSUME",
  "event_type": "MTF_DM_CLAIM_LEVEL_DATA_RECEIVED",

  "source_artifact_id": "src_synthetic_mtf_dm_claim_level_data_001",
  "source_payload_hash": "sha256:<payload-hash>",

  "clock_effect": {
    "starts_clock": "PROMPT_MFP_PAYMENT_WINDOW",
    "clock_start_day_label": "DAY_0",
    "clock_start_transaction_time": "2026-01-15T11:32:00Z"
  },

  "created_objects": [
    {
      "object_type": "DiscountAssertion",
      "object_id": "da_mfp_eligible_0001",
      "object_hash": "sha256:<object-hash>"
    }
  ],

  "created_at": "2026-01-15T11:32:00Z"
}

13.6 Effectuation as AdapterEvents

UDDL v0.1 does not create a separate “Effectuation” schema.

Effectuation is represented through AdapterEvents:

MFP_REFUND_INSTRUCTION
MFP_REFUND_REMITTANCE
NONPAYMENT_NOTICE
CREDIT_DEBIT_LEDGER_INSTRUCTION
REBATE_DENIAL_PACKET
DISPUTE_PACKET
REVIEW_QUEUE_ITEM

This keeps the core profile small and avoids duplicating receipt machinery.

14. Worked flow: retroactive 340B flip

14.1 Scenario

A selected Part D drug is dispensed on January 15, 2026.

The MTF DM later transmits claim-level data elements to the manufacturer. That MTF DM transmission is represented as ae_mtf_dm_claim_data_consume_0001 and starts the 14-day prompt MFP payment window.

As of the payment-window resolution, the resolver has an active MFP eligibility assertion and no active 340B eligible assertion.

The resolver emits:

UnitDispositionReceipt outcome: MFP_PAYABLE_PENDING_LATE_340B_ASSERTION
payment action: MFP_REFUND_INSTRUCTION
AdapterEvent: MFP refund instruction emitted

Later, a generic third-party 340B claims-designation CSV row is consumed. The row indicates the unit was designated 340B eligible by a covered entity, TPA, or other designation process. The row includes enough information to match the original dispense event under the declared matcher profile.

The resolver reruns as of the later transaction time.

If the 340B ceiling price for the date of service is lower than MFP, the resolver emits:

UnitDispositionReceipt outcome: CREDIT_DEBIT_REQUIRED
delta from prior receipt
AdapterEvent: credit/debit ledger instruction emitted
optional dispute packet if evidence contract is not fully satisfied

The credit/debit movement is attributed to the specific CMS guidance anchor represented in ctx_credit_debit_ledger_001, not asserted as a generic CMS endorsement of any private recovery process.

14.2 Required receipts

The fixture MUST produce at least four receipts:

MTF DM claim-level data consume receipt.
Initial MFP resolution receipt within the payment window.
Designation CSV consume receipt.
Re-resolution / credit-debit delta receipt.

14.3 What the fixture proves

The fixture proves that UDDL can answer:

When did the payment clock start?
What was knowable during the prompt MFP payment window?
Why was MFP paid?
What late assertion arrived?
Who asserted it?
What evidence supported it?
How was it matched?
Which price-file versions were used?
Why did the outcome change?
What delta artifact was emitted?
Which receipt proves the chain?

15. Fixture suite v0.1

UDDL v0.1 ships with six synthetic fixtures.

All fixture values are illustrative.

Each fixture MUST include:

fixture metadata
public-safety statement
PHI status
source artifact list
input objects
expected output receipts
expected conformance result
canonical object hashes
fixture package hash

Fixture 1: Clean MFP-only Part D dispense

Name: fx_001_clean_mfp_only_partd

Purpose: Show baseline MFP payment when no active 340B assertion exists.

Expected resolution outcome: MFP_PAYABLE_PENDING_LATE_340B_ASSERTION

Expected payment action: MFP_REFUND_INSTRUCTION

Required objects:

DispenseEvent
MTF DM claim-level data AdapterEvent
MFP eligible DiscountAssertion
NonduplicationResolutionProfile
UnitDispositionReceipt
MFP refund instruction AdapterEvent

Fixture 2: Known 340B before MFP resolution, 340B lower

Name: fx_002_known_340b_before_resolution_340b_lower

Purpose: Show nonduplication when 340B eligibility is known before MFP resolution and 340B ceiling price is lower than MFP.

Expected resolution outcome: MFP_NOT_REQUIRED_340B_LOWER

Expected payment action: NONPAYMENT_NOTICE

Required objects:

DispenseEvent
MTF DM claim-level data AdapterEvent
MFP eligible DiscountAssertion
340B eligible DiscountAssertion
price file pins
UnitDispositionReceipt
nonpayment notice AdapterEvent

Fixture 3: Known 340B before MFP resolution, MFP lower

Name: fx_003_known_340b_before_resolution_mfp_lower

Purpose: Show that 340B eligibility does not automatically eliminate MFP obligations when MFP is lower.

Expected resolution outcome: MFP_REQUIRED_NONDUPLICATED_AMOUNT

Expected payment action: MFP_REFUND_INSTRUCTION

Required objects:

DispenseEvent
MTF DM claim-level data AdapterEvent
MFP eligible DiscountAssertion
340B eligible DiscountAssertion
price file pins
UnitDispositionReceipt
MFP refund instruction AdapterEvent

Fixture 4: Retroactive 340B designation flips prior MFP payment

Name: fx_004_retroactive_340b_flip_credit_debit

Purpose: Flagship fixture. Show bitemporal re-resolution when late 340B designation arrives after prompt MFP payment.

Expected initial resolution outcome: MFP_PAYABLE_PENDING_LATE_340B_ASSERTION

Expected initial payment action: MFP_REFUND_INSTRUCTION

Expected later resolution outcome: CREDIT_DEBIT_REQUIRED

Expected later payment action: CREDIT_DEBIT_LEDGER_INSTRUCTION

Required objects:

DispenseEvent
MTF DM claim-level data AdapterEvent
MFP eligible DiscountAssertion
initial UnitDispositionReceipt
designation CSV AdapterEvent
340B eligible DiscountAssertion
re-resolution UnitDispositionReceipt
credit/debit AdapterEvent

Fixture 5: Dual eligible / MDRP exposure detection

Name: fx_005_dual_eligible_mdrp_detection

Purpose: Show that benefit context and MDRP exposure are assertable, not assumed.

v0.1 behavior: Detection only. UDDL v0.1 does not include a full MDRP resolver profile.

Expected resolution outcome: DUPLICATE_DISCOUNT_RISK

Expected payment action: REVIEW_QUEUE_ITEM

Required objects:

DispenseEvent
MFP eligible DiscountAssertion
MDRP exposed DiscountAssertion
340B eligible or ineligible DiscountAssertion
state carve-out evidence reference
UnitDispositionReceipt

Conformance rule: This fixture has exactly one deterministic expected outcome: DUPLICATE_DISCOUNT_RISK.

Fixture 6: Match skew across designation CSV and PDE-derived record

Name: fx_006_match_skew_route_review

Purpose: Show governed matcher behavior when a late designation likely maps to the original dispense event but does not match perfectly.

Examples of illustrative skew:

date of service differs under a declared tolerance profile
quantity differs due to unit-of-measure transformation
dispensing entity hash unavailable across salt boundary
claim reference absent

Expected resolution outcome: ROUTE_REVIEW_MATCH_SKEW

Expected payment action: REVIEW_QUEUE_ITEM

Required objects:

DispenseEvent
designation CSV AdapterEvent
340B eligible DiscountAssertion
DiscountMatcherProfile
UnitDispositionReceipt with MATCHED_WITH_SKEW

16. Conformance model

16.1 UDDL-conformant implementation

An implementation may claim UDDL v0.1 conformance only if it can:

parse the UDDL v0.1 schemas
canonicalize JSON using the declared canonicalization rule
compute deterministic hashes
consume all required fixture inputs
emit canonical DispenseEvent objects
emit canonical DiscountAssertion objects
evaluate evidence contracts
use a declared matcher profile
preserve residue hashes
run the nonduplication resolver
emit UnitDispositionReceipt objects
replay as-of outcomes
produce expected fixture outcomes
preserve profile hashes in receipts
emit a nonpayment notice where required by the fixture
distinguish resolution outcome from payment action

16.2 Fixture conformance levels

json

[
  {
    "level": "L0",
    "name": "Schema Parse",
    "requirement": "Implementation can parse UDDL schemas and validate object shape."
  },
  {
    "level": "L1",
    "name": "Canonical Hash",
    "requirement": "Implementation can canonicalize UDDL JSON using the declared canonicalization rule and produce expected object hashes."
  },
  {
    "level": "L2",
    "name": "Fixture Replay",
    "requirement": "Implementation can run all six fixtures and produce expected deterministic outcomes."
  },
  {
    "level": "L3",
    "name": "Receipt Integrity",
    "requirement": "Implementation preserves input envelope hashes, profile hashes, matcher version, payment clock, payment action, and residue manifests."
  },
  {
    "level": "L4",
    "name": "Adapter Round Trip",
    "requirement": "Implementation can consume designation CSV and emit all mapped, quarantined, rejected, and residue fields with receipt."
  },
  {
    "level": "L5",
    "name": "As-of Replay",
    "requirement": "Implementation can reproduce initial and re-resolution outcomes at specified transaction times."
  }
]

16.3 Conformance phrase

Recommended phrase:

Validated against the UDDL v0.1 fixture suite.

Reserved phrase:

UDDL-conformant.

The phrase “UDDL-conformant” should be controlled through future governance and trademark policy if the profile develops into a public conformance referent.

17. Docket atomization method

17.1 Annex status

The atomization schema and method in this section are normative parts of UDDL v0.1.

A populated requirements annex, derived from the public HRSA dockets, will be published separately as a companion artifact once comment mining is complete.

17.2 Purpose

The docket atomization method turns stakeholder positions into atomic data requirements.

Each atom should include:

stakeholder class
source comment ID
page or section
claim type
data element requested
timing concern
dispute concern
cash-flow concern
privacy/security concern
duplicate-discount concern
proposed operational mechanism
associated UDDL object or fixture

17.3 Atom schema

json

{
  "schema": "uddl.docket_atom",
  "schema_version": "0.1.0",

  "atom_id": "atom_hrsa_rfi_0001",
  "source_artifact_id": "src_hrsa_rfi_comment_0001",
  "stakeholder_class": "COVERED_ENTITY",

  "claim_type": "PAYMENT_TIMING",
  "summary": "Commenter asserts rebate timing may create cash-flow strain unless payment or denial occurs within a defined window.",

  "data_elements_requested": [
    "date_of_service",
    "claim_ref",
    "rebate_request_timestamp",
    "denial_reason",
    "denial_documentation"
  ],

  "uddl_mapping": {
    "objects": [
      "DiscountAssertion",
      "DesignationEvidenceContract",
      "UnitDispositionReceipt",
      "AdapterEvent"
    ],
    "fixtures": [
      "fx_004_retroactive_340b_flip_credit_debit"
    ]
  },

  "content_hash": "sha256:<atom-hash>"
}

17.4 Companion annex outputs

The completed docket annex should produce:

A requirements table.
A fixture coverage matrix.
A stakeholder-pain map.
A conformance backlog for v0.2.

18. Repository structure

Recommended public repository structure:

text

/uddl
  /spec
    uddl-v0.1.md
    governance.md
    conflicts-policy.md
    source-artifact-register.md

  /schemas
    dispense_event.schema.json
    discount_assertion.schema.json
    unit_disposition_receipt.schema.json
    designation_evidence_contract.schema.json
    nonduplication_resolution_profile.schema.json
    discount_matcher_profile.schema.json
    adapter_binding.schema.json
    adapter_event.schema.json
    docket_atom.schema.json

  /bindings
    /designation_csv
      adapter_binding_designation_csv_v0_1.json
      sample_designation_csv.synthetic.csv
      residue_manifest.example.json
    /mtf_dm_stub
      README.md
    /ncpdp_n1_stub
      README.md
    /pde_derived_stub
      README.md
    /medicaid_invoice_stub
      README.md
    /manufacturer_effectuation_stub
      README.md

  /fixtures
    /fx_001_clean_mfp_only_partd
    /fx_002_known_340b_before_resolution_340b_lower
    /fx_003_known_340b_before_resolution_mfp_lower
    /fx_004_retroactive_340b_flip_credit_debit
    /fx_005_dual_eligible_mdrp_detection
    /fx_006_match_skew_route_review

  /resolver
    reference_resolver_pseudocode.md
    expected_outcomes.json

  /docket
    docket_atom_schema.json
    requirements_annex_template.csv
    fixture_coverage_matrix_template.csv

  /examples
    retroactive_flip_walkthrough.md
    lower_of_without_price_disclosure.md
    nonpayment_notice_walkthrough.md

19. Governance note

19.1 Maintainer

UDDL v0.1 is initially maintained by the author as a public draft.

The maintainer is responsible for:

preserving version history
publishing change logs
maintaining fixture integrity
reviewing public issues
identifying named reviewers
disclosing conflicts
separating public standard work from private advisory work

19.2 Change classes

Patch changes

Patch changes do not alter schema semantics.

Examples:

typo fixes
clarification notes
non-normative examples
citation updates
formatting corrections

Minor changes

Minor changes add optional fields, fixtures, or bindings without breaking existing v0.1 payloads.

Examples:

new fixture
new optional evidence class
new observed-format binding
expanded docket atom tags

Major changes

Major changes alter required fields, resolver semantics, conformance requirements, or outcome vocabulary.

Examples:

Part B support
NDC-HCPCS crosswalk schema
new required receipt field
changed lower-of resolver logic
changed evidence-contract satisfaction rules

19.3 Reviewer model

UDDL may credit named reviewers.

Reviewer credit means:

the reviewer provided feedback
the reviewer helped validate fixture realism or requirements language
the reviewer does not necessarily endorse every provision
the reviewer does not certify legal, operational, or technical correctness

19.4 Decision log

Every accepted normative change should include:

issue ID
proposer
stakeholder class, if known
problem statement
alternatives considered
decision
version applied
affected schemas
affected fixtures

19.5 Timestamping

Each published version should be hashed.

Recommended artifacts to hash:

specification markdown
schemas
fixture suite
expected outcomes
source-artifact register
governance note
conflicts policy

Recommended optional timestamp mechanism:

OpenTimestamps or comparable public timestamp proof

20. Conflicts policy

20.1 Neutrality principle

UDDL is intended to serve as a neutral data-contract and conformance profile.

It should not encode a private stakeholder’s preferred economic outcome as if it were neutral technical truth.

20.2 Funding disclosure

Any funding, paid advisory relationship, sponsorship, commissioned analysis, or implementation support connected to UDDL should be disclosed in a public conflicts register.

The conflicts register should include:

payer or client class
nature of engagement
whether deliverables are public or private
whether the engagement influenced any UDDL issue, fixture, schema, or resolver profile
date range
mitigation steps

20.3 No hidden private rules

A private engagement may produce private implementation guidance.

A private engagement should not silently change the public standard.

If a private engagement surfaces a generally useful pattern, it may be contributed to UDDL only if:

it is generalized
it is stripped of confidential data
it is not dependent on proprietary architecture
it can be validated with synthetic fixtures
the source of the contribution is disclosed if material

20.4 Covered entity / manufacturer balance

UDDL should preserve a visible path for both manufacturer-side and covered-entity-side critique.

At minimum, major releases should seek review from:

at least one manufacturer operations or market access data reviewer
at least one covered entity or 340B operations reviewer
at least one TPA or pharmacy operations reviewer
at least one policy or legal reviewer
at least one technical implementer

20.5 PHI and security

UDDL public artifacts must not include live PHI.

Any implementation using live claims data requires appropriate security, privacy, contractual, and legal review. UDDL public conformance should be possible entirely with synthetic data.

21. Summary

UDDL is a public, fixture-backed profile for proving what was known, asserted, matched, lost, paid, not paid, credited, debited, and resolved when a dispensed drug unit may be subject to MFP, 340B, and Medicaid duplicate-discount constraints.

22. What UDDL lets every stakeholder ask

The MFP / 340B problem is not just a pricing problem. It is a unit-disposition lineage problem.

UDDL v0.1 defines a public, synthetic fixture suite and minimal data grammar for representing a dispense event, discount assertions, evidence contracts, resolver profiles, matcher versions, payment-clock events, payment actions, nonpayment notices, and receipts.

The goal is simple: make every stakeholder able to ask the same questions about a contested unit.

What was dispensed? Who asserted 340B, MFP, or MDRP exposure? When did they assert it? What evidence supported it? How was it matched? Was matching inside a shared salt boundary or structural only? What price-file versions were used? When did the MTF DM claim-level-data clock start? What crossed the boundary? What got lost? What did the resolver decide as of the payment window? Was payment made, not made, credited, debited, or routed for review? What changed later? What receipt proves it?

UDDL does not pick a side.

It makes the dispute auditable.