Cloud-based patient data exchange

Abstract

The present invention discloses a cloud-based patient data exchange. The present invention relates to a method for sharing a medical data set, which comprises the following steps: receiving a medical data set from a medical system (10); receiving association information from a database (20) separate from the medical system (10), wherein the association information provides information associated with the medical data set; uploading the medical data set to a cloud platform (40); processing the association information and the medical data set to identify one or more authorized users (50) who are authorized to access the corresponding medical data set; retrieving additional user information of the authorized user (50); and granting the authorized user (50) access to the corresponding medical data set in the cloud platform (40) based on the additional user information.

Description

Technical Field

[0001] The present invention relates to data processing technology, and in particular to cloud-based patient data exchange. Background Art

[0002] In recent decades, there has been a growing trend in the amount of digital data collected in healthcare. On the one hand, this is related to administrative data, and on the other hand, it is also related to medical data, such as test results or radiology images of patients.

[0003] To process this data, healthcare informatics relies on multiple information and storage systems that help and support clinicians and clinical staff. While databases such as hospital information systems (HIS), radiology information systems (RIS), clinical information systems (CIS), laboratory information systems (LIS) or cardiovascular information systems (CVIS) focus on the administrative needs of hospitals, storage and archiving medical systems such as picture archiving and communication systems (PACS) enable economical storage and convenient access to medical data.

[0004] Note that the different systems and databases used are usually separate from each other and usually rely on different standards and formats to store and forward data. For example, the standard established for transmitting data related to hospital information systems is HL7, while the common format for storing and transmitting PACS images is DICOM (Digital Imaging and Communications in Medicine). Therefore, even though the data streams from different systems and databases usually involve complementary information that must be combined in the clinical workflow, they are not easily compatible. For example, this complementary information may involve the patient's test results on the one hand, and information associated with the patient, such as billing information, the patient's health history, or information about the referring doctor on the other hand. Although the patient's test results are usually stored and transmitted in the form of dedicated medical data sets, the information associated with the patient is archived in a separate database in the form of associated information.

[0005] The architecture currently in use is adequate as long as each administrative unit (such as a hospital, imaging center, or radiology department) works with its own data. However, current systems often reach their limits when the need arises to transfer information outside of these organizations—for example, whenever a patient is referred to another doctor or another hospital.

[0006] One problem in this regard is that medical files are often subject to proprietary formats applied by a combination of equipment manufacturers and individual computer networks within an organization. Another problem relates to the inherent sensitivity of medical data, which makes medical entities often very reluctant to grant direct access to databases within their own control, as this would raise important patient privacy issues.

[0007] Furthermore, inherent incompatibilities in the data sources required to process efficient data transfer can cause problems. As mentioned above, databases used to store personal information such as address details or contact information (required to forward medical data to patients) often rely on different data standards than the systems storing the medical data sets to be forwarded. In other words, various different databases must be manually accessed to retrieve the information required to share the medical data sets.

[0008] Furthermore, the information on who has actually been authorized to use a given medical dataset is often scattered across different data sources. This may depend on the practices of a single organization, the case under consideration, or even on the authorizer itself. For example, the patient who is an authorized user can usually (but not necessarily) be derived from the medical dataset itself. In contrast, detailed information about, for example, referring physicians is often not included in the medical dataset. This makes any simple automated query difficult to implement and hinders integration with existing clinical workflows.

[0009] All of this has surprising consequences. Even today, medical data - and especially medical imaging data - is still exchanged physically in the form of digital memory storage media, such as CDs, DVDs or memory sticks. Summary of the invention

[0010] Therefore, it is an object of the present invention to provide means and / or methods that enable an improved way of sharing medical data with authorized users outside the clinical organization, such as referring physicians or the patients themselves. In particular, it is an object of the present invention to provide means and / or methods that enable seamless integration of the process into existing clinical workflows that are generally compatible with existing clinical hardware devices and software equipment.

[0011] The object is solved by a method for sharing a medical dataset, a corresponding system, a corresponding computer program product and a computer-readable storage medium.

[0012] In the following, the technical solution according to the present invention is described with respect to the claimed device and with respect to the claimed method. The features, advantages or alternative embodiments described herein can also be assigned to other claimed objects, and vice versa. In other words, the method of the present invention can be improved by the features described or claimed with respect to the device. In this case, for example, the functional features of the method are implemented by the target unit or element of the device.

[0013] According to a first aspect, a computer-implemented method for sharing a medical data set comprising several steps is provided. A first step involves receiving a medical data set from a medical system. A second step involves receiving association information from a database separate from the medical system, wherein the association information provides information associated with the medical data set. Another step involves uploading the medical data set to a cloud platform. Another step involves processing the association information and the medical data set to identify one or more authorized users who are authorized to access the corresponding medical data set. However, another step involves retrieving additional user information for the authorized user, which is different from the association information. Another step involves granting the authorized user access to the corresponding medical data set in the cloud platform based on the additional user information.

[0014] In other words, the concept of the present invention is to integrate at least two different data sources, namely the medical dataset and the associated information, and combine them with cloud technology to achieve an automated computer-implemented workflow for sharing the medical dataset with authorized users.

[0015] Medical data sets can be envisioned as test results that generally relate to patients. For example, these test results can include a medical image data set, which includes medical images acquired using a medical imaging modality. The medical imaging modality corresponds to a system for generating or producing medical images. For example, the medical imaging modality can be a computed tomography system, a magnetic resonance system, an X-ray system, an angiography (or C-arm X-ray) system, a positron emission tomography system, etc. In addition, medical images can be generated by digitally recording microscope images of tissue sections. Accordingly, the medical image can be a computed tomography image, a magnetic resonance image, an X-ray image, an angiography image, a positron emission tomography image, a digital pathology image, etc. The medical image data can be a two-dimensional, three-dimensional, or four-dimensional medical image, providing two and / or three dimensions in space, with or without additional dimensions in time. In addition to medical images, for example, the medical data set can relate to other examination results of the patient such as laboratory data, or to other personal test data of the patient.

[0016] A medical system may generally be configured to acquire and / or forward and / or store medical data sets. For example, a medical system may be implemented as a medical imaging system that includes one or more medical imaging modalities and / or one or more data storage and archiving systems for medical image data. A medical imaging system may include a picture archiving and communication system (PACS). As yet another example, a medical system may include equipment for acquiring laboratory test data of a patient and / or facilities for storing and archiving corresponding medical data sets. Furthermore, a medical system may include any combination of the above.

[0017] The associated information relates to data that is separated from or outside the medical data set and / or to data that is not included in the medical data set. The associated information contains information associated with the corresponding medical data set because the associated information is additional information or supplementary information that supplements the corresponding medical data set or corresponds to the corresponding medical data set. The associated information may be information that is not recorded in the medical data set, or information that does not exist at all in the medical data set for a specified variable. Therefore, the associated information may be management information related to medical, management, financial and legal issues. In addition, the associated information may contain the patient's health record, information about the workflow within the organization, information related to the outside of the organization, such as personal information of the referring doctor, or structured or unstructured diagnostic reports. The associated information may be provided in the form of electronic medical records (EMR), other electronic health records, electronic clinical pathways, patient identification records, diagnostic reports, similar patient studies, electronic laboratory reports, etc.

[0018] The association of associated information with a medical data set can be viewed as a structural association that electronically links these two data types. In other words, the medical data set and the associated information can be interconnected in the form of a unique identifier via a reference tag so that each medical data set is clearly associated with the corresponding associated information. The structural association can be implemented by a unique identifier (such as an electronic data identifier or any other suitable electronic tag). In addition, the unique identifier can include the patient's ID or accession number. The unique identifier can also include a hash of the aforementioned data and / or any combination thereof. The unique identifier is used as a link between the medical data set and the associated information. According to an embodiment, all medical data sets and associated information created for a specific patient in a clinical environment have the same unique identifier. Therefore, the association between a given medical data set and a given associated information can be established based on comparing or matching unique identifiers (i.e., corresponding electronic data identifiers or tags). In this regard, if the corresponding electronic data identifiers or tags correspond, match or are identical, then the association can be determined.

