DE202017006793U1 - Dynamic creation of overview messages in the healthcare sector - Google Patents

Abstract

A central broker node (OBS) for performing a broker service for servicing a client (CL) request for a patient summary message (u) based on a standardized platform, comprising: - a broker input interface (IB) associated with Receiving (S20) the request (to) of the client (CL), - a broker extraction interface (EIN) intended for reading in an extraction message (s), - a processing unit (V) capable of resolving (S21) the received request (an) and for determining a client identifier and determining the parameters of the requested summary message (u) is determined - and wherein the processing unit (V) is further intended for access (S22) to a database (DB) to those extraction messages and the processing unit (V) is further intended for access (S23) to a central registry (XDS-REG) to check on the basis of the determined client identifier an existing authorization of the client (CL) for accessing the respective document, in which the respective parameter of all aggregated extraction messages (s) is contained and wherein the processing unit (V) in the case of existing authorization for inserting (S24) the respective parameter into the overview message (uen) and for creating (S25) the overview message (uen).

Description

The present invention relates to methods and system for generating a summary message for a patient based on a standardized platform.

The medical or health-related data of a patient are generated in different institutions, such as clinics and institutes. They are thus present in distributed form (locally). The respective facilities are usually networked. The data is increasingly digitally captured or at least stored in digital form.

In order to improve a quality of treatment for the patient and to increase the safety of the treatment, it is desirable that the exchange of data between the different distributed devices be improved. This also serves to avoid unnecessary duplication and overall cost reduction in the health sector.

Central storage of medical information is not possible in many countries due to privacy regulations. This means that the medical data, e.g. Anamnesis data, previous findings or reports, generated image data, etc. may not, or at least not unsecured, leave the sphere of the respective institution on which they have been recorded; The data thus remains local and therefore distributed and decentralized.

Another problem in the prior art is that the number of data (stored medical data) increases. The selection of relevant data for the respective application thus presents a challenge. Even if the data were not present in decentralized data pits, but centrally, extracting relevant information from these very extensive data volumes would be a computation-intensive and resource-intensive task. because a variety of different space-intensive files must be searched. However, the local facilities are not always equipped with the necessary infrastructural (information technology) resources.

A further complicating factor is that the requirements for the selection of data can be very different. On the one hand, different authorizations of the participants (for example in the role as doctor, patient, personnel, etc.), which can also vary over time, have to be taken into account and, on the other hand, there are different applications and medical questions. For example, it makes a difference whether the data should be collected for a medical study or for a specific diagnosis of a patient, the latter usually requiring a higher level of detail of the data.

It is therefore desirable to make health data available beyond the boundaries of the respective facility and to fulfill the above-mentioned restrictions and specifications.

1. 1. Eine XDS Quelle, die die Daten erzeugt (z.B. ein bildgebendes System oder eine Messvorrichtung),
2. 2. eine XDS Repository, die zur lokalen persistenten Speicherung der erfassten Daten und deren Registrierung im Repository dient und
3. 3. eine zentralen Registry.

In the prior art, standard data exchange of electronic health data in EHR systems (EHR - Electronic Health Record) between the distributed institutions is usually used. IHE (IHE - Integrating the Healthcare Enterprises), for example, is an international initiative of users and manufacturers with the aim of standardizing and harmonizing data exchange between healthcare IT systems. XDS is an example of a cross-enterprise document sharing system. In IHE XDS based environments there are three different actors:

1. 1. An XDS source that generates the data (eg, an imaging system or a measuring device),
2. 2. an XDS repository, which serves for local persistent storage of collected data and its registration in the repository and
3. 3. a central registry.

The registry is responsible for storing metadata about these generated data or documents so that the documents relevant for the treatment of a patient can be easily found, selected and retrieved, regardless of the repository, ie regardless of the location (in the clinical Device) on which they are actually stored. For this purpose, the metadata contains a pointer (pointer, link, reference) to the storage location of the document in the repository of the respective local facility (for example, in an information technology unit of the clinic, etc.). Multiple local repositories from one or more devices can be attached to a registry. In this standard, an important aspect is that the registry does not have access to the documents stored in the repository, it only has pointers to their location. This precaution serves to comply with safety regulations, namely to ensure that the safety-critical medical data does not leave the respective facility. A client or a data sink can access the documents in the repository with existing access authorization.

As mentioned above, due to the large amount of data, the challenge is to provide relevant data. An overview document or a patient-specific summary file can serve this purpose. The HL7 standard (Health Level 7) for the exchange of data between healthcare organizations already defines a so-called C-CDA document. "CDA" stands for a "Clinical Document Architecture" and the prefix "C-" for the term "consolidated". CDA is an XML-based schema for all clinical documents in the healthcare sector. An overview document is thus already provided in this standard. However, the generation of such a summary document is very complicated in the prior art, since for the extraction of a respective component of the overview document, the respectively corresponding basic document must be opened and searched in which the component is contained.

Due to the technical requirements described above (security, data protection, etc.), it was necessary in IHE XDS based systems to open each individual document if it was to extract data relevant for an overview presentation. If, for example, an overview file for a specific application contains information about the weight and the age of the patient, then in the previous systems it is necessary to open a first file in which information on the weight is stored and this data is taken over and a second file in which information about the age are deposited. It is obvious to a person skilled in the art that this procedure, even if it is automated, is very compute-intensive and time-intensive and therefore requires a large amount of resources.

Based on this problem, the present invention has the object to provide a way to improve the data exchange in the health sector in compliance with the restrictions and requirements described above. In particular, it should be possible to dynamically generate a summary document from a multiplicity of locally stored data sources upon a request from a client and thereby adhere to the access authorizations of the respective clients with variable authorization rules.

This object is achieved in each case by an article according to the independent claims. Advantageous embodiments are the subject of the dependent claims, the description and the drawings.

In the health sector, a large amount of data is generated and must be managed. For medical questions, targeted access to relevant data, which is calculated from distributed data sources, is important. One aspect of the invention relates to generating this relevant data in the form of a summary message or in the form of a patient summary file.

The terms used in this application are defined below.

The registry is a digital storage that is stored centrally. It can be addressed as cloud storage via appropriate network access. Preferably, it is an XDS registry. The registry serves as a document metadata index, ie as a metadata index for the recorded data records.

The repository is a digital storage, e.g. in the form of a hard disk or a RAID system, which is held locally. It is used for local storage of the recorded data sets or documents. Preferably, it is designed as an XDS repository.

The term "data set" can also be understood in the sense of "document". First, on a data source (technical facility in the healthcare sector), such as an imaging device or a measuring device or other medical device, records. These are stored in a document and can be further processed. The document may have a specific structure that facilitates further automatic processing. The structure can be based on a standard. Preferably, the structure is based on an IHE-XDS standard and is a CDA-formatted document (CDA: Clinical Document Architecture). Other embodiments of the invention use a different format.

