DE102010035540A1 - Method for transmission and distribution of digital imaging and communications in medicine data between components of application of digital imaging and communications in medicine network, involves transmitting set by distribution module - Google Patents

Abstract

The method involves assigning determined data function recognition to digital imaging and communications in medicine data set (D) according to measurement of an analysis result of the data function recognition. The data set to be analyzed is transmitted from a data sorting module with the assigned data function recognition to a data distribution module. The data set is transmitted by the data distribution module based on the assigned data function recognition of components of an application (8) of a digital imaging and communications in medicine network (1). Independent claims are also included for the following: (1) a system for transmission and distribution of digital imaging and communications in medicine data between components of an application of imaging and communications in medicine network, comprising a data sorting module (2) a computer program product having a set of instructions for performing a method for transmission and distribution of digital imaging and communications in medicine data between components of an application of imaging and communications in medicine network (3) a machine-readable memory medium having a set of instructions for performing a method for transmission and distribution of digital imaging and communications in medicine data between components of an application of imaging and communications in medicine network.

Description

The invention relates to a method for the transmission and distribution of DICOM data between components of at least one application of a DICOM network. The invention further relates to a system for carrying out the method.

Medical application programs (applications) today generally consist of individual data processing (software) components, between which there are a multiplicity of control and data flow connections. In particular, the data flow connections are often complex in medical technology applications, especially since such applications, especially in the field of digital imaging, with large amounts of data of different types (especially data of different modalities, organs, types of examinations, etc.) complex processing operations (eg. 3D reconstructions, etc.) in a short time must perform.

A well-organized data flow between the individual components of a medical-technical application is of particular importance in application design, especially since the data flow between the components decisively influences the performance of the application, but the performance of a medical application on the other hand a determining factor for the acceptance of the application in the application clinical practice is.

In the field of application of medical imaging technology, the data exchange today is based primarily on the so-called DICOM (Digital Imaging and Communications in Medicine) standard. Applications for this area of application are usually integrated in a so-called DICOM network, via which they are networked with data transmission technology using imaging modalities, data memories, etc.

For the intra-application transmission and distribution of DICOM data, d. H. For the data transmission between the individual components of an application, there are currently no satisfactory standardized solutions. The application-internal DICOM data flow is therefore usually re-implemented individually by the application developer for each medical-technical application. This is crucially responsible for the high workload and the long development time of such applications.

In addition, due to the lack of standardized solutions, the application-internal DICOM data flow is often solved unnecessarily complex and unclear, which sometimes has a negative effect on the performance of the respective application and its maintenance costs.

The invention has for its object to provide a flexible and at the same time effective method for transmitting and distributing DICOM data between components of at least one application of a DICOM network, which should also support and accelerate the development of such applications effectively. Another object of the invention is to provide a system which is particularly suitable for carrying out the method.

With respect to the method, the object is achieved according to the invention by the features of claim 1. With regard to the associated system, the object is achieved according to the invention by the features of claim 17.

The system according to the invention then comprises a data sorting module (also referred to as a "data mapper") and a data distribution module (also referred to as a "data distributor").

The data sorting module is (program-wise) designed in such a way that, during operation, it analyzes a DICOM data record transmitted to the application by an application-external component of the DICOM network. In accordance with the analysis result, the data sorting module selects one from a plurality of predetermined data function identifiers, assigns them to the analyzed DICOM data set and transfers the analyzed DICOM data set together with the assigned data function identifier to the data distribution module. The data distribution module is in turn designed in such a way that it uses the transferred data function identifier to identify at least one component of the application as the target component, ie. H. as the recipient for the passed DICOM record and passes the DICOM record to that component (s).

The control of the incoming DICOM data flow of the application is thus inventively in two (software) components, namely the data sorting module and the data distribution module bundled. This enables a high degree of standardization of the application-internal DICOM data flow, in particular since the assignment of the incoming DICOM data records thereby does not have to be implemented separately in each of the components of the application. This favors the independent development of the individual components by different groups of people, and possibly different manufacturers, especially since the various components of the application with regard to the DICOM data flow not, or only to a small extent individually matched.

In a preferred embodiment, in addition to the data sorting module and the data distribution module, the system comprises a data output module (also referred to as a "data publisher") which controls the outbound DICOM data flow of the application, ie DICOM data to an application-external component of the DICOM network, in particular Issue a (software) component of another application, a data store or a printer. The data sorting module, the data distribution module and the data output module can thus bundle the entire - internal and external, incoming and outgoing - DICOM data flow, so that in turn these aspects can be disregarded in the implementation of the individual components of the application.

For further standardization of the DICOM data flow is provided in an advantageous embodiment of the invention that the DICOM data flow between the components of the application is performed exclusively on the data distribution module, ie in other words the data sorting module, the optional data output module and all other components of the application Do not exchange DICOM records without mediation by the data distribution module.

In a particularly expedient embodiment, the data sorting module, the data distribution module and, if present, the data output module are implemented generically and thus, in their implementation, contain no information that is individual for a particular application. Due to this generationality, the data sorting module, the data distribution module and possibly the data output module can be reused for any medical application, without being able to make application-specific adaptations to the implementation of these modules. D. H. especially without having to reprogram and / or recompile these modules. Rather, the data sorting module, the optionally existing data output module and optionally also the data distribution module are designed such that they can be adapted to any individual application by configuration (also parameterization). The configuration (parameterization) is understood here to be the specification of component-external information which influences the function of the component and, if necessary, changes without the implementation of the component having to be changed for this purpose. In particular, the data sorting module is preferably designed in such a way that, during operation, it accesses a data protocol assigned as configuration information, this data protocol, as intended, defining at least part of the data function identifications available for selection.

