臺灣的人口成長與老年人口增加，與壽命延長有很大的關系(現今社會醫(yī)療技術發(fā)達，使之人口壽命延長)，但是如果壽命的延長未能帶給老人較高的生活品質，反而因此纏綿病榻，因此除了關切經濟、人口的發(fā)展之外，給予老人福利與醫(yī)療問題也是未來所需重視的。隨著高齡化社會來臨，聘請看護或是送至安養(yǎng)中心與護理之家的老人將會逐漸增加，在醫(yī)院里的護理人員平日工作繁忙，又得長期專注工作，此時若能夠藉由一些技術設備(科技運用在醫(yī)療方面之成果)協(xié)助，才能有效的提升醫(yī)療品質。

本作品以針對醫(yī)院病房與護理中心管理自動化的概念來設計一款「點滴自動偵測控制盒與自動化管理??的系統(tǒng)」，本系統(tǒng)主要是利用「重力感測技術來偵測點滴」是否快沒有了以及「多重資料的確認」系統(tǒng)，再將此資訊經由異質通訊網路架構傳送至護理中心的管理伺服端，再經由警示系統(tǒng)通知醫(yī)護員人做點滴的更換，讓病患可以安心的修養(yǎng)，解決「不需擔心點滴是否會打錯以及點滴是否已打完等問題」。

研究動機

本作品創(chuàng)意構想來自于家人生病住院吊點滴時，每隔一段時間護理人員就需要巡房一次，當點滴快沒了，家屬又要提心吊膽擔心是否會有回血的問題，頻頻按緊急鈴催促護理師過來，為了解決此困擾，決定設計一款「點滴自動偵測盒及即時監(jiān)控系統(tǒng)」。

目前傳統(tǒng)所使用的都是一般的點滴架，每當有病患需要施打點滴護理人員就需要定時的做巡房的動作，且都是透過人力來確認點滴，此時卻無法100%掌握點滴是否為該給病患施打的點滴，近幾年常發(fā)生很多因為點滴打錯造成病患過世與點滴打完卻沒人理，造成點滴回血等情況。

工作原理

本系統(tǒng)采用盛群HT66F70A晶片并搭配其周邊IC，使用于各個點滴偵測盒上，并使用GPIO、INT、ADC、Timer、UART等功能來完成。系統(tǒng)采用三階段的資料傳遞模式，三個階段分別有三個不同的裝置，由低至高分別為前端的重力感測器及控制盒、中間的中繼站、后端的伺服介面。

在醫(yī)生看完診且認為病人有需要住院與施打點滴的必要性后，病人的個人資訊會完整建立于護理站的伺服電腦中，再由護理人員導引病患住進正確病房與病床。

在病床邊的點滴架上設置一個點滴偵測器跟重力感測器，當護理人員要幫病患施打點滴時，使用手機App軟體掃描病人QR code以及點滴瓶QR code，將兩筆資料傳送至醫(yī)護中心做資料比對，確定該點滴確實屬于醫(yī)師開給此病患的點滴處方箋后，護理人員便可以放心施打點滴。

重力感測器偵測點滴的余量，每五秒將點滴余量傳送至醫(yī)護中心做即時的監(jiān)測，當點滴余量??過低時，醫(yī)護中心就可以馬上加派護理人員前往更換點滴。

作品結構

系統(tǒng)架構模型

*子系統(tǒng)一架構模型：

使用HT66F70A微控制單晶片制作點滴偵測器。內部元件包括：HT66F70A微控制單晶片、ZigBee 2.4GHz無線通訊模組、Load cell重力感測器。

*子系統(tǒng)二架構模型：

中繼站以PXA300嵌入式平臺為主機。周邊元件包括:有線資料接收與發(fā)送、無線資料接收與發(fā)送,病患資料及點滴余量之顯示。

*子系統(tǒng)三架構模型：

