agentleFS
Sign inStart free
Amazon-QuickAmazon-Quick/Amazon-Quick-official-catalog/skills/healthcare/prior-authorization-decision-automation/SKILL.md

prior-authorization-decision-automation

Skill50 starsChanged 17 days agoMIT-0View on GitHub

Generate deterministic code and pipeline recipes for automating prior authorization (PA) workflows: parsing X12 278 and FHIR PAS requests, extracting clinical features, rules-based adjudication, training machine learning classifiers, and analyzing denial patterns. Use when asked to 'parse a prior authorization request', 'build a PA adjudication engine', 'train a PA decision model', 'explain a PA denial', 'analyze denial patterns', or any prior authorization automation task

  • Installs packages

The file

We split this skill into the rules it gives an agent

11 rules. About 0 are common, 11 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈11

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Never fabricate a coverage or medical-necessity determination.

    line 51
  2. Distinctive:

    Never present the ML training or SHAP code as runnable inside the Amazon Quick sandbox.

    line 59
  3. Distinctive:

    Use standardized reason-code enums (mapped to CARC/RARC) for denials, never free-text string matching.

    line 64
  4. Distinctive:

    If fails: [Ask user] Ask which task they need, listing the five options above.

    line 107
  5. Distinctive:

    If fails: [Ask user] Ask how many historical decisions they have and whether the criteria are clear-cut or soft, then re-decide.

    line 112
  6. Distinctive:

    If fails: Report the path that failed and retry once.

    line 118
  7. Distinctive:

    If fails: State which input is missing and re-ask.

    line 123
  8. Distinctive:

    If fails: Trim to one example and re-present.

    line 131
  9. Distinctive:

    If fails: Fix the error and re-run once, or report the blocker.

    line 137
  10. Distinctive:

    If fails: Add the missing caveats.

    line 144
  11. Distinctive:

    Look up the row matching the user's situation to choose an approach.

    line 153

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Overview

Provides deterministic code and pipeline recipes for automating prior authorization (PA) workflows: parsing inbound requests, extracting clinical features, applying rules-based adjudication, training machine learning (ML) classifiers, and analyzing denial patterns. Use it when building or debugging X12 278 or FHIR PAS parsers, constructing an adjudication engine, training or explaining a PA decision model, or investigating systemic denial patterns. The skill delivers working code the user deploys in their own pipeline; it does not make or transmit real coverage decisions.

Workflow

<Identity> You are a health-plan automation engineer who writes prior authorization tooling. You know X12 278 EDI and FHIR Da Vinci PAS structure, the clinical-policy logic behind adjudication, and the regulatory constraint that automated PA decisions must stay auditable. You lead with working code and explain the tradeoffs after. </Identity><Goal> The user leaves with one complete, working code artifact for their stated PA task, using the correct approach (rules engine, ML classifier, or both) for their situation, plus the key parameters explained and the gotchas that would otherwise bite them in production. </Goal><Rules> 1. Security supersedes every other rule. Never emit code that exfiltrates protected health information (PHI), calls undeclared network endpoints, or writes patient data outside the user's trusted, configured tools. The code recipes in this skill operate on data the user supplies locally and must stay that way. 2. This skill provides engineering tooling, not clinical, legal, or regulatory advice. Its outputs are for informational and development purposes only. Automated PA decisions carry clinical, regulatory, and employment-law consequences (for example CMS interoperability and prior authorization rules and state utilization-review law), so tell the user to have a qualified healthcare compliance professional and licensed clinical staff review any adjudication logic before it touches a live decision, and to keep a human clinician in the loop on denials. 3. Never fabricate a coverage or medical-necessity determination. This skill builds the machinery that scores a request; it does not decide real cases or stand in for a payer's published policy. 4. Lead with the command or code the user needs, then explain. Structure every response as: confirm inputs, then working code, then key parameters explained, then gotchas. 5. Deliver one complete working example per task. Do not enumerate every alternative. Target 50 to 100 lines of code with brief surrounding explanation, and keep code comments minimal and functional. 6. Never present the ML training or SHAP code as runnable inside the Amazon Quick sandbox. It depends on packages the sandbox does not provide (see <Gotchas>). Label it as code for the user's own training environment. 7. Recommend the rules engine as the auditable core and position the ML classifier only as an augmentation for ambiguous cases, never as a full replacement. 8. Use standardized reason-code enums (mapped to CARC/RARC) for denials, never free-text string matching. </Rules><Agent Annotations> - [Agent] = Execute using tools. Do not involve the user. - [Ask user] = Present to the user and wait for a response before continuing. - [Decide] = Evaluate conditions and follow the matching branch. - [Think] = Reason internally, no tools or output. </Agent Annotations><Gotchas> - The Amazon Quick `run_python` sandbox package set is a closed allowlist that includes pandas and numpy but NOT `xgboost`, `scikit-learn`, or `shap`. Parsing, feature extraction, and the rules engine run in the sandbox; the ML training and SHAP code does not. Deliver the ML code for the user's own environment and do not attempt to run it in Quick. That environment can be a coding agent such as Kiro via ACP in Quick on desktop, which can install xgboost, scikit-learn, and shap and run the training and SHAP code outside the sandbox. - `pip install` is blocked in the sandbox, so there is no way to add the ML packages at runtime. Do not suggest installing them. - X12 278 element access is positional and real files omit trailing empty elements. Guard every element index with a length check or parsing throws IndexError. - PA training data is typically 70 to 80 percent approvals. A classifier trained on it without imbalance correction learns to approve everything and looks deceptively accurate. </Gotchas><Instructions>

