WO2021256657A1 - 다수개의 병원서버 및 컨소시엄서버를 동시다발적으로 연동하기 위한 클라우드 기반의 api스펙 관리방법 - Google Patents

다수개의 병원서버 및 컨소시엄서버를 동시다발적으로 연동하기 위한 클라우드 기반의 api스펙 관리방법 Download PDF

Info

Publication number
WO2021256657A1
WO2021256657A1 PCT/KR2021/001956 KR2021001956W WO2021256657A1 WO 2021256657 A1 WO2021256657 A1 WO 2021256657A1 KR 2021001956 W KR2021001956 W KR 2021001956W WO 2021256657 A1 WO2021256657 A1 WO 2021256657A1
Authority
WO
WIPO (PCT)
Prior art keywords
api
servers
hospital
server
consortium
Prior art date
Application number
PCT/KR2021/001956
Other languages
English (en)
French (fr)
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 CN202180033827.0A priority Critical patent/CN115516574B/zh
Priority to US17/925,710 priority patent/US11854692B2/en
Priority to EP21826175.8A priority patent/EP4170674A4/en
Publication of WO2021256657A1 publication Critical patent/WO2021256657A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/567—Integrating service provisioning from a plurality of service providers
    • 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
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/301—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is a virtual computing platform, e.g. logically partitioned systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • 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
    • 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
    • G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • 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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5029—Service quality level-based billing, e.g. dependent on measured service level customer is charged more or less
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/53—Network services using third party service providers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02A—TECHNOLOGIES FOR ADAPTATION TO CLIMATE CHANGE
    • Y02A90/00—Technologies having an indirect contribution to adaptation to climate change
    • Y02A90/10—Information and communication technologies [ICT] supporting adaptation to climate change, e.g. for weather forecasting or climate simulation

