Security & Data Protection

1. Security Architecture

PMJAY Claim Trust Engine follows a data-minimization and local-first architecture for supported claim-processing workflows.

The Platform separates:

Account & Authentication Layer

Handles:

• Registration
• Login
• Password verification
• OTP verification
• Authentication/session management
• Subscription information
• Payment-related records
• Device verification
• Account management

Claim Governance Layer

Supported workflows operate locally within the user’s browser and may include:

• File reading
• Spreadsheet parsing
• Claim validation
• Deduction calculations
• Doctor payout calculations
• Hospital payout calculations
• Reconciliation
• Report generation

2. Local Browser Processing

Visual Architecture Flow:

For supported local-processing workflows, the selected claim file is processed within the user’s browser. The claim file is not intentionally uploaded to the application server.

3. Claim Data and Server APIs

Server APIs are used for account and application functions such as authentication, account management, subscriptions, packages, payments, and device verification.

Supported local claim-processing workflows are distinguished from server API traffic and do not intentionally transmit patient or claim spreadsheet fields through account API endpoints.

4. Database Separation

The application database is used for account and application functions and is not intended to store patient claim spreadsheet rows for supported local-processing workflows.

5. Authentication Security

Authentication controls include:

• Password hashing
• OTP verification
• Session/authentication controls
• Authorization
• Device verification

6. Browser Storage

Browser storage may contain authentication/session information, user preferences, theme configuration, or calculation preferences.

Supported claim-processing records are not intentionally persisted in localStorage or sessionStorage.

7. Network Security

Communications between the browser and server-side application services use HTTPS/TLS encrypted connections.

8. Secrets Management

Database credentials, private API credentials, payment-provider secrets, JWT signing secrets, and other server-side secrets remain server-side and must not be embedded in public frontend JavaScript.

Direct public access to `.env` and other sensitive configuration files is denied.

9. Analytics

The current architecture does not intentionally use third-party analytics to collect patient or claim information.

10. Error Monitoring

The current architecture does not intentionally send patient or claim information to third-party error-monitoring services.

11. Logging

Application logs should follow data minimization and should not unnecessarily contain:

• Patient names
• Beneficiary information
• Claim records
• UTR information
• Sensitive claim fields

12. User Device Security

Users should maintain basic device security controls:

• Password-protected devices
• Updated operating systems
• Updated browsers
• Secure networks
• Protected exported files
• Secure backups
• Proper deletion of sensitive files

13. Exported Reports

Once a report is downloaded to a user’s computer, the user is responsible for protecting that file on their local device.

14. Vulnerability Reporting

Security researchers and users who believe they have discovered a vulnerability should report it privately and avoid including unnecessary patient information.

15. Security Incident Response

Security incident response steps include:

1. Identification
2. Containment
3. Investigation
4. Remediation
5. Recovery
6. Notification where legally required

16. Security Scope

The security architecture described applies to the current supported implementation. Future features requiring server-side patient/claim processing must undergo security and privacy review before deployment.