Archetype-Based Semantic Interoperability of Web Service ... · PDF fileArchetype-Based...

Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without writtenpermission of Idea Group Inc. is prohibited.

Int’l Journal on Semantic Web & Information Systems, 1(4), 1-22, October-December 2005 1

Archetype-Based SemanticInteroperability of Web Service

Messages in the Health Care DomainVeli Bicer, Middle East Technical University (METU), Turkey

Ozgur Kilic, Middle East Technical University (METU), TurkeyAsuman Dogac, Middle East Technical University (METU), TurkeyGokce B. Laleci, Middle East Technical University (METU), Turkey

ABSTRACT

In this article, we describe an infrastructure enabling archetype-based semanticinteroperability of Web Service messages exchanged in the health care domain.We annotate the Web Service messages with the OWL representation of thearchetypes. Then, by providing the ontology mapping between the archetypes, weshow that the interoperability of the Web Service message instances can be achievedautomatically. An OWL mapping tool, called OWLmt, has been developed for thispurpose. OWLmt uses OWL-QL engine, which enables the mapping tool to reasonover the source archetype instances while generating the target archetype instancesaccording to the mapping patterns defined through a GUI.

Keywords: Please provide

INTRODUCTION

Health care is one of the few do-mains where sharing information is thenorm rather than the exception (Heard,Beale, Mori & Pishec, 2003). On the otherhand, today there is no universally ac-

cepted standard for the digital represen-tation of clinical data. There is a multitudeof medical information systems storingclinical information in all kinds of propri-etary formats.

We address this interoperabilityproblem within the scope of theARTEMIS project by wrapping and ex-

2 Int’l Journal on Semantic Web & Information Systems, 1(4), 1-22, October-December 2005


posing the existing health care applicationsas Web Services. However, given thecomplexity of the clinical domain, the WebService messages exchanged have numer-ous segments of different types and op-tions. To make any use of these messagesat the receiving end, their semantics mustbe clearly defined.

In a previous effort described inDogac et al. (in press), we annotated WebServices through the reference informa-tion models of Electronic HealthcareRecord (EHR) standards. EHR standardsdefine the interfaces for clinical content ex-change. The prominent EHR standardsinclude openEHR (openEHR Community,2005), HL7 CDA (HL7 Clinical Docu-ment Architecture, 2004), and CEN TC/251 prEN 13606-1 (referred to asEHRcom) (CEN TC/251 prEN 13606-1, 2004). Although such an approach al-lowed us to achieve a certain degree ofinteroperability, there were further prob-lems to be addressed as follows:

• The reference information models ofEHRs contain generic classes ratherthan having a class for each specializedclinical concept. Therefore, given a classin source ontology, the correspondingclass in the target ontology is not clearunless the context is known. For ex-ample, an instance of an ENTRY classin EHRcom corresponds to one of theinstances of ACT or ORGANIZER orOBSERVATION or PROCEDUREclasses in HL7 CDA.

• Another problem in mapping referenceinformation models one into another isas follows: different reference informa-

tion models structure their classes dif-ferently. As an example, both CENEHRcom and HL7 CDA have a classname called SECTION, and sectionscan have nested sections. When the sec-tions of a clinical document are orga-nized differently, then generating the samehierarchy for the target domain as in thesource domain would not be correct.

In this article, we address theseproblems by using archetypes to comple-ment the work described in Dogac et al.(in press). An archetype is a reusable, for-mal expression of a distinct, domain-levelconcept such as blood pressure, physi-cal examination, or laboratory result,expressed in the form of constraints ondata whose instances conform to some ref-erence information model (Beale & Heard,2003). The reference information modelcan be CEN EHRcom (CEN TC/251prEN 13606-1, 2004), openEHR(openEHR Architecture Specifications,2005), or the HL7 CDA schema (HL7Clinical Document Architecture, 2004).

We use the Web Ontology Language(OWL) (OWL, 2004) representation ofthe archetypes to semantically annotate theWeb Service messages. We then providethe mapping between the OWL represen-tations of archetypes through an OWL on-tology mapping tool called OWLmt(OWLmt, 2005). The mapping definitionproduced by OWLmt is used by OWLmtengine to automatically transform the WebService message instances one into otherwhen two health care institutes conform-ing to different archetypes want to ex-change messages.



RELATED WORKSemantic heterogeneity occurs when

there is a disagreement about the meaning,interpretation, or intended use of the sameor related data (Sheth & Larsen, 1990).Since medical information systems todaystore clinical information about patients in allkinds of proprietary formats, there is a needto address the interoperability problem. Forthis purpose, several EHR standards thatallow the structure of clinical content for thepurpose of exchange are currently under de-velopment. A very detailed survey and analy-sis of electronic health care records is pre-sented in Eichelberg, Aden, Dogac, andLaleci (2005).

However, since there are more thanone electronic health care record stan-dards, the semantic heterogeneity prob-lem is still unavoidable among health caresystems. HL7 and openEHR offer differ-ent reference information models for thehealth care domain. For example, an in-stance of an ENTRY class in openEHRcorresponds to one of the instances ofACT, ORGANIZER, OBSERVATION,or PROCEDURE classes in HL7 CDA.

Two approaches are described inKashyap and Sheth (1996) for providinginteroperability based on ontologies. Oneis to build a common ontology; the otheris reusing existing ontologies and combin-ing them. Instead of building a commonontology, we resolve the semantic hetero-geneity among health care standards byreusing existing ontologies and combiningthem through ontology mapping, whichallows the exchange of information amonghealth care information systems conform-ing to different standards.

ARCHETYPESAND REPRESENTINGARCHETYPES IN OWL

