agentleFS
mark64oswaldmark64oswald/healthsim-workspace/skills/membersim/SKILL.md

membersim

Skill9 starsChanged 17 days agoApache-2.0View on GitHub

MemberSim generates realistic synthetic claims and payer data for testing claims processing systems, payment integrity, and benefits administration.

The file

We split this skill into the rules it gives an agent

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    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:

    Use this skill when the user requests healthcare claims, payer data, or benefits administration cohorts.

    line 10
  2. Distinctive:

    Create professional and facility claims with proper coding

    line 23
  3. Distinctive:

    No clinical advice: Never recommend treatments, prescriptions, or clinical decisions based on generated data.

    line 34
  4. Distinctive:

    Use valid medical code systems: Always reference recognized standards: ICD-10 for diagnoses, CPT/HCPCS for procedures, NPI for providers, …

    line 35
  5. Distinctive:

    Use profile specifications to generate member populations:

    line 368
  6. Distinctive:

    Create initial utilization claims

    line 390
  7. Distinctive:

    When generating across products, MemberSim entities are automatically linked:

    line 396

≈ “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

MemberSim - Claims and Payer Data Generation

For Claude

Use this skill when the user requests healthcare claims, payer data, or benefits administration cohorts. This is the primary skill for generating realistic synthetic claims and member data.

When to apply this skill:

  • User mentions claims, billing, or reimbursement
  • User requests 837P (professional) or 837I (facility) claims
  • User specifies payer, insurance, or benefits cohorts
  • User asks for X12 formatted output (834, 835, 837, 270/271)
  • User needs member enrollment, eligibility, or prior authorization data

Key capabilities:

  • Generate members with coverage and benefit plans
  • Create professional and facility claims with proper coding
  • Model claim adjudication with CARC codes and payment calculations
  • Track accumulators (deductible, OOP, coinsurance)
  • Handle prior authorization workflows
  • Transform output to X12 formats (837, 835, 834, 270/271)

For specific claims cohorts, load the appropriate cohort skill from the table below.

Safety Guardrails

  • All data is synthetic. MemberSim generates fictional, simulated test data. No real patient or member data is used.
  • No clinical advice. Never recommend treatments, prescriptions, or clinical decisions based on generated data. This is test data, not real medical records.
  • Use valid medical code systems. Always reference recognized standards: ICD-10 for diagnoses, CPT/HCPCS for procedures, NPI for providers, NDC/RxNorm for drugs, LOINC for labs, SNOMED CT for clinical terms.
  • Do NOT generate real SSNs, real member IDs from production systems, or data that could be confused with actual PHI.

Overview

MemberSim generates synthetic claims and payer data for testing claims processing, payment integrity, and benefits administration:

Quick Start

Simple Professional Claim

Request: "Generate a professional claim for an office visit"

{
  "claim": {
    "claim_id": "CLM20250115000001",
    "claim_type": "PROFESSIONAL",
    "member_id": "MEM001234",
    "provider_npi": "1234567890",
    "service_date": "2025-01-15",
    "place_of_service": "11",
    "principal_diagnosis": "I10",
    "claim_lines": [
      {
        "line_number": 1,
        "procedure_code": "99214",
        "charge_amount": 175.00,
        "units": 1
      }
    ]
  },
  "adjudication": {
    "status": "paid",
    "allowed_amount": 125.00,
    "paid_amount": 100.00,
    "copay": 25.00
  }
}

Facility Claim with DRG

Request: "Generate an inpatient claim for heart failure admission"

Claude loads facility-claims.md and produces a complete 837I-style claim:

{
  "claim": {
    "claim_type": "INSTITUTIONAL",
    "principal_diagnosis": "I50.9",
    "drg": { "ms_drg": "291", "description": "Heart failure & shock w/o CC/MCC" },
    "admit_date": "2025-01-10",
    "discharge_date": "2025-01-13",
    "claim_lines": [
      { "revenue_code": "0120", "description": "Room and board - semi-private", "per_diem": 1800.00, "units": 3 },
      { "revenue_code": "0250", "description": "Pharmacy", "charge_amount": 950.00 },
      { "revenue_code": "0300", "description": "Laboratory", "charge_amount": 1200.00 }
    ]
  }
}

