中規模病院の経営企画室のブログ

電子カルテ導入のプロジェクトでは、カルテシステム本体以外にも、いろいろな医療機器がバージョンアップや買い替えの対象になります。 となれば、徹底的な価格交渉をして出費を抑えたいものです。価格交渉の最も有効な手段が「相見積もり」です。一つの案件に複数の見積りを依頼するわけです。 「購入する立場」は非常に強いもので、 メーカーに来ていただき説明を求め、いただいた見積を吟味する作業は、 ある意味で「華やか」な仕事とも言えます。 その華やかさの中で、最後に笑えるメーカーはたった1社であることは言うまでもありません。コンペに参加したその他のメーカーは数週間、数ヶ月にわたって努力した結果が、「ゼロ」になります。 去りゆくメーカーの担当者には本当に気の毒なのですが、コストの増大は病院経営を圧迫し、ひいては患者様に迷惑をかけます。たとえ古くからの付き合いで会ったとしても、ここは譲るわけにいきません。 私は、これまでのいくつかの医療機関で仕事をしてきましたが、いろいろな購入案件に携わってきました。時には、病院の購買部門に所属していた時期がありました。 そんな中でこれまで一緒に仕事をした人の中には、「難癖」ともとれるようなゴリ押しで文字通り「買い叩く」という、仕事の仕方をする人もいました。そんな「買う側の立場」にモノを言わせた仕事の仕方がたまらなく嫌だった私は、誰もが納得い く合理性を求めて、詳細なデータを集める価格交渉を突き詰めようとしてきました。断られるメーカーが「それなら仕方ない」と思えるような、多角的でフェアなデータ分析をするように心がけました。 結局、情報量を稼ぐにはどうしてもメーカーとのやり取りが多くなってしまい、人間同士、情が湧いてしまい、断りづらさはむしろ増したような…。 と、こんな葛藤を抱えているのは私だけかもしれませんが、「買う側、選ぶ側」にも辛い気持ちがある、というお話でした。

帝京大学医学部附属病院：治験・問診業務のバイタルデータ取得にコンティニュアを適用 ノートPCと血圧計・体重計によるラストワンマイルソリューション 増田克善さん（医療ITライター）のこんな記事を見かけました。 なんでも、帝京大学病院さんで、バイタルデータの取得して電子カルテに取り込む処理を自動化する取り組みらしいです。記事の多くは治験に関わることなので、私にはピンときませんが、後ろの方の「問診業務支援システム」は興味深く読ませていただきました。 記者の方が書かれているとおり、入力ミスの防止や、データの二次利用など、色々なメリットがある一方、患者様の発する言葉に含まれる意味をどのよう反映するかなど、課題も多いのだと思います。 コンティニュア・ヘルス・アライアンス ところで、この記事で初めて知ったのですが、 コンティニュア・ヘルス・アライアンス という団体があり、医療機器・健康機器の規格統一の活動をされているそうです。 対応機器の一覧には一般向けの機器が多いのですが、いくつか医療機関向けのものもありました。メーカーの皆さんには積極的に参加していただきたいと願います。 こういった規格が統一されて、電子カルテへのデータ取り込みが簡単になると、現場の手間やミスも減るし、医療機器やシステムのコストも下げられるだろうし、とても良いことだと思います。 ただ、いつも思うのですが、こういう規格は、営利目的で作るものではないので、国が主導したらどうかと考えてしまいます。 古くはVHSとベータ（古過ぎ！）とか、最近では電気自動車の充電装置など、規格を主導することで莫大な利益が転がり込むことから、メーカーが必死になるケースは多いものです。 しかし、医療という業種の性質からすると、こういった規格手動から生まれる利益や、市場独占を目的にメーカーが過激な競争をするのは良くないのではないかと思います。 国民の健康を効率よく維持するという意味では、社会インフラとして政府が主導したほうが良いのではないかと思います。

