Method for integrating and executing applications implemented by a medical imaging platform - Patents.com

Abstract

The invention relates to a method (100) for integrating and executing a software application (A1) implemented by a medical imaging platform (4, 41) operating a file system (42). Such a method (100) comprises a step of reading (110) a contract (C1) dedicated to the software application (A1), the contract comprising access paths to input and / or output directories of the file system (42) for writing (120) and / or reading (140) values ​​of input / output data of the software application (A1). The invention further relates to a medical imaging platform suitable for executing such a method (100) for integrating and executing a software application (A1).

Description

[Technical field]

[0001] The present invention relates to a method for integrating and executing applications for analyzing medical images implemented by a medical imaging platform. [Background technology]

[0002] It is known to use medical imaging platforms to help doctors locate pathologies, optionally by various methods, for example using medical images acquired by magnetic resonance imaging (MRI) devices. Such medical imaging platforms are generally designed to host one or more software applications specialized to locate a given pathology (stroke, pneumonia, tumor, etc.), analyze a particular organ (brain, lung, chest, etc.), or estimate a particular physiological or hemodynamic parameter (tissue density, blood flow, or blood volume, etc.). In a hospital environment, medical images are generated from one or more medical imaging devices (MRI, scanner, etc.) and sent to the platform or stored in a Picture Archiving and Communication (PACS) server. Moreover, medical images are encoded and sent according to a specific protocol known as Digital Imaging and Communication in Medicine (DICOM) to facilitate the transfer of medical images between imaging devices and systems of different manufacturers.

[0003] Thus, a medical imaging platform hosts several software applications for processing several cases (in terms of pathology, organs, acquisition methods). The DICOM format allows additional meta-information to be associated with the image itself, based on which the medical imaging platform "decides" to start the execution of some software application. Thus, document US2019 / 0108905A1 describes an embodiment in which, depending on said DICOM meta-information, a configuration file of a data processing pipeline implementing several software applications (called filters) integrated on the platform can be selected from several configuration files or created in order to define the data processing process of such a medical image.

[0004] However, currently available platforms cannot always include all the software applications to meet the ever-increasing variety of cases, nor can they include the latest versions of the software applications to continue to benefit from the many technological innovations in this field. Therefore, it is necessary to enhance or update multiple software applications within fielded medical imaging platforms.

[0005] From a technical standpoint, a medical imaging platform is analogous to a computer that includes a processor unit consisting of an operating system of hardware (data or program memory, peripherals, etc.) and one or more microprocessors or microcontrollers that execute the program instructions of hosted software applications, said program instructions being located on one or more memories of the platform that communicate with the processor unit.

[0006] "Memory or storage means" means any computer memory, whether volatile or not. A non-volatile memory is a computer memory that, by its technology, is able to retain its data in the absence of power supply. It may contain data resulting from inputs, calculations, measurements and / or program instructions. The main non-volatile memories currently available are of the electrically writable type, such as EPROM (Erasable Programmable Read-Only Memory), or of the more electrically writable and erasable type, such as EEPROM (Electrically Erasable Programmable Read-Only Memory), Flash, SSD (Solid State Drive), etc. Non-volatile memories are distinguished from memories known as "volatile", whose data is lost in the absence of power supply. The main types of volatile storage devices currently available are RAM (Random Access Memory, also called "Read-Write Memory"), DRAM (Dynamic Random Access Memory, which requires periodic refreshing), SRAM (Static Random Access Memory, which requires such refreshing in the event of a power drop), DPRAM or VRAM (particularly suitable for video), etc.

[0007] Known medical imaging platforms have or require methods for software application integration. The most popular integration method uses the DICOM standard. According to this method, each software application is designed to process input data only in DICOM format and to provide results only in this same format, and furthermore, said data must comply with a specific communication protocol. However, this first integration method has significant drawbacks. Firstly, the DICOM format and protocol are not optimal for generating and sharing reports based on intermediate results generated by other software applications. Moreover, the DICOM standard does not allow easy configuration of software applications according to the specific circumstances of receipt and / or use of the imaging data to be analyzed.