[0019] A database may generally be considered to be configured to generate and / or store and / or forward associated information. A database may relate to a medical information system such as HIS, RIS, LIS, CIS or any other information system for archiving and exchanging data and supplementary information associated with medical data.

[0020] A database being "separated" from a medical system may mean that the database relies on a different data format or data standard for storing and transmitting associated information than the medical system for storing and transmitting medical data sets, and / or that the database is physically separated from the medical system. For example, the physical separation of the database from the medical system may be implemented by different and / or independent local or extended storage systems and / or server systems for the database and the medical system. "Separation" may also mean that the medical system can neither directly access the database nor the database can directly access the medical system. In this regard, "no direct access" may mean that the database and the medical system cannot directly exchange information or actively query each other to retrieve information. To some extent, the above method can therefore be viewed as a computer-implemented connector or intermediary between the database and the medical system.

[0021] In other words, the step of receiving (medical data or associated information) can be equivalent to automatically receiving the corresponding message from the corresponding source (medical system or database), or monitoring the respective data streams from these sources by any computer system implementing the method. In addition, before the receiving step, the respective sources (medical systems and / or databases) can be optionally actively queried for the corresponding data (medical data sets and / or associated information).

[0022] Medical systems and databases can be considered to represent a local architecture within a given local environment, such as a clinical alliance, hospital, venue, or imaging center. A cloud platform may, for example, involve a central cloud server external to or remote from the local environment. The cloud platform is accessible to authorized web services via a cloud storage gateway and may include a group of real or virtual computers remote from the local environment. Alternatively, the cloud platform may be implemented as an externally accessible local exchange server within the local architecture of a given organization.

[0023] In the step of processing the associated information and the medical data set, each message can be automatically evaluated. Subsequent identification of one or more authorized users can include searching the received data packets to find prompts or instructions of one or more authorized users. Such a signature can include an explicit reference to the authorized users contained in the data. In addition or as an alternative, metadata such as headers or data tags of the medical data set and associated information can be searched. Similarly, data indicators or electronic tags representing the owner of the corresponding data, the relevant patient, or any other authorized person can be evaluated to identify the authorized user. For example, the data indicator can be a personnel number, a patient ID, or an account number. The electronic tag can be an abstract electronic data identifier indicating an authorized user.

[0024] In order to grant authorized users access to a medical dataset (and thus share a medical dataset), more is needed than just finding out who the authorized user actually is. First, the authorized user must be informed that a medical dataset has been uploaded to the cloud platform for him. In addition, it is determined how the user can access the cloud platform. For example, some users have a permanent account for the cloud platform, while others do not. Finally, means and information must be provided and forwarded to the user so that the user can access the corresponding medical dataset. For this reason, the method relies on additional user information, which is different from and additional to the identification of the authorized user alone. Therefore, once an authorized user or a group of authorized users is identified, auxiliary information related to the user (= additional user information) is automatically retrieved. This information is then used to automatically grant the identified authorized user access to the medical data uploaded to the cloud platform. Compared to the medical dataset and the associated information, the additional user information does not involve (or does not include any) medical information. Instead, the additional user information may include personal information about the authorized user, such as name, social security number, date of birth, address, telephone number, etc. Specifically, the additional user information may include information about the way in which the authorized user can access the cloud platform, such as whether the authorized user has a user account on the cloud platform.

[0025] In summary, the method steps outlined according to the first aspect facilitate the automatic data exchange of medical data between authorized users in a collaborative manner, thereby seamlessly integrating into the existing clinical workflow. Specifically, the method allows for the selective retrieval of all information required to share a medical data set with an authorized user. By integrating multiple separate data sources, the method automatically handles any inconsistencies in data records. For example, since all available information is integrated and processed to identify an authorized user, the method is effective regardless of which available data source (i.e., medical system or database) or in which instance of the clinical workflow the authorized user is recorded. Similarly, the autonomous retrieval of additional user information required for sharing medical data sets enables the method to be flexibly adapted to a variety of different workflows in a clinical environment. At the same time, the automatic processing and retrieval of information enables the method according to the first aspect to have high reliability and security. In addition, by including the automatic upload of medical data to a cloud platform, the method enables convenient access to medical data for authorized users. In addition, since the sharing process is performed via the cloud platform, the healthcare organization does not have to grant access to its local database itself, which helps to enhance data security.

[0026] For the step of granting access, additional user information for each uploaded medical data set and / or instructions of authorized users may be forwarded to the cloud platform. The step of granting access may then be performed (primarily) at the cloud platform. Alternatively, the cloud platform may also be configured to retrieve additional user information on its own (and then forward it to the cloud platform) based on the instructions of one or more authorized users. As yet another alternative, the step of granting access may be performed primarily locally (i.e., not at the cloud platform), wherein the necessary steps at the cloud platform are triggered, commanded, and controlled locally by appropriate systems such as local connection nodes.

[0027] According to an embodiment, the medical data set may be formatted according to a first communication standard (or in other words, may be formatted in a first standardized format), and the associated information may be formatted according to a second communication standard (or in other words, may be formatted in a second standardized format), wherein the first communication standard is different from the second communication standard (wherein, in other words, the first standardized format is different from the second standardized format). The standardized formats or communication standards may relate to proprietary formats or open standards for managing medical data sets and / or associated information.

[0028] By considering different standards (communication standards, standardized formats), the approach can be seamlessly integrated with existing clinical workflows, which often rely on different standards for medical datasets and corresponding associated information.

[0029] According to an embodiment, the medical data set may be formatted in DICOM format (as a first communication standard). In addition, the step of receiving the medical data may include receiving the medical data by using a dedicated DICOM Application Entity Topic (DICOM AET), which may be accomplished by assigning the DICOM AET to, for example, an interface for receiving the medical data set or any other means involved in putting the method steps into practice.

[0030] DICOM (= Digital Imaging and Communications in Medicine) is an open standard for the communication and management of medical imaging information and related data in healthcare informatics. DICOM can be used to store and transmit medical images, enabling the integration of medical imaging devices such as scanners, servers, workstations, printers, network hardware and Picture Archiving and Communication Systems (PACS). DICOM is widely adopted by clinical groups, hospitals and for smaller applications such as doctors' offices or institutions. DICOM data objects include several attributes, including items such as the patient's name, ID, etc., and also include a special attribute that contains the image pixel data. A single DICOM object can have only one attribute containing pixel data. For many modalities, this corresponds to a single image. However, the attribute can contain multiple "frames", enabling the storage of cine loops or other multi-frame data.

[0031] However, DICOM defines not only standards for data objects, but also entire communication standards that severely restrict the design of hardware components. DICOM files can be exchanged between two entities that are capable of receiving and / or processing images and patient data in DICOM format. Thus, in other words, the two entities are compatible with the DICOM format or represent so-called DICOM nodes. In the framework of the present invention, medical systems and systems for sharing medical data sets can be compatible with the DICOM format or can be DICOM nodes.

[0032] DICOM AE Topic or AET is an abbreviation for Application Entity Topic. An Application Entity (AE) (i.e., a DICOM node or DICOM compliant device) uses an AE Topic to identify itself in a network. DICOM AETs are locally unique and are typically managed by a system administrator. Therefore, by relying on DICOM AETs, communication according to the method may be simplified because medical data sets may be automatically forwarded to a computer-implemented method for further processing.

