HL7_V3_Meta-Model

Version: V 1-16 (5/12/2002)
ModelID: MET_0116

HL7 Version 3 Standard, Copyright Health Level Seven, Inc.© 2002. All Rights Reserved.

Table of contents

This model advances the meta-model to account for methodology changes adopted through March, 2002.

All section have been updated, and the concept of a Message Information model (MIM) has been dropped. This model was prepared as part of the preparatory work for developing the HL7 Development Framework (HDF).

A meta-model is constructed to document the HL7 development process and the artifacts to support that process. The Mets-Model Information Model documents the information content of HL7's analysis and design artifacts.

The representations available for the Meta-Model Information Model include a diagram for each of the high level subject areas. The available graphics follow:

• Attributes of Actor:

• Associations of Actor:
• in :: (1..1)Model :: has :: (0..*)
• participates_in :: (0..*)Use_case :: involves :: (1..*)
• included_in :: (0..*)Use_case_category :: includes :: (0..*)

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.

The actors in the model are each given a unique name. The actor name is a singular noun or noun phrase.

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.

• Attributes of Application_role:

• Associations of Application_role:
• source_for :: (0..*)Application_role_relationship :: has_source :: (1..1)
• target_of :: (0..*)Application_role_relationship :: has_target :: (1..1)
• has :: (0..*)Design_annotation :: for :: (0..1)
• defined_in :: (1..1)Design_category :: includes :: (0..*)
• receives :: (0..*)Interaction :: received_by :: (1..1)
• sends :: (0..*)Interaction :: sent_by :: (1..1)
• in :: (1..1)Model :: has :: (0..*)

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.

Application roles may contain other application roles, in which case they inherit or contain the characteristics and responsibilities of the contained role based on the type of containment relationship.

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 following a naming standard established by HL7.

A name assigned to the application role. The name is unique within the scope of the model in which the application role is defined and is derived based on a formal naming standard established by HL7. The present standard is: (<Focal class> <mood><State transition capability><Application capability/coupling>, and the standards for Query Roles remains to be established).

A short, common-use name assigned to the application role. The short name is intended to be familiar to domain experts and is not required to be unique.

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.

• Attributes of Application_role_relationship:

• Associations of Application_role_relationship:
• has_source :: (1..1)Application_role :: source_for :: (0..*)
• has_target :: (1..1)Application_role :: target_of :: (0..*)
• in :: (1..1)Model :: has :: (0..*)

Application roles relationships allow the building of hierarchies of application roles such that one application role automatically takes on the characteristics of the application role it is related to.

At present, Application roles relationships can only be of two types:

Includes - The source application role behaves as though it were the sender and receiver for all interactions that are defined for the target application role.

OneOf: The source application role behaves as though it were the sender and receiver of all interactions that are defined for one and only one of its target application roles.

Application roles relationships may not be defined in a recursive manner. In traveling from source to target along all defined application role relationships there should be no situation where the original application role is identified as a target. I.e. the chain of application roles must not form a loop.

Defines how the source and target application role relate. At present, the permitted values are 'includes', and "oneOf," where the later implies that when conformance is claimed, the claimant must select one (and only one) of the included roles to implement.

• Attributes of Association:

• Association generalizes:

• Association is a specialization of: Relationship

An association is a relationship between classes that 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 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 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 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.

• Attributes of Attribute:

• Associations of Attribute:
• constrained_by :: (0..1)Attribute_domain_constraint :: constrains :: (0..*)
• is_of_type :: (1..1)Attribute_type :: types :: (0..*)
• in :: (1..1)Class :: has :: (0..*)
• has_dependent :: (0..*)DIM_attribute_row :: based_on :: (1..1)
• is_of_type :: (0..1)Data_type :: types :: (0..*)
• is_state_attribute_for :: (0..1)Subject_class :: has_state_attribute :: (1..1)
• had_V23_type :: (1..1)V23_data_type :: typed :: (0..*)
• based_on :: (0..*)V23_fields :: is_source_for :: (0..*)
• stems_from :: (0..*)V23_segments :: source_of :: (0..*)

• Attribute generalizes:

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.

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.

A short informative description of the Class characteristic captured by the Attribute.

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.

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.