[0008] Other known platforms have opted for a second integration method based on the use of application programming interfaces (APIs). This solution is advantageous since it facilitates access to configuration services for software applications and offers numerous opportunities to export results. On the other hand, this second method generally has significant drawbacks due to the fact that APIs are generally specific or dedicated to a given medical imaging platform or to a given manufacturer of such a platform. To be able to develop an application that can be integrated into a first medical imaging platform, the designer of the application must know the APIs required by said first platform and build his application on this API. If said application is to be integrated into a second platform that requires a second API different from the first API, said designer must change the design of his application and create a second software application. Moreover, it is difficult or even impossible for said designer to test the correct operation of the application before its deployment in the absence of a test platform provided for his use. For this purpose, the designer must prepare an emulator of said platform or a stub to simulate its behavior, which is not always possible or can be complicated or expensive.

[0009] At best, application developers can give their application's "business" code a certain degree of independence with respect to the format of the manipulated data, thanks to generating a description of the data that is sent along with the manipulated data, as shown in the document "Data description for data independence" by WCMcGee, a technique better known today as "Hexagonal Architecture". However, such teachings do not provide any solution to give the application independence with respect to the host platform. Summary of the Invention

[0010] The present invention overcomes the shortcomings arising from the prior art.

[0011] Among the many advantages achieved by the invention, it may be mentioned more specifically that it allows software applications to be designed independent of a specific medical imaging platform. Thanks to the invention, said software applications may use and / or generate data conforming to the DICOM standard or according to any other format. Thus, software applications are integrated into the medical imaging platform in the form of autonomous application modules that specify their dependencies and their inputs and outputs are read or written on the file system used by any medical imaging platform. Thus, the invention achieves a very high interoperability and no longer ties applications to a given type of platform, as is still the case today. Moreover, application designers have the ability to very easily test the behavior of their application before its deployment, without the need to get or take down the medical imaging platform for debugging purposes, its simulators / emulators or, as a variant, sophisticated stubs that are too limited to simulate all the functions of such a platform.

[0012] In the remainder of this document, "file system" refers to a medical imaging platform or any computer operated service that determines the organization of read or write accessible data in memory, or more generally in physical or logical volumes of such memory. As a standard, such a file system determines how to store said data and organizes them in logical structures known as files. Such a file system allows data to be processed, stored, and shared between several computer programs, such as the operating system of a computer resource (or, in this case, the medical imaging platform), and software applications that use the operating system to request said resources. Thus, a file system provides an abstract view of data stored in memory and allows read and / or write access thereto through access routes known as paths.

[0013] To this end, the present invention provides a method for integrating and executing software applications, said method being designed to be implemented by a medical imaging platform operating a file system, said method comprising: - retrieving a contract specific to a software application that generates output data based on input data, said contract comprising: a unique identifier representing said software application; an input virtual directory intended to store input data values ​​of the software application; an output virtual directory intended to store output data values ​​of the software application; - writing values ​​of input data of the software application to an input directory of the file system; - starting the execution of a software application represented by a unique identifier having as arguments an access path to an input directory of a file system and an access path to an output directory of said file system, said access paths being associated with the input virtual directory and the output virtual directory, respectively, retrieved from said contract; - reading the output data values ​​of the software application from an output directory of the file system.

[0014] In order to be able to easily configure the execution of a software application, a contract may include values ​​of operating parameters of said software application, in which case the step of initiating the execution of said software application of the method according to the invention may be adapted to include as arguments the values ​​of said operating parameters.

[0015] To achieve the integration of the software application, the method according to the invention may comprise a step of placing the software application and the contract in a memory of the software platform.

[0016] Advantageously, and in particular to facilitate pre-testing of software applications, a software application may take the form of a computer container, and a unique identifier representing said software application is included in said contract representing an image of said computer container.

[0017] Advantageously, an input virtual directory intended to store input data of a software application may be associated in the contract with an attribute specifying the optional or mandatory nature of said input data, in which case, if such attribute indicates the optional nature of said input data, the step of writing the input data may be performed only when such input data is available in the medical imaging platform.

[0018] The invention further provides for enriching output data generated by a software application integrated and executed according to the invention with meta-information. For this purpose, an output virtual directory intended to store values ​​of output data of a software application may be associated in a contract with a classification attribute of said output. Then, the step of retrieving the value of the output data of a software application may consist in associating said value of said classification attribute with the value of said output data.

