Inspiration

I've spent time close to healthcare operations. And the thing that stays with you isn't the complexity of the technology — it's the human cost of when it fails.A claims processor manually retyping a handwritten ambulance runsheet at 11pm because the OCR rejected it. A COB specialist trying to untangle three overlapping insurance policies with a spreadsheet and a prayer. And the one that haunted me most: a family receiving an automated billing call for a deceased parent — because no system checked before the dialers fired.That last one isn't just painful. It's a lawsuit. FDCPA and TCPA class-action exposure from a single batch billing run against a member in the Social Security Death Master File can exceed $5 million in settlements. And it happens because payers are running disconnected bots with no shared memory, no persistent state, and no human authority checkpoints that actually matter.I built OmniShield 360 because I believed UiPath Maestro Case was finally the right primitive to hold all of this together — a single governed lifecycle where AI agents, robots, APIs, and humans work in sequence, with Maestro owning the state so nothing falls through the cracks.

What it does

OmniShield 360 is a persistent UiPath Maestro Case that takes a healthcare claim from first intake all the way through adjudication, settlement, EHR sync, and closure — and handles every failure mode along the way.When a claim arrives — whether it's a clean electronic 837 or a blurry handwritten ambulance runsheet — the case opens and seven coded AI agents get to work inside it:The OCR streaming agent reads the document and watches confidence scores in real time. If it drops below 85%, it doesn't guess. It pauses the case and opens a task for a human Intake Specialist who can see exactly which fields are uncertain and fix them before anything else runs.The PHI masking agent strips every piece of protected health information before it touches an LLM — tracking each token's exact position in the text so it can be restored perfectly, even when two patient identifiers are sitting right next to each other.The COB engine applies CMS Medicare Secondary Payer rules first — because federal law says so — then commercial birthday rules, then plan start dates. It produces a clean, legally ordered payer sequence for dual and triple coverage claims, not a coin flip.The compliance agent checks the member's SSN against the Social Security Death Master File. The moment there's a match, it freezes the billing pipeline before a single outbound communication fires, routes the case to a Legal Estates hold, and puts a task in front of a specialist. No automated calls. No lawsuit.The Agent-as-Judge runs last — scanning everything accumulated across all prior stages for contradictions before the Claims Adjuster sees the final approval screen. It's the check that catches what individual agents miss when they're only looking at their own slice.And through all of it, there are eight human decision points built into the case. Not as an afterthought — as a design principle. Humans approve medical necessity decisions. Humans confirm COB payer order. Humans authorize final settlement. The agents make humans faster and better informed. They don't replace them.

How we built it

The foundation is UiPath Maestro Case — chosen specifically because healthcare claims aren't transactions, they're investigations. They take days. They get exceptions. They need to pause, re-enter, escalate, and resume without losing context. Maestro holds that state natively. No custom state machine code, no workarounds.The seven coded agents are Python 3.11, mapped to Orchestrator-invocable functions via uipath.json. Each one returns a structured case write-back patch — Maestro applies it and decides what happens next. The agents never move the case themselves. That discipline matters: it means Maestro's audit log is always the single source of truth.For the LLM-backed tasks — medical necessity review and the Agent-as-Judge — UiPath Agent Builder handles the AI trust layer. PHI is masked before every call. Results are cached on resubmissions and retried with exponential backoff on failures. When the model isn't confident enough, it hands off to a human rather than guessing.The entire codebase was built using Claude Code as a UiPath Coding Agent, through uip skills install --agents claude. The algorithms that matter most — the position-indexed PHI tokenizer, the O(n) SHA-256 fraud fingerprinting, the CMS MSP precedence waterfall, the SSDI circuit breaker — were all designed and implemented in that workflow. It's not a demo of using an AI to write boilerplate. It's an AI agent that made consequential engineering decisions under real constraints.CI/CD runs on GitHub Actions — Ubuntu and Windows both — with strict mypy type checking, seven regression scenarios that run without any API keys (UIPATH_NO_LLM=1), and automated uipath pack and publish to the Orchestrator Tenant Feed on every merge.

Challenges we ran into

Getting PHI masking right. The first version used straightforward string replacement — find the value, swap in a token, reverse it on the way out. It broke the moment two PHI tokens were adjacent, or one was a substring of the other. Rebuilding it to track the character-position span of every substitution in the final output text — so restoration is positional, not textual — was the fix. It's invisible when it works. It's a HIPAA incident when it doesn't.COB logic is genuinely hard. Most COB engines apply a birthday rule and stop. The real-world case is messier: CMS MSP rules legally override commercial rules, but only in specific Medicare enrollment scenarios. Within commercial plans, the birthday rule applies unless one plan is employer-sponsored and the other is individual. And then there's the tertiary payer case, which most systems pretend doesn't exist. Getting all of that into one coherent precedence waterfall — without letting the commercial logic bleed into the CMS logic — took more iterations than anything else in the project.Testing LLM-backed agents in CI. Medical necessity review calls a live LLM. Non-deterministic by nature. Getting seven scenarios to pass reliably on every push without live API access meant designing the UIPATH_NO_LLM=1 bypass mode from day one — every LLM agent has a deterministic fallback path that returns realistic pre-configured responses. It's not a mock. It's a governed offline mode. The difference matters when you're trying to prove a CI green means something.Maestro case write-back discipline. Early on, agents were making assumptions about what fields Maestro was reading and when. That produced subtle race conditions where a case field was written by one agent and immediately overwritten by another before Maestro could act on it. Defining explicit typed CaseTaskResult contracts in case_management/contracts.py — one per stage, with every field that Maestro reads declared and documented — eliminated the ambiguity entirely.

