KR102627705B1 - Apparatus and method for management of accessing medical data - Google Patents

Abstract

The present disclosure relates to management and collection of data, and more specifically, to devices and methods for managing access to medical data. An apparatus for medical data access management according to an embodiment of the present disclosure includes a key-based authentication unit that generates a parsed access key based on the access key given by the user, and a key management unit that determines whether the parsed access key is valid. , a rule-based authorization unit that grants data access permission based on rules related to the user's data access, a rule management unit that determines whether the user's data access request meets the rule, and a rule management unit that determines whether the user's data access request meets the rule. It includes a consent-based authorization unit that grants data access authority based on consent, a consent management unit that determines whether the consent is valid, and a health management service that receives data requested by the user and transmits it to the user.

Description

Apparatus and method for managing access to medical data {APPARATUS AND METHOD FOR MANAGEMENT OF ACCESSING MEDICAL DATA}

The present disclosure relates to management and collection of data, and more specifically to devices and methods for managing access to medical data.

Recently, research and use of big data in health care has been actively conducted. This field of big data is bringing about numerous innovations as data from various sources such as theorists, system builders, researchers, or application designers are simultaneously accumulated. In particular, because each piece of data belongs to a specific user (e.g., patient doctor) or a specific group (e.g., hospital), this can present challenges for users interested in adopting, sharing, or analyzing this data. .

Typically, the conventional approach to solving these difficulties has been to create a single system that can manage data individually. However, this approach omits most authentication steps in communication between systems because current solutions focus on medical data management in terms of back-end data storage, making it difficult for users to fully control and monitor their data. Therefore, it is not easy to protect data, and lastly, there is a problem that safe data sharing between users is difficult due to the lack of standards and mechanisms.
Prior Art 1: US 20140215490 A1 (Publication date: 2014-07-31)
Prior Art 2: KR 20130001500 A (Publication date: 2013-01-04)

This disclosure provides an apparatus and method for managing access to medical data and IoT data in a data hub.

An apparatus for medical data access management according to an embodiment of the present disclosure includes a key-based authentication unit that generates a parsed access key based on the access key given by the user, and a key management unit that determines whether the parsed access key is valid. , a rule-based authorization unit that grants data access permission based on rules related to the user's data access, a rule management unit that determines whether the user's data access request meets the rule, and a rule management unit that determines whether the user's data access request meets the rule. It includes a consent-based authorization unit that grants data access authority based on consent, a consent management unit that determines whether the consent is valid, and a health management service that receives data requested by the user and transmits it to the user.

A method for managing medical data access according to an embodiment of the present disclosure includes the steps of granting an access key to a user, determining whether the access key is valid, and, if the access key is valid, requesting data access and It includes determining whether a related rule is met, and returning the data requested by the user to the user if the data access request satisfies the rule.

According to an embodiment of the present disclosure, difficulties experienced by users due to imbalanced access to medical data and security issues can be alleviated.

Additionally, according to an embodiment of the present disclosure, a user can easily access desired medical data and manage the medical data efficiently.

1 is a block diagram showing the configuration of an apparatus for medical data access management according to an embodiment of the present disclosure.
Figure 2 is a flowchart illustrating a process for granting access to medical data to a user according to an embodiment of the present disclosure.
Figure 3 is a flowchart showing a process for accessing medical data according to an embodiment of the present disclosure.

Below, embodiments of the present disclosure will be described clearly and in detail so that a person skilled in the art can easily practice the present disclosure.

The components described with reference to terms such as unit, module, block, ~or, ~er, etc. used in the detailed description and the functional blocks shown in the drawings are It may be implemented in the form of software, hardware, or a combination thereof. By way of example, software may be machine code, firmware, embedded code, and application software. For example, the hardware may include an electrical circuit, an electronic circuit, a processor, a computer, an integrated circuit, integrated circuit cores, a pressure sensor, an inertial sensor, a microelectromechanical system (MEMS), a passive component, or a combination thereof. .

Figure 1 is a block diagram showing the configuration of an apparatus 100 for medical data access management according to an embodiment of the present disclosure. For example, a user of device 100 may be a doctor 10 or a patient 20. Doctor 10 may represent a user who needs access to specific medical data to perform a specific task (e.g., diagnosis), and patient 120 may represent a user who owns medical data and wishes to share it with other users. It can be expressed.

The device 100 can receive medical data access requests so that the doctor 10 and the patient 20 can share medical data with each other, and serves as a data hub that manages medical data by granting medical data access permission. can do. The device 100 according to an embodiment of the present disclosure includes a key-based authentication unit 110, a key management unit 120, a rule-based authorization unit 130, a rule management unit 140, a consent-based authorization unit 150, It may include a consent management unit 160, a health management service 170, and a data lake 180.

For example, the device 100 shown in FIG. 1 may be implemented in the form of software or hardware such as a Field Programmable Gate Array (FPGA) or Application Specific Integrated Circuit (ASIC). However, the device 100 is limited to software or hardware. However, each component of device 100 may be configured to reside in a storage medium or may be configured to run on one or more processors. In other words, each component of the device 100 includes components such as software components, object-oriented software components, class components, and task components, processes, functions, properties, procedures, subroutines, and program code. It may be at least one of segments, drivers, firmware, microcode, circuits, data, data structures, tables, arrays, or variables.

