What Does the Data for This Category Look Like?
This category's data comes from the national medical security information platform, hospital HIS and medical insurance interfaces, medical insurance catalog and coding library, and cross-provincial medical settlement platform. The update frequency is daily batch synchronization. Daily processed documents include medical settlement lists, expense details, medical record homepages, prescriptions, rejection lists, and settlement reconciliation statements. Structured data includes fields such as settlement number, expense amount, diagnosis and treatment project code, drug and consumable code, insured person information, and audit status. Unstructured data includes prescription scans, medical record attachments, etc. The main data format is structured tables, and some fields need to match the national unified medical insurance coding standards.
What Constraints Do These Characteristics Impose on Database and Operations?
The large volume of daily batch synchronization data requires scheduled incremental synchronization tasks to avoid excessive system resource usage from full pull requests. Heterogeneous data from multiple sources needs to adapt to different storage types: unstructured settlement attachments and prescription scans are suitable for document database storage, while structured data such as settlement ledgers, audit results, and medical insurance coding mappings are suitable for relational database storage. Matching and verification of medical insurance-specific coding fields is the core time-consuming link, so joint indexes need to be created for frequently queried coding fields. High data consistency requirements require transaction guarantees for ledger updates during the audit process to avoid fund overpayment or rejection disputes. Reasonably configure the database connection pool to meet the concurrent requirements of batch data processing and prevent connection exhaustion from affecting normal business operations.
How to Configure Settings
The following configurations apply to FastGPT v4.17.0.
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
MONGODB_URI | Cluster connection string with authentication information, configured with read-write separation nodes | Store unstructured medical business documents such as settlement attachments and prescription scans |
PG_URL | Read replica connection address configured | Store structured data such as settlement ledgers, audit results, and medical insurance coding mappings |
DB_MAX_LINK | 20–30 | Adapt to concurrent read-write requirements of daily batch updated data, avoid database connection exhaustion |
REDIS_URL | Local cache node address configured, set key expiration time to 1 hour | Cache frequently queried medical insurance coding mapping data to reduce repeated database queries |
| Data synchronization interval | 15–30 minutes | Match daily updated business rhythm, balance data real-time performance and system resource usage |
| Index configuration | Create joint indexes for settlement number, insured person ID, and diagnosis and treatment code fields | Accelerate multi-condition query and statistical operations for ledger summary |
Three Common Misconfigurations
- Partial data only captured: Symptoms include missing ledger fields or insufficient record count in the database synchronization background, with logs showing partial interface requests not completed. Cause: No resume-from-breakpoint logic configured for incremental synchronization, so synchronization does not resume from the last pull position after an interruption.
- Data parameter enhancement processing unavailable: Symptoms include inability to call medical insurance coding matching and expense verification enhancement functions in the trial environment, with a permission denied prompt displayed on the interface. Cause: Corresponding module permission configuration not enabled, or compliant medical insurance data interface permissions not bound.
- MongoDB slow operation log error: Symptoms include
slow operation xxxxmslogs appearing during batch synchronization in a Docker deployment environment, with MongoDB response delays. Cause: MongoDB read-write separation not configured, with a single node processing a large number of read-write requests simultaneously leading to response overload.
How to Confirm Successful Configuration
- Run database connection tests to verify that read-write permissions for
MONGODB_URIandPG_URLare normal, with no connection timeout errors. - Check data synchronization task logs to confirm that daily incremental synchronization tasks run at the set interval, with no batch data loss or field missing issues.
- Spot-check ledger summary results, verify the correctness of medical insurance coding matching fields, and confirm that cached coding data updates match the set expiration time.
- Check Redis connection status, confirm that frequently queried cache keys do not experience expiration or loss, reducing direct database query times.
The values provided are common starting points and should be measured against the reader's own samples.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-09-28.