Glossary

Editor Various Contributors
HL7 Publishing Work Group

Content Last Edited: 2007-03-27T13:54:37


Table of Contents

2.1  A
2.2  B
2.3  C
2.4  D
2.5  E
2.6  F
2.7  G
2.8  H
2.9  I
2.10  J
2.11  K
2.12  L
2.13  M
2.14  N
2.15  O
2.16  P
2.17  Q
2.18  R
2.19  S
2.20  T
2.21  U
2.22  V
2.23  W
2.24  X
2.25  Y
2.26  Z

 1 Introduction to the Glossary

The HL7 Glossary provides "core" definitions of words and terms used throughout HL7 standards and documents. These definitions are maintained by the Modeling and Methodology (MnM) and Publishing Technical Committees (TC) and are identified in the glossary as "Core Glossary".

It should be noted that while the Modeling and Methodology and Publishing Technical Committees maintain the glossary definitions, the definitions themselves originate from within the various technical committees and special interest groups and are not constrained or vetted in any way by the MnM or Publishing TCs. It is expected that each committee and its balloters know their business best and that, should an imprecise or incorrect definition be put forward, it will be corrected through the domain balloting process.

It should further be noted that this glossary does not include all the definitions from the Reference Information Model (RIM) as the RIM definitions are already available in the RIM publication and are in context there.

Readers may also note that "core" definitions may be constrained or narrowed within the context of specific domains. For instance, the PM domain includes a definition for Person that is constrained from the RIM definition of Person. In these cases, the PM:Person is perfectly consistent with the RIM:Person, albeit as a specialized subset of the larger group. So while all instances of a PM:Person will also be members of RIM:Persons, not all instances of RIM:Person will fall within the group of PM:Persons.

The MnM and Publishing TCs encourage all members to review the definitions put forward by committees as part of the balloting process with an eye towards correcting and refining them as necessary and appropriate.

 2 Alphabetic Index
 2.1 A
Acuity

Defined in Clinical Decision Support: Acuity is a metadata string which denotes the chronicity of the setting for order set employment. Options include
  • Acute
  • Chronic
  • Emergency

OrderSet.precondition.Criterion.code

annotation

Core Glossary: A note following a Domain Message Information Model (DMIM) diagram that explains the DMIM or the modeling behind the DMIM.

ANSI

Core Glossary: American National Standards Institute

application

Core Glossary: A software program or set of related programs that provide some useful healthcare capability or functionality.

application role

Core Glossary: An abstraction that expresses a portion of the messaging behavior of an information system.

artifact

Core Glossary: Any deliverable resulting from the discovery, analysis, and design activities leading to the creation of message specifications.

association

Core Glossary: A reference from one class to another class or to itself, or a connection between two objects (instances of classes).

For more information refer to the Relationships section of the Version 3 Guide.

association composition

Core Glossary: See composite aggregation

association role name

Core Glossary: A name for each end of an association. The name is a short verb phrase depicting the role of the class at the opposite end of the association from the perspective of the class adjacent to the role.

attribute

Core Glossary: An abstraction of a particular aspect of a class. Attributes become the data values that are passed in HL7 messages.

For more information refer to the Attributes section of the Version 3 Guide.

attribute type

Core Glossary: A classifier for the meaning of an attribute. In HL7 Version 3, attribute type is indicated by a suffix added to the attribute name.

(Return to glossary index)
 2.2 B
bag

Core Glossary: A form of collection whose members are unordered, and need not be unique.

blank

Core Glossary: One of the allowed values for conformance requirements. Blank means that conformance for this element is to be negotiated on a site-specific basis.

Boolean collective

Defined in Clinical Decision Support: Boolean collective [BooleanCollective; AND, OR, XOR supported] is a feature of order set specification layer III which identifies named sets of orders (collectives) to be manipulated and controlled at time of order set presentation. This supports menu options which may enforce exclusivity/concurrency of order set item at the time of order session processing.

The implicit assumption of order set construction is that all order items by default may be selected by the clinician as independent choices. Hence the usual case is that each order item within an order set is linked by an inclusive OR (any item or no item may be selected). Boolean collectives may override this default at order selection and allows adjacent order items within the order set to be required for selection as a group, or individually. All order set items flagged as AND will be required to be selected as a unit or not at all. All items flagged as XOR will require selection of at most of a single item from the group at time of order selection.

When employed by decision enabled (layer IV) systems, this feature supports the identification of a set of order items from the order set which serve a common purpose for clinical decision support. All order items within a collective may be manipulated 'en bloc', supporting alerts, manipulation of pre-selection flags, and other presentation features which enhance the decision support features of order sets.

(Return to glossary index)
 2.3 C
cardinality

Core Glossary: Property of a data element (the number of times a data element MAY repeat within an individual occurrence of an object view) or column in the Hierarchical Message Description (the minimum and maximum number of occurrences of the message element).

Care plan

Defined in Clinical Decision Support: A Care plan is an ordered assembly of expected or planned Acts, in Definitional mood, including observations, services, appointments, procedures and setting of goals, usually organized in phases or sessions, which have the objective of organizing and managing health care activity. Care plans are often focused upon on or more health care problems, with the expectation of one or more favourable outcomes. Care plans may include orders sets as actionable elements, usually supporting a single session or phase

