Generic model for services: health domain study
Zoran Milosevic
CRC for EDST,
University of Queensland,
Brisbane, QLD 4072, Australia.
zoran@dstc.edu.au

Abstract
This paper provides a broader view on services thancurrent Service Oriented Architecture (SOA) approaches.
We analyse a generic concept of service from economic,
legal and business perspectives and discuss theimplications for the health domain. This enables us todevelop an ODP enterprise viewpoint of the service concept
and its relationship with the ODP computational viewpoint,
closely linked with the SOA concepts. The health domain
provides a rich base for developing a comprehensive viewon services. This is because of the inherent complexity ofthe domain with many actors, policies and dynamics
involved in an increasingly multi-organisational and multijurisdictional context.
The paper also provides acontribution in positioning services as part of an overall
enterprise architecture for the health domain.
Keywords: Service Model, RM-ODP, SOA, HealthDomain1. Introduction
The recent popularity of Service Oriented Architecture(SOA) approaches can be explained by the fact that they
promote modularity and enable developing andrestructuring of ICT service units in business congruent
structures. This is an attractive alternative to the monolithic
applications of the past, that resulted from the structure
clash between business systems and ICT systems. Suchmonolithic applications, offered by different vendors anddeployed in a fragmented way, have resulted in IT systems
that often provide duplicated and inconsistent views on data
and functionality. This situation has resulted in manydifficulties in managing IT systems, including change
management in response to new requirements. This state ofaffairs is evident in many industry domains including healthcare.

The SOA allows decoupling of ICT applications into thelogical units of business functionality, namely thecomponents that can be configured and composed to create
new or changed business function with minimal impact on
the rest of the system. These components offer theirfunctionality through their interfaces and are often referred
to as services in the SOA speak. Web Services are one
special case of SOA.
However, the SOA paradigm has also raised a number ofquestions regarding the meaning of the term ‘service’, inparticular for the business stakeholders used to thinking interms of economic or business perspectives. If the conceptof service is to be used by both the IT and business domain
experts, then there needs to be a clear separation ofconcerns pertinent to this concept.
This paper provides such a separation, by considering
not only the computational and engineering aspects ofservice, as in the SOA approaches, but also their enterprise
aspects. Both aspects can be regarded as a specialisation ofa generic concept of service. The value of this broader
scope is in the capability to provide a unified view ofservice, so that both business and IT stakeholders establish
a common foundation for communicating among
themselves. This also ensures architectural alignment
between business and IT aspects of an overall enterprisearchitecture of a system in broader sense.
We discuss the ideas in the paper by considering thepervasiveness of the service concept in the health domain.
This is a highly complex domain, involving many different
actors that must effectively collaborate in a service delivery
while increasingly relying on the IT capabilities to do so.
The service concept in the health domain needs to coveractivities of (and policies to apply to) health professionals,
some of which are increasingly relying on the underlying IT
services.
The next section provides a background discussion on
the generic considerations for the concept of services,1

illustrated with examples from health domain. Section 3
considers the concept of service from various architectural
perspectives of an overall enterprise architecture. Section 4
proposes an ODP enterprise viewpoint on service. This isfollowed by an ODP computational viewpoint of service,
which is then mapped onto the SOA and Event-DrivenArchitecture (EDA) styles. Section 7 summarises ourapproach and outlines direction for our future work.

2. Service: generic aspects and health examples
This section outlines key aspects of the service concept,
in particular from the economic, legal and businessperspectives and reflects on their corresponding
characteristics in the health domain.
In general, a service can be defined as ‘something done
to benefit others’. Service provision is then a process thatcreates benefits to consumers by facilitating a change in
consumers, a change in their physical possessions, or achange in their intangible assets [1].
In the health domain, the benefits to consumers are theimprovement of their medical condition, their health andtheir well-being, through the delivery of health-careservices. These are provided by various specialist providers,such as doctors, nurses, and allied health professionals, andusually through coordinated interactions between these
professionals, e.g. in the context of the “continuity of care”
for individual consumers, or through care packages. The
delivery of such a combined care package can be quite
complex and often requires synchronised and timely service
delivery from all service providers involved. Finally, in thehealth domain the benefits are increasingly covering abroader range of services for the population in general,
including for example preventative care and community
services in addition to the acute service delivery. This
broader spectrum of service delivery for all citizens during
their life time is often referred to as ‘care continuum’.

