In the second case study, we considered a process of an unplanned, stationary hospital- ization in a surgical clinic. The process includes patient admission, medical indication in the anesthesia, surgical intervention, post-surgery stay on the ward, patient discharge, and financial accounting. Most of the case study participants were medical staff such as doctors or nurses, but we also interviewed employees responsible for financial accounting. We selected these employees because of the knowledge-intensive business processes (e.g., diagnostic procedures) they are involved in. Note that the second case study approves and generalizes identified requirements of the first case study (cf. Section 3.3).
RQ1. The case study showed that most processes are not documented. Especially, inexperienced staff does not know how processes shall be documented and which process information they need. As responsibilities for processes are not clearly defined, this often leads to difficulties and misunderstandings regarding the collaboration between departments. Consequently, communication between departments is error-prone.
There are delays in the entire process (e.g., delayed diagnosis) because departments focus only on their own tasks. Problems further exist due to the lack of adherence to agreements, e.g., about the procurement of hospital beds to patients. Hence, these results show that documentation of business processes is crucial to overcome these issues. Hence, the results of RQ1 confirm our Requirement R1.
RQ2. Like in the automotive case study, we investigated the second research question based on the three sub-research questions as depicted in Table 3.3.
To answer SRQ1, we investigated the location of process information. In the clinical sector, both standard applications (e.g., SAP) and individual ones are in use. Clinical staff interacts with these applications using fat clients (e.g., DIACOS4) as well as thin clients (e.g., iMED5, CIRS6). Process information is available on shared drives, on local drives, on the Internet, in digital archives, and in paper-based form (e.g., patient files, medical reports, lab reports, and patient checklists). Our study has revealed that a large amount of process information is not available in electronic form at all (cf. Figure 3.4A). Therefore, exchange of process information between departments is often handled man- ually and only automated to a limited degree. Usually, the business processes and their tasks are not implemented but scattered over multiple systems. For example, patient data is entered in a SAP system, then printed, and further processed by different appli- cations. Hence, these results confirm Requirement R2; i.e., ease of access.
To answer SRQ2, we analyzed file formats and applications (e.g., SAP, DIACOS). Six out of eight interviewees confirmed that they mainly use PDF and Word files. None of the participants uses audio files and only one of them uses video files (medical tutorials). Like in Case Study 1, we asked for the three most important file formats the participants
4DIACOS is an application for documenting clinical services. 5
iMED is an enterprise-specific application of our case study partner.
75% 100% 50% 0% 88% 38% 100% 0% 0% 50% 100% Databases/applications Shared drives Local drives Optical storage media Internet Digital archives In non-electronic form Others
Question: Where is the process
information located? 21 15 9 6 4 4 4 0 10 20 Paper form DOC SAP PDF DIACOS OP-DOC RTF
Question: What are the most three
important file formats/applications during daily work?
A B
Figure 3.4: Location of process information and important file formats/applications.
need during their work. The formats most frequently used are paper-based documents, Word files, and SAP data records (cf. Figure 3.4B). Similar to Case Study 1, we have a large amount of different file formats and applications needed during daily work.
To answer SRQ3, we re-addressed quality issues of process information. Like in Case Study 1, we considered the structure and quantity of process information. Again, most process information is only available in unstructured form. Further, Case Study 2 shows that problems are the poor quality (e.g., poorly maintained data) and the incompleteness (e.g., not all necessary information is available on the emergency protocol) of process information. Besides, process information is often outdated, e.g., due to the lack of responsibilities concerning maintenance. The amount of process information is classified by most interviewees as “too few” (cf. Figure 3.5A). Process information is typically paper-based and only one person at a certain point in time can access this information (e.g., the patient file is needed for investigations, reporting, patient care, and accounting).
1 2 3 4 5 1
Question: How is the quality of the
available process information?
a
1: excellent, 2: good, 3: average, 4: below average, 5: unsatisfactory
lower quartile minimum median maximum upper quartile 1 2 3 4 5 1
Question: How big is the amount of
process information?
a
1: far too few, 2: too few, 3: the right amount, 4: too much, 5: far too much
lower quartile minimum median maximum upper quartile A B
Figure 3.5: Amount and quality of process information.
Quality of process information is rated differently (cf. Figure 3.5B). Reason is that the quality of process information differs depending on the data source. For example, self- made process information is ranked higher than third-party one. The issues considered
confirm Requirement R2; i.e., process information should be available in an adequate quality to effectively and efficiently perform business processes.
RQ3. Useful information to determine a process context can be time, users or individ- ual computers (because some devices are only used for performing certain process tasks). Also, the user’s location can be helpful, e.g., in order to determine whether a doctor is currently on ward or in the operating theater. However, four out of eight interviewees believe that it is difficult to determine a process context in healthcare processes. In par- ticular, there are no fully pre-specified processes. Instead, they dynamically evolve and many tasks are performed manually without any IT support. When considering tasks supported by applications, the process context can be determined based on the infor- mation progress (e.g., is a patient ready for accounting or already settled). Information state changes (e.g., State 1: “patient is in the operating theater” or State 2: “patient is on the ward”) in applications can be used to determine the process context as well.
When considering the results of RQ3, it is obvious that these results are consistent with the results of our case study in the automotive domain. Therefore, Requirement R3 has been confirmed by the clinical case study as well.
Hence, Requirements R1-R3 ensure process-, information- and context-awareness in POIL. Therefore, they can be considered as the most important POIL requirements.