[0033] According to an embodiment, the association information may be formatted in the HL7 standard and / or the FHIR standard (as a second communication standard).

[0034] HL7 (Health Level Seven) specifies a set of flexible standards, guidelines and methods by which various devices in healthcare informatics (such as databases and / or workstations) can communicate with each other. HL7 differs from the DICOM standard in terms of underlying technology as well as application areas. While DICOM focuses on medical image data sets, HL7 is mainly used for management, such as in electronic patient records. Like DICOM, HL7 allows information to be shared and processed in a unified and consistent manner, and therefore enables easy sharing of clinical (medical) information. The FHIR (Fast Healthcare Interoperability Resources) standard is built on previous standards from HL7, and FHIR uses a web-based API technology suite. This means enhanced interoperability and support for a variety of devices from workstations to tablets to smartphones.

[0035] By relying on the DICOM standard and / or the HL7 standard and / or the FHIR standard, the method is compatible with commonly used formats and can be easily implemented in existing clinical workflows. Therefore, the distribution of a DICOM AET has the particular benefit that medical data sets can be automatically routed for further processing.

[0036] According to an embodiment, in the step of retrieving, the additional user information is extracted from the associated information, and / or the additional user information is retrieved from a database, and / or the additional user information is retrieved from a separate user data repository. In other words, the step of retrieving may include querying different data sources for the additional user information of each authorized user.

[0037] By considering these sources for retrieving additional user information, the method can ensure that the additional user information required to share medical image data with authorized users is actually available. This is because the additional user information required to share medical datasets with authorized users is usually scattered within the healthcare organization. One source may be the medical dataset itself. However, since the medical dataset is usually recorded before (or even long before) the data is shared, the medical dataset usually lacks additional user information except for only indicating the corresponding patient (via, for example, an accession number or patient ID). Therefore, since these information sources are related to the management of the healthcare organization, it is more likely to find additional user information in the associated information or the corresponding database. In addition to this, a separate user data repository can be considered. For example, such a user data repository can be implemented by a dedicated cloud address book. The user data repository can be separated from the medical system and / or database.

[0038] According to an embodiment, the additional user information includes an email address of the authorized user, a phone number of the authorized user, account information of the authorized user with respect to the cloud platform, an address of the authorized user, and / or any combination thereof.

[0039] The method may use the additional user information to find out how a particular authorized user can access the medical dataset (e.g., via an existing account). Likewise, the address information and contact information may be used to automatically contact the user and inform the user that the medical dataset has been uploaded to the cloud platform for him / her, and to communicate the specific process for accessing the medical dataset. In this regard, the additional user information is functional data for controlling the computer-implemented method for sharing a medical dataset. Therefore, the additional user information inherently reflects a feature of the method (and the claimed system).

[0040] According to an embodiment, the step of granting access may include the step of determining whether the authorized user has an account in the cloud platform based on the additional user information.

[0041] This has the benefit that the method can flexibly react to the respective requirements of some of the authorized users. While it can be assumed that professional healthcare providers (such as referring doctors / specialists or other hospitals) have permanent user accounts in the cloud platform, this is usually not the case for patients or family doctors. Therefore, the method automatically takes into account different ways for sharing medical datasets with different authorized users and is therefore more versatile when integrating it with existing workflows.

[0042] If the authorized user has a user account in the cloud platform, the method may optionally continue with the following steps: based on the additional user information, the authorized user is mapped to the user account of the authorized user in the cloud platform. If the authorized user does not have a user account in the cloud platform, the method may optionally continue with the following steps: creating a unique password for each authorized user, and / or generating a URL for each authorized user, using which the authorized user can access the corresponding medical data set in the cloud platform, and forwarding the URL to the authorized user.

[0043] According to an embodiment, the step of granting access comprises: mapping (or in other words, assigning) the authorized user to a corresponding user account of the authorized user in the cloud platform based on the additional user information, and enabling the authorized user to access the medical dataset via the account.

[0044] The mapping of additional user information to user accounts provides a convenient way for accessing shared data because it is built on existing infrastructure. In this regard, the step of making the medical dataset accessible may include providing an electronic link to the corresponding medical dataset in the user account, using which the authorized user can access or download the medical dataset when logged into his user account. Furthermore, since permanent accounts are usually assigned to users who have been formally authenticated, this step also contributes to the data security of the method.

[0045] Optionally, the method may comprise the step of communicating to authorized users that the medical data set has been assigned to their respective user accounts, eg via email or SMS (acronym for "Short Message Service"), etc. This increases the user-friendliness of the method.

[0046] According to an embodiment, the step of granting access may include: generating URLs for authorized users respectively, using the URLs to enable the authorized users to access corresponding medical data sets in the cloud platform, and forwarding the URLs to the authorized users based on additional user information.

[0047] By providing authorized users with a URL for accessing a medical dataset, the situation of authorized users lacking a permanent account to the cloud platform can be addressed - which may often be the case for patients or smaller institutions. In doing so, the method automatically addresses different ways for accessing the cloud platform and also eliminates manual intervention in routing information to the appropriate recipients. Specifically, there is no need to register authorized users in the cloud platform, which may be cumbersome for one-time access.

[0048] According to an embodiment, the step of granting access may include: creating unique passwords for the authorized users respectively; forwarding the unique passwords to the authorized users respectively based on the additional user information; and granting access to the medical datasets respectively after receiving the unique passwords from the authorized users.

[0049] Providing a unique password also contributes to the data security of the method, as this ensures that only authorized users have access to the medical dataset.

[0050] The steps of creating and forwarding a unique password and providing access after receiving the unique password from an authorized user can be combined with the aforementioned step of granting access via a user account or via providing a URL. For both situations, providing a unique password also increases data security.

[0051] As another alternative in this regard, the method may include using different communication channels for forwarding the URL to the authorized user on the one hand, or notifying the authorized user that the data has been mapped to his user account, and forwarding the password on the other hand. The different information channels may for example include email or SMS messages, telephone calls, messenger services, messages using a web client, or even postal messages and printouts. The corresponding contact data and preferred contact information may be retrieved from the additional user information.

[0052] According to an embodiment, the method may further include: extracting a unique identifier from the received medical data set, and associating corresponding association information with the medical data set based on the unique identifier.

[0053] Therefore, the unique identifier is used to identify the association information for the corresponding medical data set, or in other words, to match the corresponding medical data set with the corresponding association information.

[0054] In this sense, if the given medical dataset has the same unique identifier, the given medical dataset may match the association information. Thus, the step of associating may include: extracting the second unique identifier from the association information; and associating the association information with the corresponding medical dataset if the unique identifier and the second unique identifier correspond.

[0055] In other words, the process of matching a given medical dataset with associated information (associating associated information with the medical dataset) may include identifying all available associated information having the same unique identifier as the medical dataset in the data stream from the database and associating the information with the medical dataset.

[0056] The use of unique identifiers facilitates rapid identification of the correct associated information for a given medical dataset, thus improving the integrability of the method into existing workflows, making it easily scalable, and ensuring that all relevant authorized users are identified.

[0057] In practice, the unique identifier is typically provided by a registration number or patient ID assigned to each new patient entering a healthcare environment. However, as mentioned, the unique identifier may be any suitable electronic data identifier or electronic tag.

[0058] According to an embodiment, the method may include a step of determining whether the received medical dataset is to be shared with all or some of the authorized users. The step of determining may be based on the medical dataset, associated information and / or additional user information. Furthermore, the step of determining may include reading the medical image dataset, associated information and / or additional user information. In this regard, the method may read metadata as well as the body of the medical dataset, associated information and / or additional user information. Whether the received medical dataset is shared with all or some of the authorized users may be encoded in the medical dataset, associated information and / or additional user information in the form of an electronic identifier or tag, a data mark or text.

