Fractional CAIO in Upland, CA

Healthcare billing infrastructure as the foundation for AI advisory

This page is built on a real engagement: I designed and built the complete healthcare billing software application for HBSGI, a healthcare benefits company headquartered in Upland, CA. The application covered BizTalk EDI integration, HIPAA ANSI X12 transaction handling — 837 claim submission, 835 electronic remittance advice, 997 functional acknowledgment — and the full billing workflow from claim creation through payer payment and reconciliation.

To be direct about the nature of that work: it was billing infrastructure, not an AI engagement. I did not lead AI initiatives at HBSGI.

What that engagement provides is something more valuable for AI advisory in healthcare: first-hand knowledge of how healthcare billing data is structured, how it flows across systems, and what the business rules look like at the transaction level. The input layer for claims denial prediction models is an 837 transaction set. The data that remittance reconciliation AI processes is the 835. The acknowledgment workflow that determines whether a submitted claim even reached its destination is the 997. Having built the systems that produce and consume those transactions — not read about them, but designed and shipped production code for them — is a different starting point than approaching healthcare AI from a market overview.

The G4S parolee monitoring engagement provides an analogy. That work — designing offender monitoring technology where errors have serious real-world consequences — gives a specific, grounded perspective on AI in high-stakes operational contexts. The HBSGI engagement plays the same role for healthcare AI: inside knowledge of how the underlying systems work is what makes the AI advisory specific rather than generic.

Healthcare AI use cases this background directly informs

Claims denial prediction. Payers reject claims for predictable reasons: missing prior authorization, incorrect procedure-diagnosis code pairing, provider credentialing gaps, policy-period mismatches. ML models trained on historical claims submissions and payer adjudication outcomes can flag likely-to-deny claims before EDI submission, allowing correction before the claim enters the payer’s adjudication pipeline. The input data for these models is structured 837 transaction data — the exact format the HBSGI billing application produces. Understanding that data architecture from the inside is the starting point for designing a denial prediction system that actually works.

Automated claims scrubbing. Before an 837 transaction reaches a payer or clearinghouse, it can be validated against payer-specific rules, clinical code pairing requirements, and HIPAA transaction set requirements. AI-assisted scrubbing extends that validation: identifying billing errors, missing required fields, and payer rule violations that deterministic rule engines miss. The scrubbing logic is applied to the same transaction structure — and the nuances of that structure are directly familiar from the HBSGI build.

Remittance reconciliation. The 835 remittance advice that a payer returns does not always map cleanly to the 837 claims that generated it. Partial payments, claim splits, adjustment codes, and payer-specific line item behavior make automated reconciliation non-trivial. ML-assisted reconciliation — matching 835 records to submitted 837 claims, identifying payment discrepancies, and flagging exceptions for human review — addresses a category of labor that is among the largest cost items in billing operations. Having built both the 837 submission and 835 processing sides of that workflow is the relevant background.

Prior authorization automation. LLM-assisted extraction and routing of prior authorization requests — pulling clinical criteria from payer coverage policies, matching them against submitted clinical documentation, and routing routine approvals without manual review — is one of the most impactful AI applications in healthcare administration. Prior auth delays affect patient care and create significant administrative cost; the AI application is well-established and the architecture is tractable.

Clinical documentation AI. Ambient AI that captures and structures clinical encounters, or LLMs that extract structured billing codes from clinical notes, reduces documentation burden on clinicians and reduces billing errors at the source — before the claim is ever created. This is the upstream end of the billing workflow the HBSGI application handles downstream.

The payer-side context: WellPoint and PacifiCare

The HBSGI work covers the provider side of the claims transaction. An 837 is submitted by a provider; it is received, adjudicated, and responded to by a payer. Understanding AI strategy in healthcare billing benefits from knowing both sides of that transaction.

