Integration of Documentation Task into Medical Treatment Processes in the Hospital

Abstract

Medical Guidelines capture medical knowledge how to diagnose and treat certain diseases. To some degree they describe patient data that is required to make treatment decisions. Usually documentation of medical procedures is carried out as an afterthought and produces additional workload for doctors and nurses. In this contribution we study the German guideline for neck pain, translate the guideline into a process model and identify the tasks of this process where documentation needs to take place, as well as the required data.

Introduction

Documentation processes are an essential part of medical practice in a hospital. The documented data is used for billing the health insurer, communication with other health care facilities (e.g. aftercare, rehabilitation), medical research and evaluation of treatment options. These days the documented data has not always direct benefit for the current treatment of a patient. Often only data that appears useful in the short run is captured, neglecting the requirements of retrospective research. Finally, documentation processes are also error-prone, the more so the longer the topic to be documented lies in the past. As a result, documentation of medical procedures is often carried out only as an afterthought. This leads to additional workload for doctors, nurses and technical staf as well as redundant activities and media breaks. A study performed by the Deutsches Krankenhausinstitut e.V. (DKI) found for example, that surgeons spend 2 hours for patient-centric documentation and another 42 minutes for administrative documentation a day. Internists spend more than 2,5 hours for patient-centric and 40 minutes for administrative documentation a day ([ 6 ], [ 1 ]). Administrative documentation has been defined in this study as necessary data and documents for communicating with insurance or other administrative ofices. Patient-centric documentation on the other hand contains all documents having the patient in focus, like diagnosis and treatment. If documentation were better integrated with the treatment process, data produced during treatment could automatically be captured for documentation and the error rate as well as the overhead could be reduced. This way doctors and nurses would have more time for patients. In addition, if documentation of the current treatment had direct benefit for patients and medical staf during the treatment, the motivation to document would be higher.

Our idea is to use a formal model of the treatment process, which can be executed by a process engine. This way process guidance to the practitioner could be provided, e.g. making recommendations about the next possible treatment steps. To make an appropriate recommendation, the system needs certain information, based on data, which has been documented before. This information contains the state of the process, together with all necessary information about the patient and the environment to support the decision. Our approach is to log all the necessary information, which has lead to the decision together with the decision itself as documentation of the process. Therefore we need a formal model of healthcare processes.

The literature points at many contributions that represent a Clinical Practice Guideline (CPG) in a way usable by IT systems called a Computer Interpretable Guideline (CIG). Our idea is to first express the quite simple German CPG for neck pain with a Business Process Model and Notation (BPMN) model. Since medical treatment processes can be seen as workflows, standard process modeling languages, like BPMN [ 4 ], should be suitable to represent actual processes in a hospital as well as CPGs. Most industries employ BPMN to model processes. Even if BPMN has the same acceptence problems among healthcare professionals like other proposed formalisms, it is understood and widely accepted in other professions, e.g. by management and knowledge engineers. Hence other modelling experts can help healthcare professionals with modelling a CPG more easily.

If a CPG can be represented with BPMN it can be executed by common process engines, which are already used and established for business processes like billing and accounting. This supports the integration of CPG models in existing environments. The integrated CPG models can be used to verify existing processes or to build a Decision Support System (DSS) for treatment.

As a second step we annotate those activities in the process model which produce information that is to be documented. This is expressed via the BPMN construct of a data object. We simply list the information we are interested in documenting on the arc between the task that produces them and the data object. According to the Business Process Modeling (BPM) life cycle the process model has to be configured by attaching additional technical details in order to make it executable by a process engine. It is also during this step that the decision made at gateways are to be specified in detail.

This way, the necessary data for each executable task is specified. The data which is needed for each decision is specified as well and therefore known by the execution engine. All this data is then logged as process documentation. Furthermore, this data can be used for consistency checking in the model: Each task can check, if the data it needs is specified by some task before by building the reverse reachability graph. 2

