Case Study 2: Pinnacle Health's HIPAA Compliance for CICS Claims Processing

Case Study 2: Pinnacle Health's HIPAA Compliance for CICS Claims Processing

Background

Pinnacle Health Systems is a regional health insurance provider processing 1.8 million claims per year through a CICS-based claims adjudication system. The system has been in production since 1997 and has grown organically — new transactions and files added over 25 years with minimal security architecture review.

Diane Morrison, the CIO, received a letter from the Office for Civil Rights (OCR) notifying Pinnacle of a HIPAA compliance audit triggered by a complaint from a former employee. The complaint alleged that claims processors had unrestricted access to patient clinical data that was not necessary for their job function — a potential violation of HIPAA's "minimum necessary" rule (45 CFR §164.502(b)).

Ahmad Rashid, the lead CICS systems programmer, was assigned to assess the current security posture and remediate any findings before the OCR audit team arrived in 90 days.

The Current State Assessment

Ahmad spent the first two weeks conducting a thorough assessment. His findings were sobering.

Assessment Finding 1: No Field-Level Access Control

The CICS claims system has a single transaction — CLMS — used by all claims staff. The transaction displays a comprehensive claims screen that includes:

Billing data: Procedure codes, billing amounts, provider information, payment status
Clinical data: Diagnosis codes (ICD-10), treatment notes, physician orders, lab results
Patient demographics: Name, address, SSN, date of birth, phone number, emergency contact
Financial data: Copay, deductible, out-of-pocket maximum, explanation of benefits

Every user who can execute the CLMS transaction sees every field. Claims processors who only need billing data can see clinical records. Billing specialists who only need financial data can see clinical notes. There is no field-level restriction.

Ahmad's assessment: "The CLMS transaction was written in 1997 as a single monolithic BMS map with all 47 fields displayed to every user. The original developers didn't differentiate between user roles because in 1997, there were 12 users and everyone did everything. Now we have 380 users in six different job functions, and they all see the same screen."

Assessment Finding 2: No Resource-Level Security for PHI Files

The CICS SIT has XFCT=NO. The claims system uses eight VSAM files, four of which contain Protected Health Information (PHI):

File	Contents	PHI?	Current Security
CLMSMAST	Claims header records	Yes (diagnosis codes)	None
CLMSDETL	Claims detail/line items	Yes (procedure details)	None
CLMSCLIN	Clinical review records	Yes (treatment notes)	None
CLMSDEMO	Patient demographics	Yes (SSN, DOB)	None
CLMSPROV	Provider directory	No	None
CLMSCODE	Procedure code reference	No	None
CLMSRATE	Fee schedule	No	None
CLMSAUDT	Audit records	No	None

Ahmad's assessment: "Any CICS transaction in the region can open any of these files. We have a report-generation transaction (RPTG) used by the analytics team that reads CLMSCLIN to generate utilization reports. The analytics team has no clinical justification for accessing individual treatment notes — they only need aggregate data."

Assessment Finding 3: Shared Userids for External Access

Pinnacle's provider portal allows healthcare providers to check claims status online. The portal connects to CICS through a web service using a single shared userid: PROVIDER. All provider inquiries run under this userid. The audit trail shows 500,000 transactions per year attributed to "PROVIDER" — with no way to determine which of the 4,200 provider organizations made which inquiry.

Assessment Finding 4: Inadequate Audit Trail

The only audit mechanism is SMF 110 transaction performance records. No RACF auditing, no CICS journaling, and no application-level audit trail. When the former employee filed the complaint, Pinnacle could not provide evidence of who accessed which patient records, when, or why.

Diane's reaction: "We can tell the OCR auditor how many transactions we processed last month. We cannot tell them whether any specific employee accessed any specific patient's records. That's not just a compliance gap — it's a fundamental failure of our duty to protect patient privacy."

The Remediation Architecture

Ahmad designed a comprehensive remediation plan with three workstreams: field-level security, resource-level security, and audit trail implementation.

Workstream 1: Field-Level Security (The Minimum Necessary Rule)

The minimum necessary rule requires that access to PHI be limited to the minimum information necessary for the user's job function. For the CLMS transaction, this meant different users should see different fields on the same screen.

