Towards Health Care Process Description Framework: an XML DTD ...

Towards Health Care Process Description Framework: an XML DTD Design Pascal Staccini,b,d, MD, MS, Michel Joubert, PhD, Jean-Fran9ois Quarantad,MD, Sylvain AymardC, PhD, Dominique Fieschic, PhD, Marius Fieschic, PhD aDepartement d'Information Medicale, CHU Nice, France bSTIC, Faculte de M6decine, Universite de Nice-Sophia Antipolis, Nice, France CLERTIM, Faculte de Medecine, Universite de la Mediterran6e, Marseilie, France dCoordination des Vigilances Sanitaires et de la Gestion des Risques, CRU Nice, France The development of health care and hospital information systems has to meet users' needs as well as requirements such as the tracking of all care activities and the support of quality improvement. The use of process-oriented analysis is of-value to provide analysts with: (i) a systematic description of activities; (ii) the elicitation of the useful data to perform and record care tasks; (iii) the selection of relevant decision-making support. But paper-based tools are not a very suitable way to manage and share the documentation produced during this step. The purpose of this work is to propose a method to implement the results of process analysis according to XML techniques (eXtensible Markup Language). It is based on the IDEFO activity modeling language (Integration DEfinition for Function modeling). A hierarchical description of a process and its components has been defined through a flat XML file with a grammar of proper metadata tags. Perspectives of this method are discussed.

processes. It is known that for quality measurement to be practical, relevant and not time consuming, it must be integrated into the routine of provision of care and, whenever possible, use information systems. But, as regard the integration of quality paradigm, the development of information systems does not take place within any understandable or standardised framework5. Care activities cross over organisational boundaries. They involve multiple users for delivering services in a collaborative way of working. The technology support ought to be there to ensure that data needed is available. From a data management point of view, initial way of addressing this issue is to build "integrated clinical workstation" that provides clinicians with relevant multiple views of the patient's data. But health care working environment is changing. It shifts towards real-time transverse assessments and generalised support of decisionmaking to support risk management.

INTRODUCTION

Thus information systems must fit the dynamics of clinical pathways in terms of actions, roles and data exchange. This can be achieved through the medium of process models67. Process models can be used to drive the organisation's processes through workflow applications used to manage the coordination and the cooperation of actors executing tasks. They can also be used as a tool to capture existing or optimal work practices through multiple and interrelated activities to aid the understanding of complex organizational behaviour.

Today's health care professionals have to deal with both organizational and information technology challenges'. They experience difficulties to combine individual and collective needs for meeting strategies and content of the design and implementation of clinical information system2. It is obvious to say that the issue of information technology is to support professional activity as a whole. But, as regard to the elicitation of users' requirements, clinicians and nurses, working at the point of care, have to satisfy top-down organizational needs for data handling and activity monitoring, and would like flexible, relevant, collaborative and multidisciplinary decision support tools intended to help them improve outcomes3.3

OBJECTIVES

Components of process analysis techniques are8: 1) observation and interviewing; 2) modeling; 3) facilitated group decision making; 4) performance analysis. This current research addresses a part of the process analysis methodology, through the modeling of health care work practices. It is based on materials produced during the first step of observation and

The needs for quality improvements in health care delivery stress the necessity for the detection, the measurement and the prevention of adverse events4. The primary objective of a clinical information system is to trace all care activities for each patient and to allow users to document all events of the care

1067-5027/01/$5.00 C 2001 AMIA, Inc.

647

interviewing9. It is aimed to find a method to help the elicitation of users requirements, in order to build a web-based tool that could improve the navigation through the description and the documentation of the analysis. Generally speaking, process analysis requires activity and data modeling through a topdown approach. Thus there is a need to define a process definition framework to describe the relationships between components at each level of the decomposition, and to be able to share documentation within a single process or a family of processes. We implemented the material of process analysis with XML techniques (eXtensible Markup Language). The description of the hospital blood transfusion process9 is used as basic example to illustrate the specification of a heath care process definition framework using XML.