伺服端以Windows作業(yè)系統(tǒng)的電腦為主架構，搭配使用者之智慧手機。支援Android系統(tǒng)與Wi-Fi無線網路通訊。

系統(tǒng)環(huán)境模型與架構

1.伺服端與中繼站之有線訊號傳輸流程

(1)伺服端將病患資訊于SQL server資料庫內儲存資料。

(2)以Ethernet有線網路架構將資料傳送至中繼站。

2.中繼站與點滴偵測器之無線訊號傳輸流程

(1)中繼站將伺服端傳送過來的資料做整理。

(2)確認封包無流失后將資料送至無線模組發(fā)送給點滴偵測器。

3.中繼站與點滴偵測器之無線訊號傳輸規(guī)則

每一筆資料傳送18個ASCLL字元，辨識點滴余量、點滴藥品、姓名、性別、病歷號、房碼，如圖1所示。

圖1 : ：通訊協(xié)定架構圖

系統(tǒng)元件間流程設計

系統(tǒng)元件根據系統(tǒng)控制流程分為四大點，其系統(tǒng)控制流程圖，如圖2所示。

*伺服端將儲存于醫(yī)院Data Base中之病患資料以Ethernet有線網路方式傳送至中繼站

1.提供中繼站顯示病患資料有助于心患家屬探病時可快速找到家屬所在之床位。

*伺服端與醫(yī)護人員手機APP軟體連線，并于伺服端內進行以下動作

1.接收資訊將于伺服端內資料庫之病人與點滴資訊進行比對。

2.將比對結果回傳至醫(yī)護人員手機APP軟體中顯示。

*中繼站接收點滴偵測器傳來的點滴資訊

1.將點滴余量顯示于中繼站螢幕上，如圖2所示

*伺服端將接收由中繼站傳回之點滴偵測器所偵測的點滴余量

1.顯示病患點滴余量。

2.掌握病患點滴之即時狀況。

圖2 : ：主系統(tǒng)控制流程圖

系統(tǒng)元件內設計-軟體架構與模組設計

*點滴偵測器元件內模組設計

點滴偵測器元件內各模組使用晶片運算資源的優(yōu)先權順序：(1) 抓取Load cell感測之類比訊號(2) 類比訊號轉換數位訊號(3) 無線資料傳送(4) 百分比LED燈號顯示。

*點滴偵測器元件流程設計

點滴偵測器采自動偵測系統(tǒng)運作，由Load cell重力感測器量測點滴重量，透過單晶片做內部ADC轉換，并亮起目前點滴余量百分比相對應之LED數量，最后并將訊號透過異質網路架構傳送至醫(yī)護中心，如圖3所示。

圖3 : ：點滴偵測器流程圖

*點滴偵測器內元件軟體架構設計

點滴偵測器使用的硬體、韌體、應用由下而上。如圖4其中硬體層面包括：HT66F70A微控制單晶片，LED，Load cell重力感測器，ZigBee無線模組。韌體層面包括：ADC撰寫、I/O撰寫、Timer撰寫及使用I/O模擬UART功能之撰寫。應用層面包括：重力感測，無線傳送。

圖4 : ：點滴偵測器模組架構圖

*中繼站元件內模組設計

中繼站元件內各模組片運算資源的優(yōu)先權順序：(1) 無線資料接收(2) 點滴資訊顯示(3) 有線資料傳送(4) 有線資料接收(5) 病患資訊顯示。

*中繼站元件流程設計

1.接收伺服端傳送的病患資料，顯示病患資料于螢幕上。

2.接收點滴偵測器傳送的點滴余量訊息，顯示點滴余量于螢幕上。

3.傳送點滴余量資訊給伺服端。

圖5 : ：中繼站控制流程圖

*中繼站內元件軟體架構設計

點滴偵測器使用的硬體、軟體、應用由下而上。其中硬體層面包括：PXA300嵌入式平臺、ZigBee無線模組、Ethernet乙太網路(如圖7所示)。軟體層面包括：Visual Studio 2005之撰寫。應用層面包括：觸控感測、無線資料接收、有線資料接收與傳送、資料管理。

