KR20230032807A - Secure platform system for analyzing cdm data in multi-institutional distributed network, and method of the same - Google Patents

Abstract

Various embodiments provide a secure platform system for analyzing CDM data in a multi-institutional distributed network, and a method thereof. According to various embodiments, a method comprises the steps of: generating, by an authentication server, a token for a user; generating, by a code signer, an electronic signature for an analysis code of the user; issuing, by a ticket issuing server, a ticket for the user; verifying, by a service server of each hospital, the user using the ticket and using the electronic signature to verify the analysis code; when verification of the user and the analysis code is successful, executing, by the service server, the analysis code to analyze CDM data of the hospital; and replying, by the service server, to the user with an analysis result of the CDM data. According to the present invention, patients do not have to worry about personal information being leaked outside the hospital.

Description

Platform system and method thereof for analyzing secure multi-organizational CDM data in a multi-organization distributed environment

Various embodiments relate to a medical information system and method thereof, and more particularly, to a network security platform system and method for safely and conveniently analyzing medical data of various hospitals.

Over the past decades, hospitals around the world have collected medical treatment and observation data on patients to form big data. However, since health big data is stored in different formats for each hospital, it is not suitable for multi-center research. In response, OHDSI (observational health data sciences and informatics), an international non-profit organization, has presented many software to support health big data analysis.

First, OHDSI provides the OMOP-CDM (observational medical outcomes partnership common data model) to standardize different data formats for different hospitals. OMOP-CDM is a common database schema for storing medical and observational data. OMOP-CDM supports popular DBMS such as Oracle and MS SQL Server. The hospital's data curator converts the original medical data in the hospital into OMOP-CDM through ETL (extract-transform-load).

Second, OHDSI provides Atlas as a platform for analyzing medical data converted to OMOP-CDM. Atlas is implemented in the form of a web application and supports functions such as cohort definition. The most distinctive feature of Atlas is that it automatically generates analysis codes to analyze data. This analysis code is written in R language. The user analyzes medical data by executing the analysis code generated through Atlas in his/her local computing environment. During execution, this analysis code accesses the remote OMOP-CDM database and reads necessary data. In addition, if two or more hospitals have prepared the OMOP-CDM database, the user can easily analyze the data of the corresponding hospitals through the same analysis code.

As such, although OHIDS supports various software for analyzing medical data expressed in OMOP-CDM, Atlas and OMOP-CDM still have some problems. One of them is that although OMOP-CDM data provides a unified representation of medical data, hospitals still keep their databases in isolated in-hospital networks. Such an operating environment reduces the accessibility to external users' data. Another of them is that users still have to individually prove their identity to each hospital in order to access their data. In other words, each hospital must operate a separate account database for authenticating users.

User authentication is essential for remote service development through the network. This is because the service must be provided only to authorized users. In particular, when services are distributed over a network, a special authentication protocol is required. When designing an authentication protocol without considering a distributed environment, a user account database must be operated for each service. Kerberos was designed to solve this.

Kerberos aims to separate user authentication and service access authorization, and for this purpose, it requires three main components: an authentication server, a ticket issuance server, and a service server. Among them, the service server means the aforementioned service distributed on the network, and there are several servers that provide the service (analyze CDM data). The authentication server plays a role in verifying the user's identity in conjunction with the user's account database. The user whose identity has been confirmed is issued a ticket to use the ticket generation server from the authentication server. The ticket issuing server issues a ticket allowing the user to use the service server to the identified user. When the service server verifies the ticket issued by the ticket issuing server, the service server can authorize service access to the user without a separate user account database. In addition, when a user accesses a new service server, it is possible to acquire access rights to the service server by presenting only the ticket of the authentication server to the ticket issuing server without performing identity verification from the beginning through the authentication server.

Although Kerberos provides convenient user authentication in a distributed network environment, it allows users to access only one service at a time. In Kerberos, only the information to prove the user's identity is encrypted and delivered, and the means to safely deliver additional data relies on the service.

As mentioned above, hospitals store medical data within the institution's local network for administrative and security reasons. Since this setting causes the resources to be analyzed (medical data) to be distributed on the network, it is difficult to integrate the medical data. On the other hand, in general, hospitals have their own form for storing their own data because they have individually accumulated data. Differences in data formats can be an obstacle when merging and further analyzing medical data collected from each institution. In addition, transferring data outside the hospital network without adequate security may violate patients' privacy. In addition, even if medical data is transmitted through a secure network channel between institutions, patients may not want their personal information to be included.

Therefore, in various embodiments, a user authenticated from a secure server group of a platform located on the Internet safely and quickly delivers medical data analysis codes to servers of hospitals connected to the platform, and the analysis results are also safely and quickly returned. There is a purpose.

Various embodiments provide a platform system and method thereof for analyzing secure multi-agency CDM data in a multi-agency distributed environment.

