オンライン請求システムの各種ファイルについて
こんばんは、スタゲイラです。
だいぶ間隔が空いてしまい申し訳ありません。
さて、最近少し気になったトピックがありました。 多くの医療機関は、レセプトを電子請求していますが、その際に
- オンライン受領書
- 返戻内訳書
- 増減点連絡書
等がCSVでダウンロード出来ます……が。 中身を見ますと、案の定、そのまんまエクセルで加工して使える代物には見えませんでした。
例えば「返戻内訳書」を見てみましょう。 CSVは行ごとに
- ヘッダ行
- データレコード（タイトル部）
- データレコード（明細部）
に別れており、それぞれ列数が違います。 格列の内容が何を示しているかは、
- 一列目のレコード種別を見て、上記3つのどれに該当するデータか判断する
- 仕様と睨めっこして、どれが何の内容か確認する
という作業が必要です。
……どこかで見た仕様だと思ったら、何のことはない。UKEと同じ作りなんですね。
できれば普通にエクセルで開けるようなCSVにして欲しいものです。
ということで、この種のCSVについてパーサーを書こうと思っています。 出来たらGitHubに載っけますので、気長にお待ち頂けると幸いです。
レセ電パーサー：また破壊的変更をやりました……
こんばんは、スタゲイラです。
今回もレセ電パーサーに破壊的変更を加えました。 毎度すいません！
えー、さて。何があったかといいますと。
このレセ電パーサー、そもそもは『患者情報だけが見たい』『処方情報を集計したい』といった、個別情報を引っこ抜くために作成したものでした。
つまり、「レセプトを再現する」用途では、まったく考えてなかったんですね。
しかしながら、最近それに似た作業をやってたところ、恐ろしい文書に出くわしました。
支払基金の電子レセプト作成手引きから引用です。
なるほど。どうやら、レセプト行為には『一連番号』なるものが振られるようですね。
確かに紙レセプトを見ていたとき、番号が振られていました。
さて。ではこの番号はレセ電のどこに記録されているかというと……
……どこにも記録されていません！（白目
そう、この一連番号、審査のコンピューターが割り振るものなのです！
しかしこの番号がないと並び替えも出来ませんので、なくなく審査のロジック（と思しき物）をパーサーで再現しました。
それに伴い、Receオブジェクトの仕様も変更しています。以前はREなどのレコード情報をキーにしたディクショナリでしたが、順番通りのリストに変更しました。
とはいえ、REやIYでデータが抽出できる仕様は残してあります。これがないと不便ですので。
前々から思っていましたが、レセ電UKEファイルの仕様は、「データ利活用をする」目的ではなく、「審査で紙印刷する」ためのものなのでは……？ という疑念が拭えません。
ところどころ、「印刷プログラムが順番に読み取っていって、印字していく」ためとしか思えない仕様が散見されます。
（例えば、診療識別番号を『先頭にのみ』記録する仕様には、何ら合理的理由が見い出せません。明らかに、印刷を念頭に置いた仕様に見えます）
いつの日か、人間にも可読性があって、かつコンピューターにも優しいファイル形式になるといいなあ……
現状、どっちにも優しくないんですよね、このファイル形式。
レセ電パーサー：破壊的更新を実施しました
こんばんは、スタゲイラです。
今回はレセ電パーサーに破壊的変更を加えました。
具体的には、患者IDを指定した際の挙動を変えています。
今まではレセオブジェクトを返していましたが、今回からレセオブジェクトのリストを返すようになりました。
こちら、実務で使っていたら『同一患者に複数のレセがある』ケースがあることに今さら気付き、安直に修正した結果となります。
そりゃ、同月に入外受診したり、DPCと出来高が混ざったりすれば、そうなりますよね……
さて、実務でレセ電パーサーを使っていれば、当然分析に応用したくなります。
そこで、レセ電ファイルからデータを抽出するユーティリティを開発中です。
こちらは『点数や食事だけ抽出』とか、『診療行為をリスト化する』とかを考えています。
PandasのDataFrameで吐き出す仕様にしようかなー、と考え中ですので、のんびりお待ちください。
お久しぶりです。レセ電パーサを更新しました
こんばんは、スタゲイラです。
はい、まる２年にわたってブログを放置していました……！
申し開きようもございません。部署異動もあり、医療実務から離れていたら、すっかりモチベーションが続かなくなっていました。
しかし、最近になってDPCデータやレセ電データをいじくる機会もありまして、リハビリがてら再開しようと思います。
まずはレセ電パーサの更新をしてみました。
以前はデータ行数によってディクショナリが返るか、ディクショナリのリストが返るか、挙動が変わっていました。
自分で使ってみてひどい仕様だと反省し、一貫してディクショナリのリストが返る仕様に変更してます。すみませんでした……
さて、今後なのですが、そろそろDPCデータ分析の基盤を見直すかなーと思っています。
今まで本ブログでは、「Python環境がなくても動く分析ツールを！」という目標を掲げ、Scalaをいじってみたり、PowerShellを書いてみたり、色々迷走していました。
が、どう考えても労力に割に合いませんし、私みたいな一介の事務員がJavaScript + Electronでアプリでっち上げるのも、無理があります。
（いや、書きましたけど、続けられません！／苦笑）
ということで、Pythonを中心に、というかほぼPythonオンリーで環境構築することにします。
今までDPCデータのDB投入も、PostgreSQLのインポートツール使ったりしてましたが、Python経由で投入することにします。
次回以降、色々書いていこうと思いますので、お使い頂ければ幸いです。
Facebookの「Prophet」を使った時系列予測
前の記事から大分時間が空いてしまって、すみません。
私事ですが、転勤などあって、ドタバタしていました。
さて、今日の話題は時系列予測です。
時系列予測を行うには、以下のような方法が挙げられます。
- Excel2016の新機能、「予測シート」を使う
- Power BIの予測機能を使う
- RかPythonで頑張る
さて、１番と２番については、どちらも「指数平滑法」というアルゴリズムを使っています。
3は色々方法がありますが、有名なのはRのforecastパッケージと、pythonのstatsmodels.tsaでしょう。
これらの方法には、色々メリットがありますが、今日紹介するのは時系列予測界隈のニューフェイス、facebook製作のProphetライブラリです。
Prophet、素人のための時系列予測ライブラリ
煽りっぽい書き方ですが、facebookのページには、時系列予測を扱えるユーザーを広げようと書いてあります。
Prophetのモットー、'Forecasting at scale'とは、ビッグデータを扱おうという意味ではなく、時系列予測を行える人間を増やそうという意味です。
実際、Prophetは使い方にクセがありますが、かなり使いやすいライブラリです。ユーザーが指定しなければならないパラメータを、極力減らしています。
まず、以下のようなデータフレームを用意します。 そう、Pandasのデータフレームを使うことが前提です。
| y | ds | cap | |
|---|---|---|---|
| 112 | 1949-01-01 | 1000 | |
| 118 | 1949-02-01 | 1000 | |
| 132 | 1949-03-01 | 1000 | |
| 129 | 1949-04-01 | 1000 | |
| 121 | 1949-05-01 | 1000 |
さらに注意すべきは、
- 予測したい数値は
yというカラムに入れる - 日付データは
dsというカラムに入れる
と、カラム名まで決めうちになっていることです。 こんな風に、データフレームを使うだけではなく、カラム名まで決めうちにするライブラリは珍しいですね。
また、Prophetは「上限値」を設定することが出来ます。capというカラムに指定してください。
from fbprophet import Prophet m = Prophet(growth='logistic') m.fit(df)
まず、モデルのインスタンスを作成し、fitメソッドでデータを食わせます。scikit-learnでよく見るスタイルですね。
また、上限値を設定する場合は必ずlogisticモデルを選択しなければいけません。
ちなみに、growthパラメータは'logistic'と'linear'の２択ですので、迷ったら両方試せば良いでしょう。
続いて、未来予測を行います。どれくらいの期間予測するのか設定しましょう。
statsmodelsではパラメータにより予測期間を設定しますが、Prophetでは未来のデータを収めるデータフレームを作ります。
これもかなり特異な部分ですが、ヘルパーメソッドが用意されているので、大して複雑ではありません。
future = m.make_future_dataframe(periods=36,freq='M') future['cap'] = 1000 forecast = m.predict(future)
今回のデータは月次データなので、freq='M'を指定しました。periods=36となっているので、３６ヶ月分のデータを予測することになります。
今回は上限値を設定したいので、futureデータフレームにもcapカラムを用意しています。
なお、capは定数でなくても構いません。
ある時期を境に、上限値が変わることが分かっているなら、そのように設定すれば、モデルはそれを元に予測を行います。賢い！
さて、こうして作られたforecast変数は、予測値の他、トレンドや季節性、信頼区間などのデータが入ったデータフレームです。
データフレームの中身を見てもいいですし、手っ取り早くplotメソッドで可視化も出来ます。
m.plot(forecast)
結果は上のようになります。上の点線が、設定した上限値です。
あっけないほど簡単に時系列予測が出来てしまいました。
まあ、実際には上限値の設定により予測値が大きくブレることもあったり、注意が必要ですが、かなりお手軽に使えるライブラリです。
Python界隈では、Rのforecastパッケージのような、扱いやすい予測ライブラリがありませんでした。Prophetはかなりいい位置にあるのではないでしょうか。
本家ドキュメントでは、クリスマスのように数値が跳ね上がる瞬間を、上手に扱う方法も紹介されています。極めてビジネス寄りの思想で作られたライブラリですね。
全自動BIツールとしてのGoogleスプレッドシート
前回の記事から二ヶ月ぶりくらいです。
放置しててすみません。私事ですが、色々ドタバタしていたもので……
さて、今日のお題はGoogleスプレッドシートです。
そもそもGoogleスプレッドシートって？
「あのGoogleが Excelパクったやつでしょ？」と思ったあなた、まあ、そんなに間違ってはいません。 関数とか、かなり完コピしてますし、一見してとても、その、すごくExcelです……
ですが、このスプレッドシート、Excelには無い素晴らしい機能があります。
サジェスト型BIツール
試しに、機械学習のお題によく使われる、irisデータセットを貼り付けてみました。
すると、画面右下に「データ探索」というボタンが出現し、クリックすれば……あら不思議。
Google先生が、私の代わりに散布図やらヒストグラムを描いてくれ、あれこれデータについて教えてくれます。
上記リンクのシートでは、散布図とヒストグラムを載せていますが、これはサジェストされたものを１クリックで載せたものです。
所要時間は、せいぜい３０秒くらいでしょう。
BIツールの現状と問題点
データの可視化に活躍するBIツール。
ですが、当然ながら、ユーザーは可視化について、ある程度の前提知識を求められます。
そして困ったことに、そんなことは学校教育で教わりません。
（理系に進んで研究をやっていれば別なんでしょうけど、私文系だったので……）
Googleスプレッドシートは、「何の可視化をすべきか」「データの要点は何か」を、向こうからサジェストしてくれます。
ユーザーは与えられた選択肢から選ぶだけです。まあ、的外れなサジェストもありますが、兎に角形にしてくれるわけです。
もし職場で、手っ取り早くデータ分析を広めたいのなら、Googleスプレッドシートは最適な入り口でしょう。
Excelのように煩雑なグラフ作成手順を踏む必要はありませんし、BIツールのように前提知識を求めません。
まあ、そのうちMicrosoftも似たような機能を載せてきそうですが、現状ではGoogleに一日の長がありますね。
DPCチェッカー ver0.4を公開しました
修正内容
- 問い合わせ結果がゼロ件だった場合、何の表示もなかったので、
データなしと表示するように修正 - レイアウトが崩れていたのを修正
現在の開発状況
現在、手探りでElectronを書いてますが、流石に限界なのでボイラープレートに乗っかろうと思ってます。
Electron-vueという、素晴らしいテンプレートがありますので、それを使おうかなあ……
Electron周辺は、とにかく動きが早くて追いかけるのが大変ですが、日々便利なツールが増えていく状況は楽しいですね！
JavaScriptの世界には、他には無い熱さがあります。
平成３０年度改定について
ざっと見たところ、EF／Dファイルには大きな変更は無さそうなので、このまま走ると思います。
ただ、実運用してみて変なバグが見つかったら、順次修正する予定です。
