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

今日は、以前私自身が勤めていた病院に行ったら、職員の対応が素晴らしかったことを書きます。 なぜ古巣の病院に行ったかというと、私の実の母親の受診の「付き添い」として、です。 少し重い疾患で、設備の整った病院で診てもらう必要があり、「元いた病院」という気恥ずかしさもありましたが、設備が整った病院ということでお世話になっています。 5月中旬の外来受診の時のことです。 実はこの病院、ゴールデンウィークを利用して、電子カルテをはじめ、HIS系システムの更新がありました。 予約日当日、早めに病院に着いたのですが、もう…、患者でごった返していました。 初めての再来受付機 まず、再来受付がたいへんな行列に。 いままでこの病院では、再来受付機がなく、外来の各ブロックで患者さんから手渡しで診察券を受け取って「受付」していました。 それが、導線も変わり、機械の操作につまずき、たいへんな渋滞を引き起こしていました。 番号呼び出し 病院で増えてきた「番号呼び出し」も、今回のシステム更新時に取り入れた新しい取り組みとのこと。 この病院では、受付時に発行した番号を、診療、会計、薬の受け渡しと、全ての工程で使用する仕組みです。 混雑した待合室の中で、「〇〇番のカタ～、〇番診察室にお入りください。」とアナウンスが聞こえてきます。 しかし、地元の患者さんにはどうも受け入れられないようです。私の周りでも「番号で呼ばれてもわかんないよ」という言葉が聞こえてきます。 看護師の対応が素晴らしい こんな、ある意味「パニック」の状態の外来で、感心したのは職員の対応。 まずは看護師。 アナウンスの後に患者が入ってこないと、待合に出て番号呼び、それでも反応がないと患者名でもう一度呼び出し。 この時、患者が待合室からあふれているものだから、廊下まで探しに行きます。 これ、体力的にも辛いでしょうが、精神的にもかなりキツいはず。 ひとたび待合室に出れば、患者から呼び止められます。 「〇〇ですけど、まだですか」 「〇〇時の予約ですが…何時頃になりそう？」 「俺、忘れられているのでは？」 「番号で呼ばれてもわからん！」 「予約時間」を大幅に超えて待たされれば、職員をつかまえて文句の一つでも言い...

前回 に引き続き、部門システムの仮想サーバーかを断念した理由を書きます。 前回の記事では、物理構成に比べて仮想構成の方が高額になってしまったことを書きました。 もう一つ、決定的な理由が「間に合わなかった」ということです。 スタートが遅かった ブログタイトルの通り、私自身は「経営企画室」の人間で、システム部門は別にあります。なので、「当院のシステムをどうやって構築するか」は、本来私の仕事ではありません。 しかし、各部署がバラバラに動いては、「仮想化」なんて発想が出てくることもなく、かといって当のシステム部門が動くでもなく…。 刻々と既存システムの「保守満了」が近づいていることに危機感を覚えた私は、何度となく関係者に「仮想化とは」を説明しました。 経営企画室が所属する事務部の長である事務長に、そして、なぜか「本職」であるはずのシステム部門の職員に、仮想化のメリットデメリットを何度なく説明しました。 ようやく、事務部門が説得できて、いざ院長・副院長にプレゼン、許可を得られたのは、既存システムの保守満了の1年前でした。 仮想サーバーのサイジング 「1年」というと、十分な時間と思われるかもしれません。 旧来の物理構成のシステムであれば十分でしょう。 しかし、仮想サーバーになると、適切なスペックのサーバーを設計（サイジング）するための時間が必要です。 容量や処理能力が、「足りない」のは論外、だからといって最初から過剰なスペックで設計すれば、なんのための仮想化かわかりません。 ということで、仮想サーバーに「のせる」各システムの必要スペックを計算するのですが、この作業がまったくはかどりませんでした。 先にも書いたとおり、システムを預かる各部署は、「1年」というと、「かなり先のこと」という感覚で、全然話が進まないのです。 PACSのデータ移行 サイジングの作業に手間取っている中、数ある部門システムで中で最大のリソースを要する「PACS」の更新のタイムリミットが迫ってきます。 PACSは、DICOMデータの移行に数ヶ月かかるので、他のシステムに対して、最低でも3ヶ月は前倒しになります。 つまり、PACSが仮想サーバー導入のタイムリミットを決めるわけです。 ...

ここ数ヶ月、次期PACSの更新の話を引きずっていましたが、やっとベンダー選定、院内決裁とも終了しました。 どちらのベンダーさんにするかは、かなり前から方針が決まっていたのですが、様々な周辺の費用（ 「次期PACS導入の付帯費用いろいろ（2019/5/21） 」）がかかることがわかっていたので、これを整理するのに時間がかかりました。 さて、5/21の記事にも書いたのですが、当初、PACSを始め、多くの部門システムを仮想化する予定だったのですが、これを断念しました。 今回と次回、2回に分けて、「なぜ仮想サーバーをやめたのか」を書きたいと思います。 まず、今日の記事で書く、仮想サーバーを断念した理由の一つが、「費用対効果が怪しくなってきたかた」ということです。 医療機関同士の交流や、医療向けのイベントなどで「サーバーの仮想化」という言葉を聞くようになったのは、私の感覚では3年くらい前からです。 レセコンや電子カルテと同じく、最初は大病院から採用が始まり、やっと我々中小病院でも手の出せる費用感になってきたところで、丁度、当院がシステム更新の時期を迎えたことで、「これは行くしかないだろう」ということで検討し始めました。 そこにいくつかの「誤算」が重なり、結果的に費用対効果の見通しが立たなくなりました。 Oracleのライセンス体系 誤算の一つは、データベースシステムの「Oracle」の費用です。 あまりうまく説明できないのですが、ソフトウェアのライセンスは、通常、使用する本数分支払います。ところがOracleは、サーバー全体に費用が発生します。 どういうことかというと、仮想サーバーに複数のシステムが構築されていたとして、そのうちのいくつかがOracleを使用するシステムだったとします。ライセンスが「Oracleを使用するシステム数」だけあればよさそうですが、そうではなく、仮想サーバー全体にかかってくるのです。 どうも、サーバーが「仮想化」されるようになり、これまでのソフトウェアのビジネスモデルが成立しなくなってきていることから、このようなライセンス体系になったそうです。詳しいところまで私は理解していませんが、多くのインテグレーターさん、システムベンダーさんが口をそろえてそのように...