Broker service is a service that runs on a computer-based node with a processing unit. For this purpose, a broker node is provided, which is intended to execute the broker service. The broker service can be implemented in software. The broker service is provided as a central service. Preferably, the broker service is adapted to be integrated into an IHE-XDS platform.

The extraction service is a service that runs on a computer-based node with a processing unit. For this purpose, an extraction node is provided, which is intended to execute the extraction service. The extraction service can be implemented in software. The extraction service is provided as a local service (e.g., assigned in a clinic or client). Preferably, the extraction service is adapted to be integrated into an IHE-XDS platform.

A client is an electronic entity, such as a computer-based entity, such as a computer, a mobile device, a tablet, a smartphone, or a workstation. The client can be operated by different users in different roles (eg doctor, nurse, nurse). Depending on the role, different access rights can be assigned to the data. This can be implemented in an access rights management system. The client can act as sender and receiver of records. The client may be used to query the summary message or to generate records (eg, a medical report).

The summary message is an electronic dataset that serves as a summary for the previous treatment of the patient or, in the case of complex progressions, of sections thereof. A structured document (e.g., CDA document) transmitted from a data source (e.g., a medical device) may send one or more observation messages to the service (especially first to the local extraction service and then to the central broker service). If e.g. If a document contains information about allergies and weight, it can also generate a first message with <Allergies> and a second message with <Weight>, depending on the implementation you choose. The overview message serves for the overview-like representation of evaluated patient-specific data records, data and / or parameter values or more complex compilations of data in the form of reports, findings or other medical results that are aggregated and summarized in the overview message. In addition to the medical or health-related data, the overview message contains a note that uniquely identifies the patient (the patient identifier) and a clearly identifying reference to the respective document in which the component or parameter of the overview message is contained (document identifier). The individual components of the overview message are usually distributed on different systems and in different formats. You may not leave the respective network (unprotected). Which components are to be included in the overview message can preferably be configured in a preparation phase. Thus, for example, in one embodiment of the invention, the weight, age, allergies present and the patient's current medication may be determined as constituents of the overview message. The data is preferably structured so that it can be efficiently processed and read. You can e.g. be formatted as a string composed of the respective components.

According to a preferred embodiment of the invention, the overview message has a double functionality. On the one hand, it contains the respectively desired, preconfigurable components (eg age, weight, etc.) and on the other hand, it contains a link to the respective document in which the respective component is contained (that is, a total of a number of references to a set from distributed documents). If required, a client to whom the summary message is delivered by means of the method or system proposed here can then access further, more detailed information via the link. This can be done as it were optional and in a second step. However, the overview message initially allows him to view a patient-specific summary of parameter values or other data in a first step, without having to open the individual documents in which the parameters are contained. The access times and the time to search for medical details in extensive collections of documents can thus advantageously be significantly reduced.

The extraction message is an electronic record extracted from the collected medical data of the data source. The extraction is carried out by a specific service, namely the extraction service or extraction service. The extraction service can also be configured in the preparation phase to determine which items it should extract from the collected record. The extraction message includes the type (e.g., weight) and the value (e.g., 75kg) for simple numerical types (age, weight, etc.). For complex types (e.g., MRI scans), only one type indication can be extracted (specifying: image or MRI image or anatomical region represented in the image).

The respective nodes (e.g., extraction nodes, broker nodes) are computer-based hardware units. A node can be designed as a network node. In particular, it can be a device that performs switching functions, but also a device that works at the edge of the network as an interworking unit. A node may be a controller, node computer, terminal, printer, disk drive, minicomputer, gateway, or other device. A node can multiply, divide, and statistically allocate data channels and, by means of dynamic allocation, convey data transmission channels.