Archetypes are constraint-basedmodels of domain entities, and each ar-chetype describes configurations of datainstances whose classes conform to a ref-erence information model. Having a smallbut generic reference information modelhelps the EHR system to handle many dif-ferent medical concepts. Yet, the smallnumber of generic concepts in the refer-ence information model is not enough todescribe the semantics of the domain-spe-cific concepts, which are describedthrough archetypes.

An archetype is composed of threeparts: header section, definition section,and ontology section. The header sectioncontains a unique identifier for the arche-type, a code identifying the clinical conceptdefined by the archetype. The header sec-tion also includes some descriptive infor-mation such as author, version, and status.The definition section contains the restric-tions in a tree-like structure created fromthe reference information model. This struc-ture constrains the cardinality and contentof the information model instances com-plying with the archetype. Codes represent-ing the meanings of nodes and constraintson text or terms, bindings to terminologiessuch as SNOMED (SNOMED ClinicalTerms, 2005) or LOINC (LOINC, 2005),are stated in the ontology section of an ar-chetype. A formal language for expressingarchetypes (i.e., Archetype Definition Lan-guage [ADL]) is described in ADL(2003).



As already mentioned, ADL special-izes the classes of the generic informationmodel by constraining their attributes. Theapplicable constraints are as follows(ADL, 2003):

• Constraints on the range of data-val-ued properties.

• Constraints on the range of object-val-ued properties.

• Constraints on the existence of a prop-erty, indicating whether the property isoptional or mandatory.

• Constraints on the cardinality of a prop-erty, indicating whether the property re-fers to a container type, the number ofmember items it must have, and theiroptionality, and whether it has a list ora set structure.

• Constraints on a property with occur-rences, indicating how many times inruntime data an instance of a given classconforming to a particular constraint canoccur. It only has significance for ob-jects, which are children of a containerproperty.

It is also possible to reuse previouslydefined archetypes and archetype frag-ments. There are two constructs for thispurpose: The first one is the use node con-struct, which is used to reference an ar-chetype fragment by a path expression.The use node references an archetypefragment within the archetype. The sec-ond one is the allow archetype construct,which is used to reference other arche-types by defining criteria for allowable ar-chetypes. As an example to an archetypedefinition in ADL, a part of Complete

Blood Count archetype definition is pre-sented in Figure 1. The complete ADLdefinition can be found in Complete BloodCount Archetype ADL Definition (2005).Here, the OBSERVATION class from thereference information model is restrictedto create Complete Blood Count arche-type by restricting its CODED TEXTvalue to ac0001 term (ac0001 term isdefined as complete blood count in theconstraint definitions part of the ADL anddeclared to be equivalent to Loinc::700-0term in the term bindings part) and by de-fining its content to be a list of Haemoglo-bin, Haematocrit, and Platelet Count testresult elements.

In ARTEMIS architecture, OWLrepresentations of the archetypes are ex-ploited. OWL describes the structure of adomain in terms of classes and proper-ties. Classes can be names (URIs) or ex-pressions. The following set of construc-tors is provided for building class expres-sions: owl:intersectionOf, owl:unionOf,owl:complementOf, owl:oneOf,owl:allValuesFrom, owl:someValuesFrom,owl:hasValue.

In OWL, properties can have mul-tiple domains and multiple ranges. Mul-tiple domain (range) expressions restrictthe domain (range) of a property to theintersection of the class expressions.

Another aspect of the language is theaxioms supported. These axioms make itpossible to assert subsumption or equiva-lence with respect to classes or properties(Baader, Horrocks, & Sattler, 2004). Thefollowing are the set of OWL axioms:rdfs:subClassOf, owl:sameClassAs,rdfs:subPropertyOf, owl:sameProperty As,



owl:disjointWith, owl:sameIndividualAs,owl:differentIndividualFrom, owl:inverseOf,owl:transitiveProperty, owl:functional Prop-erty, owl:inverse FunctionalProperty.

In HL7 Template and Archetype Ar-chitecture Version 3.0. (2003) andopenEHR Community (2005), the OWLrepresentations of reference informationmodels of archetypes are given. The firststep in representing archetypes in OWL isto construct the reference information

model of the domain in OWL. A simplealgorithm for mapping object model toOWL is given in HL7 Template and Ar-chetype Architecture Version 3.0. (2003).First, each class in the reference informa-tion model is represented as an OWL class.Second, each relationship is representedas an ObjectProperty, and each data-val-ued property is represented asDatatypeProperty in OWL. Finally, cardi-nalities of relationships and properties are

Figure 1. The ADL definition of complete blood count archetype

OBSERVATION[at1000.1] matches {-- complete blood picture name matches {

CODED_TEXT matches { code matches {[ac0001]} -- complete blood count}}

data matches { LIST_S[at1001] matches {-- battery

items cardinality matches {0..*} \epsilon { ELEMENT[at1002.1] matches {-- haemaglobin

name matches { CODED_TEXT matches {

code matches {[ac0003]} -- haemaglobin}} value matches {

QUANTITY matches { value matches {0..1000} units matches {^g/l|g/dl|.+^}}}}

ELEMENT[at1002.2] occurrences matches {0..1} matches {-- haematocrit


code matches {[ac0004]}-- haematocrit}} value matches {

QUANTITY matches { value matches {0..100} units matches {"%"}}}}

ELEMENT[at1002.3] occurrences matches {0..1} matches {-- platelet count


code matches {[ac0005]} -- platelet count}} value matches {

QUANTITY matches { value matches {0..100000} units matches {"/cm^3"}

}}}}}}}



represented by cardinality restrictions inOWL. The next step is representing arche-types in OWL, based on the reference in-formation model as described in ADL(2003) and HL7 Template and ArchetypeArchitecture Version 3.0. (2003). Asstated in HL7 Template and ArchetypeArchitecture Version 3.0. (2003), eachADL object node generates an OWL classdeclaration. Object-valued properties arerestricted through these OWL classes.