Identifies the relative sort order of the attribute within the containing class. Lower numbers appear first. In the circumstance where two attributes within a class have the same number, sorting will occur based on alphabetically ascending attribute name.

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.

• Attributes of Attribute_domain_constraint:

• Associations of Attribute_domain_constraint:
• constrains :: (0..*)Attribute :: constrained_by :: (0..1)
• links_domain :: (1..1)Vocabulary_concept :: is_constraint :: (0..*)

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.

• Attributes of Attribute_type:

• Associations of Attribute_type:
• types :: (0..*)Attribute :: is_of_type :: (1..1)
• implemented_by :: (0..1)Data_type :: implements :: (1..*)

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.

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.

This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.

• Attributes of Class:

• Associations of Class:
• has :: (0..*)Attribute :: in :: (1..1)
• has_dependent :: (0..*)DIM_class_row :: is_based_on :: (1..1)
• in :: (1..1)Model :: has :: (0..*)
• is_destination :: (0..*)Relationship :: has_destination :: (1..1)
• is_source :: (0..*)Relationship :: has_source :: (1..1)
• primarily_resides_in :: (0..1)Subject_area :: holds :: (1..*)
• appears_in :: (0..*)Subject_area :: includes :: (1..*)

• Class generalizes:

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.

The Classes in the information model are given a unique name. The Class name is a singular noun or noun phrase.

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 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.

This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.

• Attributes of Code_system:

• Associations of Code_system:
• has_terms :: (0..*)Coded_term :: is_part_of :: (1..1)
• is_basis_for :: (0..*)Vocabulary_concept :: has_basis_in :: (0..1)

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.

Code System - indicates the name of the code system. e.g. ICD, ICPM, ICPC, SNOMED, 639-1, MIME types, ...

The code system version for the term.

Table Identifier - the table number or identifier (if one exists) in the source vocabulary where this concept originated.

The name of the organization that maintains the code system. Examples are WHO, College of American Pathologists, ISO, IANA, and HL7.

• Attributes of Coded_term:

• Associations of Coded_term:
• is_part_of :: (1..1)Code_system :: has_terms :: (0..*)
• in_version :: (1..1)Domain_version :: has :: (0..*)
• linked_to_set :: (0..*)Observation_id_link :: links_obs_term :: (1..1)
• represents :: (0..1)Vocabulary_concept :: is_represented_by :: (0..*)

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.

Code System Vout - the version number of the code system at the time the code was retired or deleted.

A textual name for the term.

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.:

The code system version in which this term was first introduced.

The code system version in which this term was first deleted or changed.

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.

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.

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.

• Attributes of Communication_wrapper:

• Associations of Communication_wrapper:
• may_wrap_interactions_of_type :: (1..1)Interaction_type :: supports_wrapper :: (1..1)
• acts_as :: (1..1)Message_type :: implemented_by :: (0..1)
• in :: (1..1)Model :: has :: (0..*)

A message type intended to act as the outer communication wrapper when transmitting a message.

A unique identifier used to reference the communication_wrapper.

A unique name for the interaction 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.

• Composite_aggregation is a specialization of: Association

An association between classes that depicts the relationship between a composite aggregate class and its component parts. The source_multiplicity of the composite aggregation is constrained to be "1..1".

• Associations of Composite_data_type:
• contains :: (1..*)Data_type_component :: belongs_to :: (1..1)

• Composite_data_type is a specialization of: Data_type

A composite data type consists of one or more named and typed components.

• Attributes of Concept_relationship:

• Associations of Concept_relationship:
• in_version :: (1..1)Domain_version :: has :: (0..*)
• links_content :: (1..1)Vocabulary_concept :: is_contained_concept :: (0..*)
• has_container :: (1..1)Vocabulary_concept :: is_containing_concept :: (0..*)

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.

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."

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.

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.

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.

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.

• Attributes of Control_event:

• Associations of Control_event:
• wraps_interaction :: (0..*)Interaction :: has_control_event :: (1..1)
• acts_as :: (1..1)Message_type :: implemented_by :: (0..1)

A control event provides information about an action in the health-care domain which causes information to be exchanged or which must be tracked and have a record of the activity persisted.

A unique identifier used to reference the communication_wrapper.

A unique name for the interaction 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.

• Attributes of Data_type:

• Associations of Data_type:
• types :: (0..*)Attribute :: is_of_type :: (0..1)
• implements :: (1..*)Attribute_type :: implemented_by :: (0..1)
• resides_in :: (0..*)Data_type_category :: contains :: (0..*)
• types :: (0..*)Data_type_component :: is_of_type :: (1..1)
• is_subtype :: (0..*)Data_type_generalization :: has_subtype :: (1..1)
• is_supertype :: (0..*)Data_type_generalization :: has_supertype :: (1..1)
• defined_by :: (0..*)Generic_type_parameter :: defines :: (1..1)
• allowed_for :: (0..*)Generic_type_parameter :: has_allowed_types :: (0..*)
• types :: (0..*)Generic_type_parameter :: has_instance_type :: (0..1)
• in :: (1..1)Model :: has :: (0..*)

• Data_type generalizes:

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.

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.

The formal name for the data type.

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.

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.

• Attributes of Data_type_category:

• Associations of Data_type_category:
• contains :: (0..*)Data_type :: resides_in :: (0..*)
• is_nested_in :: (0..1)Data_type_category :: nests :: (0..*)
• maintained_by :: (1..1)HL7_committee :: maintains :: (0..*)
• in :: (1..1)Model :: has :: (0..*)

A data type category collects data types that represent similar real world concepts, or are represented in a similar fashion.

The name given to the data type category.

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.

• Attributes of Data_type_component:

• Associations of Data_type_component:
• belongs_to :: (1..1)Composite_data_type :: contains :: (1..*)
• is_of_type :: (1..1)Data_type :: types :: (0..*)

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 formal name of the data type component.

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 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.

• Attributes of Data_type_generalization:

• Associations of Data_type_generalization:
• has_subtype :: (1..1)Data_type :: is_subtype :: (0..*)
• has_supertype :: (1..1)Data_type :: is_supertype :: (0..*)

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).

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.

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.

• Attributes of Design_annotation:

• Associations of Design_annotation:
• for :: (0..1)Application_role :: has :: (0..*)
• for :: (0..1)Interaction :: has :: (0..*)
• has_content :: (1..1)Note :: content_for :: (0..*)
• for :: (0..1)Trigger_event :: has :: (0..*)

Indicates the type of element that is the target or focus of the annotation.

• Attributes of Design_category:

• Associations of Design_category:
• includes :: (0..*)Application_role :: defined_in :: (1..1)
• nested_in :: (0..1)Design_category :: nests :: (0..*)
• maintained_by :: (0..1)HL7_committee :: maintains :: (0..*)
• includes :: (0..*)Interaction :: defined_in :: (1..1)
• in :: (1..1)Model :: has :: (0..*)
• includes :: (0..*)Storyboard :: defined_in :: (1..1)
• includes :: (0..*)Trigger_event :: defined_in :: (1..1)

A major category of information represented in the design of HL7 information structures model. A category allows portions of a large model to be viewed as a whole thereby eliminating some complexity involved in understanding a large model.

As these categories are nested, they create a hierarchy of design information that supports the publication and interpretation of the standards.

The name given to the interaction model category. The identifier for the committee defining this category is prepended to the name as Cnn.

A unique identifier for this category. The structure for this identifier will be defined by HL7 for each "level" of category.

As design categories are nested, they form a hierarchy whose levels are designated by this attribute. Examples levels are:

Section - A categorization of the deliverables of the HL7 organization. Identifies a high-level content area in which work is performed by HL7 members. It is usually comprised of one or more subsections.

Subsection - A sub-categorization of information within a section. Reflects one of the primary focal areas of the HL7 organization. It contains individual domains.

Domain - A major focus area around which messages and other HL7 deliverables are built. A modeling domain is the primary unit of work for a technical committee. The modeling domain represents a cohesive view of an area of healthcare, including the events that can occur, the types of applications used and the information exchanged and recorded.

Short informative text describing the scope of the content for the interaction model category.

For sections and subsections this may include a description of boundaries and the relationship itself and other subsections.

For domains, it may include a description of boundaries and the relationship of itself and other modeling domains. From reading the scope it should be clear what type of interactions, application roles, trigger events and information models will be defined within the domain.

This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.

• Attributes of Design_information_model:

• Associations of Design_information_model:
• contains :: (1..*)DIM_row :: part_of :: (1..1)
• derives_from :: (0..1)Design_information_model :: further_constrains :: (0..*)
• is_part_of :: (1..1)Model :: contains :: (0..*)

The Design Information Model (DIM) is the representation of the information that must be recorded, managed and/or transmitted to satisfy the requirements of a particular domain or set of specifications to be published by HL7.

The DIM has two major forms that are distinguished by the models from which the DIM draws its classes, attributes, relationships, etc. These are a simple Design Information Model DIM, and the Constrained Design Information Model IC-DIM).

A DIM is the representation of the information that needs to be recorded and transmitted to satisfy the requirements of a particular domain. The content for the DIM is drawn directly from the containing information model.

The information is represented through the cloning and restricting of the classes, attributes and associations of the containing Model. That is classes, attributes and associations from a Model may be represented more than once in a DIM. This is done to allow the messages to be tailored to the specific needs of different instances of a class. For example, 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 DIM.

When a class is cloned, the clone must be given a unique name. If there are multiple clones derived from the same Model class, each clone may be constrained independently. Constraints involve: removing attributes, tightening association cardinality (increasing minimum/decreasing maximum), discarding associations, constraining datatypes, making an attribute or association mandatory, specifying association or attribute conformance, reducing vocabulary domains, specifying a default or fixed value for an attribute and adding constraint notes.

The DIM 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.

A Constrained Design Information Model (C-DIM) is derived from a DIM or another C-DIM. That is, C-DIM is design information model that is developed with the further constraint that its content, while being drawn from the containing information model, may only include elemtns that are a constrained subset of the DIM or C-DIM from which it is derived.

A unique identifier for the R-MIM.

A unique formal name for the DIM.

A Design information model may be of one of two types.

A simple design information model (designated DIM) may draws its information and creates its clones from the containing Model without further restrictions.

A constrained design information model (designated C-DIM) applies further constraints to an existing DIM or C-DIM upon which it is dependent.

A description explaining use and meaning of the information constructs represented in a DIM.

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.

• Attributes of DIM_attribute_domain_constraint:

• Associations of DIM_attribute_domain_constraint:
• constrains :: (0..*)DIM_attribute_row :: constrained_by :: (0..1)
• links_domain :: (1..1)Vocabulary_concept :: is_constraint :: (0..*)

Constrains a coded DIM 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.

• Associations of DIM_attribute_row:
• based_on :: (1..1)Attribute :: has_dependent :: (0..*)
• constrained_by :: (0..1)DIM_attribute_domain_constraint :: constrains :: (0..*)
• defines :: (0..*)HMD_attribute_row :: defined_by :: (1..1)

• DIM_attribute_row is a specialization of: DIM_row

Expresses the presence of selected attributes in the DIM.

• Attributes of DIM_class_row:

• Associations of DIM_class_row:
• is_based_on :: (1..1)Class :: has_dependent :: (0..*)
• is_related_by :: (0..*)DIM_relationship_row :: has_distal_class :: (0..1)
• is_active_parent :: (0..*)DIM_row :: has_active_parent :: (1..1)
• is_true_parent :: (0..*)DIM_row :: has_true_parent :: (1..1)
• defines :: (0..*)HMD_class_row :: defined_by :: (1..1)

• DIM_class_row is a specialization of: DIM_row

Expresses the presence of selected classes or clones thereof in the DIM.

Pointer to the first child relationship row for this class row.

Pointer to the first child attribute row for this class row.

• Attributes of DIM_notation:

• Associations of DIM_notation:
• annotates :: (1..1)DIM_row :: has_notation :: (0..*)
• links_note :: (1..1)Note :: is_notation :: (0..*)

Indicates the type of the note. Types include:

RV : Required value

CP : Conditional Presence

CN : Constraint

DM : Domain

CT : Comment

• Attributes of DIM_other_row:

• Associations of DIM_other_row:
• has_parent :: (1..1)DIM_row :: is_parent :: (0..*)
• defines :: (0..*)HMD_other_row :: defined_by :: (1..1)

• DIM_other_row is a specialization of: DIM_row

Expresses the presence of special rows in the DIM. There is one type of such additional row:

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.

• Attributes of DIM_relationship_row:

• Associations of DIM_relationship_row:
• has_distal_class :: (0..1)DIM_class_row :: is_related_by :: (0..*)
• has_other_half :: (1..1)DIM_relationship_row :: is_other_half :: (0..1)
• defines :: (0..*)HMD_relationship_row :: defined_by :: (1..1)
• is_based_on :: (1..1)Relationship :: has_dependent :: (0..*)

• DIM_relationship_row is a specialization of: DIM_row

Expresses the presence of selected association nodes (UML roles) in the DIM. Each relationship in the RIM and DIM produces two rows in the tabular DIM, one for the appearance of each end of the relationship in one of the DIM classes or clones.

Expresses whether this half-relationship can be followed in building an HMD. 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.

• Attributes of DIM_row:

• Associations of DIM_row:
• has_active_parent :: (1..1)DIM_class_row :: is_active_parent :: (0..*)
• has_true_parent :: (1..1)DIM_class_row :: is_true_parent :: (0..*)
• has_notation :: (0..*)DIM_notation :: annotates :: (1..1)
• is_parent :: (0..*)DIM_other_row :: has_parent :: (1..1)
• derives_from :: (0..1)DIM_row :: further_constrains :: (0..*)
• part_of :: (1..1)Design_information_model :: contains :: (1..*)

• DIM_row generalizes:

The DIM 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.

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.

A compound data element that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.

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.

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.

Points to the next sibling node in the tabular R-MIM.

Points to the previous sibling node in the tabular R-MIM.

The name of the row in the R-MIM. Rows representing attributes should not be renamed.

• Associations of DIM_state_row:
• is_based_on :: (1..1)State :: has_dependent :: (0..*)

• DIM_state_row is a specialization of: DIM_row

Expresses the presence of selected states in the DIM.

• Attributes of Domain_version:

• Associations of Domain_version:
• has :: (0..*)Coded_term :: in_version :: (1..1)
• has :: (0..*)Concept_relationship :: in_version :: (1..1)
• has :: (0..*)Observation_id_link :: in_version :: (1..1)
• has :: (0..*)Vocabulary_concept :: in_version :: (1..1)

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.

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.

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.

Comment - a summary of why the edits were made, and what was done.

• Generalization_relationship is a specialization of: Relationship

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. In HL7 information models, a subtype may be associated with only 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.

The supertype is the "source" of the relationship, and the subtypes are the "destinations" of this relationship.

• Attributes of Generic_type_parameter:

• Associations of Generic_type_parameter:
• has_allowed_types :: (0..*)Data_type :: allowed_for :: (0..*)
• defines :: (1..1)Data_type :: defined_by :: (0..*)
• has_instance_type :: (0..1)Data_type :: types :: (0..*)

• Generic_type_parameter is a specialization of: Data_type

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.

• Attributes of Hierarchical_message_description:

• Associations of Hierarchical_message_description:
• contains :: (1..*)HMD_row :: is_part_of :: (1..1)
• contains :: (1..*)Message_type :: is_part_of :: (1..1)
• in :: (1..1)Model :: has :: (0..*)

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.

The HMDs in the model are each given a unique, formal name.

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 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.

The HMDs in the model are each given a short, common use name that is familiar to domain experts. The short name does not need to be unique.

• Attributes of HL7_committee:

• Associations of HL7_committee:
• maintains :: (0..*)Data_type_category :: maintained_by :: (1..1)
• maintains :: (0..*)Design_category :: maintained_by :: (0..1)
• prepares :: (0..*)Model :: prepared_by :: (1..1)
• responsible_for :: (0..*)Project :: responsibility_of :: (1..1)
• maintains :: (0..*)Subject_area :: maintained_by :: (0..1)
• maintains :: (0..*)Use_case_category :: maintained_by :: (0..1)

Unique identifier assigned to each of the Technical Committees and Special Interest Groups of the HL7 Working Group.

The name of the Technical Committee or Special Interest Group.

Assigned committee identifier.

The approved mission statement or charter for this committee.

Name of the individual who facilitates modeling for this committee.

• Associations of HMD_attribute_row:
• defined_by :: (1..1)DIM_attribute_row :: defines :: (0..*)

• HMD_attribute_row is a specialization of: HMD_row

An attribute row represents a single attribute in the R-MIM.

• Associations of HMD_class_row:
• defined_by :: (1..1)DIM_class_row :: defines :: (0..*)