[0059] Optionally, if it is determined on this basis that the received medical data set is to be shared with authorized users, the method uploads the medical image data to the cloud platform. If not, the method does not do so.

[0060] This has the advantage that only these data are shared / uploaded to the cloud platform, which should actually be shared. This limits the data traffic and at the same time also improves data security.

[0061] According to an embodiment, the step of processing includes accessing and reading the association information to identify one or more authorized users from the association information, and accessing and reading the medical data to identify one or more authorized users from the medical data set.

[0062] Access to and reading of available data sets and information ensures that all authorized users are correctly identified, regardless of which database the corresponding authorization is recorded in. This facilitates the integration of the method into existing workflows.

[0063] According to an embodiment, the step of processing may include reading metadata (ie, the medical data set or associated information) of the received data packet, wherein the metadata may include a header and / or a specific electronic tag or identifier indicating an authorized user.

[0064] The method utilizes the processing and reading of metadata to identify authorized users, which takes advantage of the fact that data packages used in medical environments are standardized and usually include default metadata about the identity of the patient and / or referring physician or other authorized users (of which the DICOM standard is a prime example). This has the advantage that data processing is relatively fast. Attributes that can be used as metadata for identification can be, for example, patient name, patient ID, accession number, date of birth, gender, etc.

[0065] Additionally or alternatively, although this may typically be the case for patient reports, in particular if it is found that the received data packet is not provided in a standardized format, the processing step may also include reading the body or all of the received data packet (i.e. the medical data set and associated information). Furthermore, additionally or alternatively, the processing step may include reading text from the medical data set, the associated information and / or the additional user information. To this end, the method may rely on semantic search tools or text recognition algorithms, such as OCR (abbreviation for "optical character recognition"). The advantage is that all relevant information can be accessed for the shared medical data set.

[0066] According to an embodiment, the method may further comprise the step of: querying a database for associated information. Optionally, this step may be performed when the medical data set is received, or may be triggered by receiving the medical data set.

[0067] By actively querying the database for associated information, this method ensures that all information required to identify the authorized user is quickly retrieved.

[0068] Likewise, the process of querying the database for associated information may include determining a unique identifier from the medical data set and querying the associated information using the unique identifier. The unique identifier may be a patient ID or accession number, or any other suitable electronic identifier that uniquely identifies a patient case or clinical process.

[0069] The use of a unique identifier facilitates rapid querying of the database to obtain the correct associated information corresponding to a given medical data set. This therefore improves the integration of the method into existing workflows and ensures that all relevant authorized users are identified.

[0070] Depending on the implementation, authorized users may include the patient, referring physician, next of kin, parent or legal guardian or health insurance personnel and / or referring hospital.

[0071] By addressing this group of authorized users, the approach serves the primary recipients of shared medical datasets and provides a unified solution to several different needs, which makes the approach cost-effective and user-friendly.

[0072] According to another aspect, an alternative computer-implemented method having a plurality of steps is provided. A first step involves receiving a medical data set from a medical system. Another step involves uploading the medical data set to a cloud platform. Another step involves querying a database separate from the medical system to obtain association information, wherein the association information provides supplemental information associated with the medical data set. Another step involves processing the association information and / or the medical data set to identify one or more authorized users who are authorized to access the corresponding medical data set. Another step involves retrieving additional user information of the authorized user. Another step involves granting the authorized user access to the corresponding medical data set in the cloud platform based on the additional user information.

[0073] According to another aspect, a system for sharing a medical data set is provided. The system includes an interface unit configured to communicate with a medical system for receiving a medical data set, a database for receiving associated information, and a cloud platform for uploading a medical data set. Therefore, the database is separated from the medical system, and the associated information provides information associated with the medical data set. In addition, the system includes a computing unit configured to receive the medical data set and the associated information from the interface unit, to identify one or more authorized users based on processing the medical data set and the associated information, to retrieve additional user information of the authorized user, to upload the medical data set to the cloud platform via the interface unit, and to grant the authorized user access to the corresponding medical data set in the cloud platform based on the additional user information. Thereby, the authorized user is authorized to access the corresponding medical data set.

[0074] The system can be viewed as a connecting node or routing system that integrates and processes different data sources to automatically relay received medical datasets to authorized users for sharing.

[0075] The computing unit can be implemented as a data processing system or a part of a data processing system. Such a data processing system can, for example, include a cloud computing system, a computer network, a computer, a tablet computer, a workstation, etc. The computing unit can include hardware and / or software. The hardware can be, for example, a processor, a memory, and a combination thereof. The hardware can be configured by software and / or can be operated by software. Typically, all these potential units, subunits, or modules of the computing unit can, for example, be connected via a network or a corresponding interface at least temporarily exchange data with each other. Therefore, each unit can be spaced apart from each other to be positioned.

[0076] The interface unit may be configured to communicate via one or more connections or buses. The interface unit may be implemented in the form of separate physical interfaces, each providing a separate connection to a respective database, medical system or repository, and optionally relying on different network standards, such as (Ethernet, DSL, PPPoE, ISDN, ATM). Alternatively, the interface unit may be implemented as a (sole) gateway or interface to a network (such as an Ethernet port or a WLAN interface) to enable all necessary communications via the gateway or interface.

[0077] According to an embodiment, the system is assigned a specific destination address so that the medical image data can be automatically routed to the system. To this end, for example, a DICOM AET can be assigned to the system (or in other words, the system can include a DICOMAET).

[0078] This has the effect that medical data sets can be automatically routed to the system for further processing and ultimately shared with authorized users.

[0079] According to an embodiment, the computing unit is further configured to retrieve additional user information from the association information.

[0080] According to an embodiment, the computing unit is further configured to retrieve additional user information from the user data repository via the interface unit, wherein the interface unit is further configured to communicate with the user data repository to retrieve the additional user information. The user data repository may be separate from other data sources (i.e., medical systems and databases).

[0081] According to another aspect, an environment for sharing medical datasets is provided, the environment comprising the system for sharing medical datasets as introduced above and a medical system, wherein the medical system is configured to acquire and / or store and / or exchange medical datasets.

[0082] Then, an integrated system is provided that complements the functionality of the medical system with an automated process for sharing medical datasets. This enables rapid integration with existing clinical workflows.

[0083] According to an embodiment, the environment for sharing medical datasets further comprises a database and / or a user data repository.

[0084] According to another aspect, the invention relates to a computer program product comprising program elements which, when loaded into a memory of a computing unit, direct computing units of a system sharing a clinical data set to perform the steps of a method according to the invention.

[0085] According to another aspect, the invention relates to a computer-readable medium having stored thereon program elements which, when executed by the computing unit, can be read and executed by a computing unit of a system for sharing clinical data sets in order to perform the steps of the method of the invention.

[0086] Implementing the invention by means of a computer program product and / or a computer-readable medium has the advantage that already existing systems can be easily adapted by means of a software update to operate as proposed by the invention.

[0087] A computer program product may be, for example, a computer program, or may include another element adjacent to the computer program itself. The other element may be hardware, for example a storage device on which the computer program is stored, a hardware key for using the computer program, etc., and / or the other element may be software, for example documentation or a software key for using the computer program. The computer program product may also include development materials, a runtime system and / or a database or library. The computer program product may be distributed among several computer instances. BRIEF DESCRIPTION OF THE DRAWINGS

[0088] The characteristics, features and advantages of the present invention described above and the manner in which they are achieved become clearer and easier to understand according to the following description and embodiments described in detail in conjunction with the accompanying drawings. The following description does not limit the present invention to the embodiments included. In different drawings, the same components or parts may be marked with the same reference numerals. Generally, the drawings are not drawn to scale. In the following drawings:

[0089] Figure 1 A system for sharing medical datasets according to an embodiment is described, and