Ahmad designed a role-based field display architecture:

Role 1 — Claims Processor: - Can see: Procedure codes, billing amounts, payment status, provider info, patient name - Cannot see: Diagnosis codes, treatment notes, lab results, SSN (masked to last 4)

Role 2 — Clinical Reviewer: - Can see: Diagnosis codes, treatment notes, physician orders, lab results, patient name - Cannot see: Billing amounts, payment status, SSN (masked to last 4)

Role 3 — Billing Specialist: - Can see: Billing amounts, copay, deductible, OOP max, EOB, patient name, address - Cannot see: Diagnosis codes, treatment notes, lab results

Role 4 — Privacy Officer: - Can see: All fields (full access for investigations) - All access is logged with AUDIT(ALL)

Role 5 — Auditor: - Can see: All fields (read-only) - Cannot modify any records - All access is logged with AUDIT(ALL)

Role 6 — Provider (external): - Can see: Claims status, payment amounts, patient name only - Cannot see: Clinical data, SSN, other patient demographics

The implementation required three changes:

Change 1: RACF resource profiles for role checking

Ahmad defined custom RACF resource profiles that the COBOL program queries at runtime to determine the user's role:

* Define role-indicator resources in a custom RACF class
* (Using FACILITY class as a general-purpose class)
RDEFINE FACILITY PINN.CICS.ROLE.CLMSPROC UACC(NONE)
PERMIT PINN.CICS.ROLE.CLMSPROC CLASS(FACILITY) ID(PNCLMP) ACCESS(READ)

RDEFINE FACILITY PINN.CICS.ROLE.CLINREV UACC(NONE)
PERMIT PINN.CICS.ROLE.CLINREV CLASS(FACILITY) ID(PNCLNR) ACCESS(READ)

RDEFINE FACILITY PINN.CICS.ROLE.BILLING UACC(NONE)
PERMIT PINN.CICS.ROLE.BILLING CLASS(FACILITY) ID(PNBILL) ACCESS(READ)

RDEFINE FACILITY PINN.CICS.ROLE.PRIVACY UACC(NONE)
PERMIT PINN.CICS.ROLE.PRIVACY CLASS(FACILITY) ID(PNPRIV) ACCESS(READ)

RDEFINE FACILITY PINN.CICS.ROLE.AUDITOR UACC(NONE)
PERMIT PINN.CICS.ROLE.AUDITOR CLASS(FACILITY) ID(PNAUDT) ACCESS(READ)

Change 2: COBOL role-detection logic

