System and method for anonymizing and transmitting health data across geographic areas for analysis

Abstract

Systems and methods for protecting patient privacy while transmitting health data from one geographic area to another for data analysis are disclosed. A method includes receiving, at a first region, patient-specific health data including patient privacy information; removing patient privacy information from the patient-specific health data to generate anonymous health data; storing the patient privacy information in the first area; and transmitting the anonymous health data to the second area for analysis.

Description

[0001] Related Applications This application claims the benefit of U.S. Provisional Application No. 62 / 355,742, filed on June 28, 2016, the entire disclosure of which is incorporated herein by reference in its entirety. Background Art

[0002] Different countries or geographic regions may have different requirements for protecting patient privacy. Such requirements may limit or prevent the transfer of health data or health information across borders. For example, U.S. law attempts to protect patient privacy by defining a category of information that can link personal health information to an individual. This type of information is called "protected health information (PHI)", and U.S. healthcare professionals and service providers (e.g., doctors, hospitals, insurance companies, covered entities, business partners, etc.) are subject to regulations that govern the use and transfer of PHI-related data. Other countries and regions may include similar regulations, laws, and / or standards. For example, Canada protects patient information at the federal and provincial levels. As another example, starting May 25, 2018, Europe will protect personal data (including medical information) under the General Data Protection Regulation (GDPR).

[0003] At the same time, specific data analytics capabilities may only exist within a certain region. For example, a particular healthcare company may only have data analytics facilities in a selected region. Patients outside of that selected region may not be able to access the company's data analytics services because patient privacy regulations may dictate that their health data cannot be transferred to the selected region. Due to patient privacy regulations, patient access to various medical analytics may be limited, and data analytics companies may not be able to provide services to patient populations from different regions. In short, patient privacy regulations that restrict the cross-border transfer of patient privacy information may mean that data cannot be analyzed by data analytics facilities that exist outside the region. Therefore, patients may be limited to the data analytics capabilities available in their region. In addition, data analytics companies may have to maintain facilities in each region that are governed by a specific set of patient privacy regulations in order to provide services to patients in that region.

[0004] Therefore, it is desirable to protect patient privacy while still allowing data collected in one region to be analyzed in a second region. The foregoing general description and the following detailed description are exemplary and explanatory only and are not limiting of the present disclosure. According to one embodiment, various embodiments of the present disclosure are directed to systems and methods for protecting patient privacy while transferring health data from one geographic region to another geographic region for data analysis. Summary of the invention

[0005] According to certain aspects of the present disclosure, systems and methods are disclosed that allow health data to be transferred and analyzed between regions while protecting patient privacy.

[0006] A method includes receiving patient-specific health data including patient privacy information at a first region; removing the patient privacy information from the patient-specific health data to generate anonymous health data; storing the patient privacy information at the first region; and transmitting the anonymous health data to a second region for analysis.

[0007] According to another embodiment, a system for providing cross-border health data transmission while protecting patient privacy includes: a data storage device storing instructions for providing cross-border health data transmission while protecting patient privacy; and a processor configured to: receive patient-specific health data including patient privacy information in a first area; remove the patient privacy information from the patient-specific health data to generate anonymous health data; store the patient privacy information in the first area; and transmit the anonymous health data to a second area for analysis.

[0008] According to another embodiment, a non-transitory computer-readable medium containing computer-executable programming instructions for use on a computer system, wherein the computer-executable programming instructions are used to execute a method for providing cross-border health data transmission while protecting patient privacy, the method comprising: receiving patient-specific health data including patient privacy information in a first region; removing the patient privacy information from the patient-specific health data to generate anonymous health data; storing the patient privacy information in the first region; and transmitting the anonymous health data to a second region for analysis.

[0009] Other purposes and advantages of the disclosed embodiments will be explained in part in the following description, and in part will be obvious from the description, or can be understood by the practice of the disclosed embodiments. The purposes and advantages of the disclosed embodiments will be realized and obtained by the elements and combinations particularly pointed out in the appended claims.

[0010] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosed embodiments, as claimed.

[0011] Other purposes and advantages of the disclosed embodiments will be explained in part in the following description, and in part will be obvious from the description, or can be understood by the practice of the disclosed embodiments. The purposes and advantages of the disclosed embodiments will be realized and obtained by the elements and combinations particularly pointed out in the appended claims.

[0012] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosed embodiments, as claimed. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various exemplary embodiments and, together with the description, serve to explain the principles of the disclosed embodiments.

[0014] Figure 1 is an exemplary schematic block diagram of a cross-border data system for transmitting health data via a cloud platform according to an exemplary embodiment of the present disclosure.

[0015] Figure 2 is a flow chart of an exemplary method for transmitting health data via cloud platforms in different regions according to an exemplary embodiment of the present disclosure; Figure 3A is a block diagram of an exemplary data privacy system for transmitting health data across borders without compromising patient privacy according to an exemplary embodiment of the present disclosure.

[0016] Figure 3B is a block diagram of an exemplary patient privacy platform according to an exemplary embodiment of the present disclosure, which can both prepare data for transmission to a second area and receive analyzed data from an external area.

[0017] Figure 3C is a flow chart of an exemplary method of removing patient privacy information from health data according to an exemplary embodiment of the present disclosure.

[0018] Figure 3D is a flow chart of an exemplary method of associating analyzed data to stored patient privacy information according to an exemplary embodiment of the present disclosure.

[0019] Figure 4A is a block diagram of an exemplary data analysis system for analyzing anonymized data according to an exemplary embodiment of the present disclosure.

[0020] Figure 4B is a block diagram of an exemplary analysis platform for analyzing health data received from different regions according to an exemplary embodiment of the present disclosure.

[0021] Figure 4C is a flow chart of an exemplary method of analyzing anonymized data according to an exemplary embodiment of the present disclosure.

[0022] As used herein, the term "exemplary" is used in the sense of "example" rather than "ideal". In addition, the terms "first", "second", etc. do not indicate any order, quantity, or importance, but are used to distinguish one concept or structure from another concept or structure. In addition, the terms "one" and "an" in this article do not indicate a quantitative limitation, but rather indicate the presence of one or more referenced items. For the purposes of this disclosure, "patient" may refer to any individual or person for whom a diagnostic or therapeutic analysis (e.g., data analysis) is performed, or any individual or person associated with a diagnostic or therapeutic analysis of one or more individuals.

[0023] The term "health data" may include medical data collected for a patient in a practice, as well as health data collected for a patient by any healthcare provider, laboratory, specialist, clinician, etc. Health data may be associated with a specific patient, where the patient may be identified by patient privacy information. Patient privacy information may be any information that links health data to a specific individual. Patient privacy information may be defined objectively (as information that associates an individual with his / her health data) and / or defined by laws and regulations. Various regions may include different definitions of what information constitutes patient privacy information. "Region" may refer to any environment where the borders are defined by regulations that protect patient privacy. In one embodiment, "region" may refer to a known geographic region governed by a series of regulations that protect patient privacy / personal data. For example, "region" may refer to a state (e.g., California), a country (e.g., the United States, Japan, Canada, etc.), or a group of countries (e.g., Europe) that operate in accordance with a single series of patient privacy laws. For the United States, patient privacy information may include protected health information (PHI). For the United States and various other regions, patient privacy information may include personal health information, patient identity information, etc.

[0024] Alternatively or additionally, a “region” may refer to a given physical facility, a given entity's computing system, or a given cloud platform. In this case, the different regions where health data is compiled may still exist within a single country, state, or province. For example, a first region may include a hospital that can remove patient privacy information from the collected health data before transmitting the health data to a second region (e.g., a cloud platform) for data analysis. The hospital and the cloud platform may exist in the same geographically defined region, such as the United States. DETAILED DESCRIPTION

[0025] Reference will now be made in detail to exemplary embodiments of the present disclosure, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numerals will be used throughout the drawings to refer to the same or like parts.

[0026] The present disclosure includes a system and method for allowing the transmission and analysis of health data between regions while protecting patient privacy. In one embodiment, patient privacy information in health data generated in one region can be removed and the health data can be transmitted to a second region. The health data can be analyzed in the second region, and then the analyzed data can be transmitted from the second region to the first region, where the health data is associated with its corresponding patient privacy information. In this way, data analysis can be performed in a remote region without transmitting patient privacy information to the remote region. In this way, the transmission of health data can include modifying and editing the health data so that the data can be analyzed in the remote region.

