KR20210079076A - 스마트 진료 시스템 및 그 방법 - Google Patents

스마트 진료 시스템 및 그 방법 Download PDF

Info

Publication number
KR20210079076A
KR20210079076A KR1020190171184A KR20190171184A KR20210079076A KR 20210079076 A KR20210079076 A KR 20210079076A KR 1020190171184 A KR1020190171184 A KR 1020190171184A KR 20190171184 A KR20190171184 A KR 20190171184A KR 20210079076 A KR20210079076 A KR 20210079076A
Authority
KR
South Korea
Prior art keywords
information
management server
hospital
hospital management
terminal device
Prior art date
Application number
KR1020190171184A
Other languages
English (en)
Other versions
KR102312830B1 (ko
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 KR1020190171184A priority Critical patent/KR102312830B1/ko
Priority to JP2022538458A priority patent/JP7340702B2/ja
Priority to US17/787,589 priority patent/US20220415490A1/en
Priority to PCT/KR2020/018232 priority patent/WO2021125719A1/ko
Publication of KR20210079076A publication Critical patent/KR20210079076A/ko
Priority to KR1020210133168A priority patent/KR20210125966A/ko
Application granted granted Critical
Publication of KR102312830B1 publication Critical patent/KR102312830B1/ko

Links

Images

Classifications

    • 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
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/20—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0484—Interaction techniques based on graphical user interfaces [GUI] for the control of specific functions or operations, e.g. selecting or manipulating an object, an image or a displayed text element, setting a parameter value or selecting a range
    • 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
    • G16H20/00—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
    • 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
    • G16H20/00—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
    • G16H20/10—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients
    • 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
    • G16H80/00—ICT specially adapted for facilitating communication between medical practitioners or patients, e.g. for collaborative diagnosis, therapy or health monitoring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/023—Services making use of location information using mutual or relative location information between multiple location based services [LBS] targets or of distance thresholds
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/025—Services making use of location information using location based information parameters

Landscapes

  • Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Business, Economics & Management (AREA)
  • Epidemiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Public Health (AREA)
  • General Business, Economics & Management (AREA)
  • Biomedical Technology (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Tourism & Hospitality (AREA)
  • Pathology (AREA)
  • Human Computer Interaction (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Strategic Management (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Human Resources & Organizations (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Chemical & Material Sciences (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Medicinal Chemistry (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

단말 장치에 동작을 실행시키는 컴퓨터로 읽을 수 있는 매체에 저장된 애플리케이션이 개시된다. 본 애플리케이션에서 수행되는 동작은 증상 정보를 입력 받기 위한 UI 화면을 제공하는 단계, UI 화면을 통해 사용자의 증상 정보가 입력되면, 증상 정보 및 대기 번호 요청을 병원 관리 서버로 전송하는 단계, 병원 관리 서버로부터 대기 번호 요청에 대응되는 대기 번호를 수신할 수 있고, 수신된 대기 번호를 포함하는 UI 화면을 제공하는 단계, 사용자의 식별 정보를 애플리케이션 서버로 전송하는 단계 및 애플리케이션 서버가 사용자의 식별 정보를 병원 관리 서버로 전송하도록 제어하는 단계를 포함한다.

Description

스마트 진료 시스템 및 그 방법 {SMART MEDICAL TREATMENT SYSTEM AND METHOD THEREOF}
본 개시는 스마트 진료 시스템 및 그 방법에 관한 것으로, 더욱 상세하게는 개인 식별 정보와 개인 증상 정보를 구분하여 관리하는 스마트 진료 시스템 및 그 방법에 관한 것이다.
환자가 병원을 방문하여 대기하는 시간이 길어 질 수 있다. 대기 시간이 길어지는 이유는 하나의 병원에 환자에 대한 진료 시간이 길어지거나 방문 환자가 많아지기 때문일 수 있다.
대기 시간을 줄이려면 다수의 환자와 담당 의사의 진료 시간을 단축시킬 필요성이 있다. 환자와 담당 의사의 진료 시간을 단축시키기 위해선 환자에게 반복적으로 물어보는 정보들을 미리 수집하는 것이 도움이 될 수 있다. 구체적으로, 담당 의사 또는 병원은 환자가 병원을 방문한 이유가 무엇인지 구체적으로 어떤 증상으로 병원을 방문 하였는지에 대한 정보를 미리 수집하여 진료 시간을 단축시킬 수 있다. 여기서, 효과적인 병원 운영 및 환자의 접근 편의성을 위하여 스마트 진료 시스템이 이용될 수 있으며, 스마트 진료 시스템의 운영을 위해 환자에게 애플리케이션을 통해 병원의 다양한 서비스를 제공할 수 있다. 구체적으로, 병원은 애플리케이션을 통해 환자에 대한 개인 정보를 요청할 수 있다. 하지만, 애플리케이션을 통해 환자의 개인 정보를 수집하는 경우, 환자의 개인 정보가 애플리케이션 서버를 통해 유출될 가능성이 높을 수 있다. 환자들은 개인 정보를 애플리케이션을 통해 기입하는 것을 꺼려할 수 있으며 병원은 개인 정보 유출에 대한 책임 문제 때문에 개인 정보(예를 들어, 증상 정보)를 받는 것을 기피하는 문제점이 있을 수 있다. 또한, 처방에 대한 정보를 환자에게 제공하는 경우에도, 개인 정보가 유출될 가능성이 있어, 환자 및 병원 모두 처방 정보를 제공하는 것을 기피하는 문제점이 있을 수 있다.
한편, 병원에 방문 환자가 많아지는 경우 예약 시스템을 도입하여 환자의 방문 시간을 분산시킬 수 있다. 하지만, 예약 확정 후 예정 시간에 방문하지 않는 환자들이 발생하는 경우가 있을 수 있다. 예정된 예약 시간에 방문하지 않는 노쇼(No-Show)환자들이 많아지는 경우 또는 예약 없이 당일에 접수하는 환자들이 있는 경우, 병원은 접수 또는 진료 순서를 결정함에 있어 복잡성이 증가할 수 있다. 따라서, 병원은 예정된 시간에 환자들이 방문할 것인지를 판단하는 것이 환자들의 대기 시간을 줄이는데 중요한 역할을 할 수 있다. 예정된 시간에 환자들이 정상적으로 방문할 것인지를 예약 시간 이전에 전화로 직접 물어보는 경우, 전화 업무를 담당하는 직업의 업무가 늘어날 수 있으며, 인건비가 증가하는 원인이 될 수 있다. 따라서, 스마트 진료 시스템에서 예약 기능을 제공하는 경우, 예약 환자들이 실제로 병원에 내원할 것인지 정확히 판단하는 것이 효율적인 진료 시스템을 관리하는데 도움이 될 수 있다.
본 개시는 상술한 문제를 개선하기 위해 고안된 것으로, 본 개시의 목적은 개인 식별 정보와 개인 증상 정보를 구분하여 별도의 장치에 전송하고, 진료 순서를 결정함에 있어 복잡성 문제를 해결하기 위하여 예약 환자들의 실제 병원 방문 여부를 판단하는 애플리케이션 및 그 애플리케이션을 포함하는 단말 장치를 제공함에 있다.
상술한 목적을 달성하기 위한 본 실시 예에 따른 단말 장치에 동작을 실행시키는 컴퓨터로 읽을 수 있는 매체에 저장된 애플리케이션에 있어서, 상기 동작은 증상 정보를 입력 받기 위한 UI 화면을 제공하는 단계, 상기 UI 화면을 통해 사용자의 증상 정보가 입력되면, 상기 증상 정보 및 대기 번호 요청을 병원 관리 서버로 전송하는 단계, 상기 병원 관리 서버로부터 상기 대기 번호 요청에 대응되는 대기 번호를 수신할 수 있고, 수신된 대기 번호를 포함하는 UI 화면을 제공하는 단계, 상기 사용자의 식별 정보를 애플리케이션 서버로 전송하는 단계 및 상기 애플리케이션 서버가 상기 사용자의 식별 정보를 상기 병원 관리 서버로 전송하도록 제어하는 단계를 포함한다.
여기서, 상기 병원 관리 서버로 전송된 상기 증상 정보를 포함하는 제1 UI 화면 및 상기 사용자의 식별 정보를 포함하는 제2 UI 화면이 상기 병원 관리 서버와 통신하는 디스플레이 장치에 제공될 수 있다.
또한, 상기 동작은 병원 예약을 위한 UI 화면을 제공하는 단계, 상기 UI 화면을 통해 병원 예약을 위한 정보가 입력되면, 상기 사용자의 식별 정보 및 상기 병원 예약을 위한 정보를 상기 애플리케이션 서버로 전송하는 단계 및 상기 애플리케이션 서버로부터 병원 예약 정보가 수신되면, 상기 수신된 병원 예약 정보를 포함하는 UI 화면을 제공하는 단계를 더 포함할 수 있고, 상기 예약 정보는 예약 시간을 포함할 수 있다.
여기서, 상기 동작은 상기 예약 시간으로부터 임계 시간 이전 시점부터 상기 단말 장치의 위치 정보를 상기 병원 관리 서버로 전송하는 단계 및 상기 병원 관리 서버로부터 상기 위치 정보에 대응되는 대기 번호를 수신하면, 수신된 대기 번호를 포함하는 UI 화면을 제공하는 단계를 더 포함할 수 있다.
여기서, 상기 병원 관리 서버는 상기 위치 정보가 상기 병원의 위치로부터 임계 거리 내이면, 순위가 높은 대기 번호를 상기 단말 장치로 제공할 수 있다.
또한, 상기 동작은 상기 수신된 대기 번호를 상기 애플리케이션 서버에 전송하는 단계 및 상기 애플리케이션 서버가 상기 대기 번호를 상기 병원 관리 서버로 전송하도록 제어하는 단계를 더 포함할 수 있고, 상기 병원 관리 서버로 전송된 상기 증상 정보 및 상기 대기 번호를 포함하는 제1 UI 화면 및 상기 사용자의 식별 정보 및 상기 대기 번호를 포함하는 제2 UI 화면이 상기 병원 관리 서버와 통신하는 디스플레이 장치에 제공될 수 있다.
또한, 상기 동작은 상기 병원 관리 서버로부터 처방 정보를 수신하는 단계 및 상기 수신된 처방 정보를 포함하는 UI 화면을 제공하는 단계를 더 포함할 수 있고, 상기 병원 관리 서버는 상기 대기 번호에 기초하여 상기 처방 정보를 전송할 단말 장치를 식별할 수 있고, 상기 식별된 단말 장치로 상기 처방 정보를 전송할 수 있다.
한편, 상기 병원 관리 서버는 제1 병원 관리 서버 및 제2 병원 관리 서버를 포함할 수 있고, 상기 증상 정보 및 상기 대기 번호 요청은 상기 제1 병원 관리 서버로 전송될 수 있으며, 상기 사용자의 식별 정보는 상기 제2 병원 관리 서버로 전송될 수 있다.
또한, 상기 증상 정보는 제1 통신 모듈을 통해 상기 병원 관리 서버로 전송될 수 있고, 상기 사용자의 식별 정보는 제2 통신 모듈을 통해 상기 병원 관리 서버로 전송될 수 있다.
여기서, 상기 동작은 상기 병원 관리 서버로부터 처방 정보를 수신하는 단계 및 상기 수신된 처방 정보를 포함하는 UI 화면을 제공하는 단계를 포함할 수 있고, 상기 처방 정보는 상기 제1 통신 모듈을 통해 상기 병원 관리 서버로부터 수신될 수 있다.
한편, 본 개시의 일 실시 예에 따른 단말 장치는 애플리케이션을 저장하는 메모리, 디스플레이, 통신 인터페이스, 상기 애플리케이션을 실행하여 동작을 수행하는 프로세서를 포함하고, 상기 동작은 증상 정보를 입력 받기 위한 UI 화면을 상기 디스플레이에 표시하는 단계, 상기 UI 화면을 통해 사용자의 증상 정보가 입력되면, 상기 증상 정보 및 대기 번호 요청을 병원 관리 서버로 전송하는 단계, 상기 병원 관리 서버로부터 상기 대기 번호 요청에 대응되는 대기 번호를 수신할 수 있고, 수신된 대기 번호를 포함하는 UI 화면을 상기 디스플레이에 표시하는 단계, 상기 사용자의 식별 정보를 애플리케이션 서버로 전송하는 단계 및 상기 애플리케이션 서버가 상기 사용자의 식별 정보를 상기 병원 관리 서버로 전송하도록 제어하는 단계를 포함할 수 있다.
여기서, 상기 프로세서는 상기 병원 관리 서버로 전송된 상기 증상 정보를 포함하는 제1 UI 화면 및 상기 사용자의 식별 정보를 포함하는 제2 UI 화면을 상기 병원 관리 서버와 통신하는 디스플레이 장치에 제공할 수 있다.
또한, 상기 프로세서는 상기 UI 화면을 통해 병원 예약을 위한 정보가 입력되면, 상기 사용자의 식별 정보 및 상기 병원 예약을 위한 정보를 상기 애플리케이션 서버로 전송할 수 있고, 상기 애플리케이션 서버로부터 병원 예약 정보가 수신되면, 상기 수신된 병원 예약 정보를 포함하는 UI 화면을 상기 디스플레이에 표시할 수 있고, 상기 예약 정보는 예약 시간을 포함할 수 있다.
여기서, 상기 프로세서는 상기 예약 시간으로부터 임계 시간 이전 시점부터 상기 단말 장치의 위치 정보를 상기 병원 관리 서버로 전송할 수 있고, 상기 병원 관리 서버로부터 상기 위치 정보에 대응되는 대기 번호를 수신하면, 수신된 대기 번호를 포함하는 UI 화면을 상기 디스플레이에 표시할 수 있다.
여기서, 상기 병원 관리 서버는 상기 위치 정보가 상기 병원의 위치로부터 임계 거리 내이면, 순위가 높은 대기 번호를 상기 단말 장치로 제공할 수 있다.
또한, 상기 프로세서는 상기 수신된 대기 번호를 상기 통신 인터페이스를 통해 상기 애플리케이션 서버에 전송할 수 있고, 상기 애플리케이션 서버가 상기 대기 번호를 상기 병원 관리 서버로 전송하도록 제어할 수 있고, 상기 병원 관리 서버로 전송된 상기 증상 정보 및 상기 대기 번호를 포함하는 제1 UI 화면 및 상기 사용자의 식별 정보 및 상기 대기 번호를 포함하는 제2 UI 화면이 상기 병원 관리 서버와 통신하는 디스플레이 장치에 제공될 수 있다.
또한, 상기 프로세서는 상기 병원 관리 서버로부터 처방 정보를 수신할 수 있고, 상기 수신된 처방 정보를 포함하는 UI 화면을 상기 디스플레이에 표시할 수 있고, 상기 병원 관리 서버는 상기 대기 번호에 기초하여 상기 처방 정보를 전송할 단말 장치를 식별할 수 있고, 상기 식별된 단말 장치로 상기 처방 정보를 전송할 수 있다.
또한, 상기 병원 관리 서버는 제1 병원 관리 서버 및 제2 병원 관리 서버를 포함할 수 있고, 상기 증상 정보 및 상기 대기 번호 요청은 상기 제1 병원 관리 서버로 전송될 수 있으며, 상기 사용자의 식별 정보는 상기 제2 병원 관리 서버로 전송될 수 있다.
여기서, 상기 증상 정보는 제1 통신 모듈을 통해 상기 병원 관리 서버로 전송될 수 있고, 상기 사용자의 식별 정보는 제2 통신 모듈을 통해 상기 병원 관리 서버로 전송될 수 있다.
여기서, 상기 프로세서는 상기 병원 관리 서버로부터 처방 정보를 수신할 수 있고, 상기 수신된 처방 정보를 포함하는 UI 화면을 상기 디스플레이에 표시할 수 있고, 상기 처방 정보는 상기 제1 통신 모듈을 통해 상기 병원 관리 서버로부터 수신될 수 있다.
도 1은 본 개시의 일 실시 예에 따른 사용자 단말 장치를 도시한 블록도이다.
도 2는 도 1의 사용자 단말 장치의 구체적인 구성을 설명하기 위한 블록도이다.
도 3은 일 실시 예에 따른 환자 진료 시스템의 구성을 설명하기 위한 도면이다.
도 4는 도3의 실시 예를 설명하기 위한 흐름도이다.
도 5는 다른 실시 예에 따른 환자 진료 시스템의 구성을 설명하기 위한 도면이다.
도 6은 도5의 실시 예를 설명하기 위한 흐름도이다.
도 7은 또 다른 실시 예에 따른 환자 진료 시스템의 구성을 설명하기 위한 도면이다.
도 8은 도7의 실시 예를 설명하기 위한 흐름도이다.
도 9는 병원에서 환자를 관리하는 복수의 단계를 설명하기 위한 흐름도이다.
도 10은 환자를 관리하는 복수의 단계 중 일 실시 예에 따른 예약 단계를 설명하기 위한 흐름도이다.
도 11은 과거 이력 정보를 이용하여 예약 단계를 수행하는 실시 예를 설명하기 위한 도면이다.
도 12는 도 11의 실시 예에 따른 UI를 설명하기 위한 도면이다.
도 13은 환자를 관리하는 복수의 단계 중 다른 실시 예에 따른 예약 단계를 설명하기 위한 흐름도이다.
도 14는 도 13의 실시 예에 따른 UI를 설명하기 위한 도면이다.
도 15는 환자를 관리하는 복수의 단계 중 접수 단계를 설명하기 위한 흐름도이다.
도 16은 위치 정보를 이용하여 대기 번호를 전송하는 실시 예를 설명하기 위한 도면이다.
도 17은 도 16의 실시 예의 구체적인 방법을 설명하기 위한 흐름도이다.
도 18은 순서 알림 정보를 전송하는 일 실시 예를 설명하기 위한 흐름도이다.
도 19는 순서 알림 정보를 전송하는 다른 실시 예를 설명하기 위한 흐름도이다.
도 20은 환자를 관리하는 복수의 단계 중 진료 단계를 설명하기 위한 흐름도이다.
도 21은 환자 정보와 대기자 정보를 맵핑하는 일 실시 예를 설명하기 위한 도면이다.
도 22는 도 21의 실시 예에서 전송되는 정보를 구체적으로 설명하기 위한 도면이다.
도 23은 환자 정보와 대기자 정보를 맵핑하는 다른 실시 예를 설명하기 위한 도면이다.
도 24는 환자 정보와 대기자 정보를 맵핑하는 또 다른 실시 예를 설명하기 위한 도면이다.
도 25는 증상 정보를 동기화하는 일 실시 예를 설명하기 위한 도면이다.
도 26은 증상 정보를 동기화하는 다른 실시 예를 설명하기 위한 도면이다.
도 27은 환자를 관리하는 복수의 단계 중 처방 단계를 설명하기 위한 흐름도이다.
도 28은 처방 정보를 전송하는 단계를 설명하기 위한 도면이다.
도 29는 처방 정보를 동기화하는 일 실시 예를 설명하기 위한 도면이다.
도 30은 증상 정보 및 처방 정보를 동기화하는 실시 예를 설명하기 위한 도면이다.
도 31은 일 실시 예에 따른 사용자 단말 장치의 제어 방법을 설명하기 위한 흐름도이다.
이하에서는 첨부 도면을 참조하여 본 개시를 상세히 설명한다.
본 개시의 실시 예에서 사용되는 용어는 본 개시에서의 기능을 고려하면서 가능한 현재 널리 사용되는 일반적인 용어들을 선택하였으나, 이는 당 분야에 종사하는 기술자의 의도 또는 판례, 새로운 기술의 출현 등에 따라 달라질 수 있다. 또한, 특정한 경우는 출원인이 임의로 선정한 용어도 있으며, 이 경우 해당되는 개시의 설명 부분에서 상세히 그 의미를 기재할 것이다. 따라서 본 개시에서 사용되는 용어는 단순한 용어의 명칭이 아닌, 그 용어가 가지는 의미와 본 개시의 전반에 걸친 내용을 토대로 정의되어야 한다.
본 명세서에서, "가진다," "가질 수 있다," "포함한다," 또는 "포함할 수 있다" 등의 표현은 해당 특징(예: 수치, 기능, 동작, 또는 부품 등의 구성요소)의 존재를 가리키며, 추가적인 특징의 존재를 배제하지 않는다.
A 또는/및 B 중 적어도 하나라는 표현은 "A" 또는 "B" 또는 "A 및 B" 중 어느 하나를 나타내는 것으로 이해되어야 한다.
본 명세서에서 사용된 "제1," "제2," "첫째," 또는 "둘째,"등의 표현들은 다양한 구성요소들을, 순서 및/또는 중요도에 상관없이 수식할 수 있고, 한 구성요소를 다른 구성요소와 구분하기 위해 사용될 뿐 해당 구성요소들을 한정하지 않는다.
어떤 구성요소(예: 제1 구성요소)가 다른 구성요소(예: 제2 구성요소)에 "(기능적으로 또는 통신적으로) 연결되어((operatively or communicatively) coupled with/to)" 있다거나 "접속되어(connected to)" 있다고 언급된 때에는, 어떤 구성요소가 다른 구성요소에 직접적으로 연결되거나, 다른 구성요소(예: 제3 구성요소)를 통하여 연결될 수 있다고 이해되어야 할 것이다.
단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 출원에서, "포함하다" 또는 "구성되다" 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.
본 개시에서 "모듈" 혹은 "부"는 적어도 하나의 기능이나 동작을 수행하며, 하드웨어 또는 소프트웨어로 구현되거나 하드웨어와 소프트웨어의 결합으로 구현될 수 있다. 또한, 복수의 "모듈" 혹은 복수의 "부"는 특정한 하드웨어로 구현될 필요가 있는 "모듈" 혹은 "부"를 제외하고는 적어도 하나의 모듈로 일체화되어 적어도 하나의 프로세서(미도시)로 구현될 수 있다.
본 명세서에서, 사용자라는 용어는 전자 장치를 사용하는 사람 또는 전자 장치를 사용하는 장치(예: 인공지능 전자 장치)를 지칭할 수 있다.
이하 첨부된 도면들을 참조하여 본 개시의 일 실시 예를 보다 상세하게 설명한다.
도 1은 본 개시의 일 실시 예에 따른 사용자 단말 장치를 도시한 블록도이다.
도1을 참조하면, 사용자 단말 장치(100)는 메모리(110), 통신 인터페이스(120), 디스플레이(130) 및 프로세서(140)로 구성될 수 있다.
메모리(110)는 프로세서(140)에 포함된 롬(ROM)(예를 들어, EEPROM(electrically erasable programmable read-only memory)), 램(RAM) 등의 내부 메모리로 구현되거나, 프로세서(140)와 별도의 메모리로 구현될 수도 있다. 이 경우, 메모리(110)는 데이터 저장 용도에 따라 사용자 단말 장치(100)에 임베디드된 메모리 형태로 구현되거나, 사용자 단말 장치(100)에 탈부착이 가능한 메모리 형태로 구현될 수도 있다. 예를 들어, 사용자 단말 장치(100)의 구동을 위한 데이터의 경우 사용자 단말 장치(100)에 임베디드된 메모리에 저장되고, 사용자 단말 장치(100)의 확장 기능을 위한 데이터의 경우 사용자 단말 장치(100)에 탈부착이 가능한 메모리에 저장될 수 있다.
메모리(110)는 스마트 진료 시스템에 이용되는 애플리케이션을 저장할 수 있다. 메모리(110)에 저장된 애플리케이션은 병원 예약 기능을 사용자에게 제공할 수 있다. 메모리(110)에 저장된 애플리케이션은 기 설정된 주기로 업데이트 될 수 있으며, 애플리케이션은 프로세서(140)를 이용하여 다양한 기능을 사용자에게 제공할 수 있다.
통신 인터페이스(120)는 다양한 유형의 통신 방식에 따라 다양한 유형의 외부 장치와 통신을 수행하는 구성이다. 통신 인터페이스(120)는 와이파이 모듈, 블루투스 모듈, 적외선 통신 모듈 및 무선 통신 모듈 등을 포함한다. 여기서, 각 통신 모듈은 적어도 하나의 하드웨어 칩 형태로 구현될 수 있다.
와이파이 모듈, 블루투스 모듈은 각각 WiFi 방식, 블루투스 방식으로 통신을 수행한다. 와이파이 모듈이나 블루투스 모듈을 이용하는 경우에는SSID 및 세션 키 등과 같은 각종 연결 정보를 먼저 송수신하여, 이를 이용하여 통신 연결한 후 각종 정보들을 송수신할 수 있다.
적외선 통신 모듈은 시 광선과 밀리미터파 사이에 있는 적외선을 이용하여 근거리에 무선으로 데이터를 전송하는 적외선 통신(IrDA, infrared Data Association)기술에 따라 통신을 수행한다.
무선 통신 모듈은 상술한 통신 방5식 이외에 지그비(zigbee), 3G(3rd Generation), 3GPP(3rd Generation Partnership Project), LTE(Long Term Evolution), LTE-A(LTE Advanced), 4G(4th Generation), 5G(5th Generation)등과 같은 다양한 무선 통신 규격에 따라 통신을 수행하는 적어도 하나의 통신 칩을 포함할 수 있다.
그 밖에 통신 인터페이스(120)는LAN(Local Area Network) 모듈, 이더넷 모듈, 또는 페어 케이블, 동축 케이블 또는 광섬유 케이블 등을 이용하여 통신을 수행하는 유선 통신 모듈 중 적어도 하나를 포함할 수 있다.
일 예에 따라 통신 인터페이스(120)는 리모컨과 같은 외부 장치 및 외부 서버와 통신하기 위해 동일한 통신 모듈(예를 들어, Wi-Fi 모듈)을 이용할 수 있다.
다른 예에 따라 통신 인터페이스(120)는 리모컨과 같은 외부 장치 및 외부 서버와 통신하기 위해 상이한 통신 모듈(예를 들어, Wi-Fi 모듈)을 이용할 수 있다. 예를 들어, 통신 인터페이스(120)는 외부 서버와 통신하기 위해 이더넷 모듈 또는 WiFi 모듈 중 적어도 하나를 이용할 수 있고, 리모컨과 같은 외부 장치와 통신하기 위해 BT 모듈을 이용할 수도 있다. 다만 이는 일 실시 예에 불과하며 통신 인터페이스(120)는 복수의 외부 장치 또는 외부 서버와 통신하는 경우 다양한 통신 모듈 중 적어도 하나의 통신 모듈을 이용할 수 있다.
디스플레이(130)는 LCD(Liquid Crystal Display), OLED(Organic Light Emitting Diodes) 디스플레이, PDP(Plasma Display Panel) 등과 같은 다양한 형태의 디스플레이로 구현될 수 있다. 디스플레이(130)내에는 a-si TFT, LTPS(low temperature poly silicon) TFT, OTFT(organic TFT) 등과 같은 형태로 구현될 수 있는 구동 회로, 백라이트 유닛 등도 함께 포함될 수 있다. 한편, 디스플레이(130)는 터치 센서와 결합된 터치 스크린, 플렉시블 디스플레이(flexible display), 3차원 디스플레이(3D display) 등으로 구현될 수 있다.
또한, 본 개시의 일 실시 예에 따른, 디스플레이(130)는 영상을 출력하는 디스플레이 패널뿐만 아니라, 디스플레이 패널을 하우징하는 베젤을 포함할 수 있다. 특히, 본 개시의 일 실시 예에 따른, 베젤은 사용자 인터렉션을 감지하기 위한 터치 센서(미도시)를 포함할 수 있다.
프로세서(140)는 단말 장치의 전반적인 제어 동작을 수행할 수 있다. 구체적으로, 프로세서(140)는 단말 장치의 전반적인 동작을 제어하는 기능을 한다.
프로세서(140)는 디지털 신호를 처리하는 디지털 시그널 프로세서(digital signal processor(DSP), 마이크로 프로세서(microprocessor), TCON(Time controller)으로 구현될 수 있다. 다만, 이에 한정되는 것은 아니며, 중앙처리장치(central processing unit(CPU)), MCU(Micro Controller Unit), MPU(micro processing unit), 컨트롤러(controller), 어플리케이션 프로세서(application processor(AP)), GPU(graphics-processing unit) 또는 커뮤니케이션 프로세서(communication processor(CP)), ARM 프로세서 중 하나 또는 그 이상을 포함하거나, 해당 용어로 정의될 수 있다. 또한, 프로세서(140)는 프로세싱 알고리즘이 내장된 SoC(System on Chip), LSI(large scale integration)로 구현될 수도 있고, FPGA(Field Programmable gate array) 형태로 구현될 수도 있다. 또한, 프로세서(140)는 메모리(110)에 저장된 컴퓨터 실행가능 명령어(computer executable instructions)를 실행함으로써 다양한 기능을 수행할 수 있다.
사용자 단말 장치(100)는 애플리케이션을 실행하여 동작을 수행하는 프로세서(140)를 포함할 수 있다.
구체적으로, 프로세서(140)는 증상 정보를 입력 받기 위한 UI 화면을 디스플레이(130)에 표시할 수 있다. 여기서, 증상 정보는 사용자 단말 장치(100)를 이용하는 환자의 증상과 관련된 정보를 의미할 수 있다. 예를 들어, 증상 정보는 신체 부위(왼팔 손목) 및 통증 종류(저림)를 포함할 수 있다. 또한, 증상 정보는 디스플레이(130)에 표시된 UI 화면에 기초하여 사용자에 의해 입력될 수 있다. 여기서, 사용자는 환자를 의미할 수 있다. 증상 정보는 사용자 단말 장치(100)의 사용자 인터페이스(150)를 통해 입력될 수 있다. 한편, 프로세서(140)가 증상 정보를 입력 받기 위한 UI 화면을 언제 표시하는지는 대해서 다양한 조건이 있을 수 있다. 일 예로, 프로세서(140)는 애플리케이션 서버(200)로부터 예약 정보를 전송 받으면 증상 정보를 입력 받기 위한 UI 화면을 디스플레이(130)에 표시할 수 있다. 다른 예로, 프로세서(140)는 애플리케이션이 사용자에 의해 실행되면 증상 정보를 입력 받기 위한 UI 화면을 디스플레이(130)에 표시할 수 있다. 한편, 이외에 다양한 기 설정된 이벤트에 기초하여 프로세서(140)는 증상 정보를 입력 받기 위한 UI 화면을 디스플레이(130)에 표시할 수 있다.
또한, 프로세서(140)는 UI 화면을 통해 사용자의 증상 정보가 입력되면, 증상 정보 및 대기 번호 요청을 병원 관리 서버(300)로 전송할 수 있다. 대기 번호 요청이란 환자가 병원에 담당 의사에게 진찰을 받기 위하여 접수 순서를 부여 받기 위해 요청하는 것을 의미할 수 있다. 접수 순서는 환자가 실제로 대기 번호를 부여 받는 순서를 의미할 수 있으며, 진료 순서는 환자가 실제로 진료를 받는 순서를 의미할 수 있다. 접수 순서와 진료 순서가 일반적으로 동일하지만, 경우에 따라 접수 순서와 진료 순서가 상이할 수 있다.
병원 관리 서버(300)는 사용자 단말 장치(100)로부터 대기 번호 요청을 수신하면 대기 번호를 사용자 단말 장치(100)에 할당하고 할당된 대기 번호를 사용자 단말 장치(100)에 다시 전송할 수 있다. 그리고, 병원 관리 서버(300)는 대기 번호 요청을 전송한 사용자 단말 장치(100)와 대기 번호를 맵핑하여 기기 정보로서 병원 관리 서버(300)의 메모리에 저장할 수 있다. 즉, 병원 관리 서버(300)는 특정 대기 번호에 대응되는 단말 장치를 맵핑하여 저장하고 있을 수 있다. 특히, 병원 관리 서버(300)는 대기 번호와 사용자 단말 장치(100)를 맵핑하는 경우, 대기 번호와 사용자 단말 장치(100)의 증상 정보를 맵핑할 수 있다. 병원 관리 서버(300)는 증상 정보를 특정 환자에 대한 정보로 저장하지 않고 대기 번호에 대응되는 증상 정보로 저장할 수 있다. 증상 정보를 대기 번호와 맵핑(그룹핑)하여 저장하는 이유는 증상 정보가 어느 환자에 대한 것인지 정확히 저장하지 않기 위함이다. 증상 정보가 어느 환자에 대한 것인지 저장하지 않음으로써 개인 정보 유출에 대비할 수 있기 때문이다. 그리고, 증상 정보가 누구의 것인지는 현 의료에서 진료 행위와 같이 담당 의사의 확인이 있은 후 환자 정보에 저장될 수 있다. 이와 관련한 구체적인 동작은 후술한다.
또한, 프로세서(140)는 병원 관리 서버(300)로부터 대기 번호 요청에 대응되는 대기 번호를 수신할 수 있고, 수신된 대기 번호를 포함하는 UI 화면을 디스플레이(130)에 표시할 수 있다. 사용자는 디스플레이(130)에 표시된 대기 번호에 기초하여 자신의 진료 순서를 판단할 수 있다. 한편, 프로세서(140)는 디스플레이(130)에 대기 번호 이외에 추가적으로 날짜 정보, 주민 번호, 대기 인원, 대기 장소, 대기 예상 시간 중 적어도 하나를 더 표시할 수 있다.
또한, 프로세서(140)는 사용자의 식별 정보를 애플리케이션 서버(200)로 전송할 수 있다. 식별 정보는 사용자를 특정할 수 있는 정보를 의미할 수 있다. 예를 들어, 식별 정보는 이름, 생년월일, 애플리케이션 가입 ID, 의료 보험 번호, 여권 번호 등 병원에서 저장된 환자 번호 중 적어도 하나를 포함할 수 있다. 한편, 프로세서(140)는 증상 정보를 제외하고 식별 정보만을 애플리케이션 서버(200)로 전송할 수 있다. 또한, 프로세서(140)는 애플리케이션 서버(200)가 사용자의 식별 정보를 병원 관리 서버(300)로 전송하도록 제어하는 제어 명령을 생성할 수 있다. 프로세서(140)는 상술한 제어 명령과 식별 정보를 애플리케이션 서버(200)에 전송할 수 있다. 프로세서(140)는 식별 정보 및 증상 정보를 구분하여 관리할 수 있다. 구체적으로, 프로세서(140)는 식별 정보를 애플리케이션 서버(200)에 전송하고 증상 정보를 병원 관리 서버(300)에 직접 전송할 수 있다. 결과적으로, 식별 정보 및 증상 정보 모두가 병원 관리 서버(300)에 전송되지만 증상 정보는 애플리케이션 서버(200)를 거치지 않을 수 있다. 따라서, 애플리케이션 서버(200)이 해킹 당하는 경우에도 증상 정보는 유출되지 않을 수 있다.
여기서, 병원 관리 서버(300)로 전송된 증상 정보를 포함하는 제1 UI 화면 및 사용자의 식별 정보를 포함하는 제2 UI 화면을 병원 관리 서버(300)와 통신하는 디스플레이 장치(600, 도24 참조)에 제공 될 수 있다.
병원 관리 서버(300)는 사용자 단말 장치(100)로부터 증상 정보를 수신할 수 있다. 그리고, 병원 관리 서버(300)는 식별 정보를 애플리케이션 서버(200)로부터 수신할 수 있다. 그리고, 병원 관리 서버(300)는 증상 정보를 포함하는 제1 UI 화면을 생성하고, 생성된 제1 UI화면에 대응되는 정보를 디스플레이 장치(600)에 전송할 수 있다. 또한, 병원 관리 서버(300)는 식별 정보를 포함하는 제2 UI을 생성하고, 생성된 제2 UI 화면에 대응되는 정보를 디스플레이 장치(600)에 전송할 수 있다. 제1 UI 화면 및 제2 UI 화면에 대한 정보를 수신 받은 디스플레이 장치(600)는 제1 UI 화면 및 제2 UI 화면을 동시에 디스플레이 장치(600)의 디스플레이에 표시할 수 있다.
한편, 제1 UI 화면은 사용자(환자)의 증상 정보, 대기 번호 중 적어도 하나를 포함할 수 있다. 증상 정보 및 대기 번호는 대기자 정보로 호칭될 수 있다. 제1 UI 화면은 도 24의 제2 영역(2410)에 표시되는 화면일 수 있다. 또한, 제2 UI 화면은 사용자(환자)의 식별 정보, 병력 정보 중 적어도 하나를 포함할 수 있다. 식별 정보 및 병력 정보는 환자 정보로 호칭될 수 있다. 제2 UI 화면은 도 24의 제1 영역(2405)에 표시되는 화면일 수 있다.
여기서, 디스플레이 장치(600)는 병원 관리 서버(300)에 연결된 디스플레이를 포함하는 전자 장치를 의미할 수 있다. 예를 들어, 병원 관리 서버(300)에 연결된 담당 의사의 PC를 의미할 수 있다.
또한, 프로세서(140)는 UI 화면을 통해 병원 예약을 위한 정보가 입력되면, 사용자의 식별 정보 및 병원 예약을 위한 정보를 애플리케이션 서버(200)로 전송할 수 있고, 애플리케이션 서버(200)로부터 병원 예약 정보가 수신되면, 수신된 병원 예약 정보를 포함하는 UI 화면을 디스플레이에 표시할 수 있고, 예약 정보는 예약 시간을 포함할 수 있다.
프로세서(140)는 사용자 단말 장치(100)에 포함된 디스플레이를 통해 다양한 UI를 사용자에게 제공할 수 있다. 그리고, 사용자 단말 장치(100)는 사용자에게 병원 예약을 위한 정보 입력을 요청하는 UI 화면을 디스플레이에 표시할 수 있다. 병원 예약을 위한 정보는 진료 병원, 진료과, 진료 시간, 담당 의사 중 적어도 하나를 의미할 수 있다. 프로세서(140)는 사용자 단말 장치(100)에 포함된 사용자 인터페이스를 통해 병원 예약을 위한 정보가 수신되면, 수신된 병원 예약을 위한 정보 및 고유의 사용자 단말 장치(100)의 식별 정보를 애플리케이션 서버(200)에 전송할 수 있다. 여기서, 애플리케이션 서버(200)에 전송되는 식별 정보는 사용자 단말 장치(100)를 이용하는 사용자(환자)의 이름, 주민 번호, 환자 번호 등과 같은 개인 식별 정보를 의미할 수 있다. 만약, 애플리케이션 서버(200)에 사용자 단말 장치(100)의 개인 식별 정보가 저장되어 있는 경우, 사용자 단말 장치(100)는 식별 정보를 애플리케이션 서버(200)에 전송하지 않는 형태로 구현될 수 있다.
애플리케이션 서버(200)는 사용자 단말 장치(100)로부터 병원 예약을 위한 정보 및 식별 정보를 수신하여 병원 관리 서버(300)에 병원 예약을 위한 정보 및 식별 정보를 전송할 수 있다. 그리고, 병원 관리 서버(300)는 수신된 병원 예약을 위한 정보 및 식별 정보에 기초하여 병원 예약 정보를 생성할 수 있다. 그리고, 생성된 병원 예약 정보를 애플리케이션 서버(200)에 전송할 수 있다. 애플리케이션 서버(200)는 병원 관리 서버(300)로부터 수신된 병원 예약 정보를 사용자 단말 장치(100)에 전송할 수 있다. 그리고, 사용자 단말 장치(100)는 수신된 병원 예약 정보를 포함하는 UI 화면을 사용자 단말 장치(100)의 디스플레이에 표시할 수 있다. 여기서, 병원 예약 정보는 진료 병원, 진료과, 진료 시간(예약 시간), 담당 의사 중 적어도 하나를 포함할 수 있다.
한편, 실시 예에 따라, 사용자 단말 장치(100)는 병원 관리 서버(300)로부터 예약 정보 및 대기 번호를 동시에 수신하는 형태로 구현될 수 있다. 또한, 다른 실시 예에 따라, 사용자 단말 장치(100)는 병원 관리 서버(300)로부터 예약 정보를 먼저 수신하고 그 이후에 대기 번호를 수신하는 형태로 구현될 수도 있다.
한편, 예약과 관련된 구체적인 동작은 도 10 내지 도 14에 기술한다.
여기서, 프로세서(140)는 예약 시간으로부터 임계 시간 이전 시점부터 사용자 단말 장치(100)의 위치 정보를 병원 관리 서버(300)로 전송할 수 있고, 병원 관리 서버(300)로부터 위치 정보에 대응되는 대기 번호를 수신하면, 수신된 대기 번호를 포함하는 UI 화면을 디스플레이에 표시할 수 있다.
여기서, 병원 관리 서버(300)는 위치 정보가 병원의 위치로부터 임계 거리 내이면, 순위가 높은 대기 번호를 사용자 단말 장치(100)로 제공할 수 있다.
위치 정보 와 대기 번호와 관련된 구체적인 동작은 도 15 내지 도 19에 기술한다.
한편, 프로세서(140)는 수신된 대기 번호를 통신 인터페이스를 통해 애플리케이션 서버(200)에 전송할 수 있고, 애플리케이션 서버(200)가 식별 정보와 대기 번호를 병원 관리 서버(300)로 전송하도록 제어할 수 있다.
앞서, 설명한 바와 같이, 사용자 단말 장치(100)에서 수신된 증상 정보는 대기 번호와 맵핑(그룹핑)되어 병원 관리 서버(300)의 메모리에 저장될 수 있다. 따라서, 병원 관리 서버(300)는 수신된 증상 정보가 어느 환자의 것인지 알 수 없고, 단순히 특정 대기 번호에 대응되는 것이라는 정보만을 저장하고 있을 수 있다. 따라서, 사용자 단말 장치(100)는 대기 번호만을 애플리케이션 서버(200)에 전송할 수 있다. 사용자 단말 장치(100)는 사용자 단말 장치(100)에 할당된 대기 번호를 애플리케이션 서버(200)에 전송할 수 있고, 애플리케이션 서버(200)는 사용자 단말 장치(100)에 할당된 대기 번호를 병원 관리 서버(300)에 전송할 수 있다. 병원 관리 서버(300)는 사용자 단말 장치(100)에 할당된 대기 번호를 수신하여, 특정 대기 번호에 대응되는 증상 정보가 사용자 단말 장치(100)에 대한 것임을 판단할 수 있다. 할당된 대기 번호를 애플리케이션 서버(200)에 전송하는 동작과 관련되어 구체적인 내용은 도 21의 S2170 단계에서 후술한다.
앞서 설명한 바와 같이, 개인 정보 유출을 방지하기 위해 병원 관리 서버(300)는 증상 정보를 식별 정보와 결합하지 않을 수 있다. 그리고, 병원 관리 서버(300)는 증상 정보를 특정하기 위하여 대기 번호와 결합할 수 있다. 그리고, 병원 관리 서버(300)는 애플리케이션 서버(200)로부터 식별 정보 및 대기 번호를 수신할 수 있다.
한편, 일 예로, 병원 관리 서버(300)는 식별 정보 및 대기 번호를 동시에 애플리케이션 서버(200)로부터 수신할 수 있다. 다른 예로, 병원 관리 서버(300)는 식별 정보를 먼저 애플리케이션 서버(200)로부터 수신하고 대기 번호를 나중에 애플리케이션 서버(200)로부터 수신하는 형태로 구현될 수 있다.
이와 관련하여 구체적인 동작은 도 20 내지 도 24에서 후술한다.
또한, 병원 관리 서버(300)로 전송된 증상 정보 및 대기 번호를 포함하는 제1 UI 화면 및 사용자의 식별 정보 및 대기 번호를 포함하는 제2 UI 화면이 병원 관리 서버(300)와 통신하는 디스플레이 장치(600)에 제공될 수 있다.
병원 관리 서버(300)는 사용자 단말 장치(100)로부터 직접 증상 정보를 수신할 수 있고, 병원 관리 서버(300)는 사용자 단말 장치(100)에 부여한 대기 번호를 증상 정보에 결합하여 저장할 수 있다. 그리고, 병원 관리 서버(300)는 애플리케이션 서버(200)로부터 수신한 식별 정보 및 대기 정보를 결합하여 저장할 수 있다. 병원 관리 서버(300)가 증상 정보와 식별 정보를 모두 수신하지만, 증상 정보는 사용자 단말 장치(100)로부터 수신한 것이며, 식별 정보는 애플리케이션 서버(200)로부터 수신한 것일 수 있다. 애플리케이션 서버(200)에는 식별 정보만이 저장될 수 있으며, 증상 정보가 전혀 저장되지 않은 상태일 수 있다. 따라서, 애플리케이션 서버(200)가 해킹된다고 하여도 사용자 단말 장치(100)를 이용하는 사용자의 증상 정보는 유출되지 않을 수 있다.
병원 관리 서버(300)는 증상 정보와 증상 정보에 대응되는 대기 번호를 포함하는 제1 UI 화면을 생성할 수 있고, 생성된 제1 UI 화면을 디스플레이 장치(600)에 전송할 수 있다. 그리고, 병원 관리 서버(300)는 식별 정보와 식별 정보에 대응되는 대기 번호를 포함하는 제2 UI 화면을 생성할 수 있고, 생성된 제2 UI 화면을 디스플레이 장치(600)에 전송할 수 있다.
또한, 프로세서(140)는 병원 관리 서버(300)로부터 처방 정보를 수신할 수 있고, 수신된 처방 정보를 포함하는 UI 화면을 디스플레이에 표시할 수 있다. 여기서 처방 정보는 담당 의사가 환자에 대한 진료 결과를 입력한 정보를 의미할 수 있다. 병원 관리 서버(300)는 대기 번호에 기초하여 처방 정보를 전송할 사용자 단말 장치(100)를 식별할 수 있고, 식별된 사용자 단말 장치(100)로 처방 정보를 전송할 수 있다. 한편, 처방 단계와 관련된 구체적인 동작은 도 27 내지 도 30에서 후술한다.
한편, 병원 관리 서버(300)는 제1 병원 관리 서버 및 제2 병원 관리 서버를 포함할 수 있고, 증상 정보 및 대기 번호 요청은 제1 병원 관리 서버로 전송될 수 있으며, 사용자의 식별 정보는 제2 병원 관리 서버로 전송될 수 있다.
여기서, 제1 병원 관리 서버는 도 7의 병원 관리 서버(300) 및 접수 관리 서버(500)를 의미할 수 있다. 그리고, 제2 병원 관리 서버는 도 7의 병원 관리 서버(300) 및 EMR 서버(400)를 의미할 수 있다. 증상 정보 및 대기 번호 요청은 접수 관리 서버(500)를 거쳐 병원 관리 서버(300)에 전송될 수 있다. 그리고, 식별 정보는 병원 관리 서버(300)를 거쳐 EMR 서버(400)에 전송될 수 있다. 접수 관리 서버(500) 및 EMR 서버(400)에 대한 구체적인 기술은 도 7 내지 도 8에서 후술한다.
여기서, 증상 정보는 제1 통신 모듈을 통해 병원 관리 서버(300)로 전송될 수 있고, 사용자의 식별 정보는 제2 통신 모듈을 통해 병원 관리 서버(300)로 전송될 수 있다.
사용자 단말 장치(100)는 증상 정보와 식별 정보가 함께 유출되는 것을 방지하기 위하여 다른 통신 방식을 이용하여 병원 관리 서버(300)에 정보를 전송할 수 있다. 예를 들어, 프로세서(140)는 근거리 무선 통신 방식을 이용하여 증상 정보를 병원 관리 서버(300)에 전송할 수 있다. 근거리 통신 방식은 블루투스(Bluetooth), 와이파이(WiFi), 지그비(Zig bee), NFC(Near Field Communication), 적외선 중 적어도 하나를 의미할 수 있다. 또한, 프로세서(140)는 증상 정보를 전송하는데 이용한 통신 방식 이외에 다른 통신 방식을 이용하여 식별 정보를 병원 관리 서버(300)에 전송할 수 있다. 또한, 프로세서(140)는 식별 정보를 이동 통신 네트워크를 통해 병원 관리 서버(300)에 전송할 수 있다. 여기서, 이동 통신 네트워크는 LTE(Long Term Evolution), LTE-A(LTE Advanced), 4G(4th Generation), 5G(5th Generation)등과 같은 다양한 무선 통신 네트워크 등을 의미할 수 있다.
여기서, 프로세서(140)는 병원 관리 서버(300)로부터 처방 정보를 수신할 수 있고, 수신된 처방 정보를 포함하는 UI 화면을 디스플레이에 표시할 수 있고, 처방 정보는 제1 통신 모듈을 통해 병원 관리 서버(300)로부터 수신될 수 있다.
처방 정보는 진료상세명세서를 의미할 수 있다. 진료상세명세서는 약물 종류, 검사 항목, 치료 행위 항목 중 적어도 하나를 포함할 수 있다.
처방 정보는 증상 정보와 마찬가지로 민감한 개인 정보일 수 있다. 따라서, 처방 정보는 개인 정보 유출을 방지하기 위하여 식별 정보와 결합되어 함께 사용자(환자)에게 전송되지 않을 수 있다. 처방 정보와 식별 정보가 결합되어 저장되는 곳은 안정성이 확보된 EMR 서버(400)일 수 있다. 병원 관리 서버(300)는 처방 정보를 대기 번호와 함께 그룹핑하여 저장할 수 있다. 처방 정보 및 대기 번호가 함께 유출되어도 처방 정보가 누구의 것인지 알기 어렵기 때문이다. 따라서, 병원 관리 서버(300)는 증상 정보를 수신하는데 이용한 제1 통신 모듈을 그대로 이용하여 처방 정보를 사용자 단말 장치(100)에 전송할 수 있다.
한편, 프로세서(140)는 수신된 대기 번호를 기 설정된 조건에 기초하여 삭제할 수 있다. 일 예로, 프로세서(140)는 대기 번호가 수신된 시점으로부터 임계 시간이 경과한 이후 대기 번호를 삭제할 수 있다. 다른 예로, 프로세서(140)는 대기 번호에 포함된 날짜 정보에 기초하여 대기 번호를 삭제할 수 있다. 대기 번호는 날짜 정보를 포함할 수 있으며, 프로세서(140)는 대기 번호에 포함된 날짜 정보와 사용자 단말 장치(100)의 날짜 정보를 비교할 수 있다. 그리고, 대기 번호에 포함된 날짜 정보가 사용자 단말 장치(100)의 날짜보다 이전이면, 프로세서(140)는 대기 번호를 삭제할 수 있다.
한편, 상술한 대기 번호 삭제 동작은 대기 번호를 생성 또는 수신한 다양한 장치(사용자 단말 장치(100), 어플리케이션 서버(200), 병원 관리 서버(300), 접수 관리 서버(500)) 중 적어도 하나의 장치에서 수행될 수 있다.
한편, 본 개시에 따른 스마트 진료 시스템은 환자의 식별 정보와 증상 정보를 구분한다. 구체적으로, 사용자 단말 장치(100)는 식별 정보를 애플리케이션 서버(200)로 전송하고, 애플리케이션 서버(200)는 식별 정보를 병원 관리 서버(300)에 전송한다. 반면에, 사용자 단말 장치(100)는 증상 정보를 애플리케이션 서버(200)로 전송하지 않고, 바로 병원 관리 서버(300)에 전송한다. 따라서, 애플리케이션 서버(200)가 해킹을 당하여도 환자의 증상 정보는 유출되지 않을 수 있다. 환자의 증상 정보는 대기 번호와 결합하여 특정될 수 있다. 일반적으로, 증상 정보는 환자 고유의 개인 식별 정보와 결합하기 때문에 증상 정보가 누구의 병력 정보인지 알 수 있지만, 증상 정보가 대기 번호와 결합하게 되면 증상 정보가 누구의 것인지 쉽게 알 수 없다. 다만, 담당 의사는 대기 번호와 결합된 증상 정보가 어느 환자의 것인지 파악할 수 있어야 한다. 따라서, 대기자 정보(증상 정보를 포함)와 환자 정보(식별 정보)를 맵핑하는 동작이 필요할 수 있다. 이러한 과정을 통해 병원 관리 서버(300) 또는 담당 의사는 증상 정보가 어느 환자의 것인지 알 수 있다. 본 개시에 따른 증상 정보 관리 방법은 애플리케이션 서버(200)에 증상 정보를 저장시키지 않고 환자의 증상 정보를 미리 수집하여(또는 수신하여) 진료 시간을 단축시킬 수 있다. 즉, 환자의 개인 정보 유출에 대한 문제를 해결하면서 진료 시간을 단축시킬 수 있으므로, 본 개시에 따른 스마트 진료 시스템은 환자(고객)들의 대기 시간을 효과적으로 줄일 수 있는 효과를 가질 수 있다.
또한, 본 개시는 예약 환자들이 실제로 병원에 내원할 것인지 여부를 판단하는 동작을 포함한다. 구체적으로, 병원 관리 서버(300)는 사용자 단말 장치(100)로부터 위치 정보를 수신할 수 있다. 그리고, 병원 관리 서버(300)는 수신된 위치 정보가 병원의 위치로부터 임계 거리 내에 있다고 판단하면, 병원에 실제로 방문할 것이라고 판단할 수 있다. 위치 정보를 이용하여 예약 환자의 병원 방문 여부를 판단하면, 노쇼 고객을 구분할 수 있으며 불필요한 예약을 쉽게 취소할 수 있다. 본 개시의 실시 예에 따라 불필요한 예약을 취소할 수 있다면 병원 관리의 복잡성을 제거하여 단순화 시킬 수 있으며, 효율적으로 대기 인원을 관리할 수 있다. 대기 인원을 효율적으로 관리한다면 본 개시에 따른 스마트 진료 시스템은 환자들의 병원 대기 시간을 단축시킬 수 있는 효과를 가질 수 있다.
도 2는 도 1의 사용자 단말 장치의 구체적인 구성을 설명하기 위한 블록도이다.
도 2를 참조하면, 사용자 단말 장치(100)는 메모리(110), 통신 인터페이스(120), 디스플레이(130), 프로세서(140), 사용자 인터페이스(150), 입출력 인터페이스(160), 마이크(170) 또는 카메라(180) 중 적어도 하나로 구성될 수 있다.
메모리(110), 통신 인터페이스(120), 디스플레이(130), 프로세서(140)에 대해서는 도 1에서 설명 하였으므로 중복 기재를 생략한다.
사용자 인터페이스(150)는 버튼, 터치 패드, 마우스 및 키보드와 같은 장치로 구현되거나, 상술한 디스플레이 기능 및 조작 입력 기능도 함께 수행 가능한 터치 스크린으로도 구현될 수 있다. 여기서, 버튼은 사용자 단말 장치(100)의 본체 외관의 전면부나 측면부, 배면부 등의 임의의 영역에 형성된 기계적 버튼, 터치 패드, 휠 등과 같은 다양한 유형의 버튼이 될 수 있다.
입출력 인터페이스(160)는 HDMI(High Definition Multimedia Interface), MHL (Mobile High-Definition Link), USB (Universal Serial Bus), DP(Display Port), 썬더볼트(Thunderbolt), VGA(Video Graphics Array)포트, RGB 포트, D-SUB(D-subminiature), DVI(Digital Visual Interface) 중 어느 하나의 인터페이스일 수 있다.
입출력 인터페이스(160)는 오디오 및 비디오 신호 중 적어도 하나를 입출력 할 수 있다.
구현 예에 따라, 입출력 인터페이스(160)는 오디오 신호만을 입출력하는 포트와 비디오 신호만을 입출력하는 포트를 별개의 포트로 포함하거나, 오디오 신호 및 비디오 신호를 모두 입출력하는 하나의 포트로 구현될 수 있다.
사용자 단말 장치(100)는 마이크(170)를 더 포함할 수 있다. 마이크는 사용자 음성이나 기타 소리를 입력 받아 오디오 데이터로 변환하기 위한 구성이다.
마이크(170)는 활성화 상태에서 사용자의 음성을 수신할 수 있다. 예를 들어, 마이크는 사용자 단말 장치(100)의 상측이나 전면 방향, 측면 방향 등에 일체형으로 형성될 수 있다. 마이크는 아날로그 형태의 사용자 음성을 수집하는 마이크, 수집된 사용자 음성을 증폭하는 앰프 회로, 증폭된 사용자 음성을 샘플링하여 디지털 신호로 변환하는 A/D 변환회로, 변환된 디지털 신호로부터 노이즈 성분을 제거하는 필터 회로 등과 같은 다양한 구성을 포함할 수 있다.
카메라(180)는 피사체를 촬상하여 촬상 영상을 생성하기 위한 구성이며, 여기서 촬상 영상은 동영상과 정지 영상 모두를 포함하는 개념이다.
카메라(180)는 적어도 하나의 외부 기기에 대한 이미지를 획득할 수 있으며, 카메라, 렌즈, 적외선 센서 등으로 구현될 수 있다.
사용자 단말 장치(100)는 스피커(미도시)를 포함할 수 있다. 스피커(미도시)는 입출력 인터페이스에서 처리된 각종 오디오 데이터뿐만 아니라 각종 알림음이나 음성 메시지 등을 출력하는 구성요소일 수 있다.
사용자 단말 장치(100)는 진동부(미도시)를 포함할 수 있다. 진동부(미도시)는 임계 조건에서 진동 기능을 제공하는 구성요소일 수 있다. 임계 조건은 예약 확정 알림, 예약 시간 알림, 대기 번호 확정 알림, 진료 순서 알림, 처방 정보 수신 알림, 결제 요청 알림, 결제 확정 알림 중 적어도 하나일 수 있다. 이외에도 다양한 상황에서 진동부(미도시)의 진동 기능이 제공될 수 있다.
도 3은 일 실시 예에 따른 환자 진료 시스템의 구성을 설명하기 위한 도면이다.
도 3을 참조하면, 환자 진료 시스템(1000)은 사용자 단말 장치(100), 애플리케이션 서버(200) 및 병원 관리 서버(300)로 구성될 수 있다.
환자 진료 시스템(1000)은 병원에서 이루어지는 다양한 동작들의 집합을 의미할 수 있다. 구체적으로, 환자 진료 시스템(1000)은 환자의 진료 과정에서 이루어지는 예약, 접수, 진료, 처방 단계와 관련된 동작들을 포함할 수 있다.
사용자 단말 장치(100)는 스마트폰, 태블릿, PDA 와 같은 휴대용 전자 장치를 의미할 수 있다. 사용자 단말 장치(100)에는 애플리케이션이 설치될 수 있으며, 구체적으로, 사용자 단말 장치(100)에는 환자 진료 시스템(1000)에 이용되는 병원 애플리케이션이 설치될 수 있다. 병원 애플리케이션은 사용자가 진료 받고자 하는 병원의 예약을 수행할 수 있도록 가이드하는 다양한 UI를 제공할 수 있다.
애플리케이션 서버(200)는 사용자 단말 장치(100)에 설치된 애플리케이션에 대한 관리 및 제어를 위한 서버를 의미할 수 있다. 애플리케이션 서버(200)는 사용자 단말 장치(100)에 설치된 애플리케이션 프로그램의 실행 환경 및 데이터베이스의 접속 기능을 수행할 수 있다. 또한, 애플리케이션 서버(200)는 사용자 단말 장치(100)에 설치된 애플리케이션을 통하여 사용자 단말 장치(100)와 외부 서버 또는 외부 장치와 데이터를 주고 받을 수 있도록 동작할 수 있다.
병원 관리 서버(300)는 병원에서 이용되는 다양한 전자 장치를 의미할 수 있다. 병원 관리 서버(300)는 환자들의 진료 기록을 저장하는 장치, 대기 번호 등을 관리하는 접수 관리 장치, 의사가 환자와 관련된 정보를 입력하는 장치, 병원 내의 복수의 장치들을 제어하는 장치 등과 같이 병원에서 이용되는 다양한 장치를 의미할 수 있다. 한편, 병원 관리 서버(300)는 적어도 하나의 전자 장치를 의미할 수 있다. 실시 예에 따라, 병원 관리 서버(300)는 복수의 하드웨어로 구성되거나 복수의 전자 장치로 구성될 수 있다.
또한, 사용자 단말 장치(100)는 증상 정보(또는 개인 증상 정보) 및 식별 정보(또는 개인 식별 정보)를 서로 다른 장치에 전송할 수 있다. 여기서, 증상 정보는 사용자 신체적 또는 육체적으로 이상을 느끼는 증세를 의미할 수 있다. 그리고, 식별 정보는 이름, 생년월일, 주민번호, 여권번호, 의료보험번호, 고유 ID 등과 같이 사용자를 식별할 수 있는 정보를 의미할 수 있다.
또한, 사용자 단말 장치(100)는 예약 단계에서 식별 정보를 애플리케이션 서버(200)에 전송할 수 있다. 그리고, 애플리케이션 서버(200)는 수신된 식별 정보를 병원 관리 서버(300)에 전송할 수 있다. 병원 관리 서버(300)는 수신된 식별 정보에 기초하여 예약 동작을 수행할 수 있다.
그리고, 사용자 단말 장치(100)는 증상 정보를 애플리케이션 서버(200)를 거치지 않고 직접 병원 관리 서버(300)에 전송할 수 있다. 다만, 환자 진료 시스템(1000)에서 결과적으로 증상 정보 및 식별 정보는 병원 관리 서버(300)에 전송될 수 있다.
사용자 단말 장치(100)가 증상 정보 및 식별 정보를 서로 다른 장치로 전송하는 이유는 개인 정보를 보호하기 위한 것일 수 있다. 증상 정보와 식별 정보를 하나의 데이터 그룹으로 그룹핑하여 전송하는 경우, 개인 정보가 유출될 가능성이 높을 수 있다. 하지만, 도 3과 같이 증상 정보 및 식별 정보를 구분하여 전송하는 경우, 애플리케이션 서버(200)가 해킹을 당해도 증상 정보는 유출되지 않을 수 있다. 마찬가지로, 사용자 단말 장치(100)에서 전송되는 증상 정보 전송 과정에 해킹이 이루어져도 사용자의 식별 정보는 유출되지 않을 수 있다.
도 4는 도3의 실시 예를 설명하기 위한 흐름도이다.
도 4를 참조하면, 사용자 단말 장치(100)는 사용자 입력에 기초하여 예약 요청 및 식별 정보를 애플리케이션 서버(200)에 전송할 수 있다(S405). 그리고, 애플리케이션 서버(200)는 수신된 예약 요청 및 식별 정보를 병원 관리 서버(300)에 전송할 수 있다(S410). 그리고, 병원 관리 서버(300)는 수신된 예약 요청 및 식별 정보에 기초하여 예약 정보를 생성할 수 있다(S415). 여기서, 예약 정보는 병원 이름, 진료과, 예약 시간, 예약 담당 의사, 준비물, 주의 사항 등과 같이 병원 진료와 관련된 다양한 정보를 포함할 수 있다. 여기서, 예약 정보를 생성함에 있어, 병원 관리 서버(300)는 환자의 신환(또는 신규환자) 또는 재진 여부를 식별할 수 있다. 병원 관리 서버(300)는 환자가 신환인지 여부에 따라서 예약 정보를 다르게 관리할 수 있다. 구체적으로, 병원 관리 서버(300)는 환자가 신환인 경우, EMR 서버(400)(도, 6 참조)에 환자의 정보를 새로 생성할 수 있다.
또한, 병원 관리 서버(300)는 수신된 예약 정보에 기초하여 예약 정보에 대응되는 환자 정보를 생성할 수 있다(S420). 예를 들어, 수신된 예약 정보에 포함된 사용자 이름이 “홍길동”이면, 병원 데이터베이스에 저장된 “홍길동”에 대한 환자 정보를 생성할 수 있다. 여기서, 환자 정보란 개인의 식별 정보 및 병력 정보가 모두 기록된 의료 기록에 대한 정보를 의미할 수 있다. 신환 (신규 환자)의 경우, 병원 관리 서버(300)는 환자 정보가 데이터 베이스에 저장되지 않은 것이므로 새로운 병록 번호를 생성할 수 있다. 그리고, 재진의 경우, 환자 정보가 데이터 베이스에 저장되어 있으므로 기존의 병록번호에 예약정보를 추가 할 수 있다. 한편, 예약 요청과 관련된 구체적인 동작은 도 10 내지 도 14에서 후술한다. 한편, 병원 관리 서버(300) 또는 애플리케이션 서버(200)는 환자의 개인 정보와 관련된 예약 정보 또는 식별 정보를 기 설정된 시간이 경과한 경우 자동으로 삭제할 수 있다. 또한, 처방 정보와 관련된 삭제 동작에 대해서는 도 28에서 구체적으로 후술한다.
또한, 병원 관리 서버(300)는 생성된 예약 정보를 애플리케이션 서버(200)에 전송할 수 있다(S425). 그리고, 애플리케이션 서버(200)는 수신된 예약 정보를 사용자 단말 장치(100)에 전송할 수 있다(S430). 그리고, 사용자 단말 장치(100)는 수신된 예약 정보를 디스플레이에 표시할 수 있다(S435). 또한, 사용자 단말 장치(100)는 대기 번호 요청 여부를 판단할 수 있다(S440). 대기 번호를 요청 여부를 판단하는 동작은 병원 관리 서버(300)에 사용자 고유의 대기 번호를 할당해달라는 요청을 전송할 것인지 판단하는 것을 의미할 수 있다. 예약과 다르게 대기 번호를 새로 요청하는 이유는 병원이 예약 정보와 별개로 대기 번호를 이용하여 환자들의 진료 순서를 결정하고 있기 때문일 수 있다. 따라서, 사용자 단말 장치(100)는 사용자가 병원을 방문할 것인지 여부를 판단하기 위하여 사용자의 의도를 묻는 UI를 제공할 수 있다. 그리고, 사용자 단말 장치(100)가 병원을 방문하겠다는 사용자의 응답을 수신하면(대기 번호를 요청하기로 판단하면), 사용자 단말 장치(100)는 대기 번호 요청 및 증상 정보를 병원 관리 서버(300)에 전송할 수 있다(S445). 사용자 단말 장치(100)가 대기 번호 요청과 함께 증상 정보를 함께 전송하는 것은 개인 정보인 증상 정보를 식별 정보와 분리하여 전송하기 위해서이다. 여기서, 증상 정보는 사용자 단말 장치(100)의 메모리에 저장된 상태이거나 사용자에 의해 입력된 것일 수 있다. 증상 정보를 입력 받는 시점은 다양할 수 있다.
병원 관리 서버(300)는 사용자 단말 장치(100)로부터 대기 번호 요청 및 증상 정보를 수신하면, 병원 관리 서버(300)는 대기 번호 요청 및 증상 정보를 전송한 사용자 단말 장치(100)에 대한 기기 정보를 획득할 수 있다.
그리고, 병원 관리 서버(300)는 사용자가 병원을 방문할 것인지 여부를 판단할 수 있다(S450). S450 단계의 구체적인 내용은 도 15 내지 도 17에서 기술한다.
병원 관리 서버(300)는 환자가 병원을 방문하는 것으로 판단하면, 예약 정보에 기초하여 우선 순위를 갖는 대기 번호를 사용자 단말 장치(100)에 할당할 수 있다. 그리고, 병원 관리 서버(300)는 사용자 단말 장치(100)에 할당된 대기 번호 및 사용자 단말 장치(100)로부터 수신한 증상 정보를 결합하여 대기자 정보를 생성할 수 있다(S455). 여기서, 대기자 정보는 대기 번호 및 증상 정보를 포함할 수 있으며 사용자의 식별 정보를 포함하지 않을 수 있다. 따라서, 대기자 정보만으로는 사용자가 누구인지 특정할 수 없다.
병원 관리 서버(300)는 사용자 단말 장치(100)에 할당한 대기 번호를 획득한 기기 정보에 기초하여 사용자 단말 장치(100)에 전송할 수 있다(S460). 그리고, 사용자 단말 장치(100)는 수신된 대기 번호를 디스플레이에 표시할 수 있다(S465).
그리고, 병원 관리 서버(300)는 환자 정보 및 대기자 정보를 맵핑할 수 있다(S470). S470 단계에 대해서는 도 20 내지 도 26에서 구체적으로 후술한다.
도 5는 다른 실시 예에 따른 환자 진료 시스템의 구성을 설명하기 위한 도면이다.
도 5를 참조하면, 환자 진료 시스템(1000)은 사용자 단말 장치(100), 애플리케이션 서버(200), 병원 관리 서버(300) 및 EMR 서버(400)를 포함할 수 있다. 도 3의 설명에서 병원 관리 서버(300)가 병원에서 이용되는 다양한 전자 장치를 포함할 수 있다고 기술하였다. 하지만, 도 3의 병원 관리 서버(300)에 포함될 수 있는 EMR 서버(400)를 별도로 분리한 실시 예를 도 5에서 설명한다.
구체적으로, 사용자 단말 장치(100)는 식별 정보를 애플리케이션 서버(200)에 전송할 수 있으며, 애플리케이션 서버(200)는 수신된 식별 정보를 병원 관리 서버(300)에 전송할 수 있고, 병원 관리 서버(300)는 수신된 식별 정보를 EMR 서버(400)에 전송할 수 있다. 그리고, EMR 서버(400)는 수신된 식별 정보에 대응되는 환자 정보를 검색하고, 검색된 환자 정보를 병원 관리 서버(300)에 전송할 수 있다. 한편, 사용자 단말 장치(100)는 증상 정보를 병원 관리 서버(300)에 전송할 수 있다.
여기서, EMR 서버(400)는 복수의 환자들에 대한 의료 기록을 전산 처리하는 서버를 의미할 수 있다. 구체적으로, EMR 서버(400)는 수신된 식별 정보에 대응되는 환자 정보를 검색하고, 검색된 환자 정보(식별 정보 포함)를 병원 관리 서버(300)에 전송할 수 있다.
도 3에서 병원 관리 서버(300)는 병원 관리 업무에 이용되는 다양한 전자 장치로 기술되었지만, 도 5의 병원 관리 서버(300)는 대기 번호 할당하는 장치를 의미할 수 있다. 또한, 도 5의 병원 관리 서버(300)는 환자 정보 및 대기자 정보를 맵핑하는 장치를 의미할 수 있다.
결과적으로, 병원 관리 서버(300)는 사용자 단말 장치(100)로부터 증상 정보를 수신할 수 있으며, 애플리케이션 서버(200)로부터 식별 정보를 수신할 수 있다.
한편, 도 5에서 개시하는 동작들에 대한 구체적인 설명은 도 3의 동작들과 대응될 수 있다. 따라서, 도 3과 중복되는 설명에 대하여 자세한 기재를 생략한다.
도 6은 도5의 실시 예를 설명하기 위한 흐름도이다.
도 6을 참조하면, 사용자 단말 장치(100)는 예약 요청 및 식별 정보를 애플리케이션 서버(200)에 전송할 수 있다 (S605). 그리고, 애플리케이션 서버(200)는 수신된 예약 요청 및 식별 정보를 병원 관리 서버(300)에 전송할 수 있다 (S610). 그리고, 병원 관리 서버(300)는 수신된 식별 정보를 EMR 서버(400)에 전송할 수 있다(S615). 그리고, EMR 서버(400)는 수신된 식별 정보에 대응되는 환자 정보를 검색할 수 있다. 그리고, EMR 서버(400)는 검색된 환자 정보를 병원 관리 서버(300)에 전송할 수 있다(S620). 만약, EMR 서버(400)에 수신된 식별 정보에 대응되는 환자 정보가 존재 하지 않으면, EMR 서버(400)는 새로운 병록 번호를 생성하고, 새로 생성된 병록 번호를 병원 관리 서버(300)에 전송할 수 있다. 한편, 병원 관리 서버(300)는 수신된 환자 정보에 기초하여 예약 정보를 생성할 수 있다(S625). 그리고, 병원 관리 서버(300)는 생성된 예약 정보를 애플리케이션 서버(200)에 전송할 수 있으며(S630), 애플리케이션 서버(200)는 수신된 예약 정보를 사용자 단말 장치(100)에 전송할 수 있다(S635).
사용자 단말 장치(100)가 예약 정보를 수신하면, 사용자 단말 장치(100)는 예약 정보를 디스플레이에 표시할 수 있고 (S640), 대기 번호 요청 여부를 판단할 수 있다(S645). 사용자 단말 장치(100)가 대기 번호를 요청하는 것으로 판단하면, 사용자 단말 장치(100)는 대기 번호 요청 및 증상 정보를 병원 관리 서버(300)에 전송할 수 있다(S650). 또한, 병원 관리 서버(300)는 사용자의 병원 방문 여부를 판단할 수 있다(S655). 또한, 사용자가 병원을 방문하는 것으로 판단되면, 병원 관리 서버(300)는 대기 번호를 사용자 단말 장치(100)에 할당하고, 할당된 대기 번호 및 증상 정보를 결합하여 대기자 정보를 생성할 수 있다(S660). 병원 관리 서버(300)는 사용자 단말 장치(100)에 대기 번호를 전송할 수 있으며(S665), 사용자 단말 장치(100)는 수신된 대기 번호를 디스플레이에 표시할 수 있다(S670). 또한, 병원 관리 서버(300)는 환자 정보 및 대기자 정보를 맵핑할 수 있다(S675).
한편, 도 6에서 개시하는 동작들에 대한 구체적인 설명은 도 4의 동작들과 대응될 수 있다. 따라서, 도 4와 중복되는 설명에 대하여 자세한 기재를 생략한다.
도 7은 또 다른 실시 예에 따른 환자 진료 시스템의 구성을 설명하기 위한 도면이다.
도 7을 참조하면, 환자 진료 시스템(1000)은 사용자 단말 장치(100)¸ 애플리케이션 서버(200)¸ 병원 관리 서버(300)¸ EMR 서버(400) 및 접수 관리 서버(500)를 포함할 수 있다.
접수 관리 서버(500)는 병원의 환자 접수 동작과 관련된 기능을 수행하는 장치를 의미할 수 있다. 접수 관리 서버(500)는 대기 번호를 관리하는 기능을 별도로 수행하는 장치를 의미할 수 있다. 한편, 도 5의 병원 관리 서버(300)는 대기 번호를 할당하는 기능을 수행하는 것으로 기재하였지만, 도 7의 병원 관리 서버(300)는 대기 번호를 할당하는 기능을 수행하지 않을 수 있으며, 환자 정보 및 대기자 정보를 맵핑하는 기능을 수행할 수 있다.
구체적으로, 사용자 단말 장치(100)는 식별 정보를 애플리케이션 서버(200)에 전송할 수 있고, 애플리케이션 서버(200)는 수신된 식별 정보를 병원 관리 서버(300)에 전송할 수 있다. 병원 관리 서버(300)는 수신된 식별 정보를 EMR 서버(400)에 전송할 수 있다. EMR 서버(400)는 수신된 식별 정보에 대응되는 환자 정보를 검색할 수 있고, 검색된 환자 정보를 병원 관리 서버(300)에 전송할 수 있다.
또한, 사용자 단말 장치(100)는 증상 정보를 접수 관리 서버(500)에 전송할 수 있고, 접수 관리 서버(500)는 수신된 증상 정보를 대기 번호와 함께 병원 관리 서버(300)에 전송할 수 있다.
결과적으로, 병원 관리 서버(300)는 접수 관리 서버(500)로부터 증상 정보를 수신할 수 있으며, 애플리케이션 서버(200)로부터 식별 정보를 수신할 수 있다.
한편, 도 7에서 개시하는 동작들에 대한 구체적인 설명은 도 3 및 도 5의 동작들과 대응될 수 있다. 따라서, 도 3 및 도 5와 중복되는 설명에 대하여 자세한 기재를 생략한다.
도 8은 도7의 실시 예를 설명하기 위한 흐름도이다.
도 8을 참조하면, S805, S810, S815, S820, S825, S830, S835, S840, S845 동작은 도 6의 S605, S610, S615, S620, S625, S630, S635, S640, S645에 대응될 수 있다. 따라서, 도 6과 중복되는 설명은 기재를 생략한다.
도 8의 사용자 단말 장치(100)는 대기 번호를 요청하기로 판단하면, 대기 번호 요청 및 증상 정보를 접수 관리 서버(500)에 전송할 수 있다 (S850). 또한, 접수 관리 서버(500)는 사용자의 병원 방문 여부를 판단할 수 있다 (S855). 또한, 사용자가 병원을 방문하는 것으로 판단되면, 접수 관리 서버(500)는 대기 번호를 사용자 단말 장치(100)에 할당하고, 할당된 대기 번호 및 증상 정보를 결합하여 대기자 정보를 생성할 수 있다 (S860). 그리고, 접수 관리 서버(500)는 대기 번호를 사용자 단말 장치(100)에 전송할 수 있다 (S865). 그리고, 사용자 단말 장치(100)는 수신된 대기 번호를 디스플레이에 표시할 수 있다 (S870).
한편, 접수 관리 서버(500)는 S860 단계를 통해 결합된 대기자 정보를 병원 관리 서버(300)에 전송할 수 있다 (S875). 그리고, 병원 관리 서버(300)는 환자 정보 및 대기자 정보를 맵핑할 수 있다 (S880).
한편, 도 8에서 개시하는 동작들에 대한 구체적인 설명은 도 4 및 도 6의 동작들과 대응될 수 있다. 따라서, 도 4 및 도 6과 중복되는 설명에 대하여 자세한 기재를 생략한다.
도 9는 병원에서 환자를 관리하는 복수의 단계를 설명하기 위한 흐름도이다.
도 9를 참고하면, 환자 진료 시스템(1000)은 예약 단계 (S900), 접수 단계 (S910), 진료 단계 (S920) 및 처방 단계 (S930)를 포함할 수 있다.
예약 단계 (S900)는 환자가 병원을 직접 방문하기전에 예약 대상 및 예약 시간을 결정하는 단계를 의미할 수 있다. 예약 대상은 진료 병원, 진료과 또는 진료 의사 중 적어도 하나를 포함할 수 있으며, 예약 시간은 진료 시간 또는 검사 시간 중 적어도 하나를 포함할 수 있다.
또한, 예약 단계 (S900)는 예약 대상 및 예약 시간을 결정하는 다양한 실시 예를 포함할 수 있다. 일 실시 예에 따라, 사용자가 직접 예약 대상 및 예약 시간을 결정할 수 있다. 다른 실시 예에 따라, 진료 증상을 입력하면, 자동으로 진료과, 진료 병원, 진료 시간 또는 검사 시간 중 적어도 하나가 결정될 수 있다.
접수 단계(S910)는 병원에 실제 환자가 병원에 방문한 경우 진료 순서를 결정하는 단계를 의미할 수 있다. 접수 단계 (S910)는 환자가 예약을 한 경우와 환자가 예약을 하지 않은 경우를 구분하여 진료 순서를 결정할 수 있다. 환자가 예약을 하지 않은 경우, 별도의 대기 번호 요청이 있는 경우에만 대기 번호를 사용자에게 부여할 수 있다. 여기서, 별도의 대기 번호 요청은 병원 애플리케이션을 이용하여 대기 번호를 요청하는 형태로 구현되거나 직접 접수 관리자에게 구두로 요청하는 형태로 구현될 수 있다.
한편, 접수 단계는 종이 대기 번호를 뽑는 과정으로 구현될 수 있다. 여기서, 종이 대기 번호를 제공하는 장치는 병원 관리 서버(300) 또는 접수 관리 서버(500)와 시간 정보가 동기화 된 상태일 수 있다.
진료 단계 (S920)는 의사가 환자를 진찰하는 단계를 의미할 수 있다. 의사가 이용하는 전자 장치는 내부 데이터베이스로부터 환자 정보를 수신할 수 있으며 내부 데이터베이스 이외에 별개의 서버로부터 대기자 정보를 수신할 수 있다. 환자 정보는 사용자에 대응되는 식별 정보를 포함할 수 있고, 대기자 정보는 사용자에 대응되는 증상 정보를 포함할 수 있다. 그리고, 환자 정보 및 대기자 정보는 다양한 실시 예에 따라 맵핑될 수 있다. 일 실시 예에 따라, 환자 정보 및 대기자 정보는 대기 번호에 기초하여 자동 맵핑될 수 있다. 다른 실시 예에 따라, 환자 정보 및 대기자 정보는 의사의 입력에 기초하여 맵핑될 수 있다.
처방 단계 (S930)는 의사가 환자 정보 및 대기자 정보에 기초하여 환자에 대응되는 처방을 내리는 것을 의미할 수 있다. 구체적으로, 의사는 처방 정보를 병원 관리 서버(300)에 입력할 수 있다. 그리고, 처방 정보 중 일부 정보를 환자에게 전송할 수 있다.
도 10은 환자를 관리하는 복수의 단계 중 일 실시 예에 따른 예약 단계를 설명하기 위한 흐름도이다.
도 10을 참조하면, 예약 단계 (S900)는 애플리케이션 로그인 단계(S901), 진료 병원, 진료과, 진료 시간 또는 담당 의사 을 선택하는 단계 (S902), 예약을 확정하는 단계 (S903)를 포함할 수 있다.
애플리케이션 로그인 단계(S901)는 병원과 관련된 애플리케이션에 사용자 고유의 ID를 이용하여 접근 권한을 획득하는 것을 의미할 수 있다. 여기서, 로그인 방식은 기 저장된 고유의 ID 및 패스워드를 이용하는 방식, 휴대폰 본인 인증 방식, 생체 정보 인증 방식 등 다양한 본인 인증 방식이 적용될 수 있다.
진료 병원, 진료과, 진료 시간 또는 담당 의사 중 적어도 하나를 선택하는 단계 (S902)는 다양한 실시 예가 적용될 수 있다.
일 실시 예에 따라, 사용자가 직접 진료 병원, 진료과, 진료 시간 또는 담당 의사 중 적어도 하나를 검색할 수 있다. 사용자가 진료 병원, 진료과, 진료 시간 또는 담당 의사 중 적어도 하나를 직접 입력하고, 사용자 단말 장치(100)는 입력된 정보를 예약에 필요한 정보로 획득할 수 있다.
다른 실시 예에 따라, 사용자 단말 장치(100)는 사용자에게 복수의 선택 항목UI를 제공하고 사용자가 복수의 선택 항목 UI 중 특정 항목 UI를 선택하도록 가이드할 수 있다.
사용자 단말 장치(100)는 진료과에 대한 복수의 선택 항목 UI를 제공할 수 있다. 사용자가 진료 증상을 입력하면 사용자 단말 장치(100)는 진료 증상에 대한 진료과를 분석할 수 있다. 그리고,?사용자 단말 장치(100)는 분석된 결과에 기초하여 적어도 하나의 진료과를 항목 UI로 제공할 수 있다. 그리고, 제공된 항목 UI가 사용자의 의도에 맞는지 확인할 수 있다.
또한, 사용자 단말 장치(100)는 진료병원에 대한 복수의 선택 항목 UI를 제공할 수 있다. 구체적으로, 사용자 단말 장치(100)는 현재 사용자 단말 장치(100)의 GPS 위치 정보, 기 저장된 GPS 위치 정보(예를 들어, 집, 회사), 최근 병원 방문 이력 정보 중 적어도 하나에 기초하여 진료 병원에 대한 복수의 선택 항목 UI를 제공할 수 있다.
또한, 사용자 단말 장치(100)는 진료 시간에 대한 복수의 선택 항목 UI를 제공할 수 있다. 사용자 단말 장치(100)는 병원 관리 서버(300)와 정보를 교환함으로써 병원에 예약이 가능한 시간 정보를 요청할 수 있으며, 병원 관리 서버(300)로부터 예약이 가능한 시간 정보를 획득할 수 있다. 그리고, 사용자 단말 장치(100)는 획득된 예약이 가능한 시간 정보를 복수의 선택 항목 UI를 제공할 수 있다.
한편, 제공된 복수의 항목 UI 중 특정 항목 UI에 대한 사용자 입력이 수신되면, 사용자 단말 장치(100)는 수신된 특정 항목에 대응되는 정보를 예약에 필요한 정보로 획득할 수 있다.
또한, 사용자 단말 장치(100)는 사용자의 과거 병원 방문 이력 정보에 기초하여 복수의 리스트를 표시하고, 복수의 리스트 중 사용자가 선택한 항목을 예약에 필요한 정보로 획득할 수 있다. 사용자의 과거 병원 방문 이력 정보를 이용하는 실시 예는 도 11 및 도 12에서 구체적으로 기술한다.
예약을 확정하는 단계 (S903)는 사용자 단말 장치(100)가 예약에 필요한 정보를 병원 관리 서버(300)에 전송하고, 사용자 단말 장치(100)가 병원 관리 서버(300)로부터 최종 예약 정보를 획득하는 것을 의미할 수 있다.
도 11은 과거 이력 정보를 이용하여 예약 단계를 수행하는 실시 예를 설명하기 위한 도면이다.
도 11을 참조하면, 표(1105)는 사용자의 과거 병원 방문 이력 정보를 의미할 수 있다. 그리고, 표(1110)는 표(1105)를 분석한 결과를 의미할 수 있다. 사용자 단말 장치(100)는 사용자의 과거 병원 방문 이력 정보에 기초하여 최근 방문 병원, 최다 방문 병원 또는 과거 방문 병원 중 적어도 하나를 식별할 수 있다. 여기서, 과거 방문 병원은 최다 방문 병원 이외에 다른 정보에 기초하여 사용자에게 추천하는 병원을 의미할 수 있다. 예를 들어, 최다 방문 병원은 데이터에 저장된 특정 임계 기간(예를 들어, 5개월)에서 가장 많이 방문한 병원을 의미할 수 있으며, 과거 방문 병원은 데이터에 저장된 모든 기간에서 가장 많이 방문한 병원을 의미할 수 있다.
사용자 단말 장치(100)는 과거 병원 방문 이력 정보 중 날짜 정보에 기초하여 최근 방문 날짜를 식별하고 식별된 최근 방문 날짜에 대응되는 병원을 식별하여 최근 방문 병원으로 결정할 수 있다. 또한, 사용자 단말 장치(100)는 임계 기간(예를 들어, 5개월)의 과거 병원 방문 이력 정보를 분석하여 최다 방문 병원을 획득할 수 있다.
그리고, 사용자 단말 장치(100)는 식별된 최근 방문 병원, 최다 방문 병원 또는 과거 방문 병원 중 적어도 하나를 항목 UI로 제공할 수 있다.
한편, 표(1105) 및 표(1110)에서는 날짜, 병원, 진료과, 병명 등을 표시하였지만 이는 예시적인 것에 불과하며 추가적인 정보가 포함될 수 있다.
도 12는 도 11의 실시 예에 따른 UI를 설명하기 위한 도면이다.
도 12를 참고하면, 사용자 단말 장치(100)는 사용자에게 방문하고자 하는 병원 정보를 입력하도록 가이드하는 UI를 제공할 수 있다 (1205). 또한, 사용자 단말 장치(100)는 복수의 항목 UI를 표시하여 사용자가 특정 항목을 선택하도록 가이드할 수 있다. 구체적으로, 복수의 항목 UI는 최근 방문 병원에 대응되는 UI (1210), 최다 방문 병원에 대응되는 UI(1215), 과거 방문 병원에 대응되는 UI(1220), 현재 위치 주변 병원에 대응되는 UI(1225), 사용자가 직접 방문 병원을 입력하는 UI(1230) 중 적어도 하나를 포함할 수 있다.
여기서, 현재 위치 주변 병원에 대응되는 UI를 위해 사용자 단말 장치(100)는 위치 정보를 외부 서버에 전송할 수 있으며, 외부 서버로부터 위치 정보에 대응되는 병원 정보를 수신할 수 있다.
도 13은 환자를 관리하는 복수의 단계 중 다른 실시 예에 따른 예약 단계를 설명하기 위한 흐름도이다.
도 13을 참조하면, 예약 단계 (S900) 중 로그인 단계(S901) 및 예약 확정 단계(S903)는 도 10에서 기재 하였으므로 중복 설명은 생략한다. 예약 단계(S900)는 사용자의 증상 정보를 입력 받는 단계(S902-1), 진료과를 결정 하는 단계(S902-2), 진료 병원, 진료 시간 또는 담당 의사 중 적어도 하나를 선택하는 단계(S902-3)를 포함할 수 있다.
사용자의 증상 정보를 입력 받는 단계(S902-1)는 사용자가 입력하는 증상 정보를 수신하는 단계를 의미할 수 있다. 사용자 단말 장치(100)는 사용자가 증상 정보를 입력할 수 있도록 가이드하는 UI를 표시할 수 있다. 또한, 사용자 단말 장치(100)는 사용자 인터페이스(150)를 통해 사용자가 입력한 증상 정보를 수신할 수 있다.
진료과를 결정 하는 단계(S902-2)는 수신된 증상 정보에 기초하여 자동으로 진료과를 식별하는 것을 의미할 수 있다. 사용자 단말 장치(100)는 기 저장된 룩업 테이블에 기초하여 수신된 증상 정보에 대응되는 진료과를 결정할 수 있다. 여기서, 식별되는 진료과는 적어도 하나일 수 있다. 복수개의 진료과가 식별된 경우, 사용자 단말 장치(100)는 가장 정확도가 높은 결과가 우선하여 디스플레이에 표시될 수 있다.
일 예로, 기 저장된 룩업 테이블은 사용자 단말 장치(100)에 저장될 수 있다. 여기서, 사용자 단말 장치(100)는 내부 메모리에 저장된 정보에 기초하여 진료과를 결정할 수 있다.
다른 예로, 기 저장된 룩업 테이블은 애플리케이션 서버(200)에 저장된 것일 수 있다. 따라서, 사용자 단말 장치(100)는 수신된 증상 정보를 애플리케이션 서버(200)에 전송할 수 있으며, 애플리케이션 서버(200)는 수신된 증상 정보에 기초하여 진료과를 결정할 수 있다. 그리고, 결정된 진료과를 사용자 단말 장치(100)에 전송할 수 있다. 여기서, 사용자 단말 장치(100)는 증상 정보를 애플리케이션 서버(200)에 전송하는 과정에서 식별 정보를 전송하지 않을 수 있다. 증상 정보가 애플리케이션 서버(200)에 전송 되는 경우, 개인 정보가 유출될 가능성이 있으므로, 증상 정보를 애플리케이션 서버(200)에 전송하는 경우 사용자 단말 장치(100)는 식별 정보를 제외하고 증상 정보만으로 애플리케이션 서버(200)에 전송할 수 있다.
진료 병원, 진료 시간 또는 담당 의사 중 적어도 하나를 선택하는 단계(S902-3)는 진료과가 결정된 이후에 예약에 필요한 세부 정보를 획득하는 것을 의미할 수 있다.
도 14는 도 13의 실시 예에 따른 UI를 설명하기 위한 도면이다.
도 14를 참조하면, 사용자 단말 장치(100)는 증상 정보를 입력 받도록 가이드하는 UI(1405)를 디스플레이에 표시할 수 있다. 그리고, 사용자 단말 장치(100)는 복수의 항목 UI를 디스플레이에 표시할 수 있다. 여기서, 복수의 항목 UI는 최근 진단 받은 병명에 대응되는 UI (1410), 최다 진단 받은 병명에 대응되는 UI(1415), 과거에 진단 받은 병명에 대응되는 UI(1420), 사용자가 직접 증상을 입력하는 UI(1425) 중 적어도 하나를 포함할 수 있다.
한편, 복수의 항목 UI(1410, 1415, 1420)에 표시되는 정보들(골절, 알러지, 감기)는 도 11의 표(1105에 포함된 정보에 기초한 것일 수 있다.
도 15는 환자를 관리하는 복수의 단계 중 접수 단계를 설명하기 위한 흐름도이다.
도 15를 참조하면, 접수 단계(S910)는 내원 여부 판단 단계(S911) 및 대기 번호 부여 단계(S912)를 포함할 수 있다.
내원 여부 판단 단계(S911)는 대기 번호를 요청한 사용자(또는 환자)가 병원에 방문하였는지 여부를 판단하는 동작을 의미할 수 있다. 대기 번호를 원격으로 부여하는 경우 사용자가 병원 근처에 존재 하지 않아 무의미한 대기 번호가 부여되는 문제점이 발생할 수 있다. 따라서, 병원 관리 서버(300)는 특정 조건 하에서만 환자에게 대기 번호를 부여할 수 있다. 내원 여부 판단에 대한 구체적인 동작은 도 16 및 도 17에서 후술한다.
대기 번호 부여 단계(S912)는 접수 번호를 부여하는 단계를 의미할 수 있다. 그리고, 병원 관리 서버(300)는 대기 번호 및 증상 정보에 기초하여 진료 순서를 결정할 수 있다.
환자A, B, C의 진료 순서를 결정하는 것으로 가정한다. 환자의 정보는 아래와 같다.
“환자 A: 대기 번호1, VAS 통증 점수 3 (덜 심한 통증),발병일: 5개월전, 진료 예상 시간으로부터 남은 시간 : 5분”
“환자 B:대기 번호 2,VAS 통증 점수 6점 (중간 정도의 통증), 발병일: 1주일전, 진료 예상 시간으로부터 남은 시간 : 20분”
“환자 C: 대기 번호 3, VAS 9점 (심한 통증) , 발병일: 당일, 10m 높이에서 낙상, 진료 예상 시간으로부터 남은 시간 40분”
병원 관리 서버(300)는 대기번호 및 증상정보에 기초하여 진료 순서를 결정한다.
일 실시 예에 따라, 병원 관리 서버(300)는 대기 번호를 고려하여 진료 순서를 결정할 수 있다. 구체적으로, 병원 관리 서버(300)는 대기 번호 순서에 따라 상술한 가정에서 대기 번호 1, 2. 3 순서로 진료 순서를 결정할 수 있다.
다른 실시 예에 따라, 병원 관리 서버(300)는 증상 정보(또는 통증 정보)를 고려하여 진료 순서를 결정할 수 있다. 이 경우, 병원 관리 서버(300)는 대기 번호 3, 2, 1 순서로 진료 순서를 결정할 수 있다.
또 다른 실시 예에 따라, 병원 관리 서버(300)는 진료 순서를 결정함에 있어 우선 순위가 필요한 환자를 고려하여 진료 순서를 결정할 수 있다. 상술한 예시에서 대기 번호가 10번인 환자 D가 있을 수 있다. 환자 D는 우선 순위가 필요한 환자일 수 있다. 예를 들어, 환자 D는 치료가 시급한 응급 환자이거나 병원에서 난동을 부리는 환자일 수 있다. 병원 관리 서버(300)는 환자 D에게 대기 번호와 관계 없이 우선 순위를 부여하여 진료 순서를 결정할 수 있다. 병원 관리 서버(300)는 결과적으로 10, 3, 2, 1 순서로 진료 순서를 결정할 수 있다.
한편, 대기 번호와 관련되어 병원 관리 서버(300)가 관련 동작을 수행하는 것으로 기재하였지만, 접수 관리 서버(500)가 관련 동작을 수행하는 형태로 구현될 수 있다. 여기서, 접수 관리 서버(500)는 디스플레이를 추가적으로 포함할 수 있으며, 접수 관리 서버(500)는 디스플레이에 진료 순서를 표시할 수 있다. 그리고, 환자 D와 같이 부득이하게 우선 순위를 줘야 하는 상황이 발생하면 양해의 문구를 제공할 수 있다.
한편, 다른 실시 예에 따른, 대기 번호 부여 단계(S912)는 환자가 병원에 내원하였다고 판단한 경우 대기 번호를 부여하는 동작을 의미할 수 있다. 대기 번호는 대상 정보, 시간 정보, 순서 정보, 긴급 정보 중 적어도 하나를 포함할 수 있다. 대상 정보는 진료병원, 진료과, 담당 의사 중 적어도 하나의 정보를 포함할 수 있다. 사용자는 대상 정보에 기초하여 어느 진료과의 어느 담당 의사의 대기 순서인지를 파악할 수 있다. 시간 정보는 대기 번호가 부여된 시간, 대기 예상 시간 정보 중 적어도 하나를 포함할 수 있다. 순서 정보는 현재 대기 순서와 관련된 정보를 의미할 수 있다. 긴급 정보는 현재 환자가 긴급한 환자인지 여부를 나타내는 정보를 의미할 수 있다. 만약, 순위가 늦은 환자라도 긴급 환자로 구분되는 경우 우선하여 진료할 수 있도록 하기 위함이다. 긴급 정보는 증상 정보, 환자의 요청, 병원 직원의 요청 중 적어도 하나에 기초하여 결정될 수 있다.
도 16은 위치 정보를 이용하여 대기 번호를 전송하는 실시 예를 설명하기 위한 도면이다.
일 실시 예에 따라, 사용자가 병원 예약을 확정한 경우, 사용자 단말 장치(100)는 예약 정보를 메모리에 저장할 수 있다. 그리고, 사용자 단말 장치(100)는 예약 정보에 포함된 예약 시간에 기초하여 GPS 기능을 활성화 시킬 수 있다. 그리고, 사용자 단말 장치(100)는 위치 정보를 병원 관리 서버(300)에 전송할 수 있다. 병원 관리 서버(300)는 위치 정보에 기초하여 사용자가 현재 병원 근처에 있는지 판단할 수 있다.
다른 실시 예에 따라, 사용자가 병원 예약을 하지 않은 경우, 사용자 단말 장치(100)는 사용자의 대기 번호 요청에 기초하여 위치 정보를 병원 관리 서버(300)에 전송할 수 있다. 병원 관리 서버(300)는 예약 정보가 없는 경우에도, 사용자 단말 장치(100)로부터 위치 정보가 수신되면 사용자가 현재 병원 근처에 있는지 판단할 수 있다.
특정 병원(1605)의 병원 관리 서버(300)가 사용자(1615)의 위치 정보가 병원 위치에서 임계 거리 이내(1610)(예를 들어, 100m)에 있다고 판단하면, 병원 관리 서버(300)는 사용자 단말 장치(100)에 대기 번호를 사용자 단말 장치(100)에 전송 할 수 있다. 병원 관리 서버(300)는 위치 정보에 기초하여 사용자(1615)의 위치 정보가 병원 위치에서 임계 거리 이상 떨어져 있다고 판단하면, 병원 관리 서버(300)는 대기 번호를 부여하지 않을 수 있다. 여기서, 병원 관리 서버(300)는 사용자 단말 장치(100)에 예약 취소 여부를 묻는 UI를 표시하도록 제어하는 신호를 사용자 단말 장치(100)에 전송할 수 있다. 병원 관리 서버(300)는 사용자의 응답이 없거나 예약 취소 명령을 수신하면, 예약을 취소할 수 있다.
도 17은 도 16의 실시 예의 구체적인 방법을 설명하기 위한 흐름도이다.
도 17을 참조하면, 환자가 병원 방문 예약을 확정한 실시 예를 가정한다. 병원 관리 서버(300)는 예약 시간의 임계 시간 이전부터 사용자 단말 장치(100)의 GPS 모듈을 제어할 수 있다 (S1705). 예를 들어, 예약 시간이 오후 2시이고 임계 시간이 15분이면, 병원 관리 서버(300)는 오후 1시 45분부터 사용자 단말 장치(100)의 GPS 모듈을 제어할 수 있다. 여기서, 사용자 단말 장치(100)의 GPS 모듈을 제어한다는 것은 병원 관리 서버(300)가 GPS 정보를 요청하는 제어 명령을 사용자 단말 장치(100)에 전송하는 것을 의미할 수 있다. 그리고, 사용자 단말 장치(100)는 GPS 정보를 요청하는 제어 명령을 수신하고, GPS 정보를 획득할 수 있으며, 획득된 GPS 정보를 병원 관리 서버(300)에 전송할 수 있다.
그리고, 병원 관리 서버(300)는 사용자 단말 장치(100)로부터 위치 정보를 획득할 수 있다 (S1710).
그리고, 병원 관리 서버(300)는 예약 시간 후 기 설정된 시간이 경과하였는지 판단할 수 있다 (S1715). 예를 들어, 예약 시간이 오후 2시이고 기 설정된 시간이 20분이면, 병원 관리 서버(300)는 오후 2시 20분이 경과하였는지 여부를 판단할 수 있다. 여기서, 예약 시간 후 기 설정된 시간이 경과하면, 병원 관리 서버(300)는 예약을 취소할 수 있다 (S1716). 예약 시간 후 기 설정된 시간이 경과하지 않으면, 병원 관리 서버(300)는 수신된 사용자 단말 장치(100)의 위치 정보가 예약된 병원의 위치 근처인지 판단할 수 있다 (S1720).
사용자 단말 장치(100)의 위치 정보가 예약된 병원의 위치 근처가 아니라고 판단되면, 병원 관리 서버(300)는 계속하여 사용자 단말 장치(100)로부터 위치 정보를 수신할 수 있다. 한편, 사용자 단말 장치(100)의 위치 정보가 예약된 병원의 위치 근처라고 판단되면, 병원 관리 서버(300)는 대기 번호를 생성할 수 있다 (S1725).
한편, 대기 번호를 생성하거나 대기 번호를 취소하는 경우, 사용자의 확인이 필요할 수 있다.
도 18은 순서 알림 정보를 전송하는 일 실시 예를 설명하기 위한 흐름도이다.
도 18을 참조하면, S1805, S1810, S1815, S1820, S1825, S1830, S1835, S1840, S1845, S1850, S1855, S1860, S1865, S1870 단계는 도 4의 S405, S410, S415, S420, S425, S430, S435, S440, S445, S450, S455, S460, S465, S470단계에 대응될 수 있다. 따라서, 중복되는 설명의 기재를 생략한다.
병원 관리 서버(300)는 S1850 단계에 기초하여 사용자 단말 장치(100)의 위치 정보가 병원 근처인지 판단할 수 있다. 그리고, 사용자 단말 장치(100)의 위치 정보가 병원 근처이면, 사용자 단말 장치(100)에 대기 번호를 할당할 수 있다. 그리고, 병원 관리 서버(300)는 현재 진료 순서가 사용자 단말 장치(100)에 할당된 대기 번호의 순서인지 판단할 수 있다 (S1875). 만약, 현재 진료 순서가 사용자 단말 장치(100)에 할당된 대기 번호의 순서가 아닌 경우, 병원 관리 서버(300)는 사용자 단말 장치(100)에 할당된 대기 번호의 순서가 올 때까지 계속 진료 순서를 모니터링 할 수 있다.
병원 관리 서버(300)는 S1850 단계에 기초하여, 사용자 단말 장치(100)의 위치 정보가 병원 근처이면, EMR 서버(400)로부터 최신 병록 번호를 수신(또는 동기화)할 수 있다. EMR 서버(400)에 저장된 병록 번호는 신뢰성이 높은 데이터 일 수 있다. 하지만, 매번 EMR 서버(400)에 병록 번호의 동기화를 시도하는 경우 실제로 내원하지 않는 환자들의 정보가 EMR 서버(400)에서 업데이트 될 수 있다. 이러한 상황에서 불필요한 EMR 서버(400)로의 접근을 방지하기 위하여, 병원 관리 서버(300)는 사용자 단말 장치(100)의 위치 정보가 병원 근처인 경우에 한하여, 최신 병록 번호를 EMR 서버(400)로부터 수신할 수 있다.
한편, 사용자 단말 장치(100)에 할당된 대기 번호의 순서가 도래한 경우, 병원 관리 서버(300)는 사용자 단말 장치(100)에 순서 알림 정보를 제공할 수 있다 (S1880). 또한, 사용자 단말 장치(100)는 수신한 순서 알림 정보를 디스플레이에 표시할 수 있다 (S1885).
도 19는 순서 알림 정보를 전송하는 다른 실시 예를 설명하기 위한 흐름도이다.
도 19를 참조하면, S1905, S1910, S1915, S1920, S1925, S1930, S1935, S1940, S1945, S1950, S1955, S1960, S1965, S1975, S1980 단계는 도 8의 S805, S810, S815, S820, S825, S830, S835, S840, S845, S850, S855, S860, S865, S875, S880 단계에 대응될 수 있다. 따라서, 중복되는 설명의 기재를 생략한다.
접수 관리 서버(500)는 S1955 단계에 기초하여 사용자 단말 장치(100)의 위치 정보가 병원 근처인지 판단할 수 있다. 그리고, 사용자 단말 장치(100)의 위치 정보가 병원 근처이면, 사용자 단말 장치(100)에 대기 번호를 할당할 수 있다. 그리고, 접수 관리 서버(500)는 현재 진료 순서가 사용자 단말 장치(100)에 할당된 대기 번호의 순서인지 판단할 수 있다 (S1985). 만약, 현재 진료 순서가 사용자 단말 장치(100)에 할당된 대기 번호의 순서가 아닌 경우, 접수 관리 서버(500)는 사용자 단말 장치(100)에 할당된 대기 번호의 순서가 올 때까지 계속 진료 순서를 모니터링 할 수 있다.
한편, 사용자 단말 장치(100)에 할당된 대기 번호의 순서가 도래한 경우, 접수 관리 서버(500)는 사용자 단말 장치(100)에 순서 알림 정보를 제공할 수 있다 (S1990). 또한, 사용자 단말 장치(100)는 수신한 순서 알림 정보를 디스플레이에 표시할 수 있다 (S1995).
도 20은 환자를 관리하는 복수의 단계 중 진료 단계를 설명하기 위한 흐름도이다.
도 20을 참조하면, 진료 단계 (S920)는 환자 정보를 수신하는 단계 (S921), 대기자 정보를 수신하는 단계 (S922), 환자 정보 및 대기자 정보를 맵핑하는 단계 (S923)를 포함할 수 있다.
환자 정보를 수신하는 단계 (S921)는 애플리케이션 서버(200)로부터 수신한 식별 정보에 대응되는 환자에 대한 정보를 획득하는 것을 의미할 수 있다. 예를 들어, 병원 관리 서버(300)는 애플리케이션 서버(200)로부터 식별 정보(이름: 홍길동, 생년월일: 90년 1월 1일)를 수신하고, 식별 정보에 대응되는 환자 정보를 병원 관리 서버(300)의 내부 데이터베이스 또는 EMR 서버(400)로부터 획득할 수 있다. 환자가 재진인 경우, 병원 관리 서버(300)는 기 저장된 환자 정보를 획득할 수 있다. 환자가 신환(신규 환자)인 경우, 병원 관리 서버(300)는 새로운 환자 정보를 획득할 있다.
대기자 정보를 수신하는 단계 (S922)는 사용자 단말 장치(100)로부터 증상 정보 및 대기 번호를 수신하는 동작을 의미할 수 있다. 대기자 정보는 환자의 증상 정보 및 대기 번호가 포함될 수 있다. 증상 정보는 사용자 단말 장치(100)의 사용자 인터페이스(150)에 의해 입력된 정보일 수 있으며, 대기 번호는 병원 관리 서버(300) 또는 접수 관리 서버(500)로부터 획득한 정보일 수 있다. 한편, 병원 관리 서버(300)가 대기자 정보에 포함된 대기 번호 및 증상 정보를 함께 수신하는 것으로 기재하였지만, 실제 구현 시 대기 번호와 증상 정보를 다른 시점에 수신하는 형태로 구현될 수 있다. 여기서, 증상 정보는 다양한 통신 방식에 의하여 병원 관리 서버(300)에 전송될 수 있다. 일 예로, 증상 정보는 근거리 무선 통신 (예를 들어, NFC 통신)에 기초하여 병원 관리 서버(300)에 전송될 수 있다.
병원 관리 서버(300)는 수신된 증상 정보와 대기 번호를 결합할 수 있다. 여기서, 결합의 의미는 증상 정보와 대기 번호를 하나의 데이터 그룹으로 그룹핑하는 동작을 의미할 수 있다. 즉, 병원 관리 서버(300)는 복수의 단말 장치로부터 복수의 증상 정보를 수신할 수 있다. 여기서, 병원 관리 서버(300)는 복수의 증상 정보가 어느 환자에 대응되는 것인지 식별할 필요성이 있는데, 병원 관리 서버(300)는 환자의 이름대신 대기 번호를 기준으로 식별할 수 있다. 예를 들어, 병원 관리 서버(300)는 대기 번호(#005)와 증상 정보(손목 저림)를 하나의 데이터 그룹(대기자 정보)로 그룹핑하여 병원 관리 서버(300)의 메모리에 저장할 수 있다. 그리고, 병원 관리 서버(300)는 그룹핑된 대기자 정보를 병원 관리 서버(300)에 연결된 디스플레이 장치(600)에 전송할 수 있다. 여기서, 디스플레이 장치(600)는 담당 의사의 PC일 수 있다.
환자 정보 및 대기자 정보를 맵핑하는 단계 (S923)는 대기자 정보에 대응되는 환자 정보를 식별하는 동작을 의미할 수 있다. 병원 관리 서버(300)는 복수의 환자 정보를 저장하고 있을 수 있으며, 현재 적어도 진료를 기다리고 있는 복수의 환자 정보를 식별할 수 있다. 환자 정보에는 개인 식별 정보가 포함되어 있으므로, 복수의 환자 중 어느 환자에 대응되는 정보인지 쉽게 식별할 수 있다. 하지만, 대기자 정보는 대기 번호 및 증상 정보로 구성되어 있다는 측면에서, 대기자 정보가 어느 환자에 대응되는 정보인지 쉽게 식별하기 어려울 수 있다. 병원 관리 서버(300)는 대기자 정보가 어느 환자에 대한 정보인지 판단하는 동작을 수행할 수 있다. 다양한 맵핑 동작에 대해서는 도 21 내지 도 24에서 구체적으로 기술한다.
도 21은 환자 정보와 대기자 정보를 맵핑하는 일 실시 예를 설명하기 위한 도면이다.
도21을 참조하면, S2105, S2110, S2115, S2120, S2125, S2130, S2135, S2140, S2145, S2150, S2155, S2160, S2165 단계는 도 4의 S405, S410, S415, S420, S425, S430, S435, S440, S445, S450, S455, S460, S465 단계와 대응될 수 있다. 따라서, 중복되는 설명의 기재를 생략한다.
사용자 단말 장치(100)는 병원 관리 서버(300)로부터 대기 번호를 수신할 수 있으며, 수신된 대기 번호를 디스플레이에 표시할 수 있다. 그리고, 사용자 단말 장치(100)는 수신된 대기 번호를 애플리케이션 서버(200)에 전송할 수 있다 (S2170). 또한, 애플리케이션 서버(200)는 기 저장된 식별 정보와 수신된 대기 번호를 결합할 수 있다 (S2175). 여기서, 결합한다는 의미는 식별 정보와 대기 번호를 하나의 데이터 그룹으로 그룹핑하는 것을 의미할 수 있다. 또한, 애플리케이션 서버(200)는 결합된 식별 정보 및 대기 번호를 병원 관리 서버(300)에 전송할 수 있다(S2180). 또한, 병원 관리 서버(300)는 결합된 식별 정보 및 대기 번호에 기초하여 환자 정보와 대기자 정보를 맵핑할 수 있다 (S2185). 맵핑 동작의 과정에 대해서는 도 22에서 구체적으로 후술한다. 한편, 애플리케이션 서버(200)에서 결합 동작이 수행되는 경우, 사용자의 동의가 필요할 수 있다. 여기서, 사용자 동의와 관련된 처리 동작은 사용자 단말 장치(100)를 통해 수신될 수 있다.
도 22는 도 21의 실시 예에서 전송되는 정보를 구체적으로 설명하기 위한 도면이다.
도 22를 참조하면, 사용자 단말 장치(100)는 애플리케이션 서버(200)에 예약 요청 및 식별 정보(2205)를 전송할 수 있다(S2105). 예를 들어, 식별 정보(2205)는 “홍길동”과 같은 환자 이름일 수 있다. 애플리케이션 서버(200)는 수신된 식별 정보(2205)를 병원 관리 서버(300)에 전송할 수 있다(S2110).
또한, 병원 관리 서버(300)는 수신된 식별 정보(2210)에 기초하여 예약 정보를 생성할 수 있다. 또한, 병원 관리 서버(300)는 예약 정보에 대응되는 환자 정보(2220)를 생성할 수 있다(S2120). 여기서, 환자 정보(2220)는 식별 정보(예를 들어, 홍길동), 나이(예를 들어, 30), 성별(예를 들어, 남), 초진/재진 여부(예를 들어, 초진) 중 적어도 하나를 포함할 수 있다. 여기서, 초진/재진 여부는 신환/재진 여부로 변경되어 실시 될 수 있다.
또한, 사용자 단말 장치(100)는 사용자 단말 장치(100)로부터 대기 번호 요청 및 증상 정보(2245)를 병원 관리 서버(300)에 전송할 수 있다 (S2145). 여기서, 증상 정보(2245)는 “손목 저림”과 같은 신체 일부분과 증상에 대한 내용을 포함할 수 있다.
한편, 병원 관리 서버(300)는 환자의 병원 방문 여부를 판단하여 대기 번호를 부여할 수 있다. 또한, 병원 관리 서버(300)는 대기 번호 및 증상 정보를 결합하여 대기자 정보(2255)를 생성할 수 있다 (S2155). 여기서, 대기자 정보(2255)는 대기 번호 (예를 들어, #005) 및 증상 정보 (예를 들어, 손목 저림)를 포함할 수 있다.
또한, 병원 관리 서버(300)는 사용자 단말 장치(100)에 대기 번호(2260)를 전송할 수 있다 (S2160). 그리고, 사용자 단말 장치(100)는 애플리케이션 서버(200)에 대기 번호(2260)를 전송할 수 있다.
애플리케이션 서버(200)는 식별 정보(또는 식별 정보 중 일부 정보) 및 대기 번호를 결합하여 맵핑 기준 데이터 그룹(2275)를 생성할 수 있다 (S2175). 또한, 애플리케이션 서버(200)는 생성된 맵핑 기준 데이터 그룹(2275)을 병원 관리 서버(300)에 전송할 수 있다 (S2180). 맵핑 기준 데이터 그룹이란 맵핑 동작에 이용되어 기준 정보로 이용하는 데이터 그룹을 의미할 수 있다.
또한, 병원 관리 서버(300)는 환자 정보(2220) 및 대기자 정보(2255)를 맵핑할 수 있다. 병원 관리 서버(300)는 복수의 환자 정보와 복수의 대기자 정보를 메모리에 저장하고 있을 수 있다.
맵핑 동작에 있어서, 병원 관리 서버(300)는 애플리케이션 서버(200)로부터 수신한 데이터 그룹(2275)을 이용할 수 있다. 병원 관리 서버(300)는 데이터 그룹(2275)에 포함된 대기 번호(#005)를 획득하고, 복수의 대기자 정보에서 획득된 대기 번호(#005)에 대응되는 대기자 정보(2255)를 획득할 수 있다. 그리고, 병원 관리 서버(300)는 데이터 그룹(2275)에 포함된 식별 정보(홍길동)를 획득하고 복수의 환자 정보 중에서 획득된 식별 정보(홍길동)에 대응되는 환자 정보(2220)를 획득할 수 있다. 그리고, 병원 관리 서버(300)는 획득된 대기자 정보(2255)와 획득된 환자 정보(2220)를 맵핑하여 새로운 맵핑 결과 데이터 그룹(2285)을 생성할 수 있다. 여기서, 맵핑 결과 데이터 그룹(2285)은 대기 번호(#005), 식별 정보(홍길동), 나이(30), 성별(남), 신환 및 재진 여부(신환), 증상 정보(손목 저림) 중 적어도 하나를 포함할 수 있다.
도 22에 따른 병원 진료 시스템(1000)에서는 증상 정보가 애플리케이션 서버(200)에 거치지 않고 병원 관리 서버(300)에 전송되었다. 그리고, 증상 정보가 대기 번호와 결합되었음에도 불구하고 맵핑 기준 데이터 그룹(2275)에 기초하여 증상 정보에 대응되는 환자 정보(2220)를 획득할 수 있다. 따라서, 본 개시의 병원 진료 시스템(1000)에서는 애플리케이션 서버(200)가 해킹을 당해도 증상 정보가 유출되지 않을 수 있다.
도 23은 환자 정보와 대기자 정보를 맵핑하는 다른 실시 예를 설명하기 위한 도면이다.
도 23을 참조하면, S2305, S2310, S2315, S2320, S2325, S2330, S2335, S2340, S2345, S2350, S2355, S2360, S2365 단계는 도 4의 S405, S410, S415, S420, S425, S430, S435, S440, S445, S450, S455, S460, S465 단계와 대응될 수 있다. 따라서, 중복되는 설명의 기재를 생략한다.
사용자 단말 장치(100)는 병원 관리 서버(300)로부터 대기 번호를 수신하여 디스플레이에 표시할 수 있다. 여기서, 사용자 단말 장치(100)는 수신된 대기 번호와 내부 메모리에 기 저장된 식별 정보를 결합하여 맵핑 기준 데이터 그룹을 생성할 수 있다 (S2370). 도 21 및 도 22에서는 대기 번호와 식별 정보를 결합하는 동작이 애플리케이션 서버(200)에서 이루어지는 실시 예에 대해서 기술하였다. 하지만, 실시 예에 따라 대기 번호와 식별정보를 결합하는 동작은 사용자 단말 장치(100)에서 수행될 수 있다. 식별 정보는 사용자 단말 장치(100) 및 애플리케이션 서버(200) 모두에 저장되어 있을 수 있기 때문이다. 한편, 사용자 단말 장치(100)에서 결합 동작이 수행되는 경우, 사용자의 동의가 필요할 수 있다.
사용자 단말 장치(100)는 결합된 식별 정보 및 대기 번호(S2370 단계에서 생성한 맵핑 기준 데이터 그룹)을 병원 관리 서버(300)에 전송할 수 있다 (S2375). 또한, 병원 관리 서버(300)는 결합된 식별 정보 및 대기 번호에 기초하여 환자 정보 및 대기자 정보를 맵핑하여 맵핑 결과 데이터 그룹을 생성할 수 있다 (S2380). 맵핑 동작에 대해서는 도 22에서 구체적으로 기술 하였는 바 중복되는 설명은 생략한다.
도 21 내지 도 23은 병원 관리 서버(300)에서 환자 정보와 대기자 정보를 맵핑 기준 데이터 그룹을 이용하여 자동으로 맵핑하는 실시 예를 기술하였다. 하지만 다른 실시 예에 따라 환자 정보와 대기자 정보가 별도의 맵핑 기준 데이터 그룹을 이용하지 않고 담당 의사에 의하여 직접 맵핑될 수 있다. 담당 의사에 의하여 직접 맵핑되는 실시 예에 관해 도 24에서 기술한다.
도 24는 환자 정보와 대기자 정보를 맵핑하는 또 다른 실시 예를 설명하기 위한 도면이다.
도 24를 참조하면, 병원 관리 서버(300)는 디스플레이 장치(600)와 연결될 수 있다. 디스플레이 장치(600)는 병원 관리 서버(300)로부터 환자 정보 및 대기자 정보를 수신할 수 있다. 여기서, 환자 정보는 병원 관리 서버(300)로부터 수신되는 형태로 기재하였다. 다만, 실시 예에 따라 디스플레이 장치(600)는 환자 정보를 EMR 서버(400)로부터 직접 수신할 수 있다.
그리고, 디스플레이 장치(600)는 수신된 환자 정보 및 대기자 정보를 동시에 하나의 화면에 표시할 수 있다. 구체적으로, 디스플레이 장치(600)는 하나의 화면 중 제1 영역(2405)에 환자 정보를 표시할 수 있고, 하나의 화면 중 제1 영역(2405)과 다른 제2 영역(2410)에 대기자 정보를 표시할 수 있다.
여기서, 디스플레이 장치(600)는 병원 관리 서버(300)로부터 복수의 환자 정보를 수신할 수 있다. 현재 병원에 접수 완료 되어 내원 중인 환자들에 대응되는 복수의 환자 정보가 병원 관리 서버(300)로부터 수신되면, 디스플레이 장치(600)는 복수의 환자 정보에 포함된 식별 정보 중 이름 정보를 제1 영역(2405)에 표시할 수 있다. 제1 영역에 표시되는 환자 정보는 복수 개일 수 있지만, 제2 영역(2410)에 표시되는 대기자 정보는 하나일 수 있다. 병원 관리 서버(300)는 접수 순서 또는 진료 순서 중 적어도 하나에 기초하여 대기 번호를 부여할 수 있으며, 접수 순서 또는 진료 순서 중 적어도 하나에 대응되는 대기 번호는 하나일 수 있다. 따라서, 병원 관리 서버(300)가 디스플레이 장치(600)에 전송하는 대기자 정보는 하나일 수 있다. 따라서, 디스플레이 장치(600)의 제2 영역(2410)에 표시되는 대기자 정보는 하나일 수 있다.
담당 의사는 디스플레이 장치(600)에 표시되는 대기자 정보와 환자 정보를 직접 맵핑할 수 있다. 복수의 환자 정보 중 어느 환자 정보가 대기자 정보에 대응되는지 담당 의사가 직접 판단할 수 있다. 담당 의사는 환자의 얼굴 기억하거나, 환자에게 직접 이름, 생년 월일 또는 증상 정보를 재차 묻는 형태로 식별 정보를 알 수 있고, 직접 환자 정보와 대기자 정보를 맵핑할 수 있다.
도 25는 증상 정보를 동기화하는 일 실시 예를 설명하기 위한 도면이다.
도 25를 참조하면, 디스플레이 장치(600)는 병원 관리 서버(300)로부터 맵핑 동작(S2185)에 기초하여 하나의 환자 정보와 하나의 대기자 정보를 획득할 수 있다. 도 22에서는 맵핑 결과 데이터 그룹(2285)을 생성하는 것으로 기재하였으나 이는 일 실시 예에 따른 동작에 불과하며, 맵핑 동작은 새로운 데이터 그룹을 생성하는 것이 아닌 단순히 특정 환자 정보와 특정 대기자 정보를 맵핑하는 것만을 의미할 수도 있다. 도 25에서는 특정 환자 정보와 특정 대기자 정보가 맵핑된 상태만을 가정한 실시 예를 기술한다.
디스플레이 장치(600)는 병원 관리 서버(300)로부터 진료 순서에 대응되는 대기자 정보를 수신하고 수신된 대기자 정보를 제2 영역(2410)에 표시할 수 있다. 그리고, 디스플레이 장치(600)는 대기자 정보와 맵핑된 환자 정보를 병원 관리 서버(300)로부터 수신하고, 수신된 환자 정보를 제1 영역(2405)에 표시할 수 있다.
여기서, 증상 정보는 대기자 정보에만 포함되어 있으므로, 제2 영역(2410)에만 증상 정보가 표시될 수 있다. 여기서, 디스플레이 장치(600)는 UI (2505) 또는 UI (2510) 중 적어도 하나의 UI를 표시할 수 있다. UI (2505)는 환자 정보 및 대기자 정보 상호간에 동기화 대상 항목들을 모두 동기화 시키는 기능에 대응되는 UI일 수 있다. 디스플레이 장치(600)가 UI (2505)를 선택하는 사용자 입력을 수신하면, 디스플레이 장치(600)는 동기화 대상 항목들에 대하여 동기화 동작들을 수행할 수 있다. 도 25에서 동기화 항목은 증상 정보일 수 있다. 도 25에서 개시하는 실시 예에서 동기화 우선 순위는 대기자 정보에 있을 수 있다. 즉, 환자 정보의 증상 정보는 데이터가 존재하지 않고, 대기자 정보의 증상 정보에는 데이터가 존재하므로, 대기자 정보의 증상 정보(왼팔 손목 저림)를 환자 정보에도 포함시킬 수 있다. 그리고, 디스플레이 장치(600)는 환자 정보에 포함된 증상 정보(왼팔 손목 저림)를 제1 영역(2405)에 표시할 수 있다.
한편, UI(2510)는 모든 동기화 항목들이 아닌 특정 항목만을 동기화하는 기능에 대응되는 UI일 수 있다. 도 25에서는 동기화 항목이 증상 정보 하나인 것으로 도시하였지만 실제 구현 시 동기화 항목이 복수 개일 수 있다. UI(2510)는 복수의 동기화 항목 중 특정 항목(증상 정보)을 동기화하는 기능에 대응되는 UI일 수 있다.
도 26은 증상 정보를 동기화하는 다른 실시 예를 설명하기 위한 도면이다.
도 26을 참조하면, 디스플레이 장치(600)는 대기자 정보에 포함된 증상 정보를 동기화 시키는 UI (2605)를 표시할 수 있다. UI(2605)가 사용자에 의해 선택되면, 디스플레이 장치(600)는 대기자 정보에 포함된 증상 정보를 분석할 수 있다. 구체적으로, 디스플레이 장치(600)는 증상 정보의 텍스트를 분석하여 신체 정보 및 통증 정보로 구분할 수 있다. 예를 들어, 증상 정보가 “왼팔 손목 저림”이면 디스플레이 장치(600)는 증상 정보에 기초하여 신체 정보(왼팔 손목) 및 통증 정보(저림)를 획득할 수 있다. 디스플레이 장치(600)는 획득한 신체 정보 및 통증 정보에 기초하여 인체 모형의 UI (2610)를 표시할 수 있다. 구체적으로, 인체 모형의 UI (2610)에 획득한 신체 정보(왼쪽 손목)의 위치를 쉽게 알 수 있도록 강조 UI (2615)를 표시할 수 있다. 또한, 해당 위치 근처에 획득한 통증 정보(저림)를 표시할 수 있다. 한편, 디스플레이 장치(600)는 획득한 통증 정보(저림)를 의학 용어(수근관 증후군)로 변환하여 표시할 수 있다. 의학 용어로 변경하는 동작은 신체 정보 및 통증 정보가 모두 고려될 수 있다.
도 27은 환자를 관리하는 복수의 단계 중 처방 단계를 설명하기 위한 흐름도이다.
도 27을 참조하면, 처방 단계(S930)는 처방 정보를 입력하는 단계(S931) 및 처방 정보 및 서비스 정보를 전송하는 단계(S932)를 포함할 수 있다.
처방 정보를 입력하는 단계(S931)는 병원 관리 서버(300)가 담당 의사의 처방 정보를 수신하는 단계를 의미할 수 있다. 담당 의사는 병원 관리 서버(300)에 환자를 진찰한 이후 처방 정보를 입력할 수 있다. 예를 들어, 병원 관리 서버(300)에 연결된 디스플레이 장치(600)에 환자 정보 및 대기자 정보가 표시되어 있다고 가정한다. 담당 의사는 디스플레이 장치(600)에 표시된 환자 정보, 대기자 정보 및 진찰 과정을 통해 획득한 정보를 종합하여 어떠한 처방을 내릴지 결정할 수 있다. 그리고, 디스플레이 장치(600)에 연결된 사용자 인터페이스를 통해 처방 결과를 디스플레이 장치(600)에 입력할 수 있다. 처방 결과에 한 정보(처방 정보로 후술)는 디스플레이 장치(600)의 메모리에 저장될 수 있다. 그리고, 디스플레이 장치(600)는 저장된 처방 정보를 병원 관리 서버(300)에 전송할 수 있다.
처방 정보 또는 서비스 정보 중 적어도 하나의 정보를 전송하는 단계(S932)는 담당 의사가 입력한 처방 정보를 외부에 전송하는 동작을 의미할 수 있다. 병원 관리 서버(300)는 수신된 처방 정보를 EMR 서버(400) 또는 사용자 단말 장치(100)에 전송할 수 있다. EMR 서버(400)는 처방 정보를 포함하는 환자 정보를 병원 관리 서버(300)로부터 수신하면, 새로운 환자 진찰 내용을 환자 병록 번호에 기록 및 업데이트할 수 있다. EMR 서버(400)에는 환자 정보가 넘어가지만, 사용자 단말 장치(100)에는 환자 정보에 포함된 모든 정보를 전송하지 않을 수 있으며, 사용자 단말 장치(100)에는 처방 정보 또는 서비스 정보 중 적어도 하나를 전송할 수 있다.
여기서, 서비스 정보란 환자가 숙지 해야할 주의 사항을 의미할 수 있다. 예를 들어, 서비스 정보는 피해야할 음식, 피해야할 운동 종류, 처방약 복용량, 처방약 복용시간, 예약 정보, 병원 방문 추천 날짜 등을 포함할 수 있다. 병원 방문 예약 여부는 진찰 과정에서 다음 병원 방문에 대한 예약 시간을 결정한 경우, 그에 대한 결과를 다시 한번 환자에게 통지하는 것을 의미할 수 있다. 그리고, 병원 방문 추천 날짜는 병원 방문에 대한 예약을 하지는 않았지만 언제쯤 병원에 방문할 것인지 권유하는 날짜를 의미할 수 있다. 일 예로, 병원 관리 서버(300)는 “2~3일 후 내원 방문 권유”라는 서비스 정보를 사용자 단말 장치(100)에 전송할 수 있다.
한편, 병원 관리 서버(300)가 사용자 단말 장치(100)에 처방 정보 또는 서비스 정보 중 적어도 하나를 사용자 단말 장치(100)에 전송하기 위하여 처방 정보와 대기 번호를 결합할 수 있다. 여기서, 결합하는 동작은 처방 정보와 대기 번호를 하나의 데이터 그룹으로 그룹핑하는 것을 의미할 수 있다. 그리고, 처방 정보와 대기 번호를 결합하는 것은 대기자 정보에 처방 정보를 추가하는 것을 의미할 수 있다.
처방 정보와 식별 정보를 결합하지 않고 처방 정보와 대기 번호를 결합하는 이유는 처방 정보가 해킹 당해도 누구의 처방 정보인지 알기 어렵도록 하기 위함이다. 일반적으로, 진료 후 EMR 서버(400)에 전송되는 환자 정보는 식별 정보 및 처방 정보가 하나의 데이터 그룹으로 그룹핑되어 저장될 수 있다. 하지만, EMR 서버(400)는 병원 내부 시스템에서 저장되어 있을 뿐이며 별도의 보안 프로그램이 작동한다는 점에서 안정성이 확보되어 있을 수 있다. 하지만, 사용자 단말 장치(100)에 특정 정보를 전송하는 것은 내부 시스템이 아닌 외부 시스템으로 정보를 전송하는 것이라는 측면에서 보안 위협이 있을 수 있다.
따라서, 이러한 보안 위협을 방지하기 위하여 병원 관리 서버(300)는 처방 정보와 식별 정보를 결합하지 않고 처방 정보와 대기 번호를 결합할 수 있다. 대기자 정보에는 식별 정보가 존재하지 않고 단순히 대기 번호를 부여한 사용자 단말 장치(100)에 대한 정보만이 포함될 수 있다.
한편, 병원 관리 서버(300)는 대기 번호를 사용자 단말 장치(100)에 전송하는 단계에서 부여된 대기 번호와 사용자 단말 장치(100)를 맵핑할 수 있고, 맵핑된 대기 번호 및 사용자 단말 장치(100)를 병원 관리 서버(300)의 메모리에 저장할 수 있다. 병원 관리 서버(300)는 맵핑된 대기 번호 및 사용자 단말 장치(100)에 기초하여 사용자 단말 장치(100)에 대기자 정보에 포함된 처방 정보를 선택적으로 전송할 수 있다. 또한, 병원 관리 서버(300)는 처방 정보 이외에 서비스 정보도 함께 사용자 단말 장치(100)에 전송할 수 있다.
한편, 처방 단계(S930)는 제1 처방 정보와 제2 처방 정보로 구분될 수 있다.
제1 처방 정보는 환자가 결제하기 전 단계에서 생성된 최초의 처방 정보를 의미할 수 있고, 제2 처방 정보는 환자가 결제한 이후 단계에서 생성된 처방 정보를 의미할 수 있다.
병원 관리 서버(300)는 제1 처방 정보 및 결제와 관련된 정보를 사용자 단말 장치(100)에 전송할 수 있다. 그리고, 환자는 수신된 제1 처방 정보 및 결제와 관련된 정보에 기초하여 결재를 진행할 수 있다. 여기서, 제1 처방 정보는 대기 번호와 결합되어 사용자 단말 장치(100)에 전송될 수 있다.
환자가 사용자 단말 장치(100)에서 결제를 완료한 경우, 사용자 단말 장치(100)는 결제가 완료되었다는 정보를 병원 관리 서버(300)에 전송할 수 있다. 한편, 다른 실시 예에 따라, 사용자 단말 장치(100)는 애플리케이션 서버(200)를 통해 병원 관리 서버(300)에 결제 완료 정보를 전송할 수 있다.
병원 관리 서버(300)는 결제 완료 정보를 수신하고, 제2 처방 정보를 생성할 수 있다. 그리고, 병원 관리 서버(300)는 최종적으로 제2 처방 정보를 사용자 단말 장치(100)에 전송할 수 있다. 여기서, 제2 처방 정보는 대기 번호와 결합되어 사용자 단말 장치(100)에 전송될 수 있다. 그리고, 병원 관리 서버(300)는 제2 처방 정보 및 제2 처방 정보에 대응되는 서비스 정보를 사용자 단말 장치(100)에 전송할 수 있다.
예를 들어, 제1 처방 정보는 주사, 약물 치료 및 물리치료라고 가정한다. 여기서, 병원 관리 서버(300)는 제1 처방 정보를 사용자 단말 장치(100)에 전송할 수 있다.
한편, 환자가 병원으로부터 임계 거리 이상 멀어지거나 기 설정된 시점(진료 완료 시점, 결제 완료 시점 또는 환자가 병원으로부터 임계 거리 이상 멀어진 시점) 후 임계 시간 이상의 경우, 병원 관리 서버(300)는 처방 정보 또는 서비스 정보를 사용자 단말 장치(100)에 전송할 수 있다.
도 28은 처방 정보를 전송하는 단계를 설명하기 위한 도면이다.
도 28을 참조하면, 병원 관리 서버(300)는 결합된 식별 정보 및 대기 번호에 기초하여 환자 정보 및 대기자 정보를 맵핑할 수 있다 (S2805). 환자 정보 및 대기자 정보를 맵핑하는 동작은 도 21 내지 도 24에서 기재 하였으므로 중복 설명을 생략한다.
병원 관리 서버(300)는 환자 정보 및 대기자 정보를 맵핑한 이후에 처방 정보를 수신할 수 있다(S2810). 병원 관리 서버(300)는 수신된 처방 정보와 대기 번호를 결합할 수 있다 (S2815). 여기서, 처방 정보와 대기 번호를 결합하는 것은 대기자 정보에 처방 정보를 추가하여 하나의 데이터 그룹을 생성하는 것을 의미할 수 있다. 여기서, 생성되는 데이터 그룹은 변경된 대기자 정보일 수 있다. 변경된 대기자 정보에는 처방 정보, 대기 번호가 포함될 수 있다. 병원 관리 서버(300)는 변경된 대기자 정보에 기초하여 대기 번호에 대응되는 사용자 단말 장치(100)를 식별할 수 있다 (S2820). 그리고, 병원 관리 서버(300)는 식별된 사용자 단말 장치(100)에 처방 정보를 전송할 수 있다 (S2825). 한편, S2825 단계와 다른 실시 예에 따라, 병원 관리 서버(300)는 처방 정보를 애플리케이션 서버(200)에 전송하고, 애플리케이션 서버(200)에서 사용자 단말 장치(100)에 처방 정보를 전송하는 형태로 구현될 수 있다. 또한, 병원 관리 서버(300)는 결합된 처방 정보 및 대기 번호를 임계 시간이 경과한 이후 삭제할 수 있다 (S2830). 환자의 진료 기록과 관련해서는 환자 정보가 별도로 저장되어 있으므로, 병원 관리 서버(300)는 결합된 처방 정보 및 대기 번호를 계속하여 메모리에 저장할 필요가 없을 수 있다. 한편, S2830에서는 임계 시간이 경과한 이후 처방 정보가 삭제되는 것으로 기재하였지만, 구현 예에 따라, 병원 관리 서버(300)는 처방 정보를 사용자 단말 장치(100)에 전송한 이후 바로 결합된 처방 정보 및 대기 번호를 삭제할 수 있다.
한편, 대기 번호는 날짜 정보를 추가적으로 포함할 수 있다. 병원 관리 서버(300)는 대기 번호에 포함된 날짜 정보가 현재 병원 관리 서버(300)에서 식별되는 날짜 정보를 비교할 수 있다. 여기서, 대기 번호에 포함된 날짜 정보가 현재 병원 관리 서버(300)의 날짜보다 이전이면, 병원 관리 서버(300)는 대기 번호를 삭제할 수 있다.
한편, 도 28에서는 병원 관리 서버(300)가 처방 정보, 환자 정보, 대기자 정보를 저장하고 관리하는 도 3 및 도 4의 실시 예를 기초로 기술하였다. 하지만, 실시 예에 따라 도 5 내지 도 8의 실시 예에도 처방 정보와 관련된 동작이 적용될 수 있다.
구체적으로, 환자 진료 시스템(1000)이 사용자 단말 장치(100), 애플리케이션 서버(200), 병원 관리 서버(300), EMR 서버(400), 접수 관리 서버(500) 및 디스플레이 장치(600)를 포함할 수 있다.
여기서, 디스플레이 장치(600)는 병원 관리 서버(300)에 연결된 장치를 의미할 수 있으며, 담당 의사가 관리하는 장치를 의미할 수 있다. 그리고, 디스플레이 장치(600)는 사용자 인터페이스(예를 들어, 키보드 및 마우스 등)를 추가로 포함할 수 있으며, 사용자 인터페이스를 통해 담당 의사의 처방 정보를 수신할 수 있다. 여기서, 디스플레이 장치(600)는 수신된 처방 정보를 환자 정보 및 대기자 정보에 추가할 수 있다. 기존 환자 정보 및 대기자 정보에는 처방 정보가 입력되어 있지 않았지만, 디스플레이 장치(600)는 수신된 처방 정보를 각각 환자 정보 및 대기자 정보에 추가할 수 있다. 결국, 환자 정보 및 대기자 정보는 처방 정보가 추가되어 변경될 수 있다. 처방 정보가 추가된 이후의 환자 정보 및 대기자 정보를 변경된 환자 정보 및 변경된 대기자 정보로 기술한다. 변경된 환자 정보에는 환자의 증상 정보, 환자의 처방 정보, 환자의 식별 정보 중 적어도 하나가 포함될 수 있다. 또한, 변경된 대기자 정보에는 환자의 증상 정보, 환자의 대기 번호, 환자의 처방 정보 중 적어도 하나가 포함될 수 있다. 변경된 대기자 정보는 도 28의 S2815 단계에 대응될 수 있다.
디스플레이 장치(600)는 변경된 환자 정보 및 변경된 대기자 정보를 병원 관리 서버(300)에 전송할 수 있다. 병원 관리 서버(300)는 변경된 환자 정보를 EMR 서버(400)에 전송할 수 있다. EMR 서버(400)는 업데이트된 환자 정보를 메모리에 저장할 수 있다.
한편, 병원 관리 서버(300)는 접수 관리 서버(500)에 변경된 대기자 정보를 전송할 수 있다. 접수 관리 서버(500)는 변경된 대기자 정보를 수신할 수 있으며, 변경된 대기자 정보에서 대기 번호를 식별할 수 있다. 그리고, 접수 관리 서버(500)는 대기 번호에 대응되는 사용자 단말 장치를 식별할 수 있다. 접수 관리 서버(500)는 대기 번호를 부여하는 단계에서 대기 번호와 사용자 단말 장치를 맵핑하는 기기 정보를 생성하여 메모리에 저장할 수 있다. 접수 관리 서버(500)는 복수의 기기 정보에서 변경된 대기자 정보에서 식별된 대기 번호에 대응되는 사용자 단말 장치(100)를 식별할 수 있다. 그리고, 식별된 사용자 단말 장치(100)에 변경된 대기자 정보에 포함된 처방 정보를 전송할 수 있다.
도 29는 처방 정보를 동기화하는 일 실시 예를 설명하기 위한 도면이다.
도 29를 참조하면, 디스플레이 장치(600)는 처방 정보를 동기화 시키는 UI(2905)를 표시할 수 있다. 디스플레이 장치(600)가 담당 의사의 처방 정보를 수신하면, 디스플레이 장치(600)는 수신된 처방 정보를 제1 영역(2405)에 표시할 수 있다. 그리고, 디스플레이 장치(600)는 UI(2905)를 선택하는 담당 의사의 입력이 수신되면, 제1 영역(2405)에 표시된 처방 정보를 제2 영역(2410)에 표시할 수 있다.
또한, 디스플레이 장치(600)는 처방 정보만을 동기화하는 UI(2910)를 제2 영역(2410)에 표시할 수 있다. 디스플레이 장치(600)는 UI (2910)를 선택하는 담당 의사의 입력이 수신되면, 제1 영역(2405)에 표시된 모든 처방 정보를 제2 영역(2410)에 표시할 수 있다.
또한, 디스플레이 장치(600)는 수신된 특정 처방 정보를 환자 정보에 추가하여 기존 환자 정보를 업데이트 할 수 있다. 업데이트 된 환자 정보를 변경된 환자 정보로 기술한다. 디스플레이 장치(600)는 UI(2905) 또는 UI(2910)을 선택하는 담당 의사의 입력이 수신되면, 변경된 환자 정보에 포함된 처방 정보(무통주사, 진통제 3일)를 대기자 정보에 추가할 수 있다. 추가된 처방 정보를 포함하는 대기자 정보를 변경된 대기자 정보로 기술한다.
도 30은 증상 정보 및 처방 정보를 동기화하는 실시 예를 설명하기 위한 도면이다.
도 30을 참조하면, 디스플레이 장치(600)는 증상 정보 및 처방 정보 모두를 동기화 하는 UI (3005), 증상 정보만 동기화 하는 UI (3010), 처방 정보만 동기화 하는 UI (3015) 중 적어도 하나를 표시할 수 있다.
UI (3005)를 선택하는 담당 의사의 입력이 수신되면, 디스플레이 장치(600)는 대기자 정보에 포함된 증상 정보를 환자 정보에 추가하고 환자 정보에 포함된 처방 정보를 대기자 정보에 추가할 수 있다.
또한, UI (3010)를 선택하는 담당 의사의 입력이 수신되면, 디스플레이 장치(600)는 대기자 정보에 포함된 증상 정보만 환자 정보에 추가할 수 있다.
또한, UI (3015)를 선택하는 담당 의사의 입력이 수신되면, 디스플레이 장치(600)는 환자 정보에 포함된 처방 정보만 대기자 정보에 추가할 수 있다.
다양한 동기화 UI를 제공하는 도 30의 실시 예는 담당 의사의 선택에 따라 증상 정보, 처방 정보 중 적어도 하나를 동기화하는 동작을 포함하므로, 담당 의사의 데이터 관리를 용이하게 할 수 있다.
도 31은 일 실시 예에 따른 사용자 단말 장치의 제어 방법을 설명하기 위한 흐름도이다.
도 31을 참조하면, 본 실시 예에 따른 사용자 단말 장치(100)에 동작을 실행시키는 컴퓨터로 읽을 수 있는 매체에 저장된 애플리케이션에 있어서, 동작은 증상 정보를 입력 받기 위한 UI 화면을 제공하는 단계 (S3105), UI 화면을 통해 사용자의 증상 정보가 입력되면, 증상 정보 및 대기 번호 요청을 병원 관리 서버(300)로 전송하는 단계 (S3110), 병원 관리 서버(300)로부터 대기 번호 요청에 대응되는 대기 번호를 수신하고, 수신된 대기 번호를 포함하는 UI 화면을 제공하는 단계 (S3115), 사용자의 식별 정보를 애플리케이션 서버(200)로 전송하는 단계 (S3120) 및 애플리케이션 서버(200)가 사용자의 식별 정보를 병원 관리 서버(300)로 전송하도록 제어하는 단계 (S3125)를 할 수 있다.
여기서, 병원 관리 서버(300)로 전송된 증상 정보를 포함하는 제1 UI 화면 및 사용자의 식별 정보를 포함하는 제2 UI 화면이 병원 관리 서버(300)와 통신하는 디스플레이 장치(600)에 제공될 수 있다.
또한, 동작은 병원 예약을 위한 UI 화면을 제공하는 단계, UI 화면을 통해 병원 예약을 위한 정보가 입력되면, 사용자의 식별 정보 및 병원 예약을 위한 정보를 애플리케이션 서버(200)로 전송하는 단계 및 애플리케이션 서버(200)로부터 병원 예약 정보가 수신되면, 수신된 병원 예약 정보를 포함하는 UI 화면을 제공하는 단계를 더 포함할 수 있고, 예약 정보는 예약 시간을 포함할 수 있다.
여기서, 동작은 예약 시간으로부터 임계 시간 이전 시점부터 사용자 단말 장치(100)의 위치 정보를 병원 관리 서버(300)로 전송하는 단계 및 병원 관리 서버(300)로부터 위치 정보에 대응되는 대기 번호를 수신하면, 수신된 대기 번호를 포함하는 UI 화면을 제공하는 단계를 더 포함할 수 있다.
여기서, 병원 관리 서버(300)는 위치 정보가 병원의 위치로부터 임계 거리 내이면, 순위가 높은 대기 번호를 사용자 단말 장치(100)로 제공할 수 있다.
또한, 동작은 수신된 대기 번호를 애플리케이션 서버(200)에 전송하는 단계 및 애플리케이션 서버(200)가 대기 번호를 병원 관리 서버(300)로 전송하도록 제어하는 단계를 더 포함할 수 있고, 병원 관리 서버(300)로 전송된 증상 정보 및 대기 번호를 포함하는 제1 UI 화면 및 사용자의 식별 정보 및 대기 번호를 포함하는 제2 UI 화면이 병원 관리 서버(300)와 통신하는 디스플레이 장치(600)에 제공될 수 있다.
또한, 동작은 병원 관리 서버(300)로부터 처방 정보를 수신하는 단계 및 수신된 처방 정보를 포함하는 UI 화면을 제공하는 단계를 더 포함할 수 있고, 병원 관리 서버(300)는 대기 번호에 기초하여 처방 정보를 전송할 사용자 단말 장치(100)를 식별할 수 있고, 식별된 사용자 단말 장치(100)로 처방 정보를 전송할 수 있다.
한편, 병원 관리 서버(300)는 제1 병원 관리 서버 및 제2 병원 관리 서버를 포함할 수 있고, 증상 정보 및 대기 번호 요청은 제1 병원 관리 서버로 전송될 수 있으며, 사용자의 식별 정보는 제2 병원 관리 서버로 전송될 수 있다.
또한, 증상 정보는 제1 통신 모듈을 통해 병원 관리 서버(300)로 전송될 수 있고, 사용자의 식별 정보는 제2 통신 모듈을 통해 병원 관리 서버(300)로 전송될 수 있다.
여기서, 동작은 병원 관리 서버(300)로부터 처방 정보를 수신하는 단계 및 수신된 처방 정보를 포함하는 UI 화면을 제공하는 단계를 포함할 수 있고, 처방 정보는 제1 통신 모듈을 통해 병원 관리 서버(300)로부터 수신될 수 있다.
한편, 도 31과 같은 애플리케이션 동작은 도 1 또는 도 2의 구성을 가지는 전자 장치 상에서 실행될 수 있으며, 그 밖의 구성을 가지는 전자 장치 상에서도 실행될 수 있다.
한편, 상술한 본 개시의 다양한 실시 예들에 따른 방법들은, 기존 전자 장치에 설치 가능한 어플리케이션 형태로 구현될 수 있다.
또한, 상술한 본 개시의 다양한 실시 예들에 따른 방법들은, 기존 전자 장치에 대한 소프트웨어 업그레이드, 또는 하드웨어 업그레이드 만으로도 구현될 수 있다.
또한, 상술한 본 개시의 다양한 실시 예들은 전자 장치에 구비된 임베디드 서버, 또는 전자 장치 및 디스플레이 장치 중 적어도 하나의 외부 서버를 통해 수행되는 것도 가능하다.
한편, 본 개시의 일시 예에 따르면, 이상에서 설명된 다양한 실시 예들은 기기(machine)(예: 컴퓨터)로 읽을 수 있는 저장 매체(machine-readable storage media)에 저장된 명령어를 포함하는 소프트웨어로 구현될 수 있다. 기기는, 저장 매체로부터 저장된 명령어를 호출하고, 호출된 명령어에 따라 동작이 가능한 장치로서, 개시된 실시 예들에 따른 전자 장치를 포함할 수 있다. 명령이 프로세서에 의해 실행될 경우, 프로세서가 직접, 또는 프로세서의 제어 하에 다른 구성요소들을 이용하여 명령에 해당하는 기능을 수행할 수 있다. 명령은 컴파일러 또는 인터프리터에 의해 생성 또는 실행되는 코드를 포함할 수 있다. 기기로 읽을 수 있는 저장매체는, 비일시적(non-transitory) 저장매체의 형태로 제공될 수 있다. 여기서, '비일시적'은 저장매체가 신호(signal)를 포함하지 않으며 실재(tangible)한다는 것을 의미할 뿐 데이터가 저장매체에 반영구적 또는 임시적으로 저장됨을 구분하지 않는다.
또한, 본 개시의 일 실시 예에 따르면, 이상에서 설명된 다양한 실시 예들에 따른 방법은 컴퓨터 프로그램 제품(computer program product)에 포함되어 제공될 수 있다. 컴퓨터 프로그램 제품은 상품으로서 판매자 및 구매자 간에 거래될 수 있다. 컴퓨터 프로그램 제품은 기기로 읽을 수 있는 저장 매체(예: compact disc read only memory (CD-ROM))의 형태로, 또는 어플리케이션 스토어(예: 플레이 스토어TM)를 통해 온라인으로 배포될 수 있다. 온라인 배포의 경우에, 컴퓨터 프로그램 제품의 적어도 일부는 제조사의 서버, 어플리케이션 스토어의 서버, 또는 중계 서버의 메모리와 같은 저장 매체에 적어도 일시 저장되거나, 임시적으로 생성될 수 있다.
또한, 상술한 다양한 실시 예들에 따른 구성 요소(예: 모듈 또는 프로그램) 각각은 단수 또는 복수의 개체로 구성될 수 있으며, 전술한 해당 서브 구성 요소들 중 일부 서브 구성 요소가 생략되거나, 또는 다른 서브 구성 요소가 다양한 실시 예에 더 포함될 수 있다. 대체적으로 또는 추가적으로, 일부 구성 요소들(예: 모듈 또는 프로그램)은 하나의 개체로 통합되어, 통합되기 이전의 각각의 해당 구성 요소에 의해 수행되는 기능을 동일 또는 유사하게 수행할 수 있다. 다양한 실시 예들에 따른, 모듈, 프로그램 또는 다른 구성 요소에 의해 수행되는 동작들은 순차적, 병렬적, 반복적 또는 휴리스틱하게 실행되거나, 적어도 일부 동작이 다른 순서로 실행되거나, 생략되거나, 또는 다른 동작이 추가될 수 있다.
이상에서는 본 개시의 바람직한 실시 예에 대하여 도시하고 설명하였지만, 본 개시는 상술한 특정의 실시 예에 한정되지 아니하며, 청구범위에서 청구하는 본 개시의 요지를 벗어남이 없이 당해 개시에 속하는 기술분야에서 통상의 지식을 가진 자에 의해 다양한 변형 실시가 가능한 것은 물론이고, 이러한 변형실시들은 본 개시의 기술적 사상이나 전망으로부터 개별적으로 이해되어져서는 안될 것이다.
100: 사용자 단말 장치110: 메모리
120: 통신 인터페이스130: 디스플레이
140: 프로세서

Claims (20)

  1. 단말 장치에 동작을 실행시키는 컴퓨터로 읽을 수 있는 매체에 저장된 애플리케이션에 있어서,상기 동작은,증상 정보를 입력 받기 위한 UI 화면을 제공하는 단계;상기 UI 화면을 통해 사용자의 증상 정보가 입력되면, 상기 증상 정보 및 대기 번호 요청을 병원 관리 서버로 전송하는 단계;상기 병원 관리 서버로부터 상기 대기 번호 요청에 대응되는 대기 번호를 수신하고, 수신된 대기 번호를 포함하는 UI 화면을 제공하는 단계;상기 사용자의 식별 정보를 애플리케이션 서버로 전송하는 단계; 및상기 애플리케이션 서버가 상기 사용자의 식별 정보를 상기 병원 관리 서버로 전송하도록 제어하는 단계;를 포함하는, 애플리케이션.
  2. 제1항에 있어서,상기 병원 관리 서버로 전송된 상기 증상 정보를 포함하는 제1 UI 화면 및 상기 사용자의 식별 정보를 포함하는 제2 UI 화면이 상기 병원 관리 서버와 통신하는 디스플레이 장치에 제공되는, 애플리케이션.
  3. 제1항에 있어서,상기 동작은,병원 예약을 위한 UI 화면을 제공하는 단계;상기 UI 화면을 통해 병원 예약을 위한 정보가 입력되면, 상기 사용자의 식별 정보 및 상기 병원 예약을 위한 정보를 상기 애플리케이션 서버로 전송하는 단계; 및상기 애플리케이션 서버로부터 병원 예약 정보가 수신되면, 상기 수신된 병원 예약 정보를 포함하는 UI 화면을 제공하는 단계;를 더 포함하며,상기 예약 정보는, 예약 시간을 포함하는, 애플리케이션.
  4. 제3항에 있어서,상기 동작은,상기 예약 시간으로부터 임계 시간 이전 시점부터 상기 단말 장치의 위치 정보를 상기 병원 관리 서버로 전송하는 단계; 및상기 병원 관리 서버로부터 상기 위치 정보에 대응되는 대기 번호를 수신하면, 수신된 대기 번호를 포함하는 UI 화면을 제공하는 단계;를 더 포함하는, 애플리케이션.
  5. 제4항에 있어서,상기 병원 관리 서버는,상기 위치 정보가 상기 병원의 위치로부터 임계 거리 내이면, 순위가 높은 대기 번호를 상기 단말 장치로 제공하는, 애플리케이션.
  6. 제1항에 있어서,상기 동작은,상기 수신된 대기 번호를 상기 애플리케이션 서버에 전송하는 단계; 및상기 애플리케이션 서버가 상기 대기 번호를 상기 병원 관리 서버로 전송하도록 제어하는 단계;를 더 포함하며,상기 병원 관리 서버로 전송된 상기 증상 정보 및 상기 대기 번호를 포함하는 제1 UI 화면 및 상기 사용자의 식별 정보 및 상기 대기 번호를 포함하는 제2 UI 화면이 상기 병원 관리 서버와 통신하는 디스플레이 장치에 제공되는, 애플리케이션.
  7. 제1항에 있어서,상기 동작은,상기 병원 관리 서버로부터 처방 정보를 수신하는 단계; 및상기 수신된 처방 정보를 포함하는 UI 화면을 제공하는 단계;를 더 포함하며,상기 병원 관리 서버는, 상기 대기 번호에 기초하여 상기 처방 정보를 전송할 단말 장치를 식별하고, 상기 식별된 단말 장치로 상기 처방 정보를 전송하는, 애플리케이션.
  8. 제1항에 있어서,상기 병원 관리 서버는,제1 병원 관리 서버 및 제2 병원 관리 서버를 포함하며,상기 증상 정보 및 상기 대기 번호 요청은 상기 제1 병원 관리 서버로 전송되며,상기 사용자의 식별 정보는, 상기 제2 병원 관리 서버로 전송되는, 애플리케이션.
  9. 제1항에 있어서,상기 증상 정보는, 제1 통신 모듈을 통해 상기 병원 관리 서버로 전송되고,상기 사용자의 식별 정보는, 제2 통신 모듈을 통해 상기 병원 관리 서버로 전송되는, 애플리케이션.
  10. 제9항에 있어서,상기 동작은,상기 병원 관리 서버로부터 처방 정보를 수신하는 단계; 및상기 수신된 처방 정보를 포함하는 UI 화면을 제공하는 단계;를 더 포함하며,상기 처방 정보는, 상기 제1 통신 모듈을 통해 상기 병원 관리 서버로부터 수신되는, 애플리케이션.
  11. 단말 장치에 있어서,애플리케이션을 저장하는 메모리;통신 인터페이스;디스플레이;상기 애플리케이션을 실행하여 동작을 수행하는 프로세서;를 포함하며,상기 동작은,증상 정보를 입력받기 위한 UI 화면을 상기 디스플레이에 표시하는 단계;상기 UI 화면을 통해 사용자의 증상 정보가 입력되면, 상기 증상 정보 및 대기 번호 요청을 병원 관리 서버로 전송하는 단계;상기 병원 관리 서버로부터 상기 대기 번호 요청에 대응되는 대기 번호를 수신하고, 수신된 대기 번호를 포함하는 UI 화면을 상기 디스플레이에 표시하는 단계;상기 사용자의 식별 정보를 애플리케이션 서버로 전송하는 단계; 및상기 애플리케이션 서버가 상기 사용자의 식별 정보를 상기 병원 관리 서버로 전송하도록 제어하는 단계;를 포함하는, 단말 장치.
  12. 제11항에 있어서,상기 프로세서는,상기 병원 관리 서버로 전송된 상기 증상 정보를 포함하는 제1 UI 화면 및 상기 사용자의 식별 정보를 포함하는 제2 UI 화면을 상기 병원 관리 서버와 통신하는 디스플레이 장치에 제공하는, 단말 장치.
  13. 제11항에 있어서,상기 프로세서는,상기 UI 화면을 통해 병원 예약을 위한 정보가 입력되면, 상기 사용자의 식별 정보 및 상기 병원 예약을 위한 정보를 상기 애플리케이션 서버로 전송하고,상기 애플리케이션 서버로부터 병원 예약 정보가 수신되면, 상기 수신된 병원 예약 정보를 포함하는 UI 화면을 상기 디스플레이에 표시하고,상기 예약 정보는, 예약 시간을 포함하는, 단말 장치.
  14. 제13항에 있어서,상기 프로세서는,상기 예약 시간으로부터 임계 시간 이전 시점부터 상기 단말 장치의 위치 정보를 상기 병원 관리 서버로 전송하고,상기 병원 관리 서버로부터 상기 위치 정보에 대응되는 대기 번호를 수신하면, 수신된 대기 번호를 포함하는 UI 화면을 상기 디스플레이에 표시하는, 단말 장치.
  15. 제14항에 있어서,상기 병원 관리 서버는,상기 위치 정보가 상기 병원의 위치로부터 임계 거리 내이면, 순위가 높은 대기 번호를 상기 단말 장치로 제공하는, 단말 장치.
  16. 제11항에 있어서,상기 프로세서는,상기 수신된 대기 번호를 상기 통신 인터페이스를 통해 상기 애플리케이션 서버에 전송하고,상기 애플리케이션 서버가 상기 대기 번호를 상기 병원 관리 서버로 전송하도록 제어하고,상기 병원 관리 서버로 전송된 상기 증상 정보 및 상기 대기 번호를 포함하는 제1 UI 화면 및 상기 사용자의 식별 정보 및 상기 대기 번호를 포함하는 제2 UI 화면이 상기 병원 관리 서버와 통신하는 디스플레이 장치에 제공되는, 단말 장치.
  17. 제11항에 있어서,상기 프로세서는,상기 병원 관리 서버로부터 처방 정보를 수신하고,상기 수신된 처방 정보를 포함하는 UI 화면을 상기 디스플레이에 표시하며,상기 병원 관리 서버는, 상기 대기 번호에 기초하여 상기 처방 정보를 전송할 단말 장치를 식별하고, 상기 식별된 단말 장치로 상기 처방 정보를 전송하는, 단말 장치.
  18. 제11항에 있어서,상기 병원 관리 서버는,제1 병원 관리 서버 및 제2 병원 관리 서버를 포함하며,상기 증상 정보 및 상기 대기 번호 요청은 상기 제1 병원 관리 서버로 전송되며,상기 사용자의 식별 정보는, 상기 제2 병원 관리 서버로 전송되는, 단말 장치.
  19. 제11항에 있어서,상기 증상 정보는, 제1 통신 모듈을 통해 상기 병원 관리 서버로 전송되고,상기 사용자의 식별 정보는, 제2 통신 모듈을 통해 상기 병원 관리 서버로 전송되는, 단말 장치.
  20. 제19항에 있어서,상기 프로세서는,상기 병원 관리 서버로부터 처방 정보를 수신하고,상기 수신된 처방 정보를 포함하는 UI 화면을 상기 디스플레이에 표시하고,상기 처방 정보는, 상기 제1 통신 모듈을 통해 상기 병원 관리 서버로부터 수신되는, 단말 장치.
KR1020190171184A 2019-12-19 2019-12-19 스마트 진료 시스템 및 그 방법 KR102312830B1 (ko)

Priority Applications (5)

Application Number Priority Date Filing Date Title
KR1020190171184A KR102312830B1 (ko) 2019-12-19 2019-12-19 스마트 진료 시스템 및 그 방법
JP2022538458A JP7340702B2 (ja) 2019-12-19 2020-12-14 スマート診察システム及びその方法
US17/787,589 US20220415490A1 (en) 2019-12-19 2020-12-14 Smart diagnosis system and method
PCT/KR2020/018232 WO2021125719A1 (ko) 2019-12-19 2020-12-14 스마트 진료 시스템 및 그 방법
KR1020210133168A KR20210125966A (ko) 2019-12-19 2021-10-07 스마트 진료 시스템 및 그 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020190171184A KR102312830B1 (ko) 2019-12-19 2019-12-19 스마트 진료 시스템 및 그 방법

Related Child Applications (1)

Application Number Title Priority Date Filing Date
KR1020210133168A Division KR20210125966A (ko) 2019-12-19 2021-10-07 스마트 진료 시스템 및 그 방법

Publications (2)

Publication Number Publication Date
KR20210079076A true KR20210079076A (ko) 2021-06-29
KR102312830B1 KR102312830B1 (ko) 2021-10-15

Family

ID=76477751

Family Applications (2)

Application Number Title Priority Date Filing Date
KR1020190171184A KR102312830B1 (ko) 2019-12-19 2019-12-19 스마트 진료 시스템 및 그 방법
KR1020210133168A KR20210125966A (ko) 2019-12-19 2021-10-07 스마트 진료 시스템 및 그 방법

Family Applications After (1)

Application Number Title Priority Date Filing Date
KR1020210133168A KR20210125966A (ko) 2019-12-19 2021-10-07 스마트 진료 시스템 및 그 방법

Country Status (4)

Country Link
US (1) US20220415490A1 (ko)
JP (1) JP7340702B2 (ko)
KR (2) KR102312830B1 (ko)
WO (1) WO2021125719A1 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102365428B1 (ko) * 2021-09-03 2022-02-23 주식회사 티앤비 병원 비대면 접수 방법 및 시스템
KR102641735B1 (ko) * 2023-08-14 2024-02-27 주식회사 아이엠디티 진단이력 관리 기능을 통한 외래진료 지원 시스템

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115879574A (zh) * 2021-09-27 2023-03-31 华为技术有限公司 健康管理方法、相关装置及通信系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20130082641A (ko) * 2011-12-12 2013-07-22 주식회사 하나은행 방문 예약 서버 및 방법
KR20160011033A (ko) * 2014-07-21 2016-01-29 주식회사 지엠홀딩스 통합 의료 예약 서비스 제공 방법
KR20160144570A (ko) * 2015-06-08 2016-12-19 (주)유메디 병원 진료 예약 플랫폼 시스템 및 이의 방법
KR20170029987A (ko) * 2015-09-08 2017-03-16 (주)크레소티 위치기반 진료 서비스 시스템
KR20180075298A (ko) 2016-12-26 2018-07-04 엠투클라우드 주식회사 위치 기반의 진료 접수 방법 및 그 시스템

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5876952B2 (ja) 2014-03-27 2016-03-02 タック株式会社 医療系予約システム、及び、プログラム
KR101634859B1 (ko) * 2014-05-22 2016-06-29 주식회사 유비케어 환자 진료 시스템 및 환자 진료 방법
JP2016110247A (ja) 2014-12-03 2016-06-20 株式会社アイテック 診療の予約、診療料金及び医薬品料金の精算を行なうためのシステム及び方法
JP6222535B2 (ja) 2016-03-30 2017-11-01 株式会社ゼンアーキテクツ 地域医療総合受付システム及びそのプログラム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20130082641A (ko) * 2011-12-12 2013-07-22 주식회사 하나은행 방문 예약 서버 및 방법
KR20160011033A (ko) * 2014-07-21 2016-01-29 주식회사 지엠홀딩스 통합 의료 예약 서비스 제공 방법
KR20160144570A (ko) * 2015-06-08 2016-12-19 (주)유메디 병원 진료 예약 플랫폼 시스템 및 이의 방법
KR20170029987A (ko) * 2015-09-08 2017-03-16 (주)크레소티 위치기반 진료 서비스 시스템
KR20180075298A (ko) 2016-12-26 2018-07-04 엠투클라우드 주식회사 위치 기반의 진료 접수 방법 및 그 시스템

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102365428B1 (ko) * 2021-09-03 2022-02-23 주식회사 티앤비 병원 비대면 접수 방법 및 시스템
KR102641735B1 (ko) * 2023-08-14 2024-02-27 주식회사 아이엠디티 진단이력 관리 기능을 통한 외래진료 지원 시스템

Also Published As

Publication number Publication date
JP7340702B2 (ja) 2023-09-07
KR102312830B1 (ko) 2021-10-15
JP2023508039A (ja) 2023-02-28
WO2021125719A1 (ko) 2021-06-24
US20220415490A1 (en) 2022-12-29
KR20210125966A (ko) 2021-10-19

Similar Documents

Publication Publication Date Title
KR20210125966A (ko) 스마트 진료 시스템 및 그 방법
EP2767951B1 (en) Information processing device, method and program
JP5745933B2 (ja) 病歴診断システムおよび方法
EP2892022A1 (en) Method and apparatus for personal medical treatment using mobile terminal
US20170061074A1 (en) Telemedicine system and method
US20150100333A1 (en) Systems and methods for verifying protocol compliance
WO2020186905A1 (zh) 诊疗引导方法、装置和系统、计算机可读存储介质
US20190295700A1 (en) Systems and methods for managing mobile-based patient centric medical data
Nam et al. Development of smartphone application that aids stroke screening and identifying nearby acute stroke care hospitals
US20190304574A1 (en) Systems and methods for managing server-based patient centric medical data
JP7340053B2 (ja) 情報連携システム、情報連携装置、情報連携方法及びプログラム
JP2014203416A (ja) 待ち時間予測システム
JP5845235B2 (ja) 病院利用支援システム
US20150254416A1 (en) Method and system for providing medical advice
JP6185854B2 (ja) 診療待ち情報表示システム及び方法、並びに、プログラム
WO2017105602A1 (en) Telemedicine system and method
KR101460174B1 (ko) 영상검사자료 통합검색기능이 구비된 병원진료검색시스템 및 그 제어방법
JP6736838B2 (ja) 情報処理装置、カルテ画面表示方法、およびプログラム
JP7284969B1 (ja) 医療情報共有システム
JP7115799B1 (ja) 情報提供方法、情報提供装置、情報提供プログラム及び記録媒体
WO2014149299A1 (en) Methods, apparatuses and computer program products for providing a knowledge hub health care solution
JP4512338B2 (ja) 医療情報処理システムの制御方法、情報処理装置、および情報処理装置の制御プログラム
JP7298670B2 (ja) 情報処理システム、カルテ画面表示方法、およびプログラム
JP6988943B2 (ja) 情報処理システム、カルテ画面表示方法、およびプログラム
JP2013041339A (ja) 電子カルテサーバ、表示方法及び表示プログラム

Legal Events

Date Code Title Description
E701 Decision to grant or registration of patent right