介護報酬を請求する前に、サービスの提供実績と計画・契約を突き合わせて食い違いを出す

処理の起点を決める

毎月1日の朝7時に、前の月の実績を対象に動かします。 記録の入力は月末までに終える決まりにし、1日の朝には前月の実績がそろっている前提です。1日の朝に一覧が出ていれば、その日のうちに問い合わせを始められます。

3日と6日にも、もう一度回します。 1日の時点で入力が終わっていない記録や、ケアマネジャーから予定の変更が届いたものを反映するためです。再点検では、前回の一覧との差分だけを出します。 同じ件を毎回一から見直さないためです。

6日を最後にするのは、提出の期限から逆算しているからです。 兵庫県国保連合会の案内では、インターネット請求で7日までに届いた請求には事前チェックが行われ、エラーがあれば8日の午前中に事前審査結果のエラーリストが送られます。10日までに訂正したデータを送り直せば、その審査に間に合うとされています。事前チェックの有無や日程は国保連合会ごとに確かめてください。

トリガーは、介護ソフトのCSVが所定のフォルダに置かれたことでもかまいません。 最初は事務員が1日の朝に手動で出力し、置かれたことを合図にプログラムを動かす形で始められます。

入力データを集める

質を決めるのは、予定のデータがそろっているかです。 FAXで届いた予定を介護ソフトに入力していないと、実績だけの行がすべて「予定に無い実績」になります。予定の入力漏れと、本当に予定に無いサービスとが、区別できなくなります。

記録の本文は、AIの判定のためだけに取ります。 突き合わせの本体では使いません。本文を使うのは、判定の対象に絞った件だけです。

データの取得方法を決める

介護ソフトからは、実績、予定、計画、受給者の情報の4つをCSVで出力します。 出力の画面と列の名前はソフトごとに違うので、最初に列の対応表を作り、プログラムは対応表を見て列を読み替えます。 ソフトを入れ替えても、対応表を直すだけで済みます。

時間帯のキーには幅を持たせます。 予定が10時から、実績が10時5分からのような数分のずれは、同じサービスとして扱います。幅をいくつにするかは、事業所の運用で決めて設定値にします。 幅を持たせないと、ほぼ全件が食い違いになります。

記録の本文は、利用者番号・日付・開始時刻で実績につなぎます。 同じ日に2回訪問している利用者がいるので、日付だけではつなげません。

AIへ渡す前に整形する

1. 列の読み替え … 対応表に沿って、各CSVの列名をこの構成の共通の名前にそろえます
2. 重複の確認 … 実績と予定のそれぞれで、同じ利用者・日付・サービス・時間帯の行が2件無いかを validate で確かめます。重複があればつなぐ前に一覧に出します
3. 時間帯の丸め … 設定した幅で開始時刻をまとめ、キーにします
4. 期間の展開 … 認定の有効期間、契約の期間、計画の期間を、日付ごとに照合できる形にします
5. 判定の対象の抽出 … 加算の付いた実績と、予定からずれた実績を取り出し、記録の本文をつなぎます
6. 本文の置き換え … 記録の本文に含まれる利用者と家族の氏名、住所、電話番号を役割名に置き換えます
7. 本文の長さの確認 … 本文が空の記録は、AIに渡さずに「記録の本文なし」として一覧に出します

2番目を軽く見ないでください。 実績に重複があると、つないだ結果の行数が増え、同じ件が食い違いとして2回出るか、重複そのものが見えなくなります。 重複請求は返戻の原因の1つなので、ここで止める価値があります。

7番目の「本文なし」も、それ自体が確認の対象です。 加算を付けた日の記録に本文が無ければ、加算の根拠が記録に残っていないということです。

AIに処理させる

させるのは、1件の記録の本文を読んで、その日の算定の内容と合っているかを3つの観点で判定し、根拠の文を抜き出すことだけです。

判定の値は consistent（合っている）／ inconsistent（合っていない）／ unclear（判断できない）の3つです。

右端の unclear が、この構成でいちばん大事な値です。 「様子変わりなし」だけの記録に入浴の加算が付いているとき、それが入浴していない記録なのか、書き方が短いだけなのかは本文からは決まりません。決まらないものを consistent に寄せると、見つけたかった誤りが消えます。 迷ったら unclear にさせ、人に回します。

加算の根拠の観点では、要件を判断させません。 見るのは、「算定した加算に対応する行為が、その日の記録に書かれているか」だけです。加算の算定要件を満たしているかは、告示と通知に照らして人が判断します。

4行目がいちばん起きやすい失敗です。 入浴の加算が付いた日の記録に「入浴後、爪切り実施」とあれば、入浴の記載として読めます。「更衣介助実施」だけのときに、「入浴に伴う更衣と考えられる」と補わせてはいけません。

指示内容を固定する

あなたは介護事業所の請求事務で、サービス提供記録の本文が、
その日の算定の内容と合っているかを確かめる立場です。
渡された本文だけを見て判定してください。推測で補わないでください。

【判定する3つの観点】
1. cancel_or_change ... 本文に、サービスの中止、短縮、内容の変更が書かれているか
2. not_provided ....... 本文に、不在、キャンセル、入院など、
                        サービスが行われなかったことを示す記載があるか
3. addition_basis ..... 算定した加算それぞれについて、
                        対応する行為がその日の本文に書かれているか

【status の選び方】
- consistent ..... 本文の記載と算定の内容が合っている
- inconsistent ... 本文の記載と算定の内容が合っていない
- unclear ........ 本文からは判断できない
迷ったときに consistent を選ばないでください。