A doctor 10 or a patient 20 who is a user of the device 100 may transmit an authentication request to the identity service 200 to access medical data and may be granted an access key to the data. The identity service 200 may determine whether the authentication request received from the doctor 10 or the patient 20 is valid. For example, an authentication request may include a username and password. If the identity service 200 determines that the authentication request of the doctor 10 or the patient 20 is valid, the access key may be returned to the doctor 10 or the patient 20. On the other hand, if the identity service 200 determines that the authentication request of the doctor 10 or the patient 20 is invalid, the doctor 10 or the patient 20 may transmit the authentication request again. For example, identity service 200 may be implemented as a third-party server.

The key-based authentication unit 110 may parse the access key given by the doctor 10 or the patient 20. Specifically, the access key granted from the identity service 200 is encrypted and may include information such as signature or expiration time. The parsed access key generated by the key-based authentication unit 110 parsing the access key may be a decrypted access key. In other words, the key-based authentication unit 110 can access information such as signature or expiration time by decrypting the encrypted access key by parsing the encrypted access key. The key-based authentication unit 110 may transmit the parsed access key to the key management unit 120.

The key management unit 120 may determine whether there is invalid information in the parsed access key. For example, if the signature or expiration time included in the parsed access key is invalid, the key management unit 120 may determine that the access key given by the doctor 10 or the patient 20 is invalid. If the key management unit 120 determines that the parsed access key is valid, the doctor 10 or the patient 20 may receive a notification from the health management service 170 that data access has been requested.

The rule-based authorization unit 130 may grant data access permission to a doctor 10 or patient 20 having a valid access key based on rules related to data access. The rule-based authorization unit 130 may request the rule management unit 140 to determine whether the data access request of the doctor 10 or the patient 20 conforms to the rule.

The rule management unit 140 may determine whether the data access request meets the rules related to data access. Specifically, the rule management unit 140 may include predefined rules indicating which users can access which data. In other words, predefined rules can indicate a correspondence between a user and specific data. For example, a predefined rule may be that the doctor 10 can access medical data related to his patients managed by the hospital where he works. If the rule management unit 140 determines that the data access request meets the rules related to data access, the rule-based authorization unit 130 may grant data access permission to the doctor 10 or the patient 20.

The consent-based authorization unit 150 may grant data access permission based on consent for data access. For example, consent related to data access may include information such as where the user can access the data, exceptions to data access, or when the user can access the data. The consent-based authorization unit 150 may request the consent management unit 160 to check the validity of the consent, and the consent management unit 160 may determine whether there is valid consent for data access. If the consent management unit 160 determines that the consent for data access is valid, the consent-based authorization unit 150 may grant data access permission to the doctor 10 or the patient 20.

The health care service 170 may receive a request for access to specific data from the doctor 10 or the patient 20, and may receive data from the data lake 180. Additionally, the health care service 170 may transmit a notification about a data access request to the doctor 10 or the patient 20.

Data lake 180 may include data related to the doctor 10 or the patient 20. For example, data lake 180 may include medical data or IoT (Internet of Things) data. The data lake 180 may transmit data requested by the doctor 10 or the patient 20 to the health care service 170.

Figure 2 is a flowchart illustrating a process for granting access to medical data to a user according to an embodiment of the present disclosure. Hereinafter, the description will be made with reference to FIG. 1 along with FIG. 2 .

In step S201, the physician 10 may transmit an authentication request to the identity service 200 for an access key. For example, an authentication request may include a username and password. In step S202, the identity service 200 may determine whether the received authentication request is valid. If the user name or password value is incorrect (“No”), the identity service 200 may determine that the authentication request is invalid, and step S201 may be performed again. If the authentication request is determined to be valid (“Yes”), the identity service 200 may return a new access key to the doctor 10 in step S203.

In step S204, the doctor 10 may transmit a request for access to specific data from the data catalog to the health care service 170. For example, a data catalog may contain a list of available medical data. In step S205, the key-based authentication unit 110 may parse the access key and request validation of the access key from the key management unit 120. In step S206, the key management unit 120 may determine whether the parsed access key is valid. For example, if the signature or expiration time of the parsed access key is invalid (“No”), step S201 may be performed again. If the parsed access key is determined to be valid (“Yes”), the health care service 170 may transmit a data access request notification to the patient 20 in step S207.

At step S208, patient 20 may send an authentication request to identity service 200 for an access key. Similar to step S201, the authentication request may include a user name and password. In step S209, the identity service 200 may determine whether the received authentication request is valid. If the user name or password value is incorrect (“No”), the identity service 200 may determine that the authentication request is invalid, and step S208 may be performed again. If the authentication request is determined to be valid (“Yes”), the identity service 200 may return a new access key to the patient 20 in step S210.