A platform system according to various embodiments includes an authentication server configured to generate a token for a user, a code signer configured to generate an electronic signature for an analysis code of the user, and a ticket configured to issue a ticket for the user. The ticket issuing server and each hospital verify the user using the ticket, verify the analysis code using the electronic signature, and when the verification of the user and the analysis code succeeds, the analysis code and a service server configured to execute and analyze CDM data of the hospital.

The method of the platform system according to various embodiments includes generating a token for a user by an authentication server, generating a digital signature for an analysis code of the user by a code signer, and generating a ticket by a ticket issuing server for the user. issuing, the service server of each hospital verifying the user using the ticket, verifying the analysis code using the electronic signature, and when the verification of the user and the analysis code succeeds, and analyzing the CDM data of the hospital by the service server executing the analysis code.

According to various embodiments, since medical data of hospitals connected to the platform are unified into CDM, an external researcher can analyze data of multiple hospitals through the same methodology. And, since the CDM data is not transmitted outside the local network of the hospital and analyzed only inside the service server, patients do not have to worry about leakage of personal information outside the hospital.

According to various embodiments, users perform (multiple steps) authentication through a group of secure servers on the platform located outside the hospital's local network. Users who pass authentication do not perform additional authentication at each hospital that requests data analysis. Therefore, each hospital does not have to operate an account database to verify the user's identity.

The CDM data analysis code written by the user must not be altered by a third party while being transferred from the user to the hospital's service server. Various embodiments may ensure the integrity of the analysis code in this process.

1 is a diagram schematically illustrating a platform system and method thereof for analyzing secure multi-organization CDM data in a multi-organization distributed environment according to various embodiments.
FIG. 2 is a diagram showing in detail a process in which the user of FIG. 1 performs platform authentication through an authentication server.
FIG. 3 is a diagram showing in detail a process in which the user of FIG. 1 receives an electronic signature for an analysis code for analyzing CDM data from a code signer.
FIG. 4 is a diagram showing in detail a process in which the user of FIG. 1 obtains a ticket for accessing CDM data of all hospitals of the platform through a ticket issuing server.
5 and 6 are diagrams showing in detail a process in which the user of FIG. 1 distributes an analysis code including a ticket and an electronic signature to all hospitals connected to the platform through a relay server and receives an analysis result.
7 is a diagram illustrating an internal configuration of a service server of a platform system according to various embodiments.

Hereinafter, various embodiments of this document will be described with reference to the accompanying drawings.

1 is a diagram schematically illustrating a platform system 100 and method thereof for analyzing secure multi-agency CDM data in a multi-agency distributed environment according to various embodiments.

Referring to FIG. 1 , a platform system 100 according to various embodiments is built on a distributed network in which each hospital stores CDM data in its own server and is connected to a network. Specifically, the platform system 100 includes a secure server group 110, a certificate authority (CA) 120, and a hospital network 130 of each hospital. The security server group 110 includes an authentication server (AS) 111, a code signer (CS) 113, a ticket-granting server (TGS) 115, and a relay server. It is composed of (relaying server; RS) 117. Each of the servers 111, 113, 115, and 117 of the security server group 110 may be implemented in the form of each application program in one computer or independently in each of a plurality of computers connected to a network. The independently operating certification authority 120 is connected to the security server group 110 via the Internet. The hospital network 130 is composed of a service server (SS) 131 and a database 133 for CDM data. This platform system 100 uses OMOP-CDM as a medical CDM. Therefore, the platform system 100 uses analysis codes (AC) written in the R language to analyze the medical data converted to OMOP-CDM. The hospital network 130 is connected to the secure server group 110 via the Internet.

The method of analyzing the data of each component constituting the platform system 100 and the hospital connected to the platform system 100 by the user 140 is as follows. First, in step 151 , the user 140 proves his or her identity to the security server group 110 . The authentication server 111 is responsible for user authentication and issues a token to the authenticated user 140 . Subsequently, in step 153, the user 140 sends the analysis code to the code signer 113, and obtains an electronic signature for the analysis code created to analyze the medical CDM data held by hospitals through the code signer 113. do. Subsequently, in step 155, the user 140 receives a ticket for using the service server 131 of each hospital from the ticket issuing server 115. Finally, in step 157, the user 140 distributes the analysis code including the ticket and electronic signature to all hospitals connected to the platform through the relay server 117, and receives the analysis result as a reply. As a preliminary work for safely operating all of these processes, the user 140 and all the components constituting the platform each generate a private key and a public key, and receive a public key certificate from the certification authority 120 . This certificate conforms to the X.509 version 3 standard, which is currently the most widely used. Platform participants can be issued certificates similar to general electronic financial transactions.