Prior to the HBSGI engagement, I led enterprise architecture work with WellPoint (Fortune 500 #204 at the time, health insurance) and PacifiCare Health Systems (Fortune 500 #169, HMO). Those engagements were on the payer side — working within the systems that receive claims, apply benefit rules, determine coverage, and generate remittance. That means understanding not just how an 837 is formatted and submitted, but how a large payer processes it once it arrives: the adjudication logic, the payment determination, and the 835 that comes back.

For AI advisory in healthcare, that dual-side context matters: claims denial prediction requires understanding how payers evaluate claims; remittance reconciliation AI requires understanding how payers generate 835 records. Having worked on both sides of the transaction is an unusual foundation for this kind of advisory.

AI governance for healthcare data

Healthcare AI governance is not a standard AI governance framework with a compliance checklist added. PHI creates specific, legally enforceable constraints that must be designed into the system architecture from the start.

The minimum necessary standard. HIPAA limits the use of PHI to the minimum necessary for the stated purpose. A claims denial prediction model that consumes full patient records when it only needs procedure codes, diagnosis codes, and payer identifiers is not compliant. Data minimization is a design requirement, not a preference.

De-identification for training data. Training ML models on claims data requires de-identified training sets. HIPAA defines two acceptable de-identification methods: the Safe Harbor method (removing 18 specific identifier categories) and the Expert Determination method (statistical certification by a qualified expert). Neither is trivial to implement correctly, and using non-de-identified PHI in model training creates significant liability.

Private LLM deployment. Public LLM APIs — including major commercial providers — are not appropriate for PHI. Sending claims data, patient records, or remittance information to a third-party LLM endpoint requires a HIPAA Business Associate Agreement, and even with a BAA in place, most healthcare legal teams are not comfortable with PHI leaving the organization’s controlled infrastructure. Private LLM deployment — on the organization’s own infrastructure or within a HIPAA-eligible cloud environment with appropriate controls — is the correct architecture for healthcare AI. Designing this from the beginning is substantially less expensive than retrofitting compliance after models are in production.

What a Fractional CAIO delivers for an Upland or Inland Empire firm

The highest-value deliverables for most Inland Empire healthcare and benefits companies:

1. AI readiness assessment — a systematic audit of your current platform, data architecture, and governance posture relative to the AI capabilities you’re considering. For healthcare companies, this includes PHI data mapping and regulatory constraint identification.
2. Claims AI use-case roadmap — prioritized AI use cases for your specific claims and billing workflow, with LLM and ML architecture recommendations and ROI estimates based on actual claims data structures.
3. PHI data governance framework — policy and architecture design for PHI use in AI systems: data minimization, de-identification for training, access controls, and audit logging. Built to satisfy HIPAA requirements from the start.
4. Private LLM deployment architecture — end-to-end design for deploying LLMs in a HIPAA-eligible environment: infrastructure selection, security controls, BAA management, and inference pipeline architecture.
5. Denial prediction and scrubbing system design — ML architecture for pre-submission claims validation, including training data preparation, model selection, integration with existing billing workflows, and human-in-the-loop escalation design.
6. Executive and board AI communication — translating AI program progress, risk, and investment into business terms for executive leadership and board-level governance.

These are detailed on the main Fractional CAIO services page — substantiated here by hands-on healthcare billing system architecture and payer-side enterprise architecture experience.

How the engagement works

• Discovery (2–4 weeks): process mapping, data audit, PHI regulatory mapping, and AI use-case prioritization. Output: a written AI roadmap and governance framework tailored to your claims and billing environment.
• Architecture phase: claims AI system design, PHI governance framework, private LLM deployment architecture, or whichever priority use cases the discovery surfaces.
• Build and deployment: model integration, compliance validation, and production deployment with monitoring, audit logging, and human review workflows.
• Ongoing: model accuracy tracking, regulatory documentation updates, and roadmap expansion as your AI program matures.

If you’re an Upland or Inland Empire company in healthcare, benefits administration, or any regulated domain evaluating AI strategy — the next step is a discovery call.