Cohort Skills

Load the appropriate cohort based on user request:

CohortTrigger PhrasesFile
Plan & Benefitsplan, benefit plan, HMO, PPO, HDHP, copay, deductible structureplan-benefits.md
Enrollment & Eligibilityenrollment, eligibility, 834, 270, 271, coverageenrollment-eligibility.md
Professional Claimsoffice visit, 837P, physician claim, E&Mprofessional-claims.md
Facility Claimshospital, inpatient, 837I, DRG, UB-04facility-claims.md
Prior Authorizationprior auth, pre-cert, authorization, PAprior-authorization.md
Accumulator Trackingdeductible, OOP, accumulator, cost sharingaccumulator-tracking.md
Value-Based Carequality measures, VBC, HEDIS, risk adjustment, HCC, care gapsvalue-based-care.md
Behavioral Healthmental health, psychiatry, psychotherapy, substance abuse, SUDbehavioral-health.md

Generation Parameters

ParameterTypeDefaultDescription
claim_typestringPROFESSIONALPROFESSIONAL, INSTITUTIONAL, DENTAL
claim_statusstringpaidpaid, denied, pending, partial
network_statusstringin-networkin-network, out-of-network
member_ageint or range18-65Member age
plan_typestringPPOHMO, PPO, EPO, POS, HDHP

Output Entities

EntityKey Fields
Membermember_id, subscriber_id, group_id, plan_code, coverage_start/end, PCP (HMO)
Claimclaim_id, claim_type, member_id, provider_npi, service dates, diagnosis codes, claim_lines[]
ClaimLineprocedure_code (CPT/HCPCS), modifiers, units, charge_amount, revenue_code (institutional)
Adjudicationstatus (paid/denied/pending), allowed_amount, paid_amount, deductible, copay, coinsurance, adjustment_reason_codes
Planplan_type (HMO/PPO/etc.), deductibles, OOP maximums, copays, coinsurance rates, network requirements
Accumulatordeductible_accumulated vs remaining, OOP/MOOP accumulated vs remaining, family vs individual tracking

See ../../references/data-models.md for complete schemas.

Adjudication Logic

Payment Calculation

1. Verify eligibility (coverage active on service date)
2. Check network status (in-network vs OON)
3. Determine allowed amount (fee schedule or % of charges)
4. Apply cost sharing:
   a. Deductible (if not met)
   b. Copay (fixed amount)
   c. Coinsurance (% of allowed after deductible)
5. Calculate paid amount = allowed - member responsibility
6. Update accumulators (deductible accumulated/remaining, OOP/MOOP accumulated/remaining)

Common Denial Reasons

CodeDescriptionCohort
CO-4Procedure code inconsistent with modifierInvalid modifier
CO-45Charge exceeds fee scheduleUCR violation
CO-50Non-covered servicesBenefit exclusion
CO-96Non-covered charge(s)Out of network, no OON benefit
CO-97Benefit included in another serviceBundling
PR-1Deductible amountMember responsibility
PR-2Coinsurance amountMember responsibility
PR-3Copay amountMember responsibility

Output Formats

FormatRequestUse Case
JSONdefaultAPI testing
X12 834"as 834", "X12 enrollment"Enrollment file
X12 270"as 270", "eligibility inquiry"Eligibility request
X12 271"as 271", "eligibility response"Eligibility response
X12 837P"as 837P", "X12 professional"Claims submission
X12 837I"as 837I", "X12 institutional"Facility claims
X12 835"as 835", "remittance"Payment posting
CSV"as CSV"Analytics
SQL"as SQL"Database loading

See ../../formats/ for transformation skills.

