Building a Medication Plan Workflow for HarmonyOS Intelligent Agents

Creating the Workflow

In the latest version of the Xiaoyi Open Platform, workflows, plugins, cards, and knowledge bases are placed in the Resource Library. Creating a new workflow yields a default start node and end node. The start node receives input; the end node outputs results. Between them, developers can add plugin, LLM, selector, and questioner nodes.

Getting Current Time

A "Get Current Time" plugin from the plugin market is added first. This is necessary because LLMs and plugins at runtime are affected by context and cannot guarantee accurate current time on every call. When users say "start today," "take tomorrow," or "until next Friday," an accurate current date is required to convert relative dates into concrete dates. The start node is connected to the time plugin, passing the user input to it. The plugin outputs the current date or time, which is then passed to the LLM along with the user input.

Using LLM to Extract Medication Information

After the time plugin, an LLM node is added to extract parameters from the user instruction. It receives two inputs: userInput from the start node and currentDate from the time plugin. The LLM extracts drug name, dose, unit, frequency, times, start date, end date, duration, and note. Output fields: name, dose, unit, frequency, times, startDateString, endDateString, duration, note.

The system prompt for this node is:

You are a medication information extraction assistant. Your task is to extract medication parameters from user input and output only valid JSON, no explanations, Markdown, or extra text.
You will receive two inputs:
-${currentDate}: current date or time, used as baseline for parsing relative dates like "today, tomorrow, day after tomorrow, this Friday, next Monday".
-${userInput}: user's natural language medication description.

Output JSON format must be strictly:
{
  "name": "",
  "dose": 0,
  "unit": "",
  "frequency": "",
  "times": [],
  "startDateString": "",
  "endDateString": "",
  "duration": 0,
  "note": ""
}

Field rules:
1. name: drug name, e.g., Aspirin, Ibuprofen, Amoxicillin. If not mentioned, return empty string.
2. dose: numeric part of each dose. "1 tablet" → 1, "two tablets" → 2, "5 ml" → 5. If not mentioned, return 0.
3. unit: dosage unit, e.g., tablet, grain, bag, ml, mg, g. Only extract unit following dose. If not mentioned, return empty string.
4. frequency: medication frequency. Must choose one from enum: ["每天", "每隔1天", "每隔2天", "每隔3天", "每隔4天", "每隔5天", "每隔6天", "每周", "每隔1周", "每隔2周", "每隔3周"]. Rules: "once daily, three times daily, daily, every day, morning and evening, after meals, once each morning noon evening" → "每天"; "every other day, once every two days" → "每隔1天"; "once every three days" → "每隔2天"; "once every four days" → "每隔3天"; "once a week, every Wednesday" → "每周"; if no match, return empty string.
5. times: array of dosing time points in ["HH:mm"] format. Explicit times take priority: "8 AM" → ["08:00"]; "9:30 PM" → ["21:30"]; "8 AM and 9 PM" → ["08:00", "21:00"]. Fuzzy times mapped to defaults: morning/breakfast → "08:00"; noon/lunch → "12:00"; afternoon → "15:00"; evening/dinner → "19:00"; bedtime → "22:00". Common expressions: "morning and evening" → ["08:00", "19:00"]; "morning noon evening, after three meals, after meals, three times daily" → ["08:00", "12:00", "19:00"]; "twice daily" unspecified → ["08:00", "19:00"]; "once daily" unspecified → ["08:00"]; if cannot infer → [].
6. startDateString: start date string yyyy-MM-dd. Only extract when user explicitly states start date: "from today", "start today", "start tomorrow", "start day after tomorrow", "start July 1", "start next Monday". Relative dates calculated from currentDate: "today" → currentDate; "tomorrow" → currentDate + 1 day; "day after tomorrow" → currentDate + 2 days; "this Friday" → Friday of current week; "next Monday" → Monday of next week. If not stated, return empty string. Do not infer start date just because user said "take for 3 days".
7. endDateString: end date string yyyy-MM-dd. Only extract when user explicitly states end date: "until tomorrow", "until day after tomorrow", "until Friday", "until July 10", "until next Monday". Relative dates calculated from currentDate. If not stated, return empty string. Do not calculate endDateString from duration unless user explicitly says "until, up to, until ...".
8. duration: treatment duration in days, numeric. Extract when user explicitly states duration: "take 3 days" → 3; "take five days" → 5; "take continuously 10 days" → 10; "take a week" → 7; "take two weeks" → 14; "take half month" → 15; "take a month" → 30. Note: "start today take 5 days" → startDateString today, duration 5, endDateString empty. "until tomorrow" → endDateString tomorrow, duration 0. If both end date and duration explicitly stated, prefer endDateString, duration can return user-stated days; if conflict, do not auto-correct, put raw conflict in note. If not stated, return 0.
9. note: remarks, e.g., "after meals", "before meals", "bedtime", "with meals", "doctor's orders", "when in pain", "as needed". If "after meals, before meals, bedtime" already used to infer times, can still keep in note. If none, return empty string.
Other requirements: only output JSON; no explanatory text; JSON strings use double quotes; dose and duration must be numbers; times must be string array; uncertain fields return default empty values, do not fabricate.

This LLM node performs an initial full extraction. If the user provides complete information in one sentence, later steps can skip re-prompting; if information is missing, the flow proceeds to judgment and prompting nodes.

Iterative Judgment and Prompting for Missing Information

Users rarely provide all medication details at once. For example, a user may only say "Add Aspirin" without dose, timing, or start date. The workflow must judge each extracted field. First, a selector node checks the drug name. If name is empty, a questioner node asks the user which drug to add. The user's reply goes to another LLM node to extract the drug name. If name is not empty, the flow proceeds to the next field. The same pattern repeats for dose, unit, times, frequency, start date, and end method.

Only parameters required for plugin execution need prompting. Non-essential fields like notes can use defaults if not provided, avoiding excessive dialogue that would make the process tedious.

Using Fixed Options for Medication Frequency

Frequency handling differs because the plugin only accepts fixed enum values, not free-form input. Instead of natural language, the questioner presents fixed options: "每天" (daily), "每周" (weekly), "每隔1天" (every other day), etc. The user selects from these, eliminating manual input and preventing LLM extraction mismatches with plugin requirements.

Each option in the questioner must connect to the next node; unconnected options cause workflow test-run errors.

Invoking the Add Medication Plan Plugin

After all necessary information is extracted and supplemented, parameters (drug name, dose, times, frequency, start date) are passed to the Add Medication Plan plugin. The plugin's input and output parameters are shown in the screenshot. When configuring, data types must match: dose and duration as numbers, times as string array, dates as specifically formatted strings. The preceding extraction, judgment, and prompting steps aim to ensure parameters are complete and valid, reducing plugin call failures.

Handling On-Device Plugin Call Failures

The plugin used is an on-device plugin dependent on an installed app. If the app is missing or version incompatible, the plugin may error. A subsequent LLM node analyzes the plugin's return. On success, it informs the user the plan was added. On error, it provides actionable guidance: install the app, upgrade the version, or check device support.

This ensures the workflow returns user-friendly results regardless of plugin success or failure, rather than exposing raw error messages. Compared to direct plugin calls, the workflow sequences parameter extraction, prompting, relative date conversion, fixed-option constraints, and error handling in a deterministic order, making the medication plan addition more stable and aligned with natural language interaction habits.