[0019] In order to provide protection against any malicious modifications to a contract associated with a software application, the contract may be encoded prior to its integration into a platform or after any update thereof by the platform, in which case the step of reading a contract may include a prior sub-step of decrypting the contract.

[0020] According to a second object, the invention relates to a computer program comprising program instructions executable by a processor unit of a computer, said program instructions being resident in a non-volatile memory of said computer, the execution of said program instructions by said processor unit causing the process of integrating and executing a software application according to the invention to be performed.

[0021] According to a third object, the invention further relates to a computer-readable storage medium comprising instructions for such a computer program.

[0022] Finally, the invention further relates to a medical imaging platform comprising a processor unit and a memory used by a file system, said memory containing the program instructions of a computer program according to the invention.

[0023] Other features and advantages will become more clearly apparent from a reading of the following description and a review of the accompanying drawings. [Brief description of the drawings]

[0024] [Figure 1] FIG. 1 illustrates a medical imaging system that includes a medical imaging platform. [Diagram 2] FIG. 2 shows a simplified architecture of a medical imaging platform according to the present invention. [Diagram 3] FIG. 3 shows an example of a design of a software application that can be integrated and executed by a medical imaging platform according to the invention. [Figure 4] FIG. 4 illustrates a method for integrating and executing software applications with a medical imaging platform according to the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0025] FIG. 1 shows an example of a medical imaging system S comprising an imaging device 1. The magnetic resonance imaging device 1 provides a plurality of digital image sequences 12 of one or more parts of a patient's body, as non-limiting examples the brain, the heart, the lungs. The magnetic resonance imaging device 1 is generally controlled by means of a console 2. A user 6, for example an operator, a doctor or a researcher, may thus select commands 11 for controlling the imaging device 1 from parameters or instructions 16 entered via a human-machine input interface 8 of the analysis system S. Such a human-machine interface 8 may for example consist of a computer keyboard, a pointing device, a touch screen, a microphone or more generally any interface arranged to convert gestures or instructions given by a human 6 into data for controlling or configuring the imaging device 1. Based on information 10 generated by said device 1, a plurality of digital image sequences 12 of a part of a human or animal body are obtained.

[0026] The image sequence 12 may optionally be stored in a server 3 or in a PACS, i.e. a computer equipped with its own storage means, constituting a patient's medical file 13. Such a file 13 may contain different types of images, such as functional images showing tissue activity, or anatomical images representing tissue properties. The image sequence 12, or more generally the experimental data, is analyzed by said medical imaging platform 4 in order to generate text or graphic indicators 14 that can be visualized according to instructions 16 sent to the medical imaging platform 4 by a medical practitioner 6, by means of a human-machine output interface 5, which is provided for this purpose.

[0027] Fig. 2 shows an example of an architecture of a medical imaging platform 4 intended to be integrated into an imaging analysis system such as the system S shown in Fig. 1 according to the invention. Such a medical imaging platform 4 may include a processor unit in the form of one or more microprocessors or microcontrollers 41 implementing suitable application program instructions placed on a storage or memory means 45 of said imaging analysis system S. Read and / or write access by the processor unit 41 to said memory 45 may be managed by a file system 42. Said processor unit 41 advantageously communicates with an input / output module 43 responsible in particular for receiving a medical image sequence 12, or with a module 44 responsible for determining, based on said received image sequence 12, which one or more software applications among the available software applications A1, A2, An are worthy of implementation for analyzing said image sequence 12 with a view to generating a suitable quantity 14 of interest intended for the medical practitioner 6. Said software applications A1 to An, or more precisely the program instructions characterizing them, are pre-placed on the memory 45 of the platform 4. As will be explained below, each software application A1, A2, An is associated with a separate digital content of said software application dedicated to it, a digital content called "contract" C1, C2, Cn in the following. Thus, the program instructions of the software application A1 together with the contract C1 in the form of a digital content comprising information that can be used or interpreted by the processor unit 41 are placed in the memory according to the method 100 for integrating and executing software applications according to the invention, more specifically. A computer program comprising instructions that can be executed by the processor unit 41 of said platform 4 to adapt the operation of the medical imaging platform 4 is placed in the memory 45, said program instructions implementing such an integration and execution method 100.

