投稿

ラベル(データ活用)が付いた投稿を表示しています

フットケアチェックの周期を判定する

7月から本番稼働したのが「フットケアチェックの周期を判定する」というものです。 「フットケア」とは、一般の皆さんからすると、「巻き爪が…」とか、あるいは「美容」近いイメージを抱くかもしれません。 一方、当院は糖尿病や腎臓疾患を抱える患者さんが多く、足先が化膿したり、場合によっては壊死することもあり、この「フットケア」が医療行為としてたいへん重要なのです。 (私はもちろん専門家ではないので、間違っていたらスミマセン) さて、患者さんに対しどんな「フットケア」が必要か、患者さんの足の状態を調べることを当院では「フットチェック」と呼んでいます。 このフットチェック、多くの項目を調べるため、チェックする看護師には相応の負担がかかります。 なので、手当たり次第にやるのではなく、患者さんの状態に応じて、適切な周期で介入するようにしたい、という取り組みです。 いつもと違う 私が手がけるデータ集計案件は、2種類に分けられます。 経営に関する案件 この手の案件は院長や事務長から直接指示が来ます。そして、毎度のことですが、「それはムリ」と言えるような「期限付き」で飛び込んできます。 臨床現場の効率化や精度向上に関する案件 一方、こちらは私の方から提案することがほとんど。 会議などで交わされる情報の中に、「もしかしたらこれはデータを活用すれば解決できるのでは?」と思ったとき。 あるいは、他の病院の方とのお話や、ネットや書籍で見かけた他院さんの取り組みに「なるほど」と感じ、それが当院でも真似できないかと思ったとき。 「こうしたら今の仕事がもっと楽になるのでは」と働きかけますが、それが何をもたらすのか現場の職員の理解を得られず、拒絶されることもしばしば。 アイディアを理解してもらうまでが一苦労というわけです。 今回は、臨床現場の案件だったわけですが、いつもと勝手が違いました。 むしろ現場の方が積極的で…。 必要以上のフットチェックの頻度 私が院内でこの「フットケア」の言葉を耳にするようになったのはここ3年くらい。 フットケアの重要性を早くから認識していた一部の職員は、これを広めるべく努力を重ねた時代がありました。 ところが、ある時期からそれが過剰になり、看護師の負担になっていたのです。 足の状態が悪...

PACSのデータの二次利用は八方塞がり

医療機関のシステム担当者、データ集計担当者が集まると、よく聞かれるのが、 「PACSのデータは使い物にならない」 という話。 検査データや投薬データはデータベースとして各項目が独立しているので、簡単に集計できるのですが、PACSはそれができないということです。 PACSは、たいてい画像を管理するPACS本体と、検査に対する所見を記載する「レポートシステム」で構成されています。 この、レポート部分のデータが項目別に入力されていたら、本当に有益なデータとして活用できると思うのですが、少なくとも当院が使用しているしすてむはそうではありません。 テキストをダラダラ入力しているだけなので、「人間が読む」で終わり。 テキスト検索の可能性 そんな中、院内のあるチームに呼ばれ、PACSのレポートデータの活用について意見を求められました。 レポートに書かれているデータが、規則的なレイアウトで入力されていたら、そこからデータを生成できないか? とのこと。 具体的には、心エコーのレポートからEF値を抜き出して、それで患者の循環器疾患のリスクをランク付けできないか、というものです。 レポートは、基本的にテキストで書かれているのですが、 ~ SV:○○ml EF:○○% CO:〇〇L/min ~ となっているので、Excelの「LEFT関数」や「RIGHT関数」の容量で、「EF:」を含む前半を切り落とし、その後%以降を切り落とせば、EF値が生成できるのではないかと。 じつは、このアイディア、私も以前から考えていたのですが、問題は、レポートシステムのベンダーが応じてくれるかどうか。 やはりNGでした 当院はPACSの純正のレポートシステムを使用しています。 というわけで、PACSベンダーさんにレポートデータ出力を相談しました。 方法は2通り。 データ出力の機能を搭載できるか データベースの閲覧権限を付与してもらう  「1」は、多くのアプリケーションに搭載されている「データ出力機能」のようなもの。 csv形式やExcel形式にデータを出力するというモノを想定していました。 そして、数日後ベンダーさんから回答は、 「特注になるので、100万くらいで…」 勝手に「標準で搭...

