Healthcare revenue cycle and prior authorization datasets for AI training

A healthcare revenue cycle dataset is a de-identified, linked set of the administrative transactions between a patient visit and final payment: eligibility checks, prior authorization requests and payer decisions, claims and remittances, and the denials and appeals that followed. SourceX sources these records from provider groups, billing companies and revenue cycle teams running systems such as Epic, athenaOne or Waystar. Before delivery, records are de-identified using HIPAA's Safe Harbor or Expert Determination method, chosen with the data owner.

Request this dataset Email the data team

Dataset manifest

Sourced to your spec

What it is: Linked prior authorizations, claims, remittances, denials and appeals for real encounters
Typical systems: Epic Resolute, Oracle Health, athenaOne, eClinicalWorks, NextGen, Waystar, Availity
Typical history: Varies by partner; billing-system migrations can cut history short
Modality: Structured transactions and codes, plus determination letters, appeals and clinical attachments
Delivery formats: Agreed per order; encounter-linked Parquet or JSONL, or de-identified X12 files
Preparation: De-identified by Safe Harbor or Expert Determination, as agreed with the data owner
Licensing: Permitted use agreed per order; terms usually bar re-identification and linkage
Availability: Sourced to your spec from providers and billing organizations; not guaranteed

Request this dataset

What a delivery contains

Fields vary by source system and are fixed per order. A typical delivery includes:

Field	Type	What it holds
encounter_id	string	Random pseudonymous key linking every transaction for one episode of care, not derived from patient or account numbers.
patient	object	Pseudonymous patient token with age band, sex and state; under Safe Harbor, ages over 89 are grouped together.
coverage	object	Payer category (commercial, Medicare Advantage, Medicaid managed care, traditional Medicare or other), a payer pseudonym and the eligibility response.
prior_auth	object	Request channel (X12 278, payer portal, fax or phone), requested services, diagnosis codes, urgency and the clinical documents attached.
prior_auth.events	array	Submission, pends for more information, peer-to-peer reviews and the determination, with approved services and units.
claim	object	Professional or institutional claim from the 837 with setting, billed charges, claim frequency and the authorization reference.
claim.lines	array	Service lines with CPT or HCPCS codes, modifiers, units, revenue codes on facility claims and pointers to ICD-10-CM diagnoses.
edits	array	Scrubber, clearinghouse and payer front-end rejections raised before adjudication, and how each was corrected.
remittance	object	Adjudication from the 835 per line, including allowed and paid amounts, patient responsibility, and CARC, RARC and group codes.
work_queue	array	Follow-up on the account by role — payer calls, corrected claims, reconsiderations, appeals, write-offs — in order.
appeal	object	Appeal level, de-identified letter text, evidence attached and the payer's decision.
outcome	object	Final status such as paid, partly paid, written off or billed to the patient, with elapsed days where the method allows.
deid	object	The de-identification method, how dates and free text were treated, and any conditions an expert set.

Example record

{
  "encounter_id": "enc_6b20f4",
  "deid": { "method": "expert_determination", "dates": "day_offsets_from_first_event", "free_text": "scrubbed_and_reviewed" },
  "patient": { "id": "pt_91ce", "age_band": "55-64", "sex": "F", "state": "[STATE]" },
  "coverage": { "payer": "payer_07", "payer_type": "commercial_ppo", "eligibility": "active" },
  "prior_auth": {
    "channel": "payer_portal", "requested": [{ "cpt": "73721", "units": 1 }], "dx": ["M17.11"],
    "attachments": ["office_note", "xray_report"],
    "events": [
      { "day": 0, "type": "submitted" },
      { "day": 2, "type": "pended", "reason": "Need notes showing 6 weeks of conservative therapy." },
      { "day": 5, "type": "info_sent", "doc": "pt_progress_note" },
      { "day": 7, "type": "approved", "auth_ref": "auth_tok_33a", "approved": [{ "cpt": "73721", "units": 1 }] }
    ]
  },
  "claim": { "form": "837P", "service_day": 12, "submitted_day": 16, "service_year": 2024,
             "setting": "freestanding_imaging", "frequency": "original", "auth_ref": "auth_tok_33a",
             "lines": [{ "cpt": "73723", "units": 1, "dx_ptr": [1], "charge": 2140.00 }] },
  "remittance": { "day": 38, "paid": 0.00,
                  "adjustments": [{ "group": "CO", "carc": "15", "rarc": ["N54"], "amount": 2140.00 }] },
  "work_queue": [
    { "day": 41, "role": "denials_specialist", "action": "note",
      "text": "Auth covers 73721 only. Radiologist added contrast after first sequences. Requesting auth update." },
    { "day": 44, "role": "denials_specialist", "action": "appeal_level_1",
      "attachments": ["radiology_report", "auth_update_request"] }
  ],
  "appeal": { "level": 1, "decision_day": 71, "result": "overturned",
              "text": "[DE-IDENTIFIED LETTER: medical necessity of contrast, citing findings in radiology report]" },
  "outcome": { "status": "paid_after_appeal", "paid": 612.40, "paid_day": 75,
               "days_service_to_payment": 63, "follow_up_actions": 2 }
}

