実施単位数が算定上限を超えて登録できてしまう
疾患別の算定上限を超えた単位数の実施記録がそのまま登録され、請求段階で返戻・査定の対象になるおそれがあります。
ベンダーのテストでは範囲に入りにくい算定・連携部分を、発注側・ベンダーのいずれにも属さない第三者として設計し、検証から記録まで代行します。
支援実績5,000件以上













リハビリ部門システムの不具合は、療法士の操作画面だけで完結しません。実施記録の登録から電子カルテ・医事会計への連携、月末の請求処理まで、どの段階で起きるかによって表面化する時期と影響の出方が変わります。
疾患別の算定上限を超えた単位数の実施記録がそのまま登録され、請求段階で返戻・査定の対象になるおそれがあります。
同じ患者への予約が重複したまま通り、当日の担当割り当てが成立せず、受付で手作業の調整が発生してしまいます。
同意日が空欄でも記録を保存できてしまい、計画書の要件を満たさない実施分が加算の対象として算定されるおそれがあります。
部門システム側では登録済みでも連携先へ送信されず、電子カルテの記録と実施状況が食い違う状態が残ります。
締め後の修正や取消が当月の請求データへ反映されず、翌月以降も不整合が残り、医事課が原因の切り分けに追われます。
部門システムの更改・改修で検証しなかった範囲に不具合が残ると、稼働後の請求・記録・監査で表面化し、療法士と医事課の負担や収支に影響します。
動作させる前の設計書・仕様書の段階で、算定・帳票・連携・権限・移行の観点から照合します。稼働後に表面化する不整合の多くは、この段階の確認漏れに起因します。
報酬改定で変わる算定要件と、部門システムに登録された実施単位数の上限・加算区分の設定値を照合します。ベンダーの対応版を適用するだけでは、設定値が要件どおりかを医療機関側で確かめられません。
リハビリ総合実施計画書などの出力様式が、制度が定める帳票様式と一致するかを書面の段階で確認します。改定に伴う様式変更の反映漏れは、印刷・出力の段階でしか検出できず、稼働後の手戻りとなります。
製品ベンダーと電子カルテ・医事会計ベンダーの間で取り決めた連携項目と送信タイミングを、API定義と照合します。双方が自社範囲外と答えやすい接続部分こそ、文書の突合で責任範囲を固定します。
職種ごとの権限と運用ルールが、アクセス制御の設計書どおりに実装されるかを確認します。療法士・医事課・管理者で参照と更新の範囲が異なるため、運用ルールと設計の食い違いを稼働前に洗い出します。
旧システムから移す患者情報・実施記録・マスタの項目仕様を、DB設計書と照合します。移行時の欠落や桁・区分の変換誤りは初回の締め処理まで表面化しないため、移行前の照合が調査工数を左右します。
リハビリ部門システムのテストは、算定ロジック・連携・業務シナリオ・運用の工程ごとに設計し、各工程で確認する対象を分けます。
実施単位数と加算の算定ロジックを対象に、算定上限ちょうど・上限超過・下限未満などの境界値を意図的に発生させて検証します。計算結果が医事会計側の設定と一致するかを確認します。
電子カルテ・オーダリング・医事会計との間で、オーダー受領・実施記録・送信タイミングを双方向で検証します。どちらのベンダーのテスト範囲にも入らない接続部分を対象に含めます。
予約・受付・実施記録・計画書作成から月末の締めと請求データとの突合まで、実際の業務シナリオを通して検証します。稼働後の締めで不整合が表面化する前に確認します。
療法士が運用手順どおりに操作し、予約の重複や取消、権限外の操作などの異常系もあわせて確認します。現場の操作確認だけで検証範囲を閉じないことが前提です。
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
提示されたテスト項目書の抜けを見極める段階では、算定・連携・業務フローを起点に検証範囲を設計できるかが問われます。GENZは第三者の視点で項目書の十分性を点検し、判断に使える記録まで残します。
診療報酬の算定要件と、予約・受付・実施記録・計画書作成の流れを対応づけ、加算の境界値や記録漏れをテスト項目にします。
電子カルテ・オーダリング・医事会計との接続について、どの連携のどの方向をどこまで検証するかを見積もり時点で文書にします。
発注側・ベンダー側どちらのQA配置にも合わせ、ベンダーの作業を否定せず、療法士の運用手順どおりの受け入れテストを進めます。
テスト項目書・不具合票・報告書を成果物として残し、リリース判断やシステム監査、実地指導で検証範囲と結果を説明できる状態にします。
リハビリ部門システムの検証は、ご相談から報告書の納品まで次の流れで進みます。
検証してほしい業務シナリオや連携の構成、改修の時期を伺い、課題を整理します。
仕様書をもとに検証範囲と優先順位を決め、必要な工数と費用をお示しします。
決めた計画に沿ってテストを実施し、不具合票と進捗を随時ご共有します。
報告書を納品し、修正版について回帰テストで修正内容を確認します。
部門の人手を使わず受け入れテストを進める
お持ちのテスト計画とテスト項目書をもとに、GENZが検証範囲と優先順位、必要工数の考え方、回帰テストの要否をお示しします。受け入れテストの実施から報告書の作成まで担います。