《台大药局领药号机制探讨讲解学习》由会员分享，可在线阅读，更多相关《台大药局领药号机制探讨讲解学习（23页珍藏版）》请在金锄头文库上搜索。
1、台大藥局領藥號機制探討,領藥號基本運作機制,診間開好藥單，傳送至藥局，得到領藥號，將領藥單印出，交予患者。 藥局得到藥單，將其給予藥台配藥，再依照領藥號配送至領藥窗口，請患者領藥。,藥局的配藥運作,一共九個藥台，編號AI，每個藥台各有一位藥劑師配藥 領藥窗口共有四個，編號14，1號窗口的領藥號在12000， 2號窗口的領藥號在20014000，以此類推。 而每個藥台各自有對應的領藥窗口，而這個藥台所配的藥單，其領藥號依其領藥窗口規則,藥局的配藥運作,基本上配藥工作，是以藥台為單位而分配的，而且以五張藥單為一梯次輪替。換言之，一個藥台配完了五張藥單，才換下一個藥台配藥。 即便藥台要停止工作時，亦
2、需配完五張藥單才能結束工作,藥台的工作交接,根據前述，藥局有工作時段，且因應時段有不同的排班人員，而在時段交接時，原時段的工作人員，即便在此時段內不用工作，亦須把五張藥單配滿才可結束工作。 此亦與先前所提過的規則相符,設計機制時的主要考量,工作平均分配 工作的分配必須完全符合公平原則，每個藥台配了五張藥單，便應該換下一個藥台工作 藥台狀態更動的時效性 藥台狀態是希望可以隨時更動，而更動後的生效時機卻需注意,架構圖,做法1,想法： 發放流水號來控制領藥號的正確性 從藥臺與窗口的狀態(Status) 來計算領藥號 處方流水號領藥號 & 藥臺的對應 如何確保Status的正確性？ 流水號的分割,做法
3、1所需,SeqNo：流水號 流水號範例：001 00001 每一筆領藥需求流水號加1 每一筆修改工作狀態流水號加10萬，以確認修改過藥局的工作狀態 getStatus：取得藥局工作狀態 setStatus：設定藥局工作狀態 getSeqNo：取得流水號 F ( SeqNo , getStatus )：運算出實際領藥號,做法1-內部運作方式,AP Server不斷地從DB Server取得流水號及藥局工作狀態，利用公式算出實際領藥號，之後將結果傳回診間及藥局 每當DB Server取得新的工作狀態時，就會將十萬位數加1，以確認工作狀態變更,做法1-診間取得藥號流程,診間發出領藥需求 DB Ser
4、ver將流水號加1 AP Server利用f函式運算出領藥號 回應診間實際領藥號，並到藥局發出配藥需求,示意圖,AP Server,AP Server,AP Server,DB Server,診間,藥局,傳回SeqNo,領藥號&藥台&窗口的結果傳回,If(SeqNo OK) F(SeqNo , Status) ElsegetStatus,SeqNo + 1,getStatus,getSeqNo,做法1-修改藥局工作狀態,從DB Server取得目前工作狀態表及流水號10萬位數的數目 Ex: 00300025，就是3 修改完後傳回DB Server，先比對流水號10萬位數的數目確認與修改的版本是
5、否相同 是：修改成功 否：拒絕要求，因為可能有其它電腦先行修改了，必需重新取得目前工作狀態後方得修改,示意圖,AP Server,AP Server,AP Server,DB Server,診間,藥局,getStatus,Status& 確認用SeqNo,SegNo:003 000025 最新的狀態處存在DB中,Status&確認用的SeqNo 傳到藥局,傳回變更好Status 確認用的SeqNo,If(確認用SeqNo OK) （setStatus , SeqNo + 1000000 ） Else 再將最新的Status送回藥局,setStatus,做法2,想法： 先把處方分配好再來等處方
6、用Database Server來儲存資料 預先分配好的處方-藥臺-領藥號 等處方產生之後，再從已分配好的表格中查詢,做法2內部運作方式,藥局先計算領藥號與流水號的對應，並寫入DB Server 當診間需要領藥號的時候，直接取得流水號，用流水號查詢領藥號,做法2診間取得藥號流程,診間發出領藥需求 DB Server將流水號加1 等待DB Server做完處理回傳，取得領藥號,做法2-藥局修改工作狀態(1),修改工作狀態的table後再update到DB Server Ex:,做法2-藥局修改工作狀態(2),藥局按照其工作狀態內容運算出領藥號 Ex:,示意圖,AP Server,AP Serve
7、r,AP Server,DB Server,診間,藥局,預先算好領藥號和 SeqNo的對應表,對應表儲存在 DB Server中,將SeqNo+1並且將對應的領藥號傳出,兩種作法的優缺點比較(1),做法1 需要的時候再算出號碼 對Status的修改可以馬上生效 可以允許來自不同電腦的修改 修改時可能會出現Starvation 必須確保 SetStatus 和 流水號+10萬 這兩個動作中間不被干擾 資料的流量無法確定，可能必須視情形調整資料的存放方式,兩種作法的優缺點比較(2),做法2 先算出對應來等處方產生 修改Status需要重新計算現有的表格 基本上只能讓一臺電腦做修改 不會有Starvation的問題 需要確保藥局和資料庫之間process的運作順序正確 人員的流動無法控制，可能造成 ”有藥沒人配” 或是 “有人沒藥配”,