Accomplishments that we're proud of

The Agent-as-Judge came together better than expected. The idea of having a cross-stage consistency reviewer — one agent whose only job is to look for contradictions in everything the other agents decided — turned out to be genuinely useful in testing. It caught cases where a fraud risk flag in Stage 2 was technically resolved but not in a way that was consistent with the medical necessity decision in Stage 3. No individual agent would have seen that. The Judge did.

What we learned

Maestro Case changes how you think about automation architecture. Once you have a persistent, stateful lifecycle as the outer shell, a lot of problems that looked like integration problems turn out to be coordination problems — and coordination problems are much easier to solve when one component owns the state and everyone else just writes patches to it. The UIPATH_NO_LLM=1 pattern taught us something broader: any AI-backed agent that can't run deterministically in a test environment is a system you can't trust in production. The discipline of building the offline mode first — and treating it as a first-class path, not a hack — made the whole system more robust, not just more testable. And position-indexed PHI tokenization sounds like an implementation detail. It's not. It's the thing that makes the entire LLM integration safe. If PHI can leak into an external API call under any circumstances — overlapping tokens, adjacent values, substring collisions — the architecture is broken regardless of how good everything else is. Getting that right early saved everything downstream.

What's next for Omnishield360

The SSDI check is currently running against a mocked Death Master File for the demo. The production path is a live integration with the SSA or a commercial DMF provider like LexisNexis — with real-time match confidence scoring, not just binary match/no-match. That changes the routing logic meaningfully: a 94% confidence match on a common name needs a different human action than a 100% SSN match. The COB engine needs real payer API integrations behind it — right now it's computing the correct payer order, but writing it back manually. Connecting it to the actual clearinghouse APIs so it can dispatch the split claim automatically is the next engineering milestone. On the Maestro side: native Data Fabric case entity support would significantly simplify the trigger configuration. The current Wait-for-Connector setup works, but it's more configuration than it should be for a standard claim intake trigger. As Maestro Case matures out of private preview, that's the integration that would make this production-deployable at scale. And the human action app interfaces are functional but minimal. For a real payer deployment, each Action Center task — intake validation, COB confirmation, fraud investigation, legal estates disposition — needs a purpose-built UI that surfaces exactly the right context for that decision. That's product design work as much as engineering work, and it's where the system would earn its keep day-to-day.

Built With

  • apache
  • claude-code-(uipath-coding-agent)
  • github-actions
  • opentelemetry
  • python-3.11
  • uipath-agent-builder
  • uipath-api-workflow
  • uipath-automation-cloud
  • uipath-cli
  • uipath-coded-agents
  • uipath-human-action-app
  • uipath-integration-service
  • uipath-maestro-case
  • uipath-orchestrator
  • uipath-studio-web
Share this project:

Updates

posted an update —

After deep-diving the codebase this final stretch, here's what's locked and ready for judges:

What's Complete

  • 7 coded Python agents running inside a UiPath Maestro Case — Intake → Review → Settlement → Closure with 5 secondary exception stages
  • SSDI/Death Master File circuit breaker — claim-scoped billing freeze the instant a deceased member is detected. Zero FDCPA exposure.
  • O(n) SHA-256 duplicate fraud detection — O(1) lookup, no exponential blowup regardless of claim volume
  • Position-indexed PHI masking — PII is tokenized before any LLM call, with collision-safe restoration
  • Plan-aware COB engine — CMS Medicare Secondary Payer precedence → commercial birthday rule → plan start date. Full 3-way coverage support.
  • Agent-as-Judge — cross-stage contradiction detection before final settlement approval
  • 8 Human-in-the-Loop gates — humans stay in authority at OCR validation, medical necessity, COB confirmation, fraud hold, legal estates, and final claims adjuster approval
  • Cross-platform CI/CD — GitHub Actions runs all 7 deterministic scenarios on Ubuntu + Windows, mypy strict, uipath pack → publish to Orchestrator
  • Built with Claude Code via uip skills install --agents claude — UiPath Coding Agents bonus documented and shown in demo

Run it yourself (no API keys needed)

git clone https://github.com/jagaadi/Omnishield360
cd Omnishield360 && pip install uv && uv venv && uv pip install -e ".[dev]"
UIPATH_NO_LLM=1 python main.py --scenario SCENARIO_03_COMPLIANCE_DECEASED_LITIGATION_SHIELD

Log in or sign up for Devpost to join the conversation.