FIG. 2 is a diagram showing in detail a process (step 151) in which the user 140 of FIG. 1 performs authentication of the platform through the authentication server 111.

)을 전달한다. 메시지와 함께 서명이 전달되는 이유는 메시지가 네트워크를 통해 전달되는 동안 공격자에 의해 변조되는 것을 방지하고, 송신자를 확인하기 위함이다. 플랫폼의 모든 컴포넌트는 항상 이와 같이 메시지와 서명 쌍을 전달하기 때문에 특별한 경우를 제외하고 앞으로 편의상 서명에 대한 설명은 생략한다. Referring to FIG. 2, a user 140 who intends to use the platform, in step 211, requests authentication server 111 to prove his or her identity, such as ID and password, or biometric information. A message (M _C-AS ) including identification information (ID _C ) of the user 140 and a signature (

) is delivered. The reason why the signature is transmitted along with the message is to prevent the message from being tampered with by an attacker while it is being transmitted through the network, and to verify the sender. Since all components of the platform always deliver a message and signature pair like this, the description of the signature will be omitted for convenience except for special cases.

)를 사용자(140)에게 반환한다. 이 토큰(token)은 사용자(140)의 신원과 유효기간을 DES(data encryption standard)나 AES(advanced encryption standard)와 같은 대칭키 암호 알고리즘으로 암호화하여 생성된다. 따라서, 토큰(token) 생성에 사용된 키를 알고 있는 참여자만 토큰(token)의 유효성을 검증할 수 있다. 인증 서버(111)는 제3자가 임의로 토큰(token)을 생성하는 것을 방지하기 위해 토큰(token) 생성에 사용된 키를 누구와도 공유하지 않는다. 반대로, 플랫폼에 등록되지 않은 사용자(140)나 불법적인 요청이라면, 인증 서버(111)는 인증 실패 응답을 사용자(140)에게 전달하고, 사용자(140)는 플랫폼의 어떠한 서비스도 이용할 수 없다.If the legitimate user 140, the authentication server 111, in step 213, a message (M _AS-C ) including a cryptographically generated token and a signature (

) to the user 140. This token is generated by encrypting the identity and expiration date of the user 140 with a symmetric key encryption algorithm such as data encryption standard (DES) or advanced encryption standard (AES). Therefore, only participants who know the key used to generate the token can verify the validity of the token. The authentication server 111 does not share a key used to generate a token with anyone to prevent a third party from randomly generating a token. Conversely, if it is a user 140 who is not registered with the platform or an illegal request, the authentication server 111 delivers an authentication failure response to the user 140, and the user 140 cannot use any service of the platform.

FIG. 3 is a diagram showing in detail a process (step 153) in which the user 140 of FIG. 1 receives an electronic signature for an analysis code (AC) for analyzing CDM data from the code signer 113.

)을 코드 사이너(113)에 전달한다. Referring to FIG. 3 , before accessing the code signer 113, the user 140 writes an analysis code (AC) for analyzing CDM data of hospitals through the platform. The analysis code (AC) can be written in various ways. Since the platform is implemented based on OMOP-CDM, the user 140 uses software provided by OHDSI. Therefore, the analysis code (AC) is generally written in the R language. The analysis code (AC) includes all information for analyzing CDM data, such as cohort definitions and SQL queries. Since the analysis code (AC) uses medical data for analysis, it must not be tampered with in any way until it is delivered to each hospital through the network. Digital signatures are used for data integrity and non-repudiation in transmission. To satisfy this requirement, the user 140 requests the code signer 113 to generate a digital signature for the analysis code AC. To this end, the user 140, in step 311, receives a token issued from the authentication server 111 in the previous step (step 213) and a message (MC _-CS ) including an analysis code (AC) and signature(

) to the code signer 113.

)을 사용자(140)에게 응답으로 전달한다. 이 전자서명은 코드 사이너(113)의 개인키로 생성되었기 때문에 코드 사이너(113)를 제외한 누구도 동일한 전자서명을 생성할 수 없다. 반면, 코드 사이너(113)의 공개키를 획득할 수 있다면 누구나 전자서명을 검증할 수 있다. 만약 사용자(140)가 분석코드(AC)의 일부를 수정하거나, 완전히 새로운 분석코드(AC)를 작성할 경우, 코드 사이너(113)에 새로운 전자서명 생성을 요청해야 한다.If there is nothing wrong with the message, the code signer 113 generates a digital signature (sig ^AC ) for the analysis code (AC) using its own private key in step 313, and generates a message (M _CS-C ) including it. and the signature on it (

) is delivered to the user 140 as a response. Since this electronic signature is generated with the private key of the code signer 113, no one other than the code signer 113 can generate the same electronic signature. On the other hand, anyone who can obtain the public key of the code signer 113 can verify the digital signature. If the user 140 modifies part of the analysis code AC or writes a completely new analysis code AC, the user 140 must request the code signer 113 to generate a new digital signature.