MESH (1968, NLM): N 04.590.233.624 Patient care planning - "Usually a written medical and nursing care program designed for a particular patient."

Character Data

Core Glossary: Text in a particular coding (e.g., ASCII), as distinguished from binary data.

choice

Core Glossary: A message construct that includes alternative portions of the message. For a choice due to specialization, the sender picks one of the alternatives and sends it along with a flag.

choice due to specialization

Core Glossary: A choice that arises when a Hierarchical Message Description includes (a) an object view which is associated with a class that is a superclass of two or more object views, or (b) an object view which is a superclass of one or more object views and MAY itself be instantiated. Under this circumstance different message instances MAY contain different object views. The choice structure is used to accommodate the alternatives.

class

Core Glossary: An abstraction of a thing or concept in a particular application domain.

For more information refer to the Classes section of the Version 3 Guide.

classifier attribute

Core Glossary: An attribute used in generalization hierarchies to indicate which of the specializations is the focus of the class .

For more information refer to the Attributes section of the Version 3 Guide.

clone

Core Glossary: A class from the Reference Information Model (RIM) that has been used in a specialized context and whose name differs from the RIM class from which it was replicated. This makes it possible to represent specialized uses of more general classes to support the needs of messaging.

CMET

Core Glossary: See Common Message Element Type.

CMET Message Information Model

Core Glossary: A form of Refined Message Information Model (RMIM) constructed to represent the totality of concepts embodied in the individual RMIMs needed to support the definition of HL7's Common Message Element Types.

CMIM

Core Glossary: See CMET Message Information Model.

coded attribute

Core Glossary: An attribute in the Reference Information Model (RIM) with a base data type of CD, CE, CS, or CV.

coding strength

Core Glossary: An extensibility qualifier that specifies whether or not a code set can be expanded to meet local implementation needs.

coding system

Core Glossary: A scheme for representing concepts using (usually) short concept identifiers to denote the concepts that are members of the system; defines a set of unique concept codes. Examples of coding systems are ICD-9, LOINC and SNOMED.

collection

Core Glossary: An aggregation of similar objects. The forms of collection used by HL7 are set , bag, and list. Objects which MAY be found in collections include data types and message element types.

common message element type (CMET)

Core Glossary: A message type in a Hierarchical Message Description (HMD) that MAY be included by reference in other HMD's.

For more information refer to the Common Message Element Types section of the Version 3 Guide.

composite aggregation

Core Glossary: A type of association between objects, indicating a whole-part relationship.

composite data type

Core Glossary: A data type assigned to a message element type that contains one or more components, each of which is represented by an assigned data type.

composite message element type

Core Glossary: A message element type that contains subordinate heterogeneous message types.

concept identifier

Core Glossary: A unique identification assigned to a concept by the HL7 organization.

conformance claim

Core Glossary: A specification written by HL7 to precisely define the behavior of an application with respect to its HL7 interfaces, and which MAY be designated functional or technical. A functional conformance claim is simply a statement that an application conforms to a particular application role. A technical conformance claim (also referred to as a Technical Statements of Performance Criteria) defines the behavior of an application in some other sense than the messages it sends or receives. This MAY include the Implementation Technology Specifications that it supports, the use of specific optional protocols or character sets, or many other behaviors.

conformance claim set

Core Glossary: A list of the identifiers of specific HL7 conformance claims, used by a sponsor to describe the conformance of its application.

conformance requirement

Core Glossary: A column in the Hierarchical Message Description (HMD) that designates whether the system SHALL communicate an attribute's value if a value is available. Allowed values are required (must be included), not required (may be left out) or not permitted (may never be included.) Items listed as not required in the HL7 specification SHALL be declared by a vendor as either required or not permitted when a conformance claim is asserted for that message type.

conformance verb

Core Glossary: In HL7 Version 3 Specifications, the correct verb form for indicating a requirement is "SHALL." The correct verb form for indicating a recommendation is "SHOULD." The correct verb form for an option is "MAY."

Universally accepted standardization terminology does not recognize "must". Use "SHALL" to indicate a mandatory aspect or an aspect on which there is no option.

The negatives are SHALL NOT, SHOULD NOT, MAY NOT.

The Publishing Facilitator's Guide requires the Conformance Verbs to be capitalized when they are used to indicate conformance criteria, to differentiate from common usage of the words.

The source for this usage is ANSI.

connection

Core Glossary: In an information model, a specified relationship between two classes .

constraint

Core Glossary: Narrowing down of the possible values for an attribute; a suggestion of legal values for an attribute (by indicating the data type that applies, by restriction of the data type, or by definition of the domain of an attribute as a subset of the domain of its data type). MAY also include providing restrictions on data types. A constraint imposed on an association MAY limit the cardinality of the association or alter the navigability of the association (direction in which the association can be navigated). A Refined Message Information Model (RMIM) class MAY be constrained by choosing a subset of its Reference Information Model (RIM) properties (i.e., classes and attributes) or by cloning, in which the class’ name is changed.

For more information refer to the Constraints section of the Version 3 Guide.

control event wrapper

Core Glossary: A wrapper that contains domain specific administrative information related to the "controlled event" which is being communicated as a messaging interaction. The control event wrapper is used only in messages that convey status, or in commands for logical operations being coordinated between applications (e.g., the coordination of query specification/query response interactions).