By specifying a corresponding data protocol, the application developer can thereby specify the data function identifiers relevant to a specific application in each case in an application-specific manner, thereby adapting the - in itself generic - data sorting module to the requirements of the respective application, without having to influence the implementation of the data sorting module. This aspect can significantly contribute to the saving of development time in the development of a medical application.

In an advantageous embodiment, the data sorting module is not designed solely for distributing the incoming DICOM data flow from outside the application. Rather, the data sorting module in this embodiment can also be used for intra-application distribution of DICOM data records that are output by other components of the application. The data sorting module expediently has an internal (data) input interface via which the data sorting module can record DICOM data records internally within the application. These DICOM data records are also preferably not supplied to the data sorting module directly by the issuing component. Rather, this feedback DICOM data flow preferably also takes place indirectly via the data distribution module.

In an expedient embodiment of the invention, the data distribution module is implemented across applications. It is thus decoupled from the or each application in particular with regard to its cycle life cycle (life cycle). Furthermore, the data distribution module is preferably designed to simultaneously control the - in each case application-specific - DICOM data flow of several applications.

In contrast, the data sorting module and, if present, the data output module are preferably always assigned to a specific (single) application.

In the context of the invention, it can be provided in this case that the data sorting module and possibly the data output module are permanently assigned to an application. In a refinement of the invention which is preferred on account of its flexibility, however, the system is deviating therefrom in such a way that the specific assignment of the data sorting module, and possibly of the data output module, to a specific application at runtime is reversibly established and solvable. The data sorting module and possibly data output module can thus be reversibly connected to the application at run time of the application, and be replaced by the application. This is particularly advantageous for saving resources if the DICOM data flow of several applications is controlled in parallel by the system. In this case, in a suitable variant of each of these applications, a separate data sorting module and possibly a separate data output module are assigned. If the data sorting modules and possibly the data output modules can be connected to the respective application at runtime and solvable by the application, the number of parallel data sorting modules and possibly data output modules can be less than the number of simultaneously running applications, especially since not all applications are usually DICOM at the same time Distribute records. In this case, those data sorting modules and possibly data output modules, which are not accessed by the respectively associated application for a long time, are advantageously decoupled from the application and stored in a reuse pool. As soon as one of the applications again requires the functionality of the data sorting module or, if present, the data output module, the application is again assigned a data sorting module or data output module.

The plurality of data sorting modules and possibly data output modules are preferably implemented the same. In particular, the data sorting modules or data output modules are in each case instances of a common component schema (eg objects of a common class in the sense of object-oriented programming). However, the modules are preferably parameter-specific (that is to say configurable).

Each component of the or each application preferably has at least one input interface and / or at least one output interface for receiving or outputting a DICOM data record. The components are in this case preferably designed in such a way that at least one data function identifier can be assigned to the or each input or output interface by configuration of the component, with this assignment resulting in the relevant input interface or output interface accepting or only accepting data sets of the assigned data function identifier (s) . In other words, by configuration, the input and output interfaces of the modules can be "tagged" with data function identifiers.

In a preferred embodiment, this marking again uses the data distribution module in order to determine the target component (s) for a DICOM data record provided with a specific data function identifier. By marking the input and output interfaces of the components with data function identifiers, it is thus possible to direct the entire DICOM data flow solely by the nature or function of the DICOM data to be transmitted. Thus, the designer of a component merely needs to know what kind of DICOM records the component needs as input data, and what kind of DICOM records that component should output. On the other hand, he does not need to know, specify or implement where the component gets the input data and where the component should send the output data. Also, the data distribution module need not explicitly communicate source components and target components for the DICOM data flow connections. Instead, the data distribution module can use the interface markings to establish the data flow connections themselves-and thus in particular without the intervention of the application developer-by transmitting data streams between identically marked input interfaces and output interfaces.

In addition or as an alternative to the possibility of establishing the interface marking by configuration, within the scope of the system it is advantageously provided the option that at least one component can mark at least one input interface or output interface of itself. Preferably, this marking can be made during the term of the component. In this case, the component can in this case therefore mark the relevant input or output interface dynamically with a specific data function identifier, and preferably also delete or change this marking.

The system described above is preferably a software, ie a computer program, which is implemented on a data processing system in an executable form. The data sorting module, the data distribution module, and the possibly existing data output module are preferably software components, in particular components of a (software) framework on which the application is based.

In particular embodiments, the system is a computer program product or a machine-readable storage medium, each of which contains computer-readable instructions of a computer program, these instructions being used to carry out the inventive method described above in one of its variants when the computer program is run on a computer program Data processing system expires.

An embodiment of the invention will be explained in more detail with reference to a drawing. Show:

1 1 is a schematic block diagram of a DICOM network with several imaging medical modalities and multiple diagnostic stations, each with associated data processing systems, in each of which at least one medical-technical application is installed,

2 in a schematic block diagram of one of the applications according to 1 and an associated system for communicating distribution of DICOM data between components of the application and external components of the DICOM network, and

3 in illustration according to 2 two parallel applications according to 1 with the two applications associated system for the transmission of distribution of DICOM data.

Corresponding parts and sizes are always provided with the same reference numerals in all figures.

This in 1 illustrated DICOM network 1 includes several medical imaging modalities, of which 1 an example of a magnetic resonance tomograph 2 , a computer tomograph 3 as well as an X-ray C-arm device 4 are shown. The DICOM network 1 also includes several diagnostic stations 5a . 5b and 5c , Every diagnostic station 5a - 5c Here is one below as a work computer 6a . 6b respectively. 6c assigned data processing system assigned. Likewise, every modality 2 . 3 and 4 one each below as a control computer 7a . 7b respectively. 7c assigned data processing system assigned.

In each of the work computers 6a - 6c and control computer 7a - 7c is in each case at least one medical technology (software) application 8th implemented.