ARTEMIS SEMANTICINFRASTRUCTURE

The aim of the ARTEMIS project(ARTEMIS Consortium, 2004) is to al-low health care organizations to keep theirproprietary systems and yet expose thefunctionality of their applications throughWeb Services. ARTEMIS has a peer-to-peer infrastructure to facilitate the seman-tic discovery of Web Services and ser-vice registries (Dogac et.al., in press).

The full sharability of data and infor-mation requires two levels ofinteroperability:

• The functional (syntactic) interoperability,which is the ability of two or more sys-tems to exchange information. This in-volves agreeing on the common networkprotocols, such as Internet or ValueAdded Networks; the transport bindingsuch as HTTP, FTP, or SMTP and themessage format like ASCII text, XML(Extensible Markup Language) or EDI(Electronic Data Interchange). Web Ser-vices provide functional interoperabilitythrough well-accepted standards likeSOAP (2003) and WSDL (2005).

However, note that in order to accessand consume Web Services through pro-grams, you must know their operationaland message semantics in advance.

• Semantic interoperability is the abilityfor information shared by systems tobe understood at the level of formallydefined domain concepts so that the in-formation is computer processable bythe receiving system. In other words,semantic interoperability requires the se-mantics of data to be defined throughformally defined domain-specific con-cepts in standard ontology languages(ISO TC/215, 2003).

To provide semantic interoperabilityin ARTEMIS, the Web Services are an-notated with the following semantics:

• Operational semantics of Web Services.In order to facilitate the discovery ofthe Web Services, there is a need forsemantics to describe what the servicedoes; in other words, what the servicefunctionality semantics is in the domain.For example, in the health care domain,when a user is looking for a service toadmit a patient to a hospital, the usershould be able to locate such a servicethrough its meaning, independent ofwhat the service is called and in whichlanguage it is in. Note that WSDL (2005)does not provide this information.

• In ARTEMIS, HL7 categorization ofhealth care events are used to annotateWeb Service functionality, since HL7 ex-poses the business logic in the health caredomain. If further ontologies are devel-oped for this purpose, they easily can



be accommodated in the ARTEMIS ar-chitecture through ontology mapping.

• Message semantics of Web Services.When invoking a Web Service, there isalso a need to know the meaning asso-ciated with the messages or documentsexchanged through the Web Service.In other words, service functionality se-mantics may suffice only when all the WebServices use the same message standards.For example, a GetClinicalInformationWeb Service may include the messagesto pass information on diagnosis, aller-gies, encounters, and observation resultsabout a patient. Unless both the send-ing and the receiving ends of the mes-sage conform to the same EHR stan-dard, interoperability cannot beachieved.

ARTEMIS proposes to semanticallyenrich the Web Service messages througharchetypes. As depicted in Figure 2, throughan annotation tool provided by theARTEMIS infrastructure, the health care in-stitutes can annotate the input and outputmessages of their Web Services with arche-types. For example, Hospital A in Figure 2declares that its Web Service accepts aPatientInfo Archetype Instance based onOpenEHR RIM as an input and returns aBodyWeightAtBirth Archetype Instancebased on OpenEHR RIM as an output. Notethat the consumer application of the WebService may be compliant with another stan-dard. ARTEMIS enables the service con-sumers to speak their own language. Forthis purpose, the annotation tool enables thehealth care institutes to define their applica-tion message schemas in terms of archetypes.

For example, Hospital B in Figure 2 declaresthat its messaging structure will provide andaccept PatientInfo and BirthWeight informa-tion as archetype instances based on HL7RIM while invoking the Web Services pro-vided in the ARTEMIS network.

In the ARTEMIS architecture, theOWL representations of archetype defini-tions and instances are used. Tointeroperate the archetype instances basedon different HER standards, the ARTEMISmediator provides an OWL mapping toolcalled OWLmt. Through a graphical inter-face, OWLmt tool enables the user to de-fine the mappings between archetype defi-nitions, and the resulting mapping definitionsare stored at the mediator. When a healthcare institute wants to join the ARTEMISnetwork, they advertise their Web Servicesto the mediator by semantically annotatingthem through archetypes. When one of thehealth care institutes wishes to invoke aWeb Service provided by another institutein the ARTEMIS Network, the Web Ser-vice invocation request is delivered to themediator. The health care institute providesthe Web Service input to the mediator interms of the archetype instances it con-forms. Then the mediator invocation toolconsults the OWLmt Mapping Engine totransform the archetype instances from oneEHR reference information model standardto another, using the mapping definitionsthat previously have been generated throughthe OWLmt Mapping Definition Tool. Fi-nally, the Web Service is invoked with thearchetype instance to which the providerconforms. The output of the Web Serviceis processed in the same manner and pre-sented to the requester as an archetype in-



Figure 2. Artemis semantic architecture



stance based on the EHR standard to whichthe requester conforms. In the following sec-tions, the details of this process are elabo-rated through examples.

ARCHETYPE-BASEDINTEROPERABILITY OFWEB SERVICE MESSAGES

Since there is more than one EHRstandard such as openEHR (openEHRCommunity, 2005), HL7 CDA (HL7Clinical Document Architecture, 2004),and CEN EN 13606 EHRcom (CEN TC/251 prEN 13606-1, 2004), each withdifferent reference information models andarchetypes, annotating Web Service mes-sages with archetypes does not solve theinteroperability problem.

Therefore, we need to transform ar-chetypes of one standard into anotherthrough ontology mapping. For this pur-pose, we use the OWL representation ofboth the involved reference informationmodels and the archetypes. Then, throughan OWL ontology mapping tool that wedeveloped, called OWLmt, we map thereference information models and the ar-chetype schemas one into other. Oncesuch a mapping is achieved, OWLmt au-tomatically transforms a Web Servicemessage annotated with an archetype inone standard into another.

