「ICTを活用した遠隔地からの死亡診断with看護師」制度?の中間まとめ

先日の学会にあわせて開催した研修セミナーでは厚生労働省のご担当者にお出でいただき、「ICTを活用した死亡診断に関わる看護師研修」制度について丁寧なご説明をいただきました。
その結果を私なりにまとめるとタイトルに示したような制度であることがよくわかりました。

講演の資料に加えて、ガイドライン自体も配布しましたので、参加者のみなさんも資料をよく読んで頂き、質疑もかなり活発に行われました。
ガイドラインへの質疑を大別すると、
「条件が厳しいので制度が利用できるのは離島などに限られそうだが、必要とされているのは特養などの施設など別の所ではないのか?」
「実施にあたっての費用が診療報酬等でカバーされるのか?必要な機器は誰が用意するのか?」
といった点であったかと思います。
座長をしていた私からも
「人的資源の乏しい離島の看護師が研修を受ける場合、代理の人員を用意するなどの手立てが必要ではないか?」や「除外基準に反して進めてしまった場合などの責任はどうなるのか」について質問をしました。

あくまでも私なりの理解ですが、厚生労働省の中でもこれらについてはかなり議論され、関係各所からの意見も踏まえた結果が今回のガイドラインといえるようです。まずはここから始めようということかと思いますが、今後の多死の状況を考えると、今回のような遠隔で医師が診断するのを看護師が補助するというスタイルではなく、医師との協働の下でトレーニングを受けた看護師が代理で死亡診断をするというスタイルにしないと対応できないのではないかと思われます。

今回のガイドラインに基いて行われる研修の募集も、全国訪問看護事業協会で始まっています。
今後も動きを見守っていきたいと思います。

RedisやAPCuがうまく効かない件

以前にowncloudを導入した際に、キャッシュの役割を果たすACPuやRedisを導入しました。

導入後、サイトの表示が早くなるなど効果があったのですが、サーバーの仕様なのかredis-serverが5日経過すると落ちてしまって、動作が不安定になるという現象が起きていました。またよくよく確認した所、APCuの導入はできていたのですが、実際にデータがキャッシュされていない事がわかり、その対応法もよくわからないままです。

そこでAPCuは使えそうにないので、Redisを使えるようにしようと思い、どうしようか思案しましたが、redisを一旦休止して再起動するスクリプトを作成して、cronで一日1回スクリプトを起動させるようにしてみました。

#!/bin/sh
redis-cli SHUTDOWN SAVE
redis-server /home/username/local/bin/redis/redis.conf &

SHUTDOWNを大文字で入力しなければいけないことに気がつくまで少し時間がかかりましたが、一応、このスクリプトで一度サーバーを落としてから再起動することをRedisのログで確認しました。これでうまくいくでしょうか。

追記
この方法はうまくいっているようです。
cronを1日1回ではなく、3日に一度にするようにしました。
redisが落ちているのかを確認する方法とかを調べていましたが、自分で落として再起動という案は素人なりに良いアイディアでした。

明日から在宅看護学会学術集会

明日から2日間、第7回日本在宅看護学会学術集会が甲府市の山梨県立大学で開催されます。

紅葉の季節ではありますが、ぜひご参加ください。

私が関わっているものは以下の内容になります。

「ICTを活用した死亡診断に関わる看護師研修」の研修を開催

11月25日、26日に山梨県立大学で開催される第7回日本在宅看護学会学術集会の会期中に、学会の研修委員会企画として研修セミナー「多死時代を支える看護師の役割 ~ICTを活用した死亡診断の理解・普及に向けて~」を開催します。

このブログでも何回か取り上げた、離島やへき地において、医師が不在の場合に看護師がICTを用いて医師と連絡を取り合い死亡診断を補助する制度が動き出しますが、現時点では厚生労働省のホームページでもガイドライン以外の詳細な情報は掲載されておりません。本研修ではこの制度を所管する厚生労働省医政局看護課サービス推進室から講師をお招きして講演をしていただいたうえで、質疑応答を予定しており、おそらく会場には研修を開催する団体の関係者なども参加すると思われるので、具体的かつ詳細な情報を得る貴重な機会となると思います。 ちなみに私が座長をします。