FIG. 4 is a diagram showing in detail a process (step 155) in which the user 140 of FIG. 1 obtains a ticket for accessing CDM data of all hospitals of the platform through the ticket issuing server 115.

)를 전달한다. Referring to FIG. 4 , a user 140 requests a ticket issuance server 115 to issue a ticket to access a hospital connected to the platform. To this end, in step 411, the user 140 sends a message ( _MC-TGS ) including a token of the authentication server 111 and a digital signature (sig ^AC ) of the code signer 113 and a signature thereof. (

) is delivered.

)을 전달한다. 이 티켓(ticket)은 인증 서버(111)의 토큰(token)과 유사하게 사용자의 ID와 유효기간 같은 정보를 DES나 AES와 같은 대칭키 암호 알고리즘을 이용해 생성된다. 하지만, 티켓 발행 서버(115)는, 인증 서버(111)와는 달리, 티켓(ticket)을 암호화하는 데 사용한 키를 티켓(ticket)을 수신할 각 서비스 서버(131)의 공개키로 암호화하여 티켓(ticket)과 함께 사용자(140)에게 전달한다. 사용자(140)는 티켓(ticket)과 함께 전달받은 티켓 검증을 위한 키를 복호화할 수 없다. 즉, 서비스 서버(131)를 제외하고, 사용자(140)를 포함하여 어떠한 방식으로든 티켓(ticket)을 획득한 제3자는 티켓(ticket)을 생성하거나 복호화할 수 없다. 티켓 발행 서버(115)는 분산 네트워크 위에서 운영되는 플랫폼에 있어 가장 중요한 컴포넌트이다. 플랫폼의 도움 없이, 사용자(140)가 여러 의료 기관의 CDM 데이터를 분석하려 한다면 사용자(140)는 각 기관의 관리자에게 일일이 신원을 증명하고, 분석코드(AC) 실행을 요청해야 한다. 심지어, 이런 환경에서는, 각 기관이 데이터를 이용하려는 모든 사용자(140)의 신원 정보를 저장하는 데이터베이스를 운영해야 한다. 티켓 발행 서버(115)는 이러한 번거로움을 해소하기 위해 모든 의료 기관에서 데이터를 분석하려는 사용자(140)의 신원을 인증할 수 있게 하는 티켓을 생성한다. 각 병원은 이 티켓을 검증함으로써, 별도의 사용자 계정 데이터베이스 없이 사용자(140)를 인증할 수 있게 된다.In step 413, the ticket issuing server 115 sends a message (M _TGS-C ) including a cryptographically generated ticket to the user 140 of the platform and a signature (

) is delivered. Similar to the token of the authentication server 111, this ticket is generated by using a symmetric key encryption algorithm such as DES or AES for information such as a user's ID and expiration date. However, unlike the authentication server 111, the ticket issuing server 115 encrypts the key used to encrypt the ticket with the public key of each service server 131 to receive the ticket, ) and delivered to the user 140. The user 140 cannot decrypt the key for validating the ticket received along with the ticket. That is, other than the service server 131, a third party including the user 140 who has obtained a ticket in any way cannot generate or decrypt the ticket. The ticketing server 115 is the most important component of a platform operating on top of a distributed network. Without the help of the platform, if the user 140 intends to analyze the CDM data of several medical institutions, the user 140 must individually prove his or her identity to the manager of each institution and request execution of the analysis code (AC). Even in this environment, each institution must operate a database storing the identity information of all users 140 who want to use the data. The ticket issuing server 115 generates a ticket enabling authentication of the identity of the user 140 who intends to analyze data in all medical institutions in order to solve this trouble. By verifying this ticket, each hospital can authenticate the user 140 without a separate user account database.

5 and 6 are the process of the user 140 of FIG. 1 distributing the analysis code including the ticket and digital signature to all hospitals connected to the platform through the relay server 117 and receiving the analysis result in return (step 157) These are drawings showing in detail.

5 shows a process in which a user 140, a relay server 117, and service servers 131 of hospitals communicate in a fully automated model according to an embodiment. In this model, the entire process from distributing analysis codes (AC) to returning CDM data analysis results is fully automated.

)을 보안 서버 그룹(110)의 중계 서버(117)에 전달한다. 중계 서버(117)는 토큰(token)을 검증하여 송신자의 인증 서버(111)에 의해 인증된 사용자(140)인지 확인한다. 사용자(140)의 신원이 확인되면, 중계 서버(117)는 513 단계에서, 토큰(token)을 제외한 나머지 정보를 메시지(M_RS-SS)로 다시 포장하고, 이 메시지와 이에 대한 서명(

)을 플랫폼에 등록된 모든 병원의 서비스 서버(131)들(SS1-SSn)에 전달한다. Referring to FIG. 5 , the user 140 preliminarily obtains a token of the authentication server 111, an analysis code (AC), a digital signature (sig ^AC ) of the code signer 113, and a ticket issuing server 115 ) is assumed to have a ticket. First, in step 511, the user 140 receives a message (M _C-RS ) including these four pieces of information and a signature (

) to the relay server 117 of the security server group 110. The relay server 117 verifies the token and confirms whether the sender is the user 140 authenticated by the authentication server 111 . When the identity of the user 140 is confirmed, the relay server 117 repackages the remaining information except for the token into a message (M _RS-SS ) in step 513, and the message and the signature (

) to the service servers 131 (SS1-SSn) of all hospitals registered on the platform.