• HMD_class_row is a specialization of: HMD_row

There is one class row in an HMD. This row is the root of the HMD.

• Attributes of HMD_domain_constraint:

• Associations of HMD_domain_constraint:
• constrains :: (0..*)Message_row_control :: has_domain :: (0..1)
• links_domain :: (1..1)Vocabulary_concept :: is_constraint :: (0..*)

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.

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.

May specify the realm of applicability for this attribute row.

• Attributes of HMD_notation:

• Associations of HMD_notation:
• annotates :: (1..1)Message_row_control :: has_notation :: (0..*)
• links_note :: (1..1)Note :: is_notation :: (0..*)

Indicates the type of the note. Types include:

RV : Required value

CP : Conditional Presence

CN : Constraint

DM : Domain

CT : Comment

• Associations of HMD_other_row:
• defined_by :: (1..1)DIM_other_row :: defines :: (0..*)

• HMD_other_row is a specialization of: HMD_row

Links an 'other' R-MIM row into a message.

• Associations of HMD_relationship_row:
• defined_by :: (1..1)DIM_relationship_row :: defines :: (0..*)
• typed_by_CMET :: (0..1)Message_type :: types :: (0..*)

• HMD_relationship_row is a specialization of: HMD_row

An relationship row represents a single association, aggregation or inheritance relationship traversed in the R-MIM graph walk.

• Attributes of HMD_row:

• Associations of HMD_row:
• has_parent :: (1..1)HMD_row :: is_parent :: (0..*)
• is_part_of :: (1..1)Hierarchical_message_description :: contains :: (1..*)
• controlled_by :: (0..*)Message_row_control :: controls :: (1..1)

• HMD_row generalizes:

The rows of an HMD.

Indicates the nesting level of the row in the HMD.

Indicates the source of the MET - reuse a definition from this HMD, CMET or data type.

Captures the set ("|" delimited) of METs that this row is "of."

Captures the base MET name that a particular row possesses (row is "of" type MET).

This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.

• Attributes of Interaction:

• Associations of Interaction:
• received_by :: (1..1)Application_role :: receives :: (0..*)
• sent_by :: (1..1)Application_role :: sends :: (0..*)
• has_control_event :: (1..1)Control_event :: wraps_interaction :: (0..*)
• has :: (0..*)Design_annotation :: for :: (0..1)
• defined_in :: (1..1)Design_category :: includes :: (0..*)
• is_linked_by :: (0..*)Interaction_sequence :: links :: (1..1)
• has_type :: (1..1)Interaction_type :: is_type_for :: (0..*)
• transfers :: (1..1)Message_type :: transferred_by :: (1..*)
• in :: (1..1)Model :: has :: (0..*)
• invokes :: (0..*)Receiver_responsibility :: initated_by_receiver :: (0..1)
• has_responsibility_option :: (0..1)Receiver_responsibility :: is_responsibility_for :: (1..1)
• initiated_by :: (1..1)Trigger_event :: initiates :: (0..*)

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.

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>."

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.

A unique, formal name describing the interaction.

The short, meaningful name describing the interaction. Short names are not required to be unique.

• Attributes of Interaction_sequence:

• Associations of Interaction_sequence:
• links :: (1..1)Interaction :: is_linked_by :: (0..*)
• is_part_of :: (1..1)Storyboard :: contains :: (0..*)

Captures the sequence in which a particular interaction is included in a storyboard.

The order in which the interaction participates in the Storyboard.

The name assigned to the system in the Storyboard which transmits this interaction. Necessary for constructing diagrams of the interaction.

The name assigned to the system in the Storyboard which transmits this interaction. Necessary for constructing diagrams of 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.

• Attributes of Interaction_type:

• Associations of Interaction_type:
• supports_wrapper :: (1..1)Communication_wrapper :: may_wrap_interactions_of_type :: (1..1)
• is_type_for :: (0..*)Interaction :: has_type :: (1..1)
• has_allowed_receiver_responsibility_type :: (0..*)Interaction_type :: receiver_responsibility_type_for :: (0..*)

A categorization assigned to interactions to indicate how they behave and how they are used.

A unique identifier used to reference the interaction type.

A unique name for the interaction type.

Describes the purpose and use of interactions having this type.

