These pages are best viewed with Microsoft Internet Explorer 5.x with a screen resolution of 1024 x 768. While this is intended to work with all browsers, there are currently some issues with Netscape which we are continually trying to resolve.
HL7® Version 3 Standard, © 2002 Health Level Seven ®, Inc. All Rights Reserved.
HL7 and Health Level Seven are registered trademarks of Health Level Seven, Inc. Reg. U.S. Pat & TM Off
Reproduction of this material in any form is strictly forbidden without the written permission of the publisher.
Ann Arbor, MI January 2003
Dear Reviewer,
This site presents the draft Health Level 7 (HL7) message that has been developed by the HL7 Regulated Clinical Research Information Management Technical Committee, to be used for submission of annotated electrocardiographic (ECG) waveforms by the sponsor of a clinical trial to the United States Food and Drug Administration (FDA) as announced in the Federal Register. The site has been established to provide material for review of this message during the comment period specified in the announcement. This is not an HL7 ballot. Instructions for submitting comments to the FDA can be found in the Federal Register notice.Organization of the Site
This site follows the organization currently in use for HL7 Version 3 ballots.
Your entry point as a reviewer is through the link in the upper left-hand section of this page -- the link labeled "Link to ECG Annotation Message Review Material". There are also links in the "Overview" below, which will take you directly to the artifact described. You may download the review material at this time by using the "Link to Downloads Page". The downloaded package will also open at the present page, and will provide entry through the same links.
The site contains supporting materials as well as the documents for your comment. A list of all documents appears in the navigation panel on the left-hand side of the page once you enter the site. The supporting documents appear first in that list, and include the Introduction/Backbone, the V3 Help Guide, the Conformance and Localization document, the Glossary, the Reference Information Model specification, the Vocabulary specification, the Data Types specification, and the XML Implementable Technology Specification for representing any HL7 message in XML.
Documents for your comment are all included under the heading Health and Clinical Management Domains, and the sub-heading Domain: Clinical Trials - Informative.
It is important that you carefully read the document entitled "Introduction/Backbone", especially the section "V3 Packages". This section outlines all of the documents in the package, with the purpose of each.
Brief Overview of Artifacts to Review
The following is a brief orientation to the process used to develop the Annotated ECG message, and to the artifacts from that process that will be presented in this package for your review. A more detailed discussion of HL7 message development is contained in the HL7 V3 Guide, a supporting document which is included in the review package.
INTRODUCTION AND SCOPE
This section contains the background and rationale for developing the Annotated ECG interchange standard.
Artifact(s) to Review:STORYBOARD
Introduction and Scope section 1.0
The first step in developing a new HL7 message is to establish a business context for which one or more messages will be developed. That context is described in the Domain Information Model section, and in the Storyboard Purpose, which lays the foundation for describing HL7 messages and their content.
Artifact(s) to Review:INTERACTIONS The Storyboard Purpose is analyzed to determine the Trigger Events, the Sending and Receiving Application Roles, and the data that are to be interchanged based on the business context. An Interaction is created and named for each unique combination of Trigger Event, Sending Application Role, Receiving Application Role and data package. An Interaction Diagram is created that shows the progression of interactions between the Application Roles. A Storyboard Narrative is developed for each Interaction, describing a real-life event that illustrates the business context for the Interaction.
Domain Information Model section 2.0 Storyboard Purpose (ST) section 4.1.x
Trigger Events are real-world events that occur outside a computer application system, but which initiate the exchange of information between application systems. Trigger events include changes in state of business objects (e.g. order is placed; observation is complete); as well as the achievement of agreed time- or process-based criteria for the exchange (e.g. end of business day, clinical trial complete). Each Trigger Event can participate in multiple Interactions.REFINED MESSAGE INFORMATION MODEL (RMIM)
Application Roles represent a set of communication responsibilities that might be implemented by an application. Thus they describe system components or sub-components that are capable of sending and/or receiving Message Types in response to Trigger Events. An application role is not equivalent to an application system. Any particular application system may support only one application role, or it may support many such roles. Each Application Role may participate in multiple Interactions.
The Data Package includes information items that are expected to be exchanged between specified Application Roles in response to a specified Trigger Event. The Data Package will ultimately be specified as a Message Type. Each Message Type can participate in multiple Interactions.
Artifact(s) to Review:
Interaction (Ladder) Diagram section 4.1.x Storyboard Narrative (SN) section 4.1.x.x Application Roles (AR)* section 4.2.x Trigger Events (TE) section 4.3.x Interaction Definitions (IN) section 4.6.x
The RMIM is a class model that organizes the information from one or more Data Packages into classes that represent Acts, Roles, Entities and Participations that can be derived from the HL7 Reference Information Model (RIM). The processes and rules for refining the RIM to create such derived information structures are discussed at length in the supporting document Conformance and Localization, section 1.2 Refinement Process and the sections that follow in that document.
The data items in the data package are represented by attributes of these RMIM classes, and any refinements in definition of these attributes and classes over their definitions in the RIM are discussed in this section of the standard. RMIM attributes are not necessarily single values, but rather each is assigned a data type which specifies a set of components which may be valued for the attribute. For example, an attribute assigned the data type PQ (Physical Quantity) represents not only the numeric value of the physical quantity, but also the UCUM unit of measure for that numeric value, an unlimited number of translations of the numeric value into other units of measure with accompanying unit and unit of measure system designations, and a textual specification of the physical quantity. The allowable data types are fully enumerated in the supporting document Data Types: Abstract.
Each coded attribute in the RMIM is also assigned a vocabulary domain, identifying the specific values the attribute is allowed to assume. The vocabulary domains are fully enumerated in the supporting document Vocabulary.
Both the data types and the vocabulary domains can be further constrained in the "downstream" documents such as the Hierarchical Message Description and the Message Type described below.
Artifact(s) to Review:HIERARCHICAL MESSAGE DESCRIPTION (HMD)
RMIM Discussion and Diagram section 4.4.1
The HMD defines the content of one or a few closely related messages without reference to any implementation technology. It is a serialization of the elements (i.e., classes, attributes and associations) represented in the RMIM, achieved by traversal of the RMIM beginning at its defined entry point. The traversal process proceeds outward from the entry point class, taking each relevant association to that class in turn, and thence moving from class to class across any desired available associations, applying the refinement processes and rules cited under the RMIM section above. The HMD is presented as a grid view, as a table view, as an XML example document (downloadable), and as an Excel spreadsheet. These various presentations are described in detail in the V3 Help Guide, section 3.7 Hierarchical Message Descriptions and Message Types.
Artifact(s) to Review:MESSAGE TYPE (MT)
Base Hierarchical Message Description (HD) - grid view section 4.5.x
Each message type represents the fully constrained content of one HL7 message without reference to any implementation technology. In general, the message types are the result of one final application of the refinement processes and rules to the HMD. The base, or common, message type for each HMD is the unrefined HMD itself.
Each Message Type is presented as a grid view and as the XML schema (downloadable) for the message. An example XML document (downloadable) is also included for each message type. The schema is created in accordance with the HL7 XML Implementation Technology Specification (XML ITS), which specifies the rules for rendering any HL7 message in XML. Changes in the schema cannot be made directly, but must result either from changes in the "upstream" artifacts (RIM, RMIM, HMD, MT), or from changes in the XML ITS or the allowable Data Types. The XML ITS is presented in the supporting document XML Implementable Technology Specification. Both the XML ITS and the Data Type specifications are HL7 standards which can be revised through the HL7 ballot process.
All Message Types for an HMD are also displayed in the XL view of the HMD.
Artifact(s) to Review:
Individual Message Types (MT) - grid view section 4.5.x Individual Message Types (MT) - schema view section 4.5.x Individual Message Types (MT) - example section 4.5.x