the inputs (I): information or material used to produce the output of an activity; - the controls (C): information or material that constrains an activity; controls regulate the transformation of inputs into outputs; - the outputs (0): information or material produced by or resulting from the activity; - the mechanisms (M): usually people, machines, or existing systems that perform or provide energy to the activity. Two other diagrams are proposed in this method that reflect the top-down decomposition of this modeling technique: - the context diagram shows the scope of the process or subprocess, with their major inputs, controls, outputs and mechanisms; - the node tree diagram shows the decomposition of the context diagram into specific subprocesses, sequential series of steps or tasks. -

METHOD

IDEFO methodology provides analysts and users with hierarchical views and components. The way we build the XML implementation according to these features, was to preserve these characteristics: the node root of the XML tree represents the high level process (context diagram) and subprocesses are child nodes. A heterogeneous structure has been built in order to compile the entire description of a process and its components within a single file, while preserving the description of single entities such as the roles and the tasks, in order to be able to reuse it as part of tasks or subprocesses. We unified in the same framework the description of tasks and the definition of the data.

Process analysis techniques are aimed to facilitate communication via easy understandable language, to provide a means of defining boundaries, to encourage the analysts to think and document in terms of the problem as opposed to the solution and to make it easy for them to modify the knowledge structure. One of the standard activity modeling technique is IDEFO (Integrated DEfinition for Function modeling). It is a structured methodology for functional process analysislo. The IDEFO activity modeling is based on a unit diagram, called ICOM box (figure 1) that shows, for a task or a set oftasks: C: How to ldentify the patient

0: Identity Chocked I:: Patient -0

Idenif Patient

R:: Physkian M:: identity data

0: Informed patient 0: Patient to be trandused C:: Choke of blood unit

0:: Prescription

_lChoose blood produt

R:: Physician

/

Wriodngu

C:: an order

0: Blood unit order 0:: Transfusion order O

Figure 1. Decomposition ofthe prescription ofa bloodproduct, first subprocess ofthe global transfusion process, showingfor each task the inputs (1), the controls (C), the outputs (0), the mechanisms and roles (M, R)

648

RESULTS The elements of the process definition The first step to design a DTD for a specific domain is to decide what are the elements to be managed. As regard to the process definition, there are three main elements of the domain: PROCESS, TASK and ROLE. There are two types of process: 1) the main process itself which can be seen separately in reporting (even if used as a subprocess elsewhere); 2) a subprocess is something which can be executed only as a subprocess of a named process and won't show up as a separate process. The object of a process can be described with a short comment. The note element contains text and can be attached to any other entity of a process. The keyword "description" of a note can be used to build documentation about process and its components.The basic XML definition of the process, subprocess and note elements looks like this:



Relationships between process model elements Tasks are atomic entities. An individual task may represent a subprocess. Tasks may be arranged into subprocesses. Subprocesses may be arranged into a process. In addition, tasks and subprocesses can respectively be combined into a subprocess or process, according to four control structures: sequence relationship describes that two or more tasks/subprocesses are executed sequentially; parallel or concurrent relationship describes that two or more tasks/subprocesses are executed in parallel; iteration, or looping describes that a task/subprocess is executed repetitively in a loop until a specified condition is fulfilled; conditional relationships allow to perform tasks only when certain conditions are met.

-

-



-

-

In order to make this structure valid and to be able to lists of elements or attributes shared between several elements, an internal entity has been defined. For example the process itself and the subprocesses may content sequences of tasks. The internal entity (%component) has been defined as followed:

use

In process analysis parlance, a task is an actively doable thing as opposed to an action, which is the specification of an actual concrete task. We chose to talk about "tasks" as being things to do. A task is performed: it is something to do within a process. A task is an atomic unit of work and cannot be decomposed as opposed to a process (e.g. identify a patient or write an order versus prescribe or order, etc.). A task has a name or label and can be described by a note. A single task may be used by several subprocesses within a single process. The XML reserved attribute ID is used to identify a task.

I

flrst step of the process dedicated to the decision of prescription to (...)