Using organizational modeling to evaluate health care IS/IT projects

Using Organizational Modeling to Evaluate Health Care IS/IT Projects

André Vasconcelos, Ricardo Mendes, José Tribolet CEO - Centro de Engenharia Organizacional, INESC and Department of

Computer Engineering, Instituto Superior Técnico, Technical University of Lisbon {Andre.Vasconcelos, Ricardo,Mendes, Jose.Tribolet}@ceo.inesc.pt

Abstract This paper presents a research project that aims at creating

a methodology for evaluating IS/IT Projects in the Portuguese Health Care System. This project is being jointly developed by the Center for Organizational Engineering and a task force from Saúde XXI, the Portuguese Health Operational Program. In order to create a framework on which to base project evaluation, the project team developed a model of the Portuguese Health System, using the CEO Framework. The CEO Framework is an UML-based organizational modeling framework that uses business process and information systems modeling techniques to represent, monitor and simulate organizational behavior. The model created reflects the reality of the Portuguese Health Care System, including the entities involved, the inter and intra-organizational processes that are executed, the current Information Systems Architecture and the in force Information Systems Strategy. Based on the created Organizational Model, the project team created a tool that facilitates the evaluation of IS/IT projects, by measuring (1) the support to the current processes; (2) the conformance to the IS Architecture and Strategy; (3) the relation with other past or current projects. This paper describes the organizational modeling process that was executed, the developed evaluation methodologies and tools, and the preliminary results regarding ongoing project evaluation.

Keywords: Organizational Modeling, Information Systems Architecture, UML, Health Information Systems, Project Evaluation, CEO framework.

1. Introduction This paper presents a project that proves the usefulness of

Organizational Engineering at the service of the Portuguese Health Care System (PHCS). By using Organizational Modeling and Analysis techniques, the researchers developed a framework that provides a basis for normalizing Processes and Information System Architectures in Portuguese Health Care System Institutions.

The main motivation behind this project is the creation of a methodology that would allow the evaluation of IS/IT projects in the PHCS with regard to a commonly defined Strategy and Architecture for Processes, Entities and Information Systems in the PHCS. Such a methodology is fundamental for effectively

managing the application of existing funds to projects proposed by PHCS institutions.

In order to tackle this problem, Saúde XXI and the Center for Organizational Engineering (CEO) decided to use Organizational Engineering techniques like Business Modeling and Multi-Dimensional Analysis Techniques, based on an analysis framework developed by the CEO – the CEO Framework (FCEO). This framework considers several Organizational entities, like Goals, Processes, Resources, Systems and Roles to support the description and analysis of Business and IS/IT related scenarios.

Based on the FCEO, the project team designed a project that would have as output a methodology for evaluating IS/IT Projects in the PHCS, in light of a defined Strategy for the PHCS, common Architectures for Business Processes and Information Systems. In order to create this methodology, the project team had to carry out very complex tasks like the analysis and modeling of the PHCS with regard to Informational Entities involved, currently executed Business Processes and existing Information Systems; the creation of a common Information Systems Architecture; and the definition of evaluation criteria for proposed IS/IT projects.

The next section of this paper describes the problem that originated the need for this project. Section 3 describes CEO Framework, used as a modeling and analysis tool for the PHCS. Section 4 presents the project steps and the methodology created by the project team. Section 5 presents an example of the application of the created methodology to a IS/IT project proposed by a PHCS institution. Section 6 presents a discussion regarding the usefulness and major contributions of this project. Finally, section 7 draws some final conclusions and present future work to be done in this line.

2. Problem Statement Saúde XXI is an institution created to manage the application

of funds in the PHCS. These funds can be used to finance projects in a wide range of areas that include equipment acquisition, building construction, education, information systems, among others. The responsibility posed upon this institution is thus very heavy, in the sense that it has to evaluate and choose the projects that will be financed. Although in several areas there are public documents that clearly state an investment strategy and thus guide institutions in the conception of their own projects, regarding Information Systems, the scenario is very different. Up until recently, the acquisition of an Information System was regarded by most entities in the PHCS as necessary but secondary investment, and the process of

choosing and implementing an Information System was mostly carried out by the Technical Departments. Information Systems acquisition was not regarded at a strategic level and projects created and proposed for financing reflected that reality.

Regarding Information Systems, there is a very important institution in the PHCS: IGIF. This institution plays a very important role in managing financial issues in the PHCS and has also an important role in developing and deploying Information Systems into the PHCS institutions. Being an institution mainly focused on the financial aspects of the PHCS, the main concerns of IGIF regarding Information Systems are to create a normalized way of managing administrative processes inside and between institutions. The other strategic issues regarding the introduction of Information Systems in the institutions are entirely left at will for each institution and there is no public and common definition of an Information Systems Strategy in the PHCS.

Given this scenario, how can a proposed Information Systems project be evaluated for more than just financial aspects? The answer is: it can’t.

The project described in this paper was thus created with a simple goal: to create a methodology for evaluating the IS/IT Projects proposed by the PHCS institutions. Obviously, this is more than a technological problem, since the benefits of any given Information System is measured by its effective support to the Organization. Having this goal on sight, Saúde XXI hired the CEO to lead the process of creating a methodology that would help to overcome these shortcomings.

The first step of the project was obviously to clearly define the problem being evaluated and thus the project team analyzed all the available information regarding Information Systems in the PHCS. Some conclusions could immediately be drawn to clarify the problem: • There was no Strategy defined regarding Information Systems in the PHCS; • There wasn’t a commonly shared vision over the state of affairs regarding existing Information Systems and the Processes and Entities they supported; • There was no common language used between institutions to describe Information Systems characteristics and functionalities, Informational Entities, Processes and Goals; • Most Information Systems Projects were regarded as mere Financial Investment and had no description of the Information System or the Processes it aimed to support; • The information provided by candidates for getting financing for their proposed projects was poorly organized and couldn’t allow a normalized analysis of more that just the financial aspects of the project.

The path for achieving the proposed goal was obviously complicated and demanded a wide project that would embrace PHCS issues, not only at a Technological level, but also at the Business Processes and Entities level.

3. The CEO Framework The CEO Framework (Figure 1) aims at providing a formal

way of describing business goals, processes, resources and information systems and the dependencies between them. It is composed of three separate levels, each of which provides adequate forms of representing the notions about the layer being described [1].

Figure 1. Goal / Process / System framework

In the first level, the aim is at describing the current set of goals that drive business. These goals must be achieved through one or more business process. The business processes are described at the second level and must exist in order to satisfy one or more goals. Besides serving goals, business processes interact with resources in order to do work and may be supported by information systems. The information systems layer aims at modeling the components of the system that support business. Although the framework presents a clear separation of concerns (business and system), the dependencies and relationships between the different layers are easily recognized [2],[1].