SQL Server + Excel VBAにハマっています

この1週間ほど、プログラミングにハマっておりました。 Excelから電子カルテのデータベース(SQL Server)に、ADODBで接続してデータを抽出するやり方は、半年ほど前に成功したのですが、それからというものデータ活用の可能性が飛躍的に広がりました。 電子カルテには多くの集計表がプリセットされているのですが、医療機関によって事情が違ったり、見たいところが違ったりするのでしょう、やはり、重要な資料は自分で作成することになります。 そんな中、私の数少ない問題解決の引き出しの中でも、この「SQL Server + Excel VBA」は、今では最も多用する手法になっております。 SQLでザックリ集計し、VBAで整える 複数のテーブルを結合してデータを構成するのは、リレーショナルデータベースであるSQLにお任せです。 以前は、Accessを使っていましたが、SQL Serverでクエリーを実行するようになって実感するのが、「圧倒的なスピード」です。 そして取得してきたデータを、エンドユーザーである院長・事務長、あるいは現場の職員が見やすい形に整えるのは、Excelの仕事です。 電子カルテメーカーが用意している集計表は、「色気がない」というか、見やすいかどうかは別にして、とりあえず必要な要素を並べました…みたいな。 例えば一定のしきい値を超えていたら、フォントの色を変えるとか、桁数の多い数字を「〇千円」単位にするとか、そういう気配りをすることによって、資料を見る人の負担を軽くできると思うのです。 そしてハマる この「ハマる」という言葉、2つの意味があります。 一つは、文字通りというか、「集中してしまう」ということです。 このブログで何度か書いていますが、私はIT業界の経験はなく、プログラミングなどとは縁のない人生でした。 ところが、SQLとVBAを勉強してから、より良い統計資料を作ろうと奮闘しているのですが、そこで気がついたのが、プログラミングをしている時って、本当に「集中」してしまうのです。 なんか、気がついたら何時間も経ってた…、みたいな。 ふと我に返ると、タスクリストにある他の仕事にまったく手がついていないという…。 そしてもう一つハマっているのが、周りの人に、この「...

予定の検査なのに、オーダーを入力するのは前日

今、透析患者の「検査オーダーの履歴を集計する」という仕事に取り組んでいます。 透析患者さまは、ルーティンでいろいろな検査をします。 診療のことは私はよくわかりませんが、超音波(エコー)検査などでシャントの状態を、SPPやCABI等の検査で血管の状態を定期的に補足し、患者さまに問題が新たな問題が発生していないか、細心の注意を払っているようです。 これらの検査は、自覚症状がなくても、当院で定めたルーティンで、定期的に行われます。 今回、相談をいただいたのは、この「定期の検査の入力を簡略化したい」という案件です。 「簡略化したい」とはどういうことでしょう。おそらく、なにか面倒なことがあるのでしょう。 検査の種類ごとに、1年に1回、半年に1回、3ヶ月ごとに1回など、間隔が決まっている。 決められた間隔で検査をするにあたり、患者ごとに各検査を「いつしたか」をExcelで管理している。 Excelに転記するため、患者ごとにカルテを開き、目的の検査の履歴を探すのが「面倒」。 なるほど。 当然ですが、電子カルテには、実施した検査の情報がデータとして蓄積されています。 これを加工すれば、患者さまが、それぞれの検査を、最後にしたのがいつか、を一覧にすることは、簡単なことです。 なんだったら、次の検査の予定を補足することだって、難しいことではありません。 履歴だけでいいんです ところが、「次の検査はいいので、『前回の検査をいつやったか』だけわかれば…」と。 いやいや、「次の検査がいつなのかわかったら、もっと便利なのでは」と押してみるも、それは電子カルテの運用上、ムリなのだそうです。 予定のオーダーは入力しないのだから…。 オーダー入力は前日 正確に言うと、オーダーを入力しないのではなく、オーダーを入力するのが「実施日の前日」なのだそうです。 なぜ、そんな面倒なことをしているかというと、数ヶ月前にオーダーを入力したところで、患者さまの透析の「曜日」が変わることがあるからなのだそうです。 透析患者さまは、多くの場合、週に3回の血液透析をします。2回/週や4回/週の患者さまもいるかもしれませんが、当院ではほとんど3回/週です。 すると、月・水・金で通われる...