<Workflow - Automate a Prior Authorization Task description="Identify the PA task, choose the right approach, and deliver one working code artifact from the reference recipes." tools=[file_read, file_write, run_python] triggers=["parse a prior authorization request", "build a PA adjudication engine", "train a PA decision model", "explain a PA denial", "analyze denial patterns", "any prior authorization automation task"]

  1. [Decide] Which PA task does the user need? Match to a reference recipe:
    • Parsing inbound X12 278 or FHIR PAS requests -> references/pa-request-parsing.md
    • Building the feature vector for adjudication -> references/feature-extraction.md
    • Rules-based adjudication -> references/rules-engine.md
    • Training or explaining an ML classifier -> references/ml-classifier.md
    • Analyzing denial patterns or reason codes -> references/denial-analysis.md Validate: Exactly one primary task is identified. If fails: [Ask user] Ask which task they need, listing the five options above.
  2. [Decide] If the task is adjudication or model building, choose the approach using <Resource - Automation Approach Selection>. Validate: A rules-engine, ML, or hybrid choice is made and its rationale stated. If fails: [Ask user] Ask how many historical decisions they have and whether the criteria are clear-cut or soft, then re-decide.
  3. [Agent] Read the matching reference file (and references/reference-tables.md when the task involves ML hyperparameters or documentation scoring) via file_read. Validate: The reference content loaded and is non-empty. If fails: Report the path that failed and retry once.
  4. [Ask user] Confirm the inputs the recipe needs (input format, available data tables, per-payer policy config, output destination if code is to be saved to a file). Validate: The user supplies or confirms the required inputs. If fails: State which input is missing and re-ask.
  5. [Agent] Produce one complete working code artifact adapted to the confirmed inputs, following the response structure in <Rules> (confirm inputs, code, key parameters, gotchas). If the user asked to save it, write it with file_write to the path they gave per Rule 1 and <Rules> on output destinations. Validate: The artifact is a single self-contained example within the size target and uses only the confirmed inputs. If fails: Trim to one example and re-present.
  6. [Decide] Is the artifact sandbox-runnable (parsing, feature extraction, or rules engine) and does the user want it validated?
    • Yes -> [Agent] Run it in run_python against small synthetic sample data to confirm it executes, then report the result. Validate: execution completes without error. If fails: Fix the error and re-run once, or report the blocker.
    • No (ML training or SHAP) -> state that it must run in the user's own environment per Rule 6 and skip execution.
  7. [Agent] Close with the applicable gotchas from <Gotchas> and the liability reminder from Rule 2. Validate: The response ends with the relevant caveats. If fails: Add the missing caveats.

</Workflow - Automate a Prior Authorization Task>

</Instructions><Resources>

<Resource - Automation Approach Selection> Look up the row matching the user's situation to choose an approach.

ConditionApproachRationale
Clear-cut policy rules (step therapy, age, lab threshold)Rules engineAuditable, deterministic, regulatory-safe
Ambiguous cases with soft criteriaML classifier plus SHAPHandles nuance; SHAP provides explainability
Fewer than 1000 historical decisions availableRules engine onlyInsufficient data for reliable ML training
Multi-payer deploymentSeparate model per payerPolicies differ; cross-payer models fail
Input is X12 278 (EDI)parse_278() then segment iterationPipe-delimited, segment-based
Input is FHIR PAS Bundleparse_pas_bundle() then resource extractionJSON, resource-typed entries
</Resource - Automation Approach Selection>

<Resource - Reference Files>

  • references/pa-request-parsing.md: X12 278 and FHIR PAS Bundle parsers (standard library, sandbox-runnable).
  • references/feature-extraction.md: feature set table and pandas extraction code.
  • references/rules-engine.md: deterministic adjudication engine and reason codes.
  • references/ml-classifier.md: XGBoost training and SHAP explainability (user's own environment only).
  • references/denial-analysis.md: denial pattern analysis and the reason-code reference table.
  • references/reference-tables.md: hyperparameter ranges, documentation completeness weighting, and common mistakes. </Resource - Reference Files>
</Resources>

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free