HL7 Version 3 Templates DRAFT Specification Release 1.0, ver. 0.01 (DRAFT August 2, 2002)
Editors: Robert H. Dolin, MD, Kaiser Permanente Peter 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
HL7 V3 Templates DRAFT Specification ver. 0.01 August 2, 2002 1 1 INTRODUCTION...... 4
1.1 INTENT OF THIS DOCUMENT...... 4 1.2 HL7 TEMPLATES DEFINED...... 4 1.3 TEMPLATES AND VERSION 3...... 4 1.3.1 Templates, the RIM and R-MIMs...... 4 1.3.2 Templates, CMETs, Clones and HMDs...... 5 1.3.3 Templates and Vocabulary...... 5 1.3.4 Templates and Message Types...... 5 1.3.5 Templates and the CDA...... 5 1.4 KEY ASPECTS OF HL7 TEMPLATES...... 6 1.4.1 Template identification...... 6 1.4.2 Template creation...... 6 1.4.3 Referencing Templates...... 6 1.4.4 Validating Templates...... 6 2 SCOPE OF THIS SPECIFICATION...... 6
3 NORMATIVE REFERENCES...... 6
4 TEMPLATE REQUIREMENTS...... 7
4.1 IDENTIFIERS...... 7 4.2 DECLARING THE USE OF A TEMPLATE...... 7 4.3 TEMPLATE GRANULARITY...... 7 4.4 VOCABULARY...... 7 4.5 VALIDATING AN HL7 INSTANCE AGAINST A TEMPLATE...... 9 4.6 TEMPLATE ASSERTIONS...... 9 4.6.1 In-scope, Release 1.0...... 9 4.6.1.1 Nesting...... 9 4.6.1.2 Open/closed...... 9 4.6.1.3 Defaults...... 10 4.6.1.4 Order...... 10 4.6.1.5 Dependency...... 10 4.6.1.6 Selection...... 10 4.6.1.7 Composition...... 10 4.6.1.8 Sequence...... 10 4.6.1.9 Proximity...... 11 4.6.1.10 External templates...... 11 4.6.1.11 Value-sets...... 11 4.6.1.12 Reference...... 11 4.6.1.13 Cardinality...... 11 4.6.1.14 Nulls...... 11 4.6.2 Out-of-scope, Release 1.0...... 11 4.6.2.1 Logic...... 11 4.6.2.2 Chronological...... 12 4.6.2.3 Comparison...... 12 4.6.2.4 Operations...... 12 5 TEMPLATE METHODOLOGY...... 13 5.1.1 Scenario - Lab batteries...... 13 5.1.1.1 Constrain by cloning...... 14 5.1.1.2 Constrain using a constraint language...... 15 5.1.1.3 Constrain using a tabular template representation...... 17 5.1.2 Scenario – Document contents...... 18 5.1.2.1 Constrain by cloning...... 18 5.1.2.2 Constrain using the constraint box...... 20 5.1.2.3 Constrain using a tabular template representation...... 23
HL7 V3 Templates DRAFT Specification ver. 0.01 August 2, 2002 2 6 GLOSSARY...... 25
7 APPENDIX...... 25
7.1 MAPPING EXTERNAL TEMPLATES INTO THE PROPOSED STRUCTURE...... 25 7.1.1 GEHR...... 25 7.1.1.1 gehr.cont.observe.foot_diabetic...... 25 7.1.2 3M Information Model...... 28 7.1.2.1 BirthWeightObs...... 28 7.1.3 Mayo Foundation...... 29 7.1.3.1 Vital Signs...... 29 8 OPEN ISSUES...... 31
8.1 RELATIONSHIP BETWEEN TEMPLATES, TEMPLATE ARCHITECTURE...... 31 8.2 RELATIONSHIP TO DATA ENTRY...... 31 8.3 THE TERM “TEMPLATE”...... 31 8.4 NAMED PATHS...... 31
HL7 V3 Templates DRAFT Specification ver. 0.01 August 2, 2002 3 1 Introduction
1.1 Intent 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.2 HL7 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.3 Templates 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.1 Templates, 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
HL7 V3 Templates DRAFT Specification ver. 0.01 August 2, 2002 4 which eventually provide message structures. “Constrained” schema is not the same thing as a document expressing constraints on data.
1.3.2 Templates, 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.3 Templates 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.4 Templates 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.5 Templates 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]
HL7 V3 Templates DRAFT Specification ver. 0.01 August 2, 2002 5 [templates can apply at the document root level or sub-document level]
1.4 Key Aspects of HL7 Templates
1.4.1 Template 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.2 Template creation Templates are defined by HL7 or by external sources.
1.4.3 Referencing 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.4 Validating 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.
2 Scope 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.
3 Normative 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
HL7 V3 Templates DRAFT Specification ver. 0.01 August 2, 2002 6 SNOMED/DICOM Microglossary EbXML, XML.org, OASIS Registries
4 Template requirements This section defines the requirements for HL7 Templates.
4.1 Identifiers 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.2 Declaring 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.3 Template 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.4 Vocabulary 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.)
HL7 V3 Templates DRAFT Specification ver. 0.01 August 2, 2002 7 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?
Observation Value HLA-B27 AG Absent HLA AG ABSENT HLA-B27 Auscultation of abdomen Borborygmia Abdomen exam Ausculation reveals borborygmia ROM of Knee 30 degrees Exam of Knee ROM is 30 degrees Wheezing Frequency Daily and continual Respiratory Symptom Wheezing daily and continual
Draft HL7 and CAP (SNOMED) guidelines currently recommend the following:
When exchanging information about observations: o Observation.cd can be populated with a descendent of Observation procedure (122544007). o 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: o Observation.cd can be populated with a descendent of Qualifier for type of diagnosis (106229004). o 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.
HL7 V3 Templates DRAFT Specification ver. 0.01 August 2, 2002 8 4.5 Validating 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.6 Template 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.1 In-scope, Release 1.0
4.6.1.1 Nesting . 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. [?] Until what level can templates be nested?
4.6.1.2 Open/closed . Individual sections of a template can be “open” or “closed”. (See also discussion of Extensibility, below) An open template means you can send more than what is in the template. A closed template means you can only send what is defined in the template.
HL7 V3 Templates DRAFT Specification ver. 0.01 August 2, 2002 9 CNM: This discussion is not clear. Based on the Monterey presentation, I would say that the notion of ‘open’ or ‘closed’ is really a description of the scope of template relative to a given HL7 spec, i.e. if the Template specifies constraints for the entire specification, it is, by definition, ‘closed;’ if it only specifies constraints for a portion/subset of the spec, it is ‘open.’ IS THIS A CORRECT UNDERSTANDING?
4.6.1.3 Defaults . The default for the negation indicator is that it be “closed”.
. If an attribute is Optional with no defaults at the level of the specification being constrained, that attribute cannot carry a default attribute within a template.
If templates could add defaults to optional attributes, an instance that doesn't include the optional attribute would be interpreted to be different things by those validating the instance without the template vs. those validating the instance with the template.
LRM: You might also want to expand on what the default for the negation indicator means.
4.6.1.4 Order . Items in a template can be “ordered” or “unordered”. An ordered template means that the elements declared in the template must correspond to the order of elements in the instance. An unordered template means that such correspondence is not required. (see below, Sequence)
OPEN ISSUES: LRM: Is there really a requirement for templates to be order independent? - this puts an extra burden on validation tools (esp W3C schema) and on receiving applications - and so predictable order was chosen by HL7 for the messages, and there should be a clearly stated reason why a different choice is appropriate for templates. LRM: If we use the HMD as the point of validation for the meaning of a Template that the ability for Templates to be order independent will be difficult. For example if you rearrange the elements in an HMD is it not a different HMD to Xpath?
4.6.1.5 Dependency Expressing dependencies – where the Mandatory or Conformance status, or the cardinality or value of one field depends on the presence or value of another field or fields. (see Cardinality and Nulls below). Would this also include derivation method as in the ‘Observation’ class of the RIM?
4.6.1.6 Selection Expressing selection lists, with the ability to say “check only one” vs. “check all that apply”.
4.6.1.7 Composition . Direct Containment :: The current context contains the specified item as a direct child . Indirect Containment :: The current context contains the specified item as a direct child OR as an indirect descendant . Containment with minimum Depth X :: The current context contains the specified item with no more than X nodes between it . Containment with maximum Depth X :: The current context contains the specified item with at least X nodes between it
4.6.1.8 Sequence . Follows :: The specified item must follow the current item . Precedes :: The specified item must come before the current item
HL7 V3 Templates DRAFT Specification ver. 0.01 August 2, 2002 10 4.6.1.9 Proximity . No more than X between :: The specified item must appear within a specified distance from the current location. (I.e. there may be no more than X items between the current item and the specified item . Adjacent :: A special case of "No more than X between" where X = 0.
4.6.1.10 External templates . Template :: The specified template must be true when invoked starting at the current context . Datatype :: The current context must be a particular datatype (or restriction thereof) . CMET :: The current context must match the requirements of a specific CMET/Message Type
OPEN ISSUES: [LA]I don’t really understand these requirements as “external” templates. In fact, I’m not sure I understand them at all.
4.6.1.11 Value-sets (See also Terminology requirements below.) . Domain :: The concept identified by the current item must be drawn from the specified domain . Fixed :: The value must be exactly the specified value (NOTE: This may be used to restrict coding system) . Coding Scheme :: A template can constrain the coding scheme for a coded element. . Subsetting :: A template can declare a vocabulary domain for a coded element that is any subset of an external vocabulary. This subset can be as small as a single element. . Subset based on hierarchy ::An external vocabulary subset can be defined as all descendants of a particular concept (in a hierarchically structured terminology) . Subset based on concept definitions :: An external vocabulary subset can be defined as all concepts in an external vocabulary that are defined in a certain way (have a certain role relationship to a particular body site, use a particular method of observation, etc). . Subset Union :: The declared vocabulary domain for a coded element can be a union of two sets of concepts drawn from the same external vocabulary. . Subset Subtraction :: the declared vocabulary domain for a coded element can be a defined subset minus a contained defined subset.
4.6.1.12 Reference . Constant :: Used within a parent assertion to include a constant value that is not actually found in the instance. E.g. Assert Sum (some location in instance, 1) would mean that the current location within the instance document/message must have a value that is equal to the value at 'Some Location' + 1. In this case, '1' would be a constant.
4.6.1.13 Cardinality . Minimum Direct Occurrences X :: There must be at least the specified number of the identified element as direct children of the current item . Maximum Direct Occurrences X :: There must be at most the specified number of the identified element as direct children of the current item.
4.6.1.14 Nulls . Not null :: The current element must not be null
4.6.2 Out-of-scope, Release 1.0
4.6.2.1 Logic . AND :: All assertions contained within this assertion must be true . OR :: At least one of the assertions contained within this assertion must be true
HL7 V3 Templates DRAFT Specification ver. 0.01 August 2, 2002 11 . At least X True :: At least X of the contained assertions must be true (Allows for 2 of the 3, 4 of the 10, etc. This is the general case for AND and OR. AND is when X is equal to the number of the assertions; OR is when X is equal to 1) . No more than X True :: No more than X of the contained assertions is allowed to be true . Exactly X True :: Of the list of contained assertions, there must be exactly X of them that are true . NOT :: The contained assertion (there may only be 1) must NOT be true
4.6.2.2 Chronological . Chronologically Prior :: The start time for the current item is earlier than the start time for the specified item. . Chronologically Following :: The start time for the current item is later than the start time for the specified item. . Chronologically within :: The start time for the current item is later than the start time for the specified item and the end time for the current item is earlier than the end time for the current item. . Chronologically co-starting :: The start time for the current item is equal to the start time for the specified item. . Chronologically co-ending :: The end time for the current item is equal to the end time for the specified item.
4.6.2.3 Comparison . Value Equals :: The specified value must equal the current value . Value Less Than :: The specified value must be less than the current value . Value Less Than or Equal :: The specified value must be less than or equal to the current value . Value More Than :: The specified value must be more than the current value . Value More Than or Equal :: The specified value must be more than or equal to the current value . Value Approximately Equals :: The specified value is approximately equal to the current value, within a specified range (or fuzzy range)
4.6.2.4 Operations . Sum :: The current value must be equal to the sum of the values matching the contained assertions . Product :: The current value must be equal to the product of the values matching the contained assertions . Inverse :: The current value must be equal to the inverse of the specified value (1/x) . Negate :: The current value must be equal to the product of the specified value and "-1" . Other operations such as those found in spreadsheets and statistical packages (such as Average, Root, Divide)
OPEN ISSUES: [LRM] There are some very sophisticated spreadsheet & statistical packages out there. Can we try enumerating the requirements?
HL7 V3 Templates DRAFT Specification ver. 0.01 August 2, 2002 12 5 Template methodology This proposal specifically defines a “template” as a constraint on a balloted HL7 specification. These constraints are expressed not as clones, but as constraints on the RIM. There is both an abstract constraint language (corresponding to clone and attribute names in the model being constrained) and an ITS-specific constraint language, optimized for the specific ITS.
Constraint expressions are expressed in a way that is technology neutral. The constraints are based on RIM structures, and the exact clones being constrained are dependent on where the template is used. In an XML ITS, the constraints are actualized as X-Path expressions or Relax NG XML schema, or some other as yet to be determined formalism.
Template formalisms will be developed by the following Process: Define the Desired Patterns: This will be accomplished using in the context of traversing the RIM speak (i.e. Act / Act Relationship / Participant, etc.). Find the desired pattern in an existing R-MIM Extract the pattern (as a clone) from the R-MIM. Define the User Friendly Template in terms of the cloned R-MIM fragment. The Template Object will then have the following attributes: o They will have a representation as a fragment of an Implementation Profile (containing Proper constraints, including Unwrapping => on one or more R-MIM / HMDs). o They will reference or include other templates. These templates must be valid with respect to the same R-MIM. o The templates will be associated and defined by their metadata (e.g. ID, etc.).
5.1.1 Scenario - Lab batteries This example shows two ways of modeling a “lab battery” template, that subject to has the following constraints:
When reporting the results of a CBC, the following observations shall be present: o Hemoglobin (required, cannot repeat) o Hematocrit (optional, cannot repeat) o Platelet count (required, cannot repeat)
The first way constrains by cloning. The second way constrains by using the constraint box in the R-MIM.
HL7 V3 Templates DRAFT Specification ver. 0.01 August 2, 2002 13 5.1.1.1 Constrain by cloning A_Hgb A_Observation_event AR_Observation_event_com ponent class_cd* <= OBS class_cd* = OBS type_cd *: <= "COMP" mood_cd : <= EVN mood_cd *: <= EVN 1..1 cd: = "HGB" cd: = "CBC " v alue: PQ
A_Hct AR_Observation_event_com ponent class_cd* <= OBS mood_cd : <= EVN type_cd *: <= "COMP" cd: = "HCT " 0..1 v alue: PQ
A_Plt AR_Observation_event_com ponent class_cd* <= OBS mood_cd : <= EVN type_cd *: <= "COMP" cd: = "PLT" 1..1 v alue: PQ
This R-MIM results in the following (approximate) HMD:
ATTR DT CARD VOCAB ------A_Observation_event class_cd CS 1..1 OBS mood_cd CS 1..1 EVN cd CE 1..1 CBC AR_Observation_event_component AR 1..1 type_cd CS 1..1 COMP A_Hgb class_cd CS 1..1 OBS mood_cd CS 1..1 EVN cd CE 1..1 HGB value PQ 1..1 AR_Observation_event_component AR 0..1 type_cd CS 1..1 COMP A_Hct class_cd CS 1..1 OBS mood_cd CS 1..1 EVN cd CE 1..1 HCT value PQ 1..1 AR_Observation_event_component AR 1..1 type_cd CS 1..1 COMP A_Plt class_cd CS 1..1 OBS mood_cd CS 1..1 EVN cd CE 1..1 PLT value PQ 1..1
And results in the following (approximate) XML DTD and instance:
HL7 V3 Templates DRAFT Specification ver. 0.01 August 2, 2002 14
Things to note include: Because the constraints were expressed by clones, the XML DTD is able to validate them as well.
5.1.1.2 Constrain using a constraint language
Constraint: CBC Any occurence of Observation.cd="CBC" will contain: o [1..1] Act_relationship.type_cd="COMP" containing [1..1] Observation.cd = "HGB"; AND o [0..1] Act_relationship.type_cd="COMP" containing [1..1] Observation.cd = "HCT"; AND o [1..1] Act_relationship.type_cd="COMP" containing [1..1] Observation.cd = "PLT".
AR_Observation_event_com ponent type_cd* <= COMP+OCCR context_control_cd: CS <= N+C "C" sequence_nbr*: INT priority _nbr: INT pause_qty : PQ 0..* A_Observation_event 0..1 class_cd* <= OBS mood_cd *: CS <=EVN id*: II [1..1] (f iller order number) cd*: CE CWE <=ObservationType (e.g. LOINC code) txt*: ED (f ree text describing the ev ent) status_cd*: CS [0..1] ef f ectiv e_time*: IVL
HL7 V3 Templates DRAFT Specification ver. 0.01 August 2, 2002 15 This R-MIM results in the following (approximate) HMD:
ATTR DT CARD VOCAB ------A_Observation_event class_cd CS 1..1 OBS mood_cd CS 1..1 EVN cd CE 1..1 AR_Observation_event_component AR 0..* type_cd CS 1..1 COMP A_Observation_event 0..1 class_cd CS 1..1 OBS mood_cd CS 1..1 EVN cd CE 1..1 value ANY 1..1
And results in the following (approximate) XML DTD and instance:
Things to note include: The constraint is expressed as a pattern against the more generic RIM, rather than against the specific clones used here. This allows the constraint to be used for any applicable clone. The constraints expressed in the constraint box cannot be validated by a validating W3C Schema XML parser. Some other step would be needed to validate the constraints. Note that this R-MIM represents a very common pattern, to which many constraints are applicable.
HL7 V3 Templates DRAFT Specification ver. 0.01 August 2, 2002 16 5.1.1.3 Constrain using a tabular template representation
AR_Observation_event_com ponent type_cd* <= COMP+OCCR context_control_cd: CS <= N+C "C" sequence_nbr*: INT priority _nbr: INT pause_qty : PQ 0..* A_Observation_event
0..1 class_cd* <= OBS mood_cd *: CS <= EVN id*: II [1..1] (f iller order number) cd*: CE CWE <=ObservationType (e.g. LOINC code) txt*: ED (f ree text describing the ev ent) status_cd*: CS [0..1] ef f ectiv e_time*: IVL
CBC Template:
ATTR DT CARD VOCAB ------Observation class_cd CS 1..1 OBS mood_cd CS 1..1 EVN cd CE 1..1 CBC Act_relationship AR 1..1 type_cd CS 1..1 COMP Observation 1..1 class_cd CS 1..1 OBS mood_cd CS 1..1 EVN cd CE 1..1 HGB value PQ 1..1 Act_relationship AR 0..1 type_cd CS 1..1 COMP Observation 1..1 class_cd CS 1..1 OBS mood_cd CS 1..1 EVN cd CE 1..1 HCT value PQ 1..1 Act_relationship AR 1..1 type_cd CS 1..1 COMP Observation 1..1 class_cd CS 1..1 OBS mood_cd CS 1..1 EVN cd CE 1..1 PLT value PQ 1..1
The resulting HMD, XML DTD, and instances are the same as the prior example using the constraint language.
Things to note include: Template validation doesn’t require that the XML correspond exactly to this table in the same way that the XML ITS would generate XML from an HMD. Template validation should check to see that the
HL7 V3 Templates DRAFT Specification ver. 0.01 August 2, 2002 17 stated components are present, and should not complain if additional, possibly interweaving components are present. Thus, there does need to be a “HGB” observation within the “CBC” observation, but it is acceptable for there to be some other observation within the “CBC” observation, possibly coming before the “HGB” observation.
5.1.2 Scenario – Document contents This example shows two ways of modeling the required components of a document:
A "comprehensive review" document has the following constraints: o "objective" section (required, cannot repeat) o The "objective" section contains a "physical-exam" section (required, cannot repeat) o The "objective" section contains a "lab" section (optional, cannot repeat) o The "physical-exam" section contains a "vital-signs" section (required, cannot repeat) o The "lab" section contains a CBC observation, with the following components: o Hemoglobin (required, cannot repeat) o Hematocrit (optional, cannot repeat) o Platelet count (required, cannot repeat)
5.1.2.1 Constrain by cloning
A_Document class_cd* = DOCCLIN mood_cd *: <= EVN cd: = "ComprehensiveReview "
AR_com ponent 1..1 A_Vital_signs type_cd *: <= "COMP" A_Physical_exam class_cd* <= DOCSECT class_cd* <= DOCSECT AR_com ponent mood_cd : <= EVN A_Objective AR_com ponent mood_cd : <= EVN cd: = "VitalSigns " cd: = "PhysicalExam" type_cd *: <= "COMP" class_cd* <= DOCSECT type_cd *: <= "COMP" mood_cd : <= EVN 1..1 cd: = "objective" 1..1
AR_com ponent 0..1 type_cd *: <= "COMP" A_Hgb A_Observation_event AR_Observation_event_com ponent class_cd* <= OBS class_cd* = OBS type_cd *: <= "COMP" mood_cd : <= EVN A_Lab mood_cd *: <= EVN 1..1 cd: = "HGB" class_cd* <= DOCSECT cd: = "CBC" v alue: PQ mood_cd : <= EVN cd: = "lab " AR_com ponent A_Hct type_cd *: <= "COMP" AR_Observation_event_com ponent class_cd* <= OBS 1..1 mood_cd : <= EVN type_cd *: <= "COMP" cd: = "HCT " 0..1 v alue: PQ
A_Plt class_cd* <= OBS AR_Observation_event_com ponent mood_cd : <= EVN type_cd *: <= "COMP" cd: = "PLT" 1..1 v alue: PQ
This R-MIM results in the following (approximate) HMD:
ATTR DT CARD VOCAB ------
HL7 V3 Templates DRAFT Specification ver. 0.01 August 2, 2002 18 A_Document class_cd CS 1..1 DOCCLIN mood_cd CS 1..1 EVN cd CE 1..1 CompReview AR_Component AR 1..1 type_cd CS 1..1 COMP A_Objective class_cd CS 1..1 DOCSECT mood_cd CS 1..1 EVN cd CE 1..1 objective AR_Component AR 1..1 type_cd CS 1..1 COMP A_Physical_exam class_cd CS 1..1 DOCSECT mood_cd CS 1..1 EVN cd CE 1..1 PhysicalExam AR_Component AR 1..1 type_cd CS 1..1 COMP A_Vital_signs class_cd CS 1..1 DOCSECT mood_cd CS 1..1 EVN cd CE 1..1 VitalSigns AR_Component AR 0..1 type_cd CS 1..1 COMP A_Lab class_cd CS 1..1 DOCSECT mood_cd CS 1..1 EVN cd CE 1..1 lab AR_Component AR 1..1 type_cd CS 1..1 COMP A_Observation_event class_cd CS 1..1 OBS mood_cd CS 1..1 EVN cd CE 1..1 CBC AR_Observation_event_component AR 1..1 type_cd CS 1..1 COMP A_Hgb class_cd CS 1..1 OBS mood_cd CS 1..1 EVN cd CE 1..1 HGB value PQ 1..1 AR_Observation_event_component AR 0..1 type_cd CS 1..1 COMP A_Hct class_cd CS 1..1 OBS mood_cd CS 1..1 EVN cd CE 1..1 HCT value PQ 1..1 AR_Observation_event_component AR 1..1 type_cd CS 1..1 COMP A_Plt class_cd CS 1..1 OBS mood_cd CS 1..1 EVN cd CE 1..1 PLT value PQ 1..1
And results in the following (approximate) XML DTD and instance:
HL7 V3 Templates DRAFT Specification ver. 0.01 August 2, 2002 19
5.1.2.2 Constrain using the constraint box
HL7 V3 Templates DRAFT Specification ver. 0.01 August 2, 2002 20 Constraint: CBC Any occurence of Observation.cd="CBC" will contain: Constraint: Comprehensiv e Review o [1..1] Act_relationship.type_cd="COMP" Any occurence of DOCSECT.cd="objective" will contain: containing [1..1] Observation.cd = "HGB"; AND o [1..1] Act_relationship.cd = "COMP" containing o [0..1] Act_relationship.type_cd="COMP" [1..1] DOCSECT.cd = "PhysicalExam"; AND containing [1..1] Observation.cd = "HCT"; AND o [0..1] Act_relationship.cd = "COMP" containing o [1..1] Act_relationship.type_cd="COMP" [1..1] DOCSECT.cd = "lab". containing [1..1] Observation.cd = "PLT".
Any occurence of DOCSECT.cd="PhysicalExam" will contain: o [1..1] Act_relationship.cd = "COMP" containing [1..1] DOCSECT.cd = "VitalSigns". AR_Observation_event_component type_cd* <= COMP+OCCR context_control_cd: CS <= N+C "C" sequence_nbr*: INT priority _nbr: INT pause_qty : PQ 0..* A_Observation_event AR_Nested_component 0..1 class_cd* <= OBS type_cd *: <= COMP 0..* mood_cd *: CS <= EVN A_Section id*: II [1..1] (f iller order number) cd*: CE CWE <=ObservationType (e.g. LOINC code) class_cd* <= DOCSECT txt*: ED (f ree text describing the ev ent) mood_cd : <= EVN status_cd*: CS [0..1] cd: <= DocumentSectionType ef f ectiv e_time*: IVL
Constraint: Objectiv e section Constraint: Lab section If DOCCLIN.cd = "Comprehensive Review" then: If DOCSECT.cd = "lab" then o Must be [1..1] DOCSECT.cd = "objective" o [1..1] Observation.cd = "CBC"
This R-MIM results in the following (approximate) HMD:
ATTR DT CARD VOCAB ------A_Document class_cd CS 1..1 DOCCLIN mood_cd CS 1..1 EVN cd CE 1..1 ComprehensiveReview AR_Document_component AR 1..* type_cd CS 1..1 COMP A_Section class_cd CS 1..1 DOCSECT mood_cd CS 1..1 EVN cd CE 1..1 DocumentSectionType AR_Nested_component AR 0..* type_cd CS 1..1 COMP A_Section AR_Section_component AR 0..* type_cd CS 1..1 COMP A_Observation_event class_cd CS 1..1 OBS mood_cd CS 1..1 EVN cd CE 1..1 AR_Observation_event_component AR 0..* type_cd CS 1..1 COMP A_Observation_event 0..1 class_cd CS 1..1 OBS mood_cd CS 1..1 EVN cd CE 1..1 value ANY 1..1
And results in the following (approximate) XML DTD and instance:
HL7 V3 Templates DRAFT Specification ver. 0.01 August 2, 2002 21
Things to note include: A combination of constraints may need to be placed onto a more generic R-MIM to achieve all the requirements of a particular template. The HMD in the example using the constraint box is considerably smaller. The HMD in the example using the constraint box is less able to guide data entry. The constraints can validate instances, but may not be as useful to help in their creation.
HL7 V3 Templates DRAFT Specification ver. 0.01 August 2, 2002 22 5.1.2.3 Constrain using a tabular template representation
AR_Observation_event_com ponent type_cd* <= COMP+OCCR context_control_cd: CS <= N+C "C" sequence_nbr*: INT priority _nbr: INT pause_qty : PQ 0..* A_Observation_event AR_Nested_com ponent 0..1 class_cd* <= OBS type_cd *: <= COMP 0..* mood_cd *: CS <= EVN A_Section id*: II [1..1] (f iller order number) cd*: CE CWE <=ObservationType (e.g. LOINC code) class_cd* <= DOCSECT txt*: ED (f ree text describing the ev ent) mood_cd : <= EVN status_cd*: CS [0..1] cd: <= DocumentSectionType ef f ectiv e_time*: IVL
Comprehensive Review Template: o "objective" section (required, cannot repeat) o The "objective" section contains a "physical-exam" section (required, cannot repeat) o The "objective" section contains a "lab" section (optional, cannot repeat) o The "physical-exam" section contains a "vital-signs" section (required, cannot repeat) o The "lab" section contains a CBC observation, with the following components: o Hemoglobin (required, cannot repeat) o Hematocrit (optional, cannot repeat) o Platelet count (required, cannot repeat)
ATTR DT CARD VOCAB ------Act class_cd CS 1..1 DOCCLIN mood_cd CS 1..1 EVN cd CE 1..1 ComprehensiveReview Act_relationship AR 1..1 type_cd CS 1..1 COMP Act 1..1 class_cd CS 1..1 DOCSECT mood_cd CS 1..1 EVN cd CE 1..1 objective Act_relationship AR 1..1 type_cd CS 1..1 COMP Act 1..1 class_cd CS 1..1 DOCSECT mood_cd CS 1..1 EVN cd CE 1..1 PhysicalExam Act_relationship AR 1..1 type_cd CS 1..1 COMP Act 1..1 class_cd CS 1..1 DOCSECT mood_cd CS 1..1 EVN cd CE 1..1 VitalSigns Act_relationship AR 0..1 type_cd CS 1..1 COMP Act 1..1 class_cd CS 1..1 DOCSECT mood_cd CS 1..1 EVN cd CE 1..1 lab Act_relationship AR 1..1 type_cd CS 1..1 COMP ACT_CBC-template
HL7 V3 Templates DRAFT Specification ver. 0.01 August 2, 2002 23 The resulting HMD, XML DTD, and instances are the same as the prior example using the constraint language.
HL7 V3 Templates DRAFT Specification ver. 0.01 August 2, 2002 24 6 Glossary to be supplied
7 Appendix
7.1 Mapping external templates into the proposed structure
7.1.1 GEHR
7.1.1.1 gehr.cont.observe.foot_diabetic
Archetype Diabetic foot observation Identification GEHR identifier gehr.cont.observe.foot_diabetic Type Content Concept This archetype is a highly specialised archetype for observation of Description diabetic feet. This is designed to be used in conjunction with the Australian national diabetic database. Use For event transactions related to assessment of diabetes. Misuse Structure Content Root Content Type OBSERVATION_CONTENT Subject Self Hierarchical proposition Form Hierarchy Hierarchical group (Root) Hierarchical group (1..1) NAME Left Hierarchical value (1..1) Name Calus TYPE=PLAIN_TEXT {Absent, ANY} Hierarchical value (1..1) Name Fissures TYPE=PLAIN_TEXT {Absent, ANY} Hierarchical value (1..1) Name Nail dystrophy TYPE=PLAIN_TEXT {Absent, ANY} Hierarchical value (1..1)
HL7 V3 Templates DRAFT Specification ver. 0.01 August 2, 2002 25 Name Interdigital maceration TYPE=PLAIN_TEXT {Absent, ANY} Hierarchical value (1..1) Name Number of ulcers TYPE=NUMERIC Validation >=0 Hierarchical value (0..*) Default_name NEW VALUE TYPE= Hierarchical group (1..1) NAME Right Hierarchical value (1..1) Name Calus TYPE=PLAIN_TEXT {Absent, ANY} Hierarchical value (1..1) Name Fissures TYPE=PLAIN_TEXT {Absent, ANY} Hierarchical value (1..1) Name Nail dystrophy TYPE=PLAIN_TEXT {Absent, ANY} Hierarchical value (1..1) Name Interdigital maceration TYPE=PLAIN_TEXT {Absent, ANY} Hierarchical value (1..1) Name Number of ulcers TYPE=NUMERIC Validation >=0 Hierarchical value (0..*) Default_name NEW VALUE TYPE=ANY Hierarchical value (0..1) Name Comment TYPE=PLAIN_TEXT ANY Hierarchical value (0..*) Default_name NEW VALUE TYPE=ANY Protocol Hierarchical proposition (Optional) Form List Hierarchical Value (0..1) Default name NEW VALUE
HL7 V3 Templates DRAFT Specification ver. 0.01 August 2, 2002 26 TYPE=TEXT
AR_Observation_event_com ponent type_cd* <= COMP+OCCR context_control_cd: CS <= N+C "C" sequence_nbr*: INT priority _nbr: INT pause_qty : PQ 0..* A_Observation_event
0..1 class_cd* <= OBS mood_cd *: CS <= EVN id*: II [1..1] (f iller order number) cd*: CE CWE <=ObservationType (e.g. LOINC code) txt*: ED (f ree text describing the ev ent) status_cd*: CS [0..1] ef f ectiv e_time*: IVL
gehr.cont.observe.foot_diabetic template:
ATTR DT CARD VOCAB ------Observation class_cd CS 1..1 OBS mood_cd CS 1..1 EVN cd CE 1..1 DiabeticFootEvaluation target_site_cd CE 1..1 LeftFoot Act_relationship AR 1..1 type_cd CS 1..1 COMP Observation 1..1 class_cd CS 1..1 OBS mood_cd CS 1..1 EVN cd CE 1..1 Calus Act_relationship AR 1..1 type_cd CS 1..1 COMP Observation 1..1 class_cd CS 1..1 OBS mood_cd CS 1..1 EVN cd CE 1..1 Fissures Act_relationship AR 1..1 type_cd CS 1..1 COMP Observation 1..1 class_cd CS 1..1 OBS mood_cd CS 1..1 EVN cd CE 1..1 NailDystrophy Act_relationship AR 1..1 type_cd CS 1..1 COMP Observation 1..1 class_cd CS 1..1 OBS mood_cd CS 1..1 EVN cd CE 1..1 InterdigitalMaceration Act_relationship AR 1..1 type_cd CS 1..1 COMP Observation 1..1 class_cd CS 1..1 OBS mood_cd CS 1..1 EVN
HL7 V3 Templates DRAFT Specification ver. 0.01 August 2, 2002 27 cd CE 1..1 NumberOfUlcers
Things to note include: This is a simplified representation of the GEHR archetype, and doesn’t capture all constraints. Template is applied to same basic pattern used in the CBC example.
7.1.2 3M Information Model
7.1.2.1 BirthWeightObs BirthWeightObs ::= PatientObservation (WCS { obsId (RCodedTerm (BirthWeight)), obsValue (WCS{ att (WCS{ numericOperator OPTIONAL, precision ("%4.0d"), value (WCS {decimal}), units (WCS ({Grams})) }) }), abnFlag (RCodedDomain (NumericAbnormal)) OPTIONAL, deltaFlag (RCodedDomain (NumericDelta)) OPTIONAL, refRange OPTIONAL, status OPTIONAL, comments (RComments (PatObsComment)) OPTIONAL })
AR_Observation_event_com ponent type_cd* <= COMP+OCCR context_control_cd: CS <= N+C "C" sequence_nbr*: INT priority _nbr: INT pause_qty : PQ 0..* A_Observation_event
0..1 class_cd* <= OBS mood_cd *: CS <= EVN id*: II [1..1] (f iller order number) cd*: CE CWE <=ObservationType (e.g. LOINC code) txt*: ED (f ree text describing the ev ent) status_cd*: CS [0..1] ef f ectiv e_time*: IVL
Birth weight observation template:
ATTR DT CARD VOCAB ------Observation class_cd CS 1..1 OBS mood_cd CS 1..1 EVN cd CE 1..1 BirthWeight status_cd CS 0..1 value PQ 1..1 interpretation_cd CS 0..1 txt ED 0..1
HL7 V3 Templates DRAFT Specification ver. 0.01 August 2, 2002 28 Things to note include: Many existing templates are largely going to be just constraints on existing patterns. Not sure I know what all the components of the 3M constraints mean – so this example is not 100% accurate.
7.1.3 Mayo Foundation
7.1.3.1 Vital Signs The Mayo Foundation Vital Signs section of a clinical note is highly structured, and comprised of the following components:
ACT.cd coded w/ LOINC
ACT.effective_time applies to all entries in the column.
Observation.value first is metric, second is in English units.
Mayo Foundation Vital Signs template:
ATTR DT CARD VOCAB ------Observation class_cd CS 1..1 OBS mood_cd CS 1..1 EVN cd CE 1..1 VitalSigns effective_time TS 1..1 Act_relationship AR 1..1 type_cd CS 1..1 COMP Observation 1..1 class_cd CS 1..1 OBS mood_cd CS 1..1 EVN cd CE 1..1 Height Act_relationship AR 1..1 type_cd CS 1..1 COMP Observation 1..1 class_cd CS 1..1 OBS mood_cd CS 1..1 EVN
HL7 V3 Templates DRAFT Specification ver. 0.01 August 2, 2002 29 cd CE 1..1 Weight Act_relationship AR 1..1 type_cd CS 1..1 COMP Observation 1..1 class_cd CS 1..1 OBS mood_cd CS 1..1 EVN cd CE 1..1 BMI Act_relationship AR 1..1 type_cd CS 1..1 COMP Observation 1..1 class_cd CS 1..1 OBS mood_cd CS 1..1 EVN cd CE 1..1 BSA Act_relationship AR 1..1 type_cd CS 1..1 COMP Observation 1..1 class_cd CS 1..1 OBS mood_cd CS 1..1 EVN cd CE 1..1 Temperature Act_relationship AR 0..1 type_cd CS 1..1 COMP Observation 1..1 class_cd CS 1..1 OBS mood_cd CS 1..1 EVN cd CE 1..1 HeadCircumference Act_relationship AR 1..1 type_cd CS 1..1 COMP Observation 1..1 class_cd CS 1..1 OBS mood_cd CS 1..1 EVN cd CE 1..1 Pulse ...
Things to note include: Mayo needs to constrain to a particular coding scheme (e.g. LOINC). Mayo needs to constrain to a particular unit of measure (metric vs. English)
HL7 V3 Templates DRAFT Specification ver. 0.01 August 2, 2002 30 8 Open Issues
8.1 Relationship between templates, template architecture Rules of extensibility for templates and the mechanism by which this will be implemented within the v3 methodology.
Need further thought about a “template architecture”. How for instance to know that one template is a specialization of another? Also, because of multiple potential contributors, it is possible that a “CDA Level 3 Cardiology Progress Note” template is not necessarily a specialization of a “CDA Level 2 Cardiology Progress Note” template submitted by some other organization. This architecture may be manually specified and/or possibly computed.
LRM: By extensibility, do you mean the ability to define one template that is based on another (open) template that adds additional elements? I suspect some of this will be resolved in the discussion on open vs. closed. There shouldn't be too much difficulty extending open templates. Some examples of what you'd like to do with extension would be good.
BD: not sure what is meant here by “extensibility”, especially since we’ve said that templates can only constrain balloted specifications.
TB: The thing to consider most closely here are compatibility of data created using different templates.
BD: How do we accommodate thousands of templates, to identify relationships and overlaps among them?
8.2 Relationship to data entry . Will the described template approach enable the complete expression (and creation) of data entry templates? . Need to understand the difference between the representation of a data-entry template shown to a clinician (e.g. a form they are to fill in) vs. the underlying canonical representation of that template vs. the representation of the data after it has been filled out and sent to a repository. (How much of the template is stored in the final instance? Will it point to the template and/or will it store all the choices that the provider may have been able to choose from?)
TB: Yes – this is important. One screen form might easily correspond to half a dozen templates behind the scenes. .
8.3 The term “template” . We should consider referring to these as “archetypes” rather than “templates”
8.4 Named paths . Thomas Beale suggests the need for named paths within a template. Need further clarity on these.
HL7 V3 Templates DRAFT Specification ver. 0.01 August 2, 2002 31