改定後の算定基準と単位数の計算結果がずれる
介護報酬の告示や解釈通知の読み違いがあると、単位数の算定式そのものがずれます。直前の仕様修正に追いつけず、施行後も誤った金額を計算し続けます。
GENZ, Inc.
介護請求ソフト開発者へ
介護請求ソフトの
介護請求ソフト開発者へ
介護請求ソフトの請求・伝送を、出荷前に第三者の目で検証する
改定対応版の出荷判断に、第三者の検証結果を。給付管理票から請求明細・伝送までの流れを踏まえ、施行日に間に合うテストをGENZが設計・実行します。
支援事例
支援実績5,000件以上
介護請求ソフトで見逃されやすい不具合
介護請求ソフトの不具合は、金額の誤りとして導入先の請求業務に直接表れます。返戻や過誤として表面化するまで気づきにくいものが多く、改定対応でテスト期間が圧縮されるほど見逃しが増えます。
改定後の
給付管理票の実績と請求明細の計上内容が食い違う
給付管理票の実績と請求明細の計上内容が一致しないと、返戻や過誤の対象になります。帳票ごとにロジックが分かれる製品では、片方だけ改修が漏れます。
伝送する請求データが受付の条件を満たさない
受付の条件に合わない請求データは、伝送時にエラーとなります。要介護状態区分の成立条件を製品側で確かめていないと、締切当日に返戻が判明します。
利用者負担額の端数処理が想定した金額と異なる
利用者負担額の端数処理は、計算順序の違いでわずかな差が出ます。導入先の会計データと合わず、金額相違の問合せが請求期間に集中します。
サービス種別ごとの加算と減算が正しく選ばれない
加算・減算はサービス種別ごとに適用条件が分かれ、判定の組み合わせが増えます。特定の加算だけで誤判定が残ると、その導入先でだけ金額が合いません。
請求の不具合が導入先と自社に及ぼす影響
請求データの不具合は、返戻や過誤となって導入先の介護事業所へ届き、やがて自社の開発体制と収支へ戻ってきます。影響は段階を追って広がります。
テストの委託先を選ぶ前に確かめたい観点
介護請求ソフトのテストを外部へ委託する場合、選定によって改定対応版の確認が足りるかが変わります。汎用的なテストの実績だけでなく、介護保険の請求業務を前提に検証を組み立てられるかを確かめておく必要があります。
算定条件の解釈を共有できない委託先に頼むと、加算・減算の適用条件の読み違いが検証でも見過ごされ、特定の加算でだけ金額が合わない不具合が導入先で表面化するおそれがあります。
介護報酬の算定と請求業務の流れを前提に話せるか
単位数の算定式や加算・減算の適用条件、要介護状態区分ごとの明細の成立条件まで踏まえて話せる委託先かを確かめます。用語の説明から始まる相手では、圧縮されたテスト期間がさらに削られます。
確認する資料
- 算定条件対応表
- 加算減算の適用条件一覧
- 状態区分別の明細条件
伝送と受付結果の取り込みが範囲外だと、請求期間中に伝送エラーや金額相違が起きたとき、原因の切り分けを締切の動かない状況で進めることになり、緊急修正と暫定回避が同時に走るおそれがあります。
伝送と受付結果の取り込みまで範囲に含められるか
給付管理票と請求明細の出力だけでなく、伝送用データの生成と受付結果の取り込みまで範囲に含められるかを確かめます。伝送まわりを外すと、返戻の原因が操作か不具合かを切り分けられません。
確認する資料
- 伝送データの検証範囲
- 受付結果の取り込み手順
- 返戻時の切り分け手順
施行日からの逆算が組めない委託先では、仕様確定の遅れがそのまま検証の遅れになり、利用できる請求分の期限を越えて伝送ソフトの切り替え確認が終わらないおそれがあります。
制度改定の施行日から逆算した検証日程を組めるか
施行日から逆算して、仕様確定の遅れを織り込んだ検証日程を提示できるかを確かめます。利用できる請求分に期限が定められた伝送ソフトがある以上、期日に間に合わない計画は機能しません。
確認する資料
- 施行日逆算の日程表
- 仕様遅延時の再計画
- 対象バージョンの期限管理
検証結果が社内の説明に使える形で残らないと、出荷可否の判断が担当者の経験則に戻り、「どこまで確認したか」を管掌役員へ説明できないままリリース判定を迎えるおそれがあります。
検証の結果を社内の説明に使える形で記録できるか
確認した範囲と未確認の範囲、残存リスクが、出荷可否の上程資料にそのまま使える粒度で残るかを確かめます。担当者の所感に寄る報告では、管掌役員への説明が経験則に戻ります。
確認する資料
- 確認済み範囲の一覧
- 未確認範囲と残存リスク
- 不具合の証跡記録
配布形態やライセンスの区切りに合わせて入れない委託先では、サービス種別ごとの組み合わせの確認が落ち、優先度の低い組み合わせの不具合が未確認のまま残るおそれがあります。
自社の開発の進め方に合わせて検証を組み立てられるか
クラウド型かインストール型か、サービス種別ごとにライセンスが分かれるかといった自社の配布形態に合わせられるかを確かめます。検証の区切りが開発の単位とずれると往復が増えます。
確認する資料
- 配布形態別の検証区分
- ライセンス別の組合せ表
- 開発単位に沿った区切り
- 修正確認の往復手順
GENZが提供するテストの内容
介護請求ソフトの改定対応に特化し、算定ロジックから伝送までを第三者として検証し、結果を証跡として整理してお渡しします。
STEP 01
対象範囲とリスクの洗い出し改定内容と対象サービス種別から確認の順序を決めます
どう確かめるか
改定後の算定ロジックのテスト設計と実行の代行
告示・通知で見直される算定式、加算・減算の適用条件、コード体系をもとに、サービス種別ごとの組み合わせを網羅するテストケースを設計し、実行します。
- 01告示・通知の変更点と製品仕様の対応表を確認します
- 02対象となるサービス種別と加算の組み合わせを洗い出します
- 03前回削られた確認範囲と問合せ記録からリスクを整理します
OUTPUTテスト計画書と対象範囲表
STEP 02
テスト計画とテストケースの作成組み合わせを網羅するケースに落とします
どう確かめるか
給付管理票と請求明細の出力を突き合わせる検証
給付管理票と請求明細の出力が、利用者の要介護状態区分やサービス種別の条件に沿って成立するかを突き合わせ、金額の相違を帳票単位で確かめます。
- 01算定式と適用条件を網羅するテストケースを作成します
- 02給付管理票と請求明細の出力パターンを網羅して設計します
- 03伝送データの生成と受付結果を確かめる手順を定めます
OUTPUTテストケース一覧
STEP 03
テストの実行と不具合の報告発生条件と影響範囲を添えて報告します
どう確かめるか
伝送する請求データと受付結果の取り込み確認
製品が出力する伝送データが受付側の仕様に合うかを確認し、利用できる請求分に期限があるバージョンを跨ぐ前に、切り替えたあとの手順まで検証します。
- 01開発の進行に伴走し、区切りごとにテストを実行します
- 02不具合の発生条件と再現手順を添えて開発へ報告します
- 03確認できていない範囲を残存リスクとして一覧に整理します
OUTPUT不具合報告書と再現手順
STEP 04
修正後の再テストと結果の報告修正版を意図的に発生させて検証します
どう確かめるか
実施したテスト結果の記録と残存リスクの証跡整理
実施した範囲と未確認の範囲、不具合の発生条件を証跡として整理するため、リリース判定の場で残存リスクを所感ではなく記録に基づいて説明できます。
- 01修正後の版で同じ条件を意図的に発生させて検証します
- 02修正が他のサービス種別の算定へ及ぶ影響を確認します
- 03実施した範囲と結果を証跡として整理して報告します
OUTPUT検証結果と証跡一式
テストを外部へ任せることで変わること
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 施行日までの圧縮された期間でも確認を完了できる
- 給付管理・請求・伝送の流れを前提にしたテスト設計が得られる
- 人手不足で削っていた組み合わせまで網羅して検証できる
- 出荷判断と上程に使える証跡と記録が社内に残る
介護請求ソフトの開発体制に合わせた関わる形
介護請求ソフトの製品形態は、請求機能に絞ったものから記録・請求・経営資料までをひとつにまとめたクラウド型までさまざまです。GENZは開発の進行に伴走し、形態と開発体制に合わせてテストの段取りを組みます。
クラウド型の製品を継続的に改修する場合
記録から請求までをひとつの製品で扱うクラウド型は、改定の影響が複数機能へまたがります。機能ごとに先行検証し、請求まで通しで確認します。
インストール型の製品を更新する場合
サービス種別ごとにライセンスを分けるインストール型は、種別と加算の組み合わせが確認の軸になります。削ってきた裾まで網羅的に検証します。
介護保険と障がい福祉の両方に対応する場合
介護保険と障がい福祉の双方に対応する製品は、制度ごとに算定条件と様式が分かれます。影響範囲を切り分け、請求データの出力を確認します。
居宅介護支援など特定業務に絞った製品の場合
居宅介護支援に絞った製品は、ケアプランと実績の対応関係が請求の正しさを左右します。給付管理票から伝送までの流れに沿って検証します。
お問合せから開始までの流れ
改定対応のテストは、施行日から逆算した着手が鍵になります。相談から開始までの流れは次のとおりです。
お問合せと改定対応の現状の共有
改定の予定と対象のサービス種別、前回削った確認範囲をお聞かせください。
テスト対象範囲の確認とお見積
算定ロジックから伝送までのどこを対象にするかを整理し、見通しを示します。
ご契約とテスト計画の内容合意
範囲と期間のご合意のあと、テストの方針と報告の形を計画書に残します。
テストの開始と定例での進捗報告
開発の進行に伴走してテストを始め、不具合と未確認範囲を定例で報告します。
改定の施行日から逆算した検証のご相談
介護請求ソフトの検証範囲を、改定の期限から逆算して相談する
相談の場では、対象のサービス種別と改定の影響範囲を整理し、テスト範囲の切り分けと優先順位、伝送まわりの検証の要否までお示しします。上程に使える形で段取りが残ります。