Background

A CPG represents evidence-based medical best practices for certain medical conditions, e.g. lymphoma, describing their diagnosis and treatment. The definition and importance of CPGs have been mentioned in [ 10 ]. Grimshaw and Russell analysed almost 60 published evaluations of CPG usage and found that a great majority reported a significant improvement of quality of care and patient outcome [ 3 ]. To ensure the quality of those recommendations, in Germany CPGs are reviewed and staged in a systematic way by the Arbeitsgemeinschaft der Wissenschaftlichen Medizinischen Fachgesellschaften (AWMF). In this system the stage “S3” describes the highest quality. Although CPGs have a certain logical structure, they consist of free-form text, tables, and diagrams. Many of them are presented in a long and a short form. The short form may consist of only one or two pages, describing the overall procedure in a flow-chart. On the other hand, the long version may contain up to more than hundred pages describing each step in detail with possible side efects.

Since CPGs are normal text-based documents, they can not be used directly in computer systems. To do so, CPGs have to be formalized into computerinterpretable representations, so-called CIGs. There are many examples of CIGs, which have all been designed by diferent institutions with diferent goals in mind.

Wang et al. [ 10 ] analyze 11 CIG languages to identify the most important components. They found that actions and decisions are essential in all analyzed languages. Additional important components are patient state and execution state. All of the analyzed languages support this components. Peleg et al. [ 8 ] use the term Task Network Model (TNM) to describe CIGs that support hierarchical decomposition over time. This ability is an important feature during the modeling process, enabling a top-down approach and modularization. To find similarities and diferences of languages that are based on TNMs, six languages are compared in [ 8 ]. Despite the fact, that each language has been developed with a diferent goal in mind, common components, like structuring treatment plans sequentially, which may be parallel or not, have been identified. According to this research exisiting CIGs share most of the features, however, the CIG language landscape seems very fragmented and lacks a standard.

Mulyar et al. [ 5 ] investigate the support of four TNM-based CIG languages for 43 common workflow patterns like Multichoice, Milestone or Recursion1. They conclude that of all workflow patterns only up to 22 patterns have been supported by one of the investigated languages (PROforma). On the other hand not much lfexibility has been added by the CIG languages. This leads to the question, if those specialized CIG languages are really necessary, or if CPGs can be modeled with a general modeling language, like BPMN [ 4 ], which is a freely available standard by the International Organization for Standardization (ISO).

A current review [ 7 ] discusses and classifies 21 articles about research on CIGs. The classification describes 8 topics of interest for CIG research. These topics describe constitute phases in the life cycle of a CIG, like the integration with Electronical Health Record (EHR), validation or exception handling. The paper gives a good overview of the literature of the past 20 years and it becomes clear, that the development and deployment of a CIG is not trivial. 1 from http://workflowpatterns.com Essentially, guidelines are process models that contain medical knowledge. BPMN is a widely accepted and understood standard to model business processes. Because it allows to represent all the relevant concepts of CPGs identified in [ 10 ] and [ 7 ], BPMN seems also suitable to model and represent CPGs. A CPG modeled with BPMN could be integrated into IT systems that are already employed in the hospital to support administrative workoflws. Since BPMN is an open standard, sharing of guideline models would be easier. Additionally, there are many tools for validating and transforming BPMN-models available.

To demonstrate our approach, we took the neck pain guideline created by Deutsche Gesellschaft für Allgemeinmedizin und Familienmedizin (DEGAM)2 [ 2 ] (80 pages of narrative, two flow diagrams) and constructed an initial model in BPMN. This model in figure 1 shows a conceptual top-down view, based on the flow-chart from the guideline. We used the tasks from the original document and added necessary decision gates. Additionally the gates were annotated with the dataflow necessary for documentation.