The modeling language used to implement the CEO Framework was UML. As UML was initially designed to describe aspects of a software system, it had to be extended to more clearly identify and visualize the important concepts of business, namely by use of stereotypes. A stereotype is an extension of the vocabulary of the UML, which allows you to create new building blocks specific to your problem from existing ones. Stereotypes may have their own icons [3].

Due to size restrictions, there will not be a full presentation of the CEO Framework (for further reading, refer to [1]). Figure 2 presents the UML metamodel defined for the CEO Framework.

«goal»

G oa l

R esource

«resource»«process»P rocess

«b lock»

B locksupports

con tro ls ,executesproduces,

consum es,uses, refines

«contradic tory»

achieves

*

**

*

sends,receives

Figure 2 - UML Metamodel of the CEO Framework

The CEO Framework is in constant evolution by the CEO, as it is being the subject of study from several MSc and PhD thesis, but is also being used to tackle real-life problems in Portuguese Private and Public Organizations. The wide range of application of Organizational Modeling techniques originated the creation of several paths in the evolution of the FCEO, with different concerns such as role modeling, business process execution or change management. Regarding the project being described in this paper, there is one particular field of study that contributed largely towards solving the existing problem: Information Systems Architecture.

3.1. Information System Architecture Information System Architecture (ISA) is a part of a vaster

field of architectures and models relevant for the organization. Considering the architecture level, one can distinguish the following architectures: Enterprise Architecture, Information System Architecture (ISA) and Software Architecture (SWA).

Software Architecture’s (SWA) main study area is on how programs or application components are internally built [4]. At this level it is import to consider the objects and classes needed for implementing the software. SWA is a quite stable and mature field. Enterprise Architecture is a group of models defined for getting a coherent and comprehensible picture of the enterprise [5]. The models define different “perspectives or viewpoints from which the company is considered, focusing on some aspects and ignoring others in order to reduce complexity” [6]. Thus, a model of the company can contain several activity, processes, organization, information and behavior diagrams of the company. Enterprise architecture is considered a vaster concept than ISA, which includes business strategies and processes, besides Information System (IS) models that support them. Usually, at enterprise architecture level, IS are consider “simple” resources used in business (as people, equipment and material, etc.) [7] and [8]. Finally, Information System Architecture (ISA) addresses the representation of the IS components structure, its relationships, principles and directives [9], with the main propose of supporting business [10].

ISA usually distinguish three aspects, defining three “sub architectures” [11]: • Informational Architecture, or Data Architecture. This level represents main data types that support business. • Application Architecture. Application architecture defines applications needed for data management and business support. • Technological Architecture. This architecture represents the main technologies used in application implementation and the infrastructures that provide an environment for IS deployment.

Each of these architectural levels present different concerns. CEO framework, at system level, is supported on three major blocks: Information entity, IS Block and IT Block [12].

p r o c e s s

is s u p p o r te d

h a s >

is im p le m e n te d

is u s e d >

< C R U D

re la te s

o p e r a t io n

p a r t o f

re la te s

e x is ts

« p ro c e s s »

« IS B lo c k »

IS B lo c k

« In fo rm a t io n E n ti ty »

In fo rm a t io nE n t i ty

« IT B lo c k »

IT B lo c k

IS S e r v ic e« IS S e r v ic e »

IT S e r v ic e« IT S e rv ic e »

« o p e ra t io n »

B u s in e s sS e r v ic e

« B u s in e s s S e rv ic e »

Figure 3. System level CEO framework metamodel

Identifying and defining the major data types that support business development is Informational Architecture major propose [11], [13] – represented by the Information Entity Block.

The second architecture level, defined by DeBoever, is the application (or system) architecture. This architecture defines the main applications needed for data management and business support. This architecture should not be a definition of the software used to implement systems. The functional definition of the applications that should ensure access to data in acceptable time, format and cost is this architecture main focus [11]. Application architecture defines the major functional components of the architecture – CEO framework uses the IS Block in this architecture. Technological architecture defines the major technologies that provide an environment for application building and deployment. At this level, the major technological concepts relevant for the IS are identified – as network, communication, distributed computation, etc. [11]. The IT Block is used to model the concepts at this level.

4. The Project Having as major goal the creation of a methodology for

evaluating projects in the PHCS, the project mounted by the CEO and Saúde XXI encompassed several complex tasks, organized into the following groups: • Create a Model, at Business and ISA levels of the PHCS • Create a Knowledge Base for existing Information Systems Projects • Define the Procedures for evaluating projects basing on the created Model, Architecture and Knowledge Base • Define the set of information that each project must provide in order to allow proper evaluation

The next sections will make a brief presentation of the goals and tasks executed in each of these groups.

4.1. Creating a Reference Model for the PHCS In order to set a common assessment of the PHCS we

established an organizational reference model. This organizational model will provide Saúde XXI and all the project proponents a common view of the systems and business of the PHCS.

The Portuguese Health Care Organizational Reference Model, or reference model (for short), was developed using the CEO Framework and concepts (described in section 3) and is defined around three major models: the informational entity, the business process and the application and IT models. Next we present some excerpts of the reference model. 4.1.1. Informational entity model

At the informational entity level the things, places, or concepts relevant in the health care context are described in a hierarchical way. Each entity is also described in detail – in Figure 4 Patient Informational Entity is described.

E n t i t y N a m e P a t ie n t I n fo rm a t i o n a l E n t i t y n . º 1 A l te r n a te N a m e H e a lth c a r e c u s to m e r I d e n t i f i e r B e n e f ic ia r y n u m b e r , H e a l th c a r e s y s te m T y p e P e r s o n D e s c r ip t io n A n y C i t iz e n h a v in g th e c o n s t i tu tio n a l r ig h ts to u s e th e

P u b lic P o r tu g u e s e H e a l th C a r e S y s te m R e la t io n s g e t s h e a l th c a r e t r e a tm e n ts ( 8 ) in a H e a l th C a r e U n i t ( 7 ) is c o n d u c te d b y m a n a g e m e n t d o c to r ( 2 )

b e n e f i t s f r o m o n e o r s e v e r a l p a y m e n t e n t i t ie s ( 5 ) h a s m e d ic a l d r u g a n d e x a m s p r e s c r ip t io n s ( 1 0 )