[0090] Figure 2 A method for sharing a medical dataset according to an embodiment is described. DETAILED DESCRIPTION

[0091] Figure 1 A system architecture 1 for sharing medical data sets according to an embodiment is depicted. The system architecture 1 or a portion of the system architecture 1 is configured to perform a method according to one or more embodiments of the present invention, for example, as described with reference to Figure 2 as described.

[0092] The system architecture 1 according to one or more embodiments may include a medical system 10, at least one database 20, a system for sharing medical data sets 30 (hereinafter referred to as a "connection node"), a cloud platform 40, and optionally at least one user data repository 60. The "system for sharing medical data sets" used in this context should not be interpreted as only referring to the device 30. Rather, the "system for sharing medical data sets" as used throughout this application may cover other component parts or devices of the system architecture 1, such as the medical system 10 and / or the database 20 and / or the cloud platform 40.

[0093] For example, the system architecture 1 includes a portion 2 (hereinafter also designated as "local environment 2"), which may be installed primarily locally in a clinical environment or medical environment, such as a clinical consortium (i.e., an association of two or more hospitals), a hospital, an imaging center, or a radiology institution. Other portions of the system architecture 1, such as a cloud platform 40, may be remote from local components.

[0094] exist Figure 1 In the example shown, the medical system 10, the database 20, the connection node 30 and the user data repository 60 are implemented locally in the local environment 2. The cloud platform 40 is remote from the local environment 2. However, this should not be interpreted as limiting the disclosure of the present invention. For example, components such as the database 20 or the user data repository 60 can also be obtained from the local environment 2 to a remote device. Conversely, the cloud platform 40 can also be installed locally at the local environment 2.

[0095] The various components of the system architecture 1 can be connected to each other at least temporarily for data transfer and / or exchange. The medical system 10 communicates with the connection node 30 via its interface unit 32 to transfer medical data sets. For example, the connection node 30 can be activated based on a request, wherein the request is sent by the medical system 10. The connection node 30 also communicates with the database 20 and the user data repository 60 via the interface unit 32. Likewise, the database 20 and the repository 60 can be activated based on a request, wherein the request is sent by the connection node 30.

[0096] Preferably, data transfer is achieved using a network connection. The network can be implemented as a local area network (LAN) such as an intranet, an Ethernet or a wide area network (WAN) such as the Internet. Preferably, the network connection is wireless, for example as a wireless LAN (WLAN or Wi-Fi). The network may include a combination of different network types.

[0097] The medical system 10 is typically configured to acquire and / or store and / or archive and / or forward medical data sets of a patient. For example, the medical data sets are explicitly associated with the patient by providing each medical data set with a unique identifier indicating the corresponding patient. The medical system 10 may be configured such that it cannot be accessed from outside the local environment 2. This may include the medical system 10 being configured such that it cannot be (directly) accessed by an authorized user 50.

[0098] For each medical data set, there is usually at least one authorized user 50 who is authorized to access the medical data set. Typically, the at least one authorized user 50 is the patient himself and / or his attending physician. However, in many cases, the medical data set has more authorized users 50 than the above. Other authorized users 50 may be referring or consulting doctors, specialists such as radiologists, next of kin, parents or legal guardians, or health insurance personnel. However, in most cases, not all of these authorized users 50 are recorded in the medical data set.

[0099] like Figure 1 The depicted medical system 10 is configured as a medical imaging system. The medical system 10 includes a medical imaging modality 11 for acquiring medical image data, such as a computed tomography system or a magnetic resonance system, an angiography (or C-arm X-ray) system, a positron emission tomography system, etc. In addition, the medical system 10 may include an archiving / reviewing station 12 for storing, archiving and reviewing medical data, such as a PACS. Storage includes occasional temporary storage of data and permanent storage in the sense of archiving.

[0100] Additionally, the medical system 10 may include a user interface 13 for inspecting, processing and / or forwarding medical image data sets. In addition to this, the medical image system 10 may include a router or node (not shown) for forwarding medical image data.

[0101] An alternative embodiment for the medical system 10 may include multiple imaging modalities 11 and multiple archive / examination stations 12. In order to interconnect the various components, the medical system 10 may include a network (not shown). According to an embodiment, the network includes a DICOM compatible network. DICOM is a network protocol located on top of TCP / IP. Messages according to the DICOM protocol include a header with metadata (e.g., including patient information) and information in the form of an image. DICOM allows interoperability between various medical systems and is capable of exchanging both image data and reports between systems. According to an embodiment, the imaging modality 11, the archive / examination station 12, and any other node in the medical system 10 are DICOM compatible devices, thereby making the medical system 10 such a DICOM compatible device.

[0102] The network connecting the medical system 10 to the connection node 30 may also comprise a DICOM compliant network. Thus, the connection node 30 may also be configured as a DICOM compliant device in the form of, for example, a DICOM node or a DICOM application entity having a DICOM application entity subject.

[0103] Alternative embodiments of the present invention may include multiple networks using different network protocols that may be the same as or different from DICOM. In this case, the DICOM Application Entity Subject would be any other suitable identifier for identifying a connecting node 30 in a network.

[0104] In the above, the medical system 10 has been described as a medical image system configured to acquire and / or archive and / or forward medical image data. However, this will be explained by way of example and not limitation. The medical data set may relate to medical image data, laboratory data of a patient, patient records, diagnostic reports, clinical studies, etc. and combinations thereof. Accordingly, components of the medical system 10 may be configured to acquire and / or archive and / or forward the data.

[0105] The database 20 is configured to generate and / or store and / or exchange association information associated with a patient's medical data set. According to an embodiment, the database 20 is a part of a hospital information system (HIS), a radiology information system (RIS), a clinical information system (CIS), a laboratory information system (LIS) and / or a cardiovascular information system (CVIS). The database 20 can be configured so that it cannot be accessed from outside the local environment 2. This can include that the database 20 is configured so that it cannot be (directly) accessed by an authorized user 50. The association information managed by the database 20 may involve supplementary management information corresponding to the corresponding patient. As an alternative or in addition, the association information may be related to the health record or health history of the corresponding patient. Therefore, the association information in one way or another can provide instructions about the authorized user 50 for the corresponding situation.

[0106] In addition to this, the association information may contain additional user data, such as contact information for the authorized user 50 mentioned in the association information.

[0107] As with the medical dataset, the associated information explicitly relates to the patient. This can be provided electronically by a unique identifier, which is preferably the same as the identifier used for the medical dataset. For example, such a unique identifier can be embodied by a patient and / or case accession number or a patient ID such as the patient's social security number.

[0108] The database 20 may be implemented as a cloud storage. Alternatively, the database 20 may be implemented as a local storage or an extended storage. The database 20 may include a plurality of separate repositories and a user interface (not shown) for generating, checking and / or processing associated information, such as a workstation for generating a diagnostic report or managing a patient's electronic medical record. Like the medical system 10, the database 20 may include a network compatible with a specific standard, which is used to interconnect the various components of the database 20 and facilitate data exchange. According to an embodiment, the network may be a network compatible with the HL7 standard and / or the FHIR standard.

[0109] Optionally, the local environment 2 may include another user data repository 60 for storing additional user information for some or all users registered in the environment. The database 20 and the repository 60 may also be combined in a database that includes (archived) associated information and additional user data. According to an embodiment, the repository 60 may be conceived as an electronic address book. Compared to associated data, there is no clear relationship between additional user information and medical data sets, and additional user information is linked to a specific case by a fixed association in a dedicated electronic identifier or similar form. Additional user information such as stored in the repository 60 can usually only be retrieved based on a user name. The user data repository 60 may be implemented as a cloud storage. Alternatively, the user data repository 60 may be implemented as a local storage or an extended storage. In addition, the user data repository 60 may reside outside the local environment 2 and, for example, be provided in the form of an external cloud service.

