Criteria Judge Keith Swenson Judge Nathaniel Palmer Innovation * Really good example
* Very engaging and very prom- ising case study for all of us
* Make a fixed business process and lets nail exactly how we do that * I was very encouraged by this whole thing
* Very mature look at the improve- ments that need to be done
* Use ACM as a platform for col- laborating around the patient * following the lifecycle literally of the patient
* Focused on care provided over the course of disease management or something that in effect is going to involve multiple hospitalisation, multiple professionals
* Interesting framework on how to have that information really, in real time context, but also provide that platform for professionals to collab- orate around
Adaptability * Every patient is different and you have to adapt to it
* Adapt to the needs of each patient * Flexible
* Giving options
* Procedures will be routine or sur- geries could be routine but there is no routine patient
* Interesting framework on how to have that information really, in a real time context, but also provide that platform for professionals to collaborate around
Impact * Patient-centric
* Pull organisations together * Tool they need to then make de- cisions and act on them
* Doctors being knowledge workers
* Collaborating around the patient * Patient centric
* Following the lifecycle literally of the patient
* Involve multiple hospitalisation, multiple professionals
* Interesting framework on how to have that information really, in a real time context, but also provide that platform for professionals to collaborate around
* Clinicians will spend their time not dealing with the paperwork but really dealing with the delivery of healthcare
Table 12.8: ACM award reviewer’s feedback.
12.4
Setup Evaluation
The final approach undertaken to evaluate the proposal, was an evaluation by the actual de- velopers of current CISs. The author had an evaluation session with four members of the CIU at
12.4 Setup Evaluation 159
Velindre (for the session transcript see Appendix B). The members attending the session were David Howells and Rhodri Evans (Principal Software Developers), Hazel Bailey (a Principal Support and Business Analyst), and David Morrey (the head of the CIU at Velindre). The aim of this session was to evaluate the possibility of setting up and adjusting the proposal to work with the current legacy systems.
12.4.1
Session Structure
The evaluation session lasted for an hour and fifteen minutes where the author explained the approach, the scenario selection process, and the mapping process. Screenshots showing some of the prototype results were also presented and discussed. This was followed by a discussion about the usages, the approach, and the challenges of the proposal. The discussion was led by open-ended questions, which are grouped to discuss teams feedback on these aspects.
Usage
The usage questions mainly aimed to discuss the use of the approach in relation to Canisc. This included what they had already implemented for Canisc and what they plan to implement in the future.
• Would the requirements you already implemented for Canisc benefit from having a pro- cess engine?
• Can an event driven process engine, implement any of your future plans to improve the user functionalities?
• Would you consider moving to a more active system?
Challenge
The challenges set of questions aimed to discuss the possibility of applying the proposed ap- proach, and the barriers to its implementation.
• Do you find the implementation of this approach possible? • What would the barriers be to its implementation?
160 12.4 Setup Evaluation
Approach
The approach questions aimed to discuss the advantages and disadvantages of using the pro- posed approach.
• Did you consider using similar ideas in the past? • Would you consider using this approach in the future? • What are the advantages of this approach?
• What are the disadvantages of this approach?
12.4.2
Analysis and Results
The CIU team at Velindre agreed that having a process engine that recognises the pathway is very useful. They see the need for it in healthcare systems and in cancer care in particular. They confirmed that the adoption of the approach can make the treatment process more efficient. Moreover, it will merely transform the pathway to be electronic.
In terms of the usage of the proposal, the team confirmed that it is extremely relevant and lined up with the future plans for Canisc. In particular, it is ideally suited for the management of the MDTs within Canisc.
The team at Velindre also pointed out that Canisc already implements some of the workflow elements. One of these applications is the Ionising Radiation (Medical Exposure) Regulations (e-IRMER) [257], which is a radiotherapy planning and treatment scheduling and prescribing module. E-IRMER is both process and role based. The MDT summary in Canisc is also similar to this concept, where the system view everything the clinicians need to know, for an MDT, in one screen. Within the system, they list three of the most recent summaries and give the access to information available elsewhere.
Although similar elements of process engine have been implemented within Canisc, the team believe that the implemented functionalities can be done better using the proposed approach. These additional advantages include, the automation of the process which facilitates the team updates. They also clearly recognise that any planning process for any treatment can benefit from this approach.
The team at the CIU identified the clinicians ability to describe their needs as one of the barriers of implementation. Dr. Morrey said: "It is like chicken and egg, the clinicians are not used to thinking or expressing their business requirements in terms of an event driven system". The team
12.4 Setup Evaluation 161
agreed that clinicians are used to a more passive system. Therefore, they are used to expressing their requirements as access to the dataset within these systems. However, if clinicians express their needs as events, this will help information system developers understand what they want. Mr. Howells drew attention to the worry that this approach could be rigid and never change to meet different cases. However, Mr. Evans stated that this depends on how high level you view it as if you pitch it at a higher level you should cover 80% of the cases. Additionally, if the process map is done at a high level, probably 97% of cases will be covered. The higher this percentage covered is, the higher the risk becomes. This is because the clinicians will find it harder to remember the rest of the cases which do not fall into the mapped path.
This led to a discussion on finding the balance between presenting the right information at the right time and the risk of information not being available. This is because not all the information can be shown to the users which introduces a risk. However, Ms. Bailey stated that clinicians constantly make decisions where they do not have all the information available that there is a bigger risk, in stopping them from looking at the information. Therefore, they suggested providing access to other information or just giving the user the ability to flip between the workflow view and the traditional system.
In the discussion regarding the approach, the question about who is the decision makers was raised - namely is it the system or the clinicians?. This is when the author confirmed that decisions within the system are user driven and the system should not act on behalf of them. At the clinical decision points, the system indicates that relevant information is available and the final decision is taken by the clinician. This is when it was clarified that the system should be role based driven with respect to clinical decisions as well as patient driven according to the medical condition.
Another aspect discussed, regarding the approach, is where the data will be stored. At this stage it was clarified that the clinical data are stored in their own database. However, the process and coordination databases will be stored at the interface layer attached immediately to the workflow engine. Here the problem of information overload within the engine was raised.
The CIU team at Velindre described their move to this approach as an incremental step. The barrier to its implementation within Canisc will be the cost and specifying the requirements to justify the cost and the learning process. Add to this, the time needed for setup.
Mr. Howells believed that the interface with legacy systems is possible but not easy. This is as different versions of Health Level Seven (HL7) [258] are used in the implementations and each is engineered differently within the legacy systems.
In terms of whether the approach requires re-engineering, Mr. Howells thought it does, while Mr, Evans clarified that if it gets implemented on top of the current system only a web layer is
162 12.4 Setup Evaluation
required, which should not be a worry. Although it is not a straightforward process, it will not require re-writing the system but adding databases and engines. Moreover, the data exchange mechanism among legacy systems needs to be identified as to whether it is setting triggers to fetch new information or just waiting for the information to be sent (i.e. pull or push).
The disadvantage of this approach is the maintenance overhead, which could be costly depend- ing upon how often it needs to be changed and how easy it is to change. This is the biggest disadvantage of the workflow items already used within Canisc according to Ms. Bailey [259]. However, having the workflow managed in a separate workflow system should make changes to the workflow easier to implement [259].
12.4.3
Recommendations
The team at the CIU suggested a number of recommendations as follows:
• The inclusion of the role based access to identify the people who need to know the in- formation. This is to ensure the treatment process is user driven as well as patient driven.
• The use of the MoM guidelines to give the level of abstraction required for the map is valid. However, this should be followed by getting the users perception on this represented in a conceptual model or demonstrated in a prototype. Accordingly, users should alter the requirements to satisfy their clinical needs. Moreover, the developers need to discuss with the user and explain how things could be done more efficiently using an event driven approach.
• The team also suggested giving the users the option to switch from the workflow layer to Canisc to provide access to the full clinical record. This is to ensure that the system is not preventing access to any of the medical information that could possibly be required for a decision.
• The team agreed that this proposal is better implemented with something like the WCP. This is because it has interface access to many of the required legacy systems at the moment. This means that the WCP can be used as the connection to the other systems. This is probably the right place for this approach, to avoid doing the interfacing with the legacy systems again. Although it could be used as a type of functionality within Canisc, it may be more generic in the WCP.