GENZ, Inc.

第三者検証のご提案 リハビリ部門システムのテストを第三者視点で代行します

ベンダーのテストでは範囲に入りにくい算定・連携部分を、発注側・ベンダーのいずれにも属さない第三者として設計し、検証から記録まで代行します。

支援事例

支援実績5,000件以上

支援実績を示す企業ロゴ 01
支援実績を示す企業ロゴ 02
支援実績を示す企業ロゴ 03
支援実績を示す企業ロゴ 04
支援実績を示す企業ロゴ 05
支援実績を示す企業ロゴ 06
支援実績を示す企業ロゴ 07
支援実績を示す企業ロゴ 08
支援実績を示す企業ロゴ 09
支援実績を示す企業ロゴ 10
支援実績を示す企業ロゴ 11
支援実績を示す企業ロゴ 12
支援実績を示す企業ロゴ 13

この記事はソフトウェアテストの専門家が監修しています

監修枡井 愼治株式会社GENZ 代表取締役

GENZは創業以来、5,000件以上のソフトウェアテスト・第三者検証を手がけてきたプロフェッショナルです。品質に関する課題やお悩みに、真摯に寄り添います。

代表取締役 枡井 愼治 株式会社GENZ 〒101-0062 東京都千代田区神田駿河台2-3-11 ヒューリック御茶ノ水ビル3F TEL:03-5244-4711
01 ISSUES

リハビリ部門システムでよくある不具合

リハビリ部門システムの不具合は、療法士の操作画面だけで完結しません。実施記録の登録から電子カルテ・医事会計への連携、月末の請求処理まで、どの段階で起きるかによって表面化する時期と影響の出方が変わります。

実施単位数が算定上限を超えて登録できてしまう

疾患別の算定上限を超えた単位数の実施記録がそのまま登録され、請求段階で返戻・査定の対象になるおそれがあります。

算定上限

同一時間帯のリハビリ予約の重複が受付時に検知されない

同じ患者への予約が重複したまま通り、当日の担当割り当てが成立せず、受付で手作業の調整が発生してしまいます。

予約受付

計画書の同意日が未入力のまま実施記録を登録できる

同意日が空欄でも記録を保存できてしまい、計画書の要件を満たさない実施分が加算の対象として算定されるおそれがあります。

計画書管理

部門システムへ登録した実施記録が電子カルテ・医事会計へ反映されない

部門システム側では登録済みでも連携先へ送信されず、電子カルテの記録と実施状況が食い違う状態が残ります。

システム連携

締め後に修正した記録と取消が請求データへ反映されず不整合が残る

締め後の修正や取消が当月の請求データへ反映されず、翌月以降も不整合が残り、医事課が原因の切り分けに追われます。

請求処理
02 RISK

残存した不具合により生じる問題

部門システムの更改・改修で検証しなかった範囲に不具合が残ると、稼働後の請求・記録・監査で表面化し、療法士と医事課の負担や収支に影響します。

業務上の問題対応を行う担当者の様子を写した写真。
03 REVIEW

静的テスト(レビュー)でおさえるべき観点

動作させる前の設計書・仕様書の段階で、算定・帳票・連携・権限・移行の観点から照合します。稼働後に表面化する不整合の多くは、この段階の確認漏れに起因します。

照合しない場合、加算区分の設定誤りが算定結果に残り、返戻・査定の対象となります。

算定要件とマスタ設定値(実施単位数の上限・加算の区分)を照合する

報酬改定で変わる算定要件と、部門システムに登録された実施単位数の上限・加算区分の設定値を照合します。ベンダーの対応版を適用するだけでは、設定値が要件どおりかを医療機関側で確かめられません。

確認する資料
  • 算定要件一覧
  • マスタ設定表
  • 改定対応仕様書
照合しない場合、様式不一致の計画書が発生し、加算の算定根拠を監査で説明できなくなります。

計画書の出力様式と制度が定める帳票様式を照合する

リハビリ総合実施計画書などの出力様式が、制度が定める帳票様式と一致するかを書面の段階で確認します。改定に伴う様式変更の反映漏れは、印刷・出力の段階でしか検出できず、稼働後の手戻りとなります。

確認する資料
  • 帳票様式定義
  • 出力仕様書
  • 制度告示資料
照合しない場合、接続部分の不整合がどちらのテスト範囲にも入らないまま稼働へ進みます。

電子カルテ・医事会計とのAPI定義と連携項目の取り決め文書を照合する

製品ベンダーと電子カルテ・医事会計ベンダーの間で取り決めた連携項目と送信タイミングを、API定義と照合します。双方が自社範囲外と答えやすい接続部分こそ、文書の突合で責任範囲を固定します。

確認する資料
  • API定義書
  • 連携取決書
  • 送信タイミング表
照合しない場合、意図しない権限のまま運用が始まり、記録の修正経緯を追跡できなくなります。

職種・権限の運用ルールとアクセス制御の設計書を照合する

職種ごとの権限と運用ルールが、アクセス制御の設計書どおりに実装されるかを確認します。療法士・医事課・管理者で参照と更新の範囲が異なるため、運用ルールと設計の食い違いを稼働前に洗い出します。

確認する資料
  • 権限設計書
  • 職種運用規程
  • アクセス制御表
照合しない場合、移行誤りが月末の締め処理で初めて表面化し、手作業での突合が常態化します。

移行データの項目仕様と旧システムのDB設計書を照合する

旧システムから移す患者情報・実施記録・マスタの項目仕様を、DB設計書と照合します。移行時の欠落や桁・区分の変換誤りは初回の締め処理まで表面化しないため、移行前の照合が調査工数を左右します。