[0028] Fig. 3 shows an example of a functional description of a software application according to the invention. Such a software application consists of digital processing related to one or more input data to generate one or more output data. By way of example, such a first software application may consist of an application aimed at classifying a stream of DICOM images 12 acquired by an X-ray imaging device and generating output data sorted by type, said images being enriched by one or more labels intended to classify said images. Such labels may be selected from a set of acronyms describing the acquisition method: "CTP" (Computed Tomography Perfusion), "CTA" (Computed Tomography Angiography), "NCCT" (Non-Contrast Computed Tomography). In a variant, such a first software application may use input data in the form of a DICOM image labeled "CTP" and generate, at the output, output data in the form of a chart showing hemodynamic parameters and a result report expressed in text format and intended to be finally sent by e-mail. The second software application may be designed to use input data in the form of a stream of DICOM images 12 acquired from a magnetic resonance imaging device and to generate output data sorted by type, said images being enriched with one or more labels intended to classify said images. Such labels may be selected from a set of acronyms describing the acquisition method of the imaging device: DWI (Diffusion Weighted Imaging), PWI (Perfusion Weighted Imaging), FLAIR (Fluid Attenuated Inversion Recovery).

[0029] Generally, as shown in FIG. 3, a software application A1 generates output data OD1, ..., ODj based on input data ED1, ..., EDi. Said input and / or output data may have different formats, e.g. text, DICOM, or other types, respectively. Moreover, the software application A1 may utilize one or more environment variables E1, ..., Ek. Such environment variables are sent to the software application during its execution, with the purpose of configuring said execution of the software application or the operations performed by it. According to a preferred embodiment, the application A1 may be defined in the form of a computer container, the image of which takes the form of a static file that contains an executable code (i.e. a set of program instructions) and defines the parameters or dependencies necessary for its execution. Such a technical choice of "containerization" of a software application may in particular simplify the step of testing the operation of the software application before its deployment, but thereby without the need for a test configuration similar to that of a medical imaging platform. Indeed, the pattern of the software application is clearly defined and the container image may be implemented and tested in the manner of a lightweight and modular virtual machine, like an autonomous application module. Let us first take the example of Docker technology, designed to handle Linux containers (Linux is a family of Unix (AT&T)-style open source operating systems created by Linus Torvalds). Let us assume that the image identifier AID of the software application A1 shown in FIG. 3 denotes the software application "my_application" version 1.0. The software application A1 can be created by executing the command " docker run \ - v / tmp / inputs / ED1: / inputs / ED1 \(arg1) - v / tmp / inputs / ED1: / inputs / EDi \(arg2) - v / tmp / outputs / OD1: / outputs / OD1 \(arg3) - v / tmp / outputs / ODj: / outputs / ODj \(arg4) - e E1=VALUE1 \(arg5) - e Ek=VALUEk \(arg6) my_application:1.0 ” \(arg7) This can be executed by the computer by manually invoking

[0030] The command argument (arg1) allows to define or determine a link (operation also known as "mapping") between the "physical" location or directory DED1 of the input data ED1 (in this case, according to the example shown in FIG. 2, a temporary directory in the file system 45 of the medical imaging platform 4 or more generally of the development or test computer) and a "virtual" directory VDED1 defined in the application module by the designer of the application A1 (in this case, in the example shown in FIG. 3, the virtual directory " / inputs / ED1"). Said directory DED1 is accessible via the access path DPED1 " / tmp / inputs / ED1". Thus, said software application A1, when executed, reads the values ​​of the input data ED1 from the virtual directory VDED1 " / inputs / ED1", but physically, i.e. in the memory 45 of the machine 4 implementing said software application A1, said virtual directory corresponds to the physical directory DED1 selected by the user, in this case the directory whose access path DPED1 is " / tmp / inputs / ED1".