In this section, we explain this pro-cess through a running example. For thispurpose, we first generate the OWL de-scriptions of an archetype based onopenEHR and another one based on HL7.We then present the OWL mapping tooland depict its functionality through the run-ning example.

Example OpenEHR and HL7Archetypes in OWL

Figure 3 depicts an archetype in ADLthat represents the body weight at birthconcept. This concept is described by re-stricting the OBSERVATION class inopenEHR Reference Model.

The OWL representation of the ar-chetype in Figure 3 is presented inopenEHR Body Weight at Birth Arche-type OWL Definition (2005). In brief,each restriction on an object-valued prop-erty introduces a new class, which is asubclass of the class on which the restric-tion is defined in the ADL document. Forthe example, in Figure 3, the data prop-erty of the OBSERVATION class is de-fined as having a type HISTORY, whichis further restricted. In OWL, this restric-tion on history class is handled by intro-ducing a subclass of history called bodyweight at birth history. On the otherhand, each restriction on a data-valuedproperty either introduces a user-deriveddatatype for further restricting datatype ofthe property or produces owl:hasValueor owl:oneOf restrictions on the propertyfor restricting the value of the property toone value or set of values, respectively.Note that user-derived datatypes can berepresented in XML schema and refer-enced from the OWL representation ofthe archetype.

Figure 4 depicts the body weight atbirth ADL archetype based on the HL7Version 3 Reference Information Model,whose OWL representation is presentedin HL7 Body Weight at Birth ArchetypeOWL Definition (2005).



Figure 3. An example body weight at birth OpenEHR archetype in ADL

archetype openEHR-EHR-OBSERVATION.weight-birth.v1

specialize openEHR-EHR-OBSERVATION.weight.v1

concept [at0000.1] -- Body weight at birth

description ... definition OBSERVATION[at0000.1] matches { -- Body weight at birth data matches { HISTORY[at0002] matches { -- history events cardinality matches {1..1; ordered} matches { EVENT[at0003] matches { -- Birth data matches { Simple[at0001] matches { -- Birth simple item matches { ELEMENT[at0004.1] matches { -- Birth weight value matches { C_QUANTITY property = <"mass"> units = <"kg"> magnitude = <|0.0..10.0|> } } } } } } } } } state matches {0..1} matches { List[at0008] matches { -- state structure items cardinality matches {1..1; ordered} matches { ELEMENT[at0009] occurrences matches {0..*} matches { -- Clothing value matches { CODED_TEXT matches { code matches {[local:: at0010, -- Dressed at0011] -- Naked } assumed_value matches {"at0011"} } } } } } } other_participations matches {0..1} matches{ List [at0014] matches { -- participation structure items cardinality matches {1..1; ordered} matches { PARTIPICATION [at0012] matches{ --Baby function matches { CODED_TEXT matches { code matches { [local::at0013] -- Patient }} } } } } } } ...



Figure 4. An example body weight at birth HL7 archetype in ADL

archetype HL7-OBSERVATION.weight-birth.v1

specialize HL7-OBSERVATION.weight-birth.v1

concept [at0000.1] -- Body weight at birth

description author = <"Veli Bicer <[email protected]>"> submission = <

organisation = <"METU-SRDC"> date = <2005-01-10>

> version = <"version">

status = <"draft"> revision = <"1.0"> description("en") = <

purpose = <"Describe the observation for the body weight at birth"> use = <""> misuse = <"">

> adl_version = <"1.2"> rights = <"">

definition

Observation[at0000] matches { -- birth_weight classCode cardinality matches {1} matches {[hl7_ClassCode::OBS]} moodCode cardinality matches {1} matches {[hl7_ClassCode::EVN]} id matches {*}

code cardinality matches {1} matches {[at0001],[at0002]} confidentialityCode cardinality matches {1..*} matches {[hl7_Confidentiality::N]} uncertaintyCode matches {[hl7_ActUncertainty::N]} value cardinality matches {1} matches {/.*kg[^ ]/} hasParticipation cardinality matches {1..*} matches{ Participation matches{ hasRole cardinality matches {1..*} matches{ Patient{ classCode cardinality matches {1} matches {[hl7_ClassCode::PAT]} player cardinality matches {1..*} matches{ Person matches{ classCode cardinality matches {1} matches {[hl7_ClassCode::PSN]} }}}}}}

} ...



ONTOLOGY MAPPINGIn the Example OpenEHR and

HL7 Archetypes in OWL subsection, wepresent ADL descriptions of two arche-types. As depicted in Figures 3 and 4, thearchetypes differ in terms of structure andformat of the data they represent. The maincause of this difference is that the arche-types refer to different reference models(i.e., openEHR RIM and HL7 RIM). Thus,the interoperability between these arche-types becomes a difficult task, although theyrepresent the same concept — weight atbirth.

ARTEMIS mediator provides an on-tology mapping tool — OWLmt — thatenables us to define the mapping betweendifferent OWL schemas. In this section,we describe an ontology mapping processin OWL to achieve the interoperability be-tween the archetypes based on differentreference models. Once such a mappingdefinition is stored at the mediator, the me-diator will interoperate the Web Servicemessages represented as archetypes be-tween the health care institutes conform-ing to different EHR standards.

Ontology mapping is the processwhere two ontologies with an overlappingcontent are related at the conceptual levelto produce a mapping definition. Thesource ontology instances then are auto-matically transformed into the target on-tology instances according to the mappingdefinitions. The architecture of theOWLmt tool (see Figure 5) allows map-ping patterns to be specified through aGUI. These patterns are stored in a docu-ment called Mapping Definition. Themapping engine uses the Mapping Defini-

