Announcements

In healthcare, a made-up answer isn't a harmless miss. It's a denied claim, a compliance flag, a patient waiting longer than they should.

So we built MedKong.ai alongside healthcare providers, operators and frontline revenue cycle teams, one module at a time, until there were eight.

Data in → MedKong → Decisions out.

---

What MedKong is (and isn't)

It's not a SaaS tool you log into. It's not a chatbot. MedKong is a kit of versioned modules: ontology objects, governed actions, functions, automations and operator workbenches. AKOS engineers deploy them into your Foundry environment, against the EHR, PM, clearinghouse and document systems you already run. Your team operates it, governs it and extends it. Your payer rules, reviewer roles and approval thresholds are configuration you own, not something we hard-code.

Every module does the first pass and shows its work: the evidence it used, the policy it cited, the inputs it's still missing. Then a named person makes the call. Nothing becomes operational truth without someone behind it.

Built for operators, by operators.

The 8 modules

Each module is deployable on its own, in any order. Each one answers a single operational question and hands structured context to the next, so the visit, documentation, codes, charges and payments stay linked to the same patient and encounter.

Pre-service

01. Prior Authorization

Is authorization required, what policy and documentation apply, and is the packet ready? The module checks the request against the policy stack (LCDs, NCDs and articles), cites what it found, lists missing inputs, and builds the documentation checklist and submission routing. If a run stops for missing documentation, it picks up from that checkpoint instead of starting over.

02. Eligibility & Benefits

Is the patient's coverage active, and what payer context governs the planned service? MEDKONG returns verified coverage, payer category and rank, any exceptions, and the follow-up still needed before the visit.

Mid-cycle

03. Charge Capture

Were all performed services captured from the encounter and turned into billable charges? Transcription stays linked to the encounter, alongside the CPT set, negotiated-price lookup and a running charge total.

04. Coding Review

Do the diagnosis and procedure codes reflect what was actually documented? Suggested codes arrive with the evidence from the note behind them. Coders approve, reject, or query the provider in a thread tied to the visit, and every decision is recorded.

05. Claim QA & Submission.

Is the whole claim record consistent and ready for the clearinghouse and payer? MedKong checks the full record before it leaves, so the team works from a scrubbed claim, corrected data, a submission timestamp and clearinghouse status in one place.

Post-service

06. Denials & Appeals

Why was the claim rejected or denied, what has to change, and what's the next recovery step? Each denial becomes a work item with the corrected record, supporting history, and resubmission or appeal status.

07. Payment Posting.

What was paid, by whom, by what method, and what balance remains? Payments post against the encounter with notes and an updated balance, so financial status is visible at the visit level.

08. AR Follow-up.

Which balances need attention, who owns them, and what happens next? A prioritized balance queue with activity notes, status and next-action visibility.

Audit and oversight, under every module.

Every MedKong module is built on the same four layers: an engine that prepares the work with its evidence, a workbench where an authorized person decides, governance that sets who can act and on what, and an audit record that keeps what happened.

That audit record isn't a report bolted on at the end. Source documentation, evidence, policy citations, the reasoning behind a suggestion, the alternatives that were rejected, the reviewer, the timestamp and every revision are kept as structured records. Once a person has reviewed a step, a machine rerun never overwrites it.

Why Foundry

Foundry gives each module the context, controls and operational backbone it needs to deliver consistent results. Source systems land once, with lineage and permissions carried everywhere downstream. Patients, encounters, codes, authorizations, claims and accounts live in one shared ontology that every module reads and writes. Sensitive edits run through governed actions with identity and time recorded, not direct writes.

It's also why MedKong can be deployed rather than rented. Every module is Foundry infrastructure, versioned and installed into your environment.

Already in production

MedKong is live in two multi-location provider deployments, where claims have reached a 94% first-pass acceptance rate. The same record, engines and governance also power MedKong for Medicare Administrative Contractors: a review system that turns a submitted prior authorization request into a structured, evidence-backed case across seven review gates, with the reviewer in control of every determination. It's pilot-ready today.

Start with the queue that hurts most

You don't have to deploy all eight. Start with one module, whether that's prior auth, coding or claim QA, then add the next on the same foundation without rebuilding it. Read more at medkong.ai or request a walkthrough of the kit.