Methods for integrating and executing applications performed by a medical imaging platform

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 an application for analyzing medical images implemented by a medical imaging platform.

Background Art

[0002] It is known that a medical imaging platform is used by a physician, optionally, to assist in finding a pathology by using medical images acquired by various methods, for example, by a magnetic resonance imaging (MRI) device. Such a medical imaging platform is generally designed to host one or more software applications specialized for finding a predetermined pathology (such as stroke, pneumonia, tumor, etc.), analyzing a specific organ (such as brain, lung, chest, etc.), or estimating a specific physiological or hemodynamic parameter (such as 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 an image archiving and communication (PACS) server. Moreover, medical images are sent encoded according to a specific protocol known as digital imaging and communications in medicine (DICOM) to facilitate the transfer of medical images between imaging devices and systems of different manufacturers.

[0003] Therefore, a medical imaging platform hosts multiple software applications for handling multiple cases (with respect to pathology, organs, and acquisition methods). The DICOM format allows additional metadata to be associated with the image itself, and based on this, the medical imaging platform "decides" to start executing any of the software applications. Accordingly, document US2019 / 0108905A1 describes an embodiment in which, in order to define the data processing process for such medical images, a configuration file for a data processing pipeline that executes several software applications (called filters) built into the platform according to the said DICOM metadata can be selected from or created from a number of configuration files.

[0004] However, currently available platforms cannot always include all the software applications needed to accommodate the ever-increasing variety of cases, nor can they always include the latest versions of those software applications to keep up with the many technological innovations in this field. Therefore, it is necessary to enrich or update multiple software applications within the medical imaging platform deployed in the field.

[0005] From a technical standpoint, a medical imaging platform is similar to a computer that includes a processor unit comprising one or more microprocessors or microcontrollers that execute program instructions for hardware (data or program memory, peripherals, etc.) and hosted software applications. The program instructions are located in one or more memories of the platform that communicate with the processor unit.

[0006] "Memory or storage means" refers to any computer memory, whether volatile or not. Non-volatile memory is computer memory that, by its technology, can retain its data in the absence of power. It may contain data resulting from inputs, calculations, measurements, and / or program instructions. The main types of non-volatile memory currently available are electrically writable types such as EPROM (Erasable Programmable Read-Only Memory), or even more electrically writable and erasable types such as EEPROM (Electrically Erasable Programmable Read-Only Memory), flash memory, and SSDs (Solid State Drives). Non-volatile memory is distinguished from memory known as "volatile" memory, where data is lost when there is no 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 refreshes), SRAM (Static Random Access Memory, which requires such refreshes in the event of a power outage), DPRAM, or VRAM (particularly suitable for video).

