KR20220066510A

KR20220066510A - 통합 실손의료보험 자동청구방법 및 시스템

Info

Publication number: KR20220066510A
Application number: KR1020200152620A
Authority: KR
Inventors: 홍병진
Original assignee: 주식회사 레몬헬스케어
Priority date: 2020-11-16
Filing date: 2020-11-16
Publication date: 2022-05-24
Also published as: KR102524829B1

Abstract

본 발명은 환자가 가입한 모든 보험사들에 동시에 보험금 청구가 가능한 통합 실손의료보험 자동청구방법에 관한 것이다. 사용자단말이 전용 애플리케이션을 실행하고, 개인 식별 정보를 입력하여 클라우드서버에 송신하면, 클라우드서버가 다수개의 병원서버에서 동시에 환자 번호를 조회하는 단계와, 다수개의 병원서버가 환자번호를 조회하고, 다수개의 병원서버 중 적어도 하나의 병원서버에서 상기 환자 번호의 등록여부가 확인되면 클라우드서버에 환자 번호의 등록확인을 전달하고, 클라우드서버가 사용자단말에 상기 환자 번호의 등록여부를 전달하는 단계와, 사용자단말이 환자번호로 로그인을 진행하여 클라우드서버에 진료데이터 확인을 요청하면, 클라우드서버가 진료 기간 및 신청일을 설정하여 다수개의 병원서버에 진료데이터를 요청하는 단계와, 다수개의 병원서버는 환자번호에 기초하여 진료데이터를 확인하고, 환자 진료데이터가 있는 병원서버가 클라우드서버에 환자 진료데이터를 전송하면, 클라우드서버가 병원별 진료데이터를 확인하여 다수개의 보험사 계약 확인 및 데이터 연동을 통하여 보험금 수령 가능금액을 확인하고 보험금청구서를 생성하는 단계를 포함한다.

Description

통합 실손의료보험 자동청구방법 및 시스템{Integrated claim method and system for loss insurance}

본 발명은 통합 실손보험청구 자동청구방법 및 시스템에 관한 것으로, 특히 동시에 여러 병원의 진료데이터를 병원연동 API엔진을 통해 가져와서 환자가 가입한 모든 보험사들에 동시에 보험금 청구가 가능한 통합 실손의료보험 자동청구방법 및 시스템에 관한 것이다.

실손의료보험은 보험가입자가 질병이나 상해로 입원 또는 통원치료 시 의료비로 실제 부담한 금액을 보장해주는 건강보험이다. 일반적으로 보험 가입자가 보험금을 청구하기 위해서는 보험 가입자가 병의원 및 약국에 방문하여 진료비영수증, 진단서, 처방전, 처방전약비용영수증 등 각종 증빙서류를 발급받은 뒤 보험사에 팩스로 전송하거나 우편으로 발송한다.

상기와 같이 실손의료보험금을 청구하기 위해 의료기관으로부터 증빙 서류를 발급받아, 보험사의 청구 양식을 작성하여 해당 보험사에 청구해야 하며, 신청 절차 상의 번거로움으로 인해, 다수의 보험가입자가 소액 의료비의 경우 보험약정에 따라 보험금을 지급받을 수 있음에도 불구하고 절차가 복잡하고 불편하여 보험금을 청구하지 않는 실정이다.

한편, 실손의료보험이 보편화되면서 2개 이상의 실손의료보험을 가입한 중복 가입자가 138만명에 이르는 실정이다. 환자가 진료 후 해당 진료에 대해 실손의료보험청구가 가능한지를 직접 확인해야하고, 각각의 서류를 준비해야하는 번거로움이 발생하고 있다.

선행기술로는 공개특허 제10-2018-0122506호(스크래핑 기반의 보험금 자동 청구 서비스 제공 방법 및 장치)가 있으나, 청구 누락되거나 미지급된 보험금 정보를 스크래핑을 통해 분석 추출하여 사용자에게 자동적으로 청구하게 하는 기술을 개시하고 있을 뿐이다.

본 발명이 해결하고자 하는 과제는 여러 병원의 진료데이터를 병원연동 API엔진을 통해 가져와서 환자가 가입한 모든 보험사들에 동시에 보험금 청구가 가능한 통합 실손의료보험 자동청구방법 및 시스템을 제공하는 데 있다.