coupling

Core Glossary: 1. An interaction between systems or between properties of a system.

Core Glossary: 2. With regard to application roles , refers to whether or not additional information about the subject classes participating in a message may be commonly available to system components outside of the specific message.

(Return to glossary index)
 2.4 D
data type

Core Glossary: The structural format of the data carried in an attribute. It MAY constrain the set of values an attribute may assume.

For more information refer to the Data Types section of the Version 3 Guide.

default value

Core Glossary: In HL7 messages, the value for an attribute that is to be used by message receivers if no value is given.

distal class

Core Glossary: From the perspective of a class in an information model, it is the class at the opposite end of an association between the two.

DMIM

Core Glossary: See Domain Message Information Model.

domain

Core Glossary: 1. A particular area of interest. For example, the domain for HL7 is healthcare.

Core Glossary: 2. The set of possible values of a data type , attribute, or data type component. See also vocabulary domain .

Core Glossary: 3. A special interest group within HL7, such as Pharmacy, Laboratory, or Patient Administration.

domain expert

Core Glossary: An individual who is knowledgeable about the concepts in a particular problem area within the healthcare arena and/or is experienced with using or providing the functionality of that area.

Domain Message Information Model

Core Glossary: A form of Refined Message Information Model (RMIM) constructed to represent the totality of concepts embodied in the individual RMIMs needed to support the communication requirements of a particular HL7 domain.

For more information refer to the Information Model section of the Version 3 Guide.

domain name

Core Glossary: The name assigned to a vocabulary domain.

domain specification

Core Glossary: The specification of a vocabulary domain.

(Return to glossary index)
 2.5 E
entry point

Core Glossary: The point at which a Common Message Element Type (CMET) is inserted into a Refined Message Information Model (RMIM).

event

Core Glossary: 1. A stimulus that causes a noteworthy change in the state of an object, or a signal that invokes the behavior of an object. See also trigger event.

Core Glossary: 2. A vocabulary domain value for Mood.

extensibility qualifier

Core Glossary: A vocabulary domain qualifier used in a domain specification, which indicates whether or not the existing vocabulary domain can be extended with additional values. There are two possible values: CNE (coded, no extension) and CWE (coded with extension).

For more information refer to the Vocabulary Domain Qualifiers section of the Version 3 Guide.

Extensible Markup Language

Core Glossary: A meta-language that defines a syntax used to define other domain -specific, semantic, structured markup languages. Based on SGML (Standard Generalized Markup Language), it consists of a set of rules for defining semantic tags used to mark up the content of documents. Abbreviated as XML.

(Return to glossary index)
 2.6 F
Full Text Order

Defined in Clinical Decision Support: Full text order will be a complete textual description of the order, observation or goal including purpose, instructions, frequency, priority, repetitions, etc. All order set items with a full text description but a "null" order set specification layer will be considered non-actionable by the order session, will be descriptive only and will function as comments to the user when an order set is displayed during order processing.

function point

Core Glossary: Any function, user transaction, or other interaction or event in the sponsor’s application which, when it occurs, does or may correspond to an HL7 trigger event. Used to describe the conformance of an information system with the HL7 standard.

(Return to glossary index)
 2.7 G
generalization

Core Glossary: An association between two classes, referred to as superclass and subclass, in which the subclass is derived from the superclass. The subclass inherits all properties from the superclass, including attributes, relationships, and states, but also adds new ones to extend the capabilities of the parent class. Essentially, a specialization from the point-of-view of the subclass.

For more information refer to the Relationships section of the Version 3 Guide.

generalization hierarchy

Core Glossary: All superclasses and subclasses with a common root superclass.

graphical expression

Core Glossary: A visual representation of a model that uses graphic symbols to represent the components of the model and the relationships that exist between those components.

grid view

Core Glossary: A complete view of the message type definition, which, due to its size, is presented in a scrollable format.

(Return to glossary index)
 2.8 H
Hierarchical Message Description

Core Glossary: A specification of the exact fields of a message and their grouping, sequence, optionality, and cardinality. This specification contains message types for one or more interactions, or that represent one or more common message element types. This is the primary normative structure for HL7 messages.

HMD

Core Glossary: See Hierarchical Message Description.

HTML

Core Glossary: Hypertext Markup Language, a specification of the W3C that provides markup of documents for display in a web browser

(Return to glossary index)
 2.9 I
identifier attribute

Core Glossary: An attribute used to identify an instance of a class.

For more information refer to the Attributes section of the Version 3 Guide.

implementation technology

Core Glossary: A technology selected for use in encoding and sending HL7 messages. For example, XML is being used as an implementation technology for Version 3.

Implementation Technology Specification

Core Glossary: A specification that describes how HL7 messages are sent using a specific implementation technology . It includes, but is not limited to, specifications of the method of encoding the messages, rules for the establishment of connections and transmission timing and procedures for dealing with errors.

For more information refer to the Implementation Technology Specifications section of the Version 3 Guide.

inclusion

Core Glossary: The specification in the Hierarchical Message Description indicating whether an element of a message type MAY be null in some message instances. Contrast this with conformance.

information model