[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 the DICOM format and provide results only in this same format, and furthermore, the data must conform to a specific communication protocol. However, this first integration method has significant drawbacks. Firstly, the DICOM format and protocol are not ideal for generating and sharing reports based on intermediate results produced by other software applications. Moreover, the DICOM standard does not allow for easy configuration of software applications depending on the specific circumstances of receiving and / or using the imaging data being 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 because it facilitates access to configuration services for software applications and provides 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 exclusive to a given medical imaging platform or a given manufacturer of such a platform. In order to develop an application that can be integrated into a first medical imaging platform, the application designer must know the API required by the first platform and build their application on this API. If the application is to be integrated into a second platform that requires a second API different from the first API, the designer must modify the design of their application and create a second software application. Moreover, for the designer, testing the correct operation of an application before its deployment is difficult or even impossible if there is no test platform provided for their use. For this purpose, the designer must have an emulator of the platform or a stub to simulate its behavior, which is not always possible or can be complex or expensive.

[0009] At best, application developers can give their application's "business" code some independence with respect to the format of the data being handled by generating a description of the data that is sent along with the data being handled, as shown in the WCMcGee document "Data description for data independence." This is a technique more commonly known today as "hexagonal architecture." However, such instruction does not provide any solution that gives the application independence with respect to the host platform. [Overview of the Initiative]

[0010] This invention overcomes the shortcomings of the prior art.

[0011] Among the many advantages achieved by the present invention, more specifically, it can be noted that the present invention allows for the design of software applications independently of a particular medical imaging platform. Thanks to the present invention, the software applications can utilize and / or generate data conforming to the DICOM standard or any other arbitrary format. Thus, the software applications are integrated into the medical imaging platform in the form of autonomous application modules specifying their dependencies, and their inputs and outputs are read from or written to a file system used by any medical imaging platform. Consequently, the present invention achieves extremely high interoperability and no longer associates applications with a given type of platform, as is still the case today. Moreover, the application designer has the ability to very easily test the operation of their application before its deployment without the need to obtain or remove the medical imaging platform for debugging purposes, its simulator / emulator, or, as a variation, sophisticated stubs that are too limited to simulate all the functions of such a platform.

[0012] For the remainder of this document, “filesystem” means a service operated by a medical imaging platform or any computer that determines the organization of read- or write-accessible data in memory, more generally in the physical or logical volumes of such memory. As a standard, such a filesystem determines how such data is stored and organizes it in logical structures known as files. Such a filesystem enables the processing, storage, and sharing of data among several computer programs, such as the operating system of a computer resource (or, in this case, a medical imaging platform) and software applications that use the operating system to access such resources. Thus, a filesystem provides an abstract representation of data stored in memory and enables read and / or write access to it from access routes known as paths.

[0013] For this purpose, the present invention provides a method for integrating and executing a software application, the method being designed to be implemented by a medical imaging platform operating a file system. Such a method is - A step of reading a contract specific to a software application that generates output data based on input data, wherein the contract is: ○ A unique identifier indicating the aforementioned software application, ○ An input virtual directory intended to store input data values ​​for a software application, ○ A step comprising digital content including an output virtual directory intended to store the output data values ​​of a software application, - A step of writing the values ​​of the input data of the software application to the input directory of the file system, - A step of starting the execution of a software application indicated by a unique identifier having access paths to the input directory of a file system and the output directory of the file system as arguments, wherein the access paths are associated with the input virtual directory and the output virtual directory read from the contract, respectively. - Includes the step of reading the values ​​of the output data of the software application from the output directory of the file system.

[0014] To facilitate the configuration of the execution of the software application, the contract may include values ​​for the operating parameters of the software application. In this case, the step of starting the execution of the software application in the method according to the present invention may be adapted to include the values ​​for the operating parameters as arguments.

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

[0016] To facilitate pre-testing of the software application, the software application may take the form of a computer container, and a unique identifier representing the software application may be included in the contract representing the image of the computer container.

[0017] Advantageously, an input virtual directory intended to store input data for a software application may be associated within the contract with an attribute specifying any or required nature of the input data. In this case, if such an attribute indicates any of the natures of the input data, the step of writing the input data may be performed only when such input data is available on the medical imaging platform.

[0018] The present invention further provides a way to qualitatively enhance output data generated by a software application integrated and executed in accordance with the present invention through metadata. For this purpose, an output virtual directory intended to store the values ​​of the software application's output data may be associated within the contract with the classification attributes of the output. The step of reading the values ​​of the software application's output data may consist of associating the values ​​of the classification attributes with the values ​​of the output data.

[0019] To provide protection against any malicious modifications to contracts associated with a software application, such contracts may be encoded before their integration into the platform or after any updates thereto by the platform. In this case, the step of reading the contract may include a prior substep of decrypting the contract.

[0020] According to a second object, the present invention relates to a computer program comprising program instructions that can be executed by a processor unit of a computer, wherein the program instructions may be placed in the non-volatile memory of the computer, and the execution of the program instructions by the processor unit carries out a process of integrating and executing a software application in accordance with the present invention.

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

[0022] Finally, the present invention relates to a medical imaging platform comprising a processor unit and memory used by a file system, wherein the memory contains program instructions for a computer program according to the present invention.

[0023] Other features and advantages will become clearer if you read the following explanation and examine the accompanying diagrams. [Brief explanation of the drawing]

[0024] [Figure 1] Figure 1 shows a medical imaging system including a medical imaging platform. [Figure 2] Figure 2 shows a simplified architecture of a medical imaging platform according to the present invention. [Figure 3] Figure 3 shows an example of the design of a software application that can be integrated and executed by a medical imaging platform according to the present invention. [Figure 4] Figure 4 shows a method for integrating and executing a software application by a medical imaging platform according to the present invention.

Best Mode for Carrying Out the Invention

[0025] Figure 1 shows an example of a medical imaging system S including 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, heart, and lungs. The magnetic resonance imaging device 1 is generally controlled using a console 2. Thus, a user 6, such as an operator, doctor, or researcher, can select a command 11 for controlling the imaging device 1 from parameters or instructions 16 input via the human-machine input interface 8 of the analysis system S. Such a human-machine interface 8 can be composed of, for example, a computer keyboard, a pointing device, a touch screen, a microphone, or any interface provided to convert gestures or instructions given by a human 6 into data for controlling or setting the imaging device 1. Based on the information 10 generated by the 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 a PACS, i.e., a computer equipped with its own storage means, and may constitute 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 characteristics. The image sequence 12, or more generally, experimental data, is analyzed by the medical imaging platform 4 to generate text or graphic indicators 14 that can be visualized according to instructions 16 sent to the medical imaging platform 4 by a healthcare professional 6 via a human-machine output interface 5. The medical imaging platform 4 is provided for this purpose.

[0027] Figure 2 shows an example architecture of a medical imaging platform 4 intended to be integrated into an imaging analysis system such as the system S shown in Figure 1, in accordance with the present invention. Such a medical imaging platform 4 may include processor units in the form of one or more microprocessors or microcontrollers 41 that implement appropriate application program instructions placed on the storage or memory means 45 of the imaging analysis system S. Read and / or write access to the memory 45 by the processor units 41 may be managed by a file system 42. The processor units 41 advantageously communicate with an input / output module 43 responsible in particular for receiving medical image sequences 12, or with a module 44 responsible for determining, based on the received image sequences 12, which one or more of the available software applications A1, A2, An is worthy of being implemented to analyze the image sequences 12 for the purpose of generating an appropriate amount 14 of interest intended for healthcare professionals 6. The software applications A1 to An, or more accurately, the program instructions characterizing them, are pre-placed on the memory 45 of the platform 4. As described later, each software application A1, A2, and An is associated with a separate digital content dedicated to that software application, hereinafter referred to as “contracts” C1, C2, and Cn. Accordingly, the program instructions for software application A1 are placed in memory together with contracts C1, which are in the form of digital content containing information that can be utilized or interpreted by the processor unit 41, in accordance with the method 100 for integrating and executing the software applications according to the present invention. To adapt the operation of the medical imaging platform 4, a computer program containing instructions that can be executed by the processor unit 41 of the platform 4 is placed in memory 45, and such integration and execution method 100 is carried out by the program instructions.

[0028] Figure 3 shows an example of a functional description of a software application according to the present invention. Such a software application consists of digital processing involving one or more input data to generate one or more output data. For 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, the images being qualitatively enhanced by one or more labels intended to classify the images. Such labels may be selected from a set of acronyms describing the acquisition method, such as "CTP" (computed tomography perfusion), "CTA" (computed tomography angiography), and "NCCT" (non-contrast computed tomography). In a modified example, such a first software application may use input data in the form of DICOM images labeled "CTP" and generate output data in the form of charts showing hemodynamic parameters and a results report expressed in text format and ultimately intended to be sent by email. A second software application may be designed to take input data in the form of a stream of DICOM images 12 acquired from a magnetic resonance imaging apparatus and generate output data sorted by type, wherein the images are qualitatively enhanced by one or more labels intended to classify the images. Such labels may be selected from a set of acronyms describing the acquisition method of the imaging apparatus: DWI (diffusion-weighted imaging), PWI (perfusion-weighted imaging), and FLAIR (fluid-attenuation inversion recovery).

[0029] Generally, as shown in Figure 3, software application A1 generates output data OD1, ..., ODj based on input data ED1, ..., EDi. The input and / or output data may each have different formats, e.g., text, DICOM, or other types. Furthermore, software application A1 may utilize one or more environment variables E1, ..., Ek. Such environment variables are sent to the software application for the purpose of setting the execution of the software application or the processing performed thereby during its execution. According to a preferred embodiment, application A1 may be defined in the form of a computer container, and its image takes the form of a static file containing executable code (i.e., a set of program instructions) and defining the parameters or dependencies necessary for its execution. Such a technical choice of "containerizing" the software application makes it possible to simplify the step of testing the operation of the software application, in particular, before its deployment, without requiring a test configuration similar to that of a medical imaging platform. In fact, the pattern of the software application is clearly defined, and the container image can be implemented and tested in the manner of a lightweight and modular virtual machine, like an autonomous application module. Let's start with an example of Docker® technology, which is designed to handle Linux® containers (Linux is a family of Unix® (AT&T)-type open-source operating systems created by Linus Torvalds). Let's assume that the identifier AID of the image of software application A1 shown in Figure 3 indicates version 1.0 of the software application "my_application". The aforementioned software application A1 contains commands, “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) It can be executed by a computer by manually calling it.

