SYSTEM AND METHOD FOR MANAGING, VALIDATING AND TRANSMITTING HEALTH DATA ACROSS GEOGRAPHIC REGIONS - Patent application

Abstract

[0009] Systems and methods are disclosed for enabling health data to be analyzed, managed, and stored within different geographic regions while preserving patient privacy. One method for managing cross-border health data while preserving patient privacy includes receiving a DICOM object from a hospital computing device for analysis, generating a unique case identifier for the DICOM object, verifying the validity of the received DICOM object, and if the received DICOM object is valid based on the verification, anonymizing the received DICOM object, updating the anonymous DICOM object to include the unique case identifier, compressing the updated DICOM object, and sending the compressed DICOM object to at least one data analysis web service.

Description

[Technical field]

[0001] (Related Applications) This application claims priority to U.S. Provisional Application No. 62 / 809,151, filed February 22, 2019, the entire disclosure of which is incorporated herein by reference in its entirety. [Background technology]

[0002] Hospitals generate and store a significant amount of health data records about patients. Traditionally, health data (e.g., medical reports, x-rays, CT scans, etc.) analysis is performed by medical professionals at hospitals. However, hospitals may not be capable of performing predictive health data analysis involving state-of-the-art technology (e.g., involving image processing, natural language processing, and artificial intelligence). Increasingly, various aspects of health data analysis are being performed outside of hospitals. When health data is analyzed outside of hospitals, there may be several factors to consider for transferring health data outside of hospitals, including file size, data type, data routing, file validity (e.g., image quality), application user interface (API) to be used to facilitate selection of files to transfer, privacy, etc.

[0003] In some circumstances, health data may need to be analyzed within areas outside of the hospital or hospital department. Various hospital facilities, departments, countries, or geographic regions may have different requirements for protecting patient privacy. In general, health data may include patient privacy data, and transferring such health data outside a designated country or region may violate patient privacy requirements. For example, U.S. law attempts to protect patient privacy by defining categories of information that may link personal health information to an individual. This category of information is referred to as "Protected Health Information (PHI)," and U.S. health care professionals and service providers (e.g., physicians, hospitals, insurance companies, covered entities, business associates, etc.) are governed by regulations that dictate the use and transfer of PHI-related health data. Other countries and regions may include similar regulations, laws, and / or standards (e.g., GDPR).

[0004] At the same time, certain health data analysis, storage, and management capabilities may only exist within a region. For example, a particular medical data analysis may involve the use of web services and infrastructure with analytics available only within one selected region. Patients outside the selected region may not have access to the analytics services because patient privacy regulations may dictate that their patient privacy information (and therefore their health data) cannot be transferred to the selected region. In short, patient privacy regulations that limit the cross-border transfer of patient privacy information may mean that the data cannot be analyzed by data analytics facilities that exist outside the region. As a result, patients may be limited to the data analytics capabilities available within a region.

[0005] Thus, there is a desire for a health data management system that can create a secure, scalable, robust, and flexible infrastructure for end-to-end automated capture and processing of health data in preparation for extra-domain analysis. Further, there is a desire for a health data management system that can provide reports that include analyzed health data results of the extra-domain analysis. In one embodiment, various systems and methods of health data management systems may include a guided analyst workflow for validating the results of the extra-domain analysis.

[0006] The foregoing general description and the following detailed description are exemplary and explanatory only and are not intended to be limitations of the present disclosure. Various embodiments of the present disclosure relate to a system and method for efficiently analyzing, managing, and storing health data within different geographic regions while preserving patient privacy, according to one embodiment. Summary of the Invention [Means for solving the problem]

[0007] According to one aspect of the present disclosure, a system and method are disclosed for managing cross-border health data for analysis while protecting patient privacy.

[0008] A method for managing cross-border health data while protecting patient privacy, the method including the steps of receiving a DICOM object from a hospital computing device for analysis, generating a unique case identifier for the DICOM object, verifying the validity of the received DICOM object, and if the received DICOM object is valid based on the verification, anonymizing the received DICOM object, updating the anonymous DICOM object to include the unique case identifier, compressing the updated DICOM object, and sending the compressed DICOM object to at least one data analysis web service.

[0009] According to another embodiment, a system for managing cross-border health data while preserving patient privacy comprises a data storage device storing instructions for managing cross-border health data while preserving patient privacy; and a processor configured to receive a DICOM object from a hospital computing device for analysis, generate a unique case identifier for the DICOM object, validate the received DICOM object, and based on the validation, if the received DICOM object is valid, anonymize the received DICOM object, update the anonymous DICOM object to include the unique case identifier, compress the updated DICOM object, and send the compressed DICOM object to at least one data analysis web service.

[0010] According to another embodiment, a non-transitory computer readable medium for use on a computer system containing computer-executable programming instructions for implementing a method for managing cross-border health data while protecting patient privacy, the method including the steps of receiving a DICOM object from a hospital computing device for analysis, generating a unique case identifier for the DICOM object, verifying the authenticity of the received DICOM object, and if the received DICOM object is valid based on the verification, anonymizing the received DICOM object, updating the anonymous DICOM object to include the unique case identifier, compressing the updated DICOM object, and sending the compressed DICOM object to at least one data analysis web service.

[0011] Additional objects and advantages of the disclosed embodiments will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the disclosed embodiments. The objects and advantages of the disclosed embodiments will be realized and attained by means of 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. The present specification also provides, for example, the following items: (Item 1) 1. A computer-implemented method for managing cross-border health data while protecting patient privacy, the method comprising: receiving a DICOM object from a hospital computing device for analysis; generating a unique case identifier for the DICOM object; validating the received DICOM object; if the received DICOM object is valid based on the verification, anonymizing the received DICOM object; updating the anonymous DICOM object to include the unique case identifier; compressing the updated DICOM object; sending the compressed DICOM object to at least one data analysis web service; A method comprising: (Item 2) 2. The computer-implemented method of claim 1, wherein the unique case identifier is attached to one or more DICOM objects associated with a single case study. (Item 3) 2. The computer-implemented method of claim 1, wherein the validation of the received DICOM object is based on a DICOM image size, an orientation of the DICOM image, or an image quality associated with the DICOM object. (Item 4) The step of anonymizing the received DICOM object further comprises: extracting patient privacy information from the DICOM object; The extracted patient privacy information; identifying domain specific web services; sending the encrypted patient privacy information along with the unique case identification to the identified domain-specific web service; 2. The computer-implemented method of claim 1, comprising: (Item 5) The step of identifying domain specific web services further comprises: providing one or more network parameters associated with the hospital computing device to a web application firewall (WAF) service to determine a geographic location of the hospital computing device; retrieving a network address of a domain-specific web service using a location-specific application programming interface (API) provided by the WAF service, the identified domain-specific web service being the domain-specific web service associated with the retrieved network address; 5. The computer-implemented method of claim 4, comprising: (Item 6) receiving a request to download a health data management system onto the hospital computing device; providing an installation file for downloading the health data management system onto the hospital computing device; 2. The computer-implemented method of claim 1, further comprising: (Item 7) configuring the health data management system to receive DICOM objects from at least one of a patient assessment system, a CT scanner, and a hospital workstation; receiving a priority for the hospital computing devices via a web interface; updating the compressed DICOM object based on the received priority; 7. The computer-implemented method of claim 6, further comprising: (Item 8) creating a virtual machine on the hospital computing device; extracting the installation file from a virtual machine client; activating the virtual machine; 7. The computer-implemented method of claim 6, further comprising: (Item 9) 7. The computer-implemented method of claim 6, wherein configuring the health data management system further comprises configuring a host name, one or more network parameters for the hospital computing device, one or more communication ports, a DICOM application entity title, or a combination thereof. (Item 10) receiving a request for a health data report in a defined format; retrieving the health data report from a storage entity using the unique case identifier; retrieving patient privacy information associated with the unique case identifier; updating the retrieved health data report to include the patient privacy information; pushing the health data report to at least one of a computing device, a hospital electronic record server, or a preconfigured destination network address; 2. The computer-implemented method of claim 1, further comprising: (Item 11) Item 11. The computer-implemented method of item 10, wherein the health data report is pushed as a International Health Level 7 (HL7) message, a DICOM file, or as a Portable Document Format (PDF) object. (Item 12) 2. The computer-implemented method of claim 1, wherein the hospital computing device is at least one of a patient assessment system, an imaging modality, and a hospital workstation. (Item 13) 1. A system for managing cross-border health data while protecting patient privacy, the system comprising: one or more data storage devices storing instructions for managing cross-border health data while protecting patient privacy; one or more processors, the one or more processors executing the instructions; receiving a DICOM object from a hospital computing device for analysis; generating a unique case identifier for the DICOM object; validating the received DICOM object; if the received DICOM object is valid based on the verification, anonymizing the received DICOM object; updating the anonymous DICOM object to include the unique case identifier; compressing the updated DICOM object; sending the compressed DICOM object to at least one data analysis web service; one or more processors configured to perform a method comprising: A system comprising: (Item 14) Item 14. The system of item 13, wherein the validation of the received DICOM object is based on a DICOM image size, an orientation of the DICOM image, or an image quality associated with the DICOM object. (Item 15) Item 14. The system of item 13, wherein the hospital computing device is at least one of a patient assessment system, an imaging modality, and a hospital workstation. (Item 16) receiving a request to download a health data management system onto the hospital computing device; providing an installation file for downloading the health data management system onto the hospital computing device; Item 14. The system of item 13, further comprising: (Item 17) The system further comprises: configuring the health data management system to receive DICOM objects from at least one of a patient assessment system, a CT scanner, and a hospital workstation; receiving a priority of the hospital computing devices via a web interface; updating the compressed DICOM object based on the received priority; Item 17. The system of item 16, configured to perform the following: (Item 18) The system further comprises: creating a virtual machine on the hospital computing device; extracting the installation file from a virtual machine client; activating the virtual machine; Item 17. The system of item 16, configured to perform the following: (Item 19) 1. A non-transitory computer readable medium for use on a computer system containing computer executable programming instructions for implementing a method for managing cross-border health data while protecting patient privacy, the method comprising: receiving a DICOM object from a hospital computing device for analysis; generating a unique case identifier for the DICOM object; validating the received DICOM object; if the received DICOM object is valid based on the verification, anonymizing the received DICOM object; updating the anonymous DICOM object to include the unique case identifier; compressing the updated DICOM object; sending the compressed DICOM object to at least one data analysis web service; 16. A non-transitory computer readable medium comprising: (Item 20) The step of identifying domain specific web services includes: providing one or more network parameters associated with the hospital computing device to a web application firewall (WAF) service to determine a geographic location of the hospital computing device; retrieving a network address of a domain-specific web service using a location-specific application programming interface (API) provided by the WAF service, the identified domain-specific web service being the domain-specific web service associated with the retrieved network address; 20. The non-transitory computer-readable medium of item 19, comprising: [Brief description of the drawings]

