システム研修会資料
目次
保険証のＱＲコード（２次元バーコード）読み取り対応 ２ アプリケーションにＱＲコードが渡るまでの流れ ３ バーコードリーダ以外での読み取り開発について ４ ｗｅｂカメラの選択 ５ 処方せんＱＲコード記載 ６ グループ診療対応 ８ グループ診療の管理 ９ データ参照保護 １０ テーブルスキーマ変更 １１ ＣＯＢＯＬプログラムの対応 １３ ユーザープログラムの修正 １５ ユーザー起動プログラム １５ プログラム更新 １６ マスタ更新 １６ 外部システム連携 １６ ＤＢ肥大化によるＤＢアクセススピード低下の改善対応 １７ ＵＳＢメモリー型 jma-receipt サーバ １８ Ｍｏｎｔｓｕｑｉのセキュリティ対応 ２１保険証のＱＲコード(２次元バーコード)読み取り対応
保険証に記載されたＱＲコード（２次元バーコード）の読み取り対応を行う。 二次元バーコードリーダ 価格は 7 万～15 万円 (一次元は 1 万円前後) インターフェイス USB-Serial 又はシリアル接続を想定している ※キーボードモードでは日本語に対応していないため使用できない Linux では usbserial.ko が USB シリアルドライバ /dev/ttyUSB0 でアクセスできる 自動認識しない場合は、VendorID 等を指定すると認識する場合がある # modprobe usbserial vendor=0x0536 product=0x028aアプリケーションにＱＲコードが渡るまでの流れ
1. QR コードリーダ -> glclient -> glserver -> アプリケーションプログラム glclient を拡張して、バーコードリーダを制御する(USB シリアルから読み取る) glserver aps glclient OR コードリーダー 2. QR コードリーダ -> QRclient(仮称) -> glserver -> アプリケーションプログラム glserver と会話できる QRclient(仮称)を常駐させておく glserver OR コードリーダー QRclient glserver と直接 会話 glclient apsバーコードリーダ以外での読み取り開発について
Web カメラ -> ソフトウェアデコード -> glclient ->(以下略) ソフトウェアデコードライブラリを開発中 libdecodeqr オフィシャルサイト: http://trac.koka-in.org/libdecodeqr ライセンス : LGPL カメラ制御、画像処理に Intel が開発したフリーなライブラリ(OpenCV)を利用 (http://sourceforge.net/projects/opencvlibrary/)Linux, Windows, MacOSX,その他...で使用可能 libdecodeqr で使用できるのは OpenCV 0.9.7 以上 現在 libdecodeqr には、 画像 -> 文字列 (simpletest) Web カメラ映像 -> 文字列(webcam) というサンプルが付属。 基本的にはこの webcam サンプル を改良して、バーコードリーダとして使用する。 (注意点)
Sarge の OpenCV のバージョンが 0.9.5 なので、Sarge パッケージでは動作しない。 Sarge で動作する OpenCV パッケージについては日医標準レセプトのパッケージとして 提供を行う。
web カメラの選択
Linux ではすべての Web カメラが動作するわけではないので、注意が必要。 Linux と Web カメラというページがよくまとまっている。 http://www.rmatsumoto.org/index.php?Linux%A4%C8Web%A5%AB%A5%E1%A5%E9 前ページにも書いてあるが、Web カメラの規格が決まった(UVC)ので、 比較的新しい Web カメラは個々にドライバを用意しなくても使用できるよう になってきている。 ただし、UVC ドライバはまだ自分でコンパイルが必要。 (http://linux-uvc.berlios.de/) (Etch ではソースモジュールとしてパッケージになっている)。 また ＱＲコードに向かない「web カメラ」もある。 ・無焦点 (接写に弱い) ・広角レンズ (端がゆがむ) web カメラ ＋ 追加レンズ によって改善する場合もある処方せん
QR コード記載
処方せんの余白にＱＲコードの記載を行う。 １ ＱＲコードのバージョン 処方せんデータ標準化インターフェース仕様バージョン２（JAHIS2）を採用する。 ２ ＱＲコード記載のスキーム /tmp/(session)qr.dat 処方せんに記載する内容 患者氏名、保険公費情報 処方内容、医薬品、服用方法 備考欄情報など QR 作成コマンド ③BLOB 埋め込み ①処方せんデータ作成 処方せんPG /tmp/(session)qr(n).png ①処方せん作成プログラムで「処方せんデータ標準化インターフェース仕様」に準拠したＣＳＶ形 式テキストファイルを作成する。②処方せん作成プログラムからＱＲコードイメージを作成するシェルを起動する。 ＱＲコードイメージを作成する外部コマンドを実行し、①で作成したＣＳＶ形式テキストファイ ルからＱＲコードイメージをファイル出力する。 ③処方せん作成プログラムで②で作成したＱＲコードイメージを取り込み処方せんフォームに埋 め込みを行う。 処方せんへのＱＲコード記載イメージ
グループ診療対応
本システムにおけるグループ診療機能について説明をする。 ・基本的な仕組みとして、一つのデータベース（orca）で各テーブルも一つ（tbl_ptinf 等)とし、 各テーブル内に医療機関を識別するＩＤを格納することにより実装する。 ・１システムで複数医療機関の運用が行えることを指す。 ・１システム内で複数医療機関のデータを管理する為、バッチ処理（レセプト処理）の同時 処理を可能とする。 システム概要図 ｏｒｃａ データベース Ａ医院クライアント Ｂ医院クライアント Ｃ医院クライアント 各テーブル内に医療機関識別用の 項目を付加 医療機関 サーバ 識別番号 患者ＩＤ 患者情報 1 00001 日医 一郎 1 00002 日医 二郎 1 00003 日医 三郎 2 00001 日医 四郎 2 00002 日医 五郎 3 00001 日医 六郎 患者情報テーブル(tbl_ptinf)の格納例 医療機関識別番号・・・１（Ａ医院） ２（Ｂ医院） ３（Ｃ医院）グループ診療の管理
グループ診療の設定をテーブルにより管理する。（管理用テーブルの新設） システム基本テーブル ： tbl_sysbase 管理項目 ・グループ番号 … テーブル管理上の番号（キー） ・医療機関識別番号 … 医療機関を識別する番号（hospnum と同期） ・医療機関識別名称 … テーブル管理上の便宜を図るための医療機関名称 ・運用期限 … 医療機関の運用を行う期限 ・本院分院グループ番号 … 本院分院のグループを管理する番号（システム内に複数の本院 分院の組合せを構築できるように考慮） ・本院分院区分 … 本院分院の関係がある場合に本院または分院を識別 ０：本院分院でない １：本院である ２：分院である グ ル ー プ 番号 医 療 機 関 識別番号 医療機関識別名称 運用期限 本院分院 グループ 本院分院区分 1 1 Ａ医院 99999999 0 0 2 2 Ｂ医院 20041231 0 0 3 3 Ｃ医院 99999999 1 1 (本院) 4 4 Ｃ医院 新宿分院 99999999 1 2 (分院) 5 5 Ｃ医院 赤坂分院 99999999 1 2 (分院) 6 6 Ｄ医院 99999999 2 1 (本院) 7 7 Ｄ医院分院 99999999 2 2 (分院) システム管理 １００１ 医療機関基本情報 医 療 機 関 識 別番号 管理番号 区分番号 有効期間 名称 医療機関番号 1 1001 * 0 – 9 Ａ医院 11111111 2 1001 * 0 – 9 Ｂ医院 2222222 3 1001 * 0 – 9 Ｃ医院 3333331 4 1001 * 0 – 9 Ｃ医院 新宿分院 3333332 5 1001 * 0 – 9 Ｃ医院 赤坂分院 3333333 6 1001 * 0 – 9 Ｄ医院 4444441 7 1001 * 0 – 9 Ｄ医院分院 4444442データ参照保護
医療機関のデータ参照における接続端末の識別は、以下の方法により行う。
ユーザーID 命名規約 … ユーザーID の先頭に医療機関識別番号を２桁で付ける。 例) 01user , 02user
glclient -user 01user -pass xxxxx panda:orca00
glserver wfc aps MCP-USER : 01user
glauth 01user:xxxxx OK?
SPA-HOSPNUM : 1 （医療機関識別番号：01 を参照する。） 殆どは単独運用と思われるので、現行通りのユーザーID でも問題なく運用が可能なようにする。 システム基本テーブル内にレコードが１件しか存在しない場合は、ユーザーID の先頭２桁のチ ェックおよび医療機関識別番号変換は行わず、無条件にシステム基本テーブルの医療機関識別番 号をSPA-HOSPNUM にセットする。 ※もともと数字２桁で始まるユーザーＩＤを作成していた場合は、見直すことを注意する。
テーブルスキーマ変更
テーブルスキーマは以下の変更を行う。
１．医療機関ID（hospid）列が存在する場合
hospid 列が存在するテーブルは、 hospid を hospnum へ変更する。
（例）患者番号 hospid ptnum kohid ptid hknid hospnum ptnum kohid ptid hknid ～ ～ (1) hospnum 列の追加（integer）
alter table tbl_ptnum add column hospnum integer ; (2) hospid 列の削除
alter table tbl_ptnum drop column hospid ;
※プライマリキー、インデックスでhospid 列を設定しているものは削除される。 (3) hospnum 列に初期値（1）をセット
update tbl_ptnum set hospnum = 1 ; (4) プライマリキーを作成
alter table tbl_ptnum add constraint tbl_ptnum_primary_key primary key (hospnum,ptid) ;
２．医療機関ID（hospid）列が存在しない場合 hospid 列が存在しないテーブルは、 hospnum を追加する。 （例）システム管理 kanricd styukymd ～ kbncd ～ kanricd kbncd styukymd edyukymd hospnum edyukymd (1) hospnum 列の追加（integer）
alter table tbl_syskanri add column hospnum integer ; (2) hospnum 列に初期値（1）をセット
update tbl_syskanri set hospnum = 1 ; (3) プライマリキーを削除
alter table tbl_syskanri drop constraint tbl_syskanri_primary_key ; (4) プライマリキーを作成
alter table tbl_syskanri add constraint tbl_syskanri_primary_key primary key (hospnum,kanricd,kbncd,styukymd,edyukymd) ;
【 ソースの修正 】
.db … hospid 削除 hospnum 追加 .INC … hospid 削除 hospnum 追加
COBOL プログラムの対応
COBOL プログラムでは以下の対応を行う。 １．COMMON-SPA に項目を追加する。 SPA-HOSPNUM PIC 9(2) この項目には、データ参照保護で説明したようにセッション開設時に医療機関識別番号がセット される。実際には、orca00 の ORCGM00 内でセットされる。 SPA-HOSPNUM にセットする値で適切でない場合は、初期値として１を設定する。 ２．テーブルアクセス部分のコーディング変更 医療機関識別番号を項 目にセットする行を挿 入する。 （例）システム管理の医療機関基本情報の取得 INITIALIZE SYS-1001-RECMOVE SPA-HOSPNUM TO SYS-1001-HOSPNUM MOVE “1001” TO SYS-1001-KANRICD MOVE “*” TO SYS-1001-KBNCD MOVE “DBSELECT” TO MCP-FUNC MOVE “tbl_syskanri” TO MCP-TABLE MOVE “key8” TO MCP-PATHNAME MOVE SYS-1001-REC TO MCPDATA-REC CALL “MONFUNC” USING
MCPAREA MCPDATA-REC ３．サブルーチン化 今後の改造要件に対応するため再度サブルーチン化を行うか検討する。 ※今後の改造要件とは、正規化、ＤＢ構造変更、過去データの追い出しなどがある。 MONFUNC ORCDBMAIN
ORCDBMAIN CALL “ORCDBSYSKANRI” CALL “ORCDBPTINF” CALL “ORCDBSRYACCT” CALL “ORCDBETC” ORCDBMAIN 内で HOSPNUM 項目が数値例外 あるいは０等不適切な値の場合 SPA-HOSPNUM より再セットを 行う。 テーブル分割 ： ： ORCDBPTINF ORCDBETC tbl_sryacct_parent tbl_sryacct_child ORCDBSRYACCT ORCDBSYSKANRI tbl_sryacct
ユーザープログラムの修正
ユーザーにより作成されたプログラムは、“COBOL プログラムの対応”による修正を行わなけれ ば動作しなくなる。暫定的な救済措置は、今後のためにも行わないことにする。 また医療機関別に請求書兼領収書などのカスタマイズプログラムが存在する場合は、プログラム名 を医療機関毎に別名にする必要がある。 Ａ医院 Ｂ医院 請求書プログラム 請求書プログラム ユーザカスタマイズプログラムの格納場所 /usr/lib/jma-receipt/site-lib 格納場所については今までと同様にする為、プログラム名が重複した場合 どちらかの医院のプログラムが無効となってしまうので注意する。 帳票のフォームＩＤについても同様である。ユーザー起動プログラム
ユーザー起動プログラムでは、システムからシェルスクリプトを起動する際に医療機関識別番号を パラメータとして渡すように変更する。 ユーザープログラム側では、パラメータにより通知された医療機関識別番号を使用しテーブルアク セスを行うようにソースを変更する。変更方法の詳細は“COBOL プログラムの対応”を確認の こと。プログラム更新
パッチプログラムの適用は、システム管理者のみが実行できるようにし、各医療機関のシステム管 理者権限では実行できないようにする。マスタ更新
マスタ更新は、各医療機関で随時実行する（現行通りとする）。外部システム連携
グループ診療でのCLAIM 接続による医療機関識別は以下のように mmlCm に施設 ID として 医療機関ID を設定することによりおこなう。<mmlCm:Id mmlCm:type="insurance" mmlCm:tableId="MML0027"> JPN000000000000
</mmlCm:Id>
またODBC 接続などにより外部から直接データベースにアクセスする場合は hospnum を 考慮したアクセス方式に変更することとする。
ＤＢ肥大化によるＤＢアクセススピード低下の改善対応
日医標準レセプトソフトはハードディスク容量に空き領域があれば過去データについて 制限無しで保存が可能な仕様となっているが、使用期間が長期に渡った場合はデータ量の 増加に伴い、オンライン業務及びレセプト処理等のバッチ業務について処理速度の低下を 招く要因となっている。これを改善する方法としてテーブルに記録されたデータのうち現在 参照することが殆どない過去データについては別テーブルに退避を行い、日レセの通常業務 で参照するデータ量をある程度一定に保つことで、処理コストの安定化を図ることとする。 又、各テーブルの正規化も参照、更新のレスポンスが得られるものについては随時行っていく。 ※現時点では、詳細な実装内容が決定していないため概念図のみを記述するにとどめる。 過去月データの退避処理 退避元テーブルと退避先テーブルのテーブル構造は同一のものとする 退避元テーブル 退避先テーブル 過去月データへのアクセス処理 ORCDBMAIN・・・グループ診療対応 ＤＢアクセスモジュール 通常業務 レセプト処理 退避元テーブル 退避先テーブル ORCDBMAIN ORCDBMAINUSB メモリー型 jma-receipt サーバ
○概要 USB メモリーに OS + システムを入れ、HDD にデータを置くことで、USB メモリの 入れ換えによってシステムの入れ換え(アップグレード)を実現する。 ・USB メモリ(2GB or 4GB、10MB/s 以上の速度) 市場価格では 5 千円～ 2 万円 ※USB メモリからブートできるマシンが望ましい(必須ではない)USB メモリは Linux ではハードディスクと同じ様にアクセスできる(sda,sdb...)
○ブート方法 1. BIOS の設定変更により USB メモリからブートする ※ USB メモリを挿してブートしないとメニューに表れない場合が多い ・HDD,CD-ROM,FDD の一覧に USB がある場合 USB メモリを上位(HDD より上)に持ってくる。 ・HDD として認識されている場合 HDD のメニューを出した後 USB メモリを上にする。 2. HDD の GRUB から起動する。
・USB から起動できない場合でも GRUB が USB メモリを認識出来ている場合は、 GRUB から起動させることができる。 大抵の場合は hd0 が HDD, hd1 が USB メモリと認識されるので、 root (hd1,0) として起動する。 起動できた場合は HDD の GRUB に USB メモリのエントリを追加する。 3. CD-ROM or FDD の GRUB から起動する。 ・HDD のブートメニューを変更したくない場合ときなどは、CD-ROM or FDD に GRUB を入れ、その GRUB から USB メモリを起動する。
4. HDD にコピーして起動する。 ・USB メモリが起動時に認識出来ない場合は USB メモリの内容をコピーして、 通常のデュアルブート状態にする(空きパーティションが必要)。 ○構成 USB メモリ →システム HDD → データ → swap → /home → 一部設定ファイル(機種固有の設定ファイル) ○/etc のファイルはバージョンアップによって書き換えられる場合もあるために、 そのまま使用できない。 ・USB メモリの /etc ・ハードディスク内の /etc は loopback ファイルシステムを使用して (例) HDD/usb_orca_sarge_etc.img をファイルシステムとしてマウントする。 ○USB メモリサーバによるセットアップ手順はこうなる(予定) 0. Debian システムが入った USB メモリを用意する 1. USB メモリでブートできるように BIOS の設定変更 2. ブート 3. GRUB の起動 -> 選択
4. X の自動認識 -> X の起動 (失敗した場合は手動) 5. ハードディスクの自動調査 6. データベースのセットアップ (dump からリストア等) (一部手動) 7. 設定ファイルの調整 (一部手動) 8. 起動
