Patent Description:
Before a patient undergoes an examination, e.g. with a medical imaging device, he needs give his informed consent based upon a clear appreciation and understanding of the facts, implications, and consequences of an examination. The informed consent needs to be documented tamper-proof.

After the examination, the patient wants to receive the examination results (e.g. DICOM images).

In state of the art systems, the informed patient consent was documented archiving a paper "patient consent form" which is filled in and signed by the patient prior to the examination. The content of the consent form is adapted to the special nature of the examination by having several pre-printed forms on stock of by printing the form on-demand.

The disadvantages of a paper consent form are first of all infrastructure cost for preparing, stocking, and archiving the paper consent form. Second, patients require significant time for filling in the form.

After the examination, in state of the art systems, the patient receives physical copies of the examination results. This can be in the form of e.g. paper printouts, film sheets, optical media, or other digital storage media. The disadvantages of delivering the examination data on physical media to the patient are first again infrastructure cost for preparing the physical media. Second, staff will need time for preparing and handling the physical media. Another disadvantage is that physical media when passed to the patient can be destroyed or damaged. Moreover, the patient or referring physician might not have the required infrastructure for reading the examination data from the physical media.

Thus, in known systems according to state of the art, the informed patient consent as well as the examination results, for example medical images, are exchanged in analog form, for example via printed and signed paper or by a physical data carrier.

In state of the art it is known to provide web-based patient portals where patients and referring physician can log in to retrieve examination data. The disadvantages of these portal-based systems, however, are unsecure distribution of login credentials and the fact that medical data must be stored on the web server. The web server infrastructure must then comply to the data protection regulations of the respective location.

The closest prior art is indicated in <CIT> which is directed to a system and method for generating, storing and accessing secured medical imagery. The solution is primarily directed to provide secure access to medical images by a medical professional who can access a secure medical imagery system including capture of images of a patient. Access to secure images can be shared with a patient or another medical professional only after a first authorization by a medical professional has taken place. However, in that case a contact database is necessary in order to provide additional contact information (patients, other medical professionals).

An object of the present invention is to improve the known approach. In particular, the disadvantages, mentioned above should be eliminated. Further, the data, comprising protected health data should be communicated in a simple but tamper-proof way and more efficiently without the need of special infrastructure.

This object is achieved by the subject matter according to the independent claims with the respective claimed features. Advantageous embodiments are the subject matter of the dependent claims, the description and the figures.

According to a first aspect the present invention refers to a method for a patient's mobile device for receiving secure access to personal medical data, wherein the personal medical data comprises protected health information and image data, which is stored in a data store in encrypted form, using an asymmetric key pair with a public key and a private key, wherein the method is executed on the patient's mobile device and comprises the method steps:.

This solution has the advantage that the hospitals and hospital network and infrastructure providers can save significant cost which is normally incurred for infrastructure and work time of physical media-based patient consent and image delivery solutions.

In general, the present invention is based on the idea, to simplify the information exchange of protected health data (PHI data) by combining simple means, namely a QR-code based method to effortless integrate the patient's mobile device into the hospital workflow together with the method to keep the private encryption key always on the patient's mobile device and thus guaranteeing data protection. The cloud itself does not need to fulfill any special requirements or regulations in terms of data protection, which is an enormous advantage, too.

The invention replaces patient consent and examination data delivery based on physical media by digital, cloud-based solution that makes use of the patient's mobile device. Data security is guaranteed by using asymmetric encryption and keeping the private key on the patient's mobile device at all times.

With the proposed solution, it is possible to offer a pure digital patient consent and data delivery method which meets all of the requirements relating to security and data protection and further requirements related to the medical domain and which will appeal to more and more patients as they become familiar with using personal mobile devices. Especially in developing countries, a smart phone is often the only personal computer a patient owns. Therefore, delivering images on a smart phone is superior to delivering images on a CD with built-in Windows based viewing software when the patients and referring physicians do not own Windows PCs.

According to a preferred embodiment of the invention the method is executed as a web client of the web service and is run in a browser on the patient's mobile device. A web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (e.g. WSDL). Other systems interact with the web service in a manner prescribed by its description using e.g. SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other web-related standards. In an alternative embodiment, the method may also be executed as a dedicated mobile application, to be run on a processor of the patient's mobile device.

According to another preferred embodiment of the invention the step of 'navigating' the web client of the patient's mobile device to a web service is executed by accessing a URL link, where the web service is accessible. For example, a receptionist at the hospital may inform the patient about the link to be used. Or the link may be provided in written form by the receptionist.

