Built by AKOS
Built on FoundryOntology-backed case objects, governed actions and full lineage — the infrastructure layer under every review gate.Human in the loopAudit trail per actionPolicy-aware findingsA review system, not an AI answer.
A purpose-built operational workbench for reviewing Medicare hospital outpatient prior authorization requests. Automated intake, eligibility and policy analysis, combined with a disciplined human-review process — reviewers receive a guided case, not a collection of files and reference tables.
Faster case preparation
Request, coverage, program, policy, diagnosis, modifier and documentation checks are assembled into one guided flow before a reviewer opens the case.
Consistent review
Every case follows the same P1–P7 decision framework and uses controlled status vocabularies, across reviewers and across contractors.
Evidence at the point of decision
Visit notes, attachments, HCPCS data, articles, LCDs, NCDs, coverage rules and modifier rules sit alongside the case. Nobody leaves the workspace.
Human authority by design
Reviewers verify or override every finding. Once a human has reviewed a step, a machine refresh never overwrites that decision.
Decision-ready output
The workflow proposes an outcome, issues the final decision, creates the UTN where applicable, generates the provider letter and locks the record.
Audit-ready case history
Findings, reasons, notes, timestamps, reviewer identity, evidence and policy quotations, overrides and final outputs are retained as structured data.
Nine gates from receipt to provider letter.
A case opens automatically on submission. Three intake gates screen it, four medical-review gates judge it, and the decision stage issues the outcome. An objection at intake routes straight to Decision — no medical review on a request that should never have reached one.
Receipt & case creation
Submission state, round, receipt channel, jurisdiction snapshot and timing. Opens the case, sets the decision clock, prepares P1–P3.
Reviewer controlOpen and prioritize the caseCompleteness
Required PAR elements and attached documentation — beneficiary, codes, units, DOS, facility, bill type, expedited flag, document counts.
Reviewer controlVerify, or mark incomplete with reasonEligibility
Original Medicare coverage on the date of service: named plan against all plans on file, coverage windows, payer rank, verification status.
Reviewer controlVerify, or rule out-of-scope / unknownProgram scope
HCPCS presence on the PA list, category effective dates and hospital outpatient bill type.
Reviewer controlVerify, change category, or mark PA not requiredGoverning policy
Category, state, MAC jurisdiction and DOS resolved to the coverage article, its version, and the linked LCD and NCD set.
Reviewer controlVerify, select an alternate stack, or record no articleDiagnosis coverage
ICD-10 against the article’s medical-necessity rule groups: covered and non-covered flags, closed-list behavior, quoted rule text.
Reviewer controlCovered, excluded, not covered, or unknownModifiers & attestation
Laterality, attesting clinician and the article’s published modifier requirements against the request facts.
Reviewer controlSatisfied, unverified, needs input, or conflictDocumentation
Every administrative and clinical requirement against the submitted evidence: one ledger row each, with finding, quote, source and policy text.
Reviewer controlVerify or correct every row, then save the headlineFinal decision
The judged board, standing objections, early-exit rules and prior response state — proposed as affirmed, non-affirmed or rejected.
Reviewer controlChoose the outcome and confirm the irreversible issueA reviewed objection at P1, P2 or P3 routes the case directly to Decision as a rejected intake request; the medical-review gates are skipped. A reviewed objection at P4–P7 completes medical review and proposes non-affirmed. Changing the category or governing policy upstream refreshes every dependent suggestion and returns previously verified downstream steps to review — human-overridden steps stay protected.
One interaction model across every gate.
A progressive P1–P7 rail with active, completed, locked and skipped states. The machine suggests a status, a reason and the detail behind it; the reviewer verifies or overrides. The panels below are the queue, two of the gates, and the decision stage.
The queue, by MAC.
Select a MAC and the dashboard shows the open workload: what is awaiting review, what is in review, what is past its decision clock, and how decisions have gone. Every row carries its round, channel, current gate and due date.
The MEDKONG MAC review workbench. Sample data.
MEDKONG for MACs is built on Palantir Foundry.
A MAC review has to survive an audit. Foundry is what turns request data, beneficiary coverage, the CMS and MAC policy corpus and clinical documents into one governed operational model — and what makes every machine suggestion inside the workflow traceable rather than plausible.
The MAC case and the documentation ledger are ontology objects. The gate reviews and the final decision are governed actions. Nothing here is a chatbot bolted onto a portal.
Case objects, not spreadsheets
The MAC case and each documentation-review row are typed objects. Every gate status, reason, detail, reviewer and timestamp is a field an auditor can query.
Automations open the case
A submission or resubmission opens the case, snapshots the jurisdiction, prepares P1–P3 and starts P4–P7 in the background. Live-monitored, retry-enabled.
Actions carry authority
Record step review, review a ledger row, issue the decision — each is a governed action with organization-based validation, so only authorized reviewers act.
Lineage from policy to letter
Article, LCD, NCD, rule rows, evidence quotes and the letter are linked objects. An audit walks backward from any determination to what it was based on.
Human authority is encoded into the product.
These are not policies layered on top of the software. They are how the case object, the review actions and the decision action behave.
Built for the people who own the review.
See the review board on a real case.
A walkthrough runs 45 minutes and follows one case from the queue to the issued letter. Tell us your jurisdiction and role and an AKOS - MEDKONG engineer will set it up.
What the walkthrough covers
- 01Select a MAC and open the live case queue
- 02Open a newly submitted case — P1–P3 already prepared at receipt
- 03Verify P1, walk P2 coverage windows and payer rank
- 04Change a category at P3 and watch dependent suggestions refresh
- 05Search and select the governing article at P4, with its LCD and NCD stack
- 06See which rule rows support the P5 and P6 findings
- 07Expand a P7 requirement: rationale, evidence quote, source, policy quote — then correct a row
- 08Read the judged board at Decision and why the outcome is proposed
- 09Issue the decision: UTN, itemized letter, PDF view, locked case
MEDKONG for MACs runs today in the MEDKONG prior authorization sandbox as a pilot-ready workflow. Source-system interfaces, production SLAs, retention, accessibility and security accreditation are confirmed during discovery and solution design.