Indicates whether the trigger event associated with the interaction should be associated with a state transition. Possible values are:

R - Trigger must have a state transition

N - Trigger must NOT have a state transition

A - Trigger event is permitted to be associated with a state transition, but is not required to be.

This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.

• Attributes of Message_row_control:

• Associations of Message_row_control:
• has_domain :: (0..1)HMD_domain_constraint :: constrains :: (0..*)
• has_notation :: (0..*)HMD_notation :: annotates :: (1..1)
• controls :: (1..1)HMD_row :: controlled_by :: (0..*)
• included_in :: (1..1)Message_type :: includes :: (0..*)

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.

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)..

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.

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).

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.

This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.

• Attributes of Message_type:

• Associations of Message_type:
• implemented_by :: (0..1)Communication_wrapper :: acts_as :: (1..1)
• implemented_by :: (0..1)Control_event :: acts_as :: (1..1)
• types :: (0..*)HMD_relationship_row :: typed_by_CMET :: (0..1)
• is_part_of :: (1..1)Hierarchical_message_description :: contains :: (1..*)
• transferred_by :: (1..*)Interaction :: transfers :: (1..1)
• includes :: (0..*)Message_row_control :: included_in :: (1..1)
• combined_in :: (0..1)Union_message_type :: combines :: (1..*)

• Message_type generalizes:

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.

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.

Informative text describing the intended use or purpose of a particular message 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.

• Attributes of Model:

• Associations of Model:
• has :: (0..*)Actor :: in :: (1..1)
• has :: (0..*)Application_role :: in :: (1..1)
• has :: (0..*)Application_role_relationship :: in :: (1..1)
• has :: (0..*)Class :: in :: (1..1)
• has :: (0..*)Communication_wrapper :: in :: (1..1)
• has :: (0..*)Data_type :: in :: (1..1)
• has :: (0..*)Data_type_category :: in :: (1..1)
• has :: (0..*)Design_category :: in :: (1..1)
• contains :: (0..*)Design_information_model :: is_part_of :: (1..1)
• prepared_by :: (1..1)HL7_committee :: prepares :: (0..*)
• has :: (0..*)Hierarchical_message_description :: in :: (1..1)
• has :: (0..*)Interaction :: in :: (1..1)
• has :: (0..*)Receiver_responsibility :: in :: (1..1)
• has :: (0..*)Storyboard :: in :: (1..1)
• has :: (0..*)Subject_area :: in :: (1..1)
• has :: (0..*)Trigger_event :: in :: (1..1)
• has :: (0..*)Use_case :: in :: (1..1)
• has :: (0..*)Use_case_category :: in :: (1..1)

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 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.

The date the model was last modified by the model developing organization.

A short form identifier of the organization responsible for the publication and maintenance of the model. . For HL7, this name shall be "HL7."

A short narrative describing the scope and intent of the model.

• Attributes of Note:

• Associations of Note:
• is_notation :: (0..*)DIM_notation :: links_note :: (1..1)
• content_for :: (0..*)Design_annotation :: has_content :: (1..1)
• is_notation :: (0..*)HMD_notation :: links_note :: (1..1)

• Note generalizes:

Provides additional descriptive information about the associated item.

Provides additional descriptive detail about the associated item.

Identifies the type of annotation. Supported types are: Design_notes, Implementation_notes, and External_standard_reference.

Allows for reference numbering of annotations when the models are published.

An encoded indication of where in the analytic and design process the note was first documented,

• Attributes of Observation_id_link:

• Associations of Observation_id_link:
• links_obs_term :: (1..1)Coded_term :: linked_to_set :: (0..*)
• in_version :: (1..1)Domain_version :: has :: (0..*)
• links_domain :: (0..1)Vocabulary_concept :: equates_to :: (0..*)

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.

• Attributes of Project:

• Associations of Project:
• responsibility_of :: (1..1)HL7_committee :: responsible_for :: (0..*)

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.

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.

The date on which the project scope was published in the ANSI PINS system.

• Attributes of Receiver_responsibility:

• Associations of Receiver_responsibility:
• is_responsibility_for :: (1..1)Interaction :: has_responsibility_option :: (0..1)
• initated_by_receiver :: (0..1)Interaction :: invokes :: (0..*)
• in :: (1..1)Model :: has :: (0..*)
• invokes :: (0..1)Trigger_event :: initated_by_receiver :: (0..*)