Ahmad modified the CLMS transaction program to check the user's role at initialization:

       WORKING-STORAGE SECTION.
       01  WS-USER-ROLE          PIC X(10).
           88  ROLE-CLAIMS-PROC  VALUE 'CLMSPROC'.
           88  ROLE-CLIN-REVIEW  VALUE 'CLINREV'.
           88  ROLE-BILLING      VALUE 'BILLING'.
           88  ROLE-PRIVACY      VALUE 'PRIVACY'.
           88  ROLE-AUDITOR      VALUE 'AUDITOR'.
           88  ROLE-PROVIDER     VALUE 'PROVIDER'.
           88  ROLE-UNKNOWN      VALUE 'UNKNOWN'.

       01  WS-SEC-RESP           PIC S9(8) COMP.
       01  WS-SEC-RESP2          PIC S9(8) COMP.

       PROCEDURE DIVISION.

       DETERMINE-USER-ROLE.
      * Check each role in priority order
           EXEC CICS QUERY SECURITY
               RESTYPE('FACILITY')
               RESID('PINN.CICS.ROLE.PRIVACY')
               RESIDLENGTH(24)
               LOGMESSAGE(NOLOG)
               RESP(WS-SEC-RESP)
           END-EXEC
           IF WS-SEC-RESP = DFHRESP(NORMAL)
               SET ROLE-PRIVACY TO TRUE
               GO TO ROLE-DETERMINED
           END-IF

           EXEC CICS QUERY SECURITY
               RESTYPE('FACILITY')
               RESID('PINN.CICS.ROLE.AUDITOR')
               RESIDLENGTH(24)
               LOGMESSAGE(NOLOG)
               RESP(WS-SEC-RESP)
           END-EXEC
           IF WS-SEC-RESP = DFHRESP(NORMAL)
               SET ROLE-AUDITOR TO TRUE
               GO TO ROLE-DETERMINED
           END-IF

           EXEC CICS QUERY SECURITY
               RESTYPE('FACILITY')
               RESID('PINN.CICS.ROLE.CLINREV')
               RESIDLENGTH(24)
               LOGMESSAGE(NOLOG)
               RESP(WS-SEC-RESP)
           END-EXEC
           IF WS-SEC-RESP = DFHRESP(NORMAL)
               SET ROLE-CLIN-REVIEW TO TRUE
               GO TO ROLE-DETERMINED
           END-IF

           EXEC CICS QUERY SECURITY
               RESTYPE('FACILITY')
               RESID('PINN.CICS.ROLE.BILLING')
               RESIDLENGTH(24)
               LOGMESSAGE(NOLOG)
               RESP(WS-SEC-RESP)
           END-EXEC
           IF WS-SEC-RESP = DFHRESP(NORMAL)
               SET ROLE-BILLING TO TRUE
               GO TO ROLE-DETERMINED
           END-IF

           EXEC CICS QUERY SECURITY
               RESTYPE('FACILITY')
               RESID('PINN.CICS.ROLE.CLMSPROC')
               RESIDLENGTH(24)
               LOGMESSAGE(NOLOG)
               RESP(WS-SEC-RESP)
           END-EXEC
           IF WS-SEC-RESP = DFHRESP(NORMAL)
               SET ROLE-CLAIMS-PROC TO TRUE
               GO TO ROLE-DETERMINED
           END-IF

      * No role matched - deny access
           SET ROLE-UNKNOWN TO TRUE
           EXEC CICS SEND TEXT
               FROM(WS-ACCESS-DENIED-MSG)
               LENGTH(40)
               ERASE
           END-EXEC
           EXEC CICS RETURN END-EXEC
           .

       ROLE-DETERMINED.
           PERFORM BUILD-SCREEN-BY-ROLE
           .

Change 3: BMS map restructuring

Rather than a single monolithic BMS map, Ahmad created a base map with common fields and role-specific overlay maps:

CLMSBASE — Base map: patient name, claim number, status
CLMSBILL — Billing overlay: procedure codes, amounts, payments
CLMSCLIN — Clinical overlay: diagnosis, treatment, labs
CLMSDEMO — Demographics overlay: address, SSN, DOB
CLMSFINL — Financial overlay: copay, deductible, EOB

Each role sends the base map plus the appropriate overlays:

       BUILD-SCREEN-BY-ROLE.
           PERFORM SEND-BASE-MAP

           EVALUATE TRUE
               WHEN ROLE-CLAIMS-PROC
                   PERFORM SEND-BILLING-OVERLAY
               WHEN ROLE-CLIN-REVIEW
                   PERFORM SEND-CLINICAL-OVERLAY
               WHEN ROLE-BILLING
                   PERFORM SEND-BILLING-OVERLAY
                   PERFORM SEND-FINANCIAL-OVERLAY
               WHEN ROLE-PRIVACY
                   PERFORM SEND-ALL-OVERLAYS
               WHEN ROLE-AUDITOR
                   PERFORM SEND-ALL-OVERLAYS
               WHEN ROLE-PROVIDER
                   PERFORM SEND-PROVIDER-VIEW
           END-EVALUATE
           .

This approach means a claims processor physically cannot see clinical data — the BMS map fields aren't sent to their terminal. It's not just hidden with ASKIP/DARK attributes (which could be bypassed with a terminal emulator); the data is never transmitted.

Workstream 2: Resource-Level Security

Ahmad enabled file-level security (XFCT=YES) and defined profiles that enforced access by role:

* Clinical files - clinical reviewers and privacy officers only
RDEFINE FCICSFCT PINNPROD.CLMSCLIN UACC(NONE) AUDIT(ALL)
PERMIT PINNPROD.CLMSCLIN CLASS(FCICSFCT) ID(PNCLNR) ACCESS(READ)
PERMIT PINNPROD.CLMSCLIN CLASS(FCICSFCT) ID(PNPRIV) ACCESS(READ)
PERMIT PINNPROD.CLMSCLIN CLASS(FCICSFCT) ID(PNAUDT) ACCESS(READ)

