How it works
Replace phone calls with one HTTP request.
HBYS sends the request, Medonay evaluates the rules, the insurer is notified in real time. Every actor and every technical step is below.
What happens today
Private hospital pre-authorization in Türkiye still runs largely over the phone. The patient waits at the cashier while a staffer queues for an insurer operator.
Current flow
Hospital staff calls the insurer, reads the policy verbally, dictates each line item. Wait time typically 5-25 minutes.
Real cost
Patient experience friction, brand damage; 4-6 FTEs in a mid-size hospital tied to the phone; recurring monthly line-item deltas from verbal-transmission errors.
After Medonay
One synchronous API call, sub-second decision, automatic audit trail, HMAC-signed async webhook to the insurer. Milliseconds instead of minutes.
HBYS (Hospital Information System)
HBYS is the software platform that runs a hospital's administrative, financial and clinical operations end to end. Patient registration, outpatient, lab (LIS), radiology (RIS), pharmacy, billing and pre-authorization modules.
Türkiye has dozens of hospital information systems and each speaks its own format. None publishes public REST documentation; integration runs through an NDA, a PDF spec and a VPN test environment. So Medonay connects to each HBYS through its own adapter: adding a system is one file and one record, and the decision engine never changes.
Private health insurance pre-authorization
Pre-authorization = the insurer confirms, before service is delivered, that the service is in scope and at what coverage rate. Policy + coverage + waiting period + annual limit + plan rules are evaluated in sequence.
Most payers still run pre-authorization over SOAP/XML, a closed portal or a call center; a real-time, open API is the exception. Medonay connects to each payer through an adapter that speaks its format too.
Where Medonay stands today
The codebase ships a sample and a real HBYS adapter (FHIR R4-shaped) and only a mock insurance adapter. Thanks to the adapter pattern, adding a new vendor is one file + one DB row; the AdjudicationEngine never changes. The adapter schedule opens with the first real partner.
Scenario: 38-year-old Ahmet, lab + ECG
Nine steps for a single patient. Target latency: sub-second synchronous response to the hospital.
- 1
Outpatient registration
Reception enters Ahmet's national ID; HBYS knows he holds a supplementary health policy.
- 2
Doctor recommends
Internal medicine recommends two items: 901550 Complete blood count (70 TL), 902340 12-lead ECG (120 TL).
- 3
HBYS calls Medonay
The hospital's HBYS calls POST /v1/provision/request. X-API-Key in headers, patient policy + two items in the body. Payload in the hospital's own shape.
- 4
Adapter normalizes
That HBYS's adapter turns the request into Medonay's common shape. The raw national ID is SHA-256-hashed at this boundary; the service layer never sees plaintext.
- 5
Cross-insurer policy resolution
When the hospital payload carries 'patient.provider_code', Medonay queries only that insurer (hint fast-path). Otherwise it queries every active insurer in parallel. When two or more match (e.g. a patient holding both an employer group policy and one they bought themselves), Medonay refuses to pick: it returns 409 POLICY_SELECTION_REQUIRED with the candidate list. The hospital staff asks the patient which policy to use and resubmits with the same 'hbys_request_id' and 'provider_code' set; the original request transitions from 'awaiting_selection' to 'decided'. The system never makes a money-impacting choice on the patient's behalf.
- 6
Adjudication engine decides
For each item: category in scope? Policy active? Coverage lookup, waiting period, plan rules (DSL), per-item / sub-limit / annual limit clamps. Sequential and deterministic.
- 7
Persist + sync response
provision_decisions + items + outbound_webhook_deliveries written in one transaction. JSON returned to HBYS; measured p95 under 100 ms in production.
- 8
Async insurer notification
Worker pool picks up the queued webhook, POSTs to the insurer's URL with HMAC-SHA256 signature. On failure: 60s, 5m, 30m, 2h, 12h backoff. Eventually dead_letter.
- 9
Hospital prints the decision
Staff sees ✅ Approved on screen: which item at which rate, patient co-pay amount. Cashier calls the patient.
Technical architecture: a bird's-eye view
High-level flow plus the five principles that keep the system scalable.
Adapter pattern
Each HBYS and each insurer gets its own adapter file. New partner = 1 file + 1 DB row + 1 registry entry. Engine code never changes.
Pure adjudication engine
Same (request, policy) → same decision. No time.Now(), no DB writes, no outbound HTTP inside the engine. engine_version is stamped onto every decision; a past decision can be reproduced on the same version.
Cross-insurer policy resolution
The hospital does not need to know which insurer covers the patient; Medonay queries every active insurer in parallel. When two or more match (a patient with valid policies at multiple carriers: group + supplementary, or different hospital-aligned plans), Medonay does NOT silently pick: it returns 409 POLICY_SELECTION_REQUIRED with the candidates, the operator asks the patient, then resubmits with the same request id and the chosen 'provider_code'. The operator can also bypass this by sending the insurer code on the first request (hint fast-path). The system never makes a money-impacting choice for the patient.
Audit & rule_trace
Every state-changing call writes an audit_log row (append-only, regulator-facing). Every decision stores a rule_trace JSONB showing which rule fired in which order.
Security baseline
National ID SHA-256 + pepper, JWT (panel) + X-API-Key (HBYS), multi-tenant org_id scoping, HMAC webhook signatures, bcrypt cost 12, custom HTTP server timeouts + custom HTTP client.
Scale envelope
Each customer installation runs on its own database and is sized for that installation. Database connections are capped per installation, so a sudden load spike cannot exhaust the database. The decision itself takes milliseconds; end-to-end time depends on how fast the system on the other side answers. Target p95 under 1 second.
Ready to talk?
Whether you're on the hospital or insurer side, share your current integration state and we'll draft an adapter schedule together.