[0030] The command argument (arg1) can define or determine a link (an operation also known as "mapping") between the "physical" location or directory DED1 of the input data ED1 (in this case, a temporary directory on the file system 45 of the medical imaging platform 4 or more generally a development or test computer, as shown in the example in Figure 2) and the "virtual" directory VDED1 defined within the application module by the designer of application A1 (in this case, the virtual directory " / inputs / ED1" as shown in the example in Figure 3). The directory DED1 is accessible via the access path DPED1 " / tmp / inputs / ED1". Therefore, when the software application A1 is executed, it reads the value of the input data ED1 from the virtual directory VDED1 " / inputs / ED1", but physically, i.e., within the memory 45 of the machine 4 running the software application A1, the 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, the 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", respectively, for the data EDi, OD1, and ODj.

[0032] The arguments (arg5) and (arg6) allow the values ​​VALUE1 and VALUEk to be sent to the environment variables E1 and Ek of application A1, respectively.

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

[0034] The present invention should not be considered limited solely to this choice of implementing software applications in the form of containers or “Docker” technology. In modifications, it may rely on equivalent solutions such as the “Podman” solution developed by Red Hat. The software application may further consist of a “standard” executable program instead of a container. In all cases, for an example of implementation to be executed by a method for integrating and executing a software application according to the present invention, such as method 100 shown in Figure 4, a software application such as application A1 described in Figure 2 is associated with a separate digital content C1 known as a contract. For example, by executing this by module 44 shown in Figure 2, the execution of the software application may be initiated by unambiguously referencing it by determining the links between the physical locations DED1, DEDi and DOD1, DODj of the input data ED1, EDi and output data OD2, ODj on the imaging platform 4 and the virtual or “internal” locations VDED1, VDEDi, VDOD1, VDODj within the application module, or by defining values ​​for environment variables E1 to Ek. The joint operation of this contract C1 and the file system 42 facilitates the integration and execution of software applications.

