Computer-implemented runtime system, healthcare network, method and computer program

Abstract

The present disclosure relates to a computer-implemented runtime system, a healthcare network, a method, and a computer program. The runtime system is operable to provide a continuous product execution runtime environment for at least one application via a healthcare network, the healthcare network comprising a plurality of production devices configured to process medical information of the runtime environment, and the runtime system further comprising a focusing machine and an action plan repository configured to provide an autonomous runtime environment by: monitoring the running use case of the application on at least one device by the focusing machine; taking over the responsibility of the running use case of the application by the focusing machine in the case where an error state is detected for the monitored running use case; analyzing the detected error state of the running use case by the focusing machine; obtaining at least one suitable replacement action from a plurality of actions stored in the action plan repository based on the analyzed error state of the running use case; terminating and preferably completing the running use case or part thereof by the focusing machine by adopting the obtained replacement action on the application.

Description

Technical Field

[0001] The invention relates to a computer-implemented runtime system. The invention also relates to a healthcare network, a method and a computer program. Background Art

[0002] The invention belongs to the field of healthcare networks, such as are described in EP 3 457 408 A1 and EP 3 567 600 A1.

[0003] The healthcare network includes multiple systems - including devices, products, platforms, and applications (also referred to as software, programs or computer programs). Devices can include medical devices (e.g., picture archiving and communication systems (PACS), ultrasound systems, etc.), user terminals for use by medical professionals and patients, expert user terminals (e.g., nurse call systems), servers, and medical data storage devices. The platform facilitates devices and applications to access services and repositories inside or outside the healthcare network. Applications operate on or in conjunction with devices or are accessible via devices, and can include communication applications that facilitate communication between devices on the healthcare network, medical applications configured to process medical information, applications configured to manage proprietary information, applications for managing knowledge in a healthcare environment, and applications configured to manage medical records.

[0004] Such modern medical application environments are complex and use a variety of different devices and products from different manufacturers in a heterogeneous landscape and infrastructure with heterogeneous functions and applications and often in a non-standardized manner. In particular, the trend in the architecture of modern medical devices and products is towards an increasing number of relatively small systems, applications and services that interconnect and interact with each other, rather than using only a few relatively complex systems or isolated products.

[0005] In this heterogeneous landscape architecture with an increasing number of relatively independently operating systems, applications and services, the probability of undesirable situations and system errors increases for different products and devices and the interactions between them. For example, if the situation during operation exceeds the so-called happy path, the application can no longer handle the corresponding use case. Therefore, the application gets stuck.

[0006] According to the typical approach, the user seeking to get out of the situation quickly is often faced with an error dialog box, or even worse, with an exception dialog box, and the telephone number of the service help desk is left to him. Besides the fact that these remote service help desks are usually not available in case they are needed, they are usually not productive, so that the user usually cannot get around the error situation. This mainly leads to the need to restart the ongoing use case, without guaranteeing that the same error situation will happen again. Usually, the work and data of the interrupted use case are no longer recoverable.

[0007] For background activities, known watchdog mechanisms provide low-level actions such as start, resume or restart, but they neither handle error prevention or correction nor proper use case continuation.

[0008] In this context, the problem addressed by the present invention is to improve the handling of ongoing use cases of stuck applications. Summary of the invention

[0009] According to the invention, this problem is solved by a computer-implemented runtime system and / or a healthcare network and / or a method and / or a computer program.

[0010] Accordingly, the following is provided:

[0011] -A computer-implemented runtime system operable to provide a continuous production execution runtime environment for at least one application via a healthcare network, the healthcare network comprising a plurality of production devices configured to process medical information of the runtime environment, wherein the runtime system further comprises a focusing machine and an action plan repository configured to provide an autonomous runtime environment by: monitoring, by the focusing machine, a running use case of an application on at least one device; taking over, by the focusing machine, responsibility for the running use case of the application in the event that an error state is detected for the monitored running use case; analyzing, by the focusing machine, the detected error state of the running use case; obtaining, by the focusing machine, at least one suitable replacement action from a plurality of actions stored in the action plan repository based on the analyzed error state of the running use case; and terminating, by the focusing machine, and preferably completing, the running use case or a portion of the running use case by adopting the obtained replacement action on the application.

