HL7 Version 3 Templates
DRAFT Specification
Release 1.0, ver. 0.01 (DRAFT August 2, 2002)
Editors: / Robert H. Dolin, MD, Kaiser PermanentePeter L. Elkin, MD, Mayo Clinic
Contributors: / Liora Alschuler, alschuler.spinosa
Thomas Beale, GEHR
Calvin Beebe, Mayo Clinic
George W. Beeler, Jr. Ph.D., Beeler Consulting LLC
Fred Behlen
Sandy Boyer, BSP, Consultant
William T.F. Goossen, PhD, RN
Martin Kernberg, MD
Ted Klein
Charles Mead, MD
Lloyd McKenzie
Angelo Rossi-Morri
Ken S. Rubin
Alexander Ruggieri, MD, Mayo Clinic
Gunther Schadow, MD, PhD
Amnon Shabo, IBM
Harold Solbrig, Mayo Clinic
Revision History, DRAFT Release 1.0:
version 0.01, August 2, 2002: Major revision to previous document of June 3. Extracted Registry requirements, and tooling requirements to separate documents. Major changes logged in separate Change log file; deleted material in separate file of major deletions. la
1Introduction......
1.1Intent of this document......
1.2HL7 Templates Defined......
1.3Templates and Version 3......
1.3.1Templates, the RIM and R-MIMs
1.3.2Templates, CMETs, Clones and HMDs
1.3.3Templates and Vocabulary......
1.3.4Templates and Message Types
1.3.5Templates and the CDA......
1.4Key Aspects of HL7 Templates......
1.4.1Template identification......
1.4.2Template creation......
1.4.3Referencing Templates......
1.4.4Validating Templates......
2Scope of this Specification......
3Normative References......
4Template requirements......
4.1Identifiers
4.2Declaring the use of a template......
4.3Template granularity
4.4Vocabulary
4.5Validating an HL7 instance against a template......
4.6Template assertions......
4.6.1In-scope, Release 1.0......
4.6.1.1Nesting
4.6.1.2Open/closed
4.6.1.3Defaults
4.6.1.4Order
4.6.1.5Dependency......
4.6.1.6Selection......
4.6.1.7Composition......
4.6.1.8Sequence......
4.6.1.9Proximity......
4.6.1.10External templates......
4.6.1.11Value-sets......
4.6.1.12Reference......
4.6.1.13Cardinality......
4.6.1.14Nulls......
4.6.2Out-of-scope, Release 1.0......
4.6.2.1Logic......
4.6.2.2Chronological......
4.6.2.3Comparison......
4.6.2.4Operations......
5Template methodology......
5.1.1Scenario - Lab batteries......
5.1.1.1Constrain by cloning......
5.1.1.2Constrain using a constraint language......
5.1.1.3Constrain using a tabular template representation......
5.1.2Scenario – Document contents......
5.1.2.1Constrain by cloning......
5.1.2.2Constrain using the constraint box......
5.1.2.3Constrain using a tabular template representation......
6Glossary......
7Appendix......
7.1Mapping external templates into the proposed structure......
7.1.1GEHR......
7.1.1.1gehr.cont.observe.foot_diabetic......
7.1.23M Information Model......
7.1.2.1BirthWeightObs......
7.1.3Mayo Foundation......
7.1.3.1Vital Signs......
8Open Issues......
8.1Relationship between templates, template architecture......
8.2Relationship to data entry......
8.3The term “template”......
8.4Named paths......
1Introduction
1.1Intent of this document
This document specifies HL7 Templates and will be balloted as a normative HL7 standard. Related documents specify an HL7 Templates Registry and HL7 Templates Tooling. These documents will not be balloted but will form the basis for HL7 research and development on recommendation of the Templates SIG and at the discretion of the Board of Directors. [add reference when document available]
1.2HL7 Templates Defined
A “template” in the broadest sense is simply a constraint on a more generic model. HL7 Templates are part of the HL7 Version 3 family of specifications, hence the constraints are applied to HL7 Version 3 artifacts. The creation of HL7 templates allows for the more formal identification and specification of terminology and concept representation for a particular purpose. Templates thus specify the expression of the normative representation of concept(s) and their relationships so that they can be used and re-used throughout our standards.
HL7 has a formal mechanism for constraining the RIM to produce ballotable specifications. However 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. This specification describes a process whereby users can develop templates to identify and enforce such constraints.
These constraints are expressed in an implementation technology specification (ITS)-neutral canonical representation. They can be implemented as an ITS-specific constraint language, optimized for the specific ITS. [See TB comments under Vocabulary.]
In separate documentation, HL7 will articulate how these templates can be stored in an HL7 template registry. Such a registry would be capable not only of maintaining HL7 templates, but could be extended to support the needs of specialty societies as well.
1.3Templates and Version 3
First it is important to differentiate between a template and other Version 3 artifacts: the RIM, CMETs, clones, R-MIMs, HMDs and CDA documents.
1.3.1Templates, the RIM and R-MIMs
The HL7 Reference Information Model (RIM) is … [define through prose, glossary entry or reference to HDF].
This specification defines a “template” as a constraint on the RIM.
An Refined Message Information Model (R-MIM) is…[define through prose, glossary entry or reference to HDF]. An R-MIM is a template because it represents a specific constraint on the RIM.
OPEN ISSUES:
CNM: Shouldn’t this statement be scoped to a smaller domain? Are there Templates that will be constraints on just the RIM? Or would Templates (at least HL7 Templates) be constraints on subsets (i.e. constraints) of the RIM. Can an HL7 Specification be defined without the use of Clones? I didn’t think so. If true, this statement should be clarified since Templates would never (realistically) constrain the RIM per se, but rather pre-defined constraints on the RIM.
TB: need to be careful here. An R-MIM is a constrained sub-schema based on the RIM; it defines a set of constrained / altered types and attributes. It doesn’t express constraints on instances of the RIM – there are no such things in HL7 – that’s not its job; its job is to be a schema parent for more constrained schemas which eventually provide message structures. “Constrained” schema is not the same thing as a document expressing constraints on data.
1.3.2Templates, CMETs, Clones and HMDs
Clones and CMETs within an R-MIM are templates that constrain various RIM structures. An HMD is a template because it represents a constraint on an R-MIM. .
An important distinction needs to be drawn between a clone and a template—for instance, when is a committee to express needed constraints in a clone (or a CMET), as opposed to expressing those constraints in a template? The answer appears as more of a heuristic than a rule.
A look at the detail illustrates the difference between clones and templates. In general, clones result in new XML tag names, whereas templates do not. Clones add new markup, whereas templates constrain existing markup. Clones express what is possible, and the range of possibilities can be constrained with a template. Clones show up on R-MIM Visio diagrams, whereas templates do not. Clones are defined by HL7 for the purpose of use within one or more balloted specifications. Thus, clones are specific constraints on the RIM defined by HL7 committees for inclusion in one or more balloted specifications. Clones result in new XML tag names. A balloted specification declares the exact set of allowable clones.
Conversely, templates are constraints upon the RIM declared either by HL7 or by some external source. HL7 templates may only constrain the range expressions allowable within the context of a balloted HL7 specification.
A CMET is nothing more than a clone that is used in multiple specifications. The CMET is a convenient macro that ensures all specifications include the same pattern. CMETs are clones and are always defined by HL7. The HL7 development methodology has a formal mechanism for expressing which CMETs can be used where within a balloted specification.
OPEN ISSUES:
TB: All of the uses of the word “template” are different to what I think you are trying to do here, and certainly different from what archetypes are about.
CNM: Doesn’t this imply that Clones are (predominantly) syntactic constraints? Doesn’t this imply that Templates are (predominantly) semantic constraints?.
1.3.3Templates and Vocabulary
The set of terminology used to represent a particular concept is determined by the RIM. In some circumstances, terminologies may vary by realm. Templates can constrain to a subset of the RIM defined or referenced vocabulary, but can’t do any more than that.
1.3.4Templates and Message Types
A message type is a template that constrains an HMD. [describe declaration of template within instance; templates at which levels of message type? message instance?]
LRM: we need to identify the relationship between conformance profiles and templates. There are several tie-ins. 1. Conformance profiles will indicate constraints on a message type indicating what they are actually capable of generating/receiving. This has some overlap with the concept of templates. 2. Conformance profiles may need to indicate what templates the application is capable of receiving/generating for a particular message/interaction.
1.3.5Templates and the CDA
[describe use of templates to constrain Level One, thus creating Level Two CDA. Use of templates in Level Three CDA. Declaration of templates within CDA documents -- describe here or reference CDA spec]
[templates can apply at the document root level or sub-document level]
1.4Key Aspects of HL7 Templates
1.4.1Template identification
Templates carry globally-unique identifiers. The subject and origin of a template is conveyed by a multi-part identifier. See Section 4, Template Requirements, Identifiers.
1.4.2Template creation
Templates are defined by HL7 or by external sources.
1.4.3Referencing Templates
An HL7 specification declares its use of clones and may or may not declare its use of templates. Templates would be referenced at the point they are needed, with each instance declaring exactly the templates it is invoking. Templates can begin at any point in an instance where the constrained classes can occur. These instances allow validation against both the HL7 specification and the referenced template(s).
In addition, message and document instances can declare the use of additional templates, that is, templates not already specified through an HMD.
1.4.4Validating Templates
The use of templates, irrespective of their source, implies that instances can be validated—both against the template and against the HL7 specification the instance is referencing.
2Scope of this Specification
The HL7 template specification is compatible with HL7 V3 Development Framework. This specification should build upon prior work, fitting it into the HL7 V3 development framework rather than trying to invent a new approach.
Further, the intent of the first ballot is to standardise what people are already doing with templates, rather than to attempting to introduce new functionality. Operationally, the scope of templates is bounded by what can be expressed using the template methodology from an R-MIM that does not use a constraint box.
The scope of this specification is limited to the normative definition and expression of a specific Template. It does not define the requirements for building the tools for authoring, viewing, archiving, managing, merging, evolving, etc. multiple Templates in a Template Registry. See [ref Registry Document]
OPEN ISSUE: Need to understand and be clear on the differences between Templates and: International Localization, constraining by Realm, Conformance specifications, V3 messaging extensibility, CDA local markup. Depending on how sophisticated the template constraint language is, there may also be a blurring between Templates and: Decision Support, Arden Syntax, Guidelines.
3Normative References
HL7 Version 3.0, HL7 Clinical Document Architecture (ANSI/HL7 CDA R1.0-2000)
ISO TS17117:
The following models have been reviewed:
- GEHR Archetypes
- CEN Archetypes
- 3M Information Models
- SNOMED/DICOM Microglossary
- EbXML, XML.org, OASIS Registries
4Template requirements
This section defines the requirements for HL7 Templates.
4.1Identifiers
Templates will carry two types of identifiers:
- Globally-unique identifier
- template subject and origin
OPEN ISSUES: OID, GUID? [insert description, definition]
[insert proposal for multi-part identifier; see listserv discussion]
How to represent the “essence” of a template – for instance, that this is a CBC template, or a template that defines a history-and-physical? Is it the case that the Act.cd of the base class in the template represents the template’s “essence”?
4.2Declaring the use of a template
- Use of a template can be declared in a balloted specification.
- Use of a template can be declared in an instance.
For instance, a specification may say designate a particular clone, with a particular template applied to it. Alternately, the use of a template can be declared at the time the instance is created. An authoring application may impose additional guidance and/or restrictions upon the selection and applicability of templates. The instance declares the insertion point of each template that is used.
OPEN ISSUES: exactly how is use of a template declared in an instance or balloted spec? should this be part of this specification or left to the discretion of authors of other specifications?
Thomas Beale suggests that the id of the invoked template is ALWAYS needed in the instance. This seems to contradict Harold Solbrig’s notion of “predicates”.
TB: I think I suggested this because with no id declared, how do you efficiently locate what might be the best or closest candidate matching template? In some cases, this could result in sledge-hammer processing in an attempt to find a suitable template
4.3Template granularity
- Templates can constrain anything that can be said in a valid HL7 instance, down to the level of a data type property.
- A template can constrain any data type property.
- A template can constrain the allowable sections of a CDA Level Two or Level Three document, based on the document type code.
OPEN ISSUES:
TB: I don’t think this can be formally said to be true of R-MIMs, CMETs etc, since their job is not to express constraints on data, but to define allowable types of which data can be instances; see earlier comments. But I do think this statement is what templates are about.
LA: (third bullet) I’m not sure if this belongs here or under Section 1.3.5 on Templates and the CDA. If it stays here, it should be extended to include template constraints on section contents.
4.4Vocabulary
HL7 will support multiple coding schemes for the same concept. Different realms (i.e. countries) have the right to use different coding systems for the same concept. There is also the possibility of multiple coding systems being registered for a single domain within a single realm, though one of the coding systems must be marked as “preferred”. (Note: this policy is consistent with the policy of the HL7 Vocabulary Committee.)
OPEN ISSUES: Could requirements for subseting be used to combine elements in the template with different coding schemes? Could this also be used to have multiple codes, from different coding schemes for one template element? Like synonyms?
[TB] Consider that in a template you will want to do two things:
1. fix a data item to be just one name or term, e.g. "complete blood count" [code = xyz, terminology = abc]. This is most often done for names of things or "questions"
2. constrain a data value to be one of a set or picklist, e.g. names of body parts which are palpable, names of blood groups etc
The first is relatively easy, but you still don't want to be creating templates that are tied to some particular terminology such as SNOMED - else we end up with templates which would have been globally applicable, but are in reality only useful to sites using some particular terminology system. And don't forget non-English language countries - many of them will not be using any of the mono-lingual (English) terminologies.
The second is a lot harder. The way to state constraints which result in a particular subset of valid terms being available to the user is heavily dependent on the terminology. But again, we don't want to tie templates to a given terminology, when what they express is otherwise valid regardless of terminology.
There are ways out of this, which I will not go into here (if anyone wants to discuss that, please say so).
Observation.cd vs. Observation.value – how will templates help us resolve the potential for saying the same thing in more than one way?
ObservationValue
HLA-B27 AGAbsent
HLA AG ABSENTHLA-B27
Auscultation of abdomenBorborygmia
Abdomen examAusculation reveals borborygmia
ROM of Knee30 degrees
Exam of KneeROM is 30 degrees
Wheezing FrequencyDaily and continual
Respiratory SymptomWheezing daily and continual
Draft HL7 and CAP (SNOMED) guidelines currently recommend the following:
- When exchanging information about observations:
- Observation.cd can be populated with a descendent of Observation procedure (122544007).
- Observation.cd can be populated with a descendent of Observable entity (363787002). [Observable entity values semantically represent the measured component of an observation procedure. Therefore when they are used, they should be assumed to be an observation of the particular observable entity. For example, you can send the observation procedure code "total body water measurement (241419008)", or, if you send the observation entity code "total body water (251837008)", you would assume it is an observation of total body water, and therefore logically equivalent to the observation procedure code.]
- When exchanging information about findings and diseases:
- Observation.cd can be populated with a descendent of Qualifier for type of diagnosis (106229004).
- Observation.value should be populated with descendents of Finding (246188002) or descendents of Disease (64572001).
TB: this is one of the strengths of using archetypes we have found – the template aspect of an archetype predisposes the data recorder to use of certain Observation.cds, and also provides sensible constraints for values, given that these cds have been used.
4.5Validating an HL7 instance against a template
An instance that declares the use of a template must be a valid and conformant HL7 instance. In addition, the receiver can choose to validate the instance against declared templates – using an XSLT script, a Relax NG schema, or some other yet to be determined mechanism.
Note that the meaning of an instance is not affected by whether or not it is validated against a template.
- An HL7 instance that declares the use of a template is a valid HL7 instance and is also valid against the template constraints.
- Users require the ability to express constraints without needing to change the XML tag names specified in an HL7 schema. The use of a template does not require the use of new XML tags.
It is not required that an instance declare the use of a template in order to validate that the instance conforms to the constraints or assertions of a particular template.
A template can be used within an instance wherever applicable. There is a means of declaring where (insertion point), when and how templates are to be used.
OPEN ISSUES:
LRM: Can we add another requirement: A template that works on a model (R-MIM/HMD/MsgType) having recursive or repetitive associations will also work against derived models where those recursions and/or associations have been unrolled. (Reason this is important is that the tag names will change as part of the unrolling.)
4.6Template assertions
Templates can express various assertions or constraints. The assertions described below are divided into those within scope for this release and those that are out of scope for this release.
4.6.1In-scope, Release 1.0
4.6.1.1Nesting
- A template can contain another template. This can be declared in a balloted specification and/or at run time.
For example: The Vital Signs Template might contain a Blood Pressure Template as an element.
OPEN ISSUES:
TB: I would suggest that at the point in a template where the next piece of data is constrained by another template, what you want to put is yet another constraint: one which when evaluated results in a list of template ids from the repository - being the list of templates which can be validly used at that point. There are several systems for doing this.