[0035] Accordingly, referring to Figures 2 and 3, contract C1 includes a set of fields or elements that can be distinguished from one another by, for example, tags or any other equivalent technical means, and as a result, before the execution of the software application itself, which is optionally set by the environment variables E1, Ek, the values ​​of the input data ED1, EDi are written to memory location 45 by the file system 42, and at the end of the execution of the software application A1, the output data OD1, ODj generated thereby can be used by the platform 4. Contract C1 related to software application A1 is advantageous, -Software application A1, in this case, in Figure 3, the unique identifier AID of the container image and, -During the execution of the software application A1, the values ​​EV1 and EVk are assigned to the environment variables E1 and Ek, respectively. - Input virtual directories VDED1 and VDEDi are intended to store the values ​​of input data ED1 and EDi for software application A1. -This may include output virtual directories VDOD1 and VDODj, intended to store the values ​​of output data OD1 and ODj of 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 the input data ED1, EDi or output data OD1, ODj. The presence of values ​​EV1, EVk assigned to environment variables is optional, because a particular software application does not require operational parameters such as selecting a color palette from one or more repositories of a 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) the contract C1. On the other hand, the content of the contract C1 is imposed by the software application depending on the input data, output / environment variables it requires. After the software application and its contract are incorporated into the memory 45 of the medical imaging platform 4, it is the task of the platform operator or the platform itself to modify and / or set contract C1 by inputting, for example, physical access paths DPED1, DPDEi, DPOD1, DPODj to the directories DED1, DEDi, DOD1, DODj of the file system 42 that manages the memory 45 of the platform 4 for storing the input data ED1, EDi and output data OD1, ODj of the application A1, provided that the input directory DED1, DEDi and output directory DOD1, DODj are immutable, and to set the values ​​of environment variables EV1, EVk if they exist or are required. Preferably, the access paths DPED1, DPDi, DPOD1, DPODj are not recorded in contract C1 in order to leave the task of allocating the temporary directories DED1, DEDi, DOD1, DODj before the execution of the application A1 itself to the imaging platform 4.The determination of links between virtual directories VDE1, VDEi, VDO1, VDOj and physical directories DED1, DEDi, DOD1, DODj is done by the arguments of the execution command, as previously shown with reference to the application "my_application". To recognize the aforementioned arbitrary updates to contract C1, one may refer to the step of setting up software application A1 when it has finished being incorporated into or placed in memory 45.