U s e s d r u g s a n d C o m p le m e n ta r y M e a n s o f D ia g n o s t ic in a tr e a tm e n t ( 1 1 ) I s t r e a te d b y h e a l th c a r e p r o f e s s io n a l s ( 1 2 ) in o r d e r to d ia g n o s t i c o r t r e a t d i s e a s e s ( 9 ) in te r a c t s w ith th e P u b lic H e a l th C a r e M a n a g e m e n t O r g a n iz a t io n ( 3 ) is c u s to m e r o f a H e a l th C a r e M a n a g e m e n t O r g a n iz a t io n ( 6 )

Figure 4. Patient Informational Entity

Figure 5 to Figure 7 present the health care unit informational entity description and hierarchical relations – for example a hospital health care unit is a specialization of a general health care unit.

E n t i t y N a m e H e a lt h C a re U n i t I n fo r m a t i o n a l E n t i t y n .º 7 A l t e r n a t e N a m e - - S u b E n t i t i e s P r im a r y H e a l th C a r e U n i t ,; H o s p i ta l h e a l th C a r e U n i t ;

C o n t in u e d H e a lth C a r e U n i t ; M o b il e H e a l th C a r e U n it ; O th e r H e a l th C a r e U n i t

T y p e T h in g D e s c r ip t io n O r g a n i z a t io n u n i t r e s p o n s i b le fo r p r o v id in g h e a l t h c a r e to

th e p a t i e n ts

Figure 5. Health Care Unit Informational Entity

Health care units responsible for providing primary health cares are described in Figure 6. Figure 7 presents the Hospital health care unit.

E n t i ty N a m e P r im a r y H e a lt h C a r e U n it I n fo rm a t i o n a l E n t i ty n . º 7 .1 A lte r n a te N a m e H e a lth C a re C e n te r , F a m il ia r H e a l th C a r e P la n n in g C e n te r T y p e T h in g D e s c r ip t i o n O r g a n iz a t io n u n i t r e s p o n s ib le f o r p r o v id in g p r im a r y h e a l th c a re

t o th e p a t i e n ts R e la t io n s p r o v id e s h e a l th c a r e ( 8 ) t o p a t ie n ts (1 ) i s m a n a g e d b y a P r im a ry H e a l th c a re m a n a g e m e n t o rg a n iz a t io n

( 6 .1 ) h e a l th c a r e p ro fe s s io n a l s w o r k i n p r im a ry h e a l th c a r e u n i ts

Figure 6. Primary health care unit

E n t it y N a m e H o s p it a l H e a lt h C a re U n it I n fo rm a tio n a l E n t ity n . º 7 .2 A lte r n a te N a m e H o s p ita l U n it T y p e T h in g D e s c r ip t io n O rg a n iz a tio n u n it re s p o n s ib le f o r p ro v id in g s p e c ia l iz e d h e a l th

c a re to th e p a t ie n ts R e la t io n s p ro v id e s h e a lth c a re (8 ) to p a tie n ts (1 ) is m a n a g e d b y a h o s p ita l h e a lth c a re m a n a g e m e n t

o rg a n iz a t io n (6 .2 ) h e a l th c a re p ro fe s s io n a ls w o rk in h o s p ita l h e a lth c a re u n its

Figure 7. Hospital health care unit

All informational entities are also characterized by theirs attributes – for instance, the patient has a name, number, passport number, insurance company, etc. However, the description of this information is not very important for the research described in this paper.

The relations between some of the informational entities are described in Figure 8.

« r e s o u r c e »H e a l t h C a r e

M a n a g e m e n tO r g a n i z a t i o n :

O r g a n i z a t i o n

« r e s o u r c e »

H e a l t h C a r e U n i t :O r g a n i z a t i o n


P a t i e n t : P e r s o n


M a n a g e m e n tp h y s i c i a n : P e r s o n


H e a l t h C a r e : T h i n g

p r o v i d e s

m a n a g e s m a n a g e s

p r o v i d e s h e a l t h c a r e

is c u s t o me r

r e p o r t s

Figure 8. Relations between informational entities

The global informational entity model consists of 15 top-level entities and a total of 80 top/low-level informational entities. 4.1.2. Business Process model

Business process modeling was a quite time-consuming task, considering that it required an intensive and extensive data collection with the cooperation of the major actors in the health care process.

Further, the business process oriented view of the Portuguese health care industry was not an easy task because there are several functional areas with partial (and sometimes inaccurate) view of the global business process.

In order to address this complexity the project team opted to define four different views on the business processes: • The health care view that addresses the activities developed in health care units. • The global clinical view that is concern about inter-organizational activities, as medical procedures definition, public health care actions, among others. • The administrative view, concern on the financial and administrative activities between organizations of the PHCS. • The Patient view that presents all the possible activities where a citizen may interact with the PHCS, during his or her life.

Next we opt to present some of the health care view business processes.

In order to analyze health care business in a standard and simple way the project team decided to define several abstraction levels. Thus, the major challenge was to create a high-level health care business process that encapsulate all medical, nurses, pharmaceutical, and patient relations in hospital, primary health care, or other health care units. This high-level business process is described in Figure 9.

«resource»

Patient

«Clinical process»

ExecuteHealth Care

«resource»

Patient

«process»

ForwardPatient

«process»

ReceivePatient

Figure 9. Health care business process

As previous model describes all health care processes may be analyzed into three major sub-processes: the patient reception, the health care execution and the patient forwarding. Notice that the project team opted to define two business process types: the clinical business processes (in green dashed line) and the administrative business processes (in blue – see Figure 13), in order to make a clear distinction between health care industry core activities and support activities, respectively.

The patient reception business process may be further specialized in order to represent a real business process (not an abstract one) – see Figure 10.

« p ro c e s s »

R e c e iv e P a t ie n t

« p r o c e s s »

R e c e iv e P a t ie n tin U r g e n c y

« p ro c e s s »

R e c e iv e P a t ie n tin M e d ic a l

A p p o in tm e n t

« p r o c e s s »

R e c e iv eT r a n s fe r r e d

P a t ie n t

« p ro c e s s »

R e c e iv e In t e r n e dP a t ie n t

Figure 10. Receive patient business process hierarchical decomposition

The health care execution business process specialization is described in Figure 11.

« C l i n i c a l p r o c e s s »

E x e c u t e M e d i c a lA p p o i n t m e n tH e a l t h C a r e


E x e c u t e P a t i e n tH o s p i t a l i z a t i o n


E x e c u t eC o m p l e m e n t a r y

D i a g n o s t i c E x a m

« C l in i c a l p r o c e s s »

E x e c u t e S u r g e r y


E x e c u t e H e a l t hC a r e

Figure 11. Execute health care business process specialization

Figure 12 presents patient forwarding business process specialization.

« p r o c e s s »

F o r w a r d P a t i e n t

« p r o c e s s »

P a t i e n t R e l i e f

« p r o c e s s »

T r a n s f e r P a t i e n t