[0027] In one embodiment, the cloud platform in the first area can receive health data. The health data may include patient records / health information with or without patient privacy information. The health data may include data generated, generated, or received in the first area. For example, the health data may include image data generated from one or more imaging modalities (e.g., CT, MRI, ultrasound, etc.).

[0028] In one embodiment, health data can be separated from patient privacy information in a first area. For example, before the health data is transferred from the first area to the second area, the health data can be separated from the patient privacy information. The cloud platform in the first area can remove any detected patient privacy information from the received health data and store the patient privacy information through any storage medium. For example, the cloud platform in the first area can receive a health data file of a CT scan, where the CT scan is associated with PHI. For this scenario, the cloud platform in the first area can remove the PHI from the received CT scan and store the PHI. The PHI can be stored in a PHI storage system (e.g., a PHI database).

[0029] The cloud platform in the first area can communicate with the cloud platform in the second area. For example, the cloud platform in the first area can transmit anonymized health data (e.g., health data without patient privacy information) to the cloud platform in the second area. In other words, the health data can be transmitted to the second area, while its associated patient privacy information is retained only in the first area. In one embodiment, the cloud platform in the first area can receive a data analysis request associated with a received health data file. The cloud platform in the first area can identify that the requested data analysis should be performed in the second area. The cloud platform in the first area can then communicate with the cloud platform in the second area to prompt the cloud platform in the second area to complete the requested data analysis. In one embodiment, the second area can notify the first area when the data analysis is completed, or when the analyzed data is available for re-identification.

[0030] In one embodiment, data analysis can be performed in the second area. For example, a report of the analyzed data can be generated in the second area. In one scenario, the cloud platform in the second area can receive anonymized health data, generate an anonymous report of the analyzed data, and transmit the anonymous report to the cloud platform in the first area. For example, the report may include a portable document format (PDF) file of one or more metrics, graphs, images, treatment recommendations, etc. derived from the data analysis performed on the anonymized health data. Alternatively or additionally, the report may include files that can provide various interactive interfaces to the user, including, for example, anatomical models, comparisons with population data, predictions, simulations (e.g., treatment effects, fluid flow, heat transfer, etc.), treatment recommendations, etc.

[0031] In one embodiment, the first regional cloud platform can receive the anonymous report and match the report with the patient. For example, the anonymous report can be associated with an identifier corresponding to the patient privacy information corresponding to the patient privacy information stored in the first regional cloud platform.

[0032] In one embodiment, the first regional cloud platform may mark patient health data with an identifier that is not related to patient privacy. The identifier may be random, not data-specific, and / or associated with a region, time / date, hospital, etc. The identifier may be used to track patient data without patient privacy information because the data may be separated from the patient privacy information before being transmitted out of the first region. In one embodiment, the cloud platform of the first region may include a database of stored patient privacy information, such as a PHI database. Once a report of the analyzed health data is transmitted to the first cloud platform and the first region, the first cloud platform may match the identifier with the stored patient privacy information (e.g., the stored PHI of the PHI database).

[0033] In one embodiment, in the described systems and methods, patient privacy information can be encrypted in each iteration of its use and existence. For example, patient privacy information can be encrypted during the transfer process (e.g., transmission within the region, transmission to a storage device, removal from a storage device, etc.), encrypted at rest (e.g., during storage, classification, data collection, etc.), or encrypted during reattachment to analyzed data, etc. For example, when PHI is received with patient health data, PHI can be encrypted. When PHI moves over an encrypted link (e.g., Secure Sockets Layer (SSL)), it can be further encrypted. SSL can provide increased security on the network. PHI can also be encrypted when classified before storage and encrypted (again) when stored. For example, PHI can be stored in a location that can be encrypted (e.g., a database). One or more keys of the storage location can be securely stored so that even if the storage location is known, the stored content can be encrypted and inaccessible. PHI can be further encrypted when retrieved from the database and / or used to generate a new report. In another embodiment, all data transmitted within the disclosed system (e.g., patient privacy information, health data, stored data, analyzed data, identifiers, hashes, etc.) can be encrypted.

[0034] Alternatively or additionally, a hash of the patient's privacy information can be generated or used to anonymously link the patient's privacy information to an identifier. For example, the patient's privacy information of the selected patient is used as the input of the hash function, and the hash function can output a hash. Even if the hash does not include the patient's privacy information, the hash can be mapped to the input patient's privacy information. In one embodiment, the hash function can be an irreversible hash function that can omit the patient's privacy information. Exemplary hash functions include SHA1, MD5, encryption algorithms (bcrypt), etc. Any hash function can be used, but the same hash algorithm can be used in each case so that different data sets can be mapped to each other. In one embodiment, the hash can include a unique value calculated for each field that is considered to be patient privacy data. Any field of patient privacy information can be hashed. Exemplary hash fields can include: patient's first name, patient's last name, patient identifier (e.g., patient ID), patient's date of birth, referring doctor's name, referring doctor's last name, study date, study time, etc.

[0035] In one embodiment of hashing, PHI may be stored exclusively in a PHI database in a first region (e.g., the United States). The hash may be stored with an identifier associated with the PHI and / or patient health data. The hash may also be sent to a second region or stored in a permanent storage device in the second region. The hash may provide a method for longitudinally tracking health data in a second region without patient privacy information. In other words, the hash may allow data to be linked to another piece of data. In an illustrative example of hashing, a first platform in a first region may receive a first scan. The first scan may be a medical scan of patient John Doe. The first platform may store hashes of "John" and "Doe". At another time, a different scan may be received, also of John Doe. The first cloud platform may hash the received scan of John Doe again and compare the second hash with the stored hash. Since the second hash of the different scans may match the stored hashes of "John" and "Doe", the first region cloud platform may conclude that the scans belong to the same patient (e.g., John Doe).

[0036] In one embodiment, the hash can be generated and stored by the region where the case is created and pushed. In one embodiment, the hash can be transmitted between regions, while the patient privacy information is retained in the region where the patient health data is collected. Alternatively or additionally, the hash can be calculated when the anonymized health data is forwarded to the second region before data analysis.

[0037] Any cloud platform can use hashing to link data sets to each other as potentially associated with a specific individual, but only the cloud platform that originally collected the health data can link the hash to the patient's private information. The hash or identifier can allow health data to be tracked without transmitting private patient information across borders.

[0038] Figure 1 is a schematic diagram of a cross-border data system for transmitting health data between a first region and a second region. Figure 2 is a flow chart of an exemplary process for transferring health data between a first region and a second region. FIG. 3A to FIG. 3D Depicted are general embodiments of systems and methods at an exemplary "first area" that collects health data and stores patient privacy information related to the collected health data. FIG. 4A to FIG. 4C Depicts a general embodiment of an exemplary "second area" system and method in which analysis of anonymized health data may be performed. For clarity, Figures 1 to 4C A “first area” as a privacy protection area and a “second area” as a data analysis area are shown.

[0039] In practice, a geographic region can be both a privacy protection region and an analysis region, with the primary goal of keeping patient privacy information in the region where health data is generated. For example, data can be generated in Europe (e.g., region 1). The data can be stripped of patient privacy information and transmitted to the United States (e.g., region 2) for analysis. The U.S. cloud platform can generate analyzed data and transmit the analyzed data back to Europe, where the cloud platform can receive the analyzed data and pair the analyzed data with its corresponding patient privacy information. At the same time, the European cloud platform may be receiving raw health data from the United States with PHI removed, analyzing the health data, and transmitting the analyzed data to the United States, where the data will be associated with its corresponding PHI stored in the United States. Although the embodiments show the designated roles of the "first region" and the "second region", those of ordinary skill in the art will understand that a geographic region may have or provide the capabilities of both the "first region" and the "second region".

[0040] Furthermore, while the present embodiment describes an example scenario including two (2) geographic or geopolitical regions (e.g., the first region and the second region are different countries), the disclosed systems and methods may include embodiments including any number of regions, such as several different or various types of regions where private patient information may be removed, retained, and used to be reattached to received, analyzed data, and several regions where anonymous health data may be received and processed. In such a system, some region-to-region interactions may not necessarily trigger the removal of PHI information as a precursor to transferring data between regions, while other regions in the same system may exchange data only after patient private information compliance is satisfied.