Synthetic record for illustration. Field names, structure and format are agreed per order.

What AI teams use it for

Train prior authorization agents

Requests that were pended and then approved once more documentation arrived show what each payer actually asked for, so an agent can assemble a complete request the first time.

Predict and prevent denials

Claims linked to their remittances, with CARC and RARC codes, label which coding, authorization and eligibility patterns led to denials before the claim went out.

Choose the next action on a denied claim

Work-queue histories and appeal results show which response worked for each denial reason: a corrected claim, a phone call, a reconsideration or a formal appeal.

Automate payment posting and underpayment review

Remittance details joined to the original claim lines teach models to post payments, spot short-pays and route variances, where payment amounts are kept in scope.

Build held-out evaluation sets for revenue cycle agents

Encounters with known determinations and final payment become private test items for checking authorization, coding and denial decisions against what actually happened.

Use-case guides: Healthcare administration AI, Private evaluation sets

What makes this data valuable

Encounter linkage

Authorization, claim, remittance and appeal share one token, so late outcomes reach the decision that caused them.

Standard reason codes

CARC, RARC and group codes give machine-readable denial labels, even though payers apply them unevenly.

Appeal results

Overturned and upheld decisions show which arguments and evidence changed a payer's mind.

Pend histories

Requests for more information record exactly what a reviewer found missing from an authorization request.

Payer and specialty mix

Rules differ by payer type, plan and specialty, so breadth across payers matters more than depth in any one.

Dated code sets

Recording the service year with each code keeps annual ICD-10-CM and CPT changes from turning into label noise.

Where raw claim and remittance data misleads

Revenue cycle data looks standardized because it travels as X12, but it records a running negotiation with payers, and several of its habits mislead when read at face value:

Claims have versions. A corrected claim (frequency code 7) replaces an earlier one, a void (code 8) cancels it, and an 835 can reverse an earlier payment (claim status code 22) and re-adjudicate the claim. Collapse each claim to its final state, or one encounter counts as several denials.
Rejections never reach the remittance. Claims stopped by a clearinghouse or a payer's front end come back on acknowledgments such as the 277CA, not the 835, so remittance-only data misses the cheapest errors to fix.
Money moves between claims. Provider-level adjustments on an 835 recoup overpayments on earlier claims from the current payment, so a remittance total can reflect encounters that are not on it.
Only worked denials have follow-up. Teams prioritize by balance and payer, and small denials are often written off untouched, so appeal success rates describe the denials someone chose to fight.
Much prior authorization happens off X12. Requests and decisions also move through payer portals, fax and phone, so the record may be a fax image or a work-queue note rather than a 278.
Code sets change on a calendar. ICD-10-CM is revised each year from October 1 and CPT from January 1, with some mid-year changes, so each code has to be read against its service date.

How de-identification lands on revenue cycle fields

Both methods in 45 CFR 164.514 change specific fields (HHS guidance):

Control numbers are the join keys. The patient control number links an 837 to its 835; member, claim and authorization numbers are identifiers too. Random tokens from one mapping held by the data owner keep the files linkable, and HIPAA allows such codes when they are not derived from information about the patient.
Dates carry the deadlines. Filing limits, authorization validity and appeal windows are counted in days. Safe Harbor keeps only years. Under Expert Determination, shifting each patient's dates by a random offset can keep every interval while hiding calendar dates, where the expert's analysis supports it.
The group name is often an employer. Safe Harbor treats a patient's employer's name as an identifier, and the insured group name on a commercial claim frequently is one. HHS does not require removing providers' names, but they reveal the source practice, so data owners may ask for them to be pseudonymized.
Free text holds what scrubbing misses. Appeal letters, clinical notes and faxed pages carry names, dates and record numbers in places structured rules do not reach.

Request the narrowest field list that serves the task. HIPAA's minimum necessary standard limits protected health information used or disclosed for a purpose to what it requires, and each field left out is one fewer to de-identify.

What to check before licensing

Map the chain of custody. A billing company or revenue cycle vendor usually works as a business associate of its provider clients; its agreement has to permit de-identification, and the providers usually have to approve licensing.
Get in writing which de-identification method was applied to each source, and by whom. For an Expert Determination, ask what conditions the expert set on recipients and how long the determination stays valid, since HHS notes that some experts issue time-limited determinations.
Check how encounter and patient tokens were generated. HHS treats a code derived from an identifier without a secret key, such as a plain hash of a member ID, as an identifier itself.
Test free text and attachments on the sample — clinical notes, appeal letters, faxed pages and scanned remittances — for names, dates, record numbers and practice letterheads.
Measure linkage on the sample, including the share of claims with a matching remittance, of denials with a recorded follow-up and of authorization requests with a determination.
Decide early what happens to dollar amounts. Allowed and paid amounts expose negotiated rates that payer contracts may keep confidential, and banding them, or keeping only whether each line paid in full, in part or not at all, still preserves denial and underpayment labels.
Ask whether sensitive services such as substance use disorder treatment and reproductive or behavioral health are excluded, and which state rules apply on top of HIPAA. California, for example, requires contracts licensing de-identified patient information to bar re-identification.
Check that codes are valid for their service year, and agree whether CPT descriptor text is included, since the American Medical Association licenses CPT content.

