サンプルテストケースを使用したヘルスケアドメインのテスト

テストを開始する前に、ヘルスケア分野の基本的な知識を簡単に学習しましょう。

ヘルスケアドメインのテスト

ヘルスケア領域のテスト ヘルスケアドメインテストの目的は、ヘルスケアアプリケーションの品質、信頼性、パフォーマンス、安全性、効率を確保することです。

ヘルスケア領域の基礎知識

医療システム全体は、病院または医療提供者 (医師) という単一の組織によって相互に織り込まれています。

他のエンティティには次のものが含まれます。

保険会社： メディケア、メディケイド、BCBS など
患者/消費者: 患者登録済み
規制当局： HIPAA、OASIS評価、HCFA 1500、UB92など
ヘルスケアおよびライフサイエンスソリューションベンダー

医療制度の基本用語

プロバイダー: 医療サービスの認可を受けた医療従事者（医師）、医療団体、診療所、研究室、病院など
請求： 健康保険会社に医療サービスの請求書の支払いを依頼する
ブローカ： 被保険者または将来の被保険者に代わって保険の交渉や調達を行う保険の専門家
ファイナンス： 医療費を支払う保険機関は、政府 (メディケアまたはメディケイド) または民間 (BCBS) です。
メディケア: 高齢者および永久障害者のための連邦健康保険プログラム
メディケイド： 低所得世帯や個人の医療費の支払いを支援する共同および州のプログラム
CPTコード: 現在の手続き用語コードは、医療、外科、診断サービスを説明するために設定された医療コードです。
HIPAA: 医師、病院、医療提供者、医療保険プランがサービスを提供するために従わなければならない一連の規則と規制です。

ヘルスケアのビジネスプロセス

ほとんどの医療機関は、システムがスムーズに機能するようにソフトウェアプログラムを適応させています。このソフトウェアシステムは、これに対処する各エンティティのすべての情報を XNUMX つの文書で提供します。

このシステム全体を XNUMX つの Web アプリケーションに相互接続するのは大変な作業ですが、それを効果的に動作させるのはさらに大きな作業です。この健康アプリケーションの厳格なテストは必須であり、さまざまなテスト段階を通過する必要があります。

このチュートリアルでは、

プロバイダーシステムのテスト

プロバイダー (医師/病院) システムのサンプルテストシナリオとテストケース:

シニア#	テストシナリオ	テストケース
1)	プロバイダーシステムへのアクセス	プロバイダーシステムでは、プロバイダーのデータを入力、編集、保存できる必要があります
2)	正の流れシステムテスト	さまざまなタイプのプロバイダーを入力し、プロバイダーの詳細を変更し、保存して問い合わせるシナリオが含まれています。
3)	負流システム試験	不完全なデータ、契約の発効日、システム内の既存のプロバイダーに関する詳細の入力を含むプロバイダー情報を保存できます。
4)	システム統合テスト	メンバーシステム、財務システム、請求システム、プロバイダーポータルへのフィードを検証します。また、プロバイダーポータルからの変更が各プロバイダーのレコードに入力されているかどうかを検証します。
5)	ポジティブフロープロバイダーのポータルテスト	ログインしてプロバイダーの詳細、請求ステータス、メンバーの詳細を表示します氏名、住所、電話番号などを変更する場合は変更お申し込みを行ってください。
6)	ネガティブフロープロバイダーのポータルテスト	無効なIDを持つメンバーの詳細を表示する無効な認証情報でログインする
7)	ポジティブフローブローカーポータルのテスト	ログインしてブローカーと手数料の支払いに関する詳細を表示します氏名、住所、電話番号等の変更お手続きをお願いします。
8)	ネガティブフローブローカーポータルのテスト	無効な資格情報でログインするシナリオを含める必要があります。

ブローカーシステムのテスト

ブローカーシステムのサンプルテストシナリオとテストケース:

シニア#	テストシナリオ	テストケース
1)	ブローカーシステム	ブローカーデータを編集、入力、保存できる必要があります会員システムからの保険料支払明細に基づく仲介手数料の計算
2)	ポジティブフローシステムのテスト	さまざまな種類のブローカーのブローカーレコードを入力、保存、編集しますアクティブなブローカーの場合、異なるプランを持つメンバーのそれぞれのレコードを含むフィードファイルを作成してコミッションを計算します。
3)	負流システム試験	不完全なデータを含むブローカーレコードを入力し、さまざまな種類のブローカー用に保存します異なるプランを持つメンバーのそれぞれのレコードを含むフィードファイルを作成することで、終了したブローカーの手数料を計算します異なるプランを持つメンバーのそれぞれのレコードを含むフィードファイルを作成することで、無効なブローカーの手数料を計算します
4)	システムテスト	金融システム、ブローカーポータル、会員システムなどの下流システムへのフィードの検証ブローカーポータルからの変更がそれぞれのブローカーレコードに組み込まれているかどうかを検証します

会員システムのテスト

メンバー (患者) システムのサンプルテストシナリオとテストケース:

シニア#	テストシナリオ	テストケース
1)	会員制度	メンバーの登録、回復、終了依存関係を削除して追加する保険料請求書を生成する保険料の支払いを処理する
2)	ポジティブフローシステムのテスト	現在、過去、将来の発効日を使用して、さまざまなタイプのメンバーを登録しますメンバーの問い合わせと変更翌月のアクティブ会員の保険料請求書を作成する過去、現在、将来の終了日が発効日よりも後のアクティブなメンバーを終了する終了したメンバーを現在、過去、将来の発効日を指定して再登録する終了した番号を復元する
3)	負流システム試験	データが不十分な場合は会員登録する解約した会員の場合は翌月の保険料請求書を発行する
4)	システム統合テスト	プロバイダーポータル、ブローカーポータル、財務システム、請求システムなどの下流システムへのフィードを検証します。メンバーポータルからの変更がそれぞれのメンバーレコードに組み込まれているかどうかを検証します支払いの詳細が記載されたメンバーポータルからのフィードで生成された保険料請求書の支払いを処理します。

請求システムのテスト

請求システムのサンプルテストシナリオとテストケース:

シニア#	テストシナリオ	テストケース
1)	クレーム制度	医療保険の請求は、会員だけでなく扶養家族の請求も編集、入力、処理する必要があります。無効なクレームの場合、間違ったデータが入力されたときにエラーがスローされるはずです
2)	ポジティブフローシステムのテスト	メンバーおよび扶養家族の請求を編集、入力、処理するシナリオを含める必要があります。
3)	負流システムのテスト	無効な手順コードと診断コードを含む請求を検証して入力する必要があります非アクティブなプロバイダー ID を使用してクレームを検証し、入力します。終了したメンバーに対する請求を検証して入力する
4)	システム統合	プロバイダーや金融ポータルなどの下流システムへのフィードを検証するシナリオを含める必要があります。

財務システムのテスト

財務システムのサンプルテストシナリオとテストケース

シニア#	テストシナリオ	テストケース
1)	財務システム	メンバーの登録、回復、終了
2)	ポジティブフローシステムのテスト	支払いのために各メンバー、プロバイダー、またはブローカーに対して正しい口座番号または住所が選択されているかどうかを確認する必要があります。
3)	ネガティブフローシステムのテスト	フィードにそれぞれのレコードを作成して、無効なメンバー、プロバイダー、またはブローカー ID に対して支払いが行われたかどうかを確認します。フィード内にそれぞれのレコードを作成して、メンバー、プロバイダー、またはブローカーに対して無効な金額で支払いが行われたかどうかを確認します。

規制遵守のテスト

患者の機密データと健康情報を保護することは、医療規制機関にとって最優先事項です。テストはそのような規制機関に従って行われるべきです。

規制遵守のためのサンプルテストシナリオとテストケース:

