10.4
Putting It All Together
In this section, the breast cancer ICP scenario (section 10.2) will be linked to the different process mapping elements (section 10.3). This is to clarify the interpretation process of the guideline stages into process definitions. The process definitions are mapped into process ob- jects and activities. Each of these activities and objects define what information needs to be processed, how it is going to be processed, and by which actor or role these actions will be pro- cessed. This leads to the granularity and the interactions with legacy databases being defined. This representation of the coordination process is a challenge since the clinical guidelines do not provide enough information about the details of the treatment stages and all the related elements.
In section 10.2.2 critical stages within the treatment flow needing support were identified (see figure 10.11). One of the critical stages, identified in 10.2, is the notification to MDT reviewers about the outcome of the triple assessment results and clinical examination notes. This notifica- tion stage is shown in figure 10.11, and requires the gathering of results of the triple assessment before the inclusion of the case for discussion at the next MDT meeting. Figure 10.22 is part of figure 10.17 showing how this single step in the clinical guidelines is interpreted in the process map. The interpretation consists of the following:
1. On completion of the triple assessment the patient gets referred to the MDT. On the map this requires the triple assessment’s process object to reach the state of being “completed”. 2. At the point when the triple assessment is completed, the system suggests to the user a referral of the patient’s case to the MDT review meeting. This is done through a referral activity in which the role and the user will be specified. This is to ensure that the referral is delivered to the right user’s inbox (see figure 10.23).
3. When the referral is completed, the process object of the referral will change its state to being “done”. This is when the case summary of the patient will be gathered. As a result a case summary process object will be created, which then calls an ASP activity which gathers all the required assessment results for the MDT.
4. The ASP activity will be linked to the module including its logic, as shown in figure 10.17. The logic here will connect to the multiple databases containing the assessment results within a C# code (see figure 10.24), examples include accessing the oncology database for medical history, the radiology for images, and the pathology for fine needle aspiration results. Using the patient’s information extracted from these database, the treatment flow is suggested, using the data-flow feature of the WFMS. The data collected will then be
124 10.4 Putting It All Together
gathered on a single screen designed and structured in the module’s code, within the VB.NET code (see figure 10.25).
5. When the summary is ready, the case summary state changes to “done”. The MDT meet- ing is scheduled for the inclusion of the patient’s case only after this stage is reached.
In order to map the above stages a considerable amount of preparatory work was undertaken and decisions made. An example of preparatory work, is identifying the different roles involved in the treatment process and the different shared inboxes/intrays for the different departments within an organisation. An example of a decision being taken is sending the MDT summary to the MDT secretary rather than the MDT members attending the meeting. This gives a taste of the challenges involved in mapping the coordination stages in the clinical guidelines into a WFMS. The implementer at the mapping stage will have to localise the map to the local procedures of the organisation which will run the system.
Our experience, showed that the process of translating the ICP into a WFMS requires a full understanding of the actual treatment process. It is essential to understand each of the treat- ment stages within the ICP and the related communication and coordination requirements that are necessary in these stages and between stages to ensure the care team members are fully informed about the patient’s progress and the team member’s role in the treatment. Therefore, the involvement of the stakeholders so that their requirements are understood and mapped into the flow stages is a key part of the mapping process. The actual detail of each of the treatment stages is what gets implemented in the map; actions are represented as activities, requirements of each of these stages and their outcomes are represented as objects and their states, users are represented as roles, and the sequence of the processes is represented in transition objects. These elements will then be used to construct the VO surrounding the patient.
10.4 Putting It All Together 125
Figure 10.22: Notification to MDT Process Map.
126 10.4 Putting It All Together
Figure 10.24: C# code for database access.
127
Chapter 11
Implications of the Proposed Approach
Overview
This chapter lists the implications of WffICP. The functionalities will then be discussed to see how they can support the care pathway. The operation of the implications will be explained. This will be supported by some examples and screenshots.