How licensing works through SourceX

1
Define
Send the domain, modality, volume, format, timeline and permitted use you need.
2
Source
SourceX identifies businesses that hold matching data and are open to licensing it.
3
Qualify
Fit, rights and quality are checked, and you review samples before committing.
4
License
Scope, permitted use, exclusivity, price and obligations are agreed in writing.
5
Deliver
Approved data is prepared, de-identified where required and transferred securely.

Questions buyers ask

Who has the right to license revenue cycle data?

Usually the healthcare provider, as the covered entity whose records they are. Billing companies, revenue cycle vendors and clearinghouses hold claims for many providers, but they process them under business associate agreements and client contracts that limit what they may do with the data, so the provider's approval is normally needed as well. Rights are confirmed before a dataset is offered, and supply depends on which organizations agree to license.

Which HIPAA de-identification method fits revenue cycle data?

It depends on whether the task needs day-level timing. Safe Harbor, under 45 CFR 164.514(b)(2), strips 18 categories of identifiers, including every element of a patient's dates except the year, and the data holder must not have actual knowledge that what remains could identify a patient. That still leaves enough for coding, denial-reason and appeal-drafting work. Expert Determination, under 164.514(b)(1), has a qualified expert assess and document that the risk of identifying anyone is very small for the intended recipient, and can preserve day-level timing for deadline and turnaround tasks.

Can I get the raw X12 837 and 835 transactions?

Sometimes, after de-identification. Raw X12 carries identifiers in predictable places: names in NM1 segments, addresses in N3 and N4, birth dates in DMG, account and claim numbers in CLM and CLP, and more in REF and date segments. These are removed or replaced while keeping the files parseable. Parsed records linked by encounter are often more useful, because most of the value lies in joining authorization, claim, remittance and follow-up records, not in the envelope structure.

Do prior authorization records include clinical documentation?

Often. Requests and appeals carry office notes, imaging and lab reports, therapy notes and letters of medical necessity, because that evidence decides the outcome. It is also the most identifying part of the record, and HHS guidance says identifiers must be removed from free text as well as structured fields. Clinical attachments are included only when they can be de-identified and checked on the sample; otherwise the scope keeps codes, determinations and reason text.

Does a business associate agreement apply to this data?

A business associate agreement (BAA) covers whoever handles identifiable data for a provider before de-identification, such as its billing company. HHS guidance allows a business associate to de-identify protected health information for a covered entity only to the extent the BAA authorizes it. Properly de-identified data falls outside the Privacy Rule's definition of protected health information, so a buyer of a de-identified dataset does not sign a BAA. The license carries the obligations instead, typically a ban on re-identification and on linkage with other data.

How reliable are denial reasons as labels?

Useful but imperfect. CARC and RARC codes are standard, yet payers pick different codes for the same problem, and many denials turn out to be fixable data errors rather than coverage decisions. The real label is what happened next: a corrected claim, an appeal, payment or a write-off. Recent data may carry more detail, because a 2024 CMS rule requires Medicare Advantage, Medicaid, CHIP and federal-exchange plans to give a specific reason when they deny prior authorization for items and services other than drugs, from 2026.

Can a dataset be limited to certain specialties, payers or states?

Yes. Scope is set per order by specialty, care setting such as physician practice or hospital outpatient department, payer type, state and service year. Payer names may be pseudonymized at the data owner's request, and narrow combinations, such as a rare specialty in a small state, can raise re-identification risk enough to need generalization. What can be supplied depends on which organizations hold matching records and agree to license them.

Insurance claims workflows
Claim files from first notice of loss to closure, with reserves, notes and outcomes
Contact center call recordings and transcripts
Recorded service and support calls with diarized transcripts, dispositions and QA scores
SOPs, playbooks and internal knowledge bases
Written procedures with page history, ownership and links to execution records
Human feedback and QA-scored work
Work items with scores, verdicts and corrections from the people who reviewed them
Enterprise workflow and task execution histories
Linked task trajectories from request to outcome, across every tool the work touched

Evaluating this data for procurement?

Diligence packets are prepared per dataset. Rights, privacy processing and quality differ between datasets.

Request dataset diligence

Tell us what your models need

Send your spec — domain, volume, format, timeline and permitted use — and SourceX will match it against partner data and come back with what can be licensed.