[0012] - A healthcare network comprising: a plurality of production devices which can be operated by a plurality of users and are configured to process medical information; and at least one runtime system according to the present invention, the runtime system having at least one interface for coupling to the plurality of production devices and configured to provide an autonomous runtime environment for the plurality of production devices.

[0013] -A computer-implemented runtime method for providing a continuous and autonomous product execution runtime environment for at least one application, the computer-implemented runtime method comprising the following steps: providing a healthcare network, the healthcare network comprising a plurality of production devices configured to process medical information of the runtime environment; monitoring the running use cases of the application on at least one device via an interface of the healthcare network; in the event that an error state is detected for the monitored running use cases, taking over the responsibility of the running use cases of the application by an externally provided focusing machine; analyzing the detected error state of the running use cases by the focusing machine; obtaining at least one suitable action from a plurality of actions based on the analyzed error state of the running use cases; and terminating and preferably completing the running use case or part of the running use case by the focusing machine by adopting the obtained action on the application.

[0014] - A computer program comprising a set of instructions which, when executed by a computerized electronic device, causes the computerized electronic device to carry out the method according to the invention.

[0015] The method according to the present invention focuses on providing an autonomous product execution environment that handles use cases, situations, events, etc. in an automatic and / or autonomous manner. In particular, use cases are handled with a dedicated selection of applicable actions and decision autonomy by saving operational data and use case context.

[0016] The proposed solution according to the present invention provides an autonomous, preferably cloud-based runtime environment that is configured to make appropriate autonomous decisions on when, whether, and how to proceed with an ongoing use case or situation at runtime. Thus, the autonomous runtime environment can become active already in situations that are unknown to the running or installed systems, applications and / or services.

[0017] The new autonomous runtime environment means that the responsibility of the ongoing defective use case is transferred and handed over to an externally arranged focusing machine. For the next step of this ongoing defective use case, the focusing machine of the runtime system continues the ongoing use case based on a number of configurable actions. At most, the focusing machine is completing the defective use case instead of the original use case owner (e.g., the production equipment). This use case format executed externally allows for safe handling of non-productive dead-end situations.

[0018] The application behavior appears to automatically and autonomously continue the interrupted use case without further user interaction or additional information. To this end, the application notification needs to replace the current execution path of the defective use case with an alternative execution path of the current defective use case. In this way, the faulty (or at least atypical) behavior of the application, software or program is masked by adopting appropriate use case compatible functional replacement.

[0019] As described in the introduction, known solutions neither structure nor distribute the functionality in the novel approach. In known solutions, use case execution is considered as an exclusive internal responsibility of the corresponding application or service. In contrast, the novel approach according to the present invention provides a technical focusing machine to conditionally transfer this responsibility for a failed or defective use case (or use case step) to a different program outside the set of available programs. Neither the initial application or service nor the focusing machine can know a priori what the next program is due, which of the next programs successfully solves the required next steps in the use case, which in turn completes the use case with or even without the initial application or service. Therefore, a core aspect of the present invention is that the focusing machine does not define, redefine or modify existing use cases, even if they produce error states.

[0020] This autonomous runtime environment provides the most flexible alignment with running use cases by employing replacement functions. In particular, the autonomous runtime system attempts to complete known or unknown running use cases, for example, if that particular use case is stuck or if the user of the application receives an exception that neither the user nor the application itself can handle. The autonomous runtime system then helps to release the application from the exception, continue the application and / or successfully complete the use case. Thus, time-consuming interruptions are avoided as much as possible. In addition, the user's previous work is saved and therefore not lost.

[0021] The infrastructure of the autonomous runtime system includes a set of suitable interfaces and components that are configured to execute working models, storyboards and / or action plans. According to the present invention, at least one application or service runs on a production device. The autonomous runtime environment includes a so-called focusing machine that is configured to execute so-called action plans. These action plans contain conditions, action lists, etc. that are necessary for continuing to run use cases. The autonomous runtime environment can also include auxiliary repositories such as plan repositories (which include downloadable action plans) and behavior repositories (which have configured and updated metrics from use case behavior aspects). In addition, the action plan generator collects available action plans during software development, already in development or in later processing. Then, during product shipment to cloud production and as a runtime add-on at any time, these action plans are transmitted and deployed to a cloud-based production environment together with the software.

[0022] A major advantage of the present invention is that the replacement action replacing a failed or stuck use case or use case step is not part of the corresponding application or service. This ensures that the replacement action is technically executable whenever it is triggered, even if the corresponding application or service, respectively, is not able to execute it, for example, because no internal control flow is prepared for this situation.