본 발명의 실시예에 따른 통합 실손의료보험 자동청구방법은 사용자단말이 전용 애플리케이션을 실행하고, 개인 식별 정보를 입력하여 클라우드서버에 송신하면, 클라우드서버가 다수개의 병원서버에서 동시에 환자 번호를 조회하는 단계와, 다수개의 병원서버가 환자번호를 조회하고, 다수개의 병원서버 중 적어도 하나의 병원서버에서 상기 환자 번호의 등록여부가 확인되면 클라우드서버에 환자 번호의 등록확인을 전달하고, 클라우드서버가 사용자단말에 상기 환자 번호의 등록여부를 전달하는 단계와, 사용자단말이 환자번호로 로그인을 진행하여 클라우드서버에 진료데이터 확인을 요청하면, 클라우드서버가 진료 기간 및 신청일을 설정하여 다수개의 병원서버에 진료데이터를 요청하는 단계와, 다수개의 병원서버는 환자번호에 기초하여 진료데이터를 확인하고, 환자 진료데이터가 있는 병원서버가 클라우드서버에 환자 진료데이터를 전송하면, 클라우드서버가 병원별 진료데이터를 확인하여 다수개의 보험사 계약 확인 및 데이터 연동을 통하여 보험금 수령 가능금액을 확인하고 보험금청구서를 생성하는 단계를 포함한다.

본 발명에 의하면 환자가 가입된 모든 보험사에 별도의 서류 준비 없이 간편하게 실손의료보험을 신청할 수 있다. 또한, 여러 병원에서 진료를 보더라도 통합적으로 실손의료비 청구가 가능하다. 또한, 보험금 청구에 따른 심사, 중복 수령을 판단할 수 있어 예상 수령액을 환자에게 안내할 수 있다.

도 1과 도 2는 본 발명의 실시예에 따른 통합 실손의료보험 자동청구방법을 설명하는 흐름도이다.
도 3과 도 4는 본 발명의 실시예에 따른 통합 실손의료보험 자동청구시스템의 구성도이다.

본 명세서에 개시되어 있는 본 발명의 개념에 따른 실시 예들에 대해서 특정한 구조적 또는 기능적 설명은 단지 본 발명의 개념에 따른 실시 예들을 설명하기 위한 목적으로 예시된 것으로서, 본 발명의 개념에 따른 실시 예들은 다양한 형태들로 실시될 수 있으며 본 명세서에 설명된 실시 예들에 한정되지 않는다.

본 발명의 개념에 따른 실시 예들은 다양한 변경들을 가할 수 있고 여러 가지 형태들을 가질 수 있으므로 실시 예들을 도면에 예시하고 본 명세서에서 상세하게 설명하고자 한다. 그러나 이는 본 발명의 개념에 따른 실시 예들을 특정한 개시 형태들에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물, 또는 대체물을 포함한다.

본 명세서에서 사용한 용어는 단지 특정한 실시 예를 설명하기 위해 사용된 것으로서, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 명세서에서, "포함하다" 또는 "가지다" 등의 용어는 본 명세서에 기재된 특징, 숫자, 단계, 동작, 구성 요소, 부분품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성 요소, 부분품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.

이하, 본 명세서에 첨부된 도면들을 참조하여 본 발명의 실시 예들을 상세히 설명한다.

도 1과 도 2는 본 발명의 실시예에 따른 통합 실손의료보험 자동청구방법을 설명하는 흐름도이다. 도 1과 도 2를 참조하면, 본 발명의 통합 실손의료보험 자동청구방법은 먼저 사용자단말(300)이 전용 애플리케이션을 실행하여(S101), 개인 식별 정보를 입력하여 클라우드서버(100)에 송신하면(S103) , 클라우드서버(100)가 다수개의 병원서버(200)에서 동시에 환자 번호를 조회한다(S105). 이때, 상기 개인 식별 정보는 CI(개인식별 연계정보), 주민등록번호, 공인인증서, 바이오DATA(지문, 홍채, DNA정보) 중 적어도 하나일 수 있다.

다수개의 병원서버(200)가 환자번호를 조회하고(S107), 다수개의 병원서버(200) 중 적어도 하나의 병원서버에서 상기 환자 번호의 등록여부가 확인되면 클라우드서버(100)에 환자 번호의 등록확인을 전달하고(S109), 클라우드서버(100)는 사용자단말(300)에 상기 환자 번호의 등록여부를 전달한다(S111). 이때, 클라우드서버(100)는 동시에 모든 병원의 진료 데이터를 API엔진부를 통해 확인이 가능하다. 즉, 클라우드서버(100)는 데이터필드 및 칼럼명 확인, 쿼리실행문을 통해 진료데이터 확인이 가능하다.

