MACESS Replacement Strategy

A controlled, stepwise approach to removing structural constraints and enabling a unified, efficient, and future-proof processing model for claims and authorizations.

Introduction

Strategic Overview of the MACESS Replacement Initiative

Overview

The objective is not simply to replace MACESS as a legacy system, but to remove structural constraints that prevent Conifer from operating with a unified, efficient, and future-proof processing model for claims and authorizations.

The concept of a single frontend layer—often described as a 360-degree member or case view—is central to that strategy, but it is only achievable if MACESS is replaced in a controlled, stepwise manner.

Key point: MACESS should not be replaced as a single monolithic action. It currently fulfills multiple roles, and each of those roles needs to be addressed independently, based on risk, value, and dependency.

Scope Note: This document focuses on functional decomposition and delivery strategy. Non-functional considerations such as security, encryption, scalability, performance, disaster recovery, and compliance are assumed to be addressed separately and are not covered in this document.

Three Components: Detailed Breakdown

1. File Cabinet ReplacementLowest-risk starting point

The existing file cabinet is tightly coupled to the MACESS UI and is inherently rigid and document-centric. By introducing a modern, API-first document repository, Conifer can decouple document storage and access from the legacy interface without changing how claims or authorizations are processed.

Documents remain intact, access control and auditability are migrated/preserved, but storage becomes flexible, scalable, and integration-friendly.

This new file cabinet becomes the single source of truth for documents across claims, authorizations, and correspondence. Crucially, it enables a modern document viewer that can be embedded into a new frontend layer.

At this stage, MACESS may still exist operationally, but it is no longer the place users must go to view or understand documents. This is the first concrete step toward separating user experience from backend tooling.

2. Workflow / Work Distribution ReplacementDriven by economics

This step is primarily driven by economics and long-term control. If the intent is to remove MACESS licensing costs, then queues and routing logic cannot remain inside MACESS indefinitely. This step is intentionally decoupled from the file cabinet replacement, because workflow is operationally sensitive and deeply embedded in daily processes.

Replacing workflow does not mean re-implementing adjudication or clinical decision logic. It means externalizing task assignment, prioritization, and routing into a Conifer-owned layer that can evolve over time.

This allows work to move from being queue-driven to case-driven, which is essential for enabling a unified frontend.

During transition, routing can be run in parallel and validated before MACESS queues are fully retired, keeping operational risk low.

3. Document TriageHandled by IBML IDP

Document triage, classification, confidence scoring, and exception detection for non-clinical data entry should be handled by IBML. Once IBML is live and stable for the document categories it owns, the MACESS Document Triage module is no longer required for those same use cases.

Importantly: This step is deliberately isolated so that MACESS exit is not dependent on IBML timelines beyond this specific capability. Will not be addressed in detail in this document.

Together, these three steps form a clean and resilient MACESS replacement strategy:

File cabinet replacement decouples storage and access
Workflow replacement removes license dependency and unlocks flexibility
Document triage is covered by Intelligent Document Capture Processing

The Result: True 360-Degree View

With documents coming from the new file cabinet and workflow owned outside of MACESS, a unified frontend can become the primary system of work for clinical staff. This frontend pulls claims and authorization context directly from EZ-CAP. No core business rules are re-implemented; the frontend aggregates context, status, and actions in one place.

Documents from the new file cabinet
Intake and classification signals from IBML
Claim and authorization state from EZ-CAP
Workflow status and task ownership from new routing layer

Instead of users switching between MACESS, EZ-CAP, and intake tools, the frontend becomes the single operational surface.

The Idea: Future Improvements

This architecture enables future improvements that are extremely difficult to implement today.

Once storage, workflow, and user experience are unified, Conifer gains the ability to layer in advanced capabilities that directly improve claims adjudication and authorization processing. These capabilities become possible only after the foundational components (File Cabinet, Workflow, and Document Triage) are in place and operating independently from MACESS.

1. File Cabinet

2. Workflow / Work Distribution Replacement

Combined Delivery Roadmap

This roadmap illustrates the combined delivery approach across File Cabinet and Workflow workstreams, showing parallel development tracks and key integration milestones leading to complete MACESS retirement.

PHASE 1: Foundation
Months 1-7

Track 1: File Cabinet

FE Document Viewer

Reusable component for Claims and Auth FE Apps (360-degree view)

Connects to Middleware
||
Middleware Layer

API Gateway with MACESS Connector

Initially reads from MACESS

Milestone: Control Gained

FE decoupled from MACESS. Document viewing operational.

Track 2: Workflow

Work Routing ComponentPriority #1

First and most important component to start in Phase 1

Part 1: Application

Core routing logic and UI

Part 2: Integration

Downstream systems creating work items

Workflow Engine

Integrates with File Cabinet middleware to pull and preload documents automatically

Depends on Track 1 Middleware

Milestone: Workflow Operational

Work routing and document preload active.

Phase 1 Complete - Month 7

Workflow Module

Ready for end users. Administration still via configuration files (UI to be provided in Phase 2).

Document Viewing Control

Gained and decoupled from MACESS using middleware layer.

FE Document Viewer

First version ready as reusable component for 360-degree initiative (Claims/Auth apps).

Middleware with MACESS Connector

Fully functional with APIs for Document Viewer operational.

Automatic Document Pull and Preload

Users can automatically pull documents from MACESS into the new viewer when starting work on an item. Next item is preloaded for immediate loading time.

Opportunity: This creates the ability to build macros or other automation to automatically pull work item data into EZ-CAP or other relevant downstream apps - serving as an intermediary solution before Auth and Claims Clinician FE apps are created as part of the 360-degree initiative.

Continue
PHASE 2: MACESS Retirement (Storage Migration + Admin Console)
Months 8-12

File Cabinet Completion

New Document Storage

Replace MACESS File Cabinet with new storage system

Document Migration

Migrate all documents from MACESS to new repository

MACESS License Exit

Remove File Cabinet license dependencies completely

Workflow Completion

Administrative Console UI

Build admin screens for queue, routing, and configuration management

Configuration Migration

Move from JSON-based to database-backed configurations

MACESS Workflow Retirement

Decommission MACESS workflow module completely

Final Outcome: Complete MACESS Retirement

All MACESS dependencies removed. Full control over document storage and workflow. License costs eliminated.

Timeline Summary

Months 1-7: Foundation (Parallel FE + Middleware + Workflow)
Months 8+: MACESS Retirement (Storage Migration + Admin Console)

MACESS Replacement Strategy Document