[0013] [Figure 1] FIG. 1 depicts an example schematic block diagram of health data management between a hospital and a data analytics vendor according to an exemplary embodiment of the present disclosure.

[0014] [Diagram 2]FIG. 2 depicts an example data flow of health data through the health data management system 100 of FIG. 1 according to an example embodiment of the present disclosure.

[0015] [Diagram 3] FIG. 3 depicts components of the health data management system 100 of FIG. 1 according to an exemplary embodiment of the present disclosure.

[0016] [Figure 4] FIG. 4 depicts an example sequence flow of health data through the health data management system 100, according to an example embodiment of the present disclosure.

[0017] [Diagram 5] FIG. 5 is a flow diagram of an example method for managing health data according to an example embodiment of the present disclosure.

[0018] [Figure 6] FIG. 6 is a flow diagram of an example method for transmitting health data for cross-border analysis according to an example embodiment of the present disclosure.

[0019] [Figure 7] FIG. 7 is a flow diagram of an example method for receiving a health data analysis report according to an example embodiment of the present disclosure.

[0020] [Figure 8A] FIG. 8A is a flow diagram of an example method for installing the health data management system 100 of FIG. 1 according to an example embodiment of the present disclosure.

[0021] [Figure 8B] FIG. 8B is an exemplary schematic block diagram and data flow of an installation of the health data management system 100 of FIG. 1 according to an exemplary embodiment of the present disclosure.

[0022] [Figure 8C]FIG. 8C is a screenshot of a web interface that allows a hospital administrator to configure the health data management system 100 of FIG. 1, according to an exemplary embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0024] As used herein, the term "exemplary" is used in the sense of "example" and not "ideal." Additionally, the terms "a" and "an" do not denote a limitation of quantity herein, but rather denote the presence of one or more of the referenced items. For purposes of this disclosure, a "patient" may refer to any individual or person on whom a diagnostic or therapeutic analysis (e.g., data analysis) is being performed, or to any individual or person associated with one or more individual diagnostic or therapeutic analyses.

[0025] The term "health data" may include medical data collected about a patient at a single practice (e.g., Digital Imaging and Communications in Medicine (DICOM) objects), and health data collected about a patient by any healthcare provider, laboratory, specialist, clinician, etc. Health data may be associated with a particular patient, who is identifiable via patient privacy information. Patient privacy information may be any information that links health data to a particular individual. Patient privacy information may be defined objectively (as information that connects an individual to their health data) and / or by law and regulation. Various domains may include different definitions of the types of information that constitute patient privacy information.

[0026] A "region" may refer to any environment with borders defined by regulations protecting patient privacy. In one embodiment, a "region" may refer to a known geographic area governed by a set of regulations protecting patient privacy / personal data. For example, a "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 under a single set 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 identifying information, etc. (e.g., CT, MRI, ultrasound, etc.). Various systems and methods for protecting patient health information while transmitting health data are disclosed, for example, in U.S. Non-Provisional Application No. 15 / 635,127, filed June 27, 2017, and entitled "Systems and Methods for Modifying and Reacting Health Data Across Geographic Regions," which is incorporated herein by reference in its entirety.

[0027] Alternatively or additionally, a "region" may refer to a given physical facility, a computing system of a given entity, or a given cloud platform. In such cases, the various regions between which health data is compiled may still be within a single country, state, or province. For example, a region may include a hospital that may remove patient privacy information from collected health data prior to transferring the health data to another region (e.g., a cloud platform) for data analysis. The hospital and cloud platform may be within the same geographically defined region, e.g., the United States.

[0028] The present disclosure includes a system and method for transferring health data outside of a hospital. In one embodiment, the health data may be transferred to a cloud-based web service for analysis. The health data transfer may include steps of selecting or identifying files to transfer for analysis, preparing files for transfer or analysis, performing automatic health data capture, timing the transfer of files, determining whether various files are related, detecting completed analysis of the health data, monitoring the status or progress of the health data analysis, generating reports of the completed analysis, receiving or transmitting reports of the completed analysis, and otherwise managing the interaction between the domain (e.g., hospital) and the cloud-based web service.

[0029] In one embodiment, preparing the file for transfer and determining the completed analysis may involve protecting patient privacy during the transfer of the health data out of the first domain. In an exemplary case, the first domain may include a hospital. In such a scenario, the health data management system may include an embodiment of transferring data from the hospital to a vendor for remote analysis of the data. In one embodiment, the health data management system may receive health data from a hospital, where the file of the health data includes patient privacy information. The health data management system may anonymize the health data file by stripping the patient privacy information from the health data. The health data management system may further transmit the anonymous health data to a cloud-based data analysis web service. In one embodiment, the patient privacy information may be transmitted and stored within a domain-specific cloud-based web service (e.g., in the first hospital domain). In other words, the anonymized health data may be transferred from the first domain to a cloud-based data analysis web service, while the patient privacy information associated with the health data may remain within the first domain in the domain-specific cloud-based web service.

[0030] In one embodiment, the health data management system may generate or detect a completed report including the results of the health data analysis from the cloud-based data analysis web service. In one embodiment, the health data management system may push the result report to a domain (e.g., a first hospital domain). In this manner, the data analysis may be performed in the remote domain without transmitting patient privacy information to the remote domain. In other words, transmitting the health data may include modifying and editing patient privacy information from the health data such that the health data may undergo analysis at the remote domain while respecting patient privacy.

[0031] In one embodiment, the health data management system may transfer health data (e.g., DICOM objects) from a customer location (e.g., hospital, clinic, etc.) to a cloud computing web service for analysis of the DICOM objects. The system may also receive health data directly from a CT scanner, CT workstation, or patient assessment system using the DICOM protocol.

