The standards in this document provide an integrated group ...
EDITORS, CO-EDITORS, AND CONTRIBUTORS
|Editors: |Principal Editors: |
| |Peter L. Elkin, MD, Mayo Clinic (Elkin.Peter@mayo.edu) |
| |Martin Kernberg, MD, UCSF (mkfrad@) |
| | |
| |Co-Editors: |
| |Thomas Beale, Ocean Informatics |
| |Sam Heard, MD, Ocean Informatics |
| |Mark Shafarman, Chair-Elect, 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 (charliem22@) |
| |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 |
REVISION HISTORY
|Revision history |
|Version |Date |Author |Comments |
|1.0 | |R Dolin |Initial Baltimore Draft, with Templates SIG, EHR SIG, and Structured |
| | | |Documents TC, Modelling and Methodology TC, Vocabulary TC, Clinical |
| | | |Decision Support |
|1.1 |19 Feb 2003 |M. Kernberg |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 |ADL Language independence, additional languages and terminology |
| | | |approaches |
|1.4 |11 Apr 2003 |T Beale |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 |P Elkin |Draft Proposal for HL7 Memphis Meeting; Integration of OWL Model |
|2.1 |November 30, 2003 |M Kernberg and P Elkin, T |Revisions based on HL7 Memphis Meeting 2003; Integration of ADL Model; |
| | |Beale, and S Heard |Integration of OCL Constraint Language for HL7 Artifacts; Integration of |
| | | |SML for Expert Contributions |
|2.5 |September, 2004 |P. Elkin, T Beale, R. Hamm, S |Revisions to the Spec based on the Conf Call feedback and the KR work on |
| | |Heard |Templates and Archetypes. |
Table of Contents
1. ABSTRACT 8
2. INTRODUCTION 8
Intent of this document 8
What is the mechanism of templates and archetypes? 8
What is the intended purpose of a template and archetype? 10
How do templates and archetypes differ from related HL7 artifacts? 11
SCOPE OF HL7 V3 TEMPLATES AND ARCHETYPES 14
Guiding principles 14
In scope 14
Out of scope 15
3. HL7 Definition of Terms 15
4. ARCHITECTURAL OVERVIEW: RELATIONSHIP OF TECHNICAL FORMALISMS AND THE RIM 16
5. TEMPLATES AS GENERAL CONSTRAINTS ON HL7 ARTIFACTS 18
Template and archetype requirements 18
Template and archetype design 18
Template and archetype assertions 18
Static assertions 18
Co-occurrence assertions 19
Containment assertions 20
Logic assertions 20
Normative template and archetype representation 20
Template and archetype declaration 20
Template and archetype registration 21
Template and archetype repository 21
Template and archetype metadata 21
9. OCL: GENERAL CONSTRAINTS ON HL7 ARTIFACTS 70
Object Constraint Language Specification 70
Contents 70
Topic Page 70
9.1 Overview 70
9.1.1 Why OCL? 70
9.1.2 Where to Use OCL 71
9.2 Introduction 72
9.2.1 Legend 72
9.2.2 Example Class Diagram 72
9.3 Relation to the UML Metamodel 72
9.3.1 Self 72
9.3.2 Specifying the UML context 73
9.3.3 Invariants 73
9.3.4 Pre- and Postconditions 74
9.3.5 Package context 74
9.3.6 General Expressions 75
9.4 Basic Values and Types 75
9.4.1 Types from the UML Model 75
9.4.2 Enumeration Types 76
9.4.3 Let Expressions and «definition» Constraints 76
9.4.4 Type Conformance 76
9.4.5 Re-typing or Casting 77
9.4.6 Precedence Rules 78
9.4.7 Use of Infix Operators 78
9.4.8 Keywords 78
9.4.9 Comment 78
9.4.10 Undefined Values 79
9.5 Objects and Properties 79
9.5.1 Properties 79
9.5.2 Properties: Attributes 80
9.5.3 Properties: Operations 80
9.5.4 Properties: Association Ends and Navigation 80
9.5.5 Navigation to Association Classes 82
9.5.6 Navigation from Association Classes 83
9.5.7 Navigation through Qualified Associations 83
9.5.8 Using Pathnames for Packages 84
9.5.9 Accessing overridden properties of supertypes 84
9.5.10 Predefined properties on All Objects 85
9.5.11 Features on Classes Themselves 85
9.5.12 Collections 86
9.5.13 Collections of Collections 87
9.5.14 Collection Type Hierarchy and Type Conformance Rules 87
9.5.15 Previous Values in Postconditions 88
9.6 Collection Operations 88
9.6.1 Select and Reject Operations 89
9.6.2 Collect Operation 90
9.6.3 ForAll Operation 91
9.6.4 Exists Operation 91
9.6.5 Iterate Operation 92
9.6.6 Iterators in Collection Operations 93
9.6.7 Resolving Properties 93
9.7 The Standard OCL Package 93
9.8 Predefined OCL Types 94
9.8.1 Basic Types 94
9.8.2 Collection-Related Types 98
9.9 Grammar 105
10. TEMPLATE AND ARCHETYPE CONSTRAINTS ON CLINICAL DATA: SYNTAX 109
10.1 ADL Formalism 109
Introduction 109
Status 109
Syntax Overview 110
Typographical Conventions 110
Symbols 110
Archetype Structure 111
Body Part Syntax 111
Terminology Part 112
Identification 113
ISO Oid Id 113
Multi-axial Archetype Identifier 114
Archetype Metadata 115
Archetype Relationships 117
Composition 117
Specialization 117
Versions 118
Revisions 118
Relationship with Knowledge – Ontologies and Terminology 118
Design Time Node Names 118
Runtime Node Name Constraints 118
Values 119
Terminology Definitions and Bindings 119
Paths 120
Invariants 121
Templates 122
Foreign Languages 122
Archetype Examples 123
Blood Pressure 124
problem/SOAP Headings 127
Haematology result 131
Complete Blood Count (CBC) 132
APGAR 134
Template Examples 138
Ante-natal Visit 138
Diabetic Review Contact 138
Querying 138
Production Rules 139
Generic Syntax 139
OpenEHR Plug-ins 141
References 142
10.2 SR-XML: GRAPHICAL TEMPLATE REPRESENTATION 143
SR XML OF CLINICAL INFORMATION AND PROCEDURES 143
SR XML TEMPLATE 1: CLINICAL INFORMATION 144
SR XML TEMPLATE 2: DEMOGRAPHICS 145
SR XML TEMPLATE 3: CLINICAL INDICATION 146
SR XML TEMPLATE 4: INTERVENTIONAL (OR IMAGING) REPORT 146
SR XML TEMPLATE 5: COMPARISON 147
SR XML TEMPLATE 6: TECHNICAL METHODS 148
SR XML TEMPLATE 7: QUANTITATIVE ANALYSIS 148
SR XML TEMPLATE 8: QUALITATIVE ANALYSIS 149
SR XML IMAGING/INTERVENTIONAL TEMPLATE 9: ASSESSMENT 150
SR XML IMAGING/INTERVENTIONAL TEMPLATE 10: PLAN 150
11. TEMPLATE CONSTRAINTS ON CLINICAL DATA: SEMANTICS 151
11.1 OWL Formalism 151
11.2 Template and archetype Formalism 151
OWL Class Axioms 152
11.3.2.2. OWL Descriptions 152
11.3.2.3. OWL Restrictions 153
11.3.2.4. OWL Property Axioms 154
11.3 Example Template and archetype For a CBC 155
11.4 Template and archetype Validation 157
11.5 HL7 ebXML Registry 162
Template and archetype registration 162
Finding a registered template and archetype 169
Create an HL7 instance that conforms to a template and archetype 170
Advance a template and archetype to normative status 170
Declare the use of a template and archetype in a normative specification 171
12. OUTSTANDING ISSUES 172
13. Web Ontology Language (OWL) Specification 173
13.1 OWL Language and its Formal Logic 173
Relationships between OWL classes 177
Membership in OWL classes 177
Characteristics of members of OWL classes 178
RDFS domains and ranges are strengthened to if-and-only-if over the OWL universe. 178
Some OWL properties have iff characterizations 179
RI contains elements corresponding to all possible OWL descriptions and data ranges 180
13.2 SR XML example of Procedural Template 182
SR XML Procedural Template 1: ECG 182
SR XML TEMPLATE 2: DEMOGRAPHICS 182
SR XML TEMPLATE 3: CLINICAL INDICATION(S) 184
SR XML TEMPLATE 4: COMPARISON 184
SR XML TEMPLATE 5: CLINICAL INFORMATION 184
SR-XML Template 6: Technical Methods 185
SR XML Template 7: Quantitative Analysis 186
SR XML Template 8: Qualitative Results 187
SR XML TEMPLATE 9: ASSESSMENT 187
13.3 Template Document Ontology 188
INTRODUCTION: GENERAL DOCUMENT TYPES IN CLINICAL MEDICINE 188
PART 1 DOCUMENT ONTOLOGY: GENERAL DOCUMENT TYPES 189
PART 2: DOCUMENT ONTOLOGY AND CLINICAL DOMAINS 191
Notes: 192
PART 3: APPLICATION OF INFORMATION MODEL TO CLINICAL PRESENTATION IN EMERGENCY MEDICINE: Template Examples 193
PART 4: A DOCUMENT ONTOLOGY FOR MEDICAL IMAGING 195
14. GLOSSARY 197
15. REFERENCES 198
1. ABSTRACT 8
2. INTRODUCTION 8
Intent of this document 8
What is the mechanism of templates and archetypes? 8
What is the intended purpose of a template and archetype? 10
How do templates and archetypes differ from related HL7 artifacts? 11
SCOPE OF HL7 V3 TEMPLATES AND ARCHETYPES 14
Guiding principles 14
In scope 14
Out of scope 15
3. HL7 Definition of Terms 15
4. ARCHITECTURAL OVERVIEW: RELATIONSHIP OF TECHNICAL FORMALISMS AND THE RIM 16
5. TEMPLATES AS GENERAL CONSTRAINTS ON HL7 ARTIFACTS 18
Template and archetype requirements 18
Template and archetype design 18
Template and archetype assertions 18
Static assertions 18
Co-occurrence assertions 19
Containment assertions 20
Logic assertions 20
Normative template and archetype representation 20
Template and archetype declaration 20
Template and archetype registration 21
Template and archetype repository 21
Template and archetype metadata 21
6. OCL: GENERAL CONSTRAINTS ON HL7 ARTIFACTS 25
Object Constraint Language Specification 25
Contents 25
Topic Page 25
6.1 Overview 26
6.1.1 Why OCL? 26
6.1.2 Where to Use OCL 27
6.2 Introduction 27
6.2.1 Legend 27
6.2.2 Example Class Diagram 27
6.3 Relation to the UML Metamodel 28
6.3.1 Self 28
6.3.2 Specifying the UML context 28
6.3.3 Invariants 29
6.3.4 Pre- and Postconditions 29
6.3.5 Package context 30
6.3.6 General Expressions 30
6.4 Basic Values and Types 30
6.4.1 Types from the UML Model 31
6.4.2 Enumeration Types 31
6.4.3 Let Expressions and «definition» Constraints 31
6.4.4 Type Conformance 32
6.4.5 Re-typing or Casting 33
6.4.6 Precedence Rules 33
6.4.7 Use of Infix Operators 34
6.4.8 Keywords 34
6.4.9 Comment 34
6.4.10 Undefined Values 34
6.5 Objects and Properties 35
6.5.1 Properties 35
6.5.2 Properties: Attributes 35
6.5.3 Properties: Operations 35
6.5.4 Properties: Association Ends and Navigation 36
6.5.5 Navigation to Association Classes 37
6.5.6 Navigation from Association Classes 38
6.5.7 Navigation through Qualified Associations 39
6.5.8 Using Pathnames for Packages 39
6.5.9 Accessing overridden properties of supertypes 39
6.5.10 Predefined properties on All Objects 40
6.5.11 Features on Classes Themselves 41
6.5.12 Collections 41
6.5.13 Collections of Collections 42
6.5.14 Collection Type Hierarchy and Type Conformance Rules 42
6.5.15 Previous Values in Postconditions 43
6.6 Collection Operations 44
6.6.1 Select and Reject Operations 44
6.6.2 Collect Operation 45
6.6.3 ForAll Operation 46
6.6.4 Exists Operation 47
6.6.5 Iterate Operation 47
6.6.6 Iterators in Collection Operations 48
6.6.7 Resolving Properties 48
6.7 The Standard OCL Package 49
6.8 Predefined OCL Types 49
6.8.1 Basic Types 49
6.8.2 Collection-Related Types 54
6.9 Grammar 60
7. TEMPLATE AND ARCHETYPE CONSTRAINTS ON CLINICAL DATA: SYNTAX 64
7.1 ADL Formalism 64
Introduction 64
Status 64
Syntax Overview 65
Typographical Conventions 65
Symbols 65
Archetype Structure 66
Body Part Syntax 66
Terminology Part 67
Identification 68
ISO Oid Id 68
Multi-axial Archetype Identifier 69
Archetype Metadata 70
Archetype Relationships 72
Composition 72
Specialization 72
Versions 73
Revisions 73
Relationship with Knowledge – Ontologies and Terminology 73
Design Time Node Names 73
Runtime Node Name Constraints 73
Values 74
Terminology Definitions and Bindings 74
Paths 75
Invariants 76
Templates 77
Foreign Languages 77
Archetype Examples 78
Blood Pressure 79
problem/SOAP Headings 82
Haematology result 86
Complete Blood Count (CBC) 87
APGAR 89
Template Examples 93
Ante-natal Visit 93
Diabetic Review Contact 93
Querying 93
Production Rules 94
Generic Syntax 94
OpenEHR Plug-ins 96
References 97
7.2 SR-XML: GRAPHICAL TEMPLATE REPRESENTATION 98
SR XML OF CLINICAL INFORMATION AND PROCEDURES 98
SR XML TEMPLATE 1: CLINICAL INFORMATION 99
SR XML TEMPLATE 2: DEMOGRAPHICS 100
SR XML TEMPLATE 3: CLINICAL INDICATION 101
SR XML TEMPLATE 4: INTERVENTIONAL (OR IMAGING) REPORT 101
SR XML TEMPLATE 5: COMPARISON 102
SR XML TEMPLATE 6: TECHNICAL METHODS 103
SR XML TEMPLATE 7: QUANTITATIVE ANALYSIS 103
SR XML TEMPLATE 8: QUALITATIVE ANALYSIS 104
SR XML IMAGING/INTERVENTIONAL TEMPLATE 9: ASSESSMENT 105
SR XML IMAGING/INTERVENTIONAL TEMPLATE 10: PLAN 105
8. TEMPLATE CONSTRAINTS ON CLINICAL DATA: SEMANTICS 106
8.1 OWL Formalism 106
8.2 Template and archetype Formalism 106
OWL Class Axioms 107
8.3.2.2. OWL Descriptions 107
8.3.2.3. OWL Restrictions 108
8.3.2.4. OWL Property Axioms 109
8.3 Example Template and archetype For a CBC 110
8.4 Template and archetype Validation 112
8.5 HL7 ebXML Registry 117
Template and archetype registration 117
Finding a registered template and archetype 124
Create an HL7 instance that conforms to a template and archetype 125
Advance a template and archetype to normative status 125
Declare the use of a template and archetype in a normative specification 126
9. OUTSTANDING ISSUES 127
10. APPENDICES 128
10.1 OWL Language and its Formal Logic 128
Relationships between OWL classes 132
Membership in OWL classes 132
Characteristics of members of OWL classes 133
RDFS domains and ranges are strengthened to if-and-only-if over the OWL universe. 133
Some OWL properties have iff characterizations 134
RI contains elements corresponding to all possible OWL descriptions and data ranges 135
10.2 SR XML example of Procedural Template 137
SR XML Procedural Template 1: ECG 137
SR XML TEMPLATE 2: DEMOGRAPHICS 137
SR XML TEMPLATE 3: CLINICAL INDICATION(S) 139
SR XML TEMPLATE 4: COMPARISON 139
SR XML TEMPLATE 5: CLINICAL INFORMATION 139
SR-XML Template 6: Technical Methods 140
SR XML Template 7: Quantitative Analysis 141
SR XML Template 8: Qualitative Results 142
SR XML TEMPLATE 9: ASSESSMENT 142
10.3 Template Document Ontology 143
INTRODUCTION: GENERAL DOCUMENT TYPES IN CLINICAL MEDICINE 143
PART 1 DOCUMENT ONTOLOGY: GENERAL DOCUMENT TYPES 144
PART 2: DOCUMENT ONTOLOGY AND CLINICAL DOMAINS 146
Notes: 147
PART 3: APPLICATION OF INFORMATION MODEL TO CLINICAL PRESENTATION IN EMERGENCY MEDICINE: Template Examples 148
PART 4: A DOCUMENT ONTOLOGY FOR MEDICAL IMAGING 150
11. GLOSSARY 152
12. REFERENCES 153
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.[?]
• 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.
• 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.
1 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, document-level, section-level and entry-level templates can be used to constrain the generic Clinical Document Architecture specification.
2 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 Figure 1.
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.
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.
[pic]
By the Templates mechanism, HL7 empowers external organizations to generate, maintain and distribute packages of Templates that correspond to defined use cases. 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.
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 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 the case that a user needs to create both a conformance profile and one or more Templates to achieve the desired degree of constraint.
[pic]
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.
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) [?].
• 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.
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.
2. REFERENCES AND ABBREVIATIONS (Separate section)
2.8.1 references
2.8.2 abbreviations
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.
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.
[pic]
[pic]
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.
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 valued[?] by numbers.
A Template or constituent Templates can express a regular expression constraint[?] 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 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:
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.
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.
1. ABSTRACT
The standards in this document provide an integrated group of formalisms, methodology, and a repository mechanism for constraints on HL7 artifacts in general, 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.
2. INTRODUCTION
Introduction
Intent of this document
The primary intent of this document is to define a set of provisions to facilitate production, implementation and comparison of HL7 V3 Template and Archetypes.
This document provides a normative representation for HL7 V3 Template and Archetypes and a description of the metadata to characterize them.
Exactly what is meant by “HL7 V3 Templates and Archetypes”, and the various scenarios surrounding the use of these artifacts will also be described in sufficient detail as to enable their implementation.
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 and archetypes,
- 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 and archetypes,
- The guidelines for the uniform generation of the most relevant types of templates and archetypes across the cooperating organizations, including any specific intermediate formalism that will be found appropriate for each type for template and archetype to facilitate input and verification of templates and archetypes by domain experts.
What is the mechanism of templates and archetypes?
In the general sense, a template and archetype 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 Template and archetype 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 and archetypes.
The stepwise process to produce, maintain and distribute templates and archetypes will be supported by a series of annexes, as illustrated in fig. N1.
[pic]
By the template and archetype mechanism, HL7 empowers external organizations to generate, maintain and distribute packages of templates and archetypes that correspond to defined use cases.
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 and archetypes 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 and archetypes 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 and archetypes. 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 and archetypes. Other organizations can notify their interest in the package or in particular templates and archetypes, and contribute to their maintenance and distribution, by cooperating with the primary responsible organization or by including the package or individual templates and archetypes 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 and archetypes 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 and archetypes. This process will be facilitated by the registry of templates and archetypes and by the normative formalism to represent templates and archetypes.
Relevant templates and archetypes 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 and archetypes, to be used as “ancestors” to revise a set of existing templates and archetypes 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 and archetype 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 and archetypes.
When the responsible body for maintaining and documenting a package or a generic template and archetype becomes the HL7 TC, HL7 will arrange to include the templates and archetypes and the related supporting material into an adequate repository.
What is the intended purpose of a template and archetype?
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 and archetypes include, but are not limited to:
• Human-to-Human Communication - templates and archetypes 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 and archetypes can be used to validate message content according to the template and archetype rules. "Verify that this message is a valid instance of a CBC template and archetype (according to my definition...)"
• Construction - templates and archetypes can be used to guide and direct information input. A template and archetype 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 and archetypes are object oriented and can be constructed with strict inheritance of constraint models.
• Predication - templates and archetypes can be used to determine whether a message meets a specific 'predicate'. As an example, templates and archetypes 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 and archetypes 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 and archetypes 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 and archetypes differ from related HL7 artifacts?
HL7 V3 Templates and archetypes 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 template and archetype or a conformance profile.
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 and archetypes do not constrain by creating new clones, and therefore do not result in new XML element names.
Both conformance profiles and templates and archetypes express constraints against normative specifications. HL7 instances are valid against both the normative specification AND against the additional constraints expressed in the template and archetype 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 and archetypes 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 and archetypes need not constrain an entire specification; templates and archetypes can contain other templates and archetypes (for instance, a history-and-physical template and archetype can contain a cardiac-exam template and archetype which can contain a vital-signs template and archetype); and templates and archetypes are reusable (for instance, a vital-signs template and archetype 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 and archetypes 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 template and archetype. It can be the case that a user needs to create both a conformance profile and one or more templates and archetypes to achieve the desired degree of constraint.
[pic]
Figure 1: UML diagram of where Templates and Archetypes fit in the HL7 dependency hierarchy.
SCOPE OF HL7 V3 TEMPLATES AND ARCHETYPES
Guiding principles
There is a need to define a scope for HL7 V3 Templates and archetypes that may not meet all theoretical requirements, but can yield a practical standard in a reasonable amount of time. It is anticipated that subsequent versions of the HL7 V3 Template and Archetype standard will add incremental functionality.
The scope of the first release of the HL7 V3 Template and Archetype standard is a based on the following guiding principles:
• Standardize what is currently being done internationally with templates and archetypes, rather than to attempting to introduce new functionality.
• Enable the expression of at least 85% of real-world use cases.
• Minimize the technical implementation barriers so that this standard can be widely deployed.
• Take advantage of existing HL7 tools where possible.
• Be consistent with GEHR, CEN, DICOM and other standards that have defined templates and archetypes so that the interchange of tools, templates and archetypes can be performed.
• Draw a reproducible boundary for the initial standard that makes it easy for readers to understand what is and is not in scope.
• Offer a migration pathway to more complex constraints.
In scope
Operationally, the guiding principles serve to limit the expressivity of HL7 V3 Templates and archetypes, 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.
Out of scope
The following components are not a normative part of this standard:
• HL7 V3 Template and Archetype analysis-level authoring tools;
• This standard does not actually build the complete set of templates and archetypes, but instead specifies a normative template and archetype representation.
• A template and archetype is a static data structure that can express assertion-based inter-data field/value dependencies, but contains no inherent behavior. This distinction can be subtle at times, but for instance, a template and archetype might say that if the value of fieldOne is “X”, then the value of fieldTwo must be “Y”. A template and archetype 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 and archetypes, but is not part of the template and archetype standard.
• A definitive mechanism for comparing overlapping templates and archetypes and converging them on a single best template and archetype. This standard places no restrictions on who can create and register a conformant HL7 V3 Template and archetype. However it is recognized that such convergence is of considerable clinical utility, and it is hoped that such efforts will be encouraged.
3. HL7 Definition of Terms
Archetype: A syntactically and semantically structured aggregation of vocabulary or other data that is the basic unit of clinical information
Template: A structured aggregation of one or more archetypes, 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.
4. ARCHITECTURAL OVERVIEW: RELATIONSHIP OF TECHNICAL FORMALISMS AND THE RIM
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,
• OCL provides a shared constraint language for HL7 artifacts
• ADL provides a compact syntactic representation of clinical information
• OWL provides a semantically rich representation of clinical information
• SR-XML provides a shared graphical representation of clinical information, for clinical domain experts, informaticists, and programmers.
[pic]
5. TEMPLATES AS GENERAL CONSTRAINTS ON HL7 ARTIFACTS
1. Template Functional Requirements
Template and archetype requirements
This section defines requirements for the normative representation of an HL7 V3 Template and archetype.
Template and archetype design
While any number of tools can create a normative HL7 V3 Template and archetype, there are requirements that all of them must adhere to.
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.
Any tool that creates an HL7 V3 Template and archetype will collect appropriate metadata about that template and archetype, including the fragment that was constrained.
Constraining a fragment 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 archetypes is to specify constraints on nested sections.
Template and archetype assertions
This section defines the types of constraints or assertions that can be expressed.
Static assertions
A template and constituent archetypes can constrain the cardinality of a clone’s association.
A template and constituent archetypes can constrain the cardinality of a clone’s attribute.
A template and constituent archetypes can constrain the allowable date/time values in a date/time field.
A template and constituent archetypes can constrain any attribute value to be a subset of those values legally permissible in the specification being constrained.
A template or constituent archetypes can constrain the range of allowable date/time values for attributes valued by date/time data types.
A template or constituent archetypes can constrain the range of allowable code values for attributes valued by terminology concepts.
A template or constituent archetypes can constrain the range of allowable numbers for attributes valued[?] by numbers.
A template or constituent archetypes can express a regular expression constraint[?] on attributes valued by strings.
A template or constituent archetypes can constrain any data type component, including recursively-nested components.
A template or constituent archetypes 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 archetype.
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 archetypes 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 archetypes 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 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)).
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 archetypes can be “ordered” or “unordered”. In an ordered template and archetype, the order of the stated assertions is important. In an unordered template and archetype, 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 archetypes are “ordered”, the “hemoglobin” must come before the “hematocrit”. If the template and constituent archetypes is “unordered” the “hemoglobin” can come before or after the “hematocrit”.
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).
Normative template and archetype representation
This section describes the normative representation of a conformant HL7 V3 Template and archetype.
((NOTE: I know this is what everyone is asking for, but be patient… We need to discuss the above requirements and discuss the various representation proposals that have come forward. As tempting as it is, we’re not quite ready to address this piece yet.))
Template and archetype declaration
This section specifies how an HL7 V3 instance declares the use of a template and archetype.
Guiding assertions to be used in crafting the solution include:
1. The mechanism for identifying templates and archetypes must be ITS agnostic. (It is quite possible that a piece of data will be translated across multiple ITSs before it arrives at its 'final' destination. If we make identifying templates and archetypes ITS-specific, it's going to make translation a real pain.
2. The mechanism should support templates and archetypes that are routed in Act, Entity or Role (and maybe Participation).
3. We should be informed by the way HL7 identifies what 'message' is being sent, namely through an attribute in the Communication wrapper). However, the 'USAM' or 'Backbone' classes are intended to carry clinical and administrative data, not metadata.
Based on these assertions, the current proposal is to create a new 'blue' class on the bottom half of the RIM, which is related to Act, Entity, Role, and perhaps Participation. This class would have an implicit link, meaning that committees don't need to diagram it. Instead, it will just automatically be added as an optional link in each ITS. This will allow us to identify templates and archetypes wherever we need them. Furthermore, different ITS's may choose to communicate this 'blue' class in different ways, opening the door to supporting XML 'standard' ways of identifying templates and archetypes if such a thing ever appears.
Template and archetype registration
This section defines template and archetype registry/repository requirements.
Template and archetype repository
This section defines requirements for a repository of HL7 V3 Templates and archetypes.
HL7 will create a common set of metadata that is used to catalog both templates and archetypes 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 template and archetype.
The hierarchical relationship between two templates and archetypes can be expressed. Thus, if there are a series of, say, echocardiography templates and archetypes, each applying tighter and tighter constraints, this hierarchy can be represented in the repository.
Template and archetype metadata
This section defines requirements for metadata used to catalog HL7 V3 Templates and archetypes.
NOTE: Each template and archetype 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 template and archetype, nor is there any guarantee of uniqueness in any other metadata field or combination of fields.
((NOTE: The following table was crafted by John Silva (except for “fragment id” and “core code”), and represents a mapping of various metadata strategies (encompassing ebXML, Dublin Core, and others). The intent is for both Templates and archetypes and Conformance committees to converge on the same set of values.
The ballot version of this table will contain only the first three columns, appropriately revised and harmonized with Conformance TC))
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).
CDA Level 2 Model
[pic]
OWL Representation of the CDA Level 2 Model
1
1
1
1
1
1
1
0
1
1
1
1
1
1
0
1
1
0
0
1
0
0
1
1
0
1
1
0
1
0
0
0
0
1
1
0
1
0
0
0
1
1
1
1
Archetype Constraint Model
[pic][pic]
Adverse Reaction Archetype
archetype
openEHR-EHR-EVALUATION.adverse_reaction.v1
concept
[at0000] -- Adverse reaction
description
author =
status =
version =
revision =
submission = <
organisation =
date =
>
adl_version =
description("en") = <
purpose =
use =
misuse =
>
description("tr") = <
purpose =
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 {|
items("at0001") = <
text =
description =
>
items("at0002") = <
text =
description =
>
items("at0003") = <
text =
description =
>
items("at0004") = <
text =
description =
>
items("at0005") = <
text =
description =
>
items("at0006") = <
text =
description =
>
items("at0007") = <
text =
description =
>
>
constraint_definitions("en") = <
items("ac0001") = <
text =
description =
>
>
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
[pic]
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 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=)
Namespace(xsd=)
Namespace(rdfs =)
Namespace(rdfs =)
Namespace(ba =)
Namespace(rm =)
Namespace(this =)
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
(
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
(
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
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))
)
)
)
)
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)
)
)
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
(
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
(
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
)
)
)
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
allValuesFrom(this:at0022)
)
)
)
Adverse Event Archetype linked to the CDA Level 2 Model OWL:rdf
]>
OWL ontology
7. Overview
8 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 Goals of OWL
Subsumptive reasoning that can support closed and open world assumptions.
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.
FIGURE 1 OM+ADL/OWL interoperability architecture
8 Object Model / OWL Mapping
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))
18 ADL / OWL Mapping
1. Example
[pic]
}
-------- “substituted archetype” : sub terms, choose lang, terminology-----to be determined
-------- OWL DL ------
// Assume the following:
// Begin Archetype
[pic]
[pic]
[pic]
8 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 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 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
But the archetype says:
TREE[at0001]
items
ELEMENT[at0002]
ELEMENT[at0003]
CLUSTER[at0004]
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 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
• 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 Archetype Ontology Mapping
....
Archetypes for the Semantic Web: the ADL / OWL Mapping Comparative Semantics of OWL and ADL Rev 0.5
8 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.
Table 1.Conformance Profiles, Templates and archetypes and ebXML strawman mappings
|Metadata |Template and |Description |Conformance |Description |ebXML |
|Element Type |archetype | |Element | | |
| |Element | | | | |
| |fragment id (1) |Identifies the fragment that | | | |
| | |was constrained to create this | | | |
| | |template and archetype. [?] | | | |
| | | | | | |
| | |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. | | | |
| |core code (?) |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. | | | |
| |title (+) |The name given to the resource.|SpecName |Provides a name that|RegistryObject.name |
| | | | |clearly and |(InternationalString) |
| | | | |concisely defines | |
| | | | |the exchange | |
| |description (?) |A textual description of the |Comment | |RegistryObject.description|
| | |content of the resource | | |(InternationalString) |
| |format (1) |The data format of the template| ? |Always XML |Repository.objectType |
| | |and archetype before it is | | |(ebXML has a predefined |
| | |transformed into the HL7 | | |set that can be extended, |
| | |template and archetype | | |e.g. UMLModel, XMLSchema, |
| | |formalism. | | |ExternalLink) |
|Organization |submitting_entity |The entity submitting and/or |OrgName |Submitter |Organization (class) |
| |(1) |maintaining the resource in the| |organization | |
| | |HL7 repository. | | | |
| |package_documentatio|the URL to download the | | | |
| |n_URL |supporting documentation about | | | |
| | |the package of templates and | | | |
| | |archetypes | | | |
| |template and |the URL to download the | | | |
| |archetype_documentat|specific supporting | | | |
| |ion_URL |documentation about the | | | |
| | |template and archetype | | | |
| |creator (+) |The person or organization |? | |Organization (class) |
| | |primarily responsible for | | | |
| | |creating the intellectual | | | |
| | |content of the resource. | | | |
| |technical_contact |The person or department to be |Submitter |Submitter’s name |User.personName |
| |(*) |contacted for technical issues |(First Name, | |(PersonName) |
| | |related to the resource. |Last Name) | | |
| |? | |Email |Submitter’s email |User.emalAddresses |
| | | | | |(Collection of |
| | | | | |EmailAddress) |
| |? | |Phone |Submitter’s phone |User.telephoneNumbers |
| | | | | |(Collection of |
| | | | | |TelephoneNumber) |
| |? | |Fax |Submitter’s Fax |User.telephoneNumbers |
| | | | |number | |
| |? | |For More |URI to provide more |? ExternalLink (class) |
| | | |Information |information on | |
| | | | |profile (proposed) | |
| |content_contact (*) |The person or department to be |? |same as Submitter? |User.personName |
| | |contacted for content issues | | |(PersonName) |
| | |related to the resource. | | | |
| |approving_body (+) |Organization that has reviewed |HL7 Affiliate | |Organization (class) |
| | |the resource, and agrees that |( maybe ) | | |
| | |it is suitable for clinical | | | |
| | |use. (Note – resources can be | | | |
| | |approved by organizations other| | | |
| | |than the one the author is | | | |
| | |affiliated with.) | | | |
|Life cycle |date.first_in_effect|The date this resource was |Date |First submittal date|RegistryObject.AuditableEv|
| |(1) |first available for production | | |ent.timestamp (with |
| | |use in HL7. | | |eventType = Created) |
| |date.available (1) |The date this resource was |? | |RegistryObject.AuditableEv|
| | |first available on HL7. | | |ent.timestamp (with |
| | |(Enables the automatic | | |eventType = Created ?) |
| | |generation of a "what's new" | | | |
| | |list.) | | | |
| |date.revised (*) |The dates this resource has |? | |RegistryObject.AuditableEv|
| | |been reviewed or revised. | | |ent.timestamp (with |
| | | | | |eventType = Updated) |
| |date.will_expire (?)|The date the intellectual |? | |RegistryObject.AuditableEv|
| | |content of this resource will | | |ent.timestamp (with |
| | |expire. | | |eventType = Deprecated) |
| | | | | |RegistryEntry.expiration |
| |modification_history|A list of changes from the |? (could be in | |RegistryObject.AuditableEv|
| |?) |previous version. |Comments) | |ents (but it doesn’t seems|
| | | | | |to have way to store text)|
| | | | | |Can use Slot named ‘Change|
| | | | | |Log’ |
| |publication_state |This field tracks the |? | |RegistryObject.RegistryEnt|
| |(1) |completion state (e.g. draft, | | |ry.status (ebXML has |
| | |final) of the resource. The | | |Submitted, Approved, |
| | |value is user assigned, and | | |Deprecated, and Withdrawn |
| | |indicates the status of the | | |– how to represent |
| | |resource to the | | |Normative/Informative? |
| | |submitting_entity. | | |Can use Slot name ‘HL7 |
| | | | | |Status’ |
| | |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. | | | |
| |resource_state (1) |This field tracks the status of|? |Conformance has |RegistryObject.RegistryEnt|
| | |resources in the registry. | |notion of active vs.|ry.status |
| | |Values are assigned by HL7, and| |archived profiles | |
| | |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. | | | |
| |version.resource (1)|Templates and archetypes get a |AssociatedProfiles|Done by association |RegistryObject.RegistryEnt|
| | |new version number when | | |ry.majorVersion and |
| | |revised. | | |minorVersion |
| |version.metadata (1)|The version of metadata used to|? | |Does this mean a change to|
| | |catalog this resource. | | |the repository’s ‘schema’ |
| | | | | |? |
|Association |family_identifier |Every resource has a globally |AssociatedProfiles| |RegistryObject.RegistryEnt|
| |(1) |unique identifier that remains | | |ry.majorVersion and |
| | |constant across revisions. | | |minorVersion +1 |
| | | | | | |
| | |When a resource is revised | | |Association.associationTyp|
| | |The new resource gets a new | | |e = Replaces |
| | |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”. | | | |
| |relation (*) |Represents the relationship |AssociatedProfiles| |Association.associationTyp|
| | |between the current resource | | |e = |
| | |and the target resource. | | |{ebXML defines RelatedTo, |
| | | | | |HasMember, |
| | | | | |ExternallyLinks, Contains,|
| | | | | |EquivalentTo, Extends, |
| | | | | |Implements, InstanceOf, |
| | | | | |Supercedes, Uses, |
| | | | | |Replaces, SubmitterOf, |
| | | | | |ResponsibleFor, |
| | | | | |OffersService) |
| |relation.references |The target of the references |AssociatedProfiles| |Association.targetObject |
| |(*) |relation is a source of | | |(UUID) |
| | |knowledge drawn upon in the | | | |
| | |creation of this resource. | | | |
|Keywords/ |clinical_category |The practice setting or |? |Done through the |Classification (can |
|Taxonomy |(?) |organizational unit/specialty | |message type which |reference external |
| | |to which this resource is | |implicitly implies |classification scheme) |
| | |applicable. | |clinical area? | |
| |intended_use (?) |Identifies the HL7 |? | |Classification (reference |
| | |specification(s) that this | | |appropriate HL7 stadard |
| | |template and archetype is | | |OID as external ref.) |
| | |applicable to. | | | |
| |language (1) |The language of the |? | |Classification (reference |
| | |intellectual content of the | | |appropriate external ISO |
| | |resource. | | |language standard) |
| |subject.keyword (*) |The topic(s) of the resource. |Keywords | |Classification or Slot ? |
| | | | | |(who comes up with keyword|
| | | | | |or taxonomy list?) |
| |attribute_list (*) |The list of Entities contained | HL7 Version, |The list of fields |Items represented in ebXML|
| | |within the Template and |Message Type, |populated based on |Slots ? |
| | |archetype |Message Structure |the contents of the |[These can also be |
| | | |Type, Trigger, Z |profile [XML] |represented as |
| | | |Trigger, Order |document. |Classification nodes. |
| | | |Control Code, | |With ebXML V3.0 Content |
| | | |Profile Level | |Based Queries, these |
| | | | | |values could be |
| | | | | |auto-populated!] |
Appendices
69. 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
69.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.
69.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. 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.
69.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.
69.2 Introduction
69.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 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.
69.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
69.3 Relation to the UML Metamodel
69.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..*
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
69.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.
69.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
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
69.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 = ...
69.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 ...
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.
69.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.
69.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()
69.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.
69.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
69.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.
69.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 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
69.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
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 7-11).
69.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.
69.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.
69.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:
69.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:
this is a comment
69.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
69.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
69.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.
69.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.
69.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
69.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()
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.
69.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.
69.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.
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
79.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() 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]
69.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 (->).
69.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 role-name. 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]
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.
69.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
69.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
69.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.
69.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:
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.
69.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 }
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 Int-expr2, 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)
69.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 }
69.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)
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.
69.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:
a.b@pre.c—takes the old value of property b of a, say x -- and then the new value of c of x. a.b@pre.c@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.
69.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.
69.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:
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 | boolean-expression-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 | boolean-expression-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) )
69.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 | expression-with-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()
69.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)
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, ...)
69.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 boolean-expression-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)))
69.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:
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 boolean-expressionwith-v is true for at least one element of collection. If the boolean-expression-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.’
69.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-with-elem-and-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 . When the iterate is evaluated, elem iterates over the collection and the expression-withelem-and-acc is evaluated for each elem. After each evaluation of expression-withelem-and-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 =
}
}
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.
69.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 )
69.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) )
69.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.
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.
69.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.
69.8.1 Basic Types
The basic types used are Integer, Real, String, and Boolean. They are supplemented with OclExpression, OclType, and OclAny.
69.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.
69.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 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)
69.8.1.3
69.8.1.4
69.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.
69.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.
69.8.1.7 Real
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)
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 : Real) : Boolean
True if r1 is greater than r2.
post: result = not (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
69.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 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?
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)
69.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(‘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.
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)
69.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)
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 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)
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))
69.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
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 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 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 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)
69.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 ).
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 )
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 )*
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 := “=” | “>” | “=” | “ 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 ( B, if A is |A ( B |
| | |true, then B is true. | |
|( |Logical disjunction - OR |Or |A ( B |
|( |Logical conjunction - AND |And |A ( B |
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 some.archetype.id
concept some_term
[ specialise some.other.archetype.id ]
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 [term]
name ( {term/text constraint}
ref_model_attribute ( { constraint }
ref_model_relationship existence ( {1..1} ( {
REF_MODEL_ENTITY node ocurrences ( {1..1} ( {
...etc
}
}
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 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.
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:prenatal.v1
nictiz.hl7:rim:act.progress_note.v1
uk-nhs.openehr:ehr_rm:entry.progress_note:naturopathy.v2
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.
[pic]
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.
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 “*.iso-ehr.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 mayo.iso-ehr.entry.haematology:cbc.v1
concept [AT0004] -- complete blood count
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.
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 “micro-terminologies”, 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
}
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 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 (battery items)]
name ( {“CBC”}
items existence ( {1..1; ordered} ( {
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 ).
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.
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.
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 |HL7 CDA |CEN 13606 |CEN 13606 revision |
|Transaction |Document |Composition |Composition |
|Organiser |Section |Headed Section |Section |
|History | | | |
|List_s – a path-enabled linear|List – key word in XML | | |
|structure (not the generic | | | |
|language feature List). | | | |
|Element |Item |Data item |Element |
|Compound |?? |Cluster |Cluster |
|Entry |Entry | |Entry |
Blood Pressure
archetype racgp.openehr.entry.blood_pressue.v1
concept [AT0000] -- blood pressure measurement
ENTRY node ( {
meaning [AT0001] -- blood pressure
name ( {AC0001} -- synonym of blood pressure
data existence ( {1} ( { -- C_SINGLE_REL
LIST_S node ( {
items existence ( {1..1; ordered} ( { -- C_LIST
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 new item
name ( {any} -- anything??
value ( {any}
}
}
}
}
protocol existence ( {0..1} ( { -- C_SINGLE_REL
LIST_S node ( {
items existence ( {1..1; ordered} ( { -- C_LIST
ELEMENT node ocurrences ( {0..1} ( {
meaning [AT0005] -- instrument
name ( {AC0005} -- any synonym of ‘instrument’
value ( { type ( {CODED_TEXT}; value ( {AC0006} }
}
ELEMENT node ocurrences ( {0..1} ( {
meaning [AT0007] -- position
name ( {AC0007} -- any synonym of patient position
value ( { type ( {CODED_TEXT}; value ( {AC0008} }
}
ELEMENT node ocurrences ( {0..1} ( {
meaning [AT0009] -- cuff size
name ( {AC0009} -- size of cuff
value ( { type ( {CODED_TEXT}; value ( {AC0010} }
}
ELEMENT node ocurrences ( {0..*} ( {
meaning [unknown] -- unknown new item
name ( { any } -- any
value ( {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 arterial pressure
AT0001 = {163020007} -- O/E Blood pressure reading
AT0002 = {163030003} -- O/E - Systolic BP reading
AT0003 = {163031004} -- O/E - Diastolic BP reading
AT0005 = {57134006} -- instrument
AT0007 = {246273001} -- patient position
AT0009 = {246153002} -- type of cuff
}
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]} -- instrument
AC0007 = { synonym of [246273001]} -- synonyms of position
AC0008 = { has_relation [102002] -- is-a
with_target [246273001]} -- patient position
AC0009 = { synonym of [246153002]} -- synonyms of cuff size
AC0010 = { has_relation [102002] -- is-a
with_target [246153002]} -- cuff size
}
problem/SOAP Headings
archetype ihc.iso-ehr.section.soap_headings.v1
concept [AT0000] -- problem/SOAP headings
ORGANISER node ( {
meaning [AT0001] -- problem
name ( {AC0001}
items existence ( {1..1; ordered} ( { -- C_LIST
ORGANISER node ocurrences ( {0..1} ( { -- can only be 0..1 or 1..1
meaning [AT0002] -- subjective
name ( {AC0002}
items existence ( {0..1; ordered} ( { -- C_LIST
ENTRY archetype ocurrences ( {0..*} ( {id ( {“*.iso-ehr.entry.*.*”}}
ORGANISER node ocurrences ( {0..*} ( {
meaning [unknown] – any term ok
name ( {any}
}
ORGANISER archetype ocurrences ( {0..*} ( {id ( {“*.iso-aniser.*.*”)}} -- any organiser
}
}
ORGANISER node ocurrences ( {0..1} ( {
meaning [AT0003] -- objective
name ( {AC0003}
items existence ( {0..1; ordered} ( { -- C_LIST
ENTRY archetype ocurrences ( {0..*} ( {id ( {“*.iso-ehr.entry.*.*”}}
ORGANISER node ocurrences ( {0..*} ( {
meaning [unknown]
name ( {any}
}
ORGANISER archetype ocurrences ( {0..*} ( {id ( {“*.iso-ehr.section.*.*”}}
}
}
ORGANISER node ocurrences ( {0..1} ( {
meaning [AT0004] -- assessment
name ( {AC0004}
items existence ( {0..1; ordered} ( { -- C_LIST
ENTRY archetype ocurrences ( {0..*} ( {id ( {“*.iso-ehr.entry.*.*”}}
ORGANISER node ocurrences ( {0..*} ( {
meaning [unknown]
name ( {any}
}
ORGANISER archetype ocurrences ( {0..*} ( {id ( {“*.iso-ehr.section.*.*”}}
}
}
ORGANISER node ocurrences ( {0..1} ( {
meaning [AT0005] -- plan
name ( {AC0005}
items existence ( {0..1; ordered} ( { -- C_LIST
ENTRY archetype ocurrences ( {0..*} ( {id ( {“*.iso-ehr.entry.*.*”}}
ORGANISER node ocurrences ( {0..*} ( {
meaning [unknown]
name ( {any}
}
ORGANISER archetype ocurrences ( {0..*} ( {id ( {“*.iso-ehr.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 »;
description = “The clinician’s professional assessment of the problem”}
AT0005 = { text = « plan »;
description = “The clinician’s professional advice”}
}
term_definitions(de; translation = “mdarlison@chime.ucl.ac.uk”) = {
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”}
}
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
}
Haematology result
archetype mayo. iso-ehr.entry.haematology.v1
concept [AT0000] -- haematology
ENTRY node ( {
meaning [AT0001] -- battery
name ( {AC0001} -- Name of battery
data existence ( {1} ( { -- C_SINGLE_REL
LIST_S node ( {
items existence ( {1..1; ordered} ( { -- C_LIST
ELEMENT node ocurrences ( {1..1} ( {
meaning [AT0002] -- haematology test item
name ( {AC0002} -- name of test item
value ( {any} -- any data type
}
}
}
}
}
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 = “p_ameline@nautilus.fr”) = {
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”}
}
term_binding(UMLS) = {
AT0000 = {SOME_CODE}
AT0001 = {SOME_CODE}
AT0002 = {SOME_CODE}
}
constraint_definition(en) = {
AC0001 = { text = « haematology test name »;
description = “the name of the battery”}
AC0002 = { text = « haematology test item name »;
description = “the name of the battery item”}
}
Complete Blood Count (CBC)
archetype mayo. iso-ehr.entry.haematology.cbc.v1
concept [AT0003] -- haematology - complete blood count
specialise mayo. iso-ehr.entry.haematology.v1
ENTRY node ( {
meaning [AT0001] -- battery items
name ( {AC0001} -- CBC
data existence ( {1} ( { -- C_SINGLE_REL
LIST_S node ( {
items existence ( {1..1; ordered} ( { -- C_LIST
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}}
}
}
}
}
}
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 = “p_ameline@nautilus.fr”) = {
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 »;
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 (Blood) automated
[4545-0] -- Hematocrit (Blood) spun
}
AC0004 = {[778-1], -- Platelet count (Blood) manual
[777-3] -- Platelet count (Blood) automated
}
}
APGAR
archetype nictiz.iso-ehr.entry.apgar.v1
concept [AT0001] -- apgar test result
ENTRY node ( {
subject_relationship ( {AC0001}
data existence ( {1} ( { -- C_SINGLE_REL
HISTORY node ocurrences ( {1} ( {
periodic ( {False}
events existence ( {1..1; ordered} ( { -- C_LIST
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
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 +
([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}
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 = {?????}
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.iso-ehr.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.iso-ehr.entry.cbc.v1
WHERE battery/haemaglobin.value.units = “g/l”
Element features are accessed by dot notation.
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 ) .
Generic Syntax
######## overall structure ########
archetype: heading_part
body_part
terminology_part
heading_part: “archetype” archetype_id
”meaning” c_text
”type” rm_type_name
[ “parent version” archetype_id ]
[ “specializes” archetype_id ]
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 -- plug in area
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 ]
”}”
c_meaning_expr: “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_existence: “{“ c_cardinality [ “;” “ordered”] [“;” “unique”] “}”
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_occurrences_expr MATCH_SYM c_transaction_node |
“ORGANISER” c_occurrences_expr MATCH_SYM c_organiser_node |
“ENTRY” c_occurrences_expr MATCH_SYM c_entry_node |
c_structure_node_expr
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 .
Beale T. Archetypes: Constraint-based Domain Models for Future-proof Information Systems. 2000. .
Dolin R, Elkin P, Mead C et al. HL7 Templates Proposal. 2002. Available at .
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 .
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 .
Galen. See
GLIF (Guideline Interchange Format). .
ProForma language for decision support. .
Prodigy. SCHIN, Newcastle. See .
Solbrig H, Markwell D et al. HL7 Common Terminology Service (CTS). Available at .
710.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 Reporting-Extended 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) |Meaning |
|( |Sequence of ordered elements |
|* |0 or more |
|+ |1 or more |
|? |0 or 1 (optional) |
|#PCDATA |Character data |
|= |Same as |
|… |Continued on additional templates |
SR XML TEMPLATE 1: CLINICAL INFORMATION
[pic]
LEGEND
HPI History of Present Illness
ROS Review of Systems
PMHx Past Medical History
Hx History
SR XML TEMPLATE 2: DEMOGRAPHICS
[pic]
SR XML TEMPLATE 3: CLINICAL INDICATION
[pic]
SR XML TEMPLATE 4: INTERVENTIONAL (OR IMAGING) REPORT
[pic]
SR XML TEMPLATE 5: COMPARISON
[pic]
SR XML TEMPLATE 6: TECHNICAL METHODS
[pic]
SR XML TEMPLATE 7: QUANTITATIVE ANALYSIS
[pic]
SR XML TEMPLATE 8: QUALITATIVE ANALYSIS
[pic]
SR XML IMAGING/INTERVENTIONAL TEMPLATE 9: ASSESSMENT
[pic]
SR XML IMAGING/INTERVENTIONAL TEMPLATE 10: PLAN
[pic]
811. TEMPLATE CONSTRAINTS ON CLINICAL DATA: SEMANTICS
811.1 OWL Formalism
8.11 Author: Peter Elkin, MD
811.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.[?] 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 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.
::= Class( {} {} )
::= 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.
::= EnumeratedClass( {} {} )
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.
::= DisjointClasses( {} )
::= EquivalentClasses( {} )
::= SubClassOf( )
811.3.2.2. OWL Descriptions
::= Class( {} {} )
::= complete | partial
::= |
In OWL Lite it is possible to state that two classes are the same.
::= EquivalentClasses( {} )
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.
::=
|
| unionOf( {} )
| intersectionOf( {} )
| complementOf( )
| oneOf({} )
811.3.2.3. OWL Restrictions
::= restriction( {allValuesFrom()}
{someValuesFrom()} [] )
::= restriction( {allValuesFrom()}
{someValuesFrom()} [] )
::= 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( {allValuesFrom()}
{someValuesFrom()} {value()}
{} )
::= restriction( {allValuesFrom()}
{someValuesFrom()} {value()}
{} )
::= minCardinality( )
| maxCardinality()
| cardinality()
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.
::=
::= oneOf({} )
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.
811.3.2.4. OWL Property Axioms
::= DatatypeProperty ( {} {super()}
{domain()} {range()}
[Functional] )
::= ObjectProperty ( {} {super()}
{domain()} {range()}
[inverseOf()] [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.
::= EquivalentProperties( {} )
::= SubPropertyOf( )
::= EquivalentProperties( {} )
::= SubPropertyOf( )
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.
::= DatatypeProperty ( {} {super()}
{domain()} {range()}
[Functional] )
::= ObjectProperty
( {} {super()}
{domain()} {range()}
[inverseOf()] [Symmetric]
[Functional | InverseFunctional | Functional InverseFunctional | Transitive] )
811.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:
OWL RDF Syntax for CBC Lab Test. Based on example By Dr. Peter ELkin
$Header:$
1
0
1
1
1
LOINC
0
0
0
123-456
456-789
123-789
987-654
654-321
811.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.
Serialized constraints expressed below as OWL Axioms:
• ::= Class(ex:R-MIM Individual (ex:ID "12345"))
Defines the entire Restricted MessageInformation Model
• ::= 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)
• ::= SubClassOf(sub=ex:R-MIM_Fragment super=ex:R-MIM)
Specifies that the R-MIM fragment is a subclass of the entire R-MIM
• ::= 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)
• ::= 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)
• ::= ObjectProperty(ex:typeCode (Individual(ex:codeValue) ) )
• ::= ObjectProperty(ex:class_cd (Individual(ex:codeValue) ) )
• ::= ObjectProperty(ex:moodCode (Individual(ex:codeValue) ) )
Defines the Object Properties used in the above Class definitions
• ::= DatatypeProperty(ex:codeValue xsd:integer)
Defines the Data Type Properties for the Object Properties
CBC is a Subclass of Labtest:
CBC Template and archetype Validation Continued from the previous page:
811.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 , 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 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 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.
Graphic Describing the abstract workflow of template and archetype registry
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.
[pic]
ebXML Representation of the History Of present Illness section of the HL7-CDA Document.
[pic]
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 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.
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.
912. 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?
103. APPENDICESWeb Ontology Language (OWL) Specification
103.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 =
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.
EC is extended to the syntactic constructs of s, s, s, and 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 | (ER(p) → y (EC(r)} |
|restriction(p someValuesFrom(e)) |{x (R | ( (ER(p) → y (EC(e)} |
|restriction(p value(i)) |{x (R | (ER(p)} |
|restriction(p value(d,l)) |{x (R | (ER(p)} |
|restriction(p minCardinality(n)) |{x (R | card({y : (ER(p)}) ≤ n} |
|restriction(p maxCardinality(n)) |{x (R | card({y : (ER(p)}) ≥ n} |
|restriction(p cardinality(n)) |{x (R | card({y : (ER(p)}) = n} |
|Individual(annotation(…) … annotation(…) type(c1) … type(cm) |EC(c1) ∩ … ∩ EC(cm) ∩ EC(pv(pv1)) ∩…∩ EC(pv(pvn)) |
|pv1 … pvn) | |
|Individual(i annotation(…) … annotation(…) type(c1) … type(cm)|{S(i)} ∩ EC(c) ∩ … ∩ EC(cm) ∩ EC(pv(pv1)) ∩…∩ |
|pv1 … pvn) |EC(pv(pvn)) |
|pv(p Individual(…)) |{x (R | (y(EC(Individual(…)) : (ER(p)} |
|pv(p id), for id an individualID |{x (R | (ER(p) } |
|pv(p d,l) |{x (R | (ER(p) } |
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(…) … annotation(…) super(s1) … super(sn)|ER(p) (ER(s1) ∩…∩ ER(sn) ∩ |
| | EC(d1)×LV ∩…∩ EC(dn)×LV ∩ R×EC(r1) ∩…∩ |
| domain(d1) … domain(dn) range(r1) … range(rn) |R×EC(rn) |
| [Functional]) |[ER(p) is functional] |
|IndividualProperty(p annotation(…) … annotation(…) |ER(p) (ER(s1) ∩…∩ ER(sn) ∩ |
| super(s1) … super(sn) | EC(d1)×R ∩…∩ EC(dn)×R ∩ R×EC(r1) ∩…∩ |
| domain(d1) … domain(dn) range(r1) … range(rn) |R×EC(rn) |
| [inverse(i)] [Symmetric] |[ER(p) is the inverse of ER(i)] [ER(p) is symmetric]|
| [Functional] [InverseFunctional] | |
| [Transitive]) |[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(…) |EC(Individual([i] type(c1) … type(cm) pv1 … pvn)) is|
| type(c1) … type(cm) pv1 … pvn) |nonempty |
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 | ∈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:
Relationships between OWL classes
|If E is |then CEXTI(SI(E))= |with |
|owl:Thing |IOT |IOT(renal insufficiency |
|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 |IL(RI |
Membership in OWL classes
|If E is |then SI(E)( |
|owl:Thing |IOC |
|owl:Nothing |IOC |
|rdfs:Literal |IDC |
|a datatype of D |IDC |
|rdf:nil |IL |
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 | (EXTI(c) → (EXTI(c) |
|owl:FunctionalProperty | and (EXTI(c) → y1 = y2 |
|owl:InverseFunctionalProperty |(EXTI(c) ((EXTI(c) → x1 = x2 |
|owl:TransitiveProperty |∈EXTI(c) ((EXTI(c) → (EXTI(c) |
RDFS domains and ranges are strengthened to if-and-only-if over the OWL universe.
|If E is |then for |∈CEXTI(SI(E)) iff |
|rdfs:domain |x(IOP,y(IOC |(EXTI(x) → z(CEXTI(y) |
|rdfs:range |x(IOP,y(IOCÎIDC |(EXTI(x) → z(CEXTI(y) |
Some OWL properties have iff characterizations
|If E is |then (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) |
|owl:inverseOf |x,y(IOOP ^(EXTI(x) iff (EXTI(y) |
|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
(EXTI(SI(rdf:first)), y1(CEXTI(C), (EXTI(SI(rdf:rest)), …,
(EXTI(SI(rdf:first)), yn(CEXTI(C), and (EXTI(SI(rdf:rest)).
|If E is |then if ∈EXTI(SI(E)) then |
|owl:complementOf |x,y(IOC and CEXTI(x)=IOT-CEXTI(y) |
|If E is |then if ∈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 (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 |then x(IOR, y(IOC, p(IOP, and CEXTI(x) = |
|(EXTI(SI(owl:allValuesFrom))) ^ |{u(IOT | (EXTI(p) → v(CEXTI(y) } |
|(EXTI(SI(owl:onProperty))) | |
|(EXTI(SI(owl:someValuesFrom))) ^ |{u(IOT | ( (EXTI(p) ^v(CEXTI(y) } |
|(EXTI(SI(owl:onProperty))) | |
|(EXTI(SI(owl:hasValue))) ^ |{u(IOT | (EXTI(p) } |
|(EXTI(SI(owl:onProperty))) | |
|If |then x(IOR, y(LV, y is a non-negative integer, p(IOP, |
| |and CEXTI(x) = |
|(EXTI(SI(owl:minCardinality))) ^ |{u(IOT | card({v : (EXTI(p)}) ≥ y } |
|(EXTI(SI(owl:onProperty))) | |
|(EXTI(SI(owl:maxCardinality))) ∧ |{u(IOT | card({v : (EXTI(p)}) ≤ y } |
|(EXTI(SI(owl:onProperty))) | |
|(EXTI(SI(owl:cardinality))) ∧ |{u(IOT | card({v : (EXTI(p)}) = y } |
|(EXTI(SI(owl:onProperty))) | |
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.
|If there exists |then there exists l1,…,ln ∈ IL with |
|x1, …, xn (IOC | (EXTI(SI(rdf:first)), (EXTI(SI(rdf:rest)), … |
| | (EXTI(SI(rdf:first)), (EXTI(SI(rdf:rest)) |
|x1, …, xn (IOT(LV | (EXTI(SI(rdf:first)), (EXTI(SI(rdf:rest)), … |
| | (EXTI(SI(rdf:first)), (EXTI(SI(rdf:rest)) |
|If there exists |then there exists y with |
|l, a sequence of x1,…,xn over IOC |y(IOC, (EXTI(SI(owl:unionOf)) |
|l, a sequence of x1,…,xn over IOC |y(IOC, (EXTI(SI(owl:intersectionOf)) |
|l, a sequence of x1,…,xn over IOT(LV |y(CEXTI(SI(rdfs:Class)), (EXTI(SI(owl:oneOf)) |
|If there exists |then there exists y ( IOC with |
|x (IOC | (EXTI(SI(owl:complementOf)) |
|If there exists |then there exists y (IOR with |
|x (IOP ^w (IOC (IDC | (EXTI(SI(owl:onProperty)) ^ |
| | (EXTI(SI(owl:allValuesFrom)) |
|x (IOP ^w (IOC (IDC | (EXTI(SI(owl:onProperty)) ^ |
| | (EXTI(SI(owl:someValuesFrom)) |
|x (IOP ^w (IOT (LV | (EXTI(SI(owl:onProperty)) ^ |
| | (EXTI(SI(owl:hasValue)) |
|x (IOP ^w (LV ^w is a non-negative integer | (EXTI(SI(owl:onProperty)) ^ |
| | (EXTI(SI(owl:minCardinality)) |
|x (IOP ^w (LV ^w is a non-negative integer | (EXTI(SI(owl:onProperty)) ^ |
| | (EXTI(SI(owl:maxCardinality)) |
|x (IOP ^w (LV ^w is a non-negative integer | (EXTI(SI(owl:onProperty)) ^ |
| | (EXTI(SI(owl:cardinality)) |
103.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)
SR XML Procedural Template 1: ECG
SR XML TEMPLATE 2: DEMOGRAPHICS
[pic]
SR XML TEMPLATE 3: CLINICAL INDICATION(S)
[pic]
SR XML TEMPLATE 4: COMPARISON
[pic]
SR XML TEMPLATE 5: CLINICAL INFORMATION
[pic]
Legend HPI History of Present Illness
ROS Review of Systems
PMHx Past Medical History
Hx History
SR-XML Template 6: Technical Methods
SR XML Template 7: Quantitative Analysis
SR XML Template 8: Qualitative Results
SR XML TEMPLATE 9: ASSESSMENT
[pic]
103.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.
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 | |
|* |0 or more |
|+ |1 or more |
|? |0 or 1 (optional) |
|REPORT TYPES (Based on Temporal|HOSP|CLINICA| |Clinical Information |Diagnostic Tests |
|Sequence) |. |L | |Template |Template |
|N. = Note |CLIN|REFERRA| | | |
|R. = Report |IC |L | | | |
| |OFFI|EDUCATI| | | |
| |CE |ON | | | |
| | |RESEARC| | | |
| | |H | | | |
| | | | | | |
|ORGAN | | | | | |
|SYSTEMS | | | | | |
|Central Nervous System |+ |+ |Neurology/ |Neurosurgery |Neuroradiology |
| | | |Anesthesiology/ | | |
| | | |Psychiatry | | |
|Eye |+ |+ |(Optometrist) |Ophthalmology |Neuroradiology |
|Ear, Nose, and Throat |+ |+ |Allergy and |Otolaryngology |Head and Neck Imaging |
| | | |Immunology | | |
|Heart |+ |+ |Cardiology |Cardiovascular Surgery |Cardiovascular Imaging |
|Hemovascular System |+ |+ |Hematology |Vascular Surgery |Interventional Radiology |
|Pulmonary System |+ |+ |Pulmonology |Thoracic Surgery |Chest Radiology |
|Gastrointestinal System |+ |+ |Gastroenterology |Gastrointestinal |Gastrointestinal Radiology |
| | | | |Surgery | |
|Renal System |+ |+ |Nephrology |Urology |Uroradiology |
|Reproductive System | |+ | |Obstetrics and |Women’s Imaging |
| | | | |Gynecology | |
|Musculo-skeletal |+ |+ |Rheumatology |Orthopedics |Musculoskeletal Imaging |
|Dermal System |+ |+ |Dermatologist |Plastic Surgery | |
| | | | | | |
|SYSTEMIC PROCESSES | | | | | |
|EndocrineMetabolic |+ |+ |Endocrinology |Endocrine Surgery |Nuclear Medicine |
|Immune System |+ |+ |Immunologist |Transplant Surgery | |
|Toxins | |+ |Toxicologist | | |
|Infectious |+ |+ |Infectious Diseases | | |
|Neoplasia |+ |+ |Oncology |Surgical Oncology |Radiation Oncology |
| | | | | | |
|TEMPORAL | | | | | |
|Neonatal Life | |+ |Genetics | | |
| | | |Neonatology | | |
|Childhood | |+ |Pediatrics |Pediatric Surgery |Pediatric Radiology |
|Adolescence | |+ |Adolescent Medicine | | |
|Adulthood | |+ |Internal Medicine | | |
|Acute Medical Process |+ |+ |Emergency Medicine |Trauma |Emergency Radiology |
| | | |Intensive Care Medicine | | |
|Chronic Medical Process | |+ |Geriatrics | | |
|In Vitro or Terminal Process | |+ |General Pathology |Surgical Pathology | |
| | | |Laboratory Medicine | | |
|Transcendent | |+ |Medical Ethics | | |
| | | | | | |
|GENERAL | | | | | |
| | |+ |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.
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/Procedure |
| | | | | |
| | | | | |
|Central Nervous System |Headache |Contusion |Head CT |Lumbar Puncture |
| |Seizure |Concussion |Brain MRI | |
| |Syncope |Coma | | |
| |Confusion |Skull fracture | | |
| |Dementia | | | |
| |Psychosis | | | |
| |Depression | | | |
|Eye |Conjunctivitis |Corneal abrasion |Orbital Series |Wood’s Lamp |
| | |Globe laceration |Orbital CT |Slit Lamp |
| | |Orbital floor fracture | | |
|Ear, Nose, and Throat |Otitis Media |LaForte Fractures | | |
| |Otitis Externa |Nasal Fracture |Facial Series | |
| |Rhinitis |Facial Contusion |Mandible Series | |
| |Pharyngitis | |Temporal Bone CT | |
| |Sinusitis | |Facial CT | |
|Endocrine/Metabolic |Thyroid Storm |Dehydration | |Rehydration |
| |Addisonian Crisis | | | |
|Immune System |Urticaria | | |Antihistamines |
| |Anaphylactoid Reaction | | |H2 Blockers |
| |Delayed hypersensitivity | | |Epinephrine |
| |Anaphylaxis | | |Steroids |
|Heart |Chest Pain |Cardiac Contusion |Chest Pain MPS |Pericardiocentesis |
| |Cardiac Arrest |Cadiac Tamponade |Chest Radiograph | |
| |Dysrhythmia | |Echocardiography | |
| |Cardiac Tamponade | |Transesophageal Echo | |
| |Myocardial Ischemia | |Cardiac MRI | |
| |Myocardial Infarct | |Chest CT | |
| |Cardiac Standstill | | | |
| |Ventricular Rupture | | | |
| |Congestive Heart Failure | | | |
| |Hypertension | | | |
|Hemovascular System |Anemia |Hemorrhage |Venous Ultrasound |Hemostasis |
| |Hypertension | |Peripheral Arterial US | |
| |Hypotension | |Spiral CT Angio | |
| |Venous Stasis | |MR Angiography | |
| |Venous Thrombosis | | | |
| |Arterial Insufficiency | | | |
| |Arterial Occlusion | | | |
|Pulmonary System |Shortness of Breath |Pulmonary Contusion |Chest Radiograph |Pleurocentesis |
| |Dyspnea |Pulmonary Laceration |Chest CT |Chest Tube |
| |Tachypnea |Pneumothorax | | |
| |Bronchospasm | | | |
| |Bronchitis | | | |
| |Pneumonia | | | |
| |Pleural Effusion | | | |
|Gastrointestinal System |Abdominal Pain |Ileus |KUB |Diagnostic Peritoneal Lavage |
| |Mesenteric Ischemia |Bowel Infarction |Abdominal Series | |
| |Mesenteric Infarct |Volvulus |Abdominal US | |
| |Gastritis |Hepatic Laceration |Abdominal/Pelvic CT | |
| |Gastroenteritis |Splenic Laceration |Abdominal/Pelvic MRI | |
| |Pancreatitis |Pancreatic Contusion | | |
| |Cholecystitis |Cholelithiasis | | |
|Genitorenal System |Pyelonephritis |Hydronephrosis |KUB |Foley Catheter Placement |
| |Cystitis |Ureteral Obstruction |IVP | |
| |Urethritis |Renal Colic |Spiral CT | |
| |Hematuria |Bladder Contusion |Retrograde Urethrogram | |
| | |Bladder Laceration | | |
|Reproductive System |Cervicitis |Ov. Cyst Hemorrhage |Pelvic US |Culdocentesis |
| |Endometriosis |Ovarian Cyst Rupture |Endovaginal US |Delivery |
| |Urethritis |Ovarian Torsion | |C-Section |
| | |Uterine Prolapse | | |
| | |Ectopic Pregnancy | | |
| | |Premature Labor | | |
|Musculoskeletal |Osteoarthritis |Muscle strain |Skeletal Radiography |Splint |
| |Rheumatoid arthritis |Muscle rupture |Bone scan |Reduction |
| |Septic arthritis |Joint Subluxation |Skeletal CT |Traction |
| |Reiter’s |Joint Dislocation |Musculoskeletal MRI | |
| |Gout |Skeletal Fracture | | |
| | |Amputation | | |
|Dermal system |Contact Dermatitis |Laceration | |Laceration Repair |
| |Allergic Dermatitis |Contusion | | |
| |Psoriasis |Ecchymosis | | |
| |Impetigo |Hematoma | | |
| |Cellulitis |Burn | | |
| |Necrotizing Fasciitis | | | |
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 |Ultrasound |Magnetic |Nuclear Medicine |X-Ray |CT |Interventional |
|SITE (Cephalo-Caudal | |Resonance | |(Conventional | |Cardiology and Radiology|
|Sequence)/ | |Imaging | |Radiography, | |(Biopsy, Drainage |
|RADIATION TYPE | | | |Fluoroscopy, | |Catheters, Angioplasty) |
| | | | |Conventional Tomograms) | | |
| | | | | | | |
| | | | | | | |
|Head |Neonatal US |Brain MRI |Brain SPECT |Skull Series |Brain CT | |
| | | |Brain PET |Nasal Series | | |
| | | | |Facial Series | | |
|Spine |Fetal US |+ |Gallium |+ |+ |Lumbar Puncture |
|(C-spine, | | |Bone Scan | | | |
|T-spine, | | | | | | |
|LS-spine) | | | | | | |
| | | | | | | |
|Orbit |+ |+ | |Orbital Series |CT Orbit | |
|Temporal Bones | |+ | |TMJ |CT Temporal Bones| |
|Sinuses | |+ | |Sinus Series |CT Sinues | |
|Mandible | |+ |Bone Scan |Mandibular Series |+ | |
| | | | |Orthopantomogram | | |
|Dentition | |+ | |Dental series |+ | |
|Neck |+ |+ |Thyroid |Neck Soft Tissue |+ | |
| | | |Parathyroid | | | |
|Thorax |+ |+ |Ventilation |Chest radiograph |Chest CT |Lung Bx |
| | | |Perfusion | | | |
|Cardiac |Echocardiograph|Cardio-vascula|Planar |Cardiac Catheterization |Coronary |Pericardiocentesis |
| |y |r MRI |SPECT | |artery |Pacemaker |
| |ICE | |PET | |calcification | |
| |IVUS | |RNA | | | |
|Hemovascular System |Doppler |Vascular MRA |99m TC/tagged RBC |Venography |Spiral CTA |Angioplasty |
| | | | |Conventional Angiography | |Stent |
| | | | | | |Rotoblader |
| | | | | | |Laser |
|Pulmonary System |+ |+ |Ventilation |CXR |CT Chest |Lung Bx |
| | | |Perfusion | |Spiral CTA |Chest Tube |
|Gastrointestinal System |+ |+ |Gastric emptying |Barium Swallow |CT Abdomen |G-tube |
| | | |HIDA |UGI Series |CT Pelvis |J-tube |
| | | |Liver-Spleen |SB Series | | |
| | | | |Colon Series | | |
|Renal System |+ |+ |Renal Scan |KUB |CT |Nephrostomy tube |
| | | | |IVP |Nephroto-mogram |placement |
|Reproductive System |Obstetric |+ |Testicular Scan |Hysterosalpingogram |+ |+ |
| |Gyneco-logic | | | | | |
|Pelvis | |+ |Bone Scan |+ |+ |+ |
|Musculo-skeletal |+ |+ |Bone Scan |+ |+ |+ |
| | | |Gallium | | | |
| | | | | | | |
|SYSTEMIC PROCESSES | | | | | | |
|Endocrine |+ |+ |Pheochromo-cytoma |Metabolic Survey |+ |+ |
|Metabolic | | | | | | |
|Immune System |+ |+ |Gallium |Lymphangiogram |+ |+ |
|Toxins | | | |Radiograph (Lead) | | |
|Infectious Inflammatory |+ |+ |Indium-111 |+ |+ |+ |
| | | |Gallium | | | |
|Neoplasia |+ |+ |18-FDG |Metastatic Survey |+ |+ |
| | | | | | | |
114. 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.
125. REFERENCES
• 3M Information Models
• CEN Archetypes
o Chapter on Conformance and Extensibility
o DSTC Archetype Editor ()
• EbXML, , 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 ()
• SNOMED/DICOM Microglossary
[1] There is a distinct scope of persistence for a clinical document, independent of the persistence of any XML-encoded CDA document instance.
[2] OCL is the formal constraitn language for information models expressed in UML, such as the HL7 V3 RIM.
[3] Correct guess ?
[4] Correct guess ?
[5] does it include the version number ?
[i]
-----------------------
Domain Friendly Template and archetype Interface
HL7 Friendly Template and archetype
Process A
Template and archetype Representation Format
R-MIM XX
Process B
Domain Expert
[pic]
[pic]
[pic]
[pic]
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- the history channel this day in history
- the standards for mathematical practice
- samples the variable in an experiment
- ethical standards in the workplace
- high standards in the workplace
- type the missing number in this sequence
- display the formulas in this worksheet
- a give the molecular formula of menthol b this molecule is an alcohol classify
- to what extent did the decade of the 1950s deserve its reputation as an age of p
- ethical standards in the human services field
- how to use the management studio before you do the exercises for this chapter
- how would you characterize the universities in this cluster