2.1 Economic aspects
When considered from an economic perspective, service
is an economic activity through which benefits to theconsumer are delivered, in exchange for a payment of someform to those who provide services.
In the health domain, service provision also has an
economic aspect because of the cost of service delivery,arising from the labour cost or from the utilisation ofnecessary resources such as medical equipment andmedications. We note that there are various economic
models for covering costs associated with service provision
ranging from full public subsidies to fully private payment
with most of these being a blend of public and private

models. This depends on the national health system inquestion, which may include state jurisdictions.

2.2 Legal aspects
In the context of legal frameworks that govern service
provision in most economies, including international trade,a promise to deliver service, or service offer, implies certain
level of guarantees from the service providers. The
guarantees can be in terms of what functionality is provided
and also in terms of non-functional variables often referred
to as Quality of Service (QoS). These guarantees can besubstantiated by various mechanisms such as certification
requirements and reputation characteristics of providers.
The guarantees can even be taken as given, based on the
direct trust in service providers from consumers’ previous
experience. The legal frameworks also provide rules andregulations for the measures to be taken in case theseguarantees are not met or are violated.
In the case of health care service providers, part of theguarantees are derived from the rules that set prerequisite
criteria for permitting delivery of health services, e.g.
requirements for passing certification tests typically set bygovernments or medical boards. An example of such anorganisation in Australia is the Australian College of HealthServices Executives [9]. These bodies also set rules for theactions to be taken in cases where there is inadequate
service delivery. There are various forms of penalties that
apply to service providers ranging from financial penalties
to the revocation of their licences or certifications forproviding services.

2.3 Business aspects
In the world of business, services are usually describedin terms of service offers, which when accepted byconsumers, form the corresponding agreements or a legallybinding contract. Contracts can be regarded as a special
way of defining guarantees to consumers for the behaviourof service providers. A business contract is constrained by
the legal framework of the jurisdiction in which it is made.
The contract will specify what the service provider has
agreed to deliver and what the service consumer has agreed
to accept, i.e. the consideration to be given in exchange forthe use of service.
In health, contracts also exist as a way of governinginteractions between various actors such as between private
and public providers, medical and non-medical providers
and so on. They are also subject to standard business
contracts law. However, the ‘contracts’ that apply to theinteractions between health care providers are consumers
have a somewhat different character. The main concerns
here are the policies that specify the responsibilities of2

health providers and which are motivated by the safetyconcerns. Policies can also state the rights that consumers
have in case of inadequate service delivery by healthprofessionals. Note that consumers also have certain
responsibilities, for example to comply with the therapies
prescribed. As opposed to business contract law coverage,
the law that applies to the consumer and health providers ismostly common law.
Furthermore, in business, many standard agreement
types have been developed over time, reflecting historicalpatterns of interactions. Examples are real-estate contracts,financial contracts, construction contracts and service levelagreements (SLAs).
In the health domain, there are standard agreements too.
Some involve commercial providers and others are more
within government scope, such as agreements between nongovernment organisations and health service providers, e.g.
Memorandums of Understandings.

2.4 Generic aspects: summary
In summary, in addition to the functional aspects to beprovided by the service (i.e. ‘something to be done’), there
are other characteristics of services such as:•••

the benefits or value delivered to consumers and theassociated measures; in other words, these areoutcomes, which in the health domain are an improved
health for individual consumers and for the populationin generalpolicies that apply to those who deliver services andpossibly to those who are recipients of services; forexample in the health domain the former are quality ofcare, accountability, delegation and privacy while thelatter are patients' responsibility to follow treatment
guidelines. Note that a subset of policies come into
effect in case of violation of the primary policies, e.g.
the measures that need to be taken when there is anunsatisfactory treatment of patients
costs associated with service delivery

