エス・エム・エスのエンジニアの宮坂です。2022年1月に入社し、以来、介護事業者向け経営支援サービス「カイポケ」のリニューアル開発に携わっています。 今回は私が開発を担当している「介護報酬の算定ロジック開発」についてお話したいと思います。
介護報酬とは何か
そもそも介護報酬とは何でしょう？ 高齢になったり病気になったりして、周りのサポートがないと生活が難しい状態になってしまった場合、介護サービスを受けることになります。介護サービスは、提供したサービス内容や介護の必要度合いなどに応じて金額が定められていて、これを介護保険（一部、利用者負担）から介護サービスを提供した事業者に支払われます。これが介護報酬と呼ばれるものです。 介護保険は、法律によって40歳以上になると誰もが加入することになり、その保険料は毎月の給与などから引かれているので、介護を受けていない人も含めて介護サービスを支えていることになります。
難解な介護報酬の算定
この介護報酬、ちゃんと計算して請求しないと介護サービスを提供している事業者は収入を得られないので事業を続けられず困ってしまうのですが、この算定がすごく難しいのです。
提供される介護サービスにはそれぞれ「単位数」というものが定義されていて、提供した条件によってはさらに単位数が加算されます。その計算のルールが算定構造として国から提供されており、それをもとにロジックを組み立てていきます。こうして、算定した単位数に、地域ごとに定められた「地域単価」を掛けることで、介護報酬が決まります。（介護報酬 = 単位数 × 地域単価）
例えば、ある介護サービスの利用者に
- 「身体介護」という訪問介護のサービスを20分提供した
- 訪問は2人で行った
- その提供時間は「早朝」だった
とします。このときの地域単価が10円の場合の介護報酬は、
- 身体介護 20分以上30分未満 = 250 単位 … ①
- 2人の訪問介護員等による場合 = ① × (200/100) = 500 単位 … ②
- 夜間もしくは早朝の場合 = ② + ② × (25/100) = 625 単位 … ③
- 介護報酬 = ③ × 10 = 6,250 円
となります。このうちの利用者の負担額が1割とすると、
- 介護保険への請求額 = 6,250 × (1 - 0.1) = 5,625 円
- 利用者への請求額 = 6,250 - 5,625 = 625 円
となり、介護サービス事業者は、介護保険から 5,626 円、介護サービスの利用者から 625 円を受け取る計算になります。 (介護保険の自己負担は所得に応じて1割から3割までのいずれかとなります)
こういった単純なパターンであればそこまで難しくありませんが、介護報酬を算定する際には様々な条件を考慮しなくてはなりません。
- 単位数が加算される条件の考慮
- 図1 だと「緊急時訪問介護加算」は「身体介護」提供時にしか加算されない
- 利用者の介護度（どの程度の介護が必要なのかのレベル）
- 介護度に応じた介護保険から支払うことができる金額の限度額の考慮
- 生活保護などによる公費負担
- 利用者が引っ越しをした、介護度が変わったなど介護サービス提供中に発生した変更の考慮
などなど、挙げ出したらキリがないですが、介護報酬をキチンと計算するには、すべてのパターンを考慮した算定ロジックを実装する必要があります。このパターンとこのパターンを組み合わせた場合はどう算定したら良いのだろう…というような算定構造だけではわからない不明瞭なパターンも多くあり、様々な資料を読み漁りつつ、正確な算定を実装していく必要があり、ここが介護報酬の算定を難解にしている理由の一つでもあります。
3年に一度の介護制度の改正
もう一つ、介護報酬の算定にとって高いハードルがあります。それは3年に一度行われる報酬改定です。刻々と変わる社会の状況に対応するため、定期的に介護保険制度の見直しが行われています。これによって、今までの制度が更新されることもあれば、新しい制度が追加されることもあるので、これに対応して行かなければいけません。 報酬改定については以前にも記事にしているので、興味がある方はそちらもご覧ください。
この改正された制度は大半が4月から（一部は10月から）適用されるのですが、適用開始のギリギリまで正式決定されません。例えば令和3年の報酬改定では、令和3年3月31日に確定された旨が通知されました。お金に関わる計算なので、正確な実装を求められるのですが、制度の内容が不明瞭な中での短期間での開発が必要になり、開発の難易度が高くなっています。
もちろん、過去分の請求をしていない人たちも存在するため、制度改正前の介護報酬の算定もある程度の期間は維持しておかないといけません。これもロジックの実装の難易度を上げる要因となっています。
難解な算定ロジックと闘うために
だからといって、この部分の実装を諦めるわけにはいきません。介護報酬の算定とその請求処理はカイポケのコア機能です。これが正しく実装されなければ、プロダクトが成り立たないのです。
そこで、難易度の高い計算をより容易により正確に実装するため、様々なトライをしています。
新たな介護報酬算定ロジックの開発
度重なる報酬改定の短期間での開発で、継ぎ足し継ぎ足しの実装をしていった結果、既存の介護報酬の算定ロジックは非常に複雑度の高いものになっています。そこで、介護報酬の算定順序や算定に影響のある条件を整理し直して、介護報酬算定ロジックの開発を一から行っています。 先程ご紹介した算定構造はある程度のパターンを持った構造で表現できるので、これを元に算定ロジックの実装を進めています。一度算定構造の理解が誤っていて、実装を一からやり直しをすることがありましたが、理解度が上がった段階で整理をすることができたので、シンプルな設計に再構成することができました。 まだまだ完成には程遠いですが、短期間での報酬改定に対応できる算定ロジックを目指して開発を進めて行きたいと思っています。専門家によるテストケースの作成
紹介したとおり、介護報酬の算定には、様々なパターンが考えられ、すべてのパターンで正確に算定できる必要があります。算定ロジックの実装と並行して、ドメインエキスパートやQA、プロダクトオーナーなどエンジニア以外のロールの方々の知識を集結して、考えうるパターンを網羅したテストケースを作成してテスト実行を自動化しました。 これによって、実装の変更による不具合をすぐに検出し、品質の担保をしていきたいと思っています。
まとめ
介護報酬の算定の難解さと、その難解な算定ロジックとどのように闘っているかを紹介しました。正直、私も入社して1年ほどなので、まだまだわからないことだらけです…。 ですが、いろいろな知識を持ったチームメンバーと、難解なロジックを一つのアプリケーションに落としていく過程にやりがいも面白さを感じています。チームの雰囲気も良く、協力的なので、様々なトライをしながらの開発ができ、そういった環境もロジック開発の面白さを感じさせてくれる部分なのかなと思ったりしています。 まだまだ開発の半ばなので、一緒にチャレンジしてくれる仲間が必要です！少しでも興味を持ってもらえたら幸いです！
