SEMANTIC SERVICE-ORIENTED DESIGN AND DEVELOPMENT
METHODOLOGY FOR ENTERPRISE HEALTHCARE
INTEGRATION
Ratnesh Sahay, Ronan Fox and Manfred Hauswirth
Digital Enterprise Research Institute, National University of Ireland, Galway, Ireland
Keywords:
Health level seven (HL7), SOA, Web service, Electronic patient record (EPR), Semantics.
Abstract:
The application of ontologies (semantic) to enhance any existing or proposed Service-Oriented Architecture
(SOA) based software architecture has various levels of use in terms of intra and inter enterprise integration.
The use of ontologies in an architectural design and development methodology of any service-oriented enter-
prise software holds the key to offer a dynamic, flexible and scalable solution. Current efforts in semantic
Service-Oriented Architecture (sSOA) involve primarily the top-down modeling of services and data. A road-
map that meets industrial demand of existing (bottom-up) services and data is missing. This paper analyses
a healthcare standard (HL7) as an integration mechanism to connect healthcare enterprises. We have applied
semantics on top of HL7 profiles to fill the gap between HL7 and SOA artifacts. The results have shown that
semantics can ease the integration steps and burden to connect healthcare enterprises. We have proposed an
integration platform which is based on a semantic Service-oriented Architecture (sSOA). Our goal is to ap-
ply lightweight semantics that incorporate and benefit from both development methodologies (top-down and
bottom-up), to create a converged approach, for enterprise healthcare integration.
1 INTRODUCTION
In recent years various research and industrial ef-
forts have been focussed on Service-Oriented Archi-
tectures(SOAs) where Web services provide the tech-
nological foundation for implementing and deliver-
ing SOA platforms. The integration and/or interop-
erability requirements of enterprise information sys-
tems have resulted in the development of new types
of SOAs, called semantic Service-oriented Architec-
ture (sSOA). However, a clear design and develop-
ment methodologyis missing and ”gaps” between do-
main, SOA (Web service), and semantic (ontology)
artifacts exist.
A generalised integration approach for all types
of enterprises is not useful as each domain has its
own complexities and interoperability requirements.
A domain-based balanced integration approach which
includes domain knowledge (e.g. simple taxonomies,
ontologies), technology (e.g. Web services, semantics
tools), and domain specific development methodol-
ogy (e.g. top-down/bottom-up) is required to achieve
the full potential of a semantic Service-oriented archi-
tecture and to deliver a meaningful enterprise integra-
tion solution.
In a top-down ontology development methodol-
ogy ontologies are created first whereas in bottom-
up methodology ontologies are created from existing
syntactic format, e.g., XML, EDI, WSDL. We have
introduced a Electronic Patient Record (EPR) inte-
gration platform, called PPEPR: Plug and Play Elec-
tronic Patient Records
1
, to connect healthcare enter-
prises. Our focus is on Health Level Seven (HL7)
standard, which is due to the fact that it is the most
widely used message based healthcare communica-
tion standard and HL7’s user base has been growing
since the early 2000s.
In this paper, first we analyse the HL7 standard
and its Web Service and SOA profiles from Electronic
Patient Record (EPR) integration perspective. Sec-
ond, we describe how ontologies are applied on top
of HL7 profiles to resolve the ambiguity and hetero-
geneity between messages, service, and process defi-
nitions. Next, we explain our ontology development
methodology. Finally, we explain PPEPR’s assess-
ment that shows its effectiveness which is evaluated
on various integration parameters.
1
http://www.ppepr.com/
159
Sahay R., Fox R. and Hauswirth M.
SEMANTIC SERVICE-ORIENTED DESIGN AND DEVELOPMENT METHODOLOGY FOR ENTERPRISE HEALTHCARE INTEGRATION.
DOI: 10.5220/0001835101590166
In Proceedings of the Fifth International Conference on Web Information Systems and Technologies (WEBIST 2009), page
ISBN: 978-989-8111-81-4
Copyright
c
2009 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
The main contribution of this paper is to present a
design and development methodology for associating
semantics with HL7’s message, service, and process
definitions in a service-oriented environment.
2 HL7 AND SOA
Health Level Seven (HL7) is a standardization body,
which develops data standards for storing and ex-
changing information across the healthcare industry.
The HL7 standards cover both clinical and admin-
istrative aspects of the healthcare industry, includ-
ing laboratory, clinical genomic, medical records, pa-
tient care, pharmacy, public health reporting, regu-
lated studies, accounts and billing, claims and reim-
bursement, patient administration and personnel man-
agement scheduling. There are two major HL7’s ver-
sions, HL7 v2 & v3. The HL7 v2 standard was cre-
ated mostly by clinical interface specialists, and the
HL7 v3 standard has been influenced by medical in-
formaticians.
HL7 v2 message is (EDI) Electronic Data Inter-
change based and consists of segments which are rep-
resented by rows. Segments are divided into data
fields, separated by vertical bar symbols, each field
containing data elements. Data elements conform to
any of several HL7 v2 data types.
The HL7 v3 specifications are centered around a
single, unified Reference Information Model (RIM)
covering all domains of the healthcare industry.
The RIM defines all data structures, data types and
vocabularies, as well as the relationships between
them. RIM structural arrangement is based on object-
oriented paradigm and it includes several classes, rep-
resenting domain models from which all healthcare-
related messages and documents are built. HL7 v2
messages are unstructured and flexible involving op-
tional fields and segments whereas HL7 v3 is struc-
tured and provides greater consistency across the en-
tire standard.
In 2003 HL7 has published the HL7 v3 Web ser-
vice profile(Ruggeri et al., ) that provides the useful
capability to transport existing HL7 v3 messages us-
ing Web service protocols. The intention of this WS
profile is to achieve “plug-n-play” interoperability via
Web services in a healthcare environment. In this en-
vironment Independent Software Vendors (ISV) and
corporate developers implementing HL7 interfaces
can write generic and reusable classes, subroutines,
and modules consistent with the guidelines set forth
by the HL7 for Web services standards in order to
handle HL7 message traffic from a potentially unlim-
ited number of connecting applications and services.
If applications that “expose” HL7 messages follow
the HL7 Web services profile (WSP) guidelines, then
“consumers” of HL7 messages can be written with-
out prior knowledge of interacting applications. A
detailed description of HL7 specifications is outside
the scope of this paper and we briefly explain HL7
from an integration perspective. Three major issues
from an integration perspective are:
1. The service definition becomes superfluous, this
leads to message definition based bottom up ap-
proach where service clients are automatically
able to interoperate based on the messaging def-
inition.
2. The WS-profile assumes that all different health-
care entities will follow the particular standard.
3. Message, service, and process definitions are tied
together. Thus, there is an absence of “separation
of concern”.
One major benefit of this approach is that “prior
knowledge”or a single “agreed” model is not required
at the communication level but still assumes a single
“agreed” model at specification level where all health-
care entities should follow the Web service profile.
There is a commonindustrial practice that people who
manage information, most often have different ways
of interpreting this information(Iakovidis et al., ). For
example, most of IT or healthcare professionals are
open to different interpretation of medical standards
and diverge from the standard intended meaning and
use them for different purposes, thus challenging the
purpose of industry standards(Valle et al., 2005).
Recently HL7 has published SOA4HL7(Honey
et al., ), a guideline for implementing healthcare
services within a Service Oriented Architecture.
SOA4HL7 complements the Service Specification
Framework (SSF) defined within the Healthcare Ser-
vices Specification Project (HSSP)
2
, but provides an
additional interim method of defining and implement-
ing Web services based on HL7 v3 artifacts. Two ma-
jor integration issues are:
1. The SOA4HL7 profile is intended to provide a
top-down “service based” approach, which means
that the service definition (or service contract) be-
comes key and needs to be available to the client
at design time. This requires a single “agreed”
service definition model, in the form of a fully ap-
proved industry standard specification.
2. Even though the SOA4HL7 profile has separated
the message definition from the service defini-
tion, a valuable input from the Healthcare Ser-
vices Specification Project (HSSP), it still lacks
2
http://hssp.wikispaces.com/
WEBIST 2009 - 5th International Conference on Web Information Systems and Technologies
160
the separation of the “processes” from the ser-
vices. This separation is important because each
healthcare enterprise differ in their process mod-
els even if they follow same standard.
SOA-based enterprises expose their external be-
havior (public) without revealing the internal func-
tionality or behavior (private). Such enterprise ser-
vices interact with each other according to their
behavioral description (externally and/or internally).
We describe such behaviors as interaction behaviors.
In this regard, the separation of interaction behavior
(e.g. HL7 message exchange pattern
3
) into a process
(orchestration and/or choreography) layer is required
to enable control and resolve the heterogeneity of in-
teraction behavior. The semantic description of inter-
action behavior is called behavioral semantics. This
behavioral semantics is the formal description which
defines a service’s external (public) and internal (pri-
vate) behavior. The external behavior describes a pro-
tocol that can be used by a client to consume the ser-
vice functionality. The internal behavior describes a
workflow, i.e., how the functionality of the service is
aggregated out of other services (Vitvar et al., 2008).
In our approach, a behavioral ontology is being de-
veloped for the semantic description of a service’s ex-
ternal behavior and functional ontology for internal
behavior. Based on the above discussion PPEPR ad-
dresses the following integration requirements:
1. Identifies the “semantic gap” between and within
SOA, HL7 WS and SOA profiles.
2. Applies ontologies (message, functional, be-
havioural) to resolve heterogeneity between mes-
sage, service, and process definitions.
3. Provides a healthcare standard based flexible ar-
chitecture that includes top-down and bottom-up
development methodologies.
4. Follows a semi-automatic integration approach,
where ontologies (schema level) are constructed
and mapped at design time to be mediated at run-
time (instance level).
5. Design and provide ontological reference to pub-
lic (choreography) and private (orchestration) be-
havioral descriptions of healthcare services to re-
solve heterogeneity between process models.
6. Reduces the amount of mappings between het-
erogenous messages, as compared to existing syn-
tactic integration platforms.
7. Enables the “separation of concern”, between
healthcare message, service, and process.
3
http://www.w3.org/TR/wsdl20-adjuncts/#meps
3 sSOA FOR EPR INTEGRATION
Healthcare is a complex domain, comprising ven-
dors, standards, legacy systems, and information sys-
tems which differ inherently from one another. Our
core solution lies in enabling semantic interoperabil-
ity between existing and new EPR systems. PPEPR
is based on the design principles of a semantic SOA
Reference Architecture and is built around semantic
Web service technology(Vitvaret al., 2007). PPEPR’s
architecture considers three types of integrations be-
tween EPRs based on their Web service capabilities
(or lack thereof).
EPR (non-Web service) ↔ EPR ( non-Web ser-
vice). This type of interaction is focussed on exist-
ing EPRs, which are mostly HL7 v2.x based.
EPR (non-Web service) ↔ Web Service EPR.
This type of integration is the most complex(e.g. HL7
2.x ↔ HL7 v3 ), since EPRs (non-Web services) are
required to communicate with the other EPRs (Web-
services).
Web Service EPR (1) ↔ Web Service EPR (2).
This type of integration offers the best interoperabil-
ity solution by achieving the full potential of semantic
Service-oriented Architecture (sSOA).
A detailed description of PPEPR’s architecture
and its functioning(Sahay et al., 2008; Fox et al.,
2008) is outside the scope of this paper. In this
paper, our main focus is to present design and de-
velopment methodologies for associating semantics
with HL7’s message, service, and process definitions
in service-oriented environment. The details of se-
mantic Web service technologies [Web service ex-
ecution environment (WSMX), Web service model-
ing language (WSML), Web service modeling toolkit
(WSMT)] and the underlying conceptual framework
Web service modeling ontology (WSMO)(Roman
et al., 2005; Bussler et al., 2002) are outside the scope
of this paper.
3.1 Semantics for Messages
Figure 1 describes how ontologies are grounded (low-
ering/lifting) to and from XML (Schema & Instance)
and mediated by PPEPR. The grounding (lower-
ing/lifting) task at runtime (instance level) is per-
formed by PPEPR’s adapter framework and media-
tion by data mediator. Currently PPEPR can process
messages in two formats, e.g., EDI and XML. The
adapter framework stores the grounding rules, i.e.,
XSLTs
4
developed at design-time for each message.
4
http://www.w3.org/TR/xslt
SEMANTIC SERVICE-ORIENTED DESIGN AND DEVELOPMENT METHODOLOGY FOR ENTERPRISE
HEALTHCARE INTEGRATION
161
WSML
WSML
HL7v3 XML/EDI
PPEPR
HL7 v3 XML Schema
OWL OWL
HL7v2 XML Schema
Schema
Level
WSML
HL7v2 XML/EDI
WSML
Instance
Level
Adapter
Framework
Adapter
Framework
Figure 1: Ontologizing, mapping (Schema level) and medi-
ating (Instance level) HL7 messages.
HL7 messages are uniquely defined by message-
ids and the adapter uses these message-ids to iden-
tify and process each message at run-time. In fig-
ure 1 schema level integration (grounding & ontology
mapping) is performed at design time and the instance
level is performed at run time. To mediate a source to
target message instance PPEPR requires source/target
ontologies and mapping definitions defined at schema
level. Section 4 describes the PPEPR’s methodology
for developing, optimising HL7(v3 & v2) and map-
ping domain ontologies from message ontologies.
3.2 Semantics for Service & Process
Definitions
As discussed above, PPEPR’s semantic Web ser-
vice technologies are based on the WSMO frame-
work(Roman et al., 2005). For a service’s external be-
havior, WSMO defines a choreography(Cimpian and
Mocan, 2005) distinct from WS-CDL
5
(WS-CDL de-
fines a common global viewpoint of the observable
behavior of collaborating services whereas in WSMO
the choreography and orchestration is part of the in-
terface definition of a service description). In PPEPR,
the common global viewpoint is implicit as services
are based on HL7 defined message exchange patterns
and the behavioral ontology is designed for the se-
mantic description of message exchange patterns.
The internal behavior of a service is semanti-
cally described by a functional ontology. HL7 cate-
gorises healthcare events and the PPEPR functional
ontology is based on this categorisation, where each
HL7 trigger event is a Web service within PPEPR. A
functional ontology is a semantic description of HL7
based healthcare events. HL7 v2 & v3 differ syntacti-
cally in the structure of their trigger events. There-
fore, functional ontologies are created and mapped
based on their similarity. To model and execute mes-
sage exchange patterns, it is necessary to employ
a process modelling and execution standard which
is able to reference ontological elements and allow
their mapping within the model. BPEL for Seman-
tic Web Services (BPEL4SWS(Filipowska et al., ;
5
http://www.w3.org/TR/ws-cdl-10/
Nitzsche et al., 2007; Karastoyanova et al., 2008)), a
conservative set of language extensions to BPEL en-
ables the referencing of ontological elements within
a business process description. BPEL4SWS facili-
tates the orchestration of Semantic Web Services us-
ing a process based approach and is coupled with its
ontological representation which is called sBPEL. In
order to relate the semantics pertaining to one ele-
ment in the BPEL4SWS description an additional at-
tribute
modelReference
( like SAWSDL(Farrell and
Lausen, 2007) ) identifies the corresponding ontologi-
cal instance in the sBPEL process model. The PPEPR
mechanisms to discover and collaborate with services
are end-point based (known at design time) in contrast
to the WSMO goal-based mechanism.
WSDL
Semantically-enabled
service definition
(WSML)
HL7 v3
Functional Ontology
(WSML)
HL7 v2
Functional Ontology
(WSML)
Level 1
Level 2
Level 3
BPEL
Semantically-enabled
process definition
(sBPEL)
Figure 2: Ontologising healthcare service (WSDL) & pro-
cess definitions (BPEL).
Figure 2 describes the PPEPR approach for de-
veloping semantically-enabled service (WSML) and
process (sBPEL) definitions. Level 3 illustrates the
semantic descriptions (functional ontologies) of EPR
services, Level 2 illustrates the semantic definitions
of services and processes, and Level 1 is syntac-
tic definition of services (WSDL
6
) and processes
(BPEL)(Andrews et al., 2003). To integrate a new
EPR, a semantic service definition (Level 3 → Level
2, top-down) is created first whereas existing systems
are integrated in bottom-up (Level 1 → Level 2) fash-
ion. This involves a manual process of transforming
WSDL/BPEL to WSML/sBPEL. We are investigating
means to incorporate the work in(Vitvar et al., 2008)
to automate the WSDL ↔ WSML grounding task.
Grounding and invocation of services are performed
at the semantically-enabled middleware (WSMX).
PPEPR’s functional and behavioral ontologies are
designed to annotate service and process definitions.
Figure 3 shows how Web services (Order placer and
fulfiller) interfaces and internal workflows are anno-
tated by behavioral and functional ontologies. The
6
http://www.w3.org/TR/wsdl
WEBIST 2009 - 5th International Conference on Web Information Systems and Technologies
162
HL7 v3
Behavioral Ontology
HL7 v3
Functional Ontology
HL7 v2
Functional Ontology
Order Fulfiller
Web Service
Web Service Interface
(External behavior)
Business workflow
(Internal behavior)
Order Placer
Web Service
invoke receive
receive invoke
HL7 v2
Behavioral Ontology
Figure 3: Semantics for Web Service’s External and Internal
behavior.
bi-directional arrow indicates mapping between on-
tologies. Behavioral ontology provides the ontolog-
ical reference to Web service interface, i.e., public
external behavior. Functional ontology provides the
ontological reference to internal workflows of order
placer and fulfiller.
Figure 4 shows the choreography between the
three actors of the PPEPR, where the Order placer
(General Practitioner EPR) initiates the lab order ful-
filment request. The request activates with a trigger
event “Placer order activate” which maps to a simi-
lar trigger event OML
ˆ
021 (in case GP EPR (order
placer) is HL7v2 compliant). Order fulfiller (Hos-
pital Lab EPR) sends the confirmation receipt of an
order followed by a trigger event (“filler promise ac-
tivate(HL7v3)” or “ORU
ˆ
022(HL7v2)”) that sends a
promise message (which can also be rejected) to ful-
fill the order. The final two messages are the lab test
results sent followed by the confirmation from the or-
der receiver (Hospital EPR) and order placer (General
Practitioner EPR).
Order Placer
Order Fulfiller
Order Fulfillment Request
Order Confirm Response
Promise Order Fulfillment
Promise Confirm Response
Result Complete
Result Confirmation Response
Order Reciever
Result Complete
Result Confirmation Response
Placer Order
Activate
Filler Promise
Activate
Result Event
Complete
OML^O21
ORU^O22
ORU^RO1
Mapping
Mappi
ng
Message
HL7 v3 trigger event
HL7 v2 trigger event
Figure 4: Choreography[Lab Test Order] between Order
Placer, Order Fulfiller and Order Receiver.
As we discussed above, HL7 not only defines the
message content, but also the business logic (HL7
trigger events) to achieve certain functionality in the
health care domain.
Figure 5 shows the process models of the order
placer, fulfiller, and receiver required to achieve the
actual healthcare process. It is sufficient if three ac-
tors, the process placer, the process fulfiller, and the
process receiver model and execute a process accord-
ing to the message exchange patterns defined in HL7
Figure 5: Business Process Models
ABC
for Order Placer,
Fulfiller, and Receiver in a HL7 Lab Test Order Request.
and shown in figure 4.
A detailed description of BPEL4SWS is outside
the scope of this paper. In this section, our focus is
around PPEPR’s integration requirements at the ser-
vice and process levels and how BPEL4SWS resolves
heterogeneity among various process models even if
they implement a specific healthcare standard.
4 DEVELOPMENT
METHODOLOGY
Figure 6 shows the development methodology for
HL7 (v3 & v2) domain ontologies and their map-
pings. The methodology is divided into levels 1-3
(bottom-up)and levels 4-3 (top-down), where it meets
at level 3. Table 1 shows the mapping between ar-
tifacts of both the HL7 versions. The Data Types,
Segments, Data fields, and messages are mapped to
equivalent HL7 v3 artifacts.
Table 1: Mapping HL7 v2 and HL7 v3.
HL7 v2 HL7 v3
Data Type Data Type
Segment Class
Message Class
Data Fields Class Attribute
Initially our approach for developing semanti-
cally - enabled messages, service, and process def-
initions was based on HL7’s message specifications
and where all information related to message, service
and process are tied together in message definition.
This approach required that our previous approach to
be ”bottom-up” which means ontologies were devel-
oped from the existing HL7 messages (XML/XML
Schema).
Our experience in PPEPR has told us that devel-
oping ontologies in a bottom-up fashion causes rep-
etition in concepts and mapping rules. However, the
bottom-upapproach is still needed to connect with ex-
isting healthcare systems. HL7 profiles (Web-Service
SEMANTIC SERVICE-ORIENTED DESIGN AND DEVELOPMENT METHODOLOGY FOR ENTERPRISE
HEALTHCARE INTEGRATION
163
HL7 v3 XSD(1) HL7 v3 XSD(2) HL7 v2 XSD(3) HL7 v2 XSD(4)
Message
Ontology1
(WSML)
Message
Ontology2
(WSML)
Message
Ontology3
(WSML)
Message
Ontology4
(WSML)
Optimise & Merge
ontologies
Domain
Ontology
HL7 v3
(WSML)
Domain
Ontology
HL7 v2
(WSML)
HL7 Data type
Ontology (WSML)
HL7 Vocabularies
Ontology (WSML)
Level 1
Level 2
Level 4
Level 3
Figure 6: Ontologising method for HL7 messages.
and SOA4HL7) open up the possibility of construct-
ing ontologies first (top-down) for annotating mes-
sage, service and process definitions. The major
benefit of including both the approaches (top-down/
bottom-up) is 50 percent reduction in the size of on-
tologies and number of mapping rules.
In figure 6 ontologies at level 4 (HL7 data types
and vocabularies) were created first (top-down) as
they are context-independent (deployment environ-
ment) and referenced by HL7 messages. All messages
at level 1 are transformed to equivalent WSML rep-
resentation. During the first stage of PPEPR devel-
opment level 1 and level 2 were involved, then later
we included the optimisation and merge processes, in-
volving levels 3 and 4.
For the functional and behavioural ontologies, our
development approach is top-down, since the na-
ture of functional and behavioural ontologies is quite
different from message ontologies. For example,
messages are XML schema based and that involves
various transformations from syntactic to semantic
format and vice-versa, however functional and be-
havioural ontologies are mostly used for annotating
semantically-enabled service (WSML), and process
definitions(sBPEL) which are already in semantic for-
mat. In figure 2 transformation from level 1 to 2 is a
manual task at the moment, and we are investigating
means to incorporate the work in(Vitvar et al., 2008)
to automate the WSDL ↔ WSML grounding task.
A detailed description of PPEPR’s HL7 (v3 & v2)
message development is outside the scope of this pa-
per. This section focus more on domain ontology de-
velopment from messages.
5 PPEPR ASSESSMENT
The following parameters are used to measure the im-
pact of Semantics within PPEPR and effectiveness of
PPEPR as an integration platform :
1. Design-Time
(a) Modeling HL7 message: The time taken for
modelling HL7 ontologies, creating transfor-
mation rules (e.g. XSLT), and mapping def-
initions takes on average 1.5 days. A typi-
cal HL7 engine takes 0.5 days for mapping
(syntactic). Similarly, PPEPR also takes 0.5
days for mapping (semantic). Therefore, ex-
tra work using PPEPR is 1 day for ontolog-
ical modelling. The measurement was based
on developers-recorded observations with good
level of knowledge in HL7 and semantic tech-
nology tools. Each message within HL7 v3
consist of 49-51 ontological concepts. Each
message within HL7 v2 consist of 36-40 onto-
logical concepts. There are 102 mapping rules
between ontologicalconcepts of HL7 (v3 & v2)
and on average similar number of rules are be-
tween other messages of each version. About
230-245 types of messages are contained in
each version of the HL7 standard.
(b) Syntactic vs. Semantic Mapping: Syntactic
mapping is predominantly based around the
XML/XML Schema level of expressivity. Due
to the inherent nature of XML/XML Schema,
mappings are more at an implementation level
and that causes a significant increase in amount
of mappings. In PPEPR mappings are at the se-
mantic(ontological)level which by nature maps
two equivalent elements (concepts) at a higher
level. The results have shown that the num-
ber of mappings reduced by up to 50 percent-
PPEPR’s major milestone.
2. Run-Time
(a) Execution-time: The total message exchange
time [message transformation, mediation and
transmission] measured between two EPRs on
typical broad-band connection is 2-3 seconds.
(b) Transformation: During the first stage of
PPEPR development we tested the correctness
of message transformation. The purpose of this
test is to ensure that transformation (lifting/low-
ering) process is not losing the original message
content and structure.
(c) Stability: In 3 months 250 messages has been
exchanged on a PPEPR prototype with 100 per-
cent success rate.
WEBIST 2009 - 5th International Conference on Web Information Systems and Technologies
164
PPEPR can work as a standalone system directly in-
terfacing with EPR systems or can be used as an add-
on to existing HL7 integration engines. The PPEPR
software consists of two parts: The design-time and
the runtime. The design-time portions of the system
are used when installing PPEPR and configuring the
various EPR systems which are to be made interoper-
able.
6 RELATED WORKS
COCOON (Valle et al., 2005)
7
and ARTEMIS
(Bicer et al., 2005; Valle et al., 2005)
8
are 6th Frame-
work E.U projects aimed at setting up semantics-
based healthcare information infrastructure and de-
veloping semantic Web Services based Interoperabil-
ity framework for the healthcare domain. The ma-
jor differences between these eHealth projects and
PPEPR are:
1. PPEPR requires no changes to exiting EPRs.
2. Others projects are Web-scale projects. The major
focus of PPEPR is to ease the integration burden
of healthcare enterprises. Additionally, PPEPR’s
architecture is flexible enough to include Web-
scale integration.
3. Others projects employ primarily top-down ap-
proaches as far as semantics (ontology develop-
ment) for service oriented architecture is con-
cerned. PPEPR incorporates both the methodolo-
gies (top-down/bottom-up).
4. PPEPR defines the clear ”separation of concerns”
for messages, services and healthcare process
model.
5. PPEPR employs behavioral semantics to resolve
behavioral heterogeneity of interacting healthcare
services.
6. PPEPR ontologies are semantically interoperable,
means that it can be easily used in other SWS
frameworks like SAWSDL.
7. PPEPR ontologies are in WSML format and they
are lightweight. It uses only the subset of WSML
features that can be easily converted to other se-
mantic languages [e.g. RDF/RDFS
9
, OWL
10
]
without losing the semantics. The major motiva-
tion behind this is to be interoperable with other
standard semantic Web languages.
7
http://www.cocoon-health.com/
8
http://www.srdc.metu.edu.tr/Webpage/projects/artemis
9
http://www.w3.org/RDF/
10
http://www.w3.org/2007/OWL/wiki/OWL Working Group
RIDE
11
and SemanticHEALTH
12
are E.U
roadmap projects with Special Emphasis on Seman-
tic Interoperability. PPEPR has been influenced by
the RIDE and SemanticHEALTH guidelines to design
and develop a semantic solution to a core eHealth in-
teroperability problem.
7 CONCLUSIONS
As we have discussed above, healthcare is a com-
plex domain and any integration system, such as
PPEPR, which connects healthcare enterprise appli-
cations must facilitate heterogeneous healthcare sys-
tems at all levels - data, services, processes, health-
care vendors, standards, legacy systems, and new in-
formation systems, all of which must interoperate to
provide healthcare services.
In this paper, we describe the need of semantics
in a service-oriented architecture (SOA) based health-
care integration system. This paper also presents
our approach to include HL7 profiles (Web-Service
and SOA4HL7) for ontologising message, service
and process definitions, now we are able to deal
with integration issues at separate levels. We anal-
yse the integration requirements of HL7 compliant
healthcare enterprises at message, service and pro-
cess levels. We present the ontology development
methodology that includes the top-down and bottom-
up approaches to meet the enterprise integration re-
quirements. The paper describes the latest results
in the development of PPEPR, an integration sys-
tem that connects enterprise healthcare applications
at all levels (message, service, process, non-Web ser-
vice, etc.). PPEPR’s architectural and ontological de-
signs are domain based. These designs and ontolo-
gies include both standard based ontologies (message,
functional, and behavioural) and the definition of ap-
proachesused to developthem. PPEPR ontologies are
lightweight to be interoperable with other semantic
languages and semantic Web service (SWS) frame-
work.
In our future work we plan to focus more on
optimizing ontologies. This will have the result of
reducing the size of ontologies and mapping def-
initions. We see this as PPEPR’s core strength
compared to syntactic integration solutions. We
plan to automate the grounding tasks (from XM-
L/XMLSchema/WSDL to WSML and back) for both
the HL7 versions (v2 and v3). In addition, we plan to
incorporate uses cases with more complex HL7 mes-
sage exchange patterns within PPEPR.
11
http://www.srdc.metu.edu.tr/Webpage/projects/ride/
12
http://www.semantichealth.org/
SEMANTIC SERVICE-ORIENTED DESIGN AND DEVELOPMENT METHODOLOGY FOR ENTERPRISE
HEALTHCARE INTEGRATION
165
ACKNOWLEDGEMENTS
We would like to thank Waseem Akhtar, James Coo-
ley, and Armin Haller for their comments and input to
this paper. The work presented in this paper has been
funded in part by Science Foundation Ireland under
Grant No. SFI/08/CE/I1380 (Lion-2) and the Enter-
prise Ireland under Grant No. CFTD 2005 INF 224
(SAOR).
REFERENCES
Andrews, T., Curbera, F., Dholakia, H., Goland, Y., Klein,
J., Leymann, F., Liu, K., Roller, D., D.Smith, Thatte,
S., Trickovic, I., and Weerawarana, S. (2003). Busi-
ness process execution language for web services ver-
sion 1.1. OASIS.
Bicer, V., Kilic, O., Dogac, A., and Laleci, G. B. (2005).
Archetype-Based Semantic Interoperability of Web
Service Messages in the Health Care Domain. Int’t
Journal on Semantic Web and Information Systems,
1(4):1–22.
Bussler, C., Fensel, D., and Maedche, A. (2002). A Con-
ceptual Architecture for Semantic Web enabled Web
Services. SIGMOD Rec., 31(4):24–29.
Cimpian, E. and Mocan, A. (2005). WSMX Process Medi-
ation Based on Choreographies. In 1st International
Workshop on Web Service Choreography and Or-
chestration for Business Process Management, Nancy,
France. IEEE Computer Society.
Farrell, J. and Lausen, H. (2007). Semantic Annotations for
WSDL and XML Schema. W3C Recommendation.
Filipowska, A., Haller, A., Kaczmarek, M., Lessen,
T. V., Nitzsche, J., and Norton, B. Process On-
tology Language and Operational Semantics for Se-
mantic Business Processes. BPEL4SWS specifica-
tion, Available at
http://www.ip-super.org/res/
Deliverables/D1.3.pdf
.
Fox, R., Sahay, R., and Hauswirth, M. (2008). PPEPR for
Enterprise Healthcare Integration. In Proceedings of
the eHealth 2008 Conference, City University, Lon-
don EC1. Springer CCIS.
Honey, A., Dutta, A., Porrasmaa, J., Mykkanen, J., Connor,
K., Kumar, M., and Stevens, R. Service Oriented
Architecture and HL7 v3 Methodology. Available
at
http://www.hl7.org/v3ballot2008jan/
html/infrastructure/soa4hl7/SOA4HL7_
Methodology_final.pdf
.
Iakovidis, I., Dogac, A., Purcarea, O., Comyn, G., and
Laleci, G. B. Interoperability of eHealth Systems -
Selection of Recent EU’s Research Programme De-
velopments. In Proc. of CeHR: International Confer-
ence 2007, eHealth: Combining Health Telematics,
Telemedicine, Biomedical Engineering and Bioinfor-
matics to the Edge, Regensburg, Germany.
Karastoyanova, D., van Lessen, T., Leymann, F., Ma, Z.,
Nitzsche, J., Wetzstein, B., Bhiri, S., Hauswirth, M.,
and Zaremba, M. (2008). A reference architecture
for semantic business process management systems.
In Semantic Web Technology in Business Information
Systems (SWEBIS) Workshop.
Nitzsche, J., van Lessen, T., Karastoyanova, D., and Ley-
mann, F. (2007). Bpel for semantic web services
(bpel4sws). In OTM Workshops (1).
Roman, D., Keller, U., Lausen, H., de Bruijn, J., Lara, R.,
Stollberg, M., Polleres, A., Feier, C., Bussler, C., and
Fensel, D. (2005). Web service modeling ontology.
Applied Ontology, 1(1):77–106.
Ruggeri, R., de Graauw, M., Kaler, C., Cabrera, L. F.,
and Regio, M. HL7 Version 3 Standard: Trans-
port Specification - Web Services Profile, Re-
lease 2. Available at
http://www.hl7.org/
v3ballot/html/infrastructure/transport/
transport-wsprofiles.htm
.
Sahay, R., Akhtar, W., and Fox, R. (2008). PPEPR: Plug and
Play Electronic Patient Records. In Proceedings of the
23rd Annual ACM Symposium on Applied Computing,
the Semantic Web and Applications (SWA) track, For-
taleza, Cear, Brazil.
Valle, E. D., Cerizza, D., Veli, P. D. M., Yildirak, B., Gokce,
K., Laleci, B., and Lausen, H. (2005). The Need
for semantic Web Service in the eHealth. In W3C
Workshop-SWSF, Innsbruck, Austria, Position paper.
Vitvar, T., Kopecky, J., Viskova, J., and Fensel, D. (2008).
WSMO-Lite Annotations for Web Services. In The
5th European Semantic Web Conference, Tenerife,
Spain.
Vitvar, T., Mocan, A., Kerrigan, M., Zaremba, M.,
Zaremba, M., Moran, M., Cimpian, E., Haselwanter,
T., and Fensel, D. (2007). Semantically-enabled ser-
vice oriented architecture: Concepts, technology and
application. Service Oriented Computing and Appli-
cations.
WEBIST 2009 - 5th International Conference on Web Information Systems and Technologies
166