Our goal is to use as few constructs as possible to map the necessary concepts from the medical domain. The fewer constructs a model involves, the clearer and easier to understand it is. In the following we propose a mapping from common CIG constructs, which were developed to capture concepts of medical CPGs. Action An action is a simple task. BPMN has the notion of atomic tasks, which can be executed by the process engine. Each action can be connected to a data object in which data is stored, like an EHR. The user only has to specify which data shall be stored in which system We do not want to concern the user with details on how the data is stored.This has to be done by configuring the process engine.

Decision Decisions are made by medical experts. They regard the diagnosis to be made or the treatment to be chosen. This decisions are based on the actual patient state as represented in one or more data objects providing an EHR. A DSS might calculate ranked recommendations based on the documented data in the EHR and present it to the practitioner. The practitioner then can choose one of those options (or something completely diferent). Her choice is then documented in the EHR, together with an optional argument for the decision. Process models in BPMN use the construct of gateways which comes in diferent variants to represent choices to be taken during the process execution. For decisions we take XOR-Gateways to represent exclusive decisions.

Data inquiry Data inquiry for actions is implicit in the model. The inquired data for decisions is for now modeled using textual annotations at the gateways.

Hierarchical plans Sub-processes in BPMN support the hierarchical decomposition of processes. This construct therefore allows to decompose the model, an operation also possible in TNMs. 2 http://leitlinien.degam.de/index.php?id=269 Parallel tasks BPMN supports parallelism using parallel gateways (ANDGateways). Those can be used to model parallel tasks, like requesting multiple tests in the laboratory. Scenario Neck Pain Guideline Our model has one start event (“patient arrives”) and two possible end events (“patient treated” and “patient referred”). They represent the entry of patients and the two diferent outcomes specified in the guideline.

The action “anamnesis” is modeled as an atomic task. During “anamnesis” the doctor asks the patient about her medical history and current condition, e.g. where the pain is located and when it began. This information needs to be documented. The documentation system is modeled as a data object called “EHR”. The user input is implicit in the BPMN and does not need to be modeled explicitly. The output for the process documentation has to be modeled, but only to the point, that the user has to specify, which data has to be documented. This specification is done by writing the data fields on the edges, which are associated with the data object. In our example it is shown, that some data called “patient status”, “pain location”, “pain duration” and more is stored in the data object. The tasks “clinical examination” and “referral to specialist” also store data in this data object. An additional data object “discharge letter” is created in the task “referral to specialist”. Only atomic tasks can have an association to a data object. Sub-processes like “further examinations” are not connected to data objects so as not to overload the model. Instead, if a sub-process contains atomic tasks, which consume or produce data, this is modeled in the sub-process. Because data objects are referenced by name, a sub-process can use the same data store (e.g. data object “EHR”) as the overall process, just by using the same name.

Several kinds of decisions are included in our example. The first one is the most complex. Based on the data stored in the “EHR”, a ranking is presented which gives the user to classify the patients pain either as “unspecific” or as “suspicion of serious reasons”. This is modeled for now using a textual annotation. During the congfiuration phase of the process model an algorithm needs to be provided by the process implementer that realizes the decision. The best option would be to devise a generic decision algorithm and a domain-specific language for modeling decisions (required data, possible options, arguments for options) which expressions could be interpreted by the algorithm. This use of user-specified annotation languages is supported by the BPMN 2.0 standard. However, this is out of scope for this contribution. The second kind of decision is shown after the task “further examinations”. The doctor can decide, if she should refer the patient to a specialist directly or perform X-Ray diagnostics before. 4

Discussion

The hospital process domain exhibits a gap between medical treatment and organizational processes. While CPGs provide valuable knowledge to medical practitioners they are not designed to be supported by IT systems. Therefore CIGs were introduced as formal representation of CPGs. However, they focus on medical aspects of the process and cannot be easily integrated with organizational aspects, like registration of examinations, or billing the health insurer. [ 5 ] found that CIGs do not add flexibility to treatment processes. On the other hand, BPMN was developed to express these business processes and, together with a process engine, to support them and integrate existing IT systems. Previous work by Reijers et al. [ 9 ] found out, that workflow management, an approach similar to BPM, can be successfully used to support medical treatment processes.