[0032] In one embodiment, the health data may include patient-specific image data (e.g., in the form of a DICOM file). In one scenario, the image data may include data regarding the geometry of the patient's heart, e.g., at least a portion of the patient's aorta, a proximal portion of the main coronary artery (and branches extending therefrom) connected to the aorta, and / or the myocardium. The patient-specific anatomical data may be acquired non-invasively, e.g., using a non-invasive imaging method. For example, CCTA is an imaging method in which a user may operate a computed tomography (CT) scanner to view and create images of structures, e.g., the myocardium, the aorta, the main coronary arteries, and other blood vessels connected thereto. The CCTA data may vary in time, e.g., to show changes in blood vessel shape over the cardiac cycle. CCTA may be used to generate images of the patient's heart.

[0033] Alternatively, other non-invasive imaging methods (including magnetic resonance imaging (MRI) or ultrasound (US)) or invasive imaging methods (such as digital subtraction angiography (DSA)) may be used to generate images of structures of the patient's anatomy. The imaging method may involve injecting a contrast agent intravenously into the patient to allow identification of structures of the anatomy. Health data accompanying the images (e.g., generated by CCTA, MRI, etc.) may be provided by a third party vendor, such as a radiology lab or cardiologist, by the patient's physician, etc.

[0034] 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. Blood pressure may include blood pressure in the patient's brachial artery (e.g., using a pressure cuff), such as maximum (systolic) and minimum (diastolic) pressure. Exemplary health data may thus include data collected from imaging modalities, wearable devices, blood pressure cuffs, thermometers, fitness trackers, blood glucose meters, heart rate monitors, etc.

[0035] FIG. 1 is a schematic block diagram of a hospital-vendor system for managing health data via a cloud platform, according to an exemplary embodiment of the present disclosure. The hospital-vendor system may include a health data management system 100 configured to receive information from hospital computing devices (e.g., CT workstation 102, CT scanner 104, patient assessment system 106, etc.) via a wireless network 110. In one embodiment, the wireless network 110 may include a network local to a hospital network (e.g., a first region), and the health data management system 100 may be deployed within the wireless network 110. In one embodiment, the hospital may be a location where the hospital is registered as a customer of the vendor. An exemplary vendor of the hospital-vendor system may include a data analytics service (e.g., a data analytics service 114).

[0036] In one embodiment, the health data management system 100 may be deployed in a hospital network as a virtual appliance delivered as a single file over a wireless network 110. For example, a hospital site administrator may download a file containing the health data management system 100 from a vendor user interface. The download may enable the hospital computing devices (CT workstations 102, CT scanners 104, patient assessment systems 106, etc.) to move DICOM studies to the virtual machine (e.g., health data management system 100). In one embodiment, the site administrator also registers the hospital as a customer of the vendor and therefore also connects the health data management system 100 to the vendor's network (e.g., network 111 of data analysis service 114). These processes are described in more detail in Figures 8A-8C.

[0037] In an exemplary embodiment, the health data management system 100 may query hospital computing devices (such as the CT workstation 102, the CT scanner 104, and the patient assessment system 106) and pull one or more DICOM objects from such computing devices. In an exemplary embodiment, the DICOM objects may include patient privacy information, a priority level of analysis to be performed on the DICOM object's files, the type of case study / analysis to be performed, patient scans / images, etc. Alternatively or in addition, the hospital computing devices may be connected to a web server that provides or stores the DICOM objects. In such a case, the health data management system 100 may pull one or more DICOM objects from the server. In yet another embodiment, the DICOM objects may be uploaded (e.g., to the data analysis service 114) using a web interface provided by the health data management system 100. In short, the health data management system 100 may receive health data files via a network (e.g., the hospital network 110) in a first region and upload the health data files to the data analysis service 114 in a second region using various methods (e.g., via the network 111). As described above, the health data management system 100 may anonymize the health data file before uploading the file out of the first domain (e.g., by removing patient privacy information from the health data file).

[0038] In one embodiment, the management service 112 may manage subscriptions / customers of the data analytics service 114. For example, the management service 112 may register one or more customers of a vendor that analyzes anonymous health data. For example, the management service 112 may receive requests from potential customers (e.g., hospitals) that wish to have services provided by the data analytics service 114. In one scenario, the management service 112 may act as one or more cloud platforms for managing and storing anonymous health data. The management service 112 may provide an interface for hospitals to provide anonymous health data to the data analytics service 114. In one embodiment, the interface may be a health data management system 100 that may convert the health data generated at the hospital into anonymous health data and route the data to an appropriate data analytics web service.

[0039] In one embodiment, the management service 112 may further manage the order in which the health data files are analyzed by the data analysis service 114. In one embodiment, the order may be based on the order in which the files were generated and uploaded, and / or the priority level associated with each of the files. The management service 112 may further generate, manage, and store reports regarding the analyzed anonymous health data. For example, the management service 112 may vary the reports generated depending on the client (e.g., hospital) from which the DICOM object originated. For example, different clients may configure different settings during registration. The reports may be generated based on the settings dictated at the time of registration. In one embodiment, the health data management system 100 and / or the management service 112 may manage the anonymous health data files and / or reports.

[0040] The data analytics service 114 may comprise web services and serve as one or more cloud platforms for analyzing the anonymous health data. Additionally, the data analytics service 114 may calculate results, generate result reports (e.g., 3D models, PDFs, etc.), and present the analysis and results to the hospital users. For example, one or more web services of the data analytics service 114 may calculate blood flow in the coronary arteries using received anonymous health data from a cardiac CT scan of the hospital computing device. The one or more web services may provide an interactive 3D model of the coronary arteries showing the calculated fractional flow reserve values ​​along with a PDF report.

[0041] In one embodiment, the patient privacy information web service 116 may act as one or more cloud platforms for managing and storing patient privacy information. The patient privacy information web service 116 may pair the patient privacy information with completed reports from the data analytics service 114. For example, the health data management system 100 may use the patient privacy information web service 116 to store the patient privacy information in a database. In this manner, the patient privacy information may be isolated from the data analytics service 114. In one embodiment, the patient privacy information web service 116 may re-identify anonymous reports from the data analytics service 114 by pairing the reports with stored patient privacy information in a database of or accessible by the patient privacy information web service 116. In one embodiment, the patient privacy information web service 116 may be accessible only from the area (e.g., network 110) where the health data was generated. In another embodiment, the patient privacy information web service 116 may be prompted by the health data management system 100 (e.g., via network 111) to provide identifying information to completed reports. In some cases, the patient privacy information web service 116 may provide identifying information that is lacking patient privacy information.

[0042] The network 110 and the network 111 may include the Internet, a content distribution network, or any other wired, wireless, and / or telephone or local network. In an embodiment, the health data management system 100, the CT scanner 104, the CT workstation 102, the patient assessment system 106, and the HL7 engine 108 may communicate with each other via the network 110. For example, the health data management system 100 may receive health data (e.g., DICOM objects) from the CT scanner 104, the CT workstation 102, or the patient assessment system 106 via the network 110. The health data management system 100 may further transmit completed reports, notifications of completed reports, or interruptions to completing reports (e.g., health data quality issues) to the CT scanner 104, the CT workstation 102, or the patient assessment system 106 via the network 110. The health data management system 100 may further push completed reports to the patient privacy information web service 116 via network 110 or network 111 so that reports from the data analysis service 114 can be paired with patient privacy information.

[0043] The health data management system 100 may also be configured to communicate with the management service 112 and the data analytics service 114 via the wireless network 111. For example, the health data management system 100 may upload raw health data to the data analytics service 114 for analysis. The health data management system 100 may also communicate with the management service 112 to receive data logs indicating the status or progress of the analysis. Additionally, the health data management system 100 and / or the management service 112 may receive or push analysis reports (e.g., PDF results) from the data analytics service 114 via the network 111 and communicate the reports to various interfaces that are part of the network 110. The management service 112 and the data analytics service 114 may also communicate via the wireless network 111.

[0044] 2 depicts an exemplary detailed view of the interaction between the health data management system 100 of FIG. 1 and a patient privacy cloud platform (e.g., patient privacy information web service 116) according to an exemplary embodiment of the present disclosure. Any platform or service that is structured to store data may be employed as a patient privacy cloud platform. Storage of patient privacy information, including PHI data, is one exemplary embodiment of the present disclosure.