tion to automatically transform source on-tology instances into target ontology in-stances.

The OWLmt mapping tool has thefollowing mapping capabilities:

• Matching the source ontology classesto the target ontology classes. We havedeveloped the following four concep-tual mapping patterns to represent thematching between the classes of thesource and target ontology classes:EquivalentTo, SimilarTo, IntersectionOf,and UnionOf. The identical classes aremapped through EquivalentTo pattern.SimilarTo implies that the involvedclasses have overlapping content. As anexample, the body weight at birth classwhich is a subclass of observation classin the openEHR archetype is similar tothe birth weight, class which is inher-ited from the observation class in theHL7 archetype, since they both repre-sent the weight at birth concept. TheSimilarTo patterns in OWLmt are rep-resented in OWL (see Figure 6). Howsimilar classes are further related is de-scribed through property mapping pat-terns.The IntersectionOf pattern creates thecorresponding instances of the targetclass as the intersection of the declaredsource class instances. Similarly, theUnionOf pattern implies the union of thesource classes’ instances to create thecorresponding instances of the targetclass.In some cases, a class in a source on-tology can be more general than a classin the target ontology. In this case, the



instances of the source ontology thatmake up the instances of the target on-tology are defined through KnowledgeInterchange Format (KIF) (2005) con-ditions to be executed by the mapping

engine. As an example, assume that aSimilarTo pattern is defined between thebody weight at birth class of theopenEHR archetype and the birthweight class of HL7 archetype. The

Figure 5. Architecture of OWLmt



body weight at birth class in theopenEHR archetype has a propertystate with the cardinality of zero or one(see Figure 3). On the other hand, thecode property of the birth weight classof the HL7 archetype (see Figure 4) haseither LOINC (2005) value of 8351-9(weight at birth with clothes) or LOINCvalue of 8350-1 (weight at birth withoutclothes), depending on the value of thecode value under the state property inthe openEHR archetype. However, thecode value is mandatory in the HL7 ar-chetype, unlike the optionality of the stateproperty in the openEHR. Therefore, weadd a condition in KIF format to theSimilarTo pattern (see Figure 6) to en-sure that there exists at least one stateproperty of the body weight at birthinstance in order to map it to an instanceof birth weight class.Matching the source ontology ObjectProperties to target ontology ObjectProperties. ObjectPropertyTransformpattern is used to define the matchingfrom one or more object properties inthe source ontology to one or more ob-ject properties in the target ontology.As an example, consider the openEHR

archetype in the Example OpenEHRand HL7 Archetypes in OWL subsec-tion. According to the openEHR speci-fications (openEHR Architecture Speci-fications, 2005), the body weight atbirth class has an other participationsobject property inherited from the ob-servation class, referring to a list of theparticipation class in order to repre-sent the parties that participate in thebody weight at birth observation. Withthe help of this object property, we havedefined a path from body weight atbirth class to the PARTY REF in or-der to state the patient who is involvedin this particular observation. Likewise,in the HL7 archetype, there is also apath from the birth weight class to theperson with a set of object propertiessuch as hasParticipation, hasRole, andplayer. Although these two paths havedifferent structures and involve differentproperties (e.g., other participations andhasRole) and classes (e.g., List inopenEHR and Patient in HL7), they rep-resent the same content; that is, patientof an observation (see Figure 7). There-fore, in the mapping process, anObjectPropertyTransform pattern is

Figure 6. An example SimilarTo pattern

<SimilarTo rdf:about= "http://www.srdc.metu.edu.tr/Map#SimilarTo_1"> <similarToInput rdf:resource= "http://www.sample.org/openEHRweight-

birth#Body_weight_at_birth"/> <similarToOutput rdf:resource= "http://www.sample.org/hl7weight-birth.owl#birth_weight"/> <operationName>SimilarTo_1</operationName> <Condition>(and (rdf:type ?x

http://www.sample.org/openEHRweight-birth#Body_weight_at_birth) (state ?x ?y))

</Condition> ... </SimilarTo>



defined to match these paths to one an-other. These path expressions arestated as parameters in theObjectPropertyTransform pattern inKIF format. For example, the path be-tween the body weight at birth andPARTY REF can be represented in thesource ontology through the followingpath: (rdf:type ?x Body weight at birth)(other participations ?x ?y) (rdf:type ?yList) (items ?y ?z) (rdf:type ?z PAR-TICIPATION) (performer ?z ?k)(rdf:type ?k PARTY REF).This path corresponds to the followingpath in the target ontology: (rdf:type ?xbirth weight) (hasParticipation ?x ?y)(rdf:type ?y Participation) (hasRole ?y?z) (rdf:type ?z Patient) (player ?z ?k)(rdf:type ?k Person).Through such patterns, the OWLmtconstructs the specified paths amongthe instances of the target ontology inthe execution step, based on the pathsdefined among the instances of thesource ontology.

• Matching source ontology Data Proper-ties to target ontology Data Properties.Through the DatatypePropertyTransformpattern, the data type properties of an in-stance in the source ontology are mappedto corresponding target ontology instancedata type properties. OWLmt supportsa set of basic XPath (XQuery 1.0 andXPath 2.0, 2004) functions and opera-tors such as concat, split, and substring.In some cases, there is a further need fora programmatic approach in order tospecify complex functions (e.g., need touse if-then-else, switch-case, or for-next).Therefore, we have introduced JavaScriptsupport to OWLmt. By specifying theJavaScript to be used in theDatatypePropertyTransform pattern, thecomplex functions (enriched by the JavaSDK libraries) can be applied in the valuetransformations.As an example, the OWL representa-tions of the archetypes (see Figures 3and 4) include data type properties thatinvolve the same kind of data. For in-