In this contribution we only consider the integration of documentation steps into the treatment process. To this end we used standard BPMN with some additional annotations at the arcs to model one specific textual CPG. Large portions of the integration work belong to the configuration phase in the BPM life cycle, in which detailed specification for the process model is provided, to make the model executable. This includes binding the data objects, used in the model, to data storages like EHR, mapping the annotations to information produced by the corresponding task, and providing the decision rules for gateways.

We plan to evaluate the open-source process engines Activiti 3, jBPM4 & Drools5, ruote6, Enhydra Shark7, camunda8 and Bonita BPM9 to our needs. Then we will implement the modeled guideline in one of these engines address the afore-mentioned questions. 3 http://activiti.org 4 http://www.jboss.org/jbpm 5 http://www.jboss.org/drools 6 http://ruote.rubyforge.org/ 7 http://shark.ow2.org/doc/1.0/ 8 http://www.camunda.com 9 http://www.bonitasoft.com/

References

1. Blum , U. , Müller , K. : Dokumentationsaufwand im Ärztlichen Dienst der Krankenhäuser . das Krankenhaus pp. 544 - 548 ( Jul 2003 )

2. DEGAM: Leitline Nackenschmerzen . AWMF (Jun 2009 )

3. Grimshaw , J.M. , Russell , I.T.: Efect of clinical guidelines on medical practice: a systematic review of rigorous evaluations . Lancet 342 ( 8883 ), 1317 - 1322 ( Nov 1993 ), PMID: 7901634

4. ISO/IEC: Information technology - object management group business process model and notation . Tech. Rep. 19510 , ISO/IEC (Jul 2013 )

5. Mulyar , N., van der Aalst , W.M. , Peleg , M.: A pattern-based analysis of clinical computer-interpretable guideline modeling languages . Journal of the American Medical Informatics Association 14 ( 6 ), 781 - 787 ( Nov 2007 )

6. Müller , K. , Blum , U. : Krankenhausärzte: Enormer Dokumentationsaufwand. Deutsches Ärzteblatt 23 ( 100 ), 24 (Jun 2003 )

7. Peleg , M. : Computer-interpretable clinical guidelines: A methodological review . Journal of Biomedical Informatics 46 ( 4 ), 744 - 763 ( Aug 2013 )

8. Peleg , M. , Bury , J. , Fox , J. , Greenes , R.A. , Hall , R. , Johnson, P.D., Jones , N. , Kumar , A. , Miksch , S. , Quaglini , S. , Seyfang , A. , Shortlife , E.H. , Stefanelli , M. : Comparing computer-interpretable guideline models: A case-study approach . Journal of the American Medical Informatics Association 10 ( 1 ), 52 - 68 ( 2003 )

9. Reijers , H.A. , Russell , N. , Geer , S. v.d., Krekels , G.A.M. : Workflow for healthcare: A methodology for realizing flexible medical treatment processes . In: RinderleMa, S. , Sadiq , S. , Leymann , F . (eds.) Business Process Management Workshops, pp. 593 - 604 . No. 43 in Lecture Notes in Business Information Processing , Springer Berlin Heidelberg (Jan 2010 ), http://link.springer.com/chapter/10. 1007/978-3- 642 -12186-9_ 57

10. Wang , D. , Pelegb , M. , Tub , S.W. , Boxwalac , A.A. , Greenesc , R.A. , Patela , V.L. , Shortlifea , E.H. : Representation primitives, process models and patient data in computer-interpretable clinical practice guidelines:: A literature review of guideline representation models . International Journal of Medical Informatics 68 ( 1-3 ), 59 - 70 ( Dec 2002 )