Definitions

  • the present invention relates to a cloud-based API management method for simultaneously interworking a plurality of hospital servers and consortium servers.
  • a plurality of hospital servers and consortium servers are simultaneously interlocked to provide an integrated interface in the cloud server. It relates to a cloud-based API specification management method.
  • the API builder unit disposed in the hospital server extracts patient information and prescription information from the EMR DB, and converts the prescription information and the patient information using the API.
  • the data source is created in the API Builder section, and it can be easily written through the SQL query writing guide and converted to standard data through the API Builder and repeated verification.
  • data between heterogeneous DBMSs and data developed in different development languages can be standardized.
  • these systems have difficulties in integrated management because API builders are installed in different hospital servers or medical institution servers.
  • in managing the API it is manually managed, and the consistency of data is not checked.
  • the problem to be solved by the present invention is that the cloud server provides a predefined API to the hospital server and the consortium server so that the patient does not need to directly access the hospital server and the consortium server.
  • the purpose of this is to provide a cloud-based API specification management method for linking multiple hospital servers and consortium servers simultaneously for convenient provision.
  • a cloud-based API specification management method for simultaneously interworking a plurality of hospital servers and consortium servers is a method for a user terminal to search for a patient number in a dedicated application, make a medical appointment, make a medication, pay, and lose Selecting at least one service from among the insurance claim services, the user terminal transmitting patient-specific information and service selection results to a cloud server, and the cloud server simultaneously providing patient data to a plurality of hospital servers based on patient-specific information request, the cloud server receiving patient data from a plurality of hospital servers, the cloud server merging patient data, and the cloud server providing services to a plurality of consortium servers in response to the service selected by the user terminal requesting, and a plurality of consortium servers providing the requested service using the API.
  • the private API becomes an open API of the hospital and becomes a standard for the rear ecosystem. It is possible to develop services from a single source in each hospital system that is different from each other. In addition, it is possible to simultaneously interwork with multiple hospital servers and multiple consortium servers, enabling integrated management of patient data. In addition, it is possible to provide an integrated interface to patients by extracting and merging patient data from a plurality of hospital servers and consortium servers.
  • the hospital server or consortium server is not directly connected to the user terminal, so security is enhanced. It is highly scalable as it can be applied to tens of thousands of hospitals and consortium companies.
  • mobile services can be provided with one patient app regardless of the various data formats of hospitals and consortiums.
  • hospitals and consortiums can provide data as an open API function without separate development work through API engine in other apps that require the same service using the generated data structure.
  • FIG. 1 is a configuration diagram illustrating a cloud-based API specification management system for simultaneously interworking a plurality of hospital servers and consortium servers according to an embodiment of the present invention.
  • FIG. 2 is a diagram showing the configuration of a cloud server and a hospital server according to an embodiment of the present invention.
  • FIG. 3 is a flowchart illustrating an operation method of an API generator of a cloud server according to an embodiment of the present invention.
  • FIG. 4 is a flowchart illustrating an operation method of an API engine unit of a hospital server according to an embodiment of the present invention.
  • FIG. 5 is a flowchart illustrating a cloud-based API specification management method for simultaneously interworking a plurality of hospital servers and consortium servers according to an embodiment of the present invention.
  • FIG. 6 is a conceptual diagram illustrating a communication protocol of a cloud-based API management system according to an embodiment of the present invention.
  • FIG. 7 is a flowchart illustrating a cloud-based API specification management method for simultaneously interworking a plurality of hospital servers and consortium servers according to an embodiment of the present invention.
  • FIG. 8 is a flowchart illustrating an architectural change of a cloud-based API call for concurrently interworking a plurality of hospital servers and consortium servers according to an embodiment of the present invention.
  • API specifications refer to definitions and rules for easily describing and expressing APIs. It shows the API more easily and can be automatically generated with codes of various programming languages.
  • FIG. 1 is a configuration diagram illustrating a cloud-based API specification management system for synchronously interworking a plurality of hospital servers according to an embodiment of the present invention.
  • the API management system 10 includes a cloud server 100 , a plurality of hospital servers 200 , a plurality of consortium servers 300 , and a user terminal 400 .
  • the cloud server 100 may generate an API provided to a plurality of hospital servers 100 and a plurality of consortium servers 300 and perform a function of managing the provided API.
  • the plurality of consortium servers 300 may include a pharmacy server 310 , a PHR server 320 , an insurance company server 330 , a bank company server 340 , a card company server 350 , and a block chain server 360 .
  • the cloud server 100 provides a predefined API to the hospital server and the consortium server, so that when the user terminal 400 requests a service such as medical treatment service and loss insurance claim, the cloud server does not need to be directly connected to the hospital server and consortium server. can be provided easily.
  • FIG. 2 is a diagram showing the configuration of a cloud server and a hospital server according to an embodiment of the present invention.
  • the cloud server 100 includes an API generation unit 110 , an API management unit 120 , an API call unit 125 , a data verification unit 130 , a data merging unit 140 , and a copyright management unit 150 . ), a billing unit 160 , a monitoring unit 170 , and a database 180 .
  • the API generator 110 may generate a predefined API for providing an integrated interface between the hospital servers and the consortium server. It may be an API for standardizing database information of hospital servers and consortium servers.
  • the API generator 110 may define a data source and register SQL and procedures. Also, the API generating unit 110 may register middleware access information and a call path, and may register web service access information and a URL.
  • the API management unit 120 When the API management unit 120 receives a service call from the user terminal, the API matching the service is called to provide simultaneous patient number inquiry, treatment reservation, payment, and loss insurance claim services to a plurality of hospital servers and consortium servers. can do.
  • the API management unit 120 may perform input and output error checking through the API constraint management function.
  • the API management unit 120 may monitor the status of API services of each hospital server and consortium server, version information, memory usage, disk usage, CPU usage of the server, and the like.
  • the API management unit 120 may encrypt the sensitive information and store it in the database.
  • the API management unit 120 may manage the domain of the API.
  • the API management unit 120 When the API specification managed by the metadata is changed, the API management unit 120 may add metadata for automatic distribution. That is, a standardized mapping definition is written, and a mapping sample example is used in a standardized prototype template according to the processing method, so that a standardized source loading program can be generated, and a programmed processor and extracted data can be selectively registered.
  • the API call unit 125 is implemented to automatically make an API call, and operates to make simultaneous calls in parallel with a plurality of hospital servers and consortium servers.
  • the data verification unit 130 may perform an error test of the generated API. If there is error data, you can save and distribute the data and API after correcting the data.
  • the data merging unit 140 may receive and merge patient data from a plurality of hospital servers. When a patient uses several hospitals, it is possible to increase convenience by receiving patient data from each hospital server and merging them.
  • the copyright management unit 150 may manage copyright through a classification system that can be identified for each hospital server.
  • the copyright management unit 150 may manage program sources and versions, and may provide an interface guide standard for each function by setting a management number classification system for each function or architecture.
  • the billing unit 160 may charge when the API is used in the consortium server.
  • the billing unit 160 may measure the API usage of the consortium server and reflect usage status/statistics for each group.
  • the monitoring unit 170 may monitor the interworking between a plurality of hospital servers and the consortium server.
  • the database 180 may store API tools.
  • the API can be provided to the hospital server by registering a predefined API specification as metadata.
  • API specifications managed by Excel and confluence can be registered as metadata to select API specifications suitable for each hospital server, and can be configured to be automatically distributed to the API engine of each hospital server.
  • the cloud server and the hospital server are linked through a firewall in the form of standardized DATA to quickly build an app service for patients.
  • a data structure for each content menu screen may be defined in the form of an open API in order to define a patient content menu and apply a data structure suitable for the standard to all hospitals. If each hospital extracts the appropriate data in SQL, JSON, XML, and data format, the API can be linked with the cloud server in a standardized data format to quickly build an app service for patients and provide the service.
  • a hospital can provide data with an open API function without additional development work through the API in other apps that require the same service for the data structure created once.
  • URL links to sample screens for each API are provided so that hospital personnel can write more easily.
  • the cloud server 100 is provided with virtual data management to support developers and testers, and can check real data to support operators and operation testers for real service support.
  • the cloud server 100 may provide an overall connection method while keeping the internal security policy based on the hospital's security and medical law in the stage where one business logic is interlocked with a plurality of data interfaces.
  • the cloud server 100 may provide a connection method for infrastructure construction and interworking for performing interfaces of a plurality of hospitals.
  • the basic API server internal system can be configured as a dedicated VPN.
  • the cloud server 100 may provide a method for guiding the interface in the form of an open API for the consortium group to view the corresponding contents.
  • the first hospital server 210 includes an EMR DB 211 , a consortium interface 213 , and an API engine unit 215 .
  • the EMR DB 211 may store patient information, diagnosis/prescription information, hospitalization information, hospital care information, and the like.
  • the consortium interface 213 is composed of a patient waiting system, an intelligent turn order system, a parking management system, a payment management system, a loss claim system, a prescription delivery system, and the like.
  • the configurations of the EMR DB 211 and the consortium interface 213 are illustrated as examples and are not limited thereto.
  • the API engine unit 215 may extract data from the EMR DB 211 .
  • the API engine unit 215 may receive and load an API (Application Programming Interface) for each hospital server received from the cloud server, and load API meta information from the cloud server to perform the API service.
  • the API engine unit 225 is installed in the hospital server and is a middleware that connects the mobile service and the hospital server, and is a development tool that supports the API by connecting to the hospital legacy in various environments. That is, it is installed in the hospital server and can be used as a restful API development and gateway server for interworking with various systems in the hospital as well as app services for patients.
  • the API engine unit 215 includes an EMR data extraction unit 216 , an API receiving unit 217 , an API meta information loading unit 218 , and an API service unit 219 .
  • the EMR data extraction unit 216 may extract data from the EMR DB 211 .
  • the API receiving unit 217 may receive the API for each hospital server generated from the cloud server.
  • the API metadata loading unit 218 may load API metadata from the cloud server.
  • the API service unit 219 may drive the API service based on API metadata.
  • FIG. 3 is a flowchart illustrating an operation method of an API generator of a cloud server according to an embodiment of the present invention.
  • the cloud server defines a standard API ( S301 ). Thereafter, the cloud server creates an API for each hospital server or consortium server (S203). The generated API is tested ( S305 ), and if there is no error, data and API are stored and distributed, and if there is an error, data and API can be stored and distributed by modifying the data.
  • FIG. 4 is a flowchart illustrating an operation method of an API engine unit of a hospital server according to an embodiment of the present invention.
  • the API engine unit of the hospital server starts the API engine (S401). Thereafter, the API execution unit loads the API meta information from the cloud server (S403). The API service is driven based on the loaded API meta information (S405).
  • FIG. 5 is a flowchart illustrating a cloud-based API management method for simultaneously interworking a plurality of hospital servers according to an embodiment of the present invention.
  • the user terminal 400 selects at least one service among patient number inquiry, medical appointment, pharmaceutical preparation, payment, and loss insurance claim service in the dedicated application (S601).
  • the user terminal transmits the patient-specific information and the service selection result to the cloud server (S603).
  • the cloud server simultaneously requests patient data from a plurality of hospital servers based on patient-specific information (S605).
  • the cloud server receives patient data from a plurality of hospital servers (S607).
  • the cloud server merges the patient data (S609).
  • the cloud server simultaneously requests a service from a plurality of consortium servers in response to the service selected by the user terminal (S611).
  • the consortium server provides a service by using the API (S613).
  • the cloud server measures and charges the API usage of the consortium server (S615).
  • FIG. 6 is a conceptual diagram illustrating a communication protocol of a cloud-based API management system according to an embodiment of the present invention.
  • the user terminal 400 and the Internet communication network, the cloud server 100 and the Internet communication network, the hospital server and the consortium server and the Internet communication network use the HTTPS security protocol, and the HTTP protocol is used between the load balancer and the firewall in the cloud server.
  • FIG. 7 is a flowchart illustrating a cloud-based API management method for simultaneously interworking a plurality of hospital servers and consortium servers according to an embodiment of the present invention.
  • the cloud server 100 inquires the patient number from a plurality of hospital servers 200 at the same time do (S705).
  • the cloud server 100 When the plurality of hospital servers 200 inquire the patient number (S707), and the cloud server 100 checks whether the patient number is registered in at least one hospital server among the plurality of hospital servers 200, the cloud server 100 ) transmits the registration confirmation of the patient number (S709), and transmits whether the patient number is registered to the user terminal 400 (S711).
  • the user terminal 400 logs in with the patient number (S713), and the cloud server 100 identifies hospital information (S717).
  • the cloud server 100 calls the medical service, it requests the hospital server 200 to interwork the medical service (S719).
  • the hospital server 200 starts the patient application treatment (S721), and requests the consortium server 300 to link the consortium service (S723).
  • FIG. 8 is a flowchart illustrating an architectural change of a cloud-based API call for concurrently interworking a plurality of hospital servers and consortium servers according to an embodiment of the present invention.
  • the user terminal 400 executes a dedicated application, executes the business logic of the cloud server 100 to request data, calls a standard API through API Loader, and provides API meta management of the cloud server.
  • Query API mapping Inspects API transmission data through API Field Validator, calls mapping API in conjunction with multiple hospital servers and consortium servers, and returns business logic and conversion data after executing field conversion to standard API through API Executor to provide services. Check the consistency of data sent and received through the API.