[0041] Figure 1 It is an exemplary schematic block diagram of a cross-border data system 100 for transmitting health data via a cloud platform according to an exemplary embodiment of the present disclosure. The cross-border data system 100 may include multiple computing systems and / or devices configured to send and receive information from a data collection device 110, a cloud platform 113 in a first area, a cloud platform 120 in a second area, and a consumer device 130 through an electronic network. In one embodiment, the first area cloud platform 113 can be used as a data privacy platform (collecting and preparing data to protect patient privacy), while the second area cloud platform 120 can be used as a data analysis platform. In one embodiment, various components of each cloud platform 113 or cloud platform 120 can be in direct local contact with one or more other components of the cross-border data system 100. In one embodiment, the cross-border data system 100 can operate on a wide area network (WAN) or a local area network (LAN), and various components of the cross-border data system 100 operate remotely or independently from each other.

[0042] It should be understood that the cross-border data system 100 may include any type or combination of computing systems, such as handheld devices, personal computers, servers, cluster computing machines, and / or cloud computing systems. In one embodiment, the cross-border data system 100 may include a hardware assembly, including a memory, a central processing unit ("CPU"), and / or a user interface. The memory may include any type of RAM or ROM implemented in the following: a physical storage medium, such as a magnetic storage device including a floppy disk, a hard disk, or a tape; a semiconductor storage device, such as a solid-state disk (SSD) or flash memory; an optical disk storage device; or a magneto-optical disk storage device. The CPU may include one or more processors for processing data according to instructions stored in the memory. The functions of the processor may be provided by a single dedicated processor or multiple processors. In addition, the processor may include, but is not limited to, digital signal processor (DSP) hardware, or any other hardware capable of executing software. One or more user interfaces may include any type or combination of input / output devices, including a display monitor, a touchpad, a touch screen, a microphone, a camera, a keyboard and / or a mouse, or other interfaces. Each area of ​​the cross-border data system 100 may include an assembly of such components, as described in further detail below.

[0043] In one embodiment, the data collection device 110 can generate or receive health data. For example, the health data can include patient-specific image data (e.g., a Digital Imaging and Communications in Medicine (DICOM) file). In one scenario, the image data can include data about the geometry of the patient's heart, for example, data about at least a portion of the patient's aorta, the proximal portion of the main coronary arteries connected to the aorta (and branches extending therefrom), and the myocardium. Patient-specific anatomical data can be obtained non-invasively, for example, using non-invasive imaging methods. For example, CCTA is an imaging method in which a user can operate a computed tomography (CT) scanner to view and create images of structures such as the myocardium, the aorta, the main coronary arteries, and other blood vessels connected thereto. CCTA data can be time-varying, for example, to show changes in the shape of the blood vessels during the cardiac cycle. CCTA can be used to generate images of a patient's heart.

[0044] Alternatively, other non-invasive imaging methods including magnetic resonance imaging (MRI) or ultrasound (US), or invasive imaging methods such as digital subtraction angiography (DSA), can be used to generate images of the patient's anatomical structures. The imaging method can include intravenous injection of contrast agents into the patient to enable identification of anatomical structures. The resulting imaging data (e.g., provided by CCTA, MRI, etc.) can be provided by a third party provider, such as a radiology laboratory or cardiologist, the patient's physician, etc.

[0045] Other patient-specific anatomical data may also be determined non-invasively from the patient. For example, physiological data such as the patient's blood pressure, baseline heart rate, height, weight, hematocrit, stroke volume, etc. may be measured. The blood pressure may be the blood pressure in the patient's brachial artery (e.g., using a pressure cuff), such as the maximum pressure (systolic pressure) and the minimum pressure (diastolic pressure). Exemplary data collection devices 110 may therefore include imaging modalities, wearable devices, blood pressure cuffs, thermometers, fitness trackers, blood glucose meters, heart rate monitors, etc.

[0046] In one embodiment, health data may be received at a first regional cloud platform 113. The first regional cloud platform 113 may have two functions: (1) preparing the collected health data for analysis in a second region, and (2) matching the analyzed data received from the second region with patient privacy information stored in the first region. For the first function, the first regional cloud platform 113 may remove patient privacy information associated with the collected health data. For the second function, the first regional cloud platform 113 may receive analyzed data from the second region, wherein any patient privacy information is removed from the analyzed data. The first regional cloud platform 113 may identify which patient is associated with the received analyzed data and provide the consumer device 130 with access to the analyzed data. It should be understood that the first regional cloud platform may reside in any region, and the patient privacy information may correspond to the patient privacy regulations and standards of the corresponding first region. For illustration, an exemplary first regional cloud platform 113 may be located in the United States, where the patient privacy information may include PHI.

[0047] The first area cloud platform 113 may include various components, including a processor 115, a PHI storage device 117, and a result storage device 119. In one embodiment, the processor 115 may receive data collected in the first area. Patient-specific anatomical data obtained (e.g., by the data collection device 110) may be transmitted via a secure communication line (e.g., via a network). For example, the data may be transmitted to a server or other computer system. In an exemplary embodiment, the data may be transmitted to a server or other computer system operated by a service provider (e.g., cloud platform 113) that provides network-based services. Alternatively, the data may be transmitted to a computer system operated by a patient's doctor or other user, for example, for analysis, viewing, or storage in the first area.

[0048] In an exemplary embodiment where the patient privacy information includes PHI, the processor 115 may further remove the PHI from the collected health data. For example, the processor 115 may separate the health data from the associated PHI and store the PHI (e.g., using the PHI storage device 117). In one embodiment, the processor 115 may further create one or more hashes of the PHI, wherein the one or more hashes do not contain the PHI. The hash may be irreversible. The processor 115 may transfer the data to the second area so that the data is transmitted with the one or more hashes, but without the PHI. The PHI may remain in the first area. In one embodiment, when the analyzed data from the second area enters the first area, the result storage device 119 may be accessed at a later stage. For example, the result storage device 119 may store the analyzed data from the second area.

[0049] In one embodiment, the processor 115 may transmit the anonymized health data to the second area cloud platform 120. In one embodiment, the cloud platform 120 may include an anonymized data storage device 121, an analysis generator 123, and a permanent storage device 125. In one embodiment, the anonymized data storage device 121 may include various data separated from patient privacy information (e.g., PHI). The anonymized data storage device 121 may receive and / or store any data files from areas other than the second area. For example, the anonymized data storage device 121 may include a storage device for anonymous DICOM data sets, post-analysis data reports, various auxiliary data, and the like. In one embodiment, the data stored in the anonymized data storage device 121 may be analyzed by the analysis generator 123. The analysis generator may perform any form of data analysis based on the data of the anonymized data storage device 121. Exemplary forms of data analysis may include non-invasive determination and / or blood flow simulation of patient-specific blood flow characteristics. For example, various systems and methods for such blood flow analysis are disclosed in U.S. Patent No. 8,315,812, filed on January 25, 2011, entitled “Method and System for Patient-Specific Modeling of Blood Flow,” which is incorporated herein by reference in its entirety.

[0050] In one embodiment, the permanent storage device 125 may include past analyzed data, health data received in the past, group data, etc. The analysis generator 123 may process the data of the anonymized data storage device 121 and the data of the permanent storage device 125. For example, a machine learning algorithm trained on the data of the permanent storage device 125 may be used to calculate features or metrics of the data from the anonymized data storage device 121. In one embodiment, the permanent storage device 125 may include historical or group data from past data storage or analysis, while the anonymized data storage device 121 may include data newly transferred from the first area to the second area for analysis. For example, the anonymized data storage device 121 may include data that has not yet been analyzed, while the permanent storage device 125 may include data that has been analyzed at least once before by the analysis generator 123.

[0051] In one embodiment, the analysis generator 123 may output a report of the analyzed data, for example, in the form of a PDF file. In one embodiment, the report may include interactive elements. For example, the report may include an interactive three-dimensional model, in which the user can zoom in / out various parts or segments of the model, prompt simulations, request data comparisons, etc. The simulation may include simulations of the patient's blood flow, blood pressure, treatment, physiological state, etc. The data comparison may include a color interface, longitudinal data reports, charts, graphs, infographics, animations, etc. For example, various exemplary interactive displays and reports are described in U.S. Patent No. 8,315,812, entitled "Method and System for Patient-Specific Modeling of Blood Flow" filed on January 25, 2011, which is incorporated herein by reference in its entirety. Various other displays and reports are described in, for example, U.S. Patent Application No. 14 / 480,870, entitled "Systems and Methods for Reporting Blood Flow Characteristics" filed on September 9, 2014, which is incorporated herein by reference in its entirety.