Core Glossary: A structured specification, expressed graphically and/or narratively, of the information requirements of a domain. An information model describes the classes of information required and the properties of those classes, including attributes, relationships, and states. Examples in HL7 are the Domain Reference Information Model,Reference Information Model, and Refined Message Information Model.

For more information refer to the Information Model section of the Version 3 Guide.

inheritance

Core Glossary: In a generalization relationship, the subclass inherits all properties from the superclass, including attributes, relationships, and states, unless otherwise specified.

instance

Core Glossary: A case or an occurrence. For example, an instance of a class is an object.

interaction

Core Glossary: A single, one-way information flow that supports a communication requirement expressed in a scenario.

interaction diagram

Core Glossary: A graphical representation of communications between application roles. An interaction diagram may also be referred to as a ladder diagram, sequence diagram, or storyboard interaction diagram.

interaction list

Core Glossary: A list of the interactions that appear in an interaction diagram.

interaction model

Core Glossary: A specification of the responsibilities of message senders and receivers.

interaction narrative

Core Glossary: A narrative description of each interaction contained in an interaction list .

internal data type

Core Glossary: An HL7 data type defined to support the definition of other data types, but which may not be assigned as the type for a data field itself.

interoperability

Core Glossary: In this context, interoperability refers to the ability of two or more computer systems to exchange information.
  • Main Entry: in·ter·op·er·a·bil·i·ty
    • Function: noun
    • Date: 1977
    • ability of a system (as a weapons system) to use the parts or equipment of another system
    • Source: Merriam-Webster web site
  • interoperability
    • ability of two or more systems or components to exchange information and to use the information that has been exchanged.
    • Source: IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, IEEE, 1990

“Functional” interoperability is the capability to reliably exchange information without error

“Semantic" interoperability is the ability to interpret, and, therefore, to make effective use of the information so exchanged.

In our context, "effective use" means that the information can be used in any type of computable algorithm (appropriate) to that information

Is Personal

Defined in Clinical Decision Support: Is Personal is a data flag indicating whether the order set is institutional (Boolean false) or owned by an individual (Boolean true)

ITS

Core Glossary: See Implementation Technology Specification.

(Return to glossary index)
 2.10 J
joint state

Core Glossary: A summarization of multiple partial states in a state machine.

(Return to glossary index)
 2.11 K
 2.12 L
ladder diagram

Core Glossary: See interaction diagram.

life cycle

Core Glossary: See state machine.

LIFO

Core Glossary: Last in-first out. See push-down stack.

list

Core Glossary: A form of collection whose members are ordered, and need not be unique.

literary expression

Core Glossary: A representation of a model in text. The literary expression seeks to balance the need for a rigorous, unambiguous description of the model with the need for a rendition that can be easily read and interpreted by individuals who understand the general concepts underlying object-oriented models, but who may not be schooled in formal model definition languages.

LOINC

Core Glossary: Logical Observations, Identifiers, Names, and Codes

loosely coupled

Core Glossary: Loosely coupled application roles do not assume that common information about the subject classes participating in a message is available to system components outside of the specific message.

(Return to glossary index)
 2.13 M
mandatory

Core Glossary: If an attribute is designated as mandatory, all message elements which make use of this attribute SHALL contain a non-null value or they SHALL have a default that is not null. This requirement is indicated in the "mandatory" column in the Hierarchical Message Description.

mandatory association

Core Glossary: An association with a multiplicity minimum greater than zero on one end. A fully mandatory association is one with a multiplicity minimum greater than zero on both ends.

markup

Core Glossary: Computer-processable annotations within a document. Markup encodes a description of a document’s storage layout and logical structure. In the context of HL7 Version 3, markup syntax is according to the XML Recommendation.

Master Files

Core Glossary: Common lookup tables used by one or more application systems.

MAY

Core Glossary: The conformance verb MAY is used to indicate a possibility. See the conformance verb definition for more information.

MDF

Core Glossary: See Message Development Framework.

message

Core Glossary: A package of information communicated from one application to another. See also message type and message instance.

Message Development Framework

Core Glossary: The collection of models, methods, and tools that comprise the methodology for specifying HL7 Version 3 messages. This framework is used by the developers of the HL7 standards.

message element

Core Glossary: A unit of structure within a message type.

message element type

Core Glossary: A portion of a message type that describes one of the elements of the message.

message instance

Core Glossary: A message, populated with data values, and formatted for a specific transmission based on a particular message type.

message payload

Core Glossary: Data carried in a message.

message type

Core Glossary: A set of rules for constructing a message given a specific set of instance data. As such, it also serves as a guide for parsing a message to recover the instance data.

meta-model

Core Glossary: A model used to specify other models. For example, the meta-model for a relational database system might specify elements of type ‘Table’, ‘Record’, and ‘Field.’.

methodology

Core Glossary: Methods or rules followed in a particular discipline.

MIME

Core Glossary: Multipurpose Internet Mail Extensions (MIME, RFC 2046)

model

Core Glossary: A representation of a domain that uses abstraction to express the relevant concepts. In HL7, the model consists of a collection of schema and other documentation.

multiplicity

Core Glossary: 1. In the information model, multiplicity is a specification of the minimum and maximum number of objects from each class that can participate in an association. Multiplicity is specified for each end of the association.