[0037] Figure 4 shows an implementation and functional description of method 100 for integrating and executing a software application according to the present invention. Such method 100 is implemented by a medical imaging platform such as platform 4 shown in Figures 1 and 2. The operation of platform 4 is adapted by introducing a computer program into memory 45, and the implementation of such method 100 occurs when the program instructions are executed by a processor unit 41, optionally under the control of a decision module 44. It may also be assumed that memory 45 contains a software application A1 in the form of a container associated with contract C1, for example, contract C1, which takes the form of a structured text file, i.e., organized with appropriate tags, in the manner of software application A1 and contract C1 already described with reference to Figure 3.

[0038] Upon receiving the medical image sequence 12 used by the processor unit 41, the implementation of method 100 is initiated, and a software application A1 deemed appropriate is executed.

[0039] The main steps of the method 100 are indicated by solid white arrows in Figure 4. Furthermore, processing steps related to the software application A1 are indicated by solid black arrows in Figure 4. Figure 4 also illustrates the interactions between the main "actors" involved in the implementation of the method 100 (i.e., the processor unit 41 of platform 4, the file system 42 operated by it, contract C1, and software application A1).

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

[0041] In a modified example, according to a more general case, the contract C1 is not modified or configured by the medical imaging platform 4. Furthermore, step 110 of method 100 includes a substep (not shown in Figure 4 for simplicity) of allocating or determining temporary directories DED1 and DEDi of file system 42 which must be used to initialize the values ​​of input data ED1 and EDi, respectively, and directories DOD1 and DODj of file system 42 which must be used to read the values ​​of output data OD1 and ODj, respectively.

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

