集中治療室におけるドーパミンの使用とその影響：JIPADを利用したコホート研究

Open Access
Published: 02 April 2022
Dopamine use and its consequences in the intensive care unit: a cohort study utilizing the Japanese Intensive care PAtient Database
Reina Suzuki, Shigehiko Uchino, Yusuke Sasabuchi, Alan Kawarai Lefor & Masamitsu Sanui
Critical Care volume 26, Article number: 90 (2022)

自治に来て、最初の文献。
そしてJIPADデータを利用した研究としてはimpact factorが一番高い。

単純に、嬉しいです。

JIPADが2020年度年次レポートを公開！

最新のレポート（2020年度版）

今年も出ました。
毎年参加施設も症例数も増加していて、今年は70施設、5万例超。
さらに、企画として今年はCOVID症例のまとめ（第1波〜3波）つき。

日本のICUってどーよ？が分かる唯一のデータ。
是非ご覧ください。

JROD発表！

JIPADのデータを利用した文献2つ目がJournal of Intensive Careに掲載された。
（ちなみに一本目はこちら）

Endo H, Uchino S, Hashimoto S, et al.
Development and validation of the predictive risk of death model for adult patients admitted to intensive care units in Japan: an approach to improve the accuracy of healthcare quality measures.
J Intensive Care. 2021 Feb 15;9(1):18. PMID: 33588956.

年次レポートを見てもわかる通り、既存の重症度スコアを日本のデータに当てはめると、AUROCは0.9あるけど、SMRは0.5で、死亡率を著明に高く予測してしまう。
そこで、日本版の重症度予測方法を開発したのがこの文献。その名もJROD（Japan Risk of Death）。
新しいスコアを作るのではなく、APACHE IIIjの予測を日本の現状に合うように修正。

今後はこの予測率が参加施設でも見られるように、JIPADのデータベースを改良中。乞うご期待！

JIPADが2019年度年次レポートを公開！

最新のレポート（2019年度版）

5回目の年次レポート。
どんどん電子化が進み、レポート作成が早くなってきた。

57施設、46000例が対象。
日本のICUの疫学情報はJIPADだけ。
是非、ご覧あれ。

JIPADデータ利用が開始されて1年経った。

JIPADのデータ利用が解禁！

この1年で、利用申請が21件。
そのうち2件は国際雑誌に文献が受理されている。
その2件は、JIPADに利用申請をして、自分の施設のIRBを通して、データをJIPADから受け取って、解析して、執筆して、投稿して、直して再投稿して、というプロセスを1年以内に終了したということで、それって凄くない？

データ利用の説明はこちらから。
今月から2019年度のデータも利用可能になったので、合計で軽く10万例オーバー。
おっと、当然のことながらJPAD参加施設であることが条件ですよ。

部門システムからのデータの自動取り込みにおける注意点

先月にまとめて書いた文章。

データの自動取り込みの罠
自動取り込みの罠①：入退院日、入退室日時
自動取り込みの罠②：身長、体重、病名、術式
自動取り込みの罠③：バイタルサイン
自動取り込みの罠④：GCS
自動取り込みの罠⑤：人工呼吸の開始終了
自動取り込みの罠⑥：血液ガス

興味ない人は何書いてんだ？と思ったかもしれないけど、けっこう真剣に書いたんですよ、これ。
北は北海道から南は沖縄まで、合計約70のICUを実際に訪問して、繰り返し話した内容をまとめたので。

でも、ちょっとこのままだと初めて会う人（メールする人）に「読んでください」とは言いにくいので、文体と内容を変えて、一つの文章にまとめました。
それをJIPADのホームページに掲載してもらったので、紹介します。

部門システムからのデータの自動取り込みにおける注意点

自分で言うのも何だけど、これから自動取り込みでデータベースを運用しようと思っている人にはマジでお役に立つはずだと思っております。

Big dataとLarge database

今月号のJournal of Critical Careに、
Special Section: Data, technology and large databases as catalysts of quality improvement in the ICU - Part 1
という特集があった（今気がついたが、Part 1となっているということは次もありそうだ）。
5つの文章が掲載されている。タイトルだけ列挙。

