Product preview · KunXi Medical LLM · Products
By design, these are not chatbots: each digital worker would plug into the systems of hospitals, pharma companies, insurers, pharmacies and families, act within its A0–A4 authority and hand back a result with an evidence chain. Below, a concept design of the planned first product’s in-hospital workspace (not a real product screen; simulated data).
Product previewKunXi Medical LLM is at the design and concept stage
This section describes what we plan to build and how we intend to do it — not finished products or results. Product forms, model sizes, technical approaches, features, interfaces, metrics, scenarios and timelines are design concepts that have not been built or validated; they may be adjusted or changed as development, validation and regulatory requirements evolve. Nothing here is a commitment, an offer or a claim of clinical effectiveness.
All rights reserved. No reposting, adaptation or commercial use without written permission.Read the copyright notice
Insurance risk by department (issues per 100 records)
HighMediumLow
Claim denials and deductions · monthly (CNY 10k)
Disease follow-up (this month)
Plans run after the attending doctor confirms them; abnormal values trigger reminders and, if needed, referral.
Agent activity (full audit trail)
NoticeThis module is a design concept, not yet built, and may change.
In the plan, each digital worker has a clear customer, a complete task, a step count and a deliverable. Compliance alerts and claim recommendations are A3 actions that need human approval.
Complete taskReads the record before discharge, checks it against 15,500 rules and verifies the DRG group
Planned outputCompliance alerts + fixes + evidence chain A3
Problem to solvePressure from insurance clawbacks and denials; manual self-checks miss issues
Complete taskAdmission to discharge: drafts notes, checks orders, codes, plans follow-up
Planned outputDraft notes, coding suggestions, follow-up plan
Problem to solveHeavy documentation load; coding errors
Complete taskCohort build → variable extraction → statistical analysis → bias assessment
Planned outputAn evidence pack a third party can re-run
Problem to solveScarce regulatory-grade evidence; long study cycles
Complete taskReads records and pre-existing conditions, checks terms and liability, recommends underwriting and claim decisions
Planned outputClaim recommendation + evidence chain A3
Problem to solveSlow manual claims; hard to price people with conditions
Complete taskReviews prescriptions, checks interactions and insurance rules
Planned outputReview opinion + full audit trail
Problem to solveToo few pharmacists; compliance pressure
Complete taskReads device and check-up data, assesses TCM constitution, writes a follow-up and care plan
Planned outputHealth report + follow-up plan + audit trail
Problem to solveDevice data nobody can read; services people don’t renew
Complete taskTracks blood pressure and glucose, reminds about medication, explains reports, escalates anomalies
Planned outputGoal: better control and follow-up completion
Problem to solveLow control rates in chronic disease; broken continuity of care
NoticeThis module is a design concept, not yet built, and may change.
By design, digital workers would take care of the repetitive reading, checking, verifying, drafting and scheduling, and hand anything that needs judgement to a person along with the evidence: doctors confirm orders and care, medical-records and insurance staff re-check coding and compliance, pharmacists confirm high-risk drugs, claims handlers sign off claims.
NoticeThis module is a design concept, not yet built, and may change.
Described as “current process – entry point – input – output – human review – exception handling – measurable value”. All of this is a product concept: screens and flow are concept illustrations and the metrics are designed acceptance targets; the product is still being designed, with no pilot or measured results yet.
Planned entry point: stop it beforehand
Today: found after the fact, recovered after the fact
| Stage | Insurance compliance & record QC agent (concept · on-premises) |
|---|---|
| Current process | After discharge, staff spot-check records and codes with low coverage; insurance audits find issues later, then deduct and claw back |
| Entry point | After the discharge summary, before the settlement list is uploaded; an A3 action: it only alerts, never edits the record or uploads on anyone’s behalf |
| Input | Clinical notes, orders, tests, front sheet, settlement list; 15,500 rules and the hospital’s own knowledge base |
| Output | List of suspected violations + suggested fixes + source evidence chain; DRG / DIP pre-grouping and coding suggestions |
| Human review | Ward doctor confirms changes → medical records / insurance office re-checks; every action logged and auditable |
| Exceptions | Low confidence or rule conflicts go to a person; model failures fall back to the rule engine; staged release, one-click rollback |
| Measurable value | Efficiency: QC time per record · quality: recall, false-alarm rate, coding agreement · operations: denials and deductions (patient outcomes are not a first-release claim) |
Inpatient records in secondary and tertiary hospitals; used by doctors, medical-records staff and the insurance office; no diagnostic or treatment decisions; doctors and the insurance office have the final say.
SourcesNational Healthcare Security Administration (15,500 rule points, 2025); flow and screens are KunXi illustrations (simulated data); metrics are acceptance targets, not measured results
Model family
NoticeThis module is a design concept, not yet built, and may change.
In the plan, one 320B medical model plans long tasks and acts as the teacher, distilled into three deployment tiers that reach further down by setting. Model sizes and tiers may change; the four launch gates are design metrics, each to be met by measurement before release.
| Deployment | 320BCloud flagship | 70BOn-premises | 32BAppliance | 7BEdge / offline |
|---|---|---|---|---|
| Deployment | Compute centre and provincial nodes, inside the authorised domain | Integrated compute-data-model stack / private deployment / dedicated data domain | Integrated stack / ready-to-run appliance, plug-and-play in hospital (target) | Runs offline, works on weak networks (target) |
| Reference hardware | From one 8-GPU node (FP8 weights ≈ 320 GB) | Virtual machine or one 8-GPU inference server (domestic accelerators optional) | 2–4 GPU appliance or virtual machine | Single-GPU industrial PC / edge device |
| Who it serves | Pharma, insurers, model licensees; teacher for the family | Insurance offices, medical-records departments and wards of tertiary hospitals | Secondary hospitals, medical alliances, check-up centres, pharmacy-chain HQs | Primary care, pharmacy stores, wearables and consumer devices |
| Typical tasks | 100-step task planning, RWE evidence packs, claim re-review | The planned first product (insurance compliance & record QC), inpatient journey | Record QC, prescription pre-review, report reading | Primary-care AI assistant, prescription review, on-device chronic care |
Four launch gates (design metrics, released after measurement)
320B medical continued pre-training + three-real reinforcement learning → distil 70B / 32B / 7B with specialty fine-tuning; about 0.8 trillion tokens for V1, targeting about 1.5 trillion after multi-domain federation (estimates); exam scores are a capability floor only, never evidence of clinical effectiveness.
SourcesHardware is a reference configuration; gates are design metrics, not measured results; training corpus figures are estimates
NoticeThis module is a design concept, not yet built, and may change.
By design, the planned first product would not depend on regional data authorisation: data would stay in the hospital and it would run on-premises.
Reference: one 8-GPU inference server; data never leaves the hospital
Goal: ready to run, plug-and-play in hospital
Goal: works on weak networks in primary care and stores
HIS / EMR / LIS / PACS / insurance settlement list
P95 ≤ 3 s per step (target)
Designed to fall back to the rule engine on failure; staged release, one-click rollback
Note: KunXi Medical LLM is a product preview at the design and concept stage. Unless a public study is cited, the products, capabilities, thresholds, metrics and timelines in this section are KunXi design targets, concepts or estimates — not achieved or measured results — and may change; product screens are concept illustrations with simulated data. By design, the agents only make suggestions; clinical decisions are made by doctors.
KunXi Medical LLM is at the design and concept stage. Hospitals, pharma companies, insurers, pharmacies and health-management providers who are interested are welcome to talk to us and assess data, workflow and the validation path together.