* Demographics file - restricted, SSN data
RDEFINE FCICSFCT PINNPROD.CLMSDEMO UACC(NONE) AUDIT(ALL)
PERMIT PINNPROD.CLMSDEMO CLASS(FCICSFCT) ID(PNBILL) ACCESS(READ)
PERMIT PINNPROD.CLMSDEMO CLASS(FCICSFCT) ID(PNPRIV) ACCESS(UPDATE)
PERMIT PINNPROD.CLMSDEMO CLASS(FCICSFCT) ID(PNAUDT) ACCESS(READ)

* Claims master - all claims roles can read
RDEFINE FCICSFCT PINNPROD.CLMSMAST UACC(NONE) AUDIT(FAILURES)
PERMIT PINNPROD.CLMSMAST CLASS(FCICSFCT) ID(PNCLMP) ACCESS(UPDATE)
PERMIT PINNPROD.CLMSMAST CLASS(FCICSFCT) ID(PNCLNR) ACCESS(READ)
PERMIT PINNPROD.CLMSMAST CLASS(FCICSFCT) ID(PNBILL) ACCESS(READ)
PERMIT PINNPROD.CLMSMAST CLASS(FCICSFCT) ID(PNPRIV) ACCESS(UPDATE)
PERMIT PINNPROD.CLMSMAST CLASS(FCICSFCT) ID(PNAUDT) ACCESS(READ)

The key decision: AUDIT(ALL) on files containing clinical data (CLMSCLIN, CLMSDEMO) and AUDIT(FAILURES) on less sensitive files. Every access to clinical data generates a RACF audit record — successful or not. This provides the evidence trail OCR requires.

Workstream 3: Audit Trail and Provider Portal Security

Application-level audit logging:

Ahmad implemented a PHI access audit program that every claims transaction calls:

       01  WS-PHI-AUDIT-REC.
           05  PHI-AUD-TIMESTAMP     PIC X(16).
           05  PHI-AUD-USERID        PIC X(08).
           05  PHI-AUD-TERMINAL      PIC X(04).
           05  PHI-AUD-TRANID        PIC X(04).
           05  PHI-AUD-ACTION        PIC X(08).
               88  PHI-VIEW          VALUE 'VIEW    '.
               88  PHI-UPDATE        VALUE 'UPDATE  '.
               88  PHI-PRINT         VALUE 'PRINT   '.
           05  PHI-AUD-PATIENT-ID    PIC X(12).
           05  PHI-AUD-CLAIM-NUM     PIC X(15).
           05  PHI-AUD-DATA-TYPES    PIC X(30).
           05  PHI-AUD-ROLE          PIC X(10).
           05  PHI-AUD-REASON        PIC X(50).

The PHI-AUD-DATA-TYPES field records exactly which categories of PHI the user accessed: "BILLING", "CLINICAL", "DEMOGRAPHICS", or combinations thereof. This allows Pinnacle to answer the OCR auditor's question: "Show me every instance where user X accessed patient Y's clinical records."

The PHI-AUD-REASON field is populated for certain access types. When a privacy officer accesses a record (which gives them full access), the system prompts for a reason code — "INVESTIGATION", "COMPLAINT RESPONSE", "BREACH ASSESSMENT", etc. This supports the HIPAA requirement for documentation of access by those with elevated privileges.

Provider portal surrogate processing:

Ahmad implemented surrogate user processing for the provider portal:

* Define provider-specific RACF groups
ADDGROUP PNPROV OWNER(SECADMIN) SUPGROUP(PNGRPS)

* Each provider organization gets a unique userid
ADDUSER PROV0001 DFLTGRP(PNPROV) NAME('MERCY GENERAL HOSPITAL')
ADDUSER PROV0002 DFLTGRP(PNPROV) NAME('DR PATEL FAMILY MEDICINE')
... (4,200 provider userids)

* Surrogate authority for the portal service userid
RDEFINE SURROGAT PROV*.DFHSTART UACC(NONE)
PERMIT PROV*.DFHSTART CLASS(SURROGAT) ID(PORTLSVC) ACCESS(READ)