Novel approaches to facilitate the implementation of guidelines in the ICU
Prediction on critically ill patients: The role of “big data”
Data-driven ICU management: Using Big Data and algorithms to improve outcomes
Linking of global intensive care (LOGIC): An international benchmarking in critical care initiative
National registries: Lessons learnt from quality improvement initiatives in intensive care

ガイドラインの話、Big dataの話、データベースの話。
ほとんどの人はあまり興味のない話題かもしれないけど、僕は読んでいて、いろいろなことを考えた。
考えすぎたので説明は難しいけど、とりあえず、機械学習がどうやったら臨床に入ってくるのかとか、データベースって大事だぞとか、それをどう使ったら患者予後改善につながるかとか、僕と同じことを考えている人はたくさんいそうだ、ということが確認できた。

最近、JIPADについての否定的な意見を間接的に複数回聞いた。
でも、やっていることは間違ってないぞ。
それをどう伝えるか、考えないといけない。

自動取り込みの罠⑥：血液ガス

つまらないことをずっと書いてるな、こいつ。
と思っている方。お待たせいたしました。これが最後です。

血液ガスなんて、電子カルテや部門システムに取り込まれているからそれで終了じゃん、と思うかもしれないが、これまたうまく行かない。
まず、FiO2が入力されていないことが多い。APACHEではA-aDO2、SAPSやSOFAではPF比を使用するので、どちらにしろFiO2が必要。臨床を考えてみても、これらの数字が計算されて画面に表示されていた方が便利だと思うのだが、僕の経験では入力している施設はだいたい4分の1程度。血液ガスを機械に入れるときに、バーコード認証とかベッド番号の入力とかをする機会があるが、その時にFiO2も入力すればいいだけなのに。
じゃあこれから入力しようと思っても、そうはいかない。血液ガスの機械が情報を部門システムや電子カルテに送らないといけないし、部門システム・電子カルテ側はそれを受け取ってかつ表示しないといけない。二つのシステムの変更が必要で、そのためには時間とお金がかかってしまう。

血液ガスの取り込み時には他にも問題がある。それは検体の種類。データベースへの取り込みに必要なのは動脈血の情報のみだけど、静脈血の血液ガスを見ることもある。pHとか電解質とか血糖とか乳酸とかも分かるからね。他にも、胸水のpHとか髄液の乳酸とかも測定することがある。ということは、血液ガス測定時にはFiO2だけじゃなくて検体情報も入力しないといけない。この習慣のない施設も珍しくない。

電子カルテ・部門システムの導入時・改訂時にFiO2の機能を追加すること、そして機械に検体を入れるときにFiO2と検体種類を入力する習慣を作ることが必要。
ただし、部門システムではこの対応をしてくれるけど電子カルテはしてくれない、ということが起こる。理由は不明。でも、電子カルテで血液ガスのFiO2も取り込んで表示しているという話は聞いたことがない気がする。

以上で終了。
他にも工夫はいくつかあるけど、主だったところは書いたと思う。
まとめると、
・自動取り込みは思っているほど簡単じゃない。
・システムの変更にはお金も時間もかかるので、導入時や改訂時に行うべき。
・機械の問題だけでなく、医療者の習慣の変化も必要。ただし、バイタルサインをちゃんと記録するとか、正しい日時を入力するとか、PF比を計算するためFiO2を入力するとか、データベースのためじゃなくて臨床においてするべきことをちゃんとやる。
・電子カルテによるデータベースに必要な情報の自動取り込みは現状では難しい。
という感じか。

上記を大変だと思うか、これだけやってしまえば後は簡単にデータ収集ができると思うか。
それはあなた次第。

自動取り込みの罠⑤：人工呼吸の開始終了