The interfaces described are components of the technical system used for communication. The interface can be used as a network interface (eg WLAN or another radio interface) be educated. It can also be provided several interfaces per network segment or communication device, such as when using a bridge with at least two network interfaces (the bridge / bridge ensures that signals, protocols and / or transmission systems are converted, if the communicating systems no common interface or when using hubs and switches or routers. On another ISO / OSI level, the interface can also be designed as a software interface and connect the respective applications or operating system program in terms of data technology. The interfaces can thus be software-side data interfaces that provide logical connections in a software system. They enable and regulate the exchange of commands and / or data between different processes and components. The interface can be provided for inter-process communication and / or as an interface for program components. In particular, the wireless interfaces of the known network protocols, such as TCP, HTTP, etc. are understood as interfaces.

The processing unit and the computing unit are computer-based instances that are used to execute computer programs. It can in particular be a processor, a microcontroller and / or a microprocessor. The processing and arithmetic unit can be designed as a central processing unit (CPU) and serve to execute commands of a program. It can include a calculator and a control unit and communication interfaces.

• - Einlesen eines Datensatzes von einer lokalen Datenquelle;
• - Auswählen von Parametern des eingelesenen Datensatzes zum Erzeugen einer Extraktionsnachricht;
• - Versenden der Extraktionsnachricht an einen zentralen Brokerservice.

According to a first aspect, the object is achieved by a method for operating an extraction service for generating an (electronic) extraction message for a patient on the basis of a standardized platform, comprising the following method steps:

• - reading a data record from a local data source;
• Selecting parameters of the read record to generate an extraction message;
• - Sending the extraction message to a central broker service.

According to the IHE XDS standard, it is envisaged that the read-in data record will be sent to a local repository for storage. The repository is adapted to send metadata from the data record (received from the data source) to a central registry for the purpose of registration. The registry only contains metadata about the data collected on the data source. The actual (binary) data is only stored locally in the repository. According to a preferred embodiment of the invention, the process is based on this standardized procedure. An important advantage is therefore to be seen in the fact that the standard procedure must not be changed or influenced in order to achieve the advantages of the invention. The hospitals nor the connected clients do not need to buy new hardware (or software). It is only necessary to provide two services (a local extraction service and a central broker service). These can advantageously be integrated and implemented on existing nodes. In principle, the concept presented here and the invention can also be used with other standards and also with proprietary standards and also with non-standard-compliant systems and not exclusively with XDS.

In an advantageous embodiment of the method, it is preconfigurable (in a configuration phase of the method) to extract the parameters from the read-in data set. This means that the procedure can be divided into an execution phase and an upstream configuration phase and that in the configuration phase it is possible to set which parameters should basically be extracted. These are identified as extractable.

• - Einen Patienten-Identifikator, der den jeweiligen Patienten eindeutig kennzeichnet;
• - einen Dokumenten-Identifikator, der einen Speicherort von Metadaten zu dem eingelesenen Datensatz eindeutig referenziert, aus dem (Datensatz) die Daten extrahiert wurden;
• - eine konfigurierbare Auswahl von extrahierten Parametern, insbesondere unter Angabe eines Parametertyps (z.B. Gewicht, Alter, Allergie etc.) und dessen Wert (z.B. 67 kg, 35, Heuschnupfen). Vorzugsweise wird dabei ein Code verwendet, der einen Parametertyp eindeutig kennzeichnet. In einer bevorzugten Ausführungsform der Erfindung ist ein Parameter somit durch die Angabe eines Parametertyps und des entsprechenden Wertes gekennzeichnet.

According to a further advantageous embodiment of the method, the extraction message comprises at least the following elements:

• - a patient identifier that uniquely identifies the patient;
• a document identifier that uniquely references a location of metadata about the read record from which the data was extracted;
• a configurable selection of extracted parameters, in particular specifying a parameter type (eg weight, age, allergy etc.) and its value (eg 67 kg, 35, hay fever). Preferably, a code is used that uniquely identifies a parameter type. In a preferred embodiment of the invention, a parameter is thus characterized by the specification of a parameter type and the corresponding value.

It should be noted that the term "parameter" is used in different references or instances in the application. For example, there are parameters contained in the requested summary message, in the generated summary message, in the extraction message, and in aggregated extraction messages. The parameter (specifying the parameter type and parameter value) thus references the each associated records and is used in technical terms as an index. The index makes it possible to quickly determine the storage position of the respective requested data record within the storage medium, so that only a subset of the stored data must be searched. This has the technical advantage that a fast search in large amounts of data can be carried out efficiently while at the same time being able to comply with the security regulations and access regulations.

If, for example, the requested overview message should include the parameter "blood group", then the parameter "blood group" is first determined from the overview message in order then to access the database in order to collect and summarize those extraction messages which contain the parameter "blood group". include. For the aggregated extraction messages, the access right of the requesting client to the "blood group" data records is then determined under access to the central registry and only if an authorization can be validated, the respective parameter is included in the overview message to be created. Lying e.g. provide two different data sets in the database, including the parameter "blood type", namely a first data set that includes a diagnosis (eg in the form of a diagnosis "AIDS" with reference to the blood group in a medical report) and a second data set that contains a Extract of data of a vaccination certificate includes, so can eg the client has permission to access the second record, but not the first record. In this case, only the second data record is referenced in the overview message to be created, since there is only authorization for this.

• - Empfangen der Anfrage des Clients;
• - Auflösen der empfangenen Anfrage und Bestimmen eines Client-Identifikators und Ermitteln von Parametern der angefragten Übersichtsnachricht;
• - Zugriff auf eine Datenbank, um diejenigen Extraktionsnachrichten zu aggregieren, die den ermittelten Parametern entsprechen;
• - Zugriff auf eine zentrale Registry, um auf Basis des bestimmten Client-Identifikators eine existierende Berechtigung des Clients zum Zugriff auf das jeweilige Dokument zu überprüfen, in dem der jeweilige Parameter aller aggregierten Extraktionsnachrichten enthalten ist und bejahendenfalls (also falls die Berechtigung vorhanden ist):
• - Einfügen des jeweiligen Parameters in die Übersichtsnachricht und iteratives
• - Erstellen der Übersichtsnachricht.

According to a second aspect, the object is achieved by a method for operating a central broker service for servicing a client request for a summary message for a patient on the basis of a standardized platform, comprising the following method steps:

• - receiving the request from the client;
• - resolving the received request and determining a client identifier and determining parameters of the requested summary message;
• - accessing a database to aggregate those extraction messages corresponding to the determined parameters;
• Access to a central registry to check on the basis of the specific client identifier an existing authorization of the client to access the respective document, in which the respective parameter of all aggregated extraction messages is contained and, if so, if the authorization exists:
• - Insert the respective parameter into the overview message and iteratives
• - Create the overview message.

In a preferred embodiment of the invention, the overview message is generated dynamically and only when required at the request of the client and in particular during the access (to the database). Thus, advantageously, the security regulations can be adhered to and the data to be protected are stored exclusively locally or locally (the data acquisition) persistently.

According to a further preferred embodiment of the invention, the overview message is delivered as a fully structured document, and in particular is formatted according to a CDA standard. This facilitates the further processing of the data and the inclusion of the overview message in other standardized systems.

According to a further preferred embodiment of the invention, authorization rules are stored in the central registry, which are also variable during execution of the method. The authorization rules are used to define the access rights of the clients. Advantageously, a dynamic adaptation to the use case can be achieved with the separate storage of the authorization rules.

According to a further preferred embodiment of the invention, an access authorization of the requesting client and / or context parameters of the request are taken into account when generating the overview message. Depending on the role (eg position of the user with respectively different dedicated access authorization) and context (eg purpose and background or meaning of the request, eg for a diagnosis or for a study) of a request, different access rights apply to the respective data records. Advantageously, the authorization rules can also be changed during operation without requiring a restart of the method. In computer science, it is known to define a user role (or role for short). In this case, a set of individual rights for access to safety-critical data and / or software can be summarized. User roles are used in order not to have to specify the individual rights of the aforementioned areas for each user individually: instead of assigning the same individual rights to many users directly, a user role is defined that contains the rights to be assigned. To the users then the respective respective role is assigned. This facilitates the rights management of the software system, since only the rights of the user role need to be adapted, in particular in the case of changes to the rights structure. The rights management can be implemented in an access control system. Preferably, the user interface of the client is adapted to its user role, that is, depending on what permissions it has, it can generate more extensive requests or just simple. The user role with the access authorizations can be provided in a mobile data carrier which can be read out via a wireless interface (eg in the form of a chip card or an RFID tag).

According to a further preferred embodiment of the invention, the queried parameters are filtered according to configurable filter criteria for generating the overview message.

According to a further preferred embodiment of the invention, the overview message comprises a link to the respective document in which the requested parameter (s) is / are contained. Typically, the summary message contains a set of parameters, and thus a set of links pointing to the respective documents or their location. As already described above, the respective access rights of the client to the documents are checked and stored centrally (preferably in the registry) in a preceding step. In a preferred embodiment of the invention, this can be carried out by means of an access control system. If an access right could not be validated during operation (ie no access is available), then the parameter is automatically removed from the overview message and accordingly contains no link to the document.

According to a further preferred embodiment of the invention, the overview message is not stored in the registry. It is preferably stored on no node, but only made available to the client upon his request. This can increase security and prevent misuse of the data.

According to a further preferred embodiment of the invention, all calculations for generating the overview message are carried out completely by the central broker service. This creates the important advantage that the entire workload and resource consumption can be outsourced to the server or to the cloud, so to speak. Optionally, an access control or authorization system can also be accessed.

According to another preferred embodiment of the invention, the standardized platform is an IHE-XDS platform.

• - Eine Extraktionseingangsschnittstelle, die zum Einlesen eines Datensatzes von einer lokalen Datenquelle bestimmt ist;
• - Einer Recheneinheit, die zum Auswählen von Parametern des eingelesenen Datensatzes zur Erzeugung einer Extraktionsnachricht bestimmt ist;
• - Eine Extraktionsausgangsschnittstelle, die zum Versenden der Extraktionsnachricht an einen zentralen Brokerservice bestimmt ist.

In another aspect, the invention relates to an extraction node for generating an extraction message for a patient based on a standardized platform, comprising:

• An extraction input interface intended for reading in a data set from a local data source;
• - A computing unit, which is intended for selecting parameters of the read record for generating an extraction message;
• An extraction output interface intended to send the extraction message to a central broker service.

• - Eine Brokereingangsschnittstelle, die zum Empfangen der Anfrage des Clients dient;
• - Einer Brokerextraktionsschnittstelle, die zum Einlesen einer Extraktionsnachricht bestimmt ist;
• - Einer Verarbeitungseinheit, die zum Auflösen der empfangenen Anfrage und zum Bestimmen eines Client-Identifikators und zum Ermitteln der Parameter der angefragten Übersichtsnachricht bestimmt ist;
• - und wobei die Verarbeitungseinheit weiterhin zum Zugriff auf eine Datenbank bestimmt ist, um diejenigen Extraktionsnachrichten zu aggregieren, die den ermittelten Parametern entsprechen;
• - und wobei die Verarbeitungseinheit weiterhin zum Zugriff auf eine zentrale Registry bestimmt ist, um auf Basis des bestimmten Client-Identifikators eine existierende Berechtigung des Clients zum Zugriff auf das jeweilige Dokument zu überprüfen, in dem der jeweilige Parameter aller aggregierten Extraktionsnachrichten enthalten ist und
• - wobei die Verarbeitungseinheit bei existierender Berechtigung zum Einfügen des jeweiligen Parameters in die Übersichtsnachricht und zum Erstellen der Übersichtsnachricht bestimmt ist.

In another aspect, the invention relates to a central broker node for executing a broker service for servicing a client request summary message for a patient based on a standardized platform, comprising:

• A broker input interface used to receive the client's request;
• A broker extraction interface intended for reading in an extraction message;
• A processing unit which is intended to resolve the received request and to determine a client identifier and to determine the parameters of the requested summary message;
• - and wherein the processing unit is further designated to access a database to aggregate those extraction messages that correspond to the determined parameters;
• - And wherein the processing unit is further intended to access a central registry to check based on the specific client identifier an existing authorization of the client to access the respective document in which the respective parameter of all aggregated extraction messages is included and
• - Wherein the processing unit is determined in existing permission to insert the respective parameter in the overview message and to create the summary message.

• - Eine Extraktionseingangsschnittstelle, die zum Einlesen eines Datensatzes von einer lokalen Datenquelle bestimmt ist;
• - Eine Recheneinheit, die zum Auswählen von Parametern des eingelesenen Datensatzes zur Erzeugung einer Extraktionsnachricht bestimmt ist;
• - Eine Extraktionsausgangsschnittstelle, die zum Versenden der Extraktionsnachricht an einen zentralen Brokerservice bestimmt ist;
• - Einem lokalen Repository, das zur lokalen Speicherung der erzeugten Datensätze und zur Versendung von Metadaten zu den erzeugten Datensätzen mit einem Link auf die Datensätze an eine zentrale Registry bestimmt ist;
• - Eine Brokereingangsschnittstelle, die zum Empfangen der Anfrage des Clients dient;
• - Einer Brokerextraktionsschnittstelle, die in Datenaustausch steht mit der Extraktionsausgangsschnittstelle und zum Einlesen einer Extraktionsnachricht bestimmt ist;
• - Einer Verarbeitungseinheit, die zum Auflösen der empfangenen Anfrage und zum Bestimmen eines Client-Identifikators und zum Ermitteln der Parameter der angefragten Übersichtsnachricht bestimmt ist;
• - und wobei die Verarbeitungseinheit weiterhin zum Zugriff auf eine Datenbank bestimmt ist, um diejenigen Extraktionsnachrichten zu aggregieren, die den ermittelten Parametern entsprechen;
• - und wobei die Verarbeitungseinheit weiterhin zum Zugriff auf die zentrale Registry bestimmt ist, um auf Basis des bestimmten Client-Identifikators eine existierende Berechtigung des Clients zum Zugriff auf das jeweilige Dokument zu überprüfen, in dem der jeweilige Parameter aller aggregierten Extraktionsnachrichten enthalten ist und
• - wobei die Verarbeitungseinheit bei existierender Berechtigung zum Einfügen des jeweiligen Parameters in die Übersichtsnachricht und zum Erstellen der Übersichtsnachricht bestimmt ist.

In another aspect, the invention relates to a system for generating a summary message for a patient based on a standardized platform and for operating a central broker service and an extraction service, with:

• An extraction input interface intended for reading in a data set from a local data source;
• - A computing unit, which is intended for selecting parameters of the read record for generating an extraction message;
• An extraction output interface intended to send the extraction message to a central broker service;
• - A local repository that is used to locally store the generated records and to send metadata to the generated records with a link to the records to a central registry;
• A broker input interface used to receive the client's request;
• A broker extraction interface that is in communication with the extraction output interface and for reading in an extraction message;
• A processing unit which is intended to resolve the received request and to determine a client identifier and to determine the parameters of the requested summary message;
• - and wherein the processing unit is further designated to access a database to aggregate those extraction messages that correspond to the determined parameters;
• - And wherein the processing unit is further determined to access the central registry to check based on the specific client identifier an existing authorization of the client to access the respective document in which the respective parameter of all aggregated extraction messages is included and
• - Wherein the processing unit is determined in existing permission to insert the respective parameter in the overview message and to create the summary message.

1. 1. Einlesen eines Datensatzes von einer lokalen Datenquelle;
2. 2. Auswählen von Parametern des eingelesenen Datensatzes zum Erzeugen einer Extraktionsnachricht;
3. 3. Versenden der Extraktionsnachricht an einen zentralen Brokerservice;
4. 4. Empfangen der Anfrage des Clients;
5. 5. Auflösen der empfangenen Anfrage und Bestimmen eines Client-Identifikators und Ermitteln von Parametern der angefragten Übersichtsnachricht;
6. 6. Zugriff auf eine Datenbank, um diejenigen Extraktionsnachrichten zu aggregieren, die den ermittelten Parametern entsprechen;
7. 7. Zugriff auf eine zentrale Registry, um auf Basis des bestimmten Client-Identifikators eine existierende Berechtigung des Clients zum Zugriff auf das jeweilige Dokument zu überprüfen, in dem der jeweilige Parameter aller aggregierten Extraktionsnachrichten enthalten ist und bejahendenfalls (also falls die Berechtigung vorhanden ist):
8. 8. Einfügen des jeweiligen Parameters in die Übersichtsnachricht und iteratives
9. 9. Erstellen der Übersichtsnachricht.

According to a further aspect, the present invention relates to a method corresponding to the system described above. The process is performed distributed, both locally on the extraction node and centrally on the broker node. The method thus serves for operating an extraction service on an extraction node and a broker service on a broker node for generating an (electronic) extraction message for a patient on the basis of a standardized platform, comprising the following method steps:

1. 1. reading a data record from a local data source;
2. 2. selecting parameters of the read record to generate an extraction message;
3. 3. sending the extraction message to a central broker service;
4. 4. receiving the client's request;
5. 5. resolving the received request and determining a client identifier and determining parameters of the requested summary message;
6. 6. accessing a database to aggregate those extraction messages corresponding to the determined parameters;
7. 7. accessing a central registry to check on the basis of the specific client identifier an existing authorization of the client to access the respective document, in which the respective parameter of all aggregated extraction messages is contained and if so (if the authorization exists) :
8. 8. Insert the respective parameter into the overview message and iteratives
9. 9. Create the summary message.

In this case, steps 1 to 3 are carried out on the extraction node and the remaining steps (4 to 9) on the broker node or centrally on distributed cloud-based network nodes.

An important advantage of the above-described solution of the problem is that the computational load for providing the summary message can be relocated as a patient summary to the network, to a server or to the cloud and not located locally on the requesting client. Furthermore, it can be seamlessly built on existing standards and the safety requirements of sensitive, sensitive data can be met in the Healthcare (PHI) data. These provide, among other things, that the local medical data of a patient recorded in a facility (hospital) may only be stored in this facility and not made available externally. Thus, methods known in the art, e.g. work with web crawlers, not to be used.

The solution to the problem was described above using the procedure, specific nodes and a system. there mentioned features, advantages or alternative embodiments are also to be transferred to the other claimed objects and vice versa. In other words, the objective claims (which are directed, for example, to a system, an account or a computer program product) may also be developed with the features described or claimed in connection with the method. The corresponding functional features of the method are thereby formed by corresponding representational modules, in particular by hardware modules or microprocessor modules, of the system or of the product, and vice versa.

A further task solution provides a computer program with computer program code for carrying out all method steps of the methods described in more detail above (on the different nodes) when the computer program is executed on a computer or on the respective node. It is also possible that the computer program is stored on a readable by a computer medium.

Another task solution provides a computer program product that can be loaded directly into the memory of a digital computer and includes computer program code for executing any of the above described when the computer program product is executed on a computer.

• 1 eine schematische Übersichtsdarstellung eines Systems zur zentralen Erstellung einer Übersichtsnachricht gemäß einer bevorzugten Ausführungsform der Erfindung;
• 2 ein Blockschaltbild eines Knotens, der einen lokalen Extraktionsservice gemäß einer bevorzugten Ausführungsform der Erfindung implementiert;
• 3 ein Blockschaltbild eines Knotens, der einen zentralen Brokerservice gemäß einer bevorzugten Ausführungsform der Erfindung implementiert;
• 4 ein Ablaufdiagramm eines Verfahrens zur Ausführung auf einem Extraktionsknoten;
• 5 ein Ablaufdiagramm eines Verfahrens zur Ausführung auf einem Brokerknoten; und
• 6 ein Sequenz-Diagramm zum Nachrichtenaustausch zwischen beteiligten Knoten.

In the following detailed description of the figures, non-limiting exemplary embodiments with their features and further advantages will be discussed with reference to the drawing. In this show:

• 1 a schematic overview of a system for centrally creating a summary message according to a preferred embodiment of the invention;
• 2 a block diagram of a node that implements a local extraction service according to a preferred embodiment of the invention;
• 3 a block diagram of a node implementing a central broker service according to a preferred embodiment of the invention;
• 4 a flowchart of a method for execution on an extraction node;
• 5 a flowchart of a method for execution on a broker node; and
• 6 a sequence diagram for message exchange between participating nodes.

The invention relates to the automatic generation of an overview document which is identified below as an overview message and in the figures with the reference symbol uen.

The overview message is intended to serve a user (doctor or the patient himself or other participants) who works on a computer node designed as a client CL to provide an overview of already existing health data of the patient. The compilation of the overview message should be configurable. In particular, depending on the application, it should be possible to determine which parameters the overview message should include. In a first example, the summary message for Huber patient should include the weight and blood type, while in a second example, the same patient should be allergy and surgical findings and reports included.

According to a preferred embodiment of the invention, the role of the requesting client CL and the situational use case for the request to (the request context) are also taken into account in the generation of the summary message. This has the following background: In medical authorization systems, there are usually roles that are assigned to a user / client and that are linked to rights. For example, a user in the role "Physician" can see radiological findings and discharge letters, while a user in the role of "Caregiver" is only allowed to see discharge letters. In order to be able to automatically check whether the respective user has access to the document from which the information or parameters were extracted, the rights and roles of the user are recorded when the call is made. Likewise, the request context is captured. This represents e.g. for what purpose the summary message should be generated (e.g., study, diagnosis, etc.).

To create the summary message uen various legal conditions must be met. For example, it must be ensured that patient-specific data does not leave the sphere of the clinical setting in which it was collected. They must therefore be stored locally.

In order to be able to comply with these legal conditions and other requirements, it is preferable to use a standardized exchange platform. There are basically several options. A preferred standard is an IHE standard, especially an IHE-XDS platform.

• - eine lokale Datenquelle XDS-S, auf der die Daten erzeugt werden, z.B. ein MRT-Gerät oder eine andere bildgebende Einrichtung oder ein Blutdruckmessgerät etc. Die Datenquelle XDS-S erzeugt Datensätze ds;
• - Ein lokaler Speicher, der als XDS-Repository XDS-REP ausgebildet sein kann. Er dient zur persistenten Speicherung der Binärdaten ds und zur Weiterleitung von Metadaten an eine zentrale Registry XDS-REG;
• - Die zentrale Registry XDS-REG. Sie dient zur Speicherung der Metadaten zu den auf der lokalen Datenquelle XDS-S erfassten Datensätzen ds mit einem Zeiger auf den Speicherort derselben, also auf das lokale Repository XDS-REP. Die Datensätze ds werden nicht auf der zentralen Registry XDS-REG gespeichert, sondern dort nur registriert.

According to the IHE-XDS standard, three actors are envisaged:

• - a local data source XDS-S, on which the data are generated, eg an MRT device or another imaging device or a sphygmomanometer etc. The data source XDS-S generates data records ds;
• - A local storage that can be configured as an XDS repository XDS-REP. It is used for the persistent storage of binary data ds and for the forwarding of metadata to a central registry XDS-REG;
• - The central registry XDS-REG. It is used to store the metadata for the records ds collected on the local data source XDS-S with a pointer to their storage location, ie to the local repository XDS-REP. The records ds are not stored on the central registry XDS-REG, but only registered there.

• - Einen lokalen Extraktionsknoten OES und
• - Einen zentralen Brokerknoten OBS.

This standard-compliant architecture is extended according to the invention by two interacting nodes:

• - A local extraction node OES and
• - A central broker node OBS.

The extraction node OES is preferably configured to perform an extraction service (or service). The broker node OBS is preferably designed to perform a broker service.

The interaction of these actors will be explained in more detail below with reference to FIG. 1.

The extraction service serves to receive the recorded data records ds and extracts therefrom, according to preconfigurable rules, certain parameters of interest which should in principle be available for summary messages. The extraction service thus generates an excerpt from the respective data record ds and structures this in the form of an extraction message and sends it to the central broker service. For transfer, an HL7 FHIR transaction can be used (FHIR: Fast Healthcare Interoperability Resources).

• - Einen Patienten-Identifikator; dies ist eine eineindeutige Kennzahl, die den Patienten identifiziert
• - Einen Dokumenten-Identifikator; dies ist ebenfalls eine eineindeutige Kennzahl, die das Dokument identifiziert bzw. dessen Speicherort referenziert, aus dem die extrahierten Parameter erfasst worden sind und
• - Die jeweiligen Parameter.

The extraction message contains at least the following entries:

• - a patient identifier; this is a one-to-one metric that identifies the patient
• - a document identifier; this is also a one-to-one metric that identifies or references the location of the document from which the extracted parameters have been collected and
• - The respective parameters.

The central broker service serves to receive the extraction message. Furthermore, it is the recipient node of a request from the client CL. The client CL wants e.g. In his function as an anesthetist, Huber receives an overview for a specific patient for the planning of the upcoming anesthesia during an operative procedure. He is interested in special parameters such as allergies, weight and age of the patient and anesthetic gases that have been used in previous operations. He creates a configured query that includes allergy, weight, age, and anesthetic gases parameters. This request is transmitted via a transaction, preferably a HL7 FHIR transaction to the central broker service.

The central broker service resolves upon receipt of the request and extracts or determines a client identifier identifying the requesting client CL. In this case, both a role of the requesting person (property as a physician, in particular anesthesiologist) and the context of the request (for a pending anesthesia) can be taken into account. The client identifier includes characterizing elements. Furthermore, the central broker service determines the desired parameters for the requested overview message uen for the respective patient. Usually, the request is patient-specific. However, multiple queries may be combined to form a more complex query (e.g., "overview of all patients with surgery appointment tomorrow in terms of allergy, weight, age, and anesthetic gases parameters), which will then be patient-overlapping.

With the parameters determined, the central broker service accesses a database DB in order to find the entries or the extraction messages which comprise the desired parameters. The database access thus determines a set of extraction messages, which - in the above example - information on allergies, weight, age and anesthetic gases of the patient Huber.

However, since the requesting client Cl is not always authorized to access all documents, it is necessary for the central broker service to carry out further transactions for checking the respective authorizations of the client CI for the documents. For this he prefers to access the central registry XDS-REG. This can be done via an ITI 18 or ITI 61 Execute transaction. In an advantageous alternative embodiment of the invention, access to the central registry XDS-REG can also be carried out indirectly, mediated by an access control system (ACS).

The central broker service or the authorization system now iteratively checks for the list with the appropriate extraction messages for each of the extraction messages, which parameters it comprises and from which document the respective parameter originates in order to determine whether the requesting client authorizes CL to access the respective document is. Only if an authorization could be determined, the respective parameter is included in the overview message uen to be generated. Otherwise (without authorization), the parameter is not included in the overview message uen.

In multiple iterations, the overview message can ultimately be generated on-the-fly, so to speak, and delivered as a structured document to the requesting client CL. For communication between the client CL and the central broker service, an ITI 43 or an HL7 FHIR transaction.

As in 1 As shown, the data source XDS-S, the extraction service and the storage system XDS-REP are positioned locally in a clinical facility. The corresponding nodes XDS-S, OES, XDS-REP communicate via standardized protocols, such as via ITI 41 , This is a transaction with content (payload) of a so-called "provide and register document set-b" message. The payload of the message may contain metadata md to the recorded record with the access permissions and other metadata, such as a time stamp, the respective data source XDS-S etc.

The metadata md are sent with a link to the location of the data ds to a central registry XDS-REG for registration. The registry XDS-REG is provided as a central instance and can be moved to the cloud, so to speak. As a central instance, the broker service on the broker node OBS is also provided, which also communicates with the other players via a suitable network connection.

The communication between the local repository XDS-REP and the central registry XDS-REG can be done via an ITI 42 Transaction.

2 schematically shows the architecture of the extraction node OES on which the extraction service is implemented. It comprises an extraction input interface IE for receiving the data records ds acquired on the data source XDS-S and a computing unit P for extracting relevant parameters from the data records ds. The arithmetic unit P calculates the extraction message and sends it via the extraction output interface OE to the central broker service. Optionally, the extraction service may include other components, such as a cache or memory for (intermediate) storage of the generated extraction message.

In 3 Figure 1 schematically illustrates the architecture of the broker node OBS on which the central broker service is implemented. It comprises a broker extraction interface EIN for receiving the extraction message and a further interface for communication with the registry XDS-REG and a further broker input interface IB serving to receive the request to the client CL. A processing unit V serves to resolve the received request to and determine a client identifier and to determine the parameters of the requested summary message uen for the patient. Preferably, a patient ID is also transmitted in the request and detached on the broker service node OBS.

With reference to 4 In the following, a procedure of the method executed on the extraction node OES will be described.

After the start of the method, the record ds from the source XDS-S is received in step S10, and preconfigured parameters with their values are selected in step S11. Here, e.g. relevant parameters (e.g., weight, age, allergy, anesthetic gas composition) and their values are determined to produce therefrom an extraction message in step S12. The extraction message then includes e.g. the information <code for weight>, 75, <optional unit> kg, <documentID>, <patientID>. The extracted information is sent in step S14 to the broker service, which stores the information, in particular in the database DB. It is important to emphasize that the stored data are not the original, sensitive medical data, but only excerpts or non-safety-critical extracts of the same. Advantageously, certain operations may then be implemented on the resulting data collection (such as the automatic generation of a summary message or a patient summary, or even querying of concrete values and / or further (e.g., statistical) evaluations of the data). The method can be operated in PUSH mode, so that newly generated documents or data records are always moved to the extraction node. Alternatively, the generated data records ds can also be supplied to the extraction service at specific times or after configurable events. Alternatively, the method is operated in PULL mode so that the extraction node triggers and requests the sending of records ds.

With reference to 5 In the following, an operation of the method executed on the broker node OBS will be described.

After starting the method, the request is received at the client CL in step S20. This is resolved in step S 21 in order to determine the client identifier and to determine the desired parameters of the request or of the requested summary message. Thereupon, in step S22, an access to the connected database DB can take place in order to search for and aggregate those extraction messages which correspond to the determined parameters. In this case, therefore, preferably all those extraction messages are determined which comprise the parameters. As an intermediate result, a list with determined extraction messages is generated. Each extraction message usually includes several parameters. This is therefore only an intermediate result, since it still has to be checked for each of the parameters whether the requesting client CL in its role and in its request context is also authorized to access the documents from which the respective parameter has been extracted. A parameter can also be contained in several documents or data records ds. It is obvious to the person skilled in the art that this task is accompanied by a high computing load. The role and the request context are captured when the request is generated by the client CL and sent to the broker service in a data packet with the request query in the request message.

Therefore, an important advantage of the inventive solution is the fact that these computationally intensive operations can be completely outsourced to the cloud, ie to the central broker service or the broker node OBS, and not to the local node or to the client CL , In particular, no database access and no search need to be performed on the local node, which makes the approach proposed here very efficient.

In step S23 - again starting from the broker service - an access to the central registry XDS-REG to check based on the specific client identifier an existing authorization of the client CL to access the respective document / record ds, in the the respective parameter of all aggregated extraction messages is contained. If yes (ie if the authorization exists) the respective parameter is inserted in step S24 in the overview message uen. These steps are repeated iteratively for all the permissions of all the records ds to all the parameters of all the extraction messages of the intermediate result, until all elements have been determined whether the access authorization exists or not. Thereupon, finally, the overview message uen can be created in step S25. It can be delivered to client CL via a standardized transaction. After that, the process may end.

6 shows a UML diagram for the data exchange between participating nodes according to a preferred implementation. An access control node is also provided on which an access control service ACS (access control system) is implemented. For this reason, it will also be referred to below as the ACS node for short and bears the reference symbol ACS. In alternative embodiments of the invention, the functionality of the ACS node is integrated into another central node, in particular into the central registry XDS-REG.

The in 6 Client CL represented can be an XDS receiver (ie a data sink, eg a doctor who wants to request data) or an XDS transmitter (and thus a data source), which itself generates data. With transaction 1 the client CL can access the ACS node, which then the record ds with transactions 2 . 3 registered in the XDS registry XDS-REG. The ACS node can then carry out filter operations, for example to implement captured policies and other authorizations. With transaction 5 a result can be output to the client Cl.

The client CL provides with the in 6 represented transaction 7 a request to the broker service, as in 6 shown. After the broker service has extracted the necessary data from the request to, this can with transcation 8th a search for - to the request to and the client CL corresponding - extraction messages en in the database DB run. Then done in transaction 9 an access to the ACS node (or directly to the registry XDS-REG), with transaction 10 accesses the registry XDS-REG to determine access permissions and with transaction 11 on the ACS node. There you can with transaction 12 Filtering operations are performed. It can also do multiple filter operations 12 can be executed consecutively in order to fulfill, for example, stored policies (which can regulate, for example, that certain documents / data records ds may not be issued to specific clients CL or only in predefined periods). It may also be that the disclosure of certain records ds is associated with an agreement of the patient who is flagged (or not set) in a registry. Accordingly, filtering is performed for those records for which consent has been obtained. The application of further control mechanisms is also within the scope of the invention. The filtering operation performed by the ACS node may still require it, or other nodes to have access (for example, for data synchronization). These other nodes are in 6 however - for the purpose of clarity - not shown. With transaction 13 the intermediate result can be passed on to the Brokerservice. This can be with the surgery 14 Execute further processes and, for example, remove certain extraction messages from the overview message for which no authorization exists. With transaction 15 the result is compiled with the summary message uen specifically for the requesting client CL and with transaction 16 issued to this. The result is preferably a document in CDA format (Clinical Document Architecture of the HL7 standard).

 {
   "resourceType" : „Observation“ ,
   "contained":[
      {
         "resourceType":"Patient",
         "id":"1",
         "identifier":[
             {
                "use":"usual",
                "system":"1.1.1",
                "value":"ee499dd1-06f5-4335-9304-67536aa5c6ad"
             }
         ]

      }
   ] ,
   "status":"preliminary",
   "category":[
      {
         "coding":[
             {
                "system":"http://hl7.org/fhir/observation category",
 
                "code":"vital-signs",
                "display":"Vital Signs"
             }
        ]
      }
   ],
   "code":{
      "coding":[
          {
            "system":"http://loinc.org",
            "code":"3141-9",

             "display":"Weight Measured"
          }
      ] ,
      "text":"LOINC Body weight"
   },
   "subject":{
      "reference":"#1"
   },
   "effectivePeriod":{
      "start":"2017-02-01T13:33:17+01:00",
      "end":"2017-02-01T13:33:17+01:00"
   },
   "valueQuantity":{
      "value":80.0,
      "unit":"kg",
      "system":"http://unitsofmeasure.org",
      "code":"[kg]"
   } ,
   "comment":""
 }

Below is an example of an overview message uen given, however, the document identifier is not explicitly mentioned, but is constructed according to the patient identifier <patient id>:

 {
   "resourceType": "Observation",
   "Contained": [
      {
         "Resource type": "Patient""Id":"1""Identifier": [
             {
                "Use", "usual""System":"1.1.1""Value":"ee499dd1-06f5-4335-9304-67536aa5c6ad"
             }
         ]

      }
   ],
   "Status": "preliminary""Category": [
      {
         "Coding": [
             {
                "system": "http://hl7.org/fhir/observation category",
 
                "Code", "vital signs""display":"VitalSigns"
             }
        ]
      }
   ]
   "code":{
      "Coding": [
          {
            "System": "http://loinc.org""Code":"3141-9""display":"WeightMeasured"
          }
      ],
      "text": "LOINC body weight"
   },
   "Subject": {
      "Reference", "# 1"
   },
   "Effective period": {
      "Start", "2017-02-01T13: 33: 17 + 01: 00",
      "End", "2017-02-01T13: 33: 17 + 01: 00"
   },
   "ValueQuantity": {
      "Value": 80.0,
      "Unit", "kg""System":"http://unitsofmeasure.org""Code":"[kg]"
   },
   "Comment": ""
 } 

In summary, it can be stated that the proposal according to the invention makes it possible to index medical records ds in a configured manner and store them in indexed form in order to enable a very efficient search in the extensive data records on a dedicated, high-performance server in order to generate a summary file or an overview message being able to both comply with security regulations and build on existing standards without having to make any changes to the existing management service or existing hardware.

A basic idea of the present invention is to provide a system with which a summary message can be automatically generated without having to make changes to the existing infrastructure of the medical IT system. In the overview message, preconfigured data evaluations may be represented, such as a patient summary or other evaluations, e.g. the output of a warning signal during critical changes to the data records. Through skillful sequencing and stringing of transactions, the summary message can be calculated to contain only those components for which the ACS, XDS-REG authorization system has validated access permissions. This is one of the key points of the present application that the information contained in the summary message, the so-called observations (or observations), not only be extracted and stored, but can be processed in addition with existing document-based authorization systems. This can reduce costs, as no new hardware needs to be funded. It can be based on existing systems with standard standards.

With this solution, the technical advantage can be achieved that the compute-heavy calculations can all be moved to the cloud. In the cloud, a dedicated, high-performance service node can be provided for this purpose. The generation process for generating the summary message can be carried out entirely on the data generation side and not on the data consumption side, ie not on the client side.

Finally, it should be noted that the description of the invention and the embodiments are not to be understood as limiting in terms of a particular physical realization of the invention. All features explained and shown in connection with individual embodiments of the invention may be provided in different combinations in the article according to the invention, in order to simultaneously realize their advantageous effects.

It is particularly obvious to a person skilled in the art that the invention can be applied not only to IHE-XDS systems, but also to other standards. Preferably, the local nodes are separate from the central nodes. However, in specific embodiments of the invention, for example, if the page of data generation has a great deal of resources, it is also possible that the broker service is implemented on the same node as the extraction service. Usually, however, the node OBS of the broker service and the node OES of the extraction service are implemented distributed over several physical products.

The scope of the present invention is given by the following claims and is not limited by the features illustrated in the specification or shown in the figures.

Claims (14)

A central broker node (OBS) for executing a broker service for servicing a client (CL) request for a summary message (u) for a patient based on a standardized platform, comprising: A broker input interface (IB) for receiving (S20) the request (on) of the client (CL); A broker extraction interface (EIN), which is intended for reading in an extraction message (s); - A processing unit (V), which is for dissolving (S21) of the received request (s) and for determining a client identifier and for determining the parameters of the requested summary message (u) is determined; and wherein the processing unit (V) is further adapted to access (S22) a database (DB) to aggregate those extraction messages that correspond to the determined parameters; - And wherein the processing unit (V) is further intended for access (S23) to a central registry (XDS-REG) to check based on the specific client identifier an existing authorization of the client (CL) to access the respective document in which the respective parameter of all aggregated extraction messages (s) is contained and - Wherein the processing unit (V) in existing authorization for inserting (S24) of the respective parameter in the overview message (uen) and for creating (S25) of the summary message (uen) is determined. Central Broker Knot (OBS) after Claim 1 in which the processing unit (V) is intended to generate the overview message (u) dynamically and only when required at the request of the client (CL) and in particular during the access (S22) to the database (DB). Central broker node (OBS) according to one of the preceding claims, in which the summary message (u) is a fully structured document, in particular a fully structured document formatted according to a CDA standard. Central broker node (OBS) according to one of the preceding claims, in which an authorization of the client (CL) is based on an authorization rule, wherein the authorization rule is stored in the central registry (XDS-REG), and wherein the authorization rule is changeable. Central broker node (OBS) according to one of the preceding claims, wherein the processing unit is intended to take into account when generating the summary message (uen) an authorization of the requesting client (CL) to access records and / or context parameters of the request. Central broker node (OBS) according to one of the preceding claims, wherein the processing unit is intended to filter the queried parameters according to configurable filter criteria for generating the overview message (uen). Central broker node (OBS) according to one of the preceding claims, wherein the summary message (u) comprises a link to the respective document in which the requested parameter (s) is / are included. Central broker node (OBS) according to one of the preceding claims, wherein the summary message (uen) not in the registry (XDS-REG) and especially stored on any node, but only the client (CL) is made available. Central broker node (OBS) according to one of the preceding claims, wherein the processing unit is intended to execute all calculations for generating the summary message (u) completely by the central broker service on a central broker node (OBS). A central broker node (OBS) according to any one of the preceding claims, wherein the standardized platform is an IHE-XDS platform. An extraction node (OES) for generating an extraction message (s) for a patient based on a standardized platform, comprising: - An extraction input interface (IE), which is intended for reading in (S10) a record (ds) from a local data source (XDS-S); - A computing unit (P), which is for selecting (S11) parameters of the read record (ds) for generating (S12) an extraction message (s) is determined; An extraction output interface (OE), which is intended for sending (S14) the extraction message (s) to a central broker service. Extraction Node (OES) according to the immediately preceding claim, wherein the selected parameters are preconfigurable from the read-in data set (ds). Extraction node (OES) according to one of the preceding Claims 11 or 12 in which the extraction message (s) at least comprises: - a patient identifier; a document identifier that uniquely references a location of metadata about the read record from which the data was extracted; a configurable selection of extracted parameter types with their values, where a code uniquely identifies a parameter type. A system for generating a summary message (u) for a patient based on a standardized platform and for operating a central broker service and an extraction service, comprising: - An extraction input interface (IE), which is intended for reading in (S10) a record (ds) from a local data source (XDS-S); - A computing unit (P), which is for selecting (S11) parameters of the read record (ds) for generating (S12) an extraction message (s) is determined; An extraction output interface (OE) intended to send (S14) the extraction message (s) to a central broker service; - A local repository (XDS-REP) that stores the generated records (ds) locally and sends metadata about the created records (ds) with a link to the records (ds) to a central registry (XDS-REG) is determined; A broker input interface (IB) for receiving (S20) the request (on) of the client (CL); A broker extraction interface (ON) which is in data exchange with the extraction output interface (OE) and is intended for reading in an extraction message (s); - A processing unit (V), which is for dissolving (S21) of the received request (s) and for determining a client identifier and for determining the parameters of the requested summary message (u) is determined; and wherein the processing unit (V) is further adapted to access (S22) a database (DB) to aggregate those extraction messages that correspond to the determined parameters; - And wherein the processing unit (V) is further intended for access (S23) to the central registry (XDS-REG) to check based on the specific client identifier existing authorization of the client (CL) to access the respective document in which the respective parameter of all aggregated extraction messages (s) is contained and - Wherein the processing unit (V) in existing authorization for inserting (S24) of the respective parameter in the overview message (uen) and for creating (S25) of the summary message (uen) is determined.

Images