HL7 V3 Guide
HL7 V3 Guide
Committee Ballot # 2
HL7 Version 3 Standard, Copyright © 2002. All Rights Reserved.
[pic]
Table of contents
1 HL7 FOUNDATION COMPONENTS
1.1 INFORMATION MODEL
1.1.1 Information Model Components
1.1.2 Types of Information Models
1.1.3 Static Structure: Classes and Relationships
1.1.4 Information Content: Attributes, Values, and Constraints
1.1.5 Dynamic Behavior: States and Transitions
1.2 VOCABULARY
1.2.1 HL7 Vocabulary Domains
1.2.2 Use of Vocabulary Domains to Build V3 Messages
1.2.3 Use of External Terminologies
1.2.4 Use of Local Vocabularies
1.2.5 HL7 Vocabulary and the UMLS Metathesaurus
1.2.6 Good Vocabulary Practices
2 HL7 MESSAGING COMPONENTS
2.1 INTRODUCTION
2.1.1 Document Scope
2.1.2 Overview of the V3 Publication
2.1.3 Methodology Preview
2.2 STORYBOARD AND STORYBOARD NARRATIVE
2.2.1 Overview
2.2.2 Storyboard Format
2.3 Application Roles
2.4 CONFORMANCE CLAIMS AND ORGANIZATIONAL PRACTICES
2.4.1 Introduction
2.4.2 Conformance Claim Work Products
2.5 Trigger Events
2.6 REFINED MESSAGE INFORMATION MODELS
2.7 UNDERSTANDING HIERARCHICAL MESSAGE DEFINITIONS
2.7.1 Overview
2.7.2 Hierarchial Message Descriptor (HMD) Column Descriptions
2.8 Message Types
2.9 INTERACTIONS
2.9.1 Overview
2.9.2 Message Types
2.9.3 Receiver Responsibilities
2.9.4 Interaction Models
Appendices
A References
B Appendix A: Act Properties and Moods
[pic]
|1 |HL7 FOUNDATION COMPONENTS |
|1.1 |INFORMATION MODEL |
The information model defines all the information from which the data content of HL7 messages are drawn. It follows object-oriented modeling techniques, where the information is organized into classes that have attributes and that maintain associations with other classes. The information model forms a shared view of the information domain used across all HL7 messages independent of message structure. Thus, the information model provides a means for discovering and reconciling differences in data definition.
|1.1.1 |Information Model Components |
The information model consists of the following components:
• classes, their attributes, and relationships between the classes;
• state transition models for some classes;
• data types and constraints.
Large portions of the information model have graphical representations in the Unified Modeling Language (UML). This includes the class diagram, the state transition diagram, and the data type diagram. Those graphical representations are views into the respective information model component. Some of the information model is specified informally in descriptive text and accompanying documents.
The information model notation is based largely on the Unified Modeling Language (UML), a modeling language that unifies the object-oriented modeling methods of Grady Booch, Jim Rumbaugh, Ivar Jacobson, and others. The UML is a rich, mainly graphical, means of expressing object-oriented concepts. To obtain more information about UML see or the book UML Distilled by Martin Fowler (ISBN 0-201-32563-2).
|1.1.2 |Types of Information Models |
The HL7 information modeling process recognizes three different types of information models. Each of the model types uses the same notation and has the same underlying meta-model. The models differ from each other based on their information content, scope, and intended use. The three types of information models are:
• Reference Information Model (RIM): The RIM is used to express the information content for the collective work of the HL7 Working Group. The RIM is a coherent, shared information model that is the source for the data content of all HL7 messages. The RIM is maintained by a collaborative, consensus building process involving all Technical Committees and Special Interest Groups. Through a process known as model harmonization, information content submitted as RIM change proposals is debated, enhanced, and reconciled by Technical Committee representatives and applied to the RIM.
• Domain Message Information Model (D-MIM): The D-MIM is a derivative of the RIM that includes a fully expanded set of class clones, attributes and relationships that are used to create messages for any particular domain. Generalization hierarchies in the RIM may be collapsed in the R-MIM. The D-MIM is used as a common base upon which all R-MIMs within a domain are built.
• Refined Message Information Model (R-MIM): The R-MIM is used to express the information content for a message or set of messages with annotations and refinements that are message specific. The content of the R-MIM is drawn from the D-MIM for the specific subject domain. The R-MIM may include clones of selected classes with alias names specific to the perspective of the message(s) to be derived. The R-MIM is used to create a certain message-specific projection of the D-MIM for the purpose of being context specific while maintaining the semantic link to the more generic RIM.
|1.1.3 |Static Structure: Classes and Relationships |
|1.1.3.1 |Classes |
A class is an abstraction of things or concepts that are subjects of interest in a given application domain. All things or concepts subsumed under a class have the same properties and are subject to and conform to the same rules. Classes are the people, places, roles, things, and events about which information is kept. Classes have a name, description, and sets of attributes, relationships, and states.
The instances of classes are called objects. Where classes represent categories of concepts, people and things, objects represent the individual things themselves. There is still a difference between objects and the things they represent. Objects capture all relevant data about things, which are known to the information system, but are not the things themselves. For instance, a particular human being, named John Doe, may be represented through an object in an information system. That object contains John Doe's demographic or medical data, but the object is still different from John Doe himself.
|1.1.3.2 |Relationships |
Classes relate with classes in various ways. Such relationships can be of three types:
• Generalization
• Association
• Composite Aggregation
|1.1.3.2.1 |Generalizations |
A generalization relationship is a connection between classes (as opposed to instances). The generalization relationship expresses that one class (called the superclass) is a generalization of another class (called the subclass). Conversely, the subclass is a specialization of the superclass. Instances of a subclass are also instances of the superclass. Conceptually, the superclass does not have a separate related instance to the instance of the subclass, although implementation-wise this may be different. Conceptually, generalization relationships are associations between classes, not between instances.
In a generalization relationship the subclass inherits all properties from the superclass, including attributes, relationships, and states. In addition, the subclass has other properties that are special for the subclass.
Each subclass may in turn have subclasses of its own. Thus, superclass/subclass and generalization/specialization are relative concepts. A class can be both a subclass of its superclass and a superclass of its subclasses. The entirety of superclasses and subclasses with a common root superclass is called a generalization hierarchy.
A generalization usually has multiple specializations. However, not all of the conceptual specializations need to be represented in the model. Only those concepts that warrant special properties (e.g., attributes, relationships, states) are modeled as distinguished classes. If all specializations of a class are fully enumerated as subclasses in the model, the superclass could be "abstract." An abstract class is never instantiated directly, but only through one of its specializations.
|1.1.3.2.2 |Associations |
An association defines a connection between objects. The objects may be instances of two different classes or of the same class (reflexive association). Just as classes have instances, associations have instances too. An association instance is a connection between objects and is defined by an association that connects classes.
[pic]
Figure 1: One association defined in the information model can have multiple instances. Each instance of an association connects two objects. The number of instances of an association connecting to one object is regulated by the multiplicities.
Associations in the HL7 Methodology have at least two ends. Each end of the association instance connects with one and only one object. However, one object may be associated with more than one object of the same class by the same association. In this case, multiple association instances exist, each connecting exactly two objects. The number of instances of an association that can connect to one object is regulated by the multiplicities of the association.
An association multiplicity specifies the minimum and maximum number of objects of each class participating in the association. The multiplicity is documented as a pair of cardinal numbers (i.e., non-negative integers) min..max. The lower bound min is a non-negative integer, usually zero or one. The upper bound max is an integer greater or equal to min, usually one, or unlimited, indicated by an asterisk ("*").1 Valid multiplicities are listed in the following table:
|Multiplicity |Meaning |
|0..1 |minimum zero, maximum one |
|0..n |minimum zero, maximum the integer n, where n > 1 |
|0..* |minimum zero, maximum unlimited |
|1 |short for "1..1" minimum one, maximum one |
|1..n |minimum one, maximum the integer n, where n > 1 |
|1..* |minimum one, maximum unlimited |
|n1..n2 |minimum the integer n1, maximum the integer n2, where n1 > 1 and n2 >n1 |
|n..* |minimum the integer n, maximum unlimited, where n > 1 |
|1.1.3.2.3 |Composite Aggregations |
A composite aggregation is a special flavor of an association between objects. Composite aggregations indicate that objects relate to each other as part and whole. Unlike common associations, a composite aggregation relationship is directed, one end being the whole and the other end being the part. The part is conceptually strongly dependent on the whole class, so that the part cannot exist without the whole.
|1.1.3.2.4 |Classes Expressing Complex or Dynamic Associations |
Many associations between business objects are of a more complex nature than could be expressed by a common association. For example, an association between two objects might only be valid in a certain time interval. Other associations need to be qualified or classified. This can be expressed with modeling patterns (design patterns). Modeling patterns are building blocks that can be reused in many circumstances. Four of those patterns are defined in the following sub-sections.
When a model contains associations with multiplicities "0..*" on both ends, this is an indication for a complex relationship that is likely to require more information. For example, the relationship between Patient and Physician would be a many-to-many association. In database design, many-to-many relationships were commonly resolved because there was no other way to technically implement them. In conceptual information modeling, resolving of such relationships is common because it is unlikely that many-to-many associations exist without further qualifications.
Note that the UML concept of an "association class" differs from the "associative class." An association class does not generally allow resolution of many-to-many classes, because multiple associations between the same pair of objects are not distinguished as individual associations with an association class. Associative classes are more powerful than association classes. The disadvantage of associative classes is that simple association names are turned into abstract and awkward association names. For instance, where a Physician sees a Patient with a many-to-many association, a physician is_involved_in many Patient-Physician-Associations, that in turn has_as_patient a Patient.
[pic]
Figure 2: Resolving a many-to-many association (a) through an associative intermediary class (b).
|1.1.4 |Information Content: Attributes, Values, and Constraints |
|1.1.4.1 |Attributes |
Class attributes are the core components of the information model. The attributes are the source for all the information content of HL7. The majority of attributes are descriptive attributes that depict aspects of classes that are important for communication between healthcare systems. Besides the descriptive attributes there are three special kinds of attributes in the information model:
• identifier attributes
• classifier attributes
• state attributes
|1.1.4.1.1 |Identifier Attributes |
Identifier attributes can be used to identify an instance of a class. Sometimes more than one attribute may be needed to identify an instance of a class. The identifier attributes always have a value. The values of identifier attributes are unique among all instances of the class. Since identity is static, values of identifier attributes never change. Identifier attributes are assigned the Instance Identifier (II) data type and are generally have a name ending in "-ID".
Examples of Identifier Attributes from the RIM include Entity.ID and Act.ID. These identifier attributes have an II datatype and uniquely identify a particular Entity or Act respectively. In each case the identifier attributes are a set of instance identifiers. This indicated that there may be multiple unique identifiers for an Entity or Act. Entity identifiers might include medical record numbers, social security numbers, driver license number, and others. Act identifiers might include placer accession numbers, filler accession numbers, and others.
|1.1.4.1.2 |Classifier Attributes |
Classifier attributes are used in generalization hierarchies to indicate which of the specializations is the focus of the class. The classifier attribute is placed in the superclass and contains a code value declaring the subclass type. There may be multiple classifier attributes in a superclass, indicating multiple independent generalization hierarchies. In a fully enumerated specialization hierarchy, classifier attributes are needed in order to specify the specialization class in a message.
The classifier attributes are a critical aspect of the classes forming the backbone of the RIM (Entity, Role, and Act). The classifier attributes are named "Class-CD". The classifier attributes provides a great amount of flexibility and extensibility in the information model. The vocabulary domains for classifier attributes include an entry for each specialization of the backbone class. For example the vocabulary domain specified for Entity.Class_CD includes Living subject, Organization, Place and Material. The vocabulary domain may also include entries that are not explicitly expressed as classes in the model. For example, Group is a valid Entity class code (or specialization of entity) but does not appear in the model as a class. This provides the flexibility and extensibility capability.
|1.1.4.1.3 |State Attributes |
A state attribute is used in subject classes. It contains a value that concisely indicates the current state of the class. A subject class must have only one state attribute. The state attribute must be assigned the data type "set of code value" that allows multiple state flags to be specified. State attributes as named Status-CD and are associated with vocabulary domains defined by HL7 that correspond to the state machine defined for the subject class. For example the Act.Status_CD has the domain values of active, suspended, cancelled, completed, and aborted.
|1.1.4.2 |Data Types |
Data types are the basic building blocks of attributes. They define the structural format of the data carried in the attribute and influence the set of allowable values an attribute may assume. Data types have very little intrinsic semantic content. The semantic context for a data type is carried by its corresponding attribute. Every attribute in the RIM is associated with one and only one data type, and each data type is associated with zero or many attributes.
|1.1.4.3 |Constraints |
Constraints narrow down the set of possible values that an attribute can take on. Constraints include vocabulary domain constraints (e.g., this attribute must be a LOINC code), range constraints (e.g., this attribute must be a floating point number between 0 and 1) and more. While the term "constraint" has the connotation of restricting and limiting, the objective in defining constraints is more to provide guidance in the proper use of a class or attribute. The important point about constraints is to suggest legal values rather than to penalize illegal values.
A vocabulary domain is a constraint applicable to code values. Vocabulary domains define the set of possible values for a code value. Hence, vocabulary domain constraints are largely defined in terms of sets and subsets rather than using predicates. The data types code value and concept descriptor, without a domain specification, have an infinite domain that includes all concepts that man can ever conceive of. In other words, code values are useless without some guidance provided by constraints to their value set.
Constraints may be specified in the RIM, MIM, R-MIM or HMD. If specified in the RIM, the constraint is relevant for an attribute in all messages containing the attribute. If specified in the MIM or R-MIM, the constraint is specific to all of the messages derived from that MIM or R-MIM. Constraints may also be specified within the HMD where they can be made specific to a particular set of message structures. Constraints specified in a higher level (e.g., the RIM) may be further constrained in a lower level (e.g., MIM or HMD). However, the subordinate constraint must conform to the constraint on the higher level. Higher level constraints cannot be undone on a lower level.
[pic]
Figure 3: A simple state transition model representing the life cycle of an activity.
|1.1.5 |Dynamic Behavior: States and Transitions |
An aspect of the behavioral aspect of a class is defined in a state diagram associated with a class in an information model. State diagrams are developed for classes that are the central subject of an interaction. These classes are called subject classes. Interactions are sometimes motivated by changes in the status of a subject class. For example Act may be identified as a subject class. The vocabulary domain for the Act.Status_CD declares the defined states for the Act. Those states include Active, Suspended, Cancelled, Complete, and Aborted. A state diagram depicts the allowable class states with a box labeled with the name of the state. Changes in state are called state transitions and are depicted in the diagram by a line with a arrowhead showing the direction of the transition. An example of a state transition might be the change in the state of an Act from Active to Complete. The change in state (state transition) is associated with a trigger event that causes the transition. The trigger event in this example might be the fulfillment of an order. An order is a special type of Act. The transition from an Active order to a Completed order is triggered by the fulfillment of the Order. The state diagram depicts the states, trigger event, and state transitions of interest.
[pic]
Analysis of the state diagram can be useful for discovering trigger events that might lead to the need for interactions.
|1.2 |VOCABULARY |
|1.2.1 |HL7 Vocabulary Domains |
Within the HL7, a vocabulary domain is the set of all concepts that can be taken as valid values in an instance of a coded field or attribute. For example, in the RIM, the Living_subject class has a coded attribute administrative_gender_cd. If the administrative_gender_cd attribute becomes part of a hierarchical message definition (HMD), and a message instance is subsequently created as part of an implemented interface, the administrative_gender_cd field contains the concepts male and female.
It is important to note that a value domain consists of a set of concepts, not a set of words or codes. In different implementations of an interface, the same concept could be represented using different coding systems. Thus, each concept in a vocabulary domain has a one-to-many relationship to codes that might be used as representations for the concept in a message instance.
The general meaning of code system is a scheme for representing concepts using (usually) short concept identifiers to denote the concepts that are members of the system. A coding scheme defines a set of unique concept codes.
|1.2.1.1 |Vocabulary Domains and RIM Attributes |
Each coded attribute in the RIM (i.e., with a data type of CC, CD, CE, CS, CV, SET_CD, SET_CE, SET_CS, or SET_CV) will be associated with one and only one vocabulary domain. For example the vocabulary domain for Administrative_gender_cd is AdmistrativeGender. Some vocabulary domains are associated with more that one RIM attribute. For example the Vocabulary domain PhysicalQuantity is associated with both diet_carbohydrate_qty and Diet_energy_qty. The vocabulary domain table may be an HL7-defined table, an HL7-recognized external coding scheme (e.g., LOINC, SNOMED, HIPAA) or some combination of those, or may contain locally defined codes.
The HL7-defined vocabulary domain tables that have been developed for coded class attributes are stored in the HL7 repository. A number of printable views have been extracted to produce the HL7 Vocabulary Domain Listings for the RIM The views are presented in table format and include the HL7 Vocabulary Domain Values list and the HL7 Domain Tables and Coded Attributes list. HL7-recognized external vocabulary domains are described in the External Domains list. Links are provided between these tables and attributes in the RIM.
• The HL7 Vocabulary Domain Values table includes a mnemonic code, concept identifier, print name, and definition/description for each value. This table also shows any hierarchical relationship that exists between values in each domain table.
• The HL7 Domain Tables and the Coded Attributes table name the coded attribute(s) in the RIM that are supported by that vocabulary domain.
• The External Domains table includes concept identifier, defining Express, code system abbreviation, description, and a link to the source for each table.
|1.2.1.2 |Vocabulary Domain Qualifiers |
Coded fields contain two pieces of information relative to Vocabulary: The vocabulary domain and the extensibility qualifier. The Extensibility qualifier has two possible values: CNE (coded no exceptions), and CWE (coded with exceptions). There are presently only two vocabulary domain qualifiers: Extensibility and Realm. Currently, the Extensibility qualifier is the only qualifier that can be used in domain specifications. Both the Realm and Extensibility qualifiers can be used in domain constraints.
The vocabulary domain name and the associated Extensibility qualifier for each coded attribute in the RIM are specified in the RIM narrative. This specification occurs as the first line of the description for a coded RIM class attribute. The information is formatted as shown in the example below from Entity_class_cd:
Domain: "EntityClass" (CNE)
There is a hyperlink between the vocabulary domain name (EntityClass) and its entry in the HL7 Vocabulary Domain Values table. For those domains that are not yet developed, a domain name has been assigned but the table contains no values.
The CWE value for the Extensibility qualifier means that the code set can be expanded to meet local implementation needs. When a coded attribute is sent in a message, local concepts or free text may be sent in place of a standard code if the desired concept is not represented in the standard vocabulary domain.
The CNE value for the Extensibility qualifier means that the code set is fixed and cannot be extended. A concept from the specified domain must be sent as the value of the coded field in a message. If the field cannot be valued from the concepts that exist in the specified domain, the field cannot be placed in the message. If a CNE field is required in a message, but the field cannot be valued from the concepts that exist in the specified domain, then no valid message can be created.
The Realm qualifier allows the domain of a coded attribute to be specialized according to the geographical, organizational, or political environment where the HL7 standard is being used. For example, the Realm qualifier would allow the Gender domain to hold a somewhat different value set for HL7 messages when used in Japan versus when the Gender domain is used in HL7 messages in the United States.
All domain qualifiers are values in the VocabularyDomainQualifier domain.
|1.2.2 |Use of Vocabulary Domains to Build V3 Messages |
Constraints are applied to RIM classes and their coded RIM attributes by selecting appropriate values from the vocabulary domains for those attributes.
|1.2.2.1 |Vocabulary Domain Constraints |
The vocabulary domain specifications stated in the RIM always refer to a complete vocabulary domain. That is, at the RIM level there is no specialization based on realm of use or on the context and needs of a specific message. As RIM attributes are specialized to suit a specific message context, the domain of the attribute can be reduced (constrained) to reflect the specialization.
A domain that has been constrained to a particular realm and coding system is called a value set. A vocabulary domain constraint can be applied to any level below the RIM, and is an expression that states how the sub-domain (value set) was derived from the domain specified in the RIM. A vocabulary domain constraint in R-MIM, D-MIM, etc contain the name of the value set and its list of domain qualifiers. Domain constraint expressions are only contained in the Value Set Definition Table.
The general rule for creating vocabulary domain constraints is that a domain can be reduced in scope as it is specialized for a particular use, but its semantic scope can never be expanded. The application of the general rule results in the following specific rules.
• The vocabulary domain of a coded element or attribute used at any level of specialization below the RIM must be a subset of the vocabulary domain specified for the attribute in the RIM. Note that for attributes that are qualified with an extensibility of CWE, local codes are an allowed extension to the domain, but this is not intended as an increase in the semantic scope of the attribute.
• Once the Extensibility qualifier value CNE has been invoked at any level of attribute domain specification (RIM, R-MIM, CMET, HMD, etc), the CNE qualifier must be retained in any subsequent domain constraints. For example, if a coded attribute has a CNE qualifier in the RIM, any R-MIM, CMET, HMD, etc must also have a CNE qualifier associated with the domain of that attribute. If a vocabulary domain in the RIM has the Extensibility qualifier value of CWE (coded with exceptions), a subsequent constraint of that attribute's domain can have either the CNE or CWE qualifier.
|1.2.3 |Use of External Terminologies |
HL7-recognized external terminologies are listed in the External Domains table.
The Vocabulary Technical Committee is working on strategies for use of external vocabularies in HL7 domain specifications and messages. The following principles summarize HL7's general approach:
• HL7 is committed to using existing terminologies as values for coded fields in HL7 messages, where possible, rather than creating a new terminology.
• HL7 is seeking a solution that allows the use of proprietary vocabularies (SNOMED, Read, MEDCIN, etc.) in a manner that is equitable to all vocabulary creation/maintenance organizations.
Given these goals, the HL7 Vocabulary Technical Committee has concluded that:
• HL7 should not choose a single proprietary coding scheme.
• The presumption is that a "market model" will assure responsive maintenance of proprietary terminologies.
• HL7 will properly license any terminologies it uses.
• The primary code in coded fields can be a UMLS CUI (Unified Medical Language System, Concept Unique Identifier) or a proprietary code when properly licensed.
• Coding schemes used by HL7 must be registered with HL7. See more details below. HL7-registered vocabularies are listed in the External Domains table.
• To be used for a given domain, a terminology must cover all of the concepts defined in the domain specification for that domain.
• To enable interoperability, proprietary codes used in messages must be mapped to a publicly available reference model that supports the desired degree of interoperability.
|1.2.4 |Use of Local Vocabularies |
It is legal to use locally defined concepts and codes in HL7 messages when the standard value set does not contain the needed concept, and when the vocabulary domain has an Extensibility qualifier of CWE (coded with exceptions).
There are a few rules that govern the use of local codes:
• A local code cannot be sent for a concept that is already represented in the standard domain.
• Locally defined code systems will be assigned OIDs (object identifiers) so that they can be distinguished from any other HL7-registered proprietary or external terminology.
• Users are encouraged to submit local codes to the HL7 Vocabulary Technical Committee so that they can be incorporated into the HL7 vocabulary domain, thereby increasing the interoperability of the communicating systems.
|1.2.5 |HL7 Vocabulary and the UMLS Metathesaurus |
HL7 has an informal agreement with the United States National Library of Medicine (NLM) that HL7-maintained vocabulary tables will be incorporated into the UMLS Metathesaurus. In fact, many of the characteristics of the HL7 domain specification database are based on the design principles of the Metathesaurus tables.
The main reasons for wanting the HL7 tables in the Metathesaurus are:
• It is a neutral environment where cross mapping of various terminologies can occur.
• The Metathesaurus has proved to be a stable and readily accessible archive of concepts and their representations.
• Linking HL7 content to the Metathesaurus content allows HL7 users to take advantage of the richness of the UMLS Knowledge Sources, including links to bibliographic references and the semantic network.
Placing HL7 terms and codes in the Metathesaurus will allow easy cross-referencing between HL7 terms and existing vocabularies, like SNOMED International and LOINC. It also creates linkages to other aspects of the UMLS Knowledge Sources such as bibliographic references, the Semantic Network, the Specialist Lexicon, definitions, and co-occurrence data. These linkages have the potential to make data in HL7 messages much more useful to the parties that send and receive clinical messages. Having all of the codes in a common database will allow comparisons that can lead to greater consistency and interoperability among the various message developers.
|1.2.6 |Good Vocabulary Practices |
The Vocabulary Technical Committee develops and maintains the document containing good vocabulary practices guidelines to be followed in definition and maintenance of vocabulary domains. Contact the Vocabulary Technical co-chairs to abtain a copy of the Good Vocabulary Practices Guidelines document.
|2 |HL7 MESSAGING COMPONENTS |
|2.1 |INTRODUCTION |
This HL7 V3 Guide was created for use by members of the Health Level Seven (HL7) Working Group as a companion to the V3 Standard. The information contained in this document is based on and was drawn from the Message Development Framework (MDF). In fact, the V3 Guide can be considered a "condensed" version of the MDF in that it contains only the methodological information an HL7 member needs to understand the V3 publication. Most of the theoretical and technical discussions provided in the MDF are not included in the V3 Guide.
|2.1.1 |Document Scope |
This document defines and describes the elements such as Storyboards, the Information Model, and vocabulary that comprise the piece of the V3 publication. HL7 members should use this document as a tool for gaining general understanding of the V3 publication.
|2.1.2 |Overview of the V3 Publication |
As indicated in the Backbone document, there are several documents within the V3 publication. However, the V3 Guide is primarily concerned with the following four documents:
• HL7 Version 3 Standard: Administrative Management
• HL7 Version 3 Standard: Infrastructure Management
• HL7 Version 3 Standard: Health and Clinical Management
• HL7 Version 3 Standard: Vocabulary
The first three documents noted above are divided into Sub-sections and domains as outlined below.
|HM |Section: Health and Clinical Management |
|PO |Sub-Section: Practice and Operations |
| |LB |Domain: Laboratory |
| |RX |Domain: Pharmacy |
|RC |Sub-Section: Records |
| |PC |Domain: Medical Records |
|AM |Section: Administrative Management |
|PR |Sub-Section: Practice |
| |PA |Domain: Patient Administration |
| |SC |Domain: Scheduling |
|FI |Sub-Section: Financial |
| |FM |Domain: Financial Management |
| |CR |Domain: Claims & Reimbursements |
| |AB |Domain: Accounting & Billing |
|IM |Section: Infrastructure Management |
|CO |Sub-Section: Control |
| |MC |Domain: Message Control |
| |MF |Domain: Master Files |
|QU |Sub-Section: Query |
| |QD |Domain: Query |
Additional Sections and Sub-sections exist in HL7; however, they have not yet included submissions for the V3 Release.
[pic]
Each of the domains documents contain the following:
• Storyboard (ST)
• Storyboard Narrative (SN)
• Application Roles (AR)
• Trigger Event (TE)
• Domain Message Information Model (DM)
• Refined Message Information Model (RM)
• Hierarchical Message Definition (HD)
• Message Type (MT)
• Example (EX)
• Interactions (IN)
Each of the bullets above represents an artifact. Each artifact is submitted by a Technical Committee and given a unique identifier that is assigned by concatenating the Sub-Section, Domain and Artifact code (the artifact codes are in parentheses in the bulleted list above), a 5-digit, non-meaningful number, two digit realm and 2 digit version. For example, an application role submitted by the Patient Administration domain may have the following unique artifact identifier:
PRPA_AR00001UV00
Where:
PR = Subsection: Practice
PA = Domain: Patient Administration
AR = Artifact: Application Role
00001 = 5 digit non-meaningful number
UV = realm (the only current value is UV for universal)
00 = Current version number
As you browse through the ballot documents, you will notice that most artifact identifiers are hyperlinks that take you to the particular artifact in question.
The chapters of the Messaging Components Section of the V3 Guide explain each of these artifacts.
|2.1.3 |Methodology Preview |
• STORYBOARD AND STORYBOARD NARRATIVE (§2.2 ) contains a describes the elemets of storyboards and storyboard narratives.
• INSERT ENTRY FOR APPLICATION ROLES
• INSERT ENTRY FOR TRIGGER EVENTS
• INSERT ENTRY FOR D-MIM
• INSERT ENTRY FOR R-MIM
• UNDERSTANDING HIERARCHICAL MESSAGE DEFINITIONS (§2.7 ) describes Hierarchical Message Definitions (HMDs) and their structure.
• INSERT ENTRY FOR MESSAGE TYPES
• INTERACTIONS (§2.9 ) discusses interactions (or communication needs) for an HL7 message.
|2.2 |STORYBOARD AND STORYBOARD NARRATIVE |
|2.2.1 |Overview |
The storyboard concept is borrowed from the movie and animation industry, and is useful to the development of HL7 messages for the same reasons proven in that industry:
• A storyboard depicts a story using a series of "snapshots" or events in chronological sequence;
• Each snapshot represents a recognizable, meaningful moment in the sequence of events that the reader must know about to understand the overall sequence and result;
• Each snapshot illustrates the key participants in the storyboard and their interaction with other players;
• The whole series of snapshots provides a coherent description of a complete process or activity.
Storyboarding is helpful as part of the message development methodology because:
• Each storyboard is comprised of a sequence of interactions.
• Storyboarding provides context for the other normative documents produced during the message development process and provide the supporting narrative for collaboration diagrams.
• Storyboards are helpful in grouping interactions that may constitute an application role.
A Storyboard consists of a short description of its purpose and an interaction diagram that shows the progression of interactions between the application roles. A storyboard narrative is a description of a real-life event that provides the necessary context for the development of a specific interaction described in the storyboard. The process of storyboarding lays the foundation for describing HL7 messages and their content.
|2.2.2 |Storyboard Format |
The V3 Storyboards are comprised of five sections: a Name, an ID, a Purpose, Annotations, Interaction Diagram and List. The name is simply a short, descriptive phrase. The ID is a 16-character code and ST appearing as the ninth and tenth characters identifies the artifact as a Storyboard. The purpose is a short phrase which gives the purpose for which the storyboard was created. Frequently it describes the generic set of actions that the storyboard represents. Annotations are of two types, either Developments Notes (DN) or Walk Throughs (WT). Developer notes describe how and why the storyboard was developed. A walkthroughs is a narrative that describes how one moves through the Interaction Diagram. The Interaction Diagram shows the interactions between the application roles and list of Interactions with hyperlinks to the complete description of the Interaction.The interaction diagram is required and can be depicted using a sequence diagram.
|2.2.2.1 |Storyboard Narrative Format |
The V3 Storyboard Narratives are comprised of a Name, an ID, a narrative, the applicable status field and identifier field values. The ID is a 16-character code and SN appearing as the ninth and tenth characters identifies the artifact as a Storyboard Narrative. The narrative qualifies the possible ways in which the story could transpire.
A sample Storyboard and Storyboard Narrative from Medical Records is provided below:
Story: Original Document Notification (RCMR_ST00001UV00)
Purpose
Describe various ways documents are originated, edited, revised, apprended, and removed from patient care.
Annotations
Type Realm Note
DN UV Universal development note
WT UV Universal walkthrough note
NEEDS FORMATTING
A sample Storyboard Diagram from the Medical Records Sub-section is provided below
[pic]
1 RCMR_IN00001 Original Document Notification
2 RCMR_IN00002 Original Document Notification and Content
3 RCMR_IN00003 Document Status Change Notification
4 RCMR_IN00004 Document Status Change Notification and Content
5 RCMR_IN00005 Document Addendum Notification
6 RCMR_IN00006 Document Addendum Notification and Content
7 RCMR_IN00007 Document Edit Notification
8 RCMR_IN00008 Document Edit Notification and Content
9 RCMR_IN00009 Document Replacement Notification
10 RCMR_IN00010 Document Replacement Notification and Content
11 RCMR_IN00011 Document Cancel Notification
ADD TO ABOVE NAMED GRAPHIC
Narrative: Original Document Notification (RCMR_SN00001UV00)
A pathology resident performs a gross dissection examination of the tissue submitted from a surgical procedure to remove the gall bladder of a 37 year old female patient. The pathologist assigns a surgical case number to the study and dictates their observations into a central dictation system. This narrative is exposed to a transcriptionist who keys the text into a transcription management system. This application generates a message from the Transcription Management System to specialized case of a document management system called a surgical pathology system.
Since a complete surgical pathology exam contains microscopic findings and conclusiongs the the Document Completion Status is marked as 'Incomplete'
Status field value contained in this message include:
• Status_cd: 'draft'
• Completion_cd: 'incomplete'
• Confidentiality_cd: 'usual control'
• Availability_dttm: not present
• Storage_cd: 'active'
Identifier fields include:
• id: 'a123'
• set_id: 'BB35'
• version_nbr: '1'
NEEDS FORMATTING
|2.3 |Application Roles |
Application roles describe the type of system component that sends and receives the message. An application role has a name, a description and a unique identifier.
Role: Transcription Manager (RCMR_AR00001)
Description
Long Name: Transcription Manager
This role manages the transcription of documents and the transmission of documents and document status changes to other applications.
There are no specifications about how the system component carries out these responsibilities. The same system component can be described by more than one application role. Application roles are not necessarily mutually exclusive, but can be nested or overlapped. An example would be an order entry system that can send laboratory orders or pharmacy orders. Three application roles are defined: a Laboratory Order Placer, a Pharmacy Order Placer and a Laboratory and Pharmacy Order Placer which includes the other two. There may be no interactions that include application roles actually named Laboratory and Pharmacy Order Placer, but a system component could claim this application role and undertake to send interactions with both Laboratory Order Placer application roles and Pharmacy Order Placer application roles. This allows application roles to explicitly describe niche players as well as more generalized systems.
Application Roles are sometimes identified as being "loosely coupled" versus "tightly coupled." This distinction 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. Loosely coupled application roles do not assume common information is available, while tightly coupled application roles do assume information is available. Information may be common because both system components have access to a common data store or repository or there may be separate, but synchronized, data stored within each system. An example may be a loosely coupled system which requires the particulars about a patient sent with each message, versus a tightly coupled system which can act on a message sent with only the patient identifier to distinguish which patient.
|2.4 |CONFORMANCE CLAIMS AND ORGANIZATIONAL PRACTICES |
|2.4.1 |Introduction |
HL7 V3 messages were designed to be specific enough to permit strong conformance claims to be asserted and verified. Release 1 of V3 has all the features that will be required for conformance statements, but a formal V3 conformance registry process is not yet in place
This section describes how conformance criteria are stated and used in V3.
Most conformance criteria are stated in terms of the performance of a healthcare information system with respect to its interfaces. As such the burden of conformance falls primarily on the developer or installer of the information system. The goal with respect to these conformance criteria is to provide a concrete definition of conformance that can be the basis of contractual agreements and conformance testing.
[pic]
Figure 4: HL7 Conformance Claims
In other cases, HL7 states good organizational practices for using the HL7 Standard. As there is no contractual relationship between HL7 and user organizations, HL7 does not expect to be able to audit or otherwise enforce compliance. Nonetheless, it is extremely valuable to state these principles in a clear and concise way.
|2.4.1.1 |Conformance Claims |
One of the primary benefits of V3 is that conformance criteria are stated in terms that are sufficiently concrete to use in contracts and test the conformance of a system.
The parties that need to communicate about conformance are the sponsors and users. The sponsor of an information system is the vendor, in-house developer, or provider of public domain software. The user of a health care information system is the organization that buys or leases the information system or employs an information system for which the software was developed in-house or is in the public domain.
The scope of HL7 is very broad; very few if any systems will conform to all the application roles contemplated for V 3. For this reason, a general statement such as "system X conforms to HL7" is imprecise. A user wants to know "to what parts of HL7 does it conform"?
In order to be precise, the specifications created by the HL7 technical committees describe entities that constitute individual statements of conformance criteria. The sponsor of a healthcare information system combines them into a conformance claim set by simply publishing the list of individual conformance statements that it claims. This list is called a conformance claim set. The user relies on the conformance claim set to know the HL7 capabilities of a sponsor's system, and its ability to interact with other systems, before making a commitment to purchase or otherwise employ the system under consideration. The user can expect that the sponsor's system fully conforms to each of the statements in its conformance claim set. After a contract is signed, the conformance claim set serves as a basis for resolution of differences in the expected and actual implementation of HL7.
As certification methods are developed for V3, there will be explicit tests to validate the conformance of a sponsor's systems to the statements of conformance criteria.
|2.4.2 |Conformance Claim Work Products |
As described in the Introduction, statements of conformance criteria are designed to provide precise descriptions of the HL7 functions a system must support with respect to a specific part of the HL7 specifications. Conformance criteria are defined by HL7 and given an unambiguous identifier.
A conformance claim set is a list of the identifiers of specific HL7 statements of conformance criteria.
There are two kinds of statements of conformance criteria: functional and technical. A functional statement of conformance criteria is a commitment to fulfill the responsibilities of a V3 application role. Functional statements of conformance criteria are completely specified by functional technical committees as they define interactions relating to an application role. In other words, they are claims to:
• send certain HL7 messages to systems that conform to certain other application roles in response to certain trigger events;
• receive certain HL7 messages to systems that conform to certain other application roles; and
• upon receipt of certain messages, perform the receiver responsibilities.
Furthermore, the sponsor must enumerate all optional conformance message elements associated with a conformance claim, and identify:
• whether it can send or receive the conformance message element;
• if the conformance message element is of data type multimedia-enabled free text, which of the media types it supports.
A technical statement of conformance criteria is any other testable claim. Today, this is the XML Implementable Technology Specification. In general, the Control/Query Technical Committee writes technical statements of conformance criteria.
|2.4.2.1 |Functional Statement of Conformance Criteria |
Each application role defined in a release of HL7 V3 specifications is a functional statement of conformance criteria. In claiming conformance to an application role, the sponsor is asserting that it fulfills the obligations of that application role. This specifically means that it sends all of the interactions that are required to be sent, and receives all the interactions that the application role is required to receive, and performs the receiver responsibilities associated with them.
It is important to notice that each interaction is associated with one and only one application role. The same message type may be used in response to the same trigger event in another application role, but that interaction will have a different identifier. Likewise the same message type may be used in response to a different trigger event in the same application role, but that will also be a different interaction.
• Sending Interactions The sponsor claims that its information system will send an interaction in response to the HL7 trigger event that initiates it. The sponsor also claims that the message will be sent using the message type prescribed by HL7 in the Hierarchical Message Description (HMD. The HMD defines the sequence, grouping, repetition and abstract type of message elements in the message. It does not, however, define the elements' physical format or the manner in which the message is sent. These characteristics will vary according to the Implementable Technology Specifications (ITS) applied to the HMD. The interpretation of the terms null, not present and the possible inclusion values in the HMD are critical to determining conformance. The term conformance message element means any element of a message that is either a component of the message type or a component of any component of the message type, to the entire depth of the tree that is represented in the HMD. Certain conformance message elements have special treatment, because they correspond to attributes of the Reference Information Model. They are called RIM attribute elements. The statement of conformance criteria is different for RIM attribute elements. Inclusion refers to the conditions under which a message element appears in a message. The term relates directly to the determination of conformance. This section defines how it is used when relating to interactions that are sent by a sponsor's information system. The possible values for the inclusion of a message element are:
o Mandatory. The message element must appear every time the message description is used for an Interaction (subject to the rules of multiplicity and conditionality.) In addition, if the component represents a RIM attribute, it must not have any null values.
o Optional. The element need not appear in every message instance; if it appears, and it is a RIM attribute it can have a null value.
Conformance refers to....
o Required. The message element must appear every time the message description is used for an Interaction (subject to the rules of multiplicity and conditionality.) All message elements that have an inclusion value of mandatory must have a conformance value of required.
o Not Required. The message element may be populated or used by one system sponsor, but not by another. Each system sponsor is required to state its ability to accept or send the message element as part of its conformance claim.
o Not Permitted. This message element may never occur when the message type is used for an interaction. Since a single HMD is used to describe multiple message types, this option is necessary.
In describing a sponsor's information system the term function point is any system function, user transaction, or other interaction or event which, when it occurs, may correspond to an HL7 Trigger Event. It is difficult to be more specific because of the variety of architectures and terminologies used by various information systems. The relationship between trigger events and function points is many-to-many. More than one function point may represent the same trigger event. For example, "discharge AMA" and "patient death" may be handled on different screens although they both represent the same trigger event. It is equally true that a single function point may represent different trigger events. For example, "discharge mother and baby" may represent two unique discharge trigger events. A claim that an information system corresponds to an application role implies the following statements:
o The mappings between data elements in the sender's database and the message must conform to the semantics of the message information model and its specific relationships that are named in the HMD. (This does not imply that the sender's database uses the same names for the data elements or has the same structure as the appropriate HL7 message information model.)
o Whenever any function point occurs that corresponds to any HL7 trigger event that initiates an interaction, the system will send all the interactions specified for the application role.
• Receiving Interactions A sponsor claiming to conform to an application role also has requirements when receiving interactions. In general, the receiving system must map appropriately all message elements of the interaction instance to the corresponding data in the receiving information system. If, however, the message element has a conformance value of not required and the sponsor does not claim to support the message element, then this requirement does not apply. The data so mapped must appear correctly in screens, reports, and other outputs of the system. Specifying the information content of specific screens, reports, and other outputs is beyond the scope of HL7. However, if a specific data element does occur on a screen, report, or other output, and the corresponding data field has been received in an HL7 message, the value in the last HL7 message should appear. Of course, this flow may be overridden by subsequent actions of the users of the information system. The mapping between data fields in the message and the receiver's database must conform to the semantics of the message information model and its specific connections that are named in the HMD. (This does not imply that the receiver's database uses the same names for the data fields or has the same structure as the appropriate HL7 message information model.) If the trigger event for which the message is sent corresponds to one or more function points in the receiver's system it should take the actions that correspond to the function point. Suppose, for example, that the function point that corresponds to canceling an order creates consequential updates to the patient account and work list portions of the database of the information system. The receipt of an HL7 message that corresponds to that function point should trigger the same updates. Sometimes the receiving information system may choose to recognize the receipt of an HL7 message instance as a distinct function point from the local execution of the same information. (For example, it may choose to defer the transaction for verification.) It is not a failure to conform to have a reasonable but different workflow for the recognition of events through HL7 messages. Certain interactions include responsibilities of the receiving information systems to initiate other interactions. In claiming that its information system corresponds to an application role, the sponsor is claiming that it performs all receiver responsibilities.
• Simultaneously Sending and Receiving Interactions In many cases a sponsor's information system may conform to application roles that make the information system both the sender and receiver of the interaction. It may implement this transfer of information in any manner at all, not necessarily using the HL7 Standard. In certain cases a sponsor's information system must send an interaction both to itself and to another application role that is implemented in another information system. In this case it need not use HL7 interactions for the information transfer to itself, but it must use HL7 interactions for the transfer to the other information system.
|2.4.2.2 |Technical Statement of Conformance Criteria |
A technical statement of conformance criteria is a statement that an information system corresponds to some aspect of the HL7 Standard that is different from, and independent of, the functional statement of conformance criteria that are asserted through application roles. The statement is made as unambiguously as possible in natural language text. In order to be a technical statement of conformance criterion it must also be testable.
Examples of technical statement of conformance criteria include the Implementable Technology Specifications and special HL7 protocols such as batch or sequence number.
• Technical Conformance Criteria with Respect to Vocabularies The Vocabulary Technical Committee will write one or more of the technical statements of conformance criteria. They will include these principles:
o This system has the ability to produce a report of all local codes in use in a specific implementation.
o This system has the ability to produce an HL7 message containing a report of all local codes in use in a specific implementation.
o This system has the ability to change the code in use for a concept without invalidating system outputs, including reports that include times before and after the change.
o This system has the ability to replace the code in use for a concept with several that represent subspecies of the concept without invalidating system outputs, including reports that include times before and after the change.
|2.4.2.3 |Good Organizational Practices |
Statements of good organizational practice will be written as a series of statements about the policies of a generic user organization. To the maximum extent practical it should be possible to objectively determine the performance of an organization with respect to the statements.
• Good Organizational Practices for Vocabulary The Vocabulary Technical Committee will write one or more statements of good organizational practice that embody the following principles:
o The organization will use standard codes if they exist. If the concept to be sent exists in the domain specification for the field, a code from the domain must be sent. In other words, one cannot send a local code for something that exists in the standard domain.
o The organization will not use a code from a standard set and give it a new meaning.
o Where the organization uses a local code, it will use one that is consistent with the semantic type of national codes assigned to the same data field. In other words, if the field is "Eye Color" with values of "blue," "hazel," and "brown, it would be inappropriate to send a code meaning "Arm." (Note: A violation of this principle can only be detected by human review.)
o Where the organization finds the necessity to use local codes, it will submit them to HL7 for review and addition. HL7 will share these proposed concept additions with HL7 vocabulary source providers.
o An organization will promptly begin using new codes when it upgrades its systems.
o When an organization has submitted a local code requesting the creation of a standard code, and the responsible standards organization denies the creation of a new standard code, and the denial provides an alternative method to meet the need, the organization will adopt the alternative method.
|2.5 |Trigger Events |
A trigger event is an explicit set of conditions that initiate the transfer of information between system components. A trigger event is a real-world event, for example, a laboratory order is placed, or a drug is dispensed. A trigger event is described by a unique identifier, a name and the description of the condition that would cause information to flow.
Trigger: Original Document Notification (RCMR_TE00001)
Description
Long Name: Original Document Notification
This is a notification of the creation of a document without the accompanying content. Systems become aware of documents by multiple approaches.
A set of conditions must be systematically recognizable by an automated system. In many cases the successful completion of a particular business transaction is also a trigger to send messages, such as a particular point in time (e.g., at midnight send all queued update transactions), or a relative interval of time (e.g., every 12 hours send accumulated information to a tracking system). A message may also be sent as a result of an "alert" event that results from monitoring a complex set of data elements for a particular pattern of values.
More than one interaction can be initiated by the same trigger event, but each interaction is triggered by only one trigger event. Trigger events are often defined in state transitions for subject classes. These trigger events cause messages to flow because the state of a subject class is changing. Once a trigger event has occurred, messages are sent to inform the participating system. These state transitions can be part of an expected business cycle or may be triggered because of exceptions in the normal business processes. The full set of states and their transitions are documented in state diagrams accompanying an information model at the Reference Information Model (RIM) level, or one of information models (Domain Information Model (D-MIM), Message Information Model-MIM or Refined Message Information Model-R-MIM).
|2.6 |REFINED MESSAGE INFORMATION MODELS |
Question 2 is answered by referring to a trigger event. A trigger event is an explicit set of conditions that initiate the transfer of information between system components. A trigger event is described by a unique identifier, a name and the description of the condition that would cause information to flow.
The set of conditions must be systematically recognizable by an automated system. Trigger events can be as simple as manual intervention, where a human user "invokes" a specific message transfer. In many cases the successful completion of a particular business transaction is also a trigger to send messages, such as a particular point in time (e.g., at midnight send all queued update transactions), or a relative interval of time (e.g., every 12 hours send accumulated information to a tracking system). A message may also be sent as a result of an "alert" event that results from monitoring a complex set of data elements for a particular pattern of values.
More than one interaction can be initiated by the same trigger event, but each interaction is triggered by only one trigger event. Trigger events are often defined in state transitions for subject classes. These trigger events cause messages to flow because the state of a subject class is changing because a trigger event has occurred and the messages are being sent to inform participating system components. These state transitions can be part of an expected business cycle or may be triggered because of exceptions in the normal business processes. The full set of states and their transitions are documented in state diagrams accompanying an information model at the Reference Information Model (RIM) level, or one of information models (Message Information Model-MIM or Refined Message Information Model-R-MIM) defined during message development.
|2.7 |UNDERSTANDING HIERARCHICAL MESSAGE DEFINITIONS |
|2.7.1 |Overview |
This chapter describes how a message structure uses the Hierarchical Message Definitions (HMD), a normative expression of the standard.
Some questions that are frequently asked are: "Why do we need to create an HMD? If we already know the sender, the receiver, the trigger event and the classes, why not just send the data?" There are several important answers to this question.
• The information model contains a group of classes that frequently are interconnected in more than one way. For example, there may be associations that lead from Patient to Person directly (this is the person who is the patient) and indirectly (this is the person who is the next of kin or the patient, or this is the person who is the primary physician of the patient). The communicating systems must be able to determine which of the objects derived from these classes contain the data to be sent. Furthermore, they must be able to navigate to the related objects through the associations that are defined for the classes.
• The same attributes may not be appropriate for different objects. Although both the patient and the physician associated with a clinical order are people, it is unlikely that we will send the physician's religion, date of birth, or sex each time we process an order for the patient. The communicating systems must be aware which of the objects will be sent.
• Finally, to send data over the wire, the computer must organize it sequentially. There are many different ways to organize the data from a group of objects interconnected by their associations. If the sender and the receiver do not agree exactly on that order, the communication is frustrated. If the sender transmits information about the attending physician before that of the primary care physician, and the receiver is expecting the opposite order, there will be a problem. The communicating systems must know the exact sequence in which information will be sent.
The Hierarchical Message Definition specifies these choices. It defines a single message structure that is used for an interaction without reference to the implementation technology. The Implementation Technology Specification describes how to combine data with the message structure in order to create a message instance. This means that a message sent in the format of one implementation technology can be easily transliterated into the format of another.
In simplest terms, an HMD is a tabular representation of the sequence of elements (i.e., classes, attributes and associations) that may be used to generate HL7 messages. The HMD is composed of three sections. The leftmost section maps the elements (classes, attributes and associations) to the RIM. The center section, called the common message, is a generic template for the specific instances described on the rightmost part of the HMD. The common message will never be sent, and does not have a corresponding trigger event. The specific instances of the message, called message types, described on the rightmost part of the HMD may be communicated in response to a trigger event.
A sample HMD is provided below:
[pic]
Figure 5: Sample HMD.
|2.7.2 |Hierarchial Message Descriptor (HMD) Column Descriptions |
No - Row number. Each row is sequentially numbered and identifies the order in which the data within the message is sent.
Row - Identifies the type of element. Valid values are class, attr (attribute), and assoc (association).
Property - The name of the class, attribute or association role name as it appears in the RIM.
RIM Source - Identifies the class from which the attribute or association originates.
Element Name - The name of the element as it appears in the R-MIM. This may or may not be the same as the value in Property. This value will be different when a class, association or role is cloned and renamed in the process of creating the R-MIM.
Short Name - The name of the element in the XML ITS. Refer to the HL7 Version 3 Standard: XML Implementation Technology Specification for more details.
InMET - In Message Element Type. This column points to the parent of the element within the current hierarchy.
OfMET - Of Message Element Type. Identifies the data type of attributes or class name of associations.
S - Message Element Type Source. Valid values are D (data type), N (new, being defined starting at this row), U (use, meaning that an element, but not its value, from a previous row in the HMD is being reused), C (CMET), I (Instance, refers to the reuse of a particular element and its value as defined previously in the HMD), and R (recursive, into itself).
Each group of the following columns appears in both the template and the Message Types:
C - Cardinality. This specifies the minimum and maximum number of occurrences of the message element.
D - Vocabulary Domain Specification. Clicking on this link will take you to the Domain Specification for this element.
CS - Coding Strength. Valid values are CWE (coded with exceptions, meaning that the code set can be expanded to meet local implementation needs) and CNE (coded no exceptions, meaning that the code set cannot be expanded).
M - Mandatory. Valid values are M (Mandatory) or Blank. An M in the field requires that some data be sent for this element. If the data is not known, a value of unknown, not given, etc. must be sent. An M in this column (for Mandatory) differs from a 1 in the Cardinality column in that an M indicates that the message cannot be validly parsed without a value in this field or without defining a default. If no default is provided, you either do not send a message or must send a value. An M in this column also differs from an R in the Conformance column (explained below).
N - Note. If one is provided, this is simply a free text note provided by the committee.
D - Default. Default value provided by the committee. If null is sent, the default should be substituted on receipt (i.e., if the default value is 10 and a null is sent, the receiving system should substitute 10).
D - Default Update Mode. This is a heading for the allowable set of values defined in the Update Mode Set column.
U - Update Mode Set. The allowable set of values for the mode identified in the Default Update Mode column.
C - Conformance. Valid values are R (required), NP (not permitted), and Blank (not required). A value of R (required) means that the message elements must appear every time the message description is used for an Interaction. If the data is available, the element must carry the data. If the data is not available, a blank may be sent. NP (not permitted) means that the message element is never sent for this message type. Blank means that conformance for this element is to be negotiated on a site-specific basis.
|2.8 |Message Types |
A message type has an assigned unique identifier and a description along with annotations. The specific message type is documented in the Hierarchical Message Description (HMD) and is associated with a specific D-MIM and R-MIM.
Message Type: Document Header (without contents) (RCMR_MT00001)
|Grid View |
|Table View |
|Schema |
|Example |
| |
| |
| |
| |
Description
This message type is used to convey status information about a document, without sending the document itself.
Annotations
|Type |
|Realm |
|Note |
|DN |UV |Universal development note |
|WT |UV |Universal walkthrough note |
The HMD specifies the order and constraints of particular set of attributes and relationships drawn from the RIM classes of interest. Each unique pattern of attributes and relationships is made explicit as "cloned" classes. A single HMD can specify different patterns of constraints for the same set of attributes as long as the constraints are at least as strict as those prescribed in the common message for the HMD. Constraints may be stricter (or "tighter") than the common message. This allows a single HMD to satisfy the needs of a number of related interactions. For example, an HMD may be defined to satisfy the information needs for adding a person to a registry. One of the message types defined for the HMD contains all relevant attributes. Different constraints can be applied in a related message type to update various person characteristics.
|2.9 |INTERACTIONS |
|2.9.1 |Overview |
Interactions are at the heart of messaging. The formal definition of an interaction is:
A unique association between a specific message type (information transfer), a particular trigger event that initiates or "triggers" the transfer, and the application roles that send and receive the message type. It is a unique, one-way transfer of information.
A single Interaction explicitly answers the questions:
1. Which type of system component sends a particular type of message;
2. How a system knows when to send a particular type of message;
3. What the particular message type is;
4. To what type of receiving system component the message type is sent;
5. What the expectations are, if any, for the receiving system to be able to send other associated interactions.
|2.9.1.1 |Application Roles |
Application roles describe the type of system component that sends and receives the message, answering questions 1 and 4. An application role has a name, a description and a unique identifier. The scope of responsibility for a particular application role is the complete set of interactions in which the system component participates, either as a sender or a receiver.
Application Roles are sometimes identified as being "loosely coupled" versus "tightly coupled." This distinction 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. Loosely coupled application roles do not assume common information is available, while tightly coupled application roles do assume information is available.
|2.9.1.2 |Trigger Event |
Question 2 of the Interaction definition is answered by referring to a trigger event. A trigger event is an explicit set of conditions that initiate the transfer of information between system components. A trigger event is described by a unique identifier, a name and the description of the condition that would cause information to flow. The set of conditions must be systematically recognizable by an automated system. Trigger events can be as simple as manual intervention, where a human user "invokes" a specific message transfer. In many cases the successful completion of a particular business transaction is also a trigger to send messages, such as a particular point in time (e.g., at midnight send all queued update transactions), or a relative interval of time (e.g., every 12 hours send accumulated information to a tracking system). A message may also be sent as a result of an "alert" event that results from monitoring a complex set of data elements for a particular pattern of values.
More than one interaction can be initiated by the same trigger event, but each interaction is triggered by only one trigger event. Trigger events are often defined in terms of state transitions for subject classes. These trigger events cause messages to flow because the state of a subject class is changing. These state transitions can be part of an expected business cycle or may be triggered because of exceptions in the normal business processes.
|2.9.2 |Message Types |
Question 3 is answered by referring to a specific message type. A message type has an assigned unique identifier and a description. The specific message type is documented in the Hierarchical Message Description (HMD) that is defined during the message development processes and is associated with as specific R-MIM.
The HMD specifies the order and constraints of particular set of attributes and relationships drawn from the RIM classes of interest with each unique pattern of attributes and relationships made explicit as "cloned" classes. A single HMD can specify different patterns of constraints for the same set of attributes as long as the constraints are at least as strict as those prescribed in the common message for the HMD. Constraints may be stricter (or "tighter") than the common message. This allows a single HMD to satisfy the needs of a number of related interactions. For example, an HMD may be defined to satisfy the information needs for adding a person to a registry. One of the message types defined for the HMD contains all relevant attributes. Different constraints can be applied in a related message type to update various person characteristics.
|2.9.3 |Receiver Responsibilities |
The definition of receiver responsibilities answers question 5. Receiver responsibilities refer to additional interactions that the receiving application role must initiate upon receiving the interaction in question. Receiver responsibilities do not necessarily exist for each interaction. Receiving a message may be considered a trigger event that causes information to flow, or there may be additional conditions that must be fulfilled prior to subsequent message(s) being sent. The receiver responsibilities is expressed as a list of the interactions the receiving application role must be able to send.
|2.9.4 |Interaction Models |
The interdependencies between interactions may be expressed as sequence diagrams. A sequence diagram expresses the same information but is read from the top down to indicate the expected sequence of related interactions. The purpose is usually described through a storyboard, which may be illustrated with storyboard examples.
[pic]
Figure 6: Sequence Diagram.
[pic]
|A |References |
Message Development Framework
HL7 Version 3 Standard: Message Development Framework, HL7 Version 3 Taskforce
HL7 Version 3 Standard: Administrative Management
HL7 Version 3 Standard: Administrative Management, HL7 Version 3 Taskforce
HL7 Version 3 Standard: Infrastructure Management
HL7 Version 3 Standard: Infrastructure Management, HL7 Version 3 Taskforce
HL7 Version 3 Standard: Health and Clinical Management
HL7 Version 3 Standard: Health and Clinical Management, HL7 Version 3 Taskforce
HL7 Version 3 Standard: Vocabulary
HL7 Version 3 Standard: Vocabulary, HL7 Version 3 Taskforce
HL7 Version 3 Statement of Principles
HL7 Version 3 Statement of Principles, HL7 Version 3 Taskforce stofprin
Method for the Development of Healthcare Messages
Method for the Development of Healthcare Messages, CEN TC 251
Object Oriented Software Engineering
Object Oriented Software Engineering, Ivar Jacobson, et al.
Object Oriented Analysis
Object Oriented Analysis, Peter Coad & Ed Yourdon
Open EDI Reference Model
Open EDI Reference Model, ISO/IEC CD 14662
Unified Method, Version 0.8
Unified Method, Version 0.8, Grady Booch & James Rumbaugh
UML Distilled
UML Distilled, Martin Fowler with Kendall Scott
|B |Appendix A: Act Properties and Moods |
|Table 1: Detailed behavior of Act properties with respect to the mood. |
|Property |Definition |Intent (and order) |Event |Predicate moods |Goal |
|Act.id |object id |object id |object id |object id |object id |
|Act.availability_time |time the object was created |time the object was created |time the object was created |time the object was |time the object was |
| | | | |created |created |
|Act.confidentiality_cd |applicable confidentiality policies. |confidentiality policy (at least |confidentiality policy (at least as strong |not used |confidentiality policy |
| | |as strong as in definition.) |as in definition. If preceded by an intent, | |(at least as strong as |
| | | |inherits that policy) | |in definition.) |
|Act.cd |name of defined action |name of intended action, |name of performed action, redundant if |name of predicated |name of goal action |
| | |redundant if action is identified|action is identified through a link to an |action, redundant if |(observation,) redundant|
| | |through a link to an act |act definition or intent |identified through a |if action is identified |
| | |definition | |link to an act |through a link to an act|
| | | | |definition or intent |definition |
|Act.txt |textbook-like description of the act |description of the intended |textual report of what actually happened in |textual description of |textual description of |
| | |actions, instructions (not just |the act |the predicate. A |the goal. A goal with no|
| | |repeating what is said already in| |predicate with no other|other values than the |
| | |the text of the act definition) | |values than the text is|text is only interpreted|
| | | | |only interpreted by |by humans |
| | | | |humans | |
|Act.activity_time |the time the act provider carries out the |the time(s) the action is |the actual time the act event happened |not used |not used |
| |action (e.g., business hours) |(tentatively) scheduled to | | | |
| | |happen, most intents will only | | | |
| | |use effective time leaving | | | |
| | |activity time open | | | |
|Act.effective_time |not used |constrains the effective time of |observation: physiologically relevant time |a time constraint on |the time targeted for |
| | |the event |(usually a simple point in time); |the predicate. For an |the goal (deadline,) |
| | | |Substance_administration: time (and |act event to match that|usually a simple point |
| | | |duration) the medication is actually given; |predicate, the act |in time or a range. |
| | | |transportation: the time range the payload |event effective time | |
| | | |is en route; surgical procedure: the time |must be within the | |
| | | |range between first cut and last suture. |constraint of the | |
| | | | |predicate. | |
|Act.status_cd |state of the act definition (see text |state of the intent (see text.) |state of the occurrence (see text) |by default set to |state of the goal (see |
| |describing the attribute.) | | |"active" (see text |text describing the |
| | | | |describing the |attribute) |
| | | | |attribute.) | |
|procedure.method_cd |method(s) available for the Act. No method |method selected, or method(s) |method employed in the occurrence, subset of|rarely used, constrains|rarely used, constrains |
| |code is applicable if not listed in the act|constrained, subset of the |the definition's method code set |the predicate |the goal to be evaluated|
| |definition |definition's method codes | | |only with a specific |
| | | | | |method, must be subset |
| | | | | |of methods in the |
| | | | | |definition |
|Act.interpretation_cd |interpretation codes applicable (reported) |not used |interpretation codes reported |interpretation code may|interpretation code may |
| |with this act | | |be given instead of a |be given instead of a |
| | | | |value range (e.g., if |value range (e.g., |
| | | | |potassium is low, ...) |potassium to be back to |
| | | | | |normal in two days) |
|Act.repeat_nbr |minimum/maximum number of a repeatable Act.|minimum/maximum number of |not used |can be used (together |can be used (together |
| |Most acts are repeatable and maximum is by |repetitions ordered | |with critical timing) |with critical timing) in|
| |default infinite | | |in the sense of: if 3 |the sense of: 3 |
| | | | |subsequent morning |subsequent morning |
| | | | |glucose values are |glucose values to be |
| | | | |high, ... |normal |
|Act.interruptible_ind |specifies defined act (or plan component) |specifies step in the care plan |not used |not used |not used |
| |as being interruptible |as being interruptible | | | |
|Observation.value ordered scales |specifies the absolute range of possible |not used |the actual value (or range of values if off |the predicated value |the goal criterion for |
| |observation values. | |scale.) |range |the value as a range |
|nominal scales |specifies the domain of the defined |not used |the actual value (or set of values if |the predicated value |the goal criterion for |
| |parameter | |alternatives could not be discriminated) |set |the value as a set |
|Observation.derivation_expr |an expression for calculating the value |same as in definition |same as in definition |same as in definition |same as in definition |
| |from linked input parameters | | | | |
|Substance_administration.doseform_cd |the set of doseforms available for this |the ordered doseform(s), usually |administered doseform |goal is not defined for|constrains the predicate|
| |medication act, though usually |just one | |other than observation |to a particular doseform|
| |Substance_administration acts are defined | | |acts |(not often needed) |
| |one per doseform | | | | |
|Substance_administration.route_cd |the set of routes applicable for the |the route(s) ordered or intended |the route actually chosen for administration|goal is not defined for|constrains the predicate|
| |medication, however, medication can be | | |other than observation |to a particular route |
| |administered over unusual routes | | |acts | |
|Substance_administration.dose_qty |a range defining the recommended dosage |an ordered dosage, may be a crisp|the dose administered |goal is not defined for|just another constraint |
| | |quantity or a constrained range | |other than observation |on the predicate |
| | | | |acts | |
|Substance_administration.strength_qty |a set of strengths, though medications are |the strength actually ordered, |the strength of the administered drug |goal is not defined for|just another constraint |
| |usually defined one per strength |may be empty since the order does| |other than observation |on the predicate |
| | |not need to concern itself with | |acts | |
| | |manufactured drugs | | | |
|Substance_administration.rate_qty |a range defining the recommended rate |a range (or crisp quantity) for |the actual rate by which drug was |goal is not defined for|just another constraint |
| | |the intended rate |administered |other than observation |on the predicate |
| | | | |acts | |
|Substance_administration.substitution_cd |specifies allowable kinds and reasons for |specifies allowable kinds and |specifies actual kind and reason for |not used |not used |
| |substitution (if any) |reasons for substitution (if any)|substitution (if any) | | |
|Substance_administration.dose_check_qty |not used (although could be used as in |not used (although could be used |used as per regional requirements (Japan use|goal is not defined for|just another constraint |
| |0.5(1 g Q4-6H but not more than 4 g/d) |as in definition) |case) |other than observation |on the predicate |
| | | | |acts | |
Endnotes
1. [source] In other models, the lower case letters "n" or "m" are sometimes used, indicating integer variables. This notation is not defined in the UML Notation Guide. The problem with using letters instead of the asterisk is that if the same letter is used more than once, it may be misunderstood to represent the same integer number everywhere. Furthermore, an "n" indicates some boundary specified elsewhere, while the asterisk ("*") indicates unbounded multiplicity, without the notion of any dependency between such multiplicities.
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- microsoft excel guide pdf
- excel 2010 user guide pdf
- excel user guide pdf
- first time home buyer guide pdf
- excel guide for beginners pdf
- guide to mutual fund investing
- nature communications guide to authors
- home buying guide pdf
- teacher s guide sri lanka
- teachers guide nie sri lanka
- etf guide pdf
- microsoft excel 2010 guide pdf