Examples

Example 1: Paid Office Visit

Request: "Generate a paid claim for a 99214 office visit for hypertension"

{
  "member": {
    "member_id": "MEM001234",
    "name": { "given_name": "Sarah", "family_name": "Johnson" },
    "birth_date": "1978-06-15",
    "gender": "F",
    "plan_code": "PPO-GOLD",
    "coverage_start": "2024-01-01"
  },
  "claim": {
    "claim_id": "CLM20250115000001",
    "claim_type": "PROFESSIONAL",
    "member_id": "MEM001234",
    "provider_npi": "1234567890",
    "service_date": "2025-01-15",
    "place_of_service": "11",
    "principal_diagnosis": "I10",
    "claim_lines": [
      {
        "line_number": 1,
        "procedure_code": "99214",
        "charge_amount": 175.00,
        "units": 1,
        "diagnosis_pointers": [1]
      }
    ]
  },
  "adjudication": {
    "status": "paid",
    "allowed_amount": 125.00,
    "deductible": 0.00,
    "copay": 25.00,
    "coinsurance": 0.00,
    "paid_amount": 100.00,
    "patient_responsibility": 25.00
  }
}

Example 2: Denied Claim (Prior Auth Required)

Request: "Generate a denied claim for MRI without prior authorization"

{
  "claim": {
    "claim_id": "CLM20250115000002",
    "claim_type": "PROFESSIONAL",
    "service_date": "2025-01-15",
    "place_of_service": "22",
    "principal_diagnosis": "M54.5",
    "claim_lines": [
      {
        "line_number": 1,
        "procedure_code": "72148",
        "charge_amount": 1500.00,
        "units": 1
      }
    ]
  },
  "adjudication": {
    "status": "denied",
    "denial_reason": "CO-15",
    "denial_message": "Prior authorization required",
    "allowed_amount": 0.00,
    "paid_amount": 0.00
  }
}

See claim-examples.md for additional examples: partial payment with deductible application, oncology infusion claims, OON emergency, and telehealth visits.

Related Skills

MemberSim Cohorts

  • plan-benefits.md - Plan configuration and benefit structure
  • enrollment-eligibility.md - Enrollment and eligibility
  • professional-claims.md - Professional claim details
  • facility-claims.md - Institutional claim details
  • prior-authorization.md - PA workflows (includes oncology PAs)
  • accumulator-tracking.md - Cost sharing tracking
  • value-based-care.md - VBC, HEDIS, risk adjustment

Cross-Product: PatientSim (Clinical)

MemberSim claims correspond to PatientSim clinical encounters:

MemberSim SkillPatientSim CohortsIntegration
professional-claims.mdOffice visits, consultsMatch E&M codes to encounter complexity
facility-claims.mdInpatient, ED, surgeryMatch DRG to admission diagnoses
prior-authorization.mdElective proceduresPA approved → procedure scheduled
behavioral-health.mdPsychiatric careMatch visit types and diagnoses

PatientSim Cohort Links:

  • ../patientsim/heart-failure.md - HF admission claims
  • ../patientsim/diabetes-management.md - Diabetes office visit claims
  • ../patientsim/elective-joint.md - Surgical episode claims
  • ../patientsim/oncology/ - Oncology infusion claims
  • ../patientsim/behavioral-health.md - Behavioral health claims

Integration Pattern: Generate clinical encounter in PatientSim first, then use MemberSim to create corresponding claims with matching service dates, diagnosis codes, and procedures.

Cross-Product: RxMemberSim (Pharmacy)

Medical and pharmacy benefits are often coordinated:

MemberSim SkillRxMemberSim SkillIntegration
plan-benefits.mdformulary-management.mdCoordinated benefit design
accumulator-tracking.mdrx-accumulator.mdCombined deductible/OOP
prior-authorization.mdrx-prior-auth.mdMedical vs. pharmacy PA
enrollment-eligibility.mdrx-enrollment.mdSynchronized coverage

