02 Whole

University of Wollongong Thesis Collections
University of Wollongong Thesis Collection

University of Wollongong Year 
Complete interoperability in healthcare :

technical, semantic and process
interoperability through ontology
mapping and distributed enterprise
integration techniques
Amanda Joanne Ducrou
University of Wollongong
Ducrou, Amanda Joanne, Complete interoperability in healthcare : technical, semantic

and process interoperability through ontology mapping and distributed enterprise integration
techniques, Doctor of Philosophy thesis, Faculty of Informatics, University of Wollongong,
2009. http://ro.uow.edu.au/theses/3048
This paper is posted at Research Online.

COMPLETE INTEROPERABILITY IN
HEALTHCARE
Technical, Semantic and Process
Interoperability through Ontology Mapping
and Distributed Enterprise Integration
Techniques
A thesis submitted in fulfilment of

the requirements for the award of the degree
DOCTOR OF PHILOSOPHY
from
UNIVERSITY OF WOLLONGONG
by
AMANDA JOANNE DUCROU

BE (software), MDigMMedia (distinction)
FACULTY OF INFORMATICS
2009
Certification
I, Amanda J. Ducrou, declare that this thesis, submitted in fulfilment of

the requirements for the award of Doctor of Philosophy, in the Faculty of
Informatics, University of Wollongong, is wholly my own work unless oth-
erwise referenced or acknowledged. This document has not been submitted
for qualifications at any other academic institution.
Amanda J. Ducrou
25th May, 2009
Acknowledgements
I would like to acknowledge my supervisor, Peter Eklund, for giving me the

opportunity to attain a PhD and for his ongoing supervision. Peter always
trusts me to complete any task he gives me without constantly checking up
on me, but is always available for a discussion if needed. Peter has given
me some great advice over the years, for which I thank him.
I would like to take this opportunity to thank Pen Computer Systems, and
chiefly managing director John Johnston for his guidance in the field of
Health Informatics and for supporting my work. I would also like to thank
Tarkhan Shahho for helping on the technical side of the ePOC project, and
Brett Esler for introducing me to HL7 Version 3 and being available for
endless discussions on how to represent clinical constructs.
Also in conjunction with the ePOC project, I would like to thank my col-
league Jason Sargent for all his hard work in that area, and also Damian
Ryan and the rest of the TACT staff for their support for the ePOC field trial
and for their consultations on clinical knowledge employed in that project.
My parents, Jeff and Janelle Ryan, have always believed in me beyond all
reason and I am just glad to make them proud. Thanks, Mum and Dad, for
always being supportive.
Last but not least, I thank my husband, Jon, for all his support, advice and
proof-reading which has helped me to finally complete this thesis. Thank
you for always having faith in me.
Contents
Abstract 17
1 Introduction 19
1.1 Facets of Health Informatics . . . . . . . . . . . . . . . 21
1.1.1 Electronic Patient Care Records . . . . . . . . . . . . . 22
1.1.2 Clinical Terminologies . . . . . . . . . . . . . . . . . . 26
1.1.3 Clinical Information Models . . . . . . . . . . . . . . . 29
1.1.4 Decision Support Systems . . . . . . . . . . . . . . . . 30
1.1.5 Medical Imaging . . . . . . . . . . . . . . . . . . . . . . 31
1.2 Methodology . . . . . . . . . . . . . . . . . . . . . . . . 32
1.3 Health Informatics Standards
Focused On in This Work . . . . . . . . . . . . . . . . . 34
1.4 Defining The Problem:
Integration and Interoperability . . . . . . . . . . . . 35
1.4.1 Defining Interoperability . . . . . . . . . . . . . . . . . 38
1.4.2 Messaging as a Technical Interoperability
Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
1.5 Enterprise Integration Background . . . . . . . . . . 42
1.5.1 Enterprise Service Bus . . . . . . . . . . . . . . . . . . 42
1.5.2 Advantages of XML . . . . . . . . . . . . . . . . . . . . 43
1.6 Previous Work . . . . . . . . . . . . . . . . . . . . . . . 44
1.6.1 Terminologies . . . . . . . . . . . . . . . . . . . . . . . 44
1.6.2 HL7 and Ontology Mapping . . . . . . . . . . . . . . . 46
1.6.3 Interoperability Frameworks . . . . . . . . . . . . . . 47
2 Health Standards Background 49

2.1 Health Level Seven . . . . . . . . . . . . . . . . . . . . 50
2.1.1 HL7 Version 2 . . . . . . . . . . . . . . . . . . . . . . . 51
2.1.2 HL7 Version 3 . . . . . . . . . . . . . . . . . . . . . . . 55
2.1.3 HL7 Version 2 and Version 3
Compatibility . . . . . . . . . . . . . . . . . . . . . . . 61
2.1.4 Conclusions on HL7 . . . . . . . . . . . . . . . . . . . . 63
2.2 openEHR . . . . . . . . . . . . . . . . . . . . . . . . . . 65
2.2.1 The openEHR Information Model . . . . . . . . . . . . 65
2.2.2 openEHR Archetypes . . . . . . . . . . . . . . . . . . . 67
2.2.3 Archetype Description Language (ADL) . . . . . . . . 68
2.2.4 openEHR example . . . . . . . . . . . . . . . . . . . . . 70
2.2.5 openEHR and HL7 . . . . . . . . . . . . . . . . . . . . 75
2.2.6 Conclusions on openEHR . . . . . . . . . . . . . . . . . 76
7
2.3 SNOMED CT . . . . . . . . . . . . . . . . . . . . . . . 77
2.3.1 SNOMED CT Concepts and Relationships . . . . . . . 78
2.3.2 SNOMED CT Example . . . . . . . . . . . . . . . . . . 79
2.3.3 Representation of Clinical Findings
with SNOMED CT . . . . . . . . . . . . . . . . . . . . 80
2.3.4 SNOMED CT Concepts
Represented in HL7 . . . . . . . . . . . . . . . . . . . . 83
2.4 SNOMED CT Concepts
Represented in openEHR . . . . . . . . . . . . . . . . . 83
2.4.1 Conclusions on SNOMED CT . . . . . . . . . . . . . . 85
3 Referral Messaging Prototype 87

3.1 Referral Scenario and Workflow Model . . . . . . . . . 87
3.2 Message Models . . . . . . . . . . . . . . . . . . . . . . 89
3.3 The Referral Application . . . . . . . . . . . . . . . . . 93
3.3.1 Transport Protocols . . . . . . . . . . . . . . . . . . . . 94
3.3.2 User Interface . . . . . . . . . . . . . . . . . . . . . . . 94
3.3.3 Registry Service . . . . . . . . . . . . . . . . . . . . . . 97
3.4 Conclusions from Referral Prototype . . . . . . . . . . 98
4 The ePOC Project 99

4.1 Project Background . . . . . . . . . . . . . . . . . . . . 100
4.2 Clinical Environment . . . . . . . . . . . . . . . . . . . 102
4.3 The ePOC System . . . . . . . . . . . . . . . . . . . . . 103
4.3.1 Module 1: Clinical Observations . . . . . . . . . . . . 104
4.3.2 Module 2: Cannula Insertion . . . . . . . . . . . . . . 106
4.4 SNOMED CT Subsets Used in ePOC . . . . . . . . . . 107
4.4.1 Clinical Observations SNOMED CT Subset . . . . . . 107
4.4.2 Cannula Insertion SNOMED CT Subset . . . . . . . . 108
4.5 HL7 Message Models in ePOC . . . . . . . . . . . . . . 109
4.5.1 Clinical Observations HL7 Model . . . . . . . . . . . . 110
4.5.2 Cannula Insertion HL7 Model . . . . . . . . . . . . . . 113
4.6 Software Design for ePOC . . . . . . . . . . . . . . . . 113
4.6.1 Client Entry Form . . . . . . . . . . . . . . . . . . . . . 117
4.6.2 ePOC PC Control Panel . . . . . . . . . . . . . . . . . 117
4.6.3 ePOC PDA Application . . . . . . . . . . . . . . . . . . 120
4.7 ePOC Field Trial . . . . . . . . . . . . . . . . . . . . . 122
4.8 Conclusions from ePOC . . . . . . . . . . . . . . . . . . 123
5 Ontology Mapping 125

5.1 Definition of Ontology . . . . . . . . . . . . . . . . . . 125
5.2 Ontology Mapping . . . . . . . . . . . . . . . . . . . . . 126
5.3 Mapping SNOMED CT to HL7 . . . . . . . . . . . . . 128
5.3.1 Example Manual Mapping . . . . . . . . . . . . . . . . 130
5.3.2 Extended Alignment Strategy . . . . . . . . . . . . . . 133
5.4 Mapping between HL7 Versions 2 and 3 . . . . . . . . 135
5.4.1 Observations Messages Mapping . . . . . . . . . . . . 137
5.5 SNOMED CT and openEHR . . . . . . . . . . . . . . . 139
5.6 Mapping between HL7 V3 and openEHR . . . . . . . 139
5.6.1 openEHR Clinical Observations Messages . . . . . . . 141
5.7 Ontology Mapping Conclusions . . . . . . . . . . . . . 144
6 SNOMED CT Vital Signs XML Database 147

6.1 SNOMED CT Vital Signs subset . . . . . . . . . . . . 148
6.2 Representation of SNOMED CT . . . . . . . . . . . . 149
6.3 SNOMED CT XML Converter Utility . . . . . . . . . 155
6.4 eXist Open Source Native XML Database . . . . . . . 158
6.5 Conclusions on SNOMED CT
Vital Signs Database . . . . . . . . . . . . . . . . . . . 160
7 The Jini Health Interoperability Framework (HIF-J) 161

7.1 The Jini Architecture . . . . . . . . . . . . . . . . . . . 162
7.1.1 Jini and JavaSpaces . . . . . . . . . . . . . . . . . . . 163
7.1.2 Lookup and Discovery . . . . . . . . . . . . . . . . . . 164
7.1.3 Leasing . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
7.1.4 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
7.1.5 Transactions . . . . . . . . . . . . . . . . . . . . . . . . 166
7.1.6 The Entry Class . . . . . . . . . . . . . . . . . . . . . . 166
7.2 Health Interoperability Framework
- Jini . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
7.3 SNOMED CT Terminology Server . . . . . . . . . . . 167
7.4 HealthSpace . . . . . . . . . . . . . . . . . . . . . . . . 169
7.4.1 The Message Class . . . . . . . . . . . . . . . . . . . . 170
7.5 Messaging protocols . . . . . . . . . . . . . . . . . . . . 171
7.5.1 HL7 Artifacts . . . . . . . . . . . . . . . . . . . . . . . 172
7.6 Jini Translation Service . . . . . . . . . . . . . . . . . 172
7.7 The Observation Client Application . . . . . . . . . . 175
7.8 HL7 Java Package . . . . . . . . . . . . . . . . . . . . 178
7.9 JavaSpace Problems . . . . . . . . . . . . . . . . . . . 178
7.10 Conclusions from HIF-J . . . . . . . . . . . . . . . . . 180
8 Health Service Bus (HSB) 181

8.1 ESB Background . . . . . . . . . . . . . . . . . . . . . 182
8.1.1 Service Containers and Endpoints . . . . . . . . . . . 183
8.2 Mule Open Source ESB . . . . . . . . . . . . . . . . . . 185
8.3 HSB Mule Implementation . . . . . . . . . . . . . . . 186
8.4 Messaging protocols for the HSB . . . . . . . . . . . . 187
8.4.1 Canonical Message Model . . . . . . . . . . . . . . . . 188
8.5 Translation Service . . . . . . . . . . . . . . . . . . . . 190
8.6 Content-Based Routing . . . . . . . . . . . . . . . . . . 191
8.7 Patient Records in the HSB . . . . . . . . . . . . . . . 193
8.8 SNOMED CT Terminology Service . . . . . . . . . . . 194
8.9 End-to-End Example . . . . . . . . . . . . . . . . . . . 195
8.10 Total Interoperability in the HSB . . . . . . . . . . . . 195
8.11 HSB Example . . . . . . . . . . . . . . . . . . . . . . . 197
8.11.1 GP Clinic . . . . . . . . . . . . . . . . . . . . . . . . . . 198
8.11.2 Hospital . . . . . . . . . . . . . . . . . . . . . . . . . . 198
8.11.3 Pathologist . . . . . . . . . . . . . . . . . . . . . . . . . 199
8.11.4 Radiologist . . . . . . . . . . . . . . . . . . . . . . . . . 200
8.11.5 Pharmacy . . . . . . . . . . . . . . . . . . . . . . . . . 201
8.11.6 Aged Care . . . . . . . . . . . . . . . . . . . . . . . . . 201
8.11.7 Community Care . . . . . . . . . . . . . . . . . . . . . 202
8.11.8 Registration Board . . . . . . . . . . . . . . . . . . . . 203
8.11.9 Complete Network . . . . . . . . . . . . . . . . . . . . 204
8.11.10 Process Interoperability . . . . . . . . . . . . . . . . . 204
8.12 Conclusions on the HSB . . . . . . . . . . . . . . . . . 206
9 Conclusion 207
Technical Acknowledgements 213

Tooling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
A The HL7 Reference Information Model 215
B Complete OpenEHR Height Archetype 217
C SNOMED CT Subset Used in ePOC 223
D Flowchart of User Interface screens in the ePOC PDA

application 227
E Mapping HL7 V2 and V3 229
F Mapping HL7 V3 and openEHR 233
Bibliography 235
List of Figures
2.1 HL7 V2 Patient Referral Message Communications . 53

2.2 Overview of the representation of a HL7 V2 Message
Segment . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.3 Structure of a HL7 V2 Referral Message . . . . . . . . 54
2.4 HL7 V3 RIM Classes . . . . . . . . . . . . . . . . . . . 56
2.5 Example HL7 V3 Model . . . . . . . . . . . . . . . . . 58
2.6 HL7 V3 Observations DMIM . . . . . . . . . . . . . . 59
2.7 HL7 V3 RMIM Example . . . . . . . . . . . . . . . . . 60
2.8 HL7 V3 HMD Example . . . . . . . . . . . . . . . . . . 62
2.9 HL7 V3 XML Example . . . . . . . . . . . . . . . . . . 62
2.10 The openEHR Information Model . . . . . . . . . . . . 66
2.11 openEHR ADL Archetype Structure . . . . . . . . . . 69
2.12 openEHR Archetype Example . . . . . . . . . . . . . . 71
2.13 SNOMED CT Blood Pressure Concept . . . . . . . . . 79
2.14 SNOMED CT Blood Pressure Concept - Specific . . . 81
3.1 Patient Flow . . . . . . . . . . . . . . . . . . . . . . . . 89

3.2 Referral Message Flow . . . . . . . . . . . . . . . . . . 89
3.3 HL7 V2 REF I12 Message Components . . . . . . . . 91
3.4 HL7 V2 REF I12 Message Components - Extended . 92
3.5 HL7 V2 REF I12 Message Instance . . . . . . . . . . 92
3.6 HL7 V2 XML Message from Prototype . . . . . . . . . 93
3.7 Transport Protocols used in Prototype . . . . . . . . . 94
3.8 Prototype Start-Up Screen . . . . . . . . . . . . . . . . 95
3.9 Prototype Referral Form Screen . . . . . . . . . . . . . 96
3.10 Reading Message Forms in Prototype . . . . . . . . . 96
3.11 Prototype Settings Screen . . . . . . . . . . . . . . . . 97
3.12 Registry Service in Prototype . . . . . . . . . . . . . . 98
4.1 ePOC Overall Plan . . . . . . . . . . . . . . . . . . . . 100

4.2 TACT Clinical Observations Workflow . . . . . . . . . 105
4.3 SNOMED CT Observable Entity Concepts in ePOC . 108
4.4 SNOMED CT Procedure Concepts in ePOC . . . . . . 108
4.5 SNOMED CT Cannula Insertion Concepts in ePOC . 109
4.6 Clinical Observations RMIM (part 1) . . . . . . . . . . 111
4.7 Clinical Observations RMIM (part 2) . . . . . . . . . . 111
4.8 SNOMED CT to HL7 Mapping in ePOC . . . . . . . . 112
4.9 Cannula Insertion RMIM . . . . . . . . . . . . . . . . 113
4.10 Final ePOC functionality . . . . . . . . . . . . . . . . . 114
4.11 ePOC HL7 Class Design . . . . . . . . . . . . . . . . . 115
11
4.12 XML Processing Algorithm . . . . . . . . . . . . . . . 116
4.13 ePOC Client Entry Form . . . . . . . . . . . . . . . . . 117
4.14 ePOC Control Panel . . . . . . . . . . . . . . . . . . . . 118
4.15 ePOC Client History Screen . . . . . . . . . . . . . . . 119
4.16 ePOC Messages Screen . . . . . . . . . . . . . . . . . . 120
4.17 ePOC PDA Application . . . . . . . . . . . . . . . . . . 121
5.1 SNOMED CT Blood Pressure Concept . . . . . . . . . 131

5.2 HL7 Representation of Blood Pressure Concept . . . 132
5.3 Straightforward SNOMED CT to HL7 Mapping . . . 132
5.4 SNOMED CT to HL7 Mapping Type 2 . . . . . . . . . 133
5.5 Mapping between HL7 V2 and V3 . . . . . . . . . . . 138
5.6 openEHR Blood Pressure Archetype . . . . . . . . . . 140
5.7 openEHR XML . . . . . . . . . . . . . . . . . . . . . . . 142
5.8 Comparison of openEHR and HL7 XML . . . . . . . . 143
5.9 Mapping HL7 to openEHR . . . . . . . . . . . . . . . . 145
6.1 SNOMED CT Vital Signs Subset . . . . . . . . . . . . 150

6.2 XML version of SNOMED CT Concepts . . . . . . . . 151
6.3 XML version of SNOMED CT Descriptions . . . . . . 153
6.4 XML version of SNOMED CT Relationships . . . . . 155
6.5 SNOMED CT Vital Signs Subset Creation . . . . . . 156
6.6 GUI for SNOMED CT XML Converter . . . . . . . . . 157
6.7 eXist DB Administration . . . . . . . . . . . . . . . . . 158
7.1 Process for Jini Registration . . . . . . . . . . . . . . . 165

7.2 Process for finding a Jini Service . . . . . . . . . . . . 165
7.3 Process for using a Jini Service . . . . . . . . . . . . . 165
7.4 HIF-J Architecture . . . . . . . . . . . . . . . . . . . . 168
7.5 Jini Terminology Server Classes . . . . . . . . . . . . 169
7.6 HealthSpace Message Example . . . . . . . . . . . . . 171
7.7 HIF-J Observations RMIM . . . . . . . . . . . . . . . 172
7.8 Jini Translation Service Classes . . . . . . . . . . . . 175
7.9 Observation Application . . . . . . . . . . . . . . . . . 177
7.10 Observation Application - Messaging . . . . . . . . . . 177
7.11 SNOMED CT Browser . . . . . . . . . . . . . . . . . . 178
7.12 HL7 Java Class Design . . . . . . . . . . . . . . . . . . 179
8.1 HSB Conceptual Design . . . . . . . . . . . . . . . . . 182

8.2 Generic ESB Endpoint . . . . . . . . . . . . . . . . . . 184
8.3 Mule HSB Demo Components . . . . . . . . . . . . . . 186
8.4 Final Mule HSB Setup . . . . . . . . . . . . . . . . . . 188
8.5 Canonical Message Model . . . . . . . . . . . . . . . . 189
8.6 Transformations in the Mule HSB . . . . . . . . . . . 190
8.7 Mule Configuration Example . . . . . . . . . . . . . . 191
8.8 Comparison of HIF-J and HSB Messages . . . . . . . 192
8.9 Content-Based Router Representation . . . . . . . . . 192
8.10 Mule Configuration Example 2 . . . . . . . . . . . . . 193
8.11 Patient Records in the HSB . . . . . . . . . . . . . . . 194
8.12 Mule Configuration Example 3 . . . . . . . . . . . . . 195
8.13 End-to-End HSB Example . . . . . . . . . . . . . . . . 196
8.14 HSB - GP System . . . . . . . . . . . . . . . . . . . . . 198
8.15 HSB - Hospital System . . . . . . . . . . . . . . . . . . 199
8.16 HSB - Pathologist System . . . . . . . . . . . . . . . . 199
8.17 HSB - Radiologist System . . . . . . . . . . . . . . . . 201
8.18 HSB - Pharmacy System . . . . . . . . . . . . . . . . . 201
8.19 HSB - Aged Care System . . . . . . . . . . . . . . . . . 202
8.20 HSB - Community Care System . . . . . . . . . . . . . 203
8.21 HSB - Registration Board System . . . . . . . . . . . 203
8.22 Complete HSB Example . . . . . . . . . . . . . . . . . 205
A.1 The HL7 RIM Version 2.26 – Foundation Classes. . . 216
D.1 Complete flowchart of user interface screens in ePOC

PDA application. . . . . . . . . . . . . . . . . . . . . . 228
List of Tables
1.1 Computer-based Handling of Clinical Information . . 39
2.1 HL7 V2 MSH Segment Fields . . . . . . . . . . . . . . 54

2.2 HL7 V3 Act Class Attributes . . . . . . . . . . . . . . 57
2.3 SNOMED CT Blood Pressure Concept’s Relationships 80
4.1 Mapping HL7 to SNOMED CT for Observations . . . 112

4.2 Mapping HL7 to SNOMED CT for Cannula Insertion 114
5.1 SNOMED CT to HL7 Mapping . . . . . . . . . . . . . 132

5.2 Extended Mapping of SNOMED CT to HL7 . . . . . . 135
5.3 Mapping between HL7 V2 and V3 . . . . . . . . . . . 137
5.4 Specific Mapping of HL7 V2 and V3 . . . . . . . . . . 138
5.5 openEHR Archetypes . . . . . . . . . . . . . . . . . . . 144
6.1 Part of the SNOMED CT Concepts File . . . . . . . . 149

6.2 Part of the SNOMED CT Descriptions File . . . . . . 152
6.3 Part of the SNOMED CT Relationships File . . . . . . 154
7.1 HIF-J Observations HMD . . . . . . . . . . . . . . . . 173

7.2 HIF-J Observations HMD (cont.) . . . . . . . . . . . . 174
C.1 ePOC SNOMED CT Subset (part 1) . . . . . . . . . . 224

E.1 Mapping of HL7 V2 fields to HL7 V3 . . . . . . . . . . 230

E.2 Mapping of HL7 V3 attributes to HL7 V2 . . . . . . . 231
F.1 Mapping between HL7 V3 and openEHR . . . . . . . 234
14
List of Abbreviations
HIF-J . . . . . . . . . . . . Health Interoperability Framework – Jini

ADL . . . . . . . . . . . . . . Archetype Description Language
ADT . . . . . . . . . . . . . . Admission, Discharge, Transfer
AHML . . . . . . . . . . . Australian Healthcare Messaging Laboratory
AMR . . . . . . . . . . . . . Association of Medical Receptionists
ANSI . . . . . . . . . . . . . American National Standards Institute
ARC . . . . . . . . . . . . . . Australian Research Council
CAP . . . . . . . . . . . . . . College of American Pathologists
CDA . . . . . . . . . . . . . Clinical Document Architecture
CEN . . . . . . . . . . . . . European Committee for Standardisation
CIS . . . . . . . . . . . . . . Clinical Information System
CMT . . . . . . . . . . . . . Convergent Medical Terminology
CTv3 . . . . . . . . . . . . . Clinical Terms version 3
DICOM . . . . . . . . . . Digital Imaging and COmmunication in Medicine
DMIM . . . . . . . . . . . Domain Message Information Model
DSS . . . . . . . . . . . . . . Decision Support System
EDI . . . . . . . . . . . . . . Electronic Data Interchange
EHR . . . . . . . . . . . . . Electronic Health Record
ePOC . . . . . . . . . . . . electronic Point-Of-Care
ESB . . . . . . . . . . . . . . Enterprise Service Bus
FLWOR . . . . . . . . . . For, Let, Where, Order by, Return
GEHR . . . . . . . . . . . . Good European Health Record
GP . . . . . . . . . . . . . . . General Practitioner
HL7 . . . . . . . . . . . . . . Health Level Seven
HMD . . . . . . . . . . . . . Hierarchical Message Description
HSB . . . . . . . . . . . . . . Health Service Bus
ICD . . . . . . . . . . . . . . International Classification of Diseases
IEEE . . . . . . . . . . . . . Institute of Electrical and Electronics Engineers
IHTSDO . . . . . . . . . International Healthcare Terminology Standards De-
velopment Organisation
ISO . . . . . . . . . . . . . . International Organisation for Standardisation
ITS . . . . . . . . . . . . . . . Implementable Technology Specification
JCA . . . . . . . . . . . . . . J2EE Connector Architecture
Jini . . . . . . . . . . . . . . Jini Is Not Initials
JMS . . . . . . . . . . . . . . Java Message Service
JMX . . . . . . . . . . . . . Java Management eXtensions
JVM . . . . . . . . . . . . . Java Virtual Machine
LOINC . . . . . . . . . . . Logical Observation Identifier Names and Codes
MeSH . . . . . . . . . . . . Medical Subject Headings
15
MSMQ . . . . . . . . . . . Microsoft Message Queue
NHS . . . . . . . . . . . . . National Health Service (UK)
NLM . . . . . . . . . . . . . National Library of Medicine (US)
OWL . . . . . . . . . . . . . Web Ontology Language
PACS . . . . . . . . . . . . Picture Archiving and Communication Systems
PAS . . . . . . . . . . . . . . Patient Administration System
PDA . . . . . . . . . . . . . . Personal Digital Assistant
RIM . . . . . . . . . . . . . . Reference Information Model
RMIM . . . . . . . . . . . . Refined Message Information Model
SCTID . . . . . . . . . . . SNOMED CT IDentifier
SDO . . . . . . . . . . . . . . Standards Development Organisation
SESIAHS . . . . . . . . South East Sydney and Illawarra Area Health Service
SNOMED . . . . . . . . Systemised Nomenclature of MEDicine
SNOMED CT . . . . SNOMED – Clinical Terms
SNOMED RT . . . . SNOMED – Reference Terminology
SOA . . . . . . . . . . . . . . Service-Oriented Architecture
SOAP . . . . . . . . . . . . Simple Object Access Protocol
SQL . . . . . . . . . . . . . . Structured Query Language
TACT . . . . . . . . . . . . The Ambulatory Care Team
UML . . . . . . . . . . . . . Unified Modelling Language
UMLS . . . . . . . . . . . . Unified Medical Language System
WHO . . . . . . . . . . . . . World Health Organisation
XML . . . . . . . . . . . . . eXtensible Markup Language
XPath . . . . . . . . . . . . XML Path Language
XQuery . . . . . . . . . . XML Query Language
XSLT . . . . . . . . . . . . . eXtensible Stylesheet Language Transformations
Abstract
Interoperability in healthcare is a requirement for effective communication
between entities, to ensure timely access to up-to-date patient information
and medical knowledge, and thus consistent patient care. This thesis fo-
cuses on the development of an interoperability solution for health by em-
ploying design science research methods to arrive at a final solution.
First, background topics including Health Informatics standards and
formats are covered, which leads to three major Health Informatics stan-
dards being used throughout the remainder of this work – HL7 for mes-
saging, openEHR for patient records, and SNOMED CT as a standard ter-
minology to facilitate clarity of information, and to discourage ambiguity
between communicating entities.
Ontology mapping methods between these standards designed to pro-
mote interoperability by using the standards in conjunction with each other
are then presented, leading to a solution for semantic interoperability.
A technical interoperability solution is required for sending these se-
mantically interoperable messages, which leads to the development of a
framework which uses a tuple-space paradigm to share messages. This
framework is shown to have some scalability issues, which leads to the
final solution – a scalable interoperability framework based on the Enter-
prise Service Bus methodology of enterprise integration which provides a
real-world answer to communication in healthcare.
17
18
Amanda Ducrou PhD Thesis, 2009

Chapter 1
Introduction
In Health Informatics, promises and expectations are renewed more often
than they are fulfilled. The idea of a computerised patient record has ex-
isted since as early as 1966. However, over 40 years later, it is still not a re-
ality [Tay06]. Information technology is used ubiquitously elsewhere today,
but is still far from effective in healthcare. The main challenge in Health
Informatics is to enable shareable and computable information [Ope08a], a
goal which has been achieved by many other industries such as banking.
One problem impeding shareable health information is that no agree-
ments can be made on a standard data collection process, what items to
collect, or a standard form. Also, agreement on a standard set of terms to
use within the information is extremely difficult because of the complexity
of the domain. Many health and medical terminologies have been created
to solve the “standard terms” problem, but which one should be used? Even
when terminologies have been introduced, the terms are not always used
consistently.
A major obstruction to computerised medical records is the fact that
many healthcare professionals have used and relied on paper records for so
long that they see them as an intrinsic part of the healthcare process [Agu05].
This problem is seen especially in hospitals – in a two part article en-
19
20 CHAPTER 1. INTRODUCTION
titled “Why general practitioners use computers and hospital doctors do
not” [Ben02a, Ben02b], Benson comments on the reasons for poor computer
systems in hospitals in the UK. He states:
• Over 30 years, leaders of the general practitioner profession have
worked with government to provide incentives for computerising prac-
tices and to remove barriers;
• In hospitals, computing was treated as a management overhead and
doctors had no incentives to become involved;
• General practice computerisation has been a success, but what works
in a GP surgery does not readily scale up to work in a hospital;
• In hospitals, many different computer systems need to be linked to-
gether, thus requiring common interoperability standards.
An important point, and one relevant to this work, is the comment about
common interoperability standards. Hospitals have many different depart-
ments covering different types of information, which all need to communi-
cate with each other.
In 2004, The Center for Information Technology Leadership (CiTL), a
research organisation established to help guide the healthcare community
in making more informed strategic IT investment decisions [CiT09], con-
ducted a study on Healthcare Information Exchange and Interoperability
(HIEI). They found that moving to standardized HIEI would deliver $77.8
billion in annual savings in the United States [CiT04], but the problem still
has not been solved.
In June 2005, U.S. Secretary of Health and Human Services, Michael
Leavitt, commented on the terminology problem by noting that:
“...the field of Health Informatics involves bringing together the
two communities of practice most known for their use of complex
and difficult language – medicine and computer science.” [HL707]

1.1. FACETS OF HEALTH INFORMATICS 21
In [Tay06], Taylor defines “three grand challenges for Health Informat-
ics.” These three challenges are:
1. Reading and writing patient records – creation, organisation, man-
agement and maintenance of patient records leading to effective use
of patient data.
2. Creation of medical knowledge – knowledge about diseases, health
problems and how healthcare organisations operate, and how this
knowledge can be created by combining existing information or using
information tools.
3. Access to medical knowledge – medical knowledge has no use if it
is simply collected and stored; timely access to the most up-to-date
knowledge is required.
The key to all of these challenges is interoperability. Clear communica-
tion between entities is required to achieve the goals of effective use of pa-
tient data, creating medical knowledge and enabling access to that knowl-
edge. Semantic interoperability, in which transmitting meaning is just as
important as making sure the message arrives, is essential to reaching
these goals. This thesis presents design science research aimed at solving
interoperability in healthcare.
The field of Health Informatics comprises different research and devel-
opment areas in which these challenges must be solved. Some of the re-
search areas are outlined in the following section.
1.1 Facets of Health Informatics
Many different areas and topics come under the umbrella of Health Infor-
matics. The main areas of research and development in the field are listed
below.

• Electronic Patient Care Records
• Controlled Clinical Terminologies
• Clinical Information Models
• Decision Support Systems
• Medical Imaging
These individual technologies are all important parts of greater systems
– such as Clinical Information Systems and Patient Administration Sys-
tems.
A Clinical Information System (CIS) is a comprehensive, integrated in-
formation system designed to manage the patient-related and clinical-state-
related aspects, as well as administrative and financial aspects, of a health-
care entity – usually a hospital.
A Patient Administration System (PAS) is one of the earliest compo-
nents of hospital computer systems, which records the patient’s name, home
address, date of birth and each contact with the outpatient department or
admission and discharge. These are the basic patient details required in
running a hospital.
Each of the Health Informatics topics listed above are summarised in
the following sections.
1.1.1 Electronic Patient Care Records
One of the principle aims of Health Informatics has been the development
of electronic patient record systems. A common goal is to allow information
from different providers to merge to create a single record of a patient’s
care, from their birth to their death. In reality, patients’ notes are often
stored on computers, but relatively few are stored in a way that allows
programmatic processing or amalgamation of this information [Tay06].

Electronic patient care records are called by various similar names such
as Electronic Health Records or Electronic Medical Records. They will be
referred to as Electronic Health Records (EHRs) from now on in this work.
Some examples of Electronic Health Records are GEHR, CEN 13606, Spec-
ification 1000, openEHR and the HL7 CDA.
Recently, the development of personal Health Informatics solutions has
been advancing, including such services as Google’s Google Health [Goo08]
and Microsoft’s HealthVault [Mic08]. The aim of these health systems for
the general public is to place health records in the hands of the individual –
this is the best way to keep records up-to-date and correct. If the patient can
see their own medical record, they can make sure all personal information
is correct, and fill in such things as family history. If the fact that a patient
is allergic to a certain drug is somehow lost from their file, a fatal mistake
could be made. If the patient is keeping their own record up to date, these
kinds of mistakes are likely to be avoided.
GEHR
The Good European Health Record (GEHR) project was a large European
Union-funded project undertaken within eight European countries between
1992 and 1994 [Sch04]. It was the first international research project to de-
velop a specification for a “good” quality EHR based on detailed clinical,
technical and legal requirements. Unfortunately, it proved to be very dif-
ficult to implement for a variety of technical reasons but the requirements
work still stands alone and was the major input into the first ISO1 EHR
standard on requirements for an EHR Architecture (ISO/TS 18308:2004)
[ISO04].
1 International Organisation for Standardisation

CEN 13606
CEN 13606 refers to the CEN2 standard reference model for the exchange
of EHR information. The CEN 13606 approach is to represent the refer-
ence model as a set of Unified Modelling Language (UML) diagrams, the
outcome of which is a hierarchical model reflecting the nature of real heath
records [Gil05].
Specification 1000
Specification 1000 refers to ANSI3 “Specification No. 1000, Standard Clini-
cal Data Architecture for the Structure and Content of an Electronic Health
Record”. It is the only American national standard that defines the funda-
mental data structures used to build EHRs [MdOAdSJ+ 07].
Specification 1000 addresses standardization of electronic health data
across a broad range of healthcare domains – from audiology to veterinary
services [ANS08].
openEHR
openEHR is an international not-for-profit foundation with the mission of
making the interoperable, life-long electronic health record a reality by de-
veloping open specifications, open-source software and knowledge resources
for Health Informatics [Ope08a].
openEHR provides an interoperable standard for an Electronic Health
Record which separates the domain model from the information model via
archetypes. This is referred to as a dual-model system development method-
ology [Bea02]. The openEHR information model is called the Reference
Model and is quite small, consisting of generic, high-level concepts. As
such many different healthcare concepts can be represented. The clini-
cal and patient record constructs (domain-specific concepts) are thus writ-
2 European Committee for Standardisation
3 American National Standards Institute

ten in a constraint language and applied to the reference model as arche-
types [Ope08a, KBD05]. Part of openEHR is a standard XML representa-
tion of Reference Model constructs.
openEHR is one of the health standards focused on in this work and is
detailed in the next chapter. See also Section 1.3 later in this chapter.
Google Health
Google Health is basically an aggregator of useful health sites – it offers one
place to go to find links to all types of health services on the Internet, as
well as articles on health issues which may be browsed. Google Health also
allows the user the opportunity to import medical records, but currently
only four medical centers are participating with Google to offer this ability.
Prescription information can also be imported, and nine additional sources
offer this service. Google Health includes a Decision Support System which
shows possible drug interactions between the user’s entered prescriptions.
All other data must be user-entered.
HealthVault
HealthVault, by Microsoft, is more advanced than Google Health, and of-
fers more sources to import medical records from (some of which overlap
with Google’s sources), as well as the functionality to upload any files from
the user’s computer, which can be shared. One HealthVault account can
store health records for a whole family, with the ability to share documents
or to mark items as ‘personal’ if the user would like to keep them private.
HealthVault also allows data to be uploaded directly from some digital de-
vices, such as a digital blood pressure reader. Overall, HealthVault has a
more sophisticated interface than Google Health and offers the ability for
more detailed record keeping. HealthVault also includes Decision Support
drug interaction information.