Landscapes

  • Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Medical Informatics (AREA)
  • Primary Health Care (AREA)
  • Public Health (AREA)
  • General Health & Medical Sciences (AREA)
  • Epidemiology (AREA)
  • Computing Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Biomedical Technology (AREA)
  • General Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Mathematical Physics (AREA)
  • Software Systems (AREA)
  • Tourism & Hospitality (AREA)
  • Strategic Management (AREA)
  • Operations Research (AREA)
  • Marketing (AREA)
  • Human Resources & Organizations (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Pathology (AREA)
  • Medical Treatment And Welfare Office Work (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

본 발명은 다수개의 병원서버 및 컨소시엄서버를 동시다발적으로 연동하기 위한 클라우드 기반의 API스펙 관리 방법에 관한 것이다. 사용자단말이 전용 애플리케이션을 실행하여 개인 식별 정보를 입력하면, 클라우드서버가 다수개의 병원서버에서 동시에 환자 번호를 조회하는 단계와, 클라우드서버가 다수개의 병원서버 중 적어도 하나의 병원서버에서 상기 환자 번호의 등록여부가 확인되면 사용자단말에 상기 환자 번호의 등록여부를 전달하는 단계와, 사용자단말이 환자번호로 로그인을 진행하고, 진료서비스를 호출하면 클라우드서버가 병원정보를 식별하여 병원서버에 진료서비스 연동을 요청하는 단계를 포함한다. 또한 환자 데이터를 병합하여, 클라우드 서버가 사용자 단말이 선택한 서비스에 대응하여 다수의 컨소시엄 서버에 동시에 서비스 연동을 요청하는 단계를 포함한다.

Description

다수개의 병원서버 및 컨소시엄서버를 동시다발적으로 연동하기 위한 클라우드 기반의 API스펙 관리방법
본 발명은 다수개의 병원서버 및 컨소시엄서버를 동시다발적으로 연동하기 위한 클라우드 기반의 API 관리방법에 관한 것으로, 특히 다수개의 병원서버 및 컨소시엄서버를 동시다발적으로 연동하여 클라우드서버에서 통합 인터페이스를 제공하는 클라우드 기반의 API스펙 관리방법에 관한 것이다.
최근 전염병의 확산과 의료기관 내 감염 방지를 위해서 의료기관 비대면 서비스가 전세계적으로 주목을 받고 있다. 특히 병원 내 대면 접촉 및 키오스크 업체 등 병원과 연관된 컨소시엄 업체 및 서비스 제공업자들이 모바일로 제공하는 서비스가 요청되고 있으나, 다수개의 병원들과 컨소시엄사의 데이터베이스가 상이하여 연동의 어려움이 있다. 또한, 서로 다른 병원시스템으로 인하여 서비스 개발을 하려면 병원별로 소스가 필요한 문제가 있다. 병원은 서로 다른 기존 레거시 병원 시스템인 EMR, LIS, OCS, PACS, MIS, HIS, ERP 등 병원 시스템 관리에 대한 데이터 접근 및 데이터를 서비스 하기 위한 다양한 형태의 인터페이스가 필요하다. 추가로 여러 형태의 미들웨어가 있어 이에 따른 데이터 인터페이스가 필요하다. 인터페이스 방법은 API, HTTPS, 웹서비스, 소켓통신, HTTP(SOAP), 프로시저 호출 등 다양한 N개의 구조가 있는 데이터 연동 시스템이 필요하다.
선행기술로는 등록특허 제10-1989474호(클라우드 기반의 전자처방 전송 시스템 및 방법)가 있으며, 선행기술은 출원인의 등록특허로서 병원서버 내에 배치된 API빌더부를 통해 고유의 API에 따라 처방정보를 변환하고 이를 기초로 전자처방을 전송하는 시스템을 개시하고 있다.
선행기술에서 병원서버내에 배치되는 API빌더부는 EMR DB로부터 환자정보와 처방정보를 추출하여 API를 이용하여 처방정보와 환자정보를 변환한다. 즉, API빌더부에서 데이터소스를 생성하며, SQL쿼리 작성가이드를 통한 간편 작성과 API빌더를 통한 표준 데이터로의 변환 후 반복 검증을 통해 진행할 수 있다. 이를 통해 이종 DBMS간의 데이터와 서로 다른 개발언어로 개발된 데이터들을 표준화할 수 있다. 그러나 이러한 시스템은 서로 다른 각각의 병원서버나 의료기관서버내에 API빌더가 설치되어 통합 관리의 어려움이 있다. 또한 API를 관리하는 데 있어 수동으로 관리되어, 데이터의 정합성이 체크되지 못하고 있는 실정이다.
본 발명이 해결하고자 하는 과제는 클라우드서버가 사전정의된 API를 병원서버 및 컨소시엄서버에 제공하여 환자가 병원서버 및 컨소시엄서버에 직접 접속할 필요없이 클라우드서버를 통해 진료서비스 및 실손보험청구 등의 서비스를 간편하게 제공하기 위한 다수개의 병원서버 및 컨소시엄서버를 동시다발적으로 연동하기 위한 클라우드 기반의 API스펙 관리 방법을 제공하는 데 있다.
본 발명의 실시예에 따른 다수개의 병원서버 및 컨소시엄서버를 동시다발적으로 연동하기 위한 클라우드 기반의 API스펙 관리 방법은, 사용자단말이 전용애플리케이션에서 환자번호조회, 진료예약, 약조제, 결제 및 실손보험청구 서비스 중 적어도 하나의 서비스를 선택하는 단계와, 사용자단말이 환자고유정보 및 서비스선택결과를 클라우드서버에 전송하는 단계와, 클라우드서버가 환자고유정보에 기초하여 다수개의 병원서버에 동시에 환자데이터를 요청하는 단계와, 클라우드서버가 다수개의 병원서버로부터 환자데이터를 수신하는 단계와, 클라우드서버가 환자데이터를 병합하는 단계와, 클라우드서버가 사용자단말이 선택한 서비스에 대응하여 다수개의 컨소시엄서버에 서비스를 요청하는 단계와, 다수개의 컨소시엄서버가 API를 활용하여 요청된 서비스를 제공하는 단계를 포함한다.
본 발명에 의하면 Private API가 병원의 오픈API가 되어 후방생태계의 기준이 되는 효과가 있다. 서로 다른 각각의 병원시스템에서도 하나의 원소스로 서비스 개발이 가능하다. 또한, 다수개의 병원서버 및 다수개의 컨소시엄서버에 동시다발적으로 연동이 가능하여 환자데이터에 대한 통합 관리가 가능하다. 또한, 다수개의 병원서버 및 컨소시엄서버의 환자데이터를 추출하여 병합함으로써 환자에게 통합인터페이스 제공이 가능하다.
또한, 병원서버나 컨소시엄서버는 사용자단말이 직접 접속하지 않아 보안성이 강화된다. 수만개의 병원 및 컨소시엄사에 적용이 가능하여 확장성이 높다.
또한, 병원 및 컨소시엄의 다양한 데이터 서식과 상관없이 하나의 환자용앱으로 모바일 서비스를 제공할 수 있다. 또한, 병원 및 컨소시엄은 생성된 데이터구조를 동일한 서비스를 요구하는 다른 앱에서도 API엔진을 통해 별도의 개발작업이 없이 오픈 API 기능으로 데이터를 제공할 수 있다.
도 1은 본 발명의 실시예에 따른 다수개의 병원서버 및 컨소시엄서버를 동시다발적으로 연동하기 위한 클라우드 기반의 API스펙 관리시스템을 설명하는 구성도이다.
도 2는 본 발명의 실시예에 따른 클라우드서버와 병원서버의 구성을 나타내는 도면이다.
도 3은 본 발명의 실시예에 따른 클라우드서버의 API생성부의 동작방법을 설명하는 흐름도이다.
도 4는 본 발명의 실시예에 따른 병원서버의 API엔진부의 동작방법을 설명하는 흐름도이다.
도 5는 본 발명의 실시예에 따른 다수개의 병원서버 및 컨소시엄서버를 동시다발적으로 연동하기 위한 클라우드 기반의 API스펙 관리방법을 설명하는 흐름도이다.
도 6은 본 발명의 실시예에 따른 클라우드 기반의 API 관리시스템의 통신프로토콜을 설명하는 개념도이다.
도 7은 본 발명의 실시예에 따른 다수개의 병원서버 및 컨소시엄서버를 동시다발적으로 연동하기 위한 클라우드 기반의 API스펙 관리방법을 설명하는 흐름도이다.
도 8은 본 발명의 실시예에 따른 다수개의 병원서버 및 컨소시엄서버를 동시다발적으로 연동하기 위한 클라우드 기반의 API호출의 아키텍처 변화를 설명하는 흐름도이다.
본 명세서에 개시되어 있는 본 발명의 개념에 따른 실시 예들에 대해서 특정한 구조적 또는 기능적 설명은 단지 본 발명의 개념에 따른 실시 예들을 설명하기 위한 목적으로 예시된 것으로서, 본 발명의 개념에 따른 실시 예들은 다양한 형태들로 실시될 수 있으며 본 명세서에 설명된 실시 예들에 한정되지 않는다.
본 발명의 개념에 따른 실시 예들은 다양한 변경들을 가할 수 있고 여러 가지 형태들을 가질 수 있으므로 실시 예들을 도면에 예시하고 본 명세서에서 상세하게 설명하고자 한다. 그러나 이는 본 발명의 개념에 따른 실시 예들을 특정한 개시 형태들에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물, 또는 대체물을 포함한다.
본 명세서에서 사용한 용어는 단지 특정한 실시 예를 설명하기 위해 사용된 것으로서, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 명세서에서, "포함하다" 또는 "가지다" 등의 용어는 본 명세서에 기재된 특징, 숫자, 단계, 동작, 구성 요소, 부분품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성 요소, 부분품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.
이하, 본 명세서에 첨부된 도면들을 참조하여 본 발명의 실시 예들을 상세히 설명한다. 용어를 정의하면, API스펙이란 API를 쉽게 설명하고 표현하기 위한 정의와 규칙들을 말한다. API를 보다 이해하기 쉽도록 보여주고 다양한 프로그래밍 언어의 코드로 자동생성이 가능하다.
도 1은 본 발명의 실시예에 따른 다수개의 병원서버 를 동시다발적으로 연동하기 위한 클라우드 기반의 API스펙 관리시스템을 설명하는 구성도이다.
도 1을 참조하면, API 관리시스템(10)은 클라우드서버(100)와 다수개의 병원서버(200), 다수개의 컨소시엄서버(300), 사용자단말(400)로 구성된다. 클라우드서버(100)는 다수개의 병원서버(100) 및 다수개의 컨소시엄서버(300)에 제공하는 API를 생성하고, 제공된 API를 관리하는 기능을 수행할 수 있다. 다수개의 컨소시엄서버(300)는 약국서버(310), PHR서버(320), 보험사서버(330), 은행사서버(340), 카드사서버(350), 블록체인서버(360)로 구성될 수 있다. 클라우드서버(100)가 사전정의된 API를 병원서버 및 컨소시엄서버에 제공하여 사용자단말(400)이 진료서비스 및 실손보험청구 등의 서비스를 요청시 병원서버 및 컨소시엄서버에 직접 접속할 필요없이 클라우드서버를 통해 간편하게 제공할 수 있다.
도 2는 본 발명의 실시예에 따른 클라우드서버와 병원서버의 구성을 나타내는 도면이다.
도 2를 참조하면, 클라우드서버(100)는 API생성부(110), API관리부(120), API호출부(125), 데이터검증부(130), 데이터병합부(140), 저작권관리부(150), 과금부(160), 모니터링부(170), 데이터베이스(180)로 구성된다.
API생성부(110)는 병원서버들 및 컨소시엄서버의 통합 인터페이스를 제공하기 위한 사전정의된 API를 생성할 수 있다. 병원서버 및 컨소시엄서버의 데이터베이스 정보를 표준화하기 위한 API일 수 있다. API생성부(110)는 데이터소스를 정의하고, SQL 및 프로시져를 등록할 수 있다. 또한, API생성부(110)는 미들웨어 접속정보 및 호출 경로를 등록하며 웹서비스 접속정보와 URL을 등록할 수 있다.
API관리부(120)는 사용자단말로부터 서비스호출을 수신하면 다수개의 병원서버 및 컨소시엄서버에 동시다발적으로 환자번호조회, 진료예약, 결제 및 실손보험청구 서비스를 제공하도록 해당 서비스와 매칭되는 API를 호출할 수 있다. API관리부(120)는 API제약조건 관리 기능을 통해 입력 및 출력 오류 체크를 수행할 수 있다. API관리부(120)는 각 병원서버 및 컨소시엄서버의 API 서비스의 상태, 버전정보, 메모리사용량, 디스크사용량, 서버의 CPU 사용량 등을 모니터링할 수 있다. API관리부(120)는 민감정보에 대해 암호화하여 데이터베이스에 저장할 수 있다. API관리부(120)는 API의 도메인 관리를 할 수 있다. API관리부(120)는 메타데이터에서 관리하는 API스펙이 변경되는 경우, 자동 배포를 위한 메타데이터가 추가될 수 있다. 즉, 표준화된 매핑정의서가 작성되고, 처리방식에 따라 표준화 작성된 프로토타입 탬플릿에 매핑 샘플 예시가 이용되어 표준화된 소스 적재프로그램이 생성되도록 프로그램화된 프로세서 및 추출된 데이터를 선택적으로 등록할 수 있다.
API호출부(125)는 API 호출을 자동으로 하도록 구현되며, 다수개의 병원서버 및 컨소시엄 서버들과 병렬적으로 동시에 호출이 가능하도록 동작한다.
데이터검증부(130)는 생성된 API의 오류테스트를 수행할 수 있다. 오류데이터가 있으면 데이터를 수정한 후 데이터 및 API를 저장 및 배포할 수 있다.
데이터병합부(140)는 다수개의 병원서버로부터 환자데이터를 수신하여 병합할 수 있다. 환자가 여러 곳의 병원을 이용하는 경우, 각각의 병원서버로부터 환자데이터를 수신하여 이를 병합하여 편의성을 높일 수 있다.
저작권관리부(150)는 각각의 병원서버별 식별할 수 있는 분류체계를 통해 저작권 관리를 할 수 있다. 저작권관리부(150)는 프로그램 소스 및 버전 관리가 가능하고, 기능별 또는 아키텍처별 관리번호 분류체계를 두어 기능별 인터페이스 가이드 기준을 제공할 수 있다.
과금부(160)는 병원서버의 사전정의된 API를 확인한 후 컨소시엄서버에서 API를 활용하는 경우 과금을 할 수 있다. 과금부(160)는 컨소시엄서버의 API사용량 측정 및 그룹별로 사용 현황/통계를 반영할 수 있다.
모니터링부(170)는 다수개의 병원서버와 컨소시엄서버와의 연동에 대해 모니터링을 수행할 수 있다. 데이터베이스(180)는 API도구를 저장할 수 있다.
즉, 사전정의된 API스펙을 메타데이터로 등록하여 API를 병원서버에 제공할 수 있다. 종래에는 엑셀, confluence에서 관리하던 API스펙을 메타데이터로 등록하여 각각의 병원서버에 적합한 API스펙을 선택하고, 각각의 병원서버의 API엔진에 자동으로 배포할 수 있도록 구성할 수 있다.
또한, API메타데이터를 클라우드서버(100)에서 관리함으로써 규격화된 DATA 형태로 클라우드서버와 병원서버가 방화벽을 통해 연동하여 환자용 앱서비스를 빠르게 구축할 수 있다. 구체적으로, 환자용 앱 서비스를 제공함에 있어서 환자용 컨텐츠 메뉴를 정의하고, 이에 맞는 데이터구조를 모든 병원에 표준화로 적용하기 위하여 컨텐츠 메뉴 화면별 데이터구조를 오픈API 형태로 정의할 수 있다. 각각의 병원은 여기에 맞는 데이터를 SQL, JSON, XML, 데이터 전문 형태로 추출하면 API가 규격화된 데이터 형태로 클라우드서버와 연동하여 환자용 앱 서비스를 빠르게 구축하여 서비스를 제공할 수 있다. 이를 통하여 모든 병원을 동일한 하나의 환자용 앱으로 모바일 서비스를 가능하게 할 수 있다. 병원은 한 번 만들어진 데이터구조를 동일한 서비스를 요구하는 다른 앱에서도 API를 통하여 별도의 개발 작업 없이 오픈 API기능으로 데이터를 제공할 수 있다. 또한, API별 샘플화면 URL링크가 제공되어, 병원담당자가 보다 용이하게 작성할 수 있다.
또한, 클라우드서버(100)는 개발자 및 테스터를 지원하기 위한 가상의 데이터 관리가 제공되고, 실제 서비스 지원을 위한 운영자 및 운영테스터를 지원하는 실제 데이터 확인할 수 있다. 다수개의 데이터 인터페이스를 1개의 비즈니스 로직이 구현하는 단계에서, 개발/테스트/검증을 요청하는 단계와 앱 어플리케이션 또는 응용 어플리케이션의 배포 단계와 새로운 서비스 개발 후 구동을 제공하는 전체 연결 방법을 제공할 수 있다. 클라우드서버(100)는다수개의 데이터 인터페이스를 1개의 비즈니스 로직이 연동되는 단계에서, 병원의 보안 및 의료법에 기준한 내부의 보안 정책을 지키며 전체 연결 방법을 제공할 수 있다. 클라우드서버(100)는다수개의 병원의 인터페이스를 진행하기 위한 인프라 구축 및 연동에 대한 연결 방법을 제공할 수 있다. 이때, 기본 API 서버 내부 시스템은 전용VPN으로 구성할 수 있다. 클라우드서버(100)는 병원서버의 표준화된 API를 확인한 후 컨소시엄 그룹이 해당 내용을 보고 오픈 API형태로 인터페이스를 가이드 하는 방법을 제공할 수 있다.
제1병원서버(210)는 EMR DB(211), 컨소시엄인터페이스(213), API엔진부(215)로 구성된다. EMR DB(211)는 환자정보, 진단/처방정보, 입원정보, 원무정보 등이 저장될 수 있다. 컨소시엄 인터페이스(213)는 환자대기시스템, 지능형순번기시스템, 주차관리시스템, 결제관리시스템, 실손청구시스템, 처방전달시스템 등으로 구성된다. EMR DB(211)와 컨소시엄 인터페이스(213)의 구성은 예시적으로 도시한 것으로 이에 대해 한정하는 것은 아니다.
API엔진부(215)는 EMR DB(211)로부터 데이터를 추출할 수 있다. API엔진부(215)는 클라우드서버로부터 수신된 병원서버별 API(Application Programming Interface)를 수신하여 로딩하고, 클라우드서버로부터 API메타정보를 로딩하여 API서비스를 수행할 수 있다. API엔진부(225)는 병원서버내에 설치되어 모바일서비스와 병원서버를 연결하는 미들웨어로서, 다양한 환경의 병원 레거시와 접속하여 API를 지원하는 개발도구이다. 즉, 병원서버내에 설치되여 환자용 앱 서비스 뿐 아니라 병원내 다양한 시스템과 연동을 위한 Restful API 개발 및 게이트웨이 서버로 활용할 수 있다. API엔진부(215)는 EMR 데이터추출부(216), API수신부(217), API메타정보 로딩부(218), API서비스부(219)로 구성된다. EMR 데이터추출부(216)은 EMR DB(211)로부터 데이터를 추출할 수 있다. API수신부(217)은 클라우드서버로부터 생성된 병원서버별 API를 수신할 수 있다. API메타데이터 로딩부(218)는 클라우드서버로부터 API메타데이터를 로딩할 수 있다. API서비스부(219)는 API메타데이터에 기초하여 API서비스를 구동할 수 있다.
도 3은 본 발명의 실시예에 따른 클라우드서버의 API생성부의 동작방법을 설명하는 흐름도이다. 도 3을 참조하면, 클라우드서버는 표준API를 정의한다(S301). 이후에, 클라우드서버는 병원서버 또는 컨소시엄서버별 API를 생성한다(S203). 생성된 API를 테스트하고(S305), 오류가 없으면 데이터 및 API를 저장 및 배포하고, 오류가 있으면 데이터를 수정하여 데이터 및 API를 저장 및 배포할 수 있다.
도 4는 본 발명의 실시예에 따른 병원서버의 API엔진부의 동작방법을 설명하는 흐름도이다.
도 4를 참조하면, 병원서버의 API엔진부는 API엔진을 시작한다(S401). 이후에 API수행부가 API메타정보를 클라우드서버로부터 로딩한다(S403). 로딩한 API 메타정보에 기초하여 API서비스를 구동한다(S405).
도 5는 본 발명의 실시예에 따른 다수개의 병원서버 를 동시다발적으로 연동하기 위한 클라우드 기반의 API 관리방법을 설명하는 흐름도이다.
도 5를 참조하면, 사용자단말(400)이 전용애플리케이션에서 환자번호조회, 진료예약, 약조제, 결제 및 실손보험청구 서비스 중 적어도 하나의 서비스를 선택한다(S601). 사용자단말이 환자고유정보 및 서비스선택결과를 클라우드서버에 전송한다(S603). 클라우드서버가 환자고유정보에 기초하여 다수개의 병원서버에 동시에 환자데이터를 요청한다(S605). 클라우드서버가 다수개의 병원서버로부터 환자데이터를 수신한다(S607). 클라우드서버가 환자데이터를 병합한다(S609). 클라우드서버가 사용자단말이 선택한 서비스에 대응하여 다수의 컨소시엄서버에 서비스를 동시에 요청한다(S611). 컨소시엄서버가 API를 활용하여 서비스를 제공한다(S613). 클라우드서버가 컨소시엄서버의 API사용량을 측정하여 과금한다(S615).
도 6은 본 발명의 실시예에 따른 클라우드 기반의 API 관리시스템의 통신프로토콜을 설명하는 개념도이다. 사용자단말(400)과 인터넷통신망, 클라우드서버(100)와 인터넷통신망, 병원서버 및 컨소시엄서버와 인터넷통신망은 HTTPS 보안프로토콜을 사용하며, 클라우드서버내의 로드발란서와 방화벽간에는 HTTP프로토콜을 사용한다.
도 7은 본 발명의 실시예에 따른 다수개의 병원서버 및 컨소시엄서버를 동시다발적으로 연동하기 위한 클라우드 기반의 API 관리방법을 설명하는 흐름도이다.
도 7을 참조하면, 사용자단말(400)이 전용 애플리케이션을 실행하여(S701), 개인 식별 정보를 입력하면(S703), 클라우드서버(100)가 다수개의 병원서버(200)에서 동시에 환자 번호를 조회한다(S705).
다수개의 병원서버(200)가 환자번호를 조회하고(S707), 클라우드서버(100)가 다수개의 병원서버(200) 중 적어도 하나의 병원서버에서 상기 환자 번호의 등록여부가 확인되면 클라우드서버(100)에 환자 번호의 등록확인을 전달하고(S709), 사용자단말(400)에 상기 환자 번호의 등록여부를 전달한다(S711).
사용자단말(400)이 환자번호로 로그인을 진행하고(S713), 클라우드서버(100)가 병원정보를 식별한다(S717). 클라우드서버(100)가 진료서비스를 호출하면 병원서버(200)에 진료서비스 연동을 요청한다(S719). 병원서버(200)가 환자용앱 진료를 시작하고(S721), 컨소시엄서버(300)에 컨소시엄 서비스 연동을 요청한다(S723).
도 8은 본 발명의 실시예에 따른 다수개의 병원서버 및 컨소시엄서버를 동시다발적으로 연동하기 위한 클라우드 기반의 API호출의 아키텍처 변화를 설명하는 흐름도이다.
도 8을 참조하면, 사용자단말(400)이 전용 애플리케이션을 실행하여 클라우드서버(100)의 비즈니스 로직을 실행하여 데이터를 요청하고, API Loader를 통한 표준API를 호출하여, 클라우드서버의 API메타관리로 API매핑을 조회한다. API Field Validator를 통해 API전송 데이터 검사를 실시하여, 다수개의 병원서버 및 컨소시엄 서버와 연동하여 매핑 API를 호출한 후, API Executor를 통해 표준 API로 필드변환을 실행한 후 비즈니스 로직과 변환 데이터를 리턴을 하여 서비스를 제공한다. API를 통해 주고 받는 데이터의 정합성을 체크한다.
발명은 도면에 도시된 실시 예를 참고로 설명되었으나 이는 예시적인 것에 불과하며, 본 기술 분야의 통상의 지식을 가진 자라면 이로부터 다양한 변형 및 균등한 타 실시 예가 가능하다는 점을 이해할 것이다. 따라서, 본 발명의 진정한 기술적 보호 범위는 첨부된 등록청구범위의 기술적 사상에 의해 정해져야 할 것이다.

Claims (3)

  1. 다수개의 병원서버 및 컨소시엄서버를 동시다발적으로 연동하기 위한 클라우드 기반의 API스펙 관리 시스템에 있어서,
    클라우드서버, 다수개의 병원서버, 다수개의 컨소시엄서버, 사용자단말로 구성되되,
    상기 클라우드서버는,
    병원서버들 및 컨소시엄서버의 통합 인터페이스를 제공하기 위한 사전정의된 API를 생성하는 API생성부;
    사용자단말로부터 서비스호출을 수신하면 다수개의 병원서버 및 컨소시엄서버에 동시다발적으로 환자번호조회, 진료예약, 결제 및 실손보험청구 서비스 중 적어도 하나의 서비스를 제공하도록 해당 서비스와 매칭되는 API를 호출하는API관리부;
    생성된 API의 오류테스트를 수행하는 데이터검증부;
    다수개의 병원서버로부터 환자데이터를 수신하여 병합하는 데이터병합부를 포함하는 다수개의 병원서버 및 컨소시엄서버를 동시다발적으로 연동하기 위한 클라우드 기반의 API스펙 관리 시스템.
  2. 제1항에 있어서,
    병원서버의 사전정의된 API를 확인한 후 컨소시엄서버에서 API를 활용하는 경우 컨소시엄서버의 API사용량 측정 및 그룹별로 사용 현황/통계를 반영하여 과금을 하는 과금부를 더 포함하는 다수개의 병원서버를 동시다발적으로 연동하기 위한 클라우드 기반의 API스펙 관리 시스템.
  3. 제1항에 있어서,
    상기 병원서버는 EMR DB와 API엔진부로 구성되되,
    상기 API엔진부는 EMR DB로부터 데이터를 추출하고, 클라우드서버로부터 수신된 병원서버별 API(Application Programming Interface)를 수신하여 로딩하고, 클라우드서버로부터 API메타정보를 로딩하여 API서비스를 수행하는 다수개의 병원서버를 동시다발적으로 연동하기 위한 클라우드 기반의 API 스펙관리 시스템.
PCT/KR2021/001956 2020-06-18 2021-02-16 다수개의 병원서버 및 컨소시엄서버를 동시다발적으로 연동하기 위한 클라우드 기반의 api스펙 관리방법 WO2021256657A1 (ko)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN202180033827.0A CN115516574B (zh) 2020-06-18 2021-02-16 用于以同时并发的方式联动多台医院服务器和联盟服务器的基于云的api规格管理方法
US17/925,710 US11854692B2 (en) 2020-06-18 2021-02-16 Cloud-based API spec management method for simultaneously interconnecting pluralities of hospital servers and consortium servers
EP21826175.8A EP4170674A4 (en) 2020-06-18 2021-02-16 CLOUD-BASED API SPEK MANAGEMENT METHOD FOR CONNECTING A VARIETY OF HOSPITAL AND CONSORTIUM SERVERS SIMULTANEOUSLY

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2020-0074341 2020-06-18
KR1020200074341A KR102226292B1 (ko) 2020-06-18 2020-06-18 다수개의 병원서버 및 컨소시엄서버를 동시다발적으로 연동하기 위한 클라우드 기반의 api스펙 관리방법

Publications (1)

Publication Number Publication Date
WO2021256657A1 true WO2021256657A1 (ko) 2021-12-23

Family

ID=75147815

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2021/001956 WO2021256657A1 (ko) 2020-06-18 2021-02-16 다수개의 병원서버 및 컨소시엄서버를 동시다발적으로 연동하기 위한 클라우드 기반의 api스펙 관리방법

Country Status (5)

Country Link
US (1) US11854692B2 (ko)
EP (1) EP4170674A4 (ko)
KR (1) KR102226292B1 (ko)
CN (1) CN115516574B (ko)
WO (1) WO2021256657A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024026361A1 (en) * 2022-07-26 2024-02-01 Hokmabadi Dental Corporation Methods and apparatuses for teledentistry

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102371078B1 (ko) * 2021-08-13 2022-03-07 주식회사 레몬헬스케어 이종 시스템간 데이터 유통을 위한 표준api 규격 자동화 방법 및 시스템
KR20230103332A (ko) * 2021-12-31 2023-07-07 동은정보기술주식회사 보안을 강화한 웹소켓 기반의 실시간 비대면 진료 서비스 제공 시스템 및 방법

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20120093560A (ko) * 2011-02-15 2012-08-23 김민준 의료정보 중계 방법
KR101561242B1 (ko) * 2013-12-23 2015-10-19 (주)솔트웍스 병원의료시스템의 통합 시스템 및 그 방법, 병원의료시스템의 통합 시스템 활용 서비스 지원 시스템 및 그 방법
KR20160144570A (ko) * 2015-06-08 2016-12-19 (주)유메디 병원 진료 예약 플랫폼 시스템 및 이의 방법
JP2019503017A (ja) * 2015-10-29 2019-01-31 ティー, ライ, キングTEE, Lai, King デジタル健康管理および遠隔患者監視のために設計されたモバイルプラットフォームのためのシステムおよび方法
KR101989474B1 (ko) 2018-11-23 2019-06-14 (주)레몬헬스케어 클라우드 기반의 전자처방 전송 시스템 및 방법
KR102097622B1 (ko) * 2019-05-17 2020-04-06 권성석 개인건강기록 공유 시스템 및 방법

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6854123B1 (en) * 2000-05-09 2005-02-08 International Business Machines Corporation Method, system, and program for mapping standard application program interfaces (APIs) to user interface APIs
JP2004334541A (ja) * 2003-05-08 2004-11-25 Nippon Telegr & Teleph Corp <Ntt> 標準ａｐｉ使用方法の検査装置及びその検査方法と、標準ａｐｉ使用方法検査プログラム及びそのプログラムを記録した記録媒体と、アプリケーション検査システム及びその検査方法
US20160321400A1 (en) * 2015-03-30 2016-11-03 Zoll Medical Corporation Clinical Data Handoff in Device Management and Data Sharing
US20180181716A1 (en) * 2016-12-27 2018-06-28 General Electric Company Role-based navigation interface systems and methods
US10740215B2 (en) * 2017-04-26 2020-08-11 Jpmorgan Chase Bank, N.A. System and method for implementing an API validator tool
KR20190059578A (ko) * 2017-11-23 2019-05-31 (주)메디큐브 무선보안을 적용한 스마트헬스케어 시스템
CN108111334B (zh) * 2017-12-04 2021-11-12 叶轻舟 一种网络应用节点的集成系统和方法
US10460235B1 (en) * 2018-07-06 2019-10-29 Capital One Services, Llc Data model generation using generative adversarial networks
US11170892B1 (en) * 2018-12-06 2021-11-09 VEEV, Inc. Methods and systems for analysis of requests for radiological imaging examinations
CN110322940B (zh) * 2019-07-15 2023-06-27 山东浪潮智慧医疗科技有限公司 一种医疗数据共享的访问授权方法及系统
KR102110388B1 (ko) * 2020-01-13 2020-05-13 주식회사 브이티더블유 지역적 블록체인 기반의 cPHR 서비스 운용 방법
CN111276236A (zh) * 2020-02-04 2020-06-12 广州市行心信息科技有限公司 用于医疗信息化行业的万能接口服务器
CN112261022A (zh) * 2020-10-15 2021-01-22 四川长虹电器股份有限公司 一种基于api网关的安全认证方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20120093560A (ko) * 2011-02-15 2012-08-23 김민준 의료정보 중계 방법
KR101561242B1 (ko) * 2013-12-23 2015-10-19 (주)솔트웍스 병원의료시스템의 통합 시스템 및 그 방법, 병원의료시스템의 통합 시스템 활용 서비스 지원 시스템 및 그 방법
KR20160144570A (ko) * 2015-06-08 2016-12-19 (주)유메디 병원 진료 예약 플랫폼 시스템 및 이의 방법
JP2019503017A (ja) * 2015-10-29 2019-01-31 ティー, ライ, キングTEE, Lai, King デジタル健康管理および遠隔患者監視のために設計されたモバイルプラットフォームのためのシステムおよび方法
KR101989474B1 (ko) 2018-11-23 2019-06-14 (주)레몬헬스케어 클라우드 기반의 전자처방 전송 시스템 및 방법
KR102097622B1 (ko) * 2019-05-17 2020-04-06 권성석 개인건강기록 공유 시스템 및 방법

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4170674A4

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024026361A1 (en) * 2022-07-26 2024-02-01 Hokmabadi Dental Corporation Methods and apparatuses for teledentistry

Also Published As

Publication number Publication date
EP4170674A4 (en) 2024-01-31
CN115516574B (zh) 2023-08-01
CN115516574A (zh) 2022-12-23
EP4170674A1 (en) 2023-04-26
US11854692B2 (en) 2023-12-26
US20230197256A1 (en) 2023-06-22
KR102226292B1 (ko) 2021-03-10

Similar Documents

Publication Publication Date Title
WO2021256657A1 (ko) 다수개의 병원서버 및 컨소시엄서버를 동시다발적으로 연동하기 위한 클라우드 기반의 api스펙 관리방법
JP5377494B2 (ja) ヘルスケアセマンティック相互運用プラットフォーム
US7617500B2 (en) Generic framework for integrating components with different interfaces in an enterprise application integration environment
US20090271426A1 (en) Converting between software objects
US20070124451A1 (en) Embedded system and method for controlling, monitoring of instruments or devices and processing their data via control and data protocols that can be combined or interchanged
US10446274B2 (en) Open healthcare apparatus and method
WO2021125779A1 (ko) Api 통합관리를 위한 클라우드 기반의 api 메타데이터 관리방법 및 시스템
JP2005504455A (ja) 適応マルチプロトコル通信システム
WO2021006682A1 (ko) 클라우드 기반의 실손의료비 보험금 청구 시스템 및 방법
US9367644B2 (en) Object tree walking
CN116414370A (zh) 基于低代码的平台构建方法、装置、介质及电子设备
WO2009107952A2 (en) System and method for purchase and distribution managing of hospital articles
US20090210748A1 (en) Methods and systems to test airline information systems
CN113381866A (zh) 基于网关的服务调用方法、装置、设备及存储介质
JP2013520730A (ja) 臨床用支払いネットワークシステム及び方法
Huff Clinical data exchange standards and vocabularies for messages.
WO2018186713A1 (ko) 금융상품 가입방법 및 그 시스템
Broyles et al. The evolving health information infrastructure
CN1932760B (zh) 用于运行应用程序的系统和方法
CN110377401A (zh) 基于idea的事务请求处理方法、装置、服务器和存储介质
EP1122644A1 (en) A method and system for dynamically dispatching function calls from a first execution environment to a second execution environment
Krämer Component meets service: what does the mongrel look like?
CN112582036A (zh) 一种医疗数据交换平台
JP5122043B2 (ja) 機能提供サイトを有する診療支援ネットワークシステム
Besana et al. Distributed Workflows: The OpenKnowledge Experience

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21826175

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2021826175

Country of ref document: EP

Effective date: 20230118