What the data for this category looks like
Typical data for this category comes from the national medical insurance information platform, hospital HIS and medical insurance interfaces, medical insurance catalog coding library, and cross-regional medical settlement platform. The update frequency is daily. Commonly processed documents include medical insurance settlement lists, expense details, medical record homepages, prescriptions, rejection lists, and settlement reconciliation statements. Most documents are tabular or semi-structured text, with fields such as diagnosis and treatment project codes, expense amounts, insured person identity identifiers, and medical institution information. Field units are mostly yuan, person-times, and standard coding numbers.
What constraints do these characteristics impose on the "document parsing and chunking" link
Large volumes of documents are updated daily, so the parsing process requires efficient batch processing capabilities. Multiple document formats are used, so parsing logic must adapt to PDF, HTML, TXT and other formats. Structured fields such as codes and amounts must retain contextual associations to avoid field splitting breaks. Controversial documents such as rejection lists require accurate extraction of associated fields to provide complete basis for subsequent audits.
Configuration settings
Reference only; verify against the target FastGPT release and deployment documentation.
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
chunkSize | 800–1200 characters | Adapt to the continuous field length of codes, amounts, and diagnosis and treatment items in medical insurance documents, and avoid splitting key information |
chunkSplitter | Semantic + paragraph boundary | Adapt to multi-format documents (PDF settlement sheets, HTML prescriptions, TXT details) and retain contextual associations |
customPdfParse | Enable table structured parsing | Target tabular documents such as medical insurance settlement lists and medical record homepages, extract structured fields to avoid splitting |
PARSE_FILE_TIMEOUT_SECONDS | 600 seconds | Process daily batch medical insurance documents and avoid parsing timeouts due to large file volumes |
UPLOAD_FILE_MAX_SIZE | 100 MB | Adapt to single-batch bulk uploaded settlement detail files and match daily batch processing scales |
Three common mistakes
- After uploading a Java interface document whose file extension has been modified to TXT, the parsing result has no valid data. Cause: The actual document format does not match the file extension. The parsing engine cannot identify structured medical insurance-related content, and only extracts redundant code fragments.
- After using chunk mode to call the pushdata API to upload documents, the interface permanently displays the indexing status. Cause: The
PARSE_FILE_TIMEOUT_SECONDSconfiguration value is too low, or the batch upload data volume exceeds theUPLOAD_FILE_MAX_SIZElimit, causing the parsing process to fail to complete. - After uploading an HTML interface document generated by Javadoc, there is no valid parsing content. Cause: The default chunker does not adapt to structured documents with nested HTML tags, and does not split valid text by semantic boundaries.
How to confirm the configuration is correct
- Upload a single standard medical insurance settlement list PDF, and check whether the parsing result contains complete diagnosis and treatment project codes and expense amount fields.
- Call the pushdata API to upload batch documents, and verify whether the parsing progress is completed within the time limit set by the
PARSE_FILE_TIMEOUT_SECONDSconfiguration. - Upload a non-target format document with a modified extension (such as a Java interface file renamed to TXT), and verify that the parsing result only extracts valid medical insurance-related text and has no redundant code content.
- Upload an HTML format prescription document, and check whether the chunking result retains the semantic context of the prescription and does not split key medication information.
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.