当院でもにわかに活気づいてきた「データの活用」(中編)

HISに蓄積されたデータの活用をずっと考えていたのですが、保守的な組織の当院ではどうも抵抗感があるようで…。
ところが、思いがけないきっかけがあり、状況が変わろうとしています。

この記事に直接たどり着いたかたは、ぜひ「前編」からご覧ください。


プラットフォーム選択の悩み

「できることからはじめよう」と言ったわりには、どうしても先のことを考えてしまいます。

お金をかけずになんらかの仕組みを構築することはもちろん可能ですが、どうせなら構築したモノをムダにしたくない、という「色気」がでてきます。

開発環境と言うべきか、データベースエンジンと言うべきか、ここでは、仮に「プラットフォーム」と呼びますが、テスト的な開発でも、それなりに時間と労力はかかるので、できるものなら最初から本番と同じプラットフォームを使いたいところです。

せっかく作ったものが、プラットフォームが変わるので、また作り直し…は、できるなら避けたい。

じつは、データの活用については、今まで本業の合間でコツコツいろいろなモノを試してきました。

当院が採用している電子カルテのベンダーは、データの活用には寛容です。ただ、あまりサポートは受けられません。
「テーブル情報は公開しているから、読み取り専用なら好きにしていいよ」というスタンス。
まずは、ExcelやAccessでODBC接続し、いろいろいじってみました。

一応、実用化してもいいレベルのものもできています、公開には至っていませんが。
誰かから、「ウチの部署がやっていることにケチつける気か」なんて言われそうで…。

全部お蔵入りとはもったいない話ですが、構築していく中でいろいろとわかってきたことがあります。


処理能力の問題

ExcelやAccess(とVBA)は、最も手軽なプラットフォームの一つです。

しかし、できあがったアプリケーションを、「せっかくだから、院内で広く共有しよう」となると、排他制御や処理能力など、いろいろと問題が出てきます。

クライアント側で処理するので、データ量が多くなると急激に遅くなります。あるいは、「仕様」で一定量のデータは「読み込めない」なんてことも。

そんなとき思い出すのは、データウェアハウス(以下、DHW)というジャンルの製品です。
DWHという概念は古くからあります。あらゆるデータを放り込んで、誇大なデータから必要とされる情報を迅速に集計するためのシステムです。
最近では、医療に特化したもの、つまり電子カルテ等のシステムとの接続を前提にしたものが出始めてきていますが、当然、莫大なお金がかかります。

アプリケーションの共有

「処理能力」以外にも課題はたくさんあります。

その一つが「配布」です。ExcelやAccessはもちろん、クライアントで動作するアプリケーションであれば、どのような仕組みでこれを配布するのか。
また、ソフトウェアのライセンス費用の問題も出てきます。

そこで、「Webシステム」にしたら、という発想が出てきます。

これ、実際に試してみたのですが、タイヘンでした。
院内LANにWebサーバーを立てて、SQLの結果を表示する仕組みを作ってみました。使い勝手は上々、しかしその構築は困難を極めました。SQlやPHPなど、いろいろな開発言語を駆使する必要があり、当然、たくさんのバグに見舞われたのですが、ここだけのハナシ、いくつかのバグは「改善できた理由」がわからないんですよね。同じコトをやれと言われたらムリ…。

気の利いたパッケージ製品が世の中にはありそうですが、それもお金次第。

ホント、考え出したらキリがありません。

誰が開発するか

もう一つ大事なことが、開発に携わるメンバーのことです。

会社にコンピュータに詳しい人がいて、その人が組んだプログラムによって仕事が劇的に効率化したが、その人が辞めて困ったことになった…、というのはよくある話です。
医療機関では、この手の話が特に多いような気が…。

信頼のできるシステムベンダーさんにアウトソースできれば良いのですが、それこそ莫大な金額になりそう。

社内で開発するなら、2名以上がこのプラットフォームを使える状態にしなければいけません。

Excelを基盤に開発するとなれば、VBAを使うことになりますが、恥ずかしながら、専門的に勉強したことがないので、いつも我流でコーディングしています。
マナーも作法もお構いなし、ルール無用のチカラ技…。

せっかく習得するのであれば、院内で長く使えるような開発環境を勉強したいところです。

いやちょっと待て、私が開発仕事をすることが、そもそも「アリ」なのでしょうか。


お蔵入りのガジェットが部長の目に留まる

とりあえず小規模で開発する→しかし開発したものはムダにしたくない→永続的に使用できるプラットフォームで最初から開発する→そんなお金はない→とりあえず小規模で…
と、堂々巡り…。

結論が出ないまま、とりあえず科長には、どんな課題を解決したら、多くの職員の興味を引けるかを考えてもらうことにしました。
一方で、私の方は、どんな環境で開発したら良いかを検討することにして役割を分担しました。

それから数日後、ひょんなことから状況が変わり始めます。

科長が、私が密かに作成していたデータ活用の仕組みを、部長先生に話してくれたのです。
部長先生は、それに興味を示し、私に声をかけてくれたのです。

コメント

  1. いつも楽しく拝見しております。
    コメントも時折させていただいてるのですが、同じような状態であり考えさせられることが多いものです。
    当院も電子カルテを導入して4年がたちますが、電子カルテにどんどんデータがたまっていきますが、それを有効な"情報"というものに変換できず、困っております。
    各部門でも会議の資料を作成しています。それは電子カルテのCSV抽出ツールを用いたもので、我が企画部門のものと定義がちがっていたり、抽出するマスターが違っていたりして、データが違うことをよく指摘されてしまいます。すべての会議資料を作成できるとよいのですが、人員を割けない状況であるため、実現には至っておりません。
    来年度は診療報酬の改正もあるため、なるべく迅速に病院の状況を把握し未来を見据えるような資料を作成→提案をしていきたいのですが、時間の経過は早く難しいものですね。
    このblogを励みに今日もがんばりたいと思います。
    今後も更新お待ちしております。

    返信削除
    返信
    1. コメント、ありがとうございます。
      「データが違うことをよく指摘されて…」
      その気持ち、よくわかります。
      良かれと思って、目的に応じて集計方法をアレンジすることはよくあります。「外来患者数」と言っても、外来診療の要員計画などに使うなら、「救急外来」や「外来透析」を省いたりします。私が直接データを手渡しできる人物、例えば事務長や院長にはその前提条件を説明するのですが、データ一人歩きしてしまうと、説明が不十分になり「アレ?なんかコレおかしくない~」みたいな…。
      コメントいただけて、こちらも励みになります
      これからも、ご意見、ご質問などありましたら、バンバン投稿してください。

      削除

コメントを投稿

このブログの人気の投稿

GoogleのAutoDraw、ピクトグラム作成に使えそう

旧字体や外字は使用できません

患者さんの視線とサインの高さ