how test health care application part 1
ヘルスケアドメインの理解とヘルスケアアプリケーションのテスト：
今日の記事は、ヘルスケア-ドメイン/ビジネス情報、コンポーネント、何をテストするか、そしてどのようにテストするかについてのすべてになるでしょう。
この2部構成の記事シリーズは、ヘルスケアアプリケーションのワークフローをテスト、学習、理解するために別のドメインを探索して入力したい人に役立ちます。 テストプロセス 。
要するに、この記事はあなたの最初のステップであり、あなたのヘルスケア知識の探求のガイドになります。に パート2 Healthcareドメインのさまざまなアプリケーションのテストシナリオを提供します。
テストに優れているために、 ドメイン知識が鍵です 。それで、私たちは今、クライアントのビジネスフローについて学びます。
学習内容：
ヘルスケアドメイン-はじめに
ヘルスケアまたは健康保険は損害保険に似ています。ご存知のように、どの保険でも、保険会社（保険会社）がプランを提供し、顧客（加入者または保険契約者）が希望するプランの保険を購入します。保険会社は保険契約者から保険料を受け取り、保険契約者は保険会社から提出した有効な請求に対して払い戻しを受けます。
xboxoneで動作するvr
医療保険でも同じことが起こりますが、保険会社と保険契約者に加えて、プロバイダー、TPA（サードパーティ管理者）、ブローカーなどの他の主要な貢献者がいます。
ここで、主要な貢献者のそれぞれについて詳しく説明します。
＃1）保険会社： プランを作成し、ポリシーを販売し、提出された有効な請求について保険契約者またはプロバイダーに払い戻しを行うエンティティ。
＃2）保険契約者： 保険会社またはブローカーから保険証券を購入する個人または団体は、保険会社に保険料を支払い、場合によっては請求を提出します。
Javaと比較したC ++
＃3）プロバイダー： 保険契約者とその扶養家族に医療サービスを提供する個人または団体は、請求を提出することにより、保険契約者または保険会社からサービスの支払いを受け取ります。
＃4）TPA： 保険契約者またはプロバイダーの請求を管理し、それぞれの寄稿者から管理の支払いを受け取る個人または団体。
＃5）ブローカー： ご想像のとおり、彼は保険会社に代わって顧客に保険証券を販売し、保険会社から手数料を受け取る代理人です。
例えば、 以下の例から、寄稿者の基本的な機能を理解することができます。
Enosh氏は、Ponnar氏から一般的な医師の診察と視力の問題をカバーする医療保険を購入し、医療会社にその保険料を支払いました。
エノス氏が病気になり、回復のために医師のサバリ氏に相談すると、サバリはエノスに処方箋を提供し、HealthCorp Companyに相談の請求を提出し、償還を受けます。 Ponnar氏は、HealthCorpCompanyからEnosh氏による保険料の支払いの手数料を受け取ります。
上記の例では、「General PhysicianConsultation」と「VisionProblems」が健康保険のメリットであり、Enosh氏が保険契約者、Ponnar氏がブローカー、HealthCorp Companyが保険会社、Sabari氏がプロバイダーです。
ポリシーとプランの違いを明確に理解するには、プランをクラスとして、ポリシーをオブジェクト（クラスのインスタンス）として考えてください。ポリシーは、対象となる受益者のタイプに基づいて、個別ポリシーとグループポリシーに分類できます。
個人方針： 個人が保険契約者になります。個人とその扶養家族の両方が健康保険の恩恵を享受します。ここでは、個人が保険料を支払います。
グループポリシー： 事業体（通常は雇用主）が保険契約者となり、事業体のメンバー（従業員）とその扶養家族は健康保険の恩恵を享受します。ここで、エンティティはプレミアムを支払います。
例えば、 グループポリシーを明確に理解するための例は次のとおりです。
MotoCorp Companyは、HealthCorpCompanyから従業員とその家族のためのポリシーを購入します。彼らの主張はEasyClaimCompanyによって管理されています。ここで、MotoCorp Companyは保険契約者、HealthCorp Companyは保険会社、EasyCliamCompanyはTPAです。
ヘルスケアアプリケーションをテストする方法は？
アプリケーションをテストする前に、ヘルスケア業界のワークフローを知っておく必要があります。前のトピックは、マネージドヘルスケアの概要を示しています。詳細は次のとおりです。 ここで入手可能 。
保険会社は、以下を管理するためにさまざまなアプリケーションを必要としています。
- プロバイダーデータ
- メンバーデータ
- プレミアム請求/支払い
- ブローカーデータ
- クレーム入力/検証
- ブローカー手数料の計算/支払い
一般に、ヘルスケアアプリケーションには次のシステムのリストがあります。
- メンバーシステム ：保険契約者データを維持するために、さまざまなプランとその特典のリスト、およびプランに基づいて保険契約者の保険料請求書を生成します
- プロバイダーシステム ：プロバイダーデータを維持するため
- ブローカーシステム ：ブローカーデータを維持し、手数料を計算する
- クレームシステム ：クレームの入力と検証用
- 金融システム ：プロバイダー/メンバー/ブローカーに必要な支払いを行うため
- メンバーポータル ：保険契約者情報を表示するには、保険料を支払い、保険契約者の変更情報を要求します
- プロバイダーポータル ：プロバイダー情報を表示し、プロバイダーの変更情報の要求を出すため
- ブローカーポータル ：ブローカー情報を表示し、ブローカーの変更情報の要求を発生させる
これは完全なリストではないかもしれません。しかし、これは私の知る限りのリストです。また、すべてのアプリケーションが使用されるとは限りません。これらのアプリケーションのいくつかをマージして別の組み合わせアプリケーションを作成する場合もあれば、スタンドアロンシステムである場合もあります。
例えば 、プロバイダーシステムは、一部のヘルスケアアプリケーションのメンバーシステムの一部にすることができます。ヘルスケアアプリケーションとは、顧客やパートナーを支援するために保険会社が維持する一連のシステムを意味します。
経験豊富な人のための手動テスト面接の質問と回答
ヘルスケアアプリケーションテストワークフロー
ヘルスケアシステムのユニークな特徴は、これらのアプリケーションを私たちが好きな順序でテストできないことです。従うべき特定のワークフローがあります：
- メンバー/保険契約者が健康保険に加入するには、プロバイダー（プライマリケア医）またはプロバイダーネットワークに割り当てられる必要があるため、メンバーシステムが割り当てられたプロバイダーを検証する方法が必要です。メンバーシステムがプロバイダーシステムに接続するか、データフィードがプロバイダーシステムからメンバーシステムに定期的に送信される必要があります。したがって、プロバイダーシステムをテストし、メンバーシステムをテストする前に使用できるようにする必要があります。
- クレームは、他の詳細に加えて、プロバイダーIDとメンバーIDで構成する必要があります。クレームシステムは、メンバーとプロバイダーの両方を検証してクレームを検証する必要があるため、クレームシステムをテストする前に、メンバーとプロバイダーの両方のシステムをテストして使用できるようにする必要があります。
- 金融システムは、小切手を書いたり、それぞれの個人またはエンティティにEFT支払いを行ったりするために、メンバー、プロバイダー、クレーム、ブローカーシステムからのデータを持っている必要があります。
- プロバイダーとブローカーのシステムはスタンドアロンです。
- ポータルは他のアプリケーションからのデータを必要とするため、最後にテストする必要があります。
これが、ヘルスケアアプリケーションのシステムをテストする順序です。
何ですか 次 ？
上記の情報は、ヘルスケアアプリケーションを「テストする方法」に入るのに十分な勢いを与えるはずです。 第二部 この記事の。
著者について： これは、Vairavan R Mによるゲスト投稿です。著者は、ヘルスケアアプリケーションのテストと、多国籍企業のチームを率いる経験が豊富です。
それまでの間、ご質問やコメントがある場合、またはヘルスケアドメインをよりよく理解するためにサポートが必要な場合は、お知らせください。シリーズの次の記事をお楽しみに。