[0045] In one embodiment, a user 202 may upload a DICOM object from a hospital computing device (e.g., a CT workstation, a CT scanner, a patient assessment system, etc.). Once the health data management system 100 receives the uploaded DICOM object, the health data management system 100 may extract patient privacy information (e.g., PHI data) from the DICOM object. The patient privacy information may be sent to a domain-specific cloud platform (e.g., the patient privacy information web service 116) using a service that may allow stateless operation. For example, the patient privacy information may be sent to the patient privacy information web service 116 via a Representational State Transfer (REST) ​​Application Programming Interface (API) 206. The API 206 may correspond to the data analysis service 114, and the API 206 may be installed in the first (e.g., hospital) domain. In one scenario, the patient privacy information transfer from the health data management system 100 to the patient privacy information web service 116 may be performed using Hypertext Transfer Protocol (HTTP).

[0046] In one embodiment, the patient privacy information web service 116 may include or communicate with a database (e.g., domain-specific relational database 212). For example, the patient privacy information web service 116 may receive, transfer, or access patient privacy information stored in the domain-specific relational database 212. The relational database may include a domain-specific database that is structured to recognize relationships between stored items of information. In one embodiment, the domain-specific relational database 212 may store patient privacy information extracted from DICOM objects by the health data management system 100. The patient privacy information is stored in the relational database 212 and may be encrypted. In an exemplary embodiment, the relational database 212 may provide encryption when new objects (e.g., received patient privacy information) are stored or accessed.

[0047] In one embodiment, all of the components illustrated in FIG. 2 may reside within a first domain (e.g., a hospital network) or as part of a support service network. Thus, the data (e.g., in the relational database 212) may remain within the first domain where the hospital computing device (e.g., the device used by the user 202 to upload the DICOM) is located. In one embodiment, the patient privacy information cannot be accessed outside the domain in which it was stored. For example, a user who submits a case in Japan and travels to a different geographical region will not be able to retrieve the patient privacy information.

[0048] The hospital user 214 may interact with the web application 208 to review uploaded object files, review the status of case processing, update data analysis priorities for case processing, etc. In other words, the hospital user 214 may have access to the patient privacy information and / or analyzed data from the data analytics service 114 using the web application 208 or web interface. In one embodiment, the hospital user 214 may review the status of case processing of the data analytics service 114. For example, the health data management system 100 or the web application 208 may route the hospital user 214 to the administration service 112 or the patient privacy information web service 116 endpoint based on the user's IP address so that the user 214 may review the status of case processing.

[0049] In one embodiment, customer support personnel 216 and generating users 218 of the data analytics service 114 may have access to the patient privacy information or stored versions of the patient privacy information. While the customer support personnel 216 and / or generating users 218 may be associated with the data analytics service 114, they do not have direct influence or access to the analysis of the data analytics service 114. In one embodiment, the customer support personnel 216 may be presented with a customer service interface that may provide the ability to log into each area individually by utilizing a virtual private network (VPN) service that may be exclusively arranged for their use. The VPN service may extend access to the patient privacy information of a specific area to the customer support personnel even when the customer support is not accessing the patient privacy information from the first area. The customer service interface may be part of the web application 208. In one embodiment, the generating users 218 may access or edit reports of the analyzed data via the generating user interface. The production user interface may be part of the web application 208, which may provide the production user 218 with an interface to review, validate, or edit any intermediate reports or products of the analysis.

[0050] In one embodiment, the health data management system 100 may send DICOM objects (lacking patient privacy information) to a cloud platform (e.g., data analysis service 114) for data analysis. The management service 112 may read the calculations performed by the data analysis service 114, generate interactive views, 3D models, or PDF report files, and store the result files in a database.

[0051] Once a case is processed (or health data analysis is completed), a data report may be generated and the report may be paired with the patient privacy information stored in the relational database 212. For example, the health data management system 100 may identify the patient privacy information to be associated with the anonymous report received from the data analytics service 114. In an exemplary embodiment, the patient privacy information from the relational database 212 may be retrieved using the API 206.

[0052] 3 depicts components of the health data management system 100 of FIG. 1 according to an exemplary embodiment of the present disclosure. Each health data management system 100 may include an assembly of components as described in further detail below. The health data management system 100 may consist of multiple web services such as a service class provider (SCP) service 310, a result transport service 312, an upload service 314, a monitoring service 316, a log processing service (e.g., a log shipper service 318), and a domain-specific result service 320, as shown in FIG.

[0053] In an exemplary embodiment, the Service Class Provider (SCP) service 310 may be part of the health data management system 100 where DICOM objects may be received from the CT scanner 104, the patient assessment system 106, or the CT workstation 102. The SCP service 310 may be implemented as a Linux service and launched, for example, after installation of the health data management system 100 on the network 110. In yet another embodiment, the SCP service 310 may be integrated with the management service 112 through secure HTTP.

[0054] In one embodiment, the SCP service 310 may monitor one or more configured DICOM ports from a hospital computing device (e.g., the CT scanner 104, the patient assessment system 106, or the CT workstation 102) for an indication of the generation or creation of a DICOM file. Once the SCP service 310 receives an indication of the creation of a DICOM file by a hospital computing device, the SCP service 310 may initiate the creation of a case file to receive one or more DICOM objects. For example, the SCP service 310 may create a new case and a unique case identifier with the management service 112, and the new case may be identified (by the management service 112) using the unique case identifier.

[0055] In one embodiment, the SCP service 310 may receive multiple DICOM objects containing images associated with a single case study. The SCP service 310 may generate a single case study with multiple DICOM objects. In one embodiment, the SCP service 310 may be configured to receive DICOM objects from one or more hospital computing devices in parallel, and the SCP service 310 may generate a case file for the DICOM objects of each hospital computing device. For example, the SCP service 310 may generate one case file for a set of DICOM objects received from hospital computing device "A" and a separate second case file for a set of DICOM objects received from a different hospital computing device "B". In the above exemplary embodiment, the SCP service 310 may temporarily store the received DICOM objects in a configured DICOM database.

[0056] In one embodiment, the SCP service 310 may analyze one or more tags associated with the received DICOM object. For example, the SCP service 310 may anonymize the received DICOM object. For example, the SCP service 310 may extract patient privacy information (e.g., PHI) from the received DICOM object, de-identify the extracted patient privacy data (e.g., by replacing the patient privacy data with a predefined string), and prompt for storage of the patient privacy data corresponding to the received DICOM object. In one embodiment, the DICOM object may be associated with a unique case identifier that does not include patient privacy data (e.g., PHI). The data analysis service 114 and / or the management service 112 may track the DICOM object using the unique case identifier. In another embodiment, analyzing one or more tags associated with the received DICOM object may include identifying tags related to a service provider, a time, a date, an insurance policy, or any annotations associated with the DICOM object. The SCP service 310 may further process the DICOM object based on the tags. For example, the SCP service 310 may provide or facilitate billing functionality associated with tags related to insurance policies, times, dates, or physicians. As another example, the SCP service 310 may perform one or more operations on a DICOM object based on annotations (e.g., from image acquisition). The operations may include assessing image quality, restructuring to improve the DICOM object, removing or discarding files from the DICOM object to improve image quality, etc.

[0057] In one embodiment, the SCP service 310 may compress one or more anonymous DICOM objects into a case file and upload the case file to the data analysis service 114. The anonymous DICOM objects may also be uploaded to the data analysis service 114 in an uncompressed state. In yet another embodiment, the health data management system 100 may use the upload service 314 to upload data to the data analysis service 114. For example, the SCP service 310 may prompt the upload service 314 when all DICOM files for a case file are received, which may compress the DICOM objects for a given case file and upload the compressed case file to the data analysis service 114 for analysis. In one embodiment, the case file may be uploaded to the data analysis service 114, which may be pre-configured upon installation of the health data management system 100 or upon identifying the hospital (e.g., of the CT scanner 104, patient assessment system 106, or CT workstation 102) as a customer or subscriber of the data analysis service 114.