皆さんが使っている電子カルテもしくは部門システムの経過表には、人工呼吸はどのように表示されているだろうか。
一般に、電子的な経過表には指示と実施がある。医者が出した指示と、実際に患者さんに行われた実施。点滴の欄は多くは実施が記載されていると思う。どんな持続点滴がどれくらいの流速で投与されているとか、どの抗菌薬が何時に投与されたとか。人工呼吸の場合、指示の日時が記載されている、実施の日時が記載されている、両方とも記載されている、の3通りあって、メーカー・施設によって異なる。自動取り込みを行う場合、これらのどこから取ってきてもよい。だから人工呼吸の開始終了日時は簡単に取得できる。

と思われるかもしれないが、それは多くの場合、間違いだ。
なぜなら、指示にしても実施にしても、実際にそれが行われた時間が記載されているとは限らないから。例えば患者さんを抜管したら人工呼吸の終了と酸素マスクの開始のオーダーがされて、それの実施が行われる。でも、抜管した直後にコンピューターに入力できないから、しばらくしてから抜管の時間を入力する必要がある。具体的には現在時刻を抜管時刻に修正する。そんなことを全員がやるわけないことは容易に想像がつく。分の単位でずれるなら構わないが、忘れてしまって数時間ずれることも珍しくない。
もう一つの問題は、人工呼吸の状態で入室した場合。手術後とか、救急外来で挿管されたとか、よくあることだが、この場合、JIPADでは人工呼吸の開始日時はICU入室日時と同じにすることになっている。同じにすることにより、ICUで挿管されたのかどうかが分かる。ちなみにこれはJIPADが決めたのではなく、ANZICSの方法を採用している。さて、入室した瞬間にコンピューターに向かって入力作業をする人はいないので、後で入力することになる。その結果、現在時刻を入室時刻に変更する意思を持たない限り、自動取り込みされる日時はほぼ必ず正しくないデータになる。

指示も実施も当てにならないから、人工呼吸器からの取り込みデータを使おうというアイデアを出す人もいる。部門システムでは一回換気量とか気道内圧のデータを取り込んでいることも多いので、良いアイデアと思うかもしれないが、これもまずうまく行かない。例えばCTに行っている間は呼吸器の電源を落としたりするし（人工呼吸を終了していないのに終了として取り込まれてしまう）、入室前にテストラングに繋いているかもしれないし（入室前から人工呼吸が行われたことになる）、上記の入室日時に合わせる問題はクリアしないし。

結論として、人工呼吸の開始終了は自動取り込みできない。正確には、自動取り込みしたデータを確認して、多くの場合は修正する必要がある。
大変だ、と思われたかもしれない。実際、この作業が大変だという声はよく耳にする。しかし慈恵では自動取り込みしたものを最終確認者である僕が修正することはほとんどない。何故なら、開始終了をCEが入力することになっていて、入室時刻に合わせるとか実際の時間に修正するとかいったルールが厳守されているから。さらに、その日のうちに担当医師がJIPADの入力をするので、その時にも確認が行われる。

つまりは習慣次第。

自動取り込みの罠④：GCS

一言で言ってしまえば、GCSの自動取り込みは不可能。
だって、推測しないといけないんだもん。
下記はJIPADの辞書から引用。

GCS評価時の注意事項
・ ICU入室後24時間で合計がもっとも低いときの値を記載。
・ 麻酔や鎮静剤が投与された場合は薬剤がなかったとして推測。その場合、鎮静前の状態が参考になる。たとえば定期手術後の入室なら、麻酔導入前の値を記入する。
・ ただし、薬物中毒の場合は例外で、そのままのGCSを記載する。
・ また、浮腫により開眼できない場合も同様に推測する。
・ 多くの症例ではE4V5M6となるはずである。

実際に自動取り込みをしてみたら分かることだが、GCSの欄はほぼ100％修正する（さすがに言い過ぎか、80％くらいかな）。典型的なのは、麻酔のせいで111と記載されていたり、夜寝ているので356と記載されたり。これらは456に直さないといけない。

データ収集を完全自動化できないかと考える人が時々いる。
無理です。

関連した過去ログ
GCSの評価方法
SOFAスコアのGCS