Editor | Various Contributors HL7 Publishing Work Group |
Content Last Edited: 2007-03-27T13:54:37
HL7® Version 3 Standard, © 2013 Health Level Seven® International. All Rights Reserved.
HL7 and Health Level Seven are registered trademarks of Health Level Seven International Reg. U.S. Pat & TM Off.
Use of these materials is governed by HL7 International's IP Compliance Policy.
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.
OrderSet.precondition.Criterion.code
annotationFor more information refer to the Relationships section of the Version 3 Guide.
association compositionFor more information refer to the Attributes section of the Version 3 Guide.
attribute typeThe 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)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 DataFor more information refer to the Classes section of the Version 3 Guide.
classifier attributeFor more information refer to the Attributes section of the Version 3 Guide.
cloneFor more information refer to the Common Message Element Types section of the Version 3 Guide.
composite aggregationUniversally 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.
connectionFor more information refer to the Constraints section of the Version 3 Guide.
control event wrapperFor more information refer to the Data Types section of the Version 3 Guide.
default valueFor more information refer to the Information Model section of the Version 3 Guide.
domain nameFor more information refer to the Vocabulary Domain Qualifiers section of the Version 3 Guide.
Extensible Markup LanguageFor more information refer to the Relationships section of the Version 3 Guide.
generalization hierarchyFor more information refer to the Attributes section of the Version 3 Guide.
implementation technologyFor more information refer to the Implementation Technology Specifications section of the Version 3 Guide.
inclusionFor more information refer to the Information Model section of the Version 3 Guide.
inheritance“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 PersonalFor more information refer to the Classes section of the Version 3 Guide.
object-basedThe HL7 OID Registry is available online.
object identity"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 DatesDate 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 HeaderFor more information refer to the Vocabulary Domain Qualifiers section of the Version 3 Guide.
receiver responsibilityFor more information refer to the Information Model section of the Version 3 Guide.
Refined Message Information ModelFor more information refer to the Information Model section of the Version 3 Guide.
Replaces Order SetFor more information refer to the Dynamic Behavior section of the Version 3 Guide.
state attributeFor more information refer to the Attributes section of the Version 3 Guide.
state diagramFor more information refer to the Dynamic Behavior section of the Version 3 Guide.
state transition modelFor more information refer to the Vocabulary section of the Version 3 Guide.
vocabulary domainFor more information refer to the Vocabulary Domains section of the Version 3 Guide.
vocabulary domain qualifierFor more information refer to the Vocabulary Domain Qualifiers section of the Version 3 Guide.
vocabulary domain specificationThe three-part schema specification issued by the W3C
Return to top of page |