The DICOM network 1 furthermore comprises a plurality of (here by way of example two) data memories 9a and 9b and output devices such as a printer 10 , The DICOM network 1 finally includes data transmission connections 11 , for example in the form of a so-called LAN (Local Area Network), via which the work computers 6a - 6c and control computer 7a - 7c (more precisely, the applications implemented thereon) data among themselves as well as with the data memories 9a and 9b and replace the output devices.

In the DICOM network 1 The data exchanged are at least predominantly medically relevant datasets, which are in conformity with the DICOM standard. These DICOM records D include, in particular, digital medical images, examination parameters, diagnostic reports, patient data, and the like.

In 2 is one of the applications 8th of the DICOM network 1 shown in more detail. As can be seen from the illustration, application becomes 8th in the core by several, here for example two (software) components 12a and 12b , educated. Every component 12a and 12b comprises a number of (here two, for example) defined input interfaces 13a to 13d , over which of the respective component 12a respectively. 12b DICOM data sets D can be supplied. Every component 12a and 12b furthermore comprises a number of output interfaces (here in turn two in each case) 14a to 14d about which the respective component 12a respectively. 12b DICOM records D outputs.

For transmission and distribution of DICOM data sets D between the components 12a and 12b between each other as well as between one of the components 12a . 12b and an application-external component of the DICOM network 1 , z. B. one of the data storage 9a . 9b , is the application 8th a system 15 essentially assigned by a data sorting module 16 , a data output module 17 and a data distribution module 18 is formed. At the modules 16 to 18 These are software components that are part of a domain-specific (software) framework for medical imaging.

As a framework in this context, a software is understood, the actual applications 8th on the one hand and the operating system of the respectively associated work computer 6a to 6c or control computer 7a - 7c is interposed as a so-called middleware. A framework provides functionalities that are required regularly during application development in the form of generic, ie application-independent implemented components to which the applications 8th can access.

The data sorting module 16 is used for analysis and assignment of DICOM data sets D, the application 8th from an application-external component of the DICOM network 1 , in particular of one of the data memories 9a . 9b be supplied. To accommodate these DICOM records D includes the data sorting module 16 an external input interface 19 ,

The data sorting module 16 Furthermore, it also serves for intra-application distribution of DICOM data records D, which is the data sorting module 16 from one of the components 12a and 12b be transmitted. To accommodate these DICOM records D, the data sorting module 16 an internal input interface 20 on. To output the DICOM data sets D includes the data sorting module 16 two output interfaces 21a and 21b ,

The data output module 17 is used to output DICOM records D given to him by one of the components 12a . 12b or from the data sorting module 16 to one or more external components of the DICOM network 1 For example, to one of the data stores 9a or 9b , The data output module 17 is with several (here two) input interfaces 22a and 22b Mistake.

Both the data sorting module 16 as well as the data output module 17 are the application 8th specifically assigned and thus form almost an exclusive part of this application 8th ,

Regarding the DICOM data flow between the application 8th and external components of the DICOM network 1 take the data sorting module 16 and the data output module 17 each play a central role, insofar as all of the application 8th DICOM data sets D coming from the outside initially to the data sorting module for further distribution 16 approach while all of the application 8th DICOM data sets D transmitted to the outside via the data output module 17 be issued. A direct exchange of data between one of the components 12a and 12b with external components of the DICOM network 1 is not provided and preferred by the system 15 software excluded.

The components communicate with regard to the internal DICOM data flow 12a and 12b , the data sorting module 16 and the data output module 17 not directly with each other. Rather, the data distribution module takes over 18 Hereby a central switching function, by any DICOM data flow between the components 12a and 12b , the data sorting module 16 and the data output module 17 always indirectly via the data distribution module 18 is directed.

Unlike the data sorting module 16 and the data output module 17 is the data distribution module 18 not specific to the application 8th integrated, but implemented across applications. It is in particular with regard to its cycle life cycle (life cycle) of the application 8th decoupled. Furthermore, it can also be the DICOM data flow of several applications - in each case internal to the application 8th control simultaneously.

The assignment of the DICOM data records D fed to it takes the data distribution module 18 on the basis of so-called data function identifiers K (also referred to as "data roles"), which characterize the type and function of the respective DICOM data record D.

The application 8th externally supplied DICOM records D arranges the data sorting module 16 intended to a data function identifier K too. The data sorting module 16 in this case analyzes the DICOM data set D, in particular its data header (header), and selects from a DICOM attribute contained in the DICOM data set D with predetermined reference values on the basis of a comparison Number of available data function identifiers K the data function identifier K corresponding to the DICOM data record D.

The data sort module maps in the same way 16 also those DICOM data sets D a corresponding data function identifier K to him through the internal input interface 20 be supplied.

The data function identifiers K available for selection are for the most part not fixed as part of the implementation of the data sorting module 16 established. Rather, these data function identifiers K are represented by a data protocol 23 defined that the data sorting module 16 is assigned as (component-external) configuration information.