当院では、MicrosoftのOffice（以下：Ms-Office）を使っています。 前の職場では、Googleドキュメントを使っていました。私にはどうも、Googleドキュメントに比べると、MicrosoftOfficeが一世代前のソフトウェアに思えてきます。 理由は主に2つ。 同時編集 複数のユーザーで文書を共有しているときに、Ms-Officeだと、誰か一人が開いていると、別の人は「読み取り専用で開くか、諦めるしかありません。調べればこのへんを制御する機能があるかもしれませんが、Googleドキュメントだと、ややこしい設定なしに、一度共有すれば同時にファイルを開いて同時に編集ができます。 院内で共有しているときはまだ良いのですが、外部と共有し始めると本当に歯がゆい思いをします。 ここのところ、カルテメーカーともやり取りする情報が増えてきて、例えば「各部門に何台のPCやプリンタを置くか」という管理表があるのですが、私が修正することもあるし、カルテメーカーの担当者も修正することがあります。そんな時、Excelだと、「メールで送って、返ってくるまでは編集できない」とか、「編集したら最新版を送っておく」とか、本当に面倒です。 Googleドキュメントのスプレッドシートだと、複数のユーザーが同時に編集できます。誰かが同時に開いていると、その人がいまどこのセルを編集しているかもわかります。まさにリアルタイムに共同作業ができてしまいます。 「進捗管理表」とか「IPアドレスの割り振り表」とか明らかに複数で編集する必要があるものは、Googleドキュメントのスプレッドシートに「持って来い」です。 検索 編集機能よりも、ファイルの扱い方の話になります。Ms-Officeがディレクトリ型というか、整理して保管するスタイルだとすると、Googleドキュメントは、とりあえず保存しておいて、また使うときは検索機能に任せる、というスタイルです。 Googleドキュメントのホーム画面、今は「Googleドライブ」という名前になりましたが、ここは最終更新日が新しい順にならんています。つまり頻度の高いものが上の方に、あまり使用しないものは下に行きます。実際、これであまり困らないし、むしろ更新があったものがすぐわかるのでとても便利です。 ...

ヘェ～、と思うことがあったので記事にしておきます。 今や、施設間でのレントゲン画像の受け渡しは、ほとんどCD-ROMという時代になりました。 昔は、とても普通のバッグに収らないほどの大きな封筒に入れてフィルムを持ち運んだものですが、すっかり便利な時代になりました。 医療の業界以外の方にはなじみがないと思いますが、DICOM（ダイコムと読みます）という規格が広く普及していて、画像の共有に関してはかなり標準化が進んでいます。 先ほど「受け渡しはCD-ROM」と書きましたが、これを病院のPACS（パックスと読みます）という、画像専用のサーバーに読み込んで閲覧するか、あるいはCD-ROMをそのまま見るか、医療機関によって方針がわかれるようです。 「そのまま見る」とは、CD-ROMからビューワーを起動して見ることを意味します。CD-ROMを作るとき、相手がPACSがない環境でも画像が見られるよう、ビューワーのソフトを入れて作成します。診療所などではPACSを導入していないところも少なくないので、普通はこのようにします。 受け取った施設では、CD-ROMからソフトを起動して、画像を見ることができます。もちろん、PACSを導入している施設では、画像を取り込んで設置されているPACSのビューワーで見ることもできます。 さて、システム管理者の立場では、PACSに取り込んで見たほうが良いと思います。 メリットは、 一旦取り込んでしまえば、どこの端末からでも見られる。 CD-ROMを返却あるいは、処分してしまっても良い。 ビューワーソフトを起動するのに時間がかかる。 使い慣れたインターフェースで操作できる。 一方、デメリットもあります。 診察室に入ってから患者様がCD-ROMを差し出すと、取り込みむのに時間がかかる。 大規模な医療機関では、件数が多くなりそれだけでも結構な作業量になる。 共通規格とはいえ、たまに取り込めないCD-ROMがある。 など、主に業務フローの部分で調整が必要です。 この他、「CD-ROMがウィルス感染している可能性がある」という意見もありますが、どちらの方法でも感染する確率は同じなのでここでは無視します。 そんな折、PACSメーカーのシステム担当者と話す機会があり、話を聞いて驚きました。 な...

