Built by AKOS
Built on FoundryOntology-backed objects, governed actions and full lineage: the infrastructure layer under every module, deployed into your environment.Deployed as codeAudit trail per actionHuman in the loopInfrastructure you deploy. Not software you rent.
MEDKONG is delivered as versioned modules: ontology objects, governed actions, functions, automations and operator applications, built by AKOS on Palantir Foundry and deployed into your environment. Your organization runs it, governs it and changes it.
Deployed, not hosted
Each module lands in your environment as versioned infrastructure. Your data stays in your systems of record and lands once, with lineage. There is no MEDKONG tenant holding your records.
One record underneath
Patients, encounters, documentation, codes, authorizations, claims, payments and balances are objects every module reads and writes, not copies in module-specific silos.
Yours to extend
Add an object type, a governed action or a work queue. Encode your payer policies and reviewer roles. The kit is the starting point; the operating model is yours.
Start with one module
Deploy against the queue that hurts most, whether that is prior authorization, coding or claim QA, then add adjacent modules against the same foundation without rebuilding it.
Four layers on one governed record.
An engine that prepares the work with its evidence. A workbench where an authorized person decides. Governance that sets who may act and what a rerun may touch. An audit record that keeps what happened.
Eight modules. One revenue cycle.
Deployable independently, in any order. Each answers one operational question and hands structured context to the next. The visit, documentation, codes, charges and payments stay linked to the same patient and encounter.
Eligibility & Benefits
Is the patient’s coverage active, and what payer context governs the planned service?
Prior Authorization
Is authorization required, what policy and documentation apply, and is the packet ready?
Charge Capture
Were all performed services captured from the encounter and translated into billable charges?
Coding Review
Do the diagnosis and procedure codes accurately represent the documented encounter?
Claim QA & Submission
Is the entire claim record internally consistent and ready for the clearinghouse and payer?
Denials & Appeals
Why was the claim rejected or denied, what must change, and what is the next recovery action?
Payment Posting
What was paid, by whom, by what method, and what balance remains?
AR Follow-up
Which balances need intervention, who owns them, and what follow-up should happen next?
Payer APIs, EDI transactions, clearinghouse acknowledgments, ERA posting and collection workflows are scoped and integrated per deployment, not assumed.
See the provider workbenches →MEDKONG is built on Palantir Foundry.
Foundry is the substrate every module deploys onto: the governed data foundation, the ontology, the action framework and the lineage that make an AI decision inside a revenue workflow traceable rather than plausible.
It is also why the kit can be deployed rather than hosted. Modules are Foundry object types, actions, functions and applications, versioned and installed into your environment.
One governed data foundation
Source systems land once, with lineage and permissions carried through every downstream use.
A shared operational ontology
Patients, encounters, codes, authorizations, claims and accounts as objects every module reads and writes.
Governed actions, not direct writes
Approve, reject, query, edit billing, post payment: each is an authorized action type with identity and time recorded.
Auditability by construction
Every automated decision traceable to its inputs, its rule or model version, and its reviewer.
Your environment, your controls
Roles, permissions, retention and approval points are configured in the platform you already govern.
What you own, and what AKOS delivers.
MEDKONG is not a hosted tenant. It is deployed into your environment by AKOS engineers, module by module, and handed over as infrastructure your team operates.
Built for the provider side and the reviewer side.
The same record, engines and governance serve two very different desks: the provider organization preparing and defending a claim, and the Medicare Administrative Contractor reviewing a prior authorization request.
Bring modular AI to the revenue cycle.
A walkthrough runs 45 minutes: the workbenches running, the ontology behind them, and an honest scoping of what a first module would take in your environment.
The stack behind it
Built by AKOSIntegration, ontology, agents, applicationsBuilt on FoundryGoverned data, orchestration, full lineageDeployed module by module, into the systems you already run.