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

先日、当院で使用している電子カルテのユーザー会に参加してきました。 年に一度のユーザー会なのですが、毎回参加するたびにいろいろと思うことがあります。 そこで、今回から何回かに分けて、ユーザー会で思ったことを書いていこうと思います。 今回のユーザー会でまず思ったのが、災害に関する報告なかったことです。 ここ数年、毎年のように地震や豪雨などの災害に見まわれた病院から、その時の様子を赤裸々に報告していただく演題がありました。 災害時の影響範囲や、職員との連絡手段をどうやって確保したか、そしてどのように復旧していったのか、経験者ならではの気づきがそこにあり、毎回我に返るというか、はたして同じ規模の災害が当院で起きたらどうなるのか、心配になります。 しかし、ユーザー会から帰ってきて電子カルテ委員会で問題提起しても、具体的な対策を講じるまではいかないんですけどね。 さて、そんな災害に関する演題が1件もなかったのは良かった…と思っていたところに、長崎の豪雨です。 患者さんと、職員の皆様のご無事を祈るばかりです。

経営企画室の仕事の一つに、パンフレットやリーフレットなどの企画があります。 先日、当院が展開する介護サービスのリーフレットを制作するため、関係者を集めての会議をしていたのですが、なんとも消化不良というか、残念な会議でした。 グループを前面に押し出すメリットとデメリット リーフレット制作に至る経緯を簡単に説明し、さっそく、「どんなコンテンツをリーフレットに盛り込むか」から話が始まりました。 いくつかアイディアを出しているうちに、「グループで患者さんをサポートできる」という話に。当院は、病院の他に複数のクリニックと、いくつかの介護サービスを運営しています。 となれば、「グループ全体で患者さんをサポートします」は、PRに有効な要素です。 しかし、介護サービスは当院の患者さんだけではなく、他の医療機関の患者さんにも利用してほしいものです。 なので、あまり「グループ」感を前面に押し出すと、「囲い込み」というか、早い話、紹介してくれるはずの他の医療機関さんに、「患者さんを横取りされる」ような印象を与えてしまわないか、ということが気になりました。 そんな話をしたところ、介護部門の職員から、「そんなこと気にしなくて良い」とバッサリやられました。 もちろん、他の医療機関さんや院外のケアマネージャさんと、しっかりとした信頼関係ができていれば、心配しなくても良いかもしれません。 そのあたり、私のような立場の人間は現場を知らないので、「では、グループを押し出していきましょう」となったわけです。 拡散しない しかし、その後も現場職員の、ある種「一方的」な話が続きました。 私：「一度、思いつくコンテンツを全て出してみて、その中からピックアップしては…」 現場職員：「必要なことはわかっているから面倒なことしなくても…」 私：「デザインは、複数のパターンを制作会社から提案してもらってその中で…」 現場職員：「（手元にある他の施設のリーフレットを指して）これでいいでしょ…」 どうも、 いろいろとアイディアを出してみて（拡散） そこからベストな選択をする（収束） というプロセスがうまくいきません。 より良いものを制作したいという意欲がないのか、あるいは、すでに持っている考えが「ベスト」だと思っているのか、それは私に...

今日は、以前私自身が勤めていた病院に行ったら、職員の対応が素晴らしかったことを書きます。 なぜ古巣の病院に行ったかというと、私の実の母親の受診の「付き添い」として、です。 少し重い疾患で、設備の整った病院で診てもらう必要があり、「元いた病院」という気恥ずかしさもありましたが、設備が整った病院ということでお世話になっています。 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を使用するシステム数」だけあればよさそうですが、そうではなく、仮想サーバー全体にかかってくるのです。 どうも、サーバーが「仮想化」されるようになり、これまでのソフトウェアのビジネスモデルが成立しなくなってきていることから、このようなライセンス体系になったそうです。詳しいところまで私は理解していませんが、多くのインテグレーターさん、システムベンダーさんが口をそろえてそのように...