シニア#	テストシナリオ	テストケース
1)	ユーザーの認証	検証方法を使用して、正しいユーザーがログインを取得し、他のユーザーは拒否できることを確認します。
2)	開示情報	情報へのアクセスの承認は、ユーザーの役割と患者の制限に基づいて行われます
3)	データ転送	すべての転送において、ポイントによりデータが暗号化されることが保証されます
4)	監査証跡	すべてのトランザクションと、適切な監査証跡情報のセットを使用してデータにアクセスするすべての試行が記録されます。
5)	規制機関に関連する健全性テスト	健全性テストを実行し、EPHI（電子保護医療情報）などの特定の領域でデータの暗号化が行われていることを確認します。

ヘルスケアアプリケーションのパフォーマンステスト

テストシナリオを準備する前に、システムの特定の要件を考慮する必要があります。たとえば、医療提供者 (医師/病院) は 24 時間 7 日ケアを提供するため、患者チェックインソフトウェアは常に利用できる必要があります。また、保険会社と通信してポリシー情報を検証し、請求を送信し、送金を受け取る必要があります。ここで、アーキテクチャは、システムのさまざまなコンポーネント、保険会社と通信するためのプロトコル、および 24 時間 7 日準拠するようにシステムを展開する方法を定義する必要があります。

テスターは、ヘルスケアソフトウェアシステムが望ましい負荷/パフォーマンスベンチマークを満たしていることを確認する必要があります。

医療用途向けのその他の検査タイプ

機能テスト: ヘルスケアアプリケーションの機能テスト
適合性テスト: 適合性テスト医療セキュリティ要件と業界の枠組み
プラットフォームのテスト: でのアプリケーションのテストモバイルプラットフォームとアプリケーションのブラウザ間の互換性テスト
相互運用性テスト: 相互運用性標準への適合性のテスト (例: DICOM、HL7、CCD/CDA)

医療アプリケーションにおけるテストの課題

ヘルスケアアプリケーションのテストにおけるテストの課題は、他の Web アプリケーションのテストと何ら変わりません。

テストには専門知識が必要であり、通常はコストが高くなります
通常のテスト手法（非機能テスト、機能テスト、統合テスト）に加えて、相互運用性、コンプライアンス、規制、セキュリティ、安全性のテストが必要です。
検査は安全性と規制基準を念頭に置いて行う必要があります。エラーは患者の生命に直接影響を与える可能性があるためです。
テストチームは、ソフトウェアが使用されるさまざまな機能、臨床用途、環境をよく理解する必要があります。
ヘルスケア製品は、使用する前に FDA、ISO、CMMI などのさまざまな規格に準拠する必要があります。
ソフトウェアの相互依存性 - テスターは、XNUMX つのコンポーネントまたはレイヤーでの変更が他のコンポーネントまたはレイヤーに副作用を引き起こさないことを確認する必要があります。

ヘルスケア機器のテスト

ヘルスケアデバイスのソフトウェアは患者の直接の関心事ではありませんが、別のソフトウェアテストと同様に厳格なテストも必要です。たとえば、ソフトウェアプログラムで制御される X 線装置は、ソフトウェアでのテストエラーが患者に深刻な影響を与える可能性があるため、十分にテストする必要があります。

FDA (食品医薬品局) には、医療機器のモバイルおよび Web アプリケーションに関するガイドラインがあります。医療機器の適切な機能をテストする際に、テスト計画合否基準とともに、FDA ガイドラインの一部でもあります。試験計画が実行されると、結果が収集され、FDA に報告されます。このプロセスにより、デバイスが規制機関の基準を満たしていることが保証されます。

ヘルスケア検査に関する役立つヒント

ソフトウェアをテストするときは、医療システムのテストに関する重要なヒントをいくつか検討してください。

日付は重要であり、正確である必要があります
テストケースを設計する際には、さまざまなタイプのプラン、ブローカー、メンバー、手数料などのさまざまなパラメーターを考慮します。
ドメインに関する完全な知識が必要です