Usability Engineering, Data Infrastructure, and Information System Design & Development


c1A major component within the Cardioproof project is the analysis of clinical requirements including data, content of use, clinical workflow, and data requirements gathered by other work packages. This data is then used with the goal of analysing and solving usability and workflow-related problems,which prevent the application of modelling and simulation methods in clinical practice. Dedicated contextual research was required to create workflows, interpret clinical routines, understand individual responsibilities of stakeholders, and understand stakeholder interactions with others, medical devices, and software programs. Utilizing user centred research and evaluative techniques aid in understanding the users needs and requirements on a much deeper level, allowing for thoughtful, effective, and highly useful solutions.

Contextual Research: Analysing Processes in the Field

cc1Contextual research is a type of research that involves the researcher going into the users’ environment in order to observe first hand how the workflow is influenced by various users and products. This immersive technique also allows for observations of users behaviours in a specific context to evaluate needs and determine users roles in the system. Within CARDIOPROOF, the hospitals of the clinical project partners in London, Rome, and Berlin were visited to conduct contextual research and understand clinical requirements.

Stakeholders – Who is Involved?

Stakeholders are described as the key players affecting and who are affected by the workflow. As three separate medical institutes are collaborating for CARDIOPROOF, the stakeholders from each needed to be studied with respect to protocols, workflows, and experiences. Since each location is a different size and has slightly different protocols, each procedure and who conducts what was noted. An example of this task difference is in London, where clinical fellows have traineeships of two years and often write clinical reports. In the other two locations, fellows are either not present or are not present long enough to gain the experience necessary to write clinical reports. This means that the senior level cardiologists in London can fill their time by seeing additional patients or other tasks instead of report writing (although they do review the fellow’s work before submission). This easily could impact the cardiologist’s workflow and number of patients he or she sees on a given day.

Workflows – Where to Integrate New Tools?

The workflow analysis is a step-by-step description of the tests and treatments patients go through when being treated for aortic coarctation and aortic valve disease in the CARDIOPROOF project. This means that surgeries, interventions, MRI’s, Echo’s, and segmentation procedures along with other events were observed, noting the timing and individuals taking part in each.

Workflows were then illustrated for each of the three locations. Variations in workflow were then noted as well as consistencies. This resulted in a fourth workflow, which displays the general process and highlights areas where differences in workflows occur. This iteration also helped to identify opportunities where new software tools could be integrated into the workflow. A section of this fourth workflow can be seen in the image below (Fig 3). This section of the workflow shows the end of the treatment process, explaining the events that occur once it’s decided that a surgery or intervention will take place. It also shows the individuals involved in this part of the process (hospital cardiologist, interventional cardiologist, cardiac surgeon, nurse(s), radiographer, and an anaesthesiologist). The red arrows identify where additional software features developed by the CardioProof project could be used.


To determine specifics on usage (ie. who will do the analysis, who would do the virtual stenting, and who reviews the results to make final conclusions about stenting strategy) additional research and discussions with stakeholders must be conducted. It is likely based on current workflows that different stakeholders may complete the same tasks in the different locations. This could potentially impact the user interface of the virtual tool based on preferences and needs of the various users. These potential tool users are seen in Figure 2.

Identifying Web Tool Needs

Following the development of the workflow, conversations regarding the current and future software tools took place. These discussions included analysing existing software solutions with experts and led to identifying where improvements and new solutions could take place and key information required for new web tool development. Following this task, a wireframe of the new web tool was developed (Fig 4) and can be considered in the development prototypes, as shown in Figure 5 below.


Author: Ashley Waring