DWHとBIツール

「電子カルテに蓄積したデータをいかに活用するか」 ここのところ、私にとって最もホットなテーマです。 データ活用の有効性に目覚め、ExcelやAccessを使って様々な資料やアプリケーションを作ってきたのですが、これに限界を感じ、なんらかの「プラットフォーム」が必要だと思っています。 とはいえ、どんなプラットフォームにしても、一介の事務員がぶち上げるには、「職命を賭す」といってもいいような費用が発生します。 決して失敗はできない状況で、導入する製品の選定には慎重にならざるをえません。 今日は、製品の市場調査を、データウェアハウス(以下、DWH)にとどまらず、BIツールにまで範囲を広げてます、という話です。 DWHで分析した結果を共有したい DWHのベンダーさんに話を聞いているときに、いつも思っていたのが、「分析結果をどうやって公開するのか」ということ。 「なぜ公開する必要があるのか?」と思われる方もいるでしょう。 ここで、前回の記事、「 データ活用のヒアリングで思ったこと...大きく分けると①定型、②分析、③現状認識 」で書いた、3つのデータの活用方法について、DWHとの相性を考えてみます。 前回記事では、データの活用方法を以下の3つに分類しました。 定型資料の作成 分析業務 現状認識 これらをDWHで実現するとしたら…。 「1.定型資料の作成」とは、いわゆる月報など、定期的に一定の方法で集計した資料を提出する業務です。特に難しいことではありません。 「2.分析業務」こそ、DWHの本領が発揮できる仕事でしょう。お話を聞いたDWH製品は、そのほとんどが、夜間など負荷の低い時間帯に各システムからデータを複製します。ここで重要なのが、データを「再構築」することです。各システムのデータは私たち素人がパッと見ても解釈するのにとても時間がかかります。DWHに「わかりやすい」形に再構築することで、分析作業をするユーザーの負担が軽減できます。そして、この再構築とデータベースエンジンの性能により、処理スピードの高速化されるのだと思います。 こうして、ユーザーた使いやすい形に加工されたデータ群は、選択するフィールドや、集計のパラメータを、次々と変化させるときに力を発揮します。規則性を見いだしたり、仮説を検証するのは...

データ活用のヒアリングで思ったこと...大きく分けると①定型、②分析、③現状認識

