So far in Flows, we've looked at the core APIs individually:
- Discovery finds coverage from minimal patient data
- Verification confirms eligibility and returns benefits
Now it's time to connect them - to move from isolated endpoints to a coordinated coverage flow.
This post walks through how to orchestrate Discovery → Verification, a pattern that automates one of the most common manual steps in healthcare intake: finding coverage and immediately confirming eligibility.
Why Orchestration Matters
Each of Sohar's APIs is powerful on its own, but their true strength comes from chaining them together. By linking Discovery and Verification, healthcare organisations can deliver the kind of fast, efficient experience that modern consumers expect everywhere else in their lives.
Instead of re-entering insurance details or waiting for staff to confirm coverage, a patient's basic demographics can flow seamlessly into verified eligibility within seconds. Behind the scenes, this orchestration also builds resilience - handling partial matches, retries, and fallbacks automatically - ensuring a consistent, reliable intake process.
How the Flow Works
To make this orchestration more representative of real-world workflows, we're introducing two new concepts: decision nodes and callbacks. Decision nodes represent points in the flow where logic branches - for example, whether to proceed automatically or pause for review based on the API response.
Callbacks occur when additional input is required to move forward, such as when a Discovery fails and the payer or member ID must be supplied manually before Verification can continue. These additions make the flow more dynamic and realistic, reflecting the kinds of conditional logic and human-in-the-loop steps that happen in production systems.
Determining Success
Whether a Discovery is considered "found" depends on both data completeness and business rules. At a minimum, a valid Discovery should return a payer ID and member ID - without those, the flow can't progress to Verification. But even when those identifiers are present, you may still apply lightweight logic to decide if the payer is acceptable. For example, some organisations exclude specific payer types such as Medicaid or out-of-network plans, to prevent downstream verification attempts that won't be actionable. This early filtering step ensures that only valid, billable coverages continue through the flow.
Callback
A callback represents a point in the flow where progress is paused because more information is needed before continuing. In this example, if Discovery fails to find coverage or returns a payer that isn't typically accepted - but the customer believes the patient does have another insurance - the workflow pauses.
At this point, the system requests additional input, such as having the patient or staff manually select the correct payer ID and member ID. Once that information is submitted, the callback resolves and the flow resumes from where it left off - continuing automatically into Verification. This pattern keeps the workflow stateful and resilient without forcing restarts or manual duplication.
Best Practices
- Use webhooks: Discovery is asynchronous; let your system react to completion events
- Timeouts: To prevent the patient from waiting too long, set a timeout for the initial Discovery response
Why It Matters
For developers, Discovery → Verification is the first real flow - a living example of how small, composable APIs can replace entire manual workflows. What once required staff to check payer portals now runs automatically within seconds. With this pattern in place, you can start layering in downstream logic like Network Status and Cost Estimate to complete the patient intake journey.