Each of the service servers 131 that have received them confirms the authenticity of the user 140 and the analysis code (AC) using a ticket and a digital signature (sig ^AC ). If the verification of the user 140 and the analysis code AC is successful, in step 515, each of the service servers 131 analyzes the CDM data of the corresponding hospital by executing the analysis code AC. Then, in step 517, each of the service servers 131 returns analysis results (AR) to the relay server 117 again. Finally, the user 140 downloads the analysis results (AR) collected from hospitals in step 519 . In a fully automated model, user 140 can analyze hospitals' data without anyone's intervention.

6 shows a process in which the user 140, the relay server 117, and the service servers 131 of hospitals communicate in the approval first model according to another embodiment.

Referring to FIG. 6 , in step 611, the user 140 receives a token of the authentication server 111, an analysis code (AC), a digital signature (sig ^AC ) of the code signer 113, and a ticket issuing server. The ticket (ticket) of (115) is forwarded to the relay server (117). The relay server 117 verifies the token of the authentication server 111 to confirm the user's identity. In step 613, the relay server 117 distributes the analysis code (AC), digital signature (sig ^AC ), and ticket transmitted by the authenticated user 140 to service servers 131 of hospitals.

Each of the service servers 131 authenticates the user by verifying the received ticket, and verifies the digital signature (sig ^AC ) to check the integrity of the analysis code (AC). Each of the service servers 131 does not immediately execute the analysis code (AC) that has passed verification, but waits for approval from the hospital data administrator (custodian) 135 . In step 615, the manager 135 checks the analysis code (AC) delivered to the hospital and approves the execution. Upon approval, each of the service servers 131, in step 617, analyzes the CDM data of the hospital by executing the analysis code (AC). If the manager 135 suspends or rejects the execution of the analysis code (AC), the analysis code (AC) is not executed. Each of the service servers 131 does not immediately return an analysis result (AR) of the CDM data to the user 140, but waits for the manager 135's export approval. If the manager 135 approves export of the analysis result AR in step 619 , the user 140 may download the analysis result AR in step 621 . On the other hand, if the manager 135 suspends or rejects export of the analysis result AR, the user 140 cannot access the analysis result AR even though the data analysis is completed.

On the other hand, in some embodiments, a hybrid model combining a fully automated model and an approval-first model is possible. In the hybrid model, the service servers 131 installed for each hospital hold a whitelist for trusted researchers. If the user 140 requesting CDM data analysis is registered in the whitelist, the request is processed in a fully automated model, and otherwise, it is processed in an approval-first model.

7 is a diagram illustrating an internal configuration of the service server 131 of the platform system 100 according to various embodiments. At this time, the service server 131 of FIG. 7 has a structure for supporting a fully automated model, an approval priority model, and a hybrid model.

Referring to FIG. 7 , the service server 131 provides various functions to analyze medical data unlike other components of the platform system 100 . To this end, the service server 131 includes a verification module 710, a waiting queue 720, an execution manager 730, an analysis code pool 740, an R engine 750, and an analysis result manager 760. .

The service server 131 transfers the analysis code (AC), the digital signature (sig ^AC ) of the analysis code (AC), and the ticket (ticket) to the verification module (710). The verification module 710 verifies the analysis code AC as described with reference to FIGS. 5 and 6 . The service server 131 puts the analysis code AC into the queue 720 waiting for execution.

In general, since execution of the analysis code AC requires a lot of computing resources, all analysis requests of the user 140 cannot be executed in parallel. Accordingly, the service server 131 has an execution manager 730 to limit the analysis codes AC that can be executed at one time using the analysis code pool 740 for the analysis codes AC. The execution manager 730 may analyze the CDM data of the database 133 of the institution by executing the analysis code (AC) with the approval of the manager. If all of the previous validations are successful, the service server 131 executes the analysis code (AC) using the R engine 750. Alternatively, when the analysis code (AC) is written in a programming language other than the R language, an appropriate execution engine is called.

When data analysis is completed, the service server 131 stores the analysis result AR in the analysis result manager 760 . At this time, the analysis result (AR) may be stored in a compressed file type such as zip. The service server 131 may inform the user 140 of the CDM data analysis state. The data analysis process is time consuming. In addition, there may be differences in the execution time of the analysis code (AC) for each institution. Since the user 140 cannot wait for data analysis of all hospitals to be completed, the user 140 may periodically check the analysis status of each hospital. When the user 140 requests an analysis state, the service server 131 responds with one of “waiting for execution”, “running”, or “analysis completed”. If the service server 131 is a completely automated model, the analysis code (AC) is executed immediately without going through a waiting state for execution. The service server 131 may inform the user 140 of the analysis result (AR) export state through the analysis result manager 760 . Like the execution manager 730, the analysis result manager 760 receives an input from the manager 135 whether or not the user 140 responds to the CDM data analysis result (AR). When the user 140 requests the service server 131 whether or not the analysis result (AR) can be returned, the service server 131 returns one of “download available” or “export standby” status. The user 140 may download the analysis result AR only when it is "downloadable". Similarly, when the service server 131 is a fully automated model, the "waiting for export" state is not used.