確認する資料
  • DB設計書
  • 移行項目仕様書
  • 変換ルール表
  • 旧帳票サンプル
04 TEST DESIGN

動的テストの設計・実行のポイント

リハビリ部門システムのテストは、算定ロジック・連携・業務シナリオ・運用の工程ごとに設計し、各工程で確認する対象を分けます。

STEP 01 算定ロジックのユニットテスト算定上限の境界値を項目に含めます
どう確かめるか

ユニットテスト:実施単位数と加算の計算を境界値で検証する

実施単位数と加算の算定ロジックを対象に、算定上限ちょうど・上限超過・下限未満などの境界値を意図的に発生させて検証します。計算結果が医事会計側の設定と一致するかを確認します。

  • 01単位数と加算の境界値テスト項目を作成します
  • 02算定結果と医事会計側の設定を照合します
  • 03上限超過時の判定結果を確認します
OUTPUT算定結果の正しさ
STEP 02 連携部分の統合テスト接続部分の責任範囲を事前に確定します
どう確かめるか

統合テスト:電子カルテ・医事会計との連携を双方向で検証

電子カルテ・オーダリング・医事会計との間で、オーダー受領・実施記録・送信タイミングを双方向で検証します。どちらのベンダーのテスト範囲にも入らない接続部分を対象に含めます。

  • 01連携の項目仕様と送信タイミングを整理します
  • 02双方のテスト範囲に入らない接続部分を洗い出します
  • 03送受信の結果を双方向で検証します
OUTPUT連携データの整合
STEP 03 業務シナリオのシステムテスト締めと突合までをシナリオに含めます
どう確かめるか

システムテスト:オーダー受領から締めと突合までの業務シナリオを通して検証する

予約・受付・実施記録・計画書作成から月末の締めと請求データとの突合まで、実際の業務シナリオを通して検証します。稼働後の締めで不整合が表面化する前に確認します。

  • 01予約から実施記録・計画書までの手順を通します
  • 02月末の締め処理と請求データとの突合を検証します
  • 03制度変更後の算定要件とマスタ設定値を照合します
OUTPUT業務手順の成立
STEP 04 現場運用での受け入れテスト異常系の操作手順を項目化します
どう確かめるか

受け入れテスト:運用手順どおりに操作し、異常系も確認する

療法士が運用手順どおりに操作し、予約の重複や取消、権限外の操作などの異常系もあわせて確認します。現場の操作確認だけで検証範囲を閉じないことが前提です。

  • 01運用手順書どおりの操作を現場と確認します
  • 02予約の重複・取消などの異常系を発生させて検証します
  • 03検証した範囲としなかった範囲を記録に残します
OUTPUT運用での再現性
05 RATIONALE

GENZが代行するリハビリ部門システムのテストの種類

固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。

OUTSOURCING RATIONALE THIRD-PARTY VERIFICATION

必要な時に必要な分だけ

人日単位のアサインで固定費を抱えず、繁忙期に増減できます。

独立した視点で品質を底上げ

独立した検証で偏りを排し、監査に使える客観的な記録を残せます。

専門ノウハウを即戦力で

JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。

ノートPCを前に担当者同士が相談しているオフィスの写真。

専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット

  • 算定要件とマスタ設定値の照合テスト
  • 電子カルテ・医事会計との連携テスト
  • 療法士の運用手順に沿った業務シナリオテスト
  • 制度改定対応版の適用範囲の検証テスト
06 SERVICE

要件と業務フロー起点のテスト支援

提示されたテスト項目書の抜けを見極める段階では、算定・連携・業務フローを起点に検証範囲を設計できるかが問われます。GENZは第三者の視点で項目書の十分性を点検し、判断に使える記録まで残します。

SVC 01

算定要件と業務フローを起点にテスト設計する

診療報酬の算定要件と、予約・受付・実施記録・計画書作成の流れを対応づけ、加算の境界値や記録漏れをテスト項目にします。

リスク要因と優先順位を示す無文字の図解。
SVC 02

電子カルテ連携も検証範囲に

電子カルテ・オーダリング・医事会計との接続について、どの連携のどの方向をどこまで検証するかを見積もり時点で文書にします。

複数のシステムや連携先にまたがる確認範囲を示す無文字の図解。
SVC 03

既存の体制とQA配置に合わせて伴走

発注側・ベンダー側どちらのQA配置にも合わせ、ベンダーの作業を否定せず、療法士の運用手順どおりの受け入れテストを進めます。

計画から報告までの流れを示す無文字の図解。
SVC 04

監査に使える報告書と不具合票を納品

テスト項目書・不具合票・報告書を成果物として残し、リリース判断やシステム監査、実地指導で検証範囲と結果を説明できる状態にします。

確認対象の領域を区分して示す無文字の図解。
07 FLOW

ご相談から納品までの流れ

リハビリ部門システムの検証は、ご相談から報告書の納品まで次の流れで進みます。

ご相談とヒアリング

検証してほしい業務シナリオや連携の構成、改修の時期を伺い、課題を整理します。

テスト設計と見積もりのご提示

仕様書をもとに検証範囲と優先順位を決め、必要な工数と費用をお示しします。

テストの実施と結果の共有

決めた計画に沿ってテストを実施し、不具合票と進捗を随時ご共有します。

報告書の納品と修正後の再確認

報告書を納品し、修正版について回帰テストで修正内容を確認します。

部門の人手を使わず受け入れテストを進める

リハビリ部門システムの検証範囲と優先順位をGENZにご相談ください

お持ちのテスト計画とテスト項目書をもとに、GENZが検証範囲と優先順位、必要工数の考え方、回帰テストの要否をお示しします。受け入れテストの実施から報告書の作成まで担います。