[0043] The method 100 includes a step 130 to start the execution of software application A1, the image of software application A1 being represented by a unique identifier AID obtained in step 110. Such step 130 optionally involves sending values ​​of environment variables, in this case the values ​​EV1 and EVk of variables E1 and Ek, if required by the software application. 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 access paths DPED1, DPEDi, DPOD1, DPODj to the input directories DED1, DEDi and output directories DOD1, DODj for the respective input data ED1, EDi and output data OD1, ODj. Therefore, step 130 consists of automatically configuring the equivalent of the manual commands described above by referring to the test of a software application "my_application" in the form of a container, and the arguments required for the execution of the application are sent to the software application according to the requirements (elements, tags, and / or order) specified by contract C1.

[0044] Method 100 awaits the execution result of software application A1 (represented by a thin dashed arrow in Figure 4, by an execution report 240 generated by software application A1). In fact, at the end of step 130, the processor unit 41 executes application A1, which in turn includes a first step 210 intended to read the values ​​of input data ED1 and EDi from directories DED1 and DEDi in file system 42, and then performs processing 220 related to the input data ED1 and EDi to generate output data OD1 and ODj. 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 the contract C1, the values ​​of the output data are placed in directories DOD1 and DODj in file system 42 by software application A1 in step 230. The execution of software application A1 ends with step 240 which generates an execution report indicating, for example, whether the execution was performed with or without errors.

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

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

[0047] Advantageously, the present invention provides that software applications A1, A2, An can manage input or output data having arbitrary properties. For this purpose, arbitrary properties can be specified in contracts C1, C2, Cn associated with the applications A1, A2, An. According to a preferred embodiment, referring to application A1 shown in Figure 3, a field or element of contract C1 that determines a virtual directory VDED1, VDEDi intended to store input data ED1, EDi can be associated with an attribute that specifies an arbitrary or required property of the input data ED1, EDi. According to this embodiment, method 100 according to the present invention is adapted so that if such an attribute indicates an arbitrary property of the input data ED1, EDi, step 120 is performed only when such input data ED1, EDi is available on the medical imaging platform 4. The start of execution of software application A1 will not produce an error even if there is no argument in command 130 dedicated to such arbitrary data. Thus, such an attribute may consist of a Boolean value for characterizing such arbitrary or required properties of the input data. In the modified example, the absence of such attributes may indicate that the input data is essentially essential.

[0048] The same applies to output data OD1, ODj, which may be arbitrary depending on the results generated by a software application such as application A1 in Figure 3. According to this embodiment, the fields or elements of contract C1 that determine the virtual directories VDOD1, VDODj intended to store the output data OD1, ODi may be associated with attributes that specify any or required properties of the output data OD1, ODj. If such attributes indicate any property of the output data OD1, ODj, the output data OD1, ODj may include determined values ​​that indicate values ​​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 the determined value.

[0049] Furthermore, the present invention provides for adding one or more metadata, such as labels or tags, or more generally, classification attributes for classifying input data ED1, EDi and / or output data OD1, ODj of a software application, such as application A1 in Figure 3. If such output data OD1, ODj can be qualitatively enhanced or classified by the presence of labels, the contract C1 associated with the software application A1 may be configured such that output virtual directories VDOD1, VDODj, intended to store the values ​​of the output data, can be associated with such classification attributes of the output data OD1, ODj. In this case, step 140 (of method 100 in Figure 4) for reading the values ​​of the output data OD1, ODj may consist of associating the values ​​of the classification attributes with the values ​​of the output data. If the software application A1 does not provide such classification, the associated contract C1 does not associate such classification attributes. On the other hand, the imaging platform 4 may update the contract C1 to add the classification attributes to the output virtual directories of the output data. Therefore, the qualitative improvement of output data generated by software applications can be utilized by the medical imaging platform 4 to select input data ED1, EDi for software application A1 that enters the input directories DED1, DEDi in the file system 42, or to select input data for other applications.