As described above, the analysis code (AC) is created by the user 140 and executed by each hospital, that is, the service server 131. Therefore, in the platform system 100, role sharing and cooperative analysis between the user 140 and the service server 131 for the analysis code (AC) can be made. In addition, since the analysis code (AC) is code based on the common data model (CDM), it can be executed in a standardized environment and can be collectively authenticated in a plurality of hospitals, that is, service servers 131. Accordingly, each of the plurality of hospitals, that is, the service servers 131 may independently execute the analysis code AC to analyze each CDM data.

According to various embodiments, since medical data of hospitals connected to the platform are unified into CDM, an external researcher can analyze data of multiple hospitals through the same methodology. In addition, since the CDM data is not transmitted outside the local network of the hospital and is analyzed only inside the service server 131, patients do not have to worry about leaking personal information outside the hospital.

According to various embodiments, users 140 perform (multiple steps) authentication through a group of secure servers on the platform located outside the hospital's local network. The user 140 who has passed authentication does not additionally perform authentication at each hospital requesting data analysis. Therefore, each hospital does not have to operate an account database for verifying the identity of the user 140 .

The analysis code (AC) for the CDM data prepared by the user 140 must not be tampered with by a third party while being transmitted from the user 140 to the service server 131 of the hospital. Various embodiments may ensure the integrity of the analysis code AC in this process.

Various embodiments provide a platform system (100) and method thereof for analyzing secure multi-agency CDM data in a multi-agency distributed environment.

The platform system 100 according to various embodiments includes an authentication server 111 configured to generate a token for a user 140 and a code signer configured to generate an electronic signature for an analysis code of the user 140. (113), a ticket issuing server 115 configured to issue a ticket for a user 140, and at each hospital, verifying the user 140 using the ticket and verifying the analysis code using the electronic signature; , the user 140 and the service server 131 configured to execute the analysis code and analyze the CDM data of the hospital upon successful verification of the analysis code.

According to various embodiments, when the identification information of the user 140 is received from the user 140, the authentication server 111 authenticates the user 140 based on the identification information, generates a token, and generates a user ( 140) is configured to provide a token.

According to various embodiments, when the token and the analysis code are received from the user 140, the code signer 113 generates an electronic signature for the analysis code using a private key, and sends the user 140 an electronic signature. configured to provide a signature.

According to various embodiments, the analysis code is written by the user 140 and includes information for analyzing the CDM data of each hospital.

According to various embodiments, the ticket issuing server 115, when receiving a token and an electronic signature from the user 140, generates a ticket using an encryption key, and uses the public key of the service server 131 to , encrypt the encryption key, and provide a ticket to the user 140 along with the encryption key.

According to various embodiments, the service server 131 is configured to return an analysis result of the CDM data to the user 140 .

According to various embodiments, the platform system 100 further includes a relay server configured to relay communication between the user 140 and the service server 131 .

According to various embodiments, when the token, digital signature, and ticket are received from the user 140, the relay server identifies the user 140 using the token, and sends the digital signature and ticket to the service server 131. is configured to deliver

According to one embodiment, the service server 131 is configured to return analysis results to the relay server, and the user 140 downloads the analysis results from the relay server.

According to another embodiment, the service server 131 is configured to execute the analysis code based on the manager's approval, analyze the CDM data, and return the analysis result to the user 140 based on the manager's approval. do.

According to another embodiment, the service server 131 returns an analysis result to the user 140 if the user 140 is registered in the whitelist, and if the user 140 is not registered in the whitelist, Based on the administrator's approval, it is configured to return the analysis result to the user 140.

In the method of the platform system 100 according to various embodiments, the authentication server 111 generates a token for the user 140 (step 151), the code signer 113 analyzes the user 140 A step of generating a digital signature for the code (step 153), a step of the ticket issuing server 115 issuing a ticket for the user 140 (step 155), and a service server 131 of each hospital using the ticket The step of verifying the user 140 and verifying the analysis code using the digital signature (step 157), and when the verification of the user 140 and the analysis code succeeds, the service server 131 executes the analysis code , a step of analyzing the CDM data of the hospital (step 157).

According to various embodiments, the step of generating a token (step 151) is a step in which the user 140 transmits the identification information of the user 140 to the authentication server 111, the authentication server 111 transmits the identification information Authenticating the user 140 based on the authentication method, generating a token, and providing the token to the user 140 by the authentication server 111 .

According to various embodiments, the step of generating the digital signature (step 153) may include a step in which the user 140 transmits a token and an analysis code to the code signer 113 to the code signer 113, the code signer Step (113) of generating an electronic signature for the analysis code using the private key, and step of providing the digital signature to the user (140) by the code signer (113).

