Integration · Sapiens
Claims automation that runs alongside Sapiens ClaimsPro
ClaimsPro stays the system of record. Hesper reads the claim, its exposures and the documents stored with the case, does the legwork, and writes evidence-backed findings and drafts back onto the file.
Last updated
In short
Yes. Hesper AI runs beside Sapiens ClaimsPro rather than instead of it. ClaimsPro stays the core claims system of record. Hesper picks the case up off an existing workflow rule, reads the FROI, the exposures, the narrative reports and the billing on it, and works compensability, coverage, investigation, settlement and recovery before filing a cited findings summary, an evidence package and drafts into the case repository. Your adjusters keep every decision.
Does Hesper replace Sapiens ClaimsPro?
No. ClaimsPro stays the system of record. The claim, its exposures, the reserves and benefit payments, the workflow rules and the audit trail all stay there, and so does the screen your adjusters spend the day in. Hesper administers nothing, sets no reserve of its own and releases no benefit payment. What it adds is a layer of evidence and finished work running beside the core.
The two are built for different jobs. Sapiens describes ClaimsPro as a cloud-native core claims solution with rules-driven workflow, automated claim assignment and case management for complex claims, built on a service-oriented, metadata-and-rules architecture. That is a system for recording a claim and governing who may do what to it. Hesper exists to do the work those records are a record of: reading the case end to end, retrieving and testing the evidence, and drafting what a person then signs.
The commercial argument follows from that. Replacing a core claims system is a multi-year programme with a business case of its own. Hesper connects across interfaces your ClaimsPro environment already publishes, scoped to a line and a set of jurisdictions, and withdrawing it means turning off one workflow rule. No ClaimsPro configuration changes shape because Hesper is reading it.
How does Hesper get the claim file?
Through the integration surfaces your ClaimsPro environment already has. Sapiens describes ClaimsPro as built on a service-oriented architecture, and its DigitalSuite is documented as pre-integrated with the Sapiens core suites and made up of digital engagement, digital enablement and API layer components. Carriers also run batch and file-based feeds beside those. Whichever of those your team is willing to open is what Hesper reads through. No desktop component, and nothing lifted off the screen.
- A trigger. Because ClaimsPro is rules-driven, the natural one is an existing workflow rule firing, such as the rule that escalates a claim to a senior adjuster or the one that opens a new exposure. A narrative report arriving on the case, or a scheduled queue filtered by line, jurisdiction and severity, work just as well.
- The claim as ClaimsPro governs it: the loss and its exposures, the claimant and the employer, the treating providers and vendors on the file, the coverages and reserves, and the workflow history showing how it got routed to whoever holds it now.
- The documents held with the case: ACORD forms, FROI filings, police and fire reports, medical records and narrative reports, estimates, invoices, photos, recorded-statement transcripts and correspondence.
- A written scope. On a workers' compensation book that has to include jurisdiction as well as line, because what may lawfully be retrieved about a claimant differs state by state, and a rule that is fine in one venue is a problem in the next.
Hesper will pull, accept a push, or take a scheduled batch. Because ClaimsPro is rules-driven, the cleanest first slice is usually an existing workflow rule rather than a new trigger: the rule that already routes a complex claim to a senior adjuster can route a copy to Hesper at the same moment, which means the pilot changes nothing about how work is assigned.
What does Hesper write back to ClaimsPro?
Finished work, filed where a ClaimsPro user is already looking for it. Sapiens's own description of ClaimsPro is a system that gathers and tracks data, documents and activities on a claim and keeps case-related information and communications in a central repository. Those are the places Hesper writes into. Nothing about the claim number, the routing or the history changes; Hesper only adds.
- A findings summary filed into the case repository in plain language, with each statement carrying the FROI field, the narrative report page or the billing line it rests on.
- An evidence package filed into the case repository: the underlying records, a reconstructed treatment and employment timeline, and each inconsistency the agents found with the two documents that disagree named against it.
- Drafts your team edits and owns: a coverage or compensability position, a reservation-of-rights or denial rationale, a response to a demand, or a subrogation demand against a responsible third party.
- An activity routed through your own workflow rules to whoever holds the file, naming the action Hesper recommends, so it queues the way any other ClaimsPro work item does.
What Hesper does not write matters just as much: no payments, no reserve changes it decided on its own, no denials, no compensability findings and no closed claims. Benefit decisions in particular stay inside your own rules and your own authority, because a compensability call carries statutory consequences an agent has no standing to accept. Everything Hesper produces enters ClaimsPro as a draft a person approves, edits or rejects, recorded against that person exactly as hand-worked output is.
What changes for the adjuster?
A ClaimsPro adjuster opens an indemnity claim into a repository, not a conclusion. Much of the claim goes on building context: reading the documents in the repository, chasing the ones that never arrived, querying external databases, reconciling a recorded statement against a repair estimate or a narrative medical report against a FROI. ClaimsPro records all of it faithfully and routes it well, which is the job a rules-driven core is built for. Routing the work is not the same as doing it.
With Hesper running, that reconciliation is finished and sourced before the claim is opened. The adjuster starts from a worked file rather than a repository of inputs, which on an indemnity claim is the difference between reviewing a compensability question and reconstructing one. Files that hold together clear with the checks on the record. Files that do not arrive with the contradiction named, the FROI and the narrative report set against each other, and the billing lines that duplicate already pulled out.
Decision authority does not move. Compensability, coverage, reserves, settlement authority, referral and denial all stay with your people, under the authority matrix ClaimsPro already enforces. See coverage verification and claim file review for what the agents produce at each point, and subrogation and recovery for the screen that usually happens late or not at all.
What does a ClaimsPro integration actually involve?
Less than carriers expect on the Hesper side and more than they expect on their own. We will not print a go-live date on a web page, because the schedule is set by your environment rather than by us: how your ClaimsPro instance is deployed and how change is released into it, how long your security and data reviews take, and how wide a first slice you want. The sequence below does not change between carriers, even where the configuration does.
- Scope: one line, one existing workflow rule as the trigger, the jurisdictions in play, and a written list of the claim types that are never eligible.
- Access: a non-production ClaimsPro environment, with the field and document set agreed in writing and the medical-record categories listed explicitly rather than implied.
- Mapping: your configuration's own vocabulary for claims, exposures, parties, vendors, documents and activities, agreed against what Hesper reads and writes. ClaimsPro is highly configurable, so this is carrier-specific rather than generic.
- Calibration: Hesper works closed ClaimsPro claims whose outcome your team already knows, and the comparison is made claim by claim against the compensability, reserve and settlement conclusions the file actually reached.
- Write-back: findings summaries, evidence packages and routed activities start appearing on live claims, read-only first for as long as your claims leadership wants.
- Widen: more workflow rules as triggers, more lines, more of the lifecycle, at the pace your claims leadership and your configuration release cycle allow.
Anyone who quotes you a go-live date before seeing your ClaimsPro configuration and your change-release calendar is guessing. Because ClaimsPro's metadata-and-rules architecture means two carriers on the same product can look almost nothing alike, we scope against your instance in a working session rather than against a reference implementation. Pricing is scoped to the book rather than published, for the same reason.
Where does the claim data go, and who can see it?
Claim data is encrypted in transit and at rest. Hesper is SOC 2 Type I attested and GDPR-ready, your data is never used to train models, and claim data and Hesper's output are held for the subscription term unless you instruct otherwise. Workers' compensation adds a second layer to that: claimant medical records carry state-level handling rules on top of the federal ones, so which records may be retrieved and how long they are held is agreed per jurisdiction before the first connection opens. Sapiens publishes its own security posture separately; that is theirs to speak to, not ours.
Each step an agent takes is stamped with the sources it used, the reasoning it followed and the time it ran. On an indemnity claim that record is not a nicety: a compensability position challenged at hearing is only as good as the provenance behind it, and a reconstructed timeline with no citations is an assertion. ClaimsPro's audit trail stays the authoritative account of who did what to the claim; Hesper's log explains how each entry it added was reached.
What does Hesper do, and what does your team decide?
| Hesper's agents | Your team |
|---|---|
| Reads the claim, its exposures and every document held with the case | Decides which lines, claim types, jurisdictions and severity bands are in scope |
| Runs compensability, coverage, investigation, valuation and recovery checks in parallel | Sets the authority matrix the results are routed under |
| Checks claimants, employers, treating providers and clinic addresses against external records | Approves which sources may be used in each jurisdiction |
| Files a cited findings summary, an evidence package and drafts into the case repository | Signs and owns anything that leaves the file, including every benefit decision |
| Routes an activity to the adjuster naming the recommended next action | Makes the compensability, reserve, settlement, referral and denial decisions |
| Logs every step with its sources and a timestamp | Keeps ClaimsPro as the authoritative record |
What does the output look like?
- Status
- Illustrative walkthrough, not a customer file. No Hesper customer, pilot or prospect is described here.
- Claim
- Workers' compensation, indemnity and medical, single claimant
- Trigger
- New document on the case: a treating physician's narrative report
- Read from ClaimsPro
- FROI data, the claim and its exposures, parties and vendors, and the documents held with the case
- Agents run
- Compensability review, medical records summarisation, statement cross-referencing, provider and entity verification, timeline reconstruction
- Written back
- A cited findings summary, an evidence package on the case, and an activity routed to the adjuster
Evidence cited
- The mechanism of injury described in the narrative report contradicts the FROI account and the supervisor's incident statement on two material points.
- Two billing lines duplicate treatment already billed by the same provider group under a different date of service.
- The treating provider appears on three other open indemnity claims in the book, all referred through the same clinic.
Recommended next action: Illustrative only, not a customer claim. Route to the investigation queue with the evidence package attached, and hold the disputed billing lines pending provider review. The payment, the denial, the compensability finding and the reserve are all decisions the adjuster and supervisor make in ClaimsPro; Hesper makes none of them.
Frequently asked questions
Is Hesper a Sapiens partner, or listed in the Sapiens partner ecosystem?
No. Hesper is not a Sapiens partner, is not listed in the Sapiens partner ecosystem, and holds no Sapiens certification or validation. We would rather state that than let the absence of a disclaimer imply an endorsement. It does not need one either. Everything Hesper touches is already reachable over the service and API layers ClaimsPro publishes.
ClaimsPro already includes severity models and automated fraud detection. Why add Hesper?
It does, and that is a real capability worth keeping. Sapiens's own product page describes predictive models for initial severity assessment and automated fraud detection inside ClaimsPro. The gap is what happens after a claim is scored. A score hands a flag to a person, and the workup behind that flag is still done by hand: at a manual pace of 14+ days per case against 200+ open cases per investigator, roughly 75% of flagged claims are never fully investigated (Hesper internal benchmarks). Hesper runs that workup and attaches the evidence. See fraud investigation.
Does this work with ClaimsPro for Workers' Compensation as well as the P&C edition?
Both are workable. Sapiens sells ClaimsPro editions for property and casualty and for workers' compensation, the latter covering the cycle from FROI through benefit resolution and closure. Hesper's agents are configured per line of business either way, and workers' compensation is one of the lines we already publish a use case for. What actually differs between the two is your configuration and which interfaces your team will open, not the shape of the integration.
Will this force changes to our ClaimsPro configuration?
It should not need to. Documents, activities and case information are already what ClaimsPro is made of, and Hesper adds nothing outside that vocabulary. Adding a field or a queue to make Hesper's output separately reportable is a common choice, but it is a reporting convenience and the integration does not rely on it. Because ClaimsPro is highly configurable, the mapping step is carrier-specific and we do it against your instance rather than a generic template.
Can Hesper pay, deny or close a claim on its own?
No. Payment release, reserve movement, denial, compensability and closure are all outside what Hesper may do, and on an indemnity claim that boundary is a statutory one rather than a product preference. Hesper produces evidence, findings and drafts, then routes an activity naming what it recommends. The adjuster or supervisor with the authority decides, and ClaimsPro records them as the decision-maker.
Do we have to automate the whole claims lifecycle to start?
No. A claim can be handed to Hesper at any point in its life, including one that has been open for months. ClaimsPro carriers most often start at the point where a file turns complex and gets routed to a senior adjuster, which is usually claim file review, and widen from there once the output has been checked against claims their own team already closed.
Other claims systems Hesper works beside
Book a demo on a ClaimsPro claim
Half an hour on your own lines and jurisdictions: what Hesper reads out of the case repository, what it files back, and which decisions never leave your adjusters.
Book a demo