[0052] In one embodiment, the analyzed data may be transmitted from the second region (e.g., cloud platform 120) to the first region (e.g., cloud platform 113). Alternatively or additionally, the analyzed data may be retrieved by the first region from the second region. In one embodiment, the analyzed data may be associated with patient privacy information when re-entering the first region. For example, the result storage device 119 of the first region cloud platform 113 may receive the analyzed data (e.g., where the analyzed data includes a PDF file). The identifier associated with each PDF may be matched with the stored patient privacy information. For the case where the patient privacy information includes PHI, the hash or identifier associated with each PDF may be matched with the PHI stored, for example, in the PHI storage device 117. In this way, once the analyzed data is in the first region cloud platform 113, it may be associated with its PHI. Once the analyzed data is associated with the PHI, the patient, consumer, and / or medical professional may access the analyzed data. For example, a medical professional may retrieve the analyzed data of a particular patient by establishing an interface connection with the result storage device 119 via the consumer device 130.

[0053] In one scenario, the first regional cloud platform 113 or its processor 115 may receive a request from a consumer device 130 to access analyzed data for a particular patient. The cloud platform 113 may determine whether any report of the analyzed data of the result storage device 119 matches any identifier of the PHI database 117. If a match between the report and the identifier is detected, the patient's report may be available. The cloud platform 113 may then prompt or allow the consumer device 130 to access the report of the result storage device 119 corresponding to the PHI of the particular patient. If no report of the result storage device 119 corresponds to the PHI of the particular patient, the report may not be ready yet, and the health data may still be analyzed in the second region. In one embodiment, when the patient's report is available, the processor 115 may cause a prompt or notification to be sent or displayed to the consumer device 130.

[0054] Thus, in one embodiment, if a third region (different from the first region and the second region) attempts to access the analyzed data, the analyzed data is available to the third region, although there is no associated patient privacy information. For example, an embodiment may include three regions, such as Europe, the United States (US), and Japan. Europe can be used as a first region for collecting patient health data (including image data). All patient privacy information associated with the patient health data can be retained in Europe, while the collected image data is transmitted to the United States for analysis. The analysis of the image data can be generated in the United States and transmitted back to Europe. A doctor can log in to the portal in Europe and access the analyzed data of his / her patient. However, if a doctor (or a cooperating medical professional) in Japan accesses the portal, the portal may display that the analyzed data is available without revealing the patient privacy information associated with the data. In one example, the analyzed data can be accessed or viewed in Japan, but there is no patient identity information associated with the analyzed data. Since the patient privacy information may not be transmitted beyond the borders of the first region (e.g., Europe in this example), the patient privacy information may be limited to data access in Europe.

[0055] Similarly, a doctor may collect data at a first hospital (inside or outside the United States). The data may be transmitted to a second region (e.g., the United States) for analysis, and the analyzed data may be transmitted back to the first hospital. While at another hospital (e.g., a third region), the doctor may see that the analyzed data is available (and may even be able to interact with the analyzed data), without being able to view the patient identity / patient privacy information associated with the analyzed data.

[0056] Figure 2 201 is a flowchart of an exemplary method 200 for transmitting health data via cloud platforms in different regions according to an exemplary embodiment of the present disclosure. In one embodiment of method 200, health data may be collected in one region. For example, a cloud platform in a first region may receive the collected health data (step 201). In one embodiment, step 201 may include receiving DICOM data or a DICOM file, or accessing a DICOM database / library from a first region. The health data collected in this way may be associated with patient privacy information. For exemplary method 200, patient privacy information may include PHI.

[0057] In one embodiment, step 203 may include anonymizing the collected health data. For example, the cloud platform of the first region may remove the PHI from the received health data. In one embodiment, step 203 may also include storing the PHI removed from the received health data set in, for example, a PHI database of the first region. In one embodiment, the PHI database may be included in a cloud platform, a local network, or any system in the first region. For example, step 203 may include identifying PHI fields based on regulatory requirements of the first region. For example, in a DICOM file, step 203 may include detecting a patient name field (e.g., tag (0010, 0010)), identifying a patient name, storing the patient name (e.g., in a database), and deleting the name from DICOM with a generic (e.g., non-specified) string.

[0058] In one embodiment, step 205 may include creating one or more hashes of the PHI. Adding the hash may include calculating and / or storing the hash (e.g., in a permanent storage device). The hash may be irreversible and therefore created to not include the PHI. Thus, while the PHI may remain in the first area, the hash may be transmitted to the second area along with the data (now separated from the PHI). In other words, method 200 may need to ensure that PHI associated with health data may remain in the first area, while the health data (not including the PHI) and the hash may be transmitted to the second area. Therefore, step 207 may include transmitting anonymized health data to the second area. For example, the transmitted health data may be associated with one or more hashes or other identifiers, while the PHI is retained only in the first area (e.g., in a PHI storage device).

[0059] In one embodiment, step 209 may include receiving anonymized health data in a second area. For example, an anonymized database in the second area may receive the anonymized health data from the first area, wherein the anonymized health data is separated from the PHI. The anonymized database in the second area may store the anonymized health data based on an identifier and / or hash, because the data transmitted to the second area is no longer associated with the PHI. The anonymized database may store data in several forms, including DICOM storage, PDF storage (e.g., a PDF report including analyzed data), or various auxiliary elements. In one embodiment, part or all of the received data may also be stored in a permanent storage device in the second area, for example for record keeping or for future analysis (step 211). The permanent storage device may include a database.

[0060] In one embodiment, health data collected in a first area can be analyzed in a second area. For example, steps 213 and 215 can include analyzing anonymized health data received from the first area and generating a report based on the analyzed data. In one embodiment, the report can include an anonymized PDF file that includes the analyzed data. For example, if the data received from the first area includes an original image file, the anonymized PDF file generated in the second area can include a PDF reporting blood flow characteristics determined based on the analysis of the original image file. In this case, the analysis can include generating an anatomical model based on the received image file, calculating blood flow through the anatomical model, and deriving various metrics, displays, or predictions based on the calculated blood flow. In one embodiment, steps 213 and 215 can occur after step 211. For example, in some cases, a permanent storage device can include analyzed data and / or original patient health data.

[0061] In one embodiment, step 217 may include transmitting the analyzed data to the first region, and step 219 may include matching the analyzed data to the patient. For example, step 219 may include matching an identifier and / or hash associated with the analyzed data to an identifier and / or hash associated with PHI stored in a PHI database at the first region.

[0062] Step 221 may include providing the analyzed data to a consumer, such as a patient, a healthcare provider, a healthcare professional, etc. In one embodiment, step 221 may include notifying a party that the report is complete, such as via a notification on a web portal. For example, step 221 may include generating an update on a portal interface and / or sending a notification to a user or user account.

[0063] FIG. 3A to FIG. 3D General embodiments of systems and methods, for example in the areas of data collection and privacy protection, are described. FIG. 4A to FIG. 4C Described are general embodiments of systems and methods, for example in the area of ​​data analysis. It should be understood that for the sake of clarity, FIG. 3A to FIG. 3D The exemplary embodiment combines the data collection / privacy protection area with FIG. 4A to FIG. 4C In fact, any geographic region can transmit its health data to other regions for analysis and / or analyze health data from other regions. In other words, any region can serve as a data collection / privacy protection region for some transactions and as a data analysis region for other transactions.

[0064] Figure 3A A system of an exemplary cloud platform 113 is depicted at a first region where raw data may be generated. Figure 3BA schematic diagram depicting exemplary functionality of a patient privacy information processor (similar to processor 115) of the system. Figure 3C An exemplary process for removing patient privacy information from the health data prior to transmitting the health data to a second region is included. Figure 3D An exemplary process of associating patient privacy information to analyzed data received from a second region is described. FIG. 3A to FIG. 3D Patient privacy information is described as PHI, but it should be understood that patient privacy information may include any protected personal information.

[0065] Figure 3A A block diagram of an exemplary data privacy system 300 is depicted according to an exemplary embodiment, which is used to transmit health data across borders without compromising patient privacy. All components of the data privacy system 300 may exist in one region (e.g., Europe or Japan). The data privacy system 300 may be viewed as a data offshore system, in which data collected in a first region is prepared for transmission to a second region (e.g., an offshore region). The data may be analyzed in the second region. In addition, the data privacy system 300 may process inbound analyzed data. For example, the data privacy system 300 may receive analyzed data from a second region, for example, in the form of a completed report. The analyzed data may be anonymized. The data privacy system 300 may associate the analyzed data with patient privacy information so that the patient and / or a medical professional on behalf of the patient may access the report. In one embodiment, the data privacy system 300 may include various components, including a data collection interface 301, a PHI platform 303, a PHI storage device 307, a report storage device 309, a portal 311, and a network 313. Although the exemplary system 300 describes patient private information as PHI (eg, via the PHI platform 303 and the PHI storage device 307 ), it should be understood that patient private information may include any information used to protect patient privacy.