[0023] Advantageous configurations and developments emerge from the further dependent claims and from the description with reference to the figures.

[0024] According to a preferred embodiment, the focusing machine is further configured to provide data of the completed use case or part of the completed use case to the production device and / or the runtime environment. Preferably, the function of providing data of the completed use case or part of the completed use case comprises: storing the data of the completed use case or part of the completed use case in the action plan repository by the focusing machine.

[0025] According to an embodiment, the function of taking over the responsibility includes: detecting, by the focusing engine, an error state of the monitored use case if the detected state of the running use case satisfies at least one predefined condition. Here, the predefined condition of the running use case may be a dead-end situation of the use case where the execution of the corresponding application is stopped. Additionally or alternatively, the predefined condition of the running use case may also be a predefined deviation of the executed application from the happy path of the use case.

[0026] According to another embodiment, the function of taking over responsibility and analyzing the detected error state includes: generating, by the focusing engine, a priority of conditions based on a list of available conditions; and reading, by the focusing engine, appropriate behavior metrics corresponding to the generated priority from an action plan repository.

[0027] In a preferred configuration, the function of obtaining at least one suitable replacement action includes: determining, by the focusing engine, which condition is to be applied in the current phase of the use case; and determining, by the focusing engine, actions and the order in which these actions are to be performed in the current phase of the use case.

[0028] According to further embodiments, the functionality of terminating the running use case or a part thereof comprises autonomous success control monitoring by the focusing engine by monitoring the success of the executed actions and by storing the success information in the action plan repository.

[0029] According to a particularly preferred embodiment, the healthcare network is operable to provide a cloud-based runtime environment. In particular, the autonomous runtime environment is pluggable into production in the cloud.

[0030] Where appropriate, the above-mentioned configurations and developments may be combined in any manner. Other possible configurations, developments and implementations of the present invention also include combinations not explicitly mentioned of features of the present invention that have been previously described or described below with reference to the embodiments. In particular, in this case, those skilled in the art will also add various aspects as improvements or supplements to the basic form of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] The invention is described in more detail below based on an embodiment shown in the schematic diagram of the accompanying drawings, in which:

[0032] Figure 1 shows a block diagram illustrating a computer-implemented runtime system within a healthcare network operable in accordance with the present invention;

[0033] Figure 2 A flow chart illustrating the functionality of the runtime system is shown;

[0034] Figure 3A and Figure 3B A sequence diagram illustrating another embodiment of the present invention is shown. DETAILED DESCRIPTION

[0035] The accompanying drawings are intended to provide a further understanding of embodiments of the present invention. They illustrate embodiments and, combined with the description, help explain the principles and concepts of the present invention. Other embodiments and many of the advantages mentioned will become apparent in light of the accompanying drawings. The elements in the drawings are not necessarily shown to scale.

[0036] In the drawings, similar, functionally equivalent and identical operating elements, features and components are provided with similar reference numerals in each case, unless stated otherwise.

[0037] Figure 1 A block diagram illustrating a computer-implemented runtime system within a healthcare network operable in accordance with the present invention is shown.

[0038] The runtime system is configured to provide a continuous product execution runtime environment for at least one application via a healthcare network. The healthcare network (which may be a cloud-based online network such as "Teamplay" of Siemens Healthineers) is configured to connect a plurality of production devices. The devices are configured to process medical information of the runtime environment, for example, by executing software applications, services, and / or other types of software products.

[0039] exist Figure 1 In the embodiment of the present invention, the runtime system is indicated by reference numeral 10. The runtime system 10 is part of a healthcare network 15.

[0040] The runtime system 10 includes a focusing machine 11, an action plan repository 12, and an optional action plan generator 13. The focusing machine 11 includes a first interface 14 for coupling the runtime system 10 to one or more production devices 16 via an interface 18 of a healthcare network 15. The focusing machine 11 also includes a second interface 17 for coupling to the action plan repository 12. Figure 1 In the illustrated embodiment, the action plan generator 13 is part of the action plan repository 12. Additionally or alternatively, the action plan generator 13 may also be part of the focusing machine 11, or coupled to the focusing machine 11 or the action plan generator 13 via the healthcare network 15 (not shown). Figure 1 ).

