台大药局领药号机制探讨..pptVIP

台大藥局領藥號機制探討 領藥號基本運作機制 診間開好藥單，傳送至藥局，得到領藥號，將領藥單印出，交予患者。 藥局得到藥單，將其給予藥台配藥，再依照領藥號配送至領藥窗口，請患者領藥。 藥局的配藥運作 一共九個藥台，編號A~I，每個藥台各有一位藥劑師配藥 領藥窗口共有四個，編號1~4，1號窗口的領藥號在1~2000， 2號窗口的領藥號在2001~4000，以此類推。 而每個藥台各自有對應的領藥窗口，而這個藥台所配的藥單，其領藥號依其領藥窗口規則 藥局的配藥運作 基本上配藥工作，是以藥台為單位而分配的，而且以五張藥單為一梯次輪替。換言之，一個藥台配完了五張藥單，才換下一個藥台配藥。 即便藥台要停止工作時，亦需配完五張藥單才能結束工作 藥局的工作時間 藥局的工作時間，總共有五個時段。但這些時段又可分為兩類，一為正常上班時段，一為值班時段。 藥局有紀錄所謂值班藥台，即是在值班時段工作的藥台，有的值班時段，有特殊規定，但亦不影響原來的輪班原則。 藥台的工作交接 根據前述，藥局有工作時段，且因應時段有不同的排班人員，而在時段交接時，原時段的工作人員，即便在此時段內不用工作，亦須把五張藥單配滿才可結束工作。 此亦與先前所提過的規則相符 設計機制時的主要考量 工作平均分配 工作的分配必須完全符合公平原則，每個藥台配了五張藥單，便應該換下一個藥台工作 藥台狀態更動的時效性 藥台狀態是希望可以隨時更動，而更動後的生效時機卻需注意 架構圖 做法1 想法： 發放流水號來控制領藥號的正確性 從藥臺與窗口的狀態(Status) 來計算領藥號 處方→流水號→領藥號 藥臺的對應 如何確保Status的正確性？ 流水號的分割 做法1所需 SeqNo：流水號 流水號範例：001 00001 每一筆領藥需求流水號加1 每一筆修改工作狀態流水號加10萬，以確認修改過藥局的工作狀態 getStatus：取得藥局工作狀態 setStatus：設定藥局工作狀態 getSeqNo：取得流水號 F ( SeqNo , getStatus )：運算出實際領藥號 做法1-內部運作方式 AP Server不斷地從DB Server取得流水號及藥局工作狀態，利用公式算出實際領藥號，之後將結果傳回診間及藥局 每當DB Server取得新的工作狀態時，就會將十萬位數加1，以確認工作狀態變更 做法1-診間取得藥號流程 診間發出領藥需求 DB Server將流水號加1 AP Server利用f函式運算出領藥號 回應診間實際領藥號，並到藥局發出配藥需求 示意圖 做法1-修改藥局工作狀態 從DB Server取得目前工作狀態表及流水號10萬位數的數目 Ex:就是3 修改完後傳回DB Server，先比對流水號10萬位數的數目確認與修改的版本是否相同 是：修改成功 否：拒絕要求，因為可能有其它電腦先行修改了，必需重新取得目前工作狀態後方得修改 示意圖 做法2 想法： 先把處方分配好再來等處方 用Database Server來儲存資料 預先分配好的處方-藥臺-領藥號 等處方產生之後，再從已分配好的表格中查詢 做法2內部運作方式 藥局先計算領藥號與流水號的對應，並寫入DB Server 當診間需要領藥號的時候，直接取得流水號，用流水號查詢領藥號 做法2診間取得藥號流程 診間發出領藥需求 DB Server將流水號加1 等待DB Server做完處理回傳，取得領藥號 做法2-藥局修改工作狀態(1) 修改工作狀態的table後再update到DB Server Ex: 做法2-藥局修改工作狀態(2) 藥局按照其工作狀態內容運算出領藥號 Ex: 示意圖 兩種作法的優缺點比較(1) 做法1 – 需要的時候再算出號碼 對Status的修改可以馬上生效 可以允許來自不同電腦的修改 修改時可能會出現Starvation 必須確保 SetStatus 和 流水號+10萬 這兩個動作中間不被干擾 資料的流量無法確定，可能必須視情形調整資料的存放方式 兩種作法的優缺點比較(2) 做法2 – 先算出對應來等處方產生 修改Status需要重新計算現有的表格 基本上只能讓一臺電腦做修改 不會有Starvation的問題 需要確保藥局和資料庫之間process的運作順序正確 人員的流動無法控制，可能造成 ”有藥沒人配” 或是 “有人沒藥配” * * AP Server AP Server AP Server DB Server 診間 藥局 傳回SeqNo 領藥號藥台窗口的結果傳回 If(SeqNo OK) {F(SeqNo , Status)} Else{getStatus} SeqNo + 1 getStatus getSeqNo AP