« p r o c e s s »

M a i n t a i n P a t i e n tC o n d i t i o n

« p r o c e s s »

T r a n s f e r P a t i e n tt o E x t e r n a l

O r g a n i z a t i o n

« p r o c e s s »

T r a n s f e r P a t i e n tI n t e r n a l l y

Figure 12. Patient forwarding business process specialization

For example the dynamical view of the patient reception in an urgency hospital unit is described in Figure 13.

« A d m i n is t r a t i v e p r o c e s s »

P a t ie n t A r r iv e


H e a l t hS y n d r o m e


P a t i e n t

« C li n ic a l p r o c e s s »

C l in i c a l F i l t e r i n g


P a t i e n t

Figure 13. Patient reception in urgency (dynamical view)

Several other business process models were defined and incorporated on the reference model in order to ensure that all the health care actors share a common view on the PHCS. 4.1.3. Application and IT model

The application and technological reference model describes PHCS major systems and technological options. It was defined a template to describe each existing system at application and IT level. Using this template the 25 major systems implemented in the PHCS were described. Next we present a description of 3 of these systems. The hospital drug management system is described in Figure 14.

S y s t e m N a m e H D S S y s t e m n . º 1 3 D e t a i l e d N a m e H o s p i t a l D r u g S y s t e m P r o p o s e S u p p o r t s d r u g p r e p a r a t i o n f o r t h e p a t i e n t s . D e s c r i p t i o n H D S i s a s y s t e m t h a t s u p p o r t s d r u g p r e p a r a t i o n i n t h e

h o s p i t a l p h a r m a c y a n d i t s d e l i v e r y t o t h e n u r s e s . B u s i n e s s P r o c e s s e s S u p p o r t e d

D r u g A d m i n i s t r a t i o n P r o c e s s , n a m e l y d r u g p r e p a r a t i o n i n t h e h o s p i t a l p h a r m a c y

I n f o r m a t i o n a l E n t i t i e s

P a t i e n t ( 1 ) b e i n g t r e a t e d P h y s i c i a n ( 1 2 . 1 ) t h a t p r e s c r i b e s t h e d r u g ( 1 1 . 1 ) p r e p a r e d b y p h a r m a c e u t i c a l s ( 1 2 . 3 ) a n d a d m i n i s t r a t e d b y n u r s e s ( 1 2 . 2 ) t o t h e p a t i e n t .

I m p l e m e n t e d O p e r a t i o n s

P r e p a r a t i o n p l a n f o r d r u g m a n u f a c t u r i n g i n t h e p h a r m a c y . P h a r m a c y m a n a g e m e n t 2 4 h o u r s n u r s e d r u g / p a t i e n t a d m i n i s t r a t i o n m a p .

D e p e n d e n c i e s S O N H O ( 1 7 ) : P a t i e n t a d m i n i s t r a t i v e i n f o r m a t i o n , b y O D B C a c c e s s ; G E R H A ( 4 ) : H e a l t h c a r e p r o f e s s i o n a l d a t a , b y O D B C a c c e s s ;

O S U N I X ( s e r v e r ) , M s W i n d o w s 9 5 ( c l i e n t ) D B O R A C L E

T I P l a t f o rm D e v e l o p .

P l a t f o r m D e s i g n e r D e v e l o p e r 2 0 0 0 ( O R A C L E )

N e t w o r k I n f r a s t r u c t u r e

P o r t u g u e s e H e a l t h C a r e n e t w o r k i n f r a s t r u c t u r e

C l i e n t P e r s o n a l C o m p u t e r ( m i n i m u m : 4 8 6 )

T e c h n o l o g i c S u p p o r t

E q u i p m e n t S e r v e r U n i s y s , S u n

F i r s t I n s t a l l a t i o n - - * C u r r e n t V e r s i o n - - * N . º I n s t a l l a t i o n s - - * U s e r s - - * U s e r s o c c u p a t i o n P h a r m a c e u t i c s , N u r s e s M a i n t e n a n c e C o s t s - - * R e s p o n s i b l e O r g . - - *

O t h e r I n f o r m a t i o n

D e v e l o p m e n t O r g . - - * S y s t e m b e n e f i c t s

I m p r o v e s d r u g m a n a g e m e n t i n t h e h o s p i t a l a n d p r o v i d e s t h e m e a n s f o r b e t t e r p h a r m a c y m a n a g e m e n t ; I m p r o v e s p h a r m a c e u t i c a l / n u r s e c o m m u n i c a t i o n ; E n s u r e s t h a t t h e r i g h t d r u g s a r e a d m i n i s t r a t e d t o t h e

r i g h t p a t i e n t o n t h e r i g h t t i m e ; A l l o w s a q u i c k e r a c c e s s t o d r u g d a t a b a s e a n d d r u g

p r e p a r a t i o n .

Figure 14. Hospital Drug system (HDS)*

* Some facts were removed for confidentiality reasons.

S y s t e m N a m e G E R H A S y s t em n . º 4 D e t a i le d N a m e H u m a n R e s o u rc e a n d D e c i s io n S u p p o r t

S y s t e m P r o p o s e S u p p o r ts h u m a n r e s o u rc e p la n n in g , r e c ru i tm e n t ,

s e le c t io n a n d e v a lu a t io n D e s c r ip t io n S u p p o r ts h u m a n r e s o u rc e a c t iv i t ie s d e v e lo p e d in th e

h o s p i ta l a n d o th e r h e a l th c a re u n i ts . I t i s in te g ra te d w i th h e a d q u a r te r s h u m a n re s o u rc e d e p a r tm e n t

B u s in e s s P r o c e s s e s S u p p o r t e d

H u m a n R e s o u r c e b u s in e s s p r o c e s s

I n f o r m a t io n a l E n t i t ie s

H e a l th c a re p ro fe s io n a l (1 2 ) a n d a d m in is t r a t iv e /m a n a g e m e n t p r o fe s s io n a l ( 1 3 ) – C R U D H e a l th c a re m a n a g e m e n t o r g a n iz a t io n (6 ) – C R U D

I m p le m e n t e d O p e r a t io n s

e m p lo y e e c h a ra c te r iz a t io n e m p lo y e e a b s e n t r e g is t r a t io n e m p lo y e e s a la r y m a n a g e m e n t m a n a g e m e n t o f P o r tu g u e s e h e a l th c a re h u m a n

r e s o u rc e d a ta b a s e D e p e n d e n c ie s

O S U N I X ( s e r v e r ) , M s W in d o w s 9 5 ( c l ie n t ) D B O R A C L E

T I P l a t f o rm D e v e lo p .

P la t fo r m - -

N e tw o r k I n fr a s tr u c tu r e