An interaction may have a list of possible receiver responsibilities. On receipt of an interaction having a receiver responsibility, the receiving application is required to perform the interaction and trigger event (if any) identified in one of the possible receiver responsibilities. If no interaction or trigger event is identified by a receiver responsibility, nothing is available.

A unique identifier used to reference the receiver responsibility.

Identifies the reason this particular receiver responsibility would be invoked (as opposed to other receiver responsibility options).

This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.

• Attributes of Reference_note:

• Reference_note is a specialization of: Note

A type of annotation used when referencing external standards. (Reference_annotation.type must be External_standard_reference.)

Identifies the name and version standard being referenced.

• Attributes of Relationship:

• Associations of Relationship:
• has_destination :: (1..1)Class :: is_destination :: (0..*)
• has_source :: (1..1)Class :: is_source :: (0..*)
• has_dependent :: (0..*)DIM_relationship_row :: is_based_on :: (1..1)

• Relationship generalizes:

A relationship between classes. In HL7 information models, three types of relationship are accomodated: generalization-specialization; association; and composite aggregation.

Subject to constraints expressed for the sub-types of relationship, the relationship may exist between classes, or between instances (objects) 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 further defined in the sub-types of Relationship.

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.

• Attributes of State:

• Associations of State:
• has_dependent :: (0..*)DIM_state_row :: is_based_on :: (1..1)
• has_substate :: (0..*)State :: is_substate_of :: (0..1)
• ends :: (0..*)State_transition :: ends_in :: (1..1)
• is_start_of :: (0..*)State_transition :: starts_from :: (1..1)
• in :: (1..1)Subject_class :: has :: (0..*)

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.

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.

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.

• Attributes of State_transition:

• Associations of State_transition:
• ends_in :: (1..1)State :: ends :: (0..*)
• starts_from :: (1..1)State :: is_start_of :: (0..*)
• identified_by :: (0..1)Trigger_event :: identifies :: (0..*)
• captured_in :: (0..*)Use_case :: describes :: (0..1)

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 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. The name of a transition should reflect the state in which the transition ends. It is acceptable (and common) for multiple transitions to end in the same state, and therefore have the same name.

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.

• Attributes of Storyboard:

• Associations of Storyboard:
• defined_in :: (1..1)Design_category :: includes :: (0..*)
• contains :: (0..*)Interaction_sequence :: is_part_of :: (1..1)
• in :: (1..1)Model :: has :: (0..*)
• exemplifies :: (0..*)Storyboard_example :: is_part_of :: (1..1)
• contains :: (0..*)Use_case_sequence :: contains :: (1..1)

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.

A short phrase that provides a descriptive title for the storyboard.

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 using an HL7-defined naming convention.

The purpose for which the storyboard was created. Frequently it describes the generic set of actions that the storyboard represents.

This is a compound data type that holds the id and previous_ID for history, and the first_ver and last_ver for versioning.

• Attributes of Storyboard_example:

• Associations of Storyboard_example:
• is_part_of :: (1..1)Storyboard :: exemplifies :: (0..*)

Provides a real-world example of the sequence of events captured in a Storyboard.

A unique identifier assigned to the storyboard example.

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.

• Associations of Structural_attribute:
• structure_defined_by :: (0..*)Vocabulary_concept :: defines_structure_for :: (0..1)

• Structural_attribute is a specialization of: Attribute

An attribute of a Class that provides a linkage between that Class and the Concepts (codes) that are used to further define or qualify the class's function within the model and/or to extend the class's generalization hierarchy.

The structural attribute must have a coded data type, and the allowable set of code values is limited to those that have been formally adopted by HL7.

• Attributes of Subject_area:

• Associations of Subject_area:
• includes :: (1..*)Class :: appears_in :: (0..*)
• holds :: (1..*)Class :: primarily_resides_in :: (0..1)
• maintained_by :: (0..1)HL7_committee :: maintains :: (0..*)
• in :: (1..1)Model :: has :: (0..*)
• is_nested_in :: (0..1)Subject_area :: nests :: (0..*)

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 class stewardship responsibilities and classes of interest to a particular committee.

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.

Short informative text describing the subject area so as to be clear what type of Classes it includes.