Core Glossary: 2. In the Hierarchical Message Description (HMD), multiplicity depicts the minimum and maximum number of occurrences of a message element expression in a collection.

(Return to glossary index)
 2.14 N
navigability

Core Glossary: Direction in which an association can be navigated (either one way or both ways).

not permitted

Core Glossary: One of the allowed values in conformance requirements. Abbreviated as NP, it means that the message element is never sent for that message type.

null

Core Glossary: A value for a data element which indicates the absence of data. A number of “flavors” of null are possible and are enumerated in the domain NullFlavor.

(Return to glossary index)
 2.15 O
object

Core Glossary: An instance of a class. A part of an information system containing a collection of related data (in the form of attributes) and procedures (methods) for operating on that data.

For more information refer to the Classes section of the Version 3 Guide.

object-based

Core Glossary: Any method, language, or system that supports object identity, classification, and encapsulation. An object-based system does not support specialization . Ada is an example of an object-based implementation language.

object identifier

Core Glossary: A scheme to provide globally unique identifiers. This object identifier (OID) scheme is an ISO standard (ISO 8824:1990), and has been adopted as a CSA standard (Z243.110).

The HL7 OID Registry is available online.

object identity

Core Glossary: The feature that the existence of an object is independent of any values associated with the object.

obsolescent message type

Core Glossary: A message type that has been marked for deletion in a future version of HL7.

obsolete message type

Core Glossary: A message type, previously declared obsolescent, that has been removed or replaced in a particular version of HL7.

OID

Core Glossary: See object identifier.

optional

Core Glossary: See inclusion.

Order Alerting text

Defined in Clinical Decision Support: Order alerting text is a text message which is displayed as an informational item with an order set item at the time of the order session. The alerting text may be a static element of the order set or may be dynamically populated at the initiation of the order session by a decision support program.

Order Display Group

Defined in Clinical Decision Support: Order display group is a textual category linked to each order set item; vendor software employs these tags to organize and display orders with similar actions or intent within an order set for ease of clinical browsing and to aid understanding and order selection. They may express intent, such as "Diagnostic" or "Treatments", or be organizational in nature, such as "Laboratory" or "Radiology".

Order Item Code

Defined in Clinical Decision Support: Order item code is the coded data attribute of the definitional order ACT which is requested, or is the object of the goal or observation for a particular order item within an order set

Order Medication Code

Defined in Clinical Decision Support: Medication or treatment is the coded attribute of a medication order which specifies the pharmaceutical or medical treatment to be administered to the patient.

Order Medication Route Code

Defined in Clinical Decision Support: Medication route is a coded data attribute of a medication order which identifies the route of administration of an ordered pharmaceutical treatment .

Order Preselection Flag

Defined in Clinical Decision Support: Order pre-selection flag - (answers the question: should this order item be pre-selected at time of order processing: choices = YES, NO or MANDATORY (REQUIRED)) is a data flag that determines whether this order set item will be pre-selected, de-selected or required at the time an order session is begun. Orders considered central to a protocol will be pre-selected, while optional and infrequent orders will be deselected at the time the order session is begun. Mandatory should be used only with caution in selected cases.

Order Priority

Defined in Clinical Decision Support: Order priority is the coded attribute which specifies the urgency or immediacy of the particular requested ACT.

Order Repetition

Defined in Clinical Decision Support: Order repetition specifies the number of acts to be performed within the scope of the particular order item.

Order Sanction Decision Logic

Defined in Clinical Decision Support: Order sanction decision logic is a decision criterion or knowledge construct which may employ patient record data in order to sanction (remove) an order set item in an order set at the time an order session is active.

Order Sequence Number

Defined in Clinical Decision Support: Order sequence number is an integer indicating the placement of this order set item within the order set.

Order Session

Defined in Clinical Decision Support: Order session is a Clinical Information System program function which supports a clinician through the process of order selection, order confirmation, order authentication and processing. The order session is not a focus of this standard which is oriented toward the publication of the order set knowledge.

Order set

Defined in Clinical Decision Support: "An order set is a pre-filled ordering template, or electronic protocol that is derived from evidence based best practice guidelines." (1) In the article proposing this definition, the authors provide a cursory description of their methodology and data structure. "Once a guideline is accepted, the contents of the guidelines are translated into a workflow that can then be adapted into one or more order sets and automated through the computerized provider order entry (CPOE) system."

"Each record in the table represents one order and contains all high level information about the order such as, order description, department, type of order, frequency, dose, order entry date, etc. This table also houses essential, frequently used attributes needed in order set analysis such as order set name, ordering health care professional, the patients current clinical service and patient location at the time the order set was placed."

The electronic health record interest group of HL-7 has recently published a proposed electronic health record functional description. They state order sets "support delivery of effective healthcare", improve efficiency, facilitate management of chronic conditions, and improve patient safety. They provide the following functional description of order sets: "Order sets allow a care provider to choose common orders for a particular disease state or circumstance according to best practice criteria for assembling the order set without having to generate each order individually. The EHR may recommend order sets in certain conditions or as the result of other clinical information being entered into the EHR. Or the order sets may simply be available for use by the ordering care provider."

An order set is not merely a collection of orders. The collection of proposed acts within the order set has been developed and edited to promote consistent and effective organization of health care activity.

(1) Kamal J, Rogers P, Saltz J, Mekhjian HS. Information Warehouse as a Tool to Analyze Computerized Physician Order Entry Order Set Utilization: Opportunities for Improvement. In: AMIA 2003 Symposium Proceedings; 2003; Washington, DC; 2003. p. 336-41.

Order Set Dates

Defined in Clinical Decision Support: Creation date]is the date the order set was created

Date of Last Review is the date of last order set review for content

Date Valid Until the order set is valid for use until this date

Date last edited is the date the order set was last reviewed or modified

Order Set Header

Defined in Clinical Decision Support: Order set Header Each order set has a single header which identifies the order set, specifies the patient population for whom the order set is useful, links the order set to the guideline problem of focus, identifies the protocol session whose management this supplements, and contains editorial information for authorship and metadata to support proper maintenance.

Order Set Item

Defined in Clinical Decision Support: Order set item is the recurring element of the order body. It consists of the full RIM compliant definition of an Order, Medication order, Observation or Goal to be employed in the order set. It may also be a pointer to another order set, allowing the nesting of order sets within order sets.

Order Set Key

Defined in Clinical Decision Support: Order set key uniquely defines an order set and may be employed to nest an order set as an order set item within another order set

Order set milestones

Defined in Clinical Decision Support: Order set milestones are implementation objectives with associated target and actual completiopn dates that are included with order set metadata summarizing institutional records of development, implementation and use of the order set

Order Set Owner

Defined in Clinical Decision Support: Owner is an unique identifier for the clinical author responsible for this order set document instance.

Order Set Population

Defined in Clinical Decision Support: Order set population defines the set of coded restrictions (age, gender and other patient characteristics) which specify the group of patients appropriate for the effective clinical use of this order set. Order set population consists of one or more precondition criteria that provides a computable determination whether an order set should be employed in the care of a specific patient.

Order Set Problem Code

Defined in Clinical Decision Support: Order set problem code is the terminological concept (semantic class is finding or disorder, eg from SNOMED CT) which identifies the clinical focus of this order set and the associated protocol or care plan. A protocol may be modeled in part as a sequence of order sessions during which appropriate order sets are employed, generally linked by the problem focus of the protocol.

Order Set Session Code

Defined in Clinical Decision Support: Order set session code is the concept code (semantic class is procedure, eg from SNOMED CT) defining the order session within the larger episode of a protocol, care plan or guideline. Examples include SNOMED CT - 32485007 "Admission to hospital" or SNOMED CT - 37894004 "Evaluation & Management new outpatient".

Order Set Title

Defined in Clinical Decision Support: Order Set Title is a descriptive name for this order set document instance.

Order Set Version

Defined in Clinical Decision Support: Version is an alpha numeric string denoting current version designation of the order set document instance.

(Return to glossary index)
 2.16 P
partial state

Core Glossary: Part of a state machine. A state machine MAY have multiple partial states effective at the same time; the multiple partial states can be summarized to one joint state of the state machine.

predicate reference

Core Glossary: In the Hierarchical Message Description, a message element that is referred to in the predicate defining the conditional presence of another message element.

primitive data type

Core Glossary: A data type that is defined as a single entity, and whose full semantic is contained in its definition.

primitive message element type

Core Glossary: A message element type that contains a single datum, with no subordinate components. Examples include String and Number.

property

Core Glossary: 1. Any attribute, association, method, or state model defined for a class or object.

Core Glossary: 2. In a Hierarchical Message Description (HMD), the column that states the name of the class, attribute or association role name as it appears in the Reference Information Model (RIM).

push-down stack

Core Glossary: Also known as a “last in-first out” (LIFO) list, a list maintained by a Technical Committee as it analyses the Refined Message Information Model (RMIM) and builds a Hierarchical Message Description, in which the last class added is always the first class removed. (A metaphoric reference to the spring-loaded plate carriers used in institutional dining halls, where the new plates added to the top of the stack push down the earlier plates, so the newest plate is taken off the stack first).

(Return to glossary index)
 2.17 Q
query

Core Glossary: Queries are the primary mechanism for retrieving information from computer systems. Many database management systems use the Structured Query Language (SQL) standard query format.

(Return to glossary index)
 2.18 R
realm

Core Glossary: A vocabulary domain qualifier used in a domain specification, which allows the vocabulary domain of a coded attribute to be specialized according to the geographical, organizational, or political environment where the HL7 standard is being used.

For more information refer to the Vocabulary Domain Qualifiers section of the Version 3 Guide.

receiver responsibility

Core Glossary: An obligation on an application role that receives an interactionas defined in the interaction model.

recursion

Core Glossary: An association that leads from a class directly or indirectly back to that class.

Reference Information Model

Core Glossary: The HL7 information model from which all other information models (e.g., RMIMs) and messages are derived.

For more information refer to the Information Model section of the Version 3 Guide.

Refined Message Information Model

Core Glossary: An information structure that represents the requirements for a set of messages. A constrained subset of the Reference Information Model (RIM) which MAY contain additional classes that are cloned from RIM classes. Contains those classes, attributes, associations, and data types that are needed to support one or more Hierarchical Message Descriptions (HMD). A single message can be shown as a particular pathway through the classes within an RMIM.