P o r tu g u e s e H e a l th C a r e n e tw o r k in f r a s t r u c tu r e

C lie n t P e r s o n a l C o m p u te r (m in im u m : 4 8 6 )

T e c h n o lo g ic S u p p o r t

E q u ip m e n t S e r v e r U n is y s , S u n

F ir s t I n s t a l la t io n - - * C u r r e n t V e r s io n - - * N . º I n s t a ll a t io n s O v e r 1 2 h o s p i t a ls U s e r s - - * U s e r s o c c u p a t io n A d m in is t r a t iv e p e r s o n n e l M a in t e n a n c e C o s t s - - * R e s p o n s ib le O r g . - - *

O t h e r I n f o r m a t io n

D e v e l o p m e n t O r g . - - * S y s t e m b e n e f i c t s R e a l t im e a c c e s s to e m p lo y e e d a ta .

E m p lo y e e c o s t m a n a g e m e n t c o n s id e r in g e m p lo y e e h e a l th c a r e u n i t P ro v id e s a c c e s s to a l l o th e r s y s te m s th r o u g h a

w e l l d e f in e d in te r f a c e

Figure 15. Human Resource System (GERHA) *

The Human Resource management system is described in Figure 15 and the system responsible for patient data management is described in Figure 16.

S y s t e m N a m e S O N H O S y s t e m n . º 1 7 D e t a i l e d N a m e H o s p i t a l P a t i e n t M a n a g e m e n t S y s t e m P r o p o s e P r o v id e to th e h o s p i ta l a n I n f o r m a t io n S y s te m th a t

a l lo w s p a t ie n t m a n a g e m e n t a n d i t s in t e g r a t io n w i th o th e r o r g a n iz a t io n s .

D e s c r ip t io n S O N H O is a h o s p it a l I S b a s e d o n a p a t i e n t id e n t if i c a t io n m o d u le . C u r r e n t ly i t s u p p o r t s m o s t ly h o s p it a l a d m in is t r a t iv e b u s in e s s p r o c e s s e s .

B u s in e s s P r o c e s s e s S u p p o r t e d

P a t ie n t r e c e p t io n ( in th e in d iv id u a l b u s in e s s p r o c e s s ) P a t ie n t f o r w a r d in g P r o c e s s ( in th e in d iv id u a l b u s in e s s p r o c e s s ) A d m in is t r a t iv e t a s k s in th e “ e x e c u te h e a l th c a r e p r o c e s s ”

I n f o r m a t io n a l E n t i t i e s

P a t ie n t ( 1 ) – C R U D H o s p i ta l h e a l th c a r e u n i t ( 7 .2 ) – R H o s p i ta l ( 6 .3 ) ( h e a l t h c a r e m a n a g e m e n t o r g a n iz a t i o n ) – R H e a l th c a r e ( 8 ) – C R U D D is e a s e ( 9 ) – C R U D

I m p le m e n t e d O p e r a t io n s

1 . P a t ie n t I d e n t i f i c a t io n M o d u le 2 . H o s p i ta l U r g e n c ie s M o d u le

3 . I n te r n in g M o d u le 4 . S p e c ia l i z e d m e d i c a l a p p o in tm e n t a p p o in tm e n t

D e p e n d e n c ie s O S U N I X ( s e r v e r ) , M s W in d o w s 9 5 ( c l i e n t ) D B O R A C L E

T I P la t f o rm D e v e lo p .

P la t f o r m - -

N e tw o r k I n f r a s t r u c tu r e

P o r tu g u e s e H e a l th C a r e n e tw o r k in f r a s t r u c tu r e

C l ie n t P e r s o n a l C o m p u te r ( m in i m u m : 4 8 6 )

T e c h n o lo g i c S u p p o r t

E q u ip m e n t S e r v e r U n is y s , S u n

F ir s t I n s t a l la t io n - - * C u r r e n t V e r s io n - - * N . º I n s t a l l a t io n s O v e r 5 0 h o s p i ta l s U s e r s - - * U s e r s o c c u p a t io n A d m in is t r a t iv e a n d m a n a g e m e n t

p e r s o n n e l M a in t e n a n c e C o s t s - - * R e s p o n s ib le O r g . - - *

O t h e r I n f o r m a t io n

D e v e lo p m e n t O r g . - - * S y s t e m b e n e f i c t s C e n t r a l i z e d p a t ie n t m a n a g e m e n t

P a t ie n t in te g r a te d v ie w P r o v id e s in te r f a c e s f o r p a t ie n t d a ta f o r o th e r

s y s te m s

Figure 16. Hospital Patient Management System (SONHO) *

The systems described previously, have relations and dependencies. Figure 17 presents the Information System

Architecture (ISA) of the four systems previous described, at application level.

As presented in Figure 16, SONHO system (responsible for patient management) and the GERHA system (responsible for HR management) provide services to other systems, ensuring that any system can access to patient and health care professional data, respectively.

« I S S e r v i c e »P a t i e n t D a t a

I n t e r f a c e

« I S B l o c k »

G E R H A« I S B l o c k »

S O N H O

« I S B l o c k »

H D S

« I S B l o c k »

N P C S / N D L

« I S S e r v i c e »

H R I n t e r f a c e

Figure 17. Application architecture containing the systems described

4.2. Creating a Knowledge Base for IS/IT Projects in the PHCS

The introduction of an Information System into an Organization demands not only a suitable analysis of the organizations needs and a adequate architecture for the system, but also a sound project and a competent project team. Besides that, in having in mind the need for a rational management model, projects should be well estimated in terms of their costs, in financial and organizational aspects. All of these issues are not directly related to the proposed information system, but rather to the project by which it is conceived and deployed in the organization. For this reason, the project team decided to create a Knowledge Base capable of keeping all available information about past and current projects, organized to effectively support the analysis of current proposals and guide organizations through the wilds of implementing their projects.

The creation of this Knowledge Base is, in itself, a very complex task, that enters domains such as Data-Warehousing, Data-Minning and Knowledge Representation. By this reason, only the purpose and use of this Knowledge Base will be presented in this paper and the technical issues regarding its creation will not be presented (they will be subject of presentation in a separate, focused paper).

The use of the defined Knowledge Base can be readily understood by observation of the set of indicators presented in the following section. As an example, the Knowledge Base contains information about all the current IS/IT suppliers in the PHCS. Correlated with intermediate and final evaluations on the financed projects, in which the project’s success is measured, this information is very useful, since it gives the evaluator information about the levels of success achieved by the suppliers in the PHCS.

4.3. Defining the method of evaluation Basing proponent projects in a common reference model and