• – SOP Instance UID: Hierbei handelt es sich um eine automatisch erzeugte Identifikationskennung, die zur Identifizierung des Datenprotokolls verwendet wird;
• – Data Protocol Name: Name des Datenprotokolls;
• – Data Protocol Description: Ausführungen zu den mit dem Datenprotokoll verfolgten Zielen und Absichten;
• – Data Protocol Creator: Angaben, die den Autor oder die Erzeugungssoftware des Datenprotokolls identifizieren;
• – Data Protocol Creation Datetime: Angaben zum Datum und der Zeit, zu der das Datenprotokoll erzeugt wurde;
• – Data Protocol Definition Sequence: Hierbei handelt es sich um eine Angabensequenz, die den Typ bzw. die Typen von bildgebenden Untersuchungen spezifizieren, auf die das Datenprotokoll anwendbar ist. Diese Sequenz kann insbesondere einen oder mehrere Einträge der im Folgenden beschriebenen Art enthalten:
• – Modalität: Art der Modalität(en), d. h. der bildgebenden Einrichtung, die die dem DICOM-Datensatz D zugrunde liegenden Bilder ursprünglich erzeugt hat, auf die das Datenprotokoll anwendbar ist;
• – Anatomic Region Sequence: Diese Untersequenz definiert den anatomischen Interessenbereich, auf den das Datenprotokoll anwendbar ist;
• – Laterality: Bezeichnet die laterale Körperhälfte, auf die das Datenprotokoll anwendbar ist. Einsetzbar sind insbesondere R (right), L (left), B (both) und U (unpaired);
• – Procedure Code Sequence: Diese Untersequenz identifiziert das bzw. die Verfahren, auf die das Datenprotokoll anwendbar ist. Als „Verfahren” ist hierbei die an einem Patienten durchzuführende Behandlung bezeichnet;
• – Reason For Requested Procedure Code Sequence: Diese Untersequenz identifiziert einen Verfahrensgrund bzw. eine Verfahrensursache, auf die das Datenprotokoll anwendbar ist.
• – Data Role Sequence: Diese Sequenz umfasst Angaben zu einem Satz von Datenfunktionskennungen K, nämlich mindestens einen der folgenden Argumente:
• – Data Role Number: Hierbei handel es sich um einen Zähler, d. h. eine natürliche Zahl, die – mit 1 beginnend – mit jeder weiteren Datenfunktionskennung K um 1 hochgezählt wird;
• – Data Role Type: Eine Angabe, die den Typ des DICOM-Datensatzes D definiert, z. B. FRAME für 2D-Einzelbilder und VOLUME für 3D-Bilddatensätze;
• – Unsigned: Dieses Attribut identifiziert DICOM-Datensätze D, denen im Rahmen des Datenprotokolls 23 keine andere Datenfunktionskennung K zugewiesen werden kann;
• – Data Role Name: Diese Angabe beinhaltet den Namen der jeweiligen Datenfunktionskennung K;
• – Selector Operation Sequence: Diese Untersequenz definiert die Selektionskriterien, nach denen DICOM-Datensätze D einer bestimmten Datenfunktionskennung K zugeordnet werden. Insbesondere finden sich hier Angaben zu den DICOM-Attributen, die ein Datensatz D enthalten muss, um einer bestimmten Datenfunktionskennung K zugewiesen zu werden.

The data log 23 defines a data function identifier K by assigning an associated name and a set of rules which determine which incoming DICOM data records D should be "mapped" to this data function identifier K. The data log 23 , which is expediently in an XML format, can in particular contain the following entries (tags).

• SOP Instance UID: This is an automatically generated identification identifier used to identify the data protocol;
• - Data Protocol Name: Name of the data protocol;
• - Data Protocol Description: statements on the goals and intentions pursued by the data protocol;
• - Data Protocol Creator: information identifying the author or the data logging software;
• - Data Protocol Creation Datetime: the date and time the data log was generated;
• - Data Protocol Definition Sequence: This is an informational sequence specifying the type or types of imaging examinations to which the data protocol applies. In particular, this sequence may contain one or more entries of the type described below:
• Modality: type of modality (s), ie the imaging device, which originally generated the images underlying the DICOM record D to which the data protocol is applicable;
• - Anatomic Region Sequence: This subsequence defines the anatomical area of interest to which the data log is applicable;
• - Laterality: indicates the lateral body to which the data log is applicable. In particular, R (right), L (left), B (both) and U (unpaired) can be used;
• - Procedure Code Sequence: This subsequence identifies the method (s) to which the data protocol applies. The term "method" here refers to the treatment to be performed on a patient;
• Reason For Requested Procedure Code Sequence: This subsequence identifies a policy reason or a method cause to which the data log applies.
• - Data Role Sequence: This sequence contains information about a set of data function identifiers K, namely at least one of the following arguments:
• - Data Role Number: This is a counter, ie a natural number which, starting with 1, is incremented by 1 with each further data function identifier K;
• - Data Role Type: An indication defining the type of DICOM record D, e.g. B. FRAME for 2D still images and VOLUME for 3D image data sets;
• - Unsigned: This attribute identifies DICOM records D that are under the data log 23 no other data function identifier K can be assigned;
• - Data Role Name: This entry contains the name of the respective data function identifier K;
• Selector Operation Sequence: This subsequence defines the selection criteria according to which DICOM data sets D are assigned to a specific data function identifier K. In particular, information about the DICOM attributes which a data record D must contain in order to be assigned to a specific data function identifier K can be found here.

The configurable definition of at least a part of the data function identifiers K by means of the data protocol 23 opens up a possibility, the data function identifiers K flexible and individually different for each application 8th without the implementation of the data sorting module 16 to change yourself. The data sorting module 16 can thus be implemented generic, that is to say free of application-specific information, which makes reusability of this data sorting module possible 16 for different applications 8th allows.

• – eine Datenfunktionskennung K mit der Bezeichnung „DR.Print”, die einen zugeordneten DICOM-Datensatz D als zu druckende Information kennzeichnet sowie
• – eine weitere Datenfunktionskennung K mit der Bezeichnung DR.EvDoc (Evidence Documents), die solchen DICOM-Datensätzen D zugeordnet wird, die zum Transfer in einem medizinischen Bericht bestimmt sind, sowie
• – eine Datenfunktionskennung K mit der Bezeichnung „DR.Publ”, die anzeigt, dass der damit markierte DICOM-Datensatz D zur „Veröffentlichung”, d. h. zur Übermittlung an eine vorbestimmte applikationsexterne Komponente des DICOM-Netzes 1, z. B. zur Übermittlung an einen der Datenspeicher 9a, 9b, bestimmt ist.