For more information refer to the Information Model section of the Version 3 Guide.

Replaces Order Set

Defined in Clinical Decision Support: Replaces order set is a link to the identifier of an earlier order set which is now superseded by the current order set document instance.

required

Core Glossary: One of the allowed values in conformance requirements. Abbreviated as R, it means that the message elements SHALL appear every time that particular message type is used for an interaction. If the data is available, the element SHALL carry the data, otherwise a blank MAY be sent.

Resource Link

Defined in Clinical Decision Support: Resource link is an embedded web services URL attached to the order, the order dislay group or the order set header which can direct web software to information services relevant to the clinical situation at the time of order processing.

responsibility

Core Glossary: An action required of the receiver of a message.

RIM

Core Glossary: See Reference Information Model.

RMIM

Core Glossary: See Refined Message Information Model.

RMIM diagram

Core Glossary: A diagrammatic representation of a Refined Message Information Model (RMIM). Possible formats include UML and the HL7 RMIM graphic format.

role

Core Glossary: 1. A function or position.

Core Glossary: 2. A Reference Information Modelclass that defines the competency of an Entity class. Each role is played by one Entity (the Entity that is in the role) and is usually scoped by another.

Core Glossary: 3. In UML, each end of an association is designated as a role to reflect the function that class plays in the association.

role name

Core Glossary: See association role name.

root class

Core Glossary: The class on which a message is based. Usually the root class for a family of messages is either the subject class or the class that will be first represented in the set of messages to be built.

(Return to glossary index)
 2.19 S
scenario

Core Glossary: A statement of relevant events from the problem domain, defined as a sequence of interactions. The scenario provides one set of interactions that the modeling committee expects will typically occur in the domain. Usually, a sequence diagram is constructed to show a group of interactions for a single scenario. Each scenario is displayed as a subset of the interaction model.

schema

Core Glossary: 1. A diagrammatic presentation, a structured framework, or a plan.

Core Glossary: 2. A set of requirements that need to be met in order for a document or set of data to be a valid expression within the context of a particular grammar. For example, XML Schema is a specification in SGML of the structure of a document or set of data.

schema view

Core Glossary: A link to the schema used to validate XML messages that conform to a particular message type.

scope

Core Glossary: 1. A definition of the range or extent of a project undertaken by a Technical Committee.

Core Glossary: 2. A means of constraining a role (i.e. a role is “scoped by” an entity).

section

Core Glossary: In the HL7 Version 3 Guide, a method of grouping related information into domains. These domains include Infrastructure Management, Administrative Management, and Health & Clinical Management.

Semantic

Core Glossary: In the context of a technical specification, semantic refers to the meaning of something as distinct from its exchange representation. Syntax can change without affecting semantics.

sequence diagram

Core Glossary: See interaction diagram .

set

Core Glossary: A form of collection which contains an unordered list of unique elements of a single type.

SGML

Core Glossary: Standard Generalized Markup Language, ISO 8879:1986(E) as amended and corrected

SHALL

Core Glossary: The conformance verb SHALL is used to indicate a requirement. See the conformance verb definition for more information.

SHOULD

Core Glossary: The conformance verb SHOULD is used to indicate a recommendation. See the conformance verb definition for more information.

SNOMED

Core Glossary: Systematized Nomenclature of Medicine

specialization

Core Glossary: An association between two classes (designated superclass and subclass), in which the subclass is derived from the superclass. The subclass inherits all properties from the superclass, including attributes, relationships, and states, but also adds new ones to extend the capabilities of the superclass.

specification

Core Glossary: A detailed description of the required characteristics of a product.

sponsor (of an application)

Core Glossary: In the context of conformance claims , the vendor, in-house developer, or provider of public domain software for a healthcare information system.

state

Core Glossary: A named condition of a classinstance ( object) that can be tested by examination of the instance's attributes and associations.

For more information refer to the Dynamic Behavior section of the Version 3 Guide.

state attribute

Core Glossary: An attribute describing the current state of an object.

For more information refer to the Attributes section of the Version 3 Guide.

state diagram

Core Glossary: A graphical representation of a state transition model showing states as vertices (nodes) and state transitions as directed arcs (arrows) between the nodes.

state flag

Core Glossary: A discrete value of a single enumerated domain of partial states. State flags are included in a state attribute in a message instance that indicates the joint state of an object.

state machine

Core Glossary: A description of the life cycle for instances of a class, defined by a state transition model.

state transition

Core Glossary: A change in the state of an object, as a result of a change in its attributes or associations.

For more information refer to the Dynamic Behavior section of the Version 3 Guide.

state transition model

Core Glossary: A graphical representation of the life cycle of a class. The model depicts all of the relevant states of a class, and the valid transitions from state to state.

steward committee

Core Glossary: The Technical Committee within HL7 which has primary responsibility for specifying properties for a class in the Reference Information Model (RIM). The steward committee must be consulted on any proposed changes to the properties of classes under its stewardship.

stewardship representative

Core Glossary: An individual member of the steward committee, authorized by the committee to speak on behalf of the committee, and to represent the interests of the steward committee.

storyboard