1.1.2 Clinical Terminologies
A terminology is simply a standard set of terms defined for use in a particu-
lar situation, thus enabling clearer communication between entities. A clin-
ical terminology defines a standard set of terms for use in the health care
domain. Most clinical terminologies do not provide definitions for the terms,
or rules about how they should be used. As such, care must be taken that
different entities do not use the standard terms in different ways. Some
examples of clinical terminologies are as follows:
• International Classification of Diseases (ICD-10)
• Medical Subject Headings (MeSH)
• Clinical Terms version 3 (CTv3)
• Systemised Nomenclature of Medicine (SNOMED)
• SNOMED CT (merger of CTv3 and SNOMED)
• Logical Observation Identifier Names and Codes (LOINC)
• First DataBank drug terminology
Each of the terminologies listed above is summarised in the following
subsections.
ICD-10
The International Classification of Diseases (ICD) is the international stan-
dard diagnostic classification for all general epidemiological and other health
management purposes, including the analysis of the general health situa-
tion of population groups, and monitoring of the incidence and prevalence
of diseases. ICD-10 is sponsored by the World Health Organisation (WHO)
and came into use in WHO Member States from 1994, the latest in a series
which began as the International List of Causes of Death in 1893 [Wor08].

MeSH
The Medical Subject Headings (MeSH) are a classification system for health
and biomedical research which are used to index publications in the United
States National Library of Medicine’s (NLM) Medline, which is accessible
via PubMed. PubMed is a service of the NLM that includes over 18 mil-
lion citations from Medline and other life science journals for health and
biomedical articles going back as far as the 1950s [Uni08a].
Read Codes and CTv3
The Read Codes were first introduced in the early 1980s in the UK by Dr
John Read to record summary clinical and administrative data for General
Practice [RB86]. Version 1 of the Read Codes was a four-level hierarchy
of terms. Version 2 was expanded to allow a five-level hierarchy. Both
version 1 and 2 contain cross-mappings to other classifications, including
ICD-10 [RSBP97].
Version 3 of the Read Codes, called Clinical Terms version 3 (CTv3) was
developed during the Terms Projects (1992-1995) [Sev93, Buc93]. These
projects aimed to provide greater specialist detail to the Read Codes and to
encompass the wider domain of health care [RSBP97].
SNOMED
For over 40 years the College of American Pathologists (CAP) has invested
in the research and development of its Systemised Nomenclature of MED-
icine (SNOMED) works of medical terminology [CAP09]. In collaboration
with the Kaiser-Permanente organization, CAP revolutionised the structure
of SNOMED to reflect the advances in medical informatics and the science
of computing (for example, the use of description logics, distributed devel-
opment, and relational database structures). As a result, the SNOMED
Reference Terminology (SNOMED RT) was launched in May, 2000 [IHT08].

SNOMED CT
SNOMED CT was created by merging CTv3 with SNOMED RT. SNOMED
CT is a universal and international standard terminology for healthcare
and is a multiple-inheritance hierarchy made up of concepts and their at-
tributes. SNOMED CT contains more than 344,000 active concepts: the
most comprehensive clinical vocabulary available in any language, cover-
ing most aspects of clinical medicine [Uni08b]. For this reason, SNOMED
CT is the terminology chosen for this work.
In 2007, the SNOMED CT intellectual property rights were transferred
from CAP to the SNOMED Standards Development Organisation in the
formal creation of the International Health Terminology Standards Devel-
opment Organisation (IHTSDO).
IHTSDO now owns and administers the rights to SNOMED CT [IHT08].
SNOMED CT is elaborated in greater detail in the next chapter.
LOINC
The Logical Observation Identifiers, Names and Codes (LOINC) terminol-
ogy is used primarily for laboratory observations.
The purpose of LOINC is “to facilitate the exchange and pooling of clin-
ical results for clinical care, outcomes management, and research by pro-
viding a set of universal codes and names to identify laboratory and other
clinical observations” [The08].
The Regenstrief Institute, Inc, a healthcare and informatics research or-
ganization on the campus of the Indiana University School of Medicine in
Indianapolis, USA, maintains the LOINC database and supporting docu-
mentation.

First DataBank Drug Database
First DataBank, a subsidiary of Hearst Corporation, is a provider of inte-
grated medication databases. First DataBank’s National Drug Data File
Plus (NDDF Plus) contains drug descriptive information for the US, plus
clinical decision-support modules [Fir08]. It encompasses medications ap-
proved by the US Food and Drug Administration, and also information on
common over-the-counter medications and herbal and dietary supplements.
First DataBank also provides drug databases for Canada and Europe in ad-
dition to NDDF for the US.
While First DataBank is technically a database of drug information, it is
used in the same way as other terminologies: by integrating the database
of drug information with health information systems and EHRs, to pro-
vide centralised and standardised drug information throughout a health-
care network.
1.1.3 Clinical Information Models
Some examples of clinical information models are GALEN and Health Level
Seven (HL7). Clinical information models are different to EHRs in that
they aim to best represent clinical constructs, and concentrate less on pa-
tient records and continuity of records (however, most EHRs can also be
said to be clinical information models).
GALEN
GALEN is the name given to a technology that is designed to represent
clinical information in a new way, with a goal to “put the clinical into the
clinical workstation” [Ope08b]. OpenGALEN is a not-for-profit organisa-
tion that has been formed to enable the widest possible use of GALEN.
The GALEN Common Reference Model is designed to be a reusable, ap-
plication and language independent model of medical concepts.

Health Level Seven (HL7)
Health Level Seven (HL7) began in 1987 as a messaging standard for health,
and has grown to include other standards for interoperability, such as docu-
ment standards. HL7’s mission is to provide standards for interoperability
that improve care delivery. Currently HL7 Version 2 is the most widely im-
plemented version of HL7 for exchanging data. HL7 Version 3 is aimed at
providing semantic interoperability between systems and is built on object-
oriented principles. HL7 messaging and information models Versions 2 and
3 are used in this work, elaborated in Section 2.1 in the next chapter.
The HL7 Clinical Document Architecture (CDA) is a HL7 document stan-
dard, using Version 3 of the messaging model as a base and providing an
exchange model for clinical documents, including EHRs. The CDA thus
provides an EHR model based on the HL7 V3 information model.
1.1.4 Decision Support Systems
Decision Support Systems (DSS) have gone through various phases through-
out the history of Health Informatics research.
AAPHelp4 (Acute Abdominal Pain Help) is an early DSS (developed
in the late 1970s) used to diagnose abdominal pain. Implementation of
AAPHelp showed improvements in rates of successful diagnosis and cut
unnecessary surgery rates, and yet the clinicians involved were hesitant to
use it and did not trust it [Tay06].
The reason for this is that the designers of AAPHelp made decisions on
which diseases to include, and what data items to collect, without consult-
ing the clinicians who were the end-users of the system. Also, some of the
data used to train the system was incomplete, leading to mistrust.
In medicine, the doctor-patient relationship is very important, the pre-
vailing view being that the clinician needs to speak to their patient in per-
4 http://www.aaphelp.leeds.ac.uk/aaphelp/

son to gain a full understanding of his or her symptoms. Given this, the
clinicians were unlikely to trust a black-box decision made by a computer
system, but the designers of AAPHelp did not take this into account.
The lesson from AAPHelp is that computer systems are more likely to be
accepted by clinicians if they are designed to complement clinical expertise,
rather than moving final diagnosis out of the clinician’s hands [Tay06].
As such, modern Decision Support Systems are very different to AAP-
Help – decision support for diagnostic decisions have all been unsuccessful,
for the reasons outlined above. One area where decision support has been
successful is in prescribing systems – checking for allergies, contraindica-
tions, and drug reactions and interactions. Highlighting possible drug in-
teractions or contraindications that the user may not be aware of can be
seen to be helpful, while leaving final diagnosis-type decisions up to the
clinician. Both Google Health and Microsoft’s HealthVault have drug inter-
action Decision Support Systems embedded in their end-user focused online
health sites.
Another area where DSSs are helpful is when clinical guidelines are in-
cluded in health information systems. Guidelines and help can be provided
to the clinician throughout the information system in a context-based man-
ner, as an aid in decision making without actually making final decisions.
1.1.5 Medical Imaging
Medical imaging is principally about technical interoperability, i.e. mak-
ing sure that an image is reproduced correctly at the receiving end. This
area of Health Informatics has had to be interoperable from the start for
any successful transmission of images to be possible. Picture Archiving and
Communication Systems (PACS) are systems dedicated to the storage, re-
trieval, distribution and presentation of medical images, which are stored
in an independent format, of which the most widely used is DICOM.

DICOM
Digital Imaging and COmmunication in Medicine (DICOM) is the only in-
ternationally recognised standard for the communication of images and re-
lated information in the health domain [MdOAdSJ+ 07]. DICOM originated
in 1983 when the American College of Radiology and the National Electric
Manufacturers Association identified the need for interoperability among
imaging equipment from various vendors [DIC08]. DICOM is meant to
complement HL7, and is also an object-oriented information model [Tay06].
1.2 Methodology
The research method employed here follows the paradigm of Design Sci-
ence. Design science is a method of Information Systems/Information Tech-
nology research which seeks to extend the boundaries of human and organ-
isational capabilities by creating new and innovative artifacts [HMPR04].
Knowledge and understanding of a problem and its solution are achieved
in the building and application of the designed artifacts.
The field of Information Technology studies artificial phenomena, i.e.
human creations such as organisations and information systems. Artifi-
cial phenomena can be both created and studied, leading to the dual na-
ture of Information Technology research, in that scientists can contribute
to both of these activities [MS95]. Design science is technology-oriented re-
search concerned with the creation of artificial artifacts which fall into four
product-types: constructs, models, methods and implementations [MS95].
This thesis is arranged in chapters, starting with background topics and
then moving onto artifacts developed throughout this work. The artifacts
are projects and prototype systems designed to demonstrate interoperabil-
ity in the healthcare domain. The chapters are arranged in chronological
order of when the artifacts were designed/developed.
First, the remainder of this chapter goes on to formally define the prob-

1.2. METHODOLOGY 33
lem that the presented artifacts are designed to solve – that of achieving
interoperability in healthcare – followed by background and previous work
in this domain.
Chapter 2 details the three health standards which are concentrated on
as communication, health record and terminology standards respectively,
within the interoperability artifacts presented in later chapters – HL7,
openEHR and SNOMED CT. These three standards are seen as constructs
created by their respective standards organisations and contributed to the
Health Informatics field as a whole. Within the work presented in this
thesis, these constructs are combined into higher level models for sharing
information unambiguously between communicating parties.
Referrals between entities is a classic situation requiring communica-
tion in healthcare, thus the first artifact presented is a prototype Referral
Application, developed after gaining an understanding of the HL7 standard
and employing HL7 Version 2 as the message format. This is described in
Chapter 3.
Next, a collaborative project involving health industry partners, called
ePOC, is described in Chapter 4. One of the outcomes of the ePOC project
are the beginnings of an ontology mapping solution to reconcile HL7 V3
models with SNOMED CT clinical constructs. This solution is expanded
in Chapter 5, which presents ontology mapping methods for mapping from
SNOMED CT to HL7, mapping between HL7 and openEHR, and mapping
between HL7 Version 2 and Version 3.
Next, a solution for delivering timely access to the SNOMED CT termi-
nology is described, namely a native XML database containing SNOMED
CT concepts, descriptions and relationships with a Web Services front-end.
After the setup of the XML Terminology Database is discussed, two frame-
works are presented, the final implementations of proof-of-concept systems
achieving interoperability in healthcare.
The first solution is built on Jini technology and is called The Jini Health

Interoperability Framework (HIF-J). The details of HIF-J are outlined in
Chapter 7. Some problems with HIF-J are discussed, which leads to the
final interoperability solution.
The final solution for interoperability in healthcare is based on the En-
terprise Service Bus methodology of enterprise integration, and is called
the Health Service Bus. The HSB is described in Chapter 8.
Parts of the work presented in this treatise have been published previ-
ously under the author’s maiden name, Amanda Ryan – ontology mapping
from SNOMED CT to HL7 in [Rya06] and [REE07]; the ePOC project in
[SER+ 06] and [REE07]; and Enterprise Service Bus for health in [RE08].
1.3 Health Informatics Standards
Focused On in This Work
Three standards are focused on in this work – a communication standard, a
EHR standard and a controlled clinical terminology. Each standard is used
for its intended purpose in conjunction with the other two standards.
The communication standard employed is HL7 – primarily Version 3
although Version 2 is also covered. HL7 V3 is chosen because it is consis-
tent with the Semantic Web vision of providing a universal and computer-
interpretable medium for the exchange of data (specialised within the health
care domain) [HL708]. HL7 V3 employs an object-oriented approach to
modelling clinical information in a robust and scalable way and uses de-
fined XML as a standard messaging format. HL7 is used in conjunction
with SNOMED CT and also alongside openEHR to promote semantic inter-
operability between entities in the final interoperability solution presented
at the end of this treatise. HL7 is detailed in Section 2.1.
openEHR is chosen as the standard for patient records in this work be-
cause of the openEHR Foundation’s open approach to developing knowledge
resources for health, thus making openEHR accessible. Also, the design

1.4. DEFINING THE PROBLEM:
INTEGRATION AND INTEROPERABILITY 35
methodology of openEHR leads to a flexible solution which is easily exten-
sible and future-proof, due somewhat to the simplicity and robustness of
the information model. openEHR is used in the final interoperability solu-
tion as a means for storing the information from individual HL7 messages
in one continuous patient care record. Like HL7, openEHR also includes a
standard XML representation of its concepts. openEHR is detailed in Sec-
tion 2.2.
The terminology used here is SNOMED CT – used within both HL7
and openEHR instances in the final interoperability solution as a standard
set of terms for the purpose of semantic clarity, continued from observation
messages into a patient’s care record. SNOMED CT is detailed in Section
2.3.
1.4 Defining The Problem:
Integration and Interoperability
Now that research areas in Health Informatics have been outlined, the spe-
cific problem which this work is aimed at solving is described. The focus of
this work is interoperability.
Most applications can be made better by integrating them with other
applications. An example in personal computing is that a PDA’s calendar
must synchronise with a corporate calendar server, which in turn interfaces
with email. In Health Informatics, information has traditionally existed in
‘silos’ – separate stores of similar information which do not integrate with
each other. This is referred to as ‘the information silo problem’. Gilles
Frydman, in an article titled “Information Silos Are Everywhere. But So Is
The Internet!” on e-patient.net in November, 2008 [Fry08], says:
“Although much has been written about them, information silos
are becoming far more recognised as the major reason why or-

ganisations are unable to take full advantage of the Internet’s
power to interconnect business processes.” [Fry08]
Integration of information silos, and healthcare applications in general,
would provide an enormous advantage in the provision of care.
There are four fundamental problems for any integration solution, as
detailed in [HW04]. These problems are outlined below.
1. Networks are unreliable – compared to a process running on a single
computer, distributed computing has a large set of problems to over-
come, including delays, interruptions and data loss.
2. Networks are slow – making a local method call is multiple orders of
magnitude quicker than sending data over a network.
3. Any two applications are different – integration solutions need to al-
low systems which use different platforms and data formats to com-
municate. This is the core of the interoperability problem.
4. Change is inevitable – applications change over time. A good integra-
tion solution should employ loose coupling between systems to avoid
an avalanche effect of changes to all applications if one application
changes.
Coupling is a measure of how interrelated two parties (components, ap-
plications, services, programs, users) are. The principle behind loose cou-
pling is to reduce the assumptions that the two parties make about each
other when they exchange information, thus making them less interre-
lated [HW04]. Tight coupling results in brittle, poorly scalable systems
which are hard to maintain. openEHR refers to loose coupling as “separa-
tion of responsibilities”, which is one of their core design principles (another
reason openEHR is employed in this work) [BHKL06].
The Interoperability Work Group of HL7’s Electronic Health Record Tech-
nical Committee was formed in April 2005 to attempt to define the concept

of interoperability [HL707].
According to the HL7 Interoperability Work Group:
“Electronic health information systems will do no good if they do
not enhance communication at the level of human interactions...
Without continued progress on semantic interoperability, much
of the progress expected from the investment in technology will
be seriously hampered or never even begun.” [HL707]
Semantic interoperability is about the meaningful exchange of informa-
tion in association with its context. It evolves beyond just communicating
message structure into also communicating the intent or meaning of the
data, so that the information will be understood in precisely the same way
by both the sender and the recipient [RPH08].
Semantic interoperability is not just a problem in healthcare, other sec-
tors face similar difficulties, e.g. government [BFS06]. However, the many
varying types of data in healthcare can make the problem more difficult in
this domain. For example, patient administration data, clinical data, lab-
oratory data, and patient insurance information are just some of the types
of data in health which need to interact.
A big problem in solving the interoperability problem is that common
agreement on what interoperability actually is is not easy because individ-
ual and even group understandings of its meaning are presumed as self-
evident – rather than seek to understand one another, we assume we al-
ready do [HL707]. The next section will go on to discuss the definition of
interoperability.

1.4.1 Defining Interoperability
The IEEE5 definition of interoperability is:
“the ability of two or more systems or components to exchange
information and to use the information that has been exchanged.” [IEE05]
This definition was created in 1990, and is referred to as the IEEE-90 defi-
nition of interoperability.
When the HL7 Work Group began their investigation into the mean-
ing of interoperability, it became apparent to them that some groups in
the Health Informatics sector based their definitions of interoperability on
standard technical definitions such as the IEEE-90, and tended to view in-
teroperability as a matter of simple connectivity - the ability to ensure that
a message is exchanged completely and in correct format. However, techni-
cal definitions such as the IEEE-90 do not include the idea of the semantics
of the message (preservation of the meaning, not just the content).
If technical interoperability is the presumed definition, as long as a
verifiable message payload arrives at the receiving application it does not
matter whether the recipient understands the content or the intent of the
message, or whether the original message retains its structure and mean-
ing [HL707]. The example that the HL7 Work Group uses is:
“if the transmitted message clearly shows that the patient needs
an evaluation for appendicitis, but the receiving application loses
the structure of the historical sequence and shows instead a
broader picture of just ‘abdominal pain’, the technical interoper-
ability criterion could still be satisfied, but the semantic aspect
of the message would not be understood by the receiving appli-
cation or human recipient.” [HL707]
The HL7 Work Group found that there in fact exist three hierarchic
definitions, or “levels”, of interoperability in practical use, with technical

5 Institute of Electrical and Electronics Engineers

Table 1.1: Computer-based Handling of Clinical Information

(from [RMCR01]).
Please see print copy for image
interoperability being the most basic definition. Technical interoperabil-
ity is indeed important – without basic connectivity no interoperability can
be achieved – yet this definition of interoperability is not adequate for the
data-rich environment of healthcare.
The next level of interoperability is semantic interoperability. Rossi-
Mori et al. define five goal-based levels of computer-based handling of clin-
ical information. Drawing from Rossi-Mori et al.’s work on interoperabil-
ity [RMCR01], semantic interoperability operates on levels 2-5 in Table 1.1
(level 1 is technical interoperability).
The third level of interoperability is process interoperability. Process
interoperability refers to social or workflow engineering aspects of interop-
erability to promote holistic, system-wide interoperability. As such, it has
been identified as a requirement for successful system implementation in
actual work settings. Process interoperability includes such aspects as ex-
plicit user role specification, and that data presentation and flow support
the work setting.
The hierarchical aspect of the three definitions of interoperability is as
follows:

In the definitions of interoperability surveyed by the HL7 Interoperability
Work Group,
• technical interoperability was mentioned either alone or with the
other two types of interoperability;
• if semantic interoperability was mentioned, technical interoper-
ability was also mentioned;
• if process interoperability was mentioned, technical interoperabil-
ity and semantic interoperability were also mentioned.
The hierarchic definitions of interoperability lead to three actual levels
of interoperability based on these definitions. The levels can be summarised
by the two simple rules that process interoperability also requires semantic
and technical interoperability, and semantic interoperability first requires
technical interoperability.
In light of advances in interoperability in Health Informatics, the United
States branch of the IEEE redefined interoperability specifically for this
field in 2005, deeming the IEEE-90 definition too vague. The IEEE-USA
position statement says:
“the ability ‘to use the information that has been exchanged’
means not only that healthcare systems must be able to commu-
nicate with one another, but also that they must employ shared
terminology and definitions. This latter emphasis places a much
greater burden upon system designers and electronic engineers
to make the information truly usable in the distributed clinical
setting of our healthcare environment.” [IEE05]
They then go on in greater detail about actual steps toward interoper-
ability, and place semantic interoperability in the realm of shared terminol-
ogy, specifically SNOMED CT.

The work presented in this thesis concentrates on semantic interoper-
ability as the most important level of interoperability. Although process
interoperability is the highest interoperability level and also important, it
is specific to actual settings and different cases require different solutions.
Process interoperability is addressed in the final integration solution, the
Health Service Bus, as part of the overall system. Technical interoperabil-
ity is also covered (as the hierarchy of interoperability requires), but is triv-
ial compared to semantic interoperability.
1.4.2 Messaging as a Technical Interoperability

Solution
There are four main approaches to solving the problem of communicating
data between different applications and systems over a network (technical
interoperability): file transfer, shared database, remote procedure invoca-
tion and messaging [HW04].
File transfer and shared database involve multiple applications shar-
ing either a file or a database which they can all write to and read from.
The sharing applications need to agree on file/database location and data
format.
Remote Procedure Invocation (RPI) is when one application exposes some
of its functionality so that other applications can access it remotely. RPI re-
quires synchronous communication and tight coupling between processes.
The final and best solution to this problem is messaging. Messaging
involves applications publishing messages to a common message channel,
from which other applications can read the messages at a later time. Com-
munication is asynchronous, meaning that senders do not have to rely on
the receiver being up and running at the time of sending, and can also take
into account network outages. As such, messaging promotes loose coupling
of communicating applications. Messaging is the ultimate approach taken
for technical interoperability in this research.

1.5 Enterprise Integration Background
The traditional integration solution in healthcare is the “accidental archi-
tecture.” This refers to the practice of making point-to-point integration
solutions between applications as the need arises, leading to an ad-hoc, un-
scalable architecture that was never planned. This is typically what hap-
pens when a corporate-wide strategy for integration does not exist [Cha04].
Unfortunately, an accidental architecture perpetuates silos of information,
rather than providing a real integration solution. A good replacement setup
for an accidental architecture is an Enterprise Service Bus.
1.5.1 Enterprise Service Bus
Enterprise Service Bus (ESB) is a term which was coined at Stanford Uni-
versity and is used to describe a specific middleware software architec-
ture. An ESB has a standards-based messaging engine, which is event-
driven and provides foundational services for more complex software sys-
tems [Cha04]. ESBs are both operating system and programming lan-
guage independent, and provide interoperability between different plat-
forms; for example, between Java and .NET applications. ESBs are often
Web-Services based and use eXtensible Markup Language (XML) as a stan-
dard communications language.
According to the analyst firm, Gartner Inc., in 2003 [Yef03]:
“An Enterprise Service Bus is a new architecture that exploits
Web Services, messaging middleware, intelligent routing, and
transformation. ESBs act as a lightweight, ubiquitous integra-
tion backbone through which software services and application
components flow.” [Yef03]
Standards-based integration is a fundamental concept of ESB [Cha04],
thus it makes a fitting solution in the standards-filled realm of Health In-
formatics. Another reason that ESB is an excellent solution for healthcare

1.5. ENTERPRISE INTEGRATION BACKGROUND 43
is that it can incrementally replace the accidental architecture – there is no
need to replace existing integration solutions all at once. The ESB architec-
ture can be put into place with the old system still fully operational. Legacy
systems can then be changed over to the ESB one at a time, again with all
system components still operational. If the entire integration backbone had
to be replaced at once, it would be very difficult to find the time to do it in
the healthcare industry, which due to its nature has no downtime.
In recent years, ESB has become the most promising solution to build
an SOA infrastructure from several heterogeneous sources. Roa-Valverde
and Aldana-Montes argue that using Semantic Web Services in conjunction
with an ESB can overcome the problem of enterprise integration [RVAM08].
The Health Service Bus (HSB), the end result of this work, is an in-
teroperability solution based on ESB and using Web Services, putting into
practice messaging solutions with ontology mapping between three differ-
ent health standards.
1.5.2 Advantages of XML
In [Tay06], Taylor states that knowledge representation in the healthcare
domain can be greatly improved by using XML, as XML provides a syntax
for creating metadata and is intrinsic to the Semantic Web. Catley and
Frize also attest to the benefits of applying XML to integrate distributed
information sources within the medical community [CF02]. XML provides
a richer data model than traditional database models and makes data self-
describing [Cha04]. XML is dynamic and eliminates fixed formats.
Consider the following fragment of a HL7 V2 message (in EDI6 format):
PRD|RPˆReferring ProviderˆHL70286|BloggsˆJoeˆˆˆDrˆMD
6 Electronic Data Interchange

Now, compare it to the XML version:
<provider>
<role>
<code>RP</code>
<text>Discharging/Referring Provider</text>
<table>HL70286</table>
</role>
<name>
<last>
<family>Bloggs</family>
<last>
<first>Joe</first>
<title>Dr</title>
<qual>MD</qual>
</name>
</provider>
The XML version is lengthier, but is human-readable by comparison and
some context of the data can even be gained just by reading the tag names.
However, by the nature of XML, this depends on the choice of meaningful
tag names in the first place.
As Hohpe says, standardising all data exchange to XML can be likened
to writing all documents using a common alphabet, such as the Roman
alphabet [HW04] – a standard XML format is needed.
HL7 Versions 2 and 3 and openEHR all have defined XML formats as
part of their standard. All data representation and messaging in this trea-
tise is in XML, using published, standard formats in most cases. As men-
tioned in the previous subsection, ESBs typically use XML for communica-
tion.
1.6 Previous Work
1.6.1 Terminologies
Early work in the area of mapping clinical terminologies to each other was
done by Kannry et al.– in this case to examine the issues in mapping the
Medical Entities Dictionary (MED) at Columbia University to an institu-
tional vocabulary at Yale [KWS+ 96]. Their outcomes revealed the impor-
tance of standardisation of attribute representation, and term granularity.

1.6. PREVIOUS WORK 45
More recent research in mapping terminologies to each other includes
the Kaiser-Permanente Convergent Medical Terminology (CMT), which con-
verges three terminologies into a single poly-hierarchically structured knowl-
edge base. Dolin et al. reviewed the three major terminologies and de-
scribed their weak points in the course of creating the CMT [DMC+ 04]. The
terminologies they employ are SNOMED CT, LOINC, and First DataBank.
Relevant to the work presented here, with respect to HL7 Version 3 they
conjecture that standardising certain subsets of SNOMED CT concepts for
use in HL7 messages would greatly enhance interoperability, but first some
research would have to be conducted into where the HL7 information model
and SNOMED CT overlap, and some formal guidelines be developed. This
will be addressed in Chapter 5.
In the area of timely access to SNOMED CT, Ryan et al. have reported
on a joint project between the Royal Prince Alfred Hospital, Sydney and
the School of Information Technologies, University of Sydney, which com-
prises of the Ward Round Information System (WRIS) and a Clinical Data
Analytics Language (CDAL) [RPH08]. WRIS has been designed to convert
clinicians’ clinical notes into SNOMED CT and CDAL provides clinicians
with the ability to frame any question about their data and get the answer
almost immediately.
WRIS first computes an extract of the patient’s clinical record and then
presents this to the clinician. The clinician then enters any relevant progress
notes. WRIS than computes the SNOMED CT codes from these notes,
which the clinician verifies.
At this stage, CDAL is being run automatically every hour with just
one query – a process for identifying Acute Respiratory Distress Syndrome
(ARDS) candidates. Ryan et al. see one of the most significant achieve-
ments of this project to be the introduction of medical terminologies to the
clinicians, who were not previously aware of SNOMED CT [RPH08].
WRIS is not directly comparable to this work, but there is some small

overlap in the SNOMED CT terminology services employed in Chapters 7
and 8.
1.6.2 HL7 and Ontology Mapping
In the area of ontology mapping between HL7 and other health standards,
Magni et al. proposed the development of a standard comprised of HL7
Version 3 combined with DICOM for the storage and communication of
orthodontic patient records (ortho-EPR) [MdOAdSJ+ 07]. This standard
was proposed in the American Journal of Orthodontics and Dentofacial Or-
thodontics in 2007, and they predict three years until they have an outcome.
Spahni et al. describe the information technology difficulties encoun-
tered when six hospitals merged into one organisation, particularly with
ADT (Admission, Discharge, Transfer) databases [SLM+ 07]. Their solu-
tion is called Service d’Identification et de Localisation (SIL). SIL is based
on the HL7 Version 3 information model, as the new ADT had to comply
with the Java-based architecture of other new applications, thus HL7 V3
was chosen, as it has an objected-oriented modelling methodology.
Closer to the aims of this work is the Artemis Message Exchange Frame-
work (AMEF), created by Bicer et al. for semantic interoperability in the
healthcare domain [BLDK05a]. The aim of AMEF is to mediate between
any incompatible healthcare standards in use.
As a part of AMEF, Bicer et al. have also created a tool called OWLmt
for ontology mapping, which they then used for mapping HL7 V2 and HL7
V3 [BLDK05b]. Bicer et al. have also used OWLmt along with archetypes to
promote semantic interoperability between openEHR, HL7 CDA and CEN
13606 [BKDL05].
Also in the ontology mapping area, Kilic et al. have mapped openEHR’s
Archetype Description Language to OWL [KBD05] for use in the general
openEHR community, to facilitate mapping openEHR to other ontologies.
Ray and Jones discuss the same interoperability problem in the man-

1.6. PREVIOUS WORK 47
ufacturing industry, specifically in global supply chains, in [RJ06]. They
discuss the benefits of XML and argue that current syntax-based interoper-
ability methods are not adequate. To move toward semantic interoperabil-
ity, they describe ontology mapping between different standards. This is
the same problem addressed here in the healthcare industry, in which the
data is more complex.
1.6.3 Interoperability Frameworks
With respect to the information silo problem, the Eclipse Foundation is
working on a project called the Open Healthcare Framework (OHF) to allow
developers easy access to implementing standards, in the hopes of solving
this problem [Ecl08]. The OHF is for developers, so is a different type of
framework to the solution presented at the end of this work.
Returning to AMEF, mentioned in the previous section, a prototype demon-
stration mapping HL7 V2 to HL7 V3 is shown by the authors in [BLDK05a].
This involves ontology mapping of the HL7 V2 and V3 XML schemas to
each other using OWLmt. Existing applications are then wrapped as Web
Services and the messages they exchange are mediated through OWLmt.
Catley and Frize discuss the design of an XML-based medical informa-
tion infrastructure for integration of their clinical decision support tools [CF02].
Their aim is to enable their medical databases for XML, and then publish
XML schema to a publically-accessible central repository. They plan to al-
low their researchers secure Web-enabled access to the repository, as well
as allowing outside sources Web access to their decision support tools.
In [CF03], Catley and Frize present a prototype implementation of their
design in a Neonatal Intensive Care Unit (NICU). Their example imple-
mentation is in a distributed environment and involves an XML-enabled
interface to their application server.
Shabo and Hughes discuss the problem of interoperability in sharing a
patient’s family history [SH05]. They aim at semantic interoperability be-

tween different systems using the HL7 V3 Clinical Genomics Specifications
as a canonical information representation within the Semantic Web. The
paper concentrates on the HL7 models and XML representations of those
models without discussing the architectures over which the communication
will be possible, except to mention they hope to use the Semantic Web.
Previous work employing Enterprise Service Bus includes implementa-
tion in various industries, including financial services, insurance, manu-
facturing, retail, telecommunications, energy/utility, food distribution and
government. For example, a leading subprime lender implemented an ESB
and reduced application processing costs by 60%, a leading health insur-
ance company has generated significant savings using an ESB, and a U.S.
video retail chain has implemented an ESB to configure and manage 1,800
remote stores from a central management console [Cha04].
Liu et al. use an ESB for integration of a loan processing system to
demonstrate the architectural design patterns necessary to build an adap-
tive self-managing architecture that is capable of preventing or recovering
from failures [LBG08]. They implemented different versions of the appli-
cation on several ESB platforms, including Mule (also used in this work
in Chapter 8). They found that ESB supports the design of self-managing
architecture that have fault tolerance and fault prevention.
Specifically in the healthcare industry, Shakir et al. report on the im-
plementation of an SOA using HL7 V3 in the Los Angeles County Public
Health department [SCD+ 07]. They use HL7 V3 XML as the message for-
mat in their system, which is based on Enterprise Service Bus. They report
on specific details of their implementation, rather than a general solution
to the problem.
Comparison of relevant frameworks discussed here and the Health Ser-
vice Bus are carried out at the end of this work in Chapter 9.

Chapter 2
Health Standards
Background
Three Health Informatics standards are focused on in this work, as briefly
discussed in Section 1.3 of the previous chapter. This chapter goes into
greater detail of each standard, their purposes and their information mod-
els. First, HL7 is discussed – both the Version 2 and Version 3 methodolo-
gies and models are elaborated. Second, openEHR is explained, and finally
SNOMED CT.
The order in which the standards are presented is a purposeful pro-
gression toward semantic interoperability. Knowledge of HL7 is required
for communication, a big part of the solution toward the interoperability
problem. Next, a standard is required for storing information more per-
manently, assumably in patient records, so a knowledge of openEHR is re-
quired. Finally, a standard set of terms is needed for use in both the com-
munication and document standards to ensure exact meaning throughout
the process.
By using these three standards together, each for their intended pur-
pose, semantic interoperability becomes attainable; the beginnings of which
49
50 CHAPTER 2. HEALTH STANDARDS BACKGROUND
can be seen in Chapter 4 in which HL7 V3 messages based on SNOMED
CT concepts are used for communication in an industry-based project. On-
tology mapping between the three standards is then shown in Chapter 5.
2.1 Health Level Seven
Health Level Seven (HL7) is an ANSI-accredited Standards Development
Organisation (SDO) operating in the healthcare domain. It is a not-for-
profit volunteer organisation whose members develop the standards, the
most widely used being a messaging standard that enables disparate health-
care applications to exchange clinical and administrative data (referring to
HL7 Version 2) [Hin05, HL708].
Members of Health Level Seven are known collectively as the Working
Group, which is organized into Technical Committees (TCs) and Special In-
terest Groups (SIGs). The Technical Committees are directly responsible
for the content of the standards, while Special Interest Groups serve as a
test bed for exploring new areas.
The HL7 Interoperability Work Group, whose work “Coming To Terms”
[HL707] is taken as the definition of interoperability for this research is
part of the HL7 EHR Technical Committee (see Section 1.4.1).
The name “Health Level Seven” comes from the ISO standard for Open
Systems Interconnection (OSI), which specifies a set of levels for commu-
nication, the highest of which is level seven – the Application Level. The
Application Level deals with such issues as definition and structure of data
to be exchanged, timing of data exchange, and security checks [Sta04].
HL7’s organisational vision is “to create the best and most widely used
standards in healthcare.” [HL708]
HL7 Version 2 will first be described – the original HL7 messaging stan-
dard which has been in use since the late 1980s. After going into detail of
the methodology of this data exchange standard, the newer version (Version

2.1. HEALTH LEVEL SEVEN 51
3) will be described – a more extensible object-oriented standard.
2.1.1 HL7 Version 2
One of the most successful health information models is Version 2 of the
HL7 standard, in particular Version 2.3.1. However, this standard does not
achieve plug-and-play interoperability [Hin05, HBCH98]. In fact, any kind
of interoperability between communicating HL7 Version 2 systems can be
time-consuming to establish and require careful attention to detail, espe-
cially between existing systems that have not been designed to communi-
cate from the beginning [BLDK05b]. Also, because HL7 was first devel-
oped in 1987 to suit technology at that time, it is in Electronic Data In-
terchange (EDI) format – a syntax of different fields separated by “pipes”
(|) and “carets” (∧), where precision in the number of fields is a must, as
a single missing character could irreversibly convert the message into a
meaningless stream of text. EDI is still used in many industries but is
out-dated, being in a pre-Internet format based on ASCII-encoded single
messages, rather than focusing on communication exchange as a whole.
The HL7 organisation says this about the Version 2 messaging standard:
“These messages evolved over several years using a ‘bottom-up’
approach that has addressed individual needs through an evolv-
ing ad-hoc methodology. There is neither a consistent view of
that data that HL7 moves nor that data’s relationship to other
data.” [HL708]
As such, no semantic inference of the information can be determined
automatically.
HL7 Version 2 interoperability is on the level of simple exchange with a
defined message format, where the sending application structures the mes-
sage in an expected form (that is, the data elements appear in a defined way
within the message, but the meaning of the data is not specified) [HL707].

