Olly Docs

Appearance

Updated Aug 22, 2026

Prior authorization ​

Schema deep-dive · living document · #13 in the reading sequence

Tablesclaims.prior_auths[1], claims.claim_documents[2]
Owner serviceclaims (sole writer)
LocatorPAU-YYYY-NNNNNN (prior auths). claim_documents has no locator - uuid PK, natural key (claim_id, filename) in spirit only
Last updated2026-08-21
Companionprevious: Claim (#7) · Claims Lifecycle (narrative) · the real document store: Consent, documents & notifications (#12)

1. Scope and usage ​

A prior authorization is a provider's request to have a procedure pre-approved before it is performed - the claims.prior_auths row records who asked (provider_id), for whom (member_party_id), under which policy, for what (procedure_code), and where the request sits in its own review lifecycle. claims.claim_documents is the second, unrelated table on this page: an in-schema table for file attachments hung off a claim.

Where this sits today. Prior-auth is a complete, self-contained workflow, and deliberately ahead of need. Its lifecycle runs and is exercised in production data - 116 rows, and the outbox shows every state transition firing[5]. What is not yet wired is the consumption side: no gate on the claim path reads prior_auths today, because at the current auto-approve stage the platform does not yet carry procedures (real medical conditions) that require prior authorization. A claim approves whether or not a matching authorization exists - the correct behaviour until PA-requiring conditions are introduced, not a case the schema has failed to handle. The architecture already covers the bases: submitting, reviewing and deciding a prior-auth changes one row and emits one event, and document-service turns an approval into a letter (§7). Wiring the claim-path gate is scoped in #1705; it switches on when we carry PA-requiring procedures. The narrative walks the same shape.

claim_documents is the same story, one step earlier in its life: 0 live rows as of 2026-08-21, because claims auto-approve today and there is nothing yet to attach. The table, its Go model[4], its repository[25] and its two HTTP endpoints[22][23] are in place and compile - the attachment surface is ready for when claims carry supporting documents (past the auto-approve stage, or where a reviewer needs evidence). Until then, the attachments the platform does generate flow through document-service, which owns the documents table (page #12) and renders PDFs from Kafka events.

Both tables are owned solely by the claims service and captured to CDC via the dbz_claims publication.

2. Boundaries and relationships ​

A prior-auth is not…That concern lives inJoin
a claimclaims.claims - the payment request; adjudication consults prior-auth once the gate is on (§9)none today - no FK; the join key the lookup would use is coverage_term_key (§9)
the coverage decisioneligibility - a prior-auth burns no accumulator and asks eligibility nothingnone
the provider recordprovider - provider_id is a bare uuid soft ref, indexed[1], no FKuuid, cross-service
the decision letterdocument-service - prior-auth.decided triggers a PRE_AUTH_LETTER[17] stored there, not hereoutbox event, priorAuthLocator
A claim_document is not…That concern lives inJoin
the document storedocument-service (documents table, page #12) - where attachments livenone - separate DB
the claimclaims.claims - a document hangs off a claim by real in-service FK[2]claim_id FK (unexercised - 0 rows)

provider_id / policy_id / member_party_id on prior_auths are all NOT NULL uuids with no FK - the standard cross-service posture, but here even the in-DB references (policy, member) carry no constraint. member_party_id is the only ownership handle, and it ties the row to a party, never to an employer - which is why the endpoint is closed to tenant callers entirely (§7).

3. Structure ​

DDL[1][2] · Go models[3][4]

prior_auths ​

FieldTypeReqNotes
id / locatoruuid / text✓PK / UNIQUE PAU-YYYY-NNNNNN
provider_iduuid✓Requesting provider; indexed; soft ref, no FK
policy_iduuid✓Policy the request is under; indexed; soft ref, no FK
member_party_iduuid✓The patient party; the only ownership handle
statustext✓DB default 'PENDING', but code always writes SUBMITTED (§4); the live vocabulary is SUBMITTED / PENDING_REVIEW / APPROVED / DENIED
procedure_codetextThe requested procedure (e.g. CPT 27447); nullable, empty on seeder rows
documentjsonbFree-shape supporting context - NULL on all 116 live rows (§6)
submitted_attimestamptz✓Set to now() at Submit; DB default now()
reviewed_attimestamptzStamped only by Approve / Deny
created_attimestamptz✓DB default now()

claim_documents ​

FieldTypeReqNotes
iduuid✓PK
claim_iduuid✓Real FK to claims.claims[2]; indexed
filenametext✓Original file name
content_typetext✓MIME type
urltext✓Where the bytes live - a pointer, not the blob
uploaded_attimestamptz✓Set by AttachDocument; DB default now()
created_attimestamptz✓DB default now()

Field-by-field: what and why ​

locator - minted as PAU-<year>-<seq %06d> from claims.prior_auths_locator_seq by PriorAuthService.Submit[5][11]. Two things to note. First, the prefix is PAU-, not the PA- the shorthand suggests - every one of the 116 live rows and the fmt.Sprintf that mints them say PAU-. Second, the sequence is claims.prior_auths_locator_seq, created inside the claims schema alongside claims.claims_locator_seq[12] and hand-formatted, rather than through the shared locator_seq_<prefix> machinery every other service uses - the same in-schema-sequence wart the Claim page documents. Live last_value: 353, against 116 rows (237 e2e rows minted and since deleted, so the locator space has gaps).

status - the field with two histories. The migration sets a column default of 'PENDING'[1] and the Go model still comments the vocabulary as // PENDING | APPROVED | DENIED[3]. But a later commit replaced that with a full SUBMITTED → PENDING_REVIEW → APPROVED | DENIED state machine, and Submit now writes SUBMITTED explicitly[5]. The DB default is therefore superseded and unreachable - no code path leaves it to fire, and no live row carries PENDING. Approve and Deny still accept PENDING "for legacy records"[7], a bridge to a state that no longer occurs. Nothing in the DB constrains status to any vocabulary; the state machine is entirely application-enforced (§4).

reviewed_at - NULL until a terminal decision. Approve/Deny pass &now into UpdateStatus[7][8]; Review (the SUBMITTED → PENDING_REVIEW hop) passes nil and leaves it unset[6]. Live, exactly the 11 APPROVED rows have a non-null reviewed_at and nothing else does.

document (prior_auths) - a free-shape jsonb for supporting context, NULL on all 116 rows: the submit handler accepts a document field[14] and passes whatever arrives straight through. Because it is jsonb, clinical notes, referral metadata, imaging references or a reviewer's rationale can be carried on an authorization without a migration and without agreeing a shape first - the column absorbs the supporting context a reviewed authorization attaches, whatever form it takes when the need lands (§9).

claim_documents.url - the table stores a pointer (filename, MIME, URL), not the bytes. This is the shape you would design if claims owned its own attachments, and the whole path is in place: AttachDocument[20] behind POST /claims/{locator}/documents[22]. The attachments the platform generates today are letters and statements, which document-service owns and renders; a claim's own supporting evidence writes here the first time a claim carries any, with no schema change (§9).

4. Invariants ​

InvariantEnforced by
prior_auths.locator uniqueDB UNIQUE prior_auths_locator_key[1]
Locator shape PAU-YYYY-NNNNNNApplication: fmt.Sprintf in Submit[5]; no DB CHECK on the format
Status transitions are legalApplication: each service method asserts the current status before moving (Review requires SUBMITTED[6]; Approve/Deny require PENDING_REVIEW or legacy PENDING[7]) and the repo re-checks from under a row read before the update[10]
status is one of a known setNothing - no DB CHECK; the vocabulary is code convention only, and the DB default 'PENDING' is never written
A decision stamps reviewed_atApplication: Approve/Deny pass &now[7][8]; not enforced in DB
Row change + outbox event in one txApplication: Submit/Review/Approve/Deny wrap the repo write and the outbox enqueue in a single db.Transaction[5]
provider_id / policy_id / member_party_id presentDB NOT NULL[1] - but satisfied by all-zero uuids on seeder rows (§6), so "present" does not mean "real"
A prior-auth gates a claimNothing yet - the claim-path lookup is deferred to #1705 and activates when we carry PA-requiring procedures (§9); the narrative walks the same sequencing
claim_documents belongs to a real claimDB FK claim_documents_claim_id_fkey[2] (in-service; unexercised)
claim_documents filename / type / url presentDB NOT NULL[2]
claim_documents is append-onlyConvention - only Create and ListByClaim exist in the repo[25]; no UPDATE/DELETE path, no DB grant forbids one
Row changes captured to CDCDebezium publication dbz_claims (live \d, both tables)

5. Lifecycle ​

prior_auths has a status machine; claim_documents does not (it is insert-once).

Every arrow is a PriorAuthService[26] method that asserts its entry status and writes an outbox event in the transition's transaction: Submit[5] (emits prior_auth.submitted), Review[6] (emits prior_auth.escalated), Approve[7] and Deny[8] (both emit prior-auth.decided). The PENDING legacy branch is drawn dashed by history: no live row is in it, and no path produces it any more.

Two things this diagram does not do yet. It does not touch a claim - there is no arrow from any prior-auth state into claim adjudication; that arrow is the deferred consumer scoped in #1705 and lands in autoApprove (§9). And its terminal event is heard by exactly one service: document-service generates a PRE_AUTH_LETTER on prior-auth.decided[17]; the prior_auth.submitted and prior_auth.escalated events are produced but consumed by nothing (§9).

For claim_documents the "lifecycle" is a straight line: AttachDocument inserts one row[20] (behind POST /claims/{locator}/documents[24], returns 201[22]) and ListDocuments reads them back by claim[21][23]. Insert and read, no update, no delete, no state - which is the whole surface an attachment pointer needs, and the reason turning it on is a call, not a build (§9).

6. Populated example: PAU-2026-000353, walked end to end ​

A live APPROVED prior-auth - the row that exercised the full Submit → Review → Approve path (an e2e run, all three transitions inside 8ms). No free-text lives on it; document is NULL. Locators and codes are real; the uuids are the test fixture's placeholder values.

json
{
  "id": "cee79734-78c7-4da1-9422-04c655de62e2",
  "locator": "PAU-2026-000353",
  "provider_id": "22222222-2222-2222-2222-222222222222",
  "policy_id": "00000000-0000-0000-0000-000000000000",
  "member_party_id": "11111111-1111-1111-1111-111111111111",
  "status": "APPROVED",
  "procedure_code": "27447",
  "document": null,
  "submitted_at": "2026-08-12T17:30:57.588277Z",
  "reviewed_at":  "2026-08-12T17:30:57.595826Z",
  "created_at":   "2026-08-12T17:30:57.588478Z"
}
KeyRead byWhat happens
locator: PAU-2026-000353admin / MCP priorauth_listthe PAU- prefix from Submit's fmt.Sprintf[5]; sequence value 353
status: APPROVEDdocument-service (letter); no claim path yetthe terminal state after Approve; the adjudication lookup that would consult it is the deferred consumer in #1705 (§9)
procedure_code: 27447display onlya real CPT code (total knee arthroplasty); stored, never validated against a code set
policy_id: 0000…nothingthe e2e never wired a real policy - a NOT NULL uuid satisfied by the zero value (wart, §9)
reviewed_at set, 7ms after submitdisplaystamped by Approve[7]; the whole three-step lifecycle ran in one test
document: nullnothing yetno caller sends supporting context today (true of all 116 rows); the jsonb takes any shape one sends, with no migration (§9)

The trail (outbox, live) ​

Every transition wrote a claims.events outbox row in the same transaction as the status change. Across all 116 prior-auths the census is:

prior_auth.submitted   116   (every submit; consumed by nothing)
prior_auth.escalated     8   (reviews; consumed by nothing)
prior-auth.decided      11   (approvals; document-service -> PRE_AUTH_LETTER)

All published (0 unpublished). Note the naming drift already visible here: submitted/escalated use an underscore, decided uses a hyphen - and only the hyphenated one matches a consumer key (§9).

Live population for context ​

116 prior-auths - 105 SUBMITTED, 11 APPROVED, and nothing in PENDING, PENDING_REVIEW or DENIED. procedure_code splits 99213×70 (office-visit seeder batch), empty×35 (the all-zero-uuid seeder rows), 27447×11 (the e2e-approved batch). document is NULL on all 116.

claim_documents: no live rows - the write path, walked ​

claims.claim_documents holds 0 rows as of 2026-08-21. The example below is constructed from the insert path, not pulled live - it is the shape AttachDocument would write[20] if POST /claims/{locator}/documents[22] were ever called:

json
{
  "id": "<generated uuid>",
  "claim_id": "<resolved from the {locator} path, must exist>",
  "filename": "referral.pdf",
  "content_type": "application/pdf",
  "url": "https://cdn.example/…/referral.pdf",
  "uploaded_at": "<now() at attach>",
  "created_at": "<now()>"
}

The handler resolves and tenant-checks the claim before inserting (loadOwnedClaim[22]), so a document can only be hung off a claim the caller may see, and the claim_id FK guarantees the claim exists. Everything above the FK is caller-supplied and unvalidated. Letters and statements are met by document-service today; this path activates the first time a claim carries its own supporting evidence, and the activation is a caller change rather than a schema one (§9).

7. Who references these tables ​

WhereColumn / mechanismMeaning there
document-serviceconsumes prior-auth.decided on claims.events[17][18]an approved/denied prior-auth becomes a PRE_AUTH_LETTER in its store - the only real downstream effect
web-admin / OllyverseGET /prior-auth/list (privileged)[13] → List[9]ops listing of prior-auth requests, filterable by policy/member/provider
MCP toolsservice_claims_priorauth_submit / _list / _review / _decide[19]the four routes exposed as tools; _decide maps {approve,deny} onto the two decision routes
member app (composite)MCP member_claim_detail composes claim_get + priorauth_list[27]"a claim and its associated prior-auths" for display
CDCDebezium dbz_claimsboth tables stream to the analytics sink
the claim adjudication pathnothing yetthe lookup is the deferred consumer in #1705; it activates when a product flags a benefit as requiring pre-approval (§9)

claim_documents has no external reader: the claims service is its only writer and reader (AttachDocument/ListDocuments), which is the posture an in-service attachment table wants - no cross-service contract to hold stable when it starts carrying rows. None of the above are FKs across services; all are locator or topic references (cross-service rule), except the in-service claim_documents → claims FK.

8. Design determinations ​

  1. Prior-auth is a standalone workflow, and the gate that consumes it is deferred by design. The table has its own locator, lifecycle and events, so the authorization side was built ahead of the products that need it: when a PA-requiring procedure arrives, turning the gate on is per-product configuration (a flag on the benefit in the catalogue jsonb, §9) plus one lookup in adjudication, rather than a new subsystem. Wiring that lookup is scoped in #1705.
  2. The full state machine superseded the original PENDING default. A later commit added SUBMITTED → PENDING_REVIEW → APPROVED | DENIED and made Submit write SUBMITTED[5]; the migration's 'PENDING' default[1] and the model's // PENDING | APPROVED | DENIED comment[3] are the fossils. The legacy PENDING acceptance in Approve/Deny is the compatibility bridge.
  3. Prior-auth is closed to employer tenants outright. A prior-auth carries no employer linkage claims can verify, so rather than ship an unprovable ownership check the route uses requirePrivileged[15] and refuses tenant tokens with 403; the handler comment records the residual caveat that any privileged caller can read them all[16] (the "105" in that comment is a stale count; the table is now 116).
  4. A decision produces a letter, and only a letter. prior-auth.decided is mapped to PRE_AUTH_LETTER in document-service[17], the sole consumer of any prior-auth event.
  5. Async intake, like claims. POST /prior-auth returns 202 and hands the row straight to SUBMITTED[14], matching the claim intake contract.
  6. Row + outbox in one transaction. Every prior-auth transition wraps its repo write and event enqueue in a single db.Transaction[5], so the audit event can never drift from the status.
  7. claim_documents ships ahead of need. Table, model, repository and endpoints are in place; while claims auto-approve there is nothing to attach, so it stays at 0 rows and attachments route through document-service. It populates when claims carry documents, and the first row costs no migration - the FK, the tenancy check and both endpoints are already there.
  8. Free-shape context is carried in jsonb on purpose. prior_auths.document and the coverage-term catalogue behind a benefit are both jsonb, so the supporting evidence a reviewer wants and the per-benefit flags a product needs are additive changes to a document, not ALTER TABLEs. That is what makes the §9 extension rows configuration rather than schema work.

No dedicated decision record or issue governs prior_auths in isolation; the state-machine and tenancy work landed as part of broader claims commits, and the semantic-events refactor that renamed the decided event travelled with #1644. No DR/issue numbers are asserted where none exist.

9. Caveats and extensibility ​

Group and individual. A prior-auth is keyed by member_party_id, a party uuid, and knows nothing about schemes - it serves scheme-based and direct-to-consumer members identically, with no schema change. The group-ness that matters is in authorisation, and there the design chose the honest posture: because the row carries no employer handle, prior-auth is closed to employer tenants entirely (§8.3) rather than shipping an ownership check it cannot prove, so today only admin and service callers reach it. When a member-owned prior-auth surface is needed, member_party_id is the scoping key already present.

Where to add what, when ​

The authorization side is complete: locator, state machine, transactional outbox, decision letter. What each future need costs is below. Every row is a change to a named surface, and the first two are the pair that switch the gate on together.

When we need ...What to addWhere
to carry procedures that require pre-approval (surgery, high-cost imaging, specialist referrals)a requires_prior_auth flag on the benefit, so only flagged coverage terms gate and everything else keeps auto-approvingthe module catalogue jsonb in policy_admin.product_versions.element_schema[30][29], surfaced as a field on catalogue.Module beside the per-benefit ReferralRequired that already exists[28]. A jsonb key and one struct field - no migration
the gate to have something to join oncoverage_term_key stamped on prior_auths at Submit (the benefit key claims.claim_lines[32] and eligibility.coverage_accumulators[33] already share), a claim_locator consume column so one authorization cannot be spent twice, and a valid_from/valid_to windowa new migration in services/claims/migrations/ (next free number after 0014), the stamp in PriorAuthService.Submit[5], and the field on the submit body[14]
adjudication to consult an authorizationthe lookup for an APPROVED, in-window, unconsumed prior-auth on (member_party_id, coverage_term_key), run before the accumulator burn so a missing authorization holds the claim rather than needing an allowance un-burntClaimService.autoApprove[31] in services/claims/internal/service/claim.go, ahead of the applyAccumulators call - the same ordering invariant that function already documents
a claim to carry supporting evidencenothing in the schema - start writing through POST /claims/{locator}/documents[22]rows land in claims.claim_documents; AttachDocument[20], ListDocuments[21], the FK and the tenancy check are the whole path
supporting context on the authorization itself (clinical notes, referral metadata, imaging refs)nothing - send document on the submit body[14]the document jsonb absorbs an arbitrary shape with no migration and no agreed schema up front
a reviewer to drive escalationthe UI only - Review / Approve / Deny already exist as HTTP routes[13] and MCP tools[19], which is why 105 of 116 rows sit in SUBMITTEDweb-admin / Ollyverse; the service, transitions and events need no change
a member-facing prior-auth surfacea party-scoped read in place of the blanket privileged check; member_party_id is the scoping key already on every rowrequirePrivileged[15] on the prior-auth routes[13]; the MCP member composite already joins the two[27]
a DB-level guarantee on the status vocabularya CHECK constraint naming SUBMITTED / PENDING_REVIEW / APPROVED / DENIED, once the legacy PENDING acceptance is retiredservices/claims/migrations/; the transitions themselves stay application-enforced (§4)

Known defect ​

Event-name drift, with a real consequence. prior_auth.submitted and prior_auth.escalated use an underscore; prior-auth.decided uses a hyphen[5][7]. document-service's map keys on the hyphen[17], so 116 submitted and 8 escalated events are produced and match no consumer key, while the 11 decided events land a letter. This is a naming bug, not a staging choice.

The fix: emit prior-auth.submitted and prior-auth.escalated (hyphen) from Submit[5] and Review[6] in services/claims/internal/service/priorauth.go, matching the semantic-events convention the decided event already follows, and backfill or accept the 124 historic rows in claims.outbox. Bundled into #1705.

Caveats worth knowing ​

  • The DB default 'PENDING' is unreachable, and the model comment still names the old three-state vocabulary - a schema that reads one way and behaves another. Both are fossils of the superseded design (§8.2); the fix is dropping the default and updating the comment on packages/go/domain/claims.go[3].
  • NOT NULL uuids satisfied by zero/placeholder values. policy_id, provider_id, member_party_id are NOT NULL but seeder rows carry 00000000-…, so the constraint proves presence rather than a real reference - the same illusion the Claim page calls out for element_id.
  • No FK on any prior-auth reference, including the two same-database ones (policy, member) that could in principle carry one.
  • Locator sequence has gaps - last_value 353 against 116 rows; 237 e2e rows minted and deleted.
  • claim_documents is append-only by repository convention, not by grant: only Create and ListByClaim exist[25], and nothing in the DB stops an UPDATE or DELETE being added.

References ​

Code links are pinned to commit b61c5802 on main (2026-08-21); the file is the anchor if lines drift. Pins are checked mechanically by docs/site/scripts/check-code-refs.py.

  1. claims/migrations/0006_create_prior_auths.sql - prior_auths DDL; status default 'PENDING' L8, UNIQUE locator L14, NOT NULL uuids L5-7
  2. 0005_create_claim_documents.sql - claim_documents DDL; FK to claims.claims L4, NOT NULL file fields L5-7
  3. packages/go/domain/claims.go#L99 - PriorAuth model; stale // PENDING | APPROVED | DENIED comment L105
  4. packages/go/domain/claims.go#L82 - ClaimDocument model
  5. claims/internal/service/priorauth.go#L45 - Submit: PAU- mint L54, status SUBMITTED L63, outbox prior_auth.submitted in one tx L67-74
  6. priorauth.go#L84 - Review: SUBMITTED→PENDING_REVIEW, prior_auth.escalated
  7. priorauth.go#L116 - Approve: accepts PENDING_REVIEW or legacy PENDING L125, stamps reviewed_at L133, prior-auth.decided
  8. priorauth.go#L151 - Deny: PENDING_REVIEW/PENDING → DENIED, prior-auth.decided
  9. priorauth.go#L197 - List: filter by policy/member/provider
  10. repository/gorm_priorauth.go#L42 - UpdateStatus: re-reads and asserts from before update L51-53
  11. gorm_priorauth.go#L89 - NextLocatorSeq: nextval('claims.prior_auths_locator_seq')
  12. 0010_add_locator_columns.sql#L4 - in-schema claims.prior_auths_locator_seq
  13. handler/handler.go#L128 - prior-auth routes behind requirePrivileged
  14. handler/priorauth.go#L14 - submitPriorAuth: decodes document, returns 202 L43
  15. handler/tenancy.go#L342 - requirePrivileged: 403 for tenant callers
  16. handler/handler.go#L119 - the privileged-only rationale + stale "105" open-read caveat
  17. document-service/internal/kafka/consumer.go#L30 - eventToTemplateType: prior-auth.decided→PRE_AUTH_LETTER L36, claim.approved→EOB L35
  18. document-service/internal/config/config.go#L58 - subscribes to claims.events
  19. mcp/server/src/tools/services/claims.ts#L44 - MCP prior-auth tools: submit/list/review/decide→route mapping
  20. claims/internal/service/claim.go#L868 - AttachDocument: inserts a claim_documents row
  21. claim.go#L886 - ListDocuments: reads by claim
  22. handler/claims.go#L428 - attachDocument: tenant-checks the claim (loadOwnedClaim), returns 201 L455
  23. handler/claims.go#L459 - listDocuments handler
  24. handler/handler.go#L116 - claim documents routes (POST/GET)
  25. repository/gorm_documents.go#L25 - Create + ListByClaim only (append-only, no update/delete)
  26. claims/cmd/server/main.go#L123 - PriorAuthService wired with db, repo, outbox
  27. mcp/server/src/tools/audience/member.ts#L67 - member composite: claim_get + priorauth_list
  28. packages/go/catalogue/catalogue.go#L47 - catalogue.Module, one benefit normalised; the per-benefit gate flag ReferralRequired L59 is the shape a requires_prior_auth flag takes
  29. policy-admin/internal/handler/onboarding_products.go#L74 - catalogue.Parse(v.ElementSchema) L81: the module catalogue is authored as the product version's element_schema jsonb
  30. policy-admin/migrations/0005_create_product_versions.sql - product_versions DDL; element_schema JSONB L9
  31. claims/internal/service/claim.go#L731 - autoApprove; the applyAccumulators burn at L758 is the point a prior-auth lookup precedes
  32. claims/migrations/0004_create_claim_lines.sql#L7 - claim_lines.coverage_term_key TEXT NOT NULL: the benefit key on the claim side
  33. eligibility/migrations/0003_create_coverage_accumulators.sql#L7 - coverage_accumulators.coverage_term_key: the same key on the eligibility side, part of UNIQUE uq_accumulator_key L13

Live-schema facts (status/locator-prefix census, the worked APPROVED row, the outbox event census by type, procedure_code/document distributions, sequence last_value, and the 0-row confirmation for claim_documents) come from PGPASSWORD=… psql -h 10.0.1.2 -U olly -d claims against claims.prior_auths, claims.claim_documents, claims.outbox, claims.prior_auths_locator_seq and pg_publication_tables, 2026-08-21.

Olly Health Insurance Platform

© 2026 Olly