i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 6 ( 2 0 0 7 ) 688–700

journa l homepage: www. int l .e lsev ierhea l th .com/ journa ls / i jmi

Building a reference functional model for EHR systems

Yuki Sumitaa,∗, Mami Takataa, Keiju Ishitsukab, Yasuyuki Tominagab, Kazuhiko Ohea

a Department of Planning, Information and Management, The University of Tokyo Hospital,7-3-1 Hongo, Bunkyo-ku, Tokyo 113-8655, Japanb Rational Software, Software, IBM Japan Ltd., Japan

a r t i c l e i n f o

Article history:

Received 8 November 2005

Received in revised form

24 January 2006

Accepted 28 June 2006

Keywords:

Electronic health record (EHR)

Functional model

Functional representation

Medical record system,

computerized

Meta-functional model

Unified modeling language (UML)

a b s t r a c t

Introduction: Our aim was to develop a reference functional model for electric health record

systems (RFM). Such a RFM is built from functions using functional descriptive elements

(FDEs) and represents the static relationships between them. This paper presents a new

format for describing electric health record (EHR) system functions.

Methods: Questionnaire and field interview survey was conducted in five hospitals in Japan

and one in the USA, to collect data on EHR system functions. Based on survey results, a

reference functional list (RFL) was created, in which each EHR system function was listed and

divided into 13 FDE types. By analyzing the RFL, we built the meta-functional model and the

functional model using UML class diagrams. The former defines language for expressing the

functional model, while the latter represents functions, FDEs and their static relationships.

Results: A total of 385 functions were represented in the RFL. Six patterns were found for the

relationships between functions. The meta-functional model was created as a new format

for describing functions. Examples of the functional model, which included the six patterns

in the relationships between functions and 11 verbs, were created.

Discussions: We present the meta-functional model, which is a new description format for

the functional structure and relationships. Although a more detailed description is required

to apply the RFM to the semiautomatic generation of functional specification documents,

our RFM can visualize functional structures and functional relationships, classify functions

using multiple axes and identify the similarities and differences between functions. The

RFM will promote not only the standardization of EHR systems, but also communications

between system developers and healthcare providers in the EHR system-design processes.

Labour and Welfare (MHLW) of Japan conducted a national sur-

1. Introduction

The development of electronic health record (EHR) systems islargely constrained by the requirements and budgets of indi-vidual healthcare facilities and available technologies. Sincethese systems are developed using various concepts that

depend on these constraints, many differences can be foundbetween EHR systems [1–3]. Such differences cause difficultyin the cross-institutional sharing of clinical information. In

∗ Corresponding author. Tel.: +81 3 5800 8685.E-mail address: yukis-tky@umin.ac.jp (Y. Sumita).

1386-5056/$ – see front matter © 2006 Elsevier Ireland Ltd. All rights resdoi:10.1016/j.ijmedinf.2006.06.008

© 2006 Elsevier Ireland Ltd. All rights reserved.

addition, the lack of clarity in basic product definitions andrelevant standards had slowed the adoption of such systemsbecause it constrains incentives to adopt such systems [4].

To improve this situation, there is a real need for a commonplatform for EHR systems [5]. In 2002, the Ministry of Health,

vey of medical institutions. The survey revealed that only 1.2%of all hospitals and 2.6% of all clinics in Japan had adopted EHRsystems [6]. Although these adoption rates are quite low, EHR

erved.

a l i n

sTs

tmAirttftfaEduessubatsd

diasiwEOwrri

(TopsomtfEtsop

rsds

i n t e r n a t i o n a l j o u r n a l o f m e d i c

ystems are expected to become widely used in the future.herefore, it is crucial to develop a common platform for EHRystems before their widespread adoption.

In accordance with these needs, a committee and morehan 10 research groups were formed to consider a standard

odel for EHR systems with support from the MHLW in 2003.s one of these research groups, we began this research focus-

ng on EHR system functions [7,8]. Our final goal is to build theeference functional model for EHR systems (RFM), i.e. a modelhat represents EHR system functions, the functional descrip-ive elements (FDEs), which are the elements used to describeunctions, purpose assigned EHR systems and the static rela-ionships between them. In this paper, the term “EHR systemunction” is used to refer to “tasks that can perform specialctivities in order to accomplish certain purposes assigned toHR systems”. The term “purpose assigned EHR systems” isefined as “a goal that EHR system users are trying to achievesing the EHR system” and is equivalent to the purpose for thexistence of a function. In addition, the term “static relation-hip” is used in the sense that relationships are fixed underome conditions, independent of time. The RFM is representedsing unified modeling language (UML) [9–11] class diagramsecause we must consider the links with useful existing thatre represented using UML, such as HL7 RIM [12–14]. Note thathis project is not an attempt to develop a standardized EHRystem, but rather a standard model will be referred to in theesign and development of EHR systems.

Few projects have investigated the possibility of a stan-ardized model of EHR system functions. One such project

s ISO/TS 18303:2004 [15]. This technical specification listedstandard set of requirements for an EHR architecture that

upports using, sharing, and exchanging EHR across differentnstitutions. The requirements in this technical specificationere collected from more than 30 sources such as the gooduropean health record (GEHR) [16] and CEN ENV 13606 [17,18],penEHR [19]. The functional requirements described in themere represented in natural language text and a functional

equirement is classified in one axis. In addition, the staticelationships between functional requirements were not clar-fied in them.

Another project is the HL7 EHR system functional modelEHR-S model) project that was started in USA in 2003 [20].he EHR-S model project released a draft standard of a modelf EHR system functions in July 2004 [21]. The EHR-S modelrovided a functional outline, which is a reference list of EHRystem functions, and functional profiles of given settings inrder to standardize the descriptions of functions and for-ulate common understanding of functions. The EHR sys-

em functions were classified using two axes and the relatedunctions were described for each function if there exist. TheHR-S model was based on the concept that not all EHR sys-ems require all of the functions in the list, and only neces-ary functions should be extracted from the list dependingn the need at each facility. This is the concept behind ourroject.

In other fields, several recent studies have examined the

epresentation of functional knowledge [22]. One of thesetudies, IDEF0 functional modeling is well known as a stan-ard for function modeling method for modeling the deci-ions, actions, and activities of an organization or system

f o r m a t i c s 7 6 ( 2 0 0 7 ) 688–700 689

