METHOD FOR INTEGRATION AND EXECUTION OF AN APPLICATION IMPLEMENTED BY A MEDICAL IMAGING PLATFORM

Description

[0001] The invention relates to a method for integrating and executing a medical image analysis application implemented by a medical imaging platform.

[0002] It is known to use a medical imaging platform to help a practitioner identify pathologies by exploiting medical images acquired possibly through different modalities, for example via a magnetic resonance imaging device, also known by the French acronym IRM or the Anglo-Saxon acronym MRI (for " Magnetic Resonance Imaging A medical imaging platform is designed to host one or more software applications, generally specialized to identify a given pathology (stroke, pneumonia, tumor, etc.), analyze a specific organ (brain, lung, breast, etc.), or estimate specific physiological or hemodynamic parameters (tissue density, blood flow or volume, etc.). In a hospital setting, medical images are generated from one or more medical imaging devices (MRI, CT scanners, etc.) and are transmitted to these platforms or archived on image archiving and transmission servers, also known by the abbreviation "PACS" (Program Access Console). Picture Archiving and Communication System » . Medical images are also encoded and transmitted according to a specific protocol, known as "DICOM," an English acronym for " Digital Imaging and Communications in Medicine " to facilitate the transfer of medical images between imaging devices and systems from different manufacturers.

[0003] A medical imaging platform thus hosts a plurality of software applications to process a plurality of cases (in terms of pathologies, organs, and acquisition modalities). The DICOM format allows for the association of additional metadata with the images themselves, from which a medical imaging platform "decides" to launch the execution of a particular software application. Thus, document US 2019 / 0108905A1 describes an embodiment in which, based on this DICOM metadata, a configuration file for sequencing the implementation of several applications (called filters) installed on a platform can be selected from among a plurality of configuration files, or even created, to define the processing of such medical images.

[0004] However, currently available platforms cannot at all times include all the software applications needed to address the ever-increasing diversity of cases, nor even the very latest versions of said software applications to continuously benefit from the numerous innovations in this field. It is therefore necessary to enrich or update the range of software applications within the medical imaging platforms deployed at various sites.

[0005] From a technical standpoint, a medical imaging platform is similar to a computer with a processing unit consisting of one or more microprocessors or microcontrollers that execute program instructions from an operating system, hardware resources (data or program memory, peripherals, etc.), and hosted software applications. These program instructions are loaded into one or more memory locations on the platform, which communicate with the processing unit.

[0006] The term "memory or storage device" refers to any computer memory, whether volatile or non-volatile. Non-volatile memory is computer memory whose technology allows it to retain its data in the absence of an electrical power supply. It can contain data resulting from input, calculations, measurements, and / or program instructions. The main non-volatile memories currently available are electrically writable, such as EPROM (" Erasable Programmable Read-Only Memory (according to Anglo-Saxon terminology) or electrically writable and erasable, such as EEPROM (" Electrically-Erasable Programmable Read-Only Memory "), flash, SSD (" Solid-State Drive (according to Anglo-Saxon terminology), etc. Non-volatile memories are distinguished from so-called "volatile" memories, whose data is lost when power is removed. The main volatile memories currently available are of the RAM type (" Random Access Memory " according to Anglo-Saxon terminology or also called "random access memory"), DRAM (dynamic random access memory, requiring regular updating), SRAM (static random access memory requiring such updating during an electrical under-powering), DPRAM or VRAM (particularly suitable for video), etc.

[0007] Common medical imaging platforms offer or mandate software application integration methods. The most widespread integration method utilizes the DICOM standard. Under this method, all software applications are designed to process only DICOM-formatted input data and deliver results only in the same format, with the data adhering to a specific transmission protocol. However, this integration method presents significant drawbacks. First, the DICOM format and protocol are not optimal for generating and sharing reports from intermediate results produced by other software applications. Furthermore, the DICOM standard does not allow for easy configuration of software applications based on specific contexts for receiving and / or processing the imaging data to be analyzed.

[0008] Other well-known platforms have opted for a second integration method based on the use of application programming interfaces, also known by the abbreviation API, from the Anglo-Saxon expression " Application Programming Interface This solution is advantageous because it facilitates access to configuration services for these software applications and opens up numerous possibilities for exporting results. However, this second approach generally presents a major drawback stemming from the fact that an API is usually specific to or dedicated to a given medical imaging platform or a given manufacturer of such platforms. To develop an application that can be integrated into a first medical imaging platform, the application designer must know the API required by that first platform and build their application around it. If the application is to be integrated into a second platform requiring a second API distinct from the first, the designer must modify the design of their application and produce a second software application.Furthermore, it is difficult, if not impossible, for the developer to test the proper functioning of an application before its release without a readily available test platform. This requires an emulator of the platform or a "stub" to simulate its behavior, which is not always available or can be complex or expensive.

[0009] At best, an application developer can introduce a degree of independence to an application's business logic regarding the format of the data it manipulates by generating a description of that data, transmitted concurrently with the manipulated data itself, as described in the document "Data Description for Data Independence" by W.C. McGee, SIGMOD RECORD, ACM, New York, NY, US, vol. 1, no. 2, December 1969 (1969-12), pages 3-10, ISSN: 0163-5808, DOI: 10.1145 / 983038.983039, a technique now better known as "hexagonal architecture." However, such a method offers no solution for granting the application independence from its host platforms.

[0010] The invention addresses the drawbacks raised by the prior art.

[0011] Among the many advantages provided by the invention, we can mention in particular that it allows for the design of software applications independently of any specific medical imaging platform. Thanks to the invention, these software applications can process and / or generate data conforming to the DICOM standard or any other format. Thus, the software applications are integrated into a medical imaging platform as autonomous application modules specifying their dependencies, whose inputs and outputs are read from or written to the file system operated by any medical imaging platform. The invention therefore provides a very high degree of interoperability, no longer tying an application to a specific type of platform, as is still the case today.Furthermore, an application designer has the ability to easily test the operation of their application before its release without requiring the acquisition or immobilization of a medical imaging platform for debugging purposes, a simulator / emulator of it, or a sophisticated plug, or alternatively, one too limited to simulate all the functionalities of such a platform.

[0012] Throughout this document, the term "file system" also known by the Anglo-Saxon terminology " File System The services operated by a medical imaging platform or any computer determine the organization of data accessible for reading or writing within a memory, or more generally within a physical or logical volume of such memory. Typically, such a file system determines how to store this data and organize it into logical structures called "files." Such a file system allows data to be processed, stored, and shared between several computer programs, such as a computer's operating system (or, in this case, a medical imaging platform) and the software applications that access these resources through the operating system. A file system thus provides an abstract view of the data stored in memory and allows access for reading and / or writing from an access path also called a "file path." path " according to Anglo-Saxon terminology.

[0013] The invention is specified by the attached independent claims. In addition, preferred embodiments are defined by the dependent claims.

[0014] To this end, the invention provides a method for integrating and executing a software application, said method being designed to be implemented by a medical imaging platform operating a file system. Such a method comprises: a step of loading a software application into a memory of the medical imaging platform; a step of writing the value of the input data of the software application into an input directory of the file system; a step of launching the execution of the software application; a step of reading the value of the output data of the software application into the output directory of the file system;said method being characterized in that said method further comprises: a. a step of loading a contract dedicated to said software application into said memory of the medical imaging platform, said contract consisting of digital content not modified or configured by said medical imaging platform, which includes information usable by the latter and imposed by the software application, said information describing: i. a unique identifier designating said software application which is thus associated with the contract dedicated to it; ii. a virtual input directory intended to contain a value of input data necessary for the execution of the software application;iii. a virtual output directory intended to contain the value of the output data produced by the latter, said step of loading said contract being carried out jointly with the loading of the associated software application into the memory of the medical imaging platform; b. a step of reading the contract dedicated to the associated software application by the presence of the unique identifier of the latter written in said contract, in order to know the requirements of said software application to be executed, said step of reading the contract preceding the step of launching the execution of said software application; the software application is an executable code designed and produced independently of the implementation of this integration and execution process or any other process implemented by the processing unit of said medical imaging platform;The step of launching the execution of the software application designated by said unique identifier taken from the previously read contract includes the transmission of execution arguments for the software application consisting of access paths to the input directory of the file system and to the output directory of said file system, said access paths being thus associated respectively with the virtual input and output directories of the software application by means of said execution arguments transmitted to the software application at the launch step of its execution in accordance with the content of the previously read contract at the reading step of said contract dedicated to said software application.

[0015] To facilitate configuration of the execution of a software application, the contract may include a value for an operating parameter of said software application. In this case, the step for launching the execution of said software application of a method according to the invention may be adapted to include the value of said operating parameter as an argument.

[0016] To achieve the integration of a software application, a method according to the invention includes a step of loading the software application and the contract into a memory of the medical imaging platform.

[0017] To advantageously facilitate, in particular, the preliminary testing of a software application, the latter may be presented in the form of a computer container, the unique identifier designating said software application included in said contract expressing the image of said computer container.

[0018] For the advantage of this feature, the virtual input directory intended to hold the software application's input data can be associated in the contract with an attribute specifying whether the input data is optional or mandatory. In this case, when such an attribute indicates that the input data is optional, the step of writing the input data can be implemented only if such input data is available to the medical imaging platform.

[0019] The invention also provides for enriching output data produced by an integrated software application and executed according to the invention with metadata. To this end, the virtual output directory intended to contain the value of the software application's output data can be associated in the contract with a type attribute of said output. The step of reading the value of the software application's output data can then consist of associating said value of said type attribute with the value of said output data.

[0020] To prevent malicious modification of a contract associated with a software application, the contract may be encrypted prior to its integration into the platform, or even after any update to the contract by the platform. In this case, the contract reading step may include a preliminary substep of decoding the contract.

[0021] According to a second object, the invention relates to a computer program product comprising program instructions executable by the processing unit of a computer, said program instructions being loadable into a non-volatile memory of said computer and the execution of which by said processing unit causes the implementation of a method for integrating and executing a software application according to the invention.

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

[0023] Finally, the invention further relates to a medical imaging platform comprising a processing unit, a memory operated by a file system, said memory comprising the program instructions of a computer program product according to the invention.

[0024] Other features and advantages will become clearer upon reading the following description and examining the accompanying figures, including: there figure 1 illustrates a medical imaging system comprising a medical imaging platform; the figure 2 illustrates the simplified architecture of a medical imaging platform according to the invention; the figure 3 illustrates an example of the design of a software application that can be integrated and executed by a medical imaging platform according to the invention; the figure 4 illustrates a method of integrating and executing a software application by a medical imaging platform according to the invention.

[0025] There figure 1 This illustrates an example of a medical imaging system S comprising an imaging device 1. This device delivers a plurality of digital image sequences 12 of one or more parts of a patient's body, by way of non-limiting examples, the brain, heart, and lungs. The magnetic resonance imaging device 1 is generally controlled using a console 2. A user 6, for example an operator, practitioner, or researcher, can thus select commands 11 to operate the imaging device 1 based on parameters or instructions 16 entered via an input human-machine interface 8 of the analysis system S. Such a human-machine interface 8 may consist, for example, of a computer keyboard, a pointing device, a touchscreen, a microphone, or, more generally, any interface arranged to translate a gesture or instruction issued by a human 6 into control or parameterization data for an imaging device 1.From information 10 produced 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 sequences 12 can optionally be stored on a server 3 or PACS, i.e., a computer with its own storage capacity, and constitute a patient's medical record 13. Such a record 13 can include images of different types, such as functional images highlighting tissue activity or anatomical images reflecting tissue properties. The image sequences 12, or more generally the experimental data, are analyzed by a medical imaging platform 4 designed for this purpose to produce textual or graphic indicators 14 that can be viewed via an output human-machine interface 5 by healthcare personnel 6 according to instructions 16 addressed to said medical imaging platform 4.

[0027] There figure 2 describes an example of the architecture of a medical imaging platform 4 according to the invention and intended to be integrated into an imaging analysis system such as the S system illustrated by the figure 1 . Such a medical imaging platform 4 may include a processing unit in the form of one or more microprocessors or microcontrollers 41 implementing instructions of suitable application programs loaded into storage means or memory 45 of said imaging analysis system S. Read and / or write access to said memory 45 by the processing unit 41 may be governed by a file system 42.The said processing unit 41 is advantageously in communication with an input / output module 43 charged in particular with receiving the medical image sequences 12, or even with a module 44 charged with determining, from the said received image sequences 12, which software application(s) among available software applications A1, A2, An deserve to be implemented to analyze the said image sequences 12 in order to produce relevant quantities of interest 14 for healthcare personnel 6. The said software applications A1 to An are previously, or more precisely the program instructions that characterize them, loaded into memory 45 of the platform 4.As we will study later, each software application A1, A2, An is associated with a digital content distinct from said software application and dedicated to it, a digital content which we will subsequently call a "contract" C1, C2, Cn. Thus, along with the loading of the program instructions of the software application A1, a contract C1 is loaded in the form of digital content containing information usable or interpretable by the processing unit 41, more precisely according to a method 100 for integrating and executing software applications according to the invention. To adapt the operation of the medical imaging platform 4, a computer program containing instructions executable by the processing unit 41 of said platform 4 is loaded into memory 45, said program instructions triggering the implementation of such an integration and execution method 100.

[0028] There figure 3 illustrates an example of a functional description of a software application within the meaning of the invention. Such a software application consists of digital processing of one or more input data to produce one or more output data. By way of example, such a first software application could consist of an application designed to categorize a stream of DICOM 12 images acquired by an X-ray imaging device and produce output data sorted by type, said images being enriched by one or more labels designed to qualify said images. Such labels could be chosen from a set of acronyms such as "CTP", "CTA", "NCCT", or from Anglo-Saxon expressions computed tomography perfusion " computed tomography angiography " non-contrast computed tomography qualifying acquisition methods. Alternatively, such a first software application could use input data in the form of DICOM images labeled "CTP" and produce output data in the form of cards illustrating a hemodynamic parameter and a results report expressed in text format and intended to be communicated ultimately by email. A second software application could be designed to use input data in the form of a stream of DICOM images acquired from a magnetic resonance imaging device and produce output data sorted by type, said images being enriched by one or more labels intended to qualify said images. Such labels could be chosen from a set of acronyms "DWI", "PWI", "FLAIR", or from Anglo-Saxon expressions diffusion-weighted imaging " perfusion-weighted imaging " fluid-attenuated inversion recovery » describing the methods of data acquisition for the imaging device.

[0029] In general, and as illustrated by the figure 3 A software application A1 produces output data OD1, ..., ODj from input data ED1, ..., EDi. This input and / or output data can be in various formats, such as text, DICOM, or others. A software application A1 can also use one or more environment variables E1, ..., Ek. These environment variables are passed to the software application during its execution to configure its execution or the processes it performs. In a preferred embodiment, the application A1 can be defined as a computer container whose image is a static file containing executable code (i.e., a set of program instructions) and defining the parameters or dependencies necessary for its execution.This technical choice of "containerizing" software applications simplifies the testing phase of a software application's functionality before deployment, without requiring a test setup similar to that of a medical imaging platform. Indeed, the software application's "pattern" is clearly defined, and the container image can be implemented and tested as a standalone application module, much like a lightweight, modular virtual machine. Consider the example of Docker technology, initially designed to handle Linux containers (a family of open-source, Unix-like operating systems (AT&T) created by Linus Torvalds). Let's assume that the AID identifier of the software application image A1, illustrated by the image... figure 3 refers to version 1.0 of the software application "my_application". An execution of said software application A1 by a computer could be triggered by manually invoking 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)

[0030] The argument (arg1) of the command allows you to define or resolve a link (an operation also known as "mapping" in Anglo-Saxon terminology) between the "physical" location or directory DED1 of the input data ED1 (in this case, according to the example illustrated by the figure 2 a temporary directory of the file system 45 of a medical imaging platform 4 or more generally of a development or test computer) said directory DED1 being accessible via the access path DPED1 " / tmp / inputs / ED1" and the "virtual" directory VDED1 (in this case in the example illustrated by the figure 3 , the virtual directory " / inputs / ED1") defined by the designer of application A1 in the application module. Thus, when said software application A1 is executed, the latter reads the value of the input data ED1 from the virtual directory VDED1 " / inputs / ED1" while physically, that is to say in the memory 45 of the machine 4 implementing said software application A1, said virtual directory corresponds to a physical directory DED1 chosen by said user, in this case the directory whose access path DPED1 is " / tmp / inputs / ED1".

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

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

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

[0034] The invention is not limited to the single choice of implementing a software application in the form of a container or using Docker technology. Alternatively, it could rely on an equivalent solution such as the Podman solution developed by Red Hat. A software application could also consist of a "classic" executable program instead of a container. In all cases, to be used by a software application integration and execution method conforming to the invention, such as method 100, an example of which is illustrated in the following: figure 4 , a software application, such as application A1 described by the figure 2 , is associated with third-party digital content C1, called a contract. Through the use of this contract, for example by module 44 illustrated in figure 2 The execution of a software application can be triggered by unambiguously designating it, resolving the links 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 of the application module, or even by setting values ​​to environment variables E1 to Ek. It is the combined use of this contract C1 and the file system 42 that facilitates the integration and execution of a software application.

[0035] Thus, in connection with the figure 2 and the figure 3 A contract C1 comprises a set of fields or elements, distinguishable from one another, for example, by tags or any other equivalent technical means, so that prior to the execution of a software application possibly parameterized by environment variables E1, Ek, the values ​​of the input data ED1, EDi are written to memory locations 45 via the file system 42, and that, upon completion of the execution of said software application A1, the output data OD1 and ODj produced by it can be used by said platform 4. The contract C1, associated with the software application A1, may advantageously include: the unique AID identifier of the software application A1, in this case on the figure 3 , the container image; the EV1 and EVk values ​​to be assigned respectively to the environment variables E1 and Ek during the execution of said software application A1; the virtual input directories VDED1, VDEDi intended to contain the values ​​of the input data ED1, EDi of the software application A1; the virtual output directories VDOD1, VDODj intended to contain the values ​​of the output data OD1, ODj of the software application A1.

[0036] More generally, such a C1 contract includes, for each input data ED1, EDi or output data OD1, ODj, the virtual locations VDED1, VDEDi, VDOD1, VDODj for writing / reading a value of said input data ED1, EDi or output data OD1, ODj. The presence of an EV1, EVk value to be assigned to an environment variable is optional; some software applications do not require such operating parameters, for example, to select a color palette from a plurality or a unit reference. The format of a contract is imposed by the medical imaging platform so that it can use (i.e., read and possibly update) said C1 contract. Conversely, the content of said C1 contract is imposed by the software application according to the input data, outputs / environment variables it requires.After installation of the software application and its contract in memory 45 of the medical imaging platform 4, it is up to the platform operator or the platform itself to modify and / or configure said contract C1 for example by writing the physical access paths DPED1, DPDEi, DPOD1, DPODj to the directories DED1, DEDi, DOD1, DODj of the file system 42 governing the memory 45 of said platform 4 to store 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, as well as to set the values ​​of environment variables EV1, EVk if they exist or are required.Preferably, the aforementioned access paths DPED1, DPDEi, DPOD1, and DPODj are not included in contract C1, allowing the imaging platform 4 to allocate temporary directories DED1, DEDi, DOD1, and DODj prior to the execution of application A1. The resolution of the links between the virtual directories VDE1, VDEi, VDO1, and VDOj and the physical directories DED1, DEDi, DOD1, and DODj is performed using the arguments of the execution command, as illustrated previously in relation to the application "my_application". We can refer to this optional update of contract C1 as a configuration step for software application A1 following its installation or loading into memory 45.

[0037] There figure 4 This illustrates the 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 platform 4 according to the figure 1 and the figure 2 The operation of the latter is adapted by the implantation in memory 45 of a computer program whose program instructions, when executed by the processing unit 41 under the possible control of a decision module 44, trigger the implementation of such a process 100. Let us suppose that memory 45 also contains the software application A1, for example in the form of a container associated with a contract C1, the latter being in the form of a structured text file, that is to say, arranged by means of appropriate tags, like the software application A1 and the contract C1 already described in connection with the figure 3 .

[0038] The reception of a sequence of medical images 12 used by the processing unit 41 triggers the implementation of process 100 to cause the execution of the software application A1 deemed relevant.

[0039] The main steps of said process 100 are illustrated by solid white arrows on the figure 4 Furthermore, the steps of a process specific to the software application A1 are illustrated by solid black arrows on the said figure 4 . The latter further describes the interactions between the main "actors" involved in the implementation of said process 100 (i.e. the processing unit 41 of the platform 4, the file system 42 operated by the latter, the contract C1 and the software application A1).

[0040] The said process 100 includes a first reading step 110 in the memory 45 of the contract C1 dedicated to the software application A1. As a reminder, the latter produces two output data OD1 and OD2 from input data ED1 and ED2. When the contract C1 contains the access paths DPED1, DPEDi to directories DED1, DEDi of the file system 42 which must be used to initialize values ​​of the input data ED1 and EDi respectively, the processing unit 41 knows in response (symbolized by a dashed thin arrow) the said access paths DPED1, DPEDi. Similarly, when contract C1 includes the access paths DPOD1, DPODj to directories DOD1, DODj of file system 42 which are to be used to read values ​​of output data OD1 and ODj which will be produced by software application A1 respectively, processing unit 41 knows said access paths DPOD1, DPODj.The said processing unit 41 may also know in addition the environment variables E1, Ek possibly used by the software application A1 whose values ​​EV1, EVk will be transmitted during the execution as such of the said software application A1.

[0041] Alternatively, in a more general case, said contract C1 was not modified or configured by the medical imaging platform 4. Step 110 of process 100 further includes a substep (not shown for simplification purposes on the figure 4 ) allocation or determination of temporary directories DED1, DEDi of file system 42 which are to be used to initialize values ​​of input data ED1 and EDi respectively and directories DOD1, DODj of file system 42 which are to be used to read values ​​of output data OD1 and ODj respectively.

[0042] The process 100 now includes a step 120 of writing the value of each input data ED1, EDi of the software application A1 into the input directory DED1, DEDi of the file system 42 as specified by said contract C1 or determined by the medical imaging platform 4.

[0043] The said process 100 includes a launch step 130 of the execution of the software application A1 whose image is designated by the unique identifier AID taken from step 110. Such a step 130 is accompanied by the possible transmission of values ​​of environment variables when the software application requires it, in this case the EV1 and EVk values ​​of the variables E1 and Ek. To resolve the links between the physical input directories DED1, DEDi and output directories DOD1, DODj (i.e., those whose read / write access is governed by the file system) and the virtual input directories VDED1, VDEDi and output directories VDOD1, VDODj, step 130 further involves passing the paths DPED1, DPEDi, DPOD1, DPODj to said input directories DED1, DEDi and output directories DOD1, DODj for each relevant input data ED1, EDi and output data OD1, ODj.This step 130 consists of automatically creating an equivalent of the manual command mentioned earlier in connection with the test of the software application "my_application" in the form of a container, the arguments necessary for the execution of the application being passed to said software application in accordance with the requirements (elements, tags and / or order) specified by the C1 contract.

[0044] Process 100 remains pending the result of the execution of software application A1 (via an execution report 240 produced by the latter, symbolized by a dashed thin arrow on the figure 4 ). Indeed, at the end of step 130, the processing unit 41 implements the application A1 which in turn includes a first step 210 aimed at reading the values ​​of the input data ED1 and EDi in the directories DED1, DEDi of the file system 42, then implements a processing 220 on the said input data ED1, EDi to produce output data OD1, ODj. The links between the physical (memory 45 / file system 42) and virtual directories having been previously resolved by the execution arguments passed in step 130 in accordance with said contract C1, the values ​​of said output data are written by the software application A1 in a step 230 in the directories DOD1, DODj of the file system 42. The implementation of the software application A1 ends with a step 240 of the preparation of an execution report specifying for example whether said execution was carried out with or without error.

[0045] A method 100 according to the invention now includes a step of reading 140 the value of each output data OD1, ODj of the software application A1 into the output directory DOD1, DODj of the file system 42 as defined by contract C1 or by platform 4.

[0046] Following the implementation of the integration and execution process of software application A1, the medical imaging platform 4 can trigger the implementation of a subsequent process aimed at exploiting the result produced by said application A1. Such a subsequent process can consist of a new occurrence of said process 100 to cause the execution of a second software application A2, An.

[0047] Advantageously, the invention provides that a software application A1, A2, An can handle input or output data that is optional. To this end, the optional nature can be specified in the contract C1, C2, Cn associated with said application A1, A2, An. According to a preferred embodiment, in connection with application A1 illustrated by the figure 3 The field or element of said contract C1, which determines the virtual directory VDED1, VDEDi intended to contain an input data ED1, EDi, can be associated with an attribute specifying whether said input data ED1, EDi is optional or mandatory. According to this embodiment, a method 100 according to the invention is adapted so that, when such an attribute indicates that an input data ED1, EDi is optional, the step 120 of writing the value of the latter is only implemented if such input data ED1, EDi is available for the medical imaging platform 4. Launching the execution of the software application A1 will not cause an error in the absence of an argument dedicated to such optional data in the command 130. Such an attribute can thus consist of a Boolean value to characterize such an optional or mandatory nature of an input data.Alternatively, the absence of such an attribute may mean that the said input data is mandatory.

[0048] The same applies to an output data OD1, ODj which may be optional depending on the result produced by a software application such as application A1 according to the figure 3 According to this embodiment, the field or element of said contract C1, which determines the virtual directory VDOD1, VDODj intended to contain an output data OD1, ODi, can be associated with an attribute specifying whether said output data OD1, ODj is optional or mandatory. When such an attribute indicates that said output data OD1, ODj is optional, it can include a predetermined value specifying a value of no interest. In this way, the processing unit 41 knows that it should not take such output data into account if said data describes a value equal to said predetermined value.

[0049] Furthermore, the invention provides for adding one or more pieces of metadata, such as a label or tag, or more generally a typing attribute, to qualify input data ED1, EDi and / or output data OD1, ODj of a software application such as application A1 according to the figure 3 When such output data OD1, ODj can be enriched or qualified by the presence of a label, the contract C1 associated with said software application A1 can be arranged so that the virtual output directory VDOD1, VDODj intended to contain the value of the output data can be associated with such a type attribute of said output data OD1, ODj. In this case, the read step 140 (of process 100 according to the figure 4 Enhancing the value of the relevant output data OD1, ODj can involve associating the value of the typing attribute with the value of said output data. When the software application A1 does not provide such typing, the contract C1 associated with it does not associate such a typing attribute. However, the imaging platform 4 can update said contract C1 to add said typing attribute to the virtual output directory of the relevant output data. Such enrichment of output data produced by a software application can thus be used by the medical imaging platform 4 to select input data ED1, EDi from the software application A1 to be written to the input directory DED1, DEDi of the file system 42, or to select input data from any other application.

[0050] The invention further provides an advantageous embodiment in which a contract C1, C2, Cn associated with a software application A1, A2, An can be securely updated or initialized. In this respect, such a contract can be encrypted after any modification and decrypted during step 110 of a method 100 according to the invention and as illustrated by the figure 4The AID of software application A1 may also include a redundancy code (for example, a hash of the associated software application) so that step 130 of the application execution launch includes a process to verify this redundancy code before the actual execution of the software application is triggered. If the calculated redundancy code matches the value specified in the contract, the software application execution is confirmed and initiated. Otherwise, the execution is aborted. In this way, the medical imaging platform 4 can ensure that the contract is indeed associated with the correct version of the software application.

Claims

1. Method (100) for integrating and executing a software application (A1, A2, An), said method being implemented by a processing unit (41) of a medical imaging platform (4) operating a file system (42), said method (100) comprising: - a step of loading a software application (A1, A2, An) in a memory (45) of the medical imaging platform (4); - a step (120) of writing the value of the item of input data (ED1, EDi) of the software application (A1, A2, An) to an input directory (DED1, DEDi) of the file system (42); - a step (130) of initializing the execution of the software application (A1, A2, An); - a step (140) of reading the value of the item of output data (OD1, ODj) of the software application (A1, A2, An) from an output directory (DOD1, DODj) of the file system (42); said method being characterized in that: - said method further comprises: a. a step of loading a contract (C1, C2, Cn) dedicated to said software application (A1, A2, An) in said memory (45) of the medical imaging platform (4), said contract (C1, C2, Cn) consisting of digital content not modified or configured by said medical imaging platform (4), which includes information usable by the medical imaging platform (4) and imposed by the software application (A1, A2, An), said information describing: i. a unique identifier (AID) denoting said software application (A1, A2, A3) which is thus associated with the contract (C1, C2, Cn) which is dedicated to said application, ii. an input virtual directory (VDED1, VDEDi) intended to contain a value of an item of input data (ED1, EDi) required to execute the software application (A1, A2, An); iii. an output virtual directory (VDOD1, VDODj) intended to contain the value of the item of output data (OD1, ODj) produced by said application, said step of loading said contract (C1, C2, Cn) being carried out together with the loading of the software application (A1, A2, An) which is associated therewith in the memory (45) of the medical imaging platform (4); b. a step (110) of reading the contract (C1, C2, Cn) dedicated to the software application (A1, A2, An) which is associated therewith by the presence of the unique identifier (AID) of the software application written in said contract (C1, C2, Cn), in order to know the requirements of said software application (A1, A2, An) to be executed, said step (110) of reading the contract (C1, C2, Cn) preceding the step (130) of initializing the execution of said software application (A1, A2, An); - the software application (A1, A2, An) is an executable code designed and produced independently of the implementation of the present integration and execution method (100) or of any other method implemented by the processing unit (41) of said medical imaging platform (4); - the step (130) of initializing the execution of the software application (A1, A2, An) denoted by said unique identifier (AID) taken from the contract (C1, C2, Cn) previously read (110), comprises transmitting arguments for executing the software application (A1, A2, An) consisting of 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 said file system (42), said access paths (DPED1, DPEDi, DPOD1, DPODj) are thus associated with the input virtual directory (VDED1, VDEDi) and output virtual directory (VDOD1, VDODj), respectively, of the software application (A1, A2, An) by virtue of said execution arguments transmitted to the software application (A1, A2, An) in the step (130) of initializing the execution of the software application (A1, A2, An) in accordance with the content of the contract (C1, C2, Cn) previously read in the step of reading (110) said contract (C1, C2, Cn) dedicated to said software application (A1, A2, An).

2. Method (100) according to the preceding claim, wherein the contract (C1, C2, Cn) comprises a value (EV1, EVk) of an operating parameter (E1, Ek) of the software application (A1, A2, An) associated therewith and wherein the step (130) of initializing the execution of said software application (A1, A2, An) is suitable for including transmission of the value of said operating parameter as an argument for executing the software application (A1, A2, An) in accordance with the content of the contract (C1, C2, Cn) read prior to the step (110) of reading said contract (C1, C2, Cn) dedicated to the software application (A1, A2, An).

3. Method according to any one of the preceding claims, wherein the software application (A1, A2, An) is in the form of a computer container, the unique identifier (AID) denoting said software application (A1, A2, An) included in said contract (C1, C2, Cn) which is associated therewith, expressing the image of said computer container.

4. Method (100) according to any one of the preceding claims, wherein: - the input virtual directory (VDED1, VDEDi) which is intended to contain the item of input data (ED1, EDi) of the software application (A1, A2, An) is associated with an attribute specifying the optional or mandatory nature of said item of input data (ED1, EDi) in the contract (C1, C2, Cn) which is dedicated to said software application (A1, A2, An), and - the writing step (120) of the software application is implemented only if such an item of input data (ED1, EDi) is available for the medical imaging platform (4) when such an attribute attests to an optional nature of said item of input data (ED1, EDi).

5. Method (100) according to any one of the preceding claims, wherein: - the output virtual directory (DOD1, DODj) intended to contain the value of the item of output data (OD1, ODj) of the software application (A1, A2, An) is associated with a typing attribute of said output (OD1, ODj) in the contract (C1, C2, Cn) which is dedicated to said software application (A1, A2, An), and - the step (140) of reading the value of the item of output data (OD1, ODj) of the software application (A1, A2, An) consists in associating said value of said typing attribute with the value of said item of output data (OD1, ODj).

6. Method (100) according to any one of the preceding claims, wherein: - the contract (C1, C2, Cn) which is dedicated to a software application (A1, A2, An) is encoded prior to integrating the software application in the memory (45) of the medical imaging platform (4) and wherein the step (110) of reading such a contract (C1, C2, Cn) comprises a prior sub-step of decoding said contract (C1, C2, Cn).

7. Computer program product comprising one or more program instructions which can be executed by the processing unit (41) of a computer, said program instructions being loadable into a non-volatile memory (45) of said computer and the execution of said instructions by said processing unit (41) causes the implementation of a method (100) according to any one of the preceding claims.

8. Computer-readable storage medium comprising the instructions of a computer program product according to the preceding claim.

9. Medical imaging platform (4) comprising a processing unit (41), a memory (45) operated by a file system (42), said memory (45) comprising the program instructions of a computer program product according to claim 7.