参加費等の詳細については、PDFファイルをごらんください。

2017日本在宅看護学会セミナーご案内 (PDF)

サイトのメンテナンス

近医で胃薬を処方してもらおうと思っていたら、今日は休日…。ということで、ちょっとサイトのメンテナンスをしました。

ownCloudは導入直後はファイルの転送が多くなるため、サーバーには負荷をかけているようですが、動作自体は順調で便利です。来週からはノートPCをあまり持ち運ばなくて良い生活にしようと思います。

一応、セキュリティを考慮してSSLを導入しようと思っていたのですが、レンタルサーバーの方で、共有SSLという形で使えることが分かったので、https:// から始まるURLに設定変更して、すぐに利用できるようになりました。

ついでに、古いサイトで使っていたxoops Cubeが文字化けして、管理画面も開けなくなってしまったので、こちらも.htaccessでリダイレクトを設定して、アクセスできなくなった旨を伝えるページに誘導するようにしています。ブログのデータは残してあるので、復活させたいですが、クラウドの導入ほどは簡単ではないので、冬休み辺りで再検討します。

備忘録的追記

ついでにキャッシュ関係について情報を集めて、対応してみました。まずAPCuについては、こちらを参考にインストール

% cd $home
% mkdir src
% cd src
% wget http://pecl.php.net/get/apcu-4.0.8.tgz
% tar zxvf apcu-4.0.8.tgz
% cd apcu-4.0.8
% phpize
% ./configure
% gmake

サーバーのコントロールパネルでのphp.iniへの設定、
extension_dir=/home/username/src/apcu-4.0.8/modules/
extension=apcu.so

ownCloudのconfig.iniに設定を追記した。(もっと新しいバージョンでも良いかもしれません)
'memcache.local' => '\OC\Memcache\APCu',

そのあと、こちらにあるAPCuとOPcacheの推奨設定をサーバーのコントロールパネルからphp.iniに書き込む。一応、phpinfoで設定値が変更されたことを確認する。

デフォルトの設定のままでは中間コードのキャッシュが2秒なのでそれを600秒に伸ばします。また、fast_shutdownが無効なので有効にします。これによりセッションの切断が早くなりPHPの稼働効率が上がります。

opcache.enable = 1
opcache.enable_cli = 1
opcache.memory_consumption = 128
opcache.interned_strings_buffer = 8
opcache.max_accelerated_files = 4000
opcache.revalidate_freq=600
opcache.fast_shutdown=1

OPcacheは、オペコードをキャッシュしてくれますが、データのキャッシュは提供されませんので、APCuを設定します。

apc.enabled = 1
apc.enable_cli = 1
apc.shm_size = 64M
apc.ttl=7200

測定まではしていないけれど、フォルダの変更などのスピードが早くなりました。ついでに、こちらのブログの方も表示が早くなったような。

備忘録的追記の追記

結局、redisもこちらを参考にインストールしてみました。
$ cd
$ mkdir src
$ cd src
$ wget http://download.redis.io/releases/redis-3.2.7.tar.gz
$ tar xzf redis-3.2.7.tar.gz
$ cd redis-3.2.7

とした後に、インストールするフォルダを指定するために、src/Makefile ファイルのPREFIX?=/usr/local部分に適当なパスを指定、既にpathが通っているところにしておいた。ただし、ここで最後に/をつけてしまい、何度か失敗した。
$ gmake
$ gmake install
$ redis-server
で起動できているみたい。

ownCloudの方は、マニュアルに沿ってconfig.iniを追記し、Wordpressについては、Redis Object Cacheプラグインを導入。
ownCloudのエラーメッセージは殆ど消え、ログにはエラーもない模様。