Deviating from the rule to define the data function identifiers K by configuration are in a preferred embodiment of the data sorting module 16 nonetheless defines one or a few data function identifier (s) fixed in the implementation of the data sorting module itself. These data function identifiers K are standard data function identifiers K, which are particularly frequently required by various applications, in particular

• A data function identifier K labeled "DR.Print", which identifies an associated DICOM data record D as information to be printed, as well as
• Another data function identifier K named DR.EvDoc (Evidence Documents), which is assigned to such DICOM data records D intended for transfer in a medical report, as well as
• A data function identifier K with the designation "DR.Publ", which indicates that the thus marked DICOM data record D is for "publication", ie for transmission to a predetermined application-external component of the DICOM network 1 , z. B. for transmission to one of the data storage 9a . 9b , is determined.

The DICOM record classified with the data function identifier K can be - from the data sorting module 16 or one of the other components 12a . 12b - "as value" (by value) to the data distribution module 18 be handed over. In this case, the content of the DICOM record D is actually from the data sorting module 16 or one of the other components 12a . 12b to the data distribution module 18 postponed. To that of the application 8th but to keep the traffic caused as small as possible, is the data sorting module 16 and the components 12a . 12b preferably adapted to the DICOM record D "as a reference" (by reference) to the data distribution module 18 to hand over. In this case, the DICOM record D is not moved by itself. Rather, the data distribution module 18 together with the data function identifier K assigned to the DICOM data record D, pass a link or pointer to that memory location at which the DICOM data record D is stored.

To the data distribution module 18 to enable the transmitted DICOM data records D to the respectively desired target component 12a . 12b . 16 . 17 the application 8th pass on, the output interfaces 14a - 14d . 21a . 21b as well as at least partially the input interfaces 13a - 13d . 20 . 22a . 22b with associated data function identifiers K "marked". The data function identifiers K used for the marking indicate here which type or function of DICOM data records D via the respective input interface 13a - 13d . 20 . 22a . 22b from the respective component 12a . 12b . 16 . 17 is to be accepted or which type or function of DICOM data sets D via the respective output interface 14 - 14d . 21a . 21b is issued.

These tags are used by the data distribution module 18 the assignment of the DICOM data sets D transferred to it, by always passing these data records D to the input interface (s) 13a - 13d . 20 . 22a . 22b passes, which are marked in terms of their marking with the data function identifier K corresponding to the DICOM data set D.

The interface markers become the components 12a . 12b . 16 and 17 usually specified by configuration. It is therefore determined by a component-external configuration file, via which input interface 13a . 13d . 20 . 22a . 22b or output interface 14a -14d, 21a . 21b the respective component 12a . 12b . 16 . 17 which DICOM data sets D should accept or output.

As an alternative to the option of making the interface marking by configuration, the system offers 15 the option of having components 12a . 12b can automatically make one or more of their interface markers. In this case, it is provided in particular that the components 12a and 12b Interface markers dynamically at runtime of the respective component 12a and 12b can create, remove or change.

Every component 12a . 12b . 16 . 17 names the data function identifiers K, with which their respective input interfaces 13a - 13d . 20 . 22a . 22b and output interfaces 14a - 14d . 21a . 21b are marked in an associated interface description.

The information about the interface markings of the components 12a . 12b . 16 and 17 will be followed by a registration service 24 (Registration Service) designated submodule of the data distribution module 18 recorded and managed. The registration service 24 captures the information about the interface markers by the components 12a . 12b . 16 . 17 each assigned interface description reads.

A following as a data distribution service 25 designated submodule of the data distribution module 18 the DICOM data sets D transferred to the latter reach the respective target component of the application 8th by sending each DICOM record D to the or each input interface 13a - 13d . 20 . 22a . 22b transmitted, which is marked with the data function identifier K corresponding to the DICOM data set D.

• – jede Eingangsschnittstelle 13a–13d, 20, 22a, 22b ein Flag mit der Bezeichnung „UIActivateOnDataReceived” aktivieren, wodurch bewirkt wird, die Nutzerschnittstelle der zugeordneten Komponente 12a, 12b durch den Laufzeitmanager 26 automatisch hochgefahren wird, sobald der Eingangsschnittstelle 13a–13d zugestellt werden;
• – jede Eingangsschnittstelle 13a–13d, 20, 22a, 22b ein Flag mit der Bezeichnung „DataOverwriting” aktivieren, wodurch bewirkt wird, dass der Laufzeitmanager 26 bei der Zustellung neuer DICOM-Datensätze D an diese Eingangsschnittstelle 13a–13d, 20, 22a, 22b gegebenenfalls schon vorhandene alte Daten automatisch gelöscht werden;
• – jede Eingangsschnittstelle 13a–13d, 20, 22a, 22b ein Flag mit der Bezeichnung „Mandatory” aktivieren, wodurch bewirkt wird, dass durch den Laufzeitmanager 26 die betreffende Komponente 12a, 12b nur dann aktiviert werden kann, wenn Daten für diese Eingangsschnittstelle 13a–13d, 20, 22a, 22b angekommen sind;
• – jede Ausgangsschnittstelle 14a–14d, 21a, 21b ein Flag mit der Bezeichnung „PartialData” aktivieren, das anzeigt, dass über diese Ausgangsschnittstelle 14a–14d–21a, 21b nur ein Block (ein so genannter „Chunk”) eines größeren Datenpakets übertragen wurde;
• – eine Eingangsschnittstelle 13a–13d, 20, 22a, 22b ein Flag mit der Bezeichnung „DataRequireProcessing” aktivieren, wodurch bewirkt wird, dass die zugehörige Komponente 12a, 12b, 16, 17 automatisch durch den Laufzeitmanager 26 gestartet wird, sobald Daten an der Eingangsschnittstelle 13a–13d, 20, 22a, 22b angekommen sind. Die Flags „DataRequire-Processing” und „PartialData” wirken hier zusammen, so dass folgende Fälle existieren:
• – Wenn die sendende Ausgangsschnittstelle 14a–14d, 21a, 21b das „PartialData”-Flag aktiviert hat und die betreffende Eingangsschnittstelle 13a–13d, 20, 22a, 22b der Ziel-Komponente 12a, 12b, 16,17 das „DataRequireProcessing”-Flag aktiviert hat, wird die Ziel-Komponente 12a, 12b, 16, 17 durch den Laufzeitmanager 26 erst dann gestartet, wenn alle verbundenen und mit „PartialData” markierten Ausgangsschnittstellen 14a–14d, 21a, 21b Daten ausgeliefert haben, wenn also alle zusammengehörigen Daten-Chunks gesendet wurden;
• – Wenn an eine mit aktiviertem „DataRequire-Processing”-Flag markierte Eingangsschnittstelle 13a–13d, 20, 22a, 22b ein DICOM-Datensatz D von einer Ausgangsschnittstelle 14a–14d, 21a, 21b geliefert wurde, deren „PartialData”-Flag nicht aktiviert ist, wird die Ziel-Komponente 12a, 12b dagegen sofort aktiviert, sobald der DICOM-Datensatz D ausgeliefert wurde.

