Form F Lifecycle

What is a Form F?

A Form F (Drug Intent Request) is the structured record that captures a client's intent to add, change, or terminate a drug on their formulary. It is the primary unit of work in CLIC.

Each Form F:

• Is associated with a client and a template (defined by Admin)
• Contains one or more drug intent records (one per GPI/NDC)
• Moves through draft → submitted states before being dispatched to DOSE

Lifecycle

Creating a Form F

1. Select client — looked up via RxClient360 (name, LOB, CAG)
2. Select template — Admin-defined template with required fields
3. Add drug intent records — search drug by name/GPI/NDC via FSOT; fill intent fields per record
4. Save as draft — can return and edit; multiple saves allowed
5. Submit — final validation runs; Form F becomes immutable; payload dispatched to DOSE

Form F Request — MongoDB Schema

{
  "_id": "ObjectId",
  "sn": "string",
  "requestName": "string",
  "clientId": "string",
  "status": "DRAFT | SUBMITTED | DISPATCHED | COMPLETED | CANCELLED",
  "stage": "string",
  "isLatest": true,
  "auditInfo": {
    "createdAt": "timestamp",
    "createdBy": "string",
    "updatedAt": "timestamp",
    "updatedBy": "string"
  },
  "type": "string",
  "templateRowsData": [...]
}

Drug Intent Record — MongoDB Schema

Each drug record captured within a Form F:

{
  "_id": "ObjectId",
  "sn": "string",
  "formFRequestId": "string",
  "version": 1,
  "isLatest": true,
  "drugIntentElements": {
    "formId": "string",
    "formName": "string",
    "status": "string",
    "fAndBCode": "string",
    "NDC": "string",
    "GPI": "string",
    "CAGP": {
      "accountId": "string",
      "carrierId": "string",
      "groupId": "string",
      "planCode": "string"
    }
  },
  "auditInfo": {...}
}

API Endpoints

All endpoints require Bearer JWT auth (/api/v1/drug-intent):

Method	Path	Purpose
GET	/{id}	Fetch single drug intent
GET	/	List with pagination (clientId, status, page, size, sort)
POST	/	Create (audit event emitted on creation)
PUT	/{id}	Full update with optimistic locking (@Version)
PATCH	/{id}/status	Status transition: ACTIVE / INACTIVE / SUBMITTED
DELETE	/{id}	Soft delete (flag + audit trace preserved)
POST	/{id}/formf	Append FormF edit record with validation

Validation Rules

All inputs validated at the API layer before persistence:

• Mandatory fields: Required fields cannot be null/blank at processing time
• Data type: Numeric fields (e.g., NPI/Prescriber ID) — 10 digits max, no alphabetic characters
• Referential integrity: clientId must resolve in RxClient360
• Duplicate detection: Duplicate records rejected with error message
• Concurrency: Optimistic locking via @Version — prevents lost updates under concurrent edits

Drug Search (FSOT Integration)

Within the Form F UI, users search for drugs using:

• Drug name (partial match)
• GPI (14-character Generic Product Identifier)
• NDC (National Drug Code)

Results come from FSOT (Formulary System of Truth). Once a drug is verified via FSOT, the GPI field becomes read-only on that record to prevent unintended changes.

Phase 2: AI Coding Workspace

After Phase 1 submission, Clinical Coders will use an AI-assisted workspace to:

• Review Form F drug intent data
• Receive AI-generated RxClaim coding suggestions
• Approve/edit/regenerate suggestions before final submission to RxClaim

Features in scope for 9/30 and 10/28 releases:

• F1891720 — Coding Workspace: RxClaim Form Foundations (frontend)
• F1898885 — Coding Workspace: RxClaim Form (backend)
• F1891717 — Prompt Review & Regenerate
• F1891718 — Backend Inference LLM Service (MVP)
• F1891719 — Data logging & traceability pipeline