3. Service concept and enterprise architecture
The term ‘service’ has also been used in the context ofIT systems, where in the past it has been primarily used todescribe functionality provided by a software component,
application or the whole system. In some cases, the term isalso linked with the cost aspects of service delivery.
However, in IT systems services have rarely addressed theirsocial, legal or economic aspects. These aspects are critical
for the health domain and, from the point of view of anenterprise architecture, they belong to the businessarchitecture aspects of an overall architecture.

Considering the importance of enterprise architecture forhealth systems, as evidenced by many new initiatives in thehealth domain, such as in the US Federal EnterpriseArchitecture [10], it is important to take into account a
broader definition and model for health care service. This isneeded to describe other characteristics of services, such as
the policies that apply to health providers and theirimplication on the underlying IT applications that support
coordinated health service delivery.

Business

Improve service delivery
objective
Continuity of care
community(roles, process,policies …)

Patient
consent
policies

Information

Application
Access Control
functions
Messaging
Applications

Workflows

Management
Applications

Read/
Updatefunction sElectronic Health
RecordEHR lists- medications- allergies ….
Event
Summaries
Commun ity
In formation

Technology
SOA

Web Services

TCP/IP HL7 messaging

ebXML
messaging

DB2

Figure 1: Different service aspects in an EnterpriseArchitecture

We illustrate this through a simplified example showing
some of the modelling concepts in business, information,
application and technology architecture of an overall
enterprise architecture, Fig.1 Consider patient policy
constraints regarding access to and sharing of informationin their electronic health records (EHR). These areimportant aspects for the EHR service provision and theyneed to be expressed as part of a business architecture on an
overall enterprise architecture. This business constraint
needs to be propagated to the definition of the access
control rules for the read/update functions for the EHR, in
the application architecture, as shown with the arrows
linking these modelling concepts. This functionality is thenspecified as part of the technology architecture, for example
using Web Services technology. The example also shows
links to the information architecture which specifies
structure of EHR, and which uses a specific databasetechnology, DB2.
Another example is the specification of various roles andprocesses in the continuity of care community (specified in
the business architecture) that can be implemented using a3

workflow engine which in turn may need to use read/update
function to access the EHR system.
In the remainder of this paper, we propose a broader
framework for defining services, by adopting the ISO ODP
architectural framework. According to this framework, asystem or a concept can be defined from various
architecture viewpoints reflecting specific concerns of therelevant stakeholders. These viewpoints are enterprise,computational, information, engineering and technology. In
this paper we consider only enterprise and computational
viewpoints.
In the ODP standard the concept of service is mentioned
in the context of foundational concepts and is defined as ‘aparticular abstraction of behaviour expressing guarantees
offered by a service provider’ [2]. To a significant extent,
this statement reflects the fundamental aspects of service as
per their economic, legal and business interpretation
discussed above. We will use this definition as a starting
point for further refinements. Specifically, we will refine
this definition from each the ODP enterprise andcomputational viewpoints allowing us to support modellingof services from either the IT or business perspectives. Our
intention is to provide a clear separation of concerns
associated with service concept while ensuring that its
fundamental properties are preserved.
Our aim is to ensure that service becomes a more
explicit modelling concept in the ODP specification, in asimilar way as the concept of object has the enterprise,
information, computation and engineering viewpoints. Thiscan be also seen as a contribution to current revisions
within the ODP standards, with the aim to promote a more
unified view on service.
We begin by considering service from the enterprise
viewpoint in next section, followed by computational
viewpoints, presented in following sections.

economic and legal activities through which the provider
offers services with the corresponding guarantees. Thisdefinition includes a number of modelling concepts which
we depict using the corresponding meta-classes in the metamodel in Fig. 2. These are the Service, the Provider and the
Guarantee meta-classes and the relationships between theProvider and the Service meta-classes, and between theService and the Guarantees meta-classes. The Service metaclass is an abstract meta-class, as there are many specialised
types of services. In the health domain, these can beclassified in many different ways [1]. Note that due to space
limitation this is not a fully specified meta-model. Rather, it
only includes key meta-classes and their relationship, while
omitting other detail such as attributes of the meta-classes
and full details of their relationships, e.g. their full