[0066] In one embodiment, the data collection interface 301 may receive data collected and / or created in the first region. The PHI platform 303 may perform all steps of preparing the data to be offshored and identifying associations between patient data and analyzed data. Figure 3B An exemplary PHI platform 303 is described in more detail. In one embodiment, the PHI storage device 307 can store PHI separate from health data. In one embodiment, the analyzed data returned from the second region can be associated with the associated PHI stored in the PHI database.

[0067] In one embodiment, the report storage device 309 can receive and store the analyzed data, for example in the form of a PDF report. The report storage device 309 can be similar to Figure 1 319. In one embodiment, a user may access reports stored in the report storage device 309 via a portal 311. In one embodiment, the portal 311 may generate one or more user interfaces for the patient / medical professional to view the reports of the report storage device 309. The user interface may include one or more interactive displays, including color visual indicators, graphs, charts, tables, comparisons with previous patient reports or population data, treatment recommendations, etc. In one embodiment, the portal 311 may generate or receive a notification when a patient's report is available. For example, the portal 311 may display a visual indicator on the user interface to show that the patient report has been received in the first area. The portal 311 may also prompt a notification (e.g., a message received at a user device of the patient or medical professional) when the report is available for access. Alternatively or additionally, the portal 311 may display a visual indicator corresponding to the progress of the analysis or tracking the analyzed data. For example, the portal 311 may display a user interface indicating "the report will be available in 3 days" or "please check back at 3 pm on Friday."

[0068] In one embodiment, various components of the data privacy system 300 (e.g., the PHI platform 303, the report storage device 309, and / or the portal 311) can further analyze the patient's report. For example, the data privacy system 300 can determine one or more recommended treatment plans, treatment tasks, reports, follow-up tests / analyses, etc., and / or provide recommended treatment plans, treatment tasks, reports, follow-up tests / analyses, etc. via the portal 311. Alternatively, all data / report analysis can be performed in a second area, and the data privacy system 300 can specifically identify which patient is associated with a set of analyzed data and display the analyzed data to the appropriate parties associated with the patient.

[0069] The network 313 may include the Internet, a content distribution network, or any other wired, wireless, and / or telephone or local network. The data collection interface 301, the PHI platform 303, the PHI storage device 307, the report storage device 309, the portal 311, and various user and / or administrator devices may communicate with each other via the network 313.

[0070] In one embodiment, a user may access the data collection interface 301 and / or the portal 311 via a network 313 and one or more devices. The device may include any type of electronic device configured to collect, send and / or receive data such as websites and multimedia content via the network 313. The device may include a medical device, such as a medical imaging device, a medical monitor, etc. The device may also include one or more mobile devices, smart phones, personal digital assistants ("PDAs"), tablet computers or any other type of touch screen-enabled devices, personal computers, laptops, and / or servers configured to communicate with the network 313. Each device may have a web browser and / or mobile browser installed to receive and display electronic content received from one or more web servers affiliated with the data privacy system 100. These devices may include client devices that may have an operating system configured to execute a web or mobile browser and any type of application (e.g., a mobile application). In one embodiment, various devices may be configured with a network adapter to transmit data or analysis reports via the network 313. Alternatively or additionally, various devices may be configured to transmit data or receive analyzed data via a local connection.

[0071] Figure 3B 3 is a block diagram 320 of a PHI platform 303 for preparing data for transmission to a second region and receiving analyzed data from an external region according to an exemplary embodiment of the present disclosure. Figure 3B As shown, the exemplary PHI platform 303 may include control logic 321. The control logic 321 may direct the interaction between and among the functions of the various modules and processors that may operate as part of the PHI platform 303. The PHI platform 303 may manage outgoing data for offshore data analysis, for example, by removing PHI data from a data set (e.g., via an outgoing data processor 331). When the offshore analyzed data re-enters a region, the PHI platform 303 may further manage the data, for example, by associating the data to the appropriate PHI (e.g., via an information report processor 341). The outgoing data processor 331 and the information report processor 341 will be discussed in detail below.

[0072] In one embodiment, the control logic 321 and the outgoing data processor 331 can prepare the collected data for transmission to a second area. For example, the PHI platform 303 can be in a first area, and the PHI platform 303 can process data that leaves the first area to enter the second area. There may be legal restrictions when transmitting information related to the identity of a patient. Various legal systems or systems may adhere to different restrictions. Therefore, in order to transmit PHI-related health data to another area, the health data can be separated or disassociated from the patient and the corresponding PHI.

[0073] In one embodiment, such data can be processed by an outgoing data processor 331, which includes exemplary modules such as a region module 333, an anonymization module 335, and a tracking module 337. In one instance, the outgoing data processor 331 can remove protected health information or patient privacy information from the health data collected in the first region. Removing the protected health information or patient privacy data can remove the association between the patient identity and the data collected from the patient.

[0074] In one embodiment, the region module 333 and control logic 321 may identify which region (eg, the second region) the data is being transferred to. The region module 333 and control logic 321 may determine any privacy regulations involved in transferring data from the first region to the second region.

[0075] In one embodiment, the anonymization module 335 and the control logic 321 can perform the steps required to meet privacy regulations. For example, the anonymization module 335 and the control logic 321 can remove and / or manipulate the PHI elements of the received data set to allow the transmission of the data set.