[0058] In an exemplary embodiment, after a configured time following a successful upload, the SCP service 310 may delete the DICOM object file from storage. The configured time for deletion may be zero in an exemplary upload setting. The SCP service 310 may maintain a file system directory that reflects the current state of uploaded case studies with DICOM objects. The file system directory may record new cases being received, the upload process (or upload progress), and case-related errors (e.g., problems with the upload or problems with the file that may prevent the upload). Problems with the upload may include connectivity, network, load problems. Problems with the file may include inappropriate file size, insufficient image quality, inappropriate file type for the required analysis, etc. Standards that may dictate appropriate files may be specific to the data analysis service 114. Additionally, the standards may be configured during installation of the health data management system 100.

[0059] In one embodiment, the SCP service 310 may further engage in a series of operations with the hospital computing devices. For example, the SCP service 310 may communicate with a service class user (SCU) client associated with the hospital computing device. In an exemplary embodiment, the SCP service 310 may validate the identity of the hospital computing device SCU client prior to providing a connection for receiving a DICOM object. In one embodiment, the SCP service 310 may communicate with multiple hospital computing devices in addition to the imaging devices. The SCP service 310 may perform a set of operations that are unique to each of the hospital computing devices or to a type of hospital computing device. For example, the SCP service 310 may engage in a set of operations for medical imaging devices and a different set of operations for monitoring devices or clinical trial devices. For example, operations for medical imaging devices may include validating image file size or type, converting image files to one or more file formats, verifying completion of the imaging process, etc. Operations for monitoring devices may include time intervals for receiving data. Operations for clinical trial devices may include categorizing the test type, configuring for routing data to one or more web services or facilities for analysis, etc. The operations may be pre-configured upon installation of the health data management system 100 on the network 110. In one embodiment, the health data management system 100 may include a default set of operations that are associated with one or more hospital computing devices.

[0060] In an exemplary embodiment, the results transport service 312 may push the results report (generated by the results service 320) to a pre-configured destination, e.g., a hospital web interface. The results transport service 312 may be available for configuration by the user via a (hospital) web application. In an exemplary embodiment, the results transport service 312 may only activate if results push is "enabled" in the configuration of the health data management system 100. For example, the results transport service 312 may poll the backend of the administration service 112 or a database of completed analysis results for cases in "completed" status and for PDF results reports / documents. In an embodiment, the results transport service 312 may download or generate the completed report (e.g., PDF report), which may include language settings / fields desired by the user of the hospital web application. In an embodiment, the results transport service 312 may wrap the PDF document based on the configuration, either as a DICOM encapsulated PDF object or as an HL7 message, and push the object to the web service at the appropriate pre-configured destination.

[0061] The log shipper service 318 may provide a periodic log of the operation of the health data management system 100. In one embodiment, an authorized user or interested party may request log shipping (e.g., via a remote command). In response to such a request, the log shipper service 318 may compress and upload the log files to the management service 112. In an exemplary embodiment, the monitoring service 316 may prompt the log shipper service 318 when it is time to transfer the log files to the management service 112. The log shipper service 318 may compress files containing system and application log files. Such files may be stored in a database prior to sending to the management service 112.

[0062] The monitoring service 316 may provide system upgrades for the health data management system 100. For example, the monitoring service 316 may contact an application programming interface (API) (e.g., API 206 of FIG. 2) at pre-set time intervals to check if a newer version of the health data management system 100 is available. The time interval may include a pre-configured update window. If a newer version is detected, the health data management system 100 may download the appropriate files, validate their integrity, send the files to their intended destination, and notify the SCP service 310 about the installation of the updated version of the health data management system 100. The SCP service 310 may stop accepting new connections, wait for existing jobs to finish, and self-terminate. Once the SCP service 310 is no longer running, the monitoring service 316 may reboot the health data management system 100 and start the new version of the health data management system 100.

[0063] The monitoring service 316 may also send the status of the health data management system 100 to an API (e.g., API 206 of FIG. 2). The status may include the status of the SCP service 310, the number of active connections with hospital computing devices, and the number of pending DICOM objects or cases. The monitoring service 316 may continue to report the status during an automatic update until a reboot of the health data management system 100 occurs.

[0064] The monitoring service 316 may support remote commands invoked by authorized users. These commands may be issued from a support user via a customer support portal. The customer support portal may send the commands to the health data management system 100 in response to a system status report. The monitoring service 316 may execute the commands under the context of a user that is specifically created with limited rights for the sole purpose of executing the remote command. If the remote command generates any output, the output may be sent back to the customer support portal along with the results of the command.

[0065] A domain-specific result service 320 may generate a result report. In some embodiments, the results may be generated with domain-specific format, graphics, or content. The health data management system 100 may configure or contact a result service 320 for each domain it interfaces with, or for one or more domains (e.g., in scenarios involving a network of hospitals, healthcare providers, or geographic regions). The result service 320 may store one or more pre-determined result settings (e.g., result format, graphics, content, etc.) for its individual domain. In some cases, the result service 320 may store one or more result reports until retrieval by the result transport service 312. The health data management system 100 and / or the result service 320 may retrieve the patient privacy data, pair it with the completed medical analysis, and generate the final result report.

[0066] FIG. 4 depicts an exemplary sequence flow of a method 400 of managing health data using the health data management system 100. In an exemplary embodiment, the SCP service 310 may detect the availability or upload of one or more DICOM objects by a hospital computing device (e.g., CT scanner 104, patient assessment system 106, CT workstation 102, etc.). As discussed above, the SCP service 310 may poll one or more hospital computing devices to detect when a DICOM object is generated. When a hospital computing device generates or creates a DICOM file, the SCP service 310 may detect the DICOM file (e.g., step 401). In an embodiment, step 403 may include the SCP service 310 generating a unique case for a single case study. The unique case may prepare the detected DICOM objects for a case study (e.g., by the data analysis service 114). In an embodiment, the SCP service 310 may further generate a unique case identifier for the case.

[0067] In one embodiment, the SCP service 310 may also verify the validity of the DICOM object. For example, verifying the validity of the DICOM object may include determining or receiving a predetermined image quality criterion for the DICOM object that may be subjected to analysis by the data analysis service 114. The SCP service 310 may determine whether the received DICOM object meets the predetermined criterion. If the DICOM object meets the criterion, the SCP service 310 may proceed with other steps of the method 400. If the DICOM object does not meet the criterion, the SCP service 310 may notify the hospital device to regenerate the DICOM object or resubmit the data. The SCP service 310 may further provide a reason why the DICOM object did not pass verification.

[0068] In an exemplary embodiment, the DICOM object may include patient privacy information (e.g., PHI data). The SCP service 310 may extract the PHI data from the DICOM object and de-identify the DICOM object. For example, the SCP service 310 may extract the PHI data from the DICOM object and replace the PHI data with a predefined string and / or a unique case identifier. In addition, the SCP service 310 may encrypt the PHI data. The PHI data may be stored by the domain-specific patient privacy information web service 116 (e.g., step 405). In one embodiment, the PHI data of the case may be stored such that the PHI data is associated with the case's unique case identifier.

[0069] In the illustrated embodiment above, the SCP service 310 may detect DICOM objects associated with a single case study. For example, the SCP service 310 may detect that multiple DICOM objects are associated with a case study. The SCP service 310 may aggregate the multiple DICOM objects for the case study (e.g., step 407). The SCP service 310 may further compress the aggregated DICOM objects associated with the single case study (e.g., step 409). The upload service 314 may receive the compressed DICOM objects for the case study. The upload service 314 may further upload one or more compressed DICOM objects associated with the single case study to the data analysis service 114 (e.g., step 411). In one embodiment, each case study may have a priority level associated with it. The upload service 314 may push the compressed DICOM objects to the data analysis service 114 according to the priority level of the DICOM objects. For example, a DICOM object with a higher priority level may be pushed to the data analysis service 114 before a DICOM object with a lower priority level. The priority level may be dictated by medical personnel when the DICOM object is generated. Alternatively, or in addition, the priority level may be set based on the hospital computing device where the DICOM object is received, based on the SCP service 310, based on the data analysis service 114 performing the analysis, etc. The priority level may also be modified at one or more stages / steps of the method 400. In one embodiment, the data analysis service 114 may perform a series of calculations and image processing to analyze one or more DICOM objects (e.g., step 413).