シリーズで書いております、「データ活用のヒアリングで思ったこと」。 前2回が、ハッキリ言って「現実を知って落胆した」内容でした。今回は少しまともな記事にしたいと思います。 データ活用のアイディアは大きく分けて3種類 私がヒアリングしたところ、活用方法のアイディアは大きく3種類に分かれます。 定型資料の作成 分析業務 現状認識 活用方法①:定型資料の作成 毎月、毎週、決まった形で提出される資料。 中には、既存のシステムで出すことができない、当院独自の集計表があり、これをなんとか自動的に出せないかと。 集計方法は難しくないのですが、システムから一発で出せないので、似たようなリストから、情報を拾って集計する、これを「データ活用」といって良いのかはわかりませんが、多くの部署から、同様の意見が寄せられました。 最近では、QI(クオリティ・インディケーター)が話題になっていますね。 当院では本格的にQIを進めていませんが、もしやるとなったら、たいへんな仕事になりそうです。 活用方法②:分析業務 私のような企画業務に就く者が「経営」の観点で、あるいは、医師が日常業務や学会発表に役立てるために...。 条件を変えながら大量のデータを集計する。 ①と違うのは、「条件を変えながら」という部分。 なんらかの「仮説」を検証するために、なにかの「規則性」を見いだすために、条件を変えながらデータを集計する仕事。 これが、データ活用の醍醐味かもしれませんね。 活用方法③:現状認識 上記2つとは、少し毛色が違うのですが、リアルタイムに情報を確認したい、というニーズがあります。 例えば、「予約枠の空き状況」。 大型の検査機器は、遊ばせておくだけで損失です。予約枠の状態をリアルタイムで共有できれば、「空き」に気づいた医師が、オーダーを出せるかもしれません。 例えば、「感染情報の把握」 「〇度以上の発熱や、下痢症状を訴える患者が急に増えた」など、データを監視して、場合によっては積極的に通知する。それによって、院内感染の兆候をいち早くキャッチすることができるかもしれません。 より実践的で、診療現場の職員に直接メリットをもたらすのが、この「現状認...

データ活用のヒアリングで思ったこと…使い道がわからない資料

一応…、シリーズになっております、「データ活用で思ったこと」。 この資料で何が見えるのか? とにかく驚いたのがコレ。 話をしたのは、事務系の課長のうちの一人。 課長:「例えばこの資料、毎月けっこうな手間がかかってるんですけど、そのDWHとやらで出すことができますかね? 」  私:「どれどれ、ん、なんですかコレ?」 なんとも、不思議な資料です。集計する軸が不自然なのです。 あまり詳しくは書けませんが、例えるのは簡単です。 例えば、売り上げ資料。縦軸が「月」、横軸が「診療科」…と思ったら、突然「自費」と出てきます。 各診療科の中に、子項目として「社保」、「国保」…、「自費」とあるわけではなく、診療科の並びにあるのです。 一般内科、〇〇内科、△△内科、□□外科、▽▽外科、自費、救命救急科… なんともトリッキーな資料。これは、クエリではできませんな。必ず「人」が介入する必要があります。 私:「あの、これどうやって見るんですか、横の合計は正しいんですよね?」 課長:「だと思いますが…」 何のための資料なのか、作成者が知らない まあ、実際に資料を制作しているのは課長ではなく、その下の職員でしょう。 それにしても、この資料はどうやって見れば良いのか…。 話をしていると、こんなやりとりが…。 私:「この資料って、どのレベルまでまわるんですかね?この資料で毎月何を見てるんですかね?」 課長:「私も知らないんですけど、長年コレでやっているので、上はコレが見やすいのかと。」 これ以上の対話を続ける気力はありませんでした。 DWHベンダーさんと話をしていると、こういうケースは、グループ病院や、公立の医療機関で多いそうです。 本部で指定したフォーマットで資料を提出するので、電子カルテのリプレースの時に、カルテベンダーさんが対応できない場合は、DWHベンダーさんが請け負ったりすることがあるのだそうです。 まあ、ここまでひどいケースは当院だけでしょうが、意外と、「何に使われているかわからない」という資料、多いのではないでしょうか。

データ活用のヒアリングで思ったこと…人力集計をいとわない風土

