Validation (via DVS)
Once a support file is uploaded (and classified, if it came in via v2), RCM hands it to DVS (Document Validation Service) for content validation. DVS runs the document against the rule set configured for the (country_code, agreement_code) of the account and emits a verdict.
There are two terminal outcomes for every validation attempt:
validation_status | Webhook event | Meaning |
|---|---|---|
APPROVED | DOCUMENT_VALIDATION_COMPLETED | Every applicable rule passed. The supporting document is good; the charge can move on. |
REJECTED | DOCUMENT_VALIDATION_REJECTED | One or more rules failed. The errors array lists each failure with the field, reason, and confidence. |
What's in a rule
A rule is one of:
- Field presence — "the patient document field must be filled" (
tiss.patient_document.required) - Field format — "the guide number must be exactly 14 digits" (
tiss.guide_number.format) - Cross-field invariant — "if a procedure code is in category X, the executor council must be a CRM" (
tiss.procedure_executor_consistency) - Catalogue match — "the procedure code must exist in the TUSS catalogue" (
tiss.procedure_code.catalogue) - Date constraint — "the document must be issued within 90 days of the procedure" (
tiss.issued_at.freshness)
Each rule has a stable rule_id (e.g. tiss.guide_number.format) and a severity of BLOCKING (causes REJECTED on its own) or WARNING (advisory; doesn't cause rejection alone but bundles with BLOCKINGs).
When a rule fails, each entry in the webhook errors array carries field, value, reason, subreason, reason_key, and precision_percentage — enough to show a useful error to the end user. See Webhook events → Validation for the full schema.
What's extracted
For approved files, DVS also returns extracted_fields — the structured data it pulled out of the document. Shape varies by support_file_code (a TISS guide has guide_number, patient_name, patient_document, procedure_code, issued_at, professional_council, etc.; a pathology report has different fields). Use this to display the document content in your UI without re-parsing the PDF yourself, or to drive downstream business logic.
Where rules come from
Rules are configured per (country_code, agreement_code, support_file_code) triple by OSIGU's operations team in collaboration with the payer. They're not editable by integrators. New rules are deployed continuously as payers refine their requirements — your integration doesn't need to do anything; the next upload just goes through the new rules.
If you suddenly see a reason you've never seen before in a DOCUMENT_VALIDATION_REJECTED event, it's likely a new requirement rolled out. If it's unclear, contact OSIGU support.
Delivery reliability
Validation events are delivered like all RCM webhooks: at-least-once, retried by the dispatcher on its next cycle (about once per minute) if your endpoint doesn't return 2xx, with a per-subscription circuit breaker that suspends delivery after repeated failures. Dedupe on event_id. See Webhook events → Delivery model.