4. Enterprise viewpoint considerations
The ODP enterprise viewpoint is about the scope,
policies to apply and objectives of the systems to be built.
Thus the ODP enterprise specification needs to define theorganisational, policy and legal constraints for the IT
systems to be built. Accordingly, the concept of service inthe enterprise specification deals with a broad set of issues
that include human and social behaviour in the system. Partof this behaviour applies to the behaviour (i.e.
functionality) of an underlying IT applications and systems
that are used by the human actors. This was discussed in thecontext of health domain example in the previous section.
From the ODP enterprise viewpoint, and by refining theservice as a foundation concept, stated above, service is an
abstraction of behaviour of a service provider in terms of

Figure 2: Service - ODP enterprise viewpoint4

cardinality and navigability properties.
The service provides some value to potential consumers
according to the guarantees associated with the service
offer, and this is shown as the relationship between theService and the Consumer meta-classes.
The guarantees that are offered by the service provider
for the provision of service can be regarded as a partiallyfilled business contract (shown as specialisation
relationship between the Contract and the Guarantee metaclasses). Such a contract will be instantiated at the point
when a consumer of service accepts the service offer of theprovider.
Typically, the guarantees specify the capabilities andconstraints of a service provider and can be in terms offunctional or non-functional properties. It is also possible
that, through a form of negotiation, the original guarantees
are updated to better reflect needs of consumers. Notice that
the Service Provider and Consumer meta-classes have theircorresponding roles in the respective contract (shown
through the relationships between the Contract andConsumer and Provider classes).
For a contract to be legally valid, and thus the guarantees
to be accompanied by the corresponding reparation actions,each of the roles in the contract, i.e. the provider and theconsumer must have the legal capacity properties. This is
one of the elements of legal contract validity [4]. The ODP
enterprise language includes several accountability
concepts and we use the concept of party, defined as ‘anenterprise object modelling natural person or any otherentity to have some of the rights, powers and duties of anatural person’ [3]. This is shown as two specialisation
relationships between party and consumer and provider
meta-classes.
Finally, we include a meta-class that describes violation
measures that need to be applied in the case of failure tomeet service guarantees. These measures could be definedin terms of the policies that take effect in response toviolation events. One possible approach to formallyspecifying and implementing violations of guarantees statedin business contracts is given in [8].

5. ODP computational viewpoint considerations
From the ODP computational perspective a service is an
abstraction of behaviour of a server object in terms of afunction that it makes available to other objects. These
guarantees include computational activities such as
conveyance of information back to the client object. Thistransfer of information is initiated in response to the client’s

invocation, i.e. their request for a function to be performedby the server object.
It is important to note that the above definitionencompasses both the synchronous (e.g. RPC) andasynchronous (e.g. message-oriented or publish-subscribe)styles of interactions. In the latter case, the server object iscalled producer and the client object is called consumer.
Therefore, while the concept of service in the ODP
enterprise viewpoint required some additional modelling
concepts in the ODP enterprise language, e.g. Guarantees,
Provider and Consumer (as discussed in section 4), theexisting ODP computational concepts are sufficient tomodel service in the computational viewpoint.
In the following we show how these ODP abstract
computational concepts can be mapped onto the specificarchitecture styles such as SOA and event-driven
architectures (EDA). These mappings, coupled with therelationships between the ODP enterprise andcomputational viewpoints (which will be briefly discussed
first), enable us to provide more direct linkages between
business and application architectures.

5.1 Relationships to enterprise specification
We describe several relationships between the ODP
enterprise and computational modelling concepts pertinent
to services only. These relationships need to beaccompanied with the relationships between otherenterprise and computational modelling concepts, some ofwhich are described in [3].
The function that the (computational) server object
makes available to others implements guarantees of theservice provider stated in the enterprise viewpoint. The(computational) client object implements some of thefunctionality of consumers specified in the enterprise
viewpoint.
The basic behaviour specified in terms of computational
behaviour above needs to be augmented with the behaviour
expressions specifying the policies that apply to the service
provider and consumer enterprise objects. These additional
behaviour specifications can be implemented using a
special kind of computational objects, i.e. policy objects
that implement obligation, permission or prohibition
expressions. A detail description of policy objects and their
behaviour is presented in our earlier work [6].
The use of policy specifications can be either to directly
prevent an inadequate service delivery or as part of businessactivity monitoring. In the latter case certain reparation
measures could be applied and these can be implemented
through the appropriate set of computational objects. A
more detailed description of various enforcement
approaches are given in [7, 8].