Figure 7. Mapping object properties



stance, units and magnitude data typeproperties in openEHR archetype cor-respond to the value data type prop-erty in the HL7 archetype. To map thevalues stored in units and magnitudedata type properties to the value datatype property, we state a DatatypePropertyTransform pattern. This pat-tern takes the paths of the data typeproperties units and magnitude in KIFformat as input parameters and relatesthem to the value data type property.The basic concat operation is sufficientto concatenate the values stored in theunits and magnitude and to assign theresult to the value through the mappingengine.There is also a relation between the codeproperty, which states the clothing sta-tus of a patient in openEHR archetype,and the code property of the birthweight in the HL7 archetype. Based onthe value of the code (e.g., naked ordressed) in openEHR archetype in-stance, the code data type property inHL7 archetype has either the LOINCvalue 8351-9 or the LOINC value8350-1. To achieve such a mapping, theJavaScript code (see Figure 8) can beused in the DatatypePropertyTransformpattern.

Once the mapping between two on-tologies is specified by using the MappingGUI, it can be serialized as a MappingDefinition in order to be used in the ex-ecution step as presented in the Trans-forming the Archetypes Instances sub-section. The Mapping Definition itself isan OWL document whose structure isspecified through Mapping Schema. In themapping definition, the patterns are usedto define the mappings among the classesand properties of the source and targetontology. The patterns are also specifiedas OWL class instances in the MappingSpecification. As an example, SimilarTopattern is shown in Figure 6.

However, the use of OWL as a map-ping definition language has some short-comings, as stated in Brujin and Polleres(2004). One of the shortcomings of usingOWL as a mapping definition language isits tight coupling between the source andthe target ontologies. A mapping defini-tion needs to import other related (sourceand target) ontologies with owl:import.This results in a tight coupling between on-tologies, which is undesirable, because itmakes one ontology dependent on anotherin the sense that axioms and definitions inone ontology use classes and propertiesfrom the other ontology. This can result in

Figure 8. An example JavaScript

