KR101708774B1 - 제3자 중심의 공개인증 기반 의료기록 전송 시스템 및 방법 - Google Patents

제3자 중심의 공개인증 기반 의료기록 전송 시스템 및 방법 Download PDF

Info

Publication number
KR101708774B1
KR101708774B1 KR1020160065750A KR20160065750A KR101708774B1 KR 101708774 B1 KR101708774 B1 KR 101708774B1 KR 1020160065750 A KR1020160065750 A KR 1020160065750A KR 20160065750 A KR20160065750 A KR 20160065750A KR 101708774 B1 KR101708774 B1 KR 101708774B1
Authority
KR
South Korea
Prior art keywords
authentication
server
patient
user
medical record
Prior art date
Application number
KR1020160065750A
Other languages
English (en)
Inventor
송승재
주용범
윤홍일
윤상철
신태환
Original Assignee
주식회사 라이프시맨틱스
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 주식회사 라이프시맨틱스 filed Critical 주식회사 라이프시맨틱스
Priority to KR1020160065750A priority Critical patent/KR101708774B1/ko
Application granted granted Critical
Publication of KR101708774B1 publication Critical patent/KR101708774B1/ko

Links

Images

Classifications

    • G06F19/32—
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • G06Q50/24—
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Physics & Mathematics (AREA)
  • Bioethics (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Public Health (AREA)
  • Primary Health Care (AREA)
  • Epidemiology (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

모바일 앱 등 제3자 서비스 시스템에서 의료기관에 기록된 사용자의 의료기록을 전송시켜 가져오기 위하여, 의료기관 시스템에서 공개 표준으로 제공하는 사용자 인증, 본인 인증, 및 정보제공 동의 인터페이스를 통해, 의료기관에서 직접 인증을 수행하게 하는, 제3자 중심의 공개인증 기반 의료기록 전송 시스템 및 방법에 관한 것으로서, 사용자 단말에 설치되는 제3자 서비스 앱; 상기 제3자 서비스 앱과 네트워크로 연결된 제3자 서비스 서버; 환자를 회원으로 등록하여 사용자 계정을 생성하고, 상기 사용자 계정을 인증하기 위한 사용자 인증정보를 등록하는 환자포털 서버; 사용자 인증, 본인인증, 및, 정보제공 동의를 공개된 프로토콜에 의해 수행하고, 사용자 인증, 본인인증, 및 정보제공 동의가 완료되면 액세스토큰을 발급하는 공개인증 서버; 및, 상기 환자의 의료기록을 저장하고, 상기 액세스토큰을 통해 의료기록을 요청하는 경우, 상기 환자의 의료기록을 전송하는 리소스 서버를 포함하는 구성을 마련한다.
상기와 같은 시스템 및 방법에 의하면, 의료기관 시스템에서 사용자 인증 및 본인 인증, 정보제공 동의를 직접 수행하게 함으로써, 의료기관은 자신이 보유한 환자의 의료기록을 안전하게 외부로 반출할 수 있다.

Description

제3자 중심의 공개인증 기반 의료기록 전송 시스템 및 방법 { A third party central system of tranferring medical records using open authorization and the method thereof }
본 발명은 모바일 앱 등 제3자 서비스 시스템에서 의료기관에 기록된 사용자의 의료기록을 전송시켜 가져오기 위하여, 의료기관 시스템에서 공개 표준으로 제공하는 사용자 인증, 본인 인증, 및 정보제공 동의 인터페이스를 통해, 의료기관에서 직접 인증을 수행하게 하는, 제3자 중심의 공개인증 기반 의료기록 전송 시스템 및 방법에 관한 것이다.
일반적으로, 의료기관에 도입된 의료정보 시스템은 전자의무기록(EMR, electronic medical record), 처방전달시스템(OCS, order communication system), 의료영상저장전송시스템(PACS, picture archiving communication system) 등이 있다. 이들 의료정보 시스템은 병원 등 의료기관에 전산시스템에 도입되면서, 의료기관에서 작성되고 전달되던 의료기록들이 디지털화된 것이다. 즉, 예전에 의사 등 의료진에 의해 수기로 작성 보관되던 의무기록들이 전자문서로 디지털화 되고, 의료정보 시스템에서 기록되어 영구 보관되고 있다.
전자의무기록(EMR)은 과거에 의사 등 의료진이 환자의 진료내용을 수기로 기록한 종이문서의 차트를 디지털화한 것이고, 처방전달시스템(OCS)는 과거에 의사가 수기로 작성한 종이문서의 처방전을 디지털화한 것이다. 또한, 의료영상저장전송시스템(PACS)은 과거에 CT나 MRI 등 의료영상 장비에 의해 촬영된 영상 필름을 디지털화한 것이다. 따라서 이들 환자의 진료내용, 의사의 처방전, 의료영상 자료들은 모두 디지털화되어, 의료기관 내 의료정보시스템에 저장되어 영구 보존되고, 네트워크를 통해 필요한 곳으로 전달된다.
따라서 의사나 환자는 PC 나 스마트폰 등 인터넷과 연결된 컴퓨팅 단말에서 필요할 때마다 해당 의료기관의 서버에 접속하여 환자의 의료기록을 쉽게 열람할 수 있게 되었다. 예를 들어, 건강검진관리 서버가 EMR 서버와 연동하여, 환자(사용자), 상담원, 관리자, 의료진, 외부기관(국민건강보험공단 등) 등의 단말을 인증하면 해당 단말로 EMR 건강기록을 열람할 수 있게 하는 기술이 제시되고 있다[특허문헌 1,2,3].
그러나 상기와 같은 의료정보시스템은 대부분 하나의 병원 등 단일한 의료기관 내에서 폐쇄적으로 구축되었기 때문에, 타 의료기관과 상호 호환성이 떨어진다. 그래서 의료기관들 사이에서 의료기록들을 원활하게 전송하기 위한 표준화 작업들이 활발하게 진행되고 있다.
또한, 타 의료기관 간의 의료데이터를 전송하거나 서로 교환하기 위하여, 중간에 중계서버, 통합서버, 공유서버 등을 두어 양 의료기관 간을 중계하는 기술들도 제시되고 있다[특허문헌 4,5]. 상기 선행기술들은 제1 의료기관에서 제2 의료기관 간에 의료데이터를 암호화 하여 단순히 전송 중계하거나, 통합서버와 공유서버 등에서 각 의료기관들로부터 의료 데이터를 수신하여 보관하다가 요청이 있으면 보관된 의료 데이터를 요청 기관에 전송하는 기술들이 제시되고 있다.
그러나 상기 선행기술들은 의료 데이터를 제3 기관에서 보관하거나 관리한다는 문제점이 있다. 즉, 병원 등 의료기관에서 생성된 의료기록은 매우 중요한 개인정보에 해당되기 때문에, 환자가 원하지 않는 방식으로 제3자에게 공개될 경우 프라이버시를 심각하게 침해할 우려가 크다. 따라서 환자의 명시적인 동의가 없이는 제3자의 열람을 금지하거나 해당 병원 이외의 장소로는 반출을 제한하는 등 법적으로 엄격하게 보호되고 있다. 즉, 엄격한 신분확인이나 위임장, 정보제공 동의서 제출 등 복잡한 절차를 거치는 경우에만 환자의 의료기록을 타 기관이나 제3자에게 반출할 수 있다.
따라서 인터넷 등 온라인을 통해 환자가 다른 병원이나 건강의료 관련 어플리케이션 등 제3자 서비스 시스템에 자신의 의료기록을 제공하는 것을 실제로 구현한다는 것은 용이하지 않다. 특히, 스마트폰 등 이동 단말(모바일 앱 등)에서 자신의 의료기록을 열람하는 것조차 쉽지 않다.
국내의 경우, 최근 규제가 완화되고 있지만, 학술적인 목적의 연구 외 상업적 이용은 여전히 법적 제한이 많다. 즉, 민간기업이 의료 서비스 품질 개선, 환자의 요구(needs) 분석, 신제품 개발, 건강관리 서비스 제공 등 상업적 목적으로, 의료기관에 누적되어 있는 방대한 의료 데이터를 제3자의 서버에서 체계적으로 수집/분석하는 것은 여전히 법적으로 제한이 많다.
반면, 미국이나 영국을 비롯한 선진국들은 최근 급증하는 의료비 절감과 디지털 헬스케어 산업의 육성을 위해 의료정보에 대한 각종 법적인 규제를 크게 완화하고 있다. 예를 들어, 미국의 경우 정부 주도로 블루버튼 플러스(Blue Button +) 표준을 채택하여, 인터넷을 통한 환자 자신의 의료정보 열람 및 다른 의료기관이나 서비스 사업자를 비롯한 제3자에 대한 전송(Transition)을 법적으로 보장하고 있다. 즉, 환자가 병원의 병원 홈페이지(Patient Portal)에 접속하여 블루버튼 플러스(Blue Button +) 버튼을 누르면, HL7(Health Level 7)의 C-CDA(Consolidated Clinical Document Architecture) 표준으로 포맷팅된 의료정보를 열람(View)하거나, 다운로드(Download)하거나, 제3자에게 SMTP 방식으로 전송(Transfer)할 수 있다.
그러나 환자 본인의 인증이나 정보제공동의 등 국내 법적 제한을 만족하기 위한 보다 강화된 인증 체계가 요구된다.
한국공개특허공보 제10-2009-0001965호(2009.01.09.공개) 한국공개특허공보 제10-2014-0060918호(2014.05.21.공개) 한국공개특허공보 제10-2013-0001500호(2013.01.04.공개) 한국 등록특허공보 제10-0696708호(2007.03.20.공고) 한국공개특허공보 제10-2012-0093560호(2012.08.23.공개)
본 발명의 목적은 상술한 바와 같은 문제점을 해결하기 위한 것으로, 제3자 서비스 시스템에서 의료기관에 기록된 사용자의 의료기록을 전송시켜 가져오기 위하여, 의료기관 시스템에서 공개 표준으로 제공하는 사용자 인증, 본인 인증, 및 정보제공 동의 인터페이스를 통해, 의료기관에서 직접 인증을 수행하게 하는, 제3자 중심의 공개인증 기반 의료기록 전송 시스템 및 방법을 제공하는 것이다.
또한, 본 발명의 목적은 의료기관의 인증이 완료되면 발급되는 액세스 토큰을 이용하여, 제3자 서비스 시스템이 의료기관 시스템에 직접 접속하여 필요한 의료기록 데이터를 가져오는, 제3자 중심의 공개인증 기반 의료기록 전송 시스템 및 방법을 제공하는 것이다.
상기 목적을 달성하기 위해 본 발명은 제3자 중심의 공개인증 기반 의료기록 전송 시스템에 관한 것으로서, 사용자 단말에 설치되는 제3자 서비스 앱; 상기 제3자 서비스 앱과 네트워크로 연결된 제3자 서비스 서버; 환자를 회원으로 등록하여 사용자 계정을 생성하고, 상기 사용자 계정을 인증하기 위한 사용자 인증정보를 등록하는 환자포털 서버; 사용자 인증, 본인인증, 및, 정보제공 동의를 공개된 프로토콜에 의해 수행하고, 사용자 인증, 본인인증, 및 정보제공 동의가 완료되면 액세스토큰을 발급하는 공개인증 서버; 및, 상기 액세스토큰을 통해 의료기록을 요청하는 경우, 상기 환자의 의료기록을 전송하는 리소스 서버를 포함하고, 상기 제3자 서비스 앱은 상기 공개인증 서버의 공개된 프로토콜을 통해 상기 사용자 인증, 본인인증, 및, 정보제공 동의를 요청하고, 사용자 인증, 본인인증, 및, 정보제공 동의에 필요한 환자의 입력을 받기 위하여 사용자 인터페이스 화면을 제공하고, 상기 공개인증 서버로부터 액세스토큰을 수신받아 상기 제3자 서비스 서버에 전송하면, 상기 제3자 서비스 서버는 상기 액세스토큰을 이용하여 상기 리소스 서버에 접속하여 환자의 의료기록을 전송 받는 것을 특징으로 한다.
또한, 본 발명은 제3자 중심의 공개인증 기반 의료기록 전송 시스템에 관한 것으로서, 사용자 단말에 설치되는 제3자 서비스 앱; 상기 제3자 서비스 앱과 네트워크로 연결된 제3자 서비스 서버; 환자를 회원으로 등록하여 사용자 계정을 생성하고, 상기 사용자 계정을 인증하기 위한 사용자 인증정보를 등록하는 환자포털 서버; 사용자 인증을 공개된 프로토콜에 의해 수행하고, 사용자 인증이 완료되면 액세스토큰을 발급하고, 상기 발급된 액세스토큰으로 본인인증 및 정보제공 동의를 요청받으면, 본인인증 및 정보제공 동의를 수행하는 공개인증 서버; 및, 상기 액세스토큰을 통해 의료기록을 요청하는 경우, 상기 액세스토큰을 통해 본인인증 및 정보제공 동의가 수행된 경우에만 상기 환자의 의료기록을 전송하는 리소스 서버를 포함하고, 상기 제3자 서비스 앱은 상기 공개인증 서버의 공개된 프로토콜을 통해 상기 사용자 인증, 본인인증, 및, 정보제공 동의를 요청하고, 사용자 인증, 본인인증, 및, 정보제공 동의에 필요한 환자의 입력을 받기 위하여 사용자 인터페이스 화면을 제공하고, 상기 공개인증 서버로부터 액세스토큰을 수신받아 상기 제3자 서비스 서버에 전송하면, 상기 제3자 서비스 서버는 상기 액세스토큰을 이용하여 상기 리소스 서버에 접속하여 환자의 의료기록을 전송 받는 것을 특징으로 한다.
또, 본 발명은 제3자 중심의 공개인증 기반 의료기록 전송 시스템에 있어서, 상기 의료기록 전송 시스템은 본인인증을 수행하는 본인인증 서버를 더 포함하고, 상기 공개인증 서버는 상기 본인인증 서버에 본인인증을 요청하고, 상기 본인인증 서버에서 본인인증을 수행시 환자로부터 입력을 상기 제3자 서비스 앱의 사용자 인터페이스를 통해 입력받도록 하고, 상기 본인인증의 결과를 상기 본인인증 서버로부터 직접 전송받는 것을 특징으로 한다.
또, 본 발명은 제3자 중심의 공개인증 기반 의료기록 전송 시스템에 있어서, 환자의 의료기록에 대한 정보제공 동의는 전송할 의료기록의 범위와, 해당 범위의 의료기록 전송을 허용하는 동의를 포함하는 것을 특징으로 한다.
또, 본 발명은 제3자 중심의 공개인증 기반 의료기록 전송 시스템에 있어서, 상기 액세스토큰은 만료기간이 설정되고, 상기 액세스토큰의 만료기간이 경과하면, 상기 리소스 서버는 상기 액세스토큰을 통한 의료기록 요청을 허용하지 않는 것을 특징으로 한다.
또, 본 발명은 제3자 중심의 공개인증 기반 의료기록 전송 시스템에 있어서, 상기 리소스 서버는 상기 제3자 서비스 서버로 의료기록을 전송할 때 웹 상의 RESTful(REpresentational State Transfer) API(Application Program Interface)를 통해 전송하는 것을 특징으로 한다.
또, 본 발명은 제3자 중심의 공개인증 기반 의료기록 전송 시스템에 있어서, 상기 공개인증 서버는 상기 사용자 계정의 사용자 아이디와, 상기 병록 아이디를 서로 매핑하여 저장하되, 상기 병록 아이디는 환자의 의료기록에 대하여 환자의 식별번호로 이용되는 아이디이고, 상기 리소스 서버는 환자의 병록 아이디 별로 정보제공 허용 범위를 저장하고, 상기 리소스 서버는 액세스토큰으로 환자의 의료기록 전송 요청을 받으면, 상기 액세스토큰의 유효성 체크를 상기 공개인증 서버를 통해 처리하고, 상기 공개인증 서버로부터 상기 액세스토큰에 대응되는 병록 아이디를 수신하여, 수시된 병록 아이디의 정보제공 허용 범위 내에서 상기 병록 아이디의 의료기록을 전송하는 것을 특징으로 한다.
또한, 본 발명은 사용자 단말에 설치되는 제3자 서비스 앱, 상기 제3자 서비스 앱과 네트워크로 연결된 제3자 서비스 서버, 의료기관에서 운영하는 공개인증 서버, 의료기록을 저장하는 리소스 서버로 구성되는 의료기록 전송 시스템에 의해 수행되는, 제3자 중심의 공개인증 기반 의료기록 전송 방법에 관한 것으로서, (a) 상기 제3자 서비스 앱에서 상기 공개인증 서버의 공개된 프로토콜을 통해, 의료기록을 전송받기 위한 사용자 인증, 본인인증, 및 정보제공 동의를 요청하는 단계; (b) 상기 공개인증 서버는 사용자 인증을 수행하되, 상기 제3자 서비스 앱의 사용자 인터페이스를 통해 사용자 인증정보를 입력받는 단계; (d) 상기 사용자 인증이 성공하면, 상기 공개인증 서버는 본인인증을 상기 본인인증 서버로 요청하되, 상기 본인인증 서버가 상기 제3자 서비스 앱의 사용자 인터페이스를 통해 본인인증 정보를 입력받도록 하고, 상기 공개인증 서버가 상기 본인인증의 결과를 직접 수신하는 단계; (e) 상기 본인인증이 성공하면, 상기 공개인증 서버는 정보제공 동의를 수행하되, 상기 제3자 서비스 앱의 사용자 인터페이스를 통해 환자의 정보제공 동의를 입력받는 단계; (f) 상기 정보제공 동의가 성공하면, 상기 공개인증 서버는 환자의 의료기록 전송을 허용하는 액세스토큰을 발급하여, 상기 제3자 서비스 앱에 전송하고, 상기 리소스 서버에 상기 액세스토큰에 의한 의료기록 전송의 허용 정보를 전송하는 단계; 및, (g) 상기 제3자 서비스 서버는 상기 제3자 서비스 앱으로부터 상기 액세스토큰을 수신하여 저장하고, 저장된 액세스토큰으로 상기 리소스 서버에 환자의 의료기록 전송을 요청하여 수신하는 단계를 포함하는 것을 특징으로 한다.
또한, 본 발명은 사용자 단말에 설치되는 제3자 서비스 앱, 상기 제3자 서비스 앱과 네트워크로 연결된 제3자 서비스 서버, 의료기관에서 운영하는 공개인증 서버, 의료기록을 저장하는 리소스 서버로 구성되는 의료기록 전송 시스템에 의해 수행되는, 제3자 중심의 공개인증 기반 의료기록 전송 방법에 관한 것으로서, (a) 상기 제3자 서비스 앱에서 상기 공개인증 서버의 공개된 프로토콜을 통해, 사용자 계정에 대한 사용자 인증을 요청하는 단계; (b) 상기 공개인증 서버는 사용자 인증을 수행하되, 상기 제3자 서비스 앱의 사용자 인터페이스를 통해 사용자 인증정보를 입력받는 단계; (c) 상기 사용자 인증이 성공하면, 상기 공개인증 서버는 사용자 계정으로 접속을 허용하는 액세스토큰을 발급하여, 상기 제3자 서비스 앱에 전송하는 단계; (d) 상기 제3자 서비스 앱은 상기 액세스토큰을 통해 상기 공개인증 서버로 본인인증을 요청하면, 상기 공개인증 서버는 본인인증을 상기 본인인증 서버로 요청하되, 상기 본인인증 서버가 상기 제3자 서비스 앱의 사용자 인터페이스를 통해 본인인증 정보를 입력받도록 하고, 상기 공개인증 서버가 상기 본인인증의 결과를 직접 수신하는 단계; (e) 상기 본인인증이 성공하면, 상기 공개인증 서버는 정보제공 동의를 수행하되, 상기 제3자 서비스 앱의 사용자 인터페이스를 통해 환자의 정보제공 동의를 입력받는 단계; (f) 상기 정보제공 동의가 성공하면, 상기 공개인증 서버는 환자의 의료기록 전송 승인 결과을 상기 제3자 서비스 앱에 전송하고, 상기 리소스 서버에 상기 액세스토큰에 의한 의료기록 전송의 허용 정보를 전송하는 단계; 및, (g) 상기 제3자 서비스 서버는 상기 제3자 서비스 앱으로부터 상기 액세스토큰을 수신하여 저장하고, 저장된 액세스토큰으로 상기 리소스 서버에 환자의 의료기록 전송을 요청하여 수신하는 단계를 포함하는 것을 특징으로 한다.
또, 본 발명은 제3자 중심의 공개인증 기반 의료기록 전송 방법에 있어서, 환자의 의료기록에 대한 정보제공 동의는 전송할 의료기록의 범위와, 해당 범위의 의료기록 전송을 허용하는 동의를 포함하는 것을 특징으로 한다.
또, 본 발명은 제3자 중심의 공개인증 기반 의료기록 전송 방법에 있어서, 상기 액세스토큰은 만료기간이 설정되고, 상기 액세스토큰의 만료기간이 경과하면, 상기 리소스 서버는 상기 액세스토큰을 통한 의료기록 요청을 허용하지 않는 것을 특징으로 한다.
상술한 바와 같이, 본 발명에 따른 제3자 중심의 공개인증 기반 의료기록 전송 시스템 및 방법에 의하면, 의료기관 시스템에서 사용자 인증 및 본인 인증, 정보제공 동의를 직접 수행하게 함으로써, 의료기관은 자신이 보유한 환자의 의료기록을 안전하게 외부로 반출할 수 있는 효과가 얻어진다.
또한, 본 발명에 따른 제3자 중심의 공개인증 기반 의료기록 전송 시스템 및 방법에 의하면, 의료기관의 인증이 완료되면 제3자 서비스 시스템이 액세스 토큰으로 직접 의료기관 시스템에 접속하여 필요한 의료기록 데이터를 가져옴으로써, 의료기관 시스템은 표준화된 인터페이스만 제공하여 기능 구현이 매우 단순화 시킬 수 있는 효과가 얻어진다.
도 1 및 2는 본 발명을 실시하기 위한 전체 시스템에 대한 구성도.
도 3은 본 발명의 제1 실시예에 따른 제3자 중심의 공개인증 기반 의료기록 전송 방법을 설명하는 흐름도.
도 4는 본 발명의 제1 실시예에 따른 본인인증 화면의 예시도.
도 5는 본 발명의 제1 실시예에 따른 정보제공 설정 화면의 예시도.
도 6은 본 발명의 제2 실시예에 따른 제3자 중심의 공개인증 기반 의료기록 전송 방법을 설명하는 흐름도.
이하, 본 발명의 실시를 위한 구체적인 내용을 도면에 따라서 설명한다.
또한, 본 발명을 설명하는데 있어서 동일 부분은 동일 부호를 붙이고, 그 반복 설명은 생략한다.
먼저, 본 발명을 실시하기 위한 전체 시스템의 구성을 도 1 및 도 2를 참조하여 설명한다.
도 1에서 보는 바와 같이, 본 발명을 실시하기 위한 전체 시스템은 사용자 단말(10)에 설치되어 의료기록을 수신 또는 수집하는 제3자 서비스 시스템(30), 및 의료기록을 관리하고 전송하는 의료기관 시스템(40)로 구성된다. 추가적으로, 사용자 본인 또는 실명을 인증하는 본인인증 서버(60)을 더 구비할 수 있다. 즉, 본인인증 서버와 연동될 수 있다. 또한, 상기 의료기관 시스템(40), 제3자 서비스 시스템(30), 및, 본인인증 서버(60)은 인터넷, 무선이동통신망 등 네트워크(20)에 연결되어, 서로 데이터 통신을 수행한다. 또한, 의료기록 등 데이터를 저장하기 위한 데이터베이스(50)를 더 포함하여 구성될 수 있다.
먼저, 사용자 단말(10)은 사용자 또는 환자가 이용하는 단말로서, PC, 스마트폰, 태블릿PC, 패블릿 등 통상의 컴퓨팅 기능을 구비한 단말이다. 또한, 셋탑박스, 스마트 TV 등 컴퓨팅 기능을 구비한 임베디드 기기(임베디드 시스템을 구비한 단말) 등도 해당될 수 있다. 특히, 사용자 단말(10)은 어플리케이션 또는, 모바일용 어플리케이션(또는 앱, 어플) 등이 설치되어 실행될 수 있는 단말이다. 이하에서, 사용자가 어떤 작업을 수행하는 설명은 사용자 단말(10) 또는 사용자 단말(10)에 설치된 프로그램(또는 앱)을 통해 수행하는 작업임을 의미한다.
다음으로, 제3자 서비스 시스템(30)은 사용자 단말(10)에 설치되어 수행되는 모바일용 어플리케이션(또는 앱, 어플)으로서, 의료기관과는 별도의 서비스 업체 또는 기관에서 관리되는 모바일 앱이다.
제3자 서비스 시스템(30)은 의료기관 시스템(40)의 공개된 인터페이스를 통해 사용자 인증, 본인 인증, 정보제공 설정 등의 작업을 수행하고, 그 결과로서 액세스 토큰을 수신한다. 그리고 제3자 서비스 시스템(30)은 액세스 토큰으로 의료기관 시스템(40)의 인증을 수행하고, 의료기관 시스템(40)로부터 공개된 인터페이스를 통해 의료기록을 수신하여 저장한다.
도 1 및 도 2에서 보는 바와 같이, 제3자 서비스 시스템(30)은 사용자 단말(10) 상에 독립적인 프로그램으로서 구현될 수도 있고, 서버와 클라이언트 형태로 구현될 수도 있다. 도 1은 전자의 구성 예시도이고, 도 2는 후자의 구성 예시도이다.
도 2에서 보는 바와 같이, 사용자 단말(10)에는 모바일 앱인 제3자 서비스 앱(31)이 설치되고, 제3자 서비스 서버(32)가 구축되어 네트워크(20) 상에 연결된다. 제3자 서비스 앱(31)은 제3자 서비스 서버(32)와 연동하여, 앞서 설명한 인증 작업이나 의료기록 요청 및 수신 작업들을 수행한다.
제3자 서비스 앱(31)과 제3자 서비스 서버(32)는 서버-클라이언트 모델에 따라 전체 서비스 시스템의 기능을 분담할 수 있다. 일례로서, 사용자 인증, 본인 인증, 정보제공 설정 등의 작업, 액세스 토큰을 수신하는 작업, 의료기록을 수신하는 작업 등 모든 작업이 제3자 서비스 앱(31)에 의해 수행되고, 단지 지속적으로 환자의 의료기록을 저장하는 기능만을 제3자 서비스 서버(32)에 의해 수행될 수 있다. 또한, 다른 예로서, 인증이나 정보제공 설정 작업과 액세스 토큰을 수신하는 작업은 제3자 서비스 앱(31)에 의해 수행되고, 액세스 토큰을 서버에 전송하면 제3자 서비스 서버(32)가 액세스 토큰을 통해 직접 의료기관 시스템(40)에 접속하여 의료기록을 가져오도록 구현될 수 있다. 또한, 또 다른 실시예로서, 제3자 서비스 앱(31)은 사용자 단말(10)의 디스플레이 등을 통해 인터페이스만 제공하고, 앞서 설명한 모든 기능을 제3자 서비스 서버(32)에 의해 수행하게 할 수 있다. 이하에서, 설명의 편의를 위하여, 제3자 서비스 시스템(30)으로만 설명하기로 한다.
다음으로, 의료기관 시스템(40)은 의료기록 또는 의료데이터를 보유한 병원, 요양원, 검진센터, 헬스케어 업체 등에서 운영하는 시스템으로서, 네트워크(20) 상에 연결되어, 인증된 사용자 또는 환자의 요청에 따라 의료기록을 제3자 서비스 시스템(30)으로 전송한다.
의료기관 시스템(40)은 사용자 인증, 본인 인증, 정보제공 설정 등 의료기록 제공을 위한 공개된 인터페이스(또는 공개 프로토콜)를 제공하고, 상기 공개된 프로토콜을 통해 인증 및 의료기록 정보제공 범위 등이 설정되면 이에 대한 액세스 토큰을 발행한다.
또한, 의료기관 시스템(40)는 액세스 토큰의 유효성이 체크된 사용자 또는 시스템에 의료기록 또는 의료 데이터를 제공하는 공개된 인터페이스를 제공한다. 즉, 제3자 서비스 시스템(30)은 액세스 토큰의 유효성을 체크 받고, 공개된 의료기록 요청 인터페이스를 통해, 원하는 의료기록 또는 의료데이터를 요청하고, 의료기관 시스템(40)은 요청된 의료기록을 공개된 인터페이스(또는 공개된 프로토콜)을 통해 요청자에게 전송한다. 이때 유효성 체크는 사용자 계정에 인증과 기간 만료 여부 등을 체크하는 것입니다.
한편, 의료기관 시스템(40)은 앞서 설명과 같이 인증 기능, 유효성 체크, 및, 의료기록 전송 기능 등을 가지는데, 각각의 기능들을 각각 독립된 서버로 구축할 수 있다. 즉, 의료기관 시스템(40)는 의료기관 내의 전산 시스템으로서, 시스템 설계에 따라 다수의 서버로 구성된 복합 시스템으로 실시될 수 있다.
다음으로, 본인인증 서버(60)는 환자 또는 사용자의 본인 인증(또는 실명 인증)을 수행하는 서버로서, 제3자 서비스 시스템(30)이나 의료기관 시스템(40)과는 별도의 외부 기관에서 운영하는 서버이다. 본인인증 서버(60)는 휴대폰 인증을 수행하는 이동통신사, 아이핀(i-PIN, 인터넷 개인식별번호) 인증을 수행하는 본인확인기관, 공인인증서 인증을 처리하는 공인인증기관 등의 서버이다. 또한, 그 외에도 본인 인증 또는 실명 인증을 수행하는 서버는 어느 서버나 적용이 가능하다.
다음으로, 본 발명의 일실시예에 따른 의료기관 시스템(40)의 구성을 보다 구체적으로 설명한다.
도 1 또는 도 2와 같이, 본 발명에 따른 의료기관 시스템(40)은 사용자 또는 환자의 등록 기능 등을 담당하는 환자포탈 서버(41), 의료기록 전송을 위해 공개된 프로토콜로 인증을 수행하는 공개인증 서버(42), 의료기록을 가져와서 이를 전송하는 리소스 서버(43), 및, 의료기록을 저장하는 의료정보 서버(44)로 구성될 수 있다.
환자포탈 서버(41)는 통상의 서버로서, 해당 의료기관의 환자 또는 사용자를 회원으로 등록하여, 사용자 계정을 생성하고, 상기 사용자 계정을 식별하는 사용자 아이디를 설정한다. 바람직하게는, 환자포탈 서버(41)는 의료기관의 통상의 웹 서버로서, 인터넷의 웹 상에서 의료기관의 관문으로의 포탈 서비스를 제공한다. 또한, 환자포탈 서버(41)는 스마트폰 등 모바일 플랫폼에 맞는 동일한 웹 기능을 제공할 수 있고, 별도의 포탈 서비스 앱을 위한 인터페이스를 제공할 수 있다.
환자포탈 서버(41)는 등록된 회원에 대하여, 사용자 아이디와 비밀번호 등 사용자 인증정보를 등록한다. 그리고 환자포탈 서버(41)는 사용자 인증정보로 인증되면 해당 사용자를 등록된 사용자로서 인식한다. 또한, 환자포탈 서버(41)는 사용자의 이름, 생년월일 등 추가적인 개인정보를 등록시킨다.
또한, 환자포탈 서버(41)에서 등록된 사용자의 개인정보를 의료정보 서버(44)에 기록된 환자의 개인정보와 대비하여, 해당 사용자의 사용자 아이디와 병록 아이디(또는 병록 식별정보)를 매핑시켜 저장할 수 있다. 즉, 환자포탈 서버(41)에서 환자 또는 사용자를 식별하기 위한 사용자 아이디와, 리소스 서버(43) 또는 의료정보 서버(44)에서 의료기록의 환자를 식별하기 위한 병록 아이디는 서로 다를 수 있다. 따라서 이들 2가지의 아이디(또는 식별정보)를 매핑시켜야 한다. 이를 위해, 환자포탈 서버(41)의 사용자 아이디의 개인정보, 예를 들어, 사용자의 이름이나 생년월일 등과, 의료정보 서버(44)에 기록된 환자의 개인정보를 대비하여, 일치할 때의 사용자 아이디와 병록 아이디가 서로 매핑된다.
바람직하게는, 환자포탈 서버(41) 또는 공개인증 서버(42)가 병록 아이디 및 사용자 아이디의 매핑 정보를 저장한다.
다음으로, 공개인증 서버(42)는 사용자 인증, 본인 인증, 또는, 정보제공 설정 등에 대한 기능을 공개된 인터페이스(또는 공개 프로토콜)를 통해 제공하고, 사용자 인증 등이 완료되면 액세스토큰을 발행한다. 그리고 발행된 액세스토큰으로 접속하는 제3자에게, 의료기관 시스템(40)은 사용자와 동일한 수준에서 그 요청을 처리해준다.
구체적으로, 제3자 서비스 시스템(30)에서 공개인증 서버(42)의 공개된 인터페이스를 통해 사용자 인증, 본인인증, 정보제공범위 설정 등이 완료되면, 공개인증 서버(42)는 제3자 서비스 시스템(30)에게 액세스토큰을 발급해준다. 액세스토큰은 만료기간(또는 사용기간)이 한정된 임시로 발급된 접근권한이다. 따라서 해당 사용기간이 경과되면, 발급된 액세스토큰은 그 권한이 소멸된다. 또한, 제3자 서비스 시스템(30)에서 사용자 인증 등이 수행되지만 공개인증 서버(42)의 공개된 인터페이스를 통해 진행되므로, 제3자 서비스 시스템(30)은 사용자 인증 등의 인증정보를 전혀 알지 못한다.
이후, 액세스토큰의 만료기간(또는 사용기간) 내에서, 제3자 서비스 시스템(30)이 액세스토큰을 통해 리소스 서버(43)에 접속하면, 리소스 서버(43)는 인증된 사용자와 같은 수준으로, 제3자 서비스 시스템(30)에게 서비스를 제공한다. 특히, 리소스 서버(43)는 제3자 서비스 시스템(30)의 요청에 따라 의료정보 서버(44)에 저장된 의료기록을 가져와서 전송해준다.
한편, 공개인증 서버(42)는 액세스토큰과 이에 대응하는 병록 아이디의 매핑 정보를 저장하여 보유한다. 앞서 설명한 바와 같이, 동일한 환자의 사용자 아이디와 병록 아이디는 서로 다를 수 있다. 공개인증 서버(42)에서 사용자 인증이 수행될 때에는 사용자 아이디로 사용하나, 이때 발급되는 액세스토큰에는 병록 아이디를 매핑시켜 저장해둔다. 액세스토큰으로 의료기록을 전송할 때에는 병록 아이디를 통해 의료기록를 찾기 때문이다.
다음으로, 의료정보 서버(44)는 의료기록을 저장하고 관리하는 서버로서, 바람직하게는, 전자의무기록(EMR, electronic medical record) 시스템이다. 그 외에 의료영상저장전송시스템(PACS, picture archiving communication system) 등 각종 환자의 의료정보를 저장하는 시스템이 적용될 수 있다.
한편, 의료정보 서버(44)는 환자의 의료기록에 대하여 병록 아이디(Patient ID)를 환자 식별정보로 사용한다. 따라서 의료기록을 접근하거나 참조시, 병록 아이디를 이용한다. 병록 아이디는 앞서 환자포탈 서버(41)에서 사용하는 사용자 아이디와 서로 다를 수 있다.
다음으로, 리소스 서버(43)는 의료정보 서버(44)에 저장된 의료기록 데이터를 가져와서, 외부의 요청에 따라 해당 의료기록을 전송한다. 특히, 리소스 서버(43)는 외부에 공개된 API를 제공하고, API의 호출에 의하여, 외부로부터 요청을 받는다. 즉, 제3자 서비스 시스템(30)이 리소스 서버(43)가 공개한 API를 호출함으로써, 리소스 서버(43)에 접근할 수 있다. 바람직하게는, 리소스 서버(43)는 웹 상의 API인 RESTful(REpresentational State Transfer) API를 제공하여, 의료기록을 전송한다.
또한, 리소스 서버(43)는 액세스토큰으로 접속하는 사용자 또는 시스템에게, 공개인증에 인증된 사용자 수준으로, 의료기록에 대한 접근 권한을 부여한다. 즉, 리소스 서버(43)는 액세스토큰 발생시의 정보제공범위 이내에서, 액세스토큰 사용자(또는 시스템)에게 의료기록 열람(또는 다운로드)을 허용한다. 이를 위해, 리소스 서버(43)는 병록 아이디와, 해당 아이디에 대하여 열람(또는 다운로드)을 허용하는 범위 정보를 보유하고, 액세스토큰에 대응되는 병록 아이디의 허용 범위 내에서만 의료기록을 허용한다.
또한, 바람직하게는, 리소스 서버(43)는 제3자가 직접 접근할 수 있도록 외부 네트워크와 연결되므로, 공개인증 서버(42)와 같은 시스템(장비)에 설치될 수 있다.
또한, 리소스 서버(43)는 제3자 서비스 시스템(30)에서 액세스토큰으로 접속해오면, 공개인증 서버(42)를 통해 액세스토큰의 유효성을 체크하게 하고, 그 결과로서 병록 아이디를 받아온다. 그래서 리소스 서버(43)는 받아온 병록 아이디를 어느 환자의 의료기록을 요청하는 것인지를 식별한다.
다음으로, 본 발명의 제1 실시예에 따른 제3자 중심의 공개인증 기반 의료기록 전송 방법을 도 3을 참조하여 설명한다.
도 3에서 보는 바와 같이, 먼저, 환자 또는 사용자가 병원 등 의료기관의 환자포탈 서버(41)에 회원으로 등록하고, 사용자 계정을 생성하고, 사용자 인증정보, 즉, 사용자 아이디(또는 환자 아이디)와 패스워드 등을 등록한다(S11). 이때, 환자 또는 사용자가 환자포탈 서버(41)에 직접 접속한다. 또한, 회원 등록시, 환자 또는 사용자는 환자포탈 서버(42)에 이름, 생년월일, 성별, 연락처(전화번호, 주소) 등 개인정보를 등록한다.
이때, 등록되는 사용자 아이디는 사용자가 환자포탈 서버(41) 또는 의료기관 시스템(40)에 접속하기 위한 식별정보이다. 리소스 서버(43)에서 환자를 식별하기 위한 병록 아이디와는 다를 수 있다. 병록 아이디는 해당 환자의 의료기록을 열람 또는 추출하기 위한 환자의 식별정보(또는 식별번호)이다.
다음으로, 환자포탈 서버(41)는 사용자 아이디와 병록 아이디를 매핑시켜 저장한다(S12). 이를 위해, 환자포탈 서버(41)는 의료정보 서버(44)와 함께, 사용자의 개인정보와, 환자의 개인정보를 대비하여, 사용자 또는 환자의 동일인 여부를 확인하고, 동일인 일 때 사용자 아이디와 병록 아이디를 매핑시킨다. 다른 실시예로서, 양 아이디의 매칭 작업을 공개인증 서버(42)에서 수행될 수 있다.
다음으로, 환자 또는 사용자는 제3자 서비스 앱(31)에 로그인을 수행한다(S21). 이때, 제3자 서비스 앱(31)이 제3자 서비스 서버(32)와 연동되어, 앱 사용에 대한 사용자 인증을 제3자 서비스 서버(32)에 의해 수행될 수 있다(S22).
다음으로, 환자 또는 사용자는 자신의 의료기록을 보관하고 있는 의료기관(또는 자신의 의료기록을 열람하려는 의료기관)을 선택한다(S23). 바람직하게는, 제3자 서비스 앱(31)은 의료기관의 목록을 리스트 해주고, 사용자(또는 환자)가 목록 중에서 선택할 수 있다. 이때, 의료기관 목록은 사용자가 자주 가는 병원 등을 사전에 등록되어 구성될 수 있다. 특히, 목록의 의료기관들은 의료기록 열람(또는 다운로드)을 위한 인증, 또는 의료기록 열람이나 전송 등을 위한 인터페이스(또는 프로토콜)을 공개한 의료기관이다. 바람직하게는, 의료기관들은 공개 인터페이스를 사전에 등록한 제3자 서비스 시스템(30)들만 접근하게 할 수 있다. 즉, 공개 인터페이스를 이용할 제3자 서비스 시스템들을 사전에 등록하게 하고, 등록된 제3자 서비스 시스템들에게만 공개 인터페이스 접근을 허용할 수 있다.
다음으로, 제3자 서비스 앱(31)은 선택된 의료기관의 공개된 인터페이스(또는 프로토콜)를 이용하여, 사용자 인증, 본인 인증, 및, 정보제공 동의 등 공개 인증을 요청한다(S30). 특히, 제3자 서비스 앱(31)은 의료기관 시스템(40) 또는 공개인증 서버(42)에서 제공하는 공개 API(Application Program Interface)를 호출하여 요청한다.
다음으로, 해당 의료기관 시스템(40)의 공개인증 서버(42)는 제3자 서비스 앱(31)의 공개인증 요청에 대하여, 먼저, 사용자 인증을 수행한다(S41). 공개인증 서버(42)는 사용자 인증용 페이지를 제3자 서비스 앱(31)으로 전송하여, 해당 인증용 페이지에 사용자 인증정보, 즉, 아이디와 패스워드를 입력받는다(S42). 엄밀하게는, 제3자 서비스 앱(31)이 리다이렉트(Redirect) 명령에 의하여 사용자 인증용 페이지를 가져오는 것이나, 공개인증 서버(42)가 사용자 인증용 페이지를 접속하도록 유도하는 것이므로, 이하에서도, 공개인증 서버(42) 등이 전송한다라고 표현한다.
또한, 이때, 제3자 서비스 앱(31)은 공개인증 서버(42)에서 직접 제공되는 사용자 인증용 페이지를 사용자 인터페이스(또는 화면)에 표시할 뿐, 사용자 인증을 위한 데이터에 직접 접근하지 못한다. 따라서 제3자 서비스 앱(31)은 사용자 아이디나 패스워드 등 사용자 인증을 위한 정보(사용자 인증 정보)에 전혀 접근하지 못하고, 이에 대한 데이터를 자신이 전혀 보유하지 않는다.
공개인증 서버(42)는 사용자(또는 환자)의 아이디 및 패스워드를 검증하여, 사용자 인증을 수행한다(S43). 이때, 공개인증 서버(42)는 환자포탈 서버(41)를 통해 사용자의 아이디 및 패스워드를 검증할 수 있다.
또한, 공개인증 서버(42)는 사용자 아이디에 매핑되는 병록 아이디를 추출한다(S44). 바람직하게는, 공개인증 서버(42)는 환자포탈 서버(41)로부터 사용자 아이디에 대응되는 병록 아이디를 받아올 수 있다. 또한, 사용자의 개인정보도 받아올 수 있다.
다음으로, 환자에 대한 사용자 인증이 성공적으로 완료되면, 공개인증 서버(42)는 본인인증 서버(60)에 본인 인증을 요청하여(S51), 환자 자신의 본인인증을 위한 절차를 수행시킨다(S52). 즉, 공개인증 서버(42)는 본인인증 서버(60)의 본인인증을 위한 접속 페이지를 제3자 서비스 앱(31)으로 전달하고, 이후 본인인증 서버(60)가 제3자 서비스 앱(31)과 직접 연결하여 본인인증을 수행하게 한다. 제3자 서비스 앱(31)에서 공개인증서버(42)에 본인인증을 위해 정의되어 있는 재접속 주소(Redirect URL) 호출하면 본인인증 서버(42)의 인증페이지에 접속한다.
본인인증은 핸드폰 인증, 아이핀 인증, 공인인증서 인증 등 본인 또는 실명을 확인하는 인증 방법이다. 또한, 공개인증 서버(42)는 사용자 또는 환자로 하여금 다수의 본인인증 방식 중에서 1개를 선택하게 할 수 있다.
다음으로, 본인인증 서버(60)는 제3자 서비스 앱(31) 상에서 입력되는 사용자 또는 환자의 본인정보를 직접 입력받는다(S53). 즉, 본인인증 서버(60)에서의 본인 인증을 위한 본인정보 입력 등 본인인증 절차를 제3자 서비스 앱(31)의 사용자 인터페이스(UI) 상에서 수행하도록 한다. 따라서 환자 등 사용자는 제3자 서비스 앱(31)의 사용자 인터페이스(UI) 상에서 본인 인증을 수행하나, 공개인증 서버(42)의 요청에 따라 본인인증 서버(60)에서 수행되는 본인 인증을 수행한다.
그리고 본인인증 서버(60)는 본인인증에 대한 결과를 공개인증 서버(42)로 전송한다(S54). 즉, 공개인증 서버(42)는 본인인증 서버(60)로부터 본인인증에 대한 결과를 직접 수신한다.
그리고 공개인증 서버(42)는 본인인증 서버(60)로부터 수신한 본인인증 결과(또는 실명정보)를 해당 사용자의 개인정보와 대비하여, 본인인증한 사용자가 회원으로 등록한 사용자인지를 확인한다(S55). 본인인증 결과는 사용자의 실명정보로서, 이름, 생년월일, 성별 등 개인 실명정보이다. 따라서 공개인증 서버(42)는 본인인증 서버(60)에서 받아온 실명정보를 사용자의 개인정보와 비교하여, 해당 사용자가 본인인증한 것임을 추가로 확인한다. 이때 비교하는 사용자의 개인정보는 환자포탈 서버(41)에 요청하여 가져오거나, 앞서 단계(S12)에서 미리 받아둔 개인정보를 이용할 수 있다. 대비결과, 양 실명정보가 동일하지 않으면, 동일인이 아닌 것으로 판단한다. 동일인이 아니면 제3자 서비스 앱(31)의 화면에 "동일인이 아니므로 진료정보를 제공할 수 없습니다."는 안내 메시지를 출력한다.
도 4는 본인 인증의 화면을 예시하고 있다.
다음으로, 사용자에 대한 본인인증이 성공하면, 공개인증 서버(42)는 제3자 서비스 앱(31)을 통해 사용자 또는 환자에게 정보제공 동의를 요청한다(S61). 공개인증 서버(42)는 정보제공 동의 페이지(또는 화면)를 제3자 서비스 앱(31)으로 전송하여, 제3자 서비스 앱(31) 상에서 의료기록이 제3자에게 전송된다는 것에 대한 환자의 동의를 제출받는다(S62). 구체적으로, 공개인증 서버(42)가 제3자 정보제공 동의 페이지를 제3자 서비스 앱(31)에서 제3자 정보제공동의 페이지의 URL을 호출하면, 해당 페이지를 전송하는 방식으로 동작된다.
바람직하게는, 정보제공 동의는 정보제공 범위, 및 그 범위 내에서 정보제공을 할 수 있다는 동의를 포함한다. 정보제공 범위는 환자 자신의 의료기록을 외부로 전송하고자 하는 범위이다. 의료기록 데이터의 범위는 진료 내용, 기간 등에 따라 범위가 설정될 수 있다. 예를 들어, 진료 내용은 수진 데이터, 처방 제이터, 검사결과 데이터, 건강검진 데이터, 수술 내역 등의 카테고리로 분류되고, 해당 카테고리 별로 설정될 수 있다. 또한, 의료기록 데이터의 열람/전송 범위를 6개월, 1년, 3년, 5년 등 정해진 기간이나 사용자가 정해진 기간으로 설정될 수 있다.
도 5는 정보제공 동의 화면을 예시하고 있다. 도 5와 같이, 환자의 의료기록 데이터를 종류 별로 선택하여, 제3자로의 정보제공 범위를 설정하고, 이에 대한 동의를 설정한다. 도 5와 같이, 환자의 의료기록 데이터를 종류별로 선택하거나 기간을 설정하는 등 제3자로의 정보제공 범위를 설정하고 “동의하기” 버튼을 클릭한다. 또한, 범위 설정시 제공할 의료기록의 기간이나, 정보를 전송해주는 주기 등도 설정할 수 있다.
다음으로, 공개인증 서버(42)는 앞서 설정한 정보제공 범위 내에서 사용자의 의료기록에 접근하거나 전송받을 수 있는 액세스토큰을 생성한다(S70). 즉, 제3자는 발급된 액세스토큰으로 리소스 서버(43)(또는 공개인증 서버(42))에 접속하면, 해당 사용자 또는 환자의 의료기록을 접근하여 다운로드받을 수 있다. 특히, 제공받을 수 있는 의료기록의 범위는 앞서 정보제공 설정 단계(S61,S62)에서 설정한 범위 내이다.
액세스토큰은 서버에 접근 또는 접속할 수 있는 사용자의 인증정보를 담고 있는 고유 코드이다.
이때, 공개인증 서버(42)는 정책적 필요에 따라 액세스토큰의 만료기간(expire time)을 설정할 수 있다. 액세스토큰이 만료기간이 경과하면, 해당 액세스토큰으로 리소스 서버(43)에 접속할 수 없고, 당연히 환자 의료기록에 접근할 수도 없다. 즉, 리소스 서버(43)는 액세스토큰으로 의료기록 접근 요청을 받으면, (공개인증서버를 통해) 액세스토큰의 유효성(또는 만료기간)을 체크하고, 해당 기간을 경과하면 접근을 허용하지 않는다. 따라서 액세스토큰의 만료기간이 경과되면, 제3자 서비스 앱(31)에서 해당 의료기관의 공개인증과 본인인증 등을 다시 수행해서 새로운 액세스토큰을 발급받아야 한다.
다음으로, 공개인증 서버(42)는 발급된 액세스토큰과 병록 아이디를 매핑하여 저장한다(S70b). 앞서 사용자 인증 시 사용자 아이디에 매핑되는 병록 아이디를 추출하였다. 추출된 병록 아이디가 발급된 액세스토큰에 매핑된다.
다음으로, 공개인증 서버(42)는 해당 병록 아이디와 함께 정보제공 범위 정보를 리소스 서버(43)에 전송한다(S71). 앞서 단계의 인증 결과는 해당 사용자 아이디(또는 매핑된 병록 아이디)와, 의료기록의 정보제공 범위, 액세스토큰에 의한 접속 허용 내용, 허용 기간 등을 포함한다. 리소스 서버(43)가 액세스토큰을 직접 인증하는 경우 액세스토큰을 수신받을 수도 있고, 공개인증 서버(42)를 통해 액세스토큰의 유효성 체크를 수행하는 경우에는 액세스토큰을 직접 수신하지 않는다.
그리고 리소스 서버(43)는 해당 액세스토큰에 대한 정보제공 허용 내용을 저장한다(S72). 즉, 정보제공 허용 내용은 병록 아이디, 정보제공 범위 등으로 구성된다. 리소스 서버(43)는 정보제공 허용 내용을 각 병록 아이디 별로 정보제공 허용 리스트로 관리할 수 있다. 즉, 리소스 서버(43)는 정보제공 허용 내용에 따라, 해당 액세스토큰으로 접속하는 제3자에게, 해당 정보제공 범위 내에서, 해당 병록 아이디의 의료기록을 전송할 수 있다.
다음으로, 공개인증 서버(42)는 발급된 액세스토큰을 제3자 서비스 앱(31)으로 전송한다(S73). 또한, 제3자 서비스 앱(31)은 수신한 액세스토큰을 제3자 서비스 서버(32)로 전달한다(S74). 제3자 서비스 서버(32)는 수신받은 액세스토큰을 저장해둔다(S75).
앞서 모든 단계에서, 제3자 서비스 앱(31) 또는 제3자 서비스 서버(32)는 의료기관 시스템(40)에서의 사용자 아이디나 비밀번호, 또는 본인인증 정보 등을 전혀 보유하지 않는다. 다만, 제3자 서비스 앱(31) 또는 제3자 서비스 서버(32)는 유효성이 체크된 액세스토큰만을 수신할 수 있고, 해당 액세스토큰으로 사용자 또는 환자의 의료기록을 접근하거나 다운로드 받을 수 있다.
다음으로, 제3 서비스 서버(32)는 액세스토큰으로 리소스 서버(43)에 접속하여, 의료기록 데이터를 요청한다(S81). 이때, 리소스 서버(43)는 의료기록 요청을 위한 웹 상에서의 API(Application Program Interface)를 제공하고, 제3 서비스 서버(32)는 웹 상의 API를 호출하여 의료기록 또는 의료 데이터를 요청한다. 특히, 웹상의 API를 호출시 액세스토큰으로 인증정보(또는 유효성 체크 정보)를 보낸다. 바람직하게는, 웹 상의 API는 RESTful(REpresentational State Transfer) API로 구현된다. 리소스 서버(43)가 RESTful API를 제공하고, 그 요청을 받아, 의료정보 서버(44)로부터 의료기록 데이터를 가져와서, 리소스 서버(43)가 제3자 서비스 서버(32)로 전송한다.
다음으로, 리소스 서버(43)는 액세스토큰에 대한 유효성 체크를 수행한다(S82). 이때, 리소스 서버(43)는 액세스토큰에 대한 유효성 체크(또는 인증)를 공개인증 서버(42)를 통해 수행시키게 한다.
또한, 리소스 서버(43)는 해당 액세스토큰에 대한 병록 아이디를 공개인증 서버(42)로부터 받아온다(S83). 앞서 공개인증 서버(42)는 액세스토큰과 병록아이디의 매핑 정보를 저장해두고 있고, 저장된 매핑 정보를 이용하여 액세스토큰이 확인되면 해당 액세스토큰의 병록 아이디를 전송해준다.
다음으로, 리소스 서버(43)는 액세스토큰에 대한 유효성 체크(또는 인증)가 완료되면, 제3 서비스 서버(32)의 요청에 따른 의료기록을 전송한다(S84). 즉, 리소스 서버(43)는 정보제공 허용 내용 또는 정보제공 허용 리스트에 따라, 유효성이 체크된 액세스토큰으로 접근한 제3자에게, 해당 정보제공 범위 내에서, 해당 병록 아이디의 의료기록을 전송한다.
이때, 리소스 서버(43)는 요청된 의료 데이터를 의료정보 서버(44)로부터 가져와서 포맷하고 포맷된 의료기록 데이터를 전송해준다. 바람직하게는, 리소스 서버(43)는 수신한 의료기록을 XML 또는 json 등의 형식으로 변환하여, 변환된 의료 데이터를 제3자 서비스 서버(32)에 전송한다. 제3자 서비스 서버(32)는 수신한 데이터를 파싱(parsing)하여 추출된 의료 데이터를 저장한다.
다음으로, 본 발명의 제2 실시예에 따른 제3자 중심의 공개인증 기반 의료기록 전송 방법을 도 6을 참조하여 설명한다.
도 6에서 보는 바와 같이, 먼저, 환자 또는 사용자가 병원 등 의료기관의 환자포탈 서버(41)에 회원으로 등록하고, 사용자 인증정보, 즉, 사용자 아이디(또는 환자 아이디)와 패스워드 등을 등록한다(S111). 이때, 환자 또는 사용자는 환자포탈 서버(42)에 이름, 생년월일, 성별, 연락처(전화번호, 주소) 등 개인정보를 등록한다. 환자포탈에 등록된 개인정보는 별도의 본인인증 절차를 거쳐 실명확인을 거치기도 한다.
다음으로, 환자포탈 서버(41)는 사용자 아이디와 병록 아이디를 매핑시켜 저장한다(S112). 이를 위해, 환자포탈 서버(41)는 의료정보 서버(44)와 함께, 사용자의 개인정보와, 환자의 개인정보를 대비하여, 사용자 또는 환자의 동일인 여부를 확인하고, 동일인 일 때 사용자 아이디와 병록 아이디를 매핑시킨다.
다음으로, 환자 또는 사용자는 제3자 서비스 앱(31)에 로그인을 수행한다(S121). 이때, 제3자 서비스 앱(31)이 제3자 서비스 서버(32)와 연동되어, 앱 사용에 대한 사용자 인증을 제3자 서비스 서버(32)에 의해 수행될 수 있다(S122). 그리고 환자 또는 사용자는 자신의 의료기록을 보관하고 있는 의료기관(또는 자신의 의료기록을 열람하려는 의료기관)을 선택한다(S123).
다음으로, 제3자 서비스 앱(31)은 선택된 의료기관의 공개된 인터페이스(또는 공개된 API)를 이용하여, 사용자 인증을 위한 공개 인증을 요청한다(S140). 특히, 제3자 서비스 앱(31)은 공개인증 서버(42)에서 제공하는 공개 API(Application Program Interface)를 호출하여 요청한다.
해당 의료기관 시스템(40)의 공개인증 서버(42)는 제3자 서비스 앱(31)의 공개인증 요청에 대하여, 먼저, 사용자 인증을 수행한다(S141). 공개인증 서버(42)는 사용자 인증용 페이지를 제3자 서비스 앱(31)으로 전송하여, 해당 인증용 페이지에 사용자 인증정보, 즉, 아이디와 패스워드를 입력받는다(S142). 이때, 제3자 서비스 앱(31)은 사용자 아이디나 패스워드 등 사용자 인증을 위한 정보(사용자 인증 정보)에 전혀 접근하지 못하고, 이에 대한 데이터를 자신이 전혀 보유하지 않는다. 공개인증 서버(42)는 사용자(또는 환자)의 아이디 및 패스워드를 검증하여, 사용자 인증을 수행한다(S143). 이때, 공개인증 서버(42)는 환자포탈 서버(41)를 통해 사용자의 아이디 및 패스워드를 검증할 수 있다. 또한, 공개인증 서버(42)는 사용자 아이디에 매핑되는 병록 아이디를 추출한다(S143b).
다음으로, 공개인증 서버(42)는 사용자 아이디에 해당하는 사용자 계정에 접근할 수 있는 액세스토큰을 발급한다(S144). 즉, 제3자는 발급된 액세스토큰으로 공개인증 서버(42)(또는 리소스 서버(43))에 접속하면, 해당 사용자 또는 환자의 사용자 계정으로 접근하는 것과 같은 권한을 갖는다. 즉, 공개인증 서버(42)는 해당 액세스토큰으로 접속한 제3자를 사용자 계정으로 접속한 사용자와 같은 권한으로 판단한다. 액세스토큰은 서버에 접근 또는 접속을 허용하는 고유 코드이다.
이때, 공개인증 서버(42)는 정책적 필요에 따라 액세스토큰의 만료기간(expire time)을 설정할 수 있다. 액세스토큰이 만료기간이 경과하면, 해당 액세스토큰으로 공개인증 서버(42)에 접속할 수 없고, 당연히 사용자 계정에 접근할 수도 없다. 즉, 공개인증 서버(42)는 액세스토큰으로 접근 요청을 받으면, 액세스토큰의 만료기간을 체크하고, 해당 기간을 경과하면 접근을 허용하지 않는다. 따라서 액세스토큰의 만료기간이 경과되면, 제3자 서비스 앱(31)에서 공개인증 서버(42)를 통해 사용자 인증을 다시 수행해서 새로운 액세스토큰을 발급받아야 한다.
또한, 이때,, 공개인증 서버(42)는 발급된 액세스토큰과 병록 아이디를 매핑하여 저장한다(S144b). 앞서 사용자 인증 시 추출한 병록 아이디를 발급된 액세스토큰에 매핑한다.
다음으로, 공개인증 서버(42)는 발급된 액세스토큰을 제3자 서비스 앱(31)으로 전송한다(S145). 또한, 제3자 서비스 앱(31)은 수신한 액세스토큰을 저장해둔다(S146).
또한, 공개인증 서버(42)는 액세스토큰에 대한 정보를 리소스 서버(43)에 전송한다(S147). 액세스토큰에 대한 정보는 매핑된 병록 아이디(또는 사용자 아이디)와, 액세스토큰에 의한 접속 허용 내용, 허용 기간 등을 포함한다. 그러나 이 경우, 의료기록에 대한 전송이 허용되지는 않는다. 아직 사용자가 실명인증을 하고, 의료기록에 대한 정보제공 동의 및 그 범위 설정을 하지 않았기 때문이다.
다음으로, 환자에 대한 사용자 인증이 성공적으로 완료되면, 제3자 서비스 앱(31)은 저장된 액세스토큰으로 공개인증 서버(42)에 접속하여 본인인증을 요청한다(S150). 공개인증 서버(42)는 액세스토큰의 유효성을 체크하여, 해당 액세스토큰에 대응되는 사용자 계정을 확인하고, 해당 사용자 계정으로 본인인증 요청이 수신되었음을 확인한다.
공개인증 서버(42)는 본인인증 서버(60)에 본인 인증을 요청하여(S151), 환자 자신의 본인인증을 위한 절차를 수행시킨다(S152). 즉, 공개인증 서버(42)는 본인인증 서버(60)의 본인인증을 위한 접속 페이지를 제3자 서비스 앱(31)으로 전달하고, 이후 본인인증 서버(60)가 제3자 서비스 앱(31)과 직접 연결하여 본인인증을 수행하게 한다.
본인인증 서버(60)는 제3자 서비스 앱(31) 상에서 입력되는 사용자 또는 환자의 본인정보를 직접 입력받는다(S153). 즉, 본인인증 서버(60)에서의 본인 인증을 위한 본인정보 입력 등 본인인증 절차를 제3자 서비스 앱(31)의 사용자 인터페이스(UI) 상에서 수행하도록 한다. 따라서 환자 등 사용자는 제3자 서비스 앱(31)의 사용자 인터페이스(UI) 상에서 본인 인증을 수행하나, 공개인증 서버(42)의 요청에 따라 본인인증 서버(60)에서 수행되는 본인 인증을 수행한다.
그리고 본인인증 서버(60)는 본인인증에 대한 결과를 공개인증 서버(42)로 전송한다(S154). 즉, 공개인증 서버(42)는 본인인증 서버(60)로부터 본인인증에 대한 결과를 직접 수신한다.
그리고 공개인증 서버(42)는 본인인증 서버(60)로부터 수신한 본인인증 결과(또는 실명정보)를 자신이 보유한 해당 사용자의 개인정보와 대비하여, 본인인증한 사용자가 회원으로 등록한 사용자인지를 확인한다(S155). 양 실명정보가 동일하지 않으면, 동일인이 아닌 것으로 판단한다. 동일인이 아니면 제3자 서비스 앱(31)의 화면에 "동일인이 아니므로 진료정보를 제공할 수 없습니다."는 안내 메시지를 출력한다.
다음으로, 사용자에 대한 본인인증이 성공하면, 공개인증 서버(42)는 제3자 서비스 앱(31)을 통해 사용자 또는 환자에게 정보제공 동의를 요청한다(S161). 공개인증 서버(42)는 정보제공 동의 페이지(또는 화면)를 제3자 서비스 앱(31)으로 전송하여, 제3자 서비스 앱(31) 상에서 의료기록이 제3자에게 전송된다는 것에 대한 환자의 동의를 제출받는다(S162). 바람직하게는, 정보제공 동의는 정보제공 범위, 및 그 범위 내에서 정보제공을 할 수 있다는 동의를 포함한다.의료기록 데이터의 전송 범위는 진료 내용, 기간 등에 따라 범위가 설정될 수 있다.
다음으로, 공개인증 서버(42)는 실명인증 후 설정된 의료기록의 정보제공 범위를 리소스 서버(43)에 전송한다(S171). 해당 사용자(환자)의 병록 아이디와, 의료기록의 정보제공 범위, 허용 기간 등을 포함한다.
다음으로, 리소스 서버(43)는 해당 액세스토큰에 대한 정보제공 허용 내용을 구성하여 저장한다(S172). 즉, 정보제공 허용 내용은 병록 아이디, 정보제공 범위 등으로 구성된다. 리소스 서버(43)는 정보제공 허용 내용을 각 병록 아이디 별로 정보제공 허용 리스트로 관리할 수 있다. 즉, 리소스 서버(43)는 정보제공 허용 내용에 따라, 해당 액세스토큰으로 접속하는 제3자에게, 해당 정보제공 범위 내에서, 해당 병록 아이디의 의료기록을 전송할 수 있다.
다음으로, 공개인증 서버(42)는 해당 액세스토큰에 대하여 의료기록 접근 허용 메시지를 제3자 서비스 앱(31)으로 전송한다(S173).
다음으로, 제3자 서비스 앱(31)은 수신한 액세스토큰을 제3자 서비스 서버(32)로 전달한다(S174). 제3자 서비스 서버(32)는 수신받은 액세스토큰을 저장해둔다(S175).
본 발명의 제2 실시예에서도, 앞서 모든 단계에서, 제3자 서비스 앱(31) 또는 제3자 서비스 서버(32)는 의료기관 시스템(40)에서의 사용자 아이디나 비밀번호, 또는 본인인증 정보 등을 전혀 보유하지 않는다.
다음으로, 제3 서비스 서버(32)는 액세스토큰으로 리소스 서버(43)에 접속하여, 의료기록 데이터를 요청한다(S181). 이때, 리소스 서버(43)는 의료기록 요청을 위한 웹 상에서의 API를 제공하고, 제3 서비스 서버(32)는 웹 상의 API를 호출하여 의료기록 또는 의료 데이터를 요청한다. 특히, 웹상의 API를 호출시 액세스토큰으로 인증정보를 보낸다. 바람직하게는, 웹 상의 API는 RESTful API로 구현된다.
다음으로, 리소스 서버(43)는 액세스토큰에 대한 유효성 체크를 수행한다(S182). 이때, 리소스 서버(43)는 액세스토큰에 대한 유효성 체크를 공개인증 서버(42)를 통해 수행시키게 한다.
또한, 리소스 서버(43)는 해당 액세스토큰에 대한 병록 아이디를 공개인증 서버(42)로부터 받아온다(S183). 그리고 리소스 서버(43)는 액세스토큰에 대한 유효성 체크가 완료되면, 제3 서비스 서버(32)의 요청에 따른 의료기록을 전송한다(S184). 즉, 리소스 서버(43)는 정보제공 허용 내용(범위 등) 또는 정보제공 허용 리스트에 따라, 유효성이 체크된 액세스토큰으로 접근한 제3자에게, 해당 정보제공 범위 내에서, 해당 병록 아이디의 의료기록을 전송한다.
이때, 액세스토큰이 유효성 체크가 되었더라도, 액세스토큰의 정보제공 허용 내용이 없거나, 의료기록 전송이 허용되지 않은 경우에는, 리소스 서버(43)는 의료기록을 전송하지 않는다. 이 경우는 사용자 또는 환자가 사용자 인증을 하여 액세스토큰을 발급받았으나 본인인증 이나 정보제공 동의를 하지 않은 경우이다.
이상, 본 발명자에 의해서 이루어진 발명을 상기 실시 예에 따라 구체적으로 설명하였지만, 본 발명은 상기 실시 예에 한정되는 것은 아니고, 그 요지를 이탈하지 않는 범위에서 여러 가지로 변경 가능한 것은 물론이다.
10 : 사용자 단말 20 : 네트워크
30 : 제3자 서비스 시스템 31 : 제3자 서비스 앱
32 : 제3자 서비스 서버
40 : 의료기관 시스템 41 : 환자포탈 서버
42 : 공개인증 서버 43 : 리소스 서버
44 : 의료정보 서버
60 : 본인인증 서버

Claims (11)

  1. 제3자 중심의 공개인증 기반 의료기록 전송 시스템에 있어서,
    사용자 단말에 설치되는 제3자 서비스 앱;
    상기 제3자 서비스 앱과 네트워크로 연결된 제3자 서비스 서버;
    환자를 회원으로 등록하여 사용자 계정을 생성하고, 상기 사용자 계정을 인증하기 위한 사용자 인증정보를 등록하는 환자포털 서버;
    사용자 인증, 본인인증, 및, 정보제공 동의를 공개된 프로토콜에 의해 수행하고, 사용자 인증, 본인인증, 및 정보제공 동의가 완료되면 액세스토큰을 발급하는 공개인증 서버; 및,
    상기 액세스토큰을 통해 의료기록을 요청하는 경우, 상기 환자의 의료기록을 전송하는 리소스 서버를 포함하고,
    상기 제3자 서비스 앱은 상기 공개인증 서버의 공개된 프로토콜을 통해 상기 사용자 인증, 본인인증, 및, 정보제공 동의를 요청하고, 사용자 인증, 본인인증, 및, 정보제공 동의에 필요한 환자의 입력을 받기 위하여 사용자 인터페이스 화면을 제공하고, 상기 공개인증 서버로부터 액세스토큰을 수신받아 상기 제3자 서비스 서버에 전송하면, 상기 제3자 서비스 서버는 상기 액세스토큰을 이용하여 상기 리소스 서버에 접속하여 환자의 의료기록을 다운로드 받고,
    환자의 의료기록에 대한 정보제공 동의는 전송할 의료기록의 범위와, 해당 범위의 의료기록 전송을 허용하는 동의를 포함하고,
    상기 공개인증 서버는 상기 사용자 계정의 사용자 아이디와, 병록 아이디를 서로 매핑하여 저장하되, 상기 병록 아이디는 환자의 의료기록에 대하여 환자의 식별번호로 이용되는 아이디이고,
    상기 리소스 서버는 환자의 병록 아이디 별로 정보제공 허용 범위를 저장하고,
    상기 리소스 서버는 액세스토큰으로 환자의 의료기록 전송 요청을 받으면, 상기 액세스토큰의 유효성 체크를 상기 공개인증 서버를 통해 처리하고, 상기 공개인증 서버로부터 상기 액세스토큰에 대응되는 병록 아이디를 수신하여, 수신된 병록 아이디의 정보제공 허용 범위 내에서 상기 병록 아이디의 의료기록을 전송하는 것을 특징으로 하는 제3자 중심의 공개인증 기반 의료기록 전송 시스템.
  2. 제3자 중심의 공개인증 기반 의료기록 전송 시스템에 있어서,
    사용자 단말에 설치되는 제3자 서비스 앱;
    상기 제3자 서비스 앱과 네트워크로 연결된 제3자 서비스 서버;
    환자를 회원으로 등록하여 사용자 계정을 생성하고, 상기 사용자 계정을 인증하기 위한 사용자 인증정보를 등록하는 환자포털 서버;
    사용자 인증, 본인인증, 및, 정보제공 동의를 공개된 프로토콜에 의해 수행하고, 사용자 인증, 본인인증, 및 정보제공 동의가 완료되면 액세스토큰을 발급하는 공개인증 서버; 및,
    상기 액세스토큰을 통해 의료기록을 요청하는 경우, 상기 환자의 의료기록을 전송하는 리소스 서버를 포함하고,
    상기 제3자 서비스 앱은 상기 공개인증 서버의 공개된 프로토콜을 통해 상기 사용자 인증, 본인인증, 및, 정보제공 동의를 요청하고, 사용자 인증, 본인인증, 및, 정보제공 동의에 필요한 환자의 입력을 받기 위하여 사용자 인터페이스 화면을 제공하고, 상기 공개인증 서버로부터 액세스토큰을 수신받아 상기 제3자 서비스 서버에 전송하면, 상기 제3자 서비스 서버는 상기 액세스토큰을 이용하여 상기 리소스 서버에 접속하여 환자의 의료기록을 다운로드 받고,
    환자의 의료기록에 대한 정보제공 동의는 전송할 의료기록의 범위와, 해당 범위의 의료기록 전송을 허용하는 동의를 포함하고,
    상기 공개인증 서버는 상기 사용자 계정의 사용자 아이디와, 병록 아이디를 서로 매핑하여 저장하되, 상기 병록 아이디는 환자의 의료기록에 대하여 환자의 식별번호로 이용되는 아이디이고,
    상기 리소스 서버는 환자의 병록 아이디 별로 정보제공 허용 범위를 저장하고,
    상기 리소스 서버는 액세스토큰으로 환자의 의료기록 전송 요청을 받으면, 상기 액세스토큰의 유효성 체크를 상기 공개인증 서버를 통해 처리하고, 상기 공개인증 서버로부터 상기 액세스토큰에 대응되는 병록 아이디를 수신하여, 수신된 병록 아이디의 정보제공 허용 범위 내에서 상기 병록 아이디의 의료기록을 전송하는 것을 특징으로 하는 제3자 중심의 공개인증 기반 의료기록 전송 시스템.
  3. 제1항 또는 제2항에 있어서,
    상기 의료기록 전송 시스템은 본인인증을 수행하는 본인인증 서버를 더 포함하고,
    상기 공개인증 서버는 상기 본인인증 서버에 본인인증을 요청하고, 상기 본인인증 서버에서 본인인증을 수행시 환자로부터 입력을 상기 제3자 서비스 앱의 사용자 인터페이스를 통해 입력받도록 하고, 상기 본인인증의 결과를 상기 본인인증 서버로부터 직접 전송받는 것을 특징으로 하는 제3자 중심의 공개인증 기반 의료기록 전송 시스템.
  4. 삭제
  5. 제1항 또는 제2항에 있어서,
    상기 액세스토큰은 만료기간이 설정되고, 상기 액세스토큰의 만료기간이 경과하면, 상기 리소스 서버는 상기 액세스토큰을 통한 의료기록 요청을 허용하지 않는 것을 특징으로 하는 제3자 중심의 공개인증 기반 의료기록 전송 시스템.
  6. 제1항 또는 제2항에 있어서,
    상기 리소스 서버는 상기 제3자 서비스 서버로 의료기록을 전송할 때 웹 상의 RESTful(REpresentational State Transfer) API(Application Program Interface)를 통해 전송하는 것을 특징으로 하는 제3자 중심의 공개인증 기반 의료기록 전송 시스템.
  7. 삭제
  8. 사용자 단말에 설치되는 제3자 서비스 앱, 상기 제3자 서비스 앱과 네트워크로 연결된 제3자 서비스 서버, 의료기관에서 운영하는 공개인증 서버, 본인인증을 수행하는 본인인증 서버, 의료기록을 저장하는 리소스 서버로 구성되는 의료기록 전송 시스템에 의해 수행되는, 제3자 중심의 공개인증 기반 의료기록 전송 방법에 있어서,
    (a) 상기 제3자 서비스 앱에서 상기 공개인증 서버의 공개된 프로토콜을 통해, 의료기록을 전송받기 위한 사용자 인증, 본인인증, 및 정보제공 동의를 요청하는 단계;
    (b) 상기 공개인증 서버는 사용자 인증을 수행하되, 상기 제3자 서비스 앱의 사용자 인터페이스를 통해 사용자 인증정보를 입력받는 단계;
    (d) 상기 사용자 인증이 성공하면, 상기 공개인증 서버는 본인인증을 상기 본인인증 서버로 요청하되, 상기 본인인증 서버가 상기 제3자 서비스 앱의 사용자 인터페이스를 통해 본인인증 정보를 입력받도록 하고, 상기 공개인증 서버가 상기 본인인증의 결과를 직접 수신하는 단계;
    (e) 상기 본인인증이 성공하면, 상기 공개인증 서버는 정보제공 동의를 수행하되, 상기 제3자 서비스 앱의 사용자 인터페이스를 통해 환자의 정보제공 동의를 입력받는 단계;
    (f) 상기 정보제공 동의가 성공하면, 상기 공개인증 서버는 환자의 의료기록의 전송을 허용하는 액세스토큰을 발급하여, 상기 제3자 서비스 앱에 전송하고, 상기 리소스 서버에 상기 액세스토큰에 의한 의료기록 전송의 허용 정보를 전송하는 단계; 및,
    (g) 상기 제3자 서비스 서버는 상기 제3자 서비스 앱으로부터 상기 액세스토큰을 수신하여 저장하고, 저장된 액세스토큰으로 상기 리소스 서버에 환자의 의료기록 전송을 요청하여 수신하는 단계를 포함하고,
    환자의 의료기록에 대한 정보제공 동의는 전송할 의료기록의 범위와, 해당 범위의 의료기록 전송을 허용하는 동의를 포함하고,
    상기 공개인증 서버는 사용자 계정의 사용자 아이디와, 병록 아이디를 서로 매핑하여 저장하되, 상기 병록 아이디는 환자의 의료기록에 대하여 환자의 식별번호로 이용되는 아이디이고,
    상기 리소스 서버는 환자의 병록 아이디 별로 정보제공 허용 범위를 저장하고,
    상기 리소스 서버는 액세스토큰으로 환자의 의료기록 전송 요청을 받으면, 상기 액세스토큰의 유효성 체크를 상기 공개인증 서버를 통해 처리하고, 상기 공개인증 서버로부터 상기 액세스토큰에 대응되는 병록 아이디를 수신하여, 수신된 병록 아이디의 정보제공 허용 범위 내에서 상기 병록 아이디의 의료기록을 전송하는 것을 특징으로 하는 제3자 중심의 공개인증 기반 의료기록 전송 방법.
  9. 사용자 단말에 설치되는 제3자 서비스 앱, 상기 제3자 서비스 앱과 네트워크로 연결된 제3자 서비스 서버, 의료기관에서 운영하는 공개인증 서버, 본인인증을 수행하는 본인인증 서버, 의료기록을 저장하는 리소스 서버로 구성되는 의료기록 전송 시스템에 의해 수행되는, 제3자 중심의 공개인증 기반 의료기록 전송 방법에 있어서,
    (a) 상기 제3자 서비스 앱에서 상기 공개인증 서버의 공개된 프로토콜을 통해, 사용자 계정에 대한 사용자 인증을 요청하는 단계;
    (b) 상기 공개인증 서버는 사용자 인증을 수행하되, 상기 제3자 서비스 앱의 사용자 인터페이스를 통해 사용자 인증정보를 입력받는 단계;
    (c) 상기 사용자 인증이 성공하면, 상기 공개인증 서버는 사용자 계정으로 접속을 허용하는 액세스토큰을 발급하여, 상기 제3자 서비스 앱에 전송하는 단계;
    (d) 상기 제3자 서비스 앱은 상기 액세스토큰을 통해 상기 공개인증 서버로 본인인증을 요청하면, 상기 공개인증 서버는 본인인증을 상기 본인인증 서버로 요청하되, 상기 본인인증 서버가 상기 제3자 서비스 앱의 사용자 인터페이스를 통해 본인인증 정보를 입력받도록 하고, 상기 공개인증 서버가 상기 본인인증의 결과를 직접 수신하는 단계;
    (e) 상기 본인인증이 성공하면, 상기 공개인증 서버는 정보제공 동의를 수행하되, 상기 제3자 서비스 앱의 사용자 인터페이스를 통해 환자의 정보제공 동의를 입력받는 단계;
    (f) 상기 정보제공 동의가 성공하면, 상기 공개인증 서버는 환자의 의료기록 전송 승인 결과을 상기 제3자 서비스 앱에 전송하고, 상기 리소스 서버에 상기 액세스토큰에 의한 의료기록 전송의 허용 정보를 전송하는 단계; 및,
    (g) 상기 제3자 서비스 서버는 상기 제3자 서비스 앱으로부터 상기 액세스토큰을 수신하여 저장하고, 저장된 액세스토큰으로 상기 리소스 서버에 환자의 의료기록 전송을 요청하여 수신하는 단계를 포함하고,
    환자의 의료기록에 대한 정보제공 동의는 전송할 의료기록의 범위와, 해당 범위의 의료기록 전송을 허용하는 동의를 포함하고,
    상기 공개인증 서버는 상기 사용자 계정의 사용자 아이디와, 병록 아이디를 서로 매핑하여 저장하되, 상기 병록 아이디는 환자의 의료기록에 대하여 환자의 식별번호로 이용되는 아이디이고,
    상기 리소스 서버는 환자의 병록 아이디 별로 정보제공 허용 범위를 저장하고,
    상기 리소스 서버는 액세스토큰으로 환자의 의료기록 전송 요청을 받으면, 상기 액세스토큰의 유효성 체크를 상기 공개인증 서버를 통해 처리하고, 상기 공개인증 서버로부터 상기 액세스토큰에 대응되는 병록 아이디를 수신하여, 수신된 병록 아이디의 정보제공 허용 범위 내에서 상기 병록 아이디의 의료기록을 전송하는 것을 특징으로 하는 제3자 중심의 공개인증 기반 의료기록 전송 방법.
  10. 제8항 또는 제9항에 있어서,
    환자의 의료기록에 대한 정보제공 동의는 전송할 의료기록의 범위와, 해당 범위의 의료기록 전송을 허용하는 동의를 포함하는 것을 특징으로 하는 제3자 중심의 공개인증 기반 의료기록 전송 방법.
  11. 제8항 또는 제9항에 있어서,
    상기 액세스토큰은 만료기간이 설정되고, 상기 액세스토큰의 만료기간이 경과하면, 상기 리소스 서버는 상기 액세스토큰을 통한 의료기록 요청을 허용하지 않는 것을 특징으로 하는 제3자 중심의 공개인증 기반 의료기록 전송 방법.
KR1020160065750A 2016-05-27 2016-05-27 제3자 중심의 공개인증 기반 의료기록 전송 시스템 및 방법 KR101708774B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020160065750A KR101708774B1 (ko) 2016-05-27 2016-05-27 제3자 중심의 공개인증 기반 의료기록 전송 시스템 및 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020160065750A KR101708774B1 (ko) 2016-05-27 2016-05-27 제3자 중심의 공개인증 기반 의료기록 전송 시스템 및 방법

Publications (1)

Publication Number Publication Date
KR101708774B1 true KR101708774B1 (ko) 2017-03-08

Family

ID=58404143

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020160065750A KR101708774B1 (ko) 2016-05-27 2016-05-27 제3자 중심의 공개인증 기반 의료기록 전송 시스템 및 방법

Country Status (1)

Country Link
KR (1) KR101708774B1 (ko)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20210027960A (ko) * 2019-09-03 2021-03-11 주식회사 아롬정보기술 블록체인을 이용한 의료데이터 서비스 관리 장치 및 이를 이용한 의료데이터 관리 방법
US11356450B2 (en) * 2018-04-24 2022-06-07 Arm Ip Limited Managing data access
KR20220081870A (ko) * 2020-12-09 2022-06-16 한국전자통신연구원 의료 데이터 접근 관리를 위한 장치 및 방법
KR20220144082A (ko) * 2021-04-19 2022-10-26 주식회사 에비드넷 이원적 상호 인증을 이용한 의료데이터 공유시스템
CN116192400A (zh) * 2023-01-31 2023-05-30 百洋智能科技集团股份有限公司 一种支持hccm服务的移动中台系统
KR102573773B1 (ko) * 2022-09-19 2023-09-04 주식회사 파이디지털헬스케어 개인정보 비식별 처리를 적용한 디지털 치료제 처방 데이터 교환 시스템 및 방법
KR102636838B1 (ko) * 2023-02-20 2024-02-16 주식회사 파이디지털헬스케어 연속 처방 및 다기관 연속 처방을 지원하는 디지털 치료제 플랫폼 시스템 및 디지털 치료제 제공 방법
KR102636860B1 (ko) * 2023-02-20 2024-02-16 주식회사 파이디지털헬스케어 일회성 코드를 활용한 디지털 치료제 App 인증/연동 시스템 및 방법
CN117155651B (zh) * 2023-08-31 2024-03-12 金锐软件技术(杭州)有限公司 一种优化第三方系统接入java网关的方法

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100696708B1 (ko) 2006-02-21 2007-03-20 재단법인서울대학교산학협력재단 의료기관간 의료정보 온라인 전송 시스템
KR20090001965A (ko) 2007-05-30 2009-01-09 서울대학교병원 Ｅｍｒ 시스템과 연계된 고객 건강검진정보 통합 운용 방법
KR20120093560A (ko) 2011-02-15 2012-08-23 김민준 의료정보 중계 방법
KR20120105992A (ko) * 2011-03-17 2012-09-26 (주)인성정보 스마트폰을 이용한 의료정보관리 네트워크 및 그 방법
KR20130001500A (ko) 2011-06-27 2013-01-04 유디비 주식회사 개인 건강 기록 관리 시스템 및 방법
KR20140060918A (ko) 2012-11-13 2014-05-21 가톨릭대학교 산학협력단 의료정보영상데이터 디스플레이시스템 및 그 제어방법
KR20150095255A (ko) * 2014-02-13 2015-08-21 주식회사 디지캡 신뢰 서비스 장치를 이용한 신뢰된 아이덴티티 관리 서비스 제공 시스템 및 그 운영방법

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100696708B1 (ko) 2006-02-21 2007-03-20 재단법인서울대학교산학협력재단 의료기관간 의료정보 온라인 전송 시스템
KR20090001965A (ko) 2007-05-30 2009-01-09 서울대학교병원 Ｅｍｒ 시스템과 연계된 고객 건강검진정보 통합 운용 방법
KR20120093560A (ko) 2011-02-15 2012-08-23 김민준 의료정보 중계 방법
KR20120105992A (ko) * 2011-03-17 2012-09-26 (주)인성정보 스마트폰을 이용한 의료정보관리 네트워크 및 그 방법
KR20130001500A (ko) 2011-06-27 2013-01-04 유디비 주식회사 개인 건강 기록 관리 시스템 및 방법
KR20140060918A (ko) 2012-11-13 2014-05-21 가톨릭대학교 산학협력단 의료정보영상데이터 디스플레이시스템 및 그 제어방법
KR20150095255A (ko) * 2014-02-13 2015-08-21 주식회사 디지캡 신뢰 서비스 장치를 이용한 신뢰된 아이덴티티 관리 서비스 제공 시스템 및 그 운영방법

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11356450B2 (en) * 2018-04-24 2022-06-07 Arm Ip Limited Managing data access
KR102275657B1 (ko) * 2019-09-03 2021-07-09 주식회사 아롬정보기술 블록체인을 이용한 의료데이터 서비스 관리 장치 및 이를 이용한 의료데이터 관리 방법
KR20210027960A (ko) * 2019-09-03 2021-03-11 주식회사 아롬정보기술 블록체인을 이용한 의료데이터 서비스 관리 장치 및 이를 이용한 의료데이터 관리 방법
KR102627705B1 (ko) * 2020-12-09 2024-01-23 한국전자통신연구원 의료 데이터 접근 관리를 위한 장치 및 방법
KR20220081870A (ko) * 2020-12-09 2022-06-16 한국전자통신연구원 의료 데이터 접근 관리를 위한 장치 및 방법
KR20220144082A (ko) * 2021-04-19 2022-10-26 주식회사 에비드넷 이원적 상호 인증을 이용한 의료데이터 공유시스템
KR102667744B1 (ko) * 2021-04-19 2024-05-21 주식회사 에비드넷 이원적 상호 인증을 이용한 의료데이터 공유시스템
KR102573773B1 (ko) * 2022-09-19 2023-09-04 주식회사 파이디지털헬스케어 개인정보 비식별 처리를 적용한 디지털 치료제 처방 데이터 교환 시스템 및 방법
CN116192400A (zh) * 2023-01-31 2023-05-30 百洋智能科技集团股份有限公司 一种支持hccm服务的移动中台系统
KR102636838B1 (ko) * 2023-02-20 2024-02-16 주식회사 파이디지털헬스케어 연속 처방 및 다기관 연속 처방을 지원하는 디지털 치료제 플랫폼 시스템 및 디지털 치료제 제공 방법
KR102636860B1 (ko) * 2023-02-20 2024-02-16 주식회사 파이디지털헬스케어 일회성 코드를 활용한 디지털 치료제 App 인증/연동 시스템 및 방법
WO2024177329A1 (ko) * 2023-02-20 2024-08-29 주식회사 파이디지털헬스케어 일회성 코드를 활용한 디지털 치료제 app 인증/연동 시스템 및 방법
CN117155651B (zh) * 2023-08-31 2024-03-12 金锐软件技术(杭州)有限公司 一种优化第三方系统接入java网关的方法

Similar Documents

Publication Publication Date Title
KR101708774B1 (ko) 제3자 중심의 공개인증 기반 의료기록 전송 시스템 및 방법
US8725536B2 (en) Establishing a patient-provider consent relationship for data sharing
US8990834B2 (en) Managing healthcare information in a distributed system
US10282799B2 (en) Simplified system for sharing medical information between institutions
US8024273B2 (en) Establishing patient consent on behalf of a third party
US20150379198A1 (en) Electronic management of patient health care data
US20070192140A1 (en) Systems and methods for extending an information standard through compatible online access
US10446274B2 (en) Open healthcare apparatus and method
US9479511B2 (en) Accessing multiple client domains using a single application
KR20170135332A (ko) 공인기관에 의한 의료기록 관리 및 전송 시스템 및 방법
US11343330B2 (en) Secure access to individual information
Ge et al. Patient-controlled sharing of medical imaging data across unaffiliated healthcare organizations
US8498884B2 (en) Encrypted portable electronic medical record system
US20220245270A1 (en) Personal Health Record System and Method using Patient Right of Access
KR102605710B1 (ko) 블록체인과 피케이아이기술을 이용한 개인의료기록 공유방법
US10902382B2 (en) Methods for remotely accessing electronic medical records without having prior authorization
US20200227150A1 (en) Automatic generation of patient presence for health-related data management systems
KR20180076910A (ko) 응급상황에서 제3자에 대한 응급의료 정보제공 방법
US20150100347A1 (en) Universal online healthcare marketplace
US20110054942A1 (en) System for and method of transmitting descriptive prescription between doctor and patient
US20240184915A1 (en) Secure global health information exchange
US20110313928A1 (en) Method and system for health information exchange between sources of health information and personal health record systems
KR102523227B1 (ko) 의료진 중심의 환자 관리를 위한 환자 포탈 시스템 및 이를 이용한 관리 방법
JP2019133224A (ja) 情報提供プログラム、情報処理装置及び情報提供方法
US20240202271A1 (en) Credential enabled reference for external resource access

Legal Events

Date Code Title Description
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20200210

Year of fee payment: 4