Nowadays Clinical Pathways are used in many hospitals in order to control quality and cost of treatment. Clinical Pathways can help to collect knowledge about treatments and to automate some organizational tasks, but only if they are largely integrated into clinical knowledge processing systems. On one hand process management tools are used for modelling and simulation and on the other hand providers of health information systems have begun to integrate pathway support into their systems. But there is still no interchange between these applications and no possibility to change pathway definitions among different hospitals. This paper introduces a concept for sharing Clinical Pathway knowledge among different systems and hospitals. It is intended to be one step towards a common reference architecture.
Increasing costs for health care and the resulting changes of the accounting systems forced health care organizations to think about knowledge management not only concerning medical aspects like diagnose and therapy but also economic aspects like specialization and process optimization. One major problem of knowledge management in health care organizations is the separation of medical knowledge, organizational knowledge and management information in different information systems without any connection to each other.
The integration of Clinical Pathways (CP) into Healthcare Information Systems
(HIS) is one approach to connect knowledge about medical and economic goals, tasks
and processes. A Clinical Pathway is the consensus about the optimal way of
treatment for a homogeneous group of medical cases respecting quality and economic
aspects. They can either be valid for one hospital or like a standard guideline for all
institutions doing this type of treatment. Each CP model defines the range of actions
in the areas of diagnose, therapy, care and administration that could and should be
performed as part of the treatment [
Today a few software providers of HISs offer basic functions for the support of
CPs [
As part of our work within the working group “Medical Controlling” of the German “Society for Medical Informatics, Biometrics and Epidemiology (GMDS)” we developed requirements for an all-embracing implementation of CPs in hospitals daily routine as well as computer-based clinical knowledge processing. The most important requirements are listed below:
Distributed Architecture for the Pathway Lifecycle. A huge number of CPs are already modelled with today’s process modelling tools. They could – at least partially – be reused by different hospitals treating similar cases or by different institutions concurrently or sequentially involved in the treatment process. To support this clinical information systems should be able to process externally defined workflow models. So we need a distributed architecture for the lifecycle of CPs where models and instances are shared.
Implementation of Pathway Concepts. Tasks like triggering pathway actions, monitoring and documentation of decisions and deviations from the pathway scheme at best take place in the HIS where knowledge about treatments is available and multiple data entry can be avoided. So electronic health records (EHRs) and HISs particularly have to integrate a pathway knowledge model that among others connects pathway objects with other EHR objects and a workflow engine that puts the pathway into action e.g. generating task and checklists or triggering user interactions for decision making. Connections with other HIS functions like referral, electronic order entry and time scheduling are also needed to ensure the pathway schedule.
Models and Standards for Communication and Interoperability. In order to use different applications within the pathway lifecycle as shown in Figure 1 pathway models and instances of realized pathway must be exchanged between different systems (e.g. models between process management and HISs or instances between HIS and analysis or simulation tools). This requires a reference model and interchange formats for a standardized definition of semantics and syntax of pathways.
To satisfy the requirements mentioned above but also keep the cost of integration low we propose an architecture, were only “static” information is exchanged between different functional components like pathway models and instances of realized pathways or pathway parts, but for example no control information of the workflow engine (Fig. 1).
Workflow Control and Documentation
We developed a pathway meta model, defining the target pathway ontology. The following gives a general idea of its main characteristics:
The pathway meta model has to combine different views of medical treatment, like diagnose, therapy and care tasks, administrative tasks or resources and costs with target and real consumptions. Also it needs concepts to carry all necessary knowledge e.g. for workflow control, monitoring of quality and costs, resource control, scheduling and user guidance.
The pathway object – as the main concept – encloses global knowledge like the pathway goals, inclusion and exclusion criteria, stop, cancel and pathway alternation criteria and attributes for administration of pathways. We distinguish between different kinds of action classes belonging to the pathway such as medical actions (diagnose, therapy and care), administrative actions (e.g. referrals) and computational actions (data entry, evaluation and advices). Further we distinguish different control structures (branching, decision and synchronization points). A semantic mapping of data objects among different applications by using a controlled vocabulary that can be generated by the HIS or is based on a more general reference information model (RIM) is recommended.
Compared to existing clinical guidelines or workflow models our approach mainly focus on characteristics of CPs that are considered in our pathway meta model in an explicit way:
Dealing with Time. CPs should support the organization of medical treatment in an appropriate way. Therefore our model allows arranging actions within a coarse timetable based on treatment days or time windows of several hours. Actions can be executed in any order within a time window, and action states must be checked at the end. They can also be triggered by conditions e.g. warnings in case of runaway costs.
Dealing with Deviation. CP models have to determine allowed deviations such as usual delays of execution time with additional delay tolerance information and the skipping of an optional action e.g. with an optional flag. Major deviations need to be documented.
Specific Clinical Concepts. Our model of CPs considers all needed actions for medical treatment and clinical organization, like procedures, referral or order entry.
pathway meta model covers guideline specific concepts such as rule based structures for decision support (e.g. for evaluation of actions, pre/post conditions and pathway goals) and concepts that are specific for workflows like costs and resources (e.g. staff, rooms and devices with number and duration or the patients presence, if needed).
Several paper have been published about integration of clinical guidelines [6, 7] or workflow models [5], and there are two important works that deals with reference models and standards for the interchange. The Guideline Interchange Format (GLIF) was developed by Ohno-Machado, Gennari et al. [8, 9] for the interchange of clinical guidelines. Other comprehensive work have been done by the Workflow Management Coalition (WfMC) in the field of workflow process models such as the workflow reference model and the workflow process definition interface (WfPDI) [10, 11].
The object model of the current version, GLIF 3.0, includes a guideline object with global information among others about the guideline algorithm, maintenance information, eligibility and aborting criteria. The guideline algorithm is composed by guideline steps that can be actions, decisions, branches, synchronizations, patient state steps and macros. The concepts used in GLIF 3.0 allow modelling a clinical workflow that defines concurrent and alternative sequences of medically oriented actions (therapy and administration) and programming oriented actions (e.g. data and event handling). A RIM determines semantics of data objects. Decisions and eligibility criteria are specified by the object-oriented expression language, GELLO.
The WfPDI allows defining workflow processes as a net of activities supported by various routing strategies that depends on the routing activity type and on each transition information. Execution time of actions is determined by transition conditions. Activities can relate to resources and can be coupled with computer applications or functions by a set of function parameters and by sharing system data. That’s why the interface supports resource management and integration into any applications very well. Structures that are not included but needed for a particular domain can be modelled additionally with ”Extended Attributes”.
If we want CPs to be a part of the clinical knowledge management that helps to optimize quality, efficiency and organization without causing additional effort for the clinical staff, the CP concept must be fully integrated into daily routine. CP models have to correspond with clinical organization and working methods and HISs need to be able to adopt CPs modelled with professional process management tools, for example CPs modelled by colleagues of other hospitals or medical societies. For this a modular architecture with standardized reference models and interchange formats is needed. The pathway meta model includes all necessary concepts from the medical and from the economical point of view and also for their integration in the HIS environment. The proposed architecture allows to reuse CP models and to share models and data among systems and institutions.
GLIF 3.0 and the WfPDI meet the characteristics and requirements for CP models mentioned above only partially. GLIF for example lacks of concepts for resource management, cost accounting and the possibility of defining and controlling global goals. Full integration into a HIS with a high degree of automation seems also to be not intended. Within the WfPDI specific clinical concepts are missing. Also an explicit timetable how it is usually applied with CPs is not intended. Instructions for deviation documentation are missing in both approaches. The WfPDI approach is more open and powerful than GLIF; all necessary concepts could be added by using the “Extended Attributes”.
A possible and useful solution could be to define a specific CP interface using the WfPDI concepts for implementation of our pathway model But apart from these reflections there is no solution without cooperation with today’s HIS providers. The “Integrated Clinical Pathways”-Approach is intended to be one step towards a common reference model. 4. Wetekam, V., Betz, F.: Soarian™ - Workflow Management im Gesundheitswesen. Siemens Healthcare Services. Online: http://www.uniklinikum-giessen.de/ kis-rispacs/archiv/2002/mi0940.pdf 5. Junginger, S., Kühn, H., Strobel, R., Karagiannis, D.: Ein GeschäftsprozessmanagementWerkzeug der nächsten Generation – ADONIS: Konzeption und Anwendungen.
WIRTSCHAFTSINFORMATIK 42 (2002) 5, 392-401 6. Gordon, C., Johnson, P., Waite, C., Veleso, M.: Algorithm and Care Pathway: Clinical
Guidelines and Healthcare Processes. Proceeding of AIME97, Grenoble (1997), 66-69. 7. Anyanwu, K., Sheth, A., Cardoso, J., Miller, J., Kochut, K.: Healthcare Enterprise Process Development and Integration. Journal of Research and Practice in Information Technology, Vol. 35 (2003) 2, 83-98 8. Ohno-Machado, L., Gennari, J. H., Murphy, S.N., Jain, N. L., Tu, S. W., Oliver, D. E., Pattison-Gordon, E., Greenes, R. A., Shortliffe, E. H., Barnett, G. O.: The GuideLine Interchange Format: A Model for Representing Guidelines. Journal of American Medical Informatics Association Vol. 5 (1998) No. 4, 357-371 9. InterMed Collaboratory: Guideline Interchange Format 3.0 Technical Specification (2002).
Online: http://smi-web.stanford.edu/projects/intermed-web/guidelines/ GLIF_TECH_SPEC_ May_4_2004.pdf 10. The Workflow Management Coalition: Workflow Process Definition Interface – XML Process Definition Language 1.0 Final Draft (2002). Online: http://www.wfmc.org/standards/docs/TC-1025_10_xpdl_102502.pdf 11. The Workflow Management Coalition: The Workflow Reference Model 1.1 (1995). Online: http://www.wfmc.org/standards/docs/tc003v11.pdf