using a common set of concepts and notation (CEO Framework, when applicable) for its description we expect to make it possible to set a collection of indicators for project evaluation. Some of the indicators defined are: Business Processes indicators, namely

Efficiency in existing Business Process Gain for new Business Processes

Suitability for the organization ISA:

Functional Overlapping indicator, defined as:

∑∑ FnewFold , where: Fnew – function implemented by the propose project Fold – function implemented by the propose project that already exist in other systems in the organization

Integration indicator defined as: CostsojectCostnIntegratio Pr

Technology change indicator defined as: ∑∑ ITNewIT , where:

NewIT – new technology introduced by the project that is not used in other existing IS of the organization IT – technology proposed by the project

Informational Entity Overlapping indicator, defined as:

CUDCUD IEnewIEexist ∑∑ , where

IEexistCUD – informational entity Created, Updated or Deleted by the systems proposed but already exist in other organization systems IEnew –informational entity Created, Updated or Deleted by the systems proposed.

Informational entity model compatibility indicator, defined as:

∑∑ ≠ newModelf IEIE .Re, where

ModelfIE .Re≠ – Informational entity, which attributes differed from

Information entity reference model. IEnew – informational entity Created, Updated or Deleted by the systems proposed.

Suitability for the global ISA: System overlapping indicator, defined as:

∑∑ BPIS BP# , where #ISBP – number of existing systems (in PHCS) that support a business process BP BP – business process supported by the proposed systems

Interface disregarding indicator, defined as: ∑∑ ≠ InterfaceInterface , where

Interface≠ - interface used or provided by the systems proposed that disregards the protocol or technology defined by the reference model. Interface - interface used or provided by the systems proposed.

Business Process disregarding indicator, defined as:

∑∑ ≠BPBP , where

BP≠ - business process supported by the systems that disregards the one defined by the reference model. BP – business process supported by the systems proposed.

IT Supplier indicators: IT supplier experience in PHCS, defined as:

∑∑ PHCSS PP , where PS – IT project in PHCS that the IT Supplier has been involved PPHCS – any IT project in the PHCS

Financial indicators,: Project expected ROI (Return On Investment) Business process cost indicator:

)( PHCSBPCostAverBP

Cost∑

, where

Cost – total cost of the project BP – business processes supported by the systems proposed Aver(CostBP PHCS) – business process average cost in information system of the PHCS.

User cost indicator:

)( PHCSuserCostAveruser

Cost

∑, where

Cost – total cost of the project user – future system user Aver(Costuser PHCS) – User average cost in information system of the PHCS.

Project Indicators: Full-time equivalent indicator [14] User participation indicator, defined as:

∑∑ teamMemberuser , where user – future system user that is involved in some stage of the project teamMember – member of project team (e.g., developer, project manager, IT architect, user, among others).

4.4. Defining the evaluation data [1] One of the major advantages of modeling is the creation of a common view over a subject. That is the precise behavior this project aimed at achieving with the creation of a model of the PHCS. By basing project proposals on the created PHCS reference model, a uniform view over the problems and the solutions targeted in the proposals is created between the proponents and the evaluators. Additionally, Saúde XXI and all project proponents gain a common view of the “as-is” Portuguese organizational architecture and the major strategic guidelines and orientations for IS/IT (derived from Portuguese health care strategy and business processes).

Besides ensuring a common view on current and future organizational architecture, the key points that project proposals must address, from a technical perspective, were defined. These key points that proponent organizations are “advised” to address in the project presentation were defined considering the project indicators described in section 4.3. The reference points that proposals must address are: Business processes supported by the project, namely:

Identification of business processes supported by the project, using the common reference model as basis. Characterization of new business processes (if applicable) created by the project. Considering each business process, proponents should: a) quantify expected earnings in having IT supporting the process; b) characterize the population that will be benefited; c) Identify major differences between business processes proposed and reference model ones, among others.

System functions and application architecture, namely: Hierarchical characterization of system operations and

application blocks (and dependencies). Identification of similar functions performed on other systems (inside the organizations or on other similar organizations).

Informational entities namely: Characterization of the relations between informational entities (defined on the reference model) and the systems proposed – the relation might be of type Create, Read, Update or Delete (CRUD). Identification of entities created, updated or deleted simultaneously in proposed information systems and existing organization information systems. Identification of attributes altered in the reference model information entities.

Software development methodology description.

Information Technology Architecture, namely: IT infrastructure characterization, i.e., network, computer servers and personal computers, etc. IT Platform, i.e., operating system, data base management system, among others. Description of IT tiers (as user-interface, data and logic tiers) used to implement each application proposed. Development platform, i.e., programming language, development and testing tools, etc. Presentation of new technologies that the proposed project uses (facing with current organization systems and other organization of the PHCS). Technological and informational characterization of interfaces between proposed systems and existing (or future) systems.

IT project suppliers characterization, describing participation on similar projects, previous projects developed in the organization, among others.

Project characterization, from a project management perspective, i.e., project phases, project duration, project team members experience, users participation on the project, project costs (equipment, licenses and services), among others.

In the next section, an example of the application of the created methods of evaluation is presented.

5. Evaluating an IS Hospital Project: a Case Study

In this section we present an evaluation case of an IS project proposal1. The project proponent is a large Portuguese hospital with about 5000 employees (1000 medical doctors). In the past, the hospital information systems’ (IS) grown as independent information islands (according to hospital health care units). Recently a Saúde XXI supported project provided the means for integration between these systems.

The project proposal described here focus on a particular business process: the drug management process.

5.1. Project Proposal The hospital drug management involve different actors as

physicians (that, according to patient diagnostic/disease, prescribe a drug therapy), pharmacists (responsible for drug preparation and manufacturing), nurses (that, after receiving drugs from the hospital pharmacy ensure that the patients have them according to physician drug therapy) and administrative/management personnel (responsible for other administrative task as warehouse fulfill and management, among others).

1 The facts presented here stand for a hypothetical project proposal in a

hypothetical hospital (all names, brands and facts, for confidentiality reasons, are fictitious); however, this case study is based on our experiences and participation on the evaluation of real IS/IT health care projects, where analogous proposals where evaluated.

«resource»

Drug Therapy


DrugPreparation

«resource»

Patient

«resource»

Physician


Prescribe DrugTreatment

«resource»

Pharmacist

«resource»

Drug«Administrative process»

Drug WarehouseManagement

«resource»

Drug


DrugAdministration

«resource»

nurse

«resource»

Patient

«resource»

Drug Therapy

Figure 18. Drug Management Business Process

This business process consumes and produces several informational entities as drug, patient, drug prescription, health care professional, administrative/management personnel and drug supplier. All entities maintain reference model attributes (see section 4.1.1), except from the drug and drug prescription informational entities that add additional attributes (however none of the existing is altered). Figure 19 presents de drug informational entity.