Referring to the levels of interoperability defined in Section 1.4.1, V2 is on
the level of technical interoperability.
HL7 V2’s success is largely attributable to its flexibility. It contains
many optional data elements and data segments, making it adaptable to
almost any site. However, this forces implementers to spend more time
analysing and planning their interfaces to ensure that both parties are
using the same optional features. This is why it is so time-consuming to
establish communication between existing systems.
While providing great flexibility, V2’s optionality also makes it impossi-
ble to have reliable conformance tests of any implementation. Its flexibility
means it does not provide interoperability. Problems aside, HL7 V2 is still
the most widely used health messaging standard, so an understanding of it
is required for a comprehensive grasp of the Health Informatics field.
HL7 Version 2 Message Models
In HL7 Version 2, messages are sent as the result of an actual event oc-
curring, called a trigger event [BLDK05b, HL708]. For example, a patient
referral is a trigger event, which has the code I12 in HL7. The I12 trig-
ger event results in the sending of a referral message (which has the code
REF, specifically REF I12, as it is sent due to the I12 trigger event occur-
ring). The REF I12 message requires a particular type of response – an
RRI I12 message (the code RRI I12 means a response to a referral which
resulted from trigger event I12). This RRI response message is basically an
acknowledgement message. Figure 2.1 shows the communications overview
for a REF code referral. Note that this interaction only results after a trig-
ger event, such as I12, has occurred. The REF with RRI response is the
simplest form of acknowledgement in the Version 2 standard, and more
complicated acknowledgement schemes are available.
HL7 Version 2 messages are defined as a series of segments which are
groupings of related data. Figure 2.2 is an overview of the representation

Figure 2.1: Communications overview for Patient Referral Message with

simple acknowledgement.
Figure 2.2: Overview of the representation of a HL7 V2 Message Segment.
of a Version 2 message segment, taken from [Sta04]. An arrow over the top
of a segment indicates that it may be repeated, while an arrow under the
segment indicates that it is optional. To read the message structure, the
lines and arrows are followed from left to right.
As an example, the beginning of a referral message structure is shown
in Figure 2.3. The MSH and RF1 segments are mandatory and must ap-
pear exactly once in the message, followed by the provider details seg-
ment (PRD), which can be repeated; the first instance may be the referring
provider and repeated instances of the segment could be for the referred-to
provider and then other responsible parties. Next, the extra patient de-
mographics (PD1) segment is optional, and finally the next of kin segment
(NK1) is optional or may be repeated.
The fields which make up each segment of a Version 2 message are
strictly defined, and data types are also strictly defined. As an example,
the fields for the MSH segment are shown in Table 2.1. The ‘DT’ attribute
in Table 2.1 refers to ‘datatype’ and has such values as ST (string data), HD

(hierarchic designator - unique ID of healthcare entity), TS (time stamp),
etc.
Version 2 messages are traditionally exchanged using EDI. However, an
XML specification has been developed to enable Version 2 messages to be
represented as XML to better suit modern implementer’s needs, e.g. for
transportation via Web Services.
Figure 2.3: Example structure of a HL7 Version 2 referral message.
Table 2.1: MSH segment fields.
Seq Len DT Opt Rp# Tbl# Item# Element name

1 1 ST R 00001 Field separator
2 4 ST R 00002 Encoding characters
3 180 HD O 00003 Sending application
4 180 HD O 00004 Sending facility
5 180 HD O 00005 Receiving application
6 180 HD O 00006 Receiving facility
7 26 TS O 00007 Date/time of message
8 40 ST O 00008 Security
9 7 CM R 0076 00009 Message type
0003
10 20 ST R 00010 Message control ID
11 3 PT R 0103 00011 Processing ID
0207
12 8 ID R 0104 00012 Version ID
13 15 NM O 00013 Sequence number
14 180 ST O 00014 Continuation pointer
15 2 ID O 0155 00015 Accept ack type
16 2 ID O 0155 00016 Application ack type
17 2 ID O 00017 Country code
18 6 ID O Y/3 0211 00692 Character set
19 60 CE O 00693 Principal language

2.1.2 HL7 Version 3
Version 2 of the HL7 standard is widely implemented; however it has been
increasingly difficult to support health information interoperability in to-
day’s rich computing environment using this methodology. Version 3 of
the HL7 standard incorporates a new paradigm for information represen-
tation and messaging in comparison to Version 2 in terms of a new infor-
mation model and intrinsic extensibility [HL708]. The Reference Informa-
tion Model (RIM) is the cornerstone of the HL7 Version 3 development pro-
cess. The RIM is an object model in the form of a large Unified Modelling
Language (UML) representation of clinical data and is a powerful abstract
model of healthcare [EIR06, HL708, Viz04].
HL7 Reference Information Model (RIM)
The RIM is the information model that encompasses the HL7 domain of
interest as a whole. It is a shared information model that is the source for
the data content of all HL7 messages and is intentionally abstract to al-
low the representation of the many information topics that must be shared
throughout a health system.
The RIM is comprised of six “back-bone” or core classes:
• Act – represents an action that is executed and must be documented
• Participation – expresses the context for an Act in terms such as
who performed it, for whom it was done, where it was done, etc.
• Entity – represents a physical thing or being that is of interest to, or
takes part in, healthcare
• Role – establishes a role that an Entity plays as it participates in
healthcare Acts, e.g. patient or care provider
• ActRelationship – represents the binding of one Act to another, e.g.

the relationship between an order for an observation and the observa-
tion event
• RoleLink – represents a relationship between individual Roles, e.g
the relationship between a Manager and an Employee. The Manager
Role would have the RoleLink ‘direct authority’ over the Employee
Role.
Three of these classes - Act, Entity and Role - are further repre-
sented by a set of specialized classes, or sub-types. For example, specialisa-
tions of the Act class include Observation, Procedure and Substance
Administration.
In HL7 Version 2, messages are sent based on trigger events occurring.
Correspondingly, in HL7 Version 3, messages are constructed around acts
that occur, for example, patient admissions, discharges and referrals, clini-
cal observations of a patient, medical procedures, etc.
The HL7 information model takes an act-centred view, with processes
and information in healthcare represented primarily in terms of the acts
performed within an organisational context [Viz04], as can be seen by the
nature of the RIM classes.
Figure 2.4: The Core Classes of the HL7 Version 3 Reference Information
Model (RIM).

Figure 2.4 shows the Core classes in the HL7 Version 3 RIM, and how
they interact. The full RIM is shown in Appendix A. The typical way these
classes interact is as follows:
An Entity playing a Role Participates in an Act.
Just like the HL7 Version 2 segments are made up of data fields, the
Version 3 classes are made up of attributes. Unlike Version 2, in which
fields are a serial list of data, the V3 classes are objects and are related to
other classes by certain relationships. The attributes of the Act class are
shown in Table 2.2 as an example. As can be seen in the Table, HL7 Version
3 has strict datatypes which are very similar to the Version 2 datatypes.
The second column contains the datatype, which includes such types as CS
(Code String), SET<II> (a Set of Instance Identifiers), and GTS (General
Time Stamp).
Table 2.2: Act Class Attributes (Card = Cardinality, Mand = Mandatory).
Name Data Type Coding Card Mand

classCode CS CNE 1..1 M
moodCode CS CNE 1..1 M
id SET<II> CNE 0..*
code CD CWE 0..1
negationInd BL 0..1
derivationExpr ST 0..1
title ED 0..1
text ED 0..1
statusCode CS CNE 0..1
effectiveTime GTS 0..1
activityTime GTS 0..1
availabilityTime GTS 0..1
priorityCode SET<CE> CWE 0..*
confidentialityCode SET<CE> CWE 0..*
repeatNumber IVL<INT> 0..1
interruptibleInd BL 0..1
levelCode CE CWE 0..1
independentInd BL 0..1
uncertaintyCode CE CNE 0..1
reasonCode SET<CE> CWE 0..*
languageCode CE CWE 0..1

Figure 2.5: A simple example of a HL7 Version 3 model based on the RIM.
One problem with the RIM is that it is so complex that there is some
overhead required in studying it to completely grasp it before it can be
used. However, Spahni et al. found this overhead to be worth the in-depth
understanding for the future of their system [SLM+ 07].
An example model from the RIM is shown in Figure 2.5. It consists of
an Act, which has an ActRelationship (component) with another Act.
Both Acts have the attributes classCode and moodCode, as these are
mandatory (see Table 2.2). They also have the attribute id which has been
strengthened to only one mandatory value, instead of a set of optional val-
ues (datatype, coding strength and cardinality can all be constrained as
necessary, the base class definition being a minimum strength). They also
have the attributes code and text, and the main Act has the attribute
statusCode. The main Act also has a participant, which is an Entity
playing a Role.
This simple example also shows the colouring conventions of the HL7
RIM. Acts are always coloured pink (‘salmon’), with ActRelationships
the same colour in a lighter shade, while Entities are shown in green,
Roles in yellow and Participations in blue. The other class not shown
in the example is RoleLink, which is always shown in a lighter shade of
Role-yellow.

Other HL7 Version 3 Models
A Domain Message Information Model (DMIM) is a refined subset of the
RIM that can be used to create messages for a particular domain.
The DMIM for Observations is shown in Figure 2.6. All HL7 models
(except the RIM) have an entry point, which can be seen in Figure 2.6 as the
white box at the top which says ‘Observations DMIM’. The entry point must
point to a central Act in the model, which is taken as the starting point for
reading the model. This is similar to the Version 2 trigger event. It can be
seen that no models can be created without a central Act occurring.

Figure 2.6: The HL7 Observations DMIM (POOB DM200000UV).

c Copyright 2008 Health Level Seven.

A Refined Message Information Model (RMIM) is subset of a DMIM that
is used to express the information content for a message or set of messages.
The content of an RMIM is drawn from the DMIM for the specific domain
in which the RMIM is used.
Figure 2.7 shows an example RMIM for Clinical Observations. The en-
try point is the Act called ‘ClinicalObservations’ which is an instance of
the class patientCareProvision, a specialisation of Act. The Clinical
Observations Act has many component Acts which are called ‘BloodSug-
arLevel’, ‘Urinalysis’, ‘OxygenSaturation’, ‘Weight’, etc. All of these compo-
nent Acts are instances of the specialisation Observation.
There are two participants in the Clinical Observations Act – the ‘sub-
ject’ and the ‘performer’. The subject is a Person (specialisation of Entity)
playing the Role of ‘Patient’, and the performer is a Person playing the
Role of ‘CareGiver’.
Figure 2.7: Example RMIM for Clinical Observations.

A Hierarchical Message Description (HMD) is an RMIM which has been
“flattened”, starting at the entry point, to specifically describe a message
that can be sent. An instance of a message is then rendered from the HMD
in XML. Figure 2.8 shows part of an HMD from the RMIM shown in Figure
2.7. The Element Names in the HMD (second column in the figure) are
indented to show the hierarchy over the elements in the message, making
it easy to represent in XML using the same hierarchy structure for the XML
tags.
Using the HL7 Version 3 XML Implementable Technology Specification
(ITS), the HMD can be represented in XML and populated with attribute
values to create a message instance. A part of an XML message instance
from the HMD is shown in Figure 2.9.
HL7 Version 3 and the Semantic Web
The goal of the Semantic Web is “to create a universal medium for the ex-
change of data.” [W3C01]. The vision for the Semantic Web is a web of data.
The original Web concentrates on the interchange of documents, but the Se-
mantic Web is about common formats for integration and the combination
of data drawn from diverse sources.
It can be seen that HL7 Version 3 is in line with the Semantic Web vision
which has a similar document sharing mentality, and thus a progressive
and powerful information model for healthcare. The HL7 V3 information
model is therefore an excellent choice of model to use toward the goal of
attaining semantic interoperability.
2.1.3 HL7 Version 2 and Version 3

Compatibility
HL7 V3 goals cannot be achieved while maintaining full compatibility with
previous versions [HL708]. However, HL7 does say that Version 3 will cover

Figure 2.8: Part of the HMD from the RMIM shown in Figure 2.7.
Figure 2.9: Part of an XML message instance from the HMD shown in
Figure 2.8.

the information content of the last version in the V2 series, although this
should not be construed to mean that all attributes and events will be in-
cluded in V3 in exactly the same form as within the V2 series.
This does mean, however, that translation between XML representa-
tions of HL7 Versions 2 and 3 is achievable, as the same content is being
covered in both, but in different forms. As discussed previously, the Version
2 and Version 3 datatypes are very similar, which is a good starting point
for translation. Translation between the two HL7 versions is discussed in
Chapter 5.
2.1.4 Conclusions on HL7
An understanding of HL7 Version 2 is vital to understanding current sys-
tems in Health Informatics and in understanding where the field has come
from. However, this standard does not take advantage of improvements in
computing and networks since it was first introduced, and can actually im-
pede interoperability because of its optionality. This standard is used in a
messaging prototype discussed in Chapter 3.
HL7 Version 3 is a more sophisticated, object-oriented information mod-
elling standard which is in line with new standards in computing. Its so-
phistication does lead to a steep learning curve, although this overhead is
worth it in the long term for interoperability. The V3 standard was used in
the ePOC project (Chapter 4), the Jini Health Interoperability Framework
(Chapter 7), and also in the Health Service Bus (Chapter 8).
Translation between the two versions of HL7 is possible and attainable,
and an XML transform from HL7 Version 2 to Version 3, and vice versa, is
one of the services in the interoperability frameworks discussed in Chap-
ters 7 and 8. This allows legacy systems to be connected to the new inter-
operability frameworks based on HL7 V3.
HL7 Version 3 is an excellent information model for health, and an im-
portant tool in attaining semantic interoperability. However, a defined ter-

minology is needed for exact meaning of the actual information contained
in the model, which is discussed in Section 2.3. Meanwhile, the next section
goes on to explain openEHR in detail, a health document sharing standard
also employed in the final interoperability solution.

2.2. OPENEHR 65
2.2 openEHR
As mentioned in Section 1.1.1 (Electronic Patient Care Records), a key re-
search area of Health Informatics is the development of electronic patient
record systems. For example, a common goal is to allow information from
different providers to be merged to create a single health record of a pa-
tient’s care, from birth to death [Tay06]. openEHR is one initiative which is
supporting the development of such systems.
openEHR is an international not-for-profit foundation developing open
specifications and open-source software for Health Informatics [Ope08a].
The openEHR endeavour is about creating high-quality, reusable clinical
models known as archetypes.
openEHR has generic, high-level concepts defined in a small reference
model, and as such can handle many different healthcare concepts. How-
ever, the small number of generic concepts in the model is not enough to
describe the semantics of the domain-specific concepts – these are described
through archetypes [KBD05]. Thus the openEHR model is describes as a
two-layer model in which the domain model is separate to the information
model.
The next sections explain the openEHR information model and arche-
types, followed by a detailed example, and finally a comparison between
openEHR and HL7 ends this section.
2.2.1 The openEHR Information Model
The openEHR information model is highly abstracted and provides a con-
ceptual model of what a patient record is, rather than describing any clin-
ical content. In openEHR, an Electronic Health Record consists of a set of
Compositions. Compositions are the top-level ‘data container’ and are used
to record information about events as well as persistent data items (e.g. a
patient’s family history, vaccination history, etc) [Tay06]. Figure 2.10 shows

Figure 2.10: Overview of the Structure of the openEHR Information Model.
an overview of the openEHR information model.
As can be seen in Figure 2.10, the Content of a Composition consists of
a Navigation and an Entry. The Navigation provides the structure used to
organise information in the record. The Entry contains information that
is to be recorded, as one of four types: action, observation, evaluation or
instruction.
An EHR can contain multiple Compositions, and likewise a Composition
can contain multiple Contents, which can contain multiple Navigations and
Entries. Figure 2.10 simply shows how each of these types of structures
relate to each other in the openEHR information model.

2.2. OPENEHR 67
2.2.2 openEHR Archetypes
An archetype is a reusable, formal model of a domain concept. The key
feature of the archetype approach to computing is a complete separation of
information models from domain models. Unlike some software engineer-
ing methods, the domain concepts are not simply represented by another
layer of a class model, but by a library of domain concepts, defined by a
constraint language [Ope08a].
With respect to the openEHR information model, this means that arche-
types exist for different Entries and structures (Navigations), and even at a
higher level for Compositions. The information model deals with high level
concepts of what an EHR is, while the domain concepts, such as clinical
observations, are modelled by archetypes written in a constraint language.
In healthcare, concepts that can be modelled using archetypes are the
kinds of data which occur in health information systems, including things
like:
• weight measurement
• blood pressure
• microbiology results
• discharge referral
• prescription
• diagnosis
‘Weight measurement’, ‘blood pressure’ and ‘microbiology results’ are ob-
servation Entries, while ‘discharge referral’ and ‘prescription’ are Composi-
tions, and finally, ‘diagnosis’ is an evaluation Entry. These are just some
examples of domain concepts which can be modelled as archetypes to be
used within the overall EHR model.

An archetype is composed of three sections: header, definition and
ontology, outlined below:
• The header section contains a unique identifier for the archetype as
well as metadata such as author, version and status.
• The definition section contains constraints in a tree-like structure of
nodes. This structure constrains the cardinality and content of EHR
instances complying with the archetype.
• The ontology section contains codes representing the meanings of
nodes used in the definition section, as well as bindings of these terms
to terminologies such as SNOMED CT.
The constraint language used to define openEHR archetypes is called
Archetype Description Language (ADL).
2.2.3 Archetype Description Language (ADL)
ADL is a constraint language developed by openEHR. ADL is actually a
simple “glue” syntax, which uses three other syntaxes for expressing struc-
tured constraints and data [BH04]. cADL (a constraint expression syntax)
is used to express the archetype definition, while dADL (a data expres-
sion syntax) is used to express data which appears in the ‘language’, ‘de-
scription’, ‘ontology’, and ‘revision history’ sections of an ADL archetype.
Finally, FOPL (a version of first-order predicate logic) is used to describe
constraints on data which are instances of some information model. The
top-level structure of an ADL archetype is shown in Figure 2.11.
ADL version used in this work
The current version of ADL is 1.4, but a newer version of ADL, version
2, has been developed and openEHR hopes to migrate their existing arch-
etypes over to this new version in the near future. ADL 2 archetypes use

2.2. OPENEHR 69
Figure 2.11: ADL Archetype Structure. The sections not in bold are op-
tional. c Copyright openEHR Foundation 2001-2006. All rights reserved.
www.openEHR.org.

