Copyright 1999 by Health Level Seven, Inc.
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-13 19991020
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.
|
Choice_branch Choice_MET Collection_MET Common_message_element_type |
Composite_MET Hierarchical_message_description Message_element_type Message_MET |
MET_component Model Primitive_MET Version_MET |
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 represents the meta-model of the third release of the HL7 Version 3 MDF, as updated in October 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.
This version is felt to be complete, it matches the current HL7 tooling, and is mostly correct, but probably needs some revision after the message design concepts have been tested.
|
|
|
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.
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 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.
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.
A reference between an attribute and its attribute type. The attribute type code must also be the terminal component of the attribute name.
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.
|
|
|
A choice branch is provides one alternative for a choice MET or a version MET. The branch includes a tag used to identify the branch when it is instantiated and a type that represents the branch.
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 value that identifies a particular choice. The tag values must be unique within a single choice MET or version MET.
The branch must have a unique tag value whether or not that value governs the selection of the choice in an MEI. Whether this is the governing value for a particular HMD is determined by the value_type attribute. If that attribute has a value of "Other" then this value rules. If the value_type is "State" then a set of "states" will govern the choice. The state values are linked to the choice branch by the mandatory association to a choice node which contains the states as choice values.
The value type determines whether this choice branch is governed by the tag value, or whether it is governed by a set of choice values linked to the (mandatory) associated choice node, which values are determined by associations to states in the MIM.
The presently allowed values for this element are "State" or "Other" where "Other" draws the value from tag value.
Each branch of a Choice_MET includes a type. One of these choices is used in a Choice MEI. A choice branch must be part of a version MET or a choice MET, but not a part of both.
Each branch of a Version_MET includes a type. All of these choices are used in a Choice MEI. A choice branch must be part of a version MET or a choice MET, but not a part of both.
Each choice branch must be typed by an MET.
A composite message element type for which only one of the branches will be sent in an instance.
Each branch of a Choice_MET includes a type. One of these choices is used in a Choice MEI. A choice branch must be part of a version MET or a choice MET, but not a part of both.
|
|
|
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 generalization relationship and the subtype that participates in that connection.
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.
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.
Many code systems have subsystems. These are, e.g., axes in SNOMED, classes, and subclasses in hierarchical codes such as ICD. The structure of coding systems is idiosyncratic.
A code sub-system may be further decomposed in a hierarchical fashion by implementing this association.
A code sub-system may be further decomposed in a hierarchical fashion by implementing this association.
|
|
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.
ORGANIZATION: e.g. WHO, College of American Pathologists, ISO, IANA, and HL7 of course.
NAME: e.g. ICD, ICPM, ICPC, SNOMED, 639-1, MIME types, ...
The name of the organization that maintains the code system. Examples are WHO, College of American Pathologists, ISO, IANA, and HL7.
|
|
|
This class is not expected to be exhaustively instantiated. Its purpose is not to copy the lists of terms of all external code sets. Rather it will be used for those codes that must be enumerated to define a particular HL7 domain.
It can also be used to capture and manage HL7-defined code sets.
The text string used within the coding 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 freshly defined HL7 code table would be an Enumeration domain (refers to itself as a "base"). All items in the enumeration would be terms with definition attached to them.
the unique item identifier assigned by HL7 to this concept. This concept identifier is globally unique to a concept throughout all HL7 tables. 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 "1". If a universal terminology of medicine becomes available, the universal concept identifier from that terminology could be used in place of this HL7 assigned identifier.
The status of this entry within this domain table. The values for Status come from the vocabulary domain EditStatus. Some values for status are Proposed, Rejected, Active, Obsolete, and Inactive.
A textual name for the term.
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.
An enumeration is a set of terms.
This relationship indicates that a vocabulary domain is a set of terms and every term belongs to one vocabulary domain.
Through subsystems and derived vocabulary domains, any term can be member of more than one vocabulary domain.
|
|
|
Provides for the inclusion of a collection of other METs as a component of an MET.
The collection may be a List (ordered collection of instances), a Set (unordered collection of unique instances) or a Bag (unordered collection of instances which might not be unique).
Provides the minimum and maximum number of occurrences in the collection.
Determines whether the collection is a List, a Set, or a Bag.
Each collection MET collects elements of a single type.
The common message element type is composite MET that has been declared as a public type available for assignment or substitution, as appropriate in an HMD.
OpenIssue: This class may require additional attributes.
|
|
|
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.
Each composite data type has an associated composite MET that is used to represent it in messages.
|
|
A message element type that contains other message elements (components). Each component message element has a name and a type. Each component of an element must have a different name, although many may be of the same type.
This attribute is intended to capture the definition of a "segment" MET for use in a segment-positional syntax (ER7).
OpenIssue: This attribute is redundant to the association to a MIM_class. If the association is present, then it is a segment. Otherwise, not.
Each composite data type has an associated composite MET that is used to represent it in messages.
|
|
|
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 component is linked to a single type either directly or through a generic type 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 data type generalization includes a single sub-type.
Relationship between a Generic Type Parameter and the Generic type for which it is a parameter.
Each data type generalization provides sub-types for a single super-type..
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.
Provides for one type to represent a simple alias for another.
The relationship between data types and the models in which they are first defined.
An alias provides an alternative name, alternate type code and additional description for another data type. Its most common use is to provide a specific "user-friendly" name for a collection of other data types.
Provides for one type to represent a simple alias for another.
|
|
|
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.
Each data type generalization includes a single sub-type.
Each data type generalization provides sub-types for a single super-type..
|
|
A derivative is the vocabulary domain that results from applying a particular operator to two or more other vocabulary domains.
A derivative vocabulary domain is usually a subset of another set. Defining derivatives inclusion or exclusion of one domain with another. Derivatives can exist on different levels: e.g., in the realm of an institution (hospital department), a country (USA), a treaty (EU), and so on. Thus, each derivative can be defined on another derivative in a larger realm (e.g., a German hospital narrows the domain defined by the EU that in turn may be a subset of a WHO code).
While system and subsystem are defined externally, derivatives must be explicitly defined.
The operator that defines the combinatorial rule applied to two or more operand domains to arrive at the derivative domain. Operators include union (+) and difference (-). Additional constructs may be provided.
Relationship between a derivative, its operator, and the operands (other domains) to which the operator is applied.
|
|
|
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.
A summary of why the edits were made, and what was done.
The date and time that the edit session began
An identifier of the person or group responsible for the edits.
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 vocabulary definition tables were added, modified, or deleted during the session.
An enumerated domain is defined by an enumerated set of code terms. While large code systems are impractical to enumerate, and while some are not enumerable at all, enumeration is useful for small domains.
An enumeration is a set of terms.
An enumeration includes terms from a particular domain. In the case where the enumeration is the entire domain, this relationship is self-referential.
|
|
|
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 subtype that participates in that connection.
The linkage between a generalization relationship and the supertype 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.
Determines the set of types that a generic type parameter may implement.
This relationship defines the particular instantiation type for a generic instance.
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.
Each MET must be defined in one HMD.
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.
|
|
|
The rows of an 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.
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.
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.
A reference to the trigger event that triggers or initiates this interaction.
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.
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.
|
|
|
A linkage from a particular vocabulary domain to a particular LOINC code.
The LOINC code being equated to the vocabulary domain.
The version of LOINC being referenced.
The status of the item. 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.
|
|
|
This is an abstract generalization for particular message element types (MET). It is also known simply as a type. A MET is a specification of the values that a message element can take on in its instances. It is the basic unit of structure for HL7 Version 3 messages and related information structures.
The version of HL7 models under which this MET was first balloted, with its HMD.
Indicates whether this MET is defined within an HMD, as a CMET, a type for a data type, or is being re-used in an HMD.
The formal name (sometimes called the "long name") is a very descriptive name that generally is the same as it appears in the source. Common sources for formal names are class, attribute, or association names from the Message Information Model, Object Views from the Message Object Diagram, Common Message Element Type definitions, and Data Type definitions.
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 (sometimes called the "short name") is intended to be a mnemonic abbreviation of the formal name that is more tractable for programming, for reference as types in another MET and for use in Implementation Technology Specifications.
Each collection MET collects elements of a single type.
Each MET must be defined in one HMD.
Each choice branch must be typed by an MET.
Each MET component is typed by a single MET.
The relationship between Message element types and the models in which they are first defined.
|
|
|
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.
Each R-MIM refines a single MIM.
A reference to the model (RIM version) from which all of the elements of the MIM will be drawn.
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.
A message MET types all of the messages in an HMD.
|
|
|
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).
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.
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.
|
|
|
Elements that make up a composite MET.
Each MET component has a name and a type. The names must be unique within the composite. Each component of an element must have a different name, although many may be of the same type.
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 whether this component is optional within the MET composite of which it is a part.
Locale is intended to be a code. The intent is that all the information in a component flagged for a particular locale is specific to the definition for that locale. This allows for locale-specific information to be added to a message type. A scheme for generating unambiguous locale IDs is required.
In theory, the locale ID does not need to be transmitted in a message instance, because the locally-tagged code has its own name.
Because of the hierarchy of uniform METs the approach can be applied anywhere from data types on up. It also supports message instances carrying multiple locale-specific inclusions.
The full name for the component
This is the "short name" for the component.
Provides the sequence number within the composite for use in a segment-positional syntax such as ER7.
Each MET component is typed by a single MET.
|
|
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 Message element types and the models in which they are first defined.
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.
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 Primitive MET gains its own type from a Primitive data type.
A message element type that does not contain other message elements. A primitive MET may only be defined as part of a data type MET (DMET).
A Primitive MET gains its own type from a Primitive data type.
|
|
|
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 imnportant 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 contraints of the MIM) independently. Constraints involve rmoving 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 constrints 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 assocation 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 contraints 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 subccomponent that is higher in the HMD
Constraint : a verbal expresson 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 descrobed 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 attirubutes 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 substates of a parent, provided that all of the states for a given class have unique names.
States may be defined as substates 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 a use case relationship to the source of the relationship.
Links the use case relationship to its target or destination.
Links a leaf-level use case to its Subject Class.
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.
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 the use case relationship to its target or destination.
Links a use case relationship to the source of the relationship.
|
|
|
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.
Provides for version-specific METs for inter-version compatibility. When it is used, all of its branches will be included in the message.
Each branch of a Version_MET includes a type. All of these choices are used in a Choice MEI. A choice branch must be part of a version MET or a choice MET, but not a part of both.
A vocabulary domain is a specification of the allowable values for an attribute or component of a composite data type that has a coded datatype assigned to it. The vocabulary domain may be as simple as a reference to a table of enumerated values or it can be a collection of predicate statements.
Every collection of terms is a vocabulary domain, including the one element set, the empty set, an enumeration of a few terms, and all huge vocabulary systems, their subsystems and derivatives.
A textual description of the vocabulary domain and its purpose
Editor's notes for the domain.
A unique, sequentially assigned number that identifies a vocabulary domain.
Indicates whether the domain is one that is maintained internally by HL7 in the primitive vocabulary domain enumeration tables, or whether the domain refers to a set maintained by an external organization.
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 name may be determined by the organization defining the system which includes this domain.
A coded element that indicates the country/affiliate/jurisdiction for which this domain specification applies. This term allows multiple jurisdiction-specific domains to be related under a single over-arching domain.
The values for the realms of use column come from the RealmOfUse vocabulary domain.
The status of the item. The values for Status come from vocabulary domain EditStatus. Some values for status are Proposed, Rejected, Active, Obsolete, and Inactive.
The version of the domain as assigned by HL7 or by the organization defining the system of which this domain is a part.
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.
This is used for versioning. Actually the version numbering is less important than the maintenance of these "updates" links between versions.
This relationship indicates that a vocabulary domain is a set of terms and every term belongs to one vocabulary domain.
Through subsystems and derived vocabulary domains, any term can be member of more than one vocabulary domain.
An enumeration includes terms from a particular domain. In the case where the enumeration is the entire domain, this relationship is self-referential.
Relationship between a derivative, its operator, and the operands (other domains) to which the operator is applied.
This "see also" link is used in conjunction with the comments field to direct the interested reader to other codes..
This is used for versioning. Actually the version numbering is less important than the maintenance of these "updates" links between versions.
This "see also" link is used in conjunction with the comments field to direct the interested reader to other codes..
|
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.