[0110] The database 20 and the user data repository 60 may be continuously and / or updated on a daily or weekly basis. In parallel, once a workflow within a local environment (such as a patient examination within a hospital) is completed, the database 20 may be updated with new entries.

[0111] The network connecting the database 20 and the connection node 30 may include an HL7 and / or FHIR compliant network. As an alternative or in addition, the network may support any other communication standard for exchanging data between the connection node 30 and the database 20. The same applies to the network connecting the connection node 30 with the user data repository 60.

[0112] The connection node 30 may include a processor 31 and an interface unit 32 for data exchange. The interface unit 32 may include various interfaces configured to communicate with various components of the system architecture 1. Alternatively, the interface unit 32 may be configured as a unified interface configured for data exchange with all components of the system architecture 1. The interface for data exchange may be implemented as a hardware interface or a software interface, such as a PCI bus, a USB, an Ethernet connection, or a FireWire.

[0113] The processor 31 may include hardware components or software components, such as a microprocessor or an FPGA (field programmable gate array). The processor 31 is configured to execute the Figure 2 The steps of the method are described.

[0114] The cloud platform 40 may be a central cloud server that is accessible to authorized Web services for authorized users 50. Access may be granted via a dedicated user account or via a one-time login. The cloud platform 40 may include a real or virtual computer group. The cloud platform 40 may be located outside of the local environment 2, such as Figure 1 However, alternatively, the cloud platform 40 can also be implemented as an externally accessible local exchange server inside the local environment 2.

[0115] While the network components connecting the connection node 30 to other (preferably locally installed) system components (such as the medical system 10 or the database 20) are typically bidirectional and enable communication in both directions between the interconnected components, the network connection to the cloud platform 40 may be unidirectional, in that uploading data to the cloud platform 40 is possible, but access from the cloud platform 40 to other components of the local environment 2, for example via the connection node 30, is restricted, denied, and / or not immediately possible. Note that the system architecture 1 may be configured such that the cloud platform 40 is only connected to the connection node 30, and not to other components of the local environment 2.

[0116] The computing unit of the present invention for sharing medical data sets may include a processor 31 of a connection node 30. Thus, at least part of the method of the present invention may be run on the processor 31 of the connection node 30. Furthermore, the computing unit may include additional subunits (not shown) dispersed in the system architecture 1. Such subunits may reside in the medical system 10, the database 20, the user data repository 60 or other components of the local environment 2, for example in the form of a microcontroller, an integrated circuit or a real or virtual group of computers such as a so-called "cluster" or "cloud". In addition, subunits of the computing unit may also reside in components external to the local environment 2, such as in a cloud platform 40.

[0117] Similarly, the interface unit of the present invention may include an interface unit 32 connecting the node 30, but the interface unit of the present invention may also include other interfaces linked to it in other components, such as interfaces at the medical system 10, the database 20, the user data repository 60 or the cloud platform 40.

[0118] According to one embodiment, the system of the present invention can therefore be implemented by a connection node 30 comprising only the interface unit 32 and the processor 31 of the connection node 30. However, according to other embodiments of the present invention, the system can also include additional components, such as part or all of the medical system 10, the database 20, the user data repository 60 or the cloud platform 40.

[0119] Figure 2 is a flow chart depicting a method for sharing a medical data set according to an embodiment. The method comprises several steps. The order of the steps does not necessarily correspond to the numbering of the steps and / or the order of the steps depicted, but may also vary between different embodiments of the invention.

[0120] The first step S110 involves receiving a medical data set by a connection node 30. The medical data set may be automatically or manually sent to the connection node 30 by a user such as a radiologist or technician. For this purpose, a suitable network identifier, such as a network address, or in the case of a DICOM compliant network, a DICOM application entity subject may be provided to the connection node 30. In other words, the connection node 30 is configured to listen to the data stream from the medical system 10 and receive the medical data set sent to the address of the medical system 10 in the network.

[0121] Any medical data set relayed to the connecting node 30 will be automatically further processed by the subsequent steps S120 to S160.

[0122] In order to share the medical dataset with the authorized user 50, in step S120, the connection node 30 can be configured to upload the medical dataset to the cloud platform 40. Optionally, step S120 may include the following steps: based on the upcoming intermediate dataset, first determine whether a specific medical dataset is to be shared with the authorized user 50. Preferably, this optional step is performed before uploading the corresponding medical dataset to the cloud platform 40. To this end, the medical dataset can be read and checked for a suitable electronic identifier ("shared tag") indicating that the corresponding medical dataset is to be shared. If this is the case, the method proceeds with uploading the medical dataset to the cloud platform 40 according to step S120. Such a shared tag can be set, for example, by a user (e.g., a radiologist or technician) and can be encoded in the header of the medical dataset.

[0123] In parallel with monitoring the data stream from the medical system 10, the connection node 30 is configured to monitor the data stream from the database 20 to receive information associated with the corresponding medical data set (step S130). The received associated information can then be matched with the corresponding medical data set. For example, this can be done by reading a unique electronic identifier (such as a patient ID or accession number) indicating a specific case or patient from the associated information and the medical data set, and comparing the unique identifier. Optionally, step S130 may include the step of actively querying the database 20 for the associated information corresponding to the corresponding medical data set. This optional step can also be performed using a unique identifier, for example, by reading one or more unique identifiers from the corresponding medical data set and querying the database 20 for associated information having the same unique identifier. In order to read the unique identifier, in step S130, the connection node 30 can be configured to look at the header or associated information of the medical data set.

[0124] In step S130, the aforementioned optional assessment of whether the medical data set is to be shared with the authorized user 50 may also be included. To this end, the association information may be read and checked for a "shared flag" indicating that the associated medical data set is to be shared. If this is the case, the method (system / connection node 30) proceeds with uploading the medical data set to the cloud platform 40. For example, the shared flag may be set during the management workflow and may be encoded in the association information.

[0125] In step S140, the medical dataset and / or the associated information are further processed to identify one or more users 50 authorized to access the corresponding medical dataset from the medical dataset and / or the associated information. Mainly, it is usually a patient who is authorized to access his own medical dataset. Information about the patient may be contained in the header of the medical dataset, as well as other metadata about the data source (which system the image data comes from), the anatomical type corresponding to the image data (e.g., chest, abdomen, head), and the anatomical view of the image data (e.g., back, front, side). Therefore, the connection node 30 can be configured to view the header of the medical dataset to identify the authorized user 50. Since the indication related to the authorized user 50 may also be hidden in the body of the medical dataset, the connection node 30 can also be configured to search the entire medical dataset, for example by relying on semantic search tools or optical character recognition (OCR). Although it can be assumed that the patient (as the authorized user 50) can be derived from the medical image data, it is much less likely that all other authorized users are also recorded in the medical dataset. This is because other authorized users 50, such as other specialists, usually only come into play after the medical data set has been recorded or the medical data set is not systematically recorded in the medical data set at all (usually the case for referring doctors). Usually, the information is recorded in the electronic patient record as an example of associated information, but not in the medical data set. Therefore, the connecting node 30 can also be configured to search the associated information to find (additional) authorized users 50. As in the case of processing medical data sets, the system can be configured to look in the header (if any) and in the body of the associated information.

[0126] Although processing both the medical dataset and the associated information may be beneficial, this is not mandatory in order to ensure that all authorized users 50 are correctly identified. It should be noted that the method can also be put into practice by only reading (processing) the medical dataset or the additional information for identifying the authorized users 50. Whether this is feasible depends on the specific requirements and circumstances in the local environment 2. For example, if the hospital keeps a complete record of all authorized users 50 in the associated information, then it is sufficient to evaluate only the associated information. In addition, if the medical dataset only needs to be shared with patients (and assuming that this information is systematically recorded in the medical dataset), it may be sufficient to only process the medical dataset to identify the authorized users 50 (without considering the associated information at all).

