电子发烧友App
随着医院规模的逐渐扩大，医院的建筑结构越来越复杂。本文介绍的患者就医导引系统，以嵌入式SQL和有源RFID技术为基础，能够在患者就医的整个过程中提供就医路线的导引，使患者就医的体验更人性化，同时可以提高医生工作效率和各科室的协作化程度。现阶段综合性医院普遍使用的分诊叫号系统［1-2］只能对科室内部的就诊患者进行分流。
智能导医系统由导医终端（图1中终端控制核心、RFID阅读器和LCD显示器三部分）、局域网、服务器三部分组成。导医终端配置若干个，分别安放于医院走廊、过道、电梯、楼梯间等位置。整个系统的示意图如图1所示。
构建导医系统的关键在于导医终端的搭建和服务器上数据库的建立，而系统的网络则可以依靠医院原有的有线或无线局域网。就医导引系统（以下简称导医系统）的基本工作原理如下：
病人挂号时领取一张有源射频卡（阅读距离大于1 m），该卡周期性发射病人ID号。挂号的过程中，将病人ID号与所要就诊的科室等信息在数据库中进行关联。当病人行进到导医终端附近时，连接在导医终端的射频卡阅读器将接收到病人ID号。导医终端依据接收到的ID号发起数据库检索，检索出病人挂号时建立的数据库表项，如就诊科室等相关信息。最后，综合检索到的信息将就医导引信息显示在LCD屏幕上。
1 硬件平台构建
导医系统终端硬件平台包括四个主要部分：终端控制核心、RFID阅读器、LCD显示模块和电源。其硬件框图如图2所示。
终端控制核心采用广州友善之臂的mini6410开发板，处理器内核为ARM11。该处理器性能强劲，能处理较低分辨率的视频。如果每个导医系统终端控制核心都用PC机实现，虽然能够换取更高的性能，但意味着每个终端的制作成本将大大增加。这将导致医院的运作成本和患者就医成本增加。
导医终端采用台式PC用的普通17英寸LCD作为显示器，屏幕较大，用户体验良好。由于终端的控制核心只有并行的LCD数据线，所以需要LCD转VGA模块将视频信号转成VGA接口模式。这个模块采用的是友善之臂提供的方案。
RFID阅读器模块和病人携带的RFID标签是自行设计的一套有源RFID系统，阅读距离1 m~5 m可调。有源RFID阅读器与导医系统终端控制核心采用UART串口连接。
另外，直流电源采用普通的5 V开关电源。USB接口可以在单独调试每个导医终端上的程序时，外接USB键盘或鼠标。RJ45是外接网线的物理接口，每个终端通过这个接口获取患者的完整信息。目前市面上也有很多USB接口的无线网卡，也可以无线局域网的形式将导医终端连接到局域网。如果采用USB无线网卡的方式，则需要通过USB Hub来扩充核心控制板上的USB接口，并移植相应的驱动。
2 软件平台构建
导医终端的硬件平台建立后需要构建运行于其上的软件平台，作为上层应用程序运行的基础。由于导医终端采用ARM-Linux嵌入式系统设计，除了OEM厂商提供的软件包外，很多其他要用到的库都需要自己修改或移植［3-4］。
2.1 数据库访问
应用程序访问数据库的方式如图3所示。在ARM硬件平台、Linux操作系统下也不例外。
本文介绍的导医系统的数据库是用Microsoft SQL Server建立的。SQL Server（及SyBase）使用TDS（Tabular_
Data_Stream）作为其数据库现客户端传输的协议，它对应于图中的ODBC驱动。Linux下有此协议的免费版——freetds，将其移植到ARMLinux平台作为访问SQL Server的ODBC驱动。ODBC可以移植unixODBC和QT自带的ODBC库。
2.2 ODBC库及其驱动移植
系统中带有相应的ODBC驱动和ODBC库文件，是以ODBC方式在嵌入式系统中访问SQL数据库的必需条件。这些库和驱动可以通过下载相应软件包，经过交叉编译并拷贝到ARM-Linux平台相应目录来实现移植。而在交叉编译之前必须对其进行重新配置，否则无法生成合适的库或驱动。
2.2.1 unixODBC-2.2.12的交叉编译（arm体系）
配置选项如下：（--prefix选项指定把编译好的包释放到什么地方）
。/configure --host=arm-linux --prefix=/usr/local/arm/unixODBC-arm-iconv-2.2.12 --disable-gui --enable-iconv --enable-static
然后make & make install。
另外还要编译一个x86体系的unixODBC-2.2.12，因为交叉编译freetds-0.82时要用到。
2.2.2 unixODBC-2.2.12的x86体系编译
配置选项如下：（与上面不同的是去掉了--host=arm-linux 选项）
。/configure --prefix=/usr/local/arm/unixODBC-x86-2.2.12 --disable-gui --disable-iconv --enable-static
然后make & make install。
2.2.3 交叉编译freetds-0.82
配置选项如下：
。/configure --prefix=/usr/local/arm/freetds --with-tdsver=8.0 --disable-libiconv --host=arm-linux --with-unixodbc=/usr/local/arm/unixODBC-x86-2.2.12 --with-gnu-ld --enable-shared --enable-static --enable-msdblib --enable-dbmfix
将arm体系unixODBC目录下的库lib文件夹拷贝到x86体系unixODBC目录下，替换x86下的库，然后make & make install。
2.2.4 QT ODBC库的移植
如果需要在QT下直接通过ODBC方式访问SQL Server，则开发板中还必需含有QODBC，这需要在交叉编译QT4的库时候加上配置选项-qt-sql-odbc 或者如下配置：
。/configure -opensource -embedded arm -xplatform qws/linux-arm-g++ -no-webkit -qt-libtiff -qt-libmng -qt-mouse-tslib -qt-mouse-pc -no-mouse-linuxtp -iconv -qt-sql-odbc -I/usr/local/arm/unixODBC-x86-2.2.12/include -L/usr/local/arm/unixODBC-x86-2.2.12/lib
然后make & make install，再将新编译得到的lib目录下的 *Sql*文件拷贝到开发板下，替换原来的文件。如果配置时添加的是 -plugin-sql-odbc 选项，需要将plgins/Sqldrivers/目录下的所有文件拷贝到开发板相同目录下。
2.3 SQL Server数据库构建［5］
导医系统终端接收到病人ID号后将检索数据库。这个数据库的构建直接关系到给出的导医信息是否正确。试验阶段采用如图4的数据库结构。该数据库一共由5个表组成：（1）Patient表。记录病人姓名，将要前往就诊的科室等信息;（2）Department表。记录医院科室名称及所在物理位置等信息;（3）Terminal表。记录终端机IP地址及所在物理位置等信息;（4）Position表。表示综合终端机与科室相对位置关系，它的表项直接关系到导医终端给出的方向指引是否正确;（5）Information表。综合上述所有表给出导医所需的信息：病人姓名、将要去往的就诊科室和相对方向（将要去往就诊的科室的方向）。应用程序只要依据病人ID检索到information表即可获取就医导引所需的完整信息。
SQL Server数据库在试验阶段能够比较完整地实现系统功能，实际使用时需要依据每个医院的实际情况进行调整。导医系统应用于实际医院时可能需要另外构建一个数据库服务器，并与医院现有的HIS系统进行连接，以共享一套病人挂号科室等其他信息。
3 应用程序
导医终端上的应用程序采用QT4编程实现［6］。QT是一个基于C++的图形用户界面库。它的跨平台特性比较好，编辑好的程序代码几乎不需做修改就可以编译出运行于其他平台的可执行程序。应用程序的核心是检测串口接收缓冲区，当串口接收缓冲区存在有效的病人ID号，即依据该ID号发起一次数据库连接与检索。不同于普通PC环境，在ARMLinux平台下，需要解决三个核心问题：ARM-Linux下串口通信、汉字字符集兼容和SQL Server数据库连接等。
3.1 ARM-Linux下串口通信
QT下没有提供串口通信的控件，但是提供了第三方的串口通信类qextserialport。本系统即是采用该类完成了ARM-Linux下的串口通信。该类继承自QIODevice类，可分为Win_QextSerialPort和Posix_QextSerialPort，分别支持Windows和Linux两种环境下的编译。在Linux下需要添加 #define _TTY_POSIX_宏定义，以确保选择正确的条件编译。通过以下代码即可打开串口ttySAC3，并设置波特率为9 600 Kb/s，无流控制和奇偶校验， 8位数据位，1位停止位。
port=new Posix_QextSerialPort（“/dev/ttySAC3”，
QextSerialBase：：EventDriven）;
port-》setBaudRate（BAUD9600）;
port-》setFlowControl（FLOW_OFF）;
port-》setParity（PAR_NONE）;
port-》setDataBits（DATA_8）;
port-》setStopBits（STOP_1）;
3.2 字符集的转换
Linux系统下汉字一般采用Unicode编码，而Windows系统下汉字一般采用GBK编码。如果将检索的结果做了不正确的转化，则显示的汉字将出现乱码。这个问题可从以下两个方面来解决：
（1）移植freetds和unixODBC时，要将配置选项iconv设置为disable。具体来说，unixODBC的配置选项中一定要有--disable-iconv，freetds的配置选项中一定要有--disable-libiconv。这样做可以避免ODBC和ODBC驱动进行字符集的自动转换，从而避免出现无法预见的字符集不兼容问题。
（2）QT为世界上多数语系提供广泛支持。在编写QT程序时一定要在主程序中添加相关代码，定义好程序的字符编码类型。如果希望应用程序用UTF8编码，可以添加如下代码：
QTextCodec：：setCodecForLocale（QTextCodec：：codecForName
（“UTF8”））;
QTextCodec：：setCodecForCStrings（QTextCodec：：codecForName
（“UTF8”））;
QTextCodec：：setCodecForTr （QTextCodec：：codecForName
（“UTF8”））;
3.3 数据库的连接与检索
为了实现数据库的连接，需对freetds和unixODBC进行必要的配置。这可以通过修改freetds.conf文件、odbc.ini和odbcinst.ini文件来实现，这些文件分别在各自的安装目录下。有了unixODBC和freetds的支持，通过QT的ODBC库QODBC就可以访问Windows XP下的SQL Server数据库了。
QSqlDatabase db=QSqlDatabase：：addDatabase（“QODBC”）;
db.setDatabaseName（“dbHospital”）;
db.setUserName（QString（“BME”））;
db.setPassword（QString（“123456”））;
db.setConnectOptions（“SQL_ATTR_ODBC_VERSION=
SQL_OV_ODBC3”）;
由于QODBC会自动调用unixODBC和freetds的配置文件，所以不用调用setHostName（）函数单独设置数据主机名。实现了数据库的连接，数据库的检索就相对简单了。QSqlQuery提供了一套检索数据库的简单方式。
4 实验与讨论
经实验验证，该导医系统能够正确接收有源RFID标签发射的病人ID号，并以此发起数据库检索，检索得到病人就医的相关信息后在终端上显示导引信息。
该导医系统不仅可以完成就医导引的任务，还可以扩展其他功能。例如，可以修改终端程序，使系统空闲时插播药品广告，这可以进一步减小系统成本。
另外，可以修改导医系统终端上的应用程序，使RFID阅读器实现远程控制。例如远程控制阅读器的开启和关闭、增益设置等。实现方式是在导医终端的后台运行一个服务程序。该程序一直监听一个socket端口，当收到有效的RFID控制指令时，将该控制指令写入到UART发送缓冲区。RFID阅读器上的程序收到命令后将执行相关操作。
该智能导医系统整合了有源RFID技术、嵌入式系统和数据库等软硬件技术，能够为患者提供友好的就医导引信息，也可以间接为医院提供信息发布平台，有较好的实用价值。整个系统还处于试验、设计阶段，应用于实际还需要较长时间的完善与验证。后续的工作将集中于功能的整合、完善和储存导医信息数据库建设。
责任编辑：ct
工商网监
评论