55.2 SOA and mapping to ODP
The principles of SOA have been around for long time,
including the early development of open distributed
systems and the related standards such as ISO ODP [2,3]and OMG standards. The SOA principles became
prominent in recent years with the emergence of the Web
Service technologies and specifications. Perhaps the novel
features are:•the more explicit focus on the business logic to besupported, including more direct access to human users
via Web-based interfaces•

the capability to link services through various
choreography models and•a more documented-oriented messages (typicallydefined in XML) in communication between objects.
The use of SOA in the health domain can be seen as anenabler towards replacing monolithic and hard-to-change
health applications of the past with the components that
more directly reflect the needs of various healthprofessionals. This would enable clearer definition ofservices of each of the health providers and linking theminto processes that reflect health-care specific activities.
This applies to administrative and procurement activities,
but also linking of various service providers in the context
of ‘continuity of care’ delivery.
In the following we list key SOA principles, and provide
a simplified mapping to the ODP computationalarchitecture framework.
Loose coupling – meaning that services are definedsolely in terms of the functionality they provide, without astrong (or with a small and well-known) dependency onother components; in ODP, this decoupling is achieved
through the concept of object, which can expose its
functionality through one or more interfaces;
Interoperability – meaning the ability of services
implemented using different platforms and languages tocommunicate with each other; in ODP this is achieved
through a protocol independent computational interface
specification
Composition – meaning a capability for services to beassembled into applications in various ways including theways which were not anticipated at the time of service
definitions. This allows developing more complex businesslogic and adding new functionality as new business needs
require. In ODP there are various mechanisms forcomposing objects, in particular the computational binding
object which allows connecting computational interfaces ofvarious objects. The binding object is an abstract
mechanism for linking various objects and some specificstyles of binding are orchestration and choreography. An

approach based on the refinement of binding object
targeting such binding styles are discussed in more detail in[7].

5.3 Event-driven architecture and ODP mapping
Event-driven architectures (EDA) are based on thecapabilities of components to produce events and of othercomponents to consume events. This is often referred to as
publish-subscribe model of interactions. So, rather than
through a usual synchronous communication style typicalof SOA approaches, components interact by producing andconsuming events. This assumes the existence of a message
oriented middleware (referred to as message queue) which
provides persistent storage for events, after they are
produced and consumed by others. The capabilities of
EDA, also enable the specification of applications in termsof events and event relationships, i.e. the event patterns, as
proposed in [5]. A similar approach was also taken in [6],for the purpose of real-time monitoring of businessactivities associated with enterprise contract management.
The combined capabilities of SOA and EDA offer many
options for developing health applications in an incrementalmanner, while leveraging the existing applications where
possible. For some applications in which there is no needfor real-time access to information, the SOA may suffice.
For others, the choice may be based solely on the EDA
principles or more likely it would be the combination of
SOA and EDA solutions.
The use of EDAs and event-pattern specifications in thehealth domain could be exploited to support real-time
checking of the adequacy of service delivery by healthproviders, or the implementation of medical treatment by
the patients.
In terms of the mapping to the ODP computationalmodel, the concept of event in the EDA corresponds to the
ODP concept of signal. This is defined as an atomic sharedaction resulting in an one-way communication from an
initiating object to responding object [11]. As operations in
the ODP computational model can be defined in terms ofsignals, so the messages communicated between
components in an EDA can be defined in terms of events.