[0041] The production equipment 16 is used to execute a specific application, service or system. In the context of the present invention, an application, service or system, hereinafter referred to as an application (app), represents a type of software program that intends to implement and provide the execution of a use case, create internal conditions and external conditions. These applications are simultaneously exposed to conditions in the runtime context. Such use cases process dedicated data and are expected to produce dedicated and predefined results after a set of use case steps and after some processing time. For example, this gives a plurality of such programs measurable behaviors in space and time, which in turn can be tracked and matched with conditions in the action plan, and this also gives additional actions that cannot be part of a single use case.

[0042] Action plan repository 12 comprises a plurality of suitable action plans. In particular, action plan repository 12 comprises auxiliary repository such as downloadable action plan 12a and behavior repository 12b, which has configured and updated metrics from use case behavior aspect. In the context of the present invention, action plan is composed of a list of conditions and suitable actions. Specifically, action plan repository 12 combines a set of predefined conditions that can be automatically monitored, measured and detected in the mix of application, service or system with a list of corresponding suitable actions, and if the predefined conditions are met, the corresponding suitable actions can be performed. The purpose of providing action plan is to complete the ongoing use case that is stuck, causes errors, deviates from the happy path, etc. Alternatively, because the condition shows that the original ongoing use case may not meet the subsequent conditions, or even be stuck, an action plan may also be needed to meet the situation with suitable actions. The suitable action in the action list is a functional replacement of the original control flow (or happy path), which is defined to be used in the best example scenario during development. Preferably, because it is a priori unknown what action can present the successful result required for the use case or given situation, multiple actions different from each other are provided. Appropriate action plans can be created for scopes of all types and sizes (i.e., all systems / products, a subset of systems / products, or just one or a few applications / services). Appropriate action plans can also be created for all conditions that can be detected in an automatic and / or autonomous manner. Thus, actions can have characteristics of assisting, correcting, optimizing, etc.

[0043] The action plan generator 13 preferably, but not compulsorily, provides an action plan during development. For example, during development, the action plan generator 13 is used to compile an action plan that needs to be combined with the software and will be deployed in a cloud-based production environment. The set of action plans can depend on, for example, the parts of the entire software product, the versions of applications and services, the types and quantities of collaborative systems, and the details of the target deployment, such as the expected and faulty runtime behaviors and related conditions and actions in the action plan. The action plan generator 13 can take these features into account.

[0044] The focusing machine 11, which is a core component of the runtime system 10, represents a control device that serves as a monitoring and control instance to ensure that the ongoing use case is properly completed. The focusing machine 11 can be a programmable control device, such as a computer, a microprocessor, a controller, etc. The focusing machine 11 mainly executes the action plan provided by the action plan repository 12. To this end, the focusing machine 11 monitors the ongoing use case of the application as input data and measures whether the predefined error condition is met. If the predefined error condition is met, the focusing machine 11 automatically and preferably also autonomously takes over the responsibility of the ongoing use case. In particular, the focusing machine 11 obtains one or more replacement action plans provided by the action plan repository 12 as input data in order to execute the action list of the replacement action plan and provide replacement results for the ongoing use case. In this context, it is particularly important that the replacement action used by the focusing machine 11 to replace the function of the ongoing use case or part thereof is not part of the faulty application. This is particularly intelligent because it ensures that the replacement action is technically executable at any time when it is triggered, even if the application can no longer be executed, for example, because the internal control flow is not prepared for this specific error situation.

[0045] In summary, the focusing machine 11 includes, among other things, the following monitoring and control mechanisms for the ongoing use case:

[0046] -Execution technology impact;

[0047] -Monitoring alarm information;

[0048] - Analyze log data;

[0049] - Analyze metric data;

[0050] -Detect anomalies in data generated by applications;

[0051] - distributing the feedback information to the production equipment via the first interface;

[0052] - Pre / post deployment analysis (including field testing with domain models).

[0053] The focusing machine 11 may also include an action plan repository 12 ( Figure 1 not shown).

[0054] In the following, use Figure 2 The flowchart briefly explains the functions of the runtime system 10:

[0055] One or more production devices 16 of the healthcare network 15 are executing one or more applications (step S0). In normal operation mode, these applications are correctly executed and completed by the production devices 16, ie the ongoing use case of the application follows the so-called happy path.