以前、院内でデータ活用のアイディを募るため、各部署にヒアリングをしたときのことです。 データ活用のアイディア、部署により温度差(2016/3/8) このときの記事では、人によって、仕事に対するモチベーションが様々であることを書きました。 このヒアリングを通して、いろいろな気づきがあったわけですが、一方で、当院はまだまだ「データ活用」について声を上げる人が出てきただけで、前途多難であることを思い知らされました。 今回から、「データ活用のヒアリングで思ったこと」をシリーズで書いてみます。 驚愕の人力集計 データ活用と聞いて、どんなアイディアがあるかいろいろな人に聞いて回りました。 中には、思わずうなってしまう、「なるほど!」と言えるものがありました。ユニークな発想で、かつ効果も大きいであろうもの。 それに対し、違う意味で驚いたのが、「いま手作業で作成している資料を自動化したい」というもの。 何に驚いたって、「まさか、それ、手作業でやってるの?」という…。 例えば、血液検査のある項目の数値で、ある疾患の「予備軍」が判定できるとします。 「このままではいずれ…」という段階ですね。 こういった人たちが、深刻な状態になるのをなんとかして防ぎたい…、いわゆる「予防医療」。 とっても良い取り組みだと思うのですが、問題はそのやり方。 データを集計する機能がないので、検査科が臨床検査システムから一定期間の検査結果リストを「紙で」出して、これを看護師が目視でチェックしているのだと。 やらされている看護師もたいへんだけど、やらせている方はどう考えているのか? 貴重な看護師の人件費をこんなことに使えるとは、ある意味平和というか…。 医療機関が、もともと「トップダウン」の文化であることも影響しているのかも…。 その資料を作るのにどれだけの人件費がかかっているのか、資料を手にしている人はおそらくそれを知らない。

電子カルテのデータ活用、DWH、BIツール、グループウェア…何を使えば良いのか

久しぶりにデータ活用の話題です。 データ活用のために何らかのプラットフォームを導入して…、と考えているわけですが、難航しています。 どうやって院長の決済を得るか…、ということももちろん重要なのですが、最近困っているのは、どんなプラットフォームを選べば良いか、つまりベンダー選定です。 当初から検討していたDWHベンダー以外に、いくつかのベンダに声をかけたました。 理由は、2つあります。 一つは、交渉相手が1社だけでは、フェアに価格交渉できないこと。 もう一つは、検討しているベンダーさんの製品が、今ひとつ機能が物足りないことです。 DWH、BIツール、グループウェア…何を使えば良いのか 検討していたベンダーさんと具体的な話を詰めていくと、DWHを使って様々なデータの分析ができることはわかりました。 問題は、アウトプットをどのようにエンドユーザーの手に届けるか、その方法です。 ベンダーさんのお話を聞いていると、多くの導入事例では、システム部門や経営企画部門に導入し、そこでアウトプットしたリストや、それを加工したグラフなどを交えた資料を経営サイドに提出する、という仕組みをとっているそうです。 これは、少し思い描いていたイメージと違いました。 私は、多くのユーザーがデータに触れられるような仕組みを想定していました。 いわゆる「ダッシュボード」的な…。 ポータルサイトに、必要な情報があって、それが常に更新される…みたいな。 もちろん、月次の統計資料も必要なのですが…、これは困った。 それからいろいろ調べていくと、製品のジャンルとして「BIツール」というものに行き着きました。 調べてみると、DWHとBIツールのカテゴリは非常に曖昧です。 ザックリ言うと、DWHが様々なデータを一定の形式に整え高速に処理できるようにしたもの、BIツールはデータを処理し気の利いたレポートを作成し共有するためのもの、といった感じでしょうか。 つまりDWHが入力に、BIツールが出力に重点を置いているように思えます。 ところが、DWHと名乗っていてもしっかりしたアウトプットができる製品もあるし、BIツールと名乗っていても高速に複雑な処理ができる製品もあります。 これまでDWHということで市場調査をしていたのですが、B...

データ分析のハードルが日に日にあがってゆく