[0031] Similarly, arguments (arg2), (arg3), and (arg4) define links between the virtual directories VDEDi “ / inputs / EDi”, VDOD1 “ / outputs / OD1”, and VDODj “ / outputs / ODj” and the physical directories DEDi “ / tmp / inputs / EDi”, DOD1 “ / outputs / OD1”, and DODj “ / outputs / ODj” for the data EDi, OD1, and ODj, respectively.

[0032] The arguments (arg5) and (arg6) make it possible to send the values ​​VALUE1 and VALUEk to the environmental variables E1 and Ek, respectively, of the application A1.

[0033] Finally, the command argument (arg7) indicates the identifier AID of the image of application A1, in this case "my_application" version 1.0.

[0034] The invention should not be considered limited only to this choice of implementing the software application in the form of containers or "Docker" technology. In a variant, it can rely on comparable solutions such as the "Podman" solution developed by the company Red Hat. The software application can also be composed of "standard" executable programs instead of containers. In all cases, a software application such as the application A1 described in FIG. 2 is associated with a separate digital content C1, known as a contract, so that a method for integrating and executing a software application according to the invention, such as the method 100, an example of which is shown in FIG. 4, is carried out. The execution of the software application can be started by unambiguously referencing it, for example by carrying this out by the module 44 shown in FIG. 2, by determining the link between the physical locations DED1, DEDi of the input data ED1, EDi, the physical locations DOD1, DODj of the output data OD2, ODj on the imaging platform 4, and the virtual or "internal" locations VDED1, VDEDi, VDOD1, VDODj in the application module, or by defining values ​​for the environment variables E1 to Ek. This cooperation between the contract C1 and the file system 42 can facilitate the integration and execution of software applications.

[0035] 2 and 3, the contract C1 thus comprises a set of fields or elements which can be distinguished from one another, for example by tags or any other equivalent technical means, so that before the very execution of the software application A1, the values ​​of the input data ED1, EDi, optionally set by the environmental variables E1, Ek, are written by the file system 42 into a memory location 45, and at the end of the execution of said software application A1, the output data OD1, ODj generated thereby can be used by said platform 4. The contract C1 associated with the software application A1 advantageously comprises: a software application A1, in this case in FIG. 3, a unique identifier AID of the container image, - values ​​EV1 and EVk assigned to environmental variables E1 and Ek, respectively, during the execution of said software application A1; - an input virtual directory VDED1, VDEDi intended to store values ​​of input data ED1, EDi of a software application A1; output virtual directories VDOD1, VDODj intended to store values ​​of the output data OD1, ODj of the software application A1;

[0036] More generally, such a contract C1 includes for each input data ED1, EDi or output data OD1, ODj virtual locations VDED1, VDEDi, VDOD1, VDODj for writing / reading the values ​​of said input data ED1, EDi or output data OD1, ODj. The presence of values ​​EV1, EVk assigned to environmental variables is optional, since a particular software application does not require operational parameters, such as for example to select a color palette from one or more repositories of the unit. The format of the contract is imposed by the medical imaging platform so that the medical imaging platform may have the ability to use (i.e. read and optionally update) said contract C1. On the other hand, the content of said contract C1 is imposed by the software application depending on the input data, output / environmental variables it needs. After incorporating a software application and its contract in the memory 45 of the medical imaging platform 4, it is the task of the platform operator or of the platform itself to modify and / or set said contract C1, for example by entering physical access paths DPED1, DPDEi, DPOD1, DPODj to the directories DED1, DEDi, DOD1, DODj of the file system 42 managing the memory 45 of said platform 4 for storing the input data ED1, EDi and output data OD1, ODj of said application A1, if said input directories DED1, DEDi and output directories DOD1, DODj are immutable, and to set the values ​​of environmental variables EV1, EVk, if they exist or are required. Preferably, said access paths DPED1, DPDi, DPOD1, DPODj are not recorded in the contract C1, in order to leave to the imaging platform 4 the task of allocating temporary directories DED1, DEDi, DOD1, DODj before the execution itself of the application A1.The determination of the links between the virtual directories VDE1, VDEi, VDO1, VDOj and the physical directories DED1, DEDi, DOD1, DODj is done by the arguments of the execution command, as shown above with reference to the application "my_application". Reference may be made to the step of configuring the software application A1 when it has been installed or placed in the memory 45, in order to authorize said any updates of the contract C1.

