Copyright 2000 by HL7
Link to Subjects and Classes
Link to Categories and Data types
Link to Stewardship and Class interests and DIMs
This data model was HTML encoded by software prepared for the HL7. Comments on presentation links or any bugs encountered may be addressed to:
HQ@HL7.org (HL7 Headquarters staff).
Organization: HL7
Version: V 1-14 20000806
Developed by: Modeling and Methodology
|
Application_role HL7_committee Interaction Interaction_model_category |
Interaction_sequence Storyboard Storyboard_example |
Trigger_event Use_case Use_case_sequence |
It includes the information flows or interactions, the trigger events, the application roles that send and receive the interactions and scenarios that provide an interaction trace for a series of events.
It includes: the message information model which is the sub-set of the information model needed to support a set of messages; the hierarchical message description that maps the information content of the MIM into a set of message formats; and the message element type model which describes the type structure used to convey messages.
|
HL7_committee |
Model |
Project |
|
Actor HL7_committee |
Use_case Use_case_category |
Use_case_relationship |
This model advances the meta-model of the third release of the HL7 Version 3 MDF, as updated in December 1999.
It includes the datatype and domain model, extensions to the information, interaction and use case models, and the results of two complete revisions of the Message Design Model. The latter includes the message element type model, a model of the message information model, a model of the refined message information model (R-MIM) and the relationships between these artifacts and the elements of the HMD.
The vocabulary domain model has been updated to match the MDF chapter, and the message design sections are also updated.
|
|
|
An actor is a role played by someone or something that interacts directly with the elements represented by the classes in the information model. With one exception, actors cannot represent information systems. The exception is a special actor with the literal name "some information system". The name is chosen to reinforce the notion that use cases are not built on a priori knowledge of the functionality of specific healthcare information systems.
A short informative statement that allows people to determine, with certainty, whether a particular real world role is an instance of the actor.
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
The actors in the model are each given a unique name. The actor name is a singular noun or noun phrase.
The relationship between actors and the models of which they are a part.
|
|
|
Classes and attributes in the information model may have one or more alias names. These allow for special uses in HL7, such as short names, and for translations to other languages.
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
The alias name for the linked element.
A code indicating the use of this alias.
|
|
|
Application roles are abstractions that name roles that may be played by health-care information system components when sending or receiving HL7 messages. Thus they are a defined set of responsibilities with respect to interactions. The role may have responsibility to send or receive one or more interactions. The application role and its responsibilities may form the basis for establishing conformance specifications for a standard.
Application roles should be stereotyped with respect to their responsibilities for information about a subject class. The technical committee should start its thinking about application roles from the perspective that there are three fundamental purposes for message exchange, three basic "messaging modes". These are:
Declarative - This includes messages that are sent with the intent of conveying information from one party to another. For example, a healthcare provider might send a message every time a person is registered as a patient with that provider.
Imperative - This includes messages that direct or request a party to do something. For example, a healthcare provider might send a message to a laboratory every time the provider needs the laboratory to perform a test. Note, that even though the message must include information about the test and the patient the test is for, the primary purpose of the message is to request that the test be done.
Interrogative - This includes messages that ask for information, that ask a question. For example, a healthcare provider might send a message to an MPI mediator asking whether the MPI mediator has information about a specific person.
Application roles will have stereotyped names constructed as <subject class> <relationship>. These stereotypes are specific to the messaging modes.
- For the declarative mode, the typical roles are "declarer" and "recipient"
- For the imperative model, the typical roles are "placer" and "filler"
- For the interrogative mode, the typical roles are "questioner" and "answerer"
There is no requirement that a Technical Committee create all of these "<subject class><relationship>" roles. Nor is it is limited to these possibilities. But it is expected that the committee will consider these stereotypes.
The text that describes the application role and summarizes the interaction responsibilities that are part of that role.
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
An identifier assigned to the application role. The identifier is unique within the scope of the model in which the application role is defined. In HL7, committees manage the unique identifiers for their application roles, and concatenate the committee identifier as "Cnn_<identifier>."
A name assigned to the application role. The name is unique within the scope of the model in which the application role is defined.
A reference to the application role that is responsible for receiving the message involved in this interaction. The receiving role must be prepared to accept the message and to fulfill the receiver responsibility.
The sending role has responsibilities to recognize the trigger event for the interaction and to cause the appropriate message to be sent.
Links each Application role to the Subject class for which it plays a role. The nature of this relationship is stereotyped as discussed in the description for the Application_role.
The relationship between application roles and the models of which they are a part.
|
|
|
An association between classes depicts the occurrence of a reference attribute used to connect class instances (objects). The associated objects can be of the same or different classes. When the association is defined one of the two classes is designated the "source class" and the other the "target" class. These designations are necessary to unambiguously define an association, but the designations have no semantic implications about the roles of the associated classes within the information model being defined. The selection of which class to label as "source" is arbitrary.
A short informative statement that describes the relationship between the classes connected by the association.
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
Note, the version data must fit within the range of the applicable versions for both classes to which this element is attached.
A short action phrase that specifies the role of the destination class in the association. Each association between the same pair of classes must have a unique inverse name.
A short action phrase that specifies the role of the source class in the association. Each association between the same pair of classes must have a unique name.
A set of values and value ranges indicating the number of source class instances involved in the connection. In value ranges the minimum shall be zero or more and the maximum shall be equal to or greater than the minimum. The maximum number may be expressed as unlimited.
A set of values and value ranges indicating the number of destination class instances involved in the connection. In value ranges the minimum shall be zero or more and the maximum shall be equal to or greater than the minimum. The maximum number may be expressed as unlimited.
A reference to the class that is the target of the association.
A reference to the class from which the association perspective is captured.
|
|
|
Attributes in the information model are the major source of the data content used in HL7 communications. Attributes are abstractions of the data captured about classes. Attributes capture separate aspects of the class and take their values independent of one another. Attribute domain specifications are captured in datatypes.
A short informative description of the Class characteristic captured by the Attribute.
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
Note, the version data must fit within the range of the applicable versions for the class of which this element is a part.
An indication of whether the inclusion of the attribute is mandatory in all HL7 HMDs and messages. Setting the inclusion to mandatory in the information model is deprecated.
Singular nouns are used for attribute names. Attribute names are unique within the class they describe and within the set of attributes inherited by the class they describe. The terminal element of the name shall indicate the attribute type for the attribute.
Indicates whether this attribute may repeat when it is included in the message structure of a hierarchical message description. The default is false, non-repeating.
A link between an attribute and the datatype that has been assigned to it. An attribute is assigned a datatype the first time that it is used in an HMD, and retains that type thereafter.
The state attribute of a class contains a value indicating the current state of the class. In the event that the class has concurrent states, the attribute must be a set of state values.
A reference between an attribute and its attribute type. The attribute type code must also be the terminal component of the attribute name.
Many attributes are traced to equivalent content in HL7 Version 2.x. This connection is secondary to the path that traces an attribute to an HL7 field to a segment. It is provided for modelers who wish to specify particular segments for information model attributes.
Provides a linkage for an information model attribute to its equivalent version 2.x field, if such linkage exists and has been identified.
Provides an indication of the data type used in Version 2.x for a particular attribute, if such prior usage has been identified.
The relationship between attributes and the classes of which they are a part.
|
|
Constrains a coded attribute to a particular vocabulary domain.
For any class, the special attribute status_cd has as its domain all of the states of the class.
The strength of the constraint is either CWE (coded with exceptions) or CNE (coded, no exceptions). If no value is given, CWE is the default.
|
|
|
An indication of the form of the attribute, and of its usage. The use of attribute type words in attribute names aids in creating uniformity in the names, helps to avoid unintentional redundancy, and adds clarity to the model.
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
The full name of the attribute type.
The representation of the attribute type that is appended to the name of the attribute to indicate the attribute type.
A brief description of the intended usage of this attribute type.
A reference between an attribute and its attribute type. The attribute type code must also be the terminal component of the attribute name.
Each Attribute type may be implemented by one or more data types.
|
|
|
An abstraction of a set of real-world things (objects) such that all of the objects have the same characteristics and all instances are subject to and conform to the same rules. Classes are the people, places, roles, things, and events about which information is kept.
A short informative statement that allows one to tell, with certainty, whether a particular real world thing is an instance of the Class as conceptualized in the information model.
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
This variable indicates whether or not this Class is an abstract class. An abstract class is a class that can not be instantiated and is customarily the generalization class in a generalization/specialization structure.
The Classes in the information model are given a unique name. The Class name is a singular noun or noun phrase.
The linkage between a Class and the Subject area that is its primary residence. This must be established if a Class resides in more than one Subject area.
A reference to the class that is the target of the association.
The linkage between a generalization relationship and the supertype that participates in that connection.
The linkage between a generalization relationship and the subtype that participates in that connection.
A reference to the class from which the association perspective is captured.
A reference to the class that is the part class in the relationship.
The linkage between a Subject area and each of the Classes that are in that Subject area.
A reference to the class that is the composition the relationship.
The relationship between attributes and the classes of which they are a part.
The relationship between classes and the models of which they are a part.
|
|
|
A system is a published code system by an organization, that defines it, publishes it, maintains it, and thus guarantees for its usefulness and continuity.
If the source system includes named value sets or specifically identified tables, each of these is considered as an independent code source.
Rationale: This denormalization was undertaken because building a separate set of classes for the internal value sets and tables of a source system is very difficult, since there is not a single standard structure for such systems.
The name of the organization that maintains the code system. Examples are WHO, College of American Pathologists, ISO, IANA, and HL7.
The code system version for the term.
Code System - indicates the name of the code system. e.g. ICD, ICPM, ICPC, SNOMED, 639-1, MIME types, ...
Table Identifier - the table number or identifier (if one exists) in the source vocabulary where this concept originated.
Each coded term comes from a single code system.
Each value set is based on a single code system.
This table shows the relationship between HL7 concepts and codes and descriptions from specific vocabularies. It allows a user of HL7 to see how the concepts in a given domain can be represented within a specific vocabulary/coding system. It links one specific concept to one term in a particular code system.
Code - the text string used within the code system to identify this concept.
A textual representation of the meaning of this entry as it is represented in the coding system from which it came.
Any term may have a definition stored. For the terms that are referenced from external coding systems, the definition will not be included..
These terms may be used to maintain HL7 code tables, in which case, the definition is mandatory.:
A textual name for the term.
A general purpose textual field for recording specific information about this code, or details about the rationale for creating, modifying, or deleting this particular table entry.
ISO Language - the language (English, German, French, Italian, etc.) that is used in the description. The language codes come from the vocabulary domain of Language and are specified by ISO 639:1988 (E/F) Code for the representation of names of languages.
Map Relationship - the closeness or quality of the mapping between the HL7 concept (as represented by the HL7 concept identifier) and the source coding system. The values for the relationship come from the MapRelationship domain and are patterned after the similar relationships used in the UMLS Metathesaurus. Examples of values for map relationship are: exact, broader than, narrower than, etc. Because the HL7 coding system is the master reference for the definition of the concept, the map relationship for HL7 coding system entries will always be Exact.
HL7 Status - the status of this entry within this table. The values for Status come from the vocabulary domain EditStatus. Some values for status are Proposed, Rejected, Active, Obsolete, and Inactive.
The code system version in which this term was first introduced.
The code system version in which this term was first deleted or changed.
Code System Vout - the version number of the code system at the time the code was retired or deleted.
Each linked observation identifier is drawn from a particular code system. Initially these will all be drawn from LOINC.
Links a coded term to a single concept.
Each coded term comes from a single code system.
|
|
|
An association between classes that depicts the relationship between a composite aggregate class and its component parts.
A short phrase representing the nature of the relationship from the perspective of the composite class. Example phrases are: "includes", "contains", "consists of", "has as parts". Other phrases may also be used. If no phrase is specified, the phrase "contains" will be assumed.
A short informative description of the composite aggregation connection.
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
Note, the version data must fit within the range of the applicable versions for both classes to which this element is attached.
A set of values and value ranges indicating the number of part class instances involved in the aggregation. In value ranges the minimum shall be zero or more and the maximum shall be equal to or greater than the minimum. The maximum number may be expressed as unlimited.
A short phrase representing the nature of the relationship from the perspective of the part class . Example phrases are: "is included in", "is contained in", "is part of", and "is a component of". Other phrases may also be used. If no phrase is specified, "is part of" will be assumed.
A reference to the class that is the composition the relationship.
A reference to the class that is the part class in the relationship.
A composite data type consists of one or more named and typed components.
|
|
|
There are three different types of concept-to-concept relationships. Each is identified by a relationship type code, and each relates a contained or included concept to a container concept.
The Value Set Relationship Table records the relationship between HL7 maintained value sets and the concepts that are values within the value set. An HL7 maintained value set can be composed from individual concepts, other value sets, or both.
Editor's notes for the domain. A general purpose textual field for recording specific information about the entry, or details about the rationale for modifying this particular table entry.
Generality - indicates whether the concept that is the target should be interpreted as itself, or whether it should be expanded to include its child concepts, or both when it is included in the source domain/valueset.. Possible values are: Abstract, Specializable, and Leaf. Leaf means that only the concept itself is included in the domain. Abstract means that only descendents of the concept are included in the domain, and Specializable means that the concept itself and its descendents are included in the domain. The values for the Generality column come from the ConceptGenerality domain.
Operator - the name of the relationship that exists between the value set and the concept that is being included. In the initial implementation, the only relationship is Include, which means that the domain contains the concept that is linked as the content. Relationship names come from the ValueSetOperator domain.
Sequence number operates within a given version to sequence the operations for a given "container" value set. So long as the only operator used is "include," the sequence is not needed. However, the "exclude" and "union" operators will produce sequence dependent results if they are used in conjunction with other operators such as "include."
Status - the status of the item. The values for Status come from the vocabulary domain EditStatus. Some values for status are Proposed, Rejected, Active, Obsolete, and Inactive.
The relationship types are:
DV - Domain contains value set. In this relationship, the container is a domain and the target is a value set whose concepts provide the content of the domain.
VI - Value set inclusion. In this relationship the container is a value set and the target is either a value set or concept to be part of the content in the value set. The nature of the inclusion is determined by the generality code.
Vout - the version number of the domain specification database at the time this entry was updated or deleted. A blank Vout value means that the entry continues to exist in the current version of the table.
|
|
|
Datatypes are used to express the type of an attribute or of a data type component. A data type may be composite, primitive, an alias or a generic type parameter.
A generic type parameter contains a parameter that is part of the definition of a generic data type. Each generic type parameter is part of the definition for a single generic type.
A composite data type contains one or more components.
An alias provides an alternative name, alternate type code and additional description for another data type.
A primitive data type is a data type that is defined entirely by its specification. A primitive data type may have generic type parameters.
A generic data type is a type that has one or more generic type parameters. It provides a pattern for instantiating a specific, usually composite, data type.
A detailed description or specification for the data type. All such descriptions are assumed to also reference a broader specification of data types.
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
A data type may be defined as being "internal". An internal type is used only to define other composite data types. Internal types shall not be used in messages. For example, we define a type Binary that contains pure raw data bits, and that is used only by Multimedia Enabled Free Text.
The formal name for the data type.
The formal code assigned by the Control/Query Committee for this datatype. This is the representation of the data type that appears as the data type for attributes of the information model and data type components in the data type model.
Each data type generalization provides sub-types for a single super-type..
Each component is linked to a single type either directly or through a generic type parameter.
Each data type generalization includes a single sub-type.
Relationship between a Generic Type Parameter and the Generic type for which it is a parameter.
Determines the set of types that a generic type parameter may implement.
This relationship defines the particular instantiation type for a generic instance.
Each Attribute type may be implemented by one or more data types.
If a MIM attribute is associated with a RIM attribute that does not have an assigned data type, the MIM attribute may be assigned an alternative, working data type. This association must not be instantiated otherwise.
A link between an attribute and the datatype that has been assigned to it. An attribute is assigned a datatype the first time that it is used in an HMD, and retains that type thereafter.
The relationship between data types and the models in which they are first defined.
|
|
|
A data type category collects data types that represent similar real world concepts, or are represented in a similar fashion.
Th description of the data type category expresses the unifying concept that causes a set of data types to be included in this category.
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
The name given to the data type category.
The relationship between data type categories and the models of which they are a part.
|
|
|
A component is an element of a data type that may be valued when the data type is used in HL7 communications. The component takes its type from a data type that is any of - primitive, composite, or generic type parameter.
A component of a composite data type is like a variable, i.e. it has a name and a type. The type can be declared to be included by reference instead of by value. This is useful if you know such a component mentions an instance that is already mentioned elsewhere in the communication. In languages such as Java, where objects are always handled through references this does not make any difference.
The description of a component should include its role within the composite of which it is a part and its relationships, if any, to other components of the same composite.
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
The component type can be declared to be included by reference instead of by value. This is useful if you know such a component mentions an instance that is already mentioned elsewhere in the communication. In languages such as Java, where objects are always handled through references this does not make any difference.
The formal name of the data type component.
Each component is linked to a single type either directly or through a generic type parameter.
|
|
|
Types can maintain an inheritance relationship with each other. We explicitly allow (and use) "multiple inheritance". However, we do use inheritance as a way to specialize subtypes from general super-types. Rather we go the other way. Abstract generalized types are used to categorize the concrete types in different ways. Thus one can get hold of all types that have a certain property of interest.
For instance, we define the generalized type Quantity to subsume all quantitative types. This is used to define one type Ratio as a ratio of any two quantities.
Similarly, we define a data type Interval that is a continuous subset of any type with an order relation. All types with an order relation are subsumed under OrderedType. Note that not all quantities are ordered (e.g. vectors are not) and there may be non-quantities that have an order relationship (ordinals, e.g. military ranks).
A statement of the nature of the generalization relationship.
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
The DT generalization is of one of two stereotypes. "Extends" implies that the sub-type has a "value" that is of the super type and then adds components of its own. "Restricts" implies that the sub type is a constrined version of the super type.
Each data type generalization includes a single sub-type.
Each data type generalization provides sub-types for a single super-type..
|
|
|
Captures each update of the vocabulary domain tables in a version, including the when the editing took place, who performed it, and comments as to what was done.
Comment - a summary of why the edits were made, and what was done.
The date and time that the edit session began
Who - an identifier of the person who actually edited the database. People are identified by reference to a directory where each person is assigned a unique identifier, and where locating information about the person can be found.
For whom - an identifier of the person or organization for whom the edit was made. For example, a person may be making edits as authorized by the Vocabulary TC, or on behalf of the TC for which they are the facilitator. People and organizations are identified by reference to a directory where each person or organization is assigned a unique identifier.
Version - the version number of the edit session. This number is incremented by 1 each time a new edit session takes place. The version number is used as the value of Vin and Vout as appropriate to track which table entries in the domain specification database were added, modified, or deleted during the session.
For specific tables, Vin provides the version number of the domain specification database at the time that this entry was added or updated.
|
|
|
Generalization is a relationship between a class and subtypes of the class. A supertype can be associated with more than one subtype. Each of the subtypes associated with a single supertype is mutually exclusive. A subtype may be associated with more than one supertype. The hierarchy or lattice of generalizations is called a generalization relationship. The subtype inherits the attributes, and associations, and of all of its supertypes.
A short informative description of the Generalization relationship.
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
Note, the version data must fit within the range of the applicable versions for both classes to which this element is attached.
The linkage between a generalization relationship and the supertype that participates in that connection.
The linkage between a generalization relationship and the subtype that participates in that connection.
|
|
A generic type parameter contains a parameter that is part of the definition of a generic data type. Each generic type parameter is part of the definition for a single generic type.
The most common form of generic type parameter provides an instantiation type, drawn from two or more types.
Other generic type parameters constrain the generic type, such as the collection type and multiplicity for a Collection.
Establishes the content for a generic type parameter that defines a property of a generic type other than an instantiation type.
This relationship defines the particular instantiation type for a generic instance.
Determines the set of types that a generic type parameter may implement.
Relationship between a Generic Type Parameter and the Generic type for which it is a parameter.
|
|
|
A structure that completely defines the structure of a set of messages, and reflects the relationship of the elements of these messages to components of the Refined Message Information Model from which it derives and the Message Element Types that it defines or uses.
A short textual description of the messages covered in the HMD..
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
Arbitrary identifier assigned by Technical Steering Committee. Committees may assign an interim identifier that starts with the committee's identifier, as "Cnn_<identifier>" so long as this composite identifier is unique.
The HMDs in the model are each given a name.
A MIM should support a single project.
A reference to the HMD that contains each HMD row.
Each message structure is contained in a single HMD.
The relationship between hierarchical message descriptions and the models in which they are first defined.
|
|
|
Unique identifier assigned to each of the Technical Committees and Special Interest Groups of the HL7 Working Group.
Name of the individual who facilitates modeling for this committee.
Assigned committee identifier.
The approved mission statement or charter for this committee.
The name of the Technical Committee or Special Interest Group.
Links a model to the committee that prepared it.
Establishes the relationship between committees and the projects for which that committee is responsible.
An attribute row represents a single attribute in the R-MIM.
There is one class row in an HMD. This row is the root of the HMD.
|
|
|
Constrains a coded HMD attribute row to a particular vocabulary domain. Links each coded attribute in an HMD to the code domain that may be used to value it.
For any class, the special attribute status_cd has as its domain all of the states of the class. In an HMD domain specification, the special domain name '@state' can substitute for the domain name. If held is a valid state, <@state> and <@state - (held)> are valid domain specifications.
May specify the realm of applicability for this attribute row.
The strength of the constraint is either CWE (coded with exceptions) or CNE (coded, no exceptions). If no value is given, CWE is the default.
|
|
Indicates the type of the note. Types include:
RV : Required value
CP : Conditional Presence
CN : Constraint
DM : Domain
CT : Comment
Links an 'other' R-MIM row into a message.
An relationship row represents a single association, aggregation or inheritance relationship traversed in the R-MIM graph walk.
Association represents the linkage between two association nodes in which one refers to the instance of another. (See MDF MET source "I".
Association represents the linkage between two association nodes in which one refers to the instance of another. (See MDF MET source "I".
Common message element type linkage. Class links the CMET defined by a particular message type (in a particular HMD) to the HMD row (allways a relationship row) that it types as a CMET.
|
|
|
The rows of an HMD.
Captures the base MET name that a particular row possesses (row is "of" type MET).
Captures the set ("|" delimited) of METs that this row is "of."
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
Indicates the source of the MET - reuse a definition from this HMD, CMET or data type.
Indicates the nesting level of the row in the HMD.
Each message row control controls the presence of one unsubsumed HMD row in the message structure of which the message row control is a part.
A reference to the HMD that contains each HMD row.
|
|
|
An association between a specific message (information transfer), a particular trigger event that initiates or triggers the interaction, and the roles that send and receive the interaction. An interaction is a single, one-way transfer of information. Within itself, an interaction may not specify a return message. An interaction may, however, establish a responsibility for the receiver of its message, and this responsibility may require that the receiver initiate a particular trigger event/interaction subsequent to the receipt. That follow-on interaction may have the effect of continuing or completing a transaction that requires two or more linked message exchanges.
Provides a description of the data content of the interaction, usually expressed in terms of the class instances that are expected to be part of the message sent by the interaction.
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
An identifier assigned to the interaction. The identifier should be unique within the scope of the model in which the interaction is defined. In HL7, committees manage the unique identifiers for their interactions, and concatenate the committee identifier as "Cnn_<identifier>."
A reference to an interaction that the receiver of the message must initiate once receipt of the message is acknowledged. This is an optional element in that there may no follow-on responsibility. Transactions can be established through a chain of receiver responsibilities for individual interactions.
Each interaction shall include a link to a single message structure that the interaction will transfer.
The sending role has responsibilities to recognize the trigger event for the interaction and to cause the appropriate message to be sent.
A reference to the application role that is responsible for receiving the message involved in this interaction. The receiving role must be prepared to accept the message and to fulfill the receiver responsibility.
A reference to an interaction that the receiver of the message must initiate once receipt of the message is acknowledged. This is an optional element in that there may no follow-on responsibility. Transactions can be established through a chain of receiver responsibilities for individual interactions.
A reference to the trigger event that triggers or initiates this interaction.
The relationship between interactions and the models of which they are a part.
|
|
|
A major category of information represented in the interaction model. An aggregation of interrelated interactions and application roles. A category allows portions of a large model to be viewed as a whole thereby eliminating some complexity involved in understanding a large model.
Short informative text describing the interaction model category so as to be clear what type of interactions and application roles it includes.
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
The name given to the interaction model category. The identifier for the committee defining this category is prepended to the name as Cnn.
Interaction model categories may be nested.
Interaction model categories may be nested.
The relationship between interaction model categories and the models of which they are a part.
|
|
|
Captures the sequence in which a particular interaction is included in a storyboard.
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
The order in which the interaction participates in the Storyboard.
Each storyboard is made up of a sequence of interactions, a sequence of use cases, or both.
|
|
|
Is a subset of the HL7 Reference Information Model (RIM) that contains only those classes, attributes, states and relationships necessary to support the messages to be specified for a particular project. The acronym for message information model is MIM.
The elements of the MIM may have their optionality and/or cardinality constrained beyond the levels set in the RIM. For example, if a connection is optional in the RIM, it may be constrained to be mandatory in the MIM. Similarly, an attribute that may repeat any number of times in the RIM may be constrained in the MIM to a specific number of repeats.
In selecting classes, attributes, states and connections for inclusion in a MIM, a Technical Committee should follow the following process and rules. The TC is selecting the elements of a MIM that will contain: Classes; Attributes (perhaps with constrained optionality);States; Instance connections (perhaps with constrained cardinality); and whole part connections (perhaps with constrained cardinality).
The selection rules are:
a) all selections must come from the RIM of from a single DIM that is a subset of the HL7 RIM;
b) for every attribute selected, the committee must also select the class of which that attribute is a part;
c) for every state selected, the committee must also select the class of which that state is a part;
d) all state transitions between states selected for inclusion in the MIM shall be deemed members of the MIM, too.
e) for ever instance connection and whole part connection that is selected, the committee must also select both of the classes that are connected by that connection; and
f) any class that is selected must meet one of the following two criteria:
i) the class contains at least one selected attribute, or
ii) the class participates in two selected connections (instance or whole part).
The version of HL7 models in which this MIM was first balloted. Balloting will freeze the contents of the MIM. Future changes to the MIM must be made with a new MIM, established under a new id.
Describes the general set of messages (HMDs) that will be built from this MIM.
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
Arbitrary identifier assigned by Technical Steering Committee. Committees may assign an interim identifier that starts with the committee's identifier, as "Cnn_<identifier>" so long as this composite identifier is unique.
A brief descriptive name for the MIM. This may be the same as the name of the supported project.
A reference to the model (RIM version) from which all of the elements of the MIM will be drawn.
Each R-MIM refines a single MIM.
A MIM is a container holding links to individual components of the information model.
A MIM is a container holding links to individual components of the information model.
A MIM is a container holding links to individual components of the information model.
A MIM is a container holding links to individual components of the information model.
|
|
|
An element of a message type that controls the use of a particular HMD row in messages defined by the parent message type. The message row control has one subtype that relates to HMD attribute rows.
Describes the requirement of information systems to send, or receive and process, this message element in order to claim conformance to the HL7 messaging standard defined by this message type. Values are: Required (R) and Not Required (N).
Expresses a particular constraint for this row in this type.
A notation that captures the default value for this row in the message type. It provides a value that a sending system may insert when creating a message instance if it has no other value to use.
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
Shows whether a message element may appear and if it may be null.. A mandatory or required message element may appear within an optional message element. If the outer message element, which is optional, actually appears in a message instance, any mandatory inner element must appear Possible values are: Mandatory (M), and Optional (O)..
Describes whether the message element may repeat. Shows the minimum and maximum number of repetitions for this row (and its subordinates) in this message structure. It is not consistent to have a minimum number of repetitions of zero unless the Inclusion value is Optional.
Each message row control controls the presence of one unsubsumed HMD row in the message structure of which the message row control is a part.
A reference to the message structure of which each message row control is a part.
|
|
|
A message type is part of an HMD. It defines the specific information transfer that occurs in an interaction to meet the requirements of use cases. It is a set of constraints applied to the message elements defined in the HMD. These are represented by a set of columns in the HMD. The content for those columns is specified by the message row control instances that are parts of the message type.
The message type is an atomic unit in that the entire information content defined by the message type will be sent in an interaction, or no part of it will be sent. No further decomposition is possible.
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
Arbitrary, unique identifier assigned by Technical Steering Committee. Committees may assign an interim identifier that starts with the committee's identifier, as "Cnn_<identifier>" so long as this composite identifier is unique.
Identifies that this message type structure is common to all of the message types in this HMD.
Common message element type linkage. Class links the CMET defined by a particular message type (in a particular HMD) to the HMD row (allways a relationship row) that it types as a CMET.
Each interaction shall include a link to a single message structure that the interaction will transfer.
A reference to the message structure of which each message row control is a part.
Each message structure is contained in a single HMD.
|
|
A linking element that includes an individual aggregation relationship from the RIM into a particular MIM.
Expresses a multiplicity for the part in this aggregation that applies to all uses of the aggregation in this MIM, and that is a tighter constraint than that recorded in the RIM. This attribute must be valued.
|
|
|
A linking element that includes one individual association from the RIM into a particular MIM.
Expresses a multiplicity for the source class in this association that applies to all uses of the association in this MIM, and that is a tighter constraint than that recorded in the RIM. This attribute must be valued.
Optional attribute expresses a multiplicity for the target class in this association that applies to all uses of the association in this MIM, and that is a tighter constraint than that recorded in the RIM. This attribute must be valued.
|
|
|
Includes individual attributes from the RIM into a particular MIM, provided that the parent class for the attribute is also in the MIM..
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
This attribute expresses whether the inclusion of the attribute in the HMD and message structures derived from the HMD is mandatory. If the inclusion of the attribute is mandatory in the RIM, it must also be mandatory in the MIM. The default is the inclusion constraint for this attribute in the RIM.
This attribute expresses whether the attribute may repeat in a message. The repeatability applies to all uses of the attribute in this MIM, and must be a tighter constraint than that recorded in the RIM. The default for this attribute is the repeatability assigned to the attribute in the RIM.
Each R-MIM attribute is based on one MIM attribute.
If a MIM attribute is associated with a RIM attribute that does not have an assigned data type, the MIM attribute may be assigned an alternative, working data type. This association must not be instantiated otherwise.
A MIM is a container holding links to individual components of the information model.
|
|
Constrains a coded MIM attribute to a particular vocabulary domain.
For any class, the special attribute status_cd has as its domain all of the states of the class.
The strength of the constraint is either CWE (coded with exceptions) or CNE (coded, no exceptions). If no value is given, CWE is the default.
|
|
Includes individual classes from the RIM into a particular MIM.
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
A MIM is a container holding links to individual components of the information model.
A linking element that includes one individual generalizations from the RIM into a particular MIM.
|
|
Provides an abstract generalization for the MIM links to association, aggregation, and generalization connections in the RIM.
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
A MIM is a container holding links to individual components of the information model.
|
|
Includes an individual state into the MIM, provided that the parent class for the state is also in the MIM.
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
A MIM is a container holding links to individual components of the information model.
|
|
|
This class in the meta-model contains the elements necessary to uniquely define an aggregate model, to establish its provenance and scope, and to link it to each of the elements that make up that model.
A model is a collection of subject areas, scenarios, classes, attributes, use cases, actors, trigger events, interactions, etc. that depict the information needed to specify HL7 Version3 messages. This model is further divided into four specific models - a use case model, an information model, an interaction model, and a message design model..
A short narrative describing the scope and intent of the model.
A short form identifier of the organization responsible for the publication and maintenance of the model. . For HL7, this name shall be "HL7."
The date the model was last modified by the model developing organization.
A unique identifier assigned to the model by the developing organization. In HL7, these identifiers will be assigned by the Modeling and Methodology Committee.
A descriptive title for the model. The name in combination with the version number shall be unique within the set of models developed by any particular model developing organization.
A number showing the release level of the model. The version number, in combination with the name, shall be unique for all public releases of the model.
A reference to the model (RIM version) from which all of the elements of the MIM will be drawn.
Links a model to the committee that prepared it.
The relationship between data types and the models in which they are first defined.
The relationship between actors and the models of which they are a part.
The relationship between subject areas and the models of which they are a part.
The relationship between use case model categories and the models of which they are a part.
The relationship between application roles and the models of which they are a part.
Sets relationship between model elements and the models of which they are a part.
The relationship between classes and the models of which they are a part.
The relationship between scenarios and the models of which they are a part.
The relationship between interaction model categories and the models of which they are a part.
The relationship between interactions and the models of which they are a part.
The relationship between hierarchical message descriptions and the models in which they are first defined.
The relationship between data type categories and the models of which they are a part.
The relationship between use cases and the models of which they are a part.
|
|
|
The Observation Identifier to Value Set Linking Table is used to link an observation identifier, like a LOINC code (Logical Observation Identifier Names and Codes), with a value set. This table is used when it is desirable to specify the exact value set that should be associated with a coded observation identifier as used in a service event, assessment, or observation instance.
A general purpose textual field for recording specific information about this code, or details about the rationale for creating, modifying, or deleting this particular table entry.
Status - the status of this entry within this table. The values for Status come from vocabulary domain EditStatus. Some values for status are Proposed, Rejected, Active, Obsolete, and Inactive.
The version number of the table at which this entry was deleted. A blank Vout value means that the row continues to exist in the current version of the table.
Each linked observation identifier is drawn from a particular code system. Initially these will all be drawn from LOINC.
|
|
|
The specification of a particular, coherent set of messages and events based around one (or a few) Subject Classes. A project is undertaken to address a current need for standardizing information that flows between a number of parties in healthcare. A project also defines a ballot package that might be advanced independently of other HL7 ballot packages.
The date on which the project scope was published in the ANSI PINS system.
Arbitrary identifier assigned by Technical Steering Committee.
Brief descriptive name for the project.
The approved scope statement for the project. It defines the area of healthcare functionality that needs to be supported by HL7 messaging and is a high level use case that encompasses the entire project.
Date on which the project was approved by the TSC.
A MIM should support a single project.
Establishes the relationship between committees and the projects for which that committee is responsible.
|
|
|
The Refined message information model (R-MIM) is a hybrid between a class model and an object model. Each class, attribute and association in the MIM is part of the R-MIM.
In addition, classes in the MIM may be cloned in the R-MIM. That is, they may be represented more than once. This is done to allow the messages to be tailored to the specific needs of different instances of a class. For example, both the Person class has roles for both patients and doctors. By and large, the attributes and associations of Person that are important to the patient role are different from those important to the doctor role. Cloning allows these differences to be represented explicitly in the R-MIM.
When a class is cloned, the clone must be given a unique name, and the original may be re-named, as well. Both the clone and the original may be constrained (beyond the constraints of the MIM) independently. Constraints involve removing attributes, tightening association cardinality, discarding associations and reducing vocabulary domains.
The R-MIM is displayed both as a UML diagram, and in a two-level tabular format in which each class and clone is a primary row, and the attributes and associations of those classes comprise the second-level rows. Selected attributes of the meta-model provide 'lay-out' information for the tabular format.
Identifies the first class node in the tabular display of the R-MIM.
A compound data element that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
A unique identifier for the R-MIM.
Each R-MIM refines a single MIM.
|
|
Constrains a coded RMIM attribute row to a particular vocabulary domain.
For any class, the special attribute status_cd has as its domain all of the states of the class.
The strength of the constraint is either CWE (coded with exceptions) or CNE (coded, no exceptions). If no value is given, CWE is the default.
Expresses the presence of selected attributes in the R-MIM.
Each R-MIM attribute is based on one MIM attribute.
|
|
|
Expresses the presence of selected classes or clones thereof in the R-MIM.
Pointer to the first child attribute row for this class row.
Pointer to the first child relationship row for this class row.
Shows the active parent relationship for an inherited row. Reflects the combined effects of inheritance and cloning.
Establishes the true parent for each association and attribute. Is required because the act of cloning precludes determining this association through the information model or MIM.
|
|
Indicates the type of the note. Types include:
RV : Required value
CP : Conditional Presence
CN : Constraint
DM : Domain
CT : Comment
|
|
|
A note may be placed on any row of an R-MIM or of a Hierarchical Message Definition. These notes clarify the semantic intent of the Technical Committee.
Notes within an HMD are identified by number.
Captures the subject, a column of the HMD, to which the note applies.
|
|
Expresses the presence of special rows in the R-MIM. There are two types of such additional rows:
item : Represents the individual elements of the message that make up a Set or List of elements, as required by repeating attributes or associations.
stc : Represents the presence of a sub-component of a data type in the message. These components are exposed in to allow the expression of constraints against them.
Coded value for the type of the other row. See definition of the RMIM_other_row class for the code values and their meaning.
Each 'other' node arises as a result of some other node, its parent.
|
|
Expresses the presence of selected association nodes (UML roles) in the R-MIM. Each relationship in the MIM and R-MIM produces two rows in the tabular R-MIM, one for the appearance of each end of the relationship in one of the R-MIM classes or clones.
Expresses whether this half-relationship is intended to be followed in building an HMD. This value is not normative. It may be over-ridden. When the R-MIM is diagrammed in UML, the presence of a blocked path is shown by making the UML role for the other end of the relationship unnavigable.
Each RMIM relationship row may be paired with a second such row to comprise a complete relationship.
Each RMIM relationship row may be paired with a second such row to comprise a complete relationship.
The R-MIM is modeled by the Rows that make up its tabular expression.
Expresses the minimum and maximum number of occurrences for an association or an attribute in the context of the R-MIM.
Expresses the constraints on this row for conformance testing. Possible values are:
R: required for conformance
(blank): not required for conformance
NP: not permitted to appear in his message variant (only used in message row controls, not in R-MIM).
Captures constraints and notes for a given row in the R-MIM and HMD. The type of note and its contents must both be expresses. The types provided for include:
Required value : states a value and, in the presence of repetition, how many times the value can/must appear
Conditional Presence : states a value that must or must not be present based on the value of another element or sub-component that is higher in the HMD
Constraint : a verbal expression of a constraint
Domain : a domain specification, as described in the vocabulary chapter
Comment : any general comment; this label should not be used for items that can be described with any of the other labels.
A coded value drawn from the possible modes of updating that occur when an attribute is received by a system that already contains values for that attribute. The update modes and their codes are:
R : replace (this is the default)
D : delete
I : ignore
NA : not applicable
V : verify: confirm that it exists
K : key: when creating an element store it; when updating an element confirm that it exists.
The following codes apply when updating individual items in a set:
ESA : edit set: add item
ESC : edit set: change item
ESD : edit set: delete item
ESAC : edit set: add or, if the item exists, change item
The default value for this attribute. If this field is blank or Null, the default is 'NULL'. If the field contains 'No" then no default specified. Otherwise, the field contains the value of the default and if the value is an integer it must be enclosed in quotes.
A compound data element that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
If this attribute has a value of "True" then this message element must have a non-null value in order for the receiver to process the message.
The name of the row in the R-MIM. Rows representing attributes should not be renamed.
Points to the next sibling node in the tabular R-MIM.
Points to the previous sibling node in the tabular R-MIM.
A shortened version of the name for the row.
A set of utterances from the list of values for 'default_update_mode.'. The sender may change the update mode instance by instance to any of the values in this list.
Establishes the true parent for each association and attribute. Is required because the act of cloning precludes determining this association through the information model or MIM.
Each 'other' node arises as a result of some other node, its parent.
Shows the active parent relationship for an inherited row. Reflects the combined effects of inheritance and cloning.
Expresses the presence of selected states in the R-MIM.
|
|
|
The identification of a unique combination of attribute value(s) and connections which are of interest about a subject class.
The enumerated States for each Subject class must include an "Initial state" from which some designated state transition moves the class to one or more active states.
A short informative description of the State.
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
Note, the version data must fit within the range of the applicable versions for the class of which this element is a part.
The name of this particular state which shall be unique within this class.
The condition or set of conditions that when true about the attribute(s) and connections of the parent subject class identifies that the subject class is in the declared state.
States may be defined as sub-states of a parent, provided that all of the states for a given class have unique names.
States may be defined as sub-states of a parent, provided that all of the states for a given class have unique names.
This relationship between states and the subject classes of which they are a part.
|
|
|
Captures the semantics of transitions from state-to-state for the Subject classes. Note that a legal transition may return to the same state from which it started.
State transitions also are a critical link between leaf-level use cases from which the transitions stem, and the trigger events identified with the transitions.
A short, informative description of the state transition.
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
Note, the version data must fit within the range of the applicable versions for both of the states to which this transition links.
A word or phrase that reflects the event that causes the transition. The name shall be unique with respect to the state from which the transition starts. This label may be the same as the name of the trigger event identified with the Transition.
A leaf-level use case describes the events that result in a single state transition of the subject class.
Although the instance connection from use case to state transition is optional, this is only because not all use cases are leaf-level. At the leaf-level, each use case should describe one and only one state transition.
This connection from state transition to trigger event is only optional because we do not expect all possible trigger events to be defined in HL7. Nevertheless, any state transition that is described in a use case must be linked to a trigger event.
Note that because of the above condition, and because of the condition on the instance connection from a use case to a state transition, there is a mandatory (1,1) relationship from any leaf-level use case to one trigger event.
The relationship from trigger event to state transition is (1..*) because although the event will probably drive the Subject class to a single state (e.g. "Canceled") and the transitions may start from several states. Thus one trigger event may identify many transitions.
|
|
|
A storyboard is a statement of health care relevant events defined as a sequence of leaf-level use cases or interactions. The storyboard provides one set of use case instances that the modeling committee expects will typically occur in the domain.
A storyboard may also be expressed as a subset of the interaction model in which case the representation includes all interactions that are implied by the trigger events associated with the sequence of use cases or are implied by the sender and receiver responsibilities of those interactions. Usually, an interaction diagram is constructed to show a group of interactions for a single storyboard.
The collection of storyboards that HL7 may publish does not limit the ways in which HL7 can be applied; other combinations of trigger events, interactions, and application roles that are consistent with the interaction model may also be used.
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
An identifier assigned to the storyboard to simplify references to it. The identifier should be unique within the scope of the model in which it is defined. In HL7, committees manage the unique identifiers for their storyboards, and concatenate the committee identifier as "Cnn_<identifier>."
A short phrase that provides a descriptive title for the storyboard.
The purpose for which the storyboard was created. Frequently it describes the generic set of actions that the storyboard represents.
Each storyboard is made up of a sequence of interactions, a sequence of use cases, or both.
Each storyboard is made up of a sequence of interactions, a sequence of use cases, or both.
Each storyboard example provides a real world example for a single storyboard..
The relationship between scenarios and the models of which they are a part.
|
|
|
Provides a real-world example of the sequence of events captured in a Storyboard.
A narrative example from the real world that describes a set of events represented by the sequence of use cases that make up the Storyboard which this example exemplifies.
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
A unique identifier assigned to the storyboard example.
Each storyboard example provides a real world example for a single storyboard..
|
|
|
A major category of information represented in the information model. An aggregation of interrelated classes. A subject area allows portions of a large model to be viewed as a whole thereby eliminating some complexity involved in understanding a large model.
Subject areas will also be used by the Methodology and Modeling Committee of HL7 to designate Domain Information Models (DIM), class stewardship responsibilities, and classes of interest to a particular committee.
Short informative text describing the subject area so as to be clear what type of Classes it includes.
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
The name given to the subject area. A subject area name is often the plural form of the name of the central or dominant class within the subject area. Subject area names shall be unique within a given model.
The linkage between a Subject area and each of the Classes that are in that Subject area.
The linkage between two subject areas where one of the two is nested within the other.
The linkage between two subject areas where one of the two is nested within the other.
The linkage between a Class and the Subject area that is its primary residence. This must be established if a Class resides in more than one Subject area.
The relationship between subject areas and the models of which they are a part.
A specialization of Class that is used in HL7 to identify those classes that are the focus for a set of Use Cases, Trigger events and/or Application Roles.
Reflects the fact that although a trigger event may cause multiple state transitions, all of these transitions will be within the states of a single subject class.
Links each Application role to the Subject class for which it plays a role. The nature of this relationship is stereotyped as discussed in the description for the Application_role.
Links a leaf-level use case to its Subject Class.
The state attribute of a class contains a value indicating the current state of the class. In the event that the class has concurrent states, the attribute must be a set of state values.
This relationship between states and the subject classes of which they are a part.
|
|
|
An occurrence in the health care domain, or within the systems that support this domain, that causes information to be exchanged in the domain or between systems. Trigger events are initiators of Interactions.
Each Trigger event is tied to one State transition for one of the Subject classes in the model. In turn, the State transition traces to a leaf-level Use case from which the transition stems, and the leaf-level use case defines the context for the trigger event.
If the occurrence of the trigger event is dependent upon the state of one or more objects in the domain or upon the prior occurrence of a different trigger event, this dependency will be expressed in this textual component.
The text that describes the trigger event. When viewed along with the description of the State transitions which the event identifies, this description must have sufficient detail that the event can be reliably recognized when it occurs.
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
An identifier assigned to the trigger event. The identifier is unique within the scope of the model in which the trigger event is defined. In HL7, committees manage the unique identifiers for their trigger events, and concatenate the committee identifier as "Cnn_<identifier>."
A name assigned to the trigger event. The name is unique within the scope of the model in which the trigger event is defined.
This connection from state transition to trigger event is only optional because we do not expect all possible trigger events to be defined in HL7. Nevertheless, any state transition that is described in a use case must be linked to a trigger event.
Note that because of the above condition, and because of the condition on the instance connection from a use case to a state transition, there is a mandatory (1,1) relationship from any leaf-level use case to one trigger event.
The relationship from trigger event to state transition is (1..*) because although the event will probably drive the Subject class to a single state (e.g. "Canceled") and the transitions may start from several states. Thus one trigger event may identify many transitions.
A reference to the trigger event that triggers or initiates this interaction.
Reflects the fact that although a trigger event may cause multiple state transitions, all of these transitions will be within the states of a single subject class.
Sets relationship between model elements and the models of which they are a part.
|
|
|
A use case is a summary of health care relevant events and related information system events that reflect the usage of the information in the information model and related business models. Use cases describe the interactions and information interchanges that occur in the healthcare domain and the events that cause these interchanges.
Use cases may be expressed at various levels. A use case may be a parent to several child use cases. In this circumstance, the interactions ascribed to all of the children constitute the complete interaction of the parent. The decomposition to child use cases should stop when the resulting use case involves a single actor and a single interaction in response to a single stimulus - an atomic or leaf level use case. Note that a use case may be a child of more than one parent, but must not be defined such that a trace up the parental tree from a child will run into the same child (recursion).
At the lowest level of decomposition, each leaf level use case should link to only a single state transition which, in turn, links to a trigger event that initiates interactions. If the linkage is to multiple such transitions or events, further decomposition should be considered.
The text that describes the use case and provides the details necessary to understand the events that are involved in the use case.
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
An identifier assigned to the use case. The identifier is unique within the scope of the model. In HL7, committees manage the unique identifiers for their use cases, and concatenate the committee identifier as "Cnn_<identifier>."
A short phrase that provides a descriptive name for the use case. The name should be unique within the scope of use cases defined by a particular committee.
Links the use case relationship to its target or destination.
Links a use case relationship to the source of the relationship.
A leaf-level use case describes the events that result in a single state transition of the subject class.
Although the instance connection from use case to state transition is optional, this is only because not all use cases are leaf-level. At the leaf-level, each use case should describe one and only one state transition.
Links a leaf-level use case to its Subject Class.
The relationship between use cases and the models of which they are a part.
|
|
|
A major category of information represented in the use case model. An aggregation of interrelated actors and use cases. A category allows portions of a large model to be viewed as a whole thereby eliminating some complexity involved in understanding a large model.
Short informative text describing the use case category so as to be clear what type of use cases it includes.
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
The name given to the use case category. The identifier for the committee defining this category is prepended to the name as Cnn.
Use case categories may be nested in a hierarchy.
Use case categories may be nested in a hierarchy.
The relationship between use case model categories and the models of which they are a part.
|
|
|
Use cases maintain a variety of relationships. This class captures all such flavors. See the use case model chapter of the MDF for details of the stereotypical relationships.
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
Identifies the stereotype for the use case relationship. A blank or null value is a simple generalization relationship, meaning that the target use case Use Case 1 adds additional behavior to the source use case. A value of "extends" means that the target use case adds additional behavior to the source use case at a specified Variation Point. A value of "includes" means that the target uses the source as part of its execution.
Links a use case relationship to the source of the relationship.
Links the use case relationship to its target or destination.
|
|
|
Captures the sequence in which a particular use case is enacted in a storyboard.
This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.
The order in which the use case participates in the Storyboard.
Each storyboard is made up of a sequence of interactions, a sequence of use cases, or both.
|
|
|
The definition of the data type as specified in Figure 2.2, Chapter 2 of HL7 Version 2.3.
The type of data type, such as alphanumeric, or chapter-specific.
The two- or three-character code for the data type. e.g. CM
The name for the data type as specified in the HL7 Chapter 2 table.
The format of the data type, particularly for compound data types.
Provides an indication of the data type used in Version 2.x for a particular attribute, if such prior usage has been identified.
Expresses that each field in V2.3 is typed with a data type.
|
|
Links the fields in HL7 V2.3 to the segments in which those fields appear. Source is the HL7 data dictionary.
The sequence number at which the element or field appears in the segment.
Aggregates the fields that make up each segment.
Links each field to the segment(s) in which it is used and the sequential position in which it appears.
|
|
|
Contains all of the fields (data elements) specified in HL7 Version 2.x, as captured in the data dictionary published by HL7.
The description of this field.
The unique numeric identifier assigned by HL7 for this field.
The name of the field in the HL7 Data Dictionary.
The number of the HL7 table that provides values for this field, if the field is table-based.
Expresses that each field in V2.3 is typed with a data type.
Provides a linkage for an information model attribute to its equivalent version 2.x field, if such linkage exists and has been identified.
Links each field to the segment(s) in which it is used and the sequential position in which it appears.
|
|
|
Contains all of the segments specified in HL7 Version 2.3, as captured in the data dictionary published by HL7.
The name of the segment.
The three-character segment identifier.
Many attributes are traced to equivalent content in HL7 Version 2.x. This connection is secondary to the path that traces an attribute to an HL7 field to a segment. It is provided for modelers who wish to specify particular segments for information model attributes.
Aggregates the fields that make up each segment.
|
|
|
Aliases for this table include "Vocabulary domain" and "Vocabulary value set." The distinction among the three notions is carried in the type_cd attribute.
A concept is defined by ISO 1087 as a "unit of thought constituted through abstraction on the basis of characteristics common to a set of objects." A value domain consists of a set of concepts, not a set of words or codes. Any given concept may be represented using different coding systems.
This table describes the high level definition of a given vocabulary domain. It holds the name of the vocabulary domain, and anchors the relationship of the vocabulary domain to different realms of use, and to the various vocabularies and coding systems that are used to define the vocabulary domain. The structure of this table allows a vocabulary domain (or its value sets) to be defined by recursive reference to other vocabulary domains or value sets.
Qualifies the application of the codes for RIM structural attributes, as to which moods, relationship types, etc. the code in question applies.
A unique, sequentially assigned number that identifies a vocabulary concept. It stems from the following requirements in the MDF:
1) HL7 Concept Identifier - the unique item identifier assigned by HL7 to this concept. This concept identifier is globally unique to a concept throughout all HL7 tables, and it does not overlap any HL7 value set identifier. That is, if the concept male occurred in another vocabulary domain in addition to the Gender domain, it would again have an item identifier of "40001". If a universal terminology of medicine becomes available, the universal concept identifier from that terminology will be used in place of this HL7 assigned identifier.
2) HL7 Value Set Identifier - a unique, sequential number assigned by HL7 that identifies a value set. Each unique combination of a Realm, a Domain Name, and a Code System is given a unique value set identifier. For HL7 tables that exist in version 2.X, the value set identifier is the same as the version 2.X table number. An HL7 value set will never have the same identifier as an HL7 concept.
The sequence number used when the concept was defined for an HL7 table. Attribute has no semantic import, but does allow reconstruction of the submission form at a later date.
Value Set Definition Expression - an expression that defines how the value set is derived from other pre-existing value sets. The expression refers to value sets using a name enclosed in double quotes. The name enclosed in quotes is a concatenation of the domain name, the realm, and the code system. When a value set expression is for the HL7 code system, the expression includes set operators that indicate how a given value set can be derived from pre-existing HL7 maintained value sets. The value sets referenced in the expression can be either primitive or composite. A composite value set is a value set that contains other value sets. The allowed set operators are:
Symbol Description + Union - Difference * Intersection
Parentheses are allowed in the expression when they are needed to create the proper ordering of the operations. If the value set definition is for any system other than HL7, then there must be a valid expression in the expression field that refers to a value set provided by the terminology source named in the code system column of this table. For non-HL7 vocabularies, operators other than the usual set operators are allowed. For example, ChildrenOf might be used as a keyword to indicate that all children of a given hierarchical node are included in the value set. It is the responsibility of the given terminology provider to define the operators, keywords, and syntax that are supported by their terminology system, and to state how hierarchical structures (nodes) should be referenced.
Value Set Description - a textual description of the value set as it is known within the code system. When possible, the principle upon which concepts are either included or excluded from the domain should be stated.
Concept Definition - Description - a textual representation of the meaning of this entry.
Editor's notes for the domain. A general purpose textual field for recording specific information about the entry, or details about the rationale for modifying this particular table entry.
In conjunction with 'applies_to' tells how the concept in question applies to a particular structural element.
All names in this class will be unique, regardless of whether they are for domains, concepts or value sets.
For Domains, a unique textual name for the vocabulary domain. The name is created using mixed case object oriented style names, without the use of white space or special punctuation. The name is generally singular. This name is used when the vocabulary domain is referenced by other vocabulary domain definitions. Examples of acceptable names are: Gender, OrderType, PatientType, AbnormalFlag, etc.
The domain name is retained across all realms. Thus, the vocabulary domain name implies a different set of values depending on the Realm of use and the code system. The name may be determined by the organization defining the system which includes this domain.
For Value sets, A unique textual name assigned by HL7 for the value set. The value set name implies a different set of concepts within each realm of use and code system. The name is generally singular. This name is used when the value set is used in HL7 specifications or when the value set is referenced by other vocabulary domain definitions.
For Concepts, A unique textual name assigned by HL7 for the concept. This name need not be the same as the "print name" of any of the systems.
Captures issues raised and entered into the record as part of vocabulary harmonization.
Each coded field has only one preferred value set. That is, there is a single preferred coding scheme for a given domain-realm combination. Other value set definition are allowed, but they are of lower rank. The rank is expressed as an integer, with the preferred rank being one ("1").
Realm - the realm of use of a value set.(This attribute does not apply directly to either a domain or a concept. A given vocabulary domain will have a new row for each different realm of use and code system. The jurisdiction or realm within which the domain will be used. A realm might be a country, a group of countries, a region of the world, or an organization. The values for the realm column come from the RealmOfUse vocabulary domain.
Status - the status of the item. The values for Status come from the vocabulary domain EditStatus. Some values for status are Proposed, Rejected, Active, Obsolete, and Inactive.
A code indicating the type of entity being represented as a concept. This occurs because the class represents a generalization hierarchy that has been collapsed into a single class. Values for this code and their meanings include:
D - Domain -- Within the HL7 message framework, 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. A domain is the complete set of all concepts that are valid values for an attribute in the RIM, an HMD, a CMET, or a template,
C - Simple Concept - Represents a terminal or leaf-level concept. It is represented as a single term in a code system.
- Value Set - A domain that has been constrained to a particular realm and vocabulary is called a value set. Value sets (domains that have been specialized by realm and code system) are defined from concepts from a single vocabulary. A vocabulary domain that has been specialized in the context of a specific message and placed in the context of a specific Realm and Code System becomes a value set. A value set is the subset of concepts from the global domain that are applicable in a given Realm and Code System.
H - HL7 Value Set - A value set that is based on an HL7-defined code system. E - External Value set
Vout - the version number of the domain specification database at the time this entry was updated or deleted. A blank Vout value means that the entry continues to exist in the current version of the table.
Each value set is based on a single code system.
Links a coded term to a single concept.
|
MET_Metamodel_data_types |
Boolean data
Coded data
This set of components is assigned to one attribute of most meta-model elements. These components serve to track the history of each element and designate the models in which the element is valid.
This component contains the model unique identifier (modelID) of the first model version in which this element was defined.
This component is used to track the version history of each element of the model. It contains the unique element identifier assigned to each model element. The values are assigned in the repository. Modelers should never change these values or assign new ones, but they may copy them to indicate element history.
This component contains the model unique identifier (modelID) of the model for which this element ceased to be valid. A blank lastVer value means that the element is valid in the most recent HL7 models. If this value is valued, the element is no longer a member of the current RIM. Since model identifiers are monotonically increasing, a given element is valid from the model identified by firstVer up to but not including the model identified by lastVer.
If an element of the meta-model derives from a previously defined element, this component will be valued. It contains the unique identifier of the element's predecessor,
Date data.
DateTime data.
In most instances the information to be kept about model components includes provision for a textual description of the component. Experience in documenting such models has shown the value of structuring these descriptions in order to provide for reference to external documents, identification of open issues, explanation of modeling rationale, etc. Therefore, descriptions of model components shall be of type DescriptiveText, as follows.
A paragraph that is part of the regular description shall not begin with one of the reserved phrases. Paragraphs that begin with a reserved phrase are used to capture comments about the rationale for modeling, to capture open issues and to express external references. The reserved phrases and their usage are shown below:
Reserved phrase "Rationale:" allows the modeler to document the rationale or justification for the specification of a particular element. It may occupy one or more paragraphs, but only one modeling rationale component should appear for any given model element. The first paragraph of the rationale must begin "Rationale:" The rationale will continue to the end of the description or until another reserved phrase is encountered.
Reserved phrase "OpenIssue:" allows the modeler to identify and discuss any open issues that remain to be resolved with respect to the model element. It may occupy one or more paragraphs, and there may be multiple open issues for a model element. The first paragraph of each open issue must begin with "OpenIssue:" The open issue will continue to the end of the description or until another reserved phrase is encountered.
Reserved phrase "ExtRef:" provides the specification of a reference to an external document, either by name or by a URL reference. Multiple external references may be contained in a given description. The external reference must be a single paragraph that starts with "ExtRef:" and must either be the final paragraph of the description or it must be followed by another reserved phrase paragraph.
Enumerated data
Various data model elements in the use case model and interaction model are required to have identifiers that are unique throughout the model. These elements will be specified as being represented by an IdentifierString.
Elements that use these identifiers are: application role, interaction, message, scenario, scenario example, trigger event, and use case.
An IdentifierString is a string that contains no embedded spaces and that is built from a limited character set. The IdentifierString may include any number of the following characters: upper or lower case alphabetic characters (A-Z and a-z); the digits (0-9); the dot character (.); the hyphen character (-); and the underscore character (_). These characters may be in any order, except that the first character of the IdentifierString shall be either a digit or an upper case alphabetic character.
Note: Because the dot character (.) is an allowed member of an IdentifierString, the IdentifierString cannot be used in defining fully qualified names for elements.
Integer data.
A set of values and value ranges including the minimum and maximum occurrence are required for associations and aggregations in the meta-model. A MultiplicityString shall be used to represent this set in both the literary and graphical expressions of the model. The MultiplicityString is a constrained string. It is built according to the following rules:
1. A MultiplicityString shall have at least a minimum and a maximum value.
2. A MultiplicityString may also include an open ended range at the upper end.
3. A MultiplicityString shall be expressed either as the single element "1" (the numeral one) or as a pair of elements separated by an ellipsis (..).
4. The elements making up a MultiplicityString shall be either zero, a positive integer, or the character "*."
5. If the character "*" appears in a MultiplicityString, there must be only a single occurrence, and that occurrence shall represent the set of all positive integers that are greater than the largest of the other integers in the same MultiplicityString.
6. The minimum value for the multiplicity shall be the smallest integer in the MultiplicityString, and may not be the character "*."
7. The maximum value for the multiplicity shall be the largest integer in the MultiplicityString, and must be greater than zero.
8. The elements making up a MultiplicityString should be ordered in ascending order, but are not required to be.
The NameString is a string that contains no embedded spaces and that is built from a limited character set. The NameString may include any number of the following characters: upper or lower case alphabetic characters (A-Z and a-z); the digits (0-9); the hyphen (-), and the underscore character (_). These characters may be in any order, except that the first character of the NameString shall be an alphabetic character.
The appropriate use of upper and lower case characters, and the inclusion of special characters allow data modelers to create easily readable strings for the noun- and verb-phrases required for many of these elements. (Examples might include "is_ordered_by" or "HealthCarePractitioner" or NameString.)
For clarity of reading, the initial character of a NameString should be lower case when used for names of attributes, labels of relationships, and labels for state transitions, and should be upper case in all other uses.. No matter what conventions are used with respect to capitalization, when NameStrings are compared for uniqueness, all alphabetic characters shall be treated as though they are lower case.
String data.
A version number is a string comprised solely of the digit characters and the dot (.) character.