「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のエラーメッセージは殆ど消え、ログにはエラーもない模様。

ownCloudを試してみました

仕事の合間に、ownCloudをレンタルサーバーにインストールして使い始めました。

FTPでサーバーに転送して、少々データベースの情報を入力する程度なので、10分ぐらいで準備は完了しとても簡単でした。色々「キャッシュを使え」といった類の警告が管理者向けに出てきて、このあたりのことをするほうが良さそうなので、少し試してcronは設定しましたがレンタルサーバーなので、若干融通が利かないところもあり(サーバーの再起動とかできないので…)、そこに対応するまでは詳しくもないし、ネット上の情報もあまりないのでやめておきました。
それでも個人で使う分には十分なスピードで同期してくれていると思います。バックアップ的な意味も込めて、ノートパソコンに入っていた講義資料や研究の資料を約10GBのデータを、同期用の別フォルダにコピーしてクラウドとの同期をはじめました。

使用感はDropBoxと似た感じで、今のところ違和感はありません。

それなりの量があるので、同期には時間がかかり、断続的ですが約1日かけて、今朝には終わっていました。容量にはまだかなり余裕があります。あとはサーバーの負荷の制限にかからなければ良いのですが。

これでほとんど外付けHDD的に使っていたノートパソコンを持ち運ばなくて良い生活になりそうです。(1kgちょっとのPCを持つ持たないとかいっている体力の方を改善すべきでしょうね…)

在宅看取りの研修制度への要望

前回、訪問看護師は死体の撮影係ではありませんというエントリーを書き、大変多くの方に閲覧していただいたようです。

誤解があるといけませんが、私はこの制度に「反対」なのではありません。むしろ、かつての看護師による特定行為の研修制度の検討の際には在宅看護CNSコースの担当教員として、在宅での看取りがうまくいくように死亡診断の補助、代理といったことができないかと提案したりもしていました。

先日紹介した記事の他にも、中日新聞で「死亡診断 遠くからでも 端末通じ看護師が医師に報告 「自宅で最期を」支える」という記事が、日経メディカルでも「いよいよ始まる『看護師による死亡確認』」という記事が掲載され、詳細が分かるようになってきました。
条件として

「5年以上の勤務実績に加え、3年以上の訪問看護の経験などが必要」

であり、早ければ9月ごろから1週間程度の看護師を対象とした研修が始まるとのことです。

また、中日新聞の記事では

ただ、死亡診断に際しては、虐待などによる異状死かどうかの判断は高度な専門性が必要で人材育成が欠かせない。ICTの活用は患者の機微に触れるデータを扱うため、情報管理も慎重さが求められる。なにより診断を委ねる医師と看護師が患者や家族から信頼されていないと広がらない。厚労省は今後、実施された全ケースを検証し成果や問題点を洗い出す。

とまとめられていましたが、看護師に微妙なケースの異常死かどうかの判断力を強く求めていく方向ではなく、通常の診療や訪問看護の中でそうした状況がないことを確認して、チームで対象を選定していく力を育む方向性の方が制度がうまくいくように思われます。

そもそもの話、在宅での看取りというものをイメージできる人のほうが少ないと思うのですが、家族に見守られながら亡くなるというようなケースばかりではなく、老衰の方だと朝に家族から呼吸が止まっていると報告があって、看護師が訪問し、医師を呼ぶなどという場合もよくみられます。そのような場合に医師は形式的に脈をとってみせるぐらいだと思います。一般的なケースでは、何をもって死亡確認に必要な情報とするのかは担当医の判断に任せるものとして、心電図や写真といったものを必須にするのは、その場での違和感もあり過度な医療化であるとともに、手間を増やすだけでそれほど意味がないと私は考えます。

また今回の看護師による代筆を過度に強調して、現場でこれまで行われてきた医師と看護師の間での工夫を制限するようなことにならないようにすることも大切だと思います。

私には以前学会で伺った在宅医の先生のお話が思い出されます。その先生は関東の山奥でお父様の代からの診療所を受け継ぎ、一人で周辺10km強ぐらいの訪問診療をされておられ、診療所やステーションの看護師も同じ小学校や中学校の同窓生だそうです。お忙しい先生の楽しみはマラソンで、東京マラソンの抽選にあたり、いざスタートというときに、患者さんが亡くなりそうだと看護師から携帯に連絡があり、先生は帰ると伝えたところ、患者さんの配偶者が代わりに電話にでられ「先生、帰ってこなくて大丈夫だよ、ゆっくり待ってるから、頑張って走ってきて」と言ってくださったそうです。先生は結局マラソンを完走され、ゴールしてから急いでお宅に向かわれたというお話でした。

普段は家族と遠出もできずに診療に勤しんでおられる医師のこんな場面を「楽をしている」と言ってはいけないのではないかなと思います。こんなケースで、みんなが納得して看護師が代理で死亡診断書にサインをして、ケアを始められたら良いのになあと思いました。

また日経メディカルの方では、この制度への期待だけでなく、医師同士の連携など看取りの体制の強化が先ではないかとか、12時間以内に診察できないといった要件は厳しすぎる離島では船が出ないと火葬できない、などの具体的な疑問点や課題が挙げられていて、とても勉強になりました。

あれこれ言っていても仕方がないので、まずは説明を良く伺えるように11月に山梨で開催される第7回日本在宅看護学会学術集会に合わせて開催される学会の研修で、厚労省の担当者にお話ししていただくことにしました。関心のある方はぜひご参加ください。