By means of a runtime manager 26 (Component Life Cycle Manager), which is another submodule of the data distribution module 18 The latter also adopts the life-cycle of the components 12a . 12b . 16 . 17 Influence by the data distribution module 18 DICOM records D are delivered. The type of influence is determined by display bits (so-called flags), which are each input interface 13a - 13d . 20 . 22a . 22b and / or output interface 14a - 14d . 21a . 21b assigned within the interface marking. In particular, can

• - each input interface 13a - 13d . 20 . 22a . 22b activate a flag named "UIActivateOnDataReceived", which causes the user interface of the associated component 12a . 12b through the runtime manager 26 is automatically started up as soon as the input interface 13a - 13d be delivered;
• - each input interface 13a - 13d . 20 . 22a . 22b enable a flag called "DataOverwriting," which causes the runtime manager 26 when delivering new DICOM records D to this input interface 13a - 13d . 20 . 22a . 22b possibly already existing old data are automatically deleted;
• - each input interface 13a - 13d . 20 . 22a . 22b enable a flag named "Mandatory" which causes the runtime manager to cause it 26 the component in question 12a . 12b can only be activated when data for this input interface 13a - 13d . 20 . 22a . 22b arrived;
• - each output interface 14a - 14d . 21a . 21b enable a flag called "PartialData" that indicates that this output interface 14a - 14d - 21a . 21b only one block (a so-called "chunk") of a larger data packet has been transmitted;
• - an input interface 13a - 13d . 20 . 22a . 22b enable a flag called "DataRequireProcessing", which causes the associated component 12a . 12b . 16 . 17 automatically by the runtime manager 26 is started as soon as data at the input interface 13a - 13d . 20 . 22a . 22b arrived. The flags "DataRequire-Processing" and "PartialData" work together here, so that the following cases exist:
• - If the sending output interface 14a - 14d . 21a . 21b has activated the "PartialData" flag and the relevant input interface 13a - 13d . 20 . 22a . 22b the target component 12a . 12b . 16 . 17 the "DataRequireProcessing" flag is turned on becomes the target component 12a . 12b . 16 . 17 through the runtime manager 26 only started when all connected output interfaces marked with "PartialData" 14a - 14d . 21a . 21b Have delivered data when all associated data chunks have been sent;
• - When to an input interface marked with "DataRequire-Processing" flag enabled 13a - 13d . 20 . 22a . 22b a DICOM record D from an output interface 14a - 14d . 21a . 21b delivered, whose PartialData flag is not enabled becomes the target component 12a . 12b however, activated immediately as soon as the DICOM data record D has been delivered.

An input interface 13a - 13d . 20 . 22a . 22b may also enable the flag named "UnassignedDataPort", causing this input interface to be caused 13a - 13d . 20 . 22a . 22b through the data distribution service 25 the data sent by the data sorting module 16 could not be assigned a specific data function identifier K and therefore marked as "unassigned".

The data distribution module 18 includes as another sub-module a data persistence service 27 , This service causes the DICOM data flow in the application 8th continuously "persisted", ie power fail-safe is stored, in case of a crash of the application 8th , the system 15 or the entire associated work computer 5a - 5c or control computer 7a - 7c Restore the data that has not yet been processed. To limit the persistence effort to the necessary, and thus to save computer resources, each output interface 14a - 14d . 21a . 21b activate a flag named "IgnoreReliableDataDuringWorkItemCompletion", causing a DICOM record D issued in this context to be triggered by the persistence service 27 not persisted.

• – ein als Wiederherstellungsdienst 28 bezeichnetes Untermodul, das nach einem Absturz anhand der persistierten Daten den letzten gesicherten Bearbeitungsstand wieder herstellt, sowie
• – ein als Sicherheitsdienst 29 bezeichnetes Untermodul, das – optional – den DICOM-Datenfluss verschlüsselt.

The data distribution module 18 further includes

• - as a recovery service 28 designated sub-module, which restores the last saved processing status after a crash based on the persisted data, as well as
• - as a security service 29 designated sub-module which - optionally - encodes the DICOM data flow.

In the example according to 2 this is the application 8th For example, a so-called "multi-modality reader", ie an image display software that is able to process images of various modalities and presented to the user in an appropriate form with appropriate tools and in each case suitable design.