[23–25]. This method is used mainly in modeling business pro-cess [26] and manufacturing process [27,28]. However, there isa problem with this method: it is easy to interpret the modelas saying that an activity sequence exists when none in factexists [29]. Another study is methodology to represent func-tional knowledge using ontology. This method has often beenused in machine engineering [30–32]. In informatics, an onto-logical approach has been applied to descriptions of softwarerequirements and generation support for requirement spec-ifications through the use of ontology [33]. Nevertheless, nostandard descriptions of function structures and their staticrelationships in software function have been presented.

In this paper, we represent a new description format forEHR system functions. First, questionnaire and field interviewsurveys were conducted in order to collect the functions inexisting EHR systems. Then, a reference functional list for EHRsystems (RFL), which is a list of the EHR system functions thatwere identified in the above surveys, was created. In the RFL,each function is divided into FDEs. Finally, a meta-functionalmodel and a functional model, which are parts of the RFM,were created. In these models, the functions, FDEs, and theirstatic relationships are represented using UML class diagrams.In what follows, we present the details of each step and dis-cuss the significance and limitations of the new functionaldescription.

2. Method

The overall method involves three steps: collecting, listing andmodeling of EHR system functions. Fig. 1 shows a flowchartoutlining this research.

2.1. Collecting EHR system functions

2.1.1. EHR systems in JapanThe survey was conducted between January and March of2004. Five hospitals in Japan were selected, based on fourcriteria: (1) more than one hospital of each type was selected(national, public, or private); (2) more than one hospital ofeach scale was selected (large: more than 499 beds, medium:200–499 beds, or small: less than 200 beds); (3) each Hospitaloperates an EHR system with paperless management formore than 50% of outpatients; (4) each EHR system vendorwas different. The characteristics of the selected hospitalsare listed in Table 1. The purpose of this survey was to collectthe information required for developing the RFM. Therefore,the survey did not focus on comparing the functions of eachsystem but rather on finding and collecting as many functionsas possible.

Before conducting the field interview survey, question-naires were sent to the EHR system administrators of eachhospital. The questionnaire consisted of 293 specific exam-ples of EHR system functions that were classified into cate-gories such as functions for “medical care”, “clinical decisionsupport”, “communication between staff members”, and “sys-

tem administration”. In this questionnaire, the following sixpoints were investigated for each specific example: (1) thepresence or absence of an EHR system function matching thespecific example; (2) the presence or absence of a staff task

690 i n t e r n a t i o n a l j o u r n a l o f m e d i c a l

Fig. 1 – Flowchart outlining this study. The present methodhas three steps: collecting, listing and modeling of EHR

system functions. The dashed rectangle indicates a taskcurrently under discussion.

corresponding to the specific example; (3) the reason whya function matching the specific example does not existalthough a staff task exists; (4) alternative functions or opera-tions to perform the task in case (3); (5) the presence or absenceof a need for the function; (6) any additional comments.

Interviews with healthcare professionals, systems engi-neers, and systems administrators were conducted to obtainfurther details on the functions. In parallel with these inter-views, we investigated how to use the EHR system functionsby operating actual or test environment machines in order toobtain more information regarding the functions and opera-tional procedures. In addition, documents such as user’s man-uals and specifications for the EHR systems were collected.

2.1.2. EHR system in USAA 2-day field survey was conducted at one advanced health-care facility in USA during March 2004. The purpose of thesurvey was to list the important functions in the advanced

Table 1 – Characteristics of the selected hospitals

Hospital A Hos

Founder type Public PrivAdvanced treatment hospital No NoHospital scale Medium LarNumber of outpatients treated per day 800 100Years in operation Less than 1 year 2–3

i n f o r m a t i c s 7 6 ( 2 0 0 7 ) 688–700

EHR system. The survey had three main areas of consider-ation: “system architecture”, “functions of the EHR system”and “system business operation”. Distinct aspects of the EHRsystem were extracted for each area.

2.2. Making the RFL

The RFL was created using the above-mentioned surveyresults. The RFL is a list of the EHR system functions that wereidentified in the surveys. In this study, we limited the func-tions included in the RFL to those functions used by clinicians.The RFL focused mainly on functions for browsing, writing,and storing patient health records. We also excluded functionsrelated to the physician’s order entry at this time. In the RFL,each function was constructed from up to 13 FDE types: (1) sub-ject, (2) temporal constraints (user action), (3) temporal con-straints (informational constraints), (4) temporal constraints(state of system), (5) location, (6) object (person or system),(7) direct object (information or function), (8) indirect object(information), (9) purpose (clinical), (10) purpose (non-clinical),(11) instrument (physical), (12) instrument (non-physical) and(13) verb. The FDE types are described in Table 2. We limited theverbs used to represent functions to only 11 verbs (see Table 3).Using the FDE types, the minimum FDE set was defined as: (1)subject + (7) direct object (information or function) + (13) verb.This minimum set represents abstract functions. The specificfunctions were described by adding other FDEs to the mini-mum set. All FDEs other than the minimum set were treated asoptional elements. We listed functions using the strategy thatall vital functions and all prohibited functions in EHR systemsmust be listed without omission. Other functions are listed assample functions.

2.3. Modeling the RFM

As a first step toward modeling the RFM, we analyzed theRFL to find patterns in the relationships between functions.The RFM was then built using three models: the functionalmodel, the meta-functional model, and the purpose model.These models were represented using UML class diagrams.The functional model is a model representing “functions”,“static relationships between functions”, “FDEs”, “static rela-tionships between FDEs”, and “static relationships betweenfunctions and FDEs”.

The meta-functional model is a model that defines the for-mat used to express the functional model. The purpose model

is a model that represents the purposes given to EHR systems,which are fulfilled by the implementation of functions, therelationships between purposes and those between purposesand functions.

pital B Hospital C Hospital D Hospital E

ate Private Public NationalNo No Yes

ge Medium Small Large0 700 400 1000years 3–4 years 2–3 years Less than 1 year

i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 6 ( 2 0 0 7 ) 688–700 691

Table 2 – FDE types in the RFL and their description

FDE types Description

(1) Subject The subject of a function (limited to “system”)(2) Temporal constraints (user action) User actions required to start a function(3) Temporal constraints (informational con-

straints)Constraints on information required to start a function