圖6 : ：中繼站模組架構圖

圖7 : ：中繼站搭配Windows CE系統(tǒng)之實體圖

系統(tǒng)元件設計實作

系統(tǒng)設計元件根據表4之要點，分為五大部分。

1.病房端架構：

據圖3-9的控制概念圖來設計硬體電路(如圖10所示)，主要接收由護理站所傳送之病人姓名、性別、病床號、病房號、點滴成分、凈重與相對應之余絀量給控制晶片，并將點滴資訊以LED顯示，并將點滴偵測的結果回傳至護理站，并通知護理人員進行更換動作。

2.點滴偵測控制架構：

Load cell 重力感測器主要負責偵測點滴的重量，由于其電壓過于微小，因此在重力感測器上外接一電壓放大電路，將重力感測器的電壓放大至0V~3.3V 之間，并將其類比電壓透過類比數位轉換電路轉換成數位訊號再將其以LED上顯示，電路架構設計如圖8、圖9所示。

圖8 : ：點滴偵測系統(tǒng)概念圖

圖9 : ：點滴偵測控制概念圖

3.雙電源隔離設置：

如圖10電路所示，Load Cell Sensor的電源與類比輸出訊號需做雙電源隔離進行設計，采用差分類比訊號輸出轉至OPA小訊號放大電路進行訊號處理，前端經由不同uF電容進行雜訊濾波抑制，本電路Ripple抑制在約Vp-p 17mV以內，接至HT66F70A單晶片ADC Function 處理，透過HT66F70A單晶片韌體進行多次取樣及平均化處理，最后經由UART 架構連接Zigbee建構無線資料傳輸。至于實際吊掛點滴袋經由HT66F70A韌體設置LED依相對應重量值改變LED顯示數量，作為臨床醫(yī)護人員快速判斷點滴余量準位。

圖10 : ：點滴控制盒完整電路圖

4.無線傳輸設計：

目前業(yè)界產品近端網路最大宗的產品為使用藍牙無線，但于本系統(tǒng)需要做到1對多的無線拓樸資料傳遞，故藍牙現行技術最多只能做到1對7，無法同步發(fā)送超過1對7，另外仍有產品采用低頻RF傳送資料，但因低頻RF跳頻技術遠低于2.4GHz高頻，更容易受到相同頻道時之資料沖突問題，我們采用2.4GHz ZigBee系統(tǒng)，解決藍牙無法一對多的問題，ZigBee架構最多可做到連結1對65535的Device,并且可增設Router 角色做為中繼資料傳遞節(jié)點，可將資料傳遞的距離拉長，2.4GHz每秒可做1600次跳頻技術，也大大解決了低頻RF的問題。

5.QR code顯示與手機APP比對：

目前上面上的管理系統(tǒng)大多是以RFID的方式比對，雖然能減輕醫(yī)護人員的負擔，但因為采用RFID的方式其成本對醫(yī)院來說也成為一種負擔，因此，我們利用QR code的低成本、儲存字元高與抗污損程度高的特性，加上現今社會的智慧手機普及率接近于人手一機，故撰寫一手機APP透過掃描QR code的方式來進行比對，即可以達到一樣的效果卻能大幅度降低相關成本，進一步提高整體醫(yī)療品質。

測試方法

測試方式我們先以各部分進行單獨測試，單獨測試都Pass后再進行整合測試，并將測試結果以下表顯示，各系統(tǒng)測試方式如下：

1.ZigBee無線傳輸測試：

我們先以單一組ZigBee上電測試確認賜福有讀取到數值后逐漸擴充組數來測試是否有數據遺失的問題。

2.ZigBee無線模組連線距離測試：

我們測試溫度為室溫25°C，濕度為70%，將ZigBee以1m的距離開始并逐漸加1m的方式測試。