According to various embodiments, the analysis code is written by the user 140 and includes information for analyzing the CDM data of each hospital.

According to various embodiments, issuing a ticket (step 155) includes a step in which the user 140 transmits a token and an electronic signature to the ticket issuing server 115, and the ticket issuing server 115 uses an encryption key. to generate a ticket, the ticket issuing server 115 encrypting the encryption key using the public key of the service server 131, and the ticket issuing server 115 encrypting the ticket to the user 140 Provided with the key.

According to various embodiments, the method of the platform system 100 further includes a step of the service server 131 returning an analysis result of the CDM data to the user 140 (step 157).

According to various embodiments, the step of verifying the user 140 and the analysis code (step 157) is a step in which the user 140 transmits a token, a digital signature, and a ticket to the relay server, and the relay server uses the token. Thus, the step of confirming the user 140, the relay server transferring the electronic signature and the ticket to the service server 131, and the service server 131 verifying the user 140 using the ticket, and the digital signature and verifying the analysis code using

According to one embodiment, the step of returning the analysis result (step 157) includes the service server 131 returning the analysis result to the relay server, and the user 140 downloading the analysis result from the relay server. include

According to another embodiment, the step of analyzing the CDM data (step 157) includes the step of analyzing the CDM data by allowing the service server 131 to execute an analysis code based on the manager's approval, and displaying the analysis result. The sending step includes sending an analysis result back to the user 140 based on the manager's approval.

According to another embodiment, the step of returning the analysis result (step 157) includes, if the user 140 is registered in the whitelist, the service server 131 returning the analysis result to the user 140, and If the user 140 is not registered in the whitelist, the service server 131 returns an analysis result to the user 140 based on the administrator's approval.

The devices described above may be implemented as hardware components, software components, and/or a combination of hardware components and software components. For example, devices and components described in the embodiments include a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA), and a programmable PLU (programmable logic unit). logic unit), microprocessor, or any other device capable of executing and responding to instructions. The processing device may run an operating system (OS) and one or more software applications running on the operating system. A processing device may also access, store, manipulate, process, and generate data in response to execution of software. For convenience of understanding, there are cases in which one processing device is used, but those skilled in the art will understand that the processing device includes a plurality of processing elements and/or a plurality of types of processing elements. It can be seen that it can include. For example, a processing device may include a plurality of processors or a processor and a controller. Other processing configurations are also possible, such as parallel processors.

Software may include a computer program, code, instructions, or a combination of one or more of the foregoing, which configures a processing device to operate as desired or processes independently or collectively. The device can be commanded. The software and/or data may be embodied in any tangible machine, component, physical device, computer storage medium, or device to be interpreted by, or to provide instructions or data to, a processing device. there is. Software may be distributed on networked computer systems and stored or executed in a distributed manner. Software and data may be stored on one or more computer readable media.

Methods according to various embodiments may be implemented in the form of program instructions that can be executed through various computer means and recorded in a computer readable medium. In this case, the medium may continuously store a program executable by a computer or temporarily store the program for execution or download. Also, the medium may be a single or various types of recording means or storage means in the form of a combination of several pieces of hardware. It is not limited to a medium directly connected to a certain computer system, and may be distributed on a network. Examples of the medium include magnetic media such as hard disks, floppy disks and magnetic tapes, optical recording media such as CD-ROM and DVD, magneto-optical media such as floptical disks, and ROM, RAM, flash memory, etc. configured to store program instructions. In addition, examples of other media include recording media or storage media managed by an app store that distributes applications, a site that supplies or distributes various other software, and a server.

Various embodiments of this document and terms used therein are not intended to limit the technology described in this document to a specific embodiment, and should be understood to include various modifications, equivalents, and/or substitutes of the embodiment. In connection with the description of the drawings, like reference numerals may be used for like elements. Singular expressions may include plural expressions unless the context clearly dictates otherwise. In this document, expressions such as "A or B", "at least one of A and/or B", "A, B or C" or "at least one of A, B and/or C" refer to all of the items listed together. Possible combinations may be included. Expressions such as "first," "second," "first," or "second" may modify the elements in any order or importance, and are used only to distinguish one element from another. The components are not limited. When a (e.g., first) element is referred to as being "(functionally or communicatively) connected" or "connected" to another (e.g., second) element, it is referred to as being "connected" to the other (e.g., second) element. It may be directly connected to the component or connected through another component (eg, a third component).

The term "module" used in this document includes a unit composed of hardware, software, or firmware, and may be used interchangeably with terms such as logic, logic block, component, or circuit, for example. A module may be an integral part or a minimum unit or part thereof that performs one or more functions. For example, the module may be composed of an application-specific integrated circuit (ASIC).

