こうすれば、データ処理は容易になる デジタルレセプトの仕様の改 善 医療情報学連合大会 元旭ファイバーグラス健康保険組合 常務理事 時松 衆一
はじめに： レセプトデータの活用の現 段階 １．未コード化病名の実態と使用禁止を ２．来年度からの算定日記載使用の問題 点 ３．コメントレコードの自由記載形式の 問題 とくに、日付データの記載につい て 目 次
デジタルレセプトの画面表示 レセプトを再構成して、 加入者の保健指導に活 用している レセプト内容の点検審査が目的ではない 市販３万円データベースソフトで、出来る
生活習慣病は、 374 分類でも分析不 能 １．糖尿病は、１型２型区分あるものは、２割のみ ２．高脂血症も「 0410 」以外にもかなりある ３． 高尿酸血症は、 ICD10 での抽出、それでも「痛風」は別コード
厚生労働省の標準病 名使用の通知 保険請求は標準病名 ( 病名コード ) で出来るはず
厚生労働省の標準病名例
未コード化病名の例と支払基金によるコード化の 実例 多くの未コード化病名は、レセコンの仕様変更で対応で きる
来年度からの医科レセの点数算定日の記載方式 高額レセの日計表方式 ( 横持ち ) で、データ分析はどうなるか
現行ＤＰＣのコーディングレコード記載 方式 日付の記入列 ( フィールド ) が一定
現行高額レセの日計表ハードコピー
検査施行日時の記載例 標準のコードを使用せず、自由記載の を使用するものが多 い
横持ち方式 は悪いテー ブル設計！ －ＤＢ設計 者の常識 「達人に学ぶ ＳＱＬ徹底指南書」（翔栄社刊 2008 ）
算定日付の記載方式の変更が必要 １．日時が記載されるのではなく、回数・数量が 記載されているだけ ２．統計分析に使用するためには、縦持ち方式に 変更する必要がある ３．現行のＤＰＣコーディングレコード記載方式 を基準にしたも型が良い ４．日時のデータ型は、日付型を採用すべき － 数値型 ７桁和暦はやめるべき
( 退院日 6/15) ( 退院日 25 日 ) ( 退院日 :23 年 3 月 1 日 ) [ 退院日 平成 23 年 06 月 18 日 ] 退院 日 退院日 (9 月 7 日 ) ※ 22 年 12 月 25 日 退院 25 日 退院 7 月 21 日退院 22 年 08 月 12 日 退院 23 年 5 月 24 日退院 軽快 平成 22 年 7 月 26 日 退院 退院日 22 年 06 月 10 日 退院 22 年 10 月 21 日 整形科 退院日 平成 22 年 6 月 11 日 退院日 平成 22 年 08 月 20 日 退院日 H22 年 7 月 10 日 当月内 平成 22 年 7 月 26 日 退院 入退院歴 : 平成 21 年 10 月 13 日～平成 21 年 10 月 15 日 こんなにある退院日の自由記載
尿中一般物質 22 日 (08 月 04 日救急当番日 ) (03 月 06 日 18 時 21 分 ) (06/29 検査施行 ) (07/04 検査施行 ) ( 1, 3, 6, 8,10, 15,17,20,22,24 日 ) (14 時 10 分麻酔開始 ) (14 時 35 分手術開始 ) (22 年 10 月 7 日～ 22 年 11 月 15 日 ) (4) 急性増悪 (07 月 23 日 ) (6/25 AM10:30) (H22 年 5 月 20 日～ H22 年 6 月 16 日 ) ( ドッグより )(22 年 12 月 20 日受診 ) ( 院内 検査日 18 日 ) ( 開始日 22 年 7 月 3 日～ ) ( 緊画 ) 16 日 14 時 05 分 ( 検査実施日 :12/21),( 検査実施日 :12/25) ( 交付日 23 年 5 月 30 日 ) ( 算定開始日 :07 月 24 日 ) 自由記載算定日のいろいろ
文字列で自由記載の日付を 機械的にどう変換すればよいのか １．文字列型日付から、年・月・日・時・分・回数などを 抽出する（ 0 サプレス有無も混在） ２．抽出した文字列型数字を、数値に変換 ３．その数値が、年月日時分のどれに該当するかを識別 ４．その数値を組合せ、日付変換関数で、日付表示する。 ５．その他 その前に日付がどのフィールドに入っている か確認しておく前処理が必要。 こんな事は、膨大な投資をした審査機関のプロ グラムしか対応できない。多分それでも無理
デジタルレセプトの仕様改善を １．全レコードに「主キー」を設定すること ２．各項目（フィールド）は、識別コードが異なっても、 データ型（文字列・数値・日付）別にすること ３．日付・時刻は、日付型（シリアル値）を使うこと ４．加算項目・医師名などのデータ「横持ち」方式はやめる ５．コメントレコードは、マスターコードを整備すること これだけ実現すれば、データ処理は大変容易になる。 当然、点数コードは加算一体型コードが前提だが。