Designing the process architecture

When the current business landscape was described in section 5.1, the systems involved with radiology and their transactions according to the IHE framework were described first. This is done here as well, but with the transaction model now presented in the technology layer (section 5.6). The overviews of Figure 9 and Figure 10 show these actors and transactions and they can now be changed to resemble the target situation. In terms of systems involved, two functions can be completed removed as they are substituted by the CDSS: the reporting and the evidence creation. The evidence and insights that these components normally generate are now substituted by the CDSS. (Remember, these components are not completely removed from the hospital, they are just not present in the workflow (and study) of the CDSS.) The post-processing manager, evidence creator, report manager and report creator can be removed and replaced by the CDSS in form of an evidence creator, reporting creator and a model manager (Figure 34). The workstation now solely provides capabilities to view evidence created by the CDSS. This prevents data contamination between human- and machine-made evidence.

To create full integration with the system, the current infrastructure should communicate with the CDSS in order to provide information on orders and images. The following changes should be made for each of the as-is process models.

Figure 34: Overview of all system components in the target situation

Ordering and scheduling an examination. The biggest challenge here is to initiate the workflow and create the two separate studies in the HIS without disrupting the normal workflow. The as-is workflow shows that an ordering clinician can order an examination according to a protocol which translates to a single ORM message that initiates the workflow. Luckily, orders can be divided into multiple ORM messages that each hold a unique Study Instance UID. This already occurs, for instance, when a biopsy is combined with a medical imaging examination, only one order is placed, but with some intelligence of the order filler and placer of the HIS/RIS, two studies are created (one for imaging, one for lab examinations). The HIS automatically provides a separate space for every unique study. Protocols can specify the way in which these orders are treated and thus, the hospital should add new protocols to the list that can initiate this workflow. In the eyes of the ordering clinician nothing changes as he only orders the examinations that he wants performed. Then, in the last phase of this subprocess, where all systems are notified about the order, the CDSS receives both the regular order as well as the CDSS order as this will solve a challenge in the next subprocess. Also, the CDSS will receive information about the creation and updates of patients so that it can store and maintain the created outcomes for that patient (necessary for historical analysis of all imaging of a patient).

Medical imaging acquisition. The creation of two separate studies and workflows creates another challenge. Both studies need the imaging that is acquired by the modality. However, this modality should only execute one order as otherwise the same procedure would run twice. To limit disruption, the regular order should contain the acquisition of the images. To ensure that the CDSS is aware of the acquisition of these images, the modality is set up (again using that same protocol) to send “modality completed” messages to the CDSS. Given that the CDSS is aware of the regular order and CDSS order, it can link this incoming message (carrying the regular order information) and link it to its own order. From then on, it can query the archive for the images of the regular order and use it for post-processing and reporting. Also, before the images are acquired, the CDSS is capable of prefetching historical data of the patient to perform a historical analysis (as no new images are needed).

Post-processing and reporting. These two subprocesses can be merged together as both of the activities are carried out within the CDSS. Since the internal creation of this evidence and reports is outside of the scope, it is treated as a black box. The workflow in general (worklist querying, item claiming, image querying, image storage, creation, item completion) will be the same as the current situation as this resembles the current practice in the hospital. The CDSS can then store and present the outcomes depending on their form in the enterprise report repository (automatically signed reports) or image archive (images) using the details of the study. This will normally be done in the CDSS study but can even occur for the radiologist’s study (if the outcomes were only useful in the workflow of the radiologist). In the sub-process of the presentation, assessment and discussion of a patient at an MDO, the only change is that the clinicians can now assess an additional study that is created by the CDSS. The general workflow of Figure 20 is now updated to resemble this new workflow Figure 35. The target BPMN models are shown in Figure 36-39 (the MDO is not shown since there are no relevant changes). These models were validated by a clinician, an IT coordinator and an independent integration specialist.

Figure 37: The process of regular and CDSS examination ordering and scheduling (target)

With this workflow, four protocols providing different functionalities can be implemented:

1. CT + CDSS: produce a regular CT-examination and in parallel, perform analysis on the acquired raw images by the CDSS and present these in a study.

2. CT CDSS: produce a CT-scan and only use the acquired images for the CDSS.

3. CDSS historic: produce an analysis on all historic data of a patient (could be part of a CT + CDSS or CT CDSS protocol).

4. CT + CDSS Radiology: produce an analysis on acquired images but present the results in the radiology study (only applies when the outcomes are only relevant and useful for the radiologist) In addition to the changes in the

current processes, three new process should be added. Requirements state that performance, impact and metadata tracking should be possible (SYR7 and SYR8). This is done to trace the validity and impact of the CDSS outcome as well as create a traceable path for each analysis that the CDSS has made. Two new processes should be added to the layer that allow stakeholders to do this: outcome performance tracking and process performance tracking

(Figure 40). The actors involved here are the hospital board, clinicians and IT support staff (where only the IT support staff will track the metadata of the system). Outcome performance tracking can best be performed using a dashboard that generates and presents performance measures in an intuitive and understandable way as the hospital board and clinicians might us this interface as well. The process performance tracker can be displayed in an arbitrary manner (depicted here as a simple database interface). Although measuring impact is still difficult, this design at least reserves a space for this. The third process is a development process (Figure 41). With a dedicated entity for the CDSS in place, development of new algorithms can also take place in this department (in accordance with SYR1b). The results of these new algorithms will not be used in clinical practice until they are validated but can be assessed by developers or clinicians to determine their quality and possible future use in everyday practice. The process of developing these new algorithms relies on the CRISP-DM methodology that was presented in section 3.2. Important to note is that once the hospital is satisfied with the performance of a new or improved algorithm, a formal validation study should take place (SYR9). Since there is a lot of debate on the form that these studies should take, this process cannot be described in detail until the sector has come up with consensus. It is however important to be aware of this and therefore this validation step is stressed by adding another trigger before the deployment step.

Figure 41: Process of developing new algorithms for the CDSS