two of the same syntaxes as ADL 1.4 (cADL and dADL), and replaces FOPL
with aADL (an assertion expression syntax), along with other small differ-
ences [BH06]. All references to ADL and archetypes in this work are ADL
1.4.
2.2.4 openEHR example
Figure 2.12 shows an example of an archetype on a generic model, ‘Observa-
tion’, for the concept ‘Height’ (the characters “−−” denote a comment). This
example has been simplified from the full openEHR archetype [Hea06] (the
complete archetype is shown in Appendix B). The header is made up of the
archetype, concept, language and description sections:
archetype(adl version=1.4)
openEHR-EHR-OBSERVATION.height.v1
concept
[at0000]{ −− Height
language
original language = <[“en”]>
translations = <[“de”]>
description
details = <
purpose = <“Recording the total length of the body from crown of head to sole of foot.”>
keywords = <“height”, “length”>
lifecycle state = <“AuthorDraft”>
>
This means that the identifier for the archetype is “openEHR-EHR-
OBSERVATION.height.v1” and the concept that this archetype is referring
to is ‘at0000’ (this is explained shortly in the upcoming discussion of the
ontology section). The language section states that the archetype was writ-
ten in English (en) and has been translated into German (de) (however,
the German translations have been omitted from the example for simplic-
ity). Next, the description contains details on the purpose and use of the
archetype.
In the definition section, it is seen that ‘Height’ is defined in terms of
constraints on a generic model called OBSERVATION. The other classes
which make up the definition of Height (“data”, “EVENT”, “ELEMENT”,

2.2. OPENEHR 71
Figure 2.12: An example of an Archetype, showing the syntax of

ADL. c Copyright openEHR Foundation 2001-2006. All rights reserved.
www.openEHR.org.

etc) are part of the OBSERVATION model. The definition section is as
follows:
definition
OBSERVATION[at0000] matches { −− Height
data matches {
EVENT[at0001] matches { −− Any event
data matches {
ELEMENT[at0002] matches { −− Height
name matches {
DV CODED TEXT matches {
defining code matches {
[local::at0003, −− Height
at0004] −− Length
}
}
}
value matches {
C DV QUANTITY <
units = <“cm”>
magnitude = < |0..1000| >
>
}
}
}
}
}
}
As an overview, this section says that at0000 is of the type OBSERVA-
TION and is interpreted as follows:
• OBSERVATION at0000 is defined as containing ‘data’ consisting of a
specific EVENT, at0001;
• the EVENT is then defined as containing data consisting of a specific
ELEMENT, at0002;
• the ELEMENT is defined as consisting of a ‘name’ and a ‘value’.
• ‘name’ is of datatype DV CODED TEXT which has a ‘defining code’
which must be either at0003 or at0004.
• ‘value’ is of datatype C DV QUANTITY consisting of a magnitude be-
tween 0 and 1000 in the units of cm.
“local::at0003” means that the term ‘at0003’ is defined locally in the on-
tology section of the archetype, as opposed to being from an outside refer-
ence terminology such as SNOMED CT. In fact, all of the terms used in the

2.2. OPENEHR 73
header and definition sections of the archetype (at0000, at0001, at0002) are
defined in the ontology section, shown below:
ontology
term definitions = <
items = <
[“at0000”] = <
text = <“Height”>
description = <“Height (or Length) of the body is measured from crown of
head to sole of foot. In general, length measurements are recommended for
children under 2 years of age and individuals who cannot stand;
height measurements for all others.”>
>
[“at0001”] = <
text = <“Any event”>
description = <“Any measurement of height”>
>
[“at0002”] = <
description = <“The length of the body from crown of head to sole of foot.”>
>
[“at0003”] = <
description = <“Length of body in standing position”>
>
[“at0004”] = <
text = <“Length”>
description = <“The length of the body supine”>
>
>
>
This section defines at0000 as “Height” and provides a definition for it,
thus saying that whenever at0000 is mentioned in this archetype what is
actually meant is Height. Note that there are actually three codes with the
text “Height”, but the definitions are different, each more specific than the
last. So, at0000 actually refers to either a height or length measurement
and includes recommendations for the correct situation in which to per-
form each (e.g. a length measurement is recommended for children under
2 years).
Although at0001 has the text “Any event”, we can see by the definition
that it actually refers to any height measuring event. The second Height
code, at0002 refers to the length of the body, and the third Height code,
at0003 refers specifically to the length of the body while standing, as op-
posed to the length of the body while supine, which is called Length. The

ontology section has clearly defined the three related height concepts into
three distinct concepts with no question about which concept of height is
being referred to at each stage (the purpose of terminology).
Looking back at the definition section, it can be seen that a height ob-
servation (at0000) consists of any height measuring event (at0001) which
in turn consists of a height measurement (at0002) – which is specifically
either a standing height (at0003) or a supine length (at0004), and has a
magnitude in cm.
openEHR has an XML Implementable Technology Specification (ITS),
allowing archetype instances to be represented in XML in a standard way.
The definition section is the part of the archetype which is represented in
XML in an archetype instance. Like the HL7 HMD, the hierarchical struc-
ture of the definition section makes representing it in XML a simple matter.
An XML instance of the height archetype could be as follows:
<OBSERVATION archetype node id=“at0000”>

<name>
<value>Height</value>
</name>
<archetype details>
<archetype id>openEHR-EHR-OBSERVATION.height.v1</archetype id>
<rm version>1.4</rm version>
</archetype details>
<data>
<EVENT archetype node id=“at0001”>
<name>
<value>Any event</value>
</name>
<data>
<ELEMENT archetype node id=“at0002”>
<name>
<value>Height</value>
<mappings>
<match>Length</match>
<target>
<terminology id>
<value>local</value>
<code string>at0004</code string>
</terminology id>
</target>
</mappings>
</name>
<value>
<units>cm</units>
<magnitude>80</magnitude>
</value>
</ELEMENT>
</data>

2.2. OPENEHR 75
</EVENT>
</data>
</OBSERVATION>
This height instance is a length measurement of 80cm, an observation
for a child under the age of 2.
The complete archetype contains other information, such as growth and
loss of height measures, and what device was used to take the height mea-
surement. The full archetype is shown in Appendix B.
2.2.5 openEHR and HL7
The biggest difference between HL7 and openEHR, which most other differ-
ences stem from, is the fact that they have different purposes. In particular,
HL7 does not generally address EHR requirements. HL7, at its core, is a
messaging standard and openEHR is essentially a document-sharing stan-
dard.
openEHR is predicated on a few key design principles which differ in
emphasis from the HL7 standards development process. One of the main
differences is openEHR’s two-level approach to modelling [Ope08a].
HL7 is act-centred and based on events, due to the fact that it started
out as a messaging standard, while openEHR is patient-centred, allowing
a patient’s lifelong record to be stored and added to, as events occur or as
more information is collected.
However, one of HL7’s Version 3 standards called the Clinical Document
Architecture (CDA) provides a relatively generic model for the communica-
tion of clinical documents, as opposed to discrete messages (see also Section
1.1.3). Work is commencing on HL7 templates, described as “constraint
models for existing HL7 specifications” [HL708]. This is the HL7 equiva-
lent of the two-level modelling approach for persistent storage of clinical
documents, and essentially involves XML markup on the CDA. openEHR
was chosen for document storage purposes over the HL7 CDA in this work,

as the two-level modelling approach makes for flexible and robust EHRs,
and HL7 templates are not as far advanced as archetypes at this stage.
A good interoperability solution using both of these standards is to use
HL7 for transportation of information, and to use openEHR as a persistent
EHR into which the information from the HL7 messages can be fed and
stored. This takes advantage of HL7’s strong point – the representation of
healthcare acts for communicating between entities – and also openEHR’s
strength of recording EHRs in a persistent and robust manner, thus ex-
ploiting the best points of each standard.
openEHR has an XML ITS which allows EHRs to be represented as XML
and then transported between healthcare entities (see the XML example in
the previous section). This means that a translation between openEHR
XML and HL7 XML is possible after mapping between the two, which is
discussed in Chapter 5.
2.2.6 Conclusions on openEHR
openEHR provides an interoperable standard for an Electronic Health Re-
cord which separates the domain model from the information model via
archetypes. The generality of the openEHR information model means that
many different concepts can be represented and it is robust and extensible.
Specific clinical constructs are then constrained by using archetypes, which
are expressed in the openEHR constraint language, ADL.
openEHR can interact with HL7 by storing information from HL7 mes-
sages in persistent EHRs, thus using both standards for the purpose they
were designed for, contributing to the overall strength of a healthcare infor-
mation system.
openEHR also has the capability to interact with terminologies such as
SNOMED CT for even greater semantic interoperability, which will be dis-
cussed in the next section.

2.3. SNOMED CT 77
2.3 SNOMED CT
HL7 and openEHR provide excellent models for interoperability in mes-
saging and health records, respectively. However, when it comes to actual
message and document instances, populating these models with informa-
tion could cause problems to arise if consistent terms are not used between
communicating parties, or even between two clinicians at the same site. A
standard terminology is required to achieve semantic interoperability.
One of the biggest obstructions to communication occurs when there are
multiple ways of describing a single concept. For example, one person may
write potassium as “pot” another may write potassium as “K” (the chem-
ical symbol of potassium). This can make inferring semantics a complex
problem. A standard vocabulary with which to populate the information
model with meaningful data can solve this problem. A standard code for
potassium would solve the communication problem in the example.
Systemised Nomenclature of Medicine - Clinical Terms (SNOMED CT)
is a universal and international standard terminology for healthcare and
contains more than 344,000 active concepts: the most comprehensive clini-
cal vocabulary available in any language, covering most aspects of clinical
medicine [Uni08b].
SNOMED CT was a joint development between the College of Ameri-
can Pathologists (CAP) and the National Health Service (NHS) in the UK,
representing the convergence of two other terminologies – SNOMED RT
and Clinical Terms version 3 (CTv3) (see also Section 1.1.2). SNOMED
CT’s intellectual property has been transferred by these bodies to the In-
ternational Healthcare Terminology Standards Development Organisation
(IHTSDO)1 for future development [IHT08].
This section explains the SNOMED CT terminology, and then briefly
shows how SNOMED CT can be used within the HL7 and openEHR models.
1 http://www.ihtsdo.org/

2.3.1 SNOMED CT Concepts and Relationships
SNOMED CT is a multiple-inheritance hierarchy made up of concepts and
their attributes. Attributes of concepts consist of relationships to other con-
cepts, so relationships are modelled as a triple of (concept, attribute, con-
cept). Each concept is identified by a unique identifier, called an SCTID
(SNOMED CT Identifier).
Some examples of concept groups in SNOMED CT are as follows:
• Clinical Findings – the results of a clinical observation, assessment
or finding.
• Procedures – purposeful activities performed in the provision of
health care.
• Body Structures – normal and abnormal body structures.
• Substances – active chemical constituents of drug products, food,
chemical allergens, toxicity information, etc.
• Physical Objects – natural and man-made objects.
• Events – occurrences that result in injury.
• Observable Entities – procedures or questions which, when com-
bined with a result, constitute a finding.
• Qualifier Values - concepts not contained elsewhere in SNOMED CT
which are required for attributes e.g. open, left, right, etc.
These “concept groups” are actually concepts themselves and are at the
top-level in the SNOMED CT hierarchy. Top-level concepts are concepts
that are the direct children of the root concept. The root concept is the sin-
gle, topmost concept in SNOMED CT and is SNOMED CT Concept (SCTID
138875005).
Attributes in SNOMED CT are concepts themselves, belonging to the
concept group Attribute. Therefore, attributes are a restricted vocabulary

2.3. SNOMED CT 79
within the terminology with the same properties as all other concepts in
SNOMED CT.
2.3.2 SNOMED CT Example
An example concept of ‘blood pressure reading’ and its attributes (in the
form of other SNOMED CT concepts) is shown in Figure 2.13. The cen-
tral concept is O/E - blood pressure reading (O/E stands for on examina-
tion) and belongs to the concept group Clinical Findings. This concept is
a subtype of both O/E - specified examination findings and blood pressure
finding (denoted by the ‘is a’ relationship). The Clinical Finding interprets
the Observable Entity ‘blood pressure’ and has various ‘finding’ attributes
(informer, method and site). Two of the subtypes of O/E - blood pressure
reading are systolic and diastolic blood pressure readings. The SNOMED
CT relationships from Figure 2.13 are equivalent to Table 2.3.
Figure 2.13: Blood pressure reading concept and its attributes in SNOMED
CT.

Table 2.3: SNOMED CT relationships shown in Figure 2.13. Relationships

in SNOMED CT are modelled as a triple of (concept, attribute, concept).
Concept Attribute Concept

o/e - blood pressure reading is a o/e - specified examination
findings
o/e - blood pressure reading is a blood pressure finding
o/e - blood pressure reading interprets blood pressure
o/e - blood pressure reading site structure of cardiovascular
system
o/e - blood pressure reading informer performer of method
o/e - blood pressure reading method physical examination proce-
dure
o/e - Systolic BP reading is a o/e - blood pressure reading
o/e - Diastolic BP reading is a o/e - blood pressure reading
Looking at Figure 2.13, the finding site is structure of cardiovascular
system. This is a very general concept for the site of a blood pressure read-
ing. However, this value is merely to restrict the possible values to any
concept which is a subtype of structure of cardiovascular system. This con-
cept is the supertype of entire brachial artery, which this attribute could
be specialised to if the blood pressure reading was taken from the patient’s
arm. Similarly, for finding method, physical examination procedure is very
general, but by specialising down the hierarchy, taking patient vital signs
could be used, or the subtype of taking patient vital signs: blood pressure
taking. An example showing more specific concepts is shown in Figure 2.14.
2.3.3 Representation of Clinical Findings

with SNOMED CT
As is seen in later chapters, much of the work in this thesis are artifacts
based on clinical observations and findings data, using the clinical find-
ing results as example message payloads. The ontology mappings between
SNOMED CT and HL7, HL7 Versions 2 and 3, and HL7 and openEHR
in Chapter 5 all use clinical observations and findings as examples. This
means some discussion of representing these types of information in SNO-

2.3. SNOMED CT 81
Figure 2.14: Blood pressure reading concept with more specific attribute
values.
MED CT is required.
According to Markwell [Mar06], statements about clinical findings can
be divided into two categories: those in which there are two clearly distinct
facets (example 1 below) and those which are often captured as a single
“nominalized” expression (example 2 below):
(1) Pulse rate = 82 beats/minute
(2) Has fracture of right femur
Looking at (1), the two facets are separated by the equal sign (=); the
first being the property which was observed (Pulse rate) and the second the
result of the observation (82 beats/minute).
Clinical findings in the second category (2) raise many issues in where,
or even whether, to split the different concepts represented by the state-
ment. This is an example of where problems can arise in using SNOMED
CT. Some examples of where to split this type of finding are shown in ex-
amples 3 and 4:

(3) Property = right femur, finding = fracture
(4) Omit property, finding = fracture of right femur
In (3), the clinical finding has been split into two facets in an attempt
to model the simpler type of finding. In (4), the concepts represented in the
clinical finding have not been split at all. It can be seen where problems
may arise when different people use different methods of representation,
especially in situations where there are many concepts combined to create
one finding, hence causing many more forms of representation. For exam-
ple, “the patient has a family history of myocardial infarction” could have
many different representations.
SNOMED CT can be used to represent clinical findings in either of these
ways, as there exists some very specific concepts in the terminology which
could be made up of more general findings grouped together. For example,
fracture of femur is the SNOMED CT concept with SCTID 71620000, but
it can also be represented by using the concept fracture (SCTID 72704001)
with the concept femur (SCTID 182046008), and there are many more com-
plex examples of this within the terminology.
As such, SNOMED CT is not a full ontology in the strict sense as it
contains redundancies and multiple ways of expressing the same knowl-
edge [Pat06, HSV06]. This is due to the fact that it has evolved over 40
years and was made from merging the two other terminologies, SNOMED
RT and CTv3, in the late 1990s [IHT08]. This means that in some cases it
is possible to express the same idea either as a single concept or as a group
of concepts, as seen in the previous examples. SNOMED CT is still the
most advanced and comprehensive health terminology in existence today,
but some additional constraints, or usage rules need to be followed when
using SNOMED CT or it may end up contributing to ambiguity rather than
enabling unambiguous exchange.

2.4. SNOMED CT CONCEPTS
REPRESENTED IN OPENEHR 83
2.3.4 SNOMED CT Concepts

Represented in HL7
HL7 objects, no matter what class they belong to, all have an attribute
called code. This attribute can be populated with a corresponding SNO-
MED CT concept’s code. There are also other code-type attributes in HL7
which could correspond to some SNOMED CT attributes, for example the
Act attribute targetSiteCode could contain a SNOMED CT code corre-
sponding to a finding site concept.
Careful thought has to be put into mapping these two ontologies, taking
into account the points on representation raised in the previous section.
This is covered in Chapter 5.
2.4 SNOMED CT Concepts
Represented in openEHR
A SNOMED CT concept can be entered into the ontology section of an
openEHR archetype, which then dictates which codes are allowed in EHR
instances of that archetype. The openEHR ontology section can also have a
term bindings part, which shows how the local codes (e.g. at0000, at0001,
etc) bind to outside reference terminologies, such as SNOMED CT. Revis-
iting the openEHR height archetype example in Section 2.2.4, the ontology
section with bindings to SNOMED CT could look something like the follow-
ing:
ontology
terminologies available = <“SNOMED-CT”>
items = <
[“at0000”] = <
description = <“Height (or Length) of the body is measured from crown of
head to sole of foot. In general, length measurements are recommended for
children under 2 years of age and individuals who cannot stand;
height measurements for all others.”>
>
[“at0001”] = <


description = <“Any measurement of height”>
>
[“at0002”] = <
>
[“at0003”] = <
>
[“at0004”] = <
>
>
>
term binding =<
[“SNOMED-CT”] =<
items =<
[“at0000”] = <[SNOMED-CT(2008::271603002]> −− height/growth measure
[“at0002”] = <[SNOMED-CT(2008::50373000]> −− body height measure
[“at0003”] = <[SNOMED-CT(2008::248333004]> −− standing height
[“at0004”] = <[SNOMED-CT(2008::248334005]> −− length of body
>
>
>
Thus, the SNOMED CT concepts are bound to the local terms using their
concept ids, showing that the concept “at0000” in this archetype refers to
the SNOMED CT concept for height/growth measure, the concept “at0002”
in this archetype refers to the SNOMED CT concept for body height mea-
sure, etc.
Current work in the Health Informatics industry in this area includes
work going on in both openEHR and the UK’s NHS to integrate SNOMED
CT and openEHR by binding SNOMED CT to archetypes [Ope08a]. A
terminology subsetting language is also being created by Ocean Informat-
ics2 , an Australian Health Informatics company focused on the construc-
tion of open interoperable systems for shared electronic health records. The
IHTSDO will collaborate with Ocean Informatics to use this language to en-
able creation of reusable subsets of SNOMED CT and other terminologies
which openEHR is planning to adopt [Ope08a].
2 http://oceaninformatics.com/

2.4. SNOMED CT CONCEPTS
REPRESENTED IN OPENEHR 85
2.4.1 Conclusions on SNOMED CT
Information models such as HL7 and openEHR, while providing robust,
flexible information models, cannot solve the interoperability problem alone.
A defined terminology is required to achieve semantic interoperability, to
ensure all communicating parties are using consistent terms within the in-
formation models.
SNOMED CT is the largest and most widely used terminology in the
healthcare domain, and thus is employed in this work. SNOMED CT is
used in conjunction with openEHR in the final interoperability solution
discussed in Chapter 8. Chapter 5 discusses ontology mapping from SNO-
MED CT to HL7, methods which were started in the ePOC project, and are
again used in the Jini Health Interoperability Framework (HIF-J) and in
the Health Service Bus (HSB).
Before getting to these projects, however, a small prototype referral sys-
tem was developed based on HL7 V2 and is discussed in the next chapter.


Chapter 3
Referral Messaging
Prototype
The next step in the semantic interoperability journey, after researching
current technologies and standards in the Health Informatics field, was
to implement a prototype interoperability system in order to test out this
new knowledge and these standards. A small demonstration system to test
out HL7 messaging standards, in particular referral messages, was decided
upon and is described in this chapter.
A major part of this research is the ePOC project, which is described in
detail in the next chapter (Chapter 4). One of the requirements of ePOC was
an interoperability solution using current Health Informatics standards, so
this prototype was also the first step on the way to that project.
3.1 Referral Scenario and Workflow Model
Every time a patient is referred by a general practitioner to any sort of
specialist, communication is required between these two entities. Referrals
are a classic situation requiring communication between different entities
in healthcare. For this reason, referral messages were chosen as the basis
87
88 CHAPTER 3. REFERRAL MESSAGING PROTOTYPE
of the prototype system. At the time the prototype system was developed,
referral messages were also an important part of the ePOC project, so it was
thought that this work may form a basis for that project. However, due to
circumstances beyond the project team’s control, referrals did not end up as
a part of that project because communicating with an existing information
system (required for referrals) proved impractical, for reasons outlined in
Section 4.3.
A simple workflow consisting of two general practitioners (GPs) and a
specialist were used as the basis for the message flow in the referral system.
The messaging system that was developed could, however, communicate
between any number of GPs and Specialists.
The flow of patients between the two GPs and the Specialist is shown in
Figure 3.1. A patient’s flow is shown as arrows between the GP and Spe-
cialist entities. A patient enters the system by visiting a GP (Admit). The
patient can then be referred back and forth between GPs and the Special-
ist, and also referred back to the same entity for a later visit (Referral). The
patient can be discharged at any point from any of the entities (Discharge).
This set of messages is referred to as ADT (Admit, Discharge, Transfer)
in Health Informatics standards terminology, in particular in the realm of
HL7 Version 2.
Figure 3.2 (a) shows the referral messages required in the information
system to match this patient flow. Admission and discharge are events in
the prototype system, but referrals were the only messages concentrated
on.
To allow the GPs and Specialists to find each other, a central registry
was added to the referral messaging system. This allows any number of
GPs and Specialists to communicate with each other, as long as they are
registered with the central registry. Figure 3.2 (b) shows the final referral
system message flow.

3.2. MESSAGE MODELS 89
Figure 3.1: The flow of patients between two hypothetical GPs and a Spe-
cialist
a. b.
Figure 3.2: a. The referral messages required for the patient workflow b.
The referral message flow including a central registry.
3.2 Message Models
Although HL7 Version 3 is clearly the way forward in health information
modelling and messaging, because of the complexity of the HL7 RIM it was
difficult to get started using this standard [SLM+ 07]. HL7 Version 3 is not
yet an accepted standard in Australia, so local support and definitions were
hard to find. The referral messaging prototype uses HL7 Version 2 for the
following reasons:
• Message types and formats are clearly defined, including local (Aus-
tralian) definitions and support, especially for ADT-type messages,

and referral messages in particular.
• Although it was mentioned in Section 2.1.1 that HL7 Version 2 is in
an outdated format, it can be represented in XML using an accepted
HL7 XML transport protocol, which is used here.
• A working knowledge of HL7 Version 2 would help in future interop-
erability endeavours, e.g. in communicating with legacy systems.
• It was envisaged that the system could be upgraded to HL7 Version 3
in the future by modifying the generated XML.
The REF I12 standard HL7 V2 referral message format was used, based
on the HL7 V2.3.1 Australian standard AS 4700.6 [Sta04] and NSW Health’s
HL7 Discharge Referral Message Implementers’ Specification [Vei01]. The
message segments are as follows:
• MSH – Message Control and Routing Information
• RF1 – Referral Information
• PRD – Practitioner/Provider Information (repeated twice – first is re-
ferring provider, second is referred-to provider)
• PID – Patient Demographic Information
• NK1 – Next-of-Kin Information
Figure 3.3 shows a graphical representation of the message, showing
cardinality. All segments are mandatory.
As can be seen in Figure 3.3, there is no information regarding the ac-
tual patient visit being transmitted in this message. This was omitted for
simplicity in the prototype application. If progress had moved forward in
this direction, the REF I12 message components shown in Figure 3.4 would
have been used. However, after this brief foray into HL7 V2, it was decided
that HL7 V3 was definitely the way forward and progress switched over to
this newer version.

3.2. MESSAGE MODELS 91
Figure 3.3: Diagram showing the HL7 V2 REF I12 message components in
the messages used in the prototype application.
The extra segments are as follows:
• DG1 – Diagnosis
• AL1 – Allergies
• ORC – Clinical History
• OBR – Pathology/Radiology Order Information
• OBX – Pathology/Radiology Test Result or any other
Clinical Observation
• PV1 – Patient Visit Information
• ORC – Medication History
• RXO – A Prescribed Drug/Item
• RXR – Route of a Prescribed Drug/Item
• RXC – Component of a Prescribed Drug Compound
An example instance of a message with this format is shown in Figure
3.5. This is the old EDI format for Version 2 messages and it can easily
be seen that if one pipe (|) was missing, the message would quickly become
programmatically unreadable. However, in more recent times a HL7 V2
XML specification has been developed including XML schemas and DTD1 s
for representing this same information as XML. The XML specification was
1 Document Type Definition

Figure 3.4: The HL7 V2 REF I12 message for a more complete information
system.
Figure 3.5: An instance of an HL7 V2 REF I12 message with the segments
shown in Figure 3.3.
used in the referral messaging system. An excerpt of an XML message
generated by the system is shown in Figure 3.6.
The message format was tested using the Australian Healthcare Mes-
saging Laboratory (AHML) online testing facility, and passed the HL7 Ver-
sion 2.3.1 interoperability test. AHML is accredited by the National Associ-
ation of Testing Authorities (NATA) in the field of Information Technology
for the testing of healthcare messages [AHM05].

3.3. THE REFERRAL APPLICATION 93
Figure 3.6: Excerpt of a V2 XML message from the prototype application.
3.3 The Referral Application
The prototype referral application was developed in C#.NET and consists
of a simple interface for entering a patient’s details and sending referral
messages containing those details, and a central registry system. The ap-
plication can be personalised per entity so that multiple instances of the
application can connect to the registry system, identify themselves, and

then communicate with each other.
This means that for the example workflow shown in Figure 3.2 (b), three
instances of the application were running, two as GPs and one as a Special-
ist. It can be seen that this setup could easily be expanded to allow any
number of healthcare entities to communicate with each other. In reality,
GPs would not directly send and receive messages, this would be handled
by a messaging system which responds to events in the system.
Key features of the prototype system are outlined in the following sec-
tions.
3.3.1 Transport Protocols
At the highest level, the information contained in messages in the referral
system are being represented in HL7 XML, as shown in Figure 3.6. The
XML messages are then wrapped and sent using SOAP2 over TCP/IP. SOAP
is a widely accepted standard for XML transmission over TCP/IP. Figure 3.7
shows this transport stack.
Figure 3.7: Transport protocol stack used in the prototype application
3.3.2 User Interface
Screen shots of the prototype application are shown below. Figure 3.8 shows
the first screen in the application. The user can select to either send a
referral message, or read referral messages which have been received.

2 Simple Object Access Protocol – http://www.w3.org/TR/soap/

Figure 3.8: The start-up screen in the prototype application.
If the ‘Send Referral Message’ button is clicked, the form in Figure 3.9
is shown. The user (GP/Specialist) can then enter all the patient’s details
and send the message. There are three tabs of patient details, the main
one is selected in the screenshot shown. The other two tabs are for the
patient’s address details, and details of the patient’s next of kin. All these
fields correspond to the fields required in the HL7 V2 messages.
If the ‘Read Referral Message’ button is clicked, a screen pops up with a
list of received messages to choose from (Figure 3.10 [a]). Once a message
is selected, the same form used for sending referrals is shown, but with the
fields filled with the details of the message and unable to be edited (Figure
3.10 [b]).
Once the prototype application has been installed at a particular en-
tity, some settings for name and other healthcare provider details can be
entered into the system for identification of that entity for communication
purposes. An XML file is used for persistent storage of these healthcare
provider details.
Figure 3.11 shows the form where persistent settings for the application
can be viewed and changed. Settings include the name of the facility, and

Figure 3.9: The ‘Send Referral’ Form.
a. b.
Figure 3.10: a. Select which message to view/read b. The message infor-

mation shown in a form.

the clinician’s name and qualifications. The ‘Message ID’ field refers to the
ID of the next message to be sent from this entity. If no messages have been
sent, it thus refers to the starting number for all messages from this entity.
Figure 3.11: The ‘Settings’ screen.
The prototype application includes functionality for XML message gen-
eration for sending messages, and XML message reading and parsing for
when a message is received. The XML parsing module was one of the
reusable outcomes of the referral messaging prototype.
The XML messages are stored at both ends (sending and receiving) for
future reference and testing.
3.3.3 Registry Service
The Registry Service is a hub for communication in the prototype system.
It operates as a directory lookup service, whereby an entity registered with
the service can be looked up by another entity, which can then communicate
directly with the first entity.
The Registry Service is a command-line application (it does not have
a graphical interface) which runs in the background of the system, sim-
ply registering entities and providing information on entities so that they
can be found. The Registry Service runs on an HTTP channel for commu-

nication. Figure 3.12 shows the Registry Service running in a command
window.
After the Registry Service starts up, it waits for registrations. When it
receives a registration message from an entity, it stores the location and
name of the entity and then returns a “Registered!” message. This can be
seen in Figure 3.8. The message “Registered!” in the information box on
that form has come directly from the Registry Service. The Registry then
waits for further messages. The other type of messages sent between the
Registry Service and prototype application entities are requests for details
on other entities.
Figure 3.12: Output of the Registry Service.
3.4 Conclusions from Referral Prototype
Creating this referral system was the first step toward putting Health In-
formatics standards into practice for interoperability. The most useful out-
comes of this prototype were an understanding of HL7 V2 and the develop-
ment of XML processing algorithms. As can be seen, the referral messag-
ing system is very basic, but it was a starting step toward developing an
interoperability solution for healthcare. The next step toward an interoper-
ability solution was part of a major project called ePOC, which is described
next.

Chapter 4
The ePOC Project
electronic Point-Of-Care (ePOC) was a project funded by an Australian Re-
search Council (ARC) Industry Linkage grant administered by the Univer-
sity of Wollongong, with industry partners Pen Computer Systems and the
South East Sydney and Illawarra Area Health Service (SESIAHS).
Pen Computer Systems Pty Ltd was incorporated in 1993 to meet the
specialised health information system requirements of primary health care
services in Australia [Pen08]. Pen’s operational scope addresses the devel-
opment and delivery of systems in Health Informatics, including such ar-
eas as chronic disease prevention and management programs, population
health status and reporting, decision-making on the clinical desktop, and
custom Health Informatics solutions development.
The aim of ePOC was to develop a PDA-based mobile electronic health
information system for The Ambulatory Care Team (TACT), a division of
SESIAHS in the Northern Illawarra region of New South Wales, Australia.
TACT Clinicians visit and treat patients in their homes, which takes them
away from all centralised information systems within the health service,
and thus everything is done on paper. As such, it can be seen that having a
mobile, PDA-based health information system could increase productivity
in this setting by cutting down on data processing time, such as time spent
99
100 CHAPTER 4. THE EPOC PROJECT
filling out duplicate paper forms and data entry time.
Figure 4.1 shows the overall plan for the ePOC information system. A
central system (TACT/ePOC System) receives referrals from an Online Re-
ferral Form via a Referral Database. This central system can also connect
to other Health Systems in the area health service. The central system can
then communicate with multiple Personal Digital Assistants (PDAs) which
can be taken out into the field on patient visits and do not have to remain
in the hospital or the TACT office.
Figure 4.1: The overall plan for the ePOC system.
4.1 Project Background
PDAs are increasingly finding a place in ambulatory care service settings,
providing mobile health information systems that can move beyond tradi-
tional wired networks in hospitals. The number of features available on
one small device and the wide availability of wireless networks in recent
times point to PDAs as an ideal platform for ambulatory care information
systems.
PDAs for ambulatory care offer benefits such as the ability for the collec-
tion, delivery and exchange of timely information (text, data and images)
at the point-of-care [WABC04], leading to a more efficient health care sys-
tem [NSW01]. PDAs deployed in such contexts empower clinicians, improve

4.1. PROJECT BACKGROUND 101
decision-making and facilitate improved levels of patient care. Among the
advantages that PDAs offer is the ability to store many books worth of in-
formation in a single hand-held device, which allows the clinician to take
reference materials out into the field at no extra cost. The connectivity of
PDAs on wireless networks also allows the clinician to look up reference
materials over the Internet.
The approach to developing the ePOC system was to create generic,
reusable and scalable components, which can exchange information be-
tween existing legacy area health systems (such as hospital/community,
patient, pathology, radiology and medical reference database systems) and
the new system incorporating PDAs, via messaging middleware based on
HL7 V3 and SNOMED CT. The ePOC system modelled and developed to
these standards makes an important contribution to software component
interoperability for Health Informatics projects.
Effective healthcare delivery within community based health services
depends (at least in part) on efficient information access [NSW01]. The
systems used by TACT are paper-based and limited to what is easy for
the clinician to take out on patient visits. The key advantages of a PDA
system are its high mobility and flexibility in matching complex healthcare
workflows as well as providing immediate update of healthcare records.
Such a system would significantly improve health outcomes, allowing TACT
to respond faster and with more appropriate action.
The intent of ePOC was to:
• be easy to use and integrate with existing work practices;
• be used by clinicians at the point-of-care; and
• provide healthcare information at the point-of-care for clinical support
and to aid in decision making.

Technically, ePOC’s intent was to:
• develop interface software for clinical use (for both PC and PDA plat-
forms);
• provide a generic reusable software architecture for information col-
lection at the point-of-care;
• address interoperability solutions, including messaging and terminol-
ogy; and
• develop and test a user-acceptance framework to guarantee user ac-
ceptance of mandated information systems.
The research approach adopted during ePOC was centred on a consul-
tative, open approach with all project team members. In particular, project
team area health managers (Clinical, Research and Information Technol-
ogy) and the intended end-users of the PDA application (TACT Doctors,
Nurses and Para-Health Professionals). Consultation with managers was
held on a regular basis to ascertain technical requirements for the system.
Consultation with the end-users of the system was held on an ongoing basis
in line with the user-acceptance goals of the project.
4.2 Clinical Environment
Community based health services within the state of New South Wales cur-
rently deliver over 8 million occasions of service per annum. These are
carried out by more than 7,000 clinicians from more than 850 health ser-
vice locations across the state. The cost of this service is estimated to be
more than $450 Million dollars per annum [NSW05]. The Ambulatory Care
Team (TACT) in the Northern Illawarra region of the South East Sydney
Illawarra Area Health Service (SESIAHS) is a health initiative based on
providing patients with a choice of having treatment in their place of resi-
dence (home or aged care facility) as an alternative to hospital [SER+ 06].

4.3. THE EPOC SYSTEM 103
In 2004 TACT provided medical, nursing and allied-health professional
services (such as physiotherapy and pharmacy services) to more than 1,300
patients. TACT receives referrals from inpatient and outpatient sources,
including inpatient facilities such as hospital wards and emergency depart-
ments, and outpatient facilities such as general practitioners, visiting med-
ical officers, staff specialists and also peri operative clinics [TAC04]. TACT
is a small unit of 21 staff members which runs two shifts a day (morning
and evening), with two clinicians working each shift and a maximum ser-
vice load of 32 patients per day.
The TACT clinicians were involved in a field trial of the ePOC system
in May, 2007, in which they took PDAs out into the field to collect clinical
observations data on both morning and evening shifts, each day for two
weeks.
4.3 The ePOC System
Unfortunately, due to SESIAHS organisational issues beyond the control
of project team members discussed in [EBS07], the entire ePOC system
as envisaged never eventuated. Security issues and reluctance to become
involved on the part of SESIAHS meant that integration with current and
legacy hospital systems was not possible. These issues were not on the part
of TACT, but higher up in the area health organisation.
Because communication with existing systems was not possible, focus
was completely moved away from referrals, and information collection at
the point-of-care was concentrated on next.
The final system involved one main module, Clinical Observations and
the beginning of a second module, Cannula Insertion. The central ePOC
system and PDA system were developed for the clinical observations mod-
ule and tested in a field trial.

4.3.1 Module 1: Clinical Observations
Taking clinical observations is a process done for each patient on a daily
basis by TACT staff, so this module was chosen as the starting point for the
ePOC system. The ePOC clinical observations workflow and functionality
was based on the TACT workflow for clinical observations shown in Figure
4.2.
The workflow in Figure 4.2 was derived based on current paper forms
used by clinicians on patient visits. As such, the workflow shows every step
being done in order one after the other. After consultation with TACT staff,
it was ascertained that every clinical observation is not taken on every visit,
or possibly multiple times in one visit, and not necessarily in the order they
are written on the form. For example, some patients are visited twice in one
day, and during the evening visit usually only pulse and temperature are
taken. Keeping this in mind, the ePOC PDA system (the new equivalent of
the paper forms) was designed so that the observations can be taken any
number of times, in any order, per visit.
Looking at Figure 4.2, the “Get Client Demographics” step is achieved
by downloading patient information from the central system. The TACT
clinician then logs into the PDA at the patient’s house. The “Get Date and
Time” step is done automatically by the system. Using a paper form the
clinician would have had to enter this detail, but now the PDA can auto-
matically timestamp the patient visit information. The steps after this are
all observations and can be taken in any order, multiple times, or not at all.
TACT has a requirement to collect clinical data in the field in a mean-
ingful way. A defined set of terms for disambiguation and meaningful ex-
change of information is needed. The SNOMED CT terminology was cho-
sen, as discussed in Chapter 2. HL7 V3 was employed for message trans-
port and storage, with SNOMED CT used within the information model
alongside other data. To map the SNOMED CT clinical terminology to the
information model of HL7, the HL7 message models in ePOC are based on

4.3. THE EPOC SYSTEM 105
Figure 4.2: Workflow for taking Clinical Observations in TACT.

SNOMED CT concepts and their relationships, the beginning of ontology
mapping between the two standards, the continuation of which is described
in Chapter 5.
The subset of SNOMED CT concepts used in ePOC was constructed in
close collaboration with TACT clinical staff, making use of their health do-
main knowledge to ensure the subset of concepts and relationships used
were as clinically accurate as possible.
4.3.2 Module 2: Cannula Insertion
The second module on the ePOC agenda was cannula insertion, although
the stage of integrating this module into the system was never reached.
Cannula insertion is another process regularly done by TACT. It involves
inserting a small tube (cannula) into a vein in a patient’s hand, wrist or
elbow in order to administer fluids through a drip. A big problem with
cannula insertion is that certain veins in certain patients do not take well
to the insertion, or may have become infected in the past. A major goal for
this module was to make this sort of patient history readily available at the
point-of-care, to allow the clinician to make an informed choice about which
vein to insert the cannula into.
Another goal of the cannula insertion module was to go beyond paper-
based process replication on the PDA and integrate graphics into the mobile
system. An image map showing a right and left arm was under develop-
ment on which the user could click which ‘spot’ on which arm the cannula
was inserted into. These insertion spots were mapped to SNOMED CT
Body Structure concepts in consultation with TACT clinicians, and a HL7
message model was developed. Unfortunately, the image map and message
models were not integrated into the prototype PDA system in time for the
field trial.

4.4. SNOMED CT SUBSETS USED IN EPOC 107
4.4 SNOMED CT Subsets Used in ePOC
4.4.1 Clinical Observations SNOMED CT Subset
All of the clinical observations in the set of eight for ePOC are of the two-
faceted form (as described by Markwell [Mar06] and discussed in Section
2.3.3), except urinalysis which is made up of many two-faceted observa-
tions (urinalysis measures several types of values from one urine sample).
With this in mind, it was decided not to use SNOMED CT concepts from
the Clinical Finding hierarchy as the description codes for the property
to be recorded, instead it is more accurate to represent a clinical finding
as a SNOMED CT concept from the Observable Entity hierarchy, plus the
observed value. This is in line with the two-faceted model, the first facet be-
ing the Observable Entity and the second facet its observed value. This also
works with the definition of Observable Entity as defined in SNOMED CT:
“a procedure or question which, when combined with a result, constitutes a
finding” [IHT08].
Figure 4.3 shows a subset of the SNOMED CT terms used for clinical
observations data. These are such concepts as core body temperature, pulse
rate, blood pressure, etc, in accordance with the clinical observations taken
by TACT. The top level concept in this diagram is vital signs. Only four of
the eight clinical observations required by TACT have corresponding con-
cepts which are subconcepts of the vital signs concept, the other concepts
(corresponding to Oxygen saturation, weight, blood sugar level and urinal-
ysis) are at the same level in the hierarchy as vital signs, and are all sub-
concepts of Observable Entity. The vital signs subset is used as an example
here for simplicity and readability. The circles in the diagram represent
the concepts and the arrows depict the SNOMED CT ‘is a’ relationship,
e.g. “pulse rate is a vital sign”, meaning Pulse Rate is a subconcept of Vital
Signs.
The procedures followed to take these observations have corresponding

Figure 4.3: A subset of the SNOMED CT Observable Entity codes used in

ePOC clinical observations.
concepts under the SNOMED CT Procedures hierarchy, with near-identical
relationships. Figure 4.4 shows some of the Procedure concepts used in the
ePOC project which correspond to the Observable Entities shown in Figure
4.3. These are such concepts as temperature taking, pulse taking, etc.
Figure 4.4: A subset of the SNOMED CT Procedure codes used in ePOC

clinical observations.
See Appendix C for the full SNOMED CT subset used in the final ePOC
system.
4.4.2 Cannula Insertion SNOMED CT Subset
The SNOMED CT subset for cannula insertion is different to the subset
used for clinical observations. This is due to the fact that Observable Enti-

4.5. HL7 MESSAGE MODELS IN EPOC 109
ties usually only have one relationship type – ‘is a’. The Procedures subset
for clinical observations was chosen to correspond to the Observable Entity
subset, so only the ‘is a’ relationships were noted for that module.
The cannula insertion SNOMED CT subset takes into account all rela-
tionship types, and is shown in Figure 4.5. The Procedure peripheral venous
cannula insertion - forearm has direct device venous cannula and method
insertion - action. The procedure site is a choice of three veins correspond-
ing to the veins in the three spots on the arm where the cannula can be
inserted, combined with a qualifier of either left or right.
Figure 4.5: The SNOMED CT subset used for cannula insertion in ePOC.
4.5 HL7 Message Models in ePOC
The HL7 message models in ePOC are based on the structure of the SNO-
MED CT subsets, using ontology mapping techniques which are detailed
fully in the next chapter (Chapter 5, Ontology Mapping). These techniques
were first developed here as part of the ePOC project, and were then ex-
panded to be more general.

4.5.1 Clinical Observations HL7 Model
The eight clinical observations in ePOC are represented in a HL7 model by
instances of the Observation specialisation of the Act class. Issues in-
volving the use of SNOMED CT in the Observation.code and Observa-
tion.value fields have caused much discussion and debate [Mar06], in
particular with respect to the representation of clinical findings as dis-
cussed in Section 2.3.3. However, in the case of the two-faceted clinical find-
ing, the representation is straight-forward. In this case, the Observation.
code field contains the SNOMED CT code for the observation (from the
Observable Entity subset), and the Observation.value field contains the
measured value of the observation. The Procedures shown in Figure 4.4 are
stored in the Observation.methodCode field to further enrich the model,
by capturing both of the SNOMED CT hierarchies (Observable Entity and
Procedure) within the one HL7 Act hierarchy. Figures 4.6 and 4.7 show the
complete HL7 message model used in ePOC.
The SNOMED CT concept hierarchy is preserved in the HL7 model by
the code field in the Observations, and the HL7
componentOf ActRelationships. For example, in Figure 4.3, blood pre-
ssure is a subtype of vital signs and can be said to have the relationship ‘is
a’ with vital signs. This particular SNOMED CT ‘is a’ relationship corre-
sponds to the HL7 componentOf relationship between the Act BloodPre-
ssure and the Act VitalSigns shown in Figure 4.6.
Likewise, the relationships between the Procedure concepts for each
Observation in the methodCode field are also preserved. For example, in
Figure 4.4, blood pressure taking is a subtype of taking patient vital signs
and has an ‘is a’ relationship with taking patient vital signs. Thus, the HL7
componentOf relationship also represents the ‘is a’ relationship between
BloodPressure.methodCode and VitalSigns.methodCode fields.
The mappings between HL7 and SNOMED CT as just described are
summarised in Table 4.1 for easy reference. Figure 4.8 shows the mapping

4.5. HL7 MESSAGE MODELS IN EPOC 111
Figure 4.6: The ePOC RMIM for clinical observations patient care provision
event (part 1).
Figure 4.7: Part 2 of the ePOC RMIM (patient data).

Table 4.1: Mappings of concepts and relationships between HL7 and SNO-
MED CT for clinical observations.
Concepts
HL7 Observation Field SNOMED CT Subset
code Observable Entities
methodCode Procedures
Relationships
HL7 SNOMED CT
componentOf ‘is a’
component Subtype
pictorially, with the SNOMED CT Observable Entity and Procedure subsets
next to an excerpt of the HL7 model based on these subsets, with arrows
showing where the codes for these concepts fit into the HL7 model. This
message model was implemented in the ePOC project for use in communi-
cation between the PDA and the central database.
Figure 4.8: Mapping SNOMED CT to HL7 for use in ePOC clinical obser-
vations.

4.6. SOFTWARE DESIGN FOR EPOC 113
4.5.2 Cannula Insertion HL7 Model
The HL7 message model for cannula insertion was based on the SNOMED
CT subset for cannula insertion in Figure 4.5 and is shown in Figure 4.9.
This RMIM is different to the clinical observations RMIM in that most
of the SNOMED CT relationships are upheld by different HL7 code type
fields in the one Act. Only the has direct device SNOMED CT relationship
is modelled by the HL7 device specialisation of Participation. The ve-
nous cannula device itself is modelled as an HL7 Entity. Table 4.2 shows
the mapping from SNOMED CT to HL7 for cannula insertion.
Figure 4.9: HL7 RMIM based on SNOMED CT cannula insertion subset.
4.6 Software Design for ePOC
Figure 4.10 shows the final ePOC system structure. On the left is shown the
ePOC PC system, and on the right the ePOC PDA application. The ePOC
system consists of the ePOC Control Panel software, which uses the TACT
Client Entry Form, both of which communicate with two database tables –

MED CT for cannula insertion.
Concepts
HL7 Act Field SNOMED CT Subset
code Procedure (cannula insertion)
methodCode Action (insertion)
targetSiteCode Body Structures
HL7 Entity Field SNOMED CT Subset
code Physical object (venous can-
nula)
Relationships
HL7 SNOMED CT
participation (device) has direct device
code fields in a single Act Procedure Site, Method
the Client table and the Observations table (the client ID is a foreign key
in the observations table).
The PDA system on the right consists of the ePOC PDA application, and
the TACT reference materials which are also stored on the PDA. The TACT
reference materials can be viewed in the ePOC user interface by way of an
embedded browser.
The PDA downloads client details from the ePOC system, and then up-
loads observations data in HL7 Version 3 format on return from the field.
Figure 4.10: Diagram of ePOC functionality at the end of the project.
A HL7 software package directly modelling the HL7 classes was devel-
oped and implemented in C#. This is a useful and reusable outcome of the

ePOC project. A part of the HL7 package class design is shown in Figure
4.11. The classes “Temperature”, “Pulse” and “Respiration” are all sub-
classes of “Observation”, reflecting the HL7 class structure.
Figure 4.11: Part of the HL7 software package class design.
The entire ePOC system, including the PDA application was developed
in C#.NET. The ePOC Control Panel makes use of Dundas Chart1 to show
patient history in graph-form. The ePOC system uses Microsoft ActiveSync2
for connectivity between the PC and the PDA.
The message reading portion of the software is an XML processing algo-
rithm, another reusable component of the ePOC software. This algorithm
reads HL7 V3 messages and retrieves core information from them, based on
the simpler XML processing algorithm developed in the referral messaging
prototype (see Section 3.3.2).
Figure 4.12 shows the steps involved in reading XML messages to re-
trieve observations to be stored in the database on the ePOC PC. The Client
ID is read from the patient information, and then the observations are read
one by one. If the observation is “Blood Pressure” or “Urinalysis”, special
rules are applied, as Blood Pressure is made up of two sub-observations
(systolic and diastolic) and Urinalysis is made up of 10 sub-observations
(specific gravity, pH, leukocytes, etc). Any simple observations made up

1 http://www.dundas.com/Products/Chart/NET/
2 http://www.microsoft.com/windowsmobile/activesync/activesync45.mspx

Figure 4.12: Decision tree showing the XML processing algorithm used for
reading messages in ePOC.

of an Observable Entity concept and a value are easily retrieved from the
message, no matter what the concept is – so the algorithm can retrieve
observations data of this form from any HL7 XML message.
4.6.1 Client Entry Form
The Online Referral Form shown in the ePOC overall plan (Figure 4.1) is an
existing process in TACT and SESIAHS. Patients are referred to TACT by
local GPs via an online form. The methodology of the Client Entry Form in
the final ePOC system, referenced in Figure 4.10, was to model the existing
Online Referral Form process. Including this form in the prototype was
meant to ease integration with existing systems upon implementation of
the final ePOC system. Unfortunately, The final ePOC system was never
realised. Figure 4.13 shows a screen shot of the ePOC Client Entry Form.
Figure 4.13: Screen Shot of the ePOC Client Entry Form.
4.6.2 ePOC PC Control Panel
The ePOC Control Panel is an application housed on a central PC in the
TACT office which interacts with the Client Entry Form and two database

tables corresponding to patients and clinical observations. The database
tables are related so that each clinical observation belongs to a patient.
The first step in using the ePOC system is to add clients on the central
PC using the Control Panel. Once all appropriate clients have been added,
they can be downloaded to the PDA by synchronising the PDA with the
central PC. A screenshot of the Control Panel application is shown in Figure
4.14.
Figure 4.14: The ePOC PC Control Panel.
Clicking on the ‘Add New Clients’ button launches the Client Entry
Form in which patients can be added and are saved to a database. Pa-
tients can be entered sequentially before going back to the control panel.
Before venturing into the field, the clinician connects the PDA to the PC
and connects the ePOC application by clicking the ‘Connect’ button. The
clients will be downloaded to the PDA when the ‘Sync with PDA’ button is
clicked.
When the clinician returns from the field at the end of their shift, the
messages are sent to the Control Panel from the PDA on re-synchronising.

The patient’s history can be viewed as a graph in the Control Panel – click-
ing on the ‘View History’ button opens a graph window. A screenshot of
an example graph is shown in Figure 4.15. The client’s name and address
are obscured in Figure 4.15 as this is de-identified data from the field trial
discussed in Section 4.7. The observation graphs are one of the advantages
the ePOC system has over the paper-based system – automatically plotting
patients’ observation history. The graphs were implemented using Dundas
Chart for .NET3 .
Figure 4.15: The ePOC Control Panel – Client History screen showing a
graph for patient temperature over a one week period.
The ‘Messages’ Tab
The ‘Messages’ tab in the ePOC Control Panel is for research purposes only
– the clinician end-users do not need to look at this tab. This tab shows
each individual message received from the PDA, which can then be viewed
in a tree form – the HL7 XML is displayed in a tree, with each XML node
expandable and collapsible. This is a useful tool for the health informati-
cian which demonstrates the messaging going on in the background of the

3 http://www.dundas.com/Products/Chart/NET/

system. The software design for displaying the messages is a recursive algo-
rithm which can display any HL7 V3 XML. Figure 4.16 shows the Messages
tab.
Figure 4.16: The ePOC PC Control Panel - Messages Tab.
4.6.3 ePOC PDA Application
The mobile ePOC system resides on a PDA, along with TACT reference
materials. The TACT reference materials are in HTML format and can be
viewed in a special browser within the ePOC application at any stage.
After logging into the ePOC PDA application, the clinician is presented
with a list of patients. From here, the patients’ observation history can be
viewed or new observations added. A patient’s history is displayed as a
summary table on the PDA, with drill-down functionality on each row to
view full details of each observation.
A screenshot of the PDA user interface is shown in Figure 4.17. The
figure shows the list of Clinical Observations available for TACT clinicians
to enter for the selected client. The observations may be performed in any

order. Once an observation is selected, a data input screen with numeric
keypad appears. The clinician enters the value for the observation and
progresses through to all other applicable observations for the client during
the ambulatory care visit. Once all the observations have been entered for
an episode of care, the message is written and stored, ready to be sent to
the ePOC Control Panel upon synchronisation.
A complete flowchart of the ePOC PDA user interface screens is shown
in Appendix D.
Figure 4.17: A screenshot of the ePOC PDA application.
Note that the technical interoperability level in this project essentially
equates to file sharing. This is due to the tight security restrictions imposed
by SESIAHS, leading to the ePOC system being restricted to one PC in
the TACT office. Because of these factors, semantic interoperability was
the only level focused on for this project, but HIF-J demonstrates a better
technical interoperability solution (Chapter 7), and the HSB addresses all
three levels of interoperability (Chapter 8).

4.7 ePOC Field Trial
The field trial of the ePOC system involved eight clinical staff collecting
observations data for 17 clients over two weeks in May, 2007, using ePOC
on PDAs and the ePOC Control Panel on a central PC, as described in the
previous section.
Before the field trial, TACT staff attended a training session and were
given instructional user manuals on both the ePOC Control Panel and PDA
applications. At the conclusion of the field trial, focus group discussions
were held to attain the TACT staff ’s opinion of the ePOC system. The size
of the field trial does not allow for definitive results, but the comments
from the focus group were all positive. This focus group was mainly for the
user-acceptance track of the project, which was the domain of other team
members.
A total of 64 HL7 messages resulted from the trial, which have since
been de-identified and stored in an XML database for querying. The data
contained in the messages shows that the TACT clinicians all entered the
data correctly and quickly (the data is time-stamped). This corresponds
with comments given in the focus group that the PDA application was easy
to use and understand, and that it was easy to navigate through the ePOC
PDA user interface screens.
An interesting observation from the field trial is that next-of-kin details
were not entered for any of the patients. The data fields on the ePOC Client
Entry Form were based on the TACT Online Referral Form; however, the
TACT staff did not use any of the next-of-kin data fields. At first it appeared
that the current TACT form does not match up with their actual work pro-
cess. However, when staff were questioned about this, they remarked that
they did need next-of-kin data, but the fields were not mandatory, so none
of them bothered to enter them. This raises design concerns that all fields
in the data entry interface should be made mandatory, as the TACT staff

4.8. CONCLUSIONS FROM EPOC 123
will only do as much in the application as they are mandated.
4.8 Conclusions from ePOC
Technically, the ePOC system has shown that by basing HL7 message struc-
tures on SNOMED CT relationships a tighter coupling between data model
and terminology can be created. The application of this model for clinical
observations data has shown that it is possible and applicable.
User-acceptance goals of the project were the domain of other team
members and so are not detailed here.
Besides functioning as a proof-of-concept for solving interoperability is-
sues, several reusable software components came out of the project which
are useful in further stages of interoperability and system integration solu-
tions, as shown in the following chapters.


Chapter 5
Ontology Mapping
There are many standards for Health Informatics, as shown in previous
chapters. This chapter will show how mapping between different infor-
mation models and terminology structures can enable semantic interoper-
ability. By using each standard for its purpose, an enriched model can be
achieved for communicating and storing health information instead of try-
ing to find a one-size-fits-all solution which does not exist. The first part of
the chapter will discuss the definitions of ontology and ontology mapping,
and then mapping between SNOMED CT and HL7, HL7 Versions 2 and 3,
and HL7 and openEHR will be detailed.
5.1 Definition of Ontology
Ontology is a branch of philosophy dealing with the nature of existence.
The word Ontology has been “borrowed” by Computer Science and in this
area refers to the organisation of a certain domain of knowledge. WordNet
3.0 [Ont08] defines ontology the following way:
125
126 CHAPTER 5. ONTOLOGY MAPPING
ontology
noun
1. (computer science) a rigorous and exhaustive organisation of
some knowledge domain that is usually hierarchical and con-
tains all the relevant entities and their relations
2. the metaphysical study of the nature of being and existence
A more mathematically formal definition is defined by Ehrig and Staab [ES04a,
ES04b]:
O := (C, HC , RC , HR , I, RI , A)
• An ontology O is defined by its set of concepts C with a corresponding
subsumption hierarchy HC .
• Relations RC exist between single concepts, which also have a corre-
sponding hierarchy HR .
• Instances I of a specific concept are interconnected by property in-
stances RI .
• Additionally, axioms A can be defined, which can be used to infer
knowledge from other already existing knowledge.
Extended definitions of ontologies can be found in [Gru93] and [SEH+ 03].
Terminologies are not necessarily ontologies, and discussion of SNO-
MED CT as an ontology is covered in Section 2.3.3. However, SNOMED
CT, HL7 and openEHR can all be said to be ontologies [Tay06].
5.2 Ontology Mapping
Ontology mapping is the process where two ontologies with overlapping
content are related at the conceptual level to create a semantic correspon-
dence between the two [BLDK05b, RB01], or to put it another way the two

5.2. ONTOLOGY MAPPING 127
ontologies are mapped to each other so that the source ontology instances
can be transformed into the target ontology instances according to mapping
rules. [ES04a] defines ontology mapping:
“Given two ontologies O1 and O2 , mapping one ontology onto an-
other means that for each entity (concept C, relation R, or in-
stance I) in ontology O1 , we try to find a corresponding entity,
which has the same intended meaning, in ontology O2 .” [ES04a]
This definition is non-reflexive, but can be made reflexive by also com-
pleting the inverse mapping. That is, to use the earlier definition, the target
instances can also be transformed back into the source instances. In most of
the ontology mapping work during this research the inverse mapping was
required to map both ways between two ontologies (i.e. map O1 to O2 and
then map O2 to O1 ).
There are two kinds of conflicts between heterogeneous ontologies which
make mapping difficult [TLL05]:
1. The first conflict occurs when ontologies for the same domain knowl-
edge have different semantic structures.
2. The second conflict occurs when either the same concept has differ-
ent names in both ontologies, or the same name refers to different
concepts in both ontologies.
For example, SNOMED CT is a multiple-inheritance hierarchy of health
concepts, including concepts of diseases. ICD-10 also contains disease con-
cepts, but is arranged in a three level single-inheritance hierarchy. Map-
ping between terminologies is not covered here, however. An example nam-
ing conflict encountered in this research is that “Event” is defined in both
SNOMED CT and HL7, but has different meanings in both, which is dis-
cussed in the next section.

5.3 Mapping SNOMED CT to HL7
The purpose of mapping the SNOMED CT and HL7 V3 ontologies is to cre-
ate harmony between the structure of the two models to move toward the
goal of semantic interoperability. By basing HL7 models on SNOMED CT
structures, relationships and hierarchies between clinical concepts devel-
oped by domain experts are preserved in the information to be communi-
cated, hence preserving message semantics.
HL7 Acts, Entities and Roles all have a code attribute. This at-
tribute can be populated with a SNOMED CT concept’s code corresponding
to the kind of Act, Entity or Role it is.
Using HL7 and SNOMED CT together is not as trivial as it might seem
and is the subject of much debate. The solution outlined here is normalisa-
tion of both by basing HL7 message models on SNOMED CT concepts and
their relationships to each other.
Both the HL7 and SNOMED CT information models can be said to
be ontologies based on the definition given in Section 5.1. HL7 consists
of a set of classes with subsumption hierarchies, i.e. Act has the sub-
classes Observation, Procedure and SubstanceAdministration, etc.
The classes are related to each other through relationships which are also
classes with the same properties, e.g. RoleLink, and ActRelationship.
The same can be said of SNOMED CT. Attributes in SNOMED CT are
actually concepts in the terminology with a hierarchy. For example, asso-
ciated with is a concept model attribute and has the subconcepts after, and
due to.
The mapping between these two ontologies is in one direction – from
SNOMED CT to HL7 (SNOMED CT → HL7). That is, for each entity in
SNOMED CT, a corresponding entity, which has the same intended mean-
ing, was found in HL7. The reverse mapping is not required in this in-
stance.

5.3. MAPPING SNOMED CT TO HL7 129
Both of the conflict situations listed in Section 5.2 occur between the
HL7 and SNOMED CT information models. This is to be expected as the
two information models have different aims and purposes.
The conflict between semantic structures occurs as HL7 has an act-
centred view of healthcare information and SNOMED CT’s main aim is to
model clinical constructs. This is the key difference between the two which
this ontology mapping aims to solve. Modelling the information on estab-
lished clinical constructs preserves relationships and allows more meaning
to be inferred from the resulting message instances.
The second conflict regarding naming also occurs between the two on-
tologies and must be considered during mapping to avoid confusion. For
example, one of the concept groups in SNOMED CT is Event, referring to
‘an occurrence which results in injury’. Examples of this are Accidental
Fall, Flood and Motor Vehicle Accident. HL7 also contains an Event, but
this time it refers to ‘an Act which has occurred’, i.e. it is the past tense of
Act. This could be that a patient’s blood pressure was taken, or that a pa-
tient was admitted to hospital. In SNOMED CT, a patient’s blood pressure
that has been taken is a Clinical Finding.
As can be seen, careful thought and study of the SNOMED CT hier-
archy was needed to develop this mapping process. To further complicate
matters, HL7 has some vocabulary tables of its own, used in fields such as
classCode and moodCode.
One of the findings from Dolin et al. [DMC+ 04] in the CMT project (see
Section 1.6) is that a tighter coupling of SNOMED CT and HL7 would
greatly enhance interoperability between healthcare systems. The down-
side, they argue, is that different implementations of HL7 could use differ-
ent code sets and coding schemes.
One suggestion that has been made in trying to draw the terminology
and the message structure together is the inclusion of the HL7 vocabu-
lary terms and concepts as an addition to SNOMED CT. However, this is

not necessary as mapping between the two may be achieved by using the
UMLS1 Metathesaurus [HBCH98]. The UMLS Metathesaurus acts as a
central repository for vocabularies and terminologies for several standards
groups, including both SNOMED CT and HL7.
However, using SNOMED CT exclusively is the simplest solution and
does not require the UMLS Metathesaurus. The approach taken in this
work is to do away with the HL7 tables and use SNOMED CT subsets ex-
clusively for all code-type fields, thus setting a standard coding scheme for
use throughout the model, so the concerns of Dolin et al. do not pose a prob-
lem.
The exception is the two HL7 tables already mentioned (classCode
and mood7Code), but these fields have strict non-extensible values, so us-
ing only these two HL7 tables and SNOMED CT for every other code field
is the solution used here. Other HL7 tables such as code, priorityCode,
reasonCode and languageCode are much less restricted and allow free-
hand entry of concepts, and these are the cases where restriction is required
to maintain interoperability (in this case, restriction to SNOMED CT).
The following subsection steps through a SNOMED CT → HL7 mapping
example.
5.3.1 Example Manual Mapping
Figure 5.1 shows the SNOMED CT concept of Blood Pressure Reading,
given as an example in Section 2.3.2. As can be seen in the diagram,
Systolic Blood Pressure Reading and Diastolic Blood Pressure Reading are
both subtypes of Blood Pressure Reading. The other relationships shown in
the figure describe various attributes of Blood Pressure Reading. A simple
manual mapping to HL7 from the SNOMED CT blood pressure reading is
shown in Figure 5.2.
The mapping of SNOMED CT concepts to their container attributes in

1 Unified Medical Language System – http://www.nlm.nih.gov/research/umls/

Figure 5.1: Blood Pressure Reading Concepts and Attributes in SNOMED

CT
HL7 is shown in Table 5.1. The first five rows show a relatively straight-
forward mapping between the two, e.g., the SNOMED CT attribute finding
site is captured within an attribute of a similar name in HL7 (targetSite-
Code), and the SNOMED CT concept structure of brachial artery will be the
information populating this attribute in the information model. Figure 5.3
shows these types of mappings from SNOMED CT to HL7. This is a sim-
ple mapping of SNOMED CT concepts to the one Act class instance, into
different HL7 code attributes.
The last four rows in the table refer to attributes in SNOMED CT which
are mapped to classes in HL7– manifestationOf, componentOf and in-
formant. This mapping is almost a reversal of the first mappings, with
the SNOMED CT attributes mapped to HL7 classes and the SNOMED CT
concepts mapped to an attribute in a separate, related HL7 class. For ex-

Figure 5.2: Blood Pressure Concept and its attributes from SNOMED CT
represented in HL7
Table 5.1: Mapping from SNOMED CT to HL7 in Figures 5.1 and 5.2.
SNOMED CT HL7
Concept Attribute Class Attribute
o/e - blood pressure reading n/a Observation code
structure of brachial artery finding Observation targetSiteCode
site
blood pressure taking finding Observation methodCode
method
blood pressure interprets manifestationOf Observation::code
performer of method finding informant Role::code
informer
o/e - Systolic BP reading is a componentOf Observation::code
o/e - Diastolic BP reading is a componentOf Observation::code
Figure 5.3: Straightforward mapping of concepts and relationships from

SNOMED CT to HL7.

ample, the systolic blood pressure concept populates the code field of an
Observation which is a componentOf the Observation with the code
blood pressure. Figure 5.4 shows this type of mapping from SNOMED CT to
HL7. As can be seen in the figure, the SNOMED CT concepts map to HL7
class instances, which is represented by the SNOMED CT concept’s code
populating the HL7 class’s code attribute. The SNOMED CT Relation-
ships then map to HL7 Relationship class instances. This mapping shows
a more direct translation of structure from SNOMED CT to HL7.
Figure 5.4: Another mapping from SNOMED CT to HL7.
The beginning of these mapping techniques were developed as part of
the ePOC project. Following on from that project, the mapping techniques
were extended to be more general, as described in the next section.
5.3.2 Extended Alignment Strategy
The work described in the ePOC project (Chapter 4), while being sufficient
for its application, is a preliminary step toward a greater goal to create
a complete framework for health communication and has formed the basis

for the messaging models and use of terminology in this framework. To this
end, the messaging focus was expanded more generally to include all types
of SNOMED CT concepts (not just Observable Entities and Procedures) by
taking a subset of SNOMED CT based on the concept of Vital Signs. In this
new strategy, HL7 models and messages are automatically generated based
around the HL7 PatientCareProvisionEvent and ObservationEvent
specialisations of Act using these terminological concepts. Along with the
mappings used in the ePOC project shown in Table 4.1, SNOMED CT Body
Structures have been mapped to the HL7 targetSiteCode field, and Clin-
ical Findings mapped to the HL7 interpretationCode field. This lat-
ter field is automatically populated based on the code combined with the
value field, to assist with decision support.
As an example, if the concept is blood pressure and the value is ‘120/80
mmHg’, the decision support system will automatically populate the
interpretationCode field with the concept normal blood pressure, as the
normal blood pressure concept has the relationship interprets with blood
pressure, and the blood pressure value is in a healthy range. The target-
SiteCode field is then restricted to systemic arterial structure and its sub-
concepts, based on the fact that the normal blood pressure concept has the
relationship finding site with systemic arterial structure.
This decision support system meets the criteria in Section 1.1.4 in that
it complements clinical expertise by simply constraining possible relation-
ship attributes based on established clinical constructs. The DSS is context-
based and makes using the messaging system easier. In the actual imple-
mentation of this system (discussed in Chapter 7 – HIF-J) the option to
turn the decision support off is included, in case the clinician really does
not want it on.
Constraints have also been implemented to uphold restrictions between
these fields so that all code values in the one instance of a HL7 Observat-
ion class must have existing relationships in SNOMED CT.

5.4. MAPPING BETWEEN HL7 VERSIONS 2 AND 3 135
The SNOMED CT ‘is a’ relationship is mapped to the HL7 componentOf
ActRelationship, just as in Table 4.1. Other SNOMED CT relationships,
such as Finding Site, are mapped by the two concepts belonging to the same
HL7 Observation instance, as in Figure 5.3.
A summary of all mapping types between HL7 and SNOMED CT is
shown in Table 5.2. The new mappings (not previously described in the
ePOC project) are italicised.
MED CT.
Concepts
HL7 Observation Field SNOMED CT Subset
code Observable Entities
methodCode Procedures
targetSiteCode Body Structures
interpretationCode Clinical Findings
Relationships
HL7 SNOMED CT
componentOf ‘is a’
component Subtype
manifestationOf Interprets
informant Finding Informer
code fields in a single Act Finding Site, Finding Method
5.4 Mapping between HL7 Versions 2 and 3
Translation between XML representations of HL7 Versions 2 and 3 is at-
tainable, as the two versions cover the same semantic content in different
structures and syntax (see Section 2.1.3). Mapping in both directions is re-
quired in this case (HL7 V2 ↔ HL7 V3). I.e., for each entity in HL7 V2, a
corresponding entity was found in HL7 V3, and then for each entity in HL7
V3 a corresponding entity was found in HL7 V2. This is to allow correct
translation in both directions, for communication between legacy systems
using V2 and new systems using V3.
Bicer et al. have achieved this transform using Web Ontology Language

(OWL)2 by creating an OWL mapping tool called OWLmt [BLDK05b] and
have used it in the Artemis Message Exchange Framework [BLDK05a].
As part of their work, they have used the HL7 Application Programming
Interface (HAPI) Assembler/Disassembler tool [HAP07] to perform an EDI
to XML conversion to handle HL7 Version 2 messages in the old format.
The EDI-format messages are first converted to XML, which then allows
the OWL mapping between HL7 V2 XML and HL7 V3 XML. To achieve
the XML mapping, Bicer et al. make use of various tools, including XPath,
JavaScript and OWL-QL3 , within OWLmt.
The system that Bicer et al. have created for translation is an excellent
solution to general mappings between the two HL7 versions. However, such
a heavy-weight solution was not required for this work, as one type of data
was mainly concentrated on, that of observations. As such, the simpler
lightweight solution taken here is to translate between Version 2 and 3
XML by creating XSLT stylesheets based on mapping rules between the
two models. The HL7 Versions 2 and 3 datatypes were mapped first, as they
are quite similar and provide a foundation for information representation in
both models. As an example, the mapping between the Version 3 datatype
AD (postal Address) and the Version 2 datatype XAD (extended address) is
shown in Table 5.3.
As can be seen in the table, some single V3 attributes map to multiple V2
attributes, while multiple V3 attributes map to a single V2 attribute. For
example, use is a set of codes in Version 3 (SET<CS> means ‘set of Coded
Strings’), which maps to two different ID (code) fields in Version 2 (the first
line of Table 5.3). V3 attributes such as houseNumber and direction
both map to the V2 attribute XAD-2, which is ‘other designation’. The V3
attribute useablePeriod is of the type ‘General Time Specification’ (GTS),
which corresponds to the V2 attribute XAD-13 (effective date) which is of
the type ‘Date Time’ (DTM). A general rule that anything which is of GTS
2 http://www.w3.org/TR/owl-features/
3 http://ksl.stanford.edu/projects/owl-ql

5.4. MAPPING BETWEEN HL7 VERSIONS 2 AND 3 137
Table 5.3: Mapping between HL7 Version 3 datatype “Postal Address (AD)”
and HL7 Version 2 datatype “Extended Address (XAD)”.
V3: AD V2: XAD

attribute datatype attribute datatype
XAD-7 address type ID
use SET<CS>
XAD-44 address usage ID
XAD-13 effective date DTM
useablePeriod GTS
XAD-14 expiration date DTM
isNotOrdered BL n/a
streetAddressLine ST XAD-1 street address SAD
city ST XAD-3 city ST
state ST XAD-4 state or province ST
postalCode ST XAD-5 zip or postal code ST
houseNumber ST
XAD-2 other designation ST
direction ST
country ST XAD-6 country ID
datatype in Version 3 should be represented as DTM datatype in Version
2, and vice versa, can be taken from this, as well as other general rules
such as V3 STs (Character Strings) should be converted directly to V2 STs
(Strings). A further mapping example is shown in the following subsection.
5.4.1 Observations Messages Mapping
As clinical observations messages had been researched in-depth as part of
the ePOC project, observations messages were continued as a case study
for the messaging frameworks described in Chapters 7 and 8. As described
in Section 5.3.2, the HL7 V3 model has been extended from the ePOC def-
inition of eight clinical observations to include all observations and proce-
dures, as well as more detail on body sites, interpretations, etc.
The previous work on HL7 V2 (Chapter 3) was based on referral mes-
sages, so the V2 ORU R30 message structure was researched and employed
here. The code ORU refers to a “point-of-care observations” message, and
the trigger event R30 refers to “place an order”, meaning an order was
placed for observations to be taken, which triggers the sending of an ob-
servations message.

The HL7 Version 3 and HL7 Version 2 observations message models
were then mapped to each other, as is shown in Figure 5.5. A V3 RMIM
for patient observations is shown, with mappings to the V2 observation
message segments.
Figure 5.5: Mapping between HL7 V2 and V3 Observation messages.
Table 5.4 shows the mapping of actual V2 fields to V3 attributes for
patient data, as an example. The table shows the V2 fields for the Pa-
tient Identification Segment (PID) and their mappings to V3 in the form
of class::attribute. As can be seen in the Table (and in Figure 5.5), the V2
segment PID maps to the V3 classes patient and patientPerson.
Table 5.4: Mapping of HL7 Version 2 PID fields to HL7 Version 3.
V2 field description mapping to V3 attribute

PID.3 Patient Identifier List patient::id
PID.5 Patient Name patientPerson::name
PID.7 Date/Time of Birth patientPerson::birthTime
PID.8 Administrative Sex patientPerson::aGenderCode
PID.10 Race patientPerson::raceCode
PID.11 Patient Address patient::addr
PID.13 Phone Number - home patient::telecom
PID.14 Phone Number - business patient::telecom
The complete mappings between V2 and V3 observations messages can
be seen in Appendix E. XSLT transforms were created for translating be-

5.5. SNOMED CT AND OPENEHR 139
tween HL7 V2 and V3 Observations messages based on these mappings, for
use in HIF-J and the HSB (Chapters 7 and 8).
5.5 SNOMED CT and openEHR
A SNOMED CT concept can be entered into the ontology section of an
openEHR archetype. As an example, a blood pressure archetype is shown
in Figure 5.6 (abridged from openEHR4 ). As can be seen in the Figure, key
clinical concepts in the archetype are bound to SNOMED CT concepts in
the term binding field of the ontology section. This dictates the use of ter-
minology in instances of the archetype (see also Section 2.4).
It may be possible to create openEHR archetypes based on SNOMED
CT structures, but it was thought best for general interoperability to use
existing openEHR archetypes, and that mapping the HL7 models based on
SNOMED CT to the existing archetypes was sufficient.
5.6 Mapping between HL7 V3 and openEHR
Instances of archetypes can be represented as XML using the openEHR
XML Implementable Technology Specification, so the mapping between HL7
and openEHR was done in same way as the mapping between the two ver-
sions of HL7 – using XSLT. Bi-directional mapping was also needed in this
case, to ensure that meaning was preserved during translation in both di-
rections (HL7 ↔ openEHR).
Mapping between HL7 and openEHR was first employed so that systems
using different health standards could communicate with each other using
translation services in HIF-J (Chapter 7). In the final interoperability so-
lution (HSB – Chapter 8), an EHR XML database containing openEHR in-
stances is established, and translation between HL7 and openEHR is used

4 For the full archetype see: http://www.openehr.org/svn/knowledge/archetypes/
dev/adl/openehr/ehr/entry/observation/openEHR-EHR-OBSERVATION.blood\
_pressure.v1.adl

Figure 5.6: Abridged blood pressure openEHR Archetype.

5.6. MAPPING BETWEEN HL7 V3 AND OPENEHR 141
to translate clinical observations instances sent in HL7 messages into per-
sistent EHR representations of observations to be stored in a patient’s life-
long record in the database.
An example openEHR XML instance corresponding to the archetype
shown in Figure 5.6 is shown in Figure 5.7. XML instances conforming
to this blood pressure archetype (along with other observation archetypes)
were mapped to HL7 XML instances for clinical observations.
The structure of the HL7 observation message models is very similar
to the openEHR archetype for clinical findings5 (see the next subsection –
5.6.1), so mapping was not as difficult as mapping from SNOMED CT to
HL7. The mapping in this case is basically a translation of XML element
and attribute names, rather than a complete restructure of information,
even less restructuring than between HL7 Versions 2 and 3.
For example, the XML instance of an openEHR ELEMENT is shown,
followed by the matching XML instance of a HL7 observationEvent com-
ponent in Figure 5.8.
The SNOMED CT code and the value of the observation are represented
in each, surrounded by the openEHR tags or HL7 tags respectively. The
complete mappings between HL7 and openEHR observations messages can
be seen in Appendix F. As with the HL7 V2 ↔ V3 mappings, XSLT trans-
forms were created for translating between HL7 V3 and openEHR Obser-
vations, for use in HIF-J and the HSB.
5.6.1 openEHR Clinical Observations Messages
Table 5.5 shows the openEHR archetypes used for clinical observations.
This was preliminary work done for the ePOC project, which is why the ar-
chetypes listed are for the eight observations recorded in ePOC, but open-
EHR was not used in that project. The work was continued for messaging
in HIF-J.
5 openEHR-EHR-SECTION.findings.v1.adl

Figure 5.7: XML conforming to the archetype shown in Figure 5.6.

5.6. MAPPING BETWEEN HL7 V3 AND OPENEHR 143
a. openEHR XML
b. HL7 XML
Figure 5.8: a. openEHR ELEMENT part XML.

b. HL7 observationEvent component XML.
The openEHR archetypes in Table 5.5 were grouped together using the
archetype for Clinical Findings (openEHR-EHR-SECTION.findings.v1.adl)6
– which comprises an openEHR SECTION containing OBSERVATIONS
(the archetypes in the table). This maps to the HL7 Observations RMIM by
the SECTION corresponding to a container ObservationEvent (referring
to the patient visit) with component ObservationEvents corresponding
to blood pressure, pulse, etc. This is shown in Figure 5.9. The structure
6 http://www.openehr.org/svn/knowledge/archetypes/dev/adl/openehr/ehr/section/openEHR-
EHR-SECTION.findings.v1.adl

Table 5.5: openEHR Archetypes used for Clinical Observations.
SNOMED CT Concept openEHR Archetype

core body temperature openEHR-EHR-OBSERVATION.
(276885007) body temperature.v1
pulse rate (78564009) openEHR-EHR-OBSERVATION.
heart rate.v1
rate of spontaneous respira- openEHR-EHR-OBSERVATION.
tion (271625008) respiration.v1
blood pressure (75367002) openEHR-EHR-OBSERVATION.
blood pressure.v1
haemoglobin saturation with openEHR-EHR-OBSERVATION.
oxygen (103228002) oximetry.v1
body weight (27113001) openEHR-EHR-OBSERVATION.
body weight.v1
blood glucose level openEHR-EHR-OBSERVATION.
(365812005) bm glucose.v1
contents of urine (249299009) openEHR-EHR-OBSERVATION.
urinalysis.v1draft
on the left in the figure shows the HL7 message structure taken from the
RMIM for patient observations. The structure on the left shows the Clini-
cal Findings SECTION of an EHR. It can be seen that the structure of the
Patient Observations part of the HL7 message is the same as the openEHR
Clinical Findings section. This means that the HL7 XML for this section
can simply be transformed to openEHR XML using XSLT based on map-
pings between the fields and then stored permanently as part of a patient’s
EHR.
5.7 Ontology Mapping Conclusions
There are many standards and terminologies used in Health Informat-
ics, for different purposes. Mapping between different information models
and terminology structures can enable semantic interoperability in several
ways. First, communication may be achieved between systems using differ-
ing standards. Second, by exploiting the strong points of each standard and
using them together, an enriched model may be obtained.

5.7. ONTOLOGY MAPPING CONCLUSIONS 145
Figure 5.9: Mapping HL7 message structure to openEHR structure for Ob-
servations.
By basing HL7 message models on SNOMED CT structures, both the
use of terminology is made stricter (enabling semantic interoperability) and
actual clinical structures are modelled (SNOMED CT relationships mod-
elled in HL7).
A complete lifetime EHR can be obtained by combining representations
of instances-of-care (messages) together in the one openEHR care record.
By mapping HL7 to openEHR, continuing exact semantic meaning into the
EHR can be assured. Restricting the use of terminology in the EHR to
match the HL7 models ensures this.
In practice, instead of choosing one standard for healthcare, mapping
the different ontologies to each other can avoid vendor lock-in and enable a
more open, interoperable healthcare computing environment.


Chapter 6
SNOMED CT Vital Signs
XML Database
Browsing SNOMED CT and creating mappings to information models is an
excellent start to using terminology. However, the terminology needs to be
accessible programmatically to make full use of it in a health information
system or messaging framework. As referred to previously, the SNOMED
CT terminology is extremely large, at over 300,000 concepts, and this com-
plete terminology is distributed as three text files.
To make using SNOMED CT with HL7 and openEHR accessible within
an overall communications framework, a SNOMED CT Terminology Ser-
vice was set up. The core part of the SNOMED CT Terminology Service is a
SNOMED CT XML Database. This chapter describes the process of trans-
forming the standard SNOMED CT distribution into XML and the theory
behind it.
The SNOMED CT XML was stored in an eXist native XML database
for querying. Two front-ends which connect to the XML database were cre-
ated, one to expose it as a Jini service for use in HIF-J described in the
next chapter, and a standard Web Service for connecting the XML DB to
147
148 CHAPTER 6. SNOMED CT VITAL SIGNS XML DATABASE
the Health Service Bus (Chapter 8), both written in Java. The communica-
tions front-ends, combined with the XML database form the SNOMED CT
Terminology Services.
The first step in creating the XML database was to take a subset of
SNOMED CT. This will be discussed, followed by an explanation of how
SNOMED CT is represented, and an XML converter utility which was de-
veloped and used to create the SNOMED CT XML subset is shown. The
chapter ends with a discussion of the eXist database.
6.1 SNOMED CT Vital Signs subset
SNOMED CT is the largest medical terminology in the world, with over
344,000 active concepts [IHT08]. Working with the entire terminology is
extremely cumbersome and it is unlikely that any health information sys-
tem would use the entire terminology – subsets of SNOMED CT covering
a particular domain of interest would be used. For example, a laboratory
system would only use the parts of SNOMED CT particular to laboratory
work.
Because the entire terminology is so large, a subset of SNOMED CT
coming under the heading of Vital Signs was taken. Vital Signs was cho-
sen in keeping with the theme of taking observations, started in the ePOC
project (see Chapters 4 and 5).
Figure 6.1 shows part of the Vital Signs subset. Observable Entities,
Clinical Findings, Procedures and Body Structures are shown, along with
the ‘is a’ relationships between them (black arrows) and other relationships
(red arrows). When it is mapped out as in the figure, it can be seen that the
multiple-inheritance of the SNOMED CT hierarchy creates a complicated
structure (it is usually viewed concept-by-concept in a terminology browser,
if at all). The size of the completed subset is approximately 1,000 concepts,
2,700 descriptions and 11,000 relationships between the concepts, a more

6.2. REPRESENTATION OF SNOMED CT 149
manageable size than the complete terminology.
Some understanding of how SNOMED CT is represented is required in
order to understand the final XML database, and is covered next.
6.2 Representation of SNOMED CT
SNOMED CT is distributed as a set of three delimited text files, with data
in rows with the first row being the column headings. Table 6.1 shows a
small section of the SNOMED CT Concepts file from the July 2007 release
of SNOMED CT, in table format.
Table 6.1: Part of the SNOMED CT Concepts file (July 2007 Release). All
rights reserved IHTSDO.
CONCEPT ID STA- FULLY SPECIFIED NAME CTV3 ID SNOMED PRIM-

TUS ID
ITIVE
103281005 0 Sensation of blocked XU0sM F-F5612 1
ears (finding)
103282003 0 Essential vertigo XU0sN F-F6001 1
(finding)
103283008 4 Vertigo associated XU0sO F-F6034 1
with seizures (find-
ing)
XML is a better choice of data representation than flat database files
in general (see also Section 1.5.2). Parsing these SNOMED CT text files
programmatically is time-consuming and memory-intensive. If the SNO-
MED CT concepts were instead represented in XML, they could be stored
in an XML database, which allows for faster and more intelligent querying
power.
Figure 6.2 shows the XML version of the concepts in Table 6.1. The
table rows have been turned into XML elements with the name ‘concept’,
with each data field as a child element of ‘concept’, with the same names
as the column headings used in the SNOMED CT distribution. All the
original fields have been retained so no information has been lost, and just

Figure 6.1: Part of the SNOMED CT Vital Signs subset.

Figure 6.2: XML version of the SNOMED CT concepts in Table 6.1.
by looking at a single concept the field names are apparent. This is one of
the advantages of XML achieved by meaningful tag names – it is easy to
see what each item of data is, without having to refer to a column headings
row which may not always be available.
The other two files that make up SNOMED CT are the Descriptions
file and the Relationships file. Concepts in SNOMED CT can have many
descriptions – especially when multiple languages are involved (SNOMED
CT currently has UK English, US English and Spanish). Table 6.2 shows a
small section of the SNOMED CT Descriptions file, corresponding to the
descriptions for the concept Sensation of blocked ears (finding) (SCTID:
103281005) – the first concept in Table 6.1.
As can be seen in the Table, the CONCEPT ID field is a foreign key re-
ferring to CONCEPT ID in the Concepts file. To retrieve all the descriptions
for a certain concept from the SNOMED CT database, such as Sensation of
blocked ears (103281005) an SQL1 query like the following is required:
SELECT * from Descriptions
WHERE CONCEPT ID = ‘103281005’

1 Structured Query Language

Table 6.2: Part of the SNOMED CT Descriptions file (July 2007 Release).
All rights reserved IHTSDO.
DESCRIPTION ID STA- CONCEPT ID TERM INI- TYPE LANG-

TUS TIAL UAGE
CODE
550195019 0 103281005 Sensation of blocked 0 3 en

ears (finding)
201881011 0 103281005 Blocked ears 0 2 en
166825013 0 103281005 Sensation of block in 0 2 en
ear
166826014 0 103281005 Ear blockage sensa- 0 2 en
tion
201882016 0 103281005 Sensation of blocked 0 1 en
ears
This query would return the results shown in Table 6.2. If the Concept
ID was unknown, a nested query like the following would be required:
SELECT * from Descriptions
WHERE CONCEPT ID =
(SELECT CONCEPT ID from Concepts
WHERE FULLY SPECIFIED NAME LIKE ‘%blocked ears%’)
Figure 6.3 shows the XML version of the descriptions in Table 6.2. The
descriptions XML is in the same format as the concepts XML – each row has
been converted to an XML element called ‘description’ with child elements
corresponding to each data field.
XQuery can be used to query the XML, just like SQL could be used for
the text files. The XQuery corresponding to the two SQL queries mentioned
above are as follows (using FLWOR2 ):
for $x in /SNOMED-CT/description
where $x/conceptId = ‘103281005’
return $x
for $x in /SNOMED-CT/description
where $x/conceptId =
2 FLWOR is an acronym for “For, Let, Where, Order by, Return”.

Figure 6.3: XML version of the SNOMED CT descriptions in Table 6.2.
(for $y in /SNOMED-CT/concept
where fn:matches($y/fullySpecifiedName, ‘blocked ears’)
return data($y/conceptId))
return $x
Note that the XML root element in the database is <SNOMED-CT>.
Table 6.3 shows a small section of the SNOMED CT Relationships file,
corresponding to the relationships for the concept Sensation of blocked ears
(SCTID: 103281005). In the Relationships database, the fields CONCEPT-
ID 1, RELATIONSHIP TYPE and CONCEPT ID 2 are all foreign keys to CON-
CEPT ID in the concepts file. Relationships in SNOMED CT are themselves
concepts of the type Attribute. For example, the ‘is a’ relationship:
Concept Id: 116680003
Concept Status: 0
Fully Specified Name: is a (attribute)
Ctv3Id: XU48G

Table 6.3: Part of the SNOMED CT Relationships file (July 2007 Release).
All rights reserved IHTSDO.
RELATIONSHIP CONCEPT ID RELATIONSHIP CONCEPT ID TYPE REFIN- GRO-

ID 1 TYPE 2 ABILITY UP
6610023 103281005 116680003 247234006 0 0 0

431352026 103281005 363698007 117590005 0 1 0
Snomed Id: G-C509
Is Primitive: 1
To find the subconcepts (children) of a given concept, the Concept ID of
the ‘is a’ relationship is needed (116680003). An SQL query to find the IDs
of the subconcepts of Sensation of blocked ears looks like this:
SELECT CONCEPT ID 1 from Relationships
WHERE CONCEPT ID 2 = ‘103281005’
AND RELATIONSHIP TYPE = ‘116680003’
The concepts file can then be queried based on the returned Concept IDs
to find the actual child concepts.
Figure 6.4 shows the XML version of the concepts in Table 6.3. Once
again, each row from the delimited file has been converted to an XML el-
ement called ‘relationship’ with each field converted to a child element of
this node.
The XQuery corresponding to retrieving the subconcepts of Sensation of
blocked ears is as follows:
for $x in /SNOMED-CT/relationship
where $x/conceptId2 = ‘103281005’
and $x/relationshipType = ‘116680003’
return $x
Converting the delimited text files to XML allows for greater flexibility
in using the terminology without losing any querying power. Also, to be

6.3. SNOMED CT XML CONVERTER UTILITY 155
Figure 6.4: XML version of the SNOMED CT relationships in Table 6.3.
able to run the SQL queries shown as examples, the text files would first
have to be imported into a traditional database.
Representing SNOMED CT as XML allows greater access to the ter-
minology. Manually converting the text files to XML would be extremely
time-consuming, however, so this is where the XML converter utility tool
comes in.
6.3 SNOMED CT XML Converter Utility
The process of converting the SNOMED CT concepts, descriptions and re-
lationships to XML by hand would be incredibly tedious, even when re-
stricted to the Vital Signs subset (the subset has 11,000 relationships), so
to solve this problem a small utility application was developed which takes
an SCTID as an attribute, then goes through the SNOMED CT text files
line-by-line converting all concepts, descriptions and relationships which
are related to the input SCTID into XML. The output is three XML files
corresponding to the three delimited text files, for the subset based on the
input SCTID. Note that unlike the text files, due to the nature of native
XML databases, the XML files could be combined to the same file with-

out any programmatic difference, or could even be split up into more than
three files, but they were kept in the same file structure as the input files
for ease of human understanding. Figure 6.5 shows the complete process
for creating the SNOMED CT Vital Signs XML database.
Figure 6.5: The process for creating the SNOMED CT Vital Signs subset
XML Database.
The converter utility tool was developed in C#.NET and was originally a
simple command-line based application. After using the converter and re-
alising that this was a valuable, reusable tool, a simple graphical interface
was added for ease-of-use. Figure 6.6 shows a screen shot of the main form
of the user interface.
The conversion tool works by using the .NET System.Xml library to
write the output XML. The first step in the conversion is to build a ‘to do’
list of concepts which are related to the input concept, by finding all the
concepts which have relationships with that concept from the relationships
file.
The tool recursively continues to do this for each concept until the ‘to
do’ list is complete, and compiles the list of relationships at the same time
(the list is complete when all relationships pertaining to each concept are
in the list – as relationships are two-sided a point is reached when the

6.3. SNOMED CT XML CONVERTER UTILITY 157
Figure 6.6: Graphical user interface of the SNOMED CT XML Converter

Utility Application.
relationships for the remaining concepts already exist in the list). Finally,
a descriptions list is created from the concepts list.
The last step is to then go through the lists and output each concept,
description and relationship in XML format. This whole process could be
made simpler by converting every concept, description and relationship to
XML. However, this is very time-intensive as the terminology is so large
– 344,000 concepts, with approximately 2.5 times this in descriptions and
another 2.2 times this in relationships. Also, it is useful to be able to create
subsets.
Note that knowledge of the required Concept ID is needed before using
the tool. It is suggested that a SNOMED CT browser be used in conjunction
with the converter tool for this purpose. The CliniClue browser for SNO-
MED CT by The Clinical Information Consultancy (CIC Ltd) [CiC08] was
used throughout this research for all SNOMED CT browsing requirements.
At the end of the conversion process, the XML files were stored in an
eXist native XML database, which can then be queried using XQuery, as
indicated in Figure 6.5.

6.4 eXist Open Source Native XML Database
A native XML database is a database that treats XML documents and ele-
ments as fundamental structures rather than tables, records, and fields. A
big advantage of a native XML database is that it can run queries that com-
bine information contained in multiple XML documents. As mentioned in
Section 6.2, XQuery is to native XML databases in the same way that SQL
is to relational databases. However, XQuery does not have the same func-
tionality as SQL in that it cannot add documents to the database, delete
documents from the database, or modify existing documents. This does not
have a big affect on the SNOMED CT database, as SNOMED CT is primar-
ily a static knowledge source. The ability to query multiple documents also
means that new concepts can be added as a new XML file, which will then
automatically be included in any future queries.
Figure 6.7: Screenshot of eXist database administration.
eXist is an open-source native XML database featuring efficient, index-
based XQuery processing, automatic indexing, extensions for full-text search,

6.4. EXIST OPEN SOURCE NATIVE XML DATABASE 159
XUpdate support, XQuery update extensions and tight integration with ex-
isting XML development tools [eXi08]. eXist provides functionality for cre-
ating collections (equivalent to relational database tables) and uploading
XML documents to those collections. Figure 6.7 shows the database admin-
istration page for the SNOMED CT Vital Signs collection.
The eXist database server can then be deployed in a servlet container
(Jetty is used3 ), running as a web application. eXist can be accessed from
Java applications using the XML:DB API. The XML:DB API uses a spe-
cific URI scheme to locate a collection of XML resources on the server. eX-
ist’s XML:DB API implementation supports transparent access to remote
as well as embedded database servers.
As discussed in the next two chapters, a Jini service front-end was de-
veloped which connects to the eXist database server using the XML:DB API
and used within HIF-J (Chapter 7), as well as being adapted as a general
Web Service which was connected to the Health Service Bus (Chapter 8).
3 Jetty is an open-source, standards-based, full-featured Web Server implemented entirely
in Java (see [Mor08]).

6.5 Conclusions on SNOMED CT
Vital Signs Database
SNOMED CT is a very comprehensive medical terminology, and as such has
a large number of concepts, descriptions, and relationships. A subset based
on Vital Signs is large enough to represent practical use of the terminology
and contains relationships between concepts which are representative of
the terminology as a whole.
Converting this subset to XML provides a better format for interoper-
ability and accessibility than delimited text files. Storing the XML subset
in an eXist native XML database allows for fast and easy querying of the
XML data, and can be connected to Java applications using the XML:DB
API, which is exactly what is done in HIF-J and the HSB, described in the
next two chapters.

Chapter 7
The Jini Health
Interoperability
Framework (HIF-J)
The ontology mapping techniques described in Chapter 5 are an important
part of achieving semantic interoperability in health. However, an overall
framework is needed for enabling communication and message sending in
the formats described. This is the technical interoperability level, which is
fundamentally important in that no communication can be achieved with-
out it.
The ultimate goal of this research was to develop an interoperability
solution for healthcare, and to this end a framework built on Jini technol-
ogy was created as a platform within which to exchange the semantically-
interoperable messages. Jini is a Service-Oriented Architecture for the con-
struction of secure, scalable distributed systems [Jin08]. The Jini Health
Interoperability Framework (called HIF-J) provides the technical interoper-
ability solution within which the semantic interoperability techniques can
be used. HIF-J also makes use of JavaSpaces (an optional part of Jini).
161
CHAPTER 7. THE JINI HEALTH INTEROPERABILITY FRAMEWORK
162 (HIF-J)
The first step in implementing HIF-J was to create a Jini service front-
end for the SNOMED CT XML Database (Chapter 6). Next, translation ser-
vices – both for translating between HL7 Versions 2 and 3, and for translat-
ing between HL7 and openEHR – were created using the message models,
mapping techniques and XSLT transforms detailed in the Ontology Map-
ping chapter (Chapter 5).
This chapter will provide some background on the Jini architecture and
then go on to detail the components of HIF-J – the Terminology Server,
Translation Service, and the HealthSpace JavaSpace (for messaging).
7.1 The Jini Architecture
Jini technology is a simple infrastructure for providing services in a net-
work, and for creating spontaneous interactions between programs that
use these services [AOS+ 99].
The goals of the Jini architecture are:
• Network plug-and-work – plugging a service or device into the net-
work should be all or almost all you need to do to make the service
available or deploy it to a device.
• Erase the hardware/software distinction – a service on the net-
work should be available in the same way whether it is implemented
in hardware, software or a combination of both
• Enable spontaneous networking – when services plug into the
network and are available, they can be discovered and used by clients
and other services.
• Promote service-based architecture – The easier it is to make a
service available on a network, the more services you will find on the
network.

7.1. THE JINI ARCHITECTURE 163
• Simplicity – simple systems are easier to learn and use, and sys-
tems built on simple principles will be more robust than complicated
systems.
The methodology and aims of the Jini technology make it an ideal plat-
form for distributed communication in health. According to MuleSource
Inc., Service-Oriented Architecture (SOA) “enables better integration of IT
resources, including previously isolated application silos” [Mul08c]. This is
good news for the healthcare industry, where application and information
silos are one of the main communication problems. The Jini Architecture is
an example of an SOA.
The base functions available within Jini can be broken into five areas:
• Discovery
• Lookup
• Leasing
• Events
• Transactions
These functions will each be explained, following a short discussion of
how JavaSpaces relate to Jini. The Entry class, which is part of the Jini
architecture and is crucial to JavaSpaces, will also be explained.
7.1.1 Jini and JavaSpaces
JavaSpaces are based on the tuple space coordination model of distributed
computing, which started in 1983 as embodied in the Linda programming
system by Carriero and Gelernter [CG01]. JavaSpaces provide a mecha-
nism for performing shared distributed computing, and also an interesting
and easy mechanism for persistent object storage [Hal02].

164 (HIF-J)
Technically, a JavaSpace is a Jini service that makes use of the Jini in-
frastructure and provides its capabilities to other Jini clients and services.
Therefore, a JavaSpace is a Jini service which acts as a shared distributed
object repository. As such, one the most common uses of JavaSpaces is for
information sharing, such as in messaging or chat systems, which is how
JavaSpaces is used in the context of HIF-J.
7.1.2 Lookup and Discovery
Every Jini system is built around one or more lookup services – multiple
lookup services may exist in a network. Other services use the lookup
service to advertise their availability so that clients may find them. The
process of finding the lookup service is called discovery.
Each lookup service provides a list of available services, the proxy ob-
jects for the services and its attributes.
Figure 7.1 shows the process for the SNOMED CT Service to register
with a lookup service. When the service starts, it uses discovery to find the
lookup service. The service then registers its proxy with the lookup service.
A proxy is a Java object containing the interfaces it implements and its
superclasses to define the service it is providing. A client can then lookup
that type of service and download the proxy (Figure 7.2). The client can
then invoke methods on the proxy object to use the service (Figure 7.3).
7.1.3 Leasing
When a service registers with a lookup service, it receives a lease from the
lookup service. Leases are a programming model within the Jini architec-
ture designed to allow providers of resources to clean up when the resource
is no longer needed [AOS+ 99]. As long as a service is up and running, it will
renew its lease. If the service crashes, its lease will expire, which allows the
lookup service to keep its list of available services up to date.

7.1. THE JINI ARCHITECTURE 165
Figure 7.1: Jini process for registration with a lookup service (based on
figure in [AOS+ 99]).
Figure 7.2: Jini process for finding a service (based on figure in [AOS+ 99]).
Figure 7.3: Jini process for using a service (based on figure in [AOS+ 99]).

166 (HIF-J)
7.1.4 Events
In programming in general, an event is a notification from an object, corre-
sponding to some change in the abstract state of the object [AOS+ 99]. The
Jini architecture has infrastructure in place called the Jini Event Specifi-
cation to handle distributed events.
The purpose of the Jini distributed event specification is to allow an
object in one Java Virtual Machine (JVM) to register interest in a certain
event occurring in an object in some other JVM, perhaps running on a dif-
ferent physical machine, and to receive a notification when an event of that
kind occurs [Sun05]. The Jini Event Specification takes into account the
circumstances of a distributed system, as opposed to local events.
7.1.5 Transactions
In general, a transaction is a tool that allows a set of operations to be
grouped in such a way as to guarantee them to all succeed or all fail [AOS+ 99].
The Jini architecture defines the Jini Transaction Specification, in which
the representation of a transaction is encapsulated in an object. A key part
of the transaction specification is the TransactionManager class, which cre-
ates and oversees transactions in Jini. Transactions are particularly im-
portant for JavaSpaces.
7.1.6 The Entry Class
A JavaSpace is a shared virtual space where tasks, requests and informa-
tion can easily be exchanged in the form of Entry objects [Hal02]. The Java
class Entry is a core part of the Jini specification and is crucial to JavaS-
paces in particular. The only type of objects which can be written to and
read from a JavaSpace are Entry objects. This class is explained in more
detail with respect to HealthSpace and the Message class implementation
in Section 7.4.

7.2. HEALTH INTEROPERABILITY FRAMEWORK
- JINI 167
7.2 Health Interoperability Framework
- Jini
Figure 7.4 shows the technical architecture of HIF-J. HIF-J is made up of
a JavaSpace (HealthSpace) for communication, and several Jini services.
The Jini services shown are the SNOMED CT Terminology Server and the
Translation Services. More Jini services can be added as they are required
or implemented.
The backend of the SNOMED CT Terminology Server is the SNOMED
CT Vital Signs XML database described in detail in the previous chapter.
The Translation Services rely on the XSLT transforms which were part of
the outcome of the ontology mapping described in Chapter 5.
A front-end client application for entering patients’ observations was
developed for demonstration and testing of HIF-J. This client observation
application can plug into HIF-J and communicate with other observation
applications and access the available Jini services.
All of the components of HIF-J are written in Java and are detailed in
the following sections.
7.3 SNOMED CT Terminology Server
A front end Jini service was built for the SNOMED CT Vital Signs XML
Database, to provide easy access to the terminology. Several functions were
built into the service, including:
• Retrieve a concept, given an SCTID;
• Return a list of parent concepts for a given concept;
• Return a list of child concepts for a given concept;
• Return a list of sibling concepts for a given concept;

168 (HIF-J)
Figure 7.4: The Technical Architecture of HIF-J.
• Return a list of descriptions for a given concept;
• Return all of a given concept’s attributes/relationships.
The first function returns the full details of a SNOMED CT concept from
its SCTID. For the other five functions, either the SCTID or the complete
concept can be passed to the Terminology Server to retrieve the list of par-
ents, children, siblings, descriptions or relationships.
Figure 7.5 shows the Java class structure of the SNOMED CT Terminol-
ogy Server. The class SnomedServer implements the interface SnomedCt
and uses the proxy class SnomedProxy (which also implements the Snom-
edCt interface). The details of how these classes interact was shown in
Figures 7.1, 7.2 and 7.3.

7.4. HEALTHSPACE 169
Figure 7.5: Java class structure of the Jini SNOMED CT Terminology

Server.
7.4 HealthSpace
HealthSpace is a JavaSpace implementation, used in HIF-J for communi-
cation. Communicating with a JavaSpace involves writing Entry objects to,
and reading Entry objects from, the space.
There are only seven methods in the JavaSpace interface, but these
seven methods provide the basis for more complex distributed systems [Hal02].
The seven methods are as follows:
• Read – allows an Entry to be read from a JavaSpace, without remov-
ing it. This allows a JavaSpace to be searched. The Read method will
wait until a matching Entry is found or a specified timeout is reached.
• ReadIfExists – ReadIfExists has the same functionality as Read, ex-
cept that it returns immediately if no matching Entry is found, in-
stead of waiting.
• Take – Take also has the same functionality as Read, except that if a

170 (HIF-J)
matching Entry is found, it is removed from the space. If two clients
try to Take an Entry, only one client will be successful.
• TakeIfExists – the same as Take, but does not wait for a matching
Entry and returns immediately.
• Write – allows an Entry to be written to a JavaSpace.
• Notify – provides an asynchronous mechanism for being informed
when Entries of interest are added to a JavaSpace.
• Snapshot – Snapshot is a way to optimize performance when similar
large objects are continually being read from a JavaSpace, the details
of which are not necessary here.
These seven methods can be reduced to three basic types of functionality
– Read, Take and Write (Notify is fundamentally the same as Read, but
implemented as a listener). These three simple functions provide all the
basic blocks which are needed for building a messaging system.
7.4.1 The Message Class
The Message class, a subclass implementation of Entry, was created for
communication within HealthSpace. The Message class has three impor-
tant attributes: To, From and Body.
Entry objects are read from a JavaSpace by passing a template of the ob-
ject which is desired to the space. In HIF-J, a message template is passed
to HealthSpace with the To field filled in with the client’s name, and wild-
cards for the From and Body fields. Figure 7.6 shows an example of writing
a Message object to the space and using a Message template to read from
the space.
The To attribute is used for basic routing – a client can receive its mes-
sages by taking Message Objects from HealthSpace in which their name is

7.5. MESSAGING PROTOCOLS 171
in the To field, as shown in Figure 7.6. The Body attribute contains the
payload of the message, which is actually represented in HL7 XML.
Figure 7.6: Example of writing a Message object to HealthSpace and using

a Message template to read from the HealthSpace.
Messages can be sent to multiple clients by setting the To attribute to
the name of a group. Then clients belonging to that group can perform a
Read operation on the message, thus leaving the message for other group
members rather than removing it from the space with a Take operation.
HealthSpace is implemented as a persistent JavaSpace, so Messages
will persist even if the JavaSpace is restarted. Messages will stay in Health
Space until they are retrieved by the receiver. The receiver does not have to
be available when the message is written to the space by the sender. This
means HealthSpace is asynchronous, promoting loose coupling between
clients in HIF-J. Thus, a very simple, persistent, asynchronous messaging
system has been created.
7.5 Messaging protocols
HL7 Version 3 is the messaging standard chosen for HIF-J, using the ob-
servations message models based on SNOMED CT discussed in Section 5.3
in the Ontology Mapping chapter. HL7 V3 RMIMS, HMDs, etc, developed

172 (HIF-J)
for a specific purpose are called artifacts and are shown next.
7.5.1 HL7 Artifacts
The HL7 RMIM used for observation messages in HIF-J is shown in Fig-
ure 7.7. The ‘dotted’ box around the component ActRelationship and
ObservationEvent Act in the figure means that this section may be re-
peated many times, once for each observation taken (cardinality 1..*). This
is the RMIM used in the example mapping of HL7 V3 → HL7 V2 in Section
5.4.1. The serialised HMD from the RMIM is shown in full in Table 7.1
(continued in 7.2).
Figure 7.7: HL7 RMIM used for Observation messages in HIF-J.
XML messages rendered from this HMD is communicated as the pay-
load (Body attribute) of a Java Message object to communicate via Health-
Space between Observation Applications in HIF-J.
7.6 Jini Translation Service
The XSLT stylesheets derived from mappings between HL7 V3 and HL7
V2, as mentioned in Chapter 5, were used by the HIF-J Translation Ser-

7.6. JINI TRANSLATION SERVICE 173
Table 7.1: HL7 HMD taken from RMIM in Figure 7.7 for Observation mes-
sages in HIF-J.
No Element Name Ca- Ma- Co- RIM Source Element Dom-

rd nd nf Type ain
Clinical Observations
1 PatientObservations 1..1 ActHeir Observation
Event
2 classCode 1..1 M R Act CS OBS
3 moodCode 1..1 M R Act CS EVN
4 id 1..1 M R Act II
5 code 1..1 M R Act CD SCT
6 text 0..1 Act ST
7 effectiveTime 1..1 M R Act TS
8 methodCode 0..1 Observation CE SCT
9 subject 1..1 M R Act Subject
10 typecode 1..1 M R Participation CS SBJ
11 patient 1..1 M R Participation Patient
12 classCode 1..1 M R Role CS PAT
13 id 1..1 M R Role II
14 code 1..1 M R Role CE SCT
15 addr 0..1 R Role AD
16 telecom 1..3 M R Role LIST
<TEL>
17 patientPerson 1..1 M R Role Patient Per-
son
18 classCode 1..1 M R Entity CS PSN
19 determinerCode 1..1 M R Entity CS INST
20 name 1..1 M R Entity PN
21 aGenderCode 1..1 M R LivingSubject CE SCT
22 birthTime 1..1 R LivingSubject TS
23 disabilityCode 0..1 LivingSubject SET<CE> SCT
24 raceCode 1..1 R LivingSubject SET<CE> SCT
25 performer 1..1 M R Act Performer
26 typecode 1..1 M R Participation CS PRF
27 careGiver 1..1 M R Participation CareGiver
28 classCode 1..1 M R Role CS CARE
29 id 1..1 M R Role II
30 code 1..1 M R Role CE SCT
31 addr 0..1 Role AD
32 telecom 0..1 Role TEL
33 careGiverPerson 1..1 M R Role CareGiver
Person
34 classCode 1..1 M R Entity CS PSN
35 determinerCode 1..1 M R Entity CS INST
36 name 1..1 M R Entity PN

174 (HIF-J)
Table 7.2: HL7 HMD taken from RMIM in Figure 7.7 for Observation mes-
sages in HIF-J (cont.)
No Element Name Card Ma- Co- RIM Source Element Dom-

nd nf Type ain
37 component 0..* R Act SET
<Comp>
38 typecode 1..1 M R ActRelationship CS COMP
39 contextControlCode 1..1 R ActRelationship CS AP
40 observationEvent 1..* R ActRelationship Observ-
ation
41 classCode 1..1 M R Act CS OBS
42 moodCode 1..1 M R Act CS EVN
43 code 1..1 M R Act CD SCT
44 text 0..1 R Act ST
45 effectiveTime 1..1 M R Act TS
46 value 0..1 R Observation ST
47 interpretationCode 0..1 Observation CE SCT
48 methodCode 0..1 Observation CE SCT
49 targetSiteCode 0..1 Observation CE SCT
vice for translation between message formats. Translation between HL7
V3 and openEHR was also implemented in the same service, by using the
appropriate XSLT transforms.
The HIF-J Translation Service works by taking three arguments – the
format the message is in, the format to be converted to, and the message
itself. The service then uses XML processing libraries to load the appropri-
ate XSLT transform and convert the message before returning it in the new
format. If the message is in V2 and needs to be converted to openEHR, two
conversions are performed: V2 → V3 → openEHR.
A formatting function was also written in Java, to format V2 observa-
tion messages from EDI (“pipes and carets”) format to XML if necessary.
If an application is using V2 in the EDI format, the message can first be
formatted as XML and then transformed to V3.
Figure 7.8 shows the Java class structure of the Jini Translation service.
As can be seen, it is the same structure as the SNOMED CT Terminology
Server, with an interface and a proxy, and then the main Translation-
Service class.
The Translation service only has two functions, as most of the conver-

7.7. THE OBSERVATION CLIENT APPLICATION 175
Figure 7.8: Java class structure of the Jini Translation Service.
sion work is done by XSLT:
• Translate – The main functionality, converting between versions of
HL7 and openEHR using XSLT.
• ConvertV2 – The HL7 V2 conversion function, for converting between
EDI and XML.
Now that the Terminology Server, Translation Service and messaging
system have been established, a client is needed to demonstrate the inter-
operability framework.
7.7 The Observation Client Application
A small client to collect patients’ observations was created for testing HIF-
J. The Observation Application has a simple form for entering patient ob-
servations data and then sending them to other Observation Applications
in the Jini Framework, via HealthSpace. A screen shot of the main form

176 (HIF-J)
of the Observation Application is shown in Figure 7.9, and a screen shot of
the Messaging Form is shown in Figure 7.10.
In the main form, a clinician can log in and set the name of the client
for identification and communication purposes. A patient’s observations
details can then be entered, with a drop-down select box for ‘code’, which is
populated with SNOMED CT codes supplied from the Terminology Server.
Once a code has been selected, the ‘procedure’ and ‘site’ drop-down boxes
will be populated from the Terminology Server based on relationships with
the chosen observation code.
After the ‘value’ has been entered, the decision support system discussed
in Section 5.3.2 will populate the interpretation code field (this field appears
in the message, and is not shown on the form). As noted in that section, the
option to turn the decision support off is included in the ‘options’ menu. In
that case, the interpretation code field is omitted from the message. The
clinician may enter their conclusions in the ‘clinical notes’ field.
Once the client’s name has been set, messages can be read from Health-
Space by searching for Messages with the client’s name in the to field. Mes-
sages can be manually checked by clicking ‘Check Messages’ in the Mes-
saging Form, or notifications can be set up so that the application will be
notified as soon as messages addressed to it are written to the space.
The Messaging Form also allows translation of the Message before send-
ing, simply for demonstration purposes. In a full-scale system, translation
may be necessary for some clients and not for others.
The Observation Application also includes a SNOMED CT browser, for
the purpose of demonstrating the SNOMED CT Terminology Server. A
screenshot of the SNOMED CT browser form is shown in Figure 7.11. The
browser has buttons corresponding to each of the Terminology Server’s
functions, which will be executed on a code entered into the ‘SCTID’ field
once clicked, the output of which is then displayed in the text area on the
right. Although the SNOMED CT Terminology Server is being used in the

7.7. THE OBSERVATION CLIENT APPLICATION 177
Figure 7.9: A screen shot of the main form of the Observation Application.
Figure 7.10: A screen shot of the Messaging Form of the Observation Ap-
plication.

178 (HIF-J)
Figure 7.11: A screen shot of the SNOMED CT browser in the Observation

Application.
main form of the application, the browser is for further demonstration and
testing purposes.
7.8 HL7 Java Package
HL7 classes were modelled in Java in the package ajr.hsb.hl7, which is
a Java implementation of the C# HL7 package developed in ePOC (Chapter
4). The class structure is shown in Figure 7.12. The lines with hollow
arrowheads show an inheritance or superclass/subclass relationship. I.e.,
HL7Person is a subclass of HL7Entity, and HL7Subject is a subclass
of HL7Participation. The lines with the small black arrowheads show
where one class is used by another within the package.
These classes are highly reusable for any HL7 implementation and were
used in both HIF-J and the HSB (see next chapter). The class structure is
modelled directly from the HL7 class structure, as previously mentioned in
Section 4.6.
7.9 JavaSpace Problems
When researching communication channel types it became apparent that
the JavaSpace messaging paradigm fell short, in that the only communica-

7.9. JAVASPACE PROBLEMS 179
Figure 7.12: Classes in the Java HL7 Package.
tion channel type which is supported is publish-subscribe. That is, senders
publish messages to the space and receivers subscribe to the space. The per-
formance of the HealthSpace implementation could drop if there are hun-
dreds of users – having to check every single Message in the space to see if
it is addressed to the checking application is not efficient, and even worse
is hundreds of listeners on the space sending events whenever a Message
is written using the Notify operation.
In an effort to also offer peer-to-peer message channels, incorporating
Mule Enterprise Service Bus software [Mul08a] into HIF-J was investi-
gated, as Mule has an interface to JavaSpaces. However, after further re-
search it became apparent that the interface between Mule and JavaSpaces
is designed with systems using a JavaSpace as a shared database in mind,
and a simpler solution is to use the one messaging system for all types of
messaging – in this case the Mule Message-Oriented Middleware (MOM)
core.

180 (HIF-J)
The final decision was to implement a custom health communications
framework by implementing a Mule ESB and to reuse the components of
HIF-J as services on that ESB. This solution is called the Health Service
Bus and is detailed in the next chapter.
7.10 Conclusions from HIF-J
The Jini Technology offers an easy to use plug-and-play paradigm for con-
necting clients with services in a network. JavaSpaces, based on tuple
spaces – a paradigm which is elegant in its simplicity, enabled the setup of
a persistent, asynchronous messaging system which is also plug-and-play.
HIF-J offers a starting point in creating an interoperability framework for
health, and yielded some reusable components.
However, although publish-subscribe is a good messaging channel for-
mat sometimes it is not as fast or secure as endpoint-to-endpoint communi-
cation and it would offer more flexibility to include other message channel
formats in a real solution. Due to this, and also due to the fact that JavaS-
paces were deemed not scalable enough to provide a real-world commu-
nication solution, HIF-J does not measure up as the best interoperability
framework.
A final interoperability solution, called the HSB, was built on an open-
source ESB implementation (Mule), and is detailed in the next chapter
(Chapter 8). The HSB, while providing an underlying reliable messaging
system for technical interoperability, and a message format which is se-
mantically interoperable, also addresses process interoperability and thus
is a complete solution.

Chapter 8
Health Service Bus (HSB)
The previous chapter defined a framework for messaging which is service-
oriented and platform independent, called HIF-J. However, the JavaSpace
messaging solution is not scalable and allows for only one messaging para-
digm, namely publish-subscribe. While a Jini Architecture implementation
can achieve a high level of distribution by duplicating lookup services, it is
not the best solution to the problem.
The final solution and outcome of this research is an Enterprise Service
Bus (ESB) for health, called the Health Service Bus (HSB). Just like HIF-J,
the HSB provides the technical interoperability solution within which the
semantic interoperability techniques can be used. As well as the first two
levels defined in Section 1.4.1 (technical and semantic), the third level of
interoperability, that of process interoperability, is also enabled by the HSB
infrastructure, providing a complete interoperability solution.
Like the Jini Architecture, ESB is a Service-Oriented Architecture (SOA)
solution, and so is a good solution for solving the information silo problem,
which is a widespread health information dilemma.
A conceptual diagram of the HSB architecture is shown in Figure 8.1.
The HSB is a distributed enterprise integration solution and provides com-
munication between disparate health systems which can all be connected
181
182 CHAPTER 8. HEALTH SERVICE BUS (HSB)
Figure 8.1: Conceptual diagram of the Health Service Bus (HSB).
regardless of the type of software or hardware used. The HSB also provides
a Terminology Service and Translation Services.
8.1 ESB Background
An Enterprise Service Bus provides a loosely-coupled, highly distributed
approach to integration (see also Section 1.5.1). In industry, analyst firms
such as Gartner Inc have been writing about the ESB trend since early
2002, when it was first introduced. In a Gartner report from 2002, Schulte
defined ESB as consisting of four main “pillars” – Message Oriented Middle-
ware (MOM), web services, routing intelligence and transformation [Roy02].
In his book, Enterprise Service Bus [Cha04], Chappell expands on the
characteristics of an ESB that Schulte outlined, as listed below:
• Message Oriented Middleware (MOM)
– Robust, reliable transport
– Efficient movement of data across abstract data channels

8.1. ESB BACKGROUND 183
– End-to-end reliability
• Web Services
– Service Oriented Architecture (SOA)
– Abstract business services
• Intelligent routing
– Message routing based on content and context
– Message routing based on business process rules
– Business process orchestration
• XML transformation
– Based on XSLT and independently deployed service types
The intelligent routing characteristics include business process rules
and orchestration, which are part of the HL7 Interoperability Work Group’s
definition of process interoperability [HL707]. Business process orchestra-
tion, in this context, refers to the ability to layer constraints and workflows
on top of the ESB messaging layer. The layerability of ESB contributes to
its interoperability. It means that local communication networks can be
integrated into wider networks with ease.
The HSB is scalable in that ESB is a highly distributed enterprise in-
tegration solution. Services that can work together are actually separated
due to loose coupling principles and can be scaled independently from one
another.
8.1.1 Service Containers and Endpoints
In an ESB, all applications and services that are connected to the bus are
considered abstract endpoints. The underlying implementations of these
endpoints can be very diverse, but the abstraction of treating them all the

same provides a powerful paradigm for higher-level tools to assemble end-
points into process flows (again, part of process interoperability).
A service container is a physical implementation of an endpoint and
provides the service interface to the ESB. The traits of service containers
lead to the highly distributed nature of the ESB [Cha04].
Figure 8.2 shows a generic endpoint connected to an ESB with its ser-
vice container. The dashed line in the figure represents a virtual or phys-
ical connection to the ESB. The diagrams of ESB integration patterns in
this work use glyphs based on Gregor Hohpe’s diagrams of Enterprise In-
tegration Patterns in [HW04] (called “Gregorgrams”) plus extra glyphs for
ESB-specific concepts in a similar style from [Cha04]. Diagramming con-
vention means that an endpoint is always shown to reside inside a service
container.
Figure 8.2: Generic ESB endpoint.
Service containers should handle configuration, fault handling and man-
agement data. This is referred to as the “invocation and management
framework” and is shown inside the service container in Figure 8.2.
In terms of vertical scalability, a service container may manage multiple
instances of a service; and in terms of horizontal scalability, several service
containers may be distributed across multiple machines for the purpose of
handling increased message volume [Cha04].

8.2. MULE OPEN SOURCE ESB 185
8.2 Mule Open Source ESB
Mule is the world’s most widely used open-source ESB [Mul08a]. Mule-
Source Inc. describe an ESB as
“a range of functions designed to offer a more flexible and man-
ageable way to enable a disparate range of applications to work
together. The central element to any ESB is a message bus that
is used as the communication medium or ‘wire’ between different
components or applications on the bus” [Mul08b].
Mule is a Java-based messaging framework. Mule implements many trans-
port formats including HTTP, FTP, SMTP, SOAP, and JMS (Java Message
Service). .
The messaging backbone of the Mule ESB is usually implemented using
JMS, but any other message server implementation could be used, such as
MSMQ (Microsoft Message Queue), IBM WebSphere MQ, etc.
In Mule, application functionality is wrapped as a service, which in-
cludes a service component (business logic), routers (which use endpoints
to specify where to send the message), and configuration settings. This is
consistent with the standard for ESB service containers and endpoints.
The choice and flexibility of technology and standards available in Mule
does not impede its ease of connectivity or its plug-and-play features.
Another open-source SOA company, WSO2, conducted testing to com-
pare their ESB to Mule [Per08]. However, in the course of their tests
they had not configured their Mule implementation correctly, leading Mule-
Source to conduct their own tests in response. This time, with the correct
configuration, the results were that Mule came out favourably in terms of
flexibility, scalability and performance [Mul08c].

Figure 8.3: The components of the Mule HSB demo implementation.
8.3 HSB Mule Implementation
A prototype HSB system was built for proof-of-concept purposes using Mule.
The Observation Application used for demonstration purposes in HIF-J was
also used to demonstrate the HSB, with some slight modifications for the
new framework, and is now referred to as “HSB Client”. In HIF-J, the front
end to the SNOMED CT Vital Signs database is a Jini Service, but in the
HSB the database was attached to a Web Services front-end using Apache
CXF (an open-source services framework), to fit in with the ESB architec-
ture. Likewise, the Translation Services from HIF-J were also configured
with a CXF Web Services front-end and otherwise reused.
Figure 8.3 shows the components of the demonstration HSB implemen-
tation. From left to right, the components are a Translation Service and
XML database and service, as discussed, followed by an email-drop service,
content-based router, and finally the HSB Client.
The purpose of the email-drop service is for automatically sending emails
to a designated address when errors occur on the HSB. A service container
is set up containing an endpoint which simply connects to an SMTP server
and sends an email with a given subject and message to a defined address.

8.4. MESSAGING PROTOCOLS FOR THE HSB 187
The other services on the HSB are then configured to automatically use this
service whenever an error occurs.
In HIF-J, all messages are deposited into the HealthSpace JavaSpace, to
be collected by the addressee. The HSB incorporates content-based routing,
meaning that messages can be directed to interested parties based on the
contents of the message.
This HSB forms the base for expansion with the other artifacts de-
scribed in this thesis – the referral application from Chapter 3 and the
ePOC system, both PC and PDA – which are also connected. Even though
these applications were developed in C# using .NET and the HSB Client
and services are Java-based, connection between them is possible by adding
a small adapter to each application and then connecting it to the HSB. Fig-
ure 8.4 shows the final configuration of the prototype.
The Mule messaging system is managed by a configuration file which is
an XML document containing business logic dictating how certain services
should connect to the bus. This means that changing transport protocols
does not require any programmatic changes. This is an example of process
interoperability.
8.4 Messaging protocols for the HSB
HL7 V3 is chosen as the message format in the HSB. The HL7 modelling
methodology complements the Health Service Bus, and uses XML as the
communication language – an ESB requirement. The HL7 artifacts em-
ployed in HIF-J (Section 7.5.1) are reused in the HSB.
To allow legacy systems and openEHR systems to communicate on the
HSB, translation to Version 2 and openEHR have also been implemented,
as in HIF-J. The XML Implementable Technology Specifications for both
HL7 Version 2 and openEHR were used, in keeping with the XML-centred
approach of the HSB.

Figure 8.4: Configuration overview of the Mule HSB prototype implemen-

tation.
8.4.1 Canonical Message Model
Translation services enable communication between applications, but if a
large number of applications with differing message formats want to com-
municate on the HSB the number of transformations needed quickly grows
to be unmanageable. A translation service is required between each appli-
cation’s format and every other application’s format, if all applications are
required to communicate with each other. With respect to the Mule demon-
stration implementation, this would mean two XSLT stylesheets would be
needed per pair of applications (to translate both ways), so for six dif-
ferent applications with different formats, this would mean thirty XSLT
stylesheets at worst (fifteen combinations of formats, times two). Of course,
every application may not need to communicate with every other applica-

8.4. MESSAGING PROTOCOLS FOR THE HSB 189
tion, so this is a worst-case scenario, but it shows that the number of trans-
lation definitions to facilitate this communication grows exponentially.
Hohpe and Wolfe define a Canonical Data Model as a data model which
“...defines message formats that are independent from any spe-
cific application so that all applications can communicate with
each other in this common format.” [HW04]
The advantages of a canonical format for all messages can be seen in
Figure 8.5.
Figure 8.5: Comparison of number of translations with and without a

Canonical Message Model.
The one downside of a canonical message model is that each message in
the system now has to be translated twice, once into the canonical format
at the sending end, and once from the canonical format when received. This
causes a problem in systems with very high throughput [HW04]. However,
new applications which are developed can use the canonical message model
internally and thus not require any translations. This includes new appli-
cations which replace legacy systems: reducing the number of formats in
the system overall.

Using a canonical message model decreases dependencies between ap-
plications and promotes loose coupling, in turn reducing the complexity of
the system. If the internal format of an application changes, only the trans-
lation between that application and the canonical message model needs to
be changed, without any other applications being affected [Cha04, HW04].
In the prototype HSB implementation, the HL7 Version 3 message mod-
els based on SNOMED CT are used as the canonical message model. Figure
8.6 shows the translations required in the Mule HSB.
Figure 8.6: Transformations in the Mule HSB, using a Canonical Message

Model.
8.5 Translation Service
The HSB Translation Service reuses the core functionality of the HIF-J
Translation Service. That is, the XSLT stylesheets developed during ontol-
ogy mapping were again used within the Java TranslationService class,
which contains the translation functionality. The translation interface and
proxy classes are not needed in the HSB, as it has a different communica-

8.6. CONTENT-BASED ROUTING 191
Figure 8.7: Part of the Mule Configuration setting up a CXF endpoint to

the Translation Service.
tion paradigm to HIF-J.
A CXF Web Services front-end is set up in the Mule configuration file, as
an endpoint to the Translation Service, in the HSB. Figure 8.7 shows part
of the Mule configuration file setting up the Translation Service’s endpoint.
As can be seen in the figure, the service is made up of an endpoint and a
component, which points to the Java class file TranslationService. The
endpoint has configured the service to run on port 8778 on the computer
named ‘Flexo’.
8.6 Content-Based Routing
A Content-Based Router examines the contents of a message and then routes
it based on information contained in the message [HW04]. In the HSB, mes-
sages are routed based on who the messages are addressed to. HSB clients
register their names with the Router when they first connect to the bus.
Messages between HSB clients are then sent through the Router, which
will pass them on to the appropriate party. The Content-Based Router
reads the “to” field in the HL7 message header and sends the message to
the addressee.
This is different to the messaging paradigm in HIF-J in that an extra
layer of addressing is added to the HL7 messages in that framework via
the HL7 XML message being wrapped in a Java Object as the payload of
the message. Extra attributes are then included in the Object for address-
ing information (see Section 7.4.1). In the HSB, no extra wrappers need to

Figure 8.8: Comparison between HIF-J and HSB message formats.
Figure 8.9: Representation of a Content-Based Router in the ESB diagram-

ming convention.
be added to the HL7 messages, as all messages between clients are sent to
the Router, and the Router then reads the HL7 XML directly. This com-
parison is shown in Figure 8.8. As Figure 8.8 clarifies, header information
from the HL7 message is repeated in the Java Object in HIF-J, making the
addressing redundant.
In ESB diagram notation, a Content-Based Router is symbolised by an
arrow being split into many arrows, inside a service container connected to
an endpoint. This represents one incoming message channel to the router,
and many outgoing message channels from the router to the messages’ final
destination. This representation is shown in Figure 8.9.
The Content-Based Router is configured using a Mule Virtual Memory

8.7. PATIENT RECORDS IN THE HSB 193
(VM) endpoint in the HSB implementation. The VM transport is used for
intra-VM communication between components managed by Mule [Mul09],
i.e. it is an in-memory transport meaning that it will only work within a
single Mule instance. In a larger implementation, in which multiple Mule
implementations may need to communicate over a network, a transport
such as HTTP or JMS would be used. The VM transport is useful in mod-
elling other transports in small systems. It can be set to synchronous or
asynchronous and can be used for testing with a low configuration over-
head. In the HSB, the VM transport is configured to be asynchronous by
way of the queueEvents attribute, as shown in Figure 8.10.
Figure 8.10: Part of the Mule Configuration setting up a VM endpoint to

the Content-Based Router.
8.7 Patient Records in the HSB
Messaging and terminology were concentrated on in HIF-J, with no stor-
age of continuous patient records. In the HSB, continuous patient records
are stored. An XML database (again using eXist, Section 6.4) was cre-
ated to store XML instances of openEHR patient records. This means that
openEHR was used more to its full purpose in the HSB as compared to HIF-
J. Rather than setting up a Translation Service between HL7 Version 3 and
openEHR merely to demonstrate this transform, openEHR was leveraged
for the long-term storage of patient data.
The similarity between observation structures in HL7 and openEHR
(see Figure 5.9 in Chapter 5) make this process a matter of XML transfor-

mation. The HL7 messages are converted to a continuous openEHR record
by translating the observation sections of the HL7 messages to openEHR
observations, and then storing them as observation entries in the relevant
patient’s record. The process of storing the observations in the patient’s
record, after translation from HL7, is shown in Figure 8.11. The XML
Parser shown in Figure 8.11 is part of the front-end functionality of the
EHR database, depicted as “XML Services” in Figure 8.4. It is also possible
to translate and send sections of a patient’s EHR as HL7 messages, e.g. in
response to queries, by performing the inverse translation. The XML parser
will group the observations of interest into an openEHR Section, and then
pass it along to the Translation Service to be converted to HL7 Version 3
and then sent on.
Figure 8.11: Patient Records stored in an XML Database in the HSB. Ob-
servation Entries are stored in a patient’s EHR.
8.8 SNOMED CT Terminology Service
Just as in HIF-J, a front-end service was used with the SNOMED CT Vi-
tal Signs XML database, for programmatic access to the terminology. In
the HSB, the service is a Web Services front-end, as opposed to a Jini ser-
vice. This is the same configuration as the Translation Service, with the

8.9. END-TO-END EXAMPLE 195
CXF front-end configured in the Mule build file, a business logic step which
allows all other entities on the bus access to the SNOMED CT terminol-
ogy. Figure 8.12 shows part of the Mule configuration file setting up the
Terminology Service’s endpoint.
Figure 8.12: Part of the Mule Configuration file setting up a CXF endpoint
to the SNOMED CT server.
8.9 End-to-End Example
Figure 8.13 shows an end-to-end messaging example from the Mule HSB
implementation. The HSB Client application wishes to send a message on
the HSB to another HSB Client. Step 1 is to duplicate the message and send
it on to both the Content-Based Router and the Translation Service. All
observations messages sent from the HSB Client Observation Applications
are recorded in the openEHR database in the respective patient record.
Step 2 is the Content-Based Router, which routes the message as described
in Section 8.6 and sends it on to the receiver (Step 3).
Step 4 is the Translation Service, which translates the HL7 message
into openEHR and passes it on to the EHR database (Step 5), where it is
stored in the database as described in Section 8.7.
8.10 Total Interoperability in the HSB
All three levels of interoperability (based on the definition in [HL707]) are
achieved in the HSB making it a better solution than HIF-J, which does not
achieve the level of process interoperability.

Figure 8.13: End-to-end example of the Mule HSB implementation.
Technical Interoperability
Technical interoperability is achieved in the HSB by the central HSB struc-
ture, specifically the messaging bus core. In Section 1.4.2 at the start of
this work, messaging was determined to be the best solution to technical
interoperability. Mule has a Message-Oriented Middleware core, which of-
fers security and reliability in transport, different message channel types,
and loose coupling of entities due to asynchrony. All of this is achieved with
no extra setup, except to plug the clients and services into the bus.
Semantic Interoperability
Semantic interoperability is achieved in the HSB by the canonical message
model used, which is the result of ontology mapping from SNOMED CT to
HL7. Semantic integrity is also assured in the transformations to HL7 Ver-
sion 2 and openEHR, by careful ontology mapping preserving the SNOMED
CT terminology from the canonical message model.

8.11. HSB EXAMPLE 197
Process Interoperability
Process interoperability can be achieved in the HSB, by way of the intel-
ligent routing characteristics of ESB. Process interoperability can also be
enhanced by including monitoring facilities in a HSB implementation. The
process interoperability level is trivial in the small HSB implementation
outlined above, but a possible real-life example in the following sections
will show how process interoperability could work in an actual setting.
8.11 HSB Example
The small HSB Mule implementation is useful for demonstrating how ESB
concepts can be applied to healthcare, and as a proof-of-concept. However,
a large scale health information system is more complicated than this. This
section will step through an industry-level example to show how the HSB
could work in a care network implementation.
The facilities included in the example are as follows:
• GP Clinic
• Hospital
• Pathologist
• Radiologist
• Pharmacy
• Aged Care
• Community Care
• Registration Board
Each facility will be outlined in the following subsections.

8.11.1 GP Clinic
The GP clinic is an example General Practice clinic, of which there could be
many in a care network. The computer system at the GP clinic is made up
of a desktop application and a records management system, which is con-
nected to a records database. The GP and records management applications
are custom applications written in C#.NET. The GP also has a communica-
tions management console on the HSB. Figure 8.14 shows the GP computer
system.
Figure 8.14: GP computer system in the HSB.
The C# client is shown as slightly detached from the endpoint and the
service container – this is because the service container is implemented in
Java, and the C# application is hooked into it via a network layer. This
shows a different type of endpoint than the ones discussed previously.
8.11.2 Hospital
The hospital has a Patient Administration System (PAS) and a Clinical
Information System (CIS) (see Section 1.1). Both of these systems are con-
nected to databases. The hospital has many messages coming in and out,
so it also has a message store database to allow storage and access to mes-
sages. The hospital system also employs logging, into an XML file. Figure
8.15 shows the hospital system.
Monitoring for the hospital system can be done from a centralised IT
department for the care network, also hooked into the HSB. There is no

Figure 8.15: Hospital system in the HSB.
need for on-site monitoring.
8.11.3 Pathologist
The job of the Pathologist is to analyse specimens from the GPs and Hospi-
tals in the pathology’s laboratory. The pathology lab has its own scientific
analysis software, which does not need to communicate on the HSB. The
only information other parties on the HSB are interested in are results of
analyses. The final results from the Pathologist’s analysis will be added to
a records database, which is accessed by an administration application.
Figure 8.16: Pathologist computer system in the HSB.
The Pathologist’s administration application is a legacy application which

has a J2EE Connector Architecture (JCA) interface, and so connects to the
HSB using a JCA adapter. JCA was designed to provide a Java solution to
the problem of connectivity between application servers and enterprise in-
formation systems [Sun08], and has become a popular means of connecting
legacy applications to Java environments [Cha04]. JCA was designed to
be implemented in an application server container, but can also be imple-
mented in an ESB service container. An application adapter which is JCA-
compliant can plug into the container, which is the approach taken in the
pathology system. Figure 8.16 shows the Pathologist’s system setup. The
“Pathology App” in the diagram refers to the administration application.
The scientific analysis software is not shown, as it does not communicate
on the bus, but feeds results into the “Records” database shown.
8.11.4 Radiologist
The Radiologist provides medical imaging services to the GPs and Hospi-
tals. The Radiologist’s HSB setup includes a file access service which con-
nects to the radiology imaging application for images such as X-rays or
MRIs1 . It also comprises a database with patient records, with a connected
records management application hooked into the HSB. Figure 8.17 shows
the Radiologist system setup.
As can be seen in Figure 8.17, the imaging application is not directly
connected to the HSB, but a HSB file access service can retrieve image
files from the database through the application and send them on the HSB.
This can be in response to queries, or the imaging technician can forward
the images along the HSB, for example to the GP, immediately after the
images have been recorded.
1 Magnetic Resonance Imaging

Figure 8.17: Radiologist computer system in the HSB.
8.11.5 Pharmacy
The Pharmacy fills prescriptions for patients of the GPs and Hospitals in
the care-network, and also provides drug information to clinicians in the
network. The Pharmacy’s computer system which is connected to the HSB
consists of simple Pharmacy applications which have access to a central
database. The Pharmacy application connects to the HSB through a Web
Services endpoint, and communicates via HTTP. The Pharmacy’s computer
system is shown in Figure 8.18.
Figure 8.18: Pharmacy computer system in the HSB.
8.11.6 Aged Care
Aged Care in this sense refers to an Aged Care Home, with residents who
need a high level of care. The Aged Care facility needs to be able to commu-

nicate with pharmacy, pathology, radiology, GPs and possibly Hospitals.
The Aged Care facility has several desktop computers with a packaged
application on them. To connect to the HSB, the packaged application re-
quires an adapter, similar to the Pathologist’s setup. Figure 8.19 shows the
Aged Care facility’s system.
Figure 8.19: Aged Care system in the HSB.
8.11.7 Community Care
The community care sector in Australia involves departments such as the
Home and Community Care (HACC) program, and other departments in-
volved in direct community care such as home nursing, or departments such
as TACT (see Chapter 4).
The HACC program is a joint Australian, state and territory govern-
ment initiative, including such services as nursing care, allied health care,
meals and other food services, home modification, and transport among
other things [Aus08]. As such, communication is required between the
national government department and the state and territory departments.
The HSB setup for HACC therefore includes a content-based router for com-
municating between the departments. HACC workers also need to commu-
nicate with GPs and the Pharmacy.
Home Nursing applications also come under Community Care. Both
the HACC and Home Nursing applications connect to the HSB using Web
Services over HTTP. This allows portable and hand-held computers in the
field to connect to the HSB easily over wireless Internet.

Figure 8.20: Community Care system using the HSB.
The final service shown in the Community Care network is a records
management service. All clients/patients in community care can be recorded
in this database and accessed via the HSB. Figure 8.20 shows the Commu-
nity Care network. The content-based router is depicted as in Section 8.6.
8.11.8 Registration Board
The registration board section of the HSB consists of state-based Medi-
cal Registration Boards and Nursing Councils, as well as the Association
of Medical Receptionists (AMR). Because there are so many registration
boards, including boards for different states, the Registration Board HSB
system has a content-based router to direct incoming messages to the right
boards, as in the HSB prototype system (Section 8.6). The other facilities in
the HSB communicate with the Registration Boards to query and update
registration information for medical practitioners. Figure 8.21 shows this
setup.
Figure 8.21: Registration Board setup using the HSB.

8.11.9 Complete Network
Figure 8.22 shows the complete HSB setup between all the facilities de-
scribed. The complete picture shows how the HSB can be used to connect
many different types of application and services in different formats.
The nature of ESB allows the HSB to be incrementally adopted by the
different entities as required, and allows process flows to be layered on top
– either within a single department or over the entire HSB. The HSB is a
loosely-coupled distributed solution, with no parts relying on other parts to
continue running. If one section goes down, other sections are not affected
due to the asynchronous and componentised nature of the HSB. When com-
munication is restored, the messages sent during the outage are delivered.
8.11.10 Process Interoperability
In an ESB, management traffic is designed to share the bus with appli-
cation traffic. This means that remote management can be implemented
simply by plugging a management console into the bus. For an ESB imple-
mented in Java, this can mean using Java Management eXtensions (JMX)
to manage and monitor the ESB.
The ease of management and monitoring in ESB, as well as the ap-
proach of layering services, leads to the ability to implement special capa-
bilities such as process flow management [Cha04]. For example, Business
Process Management (BPM) software can be used in an ESB to process
business workflows. Process flow can also be defined per individual depart-
ment, or for the larger network. The process flow capabilities of ESB can
range from simple metadata to the use of orchestration languages.
All of this means that process interoperability is easily implementable
in the HSB, thus achieving all three levels of interoperability important in
health.

Figure 8.22: Complete HSB, covering eight different entities in a Health-

care Network.

8.12 Conclusions on the HSB
ESB is a powerful technology for standards-based integration, which pro-
vides an excellent solution for communication in healthcare. The HSB so-
lution achieves all three levels of interoperability, as defined by the HL7
Interoperability Work Group – technical, semantic and process – thus pro-
viding a complete interoperability solution. Implementing the HSB could
solve the information silo problem in the healthcare industry, and the in-
cremental adoption strategy makes this a viable solution.
A small proof-of-concept HSB has been setup using Mule ESB software,
which connects all the artifacts described within this thesis. The ease of
setup in connecting these disparate systems (.NET and Java, HL7 Versions
2 and 3) shows that the solution has potential to be adapted to a larger sys-
tem. As well as the proof-of-concept system, a industry-based example has
been presented which shows how the HSB solution could be implemented
in an actual setting.
By using the messaging formats resulting from the ontology mapping
process in Chapter 5 as the canonical message format within the power-
ful ESB system integration paradigm, the problem of interoperability in
healthcare can be solved.

Chapter 9
Conclusion
This thesis has focused on the development of an interoperability solution
for health by employing design science research methods involving a num-
ber of models, methods and implementation artifacts. At the start of the
process, Health Informatics standards and formats where researched in
depth, which led to the ability for simple data exchange. Delving deeper
into the standards and applying them to a practical project including the
use of terminology allowed for information exchange on a higher level with
message semantics preserved from the sender to the receiver. The message
formats developed during the project were for a specific use-case, so follow-
ing on from there the message formats were expanded to a more general
case and the use of terminology within these formats also expanded.
To allow communication with legacy systems and health record systems,
translations between this format and a previous version, and an EHR stan-
dard were then actualised, followed by practical implementation of a ter-
minology server to allow programmatic access to the terminology and to
ensure term consistency between communicating parties.
All steps to this point had led to the building blocks for semantic in-
teroperability to be achieved, but a technical interoperability solution was
required to actually communicate – an actual “wire” to send the messages
207
208 CHAPTER 9. CONCLUSION
over, and to communicate with the terminology server. A framework which
used a tuple-space paradigm to share messages was developed to this end,
producing an interesting solution to complete interoperability but also bring-
ing to light some scalability issues. A scalable interoperability solution
based on a messaging core and incorporating the message formats, transla-
tions, terminology and health record storage is presented as the final out-
come.
Three health standards form the core of the interoperability artifacts
developed throughout this work. HL7 (both Versions 2 and 3) primarily as
a messaging standard, openEHR for persistent health record storage and
SNOMED CT as the controlled clinical terminology used within the other
standards. The first practical use of these standards is a referral applica-
tion developed as a prototype for HL7 Version 2 messaging. This prototype
application is an example of simple data exchange between homogeneous
entities with a defined message format.
An industry-based project called ePOC was the next stage in develop-
ing an interoperability framework. A PDA application to gather clinical
observations data at the point-of-care, and a central PC-based application
incorporating a patient database and graphical representations of observa-
tions data were developed and tested in a field trial by ambulatory care
workers.
One of the requirements for that project was communication between
the central system and several PDAs used by clinicians collecting obser-
vations data in the field. HL7 Version 3 was employed as the messaging
format in conjunction with SNOMED CT for this purpose. The HL7 mes-
sage formats were based on SNOMED CT constructs to ensure the accurate
representation of clinical constructs and their relationships to each other.
The implementation of this project demonstrates information exchange on
a semantic level between non-homogeneous devices.
The HL7 messages based on SNOMED CT developed in ePOC were for

209
eight specific observations required for that project. The messages were
then expanded to a more general case to represent any observations. The
use of the SNOMED CT terminology in ePOC had also been restricted to
two HL7 fields – code and method code. Other code fields were thus in-
cluded in the more general observation message format which also incorpo-
rated SNOMED CT. This culminated in a canonical message format to be
used in all future artifacts.
To allow entities using legacy HL7 Version 2 messages to communicate
with entities using the canonical message format, translation between the
two by ontology mapping between HL7 V3 and V2 datatypes and observa-
tions messages was achieved. Following on from this work, the HL7 V3
canonical message format was also mapped to and from a defined openEHR
observations structure for persistent storage of observations data in a pa-
tient’s lifelong health record.
A practical interoperability solution requires programmatic access to
terminology to facilitate consistent usage and accessibility of terms. A
SNOMED CT terminology server was configured consisting of a native XML
database of SNOMED CT concepts with a Web Service front-end for query-
ing the database over a network. As SNOMED CT is distributed in a tra-
ditional database format, a tool to convert the required subset to XML was
created and employed as a part of this process.
An interoperability framework built on Jini technology and making use
of JavaSpaces for communication brings together the SNOMED CT termi-
nology server and the HL7 V3 canonical message format, as well as the
translations between this format and HL7 V2 and openEHR in the form of
XSLT transforms. This framework is called HIF-J and demonstrates ac-
cess to terminology, communication between entities on a semantic level
and communication with systems using a legacy format. A small obser-
vations application was developed to demonstrate this framework. Unfor-
tunately, JavaSpaces were deemed not scalable enough for a full health

interoperability communication framework – though a powerful paradigm
of information sharing, it only led to one messaging channel type: publish-
subscribe.
The final artifact presented is an interoperability framework for health
based on the Enterprise Service Bus (ESB) principles of messaging, XML
message formats and translations, intelligent routing and web services,
called the Health Services Bus (HSB).
The HSB meets these four pillars of ESB in its implementation based on
Mule Open-Source ESB technology. Message Oriented Middleware incor-
porating robust, reliable transport is the core of Mule’s functionality. The
services in the HSB are exposed via Web Services, and intelligent routing
is implemented in the form of a content-based router. XML transforma-
tion is a key service on the HSB, allowing systems using differing health
standards to interact.
The HSB provides the same features as HIF-J but is scalable and of-
fers multiple messaging channel types. This provides the technical inter-
operability needed as a basis for communication, and ESB also implicitly
achieves process interoperability due to its layered approach. By using
the HL7 message model which is based on SNOMED CT as the canoni-
cal message model within this framework, semantic interoperability is also
achieved.
This health interoperability framework is the ultimate outcome of the
health standards and communication research in which all the previous
phases are brought together as a commercially-viable solution to communi-
cation in the healthcare industry.
Compared to other research in health interoperability systems, the HSB
is more advanced in that most of the literature in the area focuses on
semantic interoperability and mapping different standards to each other,
without addressing process interoperability. With regards to technical in-
teroperability, most of the literature either addresses it briefly or reports on

211
a particular developed implementation.
In Section 1.6, a survey of health interoperability research was pre-
sented. With a complete picture of the HSB, it is now possible to compare
this framework to other research in the area. The HSB is different to Bicer
et al.’s Artemis Message Exchange Framework (AMEF) [BLDK05a] in that
it is a complete integration solution, encompassing message mediation, ter-
minology services, patient records, management, monitoring, etc; whereas
AMEF concentrates solely on message mediation with some Web Services.
The main focus of their work is the ontology mapping aspect, covering se-
mantic interoperability. This work falls into the category of only briefly
touching on technical interoperability and not addressing process interop-
erability.
In Shabo and Hughes’s work regarding sharing family history data,
they focus on the HL7 models and semantic interoperability without go-
ing into detail about actual message exchange, except to mention Semantic
Web [SH05]. Again, Shabo and Hughes’s work concentrates on the message
formats to be exchanged without presenting a complete interoperability so-
lution.
Catley and Frize’s XML-based interoperability system glues together
different Web Services as an SOA [CF02, CF03]. They discuss the benefits
of XML within the medical informatics field, without expanding on specifics
of their XML representations. In this way, they have covered technical in-
teroperability and also touched on semantic interoperability without going
into depth. ESB is a better SOA than Catley and Frize’s in terms of dis-
tributed management and system-wide process interoperability, as detailed
in Sections 8.1 and 8.10.
The ontology mapping work carried out in [BLDK05a], [SH05] and [CF02]
is similar to the work in Chapter 5 (Ontology Mapping). That is, it is con-
centrating on semantically-interoperable messages and canonical message
formats, usually by mapping different standards to each other and always

using XML. The HSB takes this work on semantic interoperability and
places it into context within a larger interoperability solution, also address-
ing technical and process interoperability.
Shakir et al.’s implementation of ESB with HL7 V3 messages [SCD+ 07]
is similar to the HSB and was published around the time the HSB was de-
veloped. Their paper is a report on their particular implementation, going
into detail such as describing the specific software for process modelling
and data storage. As opposed to the previous papers, Shakir et al. have
addressed technical and process interoperability in great detail, but have
only touched on semantic interoperability. They are using HL7 V3 and are
currently constructing an Operational Data Store that will take inbound
data and convert it to HL7.
The HSB is different to the other work in the field in that it addresses all
three levels of interoperability as defined by the HL7 EHR Interoperabil-
ity Work Group in their definitive white paper “Coming to Terms” [HL707]
– technical, semantic and process. Due to the loosely-coupled, highly dis-
tributed nature of ESB, the HSB can be implemented incrementally and
allows for legacy systems to easily join the communication infrastructure
when they are ready. This is an important advantage in the healthcare
industry where legacy systems abound and time is precious.
Roa-Valverde and Aldana-Montes, in a paper published after develop-
ment work for this thesis was completed, propose the use of an ESB com-
bined with Semantic Web technology with the aim of building an “intelli-
gent” middleware, arguing that it is possible to use Semantic Web Services
in conjunction with an ESB to overcome the problem of enterprise integra-
tion [RVAM08]. This is what the Health Service Bus achieves, particularly
in the healthcare domain and addressing specific issues with health infor-
mation by using Health Informatics standards.

Technical
Acknowledgements
ePOC
The ePOC Project is an Australian Research Council (ARC) Linkage Grant.
In addition to the ARC the authors acknowledge the support of Pen Com-
puter Systems, TACT and the South Eastern Sydney & Illawarra Area
Health Service (SESIAHS).
SNOMED CT
This material includes SNOMED Clinical Terms (SNOMED CT) which is
used by permission of the International Health Terminology Standards De-
velopment Organisation (IHTSDO). All rights reserved. SNOMED CT was
originally created by The College of American Pathologists. “SNOMED”
and “SNOMED CT” are registered trademarks of the IHTSDO.
ESB-style Diagrams
The Sonic ESB Icon and Diagram Library for Microsoft Visio was used for
drawing Figures 8.2, 8.3, 8.4, 8.14, 8.15, 8.16, 8.17, 8.18, 8.19, 8.20, 8.21,
and 8.22. Copyright c 1993-2006, Progress Software Corporation.
213
Tooling
Health Informatics tools used during this work include:
• HL7 RMIM Designer plugin for Microsoft Visio
- available from http://newgforge.hl7.nscee.edu/projects/visio-rmim-desi/
• RoseTree II MIM, R-MIM and HMD Designer by Beeler Consulting
- available from http://newgforge.hl7.nscee.edu/projects/rose-tree/
• CIC CliniClue Browser for SNOMED CT [CiC08]
• Ocean Informatics openEHR ADL Workbench
- available from http://www.oceaninformatics.com/Solutions/ocean-products/
Knowledge-Management/Ocean-Archetype-WorkBench.html
• Ocean Informatics Archetype Editor
- available from http://www.oceaninformatics.com/Solutions/ocean-products/
Clinical-Modelling/ocean-archetype-editor.html

Appendix A
The HL7 Reference
Information Model
215
216 APPENDIX A. THE HL7 REFERENCE INFORMATION MODEL
Figure A.1: The HL7 RIM Version 2.26 – Foundation Classes.

Appendix B
Complete OpenEHR
Height Archetype
archetype (adl version=1.4)

openEHR-EHR-OBSERVATION.height.v1
concept
[at0000] −− Height
language
original language = <[ISO 639-1::en]>
translations = <
[“de”] = <
language = <[ISO 639-1::de]>
author = <
[“name”] = <“Jasmin Buck, Sebastian Garde”>
[“organisation”] = <“University of Heidelberg, Central Queensland University”>
>
>
>
description
original author = <
[“name”] = <“Sam Heard”>
[“organisation”] = <“Ocean Informatics”>
[“email”] = <“sam.heard@oceaninformatics.com”>
[“date”] = <“9/03/2006”>
>
details = <
[“de”] = <
language = <[ISO 639-1::de]>
purpose = <“Zur Dokumentation der Körpergröße in einer gestreckten Position,
von Scheitel bis Sohle”>
use = <“”>
keywords = <“Größe”, “Länge”>
misuse = <“Nicht zur Dokumentation anderer Größen und Längen
(siehe OBSERVATION.dimensions.v1)”>
copyright = <“copyright (c) 2009 openEHR Foundation” >
>
217
218 APPENDIX B. COMPLETE OPENEHR HEIGHT ARCHETYPE
[“en”] = <
language = <[ISO 639-1::en]>
purpose = <“Recording the total length of the body from crown of head to sole of foot.”>
use = <“For recording the height or length of a person at any point in time, and in addition
tracking growth and loss of height over time.”>
keywords = <“shrinkage”, “increase”, “decrease”, “height loss”, “height”, “length”, “growth”>
misuse = <“Not to be used for recording length of an object - see OBSERVATION.dimensions.
Not to be used for recording length at birth - see OBSERVATION.height-birth.
Not to be used for recording estimated or adjusted length or height, for example,
for individuals with bialteral amputation.
Not to be used for recording growth velocity.”>
copyright = <“copyright (c) 2009 openEHR Foundation”>
>
>
lifecycle state = <“AuthorDraft”>
other contributors = <“Jeroen Meintjen, Medisch Centrum Alkmaar, Netherlands”, “Sebastian
Garde, Ocean Informatics, Germany”, “Ian McNicoll, Ocean Informatics, Scotland”, “Heather
Leslie, Ocean Informatics, Australia”, “Omer Hotomaroglu, Turkey”, “Paul Donaldson, Queensland
Health, Australia”, “Heather Grain, Australia”, “Andrew James, University of Toronto, Canada”,
“Anne Harbison, Australia”, “Thilo Schuler, Germany”, “Anneke Goossen, Results 4 Care,
Netherlands”>
other details = <
[“references”] =
<“http://www.ich.ucl.ac.uk/clinical information/clinical guidelines/cpg guideline 00060”>
>
definition
OBSERVATION[at0000] matches { −− Height
data matches {
HISTORY[at0001] matches { −− history
events cardinality matches {1..*; unordered} matches {
EVENT[at0002] occurrences matches {1..*} matches { −− Any event
data matches {
ITEM TREE[at0003] matches { −− Simple
items cardinality matches {1; unordered} matches {
ELEMENT[at0004] matches { −− Height
name matches {
[local::
at0005, −− Height
at0006] −− Length
}
}
}
value matches {
C DV QUANTITY <
property = <[openehr::122]>
list = <
[“1”] = <
units = <“cm”>
magnitude = < |0.0..1000.0| >
>
[“2”] = <
units = <“in”>
magnitude = < |0.0..250.0| >
>
>
>
}
}
}
}

219
}
state matches {
ITEM TREE[at0013] matches { −− Tree
items cardinality matches {0..*; unordered} matches {
ELEMENT[at0014] occurrences matches 0..1 matches { −− Position
value matches {
[local::
at0015, −− Lying
at0016; −− Standing
at0016] −− assumed value
}
}
}
}
}
}
}
}
INTERVAL EVENT[at0009] occurrences matches {0..1} matches { −− Growth
math function matches {
defining code matches {[openehr::147]}
}
}
data matches {
use node ITEM TREE /data[at0001]/events[at0002]/data[at0003] −−
/data[history]/events[Any event]/data[Simple]
}
state matches {
use node ITEM TREE /data[at0001]/events[at0002]/state[at0013] −−
/data[history]/events[Any event]/state[Tree]
}
}
INTERVAL EVENT[at0012] occurrences matches {0..1} matches { −− Loss of height
math function matches {
defining code matches {[openehr::147]}
}
}
data matches {
use node ITEM TREE /data[at0001]/events[at0002]/data[at0003] −−
/data[history]/events[Any event]/data[Simple]
}
state matches {
use node ITEM TREE /data[at0001]/events[at0002]/state[at0013] −−
/data[history]/events[Any event]/state[Tree]
}
}
}
}
}
protocol matches {
ITEM TREE[at0007] matches { −− List
items cardinality matches {0..*; ordered} matches {
allow archetype CLUSTER[at0011] occurrences matches {0..1} matches { −− Device
include
archetype id/value matches {/openEHR-EHR-CLUSTER\.device\.v1/}
}
ELEMENT[at0017] occurrences matches 0..1 matches { −− Comment
value matches {

DV TEXT matches {*}

}
}
}
}
}
}
ontology
[“de”] = <
items = <
[“at0000”] = <
text = <“Körpergröße”>
description = <“Körpergröße in einer gestreckten Position, von Scheitel bis Sohle”>
>
[“at0001”] = <
text = <“History”>
description = <“@ internal @”>
>
[“at0002”] = <
description = <“Jede zu einem Zeitpunkt gemessene Körpergröße”>
>
[“at0003”] = <
text = <“Simple”>
>
[“at0004”] = <
text = <“Länge”>
description = <“Körperlänge”>
>
[“at0005”] = <
text = <“Größe”>
description = <“Körpergröße in stehender Position”>
>
[“at0006”] = <
text = <“Lnge”>
description = <“Länge der Körperrückseite”>
>
[“at0007”] = <
text = <“List”>
>
[“at0009”] = <
text = <“Wachstum”>
description = <“Die Änderung in der Größe”>
>
[“at0011”] = <
text = <“*CLUSTER(en)”>
description = <“**(en)”>
>
[“at0012”] = <
text = <“*Any event(en)”>
>
[“at0013”] = <
text = <“*Tree(en)”>
description = <“*@ internal @(en)”>
>
[“at0014”] = <
text = <“*New element(en)”>

221
>
[“at0015”] = <
text = <“*Supine(en)”>
description = <“*Infants and children should be measured lying face upward -
can be up to two years of age.(en)”>
>
[“at0016”] = <
text = <“*Standing(en)”>
description = <“*Height is measured standing erect, feet flat on the ground and
against a backboard(en)”>
>
[“at0017”] = <
text = <“*New element(en)”>
>
>
>
[“en”] = <
items = <
[“at0000”] = <
description = <“Height (or Length) of the body is measured from crown of head to sole of foot,
and based on either standing height or recumbent length. In general, length measurements are
recommended for children under 2 years of age and individuals who cannotstand;
height measurements for all others. Ideally, height is measured standing on both feet with weight
distributed evenly, heels together and both buttocks and heels in contact with a vertical back board;
length is measured in a fully extended, supine position with the pelvis flat, legs extended and feet flexed. ”>
>
[“at0001”] = <
text = <“history”>
>
[“at0002”] = <
description = <“Any timed measurement of height”>
>
[“at0003”] = <
text = <“Simple”>
>
[“at0004”] = <
>
[“at0005”] = <
>
[“at0006”] = <
>
[“at0007”] = <
text = <“List”>
>
[“at0009”] = <
text = <“Growth”>
description = <“Increase in height over time”>
>
[“at0011”] = <
text = <“Device”>

description = <“Description of the device used to measure height”>

>
[“at0012”] = <
text = <“Loss of height”>
description = <“Decrease in height over time”>
>
[“at0013”] = <
text = <“Tree”>
>
[“at0014”] = <
text = <“Position”>
description = <“Position of individual when measured.”>
>
[“at0015”] = <
text = <“Lying”>
description = <“Length is measured in a fully extended, supine position with the pelvis flat,
legs extended and feet flexed.”>
>
[“at0016”] = <
text = <“Standing”>
description = <“Height is measured standing on both feet with weight distributed evenly,
heels together and both buttocks and heels in contact with a vertical back board.”>
>
[“at0017”] = <
text = <“Comment”>
description = <“Comment about how the measurment was made, for example,
any difficulties or issues.”>
>
>
>
>

Appendix C
SNOMED CT Subset Used
in ePOC
223
224 APPENDIX C. SNOMED CT SUBSET USED IN EPOC
Table C.1: Full SNOMED CT Subset Used in ePOC.
CONCEPT DESCRIPTION DESCRIP- ROOT Is A

ID TION ID
363787002 observable entity 486911019 0 138875005

386053000 evaluation proce- 1776032015 1 128927009
dure
3770000 ward urine dip 7365012 1 53853004
stick testing
7771000 left 13853016 3 182353008
7918005 ward glucometer 14106013 1 252144003
test
8499008 pulse 15015013 0 70337006
24028007 right 40330015 3 182353008
27113001 body weight 45352010 0 363808001
27327002 hydrogen ion con- 45688013 0 396277003
centration
46680005 vital signs 77794018 0 363787002
46973005 blood pressure 78280016 1 61746007
taking
50496004 cubital fossa 84121011 2 91825004
50794000 specific gravity 84650015 0 396277003
54718008 peripheral pulse 90939012 0 8499008
56342008 temperature tak- 93694019 1 61746007
ing
61746007 taking patient vi- 102599012 1 5880005
tal signs
65452004 radial pulse 108743018 0 54718008
65653002 pulse taking 109071011 1 61746007
66480008 entire left forearm 507772014 2 362741001
72027000 radial pulse tak- 119686012 1 65653002
ing
75367002 blood pressure 125176019 0 46680005
78564009 pulse rate 130365016 0 46680005
86290005 respiratory rate 143107019 0 46680005
88385000 nail pulse 146542016 0 8499008
89003005 oral temperature 147575017 1 56342008
taking
103228002 haemoglobin satu- 260893019 0 86084001
ration with oxy-
gen

225
Table C.2: Full SNOMED CT Subset Used in ePOC. (cont.)

ID TION ID
182353008 side 281904019 3 272424004

233520008 peripheral venous 349897016 1 392231009
cannula insertion
249299009 contents of urine 371986013 0 364687002
252465000 pulse oximetry 376038015 1 250554003
271625008 rate of sponta- 406480018 0 86290005
neous respiration
271649006 systolic blood pre- 406507015 0 75367002
ssure
271650006 diastolic blood 406508013 0 75367002
pressure
276885007 core body temper- 413233013 0 386725007
ature
302539009 entire hand 444279019 2 302539009
307818003 weight monitoring 451201014 1 182777000
361289009 entire wrist region 478136010 2 8205005
362741001 entire forearm 480485019 2 14975008
365812005 blood glucose level 489271015 4 365811003
368224007 entire right fore- 507768010 2 362741001
arm
368235002 entire right wrist 507817015 2 361289009
368236001 entire left wrist 507820011 2 361289009
368455003 entire right hand 508856012 2 302539009
368456002 entire left hand 508859017 2 302539009
371911009 measurement of 1210501012 1 46973005
blood pressure
using cuff method
386725007 body temperature 1480858013 0 46680005
396277003 fluid observable 1776250015 0 414237002
400974009 standing systolic 1780182014 0 271649006
blood pressure
400975005 standing diastolic 1780183016 0 271650006
blood pressure
407554009 sitting systolic 2159155011 0 271649006
blood pressure
407555005 sitting diastolic 2159156012 0 271650006
blood pressure

