Prior Authorizations

Datasets

Built to Da Vinci PDex STU 2.1.0. An authorization becomes one ExplanationOfBenefit with use = preauthorization, not a Claim. Three files: the authorization and its decision, the items it covers, and the links from an authorization to the documents behind it.

Prior authorization data often sits with a delegated utilization-management vendor rather than with the plan. Whoever holds it delivers this feed.

Data conventions

PDex points the authorization's insurance at the HRex Coverage profile, whose beneficiary is an HRex Patient. An authorization sends no coverage data of its own beyond coverage_id, and almost everything those two profiles demand is already required elsewhere: the member id and subscriber relationship in coverage, the name in patients. The one exception is birth_date, recommended in the clinical feed and required for any member who has an authorization: a member missing it cannot have one published.

prior_auths

One row per authorization.

Authorization states

status carries the lifecycle of the record, outcome says how far processing got, and review_action_code carries the decision. Each state brings its own required columns.

• An authorization that has run out of time stays active. cancelled means withdrawn, not lapsed. Keep sending the row for as long as History asks for it.
• A partial approval is decided per line, so the authorization row carries outcome = partial and the reasons sit on the lines that were cut or refused. Send authorization-level denial columns only when the whole request was refused.
• claim_type has no pharmacy value: drug authorizations are out of scope. Dental is oral, vision is vision. Blank reads as professional. It is not derived from the lines, so send institutional yourself for a facility authorization.
• The provider columns take an NPI, or the id that provider is registered under in practitioners and organizations. A provider known only by a name cannot be published.
• outcome is about processing, review_action_code about the decision. They are not interchangeable, so send both: a request reviewed and sent back for more information is queued with a review action of pended. A cancelled authorization keeps the outcome it had reached and says it was cancelled in status.
• review_action_code, review_number, review_reason_codes, second_surgical_opinion_flag and decision_date publish only on a row that also carries denial_reason_codes or submitted_amount. The lines carry the same rule.
• Leave auth_period_end blank when the authorization ends on a unit or visit allowance rather than a date. allowed_units on the line then says when it is exhausted. Both may be present.
• denial_reason_codes takes CARC and RARC codes only, so a payer-defined code cannot go there. Put the wording in denial_reason_text; both are published.
• The amounts are optional; an authorization decided on medical necessity alone carries none. Send them where you have them.
• A home-care authorization is approved as a schedule: how many hours, on which days. A line's unit count cannot express that, so it goes in process_note_. Fill the slots in order. A note is published as written and never parsed.

prior_auth_lines

One row per item or service on the authorization. An authorization covering three services has three rows carrying the same prior_auth_record_id. Lines have no is_deleted: an authorization is delivered as a whole, so re-sending it replaces its previous lines.

Requested

Authorized

Send these columns only where what was authorized differs from what was requested. An approval with no changes needs none of them.

Decision

• A line is identified by service_code or by revenue_code. A revenue code cannot go in service_code: send it in revenue_code and leave service_code empty. Facility authorizations in behavioral health, inpatient, skilled nursing and rehabilitation routinely carry only a revenue code.
• service_description is what carries meaning when the line has no procedure code. Send it on every line identified by revenue_code or service_category_code.
• service_category_code comes from the X12 service type code list, the same list a 278 carries. Send the code; Payerbox adds the system.
• The authorized columns are how a modified approval is expressed: what the provider asked for stays in service_code and quantity_value, and what the payer granted goes in authorized_service_code and authorized_quantity_value. Twelve visits requested and eight approved leaves both numbers on the line, and the member sees both.
• The requested and authorized columns bind to different code lists. Send either spelling of HCPCS; Payerbox translates. CPT works in both, and the authorized list also takes X12 1365, ICD-9-CM, ICD-10-PCS and NDC. HIPPS is accepted only as requested, so express a HIPPS change through authorized_quantity_value.
• There is no column for procedure modifiers, unit price, revenue code, nursing-home level of care or the EPSDT indicator on an authorized line.
• A line's review action needs a host, as the authorization's does: send review_action_code only where the line also carries allowed_units, consumed_units, a denial reason or an amount. A pending line with none of them lets outcome on the authorization report that the request is still in processing.
• allowed_units and consumed_units are the utilization pair: what was granted, and how much of it is used. They are the only way a unit-limited authorization says how much is left, so send consumed_units whenever your system tracks it.
• Amounts sit on the authorization, not the line: submitted_amount and eligible_amount on prior_auths. PDex allows them per line; this feed has no column for them.

prior_auth_documents

One row per link between an authorization and a document behind it: the clinical notes, forms and letters a provider submitted with the request. The document itself travels in documents, which carries the file; this row says which authorization it belongs to.

• A document_record_id is not checked against documents at ingest, so a link to a document that never arrives dangles. Deliver both in the same window.
• One document can support several authorizations, and one authorization can have many documents. Send a row per pair.
• Documents are what the provider submitted. A denial letter the plan issued does not belong here.
• The link is per authorization, so a document store keyed only to the member cannot produce these rows. Those documents still travel in documents and are served as clinical documents, with nothing tying them to an authorization.
• documents takes LOINC type_code only, so a library typed by its own codes needs a crosswalk. It is short in practice: 11488-4 consult note, 18842-5 discharge summary, 96349-6 referral letter, 52036-1 home health prior authorization, 94118-7 medical records in response to authorization denial, and 34109-9 note for anything with no better match.

These resources are served by Patient Access, Provider Access, and Payer-to-Payer.