[0037] Fig. 4 shows an implementation and functional description of a method 100 for integrating and executing a software application according to the invention. Such a method 100 is implemented by a medical imaging platform, such as the platform 4 according to Fig. 1 and Fig. 2. The operation of the platform 4 is adapted by introducing into the memory 45 a computer program, the program instructions of which during their execution by the processor unit 41, optionally under the control of the decision module 44, result in the implementation of such a method 100. It can be envisaged that the memory 45 further contains a software application A1, for example in the form of a container associated with a contract C1, the contract C1 taking the form of a structured text file, i.e. arranged by appropriate tags, in the manner of the software application A1 and the contract C1 already described with reference to Fig. 3.

[0038] Implementation of the method 100 is initiated by receiving the medical image sequence 12 to be used by the processor unit 41, executing a software application A1 as deemed appropriate.

[0039] The main steps of the method 100 are indicated by solid white arrows in Fig. 4. Furthermore, processing steps relating to the software application A1 are indicated by solid black arrows in Fig. 4. Fig. 4 further depicts the interactions between the main "actors" involved in the implementation of the method 100, namely the processor unit 41 of the platform 4, the file system 42 operated thereby, the contract C1, and the software application A1.

[0040] Said method 100 comprises a first step 110 of reading from the memory 45 a contract C1 dedicated to the software application A1. To be sure, the software application A1 generates two output data OD1 and OD2 on the basis of input data ED1 and ED2. If the contract C1 comprises access paths DPED1, DPEDi to the directories DED1, DEDi of the file system 42 that must be used to initialize the values ​​of the input data ED1 and EDi, respectively, the processor unit 41 recognizes said access paths DPED1, DPEDi in a response (represented by thin dashed arrows). Similarly, if the contract C1 comprises access paths DPOD1, DPODj to the directories DOD1, DODj of the file system 42 that must be used to read the values ​​of the output data OD1 and ODj, respectively, that will be generated by the software application A1, the processor unit 41 recognizes said access paths DPOD1, DPODj. Moreover, the processor unit 41 may further recognize environmental variables E1, Ek optionally used by the software application A1, the values ​​EV1, EVk of which may be transmitted during the execution of the software application A1 itself.

[0041] In a variant, according to a more general case, said contract C1 is not subject to modification or configuration by the medical imaging platform 4. Moreover, step 110 of the method 100 comprises a sub-step (not shown in FIG. 4 for simplicity) of allocating or determining temporary directories DED1, DEDi of the file system 42 that must be used to initialize the values ​​of the input data ED1 and EDi, respectively, and directories DOD1, DODj of the file system 42 that must be used to read the values ​​of the output data OD1 and ODj, respectively.

[0042] Next, the method 100 comprises a step 120 of writing the values ​​of the respective input data ED1, EDi of the software application A1 into the input directories DED1, DEDi of the file system 42 specified by said contract C1 or determined by the medical imaging platform 4.

[0043] Said method 100 comprises a step 130 of starting the execution of a software application A1, the image of which is represented by the unique identifier AID obtained in step 110. Such a step 130 entails optionally sending, if required by the software application, the values ​​of environmental variables, in this case the values ​​EV1 and EVk of variables E1 and Ek. In order to determine the links between the physical input directories DED1, DEDi and output directories DOD1, DODj (i.e. those whose read / write access is managed by the file system) and the input virtual directories VDED1, VDEDi and output virtual directories VDOD1, VDODj, step 130 further comprises sending the access paths DPED1, DPEDi, DPOD1, DPODj to said input directories DED1, DEDi and output directories DOD1, DODj for the respective input data ED1, EDi and output data OD1, ODj in question. This step 130 therefore consists in automatically constructing the equivalent of the manual command described above with reference to the test of a software application "my_application" in the form of a container, the arguments necessary for the execution of the application being sent to said software application according to the requirements (elements, tags and / or order) specified by the contract C1.