Another preferred embodiment for navigating the user to the correct web page is that a second code (preferably a QR code) will be presented to the patient during his registration procedure at the receptionist's desk and the user of the patient's mobile device scans the provided second (QR) code, which will navigate the user's browser automatically to the correct URL for the web page in order to access the web service.

In another preferred embodiment of the invention the encrypted images are typically received from a data store to be deployed as a cloud-based data store or cloud server, which is accessible via web technology such as HTTP for transferring machine-readable file formats such as XML and JSON.

In another preferred embodiment of the invention, the personal medical data comprises protected health information (PHI) and may comprise image or other patient examination data or historic anamnestic or other PHI data, which is stored in the data store or cloud server in encrypted form (using the public key of the key pair for encryption). This improves security of the method and system.

In another preferred embodiment of the invention, it is assured that the personal medical data is always transmitted in encrypted form whenever personal medical data leaves the hospital server. This feature also improves the security level.

In another preferred embodiment of the invention, the method further comprises the steps of:.

According to another preferred embodiment, the fist code (which may preferably be QR code) encodes the user identification (UID) and thus indirectly references the patient's public key. This feature has the major technical advantage that only less data volume needs to be transferred from the patient's mobile device to the hospital server, because the UID is much more smaller than a public key of an asymmetric key pair and requires less transmission resources (for storage and bandwidth). A UID is typically <NUM> bits long whereas the public key of a state of the art asymmetric encryption system is typically <NUM> bits long.

According to another preferred embodiment, the nearfield data transmission is a transmission for digital signals. The nearfield data transmission is preferably a wireless data transmission. Different technologies for the nearfield data transmission may be applied with one security requirement, namely requiring a personal contact between the patient at his patient mobile device and a user of at the hospital server, in particular a registration server. This assures that misuse and attacks can be prevented. Moreover, an additional security check may be applied in that the receptionist will require the patient to identify her or himself with another identification object, like e.g. his identity card which may be compared with the patient. The nearfield data transmission may be implemented as optical transmission for transmission of the first code. In particular the first code may be a QR code or bar code. Another option is to use other nearfield communication protocols and standards like NFC (nearfield communication), which is a set of protocols, based on radio-frequency identification (RFID) standards including ISO/IEC <NUM>. NFC communication typically requires a distance of <NUM> or less between the communicating devices. Preferably, passive NFC tags may be used without power supply requirement. In order to provide faster operations, another option is to use a Bluetooth connection, requiring a distance of less than <NUM>. In certain scenarios also WiFi may be applied as a technology for wireless local area networking with devices based on the IEEE <NUM> standards.