3.ADC的輸入信號測試：

我們分別準備不同重量的受測物，分別為47g、100g、250g、500g與2kg作測試并以示波器測量其數值并將其數值透過運算確認是否與受測物相同。

4.Timer韌體程式偵錯及測試：

以碼表計時實際動作時間是否預期的時間是否相同。

5.I/O模擬UART韌體程式偵錯及測試：

利用X CTU來接收MCU的UART所傳送過來的數值并判斷是否有遺失或錯誤產生

6.伺服端與中繼站之連線、傳送與接收測試：

將系統(tǒng)中繼與伺服連接,確認是否有連線問題產生

7.Android系統(tǒng)之手機APP功能測試：

執(zhí)行手機APP并確認是否能掃描QR code并能從中讀取其代碼。

8.手機APP與伺服端之連線、傳送與接收測試：

將系統(tǒng)連線至伺服端，測試是否有問題產生，并手動模擬輸入一個正確的代碼與錯誤的代碼，并將其代碼分別傳送至伺服端，確認伺服是否有接收到其資料。并在之后確認手機是否有接收到伺服端回傳的比對結果資訊。

9.Load cell落摔測試：

將load cell掛在點滴架上并以任何角度、固定力道的方式推倒后扶起并掛上重物測試是否與實際相同。

10.LM358放大器ripple校正測試：

在LM358的輸出上接陶瓷電容、電解電容與固態(tài)電容，以不同的排列組合方式接上并以示波器量測其波形并比較何種組合之雜訊ripple值為最小。

11.完整系統(tǒng)整合測試：

將系統(tǒng)完整整合之后依照流程完整操作一次，確認是否有問題產生。

結論

本系統(tǒng)使用上不分點滴瓶本身的外觀及重量即可透過HT66F70A單晶片設計精準推估點滴的余量，整體成本與電路設計效益非常高，操作簡易方便，減少護理人員的巡房次數及提升工作效率，對于病患與病患家屬而言更是一大保障。隨著高齡化的來臨近年政府極力提倡智慧醫(yī)療，各大科技廠也紛紛投入醫(yī)療研究，智慧醫(yī)療慢慢的成為臺灣科技業(yè)的熱門話題。醫(yī)學界人士認為，結合ICT科技帶來的智慧醫(yī)療，將為醫(yī)療領域帶來「正確性」，并「降低醫(yī)療糾紛」、「提升醫(yī)療品質」以科技提升病患照護品質。

(作者為圣約翰科技大學電機工程系徐椿梁教授及學生陳俊伯、何正德、吳翊安、林柏宏)

參考文獻

1.鐘啟仁，微處理機實習邁向AMA中級先進微控制器應用認證使用Holtek 8位元晶片。

2.Marvell PXA300使用手冊，華亨股份有限公司。

3.陳會安，Microsoft Visual Basic 2008資料庫程式設計范本教本。

4.蔡文龍、林義證、張志成、何嘉益，Visual C# 2012學習經典，2013。

5.張義和,主流電腦輔助電路設計Protel99se – 拼經濟板,2005。

6.孫宏明，Android 4.X 手機/平板電腦程式設計入門、應用到精通，2012。

7.IEEE 802.15.4 標準和ZigBee協(xié)定規(guī)范。 Microchip ZigBee-2006 Residential Stack Protocol

8.Jeong, JY, Lee, JW “ZigBee Device Access Control and Reliable Data Transmission in ZigBee Ba??sed Health Monitoring System”, Advanced Communication Technology, ICACT 10th International Conference on, Vol. 1, pp 795-797, 2008.

9.Peng Ran, Mao-sheng Sun, Yi Ming Zou, “ZigBee Routing Selection Strategy Based on Data Services and Energy-Balanced ZigBee Routing “, Services Computing, 2006. APSCC '06. IEEE Asia-Pacific Conference on, pp400-404 , 2006.