사용자단말(300)이 환자번호로 로그인을 진행하고(S113), 클라우드서버(100)에 진료데이터 확인을 요청한다(S115). 클라우드서버(100)가 진료 기간 및 신청일을 설정하고(S117), 다수개의 병원서버(200)에 진료데이터를 요청한다(S119). 다수개의 병원서버(200)는 환자번호에 기초하여 진료데이터를 확인하고, 환자 진료데이터가 있는 병원서버(200)는 클라우드서버(100)에 환자 진료데이터를 전송한다(S123). 클라우드서버(100)는 병원별 진료데이터를 확인하고(S125), 다수개의 보험사 계약 확인 및 데이터 연동을 통하여 보험금 수령 가능금액을 확인하고 보험금청구서를 생성한다(S127). 이때, 클라우드서버(100)는 환자번호를 기준으로 모든 병원의 외래, 입원 데이터를 API엔진부를 통하여 생명보험사, 손해보험사에 제공할 진료영수증, 진료비세부내역서, 처방전, 입퇴원확인서, 진단서사본 중 적어도 하나를 추출할 수 있다. 또한, 클라우드서버(100)는 유효계약 결과를 확인하여 청구가 가능한 다수개의 보험청구서를 생성할 수 있다. 클라우드서버(100)는 생성된 보험금청구서를 사용자단말(300)에 전송한다(S129). 즉, 클라우드서버(100)는 사용자단말에 청구가능한 보험청구 금액 및 보험청구 건수를 제공할 수 있다.

사용자단말(300)은 클라우드서버(100)에 보험금청구서 접수를 요청하고, 클라우드서버(100)는 블록체인메소드, 전문통신 및 JSON 데이터, 팩스 및 전자문서형태 중 적어도 하나인지를 확인한다. 클라우드서버(100)는 블록체인 메소드인 경우(S135), 블록체인서버에 블록체인 메소드 확인을 요청하고(S137), 블록체인서버(400)는 데이터규격이 맞다고 판단되면 보험사서버(500)에 진료데이터확인을 요청한다(S139). 클라우드서버와 보험사서버간 미리 정해진 규약(PROTOCOL)으로 동시에 전송이 가능하다.

클라우드서버(100)는 전문통신 및 JSON데이터인 경우(S141), 보험사서버에 진료데이터 확인을 요청한다(S143).

클라우드서버(100)는 팩스 및 전자문서 데이터인 경우에(S145), 보험사서버에 팩스 및 전자문서 데이터를 전송한다(S147). 이때, 팩스 및 전자문서 데이터인 경우, 보험사서버가 접수번호를 생성하여, 클라우드서버에 보험청구서를 전송 요청하고, 클라우드서버가 수수료 결제를 수행하는 단계를 더 포함한다. 보험사서버(500)가 접수번호를 생성하고(S149), 클라우드서버(100)에 보험청구서를 전송 요청한다(S151). 클라우드서버(100)는 사용자단말(300)에 보험금청구서 확인을 요청하고(S153), 사용자단말(300)로부터 확인결과를 전송받으면(S155), 보험사서버(500)에 보험청구서를 전송한다(S157). 보험사서버(500)는 보험금 지급 여부를 심사하고(S159), 보험금 지급되면 지급 결과를 클라우드서버(100)에 알림을 전달한다(S161). 클라우드서버(100)는 보험금 지급 결과를 분석하고(S163), 분석결과에 기초하여 보험금 차등지급에 대해 사용자단말(300)에 알림을 전송한다(S165).

도 3과 도 4는 본 발명의 실시예에 따른 실손의료보험 자동청구시스템의 구성도이다.

도 3과 도 4를 참조하면, 실손의료보험 자동청구시스템은 클라우드서버(100), 다수개의 병원서버(200), 사용자단말(300), 블록체인서버(400), 다수개의 보험사서버(500)로 구성된다.

본 발명에서는 설명의 편의를 위해 다수개의 병원서버(200)는 제1병원서버(210), 제2병원서버(220), 제n병원서버(230)로 표현되며, 다수개의 보험사서버(500)는 제1보험사서버(510), 제2보험사서버(520), 제n보험사서버(530)으로 표현될 수 있다.

제1병원서버(210)는 EMR DB(211), 컨소시엄 보험사시스템(213), API엔진부(215)를 포함한다. EMR DE(211)는 환자정보, 진단 및 처방정보, 병원발급서류정보, 팩스문서 가공관련정보를 저장할 수 있다. 컨소시엄 보험사인터페이스(213)는 제1실손청구시스템, 제2실손청구시스템 내지 제n실손청구시스템을 포함할 수 있다. EMR DB(211)와 컨소시엄 보험사인터페이스(213)의 구성은 예시적으로 도시한 것으로 이에 대해 한정하는 것은 아니다.