According to another preferred embodiment, the data store is deployed as cloud server to be accessed via an internet protocol (like https, https. In other embodiments, the data store is deployed within a hospital network and is operated by the hospital server. In this case, the data connection between the hospital server and the data store is an internal communication connection. Although, the PHI data, stored in the data store, will be encrypted so that even in case of an attack, the data will not be compromised.

In another aspect the invention refers to a method to be executed on the hospital server. The method is intended for providing access to personal medical data and comprises the method steps:.

In another aspect the invention refers to a method to be executed on a patient's mobile device in communication with a hospital device and thus is to be executed in a distributed manner on both of the devices. The method is intended for communication of personal medical data and comprises the method steps:.

According to a preferred embodiment the hospital server accesses a Radiology Information System (RIS) in order to calculate an estimated waiting time for a scheduled medical examination for the patient and wherein this estimating waiting time is transmitted in an estimated-wait-message to the patient's mobile device.

In a further aspect the invention refers to a hospital server for providing access to personal medical data, wherein the hospital server comprises:.

In another aspect the invention relates to a system for communication of personal medical data between a hospital server and a patient's mobile device, with:.

It is to be noted that the methods described above may be provided as computer program with computer instructions to execute a method according to the description above, if the computer program is executed on a computing device, like the patient's mobile device, the hospital server or any other computing entity.

In the following a short definition of terms is given, used within this application.

The patient's mobile device is a mobile device with computing functionality. It may be a smartphone, a tablet or any other device which is associated to the patient. This device does not require any specific or additional installation of software or hardware. The patient's mobile device is a mobile device owned and operated by the patient or his guardians.

The hospital server is located within a hospital network, where an examination unit is located. The hospital server is a (preferably: mobile) device with internet connectivity owned by the hospital and operated by the receptionist. The hospital server may be the unit itself on which the web service runs. Alternatively, the hospital server may be in data connection to another unit in the hospital network on which the web service runs. The hospital server may preferably be a mobile unit, like a smartphone or a tablet, which may be used by the receptionist of the hospital. Thus, the hospital server is a server owned and operated by the hospital. It needs to have network connectivity to the medical imaging device and/or to the cloud-based data store and internet connectivity.

The data store is a data storage node and may provide physical or virtual storage capacity. The data store may be deployed within the hospital network and operated by the hospital server for different patients. Then, it is assured that each of the different patients will have his own partition on the server and that a patient only may get access to "his" or "her" personal data. The data store is accessible publicly. In another preferred embodiment the data store is deployed as cloud store and is also accessible via internet from the patient's mobile devices and from the side of the hospital network with the examination units and the hospital server. The PHI data, stored in the data store are encrypted in each of the embodiments mentioned above. The cloud is to be construed as providing elastic cloud services.

The hospital network usually comprises a medical imaging device, which is a device that produces examination data (e.g. MRI Scanner, CT device etc.). The produced data are PHI data and need to be transmitted to the patient in a secure and simple manner.

The patient's mobile device interacts with the web service via its browser and executes code, e.g. JavaScript code, which was received from the web service via standardized protocols (e.g. XML, JSON-based protocols, Web Services Conversation Language - WSCL and others).

The first and/or the second code may be provided as QR code. The first code represents the UID and the second code only serves as a measure to navigate and direct the browser to the web service and to load the respective web service instructions.

The personal medical data are related to the patient and are characterized to be protected. The personal medical data comprise protected health information (PHI data). The personal medical data may comprise medical examination data (by an imaging examination like CT, MR, etc.), anamnestic data or any kind of other personal data.

The key pair is generated by means of an asymmetric encryption algorithm and comprises a public key and associated private key. The private key will never leave the sphere of the patient's mobile device and will be stored locally on the patient's mobile device. In a preferred embodiment, the private key and/or the decrypted personal data (after being received in encrypted form from the data store) are stored in a secured private storage of the patient mobile device acting as web client. This feature helps to improve security of the system as a whole. The key pair is generated when the patient visits the web service in the hospital for the first time. If he uses the service repeatedly, it is possible to use the generated key pair once more. No new key pair needs to be generated. The user identification (UID) is a unique identifier which uniquely identifies the key pair. It requires less storage than the public key of the key pair.

The invention, in particular the method mentioned before, may be provided as a computer program loadable into a processing unit of a network unit, a patient's mobile device and/or a hospital server. The computer program comprises code adapted to perform the steps of the method as mentioned before when processed by the processing unit. The computer program may be stored on a computer readable medium or data carrier, like a memory stick. The computer program may also be downloaded in downloadable form from a server entity. The computer program may be virtualized and/or may be distributed over different network nodes.

In the following, the invention will further be described with reference to exemplary embodiments illustrated in the figures, in which:.

The present invention relates to systems and methods to replace physical media-based patient consent and image delivery workflows by a pure digital solution while maintaining equal or better data protection.

An important aspect of the invention is the seamless integration of the patient's mobile device via the use of QR-codes and the storage of the private key of the asymmetric encryption on the patient's mobile device only.

The basic workflow is described below with reference to <FIG>.

A patient operates his mobile device PD (shown in <FIG> above) and a receptionist is operating a hospital server HS, both operating connections are shown in dotted lines in <FIG>. The dotted lines are, thus, no data connection but should reflect a usage or operation of the respective device PD, HS. The dashed line from patient's mobile device PD to hospital server HS is a data connection different form the other data connection channels shown in normal solid lines. The dashed line should reflect a nearfield communication technology, like a QR code scan transmission via NFC or other protocols, explained in more detail below. The solid lines refer to wireless or wire-bound data transmission via respective protocols.

When the patient visits the hospital to undergo an examination, he will bring his own mobile device PD with internet connectivity.

He will be asked by the receptionist to navigate his browser to the web portal of the web service, which in <FIG> is depicted with reference numeral <NUM>. The user can navigate to the web portal of the service by either entering an URL or by scanning a second code, in particular a QR code, which is displayed in the reception room.

The portal page of the service will instruct the web client of the patient's mobile device PD to create a user account with an asymmetric encryption key pair (Pu = public key, Pr = private key) and a user identification Uid. This is depicted in <FIG> with reference numeral <NUM>. The user identification UID, and the private key of the asymmetric key pair Pr will be stored in the private data store of the web client. The public key Pu will be filed in a data store DS, which may be implemented as cloud server under key Uid. Uid will be displayed as QR code on the portal page.

The receptionist will then scan the QR code, provided with transmission referenced with <NUM> by the patient, with hospital server HS, which may be provided as mobile device as well. The hospital server HS will file a GET request message to the cloud-based data store DS at 4a. In reply to this GET request, the data store DS will provide the public key Pu filed under UID to the hospital server HS at 4b. In reply to this, the hospital server HS will connect patient's public key Pu and user identification Uid with a study ID StudyId generated by e.g. a RIS (radiology information system), which is represented with reference numeral 4c. The tuple (Uid, Pu, StudyId) is then sent to a central server CS, referenced in <FIG> with <NUM>. The patient data is encrypted with the public key Pu and uploaded to the cloud-based data store DS at <NUM>.

It is to be noted that the hospital server HS is preferably provided as mobile device. The hospital server HS, the central sever CS and the Medical Imaging Device MID can be incorporated by a single device. Further, the data store DS is preferably deployed as cloud store. However, it is also possible to locate the data store DS in the hospital network HNW.

While the patient waits for his examination, he can view the patient information in a provided patient consent form, to be signed by the patient. The patient information, the patient consent form and optionally further information (e.g. a calculated, prognosed waiting time) are provided directly on the patient's mobile device PD, depicted in <FIG> with reference numeral 7a. After having received the data package at patient mobile device PD, the patient may read and fill in the form and complete the same in order to prepare a message back. Before sending the message back, it will be encrypted. In particular, the web client on the patient's mobile device PD will sign the patient consent with private key Pr in order to generate the message to be sent to the cloud data store DS. Therefore, the document with the patient consent is transmitted in a tamper-proof way.

At step <NUM>, the patient then undergoes the examination. In step <NUM>, the Medical Imaging Device MID sends the examination data to the central server CS, using a suitable communication protocol (e.g. DICOM). The central server CS will encrypt the received examination data with the public key Pu and file it in step <NUM> (which means: transmit and store) under user identification Uid and (together with) a session identification Sid in the cloud-based data store DS.

After the examination, the patient will download the examination data from the cloud at step <NUM>. After having received the encrypted message, the patient's mobile device PD will decrypt it with the private key Pr, store it locally and view it on the web client or a dedicated mobile application.

<FIG> shows the data exchange in more detail. In step <NUM> the patient goes to the receptionist and is directed to the web service via an information provided at the receptionist's desk or via a second (preferably QR) code, provided there. In step <NUM> the key pair is generated with public key Pu, private key Pr and user identification UID. In step <NUM> the public key Pu is transmitted and filed in the cloud-based data store DS under the user identification UID. In step <NUM> the private key Pr is stored locally in the web client on the patient's mobile device PD, preferably in a secured storage space.

A first QR code is generated locally at the patient's mobile device PD, comprising the UID. The code may be a QR code, which is transmitted to the hospital server HS, which in reply to the received data message, scans the QR code in step <NUM> by an optical sensor device. In step <NUM> the hospital server HS accesses the data store DS in order to get the associated public key Pu, which is stored under the user identification UID. In step <NUM> the hospital server HS connects the public key Pu with the patient data and generates a tuple with public key Pu and a DICOM StudyIntanceUID, to be sent to the central server CS in step <NUM>. In step <NUM> the hospital server HS sends an encrypted patient data procedure information (or patient consent form to be completed by the patient) to the data server DS. In step <NUM> the data store DS sends the encrypted patient data procedure information (or patient consent form to be completed by the patient) to the patient's mobile device PD, where the patient's mobile device may decrypt the data with the private key Pr (not explicitly shown in <FIG>) and then may read the procedure information in clear text. The patient may complete the patient consent form. The completed patient consent form will then be encrypted again with the private key Pr and will be sent in step <NUM> to the data store DS.

After the completed patient consent was received in the hospital network system HNW, the patient's examination may be executed in step <NUM>. In step <NUM> the generated DICOM images will be sent form the medical imaging device MDI to the central server CS. In step <NUM> the central server CS will send the encrypted DICOM images, being encrypted with the public key Pu, to the data store DS so that the data store DS may forward the encrypted images to the patient's mobile device PD at step <NUM>. Again, at the patient's mobile device PD, the web service will instruct the device PD to decrypt the received data by applying the private key Pr in order to provide the images in clear text on the patient's mobile device PD.

<FIG> shows a flow chart of a method to be executed on the patient's mobile device PD for receiving PHI data, and in particular his examination results. In step <NUM> the browser of the patient's mobile device PD is navigated to the web service http address. In step <NUM> instructions are received from the web service for the web client to create a user account, comprising an asymmetric key pair Pu, Pr and a user identification UID. If a user account (Pu, Pr, UID) already exists from a prior session, it may be reused. In step <NUM> the private key Pr and the user identification UID is stored locally on the patient mobile device PD. In step <NUM> a data message is generated and prepared for being sent to the data store DS under the user identification UID, acting as key. In step <NUM> a first code, namely a QR code, is generated, encoding the user identification UID. In step <NUM>, the generated first code is prepared for transmission to a hospital server HS by using a nearfield data transmission, in particular via an optical channel or a digital protocol for nearfield communication, like NFC or Bluetooth, requiring the personal presence of the patient's mobile device (acting as sender) and the (mobile) hospital server HS, operated by the receptionist. In step <NUM> encrypted images, being encrypted with the public key Pu are received at the patient's mobile device PD, which may be decrypted in step <NUM> with the private key Pr. After this, the method may end or may be iterated again.

In a preferred embodiment, the method may additionally but optionally comprise the following steps, which are shown in hashed line in <FIG>:.

<FIG> shows a flow chart of a method to be executed on the hospital server HS. After Start, in step <NUM> a first code, namely the QR code is received from the patient's mobile device PD via the nearfield data communication, requiring personal presence of the patient and the receptionist with their electronic mobile devices PD, HS. In step <NUM> the user identification UID is extracted from the received first code. In step <NUM> the data store DS is accessed with the extracted user identification UID for getting the corresponding associated public key Pu of an asymmetric key pair in step <NUM>. In step <NUM> the personal medical data is encrypted by using the pubic key Pu. In step <NUM> the encrypted personal medical data is sent to the data store DS for making it accessible by the patient's mobile device PD.

<FIG> shows a block diagram of a hospital server HS in an overview manner. The hospital server may be a mobile electronic device with internet functionality and with interfaces to the hospital network HNW and which may further receive the scanned first code (QR code). In this case, however, additional security requirements have to be met for the mobile device in order to make sure that PHI data, which is at least temporarily stored in clear text on this device can not be compromised. The hospital server HS comprises a code interface HS1, which is adapted for receiving a first code, encoding a user identification UID, wherein the user identification UID identifies a patient's mobile device PD. The hospital server HS further comprises a processor P for extracting the user identification UID from the received first code and a data store interface HS2 for accessing a data store DS with the extracted user identification UID for getting an associated public key Pu of an asymmetric key pair Pu, Pr, wherein the processor P is further adapted for using the public key Pu for encrypting personal medical data and for sending encrypted personal medical data to the data store DS for making it accessible by the patient's mobile device PD.

Claim 1:
Method for receiving secure access to personal medical data, wherein the personal medical data comprises protected health information and image data, which is stored in a data store in encrypted form, using an asymmetric key pair with a public key and a private key, wherein the method is executed on a patient's mobile device (PD) and comprises the method steps:
- Navigating (<NUM>) a web client of the patient's mobile device (PD) to a web service;
- Receiving (<NUM>) instructions from the web service for the web client to create a user account, comprising an asymmetric key pair, Pu, Pr, and a user identification, UID, which references the asymmetric key pair, Pu, Pr;
- Storing (<NUM>) the private key (Pr) of the asymmetric key pair and the user identification, UID, locally on the patient mobile device (PD);
- Preparing (<NUM>) the public key of the asymmetric key pair to be filed in a data store (DS) under the user identification, UID, acting as key;
- Transmitting the public key and the user identification of the asymmetric key pair to the data store (DS) in order to file the public key in the data store (DS) under the user identification, UID, acting as key;
- Generating (<NUM>) a first code, encoding the user identification, UID;
- Preparing (<NUM>) the generated first code for transmission to a hospital server (HS) by using a nearfield data transmission;
- Transmitting the first code to the hospital server (HS) by using the nearfield data transmission to allow the hospital server (HS) to access the data store (DS) with the user identification in order to retrieve the associated public key;
- Receiving (<NUM>) encrypted images, being encrypted with the public key, Pu;
- Decrypting (<NUM>) the received encrypted images with the private key, Pr, for providing decrypted personal medical data as a result locally on the patient's mobile device (PD).