function copy_code(openEHR_code) {

if(openEHR_code.equals("Naked")) return "8351-9"; else if(openEHR_code.equals(Dressed") return "8350-1";

}



such things as the necessity to use the otherexternally specified ontology in order toperform certain local reasoning tasks(Brujin & Polleres, 2004).

Therefore, rather than using pureOWL, we specify queries in our mappingdefinition in OWL-QL KIF syntax whichare then executed by the mapping engine.Furthermore, the value transformationsalso should be expressed in the MappingDefinition. We specify the value transfor-mations as JavaScript strings of theDatatypePropertyTransform pattern.

Transforming theArchetype Instances

Consider the example presented inFigure 2. Hospital B, using the archetypeinstances based on HL7, wishes to invokethe Web Service provided by Hospital Ain order to receive the BirthWeight infor-mation for a patient. Through the Web Ser-vice Invocation Interface provided by theARTEMIS peer, Hospital B provides theWeb Service input as PatientInfo arche-type instance based on HL7 RIM andwishes to receive the result as aBirthWeight archetype instance againbased on HL7 RIM. Note that HospitalA has declared to the mediator that itsWeb Service exchanges are based onOpenEHR archetypes. When the media-tor invokes this Web Service on behalf ofHospital B, the invocation tool in the me-diator consults to the OWLmt MappingEngine for transforming the archetype in-stances from source ontology to the tar-get ontology. In this section, we detail howthis instance transformation is achievedthrough the OWLmt mapping engine.

The OWLmt mapping engine cre-ates the target archetype instances inOWL, using the mapping patterns in theMapping Definition and the instances ofthe source archetype. It uses OWL QueryLanguage (OWL-QL) (Fikes, Hayes, &Horrocks, 2003) to retrieve required datafrom the source ontology instances. Whileexecuting the class and property mappingpatterns, the query strings defined throughthe mapping GUI are sent to the OWL-QL engine with the URL of the sourceontology instances. The query engine ex-ecutes the query strings and returns thequery results.

During this process, OWL-QL usesthe reasoning capabilities of Java TheoremProver (JTP) (2005) to infer new facts fromthe source ontology and use them in orderto construct the target ontology instance.To illustrate this, consider the archetypesintroduced in the Example OpenEHR andHL7 Archetypes in OWL subsection. Therange of the state object property of bodyweight at birth class in openEHR arche-type is the state structure, which is a sub-class of list and involves a restriction. Statestructure in OWL is depicted in Figure 9.

The items object property of statestructure is involved in an owl:allValuesFromrestriction. Its range is stated to be the cloth-ing class, as depicted in Figure 9.

The mapping engine uses the informa-tion in the source ontology to infer newknowledge at instance level. This new knowl-edge lets OWLmt obtain more accuratequery results in the execution step. In therunning example, the following rules are usedto derive the fact that InferredInstance is aninstance of the clothing: (rdf:type



MyStateStructure state_structure)(rdfs:subClassOf state_structureRestrictionOnitems) -> (rdf:typeMyStateStructure RestrictionOnitems).

This rule derives the fact thatMyStateStructure has rdf:type ofRestrictionOnitems. With the derivation ofthis fact, all the predicates of the followingrule become true: (owl:onPropertyRestrictionOnitems items) (owl:allValuesFrom RestrictionOnitemsClothing)(rdf:type MyStateStructureRestrictionOnitems) (items MyStateStructure

MyClothingType) -> (rdf:typeMyClothingType Clothing).

According to the data obtained byquerying the source ontology instance, theOWLmt mapping engine executes the con-ceptual mapping patterns to create the cor-responding instances in the target ontol-ogy. The conditions specified for each con-ceptual mapping pattern also are appliedto ensure the accuracy in the mapping pro-cess. In this step, the instances that do notsatisfy a particular condition in the patternare discarded.

Figure 9. The state_structure class

<owl:Class rdf:ID="state_structure"> <rdfs:subClassOf rdf:resource= "openEHR:List"/> <rdfs:subClassOf>

<owl:Restriction rdf:ID="RestrictionOnitems"> <owl:allValuesFrom>

<owl:Class rdf:ID="Clothing"> <rdfs:subClassOf rdf:resource= "openEHR:ELEMENT"/>

.... </owl:Class>

</owl:allValuesFrom> <owl:onProperty>

<owl:ObjectProperty rdf:resource= "openEHR:items"/> </owl:onProperty>

</owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf>

<owl:Restriction>``birth\_weight" <owl:onProperty>

<owl:ObjectProperty rdf:resource="openEHR:items"/> </owl:onProperty> <owl:minCardinality rdf:datatype= http://www.w3.org/2001/XMLSchema#int"> 0</owl:minCardinality> <owl:maxCardinality rdf:datatype=http://www.w3.org/2001/XMLSchema#int"> 1</owl:maxCardinality>

</owl:Restriction> </rdfs:subClassOf>

</owl:Class>

Figure 10. The openEHR archetype instance

<state_structure rdf:ID="MyStateStructure"> <openEHR:items rdf:resource="#InferredInstance"/>

</state_structure>



As an example, when the mappingengine executes the SimilarTo pattern (seeFigure 6), the body weight at birth in-stance is obtained (see Figure 11) as aresult of the query of the source instance.The mapping engine then creates the cor-responding birth weight instance (seeFigure 12) in the target ontology.

After the creation of the class instancesin the target ontology, the property mappingpatterns are applied to create the object anddatatype properties for the instances in thetarget ontology. During the mapping of thedatatype properties, the value transforma-tions specified in the corresponding patternsare applied. OWLmt mapping engine usesJavaScript in order to transform the valuesfrom the source ontology to the target on-tology programmatically. In order to achievethis, it sends the JavaScript specified in the

corresponding property mapping pattern tothe JavaScript Interpreter (RHINO, 2005)with the data obtained from the source on-tology instance. The result from the execu-tion of the JavaScript is set as the value ofthe datatype property in the target ontology.For example, as a result of executing theDatatypePropertyTransform pattern, whichincludes the JavaScript (see Figure 8), thecode datatype property with LOINC codeof 8351-9 (see Figure 12) is created in thetarget instance according to the naked valueindicated in openEHR instance, as depictedin Figure 11.

As a result of these steps, the arche-type instance based on the source RIM istransformed to the archetype instance,based on the target RIM, providing theinteroperability of the Web Services ex-changing such messages.

Figure 11. Source instance

<Body_weight_at_birth rdf:ID="Instance1"> <openEHR:state>

<state_structure rdf:ID="Instance2"> <openEHR:items rdf:resource="#Instance3"/>

</state_structure> </openEHR:state>

... </Body_weight_at_birth> <Clothing rdf:ID="Instance3">

<openEHR:value> <openEHR:CODED_TEXT rdf:ID="Instance4">

<openEHR:code>Naked</openEHR:code> </openEHR:CODED_TEXT>

</openEHR:value> </Clothing>

<birth_weight rdf:ID="TInstance1"> <HL7:code>8351-9</HL7:code>

... </birth_weight>

Figure 12. Target instance



CONCLUSION ANDFUTURE WORK

Web Services have the capacity tobring many advantages to the health caredomain, such as seamless integration ofdisparate health care applications con-forming to different and, at times, com-peting standards. Also, Web Services willextend the life of the existing health caresoftware by exposing previously propri-etary functions as Web Services.

To the best of our knowledge, theARTEMIS project is the first initiative touse semantically enriched Web Servicesin the health care domain. In fact, only veryrecently did Web Services start to appearin the medical domain. An important in-dustry initiative to use Web Services is In-tegrating the Health care Enterprise (IHE)(IHE IT Infrastructure Integration Profiles,2003). IHE has defined a few basic WebServices, such as Retrieve Information forDisplay Integration Profile (RID). Yet,since IHE does not address semantic is-sues, in order to use the IHE Web Ser-vices, it is necessary to conform to theirexact specification by calling the Web Ser-vices with the names they have specifiedand by providing the messages as in-structed in its specification.

However, given the complexity of thehealth care domain and the proliferationof standards and the terminologies to rep-resent the same data, semantic annotationof the Web Service messages is essential.

In this article, we describe howinteroperability among different health caresystems conforming to different EHR stan-dards can be achieved by semantically an-notating the Web Service messages

through archetypes. An archetype is a setof constraints on the generic EHR refer-ence information model, which ensuresthat clinical concepts are correctly repre-sented without actually storing them, sincethere are very many (more than 300,000)clinical concepts. The semantic differencesamong the archetypes are then handledthrough an OWL mapping tool that is de-veloped.

As a future work, we plan to seman-tically annotate the IHE Web Services thatcurrently are being integrated into theARTEMIS infrastructure. How IHE WebServices are integrated to the ARTEMISarchitecture is described in Aden andEichelberg (2005).

ACKNOWLEDGMENTThis work is supported by the Eu-

ropean Commission through IST-1-002103-STP ARTEMIS project and inpart by the Scientific and Technical Re-search Council of Turkey (TÜB0TAK),Project No: EEEAG 104E013

REFERENCESAden, T., & Eichelberg, M. (2005).

Cross-enterprise search and accessto clinical information based on IHEretrieve information for display. Pa-per presented at EuroPACS-MIR2005.

Archetype definition language 1.2 draft.(2003). Australia: Ocean Informatics,the OpenEHR Foundation.

ARTEMIS Consortium. (2004). TheARTEMIS Project. Retrieved fromhttp://www.srdc.metu.edu.tr/webpage/projects/artemis



Baader, F., Horrocks, I., & Sattler, U.(2004). Handbook on ontologies.Description Logics.

Beale, T., & Heard, S. (2003). Arche-type definitions and principles (Re-vision 0.5). Australia: OceanInformatics, the OpenEHR Foundation.

Brujin, J., & Polleres, A. (2004). Towardsan ontology mapping specificationlanguage for the Semantic Web(DERI Tech. Rep.).

Complete Blood Count Archetype ADLDefinition. (2005). Retrieved from http://my.openehr.org/wsvn/knowledge/ar-chetypes/dev/adl/openehr/ehr/entry/obse rva t ion /openEHR-EHR-OBSERVATION.cbc.v1.adl?op=file&rev=0&sc=0

CEN TC/251 prEN 13606-1, Healthinformatics electronic health recordcommunication. Part 1: Referencemodel, draft for CEN enquiry. (2004).Brussels, Belgium: CEN/TC 251 HealthInformatics, European Committee forStandardization.

Dogac, A., et al. (in press). ARTEMIS:Deploying semantically enriched WebServices in the health care domain. In-formation Systems Journal.

Eichelberg, M., Aden, T., Dogac, A., &Laleci, G. B. (2005). A survey andanalysis of electronic health carerecord standards. Unpublished manu-script.

Fikes, R., Hayes, P., & Horrocks, I.(2003). OWL-QL: A language for de-ductive query answering on the Se-mantic Web (Tech. Rep.). Stanford,CA: Stanford University, KnowledgeSystems Laboratory.

Heard, S., Beale, T., Mori, A. R., &Pishec, O. (2003). Templates and ar-chetypes: How do we know what weare talking about (Tech. Rep.).

HL7 Body Weight at Birth ArchetypeOWL Definition. (2005). Retrievedfrom http://www.srdc.metu.edu.tr/~veli/hl7_Weight_Birth_Archetype.owl

HL7 Clinical Document Architecture, Re-lease 2.0 (HL7 v3 Standard). (2004).Ann Arbor, MI: Health Level Seven.

HL7 Template and Archetype Architec-ture Version 3.0 (Tech. Rep.). (2003).Health Level Seven Template SpecialInterest Group.

IHE IT Infrastructure Integration Profiles.(2003). The Key to Integrated Sys-tems: Integration Profiles. OakBrook, IL: Integrating the Health CareEnterprise.

ISO TC/215. (2003). Health Informatics— Requirements for an ElectronicHealth Record Architecture (ISOTechnical Specification 18308). Inter-national Organization for Standardiza-tion, Health Informatics.

JTP. (2005). Java Theorem Prover. Re-trieved from http://www.ksl.stanford.edu/software/JTP/

Kashyap, V., & Sheth, A. P. (1996). Se-mantic and schematic similarities be-tween database objects: A context-based approach. VLDB Journal, 5(4),276-304.

KIF. (2005). Knowldge interchange for-mat. Retrieved from http://logic.stanford.edu/kif/kif.html

LOINC. (2005). Logical observation iden-tifiers names and codes (Version 2.15).Indianapolis, IN: Regenstrief Institute.



Asuman Dogac is a full professor at the Computer Engineering Dept., Middle EastTechnical University (METU), Ankara, Turkey and the founding director of theSoftware Research and Development Center (SRDC), METU. Her research interestsinclude health care informatics, Web Services, and semantic interoperability.

Gokce B. Laleci is a PhD candidate at METU, Computer Engineering Dept., anda senior researcher at SRDC. Her research interests include Semantic Web, WebService technology, and health care informatics.

Veli Bicer is an MS student at METU, Computer Engineering Dept., and a seniorresearcher at SRDC. His research interests include semantic interoperability, WebService technology, and health care informatics.

Ozgur Kilic recevied a BS in computer engineering in 1998 from the BilkentUniversity. He recevied an MS in computer engineering in 2001 from the MiddleEast Technical University. He is currently a PhD student in computer engineeringat the Middle East Technical University.

openEHR Architecture Specifications.(2005). Retrieved from http://www.openehr.org/getting_started/t_openehr_primer.htm

openEHR Body Weight at Birth Arche-type OWL Definition. (2005). Retrievedfrom http://www.srdc.metu.edu.tr/~veli/openEHRweight-birth.owl

openEHR Community. (2005). Retrievedfrom http://www.openehr.org/

OWL. (2004). Web ontology language.In Proceedings of the World WideWeb Consortium.

OWLmt. (2005). OWL mapping tool. Re-trieved from http://www.srdc.metu.edu.tr/artemis/owlmt/

RHINO. (2005). JavaScript for Java.Retrieved from http://www.mozilla.org/rhino/

Sheth, A. P., & Larsen, J. (1990). Feder-ated database systems for managing dis-tributed, heterogeneous and autono-mous databases. ACM ComputingSurveys: Special Issue on Heteroge-neous Databases, 22(3), 183-236.

SNOMED Clinical Terms. (2005). Re-trieved from http://www.snomed.org/snomedct/index.html

SOAP. (2003). Simple object access pro-tocol (Version 1.2). In Proceedings ofthe World Wide Web Consortium.

WSDL. (2005). Web Service descriptionlanguage (Version 2.0). Part 0: Primer(W3C Working Draft). In Proceedingsof the World Wide Web Consortium.

XQuery 1.0 and XPath 2.0. (2004).Functions and operators (W3CWorking Draft). Retrieved from http://www.w3.org/TR/xpath-functions/

Archetype-Based Semantic Interoperability of Web Service ... · PDF fileArchetype-Based...

Documents

Transcript of Archetype-Based Semantic Interoperability of Web Service ... · PDF fileArchetype-Based...