how test health care application part 1
건강 관리 도메인 이해 및 건강 관리 애플리케이션 테스트 :
오늘의 기사는 의료 분야, 즉 도메인 / 비즈니스 정보, 구성 요소, 테스트 대상 및 테스트 방법에 관한 것입니다.
2 부로 구성된이 기사 시리즈는 의료 애플리케이션 워크 플로를 테스트, 학습 및 이해하기 위해 다른 도메인을 탐색하고 입력하려는 모든 사용자에게 유용합니다. 테스트 과정 .
요컨대,이 기사는 의료 지식 탐구에 대한 첫 번째 단계이자 가이드가 될 것입니다. 에 2 부 우리는 의료 분야의 다양한 애플리케이션에 대한 테스트 시나리오를 제공 할 것입니다.
테스트에서 탁월하려면 도메인 지식이 핵심 . 따라서 이제 고객의 비즈니스 흐름에 대해 알아 보겠습니다.
학습 내용 :
의료 분야-소개
건강 보험 또는 건강 보험은 일반 보험과 유사합니다. 아시다시피 모든 보험에서 보험사 (보험 회사)가 플랜을 제공하고 고객 (가입자 또는 보험 계약자)이 원하는 플랜의 보험을 구매합니다. 보험사는 보험 계약자로부터 보험료 금액을 받고 보험 계약자는 제출 한 유효한 청구에 대해 보험사로부터 보상을받습니다.
화이트 박스와 블랙 박스 테스트의 차이점
의료 보험에서도 마찬가지이지만 보험사 및 보험 계약자 외에도 공급자, TPA (제 3 자 관리자), 중개인 등과 같은 다른 주요 기여자가 있습니다.
이제 각 주요 기여자를 자세히 살펴 보겠습니다.
# 1) 보험사 : 계획을 작성하고, 정책을 판매하고, 제출 된 유효한 청구에 대해 보험 계약자 또는 제공자에게 상환하는 주체.
# 2) 보험 계약자 : 보험사 또는 중개인으로부터 보험을 구매하는 개인 또는 법인은 보험자에게 보험료를 지불하고 때로는 청구서를 제출합니다.
Eclipse에서 새 프로젝트를 시작하는 방법
# 3) 제공자 : 보험 계약자와 그 피부양자에게 의료 서비스를 제공하는 개인 또는 단체는 보험금 청구를 제출함으로써 보험 계약자 또는 보험자로부터 서비스에 대한 대금을받습니다.
# 4) TPA : 보험 계약자 또는 공급자의 청구를 관리하고 해당 기여자로부터 관리 비용을받는 사람 또는 개체입니다.
# 5) 브로커 : 짐작 하셨듯이, 그는 보험사를 대신하여 고객에게 보험 증권을 판매하고 보험사로부터 수수료를받는 대리인입니다.
예를 들어 아래 예를 통해 기여자의 기본 기능을 이해할 수 있습니다.
Enosh 씨는 Ponnar 씨로부터 일반 의사 상담 및 시력 문제를 다루는 건강 관리 정책을 구입하고 그에 대한 보험료를 의료 회사에 지불했습니다.
Enosh 씨가 아파서 의사 인 Sabari에게 회복을 요청한 후 Sabari는 Enosh에게 처방전을 제공하고 HealthCorp Company에 상담 청구서를 제출하고 상환을받습니다. Ponnar 씨는 HealthCorp Company로부터 Enosh 씨의 보험료 지불 수수료를받습니다.
위의 예에서 '일반 의사 상담'및 '시력 문제'는 건강 플랜의 혜택이며, Enosh 씨는 보험 계약자, Ponnar 씨는 중개인, HealthCorp Company는 보험사, Mr. Sabari는 제공자입니다.
정책과 계획의 차이점을 명확하게 이해하려면 계획을 클래스로, 정책을 객체 (클래스의 인스턴스)로 생각하십시오. 정책은 수혜자 유형에 따라 개별 정책 및 그룹 정책으로 분류 할 수 있습니다.
개별 정책 : 개인이 보험 계약자가됩니다. 개인과 부양 가족 모두 건강 보험의 혜택을 누릴 수 있습니다. 여기에서 개인이 보험료를 지불합니다.
그룹 정책 : 법인 (일반적으로 고용주)은 보험 계약자가되고, 법인의 구성원 (직원)과 그 부양 가족은 건강 보험 혜택을 누릴 수 있습니다. 여기서 기업은 보험료를 지불합니다.
예를 들어 그룹 정책에 대한 명확한 아이디어를 갖는 예는 다음과 같습니다.
MotoCorp Company는 직원과 그 가족을 위해 HealthCorp Company로부터 정책을 구매합니다. 그들의 주장은 EasyClaim Company에서 관리합니다. 여기서 MotoCorp Company는 보험 계약자이고 HealthCorp Company는 보험사이며 EasyCliam Company는 TPA입니다.
의료 애플리케이션을 테스트하는 방법?
애플리케이션을 테스트하기 전에 의료 산업 워크 플로를 알고 있어야합니다. 이전 항목에서는 관리 형 의료에 대한 소개 만 제공합니다. 자세한 내용은 여기에서 사용 가능 .
보험사는 다음을 관리하기 위해 다양한 애플리케이션이 필요합니다.
- 제공자 데이터
- 회원 데이터
- 프리미엄 청구 / 결제
- 브로커 데이터
- 청구 입력 / 검증
- 브로커 수수료 계산 / 결제
일반적으로 의료 애플리케이션에는 다음과 같은 시스템 목록이 있습니다.
- 회원 제도 : 보험 계약자 데이터, 각종 보험 혜택 목록을 유지하고 보험 계약자에 대한 보험료 청구서 생성
- 제공자 시스템 : 공급자 데이터를 유지하려면
- 브로커 시스템 : 브로커 데이터 유지 및 수수료 계산
- 클레임 시스템 : 클레임 입력 및 검증
- 금융 시스템 : 제공자 / 회원 / 브로커에게 필요한 결제를하기 위해
- 회원 포털 : 보험 계약자 정보 조회, 보험료 납부 및 보험 계약자 정보 변경 요청
- 공급자 포털 : 제공자 정보 표시 및 제공자 변경 정보 요청
- 브로커 포털 : 브로커 정보 표시 및 브로커 변경 정보 요청
이것은 완전한 목록이 아닐 수 있습니다. 그러나 이것은 내가 아는 한 목록입니다. 또한 모든 응용 프로그램이 사용되지 않을 수도 있습니다. 때로는 이러한 응용 프로그램 중 일부를 병합하여 다른 조합 응용 프로그램을 만드는 경우도 있습니다. 다른 경우에는 독립 실행 형 시스템입니다.
예를 들어 , 제공자 시스템은 일부 의료 애플리케이션에서 회원 시스템의 일부가 될 수 있습니다. 의료 애플리케이션이란 보험사가 고객과 파트너를 용이하게하기 위해 유지 관리하는 일련의 시스템을 의미합니다.
자바 인터뷰 질문과 더 신선한 답변
건강 관리 애플리케이션 테스트 워크 플로
건강 관리 시스템의 고유 한 특징은 이러한 응용 프로그램을 우리가 원하는 순서대로 테스트 할 수 없다는 것입니다. 따라야 할 특정 워크 플로가 있습니다.
- 가입자 / 보험 계약자가 건강 플랜에 등록하려면 공급자 (주치의) 또는 공급자 네트워크에 배정되어야하므로 가입자 시스템이 배정 된 공급자를 확인할 수있는 방법이 있어야합니다. 구성원 시스템이 제공자 시스템에 연결되거나 데이터 피드가 제공자 시스템에서 구성원 시스템으로 주기적으로 전송되어야합니다. 따라서 공급자 시스템을 테스트하고 구성원 시스템을 테스트하기 전에 사용할 준비를해야합니다.
- 클레임은 다른 세부 정보와 함께 공급자 ID 및 회원 ID로 구성되어야합니다. 클레임 시스템은 클레임 시스템을 테스트하기 전에 구성원 및 공급자 시스템을 모두 테스트하고 사용할 준비가되어 있어야합니다.
- 금융 시스템은 회원, 제공자, 청구 및 중개인 시스템의 데이터를 가지고 있어야 각 개인 또는 법인에 수표를 쓰거나 EFT 지불을 할 수 있습니다.
- 공급자 및 브로커 시스템은 독립형입니다.
- 포털은 다른 애플리케이션의 데이터가 필요하므로 마지막으로 테스트해야합니다.
이제 이것이 의료 애플리케이션의 시스템을 테스트해야하는 순서입니다.
무엇입니까 다음 ?
위에서 언급 한 정보는 헬스 케어 애플리케이션을 '테스트하는 방법'에 들어갈 수있는 충분한 추진력을 제공해야합니다. 2 부 이 기사의.
저자 정보 : 이것은 Vairavan R M의 게스트 포스트입니다. Author는 건강 관리 애플리케이션을 테스트하고 다국적 기업에서 팀을 이끌고있는 좋은 경험을 가지고 있습니다.
그동안 질문이나 의견이 있거나 Health Care 도메인을 더 잘 이해하는 데 도움이 필요하면 알려주십시오. 시리즈의 다음 기사를 기대해주세요.