前言
在住院病房的日常運作中，醫囑（Doctor's Order）是驅動所有臨床處置的火車頭。從主治醫師在診間或電腦前敲下鍵盤開立處方，到藥劑部審核、調劑、發藥，再到護理師推著工作車走入病房執行給藥，這條「醫囑生命週期」串接了多個跨專業部門。

在紙本時代或早期系統中，醫囑常以醫護人員熟悉的拉丁文縮寫呈現，例如：

Amoxicillin 500mg PO TID pc x 7 days

這串文字對資深護理師而言一眼能看懂（口服 Amoxicillin 500毫克、每日三次、三餐飯後、連續服用 7 天）。但如果要在現代行動護理系統（NIS）中自動產出「今日各時段應發藥物清單」，並在護理師掃描條碼時進行毫秒級的「三讀五對」比對，純文字描述就必須全面轉化為嚴謹的結構化資料模型。

今天我們將深入探討 HL7 FHIR 中專門代表用藥處方的 MedicationRequest Resource，並使用 TypeScript 實作能將臨床給藥頻率代碼精確轉換為發藥時間軸的排程演算法。

一、醫囑處方核心：MedicationRequest Resource 深度剖析
MedicationRequest 代表開立給病患的藥物供應或施打指示。

1. 狀態生命週期（Status Lifecycle）
   在臨床流轉中，status 欄位遵循明確的狀態機：
   -draft：醫師仍在草擬或尚未簽章的處方。
   -active：處方已簽章生效，藥局審核完成，護理人員可依排程領藥與施打。
   -on-hold：因病患病情突發變化（如突發過敏反應或準備緊急手術）而暫停給藥。
   -completed：完整療程執行完畢，或已達開立天數上限。
   -stopped：醫師提早中止醫囑（DC, Discontinue）。
   -entered-in-error：人為開錯（例如點錯病人），廢止該筆醫囑。

2. 核心架構區塊
   一個完整的 MedicationRequest 由四個關鍵區塊構成：
   (1.)藥物本體識別 (medicationCodeableConcept 或 medicationReference)：指涉具體藥品代碼（如健保代碼、RxNorm 或 SNOMED CT）。
   (2.)臨床關聯 (subject & encounter)：綁定受藥病人（Patient）與當次就醫案號（Encounter）。
   (3.)劑量與途徑 (dosageInstruction[].route & doseAndRate)：定義給藥途徑（口服 PO、靜脈注射 IV）與單次劑量。
   (4.)時序與頻率 (dosageInstruction[].timing)：定義給藥的週期、頻率與臨床事件關聯（如飯前、睡前）。

二、符合臨床實務的標準 MedicationRequest JSON 範例
以下展示一筆標準抗生素醫囑，完整包含口服途徑、500mg 劑量與每日三次飯後（TID pc）的標準規範：
三、常見臨床給藥頻率代碼字典
在醫院護理常規中，不同頻率代碼會直接對應到護理站的固定給藥槽位時間（Standard Medication Administration Times）：
四、演算法實作：頻率代碼轉每日排程時間軸
NIS 前端介面需要知道「今天白班（08:00~16:00）有哪些藥要發」。後端必須將 MedicationRequest 中的頻率代碼與開立日期展開為一組具體的時間戳記清單。

以下使用 TypeScript 實作核心展開排程器：
五、臨床異常情境防呆原則
在醫囑流轉資料結構中，有兩類常造成醫療糾紛的高風險場景，系統必須在資料層給予明確定義：
1.STAT（急用 / 立即給藥）：
-此類醫囑不套用每日定時排程。其 authoredOn 即為排程起點，系統應在行動端發出高優先級通知，逾 15 分鐘未完成即標記為異常延誤。
2.重複用藥檢核（Therapeutic Duplication）：
-當醫師新開立一筆 MedicationRequest 時，後端 API 必須自動檢索該病患當前處於 active 狀態的處方，若發現同成分或同藥理機轉之藥物（例如同時開立了兩種 NSAID 止痛藥），必須回傳衝突警訊。

小結
今天我們解鎖了智慧用藥管理最核心的資料骨幹：
1.深入剖析了 MedicationRequest 的生命週期狀態機與標準 JSON 結構。
2.掌握了臨床常見拉丁頻率代碼（QD、TID、Q4H、PRN）與標準院內給藥槽位的映射關係。
3.實作了 TypeScript 排程演算法，將靜態醫囑展開為每日各時段的給藥時間軸與超時（OVERDUE）判斷邏輯。

擁有了結構化的用藥排程與時間窗口後，明天 Day 13 我們將迎來模組二的最高潮：三讀五對與條碼核對機制——臨床給藥防錯的資料流與狀態轉換實踐！