Healthcare payers

Claims logic you can see: edits, pricing and EDI, extracted.

Front-end edits, adjudication rules, fee schedule pricing and the X12 837 and 835 handling around them are spread across COBOL batch, CICS screens and stored procedures. PYD ENTERPRISES maps each to a decision table, a calculation spec or a JSON Schema with its source lines.

Request a codebase scan Book technical walkthrough

837P loop map → parsing paragraphs

8 of 8 mapped

ISA / GS / STinterchange, group, transaction set 837CLMEDI01 1100
└ Loop 1000A / 1000Bsubmitter, receiverCLMEDI01 1500
└ Loop 2000A HL (20)billing providerCLMEDI01 2000
└ Loop 2000B HL (22)subscriber, payerCLMEDI01 2050
└ Loop 2300 CLMclaim: CLM01, CLM02, CLM05 compositeCLMEDI01 2200
└ HIdiagnosis codes (ICD-10-CM)CLMEDI01 2400
└ Loop 2400 LX / SV1service lines, procedure and modifiersCLMEDI01 2300
SE / GE / IEAtrailers and control countsCLMEDI01 9000

Payer logic, extracted

Parsing, edits and pricing, side by side with the code.

Three routines from a payer claims estate: an 837 segment parser, front-end adjudication edits mapped to 835 adjustment reasons, and a lesser-of pricing rule.

CLMEDI01.cblCLMEDI01.cbl:1450-1468

1       2200-PARSE-SEGMENT.
2           UNSTRING EDI-RECORD DELIMITED BY '*' OR '~'
3               INTO WS-SEG-ID
4                    WS-EL (1) WS-EL (2) WS-EL (3)
5                    WS-EL (4) WS-EL (5)
6           END-UNSTRING
7           EVALUATE WS-SEG-ID
8               WHEN 'CLM'
9                   MOVE WS-EL (1) TO CL-PATIENT-CTL-NO
10                   MOVE WS-EL (2) TO WS-CHARGE-TXT
11                   MOVE WS-EL (5) TO WS-CLM05
12                   PERFORM 2210-SPLIT-CLM05
13               WHEN 'SV1'
14                   PERFORM 2300-PROF-SERVICE-LINE
15               WHEN 'HI'
16                   PERFORM 2400-DIAGNOSIS-CODES
17               WHEN OTHER
18                   CONTINUE
19           END-EVALUATE.

JSON Schema 2020-12 · Claim (loop 2300)

1{
2  "$id": "claim.schema.json",
3  "type": "object",
4  "required": ["patientControlNumber", "totalCharge", "facilityCode", "frequencyCode"],
5  "properties": {
6    "patientControlNumber": { "type": "string", "maxLength": 38, "x-source": "CLM01" },
7    "totalCharge": { "type": "string", "pattern": "^\\d{1,16}(\\.\\d{1,2})?$", "x-source": "CLM02" },
8    "facilityCode": { "type": "string", "maxLength": 2, "x-source": "CLM05-1" },
9    "frequencyCode": { "type": "string", "maxLength": 1, "x-source": "CLM05-3" }
10  }
11}

source: CLMEDI01.cbl:1450-1468

defectElement and segment separators hard-coded as '*' and '~' instead of read from ISA; files from one clearinghouse use '|'
resolvedCLM05 split on ':' in 2210: facility code, qualifier and frequency type extracted as three fields
reviewOnly 5 elements are captured: CLM06 onward (provider signature, assignment) are dropped

Where claims logic hides

One claim, five codebases.

A professional claim arriving as an X12 837 passes through more code than most payers can list. A translator or hand-written COBOL parser splits segments and composites. Front-end edits reject or pend on timely filing, duplicates, eligibility and authorization. Adjudication applies benefit rules, accumulators and coordination of benefits. Pricing applies fee schedules, contract terms and modifier adjustments. A remittance program writes the 835 with the adjustment reason codes the provider sees.

Each step was built and changed at a different time, often by different teams, and the internal edit codes in one program have to line up with the CARC values written by another. PYD ENTERPRISES builds one symbol graph across all of it, so a single rule (for example, deny a late claim with CARC 29) shows up as one row with every program that participates in it.

The output does not replace your clinical or payment policy teams. It gives them a list they can check: which edits exist, in what order they fire, which tables they read and which adjustment codes they produce.

A payer engagement

From claim intake to remittance, in order.

01Map the EDI boundary837 and 835 handling, translator exits and hand-written parsers mapped to loops, segments and elements, exported as JSON Schema 2020-12.Week 1
02Extract edits and adjudication rulesTimely filing, duplicate, eligibility, authorization and benefit rules as DMN tables in firing order.Week 1 to 2
03Extract pricingFee schedule lookups, lesser-of logic, modifiers and contract overrides as calculation specs with the tables they read.Week 2
04Review with payment policy and configuration teamsConfirm each rule beside its source, resolve flagged paths and mark rules to keep, change or retire.Week 2 to 3

FAQ

Questions from payer IT.

Does PYD ENTERPRISES read claims or member data?

No. It reads source code, copybooks, JCL and DDL inside your environment. It does not need access to production claims, member or provider data, and equivalence fixtures are synthesized from branch conditions rather than copied from PHI.

Can it follow EDI parsing written in COBOL rather than a translator?

Yes. Many payers parse X12 in hand-written COBOL or in exits around a commercial translator. PYD ENTERPRISES maps UNSTRING and reference modification logic to the segments and elements it handles, and emits JSON Schemas annotated with the X12 element each field comes from.

How are edit codes connected to 835 adjustment reasons?

When the 835 writer is in scope, PYD ENTERPRISES traces internal edit and denial codes to the claim adjustment reason codes (CARC) and remittance remark codes the remittance program writes, so the decision table shows both.

What about pricing in PL/SQL or DB2 stored procedures?

Fee schedule lookups, lesser-of logic, modifier adjustments and contract-specific pricing are extracted from COBOL, PL/SQL and T-SQL alike, with the tables they read exported as data inputs.

Will this replace our claims vendor's configuration work?

No. If you are moving to a commercial claims platform, the extracted rules are the requirement for its configuration and the fixtures are its acceptance tests. The configuration itself is done in that platform.

Go deeper

See your claims logic as rules, not paragraphs.

Start a 14-day trial on up to 100,000 lines of claims code in your own VPC, or scope a Discovery Scan for one system.

Start 14-day trial Request a codebase scan