ここのところ、データ分析の仕事がドカドカと飛び込んできております。 私は、いまや「システム担当者」ではないので、診療報酬改定でも「たいしてすることもない」と、平穏な日々を送れると思っていたのですが…、改訂の内容が具体化されるにしたがって、いろいろな部署から「シミュレーション」を依頼されるようになり、忙しい日々を送っています。 最近は、依頼される内容がどんどん高度化しており、データ活用を推進したい私としては、うれしい半面、忙しすぎるのと、「はたして自分の算出結果が正しいのか」という不安にかられることがあります。 例えば、過去に遡った分析。 「年度別の患者数を、過去5年にわたって調べる」 というようなオファーは、そんなに悩まなくて良いのですが、これが、 「年度別に、 市区町村別の 患者数を、過去5年にわたって調べる」 となると、とたんにハードルがあがります。 過去5年ともなると、引っ越している患者さんもいます。 すると、今年のデータには今年の住所、5年前のデータには5年前の住所で集計しなければなりません。 もちろん、電子カルテのデータには変更履歴を保存しているので、できないことはないのですが…。 いろいろな案件をこなすたび、あちこち調べ回り、ノウハウが蓄積するのはいいのですが、あまり複雑になると、算出した結果が「これで合っているか?」と不安になります。 ましてや、私一人でやっているので、上司でも同僚でもいればまた違うのでしょうが、相談相手といえば、電子カルテベンダーのサポート窓口くらいで…。 本当に、体制を整えないとヤバいと思う、今日この頃です。 余談ですが、最近は、Excel、Accessにとどまらず、SQL文(データベースを扱うための言語です。ご興味ある方はネットで検索を)を書けるようになってきました。 それにしても、お仕事でSQL文を書く人は、みなさん、どうしているのでしょう。 Accessなどと違い、気の利いたビジュアルツールがないので、画面のテキスト、「SELECT 〇〇 FROM~」から、頭の中で構造をイメージして、ii証券名でバックやっています。 複雑なものになると、一つのクエリで1日中悩んだり。 プロ...

データ活用のアイディア、部署により温度差

最近、データ活用の話題ばかりになっています。 電子カルテのデータを使って病院の運営に貢献したい、ということで始まったプロジェクト。 院内で「データ活用」が少しずつ盛り上がりを見せている中、今、ホットな話題は「どんなプラットフォームを使うか」。 お金をかけなくてもできないことはない、しかし、それなりのことをやるには、それなりの環境が必要…ということで、DWH(データウェアハウス)システムの導入を画策している私。 高額なDWHを導入してもらうためには、それを使い倒すための「アイディア」を多く集めて、院長に掛け合いたい。 先日、 「データ活用」の勉強会 を開催し、改めて院内の意識を刺激し、現在は、各現場を回って、データ活用の具体的なアイディアがないか、ヒアリングをしています。 前置きが長くなりましたが、今日はヒアリングの中で感じることを書いてみます。 反応はおおむね良好 ヒアリングは、全体の2/3くらい消化して、あと1/3はこれからです。 ここまでヒアリングした部署の反応とその割合はこんな感じです。 積極的な意見:「絶対ほしい、アレもコレもやりたい…」 → 7割 慎重な意見:「確かにあれば便利だけど、金額次第かな…」 → 2割 消極的な意見:「ウチの部署は、統計といってもあんまり…」 → 1割 ところで、ここだけの話ですが、じつは私、今回のヒアリングを通して、対象者を「観察」をしています。 ヒアリングの対象者は各部署の所属長。 私は、この病院に入って、まだ4年ほどです。さまざまな部署の所属長と一緒に仕事をさせてもらった一方、中にはまだよく知らない人もいます。 「よく知らない」といっても、「たぶん、こんな人かな…」とイメージはあるわけで、今回はそれを確かめる良い機会になりました。 積極的な意見の人 DWH導入を画策している私としてはたいへんありがたい存在です。 話を聞いていると、やはり手作業のデータ集計が、病院の至るところで行われていることを実感します。 また、「実績を集計したりいろいろやるべきことはあるが、じつは日常業務に追われて手つかず…、どうしたらいいんでしょう!」と、さながら「懺悔」のムードになってしまったことも…。 多くの人が、いろいろな課題を抱えながらも現...

「データ活用」の勉強会開催とその後