このところ、ブログの更新が滞っていました。 じつは、電子カルテの説明会を行うという、大役を仰せつかりまして、その準備で忙しかったわけです。 電子カルテのプロジェクトが本格的に稼働するまで少し時間があるのですが、各現場は不安が募るばかり。聞くところによると、院長から直々に我がシステム部門に「所属長向けの説明会を開くように」と指示があったとか。院長はすでに他の病院で電子カルテを使っているのでよいのですが、他の職種についてはイメージが全く湧いておらず、それを院長が心配したそうです。 じつは、同様の意図でカルテメーカーから所属長向けの説明が既に一度行われています。 その内容が、求めていた内容とは少し違っていたとのこと。 カルテメーカーのプレゼンと言えば、導入前のコンペの段階で、いかに「他社より優れているか」と説明する姿を想像します。でも、今回は既に導入が決まり、導入後の運用、導入の作業がイメージできるものを期待していました。当然、カルテメーカーにはそのあたりを話していたはずなのですが、どうも漠然とした話になってしまったそうです。 そんな話を聞いていたので、より具体的にイメージしてもらうには…、とない頭を絞って日々プレゼン資料の作成に明け暮れていたわけです。 思うに、カルテメーカーはこれまでたくさんの事例をこなしてきて、ある程度のスケジュール感や、壁にぶつかった時の解決方法、迷った時の落とし所みたいなものが、蓄積しているのでしょう。 一方、我々にとっては、さすがに今の時代なので、「電子カルテとはなんぞや？」から始まることはないと思いますが、それでも仕事の流れがガラリ変わるわけです。 とくに、解決方法の部分はギャップが大きいと思います。ある仕事を電子化するときに、我々は、システムで「何ができて、何ができないか」も知りません。カルテメーカーは当然自社商品のことだからよく知っているし、また他の医療機関の経験があるので、「なんだかんだ言っても、こうするのが一番」みたいな答えを持っているのだと思います。 このあたりは、捉え方一つだと思います。良く考えれば「（メーカーが）蓄積したノウハウを活かせる」ということですし、悪く考えれば「こちらの要望を聞いてもらえず、まるめ込まれるのでは」ともとれます。 カルテメーカーとの付き合いはつい最近始まったばかりで、...

当院では既に看護支援システムが稼働していますが、今回の電子カルテ導入で、電子カルテメーカーのシステムに移行することになっています。 「移行する」と言っても、コトは単純ではないわけで…、書籍「看護管理としての看護情報支援システムの構築と運用」で、少しだけ勉強してみました。 この書籍は、岐阜大学医学部附属病院で看護情報支援システムを構築していく過程が綴られています。見事なまでに情報が体系化されていて、読みながらずっと「これ、本当に看護師が書いた本なのか…」と思っていました。損益分岐点の話とかUMLとか、経営の視点や、SEが使う専門用語が随所に出てきます。読み終わって改めてまえがきを読んだら、著者の五島光子さんは看護師でありながら、産能大学情報経営学部情報経営学科を出ている超ツワモノでした。 で、この書籍を読んで、本当に看護という仕事はシステム化しにくいものだと思いました。 システムを組む、プログラムを組むということは、ざっくり言えば「ユーザーが次に何をするか、選択肢を全て用意しておく」ということだと思います。 例えば銀行のATMでは、できることがメニューに表示されています。いくつかの階層を経て、かならず目的にたどり着きます。逆に、メニューにないものはATMではできないということです。ユーザーの動作を体系立ててメニューに仕込んでおくわけです。 もちろん、看護という仕事だって、システム化するとなれば、すべての選択肢を洗い出して整理しなければなりません。その「整理」がATMとは比べものにならないことは、看護の仕事に関わったことがない人でも容易に想像できると思います。 そして、洗いだした後には、それを標準化しなければなりません。病棟や診療科によって違う用語や、ちょっとした言い回し「装着する」、「はめる」、「着用する」（書籍より）を全てと統一します。 この書籍を読んでいるだけでも、気が遠くなります。 さて、当院の話に戻ります。 最初にも書きましたが、当院では既に看護支援システムが稼働しており、問題はこれまで蓄積したデータをどう移行するかです。 まだ正確な見積が出ていないのですが、データを抽出する現行メーカー、データを取り込む新メーカー双方に、莫大な費用がかかるらしいです。というか、メーカーにしてみれば高い見積もりを出して、「いっそあきらめてくれ...

前々から、ずっと気になっていた電子書籍を、ついに購入してみました。 電子書籍は、いろいろなサイトが乱立していて、どのサイトで購入して良いのか、ずっと決めかねていました。 そんな時、今年の2月に発刊して以来、ずっと止まっていた雑誌が、「電子書籍として復活する」というニュースを聞いて、購入を決意しました。 というものの、「決意」と言うには大げさで…、じつは、この ｆｌｉｃｋ! という雑誌、紙で発行していたときは、680円だった（と思う）のですが、電子書籍ではなんと350円、「あまり深く考えずに買ってみよう」となったわけです。 販売しているサイトは8種類あって、それぞれ読める媒体（Windows、Mac、Android…）や、決済方法が異なります。（詳しくは こちら の記事に） その中から Zinio を選んで購入してみました。 「雑誌」というサイズは、当然ながら文庫本よりも大きいわけで、PCの画面で読むことを想定して購入しました。ところが、Androidのタブレット（Acer A500）で読み始めたら、うまく言えませんが、雑誌を「手に持つ」感覚に近いのか、こちらのほうが馴染みました。 新しいものに触れるときは、頭で考えることももちろん必要ですが、やっぱり体験してみることが大切だと、改めて感じました。