[0127] Once the authorized user 50 is identified, the system is configured to retrieve additional user information of the authorized user 50 in step S150. The additional user information is then used to grant the authorized user 50 access to "their" medical data set in the cloud platform 40 (step S160), and finally complete the processing of the shared medical data set. Because it is usually impossible to forward the medical data set based solely on the instructions of the authorized user 50, additional user information is required. Instead, the system needs additional user information to do so. The additional user information may include the email or postal address of the authorized user 50, whether the authorized user 50 has an account for the cloud platform 40 and what the account details are if the authorized user 50 has an account for the cloud platform 40, the authorized user's phone number, the preferred notification method, etc. Such additional user information may be recorded in the medical data set. However, this is unlikely. A better source of information in this regard is the association information in which data related to the management of the hospital is recorded. Therefore, the system can be configured to retrieve additional user information by processing (i.e., reading or searching) the association information. As an alternative or in addition, the connection node 30 can be configured to retrieve additional user information from one or more separate user data repositories 60 (such as an electronic address book). To this end, the connection node 30 can be configured to query the user data repository 60 based on the name or any other suitable identifier for the authorized user 50.

[0128] In step S160, the additional user data is used to grant the authorized user 50 access to the respective medical dataset in the cloud platform 40. This may involve transmitting information about the authorized user 50 for the respective medical dataset to the cloud platform 40. This may involve determining whether the authorized user 50 has an account with the cloud platform 40. If this is the case, the respective medical dataset is linked to the respective user account of the authorized user 50 and the respective medical dataset is made accessible to the authorized user 50 via the user account. In addition, the authorized user 50 may be communicated, for example, via email or SMS, that a new medical dataset has been uploaded to his account.

[0129] If the authorized user 50 does not have a user account in the cloud platform 40, temporary access to the cloud platform 40 can be generated for the authorized user 50 via the user portal of the cloud platform 40. To this end, the authorized user 50 can be provided with a URL for accessing the medical data via the user portal. For example, the URL can be sent to the authorized user 50 via email.

[0130] In addition, the step S160 of granting access may include generating a password for accessing the respective medical data set and forwarding the password to the authorized user 50. If the authorized user 50 wants to access the medical image data, they may then be asked to insert the respective password. After receiving the password, the system may be configured to check whether the password entered by the authorized user 50 matches the generated password. If the password entered by the authorized user 50 matches the generated password, the authorized user 50 is granted access to the medical data set. Preferably, the password is forwarded to the authorized user 50 using a communication channel different from that used to notify the authorized user 50 that new content has been assigned to the respective cloud storage account and / or used to forward the URL for temporary access.

[0131] As combined Figure 1 and Figure 2 As indicated, the steps S140 of processing and S150 of retrieving additional user information are preferably performed locally at the connection node 30. The step S160 of granting access is also mainly performed at the connection node 30. The actions naturally performed at the cloud platform 40 (such as the receipt and cross-checking of passwords, the actions of linking medical image data to user accounts, etc.) can be initiated and controlled by the connection node 30. This may involve forwarding all relevant information and corresponding instructions required for these actions by the connection node 30 to the cloud platform 40. This involves information about authorized users 50, information about user accounts, information about preferred access methods, etc. In other words, the retrieved additional user information can be forwarded to the cloud platform 40. As an alternative, only the instructions about the authorized users 50 can be forwarded to the cloud platform 40, and the cloud platform 40 can be adapted to retrieve additional user information about its own actions, for example by accessing a separate user data repository linked to the cloud platform 40. In such a case, steps S150 and S160 will be mainly performed at the cloud platform 40. As yet another intermediate alternative, only step S160 may be mainly performed at the cloud platform 40 based on the results of step S140 and step S150 forwarded by the connecting node 30 to the cloud platform 40 .

[0132] In the following, two exemplary workflows for sharing medical data sets according to embodiments are described. The following will be explained by way of example rather than limitation of the present disclosure. For ease of reference, several (optional) steps as described above are omitted (but may also be integrated into the examples). In addition, the various steps of the following examples may also be combined with each other.

[0133] For example, the first exemplary workflow involves sharing a medical data set with an authorized user 50 having an account in the cloud platform 40, which is typically the case for a referring physician. Furthermore, it is assumed that the medical data set is formatted in DICOM format and associated information is retrieved from a HIS / RIS system over a network communicating in HL7 format.

[0134] In these cases, in simple terms, sharing a medical data set uploaded to the cloud platform 40 with a referring physician (as an authorized user 50) can be accomplished by automatically mapping the referring physician mentioned in the medical data set to his / her user account using the cloud platform 40. In this regard, the physician's email address can be used to link the referring physician's identity within the hospital to his / her user account in the cloud platform 40. More specifically, this can be translated into the following steps:

[0135] a) The radiologist or technician sends the medical data set (in the form of DICOM data) to the locally installed connection node 30, where the medical data set is received (according to step S110 as defined above). For this purpose, the connection node 30 provides a DICOM application entity topic, which can be configured as a sending destination in each PACS, scanner or DICOM node. Relying on a dedicated DICOM application entity topic enables the method to automatically receive the medical data set.

[0136] b) The medical dataset is uploaded to the cloud platform 40 (according to step S120 as defined above).

[0137] c) In parallel, the connecting node 30 intercepts the HL7 and / or FHIR data streams in the hospital from the HIS / RIS, thereby receiving the associated information corresponding to the medical data set (according to step S130 as defined above).

[0138] d) Reading the referring physician from the DICOM header of the uploaded medical dataset and / or from the associated HL7 message having the same accession number as the DICOM medical dataset (according to step S140 as defined above).

[0139] e) Reading the referring physician's email address and so-called additional user information from the associated HL7 ADT message, or if the associated HL7 ADT message is not available, from the user data repository 60 (according to step S150 as defined above).

[0140] f) Mapping the referring doctor's email address to the referring doctor's account in the cloud platform 40, and sharing the medical dataset with the referring doctor's account in the cloud platform 40 (according to step S160 as defined above).

[0141] For the second example, it is assumed that the authorized user 50 is a patient who does not have a user account in the cloud platform 40. Although points a) to c) correspond to the first example, points d) to f) are slightly adjusted as follows.

[0142] d) Identify the patient's attributes, such as reading the patient's name, patient ID, date of birth, gender, etc. from the DICOM header of the received medical data set and / or from the associated information in the form of HL7 and / or FHIR data streams in the hospital from the HIS / RIS (according to step S140 as defined above).

[0143] e) Reading the patient's email address from the associated HL7 ADT message, or if the associated HL7 ADT message is not available, from the cloud address book (according to step S150 as defined above).

[0144] f) A unique password for the sharing activity is created and forwarded to the patient. In addition, a link (such as a URL) to the medical data set is generated and likewise forwarded to the patient. This is done via email. The unique password is provided via another communication channel other than email to the patient, for example, via SMS to the patient's phone number, or a printout given to the patient at the hospital. The patient can then access his medical data set by using a patient portal to the cloud platform 40. The patient portal can only be accessed using a specific link (URL) and by a unique password (according to step S160 as defined above).

[0145] When the corresponding computer program product is loaded into the memory of the computing unit (processor 31), the method steps S110 to S160 can be performed together with their optional or alternative extensions as described above. The calculation can be localized because the program runs on a dedicated local processor, for example in a connection node 30 optimized for a specific purpose. Alternatively, the program can be run locally on a cluster of subunits within a local server or local environment 2. Finally, in particular, if at least part of the program is related to the details of granting access to a medical data set uploaded to the cloud, at least part of the program can also be executed in the cloud platform 40. In this regard, the processor or computing subunit inside the local environment can prompt the external component to perform the corresponding method steps.