6. Conclusions and Future Work
This paper provides an input towards a generic service
modelling covering both the business and IT aspects ofservices. We use the ISO ODP standard as a framework fordiscussing the ideas. We presented an initial proposal for
extending ODP standards to give more prominence to the6concept of service. We then discussed relationships
between ODP enterprise and computational modelling
concepts regarding services. When further consolidated,these relationships will allow generic mappings between
different viewpoints on service.
Further, each of the abstract set of ODP viewpoints canbe made more specific. On the technology side we havedemonstrated how the ODP computational modelling
concepts could be mapped to more concrete architectural
styles such as SOA and EDA. These are still abstract
models and the respective concrete models would be Web
Services architectures and JMS. Our approach is illustrated
in Fig. 3. The mappings 2, 3 and 4 show generic mappingsfrom the enterprise language concepts to the underlying
technology implementations. For example, the concept ofpolicy in the enterprise language can be mapped onto thepolicy objects in the computational viewpoint. These can be
implemented using both the SOA and EA solutions, such as
WSDL and WS-eventing. Finally, the health specificconcepts could be used to refine and extend relevant ODP
concepts. This mapping (1), with the mappings 2, 3 and 4,
thus provides a link from the enterprise language to theunderlying implementation options, such as the specific
SOA and EDA solutions.
Health Domain
concepts

1

Abstract modelling concepts

ODP EnterpriseViewpoint Concepts

2

SOA
concepts

7. Acknowledgements
The work reported in this paper has been funded in partby the Co-operative Research Centre for Enterprise
Distributed Systems Technology (DSTC) through theAustralian Federal Government's CRC Programme(Department of Education, Science and Technology). The
author would also like to thank Walter Robb, from
Queensland Health for providing valuable comments to thispaper and to Keith Duddy for his review of an earlier
version of the paper.

8. References

ODP Computational
Viewpoint Concepts
3

health domain and test this on a number existing and future
initiatives within Queensland and Australian healthorganisations. The concept of service is one, but importantmodelling concept in this language. We also plan to provide
a more comprehensive mapping between various ODP
viewpoints, by following the approach we used in [7].
We believe that the maturity of ODP standards (directly,or through other standards that were influenced by ODP),
provide a sound basis for developing an enterprisearchitecture framework for health domain. The precise
architecture of ODP, supported by the emerging and futuretools, including model-driven engineering, is a promising
candidate for developing a business-driven, and sustainable
enterprise architecture for the existing and future healthapplications.

[1] http://en.wikipedia.org/wiki/Service (accessed June 2005)

3
EDA
concepts[2] ISO/IEC IS 10746-3, Open Distributed Processing
Reference Model, Part 2, Foundations, ISO 1994

[3] ISO\IEC IS 15414, Open Distributed Processing-Enterprise4
Web Services

4
JMS,
WS-eventing…

Language, 2002.

[4] Z. Milosevic. Enterprise Aspects of Open Distributed
Systems. PhD thesis, Computer Science Dept. The
University of Queensland, October 1995.

[5] D. Luckham, The Power of Events, Addison-Wesley, 2002
[6] P. Linington, Z. Milosevic, J. Cole, S. Gibson, S. Kulkarni,
Figure 3: From health domain concepts to concrete
technology solutions

The paper was motivated by a recent collaboration
between DSTC and Queensland Health regarding theestablishment of an enterprise architecture framework forthis health organisation. However, the results pertinent to
the health domain are not specific to Queensland Healthand could be applied to many health jurisdictions.
In future we plan to continue this study by developing
more comprehensive business language concepts for the

S. Neal, A unified behavioural model and a contract forextended enterprise, Data Knowledge and Engineering
Journal, Elsevier Science.

[7] A. Berry, Z. Milosevic, Extending Choreography with
Business Contract Constraints, International Journal of
Cooperative Information Systems, Vol. 14, Nos. 2 & 3(2005), p. 131-179, World Scientific Publishing Company.

[8] G. Governatori, Z. Milosevic, Dealing with contract
violations: formalism and a domain specific language, Proc.

7

the 9th IEEE EDOC conference, Holland, Sept. 2005, toappear.

[9] http://www.achse.org.au/[10] http://www.whitehouse.gov/omb/egov/a-3-2-serviceshealth.html

8