[0070] In an exemplary embodiment, the management service 112 may receive one or more analyzed DICOM objects from the data analysis service 114 (e.g., step 415). The management service 112 may validate the data analysis performed by the data analysis service 114. The management service 112 may validate that all components of the data analysis are complete and sufficient to complete a results report. The management service 112 or the results service 320 may further generate a results report (e.g., step 417). In an alternative embodiment, the management service 112 may make the analyzed DICOM objects available to an analysis technician. The technician may further submit a request to validate the analysis and generate a results report. Alternatively, or in addition, the technician may further edit the analysis in the results report. For example, the management service 112 may provide one or more prompts for the technician to validate the analysis. In one scenario, the management service 112 may generate various reporting options for the technician to select. The options may include one or more pins, displays, views, charts, compares, etc., allowing the technician to select a combination of the options provided to finalize a report of the analyzed DICOM data.

[0071] The results transport service 312 may receive the results report from the management service 112 (e.g., step 419). The results report may include a PDF of the analysis results, an interactive model with various displays or views, etc. In one embodiment, the model may include a 3D anatomical model that the user may manipulate to view different parts of the analysis. For example, the analysis may generate a blood flow model through the 3D anatomical model. Various embodiments of diagnostic analysis using image reconstruction and anatomical models are disclosed, for example, in U.S. Patent No. 8,315,812, issued November 20, 2012, and entitled "Method and System for Patient-Specific Modeling of Blood Flow," which is incorporated by reference in its entirety. The report may include a surface model, a graph, a chart, a color coding, an indicator, an interactive display, an alert, a signal, or any known graphic object. Various embodiments of the graphical representations and displays are disclosed, for example, in U.S. Patent No. 8,706,457, issued April 22, 2014, and entitled "Method and System for Providing Information from a Patient-Specific Model of Blood Flow," which is incorporated by reference in its entirety. In one embodiment, the results transport service 312 may store the results reports in a results database (e.g., step 421). Each report may include an associated unique case identifier.

[0072] In an exemplary embodiment, the SCP service 310 or the management service 112 may receive a request to retrieve the result report, and in response, the result report may be communicated by the result transport service 312 (e.g., step 423). The request may be communicated by a web interface (e.g., using the RESTful API 206). In one embodiment, the request may include a unique case identifier.

[0073] In an exemplary embodiment, the SCP service 310 may associate patient privacy data with the retrieved results report. For example, the SCP service 310 may detect a unique case identifier in the report and determine the patient privacy data corresponding to the unique case identifier. In one such scenario, the results service 320 or the SCP service 310 may transmit the unique case identifier to the patient privacy information web service 116 and request stored PHI data from the patient privacy information web service 116 that corresponds to the unique case identifier (e.g., step 425). The patient privacy information web service 116 may retrieve the encrypted PHI data for the unique case identifier from the relational database 322 and send the PHI data to the SCP service 310. The SCP service 310 may further decrypt the PHI data and update the retrieved results report with the decrypted PHI data (e.g., step 427). The SCP service 310 may push the results report to a device or interface where a user may access the report (e.g., step 429). Although the above embodiments describe patient privacy information as PHI data, the embodiments may apply to any form of patient privacy information.

[0074] 5 is a flow diagram 500 of an example method for managing health data according to an example embodiment of the present disclosure. In operation 510, health data may be received at the health data management system 100 from a hospital computing device. The health data in operation 510 may be in Digital Imaging and Communications in Medicine (DICOM) format. The hospital computing device may include a CT scanner 104, a patient assessment system 106, or a CT workstation 102, as shown in FIG. 1.

[0075] In an exemplary embodiment, the health data management system 100 may generate a unique case identifier for the received health data (e.g., DICOM object), as per operation 512. At operation 514, the health data management system 100 may validate the health data (e.g., DICOM object). For example, a DICOM object may be invalid if the DICOM object is missing a DICOM image, if the DICOM image size is outside a defined range, or if the DICOM image does not meet a defined quality requirement. In an alternative embodiment, the health data management system 100 may send a message to the hospital computing device as a result of determining that the received DICOM object is invalid. For example, the health data management system 100 may prompt for resending the DICOM object and / or provide a notification that the received DICOM object is invalid and another DICOM object should be generated.

[0076] At operation 516, the health data management system 100 may remove patient privacy information from the validated DICOM objects. Exemplary patient privacy information may include information that may link the DICOM object to a patient, such as the patient's name, date of birth, phone number, address, email address, social security number, etc. In an exemplary embodiment, the health data management system 100 may further encrypt the extracted patient privacy information by de-identifying each of the patient privacy information using a one-way encryption function (e.g., operation 518).

[0077] At operation 520, the health data management system 100 may identify a destination network address of a domain-specific web service and send the encrypted patient privacy information. In an exemplary embodiment, to identify the domain-specific web service, the health data management system 100 may provide network parameters of the hospital computing device associated with the received DICOM object to a web application firewall (WAF) service and geolocate the hospital computing device. The WAF service may redirect the health data management system 100 to a location-specific application programming interface (API). The health data management system 100 may access the location-specific API and retrieve a network address of the domain-specific web service (e.g., patient privacy information web service 116) for managing and storing the patient privacy data. At operation 522, the health data management system 100 may send the patient privacy information to the identified destination network address of the domain-specific web service (e.g., of operation 520). In an exemplary embodiment, the health data management system 100 may send the encrypted patient information to the identified location-specific web service along with the unique case identifier.

[0078] FIG. 6 is a flow chart 600 further depicting steps of forwarding anonymized data to a cloud platform for analysis according to an exemplary embodiment of the present disclosure. At operation 610, the health data management system 100 may receive the DICOM object stripped of patient privacy information. The health data management system 100 may update the anonymous DICOM object (without the patient privacy information) to include the unique case identifier (e.g., at operation 612). For example, the DICOM object may have a header that may be updated to include the unique case identifier. (In an alternative embodiment, the unique case identifier may simply be sent with the DICOM object to the data analysis service 114, rather than as part of the DICOM object itself.) At operations 614 and 616, the health data management system 100 may compress the DICOM object and send the compressed DICOM object to the data analysis service 114. In one embodiment, the compressed DICOM object may be sent using a REST HTTP protocol.

[0079] FIG. 7 is a flowchart 700 of receiving a result report of analyzed health data according to an exemplary embodiment of the present disclosure. The method flowchart 700 may be implemented by the health data management system 100, the data analytics service 114, or any combination of components shown in FIG. 1. In an exemplary embodiment, a user (e.g., a hospital technician) may request a report on a case. For example, the user may access a web application (e.g., an online portal) and provide a unique case identifier. The web application may communicate the request to the health data management system 100. As per operation 710, the health data management system 100 may receive a request for a result report from the user through an HTTP protocol, where the request may provide the unique case identifier.

[0080] In one embodiment, the completed report may be stored in a database. The completed report may include a unique case identifier. In one embodiment, step 712 may include retrieving a results report corresponding to the received unique case identifier. In one embodiment, step 714 may include identifying patient privacy information associated with the completed report. For example, step 714 may include providing the unique case identifier to a patient privacy information data service (e.g., patient privacy information web service 116). Step 716 may include receiving patient privacy information associated with the unique case identifier. The patient privacy information may be encrypted. In one example, a user may provide a request including patient information that may be part of the patient privacy information. The database may identify a unique case identifier associated with the patient information, and the report associated with the unique case identifier may be retrieved. The report may then be associated with the corresponding patient privacy information. In one embodiment, step 718 may include decrypting the received patient privacy information, and step 720 may include updating the results report to include the decrypted patient privacy information.

[0081] Step 722 may include pushing the updated results report to the requesting entity. The updated results report may be sent to the requesting entity (e.g., step 722) using standard HTTP protocol and a web interface. In an alternative embodiment, the results report may be pushed to a hospital computing system (e.g., patient assessment system 106 or CT workstation 102) when the results report is completed. For example, the health data management system 100 may check the management service 112 for cases in a "Completed" state for which the report document has not yet been delivered. (The "Completed" state may indicate that the analysis has been completed and either a report has already been generated or a report may be generated based on the analysis results.) For all undelivered "Completed" cases, the health data management system 100 may download preconfigured reports or report settings (e.g., preferred report format or style as configured by the hospital or requesting entity). The results service 320 may wrap the PDF document based on the configuration, either as a DICOM encapsulated PDF object or as an HL7 message, and push the object (DICOM / HL7) to the appropriate preconfigured destination. The configuration is described in further detail in Figures 8A-8C. For example, in a scenario involving pushing a health data report to at least one of a hospital computing device, a hospital electronic record server, and / or a preconfigured destination network address, an HL7 standard message may be sent to at least one of the hospital computing device, the hospital electronic record server, and the preconfigured destination network address. The HL7 standard message may contain a uniform resource locator (URL) to the report.