「当院でもにわかに活気づいてきたデータ活用」と題して、 前編 、 中編 、 後編 に分けて記事を書いたのが、2~3週間前。 今日は、開催した勉強会のことを書いておきます。 勉強会は、私がデータ活用について語る第一部と、データウェアハウス(DWH)ベンダーさんによる製品説明の第2部で構成しました。 この勉強会を開催する目的は、 「データの利活用のために、プラットフォームに高額なコストをかける必要があるか」 を判断することです。 そして、その判断のポイントは、「有効な使い道がどれだけあるか」というころになります。 強制参加という形はとらなかったのですが、声をかけた人たちは全員参加してくれました。 中には、部署の中堅職員を連れて参加してくださる方も。 賛成・反対は別にして、皆さん、関心はあるのだろうと…。 第一部、私のプレゼンは、だいたいこんな構成です。 電子カルテ導入から3年が過ぎ、なぜ今さら「データ活用」なのか 各部署で独自にデータを溜め込むことの功罪 データ活用事例・アイディアいろいろ プラットフォームによるメリット/デメリット ポイントは、3つめの「データ活用事例・アイディアいろいろ」でして…、最初に書いたとおり、「有効な使い道がどれだけあるか」を募るには、現場の人たちが、「なるほど!ウチの部署でこんな使い方ができるはず…」というイメージを持ってもらわなければなりません。 一生懸命説明しましたが、なにせ時間が限られていたもので…、とイイワケしておきます。 私の話に続き、DWHベンダーさんから製品説明をしていただき、勉強会は終了しました。 さて、今回の勉強会で一番興味を示してくれたのが、糖尿病の先生。 勉強会が終了してからも、かれこれ1時間近くDWHベンダーさんに質問攻め。 糖尿病は、検査データの管理や、検査のスケジュール管理など、データ活用が求められる分野だとは思っていましたが、これほどとは…。 医師がデータ活用推進派になってくれるなら、DWH導入に向けて強力な味方になりますが、導入してからのオーダーがスゴそうです。

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

HISのデータを2次利用したい、と日々思うものの、保守的な当院でなかなか言い出せずにいたところ、あるきっかけで大きく変わろうとしています。 このページにジャンプしてこられたかは、ぜひ「 前編 」、「 中編 」からご覧ください。 部長、鋭いッス… 部長先生(以下:部長)、私が密かに開発していたガジェットに、この上ない興味を示してくれました。 聞けば、データの活用については、ずっと考えていだのだそうです。 話していると、いろいろなアイディアが出てきます。医師として、それから管理者として、私には思いもつかない活用方法のアイディアに、思わずうなってしまいます。 定期検査が滞っている患者を抽出したい 医師別に(同じ目的で)異なる薬剤を使うことがあるが、その傾向を知りたい 院内感染(が起きてしまった場合~)その感染経路を補足したい 要員計画に反映するため、病棟の負荷率を計算したい 他にもいろいろ…、とても勉強になります。 そして、部長も懸念しているのが、各部署が独自にデータを持つこと。 各部署にそんな気はないでしょうが、情報という有効な「資産」が、囲い込まれてしまい、他の部署の職員はその存在すら知らない…。 その状況をなんとかしたいという、強い思いがうかがえます。 何度も書きますが、当院、とっても保守的なので、「データを活用して…」なんて考えてるのがバレたら、怒られかねないと思って、今まで慎重に考えて、考えて、考えて…考えた末に行動できず、だったのが、強力な味方の登場に、心強い限りです。 データウェアハウスを提案 ここは部長を信頼し、データを活用するにあたりいくつかの課題について説明。 そのうちの一つが、「どんなプラットフォームを使用するか」であることをお話ししました。 「 中編 」に書いたことを丁寧に説明しました。 ExcelやAccessなどでもできないことはないが、いろいろな意味で限界があること Webシステムは技術的に高度で、開発スキルの習得に多くの時間を費やすであろうこと。 いずれにしても、開発体制から検討しなければならないこと。 そして、DWH(データウェアハウス)製品の導入を提案しました。 DWHは、たしかに莫大な初期費用がかかりますが、その分、開発に携...

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