先日、当院が患者さんに渡している請求書が問題になりました。 請求書は2種類あります。 自動精算機から出力される請求書 電子カルテの会計システムから出力される請求書 ほとんどの精算は自動精算機で行われるのですが、入院費や、一部自動精算機では処理できない会計は、職員が会計システムを操作して請求書や領収書を発行します。 記事のタイトルでお察しかと思いますが、問題は「請求日」。 自動精算機は和暦…つまり「令和」で印刷してあるのに対し、会計システム側は「西暦」になっているのだと。 6月も中旬になってこの問題に気づくとは…、担当者は何をしていたんだと言いたいところですが、それは置いておきましょう。 この件、私のデスクの近くで井戸端会議が始まりました。 話に参加しているのは、これに気がついた事務職員数名と経理担当者1名。 「同じ病院から受け取る請求書の表記が異なるのはどうかと思う」 「どっちでも良いから、統一した方が良いよね」 「まさか、システムの都合でそうなっているのでは…」 「それって、どこに聞いたら良いのか…」 「それより、合わせるとしたらどっち（元号or西暦）？」 こんな話が聞こえてきます。 （いや、聞こえるようにしゃべっているのか…？） 仕方ないので、「少し良いですか？」と口をはさむ。 私が話したのは以下の通り。 システムから発行する書類の新元号・西暦対応についてはシステム部門と医事課が対応することが、数ヶ月前に電子カルテ委員会で確認されている。 なので、この手の問題はシステム部門にまず報告するべき。 ちなみに、元号と西暦のどちらを使用するかは、生年月日に関するもの以外は基本的に「西暦」でいく方針になっている。 ちなみに、システム上の都合で元号を西暦表示に変更することができないというのは、極めて可能性が低い。 皆さん納得した様子で、その場は解散。 その後しばらくしてから、経理担当者が私にこっそり教えてくれた。 「なんか、事務長の判断で元号にすることになりました」と。 理由は、「公文書が元号だから」だと。 ちなみに、私は圧倒的に「西暦派」です。 たしかに、医療機関ですから、患者さんの取り違えを防ぐため、生年月日の確認は重要で、その際、「西暦で言ってくだ...

ただいま、次期PACSのベンダー選定が大詰めを迎えております。 今回、複数のベンダーさんにオファーして、そのうちの1社に決めるのですが、一応結論が出ていて、いまは最終候補1社のベンダーさんと調整をしているところです。 さて、こうなってくると、「落選」したベンダーさんに、「この度はご縁がなかったということで…」というお話をするわけです。 すると、どのベンダーさんも判で押したように、「金額が合わなかったのなら、もう少し頑張れますが…」という話が返ってきます。 できれば最初からお願いしたい まあ、ベンダーさんから見れば、可能な限り高く売りたいのでしょう。できれだけ高い金額で売れた方が会社のために、ひいてはご自身のためになるので当然のことです。 最初は余裕のある金額を提示して、様子を見ながら価格を下げていく…、これが駆け引きというもの。 しかし、私はこの手の、Aの方が安ければBに、Bが安くなったらAに金額を提示を求める価格交渉は、あまり好きではありません。 基本的に一発目の見積で決めます。時間の無駄ですしね。 「最初から本気を出さない」イメージ 私の流儀は別にしても、実際に再見積を何度もやることって、どうなんでしょうか。 当院から見て、「このベンダーさんは、最初からギリギリの金額を出してくれない」というイメージになってしまいます。つまり、提示されている金額よりもう一段先がある、という目で見てしまいます。 特に今回の「PACS」については、多くのベンダーさんが、モダリティ（検査機器）のベンダーさんでもあり、PACSが契約に至らなくても、モダリティでお付き合いが続いていくわけです。 駆け引きするベンダーさんであるというイメージは、今後の取引にも影響するのではないかと、こちらが心配してしまいます。 と、いろいろ書きましたが、取引に至らなかったベンダーさんには、本当に気の毒に思います。 どんなに手間をかけてプレゼン資料を作っていただいても、デモや質疑応答で時間を割いていただいても、当院が契約できるのは1社のみであり、その他のベンダーさんには、1円もお支払いしません。 機能紹介や見積合わせの打ち合わせで、こちらも大いに勉強させてもらっているのに。 もちろん...