[0044] The method 100 waits for the result of the execution of the software application A1 (by an execution report 240 generated by the software application A1, represented in FIG. 4 by a thin dashed arrow). Indeed, at the end of step 130, the processor unit 41 executes the application A1, which in turn includes a first step 210 intended to read the values ​​of the input data ED1 and EDi from the directories DED1, DEDi of the file system 42, and then executes a process 220 related to said input data ED1, EDi to generate the output data OD1, ODj. The values ​​of said output data are entered by the software application A1 in the directories DOD1, DODj of the file system 42 in step 230, since the link between the physical directory (memory 45 / file system 42) and the virtual directory is predetermined by the execution arguments sent in step 130 according to said contract C1. The execution of the software application A1 ends in a step 240 with the generation of an execution report indicating, for example, whether said execution has been carried out with or without errors.

[0045] Next, the method 100 according to the invention comprises a step 140 of reading the values ​​of the respective output data OD1, ODj of the software application A1 from the output directories DOD1, DODj of the file system 42 defined by the contract C1 or the platform 4.

[0046] At the end of the implementation of the method for integrating and executing the software application A1, the medical imaging platform 4 may start implementing a subsequent process intended to use the results generated by said application A1. Such a subsequent process may consist of a new instance of the method 100 resulting in the execution of a second software application A2, An.

[0047] Advantageously, the invention provides that a software application A1, A2, An may manage input or output data having optional properties. For this purpose, optional properties may be specified in a contract C1, C2, Cn associated to said application A1, A2, An. According to a preferred embodiment, with reference to the application A1 shown in Fig. 3, a field or element of said contract C1 determining a virtual directory VDED1, VDEDi intended to store input data ED1, EDi may be associated with an attribute specifying an optional or mandatory nature of said input data ED1, EDi. According to this embodiment, the method 100 according to the invention is adapted such that a step 120 of writing values ​​of input data ED1, EDi is performed only when such input data ED1, EDi are available in the medical imaging platform 4, if such an attribute indicates an optional nature of the input data ED1, EDi. The start of execution of the software application A1 will not cause an error even if there is no argument dedicated to such optional data in the command 130. Such an attribute may therefore consist of a Boolean value for characterizing such optional or mandatory nature of the input data. In a variant, the absence of such an attribute may indicate that the input data is mandatory in nature.

[0048] The same applies to output data OD1, ODj, which may be optional depending on the result generated by a software application such as application A1 according to Fig. 3. According to this embodiment, a field or element of said contract C1 determining a virtual directory VDOD1, VDODj intended to store output data OD1, ODi may be associated with an attribute specifying the optional or mandatory nature of said output data OD1, ODj. If such an attribute indicates the optional nature of said output data OD1, ODj, the output data OD1, ODj may include a determined value indicating a value of no interest. In this way, the processor unit 41 knows that such output data should be ignored if it indicates a value equal to said determined value.

[0049] Furthermore, the invention provides for adding one or more meta information such as labels or tags or, more generally, classification attributes for classifying the input data ED1, EDi and / or the output data OD1, ODj of a software application such as the application A1 according to Fig. 3. If such output data OD1, ODj can be enriched or classified by the presence of a label, a contract C1 associated with said software application A1 may be provided such that an output virtual directory VDOD1, VDODj intended to store the values ​​of the output data may be associated with such classification attribute of said output data OD1, ODj. In this case, step 140 (of the method 100 according to Fig. 4) of reading the value of the output data OD1, ODj in question may consist in associating said value of said classification attribute with the value of said output data. If the software application A1 does not provide such a classification, the contract C1 associated therewith does not associate such a classification attribute. On the other hand, the imaging platform 4 may update said contract C1 to add said classification attribute to the output virtual directory of the output data in question. Such enrichment of the output data generated by the software applications can therefore be utilised by the medical imaging platform 4 to select input data ED1, EDi for the software application A1 to enter into the input directories DED1, DEDi of the file system 42, or to select input data for other applications.

[0050] Moreover, the present invention provides an advantageous embodiment in which the contracts C1, C2, Cn associated with the software applications A1, A2, An can be securely updated or initialized. For this purpose, such contracts can be encrypted after any modification and decrypted during step 110 of the method 100 according to the present invention as illustrated in FIG. 4. Moreover, the identifier AID of the software application A1 can include a redundancy code (for example a hash value of said associated software application) so that the step 130 of starting the execution of the application includes a process of checking this redundancy code before starting the execution of the software application itself. If the calculated redundancy code matches the value written in the contract, the execution of the software application is authorized and started. Otherwise, said execution is aborted. In this way, the medical imaging platform 4 can verify that the contract is correctly associated with the appropriate version of said software application.