Integration Pattern: For integrated medical+Rx benefits, ensure accumulators are synchronized and coverage dates match. Some specialty drugs are covered under medical benefit (infused) vs. pharmacy benefit (oral).

Cross-Product: PopulationSim (Demographics & SDOH)

PopulationSim provides real-world reference data (CDC PLACES, SVI, ADI) for actuarially realistic member generation. When geography is specified, look up actual prevalence rates and demographics to ground synthetic member panels.

Pattern: (1) Look up county/tract data by FIPS code, (2) apply prevalence rates to member generation, (3) include data provenance in output.

SourceTableUse in MemberSim
CDC PLACES Countypopulation.places_county (via healthsim_query_reference)Utilization rates, risk adjustment
SVI Countypopulation.svi_county (via healthsim_query_reference)SDOH factors, plan selection
ADI Block Grouppopulation.adi_blockgroup (via healthsim_query_reference)Deprivation-based adherence
PopulationSim SkillMemberSim Application
data-lookup.mdPrevalence rates for risk adjustment
county-profile.mdService area demographics
svi-analysis.mdSocial vulnerability → plan tier, adherence
adi-analysis.mdArea deprivation → utilization patterns

Key Principle: When geography is specified, always ground member generation in real PopulationSim data for actuarially realistic synthetic panels.

Cross-Product: NetworkSim (Provider Networks)

NetworkSim provides network context for claims processing:

MemberSim NeedNetworkSim SkillIntegration
Provider network statusnetwork-for-member.mdIn-network vs OON determination
Benefit cost sharingbenefit-for-claim.mdCopay, coinsurance, deductible
Network configurationsynthetic-network.mdHMO/PPO/tiered structure

Integration Pattern: Use NetworkSim to determine network status before adjudicating claims. Network type (HMO/PPO) affects whether out-of-network claims are covered and at what cost share.

Cross-Product: TrialSim (Clinical Trials)

Members may participate in clinical trials with claims integration:

MemberSim ContextTrialSim IntegrationClaims Impact
Specialty drug coverageTrial drug provided freeReduced Rx claims during trial
Standard of careSOC claims continueNormal claim adjudication
Trial-related AEsMay generate medical claimsAE → ED/inpatient claims

Integration Pattern: When a member enrolls in a trial, standard of care claims continue through MemberSim while trial-specific treatments are tracked in TrialSim. Trial-related adverse events may generate claims.

Output Formats

  • ../../formats/x12-834.md - X12 enrollment format
  • ../../formats/x12-270-271.md - X12 eligibility format
  • ../../formats/x12-837.md - X12 claim format
  • ../../formats/x12-835.md - Remittance format
  • ../../formats/csv.md - CSV export
  • ../../formats/sql.md - SQL export

Reference Data

  • ../../references/data-models.md - Entity schemas
  • ../../references/oncology/ - Oncology codes, medications, regimens

Generative Framework Integration

MemberSim integrates with the Generative Framework for specification-driven generation at scale.

Profile-Driven Generation

Use profile specifications to generate member populations:

"Use the commercial healthy profile to generate 500 members"

The Profile Executor will:

  1. Sample demographics from profile distributions
  2. Generate coverage attributes (plan type, benefits)
  3. Create accumulator records
  4. Link to NetworkSim providers for PCP assignment

Journey-Driven Generation

Attach journey specifications to create claims over time:

"Add the new member onboarding journey to each member"

The Journey Executor will:

  1. Generate enrollment events
  2. Create initial utilization claims
  3. Track accumulator progression
  4. Apply branching for engagement patterns

Cross-Domain Sync

When generating across products, MemberSim entities are automatically linked:

MemberSim EntityLinks To
MemberPatientSim Patient (via SSN)
ClaimPatientSim Encounter
AuthorizationPatientSim Referral
Rx ClaimRxMemberSim Fill

See: ../generation/executors/cross-domain-sync.md

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.