Now each provider inquiry is attributed to the specific provider organization. The audit trail shows "PROV0001 (Mercy General Hospital) inquired on claim 2024-1234567" rather than "PROVIDER inquired on claim 2024-1234567."

Ahmad also restricted provider access at the file level — providers can only read claim status from CLMSMAST; they have no access to CLMSCLIN, CLMSDEMO, or any other PHI file:

PERMIT PINNPROD.CLMSMAST CLASS(FCICSFCT) ID(PNPROV) ACCESS(READ)
* No PERMIT for CLMSCLIN, CLMSDEMO — providers are denied by UACC(NONE)

The OCR Audit

The OCR audit team conducted a three-day on-site review. Their assessment focused on:

Technical Testing

The OCR team tested field-level access by logging in as test users in each role and verifying that: - A claims processor could not see diagnosis codes or treatment notes — VERIFIED - A clinical reviewer could not see billing amounts or payment status — VERIFIED - A billing specialist could not see clinical data — VERIFIED - The provider portal showed only claim status information — VERIFIED

They tested resource-level security by attempting to read clinical files from a claims processor's session — the access was denied with a NOTAUTH response. The RACF audit log captured the denied attempt. VERIFIED.

Audit Trail Review

The OCR team requested: - All access to a specific patient's records over the past 90 days — Ahmad produced the report from the PHI audit journal within 20 minutes - All clinical data access by a specific user over the past 30 days — produced in 15 minutes - All privacy officer access with reason codes for the past quarter — produced in 10 minutes

The OCR team was satisfied that the audit trail could reconstruct who accessed what PHI, when, and for what purpose.

Policy and Procedure Review

The OCR team reviewed: - The role-to-group mapping documentation - The quarterly access review process - The CICS security architecture document - The incident response plan for PHI breaches

Outcome

The OCR closed the complaint investigation with no enforcement action. Their report noted:

"Pinnacle Health Systems has implemented appropriate technical safeguards including role-based access controls with field-level restrictions, resource-level security using RACF, and comprehensive audit logging. The current security architecture enforces the minimum necessary standard for PHI access. While the previous configuration described in the complaint did not adequately restrict access to PHI, the current implementation addresses the identified concerns."

Ahmad's summary to Diane: "We passed. But we should have been doing this from the beginning. We were one disgruntled employee complaint away from a much worse outcome for 25 years."

Discussion Questions

Technical Architecture: Ahmad chose to implement field-level security in the COBOL application using EXEC CICS QUERY SECURITY calls. An alternative would have been to split the CLMS transaction into multiple role-specific transactions (CLMP for claims processors, CLMR for clinical reviewers, etc.). Compare the two approaches in terms of maintenance burden, security strength, and user experience.
The Minimum Necessary Challenge: HIPAA's minimum necessary rule is conceptually simple but operationally complex. How do you determine "minimum necessary" for a claims processor who occasionally needs to see a diagnosis code to resolve a billing dispute? Design a "break-the-glass" mechanism that allows temporary elevated access with appropriate logging.
Provider Identification: Ahmad created 4,200 individual provider userids to enable audit trail attribution. An alternative would be to use a single provider userid with application-level user tracking. Discuss the security and compliance tradeoffs of each approach.
Legacy System Challenge: This system had been running for 25 years with essentially no security. What organizational factors typically allow this to happen, and what governance structures would have prevented it?
Cost of Compliance: The remediation effort took 90 days with two full-time staff (Ahmad plus a junior programmer). The provider portal change required a 4-hour maintenance window on a Saturday night. Compare this cost to the potential cost of an OCR enforcement action, which can range from $100,000 to $1.9 million per violation category.
Field-Level Security Limitations: The BMS overlay approach means different roles see different screens for the same claim. A claims processor investigating a billing issue might need the diagnosis code context. A clinical reviewer might need the billing amount to understand the financial impact of a treatment decision. How do you balance minimum necessary access against operational efficiency?
Audit Volume Management: With AUDIT(ALL) on clinical files and PHI journal records for every access, Pinnacle now generates significantly more audit data. At 1.8 million claims per year with an average of 6 accesses per claim, that's 10.8 million audit records annually. Design a strategy for managing this volume while keeping records accessible for OCR requests.