HISに蓄積されたデータの活用をずっと考えていたのですが、保守的な組織の当院ではどうも抵抗感があるようで…。 ところが、思いがけないきっかけがあり、状況が変わろうとしています。 この記事に直接たどり着いたかたは、ぜひ「 前編 」からご覧ください。 プラットフォーム選択の悩み 「できることからはじめよう」と言ったわりには、どうしても先のことを考えてしまいます。 お金をかけずになんらかの仕組みを構築することはもちろん可能ですが、どうせなら構築したモノをムダにしたくない、という「色気」がでてきます。 開発環境と言うべきか、データベースエンジンと言うべきか、ここでは、仮に「プラットフォーム」と呼びますが、テスト的な開発でも、それなりに時間と労力はかかるので、できるものなら最初から本番と同じプラットフォームを使いたいところです。 せっかく作ったものが、プラットフォームが変わるので、また作り直し…は、できるなら避けたい。 じつは、データの活用については、今まで本業の合間でコツコツいろいろなモノを試してきました。 当院が採用している電子カルテのベンダーは、データの活用には寛容です。ただ、あまりサポートは受けられません。 「テーブル情報は公開しているから、読み取り専用なら好きにしていいよ」というスタンス。 まずは、ExcelやAccessでODBC接続し、いろいろいじってみました。 一応、実用化してもいいレベルのものもできています、公開には至っていませんが。 誰かから、「ウチの部署がやっていることにケチつける気か」なんて言われそうで…。 全部お蔵入りとはもったいない話ですが、構築していく中でいろいろとわかってきたことがあります。 処理能力の問題 ExcelやAccess(とVBA)は、最も手軽なプラットフォームの一つです。 しかし、できあがったアプリケーションを、「せっかくだから、院内で広く共有しよう」となると、排他制御や処理能力など、いろいろと問題が出てきます。 クライアント側で処理するので、データ量が多くなると急激に遅くなります。あるいは、「仕様」で一定量のデータは「読み込めない」なんてことも。 そんなとき思い出すのは、データウェア...

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

2016年度の診療報酬改定の概要について、かなり詳細な情報が出回ってきました。 前回、2014年度改定は、システム部門の責任者だったので大変な思いをしましたが、今回の改定は気が楽です。 さて、今日から2回にわたって、「HISに蓄積されているデータを活用しようという気運が高まってきた」という話を書きます。 「データ活用」に対する抵抗感 ワタクシ、常々こんなことを思っています。 ITシステムの導入効果は、運用で半分、蓄積されたデータを活用して半分、両方こなしてこそシステムのメリットを享受できる。 これは、医療に限らず、他の業種でも同じ事がいえると思います。 システムに蓄積されているデータを分析することにより、新しい事実や傾向を発見し、現場にフィードバックすること、少し大げさですが、システムに携わる者の「醍醐味」だと思っています。 話は当院にもどります。 当院では、「データ活用」を叫んでも、あまり響きません。 ともすると「あざとい」なんて言われそうな雰囲気。どうも、データ活用=重箱の隅をつつく、ようなイメージがあるみたいです。 「より効率の良い仕事ができるように」とか、「安全な仕事ができるように」とか、そういうつもりなのですが、長い時間をかけて形成された病院の風土ということもあり、これまで「データの活用」を積極的に推進してきませんでした。 「玉砕」を傍観 そんなある日、ある部署の長(ここでは「科長」としておきましょう)が、会議の席で「データ活用」を呼びかけたのです。 科長の説明はこうです。 各部署では、電子カルテの使い勝手の悪い部分を、自らの部署で補っている。 電子カルテの画面を見ながら、データをExcelに入力したり、紙に書き写したりしている。 さらに問題なのは、そのデータが「部署のモノ」になっており、そのような有効なデータがあることを他の部署が知らない。 そして、同じような仕事を隣の部署でもやっている。 私は心の中で叫びました。 「そのとーーーーーり!」 科長は続けました。 今後、我が部署ではデータを活用するため、なんらかの仕組みを構築しようと思っている。 これは我が部署単独のモノでなく、院内で広く共有できればと考えているが、なにかアイディアや要望があれば、言ってほしい。 そ...