E n tit y N a m e D ru g In fo rm a tio n a l E n tit y n . º 1 1 .1 Id e n tifie r n a m e T y p e T h in g D e sc r ip tio n S u b s ta n c e u se d fo r m e d ic a l p u rp o se s so ld o n p h a rm a c ie s ,

p ro d u c e in la b o ra to r ie s o r in th e p h a rm a c y . R e la t io n s is p re sc r ib e b y a n p h y s ic ia n (1 2 .1 )

is u se d in a p a tie n t (1 ) is p re p a re d b y a p h a rm a c is t (1 2 .3 ) n u rse (1 2 .2 ) m a y e n su re p a tie n t is h a v in g c o r re c tly th e d ru g

Figure 19. Drug Informational Entity

Currently this business process is badly supported throw the Hospital Drug System (HDS) – described in the reference model (see Figure 14) – that only supports the pharmaceutical activities and poorly supports physicians and nurses’ activities. This project is expected deliver an IS that supports the full business process and thus reducing prescription mistakes (mostly cause by paper based physician prescription), minimizing nurses wasted time in “copying” drug prescription from paper to the system and reducing process time by 30% to 60%. The proposed integrated drug management system (IDMS) application architecture is described in Figure 20.

« I S B l o c k »

D r u gP r e p a r a t i o n

« IS B l o c k »

D r u gP r e s c r i p t i o n

« I S B l o c k »

I D M S

« I S B l o c k »

D r u g P a t i e n tA d m i n i s t r a t i o n

Figure 20. Proposed integrated drug management system (IDMS)

application hierarchical view

Table 1 presents the relations (Create, Read, Update and Delete – CRUD) between Informational Entities and the information systems in the hospital.

Table 1. CRUD Matrix Informational Entity vs. Systems Informational

Entity System D

rug

Patie

nt

Dru

g Pr

escr

i-pt

ion

Hea

lth c

are

Prof

.

Adm

in./

man

ag.

Prof

.

HDS CRUD R CRUD R R

IDMS (proposed) CRUD R CRUD R R SONHO CRUD R R GERHA CRUD CRUD

Notice that the Drug and Drug Prescription Informational Entities are “owned” by two Systems – the old HDS and the proposed IDMS – this topic will be explored in project evaluation in the next section.

At technological level, the system proposed will use existing hospital network infrastructure and requires an IBM web Sphere platform with a DB2 database (which are new technologies for the hospital and for the PHCS) supported in a AS400 server. The IDMS proposed system pretends to provide an interface with HDS that will be used to replicate drug and drug prescription data on HDS and IDMS.

The IT suppliers had previous projects on the hospital and have a long experience on the Portuguese health care industry.

The project proposal presents a two-year duration. Projects phases and durations are presented in Figure 21. The proposed project presents high costs (consequence of the two years experience project team with a mean of 10 person/month).

Figure 21. Project Gantt chart

5.2. Project Evaluation Considering the data presented in previous section, the

reference model (see section 4.1) and the project evaluation indicators (see section 4.3), the project evaluation was developed. In this section, only the relevant project indicators are described.

At business process level the IDMS implementation is expected to increase 45% efficiency of the drug management business process.

In terms of ISA, the IDMS presents some functional overlapping with the HDS, once it will implement some operations that already exist in the HDS such as drug creation, search, update and delete as well as drug prescription functions. Thus, the functional overlapping indicator ( ∑∑ FnewFold )

presents a value near 0.4 (meaning that about 40% of functions already exist in current systems).

Project Integration costs are very high (40% of project cost), 70% of which are related with the integration between HDS and IDMS (the rest 30% if attributed for integration with the Patient Management System – SONHO – and the human resource system – GERHA).

At technological level, IDMS is based on different technologies than the reference model ones (namely the IT platform and server hardware), presenting a technology change indicator of 0.5 (meaning that about half of project technologies are new technologies for the organization).

The IDMS presents an informational entity overlapping indicator (

CUDCUD IEnewIEexist ∑∑ ) of 1, meaning that all

the informational entities create, updated or deleted in the proposed system already exist in other organization systems, which justifies the project high integration costs.

Considering the global ISA, the IDMS presents a interface disregarding indicator near 1, meaning that almost all interfaces provided by the IDMS do not respect at technological level the standard defined in the reference model.

Although the business process disregarding indicator is null (meaning that the system supports the drug management project completely), the business process cost indicator ( )( PHCSBPCostAver

BPCost∑

) presents a value near 5, meaning

that the system proposed cost is five times superior to the project average. The ROI (Return On Investment) presents a quite low value (less than 5%) and cost per user indicator is also quite high (near 2, meaning that each user “cost” is twice higher than in other projects).

Considering the previous indicators the project proposal (as presented before) was rejected. However, considering the possible incomes of having the drug management business process fully supported, some suggestions were required in order to re-evaluate the project proposal.

5.3. Project Redefinition Considering the rejected proposal, three major points were

suggested to be reviewed: 1. Informational entity overlapping. The informational entities

drug and drug prescription were “owned” by the proposed system (IDMS) and HDS (since both were responsible for its creating, updating and deleting). In order to correct this point, it was decided that (see the new CRUD matrix in Table 2):

HDS will be responsible for the drug entity (since this was the system that the pharmaceutics already used, where the drug is the central entity) – proving an interface read-only for the IDMS. IDMS will “own” the drug prescription entity that will trigger the need for drugs in the HDS.

Table 2. New CRUD matrix Informational Entity vs. Systems Informational

Entity System D

rug

Patie

nt

Dru

g Pr

escr

i-pt

ion

Hea

lth c

are

Prof

.

Adm

in./

man

ag.

Prof

.

HDS CRUD R R R R IDMS (proposed) R R CRUD R R SONHO CRUD R R GERHA CRUD CRUD

2. Functional overlapping. The functions related to drug and drug prescription present some overlapping because in previous proposal they must be managed in both systems. However, considering previous point (1), the functions no longer exist in both systems and consequently this “problem” automatically solved.

3. Technology. At technological level the rejected proposal present some new technologies options for the organization and for the PHCS, namely the choice for an IBM solution (at all levels: application platform, operation system and server). This technological choice was not aligned with PHCS (or hospital) strategy and thus it was recommended to follow the technological guidelines in the reference model.

Although all previous issues were addressed (and project proposal changed) the financial indicators still shown that the

project was too expensive for the hospital, namely the ROI and cost-per-user indicators. Noticing that project major costs consist in developing the new system (the installation was comparatively cheaper), we suggested to the hospital to form a consortium with other hospitals that shared the same need for a system for supporting the drug management process (which shown up to be almost all Portuguese hospitals). This way the cost per system installation would fall significantly (once the cost would be shared among several hospitals).

