Data requirements
Data requirements for a no-PHI OpsRail pilot.
OpsRail Command Center can evaluate operational risk using synthetic, masked, or de-identified exports. No member names, DOBs, addresses, SSNs, Medicare IDs, or card PANs are required.
01 · What the MVP needs
Four operational file types. All flat CSV.
The MVP analyzes four file types together. None of them require PHI. Each is parsed against a strict schema before analysis.
Decline report
Transaction-level retailer declines. Feeds decline-spike, retailer-pattern, and SKU regression detection.
Eligibility summary
Daily eligibility snapshot per plan and member. Used to detect stale or missing eligibility loads.
SKU / UPC mapping
Retailer-specific product eligibility and benefit mapping. Used to detect mapping version regressions.
Escalation tracker
Open and aging escalations across plans and retailers. Used to flag vendor SLA risk and operational backlogs.
02 · Required fields
Field-by-field schema.
Each operational file is parsed against this schema. PHI columns are not required.
| Field | Required? | PHI? | Can be hashed? | Purpose |
|---|---|---|---|---|
| plan_id | Required | No | N/A | Plan-level analysis and incident grouping |
| benefit_type | Required | No | N/A | Detect OTC, Grocery, Flex, and benefit-specific patterns |
| retailer | Required | No | N/A | Retailer concentration and retailer-side issue detection |
| store_id | Optional | No | N/A | Store-level concentration analysis |
| state | Optional | No | N/A | Market and state-level impact analysis |
| member_id_hash | Required for eligibility matching | No if hashed | Yes | Match declined transactions to active eligibility records |
| card_id_hash | Optional | No if hashed | Yes | Optional transaction grouping |
| transaction_amount | Optional | No | N/A | Impact estimation and severity context |
| decline_code | Required | No | N/A | Decline pattern and root-cause signal |
| decline_reason | Required | No | N/A | Explain operational failure mode |
| upc | Required for SKU analysis | No | N/A | Match declines to SKU / UPC eligibility mappings |
| eligibility_status | Required | No | N/A | Identify active, inactive, and member-not-found patterns |
| file_date | Required | No | N/A | Eligibility freshness and stale-file detection |
| load_timestamp | Required | No | N/A | Load recency and ingest delay detection |
| eligible_flag | Required for SKU analysis | No | N/A | Identify mapping regressions or ineligible items |
| mapping_version | Required | No | N/A | Detect recent mapping version regressions |
| ticket_id | Optional | No | N/A | Connect incidents to escalation records |
| opened_at | Required for SLA analysis | No | N/A | Identify aging tickets and SLA risk |
| severity | Required for SLA analysis | No | N/A | Prioritize vendor escalation risk |
| owner | Optional | Avoid personal emails if possible | Yes or remove | Operational ownership context |
Member and card identifiers are accepted only as hashed values (e.g., SHA-256 with a customer-managed salt). The parser does not require — and the analysis engine does not use — raw identifiers.
03 · Do not upload
Data that should not be in pilot files.
These elements are not needed for supplemental benefit operations analysis. Please strip them before upload during evaluation.
- ✕Member name
- ✕Date of birth
- ✕Address
- ✕Phone number
- ✕Email address
- ✕Social Security Number
- ✕Medicare Beneficiary Identifier (MBI)
- ✕Full card PAN
- ✕Medical diagnosis
- ✕Clinical notes
- ✕Claims detail not needed for supplemental benefit ops analysis
04 · Recommended pilot format
How to prepare files for evaluation.
Use synthetic, masked, or de-identified files
Use stable fake member IDs so transactions can join eligibility records
Prefer historical operational exports when possible
Include known incident examples to validate detection accuracy
Remove direct identifiers before upload
No PHI required
De-identified or synthetic data is sufficient to validate detection accuracy and operational value.
Ready to evaluate