In step S211, the patient 20 may request the consent management unit 160 to generate consent for the access request from the doctor 10. For example, consent to a data access request may include information such as where the user can access the data, exceptions to data access, or when the user can access the data. In step S212, the key-based authentication unit 110 may parse the access key and request validation of the access key from the key management unit 120. In step S213, the key management unit 120 may determine whether the parsed access key is valid. For example, if the signature or expiration time of the parsed access key is invalid (“No”), step S208 may be performed again. If the parsed access key is determined to be valid (“Yes”), the health care service 170 may transmit a data access request notification to the doctor 10 in step S214. Through steps S201 to S214 described above, the doctor 10 and the patient 20 can request access to medical data and be granted access to the data.

Figure 3 is a flowchart showing a process for accessing medical data according to an embodiment of the present disclosure. Hereinafter, the description will be made with reference to FIG. 1 along with FIG. 3 .

In step S301, the user (doctor or patient) may send an authentication request to the identity service 200 for an access key. As described with reference to Figure 2, the authentication request may include a user name and password. In step S302, the identity service 200 may determine whether the received authentication request is valid. If the user name or password value is incorrect (“No”), the identity service 200 may determine that the authentication request is invalid, and step S301 may be performed again. If the authentication request is determined to be valid (“Yes”), the identity service 200 may return a new access key to the user (doctor or patient) in step S303.

In step S304, the user may transmit a data access request to the health care service 170. In step S305, the key-based authentication unit 110 may parse the access key and request validation of the access key from the key management unit 120. In step S306, the key management unit 120 may determine whether the parsed access key is valid. For example, if the signature or expiration time of the parsed access key is invalid (“No”), step S301 may be performed again.

If the parsed access key is determined to be valid (“Yes”), in step S307, the rule-based authorization unit 130 determines whether the data access request meets the rules related to data access to the rule management unit 140. You can request it. In step S308, the rule management unit 140 may determine whether the data access request meets the rules related to data access. The rule management unit 140 may include predefined rules indicating which users can access which data. Predefined rules can indicate a correspondence between a user and specific data. For example, a predefined rule may be that a doctor 10 can access his or her patient data managed by his or her hospital.

If the data access does not meet the predefined rules (“No”), the consent-based authorization unit 150 may request validation from the consent management unit 160 in step S309. For example, consent to a data access request may include information such as where the user can access the data, exceptions to data access, or when the user can access the data. In step S310, the consent management unit 160 may determine whether there is valid consent for data access. If it is determined that there is no valid consent to access the data (“No”), step S304 may be performed again.

If at step S308 it is determined that the data access complies with the rules (“Yes”), or at step S310 it is determined that there is valid consent for data access (“Yes”), at step S311 the health care service 170 May return the requested data from the data lake 180 to the user.

The above-described contents are specific embodiments for carrying out the present disclosure. The present disclosure will include not only the above-described embodiments, but also embodiments that are simply designed or can be easily changed. In addition, the present disclosure will also include techniques that can be easily modified and implemented using the embodiments. Accordingly, the scope of the present disclosure should not be limited to the above-described embodiments, but should be determined by the claims and equivalents of the present invention as well as the claims described below.

110: key-based authentication unit 120: key management unit
130: Rule-based authorization unit 140: Rule management unit
150: Consent-based authorization unit 160: Consent management unit
170: Healthcare services 180: Data lake
200: Identity service

Claims (10)

A key-based authentication unit that generates a parsed access key based on the access key given by the user;
a key management unit that determines whether the parsed access key is valid;
a rule-based authorization unit that grants data access rights based on rules related to data access of the user;
a rule management unit that determines whether the user's data access request conforms to the rule in response to the access key being valid;
a consent-based authorization unit that grants data access authority based on the user's consent to data access;
a consent management unit that determines whether the consent is valid in response to the user's data access request not meeting the rules; and
In response to the user's data access request meeting the rules or the consent being valid, a health care service that receives the data requested by the user and transmits it to the user,
The parsed access key includes a signature and an expiration time of the access key, and
The device for managing access to medical data, wherein the consent includes information about the location of the user accessing the data and information about the time at which the user accesses the data. According to claim 1,
The access key is a device for medical data access management including the user's user name and password. delete delete In a method of operating a device for medical data access management including an identity service, a key-based authentication unit, a key management unit, a rule management unit, a consent management unit, and a health management service,
granting, by the identity service, an access key to the user;
parsing the access key by a key-based authentication unit to generate a parsed access key;
determining, by the key management unit, whether the parsed access key is valid;
determining, by the rule management unit, whether a data access request conforms to a rule related to data access in response to the parsed access key being valid;
returning, by the health care service, the data requested by the user to the user if the data access request meets the rules;
determining, by the consent management unit, whether consent for data access is valid if the data access request does not comply with the rules; and
returning, by the health care service, the data requested by the user to the user if the consent to access the data is valid;
The parsed access key includes a signature and an expiration time of the access key, and
The method of claim 1 , wherein the consent includes information regarding the location of the user accessing the data and information regarding the time at which the user accesses the data. According to claim 5,
wherein the access key includes the user's username and password. delete delete delete According to claim 5,
The method further comprising transmitting, by the health care service, a data access request notification to the user.