[0056] In parallel with the execution of the application, the focusing machine 11 monitors the running use cases of the application on at least one production device 16 via the first interface 14 (step S1 ).

[0057] If an error state of the monitored running use case is detected by the focusing engine 11, it takes over the responsibility of the running use case (step S2). For example, the error state represents a situation where the detected state of the running use case meets at least one predefined condition (e.g., a dead end situation where the application is stopped).

[0058] Then, the focusing machine 11 analyzes the detected error status of the running case in step S3. To this end, the focusing machine 11 compares the status of the running case and the corresponding error status with the data obtained from the action plan repository 12 via the second interface.

[0059] Based on the analyzed error status of the running use case, the focusing engine 11 extracts at least one suitable action from a plurality of actions stored in the action plan repository 12 (step S4).

[0060] The running use case or part thereof is then completed or at least terminated by the focusing engine 11 (step S5). This is done by applying the obtained action on the application.

[0061] Finally, the data of the completed use case or part thereof is provided to the production device 16 and / or the runtime environment (step S6).

[0062] Figure 3A and Figure 3B Sequence diagrams illustrating further embodiments of the present invention are shown in order to illustrate the scope of possible functionality of the present invention.

[0063] exist Figure 3A , components of a production device 16 are shown. These include at least one device 20 configured to execute one or more applications and a corresponding log repository 21.

[0064] The components on the right include components of the runtime system 10, in particular the focusing engine 11, the plan repository 12, the behavior repository 23 and at least one action unit 24. The plan repository 22, the behavior repository 23 and the action unit 24 are usually part of the action plan repository 12.

[0065] When a device 20 of the healthcare runtime environment is executing an application (particularly an application with medical content) or is located in a medical environment, corresponding log data is provided to a log repository 21 (step 1.1).

[0066] The corresponding status of the running use case is transmitted to the focusing machine 11 (step 1.2). Alternatively, the status of the running use case can also be collected by the focusing machine 11 directly from the log repository 21. This allows the focusing machine 11 to detect the running use case.

[0067] If the predetermined condition is met, such as an error state, the focusing machine 11 takes over the responsibility of running the use case (step 1.4). The focusing machine stores the corresponding log data in the log repository 21 (step 1.3).

[0068] Then, in Figure 3B In the process, the focusing engine 11 generates a priority of the conditions based on the list of available conditions (step 1.7). The focusing engine 11 has already collected this list of available conditions (step 1.0) at an earlier stage (e.g. initially when the focusing engine 11 has read the content of the action plan repository 22). In particular, the focusing engine 11 assesses which conditions are mainly available and what are typical or standard reactions at the current stage and for a given scenario.

[0069] After the priority of the conditions has been generated, the focusing engine 11 reads the appropriate behavior metrics corresponding to the generated conditions from the behavior repository 23 (step 1.8). With this information, the focusing engine 11 is able to decide which condition to apply at the current stage of the use case and for a given scenario (step 1.9). Based on this information, the actions are determined and the order in which the actions are to be performed at the current stage of the use case (step 1.10).

[0070] In addition, but not mandatory, the focusing engine 11 may also derive other context information, such as success metrics, from the behavior repository 23 (step 1.11).

[0071] In the following, the focusing machine 11 attempts to complete or at least terminate the operating case or use case phase by taking actions or action sequences derived from the action plan (step 1.12, step 1.13). To this end, the focusing machine 11 provides functions and data for the fault case affecting the protection device 16.

[0072] Optionally, but not mandatory, the focusing engine 11 then monitors and checks the conditions and success of the actions taken (step 1.14). The corresponding data is stored in the behavior repository 23 (step 1.16).

[0073] Finally, the focusing engine 11 provides the results of the fault use case completed or terminated in the above manner to the executable application of the device 20. This can be done by means of a push-process from the focusing engine 11 to the device 20 (step 1.17) or a pull-process from the device 20 to the focusing engine 11 (step 1.18).

[0074] Optionally, but not mandatory, the action plans used by the focusing engine 11 to complete or terminate the fault use case may be stored in the action plan repository 22. This enables the focusing engine 11 to download an updated list of available action plans for possible error states of the application for subsequent executions (step 1.0).

[0075] In the foregoing specification, the invention has been described with reference to specific examples of embodiments of the invention. It will, however, be evident that various modifications and changes may be made therein without departing from the broader spirit and scope of the invention as set forth in the appended claims.