According to various embodiments, each component (eg, module or program) of the described components may include a singular object or a plurality of entities. According to various embodiments, one or more components or steps among the aforementioned components may be omitted, or one or more other components or steps may be added. Alternatively or additionally, a plurality of components (eg modules or programs) may be integrated into a single component. In this case, the integrated component may perform one or more functions of each of the plurality of components identically or similarly to those performed by the corresponding component among the plurality of components prior to integration. According to various embodiments, steps performed by a module, program, or other component are executed sequentially, in parallel, iteratively, or heuristically, or one or more of the steps are executed in a different order, omitted, or , or one or more other steps may be added.

Claims (20)

In a platform system for safely analyzing multi-organizational CDM data in a multi-organization distributed environment,
an authentication server configured to generate a token for a user;
a code signer configured to generate an electronic signature for the analysis code of the user;
a ticket issuing server configured to issue a ticket for the user; and
In each hospital, the user is verified using the ticket, the analysis code is verified using the electronic signature, and when the verification of the user and the analysis code is successful, the analysis code is executed, and the hospital service server configured to analyze CDM data from
including,
platform system.
According to claim 1,
The authentication server,
When identification information of the user is received from the user, authenticating the user based on the identification information to generate the token;
configured to provide the token to the user;
platform system.
According to claim 1,
The code signer,
When the token and the analysis code are received from the user, the digital signature for the analysis code is generated using a private key;
configured to provide the electronic signature to the user;
platform system.
According to claim 1,
The analysis code is
Created by the user and including information for analyzing the CDM data of each hospital,
platform system.
According to claim 1,
The ticket issuing server,
When the token and the electronic signature are received from the user, the ticket is generated using an encryption key;
Encrypting the encryption key using the public key of the service server,
configured to provide the user with the ticket along with the encryption key;
platform system.
According to claim 1,
The service server,
Is configured to send an analysis result for the CDM data to the user,
platform system.
According to claim 6,
A relay server configured to relay communication between the user and the service server
Including more,
The relay server,
When the token, the electronic signature, and the ticket are received from the user, the user is identified using the token;
configured to deliver the electronic signature and the ticket to the service server;
platform system.
According to claim 7,
The service server,
configured to return the analysis result to the relay server;
The user,
Downloading the analysis result from the relay server,
platform system.
According to claim 7,
The service server,
Based on the administrator's approval, the analysis code is executed to analyze the CDM data,
Based on the administrator's approval, configured to return the analysis result to the user,
platform system.
According to claim 7,
The service server,
If the user is registered in the whitelist, the analysis result is returned to the user;
If the user is not registered in the whitelist, configured to return the analysis result to the user based on an administrator's approval.
platform system.
In the method of a platform system for safely analyzing multi-organizational CDM data in a multi-organization distributed environment,
the authentication server generating a token for the user;
generating, by a code signer, an electronic signature for the analysis code of the user;
a ticket issuing server issuing a ticket for the user;
a service server of each hospital verifying the user using the ticket and verifying the analysis code using the digital signature; and
When the verification of the user and the analysis code is successful, the service server executing the analysis code to analyze the CDM data of the hospital.
including,
method of the platform system.
According to claim 11,
The step of generating the token is,
transmitting identification information of the user to the authentication server by the user;
authenticating the user based on the identification information by the authentication server and generating the token; and
providing, by the authentication server, the token to the user;
including,
method of the platform system.
According to claim 11,
Generating the electronic signature,
transmitting, by the user, the token and the analysis code to the code signer;
generating, by the code signer, the electronic signature for the analysis code using a private key; and
Step of the code signer providing the digital signature to the user
including,
method of the platform system.
According to claim 11,
The analysis code is
Created by the user and including information for analyzing the CDM data of each hospital,
method of the platform system.
According to claim 11,
The step of issuing the ticket,
transmitting the token and the digital signature to the ticket issuing server by the user;
generating the ticket by the ticket issuing server using an encryption key;
encrypting the encryption key by the ticket issuing server using the public key of the service server; and
providing, by the ticket issuing server, the ticket to the user along with the encryption key;
including,
method of the platform system.
According to claim 11,
The service server returning an analysis result of the CDM data to the user.
Including more,
method of the platform system.
17. The method of claim 16,
The step of verifying the user and the analysis code,
transmitting, by the user, the token, the electronic signature, and the ticket to a relay server;
verifying the user by the relay server using the token;
transferring, by the relay server, the digital signature and ticket to the service server; and
The service server verifying the user using the ticket and verifying the analysis code using the digital signature.
including,
method of the platform system.
18. The method of claim 17,
The step of returning the analysis result,
the service server returning the analysis result to the relay server; and
The user downloading the analysis result from the relay server.
including,
method of the platform system.
18. The method of claim 17,
Analyzing the CDM data,
Analyzing the CDM data by the service server executing the analysis code based on the manager's approval
including,
The step of returning the analysis result,
Based on the manager's approval, returning the analysis result to the user.
including,
method of the platform system.
18. The method of claim 17,
The step of returning the analysis result,
If the user is registered in the whitelist, the service server returning the analysis result to the user; and
If the user is not registered in the whitelist, the service server returning the analysis result to the user based on the administrator's approval.
including,
method of the platform system.

Images