API엔진부(215)는 EMR데이터추출부, API수신부, API메타정보로딩부, API서비스부로 구성된다. API엔진부(215)는 EMR DB(211)로부터 데이터를 추출할 수 있다. API엔진부(215)는 클라우드서버로부터 수신된 병원서버별 API(Application Programming Interface)를 수신하여 로딩하고, 클라우드서버로부터 API메타정보를 로딩하여 API서비스를 수행할 수 있다. API엔진부(215)는 병원서버내에 설치되어 모바일서비스와 병원서버를 연결하는 미들웨어로서, 다양한 환경의 병원 레거시와 접속하여 API를 지원하는 개발도구이다. 즉, 병원서버내에 설치되여 환자용 앱 서비스 뿐 아니라 병원내 다양한 시스템과 연동을 위한 Restful API 개발 및 게이트웨이 서버로 활용할 수 있다. API엔진부(215)는 EMR 데이터추출부, API수신부, API메타정보 로딩부, API서비스부로 구성된다. 상기 EMR 데이터추출부은 EMR DB(211)로부터 데이터를 추출할 수 있다. 상기 API수신부는 클라우드서버로부터 생성된 병원서버별 API를 수신할 수 있다. 상기 API메타데이터 로딩부는 클라우드서버로부터 API메타데이터를 로딩할 수 있다. 상기 API서비스부는 API메타데이터에 기초하여 API서비스를 구동할 수 있다.

클라우드서버(100)는 API생성관리부(110), 설정부(120), 계산부(130), 보험금청구서 생성부(140), 분석부(150), 결제부(160)로 구성된다. API생성관리부(110)는 병원서버들 및 보험사서버들의 통합 인터페이스를 제공하기 위한 사전정의된 API를 생성할 수 있다. 병원서버들 및 보험사서버들의 데이터베이스 정보를 표준화하기 위한 API일 수 있다. API생성관리부(110)는 데이터소스를 정의하고, SQL 및 프로시져를 등록할 수 있다. 또한, API생성관리부(110)는 미들웨어 접속정보 및 호출 경로를 등록하며 웹서비스 접속정보와 URL을 등록할 수 있다.

API생성관리부(110)는 사용자단말로부터 서비스호출을 수신하면 다수개의 병원서버들 및 보험사서버들에 환자번호조회, 진료예약, 결제 및 실손보험청구 서비스를 제공하도록 해당 서비스와 매칭되는 API를 호출할 수 있다. API생성관리부(110)는 API제약조건 관리 기능을 통해 입력 및 출력 오류 체크를 수행할 수 있다. API생성관리부(110)는 각 병원서버 및 보험사서버의 API 서비스의 상태, 버전정보, 메모리사용량, 디스크사용량, 서버의 CPU 사용량 등을 모니터링할 수 있다. API생성관리부(110)는 민감정보에 대해 암호화하여 데이터베이스에 저장할 수 있다. API생성관리부(110)는 API의 도메인 관리를 할 수 있다. API생성관리부(110)는 메타데이터에서 관리하는 API스펙이 변경되는 경우, 자동 배포를 위한 메타데이터가 추가될 수 있다. 즉, 표준화된 매핑정의서가 작성되고, 처리방식에 따라 표준화 작성된 프로토타입 탬플릿에 매핑 샘플 예시가 이용되어 표준화된 소스 적재프로그램이 생성되도록 프로그램화된 프로세서 및 추출된 데이터를 선택적으로 등록할 수 있다.

설정부(120)는 사용자단말(300)로부터 진료데이터확인을 요청받으면, 진료 기간 및 신청일을 설정할 수 있다.

계산부(130)는 병원서버로부터 환자 진료데이터를 수신하면 병원별 진료데이터를 확인하고, 보험금 수령가능금액을 계산할 수 있다. 계산부(130)는 모든 가능한 세부내역 및 건수를 확인하여, 보험금 수령가능금액을 최종 산정하여, 환자에게 청구가능한 금액부터 보여줄 수 있도록 계산할 수 있다.

보험금청구서생성부(140)는 보험사에서 확인된 보험금 수령가능금액 계산결과에 기초하여 다수의 보험사서버별 보험금청구서를 각각 생성할 수 있다.

분석부(150)는 보험사별 중복수령 여부를 판단할 수 있다. 즉, 분석부(150)는 실손의료 보험을 중복 가입해도, 동시에 청구 요청한 복수의 실손의료보험 중 첫번째 처리된 실손보험 심사 후 지급이 되면 두번째 동시 처리된 실손보험의 경우 보험금에 영향도를 감안하여, 이를 미리 예측하여 예상 보험금 수령액을 안내하도록 분석할 수 있다. 분석부(150)는 해당 분석 결과를 환자에게 알림메시지를 전달할 수 있다.