[0076] Because the apparatus implementing the present invention is composed, for the most part, of electronic components known to those skilled in the art, in order to understand and appreciate the basic concepts of the present invention, and in order not to confuse or distract from the teachings of the present invention, the details of these components will not be explained to any greater extent than is deemed necessary as shown above.

[0077] In addition, the device may be physically distributed across multiple devices while operating functionally as a single device. Devices that functionally form separate devices may be integrated into a single physical device. Those skilled in the art will recognize that the boundaries between logic blocks and functional blocks are merely illustrative, and alternative implementations may merge logic blocks or functional blocks, or impose alternative decompositions of functionality on various logic blocks or functional blocks.

[0078] In the description, any reference numerals shall not be interpreted as limiting the claims. The word "comprising" does not exclude the existence of other elements or steps other than those listed in the claims. In addition, the term "a" or "an" as used herein is defined as one or more than one. Moreover, the use of introductory phrases such as "at least one" and "one or more" in the claims shall not be interpreted as implying that any particular claim containing such introduced claim elements is limited to an invention containing only one such element by introducing another claim element by the indefinite article "one" or "one", even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "one" or "one". The same applies to the use of definite articles. Unless otherwise specified, terms such as "first" and "second" are used to arbitrarily distinguish the elements described by such terms. Therefore, these terms are not necessarily intended to indicate the time or other priority of such elements. The fact that certain measures are cited in mutually different claims does not indicate that the combination of these measures cannot be used advantageously. Unless specifically indicated in the claims, the order of the steps proposed in the claims will not be detrimental to the order in which the steps can actually be performed.

[0079] The skilled person will appreciate that the illustration of the selected elements in the accompanying drawings is only used to help improve the understanding of the functions and arrangements of these elements in various embodiments of the present invention. Moreover, common and well-understood elements that are useful or necessary in commercially feasible embodiments are generally not depicted in the accompanying drawings to facilitate understanding of the technical concepts of these various embodiments of the present invention. It will also be appreciated that certain process stages in the described methods may be described or depicted in a specific order of occurrence, and those skilled in the art will appreciate that such specificity regarding sequence is not actually required.

[0080] In the context of software or information modeling, a happy path represents a default scenario characterized by the absence of unusual or error conditions, such as an optimal path.

[0081] In software engineering, a use case is a list of actions or event steps that typically defines the interactions between roles (called actors in UML) and the system to achieve a goal.

[0082] The action plan repository represents a suitable data or object storage device. The data storage device may be a computer memory device, such as a database, a register, a storage disk or drive, a DRAM, etc. An object storage device (also known as object-based storage) is a computer data storage architecture that manages data as objects, as opposed to other storage architectures such as file systems that manage data as a file hierarchy and block storage devices that manage data as blocks within sectors and tracks. Object storage devices are often used in cloud-based architectures.

[0083] The focusing machine is typically part of a program-controlled device such as a computer, microprocessor, microcomputer, DSP, CPU, or the like.

Claims

1. A computer-implemented runtime system operable to provide a continuous production execution runtime environment for at least one application via a healthcare network, the healthcare network comprising a plurality of production devices configured to process medical information of the runtime environment, wherein: The computer-implemented runtime system comprises: an action plan repository configured to store a plurality of actions; and A focusing machine including a microprocessor, the focusing machine being communicatively coupled to the action plan repository and the plurality of production devices, the focusing machine being configured to provide an autonomous runtime environment by at least: monitoring, via the focusing engine, running use cases of at least one application on at least one device; externally taking over the responsibility for the monitored operational use cases of the at least one application via the focusing engine in case an error state is detected for the monitored operational use cases; Analyzing the error status of the monitored running use case externally via the focusing machine; Based on the analyzed error status of the monitored running use case, obtaining at least one suitable replacement action from a plurality of actions stored in the action plan repository, wherein the at least one suitable replacement action is not part of the corresponding application; and At least a portion of the monitored running use case is terminated and successfully completed by employing the obtained at least one suitable replacement action on the at least one application via the focusing engine.

2. The computer-implemented runtime system of claim 1 , wherein: The focusing machine is further configured to provide data of at least a portion of the completed monitored operational use cases to at least one of the production equipment and the runtime environment.

3. The computer-implemented runtime system of claim 2, wherein: Providing data for at least a portion of a completed run use case includes: Data of at least a portion of the completed run use cases are stored in the action plan repository via the focus engine.

