IC Application Reference

The IC (Integrated Components) framework is the code-generation and runtime layer that powers every REV.health module. This page documents the shared stack, conventions, and commands.

Shared Technology Stack

Project Directory Skeleton

module-root/
  ami/                  # AMI schema definitions (.ami.json)
    patient.ami.json
    encounter.ami.json
  rules/                # Business rules (.rules.json)
    eligibility.rules.json
  api/                  # Generated API controllers + DTOs
    controllers/
    dtos/
    validators/
  components/           # Generated Angular components
    forms/
    tables/
    detail-views/
  adapters/             # External integration adapters
    surescripts/
    stedi/
    waystar/
  jobs/                 # Background job definitions
    sync/
    cleanup/
  deploy/               # IaC and deployment manifests
    cosmos/
    cdn/
    k8s/

Component Naming Convention

Code Generation Flow

graph TD
  AMI["AMI Schema
(.ami.json)"] --> PARSE["Parse & Validate"]
  PARSE --> DB["Generate Cosmos
Container Config"]
  PARSE --> API["Generate API
Controllers + DTOs"]
  PARSE --> COMP["Generate Angular
Components"]
  PARSE --> TEST["Generate Test
Scaffolds"]
  DB --> DEPLOY["Deploy Stage:
Cosmos containers"]
  API --> DEPLOY
  COMP --> CDN["Deploy Stage:
CDN bundle"]
  TEST --> CI["CI/CD Pipeline"]
  CI --> DEPLOY
  

Default Bindings

When generating components from AMI schemas, each field type maps to a default Angular component:

Environment Cascade

Permissions / RBAC Enforcement

The core RBAC rules are the same for all modules. Module-specific thresholds (e.g., which level can submit a claim vs. prescribe a controlled substance) are documented on each module's IC application page.

Access control is enforced at four layers:

• Database layer. Cosmos partition-key isolation keyed on the OrganizationID partition key blocks any cross-org read or write. The session variable is set at request context from the API using the authenticated user's org claim. Global containers (e.g., Prescription) do not use partition-key isolation; reads are scoped by patient identity through the application-layer authorization chain.
• API layer. Generated controllers compare the caller's IC permission level (0–100) against the entity threshold for the requested verb. Reading raw RawRequestText / RawResponseText requires elevated permission (typically ≥ 70) because raw payloads can leak unrelated details.
• Component layer. Edit controls disable on the client when the caller's level is below the field's write threshold. EditAMI controls (add required field, change type, remove field) are gated client-side and server-side at level 90 per IC rule #5.
• Read-access audit. Reads of sensitive data emit AuditLog rows capturing the viewer, the entity, and the authorization-chain trace per the global read-access audit contract.

Every API endpoint has a numeric permission level (0–100); the caller's role must meet or exceed the required level:

Build / Test / Run Commands

The command pattern is the same for all modules. Replace {noun} with the module's root noun (e.g., eligibility, rcm, erx-epcs, scheduling). Module-specific test flags (e.g., --scrubbing for RCM, --epcs for eRx / EPCS, --pdmp for eRx / EPCS) are documented on each module's IC application page.

Module Root Nouns

Each module is identified by a root noun used in container names, API routes, component prefixes, and deploy manifests: