HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
EDITORS, CO-EDITORS, AND CONTRIBUTORS
Editors:
Principal Editors:
Peter L. Elkin, MD, Mayo Clinic ([email protected])
Martin Kernberg, MD, UCSF ([email protected])
Co-Editors:
Thomas Beale, Ocean Informatics
Sam Heard, MD, Ocean Informatics
Mark Shafarman, Chair, HL7
Robert Dolin, MD
Dale Nelson
Contributors:
Liora Alschuler, alschuler.spinosa
Russ Hamm, Mayo Clinic
Calvin Beebe, Mayo Clinic
George W. Beeler, Jr. Ph.D., Beeler Consulting LLC
Fred Behlen, PhD., LAI Technology
Tim Benson, Abies Ltd
Paul Biron, MLIS, Kaiser Permanente
Sandy Boyer, BSP, Consultant
Andrew Goodchild, DSTC
William T.F. Goossen, PhD, RN
Richard Harding, Queensland Health
Mike Henderson, Eastern Informatics
Mary Ann Juurlink, Killdara Corporation
Ted Klein, Klein Consulting, Inc
Mike Mair, MD
Charlie McCay, Ramsey Systems, Ltd.
Lloyd McKenzie, IBM Global Services
Charlie Mead, MD, MSc ([email protected])
Bas van Poppel, Hiscom BV
Jennifer Puyenbroek, McKesson Information Solutions
Angelo Rossi-Mori, CNR
Alexander Ruggieri, MD, Mayo Clinic
Gunther Schadow, MD, PhD, Regenstrief Institute for Health Care
Amnon Shabo, IBM Research
John Silva, Philips Medical Systems
Ioana Singureanu, Eversolve
Harold Solbrig, Mayo Clinic
Harry Solomon, GE Medical Systems
HL7 Template and Archetype Architecture
Template Special Interest Group
1
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
REVISION HISTORY
Revision history
Version
Date
1.0
Author
Comments
R Dolin
1.1
19 Feb 2003
M. Kernberg
Initial Baltimore Draft, with Templates SIG, EHR SIG,
and Structured Documents TC, Modelling and
Methodology TC, Vocabulary TC, Clinical Decision
Support
SR-XML, Document Ontology and Element Components
1.2
28 Mar 2003
S Heard
ADL Minor changes, terminology independence
1.3
8 Apr 2003
S Heard
1.4
11 Apr 2003
T Beale
ADL Language independence, additional languages and
terminology approaches
ADL Re-organisation of structure
1.5
14 Apr 2003
S Heard
ADL Upgraded Apgar significantly.
1.6
15 Apr 2003
T Beale
ADL Review
1.6.2
16 Apr 2003
T Beale/S Heard
ADL Added BP example, Foreign Languages section
1.7
September 9,
2003
November 30,
2003
P Elkin
September,
2004
P. Elkin, T Beale, R.
Hamm, S Heard
Draft Proposal for HL7 Memphis Meeting; Integration of
OWL Model
Revisions based on HL7 Memphis Meeting 2003;
Integration of ADL Model; Integration of OCL Constraint
Language for HL7 Artifacts; Integration of SML for
Expert Contributions
Revisions to the Spec based on the Conf Call feedback and
the KR work on Templates and Archetypes.
2.1
2.5
M Kernberg and P
Elkin, T Beale, and S
Heard
HL7 Template and Archetype Architecture
Template Special Interest Group
2
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
Table of Contents
1. ABSTRACT .................................................................................................................... 8
2. INTRODUCTION ........................................................................................................ 25
Intent of this document ..........................................................................................................................25
What is the mechanism of templates and archetypes? ........................................................................25
What is the intended purpose of a template and archetype? ..............................................................25
How do templates and archetypes differ from related HL7 artifacts? ..............................................25
SCOPE OF HL7 V3 TEMPLATES AND ARCHETYPES .................................................................25
Guiding principles ................................................................................................................................25
In scope ................................................................................................................................................25
Out of scope .........................................................................................................................................25
3. HL7 Definition of Terms ............................................................................................ 25
4. ARCHITECTURAL OVERVIEW: RELATIONSHIP OF TECHNICAL
FORMALISMS AND THE RIM..................................................................................... 25
5. TEMPLATES AS GENERAL CONSTRAINTS ON HL7 ARTIFACTS .................. 25
Template and archetype requirements .................................................................................................25
Template and archetype design .............................................................................................................25
Template and archetype assertions .......................................................................................................25
Static assertions.......................................................................................................................................25
Co-occurrence assertions .......................................................................................................................25
Containment assertions ..........................................................................................................................25
Logic assertions .......................................................................................................................................25
Normative template and archetype representation .............................................................................25
Template and archetype declaration .....................................................................................................25
Template and archetype registration ....................................................................................................25
Template and archetype repository ......................................................................................................25
Template and archetype metadata ........................................................................................................25
9. OCL: GENERAL CONSTRAINTS ON HL7 ARTIFACTS ...................................... 75
Object Constraint Language Specification ...........................................................................................75
Contents ...................................................................................................................................................75
Topic Page ...........................................................................................................................................75
9.1 Overview .......................................................................................................................................75
9.1.1
Why OCL? ........................................................................................................................75
9.1.2
Where to Use OCL ............................................................................................................76
9.2
Introduction ...........................................................................................................................77
9.2.1
Legend...............................................................................................................................77
9.2.2
Example Class Diagram ...................................................................................................77
9.3
Relation to the UML Metamodel ...........................................................................................77
9.3.1
Self ....................................................................................................................................77
9.3.2
Specifying the UML context ..............................................................................................78
HL7 Template and Archetype Architecture
Template Special Interest Group
3
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
9.3.3
Invariants ..........................................................................................................................78
9.3.4
Pre- and Postconditions ....................................................................................................79
9.3.5
Package context ................................................................................................................79
9.3.6
General Expressions .........................................................................................................80
9.4
Basic Values and Types .........................................................................................................80
9.4.1
Types from the UML Model ..............................................................................................80
9.4.2
Enumeration Types ...........................................................................................................81
9.4.3
Let Expressions and «definition» Constraints ..................................................................81
9.4.4
Type Conformance ............................................................................................................81
9.4.5
Re-typing or Casting .........................................................................................................82
9.4.6
Precedence Rules ..............................................................................................................83
9.4.7
Use of Infix Operators ......................................................................................................83
9.4.8
Keywords ..........................................................................................................................83
9.4.9
Comment ...........................................................................................................................83
9.4.10
Undefined Values .........................................................................................................84
9.5
Objects and Properties ...........................................................................................................84
9.5.1
Properties .........................................................................................................................84
9.5.2
Properties: Attributes........................................................................................................85
9.5.3
Properties: Operations .....................................................................................................85
9.5.4
Properties: Association Ends and Navigation ..................................................................85
9.5.5
Navigation to Association Classes ....................................................................................87
9.5.6
Navigation from Association Classes ...............................................................................88
9.5.7
Navigation through Qualified Associations ......................................................................88
9.5.8
Using Pathnames for Packages ........................................................................................89
9.5.9
Accessing overridden properties of supertypes .................................................................89
9.5.10
Predefined properties on All Objects ...........................................................................90
9.5.11
Features on Classes Themselves ..................................................................................90
9.5.12
Collections ...................................................................................................................91
9.5.13
Collections of Collections ............................................................................................92
9.5.14
Collection Type Hierarchy and Type Conformance Rules ...........................................92
9.5.15
Previous Values in Postconditions ...............................................................................93
9.6
Collection Operations ............................................................................................................93
9.6.1
Select and Reject Operations ............................................................................................94
9.6.2
Collect Operation .............................................................................................................95
9.6.3
ForAll Operation ..............................................................................................................96
9.6.4
Exists Operation ...............................................................................................................96
9.6.5
Iterate Operation ..............................................................................................................97
9.6.6
Iterators in Collection Operations ....................................................................................98
9.6.7
Resolving Properties .........................................................................................................98
9.7
The Standard OCL Package ...................................................................................................98
9.8
Predefined OCL Types ..........................................................................................................99
9.8.1
Basic Types .......................................................................................................................99
9.8.2
Collection-Related Types ................................................................................................103
9.9
Grammar ..............................................................................................................................110
10. TEMPLATE AND ARCHETYPE CONSTRAINTS ON CLINICAL DATA:
SYNTAX ......................................................................................................................... 114
10.1 ADL Formalism ............................................................................................................................114
Introduction ..........................................................................................................................................114
Status .....................................................................................................................................................114
Syntax Overview ...................................................................................................................................115
Typographical Conventions ...............................................................................................................115
Symbols .............................................................................................................................................115
HL7 Template and Archetype Architecture
Template Special Interest Group
4
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
Archetype Structure ...........................................................................................................................116
Body Part Syntax ...............................................................................................................................116
Terminology Part ..................................................................................................................................117
Identification .........................................................................................................................................118
ISO Oid Id .............................................................................................................................................118
Multi-axial Archetype Identifier .........................................................................................................119
Archetype Metadata .............................................................................................................................120
Archetype Relationships ................................................................................................ 122
Composition ..........................................................................................................................................122
Specialization ........................................................................................................................................122
Versions .................................................................................................................................................123
Revisions ................................................................................................................................................123
Relationship with Knowledge – Ontologies and Terminology ..........................................................123
Design Time Node Names .................................................................................................................123
Runtime Node Name Constraints.......................................................................................................123
Values ................................................................................................................................................124
Terminology Definitions and Bindings ..............................................................................................124
Paths.......................................................................................................................................................125
Invariants ..............................................................................................................................................126
Templates ..............................................................................................................................................127
Foreign Languages................................................................................................................................127
Archetype Examples .............................................................................................................................128
Blood Pressure ......................................................................................................................................129
problem/SOAP Headings .....................................................................................................................132
Haematology result ...............................................................................................................................136
Complete Blood Count (CBC) .............................................................................................................137
APGAR ..................................................................................................................................................139
Template Examples ..............................................................................................................................143
Ante-natal Visit ..................................................................................................................................143
Diabetic Review Contact ...................................................................................................................143
Querying ................................................................................................................................................143
Production Rules ...................................................................................................................................144
Generic Syntax ......................................................................................................................................144
OpenEHR Plug-ins ...............................................................................................................................146
References ...................................................................................................................... 147
10.2 SR-XML: GRAPHICAL TEMPLATE REPRESENTATION .................................................148
SR XML OF CLINICAL INFORMATION AND PROCEDURES .................................................148
SR XML TEMPLATE 1: CLINICAL INFORMATION ..................................................................149
HL7 Template and Archetype Architecture
Template Special Interest Group
5
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
SR XML TEMPLATE 2: DEMOGRAPHICS ...................................................................................150
SR XML TEMPLATE 3: CLINICAL INDICATION .......................................................................151
SR XML TEMPLATE 4: INTERVENTIONAL (OR IMAGING) REPORT ................................151
SR XML TEMPLATE 5: COMPARISON .........................................................................................152
SR XML TEMPLATE 6: TECHNICAL METHODS .......................................................................153
SR XML TEMPLATE 7: QUANTITATIVE ANALYSIS ................................................................153
SR XML TEMPLATE 8: QUALITATIVE ANALYSIS ...................................................................154
SR XML IMAGING/INTERVENTIONAL TEMPLATE 9: ASSESSMENT.................................155
SR XML IMAGING/INTERVENTIONAL TEMPLATE 10: PLAN ..............................................155
11. TEMPLATE CONSTRAINTS ON CLINICAL DATA: SEMANTICS ................. 156
11.1 OWL Formalism ...........................................................................................................................156
11.2 Template and archetype Formalism ...........................................................................................156
OWL Class Axioms ...........................................................................................................................157
11.3.2.2. OWL Descriptions ..............................................................................................................157
11.3.2.3. OWL Restrictions ...............................................................................................................158
11.3.2.4. OWL Property Axioms .......................................................................................................159
11.3 Example Template and archetype For a CBC ...........................................................................160
11.4 Template and archetype Validation ............................................................................................162
11.5 HL7 ebXML Registry ...................................................................................................................167
Template and archetype registration ..................................................................................................167
Finding a registered template and archetype .....................................................................................174
Create an HL7 instance that conforms to a template and archetype ...............................................175
Advance a template and archetype to normative status ....................................................................175
Declare the use of a template and archetype in a normative specification ......................................176
12. OUTSTANDING ISSUES ....................................................................................... 177
13. Web Ontology Language (OWL) Specification ...................................................... 178
13.1 OWL Language and its Formal Logic ........................................................................................178
Relationships between OWL classes ...........................................................................................182
Membership in OWL classes ..........................................................................................................182
Characteristics of members of OWL classes ......................................................................................183
RDFS domains and ranges are strengthened to if-and-only-if over the OWL universe. ................183
Some OWL properties have iff characterizations ..............................................................................184
RI contains elements corresponding to all possible OWL descriptions and data ranges ....................185
13.2 SR XML example of Procedural Template ................................................................................187
SR XML Procedural Template 1: ECG ............................................................................................187
SR XML TEMPLATE 2: DEMOGRAPHICS ..................................................................................187
SR XML TEMPLATE 3: CLINICAL INDICATION(S) .................................................................189
SR XML TEMPLATE 4: COMPARISON ........................................................................................189
SR XML TEMPLATE 5: CLINICAL INFORMATION...................................................................189
SR-XML Template 6: Technical Methods .........................................................................................190
HL7 Template and Archetype Architecture
Template Special Interest Group
6
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
SR XML Template 7: Quantitative Analysis .....................................................................................191
SR XML Template 8: Qualitative Results .........................................................................................192
SR XML TEMPLATE 9: ASSESSMENT ........................................................................................192
13.3 Template Document Ontology .....................................................................................................193
INTRODUCTION: GENERAL DOCUMENT TYPES IN CLINICAL MEDICINE .......................193
PART 1 DOCUMENT ONTOLOGY: GENERAL DOCUMENT TYPES ......................................194
PART 2: DOCUMENT ONTOLOGY AND CLINICAL DOMAINS ..............................................196
Notes: .................................................................................................................................................197
PART 3: APPLICATION OF INFORMATION MODEL TO CLINICAL PRESENTATION IN
EMERGENCY MEDICINE: Template Examples ............................................................................198
PART 4: A DOCUMENT ONTOLOGY FOR MEDICAL IMAGING ............................................200
14. GLOSSARY .............................................................................................................. 202
15. REFERENCES ........................................................................................................ 203
HL7 Template and Archetype Architecture
Template Special Interest Group
7
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
FOREWORD
This document was produced by the Templates SIG, in collaboration with the Methods
and Methodology and Structured Documents Technical Committess, and with
consultation from International HL7 affiliates.
INTRODUCTION
ABSTRACT
The standards in this document provide a formalism, methodology, and a repository
mechanism for constraints on HL7 conformant artifacts, and for clinical data specifically,
in order to permit syntactic and semantic representation of complex clinical data,
computer processing of the clinical data, interoperability in multiple languages, and
digital communication among information systems and human users.
What is the Template Architecture?
The HL7 Template Architecture (TA) is a standard that specifies the syntax and
semantics of the constituent components of clinical documents or messages for the
purpose of exchange. A Template is a defined information object that specifies
constraints on rMIM or their constituent fragments. The primary intent of the Template
Architecture is to define a set of provisions to facilitate production, implementation and
comparison of HL7 V3 Templates.
A Template has the following characteristics (TABLE 1):

Persistence – A Template exists in an unaltered state, for a time period defined by
local and regulatory requirements.1

Stewardship – A template is maintained by an organization or organizations entrusted
with its care.

Potential for authentication - A clinical document is an assemblage of information
that is intended to be legally authenticated.

Context - A template establishes the default context for its contents.
1
There is a distinct scope of persistence for a clinical document, independent of the persistence of any
XML-encoded CDA document instance.
HL7 Template and Archetype Architecture
Template Special Interest Group
8
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE

Version 3.0
Wholeness - Authentication of a clinical document applies to the whole and does not
apply to portions of the document without the full context of the document.

Human readability – A clinical document is human readable.

A subset of templates have the following characteristics: TABLE 2. (these invariant
and recyclable subtemplates are termed archetypes). For example, if a rMIM
fragment (such as blood pressure) is ubiquitously and invariantly utilized in “History
and Physical-Type Templates”, then this fragment can be termed an archetype and
can be formally registered in a HL7 depository, in order to promote ease of
reusability.
Key aspects of the TA:
Key aspects of the TA include:

TAs are encoded in Extensible Markup Language (XML).

TAs derive their meaning from the HL7 Reference Information Model (RIM), DIM,
rMIM, and associated rMIM fragments, and use the HL7 Version 3 Data Types.

The TA specification is richly expressive and flexible. As an example, documentlevel, section-level and entry-level templates can be used to constrain the generic
Clinical Document Architecture specification.
Components of a TA:
This section serves as an introduction to the major components of a TA, all of which are
described again and in greater detail later on. The intent here is to familiarize the reader
with the high-level concepts to facilitate an understanding of the sections that follow.
Major components of a prototypic TA are shown in Error! Reference source not
found..
What is the normative representation?
This document provides a normative representation for HL7 V3 Templatess and a
description of the metadata to characterize them.
Exactly what is meant by “HL7 V3 Templates”, and the various scenarios surrounding
the use of these artifacts will also be described in sufficient detail as to enable their
implementation.
HL7 Template and Archetype Architecture
Template Special Interest Group
9
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
This document introduces also an outline of annexes that will be subsequently developed:
- The agreements with the organizations enabled by HL7 to register and maintain
Templates,
- The description of potential quality assurance mechanisms that may be adopted
by the external organizations and within HL7 in the development and
maintenance of Templates,
- The guidelines for the uniform generation of the most relevant types of Templates
across the cooperating organizations, including any specific intermediate
formalism that will be found appropriate for each type for Templates to facilitate
input and verification of Templates by domain experts.
What is the application of Templates? (intended use)
In the general sense, a Templates is a structured collection of data / information that, in
total, is of interest to one or more healthcare stakeholders.
In the specific sense of this document, an HL7 V3 Templates is a constraint against a
normative HL7 V3 specification. HL7 V3 instances must conform to some normative
HL7 V3 specification, and in addition, can be stated to conform to the additional
constraints expressed in one or more HL7 V3 Templates.
The stepwise process to produce, maintain and distribute Templates will be supported by
a series of annexes, as illustrated in fig. N1.
ongoing
experimental phase
external
organizations
supporting
material
quality
assurance
provisions
agreements
between HL7 and
organizations
packages
of templates
local
repositories
(local formalism)
final standard
HL7 templates
metadata
HL7 templates
formalism
HL7 templates
metadata
registry
HL7 templates
repository
ancestors
for types
of templates
Balloted
Template
Formalism
By the Templates mechanism, HL7 empowers external organizations to generate,
maintain and distribute packages of Templates that correspond to defined use cases.
HL7 Template and Archetype Architecture
Template Special Interest Group
10
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
Each package will be used within a user sub-community to share information
according to the intent of the external organization, to increase the quality of the
corresponding workflows. The usage of a package of Templates in HL7 messages or
documents implies an implicit or explicit negotiation among the involved parties, and is
reflected in the design of applications, as for any other adoption of standards.
The package of Templates must be supported by adequate documentation about
the use cases, with detailed guidelines for an appropriate usage of the package and of the
individual Templates. This material must be made available by the external organization
– typically through the web – and must be systematically maintained. The usage of a
package may be facilitated by the provision of specific software tools.The external
organization should set up an appropriate process to collect feedback from users and to
produce revisions of the package.
One organization will be the primary one responsible towards HL7 for the
maintenance of a package and of the individual Templates. Other organizations can
notify their interest in the package or in particular Templates, and contribute to their
maintenance and distribution, by cooperating with the primary responsible organization
or by including the package or individual Templates in a package that is under their
responsibility. The process should be managed through direct agreements among the
involved organization. These agreements should be made known to HL7. Future annexes
of this standard will provide the minimal requirements for these agreements.
A package of Templates may be developed and submitted to HL7 by an
intermediary organization, e.g. based on narrative material produced by another
organization, which remains directly responsible for the content.The related agreement
between the two organizations should be made known to HL7. This kind of process
should be regulated by further guidelines in a future annex to this document.
Two or more external organizations, with the support of HL7, could identify areas
of common interest and may wish to develop common Templates. This process will be
facilitated by the registry of Templates and by the normative formalism to represent
Templates.
Relevant Templates could be adopted by an HL7 SIG or TC, and – if appropriate
– may be balloted as a part of the HL7 standard or mentioned within the HL7 standard.In
particular, an HL7 TC could decide to develop one or more generic Templates or
Templates, to be used as “ancestors” to revise a set of existing Templates or Templates of
the same type and to guide the generation of new ones (e.g. a generic shape for a battery
of observations from the same sample, or a generic Template or TEMPLATE that fits
with the requirements of the CDA level 2 standard). The TC, in cooperation with the
Template SIG, may also define a simplified intermediate representation to facilitate
authoring and distribution of that type of Templates.When the responsible body for
maintaining and documenting a package or a generic Templates becomes the HL7 TC,
HL7 will arrange to include the Templates and the related supporting material into an
adequate repository.
HL7 Template and Archetype Architecture
11
Template Special Interest Group
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
What is the intended purpose of a Template?
It is often necessary to further constrain an HL7 specification – to restrict the specific
value sets, to define test batteries, to specify required internal document components, etc.
Reasons for building Templates include, but are not limited to:

Human-to-Human Communication - Templates can serve as a (structured)
formalism through which human beings (either singlely or as part of groups or
organizations) can unambiguously exchange (structured) information, which focuses
aspect or feature of (most often) clinical care, e.g.. "This is what a CBC means to our
group, what does it mean to yours?"

Constraint and validation of computer-to-computer messages - Templates can be
used to validate message content according to the Templates rules. "Verify that this
message is a valid instance of a CBC Templates (according to my definition...)"

Construction - Templates can be used to guide and direct information input. A
Templates define which fields are required, which are optional and which cannot be
entered along with the permissible value sets that may populate each field. "What
information is necessary to fill in a CBC? What are the data types, values and
selection lists for each of the fields?" Templates are object oriented and can be
constructed with strict inheritance of constraint models.

Predication - Templates can be used to determine whether a message meets a
specific 'predicate'. As an example, Templates could be constructed that describe lab
tests, CBC's, abnormal CBC's, etc, and then used to drive decision support / alerting
software mechanisms. "Is this an instance of an abnormal CBC?"

Post-processing – Templates may be used to convey the information that a
fragment of a message meets agreed constraints, and thus is suitable for a specific
processing in the receiving system (e.g. allocation of a battery to a particular device,
calculating the price of a set of laboratory tests, trigger the calculation of derived
variables)

Description - Templates can be used to describe the relationships between data
elements that can then be queried - "Where would I have to look to find all instances
of a WBC?"
How do Templates differ from related HL7 artifacts?
HL7 V3 Templates differ from related HL7 artifacts in their normative representation
and/or in the scenarios where they are applicable. For the most part, the distinctions are
clear, although there is a gray zone where for instance a user may have the option of
building either a Templates or a conformance profile.
HL7 Template and Archetype Architecture
Template Special Interest Group
12
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
HL7 V3 artifacts that can further constrain a normative HL7 V3 specification include
conformance profiles and International localization. (See V3 chapter “Refinement,
Extension and Conformance to Version 3 Messages” for details on these artifacts.)
Differences in normative representation are hard to state right now. This is an active area
of discussion, and there is more and more convergence of ideas. HL7 V2.x conformance
profiles are expressed in XML, and a normative HL7 V2.x conformance profile XML
DTD defines valid conformance profile instances. Tools are provided to help author V2.x
conformance profiles. The exact means of validation of an instance against a
conformance profile is not part of the normative specification. International localization
is expressed as a more specific R-MIM, where more detailed clones are crafted to
represent international constraints. This R-MIM yields an XML schema. V3 instances
have new XML element names reflective of the new clones, and can be validated against
the internationalized XML schema (see Figure 1).
Note that International localization results in new clones, and therefore in new
XML element names. Conformance profiles and Templates do not constrain by creating
new clones, and therefore do not result in new XML element names.
Both conformance profiles and Templates express constraints against normative
specifications. HL7 instances are valid against both the normative specification AND
against the additional constraints expressed in the Templates or conformance profile.
Both can express constraints against an entire specification.
Conformance profiles are used to further constrain the normative message
specification to be specific to a particular trigger event (e.g., to indicate the need for more
data items in the PID segment for an "update person" trigger than for a "link patient"
trigger - even though both trigger events use the same PID structure in their normative
HL7 V2.x ADT messages). A conformance profile is only expressed against an entire
specification. Conformance profiles are applied at program design time.
HL7 V3 Templates further constrain the internal content of a V3 message or
document, irrespective of triggers. In its simplest sense this indicates which clinical
concepts are to be captured and whether they are to be captured as numeric, coded or text.
Templates need not constrain an entire specification; Templates can contain other
Templates (for instance, a history-and-physical Templates can contain a cardiac-exam
Templates which can contain a vital-signs Templates); and Templates are reusable (for
instance, a vital-signs Templates can be used in a history-and-physical document and/or
in a consultation document and/or in a observation message). Often times, because the
clinical content of any clinical interaction is unknown before the patient walks thru the
door, Templates are selected at run-time.
So in general, if the intent is to constrain an entire specification based on a
specific trigger, a user would create a conformance profile. If the intent were to further
constrain the clinical content of a specification, a user would create a Templates. It can be
HL7 Template and Archetype Architecture
Template Special Interest Group
13
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
the case that a user needs to create both a conformance profile and one or more
Templates to achieve the desired degree of constraint.
RIM
Restricts
DIM
Restricts
CIM
(Constratined Information
Model)
R-MIM
MIF Representable
(Model Interchange Format of the
HDF)
(HL7 xmi Equivalent)
Restricts via OCL
Template
Figure 1: Conceptual diagram of where Templates fit in the HL7 dependency hierarchy.
Although listed only once, vocabulary constraints can be applied at any level in the
cascade. They appear at the base of this diagram to stress the importance of obtaining
clinical vocabulary input.
HL7 Template and Archetype Architecture
Template Special Interest Group
14
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
1. SCOPE OF HL7 V3 TEMPLATES (Separate Section: Normative)
1.1 Guiding principles
The scope of the HL7 V3 Templates Architecture standard is a based on the following
guiding principles:







The fundamental framework for HL7 V3 Templates is the Reference Information
Model (RIM).
Templates are a set of well-defined constraints on specific, RIM-derived HL7 V3
artifacts, including, but not restricted to, the Clincial Document Architecture (CDA).
The fundamental constraints, as is applicable to HL7 V3 artifacts in general, will be
expressed in Object Constraint Language (OCL) 2.
The formal integration of the HL7 V3 developmental methodology, including the
Model Interchange Format.
The standardized expression of HL7 V3 Clinical Templates in a form that permits
interoperable exchange, i.e., preservation of syntactic and semantic information
Be consistent with GEHR, CEN, DICOM and other standards that have defined
Templates so that the interchange of Templates can be performed.
Enable the expression of real-world use cases required by international, national,
regional, and local institutions and practitioners.
1.2 In scope
Operationally, the guiding principles serve to limit the expressivity of HL7 V3
Templates, precluding them from making certain assertions or constraints in a standard
way. The resulting set of allowable assertions form the substance of the normative part of
this standard, and overall might be summarized as those assertions that constrain static
data structures and express inter-data field/value dependencies.
2
OCL is the formal constraitn language for information models expressed in UML, such as the HL7 V3
RIM.
HL7 Template and Archetype Architecture
Template Special Interest Group
15
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
1.3 Out of scope
The following components are not a normative part of this standard:




HL7 V3 Templates analysis-level authoring tools;
This standard does not actually build the complete set of Templates, but instead
specifies a normative Templates representation.
A Templates is a static data structure that can express assertion-based inter-data field
and value dependencies, but contains no inherent behavior.
- This distinction can be subtle at times, but for instance, a Templates might say
that if the value of fieldOne is “X”, then the value of fieldTwo must be “Y”. A
Templates cannot say to actually populate fieldTwo with a value of “Y” if the
user has populated fieldOne with “X”. This application behavior is enabled by
Templates, but is not part of the Templates standard.
A definitive mechanism for comparing overlapping Templates and converging them
on a single best Templates. This standard places no restrictions at the present time on
who can create and register a conformant HL7 V3 Templates. However it is
recognized that such convergence is of considerable clinical utility, and it is hoped
that such efforts will be encouraged.
HL7 Template and Archetype Architecture
Template Special Interest Group
16
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
2. REFERENCES AND ABBREVIATIONS (Separate section)
2.8.1 references
2.8.2 abbreviations
3. DEFINITIONS
Archetype:
A subset of templates, that syntactically and semantically structured
aggregation of vocabulary or other data, which is the basic unit of clinical
information.
Scope
Area of application for a normative standard, based on the traditional area
for ship at anchor.
Template:
A structured aggregation of one or more Templates, with optional order,
used to represent clinical data.
Vocabulary:
A collection of terms in a particular language that may be
alphanumerically coded by individuals, groups, public or private agencies.
HL7 Template and Archetype Architecture
Template Special Interest Group
17
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
4. ARCHITECTURAL OVERVIEW: RELATIONSHIP OF
TECHNICAL FORMALISMS AND THE RIM (Informative)
The following diagram provides an overview of the architectural relationships among
the HL7 RIM (Reference Information Model) hierarchy, the various formalisms or
software applications recommended for computer representation, and the parallel
structure between clinical documents and messages.
The formalisms indicated in the architecture (OCL, OWL, ADL, and SR-XML) have
particular advantages with respect to their applications in the hierarchy, but retain
formal interconvertibility and a shared representation in XML-compatible objects.
Specifically,
 ADL provides a compact syntactic and semantic representation of clinical
information (which maps into UML, with OCL constraints)
 OCL (with GELLO additions) provides a standard constraint language for
HL7 RIM artifacts expressed in UML (as a fundamental representation).
 For purposes of representation in Web-conformant methodologies (i.e.,
W3C standards)
o SR-XML provides a shared graphical representation of clinical
information, for clinical domain experts, informaticists, and
programmers (for conversion to XML, XSD, XSLT, OWL and so
forth).
o OWL, the standard for Web-based ontological representation,
provides a semantically rich representation of clinical information.
The following diagram summarizes the current HL7 tooling, with the subsequent diagram providing the next stage in HL7
tooling for the Templates Architecture.
HL7 Template and Archetype Architecture
Template Special Interest Group
18
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
RIM
(Visio)
DIM
(Visio)
R-MIM
(Visio)
CDA R-MIM
(Visio)
Message R-MIM
(Visio)
Document Types
(RoseTree with Export to XSD)
Message Types
(RoseTree with Export to XSD)
Templates
(OCL stored in RoseTree)
Templates
(OCL stored in RoseTree)
Archetypes
1. ADL
2. Semantics (OWL)
3. Graphic (SR-XML)
Archetypes
1. ADL
2. Semantics (OWL)
3. Graphic (SR-XML)
Data
Data
HL7 Template and Archetype Architecture
Template Special Interest Group
19
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
RIM
(Visio/MIF)
DIM
(Visio/MIF)
R-MIM
(Visio/MIF)
CDA R-MIM
(Visio/MIF)
Message R-MIM
(Visio/MIF)
Document Types
(Visio/MIF with Export to XSD)
Message Types
(Visio/MIF with Export to XSD)
Templates
(Visio/MIF with Export to XSD)
Templates
(Visio/MIF with Export to XSD)
Archetypes
1. ADL
2. Semantics (OWL)
3. Graphic (SR-XML)
Archetypes
1. ADL
2. Semantics (OWL)
3. Graphic (SR-XML)
Data
Data
HL7 Template and Archetype Architecture
Template Special Interest Group
20
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
5. TEMPLATE FUNCTIONAL REQUIREMENTS
This section defines requirements for the normative representation of an HL7 V3
Templates.
5.1 Template Design
While any number of tools can create a normative HL7 V3 Templates, there are
requirements to which all of them must adhere. HL7, in association with domain experts
and organizations, will create a library of Templates, which are pieces of normative
specifications that can be imported into an authoring environment and constrained. These
Templates are as large as complete specifications, and can be as small as individual
CMETs and clones. Stuctured aggregation of Templates are Templates.
Within the HL7 library of Templates is an association table that indicates the HL7
specifications that contain these components. Thus, when a user creates a Template or
TEMPLATE, the HL7 specification to which the Template or TEMPLATE is applicable
is known. In addition, a user can query the library for all templatable components of any
HL7 specification.
Any tool that creates an HL7 V3 Template or TEMPLATE will collect appropriate
metadata about that Template or TEMPLATE, including the component that was
constrained.
Constraining a component must allow for the unrolling of recursive associations, or for
the repeated traversal of associations with maximum cardinality greater than 1. This is
necessary, for instance, when the normative specification being constrained simply says,
“a section can contain 0.many sections”, and the intent of the Template and constituent
Templates is to specify constraints on nested sections.
5.2 Templates Assertions
This section defines the types of constraints or assertions that can be expressed.
5.2.1 Static assertions:
A Template and constituent Templates can constrain the cardinality of a clone’s
association.
A Template and constituent Templates can constrain the cardinality of a clone’s attribute.
A Template and constituent Templates can constrain the allowable date/time values in a
date/time field.
A Template and constituent Templates can constrain any attribute value to be a subset of
those values legally permissible in the specification being constrained.
A Template or constituent Templates can constrain the range of allowable date/time
values for attributes valued by date/time data types.
HL7 Template and Archetype Architecture
Template Special Interest Group
21
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
A Template or constituent Templates can constrain the range of allowable code values for
attributes valued by terminology concepts.
A Template or constituent Templates can constrain the range of allowable numbers for
attributes valued3 by numbers.
A Template or constituent Templates can express a regular expression constraint4 on
attributes valued by strings.
A Template or constituent Templates can constrain any data type component, including
recursively-nested components.
A Template or constituent Templates can constrain the range of allowable values of a
clone’s attribute.
All additional constraints that can be expressed in a normative specification (including all
the columns in an HMD) can be further constrained in a Template or TEMPLATE.
5.2.2 Co-Occurrence Assertions
The value of one field can be constrained based on the value of another field.
Example: If fieldOne is “X”, then fieldTwo’s value must be “A”.
Chronological assertions can constrain the date/time value of one field based on the
date/time of another field.
Example: The start time for fieldOne is (earlier | later | equal to) the start time of
fieldTwo.
Numeric comparison assertions can constrain the numeric value of one field based on the
value of another field.
Example: The value of fieldOne is (equal to | less than | greater than) the value of
fieldTwo.
Numeric operation assertions can constrain the numeric value of one field based on a
numeric operator applied to the value of another field or constant.
Example: The value of fieldOne is (equal to | less than | greater than) the value of
fieldTwo (plus 7 | divided by 27).
String comparison assertions can constrain the string value of one field based on the
value of another field.
Example: The string value of fieldOne is contained in the value of fieldTwo.
Any constraint a Template and constituent Templates can make can be made dependent
on the value expressed in one or more other fields. For instance, in addition to
constraining the cardinality of an association, a Template and constituent Templates can
constrain the cardinality based on the value in a particular field.
Example: If ((fieldOne is “X” or “Y”) OR (fieldTwo is “ABC”)) then ((a nested act
HL7 Template and Archetype Architecture
Template Special Interest Group
22
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
relationship under Observation is required) AND (fieldThree in the nested act has a value
of “A” or “B” or “C”) AND (fieldThree in the nested act cannot be NULL)).
5.3 Containment assertions
Data descendant assertions can constrain allowable depth at which one component is
nested within another component.
Example: The vital-signs section must be (a direct child of | some descendant of | less
than a depth of X from) the physical-exam section.
Items in a Template and constituent Templates can be “ordered” or “unordered”. In an
ordered Templates, the order of the stated assertions is important. In an unordered
Template or TEMPLATE, the order is not important.
Example: Assertion One: There is a nested act under observationOne that has an
observation.cd for “hemoglobin”. Assertion Two: There is a nested act under
observationOne that has an observation.cd for “hematocrit. If the Template and
constituent Templates are “ordered”, the “hemoglobin” must come before the
“hematocrit”. If the Template and constituent Templates is “unordered” the
“hemoglobin” can come before or after the “hematocrit”.
5.4 Logic Assertions
Logical operators can be applied to a set of assertions to indicate which assertions in the
set must be true or false.
Example: (All | at least X | at most X | exactly X) of the assertions contained in this set
must be (true | false).
5.5 Normative Templates Representation
A normative representation of a conformant HL7 V3 Templates must be specified, in a
manner that permits
 the accurate representation of the syntax and semantics of clinical
information as defined by clinical experts
 expression in a metalanguage independent of, but transformable into,
particular technical languages or software platforms
 the mapping of the representation into HL7 RIM-conformant artifacts and
methodologies
 the mapping into standard UML representation, with permitted OCL
constraints
 the mapping into standard Web-based methodologies (including XML,
XSD, and OWL)
The normative representation by the ADL metalanguage is detailed below.
5.6 Templates Declaration
This section specifies how an HL7 V3 instance declares the use of a Templates.
Guiding assertions to be used in crafting the solution include:
HL7 Template and Archetype Architecture
Template Special Interest Group
23
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
1. The mechanism for identifying Templates or Templates must be ITS independent. It is
anticipated that a piece of data may be translated across multiple ITSs, before it arrives at
its prescribed destination.
2. The mechanism should support Templates or Templates that are routed in Act, Entity,
Role, or Participation.
3. One should be informed by the way HL7 identifies what 'message' is being sent,
namely through an attribute in the Communication wrapper. Thus, the Structural Classes,
which are intended to carry clinical and administrative data, should carry the required
Template or TEMPLATE metadata.
Based on these assertions, it is proposed to create a new class on the Structural
half of the RIM, which is related to Act, Entity, Role, and Participation. This class would
have an optional link which will be automatically added to each ITS, allowing the
identification of Templates or Templates wherever they are required. Furthermore,
different ITS's may choose to communicate this class in different ways, opening the door
to supporting XML 'standard' ways of identifying Templates or Templates, if such an
object appears.
5.7 Templates Registration
This section defines Templates registry/repository requirements.
5.7.1 Templates Repository
This section defines requirements for a repository of HL7 V3 Templates.
HL7 will create a common set of metadata that is used to catalog both Templates and
conformance profiles that are housed in the repository.A user can search against any or
all of the metadata fields when looking for a Templates.
The hierarchical relationship between two Templates can be expressed. Thus, if there are
a series of, say, Echocardiography Templates, each applying tighter and tighter
constraints, this hierarchy can be represented in the repository.
A user can search for all Templates that constrain to a particular code or coding scheme.
For instance, a user can find all Templates that make reference to the LOINC code for
CBC. A user can search for all HL7 registered Templates or Templates that are
applicable CDA Version 2 constraints.A user can search for all HL7 registered Templates
that are potentially applicable constraints for a particular balloted specification.
A user can compare two Templates and see if they are equivalent, or if not, what the
differences are. A user can check a Templates against an R-MIM Fragment and see if it is
possible to create an instance using the R-MIM that could meet the constraints of the
Templates; i.e., check to see if a Template or TEMPLATE is compatible with an R-MIM.
HL7 Template and Archetype Architecture
Template Special Interest Group
24
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
5.7.2 Templates Metadata
This section defines requirements for metadata used to catalog HL7 V3 Templates.
Each Template or TEMPLATE in the registry has a globally unique identifier (metadata
field “identifier” below). None of the other metadata fields are needed in order to refer to
a specific Templates, nor is there any guarantee of uniqueness in any other metadata field
or combination of fields.
The following table represents a mapping of various metadata strategies (encompassing
ebXML, Dublin Core, and others). The intent is for both Templates and Conformance
Committees to converge on the same set of values. The first three columns are normative,
the second three columns are informative.
6 Formal Model for Templates / Archetypes
The philosophy for the model is to allow knowledge to be created in the most appropriate
mechanism available. Modelers aften express knowledge in UML and these models with
their associated constraints and expertise is highly valued and the basis for much of the
good work of HL7 v3 to date. Clinicians frequently prefer to specify knowledge in
clinical structures which are easily and intuitively represented in Templates / Archetypes.
Terminologists represent knowledge in terminologies often based on description logics
which provide the ability to represent core and fundamental details of clinical
information. The Templates / Archetypes standard is a formalism for integration of the
knowledge generated in any or all of these knowledge sources and harnesses not only the
formalisms from which they were derived but also the intellectual investment that experts
have made in these representation mechanisms and their associated toolsets. The output
of the Template process is a singe formalism which could be represented in any suitable
Knowledge Representation (KR) system but which we will present examples from the
Web Ontology Language (OWL). Thus, we present a single formalism for integrating
KR from UML models (CDA given as an example), Clinical Structures (ADL
Archetypes given as an example), and terminologies (SNOMED-CT given as an
example).
HL7 Template and Archetype Architecture
Template Special Interest Group
25
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
CDA Level 2 Model
OWL Representation of the CDA Level 2 Model
<?xml version="1.0"?>
<rdf:RDF
xmlns="http://a.com/ontology#"
xmlns:protege="http://protege.stanford.edu/plugins/owl/protege#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:daml="http://www.daml.org/2001/03/daml+oil#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xml:base="http://a.com/ontology">
<owl:Ontology rdf:about="">
<owl:imports
rdf:resource="http://protege.stanford.edu/plugins/owl/protege"/>
</owl:Ontology>
<owl:Class rdf:ID="AssignedEntity">
<rdfs:subClassOf>
<owl:Restriction>
<owl:maxCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:maxCardinality>
<owl:onProperty>
<owl:FunctionalProperty rdf:about="#has_person"/>
HL7 Template and Archetype Architecture
Template Special Interest Group
26
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Class rdf:ID="CDA_level2"/>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:maxCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:maxCardinality>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_organization"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID="participant">
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
<rdfs:subClassOf>
<owl:Class rdf:about="#ParticipatingEntity"/>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID="NonXMLBody">
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
</owl:Class>
<owl:Class rdf:ID="recordTarget">
<rdfs:subClassOf>
<owl:Class rdf:about="#PatientRole"/>
</rdfs:subClassOf>
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
</owl:Class>
<owl:Class rdf:ID="Person">
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
</owl:Class>
<owl:Class rdf:ID="consent">
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
</owl:Class>
<owl:Class rdf:ID="Organization">
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
</owl:Class>
<owl:Class rdf:ID="Author">
<rdfs:subClassOf>
<owl:Class rdf:about="#AssignedAuthor"/>
</rdfs:subClassOf>
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
</owl:Class>
<owl:Class rdf:ID="RelatedSubject">
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:maxCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:maxCardinality>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_SubjectPerson"/>
HL7 Template and Archetype Architecture
Template Special Interest Group
27
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID="Custodian">
<rdfs:subClassOf>
<owl:Class rdf:about="#AssignedCustodian"/>
</rdfs:subClassOf>
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
</owl:Class>
<owl:Class rdf:ID="component">
<rdfs:subClassOf rdf:resource="#NonXMLBody"/>
<rdfs:subClassOf>
<owl:Class rdf:about="#SructuredBody"/>
</rdfs:subClassOf>
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
</owl:Class>
<owl:Class rdf:ID="subject">
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
</owl:Class>
<owl:Class rdf:ID="CurrentEncounter">
<rdfs:subClassOf>
<owl:Restriction>
<owl:maxCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:maxCardinality>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_location"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_ComponentOf"/>
</owl:onProperty>
<owl:maxCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID="ParticipatingEntity">
<rdfs:subClassOf>
<owl:Restriction>
<owl:maxCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:maxCardinality>
<owl:onProperty>
<owl:FunctionalProperty rdf:about="#has_person"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
<rdfs:subClassOf>
HL7 Template and Archetype Architecture
Template Special Interest Group
28
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
<owl:Restriction>
<owl:maxCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:maxCardinality>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_organization"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID="entry">
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
</owl:Class>
<owl:Class rdf:ID="Event">
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
</owl:Class>
<owl:Class rdf:ID="location">
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
<rdfs:subClassOf>
<owl:Class rdf:about="#Health_care_facility"/>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID="authorization">
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
<rdfs:subClassOf rdf:resource="#consent"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:minCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>0</owl:minCardinality>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_Authorization"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID="intendedRecipient">
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_recipient"/>
</owl:onProperty>
<owl:maxCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_organization"/>
</owl:onProperty>
<owl:maxCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:maxCardinality>
HL7 Template and Archetype Architecture
Template Special Interest Group
29
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID="Birthplace">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_birthplace"/>
</owl:onProperty>
<owl:someValuesFrom>
<owl:Class rdf:about="#Place"/>
</owl:someValuesFrom>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
</owl:Class>
<owl:Class rdf:ID="Order">
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
</owl:Class>
<owl:Class rdf:ID="inFulfillmentOf">
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
<rdfs:subClassOf rdf:resource="#Order"/>
</owl:Class>
<owl:Class rdf:ID="PatientRole">
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
</owl:Class>
<owl:Class rdf:ID="Health_care_facility">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_place"/>
</owl:onProperty>
<owl:maxCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_organization"/>
</owl:onProperty>
<owl:maxCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID="legalAuthenticator">
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
<rdfs:subClassOf rdf:resource="#AssignedEntity"/>
</owl:Class>
<owl:Class rdf:ID="encounterPerformer">
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
<rdfs:subClassOf rdf:resource="#AssignedEntity"/>
HL7 Template and Archetype Architecture
Template Special Interest Group
30
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
<rdfs:subClassOf>
<owl:Restriction>
<owl:minCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:minCardinality>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_encounterPerformer"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID="documentOf">
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
<rdfs:subClassOf rdf:resource="#Event"/>
</owl:Class>
<owl:Class rdf:ID="parentDocument">
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
</owl:Class>
<owl:Class rdf:ID="SructuredBody">
<rdfs:subClassOf>
<owl:Restriction>
<owl:minCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:minCardinality>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_component"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
</owl:Class>
<owl:Class rdf:ID="Authoring_device">
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
</owl:Class>
<owl:Class rdf:ID="Authenticator">
<rdfs:subClassOf rdf:resource="#AssignedEntity"/>
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
</owl:Class>
<owl:Class rdf:ID="MaintainedEntity">
<rdfs:subClassOf>
<owl:Restriction>
<owl:minCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>0</owl:minCardinality>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_Authorchoice"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:FunctionalProperty rdf:about="#has_person"/>
</owl:onProperty>
HL7 Template and Archetype Architecture
Template Special Interest Group
31
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
<owl:cardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID="CustodianOrganization">
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
</owl:Class>
<owl:Class rdf:ID="responsibleParty">
<rdfs:subClassOf rdf:resource="#AssignedEntity"/>
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
</owl:Class>
<owl:Class rdf:ID="ClinicalDocument">
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:cardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:cardinality>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_custodian"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:minCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>0</owl:minCardinality>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_participant"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_informant"/>
</owl:onProperty>
<owl:minCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>0</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:maxCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:maxCardinality>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_dataEnterer"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
HL7 Template and Archetype Architecture
Template Special Interest Group
32
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
<owl:Restriction>
<owl:minCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>0</owl:minCardinality>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_informationRecipient"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:minCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>0</owl:minCardinality>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_inFulfillmentOf"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_Author"/>
</owl:onProperty>
<owl:minCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:minCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:minCardinality>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_record_target"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_assignedEntity"/>
</owl:onProperty>
<owl:minCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>0</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_legalAuthenticator"/>
</owl:onProperty>
<owl:maxCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
HL7 Template and Archetype Architecture
Template Special Interest Group
33
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
>1</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_responsible_party"/>
</owl:onProperty>
<owl:maxCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:minCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>0</owl:minCardinality>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_authenticator"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_component"/>
</owl:onProperty>
<owl:cardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_relatedDocument"/>
</owl:onProperty>
<owl:minCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>0</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:minCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>0</owl:minCardinality>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_documentOf"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID="Place">
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
HL7 Template and Archetype Architecture
Template Special Interest Group
34
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
</owl:Class>
<owl:Class rdf:ID="informationRecipient">
<rdfs:subClassOf rdf:resource="#intendedRecipient"/>
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
</owl:Class>
<owl:Class rdf:ID="Patient">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_guardian"/>
</owl:onProperty>
<owl:minCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>0</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_LanguageCommunication"/>
</owl:onProperty>
<owl:minCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>0</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_birthplace"/>
</owl:onProperty>
<owl:maxCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID="informant">
<rdfs:subClassOf>
<owl:Class rdf:about="#relatedEntity"/>
</rdfs:subClassOf>
<rdfs:subClassOf rdf:resource="#AssignedEntity"/>
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
</owl:Class>
<owl:Class rdf:ID="dataEnterer">
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
<rdfs:subClassOf rdf:resource="#AssignedEntity"/>
</owl:Class>
<owl:Class rdf:ID="relatedDocument">
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
<rdfs:subClassOf rdf:resource="#parentDocument"/>
</owl:Class>
<owl:Class rdf:ID="Guardian">
<rdfs:subClassOf>
<owl:Restriction>
HL7 Template and Archetype Architecture
Template Special Interest Group
35
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
<owl:cardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:cardinality>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#is_guardian"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
</owl:Class>
<owl:Class rdf:ID="Section">
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:minCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>0</owl:minCardinality>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_Author"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:maxCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:maxCardinality>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_Subject"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:minCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>0</owl:minCardinality>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_component"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_informant"/>
</owl:onProperty>
<owl:minCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>0</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_entry"/>
HL7 Template and Archetype Architecture
Template Special Interest Group
36
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
</owl:onProperty>
<owl:minCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>0</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID="relatedEntity">
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:maxCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:maxCardinality>
<owl:onProperty>
<owl:FunctionalProperty rdf:about="#has_person"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID="AssignedCustodian">
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_Custodian"/>
</owl:onProperty>
<owl:cardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID="AssignedAuthor">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_Authorchoice"/>
</owl:onProperty>
<owl:maxCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#has_organization"/>
</owl:onProperty>
<owl:maxCardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
</owl:Class>
HL7 Template and Archetype Architecture
Template Special Interest Group
37
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
<owl:Class rdf:ID="health_chart">
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
</owl:Class>
<owl:Class rdf:ID="SubjectPerson">
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
</owl:Class>
<owl:Class rdf:ID="componentOf">
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
<rdfs:subClassOf rdf:resource="#ClinicalDocument"/>
</owl:Class>
<owl:Class rdf:ID="LanguageCommunication">
<rdfs:subClassOf rdf:resource="#CDA_level2"/>
</owl:Class>
<owl:ObjectProperty rdf:ID="has_inFulfillmentOf">
<rdfs:domain rdf:resource="#inFulfillmentOf"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="has_recipient">
<rdfs:domain>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Person"/>
<owl:Class rdf:about="#health_chart"/>
</owl:unionOf>
</owl:Class>
</rdfs:domain>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="has_component">
<rdfs:domain>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#component"/>
</owl:unionOf>
</owl:Class>
</rdfs:domain>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="has_Custodian">
<rdfs:domain rdf:resource="#CustodianOrganization"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="has_authenticator">
<rdfs:domain rdf:resource="#Authenticator"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="has_ComponentOf">
<rdfs:domain rdf:resource="#componentOf"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="has_assignedEntity">
<protege:allowedParent rdf:resource="#AssignedEntity"/>
<rdfs:range rdf:resource="http://www.w3.org/2002/07/owl#Class"/>
<rdfs:domain>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#legalAuthenticator"/>
<owl:Class rdf:about="#Authenticator"/>
</owl:unionOf>
</owl:Class>
</rdfs:domain>
</owl:ObjectProperty>
HL7 Template and Archetype Architecture
Template Special Interest Group
38
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
<owl:ObjectProperty rdf:ID="has_LanguageCommunication">
<rdfs:domain rdf:resource="#LanguageCommunication"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="has_encounterPerformer">
<rdfs:domain rdf:resource="#encounterPerformer"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="has_responsible_party">
<rdfs:domain rdf:resource="#AssignedEntity"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="has_Subject">
<rdfs:domain rdf:resource="#subject"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="has_participant">
<rdfs:domain rdf:resource="#ParticipatingEntity"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="has_dataEnterer">
<rdfs:domain rdf:resource="#AssignedEntity"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="has_Authorchoice">
<rdfs:domain>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Person"/>
<owl:Class rdf:about="#Authoring_device"/>
</owl:unionOf>
</owl:Class>
</rdfs:domain>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="has_Author">
<rdfs:domain rdf:resource="#AssignedAuthor"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="has_custodian">
<rdfs:domain rdf:resource="#AssignedCustodian"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="has_birthplace">
<rdfs:domain rdf:resource="#Birthplace"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="has_organization">
<rdfs:domain rdf:resource="#Organization"/>
<rdf:type
rdf:resource="http://www.w3.org/2002/07/owl#FunctionalProperty"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="has_guardian">
<rdfs:range rdf:resource="#Guardian"/>
<rdfs:domain rdf:resource="#Patient"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="has_relatedDocument">
<rdfs:domain rdf:resource="#relatedDocument"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="has_legalAuthenticator">
<rdfs:domain rdf:resource="#legalAuthenticator"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="has_informant">
<rdfs:domain>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
HL7 Template and Archetype Architecture
Template Special Interest Group
39
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
<owl:Class rdf:about="#AssignedEntity"/>
<owl:Class rdf:about="#relatedEntity"/>
</owl:unionOf>
</owl:Class>
</rdfs:domain>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="has_entry">
<rdfs:domain rdf:resource="#entry"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="has_record_target">
<rdfs:domain rdf:resource="#PatientRole"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="has_documentOf">
<rdfs:domain rdf:resource="#documentOf"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="is_guardian">
<rdfs:domain>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Person"/>
<owl:Class rdf:about="#Organization"/>
</owl:unionOf>
</owl:Class>
</rdfs:domain>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="has_place">
<rdfs:domain rdf:resource="#Place"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="has_informationRecipient">
<rdfs:domain rdf:resource="#intendedRecipient"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="has_SubjectPerson">
<rdfs:domain rdf:resource="#SubjectPerson"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="has_Authorization">
<rdfs:domain rdf:resource="#authorization"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="has_location">
<rdfs:domain rdf:resource="#location"/>
</owl:ObjectProperty>
<owl:DatatypeProperty rdf:ID="id">
<rdfs:range
rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="classCode">
<rdfs:domain rdf:resource="#ClinicalDocument"/>
<rdfs:range
rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="class_code">
<rdfs:range
rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
<rdfs:domain>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Person"/>
HL7 Template and Archetype Architecture
Template Special Interest Group
40
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
<owl:Class rdf:about="#Organization"/>
<owl:Class rdf:about="#health_chart"/>
<owl:Class rdf:about="#Place"/>
<owl:Class rdf:about="#CustodianOrganization"/>
<owl:Class rdf:about="#Authoring_device"/>
<owl:Class rdf:about="#Patient"/>
<owl:Class rdf:about="#Birthplace"/>
<owl:Class rdf:about="#Guardian"/>
<owl:Class rdf:about="#MaintainedEntity"/>
<owl:Class rdf:about="#AssignedEntity"/>
<owl:Class rdf:about="#intendedRecipient"/>
<owl:Class rdf:about="#AssignedAuthor"/>
<owl:Class rdf:about="#AssignedCustodian"/>
<owl:Class rdf:about="#PatientRole"/>
<owl:Class rdf:about="#ParticipatingEntity"/>
<owl:Class rdf:about="#relatedEntity"/>
</owl:unionOf>
</owl:Class>
</rdfs:domain>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="moodCode">
<rdfs:domain rdf:resource="#ClinicalDocument"/>
<rdfs:range
rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="telecom">
<rdfs:range
rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="name">
<rdfs:range
rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="addr">
<rdfs:range
rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="determiner_code">
<rdfs:domain>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Person"/>
<owl:Class rdf:about="#Organization"/>
<owl:Class rdf:about="#health_chart"/>
<owl:Class rdf:about="#Place"/>
<owl:Class rdf:about="#CustodianOrganization"/>
<owl:Class rdf:about="#Authoring_device"/>
<owl:Class rdf:about="#Patient"/>
</owl:unionOf>
</owl:Class>
</rdfs:domain>
<rdfs:range
rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
</owl:DatatypeProperty>
<owl:FunctionalProperty rdf:ID="has_person">
<rdfs:domain rdf:resource="#Person"/>
HL7 Template and Archetype Architecture
Template Special Interest Group
41
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
<rdf:type
rdf:resource="http://www.w3.org/2002/07/owl#ObjectProperty"/>
</owl:FunctionalProperty>
</rdf:RDF>
<!-- Created with Protege (with OWL Plugin 1.2 beta, Build 139)
http://protege.stanford.edu -->
HL7 Template and Archetype Architecture
Template Special Interest Group
42
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
Archetype Constraint Model
HL7 Template and Archetype Architecture
Template Special Interest Group
43
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
HL7 Template and Archetype Architecture
Template Special Interest Group
44
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
Adverse Reaction Archetype
archetype
openEHR-EHR-EVALUATION.adverse_reaction.v1
concept
[at0000]
-- Adverse reaction
description
author = <"Koray Atalað <[email protected]>">
status = <"draft">
version = <"1.0">
revision = <"1.0">
submission = <
organisation = <"METU Informatics Institute">
date = <"25/12/2003">
>
adl_version = <"1.1">
description("en") = <
purpose = <"Describe MST 2.0 Findings for Colon">
use = <"">
HL7 Template and Archetype Architecture
Template Special Interest Group
45
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
misuse = <"">
>
description("tr") = <
purpose = <"Kolon için MST 2.0 Bulgularý">
use = <"">
misuse = <"">
>
rights = <"">
definition
EVALUATION[at0000] matches {
-- Adverse reaction
data matches {
TREE[at0001] matches {
-- structure
items cardinality matches {0..1} matches {
ELEMENT[at0002] matches { -- Causative agent
value matches {
CODED_TEXT matches {
code matches {[ac0001]}
-- 'is_a' medication
}
}
}
ELEMENT[at0003] occurrences matches {0..1} matches {
-- Is
negated
value matches {True, False}
}
CLUSTER[at0004] occurrences matches {0..*} matches {
-- Reaction
items cardinality matches {0..1} matches {
ELEMENT[at0005] occurrences matches {0..1}
matches { -- Date of onset
value matches {yyyy-??-XX}
}
ELEMENT[at0006] occurrences matches {0..1}
matches { -- Date of resolution
value matches {yyyy-??-XX}
}
ELEMENT[at0007] occurrences matches {0..1}
matches { -- Duration
value matches {
REAL_QUANTITY matches {
property matches
{"time"}
units cardinality
matches {1} matches {
UNIT
matches {
unit_string matches {""}
magnitude matches {|<= -1|}
}
}
}
}
}
}
}
}
}
}
}
ontology
primary_language = <"en">
languages_available = <"en", ...>
term_definitions("en") = <
items("at0000") = <
text = <"Adverse reaction">
description = <"bla...">
HL7 Template and Archetype Architecture
Template Special Interest Group
46
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
>
items("at0001") = <
text = <"structure">
description = <"@ internal @">
>
items("at0002") = <
text = <"Causative agent">
description = <"The agent,substance...">
>
items("at0003") = <
text = <"Is negated">
description = <"">
>
items("at0004") = <
text = <"Reaction">
description = <"The reaction">
>
items("at0005") = <
text = <"Date of onset">
description = <"Date of onset of reaction">
>
items("at0006") = <
text = <"Date of resolution">
description = <"The date of resolution of the reaction">
>
items("at0007") = <
text = <"Duration">
description = <"*">
>
>
constraint_definitions("en") = <
items("ac0001") = <
text = <"'is_a' medication">
description = <"*">
>
>
HL7 Template and Archetype Architecture
Template Special Interest Group
47
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
Nested CDA Archetype Model
OWL Repesentation of Templates / Archetypes
The process for creation of this KR entity is to first create an OWL instantiation of the
CDA model. This is now normative and referencable by all other OWL artifacts (ref
URL for code provided). Then we built OWL support into the ADL workbench. Next
we built a Java wrapper for the ADL workbench (ref URL for code provided). Next, we
built a parser to take the OWL abstract syntax output from the ADL and build Java
objects in memory which are exposed though an API for repurposing (e.g. decision
support, OWL reasoners (e.g. JTP reasoner), etc.). Next we serialize the Abstract Owl
Java Objects as OWL:rdf output for storage or exchange (ref URL for code provided).
UML Model for Compositional Expressions
HL7 Template and Archetype Architecture
Template Special Interest Group
48
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
«framework»
Clinical Proposition
«implementation class»
Clinical Proposition::Operator
1
«refines»
«implementation class»
Clinical Proposition::Compositional Expression
0..1
1
*
«implementation class»
Operator
0..1
«refines»
«implementation class»
Concept
0..1
0..1
0..1
«implementation class»
Semantic Relation
0..1
0..1
Figure: This UML model states that clinical propositions are composed of Operators and
compositional expressions. Compositional expressions can are made up of operators,
concepts and relations which can be recursively composed to create a semantically valid
parse tree. These can be expressed as a generic Template / Archetype which can then be
used in combination with a rule base for the nomenclature to construct clinical
HL7 Template and Archetype Architecture
Template Special Interest Group
49
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
propositions for any healthcare documentation or messaging need. This consistency can
assist with normalization of the terminological representations used in HL7 Templates /
Archetypes. Further in order for the model to normalize with the terminological
representations we must map the class names and attributes from the model to the palette
of terminologies used in an HL7 v3 implementation.
Palettes of terminologies are the designated terminologies used by a group or region for
data representation. Examples include perhaps SNOMED-CT for diagnoses and
procedures, LOINC for laboratory results, and the NDF-RT for medications in the US.
Perhaps in Australia they may wish to use ICD10-AM, LOINC and the NDF-RT perhaps
with a modification. Once the normative terminologies are identified and internally
normalized, then the palette can be mapped to the RIM, CDA L2 Model and the
Templates / Archetype Model Classes and Attributes. By doing so we have effectively
normalized the information model with the terminological model.
Adverse Reaction OWL Abstract Syntax
Namespace(rdf=<http://www.w3.org/1999/02/22-rdf-syntax-ns#>)
Namespace(xsd=<http://www.w3.org/2001/XMLSchema:>)
Namespace(rdfs =<http://www.w3.org/2000/01/rdf-schema:>)
Namespace(rdfs =<http://www.w3.org/2002/07/owl#>)
Namespace(ba =<http://www.openEHR.org/base_archetype#>)
Namespace(rm =<http://www.openEHR.org/rm/release0.9#>)
Namespace(this =<http://archetypes.org/openEHR-EHREVALUATION.adverse_reaction.v1#>)
Ontology (
ObjectProperty(ba:is_about)
ObjectProperty(rm:data)
ObjectProperty(rm:items)
ObjectProperty(rm:value)
ObjectProperty(rm:code)
ObjectProperty(rm:non_primitive_object)
DatatypeProperty(rm:newvalue Functional range(xsd:string))
Class
(
this:Entry
partial
)
Class
(
HL7 Template and Archetype Architecture
Template Special Interest Group
50
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
this:Adverse_reaction
complete
this:Entry
)
Class
(
this:structure
complete
restriction
(
ba:is_about
allValuesFrom
(
this:at0001
)
)
)
Class
(
this:structure
complete
restriction
(
ba:is_about
allValuesFrom
(
this:at0001
)
)
)
Class
(
this:Causative_agent
complete
restriction
(
ba:is_about
allValuesFrom
(
HL7 Template and Archetype Architecture
Template Special Interest Group
51
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
this:at0002
)
)
)
Class
(
this:Causative_agent
partial
rm:ELEMENT
restriction
(
rm:value
allValuesFrom
(
intersectionOf
(
rm:CODED_TEXT
restriction
(
rm:code
allValuesFrom(this:ac0001)
)
)
)
)
)
Class
(
this:Is_negated
complete
restriction
(
ba:is_about
allValuesFrom(this:at0003)
)
)
Class
(
this:Is_negated
partial
HL7 Template and Archetype Architecture
Template Special Interest Group
52
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
rm:ELEMENT
restriction
(
rm:value
allValuesFrom
(
intersectionOf
(
rm:BOOLEAN restriction(rm:newvalue
value("False"^^xsd:string))
)
)
)
)
Class
(
this:Classification
complete
restriction
(
ba:is_about
allValuesFrom(this:at0010)
)
)
Class
(
this:Classification
partial
rm:ELEMENT
restriction
(
rm:value
allValuesFrom
(
intersectionOf
(
rm:CODED_TEXT
restriction(rm:code
allValuesFrom(rm:non_primitive_object))
)
)
)
)
HL7 Template and Archetype Architecture
Template Special Interest Group
53
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
Class
(
this:Reaction
complete
restriction
(
ba:is_about
allValuesFrom
(
this:at0004
)
)
)
Class
(
this:Reaction
partial
rm:CLUSTER
restriction
(
rm:items
someValuesFrom(this:Type_of_reaction)
)
restriction
(
rm:items
someValuesFrom(this:Date_of_onset)
)
restriction
(
rm:items
someValuesFrom(this:Severity)
)
restriction
(
rm:items
someValuesFrom(this:Date_of_resolution)
)
restriction
(
rm:items
someValuesFrom(this:Duration)
)
HL7 Template and Archetype Architecture
Template Special Interest Group
54
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
)
Class
(
this:Type_of_reaction
complete
restriction
(
ba:is_about
allValuesFrom
(
this:at0008
)
)
)
Class
(
this:Type_of_reaction
partial
rm:ELEMENT
restriction
(
rm:value
allValuesFrom
(
intersectionOf
(
rm:CODED_TEXT
restriction
(
rm:code
allValuesFrom
(
this:ac0002
)
)
)
)
)
)
Class
(
HL7 Template and Archetype Architecture
Template Special Interest Group
55
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
this:Date_of_onset
complete
restriction
(
ba:is_about
allValuesFrom
(
this:at0005
)
)
)
Class
(
this:Date_of_onset
partial
rm:ELEMENT
restriction(rm:newvalue value("yyyy-??-XX"^^xsd:string))
)
Class
(
this:Severity
complete
restriction
(
ba:is_about
allValuesFrom
(
this:at0014
)
)
)
Class(this:Severity partial rm:ELEMENT
restriction(rm:newvalue value("$object:at0014:value$"^^xsd:string))
)
Class
(
this:Date_of_resolution
complete
restriction
(
HL7 Template and Archetype Architecture
Template Special Interest Group
56
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
ba:is_about
allValuesFrom
(
this:at0006
)
)
)
Class
(
this:Date_of_resolution
partial
rm:ELEMENT
restriction(rm:newvalue value("yyyy-??-XX"^^xsd:string))
)
Class
(
this:Duration
complete
restriction
(
ba:is_about
allValuesFrom(this:at0007)
)
)
Class
(
this:Duration
partial
rm:ELEMENT
restriction(rm:newvalue value("|>= P0s|"^^xsd:string))
)
Class
(
this:Certainty
complete
restriction
(
ba:is_about
allValuesFrom
(
this:at0019
HL7 Template and Archetype Architecture
Template Special Interest Group
57
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
)
)
)
Class
(
this:Certainty
partial
rm:ELEMENT
restriction
(
rm:value
allValuesFrom
(
intersectionOf
(
rm:CODED_TEXT
restriction(rm:code
allValuesFrom(rm:non_primitive_object))
)
)
)
)
Class
(
this:Notes
partial
rm:ELEMENT
restriction
(
rm:value
allValuesFrom
(
intersectionOf(rm:TEXT)
)
)
)
Class
(
this:Notes
complete
restriction
(
ba:is_about
HL7 Template and Archetype Architecture
Template Special Interest Group
58
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
allValuesFrom(this:at0022)
)
)
)
Adverse Event Archetype linked to the CDA Level 2 Model OWL:rdf
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE rdf:RDF [
<!ENTITY owl "http://www.w3.org/2002/07/owl#">
<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">
]>
<rdf:RDF xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
xmlns:people="http://cohse.semanticweb.org/ontologies/people#"
xmlns:pp="http://cohse.semanticweb.org/ontologies/people#"
xml:base="http://www.example.org/ontology"
xmlns="http://www.example.org/ontology#">
<owl:Ontology rdf:about="">
<rdfs:comment>OWL ontology</rdfs:comment>
</owl:Ontology>
<!-- ANNOTATIONS -->
<!-- CLASSESS -->
<owl:Class rdf:ID="Reaction">
<owl:Restriction>
<owl:onProperty rdf:resource="#is_about"/>
<owl:allValuesFrom>
<owl:Class rdf:about="#at0004"/>
</owl:allValuesFrom>
</owl:Restriction>
</owl:Class>
<owl:Class rdf:ID="structure">
<owl:Restriction>
<owl:onProperty rdf:resource="#is_about"/>
<owl:allValuesFrom>
<owl:Class rdf:about="#at0001"/>
</owl:allValuesFrom>
</owl:Restriction>
<owl:Restriction>
<owl:onProperty rdf:resource="#is_about"/>
<owl:allValuesFrom>
HL7 Template and Archetype Architecture
Template Special Interest Group
59
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
<owl:Class rdf:about="#at0001"/>
</owl:allValuesFrom>
</owl:Restriction>
</owl:Class>
<owl:Class rdf:ID="Date_of_resolution">
<owl:Restriction>
<owl:onProperty rdf:resource="#is_about"/>
<owl:allValuesFrom>
<owl:Class rdf:about="#at0006"/>
</owl:allValuesFrom>
</owl:Restriction>
</owl:Class>
<owl:Class rdf:ID="Type_of_reaction">
<owl:Restriction>
<owl:onProperty rdf:resource="#is_about"/>
<owl:allValuesFrom>
<owl:Class rdf:about="#at0008"/>
</owl:allValuesFrom>
</owl:Restriction>
</owl:Class>
<owl:Class rdf:ID="Causative_agent">
<owl:Restriction>
<owl:onProperty rdf:resource="#is_about"/>
<owl:allValuesFrom>
<owl:Class rdf:about="#at0002"/>
</owl:allValuesFrom>
</owl:Restriction>
</owl:Class>
<owl:Class rdf:ID="Classification">
<owl:Restriction>
<owl:onProperty rdf:resource="#is_about"/>
<owl:allValuesFrom>
<owl:Class rdf:about="#at0010"/>
</owl:allValuesFrom>
</owl:Restriction>
</owl:Class>
<owl:Class rdf:ID="Adverse_reaction">
<rdfs:subClassOf>
<owl:Class rdf:about="Entry"/>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID="Date_of_onset">
<owl:Restriction>
<owl:onProperty rdf:resource="#is_about"/>
<owl:allValuesFrom>
<owl:Class rdf:about="#at0005"/>
HL7 Template and Archetype Architecture
Template Special Interest Group
60
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
</owl:allValuesFrom>
</owl:Restriction>
</owl:Class>
<owl:Class rdf:ID="Severity">
<owl:Restriction>
<owl:onProperty rdf:resource="#is_about"/>
<owl:allValuesFrom>
<owl:Class rdf:about="#at0014"/>
</owl:allValuesFrom>
</owl:Restriction>
</owl:Class>
<owl:Class rdf:ID="Is_negated">
<owl:Restriction>
<owl:onProperty rdf:resource="#is_about"/>
<owl:allValuesFrom>
<owl:Class rdf:about="#at0003"/>
</owl:allValuesFrom>
</owl:Restriction>
</owl:Class>
<owl:Class rdf:ID="Certainty">
<owl:Restriction>
<owl:onProperty rdf:resource="#is_about"/>
<owl:allValuesFrom>
<owl:Class rdf:about="#at0019"/>
</owl:allValuesFrom>
</owl:Restriction>
</owl:Class>
<owl:Class rdf:ID="Duration">
<owl:Restriction>
<owl:onProperty rdf:resource="#is_about"/>
<owl:allValuesFrom>
<owl:Class rdf:about="#at0007"/>
</owl:allValuesFrom>
</owl:Restriction>
</owl:Class>
<owl:Class rdf:ID="Notes">
<owl:Restriction>
<owl:onProperty rdf:resource="#is_about"/>
<owl:allValuesFrom>
<owl:Class rdf:about="#at0022"/>
</owl:allValuesFrom>
</owl:Restriction>
</owl:Class>
<!-- INDIVIDUALS -->
<!-- CLASS AXIOMS -->
<!-- PROPERTY AXIOMS -->
HL7 Template and Archetype Architecture
Template Special Interest Group
61
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
<!-- DATA TYPES -->
<!-- OBJECT PROPERTIES -->
<owl:ObjectProperty rdf:ID="is_about"/>
<owl:ObjectProperty rdf:ID="data"/>
<owl:ObjectProperty rdf:ID="items"/>
<owl:ObjectProperty rdf:ID="non_primitive_object"/>
<owl:ObjectProperty rdf:ID="code"/>
<owl:ObjectProperty rdf:ID="value"/>
<!-- DATA PROPERTIES -->
<owl:DataTypeProperty rdf:ID="newvalue">
<rdf:type rdf:resource="&owl;FunctionalProperty"/>
<rdfs:range
rdf:resource="#http://www.w3.org/2001/XMLSchema:string"/>
</owl:DataTypeProperty>
</rdf:RDF>
7 Overview
8.5 Goals of ADL
Archetypes are used at runtime to validate data as they are created or modified. All data
created with archetypes is stamped with the archetype identifier, and the identifier of
every node of the archetype, in the relevant place in the data. The result is that stored data
are “always correct” with respect to its archetypes.
ADL provides a completely formal way of writing archetypes, allowing both machine
processing and human readability. Its key characteristic is that it is completely separate
from software and database schemata, enabling its use (with tools) by domain experts.
8.4.8 Goals of OWL
Subsumptive reasoning that can support closed and open world assumptions.
8.4.8 Architectural Overview
The key to understanding how to map archetypes into an OWL ontology is to remember
that an archetype is basically a set of constraint statements with respect to a reference
model. In an OWL environment, archetype constraints need to be expressed in relation to
an ontological “model”, which in the case of an archetype, will be an OWL expression of
an object model. As a consequence, expressing an archetype or a family of archetypes in
OWL requires the appropriate reference model to be completely converted first. FIGURE
1 shows a general architecture in which two kinds of conversion are needed: object model
(e.g. UML, IDL or similar expression) to OWL, and ADL to OWL.
The result of such a conversion is an OWL ontology, expressed in the OWL abstract
syntax. This can then be converted as needed to the concrete RDF-based exchange
syntax, shown on the lower right.
HL7 Template and Archetype Architecture
Template Special Interest Group
62
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
FIGURE 1 OM+ADL/OWL interoperability architecture
8.4.8
Object Model / OWL Mapping
..1.1 Rules
package MM -> for each used package, current package ->
Namespace (“mm = URL#”)
class XXXX ->
Class(“XXXX” partial|complete
each attr aaaa cardinality/existence ->
restriction(“nm:aaaa” cardinality(xx))
)
Each relationship rrrr:YYYY ->
ObjectProperty(“nm:rrrr” domain(“#XXXX”) range
(“nm:YYYY”))
Each attribute aaaa:ZZZZ ->
DatatypeProperty(“nm:aaaa” domain(“#XXXX”)range (Type
| literal enumeration))
HL7 Template and Archetype Architecture
Template Special Interest Group
63
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
8.4.4
ADL / OWL Mapping
..2.1 Example
}
-------- “substituted archetype” : sub terms, choose lang,
terminology-----to be determined
-------- OWL DL -----// Assume the following:
HL7 Template and Archetype Architecture
Template Special Interest Group
64
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
// Begin Archetype
HL7 Template and Archetype Architecture
Template Special Interest Group
65
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
HL7 Template and Archetype Architecture
Template Special Interest Group
66
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
8.5 Mapping Rules
Archetype Description (meta-data) Mapping
This can be converted to OWL Annotations
Class Definition
Each ADL object node generates an OWL Class() declaration
The ADL path (not just the node id) is used to generate the OWL Class id - this is
because archetypes act like a compositional vocabulary - the meaning of a node deep in
HL7 Template and Archetype Architecture
Template Special Interest Group
67
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
the hierarchy is given by the composition of the terms on the node leading to it. This
gives rise to Class names in OWL like:
AdverseReaction_Description_items_Reaction_items_DateOfResolution
There may be ways of shortening this in some circumstances, but the above is what
would be machine generatable.
The alternative is to assume that each node meaning is global within the archetype and
just use these meanings as the OWL Class ids. This is generally dangerous, just as it
would be for un-coordinated terms - “blood glucose” is not the same as “measured blood
glucose” or “reference blood glucose”.
Restrictions can be added to OWL class declarations indicating the existence/cardinality
of the property in the archetype - but note: it seems that multiple restrictions are needed
to cope with the ‘occurrences’ keyword in ADL (note where it occurs - not the same
information as ‘cardinality’).
8.4.8 Object Property Definition
Each object property in an archetype generates an OWL ObjectProperty() declaration.
With a domain() declaration for the owning class id in the archetype, and a range()
declaration for the types of all objects found in the archetype under that attribute. Note
that this is not the same as what is in the reference model. E.g. the reference model says:
class TREE
items: ITEM
end
abstract class ITEM
...
End
class ELEMENT
inherit ITEM
end
class CLUSTER
inherit ITEM
end
HL7 Template and Archetype Architecture
Template Special Interest Group
68
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
But the archetype says:
TREE[at0001]
items
ELEMENT[at0002]
ELEMENT[at0003]
CLUSTER[at0004]
8.4.8 Clinical Data type Definition
OWL has no direct support for the clinical types:
clinical_attr matches {
CODED_TEXT matches {
code matches {
[local::
at0111,
at0112,
at0113,
at0114,
at0115]
}
}
}
Or ordinals:
clinical_ordinal_attr matches {
0|[local::at0001],
1|[local::at0002],
2|[local::at0003]
}
However this can probably be managed.
8.4.8 Primitive Data type Definition
OWL supports almost none of the required constraints for leaf data types. E.g. :
xxx matches {/some regex/} -- regular expression
• xxx matches {|80..120|} -- integer range
• xxx matches {|>=0|} -- integer range
• xxx matches {|100 +/-20|} -- integer range
• xxx matches {|1.3..1.5|} -- real range
• xxx matches {|>=0.5|} -- real range
•
HL7 Template and Archetype Architecture
Template Special Interest Group
69
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
• xxx matches {|10.0 +/-1.0|} -- real range
• xxx matches {False} -- subset of boolean values
• xxx matches {yyyy-mm-dd} -- date
• xxx matches {yyyy-??-xx} -- partial date - months optional, days not allowed
• xxx matches {hh:mm:xx} -- partial time - no seconds allowed
• xxx matches {|P1h30m..P1h45m|} -- range of durations (ISO8601 format)
8.4.8 Archetype Ontology Mapping
....
Archetypes for the Semantic Web: the ADL / OWL Mapping Comparative Semantics of OWL and ADL Rev
0.5
8.5 Comparative Semantics of OWL and ADL
ADL is contextual & nested, OWL is not
ADL contains OCL-like invariant statements
OWL does not (yet?) do range constraints on numeric or date types
what does “partial” and “complete” really mean?
OWL method of defining domains & ranges won’t work with OO systems
In general, OWL assumes all references are in a global id space, whereas in OO models,
names of things like attributes and classes are always in context of classes & packages,
respectively. So the problem is that to associated an attribute e.g. “value” of type “String”
in OWL, with its class, we would write:
ObjectProperty(“value” domain(unionOf(“TYPE_A”, “TYPE_B”, etc)) range(“String”))
The problem here is that the attributes “value:STRING” in TYPE_A and TYPE_B might
have nothing at all to do wiht each other - one might be a URI string inside a class URI,
the other might be a term code inside a CODED_TERM class.
e.g. also DV_BOOLEAN.value - is a Boolean, not a String so how to name it in the
ontology.
HL7 Template and Archetype Architecture
Template Special Interest Group
70
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
Table 1.Conformance Profiles, Templates and archetypes and ebXML strawman
mappings
Metadata
Element Type
Identification
Template and
archetype
Element
identifier (1)
Description
Conformance
Element
Description
ebXML
Globally unique identifier of
the resource. (Assigned by the
registry when the template
and archetype is submitted)
HL7OID
The ASN1
identifier for the
instance of the
message profile.
(Can be assigned
by registry or can
come from
submitting org’s
OID namespace)
RegistryObject.id
(UUID)
fragment id (1)
Identifies the fragment that
was constrained to create this
template and archetype. 7
SpecName
Provides a name
that clearly and
concisely defines
the exchange
RegistryObject.name
(InternationalString)
core code (?)
title (+)
7
HL7 will create a library of
“fragments” which are pieces
of normative specifications
that can be imported into an
authoring environment and
constrained. These fragments
are as large as complete
specifications, and can be as
small as individual CMETs
and clones.
Within the HL7 library of
templatable fragments is an
association table that
indicates the HL7
specifications that contain the
fragments. Thus, when a user
creates a template and
archetype, the HL7
specification to which the
template and archetype is
applicable is known. In
addition, a user can query the
library for all templatable
fragments of any HL7
specification.
This is the value of the cd
attribute of the base class of
the template and archetype.
Note that this attribute best
captures the “essence” of a
clinical template and
archetype. For instance, a
CBC template and archetype
will have a code for “CBC” in
the base class observation.cd
field.
The name given to the
resource.
description (?)
A textual description of the
content of the resource
Comment
format (1)
The data format of the
template and archetype before
<none> ?
Always XML
RegistryObject.descripti
on
(InternationalString)
Repository.objectType
(ebXML has a
does it include the version number ?
HL7 Template and Archetype Architecture
Template Special Interest Group
71
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
it is transformed into the HL7
template and archetype
formalism.
Organization
submitting_entity
(1)
package_documen
tation_URL
template and
archetype_docume
ntation_URL
creator (+)
OrgName
Submitter
organization
?
Organization (class)
Submitter’s name
User.personName
(PersonName)
?
Submitter
(First Name,
Last Name)
Email
Submitter’s email
?
Phone
Submitter’s phone
?
Fax
?
For More
Information
Submitter’s Fax
number
URI to provide
more information
on profile
(proposed)
same as
Submitter?
User.emalAddresses
(Collection of
EmailAddress)
User.telephoneNumbers
(Collection of
TelephoneNumber)
User.telephoneNumbers
technical_contact
(*)
content_contact
(*)
The person or department to
be contacted for content
issues related to the resource.
Organization that has
reviewed the resource, and
agrees that it is suitable for
clinical use. (Note –
resources can be approved by
organizations other than the
one the author is affiliated
with.)
The date this resource was
first available for production
use in HL7.
The date this resource was
first available on HL7.
(Enables the automatic
generation of a "what's new"
list.)
The dates this resource has
been reviewed or revised.
?
date.will_expire
(?)
The date the intellectual
content of this resource will
expire.
?
modification_histo
ry ?)
A list of changes from the
previous version.
? (could be in
Comments)
approving_body
(+)
Life cycle
The entity submitting and/or
maintaining the resource in
the HL7 repository.
the URL to download the
supporting documentation
about the package of
templates and archetypes
the URL to download the
specific supporting
documentation about the
template and archetype
The person or organization
primarily responsible for
creating the intellectual
content of the resource.
The person or department to
be contacted for technical
issues related to the resource.
predefined set that can
be extended, e.g.
UMLModel,
XMLSchema,
ExternalLink)
Organization (class)
date.first_in_effect
(1)
date.available (1)
date.revised (*)
HL7 Template and Archetype Architecture
Template Special Interest Group
HL7 Affiliate
( maybe )
Date
?
?
? ExternalLink (class)
User.personName
(PersonName)
Organization (class)
First submittal
date
RegistryObject.Auditabl
eEvent.timestamp (with
eventType = Created)
RegistryObject.Auditabl
eEvent.timestamp (with
eventType = Created ?)
RegistryObject.Auditabl
eEvent.timestamp (with
eventType = Updated)
RegistryObject.Auditabl
eEvent.timestamp (with
eventType =
Deprecated)
RegistryEntry.expiratio
n
RegistryObject.Auditabl
eEvents (but it doesn’t
seems to have way to
store text) Can use Slot
named ‘Change Log’
72
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
publication_state
(1)
This field tracks the
completion state (e.g. draft,
final) of the resource. The
value is user assigned, and
indicates the status of the
resource to the
submitting_entity.
?
RegistryObject.Registry
Entry.status (ebXML
has Submitted,
Approved, Deprecated,
and Withdrawn – how
to represent
Normative/Informative?
Can use Slot name ‘HL7
Status’

resource_state (1)
version.resource
(1)
version.metadata
(1)
Association
family_identifier
(1)
relation (*)
Draft – anticipate the
resource will be revised.

Final – resource is
stable for production
use. (“Final” is

HL7 Informative –
resource has been
balloted within HL7 as
an Informative
specification.

HL7 Normative –
resource has been
balloted within HL7 as a
Normative specification.
This field tracks the status of
resources in the registry.
Values are assigned by HL7,
and include:

Submitted – initial
status, assigned upon
uploading.

Approved – the resource
is technically valid.

Deprecated – status
when the submitter
wishes to withdraw the
resource.

Superceded – status
when the submitter
places a revised
resource in the registry.
Templates and archetypes get
a new version number when
revised.
The version of metadata used
to catalog this resource.
Every resource has a globally
unique identifier that remains
constant across revisions.
When a resource is revised

The new resource gets a
new value of identifier.

The new resource uses
the same
family_identifier as the
revised resource.

The new resource
increments the version
number of the revised
resource by 1.

The relation is “RPLC”
(for “replace”.
Represents the relationship
between the current resource
and the target resource.
HL7 Template and Archetype Architecture
Template Special Interest Group
?
Conformance has
notion of active
vs. archived
profiles
RegistryObject.Registry
Entry.status
AssociatedProfi
les
Done by
association
RegistryObject.Registry
Entry.majorVersion and
minorVersion
Does this mean a
change to the
repository’s ‘schema’ ?
RegistryObject.Registry
Entry.majorVersion and
minorVersion +1
?
AssociatedProfi
les
Association.association
Type = Replaces
AssociatedProfi
les
Association.association
Type = <whatever>
{ebXML defines
RelatedTo, HasMember,
ExternallyLinks,
Contains, EquivalentTo,
73
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
relation.references
(*)
Keywords/
Taxonomy
clinical_category
(?)
intended_use (?)
language (1)
subject.keyword
(*)
attribute_list (*)
Extends, Implements,
InstanceOf, Supercedes,
Uses, Replaces,
SubmitterOf,
ResponsibleFor,
OffersService)
Association.targetObjec
t (UUID)
The target of the references
relation is a source of
knowledge drawn upon in the
creation of this resource.
The practice setting or
organizational unit/specialty
to which this resource is
applicable.
AssociatedProfi
les
Identifies the HL7
specification(s) that this
template and archetype is
applicable to.
The language of the
intellectual content of the
resource.
The topic(s) of the resource.
?
Classification (reference
appropriate HL7 stadard
OID as external ref.)
?
The list of Entities contained
within the Template and
archetype
HL7 Version,
Message Type,
Message
Structure Type,
Trigger, Z
Trigger, Order
Control Code,
Profile Level
Classification (reference
appropriate external ISO
language standard)
Classification or Slot ?
(who comes up with
keyword or taxonomy
list?)
Items represented in
ebXML Slots ?
[These can also be
represented as
Classification nodes.
With ebXML V3.0
Content Based Queries,
these values could be
auto-populated!]
HL7 Template and Archetype Architecture
Template Special Interest Group
?
Done through the
message type
which implicitly
implies clinical
area?
Keywords
The list of fields
populated based
on the contents of
the profile [XML]
document.
Classification (can
reference external
classification scheme)
74
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
Appendices
9. OCL: GENERAL CONSTRAINTS ON HL7 ARTIFACTS
Object Constraint Language Specification
Note – Changes based on the ISO version of UML 1.4.1 (formal/03-02-04) are in this
font.
This chapter introduces and defines the Object Constraint Language (OCL), a formal
language to express side-effect-free constraints.
Contents
This chapter contains the following topics.
Topic Page
“Overview” 7-2
“Introduction” 7-3
“Relation to the UML Metamodel” 7-4
“Basic Values and Types” 7-7
“Objects and Properties” 7-12
“Collection Operations” 7-22
“The Standard OCL Package” 7-28
“Predefined OCL Types” 7-29
“Grammar” 7-45
9.1 Overview
This chapter introduces and defines the Object Constraint Language (OCL), a formal
language used to express constraints. These typically specify invariant conditions that
must hold for the system being modeled. Note that when the OCL expressions are
evaluated, they do not have side effects; that is, their evaluation cannot alter the state of
the corresponding executing system. In addition, to specifying invariants of the UML
metamodel, UML modelers can use OCL to specify application-specific constraints in
their models.
OCL is used in the UML Semantics chapter to specify the well-formedness rules of the
metaclasses comprising the UML metamodel. A well-formedness rule in the static
semantics chapters in the UML Semantics section normally contains an OCL expression,
specifying an invariant for the associated metaclass. The grammar for OCL is specified at
the end of this chapter. A parser generated from this grammar has correctly parsed all the
constraints in the UML Semantics section, a process which improved the correctness of
the specifications for OCL and UML.
9.1.1 Why OCL?
A UML diagram, such as a class diagram, is typically not refined enough to provide all
the relevant aspects of a specification. There is, among other things, a need to describe
additional constraints about the objects in the model. Such constraints are often described
in natural language. Practice has shown that this will always result in ambiguities. In
order to write unambiguous constraints, so-called formal languages have been developed.
HL7 Template and Archetype Architecture
Template Special Interest Group
75
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
The disadvantage of traditional formal languages is that they are usable to persons with a
strong mathematical background, but difficult for the average business or system modeler
to use.
OCL has been developed to fill this gap. It is a formal language that remains easy to read
and write. It has been developed as a business modeling language within the IBM
Insurance division, and has its roots in the Syntropy method. OCL is a pure expression
language; therefore, an OCL expression is guaranteed to be without side effect. When an
OCL expression is evaluated, it simply returns a value. It cannot change anything in the
model. This means that the state of the system will never change because of the
evaluation of an OCL expression, even though an OCL expression can be used to specify
a state change (for example, in a post-condition). OCL is not a programming language;
therefore, it is not possible to write program logic or flow control in OCL. You cannot
invoke processes or activate non-query operations within OCL. Because OCL is a
modeling language in the first place, not everything in it is promised to be directly
executable.
OCL is a typed language, so that each OCL expression has a type. To be well formed, an
OCL expression must conform to the type conformance rules of the language. For
example, you cannot compare an Integer with a String. Each Classifier defined within a
UML model represents a distinct OCL type. In addition, OCL includes a set of
supplementary predefined types (these are described in Section 7.8, “Predefined OCL
Types,” on page 7-29).
As a specification language, all implementation issues are out of scope and cannot be
expressed in OCL.
The evaluation of an OCL expression is instantaneous. This means that the states of
objects in a model cannot change during evaluation.
9.1.2 Where to Use OCL
OCL can be used for a number of different purposes:

To specify invariants on classes and types in the class model

To specify type invariant for Stereotypes

To describe pre- and post conditions on Operations and Methods

To describe Guards

As a navigation language
 To specify constraints on operations
Within the UML Semantics chapter, OCL is used in the well-formedness rules as
invariants on the metaclasses in the abstract syntax. In several places, it is also used to
define ‘additional’ operations which are used in the well-formedness rules. Starting with
UML 1.4, these additional operations can be formally defined using «definition»
constraints and let-expressions.
HL7 Template and Archetype Architecture
Template Special Interest Group
76
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
9.2
Introduction
9.2.1 Legend
Text written in the courier typeface as shown below is an OCL expression.
‘This is an OCL expression’
The context keyword introduces the context for the expression. The keyword inv, pre and
post denote the stereotypes, respectively «invariant», «precondition», and
«postcondition», of the constraint. The actual OCL expression comes after the colon.
context TypeName inv:
‘this is an OCL expression with stereotype <<invariant>> in the
context of TypeName’ = ‘another string’
In the example, the keywords of OCL are written in boldface in this document. The
boldface has no formal meaning, but is used to make the expressions more readable in
this document. OCL expressions in this document are written using ASCII characters
only.
Words in Italics within the main text of the paragraphs refer to parts of OCL expressions.
9.2.2 Example Class Diagram
Figure 7-1 on page 7-4 is used in the examples in this document.
Figure 7-1 Class Diagram Example
9.3
Relation to the UML Metamodel
9.3.1 Self
Each OCL expression is written in the context of an instance of a specific type. In an
OCL expression, the reserved word self is used to refer to the contextual instance. For
instance, if the context is Company, then self refers to an instance of Company.
Person
isMarried : Boolean
isUnemployed : Boolean
birthDate : Date
age : Integer
firstName : String
lastName : String
sex : Sex
income(Date) : Integer
accountNumber:Integer
Bank
0..1
customer
Company
name : String
numberOfEmployees : Integer
stockPrice() : Real
manager 0..*
HL7 Template and Archetype Architecture
Template Special Interest Group
77
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
managedCompanies
employee employer
wife
husband 0..1
0..1
0..* 0..*
Job
title : String
startDate : Date
salary : Integer
Marriage
place : String
date :
Date
male
female
«enumeration»
Sex
9.3.2 Specifying the UML context
The context of an OCL expression within a UML model can be specified through a
socalled context declaration at the beginning of an OCL expression. The context
declaration of the constraints in the following sections is shown. If the constraint is
shown in a diagram with the proper stereotype and the dashed lines to connect it to its
contextual element, there is no need for an explicit context declaration in the test of the
constraint. The context declaration is optional.
9.3.3 Invariants
The OCL expression can be part of an Invariant which is a Constraint stereotyped as an
«invariant». When the invariant is associated with a Classifier, the latter is referred to as a
“type” in this chapter. An OCL expression is an invariant of the type and must be true for
all instances of that type at any time. (Note that all OCL expressions that express
invariants are of the type Boolean.)
For example, if in the context of the Company type in Figure 7-1 on page 7-4, the
following expression would specify an invariant that the number of employees must
always exceed 50:
self.numberOfEmployees > 50
where self is an instance of type Company. (We can view self as the object from where
we start the expression.) This invariant holds for every instance of the Company type.
The type of the contextual instance of an OCL expression, which is part of an invariant, is
written with the context keyword, followed by the name of the type as follows. The label
inv: declares the constraint to be an «invariant» constraint.
context Company inv:
self.numberOfEmployees > 50
HL7 Template and Archetype Architecture
Template Special Interest Group
78
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
In most cases, the keyword self can be dropped because the context is clear, as in the
above examples. As an alternative for self, a different name can be defined playing the
part of self:
context c : Company inv:
c.numberOfEmployees > 50
This invariant is equivalent to the previous one.
Optionally, the name of the constraint may be written after the inv keyword, allowing the
constraint to be referenced by name. In the following example the name of the constraint
is enoughEmployees. In the UML metamodel, this name is an attribute of the metaclass
Constraint that is inherited from ModelElement.
context c : Company inv enoughEmployees:
c.numberOfEmployees > 50
9.3.4 Pre- and Postconditions
The OCL expression can be part of a Precondition or Postcondition, corresponding to
«precondition» and «postcondition» stereotypes of Constraint associated with an
Operation or Method. The contextual instance self then is an instance of the type that
owns the operation or method as a feature. The context declaration in OCL uses the
context keyword, followed by the type and operation declaration. The labels pre: and
post: declare the constraints to be a «precondition» constraint and a «postcondition»
constraint respectively.
context Typename::operationName(param1 : Type1, ... ): ReturnType pre : param1
> ... post: result = ...
The name self can be used in the expression referring to the object on which the operation
was called. The reserved word result denotes the result of the operation, if there is one.
The names of the parameters (param1) can also be used in the OCL expression. In the
example diagram, we can write:
context Person::income(d : Date) : Integer
post: result = 5000
Optionally, the name of the precondition or postcondition may be written after the pre or
post keyword, allowing the constraint to be referenced by name. In the following
example the name of the precondition is parameterOk and the name of the postcondition
is resultOk. In the UML metamodel, these names are attributes of the metaclass
Constraint that is inherited from ModelElement.
context Typename::operationName(param1 : Type1, ... ): ReturnType pre
parameterOk: param1 > ... post resultOk: result = ...
9.3.5 Package context
The above context declaration is precise enough when the package in which the Classifier
belongs is clear from the environment. To specify explicitly in which package invariant,
pre or postcondition Constraints belong, these constraints can be enclosed between
‘package’ and ‘endpackage’ statements. The package statements have the syntax:
package Package::SubPackage
context X inv:
... some invariant ...
HL7 Template and Archetype Architecture
79
Template Special Interest Group
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
context X::operationName(..)
pre: ... some precondition ...
endpackage
An OCL file (or stream) may contain any number package statements, thus allowing all
invariant, preconditions, and postconditions to be written down and stored in one file.
This file may co-exist with a UML model as a separate entity.
9.3.6 General Expressions
Any OCL expression can be used as the value for an attribute of the UML metaclass
Expression or one of its subtypes. In that case, the semantics section describes the
meaning of the expression.
9.4
Basic Values and Types
In OCL, a number of basic types are predefined and available to the modeler at all times.
These predefined value types are independent of any object model and part of the
definition of OCL.
The most basic value in OCL is a value of one of the basic types. Some basic types used
in the examples in this document, with corresponding examples of their values, are
shown in Table 7-1.
OCL defines a number of operations on the predefined types. Table 7-2 gives some
examples of the operations on the predefined types. See Section 7.8, “Predefined OCL
Types,” on page 7-29 for a complete list of all operations. The complete list of
operations provided for each type is described at the end of this chapter. Collection, Set,
Bag, and Sequence are basic types as well. Their specifics will be described in the
upcoming sections.
Table 7-1 Basic Types
type values
Boolean true, false
Integer 1, -5, 2, 34, 26524, ...
Real 1.5, 3.14, ...
String ‘To be or not to be...’
Table 7-2 Operations on predefined types
type operations
Integer *, +, -, /, abs()
Real *, +, -, /, floor()
Boolean and, or, xor, not, implies, if-then-else
String toUpper(), concat()
9.4.1 Types from the UML Model
Each OCL expression is written in the context of a UML model, a number of
classifiers (types/classes, ...), their features and associations, and their
generalizations. All classifiers from the UML model are types in the OCL
expressions that are attached to the model.
HL7 Template and Archetype Architecture
Template Special Interest Group
80
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
9.4.2 Enumeration Types
Enumerations are Datatypes in UML and have a name, just like any other
Classifier. An enumeration defines a number of enumeration literals, that are the
possible values of the enumeration. Within OCL one can refer to the value of an
enumeration. When we have Datatype named Sex with values ‘female’ or ‘male’
they can be used as follows:
context Person inv:
sex = Sex::male
9.4.3 Let Expressions and «definition» Constraints
Sometimes a sub-expression is used more than once in a constraint. The let
expression allows one to define an attribute or operation that can be used in the
constraint.
context Person inv: let income : Integer = self.job.salary->sum()
let hasTitle(t :
String) : Boolean =
self.job->exists(title = t) in
if isUnemployed then
self.income < 100
else
self.income >= 100 and self.hasTitle(‘manager’)
endif
A let expression may be included in an invariant or pre- or postcondition. It is then only
known within this specific constraint. To enable reuse of let variables/operations one can
use a Constraint with the stereotype «definition», in which let variables/operations are
defined. This «definition» Constraint must be attached to a Classifier and may only
contain let definitions. All variables and operations defined in the «definition» constraint
are known in the same context as where any property of the Classifier can be used. In
essence, such variables and operations are psuedo-attributes and psuedo-operations of the
classifier. They are used in an OCL expression in exactly the same way as attributes or
operations are used. The textual notation for a «definition» Constraint uses the keyword
‘def’ as shown below:
context Person def:
let income :
Integer = self.job.salary->sum()
let hasTitle(t :
String) : Boolean =
self.job->exists(title = t)
The names of the attributes / operations in a let expression may not conflict with
the names of respective attributes/associationEnds and operations of
the Classifier. Also, the names of all let variables and operations
connected with a Classifier must be unique.
9.4.4 Type Conformance
OCL is a typed language and the basic value types are organized in a type
hierarchy. This hierarchy determines conformance of the different types to each
HL7 Template and Archetype Architecture
81
Template Special Interest Group
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
other. You cannot, for example, compare an Integer with a Boolean or a String.
An OCL expression in which all the types conform is a valid expression. An OCL
expression in which the types don’t conform is an invalid expression. It contains a
type conformance error. A type type1 conforms to a type type2 when an instance
of type1 can be substituted at each place where an instance of type2 is expected.
The type conformance rules for types in the class diagrams are simple.

Each type conforms to each of its supertypes.
• Type conformance is transitive: if type1 conforms to type2, and type2 conforms
to
type3, then type1 conforms to type3.
The effect of this is that a type conforms to its supertype, and all the supertypes
above.
The type conformance rules for the value types are listed in Table 7-3. The
conformance relation between the collection types only holds if they
are collections of element types that conform to each other. See
Section7.5.14, “Collection Type Hierarchy and Type Conformance
Rules,” on page 7-21 for the complete conformance rules for
collections.
Table 7-4 provides examples of valid and invalid expressions.
Table 7-3 Type conformance rules
Type Conforms to/Is a subtype of
Set(T) Collection(T)
Sequence(T) Collection(T)
Bag(T) Collection(T)
Integer Real
Table 7-4 Valid expressions
OCL expression valid explanation
1 + 2 * 34 yes
1 + ‘motorcycle’ no type String does not conform to type
Integer
23 * false no type Boolean does not conform to Integer
12 + 13.5 yes
9.4.5 Re-typing or Casting
In some circumstances, it is desirable to use a property of an object that is defined
on a subtype of the current known type of the object. Because the property is not
defined on the current known type, this results in a type conformance error.
When it is certain that the actual type of the object is the subtype, the object can
be retyped using the operation oclAsType(OclType). This operation results in the
same object, but the known type is the argument OclType. When there is an object
object of type Type1 and Type2 is another type, it is allowed to write:
object.oclAsType(Type2) --- evaluates to object with type Type2
HL7 Template and Archetype Architecture
Template Special Interest Group
82
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
An object can only be re-typed to one of its subtypes; therefore, in the example,
Type2 must be a subtype of Type1.
If the actual type of the object is not a subtype of the type to which it is re-typed,
the expression is undefined (see Section 7.4.10, “Undefined Values,” on page 711).
9.4.6 Precedence Rules
The precedence order for the operations, starting with highest precedence, in OCL
is:
@pre
• dot and arrow operations:
‘.’ and ‘->’
unary ‘not’ and unary minus ‘-’
‘*’ and ‘/’
‘+’ and binary ‘-’
‘if-then-else-endif’
• ‘<’, ‘>’, ‘<=’, ‘>=’
• ‘=’, ‘<>’
‘and’, ‘or’ and ‘xor’
‘implies’
Parentheses ‘(’ and ‘)’ can be used to change precedence.
9.4.7 Use of Infix Operators
The use of infix operators is allowed in OCL. The operators ‘+’, ‘-’, ‘*’, ‘/’, ‘<‘,
‘>’, ‘<>’ ‘<=’ ‘>=’, ‘and’, ‘or’, and ‘xor’ are used as infix operators. If a type
defines one of those operators with the correct signature, they will be used as infix
operators. The expression:
a+b
is conceptually equal to the expression:
a.+(b)
that is, invoking the ‘+’ operation on a with b as the parameter to the operation. The
infix operators defined for a type must have exactly one parameter. For the infix
operators ‘<‘, ‘>’, ‘<=’, ‘>=’, ‘<>’, ‘and’, ‘or’, and ‘xor’ the return type must be Boolean.
9.4.8 Keywords
Keywords in OCL are reserved words. That means that the keywords cannot
occur anywhere in an OCL expression as the name of a package, a type or a
property. The list of keywords is shown below:
9.4.9 Comment
Comments in OCL are written following two successive dashes (minus signs).
Everything immediately following the two dashes up to and including the end of
line is part of the comment. For example:
HL7 Template and Archetype Architecture
83
Template Special Interest Group
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
this is a comment
9.4.10 Undefined Values
Whenever an OCL expression is being evaluated, there is a possibility that one or
more of the queries in the expression are undefined. If this is the case, then the
complete expression will be undefined.
There are two exceptions to this for the Boolean operators:
True OR-ed with anything is True
False AND-ed with anything is False
The above two rules are valid irrespective of the order of the arguments and the above
rules are valid whether or not the value of the other sub-expression is known.
if implies
then endpackage
else package
endif context
not def
let inv
or pre
and post
xor in
9.5
Objects and Properties
OCL expressions can refer to Classifiers; for example, types, classes, interfaces,
associations (acting as types), and datatypes. Also all attributes, association-ends,
methods, and operations without side-effects that are defined on these types, etc. can be
used. In a class model, an operation or method is defined to be side-effect-free if the
isQuery attribute of the operations is true. For the purpose of this document, we will refer
to attributes, association-ends, and side-effect-free methods and operations as being
properties. A property is one of:
an Attribute
an AssociationEnd
an Operation with isQuery being true
a Method with isQuery being true
9.5.1 Properties
The value of a property on an object that is defined in a class diagram is specified
by a dot followed by the name of the property.
context AType inv:
self.property
If self is a reference to an object, then self.property is the value of the property property
on self.
HL7 Template and Archetype Architecture
Template Special Interest Group
84
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
9.5.2 Properties: Attributes
For example, the age of a Person is written as self.age:
context Person inv:
self.age > 0
The value of the subexpression self.age is the value of the age attribute on the particular
instance of Person identified by self. The type of this subexpression is the type of the
attribute age, which is the basic type Integer. Using attributes, and operations defined on
the basic value types, we can express calculations etc. over the class model. For example,
a business rule might be “the age of a Person is always greater than zero.” This can be
stated as shown in the invariant above.
9.5.3 Properties: Operations
Operations may have parameters. For example, as shown earlier, a Person object
has an income expressed as a function of the date. This operation would be
accessed as follows, for a Person aPerson and a date aDate:
aPerson.income(aDate)
The operation itself could be defined by a postcondition constraint. This is a
constraint that is stereotyped as «postcondition». The object that is returned by the
operation can be referred to by result. It takes the following form:
context Person::income (d: Date) : Integer
post: result = age * 1000
The right-hand-side of this definition may refer to the operation being defined; that is, the
definition may be recursive as long as the recursion is not infinite. The type of result is
the return type of the operation, which is Integer in the above example. To refer to an
operation or a method that doesn’t take a parameter, parentheses with an empty argument
list are mandatory:
context Company inv:
self.stockPrice() > 0
9.5.4 Properties: Association Ends and Navigation
Starting from a specific object, we can navigate an association on the class
diagram to refer to other objects and their properties. To do so, we navigate the
association by using the opposite association-end:
object.rolename
The value of this expression is the set of objects on the other side of the rolename
association. If the multiplicity of the association-end has a maximum of one
(“0..1” or “1”), then the value of this expression is an object. In the example class
diagram, when we start in the context of a Company; that is, self is an instance of
Company, we can write:
context Company
inv: self.manager.isUnemployed = false
inv: self.employee->notEmpty()
HL7 Template and Archetype Architecture
Template Special Interest Group
85
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
In the first invariant self.manager is a Person, because the multiplicity of the association
is one. In the second invariant self.employee will evaluate in a Set of Persons. By default,
navigation will result in a Set. When the association on the Class Diagram is adorned
with {ordered}, the navigation results in a Sequence. Collections, like Sets, Bags, and
Sequences are predefined types in OCL. They have a large number of predefined
operations on them. A property of the collection itself is accessed by using an arrow ‘->’
followed by the name of the property. The following example is in the context of a
person:
context Person inv:
self.employer->size() < 3
This applies the size property on the Set self.employer, which results in the number of
employers of the Person self.
context Person inv: self.employer->isEmpty()
This applies the isEmpty property on the Set self.employer. This evaluates to true if the
set of employers is empty and false otherwise.
9.5.4.1 Missing Rolenames
When a rolename is missing at one of the ends of an association, the name of
the type at the association end, starting with a lowercase character, is used as
the rolename. If this results in an ambiguity, the rolename is mandatory. This
is the case with unnamed rolenames in reflexive associations. If the rolename
is ambiguous, then it cannot be used in OCL.
9.5.4.2 Navigation over Associations with Multiplicity Zero or One
Because the multiplicity of the role manager is one, self.manager is an object
of type Person. Such a single object can be used as a Set as well. It then
behaves as if it is a Set containing the single object. The usage as a set is done
through the arrow followed by a property of Set. This is shown in the
following example:
context Company inv:
self.manager->size() = 1
The sub-expression self.manager is used as a Set, because the arrow is used to access the
size property on Set. This expression evaluates to true. The following example shows
how a property of a collection can be used.
context Company inv:
self.manager->foo
The sub-expression self.manager is used as Set, because the arrow is used to access the
foo property on the Set. This expression is incorrect, because foo is not a defined property
of Set.
context Company inv:
self.manager.age> 40
The sub-expression self.manager is used as a Person, because the dot is used to access the
age property of Person.
HL7 Template and Archetype Architecture
Template Special Interest Group
86
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
In the case of an optional (0..1 multiplicity) association, this is especially useful to check
whether there is an object or not when navigating the association. In the example we can
write:
context Person inv:
self.wife->notEmpty() implies self.wife.sex = Sex::female
9.5.4.3 Combining Properties
Properties can be combined to make more complicated expressions. An
important rule is that an OCL expression always evaluates to a specific object
of a specific type. After obtaining a result, one can always apply another
property to the result to get a new result value. Therefore, each OCL
expression can be read and evaluated left-to-right. Following are some
invariants that use combined properties on the example class diagram:
[1] Married people are of age >= 18
context Person inv:
self.wife->notEmpty() implies self.wife.age >= 18 and
self.husband->notEmpty() implies self.husband.age >= 18
[2] a company has at most 50 employees
context Company inv:
self.employee->size() <= 50
9.5.5 Navigation to Association Classes
To specify navigation to association classes (Job and Marriage in the example),
OCL uses a dot and the name of the association class starting with a lowercase
character:
context Person inv:
self.job
The sub-expression self.job evaluates to a Set of all the jobs a person has with the
companies that are his/her employer. In the case of an association class, there is no
explicit rolename in the class diagram. The name job used in this navigation is the name
of the association class starting with a lowercase character, similar to the way described
in the section “Missing Rolenames” above.
In case of a recursive association, that is an association of a class with itself, the name of
the association class alone is not enough. We need to distinguish the direction in which
the association is navigated as well as the name of the association class. Take the
following model as an example.
Figure 7-2 Navigating recursive association classes
When navigating to an association class such as employeeRanking there are two
possibilities depending on the direction. For instance, in the above example, we may
navigate towards the employees end, or the bosses end. By using the name of the
association class alone, these two options cannot be distinguished. To make the
distinction, the rolename of the direction in which we want to navigate is added to the
association class name, enclosed in square brackets.
EmployeeRanking
HL7 Template and Archetype Architecture
Template Special Interest Group
87
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
Person
age
bosses
employees * score
*
In the expression
context Person inv:
self.employeeRanking[bosses]->sum() > 0
the self.employeeRanking[bosses] evaluates to the set of EmployeeRankings belonging
to the collection of bosses. And in the expression
context Person inv:
self.employeeRanking[employees]->sum() > 0
the self.employeeRanking[employees] evaluates to the set of EmployeeRankings
belonging to the collection of employees. The unqualified use of the association class
name is not allowed in such a recursive situation. Thus, the following example is invalid:
context Person inv: self.employeeRanking->sum() > 0 -- INVALID!
In a non-recursive situation, the association class name alone is enough, although the
qualified version is allowed as well. Therefore, the examples at the start of this section
could also be written as:
context Person inv: self.job[employer]
9.5.6 Navigation from Association Classes
We can navigate from the association class itself to the objects that participate in
the association. This is done using the dot-notation and the role-names at the
associationends.
context Job
inv: self.employer.numberOfEmployees >= 1
inv: self.employee.age > 21
Navigation from an association class to one of the objects on the association will always
deliver exactly one object. This is a result of the definition of AssociationClass.
Therefore, the result of this navigation is exactly one object, although it can be used as a
Set using the arrow (->).
9.5.7 Navigation through Qualified Associations
Qualified associations use one or more qualifier attributes to select the objects at
the other end of the association. To navigate them, we can add the values for the
qualifiers to the navigation. This is done using square brackets, following the rolename. It is permissible to leave out the qualifier values, in which case the result
will be all objects at the other end of the association.
context Bank inv:
self.customer
This results in a Set(Person) containing all customers of the Bank.
context Bank inv: self.customer[8764423]
HL7 Template and Archetype Architecture
Template Special Interest Group
88
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
This results in one Person, having accountnumber 8764423. If there is more than one
qualifier attribute, the values are separated by commas, in the order which is specified in
the UML class model. It is not permissible to partially specify the qualifier attribute
values.
9.5.8 Using Pathnames for Packages
Within UML, different types are organized in packages. OCL provides a way of
explicitly referring to types in other packages by using a package-pathname
prefix. The syntax is a package name, followed by a double colon:
Packagename::Typename
This usage of pathnames is transitive and can also be used for packages within
packages:
Packagename1::Packagename2::Typename
9.5.9 Accessing overridden properties of supertypes
Whenever properties are redefined within a type, the property of the supertypes
can be accessed using the oclAsType() operation. Whenever we have a class B as
a subtype of class A, and a property p1 of both A and B, we can write:
context B inv:
self.oclAsType(A).p1 -- accesses the p1 property defined in A
self.p1 -- accesses the p1 property defined in B
Figure 7-3 shows an example where such a construct is needed.
Figure 7-3 Accessing Overridden Properties Example
....
Depen den cy
ta rg et
s our c e
*
*
Mod elElemen t
N ote
v alu e: U ninterp rete d
In this model fragment there is an ambiguity with the OCL expression on Dependency:
context Dependency inv:
self.source <> self
This can either mean normal association navigation, which is inherited from
ModelElement, or it might also mean navigation through the dotted line as an association
class. Both possible navigations use the same role-name, so this is always ambiguous.
Using oclAsType() we can distinguish between them with:
context Dependency
inv: self.oclAsType(Dependency).source
inv: self.oclAsType(ModelElement).source
HL7 Template and Archetype Architecture
Template Special Interest Group
89
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
9.5.10 Predefined properties on All Objects
There are several properties that apply to all objects, and are predefined in OCL.
These are:
oclIsTypeOf(t : OclType) : Boolean
oclIsKindOf(t : OclType) : Boolean
oclInState(s : OclState) : Boolean
oclIsNew() : Boolean
oclAsType(t : OclType) : instance of OclType
The operation is oclTypeOf results in true if the type of self and t are the same. For
example:
context Person
inv: self.oclIsTypeOf( Person ) -- is true
inv: self.oclIsTypeOf( Company) -- is false
The above property deals with the direct type of an object. The oclIsKindOf property
determines whether t is either the direct type or one of the supertypes of an object. The
operation oclInState(s) results in true if the object is in the state s. Values for s are the
names of the states in the statemachine(s) attached to the Classifier of object. For nested
states the statenames can be combined using the double colon ‘::’ . In the example
statemachine above, values for s can be On, Off, Off::Standby, Off::NoPower. If the
classifier of object has the above associated statemachine valid OCL expressions are:
On Off
Standby NoPower
object.oclInState(On)
object.oclInState(Off)
object.oclInstate(Off::Standby)
object.oclInState(Off:NoPower)
If there are multiple statemachines attached to the object’s classifier, then the statename
can be prefixed with the name of the statemachine containing the state and the double
semicolon ::, as with nested states.
The operation oclIsNew evaluates to true if, used in a postcondition, the object is created
during performing the operation; that is, it didn’t exist at precondition time.
9.5.11 Features on Classes Themselves
All properties discussed until now in OCL are properties on instances of classes.
The types are either predefined in OCL or defined in the class model. In OCL, it
is also possible to use features defined on the types/classes themselves. These are,
for example, the class-scoped features defined in the class model. Furthermore,
several features are predefined on each type.
A predefined feature on each type is allInstances, which results in the Set of all
instances of the type in existence at the specific time when the expression is
evaluated.
If we want to make sure that all instances of Person have unique names, we can
write:
HL7 Template and Archetype Architecture
Template Special Interest Group
90
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
context Person inv:
Person.allInstances->forAll(p1, p2 |
p1 <> p2 implies p1.name <> p2.name)
The Person.allInstances is the set of all persons and is of type Set(Person). It is the set of
all persons that exist at the snapshot in time that the expression is evaluated. Note – The
use of allInstances has some problems and its use is discouraged in most cases. The first
problem is best explained by looking at the types like Integer, Real and String. For these
types the meaning of allInstances is undefined. What does it mean for an Integer to exist?
The evaluation of the expression Integer.allInstances results in an infinite set and is
therefore undefined within OCL. The second problem with allInstances is that the
existence of objects must be considered within some overall context, like a system or a
model. This overall context must be defined, which is not done within OCL. A
recommended style is to model the overall contextual system explicitly as an object
within the system and navigate from that object to its containing instances without using
allInstances.
9.5.12 Collections
Single navigation results in a Set, combined navigations in a Bag, and navigation
over associations adorned with {ordered} results in a Sequence. Therefore, the
collection types play an important role in OCL expressions.
The type Collection is predefined in OCL. The Collection type defines a large
number of predefined operations to enable the OCL expression author (the
modeler) to manipulate collections. Consistent with the definition of OCL as an
expression language, collection operations never change collections; isQuery is
always true. They may result in a collection, but rather than changing the original
collection they project the result into a new one.
Collection is an abstract type, with the concrete collection types as its subtypes.
OCL distinguishes three different collection types: Set, Sequence, and Bag. A Set
is the mathematical set. It does not contain duplicate elements. A Bag is like a set,
which may contain duplicates; that is, the same element may be in a bag twice or
more. A Sequence is like a Bag in which the elements are ordered. Both Bags and
Sets have no order defined on them. Sets, Sequences, and Bags can be specified
by a literal in OCL. Curly brackets surround the elements of the collection,
elements in the collection are written within, separated by commas. The type of
the collection is written before the curly brackets:
Set { 1 , 2 , 5 , 88 }
Set { ‘apple’ , ‘orange’, ‘strawberry’ }
A Sequence:
Sequence { 1, 3, 45, 2, 3 }
Sequence { ‘ape’, ‘nut’ }
A bag:
Bag {1 , 3 , 4, 3, 5 }
HL7 Template and Archetype Architecture
Template Special Interest Group
91
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
Because of the usefulness of a Sequence of consecutive Integers, there is a separate literal
to create them. The elements inside the curly brackets can be replaced by an interval
specification, which consists of two expressions of type Integer, Int-expr1 and Int-expr2,
separated by ‘..’. This denotes all the Integers between the values of Intexpr1 and Intexpr2, including the values of Int-expr1 and Int-expr2 themselves:
Sequence{ 1..(7 + 4) }
Sequence{ 1..10 }
are both identical to
Sequence{ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 }
The complete list of Collection operations is described at the end of this chapter.
Collections can be specified by a literal, as described above. The only other way to get a
collection is by navigation. To be more precise, the only way to get a Set, Sequence, or
Bag is:
1. a literal, this will result in a Set, Sequence, or Bag:
Set {1 , 2, 3 , 5 , 7 , 11, 13, 17 }
Sequence {1 , 2, 3 , 5 , 7 , 11, 13, 17 }
Bag {1, 2, 3, 2, 1}
2. a navigation starting from a single object can result in a collection: context Company
inv: self.employee
3. operations on collections may result in new collections: collection1>union(collection2)
9.5.13 Collections of Collections
Within OCL, all Collections of Collections are flattened automatically; therefore,
the following two expressions have the same value:
Set{ Set{1, 2}, Set{3, 4}, Set{5, 6} }
Set{ 1, 2, 3, 4, 5, 6 }
9.5.14 Collection Type Hierarchy and Type Conformance Rules
In addition to the type conformance rules in Section 7.4.4, “Type Conformance,”
on page 7-9, the following rules hold for all types, including the collection types:
The types Set (X), Bag (X) and Sequence (X) are all subtypes of Collection (X).
Type conformance rules are as follows for the collection types:
Type1 conforms to Type2 when they are identical (standard rule for all types).
Type1 conforms to Type2 when it is a subtype of Type2 (standard rule for all
types).
Collection(Type1) conforms to Collection(Type2), when Type1 conforms to
Type2.
Type conformance is transitive: if Type1 conforms to Type2, and Type2 conforms
to
Type3, then Type1 conforms to Type3 (standard rule for all types).
For example, if Bicycle and Car are two separate subtypes of Transport:
Set(Bicycle) conforms to Set(Transport)
Set(Bicycle) conforms to Collection(Bicycle)
HL7 Template and Archetype Architecture
92
Template Special Interest Group
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
Set(Bicycle) conforms to Collection(Transport)
Note that Set(Bicycle) does not conform to Bag(Bicycle), nor the other way
around.
They are both subtypes of Collection(Bicycle) at the same level in the hierarchy.
9.5.15 Previous Values in Postconditions
As stated in Section 7.3.4, “Pre- and Postconditions,” on page 7-6, OCL can be
used to specify pre- and post-conditions on operations and methods in UML. In a
postcondition, the expression can refer to two sets of values for each property of
an object:
the value of a property at the start of the operation or method
the value of a property upon completion of the operation or method
The value of a property in a postcondition is the value upon completion of the operation.
To refer to the value of a property at the start of the operation, one has to postfix the
property name with the keyword ‘@pre’:
context Person::birthdayHappens()
post: age = age@pre + 1
The property age refers to the property of the instance of Person on which executes the
operation. The property age@pre refers to the value of the property age of the Person that
executes the operation, at the start of the operation. If the property has parameters, the
‘@pre’ is postfixed to the propertyname, before the parameters.
context Company::hireEmployee(p : Person)
post: employees = employees@pre->including(p) and
stockprice() = stockprice@pre() + 10
The above operation can also be specified by a postcondition and a precondition together:
context Company::hireEmployee(p : Person)
pre : not employee->includes(p)
post: employees->includes(p) and
stockprice() = stockprice@pre() + 10
When the pre-value of a property evaluates to an object, all further properties that are
accessed of this object are the new values (upon completion of the operation) of this
object. So:
[email protected]—takes the old value of property b of a, say x -- and then the new value of c of
x. [email protected]@pre—takes the old value of property b of a, say x -- and then the old value
of c of x.
The ‘@pre’ postfix is allowed only in OCL expressions that are part of a Postcondition.
Asking for a current property of an object that has been destroyed during execution of the
operation results in Undefined. Also, referring to the previous value of an object that has
been created during execution of the operation results in Undefined.
9.6
Collection Operations
OCL defines many operations on the collection types. These operations are specifically
meant to enable a flexible and powerful way of projecting new collections from existing
ones. The different constructs are described in the following sections.
HL7 Template and Archetype Architecture
Template Special Interest Group
93
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
9.6.1 Select and Reject Operations
Sometimes an expression using operations and navigations delivers a collection,
while we are interested only in a special subset of the collection. OCL has special
constructs to specify a selection from a specific collection. These are the select and
reject operations. The select specifies a subset of a collection. A select is an operation
on a collection and is specified using the arrow-syntax:
collection->select( ... )
The parameter of select has a special syntax that enables one to specify which
elements of the collection we want to select. There are three different forms, of which
the simplest one is:
collection->select( boolean-expression )
This results in a collection that contains all the elements from collection for which the
boolean-expression evaluates to true. To find the result of this expression, for each
element in collection the expression boolean-expression is evaluated. If this evaluates
to true, the element is included in the result collection, otherwise not. As an example,
the following OCL expression specifies that the collection of all the employees older
than 50 years is not empty:
context Company inv: self.employee->select(age > 50)->notEmpty()
The self.employee is of type Set(Person). The select takes each person from
self.employee and evaluates age > 50 for this person. If this results in true, then the
person is in the result Set.
As shown in the previous example, the context for the expression in the select
argument is the element of the collection on which the select is invoked. Thus the age
property is taken in the context of a person.
In the above example, it is impossible to refer explicitly to the persons themselves;
you can only refer to properties of them. To enable to refer to the persons themselves,
there is a more general syntax for the select expression:
collection->select( v | boolean-expression-with-v )
The variable v is called the iterator. When the select is evaluated, v iterates over the
collection and the boolean-expression-with-v is evaluated for each v. The v is a
reference to the object from the collection and can be used to refer to the objects
themselves from the collection. The two examples below are identical:
context Company inv: self.employee->select(age > 50)->notEmpty() context
Company inv: self.employee->select(p | p.age > 50)->notEmpty()
The result of the complete select is the collection of persons p for which the p.age > 50
evaluates to True. This amounts to a subset of self.employee. As a final extension to the
select syntax, the expected type of the variable v can be given. The select now is written
as:
collection->select( v : Type | boolean-expression-with-v )
The meaning of this is that the objects in collection must be of type Type. The next
example is identical to the previous examples:
HL7 Template and Archetype Architecture
Template Special Interest Group
94
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
context Company inv: self.employee.select(p : Person | p.age > 50)->notEmpty()
The compete select syntax now looks like one of:
collection->select( v : Type | boolean-expression-with-v ) collection->select( v | booleanexpression-with-v ) collection->select( boolean-expression )
The reject operation is identical to the select operation, but with reject we get the subset
of all the elements of the collection for which the expression evaluates to False.
The reject syntax is identical to the select syntax:
collection->reject( v : Type | boolean-expression-with-v ) collection->reject( v | booleanexpression-with-v ) collection->reject( boolean-expression )
As an example, specify that the collection of all the employees who are not married is
empty:
context Company inv: self.employee->reject( isMarried )->isEmpty()
The reject operation is available in OCL for convenience, because each reject can be
restated as a select with the negated expression. Therefore, the following two expressions
are identical:
collection->reject( v : Type | boolean-expression-with-v ) collection->select( v : Type |
not (boolean-expression-with-v) )
9.6.2 Collect Operation
As shown in the previous section, the select and reject operations always result in a
sub-collection of the original collection. When we want to specify a collection that is
derived from some other collection, but which contains different objects from the
original collection; that is, it is not a sub-collection, we can use a collect operation.
The collect operation uses the same syntax as the select and reject and is written as
one of:
collection->collect( v : Type | expression-with-v ) collection->collect( v | expressionwith-v ) collection->collect( expression )
The value of the reject operation is the collection of the results of all the evaluations of
expression-with-v.
An example: specify the collection of birthDates for all employees in the context of a
company. This can be written in the context of a Company object as one of:
self.employee->collect( birthDate ) self.employee->collect( person | person.birthDate )
self.employee->collect( person : Person | person.birthDate )
An important issue here is that the resulting collection is not a Set, but a Bag. When more
than one employee has the same value for birthDate, this value will be an element of the
resulting Bag more than once. The Bag resulting from the collect operation always has
the same size as the original collection. It is possible to make a Set from the Bag, by
using the asSet property on the Bag. The following expression results in the Set of
different birthDates from all employees of a Company:
self.employee->collect( birthDate )->asSet()
9.6.2.1 Shorthand for Collect
Because navigation through many objects is very common, there is a shorthand
notation for the collect that makes the OCL expressions more readable. Instead of
self.employee->collect(birthdate)
HL7 Template and Archetype Architecture
Template Special Interest Group
95
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
we can also write:
self.employee.birthdate
In general, when we apply a property to a collection of Objects, then it will automatically
be interpreted as a collect over the members of the collection with the specified property.
For any propertyname that is defined as a property on the objects in a collection, the
following two expressions are identical:
collection.propertyname
collection->collect(propertyname)
and so are these if the property is parameterized:
collection.propertyname(par1, par2, ...) collection->collect(propertyname(par1, par2, ...)
9.6.3 ForAll Operation
Many times a constraint is needed on all elements of a collection. The forAll
operation in OCL allows specifying a Boolean expression, which must hold for all
objects in a collection:
collection->forAll( v : Type | boolean-expression-with-v ) collection->forAll( v |
boolean-expression-with-v ) collection->forAll( boolean-expression )
This forAll expression results in a Boolean. The result is true if the
booleanexpression-with-v is true for all elements of collection. If the booleanexpression-withv is false for one or more v in collection, then the complete expression
evaluates to false. For example, in the context of a company:
context Company inv: self.employee->forAll( forename = ‘Jack’ ) inv:
self.employee->forAll( p | p.forename = ‘Jack’ ) inv: self.employee->forAll( p :
Person | p.forename = ‘Jack’ )
These invariants evaluate to true if the forename feature of each employee is equal to
‘Jack.’
The forAll operation has an extended variant in which more then one iterator is used.
Both iterators will iterate over the complete collection. Effectively this is a forAll on
the Cartesian product of the collection with itself.
context Company inv: self.employee->forAll( e1, e2 | e1 <> e2 implies
e1.forename <> e2.forename) context Company inv: self.employee->forAll( e1,
e2 : Person | e1 <> e2 implies e1.forename <> e2.forename)
This expression evaluates to true if the forenames of all employees are different. It is
semantically equivalent to:
context Company inv: self.employee->forAll(e1 | self.employee->forAll (e2 | e1
<> e2 implies e1.forename <> e2.forename)))
9.6.4 Exists Operation
Many times one needs to know whether there is at least one element in a collection
for which a constraint holds. The exists operation in OCL allows you to specify a
Boolean expression that must hold for at least one object in a collection:
HL7 Template and Archetype Architecture
Template Special Interest Group
96
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
collection->exists( v : Type | boolean-expression-with-v ) collection->exists( v |
boolean-expression-with-v ) collection->exists( boolean-expression )
This exists operation results in a Boolean. The result is true if the booleanexpressionwith-v is true for at least one element of collection. If the booleanexpression-with-v is false for all v in collection, then the complete expression
evaluates to false. For example, in the context of a company:
context Company inv: self.employee->exists( forename = ‘Jack’ ) context
Company inv: self.employee->exists( p | p.forename = ‘Jack’ ) context
Company inv: self.employee->exists( p : Person | p.forename = ‘Jack’ )
These expressions evaluate to true if the forename feature of at least one employee is
equal to ‘Jack.’
9.6.5 Iterate Operation
The iterate operation is slightly more complicated, but is very generic. The operations
reject, select, forAll, exists, collect can all be described in terms of iterate. An
accumulation builds one value by iterating over a collection.
collection->iterate( elem : Type; acc : Type = <expression> | expression-with-elemand-acc )
The variable elem is the iterator, as in the definition of select, forAll, etc. The variable
acc is the accumulator. The accumulator gets an initial value <expression>. When
the iterate is evaluated, elem iterates over the collection and the expression-withelemand-acc is evaluated for each elem. After each evaluation of expression-withelemand-acc, its value is assigned to acc. In this way, the value of acc is built up during
the iteration of the collection. The collect operation described in terms of iterate will
look like:
collection->collect(x : T | x.property)
is identical to:
collection->iterate(x : T; acc : T2 = Bag{} | acc->including(x.property))
Or written in Java-like pseudocode the result of the iterate can be calculated as:
iterate(elem : T; acc : T2 = value)
{
acc = value; for(Enumeration e = collection.elements() ; e.hasMoreElements();
){
elem = e.nextElement();
acc = <expression-with-elem-and-acc>
}
}
Although the Java pseudo code uses a ‘next element,’ the iterate operation is defined for
each collection type and the order of the iteration through the elements in the collection is
not defined for Set and Bag. For a Sequence the order is the order of the elements in the
sequence.
HL7 Template and Archetype Architecture
Template Special Interest Group
97
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
9.6.6 Iterators in Collection Operations
The collection operations that take an OclExpression as parameter may all have an
optional iterator declaration. For any operation name op, the syntax options are:
collection->op( iter : Type | OclExpression ) collection->op( iter | OclExpression )
collection->op( OclExpression )
9.6.7 Resolving Properties
For any property (attribute, operation, or navigation), the full notation includes the
object of which the property is taken. As seen in Section 7.3.3, “Invariants,” on page
7-5, self can be left implicit, and so can the iterator variables in collection operations.
At any place in an expression, when an iterator is left out, an implicit iterator-variable
is introduced. For example in:
context Person inv: employer->forAll( employee->exists( lastName = name) )
three implicit variables are introduced. The first is self, which is always the instance
from which the constraint starts. Secondly an implicit iterator is introduced by the
forAll and third by the exists. The implicit iterator variables are unnamed. The
properties employer, employee, lastName and name all have the object on which they
are applied left out. Resolving these goes as follows:
At the place of employer there is one implicit variable: self : Person. Therefore employer
must be a property of self.
At the place of employee there are two implicit variables: self : Person and iter1 :
Company. Therefore employer must be a property of either self or iter1. If employee is a
property of both self and iter1, then this is unambiguous and the instance on which
employee is applied must be stated explicitly. In this case only iter1.employee is possible.
At the place of lastName and name there are three implicit variables: self : Person , iter1
: Company and iter2 : Person. Therefore lastName and name must both be a property
of either self or iter1 or iter2. Property name is a property of iter1. However,
lastName is a property of both self and iter2. This is ambiguous and therefore the
OCL expression is incorrect. The expression must state either self.lastName or define
the iter2 iterator variable explicit and state iter2.lastName.
Both of the following invariant constraints are correct:
context Person inv: employer->forAll( employee->exists( p | p.lastName = name) )
inv: employer->forAll( employee->exists( self.lastName = name) )
9.7
The Standard OCL Package
Each UML model that uses OCL constraints contains a predefined standard package
called “UML_OCL.” This package is used by default in all other packages in the model
to evaluate OCL expressions. This package contains all predefined OCL types and their
features.
To extend the predefined OCL types, a modeler should define a separate package. The
standard OCL package can be imported, and each OCL type can be extended with new
features.
HL7 Template and Archetype Architecture
Template Special Interest Group
98
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
To specify that a package used the predefined OCL types from a user defined package
instead of the standard package, the using package must define a Dependency with
stereotype «OCL_Types» to the package that defines the extended OCL types. A
constraint on the user defined OCL package is that as a minimum all predefined OCL
types with all of their features must be defined. The user defined package must be a
proper extension to the standard OCL package.
9.8
Predefined OCL Types
This section contains all standard types defined within OCL, including all the properties
defined on those types. Its signature and a description of its semantics define each
property. Within the description, the reserved word ‘result’ is used to refer to the value
that results from evaluating the property. In several places, post conditions are used to
describe properties of the result. When there is more than one postcondition, all
postconditions must be true.
9.8.1 Basic Types
The basic types used are Integer, Real, String, and Boolean. They are supplemented
with OclExpression, OclType, and OclAny.
9.8.1.1 OclType
All types defined in a UML model, or pre-defined within OCL, have a type. This
type is an instance of the OCL type called OclType. Access to this type allows the
modeler limited access to the meta-level of the model. This can be useful for
advanced modelers.
Properties of OclType, where the instance of OclType is called type.
type.name() : String
The name of type.
type.attributes() : Set(String)
The set of names of the attributes of type, as they are defined in the model.
type.associationEnds() : Set(String)
The set of names of the navigable associationEnds of type, as they are defined in the
model. type.operations() : Set(String)
The set of names of the operations of type, as they are defined in the model.
type.supertypes() : Set(OclType)
The set of all direct supertypes of type. post: type.allSupertypes()->includesAll(result)
type.allSupertypes() : Set(OclType)
The transitive closure of the set of all supertypes of type.
9.8.1.2 OclAny
Within the OCL context, the type OclAny is the supertype of all types in the
model and the basic predefined OCL type. The predefined OCL Collection types
are not subtypes of OclAny. Properties of OclAny are available on each object in
all OCL expressions. All classes in a UML model inherit all properties defined
on OclAny. To avoid name conflicts between properties in the model and the
properties inherited from OclAny, all names on the properties of OclAny start
HL7 Template and Archetype Architecture
Template Special Interest Group
99
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
with ‘ocl.’ Although theoretically there may still be name conflicts, they can be
avoided. One can also use the oclAsType() operation to explicitly refer to the
OclAny properties.
Properties of OclAny, where the instance of OclAny is called object.
type.allInstances() : Set(type)
The set of all instances of type and all its subtypes in existence at the snapshot at the time
that the expression is evaluated.
object = (object2 : OclAny) : Boolean
True if object is the same object as object2.
object <> (object2 : OclAny) : Boolean
True if object is a different object from object2.
post: result = not (object = object2)
object.oclIsKindOf(type : OclType) : Boolean
True if type is one of the types of object, or one of the supertypes (transitive) of the types
of object.
object.oclIsTypeOf(type : OclType) : Boolean
True if type is equal to one of the types of object.
object.oclAsType(type : OclType) : type
Results in object, but of known type type.
Results in Undefined if the actual type of object is not type or one of its subtypes. pre :
object.oclIsKindOf(type)
post: result = object
post: result.oclIsKindOf(type)
9.8.1.3
9.8.1.4
9.8.1.5 OclState
The type OclState is used as a parameter for the operation oclInState. There
are no properties defined on OclState. One can only specify an OclState by
using the name of the state, as it appears in a statemachine. These names can
be fully qualified by the nested states and statemachine that contain them.
9.8.1.6 OclExpression
Each OCL expression itself is an object in the context of OCL. The type of the
expression is OclExpression. This type and its properties are used to define
the semantics of properties that take an expression as one of their parameters:
select, collect, forAll, etc.
An OclExpression includes the optional iterator variable and type and the
optional accumulator variable and type.
Properties of OclExpression, where the instance of OclExpression is called
expression.
9.8.1.7 Real
HL7 Template and Archetype Architecture
Template Special Interest Group
100
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
The OCL type Real represents the mathematical concept of real. Note that
Integer is a subclass of Real, so for each parameter of type Real, you can use
an integer as the actual parameter.
Properties of Real, where the instance of Real is called r.
object.oclInState(state : OclState) : Boolean
Results in true if object is in the state state, otherwise results in false. The argument is a
name of a state in the state machine corresponding with the class of object.
object.oclIsNew() : Boolean
Can only be used in a postcondition.
Evaluates to true if the object is created during performing the operation. That is it didn’t
exist at precondition time. expression.evaluationType() : OclType The type of the object
that results from evaluating expression.
r = (r2 : Real) : Boolean
True if r is equal to r2.
r <> (r2 : Real) : Boolean
True if r is not equal to r2.
post: result = not (r = r2)
r + (r2 : Real) : Real
The value of the addition of r and r2.
r - (r2 : Real) : Real
The value of the subtraction of r2 from r.
r * (r2 : Real) : Real
The value of the multiplication of r and r2.
r : Real
The negative value of r.
r / (r2 : Real) : Real
The value of r divided by r2.
r.abs() : Real
The absolute value of r.
post: if r < 0 then result = - r else result = r endif
r.floor() : Integer
The largest integer which is less than or equal to r.
post: (result <= r) and (result + 1 > r)
r.round() : Integer
The integer that is closest to r. When there are two such integers, the largest one. post:
((r - result) < r).abs() < 0.5) or ((r - result).abs() = 0.5 and (result > r))
r.max(r2 : Real) : Real
The maximum of r and r2.
post: if r >= r2 then result = r else result = r2 endif
r.min(r2 : Real) : Real
The minimum of r and r2.
post: if r <= r2 then result = r else result = r2 endif
r < (r2 : Real) : Boolean
True if r1 is less than r2.
6.8.1.8 Integer
HL7 Template and Archetype Architecture
Template Special Interest Group
101
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
The OCL type Integer represents the mathematical concept of integer.
Properties of Integer, where the instance of Integer is called i.
r > (r2 : Real) : Boolean
True if r1 is greater than r2.
post: result = not (r <= r2)
r <= (r2 : Real) : Boolean
True if r1 is less than or equal to r2.
post: result = (r = r2) or (r < r2)
r >= (r2 : Real) : Boolean
True if r1 is greater than or equal to r2.
post: result = (r = r2) or (r > r2)
i = (i2 : Integer) : Boolean
True if i is equal to i2.
i : Integer
The negative value of i.
i + (i2 : Integer) : Integer
The value of the addition of i and i2.
i - (i2 : Integer) : Integer
The value of the subtraction of i2 from i.
i * (i2 : Integer) : Integer
The value of the multiplication of i and i2.
i / (i2 : Integer) : Real
The value of i divided by i2.
i.abs() : Integer
The absolute value of i.
post: if i < 0 then result = - i else result = i endif
9.8.1.9 String
The OCL type String represents strings consisting of ASCII characters or
multi-byte characters.
Properties of String, where the instance of String is called string.
i.div( i2 : Integer) : Integer
The number of times that i2 fits completely within i.
pre : i2 <> 0
post: if i / i2 >= 0 then result = (i / i2).floor() else result = -((-i/i2).floor()) endif
i.mod( i2 : Integer) : Integer
The result is i modulo i2.
post: result = i - (i.div(i2) * i2)
i.max(i2 : Integer) : Integer
The maximum of i an i2.
post: if i >= i2 then result = i else result = i2 endif
i.min(i2 : Integer) : Integer
The minimum of i an i2.
post: if i <= i2 then result = i else result = i2 endif
string = (string2 : String) : Boolean
HL7 Template and Archetype Architecture
Template Special Interest Group
102
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
True if string and string2 contain the same characters, in the same order.
string.size() : Integer
The number of characters in string.
string.concat(string2 : String) : String
The concatenation of string and string2.
post: result.size() = string.size() + string2.size()
post: result.substring(1, string.size() ) = string
post: result.substring(string.size() + 1, result.size() ) = string2 string.toUpper() : String
The value of string with all lowercase characters converted to uppercase characters. post:
result.size() = string.size() string.toLower() : String The value of string with all uppercase
characters converted to lowercase characters. post: result.size() = string.size()
9.8.1.10 Boolean
The OCL type Boolean represents the common true/false values.
Features of Boolean, the instance of Boolean is called b.
9.8.1.11 Enumeration
The OCL type Enumeration represents the enumerations defined in a UML model.
string.substring(lower : Integer, upper : Integer) : String
The sub-string of string starting at character number lower, up to and including character
number upper.
b = (b2 : Boolean) : Boolean
Equal if b is the same as b2.
b or (b2 : Boolean) : Boolean
True if either b or b2 is true.
b xor (b2 : Boolean) : Boolean
True if either b or b2 is true, but not both.
post: (b or b2) and not (b = b2)
b and (b2 : Boolean) : Boolean
True if both b1 and b2 are true.
not b : Boolean
True if b is false.
post: if b then result = false else result = true endif
b implies (b2 : Boolean) : Boolean
True if b is false, or if b is true and b2 is true.
post: (not b) or (b and b2)
if b then (expression1 : OclExpression)
else (expression2 : OclExpression) endif : expression1.evaluationType()
If b is true, the result is the value of evaluating expression1; otherwise, result is the
value of evaluating expression2.
Features of Enumeration, the instance of Enumeration is called enumeration.
9.8.2 Collection-Related Types
The following sections define the properties on collections; that is, these properties
are available on Set, Bag, and Sequence. As defined in this section, each collection
HL7 Template and Archetype Architecture
Template Special Interest Group
103
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
type is actually a template with one parameter. ‘T’ denotes the parameter. A real
collection type is created by substituting a type for the T. So Set (Integer) and Bag
(Person) are collection types.
All collection operations with an OclExpression as parameter can have an iterator
declarator.
9.8.2.1 Collection
Collection is the abstract supertype of all collection types in OCL. Each occurrence of
an object in a collection is called an element. If an object occurs twice in a collection,
there are two elements. This section defines the properties on Collections that have
identical semantics for all collection subtypes. Some properties may be defined with
the subtype as well, which means that there is an additional postcondition or a more
specialized return value.
The definition of several common properties is different for each subtype. These
properties are not mentioned in this section.
Properties of Collection, where the instance of Collection is called collection.
enumeration = (enumeration2 : Boolean) : Boolean
Equal if enumeration is the same as enumeration2.
enumeration <> (enumeration2 : Boolean) : Boolean
Equal if enumeration is not the same as enumeration2.
post: result = not ( enumeration = enumeration2)
collection->size() : Integer
The number of elements in the collection collection.
post: result = collection->iterate(elem; acc : Integer = 0 | acc + 1)
collection->includes(object : OclAny) : Boolean
True if object is an element of collection, false otherwise.
post: result = (collection->count(object) > 0)
collection->excludes(object : OclAny) : Boolean
True if object is not an element of collection, false otherwise. post: result = (collection>count(object) = 0) collection->count(object : OclAny) : Integer The number of times
that object occurs in the collection collection.
post: result = collection->iterate( elem; acc : Integer = 0 |
if elem = object then acc + 1 else acc endif)
collection->includesAll(c2 : Collection(T)) : Boolean
Does collection contain all the elements of c2 ?
post: result = c2->forAll(elem | collection->includes(elem))
collection->excludesAll(c2 : Collection(T)) : Boolean
Does collection contain none of the elements of c2 ?
post: result = c2->forAll(elem | collection->excludes(elem))
collection->isEmpty() : Boolean
Is collection the empty collection?
post: result = ( collection->size() = 0 )
collection->notEmpty() : Boolean
Is collection not the empty collection?
HL7 Template and Archetype Architecture
Template Special Interest Group
104
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
post: result = ( collection->size() <> 0 )
collection->sum() : T
The addition of all elements in collection. Elements must be of a type supporting the +
operation. The + operation must take one parameter of type T and be both associative:
(a+b)+c = a+(b+c), and commutative: a+b = b+a. Integer and Real fulfill this condition.
post: result = collection->iterate( elem; acc : T = 0 |
acc + elem )
collection->exists(expr : OclExpression) : Boolean
Results in true if expr evaluates to true for at least one element in collection. post: result
= collection->iterate(elem; acc : Boolean = false | acc or expr) collection->forAll(expr
OclExpression) : Boolean Results in true if expr evaluates to true for each element in
collection; otherwise, result is false.
post: result = collection->iterate(elem; acc : Boolean = true |
acc and expr)
9.8.2.2 Set
The Set is the mathematical set. It contains elements without duplicates. Features of
Set, the instance of Set is called set.
collection->isUnique(expr : OclExpression) : Boolean
Results in true if expr evaluates to a different value for each element in collection;
otherwise, result is false.
post: let values = collection->collect(expr) in
result = res->forAll(e | values->count(e) = 1)
collection->sortedBy(expr : OclExpression) : Sequence(T)
Results in the Sequence containing all elements of collection. The element for which expr
has the lowest value comes first, and so on. The type of the expr expression must have
the < operation defined. The < operation must return a Boolean value and must be
transitive (i.e., if a < b and b < c, then a < c). pre: expr.evaluationType().operations()>includes(‘<‘) post: result->includesAll(collection) and collection->includesAll(result)
collection->iterate(expr : OclExpression) : expr.evaluationType() Iterates over the
collection. See Section 6.6.5, “Iterate Operation,” on page 6-26 for a complete
description. This is the basic collection operation with which the other collection
operations can be described. collection->any(expr : OclExpression) : T Returns any
element in the collection for which expr evaluates to true. If there is more than one
element for which expr is true, one of them is returned. The precondition states that there
must be at least one element fulfilling expr; otherwise, the result of this operation is
Undefined. pre: collection->exists( expr ) post collection->select(expr)->includes(result)
collection->one(expr : OclExpression) : Boolean Results in true if there is exactly one
element in the collection for which expr is true.
post: collection->select(expr)->size() = 1
set->union(set2 : Set(T)) : Set(T)
The union of set and set2.
HL7 Template and Archetype Architecture
Template Special Interest Group
105
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
post: result->forAll(elem | set->includes(elem) or set2->includes(elem)) post: set>forAll(elem | result->includes(elem)) post: set2->forAll(elem | result->includes(elem))
set->union(bag : Bag(T)) : Bag(T)
The union of set and bag. post: result->forAll(elem | result->count(elem) = set>count(elem) + bag->count(elem)) post: set->forAll(elem | result->includes(elem)) post:
bag->forAll(elem | result->includes(elem))
set = (set2 : Set(T)) : Boolean
Evaluates to true if set and set2 contain the same elements.
post: result = (set->forAll(elem | set2->includes(elem)) and
set2->forAll(elem | set->includes(elem)) )
set->intersection(set2 : Set(T)) : Set(T)
The intersection of set and set2; that is, the set of all elements that are in both set and
set2.
post: result->forAll(elem | set->includes(elem) and set2->includes(elem)) post: set>forAll(elem | set2->includes(elem) = result->includes(elem)) post: set2->forAll(elem |
set->includes(elem) = result->includes(elem)) set->intersection(bag : Bag(T)) : Set(T)
The intersection of set and bag. post: result = set->intersection( bag->asSet ) set – (set2 :
Set(T)) : Set(T)
The elements of set, which are not in set2. post: result->forAll(elem | set>includes(elem) and set2->excludes(elem)) post: set->forAll(elem | result>includes(elem) = set2->excludes(elem)) set->including(object : T) : Set(T)
The set containing all elements of set plus object. post: result->forAll(elem | set>includes(elem) or (elem = object)) post: set->forAll(elem | result->includes(elem)) post:
result->includes(object) set->excluding(object : T) : Set(T)
The set containing all elements of set without object. post: result->forAll(elem | set>includes(elem) and (elem <> object)) post: set->forAll(elem | result->includes(elem) =
(object <> elem)) post: result->excludes(object)
9.8.2.3 Bag
A bag is a collection with duplicates allowed. That is, one object can be an element of
a bag many times. There is no ordering defined on the elements in a bag.
set->symmetricDifference(set2 : Set(T)) : Set(T)
The sets containing all the elements that are in set or set2, but not in both. post:
result->forAll(elem | set->includes(elem) xor set2->includes(elem)) post: set>forAll(elem | result->includes(elem) = set2->excludes(elem)) post: set2>forAll(elem | result->includes(elem) = set->excludes(elem)) set->select(expr :
OclExpression) : Set(T)
The subset of set for which expr is true.
post: result = set->iterate(elem; acc : Set(T) = Set{} |
if expr then acc->including(elem) else acc endif)
set->reject(expr : OclExpression) : Set(T)
The subset of set for which expr is false.
post: result = set->select(not expr)
HL7 Template and Archetype Architecture
Template Special Interest Group
106
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
set->collect(expr : OclExpression) : Bag(expr.evaluationType() ) The Bag of elements
that results from applying expr to every member of set. post: result = set->iterate(elem;
acc : Bag(expr.evaluationType() ) = Bag{} | acc->including(expr) )
set->count(object : T) : Integer
The number of occurrences of object in set.
post: result <= 1
set->asSequence() : Sequence(T)
A Sequence that contains all the elements from set, in undefined order. post: result>forAll(elem | set->includes(elem)) post: set->forAll(elem | result->count(elem) = 1) set>asBag() : Bag(T)
The Bag that contains all the elements from set. post: result->forAll(elem | set>includes(elem)) post: set->forAll(elem | result->count(elem) = 1)
Properties of Bag, where the instance of Bag is called bag.
bag = (bag2 : Bag(T)) : Boolean
True if bag and bag2 contain the same elements, the same number of times. post: result
= (bag->forAll(elem | bag->count(elem) = bag2->count(elem)) and bag2->forAll(elem |
bag2->count(elem) = bag->count(elem)) ) bag->union(bag2 : Bag(T)) : Bag(T)
The union of bag and bag2. post: result->forAll( elem | result->count(elem) = bag>count(elem) + bag2->count(elem)) post: bag->forAll( elem | result->count(elem) = bag>count(elem) + bag2->count(elem)) post: bag2->forAll( elem | result->count(elem) =
bag->count(elem) + bag2->count(elem)) bag->union(set : Set(T)) : Bag(T)
The union of bag and set. post: result->forAll(elem | result->count(elem) = bag>count(elem) + set->count(elem)) post: bag->forAll(elem |result->count(elem) = bag>count(elem) + set->count(elem)) post: set->forAll(elem |result->count(elem) = bag>count(elem) + set->count(elem)) bag->intersection(bag2 : Bag(T)) : Bag(T)
The intersection of bag and bag2. post: result->forAll(elem | result->count(elem) = bag>count(elem).min(bag2->count(elem)) ) post: bag->forAll(elem |result->count(elem) =
bag->count(elem).min(bag2->count(elem)) ) post: bag2->forAll(elem |result>count(elem) = bag->count(elem).min(bag2->count(elem)) ) bag->intersection(set :
Set(T)) : Set(T)
The intersection of bag and set. post: result->forAll(elem | result->count(elem) = bag>count(elem).min(set->count(elem)) ) post: bag->forAll(elem |result->count(elem) =
bag->count(elem).min(set->count(elem)) ) post: set->forAll(elem |result->count(elem) =
bag->count(elem).min(set->count(elem)) ) bag->including(object : T) : Bag(T)
The bag containing all elements of bag plus object.
post: result->forAll(elem |
if elem = object then
result->count(elem) = bag->count(elem) + 1
else
result->count(elem) = bag->count(elem)
endif)
post: bag->forAll(elem |
if elem = object then
result->count(elem) = bag->count(elem) + 1
else
result->count(elem) = bag->count(elem)
HL7 Template and Archetype Architecture
107
Template Special Interest Group
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
endif)
bag->excluding(object : T) : Bag(T)
The bag containing all elements of bag apart from all occurrences of object.
post: result->forAll(elem |
if elem = object then
result->count(elem) = 0
else
result->count(elem) = bag->count(elem)
endif)
post: bag->forAll(elem |
if elem = object then
result->count(elem) = 0
else
result->count(elem) = bag->count(elem)
endif)
bag->select(expr : OclExpression) : Bag(T)
The sub-bag of bag for which expr is true.
post: result = bag->iterate(elem; acc : Bag(T) = Bag{} |
if expr then acc->including(elem) else acc endif)
bag->reject(expr : OclExpression) : Bag(T)
The sub-bag of bag for which expr is false.
post: result = bag->select(not expr)
bag->collect(expr: OclExpression) : Bag(expr.evaluationType() ) The Bag of elements
that results from applying expr to every member of bag. post: result = bag->iterate(elem;
acc : Bag(expr.evaluationType() ) = Bag{} | acc->including(expr) )
bag->count(object : T) : Integer
The number of occurrences of object in bag.
bag->asSequence() : Sequence(T)
A Sequence that contains all the elements from bag, in undefined order. post: result>forAll(elem | bag->count(elem) = result->count(elem)) post: bag->forAll(elem | bag>count(elem) = result->count(elem)) bag->asSet() : Set(T)
The Set containing all the elements from bag, with duplicates removed. post: result>forAll(elem | bag->includes(elem) ) post: bag->forAll(elem | result->includes(elem))
9.8.2.4 Sequence
A sequence is a collection where the elements are ordered. An element may be part of
a sequence more than once.
Properties of Sequence(T), where the instance of Sequence is called sequence.
sequence->count(object : T) : Integer
The number of occurrences of object in sequence.
sequence = (sequence2 : Sequence(T)) : Boolean
True if sequence contains the same elements as sequence2 in the same order. post: result
= Sequence{1..sequence->size()}->forAll(index : Integer | sequence->at(index) =
sequence2->at(index))
and
HL7 Template and Archetype Architecture
Template Special Interest Group
108
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
sequence->size() = sequence2->size()
sequence->union (sequence2 : Sequence(T)) : Sequence(T)
The sequence consisting of all elements in sequence, followed by all elements in
sequence2.
post: result->size() = sequence->size() + sequence2->size()
post: Sequence{1..sequence->size()}->forAll(index : Integer |
sequence->at(index) = result->at(index))
post: Sequence{1..sequence2->size()}->forAll(index : Integer |
sequence2->at(index) =
result->at(index + sequence->size() )))
sequence->append (object: T) : Sequence(T)
The sequence of elements, consisting of all elements of sequence, followed by object.
post: result->size() = sequence->size() + 1
post: result->at(result->size() ) = object
post: Sequence{1..sequence->size() }->forAll(index : Integer | result->at(index) =
sequence ->at(index)) sequence->prepend(object : T) : Sequence(T)
The sequence consisting of object, followed by all elements in sequence.
post: result->size = sequence->size() + 1
post: result->at(1) = object
post: Sequence{1..sequence->size()}->forAll(index : Integer | sequence->at(index) =
result->at(index + 1)) sequence->subSequence(lower : Integer, upper : Integer) :
Sequence(T) The sub-sequence of sequence starting at number lower, up to and including
element number upper.
pre : 1 <= lower
pre : lower <= upper
pre : upper <= sequence->size()
post: result->size() = upper -lower + 1
post: Sequence{lower..upper}->forAll( index |
result->at(index - lower + 1) =
sequence->at(index))
endif
sequence->at(i : Integer) : T
The i-th element of sequence.
pre : i >= 1 and i <= sequence->size()
sequence->first() : T
The first element in sequence.
post: result = sequence->at(1)
sequence->last() : T
The last element in sequence.
post: result = sequence->at(sequence->size() )
sequence->including(object : T) : Sequence(T)
The sequence containing all elements of sequence plus object added as the last element.
post: result = sequence.append(object) sequence->excluding(object : T) : Sequence(T)
The sequence containing all elements of sequence apart from all occurrences of object.
The order of the remaining elements is not changed. post:result->includes(object) = false
HL7 Template and Archetype Architecture
Template Special Interest Group
109
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
post: result->size() = sequence->size() - sequence->count(object) post: result = sequence>iterate(elem; acc : Sequence(T)
= Sequence{}|
if elem = object then acc else acc->append(elem) endif )
sequence->select(expression : OclExpression) : Sequence(T)
The subsequence of sequence for which expression is true.
post: result = sequence->iterate(elem; acc : Sequence(T) = Sequence{} | if expr then acc>including(elem) else acc endif)
9.9
Grammar
This section describes the grammar for OCL expressions. An executable LL(1) version of
this grammar is available on the OCL web site. (See http://www.software.ibm.com/ad/ocl).
The grammar description uses the EBNF syntax, where “|” means a choice, “?”
optionality, and “*” means zero or more times, “+” means one or more times, and
expressions delimited with “/*” and “*/” are definitions described with English words or
sentences. In the description of string, the syntax for lexical tokens from the JavaCC
parser generator is used. The “~” symbol denotes that none of the symbols following may
be matched. It means “everything except the following.”
oclFile := ( “package” packageName
oclExpressions
“endpackage”
)+
packageName := pathName
oclExpressions := ( constraint )*
constraint := contextDeclaration
( ( “def” name? “:” letExpression* )
|
sequence->reject(expression : OclExpression) : Sequence(T)
The subsequence of sequence for which expression is false.
post: result = sequence->select(not expr)
sequence->collect(expression : OclExpression) : Sequence(expression.evaluationType() )
The Sequence of elements that results from applying expression to every member of
sequence.
sequence->iterate(expr : OclExpression) : expr.evaluationType() Iterates over the
sequence. Iteration will be done from element at position 1 up until the element at the last
position following the order of the sequence. sequence->asBag() : Bag(T)
The Bag containing all the elements from sequence, including duplicates. post: result>forAll(elem | sequence->count(elem) = result->count(elem) ) post: sequence>forAll(elem | sequence->count(elem) = result->count(elem) ) sequence->asSet() : Set(T)
The Set containing all the elements from sequence, with duplicated removed. post:
result->forAll(elem | sequence->includes(elem)) post: sequence->forAll(elem | result>includes(elem))
( stereotype name? “:” oclExpression)
)+
contextDeclaration := “context”
( operationContext | classifierContext )
HL7 Template and Archetype Architecture
Template Special Interest Group
110
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
classifierContext := ( name “:” name )
| name
operationContext := name “::” operationName “(“ formalParameterList “)”
( “:” returnType )?
stereotype := ( “pre” | “post” | “inv” )
operationName := name | “=” | “+” | “-“ | “<” | “<=” |
“>=” | “>” | “/” | “*” | “<>” |
“implies” | “not” | “or” | “xor” | “and”
formalParameterList := ( name “:” typeSpecifier
(“,” name “:” typeSpecifier )*
)?
typeSpecifier := simpleTypeSpecifier
| collectionType
collectionType := collectionKind
“(“ simpleTypeSpecifier “)”
oclExpression := (letExpression* “in”)? expression
returnType := typeSpecifier
expression := logicalExpression
letExpression := “let” name
( “(“ formalParameterList “)” )?
( “:” typeSpecifier )?
“=” expression
ifExpression := “if” expression
“then” expression
“else” expression
“endif”
logicalExpression := relationalExpression
( logicalOperator
relationalExpression
)*
relationalExpression := additiveExpression
( relationalOperator
additiveExpression
)?
additiveExpression := multiplicativeExpression
( addOperator
multiplicativeExpression
)*
multiplicativeExpression:= unaryExpression
( multiplyOperator
unaryExpression
)*
unaryExpression := ( unaryOperator
postfixExpression
)
| postfixExpression
postfixExpression := primaryExpression
( (“.” | “->”)propertyCall )*
HL7 Template and Archetype Architecture
Template Special Interest Group
111
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
primaryExpression := literalCollection
| literal
| propertyCall
| “(“ expression “)”
| ifExpression
propertyCallParameters := “(“ ( declarator )?
( actualParameterList )? “)”
literal := string
| number
| enumLiteral
enumLiteral := name “::” name ( “::” name )*
simpleTypeSpecifier := pathName
literalCollection := collectionKind “{”
( collectionItem
(“,” collectionItem )*
)?
“}”
collectionItem := expression (“..” expression )?
propertyCall := pathName
( timeExpression )?
( qualifiers )?
( propertyCallParameters )?
qualifiers := “[” actualParameterList “]”
declarator := name ( “,” name )*
( “:” simpleTypeSpecifier )?
( “;” name “:” typeSpecifier “=”
expression
)?
“|”
pathName := name ( “::” name )*
timeExpression := “@” “pre”
actualParameterList := expression (“,” expression)*
logicalOperator := “and” | “or” | “xor” | “implies”
collectionKind := “Set” | “Bag” | “Sequence” | “Collection”
relationalOperator := “=” | “>” | “<” | “>=” | “<=” | “<>”
addOperator := “+” | “-“
multiplyOperator := “*” | “/”
unaryOperator := “-“ | “not”
typeName :=charForNameTop charForName*
name := charForNameTop charForName*
charForNameTop := /* Characters except inhibitedChar
and [”0”-“9”]; the available
characters shall be determined by
the tool implementers ultimately.*/
charForName := /* Characters except inhibitedChar; the
available characters shall be determined
by the tool implementers ultimately.*/
HL7 Template and Archetype Architecture
Template Special Interest Group
112
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
inhibitedChar := “ “ | “\”” | “#” | “\’” | “(“ | “)” |
“*” | “+” | “,” | “-“ | “.” | “/” |
“:” | “;” | “<” | “=” | “>” | “@” |
“[” | “\\” | “]” | “{” | “|” | “}”
number := [”0”-“9”] ([”0”-“9”])*
( “.” [”0”-“9”] ([”0”-“9”])* )?
( (“e” | “E”) ( “+” | “-“ )? [”0”-“9”]
([”0”-“9”])*
)?
string := “’”
(( ~[”’”,”\\”,”\n”,”\r”] )
|(“\\”
( [”n”,”t”,”b”,”r”,”f”,”\\”,”’”,”\””]
| [”0”-“7”]
( [”0”-“7”] ( [”0”-“7”] )? )?
)
)
)*
“’”
HL7 Template and Archetype Architecture
Template Special Interest Group
113
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
10. TEMPLATE AND ARCHETYPE CONSTRAINTS ON CLINICAL
DATA: SYNTAX
10.1 ADL Formalism
7.1.1 Authors: Thomas Beale and Sam Heard, MD
Introduction
This paper describes a formal syntax for expressing archetypes and templates (see 0). The
syntax is structural, somewhat like that used in block-structured programming languages.
It has been arrived at after considering all aspects of the archetype lifecycle and with the
express aim of containing all the information in one authoritative document for each
archetype, which can be shared as required.
Any syntax can be understood as the computational equivalent of a structured model. In
this case, the model is that of archetypes, such as the openEHR archetype models
available at http://www.openehr.org/cgi-bin/document_list. In parsing theory, syntax is
“what goes into a parser”, and class instances (i.e. a “parse tree”) are created as a result.
Accordingly, every construct in the syntax has a direct class equivalent in an equivalent
class model. There are a number of reasons to devise a syntax, including:
It is a textual rendering of an archetype
It can be parsed in different ways according to need, e.g. to map to CDA, openEHR, or
CEN.
It is directly comprehensible to both humans and machines
A syntax can also be used as a means of sharing archetypes, in the sense that one syntax
can be potentially mapped to multiple class models of archetypes.
It should be noted that while the syntax described here is human readable and writable, it
is primarily intended to be authored with tools, in which color, block-structuring, and
rubric replacement for term codes would occur.
A number of important issues are dealt with in this paper, as part of devising a precise,
correct syntax. These include:
Archetype identification
Natural language translations
Relationship to terminologies
The relationship between archetypes and templates
Status
The work presented in this paper has been intentionally published in an unfinished form
in the hope of stimulating debate and convergence in both the international standards
arena and in implementation systems for archetypes and templates.
HL7 Template and Archetype Architecture
Template Special Interest Group
114
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
Syntax Overview
Typographical Conventions
The following typographical conventions are used:
Bold is used to indicate a keyword
[Blue] items in “[]” are used to indicate coded terms, i.e. entities that are supplied by a
terminology service with access to Snomed, UMLS, and LOINC etc. The key terms have
also been bolded in some places to help readability.
Magenta is used to indicate elements from the assumed reference model. Thus, where
ORGANISER is followed by items a few lines later, it means that in the assumed
reference model, there is a type ORGANISER with an attribute items.
Comments are in green.
Symbols
A terse mathematical style of symbols has been used. Like any syntax, archetypes could
be edited in the native syntax shown here (i.e. in an editor which works like a folding
editor, and displays the text directly as shown in this paper), or using any number of GUI
interfaces which might look quite different. Archetypes could also be saved directly in
the syntax shown here, or it might be converted to an XML or other form. No particular
importance should be attached to the concrete syntax used here – it is purely intended as a
mechanism for illustrating the semantics.
Basic elements of the syntax:
Wherever “name  {xxxx}” appears, this should be read as “the element name must have
a value in the set defined by the constraint ‘xxx’”; or equivalently, “the value of name
matches the constraint in ‘{}’”. The  operator can be thought of as “matches”.
Wherever “{}” appears, this should be read as a constraint specification notionally
evaluating to a set. What is between the {} is a statement, which may be complex and
nested, which evaluates to the set of allowable values for the element named on the LHS
of the  symbol
Symbols have been used for the sake of brevity and clarity, as follows:
Symbol Name
Meaning
Example
Set membership
Element of
A  {...}

Existential quantifier
For some ...
x : x > 4 and x < 5

There exists a (n)...
Universal quantifier
For all ...
x : x < 0 or x > -1

For every ...
Implication
implies – means that in A A  B

 B, if A is true, then B is
true.
Logical disjunction - OR
Or
AB

Logical conjunction And
AB

AND
HL7 Template and Archetype Architecture
Template Special Interest Group
115
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
Archetype Structure
The outer structure of an archetype is as follows:
header_part
archetype identification, meta-data
body_part
archetype
definition
terminology_part
terminology definitions and binding
The syntax of the header part of the archetype obeys the following form:
archetype
concept
[ specialise some.other.archetype.id ]
some.archetype.id
some_term
description
purpose: “xxxxx”
use: “xxxxx”
submitter: “xxxxx”
author: “xxxxx”
status: “xxxxx”
other_meta_data_item: “xxxxx”
Body Part Syntax
The body part of the archetype contains structured constraint statements defining some
domain concept; these are hierarchical and block-structured in form. Any given valid use
of the syntax is an actual archetype. Therefore, each block corresponds to something like
an “instance” of a class, rather than part of a class. Notional classes define the semantics
of archetypes. Hierarchically arranged blocks of syntax correspond to composition of
objects in an archetype.
The general form of the body is as follows:
REF_MODEL_ ENTITY node ocurrences  {1..1}  {
meaning
name

ref_model_attribute  { constraint }
{term/text
[term]
constraint}
ref_model_relationship existence  {1..1}  {
REF_MODEL_ENTITY node ocurrences  {1..1}  {
...etc
HL7 Template and Archetype Architecture
Template Special Interest Group
116
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
}
}
Every block is either a node in the current archetype, or a new archetype (see
composition, below). Nodes are indicated by the node keyword, which introduces a new
node, or the use keyword, which indicates to use a node of the correct type, defined
earlier in the same archetype. The archetype keyword introduces constraints indicating
which other archetypes are allowed at the point it occurs.
Existence/cardinality constraints have been inserted straight after the node types names,
such as ORGANISER. Technically, they should come before these names, but it seems
more readable the other way around.
Each occurrence of REF_MODEL_ ENTITY is the name of an entity in the reference
model to which the archetype is targeted. This may be a particular reference model such
as the openEHR, CDA or RIM models, or it might be a more abstract shared model, e.g. a
lowest common denominator of CDA, openEHR and revised CEN 13606. Each
occurrence of ref_model_attribute is likewise the name of an attribute in the enclosing
entity; similarly each occurrence of ref_model_relationship refers to a relationship of the
enclosing entity to another entity in the same reference model.
The attributes name and meaning are assumed to exist on every logical node in all
archetypes, and are the basis of paths, node-level identification in data, automatic
archetype processing, archetype-archetype comparison and many other things. (In the
physical representation of an archetype this might not always be true. For example, a
logical Table has names and meanings in logically sensible places, e.g. column and row
names).
Almost all {} sections in an archetype correspond to a formal type in the structural
archetype model which is the equivalent of the syntax. For example:
ELEMENT node ocurrences  {1..1}  {
meaning
[AT0001]
-heart
rate
name  {AC0001} – constrain term to SNOMED heart rate and synonyms
value  { type  {QUANTITY}; value  {0-1000}; units  {/min}}
}
This block corresponds to an instance of the class C_ELEMENT in the openEHR Data
structure archetype model – in other words, a constraint on instances of type ELEMENT
from the corresponding reference model. The constraint in the last line of the example
similarly corresponds to an instance of the class C_QUANTITY, which defined the
semantics of constraint on the class QUANTITY. Although the openEHR types have
been used as a basis here, the above syntax is applicable to similar constructs in other
reference models.
Terminology Part
The terminology part of the archetype is where local archetype terms are defined, and
where the bindings of these terms and also term constraints to real terminologies are
HL7 Template and Archetype Architecture
Template Special Interest Group
117
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
expressed. It also contains foreign language translations. The form of this section is as
follows:
terminology_definitions
primary_language = language_id
languages_available = { language_id, language_id, etc }
terminologies_available = {terminology_id, terminology_id, etc }
term_definitions(language_id) = {
local_term_id = { definition}
local_term_id = { definition}
etc
}
constraint_definitions(language_id) = {
local_constraint_id = {description = “xxxxxx” }
}
--reference_terminologies
term_binding(terminology_id) = {
local_term_id = {[code from terminology with id terminology_id]}
local_term_id = {[code from terminology with id terminology_id]}
etc
}
constraint_binding(terminology_id) = {
local_constraint_id = {some constraint}
local_constraint_id = {some constraint}
etc
}
Because the issues to do with terminologies are quite complex, the terminology part of an
archetype is described in detail further down.
Identification
Archetypes can be identified with various kinds of identifiers. We propose only two here:
the ISO Oid and a multi-axial meaningful identifier. The identifiers are declared in the
heading section of the archetype, along with the concept defined by the archetype, e.g.
archetype
mayo.iso-ehr.entry.haematology.v1
concept [AT0004] -- complete blood count
ISO Oid Id
ISO Oids can be used to unambiguously identify archetypes within storage systems,
online repositories etc, regardless of where the archetype sits in the concept space.
HL7 Template and Archetype Architecture
118
Template Special Interest Group
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
To be determined: who issues the OID? Must be the maintaining/approving authority?
Multi-axial Archetype Identifier
A meaningful multi-axial identifier has a different purpose from the OID-based id: it
encodes the partitioning of the archetype concept space in the identifier. Each identifier
instance denotes a single archetype within a versioned 3-dimensional space, with the
dimensions being:
Originating organisation
Reference model entity, i.e. target of archetype
Domain concept
As with any multi-axial identifier, the underlying principle of an archetype id is that all
parts of the id must be able to be considered immutable. This means that no variable
characteristic of an archetype (e.g. accrediting authority, which might change due to later
accreditation by another authority, or may be multiple) can be included in its identifier.
The syntax of an Archetype id is as follows:
archetype_id: archetype_originator ‘.’ qualified_rm_entity ‘.’ domain_concept ‘.’ version_id
qualified_rm_entity: rm_originator ‘:’ rm_id ‘:’ rm_entity
domain_concept: concept_name { ‘:’ specialisation }*
version_id: ‘v’ NUMBER
archetype_originator: NAME
rm_originator: NAME
rm_entity: NAME
domain_concept: NAME
specialisation: NAME
NUMBER: [0-9]*
NAME: [a-z][a-z0-9()/%$#&]*
The field meanings are as follows:
archetype_originator: id of organisation originating this archetype;
rm_originator: id of organisation originating the reference model on which this
archetype is based;
rm_id: id of the reference model on which the archetype is based;
rm_entity: ontological level in the reference model;
domain_concept: the domain concept name, including any specialisations;
version_id: numeric version identifier;
Examples of archetype identifiers include:
racgp.openehr:ehr_rm:organiser.physical_examination.v2
racgp.openehr:ehr_rm:organiser.physical_examination:prenata
l.v1
nictiz.hl7:rim:act.progress_note.v1
uk-nhs.openehr:ehr_rm:entry.progress_note:naturopathy.v2
HL7 Template and Archetype Architecture
Template Special Interest Group
119
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
A basic rule for the multi-axial archetype identifier is that it changes as soon as anything
is done to the archetype, which makes data created using the previous form invalid with
respect to the changed form. For this reason, version is included in the identifier (see
discussion below).
To be determined: it is not currently known if archetype lifecycle state should appear in
the archetype id. However, since a “draft” archetype could clearly differ from an
“approved” version of the same one, probably it should be. How would this be done? One
attractive way is that sub-1.0 version ids be used, e.g. any archetype with a version
number like v0.8 is guaranteed not to be the same as the v1.0 form of the same archetype.
The version part of the id could also simply use lifecycle state names until getting to the
“1.0” stage, e.g. vdraft, vtest, etc.
Archetype Metadata
All archetypes contain descriptive ‘metadata’, which is associated with their creation and
maintenance lifecycle, but is not generally used computationally. The model of meta-data
used here is based on various archetype and template work, and is shown in the
ARCHETYPE_DESCRIPTION class in the following model, taken from the openEHR
Common Archetype Model. The design of this model is based on GEHR, SynEx and the
HL7 Templates proposal.
HL7 Template and Archetype Architecture
Template Special Interest Group
120
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
In the syntax described in this paper, all meta-data items are entered in thee header
section of an archetype, as in the following example.
archetype
mayo.iso-ehr.entry.haematology.v1
concept [AT0004] -- complete blood count
description
purpose: “generic haematology archetype”
revision: 3
use: “for recording haematology results; as a basis for specialised blood chemistry result
archetypes”
submitter: “Mayo Clinic”
author: “Dr Hank Marvin”
status: “development”
To be continued: The design of the archetype lifecycle has not been finalised.
HL7 Template and Archetype Architecture
Template Special Interest Group
121
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
Archetype Relationships
Archetypes can be related in a number of ways, as described below.
Composition
The composition relationship between archetypes occurs when at some node in an
archetype, a new archetype would occur, rather than a continuation of the constraints in
the current archetype. The purpose of composition is to allow separate archetypes to be
connected together at runtime to form a template, which is then used to create and/or
validate data.
In the openEHR archetype system, technically all nodes can be archetyped, but only
some nodes can sensibly archetyped. These include at least:
TRANSACTION (=CDA Document, CEN Composition)
ORGANISER (=CDA Section, CEN Section)
ENTRY (~=CDA Entry, revised CEN Entry)
These types correspond to the levels at which distinct, self-contained domain concepts
can be defined. There may also be other nodes which might be sensibly archetyped, such
as HISTORY, TABLE, LIST etc, which are subparts of ENTRYs, and single
ORGANISERs which are part of ORGANISER trees. These smaller types do not make
sense as whole objects in an EHR, rather they are units of re-use in the archetype editing
environment.
Composition relationships are expressed in archetypes as constraints – i.e. statements
saying what archetypes are allowed to be attached at runtime. Composition is indicated in
the syntax by the archetype keyword in place of the node keyword. An example of an
archetype composition constraint is the following:
ENTRY archetype ocurrences  {0..*}  {id  {“*.iso-ehr.entry.*.*”}}
This says that any number of ENTRY archetypes are allowed, which must conform to the
constraint {id  {“*.iso-ehr.entry.*.*”}}, which means that the id must match the pattern “*.isoehr.entry.*.*”. Other constraints are possible as well, including that the allowed archetype must
contain a certain keyword, or a certain path. The latter is quite powerful – it allows archetypes to
be linked together on the basis of context. For example, under a “genetic relatives” heading in a
Family History Organiser archetype, the following logical constraint might be used:
ENTRY archetype ocurrences  {0..*}  {type  ENTRY and subject.relation 
{“parent” or “sibling”} }
Specialization
Archetypes can be specialised. The basic rule for specialisation is that data created
according to the more specialised archetype is guaranteed to conform to the parent
archetype. Specialisations have an id based on the parent archetype id, but with a
modified part, as described earlier. In the archetype syntax, specialisation is declared in
the header clause, e.g. as follows:
archetype
concept [AT0004] -- complete blood count
mayo.iso-ehr.entry.haematology:cbc.v1
HL7 Template and Archetype Architecture
122
Template Special Interest Group
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
specialise mayo.iso-ehr.entry.haematology.v1
This says that the CBC archetype is a specialisation of a general haematology one.
Where specialisation is used, all the features of the parent are assumed in the descendant,
including:
local term codes
local constraint codes
Changes can only be made in a disciplined way according to specified rules.
Versions
New versions of an existing archetype can be created. A new version is required for any
change to an archetype which fixes an error, and creates as a result a non-conforming
archetype. A data conversion algorithm must always be supplied with a new version.
Versions are indicated in the archetype id, meaning that two versions of the same logical
archetype are technically speaking two different archetypes.
Revisions
Archetypes can also be revised, meaning that any change which does not compromise
data created according to the earlier revision can be incorporated without creating a new
version or a specialisation. Situations where revisions are used include:
the addition of a new foreign language translation
the addition of a new terminology binding
weakening of some constraints, e.g. cardinalities being changed from 1..1 to 0..1
Since a revised archetype is 100% backwards compatible with its predecessor, revision
does not cause the archetype id to be changed – revision ids only occur as meta-data.
Relationship with Knowledge – Ontologies and Terminology
Design Time Node Names
There are three places where archetypes relate to knowledge. First, the design time name,
or meaning, of every node in an archetype is a normative, fixed value, which should be
mapped to an ontology or terminology if possible. This mapping, or “binding”, is
expressed in the archetype in a term_binding section. Language tables are included in the
archetype to enable language translation. However, no assumptions have been made
about the availability of terms for specific uses.
Runtime Node Name Constraints
Second, the runtime name of a node in actual data may be drawn from a terminology. The
use and value of runtime names may be constrained by the archetype. In situations where
the archetype is terminology driven – for example the use of LOINC for the names of
laboratory tests – the constraint needs to be completely expressed in terms of coded
values. This constraint is added to the archetype as a constraint_binding. Where the
archetype does not rely on terminology for labels that will be used in queries or reporting
the paths (or node Ids) can be based on the ‘meaning’ described above.
HL7 Template and Archetype Architecture
Template Special Interest Group
123
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
Values
Third, the value of an element may be drawn from a subset of a terminology. There is a
need, therefore, to be able to express a constraint on the possible values for any element
that is a CODED_TEXT in the archetype.
Due to these factors, the archetype language presented here uses local term ids for all
“terms” used in node meanings, and local constraint ids for all constraints on terms. Local
term ids are denoted ATnnnn, and constraint ids are denoted ACnnnn.
Terminology Definitions and Bindings
As a consequence, the main body of the archetype is completely independent of
terminologies and particular natural languages. In all places where terms might occur,
archetype local codes of the form ‘ATnnnn’ are used instead; the same for constraints on
terms, using codes of the form ‘ACnnnn’. All mappings of these local codes and term
constraints are defined in a special section of the archetype dedicated to describing the
relationship with terminologies. These ids are guaranteed immutable for the life of the
archetype, in all languages. The effect of this is to create archetype-local “microterminologies”, enabling all node meanings to be specified, and if possible bound to
terms in official terminologies.
The following is an example of an archetype terminology section:
terminology_definitions
primary_language = en
languages_available = {en, de}
terminologies_available = {SNOMED-CT(2003), UMLS(2002)}
term_definitions(en) = {
AT0001 = { text = « problem/SOAP headings »;
description = “SOAP heading structure for multiple problems”}
}
constraint_definitions(en) = {
AC0001 = {description = « SNOMED terms that are used as the primary value of
problems in the problem oriented EHR» }
}
term_definitions(de) = {
AT0001 = { text = « German text »; description = “German text”}
}
constraint_definitions(de) = {
AC0001 = {description = « German text» }
}
--reference_terminologies
term_binding(UMLS(2002)) = {
AT0001 = {[C000234]} -- problem
HL7 Template and Archetype Architecture
Template Special Interest Group
124
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
}
term_binding(SNOMED-CT(2003)) = {
AT0001 = {[128004]} – problem type
}
constraint_binding(SNOMED-CT(2003)) = {
AC0001 = {has-relation [102002] with-target [128004]} – is-a problem_type
}
}
In the above, the sections are as follows:
primary_language: language in which archetype was authored. Although archetypes
should be completely multi-lingual, it is important to know the source language, in case
any other language translation contains errors.
languages_available: a list of languages in which the archetype can be used – includes
the original language plus all languages of translation.
terminologies_available: list of terminologies used in the binding. This does not mean
that these terminologies are required for using the archetype to create or validate data, but
they would be required for a query engine or decision support tool to do inferencing,
which relied on the terminologies.
term_definitions(language_id): the normative meanings in a given language of the nodes
of the archetype, keyed by local codes of the form “ATnnnn”. A 4-digit code allows for
10,000 distinct codes per archetype, a number unlikely to ever be used. (However, if it
was to be surpassed, alphabetic characters could be allowed as well, enabling 36^4 codes
per archetype). Each new language added to the archetype simply requires the addition of
a new term_definitions section for that language.
constraint_definitions(language_id): the descriptions of the constraints, keyed by local
codes in the form “ACnnnn" making the descriptions available in different languages.
term_bindings(terminology_id): the bindings of the archetype internal codes to code
phrases in external terminologies. Some internal codes may have no binding available –
at least in the first instance.
constraint_binding(terminology_id): the binding of the archetype constraint codes
(ACnnnn) to constraints expressed appropriately against an assumed underlying
knowledge base.
Additions of new term_bindings and constraint_bindings sections and new language
definition sections can be made as new revisions, i.e. they do not change the archetype
fundamentally. This will provide great utility in the gradual multilingual development of
archetypes.
Paths
In the syntax for each node, there is an attribute called meaning, defined on every node in
an archetype. This is the normative meaning of the node expressed as a surrogate ‘id’ and
defined in the archetype term_definitions section (in multiple languages) and linked to
knowledge in the term_bindings section. By concatenating these meanings, any archetype
HL7 Template and Archetype Architecture
Template Special Interest Group
125
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
node can be referred to by its path, e.g. in invariant expressions or queries. For example,
in the fragment:
LIST_S node  {
meaning
[AT0002
name
items existence  {1..1; ordered}  {
(battery
items)]
{“CBC”}

ELEMENT node ocurrences  {1..1}  {
meaning
[AT0003
(hemoglobin)]
name

{« Hb »}
value  { type  {QUANTITY}; value  {0-200}; units  {g/l}}
}
}
}
The path AT0002/AT0003, or as the user would see it “battery items”/”hemoglobin” can
be constructed from the values of the meaning attributes. At an abstract level, a path is
always a series of node meaning values. There may be more than one concrete syntax
possible, such as:
“Battery items”/”haemoglobin”
Battery items/haemoglobin
In this paper the former syntax is used.
Invariants
With paths, we can now write invariant expressions such as the following:
invariant
(“problem/SOAP
headings”/“Assessment”)
( (“problem/SOAP headings”/“Objective”)   (“problem/SOAP headings”/ “Subjective”))

This says that there can be no assessment items if there is not at least one of Subjective or
Objective items (i.e. something on which to base the assessment). Invariants can occur in
any node.
An invariant can be written for any node block in an archetype. The syntax of invariants
will generally follow a first order predicate logic model, such as found in the Eiffel
language and under development currently in the OMG’s Object Constraint Language
(OCL).
Status: OCL currently contains a number of errors, including a couple of serious ones.
Independent work in Australia on the syntax specification has shown numerous errors
and problems. Some of these are pointed out in the short review at
http://www.deepthought.com.au/it/ocl_review.html).
Currently it is suggested to use an adaptation of OCL, “written the way it should have
been”. This can be developed fairly quickly, based on existing experience in software
correctness assertions, design by contract, and mathematical logic and knowledge
representation. See e.g. Bertrand Meyer, Haim Kilov and John Sowa among others.
HL7 Template and Archetype Architecture
Template Special Interest Group
126
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
Templates
The purpose of templates is to define combinations of archetypes to be used for particular
purposes at runtime. Templates are characterised by the following conditions:
they define archetype “chains” or “trees” by making choices of particular archetypes to
fill composition points
they may narrow constraints in the archetypes mentioned
they may add default values and structure
Templates rely on paths to be able to make statements. The general syntax of a template
is similar to an archetype, as follows:
header_part
template identification, meta-data
body_part
definition
terminology_part
terminology definitions and binding
Foreign Languages
The archetype syntax described here is intended to work in any language, and does not
treat any language (i.e. English!) as a special language (although the examples here have
English as their primary language, due to the authors’ background). In all the examples,
English rubrics for terms are shown as comments. Readers whose mother tongue is not
English need to simply imagine these comments being rendered in their own language
within their archetype development environment.
Important aspects of handling foreign languages:
Any language may be the primary language of an archetype
Any languages may be added to the translations sections, at or after authoring times
Even if there are no bindings to terminologies or no terminologies available, archetypes
will work in all languages in which they are translated
Some terminologies will be a source of normative or accepted translations of certain
terms. In this case, these translations should be added to the archetype
In an online archetype library, the translations section of any given archetype is likely to
grow by merges done on offered copies containing new translations.
Having translations on a per-archetype basis may turn out to be very powerful, since it is
thought likely that some words, and “constellations of concepts” may be translated
differently on the basis of contextual use. This would mean that at least some translations
are safer inside archetypes, which are use-based, rather than in terminologies, where
contextual use cannot (and should not) be represented. Further research and experience
should show whether this conjecture is true in the future.
HL7 Template and Archetype Architecture
Template Special Interest Group
127
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
Archetype Examples
In the following sections, a number of familiar clinical concepts are expressed in
archetype syntax form. These examples are not intended to indicate the optimal way to
model the concepts, just to show the syntax in use.
The archetype examples should be read in conjunction with the openEHR data types and
data structures specifications. The structural types are known by different names in other
systems, e.g. CDA. The mappings are:
OpenEHR
Transaction
HL7 CDA
Document
CEN 13606
Composition
CEN 13606 revision
Composition
Organiser
Section
Headed Section
Section
Data item
Element
Cluster
Cluster
History
List_s – a path- List – key word in
enabled
linear XML
structure (not the
generic language
feature List<>).
Item
Element
Compound
??
Entry
Entry
HL7 Template and Archetype Architecture
Template Special Interest Group
Entry
128
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
Blood Pressure
archetype
concept [AT0000]
--
racgp.openehr.entry.blood_pressue.v1
pressure
measurement
blood
ENTRY node  {
meaning [AT0001]
-name  {AC0001}
-data existence  {1}  {
synonym
blood
of
-- C_SINGLE_REL
pressure
pressure
blood
LIST_S node  {
items existence  {1..1; ordered}  {
-- C_LIST<C_CONTENT_ITEM>
ELEMENT node ocurrences  {1..1}  {
meaning [AT0002]
-systolic
BP
name  {AC0002}
-any
synonym
of
‘systolic’
value  { type  {QUANTITY}; value  {0-1000}; units  {mm[Hg]}}
} -- as a mandatory item a flavour of Null can be used if not recorded
ELEMENT node ocurrences  {1..1}  {
meaning [AT0003]
-diastolic
BP
name  {AC0003}
-any
synonym
of
‘diastolic’
value  { type  {QUANTITY}; value  {0-1000}; units  {mm[Hg]}}
} -- as a mandatory item a flavour of Null can be used if not recorded
ELEMENT node ocurrences  {0..*}  {
meaning [unknown]
-unknown
name  {any} -value  {any}
}
new
item
anything??
}
}
}
protocol existence  {0..1}  {
-- C_SINGLE_REL
LIST_S node  {
items existence  {1..1; ordered}  {
-- C_LIST<C_CONTENT_ITEM>
ELEMENT node ocurrences  {0..1}  {
meaning [AT0005]
-name  {AC0005}
-any
synonym
of
value  { type  {CODED_TEXT}; value  {AC0006} }
}
instrument
‘instrument’
ELEMENT node ocurrences  {0..1}  {
meaning [AT0007]
-name  {AC0007}
-- any synonym of patient
value  { type  {CODED_TEXT}; value  {AC0008} }
}
HL7 Template and Archetype Architecture
Template Special Interest Group
position
position
129
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
ELEMENT node ocurrences  {0..1}  {
meaning [AT0009]
-cuff
name  {AC0009}
-size
of
value  { type  {CODED_TEXT}; value  {AC0010} }
}
ELEMENT node ocurrences  {0..*}  {
meaning [unknown]
-unknown
name  { any } -value  {any }
}
new
size
cuff
item
any
}
}
}
}
terminology
primary_language = en
languages_available = {en, fr}
terminologies_available = {UMLS}
term_definitions(en) = {
AT0000 = { text = « blood pressure measurement »;
description = “the measurement of systemic arterial blood pressure which is
deemed to represent the actual systemic blood pressure”}
AT0001 = { text = « blood pressure »;
description = “systemic arterial blood pressure”}
AT0002 = { text = « systolic »;
description = “the systemic arterial blood pressure in systolic phase”}
AT0003 = { text = « diastolic »;
description = “the systemic arterial blood pressure in diastolic phase”}
AT0005 = { text = « instrument »;
description = “the instrument used to measure the blood pressure”}
AT0007 = { text = « position »;
description = “the position of the patient at the time of measuring the blood
pressure”}
AT0009 = { text = « cuff size »;
description = “the size of the cuff if a sphygmomanometer is used”}
}
term_binding(snomed-ct(2003)) = {
AT0000
= {364090009}
-Systemic
AT0001
=
{163020007} -O/E
Blood
AT0002 = {163030003} -- O/E - Systolic BP reading
HL7 Template and Archetype Architecture
Template Special Interest Group
arterial
pressure
pressure
reading
130
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
AT0003
=
{163031004}
-- O/E
AT0005
=
{57134006}
AT0007
=
{246273001} -AT0009 = {246153002} -- type of cuff
Diastolic
-patient
BP
reading
instrument
position
}
constraint_definition(en) = {
AC0001
=
{
text
=
« BP
»;
description = “any synonym of systemic blood pressure”}
AC0002
=
{
text
=
« systolic»;
description = “any synonym of systolic”}
AC0003
=
{
text
=
« diastolic»;
description = “any synonym of diastolic”}
AC0005
=
{
text
=
« instrument»;
description = “any synonym of of instrument”}
AC0006
=
{
text
=
« instrument
type»;
description = “any valid instrument for the measurement of blood pressure”}
AC0007
=
{
text
=
« position»;
description = “any synonym of patient position”}
AC0008
=
{
text
=
« patient
position
»;
description = “lying, reclining, sitting, standing”}
AC0009
=
{
text
=
« cuff
size»;
description = “any synonym of cuff size”}
AC0010
=
{
text
=
« BP
cuff
size»;
description = “neonatal, infant, child, adult, large adult”}
}
constraint_binding(snomed-ct(2003)) = {
--validity of AC0006 etc unknown
AC0001 = { synonym of [163020007]}
AC0002 = { synonym of [163030003]}
-- synonyms of systolic
AC0003 = { synonym of [163031004]}
-- synonyms of diastolic
AC0005 = { synonym of [57134006]}
-- synonyms of instrument
AC0006 = { has_relation [102002]
-- is-a
with_target [57134006]}
AC0007 = { synonym of [246273001]}
AC0008 = { has_relation [102002]
with_target [246273001]}
AC0009 = { synonym of [246153002]}
AC0010 = { has_relation [102002]
with_target [246153002]}
-- instrument
-- synonyms of position
-- is-a
-- patient position
-- synonyms of cuff size
-- is-a
-- cuff size
}
HL7 Template and Archetype Architecture
Template Special Interest Group
131
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
problem/SOAP Headings
archetype
concept [AT0000]
ihc.iso-ehr.section.soap_headings.v1
problem/SOAP
headings
--
ORGANISER node  {
meaning [AT0001]
name  {AC0001}
--
items existence  {1..1; ordered}  {
problem
-- C_LIST<C_CONTENT_ITEM>
ORGANISER node ocurrences  {0..1}  {
meaning [AT0002]
-name

items existence  {0..1; ordered}  {
-- can only be 0..1 or 1..1
subjective
{AC0002}
-- C_LIST<C_CONTENT_ITEM>
ENTRY archetype ocurrences  {0..*}  {id  {“*.iso-ehr.entry.*.*”}}
ORGANISER node ocurrences  {0..*}  {
meaning [unknown]
–
any
term
ok
name  {any}
}
ORGANISER archetype ocurrences  {0..*}  {id  {“*.isoehr.organiser.*.*”)}}
-- any organiser
}
}
ORGANISER node ocurrences  {0..1}  {
meaning [AT0003]
name

items existence  {0..1; ordered}  {
--
objective
{AC0003}
-- C_LIST<C_CONTENT_ITEM>
ENTRY archetype ocurrences  {0..*}  {id  {“*.iso-ehr.entry.*.*”}}
ORGANISER node ocurrences  {0..*}  {
meaning
[unknown]
name  {any}
}
ORGANISER archetype ocurrences  {0..*}  {id  {“*.isoehr.section.*.*”}}
}
}
ORGANISER node ocurrences  {0..1}  {
meaning [AT0004]
-name

items existence  {0..1; ordered}  {
assessment
{AC0004}
-- C_LIST<C_CONTENT_ITEM>
ENTRY archetype ocurrences  {0..*}  {id  {“*.iso-ehr.entry.*.*”}}
ORGANISER node ocurrences  {0..*}  {
HL7 Template and Archetype Architecture
Template Special Interest Group
132
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
meaning
[unknown]
name  {any}
}
ORGANISER archetype ocurrences  {0..*}  {id  {“*.isoehr.section.*.*”}}
}
}
ORGANISER node ocurrences  {0..1}  {
meaning [AT0005]
-name

items existence  {0..1; ordered}  {
plan
{AC0005}
-- C_LIST<C_CONTENT_ITEM>
ENTRY archetype ocurrences  {0..*}  {id  {“*.iso-ehr.entry.*.*”}}
ORGANISER node ocurrences  {0..*}  {
meaning
[unknown]
name  {any}
}
ORGANISER archetype ocurrences  {0..*}  {id  {“*.isoehr.section.*.*”}}
}
}
}
}
invariant
(“problem/SOAP
headings”/“Assessment”)

( (“problem/SOAP headings”/“Objective”)   (“problem/SOAP headings”/ “Subjective”))
terminology
primary_language = en
languages_available = {en, de}
terminologies_available = {SNOMED-CT(2003), UMLS(2002)}
term_definitions(en) = {
AT0000 = { text = « problem/SOAP headings »;
description = “SOAP heading structure for multiple problems”}
AT0001 = { text = « problem »;
description = “The problem experienced by the subject of care to which the
contained information relates”}
AT0002 = { text = « subjective »;
description = “That part of the information that was provided by the subject of
care (or another reporter) to the clinician”}
AT0003 = { text = « objective »;
description = “That part of the information that was provided by the clinician”}
AT0004 = { text = « assessment »;
HL7 Template and Archetype Architecture
Template Special Interest Group
133
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
description = “The clinician’s professional assessment of the problem”}
AT0005 = { text = « plan »;
description = “The clinician’s professional advice”}
}
term_definitions(de; translation = “[email protected]”) = {
AT0000 = { text = « Problem/SOAP Schema»;
description = “SOAP-Schlagwort-Gruppierungsschema fuer mehrfache
Probleme”}
AT0001 = { text = « klinisches Problem »;
description = “Das Problem des Patienten worauf sich diese
Informationen beziehen”}
AT0002 = { text = « subjektives»;
description = “Jene Informationen, die vom Patienten oder von anderer
patientennahe Quelle stammen”}
AT0003 = { text = « objektives»;
description = “Jene Informationen, die vom Pflegenden stammen”}
AT0004 = { text = « Auswertung »;
description = “Klinisch-professionelle Auswertung des Problems”}
AT0005 = { text = « Plan»;
description = “Klinisch-professionelle Beratung des Pflegenden”}
}
term_binding(SNOMED-CT(2003)) = {
AT0000 = { SOME_CODE}
AT0001 = {SOME_CODE}
-- problem
AT0002 = { SOME_CODE}
-- subjective
AT0003 = { SOME_CODE}
-- objective
AT0004 = { SOME_CODE}
-- assessment
AT0005 = { SOME_CODE}
-- plan
}
constraint_definitions(en)={
AC0001
=
{text
=
“problem
type”;
description = “any term that can be a problem, diagnosis or issue of significance to the
patient”}
AC0002
=
{text
=
“subjective”;
description = “any term that means information gained from the patient or other parties”}
AC0003
=
{text
=
“objective”;
description = “any term that means information measured by the clinician”}
AC0004
=
{text
=
“assessment”;
description = “any term that means an assessment by the clinician”}
AC0005
=
{text
=
“plan”;
description = “any term that means actions proposed by the clinician”}
}
HL7 Template and Archetype Architecture
Template Special Interest Group
134
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
constraint_binding(SNOMED-CT(2002)) {
AC0001 = {code_string  {has-relation [102002] -- is-a
with-target [128004]}} – problem type
AC0002 = {synonym of [128025]} -- subjective
AC0003 = {synonym of [128031]} -- objective
AC0004 = {synonym of [128034]} -- subjective
AC0005 = {synonym of [128090]} -- assessment
AC0006 = {synonym of [128093]} -- plan
}
HL7 Template and Archetype Architecture
Template Special Interest Group
135
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
Haematology result
archetype
concept [AT0000]
mayo.
--
ENTRY node  {
meaning [AT0001]
-name  {AC0001}
-data existence  {1}  {
iso-ehr.entry.haematology.v1
haematology
Name
-- C_SINGLE_REL
battery
battery
of
LIST_S node  {
items existence  {1..1; ordered}  {
-- C_LIST<C_CONTENT_ITEM>
ELEMENT node ocurrences  {1..1}  {
meaning [AT0002]
-haematology
name  {AC0002}
-name
of
value  {any}
-- any data type
}
test
test
item
item
}
}
}
}
terminology
primary_language = en
languages_available = {en, fr}
terminologies_available = {UMLS}
term_definitions(en) = {
AT0000 = { text = « haematology test results »;
description = “the results from testing blood by a haematology process”}
AT0001 = { text = « battery »;
description = “the name of the battery”}
AT0002 = { text = « haematology test item »;
description = “an individual test result in a haematology battery result”}
}
term_definitions(fr; translation = “[email protected]”) = {
AT0000 = { text = « resultat hématologie »;
description = “resultat d’un examen du sang par un processus
hématologique”}
AT0001 = { text = « groupe »;
description = “nom du groupe”}
AT0002 = { text = « élément mesuré »;
description = “ élément individuel dans un resultat d’examen”}
}
HL7 Template and Archetype Architecture
Template Special Interest Group
136
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
term_binding(UMLS) = {
AT0000 = {SOME_CODE}
AT0001 = {SOME_CODE}
AT0002 = {SOME_CODE}
}
constraint_definition(en) = {
AC0001
=
{
text
=
« haematology
description = “the name of the battery”}
AC0002
=
{
text
=
« haematology
test
description = “the name of the battery item”}
}
test
item
name
name
»;
»;
Complete Blood Count (CBC)
archetype
mayo.
concept [AT0003] -- haematology - complete blood count
specialise
mayo.
ENTRY node  {
meaning [AT0001]
-name  {AC0001}
-data existence  {1}  {
LIST_S node  {
iso-ehr.entry.haematology.cbc.v1
iso-ehr.entry.haematology.v1
battery
items
CBC
-- C_SINGLE_REL
items existence  {1..1; ordered}  {
-- C_LIST<C_CONTENT_ITEM>
ELEMENT node ocurrences  {1..1}  {
meaning [AT0002]
name  {AC0002}
-haemaglobin
value  { type  {QUANTITY}; value  {0-1000}; units  {g/l,g/dl}}
}
ELEMENT node ocurrences  {0..1}  {
meaning [AT0002]
name  {AC0003}
-haematocrit
value  { type  {QUANTITY}; value  {0-100}; units  {%}}
}
ELEMENT node ocurrences  {0..1}  {
meaning [AT0002]
name  {AC0004}
-platelet
count
value  { type  {QUANTITY}; value  {0-100000}; units  {/cm3}}
}
}
}
}
HL7 Template and Archetype Architecture
Template Special Interest Group
137
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
}
terminology
primary_language = en
languages_available = {en, fr}
terminologies_available = {LOINC(2002)}
term_definitions(en) = {
AT0000 = { text = « haematology test results »;
description = “the results from testing blood by a haematology process”}
AT0001 = { text = « battery »;
description = “the name of the battery”}
AT0002 = { text = « haematology test item »;
description = “an individual test result in a haematology battery result”}
Additions for this specialisation
AT0003 = { text = « complete blood picture »;
description = “an haematology test result reporting all standard features of
blood”}
}
term_definitions(fr; translation = “[email protected]”) = {
AT0000 = { text = « resultat hématologie »;
description = “resultat d’un examen du sang par un processus
hématologique”}
AT0001 = { text = « groupe »;
description = “nom du groupe”}
AT0002 = { text = « élément mesuré »;
description = “ élément individuel dans un resultat d’examen”}
AT0003 = { text = « numération globulaire »;
description = “SOME FR TEXT”}
}
term_binding(UMLS) = {
AT0000 = {SOME_CODE}
AT0001 = {SOME_CODE}
AT0002 = {SOME_CODE}
can add if known
}
constraint_definitions(en) = {
AC0001 = { text = « complete blood count »;
description = “a label for a standard haematology battery that reports
haemaglobin, haematocrit, platelet count….”}
AC0002 = { text = « haemaglobin »;
HL7 Template and Archetype Architecture
Template Special Interest Group
138
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
description = “an individual test result reporting the haemaglobin
concentration in the sample”}
AC0003 = { text = « haematocrit »;
description = “an individual test result reporting the pack cell volume of red
blood cells as a percentage of the sample”}
AC0004 = { text = « platelet count »;
description = “an individual test result reporting the number of platelets in a
cubic centimetre of the sample”}
}
constraint_bindings(LOINC(2002)) = {
AC0001 = {}
-- Complete blood picture
AC0002 = {[718-7]}
-- Hemoglobin (Blood)
AC0003 = {[4544-3],
-Hematocrit
[4545-0]-- Hematocrit (Blood) spun
}
AC0004 = {[778-1],
-Platelet
count
[777-3] -- Platelet count (Blood) automated
}
}
(Blood)
(Blood)
automated
manual
APGAR
archetype
concept [AT0001]
--
apgar
nictiz.iso-ehr.entry.apgar.v1
test
result
ENTRY node  {
subject_relationship  {AC0001}
data existence  {1}  {
-- C_SINGLE_REL
HISTORY node ocurrences  {1}  {
periodic

events existence  {1..1; ordered}  { -- C_LIST<C_CONTENT_ITEM>
{False}
EVENT node ocurrences  {0..1}  {
-- may not be recorded
meaning [AT0002]
-- 1 min
name  {AC0002}
offset  {1min}
data existence  {1}  { -- C_SINGLE_REL
LIST_S node  {
meaning [AT0003]
-- apgar items
name  {AC0003}
-- no runtime name
items  {
ELEMENT node ocurrences  {0..1}  {
meaning [AT0004]
-- cardiac score
HL7 Template and Archetype Architecture
Template Special Interest Group
139
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
name  {AC0004}
value  { type  {ORDINAL}; value  {0-2}; is_dimensionless 
{True}}
}
ELEMENT node ocurrences  {0..1}  {
meaning [AT0005]
-- respiratory score
name  {AC0005}
value  { type  {ORDINAL}; value  {0-2}; is_dimensionless 
{True}}
}
ELEMENT node ocurrences  {0..1}  {
meaning [AT0006]
-- muscle tone score
name  {AC0006}
value  { type  {ORDINAL}; value  {0-2}; is_dimensionless 
{True}}
}
ELEMENT node ocurrences  {0..1}  {
meaning [AT0007]
-- reflex response
name  {AC0007}
value  { type  {ORDINAL}; value  {0-2}; is_dimensionless 
{True}}
}
ELEMENT node ocurrences  {0..1}  {
meaning [AT0008]
--colour
name  {AC0008}
value  { type  {ORDINAL}; value  {0-2}; is_dimensionless 
{True}}
}
ELEMENT node ocurrences  {1}  {
meaning [AT0009]
-- total apgar score
name  {AC0009}
value  { type  {QUANTITY}; value  {0-10}; is_dimensionless 
{True}}
}
invariant:
[AT0004] AND  [AT0005] AND  [AT0006]
AND  [AT0007] AND  [AT0005]}

([AT0009]).value.value =
([AT0004]).value.value +
([AT0005]).value.value +
HL7 Template and Archetype Architecture
Template Special Interest Group
140
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
([AT0006]).value.value +
([AT0007]).value.value +
([AT0008]).value.value
}
}
EVENT node ocurrences  {0..1}  {
meaning [AT0010]
-- 2-minute event
name  {AC0010}
offset  {2min}
data existence  {1}  { -- C_SINGLE_REL
use ([AT0002]).data
-- list structure from first sample
}
}
EVENT node ocurrences  {0..1}  {
meaning [AT0011]
-- 5-minute event
name  {AC0011}
offset  {5min}
data existence  {1}  { -- C_SINGLE_REL
use ([AT0002]).data
}
}
EVENT node ocurrences  {0..1}  {
meaning [AT0012]
-- 10-minute event
name  {AC0012}
offset  {10min}
data existence  {1}  {
use ([AT0002]).data
}
}
}
}
}
}
terminology
primary_language = en
translations_available = {en}
HL7 Template and Archetype Architecture
Template Special Interest Group
141
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
terminologies_ available = {SNOMED-CT(2003)}
code_definitions(en) = {
AT0001 = { text = « apgar record »; description = “record of the agpar scoring”}
AT0002 = { text = « 1-minute event »; description = “record of score at 1 minute”}
AT0003 = { text = « apgar items »; description = “the set of scores and the total”}
AT0004 = { text = « cardiac score »; description = “the cardiac score based on heart
rate”}
AT0005 = { text = « respiratory score »; description = “the respiratory score based on
effort”}
AT0006 = { text = « muscle tone score»; description = “the muscle tone score”}
AT0007 = { text = « reflex response score»; description = “the presence of reflexes”}
AT0008 = { text = « colour score»; description = “the colour score based on peripheral
colour”}
AT0009 = { text = « apgar score »; description = “The total of the subsiduary scores”}
AT0010 = { text = « 2-minute apgar »; description = “record of the score at 2 minutes”}
AT0011 = { text = « 5-minute apgar »; description = “record of the score at 5 minutes”}
AT0012 = { text = « 10-minute apgar »; description = “record of the score at 10 minutes”}
}
term_binding(UMLS(2002)) = {
AT0001 = { C124305} -- apgar result
AT0002 = {} -- 1-minute event
AT0003 = {} -- apgar items
AT0004 = {C234305} -- cardiac score
AT0005 = {C232405} -- respiratory score
AT0006 = {C254305} -- muscle tone score
AT0007 = {C987305} -- reflex response score
AT0008 = {C189305} -- color score
AT0009 = {C187305} -- apgar score
AT0010 = {C325305} -- 2-minute apgar
AT0011 = {C725354} -- 5-minute apgar
AT0012 = {C224305} -- 10-minute apgar
}
constraint_binding(SNOMED-CT(2003)) = {
need to check but I expect that the meanings will have to be used
AC0001 = {code_string  { [xxxx]}}
-- newborn
AC0002 = {?????}
AC0003 = {?????}
AC0004 = {?????}
AC0005 = {?????}
AC0006 = {?????}
AC0007 = {?????}
HL7 Template and Archetype Architecture
Template Special Interest Group
142
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
AC0008 = {?????}
AC0009 = {?????}
AC0010 = {?????}
AC0011 = {?????}
AC0012 = {?????}
}
There are LOINC codes for the Apgar score at 1,2,5 and 10 minutes. Due to
precoordination issues which are widespread it is only possible to map the codes to
different points in the archetype. Such mappings are important for the transfer into and
out of HL7 messages. A mapping like the following may become part of the archetype.
Term_bindings(LOINC(2002))
[AT0002]/[AT0003]/[AT0009] = “9272-6” -- NEONATAL APGAR^1M POST BIRTH
[AT0010]/[AT0003]/[AT0009] = “9273-4” -- NEONATAL APGAR^2M POST BIRTH
[AT0011]/[AT0003]/[AT0009] = “9274-2” -- NEONATAL APGAR^5M POST BIRTH
[AT0012]/[AT0003]/[AT0009] = “9271-8” -- NEONATAL APGAR^10M POST BIRTH
Template Examples
Ante-natal Visit
To be continued
Diabetic Review Contact
To be continued
Querying
The archetype, as the shared representation of clinical models in the EHR, becomes the
prime ‘hook’ for retrieving information from the EHR. This means that queries are
expressed in terms of archetypes and archetype node paths. For readers familiar with
SQL, the archetypes can be thought of as a logical equivalent of tables and archetype
node paths an equivalent of fields.
To return the haemaglobin in the CBC example given above a possible query statement
is:
SELECT battery_items/haemaglobin.value{value, units} FROM mayo.isoehr.entry.cbc.v1
This will return a set of quantities and their units.
125, g/l
12.3, g/dl
116, g/l ...
To select only values where the units are g/l the following syntax would be required:
SELECT battery_items/haemaglobin.value{value, units} FROM mayo.isoehr.entry.cbc.v1
WHERE battery/haemaglobin.value.units = “g/l”
Element features are accessed by dot notation.
HL7 Template and Archetype Architecture
Template Special Interest Group
143
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
As we have seen, archetype nodes with cardinality of greater than one (i.e. the node path
is not unique in the data instance) are identified by a combination of their meaning and
name – the design and runtime identifiers. This does mean that the naming constraints or
constraint_bindings definitions at the end of an archetype define the possible queries at
this point. For returning information from these nodes the query engine will interact with
the archetype definition and the terminology service.
Consider the problem/SOAP organiser above. The ‘problem’ node can be populated with
terms from a terminology and so allow organisation of the entries under different
problem headings. To view all organisers and entries in this organiser the query would
read:
SELECT problem FROM ihc.iso-ehr.section.soap_headings.v1
To view all the entries under ‘Diabetes’ the following query would be required.
SELECT * FROM ihc.iso-ehr.section.soap_headings.v1
WHERE problem=“*diabetes*” OR problem= “*IDDM”
The latter criteria would catch “NIDDM” and “IDDM”. The constraint_bindings for a
terminology such as SNOMED-CT might insist on using a coded term at this point. This
would enable the query to capture all entries in a more sophisticated manner using the
terminology. Thus as all types of diabetes could be determined:
SELECT problem FROM ihc.iso-ehr.section.soap_headings.v1
WHERE problem=“has-relation [102002(is-a)] with-target [13297(diabetes mellitus)]”
This code phrase will enable the terminology service to interact with the query engine to
determine whether the coded term meets these criteria.
Production Rules
There is more than one syntax specification possible to express the kind of examples
shown above. A general syntax would treat all nodes in the same generic way; more
specific syntaxes can take advantage of knowledge of particular reference models. The
first set of production rules shown here define a generic syntax which assumes no
particular node types (i.e. Entry, Organiser etc), but does assume data type definitions.
Places where more specific rule subsets could be plugged in are indicated. The second set
of production rules below shows the openEHR plug-ins.
NOTE: these syntaxes are under development; the rules shown below are incomplete and
approximate at this stage. However, formal comparisons can be made with the Archetype
models of openEHR (see http://www.openEHR.org) .
Generic Syntax
######## overall structure ########
archetype:
heading_part
body_part
terminology_part
heading_part:
“archetype”
”meaning”
”type”
[
“parent
version”
[ “specializes” archetype_id ]
HL7 Template and Archetype Architecture
Template Special Interest Group
archetype_id
c_text
rm_type_name
archetype_id
]
144
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
body_part: c_node_expr
terminology_part: reference_terminologies_decl
primary_language_decl
languages_available_decl
{
term_definitions_decl
{
constraint_definitions_decl
{
term_binding_decl
{ constraint_binding_decl }*
}+
}*
}*
######## archetype identification #######
archetype_id: archetype_originator ‘.’ qualified_rm_entity ‘.’ domain_concept ‘.’
version_id
qualified_rm_entity: rm_originator ‘:’ rm_id ‘:’ rm_entity
domain_concept: concept_name { ‘:’ specialisation }*
version_id: ‘v’ NUMBER
archetype_originator: NAME
rm_originator: NAME
rm_entity: NAME
domain_concept: NAME
specialisation: NAME
######### body nodes #########
c_node_expr: rm_type_name c_occurrences_expr MATCH_SYM c_node -area
plug
in
c_occurrences_expr: “occurrences” MATCH_SYM c_cardinality
c_cardinality:
c_node:
c_fragment |
c_archetype |
c_use_fragment
c_use_fragment:
c_archetype:
######### Archetype Fragments #######
c_fragment: “{“
c_meaning_expr
c_name_expr
{c_feature_expr}+
[ c_invariant_section ]
”}”
HL7 Template and Archetype Architecture
Template Special Interest Group
145
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
c_meaning_expr:
Version 3.0
“meaning” EQ_SYM v_text
c_name_expr:“name” MATCH_SYM c_text
c_feature_expr:
rm_attr_expr | rm_rel_expr
c_attr_expr: rm_attr_name MATCH_SYM “{“ c_data_value “}”
c_rel_expr: rm_rel_name c_existence MATCH_SYM “{“ c_node_expr “}”
“{“ c_cardinality [ “;” “ordered”] [“;” “unique”] “}”
c_existence:
c_invariant_section: “invariant” {c_invariant_expr}+
c_invariant_expr:
-- potentially plug in some of OCL if it ever gets fixed…
####### data values #######
c_data_value: c_text | c_quantitative | c_time_specification | c_encapsulated
c_quantitative:
c_ordered | c_quantity_ratio | c_interval
c_ordered: c_ordinal | c_quantity | c_customary_quantity
c_customary_quantity:
c_date | c_time | c_date_time | c_duration | c_partial_date |
c_partial_time | c_partial_date_time
c_time_specification: c_periodic_time_specification | c_general_time_specification
c_text:
c_plain_text | c_coded_text
c_plain_text:
c_coded_text:
c_ordinal:
c_quantity:
c_date:
….
v_text:
###### lexical components ########
NUMBER: [0-9]*
NAME: [a-z][a-z0-9()/%$#&]*
OpenEHR Plug-ins
c_node_expr: “TRANSACTION”
c_transaction_node |
c_occurrences_expr
MATCH_SYM
“ORGANISER” c_occurrences_expr MATCH_SYM c_organiser_node |
“ENTRY” c_occurrences_expr MATCH_SYM c_entry_node |
c_structure_node_expr
HL7 Template and Archetype Architecture
Template Special Interest Group
146
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
c_structure_node_expr:
“HISTORY” c_occurrences_expr MATCH_SYM c_history_node |
“LIST_S” c_occurrences_expr MATCH_SYM c_list_s_node |
“TABLE_S” c_occurrences_expr MATCH_SYM c_table_s_node |
“TREE_S” c_occurrences_expr MATCH_SYM c_tree_s_node |
“SINGLE_S” c_occurrences_expr MATCH_SYM c_single_s_node
c_transaction_node:
c_organiser_node:
c_entry_node:
….
References
Beale T. Archetypes: Constraint-based Domain Models for Future-proof Information
Systems. OOPSLA 2002 workshop on behavioural semantics. Available at
http://www.deepthought.com.au/it/archetypes.html.
Beale T. Archetypes: Constraint-based Domain Models for Future-proof Information
Systems. 2000. http://www.deepthought.com.au/it/archetypes.html.
Dolin R, Elkin P, Mead C et al. HL7 Templates Proposal. 2002. Available at http://www.hl7.org.
Dipak Kalra et al. Software Components developed by UCL for the SynEx Project &
London Demonstrator Site. UCL, 2001.
Meyer B. Object Oriented Software Construction 2nd Ed. Prentice Hall 1997.
Kilov H. Information Modelling. Prentice Hall 1994.
Sowa J. Knowledge Representation. Brooks Cole 2000.
openEHR. See http://www.openEHR.org/.
A L Rector. The Interface between Information, Terminology and Inference Models.
MEDINFO 2001 proceedings. IOS press, Amsterdam.
A L Rector, Clinical Terminology: Why Is It So Hard? Yearbook of Medical Informatics
2001. IOS press, Amsterdam.
College of American Pathologists. Systematized Nomenclature for Medicine
(SNOMED). See http://www.snomed.org/.
Galen. See http://www.openGalen.org
GLIF (Guideline Interchange Format). http://www.glif.org/.
ProForma language for decision support. http://www.acl.icnet.uk/lab/proforma.html.
Prodigy. SCHIN, Newcastle. See http://www.prodigy.nhs.uk.
Solbrig H, Markwell D et al. HL7 Common Terminology Service (CTS). Available at
http://www.hl7.org.
HL7 Template and Archetype Architecture
Template Special Interest Group
147
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
10.2 SR-XML: GRAPHICAL TEMPLATE REPRESENTATION
Author: Martin Kernberg, MD
SR XML OF CLINICAL INFORMATION AND PROCEDURES
Because of the straightforward graphic representation in SR-XML (Structured ReportingExtended Markup Language), clinical domain experts can easily represent information
pertinent to their specialties. Clinical Information is one of the two fundamental
templates governing common clinical documents (the other is Imaging and Interventional
Procedures), represented graphically in the Elm Tree Notation of SGML, with a limited
symbol subset specific to XML (given below in the legend), permitting modeling for
either DTD or XML schema. In addition, transformation to ADL, OWL, and OCL can
also be performed, permitting representation, respectively, of formal clinical syntax,
clinical semantics, and constraints on related HL7 artifacts.
In the templates provided below, the software for modifying the related templates is
embedded, and the template can be modified by clicking on the graphic, including size
reformatting for detailed examination. The two Fundamental Templates are interrelated
in that Clinical Information becomes the Clinical Indication of a Procedure, and
Procedures become part of the Past History section of Clinical Information.
Legend:
Symbol (XML)

*
+
?
#PCDATA
=
…
Meaning
Sequence of ordered elements
0 or more
1 or more
0 or 1 (optional)
Character data
Same as
Continued on additional templates
HL7 Template and Archetype Architecture
Template Special Interest Group
148
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
SR XML TEMPLATE 1: CLINICAL INFORMATION
Clinical Information
Demographics
...2
* Clinical
Indication
...
Chief
Complaint
...
HPI
...
* ROS
...
? PMHx
...
...
* Medications
......
* Immunologic
(Allergies)
...
? Family
Hx
...
...
? Social
Hx
...
? Physical
Examination
* Diagnostic
Tests
? Assessment
* Imaging
Impression
=Diagnoses
* Interventions
Differential
Diagnosis
* Surgery
Differential
Intervention
=Diagnoses
Risk Factors
LEGEND
HPI
ROS
PMHx
Hx
History of Present Illness
Review of Systems
Past Medical History
History
HL7 Template and Archetype Architecture
Template Special Interest Group
149
November 30, 2003
? Plan
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
SR XML TEMPLATE 2: DEMOGRAPHICS
Demographics
Administrative Data
Patient Data
+ Financial Data
#PCDATA
Attending MD
Name
Date of Birth
? Social Security Number
Medical Record Number
#PCDATA
= DATE
#PCDATA
#PCDATA
Authorized Access
Verification Access
System Administrator
HL7 Template and Archetype Architecture
Template Special Interest Group
150
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
SR XML TEMPLATE 3: CLINICAL INDICATION
Clinical Indication
? Chief Complaint
? Age
? Ethnicity
? Gender
Num
#PCDATA
#PCDATA
? HPI
...
? Prior Medical History
...
? Presentation
PC DATA
+ Diagnoses
Name
Code
#PCDATA
#PCDATA
* Differential
Diagnosis
= Diagnoses
Name
Code
SR XML TEMPLATE 4: INTERVENTIONAL (OR IMAGING) REPORT
Interventional (or Imaging)
Report
Patient
Data
...
1. Institution and Department
2. Author and Title
3. Date
Demographics
Clinical Indication
+ Comparison
? Clinical Information
Technical Methods
...Template 2
...Template 3
...Template 4
... Template 5
... Template 6
Admininistrative
Data
Financial
Data
...
Results
Impression
... Template 9
Quantitative Findings
...Template 7
Qualitative Findings
+ Referring
Physician
+ Reporting
Physician
...Template 8
= Referring Physician
Address
* E-mail
* Facsimile
+ Telephones
Office
Number
? Cellular
Phone
HL7 Template and Archetype Architecture
Template Special Interest Group
151
November 30, 2003
Summary
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
SR XML TEMPLATE 5: COMPARISON
Comparison
+ Comparison(s)
Study Type
Prior Structured Report
[XLink]
Waveform Image
[XLink]
Waveform Data
[XLink]
#PCDATA
#PCDATA
#PCDATA
Date
= date
= Date
Code
...
HL7 Template and Archetype Architecture
Template Special Interest Group
152
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
SR XML TEMPLATE 6: TECHNICAL METHODS
Technical Methods
? Acquiring Device
Acquisition
Technique
? Technologist
? Location
#PCDATA
Manufacturer
Date
#PCDATA
= DATE
Name
Time
#PCDATA
= TIME
? Protocol
Last Name
#PCDATA
? Procedure Log
First Name
#PCDATA
Identification
Middle
#PCDATA
#PCDATA
SR XML TEMPLATE 7: QUANTITATIVE ANALYSIS
? Quantitative Analysis
? Local Measurements
?
Measured Variables
...
...
? 1-dimensional
(eg, Laboratory)
Values
...
? Regional Measurements
? Global Measurements
=Local Measurements
=Local Measurements
? Constant Variables
Derived Variables
=Measured Variables
=Measured Variables
? 2-dimensional
(eg, ECG)
? 3-dimensional
(eg, Imaging)
=1-Dimensional
=1-Dimensional
? Quality
...
Units
...
HL7 Template and Archetype Architecture
Template Special Interest Group
153
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
SR XML TEMPLATE 8: QUALITATIVE ANALYSIS
? Qualitative Analysis
? Non-biological
and External
* Procedures
* Instrumentation
? Biological
* Anatomic
Survey
* Pathologic
Survey
* Pathologic
Survey
* Proportions
(Spatial Dimensions)
...
? Temporal
Progression
? General Pathologic
Processes
? Specific Pathologic
Processes
* Surgery
* Foreign
Body
* Proportions
(Spatial Dimensions)
...
* Inherited
* Gas
Collection
...
* Hemovascular
Temporal
Progression
* Congenital
* Fluid
Collection
...
* Infection
* Senescent
* Solid
Collection
...
* Iatrogenic
* Mass
(Defined contour)
...
* Inflammation
* Lesion(s)
(Irregular Contour)
...
* Neoplastic
= Temporal Progression
General Pathologic
Processes
= General Pathologic Process
Specific Pathologic
Processes
= Specific Pathologic Processes
* Inherited
(or Congenital)
* Immunologic
* Metabolic
* Injury
*Information Disorders
*Toxicology
HL7 Template and Archetype Architecture
Template Special Interest Group
154
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
SR XML IMAGING/INTERVENTIONAL TEMPLATE 9: ASSESSMENT
Assessment
* Principal Quantitative
Findings
* Principal Qualitative
Findings
#PCDATA
#PCDATA
+ Impression(s)
+ Diagnoses
= Diagnoses
* Differential Diagnoses
= Diagnoses
SR XML IMAGING/INTERVENTIONAL TEMPLATE 10: PLAN
HL7 Template and Archetype Architecture
Template Special Interest Group
155
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
Plan
Disposition
? Discharge
* Referral
? Admission
? Instructions
* Prescriptions
? Orders
* Action
* Means
* Recommendation(s)
* Communication
11. TEMPLATE CONSTRAINTS ON CLINICAL DATA:
SEMANTICS
11.1 OWL Formalism
8.11 Author: Peter Elkin, MD
11.2 Template and archetype Formalism
The Template and archetype formalism is a detailed semantic representation of the
content of a codified structure. This type of composition is a pre-coordination that is not
necessarily terminological. However it most certainly is definitional. Meaning that no
two template and archetype names can exist which are the same but have different
definitional content. We have chosen the OWL formalism from the semantic web
(WebOnt Group) to illustrate the semantics that are provided by HL7 Templates and
archetypes.
OWL is a proper constraint language which handles decidably the core of first order
predicate logic.i We have chosen OWL-DL as the flavor of OWL used for HL7
Templates and archetypes. The only difference between full OWL and OWL-DL is that
names for Classes, Individuals, Properties and Datatypes must be disjoint. Meaning that
no name should occur in more than one of these categories. This assures that higher than
first-order logic is not represented and makes reasoning over these ontological
constructions less complex (they practically will finish their queries in less than
HL7 Template and Archetype Architecture
Template Special Interest Group
156
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
polynomial time). OWL-Lite was not chosen as it cannot support cardinalities of greater
than one. This restriction is not applicable to OWL-DL or OWL-Full.
OWL is an outgrowth of the DAML + OIL project with the following exceptions:



the removal of qualified number restrictions, per a decision of WebOnt;
the ability to directly state that properties can be symmetric, per a
decision of WebOnt; and
the absence in abstract syntax of some abnormal DAML+OIL
constructs, particularly restrictions with extra components, and a
difference in their meaning.
OWL Class Axioms
The full abstract syntax has more-general versions of the OWL Lite
class axioms where superclasses, more-general restrictions, and
boolean combinations of these are allowed. Together, these constructs
are called descriptions.
<axiom> ::= Class( <classID> <modality> {<annotation>}
{<description>} )
<modality> ::= complete | partial
In the full abstract syntax it is also possible to make a class exactly
consist of a certain set of individuals, as follows.
<axiom> ::= EnumeratedClass( <classID> {<annotation>}
{<individualID>} )
Finally, in the full abstract syntax it is possible to require that a collection
of descriptions be pairwise disjoint, or have the same members, or that
one description is a subclass of another. Note that the last two of these
axioms generalize the first kind of class axiom just above.
<axiom> ::= DisjointClasses( <description> {<description>} )
<axiom> ::= EquivalentClasses( <description> {<description>}
)
<axiom> ::= SubClassOf( <description> <description> )
11.3.2.2. OWL Descriptions
<axiom> ::= Class( <classID> <modality> {<annotation>}
{<super>} )
<modality> ::= complete | partial
<super> ::= <classID> | <restriction>
In OWL Lite it is possible to state that two classes are the same.
<axiom> ::= EquivalentClasses( <classID> {<classID>} )
HL7 Template and Archetype Architecture
Template Special Interest Group
157
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
Descriptions in the full abstract syntax include class IDs and the
restriction constructor. Descriptions can also be boolean combinations
of other descriptions, and sets of individuals.
<description> ::=
|
|
|
|
|
<classID>
<restriction>
unionOf( {<description>} )
intersectionOf( {<description>} )
complementOf( <description> )
oneOf({<individualID>} )
11.3.2.3. OWL Restrictions
<restriction> ::= restriction( <datavaluedPropertyID>
{allValuesFrom(<datatypeID>)}
{someValuesFrom(<datatypeID>)} [<cardinality>] )
<restriction> ::= restriction( <individualvaluedPropertyID>
{allValuesFrom(<classID>)}
{someValuesFrom(<classID>)}
[<cardinality>] )
<cardinality> ::= minCardinality(0) | minCardinality(1) |
| maxCardinality(0) | maxCardinality(1) |
| cardinality(0)
| cardinality(1)
Restrictions in the full abstract syntax generalize OWL Lite restrictions
by allowing descriptions where classes are allowed in OWL Lite and
allowing sets of data values as well as datatypes. The combination of
datatypes and sets of data values is called a data range. In the full
abstract syntax, values can also be given for properties in classes. As
well, cardinalities are not restricted to only 0 and 1.
<restriction> ::= restriction( <datavaluedPropertyID>
{allValuesFrom(<dataRange>)}
{someValuesFrom(<dataRange>)}
{value(<dataLiteral>)}
{<cardinality>} )
<restriction> ::= restriction( <individualvaluedPropertyID>
{allValuesFrom(<description>)}
HL7 Template and Archetype Architecture
Template Special Interest Group
158
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
{someValuesFrom(<description>)} {value(<individualID>)}
{<cardinality>} )
<cardinality> ::= minCardinality(<non-negative-integer> )
| maxCardinality(<non-negative-integer>)
| cardinality(<non-negative-integer>)
A dataRange, used as the range of a data-valued property and in other
places in the full abstract syntax, is either a datatype or a set of data
values.
<dataRange> ::= <datatypeID>
<dataRange> ::= oneOf({<typedDataLiteral>} )
As in OWL Lite, there is a side condition that properties that are
transitive, or that have transitive sub-properties, may not have
cardinality conditions expressed on them in restrictions.
11.3.2.4. OWL Property Axioms
<axiom> ::= DatatypeProperty ( <datavaluedPropertyID>
{<annotation>} {super(<datavaluedPropertyID>)}
{domain(<classID>)}
{range(<datatypeID>)}
[Functional] )
<axiom> ::= ObjectProperty ( <individualvaluedPropertyID>
{<annotation>} {super(<individualvaluedPropertyID>)}
{domain(<classID>)} {range(<classID>)}
[inverseOf(<individualvaluedPropertyID>)]
[Symmetric]
[Functional | InverseFunctional | Functional
InverseFunctional | Transitive] )
The following axioms make several properties be the same, or make
one property be a sub-property of another.
<axiom> ::= EquivalentProperties( <datavaluedPropertyID>
{<datavaluedPropertyID>} )
<axiom> ::= SubPropertyOf( <datavaluedPropertyID>
<datavaluedPropertyID> )
HL7 Template and Archetype Architecture
Template Special Interest Group
159
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
<axiom> ::= EquivalentProperties(
<individualvaluedPropertyID>
{<individualvaluedPropertyID>} )
<axiom> ::= SubPropertyOf( <individualvaluedPropertyID>
<individualvaluedPropertyID> )
Property axioms in the full abstract syntax generalize OWL Lite property
axioms by allowing descriptions in place of classes and data ranges in
place of datatypes in domains and ranges.
<axiom> ::= DatatypeProperty ( <datavaluedPropertyID>
{<annotation>} {super(<datavaluedPropertyID>)}
{domain(<description>)}
{range(<dataRange>)}
[Functional] )
<axiom> ::= ObjectProperty
( <individualvaluedPropertyID> {<annotation>}
{super(<individualvaluedPropertyID>)}
{domain(<description>)} {range(<description>)}
[inverseOf(<individualvaluedPropertyID>)]
[Symmetric]
[Functional | InverseFunctional | Functional
InverseFunctional | Transitive] )
11.3 Example Template and archetype For a CBC
CBC
Hemoglobin
Hematocrit
Platelet Count
The CBC is a particular type of lab test and all coded entities come from LOINC. For
brevity, only mandatory attributes are represented in the OWL-XML example below:
<?xml version="1.0" standalone="yes"?>
<rdf:RDF xmlns="http://www.example.org/cbc#" xmlns:CBC="http://www.example.org/cbc#"
xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:xsd="http://www.w3.org/2000/10/XMLSchema#">
<owl:Ontology rdf:about="http://www.example.org/cbc.owl">
<rdfs:comment>OWL RDF Syntax for CBC Lab Test. Based on example By Dr. Peter ELkin</rdfs:comment>
<owl:versionInfo>$Header:$</owl:versionInfo>
<owl:Class rdf:ID="CBC">
<owl:subClassOf rdf:resource="#LabTest"/>
<owl:Restriction>
<owl:onProperty rdf:resource="#class_cd"/>
<owl:hasValue rdf:resource="#CBC_class_cd"/>
<owl:Restriction>
<owl:onProperty rdf:resource="#class_cd"/>
<owl:minCardinality>1</owl:minCardinality>
</owl:Restriction>
</owl:Restriction>
<owl:Restriction>
<owl:onProperty rdf:resource="#moodCode"/>
<owl:hasValue rdf:resource="#CBC_moodCode"/>
<owl:Restriction>
<owl:onProperty rdf:resource="#moodCode"/>
<owl:minCardinality>0</owl:minCardinality>
HL7 Template and Archetype Architecture
Template Special Interest Group
160
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
</owl:Restriction>
</owl:Restriction>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasComponent"/>
<owl:hasValue rdf:resource="#Hemoglobin"/>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasComponent"/>
<owl:cardinality>1</owl:cardinality>
</owl:Restriction>
</owl:Restriction>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasComponent"/>
<owl:hasValue rdf:resource="#Hematocrit"/>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasComponent"/>
<owl:maxCardinality>1</owl:maxCardinality>
</owl:Restriction>
</owl:Restriction>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasComponent"/>
<owl:hasValue rdf:resource="#PlatletCount"/>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasComponent"/>
<owl:cardinality>1</owl:cardinality>
</owl:Restriction>
</owl:Restriction>
</owl:Class>
<owl:Class rdf:ID="LabTest">
<rdfs:subClassOf rdf:resource="http://www.example.org/Observation"/>
<owl:Restriction>
<owl:onProperty rdf:resource="#LabTest"/>
<owl:allValuesFrom>LOINC</owl:allValuesFrom>
</owl:Restriction>
<owl:Restriction>
<owl:onProperty rdf:resource="#class_cd"/>
<owl:minCardinality>0</owl:minCardinality>
</owl:Restriction>
<owl:Restriction>
<owl:onProperty rdf:resource="#moodCode"/>
<owl:minCardinality>0</owl:minCardinality>
</owl:Restriction>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasComponent"/>
<owl:allValuesFrom rdf:resource="#Observation"/>
</owl:Restriction>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasComponent"/>
<owl:minCardinality>0</owl:minCardinality>
</owl:Restriction>
</owl:Class>
<owl:Class rdf:ID="typeCode"/>
<owl:ObjectProperty rdf:ID="hasComponent">
<rdf:type rdf:resource="http://www.w3.org/owl#FunctionalProperty"/>
<rdfs:domain rdf:resource="#LabTest"/>
<rdfs:range rdf:resource="#typeCode"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="class_cd"/>
<owl:ObjectProperty rdf:ID="moodCode"/>
<owl:DataTypeProperty rdf:ID="codeValue">
<rdfs:domain rdf:resource="#typeCode"/>
<rdfs:range rdf:resource="http://www.example.org/LabTest-dt#labCodeValues"/>
</owl:DataTypeProperty>
<typeCode rdf:ID="Hemaglobin">
<codeValue rdf:type="http://www.example.org/LabTest-dt#labValues">123-456</codeValue>
</typeCode>
<typeCode rdf:ID="Hematocrit">
<codeValue rdf:type="http://www.example.org/LabTest-dt#labValues">456-789</codeValue>
</typeCode>
<typeCode rdf:ID="Platlet Count">
HL7 Template and Archetype Architecture
Template Special Interest Group
161
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
<codeValue rdf:type="http://www.example.org/LabTest-dt#labValues">123-789</codeValue>
</typeCode>
<typeCode rdf:ID="CBC_class_cd">
<codeValue rdf:type="http://www.example.org/LabTest-dt#class_cd-Values">987654</codeValue>
</typeCode>
<typeCode rdf:ID="CBC_moodCode">
<codeValue rdf:type="http://www.example.org/LabTest-dt#moodCode-Values">654321</codeValue>
</typeCode>
</owl:Ontology>
</rdf:RDF>
11.4 Template and archetype Validation
Templates and archetypes must conform to the HL7 Reference Information Model. This
section outlines a method for validation of an OWL based HL7 Template and archetype
using axioms derived from a R-MIM fragment. Each of these sets of axioms represent
serialized sets of constraints which the R-MIM fragment imposes. These R-MIM
Fragments must be registered in the metadata repository and further they must be
uniquely identified and available for validation of submitted HL7 Templates and
archetypes.
The basis for the validation is given in the theoretical semantics of the OWL language
(w3c Standard for the semantic web). This is expressed in both an abstract syntax and in
rdf schema (please see Appendix A).
An example of the formalism for validation based on the OWL Abstract Syntax follows.
HL7 Template and Archetype Architecture
Template Special Interest Group
162
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
R-MIM Fragment
•
The R-MIM fragment (graphically represented here) can be converted to OWL
Abstract Syntax (next slide), and used as a definition model for template
development and validation.
hasComponent
typeCode* <= COMP
contextControlCode: CS <=N+C "C"
sequenceNumber*: INT
priority Number: INT
pauseQuantity : PQ
0..*
Observ ation
Note:
This f ragment is taken f rom an imaginary O/O Results R-MIM.
The abstract constraint is:
When reporting the results of a CBC, the f ollowing observ ations shall be present:
o Hemoglobin (required, cannot repeat)
o Hematocrit (optional, cannot repeat)
o Platelet count (required, cannot repeat)
class_cd* <= OBS
moodCode *: CS <= EVN + INT
id*: II [0..1] (f iller order number)
code*: CE CWE <= ObservationType (e.g. LOINC code)
negationInd: BL[0..1]
text*: ED [0..1] (f ree text describing the ev ent)
statusCode*: CS[0..1]
ef f ectiv eTime*: IVL<TS>[0..1] ("phy siologically relev ant time")
activ ity Time: IVL<TS> [0..1] (time of perf ormance)
priority Code: CECWE[0..1] "R"
conf identiality Code*:SET<CE>CWE[0..*] "N"
v alue: ANY
interpretationCode: SET<CS> [0..*] ("abnormal f lags")
methodCode: CECWE[0..1]
targetSiteCode: CD CWE[0..1]
Serialized constraints expressed below as OWL Axioms:
•<axiom> ::= Class(ex:R-MIM Individual (ex:ID "12345"))
Defines the entire Restricted MessageInformation Model
•<axiom> ::= Class(ex:R-MIM_Fragment Individual (ex:Frag_ID "67890")
unionOf(ex:Observation ex:hasComponent) )
Defines the R-MIM Fragment as being the union of the Observation Class with the
hasComponent Class (previous slide, and below)
•<axiom> ::= SubClassOf(sub=ex:R-MIM_Fragment super=ex:R-MIM)
Specifies that the R-MIM fragment is a subclass of the entire R-MIM
•<axiom> ::= Class(ex:Observation complete ex:Act restriction(ex:classCode
minCardinality( 0 )
ex:moodCode minCardinality( 0 )
ex:hasComponent minCardinality(0) ) )
Defines the Class Observation as a complete Act with defined restrictions (previous slide
for reference)
•<axiom> ::= Class(ex:hasComponent (ex:typeCode complete ex:Observation
restriction(ex: domain(ex:COMP) minCardinality(0) ) ) )
Defines the Class hasComponent as being a complete Observation within the COMP
domain (previous slide for reference)
•<axiom> ::= ObjectProperty(ex:typeCode (Individual(ex:codeValue) ) )
HL7 Template and Archetype Architecture
Template Special Interest Group
163
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
•<axiom> ::= ObjectProperty(ex:class_cd (Individual(ex:codeValue) ) )
•<axiom> ::= ObjectProperty(ex:moodCode (Individual(ex:codeValue) ) )
Defines the Object Properties used in the above Class definitions
•<axiom> ::= DatatypeProperty(ex:codeValue xsd:integer)
Defines the Data Type Properties for the Object Properties
HL7 Template and Archetype Architecture
Template Special Interest Group
164
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
• The OWL R-MMIM Fragment can validate an existing OWL
Template, I.e. LabTest is a SubClass of Observation.
<owl:Class rdf:ID="LabTest">
<rdfs:subClassOf
rdf:resource="http://www.example.org/Observation"/>
<owl:Restriction>
<owl:onProperty rdf:resource="#LabTest"/>
<owl:allValuesFrom>LOINC</owl:allValuesFrom>
</owl:Restriction>
<owl:Restriction>
Combined with
<owl:onProperty rdf:resource="#class_cd"/>
<owl:minCardinality>0</owl:minCardinality>
<axiom> ::= Class(ex: hasComponent(ex:typeCode complete ex:Observation
restriction(ex: domain(ex:COMP) minCardinality(0) ) ) ) </owl:Restriction>
<owl:Restriction>
<owl:onProperty rdf:resource="#moodCode"/>
<owl:minCardinality>0</owl:minCardinality>
</owl:Restriction>
<owl:Restriction>
<owl:onProperty rdf:resource="# hasComponent"/>
<owl:allValuesFrom rdf:resource="# Observation"/>
</owl:Restriction>
Can be used to validate.
<owl:Restriction>
<owl:onProperty rdf:resource="#hasComponent"/>
<owl:minCardinality>0</owl:minCardinality>
</owl:Restriction>
</owl:Class>
<axiom> ::= Class(ex:Observation complete ex:Act
restriction(ex:classCode minCardinality( 0 )
ex:moodCode minCardinality( 0 )
ex:hasComponent minCardinality(0)))
CBC is a Subclass of Labtest:
<owl:Class rdf:ID=" LabTest">
<rdfs:subClassOf
rdf:resource="http://www.examp le.o rg/Observation"/>
<owl:Restrict ion>
<owl:onProperty rdf:resource="#LabTest"/>
<owl:allValuesFro m>LOINC</owl:allValuesFro m>
</owl:Restriction>
<owl:Restrict ion>
Can
<owl:onProperty rdf:resource="#class_cd"/>
<owl:minCardinality>0</owl:min Card inality>
</owl:Restriction>
<owl:Restrict ion>
<owl:onProperty rdf:resource="#moodCode"/>
<owl:minCardinality>0</owl:min Card inality>
</owl:Restriction>
<owl:Restrict ion>
<owl:onProperty rdf:resource="# hasComponent"/>
<owl:allValuesFro m rdf:resource="# Observation"/>
</owl:Restriction>
<owl:Restrict ion>
<owl:onProperty rdf:resource="#hasComponent"/>
<owl:minCardinality>0</owl:min Card inality>
</owl:Restriction>
</owl:Class>
<owl:Class rdf:ID="CBC">
<owl:subClassOf rdf:resource="#LabTest"/>
<owl:Restriction>
<owl:onProperty rdf:resource="#class_cd"/>
<owl:hasValue rdf:resource="#CBC_class_cd"/>
<owl:Restriction>
<owl:onProperty rdf:resource="#class_cd"/>
<owl:minCardinality>1</owl:minCardinality>
</owl:Restriction>
be used to validate.
</owl:Restriction>
<owl:Restriction>
<owl:onProperty rdf:resource="#moodCode"/>
<owl:hasValue rdf:resource="#CBC_moodCode"/>
<owl:Restriction>
<owl:onProperty rdf:resource="#moodCode"/>
<owl:minCardinality>0</owl:minCardinality>
</owl:Restriction>
</owl:Restriction>
<owl:Restriction>
<owl:onProperty rdf:resource="# hasComponent"/>
<owl:hasValue rdf:resource="#Hemoglobin"/>
<owl:Restriction>
<owl:onProperty rdf:resource="# hasComponent "/>
<owl:cardinality>1</owl:cardinality>
</owl:Restriction>
</owl:Restriction>
…… continued on next slide …..
HL7 Template and Archetype Architecture
Template Special Interest Group
165
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
CBC Template and archetype Validation Continued from the previous page:
<owl:Class rdf:ID="LabTest">
<rdfs:subClassOf
rdf:resource="http://www.example.org/Observation"/>
…… continued from previous slide …..
<owl:Restriction>
<owl:onProperty rdf:resource="#LabTest"/>
<owl:allValuesFrom>LOINC</owl:allValuesFrom>
<owl:Restriction>
</owl:Restriction>
<owl:onProperty rdf:resource="# hasComponent"/>
<owl:hasValue rdf:resource="#Hematocrit"/>
<owl:Restriction>
<owl:Restriction>
<owl:onProperty rdf:resource="#class_cd"/>
Can
be
used
to
validate.
<owl:onProperty rdf:resource="# hasComponent "/>
<owl:minCardinality>0</owl:minCardinality>
<owl:maxCardinality>1</owl:maxCardinality>
</owl:Restriction>
</owl:Restriction>
<owl:Restriction>
</owl:Restriction>
<owl:onProperty rdf:resource="#moodCode"/>
<owl:Restriction>
<owl:minCardinality>0</owl:minCardinality>
<owl:onProperty rdf:resource="# hasComponent "/>
</owl:Restriction>
<owl:hasValue rdf:resource="#PlatletCount"/>
<owl:Restriction>
<owl:Restriction>
<owl:onProperty rdf:resource="# hasComponent "/>
<owl:onProperty rdf:resource="# hasComponent"/>
<owl:cardinality>1</owl:cardinality>
<owl:allValuesFrom rdf:resource="# Observation"/>
</owl:Restriction>
</owl:Restriction>
</owl:Restriction>
<owl:Restriction>
</owl:Class>
<owl:onProperty rdf:resource="#hasComponent"/>
<owl:minCardinality>0</owl:minCardinality>
</owl:Restriction>
</owl:Class>
HL7 Template and Archetype Architecture
Template Special Interest Group
166
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
11.5 HL7 ebXML Registry
Template and archetype registration
HL7 will promote the creation of a unified registry of templates and archetypes (that may
be maintained on HL7.org, or housed elsewhere). When submitting a template and
archetype into the unified registry, a contributor typically needs to fill out a set of fields
(known as “template and archetype metadata”) that help catalog the template and
archetype and enable others to find it.
Part of the fields will be in common with the header that goes together with the formal
description of the template and archetype.
Note that the actual fragments of HL7 messages or CDA documents, generated
according to a template and constituent archetypes, will contain just a reference
to the template and archetype ID and no other metadata. In other words, apart
this identifier, no other artifact will allow distinguish a message which uses
explicitly (and systematically) a template and archetype from a message that
happens to have the same content, but obtained without using the template and
archetype.
The submission process will require authentication of the submitter. The register will
have rules governing which existing templates and archetypes a submitter can revise.
Typically, a submitter can add new templates and archetypes, and can revise templates
and archetypes they (or their organization) have submitted, but cannot edit templates and
archetypes submitted by other entities. The register maintains persistent copies of revised
artifacts, and assigns unique identifiers to all artifacts, including new revisions of existing
templates and archetypes.
The actual packages of HL7 V3 Templates and archetypes and the related supporting
material may be initially housed in independent template and archetype repositories
maintained and made available by each submitting organization, under their
responsibility and according to their internal formalism.
An HL7 repository – based on the HL7 normative formalism for templates and
archetypes – can be gradually created either a centralized repository or a federated
repository connecting the ones managed by the submitting organizations.
ebXML is a rapidly growing international standard for business communication over the
Internet. The ebXML standard includes a metadata registry which has its roots in ISO
11179 metadata registry standard. It includes a data model which is consistent with the
HL7 RIM and is extensible to hold the metadata required for the Templates and
archetypes Registry as noted below.
The intent of the HL7 template initiative is an architecture that can accommodate
thousands of templates and archetypes, keeping the relationship between each template
and archetype clear, and allowing a user to easily find a relevant template and archetype.
This will be partly addressed by the creation of template and archetype metadata which is
supplied at the time a template and archetype is added to the registry. This template and
HL7 Template and Archetype Architecture
167
Template Special Interest Group
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
archetype metadata will serve to (1) aid in finding a template and archetype; (2) track
authorship and responsibility for a template and archetype; (3) enable template and
archetype versioning; (4) track the currency of a template and archetype; (5) give some
indication of the purpose of the template and archetype and how or where it can be used;
and more.
The query mechanism associated with the registration of templates and archetypes system
will be an inseparable part of the Template and archetype authoring process. As one
starts to author a template and archetype they will need to be connected to the HL7 web
server. The authoring toolset will allow the user to tell it the name of the new template
and archetype its purpose and its contents. For each datum, the system will search the
registry for both the name of the template and archetype (a concept based query; ie.
Checking synonyms, word variants, etc.) and its content. Where an instance of a
particular datum has been already assigned to a template and archetype, the system will
force the author to use the original assignment (e.g. if a cbc template and archetype has
already assigned the wbc count to LOINC, then any other author who wishes to use a
wbc count in another template and archetype (e.g. a chemotherapy monitoring template
and archetype), must use the LOINC code for wbc count to represent this concept in their
new template and archetype). If there is no instance of a wbc count yet modeled in the
template and archetype registry system, then the author should be free to choose the
nomenclature (i.e. from the HL7 registered terminologies) with which the code will be
associated. This act fixes the association between this conceptual entity and a particular
coding system.
This act of associating a nomenclature with a concept code will allow these templates and
archetypes to contain and message comparable data among and between information
systems. By fixing the semantics, definitions and origin of each concept one declares a
single definitional meaning for that concept. This provides the reliability needed to build
information systems and to transmit unambiguous data in HL7 messages.
As a systems developer, one could register the templates and archetypes in their hospital
information system associating the template and archetype elements with their internal
database structure. This would allow the HL7 templates and archetypes to pull the
associated information out of individual patient records. For example, if one needed to
operate on a wbc count they could call the method for the cbc template and archetype and
the information would be imported from the local database file. This methodology
follows a strict object oriented design for healthcare informatics systems development.
Thing A and Thing B in the figure below serve to audit the input to insure adherence to
the v3 methodology using a rule base which asserts the constraints identified in the
Templates and archetypes Standard.
Templates and archetypes in a strict object oriented sense have multiple parentages. This
complex inheritance pathway means that multiple templates and archetypes will contain
the same slots or concepts. If they are used together this could provide redundant if not
ambiguous data. However this degree of complexity is desirable as it represents “the real
world.” Therefore one needs to have a method of transferring data from one template and
HL7 Template and Archetype Architecture
168
Template Special Interest Group
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
archetype to another. For example, if the CBC template and archetype is already in use
and someone wants the ChemoRx monitoring template and archetype which also contains
the WBC count then the system needs to be smart enough to send the information from
the CBC template and archetype to the ChemoRx template and archetype.
HL7 will create a set of template and archetype metadata that is used to catalog
templates and archetypes housed in the HL7 template and archetype repository.
A user can search against any or all of the template and archetype metadata
fields when looking for a template and archetype.
A user can search for all templates and archetypes that constrain to a particular
code or coding scheme. For instance, a user can find all templates and
archetypes that make reference to the LOINC code for CBC.
A user can search for all HL7 registered templates and archetypes that are
applicable CDA Level 2 (or applicable CDA Level 3) constraints.
A user can search for all HL7 registered templates and archetypes that are
potentially applicable constraints for a particular balloted specification.
A user can retrieve for edit any template and archetype
Compare two templates and archetypes and see if they are equivalent, or if not,
what the differences are.
Check a template and archetype against an R-MIM Fragment and see if it is
possible to create an instance using the R-MIM that could meet the constraints
of the template and archetype. I.e. Check to see if a template and archetype is
compatible with an R-MIM.
HL7 Template and Archetype Architecture
Template Special Interest Group
169
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
Graphic Describing the abstract workflow of template and archetype registry
Domain
Expert
Domain
Friendly
Template
and
archetype
Interface
HL7
Friendly
Template
and
archetype
Process A
Template and
archetype
Representation
Format
R-MIM XX
Process B
HL7 Template and Archetype Architecture
Template Special Interest Group
170
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
ebXML Registry Object Browser
Mayo Clinic is the Submitter of the CBC Template and archetype, the O&O R-MIM
fragment used to validate the template and archetype is an Instance of the RIM. The
CBC Template and archetype implements the R-MIM fragment and the CBC Template
and archetype is an instance of the R-MIM fragment.
HL7 Template and Archetype Architecture
Template Special Interest Group
171
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
Extrinsic Object Meta-Data Model
HL7 Template and Archetype Architecture
Template Special Interest Group
172
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
ebXML Representation of the History Of present Illness section of the HL7-CDA
Document.
HL7 Template and Archetype Architecture
Template Special Interest Group
173
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
XMLSpy representation of the Component section of the HL7-CDA Document.
Finding a registered template and archetype
The template and archetype registry can potentially hold tens of thousands of templates
and archetypes.
Application developers typically will adopt a package of templates and archetypes
suitable for the task that applications are performing in the user sub-community, referring
directly to the respective submitting organization.
The submitting organizations should actively promote the usage of the packages they are
registering, and the direct usage of the registry by the application developers should be
minimal.
The main motivations for the template and archetype registry are the following:
- to assure the future HL7 users that a registered template and archetype obeys to
precise quality assurance process (as soon as it will be in place);
- to facilitate the cooperation among submitting organizations in order to discover
areas of common interest and to produce harmonized templates and archetypes;
- to assist an organization wishing to produce templates and archetypes to locate
other organizations that already submitted a package that could satisfy their needs,
and thus facilitating the co-operation among the interested organizations for the
maintenance of a template and archetype.
Note that each organization is responsible for the maintenance of the packages it entered
in the registry, and that this maintenance should take into account the notification by
other organizations that also included the templates and archetypes into their packages.
Those organizations are also responsible for the appropriate management of the lifecycle
of each template and archetype, taking into account that the sub-community that adopted
the package relies on it to enhance the quality of their information exchanges.
In other words, each registering organization — as a proxy of a standard developing
organisation — should take into account the consequences of any change, or removal, of
a template and archetype on the applications that are actually using that template and
archetype.
Registry users can search the template and archetype registry using any of the available
metadata fields.
The registry provides a link to an URL, managed by the registering organization, where
the users can find the supporting material about the template and archetype and about the
package in which it is contained.
The supporting material describes, among other topics, how the template and archetype
should be used, how the content should be interpreted, which original formalism was
used to represent the template and archetype in a computer-readable format.
In an initial phase, the repositories with the actual templates and archetypes are managed
by the submitting organizations according to their internal rules. It is expected that the
HL7 Template and Archetype Architecture
174
Template Special Interest Group
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
repositories will differ in the search sophistication provided and in the metadata exposed
to the search engine, that may be different from the metadata used in the common
registry.
A further part of this standard will state provisions to guide the management of the local
repositories, to gradually reach an adequate level of interoperability among local
repositories and eventually produce a federated repository or a centralized one.
The process of template and archetype design leads to a formalized constraint on some
portion of some V3 specification. The actual artefact being constrained is captured as part
of the template and archetype metadata, enabling registry users to confirm that a
template and archetype is applicable to a given HL7 V3 specification.
On the other side, a registering organisation can check which other templates and
archetypes are available about a given HL7 fragment, in order to discover similarities and
possibility for convergence with other organisations.
When an area of common interest is identified, two or more organizations could
cooperate to harmonize their templates and archetypes, maybe in the context of an
appropriate HL7 TC.
Create an HL7 instance that conforms to a template and archetype
There are a number of mechanisms by which users create valid HL7 instances (messages
and/or documents). Mapped data can be pulled from an internal database, a local
document can be transformed into a CDA-conformant document, etc. A constraining
template and archetype can be used to guide data entry. For instance, Figure 2 shows
those components that are required for a Comprehensive Review document. This
template and archetype can be used to validate that a CDA document conforms to the
additional constraints expressed in the template and archetype, and can also be used to
guide data entry, ensuring that required document sections are included.
An HL7 instance can carry information showing which templates and archetypes it
conforms to. The “Globally unique identifier” of the resource — that is assigned by the
registry when the template and archetype is submitted — will fit this purpose.
Advance a template and archetype to normative status
In a repository of tens of thousands of templates and archetypes, many of which
potentially overlap, it can be challenging for the registering organizations to know which
template and archetype could be harmonized and/or accepted by multiple communities. .
There may, for instance, be an echocardiography template and archetype submitted by
LOINC, another template and archetype submitted by the American College of
Cardiology, and another one by DICOM. Ideally, these groups would converge over time
and generate either a hierarchy of echocardiography templates and archetypes that
contain progressively more and more constraints and/or they would work together to
produce a single echocardiography template and archetype.
Templates and archetypes in the registry may be approved by a number of professional
societies. In addition, templates and archetypes in the registry can themselves go through
the HL7 ballot process, yielding templates and archetypes that have an HL7 Informative
or an HL7 Normative status.
HL7 Template and Archetype Architecture
175
Template Special Interest Group
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
Declare the use of a template and archetype in a normative specification
An HL7 Technical Committee may want to require the use of a particular HL7 V3
Template and archetype within a specification going through ballot. Should such a
specification become normative, it implies that the required template and archetype has
been advanced to normative status itself, and it requires that conformant instances declare
the use of the template and archetype, using the normative declaration mechanism
described in this standard.
An HL7 Technical Committee may want to require the use of a particular type of HL7 V3
Template and archetype within a balloted specification. For example, a Technical
Committee could decide to provide a generic shape for the templates and archetypes that
represent the subdivision of a document into sections.
In this case that Technical Committee may decide to ballot a generic template and
archetype, to be used as “ancestor” in the production / revision of the related templates
and archetypes in the registry.
HL7 Template and Archetype Architecture
Template Special Interest Group
176
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
12. OUTSTANDING ISSUES
9.1 What are the available tool sets for each of the formalisms required for
implementation (OCL, ADL, OWL)?
9.2 What will be the formal mechanism for integrating standard templates from
professional organizations, research groups, and governmental bodies into the
HL7 repository?
9.3 What is the relationship of CMET’s, RMIM, CDA-RMIM, and Template constraints?
9.4 Who will submit the local vocabularies within the Archetypes to coding organizations
such as ICD, SNOMED, and LOINC? What is the status of these vocabularies, in
various languages, prior to formal international encoding? Who or what
organization will maintain the interim vocabularies?
HL7 Template and Archetype Architecture
Template Special Interest Group
177
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
13. Web Ontology Language (OWL) Specification
13.1 OWL Language and its Formal Logic
The semantics here start with the notion of a vocabulary, which can be
thought of as the URI references that are of interest in a knowledge
base. It is, however, not necessary that a vocabulary consist only of the
URI references in a knowledge base.
An OWL vocabulary V is a set of URI references, including owl:Thing,
owl:Nothing, and rdfs:Literal. Each OWL vocabulary also includes URI
references for each of the XML Schema non-list built-in simple
datatypes. In the semantics LV is the (non-disjoint) union of the value
spaces of these datatypes.
An Abstract OWL interpretation with vocabulary V is a four-tuple of the
form: I = <R, S, EC, ER>
where




R is a non-empty set of resources, disjoint from LV
S:V→R
EC : V → 2^R ∪ 2^LV
ER : V → 2^(R×R) ∪ 2^(R×LV)
S provides meaning for URI references that are used to denote OWL
individuals, while EC and ER provide meaning for URI references that
are used as OWL classes and OWL properties, respectively.
Abstract OWL interpretations have the following conditions having to do
with datatypes:
1. If d is the URI reference for an XML Schema non-list built-in
simple datatype then EC(d) is the value space of this datatype.
2. If c is not the URI reference for any XML Schema non-list built-in
simple datatype then EC(c) is a subset of R.
3. If d,l is a datatype,literal pair then D(d,l) is the data value for l in
XML Schema datatype d.
HL7 Template and Archetype Architecture
Template Special Interest Group
178
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
EC is extended to the syntactic constructs of <description>s,
<dataRange>s, <individual>s, and <propertyValue>s as follows:
Syntax - S
EC(S)
owl:Thing
R
owl:Nothing
{}
rdfs:Literal
LV
complementOf(c)
R - EC(c)
unionOf(c1 … cn)
EC(c1)  … EC(cn)
intersectionOf(c1 … cn)
EC(c1) ∩ … ∩ EC(cn)
oneOf(i1 … in)
{S(i1), …, S(in)}
oneOf(d1,l1 … dn,ln)
{D(d1,l1), …, D(dn,ln)}
restriction(p x1 … xn)
EC(restriction(p
x1))∩…∩EC(restriction(p xn))
restriction(p allValuesFrom(r))
{x R | <x,y> ER(p) → y EC(r)}
restriction(p someValuesFrom(e))
{x R | <x,y> ER(p) → y
EC(e)}
restriction(p value(i))
{x R | <x,S(i)> ER(p)}
restriction(p value(d,l))
{x R | <x,D(d,l)> ER(p)}
restriction(p minCardinality(n))
{x R | card({y : <x,y> ER(p)}) ≤
n}
restriction(p maxCardinality(n))
{x R | card({y : <x,y> ER(p)}) ≥
n}
restriction(p cardinality(n))
{x R | card({y : <x,y> ER(p)}) =
n}
Individual(annotation(…) …
EC(c1) ∩ … ∩ EC(cm) ∩
annotation(…) type(c1) … type(cm) pv1
EC(pv(pv1)) ∩…∩ EC(pv(pvn))
… pvn)
Individual(i annotation(…) …
{S(i)} ∩ EC(c) ∩ … ∩ EC(cm) ∩
annotation(…) type(c1) … type(cm) pv1
EC(pv(pv1)) ∩…∩ EC(pv(pvn))
… pvn)
pv(p Individual(…))
{x R | yEC(Individual(…)) :
<x,y> ER(p)}
pv(p id), for id an individualID
{x R | <x,S(id)> ER(p) }
pv(p d,l)
{x R | <x,D(d,l)> ER(p) }
HL7 Template and Archetype Architecture
Template Special Interest Group
179
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
An Abstract OWL interpretation, I, is an interpretation of OWL axioms
and facts as given in the table below. In the table, optional parts of
axioms and facts are given in square brackets ([…]) and have
corresponding optional conditions, also given in square brackets.
Directive
Conditions on interpretations
Class(c complete annotation(…) …
annotation(…) descr1 … descrn)
EC(c) = EC(descr1) ∩…∩
EC(descrn)
Class(c partial annotation(…) …
annotation(…) descr1 … descrn)
EC(c) EC(descr1) ∩…∩
EC(descrn)
EnumeratedClass(c annotation(…) …
annotation(…) i1 … in)
EC(c) = { S(i1), …, S(in) }
DisjointClasses(d1 … dn)
EC(di) ∩ EC(dj) = { } for 1 ≤ i < j
≤n
EquivalentClasses(d1 … dn)
EC(di) = EC(dj) for 1 ≤ i < j ≤ n
SubClassOf(d1 d2)
EC(d1) EC(d2)
DataProperty(p annotation(…) …
ER(p) ER(s1) ∩…∩ ER(sn) ∩
annotation(…) super(s1) … super(sn)
EC(d1)×LV ∩…∩ EC(dn)×LV
domain(d1) … domain(dn) range(r1) … ∩ R×EC(r1) ∩…∩ R×EC(rn)
range(rn)
[ER(p) is functional]
[Functional])
IndividualProperty(p annotation(…) …
annotation(…)
super(s1) … super(sn)
domain(d1) … domain(dn) range(r1) …
range(rn)
[inverse(i)] [Symmetric]
[Functional] [InverseFunctional]
[Transitive])
ER(p) ER(s1) ∩…∩ ER(sn) ∩
EC(d1)×R ∩…∩ EC(dn)×R ∩
R×EC(r1) ∩…∩ R×EC(rn)
[ER(p) is the inverse of ER(i)]
[ER(p) is symmetric]
[ER(p) is functional] [ER(p) is
inverse functional]
[ER(p) is transitive]
EquivalentProperties(p1 … pn)
ER(pi) = ER(pj) for 1 ≤ i < j ≤ n
SubPropertyOf(p1 p2)
ER(p1) ER(p2)
SameIndividual(i1 … in)
S(ij) = S(ik) for 1 ≤ j < k ≤ n
DifferentIndividuals(i1 … in)
S(ij) ≠ S(ik) for 1 ≤ j < k ≤ n
Individual([i] annotation(…) …
annotation(…)
type(c1) … type(cm) pv1 … pvn)
EC(Individual([i] type(c1) …
type(cm) pv1 … pvn)) is
nonempty
HL7 Template and Archetype Architecture
Template Special Interest Group
180
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
The effect of an imports construct is to import the contents of another
OWL ontology into the current ontology. The imported ontology is the
one that can be found by accessing the document at the URI that is the
argument of the imports construct. The imports closure of an OWL
ontology is then the result of adding the contents of imported ontologies
into the current ontology. If these contents contain further imports
constructs, the process is repeated as necessary. A particular ontology
is never imported more than once in this process, so loops can be
handled.
Annotations have no effect on the semantics of OWL ontologies in the
abstract syntax.
An Abstract OWL interpretation, I, is an interpretation of an OWL
ontology, O, iff I is an interpretation of each axiom and fact in the
imports closure of O.
An Abstract OWL ontology entails an OWL axiom or fact if each
interpretation of the ontology is also an interpretation of the axiom or
fact. An Abstract OWL ontology entails another Abstract OWL ontology
if each interpretation of the first ontology is also an interpretation of the
second ontology. Note that there is no need to create the imports
closure of an ontology - any method that correctly determines the
entailment relation is allowed.
From the RDF model theory [RDF MT], for V a set of URI references
containing the RDF and RDFS vocabulary, an RDFS interpretation over
V is a triple I = < RI, EXTI, SI >. Here RI is the domain of discourse or
universe, i.e., a set that contains the denotations of URI references.
EXTI is used to give meaning to properties, and is a mapping from RI to
sets of pairs over RI × (RI∪LV). Finally, SI is a mapping from V to RI that
takes a URI reference to its denotation. CEXTI is then defined as
CEXTI(c) = { x∈RI | <x,c>∈EXTI(SI(rdf:type)) }. RDFS interpretations
must meet several conditions, as detailed in the RDFS model theory.
For example, SI(rdfs:subClassOf) must be a transitive relation.
An OWL interpretation, I = < RI, EXTI, SI >, over a vocabulary V, where
V includes VRDFS, rdfs:Literal, VOWL, owl:Thing, and owl:Nothing, is
an RDFS interpretation over V that satisfies the following conditions:
HL7 Template and Archetype Architecture
Template Special Interest Group
181
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
Relationships between OWL classes
then
If E is
CEXTI(SI(E))=
with
owl:Thing
IOT
owl:Nothing
{}
rdfs:Literal
LV
owl:Class
IOC
IOCCEXTI(SI(rdfs:Class))
owl:Restriction
IOR
IORIOC
owl:Datatype
IDC
IDCCEXTI(SI(rdfs:Class))
owl:Property
IOP
intraocular
pressureCEXTI(SI(rdf:Property))
owl:ObjectProperty
IOOP
IOOPIOP
owl:DataTypeProperty IODP
IODPIOP
rdf:List
IL
Membership in OWL classes
If E is
then SI(E)
owl:Thing
IOC
owl:Nothing
IOC
rdfs:Literal
IDC
IOTrenal insufficiency
ILRI
a datatype of D IDC
rdf:nil
IL
HL7 Template and Archetype Architecture
Template Special Interest Group
182
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
Characteristics of members of OWL classes
If E is
then if eCEXTI(SI(E)) then
owl:Class
CEXTI(e)IOT
owl:Datatype
CEXTI(e)LV
owl:ObjectProperty
EXTI(e)IOT×IOT
owl:DatatypeProperty EXTI(e)IOT×LV
The next constraints are IFF, which may be harder to deal with in
OWL/DL, as they extend the various categories of properties to all of
owl:Property. However, in OWL/DL ontologies you can neither state that
an owl:DatatypeProperty is inverse functional nor ask whether it is, so
there should be not adverse consequences.
If E is
then cCEXTI(SI(E)) iff cIOP and
owl:SymmetricProperty
<x,y> EXTI(c) → <y, x>EXTI(c)
owl:FunctionalProperty
<x,y1> and <x,y2> EXTI(c) → y1 = y2
owl:InverseFunctionalProperty <x1,y>EXTI(c) <x2,y>EXTI(c) → x1 = x2
<x,y>∈ EXTI(c) <y,z>EXTI(c) →
<x,z>EXTI(c)
RDFS domains and ranges are strengthened to if-and-only-if over the OWL
universe.
If E is
then for
<x,y>∈ CEXTI(SI(E)) iff
owl:TransitiveProperty
rdfs:domain xIOP,yIOC
rdfs:range
<z,w>EXTI(x) → zCEXTI(y)
xIOP,yIOCÎIDC <w,z>EXTI(x) → zCEXTI(y)
HL7 Template and Archetype Architecture
Template Special Interest Group
183
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
Some OWL properties have iff characterizations
If E is
then <x,y>EXTI(SI(E)) iff
owl:sameClassAs
x,yIOC ^CEXTI(x)=CEXTI(y)
owl:disjointWith
x,yIOC ^CEXTI(x)∩CEXTI(y)={}
owl:samePropertyAs x,yIOP ^EXTI(x) = EXTI(y)
x,yIOOP ^<u,v>EXTI(x) iff <v,u>EXTI(y)
owl:inverseOf
owl:sameIndividualAs x = y
owl:sameAs
x=y
owl:differentFrom
x≠y
Some OWL properties have only-if characterizations
We will say that l1 is a sequence of y1,…,yn over C iff n=0 and
l1=SI(rdf:nil) or n>0 and l1εIL and l2, …, ln IL such that
<l1,y1>EXTI(SI(rdf:first)), y1CEXTI(C), <l1,l2>EXTI(SI(rdf:rest)), …,
<ln,yn>EXTI(SI(rdf:first)), ynCEXTI(C), and
<ln,SI(rdf:nil)>EXTI(SI(rdf:rest)).
If E is
then if <x,y>∈ EXTI(SI(E)) then
owl:complementOf x,yIOC and CEXTI(x)=IOT-CEXTI(y)
If E is
then if <x,l>∈ EXTI(SI(E)) then
owl:unionOf
xIOC and l is a sequence of y1,…yn over IOC and
CEXTI(x) = CEXTI(y1)…CEXTI(yn)
owl:intersectionOf
xIOC and l is a sequence of y1,…yn over IOC and
CEXTI(x) = CEXTI(y1)∩…∩CEXTI(yn)
owl:oneOf
xCEXTI(rdfs:Class) and l is a sequence of y1,…yn over
RILV and CEXTI(x) = {y1,..., yn}
If E is
and
then if <x,l>EXTI(SI(E)) then
owl:oneOf
l is a sequence of y1,…yn over
LV
xIDC and CEXTI(x) = {y1,...,
yn}
owl:oneOf
l is a sequence of y1,…yn over
IOT
xIOC and CEXTI(x) = {y1,...,
yn}
If
<x,y>EXTI(SI(owl:allValuesFrom))) ^
<x,p>EXTI(SI(owl:onProperty)))
HL7 Template and Archetype Architecture
Template Special Interest Group
then xIOR, yIOC, pIOP, and
CEXTI(x) =
{uIOT | <u,v>EXTI(p) →
vCEXTI(y) }
184
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
<x,y>EXTI(SI(owl:someValuesFrom))) {uIOT |  <u,v>EXT (p)
I
^
^vCEXTI(y) }
<x,p>EXTI(SI(owl:onProperty)))
<x,y>EXTI(SI(owl:hasValue))) ^
<x,p>EXTI(SI(owl:onProperty)))
{uIOT | <u, y>EXTI(p) }
then xIOR, yLV, y is a nonnegative integer, pIOP, and
CEXTI(x) =
If
<x,y>EXTI(SI(owl:minCardinality))) ^
<x,p>EXTI(SI(owl:onProperty)))
{uIOT | card({v :
<u,v>EXTI(p)}) ≥ y }
<x,y>EXTI(SI(owl:maxCardinality))) ∧
<x,p>EXTI(SI(owl:onProperty)))
{uIOT | card({v :
<u,v>EXTI(p)}) ≤ y }
<x,y>EXTI(SI(owl:cardinality))) ∧
<x,p>EXTI(SI(owl:onProperty)))
{uIOT | card({v :
<u,v>EXTI(p)}) = y }
RI contains elements corresponding to all possible OWL descriptions and data
ranges
The first three conditions require the existence of the finite sequences
that are used in some OWL constructs. The remaining conditions
require the existence of the OWL descriptions and data ranges.
then there exists l1,…,ln ∈ IL with
If there exists
x1, …, xn IOC
<l1,x1> EXTI(SI(rdf:first)), <l1,l2> EXTI(SI(rdf:rest)), …
<ln,xn> EXTI(SI(rdf:first)), <ln,SI(rdf:nil)>
EXTI(SI(rdf:rest))
x1, …, xn
IOTLV
<l1,x1> EXTI(SI(rdf:first)), <l1,l2> EXTI(SI(rdf:rest)), …
<ln,xn> EXTI(SI(rdf:first)), <ln,SI(rdf:nil)>
EXTI(SI(rdf:rest))
If there exists
then there exists y with
l, a sequence of x1,…,xn over
yIOC, <y,l> EXTI(SI(owl:unionOf))
IOC
l, a sequence of x1,…,xn over
yIOC, <y,l> EXTI(SI(owl:intersectionOf))
IOC
l, a sequence of x1,…,xn over yCEXTI(SI(rdfs:Class)), <y,l>
IOTLV
EXTI(SI(owl:oneOf))
then there exists y  IOC with
If there exists
x IOC
<y,x> EXTI(SI(owl:complementOf))
HL7 Template and Archetype Architecture
Template Special Interest Group
185
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
If there exists
Version 3.0
then there exists y IOR with
x IOP ^w IOC IDC
<y,x> EXTI(SI(owl:onProperty)) ^
<y,w> EXTI(SI(owl:allValuesFrom))
x IOP ^w IOC IDC
<y,x> EXTI(SI(owl:onProperty)) ^
<y,w> EXTI(SI(owl:someValuesFrom))
x IOP ^w IOT LV
<y,x> EXTI(SI(owl:onProperty)) ^
<y,w> EXTI(SI(owl:hasValue))
x IOP ^w LV ^w is a non- <y,x> EXTI(SI(owl:onProperty)) ^
negative integer
<y,w> EXTI(SI(owl:minCardinality))
x IOP ^w LV ^w is a non- <y,x> EXTI(SI(owl:onProperty)) ^
negative integer
<y,w> EXTI(SI(owl:maxCardinality))
x IOP ^w LV ^w is a non- <y,x> EXTI(SI(owl:onProperty)) ^
negative integer
<y,w> EXTI(SI(owl:cardinality))
HL7 Template and Archetype Architecture
Template Special Interest Group
186
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
13.2 SR XML example of Procedural Template
10.2.1 Author: Martin Kernberg, MD
GRAPHICAL REPRESENTATION OF HL7 STRUCTURED REPORTS:
ELECTROCARDIOGRAPHY
Author: Martin Kernberg, MD (University of California San Francisco)
ECG SR-XML
1. Position: standard or right
2. Lead count
3. Date
ECG
Demographics
...Template 2
Patient Data
Admininistrative Data
Financial Data
Clinical Indication
...Template 3
+ Comparison
...Template 4
? Clinical Presentation
...Template 5
Technical Methods
...Template 6
Results
Quantitative
Findings
...Template 7
Qualitative
Findings
...Template 8
Impression
...Template 9
Summary
SR XML Procedural Template 1: ECG
SR XML TEMPLATE 2: DEMOGRAPHICS
HL7 Template and Archetype Architecture
Template Special Interest Group
187
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
Demographics
Patient Data
Administrative Data
+ Financial Data
#PCDATA
Name
Date of Birth
Social Security Number
Medical Record Number
#PCDATA
= DATE
#PCDATA
#PCDATA
HL7 Template and Archetype Architecture
Template Special Interest Group
188
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
SR XML TEMPLATE 3: CLINICAL INDICATION(S)
Clinical Indication
Chief Complaint
Age
? Ethnicity
Num
#PCDATA
Gender
PC DATA
#PCDATA
HPI
...
Prior Medical History
...
Presentation
PC DATA
* Differential
Diagnosis
= Diagnoses
+ Diagnoses
Name
Code
#PCDATA
#PCDATA
SR XML TEMPLATE 4: COMPARISON
Comparison
+ Comparison(s)
Study Type
Prior Structured Report
[XLink]
Waveform Image
[XLink]
Waveform Data
[XLink]
#PCDATA
#PCDATA
#PCDATA
Date
= date
= Date
Code
...
SR XML TEMPLATE 5: CLINICAL INFORMATION
HL7 Template and Archetype Architecture
Template Special Interest Group
189
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
Clinical Information
* Clinical
Indication
* ROS
...
? PMHx
* Medications
...
Chief
Complaint
...
* Imaging
HPI
...
* Interventions
* Immunologic
(Allergies)
...
? Family
Hx
...
? Social
Hx
...
? Physical
Examination
* Diagnostic
Tests
=Diagnoses
Smoking
Packs per Day
Total Years
* Surgery
Risk Factors
Legend
ROS
PMHx
Hx
HPI History of Present Illness
Review of Systems
Past Medical History
History
SR-XML Template 6: Technical Methods
HL7 Template and Archetype Architecture
Template Special Interest Group
Differential
Diagnosis
190
November 30, 2003
ECG Template 6: Technical Methods
Technical Methods
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
ECG Technique
#PCDATA
Version 3.0
Acquiring Device
Manufacturer
#PCDATA
Name
#PCDATA
Identification
#PCDATA
Acquisition
Date
= Date
Time
= Time
High Pass Filter
#PCDATA
? Low Pass Filter
#PCDATA
Other Filter
#PCDATA
Technologist
Last
#PCDATA
First
#PCDATA
Middle
#PCDATA
Location
#PCDATA
SR XML Template 7: Quantitative Analysis
ECG Template 7: Quantitative Analysis
Quantitative Analysis
Lead Measurements
Lead Identification
...
? Beat Number
...
? Temporal
...
Global Measurements
? Amplitude
...
? Morphology
P Wave
...
ST Segment
...
? Quality
T Wave
...
Rates
Supraventricular
Atrial
...
HL7 Template and Archetype Architecture
Template Special Interest Group
Intervals
Ventricular
...
Axes
P Axis
...
QRS Axis
...
T Axis
...
Junctional
...
191
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
SR XML Template 8: Qualitative Results
ECG Template 8: Qualitative Analysis
Qualitative Analysis
Rhythm Classification
? Conduction Abnormalities
? Acute Coronary Syndromes
Myocardial Ischemia
= Myocardial Injury
Myocardial Injury
+ Location
Myocardial Infarction
= Myocardial Injury
? Chronicity
? Metabolic Abnormality
? Medical Therapy
= Morphologic Abnormality
? Morphologic Abnormalities
+ Type
? Chronicity
? Pulmonary Disease
= Morphologic Abnormality
SR XML TEMPLATE 9: ASSESSMENT
Assessment
* Principal Quantitative
Findings
* Principal Qualitative
Findings
#PCDATA
#PCDATA
+ Impression(s)
+ Diagnoses
* Action
= Diagnoses
#PCDATA
* Differential Diagnoses
* Means
= Diagnoses
#PCDATA
HL7 Template and Archetype Architecture
Template Special Interest Group
* Plan
* Recommendation
* Communication
#PCDATA
#PCDATA
192
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
13.3 Template Document Ontology
HL7 TEMPLATE ARCHITECTURE : DOCUMENT ONTOLOGY AND
SECTION DEFINITIONS
DRAFT ONLY: Martin Kernberg, MD, February 19, 2003
INTRODUCTION: GENERAL DOCUMENT TYPES IN CLINICAL MEDICINE
Clinical documents can be organized on the basis of multiple axes: author (health
professional, staff, and administrators), location (hospital, clinic, office), function
(clinical, referral, education, research), general constituent sections (clinical information,
diagnostic tests, procedures, assessment, plan), and clinical domains (reviewed below).
The Clinical Domains, in turn, can be organized on the basis of two axes: spatial
(specific organ system versus systemic process) and temporal (acute versus chronic;
neonate to adult; terminal and transcendent).
Modeling of the specific constituent sections of the general document types is
provided in a clinically accessible graphical notation, SR XML, for the HL7 Template
Architecture.
HL7 Template and Archetype Architecture
Template Special Interest Group
193
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
PART 1 DOCUMENT ONTOLOGY: GENERAL DOCUMENT TYPES
Empiric compilation at the Veterans Administration has tabulated over 1800
document types; the information model provided below, based on an archetypal episode
of care predicts 1920 document types (approximately 60 adult clinical domains x 32
document types).
Legend
*
+
?
HL7 Template and Archetype Architecture
Template Special Interest Group
0 or more
1 or more
0 or 1 (optional)
194
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
REPORT TYPES (Based on
Temporal Sequence)
N. = Note
R. = Report
HOSP.
CLINIC
OFFICE
CLINICAL
REFERRAL
EDUCATION
RESEARCH
Clinical
Information
Template
Reminder
Letter for
Appointment
2. Pre-Visit
Instructions
3. Patient
Questionnaire
4. Annual
Physical
Examination
5. Patient Record
Release
6. Clinical
Referral Letter
7. Telephone R.
8. Emergency
Department Report
9. EKG R.
10. Imaging Report
11. Laboratory R.
12. Consultant N.
13. Admit History
and Physical
14. Admission
Orders
15. Standing
Orders
16. Interventional
Procedure Note
17. Pre-Anesthesia
Note
18. Pre-operative
Surgical Note
19. Anesthesia N.
H, C, O
C
*
H, C, O
C, E
*
H, C, O
C
C, O
20. Surgical N.
21. Surgical Post-op
22. Anesthesia Postoperative Note
23. Progress Note
1.
Diagnostic
Tests
Template
Procedure
Template
Assessment
Template
Plan
Temp.
*
*
*
*
*
*
*
*
C
+
*
*
H, C, O
C
*
H, C, O
REF
+
*
*
+
+
H
C
C
+
+
*
*
*
+
+
+
+
H, C, O
H, C, O
H, C, O
H, C, O
H
C
C
C
C
C
+
+
*
+
+
*
*
+
*
*
+
+
*
*
*
+
+
*
+
+
?
?
H
C
+
*
*
H
C
H, C
C
+
*
+
+
*
H, C
C
+
*
*
+
*
H, C
C
+
+
+
+
*
H, C
C
+
+
+
+
*
H, C
H, C
H, C
C
C
C
+
*
+
*
*
*
+
*
+
*
+
*
*
+
H, C, O
C
+
*
*
+
*
24. Progress Report
25. Clinical Course
H, C, O
H, C, O
C
C
+
+
*
*
*
*
+
+
*
*
26. Discharge
Summary
27. Medications
28. Discharge
Instructions
29. Educational
Materials
30. Education Report
31. Follow-up Visit
32. Follow-up Report
H, C, O
C
+
*
*
+
*
H, C, O
H, C, O
C
E
*
+
?
?
*
+
+
*
H, C, O
E
+
*
*
*
*
H, C, O
H, C, O
H, C, O
E
C
C
*
+
+
*
*
*
*
*
*
*
+
+
*
*
*
HL7 Template and Archetype Architecture
Template Special Interest Group
+
*
*
*
+
+
195
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
PART 2: DOCUMENT ONTOLOGY AND CLINICAL DOMAINS
Empiric estimates of the number of clinical domains reach over 120 in number;
the information model provided below predicts 150 clinical domains.
Clinical Domain/Field
A
/
P
HP
Medicine
Surgery
Radiology
+
+
Neurosurgery
Neuroradiology
+
+
+
+
Ophthalmology
Otolaryngology
Neuroradiology
Head and Neck Imaging
+
+
Neurology/
Anesthesiology/
Psychiatry
(Optometrist)
Allergy and
Immunology
Cardiology
Cardiovascular Imaging
Hemovascular
System
6. Pulmonary
System
7. Gastrointestinal
System
8. Renal System
9. Reproductive
System
10. Musculo-skeletal
+
+
Hematology
Cardiovascular
Surgery
Vascular Surgery
+
+
Pulmonology
Thoracic Surgery
+
+
Gastroenterology
+
+
+
Nephrology
+
+
Rheumatology
Gastrointestinal
Surgery
Urology
Obstetrics and
Gynecology
Orthopedics
11. Dermal System
+
+
Dermatologist
Plastic Surgery
+
+
Endocrinology
Endocrine Surgery
+
+
+
+
+
Immunologist
Toxicologist
Infectious Diseases
Oncology
Transplant Surgery
17. Neonatal Life
+
18. Childhood
19. Adolescence
+
+
Genetics
Neonatology
Pediatrics
Adolescent Medicine
ORGAN
SYSTEMS
1. Central Nervous
System
2.
3.
4.
Eye
Ear, Nose, and
Throat
Heart
5.
SYSTEMIC PROCESSES
12. EndocrineMetab
olic
13. Immune System
14. Toxins
15. Infectious
16. Neoplasia
+
+
Interventional
Radiology
Chest Radiology
Gastrointestinal
Radiology
Uroradiology
Women’s Imaging
Musculoskeletal
Imaging
Nuclear Medicine
Surgical Oncology
Radiation Oncology
Pediatric Surgery
Pediatric Radiology
Trauma
Emergency Radiology
TEMPORAL
20. Adulthood
21. Acute Medical
Process
+
+
+
Internal Medicine
Emergency Medicine
Intensive Care
Medicine
Geriatrics
22. Chronic Medical
Process
23. In Vitro or
Terminal
Process
+
+
General Pathology
Laboratory Medicine
24. Transcendent
+
Medical Ethics
Surgical Pathology
GENERAL
HL7 Template and Archetype Architecture
Template Special Interest Group
196
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
25.
+
Family Practice
General Surgery
Diagnostic Radiology
Notes:
1. A/P
Adult/pediatric subspecialization is indicated.
2. HP:
Particular fields may be further subdivided, for purposes of a
document ontology, by associated health professional groups, such as
physicians (MD), physicians assistants (PA), nurses and nurse practitioners
(NP), nursing assistants (NA), licensed vocational nurses (LVN), and
radiologic technologists (RT).
3. As an example, a physician’s assistant (PA) may specialize in cardiovascular
surgery, performing vein harvesting for coronary artery bypass grafts, and
produce a PA coronary artery bypass surgery (C.A.B.G.) saphenous vein
harvesting note.
HL7 Template and Archetype Architecture
Template Special Interest Group
197
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
PART 3: APPLICATION OF INFORMATION MODEL TO CLINICAL
PRESENTATION IN EMERGENCY MEDICINE: Template Examples
Each section of the following table, with respect to medical and surgical
complaints, is generally related to a single template; within procedures and imaging, each
listing within a section is generally related to a single template or group of templates (for
example, imaging templates are defined by both type of imaging and anatomic site). As
emergency medicine represents a sampling of all fields of clinical medicine, albeit
partial, a common point of departure is thus defined for further specification and
integration of other subspecialty templates.
Organ System/Field
Medical Complaint
Surgical Complaint
Imaging
Management/Procedur
Central Nervous System
Headache
Seizure
Syncope
Confusion
Dementia
Psychosis
Depression
Conjunctivitis
Contusion
Concussion
Coma
Skull fracture
Head CT
Brain MRI
Lumbar Puncture
Corneal abrasion
Globe laceration
Orbital floor fracture
LaForte Fractures
Nasal Fracture
Facial Contusion
Orbital Series
Orbital CT
Wood’s Lamp
Slit Lamp
Eye
Ear, Nose, and Throat
Endocrine/Metabolic
Immune System
Heart
Hemovascular System
Pulmonary System
Otitis Media
Otitis Externa
Rhinitis
Pharyngitis
Sinusitis
Thyroid Storm
Addisonian Crisis
Urticaria
Anaphylactoid Reaction
Delayed hypersensitivity
Anaphylaxis
Chest Pain
Cardiac Arrest
Dysrhythmia
Cardiac Tamponade
Myocardial Ischemia
Myocardial Infarct
Cardiac Standstill
Ventricular Rupture
Congestive Heart Failure
Hypertension
Anemia
Hypertension
Hypotension
Venous Stasis
Venous Thrombosis
Arterial Insufficiency
Arterial Occlusion
Shortness of Breath
HL7 Template and Archetype Architecture
Template Special Interest Group
Facial Series
Mandible Series
Temporal Bone CT
Facial CT
Dehydration
Rehydration
Antihistamines
H2 Blockers
Epinephrine
Steroids
Pericardiocentesis
Cardiac Contusion
Cadiac Tamponade
Chest Pain MPS
Chest Radiograph
Echocardiography
Transesophageal Echo
Cardiac MRI
Chest CT
Hemorrhage
Venous Ultrasound
Peripheral Arterial US
Spiral CT Angio
MR Angiography
Hemostasis
Pulmonary Contusion
Chest Radiograph
Pleurocentesis
198
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
Dyspnea
Tachypnea
Bronchospasm
Bronchitis
Pneumonia
Pleural Effusion
Abdominal Pain
Mesenteric Ischemia
Mesenteric Infarct
Gastritis
Gastroenteritis
Pancreatitis
Cholecystitis
Pulmonary Laceration
Pneumothorax
Chest CT
Chest Tube
Ileus
Bowel Infarction
Volvulus
Hepatic Laceration
Splenic Laceration
Pancreatic Contusion
Cholelithiasis
KUB
Abdominal Series
Abdominal US
Abdominal/Pelvic CT
Abdominal/Pelvic MRI
Diagnostic Peritoneal
Lavage
Genitorenal System
Pyelonephritis
Cystitis
Urethritis
Hematuria
KUB
IVP
Spiral CT
Retrograde Urethrogram
Foley Catheter Placem
Reproductive System
Cervicitis
Endometriosis
Urethritis
Pelvic US
Endovaginal US
Culdocentesis
Delivery
C-Section
Musculoskeletal
Osteoarthritis
Rheumatoid arthritis
Septic arthritis
Reiter’s
Gout
Hydronephrosis
Ureteral Obstruction
Renal Colic
Bladder Contusion
Bladder Laceration
Ov. Cyst Hemorrhage
Ovarian Cyst Rupture
Ovarian Torsion
Uterine Prolapse
Ectopic Pregnancy
Premature Labor
Muscle strain
Muscle rupture
Joint Subluxation
Joint Dislocation
Skeletal Fracture
Amputation
Skeletal Radiography
Bone scan
Skeletal CT
Musculoskeletal MRI
Splint
Reduction
Traction
Dermal system
Contact Dermatitis
Allergic Dermatitis
Psoriasis
Impetigo
Cellulitis
Necrotizing Fasciitis
Gastrointestinal System
HL7 Template and Archetype Architecture
Template Special Interest Group
Laceration
Contusion
Ecchymosis
Hematoma
Burn
Laceration Repair
199
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
PART 4: A DOCUMENT ONTOLOGY FOR MEDICAL IMAGING
Two axes, anatomic site (local and systemic) and radiation types (in ascending
order of waveform energy), provide the structure of document ontology in cardiology and
radiology. (Addition of visible light, with or without magnification, would encompass
fiberoptic, laparoscopic, and exploratory surgical methods, which are modeled
elsewhere).
ANATOMIC
SITE (CephaloCaudal Sequence)/
RADIATION TYPE
Ultrasound
Magnetic
Resonanc
e Imaging
Nuclear
Medicine
X-Ray
(Conventional
Radiography,
Fluoroscopy,
Conventional
Tomograms)
CT
Head
Neonatal
US
Brain
MRI
Brain SPECT
Brain PET
Brain CT
Spine
(C-spine,
T-spine,
LS-spine)
Fetal US
+
Gallium
Bone Scan
Skull Series
Nasal Series
Facial Series
+
Orbit
+
+
Orbital Series
CT Orbit
Temporal Bones
+
TMJ
Sinuses
+
Sinus Series
CT Temporal
Bones
CT Sinues
Mandible
+
Bone Scan
+
Interventional
Cardiology and
Radiology
(Biopsy, Drainage
Catheters,
Angioplasty)
Lumbar Puncture
Mandibular Series
Orthopantomogram
Dental series
Neck Soft Tissue
+
Chest radiograph
Chest CT
Lung Bx
Cardiac Catheterization
Coronary
artery
calcification
Pericardiocentesis
Pacemaker
Dentition
Neck
+
+
+
Thorax
+
+
Cardiac
Echocardio
graphy
ICE
IVUS
Cardiovascular
MRI
Hemovascular
System
Doppler
Vascular
MRA
99m TC/tagged
RBC
Venography
Conventional
Angiography
Spiral CTA
Angioplasty
Stent
Rotoblader
Laser
Pulmonary
System
Gastrointestinal
System
+
+
CXR
+
+
CT Chest
Spiral CTA
CT Abdomen
CT Pelvis
Lung Bx
Chest Tube
G-tube
J-tube
Renal System
+
+
Ventilation
Perfusion
Gastric
emptying
HIDA
Liver-Spleen
Renal Scan
CT
Nephrostomy tube
Thyroid
Parathyroid
Ventilation
Perfusion
Planar
SPECT
PET
RNA
HL7 Template and Archetype Architecture
Template Special Interest Group
Barium Swallow
UGI Series
SB Series
Colon Series
KUB
+
+
200
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
IVP
Reproductive
System
Pelvis
Musculo-skeletal
SYSTEMIC
PROCESSES
Endocrine
Metabolic
Immune System
Toxins
Infectious
Inflammatory
Neoplasia
+
Testicular Scan
Hysterosalpingogram
Nephrotomogram
+
+
+
+
Bone Scan
Bone Scan
Gallium
+
+
+
+
+
+
+
+
Metabolic Survey
+
+
+
+
Pheochromocytoma
Gallium
+
+
+
+
Lymphangiogram
Radiograph (Lead)
+
+
+
+
+
Metastatic Survey
+
+
Obstetric
Gynecologic
Indium-111
Gallium
18-FDG
HL7 Template and Archetype Architecture
Template Special Interest Group
placement
+
201
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
14. GLOSSARY
CDA
Clinical Document Architecture is a HL7 clinical document standard.
HL7
Health Level 7 is an international standards organization, which provides health-related
open source standards both within the United States, as a member of the American
National Standards Institute, and internationally as a participant in the ISO (International
Standards Institute).
SIG
Special Interest Group is a standards development committee within the HL7
organization.
SR-XML
Is an XML based language for the representation of structured reporting, with
particular emphasis on clinical documents, based upon the SGML “Elm Tree” graphic
notation, and extended by University of California San Francisco for specific clinical
applications as a shared interface among clinical domain experts, informaticists, and
computer programmers.
HL7 Template and Archetype Architecture
Template Special Interest Group
202
November 30, 2003
HL7 TEMPLATE AND ARCHETYPE ARCHITECTURE
Version 3.0
15. REFERENCES













i
3M Information Models
CEN Archetypes
o Chapter on Conformance and Extensibility
o DSTC Archetype Editor (http://www.openehr.org/DSTC1.htm)
EbXML, XML.org, OASIS Registries
GEHR Archetypes
HL7 Clinical Document Architecture (ANSI/HL7 CDA R1.0-2000)
HL7 HDF (2002)
HL7 v2 Global Message Profile Library User's Guide, June 13, 2002.
HL7 V2.5, Chapter 2, Committee Ballot #1, Feb, 2002.
HL7 V2.x Message Profiling Specification, Version 2.2, Nov 30, 2000.
HL7 Version 3.0,
ISO TS17117
openEHR (http://www.openehr.org/)
SNOMED/DICOM Microglossary
http://www.w3.org/TR/owl-semantics/#1
HL7 Template and Archetype Architecture
Template Special Interest Group
203
November 30, 2003