[0076] In one embodiment, the tracking module 337 and the control logic 321 can track the data or transfer the data to a designated or previously identified second area. For example, the tracking module 337 and the control logic 321 can provide a way to track the data after it is separated from the PHI. For example, the tracking module 337 and the control logic 321 can create a hash of the PHI element. Such a hash can provide the ability to longitudinally track data at different time points. For example, the PHI platform 303 can receive a first scan (e.g., from the data collection interface 301. The first scan may be associated with a patient "John Doe". The anonymization module 335, the tracking module 337 and / or the control logic 321 can store hashes of "John" and "Doe". The exemplary hash may not have PHI and / or may be irreversible. In one embodiment, the data can be transmitted to the second area along with the hash to track or identify the data set, while the PHI data remains in the first area. The processor of the second area can then use the hash to track the data set or determine that the various data sets are related to each other.

[0077] Various hash functions can be used, including, for example, SHA1, MD5, encryption algorithms, etc. Information fields that can be hashed include: patient's first name, patient's last name, patient ID, patient's birth data, referring doctor's first name, referring doctor's last name, data creation date, data creation time, etc.

[0078] The PHI platform 303 can further manage the offshore analyzed data when the analyzed data re-enters a region. For example, the PHI platform 303 can associate the analyzed data to the corresponding PHI. In one embodiment, the incoming report processor 341 can receive the completed data analysis (e.g., in the form of a report). In one embodiment, the report can be created based on metadata and / or models (e.g., three-dimensional anatomical models) associated with the PHI corresponding to the analyzed data. The incoming report processor 341 can identify the patient associated with the report and pair the report with the patient or PHI / identity information. In one embodiment, the incoming report processor 341 can include exemplary modules, such as an analysis type module 343, an identification module 345, and a report visualization module 347.

[0079] In one embodiment, the analysis type module 343 and the control logic 321 may receive data, for example, from the second region. In one embodiment, the analysis type module 343 and the control logic 321 may classify or organize data received, for example, from the report storage device 309. For example, the received data may include data that has been subjected to some form of analysis. For example, the received data may arrive in the form of a portable document format (PDF) file that includes a report. Classifying or organizing the received data may include identifying the received data based on the time the data was received, the region from which the data was received, the medium on which the data was received, etc.

[0080] In one embodiment, the identification module 345 and the control logic 321 can associate PHI to the received data or report. For example, the identification module 345 and the control logic 321 can access the PHI storage device 307 and match the received data (e.g., from the report storage device 309) with the corresponding PHI from the PHI database 107.

[0081] In one embodiment, the control logic 321, analysis type module 343, and / or identification module 345 may receive multiple received analyses (e.g., multiple reports from the report storage device 309). The multiple reports may be processed by the analysis type module 343, the identification module 345, and / or the control logic 321 to determine associations between reports or previously stored reports (e.g., reports from an earlier time). The temporal association of the analyzed data may be performed using hashes. For example, the incoming report processor 341 may receive a hash associated with the analyzed data and establish a longitudinal view of the patient's physical condition based on the received hash.

[0082] In one embodiment, the report visualization module 347 and control logic 321 can manage the display or availability of the analyzed data to parties who wish to view the analyzed data. In one embodiment, the report visualization module 347 can include direct access to PDF reports, models associated with or included in reports, etc. The analyzed data can be displayed along with the covered PHI information corresponding to the analyzed data. Various forms of the analyzed data can be obtained via one or more platforms, for example, the platform is a web portal, a mobile device, a virtual reality display, a television screen, a laptop computer, a desktop computer, etc.

[0083] Figure 3C is a flow chart of an exemplary method 350 of removing patient privacy information from health data in accordance with an exemplary embodiment. Figure 3C The method 350 may be performed by the outgoing data processor 331 and the control logic 321 based on information, images, and data received from the data collection interface 301 via the electronic network 313. The method 350 may be performed using a processor (e.g., a laptop, a desktop computer, a cloud computing architecture, a graphics processing unit (GPU), a digital signal processor (DSP), a mobile phone, a tablet computer, etc.).

[0084] In one embodiment, step 351 may include receiving health data associated with PHI (eg, in a first area). The health data may be received, for example, via the data collection interface 301 from a medical professional, an imaging device, and / or a third-party medical service provider.

[0085] In one embodiment, step 353 may include identifying a selected region in which data analysis will be performed. For example, health data may be received in a first region (e.g., the United States). Step 353 may include determining that the received health data is to be transmitted to Europe for data analysis. Step 353 may also include receiving various requests to perform analysis on the received health data and determining to which region(s) the health data may be transmitted.

[0086] In one embodiment, step 355 may include identifying information to be removed in order to transmit health data (from the first area) to the selected area. For example, there are currently restrictions on transmitting PHI out of the United States. In one embodiment, step 357 may include removing patient privacy information from the received health data. For example, if the health data is to be transmitted out of the United States, step 355 may include identifying PHI to be removed from the collected health data, and removing the identified PHI from the collected health data. For example, step 355 may include identifying a PHI field that is considered to be patient privacy information for all areas interacting with the first area. As another option, step 355 may include removing all PHI fields that are not used for case processing. Yet another embodiment may include removing a PHI field specifically for the first area, or depending on the relationship between the first area and the second area. An illustrative example may include a first area as a hospital clinic and a second area as a hospital laboratory. For this case, to transmit health data between the first area and the second area, it may not be necessary to remove the PHI field, but to transmit health data out of the hospital, it may be necessary to remove the PHI field.

[0087] In one embodiment, step 359 may include transmitting the anonymized health data to a selected region, wherein the transmitted health data does not include patient privacy information (e.g., PHI). In one embodiment, step 359 may also include marking the transmitted data with an identifier that is not associated with patient privacy information. The identifier may be random, not data-specific, and / or associated with a region, time / date, hospital, etc. In one embodiment, the identifier may be used to track health data without patient privacy information.

[0088] In addition, step 359 may include hashing the patient privacy information. For example, the data may be transmitted to the selected area together with the hash of the patient privacy information, while the patient privacy information is only retained in the first area.

[0089] Figure 3CThe steps may be performed in various orders. Although the exemplary embodiment includes identifying a selected area (step 353), identifying the information to be removed (step 355), and removing the identified information (step 357), there are many alternatives. For example, an alternative embodiment may include receiving patient health data (step 351), removing all patient privacy information associated with the patient health data, and then transmitting the patient health data to any area. For example, method 300 may include identifying all patient privacy information fields to be deleted for a first area in order to transmit health data to any area. In another example, the first area may automatically remove a subset of PHI that is sufficient to allow the data to be sent out of the first area. For these scenarios, the removal of PHI data may not be affected by the area where data analysis will be performed. Method 300 may include identifying a configuration of patient privacy information fields to be deleted for each area. The configuration may be stored in any storage device, such as a database.

[0090] Figure 3D is a flow chart of an exemplary method 360 of associating analyzed data to stored private patient information according to an exemplary embodiment. Figure 3D The method can be performed by the incoming report processor 341 and the control logic 321 based on the information, images and data received from the second area. The method 360 can be performed using a processor (e.g., a laptop, a desktop computer, a cloud computing architecture, a graphics processing unit (GPU), a digital signal processor (DSP), a mobile phone, a tablet computer, etc.).

[0091] In one embodiment, step 361 may include receiving the analyzed data, for example in the form of a PDF report. The analyzed data may be anonymized and not associated with any patient privacy information (e.g., PHI). In one embodiment, step 361 may include receiving the analyzed data from the selected / second zone at the first zone.

[0092] In one embodiment, step 363 may include determining or receiving an identifier associated with the analyzed data. For example, the identifier may be an identifier used to tag a patient data set (e.g., in method 350). Alternatively, the identifier may be an identifier associated with an identifier created in the first region. The identifier may include a unique global ID that may be shared across regions. For example, the identifier may include a date (MM / DD / YY) sequence and a unique combination of numbers and / or letters.

[0093] In one embodiment, step 365 may include identifying stored patient privacy information associated with the determined / received identifier. Step 367 may include associating the analyzed data with the identified patient privacy information. In one embodiment, steps 365 and 367 may include generating an artifact that the end user can use with the corresponding PHI information. For example, step 367 may include regenerating a report of the analyzed data that includes the PHI information retained in the area. For example, the PHI information may be retrieved from an API of the first area, and a reporting tool (e.g., a report visualization module 347) may insert the PHI information in the generated report. This type of mechanism can be extended to any file or medium that the end user uses to interact with the analyzed data, including PDFs, graphical user interfaces, holograms, etc. encapsulated in DICOM files.

[0094] In one embodiment, step 369 generates one or more displays based on the analyzed data and the identified patient privacy information. Exemplary displays for end users may include PDF reports accessible through the portal, two-dimensional and / or three-dimensional models with PHI information available through the portal, reports pushed through the hospital infrastructure for visualization on the hospital system, etc.

[0095] FIG. 4A to FIG. 4C Exemplary systems and methods of data analysis areas are depicted. Figure 4A A system of an exemplary cloud platform 120 is depicted in a second area where anonymized health data may be analyzed. Figure 4B A schematic diagram depicting exemplary functionality of a data analysis platform (similar to analysis generator 123) of the system. Figure 4C An exemplary process for analyzing anonymized health data is depicted.

[0096] Figure 4A A block diagram of an exemplary data analysis system 400 for analyzing anonymized data is depicted in accordance with an exemplary embodiment. The data analysis system 400 may include various components, including an anonymized data storage device 401, an analysis platform 403, a persistent storage device 405, and a network 407. In one embodiment, the anonymized data storage device 401 may receive and store data received from an area other than the area of ​​the data analysis system 400. For example, the anonymized data storage device 401 may store health data separated from any patient or identity information. In one embodiment, the anonymized data storage device 401 may receive data associated with an identifier and / or hash that is not associated with patient privacy information. In another embodiment, the anonymized data storage device 401 may store or tag the received data with an identifier and / or hash.

[0097] In one embodiment, the analysis platform 403 can perform the same type of analysis on any data stored in the anonymized data storage device 401. In another embodiment, the analysis platform 403 performs different types of data analysis based on one or more factors, such as the type of data stored in the anonymized data storage device 401, the sender (e.g., the processor 115), the region from which the data is received, the subscription service, the hospital / research institution / medical service provider / cloud service associated with the data, etc.

[0098] For example, performing data analysis based on data type may include scenarios in which the analysis platform 403 may detect a certain type of health data file or distinguish between various types of data files. For example, if the anonymized data storage device 401 includes a DICOM file, the analysis platform 403 may generate an anatomical model based on the DICOM file and perform a predetermined series of analyses (e.g., blood flow analysis) using the generated anatomical model. Alternatively, if the anonymized data storage device 401 includes a blood pressure file, the analysis platform 403 may perform a blood pressure analysis separate from a blood flow analysis associated with the DICOM file. In some embodiments, the analyses may overlap, while in other embodiments, the analysis platform 403 may be configured to perform different sets of analyses based on the type of file received or stored by the anonymized data storage device 401.

[0099] In embodiments where the analysis may be related to the region, subscription, or facility from which the anonymized data is received, the analysis platform 403 may determine a data analysis request associated with the sender of the anonymized data. For example, a hospital may subscribe to a service that provides blood flow analysis to the hospital's patients. Upon detecting that the anonymized data is related to this type of subscription service, the analysis platform 403 may prompt to perform a blood flow analysis on the anonymized data. Similarly, the analysis platform 403 may determine that all data from a particular region "Region X" will be subject to a particular type of analysis "Analysis A". Therefore, the analysis platform 403 may perform Analysis A (or prompt to perform Analysis A) on any data received from Region X.

[0100] Alternatively or additionally, the analysis platform 403 can be configured to provide access to various types of data analysis. The data transmitted from the first area can include commands or instructions about the type of data analysis requested to be performed by the analysis platform 403 in the second area. For example, a type of blood flow analysis may not be available in the first area, but is available in the second area. The first area can transmit anonymized health data to the second area along with a request to perform a specific type of blood flow analysis. The analysis platform 403 can receive a request for this type of blood flow analysis, perform the analysis, and prompt the analyzed data to be transmitted to the first area, where the analyzed data can be associated with the corresponding patient.

[0101] In one embodiment, the permanent storage device 405 may include a repository of cases and data that can improve algorithms for data analysis, such as machine learning or deep learning. The more cases processed and / or available in the permanent storage device 405, the more accurate the data analysis may be. The permanent storage device 405 can also be used for dashboard processing of stored / known / past analyzed data and / or analysis results. The dashboard processing can include various visualizations, metrics, and options for organizing data or formulating analysis. For example, the dashboard processing can classify data (e.g., analysis type, region, etc.) and provide a selection of data sets for analysis. Visualizations can include bar charts, graphic icons, dials, emoticons, symbols, charts, curve graphs, etc. The analysis results can include, for example, analysis results that can improve data analysis based on region, demographics, time, etc. In one embodiment, the permanent storage device 405 can include permanent raw data and / or analyzed data, as well as empirical data, population data, experimental data, etc. The permanent storage device 405 can also store hashes.

[0102] The analysis platform 403 may access the persistent storage device 405 to enhance its analysis. For example, the analysis platform 403 may employ a machine learning mechanism trained on the data of the persistent storage device 405. The analysis platform 403 may analyze the data from the anonymized data storage device 401 based on the data of the persistent storage device 405. In one embodiment, the analyzed data may be stored by the persistent storage device 405 for future analysis.

[0103] In another embodiment, the data analysis system 400 may allow the stored hash to be compared with the hash associated with the received health data. For example, the data analysis system 400 may store a hash of a first data set received from a first region. At a later point in time, the data analysis system 400 may receive a different data set from the first region, where the second data set is associated with a second hash set. The data analysis system 400 may compare the second hash set with the stored hash (e.g., stored by the anonymized data storage device 401 and / or the permanent storage device 405) and determine whether the first data set and the second data set may be related (e.g., associated with the same patient). If so, the data analysis system 400 may analyze the second data set while taking into account the first data set. In this way, the data analysis system 400 may allow for longitudinal studies of one or more patients over time.

[0104] Network 407 may include the Internet, a content distribution network, or any other wired, wireless, and / or telephone or local network. Anonymized data storage device 401 , analysis platform 403 , persistent storage device 405 , and various user and / or administrator devices may communicate with each other via network 407 .

[0105] Figure 4B 4 is a block diagram of an exemplary model 420 of an analysis platform 403 for analyzing health data received from different regions according to an exemplary embodiment of the present disclosure. Figure 4B As shown, the exemplary analysis platform 403 may include control logic 421. The control logic 421 may direct the functionality of and interactions between various modules and processors that may operate as part of the analysis platform 403. Other modules and processors may include a selection module 423, a hashing module 425, an execution module 427, and an analysis module 429.

[0106] In one embodiment, the control logic 421 and the selection module 423 may receive health data from a first region and determine which analysis to perform on the health data. For example, the analysis platform 403 may include access to multiple different forms of analysis. The selection module 423 and the control logic 421 may determine the appropriate analysis to perform on a given health data set based on the region from which the health data is received, the hospital from which the data is received, the subscription service associated with the health data, etc.

[0107] In one embodiment, the control logic 421 and the hash module 425 can determine the hash associated with the received health data and determine whether the hash is associated with any stored hash. For example, the control logic 421 and the hash module 425 can compare the hash associated with the newly received data set and determine whether any data of the anonymization database 401 and / or the permanent storage device 405 corresponds to the hash of the newly received data set. The correspondence between the newly received hash and the stored hash can indicate that the received health data is associated with the same patient. Alternatively or additionally, the correspondence between the hashes can also indicate the relationship between data sets other than data sets associated with the same patient. For example, the correspondence between the hashes can indicate that various data files / collections are generated or sent by the same hospital or doctor. The correspondence between the hashes can also indicate patients within a certain age range or demographic range. In short, the control logic 421 and the hash module 425 can determine the relationship between data sets.

[0108] In another embodiment, the control logic 421 and hash module 425 can determine whether other data sets can be used to analyze the received health data set. For example, the control logic 421 and hash module 425 can determine that several data sets can be associated with the same patient (although the identity of the patient is not known). The control logic 421 and hash module 425 can then prompt data analysis based on a portion of the data associated with the same patient as a supplement to the analysis of the received data set. The control logic 421 and hash module 425 can also determine that several data sets correspond to patients in a particular age range, even though no data corresponds to a particular patient associated with the received data set. In one embodiment, when analyzing the received data set, the control logic 421 and hash module 425 can prompt data analysis that considers other patient data from patients within a given age range.

[0109] In one embodiment, the control logic 421 and the execution module 427 can perform analysis on the received health data. For example, the data analysis can be based on the selected analysis (e.g., determined by the control logic 421 / selection module 423) and data related to the received data (e.g., determined by the control logic 421 / hash module 425). In one embodiment, the control logic 421 and the execution module 427 can perform analysis of the health data without using stored data. Alternatively, the control logic 421 and the execution module 427 can access the permanent storage device 405 to perform and / or supplement the analysis of the received health data. In one embodiment, the control logic 421 and the execution module 427 can further generate a report of the completed analysis.

[0110] In one embodiment, the control logic 421 and the analysis module 429 may update and / or improve the analysis techniques based on the analyzed data. For example, the control logic 421 and the analysis module 429 may update the analysis techniques for future data analysis.

[0111] Figure 4C 4 is a flow chart of an exemplary method 430 for analyzing anonymized data according to an exemplary embodiment. The method 430 can be performed using a processor (e.g., a laptop, a desktop computer, a cloud computing architecture, a graphics processing unit (GPU), a digital signal processor (DSP), a mobile phone, a tablet computer, etc.) communicating on the electronic network 417, for example, on a cloud platform in the second region.

[0112] In one embodiment, step 431 may include, for example, receiving anonymized data from different regions. Step 433 may include determining an identifier associated with the anonymized data. In one embodiment, step 435 may include identifying and / or retrieving stored, group, empirical, historical and / or experimental data associated with the determined identifier. Step 437 may include performing analysis on the anonymized data based on the identified / retrieved data associated with the identifier. In one embodiment, step 439 may include generating a report of the analyzed data, for example in the form of a PDF file. Step 439 may also include transmitting the analyzed data back to the source region (e.g., the first region) from which the anonymized data was received. The report of the analyzed data may be anonymous when transmitted back to the first region.

[0113] The present disclosure includes systems and methods for separating patient privacy data from health data before the health data is transmitted from a first region to a second region. The present disclosure also includes systems and methods for associating analyzed data to a patient when the analyzed data is returned from the second region to the first region. Thus, data analysis can be provided across regions while avoiding the transmission of privacy data from one region to another.

[0114] Any of the described embodiments may be modified, for example, to include variations in the data that may be maintained within a region. The disclosed systems and methods may be modified to model and evaluate any range of variations in cycles.

[0115] The program aspects of the present technology can be considered as "products" or "articles of manufacture", usually in the form of executable code and / or associated data, which are carried or implemented on a machine-readable medium. "Storage device" type media include any or all tangible memories of computers, processors, etc. or their associated modules, such as various semiconductor memories, tape drives, disk drives, etc., which can provide non-transitory storage for software programming at any time. All or part of the software can sometimes be transmitted through the Internet or various other telecommunications networks. Such transmission can, for example, enable the software to be loaded from one computer or processor to another computer or processor, such as from a management server or host computer of a mobile communication network to a computer platform of a server and / or from a server to a mobile device. Therefore, another medium that can carry software elements includes optical waves, radio waves, and electromagnetic waves, which are used across physical interfaces between local devices, such as through wired and optical landline networks and various air links. Physical elements that carry such waves, such as wired or wireless links, optical links, etc., can also be considered as media that carry software. As used herein, unless restricted to non-transitory, tangible "storage" media, terms such as computer or machine "readable media" refer to any medium that participates in providing instructions to a processor for execution.

[0116] Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and examples be considered exemplary only, with the true scope and spirit of the invention being indicated by the following claims.

Claims

1. A computer-implemented method of processing electronic images to preserve privacy while transmitting data across regions, the method comprising: receiving, by a processor physically located in the first geographic region, patient-specific data including first patient private information that complies with a privacy standard specific to the first geographic region; removing first patient privacy information from the patient-specific data based on privacy standards specific to the first geographic region to generate a first set of anonymous health data using a processor physically located in the first geographic region; storing first patient private information in the first geographic region using a processor physically located in the first geographic region, the first patient private information being stored using a storage entity separate from permanent storage at a second geographic region; transmitting, using a processor physically located in a first geographic region, the first set of anonymous health data to a remote data analysis server physically located in a second geographic region for use in performing patient-specific calculations based on the first set of anonymous health data, the second geographic region being different from and external to the first geographic region; generating, using a remote data analysis server physically located in a second geographic region, an anatomical model of the patient based on the first set of anonymous health data and performing patient-specific calculations with the generated anatomical model; determining, using a remote data analysis server physically located in a second geographic region, a patient-specific blood flow calculation in the patient based on the generated anatomical model and a mass or volume of myocardial tissue of the patient; receiving, by a processor physically located in the first geographic region, from a remote data analysis server physically located in a second geographic region, analyzed anonymous health data including results of a patient-specific blood flow calculation calculated at an earlier date and stored in persistent storage; as well as A patient associated with the generated anatomical model is identified by determining, using a processor physically located in a first geographic area, first patient privacy information associated with the analyzed anonymous health data based on first patient privacy information stored within the first geographic area and patient-specific blood flow calculations stored in persistent storage, wherein the first patient privacy information is inaccessible within a second geographic area. 2 . The computer-implemented method of claim 1 , wherein the first geographic region and the second geographic region are governed by different patient privacy regulations.

3. The computer-implemented method of claim 1 , further comprising: An identifier associated with a first set of anonymous health data is generated using a processor physically located in a first geographic area, wherein first patient privacy information is absent from the identifier.

4. The computer-implemented method of claim 1 , further comprising: The first set of anonymous health data is transmitted to a second geographic region along with an identifier associated with the first set of anonymous health data using a processor physically located in the first geographic region.

5. The computer-implemented method of claim 1 , further comprising: An irreversible hash of the first patient private information is generated using a processor physically located in the first geographic area.

6. The computer-implemented method of claim 1 , further comprising: Prompting improving modeling techniques available at the second geographic region based on the analyzed anonymous health data.

7. The computer-implemented method of claim 1 , further comprising: determining, using a processor physically located in the first geographic region, an identifier associated with analyzed anonymous health data from the second geographic region; determining, using a processor physically located in the first geographic region, an association between the identifier and first patient private information stored in the first geographic region; as well as First patient private information corresponding to the analyzed anonymous health data is determined using a processor physically located in the first geographic region based on an association between the identifier and first patient private information stored in the first geographic region.

8. The computer-implemented method of claim 1 , further comprising: determining, using a processor physically located in the first geographic region, a hash associated with the analyzed anonymous health data or the first set of anonymous health data; as well as Previously analyzed data associated with the analyzed anonymous health data or the first set of anonymous health data is determined based on comparing the hash to one or more stored hashes using a processor physically located in the second geographic area.

9. A system for processing electronic images to protect privacy while transmitting data across regions, the system comprising: at least one data storage device physically located in the first geographic area and storing instructions for providing cross-border health data transfer while protecting the privacy of the first patient; as well as At least one processor physically located in a first geographic region and configured to execute instructions to perform operations including: receiving patient-specific data including first patient private information at a data storage device in a first geographic region that complies with privacy standards specific to the first geographic region; removing first patient private information from the patient-specific data to generate a first set of anonymous health data based on a privacy standard specific to the first geographic region; storing first patient private information in a data storage device in a first geographic region, the first patient private information being stored using a storage entity separate from permanent storage at a second geographic region; transmitting the first set of anonymous health data to a remote data analysis server physically located in a second geographic region for use in performing patient-specific calculations based on the first set of anonymous health data, the second geographic region being different from and external to the first geographic region; prompting, at a remote data analysis server physically located in a second geographic region, to generate an anatomical model of the patient based on the first set of anonymous health data and to perform patient-specific calculations with the generated anatomical model; determining a patient-specific blood flow calculation in the patient based on the generated anatomical model and a mass or volume of myocardial tissue of the patient; receiving analyzed anonymous health data from a remote data analysis server physically located in a second geographic region, the analyzed anonymous health data including results of a patient-specific blood flow calculation calculated at an earlier date and stored in persistent storage; as well as A patient associated with the generated anatomical model is identified by determining, at a processor in a first geographic area, first patient privacy information associated with the analyzed anonymous health data based on first patient privacy information stored in a data storage device within the first geographic area and patient-specific blood flow calculations stored in persistent storage, wherein the first patient privacy information is inaccessible within a second geographic area.

10. The system of claim 9, wherein the first geographic region and the second geographic region are governed by different patient privacy regulations.

11. The system of claim 9, wherein the operations at the remote data analysis server physically located in the first geographic region further comprise: An identifier is generated that is associated with the first set of anonymous health data, wherein the first patient private information is not present in the identifier. The first set of anonymous health data is transmitted to a second geographic area along with the generated identifier.

12. The system of claim 9, further comprising: The first set of anonymous health data is transmitted to a second geographic area along with the generated identifier.

13. The system of claim 9, wherein the operations at the remote data analysis server physically located in the first geographic region further comprise: An irreversible hash of the first patient's private information is generated.

14. The system of claim 9, the operations further comprising: Prompting improving blood flow modeling techniques available at a second geographic region based on the analyzed anonymous health data.

15. The system of claim 14, wherein the operations at the remote data analysis server physically located in the first geographic region further comprise: determining an identifier associated with the anonymized analyzed data from the second geographic area; determining an association between the identifier and first patient private information stored in the first geographic area; as well as Based on an association between the identifier and the first patient private information stored in the first geographic area, first patient private information corresponding to the anonymized analyzed data is determined.

16. The system of claim 14, the operations further comprising: determining, at a remote data analysis server physically located in a first geographic region, a hash associated with the anonymized analyzed data or the anonymized health data; as well as Previously analyzed data related to the anonymized analyzed data or the anonymous health data is determined at a remote data analysis server physically located in the second geographic area based on comparing the hash to one or more stored hashes.

17. A non-transitory computer readable medium for use on a computer system containing computer executable programming instructions to perform operations for processing electronic images to protect privacy while transmitting data across regions, the operations comprising: receiving, at a first geographic region, patient-specific image data including first patient private information that complies with a privacy standard specific to the first geographic region; removing first patient private information from the patient-specific data to generate a first set of anonymous health data based on a privacy standard specific to the first geographic region; storing first patient private information in a first geographic region, the first patient private information being stored using storage separate from a persistent storage entity at a second geographic region; transmitting the first set of anonymous health data to a remote data analysis server physically located in a second geographic region for use in performing patient-specific calculations based on the anonymous health data, the second geographic region being different from and external to the first geographic region; generating, using a remote data analysis server physically located in a second geographic region, an anatomical model of the patient based on the first set of anonymous health data and performing patient-specific calculations with the generated anatomical model; determining, using a remote data analysis server physically located in a second geographic region, a patient-specific blood flow calculation in the patient based on the generated anatomical model and a mass or volume of myocardial tissue of the patient; receiving analyzed anonymous health data from a remote data analysis server physically located in a second geographic region, the analyzed anonymous health data including results of a patient-specific blood flow calculation calculated at an earlier date and stored in persistent storage; as well as A patient associated with the generated anatomical model is identified by determining first patient private information associated with the analyzed anonymous health data based on first patient private information stored within a first geographic region and patient-specific blood flow calculations stored in persistent storage, wherein the first patient private information is inaccessible within a second geographic region.

18. The non-transitory computer-readable medium of claim 17, wherein the first geographic region and the second geographic region are governed by different patient privacy regulations.

19. The non-transitory computer readable medium of claim 17, the operations further comprising: An identifier associated with the first set of anonymous health data is generated using a processor physically located in the first geographic area, wherein The first patient private information does not exist in the identifier.

20. The non-transitory computer readable medium of claim 17, the operations further comprising: An irreversible hash of the first patient private information is generated using a processor physically located in the first geographic area.

Images