【厳守事項】
- 本文に書かれていないことを補わないでください。
  「おそらく実施した」「通常どおりと考えられる」と判断しないでください。
- addition_basis では、加算の算定要件を満たすかを判断しないでください。
  見るのは、対応する行為が本文に書かれているかどうかだけです。
- 算定できるか、実績を直すべきかは書かないでください。
- 単位数や金額に触れないでください。
- evidence には、判定の根拠にした本文の文をそのまま写してください。
  根拠にした文が無いときは空にし、status を unclear にしてください。
- 本文が空、または意味の取れない文字列のときは、すべての観点を unclear にしてください。

【その日の算定の内容】{billing_line}
【個別サービス計画に位置づけた加算】{plan_additions}
【サービス提供記録の本文】{record_text}

「迷ったときに consistent を選ばない」を明記しないと、短い記録はほぼ consistent になります。 「特変なし」と書かれた記録は、読みようによってはどの算定とも矛盾しません。矛盾しないことと、裏付けがあることは違うと、指示で分けます。

「算定要件を判断しない」も、書かないと起きます。 加算の名前を渡すと、AIはその要件を思い出して当てはめようとします。要件の当てはめは、本文の記載の確認とは別の仕事です。

出力形式を固定する

次の形のJSONで受け取ります。 スキーマは構造化出力の output_config.format に渡し、status の値を列挙で固定します。

{
  "line_id": "B-2026-09-0412",
  "checks": [
    { "aspect": "cancel_or_change",
      "status": "consistent | inconsistent | unclear", "evidence": "" },
    { "aspect": "not_provided",
      "status": "consistent | inconsistent | unclear", "evidence": "" },
    { "aspect": "addition_basis", "addition": "",
      "status": "consistent | inconsistent | unclear", "evidence": "" }
  ]
}

addition_basis は、算定した加算の数だけ要素を並べます。加算の無い実績では、この観点を出しません。

1つ目の理由は、AIの判定と規則の判定を同じ一覧に並べられることです。 プログラムの突き合わせは mismatch_type（予定だけ／実績だけ／時間帯のずれ／期間外／届出の無い加算／重複）を、AIの判定は checks を返します。どちらも行ごとの値なので、1つの表にまとめて並べ替えられます。

2つ目は、確認先を規則で決められることです。

要は、AIの出力を確認先の決定に直接使わないことです。 AIは観点ごとの status を返すだけで、誰に確かめるかはこの表が決めます。表を直せば、AIの指示を変えずに運用を変えられます。

3つ目は、evidence で問い合わせが速くなることです。 職員に確かめるときに、記録の本文のどの文が問題なのかを、そのまま示せます。

システムへ連携する

介護ソフトへは書き込みません。 実績を直すのは、記録を書いた職員に確かめた後の請求の担当者です。自動で直すと、職員が知らないうちに記録と実績が食い違います。 直した記録は、後の実地指導で経緯を問われます。

ケアマネジャーへの連絡も、自動では送りません。 一覧には問い合わせの文面の下書きを付けてもよいのですが、送るのは担当者です。 予定の変更は、居宅介護支援事業所の側の給付管理にも関わります。

人が確認する

請求の担当者は、一覧に出た件をすべて見ます。 一覧に出ない件、つまり規則でもAIでも食い違いが出なかった件は、件数だけを確かめます。

1. 期間外と重複を先に見る … 認定・契約・計画の期間外と重複は、そのまま送ると返戻になる型です。請求の期限に直結するので最初に片付けます
2. not_provided の inconsistent を見る … 不在やキャンセルが書かれているのに算定されている件です。記録を書いた職員に確かめ、実績を取り消すかを決めます
3. 加算の根拠を見る … inconsistent と unclear の件を、evidence と本文で確かめます
4. 予定とのずれをケアマネジャーに確かめる … 予定の変更で済むのか、実績の誤りなのかを相談します
5. 直した件を記録する … 何を、誰に確かめて、どう直したかを一覧に書き込みます

2番目を省かないでください。 行われなかったサービスが算定されたまま送られると、後から返還を求められる可能性がある誤りです。 返戻よりも重い結果につながります。

目標は、480件をならして1件1分です。 一覧に出るのは全体の1〜2割という想定で、それを大きく超える月は、予定の入力漏れか、時間帯の幅の設定を疑います。

例外に対処する

上の2行が、運用の初めに多く出ます。 どちらもプログラムの問題ではなく、予定の入力と受給者の情報の更新が追いついていないことの表れです。 一覧に出ることで、入力の遅れが毎月見えるようになります。

最後の行は、期限を優先して誤りを送らないための決まりです。 事前チェックで返戻になるより、確かめてから翌月に出すほうが、後の手間が少ないことがあります。

記録を残す

• 取り込んだCSVのファイル名と、取り出した日時
• 突き合わせの結果の全件（mismatch_type の無い件も含む）と、使った時間帯の幅の設定値
• AIに渡した本文（置き換え後）と、返ってきたJSONの全文
• 確認先と、問い合わせの結果、直した内容と直した人
• 再点検ごとの差分の一覧
• 居宅介護支援事業所ごとの「予定未入力」の件数と、職員ごとの「記録の本文なし」の件数

2つ目で、食い違いの無い件も残すのは、後で問われたときに点検したことを示すためです。 一覧に出なかった件も、どの規則で照合したかが分かります。

最後の行は、改善の材料になります。 特定の居宅介護支援事業所の予定が毎月未入力になるなら、ケアプランデータ連携システムでのやり取りを相談する材料になります。