4. The computer-implemented runtime system of claim 1 , wherein: Takeover responsibilities include: In the case that the state of the monitored operating case satisfies at least one predefined condition, an error state of the monitored operating case is detected via the focusing engine.

5. The computer-implemented runtime system of claim 4, wherein: The at least one predefined condition comprises a dead end situation where execution of the corresponding application is stopped.

6. The computer-implemented runtime system of claim 4, wherein: The at least one predefined condition comprises a predefined deviation of the executed application from a happy path of the monitored running use case.

7. The computer-implemented runtime system of claim 1, wherein: Taking over responsibility and analyzing detected error conditions include: generating, via the focusing engine, a priority of conditions from a list of available conditions; and The appropriate behavior metric corresponding to the priority of the generated condition is read from the action plan repository via the focusing engine.

8. The computer-implemented runtime system of claim 7, wherein: Obtaining the at least one suitable replacement action comprises: determining, via the focus engine, which condition to apply at the current stage of the use case; and The actions are determined via the focus engine, as well as the order in which the actions are to be performed at the current stage of the use case.

9. The computer-implemented runtime system of claim 1, wherein: Terminating at least a portion of the monitored operational use cases includes autonomous success control monitoring by the focusing engine by monitoring success of at least one suitable alternative action taken and by storing success information in the action plan repository.

10. The computer-implemented runtime system of claim 1, wherein: The healthcare network includes the plurality of production devices operable by a plurality of users and configured to process the medical information; as well as The computer-implemented runtime system includes at least one interface for coupling to the plurality of production devices and configured to provide an autonomous runtime environment for the plurality of production devices.

11. The computer-implemented runtime system of claim 10, wherein: The healthcare network is configured to provide a cloud-based runtime environment.

12. The computer-implemented runtime system of claim 1, wherein: Providing data for at least a portion of a completed run use case includes: Data of at least a portion of the completed run use cases are stored in the action plan repository via the focus engine.

13. The computer-implemented runtime system of claim 2, wherein: Takeover responsibilities include: In the case that the state of the monitored operating case satisfies at least one predefined condition, an error state of the monitored operating case is detected via the focusing engine.

14. The computer-implemented runtime system of claim 13, wherein: The at least one predefined condition comprises a dead end situation where execution of the corresponding application is stopped.

15. The computer-implemented runtime system of claim 5, wherein: The at least one predefined condition comprises a predefined deviation of the executed application from a happy path of the monitored running use case.

16. The computer-implemented runtime system of claim 2, wherein: Taking over responsibility and analyzing detected error conditions include: generating, via the focusing engine, a priority of conditions from a list of available conditions; and The appropriate behavior metric corresponding to the priority of the generated condition is read from the action plan repository via the focusing engine.

17. The computer-implemented runtime system of claim 16, wherein: Obtaining the at least one suitable replacement action comprises: determining, via the focus engine, which condition to apply at the current stage of the use case; and The actions are determined via the focus engine, as well as the order in which the actions are to be performed at the current stage of the use case.

18. The computer-implemented runtime system of claim 1, further comprising: at least one first interface configured to communicatively couple the plurality of production devices to the focusing machine; as well as At least one second interface is configured to communicatively couple the focusing engine to the action plan repository.

19. A computer-implemented runtime method for providing a continuous and autonomous production execution runtime environment for at least one application, the computer-implemented runtime method comprising: providing a healthcare network comprising a plurality of production devices configured to process medical information of the runtime environment; monitoring, via an interface of the healthcare network, a running use case of an application on at least one production device of the plurality of production devices; In case an error state is detected for the monitored operational use case, taking over the responsibility for the operational use case of at least one of the applications via an externally provided focus engine; Analyzing the error status of the running use case detected by the focusing engine; Based on the analyzed error state of the running use case, obtaining at least one suitable replacement action from a plurality of actions, wherein the at least one suitable replacement action is not a part of the corresponding application; as well as At least a portion of the running use case is terminated and successfully completed via the focus engine by taking at least one obtained suitable replacement action on the at least one application.

20. A computer program product comprising a set of instructions which, when executed by a computerized device, cause the computerized device to perform the method according to claim 19.

21. A non-transitory computer readable medium storing a set of instructions that, when executed by a computerized device, cause the computerized device to perform the method of claim 19.

Images