訪問看護師は死体の撮影係ではありません

ICTを利用した死亡診断に関するガイドライン策定に向けた研究の報告書が公開されました。450万円という予算の割に薄い報告書ですので、すぐに読むことができます。

先日の朝日新聞の報道読売新聞の報道では、研修を受けた看護師が看護師(おそらくは訪問看護師が行うことになると思います)が、遺体の写真を撮ったり、心電図を付けてそのデータを送るといった行為をICTを用いて行うことで医師に情報を伝え、看護師が死亡診断書を代筆するという仕組みとして紹介されています。

  看護師が訪問し、心停止や呼吸の停止、瞳孔の開きを間隔をおいて2回確認。外傷の有無なども観察し、スマートフォンやタブレット端末で遺体の写真などとともに医師に送る。医師は「死亡」と確認すれば、看護師に死亡診断書の代筆を指示し、医師はテレビ電話などを通じて遺族に口頭で説明する。 – 医師の死亡診断、遠隔で可能に スマホで看護師から報告、朝日新聞

補助する看護師は、離れた場所にいる医師の指示を受けながら、亡くなった患者に聴診などを行い、スマートフォンやタブレット端末などで状態を医師に伝える。必要な写真や心電図のデータも送る。これらのデータを基に医師が死亡診断を行い、看護師が死亡診断書を代筆する。 -看護師、スマホで医師にデータ送信…遠隔での死亡診断が可能に〔読売新聞〕

これは報告書の内容とは必ずしも一緒とも言えないように感じましたが、懸念すべき点が2点あります。

1点目は、死者の尊厳を損なったり、過剰に「死」の医療化を強調するような方法ではないかという点。看護師が死体を撮影する行為や、通常使用しない心電計を装着する行為は人の死のあり方として適切でしょうか。

2点目は、本当にICTが必要であるのかという点。分担報告にあるイギリスの例でも、心電図などは必要としていないのにかかわらず、なぜそれを適当と評価しているのかがよくわかりません。

 心電図により心停止の確認を行う必要はないのかとの問いには、触診と聴診が中心だが、5 分以上の時間をかけて診断しており、死亡確認の手順に疑念をいだいたことはないとの返答であった。 –分担報告書、P9

法医学者には、看護師が心臓が動いているか止まっているのかがわからない存在とみなされているということです。

そもそも今回のテーマであれば、医師と研修を受けた看護師ではどの程度の判断の誤りに違いがあり、心電図をつけることで、どの程度、看護師による報告の信頼性が向上するのかを評価するものだと思いますので、大変に不十分な検証であると思われます。(邪推すれば、結果ありきの研究であったようにも考えられます。)

ICTが必要だとすれば、医師が看護師の報告を速やかに受けられる仕組みぐらいではないかと思います。

これからの多死の時代に向けて大事な制度だと思っていますが、絵に描いた餅、特定行為研修制度の二の舞にならないかと、たいへんに危惧しています。西田先生にも話を聞くなどして、在宅看護学会の理事会にも意見を求めたいと思います。

*一部引用を追加しました。

手術しちゃいました(嘘)

エイプリルフールを先取りして、ふざけたタイトルをつけてしまいました。年度末でわさわさ仕事をしているのに飽き、忘れていたことをすることにしました。昨年の5月に皮下埋込み式ポートのシミュレーターの質が低下して困っているという投稿を書きました。

今年の演習で、やはり支障が生じたので、私が手術をして治してあげることにしました。(もちろん相手は人ではなく、シミュレーターです。)

同じことを考える人もいるかもしれないので手術の経過記録を以下に示します。

まず、患者さんの全体像です。よく見るとポートのところに針を刺すには随分大きな穴が開いています。

そこで、BARD MRIポート 8.0Frを購入しました。(一般の方は購入できないと思いますが、患者さんにも使えるものですので、4万円ぐらいすると思います。)

真ん中あたりのケースの下にある丸い物が取り替えるポートになります。最初に検討ポイントは、この針を刺して、点滴液が外に流れていく経路のチューブをどうするのかという点です。製品のチューブのサイズが合わなければ交換しなければ行けませんし、合うとしてもポートの付属品であるカテーテル(写真の青いチューブ)とどちらが良いかを考える必要があります。

ガイドワイヤーもついているので、カテーテルを入れ替えることもできそうでしたが、既存のものの方が内径が太くつまりづらい用に思われましたので、そちらを採用することにしました。

まずは接続部をカットして、

ぴったりハマりました。  

漏れがないかを確認   

大丈夫そうなので、元のポートを剥がす作業に入ります。

意外と簡単にペリッと剥がれました。ここで二つ目の問題です。このポートは人体に挿入することを考えて、シリコンでカバーしてあります。人間の体であれば、縫合すれば良いわけですが、相手はプラスチックの類ですので針は刺さりません。そこでボンドで接着を考えますが、シリコンは素材の特性上、ボンドとは相性が悪いです。そこで…

そうです。シリコンコーティングを切り離し、ポリアセタール製のポートをむき出しにした上で、ボンドを双方につけて10分ほど待ってから接着しました。

このようにして、あたかも新品のようなシミュレーターに生まれ変わりました。

あとは、週末を私の研究室で療養してもらい、月曜日に外れていなければOKです。

思っていたよりもポートが大きかったので、小型のポートの方がより良かったかもしれません。それからカテーテル類はまた使うかもしれないので、保存しておこうと思います。

思ったよりも上手くできたので、こっちを本業にしようかな(笑)