Patent Application
20220391536
The invention relates generally to authorized and trustworthy storage and handling of sensitive data. In particular, the present invention concerns a computer-implemented method for making medical data available to third parties, and a server configured to implement such a method. The invention also relates to a computer program product and a non-volatile data carrier.
In medical science and businesses, there is a general demand for patient-related data in order to perform research and develop new and improved drugs. In other words, there is a need to access, combine and process personal health data outside of the environment where such data is created, stored and used, namely in the health care services. Medical data originating from one or more health care providers form a very valuable basis for an evidence-based process treatment, where the data fulfils the scientific requirements of accuracy and traceability. It is further advantageous if the patients themselves may add pieces of information in such a process via an auxiliary input channel.
The need to access, combine and process personal health data outside the original source is driven by many factors. First, there is an obvious need for the patient himself/herself to perform self-treatment after, or in combination with, the care provided by a health care provider. Second, there is a vast number of research projects that are fully dependent on personal health data to make progress. This research includes academic research, the pharma industry as well as other independent actors.
WO 2018/046495 discloses a method in a healthcare monitoring system for anonymous communication of patient data associated with a patient from an electronic user device, using a patient application implemented in the electronic user device, to a host server, using a host application implemented in the host server, via a wireless network, and identification of the patient associated with the patient data after the patient data is received in the host server. The document further provides a corresponding system, computer program and non-volatile data carrier containing the computer program.
Thus, secure communication of patient data is enabled. However, the problem of making collections of medical data available to external parties, e.g. in academia and the pharma industry, remains to be solved. Namely, legislation and various regulations often prevent the data from a health care provider to be shared with external parties, and indeed even other health care providers.
Today, there are technical solutions which legally allow patients to view at least selected parts of the medical data relating to themselves. Primarily for personal-integrity reasons these solutions are designed not allow or enable any external parties to gain direct access to the medical data. This complicates the sharing of medical data with third parties.
It is therefore an object of the present invention to offer a solution for making medical data available to third parties in a convenient and straightforward manner, and at the same time fulfil all legal, regulatory and ethical conditions relating such sharing of data.
According to one aspect of the invention, this object is achieved by a method for making medical data available to third parties. The method is performed in at least one processor and involves obtaining, via a first interface, a digital storage agreement from a terminal, e.g. a smartphone, a laptop or a personal computer. The digital storage agreement authorizes storage of medical data in a central database, which medical data relates to a user of the terminal. In other words, a patient authorizes storage of his/her personal medical through an authorization process implemented in a user terminal. In response to the digital storage agreement, the method involves sending, via a second interface, a first data request to a primary server, for instance controlled by a health care provider. The first data request is configured to cause the primary server to forward medical data relating the user from the primary server to the central database. The method further involves obtaining medical data relating to the user via the second interface, and storing the obtained medical data in the central database. Via a third interface, a data enquiry is received from a third party, which data enquiry encompasses a request for the medical data relating to the user and which medical data are stored in the central database. In response to the data enquiry, the method involves checking if the user has authorized sharing the medical data requested in the data enquiry with the third party. If, and only if, the user has authorized such sharing, the method involves forwarding a copy of the medical data requested in the data enquiry to the third party via the third interface.
This method is advantageous because it enables authorized external parties convenient and low-latency access to personal medical data from large numbers of individuals for clearly specified purposes, such as fundamental research, applied research, and drug development, without violating any legal or regulatory conditions.
According to one embodiment of this aspect of the invention, the method involves receiving, via the first interface, a digital sharing authorization from the terminal, which digital sharing authorization is configured to authorize the sharing of the medical data requested in the data enquiry with the third party. Further, the method involves storing the digital sharing authorization in a contract database. Thus, it is straightforward to check whether a user has authorized a particular sharing of data whenever a data enquiry is received from a third party.
Preferably, the checking if the user has authorized sharing the medical data requested in the data enquiry with the third party involves the following: searching the contract database for the digital sharing authorization; and allowing forwarding of the copy of the medical data requested in the data enquiry to the third party via the third interface exclusively if the digital sharing authorization is found in the contract database. Thereby, the checking can be performed efficiently and automatically.
According to another embodiment of this aspect of the invention, the digital sharing authorization defines either a specific subset of the medical data relating to the user stored in the central database, or a complete amount of this data. This is advantageous because it allows each patient to tailor which data that can be shared to whom and for what purposes.
According to yet another embodiment of this aspect of the invention, the digital sharing authorization has a time limit after which it expires and ceases to be valid. This provides additional flexibility in terms of the circumstances under which data can be shared.
Analogous to the above, according to still another embodiment of this aspect of the invention, the digital storage agreement either defines a specific subset of the medical data user stored in a primary database controlled by the primary server, or a complete amount of this data. Thereby, the patient may tailor which data that that he/she accepts to be forwarded from the primary server to the central server.
Preferably, the digital sharing authorization may also have a time limit after which it expires and ceases to be valid. Hence, the medical data do not risk being permanently stored in the central database.
According to another aspect of the invention, the object is achieved by a computer program product loadable into a non-volatile data carrier being communicatively connected to at least one processor. The computer program product contains software configured to, when the computer program product is run on the at least one processing circuitry, cause the at least one processing circuitry to effect the above-described method. The advantages of this computer program product and non-volatile data carrier are apparent from the discussion above with reference to the proposed method.
According to yet another aspect of the invention, the above object is achieved by a server for making medical data available to third parties. The server contains first, second and third interfaces, and is communicatively connected to a central database.
The first interface is configured to obtain a digital storage agreement from a terminal, which digital storage agreement authorizes storage of medical data relating to a user of the terminal in the central database. The second interface is configured to send, in response to the digital storage agreement, a first data request to a primary server, e.g. controlled by a health care provider, which first data request is configured to cause the primary server to forward medical data relating to the user to the second interface. Thus, the second interface is also configured obtain medical data relating to the user from the primary server. The server is configured to store the obtained medical data in the central database. The third interface is configured to receive a data enquiry from a third party, which data enquiry encompasses a request for the medical data relating to the user stored in the central database. In response to the data enquiry, the server is further configured to check if the user has authorized sharing the medical data requested in the data enquiry with the third party. Only if the user has authorized such sharing, the server is configured to forward a copy of the medical data requested in the data enquiry to the third party. The advantages of this server are apparent from the discussion above with reference to the proposed method.
Further advantages, beneficial features and applications of the present invention will be apparent from the following description and the dependent claims.
The invention is now to be explained more closely by means of preferred embodiments, which are disclosed as examples, and with reference to the attached drawings.
The server 100 contains first, second and third interfaces 110, 120 and 130 respectively, and is communicatively connected to a central database 140.
The first interface 110 is configured to obtain a digital storage agreement R[auth] from a terminal UT, e.g. a smartphone, a tablet, a laptop or a personal computer. The digital storage agreement R[auth] authorizes storage of medical data PDID relating to a user of the terminal UT in the central database 140, for example based on a so-called strong authentication process involving a unique access key and exchange of a randomized numeric code between the terminal UT and the server 100. Preferably, the digital storage agreement R[auth] is generated by means of a dedicated software, e.g. a so-called app, installed in the terminal UT, which software is arranged to establish a secure connection to the first interface 110 of the server 100, for example over the Internet. Such a dedicated software in the terminal UT facilitates certifying that the digital storage agreement R[auth] indeed originates from an authorized person, for example by requesting digital signatures, using a chain of trust, forwarding the credentials of the person logged into the server 100, or by requiring that the user of the terminal UT re-authenticates himself/herself.
The digital storage agreement R[auth] defines an identity of the user, i.e. a subject to whom a specified amount of data PDID relates. The data PDID, in turn, are presumed to be stored in a primary database JDB, which is controlled by the primary server JS. Typically, the data PDID form part of a medical journal created by a health care provider MDP for the subject. However, the invention does not preclude that there is also an auxiliary channel for entering additional data PDaux, for example from the terminal UT, which auxiliary channel allows a patient to provide information supplementing the medical data entered by the health care provider MDP.
For example, a set of digital storage agreements R[auth] that pertain to a given health care provider may be organized in a common collection {PD} in the database 140.
Preferably, the digital storage agreement R[auth] defines either a subset, or a complete amount of the medical data PDID relating to the user that are stored in the primary database JDB and being controlled by the primary server JS. The digital storage agreement R[auth] may further define a set of purposes for which the medical data PDID are allowed to be used and/or a time limit after which the digital storage agreement R[auth] expires and ceases to be valid. Thus, when the time limit has been passed, the medical data PDID are deleted from the central database 140.
In response to the digital storage agreement R[auth], the second interface 120 is configured to send a first data request RQ1 to the primary server JS. The first data request RQ1 is configured to cause the primary server JS to forward medical data PDID relating to the user to the second interface 120. Here, exclusively medical data PDID fulfilling the conditions of the digital storage agreement R[auth] are forwarded from the primary server JS. This is verified by means of a first checking procedure CHK1 performed in the primary server JS. Provided that the first checking procedure CHK1 is passed, and the medical data PDID are forwarded from the primary server JS, the medical data PDID relating to the user from the primary server JS are obtained in the server 100 via the second interface 120.
The server 100 is then configured to store the obtained medical data PDID in the central database 140, so that the medical data PDID may be held available by the server 100 at a later point in time.
The third interface 130 is configured to receive a data enquiry ENQ from a third party DU, or a data user, for example in the form of a research institute, a university or a pharmaceutical company.
The data enquiry encompasses a request for the medical data PDID relating to the user, which medical data PDID are stored in the central database 140. Naturally, in practice, the data enquiry ENQ also encompasses medical data relating to many other patients, perhaps in the order of thousands, tens or hundreds of thousands. For simplicity, however, in this description, we only discuss the medical data PDID relating to a single individual.
In response to the data enquiry ENQ, the server 100 is further configured to perform a second checking procedure CHK2 in which it is checked if the user has authorized sharing the medical data PDID requested in the data enquiry ENQ with the third party DU. If and only if the user has authorized such sharing, the server 100 is further configured to forward a copy of the medical data PDID requested in the data enquiry ENQ to the third party DU via the third interface 130.
According to one embodiment of the invention, the server 100 is configured to receive a digital sharing authorization ACC from the terminal UT via the first interface 110. The digital sharing authorization ACC is configured to authorize the sharing of the medical data PDID requested in the data enquiry ENQ with the third party DU.
According to embodiments of the invention, the digital sharing authorization ACC may define either a subset, or a complete amount of the medical data PDID relating to the user stored in the central database 140. Additionally, or alternatively, the digital sharing authorization ACC may have a time limit after which it expires and ceases to be valid. In other words, after the time limit, none of the medical data PDID relating to the user will be shared with any third parties DU.
Obviously, it is difficult for the user to know in advance whether a particular third party DU will issue a data enquiry ENQ, and if so, which type of medical data that will be encompassed by the data enquiry ENQ. Therefore, in connection with, and preferably prior to, issuing the data enquiry ENQ, the third part DU may send a corresponding enquiry ENQUT to the user, for example via the above-mentioned software in the terminal UT. Consequently, in response to the data enquiry ENQ, the user may send a digital sharing authorization ACC through which the user authorizes sharing the medical data PDID requested in the data enquiry ENQ with the third party DU.
Moreover, it is convenient if the terminal UT sends an equivalent message ACCDU to the third part DU in parallel with the digital sharing authorization ACC, which equivalent message ACCDU mirrors the authorization sent to the server 100. Namely, thereby the third part DU gains heads up information about what medical data can be expected to be held available via the server 100.
According to one embodiment of the invention, the server is configured to store the digital sharing authorization ACC in a contract database 150. For instance, a set of digital sharing authorizations ACC pertaining to a given third party DU may be organized in a common collection {K} in the contract database 150.
According to one embodiment of the invention, the server 100 is configured to perform the second checking procedure CHK2 if the user has authorized sharing the medical data PDID requested in the data enquiry ENQ with the third party DU as follows:
(i) searching the contract database 150 for the digital sharing authorization ACC; and
(ii) allowing forwarding of the copy of the medical data PDID requested in the data enquiry ENQ to the third party DU via the third interface 130 exclusively if the digital sharing authorization ACC is found in the contract database 150.
Legally, this is equated to sharing the medical data PDID with the user/patient via a first proxy issued by the user to the server 100, and a second proxy issued by the server 100 to the third party DU in the user's name with respect of the medical data PDID. Hence, the server 100 implements a two-step proxy service for all the users/patients who have authorized sharing their medical data PDID with one or more third parties DU. This, in turn, renders the server 100 a highly efficient tool for making various collections of medical data available to external parties in the form of academia and pharma industry.
In
In order to sum up, and with reference to the flow diagram in
A first step 310 checks if a digital storage agreement R[auth] has been received from a terminal UT via a first interface 110. The digital storage agreement R[auth] authorizes storage of medical data PDID in a central database 140, which medical data relates to a user of the terminal UT. If such a digital storage agreement R[auth] has been received, a step 320 follows; and otherwise, the procedure loops back and stays in step 310.
In step 320, a first data request is sent to a primary server JS via a second interface 120. The first data request RQ1 is configured to cause the primary server JS to forward medical data PDID relating the user from the primary server JS to the central database 140.
Then, a step 330 checks if medical data PDID relating to the user have been obtained via the second interface 120; and if so, a step 340 follows. Otherwise, the procedure loops back and stays in step 330. In step 340, the obtained medical data PDID are stored in the central database 140.
Thereafter, the procedure pauses until a data enquiry ENQ from a third party DU. Consequently, if no such data enquiry ENQ is received, the procedure stops in step 340.
Here, however, in a step 350, we assume that a data enquiry ENQ from a third party DU is received via a third interface 130. The data enquiry ENQ encompasses a request for the medical data PDID relating to the user and which medical data PDID are stored in the central database 140.
Subsequently, a step 350 checks if the user has authorized sharing the medical data PDID requested in the data enquiry ENQ with the third party DU. Only if the user has authorized such sharing a step 360 follows. This means that, if the user has not authorized such sharing, the procedure ends after step 350. It is worth noticing that the user authorization may contain conditions not only in terms of which data can be shared, however also for what purposes and until which latest point in time.
In step 360, a copy of the medical data PDID requested in the data enquiry ENQ is forwarded to the third party DU via the third interface 130.
All of the process steps, as well as any sub-sequence of steps, described with reference to
Alternatively, the carrier may be an integrated circuit in which the program is embedded, the integrated circuit being adapted for performing, or for use in the performance of, the relevant processes.
Variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed invention, from a study of the drawings, the disclosure, and the appended claims.
The term “comprises/comprising” when used in this specification is taken to specify the presence of stated features, integers, steps or components. The term does not preclude the presence or addition of one or more additional elements, features, integers, steps or components or groups thereof. The indefinite article “a” or “an” does not exclude a plurality. In the claims, the word “or” is not to be interpreted as an exclusive or (sometimes referred to as “XOR”). On the contrary, expressions such as “A or B” covers all the cases “A and not B”, “B and not A” and “A and B”, unless otherwise indicated. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. Any reference signs in the claims should not be construed as limiting the scope.
It is also to be noted that features from the various embodiments described herein may freely be combined, unless it is explicitly stated that such a combination would be unsuitable.
The invention is not restricted to the described embodiments in the figures but may be varied freely within the scope of the claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| 21178066.3 | Jun 2021 | EP | regional |
