What this use case’s data looks like
Pre-existing condition determination data primarily comes from medical insurance settlement records, past medical visit records, and health notification questionnaires submitted during policy application. Medical insurance settlement records are updated synchronously by medical insurance handling institutions on a calendar day basis. Medical visit records are uploaded to the medical insurance system in real time by medical institutions. Health notification questionnaire data is generated in real time alongside the policy application process.
Data documents are divided into two categories: structured and unstructured. Structured documents include fields such as visit date, diagnosis code, and cost amount. Diagnosis codes follow the ICD-10 standard, with no unit of measurement. Unstructured medical record text contains natural language content such as chief complaint, present medical history, and past medical history.
Constraints Imposed on Tool Calling and Plugins
The need to connect multiple data sources requires plugins to support simultaneous calls to three types of external interfaces: medical insurance, medical records, and health notifications. Different interfaces have distinct authentication rules and return formats.
Differences in data update frequencies require matching caching strategies to prevent outdated data from affecting determination results. Standardized structured field requirements mandate mapping fields returned by external interfaces—such as ICD-10 codes and visit dates—to unified workflow variables. Unstructured text must first undergo entity extraction before it can be used for determination.
Additionally, variations in the length of medical documents may result in large datasets being returned by a single interface call. Returned entries must be limited to match workflow processing capabilities.
Configuration Settings
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
plugin_auth_type | api_key_auth | Most external medical data interfaces such as medical insurance and medical records use API key authentication, which aligns with industry general connection specifications. |
plugin_request_timeout | 300 seconds | Pre-existing condition determination requires pulling multiple medical documents. 300 seconds covers the response cycles of most medical institution interfaces, preventing critical data loss from timeouts. |
plugin_cache_ttl | 86400 seconds | Medical insurance settlement data is updated daily. This cache duration balances data timeliness and interface call costs. |
structured_data_mapping | {"diagnosis_code": "icd10_code", "visit_date": "service_date", "cost_amount": "total_fee"} | Standardize the mapping between external interface return fields and workflow required fields to avoid parsing failures caused by inconsistent field names. |
max_response_items | 20 | Pre-existing condition determination requires matching up to 20 relevant visit records, covering verification needs for most claim scenarios. |
error_retry_count | 2 | External interfaces may experience occasional fluctuations. Two retries reduce the rate of call failures caused by temporary faults. |
The parameter values provided on this page are common starting points for configuration. Actual values are affected by material format, data volume, and business rules. Specific issues require individual analysis. It is recommended to test on your own samples before finalizing settings.
Three Common Misconfigurations
- Symptom: When calling an MCP tool in a workflow, the configured global token variable cannot be retrieved, resulting in authentication failure. Cause: The global variable transfer switch was not enabled in the plugin configuration, and the global variable was not bound to the tool request parameters.
- Symptom: Plugin call returns empty result fields. Cause: No structured data mapping rules were set, and original interface fields were used directly, causing the workflow to fail to recognize the corresponding variables.
- Symptom: Tool call returns a timeout error. Cause: The configured request timeout duration was too short, failing to cover the time required to pull and parse multiple medical documents.
How to Verify Proper Configuration
- Navigate to the FastGPT plugin management page, select the corresponding pre-existing condition determination plugin, enter a test API key, and trigger a connectivity test. Confirm that a 200 status code is returned.
- Manually trigger the configured claim initial review workflow, view the tool call logs, and confirm that the fields mapped from structured data fully match the workflow variables, with no missing fields.
- Simulate a call scenario containing multiple visit records, verify that the number of results returned by the tool does not exceed the preset
max_response_itemsvalue. - Wait 24 hours, then call the plugin again. Confirm that the returned medical insurance data is the latest updated record, with no expired data remaining.
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-14.