[0082] In one embodiment, the health data management system 100 may act as an SCP service, receiving the report and storing it as an encapsulated PDF DICOM object. The health data management system 100 may then further issue a push command for a recipient to receive the report. If the health data management system 100 is configured to push the report to an HL7 engine / broker, the health data management system 100 may act as an HL7 client, sending the report as an HL7 message to the engine / broker or to a requesting entity (e.g., a hospital). In one embodiment, the health data management system 100 may further identify metadata associated with the completed report, such as insurance information, insurance plan coverage, report completion time, report priority, relationship of the analysis to a previous analysis, etc. Such metadata may be aggregated to inform use of the completed report by the requesting entity.

[0083] FIG. 8A is an exemplary flowchart 800 illustrating the deployment of the health data management system 100 in a customer network, according to an exemplary embodiment of the present disclosure. In an exemplary embodiment, the customer may include a clinic or a hospital, and the customer network may include a network operating within the clinic or hospital. The health data management system 100 may be deployed on the clinic / hospital machine. In an embodiment, the management service 112 may receive a request to download the health data management system 100 (e.g., step 802). For example, a site administrator may send a request to the data analytics vendor's management service 112 via a web interface to register a hospital as a customer of the vendor. The management service 112 may provide an installation (e.g., open virtual appliance or application (OVA)) file in response to the download request (e.g., step 804). In an exemplary embodiment, the OVA (open virtual appliance or application) file may be installed on a hospital computing device to establish the health data management system 100 infrastructure. The OVA file may be deployed into a virtual environment on the hospital computing device using a virtual machine (VMware) client. The OVA file may contain components such as an operating system (e.g., a customized CentOS Linux® distribution), the health data management system 100 software, and configuration details for the virtual hardware (e.g., RAM and CPU reservations and storage requirements, NIC (Network Interface Card) settings, etc.).

[0084] The administration service 112 may further provide the device identification and an activation key for the health data management system 100 to the site administrator in response to a request for activation of the health data management system 100 (e.g., steps 806 and 808). In one embodiment, the administration service 112 may provide the device identification and / or activation key via a web interface.

[0085] In one embodiment, the OVA file may be deployed within the hospital system and the health data management system 100 may be booted as a new virtual machine. The health data management system 100 may include a console accessible by a site administrator to configure network parameters, DICOM settings, communication ports for the health data management system 100, and to retrieve device identification and activation keys from the administration service 112. In an alternative embodiment, the activation key may be emailed to the site administrator to be entered while configuring the health data management system 100. In an exemplary embodiment, after deploying the OVA file, the site administrator may configure network parameters for the virtual machine, DICOM Application Entity (AE) titles, and communication ports to enable the CT scanner 104, CT workstation 102, and patient assessment system 106 to move DICOM studies to the health data management system 100 (e.g., step 810). In one embodiment, the administration service 112 may provide settings for configuration that may establish the health data management system infrastructure in the hospital.

[0086] In one embodiment, the site administrator may configure the CT scanner 104, CT workstation 102, and patient assessment system 106 with the health data management system 100 DICOM Application Entity (AE) title and communication port. In one embodiment, the administration service 112 may receive notification that the configuration is complete and the CT scanner 104, CT workstation 102, and patient assessment system 106 may move DICOM studies to the health data management system 100 (e.g., step 812).

[0087] In an exemplary embodiment, a hospital clinician or administrator may enter priorities for the DICOM objects using a web interface (e.g., step 814). In an alternative embodiment, the priorities may be set automatically according to the location of the hospital devices, DICOM object source CT scanner 104, CT workstation 102, or patient assessment system 106 within the hospital. The priorities may be transmitted to the management service 112 using the HTTP protocol. The management service 112 may store and maintain the priorities of the DICOM objects or case studies and may further provide result reports in order or urgency according to the priority.

[0088] 8B depicts a data flow 810 for installing the health data management system 100. As shown in step 1, a hospital site administrator 816 may request to download an OVA file containing the health data management system 100. The request may be received at a web interface 820 (e.g., of the management service 112 for the data analysis service 114). The hospital site administrator 816 may further request a device identification and an activation key as part of the installation process (step 2). The management service 112 may provide the OVA file, device identification, and activation key via the web interface 820.

[0089] In one embodiment (e.g., step 3), the hospital site administrator 816 may deploy the OVA file on a virtual machine server (e.g., virtual server 818). In an exemplary embodiment, step 4 may include deploying the health data management system virtual appliance 822 on the virtual machine host. In one embodiment, the deployment may include the hospital site administrator 816 selecting the virtual appliance 822 from a virtual machine client inventory menu, starting the virtual appliance 822, and initiating a virtual appliance machine console view. The hospital site administrator 816 may further configure the health data management system virtual appliance 822 to enable the health data management system virtual appliance 822 / health data management system 100 to receive health data from the CT scanner 104, the CT workstation 102, or the patient assessment system 106 (e.g., step 5).

[0090] In an exemplary embodiment, the health data management system 100 may be hosted on a Linux® 64-bit operating system. Upon start-up, a configuration menu may be displayed on the Linux® console. The console user's access may include menus to provide protection against misuse and reverse engineering of the health data management system 100. The menus may allow the user to configure the hostname and network parameters for the device, as well as its DICOM Application Entity (AE) title and communication ports.