226 APPENDIX C. SNOMED CT SUBSET USED IN EPOC
Table C.3: Full SNOMED CT Subset Used in ePOC. (cont.)

ID TION ID
407556006 lying systolic 2159157015 0 271649006

blood pressure
407557002 lying diastolic 2159158013 0 271650006
blood pressure
408867002 taking respiratory 2470712011 1 61746007
rate
415945006 oral temperature 2534418016 0 276885007
415974002 tympanic temper- 2534421019 0 276885007
ature
116154003 patient 186889013 5 303118004
248153007 male 370461016 4 365873007
248152002 female 370460015 4 365873007
394744001 gender unspeci- 1488459013 4 365873007
fied
394743007 gender unknown 1488458017 4 365873007
133932002 caregiver 213673014 5 303118004
184142008 patients next of 284447011 0 302147001
kin
365873007 gender finding 489361015 4 365860008

Appendix D
Flowchart of User
Interface screens in the
ePOC PDA application
227
APPENDIX D. FLOWCHART OF USER INTERFACE SCREENS IN
228 THE EPOC PDA APPLICATION
Figure D.1: Complete flowchart of user interface screens in ePOC PDA ap-
plication.

Appendix E
Mapping HL7 V2 and V3
229
230 APPENDIX E. MAPPING HL7 V2 AND V3
Table E.1: Mapping of HL7 Version 2 fields to HL7 Version 3 for observa-
tions messages (* - mapping through code table required).
V2 field description mapping to V3 (class::attribute)

Message Header Segment - MSH
MSH.1 Field Separator n/a
MSH.2 Encoding Characters n/a
MSH.4 Sending Facility (message header - e.g. SOAP)
MSH.6 Receiving Facility (message header)
MSH.7 Date/Time of Message (message header)
MSH.9 Message Type PatientObservations::classCode *
PatientObservations::moodCode *
MSH.10 Message Control ID PatientObservations::id
MSH.11 Processing ID n/a
MSH.12 Version ID n/a
Patient Identification Segment - PID
PID.3 Patient Identifier List patient::id
PID.5 Patient Name patientPerson::name
PID.7 Date/Time of Birth patientPerson::birthTime
PID.8 Administrative Sex patientPerson::aGenderCode *
PID.10 Race patientPerson::raceCode
PID.11 Patient Address patient::addr
PID.13 Phone Number - home patient::telecom
PID.14 Phone Number - business patient::telecom
Patient Additional Demographic Segment - PD1
PD1.6 Handicap patientPerson::disabilityCode *
Patient Visit Segment - PV1
PV1.2 Patient Class patient::code *
PV1.7 Attending Doctor careGiver::id
careGiverPerson::name
PV1.51 Visit Indicator n/a
Observation Request Segment - OBR
OBR.2 Placer Order Number PatientObservations::id
OBR.3 Filler Order Number PatientObservations::id
OBR.4 Universal Service Identifier PatientObservations::code
OBR.7 Observation Date/Time PatientObservations::effectiveTime
OBR.13 Relevant Clinical Information PatientObservations::text
OBR.44 Procedure Code PatientObservations::methodCode
Role Segment - ROL
ROL.1 Role Instance Id n/a
ROL.2 Action Code n/a
ROL.3 Role careGiver::code
ROL.4 Role Person careGiver::id
careGiverPerson::name
ROL.11 Office/Home Address careGiver::addr
ROL.12 Phone careGiver::telecom
Observation/Result Segment - OBX
OBX.2 Value Type n/a
OBX.3 Observation Identifier observationEvent::code
OBX.4 Observation Sub-ID n/a
OBX.5 Observation Value observationEvent::value
OBX.6 Units observationEvent::value
OBX.11 Observation Result Status n/a
OBX.14 Date/Time of the Observation observationEvent::effectiveTime
OBX.17 Observation Method observationEvent::methodCode
OBX.20 Observation Site observationEvent::targetSiteCode
Notes and Comments Segment - NTE
NTE.3 Comment observationEvent::text

231
Table E.2: Mapping of HL7 Version 3 attributes to HL7 Version 2 for obser-
vations messages (* - mapping through code table required).
HL7 V3 HL7 V2
class attribute segment field::attribute
PatientObservations classCode MSH MSH-9 message type *
PatientObservations moodCode MSH MSH-9 message type *
PatientObservations id MSH MSH-10 message control id
PatientObservations code OBR OBR-4 universal service id
PatientObservations text OBR OBR-13 relevant clinical info
PatientObservations effectiveTime OBR OBR-7 observation date/time
PatientObservations methodCode OBR OBR-44 procedure code
subject typecode n/a -
patient classCode n/a -
patient id PID PID-3 patient identifier list
patient code PV1 PV1-2 patient class *
patient addr PID PID-11 patient address
patient telecom PID PID-13 phone - home
PID-14 phone - business
patientPerson classCode n/a -
patientPerson determinerCode n/a -
patientPerson name PID PID-5 patient name
patientPerson aGenderCode PID PID-8 admin sex *
patientPerson birthTime PID PID-7 date/time of birth
patientPerson disabilityCode PD1 PD1-6 handicap *
patientPerson raceCode PID PID-10 race
performer typecode n/a -
careGiver classCode n/a -
careGiver id PV1 & ROL PV1-7 attending doctor
ROL-4 role person
careGiver code ROL ROL-3 role
careGiver addr ROL ROL-11 office/home address
careGiver telecom ROL ROL-12 phone
class attribute segment field::attribute
careGiverPerson classCode n/a -
careGiverPerson determinerCode n/a -
careGiverPerson name PV1 & ROL PV1-7 attending doctor
ROL-4 role person
component typecode n/a -
component contextContCode n/a -
observationEvent classCode n/a -
observationEvent moodCode n/a -
observationEvent code OBX OBX-3 observation id
observationEvent text NTE NTE-3 comment
observationEvent effectiveTime OBX OBX-14 date/time of obs
observationEvent value OBX OBX-5 observation value
OBX-6 units
observationEvent interpretCode OBX OBX-8 abnormal flags *
observationEvent methodCode OBX OBX-17 obs method
observationEvent targetSiteCode OBX OBX-20 observation site

232 APPENDIX E. MAPPING HL7 V2 AND V3

Appendix F
Mapping HL7 V3 and
openEHR
233
234 APPENDIX F. MAPPING HL7 V3 AND OPENEHR
Table F.1: Mapping between HL7 Version 3 Clinical Observations RMIM

and openEHR Clinical Findings SECTION.
HL7 V3 openEHR
observationEvent (code::278844005) SECTION (name::Findings)
code$displayName name
n/a hyperlink
n/a archetype details - findings
n/a items
n/a OBSERVATION
subject subject
patient ext ref
id$id id
id$root namespace
n/a type - patient
performer provider
CareGiver ext ref
id$id id
id$root namespace
n/a type - caregiver
n/a data
n/a HISTORY
n/a events
n/a EVENT
component/observationEvent/effecTime time
n/a data
component/observationEvent ELEMENT
value value
n/a protocol
n/a ITEM LIST
methodCode ELEMENT
targetSiteCode ELEMENT (location)
interpretationCode n/a

Bibliography
[Agu05] Antonio Aguilar. Semantic interoperability in the context
of e-Health. In CDH Seminar, 2005.
[AHM05] Australian Healthcare Messaging Laboratory (AHML).
http://www.ahml.com.au/, 2005. Last Accessed: June,
2008.
[ANS08] ANSI/ADA Specification No. 1000-2001: Standard Clini-
cal Architecture for the Structure and Content of an Elec-
tronic Health Record. American National Standards Insti-
tute (ANSI), 2008.
[AOS+ 99] Ken Arnold, Bryan O’Sullivan, Robert W. Scheifler, Jim
Waldo, and Ann Wollrath. The Jini Specification. The Jini
Technology Series. Addison-Wesley, 1999.
[Aus08] Australian Government – Department of Health and
Ageing. Home and community care. http://www.health.
gov.au/internet/main/Publishing.nsf/Content/hacc-
index.html, July 2008. Last Accessed: December 2008.
[Bea02] Thomas Beale. Archetypes: Constraint-based domain
models for future-proof information systems. In Workshop
on Behavioural Semantics (OOPSLA’02), 2002.
235
236 BIBLIOGRAPHY
[Ben02a] Tim Benson. Why general practitioners use computers and
hospital doctors do not – part 1: incentives. British Medi-
cal Journal, 325:1086–1089, November 2002.
[Ben02b] Tim Benson. Why general practitioners use computers and
hospital doctors do not – part 2: scalability. British Medi-
cal Journal, 325:1090–1093, November 2002.
[BFS06] Nils Barnickel, Matthias Fluegge, and Kay-Uwe Schmidt.
Interoperability in eGovernment through cross-ontology
semantic web service composition. In Proceeding of the
Workshop on Semantic Web for eGovernment 2006, 3rd Eu-
ropean Semantic Web Conference, June 2006.
[BH04] T. Beale and S. Heard, editors. The Archetype Definition
Language (ADL). The openEHR Foundation, 2004.
[BH06] T. Beale and S. Heard, editors. The Archetype Definition
Language Version 2 (ADL2). The openEHR Foundation,
2006.
[BHKL06] Thomas Beale, Sam Heard, D Kalra, and D Lloyd, editors.
OpenEHR Architecture Overview. The OpenEHR Founda-
tion, 2006.
[BKDL05] Veli Bicer, Ozgur Kilic, Asuman Dogac, and Gokce B.
Laleci. Archetype-based semantic interoperability of web
service messages in the health care domain. International
Journal on Semantic Web and Information Systems, 1(4):
1–23, Oct-Dec 2005.
[BLDK05a] Veli Bicer, Gokce B. Laceli, Asuman Dogac, and Yildiray
Kabak. Artemis Message Exchange Framework: Seman-
tic interoperability of exchanged messages in the health-

BIBLIOGRAPHY 237
care domain. In Proceedings of the ACM SIGMOD Inter-
national Conference on Management of Data, 2005.
[BLDK05b] Veli Bicer, Gokce Banu Laleci, Asuman Dogac, and
Yildiray Kabak. Providing semantic interoperability in the
healthcare domain through ontology mapping. In P. Cun-
ningham and M. Cunningham, editors, Innovation and
The Knowledge Economy: Issues, Applications, Case Stud-
ies. IOS Press, 2005.
[Buc93] R. Buckland. The language of health. British Medical
Journal, 306:287–288, 1993.
[CAP09] SNOMED historical perspectives. In http://www.cap.org/
apps/cap.portal. College of American Pathologists, 2009.
Last Accessed: January, 2009.
[CF02] Christina Catley and Monique Frize. Design of a health
care architecture for medical data interoperability and
application integration. In Proceedings of the Joint
BMES/EMBS Conference, pages 1952–1953, 2002.
[CF03] Christina Catley and Monique Frize. A prototype XML-
based implementation of an integrated ‘intelligent’ neona-
tal intensive care unit. In 4th International IEEE EMBS
Special Topic Conference on Information Technology Appli-
cations in Biomedicine, pages 322–325, 2003.
[CG01] Nicholas Carriero and David Gelernter. A computational
model of everything. Communications of the ACM, 44(11):
77–81, November 2001.
[Cha04] D.A. Chappell. Enterprise Service Bus. O’Reilly, 2004.

238 BIBLIOGRAPHY
[CiC08] CliniClue. In http://www.cliniclue.com/. The Clinical In-
formation Consultancy Ltd, 2008. Last Accessed: October,
2008.
[CiT04] HIEI: Healthcare information exchange and interoper-
ability (summary of report). In http://www.citl.org/
research/HIEI.htm. Center for Information Technology
Leadership, 2004. Last Accessed: May, 2008.
[CiT09] CITL: About us. In http://www.citl.org/ about/index.asp.
Center for Information Technology Leadership, 2009. Last
Accessed: January, 2009.
[DIC08] DICOM. DICOM homepage. http://medical.nema.org/,
2008. Last Accessed: May, 2008.
[DMC+ 04] R.H. Dolin, J.E. Mattison, S. Cohn, K.E. Campbell,
A.M. Wiesenthal, B. Hochhalter, D. LaBerge, R. Bar-
soum, J. Shalaby, A. Abilla, R.J. Clements, C.M. Cor-
reia, D. Esteva, J.M. Fedack, B.J Goldberg, S. Gopalarao,
E. Hafeza, P. Hendler, E. Hernandez, R. Kamangar, R.A.
Khan, G. Kurtovich, G. Lazzareschi, M.H. Lee, T. Lee,
D. Levy, J.Y. Lukoff, C. Lundberg, M.P. Madden, T.L
Ngo, B.T. Nguyen, N.P. Patel, J. Resnick, D.E. Ross, K.M.
Schwarz, C.C. Selhorst, A. Snyder, M.I. Umarji, M. Vilner,
R. ZerChen R, and C. Zingo. Kaiser-permanente’s conver-
gent medical terminology. In M. Fieschi et al, editor, Med-
Info 2004. IOS Press, 2004.
[EBS07] Peter Eklund, Lois Burgess, and Jason Sargent. Project
management and planning issues confronting collabora-
tive research projects: A case study in ehealth. In 2nd
European Conference on eHealth (ECEH07), LNI, 2007.

BIBLIOGRAPHY 239
[Ecl08] Eclipse Foundation. Open healthcare framework (OHF)
project. http://www.eclipse.org/ohf/, 2008. Last Ac-
cessed: September, 2008.
[EIR06] R. Engelbrecht, J. Ingenerf, and J. Reiner. Relevance of
terminological standards and services in telemedicine. In
K. Zielinski, M. Duplaga, and D. Ingram, editors, Informa-
tion Technology Solutions for Healthcare. Springer, 2006.
[ES04a] M. Ehrig and S. Staab. QOM - quick ontology mapping.
In S.A. McIlraith, editor, ISWC 2004, LNCS 3298, pages
683–697, 2004.
[ES04b] Marc Ehrig and York Sure. Ontology mapping - an inte-
grated approach. In The Semantic Web: Research and Ap-
plications, LNCS 3053, pages 76–91. Springer, 2004.
[eXi08] eXist. Open source native xml database. http://exist
.sourceforge.net/, 2008. Last Accessed: October, 2008.
[Fir08] First DataBank. National drug data file (NDDF)
plus. http://www.firstdatabank.com/products/nddf/,
2008. Last Accessed: December, 2008.
[Fry08] Gilles Frydman. Information silos are everywhere. but so
is the internet! e-patients.net, November 2008.
[Gil05] Peter Gillogley. CEN 13606-1 reference model.
http://www.gillogley.com/ehr cen 13606 reference model.
shtml, 2005. Last Accessed: September, 2008.
[Goo08] Google Inc. About google health. http://www.google.com/
intl/en/health/about/index.html, 2008. Last Accessed:
September, 2008.

240 BIBLIOGRAPHY
[Gru93] Tom R. Gruber. Towards principles for the design of on-
tologies used for knowledge sharing. In N. Guarino and
R. Poli, editors, Formal Ontology in Conceptual Analysis
and Knowledge Representation. Kluwer Academic Publish-
ers, 1993.
[Hal02] Steven L Halter. JavaSpaces Example by Example. Pren-
tice Hall PTR, 2002.
[HAP07] HAPI. HL7 API. http://hl7api.sourceforge.net/, 2007.
Last Accessed: September, 2008.
[HBCH98] S.M. Huff, W.D. Bidgood, J.J. Cimino, and W.E. Hammond.
A proposal for incorporating health level seven (HL7) vo-
cabulary in the UMLS metathesarus. Journal of American
Medical Informatics Association, AMIA Annual Fall Sym-
posium Supplement:800–804, 1998.
[Hea06] Sam Heard. Height: Observation. http://www.openehr
.org/svn/knowledge/archetypes/dev/html/en/
openEHR-EHR-OBSERVATION.height.v1.html, 2006.
[Hin05] Andrew Hinchley. Understanding Version 3. Alexander
Monch Publishing, 2005.
[HL707] HL7 EHR Interoperability Work Group. Coming
to terms: Scoping interoperability for healthcare.
http://www.hln.com/assets/pdf/Coming-to-Terms-
February-2007.pdf, 2007. Last Accessed: May, 2008.
[HL708] HL7. Health level 7: About HL7. http://www.hl7.org/,
2008. Last Accessed: January, 2008.

BIBLIOGRAPHY 241
[HMPR04] Alan R. Hevner, Salvatore T. March, Jinsoo Park, and
Sudha Ram. Design science in information systems re-
search. MIS Quarterly, 28:1:75–105, 2004.
[HSV06] Gergely Héja, Gyorgy Surján, and Péter Varga. Ontolog-
ical analysis of SNOMED CT. In Proceedings of SMCS
2006 – Semantic Mining Conference on SNOMED CT,
2006.
[HW04] Gregor Hohpe and Bobby Woolf. Enterprise Integration
Patterns: Designing, Building and Deploying Messaging
Systems. Addison-Wesley, 2004.
[IEE05] IEEE-USA. IEEE-USA position on interoperability for
the national health information network. http://www.ieee
usa.org/policy/positions/NHINinteroperability.html,
2005. Last Accessed: May, 2008.
[IHT08] IHTSDO. History: Snomed. http://www.ihtsdo.org/
about-us/history/snomed/, 2008. Last Accessed: Febru-
ary, 2008.
[ISO04] ISO. ISO/TS 18308: Health informatics – requirements
for an electronic health record architecture. International
Organisation for Standardisation, 2004.
[Jin08] Jini.org. The community resource for jini technology.
http://jini.org/, 2008. Last Accessed: February, 2008.
[KBD05] Ozgur Kilic, Veli Bicer, and Asuman Dogac. Mapping ar-
chetypes to OWL. In Technical Report TR-2005-3. SRDC,
2005.
[KWS+ 96] Joseph L. Kannry, Lawrence Wright, Mark Shifman, Scot
Silverstein, and Perry L. Miller. Portability issues for

242 BIBLIOGRAPHY
a structured clinical vocabulary: Mapping from Yale to
the Columbia Medical Entities Dictionary. Journal of the
American Medical Informatics Association, 3:66–78, 1996.
[LBG08] Yan Liu, Muhammad Ali Babar, and Ian Gorton. Mid-
dleware architecture evaluation for dependable self-
managing systems. In S. Becker, F. Plasil, and R. Reussner,
editors, QoSA 2008, LNCS 5281, pages 189–204, 2008.
[Mar06] D. Markwell. Representing clinical findings with HL7v3
and SNOMED CT. White Paper for discussion by SNO-
MED International Standards Board and Concept Model
Working Group, and HL7 Modeling and Methodology TC,
Vocabulary TC and TermInfo Project, pages 1–18, 2006.
[MdOAdSJ+ 07] Antonio Magni, Robson de Oliveira Albuquerque,
Rafael Timóteo de Sousa Jr, Mark G. Hans, and Franco G.
Magni. Solving incompatibilities between electronic
records for orthodontic patients. American Journal of Or-
thodontics and Dentofacial Orthopedics, 132(1):116–121,
July 2007.
[Mic08] Microsoft Corporation. Learn about healthvault. http://
www.healthvault.com/personal/websites-overview.html,
2008. Last Accessed: September, 2008.
[Mor08] Mort Bay Consulting. Jetty webserver. http://jetty. mort-
bay.org/jetty/, September 2008. Last Accessed: October,
2008.
[MS95] Salvatore T. March and Gerald F. Smith. Design and nat-
ural science research on information technology. Decision
Support Systems, 15:251–266, 1995.

BIBLIOGRAPHY 243
[Mul08a] MuleSource Inc. Mule enterprise service bus (ESB).
http://mulesource.com/products/mule.php, 2008. Last
Accessed: November, 2008.
[Mul08b] MuleSource Inc. Mule FAQ. http://mule.mulesource
.org/display/MULE/FAQ, 2008. Last Edited: April, 2008.
[Mul08c] MuleSource Inc. Mule performance test results. White Pa-
per, July 2008.
[Mul09] MuleSource Inc. Mule 2.x user guide. http://www.mule
source.org/display/MULE2USER/ Home, 2009. Last
Edited: February, 2009.
[NSW01] NSW Health. Information Management and Technology,
Strategic Plan. Information Management Division, De-
cember 2001.
[NSW05] NSW Health. What is CHIME? NSW Health, 2005.
[Ont08] Ontology. Wordnet 3.0, 2008.
[Ope08a] OpenEHR Foundation. OpenEHR. http://www.openehr
.org/, 2008. Last Accessed: May, 2008.
[Ope08b] OpenGALEN Foundation. OpenGALEN mission state-
ment. http://www.opengalen.org/index.html, 2008. Last
Accessed: May, 2008.
[Pat06] Jon Patrick. Metonymic and holonymic roles and emer-
gent properties in the SNOMED CT ontology. In Mehmet
Orgun and Thomas Meyer, editors, Advances in Ontologies
2006, volume 72 of CRPIT. Australian Computer Society,
2006.

244 BIBLIOGRAPHY
[Pen08] Pen Computer Systems, Pty Ltd. Pen computer systems
homepage. http://pencs.com.au/default.asp, 2008. Last
Accessed: December, 2008.
[Per08] Asankha Perera. Wso2 enterprise service bus (ESB)
performance testing – round 3. http://wso2.org/library
/3740, June 2008. Last Accessed: September, 2008.
[RB86] J.D. Read and T.J.R. Benson. Comprehensive coding.
British Journal of Healthcare Computing, 3:22–25, 1986.
[RB01] E. Rahm and P.A. Bernstein. A survey of approaches to
automatic schema matching. The VLDB Journal, 10:334–
350, 2001.
[RE08] Amanda Ryan and Peter Eklund. A framework for seman-
tic interoperability in healthcare: A service oriented archi-
tecture based on health informatics standards. In Proceed-
ings of MIE 2008, 2008.
[REE07] Amanda Ryan, Peter Eklund, and Brett Esler. Toward the
interoperability of HL7 v3 and SNOMED CT: a case study
modeling mobile clinical treatment. In MedInfo 2007. IOS
Press, 2007.
[RJ06] S.R. Ray and A.T. Jones. Manufacturing interoperability.
Journal of Intelligent Manufacturing, 17, 2006.
[RMCR01] Angelo Rossi-Mori, Fabrizio Consorti, and Fabrizio L.
Ricci. Sharing clinical information. principles and task-
oriented solutions. In Proceedings of “EuroRec ’01”, the
4th European Working Conference on Electronic Health
Records, 2001.

BIBLIOGRAPHY 245
[Roy02] Roy Schulte for Gartner. Predicts 2003: Enterprise ser-
vice buses emerge. Research Paper, DF-18-7304, December
2002.
[RPH08] Angela Ryan, Jon Patrick, and Robert Herkes. Introduc-
tion of enhancement technologies into the intensive care
service, royal prince alfred hospital, sydney. Health Infor-
mation Management Journal, 37(1):40–45, 2008.
[RSBP97] David Robinson, Erich Schulz, Philip Brown, and Colin
Price. Updating the read codes: User-interactive main-
tenance of a dynamic clinical vocabulary. Journal of the
American Medical Informatics Association, 4(6):465–472,
Nov/Dec 1997.
[RVAM08] Antonio J. Roa-Valverde and Jose F. Aldana-Montes. Ex-
tending ESB for semantic web services understanding. In
R. Meersman, Z. Tari, and P. Herrero, editors, OTM 2008
Workshops, LNCS 5333, pages 957–964. Springer-Verlag,
2008.
[Rya06] Amanda Ryan. Towards semantic interoperability in
healthcare: Ontology mapping from SNOMED-CT to HL7
version 3. In Mehmet Orgun and Thomas Meyer, editors,
Advances in Ontologies 2006, volume 72 of CRPIT. Aus-
tralian Computer Society, 2006.
[SCD+ 07] Abdul-Malik Shakir, David Cardenas, Gora Datta, De-
bashish Mittra, Arindam Basu, and Rini Verma. Design
and development of standards (HL7 V3) based enterprise
architecture for public health programs integration at the
County of Los Angeles (report). International Journal of

246 BIBLIOGRAPHY
Healthcare Information Systems and Informatics, 2.2:53–
66, April–June 2007.
[Sch04] Peter Schloeffel. Current EHR developments: an
Australian and international perspective – part 2.
Healthcare and Informatics Review Online. http://hcro
.enigma.co.nz/website/index.cfm?fuseaction=articledisplay
&FeatureID=020904, September 2004. Last Accessed:
May, 2008.
[SEH+ 03] Gerd Stumme, Marc Ehrig, Siegrfried Handschuh, An-
dreas Hotho, Alecander Maedche, Boris Motik, Daniel
Oberle, Christoph Schmitz, Steffen Staab, Ljiljana Sto-
janovic, Nenad Stojanovic, Rudi Studer, York Sure,
Raphael Volz, and Valentin Zacharias. The Karlsruhe view
on ontologies. Institute AIFB, 2003.
[SER+ 06] Jason Sargent, Peter Eklund, Amanda Ryan, Lois
Burgess, Joan Cooper, Carole Alcock, and Damian Ryan.
Mobile information access and diffusion in ambulatory
care service settings. In Proceedings of HIC 2006, 2006.
[Sev93] M.P. Severs. The clinical terms project. Bulletin of Royal
College of Physicians, 27:9–10, 1993.
[SH05] Amnon Shabo and Kevin S. Hughes. Family history in-
formation exchange services using HL7 clinical genomics
standard specifications. International Journal on Seman-
tic Web and Information Systems, 1.4:44–64, Oct–Dec
2005.
[SLM+ 07] Stéphane Spahni, Christian Lovis, Richard Mercille,
Hervé Verdel, Michel Cotten, and Antoine Geissbuhler.
Implementing a new ADT based on the HL7 version 3

BIBLIOGRAPHY 247
RIM. International Journal of Medical Informatics, 76:
190–194, 2007.
[Sta04] Standards Australia. AS 4700.6–2004 Implementation of
health level seven (HL7) version 2.3.1. Part 6: Referral
and discharge summary, 2004.
[Sun05] Sun Microsystems Inc. Jini distributed events specifica-
tions. http://java.sun.com/products/jini/2.1/doc/specs
/html/event-spec.html, 2005. Last Accessed: November,
2008.
[Sun08] Sun Microsystems Inc. J2ee connector architecture.
http://java.sun.com/j2ee/connector/, 2008. Last Ac-
cessed: December, 2008.
[TAC04] TACT Illawarra. TACT Referral Sources. SESIAHS, 2004.
[Tay06] Paul Taylor. From Patient Data to Medical Knowledge: the
principles and practice of Health Informatics. BMJ Books.
Blackwell Publishing Ltd, 2006.
[The08] The Regenstrief Institute, Inc. Logical observation identi-
fiers names and codes (LOINC). http://loinc.org/, 2008.
Last Accessed: December, 2008.
[TLL05] J. Tang, B.Y. Liang, and J.Z. Li. Toward detecting mapping
strategies for ontology interoperability. In WWW 2005,
May 2005.
[Uni08a] United States National Library of Medicine. PubMed.
http://www.ncbi.nlm.nih.gov/pubmed/, 2008. Last Ac-
cessed: September, 2008.
[Uni08b] United States National Library of Medicine. Unified
medical language system (UMLS). http://www.nlm

248 BIBLIOGRAPHY
.nih.gov/research/umls, 2008. Last Accessed: September,
2008.
[Vei01] Klaus Veil. HL7 Discharge Referral Message Imple-
menters’ Specification. NSW Health, June 2001.
[Viz04] L. Vizenor. Actions in health care organizations: An onto-
logical analysis. In M. Fieschi et al, editor, MedInfo 2004,
pages 1403–1407. IOS Press, 2004.
[W3C01] W3C. W3C semantic web activity. http://www.w3
.org/2001/sw/, 2001. Last Accessed: April, 2008.
[WABC04] D. Walsh, C. Alcock, L. Burgess, and J. Cooper. PDAs and
effective community healthcare delivery: a mobile technol-
ogy solution to point-of-care health services delivery for
ambulatory care. In Proceedings of CollECTeR LatAm,
2004.
[Wor08] World Health Organisation. International classifica-
tion of diseases (ICD). http://www.who.int /classifica-
tions/icd/en/, 2008.
[Yef03] Yefim V. Natis for Gartner. Predicts 2004: Application
integration and middleware. Research Paper, December
2003.

02 Whole

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

02 Whole

Uploaded by

Copyright:

Available Formats

University of Wollongong Thesis Collections

University of Wollongong Thesis Collection

Complete interoperability in healthcare :

Ducrou, Amanda Joanne, Complete interoperability in healthcare : technical, semantic

This paper is posted at Research Online.

A thesis submitted in fulfilment of

AMANDA JOANNE DUCROU

I, Amanda J. Ducrou, declare that this thesis, submitted in fulfilment of

I would like to acknowledge my supervisor, Peter Eklund, for giving me the

2 Health Standards Background 49

3 Referral Messaging Prototype 87

4 The ePOC Project 99

5 Ontology Mapping 125

6 SNOMED CT Vital Signs XML Database 147

7 The Jini Health Interoperability Framework (HIF-J) 161

8 Health Service Bus (HSB) 181

Technical Acknowledgements 213

A The HL7 Reference Information Model 215

B Complete OpenEHR Height Archetype 217

C SNOMED CT Subset Used in ePOC 223

D Flowchart of User Interface screens in the ePOC PDA

E Mapping HL7 V2 and V3 229

F Mapping HL7 V3 and openEHR 233

2.1 HL7 V2 Patient Referral Message Communications . 53

3.1 Patient Flow . . . . . . . . . . . . . . . . . . . . . . . . 89

4.1 ePOC Overall Plan . . . . . . . . . . . . . . . . . . . . 100

5.1 SNOMED CT Blood Pressure Concept . . . . . . . . . 131

6.1 SNOMED CT Vital Signs Subset . . . . . . . . . . . . 150

7.1 Process for Jini Registration . . . . . . . . . . . . . . . 165

8.1 HSB Conceptual Design . . . . . . . . . . . . . . . . . 182

A.1 The HL7 RIM Version 2.26 – Foundation Classes. . . 216

D.1 Complete flowchart of user interface screens in ePOC

1.1 Computer-based Handling of Clinical Information . . 39

2.1 HL7 V2 MSH Segment Fields . . . . . . . . . . . . . . 54

4.1 Mapping HL7 to SNOMED CT for Observations . . . 112

5.1 SNOMED CT to HL7 Mapping . . . . . . . . . . . . . 132

6.1 Part of the SNOMED CT Concepts File . . . . . . . . 149

7.1 HIF-J Observations HMD . . . . . . . . . . . . . . . . 173

C.1 ePOC SNOMED CT Subset (part 1) . . . . . . . . . . 224

E.1 Mapping of HL7 V2 fields to HL7 V3 . . . . . . . . . . 230

F.1 Mapping between HL7 V3 and openEHR . . . . . . . 234

HIF-J . . . . . . . . . . . . Health Interoperability Framework – Jini

Interoperability in healthcare is a requirement for effective communication

between entities, to ensure timely access to up-to-date patient information

cuses on the development of an interoperability solution for health by em-

ploying design science research methods to arrive at a final solution.

First, background topics including Health Informatics standards and

saging, openEHR for patient records, and SNOMED CT as a standard ter-

minology to facilitate clarity of information, and to discourage ambiguity

between communicating entities.

Ontology mapping methods between these standards designed to pro-

mote interoperability by using the standards in conjunction with each other

are then presented, leading to a solution for semantic interoperability.

A technical interoperability solution is required for sending these se-

mantically interoperable messages, which leads to the development of a

framework which uses a tuple-space paradigm to share messages. This

framework is shown to have some scalability issues, which leads to the

final solution – a scalable interoperability framework based on the Enter-

prise Service Bus methodology of enterprise integration which provides a

real-world answer to communication in healthcare.

Amanda Ducrou PhD Thesis, 2009

In Health Informatics, promises and expectations are renewed more often

ality [Tay06]. Information technology is used ubiquitously elsewhere today,