DPCデータの分析とかやるブログ

DPCデータの分析なんかをテキトーにやってます。

レセ電パーサー:また破壊的変更をやりました……

こんばんは、スタゲイラです。
今回もレセ電パーサーに破壊的変更を加えました。 毎度すいません!

github.com

えー、さて。何があったかといいますと。 このレセ電パーサー、そもそもは『患者情報だけが見たい』『処方情報を集計したい』といった、個別情報を引っこ抜くために作成したものでした。
つまり、「レセプトを再現する」用途では、まったく考えてなかったんですね。
しかしながら、最近それに似た作業をやってたところ、恐ろしい文書に出くわしました。

支払基金電子レセプト作成手引きから引用です。

f:id:stagira:20210514211122p:plain
電子レセプト作成手引き_引用

なるほど。どうやら、レセプト行為には『一連番号』なるものが振られるようですね。
確かに紙レセプトを見ていたとき、番号が振られていました。
さて。ではこの番号はレセ電のどこに記録されているかというと……

……どこにも記録されていません!(白目

そう、この一連番号、審査のコンピューターが割り振るものなのです!
しかしこの番号がないと並び替えも出来ませんので、なくなく審査のロジック(と思しき物)をパーサーで再現しました。
それに伴い、Receオブジェクトの仕様も変更しています。以前はREなどのレコード情報をキーにしたディクショナリでしたが、順番通りのリストに変更しました。
とはいえ、REIYでデータが抽出できる仕様は残してあります。これがないと不便ですので。

前々から思っていましたが、レセ電UKEファイルの仕様は、「データ利活用をする」目的ではなく、「審査で紙印刷する」ためのものなのでは……? という疑念が拭えません。
ところどころ、「印刷プログラムが順番に読み取っていって、印字していく」ためとしか思えない仕様が散見されます。
(例えば、診療識別番号を『先頭にのみ』記録する仕様には、何ら合理的理由が見い出せません。明らかに、印刷を念頭に置いた仕様に見えます)
いつの日か、人間にも可読性があって、かつコンピューターにも優しいファイル形式になるといいなあ……
現状、どっちにも優しくないんですよね、このファイル形式。