The domain of hemato-oncology is characterized by a complex and data-intensive treatment and the involvement of geographically distributed institutions (e.g. oncological ward, central commission, external panels) in the context of protocol-directed trials. Current research efforts in this domain (e.g. [1-3]) focus on specialized subtasks such as chemotherapy calculation and toxicity monitoring, but fail to support inter-application data flow and coordination aspects which have been identified as essential for integration in heterogeneous and distributed
clinical environments (e.g. [4,5]). Therefore, at Leipzig University, the distributed
workflow system HEMATOWORK, which has explicit knowledge about the oncological treatment and the associated communication paths between the involved institutions, is currently developed. In particular, HEMATOWORK intends to support the following basic tasks

Berger, H. Stephen

Brümmer, Franz

Fiebig, F.

Heller, Barbara

Jödecke, E.

Klöss, M.

Löffler, Markus

Mantovani, Luisa

Müller, Robert

Neubert, Ulrike

Rahm, Erhard

Speer, Runa

Winter, Alfred

Qucosa

HematoWork: a Knowledge-based Workflow System for Distributed Cancer Therapy

Qucosa - Publikationsserver der Universität Leipzig

HematoWork: A Knowledge-based Workflow System for Distributed Cancer TherapyR. Müller1, B. Heller2, M. Löffler2, E. Rahm1, A. Winter2, L. Mantovani3, M. Klöss2, H.Berger2,  F. Brümmer1, F. Fiebig1, E. Jödecke1, U. Neubert1, R. Speer21   ObjectivesThe domain of hemato-oncology is characterized by a complex and data-intensive treatmentand the involvement of geographically distributed institutions (e.g. oncological ward, centralcommission, external panels) in the context of protocol-directed trials. Current research ef-forts in this domain (e.g. [1-3]) focus on specialized subtasks such as chemotherapy calcula-tion and toxicity monitoring, but fail to support inter-application data flow and coordinationaspects which have been identified as essential for integration in heterogeneous and distrib-uted clinical environments (e.g. [4,5]). Therefore, at Leipzig University, the distributedworkflow system HEMATOWORK, which has explicit knowledge about the oncological treat-ment and the associated communication paths between the involved institutions, is currentlydeveloped. In particular, HEMATOWORK intends to support the following basic tasks:• Treatment Functionality: This core functionality of HEMATOWORK covers therapy man-agement and diagnostic monitoring, and is achieved through specialized applications (e.g.for calculating chemotherapy dosages) and databases coordinated by HEMATOWORK.• Intra-hospital Communication Functionality: As every specialized medical workflowsystem inherently requires services of other local sections and departments,HEMATOWORK supports processes for communication and material transfer between theoncological site and other local departments via the Hospital Information System (e.g. ap-pointment management with the radiological section, finding requests etc.).• Inter-hospital Communication Functionality: This covers the communication and mate-rial transfer between the treating hospital and external expert panels and central commis-sions. It includes sending medical reports and test material from the hospital to externalspecialists and commissions.• Tracking Functionality: This part of HEMATOWORK is located at the central commis-sions, and manages the tracking of the patients participating within the clinical trials. Thisinvolves periodical checks whether all reports have been received for a particular patient,and includes generating reminders and admonitions if reports are missing. Furthermore,incoming data are checked with respect to medical plausibility and correctness.2   MethodsFor workflow modeling, an extended Petri Net (PN) formalism has been chosen [6], based on[7,8]. Beside the classical PN constructs such as transitions, places, firing conditions, and to-                                                          1 Institut für Informatik, Universität Leipzig2 Institut für Medizinische Informatik, Statistik und Epidemiologie, Universitätsklinikum Leipzig3 Medizinische Klinik und Poliklinik II, Abteilung für Hämatologie/Onkologie, Universitätsklinikum LeipzigFig. 1: High-level PN describing the data flow between the departments.kens, the following extensions are used:• To allow flexible data modeling and to facilitate an implementation of the PN workflowmodel within a heterogeneous and distributed environment, tokens are objects conform tothe CORBA-model [9], being organized in class hierarchies and providing IDL4-interfaces.• Places and transitions can be subclassed; instances of subclasses usually are constrainedconcerning their token input/output and induce a specific behavior of the net interpreter.An important transition subclass of the oncological model is, for example, DetermineAnd-ExecuteMedicalPlan. Instances of this class are placeholders for diagnostic and therapeuticplans, and induce a request to a knowledge base to determine an appropriate medical plan,depending on the specific cancer type and the results of previous therapy procedures ap-plied to the patient. Similar to tokens, places and transitions have an IDL-interface.3   A Petri-Net Workflow Model for Distributed Cancer Therapy3.1  Organizational ProcessesFirst of all, HEMATOWORK provides a set of generic workflow nets expressing the organiza-tional structure of distributed hemato-oncology and abstracting from particular oncologicaldiseases and therapeutic procedures. Processes of this organizational class mainly cover dis-ease-independent aspects such as patient admission and discharge, or document managementand material transfer between the involved departments. Fig. 1 shows the global communica-tion paths and abstract high-level transitions of distributed hemato-oncology.As it is expected that additional hospitals and specialist practices will participate in oncologi-cal trials in the future, this organizational model does not make any assumptions about thenumber or geographic location of the participating organizations (organizational scalability).For example, the diagnostic panel and the central commission for a particular hematologicalcancer type may be located at the same site, or in different towns. To facilitate a site-specificimplementation, the model specifies all data requirements in CORBA/IDL.3.2 Disease-Specific Proc-ess RefinementDisease-specific aspects arelinked to an organizationalnet by cancer-type specifictoken classes (such as leuke-mia specific Report tokensubclasses derived from ageneric Report class), or byrefining the net during run-time through disease-specific                                                          4 Interface Definition LanguageReferredPatients :PatientProcessInitialDiagnosticsRegister andRandomize PatientTreat PatientCheck DiagnosisMonitor PatientTrack PatientCheck Treatment PlanTreating HospitalClinical Trial OfficeDiagnosticPanelTherapeuticPanelAdmitPatientDischargePatient= Place subclass InterHospitalComm for Web-based Inter-Hospital CommunicationFig. 2: Refinement of the abstract transition named Initial Therapy, which is an instance of the transition classDetermineAndExecuteMedicalPlan. The transitions named "CHOEP21" (a chemotherapy of the Non-Hodgkinlymphoma treatment) are instances of the class DetermineAndExecuteChemotherapy (which is a subclass ofDetermineAndExecuteMedicalPlan); "kb" is a global CORBA reference to the knowledge base.nets. To separate organizational from disease-specific processes and to support multiple usageof medical knowledge (as knowledge is used not only by the workflow system, but also byother applications), this disease-dependent knowledge is encapsulated in a knowledge base.Beside terminological information and knowledge about the structure of the basic diagnosticand therapeutic procedures, this knowledge base contains “procedural” knowledge about thedisease-specific conditional sequences of diagnostic and therapeutic steps. The knowledge ofthis procedural layer is then used to refine a generic workflow at run-time in the followingway (also see Fig. 2):If the workflow engine processes a transition of the type DetermineAndExecuteMedicalPlan,this triggers the activation of a so-called Plan Refinement Manager, which identifies the pa-tient´s specific situation (via inspecting the input Patient token), and then communicates withPatient::p,RandReport::rInitial TherapyCond: p==r.patient() // randomization performedAND p.toxicityCheckOk()==yes // no contra-indicationAction: PN subnet;subnet=kb.determineMedicalPlan(p.diagnosis(), r.arm());self->refine(subnet);// refine with disease-specific planCHOEP21Cond: If p.getNumCycles()>0:p.lastCycleStartedDaysAgo()==21;Action:  PN subnet; subnet=kb.determine-ChTh("CHOEP21"); self.refine(subnet);Post-Action:p.setNumCycles(p.getNumCycles()+1)Treatment Reports : ReportSalvage ProtocolCond:p.getNumCycles()==3 ANDp.therapyFailure()==yes;Action:  /* determine salvagetherapy in knowledge base */CHOEP21Cond: If p.getNumCycles()==3: p.therapyFailure()==no;If p.getNumCycles()>3:p.lastCycleStartedDaysAgo()==21;Action: ...pp::p.getNumCycles()<6p::p.getNumCycles()<3p::p.getNumCycles()==3p::p.getNumCycles()==6p RestagingCond: p.lastCycleTerminated-DaysAgo()==21Action:  ...pIntermediate RestagingCond:p.lastCycleTerminated-DaysAgo()==14Action:  ... ...ChThFSFSFChThFpRandReport::rPatient::p......Treatment Reports: ReportReport::repRefinedwithsubnetCorresponding Places (used forembedding of subnet into hostLegend: SF=Staging Form, ChThF=ChemotherapyKnowledgeBasePRMPRM=Plan Refinement Managero::Cond: Object o is moved to target placeif condition Cond holdsInstances of Transition classDetermineAndExecuteMedicalPlthe knowledge base to determine the specific medical (sub-)plan representing the appropriatemedical procedures to apply next to the patient. The identified plan is then transformed to aPN-notation and used to refine the DetermineAndExecuteMedicalPlan transition in a patient-and disease-adapted manner. The refined PN is then further processed by the workflow engine(which may detect further transitions of class DetermineAndExecuteMedicalPlan, inducingthe same refinement process on a level of finer knowledge granularity). A more detailed de-scription of the knowledge refinement process and the underlying knowledge representationapproach can be found in [10].4   Architectural and Implementation IssuesCurrently, a prototypical implementation of the workflow system HEMATOWORK is realizedat Leipzig University, based on IONA ORBIX and COSA Workflow, a PN-based workflowmanagement system. To achieve independence and autonomy of the involved departments,the net in Fig. 1 has been split up into 4 parts (indicated by the grey rectangles), each parthaving its own workflow server and communicating with the other workflow systems. Com-munication between geographically distributed departments is realized with IONA OrbixWeb.A chemotherapy calculator, a patient database and a report database have been implementedwith ORACLE/DELPHI, the oncological knowledge base is realized with O2.References(1) Musen, M.A., Tu, S.W., Das, A.K et al.: EON: A Component-Based Architecture for Automation of Proto-col-Directed Therapy. Journal of the American Medical Informatics Association vol ... (3), 1996: 367-388.(2) Séroussi, B., Morice, V., Dreyfus, F. et al.: Control theory as a conceptual framework for intensive caremonitoring. Artificial Intelligence in Medicine, 7, 1995: 155-177.(3) Müller, R., Sergl, M., Nauerth, U. et al.: TheMPO: A Knowledge-Based System for Therapy Planning inPediatric Oncology. Computers in Biology and Medicine vol. 27(3), 1997:177-200.(4) Brigl, B., Ringleb. P, Steiner, T. et al.: An Integrated Approach for a knowledge-based Clinical Worksta-tion: Architecture and Experience. Mth. Inf. Med. 37, 1998: 16-25.(5) Taboada, M., Marín, R., Mira. J. et al.: Integrating Medical Expert Systems, Patient Data-Bases and UserInterfaces. Journal of Intelligent Information Systems 7 (3), 1996: 261-285.(6) Aalst, W.M.P. van der: Three Good reasons for Using a Petri-net-based Workflow Management System. In:Navathe, S. and Wakayama, T. (eds.): Information and Process Integration in Enterprises, Kluwer AcademicPublishers, Norwell, 1997.(7) Lakos, C.A.: From Coloured Petri Nets to Object Petri Nets. In: Proceeding of the 16th International Con-ference on Application and Theory of Petri Nets, Turin, June 1995 (LNCS 935): 278-297.(8) Schöf, S., Sonnenschein, M., Wieting, R.: Efficient Simulation of THOR Nets. In: Proceeding of the 16thInternational Conference on Application and Theory of Petri Nets, Turin, June 1995 (LNCS 935): 412-431.(9) Ben-Natan, Ron, B.-N.: CORBA : A Guide to the Common Object Request Broker Architecture. New York:McGraw-Hill, 1995.(10) Müller, R., Heller, B.: A Petri Net-based Model for Knowledge-based Workflows in Distributed CancerTherapy. To appear in: Proceedings of the Workshop on Workflow Management Systems of the Conferencefor Extended Database Technology (EDBT98), Valencia, Spain, March 1998.

HSSS - Hochschulschriftenserver der SLUB

http://ul.qucosa.de/api/qucosa%3A33022/attachment/ATT-0/

HematoWork: a Knowledge-based Workflow System for Distributed Cancer Therapy

Abstract

Similar works

Full text

Available Versions

Qucosa

Qucosa - Publikationsserver der Universität Leipzig

HSSS - Hochschulschriftenserver der SLUB