[0050] Furthermore, the present invention provides an advantageous embodiment in which contracts C1, C2, Cn associated with 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 method 100 according to the present invention, as shown in Figure 4. Furthermore, the identifier AID of software application A1 may include a redundant code (e.g., the hash value of the associated software application) so that step 130, which initiates the execution of the application, includes a process to verify this redundant code before initiating the execution of the software application itself. If the calculated redundant code matches the value written in the contract, the execution of the software application is authorized and initiated. Otherwise, the execution is aborted. In this way, the medical imaging platform 4 can verify that the contract is correctly associated with the appropriate version of the software application.

Claims

1. A method (100) for integrating and executing software applications (A1, A2, An) designed to be implemented by a medical imaging platform (4, 41) operating a file system (42), wherein the method (100) comprises: Step (110) of reading a contract (C1, C2, Cn) specifically for a software application (A1, A2, An) that generates output data (OD1, OD2) based on input data (ED1, ED2), wherein the contract (C1, C2, Cn) is A unique identifier (AID) representing the aforementioned software application (A1, A2, A3), An input virtual directory (VDDED1, VDDEDi) intended to store the values ​​of the input data (ED1, EDi) of the software application, Step (110) comprises digital content including an output virtual directory (VDDOD1, VDDODj) intended to store the values ​​of the output data (OD1, ODj) of the software application (A1, A2, An), Step (120) of writing the values ​​of the input data (ED1, EDi) of the software application (A1, A2, An) to the input directory (DED1, DEDi) of the file system (42), Step (130) of starting the execution of the software application (A1, A2, An) indicated by the unique identifier, which has as arguments the access paths (DPED1, DPEDi, DPOD1, DPODj) to the input directory (DED1, DEDi) and the output directory (DOD1, DODj) of the file system (42), wherein the access paths (DPED1, DPEDi, DPOD1, DPODj) are associated with the input virtual directory (VDDED1, VDDi) and the output virtual directory (VDDOD1, VDDj) read from the contract (C1, C2, Cn) (110), respectively. A method (100) comprising the step (140) of reading the values ​​of the output data (OD1, ODj) of the software application (A1, A2, An) from the output directory (DOD1, DODj) of the file system (42).

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

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

4. The method according to claim 1 or 2, wherein the software application (A1, A2, An) takes the form of a computer container, and the unique identifier (AID) representing the software application (A1, A2, An) is included in the contract (C1, C2, Cn) representing the image of the computer container.

5. The method according to claim 1 or 2, wherein the input virtual directory (VDDED1, VDDi) intended to store the input data (ED1, EDi) of the software application (A1, A2, An) is associated in the contract (C1, C2, Cn) with an attribute specifying any or required properties of the input data (ED1, EDi), and if such attribute indicates any property of the input data (ED1, EDi), the step (120) of writing it is performed only when such input data (ED1, EDi) is available on the medical imaging platform (4).

6. The method according to claim 1 or 2, wherein the output virtual directory (VDDOD1, VDDODj) intended to store the values ​​of the output data (OD1, ODj) of the software application (A1, A2, An) is associated with the classification attribute of the output data (OD1, ODj) within the contract (C1, C2, Cn), and the step (140) of reading the values ​​of the output data (OD1, ODj) of the software application (A1, A2, An) comprises associating the values ​​of the classification attribute with the values ​​of the output data (OD1, ODj).

7. The method according to claim 1 or 2 (100), wherein the contract (C1, C2, Cn) is encoded prior to its integration into the medical imaging platform (4), and the step of reading the contract (C1, C2, Cn) (110) includes a prior substep of decoding the contract.

8. A computer program comprising one or more program instructions that can be executed by a computer processor unit (41), wherein the program instructions may be placed on the computer's non-volatile memory (45), and the execution of the program instructions by the processor unit (41) implements the method (100) according to claim 1 or 2.

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

10. A medical imaging platform device (4) comprising a processor unit (41) and a memory (45) used by a file system (42), wherein the memory (45) includes the program instructions of the computer program described in claim 8.

Images