In the example shown, the (useful) components 12a and 12b the application 8th each assigned to a particular modality. This is how the modality works 12a exemplifying the display and editing of computed tomography images while the component 12b the display and processing of magnetic resonance imaging images.

In an exemplary simplified embodiment, the application 8th according to 2 designed to display computed tomography images of the knee and head and magnetic resonance imaging of the lungs and arm.

• • DR.CT_Knie,
• • DR.CT_Kopf,
• • DR.MR_Lunge und
• • DR.MR_Arm.

Accordingly, by the application 8th specifically assigned data protocol 23 the following data function identifiers K are defined:

• • DR.CT_Knie,
• • DR.CT_head,
• • DR.MR_Lung and
• • DR.MR_Arm.

The abbreviation "DR." Stands for "Data Role".

A definition section of the data protocol defining these data function identifiers K 23 for example, is as follows:

• – Datensortierungsmodul 16:
• – Eingangsschnittstelle 20 („In1”): DR.EvDoc
• – Ausgangsschnittstelle 21a („Out1”): DR.Druck DR.CT_Knie, DR.MR_Lunge
• – Ausgangsschnittstelle 21b („Out2”): DR.Publ, DR.CT_Kopf, DR.MR_Arm
• – Komponente 12a:
• – Eingangsschnittstelle 13a („In1”): DR.CT_Kopf
• – Eingangsschnittstelle 13b („In2”): DR.CT_Knie
• – Ausgangsschnittstelle 14a („Out1”): DR.Druck
• – Ausgangsschnittstelle 14b („Out2”): DR.EvDoc
• – Komponente 12b:
• – Eingangsschnittstelle 13c („In1”): DR.MR_Lunge
• – Eingangsschnittstelle 13d („In2”): DR.MR_Arm
• – Ausgangsschnittstelle 14c („Out1”): DR.Druck
• – Ausgangsschnittstelle 14d („Out2”): DR.EvDoc
• – Datenausgabemodul 17:
• – Eingangsschnittstelle 22a („In1”): DR.Druck
• – Eingangsschnittstelle 22b („In2”): DR.Publ

The input interfaces 13a - 13d . 20 . 22a . 22b are marked with these data function identifiers K, for example, as follows:

• - Data sorting module 16 :
• - input interface 20 ("In1"): DR.EvDoc
• - Output interface 21a ("Out1"): DR.Druck DR.CT_Knie, DR.MR_Lunge
• - Output interface 21b ("Out2"): DR.Publ, DR.CT_Kopf, DR.MR_Arm
• - component 12a :
• - input interface 13a ("In1"): DR.CT_head
• - input interface 13b ("In2"): DR.CT_Knie
• - Output interface 14a ("Out1"): DR.Druck
• - Output interface 14b ("Out2"): DR.EvDoc
• - component 12b :
• - input interface 13c ("In1"): DR.MR_Lung
• - input interface 13d ("In2"): DR.MR_Arm
• - Output interface 14c ("Out1"): DR.Druck
• - Output interface 14d ("Out2"): DR.EvDoc
• - Data output module 17 :
• - input interface 22a ("In1"): DR.Druck
• - input interface 22b ("In2"): DR.Publ

Due to these interface markings, DICOM records D, for example, are taken from the output interface 21a of the data sorting module 16 with the data function identifier K "DR.CT_Knie" to the data distribution module 18 from this to the input interface 13b the component 12a transmitted.

Accordingly, the sort module 16 via the output interface 21b DICOM records D issued with the data function identifier "DR.MR_Arm" via the data distribution module 18 to the input interface 13d of the module 12b transmitted.

DICOM records D taken from the components 12a . 12b via the output interfaces 14b respectively. 14d with the data function identifier K "DR.EvDoc" are output from the data distribution module 18 to the input interface 20 of the data sorting module 16 retransmitted. The data sorting module 16 assigns these DICOM data sets D, for example, the data function identifier K "DR.Publ" and outputs them via the output interface 21b for forwarding to the data output module 17 again off.

3 shows an application of the system 15 according to 2 in which two applications 8th parallel to each other on the same workstation 6a to 6c or control computer 7a to 7c to run. The figure shows that in such a case, the data distribution module 18 the DICOM data flow of both applications 8th controls simultaneously and in parallel. The data distribution module 18 is thus cross-application for both applications 8th implemented. In contrast, each of the two applications 8th each a separate instance of the data sorting module 16 and the data output module 17 assigned.

In the example presented, this application-specific assignment is for instances of the data sorting module 16 and the data output module 17 but cancelable. This is how the system works 15 an instance of the data sorting module 16 or the data output module 17 if by the associated application 8th was not used for a given period of time, from this application 8th decoupled and placed in a reuse pool. Once the application 8th the functionality of the data sorting module 16 or the data output module 17 Once again, the reuse pool becomes an available instance of the respective module 16 or 17 reassigned.

LIST OF REFERENCE NUMBERS

1

DICOM network

2

MRI Scanner

3

CT Scanner

4

(X-ray) C-arm device

5a-c

reading station

6a-c

workstations

7a-c

tax calculator

8th

(Software) application

9a, b

data storage

10

printer

11

Communication link

12a, b

(Software) component

13a-d

Input interface

14a-d

Output interface

15

system

16

Data sorting module

17

Data output module

18

Data distribution module

19

(external) input interface

20

(internal) input interface

21a, b

Output interface

22a, b

Input interface

23

data protocol

24

registry service

25

Data Distribution Service

26

Runtime Manager

27

Datenpersitierungsdienst

28

Restore Service

29

security

D

DICOM data

K

Data Function ID

Claims (20)