Core Glossary: A narrative of relevant events defined using interaction diagramsor use cases. The storyboard provides one set of interactions that the modeling committee expects will typically occur in the domain.

storyboard diagram

Core Glossary: See interaction diagram.

Strength of Recommendation

Defined in Clinical Decision Support: Strength of recommendation flag is a clinical order priority score that may be assigned as a default by the order set author, but which may be altered programmatically at the time of order processing by guideline decision logic.

structural attribute

Core Glossary: An attribute whose coded values are needed to fully interpret the class with which it is associated.

stylesheet

Core Glossary: A file that describes how to display an XML document of a given type

sub-section

Core Glossary: In the HL7 Version 3 Guide, a section within a major section.

sub-state

Core Glossary: An identifiable state of a class that has a more specific definition than, and is entirely encompassed within the scope of, its super-state.

subclass

Core Glossary: A class that is the specialization of another class (superclass).

subject area

Core Glossary: A convenient aggregation of modelclasses used to partition large models into manageable subsets.

subject class

Core Glossary: A class that a Technical Committee designates as the central focus of a collection of messages.

super-state

Core Glossary: A state of a class that encompasses two or more independent sub-states.

superclass

Core Glossary: A class that is the generalization of one or more other classes (subclasses).

surface form (of a concept)

Core Glossary: A code value or textual description that represents a concept identified by an HL7 concept identifier. There MAY be many different surface forms associated with a single concept identifier.

system

Core Glossary: 1. An end user application.

Core Glossary: 2. In HL7, a group of messages that work together.

(Return to glossary index)
 2.20 T
table view

Core Glossary: An expression of the Hierarchical Message Description (HMD) common and message type definition condensed in size to fit on a printed page.

tightly coupled

Core Glossary: Tightly coupled application roles assume that common information about the subject classes participating in a message is available to system components outside of the specific message.

transaction

Core Glossary: A complete set of messages for a particular trigger event, e.g., a message and a response.

transport wrapper

Core Glossary: A wrapper that contains information needed by a sending application or message handling service to route the message payload to the designated receiver. All HL7 Version 3 messages SHALL have an appropriately configured transport wrapper.

trigger event

Core Glossary: An event which, when recorded or recognized by an application, indicates the need for an information flow to one or more other applications, resulting in one or more interactions.

(Return to glossary index)
 2.21 U
UML

Core Glossary: See Unified Modeling Language.

Unified Modeling Language

Core Glossary: A language for the creation of domainmodels. UML was created in order to unify several well-known object-oriented modeling methodologies, including those of Booch, Rumbaugh, Jacobson, and others.

union message

Core Glossary: A message type that contains the elements of several message structures drawn from the same Hierarchical Message Description. A union message includes all the message elements that SHALL be sent from one application role to all other application roles in response to a trigger event.

user

Core Glossary: In the context of conformance claims, the organization that uses an application. This is frequently the buyer but in some cases the user and sponsor organizations may be parts of the same organization, or otherwise have a business relationship other then vendor-buyer.

(Return to glossary index)
 2.22 V
Version 3 Guide

Core Glossary: A companion to the Version 3 Standard which contains the methodological information an HL7 member needs to understand the Version 3 standard.

Valid Document

Core Glossary: A document which meets all of the validity constraints in the XML Specification

value set

Core Glossary: A vocabulary domain that has been constrained to a particular realm and coding system.

vocabulary

Core Glossary: The set of valid values for a coded attribute or field.

For more information refer to the Vocabulary section of the Version 3 Guide.

vocabulary domain

Core Glossary: The set of all concepts that can be taken as valid values in an instance of a coded attribute or field; a constraint applicable to code values.

For more information refer to the Vocabulary Domains section of the Version 3 Guide.

vocabulary domain qualifier

Core Glossary: Part of a vocabulary domain specification. The two existing qualifiers are extensibility and realm.

For more information refer to the Vocabulary Domain Qualifiers section of the Version 3 Guide.

vocabulary domain specification

Core Glossary: A column in the Hierarchical Message Description that specifies the vocabulary domain associated with a coded attribute.

(Return to glossary index)
 2.23 W
W3C

Core Glossary: The World Wide Web Consortium, an international industry consortium

W3C Schema

Core Glossary:

The three-part schema specification issued by the W3C



Well-formed document

Core Glossary: A document which meets all of the well-formedness constraints in the XML Specification

wrapper

Core Glossary: The control or envelope information in which the message payload resides. See transport wrapper and control event wrapper .

(Return to glossary index)
 2.24 X
XHTML

Core Glossary: XHTML 1.0. A Reformulation of HTML 4 in XML 1.0. W3C Recommendation 26-January-2000, revised 1 August 2002

XML

Core Glossary: See Extensible Markup Language.

XML Declaration

Core Glossary: An XML document consists of a prolog, root document element, and other objects. A data object is an XML document if it is well-formed, as defined in the XML specification.

XSL

Core Glossary: Extensible Style Language, a specification of the W3C An XSL stylesheet specifies the presentation of a class of XML documents by describing how an instance of the class is transformed into an XML document that uses the formatting vocabulary.

XSLT

Core Glossary: XSL transformation language, a specification of the W3C A language for transforming XML documents into other XML documents.

(Return to glossary index)
 2.25 Y
 2.26 Z

Return to top of page