WO2021125779A1 - Api 통합관리를 위한 클라우드 기반의 api 메타데이터 관리방법 및 시스템 - Google Patents

Api 통합관리를 위한 클라우드 기반의 api 메타데이터 관리방법 및 시스템 Download PDF

Info

Publication number
WO2021125779A1
WO2021125779A1 PCT/KR2020/018425 KR2020018425W WO2021125779A1 WO 2021125779 A1 WO2021125779 A1 WO 2021125779A1 KR 2020018425 W KR2020018425 W KR 2020018425W WO 2021125779 A1 WO2021125779 A1 WO 2021125779A1
Authority
WO
WIPO (PCT)
Prior art keywords
api
server
hospital
cloud
hospital server
Prior art date
Application number
PCT/KR2020/018425
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 EP20903836.3A priority Critical patent/EP4080355A4/en
Priority to CN202080093673.XA priority patent/CN114981775B/zh
Priority to US17/785,655 priority patent/US11842231B2/en
Publication of WO2021125779A1 publication Critical patent/WO2021125779A1/ko

Links

Images

Classifications

    • 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
    • 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/44—Arrangements for executing specific programs
    • G06F9/451—Execution arrangements for user interfaces
    • 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/60—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 operation of medical equipment or devices
    • G16H40/67—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 operation of medical equipment or devices for remote operation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/26—Functional testing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3055—Monitoring arrangements for monitoring the status of the computing system or of the computing system component, e.g. monitoring if the computing system is on, off, available, not available
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G06F11/366—Software debugging using diagnostics
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/36—Software reuse
    • 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
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • 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/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H04L67/025—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP] for remote control or remote monitoring of applications
    • 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
    • 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/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks

Definitions

  • the present invention relates to a cloud-based API metadata management method and system for integrated API management.
  • it is possible to interwork in a standardized data form by creating and distributing API specification management and customized API for each hospital in a cloud server, It relates to a cloud-based API metadata management method and system for integrated API management that can provide an API metadata model so that a user can directly select a customized API specification.
  • 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.
  • the problem to be solved by the present invention is a cloud-based API for integrated management of APIs that integrates and manages API metadata installed in hospitals and medical institutions in a cloud server, and provides an API metadata model so that a user hospital can directly select an API specification.
  • a metadata management method and system may be provided.
  • a cloud-based API metadata management method includes the steps of: the API tool installation unit of the cloud server loads the API tool stored in the database to install the API tool, and the API tool installation unit of the cloud server installs the standard API Define, the API generating unit generates API for each hospital server, and the test unit of the cloud server tests the generated API for each hospital server to correct the data if there is error data, and if there is no error data, data and API for each hospital server storage and distribution.
  • the cloud-based API metadata management system loads the API tool and installs the API tool, defines a standard API to create an API for each hospital server, and tests the generated API for each hospital server. If there is no error data, a cloud server that stores and distributes API for each hospital server, and a hospital that receives API for each hospital server received from the cloud server to start the API engine, and loads metadata information from the cloud server to drive the API service Includes server.
  • API management of a plurality of hospitals is performed in the cloud server, so that integrated management is possible.
  • By managing API metadata in the cloud server it helps hospitals to select API specifications suitable for hospitals before simple writing, thereby reducing the writing time quickly and efficiently.
  • mobile services can be provided with a single patient app regardless of the various data formats of hospitals and medical institutions.
  • hospitals and medical institutions can provide data with an open API function without separate development work through the API engine in other apps that require the same service for the generated data structure.
  • hospitals and medical institutions can provide customized API specifications to hospitals and medical institutions by directly selecting them through the metadata model. It is easy to create, modify and manage the interface of hospital patient medical information through API engine.
  • FIG. 1 is a flowchart illustrating a cloud-based API metadata management system for integrated API management according to an embodiment of the present invention.
  • FIG. 2 is a configuration diagram illustrating each configuration of a hospital server according to an embodiment of the present invention.
  • FIG. 3 is a flowchart illustrating a method of operating a cloud server according to an embodiment of the present invention.
  • FIG. 4 is a flowchart illustrating a method of operating an API engine of a hospital server 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 flowchart illustrating a cloud-based API metadata management system for integrated API management according to an embodiment of the present invention.
  • the API metadata management system 10 includes a cloud server 100 , a plurality of hospital servers 200 , 300 , 400 , and a firewall 500 .
  • the cloud server 100 may generate an API provided to hospital servers and perform a function of managing the provided API. That is, by managing the API metadata in the cloud server 100, the cloud server and the hospital server are interlocked through a firewall in a standardized DATA form 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 this standard to all hospitals.
  • the API can work with the cloud server in a standardized data form to quickly build an app service for patients and provide the service. Through this, it is possible to enable mobile services for all hospitals with the same single patient app. Hospitals 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. In addition, URL links to sample screens for each API are provided so that hospital personnel can write more easily.
  • the cloud server 100 may provide a metadata model so that a user hospital can select a desired API specification.
  • the metadata model can manage the full version in order to manage and distribute metadata for API management installed in the customer's internal network in the cloud.
  • each hospital server To be installed on each hospital server, it can be configured so that it can be selected and distributed from the meta model when creating an API.
  • synchronization can be performed for each hospital server.
  • previously set SQL definitions and middleware fixed variables may be excluded from synchronization.
  • Metadata model includes domain dictionary, API parameter, parameter constraint setting, API classification, API definition, hospital-specific API setting, hospital information, data source, hospital parameter setting, middleware fixed variable, and SQL definition.
  • the domain dictionary is used when processing terms and conventions in the data model program for API management.
  • the domain dictionary may include a domain name, a domain Korean name, a domain description, a management memo, a data type, a format description, an input date and time, an inputter id, a modification date and time, and a modifier id.
  • API parameter corresponds to the table name of the SQL statement to be used when creating a data model program for API management, and classifies the API specification.
  • API parameters may include parameter id, domain name, input id, API id, mandatory or not, modification date and time, input/output classification, input date and time, modifier id, and parameter order.
  • Parameter constraint setting is used when processing parameter ID in data model program for API management.
  • Parameter constraint setting may include parameter id, input id, rule type, modification date and time, rule value, modifier id, and input date and time.
  • API classification includes information on API classification ID and classification name when creating a data model program for API management.
  • the API classification may include a classification id, input date and time, classification name, modifier id, input character id, and modification date and time.
  • API setting for each hospital is processed by data source definition-SQL, procedure registration, middleware access protection-call path registration, web service connection information-URL registration according to the access method when creating API in the API management data model program.
  • Hospital-specific API settings may include hospital API number, whether rule check is used, API id, input date and time, hospital code, inputter id, access method, modification date and time, API type, and modifier id.
  • Hospital information may include hospital code, hospital name message key, address message key, phone message key, and URL setting.
  • the data source may include a data source id, an input person id, a data source name, a modification date and time, a hospital code, a modifier id, and an input date and time.
  • Hospital parameter setting may include hospital parameter id, test value, hospital api number, input date and time, parameter id, input person id, tuxedo field name, modification date and time, tuxedo field ID, and modifier id.
  • the middleware fixed variable may include hospital api number, field value, field name, field description, sequence number, input date and time, field ID, input person id, data type, modification date and time, test value, and modifier id.
  • the SQL definition may include hospital api number, input date and time, query sequence number, input person id, editor SQL, modification date and time, SQL text, and modifier id.
  • the cloud server 100 includes an API tool installation unit 110 , an API generation unit 120 , an API management unit 130 , a test unit 140 , and a database 150 .
  • the API tool installation unit 110 may install an API tool for API creation.
  • the API generator 120 may generate an API for each hospital server based on the API specification selected by the user by providing the API metadata model.
  • the API for each hospital server may be an API for standardizing database information in the hospital server, such as prescription information.
  • the API generator 120 may define a data source and register SQL and procedures. Also, the API generator 120 may register middleware access information and a call path, and may register web service access information and URI.
  • the API management unit 130 may perform input and output error checking through the API constraint management function.
  • the API management unit 130 may monitor the status of each hospital server's API service, version information, memory usage, disk usage, CPU usage of the server, and the like.
  • the API management unit 130 may encrypt sensitive information and store it in a database.
  • the API management unit 130 may manage the domain of the API.
  • the API management unit 130 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 a processing method, so that a standardized source loading program can be generated, and a programmed processor and extracted data can be selectively registered.
  • the test unit 140 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 database 150 may store API tools.
  • the plurality of hospital servers is composed of a first hospital server 200 , a second hospital server 300 , and a third hospital server 400 , and the number of hospital servers is not limited.
  • the first hospital server 200 is composed of an EMR DB 210 and a QAPI Engine (QAB) 220 .
  • the EMR DB 210 may store patient information, medical treatment information, prescription information, hospital care information, hospitalization information, and history information.
  • the QAB 220 refers to an engine in which the API operates. Data can be extracted from EMR DB.
  • the QAB 220 may receive and load an API (Application Programming Interface) for each hospital server received from the cloud server, and may perform API services by loading API meta information from the cloud server.
  • the QAB 220 is installed in the hospital server and is a middleware connecting the mobile service and the hospital server. It is a development tool that supports API by connecting to 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 hospital server 200 includes an EMR DB 210 and a QAB 220 , and the EMR DB 210 includes patient information, medical treatment information, prescription information, hospital care information, hospitalization information, and history information. can be saved.
  • the type of information stored in the EMB DB unit 210 is not limited.
  • the QAB 220 includes an EMR data extraction unit 221 , an API receiving unit 223 , an API meta information loading unit 225 , and an API service unit 227 .
  • the EMR data extraction unit 221 may extract data from the EMR DB 210 .
  • the API receiver 223 may receive the API for each hospital server generated from the cloud server.
  • the API metadata loading unit 225 may load API metadata from the cloud server.
  • the API service unit 227 may drive the API service based on API metadata.
  • FIG. 3 is a flowchart illustrating a method of operating a cloud server according to an embodiment of the present invention.
  • the cloud server installs an API tool ( S201 ). Thereafter, the cloud server defines a standard API (S203).
  • the cloud server creates an API for each hospital server (S205).
  • the step of creating an API for each hospital server includes defining a data source, registering SQL and procedures, registering middleware access information and call path, and registering web service access information and URI do.
  • the cloud server may distribute the changed API logic.
  • the generated API may be tested (S207), and if there is no error, data and API are stored and distributed (S211), and if there is an error, data and API may be stored and distributed by correcting the data.
  • FIG. 4 is a flowchart illustrating an operation method of QAB of a hospital server according to an embodiment of the present invention.
  • the QAB of the hospital server is an API engine.
  • the API engine is started by inputting an access password (S301).
  • the API meta information is loaded from the cloud server (S303).
  • the API service is driven based on the loaded API meta information (S305).

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Health & Medical Sciences (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Medical Informatics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Public Health (AREA)
  • Primary Health Care (AREA)
  • Epidemiology (AREA)
  • Biomedical Technology (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Human Computer Interaction (AREA)
  • Pathology (AREA)
  • General Business, Economics & Management (AREA)
  • Business, Economics & Management (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

본 발명은 클라우드 기반의 API 메타데이터 관리방법 및 관리시스템에 관한 것이다. 클라우드 기반의 API 메타데이터 관리방법은 클라우드서버의 API도구설치부가 데이터베이스에 저장된 API도구를 로딩하여 API도구를 설치하는 단계와, 클라우드서버의 API도구설치부가 표준 API를 정의하고, API생성부가 병원서버별 API를 생성하는 단계와, 클라우드서버의 테스트부가 생성된 병원서버별 API를 테스트하여 오류데이터가 있으면 데이터를 수정하고, 오류데이터가 없으면 병원서버별 데이터 및 API를 저장 및 배포하는 단계를 포함한다.

Description

API 통합관리를 위한 클라우드 기반의 API 메타데이터 관리방법 및 시스템
본 발명은 API 통합관리를 위한 위한 클라우드 기반의 API 메타데이터 관리 방법 및 시스템에 관한 것으로, 특히 클라우드서버에서 API스펙 관리 및 병원별 맞춤형 API를 생성 및 배포하여 규격화된 데이터 형태로 연동이 가능하며, 사용자가 맞춤형 API 스펙을 직접 선택할 수 있도록 API메타데이터모델을 제공 가능한 API 통합관리를 위한 클라우드 기반의 API 메타 데이터 관리 방법 및 시스템에 관한 것이다.
선행기술로는 등록특허 제10-1989474호(클라우드 기반의 전자처방 전송 시스템 및 방법)가 있으며, 선행기술은 출원인의 등록특허로서 병원서버 내에 배치된 API빌더부를 통해 고유의 API에 따라 처방정보를 변환하고 이를 기초로 전자처방을 전송하는 시스템을 개시하고 있다.
선행기술에서 병원서버내에 배치되는 API빌더부는 EMR DB로부터 환자정보와 처방정보를 추출하여 API를 이용하여 처방정보와 환자정보를 변환한다. 즉, API빌더부에서 데이터소스를 생성하며, SQL쿼리 작성가이드를 통한 간편 작성과 API빌더를 통한 표준 데이터로의 변환 후 반복 검증을 통해 진행할 수 있다. 이를 통해 이종 DBMS간의 데이터와 서로 다른 개발언어로 개발된 데이터들을 표준화할 수 있다. 그러나 이러한 시스템은 서로 다른 각각의 병원서버나 의료기관서버내에 API빌더가 설치되어 통합 관리의 어려움이 있다.
본 발명이 해결하고자 하는 과제는 병원 및 의료기관에 설치된 API메타데이터를 클라우드서버에서 통합 관리하고, 사용자인 병원이 직접 API스펙을 선택하도록 API메타데이터모델을 제공하는 API 통합관리를 위한 클라우드 기반의 API 메타데이터 관리방법 및 시스템을 제공할 수 있다.
본 발명의 실시예에 따른 클라우드 기반의 API 메타데이터 관리방법은, 클라우드서버의 API도구설치부가 데이터베이스에 저장된 API도구를 로딩하여 API도구를 설치하는 단계와, 클라우드서버의 API도구설치부가 표준 API를 정의하고, API생성부가 병원서버별 API를 생성하는 단계와, 클라우드서버의 테스트부가 생성된 병원서버별 API를 테스트하여 오류데이터가 있으면 데이터를 수정하고, 오류데이터가 없으면 병원서버별 데이터 및 API를 저장 및 배포하는 단계를 포함한다.
본 발명의 실시예에 따른 클라우드 기반의 API메타데이터 관리시스템은, API도구를 로딩하여 API도구를 설치하되, 표준 API를 정의하여 병원서버별 API를 생성하며, 생성된 병원서버별 API를 테스트하여 오류데이터가 없으면 병원서버별 API를 저장 및 배포하는 클라우드서버와, 클라우드서버로부터 수신된 병원서버별 API를 수신하여 API 엔진을 시작하고, 메타데이터정보를 클라우드서버로부터 로딩하여 API서비스를 구동하는 병원서버를 포함한다.
본 발명에 의하면 다수개의 병원의 API 관리가 클라우드서버에서 이루어져 통합 관리가 가능하다. API메타데이터를 클라우드서버에서 관리하여 병원에서 간편작성전에 병원에 맞는 API스펙을 선택할 수 있게 도와 신속하고 효율적으로 작성시간을 단축시킬 수 있다.
또한, 병원 및 의료기관의 다양한 데이터 서식과 상관없이 하나의 환자용앱으로 모바일 서비스를 제공할 수 있다. 또한, 병원 및 의료기관은 생성된 데이터구조를 동일한 서비스를 요구하는 다른 앱에서도 API엔진을 통해 별도의 개발작업이 없이 오픈 API 기능으로 데이터를 제공할 수 있다.
또한, 병원 및 의료기관이 메타데이터모델을 통해 직접 선택함으로써 병원 및 의료기관에 맞춤형 API스펙을 제공할 수 있다. 병원의 환자 의료정보를 API엔진을 통해 인터페이스의 생성 및 수정 관리가 용이하다.
도 1은 본 발명의 실시예에 따른 API 통합관리를 위한 클라우드 기반의 API 메타데이터 관리시스템을 설명하는 순서도이다.
도 2는 본 발명의 실시예에 따른 병원서버의 각 구성을 설명하는 구성도이다.
도 3은 본 발명의 실시예에 따른 클라우드서버의 동작 방법을 설명하는 순서도이다.
도 4는 본 발명의 실시예에 따른 병원서버의 API엔진의 동작방법을 설명하는 순서도이다.
본 명세서에 개시되어 있는 본 발명의 개념에 따른 실시 예들에 대해서 특정한 구조적 또는 기능적 설명은 단지 본 발명의 개념에 따른 실시 예들을 설명하기 위한 목적으로 예시된 것으로서, 본 발명의 개념에 따른 실시 예들은 다양한 형태들로 실시될 수 있으며 본 명세서에 설명된 실시 예들에 한정되지 않는다.
본 발명의 개념에 따른 실시 예들은 다양한 변경들을 가할 수 있고 여러 가지 형태들을 가질 수 있으므로 실시 예들을 도면에 예시하고 본 명세서에서 상세하게 설명하고자 한다. 그러나 이는 본 발명의 개념에 따른 실시 예들을 특정한 개시 형태들에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물, 또는 대체물을 포함한다.
본 명세서에서 사용한 용어는 단지 특정한 실시 예를 설명하기 위해 사용된 것으로서, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 명세서에서, "포함하다" 또는 "가지다" 등의 용어는 본 명세서에 기재된 특징, 숫자, 단계, 동작, 구성 요소, 부분품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성 요소, 부분품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.
이하, 본 명세서에 첨부된 도면들을 참조하여 본 발명의 실시 예들을 상세히 설명한다. 용어를 정의하면, API스펙이란 API를 쉽게 설명하고 표현하기 위한 정의와 규칙들을 말한다. API를 보다 이해하기 쉽도록 보여주고 다양한 프로그래밍 언어의 코드로 자동생성이 가능하다.
도 1은 본 발명의 실시예에 따른 API 통합관리를 위한 클라우드 기반의 API 메타데이터 관리시스템을 설명하는 순서도이다.
도 1을 참조하면, API 메타데이터 관리시스템(10)은 클라우드서버(100)와 다수개의 병원서버(200, 300, 400), 방화벽(500)으로 구성된다. 클라우드서버(100)는 병원서버들에 제공하는 API를 생성하고, 제공된 API를 관리하는 기능을 수행할 수 있다. 즉, API메타데이터를 클라우드서버(100)에서 관리함으로써 규격화된 DATA 형태로 클라우드서버와 병원서버가 방화벽을 통해 연동하여 환자용 앱서비스를 빠르게 구축할 수 있다. 구체적으로, 환자용 앱 서비스를 제공함에 있어서 환자용 컨텐츠 메뉴를 정의하고, 이에 맞는 데이터구조를 모든 병원에 표준화로 적용하기 위하여 컨텐츠 메뉴 화면별 데이터구조를 오픈API 형태로 정의할 수 있다. 각각의 병원은 여기에 맞는 데이터를 SQL, JSON, XML 형태로 추출하면 API가 규격화된 데이터 형태로 클라우드서버와 연동하여 환자용 앱 서비스를 빠르게 구축하여 서비스를 제공할 수 있다. 이를 통하여 모든 병원을 동일한 하나의 환자용 앱으로 모바일 서비스를 가능하게 할 수 있다. 병원은 한 번 만들어진 데이터구조를 동일한 서비스를 요구하는 다른 앱에서도 API를 통하여 별도의 개발 작업 없이 오픈 API기능으로 데이터를 제공할 수 있다. 또한, API별 샘플화면 URL링크가 제공되어, 병원담당자가 보다 용이하게 작성할 수 있다.
클라우드서버(100)는 사용자인 병원이 원하는 API스펙을 선택하도록 메타데이터모델을 제공할 수 있다. 메타데이터모델은 고객사 내부망에 설치된 API관리용 메타정보를 클라우드에서 관리하고 배포하기 위해 전체버전 관리를 할 수 있다.
각각의 병원서버에 설치되기 위해 API생성시 메타모델에서 선택하여 배포할 수 있도록 구성할 수 있다. 병원서버별 API사용현황을 관리하면서 API스펙에 변경이 발생하는 경우, 병원서버별로 동기화를 할 수 있다. 이때, 기존에 설정된 SQL 정의, 미들웨어고정변수는 동기화에서 제외될 수 있다. 이를 통해 다양한 병원 시스템의 이종의 DBMS, 미들웨어, 웹서비스 등에 접속방식을 제공할 수 있다.
메타데이터모델은 도메인사전, API파라메터, 파라메터제약설정, API분류, API정의, 병원별API설정, 병원정보, 데이터소스, 병원파라메터설정, 미들웨어고정변수, SQL정의를 포함한다.
도메인사전은 API관리용 데이터모델 프로그램에서 용어 및 규약을 처리하는 경우에 사용된다. 도메인사전은 도메인명, 도메인한글명, 도메인설명, 관리메모, 데이터유형, 포맷설명, 입력일시,입력자id, 수정일시, 수정자id를 포함할 수 있다.
API파라메터는 API관리용 데이터 모델 프로그램을 생성하는 경우 사용하게 될 SQL문의 테이블명에 해당하며, API스펙을 분류한다. API파라메터는 파라메터id, 도메인명, 입력자id, API id, 필수여부, 수정일시, 입출력구분, 입력일시, 수정자id, 파라미터순서를 포함할 수 있다.
파라메터제약설정은 API관리용 데이터모델 프로그램에서 파라메터ID를 처리하는 경우에 사용된다. 파라메터제약설정은 파라메터id, 입력자id, 규칙유형, 수정일시, 규칙값, 수정자id, 입력일시를 포함할 수 있다.
API분류는 API관리용 데이터모델 프로그램을 생성하는 경우, API분류ID 및 분류명의 정보를 포함한다. API분류는 분류id, 입력일시, 분류명, 수정자id, 입력자id, 수정일시를 포함할 수 있다.
병원별API설정은 API관리용 데이터모델 프로그램에서 API생성시 접속방식에 따른 데이터 소스정의-SQL, 프로시저 등록, 미들웨어 접속보호-호출경로등록, 웹서비스접속정보-URL등록으로 처리된다. 병원별API설정은 병원API번호, 룰체크사용여부, API id, 입력일시, 병원코드, 입력자id, 접속방식, 수정일시, API유형, 수정자id를 포함할 수 있다.
병원정보는 병원코드, 병원명메세지key, 주소메세지key, 전화메세지key, URL설정을 포함할 수 있다.
데이터소스는 데이터소스id, 입력자id, 데이터소스명, 수정일시, 병원코드, 수정자id, 입력일시를 포함할 수 있다.
병원파라메터설정은 병원파라메터id, 테스트값, 병원api번호, 입력일시, 파라메터id, 입력자id, 턱시도필드명, 수정일시, 턱시도 필드ID, 수정자id를 포함할 수 있다.
미들웨어 고정변수는 병원api번호, 필드값, 필드명, 필드설명, 순번, 입력일시, 필드ID, 입력자id, 데이터유형, 수정일시, 테스트값, 수정자id를 포함할 수 있다.
SQL정의는 병원api번호, 입력일시, 쿼리순번, 입력자id, 편집기SQL, 수정일시, SQL원문, 수정자id를 포함할 수 있다.
클라우드서버(100)는 API도구설치부(110), API생성부(120), API관리부(130), 테스트부(140), 데이터베이스(150)로 구성된다. API도구설치부(110)는 API생성을 위한 API도구를 설치할 수 있다. API생성부(120)는 API생성부(120)는 API메타데이터모델을 제공하여 사용자로부터 선택된 API스펙에 기초하여 병원서버별 API를 생성할 수 있다. 상기 병원서버별 API는 처방정보 등의 병원서버내의 데이터베이스 정보를 표준화하기 위한 API일 수 있다.
API생성부(120)는 데이터소스를 정의하고, SQL 및 프로시져를 등록할 수 있다. 또한, API생성부(120)는 미들웨어 접속정보 및 호출 경로를 등록하며 웹서비스 접속정보와 URI를 등록할 수 있다.
API관리부(130)는 API제약조건 관리 기능을 통해 입력 및 출력 오류 체크를 수행할 수 있다. API관리부(130)는 각 병원서버의 API 서비스의 상태, 버전정보, 메모리사용량, 디스크사용량, 서버의 CPU 사용량 등을 모니터링할 수 있다. API관리부(130)는 민감정보에 대해 암호화하여 데이터베이스에 저장할 수 있다. API관리부(130)는 API의 도메인 관리를 할 수 있다. API관리부(130)는 메타데이터에서 관리하는 API스펙이 변경되는 경우, 자동 배포를 위한 메타데이터가 추가될 수 있다. 즉, 표준화된 매핑정의서가 작성되고, 처리방식에 따라 표준화 작성된 프로토타입 탬플릿에 매핑 샘플 예시가 이용되어 표준화된 소스 적재프로그램이 생성되도록 프로그램화된 프로세서 및 추출된 데이터를 선택적으로 등록할 수 있다.
테스트부(140)는 생성된 API의 오류테스트를 수행할 수 있다. 오류데이터가 있으면 데이터를 수정한 후 데이터 및 API를 저장 및 배포할 수 있다. 데이터베이스(150)는 API도구를 저장할 수 있다.
다수개의 병원서버는 제1병원서버(200), 제2병원서버(300), 제3병원서버(400)로 구성되며, 병원서버의 개수를 제한하지 않는다.
제1병원서버(200)는 EMR DB(210)와 QAB(QAPI Engine; 220)으로 구성된다. EMR DB(210)는 환자정보, 진료정보, 처방정보, 원무정보, 입원정보, 이력정보가 저장될 수 있다. QAB(220)는 API가 동작하는 엔진을 의미한다. EMR DB로부터 데이터를 추출할 수 있다. QAB(220)는 클라우드서버로부터 수신된 병원서버별 API(Application Programming Interface)를 수신하여 로딩하고, 클라우드서버로부터 API메타정보를 로딩하여 API서비스를 수행할 수 있다. QAB(220)는 병원서버내에 설치되어 모바일서비스와 병원서버를 연결하는 미들웨어이다. 다양한 환경의 병원 레거시와 접속하여 API를 지원하는 개발도구이다. 즉, 병원서버내에 설치되여 환자용 앱 서비스 뿐 아니라 병원내 다양한 시스템과 연동을 위한 Restful API 개발 및 게이트웨이 서버로 활용할 수 있다.
도 2는 본 발명의 실시예에 따른 병원서버의 각 구성을 설명하는 구성도이다. 도 2를 참조하면, 병원서버(200)는 EMR DB(210)와 QAB(220)로 구성되고, EMR DB(210)는 환자정보, 진료정보, 처방정보, 원무정보, 입원정보, 이력정보가 저장될 수 있다. EMB DB부(210)에 저장되는 정보의 종류가 제한되는 것은 아니다. QAB(220)는 EMR 데이터추출부(221), API수신부(223), API메타정보 로딩부(225), API서비스부(227)로 구성된다. EMR 데이터추출부(221)은 EMR DB(210)로부터 데이터를 추출할 수 있다. API수신부(223)은 클라우드서버로부터 생성된 병원서버별 API를 수신할 수 있다. API메타데이터 로딩부(225)는 클라우드서버로부터 API메타데이터를 로딩할 수 있다. API서비스부(227)는 API메타데이터에 기초하여 API서비스를 구동할 수 있다.
도 3은 본 발명의 실시예에 따른 클라우드서버의 동작 방법을 설명하는 순서도이다. 도 3을 참조하면, 클라우드서버는 API도구를 설치한다(S201). 이후에, 클라우드서버는 표준 API를 정의한다(S203).
클라우드서버는 병원서버별 API를 생성한다(S205). 이때, 병원서버별 API를 생성하는 단계는, 데이터소스를 정의하고, SQL 및 프로시져를 등록하는 단계와, 미들웨어 접속정보 및 호출 경로를 등록하는 단계, 웹서비스 접속정보와 URI를 등록하는 단계를 포함한다. 이때, 클라우드서버는 변경된 API로직을 배포할 수 있다.
생성된 API를 테스트하고(S207), 오류가 없으면 데이터 및 API를 저장 및 배포하고(S211), 오류가 있으면 데이터를 수정하여 데이터 및 API를 저장 및 배포할 수 있다.
도 4는 본 발명의 실시예에 따른 병원서버의 QAB의 동작방법을 설명하는 순서도이다.
도 4를 참조하면, 병원서버의 QAB는 API엔진으로서, 먼저 접속 암호를 입력하여 API 엔진을 시작한다(S301). 이후에 API 메타정보를 클라우드서버로부터 로딩한다(S303). 로딩한 API 메타정보에 기초하여 API서비스를 구동한다(S305).
발명은 도면에 도시된 실시 예를 참고로 설명되었으나 이는 예시적인 것에 불과하며, 본 기술 분야의 통상의 지식을 가진 자라면 이로부터 다양한 변형 및 균등한 타 실시 예가 가능하다는 점을 이해할 것이다. 따라서, 본 발명의 진정한 기술적 보호 범위는 첨부된 등록청구범위의 기술적 사상에 의해 정해져야 할 것이다.

Claims (7)

  1. 클라우드 기반의 API 메타데이터 관리방법에 있어서,
    (A-1) 클라우드서버의 API도구설치부가 데이터베이스에 저장된 API도구를 로딩하여 API도구를 설치하는 단계;
    (A-2) 클라우드서버의 API도구설치부가 표준 API를 정의하고, API생성부가 병원서버별 API를 생성하는 단계; 및
    (A-3) 클라우드서버의 테스트부가 생성된 병원서버별 API를 테스트하여 오류데이터가 있으면 데이터를 수정하고, 오류데이터가 없으면 병원서버별 데이터 및 API를 저장 및 배포하는 단계를 포함하고,
    상기 API생성부는 병원서버에 API메타데이터모델을 제공하여 병원서버로부터 선택된 API스펙에 기초하여 병원서버별 API를 생성하고, 상기 병원서버별 API는 병원서버내의 데이터베이스 정보를 표준화하는 API이고,
    상기 API메타데이터모델은 병원별API설정을 포함하고, 상기 병원별API설정은 API관리용 데이터모델 프로그램에서 API생성시 접속방식에 따른 데이터 소스정의-SQL, 프로시저 등록, 미들웨어 접속보호-호출경로등록, 웹서비스접속정보-URL등록으로 처리되는 클라우드 기반의 API 메타데이터 관리방법.
  2. 제1항에 있어서,
    (B-1) 병원서버의 QAB가 클라우드서버로부터 수신된 병원서버별 API를 수신하여 API 엔진을 로딩하는 단계;
    (B-2) 병원서버의 QAB가 클라우드서버로부터 메타정보를 로딩하는 단계;
    (B-3) 병원서버의 QAB가 API서비스를 구동하는 단계를 더 포함하는 클라우드 기반의 API 메타데이터 관리방법.
  3. 제1항에 있어서,
    상기 (A-2)단계에서 병원서버별 API를 생성하는 단계는,
    데이터소스를 정의하고, SQL 및 프로시져를 등록하는 단계;
    미들웨어 접속정보 및 호출 경로를 등록하는 단계; 및
    웹서비스 접속정보와 URI를 등록하는 단계를 더 포함하는 클라우드 기반의 API 메타데이터 관리방법.
  4. 제1항에 있어서,
    (A-3)단계에서, 변경된 API로직을 배포하는 것을 특징으로 하는 클라우드 기반의 API 메타데이터 관리방법.
  5. 클라우드 기반의 API 메타 데이터 관리 시스템에 있어서,
    API도구를 로딩하여 API도구를 설치하되, 표준 API를 정의하여 병원서버별 API를 생성하며, 생성된 병원서버별 API를 테스트하여 오류데이터가 없으면 병원서버별 API를 저장 및 배포하는 클라우드서버;
    클라우드서버로부터 수신된 병원서버별 API를 수신하여 API 엔진을 시작하고, 메타데이터정보를 클라우드서버로부터 로딩하여 API서비스를 구동하는 병원서버를 포함하고,
    상기 클라우드서버의 API생성부는 병원서버에 API메타데이터모델을 제공하여 병원서버로부터 선택된 API스펙에 기초하여 병원서버별 API를 생성하고, 상기 병원서버별 API는 병원서버내의 데이터베이스 정보를 표준화하는 API이고,
    상기 API메타데이터모델은 병원별API설정을 포함하고, 상기 병원별API설정은 API관리용 데이터모델 프로그램에서 API생성시 접속방식에 따른 데이터 소스정의-SQL, 프로시저 등록, 미들웨어 접속보호-호출경로등록, 웹서비스접속정보-URL등록으로 처리되는 클라우드 기반의 API메타 데이터 관리 시스템.
  6. 제5항에 있어서,
    상기 클라우드서버는,
    API제약조건 관리 기능을 통해 입력 및 출력 오류 체크를 수행하며, 각 병원서버의 API 서비스의 상태, 버전정보, 메모리사용량, 디스크사용량, 서버의 CPU 사용량 중 적어도 하나를 모니터링하는 API관리부를 포함하는 클라우드 기반의 API메타 데이터 관리 시스템.
  7. 제5항에 있어서,
    상기 클라우드서버는,
    생성된 API의 오류테스트를 수행하여 오류데이터가 있으면 데이터를 수정한 후 데이터 및 API를 저장 및 배포하는 클라우드 기반의 API메타데이터 관리 시스템.
PCT/KR2020/018425 2019-12-16 2020-12-16 Api 통합관리를 위한 클라우드 기반의 api 메타데이터 관리방법 및 시스템 WO2021125779A1 (ko)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP20903836.3A EP4080355A4 (en) 2019-12-16 2020-12-16 CLOUD API METADATA MANAGEMENT METHOD AND SYSTEM FOR INTEGRATED API MANAGEMENT
CN202080093673.XA CN114981775B (zh) 2019-12-16 2020-12-16 用于api综合管理的基于云的api元数据管理方法及系统
US17/785,655 US11842231B2 (en) 2019-12-16 2020-12-16 Cloud-based API metadata management method and system for integrated API management

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020190167537A KR102171436B1 (ko) 2019-12-16 2019-12-16 Api 통합관리를 위한 클라우드 기반의 api 메타데이터 관리방법 및 시스템
KR10-2019-0167537 2019-12-16

Publications (1)

Publication Number Publication Date
WO2021125779A1 true WO2021125779A1 (ko) 2021-06-24

Family

ID=73129400

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2020/018425 WO2021125779A1 (ko) 2019-12-16 2020-12-16 Api 통합관리를 위한 클라우드 기반의 api 메타데이터 관리방법 및 시스템

Country Status (5)

Country Link
US (1) US11842231B2 (ko)
EP (1) EP4080355A4 (ko)
KR (1) KR102171436B1 (ko)
CN (1) CN114981775B (ko)
WO (1) WO2021125779A1 (ko)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102171436B1 (ko) * 2019-12-16 2020-10-29 주식회사 레몬헬스케어 Api 통합관리를 위한 클라우드 기반의 api 메타데이터 관리방법 및 시스템
KR102524829B1 (ko) * 2020-11-16 2023-04-24 주식회사 레몬헬스케어 통합 실손의료보험 자동청구방법 및 시스템
KR102371078B1 (ko) * 2021-08-13 2022-03-07 주식회사 레몬헬스케어 이종 시스템간 데이터 유통을 위한 표준api 규격 자동화 방법 및 시스템
KR102663094B1 (ko) * 2021-11-19 2024-05-03 에스케이 주식회사 단일 엔드포인트를 이용한 ai 모델 운영 장치 및 방법
KR20230073647A (ko) * 2021-11-19 2023-05-26 에스케이 주식회사 모델 서버 스케일링을 제어하는 ai 모델 운영 장치 및 방법
US20240061732A1 (en) * 2022-08-18 2024-02-22 Red Hat, Inc. Industry opinionated api managed service

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20120066395A (ko) * 2010-12-14 2012-06-22 한국전자통신연구원 네트워크 서비스 지원 시스템 및 그 방법
KR20130069174A (ko) * 2011-12-16 2013-06-26 주식회사 케이티 클라우드 서버 및 가상화 디바이스 ａｐｉ 제공 장치
KR20140036886A (ko) * 2012-09-18 2014-03-26 에스케이플래닛 주식회사 메타 정보 기반의 클라우드 서비스 방법
KR20140074608A (ko) * 2012-12-10 2014-06-18 포항공과대학교 산학협력단 다수의 클라우드 스토리지 서비스를 통합하는 가상 파일 시스템
KR20150073569A (ko) * 2013-12-23 2015-07-01 (주)솔트웍스 병원의료시스템의 통합 시스템 및 그 방법, 병원의료시스템의 통합 시스템 활용 서비스 지원 시스템 및 그 방법
KR101989474B1 (ko) 2018-11-23 2019-06-14 (주)레몬헬스케어 클라우드 기반의 전자처방 전송 시스템 및 방법
KR102171436B1 (ko) * 2019-12-16 2020-10-29 주식회사 레몬헬스케어 Api 통합관리를 위한 클라우드 기반의 api 메타데이터 관리방법 및 시스템

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101763648A (zh) * 2009-12-25 2010-06-30 湖南电气职业技术学院 一种医学像影数据集成方法
US9778924B2 (en) * 2013-06-06 2017-10-03 Wipro Limited Platform for enabling creation and use of an API for a specific solution
AU2015207840B2 (en) * 2014-07-31 2020-06-18 Samsung Electronics Co., Ltd. System and method of managing metadata
US9965337B2 (en) * 2014-09-16 2018-05-08 International Business Machines Corporation Profile-driven merging of API components
EP3362890A4 (en) * 2015-10-15 2019-05-08 Pokitdok Inc. SYSTEM AND METHOD FOR PERSISTENCE AND CORRELATION OF DYNAMIC METADATA ON API TRANSACTIONS
CN106250382A (zh) * 2016-01-28 2016-12-21 新博卓畅技术（北京）有限公司 一种元数据管理引擎系统及实现方法
US10825554B2 (en) * 2016-05-23 2020-11-03 Baidu Usa Llc Methods of feature extraction and modeling for categorizing healthcare behavior based on mobile search logs
CN107680690B (zh) * 2016-08-02 2021-01-26 四川智康科技有限责任公司 一种基于元数据的临床信息系统
US10684919B2 (en) * 2016-10-25 2020-06-16 Siemens Healthcare Gmbh Query with data distribution in a hospital network
CN106845268B (zh) * 2016-12-27 2019-05-24 银江股份有限公司 一种面向医疗机构的防止泄露患者隐私的系统及其方法
US11424023B2 (en) * 2017-03-23 2022-08-23 International Business Machines Corporation Scalable and traceable healthcare analytics management
US10740215B2 (en) * 2017-04-26 2020-08-11 Jpmorgan Chase Bank, N.A. System and method for implementing an API validator tool
CN107679071B (zh) * 2017-08-22 2020-12-18 中国科学院计算机网络信息中心 一种面向关系数据库的通用数据服务定制化封装方法
US10630639B2 (en) * 2017-08-28 2020-04-21 Go Daddy Operating Company, LLC Suggesting a domain name from digital image metadata
US20190114715A1 (en) * 2017-10-17 2019-04-18 Cleverland Holding LLC Method and system for processing pet insurance claims
US11099964B2 (en) * 2017-12-20 2021-08-24 Pivotal Software, Inc. Framework actuator integration
US11064013B2 (en) * 2018-05-22 2021-07-13 Netskope, Inc. Data loss prevention using category-directed parsers
CN108989384B (zh) * 2018-05-31 2020-08-14 华为技术有限公司 一种数据处理的方法、多云管理系统以及相关设备
RU2704873C1 (ru) * 2018-12-27 2019-10-31 Общество с ограниченной ответственностью "ПЛЮСКОМ" Система и способ управления базами данных (субд)
US11030084B2 (en) * 2019-01-18 2021-06-08 Salesforce.Com, Inc. API specification parsing at a mocking server
CN110083650B (zh) * 2019-04-25 2023-06-30 中电科嘉兴新型智慧城市科技发展有限公司 一种基于元数据自发现的数据查询接口自动生成方法
CN110059103B (zh) * 2019-04-28 2023-06-06 南京大学 一种跨平台统一的大数据sql查询方法
CN110335647B (zh) * 2019-06-21 2023-04-28 上海市精神卫生中心（上海市心理咨询培训中心） 一种临床数据标准化系统及标准化数据采集方法

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20120066395A (ko) * 2010-12-14 2012-06-22 한국전자통신연구원 네트워크 서비스 지원 시스템 및 그 방법
KR20130069174A (ko) * 2011-12-16 2013-06-26 주식회사 케이티 클라우드 서버 및 가상화 디바이스 ａｐｉ 제공 장치
KR20140036886A (ko) * 2012-09-18 2014-03-26 에스케이플래닛 주식회사 메타 정보 기반의 클라우드 서비스 방법
KR20140074608A (ko) * 2012-12-10 2014-06-18 포항공과대학교 산학협력단 다수의 클라우드 스토리지 서비스를 통합하는 가상 파일 시스템
KR20150073569A (ko) * 2013-12-23 2015-07-01 (주)솔트웍스 병원의료시스템의 통합 시스템 및 그 방법, 병원의료시스템의 통합 시스템 활용 서비스 지원 시스템 및 그 방법
KR101989474B1 (ko) 2018-11-23 2019-06-14 (주)레몬헬스케어 클라우드 기반의 전자처방 전송 시스템 및 방법
KR102171436B1 (ko) * 2019-12-16 2020-10-29 주식회사 레몬헬스케어 Api 통합관리를 위한 클라우드 기반의 api 메타데이터 관리방법 및 시스템

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
CN114981775B (zh) 2024-05-03
US20230046582A1 (en) 2023-02-16
US11842231B2 (en) 2023-12-12
EP4080355A1 (en) 2022-10-26
EP4080355A4 (en) 2024-01-03
KR102171436B1 (ko) 2020-10-29
CN114981775A (zh) 2022-08-30

Similar Documents

Publication Publication Date Title
WO2021125779A1 (ko) Api 통합관리를 위한 클라우드 기반의 api 메타데이터 관리방법 및 시스템
US7146609B2 (en) Method, system and article of manufacture for a firmware image
US20070067512A1 (en) Method, system and software arrangement for processing a device support file for a field device
US9552237B2 (en) API validation system
US20180107501A1 (en) Instantiation of javascript object
US20030217358A1 (en) Method, system, and article of manufacture for firmware downloads
US20180024979A1 (en) Forms conversion and deployment system for mobile devices
CN106412086B (zh) 一种利用协议描述文件自动生成通信代码的方法及系统
US20050188367A1 (en) Executable application configuration system
US20120167055A1 (en) Efficiently developing software using test cases to check the conformity of the software to the requirements
US7568196B2 (en) Initializing virtual machine that subsequently executes application
US8910122B2 (en) Validating translations of externalized content for inclusion in an application
CN103853535B (zh) 修改中间件的方法和装置
CN101207624A (zh) 用于在网络中配置应用部件的方法和系统
US20080244562A1 (en) Method of Identifying and Checking Software Installation Requirements
CN101120323A (zh) 用于测试设备的系统和方法
CN110659206A (zh) 基于微服务的模拟架构建立方法、装置、介质及电子设备
KR102226292B1 (ko) 다수개의 병원서버 및 컨소시엄서버를 동시다발적으로 연동하기 위한 클라우드 기반의 api스펙 관리방법
US8117042B2 (en) Communication and interface support system
US20050081189A1 (en) Aggregation of document elements into runtime code
CN114386853A (zh) 基于通用审核模型的数据审核处理方法、装置及设备
CN113778897A (zh) 接口的自动测试方法、装置、设备及存储介质
WO2023151397A1 (zh) 应用程序部署方法、装置、设备及介质
CN110262841A (zh) 一种对字节码进行增强的方法和装置
US20030028678A1 (en) Method, apparatus, and program for chaining server applications

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: 20903836

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: 2020903836

Country of ref document: EP

Effective date: 20220718