# Not yet settled

  Some of the rail's rules are still being confirmed. It does more damage to publish them as settled
  than to publish them as open, so this page collects them and says plainly what is not known yet.

## Why this page exists rather than a table of numbers

Time limits decide the shape of a provider's software. If the claim time bar is 120 days, you can
reconcile once a month. If it is 14 days, you need a daily worklist, an alerting rule and somebody
whose job it is to watch it. Those are two different products.

The training material and the conformance specification currently give different answers, and
system configuration defaults give a third in places. Building to the wrong one loses money quietly,
so the figures below are set out as a conflict and not as guidance.

  Nothing here is safe to hard-code. Where you need a limit today, ask for the production value in
  writing, and keep it in configuration instead of a condition, so that changing it later does not
  need a release.

## The disagreements

<CostTable
  rows={[
    {
      where: "Claim time bar",
      symptom: "~120 days versus 14 days",
      cause:
        "14 days is stated from claim creation for outpatient, and from discharge for inpatient. If 14 is right, a monthly submission rhythm loses claims, which makes this the most consequential of the conflicts.",
    },
    {
      where: "Outpatient authorisation validity",
      symptom: "~30 days versus 180 days",
      cause:
        "Decides how long an authorisation can sit before the visit has to be opened against it.",
    },
    {
      where: "Inpatient authorisation validity",
      symptom: "~1 year versus 180 days",
      cause:
        "The same question over a longer horizon, and the two sources are half a year apart.",
    },
    {
      where: "Elective preauthorisation",
      symptom: "45 days to start the visit versus 7 days from approval",
      cause:
        "The number differs and so does the starting point, which is either issue or approval. You need both stated before you can build a countdown.",
    },
    {
      where: "Emergency claim",
      symptom: "Not stated versus 24 hours from creation",
      cause:
        "If the window is 24 hours, emergency submission has to be alarmed on the same day instead of queued for later.",
    },
    {
      where: "Missing-documents resubmission",
      symptom: "Not stated versus 14 days",
      cause:
        "After that it is rejected and cannot be resubmitted at all. An operator should be able to see a terminal deadline in the interface, rather than learn about it from the rejection.",
    },
    {
      where: "One-time code validity",
      symptom: "Not stated versus 5 minutes",
      cause:
        "Five minutes changes the consent screen, which then needs a visible countdown and a resend instead of a passive input box.",
    },
  ]}
/>

## What is not in dispute

Two windows are consistent across sources. Their shape is safe to design around even if the exact
figures move.

<Wire
  rows={[
    { call: "Visit open, outpatient", does: "Roughly a month before it has to be closed.", keep: "Close visits deliberately; do not rely on the ceiling" },
    { call: "Visit open, inpatient", does: "Roughly a year, long enough that the ceiling will not be your constraint.", keep: "Discharge closes it, not the clock" },
  ]}
/>

## Build so that a change is not a release

A better guess is not what an unresolved limit needs. Hold every clock in one place, where it can be
corrected without a code change.

<BuildSequence
  steps={[
    {
      do: "Put every limit in configuration",
      detail:
        "One named module, with the source of each value recorded beside it. Inline a limit in a condition and nobody will be able to find it when it changes.",
    },
    {
      do: "Show the deadline, do not enforce it silently",
      detail:
        "Put the date a claim must be submitted by on the claim itself. An operator who can see the deadline will meet it. If it is hidden, the first sign of it is a rejection.",
    },
    {
      do: "Alert on the approach, not the breach",
      detail:
        "A worklist that flags at 70% of the window elapsed is useful. One that reports what has already expired only tells you what you lost.",
    },
    {
      do: "Log the value you used",
      detail:
        "When a limit turns out to have been wrong, the first question is which number your system applied and since when. Make that answerable.",
    },
  ]}
/>

## Enforcement that may not be on yet

Two checks are published as rules but may not be enforced in production yet. The risk is the same in
both cases, and it is one-sided: an integration that ignores the rule passes today and starts
failing on the day the check is switched on.

<Wire
  rows={[
    { call: "Attachment checking", does: "Required-document rules may not be enforced at submission today. Build to the published per-procedure requirements whatever the environment happens to accept.", keep: "the published list" },
    { call: "Interface-only rules", does: "Some prescription and primary-care diagnosis rules may be enforced in the interface today and not in the API, so a direct integration is not stopped by them.", keep: "the rule, not the behaviour" },
  ]}
/>

## Workflows still being completed

<Wire
  rows={[
    { call: "The whitelist reason list", does: "The reasons offered differ between systems, so a reason you send may be ignored. Record what the operator chose, and do not build a picker on values that are not agreed.", keep: "your own record" },
    { call: "Removing a whitelist", does: "The current mechanism is being corrected, so do not build a removal path against it yet.", keep: "—" },
    { call: "Incoming referrals", does: "The receiving-side workflow is still being completed. An inbound queue is the right thing to build, as long as you do not treat it as final.", keep: "—" },
    { call: "Billing above the tariff", does: "It is not settled whether public-officer members bypass the tariff cap for all procedures or only some, so do not encode a blanket rule.", keep: "—" },
    { call: "Excess of loss", does: "It is still being decided whether an integrator bills against it directly or the rail applies it.", keep: "—" },
    { call: "Multiple doctors", does: "The production setting that controls whether several doctors may be attached is an open question, as is the behaviour when it is off.", keep: "—" },
    { call: "Which proofs can be reused", does: "Discharge is settled as standalone. Whether an eligibility or cover-view proof may be spent on opening a visit is not, so re-authenticate where you are unsure.", keep: "—" },
    { call: "Freshness windows", does: "It is being decided whether the window is set per factor, per purpose, or as one default with overrides. Read the expiry from the record instead of assuming a duration.", keep: "expires_at" },
  ]}
/>

  Put it in configuration, not in a condition. Log the value you applied and when. Where a rule is
  unconfirmed, build to the stricter reading: an integration that collects a document it did not
  need loses nothing, while one that skipped a required document loses a claim.

## Getting this resolved

These will be settled and published as single values. Until they are, treat any figure you are
given verbally as unconfirmed, record who gave it to you and when, and keep it in configuration so
that the correction does not need a code change. If a limit matters to your design, ask for it in
writing before you build the behaviour that depends on it.

**Next:** [Error dictionary](/rail/reference/Errors) · [Value sets and code systems](/rail/reference/Value-Sets)