Provisioning, sub-second instead of phone calls.

Yes. No HBYS vendor in Turkey publishes public REST documentation; integration always runs through an NDA, PDF docs and a VPN test environment. That is exactly why Medonay is built on the adapter pattern: one file normalises the vendor's own payload and the engine never changes.

No. If the insurer does not want to expose an API, the member list is bulk-imported into the panel as CSV; plans, coverages and rules are defined in the panel, and decisions come out of the same engine. Wiring their API later is simply one more adapter file.

No. Hospital staff can enter a request straight into the Medonay panel: nothing to install, no integration, no vendor to wait for. The web form takes the place of the phone call and the same engine answers. The HBYS integration follows later, when you are ready.

Decision production measures under 100 milliseconds p95 in production, against the in-platform adapter, from the moment the request is recorded to the moment the decision is stamped. When a decision requires a live query into a payer's own system, end-to-end time is dominated by how fast that system answers; the design target for the synchronous path is under three seconds.

No. An approval reserves the payer's share rather than spending it. The hospital then closes it as utilized if the care was delivered or void if it was not, and if neither is reported the reservation expires on its own after a configurable window (72 hours by default) and the amount returns to the available limit. Reserved money is not available to a second approval, so the same limit cannot be granted twice.

Medonay never picks one. It returns the candidate policies (payer, policy number, start date), the desk asks the patient which one to use today, and the same request continues with that choice. A corporate group policy and a personal one can genuinely be valid at the same time, and making no money-affecting decision on a silent assumption is a deliberate design choice.

Yes. With review mode on, approvals do not take effect immediately: they land in a review queue for the payer's own staff, and nothing is reserved against the limit until a person approves. It is a per-payer setting, so one payer can run fully automatic while another keeps a human in the loop.

Every decision is stored with its engine version, the input request and a full rule_trace. Which coverage, which rule and which limit fired can be read back step by step. The insurer can also cancel or correct a decision afterwards through an inbound webhook.

Nowhere in the clear. It is hashed with SHA-256 and a pepper at the adapter boundary; the database holds only the hash plus the last four digits for display. Plaintext never reaches logs, the audit trail or API responses.

Every row carries an organization id and every read and write is scoped by it in the data layer, not on the screen. An attempt to reach another tenant's record returns not-found rather than forbidden, so the existence of a record elsewhere cannot even be inferred. This isolation is tested per endpoint. If you need stronger separation than a shared database, a dedicated deployment with its own database is an option.

The cross-tenant views a platform administrator uses for support show patient identity masked, so routine support work sees commercial shape rather than identity. Revealing the identity behind a single decision is a separate, explicit action requiring a purpose from a closed list plus a reference, and it writes its own audit record. Every cross-tenant read writes an audit row as well.

What you receive as a customer is a dedicated installation carrying your data and nobody else's, running on our hosting provider's infrastructure in Turkiye: application, database and backups all stay in the country. Personal data does not leave it, so article 9 of the KVKK is not engaged for that installation and no standard contract has to be notified to the Board. The sub-processor list is short: the hosting provider, plus an email relay if one is configured, which can be your own SMTP server. This site is the exception: medonay.com is our own demonstration environment, running in Google Cloud europe-west1 (Belgium) and on Vercel, so a demo account's data is processed there.

No. At this stage there is no ISO 27001 certification, no SOC 2 report, no independent penetration test and no cyber liability policy, and none of them is claimed. Our data processing agreement lists only measures that are actually implemented. If your procurement process requires a certification, the right answer is a roadmap date rather than a claim.

There are three line items: setup, monthly maintenance per contracted insurer, and a per-provisioning fee. No packages, no volume tiers. Both recurring lines start at the first real provisioning; nothing is billed before that. Two inputs decide the quote: your monthly provisioning volume, and how many HBYS and insurer integrations you need.