Method for transmitting and distributing DICOM data (D) between components ( 12a . 12b . 16 . 17 ) at least one application ( 8th ) of a DICOM network ( 1 ), In which an incoming DICOM record (D) from a data sorting module ( 16 ) of a system ( 15 ) is analyzed for the transmission and distribution of DICOM data records (D), in which the DICOM data record (D) is analyzed by the data sorting module (D) 16 ) one of a plurality of predetermined data function identifiers (K) is assigned in accordance with the analysis result, - in which the analyzed DICOM data record (D) is assigned by the data sorting module ( 16 ) together with the associated data function identifier (K) to a data distribution module ( 18 ) of the system ( 15 ) for the transmission and distribution of DICOM data sets (D), and - in which the DICOM data set (D) is transmitted by the data distribution module (D) 18 ) based on the associated data function identifier (K) of at least one component ( 12a . 12b . 16 . 17 ) of the application ( 8th ). Method according to Claim 1, in which DICOM data (D) is transmitted by a data output module ( 17 ) to an application-external component ( 9a . 9b ) of the DICOM network ( 1 ). Method according to Claim 1 or 2, in which DICOM data sets (D) between the data sorting module ( 16 ), possibly the data output module ( 17 ) and all other components ( 12a . 12 ) of the application ( 8th ) exclusively via the data distribution module ( 18 ) be replaced. Method according to one of claims 1 to 3, in which by the data sorting module ( 16 ) to a data protocol assigned as configuration information ( 23 ), by which the data function identifiers (K) available for selection are defined in an application-specific manner. Method according to one of claims 1 to 4, in which by the data sorting module ( 16 ) via an internal input interface ( 20 ) one of another component ( 12a . 12b ) of the application ( 8th ) recorded DICOM record (D) is recorded. Method according to one of claims 1 to 5, in which by the data distribution module ( 18 ) at the same time the distribution of DICOM data records (D) within at least two applications ( 8th ) is controlled. System ( 15 ) for the transmission and distribution of DICOM data sets (D) between components ( 12a . 12b ) at least one application ( 8th ) of a DICOM network ( 1 ), with a data sorting module ( 16 ) and a data distribution module ( 18 ), - wherein the data sorting module ( 16 ) is adapted to analyze an incoming DICOM record (D) and to assign one of a plurality of predetermined data function identifiers (K) to the data record (D) in accordance with the analysis result, - the data sorting module ( 16 ) is adapted to the analyzed DICOM data record (D) together with the associated data function identifier (K) to the data distribution module ( 18 ), wherein the data distribution module ( 18 ) is adapted to the DICOM record (D) based on the associated data function identifier (K) at least one component ( 12a . 12b . 16 . 17 ) of the application ( 8th ) to hand over. System ( 15 ) according to claim 7, comprising a data output module ( 17 ), which is adapted to transfer DICOM data (D) to an application-external component ( 9a . 9b ) of the DICOM network. System ( 15 ) according to claim 7 or 8, wherein the data sorting module ( 16 ), optionally the data output module ( 17 ) and all other components ( 12a . 12b ) of the application ( 8th ) are designed to process DICOM data sets (D) exclusively via the data distribution module (D). 18 ) change. System ( 15 ) according to one of claims 7 to 9, wherein the data sorting module ( 16 ) is adapted to a data protocol assigned as configuration information ( 23 ), which defines the data function identifiers (K) available for selection in an application-specific manner. System ( 15 ) according to one of claims 7 to 10, wherein the data sorting module ( 16 ) an internal input interface ( 20 ) for receiving one of another component ( 12a . 12b ) of the application ( 8th ) DICOM record (D). System ( 15 ) according to one of claims 7 to 11, wherein the data sorting module ( 16 ), and optionally the data output module ( 17 ) an application ( 8th ) are assigned while the data distribution module ( 18 ) is implemented across applications. System ( 15 ) according to claim 12, wherein the specific assignment of the data sorting module ( 16 ) and optionally the data output module ( 17 ) at runtime of the application ( 8th ) is reversibly established and solvable. System ( 15 ) according to any one of claims 7 to 13, wherein the DICOM network ( 1 ) at least two applications ( 8th ) each having a data sorting module ( 16 ) and optionally a data output module ( 17 ) is specifically assigned. System ( 15 ) according to claim 14, wherein the data distribution module ( 18 ) is adapted to simultaneously manage the distribution of DICOM data records (D) within both applications ( 8th ) to control. System ( 15 ) according to claim 14 or 15, wherein the two applications ( 8th ) associated data sorting modules ( 16 ) are implemented the same way. System ( 15 ) according to any one of claims 7 to 16, wherein each component ( 12a . 12b . 16 . 17 ) of the or each application ( 8th ) at least one input interface ( 13a -d, 20 . 22a . 22b ) and / or at least one output interface ( 14a -d, 21a . 21b ) for recording or outputting a DICOM record (D), the input interface or interfaces ( 13a -d, 20 . 22a . 22b ) or output interface ( 14a -d, 21a . 21b ) is assignable by configuration at least one data function identifier (K), and as a result of this assignment the input interface ( 13a -d, 20 . 22a . 22b ) or output interface ( 14a -d, 21a . 21b ) accepts or outputs only DICOM records (D) with this data function identifier (K). System ( 15 ) according to any one of claims 7 to 17, wherein at least one component ( 12a . 12b ) of the or each application ( 8th ) at least one input interface ( 13a -D) and / or at least one output interface ( 14a -D) for receiving or outputting a DICOM data set (D), which at runtime ( 26 ) of the component ( 12a . 12b ) reversibly at least one data function identifier (K) is assignable. A computer program product comprising computer-readable instructions of a computer program on the basis of which the method according to one of claims 1 to 6 is performed when the computer program is stored on a data processing system ( 6a -d, 7a -D) expires. A storage medium having instructions of a computer program stored therein in computer-readable form, on the basis of which the method according to one of claims 1 to 6 is carried out when the computer program is stored on a data processing system ( 6a -d, 7a -D) expires.

Images