Designing the application architecture

In the target situation, the application components of the CDSS will not interact with the environment outside of the CDSS as their sole purpose is to create evidence and insights, create a form of delivery for them, develop new models and manage, govern and monitor this process. The delivery of the analysis is performed in the technology layer (via the transactions) and therefore this section will solely focus on the specification of the internal software components of the CDSS. In this layer, two classes of algorithms can be distinguished: live algorithms that are deployed and validated (SYR1a) and algorithms in development that are used to create new deployed models (SYR1b). The application layer therefore clearly distinguishes between the live environment and the development environment.

The main decision that must be made in this layer is whether the CDSS is implemented internally (inside the environment of the hospital) or externally (inside the environment of the external supplier). The biggest advantage of the former is that data exchange between the environment and the CDSS would be easier and richer. This is because data that leaves the logical or physical walls of the hospital must be deidentified to comply to law. For the live algorithm, the data must be identifiable as otherwise the results cannot be shown in the correct place. Placing the CDSS inside these walls will eliminate this need for deidentification. Also, the government and monitoring effort belongs mostly to the hospital. Despite this extra activity for the hospital, it is vital that they can exert control over this system and process as the algorithms will touch patient care. Finally, the CDSS is free to participate in the current transactions and orchestrations of the hospital without dealing with firewalls and other security mechanisms, making integration easier. The latter option provides possibly quicker iterations for algorithm development and can provide outcomes as a service without the need for governance from the hospital. However, since the benefits of internal deployment outweigh the benefits of external deployment, the live and development environment are deployed internally.

To identify the components in the live environment that can create a pipeline for the creation of intelligence, inspiration is drawn from the CRISP-DM model [58] of section 3.2. Many of the activities described in the CRISP-DM process model must be automated in the live environment. The following components can be derived from this that must be present in the live environment:

- Data acquisition (handled in the technology layer)

- Data processing where data is processed so that it is ready for the deployed model to analyze. This step can also already create evidence that can be presented to the outside environment.

- Model execution where the algorithm is applied to the data in order to create evidence (in the form of new images) or reports (which contain new insights based on the data). Together with the data processing component, this is modelled under the evidence and insights creator.

- Data delivery which is responsible for the delivery of the results of the system to the end user. This is done for performance monitoring (by creating dashboards) as well as delivery in the primary care process (by presenting it to the outside environment). Data delivery can be performed by a standalone application as long as it has access to the data of the CDSS. This also provides space for elaborate explanations of the performed analytics.

This complete workflow of data acquisition, data processing, model execution and data delivery must be governed and monitored in five ways: managing models to ensure that the models work as they should (in terms of for instance compliance), workflow management in order to monitor the entire pipeline and generate process performance and metadata, access management to log activity and restrict access to certain users, worklist management in order to track status and execution of orders, and output management to generate outcome performance data. These functionalities are presented under the model manager component.

The live environment of the CDSS is depicted in Figure 42. It depicts five services that are delivered by the application:

- Application management: the ability to exert control over the pipeline, the application and all its components. Also, this provides the ability to track orders (mimicking the current practices in the hospital) (SYR3, SYR6, SYR9, SYR11).

- Performance insights availability: the ability to assess performance data, metadata and logs in raw form (from the model management software) or in process form (from reporting) (SYR8).

- Monitoring and governance capabilities: the ability to monitor and govern the process, models and outcomes and generate performance and metadata (SYR7).

- Evidence and insights creation: the actual outcome of the analysis performed by the CDSS (SYR1).

- Reporting software: the ability to generate data presentations tailored to the users need (SYR2, SYR3, SYR4, SYR8, SYR13).

The development environment, since it is used to freely explore new possibility, does not require the same level of governance as the live environment (Figure 43). Also, the outcomes do not have to be placed in a report. The development environment should simply allow for free exploration and development. There is however one new component that should be added. When a model is deemed valuable and reliable, a validation study will be initiated. Whatever

the study may entail, initiation and monitoring of this process can be done in the development environment.

Figure 42: The application layer of the live CDSS

Figure 43: The application layer of the development environment of the CDSS