Considering all the recommendations a reviewed proposal was presented to Saúde XXI proposed by seven major hospitals.

5.4. Project Re-Evaluation The new project proposal was (once again) evaluated. Once

all the issues that previously did not allow project acceptance were addressed, the project was accepted. Namely the financial indicators now demonstrate the project viability – e.g., the cost-per-user is 0.9 (meaning that is bellow project average), the ROI also increased and the business process cost indicator fall for less than one.

The project was approved and the reference model updated with the new system.

6. Discussion The case study demonstrates the viability of our approach in

IS/IT project evaluation. The approach proposed considers organizational, IS/IT, project and financial aspects when evaluating IS/IT projects, and is soundly based on common reference model. Until now, the results have been very satisfying, in the sense that, not only there is a more common understanding of what each project is, but also because institutions are beginning to understand the need for a common Architecture and IS/IT Strategy. Publishing the reference model and the evaluation methods as also benefited the work of Saúde XXI, because every decision is taken on a sound and public basis.

However, the main concerns of the project team are now not related to the outcome of this project, but with the creation of the processes that guarantee the continuation of its effects.

The involvement of an entity that is totally independent and has only academical and research interests in these matters, like the CEO, was fundamental for the success of the project, namely because PHCS is not free of lobbies and financial interests, that undermine most initiatives to explicit and rigorously evaluate projects. However, the evaluation of new projects should be, as it is in other organizations, a regular organizational process, executed by entities that exist in the organization. This stands out the need for creating this process at a strategic level in the PHCS.

It is the CEO’s conviction that, in order to guarantee the existence of a strategy and a corresponding architecture for information systems in the PHCS, a new, strategic organizational unit must be created and, as with private companies, this unit must accommodate business and IS/IT at the highest level. Based on this principle and on the results of the undergone project, the CEO is currently studying this issue in order to propose an adequate organizational structure and the underlying processes needed for correctly managing IS/IT in the PHCS.

7. Conclusion and Future Work In this paper we presented the preliminary results of a project

jointly developed by Saúde XXI and the CEO, which aimed at creating a methodology for evaluating IS/IT projects on the Portuguese Health Care System. The project has sound theoretical and technical basis on the Organizational Engineering discipline and, more specifically, on the CEO Framework.

The project considered several complex tasks, including the creation of a model of the Portuguese Health Care System at Business and Information Systems levels, the creation of a Knowledge Base for Project and Systems information, the definition of a set of criteria for evaluating project proposals, and the redefinition of the information each proponent has to supply when applying for financing. This paper focuses on the project evaluation process from an organizational perspective, presenting real examples of the project team methodology, options, major decisions and actions.

Besides creating the mechanisms for correct evaluation, the project team has now to focus on proposing, at the highest instances, the necessary structural and procedural changes to assure the correct application of the evaluation system.

Two fundamental issues must also be addressed in a near future: model maintenance and proposal guidance.

Maintaining a business model is a very difficult task, since it demands the implementation of a specific process in the Organization that focuses only on that purpose. However, all the models created, and indeed all the evaluation system created, will be of no use if the reference model is not constantly maintained. For this reason, this issue must be addressed, since it is necessary to create such a maintenance process and introduce it in a seamless way in the Health Care System.

Another advantage that can be readily produced is a proposal guidance procedure. By having full access to the Reference Model and to the Knowledge Base, Health Care Institutions can create proposals that not only have a better chance of obtaining financing, but also to create proposals that are better aligned with the other institutions’. In order to accomplish this in a controlled fashion, the project team must consider the creation of navigation and analysis system, which will allow all institutions to access the information they need. Furthermore, each institution must be provided with appropriate information and education regarding information systems strategy and architecture, so that they can evolve their condition in a correct and supported way.

8. Acknowledgements The research presented in this paper was possible thanks to

the support of Saúde XXI and several Portuguese health care organizations.

9. References [1] Vasconcelos, A., Caetano, A., Neves, J., Sinogas, P., Mendes, R., Tribolet, J. “A Framework for Modeling Strategy, Business Processes and Information Systems”, 5th International Enterprise Distributed Object Computing Conference EDOC, Seatle, EUA, September 2001. [2] Caetano, A., Rito A., Tribolet J., Neves J., Sinogas P. “The Modify Project: Combined Business and System Modeling for Adaptable Enterprise Computing System Design”, CAPSI, 2000. [3] OMG, “Unified Modeling Language Specification – Version 1.3”, OMG, 1999. [4] Carnegie Mellon University, How do You Define Software Architecture?, Software Engineering Institute, Carnegie Mellon University, December 2000.http://www.sei.cmu.edu/architecture/definitions.html [5] Tissot, Florence, and Wes Crump, An Integrated Enterprise Modeling Environment, P. Bernus, K. Mertins, G. Schmidt (Eds.), Handbook on Architectures of Information Systems, Springer, pp.59-79, ISBN 3-540-64453-9, 1998. [6] Vernadat, François, Enterprise Modeling and Integration, London, Chapman & Hall, 1996. [7] Eriksson, H.-E., Penker, M. “Business Modeling with UML - Business Patterns at Work”, Wiley Computer Publishing, 2000. [8] Marshall, C. “Enterprise Modeling with UML: designing successful software through business analisys”, Addison Wesley, 2000. [9] Garlan, D. et al., Architectural Mismatch (Why It’s Hard to Build Systems Out of Existing Parts), Proceedings 17th International Conference on Software Engineering, Seatle, WA, April 23-30 1995, pp.170-185. [10] Maes, Rik, Daan Rijsenbrij, Onno Truijens, and Hans Goedvolk, Redefining Business – IT Alignment Through a Unified Framework, White Paper, May 2000.http://www.cs.vu.nl/~daan/ [11] Spewak, Steven, and Steven Hill, Enterprise Architecture Planning: Developing a Blueprint for Data, Applications and Technology, Wiley-QED, ISBN 0-471-599859, 1992. [12] Vasconcelos, A., P. Sousa, and J. Tribolet, Information System Architectures: Representation, Planning and Evaluation, Proceedings of International Conference on Computer, Communication and Control Technologies Orlando, U.S.A., July 2003. [13] DeBoever, L., Enterprise Architecture Boot Camp & Best Practices: A Workshop, Meta Group, 1997. [14] Kerzner, Harold, Project Management: A Systems Approach to Planning, Scheduling, and Controlling, John Wiley & Sons, ISBN 0471225770, 8th edition, 2003.

Using organizational modeling to evaluate health care IS/IT projects

Documents