Claims

1. A method (100) for integrating and executing software applications (A1, A2, An) designed to be executed by a medical imaging platform (4, 41) operating a file system (42), said method (100) comprising: A step (110) of reading contracts (C1, C2, Cn) dedicated to software applications (A1, A2, An) generating output data (OD1, OD2) based on input data (ED1, ED2), said contracts (C1, C2, Cn) comprising: a unique identifier (AID) indicative of said software application (A1, A2, A3); input virtual directories (VDED1, VDEDi) intended to store values ​​of said input data (ED1, EDi) of said software applications; output virtual directories (VDOD1, VDODj) intended to store the values ​​of the output data (OD1, ODj) of the software applications (A1, A2, An); writing (120) values ​​of said input data (ED1, EDi) of said software applications (A1, A2, An) to input directories (DED1, DEDi) of said file system (42); starting (130) the execution of the software application (A1, A2, An) indicated by the unique identifier having as arguments access paths (DPED1, DPEDi, DPOD1, DPODj) to the input directory (DED1, DEDi) of the file system (42) and to the output directory (DOD1, DODj) of the file system (42), the access paths (DPED1, DPEDi, DPOD1, DPODj) being associated (130) with the input virtual directory (VDED1, VDEDi) and the output virtual directory (VDOD1, VDODj) read (110) from the contract (C1, C2, Cn), respectively; and reading (140) values ​​of the output data (OD1, ODj) of the software applications (A1, A2, An) from the output directories (DOD1, DODj) of the file system (42).

2. 2. The method (100) of claim 1, wherein the contracts (C1, C2, Cn) include values ​​(EV1, EVk) of operational parameters (E1, Ek) of the software applications (A1, A2, An), and the step (130) of starting execution of the software applications (A1, A2, An) is adapted to include the values ​​of the operational parameters as arguments.

3. The method (100) of claim 1 or 2, comprising the step of placing said software applications (A1, A2, An) and said contracts (C1, C2, Cn) on a memory (45) of said software platform (4).

4. 4. The method according to claim 1, wherein the software applications (A1, A2, An) are in the form of computer containers, and the unique identifiers (AID) representing the software applications (A1, A2, An) are included in the contracts (C1, C2, Cn) representing an image of the computer containers.

5. 5. The method according to claim 1, wherein the input virtual directories (VDED1, VDEDi) intended to store the input data (ED1, EDi) of the software applications (A1, A2, An) are associated in the contracts (C1, C2, Cn) with attributes specifying the optional or mandatory nature of the input data (ED1, EDi), and if such attributes indicate an optional nature of the input data (ED1, EDi), the step of writing it (120) is performed only when such input data (ED1, EDi) is available to the medical imaging platform (4).

6. 6. The method according to claim 1, wherein the output virtual directories (DOD1, DODj) intended to store values ​​of the output data (OD1, ODj) of the software applications (A1, A2, An) are associated in the contracts (C1, C2, Cn) with classification attributes of the outputs (OD1, ODj), and the step (140) of reading the values ​​of the output data (OD1, ODj) of the software applications (A1, A2, An) consists of associating the values ​​of the classification attributes with the values ​​of the output data (OD1, ODj).

7. 7. The method (100) according to claim 1, wherein the contracts (C1, C2, Cn) are encoded prior to their integration into the platform (4), and the step (110) of reading the contracts (C1, C2, Cn) comprises a preliminary sub-step of decoding the contracts.

8. A computer program comprising one or more program instructions executable by a processor unit (41) of a computer, the program instructions being capable of being stored on a non-volatile memory (45) of the computer, the execution of the program instructions by the processor unit (41) performing a method (100) according to any one of claims 1 to 7.

9. A computer readable storage medium comprising the instructions of the computer program of claim 8.

10. A medical imaging platform (4) comprising a processor unit (41) and a memory (45) used by a file system (42), said memory (45) containing the program instructions of the computer program according to claim 8.

Images