INGEST Validate + enrich inbound EMR / SFTP feeds before they become canonical ServiceEvents.
Capability · Engine
The rules engine.
No stored procedures. No code deploys. No back-office tickets. Three architectural commitments — content-addressed artifacts, scope precedence, effective dating — turn every business-rule change into a configuration action with a lifecycle.
The eight rule-set kinds
A rule for every stage of the pipeline.
Each rule kind is its own YAML schema, its own editor surface, and its own simulator. Together they cover ingestion through posting plus EVV — every category of work that used to live in a stored procedure.
CHARGE_VALIDATE Validate charge entries against payer, program, and credential constraints at the point of capture.
CHARGE_DERIVE Derive units, supervision flags, group-size adjustments, and modifiers from canonical service events.
CLAIM_BUILD_GROUPING Group charges into claims by payer, date, and submission rules; respect per-payer grouping policies.
PRE_SUBMIT_VALIDATE Final claim scrub before EDI dispatch — the rule kind that replaces per-payer T-SQL scrubbers.
COMPANION_GUIDE_VALIDATE Validate generated 837 / 270 against the trading-partner companion guide before dispatch.
POSTING Categorise denials, distribute responsibility, and post remittances against the ledger.
EVV_CONFIG State-by-state Electronic Visit Verification configuration — required for Home Care and I/DD.
Lifecycle
Draft → review → publish — auditable end to end.
Every rule artifact follows the same lifecycle. The diagram below is the literal state machine; transitions are audited; published artifacts are content-addressed and effective-dated.
Rendering diagram…
Scope precedence
Which rule wins? It's explainable.
Rules match against a 7+1 dimensional scope — org, site, facility, billing entity, payer, program, service line, plus state. Specificity scoring + a precedence_rank tie-break make the resolution deterministic and auditable.
The legacy approach was a T-SQL WHERE ladder buried
inside a stored procedure. Diagnosing "why did this claim block?"
meant reading SQL — and trusting that the ladder did what the
author meant.
On the new platform, resolution is a pipeline: filter by
effective date, filter by rule kind, match candidates on the 7+1
dimensions, score by specificity, tie-break by
precedence_rank. Every match returns the
winning rule plus the also-rans — so explaining a
block isn't an investigation, it's a click.
Rendering diagram…
The customer ships the change; engineering does not.
What this replaces
Every category of stored procedure has a configuration surface.
The hardest part of replacing a legacy RCM platform isn't the application — it's the dozens of T-SQL stored procedures encoding business rules. Each one maps cleanly to a rule kind or configuration surface.
Per-payer claim scrubbers
usp_ScrubClaim_<Payer> stored procedures
PRE_SUBMIT_VALIDATE rule artifacts with effective dating and a paste-a-claim simulator.
Modifier requirements
Modifier_Required lookup table + procedural code
modifier_validation rule kind with a simulator that returns the winning rule and the losing rules.
Per-payer trigger procedures
credential / POS / time / telehealth / group T-SQL triggers
5-trigger modifier injection with explicit precedence — no more buried logic.
Per-state procedures
One stored procedure per state, per behaviour
State-scoped rule artifacts deep-linked from the state navigator UI.
837 segment overrides
X12_Override table + 837 assembler tweaks
Per-segment rules + live preview from the companion-guide editor.
State-specific EVV checks
Per-state EVV check procedures
EVV_CONFIG rule kind with state-by-state YAML — rolling out a new state is a configuration commit.
Keep going
The rules engine sits in the middle of two other capabilities.
Upstream
EDI Engine
Where COMPANION_GUIDE_VALIDATE artifacts run and where 835s come in to trigger POSTING rules.
ReferenceMaster Data
The canonical catalogs the rules engine looks up — providers, payers, codes, state rate codes.
UI surfaceRCM Application
The /admin/rules/:kind editor + simulator surface that every rule kind exposes.