(4) Temporal constraints (state of system) State of the system required to start a function(5) Location Location where a function is performed(6) Object (person or system) A direct or indirect object that a function affects. The object is limited to persons or systems(7) Direct object (information or function) A direct object that a function processes. The object is limited to information or functions(8) Indirect object (information) An indirect object that a function processes. The object is limited to information(9) Purpose (clinical) The clinical intention that is achieved by performing a function(10) Purpose (non-clinical) The non-clinical intention that is achieved by performing a function(11) Instrument (physical) Physical media required to perform a function(12) Instrument (non-physical) Means and instruments (excluding physical media) required to perform a function(13) Verb The verb of a function (limited to those shown in Table 3)

The italicized FDE types are mandatory to represent a function. The other FDE types are optional.

Table 3 – Definitions of verbs

Verbs Labels of verbs Definition

1 Output Output To send information to users, systems or physical media. The verbs “display”, “print”, “notify”,and “backup” are represented as “output to a screen”, “output to paper”, “output to a system”,and “output to storage media”, respectively

2 Accept Acceptance To receive the information specified by a user3 Collect Collection To gather information from inside and outside the system4 Calculate Calculation To collect data and provide numerical statistics5 Check Check To compare a direct object (information) and an indirect object (information) and return results6 Edit Edit Includes the verbs: create, update and delete7 Create Creation To produce new information8 Update Update To change the current status from already stored information to newly produced information9 Delete Deletion To eliminate stored information permanently

10 Store Storing To place or store information at a certain point in the system11 Prohibit To prevent the system from using functions

of the

tlcda

av

3

3

3Oattnc

Only 11 verbs were used to represent all functions in RFL. The labels

First, the meta-functional model was built using the pat-erns of the functional relationships that were found on ana-yzing the RFL. Next, examples of the functional model werereated in accordance with the meta-functional model. Theescription of the purpose model is currently being discussed,nd thus is not presented here.

In building the functional model, our goal was to modelt least one representative example of each pattern and eacherb.

. Results

.1. Collecting EHR system functions

.1.1. EHR systems in Japanf the 293 specific examples in the questionnaire, 270 existeds EHR system functions in more than one hospital. In addi-

ion to the differences between functions in each EHR system,he surveys clarified several cases in which the existence oron-existence of a function matching a specific example wasontradicted by non-existence or existence of a staff task cor-

verbs were used in the class representation in UML class diagrams.

responding to the specific example. There were 102 specificexamples in which an EHR system function matching a spe-cific example did not exist in more than one hospital, althougha staff task corresponding to the example existed was found.The primary reason for these cases was that the functionhad not been considered. Other common reasons were “otherfunctions were substituted for the function”, “difficulty in sys-tematization”, and “preference for human responses”.

3.1.2. EHR system in USASeveral advanced functions were found in EHR system in USA.Dictation and authorization for patients to access their ownrecords with same contents that doctors could access by givingtheir own IDs and passwords were not found in the hospitalssurveyed in Japan. Several advanced functions, such as alertsbased on cost management and regional partnerships, werefound in this survey.

3.2. Making the RFL

Approximately 100 specific examples extracted from the ques-tionnaire were represented as 385 functions in the RFL. Since

692 i n t e r n a t i o n a l j o u r n a l o f m e d i c a l

Table 4 – Percentage of modeling progress

Verbs Number offunctions in

the RFL

Number offunctions already

modeled

Percentage ofprogress (%)

Output 120 14 11.7Accept 55 3 5.5Collect 29 6 20.7Calculate 3 3 100.0Check 29 10 3.4Edit 85 5 5.9Store 54 5 9.3Prohibit 10 1 10.0

Total 385 47 12.2

Percentage of progress = (number of functions already represented

in the functional model)/(number of functions in the RFL) × 100.

the granularity of specific examples varied, these had to begeneralized and specialized to represent them as functionsin the RFL. In addition, the specific examples were subdi-vided into a few functions to represent them using only the11 verbs listed in Table 3. One such example is retrieval ofpatient information. This example was described in the RFLas three functions: (1) the system accepts patient informa-tion that user specified (such as key words and the scopeof the retrieval); (2) the system checks for the specified infor-mation and stored information; (3) the system outputs theresults”. Furthermore, functions appearing in the commentsand found while operating the test environment machine

were added to the RFL. This increased the number of func-tions to 385. Table 4 lists the numbers of functions classifiedaccording to the 11 verbs and Fig. 2 shows an excerpt fromthe RFL.