[0091] 8C illustrates an exemplary web interface 830 once the health data management system 100 has been configured to receive files from a hospital computing device. For example, the interface 830 may include information corresponding to the patient 831 and information about the received file (e.g., CT DICOM object) 833. The interface 830 may further include information representing the status of the analysis 835 (e.g., whether the analysis is processing, completed, or stored (e.g., in "all cases"). The status 835 may also include analyses or reports that are of particular interest (e.g., "attention"). These analyses or reports may be flagged for medical professionals for deeper study or for future reference.

[0092] Thus, the present disclosure includes systems and methods for analyzing, storing, and managing patient health data in different geographic regions while protecting patient privacy data. The present disclosure further includes systems and methods for transmitting anonymous health data to an analytics cloud platform outside the hospital's region and receiving analysis result reports. Thus, data analysis can be provided across regions while avoiding the transfer of privacy data from one region to another.

[0093] Any of the described embodiments may be modified to include, for example, variations in data that may be kept within a region. The disclosed systems and methods may be modified to model and assess any range of changes to circulation. The program aspects of the technology may be considered as a "product" or "article of manufacture" typically in the form of executable code and / or associated data carried on or embodied in some type of machine-readable medium. "Storage" type media includes any or all of the tangible memory of a computer, processor, or equivalent, or its associated modules, such as various semiconductor memories, tape drives, disk drives, and the like, that may provide non-transitory storage at any time for software programming.

[0094] It should be understood that the health data management system 100 may include any type or combination of computing systems, such as handheld devices, personal computers, servers, clustered computing machines, and / or cloud computing systems. In one embodiment, the health data management system 100 may comprise an assembly of hardware including a memory, a central processing unit ("CPU"), and / or a user interface. The memory may include any type of RAM or ROM embodied in a physical storage medium such as a magnetic storage device, 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, including a floppy disk, a hard disk, or a magnetic tape. The CPU may include one or more processors for processing data according to instructions stored in the memory.

[0095] In one embodiment, a user may upload DICOM objects and read result reports using one or more wired or wireless devices. The devices may include any type of electronic device configured to collect, transmit, and / or receive data, such as websites and multimedia content, over a network. The devices may include medical devices, e.g., medical imaging devices, medical monitors, and the like. The devices may also include one or more mobile devices, smartphones, personal digital assistants ("PDAs"), tablet computers, or any other type of touch screen enabled device, personal computer, laptop, and / or server disposed within the communication network. The devices may each have a web browser and / or mobile browser installed to receive and display electronic content received from one or more of the web servers. The devices may include client devices, which may have an operating system configured to run a web or mobile browser and any type of application, e.g., a mobile application. In one embodiment, the various devices may be configured with a network adapter to communicate data or analyzed reports over a network. Alternatively or in addition, the various devices may be configured to transmit data or receive analyzed data over a local connection.

[0096] The functions of one or more processors associated with one or more cloud-based web services may be provided by a single dedicated processor or by multiple processors. Further, a processor may include, but is not limited to, digital signal processor (DSP) hardware, or any other hardware capable of executing software.

[0097] All or part of the software may be communicated from time to time through the Internet or various other telecommunications networks. Such communication may, for example, enable loading of the software from one computer or processor into another, for example, from a management server or host computer of a mobile communications network into a computer platform of a server, and / or from a server into a mobile device. Thus, other types of media that may bear software elements include optical, electrical, and electromagnetic waves, such as those used across physical interfaces between local devices, through wired and optical landline networks, and via various air links. Physical elements that carry such waves, such as wired or wireless links, optical links, or the like, may also be considered media that bear the software. As used herein, unless limited to non-transitory tangible "storage" media, terms such as computer or machine "readable medium" refer to any medium that participates in providing instructions to a processor for execution.

[0098] 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 as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.

Claims

1. 1. A computer-implemented method for managing cross-border health data while protecting patient privacy, the method comprising: receiving a DICOM object for analysis from a hospital computing device, the hospital computing device being provided within a first geographic region; generating a unique case identifier for the DICOM object; verifying the validity of the received DICOM object; anonymizing the validated DICOM object if the received DICOM object is valid based on the validating, wherein the anonymizing the validated DICOM object includes: extracting patient privacy information from the DICOM object, wherein the patient privacy information is removed from the validated DICOM object; determining a geographic location of the hospital computing device; identifying region-specific web services within the first geographic region, the first geographic region including the geographic location of the hospital computing device; and providing the extracted patient privacy information along with the unique case identifier to a web service specific to the identified region, the extracted patient privacy information being accessible only within the first geographic region; and updating the de-identified DICOM object to include the unique case identifier; compressing the updated DICOM object; providing the compressed DICOM object to at least one data analysis web service located within a second geographic region outside the first geographic region; A method comprising:

2. The computer-implemented method of claim 1 , wherein the unique case identifier is attached to one or more DICOM objects associated with a single case study.

3. The computer-implemented method of claim 1 , wherein validating the received DICOM object is based on a DICOM image size, an orientation of the DICOM image, or an image quality associated with the DICOM object.

4. The step of anonymizing the received DICOM object further comprises: encrypting the extracted patient privacy information; 2. The computer-implemented method of claim 1, wherein providing the extracted patient privacy information to the identified region-specific web service includes providing the encrypted patient privacy information with the unique case identification to the identified region-specific web service, the method further including maintaining the encrypted patient privacy information within the first geographic region.

5. The method of claim 1, further comprising: providing one or more network parameters associated with the hospital computing device to a web application firewall (WAF); 2. The computer-implemented method of claim 1, wherein identifying the domain-specific web service includes retrieving a network address of a domain-specific web service using a location-specific application programming interface (API) provided by the WAF service, and the identified domain-specific web service is the domain-specific web service associated with the retrieved network address.

6. receiving a request to download a health data management system onto the hospital computing device; providing an installation file for downloading the health data management system onto the hospital computing device; The computer-implemented method of claim 1 , further comprising:

7. configuring the health data management system to receive DICOM objects from at least one of a patient assessment system, a CT scanner, and a hospital workstation; receiving a priority of the DICOM objects via a web interface, the priority being based on the hospital computing device; updating the compressed DICOM object based on the received priority; The computer-implemented method of claim 6 , further comprising:

8. creating a virtual machine on the hospital computing device; extracting the installation file from a virtual machine client; activating the virtual machine; The computer-implemented method of claim 6 , further comprising:

9. 7. The computer-implemented method of claim 6, wherein configuring the health data management system further comprises configuring a host name, one or more network parameters for the hospital computing device, one or more communication ports, a DICOM application entity title, or a combination thereof.

10. receiving a request for a health data report in a defined format; retrieving the health data report from a storage entity using the unique case identifier; Retrieving patient privacy information associated with the unique case identifier; and decrypting the received patient privacy information; updating the retrieved health data report to include the decrypted patient privacy information; and pushing the health data report to at least one of a computing device, a hospital electronic record server, or a preconfigured destination network address; The computer-implemented method of claim 1 , further comprising:

11. 11. The computer-implemented method of claim 10, wherein the health data report is pushed as a International Health Level 7 (HL7) message, a DICOM file, or as a Portable Document Format (PDF) object.

12. The computer-implemented method of claim 1 , wherein the hospital computing device is at least one of a patient assessment system, an imaging modality, and a hospital workstation.

13. 1. A system for managing cross-border health data while protecting patient privacy, the system comprising: one or more data storage devices storing instructions for managing cross-border health data while protecting patient privacy; one or more processors, the one or more processors executing the instructions; receiving a DICOM object for analysis from a hospital computing device, the hospital computing device being provided within a first geographic region; generating a unique case identifier for the DICOM object; verifying the validity of the received DICOM object; anonymizing the validated DICOM object if the received DICOM object is valid based on the validating, wherein the anonymizing the validated DICOM object includes: extracting patient privacy information from the DICOM object, wherein the patient privacy information is removed from the validated DICOM object; determining a geographic location of the hospital computing device; identifying region-specific web services within the first geographic region, the first geographic region including the geographic location of the hospital computing device; and providing the extracted patient privacy information along with the unique case identifier to a web service specific to the identified region, the extracted patient privacy information being accessible only within the first geographic region; and updating the de-identified DICOM object to include the unique case identifier; compressing the updated DICOM object; providing the compressed DICOM object to at least one data analysis web service located within a second geographic region outside the first geographic region; one or more processors configured to perform a method including: A system comprising:

14. 14. The system of claim 13, wherein validating the received DICOM object is based on a DICOM image size, a positioning of the DICOM image, or an image quality associated with the DICOM object.

15. The system of claim 13 , wherein the hospital computing device is at least one of a patient assessment system, an imaging modality, and a hospital workstation.

16. receiving a request to download a health data management system onto the hospital computing device; providing an installation file for downloading the health data management system onto the hospital computing device; The system of claim 13 further comprising:

17. The system further comprises: configuring the health data management system to receive DICOM objects from at least one of a patient assessment system, a CT scanner, and a hospital workstation; receiving a priority of the DICOM objects via a web interface, the priority being based on the hospital computing device; updating the compressed DICOM object based on the received priority; The system of claim 16 configured to:

18. The system further comprises: creating a virtual machine on the hospital computing device; extracting the installation file from a virtual machine client; activating the virtual machine; The system of claim 16 configured to:

19. 1. A non-transitory computer readable medium for use on a computer system containing computer executable programming instructions for implementing a method for managing cross-border health data while protecting patient privacy, the method comprising: receiving a DICOM object for analysis from a hospital computing device, the hospital computing device being provided within a first geographic region; generating a unique case identifier for the DICOM object; verifying the validity of the received DICOM object; anonymizing the validated DICOM object if the received DICOM object is valid based on the validating, wherein the anonymizing the validated DICOM object includes: extracting patient privacy information from the DICOM object, wherein the patient privacy information is removed from the validated DICOM object; determining a geographic location of the hospital computing device; identifying region-specific web services within the first geographic region, the first geographic region including the geographic location of the hospital computing device; and providing the extracted patient privacy information along with the unique case identifier to a web service specific to the identified region, the extracted patient privacy information being accessible only within the first geographic region; and updating the de-identified DICOM object to include the unique case identifier; compressing the updated DICOM object; providing the compressed DICOM object to at least one data analysis web service located within a second geographic region outside the first geographic region; 16. A non-transitory computer readable medium comprising:

20. The method of claim 20, further comprising: providing one or more network parameters associated with the hospital computing device to a web application firewall (WAF) service to determine a geographic location of the hospital computing device; 20. The non-transitory computer-readable medium of claim 19, wherein identifying the domain-specific web service includes retrieving a network address of a domain-specific web service using a location-specific application programming interface (API) provided by the WAF service, and the identified domain-specific web service is the domain-specific web service associated with the retrieved network address.

Images