[0146] Individual embodiments or their individual aspects and features may be combined or exchanged with one another as far as makes sense, without limiting or expanding the scope of the invention. Where applicable, the advantages described with respect to one embodiment of the invention also apply to other embodiments.

[0147] The following points are also part of this disclosure:

[0148] 1. A computer-implemented method for sharing a medical data set, the method comprising the following steps:

[0149] - receiving a medical data set from a medical system;

[0150] - receiving association information from a database separate from the medical system, wherein the association information provides information associated with the medical data set;

[0151] -Uploading the medical data set to a cloud platform;

[0152] - identifying one or more authorized users by processing the medical data set and the associated information, the authorized users being authorized to access the corresponding medical data set;

[0153] - Retrieve additional user information for said authorized user;

[0154] - Based on the additional user information, the authorized user is allowed to access the corresponding medical data set in the cloud platform.

[0155] 2. The method according to 1 further comprises the following steps:

[0156] For the received medical data set, determining whether the received medical data set should be shared with all or part of the authorized users based on the medical image data, the associated information and / or the additional user information; and

[0157] Wherein, in the uploading step, the uploading of the medical dataset is performed only when it is determined that the medical dataset should be shared with the authorized user.

[0158] 3. The method according to any of the preceding points, wherein, in the step of uploading, the medical dataset is uploaded only if at least one authorized user has been identified for the corresponding medical dataset.

[0159] 4. The method according to any of the preceding points, wherein the step of processing comprises:

[0160] accessing and reading the association information to identify one or more authorized users based on the association information; and

[0161] The medical data set is accessed and read to identify one or more authorized users based on the medical data set.

[0162] 5. The method according to any of the preceding points, wherein the step of processing comprises:

[0163] Metadata contained in the medical dataset and / or the associated information is read.

[0164] 6. The method according to any of the preceding points, further comprising the following steps:

[0165] After receiving the medical data set, the database is queried for the associated information.

[0166] 7. The method according to any of the preceding points, further comprising the following steps:

[0167] The medical data set is associated with the corresponding association information.

[0168] 8. The method according to any of the preceding points, further comprising the following steps:

[0169] extracting unique identifiers respectively from the medical datasets; and

[0170] Based on the unique identifier, the database is queried for the associated information.

[0171] 9. The method according to any of the preceding points, wherein the association information is formatted according to the HL7 and / or FHIR standards.

[0172] 10. The method according to any of the preceding points, wherein the step of receiving the medical data set comprises receiving the medical data set via an interface, wherein the interface is assigned an identifier, in particular a DICOM Application Entity Subject.

[0173] 11. The method according to any of the preceding points, wherein:

[0174] The authorized users include patients, referring physicians and / or referring hospitals or institutions.

Claims

1. A computer-implemented method for sharing a medical dataset, the method comprising the steps of: - receiving (S110) a medical data set from a medical system (10) via an interface unit (32) of a Digital Imaging and Communication in Medicine DICOM node, the DICOM node being separate from the medical system (10), the database (20) and the cloud platform (40), and the medical data set being formatted according to the DICOM standard; - extracting a unique identifier from the medical data set by a processor (31) of the DICOM node; - the processor (31) identifies, in a data stream received from the database (20), association information having the same unique identifier as the medical data set and associating the association information with the medical data set, wherein the database (20) is separate from the medical system (10) and the cloud platform (40), the association information provides information associated with the medical data set, and the association information is formatted according to at least one of the Health Level Seven (HL7) standard or the Fast Healthcare Interoperability Resources (FHIR) standard; - uploading (S120) the medical data set to the cloud platform (40) via the interface unit (32); - processing (S140) the association information and the medical data set by the processor (31) to identify one or more authorized users (50), the one or more authorized users (50) being authorized to access a corresponding medical data set in the medical data set, the corresponding medical data set having the same unique identifier as the association information; - retrieving (S150) by the processor (31) additional user information of the one or more authorized users (50); and - The processor (31) permits (S160) the one or more authorized users (50) to access the corresponding medical data set in the cloud platform (40) based on the additional user information.

2. The method according to claim 1, wherein: In the step of searching (S150): - extracting the additional user information from the associated information, and / or - retrieving said additional user information from said database (20), and / or - retrieving said additional user information from a separate user data repository (60).

3. The method according to claim 1, wherein: The additional user information includes: - email addresses of said one or more authorized users (50), - the telephone number of said one or more authorized users (50), - account information of the one or more authorized users (50) in the cloud platform (40), - the address of the one or more authorized users (50), -and / or any combination thereof.

4. The method according to claim 1, wherein: The step of granting access (S160) includes: - mapping the one or more authorized users (50) to corresponding accounts of the one or more authorized users (50) in the cloud platform (40) based on the additional user information; and - enabling said one or more authorized users (50) to access said respective medical data set via said respective account.

5. The method according to claim 1, wherein: The step of granting access (S160) includes: - Determining whether the one or more authorized users (50) have a corresponding account in the cloud platform (40) based on the additional user information.

6. The method according to claim 5, wherein: The step of granting access (S160) includes: - generating one or more URLs for the one or more authorized users (50), respectively, by means of which the one or more authorized users (50) can access the corresponding medical data set in the cloud platform (40); and - forwarding the one or more URLs to the one or more authorized users, respectively, based on the additional user information (50).

7. The method according to claim 5, wherein: The step of granting access (S160) includes: - creating a unique password for each of the one or more authorized users (50), - forwarding the unique password to the one or more authorized users (50) based on the additional user information; and - upon receiving the unique password from the one or more authorized users (50), granting access to the corresponding medical data set in the cloud platform (40).

8. A system for sharing medical datasets, comprising: - an interface unit (32) of a Digital Imaging and Communications in Medicine DICOM node, configured to communicate with: Medical system (10); A database (20) separate from the medical system (10) and the cloud platform (40); as well as The cloud platform (40); Wherein, the system further comprises: - a processor (31) of the DICOM node, the DICOM node is separated from the medical system (10), the database (20) and the cloud platform (40), and the processor (31) is configured to: receiving a medical data set from the medical system (10) via the interface unit (32), wherein the medical data set is formatted according to the DICOM standard; Extracting a unique identifier from the medical dataset; identifying association information having the same unique identifier as the medical data set in the data stream received from the database (20) and associating the association information with the medical data set, the association information providing information associated with the medical data set and the association information being formatted according to at least one of the Health Level Seven (HL7) standard or the Fast Healthcare Interoperability Resources (FHIR) standard; Uploading the medical data set to the cloud platform (40) via the interface unit (32); processing the medical data sets and the associated information to identify one or more authorized users (50) who are authorized to access a corresponding medical data set in the medical data sets, the corresponding medical data set having the same unique identifier as the associated information; · retrieving additional user information for the one or more authorized users (50); and · Granting the one or more authorized users (50) access to the corresponding medical data set in the cloud platform (40) based on the additional user information.

9. The system according to claim 8, wherein: The system includes a DICOM application entity subject.

10. An integrated system for sharing medical datasets, comprising: - A system according to any one of claims 8 or 9, and - the medical system (10), the medical system (10) being configured to acquire and / or store and / or transmit the medical data set.

11. A computer program product comprising program elements which, when loaded into a memory of a computing unit of a system for sharing medical data sets, direct the computing unit to perform the steps of the method according to any one of claims 1 to 7.

12. A computer-readable medium having program elements stored thereon, which, when executed by a computing unit of a system for sharing medical data sets, can be read and executed by the computing unit in order to perform the steps of the method according to any one of claims 1 to 7.

Images