Fig. 2 – Portion of the RFL. F400028 is one of the most abstract fu“subject”, “direct object (information or function)”, and “verb”. Awhen saving a medical chart” is composed of five FDE types: “sufunction)”, “indirect object (information)”, “purpose (non-clinica

i n f o r m a t i c s 7 6 ( 2 0 0 7 ) 688–700

3.3. Modeling the RFM

3.3.1. The meta-functional modelOn analyzing the RFL, six patterns were found for the rela-tionships between functions—pattern 1: part–whole relation-ship between “direct object (information)” FDEs or “indirectobject (information)”; pattern 2: generalization and specializa-tion between “temporal constraints” FDEs; pattern 3: sequenceconstraints; pattern 4: extension with a condition; pattern 5:extension without a condition; pattern 6: prohibition. Pattern1 means that there exists a part–whole relationship between“direct object (information)” FDEs or “indirect object (informa-tion)” and there is no difference between other FDEs. Thispattern is explained with examples such as relationshipsbetween functions: “edit of medical records: the system (sub-ject) edits (verb) medical records (direct object)” and “edit ofreferral forms: the system (subject) edits (verb) referral forms(direct object)”. As referral forms constitute parts of medicalrecords and FDEs of the both functions are same excluding“direct object (information)”, the relationship between thembelongs to pattern 1. Pattern 2 means that there exists gener-alization and specialization relationships between “temporalconstraints” FDEs and there is no difference between otherFDEs. A “temporal constraints” FDE: “when a user edits infor-mation” is special case of “when the system is in operation”.Therefore, the relationship between them fits to pattern 2.Pattern 3: sequence constraint represents the case that func-tion A needs function B that should be performed beforefunction A. Pattern 4: extension with a condition representsthe case that if function B is performed and the conditionis met, then function A is performed, and pattern 5: exten-

sion without a condition represents the case that if func-tion B is performed, then function A is performed. Finally,pattern 6: prohibition means that function A prohibits thefunction B.

nctions and is represented by the FDE minimum set:more specific function, F400006: “authorization check

bject”, “user action”, “direct object (information orl)”, and “verb”.

i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 6 ( 2 0 0 7 ) 688–700 693

Fig. 3 – The meta-functional model. This model shows that a function can have 10 relationships with nine types of FDEs.T ly de

ttt

rsptmts

f““tst

ofisiF“aRs

he relationship types between functions can have two new

To represent these patterns, we defined the pattern 3 rela-ionship as a premise relationship and the pattern 4 and pat-ern 5 relationships as extension relationships in addition tohe relationships defined in the UML.

In the meta-functional model, these six patterns were rep-esented using three relationships: a generalization relation-hip for pattern 1 and pattern 2, a premise relationship forattern 3, and an extension relationship for pattern 4 and pat-ern 5, and a UML constraints description for pattern 6. The

eta-functional model in Fig. 3 shows that the relationshipypes between functions can have two newly defined relation-hips: “premise” and “extension”.

In addition, the meta-functional model indicates that aunction can have 10 relationships: “who”, “when (user)”,when (information)”, “when (system)”, “where”, “whom”,what (direct)”, “what (indirect)”, “how”, and “do” with nineypes of FDE: “subject”, “user action”, “informational con-traints”, “state of system”, “location”, “object (person or sys-em)”, “object (information)”, “instrument”, and “verb”.

The 13 types of FDE in the RFL were reduced to nine typesf FDE in the RFM. Specifically, “direct object (information orunction)” and “indirect object (information)” were mergednto one FDE type: “object (information)” with two relation-hips: “what (direct)” and “what (indirect)”. “Instrument (phys-cal)” and “instrument (non-physical)” were merged into oneDE type: “instrument”. Furthermore, the RFM did not treat

purpose (clinical)” and “purpose (non-clinical)” as FDE types,lthough purpose was regarded as one of the FDE types in theFL. This was because each function is created in order to fulfillome purpose. Therefore, “function” does not have “purpose”

fined relationships.

as a descriptive element, but “purpose” has “function” as afulfillment element.

3.3.2. The functional modelThe goal of modeling was achieved by selecting examples atsome abstract level as representative examples. As a result,12.2% of the functions in the RFL have been represented inclass diagrams of the functional model so far. Figs. 4–6 showexamples of the functional model. Each function was denotedas a class named using the letter “F” and a “six-digit number”.

The class diagrams shown in Fig. 4 are examples of pattern1. The relationship between “indirect object (information)” ofF400014 and that of F400016 was represented as a part–wholerelationship by using the aggregation relationship (a line witha diamond). The figure shows that “performing condition ofmedical practice” is part of “booking-related information” andthat the difference between F400014 and F40016 is only “indi-rect object (information)”. In such cases, generalization rela-tionship was used to represent the relationships betweenfunctions. Therefore, the relationship between F400014 andF400016 was represented as a generalization relationship (aline with a triangle).

Fig. 5 shows an excerpt of the functional model and FDEviews which extracts FDEs of the same type and the rela-tionships between functions from the functional model. Thefunctional model in this figure shows pattern 2: generaliza-

tion and specialization between “temporal constraints” FDEs,pattern 3: sequence constraints, pattern 4: extension with acondition, pattern 5: extension without a condition, using gen-eralization, premise, and extension relationships.

694 i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 6 ( 2 0 0 7 ) 688–700

Fig. 4 – Example of the functional model (pattern 1). The relationship between the “indirect object (information)” of F400014(booking-related information) and that of F400016 (performing condition of medical practice) is connected using anaggregation relationship (a line with a diamond side), indicating that “performing condition of medical practice” is part of“booking-related information”. In addition, the difference between F400014 and F40016 is shown only in one FDE: “indirect

000

object (information)”. Therefore, the relationship between F4relationship (a line with triangle side).

In the RFL shown in Fig. 2, the relationships between func-

tions F400010 (authorization check when editing a medicalchart), F400006 (authorization check when saving a medicalchart), F400002 (authorization check when logging in), andF400008 (authorization check when viewing sensitive info.)

Fig. 5 – Example of the functional model (patterns 2–5) and FDE vrelationship between F400009 and F400010, pattern 3 relationshbetween F400006 and F600034, and pattern 5 relationship betweare created by extracting the FDEs of the same type from the fun

14 and F400016 is represented using a generalization

and function F400009 (authorization check) were pattern 2:

generalization and specialization between “temporal con-straints” FDEs. In the RFL, the “temporal constraints FDE”:“when the system is in operation” are shown as blanks in“temporal constraints (user action)”, “temporal constraints

iews. The top left class diagram shows pattern 2ip between F400024 and F400009, pattern 4 relationshipen F400010 and F600008. The three other class diagramsctional model.

i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n

Fig. 6 – Example of the functional model (pattern 6). Thepattern 6 relationship between F100049 (display ofsensitive information) and F900004 (prohibition ofF100049): “when an unauthorized user requests access toia

(ootigt

rctTtp

r““iitctsm

w“iriwc(

tw

nformation, the system prohibits F100049” was describeds a constraint of F100049: “only authorized users”.

information constraints)”, and “temporal constraints (statef system)” FDEs. Therefore, all “temporal constraints” FDEsf F400010, F400006, F400002, and F400008 are generalized tohe “temporal constraints” FDE of F400009: “when the systems in operation”. Consequently, this case was represented aseneralization relationships between functions (see the func-ional model in Fig. 5).

The functional model in Fig. 5 also shows that the premiseelationship between user identification and authorizationheck. As a user must be identified before checking authoriza-ion, the premise relationship exists between these functions.herefore, the relationship between F400024 (user identifica-

ion) and F400009 (authorization check) are shown using aremise relationship in this figure.

Next, the extension relationship with a condition wasequired to represent the relationship between functions:authorization check when saving a medical chart” andupdating status of a medical chart”. The existing relationships that if a status of a medical chart is updated and this updates caused by an action that user saves the medical chart,hen authorization check must be performed. To represent thisase, the extension relationship between F400006 (authoriza-ion check when saving a medical chart) and F600034 (updatetatus of a medical chart) with the condition: “when saving aedical chart” was used in Fig. 5.Similarly, the extension relationship without a condition

as required to represent the relationship between functions:authorization check when editing a medical chart” and “edit-ng a medical chart”. The existing relationship is that autho-ization check must be performed when a user edits a med-cal chart. To represent this case, an extension relationship

ithout a condition, which means that F400010 (authorizationheck when editing a medical chart) was performed in F600008

editing a medical chart) without any conditions, was used.

Constraints descriptions in UML were adopted to representhe pattern 6: relationships in the functional model. A functionith the verb “prohibit”: “system prohibits Fxxxxxx if a con-

f o r m a t i c s 7 6 ( 2 0 0 7 ) 688–700 695

dition A is met” can be represented using the constraint: “thefunction can be performed unless condition A is met”. Fig. 6shows an example of constraint descriptions. F900004 (prohi-bition of F100049) is described in the RFL as a function withthe verb “prohibit”: “if an unauthorized user requests accessto information, the system prohibits F100049 (display of sen-sitive information)”. Rather than using the verb “prohibit”, theconstraint description describing conditions for performingfunctions was adopted. Therefore, the relationship betweenF100049 and F900004 was described as a constraint of F100049:“only authorized users”.

To represent some specific functions in the functionalmodel, we need to describe modifiers for “object (informa-tion)”. As one solution to describe these modifiers, we used“class-in-state” in UML. The “class-in-state” description canbe used to represent a class that has some states, such as“booking information [fixed]” and “booking information [edit-ing]” of F400017 (check of patient schedule) in Fig. 4.

In addition, “temporal constraints (user action)”, “tem-poral constraints (informational constraints)” and “temporalconstraints (state of system)” in the RFL do not need to bedescribed as a class in the functional model if these canbe represented as relationships between functions suchas “premise” and “extension”. To take a simple example,“temporal constraints” FDE of F100003 (display of patientinformation) was “when a patient is specified” in the RFL.The functional model represented this case as a premiserelationship between F100003 (display of patient informa-tion) and F200002 (specification of a patient). In addition,“temporal constraints” FDE of F400008: “when information issensitive” in Fig. 2 was represented as a condition of extensionrelationships between F400008 and F100003 in Fig. 5.

4. Discussion

4.1. Collecting EHR system functions

4.1.1. Coverage of EHR systemsThe characteristics of the selected hospitals are shown inTable 1. Although only five hospitals were included in the sur-vey, the vendors of the selected EHR systems share more than70% of the EHR systems market [34]. Therefore, we believe thatthere was little problem with the coverage of EHR systems.

4.1.2. Significance of the surveyOur survey was one of a few surveys on detailed EHR systemfunctions conducted in Japan, and the results of this surveywill provide a useful reference for future EHR research anddevelopment. In the survey, we asked whether each functionwas necessary in each EHR system to determine the need foreach function. However, this was not relevant to the purposeof this paper. In the future, we intend to reflect the necessityof each function in the RFM after analyzing the survey results.

The survey conducted in USA identified three major differ-ences from the functions in Japan: (1) dictation, (2) authoriza-

tion of patients to access their own records and see the samecontent that doctors can access, and (3) alerts based on costmanagement. The first difference arises from differences ofa clinical examination style. The second and third functions

i c a l

696 i n t e r n a t i o n a l j o u r n a l o f m e d

should also become widely used also in Japan near future. Thesurvey conducted in USA identified several functions that werenot found in the survey in Japan.

4.2. Making the RFL

4.2.1. Advantages of the RFLIn the RFL, each function is described using FDEs. One advan-tage of this description is that it enables each EHR systemfunction to be classified using multiple axes. Although func-tions were classified using the verb axis in the present RFL, theaxis can be changed simply by determining another FDEs assorting keys. Fig. 7 shows an excerpt of RFL when “direct object(information and function)” FDE type was specified as a firstsorting key, “temporal constraints” FDE type as a second sort-ing key, and “instrument (non-clinical)” FDE type as a thirdsorting key. Another advantage is that this description canhelp clarify similarities and differences between functions.The similarities and differences can be recognized by deter-mining whether functions have the same FDEs. Specifically,F100085 (display of information), F100205 (save in recordingmedia) and F100006 (print information) are described as fol-lows, respectively: “the system (subject) outputs (verb) infor-mation (direct object) to a screen (instrument)”, “the system(subject) outputs (verb) information (direct object) to recordingmedia (instrument)”, and “the system (subject) outputs (verb)information (direct object) to paper (instrument)”. Comparingeach FDES, people and machines can recognize the differencebetween the functions. As described above, the description ofthe RFL has great advantages.

4.2.2. Granularity of the RFLIn this study, granularity of the RFL was based on the granu-larity level used in the questionnaire. In the questionnaire, weadopted an indefinite granularity level, as is generally used for

Fig. 7 – Portion of the RFL (information axis). The classification axkeys. This figure shows RFL when “direct object (information an“temporal constraints” FDE types as a second sort key, and “inst

i n f o r m a t i c s 7 6 ( 2 0 0 7 ) 688–700

software detailed specifications. As for descriptions of infor-mation and instrument, we adopted a more abstract level thanfor detailed software specifications. It is, however, generallydifficult to measure the granularity in quantitative terms andno such method has been established. Therefore, it is impor-tant to set a granularity level depending on the level used inan application. For an application such as a software specifi-cation generator, it is best to adopt the granularity used in thedescription of the software specifications.

4.3. Modeling the RFM

4.3.1. Relationships between functions and FDEsIn discussing the representation of the relationships betweenfunctions and FDEs in the meta-functional model, the use ofan aggregation relationship was considered. However, newlydefined relationships were selected because we limited theuse of the aggregation relationship to cases in which a “totaland part” relationship is clearly recognizable. Although FDEsare elements used to describe functions and the relationshipsbetween functions and FDEs tend to be seen as aggregationrelationships, some relationships between them are clearlynot aggregation relationships. One example is “object (infor-mation)” FDE. Objects cannot exist inside each function, butcan exist independent of each function. Therefore, the use ofnewly defined relationships is suitable for describing the rela-tionships between a function and FDEs.

4.3.2. Workload of the modeling processThe goal of our modeling was stated clearly. It may be idealto model all the functions in the RFL. Nevertheless, we repre-

sented 12.2% of them. The adequacy of the goal setting is oneof the points to be examined in the future.

Concerning the workload involved in the modeling process,the discussion and determination of the description format

is can be changed simply by determining FDE types as sortd function)” FDE type is specified as a first sort key,rument (non-clinical)” FDE type as a third sort key.

a l i n

rmfegtsbg

4FttvctsaFatri(cFgFbfrstbr

tt1sfil(ftactrpstattfti

i n t e r n a t i o n a l j o u r n a l o f m e d i c

equired a great deal of time. It took about 2 months to deter-ine how to describe the meta-functional model. Once the

ormat was determined, it took at least 3 days to constructach diagram, which consists of 4–11 functions. Since one dia-ram contains an average of six functions, it will take morehan 192 days to model all functions in the RFL based on aimple calculation. In actual fact, this will take even longerecause one function is represented in more than one dia-ram.

.3.3. Advantages of the RFMirst, we must discuss the advantages of the RFM comparedo the RFL. The functional model has some advantages inerms of representation. The functional model is not just aisual representation of the RFL. The list format in the RFLan clearly answer the following questions: (1) what func-ions do EHR systems have?; (2) which FDEs does an EHRystem function contain?; (3) which functions are related ton FDE? (determined by changing the classification axis to anDE type); (4) which functions are similar to (or different from)specific function? (determined by checking whether func-

ions have the same FDEs). In addition, the functional modelepresentation can provide rapid, clear answers to the follow-ng questions; (5) which functions are related to a function?;6) what kinds of FDEs exist in EHR systems? (determined byreating each FDE view); (7) what relationships exist betweenDEs? (determined by creating each FDE view). Fig. 5 shows theenerated FDE views that represent the relationships betweenDEs of the same type. Each FDE view is generated simplyy extracting same FDEs and the relationships between themrom the functional model. In addition, by using hierarchicalelationships of each FDE as an axis, functions can be clas-ified multiaxially. Another advantage of creating the func-ional model is that the discussions that took place whileuilding the functional model were useful for refining the RFLepresentation.

Now, we discuss the advantages of the RFM compared tohe existing EHR functional models. As described in Section 1,he description format of functional requirements in ISO/TC8308, the GEHR, CEN ENV 13606, and OpenEHR does not repre-ent static relationships between functions and classify eachunction using multiple axes. On the other hand, the functionsn the draft for the HL7 EHR-S model are described in naturalanguage text although the model description has two axesfunctions and care settings) and static relationships betweenunctions. Compared to these models, the RFM has the advan-ages of classifying functions using multiple axes and visu-lizing functional structures and functional relationships. Byontrast, EHR-S is better than our model in that it has func-ional profiles, which are selected sets of functions that areequired and implemented for particular settings. Functionalrofiles are employed to help the user understand the propercope of the functions in a specific context. The RFM hashe same concept: EHR system functions should be selectedccording to the situation of the individual healthcare institu-ion. Therefore, functional profiles should be implemented in

he RFM in the near future. Consequently, the new descriptionormat of EHR system functions in the RFM has advantages inerms of classifying and visualizing, although it is far behindn making a functional profile, compared to HL7 EHR-S model.

f o r m a t i c s 7 6 ( 2 0 0 7 ) 688–700 697

Finally, we would like to explain the significance of the RFM.We presented the meta-functional model as a new descrip-tion format for EHR system functions. The RFM can promotenot only standardization of EHR systems by representing func-tions that are required in EHR systems, but also communica-tion between system developers and healthcare providers sothat system engineers can grasp the actual system require-ments of the healthcare provider. This process will be facili-tated by clarifying: (1) the similarities and differences betweenfunctions in the RFL and the functional model, (2) the purposesof functions in the purpose model, and (3) the need for func-tions, which depends on the healthcare settings, in functionalprofiles.

4.3.4. Application of the RFMIn the future, we intend to develop the FuncSpec generator,a semiautomatic tool for generating functional specificationdocuments, as an application of the RFM. The FuncSpec gener-ator includes TouchGraph Link Browser ver1.20 [35], developedby TouchGraph LLC [36]. TouchGraph is an interactive graphvisualization tool that is widely used [37,38]. In Fig. 8(A)–(D)snapshots of the functional model displayed in the Touch-Graph Link Browser. As it is difficult to understand the func-tional structure and relationships on the screen shown in (A)is complicated, users can change the display to (B) through (D)using the TouchGraph Link Browser.

In this figure, “convert XML format” and “export functionalspecification” (indicated by the blue arrows) are componentsthat we must develop. The RFM can be exported in XML meta-data interchange (XMI) [39–41] format, which is the OMG stan-dard for exchanging metadata information via XML. AlthoughXML is used in both XMI and the TouchGraph Link Browser,their formats are different. Therefore, the XMI format mustbe converted into the XML format used in the TouchGraphLink Browser. Next, we intend to create a tool componentfor exporting the functions specified in the browser as func-tional specifications described in natural language text. Thistool automatically exports F200002 to the functional specifica-tion when F600000 is selected to export a functional specifica-tion, because F600000 premises F200002. In addition, this toolmust be able to indicate extended functions by listing them asoptional functions when a function with extended functionsis selected. This tool must also be able to display a messagewhen a function with a condition is selected.

If tools such as the FuncSpec generator are developed,then the creation of functional specifications will becomemuch easier. In addition, the functions in functional speci-fications will be described in a unified format based on theRFM. Furthermore, mistakes and omissions of descriptionswill be reduced considerably. As mentioned previously, the pri-mary reason for functions not to exist, despite the existenceof related staff tasks, was that the relevant function had notbeen discussed. This supports the argument that the develop-ment of a tool that presents functions corresponding to therequirements in staff tasks is important.

4.3.5. Limitations of the RFMConsidering a tool such as the FuncSpec generator, our repre-sentation has the following limitations.

698 i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 6 ( 2 0 0 7 ) 688–700

Fig. 8 – Conceptual diagram of the FuncSpec generator. The FuncSpec generator is a semiautomatic generation tool offunctional specifications. FuncSpec includes TouchGraph Link Browser ver.1.20 developed by TouchGraph LLC. (A)–(D) show

aph

sify functions using multiple axes, and reveal similarities and

snapshots of the functional model displayed in the TouchGrspecification” are components that we must develop.

First, “object (information)” was described at the coarselevel in the functional model. In Fig. 4, “booking informa-tion” is an example indicating that more detailed informationshould be specified in actual situations. To solve this problem,we are considering linking the RFM to existing informationalmodels, such as HL7 RIM.

In addition, the relationship types between functions arelimited in the present RFM. In the meta-functional model,the only “premise”, “extension”, and UML predefined relation-ships were provided as relationships between functions. Thismay be insufficient for useful document generation support. Itis important to provide additional relationships, such as “rec-ommendation” (the case that recommends choosing function“A” if function “B” has already been chosen), “suggestion” (thecase that suggests choosing function “A” if function “B” hasalready been chosen), and “conflict” (the case in which func-tion “A” cannot be chosen if function “B” has already beenchosen).

Finally, the descriptive power of complex constraints mustbe considered. As natural language is used to describe con-straints in our functional model, complicated cases, such asfree combinations of five functions under the condition thatfunction “A” and function “B” are mandatory, but the otherthree functions are optional, can be described easily. In devel-oping more automated applications, these constraints must

be described in a machine processing language, such as objectconstraint language (OCL) [42,43]. Although OCL can be usedto describe complex constraints, it is difficult for RFM users tomaster OCL.

Link Browser. “Convert XML format” and “export functional

4.3.6. Future researchFirst, the purpose model must be developed in the near futureto promote understanding and sharing the purposes in theEHR system. This development is very important because link-ing purposes and functions should reveal conflicting purposesof simultaneous EHR system functions.

As the next step, we intend to make functional profilesbecause the functions required by healthcare institutionsdepend largely on the characteristics of each institution. Theresults of the surveys conducted for this study will be utilizedin this step.

Furthermore, applications must also be developed andevaluated.

5. Conclusion

We proposed the meta-functional model as a new descrip-tion format for EHR system functions. It represents func-tions, FDEs, and the static relationships between them usingUML class diagrams. Although a more detailed descriptionis required to apply the RFM to semiautomatic generationof functional specification documents, our RFM can visual-ize functional structures and functional relationships, clas-

differences between functions. The RFM will not only pro-mote standardization of EHR systems, but also communica-tion between systems developers and healthcare providers inthe EHR system-design process.

i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n

Summary points

What was known before the study

• A common platform for EHR system functions isneeded in order to provide standardized descriptionsand understanding of functions.

• The draft standard of HL7 EHR-S model was releasedpreviously as a standardized model of EHR systemfunctions.

• EHR-S model has two axes (functions and care settings)and functions are listed and described in natural lan-guage text.

What the study has added to the body of knowledge

• We presented the meta-functional model as a newdescription format of EHR system functions to repre-sent functional structures and relationships.

• We presented the description format that EHR systemfunctions are classified by multiple axes based on func-tional descriptive elements (FDEs) types.

• By dividing each function into FDEs, the RFL canclarify similarities and differences between functions.The similarities and differences can be recognizedby determining whether the function has the sameFDEs.

• Compared to the HL7 EHR-S model, the RFM demon-strates advantages in multi-axis classification of func-tions and visualization of functional structures andfunctional relationships.

A

T((tmKMtTUUHthPYai

r

[20] H. Rhodes, D.T. Mon, M. Dougherty, The drive for an EHRstandard picks up speed, J. Ahima 75 (1) (2004) 18–22.

[21] HL7, EHR-S Functional Model and Standard July 2004 DSTUPackage. URL: http://www.hl7.org/ehr/ (accessed September16, 2005).

cknowledgements

his research was supported in part by grant H15-IRYOU-0462003–2004) from the Ministry of Health, Labour and WelfareMHLW) of Japan. Special thanks are extended to the hospi-als that participated in the surveys for providing valuable

aterials and comments. We thank Mr. T. Yanase and Mr. T.umashiro, Mitsubishi Research Institute and Mr. T. Kashino,s. K. Fujimori, and Mr. T. Iseki, UFJ Institute for their assis-

ance in collecting the materials, and Dr. S. Igawa and Dr.. Fukuda (Iseikai Medical Corporation), Dr. Y. Ishibe (Tottriniversity Hospital), Dr. S. Taguchi and Dr. K. Kozuka (Showaniversity Yokohamashi-Hokubu Hospital), Dr. A. Hirai (Aobaospital, Chiba City), and Dr. Y. Miyao (Karuizawa Hospital) for

heir special cooperation as the directors of the collaboratingospitals. We are also grateful to the MHLW project members:rof. M. Kimura, Prof. M. Okada, Prof. Y. Yamashita, Prof. R.amamoto, Prof. K. Kondo, Prof. H. Oyama, Mr. A. Hamada,nd Mr. M. Hirai who supplied countless valuable commentsn our the discussion.

f o r m a t i c s 7 6 ( 2 0 0 7 ) 688–700 699

e f e r e n c e s

[1] J.S. Ash, D.W. Bates, Factors and forces affecting EHR systemadoption: report of a 2004 ACMI discussion, J. Am. Med.Inform. Assoc. 12 (1) (2005) 8–12.

[2] Institute of Medicine, Key Capabilities of an ElectronicHealth Record System: Letter Report, National AcademyPress, Washington, DC, 2003.

[3] Japan Association of Medical Informatics, JAMI ViewpointConcerning the Definition of the Electronic Medical Record,http://plaza.umin.ac.jp/∼jami/publication/denshikarute en.pdf, 2003 (accessed October 18, 2005).

[4] B. Middleton, W.E. Hammond, P.F. Brennan, G.F. Cooper,Accelerating U.S. EHR adoption: how to get there from here.Recommendations based on the 2004 ACMI retreat, J. Am.Med. Inform. Assoc. 12 (1) (2005) 13–19.

[5] B. Blobel, Authorisation and access control for electronichealth record systems, Int. J. Med. Inf. 73 (3) (2004) 251–257.

[6] Ministry of Health, Labour and Welfare, Overview of Surveyof Medical Institutions in 2002. URL: http://wwwdbtk.mhlw.go.jp/toukei/data/160/2002/gaikyou/0004323/g232.html, 2002(accessed September 16, 2005) (in Japanese).

[7] K. Ohe, Functional model of standardized computer-basedpatient record systems and directions, New Med. Jpn. 31 (7)(2004) 73–76 (in Japanese).

[8] M. Takata, Y. Sumita, T. Yanase, T. Kumashiro, K. Ohe,Analysis of the system functions based on investigation ofEHR system operation hospitals, in: Proceedings of the 24thJoint Conference on Medical Informatics, 2004, pp.1140–1141 (in Japanese).

[9] OMG, UML 2.0 Infrastructure. URL: http://www.omg.org/technology/documents/formal/uml.htm, 2005 (accessedOctober 5, 2005).

[10] B. Bauer, J. Odell, UML 2.0 and agents: how to buildagent-based systems with the new UML standard, Eng. Appl.Artif. Intel. 18 (2) (2005) 141–157.

[11] D. Pilone, UML Pocket Reference, O’Reilly Media, Inc.,Sebastopol, CA, 2003.

[12] HL7, Reference Information Model. URL: http://www.hl7.org/(accessed October 9, 2005).

[13] B. Blobel, Advanced and secure architectural EHRapproaches, Int. J Med. Inf. (2005). URL: http://www.harcourt-nternational.com/journals/ijmi/ (accessed October 9, 2005)(e-pub ahead of print).

[14] W.T. Goossen, M.J. Jonker, K.U. Heitmann, I.C. Jongeneel-deHaas, T. de Jong, J.W. van der Slikke, B.L. Kabbes, Electronicpatient records: domain message information modelperinatology, Int. J. Med. Inf. 70 (2–3) (2003) 265–276.

[15] ISO/TS 18308:2004: Health Informatics—Requirements foran Electronic Health Record Architecture, 2004, pp. 1–28.

[16] The Good European Health Record (GEHR). URL: http://www.chime.ucl.ac.uk/work-areas/ehrs/GEHR/index.htm, 2005(accessed January 24, 2006).

[17] I. Schramm, V. Webe, Incremental EHR introductionconsidering the situation in health care and the currentstandards under development, Int. Congress Series 1230(2001) 889–894.

[18] G. Duftschmid, W. Gall, Representation of inter-patientrelations within electronic healthcare record architectures,Med. Inform. Internet 29 (1) (2004) 1–14.

[19] Open EHR, URL: http://www.openehr.org/, 2005 (accessedJanuary 24, 2006).

i c a l

environment, Electr. Notes Theor. Comput. Sci. 102 (2) (2004)

700 i n t e r n a t i o n a l j o u r n a l o f m e d

[22] B. Chandrasekaran, A.K. Goel, Y. Iwasaki, Functionalrepresentation as design rationale, Computer 26 (1) (1993)48–56.

[23] Knowledge Based Systems, Inc. (KBSI), IDEF Family ofMethod for Concurrent Engineering and BusinessRe-engineering Applications, 1992, URL: http://www.idef.com/ (accessed October 5, 2005).

[24] S.H. Kim, K.J. Jang, Designing performance analysis andIDEF0 for enterprise modelling in BPR, Int. J. Prod. Syst. 76(2002) 121–133.

[25] Knowledge Based Systems, Inc. (KBSI), IDEFO MethodReport: Draft Federal Information Standard Publication 183,1993. URL: http://www.idef.com/ (accessed October 5, 2005).

[26] P. Staccini, M. Joubert, J.F. Quaranta, M. Fieschi, Mapping careprocesses within a hospital: from theory to a Web-basedproposal merging enterprise modelling and ISO normativeprinciples, Int. J. Med. Inf. 74 (2–4) (2005) 335–344.

[27] D.M. Reimann, J. Sarkis, Design for automating theinspection of manufacturing parts, Comput.-Integr. Manuf.Syst. 7 (4) (1994) 262–278.

[28] J. Barreiro, J. Labarga, J. Rios, A. Vizan, Functional model forthe development of an inspection integration framework,Int. J. Mach. Tool. Manuf. 43 (15) (2003) 1621–1632.

[29] IDEF0 overview. URL: http://www.idef.com/IDEF0.html, 2005(accessed October 5, 2005).

[30] Y. Kitamura, R. Mizoguchi, Ontology-based description offunctional knowledge and its use in a functional way server,Expert Syst. Appl. 24 (2) (2003) 153–166.

[31] Y. Kitamura, R. Mizoguchi, Ontology-based systemization offunctional knowledge, J. Eng. Des. 15 (4) (2004) 327–351.

[32] Y. Kitamura, M. Kashiwase, M. Fuse, R. Mizoguchi,Deployment of an ontological framework of functionaldesign knowledge, Adv. Eng. Inf. 18 (2004) 115–127.

[33] M. Saeki, Ontology-based software development techniques,ERCIM News 58 (2004) 14.

i n f o r m a t i c s 7 6 ( 2 0 0 7 ) 688–700

[34] The list of the adoption status of electronic medical recordsystem (hospitals), New Med. Jpn. 30 (7) (2003) 93–107 (inJapanese).

[35] SourceForge.net Project: TouchGraph. URL: http://www.sourceforge.net/projects/touchgraph/, 2001 (accessedOctober 10, 2005).

[36] TouchGraph LLC. URL: http://www.touchgraph.com/, 2001(accessed October 10, 2005).

[37] N. Shadbolt, P. Lewis, S. Dasmahapatra, D. Dupplaw, B. Hu, H.Lewis, MIAKT: combining grid and Web services forcollaborative medical decision making, in: Proceedings ofAHM2004 UK eScience All Hands Meeting, 2004, pp. 784–791.

[38] H. Alani, TGVizTab: an ontology visualisation extension forProtege, in: Proceedings of VIKE ’03, Second InternationalConference on K-CAP 03, 2003.

[39] OMG, XML Metadata Interchange (XMI) Specification. URL:http://www.omg.org/docs/formal/05-05-01.pdf (accessedOctober 10, 2005).

[40] A. Cavalli, S. Maag, S. Papagiannaki, G. Verigakis, From UMLmodels to automatic generated tests for the dotLRNe-learning platform, Electr. Notes Theor. Comput. Sci. 116(19) (2005) 133–144.

[41] T. Knape, L. Hederman, V.P. Wade, M. Gargan, C. Harris, Y.A.Rahman, UML approach to process modelling of clinicalpractice guidelines for enactment, Stud. Health Technol.Inform. 95 (2003) 635–640.

[42] D. Chiorean, M. Pasca, A. Carcu, C. Botiza, S. Moldovan,Ensuring UML models consistency using the OCL

99–110.[43] M. Siikarla, J. Peltonen, P. Selonen, Combining OCL and

programming languages for UML model processing, Electr.Notes Theor. Comput. Sci. 102 (2) (2004) 175–194.