Distributed Objects & Application Systems 2001, Rome, Sept. 18-20, 2001
Business Process Integration for Distributed Applications in Radiology Jens von Berg1, Joachim Schmidt, Thomas Wendler Philips Research Laboratories Technical Systems Division Röntgenstr. 24-26, 22335 Hamburg, Germany
Abstract Distributed object technologies offer access to data and services virtually everywhere in a distributed application system and introduce a high degree of freedom in application design. In order to retain flexibility even during business process re-engineering, the explicit modelling of business process aspects separately from the application system components is desired. The most prominent technology to serve this purpose is workflow management, which is a groupware technology and mainly focuses on the collaboration of people. Recently developer of distributed object platforms start to provide services that initially aimed at managing distributed transactions but also allow for the modelling and enactment of communication sequences between distributed objects. We have applied the workflow management approach practically within a heterogeneous laboratory environment integrating typical radiology application systems. Here, we compare our experiences with what can be expected from such a distributed object platform taking Microsoft’s BizTalk as example. Workflow management, enterprise modelling, radiology, worklist, BizTalk
Introduction Once data integration is established between relevant application systems within a radiology department also other technical issues like timing, distribution of work, and the co-ordination of events have to be faced. The general business goal driving these technical issues, however, is the need for efficient business processes in terms of costs effectiveness and client satisfaction. The re-organisation of health-care reimbursement systems in many countries necessitates this effectiveness and also requires closer collaboration between different health-care providers. We will focus on business processes within a radiology department. In a historic review we will analyse, how process aspects have been and are still covered with respect of different distributed IT architectures and paradigms applied to a department. Finally, two recent approaches to manage business processes in distributed IT environments will be examined in some more detail and will be compared: Production workflow and business 1
[email protected]
integration in a distributed object platform. To be able to compare these different approaches, we have to take two different viewpoints in account. The top-down viewpoint of business process re-engineering, that is to analyse and optimise real business processes, and the bottom-up viewpoint, how business process integration is attempted or achieved technically.
The process Collaboration to achieve a common goal in business is needed since the division of labour has been introduced long time before information technology. Machines play a crucial role in radiological diagnosis. But still most activities will be performed by people using these machines as tools only. We will briefly outline a typical process in the radiology department as it might occur regardless of the information technology in use: 1. A request for an examination comes from a referring physician outside the department and has to be registered by the receptionist. The examination gets scheduled. 2. The patient enters the department. His demographical data get cross-checked and some instructions are given to him. 3. The examination is performed in the examination room by technicians. 4. The quality of the images has to be checked 5. Based on the images and some other data, the report gets dictated by the radiologist. 6. Some kind of processing of the report occurs, usually manual transcription. But this part strongly depends on technology issues. 7. The report has to be authorised by the radiologist. 8. The report has to be transmitted to the referring physician. 9. The report is viewed by the referring physician. This is a typical process of a radiology department no matter whether film-based or digital imaging techniques are used and quite independent of the information technology architecture (like radiology information system RIS, picture archive and communication system PACS). Surely this is just an example, many factors may influence a real process and decisions have to be taken on the further progression of the process. However, the commitment to a certain information technology paradigm strongly determines, how such decisions are taken and by whom. We will give some examples of technology paradigms and their impact on process decisions.
Physical data objects There are certain important business objects that implicitly guide processes in a radiological department. One is the patient. He has to be physically present during the examination, but he is also an important source of information as he will be asked to cross-check the patient data. The traditional technique that has formed organisation in radiology departments is film-based planar X-ray diagnosis. The result is a physical image. This image is the second important business object that synchronises the participants of the production process after the image acquisition. The image or a set of images and other documents called the film-folder are passed from one person in charge to the other. Usually they pile up and will be processed in whole batches. Every person
has to decide where to send the film-folder after he has finished work following some well-known business rules. Thus, the process knowledge is captured by the employee rather implicitly. The situation with the patient is quite similar. He goes through different stations like reception, preparation room, examination room. Patients are queuing in waiting rooms and this de-synchronises different stations from each other like the pile of film-folders does for the post-processing after the image acquisition. In either case the physical existence of the business object is required to perform an activity. Nobody would think about doing an examination without the patient being present or starting to do reporting without the images at hand.
Client-Server Solution Client-server information system solutions typically map this situation into data models and implement them as databases. A typical Radiological Information System (RIS) of that architecture has data entities for the relevant business objects mentioned above like ’patient’, ’request’, ’report’. Unlike the real world instances in the example above, the records in a database are virtually always accessible to any person in the department. That is why next to common data attributes like ’patient name’ one always finds some attributes that represent the status of the entity like ’report.authorised’. These attributes are taken into account when querying the database in order to get those cases that need a specific processing next, like ’authorise report’. The set of all report entities that have the state attribute ’not reported’ form the authorisation-worklist, the counterpart to the old pile of folders on the radiologists desk. Thus, these attributes compensate the loss of constraints introduced by higher data accessibility - a drawback of a new technology which is beneficial in other respects. In this scenario these status attributes and the business rules how they get modified by user interactions determine the business process, that means what will be done next. Unfortunately, both the semantics of these status attributes and the business rules how to manipulate them are hard-coded within the application distributed over several components (often in such legacy systems, this application-logic is hidden in business logic very closely related to the presentation layer). They reflect the knowledge of the requirement engineers or developers at buildtime and can hardly be changed later on unless by massive changes in program code. Figure 1 gives an example of a state diagram that we received through reverse engineering of a client-server based RIS by considering state attributes of a patient record and the user interactions that change these attributes. As this logic has not been explicitly designed but rather evolved, it is anything but coherent and canonical, although the resulting behaviour of the system is well accepted by the user.
schedule examination
registered
not waiting set "urgent" set "on call" patient arrival
not waiting & urgent
waiting
patient arrival
not waiting & on call 1h
cancel examination cancel start examination start
waiting & urgent
cancel start
examined
finish exam.
Figure 1: State diagram for the business object ’patient’ revealed by reverse engineering of RIS database attributes and typical user interaction.
Document flow The management of document flow, which is also often called workflow management, still uses the paradigm of a physical data object, a file folder or in the radiology domain a film-folder. Some developers of workflow management systems explicitly use the metaphor of a file folder that moves through a department for the design and the description of their product. The messaging service may be quite simple, an email-service will be sufficient. Nowadays HTTP and XML are the most favourite standards for this purpose. Despite the introduction of some techniques that speed up communication even over long distances, the processing remains the same like in the ’physical data’ scenario. The incoming work items now pile up in a ’to do folder’, also called a worklist. Each item contains relevant data in the attached document to be performed. The process knowledge is still with the person. This person may be also supported by the client application that uses local business rules or some information from the document to decide how to proceed, quite similar to the client-server scenario. This scenario enables co-operation of loosely coupled applications and/or participants, but there is no explicit representation of the process. Unlike physical data objects like X-ray film prints electronic documents can be easily duplicated. By allowing this in a document flow system without a clear decision, who is in duty of that document (master vs. copy), one may very soon loose the synchronisation effect that a physical document has. One of the other mechanisms for process control specified in this paper will be needed then. The implementation of document-flow management is not a big deal as soon as documents are available in electronic form and a sufficient network is available. An acceptable integration of this
functionality into legacy application systems however may require considerable efforts. We may resume that the improvement of data flow does not necessarily mean to support process management, but in the end even may counteract it.
Business Process Re-engineering Business process re-engineering is a means to analyse and optimise business processes for a specific goal like cost-effectiveness or response-time. Process analysis, which is the first step to be done, exactly means to explicitly model all the knowledge about the processes that is kept by employees or is coded in application systems. Once this knowledge is available it can be used to support decisions on how to change business processes in the future [1]. A crucial part in enterprise modelling is the relationship between processes and resources, which covers authorisation but also the assignment of work items to resources and synchronisation between them. As there exist various perspectives on this area, there is rather little chance to get a common agreement (e.g. [2]).
Production workflow Explicit business process models can not only be used as a basis for optimisation and reengineering. They can also be enacted, that means interpreted and executed by a workflow engine that guides business processes and is intended to provide the right work for a user at the right moment. Although both is often called workflow management, this paradigm is quite different to the document-flow approach above2. The most significant distinction is the necessity of a central instance, the workflow engine, that governs all process models and some representations of the organisational structure. The business processes need to be modelled very strictly and precisely in order to be enacted automatically. In production workflow the process management is totally decoupled from data objects. All the relevant process knowledge, what has to be done next under which circumstances, has been taken from application systems and is coded as process models. Because this service does not provide the required data themselves, data accessibility is assumed in production workflow. Data may remain in central databases. Only references to data records will be communicated by the workflow engine to the client application together with process information about one activity like its type, deadline, and priority. The workflow participant gets a worklist from the workflow engine with all the work items assigned to him. The state of such a work item may change at any time by the interaction of other participants that have also access to the workflow service. The central management of process policies allows for a simple re-organisation of business processes without changing code in application systems. Only the process models have to be edited. A such flexible IT architecture will be a competitive advantage in rapidly changing organisations. On the other hand, enacting process models is a bit like running a computer program. Exceptions that have not been planned and encoded at design time cannot be handled. Many production workflow systems have incorporated exceptions or ad-hoc decisions by a participant, but by taking away control from the workflow engine whenever unexpected exceptions occur, one may loose also some of the benefits of 2
When we deal with workflow management we adhere to the terminology of the Workflow Management Coalition here [3]. See also [4] for a glossary and for the Workflow Reference Model.
workflow management. How such exceptions may be captured again, is still a research topic today [5,6]. In the meantime production workflow may be applied to business lines with a high degree of well structured business processes only. As a second drawback all participants have to accept the central authority of a workflow engine. This may work fine within a department or a rather small organisation. But who is allowed to capture an inter-organisational workflow by his central workflow service and thus to control the business process? Another weak point of production workflow will come up in one of the next sections where we present some practical experiences with it.
Market perspectives for process integration in radiology The application of production workflow in health-care and especially within a radiology department seams to be a promising approach [7]. Actually, radiology exhibits a high degree of well formed business processes that can be captured by process models. Next to the benefits of minimising costs for the department, also waiting time for the patient and for the referring physician, who plays the role of a client for the department, can be minimised. For the vendors of radiology equipment like RIS, PACS, and imaging modalities, generic process models that can be refined to meet the specific needs of a country or a concrete department could become a future product accompanied by the consulting service of the company. On the other hand, the growing pressure on healthcare providers by legislation changes in many countries forces them to explicitly deal with their business processes. Radiology equipment that once only had to transmit and process data now will be expected to seamlessly integrate itself into business processes and support them. In case of workflow management this means that they have to be workflow-enabled [8], which requires some modifications to them. Some similar recent approaches in the health-care domain focus on the data flow of radiological images [9] and financial management of a patient [10].
A laboratory demonstration system For the radiology domain, we have analysed business processes [11] and realised a production workflow solution as laboratory demonstration system using a COSA workflow engine (Figure 2). COSA [15] is a rather conservative but reliable product that we had to interface by several wrappers in order to fit into a distributed object environment. We have used both DCOM and Java RMI in order to connect to different application system components. The application system components have been laboratory prototypes or workflow-enabled Philips products extended by a worklist. Among them are Java applets (NetView), server-side web applications, and complete legacy systems (Easy Review).
5,6
ZHEFOLHQW
GHPRQVWUDWLRQ
1HW9LHZ
$XWR&OLHQW
(DV\5HYLHZ
ZRUNIORZHQDEOHG DSSOLFDWLRQV\VWHPV
&20
VRFNHW
KWWS
50,
VRFNHW
50,
KWWS
ZHE
ZI
DXGLR
VHUYHU
SUR[\
SUR[\
50,
50,
&26$
&26$
1HW9LHZ
ZUDSSHU
ZUDSSHU
VHUYHU
2'%& &26$
&26$ 2'%&
',&20
KWWS
KWWS
KWWS
',&20
ZRUNIORZ VHUYHU
5,6GDWDEDVH
',&20VHUYHU
&26$
ZRUNIORZVHUYLFH
DXGLR UHSRVLWRU\
GDWDVHUYLFHV
Figure 2: Establishing data and process integration by some middleware components. Figure 3 shows a simple process model in COSA notation that we use for demonstration purpose. Each activity is assigned to an organisational role (Figure 4) and the assignment to all worklists of current users playing that role will occur as soon as the activity is ready (that is, all pre-conditions are fulfilled) following the Petri-net paradigm. These business process models can be easily edited with a graphical tool provided by COSA and may get instantly enacted by the workflow engine.
Figure 3: A simple process model for our scenario.
Figure 4: An organisational model: organisational roles. For our prototypical implementation we have chosen a realistic scenario of a radiology department not only in terms of business processes, but also in terms of resources. For both data integration and process integration aspects, the most important resources are people and application system components. Also locations are interesting, but will not be considered here formally. In Table 1 we have assigned both people (more exact: workflow participants; who may perform?) and application systems (with which suited tool?) to the activities of our business process model.
á á
á
á á
á
Web application
Net View
Easy Review
modality
PACS
RIS
referring physician
transcriptionist
radiologist
automatic
radiographer
receptionist
Register request á Register patient arrival á Pre-fetch images á Generate images á Check quality á Dictate report á Transcribe report á á Authorise report á File images á View results á
á á á á á á
Table 1: Assignment of activities to roles and to application systems. All the application systems like a RIS, softcopy reporting station (Easy Review) and additional web-based distributed applications like Net View have been intimately integrated for their data and process aspects. Especially an interface to the workflow service had to be established. Others have been simulated only (PACS, imaging modality). In either case worklist handlers have been added, that provide a worklists in the sense of production workflow. Or previously existing worklists of the type presented in ’client-server’ have been replaced by them. Such a worklist receives its work items directly from the workflow engine and provides all items that are assigned to the specific user. Figure 5 shows the worklist of Easy Review. In this case there are several work items assigned to the user Dr. Leeson via her role ’radiologist’. Corresponding to their activity type, the execution of these items may require an application system different to the one in use. ’Authorise report’ for instance cannot be done by the reporting tool Easy Review (compare Table 1) although Dr. Leeson has access to activities of that type. It remains to each application system to cope with these cases, because workflow management systems do not cover such resource aspects, but just perform the assignment of activities to workflow participants. Only in the case of automatic activities, where the application system (PACS in Table 1) acts as workflow participant and no human interaction is required, the assignment is simple.
Figure 5: The worklist of the workflow-enabled Easy Review tool provides all work items for the radiologist Dr. Leeson.
Business integration within distributed object platforms The production workflow approach is mainly driven by organisational issues to support business process re-engineering with a flexible information technology in a top-down manner. On the other side, process integration is also an upcoming topic for the developer of distributed object technology platforms as a kind of bottom-up approach. One driving force here is to establish a framework for handling distributed and long lasting transactions, a rather technical approach to achieve data integrity. Data exchange through XML is a big issue. But the promoter of these technologies also see the need to code the collaboration policies of distributed objects within a dedicated repository and not within the involved objects. Microsoft for example pursues this policy with Orchestration in its BizTalk initiative [12]. Next to communication and data aspects its goal is also to support the extraction of those business rules from the application systems that are processrelevant in order to be more flexible with respect to business re-organisation [13]. We will take this approach as example for a distributed object platform to support business processes. We have taken this technology into account because it is already available in combination with the operating system Windows 2000. We had no general survey of similar approaches in the CORBA or Java/RMI area, but as far as we know they do not provide such a widely accepted approach yet. Perhaps Sun’s endeavoured web infrastructure called Brazil [14] will also address business process integration, but we could not prove yet. In BizTalk Orchestration business processes may be modelled and assigned to software components via ports (Figure 6). Some adapters for COM, MSMQ, SQL, SOAP, and third-party applications are available. After execution the components sends a message back and following the process model the next components will called.
developer’s implementation
business process design by analyst Begin in out
register request
component 1
in print labels
register patient arrival
out
component 2
in out
component 3
ports End
Figure 6: BizTalk’s assignment of activities to components by ports.
A comparison Now what are the inherent differences between classical workflow management and Orchestration? We will take a simple business process model with automatic and manual activities and we will try to describe, how relationships between these activities, people, and application system components are represented and handled in each approach.
Assignment Mainly there is one important difference between both paradigms that has many consequences: Workflow management assigns parts of a business process (activity) to workflow participants, which may be either people or application systems (e.g. ’AutoClient’ in our scenario) that perform the activity. Orchestration does an assignment to components. Thus, Orchestration focuses on automatic activities that can be performed without human interaction. There is no organisational model to define assignment to people. Actually, there is no worklist visible to the user, but there is a message queue for each component. Worklists have to be built either in the ’client-server’ style or in the ’document-flow’ style presenting the message queue to a user.
Orchestration
D
D
D
D
D
Z D
D
D
DFWLYLW\
UROH
FRPSRQHQW
D
D
V\VWH PW
automatic
agent role
Z
DSSO
Z
D
provides worklist
production workflow
process rule
trigger
assignment
Z
Figure 7: Differences between production workflow and Orchestration. In Figure 7 the most striking differences between production workflow and business integration in Orchestration are shown in a semiformal model of a sample process and its relation to people and application systems. The process consists of some activities (rectangles). Some of them do not require human interaction (automatic, marked with ’a’), others do. In both cases the process gets started by a person using an application system (top). In production workflow (left part) activities get assigned to workflow participants through role expressions whether they are automatic or not. The assignment to an application system occurs implicitly, because the user chooses the application system before this system contacts the workflow service. The decision, which work items are to present to the user within the set of items assigned to him, remains to the application system (see above). Automatic activities get assigned to a specific agent role (like ’AutoClient’). A software agent is authorised to play that role and will query the workflow engine for these activities. It may perform these work items, confirm execution, and gives control back to the workflow engine. For Orchestration the same business process is modelled on the right hand side of Figure 7. Here, the assignment of activities is done directly and explicitly to software components. In the case of automatic activities, which is the default case for this kind of technology, these components perform the activity and report the execution asynchronously to the next component following the process model. For those activities where human interaction is required, the addressed component has to care for the assignment to a specific user. This could be done by a worklist that needs to be implemented within the component (’w’ in Figure 7). However, such a worklist is not dedicated to a person or an organisational role, but to a software component or an activity type, respectively. It has to be queried like in the client-server scenario above. Also an email notification is possible here, which results in a document-flow-like worklist.
Process control Orchestration is mainly designed to control those parts of business processes that may run automatically. It does not explicitly assign work items to people. This is why process models are usually not as complex as those in production workflow, but rather a set of small fragments. It will also be used on a finer granularity level, because it is closer related to technical events like transactions on database level than to complete tasks for human performers. In Figure 7 the process model is split up into three parts, each one ending with the assignment of a work item to a person. This assignment is done by the component and not by a central engine. After this assignment the person or the component takes over control again. It may engage the Orchestration service again or it may not. The situation in production workflow is different: Here, control is also given to users and application systems for a short time as soon as the activity is started. But it is fully determined by the workflow engine, what should happen after the confirmation of that work item. This full process control is an enabler for successful business process reengineering. Reorganisation is relieved of the burden of re-coding application systems if relevant policies remain in a central repository. On the other hand, it may take a considerable effort to establish process models that really cover large part of the business process with many people and machines involved. Production workflow A whole business process is captured Assignment of activities to workflow participants e.g. via roles Automatic activities via a special role (agent) to component Full process control aspired
Orchestration Fragmented models Assignment of activities to components Manual activities via a special component (work list) to people Frequently gives control back to components/people
Table 2: A comparison summary.
Conclusion The term ’worklist’ seams to play a crucial role. It appeared in most of the scenarios presented here. A worklist always has the purpose to present current work items to a person. But although the worklist of each technology presented in this paper may look quite the same to a user, the underlying logic that builds up this list is different. The more precisely the interrelationship between activities, people, and application system can be represented by a technology, the more flexible it will be to cope with changes within either of these three areas without effecting the representation or even the implementation of the other two. With respect to the scope and the granularity of business process models we favour fragmented process models for further modelling approaches in the radiology domain. There may be one or several main process models similar to that in our simple demonstration that trigger sub-processes. The examination would be a good example of such a sub-process. According to relevant application data like the type of examination a sub-process model has to be chosen based on rules. Also synchronisation between concurrent processes may be helpful, e.g. a background process could collect all
appointments for patients who have been scheduled but did not show up. Further processing like re-scheduling can be initiated instantly for these patients. We have compared the two promising approaches to business process integration, which are classical production workflow and an approach incorporated into a distributed object platform, BizTalk Orchestration. Both paradigms have a different origin and a different history and even differ in the goals they pursue. We hope that we have found a reasonable framework for both to be comparable. Both support the partly automated assignment of activities to resources and both provide dedicated repositories to store the corresponding rules. But as workflow considers workflow participants as relevant resource only and Orchestration only accounts for components to be addressed, both approaches show a clear deficiency whenever both the performer of an activity and the necessary tool (the application system component) are relevant and non-trivial in the business model. Workflow fails in the management of application systems and may not even support the decision, whether a specific activity can be performed with a given application system component. And this even though this component provides a general worklist to display a work item for that activity. An additional resource management system will be required in this case [16]. Orchestration on the other hand fails whenever a non-trivial assignment to people is required, e.g. a role-based assignment, a time-table and similar policies typically implemented in the organisational model of a workflow management system. The only organisational aspect that is handled today is authorisation, but not assignment. A reasonable synthesis of these two somehow disjunctive approaches will be able to enact a model that covers both aspects: Who may perform the activity? And what tools will he need for it? Also the further question: Are they available? may be addressed in the future. Even in our simple application scenario such questions arose and could not be covered satisfying by either approach alone.
References 1. zur Muehlen M. Workflow-based Process Controlling - Or: What You Can Measure You Can Control. In: Fischer L (Ed.) Workflow handbook 2001, Future Strategies Inc. pp.61-77, 2001 2. Object Management Group. Workflow Resource Assignment Interface (RAI) RFP. bom/2000-01-03 3. http://www.aiim.org 4. Workflow Management Coalition. Workflow Management Coalition Terminology & Glossary. WFMC-TC-1011, April 1999 5. Han Y.,Sheth A.,Bussler C.: A Taxonomy of Adaptive Workflow Management. In Proc of the CSCW-98 Workshop - Towards Adaptive Workflow Systems, Seattle WA (1998) 6. Klein M, Dellarocas, C.: A Knowledge-Based Approach to Handling Exceptions in Workflow Systems. Journal of Computer-Supported Collaborative Work. Special Issue on Adaptive Workflow Systems. Vol 9, No 3/4, August 2000 7. Th. Wendler. From Image Management to Workflow Management. Proc. 13th Int. Symp. on Computer Assisted Radiology and Surgery, CARS ’99, Paris (France), pp. 409-413 (keynote lecture)
8. J. Schmidt, J. von Berg, K. Meetz, Th. Wendler: Workflow enabled Radiological Application Systems - A Multi Vendor Challenge. Proc. CARS 2000, San Francisco (CA), June 2000, pp. 396-401 9. Bukhres O, Hoang D.: CORBA-Based Architecture for Image Workflow in a Large Consortium of Hospitals. Proc. DOA ’99, Sept. 5-6, Edinburgh, Scotland. pp. 252-263 10. Riggs Ch, Bornstein E.: Workflow Automation: Improving the Bottom Line. HIMSS 2001, Febr. 4-8, New Orleans 11. Th. Wendler, K. Meetz, J. Schmidt, J. von Berg. Worklist Handling in WorkflowEnabled Radiological Application Systems. SPIE Int. Symposium on Medical Imaging 2000, Febr. 12 - 18, San Diego (CA), pp. 180-187 12. http://www.biztalk.org 13. Microsoft Corporation. BizTalk Orchestration. A Technology for Orchestrating Business Interactions.White Paper, June 2000 14. http://www.sun.com/research/brazil 15. http://www.ley.de 16. J. von Berg, K. Meetz, J. Schmidt, Th. Wendler: Organizational Modeling to support Workflow Mangement in Radiology. Proc. CARS 2000, San Francisco (CA), June 2000, pp. 402-407