보험사서버로부터 보험금 지급 결과를 수신하면 보험금 지급결과를 분석하고, 분석결과에 기초하여 보험금 차등지급여부를 사용자단말(300)에 알릴 수 있다. 결제부(160)는 보험사서버(500)로부터 보험청구서 전송요청을 받으면 수수료 결제를 진행할 수 있다.

블록체인서버(400)는 클라우드서버(100)로부터 블록체인 메소드 확인을 요청받으면 데이터규격이 맞는지 여부를 판단할 수 있다. 데이터규격이 맞으면 보험사서버(500)에 진료데이터확인을 요청하고, 데이터규격이 맞지 않으면 전문통신, JSON데이터 확인을 클라우드서버에 요청한다.

발명은 도면에 도시된 실시 예를 참고로 설명되었으나 이는 예시적인 것에 불과하며, 본 기술 분야의 통상의 지식을 가진 자라면 이로부터 다양한 변형 및 균등한 타 실시 예가 가능하다는 점을 이해할 것이다. 따라서, 본 발명의 진정한 기술적 보호 범위는 첨부된 등록청구범위의 기술적 사상에 의해 정해져야 할 것이다.

10; 통합 실손의료보험 자동청구시스템 100; 클라우드서버
200; 병원서버 300; 사용자단말
400; 블록체인서버 500; 보험사서버

Claims

환자가 가입한 모든 보험사들에 동시에 보험금 청구가 가능한 통합 통합 실손의료보험 자동청구방법에 있어서,
사용자단말이 전용 애플리케이션을 실행하고, 개인 식별 정보를 입력하여 클라우드서버에 송신하면, 클라우드서버가 다수개의 병원서버에서 동시에 환자 번호를 조회하는 단계;
다수개의 병원서버가 환자번호를 조회하고, 다수개의 병원서버 중 적어도 하나의 병원서버에서 상기 환자 번호의 등록여부가 확인되면 클라우드서버에 환자 번호의 등록확인을 전달하고, 클라우드서버가 사용자단말에 상기 환자 번호의 등록여부를 전달하는 단계;
사용자단말이 환자번호로 로그인을 진행하여 클라우드서버에 진료데이터 확인을 요청하면, 클라우드서버가 진료 기간 및 신청일을 설정하여 다수개의 병원서버에 진료데이터를 요청하는 단계;
다수개의 병원서버는 환자번호에 기초하여 진료데이터를 확인하고, 환자 진료데이터가 있는 병원서버가 클라우드서버에 환자 진료데이터를 전송하면, 클라우드서버가 병원별 진료데이터를 확인하여 다수개의 보험사 계약 확인 및 데이터 연동을 통하여 보험금 수령 가능금액을 확인하고 보험금청구서를 생성하는 단계를 포함하는 통합 실손의료보험 자동청구방법.
제1항에 있어서,
사용자단말이 클라우드서버에 보험금청구서 접수를 요청하고, 클라우드서버는 블록체인메소드, 전문통신 및 JSON 데이터, 팩스 및 전자문서형태 중 적어도 하나인지를 확인하는 단계를 더 포함하고,
상기 클라우드서버는 블록체인 메소드인 경우, 블록체인서버에 블록체인 메소드 확인을 요청하고, 블록체인서버는 데이터규격이 맞다고 판단되면 보험사서버에 진료데이터확인을 요청하는 통합 실손의료보험 자동청구방법.
제2항에 있어서,
상기 클라우드서버는 전문통신 및 JSON데이터인 경우, 보험사서버에 진료데이터 확인을 요청하고,
상기 클라우드서버는 팩스 및 전자문서 데이터인 경우 보험사서버에 팩스 및 전자문서 데이터를 전송하는 통합 실손의료보험 자동청구방법.
제3항에 있어서,
팩스 및 전자문서 데이터인 경우, 보험사서버가 접수번호를 생성하여, 클라우드서버에 보험청구서를 전송 요청하고, 클라우드서버가 수수료 결제를 수행하는 단계를 더 포함하는 통합 실손의료보험 자동청구방법.
제1항에 있어서,
클라우드서버는 팩스 및 병원발급문서형태로 보험사서버에 전송하면, 보험사서버가 접수번호를 생성하고 보험청구서 전송을 클라우드서버에 요청하는 단계를 더 포함하는 통합 실손의료보험 자동청구방법.