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.
Everything below elaborates this sentence.
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.
The disagreements
| Where it surfaces | What the desk sees | What actually went wrong |
|---|---|---|
| Claim time bar | ~120 days versus 14 days | 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. |
| Outpatient authorisation validity | ~30 days versus 180 days | Decides how long an authorisation can sit before the visit has to be opened against it. |
| Inpatient authorisation validity | ~1 year versus 180 days | The same question over a longer horizon, and the two sources are half a year apart. |
| Elective preauthorisation | 45 days to start the visit versus 7 days from approval | 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. |
| Emergency claim | Not stated versus 24 hours from creation | If the window is 24 hours, emergency submission has to be alarmed on the same day instead of queued for later. |
| Missing-documents resubmission | Not stated versus 14 days | 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. |
| One-time code validity | Not stated versus 5 minutes | 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.
| Call | What it does | What you keep |
|---|---|---|
Visit open, outpatient | Roughly a month before it has to be closed. | Close visits deliberately; do not rely on the ceiling |
Visit open, inpatient | Roughly a year, long enough that the ceiling will not be your constraint. | 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.
- 01Put every limit in configurationOne 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.
- 02Show the deadline, do not enforce it silentlyPut 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.
- 03Alert on the approach, not the breachA worklist that flags at 70% of the window elapsed is useful. One that reports what has already expired only tells you what you lost.
- 04Log the value you usedWhen 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.
| Call | What it does | What you keep |
|---|---|---|
Attachment checking | Required-document rules may not be enforced at submission today. Build to the published per-procedure requirements whatever the environment happens to accept. | the published list |
Interface-only rules | 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. | the rule, not the behaviour |
Workflows still being completed
| Call | What it does | What you keep |
|---|---|---|
The whitelist reason list | 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. | your own record |
Removing a whitelist | The current mechanism is being corrected, so do not build a removal path against it yet. | — |
Incoming referrals | 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. | — |
Billing above the tariff | 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. | — |
Excess of loss | It is still being decided whether an integrator bills against it directly or the rail applies it. | — |
Multiple doctors | The production setting that controls whether several doctors may be attached is an open question, as is the behaviour when it is off. | — |
Which proofs can be reused | 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. | — |
Freshness windows | 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. | expires_at |
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 · Value sets and code systems