Different Scenarios Need Different Data · The Five Classes of Fuel

The first five chapters covered concepts, dimensions, methodology. This chapter answers the question every audience cares about most:

“What data should our hospital / our firm actually build?”

I use one classification framework — five classes, sorted by the core fuel type of the AI application:

Class	Core fuel	Tech stack	Training required?
A. Knowledge	Structured knowledge base	RAG + knowledge graph	No training
B. Data	Large-scale annotated training set	Supervised learning / fine-tuning	Retraining
C. Reasoning	Expert reasoning chains + full care episode	RLHF + reasoning models	Reasoning-chain production
D. Workflow / Agentic	Tool APIs + context + feedback	Agent framework	Flywheel loop
E. Embodied	Multimodal + action trajectories + simulation	VLA / world models	Real-robot + simulation

The killer one-liners up front:

Plenty of hospitals spend big governing data in the age of AI, only to find that 80% of their use cases don’t eat training data — they eat the knowledge base.

First figure out whether your AI eats knowledge, data, reasoning chains, workflows, or embodied trajectories. Then talk about how to build.

A. Knowledge applications (the most overlooked)

Medical examples:

• Insurance-policy Q&A assistant (DRG/DIP policy, reimbursement rules)
• Clinical guideline retrieval (NCN/CSCO/Chinese Medical Association guidelines)
• Rational-medication decision support (drug labels, contraindications)
• Hospital SOP / protocol assistant
• Contract / legal compliance review
• HR / finance / admin office assistant

Data needs: authoritative sources + currency + version lineage + structured chunking + retrieval metadata Governance focus: knowledge-engineering methodology (not data governance!) Mapping to the 9 dimensions: chiefly completeness, consistency, compliance & lineage

⚠️ Key insight: these apps require no training. The work is knowledge engineering, not data engineering. This is the truth about 80% of a hospital’s AI use cases.

Legal mapping: 80% of legal AI is knowledge-type too — retrieving statutes, precedents, contract clauses, compliance regulations. The share is even higher than in medicine.

B. Data applications

Medical examples:

• Imaging-assisted diagnosis (lung nodules, breast cancer, diabetic retinopathy screening)
• Pathology AI (digital slide recognition)
• ECG / ultrasound / dermoscopy
• Disease risk prediction, intelligent DRG grouping, AI medical-record front-page QC

Data needs: massive samples + multi-expert consensus annotation + diversity + rigorous evaluation sets Governance focus: annotation platform + expert-consensus mechanism + multi-center data pooling + tiered evaluation Mapping to the 9 dimensions: chiefly annotation quality, representativeness, lineage

Legal mapping: contract review, intelligent document audit, case-outcome prediction, sentencing assistance — textbook data-type AI (Harvey AI, Tongyi Farui, and Faxingbao all walk this road).

C. Reasoning applications (the killer app of 2026)

Medical examples:

• Differential-diagnosis agents (the MDT assistant for hard cases)
• Clinical decision support (CDSS) upgraded from rule-based to reasoning-based
• Intelligent authoring of complex medical records
• TCM syndrome-differentiation agents

Data needs: a complete diagnosis-and-treatment loop + expert reasoning paths + the differential-diagnosis process + outcome feedback Governance focus: upgrade from the “structured medical record” to the “reasoning-chain medical record” — add a mandatory “differential reasoning” field to record templates Mapping to the 9 dimensions: chiefly knowledge density, longitudinal completeness, integration

⚠️ Key insight: this kind of data barely exists in your stock — you have to produce it deliberately. You can’t mine it out of historical records, because traditional records don’t capture the differential reasoning.

Legal mapping: the “grounds for the ruling” in a judgment is law’s natural edge over medicine — a judge writing a judgment must lay out the reasoning, and the national judgment database is the world’s largest gold mine of legal reasoning chains. Turing Yitian is the benchmark case in this class.

D. Workflow / Agentic applications

Medical examples:

• Patient-operations / health-management agents
• Physician-workstation agents (intelligent record writing, order entry, prescription review)
• Group operations-cockpit agents
• A digital “external brain” for the CTO / executive
• Internet-hospital AI intake
• Infection-control / QC agents

Data needs: enterprise master patient index (EMPI) + 360° profile + tool-API orchestration + callable knowledge base + interaction-log feedback Governance focus: identity unification + profile completeness + API/MCP interface standards + privacy boundaries + flywheel loop Mapping to the 9 dimensions: integration, compliance, longitudinal completeness — plus a new one: interaction lineage

Legal mapping: legal agents (GC AI, Lüxing, Xinghan Legal Agent), end-to-end in-firm agents, the corporate “virtual legal department” — McKinsey’s Agentic Organization predicts the future legal department = 2–5 lawyers + 50–100 agents.

E. Embodied applications

Medical examples:

• Surgical robots (laparoscopic / interventional / orthopedic)
• Rehabilitation robots (upper- and lower-limb exoskeletons, neuro-rehab)
• Nursing robots (turning, transferring, medication delivery)
• Hospital logistics / drug / specimen-delivery robots
• Remote emergency-response / rounding robots

Data needs:

• Synchronized multimodal streams: vision + force + touch + IMU
• The VLA triple: visual state + natural-language instruction + action trajectory
• Expert demonstration data (physicians in motion-capture rigs)
• Physics-simulation synthetic data (digital-twin operating rooms)
• Failure-recovery trajectories (how a robot rights itself after an error — extremely scarce)

⚠️ Key insight: no single hospital can build this data alone — you must co-develop it with robotics vendors.

Legal mapping: embodied legal AI is rare, but courtroom-audio transcription, AI courtroom assistance, and AI legal KIOSK terminals show the early embryo of it.

The truth: real products are almost always hybrids

Hybrids are the norm; the single-class view is a teaching simplification:

• Imaging AI in clinical deployment = data (detection) + knowledge (diagnostic criteria / report templates) + reasoning (multi-lesion correlation)
• Patient agent = workflow (orchestration) + knowledge (health knowledge base) + data (personal profile)
• DRG assistant = data (grouping model) + knowledge (DRG coding rules) + workflow (embedded in the record front page)

The key to hybrids is architectural layering: the knowledge base belongs to knowledge management, the dataset to data governance, the workflow to the agent platform. Plenty of hospitals fail by cramming everything into the data platform.

Recommended build priority

By the logic of a “tech-driven healthcare group”:

1. Knowledge first (lowest barrier, fastest ROI): insurance policy, compliance, SOPs, clinical guidelines — results in three months
2. Data: pick two spearheads: an imaging-sharing center + DRG/insurance intelligence
3. Workflow: pick one flagship case: a patient-operations agent (buy the app, build the data foundation)
4. Reasoning: the longest game: start accumulating from structured MDT recordings — 2–3 years to pay off
5. Embodied: co-develop: build it jointly with robotics vendors

This chapter’s one-liners

There is no “universal high-quality medical data” — only “high-quality medical data matched to a scenario.”

First decide what the AI is meant to do. Then decide what data to build, and to what standard to govern it.

Next chapter: classification done — now, how do you produce these datasets? Knowledge engineering / the annotation pyramid / the reasoning-chain production line / flywheel engineering / embodied trajectories — one methodology per class.