<?xml version="1.0" encoding="UTF-8"?>
<staticModel xmlns="urn:hl7-org:v3/mif" name="0210" title="HL7 Reference Information Model"
    representationKind="flat" isSerializable="false"
    xsi:schemaLocation="urn:hl7-org:v3/mif ..\..\org.eclipse.ohf.h3et.core\Resources\MIF\Schemas\mifStaticModelFlat.xsd"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <historyItem dateTime="6/30/2005" version="02-10">
        <description>
            <p>This version of the RIM reflects corrections and changes approved in harmonization
                through March 09, 2005. This version is the tenth of the RIMs that contain content
                that will be part of Release 2 of the normative RIM.</p>
            <p>Questions should be addressed to the co-chairs of the Methodology and Modeling
                Committee and/or sent to the M&amp;M e-mail list at mnm@lists.hl7.org</p>
        </description>
    </historyItem>
    <packageLocation root="DEFN" realm="Universal" artifact="RIM"/>
    <header>
        <renderingInformation schemaVersion="1" renderingTime="7/30/2005 T24:53:20"
            application="RoseTree 3.0.8">
            <renderingNotes>This model was rendered into XML using software provided to HL7 by
                Beeler Consulting LLC. Transform: $RCSfile: RoseTreeRimToMIFStaticModel.xsl,v $
                $Revision: 1.4 $ $Date: 2005/04/17 03:20:15 $</renderingNotes>
        </renderingInformation>
        <legalese copyrightOwner="Health Level Seven" copyrightYears="2005">
            <notation>All rights reserved.</notation>
        </legalese>
        <responsibleGroup organizationName="Health Level Seven"/>
        <contributor>
            <role/>
            <name key="Beeler, George Jr" name="George Beeler, Jr., PhD."/>
            <affiliation/>
        </contributor>
        <contributor>
            <role/>
            <name key="Case, James" name="James Case, DVM, PhD."/>
            <affiliation/>
        </contributor>
        <contributor>
            <role/>
            <name key="Curry, Jane" name="Jane Curry"/>
            <affiliation/>
        </contributor>
        <contributor>
            <role/>
            <name key="Hueber, Ann" name="Ann Hueber"/>
            <affiliation/>
        </contributor>
        <contributor>
            <role/>
            <name key="McKenzie, Lloyd" name="Lloyd Mckenzie"/>
            <affiliation/>
        </contributor>
        <contributor>
            <role/>
            <name key="Schadow, Gunther" name="Gunther Schadow, M.D., PhD."/>
            <affiliation/>
        </contributor>
        <contributor>
            <role/>
            <name key="Shakir, Abdul-Malik" name="Abdul-Malik Shakir"/>
            <affiliation/>
        </contributor>
        <contributor>
            <role>Contact</role>
            <name name="HL7 Headquarters Staff"/>
            <email>mailto://HQ@HL7.org</email>
            <notes>Comments or questions about this document may be may be addressed to:</notes>
        </contributor>
    </header>
    <annotations>
        <description>
            <text>
                <p>The Health Level Seven (HL7) Reference Information Model (RIM) is a static model
                    of health and health care information as viewed within the scope of HL7
                    standards development activities. It is the combined consensus view of
                    information from the perspective of the HL7 working group and the HL7
                    international affiliates. The RIM is the ultimate source from which all HL7
                    version 3.0 protocol specification standards draw their information-related
                    content.</p>
            </text>
        </description>
        <usageNotes>
            <text>
                <div title="History of the RIM">
                    <p>Development of the HL7 RIM began in April 1996. The first release of the RIM
                        was adopted by the HL7 Technical Steering Committee at the January 1997
                        working group meeting. This release was known as the HL7 draft RIM version
                        0.80.</p>
                    <p>The next two working group meetings focused on gaining familiarity with the
                        draft RIM and implementing a process for obtaining and reconciling proposed
                        enhancements to the model. The RIM maintenance process became known as "RIM
                        harmonization." Between 1998 and 2000, there were nine harmonization
                        meetings to consider proposed enhancements to the draft RIM. The meetings
                        culminated in version 1.0 of the HL7 RIM, unveiled at the HL7 working group
                        meeting held in January 2001. The harmonization meetings focused on five
                        major themes:</p>
                    <ul>
                        <li>
                            <b>Ensure coverage of HL7 version 2.x.</b> This set of change proposals
                            introduced content to the draft model to ensure that it included all the
                            information content of HL7 version 2.x.</li>
                        <li>
                            <b>Remove unsubstantiated content from the model.</b> This set of change
                            proposals focused on removing content from the draft model that the
                            steward technical committee did not originate and could find no
                            rationale for retaining.</li>
                        <li>
                            <b>Unified service action model.</b> This set of change proposals
                            introduced a concise, well-defined set of structures and vocabularies
                            that address the information needs of a wide variety of clinical
                            scenarios. This collection of proposals, know as USAM, involved the
                            combined effort of multiple technical committees.</li>
                        <li>
                            <b>Ensure quality.</b> This set of change proposals addressed
                            inconsistencies in the draft model and conflicts between the model and
                            the modeling style guide. It began the practice of recording and
                            tracking open issues in the model.</li>
                        <li>
                            <b>Address the "left hand side" of the model.</b> This set of change
                            proposals introduced powerful structures and vocabularies for the
                            non-clinical portions of the model (patient administration, finance,
                            scheduling). Like the unified service action model, this proposal
                            involved the combined effort of multiple technical committees.</li>
                    </ul>
                    <p>The harmonization process and themes have produced an HL7 reference
                        information model that is credible, clear, comprehensive, concise, and
                        consistent. Its structure is both flexible and extensible, and its contents
                        can be readily mapped to the HL7 2.x message standard and other widely used
                        healthcare dataset specifications.</p>
                    <p>This ballot is release 1.22 of the HL7 RIM. It is a model that continues to
                        be fine tuned as technical committees use it for an ever widening scope of
                        work as part of developing a family of HL7 model-driven standards, HL7
                        version 3.0. The RIM is now remarkably stable and at the same time the
                        harmonization process ensures it will always be relevant and reflective of
                        the information needs of the HL7 standards. </p>
                </div>
                <div title="Use of the RIM by HL7">
                    <p>The HL7 RIM is a critical component of the V3 development process. It is the
                        root of all information models and structures developed as part of the V3
                        development process.</p>
                    <p>The HL7 V3 standard development process is a model-driven methodology in
                        which a network of inter-related models are developed that depict the static
                        and behavioral aspects of the requirements and design of HL7 standards, as
                        well as the underlying semantics and business rules that govern them.</p>
                    <p>The RIM provides a static view of the information needs of HL7 V3 standards.
                        It includes class and state-machine diagrams and is accompanied by use case
                        models, interaction models, data type models, terminology models, and other
                        types of models to provide a complete view of the requirements and design of
                        HL7 standards. The classes, attributes, state-machines, and relationships in
                        the RIM are used to derive domain-specific information models that are then
                        transformed through a series of constraining refinement processes to
                        eventually yield a static model of the information content of an HL7
                        standard.</p>
                    <p>The HL7 V3 standard development process defines the rules governing the
                        derivation of domain information models from the RIM and the refinement of
                        those models into HL7 standard specifications. The rules require that all
                        information structures in derived models be traceable back to the RIM and
                        that their semantic and related business rules not conflict with those
                        specified in the RIM. The RIM therefore is the ultimate source for all
                        information content in HL7 V3 standards.</p>
                    <p>The RIM is used by HL7 international affiliates to extend HL7 V3 standards to
                        meet local needs. Through a process known as localization, V3 standard
                        specifications are extended using the RIM as the source for new information
                        content. This new information is derived from the RIM and refined in the
                        same manner used to create the original specification.</p>
                </div>
                <div title="Uses of the RIM Outside of HL7">
                    <p>The RIM is primarily for use by HL7 and its international affiliates.
                        However, others outside of HL7 have also found the RIM useful. Early
                        adopters of the V3 standards development process have used the RIM to
                        develop HL7-like message specifications in their own environments. These
                        early adopters include vendors, large integrated delivery networks, and
                        government agencies within the United States and internationally. These same
                        early adopters are extremely active in HL7 and provide practical input to
                        the RIM and other aspects of V3 the development process.</p>
                    <p>Some HL7 member organizations have reported using the RIM as a source of
                        input to their enterprise information architectures or as a starting place
                        for systems analysis and design. The RIM may indeed be useful for such
                        purposes; however, HL7 provides no assurance that the RIM is useful for
                        anything other than as a reference model for HL7 standards development.</p>
                    <p>The RIM is only one model of healthcare information needs. The abstract style
                        of the RIM and the ability to extend the RIM through vocabulary
                        specifications make the RIM applicable to any conceivable healthcare system
                        information interchange scenario. In fact, it is conceptually applicable to
                        any information domain involving entities playing roles and participating in
                        acts.</p>
                    <p>The universal applicability of the RIM makes it particularly useful for an
                        organization like HL7 that has to consider the needs of a large and diverse
                        membership. The style of the RIM makes it extremely stable, which is another
                        important characteristic for HL7. The HL7 standards development process
                        calls for the creation of domain specific models derived from the RIM and
                        the incremental refinement of those models into design models that are
                        specific to the problem area. These problem area specific design models
                        narrow the abstractness of the RIM and include constraints on attribute
                        values and class relationships that are use case specific. External
                        organizations considering using the HL7 RIM are advised to adopt a similar
                        process of deriving design models as a transformation of the RIM.</p>
                </div>
            </text>
        </usageNotes>
        <walkthrough>
            <text>
                <p>The RIM uses a very abstract modeling style. The back-bone classes of the RIM and
                    their structural attributes are its core. An understanding of these classes and
                    attributes are essential to understanding the RIM.</p>
                <div title="RIM as an abstract model">
                    <p>The RIM is comprised of six "back-bone" classes:</p>
                    <ul>
                        <li>
                            <classRef root="DEFN" realm="Universal" artifact="RIM" className="Act"/>
                            which represents the actions that are executed and must be documented as
                            health care is managed and provided;</li>
                        <li>
                            <classRef root="DEFN" realm="Universal" artifact="RIM"
                                className="Participation"/> which expresses the context for an act
                            in terms such as who performed it, for whom it was done, where it was
                            done, etc.;</li>
                        <li>
                            <classRef root="DEFN" realm="Universal" artifact="RIM"
                                className="Entity"/> which represents the physical things and beings
                            that are of interest to, and take part in health care;</li>
                        <li>
                            <classRef root="DEFN" realm="Universal" artifact="RIM" className="Role"
                            /> which establishes the roles that entities play as they participate in
                            health care acts;</li>
                        <li>
                            <classRef root="DEFN" realm="Universal" artifact="RIM"
                                className="ActRelationship"/> which represents the binding of one
                            act to another, such as the relationship between an order for an
                            observation and the observation event as it occurs; and</li>
                        <li>
                            <classRef root="DEFN" realm="Universal" artifact="RIM"
                                className="RoleLink"/> which represents relationships between
                            individual roles.</li>
                    </ul>
                    <p>Three of these classes -- Act, Entity and Role -- are further represented by
                        a set of specialized classes, or sub-types. In the HL7 representation, a
                        sub-type is only added to the RIM if it requires one or more attributes or
                        associations that are not inherited from its parents. Classes that represent
                        distinct concepts, but which need no further attributes or associations are
                        represented solely as a unique code in the controlling vocabulary.
                        Therefore, these three classes include the following coded attributes, which
                        serve to further define the concept being modeled:</p>
                    <ul>
                        <li>
                            <b>classCode </b>(in Act, Entity and Role) represents the exact class or
                            concept intended, whether or not that class is represented as a class in
                            the RIM hierarchy;</li>
                        <li>
                            <b>moodCode </b>(in Act) and <b>determinerCode </b>(in Entity) an
                            attribute that distinguishes whether the class represents an instance or
                            a kind of Act or Entity. If the class is a specialization of Act then
                            moodCode further delineates the instance as an occurrence or an intent;</li>
                        <li>
                            <b>code </b>(in Act, Entity and Role) provides for further
                            classification within a particular classCode value, such as a particular
                            type of observation within the Observation class. </li>
                    </ul>
                    <p>The other three RIM back-bone classes -- Participation, ActRelationship and
                        RoleLink -- are not represented by generalization-specialization
                        hierarchies. Nevertheless, these classes represent a variety of concepts,
                        such as different forms of participation or different kinds of relationships
                        between acts. These distinctions are represented by a <b>typeCode
                        </b>attribute that is asserted for each of these classes.</p>
                </div>
                <div title="Representation of RIM class structure">
                    <p>As noted previously, the RIM is modeled using a subset of the semantics
                        embodied in UML. The RIM is a set of UML classes, each containing one or
                        more attributes, which are assigned a data type based on an independent
                        specification of Version 3 data types. The classes are linked either by a
                        set of association relationships, identified by unique role names, or by
                        generalization relationships.</p>
                    <p>Each of these elements includes a textual definition. The appearance of
                        attributes and associations is controlled by cardinality and related
                        constraints applied to the attributes and to the roles that link the
                        associations to the classes. </p>
                </div>
                <div title="Representation of controlling vocabulary">
                    <p>Several of the attributes in the RIM are coded with the CS data type, which
                        means that the value set to be used for those attributes must be drawn from
                        the set of codes that have been defined by HL7. The classCode and typeCode
                        attributes mentioned above are examples of attributes with a CS data type.</p>
                    <p>All of the code sets for these attributes are included as part of this ballot
                        and are subject to the same voting principles as the classes in the RIM.
                        Each code set is represented as a vocabulary domain -- the set of all
                        concepts that can be taken as valid values in an instance of a coded field
                        or attribute. It is important to note that a vocabulary domain consists of a
                        set of concepts, not a set of words or codes.</p>
                </div>
                <div title="Related specifications">
                    <p>As noted above, each attribute in the RIM is assigned a data type. The formal
                        specification for these data types is embodied in the normative
                        specification "<externalRef ref="http://datatypes-its-xml.htm#"
                            alt="HL7 V3 Data Types Implementable Technology Specification for XML"
                        />" and the informative document "<externalRef ref="http://datatypes.htm#"
                            alt="Data Types Abstract Specification"/>", both of which are currently
                        being balloted by HL7. A table that abstracts the definition of the data
                        types used in the RIM is included in this ballot as Appendix B.</p>
                </div>
            </text>
        </walkthrough>
        <otherAnnotation type="Implications of Balloting the RIM">
            <text>
                <p>Balloting the RIM establishes it as more than just an internal HL7 artifact. As a
                    balloted standard the RIM will be advanced as an American National Standards
                    Institute (ANSI) standard and perhaps as an ISO standard. Other ANSI or ISO
                    accredited standards organizations such as X12 and CEN-TC251 (European
                    Standardization of Health Informatics) have expressed interest in using or
                    referencing the RIM in their own standards development work. Establishing the
                    RIM as a standard makes its use by other standards development organizations
                    (SDO) much easier. The potential for tremendous benefits exists by having a
                    common reference information model used across multiple healthcare SDOs.</p>
                <p>A balloted RIM is also important to meet the local standards needs of HL7
                    International Affiliates. In order for the affiliates to apply localized
                    extensions to HL7 standards according to the HL7 V3 standard development
                    process, the RIM itself must be a standard. This is often mandated by local
                    geopolitical jurisdictions, e.g., to ensure that local standards are extensions
                    of already approved general standards.</p>
                <p>Federal, state, and local governmental agencies in the United States are
                    encouraged to consider accredited national standards when conducting initiatives
                    in which the standards are applicable. As a standard for information content of
                    HL7 interoperability standards, U.S. governmental agencies will need to consider
                    the applicability of the RIM when establishing health care systems
                    interoperability solutions.</p>
                <div title="Normative Portions of the RIM">
                    <p>The RIM consists of classes assigned to one or more subject area packages.
                        Attributes, Relationships, and State Machines are associated with classes.
                        Only the classes included in the NormativeContent subject area and their
                        associated attributes, relationships, and state machines are normative.
                        Relationships between normative and non-normative classes are non-normative.</p>
                    <p>The RIM is expressed using the Unified Modeling Language (UML) with HL7
                        specific tags as extensions to the UML model element metadata. All standard
                        UML model element metadata values are normative but only the following HL7
                        extensions are also normative:</p>
                    <ul>
                        <li>Class.stateAttribute</li>
                        <li>Class.classCode</li>
                        <li>Attribute.mandatoryInclusion</li>
                        <li>Attribute.cardinality</li>
                        <li>Attribute.vocabDomain</li>
                        <li>Attribute.vocabStrength</li>
                    </ul>
                    <p>The remaining HL7 extensions are for administrative use only and are not part
                        of the normative RIM specification.</p>
                </div>
                <div title="Normative References">
                    <p>The V3 Data type specifications (<externalRef ref="http://datatypes.htm#"
                            alt="Data Types Abstract Specification"/> and <externalRef
                            ref="http://datatypes-its-xml.htm#"
                            alt="V3 Data Types Implementable Technology Specification for XML"/>)
                        are related normative standards that are balloted independent of the RIM.
                        The <externalRef ref="http://vocabulary.htm#" alt="HL7 Vocabulary Domain"/>
                        specification is an informative reference that includes a variety of tables
                        and terminology references that are cited as domains by various RIM
                        attributes. The vocabulary specifications for what are termed "structural
                        attributes" are part of the normative RIM ballot because they are
                        fundamental to the proper representation of health information using the
                        RIM. A list of these normative tables and hyperlinks to them are provided
                            <divRef id="sbj-rimdiv">at the end of this introduction</divRef>.</p>
                </div>
                <div title="Meaning of Normative">
                    <p>The normative portions of the RIM are the only portions subject to ballot and
                        are the only portions for which conformance rules are defined. Substantive
                        changes to normative RIM model elements require a re-ballot of the RIM. When
                        re-balloting the RIM only the substantive changes are subject to ballot. The
                        following changes to the RIM are not considered substantive:</p>
                    <ul>
                        <li>Changes to descriptive text for model elements that does not materially
                            alter the semantics of the model element;</li>
                        <li>Changes to class package assignments other than additions or deletions
                            from the NormativeContent subject area;</li>
                        <li>Changes in package hierarchies or names;</li>
                        <li>Changes to class diagram layouts;</li>
                        <li>Changes to model elements outside the NormativeContent subject area
                            package.</li>
                    </ul>
                </div>
            </text>
        </otherAnnotation>
        <otherAnnotation type="Normative structural vocabulary for the RIM">
            <text>
                <p>The HL7 vocabulary domains are detailed in a separate document. A selected
                    sub-set of these tables is part of the normative RIM specification. These are
                    the tables for the structural attributes (those with data type of "CS") in the
                    normative classes. A hyper-link to each of these tables is provided in the RIM
                    specification at the point where the table is cited. In addition, direct linkage
                    to these tables is provided below:</p>
                <table borders="0">
                    <col width="0.3"/>
                    <tbody>
                        <tr>
                            <td>
                                <p>
                                    <vocabularyDomainRef root="DEFN" realm="Universal" version="1"
                                        artifact="VO" subArtifact="VD" name="ActClass"/>
                                </p>
                            </td>
                            <td>
                                <p>
                                    <vocabularyDomainRef root="DEFN" realm="Universal" version="1"
                                        artifact="VO" subArtifact="VD" name="ActStatus"/>
                                </p>
                            </td>
                            <td>
                                <p>
                                    <vocabularyDomainRef root="DEFN" realm="Universal" version="1"
                                        artifact="VO" subArtifact="VD" name="ParticipationType"/>
                                </p>
                            </td>
                        </tr>
                        <tr>
                            <td>
                                <p>
                                    <vocabularyDomainRef root="DEFN" realm="Universal" version="1"
                                        artifact="VO" subArtifact="VD" name="ActMood"/>
                                </p>
                            </td>
                            <td>
                                <p>
                                    <vocabularyDomainRef root="DEFN" realm="Universal" version="1"
                                        artifact="VO" subArtifact="VD" name="ContextControl"/>
                                </p>
                            </td>
                            <td>
                                <p>
                                    <vocabularyDomainRef root="DEFN" realm="Universal" version="1"
                                        artifact="VO" subArtifact="VD"
                                        name="RelationshipConjunction"/>
                                </p>
                            </td>
                        </tr>
                        <tr>
                            <td>
                                <p>
                                    <vocabularyDomainRef root="DEFN" realm="Universal" version="1"
                                        artifact="VO" subArtifact="VD"
                                        name="ActRelationshipCheckpoint"/>
                                </p>
                            </td>
                            <td>
                                <p>
                                    <vocabularyDomainRef root="DEFN" realm="Universal" version="1"
                                        artifact="VO" subArtifact="VD" name="EntityClass"/>
                                </p>
                            </td>
                            <td>
                                <p>
                                    <vocabularyDomainRef root="DEFN" realm="Universal" version="1"
                                        artifact="VO" subArtifact="VD" name="RoleClass"/>
                                </p>
                            </td>
                        </tr>
                        <tr>
                            <td>
                                <p>
                                    <vocabularyDomainRef root="DEFN" realm="Universal" version="1"
                                        artifact="VO" subArtifact="VD" name="ActRelationshipJoin"/>
                                </p>
                            </td>
                            <td>
                                <p>
                                    <vocabularyDomainRef root="DEFN" realm="Universal" version="1"
                                        artifact="VO" subArtifact="VD" name="EntityDeterminer"/>
                                </p>
                            </td>
                            <td>
                                <p>
                                    <vocabularyDomainRef root="DEFN" realm="Universal" version="1"
                                        artifact="VO" subArtifact="VD" name="RoleLinkType"/>
                                </p>
                            </td>
                        </tr>
                        <tr>
                            <td>
                                <p>
                                    <vocabularyDomainRef root="DEFN" realm="Universal" version="1"
                                        artifact="VO" subArtifact="VD" name="ActRelationshipSplit"/>
                                </p>
                            </td>
                            <td>
                                <p>
                                    <vocabularyDomainRef root="DEFN" realm="Universal" version="1"
                                        artifact="VO" subArtifact="VD" name="EntityStatus"/>
                                </p>
                            </td>
                            <td>
                                <p>
                                    <vocabularyDomainRef root="DEFN" realm="Universal" version="1"
                                        artifact="VO" subArtifact="VD" name="RoleStatus"/>
                                </p>
                            </td>
                        </tr>
                        <tr>
                            <td>
                                <p>
                                    <vocabularyDomainRef root="DEFN" realm="Universal" version="1"
                                        artifact="VO" subArtifact="VD" name="ActRelationshipType"/>
                                </p>
                            </td>
                            <td>
                                <p>
                                    <vocabularyDomainRef root="DEFN" realm="Universal" version="1"
                                        artifact="VO" subArtifact="VD"
                                        name="ManagedParticipationStatus"/>
                                </p>
                            </td>
                            <td/>
                        </tr>
                    </tbody>
                </table>
            </text>
        </otherAnnotation>
        <appendix name="A" title="Overview of the RIM">
            <text>
                <div title="Purpose">
                    <p>This document is meant to serve as an "Executive Summary" of the basic
                        concepts and rationale behind the design and development of the HL7
                        Reference Information Model (RIM). It is not meant to be an "application
                        guide" on RIM usage although several partial examples of usage are presented
                        when they are deemed helpful in explaining the fundamental design and
                        development concepts of the RIM.</p>
                </div>
                <div title="Overview">
                    <p>A Reference Information Model (RIM) is constructed to facilitate consistent
                        sharing and usage of data across multiple "local" contexts. In general, the
                        broader the scope of interest, the more important it is to make explicit all
                        assumptions about a topic or domain-of-interest. The HL7 Version 3 RIM is
                        designed to provide a unified framework for, and to serve as a comprehensive
                        source of, all information used by an HL7 Specification. The RIM
                        specifically and unambiguously articulates both the explicit definitions of
                        healthcare concepts - the "things of interest" to the world of healthcare
                        information systems - and the relationships (aka "associations") between
                        these concepts-of-interest.</p>
                    <p>HL7 V3 Specifications (e.g. HL7 V3 messages, structured documents, etc.)
                        permit loosely-coupled information systems to interoperate (i.e. exchange
                        data) in a variety of healthcare delivery contexts including those found in
                        disparate provider organizations, perspectives, and jurisdictions. The scope
                        of the HL7 RIM therefore includes all of the information that is required to
                        be sent between, and processed by, participating healthcare information
                        systems. In addition, it should be noted that the RIM does not model (nor
                        need to model) information stored by a given healthcare information system
                        but never transmitted to another system. </p>
                    <p>The RIM is expressed using a visual modeling syntax based on the Unified
                        Modeling Language (UML). (Specific variances between "standard UML" and "HL7
                        UML" as manifest in the RIM, such as the placement of association names, are
                        currently under review by the HL7 Modeling and Methodology Technical
                        Committee with the goal of moving to a maximum alignment between the two
                        syntaxes.) HL7 also maintains a database ("RIM repository") containing the
                        details of each RIM concept, attribute, and association including the item's
                        rationale, definition, constraints, and edit/change history. At some point
                        in the future, any or all of this information may be formally published in
                        an HL7-specific UML profile. </p>
                    <p>It is important to note that the RIM is not intended to be a logical or
                        physical model of a database, a design for a particular vendor's information
                        system, or a perspective focused on a particular healthcare organization or
                        enterprise. In fact, the RIM is not intended to represent a particular set
                        of HL7 messages, but rather the collective universe of data and
                        relationships from which any relevant HL7 message could be constructed.
                        Specific users of the RIM are expected to utilize relevant portions of the
                        RIM as needed, adopting its content to their own information modeling needs
                        and notations. </p>
                </div>
                <div title="The Rationale Behind the RIM's Design">
                    <p>The overarching structure of the RIM is based on six "core" classes: Act,
                        Entity, Role, Participation, ActRelationship, and RoleLink. Each class is
                        defined in Section 1.4. Following is a discussion of the fundamental
                        thinking behind, and basic usage guidelines for, the six classes and their
                        inter-relationships.</p>
                    <p>The HL7 RIM identifies two major "high-level" concepts that are fundamental
                        to understanding the world of healthcare information: intentional "actions"
                        or "services" (Acts), and "people, places and things" that are of interest
                        in the world of healthcare (Entities).</p>
                    <p>The concept "Act" (and its subclasses) represents all of the intentional
                        actions documented by a healthcare professional in either a clinical or
                        administrative context. The presence of the Act class as one of the core RIM
                        classes is a reflection of HL7's view that "from a messaging/system
                        communication perspective, healthcare consists of a series of attributed,
                        intentional actions. Thus, instances of the class/concept Act include both
                        clinical observations (e.g. patient temperature) and interventions (e.g.
                        administer medication), and administrative actions (e.g. admit patient).
                        Note that in this "act-centered" view of healthcare, the act of an
                        observation takes on two seemingly contradictory meanings: "the act of
                        recognizing and documenting a particular fact," and "the description of the
                        thing observed." In other words, an instance of an Observation Act
                        represents both the attributed act of observing and the results of the
                        observation. Both aspects of this expanded definition of an Observation Act
                        are captured by specific attributes of the class Act or its subclass
                        Observation.</p>
                    <p>The concept "Entity" (and its subclasses) includes all living subjects (e.g.
                        persons, animals), organizations (e.g. formal and informal), materials (e.g.
                        durable and non-durable goods, food, tissue, containers,), and places that
                        may be of interest in a healthcare messaging context. It should be noted
                        that the concept of "collection of information" (e.g. a medical record) is
                            <b>not </b> a instance or subclass of Entity, but is instead considered
                        as a collection of attributed Acts.</p>
                    <p>The RIM places two additional classes - Role and Participation - between Act
                        and Entity. The Role class models several important concepts that are
                        prevalent in the healthcare delivery domain. First, Role captures the fact
                        that the various "static" entities may "temporally" assume one or more
                        "roles" (e.g. patient, primary care physician, responsible party, Registered
                        Nurse etc.) in a particular healthcare context. Second, the concepts of
                        "capability" (e.g. Advanced Cardiac Life Support) and "certification" (e.g.
                        Licensed Practical Nurse) are also modeled using instances of the Role
                        class. Finally, careful examination of the multiplicity (0..1) and names
                        (scoper, player) of the <b>two</b> associations between Entity and Role
                        reveals that the Role class can be used to "group" instances of Entity.</p>
                    <p>It is important to distinguish the concept of Entity-in-a-Role from the
                        Act-specific concept of "the function-based role played by an
                        Entity-in-a-Role in the context of a specific Act." These semantics are
                        modeled using instances of the Participation class. For example, an
                        Anesthesia Resident (Entity-in-a-Role) administers anesthesia (Participation
                        as "provider" in the Act "administer anesthesia") to a patient
                        (Participation as a 'recipient" in the Act "administer anesthesia." <b>Note
                            that the absence of a direct association between the Participation and
                            Entity classes is a manifestation of an underlying HL7 RIM assumption
                            that all instances of Entity involved in an Act are participating in the
                            Act in a particular Role.</b>
                    </p>
                    <p>In summary, both the Participation and the Role classes are necessary to
                        fully model the complex semantics that exist between instances of Entity and
                        Act, and a concise summary of the HL7 RIM's view of healthcare can be stated
                        as follows: <b>At the highest level of abstraction, healthcare consists of a
                            series of intentional, attributed Acts performed to, by, on behalf of,
                            utilizing or in some way involving one or more instances of a
                            Participating ("as primary provider," etc.) Entity-in-a-Role ("John
                            Smith in the role of Patient"). </b>
                    </p>
                    <p>The two remaining classes in the RIM - ActRelationship and RoleLink - are
                        used to "associate" or "link" instances of the class with which it is
                        associated. The class RoleLink is used to establish a "dependency-based
                        link" (e.g. accountability, chain-of-trust, etc.) between <b>two
                        </b>instances of an Entity-in-a-Role. The semantics of ActRelationship are
                        explained below.</p>
                </div>
                <div title="Linking Acts Together: The Semantics of ActRelationship">
                    <p>An understanding of the semantics and application of ActRelationship begins
                        with, an understanding of the "fractal" or "robotic arm" nature of a set of
                        Acts. This perspective is, in turn, best viewed from the overarching
                        framework of the categorization of three types of "collecting relationships"
                        represented by instances of ActRelationship: whole/part (e.g. lab or test
                        batteries (see the discussion of the "robotic arm" below); rule-based (e.g.
                        care plans, protocols, etc.); and cognitive actions (e.g. judgment,
                        renaming, replacement, subsumption, supported by/reason for, etc.).</p>
                    <p>Regarding the "fractal" or "robotic arm" discussion, As mentioned above,
                        instances of ActRelationship can be used to model the "fractal" or "robotic
                        arm" notion behind a "whole/part" relationship. Consider a surgical
                        procedure such as a laparoscopic cholecystectomy. The procedure may be
                        represented as a single instance of Act, or, alternatively, as a
                        "collection" of (partially ordered) instances of Act each of which is a
                        finer granularity than the entire procedure, e.g. obtain consent, administer
                        pre-op medication, administer anesthesia (throughout the surgical
                        procedure), make the incision, etc. In turn, for any of the more finely
                        granulated actions just mentioned, further granulation/decomposition may
                        occur. The degree of granularity is clearly dependent on the context of the
                        action(s) and the interest level/perspective of the party performing (or not
                        performing) the decomposition. Figure 1 shows a "surgeon's-eye view" of some
                        of the instances of Act and ActRelationship for the exemplar
                        cholecystectomy..</p>
                    <p>
                        <figure>
                            <fixedImage>
                                <pixmap href="./Graphics/RIM_IntroFig1.gif"/>
                            </fixedImage>
                            <caption>Example of sequential plan construction for laparoscopic
                                cholecystectomy. Edged boxes are Act instances (all in definition,
                                or 'master' mood.) Rounded boxes are ActRelationship instances of
                                type: has-component. The sequenceNumber attribute orders the
                                relationships into a sequence. Each act can in turn be decomposed
                                into plan-components.</caption>
                        </figure>
                    </p>
                    <p>In summary, the classes Act and ActRelationship have been designed to allow
                        for representing the rich semantics of each of three types of collections
                        mentioned above at whatever coarseness or fineness of granularity is
                        appropriate to the specific messaging context. In addition, the various of
                        types of collections and levels of granularity represented by instances of
                        ActRelationship can (and will) be expected to be used to collectively
                        capture the complex semantics of clinical reasoning, e.g. an instance of
                        ActRelationship (e.g. "supported by") could be used to form a link from an
                        instance of an observation Act representing a specific lab test (e.g.
                        sedimentation rate = 48 to an instance of an observation Act representing a
                        particular diagnosis (e.g. DX = Systemic Lupus Erythematosus).</p>
                </div>
                <div title="Definitions of the Six Core Rim Classes">
                    <div title="Act">
                        <p>An <classRef root="DEFN" realm="Universal" artifact="RIM" className="Act"
                            /> is an action of interest that has happened, can happen, is happening,
                            is intended to happen, or is requested/demanded to happen. An act is an
                            intentional action in the business domain of HL7. Healthcare (and any
                            profession or business) is constituted of intentional actions. An Act
                            instance is a record of such an intentional action. </p>
                    </div>
                    <div title="Entity">
                        <p>An <classRef root="DEFN" realm="Universal" artifact="RIM"
                                className="Entity"/> is a class or specific instance of a physical
                            thing or an organization/group of physical things capable of
                            participating in Acts; an artifact. This includes living subjects,
                            organizations, material, and places. The Entity hierarchy encompasses
                            human beings, organizations, living organisms, devices, pharmaceutical
                            substances, etc. It does not include events/acts/actions, the definition
                            of things, or the roles that things can play (e.g. patient, provider).
                        </p>
                    </div>
                    <div title="Role">
                        <p>A <classRef root="DEFN" realm="Universal" artifact="RIM" className="Role"
                            /> is a categorization of competency of the Entity that plays the Role
                            as defined by the Entity that scopes the Role.</p>
                        <p>An Entity, in a particular Role, can participate in an Act. Note that a
                            particular entity in a particular role can participate in an act in many
                            ways. Thus, a Person in the role of a practitioner can participate in a
                            patient encounter as a rounding physician or as an attending physician.
                            The Role defines the competency of the Entity irrespective of any Act,
                            as opposed to Participation, which is limited to the scope of an Act.</p>
                        <p>Each role is 'played' by one Entity (the Entity that is in the role) and
                            is usually 'scoped' by another. Thus the Role of 'patient' is played by
                            (usually) a person and scoped by the provider from whom the patient will
                            receive services. Similarly, the employer scopes an Employee role. </p>
                    </div>
                    <div title="Participation">
                        <p>A <classRef root="DEFN" realm="Universal" artifact="RIM"
                                className="Participation"/> is an association between a Role and an
                            Act. The Participation represents the involvement of the Entity playing
                            the Role with regard to the associated Act. A single Role may
                            participate in multiple Acts and a single Act may have multiple
                            participating Roles. A single Participation is always an association
                            between a particular Role and a particular Act. Participation is limited
                            to the scope of the Act, as opposed to Role, which defines the
                            competency of an Entity irrespective of any Act.</p>
                    </div>
                    <div title="ActRelationship">
                        <p>An <classRef root="DEFN" realm="Universal" artifact="RIM"
                                className="ActRelationship"/> is an association between a pair of
                            Acts. This includes Act to Act associations such as collector/component,
                            predecessor/successor, and cause/outcome.</p>
                        <p> The class has two associations to the Act class, one named "source" the
                            other named "target". .... Since the relationships associated with an
                            Act are considered properties of the source act object. That means that
                            the originator of the information reported in an act object is not only
                            responsible for the attribute values of that object, but also for all
                            its outgoing relationships.</p>
                        <p> The rule of attribution is that all act relationships are attributed to
                            the responsible actor of the Act at the source of the ActRelationship
                            (the "source act".) </p>
                    </div>
                    <div title="RoleLink">
                        <p>A <classRef root="DEFN" realm="Universal" artifact="RIM"
                                className="RoleLink"/> is a connection between two roles expressing
                            a dependency between those roles. </p>
                    </div>
                    <div title="Sub Classes of Act, Entity and Role">
                        <p>Entity, Act and Role are "high-level" classes, although they are not
                            "abstract" classes in the formal sense (i.e. meaningful instances of
                            both classes are quite common). As a result, it has been necessary to
                            define a number of more specialized subclasses of these three classes to
                            specify the additional data (class attributes) required in more specific
                            contexts (e.g. the Observation subclass of Act and the Living Subject
                            and Material subclasses of Entity). Attributes of a subclass must be
                            both useful and unique to that subclass. Subclasses inherit all of the
                            attributes of their parent superclass.</p>
                        <p>There are meaningful subclasses in each of these hierarchies that do not
                            require additional attributes, and therefore are not represented as
                            classes in the RIM. The "classCode" attribute in each of these
                            hierarchies specifies which class is represented. The code set that can
                            be used with the "classCode" attributes are tightly controlled by HL7. A
                            second attribute in each hierarchy, the "code" attribute provides a
                            further classification of subtypes of each subclass.</p>
                    </div>
                    <div title="The Concept of Mood">
                        <p>The Act class represents intentional actions. These actions can exist in
                            different "moods". Moods describe activities as they progress in the
                            business cycle, from defined, through planned and ordered to complete.
                            The mood of an Act is specified by the value of the Act.moodCode
                            attribute.</p>
                        <p> Any instance of an Act assumes one and only one mood and will not change
                            its mood along its life cycle. The moods - definition, intent, order,
                            event - seem to specify a life cycle of an activity. However, the
                            participants in the activity in these different moods are different, as
                            is the data. Therefore, the mood of an Act instance is static. The
                            progression actualization (i.e., the progression from defined, through
                            planned and ordered, to being performed) is called the "business cycle"
                            to distinguish it from the "life cycle" of a single act instance.
                            Related Act instances that form such a "business cycle" are linked
                            through the ActRelationship class. </p>
                    </div>
                </div>
                <div title="Data Type and Vocabulary Specifications">
                    <p>The RIM class, attribute and association definitions provide detail about
                        logical meaning, but a full specification requires data type and vocabulary
                        specifications. <b>Data Types</b> define the allowable values of attributes
                        and what these values "mean." Data types are therefore the fundamental
                        building blocks that shape (and constrain) all the semantics that can
                        ultimately expressed in the RIM. For HL7 Version 3, the datatype
                        specifications are found in the <externalRef ref="http://datatypes.htm#"
                            alt="Data Types Abstract Specification"/> and in the <externalRef
                            ref="http://datatypes-its-xml.htm#"
                            alt="V3 Data Types Implementable Technology Specification for XML"/> A
                        summary of the data types is also provided in Appendix B.</p>
                    <p>Vocabulary specifications for attributes include the assignment of a default
                        domain, and a "coding strength." <b>Vocabulary Domains</b> are explicitly
                        defined in <externalRef ref="http://vocabulary.htm#"
                            alt="Vocabulary Domains"/>. They document cross-reference and
                        alternative representations among coding systems, while keeping track of the
                        logical concepts being expressed by each code. Each coded attribute may only
                        be expressed using specific Vocabulary Domains.</p>
                    <p>
                        <b>Coding strength</b> is a coded property of an attribute that states
                        whether or not a user of the HL7 Version 3 standard may communicate a coded
                        value that is not part of the defined domain. Such a value is termed an
                        "exception" to the domain. Coding strength may have one of two values.
                            <b>Coded with Exceptions (CWE) </b> allows the end user to send a term
                        from a local coding system in place of a term from the formal domain.
                            <b>Coded , No Exceptions (CNE) </b> states that communication instances
                        may only contain codes that are in the domain that constrains the
                    attribute.</p>
                </div>
                <div title="HL7 Version 3 Methodology and the RIM">
                    <p>In summary, the primary motivation for the development of the RIM was the
                        desire to clearly define the various data elements and relationships that
                        comprise the healthcare information space. A direct outgrowth of this
                        knowledge explication exercise is the ability to reuse the same concept in
                        multiple healthcare messages. The complete process of defining a message is
                        defined and discussed in the V3 Guide and accompanying HL7 Message
                        Definition Framework (MDF). The basic steps include definition and
                        documentation of the data interchange needs (e.g. a set of messages to
                        support a particular clinical or administrative process) via a Storyboard,
                        the selection/restriction of the RIM to those classes and attributes needed
                        to populate the given message, and the subsequent application of additional
                        constraints on number and possible values of each attribute. </p>
                    <p>Refer to the HL7 Version 3 Guide and MDF for further information.</p>
                </div>
            </text>
        </appendix>
        <appendix name="B" title="Summary of Version 3 Data Types">
            <text>
                <div title="Overview of Data Types">
                    <p>The following table summarizes the definition of each of the data types being
                        balloted as part of HL7 Version 3, as of December 2, 2002. Subsequent RIM
                        ballots will accompany a complete data type specification and will include
                        direct hyper-links to those specifications from the body of the RIM
                        document.</p>
                    <table>
                        <caption> Overview of HL7 version 3 data types </caption>
                        <col width="79"/>
                        <col width="60"/>
                        <col width="413"/>
                        <thead>
                            <tr>
                                <th>Name</th>
                                <th>Symbol</th>
                                <th>Description</th>
                            </tr>
                        </thead>
                        <tbody>
                            <tr>
                                <td>DataValue</td>
                                <td>
                                    <datatypeRef name="ANY"/>
                                </td>
                                <td> Defines the basic properties of every data value. This is an
                                    abstract type, meaning that no value can be just a data value
                                    without belonging to any concrete type. Every concrete type is a
                                    specialization of this general abstract DataValue type. </td>
                            </tr>
                            <tr>
                                <td>Boolean</td>
                                <td>
                                    <datatypeRef name="BL"/>
                                </td>
                                <td> The Boolean type stands for the values of two-valued logic. A
                                    Boolean value can be either <i>true</i> or <i>false</i>, or, as
                                    any other value may be NULL. </td>
                            </tr>
                            <tr>
                                <td>Encapsulated Data</td>
                                <td>
                                    <datatypeRef name="ED"/>
                                </td>
                                <td> Data that is primarily intended for human interpretation or for
                                    further machine processing outside the scope of HL7. This
                                    includes unformatted or formatted written language, multimedia
                                    data, or structured information in as defined by a different
                                    standard (e.g., XML-signatures.) Instead of the data itself, an
                                        <datatypeRef name="ED"/> may contain only a reference (see
                                        <datatypeRef name="TEL"/>.) Note that the <datatypeRef
                                        name="ST"/> data type is a specialization of the
                                        <datatypeRef name="ED"/> data type when the <datatypeRef
                                        name="ED"/> media type is text/plain. </td>
                            </tr>
                            <tr>
                                <td>Character String</td>
                                <td>
                                    <datatypeRef name="ST"/>
                                </td>
                                <td> The character string data type stands for text data, primarily
                                    intended for machine processing (e.g., sorting, querying,
                                    indexing, etc.) Used for names, symbols, and formal expressions.
                                </td>
                            </tr>
                            <tr>
                                <td>Concept Descriptor</td>
                                <td>
                                    <datatypeRef name="CD"/>
                                </td>
                                <td> A concept descriptor represents any kind of concept usually by
                                    giving a code defined in a code system. A concept descriptor can
                                    contain the original text or phrase that served as the basis of
                                    the coding and one or more translations into different coding
                                    systems. A concept descriptor can also contain qualifiers to
                                    describe, e.g., the concept of a "left foot" as a
                                    postcoordinated term built from the primary code "FOOT" and the
                                    qualifier "LEFT". In exceptional cases, the concept descriptor
                                    need not contain a code but only the original text describing
                                    that concept. </td>
                            </tr>
                            <tr>
                                <td>Coded Simple Value</td>
                                <td>
                                    <datatypeRef name="CS"/>
                                </td>
                                <td> Coded data in its simplest form, where only the code and
                                    display name is not predetermined. The code system and code
                                    system version is fixed by the context in which the CS value
                                    occurs. CS is used for coded attributes that have a single
                                    HL7-defined value set. </td>
                            </tr>
                            <tr>
                                <td>Coded With Equivalents</td>
                                <td>
                                    <datatypeRef name="CE"/>
                                </td>
                                <td> Coded data that consists of a coded value (CV) and, optionally,
                                    coded value(s) from other coding systems that identify the same
                                    concept. Used when alternative codes may exist. </td>
                            </tr>
                            <tr>
                                <td>Character String with Code</td>
                                <td>
                                    <datatypeRef name="SC"/>
                                </td>
                                <td> A <datatypeRef name="ST"/> that optionally may have a code
                                    attached. The text must always be present if a code is present.
                                    The code is often a local code. </td>
                            </tr>
                            <tr>
                                <td>Instance Identifier</td>
                                <td>
                                    <datatypeRef name="II"/>
                                </td>
                                <td> An identifier that uniquely identifies a thing or object.
                                    Examples are object identifier for HL7 RIM objects, medical
                                    record number, order id, service catalog item id, Vehicle
                                    Identification Number (VIN), etc. Instance identifiers are
                                    defined based on ISO object identifiers. </td>
                            </tr>
                            <tr>
                                <td>Telecommunication Address</td>
                                <td>
                                    <datatypeRef name="TEL"/>
                                </td>
                                <td> A telephone number (voice or fax), e-mail address, or other
                                    locator for a resource mediated by telecommunication equipment.
                                    The address is specified as a Universal Resource Locator (URL)
                                    qualified by time specification and use codes that help deciding
                                    which address to use for a given time and purpose. </td>
                            </tr>
                            <tr>
                                <td>Postal Address</td>
                                <td>
                                    <datatypeRef name="AD"/>
                                </td>
                                <td> Mailing and home or office addresses. A sequence of address
                                    parts, such as street or post office Box, city, postal code,
                                    country, etc. </td>
                            </tr>
                            <tr>
                                <td>Entity Name</td>
                                <td>
                                    <datatypeRef name="EN"/>
                                </td>
                                <td> A name for a person, organization, place or thing. A sequence
                                    of name parts, such as first name or family name, prefix,
                                    suffix, etc. Examples for entity name values are "Jim Bob
                                    Walton, Jr.", "Health Level Seven, Inc.", "Lake Tahoe", etc. An
                                    entity name may be as simple as a character string or may
                                    consist of several entity name parts, such as, "Jim", "Bob",
                                    "Walton", and "Jr.", "Health Level Seven" and "Inc.", "Lake" and
                                    "Tahoe". </td>
                            </tr>
                            <tr>
                                <td>Trivial Name</td>
                                <td>
                                    <datatypeRef name="TN"/>
                                </td>
                                <td> A restriction of entity name that is effectively a simple
                                    string used for a simple name for things and places. </td>
                            </tr>
                            <tr>
                                <td>Person Name</td>
                                <td>
                                    <datatypeRef name="PN"/>
                                </td>
                                <td> A name for a person. A sequence of name parts, such as first
                                    name or family name, prefix, suffix, etc. </td>
                            </tr>
                            <tr>
                                <td>Organization Name</td>
                                <td>
                                    <datatypeRef name="ON"/>
                                </td>
                                <td> A name for an organization. A sequence of name parts. </td>
                            </tr>
                            <tr>
                                <td>Integer Number</td>
                                <td>
                                    <datatypeRef name="INT"/>
                                </td>
                                <td> Integer numbers (-1,0,1,2, 100, 3398129, etc.) are precise
                                    numbers that are results of counting and enumerating. Integer
                                    numbers are discrete, the set of integers is infinite but
                                    countable. No arbitrary limit is imposed on the range of integer
                                    numbers. Two NULL flavors are defined for the positive and
                                    negative infinity. </td>
                            </tr>
                            <tr>
                                <td>Real Number</td>
                                <td>
                                    <datatypeRef name="REAL"/>
                                </td>
                                <td> Fractional numbers. Typically used whenever quantities are
                                    measured, estimated, or computed from other real numbers. The
                                    typical representation is decimal, where the number of
                                    significant decimal digits is known as the precision. </td>
                            </tr>
                            <tr>
                                <td>Ratio</td>
                                <td>
                                    <datatypeRef name="RTO"/>
                                </td>
                                <td> A quantity constructed as the quotient of a numerator quantity
                                    divided by a denominator quantity. Common factors in the
                                    numerator and denominator are not automatically cancelled out.
                                    The <i>RTO</i> data type supports titers (e.g., "1:128") and
                                    other quantities produced by laboratories that truly represent
                                    ratios. Ratios are not simply "structured numerics",
                                    particularly blood pressure measurements (e.g. "120/60") are not
                                    ratios. In many cases the <datatypeRef name="REAL"/> should be
                                    used instead of the <i>RTO</i>. </td>
                            </tr>
                            <tr>
                                <td>Physical Quantity</td>
                                <td>
                                    <datatypeRef name="PQ"/>
                                </td>
                                <td> A dimensioned quantity expressing the result of measuring.
                                </td>
                            </tr>
                            <tr>
                                <td>Monetary Amount</td>
                                <td>
                                    <datatypeRef name="MO"/>
                                </td>
                                <td> A monetary amount is a quantity expressing the amount of money
                                    in some currency. Currencies are the units in which monetary
                                    amounts are denominated in different economic regions. While the
                                    monetary amount is a single kind of quantity (money) the
                                    exchange rates between the different units are variable. This is
                                    the principal difference between physical quantity and monetary
                                    amounts, and the reason why currency units are not physical
                                    units. </td>
                            </tr>
                            <tr>
                                <td>Point in Time</td>
                                <td>
                                    <datatypeRef name="TS"/>
                                </td>
                                <td> A quantity specifying a point on the axis of natural time. A
                                    point in time is most often represented as a calendar
                                    expression. </td>
                            </tr>
                            <tr>
                                <td>Set</td>
                                <td>
                                    <datatypeRef name="SET"/>
                                </td>
                                <td> A value that contains other distinct values in no particular
                                    order. </td>
                            </tr>
                            <tr>
                                <td>Sequence</td>
                                <td>
                                    <datatypeRef name="LIST"/>
                                </td>
                                <td> A value that contains other discrete values in a defined
                                    sequence. </td>
                            </tr>
                            <tr>
                                <td>Bag</td>
                                <td>
                                    <datatypeRef name="BAG"/>
                                </td>
                                <td> An unordered collection of values, where each value can be
                                    contained more than once in the bag. </td>
                            </tr>
                            <tr>
                                <td>Interval</td>
                                <td>
                                    <datatypeRef name="IVL"/>
                                </td>
                                <td> A set of consecutive values of an ordered base data type. </td>
                            </tr>
                            <tr>
                                <td>History</td>
                                <td>
                                    <datatypeRef name="HIST"/>
                                </td>
                                <td> A set of data values that conform to the history item (HXIT)
                                    type, (i.e., that have a valid-time property). The history
                                    information is not limited to the past; expected future values
                                    can also appear. </td>
                            </tr>
                            <tr>
                                <td>Uncertain Value - Probabilistic</td>
                                <td>
                                    <datatypeRef name="UVP"/>
                                </td>
                                <td> A generic data type extension used to specify a probability
                                    expressing the information producer's belief that the given
                                    value holds. </td>
                            </tr>
                            <tr>
                                <td>Parametric Probability Distribution</td>
                                <td>
                                    <datatypeRef name="PPD"/>
                                </td>
                                <td> A generic data type extension specifying uncertainty of
                                    quantitative data using a distribution function and its
                                    parameters. Aside from the specific parameters of the
                                    distribution, a mean (expected value) and standard deviation is
                                    always given to help maintain a minimum layer of
                                    interoperability if receiving applications cannot deal with a
                                    certain probability distribution. </td>
                            </tr>
                            <tr>
                                <td>General Timing Specification</td>
                                <td>
                                    <datatypeRef name="GTS"/>
                                </td>
                                <td> A set of points in time, specifying the timing of events and
                                    actions and the cyclical validity-patterns that may exist for
                                    certain kinds of information, such as phone numbers (evening,
                                    daytime), addresses (so called "snowbirds," residing in the
                                    south during winter and north during summer) and office hours.
                                </td>
                            </tr>
                        </tbody>
                    </table>
                </div>
            </text>
        </appendix>
    </annotations>
    <figure>
        <fixedImage>
            <pixmap href="./Graphics/RIM_billboard.pdf"/>
        </fixedImage>
    </figure>
    <ownedSubjectAreaPackage name="CommunicationInfrastructure" sortKey="1">
        <figure>
            <fixedImage>
                <pixmap href="./Graphics/RIM_CoreInfrastructure.gif"/>
            </fixedImage>
        </figure>
        <annotations>
            <description>
                <text>
                    <p>A collection of subject areas that define the technical infrastructure of
                        HL7, including messaging, structured documents and components.</p>
                </text>
            </description>
        </annotations>
        <ownedSubjectAreaPackage name="CoreInfrastructure" sortKey="1">
            <annotations>
                <description>
                    <text>
                        <p>This subject area contains those classes that provide foundation elements
                            for the HL7 communications infrastructure.</p>
                        <p>Link to a <divRef id="CoreInfrastructure">class diagram</divRef> of this
                            subject area.</p>
                    </text>
                </description>
            </annotations>
            <ownedClass name="ActHeir"/>
            <ownedClass name="EntityHeir"/>
            <ownedClass name="InfrastructureRoot"/>
            <ownedClass name="RoleHeir"/>
        </ownedSubjectAreaPackage>
        <ownedSubjectAreaPackage name="MessageCommunicationsControl" sortKey="2">
            <figure>
                <fixedImage>
                    <pixmap href="./Graphics/RIM_MessageCommunicationsControl.gif"/>
                </fixedImage>
            </figure>
            <annotations>
                <description>
                    <text>
                        <p>A collection of classes related to the technical definition and control
                            of message-based communication in HL7.</p>
                        <p>Link to a <divRef id="MessageCommunicationsControl">class
                            diagram</divRef> of this subject area.</p>
                    </text>
                </description>
            </annotations>
            <ownedSubjectAreaPackage name="MessageControl" sortKey="1">
                <figure>
                    <fixedImage>
                        <pixmap href="./Graphics/RIM_MessageControl.gif"/>
                    </fixedImage>
                </figure>
                <annotations>
                    <description>
                        <text>
                            <p>This subject area contains those RIM elements involved in the
                                control, communication and acknowledgement of messages.</p>
                            <p>Link to a <divRef id="MessageControl">class diagram</divRef> of this
                                subject area.</p>
                        </text>
                    </description>
                </annotations>
                <ownedClass name="Acknowledgement"/>
                <ownedClass name="AcknowledgementDetail"/>
                <ownedClass name="Attachment"/>
                <ownedClass name="AttentionLine"/>
                <ownedClass name="Batch"/>
                <ownedClass name="CommunicationFunction"/>
                <ownedClass name="Message"/>
                <ownedClass name="Transmission"/>
            </ownedSubjectAreaPackage>
            <ownedSubjectAreaPackage name="QueryControl" sortKey="2">
                <figure>
                    <fixedImage>
                        <pixmap href="./Graphics/RIM_QueryControl.gif"/>
                    </fixedImage>
                </figure>
                <annotations>
                    <description>
                        <text>
                            <p>This subject area contains those classes necessary to formulate,
                                communicate and respond to query messages.</p>
                            <p>Link to a <divRef id="QueryControl">class diagram</divRef> of this
                                subject area.</p>
                        </text>
                    </description>
                </annotations>
                <ownedClass name="LogicalExpression"/>
                <ownedClass name="Parameter"/>
                <ownedClass name="ParameterItem"/>
                <ownedClass name="ParameterList"/>
                <ownedClass name="QueryAck"/>
                <ownedClass name="QueryByParameter"/>
                <ownedClass name="QueryBySelection"/>
                <ownedClass name="QueryContinuation"/>
                <ownedClass name="QueryEvent"/>
                <ownedClass name="QuerySpec"/>
                <ownedClass name="RelationalExpression"/>
                <ownedClass name="SelectionExpression"/>
                <ownedClass name="SortControl"/>
            </ownedSubjectAreaPackage>
        </ownedSubjectAreaPackage>
        <ownedSubjectAreaPackage name="StructuredDocuments" sortKey="3">
            <figure>
                <fixedImage>
                    <pixmap href="./Graphics/RIM_StructuredDocuments.gif"/>
                </fixedImage>
            </figure>
            <annotations>
                <description>
                    <text>
                        <p>A collection of classes related to the definition of document-based
                            communication in HL7, as represented by the Clinical Document
                            Architecture standards.</p>
                        <p>Link to a <divRef id="StructuredDocuments">class diagram</divRef> of this
                            subject area.</p>
                    </text>
                </description>
            </annotations>
            <ownedClass name="ContextStructure"/>
            <ownedClass name="Document"/>
        </ownedSubjectAreaPackage>
    </ownedSubjectAreaPackage>
    <ownedSubjectAreaPackage name="FoundationClasses" sortKey="2">
        <figure>
            <fixedImage>
                <pixmap href="./Graphics/RIM_NormativeContent.gif"/>
            </fixedImage>
        </figure>
        <annotations>
            <description>
                <text>
                    <p>This collection of classes and their associations represent the "normative"
                        content of the HL7 RIM. The content of this subject area has been balloted
                        within HL7 as a normative document.</p>
                    <p>Link to a <divRef id="FoundationClasses">class diagram</divRef> of this
                        subject area.</p>
                </text>
            </description>
        </annotations>
        <ownedSubjectAreaPackage name="Acts" sortKey="1">
            <figure>
                <fixedImage>
                    <pixmap href="./Graphics/RIM_Acts.gif"/>
                </fixedImage>
            </figure>
            <annotations>
                <description>
                    <text>
                        <p>A collection of classes including the Act class and its specializations.
                            These relate to the actions and events that constitute health care
                            services.</p>
                        <p>Link to a <divRef id="Acts">class diagram</divRef> of this subject
                        area.</p>
                    </text>
                </description>
            </annotations>
            <ownedClass name="Account"/>
            <ownedClass name="Act"/>
            <ownedClass name="ActRelationship"/>
            <ownedClass name="ControlAct"/>
            <ownedClass name="DeviceTask"/>
            <ownedClass name="DiagnosticImage"/>
            <ownedClass name="Diet"/>
            <ownedClass name="FinancialContract"/>
            <ownedClass name="FinancialTransaction"/>
            <ownedClass name="InvoiceElement"/>
            <ownedClass name="ManagedParticipation"/>
            <ownedClass name="Observation"/>
            <ownedClass name="Participation"/>
            <ownedClass name="PatientEncounter"/>
            <ownedClass name="Procedure"/>
            <ownedClass name="PublicHealthCase"/>
            <ownedClass name="SubstanceAdministration"/>
            <ownedClass name="Supply"/>
            <ownedClass name="WorkingList"/>
        </ownedSubjectAreaPackage>
        <ownedSubjectAreaPackage name="Entities" sortKey="2">
            <figure>
                <fixedImage>
                    <pixmap href="./Graphics/RIM_Entities.gif"/>
                </fixedImage>
            </figure>
            <annotations>
                <description>
                    <text>
                        <p>A collection of classes related to the Entity class, its specializations
                            and related qualifying classes. The classes represent health care
                            stakeholders and other things of interest to health care.</p>
                        <p>Link to a <divRef id="Entities">class diagram</divRef> of this subject
                            area.</p>
                    </text>
                </description>
            </annotations>
            <ownedClass name="Container"/>
            <ownedClass name="Device"/>
            <ownedClass name="Entity"/>
            <ownedClass name="LanguageCommunication"/>
            <ownedClass name="LivingSubject"/>
            <ownedClass name="ManufacturedMaterial"/>
            <ownedClass name="Material"/>
            <ownedClass name="NonPersonLivingSubject"/>
            <ownedClass name="Organization"/>
            <ownedClass name="Person"/>
            <ownedClass name="Place"/>
        </ownedSubjectAreaPackage>
        <ownedSubjectAreaPackage name="Roles" sortKey="3">
            <figure>
                <fixedImage>
                    <pixmap href="./Graphics/RIM_Roles.gif"/>
                </fixedImage>
            </figure>
            <annotations>
                <description>
                    <text>
                        <p>A collection of classes related to the Role class and its
                            specializations. These classes focus on the roles participants may play
                            in health care.</p>
                        <p>Link to a <divRef id="Roles">class diagram</divRef> of this subject
                        area.</p>
                    </text>
                </description>
            </annotations>
            <ownedClass name="Access"/>
            <ownedClass name="Employee"/>
            <ownedClass name="LicensedEntity"/>
            <ownedClass name="Patient"/>
            <ownedClass name="Role"/>
            <ownedClass name="RoleLink"/>
        </ownedSubjectAreaPackage>
    </ownedSubjectAreaPackage>
    <ownedEntryPoint className="Act"/>
    <ownedEntryPoint className="Entity"/>
    <ownedEntryPoint className="Parameter"/>
    <ownedEntryPoint className="Role"/>
    <ownedEntryPoint className="Transmission"/>
    <ownedClass>
        <class name="Account" isAbstract="false">
            <supplierStructuralDomain mnemonic="ACCT"/>
            <annotations>
                <definition>
                    <text>
                        <p>An Act representing a category of financial transactions that are tracked
                            and reported together with a single balance.</p>
                        <p>
                            <i>Discussion:</i> This can be used to represent the accumulated total
                            of billable amounts for goods or services received, payments made for
                            goods or services, and debit and credit accounts between which financial
                            transactions flow.</p>
                        <p>
                            <i>Examples:</i> Patient accounts; Encounter accounts; Cost centers;
                            Accounts receivable</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="balanceAmt" sortKey="1" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The total of the debit and credit transactions that have occurred
                                against the account over its lifetime.</p>
                            <p>Discussion: The balance of an account will generally be communicated
                                in the currency identified as the account's currencyCode. However,
                                it is allowed to communicate the balance in alternative
                            currencies.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="MO"/>
            </attribute>
            <attribute name="currencyCode" sortKey="2" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Indicates the currency that the account is managed in.</p>
                            <p>
                                <i>Discussion:</i> Specific amounts might be reported in another
                                currency however this represents the default currency for activity
                                in this account.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="Currency" codingStrength="CWE"/>
            </attribute>
            <attribute name="interestRateQuantity" sortKey="3" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A ratio that indicates the rate of interest that the account balance
                                is subject to, and the term over which the interest rate compounds.</p>
                            <p>
                                <i>Discussion:</i> This may represent interest charged (e.g. for
                                loans, overdue accounts, etc.) or credited (investments, etc.)
                                depending on the type of account.</p>
                            <p>
                                <i>Examples:</i> 0.10/1a (10%/year); 0.0005895/1d (.05895%/day)</p>
                            <p>
                                <i>Constraints:</i> Unit of the denominator PQ data type must be
                                comparable to seconds. (I.e. the denominator must be measured in
                                time.)</p>
                        </text>
                    </definition>
                </annotations>
                <type name="RTO">
                    <supplierBindingArgumentDatatype name="MO"/>
                    <supplierBindingArgumentDatatype name="PQ"/>
                </type>
            </attribute>
            <attribute name="allowedBalanceQuantity" sortKey="4" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>An interval describing the minimum and maximum allowed balances for
                                an account.</p>
                            <p>
                                <i>Discussion:</i> These are not necessarily 'hard' limits (i.e. the
                                account may go above or below the specified amounts), however, they
                                represent the 'target' range for the account, and there may be
                                consequences for going outside the specified boundaries. It is not
                                necessary to specify both upper and lower limits (or either) for an
                                account.</p>
                            <p>
                                <i>Examples:</i> 'stop loss' limits; credit limits</p>
                        </text>
                    </definition>
                </annotations>
                <type name="IVL">
                    <supplierBindingArgumentDatatype name="MO"/>
                </type>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="Act" isAbstract="false">
            <supplierStructuralDomain mnemonic="ACT"/>
            <annotations>
                <definition>
                    <text>
                        <p>A record of something that is being done, has been done, can be done, or
                            is intended or requested to be done.</p>
                        <p>
                            <i>Examples:</i> The kinds of acts that are common in health care are
                            (1) a clinical observation, (2) an assessment of health condition (such
                            as problems and diagnoses), (3) healthcare goals, (4) treatment services
                            (such as medication, surgery, physical and psychological therapy), (5)
                            assisting, monitoring or attending, (6) training and education services
                            to patients and their next of kin, (7) and notary services (such as
                            advanced directives or living will), (8) editing and maintaining
                            documents, and many others.</p>
                        <p>
                            <i>Discussion and Rationale:</i> Acts are the pivot of the RIM; all
                            domain information and processes are represented primarily in Acts. Any
                            profession or business, including healthcare, is primarily constituted
                            of intentional actions, performed and recorded by responsible actors. An
                            Act-instance is a record of such an intentional action. Intentional
                            actions are distinguished from something that happens by forces of
                            nature (natural events). Such natural events are not Acts by themselves,
                            but may be recorded as observed (Observation).</p>
                        <p>Acts connect to Entities in their Roles through Participations and
                            connect to other Acts through ActRelationships. Participations are the
                            authors, performers and other responsible parties as well as subjects
                            and beneficiaries (which includes tools and material used in the
                            performance of the act, which are also subjects). The moodCode
                            distinguishes between Acts that are meant as factual records, vs.
                            records of intended or ordered services, and the other modalities in
                            which act can appear.</p>
                        <p>One of the Participations that all acts have (at least implicitly) is a
                            primary author, who is responsible of the Act and who "owns" the act.
                            Responsibility for the act means responsibility for what is being stated
                            in the Act and as what it is stated. Ownership of the act is assumed in
                            the sense of who may operationally modify the same act. Ownership and
                            responsibility of the Act is not the same as ownership or responsibility
                            of what the Act-object refers to in the real world. The same real world
                            activity can be described by two people, each being the author of their
                            Act, describing the same real world activity. Yet one can be a witness
                            while the other can be a principal performer. The performer has
                            responsibilities for the physical actions; the witness only has
                            responsibility for making a true statement to the best of his or her
                            ability. The two Act-instances may even disagree, but because each is
                            properly attributed to its author, such disagreements can exist side by
                            side and left to arbitration by a recipient of these Act-instances.</p>
                        <p>In this sense, an Act-instance represents a "statement" according to
                            Rector and Nowlan (1991) [Foundations for an electronic medical record.
                            Methods Inf Med. 30.] Rector and Nowlan have emphasized the importance
                            of understanding the medical record not as a collection of facts, but "a
                            faithful record of what clinicians have heard, seen, thought, and done."
                            Rector and Nowlan go on saying that "the other requirements for a
                            medical record, e.g., that it be attributable and permanent, follow
                            naturally from this view." Indeed the Act class is this attributable
                            statement, and the rules of updating acts (discussed in the
                            state-transition model, see Act.statusCode) versus generating new
                            Act-instances are designed according to this principle of permanent
                            attributable statements.</p>
                        <p>Rector and Nolan focus on the electronic medical record as a collection
                            of statements, while attributed statements, these are still mostly
                            factual statements. However, the Act class goes beyond this limitation
                            to attributed factual statements, representing what is known as
                            "speech-acts" in linguistics and philosophy. The notion of speech-act
                            includes that there is pragmatic meaning in language utterances, aside
                            from just factual statements; and that these utterances interact with
                            the real world to change the state of affairs, even directly cause
                            physical activities to happen. For example, an order is a speech act
                            that (provided it is issued adequately) will cause the ordered action to
                            be physically performed. The speech act theory has culminated in the
                            seminal work by Austin (1962) [How to do things with words. Oxford
                            University Press].</p>
                        <p>An activity in the real world may progress from defined, through planned
                            and ordered to executed, which is represented as the mood of the Act.
                            Even though one might think of a single activity as progressing from
                            planned to executed, this progression is reflected by multiple
                            Act-instances, each having one and only one mood that will not change
                            along the Act-instance's life cycle. This is because the attribution and
                            content of speech acts along this progression of an activity may be
                            different, and it is often critical that a permanent and faithful record
                            be maintained of this progression. The specification of orders or
                            promises or plans must not be overwritten by the specification of what
                            was actually done, so as to allow comparing actions with their earlier
                            specifications. Act-instances that describe this progression of the same
                            real world activity are linked through the ActRelationships (of the
                            relationship category "sequel").</p>
                        <p>Act as statements or speech-acts are the only representation of real
                            world facts or processes in the HL7 RIM. The truth about the real world
                            is constructed through a combination (and arbitration) of such
                            attributed statements only, and there is no class in the RIM whose
                            objects represent "objective state of affairs" or "real processes"
                            independent from attributed statements. As such, there is no distinction
                            between an activity and its documentation. Every Act includes both to
                            varying degrees. For example, a factual statement made about recent (but
                            past) activities, authored (and signed) by the performer of such
                            activities, is commonly known as a procedure report or original
                            documentations (e.g., surgical procedure report, clinic note etc.).
                            Conversely, a status update on an activity that is presently in
                            progress, authored by the performer (or a close observer) is considered
                            to capture that activity (and is later superceded by a full procedure
                            report). However, both status update and procedure report are acts of
                            the same kind, only distinguished by mood and state (see statusCode) and
                            completeness of the information.</p>
                    </text>
                </definition>
            </annotations>
            <behavior supplierStateAttributeName="statusCode">
                <figure>
                    <fixedImage>
                        <pixmap href="./Graphics/RIM_ActStatus.gif"/>
                    </fixedImage>
                </figure>
                <subState name="aborted" parentStateName="normal">
                    <annotations>
                        <definition>
                            <text>
                                <p>Active service object is exceptionally terminated.</p>
                            </text>
                        </definition>
                    </annotations>
                </subState>
                <subState name="active" parentStateName="normal">
                    <annotations>
                        <definition>
                            <text>
                                <p>Service object is active.</p>
                            </text>
                        </definition>
                    </annotations>
                </subState>
                <subState name="cancelled" parentStateName="normal">
                    <annotations>
                        <definition>
                            <text>
                                <p>Service object has been abandoned before activation.</p>
                            </text>
                        </definition>
                    </annotations>
                </subState>
                <subState name="completed" parentStateName="normal">
                    <annotations>
                        <definition>
                            <text>
                                <p>Service object is completed.</p>
                            </text>
                        </definition>
                    </annotations>
                </subState>
                <subState name="held" parentStateName="normal">
                    <annotations>
                        <definition>
                            <text>
                                <p>Service object is on hold so it can not be activated before it is
                                    released.</p>
                            </text>
                        </definition>
                    </annotations>
                </subState>
                <subState name="new" parentStateName="normal">
                    <annotations>
                        <definition>
                            <text>
                                <p>Service object is in preparation awaiting to be activated.</p>
                            </text>
                        </definition>
                    </annotations>
                </subState>
                <subState name="normal">
                    <annotations>
                        <definition>
                            <text>
                                <p>Encompasses the expected states of a service object, but excludes
                                    "nullified" and "obsolete" which represent unusual terminal
                                    states for the life-cycle.</p>
                            </text>
                        </definition>
                    </annotations>
                </subState>
                <subState name="null"/>
                <subState name="nullified">
                    <annotations>
                        <definition>
                            <text>
                                <p>Service object should not have been instantiated, and is
                                    therefore nullified.</p>
                            </text>
                        </definition>
                    </annotations>
                </subState>
                <subState name="obsolete">
                    <annotations>
                        <definition>
                            <text>
                                <p>Service object has been superceded by a new service object.</p>
                            </text>
                        </definition>
                    </annotations>
                </subState>
                <subState name="suspended" parentStateName="normal">
                    <annotations>
                        <definition>
                            <text>
                                <p>Active service object is temporarily suspended.</p>
                            </text>
                        </definition>
                    </annotations>
                </subState>
                <transition name="abort" startStateName="active" endStateName="aborted"/>
                <transition name="revise" startStateName="active" endStateName="active"/>
                <transition name="complete" startStateName="active" endStateName="completed"/>
                <transition name="suspend" startStateName="active" endStateName="suspended"/>
                <transition name="reactivate" startStateName="completed" endStateName="active"/>
                <transition name="revise" startStateName="completed" endStateName="completed"/>
                <transition name="cancel" startStateName="held" endStateName="cancelled"/>
                <transition name="revise" startStateName="held" endStateName="held"/>
                <transition name="release" startStateName="held" endStateName="new"/>
                <transition name="activate" startStateName="new" endStateName="active"/>
                <transition name="cancel" startStateName="new" endStateName="cancelled"/>
                <transition name="complete" startStateName="new" endStateName="completed"/>
                <transition name="hold" startStateName="new" endStateName="held"/>
                <transition name="revise" startStateName="new" endStateName="new"/>
                <transition name="nullify" startStateName="normal" endStateName="nullified"/>
                <transition name="obsolete" startStateName="normal" endStateName="obsolete"/>
                <transition name="activate" startStateName="null" endStateName="active"/>
                <transition name="complete" startStateName="null" endStateName="completed"/>
                <transition name="create" startStateName="null" endStateName="new"/>
                <transition name="jump" startStateName="null" endStateName="normal"/>
                <transition name="abort" startStateName="suspended" endStateName="aborted"/>
                <transition name="resume" startStateName="suspended" endStateName="active"/>
                <transition name="complete" startStateName="suspended" endStateName="completed"/>
                <transition name="revise" startStateName="suspended" endStateName="suspended"/>
            </behavior>
            <attribute name="classCode" sortKey="1" isStructural="true" minimumMultiplicity="1"
                maximumMultiplicity="1" isMandatory="true">
                <annotations>
                    <definition>
                        <text>
                            <p>A code specifying the major type of Act that this Act-instance
                                represents.</p>
                            <p>
                                <i>Constraints:</i> The classCode domain is a tightly controlled
                                vocabulary, not an external or user-defined vocabulary. </p>
                            <p>Every Act-instance must have a classCode. If the act class is not
                                further specified, the most general Act.classCode (ACT) is used.</p>
                            <p>The Act.classCode must be a generalization of the specific Act
                                concept (e.g., as expressed in Act.code), in other words, the Act
                                concepts conveyed in an Act must be specializations of the
                                Act.classCode. Especially, the classCode is not a "modifier" or the
                                Act.code that can alter the meaning of a class code. (See Act.code
                                for contrast.)</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="ActClass" codingStrength="CNE"/>
            </attribute>
            <attribute name="moodCode" sortKey="2" isStructural="true" minimumMultiplicity="1"
                maximumMultiplicity="1" isMandatory="true">
                <annotations>
                    <definition>
                        <text>
                            <p>A code distinguishing whether an Act is conceived of as a factual
                                statement or in some other manner as a command, possibility, goal,
                                etc.</p>
                            <p>
                                <i>Constraints:</i> An Act-instance must have one and only one
                                moodCode value.</p>
                            <p>The moodCode of a single Act-instance never changes. Mood is not
                                state.</p>
                            <p>To describe the progression of a business activity from defined to
                                planned to executed, etc. one must instantiate different
                                Act-instances in the different moods and link them using
                                ActRelationship of general type "sequel". (See
                                ActRelationship.typeCode.)</p>
                            <p>
                                <i>Discussion:</i> The Act.moodCode includes the following notions:
                                (1) event, i.e., factual description of an actions that occurred;
                                (2) definition of possible actions and action plans (the master file
                                layer); (3) intent, i.e., an action plan instantiated for a patient
                                as a care plan or order; (4) goal, i.e., an desired outcome attached
                                to patient problems and plans; and (5) criterion, i.e., a predicate
                                used to evaluate a logical expression.</p>
                            <p>The Act.moodCode modifies the meaning of the Act class in a
                                controlled way, just as in natural language, grammatical form of a
                                verb modify the meaning of a sentence in defined ways. For example,
                                if the mood is factual (event), then the entire act object
                                represents a known fact. If the mood expresses a plan (intent), the
                                entire act object represents the expectation of what should be done.
                                The mood does not change the meaning of individual act properties in
                                peculiar ways.</p>
                            <p>Since the mood code is a determining factor for the meaning of an
                                entire Act object, the mood must always be known. This means,
                                whenever an act object is instantiated, the mood attribute must be
                                assigned to a valid code, and the mood assignment cannot change
                                throughout the lifetime of an act object.</p>
                            <p>As the meaning of an act object is factored in the mood code, the
                                mood code affects the interpretation of the entire Act object and
                                with it every property (attributes and associations). Note that the
                                mood code affects the interpretation of the act object, and the
                                meaning of the act object in turn determines the meaning of the
                                attributes. However, the mood code does not arbitrarily change the
                                meaning of individual attributes.</p>
                            <p>
                                <i>Inert vs. descriptive properties of Acts:</i> Acts have two kinds
                                of act properties, inert and descriptive properties. Inert
                                properties are not affected by the mood, descriptive properties
                                follow the mood of the object. For example, there is an identifier
                                attribute Act.id, which gives a unique identification to an act
                                object. Being a unique identifier for the object is in no way
                                dependent on the mood of the act object. Therefore, the
                                "interpretation" of the Act.id attribute is inert with respect to
                                the act object's mood.</p>
                            <p>By contrast, most of the Act class' attributes are descriptive for
                                what the Act statement expresses. Descriptive properties of the Act
                                class give answer to the questions who, whom, where, with what, how
                                and when the action is done. The questions who, whom, with what, and
                                where are answered by Participations, while how and when are
                                answered by descriptive attributes and ActRelationships. The
                                interpretation of a descriptive attribute is aligned to the
                                interpretation of the entire act object, and controlled by the mood. </p>
                            <p>
                                <i>Examples:</i> To illustrate the effect of mood code, consider a
                                "blood glucose" observation:</p>
                            <p>The DEFINITION mood specifies the Act of "obtaining blood glucose".
                                Participations describe in general the characteristics of the people
                                who must be involved in the act, and the required objects, e.g.,
                                specimen, facility, equipment, etc. involved. The Observation.value
                                specifies the absolute domain (range) of the observation (e.g.,
                                15-500 mg/dl).</p>
                            <p>In INTENT mood the author of the intent expresses the intent that he
                                or someone else "should obtain blood glucose". The participations
                                are the people actually or supposedly involved in the intended act,
                                especially the author of the intent or any individual assignments
                                for group intents, and the objects actually or supposedly involved
                                in the act (e.g., specimen sent, equipment requirements, etc.). The
                                Observation.value is usually not specified, since the intent is to
                                measure blood glucose, not to measure blood glucose in a specific
                                range. (But compare with GOAL below).</p>
                            <p>In REQUEST mood, a kind of intent, the author requests to "please
                                obtain blood glucose". The Participations are the people actually
                                and supposedly involved in the act, especially the placer and the
                                designated filler, and the objects actually or supposedly involved
                                in the act (e.g., specimen sent, equipment requirements, etc.). The
                                Observation.value is usually not specified, since the order is not
                                to measure blood glucose in a specific range.</p>
                            <p>In EVENT mood, the author states that "blood glucose was obtained".
                                Participations are the people actually involved in the act, and the
                                objects actually involved (e.g., specimen, facilities, equipment).
                                The Observation.value is the value actually obtained (e.g., 80
                                mg/dL, or &lt;15 mg/dL).</p>
                            <p>In event-CRITERION mood, an author considers a certain class of
                                "obtaining blood glucose" possibly with a certain value (range) as
                                outcome. The Participations constrain the criterion, for instance,
                                to a particular patient. The Observation.value is the range in which
                                the criterion would hold (e.g. &gt; 180 mg/dL or 200-300 mg/dL).</p>
                            <p>In GOAL mood (a kind of criterion), the author states that "our goal
                                is to be able to obtain blood glucose with the given value (range)".
                                The Participations are similar to intents, especially the author of
                                the goal and the patient for whom the goal is made. The
                                Observation.value is the range which defined when the goal is met
                                (e.g. 80-120 mg/dl).</p>
                            <p>
                                <i>Rationale:</i> The notion of "mood" is borrowed from natural
                                language grammar, the mood of a verb (lat. modus verbi). </p>
                            <p>The notion of mood also resembles the various extensions of the logic
                                of facts in modal logic and logic with modalities, where the
                                moodCode specifies the modality (fact, possibility, intention, goal,
                                etc.) under which the Act-statement is judged as appropriate or
                                defective.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="ActMood" codingStrength="CNE"/>
            </attribute>
            <attribute name="id" sortKey="3" minimumMultiplicity="0" maximumMultiplicity="*"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A unique identifier for the Act.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SET">
                    <supplierBindingArgumentDatatype name="II"/>
                </type>
            </attribute>
            <attribute name="code" sortKey="4" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code specifying the particular kind of Act that the Act-instance
                                represents within its class.</p>
                            <p>
                                <i>Constraints:</i> The kind of Act (e.g. physical examination,
                                serum potassium, inpatient encounter, charge financial transaction,
                                etc.) is specified with a code from one of several, typically
                                external, coding systems. The coding system will depend on the class
                                of Act, such as LOINC for observations, etc.</p>
                            <p>Conceptually, the Act.code must be a specialization of the
                                Act.classCode. This is why the structure of ActClass domain should
                                be reflected in the superstructure of the ActCode domain and then
                                individual codes or externally referenced vocabularies subordinated
                                under these domains that reflect the ActClass structure.</p>
                            <p>Act.classCode and Act.code are not modifiers of each other but the
                                Act.code concept should really imply the Act.classCode concept. For
                                a negative example, it is not appropriate to use an Act.code
                                "potassium" together with and Act.classCode for "laboratory
                                observation" to somehow mean "potassium laboratory observation" and
                                then use the same Act.code for "potassium" together with
                                Act.classCode for "medication" to mean "substitution of potassium".
                                This mutually modifying use of Act.code and Act.classCode is not
                                permitted.</p>
                            <p>
                                <i>Discussion:</i> Act.code is not a required attribute of Act.
                                Rather than naming the kind of Act using an Act.code, one can
                                specify the Act using only the class code and other attributes and
                                properties of the Act. In general and more commonly, the kind of Act
                                is readily specified by an ActRelationship specifying that this Act
                                instantiates another Act in definition mood. Or, even without
                                reference to an act definition, the act may be readily described by
                                other attributes, ActRelationships and Participations. For example,
                                the kind of SubstanceAdministration may be readily described by
                                referring to the specific drug, as the Participation of an Entity
                                representing that drug.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CD"/>
                <supplierDomainSpecification domainName="ActCode" codingStrength="CWE"/>
            </attribute>
            <attribute name="negationInd" sortKey="5" isStructural="true" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>An indicator specifying that the Act statement is a negation of the
                                Act as described by the descriptive attributes.</p>
                            <p>
                                <i>Examples:</i> Used with an Observation event, it allows one to
                                say "patient has NO chest pain". With an Observation criterion it
                                negates the criterion analogously, e.g., "if patient has NO chest
                                pain for 3 days ...", or "if systolic blood pressure is <b>not</b>
                                within 90-100 mm Hg ..."</p>
                            <p>
                                <i>Discussion:</i> The negationInd works as a negative existence
                                quantifier. This is best explained on Acts in criterion mood, and
                                then translates into all other moods. In criterion mood without
                                negation, one usually only specifies a few critical attributes and
                                relationships (features) of an Act, i.e., only those that are needed
                                to test the criterion. The more features one specifies, the more
                                constrained (specific) is the criterion. For example, to test for
                                "systolic blood pressure of 90-100 mm Hg", one would use only the
                                descriptive attributes Act.code (for systolic blood pressure) and
                                Observation.value (for 90-100 mm Hg). If one would also specify an
                                effectiveTime, i.e., for "yesterday", the criterion would be more
                                constrained. If the negationInd is true for the above criterion,
                                then the meaning of the test is whether a systolic blood pressure of
                                90-100 mm Hg yesterday does <b>not exist</b> (independent of whether
                                any blood pressure was measured).</p>
                            <p>The negationInd negates the Act as described by the descriptive
                                properties (including Act.code, Act.effectiveTime,
                                Observation.value, Act.doseQty, etc.) and any of its components. The
                                inert properties such as Act.id, Act.moodCode,
                                Act.confidentialityCode, and particularly the Author-Participation
                                are <b>not</b> negated. These inert properties always have the same
                                meaning: i.e., the author remains to be the author of the negative
                                observation. Also, most ActRelationships (except for components) are
                                not included in the negation. </p>
                            <p>For example, a highly confidential order written by Dr. Jones, to
                                explicitly <b>not</b> give "succinyl choline" for the "reason"
                                (ActRelationship) of a history of malignant hyperthermia
                                (Observation) negates the descriptive properties "give succinyl
                                choline" (Act.code), but it is still positively an order and written
                                by Dr. Jones and for patient John Smith, and the reason for this
                                order is the patient's history of malignant hyperthermia. </p>
                            <p>However, additional detail in descriptive attributes will be part of
                                the negation which then limits the effectiveness of the negated
                                statement. For example, had the order not to give a substance
                                included a doseQuantity, it would mean that the substance should not
                                be given at that particular dose (but any other dose might still be
                                O.K.).</p>
                            <p>An act statement with negationInd is still a statement about the
                                specific fact described by the Act. For instance, a negated "finding
                                of wheezing on July 1" means that the author positively denies that
                                there was wheezing on July 1, and that he takes the same
                                responsibility for such statement and the same requirement to have
                                evidence for such statement than if he had not used negation.
                                Conversely, negation indicator does <b>not</b> just negate that the
                                fact was affirmed or that the statement had been made. This holds
                                for all moods in the same way, e.g., a negated order is an order
                                    <b>not</b> to do the described act, not just the lapidary
                                statement that there is no such order.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="BL"/>
            </attribute>
            <attribute name="derivationExpr" sortKey="6" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A character string containing a formal language expression that
                                specifies how the Act's attributes are (should be or have been)
                                derived from input parameters associated with derivation
                                relationships.</p>
                            <p>
                                <i>Discussion:</i> Derived observations can be defined through
                                association with other observations using ActRelationships of type
                                "derivation". For example, to define a derived observation for Mean
                                Corpuscular Hemoglobin (MCH) one will associate the MCH observation
                                with a Hemoglobin (HGB) observation and a Red Blood cell Count (RBC)
                                observation. And the derivation expression encodes the formula: MCH
                                = HGB / RBC.</p>
                            <p>The derivation expression is represented as a character string.</p>
                            <p>[Note: The syntax of that expression is yet to be fully specified.
                                There would be a single standard expression language rather than an
                                optional choice between many expression languages. The syntax would
                                be based on a de-facto standard for many object-oriented languages,
                                such as C++, Java, OCL etc. A concrete specification of this
                                expression language is being worked on now and drafts can be
                                expected within the year 2003.]</p>
                        </text>
                    </definition>
                </annotations>
                <type name="ST"/>
            </attribute>
            <attribute name="title" sortKey="7" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A word or phrase by which a specific Act may be known among people.</p>
                            <p>
                                <i>Example:</i> name of a research study (e.g. "Scandinavian
                                Simvastatin Study"), name of a court case (e.g. "Brown v. Board of
                                Education"), name of another kind of work project or operation. For
                                acts representing documents, this is the title of the document.</p>
                            <p>
                                <b>CONSTRAINT:</b> Previous to release 2.05 of the RIM, this
                                attribute bore the datatype <b>ST</b>. From release 2.05 onwards,
                                the datatype was extended to a <b>constrained</b> restriction of the
                                    <b>ED</b> datatype. The constraints to be imposed are identical
                                to those for the <b>ST</b> datatype, except that the mediaType shall
                                be "text/x-hl7-title+xml" or "text/plain". The intent is to allow
                                sufficient mark-up to convey the semantics of scientific phrases,
                                such as chemical compounds. This markup must not be used to convey
                                simple display preferences. The default mediaType should be
                                "text/plain".</p>
                            <p>
                                <i>Discussion:</i> This is not a formal identifier but rather a
                                human-recognizable common name. However it is similar to the id
                                attribute in that it refers to a specific Act rather than a 'kind'
                                of act. (For definition mood, the title refers to that specific
                                definition, rather than to a broad category that might be conveyed
                                with Act.code.)</p>
                            <p>
                                <i>Note:</i> This attribute was <b>not</b> in the normative content
                                balloted and approved for the first release of HL7's Reference
                                Information Model Standard. The attribute will be considered when
                                the RIM is prepared for balloting the second release. The attribute
                                is being used in current HL7 Version 3 designs.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="ED"/>
            </attribute>
            <attribute name="text" sortKey="8" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A textual or multimedia description (or reference to a description)
                                of the Act.</p>
                            <p>
                                <i>Examples:</i> For act definitions, the Act.text can contain
                                textbook-like information about that act. For act orders, the
                                description will contain particular instructions pertaining only to
                                that order. </p>
                            <p>
                                <i>Constraints:</i> No restriction on length or content is imposed
                                on the Act.text attribute. </p>
                            <p>The content of the description is not considered part of the
                                functional information communicated between computer systems. For
                                Acts that involve human readers and performers, however, computer
                                systems must show the Act.text field to a human user, who has
                                responsibility for the activity; or at least must indicate the
                                existence of the Act.text information and allow the user to see that
                                information.</p>
                            <p>Free text descriptions are used to help an individual interpret the
                                content and context of the act, but all information relevant for
                                automated functions must be communicated using the proper attributes
                                and associated objects.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="ED"/>
            </attribute>
            <attribute name="statusCode" sortKey="9" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code specifying the state of the Act.</p>
                            <p>
                                <b>Design Advisory: </b>This attribute was defined in the original
                                RIM as repeating, owing to the presence of nested states in the
                                state machines. In actual practice, however, there is never a need
                                to communicate more than a single status value. therefore,
                                committees are advised to <b>constrain this attribute to a maximum
                                    cardinality of 1</b> in all message designs. </p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="ActStatus" codingStrength="CNE"/>
            </attribute>
            <attribute name="effectiveTime" sortKey="10" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A time expression specifying the focal or operative time of the Act,
                                the primary time for which the Act holds, the time of interest from
                                the perspective of the Act's intention.</p>
                            <p>
                                <i>Examples:</i> For clinical Observations, the effectiveTime is the
                                time at which the observation holds (is effective) for the patient.</p>
                            <p>For contracts, the effectiveTime is the time for which the contract
                                is in effect.</p>
                            <p>For consents, the effectiveTime is the time for which the consent is
                                valid.</p>
                            <p>For substance administrations, the effective time is the time over
                                which the substance is to be administered, including the frequency
                                of administration (e.g. TID for 10 days)</p>
                            <p>For a surgical procedure (operation), the effectiveTime is the time
                                relevant for the patient, i.e., between incision and last suture. </p>
                            <p>For transportation acts, the effective time is the time the
                                transported payload is en route.</p>
                            <p>For patient encounters, this is the "administrative" time, i.e., the
                                encounter start and end date required to be chosen by business
                                rules, as opposed to the actual time the healthcare encounter
                                related work is performed.</p>
                            <p>
                                <i>Discussion:</i> The effectiveTime is also known as the "primary"
                                time (Arden Syntax) or the "biologically relevant time" (HL7 v2.x).
                                This attribute is distinguished from activityTime.</p>
                            <p>For observations, the time of the observation activity may be much
                                later than the time of the observed feature. For instance, in a
                                Blood Gas Analysis (BGA), a result will always come up several
                                minutes after the specimen was taken, meanwhile the patient's
                                physiological state may have changed significantly. </p>
                            <p>For essentially physical activities (surgical procedures,
                                transportations, etc.), the effective time is the time of interest
                                for the Act's intention, i.e., since the intention of a
                                transportation is to deliver a payload from location A to B, the
                                effectiveTime is the time this payload is underway from A to B.
                                However, the Act usually also includes accidental work which is
                                necessary to perform the intention of the Act, but is not relevant
                                for the Act's purpose. </p>
                            <p>For example, the time a driver needs to go to the pick-up location A
                                and then return from drop-off location B to some home base, is
                                included in the physical activity, but does not matter from the
                                perspective of the payload's transportation. Another example is: a
                                person's work hours (effectiveTime) may be from 8 AM to 5 PM, no
                                matter whether that person needs 10 minutes for the commute or 2
                                hours. The commute is necessary to be at work, but it is not
                                essential for the work hours.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="GTS"/>
            </attribute>
            <attribute name="activityTime" sortKey="11" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A time expression specifying when an Observation, Procedure, or other
                                Act occurs, or, depending on the mood, is supposed to occur,
                                scheduled to occur, etc. It tells you when the labor was done for an
                                Act. The activityTime includes the times of component actions (such
                                as preparation and clean-up)For Procedures and
                                SubstanceAdministrations, the activityTime can provide a needed
                                administrative / scheduling function by providing a more complete
                                time that needs to be anticipated for particular acts.</p>
                            <p>Discussion: The activityTime is more of administrative rather than
                                clinical use. The clinically relevant time is the effectiveTime.
                                When an observation of a prior symptom is made, the activityTime
                                describes the time the observation is made, as opposed to
                                effectiveTime which is the time the symptom occurred. Thus the
                                activityTime may be entirely different than the effectiveTime of the
                                same Act. But even apart from clinical use cases, designers should
                                first consider effectiveTime as the primary relevant time for an
                                Act.</p>
                            <p>The activityTime is a descriptive attribute, i.e., like
                                effectiveTime, it always describes the Act event as it does or would
                                occur, even when working with different moods. For example, when a
                                procedure is requested, the activityTime describes the requested
                                total time of the procedure. By contrast, the author
                                Participation.time is inert, i.e., author participation time on an
                                order specifies when the order was written and has nothing to do
                                with when the event might actually occur.</p>
                            <p>ActivityTime indicates when an Act occurs, not when an Act is
                                recorded. Many applications track the time an observation is
                                recorded rather than the precise time during which an observation is
                                made, in which case Participation.time (e.g. of the Author) should
                                be used. These recorded observations can take place during an
                                encounter, and the time of the encounter often provides enough
                                information so that activityTime isn't clinically relevant.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="GTS"/>
            </attribute>
            <attribute name="availabilityTime" sortKey="12" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The point in time at which information about Act-instance (regardless
                                of mood) first became available to a system reproducing this Act. </p>
                            <p>
                                <i>Examples:</i> An Act might record that a patient had a
                                right-ventricular myocardial infarction effective three hours ago
                                (see Act.effectiveTime), but we may only know about this unusual
                                condition a few minutes ago (Act.availabilityTime). Thus, any
                                interventions from three hours ago until a few minutes ago may have
                                assumed the more common left-ventricular infarction, which can
                                explain why these interventions (e.g., nitrate administration) may
                                not have been appropriate in light of the more recent knowledge.</p>
                            <p>
                                <i>Discussion:</i> The availabilityTime is a subjective secondary
                                piece of information added (or changed) by a system that reproduces
                                this Act, and is not attributed to the author of the act statement
                                (it would not be included in the material the author would attest to
                                with a signature). The system reproducing the Act is often not the
                                same as the system originating the Act, but a system that received
                                this Act from somewhere else, and, upon receipt of the Act, values
                                the availabilityTime to convey the time since the users of that
                                particular system could have known about this Act-instance.</p>
                            <p>When communicating availabilityTime to another system, the
                                availabilityTime of an Act A is attributed to the author of another
                                Act B, that refers to or includes A. For example, if a medical
                                record extract is compiled for reporting adverse events,
                                availabilityTimes are attributed to the author who compiles that
                                report.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="TS"/>
            </attribute>
            <attribute name="priorityCode" sortKey="13" minimumMultiplicity="0"
                maximumMultiplicity="*" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code or set of codes (e.g., for routine, emergency), specifying the
                                urgency under which the Act happened, can happen, is happening, is
                                intended to happen, or is requested/demanded to happen. </p>
                            <p>
                                <i>Discussion:</i> This attribute is used in orders to indicate the
                                ordered priority, and in event documentation it indicates the actual
                                priority used to perform the act. In definition mood it indicates
                                the available priorities.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SET">
                    <supplierBindingArgumentDatatype name="CE"/>
                </type>
                <supplierDomainSpecification domainName="ActPriority" codingStrength="CWE"/>
            </attribute>
            <attribute name="confidentialityCode" sortKey="14" minimumMultiplicity="0"
                maximumMultiplicity="*" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code that controls the disclosure of information about this Act,
                                regardless of mood.</p>
                            <p>
                                <i>Discussion:</i> It is important to note that the necessary
                                confidentiality of the medical record cannot be achieved solely
                                through confidentiality codes to mask individual record items from
                                certain types of users. There are two important problems with
                                per-item confidentiality: one is inference and the other is the
                                danger of holding back information that may be critical in a certain
                                care situation. Inference means that filtered sensitive information
                                can still be assumed given the other information that was not
                                filtered. The simplest form of inference is that even the existence
                                of a test order for an HIV Western Blot test or a T4/T8 lymphocyte
                                count is a strong indication for an existing HIV infection, even if
                                the results are not known. Very often, diagnoses can be inferred
                                from medication, such as Zidovudin for treatment of HIV infections.
                                The problem of hiding individual items becomes especially difficult
                                with current medications, since the continuing administration of the
                                medication must be assured.</p>
                            <p>To mitigate some of the inference-risk, aggregations of data should
                                assume the confidentiality level of the most confidential action in
                                the aggregation.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SET">
                    <supplierBindingArgumentDatatype name="CE"/>
                </type>
                <supplierDomainSpecification domainName="Confidentiality" codingStrength="CWE"/>
            </attribute>
            <attribute name="repeatNumber" sortKey="15" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>An interval of integer numbers stating the minimal and maximal number
                                of repetitions of the Act.</p>
                            <p>
                                <i>Examples:</i> An oral surgeon's advice to a patient after tooth
                                extraction might be: "replace the gauze every hour for 1 to 3 times
                                until bleeding has stopped completely." This translates to
                                repeatNumber with low boundary 1 and high boundary 3.</p>
                            <p>
                                <i>Discussion:</i> This attribute is a member of the workflow
                                control suite of attributes. </p>
                            <p>The number of repeats is additionally constrained by time. The act
                                will repeat at least the minimal number of times and at most, the
                                maximal number of times. Repetitions will also terminate when the
                                time exceeds the maximal Act.effectiveTime, whichever comes first.</p>
                            <p>
                                <i>Usage:</i> On an Act in Event mood, the repeatNumber is usally 1.
                                If greater than 1, the Act is representing a summary of several
                                event occurrences occurring over the time interval described by
                                effectiveTime</p>
                            <p>To distinguish occurrences of acts within a sequence of repetitions,
                                use ActRelationship.sequenceNumber</p>
                        </text>
                    </definition>
                </annotations>
                <type name="IVL">
                    <supplierBindingArgumentDatatype name="INT"/>
                </type>
            </attribute>
            <attribute name="interruptibleInd" sortKey="16" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>An indicator specifying whether Act is interruptible by asynchronous
                                events.</p>
                            <p>
                                <i>Discussion:</i> This attribute is part of the suite of workflow
                                control attributes. Act events that are currently active can be
                                interrupted in various ways. Interrupting events include: (1) when
                                an explicit abort request is received against the Act (2) when the
                                time allotted to this Act expires (timeout); (3) a "through
                                condition" ceases to hold true for this Act (see
                                ActRelationship.checkpointCode); (4) the Act is a component with the
                                joinCode "kill" and all other components in that same group have
                                terminated (see Act.joinCode); and (5) when a containing Act is
                                being interrupted. </p>
                            <p>If an Act receives an interrupt and the Act itself is interruptible,
                                but it has currently active component-Acts that are
                                non-interruptible, the Act will be interrupted when all of its
                                currently active non-interruptible component-acts have
                            terminated.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="BL"/>
            </attribute>
            <attribute name="levelCode" sortKey="17" isStructural="true" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Code specifying the level within a hierarchical Act composition
                                structure and the kind of contextual information attached to
                                composite Acts ("containers") and propagated to component Acts
                                within those containers. The levelCode signifies the position within
                                such a containment hierarchy and the applicable constraints.</p>
                            <p>
                                <i>Discussion:</i> Readers should be aware that <b>this attribute
                                    may be declared "obsolescent"</b> in the next normative release
                                of the HL7 RIM. An alternate representation of this concept using a
                                specified hierarchy of Act classCode values is being considered. If
                                the change is adopted, HL7's RIM maintenance procedures state that
                                the levelCode would be declared "obsolescent" in the next RIM
                                release, and then become "obsolete" in the release following that.
                                Users are advised to check with the latest HL7 internal definitions
                                of the RIM, before using this attribute.</p>
                            <p>The levelCode concepts have been defined to meet specific health
                                record transfer requirements. While these concepts are known to be
                                applicable to some other types of transactions, they are not
                                intended to be a complete closed list. Options exist for other sets
                                of orthogonal levels where required to meet a business purpose (e.g.
                                a multiple patient communication may be subdivided by a
                                super-ordinate level of subject areas).</p>
                            <p>
                                <i>Examples:</i> The "extract level" and the "folder level" must
                                contain data about a single individual, whereas the "multiple
                                subject level" may contain data about multiple individuals. While
                                "extract" can originate from multiple sources, a "folder" should
                                originate from a single source. The "composition" level usually has
                                a single author.</p>
                            <p>
                                <i>Constraints:</i> The constraints applicable to a particular level
                                may include differing requirements for participations (e.g. patient,
                                source organization, author or other signatory), relationships to or
                                inclusion of other Acts, documents or use of templates. The
                                constraints pertaining to a level may also specify the permissible
                                levels that may be contained as components of that level. Several
                                nested levels with the same levelCode may be permitted, prohibited
                                (or limited). Instances of the next subordinate level are usually
                                permitted within any level but some levels may be omitted from a
                                model and it may be permissible to skip several layers.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="ActContextLevel" codingStrength="CWE"/>
            </attribute>
            <attribute name="independentInd" sortKey="18" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>An indicator specifying whether the Act can be manipulated
                                independently of other Acts or whether manipulation of the Act can
                                only be through a super-ordinate composite Act that has this Act as
                                a component. By default the independentInd should be true.</p>
                            <p>
                                <i>Examples:</i> An Act definition is sometimes marked with
                                independentInd=false if the business rules would not allow this act
                                to be ordered without ordering the containing act group.</p>
                            <p>An order may have a component that cannot be aborted independently of
                                the other components.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="BL"/>
            </attribute>
            <attribute name="uncertaintyCode" sortKey="19" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code indicating whether the Act statement as a whole, with its
                                subordinate components has been asserted to be uncertain in any way. </p>
                            <p>
                                <i>Examples:</i> Patient might have had a cholecystectomy procedure
                                in the past (but isn't sure).</p>
                            <p>
                                <i>Constraints:</i> Uncertainty asserted using this attribute
                                applies to the combined meaning of the Act statement established by
                                all descriptive attributes (e.g., Act.code, Act.effectiveTime,
                                Observation.value, SubstanceAdministration.doseQuantity, etc.), and
                                the meanings of any components.</p>
                            <p>
                                <i>Discussion:</i>This is not intended for use to replace or compete
                                with uncertainty associated with Observation.value alone or other
                                individual attributes of the class. Such pointed indications of
                                uncertainty should be specified by applying the PPD, UVP or UVN data
                                type extensions to the specific attribute. Particularly if the
                                uncertainty is uncertainty of a quantitative measurement value, this
                                must still be represented by a PPD&lt;PQ&gt; in the value
                                    and<b>not</b>using the uncertaintyCode. Also, when differential
                                diagnoses are enumerated or weighed for probability, the
                                UVP&lt;CD&gt; or UVN&lt;CD&gt; must be used, not the
                                uncertaintyCode. The use of the uncertaintyCode is appropriate only
                                if the entirety of the Act and its dependent Acts is questioned.</p>
                            <p>Note that very vague uncertainty may be thought related to
                                negationInd, however, the two concepts are really independent. One
                                may be very uncertain about an event, but that does not mean that
                                one is certain about the negation of the event.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="ActUncertainty" codingStrength="CNE"/>
            </attribute>
            <attribute name="reasonCode" sortKey="20" minimumMultiplicity="0"
                maximumMultiplicity="*" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code specifying the motivation, cause, or rationale of an Act, when
                                such rationale is not reasonably represented as an ActRelationship
                                of type "has reason" linking to another Act.</p>
                            <p>
                                <i>Examples:</i> Example reasons that might qualify for being coded
                                in this field might be: "routine requirement", "infectious disease
                                reporting requirement", "on patient request", "required by law".</p>
                            <p>Discussion </p>
                            <p>Most reasons for acts can be clearly expressed by linking the new Act
                                to another prior Act using an ActRelationship of type "has reason".
                                This simply states that the prior Act is a reason for the new Act
                                (see ActRelationship). The prior act can then be a specific existing
                                act or a textual explanation. This works for most cases, and the
                                more specific the reason data is, the more should this reason
                                ActRelationship be used instead of the reasonCode. </p>
                            <p>The reasonCode remains as a place for common reasons that are not
                                related to a prior Act or any other condition expressed in Acts.
                                Indicators that something was required by law or was on the request
                                of a patient etc. may qualify. However, if that piece of
                                legislation, regulation, or the contract or the patient request can
                                be represented as an Act (and they usually can), the reasonCode
                                should not be used.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SET">
                    <supplierBindingArgumentDatatype name="CE"/>
                </type>
                <supplierDomainSpecification domainName="ActReason" codingStrength="CWE"/>
            </attribute>
            <attribute name="languageCode" sortKey="21" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The primary language in which this Act statement is specified,
                                particularly the language of the Act.text.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="HumanLanguage" codingStrength="CWE"/>
            </attribute>
            <specializationChild childClassName="Account" sortKey="1"/>
            <specializationChild childClassName="ControlAct" sortKey="2"/>
            <specializationChild childClassName="DeviceTask" sortKey="3"/>
            <specializationChild childClassName="FinancialContract" sortKey="4"/>
            <specializationChild childClassName="FinancialTransaction" sortKey="5"/>
            <specializationChild childClassName="InvoiceElement" sortKey="6"/>
            <specializationChild childClassName="Observation" sortKey="7"/>
            <specializationChild childClassName="PatientEncounter" sortKey="8"/>
            <specializationChild childClassName="Procedure" sortKey="9"/>
            <specializationChild childClassName="SubstanceAdministration" sortKey="10"/>
            <specializationChild childClassName="Supply" sortKey="11"/>
            <specializationChild childClassName="WorkingList" sortKey="12"/>
            <specializationChild childClassName="ActHeir" sortKey="13"/>
            <specializationChild childClassName="ContextStructure" sortKey="14"/>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="ActRelationship" isAbstract="false">
            <annotations>
                <definition>
                    <text>
                        <p>A directed association between a source Act and a target Act.
                            ActRelationship on the same source Act are called the "outbound" act
                            relationships of that Act. ActRelationships on the same target Act are
                            called the "inbound" relationships of that Act. The meaning and purpose
                            of an ActRelationship is specified in the ActRelationship.typeCode
                            attribute. </p>
                        <p>
                            <i>Examples:</i> 1) An electrolyte observation panel may have sodium,
                            potassium, pH, and bicarbonate observations as components. The composite
                            electrolyte panel would then have 4 outbound ActRelationships of type
                            "has component".</p>
                        <p>2) The electrolyte panel event has been performed in fulfillment of an
                            observation order. The electrolyte panel event has an outbound
                            ActRelationship of type "fulfills" with the order as target.</p>
                        <p>3) A Procedure "cholecystectomy" may be performed for the reason of an
                            Observation of "cholelithiasis". The procedure has an outbound
                            ActRelationship of type "has reason" to the cholelithiasis observation.</p>
                        <p>
                            <i>Discussion:</i> Consider every ActRelationship instance an arrow with
                            a point (headed to the target) and a butt (coming from the source). The
                            functions (sometimes called "roles") that source and target Acts play in
                            that association are defined for each ActRelationship type differently.
                            For instance in a composition relationship, the source is the composite
                            and the target is the component. In a reason-relationship the source is
                            any Act and the target is the reason or indication for the source-Act.</p>
                        <p>The relationships associated with an Act are considered properties of the
                            source act object. This means that the author of an Act-instance is also
                            considered the author of all of the act relationships that have this Act
                            as their source. There are no exceptions to this rule.</p>
                        <p>See ActRelationship.typeCode for more overview of the different kinds of
                            ActRelationships.</p>
                        <p>The ActRelationship class is used to construct action plans and to
                            represent clinical reasoning or judgments about action relationships.
                            Prior actions can be linked as the reasons for more recent actions.
                            Supporting evidence can be linked with current clinical hypotheses.
                            Problem lists and other networks of related judgments about clinical
                            events are represented by the ActRelationship link.</p>
                        <p>One of the most commonly used ActRelationship types is "has component" to
                            describe the composition and de-composition of Acts. The relationship
                            type allows specifying detail of Acts to varying degrees.</p>
                        <p>The composition relationship can group actions into "batteries," e.g.,
                            LYTES, CHEM12, or CBC, where multiple routine laboratory tests are
                            ordered as a group. Some groupings, such as CHEM12, appear more
                            arbitrary; others, such as blood pressure, seem to naturally consist of
                            systolic and diastolic pressure.</p>
                        <p>The composition relationships can be arranged in a sequence to form
                            temporal and conditional (non-temporal) action plans (e.g., care plan,
                            critical path, clinical trials protocol, drug treatment protocols).
                            There is a group of attributes in both Act and ActRelationship that we
                            refer to as the "workflow Control suite of attributes", and which allow
                            the detailed specification of executable action plans. These attributes
                            are:</p>
                        <p>ActRelationship.sequenceNumber arranges the components of an Act as a
                            sequence or as concurrent collections of components, expressing logical
                            branches as well as parallel tasks (tasks carried out at the same time).
                            The ActRelationship attributes splitCode and joinCode control how
                            branches are selected or executable in parallel.</p>
                        <p>Act.activityTime and ActRelationship.pauseQty allow one to explicitly
                            time an action plan. Act.repeatNumber allows specifying act to repeat
                            (loop).</p>
                        <p>The ActRelationship type has-precondition allows plan steps to be
                            conditional on the status or outcome of previous actions. The
                            ActRelationhsip.checkpointCode specifies when pre-conditions of acts are
                            tested during the flow of control.</p>
                        <p>The composition ActRelationship allows these constructs to be organized
                            in multiple layers of nesting to fully support workflow management. This
                            nesting and the workflow control attributes are designed in analogy to a
                            block-structured programming language with support for concurrency
                            (fork, join, interrupts), and without "goto" statements. It is important
                            to note that ALL plans are established through sequencing components
                            (steps) in a composite act (block) as can be depicted in
                            "Nassi-Schneiderman" diagrams (also known as "Chap Charts" or
                            "Structograms"), not by chain-linking acts as in a flowchart diagram. </p>
                        <p>With the composition relationship, the detail of Acts can be revealed to
                            different levels for different purposes, without the structure of the
                            Act hierarchy needing to be rearranged. This allows supporting multiple
                            viewpoints on the same business processes. For instance, a
                            billing-viewpoint of a laboratory test battery may be as a single
                            billable act. A clinician's view of the same laboratory test battery is
                            as a set of individual observations, where the ordering among the
                            observations is irrelevant. The laboratory's view of this act will be
                            more detailed, including action plan steps that are never reported to
                            the clinician (e.g., centrifugation, decantation, aliquoting, running
                            certain machines etc.). The laboratory's viewpoint warrants a thorough
                            specification of action plans (that can be automated). During this
                            specification, more and more nested sub-activities will be defined.
                            Still the Act is the same, with varying degrees of detail uncovered in
                            the de-composition relationship. </p>
                        <p>We described the nature of varying detail saying that Acts are "fractal",
                            ever more decomposable, just as the movements of a robotic arm can be
                            decomposed in many fine control steps.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="typeCode" sortKey="1" isStructural="true" minimumMultiplicity="1"
                maximumMultiplicity="1" isMandatory="true">
                <annotations>
                    <definition>
                        <text>
                            <p>A code specifying the meaning and purpose of every ActRelationship
                                instance. Each of its values implies specific constraints to what
                                kinds of Act objects can be related and in which way.</p>
                            <p>
                                <i>Discussion:</i> The types of act relationships fall under one of
                                5 categories:</p>
                            <p>1.) (De)-composition, with composite (source) and component (target).</p>
                            <p>2.) Sequel which includes follow-up, fulfillment, instantiation,
                                replacement, transformation, etc. that all have in common that
                                source and target are Acts of essentially the same kind but with
                                variances in mood and other attributes, and where the target exists
                                before the source and the source refers to the target that it links
                                back to.</p>
                            <p>3.) Pre-condition, trigger, reason, contraindication, with the
                                conditioned Act at the source and the condition or reason at the
                                target.</p>
                            <p>4.) Post-condition, outcome, goal and risk, with the Act at the
                                source having the outcome or goal at the target.</p>
                            <p>5.) A host of functional relationships including support, cause,
                                derivation, etc. generalized under the notion of "pertinence".</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="ActRelationshipType" codingStrength="CNE"/>
            </attribute>
            <attribute name="inversionInd" sortKey="2" isStructural="true" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>An indicator specifying that the ActRelationship.typeCode should be
                                interpreted as if the roles of the source and target Acts were
                                reversed. The inversion indicator is used when the meaning of
                                ActRelationship.typeCode must be reversed.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="BL"/>
            </attribute>
            <attribute name="contextControlCode" sortKey="3" isStructural="true"
                minimumMultiplicity="0" maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code that specifies how this ActRelationship contributes to the
                                context of the current Act, and whether it may be propagated to
                                descendent Acts whose association allows such propagation (see
                                ActRelationship.contextConductionInd).</p>
                            <p>
                                <i>Rationale:</i> In the interest of reducing duplication, humans
                                tend to rely on context when interpreting information. For example,
                                when reading a report taken from a folder containing a patient's
                                medical record, the reader will infer that the report deals with the
                                patient, even if there is no direct reference to the patient on the
                                form. However, other pieces of information such as the author of the
                                folder (the hospital that maintains it) may sometimes apply to the
                                contents of the folder (e.g. a report generated by a doctor at the
                                hospital) and other times not (e.g. a copy of a report from another
                                institution). Humans are quite good at making the necessary
                                inferences about what context should be propagated from an item to
                                something within that item. However, incorrect inferences can occur
                                (perhaps the report in the patient's record deals with a relative).
                                Furthermore, computers have substantially more difficulty making
                                such inferences, even though they can be essential for
                                decision-support systems.</p>
                            <p>
                                <i>Discussion:</i> This attribute allows the clear specification of
                                whether an association adds to the context associated with a
                                particular item (e.g. adding an additional author) or whether it
                                replaces (overrides) part of the context associated with a
                                particular item (e.g. identifying a sole author, independent of the
                                containing item). It also indicates whether the association applies
                                to only this act (non-propagating), or whether it may apply to
                                derived acts as well (propagating).</p>
                            <p>This attribute is closely linked with
                                ActRelationship.contextConductionInd which determines whether
                                associations that have been marked as propagating will actually be
                                conducted to a child Act. For example, an author participation might
                                be marked as propagating, but still not conducted to a hyperlink to
                                an external document.</p>
                            <p>If no value or default is specified for this attribute (i.e. it is
                                null), no inference can be made about context. Systems must make
                                their own assumptions on the basis of what data is being
                                represented. (For this reason, HL7 committees are encouraged to
                                specify a default or fixed value for this attribute as part of their
                                designs to ensure consistency of interpretation.)</p>
                            <p>
                                <i>Examples:</i> An observation event has a patient participation
                                marked "additive, propagating" (AP) and has component observation
                                events linked through act relationships that are marked propagating.
                                This means that the patient participation behaves as a patient
                                participation of those component observation events in addition to
                                the parent observation event.</p>
                            <p>A composite order is created containing a pharmacy order as well as
                                requests for several lab tests. The composite order has
                                participations for patient and author, and an act relationship to a
                                diagnosis, all marked as "additive, propagating". The "component"
                                association between the composite order and the pharmacy order is
                                marked as conductive (contextConductionInd is TRUE). The pharmacy
                                order has an author participation marked as "additive,
                                non-propagating" (AN), and a reason relationship to a diagnosis,
                                marked as "overriding, propagating" (OP). The order further has a
                                relationship to a dispense event, marked as conductive, and an
                                association to a drug protocol marked as non-conductive
                                (contextConductionInd is FALSE). The meaning would be as follows:</p>
                            <p>The pharmacy order is interpreted as having the patient from the
                                composite order, and having two authors (the one from the composite
                                order, and the one on the pharmacy order itself). The diagnosis for
                                the pharmacy order would <b>only</b> be the diagnosis specified on
                                the pharmacy order, not the one specified on the composite order.
                                The dispense event would carry the patient from the composite order
                                and the diagnosis from the pharmacy order, but no author. The drug
                                protocol would not be associated with a patient, diagnosis or
                                author.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="ContextControl" codingStrength="CNE"/>
            </attribute>
            <attribute name="contextConductionInd" sortKey="4" isStructural="true"
                minimumMultiplicity="0" maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>If true, associations in the parent act are conducted across the
                                ActRelationship to the child act.</p>
                            <p>
                                <i>Discussion:</i> Only associations that have been added to the
                                context of an Act and are marked "propagating" will be conducted.
                                (See contextControlCode on ActRelationship and Participation)</p>
                            <p>The identification of an Act as a parent or child (and therefore the
                                direction context will be conducted) is determined by how the
                                association is traversed when it is serialized. The first act to be
                                encountered is considered to be the parent. Context conducts across
                                the ActRelationship to the second (child) Act.</p>
                            <p>Refer to ActRelationship.contextControlCode for rationale and
                                examples.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="BL"/>
            </attribute>
            <attribute name="sequenceNumber" sortKey="5" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>An integer specifying the relative sequential or temporal ordering of
                                this relationship among other like-types relationships having the
                                same source Act.</p>
                            <p>
                                <i>Discussion:</i> This attribute is part of the workflow control
                                suite of attributes. An action plan is a composite Act with
                                component Acts. In a sequential plan, each component has a
                                sequenceNumber that specifies the ordering of the plan steps.
                                Multiple components with the same sequenceNumber make a branch.
                                Branches can be exclusive (case-switch) or can indicate parallel
                                processes indicated by the splitCode.</p>
                            <p>If value is null, the relative position of the target Act is
                                unspecified. (i.e. it may occur anywhere.)</p>
                            <p>Use the 'priorityNumber' attribute to indicate relative preference
                                instead of order of occurrence.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="INT"/>
            </attribute>
            <attribute name="priorityNumber" sortKey="6" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>An integer specifying the relative preference for considering this
                                relationship before other like-typed relationships having the same
                                source Act. Relationships with lower priorityNumber values are
                                considered before and above those with higher values.</p>
                            <p>
                                <i>Examples:</i> For multiple criteria specifies which criteria are
                                considered before others. For components with the same sequence
                                number, specifies which ones are considered before others. Among
                                alternatives or options that are being chosen by humans, the
                                priorityNumber specifies preference.</p>
                            <p>
                                <i>Discussion:</i> The ordering may be a total ordering in which all
                                priority numbers are unique or a partial ordering, which assigns the
                                same priority to more than one relationship.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="INT"/>
            </attribute>
            <attribute name="pauseQuantity" sortKey="7" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A quantity of time that should elapse between when an Act is ready
                                for execution and the actual beginning of the execution.</p>
                            <p>
                                <i>Discussion:</i> This attribute is part of the workflow control
                                suite of attributes. An action plan is a composite Act with
                                component Acts. In a sequential plan, each component has a
                                sequenceNumber that specifies the ordering of the plan steps. Before
                                each step is executed and has preconditions these conditions are
                                tested and if the test is positive, the Act has clearance for
                                execution. At that time the pauseQuantity timer is started and the
                                Act is executed after the pauseQuantity has elapsed.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="PQ"/>
            </attribute>
            <attribute name="checkpointCode" sortKey="8" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code specifying when in the course of an Act a precondition for the
                                Act is evaluated (e.g., before the Act starts for the first time,
                                before every repetition, after each repetition but not before the
                                first, or throughout the entire time of the Act).</p>
                            <p>
                                <i>Discussion:</i> This attribute is part of the workflow control
                                suite of attributes. An action plan is a composite Act with
                                component Acts. In a sequential plan, each component has a
                                sequenceNumber that specifies the ordering of the plan steps. Before
                                each step is executed, those with preconditions have their
                                conditions tested; where the test is positive, the Act has clearance
                                for execution. The repeatNumber may indicate that an Act may be
                                repeatedly executed. The checkpointCode is specifies when the
                                precondition is checked and is analogous to the various conditional
                                statements and loop constructs in programming languages "while-do"
                                vs. "do-while" or "repeat-until" vs. "loop-exit".</p>
                            <p>For all checkpointCodes, except "end", preconditions are being
                                checked at the time when the preceding step of the plan has
                                terminated and this step would be next in the sequence established
                                by the sequenceNumber attribute. </p>
                            <p>When the checkpointCode for a criterion of a repeatable Act is "end",
                                the criterion is tested only at the end of each repetition of that
                                Act. When the condition holds true, the next repetition is ready for
                                execution. </p>
                            <p>When the checkpointCode is "entry" the criterion is checked at the
                                beginning of each repetition (if any) whereas "beginning" means the
                                criterion is checked only once before the repetition "loop" starts.</p>
                            <p>The checkpointCode "through" is special in that it requires the
                                condition to hold throughout the execution of the Act, even
                                throughout a single execution. As soon as the condition turns false,
                                the Act should receive an interrupt event (see Act.interruptibleInd)
                                and will eventually terminate.</p>
                            <p>The checkpointCode "exit" is only used on a special plan step that
                                represents a loop exit step. This allows an action plan to exit due
                                to a condition tested inside the execution of this plan. Such exit
                                criteria are sequenced with the other plan components using the
                                ActRelationship.sequenceNumber.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="ActRelationshipCheckpoint"
                    codingStrength="CNE"/>
            </attribute>
            <attribute name="splitCode" sortKey="9" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code specifying how branches in an action plan are selected among
                                other branches.</p>
                            <p>
                                <i>Discussion:</i> This attribute is part of the workflow control
                                suite of attributes. An action plan is a composite Act with
                                component Acts. In a sequential plan, each component has a
                                sequenceNumber that specifies the ordering of the plan steps.
                                Branches exist when multiple components have the same
                                sequenceNumber. The splitCode specifies whether a branch is executed
                                exclusively (case-switch) or inclusively, i.e., in parallel with
                                other branches. </p>
                            <p>In addition to exclusive and inclusive split the splitCode specifies
                                how the pre-condition (also known as "guard conditions" on the
                                branch) are evaluated. A guard condition may be evaluated once when
                                the branching step is entered and if the conditions do not hold at
                                that time, the branch is abandoned. Conversely execution of a branch
                                may wait until the guard condition turns true.</p>
                            <p>In exclusive wait branches, the first branch whose guard conditions
                                turn true will be executed and all other branches abandoned. In
                                inclusive wait branches some branches may already be executed while
                                other branches still wait for their guard conditions to turn
                            true.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="ActRelationshipSplit" codingStrength="CNE"
                />
            </attribute>
            <attribute name="joinCode" sortKey="10" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code specifying how concurrent Acts are resynchronized in a
                                parallel branch construct.</p>
                            <p>
                                <i>Discussion:</i> This attribute is part of the workflow control
                                suite of attributes. An action plan is a composite Act with
                                component Acts. In a sequential plan, each component has a
                                sequenceNumber that specifies the ordering of the plan steps.
                                Branches exist when multiple components have the same
                                sequenceNumber. Branches are parallel if the splitCode specifies
                                that more than one branch can be executed at the same time. The
                                joinCode then specifies if and how the branches are resynchronized.</p>
                            <p>The principal re-synchronization actions are (1) the control flow
                                waits for a branch to terminate (wait-branch), (2) the branch that
                                is not yet terminated is aborted (kill-branch), (3) the branch is
                                not re-synchronized at all and continues in parallel (detached
                                branch).</p>
                            <p>A kill-branch is only executed if there is at least one active wait
                                (or exclusive wait) branch. If there is no other wait branch active,
                                a kill-branch is not started at all (rather than being aborted
                                shortly after it is started). Since a detached branch is unrelated
                                to all other branches, active detached branches do not protect a
                                kill-branch from being aborted.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="ActRelationshipJoin" codingStrength="CNE"/>
            </attribute>
            <attribute name="negationInd" sortKey="11" isStructural="true" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>An indicator that asserts that the meaning of the link is negated.</p>
                            <p>
                                <i>Examples:</i> If the relationship without negation specifies that
                                Act A has Act B as a component, then the negation indicator
                                specifies that Act A does <b>not</b> have Act B as a component. If B
                                is a reason for A, then negation means that B is <b>not</b> a reason
                                for A. If B is a pre-condition for A, then negation means that B is
                                    <b>not</b> a precondition for A.</p>
                            <p>
                                <i>Discussion:</i> As the examples show, the use of this attribute
                                is quite limited, notably contrast this with the Act.negationInd
                                that actually requires that the described Act not exist, not be
                                done, etc. whereas the ActRelationship.negationInd merely negates
                                this relationship between source and target act, but does not change
                                the meaning of each Act. This is mostly used for clarifying
                                statements. </p>
                            <p>Note also the difference between negation and the contrary. A
                                contraindication is the contrary of an indication (reason) but not
                                the negation of the reason. The fact that lower back pain is not a
                                reason to prescribe antibiotics doesn't mean that antibiotics are
                                contraindicated with lower back pain.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="BL"/>
            </attribute>
            <attribute name="conjunctionCode" sortKey="12" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code specifying the logical conjunction of the criteria among all
                                the condition-links of Acts (e.g., and, or, exclusive-or).</p>
                            <p>
                                <i>Constraints:</i> All AND criteria must be true. If OR and AND
                                criteria occur together, one criterion out of the OR-group must be
                                true and all AND criteria must be true also. If XOR criteria occur
                                together with OR and AND criteria, exactly one of the XOR criteria
                                must be true, and at least one of the OR criteria and all AND
                                criteria must be true. In other words, the sets of AND, OR, and XOR
                                criteria are in turn combined by a logical AND operator (all AND
                                criteria and at least one OR criterion and exactly one XOR
                                criterion). To overcome this ordering, Act criteria can be nested in
                                any way necessary.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="RelationshipConjunction"
                    codingStrength="CNE"/>
            </attribute>
            <attribute name="localVariableName" sortKey="13" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A character string name for the input parameter from which the source
                                Act of this ActRelationship derives some of its attributes. The
                                local variable name is bound in the scope of the Act.derivationExpr
                                with its value being an Act selected based on the input parameter
                                specification.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="ST"/>
            </attribute>
            <attribute name="seperatableInd" sortKey="14" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>This attribute indicates whether or not the source Act is intended to
                                be interpreted independently of the target Act. The indicator cannot
                                prevent an individual or application from separating the Acts, but
                                indicates the author's desire and willingness to attest to the
                                content of the source Act if separated from the target Act. Note
                                that the default for this attribute will typically be "TRUE". Also
                                note that this attribute is orthogonal and unrelated to the RIM's
                                context/inheritance mechanism. If the context of an Act is
                                propagated to nested Acts, it is assumed that those nested Acts are
                                not intended to be interpreted without the propagated context.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="BL"/>
            </attribute>
            <attribute name="subsetCode" sortKey="15" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Used to indicate that the target of the relationship will be a
                                filtered subset of the total related set of targets</p>
                            <p>Used when there is a need to limit the number of components to the
                                first, the last, the next, the total, the average or some other
                                filtered or calculated subset.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="ActRelationshipSubset" codingStrength="CNE"
                />
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="ControlAct" isAbstract="false">
            <supplierStructuralDomain mnemonic="CACT"/>
            <annotations>
                <definition>
                    <text>
                        <p>An act representing a change to the state of another class, a user event
                            (e.g. query), or a system event (e.g. time-based occurrences).</p>
                        <p>
                            <p>
                                <i>Examples: </i>
                            </p>
                            <ul>
                                <li>
                                    <p>Discharging a patient (Encounter from Active to
                                    Completed);</p>
                                </li>
                                <li>
                                    <p>Stopping a medication (SubstanceAdministration from Active to
                                        Aborted); </p>
                                </li>
                                <li>
                                    <p>Sending an end-of-day summary (time-based event).</p>
                                </li>
                            </ul>
                        </p>
                        <p>
                            <i>Discussion: </i>This class corresponds to the concept of 'Trigger
                            Event', and as such, must be present as the focus of every messaging
                            interaction (because of the 1..1 association between a trigger event and
                            an interaction.) However, control acts can also appear within a message
                            payload. For example, a set of control acts associated with a Lab Order
                            identifying the events that have occurred against that order (first
                            created, then revised, then suspended, then resumed, then
                        completed.)</p>
                    </text>
                </definition>
            </annotations>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="DeviceTask" isAbstract="false">
            <supplierStructuralDomain mnemonic="CONTREG"/>
            <annotations>
                <definition>
                    <text>
                        <p>An activity of an automated system.</p>
                        <p>
                            <i>Discussion:</i>Such activities are invoked either by an outside
                            command or are scheduled and executed spontaneously by the device (e.g.,
                            regular calibration or flushing). The command to execute the task has
                            moodCode &lt;= ORD; an executed task (including a task in progress)
                            has moodCode &lt;= EVN, an automatic task on the schedule has
                            moodCode &lt;= APT.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="parameterValue" sortKey="1" minimumMultiplicity="0"
                maximumMultiplicity="*" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The parameters of the task submitted to the device upon the issuance
                                of a command (or configuring the schedule of spontaneously executed
                                tasks).</p>
                            <p>
                                <i>Rationale:</i> Some parameters for tasks are uniquely defined by
                                a specific model of equipment. Most critical arguments of a task
                                (e.g., container to operate on, positioning, timing, etc.) are
                                specified in an HL7 standardized structure, and the parameter list
                                would not be used for those. The parameter list is used only for
                                those parameters that cannot be standardized because they are
                                uniquely defined for a specific model of equipment. NOTE: This means
                                that the semantics and interpretation of a parameterValue can
                                    <b>only</b> be made with an understanding of the specifications
                                or documentation for the specific device being addressed. This
                                information is not conveyed as part of the message.</p>
                            <p>
                                <i>Constraints:</i> Parameters are only specified here if they are
                                not included in a separate HL7 defined structure. The parameters are
                                a list of any data values interpreted by the device. The parameters
                                should be typed with an appropriate HL7 data type (e.g., codes for
                                nominal settings, such as flags, REAL and INT for numbers, TS for
                                points in time, PQ for dimensioned quantities, etc.). However,
                                besides this HL7 data typing, the functioning of the parameters is
                                opaque to the HL7 standardization.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="LIST">
                    <supplierBindingArgumentDatatype name="ANY"/>
                </type>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="DiagnosticImage" isAbstract="false">
            <supplierStructuralDomain mnemonic="DGIMG"/>
            <annotations>
                <definition>
                    <text>
                        <p>An observation whose immediate and primary outcome (post-condition) is
                            new data about a subject, in the form of visualized images.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="subjectOrientationCode" sortKey="1" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code specifying qualitatively the spatial relation between an
                                imaged object and the imaging film or detector.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="ImagingSubjectOrientation"
                    codingStrength="CWE"/>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="Diet" isAbstract="false">
            <supplierStructuralDomain mnemonic="DIET"/>
            <annotations>
                <definition>
                    <text>
                        <p>A supply act dealing specifically with the feeding or nourishment of a
                            subject.</p>
                        <p>
                            <i>Discussion:</i> The detail of the diet is given as a description of
                            the Material associated via Participation.typeCode="product". Medically
                            relevant diet types may be communicated in the Diet.code, however, the
                            detail of the food supplied and the various combinations of dishes
                            should be communicated as Material instances.</p>
                        <p>
                            <i>Examples:</i> Gluten free; Low sodium</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="energyQuantity" sortKey="1" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The supplied biologic energy (Calories) per day.</p>
                            <p>
                                <i>Discussion:</i> This physical quantity should be convertible to 1
                                kcal/d (or 1 kJ/d). Note, avoid the existing confusion between
                                "large Calorie" and a "small calorie." Nutrition labels on food
                                products list "large Calories." It is more appropriate to use the
                                small calorie, which is 1/1000 of a large Calorie. These are clearly
                                distinguished in the HL7 units of measure tables.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="PQ"/>
            </attribute>
            <attribute name="carbohydrateQuantity" sortKey="2" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The supplied amount of carbohydrates (g) per day.</p>
                            <p>
                                <i>Discussion:</i> For a diabetes diet one typically restricts the
                                amount of metabolized carbohydrates to a certain amount per day
                                (e.g., 240 g/d). This restriction can be communicated in the
                                carbohydrateQuantity.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="PQ"/>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="FinancialContract" isAbstract="false">
            <supplierStructuralDomain mnemonic="FCNTRCT"/>
            <annotations>
                <definition>
                    <text>
                        <p>A contract whose value is measured in monetary terms.</p>
                        <p>
                            <i>Examples:</i> Insurance; Purchase agreement</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="paymentTermsCode" sortKey="1" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Establishes the payment terms for a contractual agreement or
                                obligation.</p>
                            <p>
                                <i>Examples:</i> "net 30"; "on receipt of invoice"; "upon completion
                                of service"</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="PaymentTerms" codingStrength="CWE"/>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="FinancialTransaction" isAbstract="false">
            <supplierStructuralDomain mnemonic="XACT"/>
            <annotations>
                <definition>
                    <text>
                        <p>An Act representing the movement of a monetary amount between two
                            accounts.</p>
                        <p>
                            <i>Discussion:</i> Financial transactions always occur between two
                            accounts (debit and credit), but there may be circumstances where one or
                            both accounts are implied or inherited from the containing model.</p>
                        <p>In the "order" mood, this represents a request for a transaction to be
                            initiated.</p>
                        <p>In the "event" mood, this represents the posting of a transaction to an
                            account.</p>
                        <p>
                            <i>Examples:</i> Cost of a service; Charge for a service; Payment of an
                            invoice</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="amt" sortKey="1" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Indicates the monetary amount to be transferred from the debit to the
                                credit account.</p>
                            <p>
                                <i>Discussion:</i> If the denomination of the amt differs from the
                                denomination of the debit or credit account, then the associated
                                exchange rate should be specified.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="MO"/>
            </attribute>
            <attribute name="creditExchangeRateQuantity" sortKey="2" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A decimal number indicating the rate of exchange in effect between
                                the currency of the account being credited, and the currency of the
                                transaction net amount.</p>
                            <p>
                                <i>Examples:</i> For the purchase of services valued in Mexican
                                pesos using U.S. dollars paid from a Canadian dollar account, the
                                credit exchange ratio would be communicated as real number "r" such
                                that "y (USD) * r = x (CAD)".</p>
                            <p>
                                <i>Rationale:</i> This allows a transaction to be expressed in a
                                currency other than that of the credit and debit accounts. It also
                                allows the credit and debit accounts to be based in different
                                currencies.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="REAL"/>
            </attribute>
            <attribute name="debitExchangeRateQuantity" sortKey="3" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A decimal number indicating the rate of exchange in effect between
                                the currency of the account being debited, and the currency of the
                                transaction net amount.</p>
                            <p>
                                <i>Examples:</i> For the purchase of services valued in Mexican
                                pesos using U.S. dollars paid from a Canadian dollar account, the
                                debit exchange ratio would be communicated as real number "r" such
                                that "y (USD) * r = x (MXP)".</p>
                            <p>
                                <i>Rationale:</i> This allows a transaction to be expressed in a
                                currency other than that of the credit and debit accounts. It also
                                allows the credit and debit accounts to be based in different
                                currencies.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="REAL"/>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="InvoiceElement" isAbstract="false">
            <supplierStructuralDomain mnemonic="INVE"/>
            <annotations>
                <definition>
                    <text>
                        <p>An Act representing a statement and justification of an "amount owed".</p>
                        <p>
                            <i>Discussion:</i> This represents the 'justification' portion of an
                            invoice. It is frequently combined with a financial transaction
                            representing the amount requested to be paid, agreed to be paid, or
                            actually paid.</p>
                        <p>A recursive relationship can be used to break a single InvoiceElement
                            into constituent elements.</p>
                        <p>In definition mood, it represents "possible" justification for future
                            billing. In request mood, it is a request to determine the amount owed.
                            In event mood, this class represents the determination of a specific
                            amount owed by a particular Entity.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="modifierCode" sortKey="1" minimumMultiplicity="0"
                maximumMultiplicity="*" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Designates a modifier to the code attribute to provide additional
                                information about the invoice element.</p>
                            <p>
                                <i>Examples:</i> Isolation allowance; After-hours service</p>
                            <p>
                                <i>Rationale:</i> This is not pre-coordinated into the CD attribute
                                because the modifier code set may not be specifically designed for
                                use with the Act.code code set. This violates the constraint for
                                using the 'modifier' property that the modifier code set must be
                                defined as part of, or specifically for the base code set.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SET">
                    <supplierBindingArgumentDatatype name="CE"/>
                </type>
                <supplierDomainSpecification domainName="InvoiceElementModifier"
                    codingStrength="CWE"/>
            </attribute>
            <attribute name="unitQuantity" sortKey="2" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A description of the number of instances of a product or service that
                                is being billed or charged for.</p>
                            <p>
                                <i>Examples:</i> 4 hours, 4 mg, 4 boxes, and 15 each of a container
                                of 1000 each, etc.</p>
                            <p>
                                <i>Discussion:</i> Each InvoiceElement that is being charged or
                                billed is identified by a charge or bill code (InvoiceElement.code).
                                In some situations, this code is a pre-coordinated code set and
                                represents a container (e.g. UPC code for a container of 1000 pills
                                and another UPC code for a container of the same pills but in a
                                container of 100). The UPC code is used in invoicing, but ratios are
                                required to specify that only a portion of the container (e.g.
                                bottle) is being billed or charged. If the InvoiceElement does not
                                reference a container, then the denominator is not specified.</p>
                            <p>For example, 15 pills in a container size of 1000 pills. In this
                                case, the numerator can be expressed as "15 {pill}" or simply "15"
                                and the denominator can be expressed as "1000 {bottle}" or simply
                                "1000" (see discussion following for rationale of using descriptive
                                text for countable units).</p>
                            <p>
                                <i>Constraints:</i>
                            </p>
                            <p>The unit of measure is restricted to a measurable unit such as
                                liters, milligrams and hours. Non-measurable, but countable units
                                such as boxes, packages, visits, pills and containers must not be
                                specified using the unit component of the PQ data type, except as an
                                annotation, marked by {xxx}. Refer to Data Types Part II Unabridged
                                Specification, Appendix A :Unified Code for Units of Measure.</p>
                            <p>Specification of countable units can be handled with the following
                                techniques:</p>
                            <p>(1) specify the countable unit in the InvoiceElement.code. That is, a
                                specific InvoiceElement.code would indicate that the item referenced
                                by the act represents a box of 20 items. There would be a different
                                InvoiceElement.code for a box of 40 items, and so on.</p>
                            <p>For example, if the InvoiceElement.code represents a box of 20 items,
                                and the InvoiceElement.unitQuantity = 2 (no units), then this
                                represents 2 boxes of 20 items for a total of 40 items.</p>
                            <p>(2) If more detail is required (e.g. to describe the composition,
                                packaging, manufacturer of a product), then use a participation
                                (typeCode = "PRD"), and a combination of role and entity classes to
                                describe the details of the packaging.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="RTO">
                    <supplierBindingArgumentDatatype name="PQ"/>
                    <supplierBindingArgumentDatatype name="PQ"/>
                </type>
            </attribute>
            <attribute name="unitPriceAmt" sortKey="3" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The monetary cost per unit being accounted.</p>
                            <p>
                                <i>Constraints:</i> In constructing the ratio, the numerator must be
                                of data type MO, and the denominator must be a PQ, specified in the
                                same manner as the unitQuantity attribute.</p>
                            <p>
                                <i>Examples:</i> $0.20/mg; $250/day; $50</p>
                        </text>
                    </definition>
                </annotations>
                <type name="RTO">
                    <supplierBindingArgumentDatatype name="MO"/>
                    <supplierBindingArgumentDatatype name="PQ"/>
                </type>
            </attribute>
            <attribute name="netAmt" sortKey="4" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Identifies the total monetary amount for the invoice element,
                                including the sum of any component elements.</p>
                            <p>
                                <i>Discussion:</i> For leaf-level amounts, this will be the value of
                                the unitQuantity * unitPriceAmt [ * factorNumber] [* pointsNumber].
                                For grouping invoice elements, this will be the sum of the netAmt
                                attributes of all contained InvoiceElements.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="MO"/>
            </attribute>
            <attribute name="factorNumber" sortKey="5" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Represents a multiplier used in determining the overall cost of
                                services delivered and/or goods received.</p>
                            <p>
                                <i>Examples:</i> this could be 10 (Number of Treatments as Units) *
                                $3.00 (Cost per Unit) * 1.5 (Factor) = $45.00 (Amount).</p>
                            <p>
                                <i>Discussion:</i> This concept is frequently used in Europe to
                                adjust the charge between that used for the public system and that
                                used for private insurers.</p>
                            <p>The simplest formula for deriving gross amounts is: unitQuantity *
                                unitPriceAmount = netAmt.</p>
                            <p>The concept of a Factor allows for a discount or surcharge multiplier
                                to be applied to a monetary amount. For example, the formula, with a
                                factor would be: unitQuantity * unitPrice (Cost/Point) *
                                factorNumber = netAmt</p>
                            <p>See related note on Points. Formula, with Points and Factors becomes:
                                unitQuantity * unitPriceAmt * pointsNumber * factorNumber =
                            netAmt</p>
                        </text>
                    </definition>
                </annotations>
                <type name="REAL"/>
            </attribute>
            <attribute name="pointsNumber" sortKey="6" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>For charges whose quantity is expressed in 'points', this expresses
                                the weighting (based on difficulty, cost and/or resource
                                intensiveness) associated with the good or service delivered.</p>
                            <p>
                                <i>Examples:</i> This could be 5 (Number of Treatments as Units) * 3
                                (Number of Points per treatment as Points)* $20.00 (Cost per Point)
                                = $300.00 (Amount).</p>
                            <p>
                                <i>Discussion:</i> This is commonly used in systems where services
                                provided are assigned a relative 'cost or difficulty rating', and
                                then a fixed price is assigned to a 'point'. Adjustments to all
                                prices charged by an organization can then be handled by increasing
                                or decreasing the cost per point to reflect changes in inflation,
                                overhead, etc.</p>
                            <p>The simplest formula for deriving gross amounts is: unitQuantity *
                                unitPriceAmount = netAmt.</p>
                            <p>The concept of Points allows for assignment of point values for
                                services and/or goods, such that a dollar amount can be assigned to
                                each point. For example, the formula, with points would be:
                                unitQuantity * pointsNumber * unitPriceAmt (Cost/Point) = netAmt.</p>
                            <p>See related note on Factor. Formula, with Points and Factors becomes:
                                unitQuantity * unitPriceAmt * pointsNumber * factorNumber =
                            netAmt.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="REAL"/>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="ManagedParticipation" isAbstract="false">
            <annotations>
                <definition>
                    <text>
                        <p>A participation that will be operated on over time and thus whose state
                            and identity must be managed. </p>
                        <p>
                            <i>Examples:</i> An attending practitioner for an inpatient encounter
                            may change due to leave of absence and it is important to note when this
                            participation will be available.</p>
                        <p>
                            <i>Rationale:</i> ManagedParticipations are defined as a subclass of
                            Participations to make explicit that not all Participations are
                            stateful. In general, when the sub-activity realized by a Participation
                            is of closer interest and needs to be managed, one SHOULD instead model
                            that sub-activity as an Act component underneath the main Act.</p>
                        <p>However, in certain environments the view of what these activities really
                            are that the participants perform is not very well recognized and hence
                            modeling those as sub-acts is deemed confusing or burdensome.</p>
                        <p>Therefore, the ManagedParticipation extends Participation with an
                            identity-attribute and a state-attribute to support these exceptional
                            use cases. ManagedParticipations should be used with utmost caution so
                            as to avoid confusion with Acts and to avoid having to duplicate the
                            act-management infrastructure around participations.</p>
                    </text>
                </definition>
            </annotations>
            <behavior supplierStateAttributeName="statusCode">
                <figure>
                    <fixedImage>
                        <pixmap href="./Graphics/RIM_ManagedParticipationStatus.gif"/>
                    </fixedImage>
                </figure>
                <subState name="active" parentStateName="normal">
                    <annotations>
                        <definition>
                            <text>
                                <p>The state representing the fact that the Participation is in
                                    progress.</p>
                            </text>
                        </definition>
                    </annotations>
                </subState>
                <subState name="cancelled" parentStateName="normal">
                    <annotations>
                        <definition>
                            <text>
                                <p>The termination state resulting from cancellation of the
                                    Participation prior to activation</p>
                            </text>
                        </definition>
                    </annotations>
                </subState>
                <subState name="completed" parentStateName="normal">
                    <annotations>
                        <definition>
                            <text>
                                <p>The terminal state representing the successful completion of the
                                    Participation.</p>
                            </text>
                        </definition>
                    </annotations>
                </subState>
                <subState name="normal">
                    <annotations>
                        <definition>
                            <text>
                                <p>The "typical" state. Excludes "nullified", which represents the
                                    termination state of a participation instance that was created
                                    in error.</p>
                            </text>
                        </definition>
                    </annotations>
                </subState>
                <subState name="null"/>
                <subState name="nullified">
                    <annotations>
                        <definition>
                            <text>
                                <p>The state representing the termination of a Participation
                                    instance that was created in error.</p>
                            </text>
                        </definition>
                    </annotations>
                </subState>
                <subState name="pending" parentStateName="normal">
                    <annotations>
                        <definition>
                            <text>
                                <p>The state representing the fact that the Participation has not
                                    yet become active.</p>
                            </text>
                        </definition>
                    </annotations>
                </subState>
                <transition name="revise" startStateName="active" endStateName="active"/>
                <transition name="complete" startStateName="active" endStateName="completed"/>
                <transition name="reactivate" startStateName="completed" endStateName="active"/>
                <transition name="revise" startStateName="completed" endStateName="completed"/>
                <transition name="nullify" startStateName="normal" endStateName="nullified"/>
                <transition name="create" startStateName="null" endStateName="active"/>
                <transition name="create" startStateName="null" endStateName="completed"/>
                <transition name="create" startStateName="null" endStateName="pending"/>
                <transition name="activate" startStateName="pending" endStateName="active"/>
                <transition name="cancel" startStateName="pending" endStateName="cancelled"/>
                <transition name="revise" startStateName="pending" endStateName="pending"/>
            </behavior>
            <attribute name="id" sortKey="1" minimumMultiplicity="0" maximumMultiplicity="*"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A unique identifier used to refer to a specific instance of a
                                Participation that may have the same Act and the same Role. (See
                                ManagedParticipation.)</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SET">
                    <supplierBindingArgumentDatatype name="II"/>
                </type>
            </attribute>
            <attribute name="statusCode" sortKey="2" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code specifying whether the participation instance is pending,
                                active, complete, or cancelled. (See ManagedParticipation.)</p>
                            <p>
                                <b>Design Advisory: </b>This attribute was defined in the original
                                RIM as repeating, owing to the presence of nested states in the
                                state machines. In actual practice, however, there is never a need
                                to communicate more than a single status value. therefore,
                                committees are advised to <b>constrain this attribute to a maximum
                                    cardinality of 1</b> in all message designs. </p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="ManagedParticipationStatus"
                    codingStrength="CNE"/>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="Observation" isAbstract="false">
            <supplierStructuralDomain mnemonic="OBS"/>
            <annotations>
                <definition>
                    <text>
                        <p>An Act of recognizing and noting information about the subject, and whose
                            immediate and primary outcome (post-condition) is new data about a
                            subject. Observations often involve measurement or other elaborate
                            methods of investigation, but may also be simply assertive statements. </p>
                        <p>
                            <i>Discussion:</i> Structurally, many observations are name-value-pairs,
                            where the Observation.code (inherited from Act) is the name and the
                            Observation.value is the value of the property. Such a construct is also
                            known as a "variable" (a named feature that can assume a value); hence,
                            the Observation class is always used to hold generic name-value-pairs or
                            variables, even though the variable valuation may not be the result of
                            an elaborate observation method. It may be a simple answer to a question
                            or it may be an assertion or setting of a parameter.</p>
                        <p>As with all Act statements, Observation statements describe what was
                            done, and in the case of Observations, this includes a description of
                            what was actually observed ("results" or "answers"); and those "results"
                            or "answers" are part of the observation and not split off into other
                            objects. </p>
                        <p>An observation may consist of component observations each having their
                            own Observation.code and Observation.value. In this case, the composite
                            observation may not have an Observation.value for itself. For instance,
                            a white blood cell count consists of the sub-observations for the counts
                            of the various granulocytes, lymphocytes and other normal or abnormal
                            blood cells (e.g., blasts). The overall white blood cell count
                            Observation itself may therefore not have a value by itself (even though
                            it could have one, e.g., the sum total of white blood cells). Thus, as
                            long as an Act is essentially an Act of recognizing and noting
                            information about a subject, it is an Observation, regardless of whether
                            it has a simple value by itself or whether it has sub-observations.</p>
                        <p>Even though observations are professional acts (see Act) and as such are
                            intentional actions, this does not require that every possible outcome
                            of an observation be pondered in advance of it being actually made. For
                            instance, differential white blood cell counts (WBC) rarely show blasts,
                            but if they do, this is part of the WBC observation even though blasts
                            might not be predefined in the structure of a normal WBC.</p>
                        <p>Diagnoses, findings, symptoms, etc. are also Observations. The
                            Observation.code (or the reference to the Observation definition)
                            specifies the kind of diagnosis (e.g. "chief complaint" or "discharge
                            diagnosis") and the value specifies the diagnosis code or symptom
                        code.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="value" sortKey="1" minimumMultiplicity="0" maximumMultiplicity="*"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Information that is assigned or determined by the observation action. </p>
                            <p>
                                <i>Constraints:</i> The Observation.value, if not otherwise
                                constrained, can be of any data type.</p>
                            <p>The appropriate data type of the Observation.value varies with the
                                kind of Observation and can generally be described in Observation
                                definitions or in a simple relation that pairs Act.codes to value
                                data types.</p>
                            <p>The following guidelines govern the choice of the appropriate value
                                data type.</p>
                            <p>(1) Quantitative measurements use the data type Physical Quantity
                                (PQ) in general. A PQ is essentially a real number with a unit. This
                                is the general preference for all numeric values, subject to a few
                                exceptions listed below. </p>
                            <p>Numeric values <b>must not</b> be communicated as simply a character
                                string (ST). </p>
                            <p>(2) Titer (e.g., 1:64) and very few other ratios use the data type
                                Ratio (RTO). For titers, the ratio would be a ratio of two integer
                                numbers (e.g., 1:128). Other ratios may relate different
                                quantitative data types, such as a "price" specified in Physical
                                Quantity over Monetary Amount.</p>
                            <p>Sometimes by local conventions titers are reported as just the
                                denominator (e.g., 32 instead of 1/32). Such conventions are
                                confusing and <b>should</b> be converted into correct ratios in HL7
                                messages. </p>
                            <p>(3) Index values (a number without unit) uses the Real Number (REAL)
                                data type. When a quantity does not have a proper unit, one can just
                                send the number as a real number. Alternatively one can use a PQ
                                with a dimensionless unit (e.g., 1 or %). An integer number should
                                only be sent when the measurement is by definition an integer, which
                                is an extremely rare case and then is most likely an ordinal (see
                                below).</p>
                            <p>(4) Ranges (e.g., &lt;3; 12-20) must be expressed as Interval of
                                Physical Quantity (IVL&lt;PQ&gt;) or intervals of other
                                quantity data types.</p>
                            <p>Sometimes such intervals are used to report the uncertainty of
                                measurement value. For uncertainty there are dedicated data type
                                extensions available. </p>
                            <p>(5) Ordinals (e.g., +, ++, +++; or I, IIa, IIb, III, IV) use the
                                Coded Ordinal (CO) data type. </p>
                            <p>(6) Nominal results ("taxons", e.g., organism type). use any of the
                                coded data types (CD, CE) that specify at least a code and a coding
                                system, and optionally original text, translations to other coding
                                systems and sometimes qualifiers. </p>
                            <p>(7) Imaging results use the Encapsulated Data (ED) type. The
                                encapsulated data type allows one to send an image (e.g., chest
                                X-ray) or a movie (e.g., coronary angiography, cardiac echo) as
                                alternatively inline binary data or as a reference to an external
                                address where the data can be downloaded on demand.</p>
                            <p>(8) Waveforms can be sent using the Correlated Observation Sequences
                                templates that provide all the data in an HL7 framework. In addition
                                one can use the Encapsulated Data (ED) data type to send waveforms
                                in other than HL7 formats or to refer to waveform data for on-demand
                                download. </p>
                            <p>(9) The character string data type may exceptionally be used to
                                convey formalized expressions that do not fit in any of the existing
                                data types. However, the string data type <b>must not</b> be used if
                                the meaning can be represented by one of the existing data types. </p>
                            <p>(10) Timestamps <b>should not</b> be sent in Observations if there
                                are more appropriate places to send those, e.g., usually as
                                Act.effectiveTime of some act. (E.g., "specimen received in lab" is
                                in the effectiveTime of an Act describing the specimen transport to
                                the lab, not in an Observation.</p>
                            <p>(11) Sets of values of any data type, enumerated sets as well as
                                intervals, are often used for Observation criteria (event-criterion
                                mood) to specify "normal ranges" or "decision ranges" (for alerts)
                                etc.</p>
                            <p>(12) For sequences of observations (repeated measurements of the same
                                property during a relatively short time) a Sequence (LIST) data type
                                is used. Refer to the Correlated Observation Sequences specification
                                for more detail.</p>
                            <p>(13) Uncertainty of values is specified using the Probability and
                                Probability Distribution data type extensions (UVP, PPD). If a
                                statistical sample is reported with absolute frequencies of
                                categories a Bag collection (BAG) can be used efficiently.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="ANY"/>
            </attribute>
            <attribute name="interpretationCode" sortKey="2" minimumMultiplicity="0"
                maximumMultiplicity="*" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>One or more codes specifying a rough qualitative interpretation of
                                the observation, such as "normal", "abnormal", "below normal",
                                "change up", "resistant", "susceptible", etc.</p>
                            <p>
                                <i>Discussion:</i> These interpretation codes are sometimes called
                                "abnormal flags", however, the judgment of normalcy is just one of
                                the common rough interpretations, and is often not relevant. For
                                example, the susceptibility interpretations are not about
                                "normalcy", and for any observation of a pathologic condition, it
                                does not make sense to state the normalcy, since pathologic
                                conditions are never considered "normal."</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SET">
                    <supplierBindingArgumentDatatype name="CE"/>
                </type>
                <supplierDomainSpecification domainName="ObservationInterpretation"
                    codingStrength="CWE"/>
            </attribute>
            <attribute name="methodCode" sortKey="3" minimumMultiplicity="0" maximumMultiplicity="*"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code that provides additional detail about the means or technique
                                used to ascertain the observation.</p>
                            <p>
                                <i>Examples:</i> Blood pressure measurement method: arterial
                                puncture vs. sphygmomanometer (Riva-Rocci), sitting vs. supine
                                position, etc. </p>
                            <p>
                                <i>Constraints:</i> In all observations the method is already
                                partially specified by the Act.code. In this case, the methodCode
                                    <b>need not</b> be used at all. The methodCode <b>may</b> still
                                be used to identify this method more clearly in addition to what is
                                implied from the Act.code. However, an information consumer system
                                or process <b>should not</b> depend on this methodCode information
                                for method detail that is implied by the Act.code. </p>
                            <p>If the methodCode is used to express method detail that is also
                                implied by the Act.code, the methodCode <b>must not</b> be in
                                conflict with the implied method of the Act.code.</p>
                            <p>
                                <i>Discussion:</i> In all observations the method is already
                                partially specified by simply knowing the kind of observation
                                (observation definition, Act.code) and this implicit information
                                about the method does not need to be specified in
                                Observation.methodCode. For example, many LOINC codes are defined
                                for specific methods as long as the method makes a practical
                                difference in interpretation. Thus, using LOINC, the difference
                                between susceptibility studies using the "minimal inhibitory
                                concentration" (MIC) or the "agar diffusion method" (Kirby-Baur) are
                                specifically assigned different codes. The methodCode therefore is
                                only an additional qualifier to specify what may not be known
                                already from the Act.code.</p>
                            <p>Also, some variances in methods may be tied to the particular device
                                used. The methodCode should not be used to identify the specific
                                device or test-kit material used in the observation. Such
                                information about devices or test-kits should be associated with the
                                observation as "device" participations.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SET">
                    <supplierBindingArgumentDatatype name="CE"/>
                </type>
                <supplierDomainSpecification domainName="ObservationMethod" codingStrength="CWE"/>
            </attribute>
            <attribute name="targetSiteCode" sortKey="4" minimumMultiplicity="0"
                maximumMultiplicity="*" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code specifying detail about the anatomical site or system that is
                                the focus of the observation if this information is not already
                                implied by the observation definition or Act.code.</p>
                            <p>
                                <i>Constraints:</i> The targetSiteCode value, if specified, <b>must
                                    not</b> conflict with what is implied about the target site or
                                system from the observation definition and the Act.code.</p>
                            <p>
                                <i>Discussion:</i> Most observation target sites are implied by the
                                observation definition and Act.code, or Observation.value. For
                                example, "heart murmur" always has the heart as target. This
                                attribute is used only when the observation target site needs to be
                                refined, to distinguish right and left etc. </p>
                            <p>If the subject of the Observation is something other than a human
                                patient or animal, the attribute is used analogously to specify a
                                structural landmark of the thing where the act focuses. For example,
                                if the subject is a lake, the site could be inflow and outflow, etc.
                                If the subject is a lymphatic node, "hilus," "periphery," etc. would
                                still be valid target sites.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SET">
                    <supplierBindingArgumentDatatype name="CD"/>
                </type>
                <supplierDomainSpecification domainName="ActSite" codingStrength="CWE"/>
            </attribute>
            <specializationChild childClassName="DiagnosticImage" sortKey="1"/>
            <specializationChild childClassName="PublicHealthCase" sortKey="2"/>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="Participation" isAbstract="false">
            <annotations>
                <definition>
                    <text>
                        <p>An association between an Act and a Role with an Entity playing that
                            Role. Each Entity (in a Role) involved in an Act in a certain way is
                            linked to the act by one Participation-instance. The kind of involvement
                            in the Act is specified by the Participation.typeCode.</p>
                        <p>
                            <i>Examples:</i> 1) Performers of acts (surgeons, observers,
                            practitioners).</p>
                        <p>2) Subjects of acts, patient, devices</p>
                        <p>3) Locations</p>
                        <p>4) Author, co-signer, witness, informant</p>
                        <p>5) Addressee, information recipient</p>
                        <p>
                            <i>Rationale:</i> Participations represent performance while Roles
                            represent competence. Participations specify the actual performance of
                            an Entity in a certain Act, and thus a Participation is scoped by its
                            specific Act. Conversely, Roles specify the competence of an Entity
                            (i.e., how it may principally participate in what kinds of acts)
                            irrespective of any individual Act.</p>
                        <p>For example, the professional credentials of a person (Role) may be quite
                            different from what a person actually does (Participation). A common
                            example is interns and residents performing anesthesia or surgeries
                            under (more or less) supervision of attending specialists. </p>
                        <p>An Act can have multiple participations of the same type, which indicates
                            collaborative activities or group involvement. The notion of multiple
                            performing Participations partially overlaps with sub-activities (Act
                            components). Whenever multiple actors are involved in an act, each actor
                            performs a different task (with the extremely rare exception of such
                            symmetrical activities as two people pulling a rope from either end).
                            Thus, the presence of multiple actors could be equally well represented
                            as an act consisting of sub-acts where each act would have only one
                            performing actor </p>
                        <p>For example, a record of a surgical service may include the actors of
                            type: (a) consenter, (b) primary surgeon, and (c) anesthetist. These
                            three actors really perform different tasks, which can be represented as
                            three related acts: (a) the consent, (b) the surgery proper, and (c) the
                            anesthesia act in parallel to the surgery. If we used the sub-acts, the
                            consenter, surgeon and anesthetist could simply be of actor type
                            "performer." Thus the more sub-acts we use, the fewer different actor
                            types we need to distinguish; conversely, the fewer sub-acts we use, the
                            more distinct actor types we need.</p>
                        <p>As a rule of thumb, sub-tasks should be considered instead of multiple
                            actors when each sub-task requires special scheduling, or billing, or if
                            overall responsibilities for the sub-tasks are different. In most cases,
                            however, human resources are scheduled by teams (instead of
                            individuals), billing tends to lump many sub-tasks together into one
                            position, and overall responsibility often rests with one attending
                            physician, chief nurse, or head of department. This model allows both
                            the multi-actor and the multi-act approach to represent the business
                            reality, with a slight bias towards "lumping" minor sub-activities into
                            the overall act.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="typeCode" sortKey="1" isStructural="true" minimumMultiplicity="1"
                maximumMultiplicity="1" isMandatory="true">
                <annotations>
                    <definition>
                        <text>
                            <p>A code specifying the kind of Participation or involvement the Entity
                                playing the Role associated with the Participation has with regard
                                to the associated Act.</p>
                            <p>
                                <i>Constraints:</i> The Participant.typeCode contains only
                                categories that have crisp semantic relevance in the scope of HL7.
                                It is a coded attribute without exceptions and no alternative coding
                                systems allowed.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="ParticipationType" codingStrength="CNE"/>
            </attribute>
            <attribute name="functionCode" sortKey="2" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>An optional code specifying additional detail about the function that
                                the Participation has in the Act, if such detail is not implied by
                                the Participation.typeCode.</p>
                            <p>
                                <i>Examples:</i> First surgeon, second surgeon (or first assistant
                                surgeon, the one facing the primary surgeon), second assistant
                                (often standing next to the primary surgeon), potentially a third
                                assistant, scrub nurse, circulating nurse, nurse assistant,
                                anesthetist, attending anesthetist, anesthesia nurse, technician who
                                positions the patient, postoperative watch nurse, assistants,
                                midwives, students, etc.</p>
                            <p>
                                <i>Constraints:</i> This code, if specified at all, <b>must not</b>
                                be in conflict with the Participation.typeCode. Automated systems
                                    <b>should not</b> functionally depend on this code. </p>
                            <p>No HL7 standard specification may be written to technically depend on
                                the functionCode. If that is deemed necessary, such concepts should
                                be defined in the Participation.typeCode instead.</p>
                            <p>
                                <i>Discussion:</i> This code can accommodate the huge variety and
                                nuances of functions that participants may perform in the act. The
                                number and kinds of functions applicable depends on the special kind
                                of act. E.g., each operation and method may require a different
                                number of assistant surgeons or nurses.</p>
                            <p>Since participation functions refer to what people do in an Act,
                                these are really sub-activities that may all occur in parallel. If
                                any more detail needs to be said about these activities other than
                                just who does them, one should consider using component acts
                                instead.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CD"/>
                <supplierDomainSpecification domainName="ParticipationFunction" codingStrength="CWE"
                />
            </attribute>
            <attribute name="contextControlCode" sortKey="3" isStructural="true"
                minimumMultiplicity="0" maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code that specifies how this Participation contributes to the
                                context of the current Act, and whether it may be propagated to
                                descendent Acts whose association allows such propagation (see
                                ActRelationship.contextConductionInd).</p>
                            <p>
                                <i>Discussion: </i> Refer to ActRelationship.contextControlCode for
                                rationale, discussion and examples.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="ContextControl" codingStrength="CNE"/>
            </attribute>
            <attribute name="sequenceNumber" sortKey="4" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>An integer specifying the relative order of the Participation in
                                relation to other Participations of the same Act.</p>
                            <p>
                                <i>Rationale:</i> The sequencing might be undertaken for functional
                                reasons or to establish a priority between participations. One
                                example is the sequencing of covered party participations to
                                establish a coordination of benefits sequence in insurance
                            claims.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="INT"/>
            </attribute>
            <attribute name="negationInd" sortKey="5" isStructural="true" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>If true, indicates that the specified participation did not, is not
                                or should not occur (depending on mood).</p>
                            <p>
                                <i>Rationale:</i> This has two primary uses: (1) To indicate that a
                                particular Role did not/should not participate in an Act. (2) To
                                remove a participant from the context being propagated between Acts.</p>
                            <p>
                                <i>Discussion:</i> A participation with a negationInd set to true is
                                stronger than one with a negationInd of false. In other words, if
                                there is a conflict, the negated participation takes precedence.</p>
                            <p>
                                <i>Examples:</i> Dr. Smith did not participate; Patient Jones did
                                not sign the consent. </p>
                        </text>
                    </definition>
                </annotations>
                <type name="BL"/>
            </attribute>
            <attribute name="noteText" sortKey="6" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A textual or multimedia depiction of commentary related to the
                                participation. This note is attributed to this participant only.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="ED"/>
            </attribute>
            <attribute name="time" sortKey="7" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>An interval of time specifying the time during which the participant
                                is involved in the act through this Participation.</p>
                            <p>
                                <i>Rationale:</i> Participation time is needed when the
                                participant's involvement in the act spans only part of the Act's
                                time. Participation time is also used to indicate the time at which
                                certain very common sub-activities happen that are not worth
                                mentioning in full acts.</p>
                            <p>
                                <i>Examples:</i> 1) The time data was entered into the originating
                                system is the Participation.time of the "data entry" participation.</p>
                            <p>2) The end of the participation time of an author is the time
                                associated with the signature.</p>
                            <p>3) The Participation.time of a co-signing participation is also the
                                time of that co-signature.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="IVL">
                    <supplierBindingArgumentDatatype name="TS"/>
                </type>
            </attribute>
            <attribute name="modeCode" sortKey="8" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code specifying the modality by which the Entity playing the Role
                                is participating in the Act.</p>
                            <p>
                                <i>Examples:</i> Physically present, over the telephone, written
                                communication. </p>
                            <p>
                                <i>Rationale:</i> Particularly for author (originator) participants
                                this is used to specify whether the information represented by the
                                act was initially provided verbally, (hand-)written, or
                                electronically.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="ParticipationMode" codingStrength="CWE"/>
            </attribute>
            <attribute name="awarenessCode" sortKey="9" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code specifying the extent to which the Entity playing the
                                participating Role (usually as a target Participation) is aware of
                                the associated Act.</p>
                            <p>
                                <i>Examples:</i> For diagnostic observations, is the patient, family
                                member or other participant aware of the patient's terminal illness?</p>
                            <p>
                                <i>Discussion:</i> If the awareness, denial, unconsciousness, etc.
                                is the subject of medical considerations (e.g., part of the problem
                                list), one should use explicit observations in these matters as
                                well, and should not solely rely on this simple attribute in the
                                Participation.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="TargetAwareness" codingStrength="CWE"/>
            </attribute>
            <attribute name="signatureCode" sortKey="10" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code specifying whether and how the participant has attested his
                                participation through a signature and or whether such a signature is
                                needed.</p>
                            <p>
                                <i>Examples:</i> A surgical Procedure act object (representing a
                                procedure report) requires a signature of the performing and
                                responsible surgeon, and possibly other participants. (See also:
                                Participation.signatureText.)</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="ParticipationSignature"
                    codingStrength="CNE"/>
            </attribute>
            <attribute name="signatureText" sortKey="11" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A textual or multimedia depiction of the signature by which the
                                participant endorses his or her participation in the Act as
                                specified in the Participation.typeCode and that he or she agrees to
                                assume the associated accountability.</p>
                            <p>
                                <i>Examples:</i> 1) An "author" participant assumes accountability
                                for the truth of the Act statement to the best of his knowledge.</p>
                            <p>2) An information recipient only attests to the fact that he or she
                                has received the information.</p>
                            <p>
                                <i>Discussion:</i> The signature can be represented in many
                                different ways either inline or by reference according to the ED
                                data type. Typical cases are:</p>
                            <p>1) Paper-based signatures: the ED data type may refer to some
                                document or file that can be retrieved through an electronic
                                interface to a hardcopy archive.</p>
                            <p>2) Electronic signature: this attribute can represent virtually any
                                electronic signature scheme.</p>
                            <p>3) Digital signature: in particular, this attribute can represent
                                digital signatures, for example, by reference to a signature data
                                block that is constructed in accordance to a digital signature
                                standard, such as XML-DSIG, PKCS#7, PGP, etc.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="ED"/>
            </attribute>
            <attribute name="performInd" sortKey="12" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Indicates that the resource for this Participation must be reserved
                                before use (i.e. it is controlled by a schedule).</p>
                            <p>
                                <i>Rationale:</i> This attribute serves a very specific need in the
                                context of resource scheduling. It is not needed in the majority of
                                participation expressions. In most circumstances, it applies to the
                                participation of a particular location or piece of equipment whose
                                use is controlled by a scheduler.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="BL"/>
            </attribute>
            <attribute name="substitutionConditionCode" sortKey="13" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Indicates the conditions under which a participating item may be
                                substituted with a different one.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="SubstitutionCondition" codingStrength="CWE"
                />
            </attribute>
            <specializationChild childClassName="ManagedParticipation" sortKey="1"/>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="PatientEncounter" isAbstract="false">
            <supplierStructuralDomain mnemonic="ENC"/>
            <annotations>
                <definition>
                    <text>
                        <p>An interaction between a patient and care provider(s) for the purpose of
                            providing healthcare-related service(s). Healthcare services include
                            health assessment.</p>
                        <p>
                            <i>Examples:</i> outpatient visit to multiple departments, home health
                            support (including physical therapy), inpatient hospital stay, emergency
                            room visit, field visit (e.g., traffic accident), office visit,
                            occupational therapy, telephone call.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="admissionReferralSourceCode" sortKey="1" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The source of the referral for a patient encounter.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="EncounterReferralSource"
                    codingStrength="CWE"/>
            </attribute>
            <attribute name="lengthOfStayQuantity" sortKey="2" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Identifies the total quantity of time when the subject is expected to
                                be or was resident at a facility as part of an encounter.</p>
                            <p>
                                <i>Discussion:</i> The actual days quantity cannot be simply
                                calculated from the admission and discharge dates because of
                                possible leaves of absence.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="PQ"/>
            </attribute>
            <attribute name="dischargeDispositionCode" sortKey="3" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code depicting the disposition of the patient at the time of
                                discharge (e.g., discharged to home, expired, against medical
                                advice, etc.). While the encounter is still "active" (the encounter
                                doesn't have an end date yet) this attribute should be interpreted
                                as the expected discharge disposition. When the encounter is
                                "completed" this field contains the actual discharge
                            disposition.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="EncounterDischargeDisposition"
                    codingStrength="CWE"/>
            </attribute>
            <attribute name="preAdmitTestInd" sortKey="4" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>An indication that pre-admission tests are required for this patient
                                encounter.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="BL"/>
            </attribute>
            <attribute name="specialCourtesiesCode" sortKey="5" minimumMultiplicity="0"
                maximumMultiplicity="*" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code identifying special courtesies extended to the patient. For
                                example, no courtesies, extended courtesies, professional courtesy,
                                VIP courtesies.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SET">
                    <supplierBindingArgumentDatatype name="CE"/>
                </type>
                <supplierDomainSpecification domainName="EncounterSpecialCourtesy"
                    codingStrength="CWE"/>
            </attribute>
            <attribute name="specialArrangementCode" sortKey="6" minimumMultiplicity="0"
                maximumMultiplicity="*" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code indicating the type of special arrangements provided for a
                                patient encounter (e.g., wheelchair, stretcher, interpreter,
                                attendant, seeing eye dog). For encounters in intention moods, this
                                information can be used to identify special arrangements that will
                                need to be made for the incoming patient. This is not related to the
                                AccommodationEvent.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SET">
                    <supplierBindingArgumentDatatype name="CE"/>
                </type>
                <supplierDomainSpecification domainName="SpecialArrangement" codingStrength="CWE"/>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="Procedure" isAbstract="false">
            <supplierStructuralDomain mnemonic="PROC"/>
            <annotations>
                <definition>
                    <text>
                        <p>An Act whose immediate and primary outcome (post-condition) is the
                            alteration of the physical condition of the subject.</p>
                        <p>
                            <i>Examples:</i> Procedures may involve the disruption of some body
                            surface (e.g. an incision in a surgical procedure) conservative
                            procedures such as reduction of a luxated join, including physiotherapy
                            such as chiropractic treatment, massage, balneotherapy, acupuncture,
                            shiatsu, etc. Outside of clinical medicine, procedures may be such
                            things as alteration of environments (e.g. straightening rivers,
                            draining swamps, building dams) or the repair or change of machinery
                            etc.</p>
                        <p>
                            <i>Discussion:</i> Applied to clinical medicine, procedure is but one
                            among several types of clinical activities such as observation,
                            substance-administrations, and communicative interactions (e.g.
                            teaching, advice, psychotherapy, represented simply as Acts without
                            special attributes). Procedure does not subsume those other activities
                            nor is procedure subsumed by them. Notably Procedure does not comprise
                            all acts of whose intent is intervention or treatment. Whether the
                            bodily alteration is appreciated or intended as beneficial to the
                            subject is likewise irrelevant, what counts is that the act is
                            essentially an alteration of the physical condition of the subject.</p>
                        <p>The choice between representations for real activities is based on
                            whether the specific properties of procedure are applicable and whether
                            the activity or activity step's necessary post-condition is the physical
                            alteration. For example, taking an x-ray image may sometimes be called
                            "procedure", but it is not a Procedure in the RIM sense for an x-ray
                            image is not done to alter the physical condition of the body.</p>
                        <p>Many clinical activities combine Acts of Observation and Procedure nature
                            into one composite. For instance, interventional radiology (e.g.,
                            catheter directed thrombolysis) does both observing and treating, and
                            most surgical procedures include conscious and documented Observation
                            steps. These clinical activities therefore are best represented by
                            multiple component acts each of the appropriate type.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="methodCode" sortKey="1" minimumMultiplicity="0" maximumMultiplicity="*"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Identifies the means or technique used to perform the procedure.</p>
                            <p>
                                <i>Discussion:</i> For any Procedure there may be several different
                                methods to achieve by and large the same result, but may be
                                important to know when interpreting a report more thoroughly (e.g.,
                                cholecystectomy: open vs. laparoscopic). Method concepts can be
                                "pre-coordinated" in the Act definition. There are many possible
                                methods, which all depend heavily on the particular kind of
                                Procedure, so that defining a vocabulary domain of all methods is
                                difficult. However, a code system might be designed such that it
                                specifies a set of available methods for each defined Procedure
                                concept. Thus, a user ordering a Procedure could select one of
                                several variances of the act by means of the method code. Available
                                method variances may also be defined in a master service catalog for
                                each defined Procedure. In act definition records (Act.moodCode =
                                DEF) the methodCode attribute is a set of all available method codes
                                that a user may select while ordering, or expect while receiving
                                results.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SET">
                    <supplierBindingArgumentDatatype name="CE"/>
                </type>
                <supplierDomainSpecification domainName="ProcedureMethod" codingStrength="CWE"/>
            </attribute>
            <attribute name="approachSiteCode" sortKey="2" minimumMultiplicity="0"
                maximumMultiplicity="*" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The anatomical site or system through which the procedure reaches its
                                target (see targetSiteCode).</p>
                            <p>
                                <i>Examples:</i>
                            </p>
                            <p>Nephrectomy can have a trans-abdominal or a primarily retroperitoneal
                                approach</p>
                            <p>An arteria pulmonalis catheter targets a pulmonary artery but the
                                approach site is typically the vena carotis interna or the vena
                                subclavia, at the neck or the fossa subclavia respectively.</p>
                            <p>For non-invasive procedures, e.g., acupuncture, the approach site is
                                the punctured area of the skin.</p>
                            <p>
                                <i>Discussion:</i> If the subject of the Act is something other than
                                a human patient or animal, the attribute is used analogously to
                                specify a structural landmark of the thing where the act focuses.</p>
                            <p>Some approach sites can also be "pre-coordinated" in the Act
                                definition, so that there is never an option to select different
                                body sites. The same information structure can handle both the
                                pre-coordinated and the post-coordinated approach.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SET">
                    <supplierBindingArgumentDatatype name="CD"/>
                </type>
                <supplierDomainSpecification domainName="ActSite" codingStrength="CWE"/>
            </attribute>
            <attribute name="targetSiteCode" sortKey="3" minimumMultiplicity="0"
                maximumMultiplicity="*" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The anatomical site or system that is the focus of the procedure.</p>
                            <p>
                                <i>Examples:</i>
                            </p>
                            <p>A Nephrectomy's target site is the right or left kidney</p>
                            <p>An arteria pulmonalis catheter targets a pulmonary artery.</p>
                            <p>For non-invasive procedures, e.g., acupuncture, the target site is
                                the organ/system that is sought to be influenced (e.g., "the
                                liver").</p>
                            <p>
                                <i>Discussion:</i> If the subject of the Act is something other than
                                a human patient or animal, the attribute is used analogously to
                                specify a structural landmark of the thing where the act focuses.</p>
                            <p>Some target sites can also be "pre-coordinated" in the Act
                                definition, so that there is never an option to select different
                                body sites. The same information structure can handle both the
                                pre-coordinated and the post-coordinated approach.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SET">
                    <supplierBindingArgumentDatatype name="CD"/>
                </type>
                <supplierDomainSpecification domainName="ActSite" codingStrength="CWE"/>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="PublicHealthCase" isAbstract="false">
            <supplierStructuralDomain mnemonic="CASE"/>
            <annotations>
                <definition>
                    <text>
                        <p>A public health case is an Observation representing a condition or event
                            that has a specific significance for public health. Typically it
                            involves an instance or instances of a reportable infectious disease or
                            other condition. The public health case can include a health-related
                            event concerning a single individual or it may refer to multiple
                            health-related events that are occurrences of the same disease or
                            condition of interest to public health. An outbreak involving multiple
                            individuals may be considered as a type of public health case. A public
                            health case definition (Act.moodCode = "definition") includes the
                            description of the clinical, laboratory, and epidemiologic indicators
                            associated with a disease or condition of interest to public health.
                            There are case definitions for conditions that are reportable, as well
                            as for those that are not. There are also case definitions for
                            outbreaks. A public health case definition is a construct used by public
                            health for the purpose of counting cases, and should not be used as
                            clinical indications for treatment. Examples include AIDS, toxic-shock
                            syndrome, and salmonellosis and their associated indicators that are
                            used to define a case.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="detectionMethodCode" sortKey="1" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Code for the method by which the public health department was made
                                aware of the case. Includes provider report, patient self-referral,
                                laboratory report, case or outbreak investigation, contact
                                investigation, active surveillance, routine physical, prenatal
                                testing, perinatal testing, prison entry screening, occupational
                                disease surveillance, medical record review, etc.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="CaseDetectionMethod" codingStrength="CWE"/>
            </attribute>
            <attribute name="transmissionModeCode" sortKey="2" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Code for the mechanism by which disease was acquired by the living
                                subject involved in the public health case. Includes sexually
                                transmitted, airborne, bloodborne, vectorborne, foodborne, zoonotic,
                                nosocomial, mechanical, dermal, congenital, environmental exposure,
                                indeterminate.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="CaseTransmissionMode" codingStrength="CWE"
                />
            </attribute>
            <attribute name="diseaseImportedCode" sortKey="3" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Code that indicates whether the disease was likely acquired outside
                                the jurisdiction of observation, and if so, the nature of the
                                inter-jurisdictional relationship. Possible values include not
                                imported, imported from another country, imported from another
                                state, imported from another jurisdiction, and insufficient
                                information to determine.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="CaseDiseaseImported" codingStrength="CWE"/>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="SubstanceAdministration" isAbstract="false">
            <supplierStructuralDomain mnemonic="SBADM"/>
            <annotations>
                <definition>
                    <text>
                        <p>The act of introducing or otherwise applying a substance to the subject.</p>
                        <p>
                            <i>Discussion:</i> The effect of the substance is typically established
                            on a biochemical basis, however, that is not a requirement. For example,
                            radiotherapy can largely be described in the same way, especially if it
                            is a systemic therapy such as radio-iodine. This class also includes the
                            application of chemical treatments to an area.</p>
                        <p>
                            <i>Examples:</i> Chemotherapy protocol; Drug prescription; Vaccination
                            record</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="routeCode" sortKey="1" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The method of introducing the therapeutic material into or onto the
                                subject.</p>
                            <p>
                                <i>Discussion:</i> Route, site of administration
                                (administrationSiteCode) and the device used in administration are
                                closely related. All three (if present) must be closely coordinated
                                and in agreement. In some cases, the coding system used to specify
                                one may pre-coordinate one or more of the others.</p>
                            <p>When the medication is delivered to an environmental site, or a
                                location, the route code indicates a site on its "body".</p>
                            <p>
                                <i>Examples:</i> per os (PO), sublingual (SL), rectal (PR), per
                                inhalationem (IH), ophtalmic (OP), nasal (NS), otic (OT), vaginal
                                (VG), intra-dermal (ID), subcutaneous (SC), intra-venous (IV), and
                                intra-cardial (IC)</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="RouteOfAdministration" codingStrength="CWE"
                />
            </attribute>
            <attribute name="approachSiteCode" sortKey="2" minimumMultiplicity="0"
                maximumMultiplicity="*" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The detailed anatomical site where the medication enters or is
                                applied to the subject.</p>
                            <p>
                                <i>Discussion:</i> This attribute is only needed if the routeCode
                                requires further specification. For example, if the routeCode is "by
                                mouth", no further specification of approach site is needed. If,
                                however, routeCode is intravenous or intra-muscular, the precise
                                site may be specified in this attribute (e.g., right forearm or left
                                deltoid muscle respectively).</p>
                            <p>Route, site of administration (approachSiteCode) and the device used
                                in administration are closely related. All three (if present) must
                                be closely coordinated and in agreement. In some cases, the coding
                                system used to specify one may pre-coordinate one or more of the
                                others.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SET">
                    <supplierBindingArgumentDatatype name="CD"/>
                </type>
                <supplierDomainSpecification domainName="ActSite" codingStrength="CWE"/>
            </attribute>
            <attribute name="doseQuantity" sortKey="3" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The amount of the therapeutic agent or other substance given at one
                                administration event.</p>
                            <p>
                                <i>Discussion:</i> The dose may be specified either as a physical
                                quantity of active ingredient (e.g. 200 mg) or as the count of
                                administration-units (e.g., tablets, capsules, "eaches"). Which
                                approach is chosen depends upon the player of the 'consumable'
                                participation (which identifies the drug being administered). If the
                                consumable has a non-countable dosage form (e.g. measured in
                                milligram or litre) then the dose must be expressed in those units.
                                If the consumable has a countable dosage form (tablets, capsules,
                                "eaches"), then the dose must be expressed as a dimensionless count
                                (i.e., with no other unit of measure specified).</p>
                            <p>The unit of measure is restricted to a measurable unit such as
                                milliliters and milligrams. Non-measurable, but countable units such
                                as tablets and capsules must not be specified using the unit
                                component of the PQ data type, except as an annotation, marked by
                                {xxx}. Refer to Data Types Part II Unabridged Specification,
                                Appendix A :Unified Code for Units of Measure.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="IVL">
                    <supplierBindingArgumentDatatype name="PQ"/>
                </type>
            </attribute>
            <attribute name="rateQuantity" sortKey="4" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Identifies the speed with which the substance is introduced into the
                                subject. Expressed as a physical (extensive) quantity over elapsed
                                time (e.g., examples are 100 mL/h, 1 g/d, 40 mmol/h, etc.)</p>
                            <p>
                                <i>Discussion:</i> This is appropriate for continuously divisible
                                dose forms (e.g., liquids, gases). If specified as an interval, the
                                rate should be anywhere in the specified range. This attribute is
                                specified as a extensive physical quantity over elapsed time, i.e.,
                                a quantity that could be used for the doseQuantity divided by a
                                duration quantity.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="IVL">
                    <supplierBindingArgumentDatatype name="PQ"/>
                </type>
            </attribute>
            <attribute name="doseCheckQuantity" sortKey="5" minimumMultiplicity="0"
                maximumMultiplicity="*" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>This attribute identifies the expected quantity to be consumed over a
                                period of time. It is used as a verification check on the values
                                specified for other values.</p>
                            <p>
                                <i>Discussion:</i> This attribute should not generally be used; it
                                is only provided for a special purpose. In some countries,
                                especially Japan, there is a regulatory requirement to note the
                                total daily dose on the prescription and associated documentation.
                                The purpose of this requirement obviously is to encourage and
                                facilitate reviewing the total dose prescribed to avoid over- (or
                                under-) dosage.</p>
                            <p>
                                <i>Examples:</i>
                            </p>
                            <p>With Erythromycin 250 mg 1 tablet 3 times a day one can calculate the
                                total daily dose as "doseCheckQuantity = doseQuantity (1) *
                                Ingredient.quantity (250 mg) * effectiveTime (3 /d) = 750 mg/1d."</p>
                            <p>For an intravenous example, this term would be "doseCheckQuantity =
                                doseQuantity (100 ml) * Ingredient.quantity (5mg/L) / rateQuantity
                                (1 h) = 0.5 mg/h" which can be calculated on a daily basis as
                                "doseCheckQuantity = 0.5 mg/h * 24 h/d = 12 mg/d."</p>
                            <p>
                                <i>Rationale:</i> Rather than defining a "total daily dose"
                                attribute as HL7 v2.3 did, we define this general purpose
                                doseCheckQuantity attribute of the Ratio (RTO) data type. </p>
                            <p>
                                <i>Constraints:</i> invariant(SubstanceAdministration med, RTO max)
                                where med.doseCheckQuantity.contains(max)
                                {max.numerator.compares(med.doseQuantity);
                                max.denominator.compares(1 s);} Numerator must be in units
                                comparable to doseQuantity and denominator must be a measurement of
                                time.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SET">
                    <supplierBindingArgumentDatatype name="RTO"/>
                </type>
            </attribute>
            <attribute name="maxDoseQuantity" sortKey="6" minimumMultiplicity="0"
                maximumMultiplicity="*" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Identifies the maximum total quantity of a therapeutic substance that
                                may be administered to a subject over the period of time.</p>
                            <p>
                                <i>Discussion:</i> This attribute is particularly useful where the
                                allowed dosage is specified as a range or the timing is variable or
                                PRN (as needed). It provides an overall limit on the quantity that
                                may be administered in a period of time. Multiple occurrences of
                                maxDoseQuantity may be used to indicate different limits over
                                different time periods.</p>
                            <p>
                                <i>Examples:</i> 500 mg/day; 1200mg/week.</p>
                            <p>
                                <i>Constraints:</i> invariant(SubstanceAdministration med, RTO max)
                                where med.maxDoseQuantity.contains(max)
                                {max.numerator.compares(med.doseQuantity);
                                max.denominator.compares(1 s);} Numerator must be in units
                                comparable to doseQuantity and denominator must be a measurement of
                                time.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SET">
                    <supplierBindingArgumentDatatype name="RTO"/>
                </type>
            </attribute>
            <attribute name="administrationUnitCode" sortKey="7" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code for the administered thing taken from a larger whole. Used if
                                the consumable material is specified as a larger whole but the
                                doseQuantity relates to a specific portion of it rather than the
                                entire consumable material.</p>
                            <p>
                                <i>Example: </i>The ordering system only has a code for "Budesonide
                                Metered Dose Inhaler" but the dose is to be measured in "number of
                                actuations".</p>
                            <p>
                                <i>Rationale: </i>In the given example, without an
                                administrationUnitCode the doseQty = 1 would mean that the entire
                                inhaler bottle is to be emptied upon a single administration event.
                                The administrationUnitCode signifying "actuation" (or "puff")
                                specifies that the doseQty relates to this fraction of the
                                medication rather than to the whole.</p>
                            <p>
                                <b>Constraints:</b>
                            </p>
                            <p>(1) This attribute should be used if and only if the material
                                specified as the player of the Role attaching to the consumable
                                participation is not in itself the finished dose form to be
                                administered but a larger whole, pack, etc.</p>
                            <p>(2) IF the material so specified is the proper administered dose
                                form, such as a tablet, capsule, etc. THEN this attribute should be
                                valued NULL (not applicable).</p>
                            <p>(3) IF the material so specified is an amorphous substance (liquid,
                                gas, powder, etc.) to be measured as a volume, mass, etc., THEN this
                                attribute should remain NULL (not applicable).</p>
                            <p>(4) IF the material so specified is a container, and the content is
                                to be measured as a volume, mass, etc., THEN this attribute should
                                be specified as "measured portion".</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="AdministrableDrugForm" codingStrength="CWE"
                />
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="Supply" isAbstract="false">
            <supplierStructuralDomain mnemonic="SPLY"/>
            <annotations>
                <definition>
                    <text>
                        <p>An act that involves provision of a material by one entity to another.</p>
                        <p>
                            <i>Discussion:</i> The product is associated with the Supply Act via
                            Participation.typeCode="product". With general Supply Acts, the precise
                            identification of the Material (manufacturer, serial numbers, etc.) is
                            important. Most of the detailed information about the Supply should be
                            represented using the Material class. If delivery needs to be scheduled,
                            tracked, and billed separately, one can associate a Transportation Act
                            with the Supply Act. Pharmacy dispense services are represented as
                            Supply Acts, associated with a SubstanceAdministration Act. The
                            SubstanceAdministration class represents the administration of
                            medication, while dispensing is supply.</p>
                        <p>
                            <i>Examples:</i> Ordering bed sheets; Dispensing of a drug; Issuing
                            medical supplies from storage</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="quantity" sortKey="1" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The amount that was or is to be supplied (depending on the moodCode)</p>
                            <p>
                                <i>Discussion:</i> This attribute may be used as an alternative to
                                expectedUseTime or both may be used. If both are specified, then the
                                specified quantity is the amount expected to be consumed within the
                                expectedUseTime.</p>
                            <p>The unit of measure is restricted to a measured unit such as
                                milliliter and milligram. Non-measured, but countable units such as
                                tablet and capsule must not be specified using the unit component of
                                the PQ data type, except as an annotation, marked by {xxx}. Refer to
                                Data Types Part II Unabridged Specification, Appendix A: Unified
                                Code for Units of Measure. The type of 'countable' information is
                                determined by information in the 'product' entity.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="PQ"/>
            </attribute>
            <attribute name="expectedUseTime" sortKey="2" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Identifies the period time over which the supplied product is
                                expected to be used, or the length of time the supply is expected to
                                last.</p>
                            <p>In some situations, this attribute may be used instead of
                                Supply.quantity to identify the amount supplied by how long it is
                                expected to last, rather than the physical quantity issued. E.g. 90
                                days supply of medication (based on an ordered dosage), 10 hours of
                                jet fuel, etc. NOTE: When possible, it is always better to specify
                                Supply.quantity, as this tends to be more precise.
                                Supply.expectedUseTime will always be an estimate that can be
                                influenced by external factors.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="IVL">
                    <supplierBindingArgumentDatatype name="TS"/>
                </type>
            </attribute>
            <specializationChild childClassName="Diet" sortKey="1"/>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="WorkingList" isAbstract="false">
            <supplierStructuralDomain mnemonic="LIST"/>
            <annotations>
                <definition>
                    <text>
                        <p>A dynamic list of individual instances of Act which reflect the needs of
                            an individual worker, team of workers, or an organization to view groups
                            of Acts for clinical or administrative reasons.</p>
                        <p>
                            <i>Discussion:</i> The grouped Acts are related to the WorkingList via
                            an ActRelationship of type 'COMP' (component).</p>
                        <p>
                            <i>Examples:</i> Problem lists, goal lists, allergy lists, to-do lists,
                            etc.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="ownershipLevelCode" sortKey="1" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Indicates the category of representation for the personnel managing
                                the list, whether person, team or organization.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="ListOwnershipLevel" codingStrength="CWE"/>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="Container" isAbstract="false">
            <supplierStructuralDomain mnemonic="CONT"/>
            <annotations>
                <definition>
                    <text>
                        <p>A subtype of ManufacturedMaterial used to hold other Entities for
                            purposes such as transportation or protection of contents from loss or
                            damage. </p>
                        <p>
                            <i>Rationale:</i> The specifications for this class arose from the
                            collaboration between HL7 and the NCCLS. Many of the attribute
                            definitions are drawn from or reference the NCCLS standard. With
                            amorphic substances (liquids, gases) a container is required. However,
                            the content of a container is always distinguishable and relatively
                            easily separable from the container, unlike the content (ingredient) of
                            a mixture.</p>
                        <p>
                            <i>Usage:</i> A container is related to a content material through
                            Role.classCode = CONT (content).</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="capacityQuantity" sortKey="1" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The functional capacity of the container.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="PQ"/>
            </attribute>
            <attribute name="heightQuantity" sortKey="2" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The height of the container.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="PQ"/>
            </attribute>
            <attribute name="diameterQuantity" sortKey="3" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The outside diameter of the container.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="PQ"/>
            </attribute>
            <attribute name="capTypeCode" sortKey="4" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The type of container cap consistent with decapping, piercing or
                                other automated manipulation.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="ContainerCap" codingStrength="CWE"/>
            </attribute>
            <attribute name="separatorTypeCode" sortKey="5" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A material added to a container to facilitate and create a physical
                                separation of specimen components of differing density.</p>
                            <p>
                                <i>Examples:</i> A gel material added to blood collection tubes that
                                following centrifugation creates a physical barrier between the
                                blood cells and the serum or plasma.</p>
                            <p>
                                <i>Rationale:</i> The composition or nature of the separator
                                material may have an effect on the analysis. Knowledge of the
                                material aids interpretation of results.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="ContainerSeparator" codingStrength="CWE"/>
            </attribute>
            <attribute name="barrierDeltaQuantity" sortKey="6" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The distance from the Point of Reference to the separator material
                                (barrier) within a container. </p>
                            <p>
                                <i>Rationale:</i> This distance may be provided by a laboratory
                                automation system to an instrument and/or specimen
                                processing/handling device to facilitate the insertion of a sampling
                                probe into the specimen without touching the separator. See the
                                Point of Reference definition or in NCCLS standard AUTO5 Laboratory
                                Automation: Electromechanical Interfaces.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="PQ"/>
            </attribute>
            <attribute name="bottomDeltaQuantity" sortKey="7" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The distance from the Point of Reference to the outside bottom of the
                                container. </p>
                            <p>
                                <i>Rationale:</i> Refer to Point of Reference in NCCLS standard
                                AUTO5 Laboratory Automation: Electromechanical Interfaces.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="PQ"/>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="Device" isAbstract="false">
            <supplierStructuralDomain mnemonic="DEV"/>
            <annotations>
                <definition>
                    <text>
                        <p>A subtype of ManufacturedMaterial used in an activity, without being
                            substantially changed through that activity. The kind of device is
                            identified by the code attribute inherited from Entity.</p>
                        <p>
                            <i>Usage:</i> This includes durable (reusable) medical equipment as well
                            as disposable equipment.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="manufacturerModelName" sortKey="1" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The human designated moniker for a device assigned by the
                                manufacturer.</p>
                            <p>
                                <i>Examples:</i> Perkin Elmer 400 Inductively Coupled Plasma
                            Unit</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SC"/>
                <supplierDomainSpecification domainName="ManufacturerModelName" codingStrength="CWE"
                />
            </attribute>
            <attribute name="softwareName" sortKey="2" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The moniker, version and release of the software that operates the
                                device as assigned by the software manufacturer or developer.</p>
                            <p>
                                <i>Examples:</i> Agilent Technologies Chemstation A.08.xx</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SC"/>
                <supplierDomainSpecification domainName="SoftwareName" codingStrength="CWE"/>
            </attribute>
            <attribute name="localRemoteControlStateCode" sortKey="3" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A value representing the current state of control associated with the
                                device. </p>
                            <p>
                                <i>Examples:</i> A device can either work autonomously
                                (localRemoteControlStateCode="Local") or it can be controlled by
                                another system (localRemoteControlStateCode="Remote").</p>
                            <p>
                                <i>Rationale:</i> The control status of a device must be
                                communicated between devices prior to remote commands being
                                transmitted. If the device is not in "Remote" status then external
                                commands will be ignored.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="LocalRemoteControlState"
                    codingStrength="CWE"/>
            </attribute>
            <attribute name="alertLevelCode" sortKey="4" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A value representing the current functional activity of an automated
                                device. </p>
                            <p>
                                <i>Examples:</i> Normal, Warning, Critical</p>
                            <p>
                                <i>Constraints:</i> The value of the attribute is determined by the
                                device.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="DeviceAlertLevel" codingStrength="CWE"/>
            </attribute>
            <attribute name="lastCalibrationTime" sortKey="5" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The date/time of the last calibration of the device.</p>
                            <p>
                                <i>Rationale:</i> Devices are required to be recalibrated at
                                specific intervals to ensure they are performing within
                                specifications. The accepted interval between calibrations varies
                                with protocols. Thus for results to be valid, the precise time/date
                                of last calibration is a critical component. </p>
                        </text>
                    </definition>
                </annotations>
                <type name="TS"/>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="Entity" isAbstract="false">
            <supplierStructuralDomain mnemonic="ENT"/>
            <annotations>
                <definition>
                    <text>
                        <p>A physical thing, group of physical things or an organization capable of
                            participating in Acts, while in a role. </p>
                        <p>
                            <i>Discussion:</i> An entity is a physical object that has, had or will
                            have existence. The only exception to this is Organization, which while
                            not having a physical presence, fulfills the other characteristics of an
                            Entity. The Entity hierarchy encompasses living subjects (including
                            human beings), organizations, material, and places and their
                            specializations. It does not indicate the roles played, or acts that
                            these entities participate in.</p>
                        <p>
                            <i>Constraints:</i> It does not include events/acts/actions, or the
                            roles that things can play (e.g. patient, provider).</p>
                    </text>
                </definition>
            </annotations>
            <behavior supplierStateAttributeName="statusCode">
                <figure>
                    <fixedImage>
                        <pixmap href="./Graphics/RIM_EntityStatus.gif"/>
                    </fixedImage>
                </figure>
                <subState name="active" parentStateName="normal">
                    <annotations>
                        <definition>
                            <text>
                                <p>The state representing the fact that the Entity is currently
                                    active.</p>
                            </text>
                        </definition>
                    </annotations>
                </subState>
                <subState name="inactive" parentStateName="normal">
                    <annotations>
                        <definition>
                            <text>
                                <p>The state representing the fact that an entity can no longer be
                                    an active participant in events.</p>
                            </text>
                        </definition>
                    </annotations>
                </subState>
                <subState name="normal">
                    <annotations>
                        <definition>
                            <text>
                                <p>The "typical" state. Excludes "nullified", which represents the
                                    termination state of an Entity instance that was created in
                                    error</p>
                            </text>
                        </definition>
                    </annotations>
                </subState>
                <subState name="null"/>
                <subState name="nullified">
                    <annotations>
                        <definition>
                            <text>
                                <p>The state representing the termination of an Entity instance that
                                    was created in error.</p>
                            </text>
                        </definition>
                    </annotations>
                </subState>
                <transition name="revise" startStateName="active" endStateName="active"/>
                <transition name="inactivate" startStateName="active" endStateName="inactive"/>
                <transition name="reactivate" startStateName="inactive" endStateName="active"/>
                <transition name="revise" startStateName="inactive" endStateName="inactive"/>
                <transition name="nullify" startStateName="normal" endStateName="nullified"/>
                <transition name="create" startStateName="null" endStateName="active"/>
            </behavior>
            <attribute name="classCode" sortKey="1" isStructural="true" minimumMultiplicity="1"
                maximumMultiplicity="1" isMandatory="true">
                <annotations>
                    <definition>
                        <text>
                            <p>An HL7 defined value representing the class or category that the
                                Entity instance represents.</p>
                            <p>
                                <i>Examples:</i> Person, Animal, Chemical Substance, Group,
                                Organization</p>
                            <p>
                                <i>Rationale:</i> Due to the extremely large number of potential
                                values for a code set representing all physical things in the
                                universe, the class code indicates both the subtype branch of the
                                Entity hierarchy used as well as a high level classifier to
                                represent the instance of Entity. This can be used to constrain the
                                eligible value domains for the Entity.code attribute.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="EntityClass" codingStrength="CNE"/>
            </attribute>
            <attribute name="determinerCode" sortKey="2" isStructural="true" minimumMultiplicity="1"
                maximumMultiplicity="1" isMandatory="true">
                <annotations>
                    <definition>
                        <text>
                            <p>An HL7 defined value representing whether the Entity represents a
                                kind-of or a specific instance.</p>
                            <p>
                                <i>Examples:</i> 1 human being (an instance), 3 syringes (quantified
                                kind) or the population of Indianapolis (kind of group)</p>
                            <p>
                                <i>Rationale:</i> An Entity may at times represent information
                                concerning a specific instance (the most common), a quantifiable
                                group with common characteristics or a general type of Entity. This
                                code distinguishes these different representations.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="EntityDeterminer" codingStrength="CNE"/>
            </attribute>
            <attribute name="id" sortKey="3" minimumMultiplicity="0" maximumMultiplicity="*"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A unique identifier for the Entity.</p>
                            <p>
                                <i>Rationale:</i> Successful communication only requires that an
                                entity have a single identifier assigned to it. However, it is
                                recognized that as different systems maintain different databases,
                                there may be different instance identifiers assigned by different
                                systems. Note that an instance identifier is a pure identifier and
                                not a classifier. For Material, serial numbers assigned by specific
                                manufacturers, catalog numbers of specific distributors, or
                                inventory numbers issued by owners, may also be represented by the
                                Role.id, which allows a more clear expression of the fact that such
                                a code is assigned by a specific party associated with that
                                material.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SET">
                    <supplierBindingArgumentDatatype name="II"/>
                </type>
            </attribute>
            <attribute name="code" sortKey="4" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A value representing the specific kind of Entity the instance
                                represents.</p>
                            <p>
                                <i>Examples:</i> A medical building, a Doberman Pinscher, a blood
                                collection tube, a tissue biopsy.</p>
                            <p>
                                <i>Rationale:</i> For each Entity, the value for this attribute is
                                drawn from one of several coding systems depending on the
                                Entity.classCode, such as living subjects (animal and plant
                                taxonomies), chemical substance (e.g., IUPAC code), organizations,
                                insurance company, government agency, hospital, park, lake, syringe,
                                etc. It is possible that Entity.code may be so fine grained that it
                                represents a single instance. An example is the CDC vaccine
                                manufacturer code, modeled as a concept vocabulary, when in fact
                                each concept refers to a single instance.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="EntityCode" codingStrength="CWE"/>
            </attribute>
            <attribute name="quantity" sortKey="5" minimumMultiplicity="0" maximumMultiplicity="*"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The number or quantity of the Entity, with appropriate units,
                                congruent with the value of Entity.determinerCode. </p>
                            <p>
                                <i>Examples:</i> With undetermined kinds, the quantity is but a
                                reference quantity for the specification of the proportion of
                                ingredients or components (e.g. through a has-part, has-ingredient,
                                or has-content Role). For example, a kind of group with 60% females
                                is Person(quantity = 100) has-part Person(quantity = 60; sex =
                                female). Amoxicillin 500 mg per tablet is Material(Tablet, quantity
                                = 1) has-ingredient Material(Amoxicillin, quantity = 500 mg).
                                Glucose 5% (D5W) is Material(D5W, quantity = 1 kg) has-ingredient
                                Material(Glucose, quantity = 50 g).</p>
                            <p>Material-specific quantity relations are expressed using the fact
                                that the data type of this attribute is a set of physical quantity
                                (SET&lt;PQ&gt;). If more than one quantity value are
                                specified in this set, each element in this set is considered to
                                specify the same amount of the material. For example, for one liter
                                of water one could use the set 1 L, 1 kg, 55.56 mol to specify the
                                volume, mass, and amount of substance for the same amount of water,
                                this is equivalent with specifying the mass density (volumic mass 1
                                kg/L) and the molar mass (18 g/mol). For Glucose one could specify
                                180 g, 1 mol according to the molar mass (180 g/mol).</p>
                            <p>
                                <i>Discussion:</i> When the Entity instance is a portion of a
                                substance, the quantity specifies the amount of that substance
                                comprised by that portion. For an undetermined substance (kind) the
                                quantity serves two purposes at the same time: (a) it provides a
                                means of relations between quantities specific for that substance,
                                and (b) it is a reference quantity for the specification of
                                ingredients or components. In all cases, the quantity is an
                                extensive "amount" kind of quantity (e.g., number, length, volume,
                                mass, surface area, energy, etc.). Note that most relative or
                                fractional quantities are not amounts, in particular, mass fraction,
                                substance concentration, mass ratios, percentages, etc. are not
                                extensive quantities and are prohibited values for this attribute.</p>
                            <p>
                                <i>Constraints:</i> For Entities with determinerCode = INSTANCE, the
                                quantity is 1. For an Entity with determinerCode = QUANTIFIED_KIND,
                                the quantity is the number of individual members in the group; for
                                an Entity with a determinerCode = KIND, the value is
                            undetermined.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SET">
                    <supplierBindingArgumentDatatype name="PQ"/>
                </type>
            </attribute>
            <attribute name="name" sortKey="6" minimumMultiplicity="0" maximumMultiplicity="*"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A non-unique textual identifier or moniker for the Entity.</p>
                            <p>
                                <i>Examples:</i> Proper names, nicknames, legal names of persons,
                                places or things.</p>
                            <p>
                                <i>Rationale:</i> Most entities have a commonly used name that can
                                be used to differentiate them from other Entities, but does not
                                provide a unique identifier.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="BAG">
                    <supplierBindingArgumentDatatype name="EN"/>
                </type>
            </attribute>
            <attribute name="desc" sortKey="7" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A textual or multimedia depiction of the Entity.</p>
                            <p>
                                <i>Discussion:</i> The content of the description is not considered
                                part of the functional information communicated between systems.
                                Descriptions are meant to be shown to interested human individuals.
                                All information relevant for automated functions must be
                                communicated using the proper attributes and associated objects.</p>
                            <p>
                                <i>Rationale:</i> Names and descriptions of entities are typically
                                more meaningful to human viewers than numeric, mnemonic or
                                abbreviated code values. The description allows for additional
                                context about the entity to be conveyed to human viewers without
                                impacting the functional components of the message.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="ED"/>
            </attribute>
            <attribute name="statusCode" sortKey="8" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A value representing whether the information associated with the
                                Entity is currently active or inactive for the purpose of
                                participation in acts.</p>
                            <p>
                                <b>Design Advisory: </b>This attribute was defined in the original
                                RIM as repeating, owing to the presence of nested states in the
                                state machines. In actual practice, however, there is never a need
                                to communicate more than a single status value. therefore,
                                committees are advised to <b>constrain this attribute to a maximum
                                    cardinality of 1</b> in all message designs. </p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="EntityStatus" codingStrength="CNE"/>
            </attribute>
            <attribute name="existenceTime" sortKey="9" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>An interval of time specifying the period in which the Entity
                                physically existed. </p>
                            <p>
                                <i>Examples:</i> Birthdate/Deathdate, ManufactureDate/DisposalDate</p>
                            <p>
                                <i>Constraints:</i> This period may represent past, present or
                                future time periods.</p>
                            <p>
                                <i>Rationale:</i> Physical entities have specified periods in which
                                they exist. Human beings are born, live their lives and die.
                                Equipment is manufactured, placed in service, retired and salvaged.
                                The relevance of this attribute is in planning, availability and
                                retrospective analysis.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="IVL">
                    <supplierBindingArgumentDatatype name="TS"/>
                </type>
            </attribute>
            <attribute name="telecom" sortKey="10" minimumMultiplicity="0" maximumMultiplicity="*"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A telecommunication address for the Entity.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="BAG">
                    <supplierBindingArgumentDatatype name="TEL"/>
                </type>
            </attribute>
            <attribute name="riskCode" sortKey="11" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A value representing the type of hazard or threat associated with the
                                Entity.</p>
                            <p>
                                <i>Examples:</i> Petrochemical or organic chemicals are highly
                                flammable agents that pose an increased risk of fire under certain
                                conditions. Entities with either natural or introduced radioactive
                                character pose a risk to those handling them. Entities comprising
                                specimens from diseased individuals pose an increased risk of
                                infection to those handling them. Persons or animals of irascible
                                temperament may prove to be a risk to healthcare personnel.</p>
                            <p>
                                <i>Rationale:</i> Some entities have characteristics that pose
                                potential increased risk of injury or damage to other Entities. This
                                attribute identifies the type of risk without specifying the level
                                of risk.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="EntityRisk" codingStrength="CWE"/>
            </attribute>
            <attribute name="handlingCode" sortKey="12" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A value representing special handling requirements for the Entity.</p>
                            <p>
                                <i>Examples:</i> Keep at room temperature; Keep frozen below 0 C;
                                Keep in a dry environment; Keep upright, do not turn upside down.</p>
                            <p>
                                <i>Rationale:</i> This attribute is used to describe special
                                handling required by the Entity to avoid damage to it or other
                                entities.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="EntityHandling" codingStrength="CWE"/>
            </attribute>
            <specializationChild childClassName="LivingSubject" sortKey="1"/>
            <specializationChild childClassName="Material" sortKey="2"/>
            <specializationChild childClassName="Organization" sortKey="3"/>
            <specializationChild childClassName="Place" sortKey="4"/>
            <specializationChild childClassName="EntityHeir" sortKey="5"/>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="LanguageCommunication" isAbstract="false">
            <annotations>
                <definition>
                    <text>
                        <p>The language communication capabilities for an Entity.</p>
                        <p>
                            <i>Examples:</i> A patient who originally came from Mexico may have
                            fluent language capabilities to speak, read and write in Spanish, but
                            only rudimentary capabilities in English. A person from Russia may have
                            the capability to communicate equally well in spoken language in
                            Russian, Armenian or Ukrainian, but prefers to speak in Armenian. </p>
                        <p>
                            <i>Discussion:</i> While it may seem on the surface that this class
                            would be restricted in usage to only the LivingSubject subtypes, Devices
                            also have the ability to communicate, such as automated telephony
                            devices that transmit patient information to live operators on a triage
                            line or provide automated laboratory results to clinicians.</p>
                        <p>
                            <i>Rationale:</i> Each Entity with the ability to communicate verbally
                            has differing language and proficiency level. This class specifies the
                            languages with which the entity can communicate, the mode of
                            communication (speak, read, write), the proficiency of that
                            communication, and the Entity's preference.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="languageCode" sortKey="1" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A value representing a language for which the Entity has some level
                                of proficiency for written or spoken communication.</p>
                            <p>
                                <i>Examples:</i> Spanish, Italian, German, English, American Sign,
                                etc.</p>
                            <p>
                                <i>Discussion:</i> Communication via spoken or written language is
                                not solely restricted to LivingSubjects. Devices that communicate
                                with persons using human language also must specify in which
                                languages they are capable. Automated voice response systems respond
                                to human language and communicate with other devices or persons
                                using human language. </p>
                            <p>
                                <i>Rationale:</i> Many individuals and devices have the capability
                                to communicate at varying levels in multiple languages. This code
                                specifies a language capability that the entity wishes to make
                                known.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="HumanLanguage" codingStrength="CWE"/>
            </attribute>
            <attribute name="modeCode" sortKey="2" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A value representing the method of expression of the language</p>
                            <p>
                                <i>Examples:</i> expressed spoken, expressed written, expressed
                                signed, received spoken, received written, received signed</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="LanguageAbilityMode" codingStrength="CWE"/>
            </attribute>
            <attribute name="proficiencyLevelCode" sortKey="3" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A value representing the level of proficiency in a language.</p>
                            <p>
                                <i>Examples:</i> excellent, good, fair, poor</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="LanguageAbilityProficiency"
                    codingStrength="CWE"/>
            </attribute>
            <attribute name="preferenceInd" sortKey="4" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>An indicator specifying whether or not the language is preferred by
                                the entity for the associated mode.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="BL"/>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="LivingSubject" isAbstract="false">
            <supplierStructuralDomain mnemonic="LIV"/>
            <annotations>
                <definition>
                    <text>
                        <p>A subtype of Entity representing an organism or complex animal, alive or
                            not. </p>
                        <p>
                            <i>Examples:</i> A person, dog, microorganism or a plant of any
                            taxonomic group.</p>
                        <p>
                            <i>Constraints:</i> Instances of this class encompass mammals, birds,
                            fishes, bacteria, parasites, fungi and viruses. Person is a
                            specialization of this class. </p>
                        <p>
                            <i>Rationale:</i> This class contains "static" or "administrative"
                            attributes of interest to medicine that differentiate living organisms
                            from other Entities.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="administrativeGenderCode" sortKey="1" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A value representing the gender (sex) of a Living subject.</p>
                            <p>
                                <i>Examples:</i> female, male </p>
                            <p>
                                <i>Discussion:</i> This attribute does not include terms related to
                                clinical gender. Gender is a complex physiological, genetic and
                                sociological concept that requires multiple observations in order to
                                be comprehensively described. The purpose of this attribute is to
                                provide a high level classification that can additionally be used
                                for the appropriate allocation of inpatient bed assignment.</p>
                            <p>
                                <i>Constraints:</i> This code is used for administrative purposes.
                            </p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="AdministrativeGender" codingStrength="CWE"
                />
            </attribute>
            <attribute name="birthTime" sortKey="2" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The date and time of a living subject's birth or hatching.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="TS"/>
            </attribute>
            <attribute name="deceasedInd" sortKey="3" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>An indication that the subject is dead.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="BL"/>
            </attribute>
            <attribute name="deceasedTime" sortKey="4" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The date and time that a living subject's death occurred.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="TS"/>
            </attribute>
            <attribute name="multipleBirthInd" sortKey="5" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>An indication as to whether the living subject is part of a multiple
                                birth.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="BL"/>
            </attribute>
            <attribute name="multipleBirthOrderNumber" sortKey="6" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The order in which this living subject was born if part of a multiple
                                birth.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="INT"/>
            </attribute>
            <attribute name="organDonorInd" sortKey="7" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>An indication that the living subject is a candidate to serve as an
                                organ donor.</p>
                            <p>
                                <i>Discussion:</i> This attribute specifies whether an individual
                                living subject has donated or is willing to donate an organ.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="BL"/>
            </attribute>
            <specializationChild childClassName="NonPersonLivingSubject" sortKey="1"/>
            <specializationChild childClassName="Person" sortKey="2"/>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="ManufacturedMaterial" isAbstract="false">
            <supplierStructuralDomain mnemonic="MMAT"/>
            <annotations>
                <definition>
                    <text>
                        <p>A subtype of Material representing an Entity or combination of Entities
                            transformed for a particular purpose by a non-natural or manufacturing
                            process. </p>
                        <p>
                            <i>Examples:</i> Processed food products, disposable syringes, chemistry
                            analyzer, saline for infusion, etc.</p>
                        <p>
                            <i>Discussion:</i> This class encompasses containers, devices, software
                            modules and facilities.</p>
                        <p>
                            <i>Rationale:</i> This class is used to further define the
                            characteristics of Entities that are created out of other Entities.
                            These entities are identified and tracked through associations and
                            mechanisms unique to the class, such as lotName, stabilityTime and
                            expirationTime.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="lotNumberText" sortKey="1" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>An alphanumeric string used to identify a particular batch of
                                manufactured material. </p>
                            <p>
                                <i>Discussion:</i> The lot name is usually printed on the label
                                attached to the container holding the substance and/or on the
                                packaging which houses the container. Note that a lot number is not
                                meant to be a unique identifier, but is meaningful only when the
                                product kind and manufacturer are also identified.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="ST"/>
            </attribute>
            <attribute name="expirationTime" sortKey="2" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The date and time the manufacturer no longer ensures the safety,
                                quality, and/or proper functioning of the material.</p>
                            <p>
                                <i>Rationale:</i> There is a need in many situations that the
                                materials used are of a specific quality or potency or functional
                                status. The ending date for this guarantee is specified by the
                                manufacturer. After that date, while the material may still provide
                                the same characteristics, the manufacturer no longer takes
                                responsibility that the product will perform as specified and denies
                                responsibility for failure of the material after that date.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="IVL">
                    <supplierBindingArgumentDatatype name="TS"/>
                </type>
            </attribute>
            <attribute name="stabilityTime" sortKey="3" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The time at which the material is considered useable after it is
                                activated.</p>
                            <p>
                                <i>Examples:</i> After opening a bottle of a liquid. The mixing of
                                two chemicals for an analysis that must be mixed and used within two
                                hours or their activity diminishes. </p>
                            <p>
                                <i>Discussion:</i> If a kind of material is described
                                (determinerCode = KIND) only the width of that interval can be
                                known, i.e., the duration after opening the reagent container at
                                which the reagent substance is considered useable for its normal
                                testing purpose. For an actual instance of the reagent (e.g., a
                                specific bottle), the stabilityTime.low TS marks the time at which
                                the reagent bottle has been opened (or the reagent was otherwise
                                activated). Together with the typical stability duration, this
                                determines the stabilityTime.high TS beyond which the reagent is no
                                longer considered useable for its normal testing purpose.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="IVL">
                    <supplierBindingArgumentDatatype name="TS"/>
                </type>
            </attribute>
            <specializationChild childClassName="Container" sortKey="1"/>
            <specializationChild childClassName="Device" sortKey="2"/>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="Material" isAbstract="false">
            <supplierStructuralDomain mnemonic="MAT"/>
            <annotations>
                <definition>
                    <text>
                        <p>A subtype of Entity that is inanimate and locationally independent. </p>
                        <p>
                            <i>Examples:</i> Pharmaceutical substances (including active vaccines
                            containing retarded virus), disposable supplies, durable equipment,
                            implantable devices, food items (including meat or plant products),
                            waste, traded goods, etc.</p>
                        <p>
                            <i>Discussion:</i> Manufactured or processed products are considered
                            material, even if they originate as living matter. Materials come in a
                            wide variety of physical forms and can pass through different states
                            (ie. Gas, liquid, solid) while still retaining their physical
                            composition and material characteristics.</p>
                        <p>
                            <i>Rationale:</i> There are entities that have attributes in addition to
                            the Entity class, yet cannot be classified as either LivingSubject or
                            Place.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="formCode" sortKey="1" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A value representing the state (solid, liquid, gas) and nature of the
                                material. </p>
                            <p>
                                <i>Examples:</i> For therapeutic substances, the dose form, such as
                                tablet, ointment, gel, etc.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="MaterialForm" codingStrength="CWE"/>
            </attribute>
            <specializationChild childClassName="ManufacturedMaterial" sortKey="1"/>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="NonPersonLivingSubject" isAbstract="false">
            <supplierStructuralDomain mnemonic="NLIV"/>
            <annotations>
                <definition>
                    <text>
                        <p>A subtype of LivingSubject that includes all living things except the
                            species homo sapiens.</p>
                        <p>
                            <i>Examples:</i> Cattle, birds, bacteria , plants molds and fungi, etc. </p>
                        <p>
                            <i>Rationale:</i> Living organisms other than human beings may require
                            additional characterizing information such as genetic strain
                            identification that cannot be conveyed in the Entity.code.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="strainText" sortKey="1" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A text string representing a specific genotypic or phenotypic variant
                                of a NonPersonLivingSubject.</p>
                            <p>
                                <i>Examples:</i> Minnesota5 (swine strain), DXL (poultry strain),
                                RB51 (vaccine strain of Brucella abortus)</p>
                            <p>
                                <i>Rationale:</i> There is no universal guideline for the naming or
                                cataloging of strains. Many strain designations are created and
                                eliminated over time, while some become established in various
                                industries for a variety of reasons (vaccine production, breeding
                                stock popularity, etc). However, the ability for anyone who cares to
                                designate an organism as a "new" strain, precludes this field from
                                being a coded value. Descriptive text is required to capture these
                                designations.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="ED"/>
            </attribute>
            <attribute name="genderStatusCode" sortKey="2" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A value representing whether the primary reproductive organs of
                                NonPersonLivingSubject are present.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="GenderStatus" codingStrength="CWE"/>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="Organization" isAbstract="false">
            <supplierStructuralDomain mnemonic="ORG"/>
            <annotations>
                <definition>
                    <text>
                        <p>An Entity representing a formalized group of entities with a common
                            purpose (e.g. administrative, legal, political) and the infrastructure
                            to carry out that purpose. </p>
                        <p>
                            <i>Examples:</i> Companies and institutions, a government department, an
                            incorporated body that is responsible for administering a facility, an
                            insurance company.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="addr" sortKey="1" minimumMultiplicity="0" maximumMultiplicity="*"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The postal and/or residential address of an organization.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="BAG">
                    <supplierBindingArgumentDatatype name="AD"/>
                </type>
            </attribute>
            <attribute name="standardIndustryClassCode" sortKey="2" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A value representing the industrial category of an organization
                                entity.</p>
                            <p>
                                <i>Examples:</i> 11231-Chicken Egg Production, 6211- Offices of
                                Physicians, 621511-Medical Laboratories, 524114-Direct Health and
                                Medical Insurance Carriers</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="OrganizationIndustryClass"
                    codingStrength="CWE"/>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="Person" isAbstract="false">
            <supplierStructuralDomain mnemonic="PSN"/>
            <annotations>
                <definition>
                    <text>
                        <p>A subtype of LivingSubject representing a human being.</p>
                        <p>
                            <i>Constraints:</i> This class can be used to represent either a single
                            individual or a group of individuals based on the value of
                            Entity.determinerCode and Entity.quantity.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="addr" sortKey="1" minimumMultiplicity="0" maximumMultiplicity="*"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The postal and/or residential address of a Person.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="BAG">
                    <supplierBindingArgumentDatatype name="AD"/>
                </type>
            </attribute>
            <attribute name="maritalStatusCode" sortKey="2" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A value representing the domestic partnership status of a person.</p>
                            <p>
                                <i>Examples:</i> Married, separated, divorced, widowed, common-law
                                marriage.</p>
                            <p>
                                <i>Rationale:</i> This information is reported on UB FL 16</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="MaritalStatus" codingStrength="CWE"/>
            </attribute>
            <attribute name="educationLevelCode" sortKey="3" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The highest level of education a person achieved (e.g. elementary
                                school, high school or secondary school degree complete, college or
                                baccalaureate degree complete).</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="EducationLevel" codingStrength="CWE"/>
            </attribute>
            <attribute name="disabilityCode" sortKey="4" minimumMultiplicity="0"
                maximumMultiplicity="*" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A value identifying a person's disability.</p>
                            <p>
                                <i>Examples:</i> vision impaired, hearing impaired.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SET">
                    <supplierBindingArgumentDatatype name="CE"/>
                </type>
                <supplierDomainSpecification domainName="PersonDisabilityType" codingStrength="CWE"
                />
            </attribute>
            <attribute name="livingArrangementCode" sortKey="5" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A value specifying the housing situation of a person. </p>
                            <p>
                                <i>Examples:</i> Independent household, institution, nursing home,
                                extended care facility, retirement community, etc.). </p>
                            <p>
                                <i>Discussion:</i> Used for discharge planning, social service
                                assessment, psychosocial evaluation.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="LivingArrangement" codingStrength="CWE"/>
            </attribute>
            <attribute name="religiousAffiliationCode" sortKey="6" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The primary religious preference of a person (e.g. Hinduism, Islam,
                                Roman Catholic Church).</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="ReligiousAffiliation" codingStrength="CWE"
                />
            </attribute>
            <attribute name="raceCode" sortKey="7" minimumMultiplicity="0" maximumMultiplicity="*"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A value representing the race of a person.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SET">
                    <supplierBindingArgumentDatatype name="CE"/>
                </type>
                <supplierDomainSpecification domainName="Race" codingStrength="CWE"/>
            </attribute>
            <attribute name="ethnicGroupCode" sortKey="8" minimumMultiplicity="0"
                maximumMultiplicity="*" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The ethnic group of the person.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SET">
                    <supplierBindingArgumentDatatype name="CE"/>
                </type>
                <supplierDomainSpecification domainName="Ethnicity" codingStrength="CWE"/>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="Place" isAbstract="false">
            <supplierStructuralDomain mnemonic="PLC"/>
            <annotations>
                <definition>
                    <text>
                        <p>A subtype of Entity representing a bounded physical place or site with
                            its contained structures, if any. </p>
                        <p>
                            <i>Examples:</i> A field, lake, city, county, state, country, lot
                            (land), building, pipeline, power line, playground, ship, truck. </p>
                        <p>
                            <i>Constraints:</i> Place may be natural or man-made. The geographic
                            position of a place may or may not be constant. </p>
                        <p>
                            <i>Discussion:</i> Places may be work facilities (where relevant acts
                            occur), homes (where people live) or offices (where people work). Places
                            may contain sub-places (floor, room, booth, bed). Places may also be
                            sites that are investigated in the context of health care, social work,
                            public health administration (e.g., buildings, picnic grounds, day care
                            centers, prisons, counties, states, and other focuses of epidemiological
                            events).</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="mobileInd" sortKey="1" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>An Indication of whether the facility has the capability to move
                                freely from one location to another.</p>
                            <p>
                                <i>Examples:</i> Ships, aircraft and ambulances all have the
                                capability to participate in healthcare acts.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="BL"/>
            </attribute>
            <attribute name="addr" sortKey="2" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The physical address of this place. </p>
                            <p>
                                <i>Constraints:</i> Must be the address that allows the physical
                                location of the place on a map.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="AD"/>
            </attribute>
            <attribute name="directionsText" sortKey="3" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A free text note that carries information related to a site that is
                                useful for entities accessing that site. </p>
                            <p>
                                <i>Discussion:</i> The attribute could include directions for
                                finding the site when address information is inadequate, GPS
                                information is not available, and/or the entity accessing the site
                                cannot make direct use of the GPS information. It could also include
                                information useful to people visiting the location. E.g., "Last
                                house on the right", "If owner not present, check whereabouts with
                                neighbor down the road".</p>
                        </text>
                    </definition>
                </annotations>
                <type name="ED"/>
            </attribute>
            <attribute name="positionText" sortKey="4" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A set of codes that locates the site within a mapping scheme. </p>
                            <p>
                                <i>Examples:</i> map coordinates for US Geological Survey maps.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="ED"/>
            </attribute>
            <attribute name="gpsText" sortKey="5" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The global positioning system coordinates of a place.</p>
                            <p>
                                <i>Discussion:</i> The global positioning system values for this
                                attribute should conform with the USGS Spatial Data Transmission
                                Standards. Among other things this includes the nature of the
                                latitude and longitude readings, the offset error, the projection.</p>
                            <p>
                                <i>Rationale:</i> In some field conditions, there will be no
                                physical address to identify a place of interest. As all locations
                                on the surface of the earth have unique geographic coordinates, the
                                GPS values allow for precise location information to be captured and
                                transmitted.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="ST"/>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="Access" isAbstract="false">
            <supplierStructuralDomain mnemonic="ACCESS"/>
            <annotations>
                <definition>
                    <text>
                        <p>A role played by a device when the device is used to administer
                            therapeutic agents (medication and vital elements) into the body, or to
                            drain material (e.g., exudates, pus, urine, air, blood) out of the body.</p>
                        <p>
                            <i>Discussion:</i> In general, Access is a Role of a
                            ManufacturedMaterial or Device, something specifically manufactured or
                            created to serve that purpose, such as a catheter or cannula inserted
                            into a compartment of the body. </p>
                        <p>Devices in the role of an Access are typically used in intake/outflow
                            observations, and in medication routing instructions. Microbiologic
                            observations on the material itself or on fluids coming out of a drain,
                            are also common.</p>
                        <p>
                            <i>Rationale:</i> The Access role primarily exists in order to describe
                            material actually deployed as an access, and not so much the fresh
                            material as it comes from the manufacturer. For example, in supply
                            ordering a box of catheters from a distributor, it is not necessary to
                            use the Access role class, since the material attributes will usually
                            suffice to describe and identify the product for the order. But the
                            Access role is used to communicate about the maintenance,
                            intake/outflow, and due replacement of tubes and drains.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="approachSiteCode" sortKey="1" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A coded specification of the anatomic site where the Access (cannula,
                                line or drain) first enters the body and, if applicable, a routing
                                from the first entrance to the target site. </p>
                            <p>
                                <i>Examples:</i> For example an arteria pulmonalis catheter targets
                                a pulmonary artery but the access approach site is typically the
                                vena carotis interna at the neck, or the vena subclavia at the fossa
                                subclavia.</p>
                            <p>
                                <i>Constraints:</i> The coding system is the same as for
                                Procedure.approachSiteCode; indeed the Access.approachSiteCode has
                                been copied from the Procedure class into the Access role class. The
                                value of the Access.approachSiteCode should be identical to the
                                value of the Procedure.approachSiteCode of an associated access
                                placement procedure.</p>
                            <p>
                                <i>Rationale:</i> Since accesses are typically placed for a
                                considerable period of time and since the access is used as a
                                resource of many acts, the access approach site becomes an important
                                identifying attribute of the access itself (as opposed to merely
                                being an attribute of the placement procedure).</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CD"/>
                <supplierDomainSpecification domainName="ActSite" codingStrength="CWE"/>
            </attribute>
            <attribute name="targetSiteCode" sortKey="2" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A coded specification of the site or body compartment into which
                                access is being provided, i.e., the compartment into which material
                                is administered or from which it is collected.</p>
                            <p>
                                <i>Examples:</i> For example, a pulmonary artery catheter will have
                                the target site "arteria pulmonalis".</p>
                            <p>
                                <i>Constraints:</i> The coding system is the same as for
                                Procedure.targetSiteCode; indeed the Access.targetSiteCode has been
                                copied from the Procedure class into the Access role class. The
                                value of the Access.targetSiteCode should be identical to the value
                                of the Procedure.targetSiteCode of an associated access placement
                                procedure.</p>
                            <p>
                                <i>Rationale:</i> Since accesses are typically placed for a
                                considerable period of time and since the access is used as a
                                resource of many acts, the target site becomes an important
                                identifying attribute of the access itself (as opposed to merely
                                being an attribute of the placement procedure). The target site is
                                important information that determines what kinds of substances may
                                or may not be administered (e.g., special care to avoid medication
                                injections into an arterial access).</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CD"/>
                <supplierDomainSpecification domainName="ActSite" codingStrength="CWE"/>
            </attribute>
            <attribute name="gaugeQuantity" sortKey="3" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A measure for the inner diameter of the Access (e.g. the lumen of the
                                tube).</p>
                        </text>
                    </definition>
                </annotations>
                <type name="PQ"/>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="Employee" isAbstract="false">
            <supplierStructuralDomain mnemonic="EMP"/>
            <annotations>
                <definition>
                    <text>
                        <p>A role played by a person who is associated with an organization (the
                            employer, scoper) to receive wages or salary.</p>
                        <p>
                            <i>Discussion:</i> The purpose of the role is to identify the type of
                            relationship the employee has to the employer rather than the nature of
                            the work actually performed (contrast with AssignedEntity).</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="jobCode" sortKey="1" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code specifying an employer-defined categorization of work, used
                                primarily for payroll/remuneration purposes and not necessarily
                                indicative of an employee's specific work assignments,
                                responsibilities and privileges. Examples are accountant, programmer
                                analyst, patient care associate, staff nurse, etc.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="EmployeeJob" codingStrength="CWE"/>
            </attribute>
            <attribute name="jobTitleName" sortKey="2" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The title of the job held, for example, Vice President, Senior
                                Technical Analyst. This is a local name for the employee's
                                occupation that doesn't necessarily correspond to any scheme for
                                categorizing occupation. Trading partners that need a coded standard
                                should be using Employee "occupation" attribute.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SC"/>
                <supplierDomainSpecification domainName="JobTitleName" codingStrength="CWE"/>
            </attribute>
            <attribute name="jobClassCode" sortKey="3" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code qualifying the employment regarding frequency or periodicity,
                                such as, full-time vs. part-time.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="EmployeeJobClass" codingStrength="CWE"/>
            </attribute>
            <attribute name="occupationCode" sortKey="4" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code qualifying the classification of kind-of-work based upon a
                                recognized industry or jurisdictional standard.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="EmployeeOccupationCode"
                    codingStrength="CWE"/>
            </attribute>
            <attribute name="salaryTypeCode" sortKey="5" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code specifying the method used by the employer to compute the
                                employee's salary or wages. For example, hourly, annual, or
                                commission.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="EmployeeSalaryType" codingStrength="CWE"/>
            </attribute>
            <attribute name="salaryQuantity" sortKey="6" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The amount paid in salary or wages to the employee according to the
                                computation method specified in salaryTypeCode. E.g., if the
                                salaryTypeCode is "hourly" the salaryQuantity specifies the hourly
                                wage.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="MO"/>
            </attribute>
            <attribute name="hazardExposureText" sortKey="7" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The type of hazards associated with the work performed by the
                                employee for the employer. For example, asbestos, infectious
                            agents.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="ED"/>
            </attribute>
            <attribute name="protectiveEquipmentText" sortKey="8" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Protective equipment needed for the job performed by the employee for
                                the employer. For example, safety glasses, hardhat.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="ED"/>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="LicensedEntity" isAbstract="false">
            <supplierStructuralDomain mnemonic="LIC"/>
            <annotations>
                <definition>
                    <text>
                        <p>A Role of an Entity (player) that is accredited with licenses or
                            qualifications (diplomas) certifying that this Entity may properly
                            perform specific functions.</p>
                        <p>
                            <i>Examples:</i> 1.) A paramedical training diploma</p>
                        <p>2.) The certification of equipment</p>
                        <p>3.) A license to a Person or Organization to provide health services.</p>
                        <p>
                            <i>Constraints:</i> The scoper is the Organization that issues the
                            credential.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="recertificationTime" sortKey="1" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The date recertification is required.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="TS"/>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="Patient" isAbstract="false">
            <supplierStructuralDomain mnemonic="PAT"/>
            <annotations>
                <definition>
                    <text>
                        <p>A Role of a LivingSubject (player) as a recipient of health care services
                            from a healthcare provider (scoper).</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="veryImportantPersonCode" sortKey="1" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code specifying the Patient's special status granted by the scoper
                                organization, often resulting in preferred treatment and special
                                considerations. For example, board member, diplomat, etc.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="PatientImportance" codingStrength="CWE"/>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="Role" isAbstract="false">
            <supplierStructuralDomain mnemonic="ROL"/>
            <annotations>
                <definition>
                    <text>
                        <p>A competency of the Entity playing the Role as identified, defined,
                            guaranteed, or acknowledged by the Entity that scopes the Role.</p>
                        <p>
                            <i>Discussion:</i> An Entity participates in an Act as in a particular
                            Role. Note that a particular entity in a particular role can participate
                            in an act in many ways. Thus, a Person in the role of a practitioner can
                            participate in a patient encounter as a rounding physician or as an
                            attending physician. The Role defines the competency of the Entity
                            irrespective of any Act, as opposed to Participation, which are limited
                            to the scope of an Act.</p>
                        <p>Each role is "played" by one Entity, called the "player" and is "scoped"
                            by another Entity, called the "scoper". Thus the Role of "patient" may
                            be played by a person and scoped by the provider organization from which
                            the patient will receive services. Similarly, the employer scopes an
                            "employee" role.</p>
                        <p>The identifier of the Role identifies the Entity playing the role in that
                            role. This identifier is assigned by the scoping Entity to the player.
                            The scoping Entity need not have issued the identifier, but it may have
                            re-used an existing identifier for the Entity to also identify the
                            Entity in the Role with the scoper.</p>
                        <p>Most attributes of Role are attributes of the playing entity while in the
                            particular role.</p>
                    </text>
                </definition>
            </annotations>
            <behavior supplierStateAttributeName="statusCode">
                <figure>
                    <fixedImage>
                        <pixmap href="./Graphics/RIM_RoleStatus.gif"/>
                    </fixedImage>
                </figure>
                <subState name="active" parentStateName="normal">
                    <annotations>
                        <definition>
                            <text>
                                <p>The state representing the fact that the Entity is currently
                                    active in the Role.</p>
                            </text>
                        </definition>
                    </annotations>
                </subState>
                <subState name="cancelled" parentStateName="normal">
                    <annotations>
                        <definition>
                            <text>
                                <p>The terminal state resulting from cancellation of the role prior
                                    to activation.</p>
                            </text>
                        </definition>
                    </annotations>
                </subState>
                <subState name="normal">
                    <annotations>
                        <definition>
                            <text>
                                <p>The "typical" state. Excludes "nullified", which represents the
                                    termination of a Role instance that was created in error.</p>
                            </text>
                        </definition>
                    </annotations>
                </subState>
                <subState name="null"/>
                <subState name="nullified">
                    <annotations>
                        <definition>
                            <text>
                                <p>The state representing the termination of a Role instance that
                                    was created in error</p>
                            </text>
                        </definition>
                    </annotations>
                </subState>
                <subState name="pending" parentStateName="normal">
                    <annotations>
                        <definition>
                            <text>
                                <p>The state representing that fact that the role has not yet become
                                    active.</p>
                            </text>
                        </definition>
                    </annotations>
                </subState>
                <subState name="suspended" parentStateName="normal">
                    <annotations>
                        <definition>
                            <text>
                                <p>The state that represents the suspension of the Entity playing
                                    the Role. This state is arrived at from the "active" state.</p>
                            </text>
                        </definition>
                    </annotations>
                </subState>
                <subState name="terminated" parentStateName="normal">
                    <annotations>
                        <definition>
                            <text>
                                <p>The state representing the successful termination of the
                                Role.</p>
                            </text>
                        </definition>
                    </annotations>
                </subState>
                <transition name="revise" startStateName="active" endStateName="active"/>
                <transition name="suspend" startStateName="active" endStateName="suspended"/>
                <transition name="terminate" startStateName="active" endStateName="terminated"/>
                <transition name="nullify" startStateName="normal" endStateName="nullified"/>
                <transition name="create" startStateName="null" endStateName="active"/>
                <transition name="create" startStateName="null" endStateName="pending"/>
                <transition name="activate" startStateName="pending" endStateName="active"/>
                <transition name="cancel" startStateName="pending" endStateName="cancelled"/>
                <transition name="revise" startStateName="pending" endStateName="pending"/>
                <transition name="resume" startStateName="suspended" endStateName="active"/>
                <transition name="revise" startStateName="suspended" endStateName="suspended"/>
                <transition name="terminate" startStateName="suspended" endStateName="terminated"/>
                <transition name="reactivate" startStateName="terminated" endStateName="active"/>
                <transition name="revise" startStateName="terminated" endStateName="terminated"/>
            </behavior>
            <attribute name="classCode" sortKey="1" isStructural="true" minimumMultiplicity="1"
                maximumMultiplicity="1" isMandatory="true">
                <annotations>
                    <definition>
                        <text>
                            <p>A code specifying the major category of a Role as defined by HL7
                                vocabulary.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="RoleClass" codingStrength="CNE"/>
            </attribute>
            <attribute name="id" sortKey="2" minimumMultiplicity="0" maximumMultiplicity="*"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A unique identifier for the player Entity in this Role.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SET">
                    <supplierBindingArgumentDatatype name="II"/>
                </type>
            </attribute>
            <attribute name="code" sortKey="3" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code further specifying the kind of Role.</p>
                            <p>
                                <i>Discussion: </i> The Role.code must conceptually be a proper
                                specialization of Role.classCode. Role.code does not modify
                                Role.classCode. Rather, each is a complete concept or a Role-like
                                relationship between two Entities, but Role.code may be more
                                specific than Role.classCode.</p>
                            <p>The Role.code may not be coded if only an un-coded name for the type
                                of role is commonly used.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="RoleCode" codingStrength="CWE"/>
            </attribute>
            <attribute name="negationInd" sortKey="4" isStructural="true" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>An indicator specifying that the Role is a competency that is
                                specifically not attributed to the Entity playing the Role.</p>
                            <p>
                                <i>Examples:</i> 1.) This Person is <b>not</b> our Employee</p>
                            <p>2.) This Mouthwash does <b>not</b> have Alcohol as an ingredient.</p>
                            <p>Constraint</p>
                            <p>Normally all Roles are considered to be affirmative. (This attribute
                                defaults to FALSE).</p>
                        </text>
                    </definition>
                </annotations>
                <type name="BL"/>
            </attribute>
            <attribute name="name" sortKey="5" minimumMultiplicity="0" maximumMultiplicity="*"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A non-unique textual identifier or moniker for the playing Entity
                                intended for use principally when playing the Role.</p>
                            <p>
                                <i>Examples:</i> Names used as an employee, as a licensed
                                professional, etc.</p>
                            <p>
                                <i>Usage:</i> In general, names are specified using Entity.name.
                                Role.name is only used when the standard wishes to distinguish names
                                that are appropriate for use when referring to the Entity in one
                                Role as opposed to other Roles..</p>
                        </text>
                    </definition>
                </annotations>
                <type name="BAG">
                    <supplierBindingArgumentDatatype name="EN"/>
                </type>
            </attribute>
            <attribute name="addr" sortKey="6" minimumMultiplicity="0" maximumMultiplicity="*"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>An address for the Entity while in the Role.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="BAG">
                    <supplierBindingArgumentDatatype name="AD"/>
                </type>
            </attribute>
            <attribute name="telecom" sortKey="7" minimumMultiplicity="0" maximumMultiplicity="*"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A telecommunication address for the Entity while in the Role.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="BAG">
                    <supplierBindingArgumentDatatype name="TEL"/>
                </type>
            </attribute>
            <attribute name="statusCode" sortKey="8" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code specifying the state of this Role as defined in the
                                state-transition model.</p>
                            <p>
                                <b>Design Advisory: </b>This attribute was defined in the original
                                RIM as repeating, owing to the presence of nested states in the
                                state machines. In actual practice, however, there is never a need
                                to communicate more than a single status value. therefore,
                                committees are advised to <b>constrain this attribute to a maximum
                                    cardinality of 1</b> in all message designs. </p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="RoleStatus" codingStrength="CNE"/>
            </attribute>
            <attribute name="effectiveTime" sortKey="9" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>An interval of time specifying the period during which the Role is in
                                effect, if such time limit is applicable and known.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="IVL">
                    <supplierBindingArgumentDatatype name="TS"/>
                </type>
            </attribute>
            <attribute name="certificateText" sortKey="10" minimumMultiplicity="0"
                maximumMultiplicity="*" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A textual or multimedia depiction of a certificate issued by the
                                scoping Entity of a Role certifying that this Role is indeed played
                                by the player Entity.</p>
                            <p>
                                <i>Examples:</i> The certificate can be represented in many
                                different ways, either inline or by reference, according to the ED
                                data type. Typical cases are:</p>
                            <p>1.) Paper-based certificate: the ED data type may refer to some
                                document or file that can be retrieved through an electronic
                                interface to a hardcopy archive.</p>
                            <p>2.) Electronic certificate: this attribute can represent virtually
                                any electronic certification scheme, such as, an electronically
                                (including digitally) signed electronic text document.</p>
                            <p>3.) Digital certificate (public key certificate): in particular, this
                                attribute can represent digital certificates, as an inline data
                                block or by reference to such data. The certificate data block would
                                be constructed in accordance to a digital certificate standard, such
                                as X509, SPKI, PGP, etc.</p>
                            <p>The certificate subject is the Entity that plays the Role. The
                                certificate issuer is the Entity that scopes the Role.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="ED"/>
            </attribute>
            <attribute name="confidentialityCode" sortKey="11" minimumMultiplicity="0"
                maximumMultiplicity="*" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code that controls the disclosure of information about this Role
                                with respect to the playing Entity..</p>
                            <p>
                                <i>Discussion:</i> It is important to note that the necessary
                                confidentiality of the medical record cannot be achieved solely
                                through confidentiality codes to mask individual record items from
                                certain types of users. There are two important problems with
                                per-item confidentiality: one is inference and the other is the
                                danger of holding back information that may be critical in a certain
                                care situation. Inference means that filtered sensitive information
                                can still be assumed given the other information that was not
                                filtered. The simplest form of inference is that even the existence
                                of a test order for an HIV Western Blot test or a T4/T8 lymphocyte
                                count is a strong indication for an existing HIV infection, even if
                                the results are not known. Very often, diagnoses can be inferred
                                from medication, such as Zidovudin for treatment of HIV infections.
                                The problem of hiding individual items becomes especially difficult
                                with current medications, since the continuing administration of the
                                medication must be assured.</p>
                            <p>To mitigate some of the inference-risk, aggregations of data should
                                assume the confidentiality level of the most confidential action in
                                the aggregation.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SET">
                    <supplierBindingArgumentDatatype name="CE"/>
                </type>
                <supplierDomainSpecification domainName="Confidentiality" codingStrength="CWE"/>
            </attribute>
            <attribute name="quantity" sortKey="12" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A ratio (numerator : denominator) specifying the relative quantities
                                of the Entity playing the Role in the Entity scoping the Role, used
                                for Roles that represent composition relationships between the
                                scoping and playing Entities.</p>
                            <p>
                                <i>Examples:</i> 1.) This syrup's (scoper) ingredients include 160
                                mg (numerator) Acetaminophen (player) per tablespoon (denominator).</p>
                            <p>2.) This herd (scoper) consists of 500 (numerator) cattle (player).</p>
                            <p>3.) A VAX 6630 computer (scoper) has 3 (numerator) CPUs (player) as
                                parts.</p>
                            <p>4.) This package (scoper) contains 100 (numerator) pills (player).</p>
                            <p>
                                <i>Discussion:</i> In composition-relationships (e.g., has-parts,
                                has-ingredient, has-content) the Role.quantity attribute specifies
                                that a numerator amount of the target entity is comprised by a
                                denominator amount of the source entity of such
                                composition-relationship. For example, if a box (source) has-content
                                10 eggs (target), the relationship quantity is 10:1; if 0.6 mL
                                contain 75 mg of FeSO4 the ingredient relationship quantity is 75 mg
                                : 0.6 mL. Both numerator and denominator must be amount quantities
                                (extensive quantities, i.e., a count number, mass, volume, amount of
                                substance, amount of energy, etc.).</p>
                        </text>
                    </definition>
                </annotations>
                <type name="RTO"/>
            </attribute>
            <attribute name="positionNumber" sortKey="13" minimumMultiplicity="0"
                maximumMultiplicity="*" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>An integer specifying the position of the Entity playing the Role
                                with respect to the Entity that scopes the Role.</p>
                            <p>
                                <i>Discussion:</i> This attribute is primarily used with respect to
                                containment roles. For example, some containers have discrete
                                positions in which content may be located. Depending on the geometry
                                of the container, the position may be referenced as a scalar ordinal
                                number, or as a vector of ordinal numbers (coordinates). Coordinates
                                always begin counting at 1.</p>
                            <p>Some containers may have customary ways of referring to the positions
                                or no way at all. In the absence of any specific regulation for a
                                specific container type, the rule of thumb is that the coordinate
                                that is changed earlier is positioned first. For an automated blood
                                chemistry analyzer with a square shaped tray, this means that the
                                first coordinate is the one in which direction the tray moves at
                                each step and the second coordinate is the one in which the tray
                                moves only every 10 (or so) steps.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="LIST">
                    <supplierBindingArgumentDatatype name="INT"/>
                </type>
            </attribute>
            <specializationChild childClassName="Access" sortKey="1"/>
            <specializationChild childClassName="Employee" sortKey="2"/>
            <specializationChild childClassName="LicensedEntity" sortKey="3"/>
            <specializationChild childClassName="Patient" sortKey="4"/>
            <specializationChild childClassName="RoleHeir" sortKey="5"/>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="RoleLink" isAbstract="false">
            <annotations>
                <definition>
                    <text>
                        <p>A connection between two roles expressing a dependency between those
                            roles.</p>
                        <p>
                            <i>Examples:</i> 1.) A role of assignment or agency depends on another
                            role of employment, such that when the employment role is terminated,
                            the assignments would be terminated as well. This is the dependency of
                            the assignment role with the employment role, or in other words, the
                            assignment is "part of" the employment.</p>
                        <p>2.) One role has authority over another (in organizational
                            relationships). For example, an employee of type "manager" may have
                            authority over employees of type "analyst" which would be indicated by a
                            role link for "direct authority".</p>
                        <p>
                            <i>Discussion:</i> RoleLink specifies the relationships between roles,
                            not between people (or other entities). People (or other Entities) are
                            primarily related by their direct player/scoper relationships around the
                            player's Role and more generally through their interactions (i.e. their
                            participations in acts).</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="typeCode" sortKey="1" isStructural="true" minimumMultiplicity="1"
                maximumMultiplicity="1" isMandatory="true">
                <annotations>
                    <definition>
                        <text>
                            <p>A code specifying the kind of connection represented by this
                                RoleLink, e.g., has-part, has-authority.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="RoleLinkType" codingStrength="CNE"/>
            </attribute>
            <attribute name="priorityNumber" sortKey="2" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>An integer specifying the relative preference for considering this
                                relationship before other like-typed relationships having the same
                                source RoleRelationships with lower priorityNumber values are
                                considered before and above those with higher values.</p>
                            <p>
                                <i>Examples:</i> For multiple backups specifies which backup is
                                considered before others. </p>
                            <p>What is the preferred ServiceDeliveryLocation for a Physician working
                                on behalf of a particular Health Authority?</p>
                            <p>
                                <i>Discussion:</i> The ordering may be a total ordering in which all
                                priority numbers are unique or a partial ordering, which assigns the
                                same priority to more than one relationship.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="INT"/>
            </attribute>
            <attribute name="effectiveTime" sortKey="3" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>An interval of time specifying the period during which the connection
                                between Roles is in effect.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="IVL">
                    <supplierBindingArgumentDatatype name="TS"/>
                </type>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="ActHeir" isAbstract="false">
            <annotations>
                <definition>
                    <text>
                        <p>A class defined solely as a work-around for the lack of support of the
                            reflexive closure of generalization relationships (i.e. "Act is-a Act")
                            by the current set of tools. </p>
                        <p>
                            <i>Examples:</i> Consider a refined message information model (RMIM)
                            contains Act with the specializations of Observation and
                            PatientEducationAct, where PatientEducationAct is conceptually a direct
                            specialization ("clone") of Act. In this case, the ActHeir class is used
                            as the basis of the PatientEducationAct clone rather than the Act RIM
                            class itself. The Act RIM class is used here only to represent the
                            common generalization of Observation and PatientEducationAct. This use
                            is entirely dictated by the (excusable) shortcomings of certain tools
                            and data-structures used in the HL7 methodology, and have no conceptual
                            meaning. </p>
                        <p>
                            <i>Discussion:</i> Notably, although it is used to represent Acts that
                            are not otherwise sub-classed in the RIM, the ActHeir class does not
                            reflect any conceptual modeling principle according to which
                            generalizations must all be abstract and only leaf-specializations (like
                            ActHeir) could be instantiated. This is not what ActHeir conveys; it is
                            simply and only a work-around practical tooling problems and subsequent
                            evolution of the tooling may permit the elimination of these classes in
                            favor of an equivalent abstraction in the methodology.</p>
                        <p>Note that EntityHeir and RoleHeir have the same use for Entity and Role
                            respectively.</p>
                    </text>
                </definition>
            </annotations>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="EntityHeir" isAbstract="false">
            <annotations>
                <definition>
                    <text>
                        <p>A subtype of Entity defined solely as a work-around for the lack of
                            support of the reflexive closure of generalization relationships (i.e.
                            "Entity is-an Entity") by the current set of tools. </p>
                        <p>
                            <i>Examples:</i> A refined message information model (RMIM) contains
                            Entity with the specializations of EnvironmentalEntity, and
                            LivingSubject, where EnvironmentalEntity is conceptually a direct
                            specialization ("clone") of Entity. In this case, the EntityHeir class
                            is used as the basis of the EnvironmentalEntity clone rather than the
                            Entity RIM class itself. The Entity RIM class is used only to represent
                            the common generalization of Observation and EnvironmentalEntity. </p>
                        <p>
                            <i>Discussion:</i> Notably, although it is used to represent Entities
                            that are not otherwise sub-classed in the RIM, the EntityHeir class does
                            not reflect any conceptual modeling principle according to which
                            generalizations must all be abstract and only leaf-specializations (like
                            EntityHeir) could be instantiated. This is not what EntityHeir conveys;
                            it is only a work-around for practical tooling problems. Subsequent
                            evolution of the tooling may permit the elimination of these classes in
                            favor of an equivalent abstraction in the methodology.</p>
                        <p>
                            <i>Rationale:</i> This use is entirely dictated by the (excusable)
                            shortcomings of certain tools and data-structures used in the HL7
                            methodology, and have no conceptual meaning. Note that ActHeir and
                            RoleHeir have the same use for Act and Role respectively.</p>
                        <p>
                            <i>Rationale:</i> It has been discovered that one cannot create an HMD
                            choice structure for a set of classes, all of which are sub-types of
                            Act, Role or Entity, but for which there is not a defined physical
                            class. These are the classes that would have been in the RIM as direct
                            descendants (heirs) of Act, Role and Entity, except for the fact that
                            they carried no unique attributes or associations. </p>
                        <p>The addition of this single empty class in each hierarchy will permit
                            messages with the appropriate and necessary choice structures to be
                            built. Subsequent evolution of the methodology and tooling may permit
                            the elimination of these classes in favor of an equivalent abstraction
                            in the methodology.</p>
                    </text>
                </definition>
            </annotations>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="InfrastructureRoot" isAbstract="false">
            <annotations>
                <definition>
                    <text>
                        <p>This abstract class is a super-type for all RIM classes, either directly
                            or through inheritance. It provides a set of communication
                            infrastructure attributes that may be used in instances of
                            HL7-specified, RIM-based communications. When valued in a communication
                            instance, these attributes indicate whether the information structure is
                            being constrained by specifically defined templates, realms or common
                            communication element types.</p>
                        <p>In general, constraint declarations, such as those communicated in this
                            class's attributes, may occur wherever a RIM class or one of its derived
                            clones is instantiated in an HL7 communication. Thus the attributes must
                            be available in all RIM classes and clones.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="nullFlavor" sortKey="1" isStructural="true" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>When valued in an instance, this attribute signals that the class
                                instance is null, and that the remainder of the information for this
                                class and its properties will not be communicated. The value of this
                                attribute specifies the flavor of null that is intended.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="NullFlavor" codingStrength="CNE"/>
            </attribute>
            <attribute name="realmCode" sortKey="2" minimumMultiplicity="0" maximumMultiplicity="*"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>When valued in an instance, this attribute signals the imposition of
                                realm-specific constraints. The value of this attribute identifies
                                the realm in question.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SET">
                    <supplierBindingArgumentDatatype name="CS"/>
                </type>
                <supplierDomainSpecification domainName="Realm" codingStrength="CNE"/>
            </attribute>
            <attribute name="typeId" sortKey="3" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>When valued in an instance, this attribute signals the imposition of
                                constraints defined in an HL7-specified message type. This might be
                                a common type (also known as CMET in the messaging communication
                                environment), or content included within a wrapper. The value of
                                this attribute provides a unique identifier for the type in
                                question.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="II"/>
            </attribute>
            <attribute name="templateId" sortKey="4" minimumMultiplicity="0" maximumMultiplicity="*"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>When valued in an instance, this attribute signals the imposition of
                                a set of template-defined constraints. The value of this attribute
                                provides a unique identifier for the templates in question.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="LIST">
                    <supplierBindingArgumentDatatype name="II"/>
                </type>
            </attribute>
            <specializationChild childClassName="Act" sortKey="1"/>
            <specializationChild childClassName="ActRelationship" sortKey="2"/>
            <specializationChild childClassName="Participation" sortKey="3"/>
            <specializationChild childClassName="Entity" sortKey="4"/>
            <specializationChild childClassName="LanguageCommunication" sortKey="5"/>
            <specializationChild childClassName="Role" sortKey="6"/>
            <specializationChild childClassName="RoleLink" sortKey="7"/>
            <specializationChild childClassName="Acknowledgement" sortKey="8"/>
            <specializationChild childClassName="AttentionLine" sortKey="9"/>
            <specializationChild childClassName="CommunicationFunction" sortKey="10"/>
            <specializationChild childClassName="Transmission" sortKey="11"/>
            <specializationChild childClassName="Parameter" sortKey="12"/>
            <specializationChild childClassName="QueryEvent" sortKey="13"/>
            <specializationChild childClassName="SelectionExpression" sortKey="14"/>
            <specializationChild childClassName="SortControl" sortKey="15"/>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="RoleHeir" isAbstract="false">
            <annotations>
                <definition>
                    <text>
                        <p>A class defined solely as a work-around for the lack of support of the
                            reflexive closure of generalization relationships (i.e. "Role is-a
                            Role") by the current set of tools.</p>
                        <p>
                            <i>Examples:</i> Consider a refined message information model (RMIM)
                            contains Role with the specializations of Employee and Member, where
                            Member is conceptually a direct specialization ("clone") of Role. In
                            this case, the RoleHeir class is used as the basis of the Member clone
                            rather than the Role RIM class itself. The Role RIM class is used here
                            only to represent the common generalization of Employee and Member. This
                            use is entirely dictated by the (excusable) shortcomings of certain
                            tools and data-structures used in the HL7 methodology, and have no
                            conceptual meaning.</p>
                        <p>
                            <i>Discussion:</i> Notably, although it is used to represent Roles that
                            are not otherwise sub-classed in the RIM, the RoleHeir class does not
                            reflect any conceptual modeling principle according to which
                            generalizations must all be abstract and only leaf-specializations (like
                            RoleHeir) could be instantiated. This is not what RoleHeir conveys; it
                            is simply and only a work-around practical tooling problems and
                            subsequent evolution of the tooling may permit the elimination of these
                            classes in favor of an equivalent abstraction in the methodology. Note
                            that EntityHeir and ActHeir have the same use for Entity and Act
                            respectively.</p>
                    </text>
                </definition>
            </annotations>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="Acknowledgement" isAbstract="false">
            <annotations>
                <definition>
                    <text>
                        <p>The Acknowledgement class contains information sent when acknowledging
                            another message.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="typeCode" sortKey="1" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>This attribute contains an acknowledgement code as described in the
                                HL7 message processing rules.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="AcknowledgementType" codingStrength="CNE"/>
            </attribute>
            <attribute name="expectedSequenceNumber" sortKey="2" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>This attribute is used in the sequence number protocol.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="INT"/>
            </attribute>
            <attribute name="messageWaitingNumber" sortKey="3" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Indicates the number of messages the acknowledging application has
                                waiting on a queue for the receiving application.</p>
                            <p>Discussion: These messages would then need to be retrieved via a
                                query. This facilitates receiving applications that cannot receive
                                unsolicited message (i.e. polling).</p>
                            <p>Examples: If there are 3 low priority messages, 1 medium priority
                                message and 1 high priority message, the message waiting number
                                would be 5, because that is the total number of messages.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="INT"/>
            </attribute>
            <attribute name="messageWaitingPriorityCode" sortKey="4" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Indicates the highest importance level of the set of messages the
                                acknowledging application has waiting on a queue for the receiving
                                application.</p>
                            <p>Discussion: These messages would need to be retrieved via a query.
                                This facilitates receiving applications that cannot receive
                                unsolicited messages (i.e. polling). The specific code specified
                                identifies how important the most important waiting message is (and
                                may govern how soon the receiving application is required to poll
                                for the message).</p>
                            <p>Priority may be used by local agreement to determine the timeframe in
                                which the receiving application is expected to retrieve the messages
                                from the queue.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="MessageWaitingPriority"
                    codingStrength="CWE"/>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="AcknowledgementDetail" isAbstract="false">
            <annotations>
                <definition>
                    <text>
                        <p>A message that provides information about the communication, parsing or
                            non-business-rule validation of the message being acknowledged.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="typeCode" sortKey="1" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Identifies the kind of information specified in the acknowledgement
                                message. Options are: Error, Warning or Information.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="AcknowledgementDetailType"
                    codingStrength="CNE"/>
            </attribute>
            <attribute name="code" sortKey="2" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code identifying the specific message to be provided.</p>
                            <p>Discussion: A textual value may be specified as the print name, or
                                for non-coded messages, as the original text.</p>
                            <p>Examples: 'Required attribute xxx is missing', 'System will be
                                unavailable March 19 from 0100 to 0300'</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="AcknowledgementDetailCode"
                    codingStrength="CWE"/>
            </attribute>
            <attribute name="text" sortKey="3" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Identifies additional diagnostic information relevant to the message.</p>
                            <p>Discussion: This may be free text or structured data (e.g. XML).</p>
                            <p>Examples: Java exception, memory dump, internal error code,
                                call-stack information, etc.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="ED"/>
            </attribute>
            <attribute name="location" sortKey="4" minimumMultiplicity="0" maximumMultiplicity="*"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Identifies a position within the message being acknowledged that is
                                related to the message.</p>
                            <p>Discussion: Not all messages will have an associated location. Some
                                messages may relate to multiple locations.</p>
                            <p>Example: There is no location for a missing element, and there may be
                                two locations if two elements violate a conditionality
                            constraint.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SET">
                    <supplierBindingArgumentDatatype name="ST"/>
                </type>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="Attachment" isAbstract="false">
            <attribute name="id" sortKey="1" minimumMultiplicity="1" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A unique identifier for the Attachment.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="II"/>
            </attribute>
            <attribute name="text" sortKey="2" minimumMultiplicity="1" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The semantic content of the attachment.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="ED"/>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="AttentionLine" isAbstract="false">
            <annotations>
                <definition>
                    <text>
                        <p>This class allows parameters for a technology specific transport to be
                            represented in the V3 message outer wrapper.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="keyWordText" sortKey="1" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A parameter defining word.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SC"/>
                <supplierDomainSpecification domainName="AttentionKeyword" codingStrength="CWE"/>
            </attribute>
            <attribute name="value" sortKey="2" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>
                                <b>OpenIssue:</b> Control-Query agreed to provide new definition
                                that includes a strong set of constraints on the data tpes that this
                                attribute can assume. Pending the delivery of that description, it
                                was agreed in harmonization to drop the proposed description.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="ANY"/>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="Batch" isAbstract="false">
            <annotations>
                <definition>
                    <text>
                        <p>The Batch class is used to specify a message which is a collection of HL7
                            V3 messages.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="versionCode" sortKey="1" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>This attribute is matched by the receiving system to its own version
                                to be sure the message will be interpreted correctly.</p>
                            <p>
                                <i>Note:</i> This attribute is also present in the sibling class,
                                Batch. This change was made rather than moving this attribute to
                                their common ancestor class, Transmission. This decision was taken
                                because we do not have all the methodology and backwards
                                compatibility issues worked out. Once we have established our
                                backwards compatibility, we should promote this attribute to the
                                parent. The problem is the sequencing of attributes within the HDF
                                and their impact on the ITSs.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="HL7StandardVersionCode"
                    codingStrength="CNE"/>
            </attribute>
            <attribute name="interactionId" sortKey="2" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The interaction identifier is a reference to the unique information
                                interchange derived from the V3 MDF for specifying a message.</p>
                            <p>
                                <i>Note:</i> This attribute is also present in the sibling class,
                                Message. This change was made rather than moving this attribute to
                                their common ancestor class, Transmission. This decision was taken
                                because we do not have all the methodology and backwards
                                compatibility issues worked out. Once we have established our
                                backwards compatibility, we should promote this attribute to the
                                parent. The problem is the sequencing of attributes within the HDF
                                and their impact on the ITSs.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="II"/>
            </attribute>
            <attribute name="referenceControlId" sortKey="3" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>This attribute indicates the control identifier of the batch when it
                                was originally transmitted.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="II"/>
            </attribute>
            <attribute name="name" sortKey="4" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>This attribute is used by the application processing the batch.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SC"/>
                <supplierDomainSpecification domainName="BatchName" codingStrength="CWE"/>
            </attribute>
            <attribute name="batchComment" sortKey="5" minimumMultiplicity="0"
                maximumMultiplicity="*" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>This attribute is available to capture comments related to the
                            batch.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SET">
                    <supplierBindingArgumentDatatype name="ST"/>
                </type>
            </attribute>
            <attribute name="transmissionQuantity" sortKey="6" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>This attribute contains the count of individual transmissions
                                contained within the batch.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="INT"/>
            </attribute>
            <attribute name="batchTotalNumber" sortKey="7" minimumMultiplicity="0"
                maximumMultiplicity="*" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The batch total. It is possible that more than a single batch total
                                exists.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SET">
                    <supplierBindingArgumentDatatype name="INT"/>
                </type>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="CommunicationFunction" isAbstract="false">
            <annotations>
                <definition>
                    <text>
                        <p>Relationship class binds the various entities which function in the
                            transmission (sender, receiver, respond-to) to be linked to the
                            transmission.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="typeCode" sortKey="1" isStructural="true" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The type of communication function being served by the entity with
                                respect to the transmission, such as sender, receiver, respond-to
                                party, etc.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="CommunicationFunctionType"
                    codingStrength="CNE"/>
            </attribute>
            <attribute name="telecom" sortKey="2" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The telecomm address that can be used to reach the entity that is
                                serving this function.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="TEL"/>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="Message" isAbstract="false">
            <annotations>
                <definition>
                    <text>
                        <p>The Message class is the parent class of all HL7 Version 3 messages.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="versionCode" sortKey="1" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>This attribute is matched by the receiving system to its own version
                                to be sure the message will be interpreted correctly.</p>
                            <p>
                                <i>Note:</i> This attribute is also present in the sibling class,
                                Message. This change was made rather than moving this attribute to
                                their common ancestor class, Transmission. This decision was taken
                                because we do not have all the methodology and backwards
                                compatibility issues worked out. Once we have established our
                                backwards compatibility, we should promote this attribute to the
                                parent. The problem is the sequencing of attributes within the HDF
                                and their impact on the ITSs.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="HL7StandardVersionCode"
                    codingStrength="CNE"/>
            </attribute>
            <attribute name="interactionId" sortKey="2" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The interaction identifier is a reference to the unique information
                                interchange derived from the V3 MDF for specifying a message.</p>
                            <p>
                                <i>Note:</i> This attribute is also present in the sibling class,
                                Batch. This change was made rather than moving this attribute to
                                their common ancestor class, Transmission. This decision was taken
                                because we do not have all the methodology and backwards
                                compatibility issues worked out. Once we have established our
                                backwards compatibility, we should promote this attribute to the
                                parent. The problem is the sequencing of attributes within the HDF
                                and their impact on the ITSs.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="II"/>
            </attribute>
            <attribute name="profileId" sortKey="3" minimumMultiplicity="0" maximumMultiplicity="*"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The message profile identifier allows a given implementation to
                                explicitly state how it varies from the standard message definition.</p>
                            <p>When multiple profiles are specified, the message instance must be
                                valid against all of them. However, a receiver may choose to
                                validate against only the first one recognized. For this reason,
                                'preferred' or more-rigorous profiles should be listed first.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="LIST">
                    <supplierBindingArgumentDatatype name="II"/>
                </type>
            </attribute>
            <attribute name="processingCode" sortKey="4" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>This attribute defines whether the message is part of a production,
                                training, or debugging system.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="ProcessingID" codingStrength="CNE"/>
            </attribute>
            <attribute name="processingModeCode" sortKey="5" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>This attribute defines whether the message is being sent in current
                                processing, archive mode, initial load mode, restore from archive
                                mode, etc.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="ProcessingMode" codingStrength="CNE"/>
            </attribute>
            <attribute name="acceptAckCode" sortKey="6" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The attribute identifies the conditions under which accept
                                acknowledgements are required to be returned in response to this
                                message.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="AcknowledgementCondition"
                    codingStrength="CNE"/>
            </attribute>
            <attribute name="responseCode" sortKey="7" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Specifies whether an application response is expected from the
                                addressee of this interaction and what level of detail that response
                                should include. This attribute restricts the default response
                                options specified by the receiver responsibilities for the
                                interaction. For example, if an interaction has receiver
                                responsibilities to send either an accept interaction or a refuse
                                interaction, and the responseCode is set to 'E' - Exception, the
                                receiver should only respond if they refuse.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="ResponseLevel" codingStrength="CNE"/>
            </attribute>
            <attribute name="sequenceNumber" sortKey="8" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>This attribute is provided for implementing the sequence number
                                protocol. This field is incremented by one for each subsequent value
                                assignment.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="INT"/>
            </attribute>
            <attribute name="attachmentText" sortKey="9" minimumMultiplicity="0"
                maximumMultiplicity="*" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Contains arbitrary attachments of data blocks to which can be
                                referred to from the interior of the message. Any ITS is advised to
                                represent the attachments behind the main message body. Attachments
                                are referred to from the message body using the reference
                                functionality of the ED data type.</p>
                            <p>OpenIssue: Constrain the use of the ED data type in the attachment
                                message type. Additionally, the appropriateness of this attribute in
                                the Message class is in question. An alternative to consider would
                                be the placement of this attribute in a new class maintaining a 0 to
                                many relationship with the Message class.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SET">
                    <supplierBindingArgumentDatatype name="ED"/>
                </type>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="Transmission" isAbstract="false">
            <annotations>
                <definition>
                    <text>
                        <p>Represents information about a specific transmission of information from
                            one application to another.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="id" sortKey="1" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Unique identifier of the transmission.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="II"/>
            </attribute>
            <attribute name="creationTime" sortKey="2" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The date/time that the sending system created the transmission. If
                                the time zone is specified, it will be used throughout the
                                transmission as the default time zone.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="TS"/>
            </attribute>
            <attribute name="securityText" sortKey="3" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>This attribute is specified for applications to implement security
                                features for a transmission. Its use is not further specified at
                                this time.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="ST"/>
            </attribute>
            <attribute name="responseModeCode" sortKey="4" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>This attribute defines the transmission mode with which a receiver
                                should communicate its receiver responsibilities, i.e. the expected
                                dynamic behavior of the receiving application with regard to
                                application response transmissions.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="ResponseMode" codingStrength="CNE"/>
            </attribute>
            <specializationChild childClassName="Batch" sortKey="1"/>
            <specializationChild childClassName="Message" sortKey="2"/>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="LogicalExpression" isAbstract="false">
            <attribute name="relationalConjunctionCode" sortKey="1" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>When more than one criteria is to be applied in the evaluation of
                                candidate instances, a conjunction is supplied to identify how to
                                relate an additional criteria.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="SQLConjunction" codingStrength="CNE"/>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="Parameter" isAbstract="true">
            <annotations>
                <definition>
                    <text>
                        <p>The Parameter class is an implementation class that represents the
                            structure of parameters that may be specified with the
                            Query-by-parameter mechanisms of the V3 query framework. Parameters may
                            be set of name/value pairs, a named parameter list with a set of
                            name/value pairs or any combination the previous two options.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="id" sortKey="1" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The Parameter.id can assist in tracing problems with implementing the
                                query-by-parameter mechanism.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="II"/>
            </attribute>
            <specializationChild childClassName="ParameterItem" sortKey="1"/>
            <specializationChild childClassName="ParameterList" sortKey="2"/>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="ParameterItem" isAbstract="false">
            <annotations>
                <definition>
                    <text>
                        <p>Represents a valued element structure (name-value pair) for the element
                            specified in the query response.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="value" sortKey="1" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Provides the value for the valued element structure (name-value pair)
                                for the element specified in the query response.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="ANY"/>
            </attribute>
            <attribute name="semanticsText" sortKey="2" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Provides a unique identification (the name of the name-value pair) to
                                an element within a specified query response structure.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="ST"/>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="ParameterList" isAbstract="false">
            <annotations>
                <definition>
                    <text>
                        <p>Specifies a named list of parameters (name/value pairs) that is
                            referenced in a query conformance statement.</p>
                    </text>
                </definition>
            </annotations>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="QueryAck" isAbstract="false">
            <annotations>
                <definition>
                    <text>
                        <p>This class carries information sent with responses to a query.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="queryResponseCode" sortKey="1" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>This attribute allows the responding system to return a precise
                                response status.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="QueryResponse" codingStrength="CNE"/>
            </attribute>
            <attribute name="resultTotalQuantity" sortKey="2" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Specifies total number of instance matches for query specification
                                associated with this query response instance.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="INT"/>
            </attribute>
            <attribute name="resultCurrentQuantity" sortKey="3" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Specifies number of matches for processed query specification that
                                occur in current bundle of matches.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="INT"/>
            </attribute>
            <attribute name="resultRemainingQuantity" sortKey="4" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Specifies number of matches for processed query specification that
                                have yet to be sent to receiver.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="INT"/>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="QueryByParameter" isAbstract="false">
            <annotations>
                <definition>
                    <text>
                        <p>This class contains the definition of a Query by Parameter, an HL7 query
                            format proposed to replace the QRD/QRF query format. The query format is
                            considered a closed query because a data server specifies a fixed list
                            of parameters published in a query conformance statement.</p>
                    </text>
                </definition>
            </annotations>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="QueryBySelection" isAbstract="false">
            <annotations>
                <definition>
                    <text>
                        <p>This class contains the definition of a Query by Selection. This is an
                            HL7 query in which a request can specify any or all of the variables
                            offered by a data server and may additionally specify any permissible
                            operators and values for each variable as published in a query
                            conformance statement. This query format is considered an open query
                            because it allows a selection specification against a published data
                            base schema.</p>
                    </text>
                </definition>
            </annotations>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="QueryContinuation" isAbstract="false">
            <annotations>
                <definition>
                    <text>
                        <p>This class maintains the state information required at the application
                            level to control the logical continuation of a query response.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="startResultNumber" sortKey="1" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Specifies the instance number in the original query result set to
                                start return in next query response message.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="INT"/>
            </attribute>
            <attribute name="continuationQuantity" sortKey="2" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Specifies the number of instance matches to return in the next query
                                response message.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="INT"/>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="QueryEvent" isAbstract="false">
            <annotations>
                <definition>
                    <text>
                        <p>This abstract class is used to gather the parts of a message interaction
                            that are specific to a query message interaction.</p>
                        <p>Rationale: A message element type is defined by a TC to meet a messaging
                            requirement for a query response (like the response message element type
                            for a demographics query). An instance of such a message element type
                            would be represented as a query message interaction in this revised view
                            of the V3 query/response model. The "return_element_group" would
                            identify the RIM view that would be similar in form to the RIM view
                            specified in a declarative or imperative application message
                            interaction.</p>
                    </text>
                </definition>
            </annotations>
            <behavior supplierStateAttributeName="statusCode">
                <figure>
                    <fixedImage>
                        <pixmap href="./Graphics/RIM_QueryEventStatus.gif"/>
                    </fixedImage>
                </figure>
                <subState name="aborted"/>
                <subState name="deliveredResponse"/>
                <subState name="executing"/>
                <subState name="new"/>
                <subState name="null"/>
                <subState name="waitContinuedQueryResponse"/>
                <transition name="abort" startStateName="deliveredResponse" endStateName="aborted"/>
                <transition name="activateQueryContinue" startStateName="deliveredResponse"
                    endStateName="executing"/>
                <transition name="abort" startStateName="executing" endStateName="aborted"/>
                <transition name="completeInitialQueryResponse" startStateName="executing"
                    endStateName="deliveredResponse"/>
                <transition name="completeQueryContinuation" startStateName="executing"
                    endStateName="deliveredResponse"/>
                <transition name="executeQuerySpec" startStateName="new" endStateName="executing"/>
                <transition name="create" startStateName="null" endStateName="new"/>
            </behavior>
            <attribute name="queryId" sortKey="1" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>This attribute may be valued by the initiating application to
                                identify the query. It is intended to be used to match response
                                messages to the originating query. QueryEvent.queryId may remain the
                                same across multiple interactions when performing continuations of a
                                previous query.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="II"/>
            </attribute>
            <attribute name="statusCode" sortKey="2" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <type name="CS"/>
                <supplierDomainSpecification domainName="QueryStatusCode" codingStrength="CNE"/>
            </attribute>
            <specializationChild childClassName="QueryAck" sortKey="1"/>
            <specializationChild childClassName="QueryContinuation" sortKey="2"/>
            <specializationChild childClassName="QuerySpec" sortKey="3"/>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="QuerySpec" isAbstract="false">
            <annotations>
                <definition>
                    <text>
                        <p>This class contains the specification of all HL7 Version 3 queries.
                            Attributes common to all queries appear in this class specification.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="modifyCode" sortKey="1" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Indicates whether the subscription to a query is new or is being
                                modified.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="ModifyIndicator" codingStrength="CNE"/>
            </attribute>
            <attribute name="responseElementGroupId" sortKey="2" minimumMultiplicity="0"
                maximumMultiplicity="*" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>The responseElementGroupId identifies the specific message type to be
                                returned in the query response. This message type must be chosen
                                from the set of message types supported by the receiver
                                responsibilities associated with the query interaction.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SET">
                    <supplierBindingArgumentDatatype name="II"/>
                </type>
            </attribute>
            <attribute name="responseModalityCode" sortKey="3" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Defines the timing and grouping of the response instances.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="ResponseModality" codingStrength="CNE"/>
            </attribute>
            <attribute name="responsePriorityCode" sortKey="4" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Identifies the time frame in which the response is expected.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="QueryPriority" codingStrength="CNE"/>
            </attribute>
            <attribute name="initialQuantity" sortKey="5" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Defines the maximum size of the response that can be accepted by the
                                requesting application.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="INT"/>
            </attribute>
            <attribute name="initialQuantityCode" sortKey="6" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Defines the units associated with the magnitude of the maximum size
                                limit of a query response that can be accepted by the requesting
                                application</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="QueryRequestLimit" codingStrength="CWE"/>
            </attribute>
            <attribute name="executionAndDeliveryTime" sortKey="7" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Specifies the time the response is to be returned.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="TS"/>
            </attribute>
            <specializationChild childClassName="QueryByParameter" sortKey="1"/>
            <specializationChild childClassName="QueryBySelection" sortKey="2"/>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="RelationalExpression" isAbstract="false">
            <attribute name="elementName" sortKey="1" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Identifies RIM element as subject of selection criteria
                            evaluation.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SC"/>
                <supplierDomainSpecification domainName="RelationalName" codingStrength="CWE"/>
            </attribute>
            <attribute name="relationalOperatorCode" sortKey="2" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Identifies common relational operators used in selection
                            criteria.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="RelationalOperator" codingStrength="CNE"/>
            </attribute>
            <attribute name="value" sortKey="3" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Value supplied for comparison using criteria.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="ST"/>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="SelectionExpression" isAbstract="true">
            <specializationChild childClassName="LogicalExpression" sortKey="1"/>
            <specializationChild childClassName="RelationalExpression" sortKey="2"/>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="SortControl" isAbstract="false">
            <annotations>
                <definition>
                    <text>
                        <p>Holds specification of sort order for instance matches to a query.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="sequenceNumber" sortKey="1" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Provides the sequence or primacy of the various SortControls for a
                                given query.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="INT"/>
            </attribute>
            <attribute name="elementName" sortKey="2" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Identifies a RIM element in a query response upon which to sort.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SC"/>
                <supplierDomainSpecification domainName="ElementName" codingStrength="CWE"/>
            </attribute>
            <attribute name="directionCode" sortKey="3" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Specifies direction (ascending or descending) of the sort.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CS"/>
                <supplierDomainSpecification domainName="Sequencing" codingStrength="CNE"/>
            </attribute>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="ContextStructure" isAbstract="false">
            <supplierStructuralDomain mnemonic="COMPOSITION"/>
            <annotations>
                <definition>
                    <text>
                        <p>A structure is a container within a document. Structures have captions
                            which can be coded. Structures can nest, and structures can contain
                            entries.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="setId" sortKey="1" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A report identifier that remains constant across all revisions that
                                derive from a common original. </p>
                            <p>An original report is the first version of a report. It gets a new
                                unique value for <i>setId</i>, and has the value of <i>versionNumber
                                </i>set to equal "1". </p>
                            <p>An addendum is an appendage to an existing report that contains
                                supplemental information. The appendage is itself an original
                                report. The parent report being appended is referenced via an
                                    <i>ActRelationship</i>, with <i>ActRelationship.typeCode</i> set
                                to equal "APND" (for "appends"). The parent report being appended
                                remains in place and its content and status are unaltered. </p>
                            <p>A replacement report replaces an existing report. The replacement
                                report uses the same value for <i>setId </i>as the parent report
                                being replaced, and increments the value of <i>versionNumber </i>by
                                1. The state of the parent report being replaced should become
                                "superceded", but is still retained in the system for historical
                                reference.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="II"/>
            </attribute>
            <attribute name="versionNumber" sortKey="2" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Version number is an integer starting at '1' and incrementing by 1.
                                The first instance or original report should always be valued as
                                '1'. The version number value must be incremented by one when a
                                report is replaced, but can also be incremented more often to meet
                                local requirements.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="INT"/>
            </attribute>
            <specializationChild childClassName="Document" sortKey="1"/>
        </class>
    </ownedClass>
    <ownedClass>
        <class name="Document" isAbstract="false">
            <supplierStructuralDomain mnemonic="DOC"/>
            <annotations>
                <definition>
                    <text>
                        <p>Specialization of Act to add the characteristics unique to document
                            management services.</p>
                    </text>
                </definition>
            </annotations>
            <attribute name="completionCode" sortKey="1" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code depicting the completion status of a report (e.g., incomplete,
                                authenticated, legally authenticated).</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="DocumentCompletion" codingStrength="CWE"/>
            </attribute>
            <attribute name="storageCode" sortKey="2" minimumMultiplicity="0"
                maximumMultiplicity="1" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>A code depicting the storage status (e.g., active, archived, purged)
                                of a report.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="CE"/>
                <supplierDomainSpecification domainName="DocumentStorage" codingStrength="CWE"/>
            </attribute>
            <attribute name="copyTime" sortKey="3" minimumMultiplicity="0" maximumMultiplicity="1"
                isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Time a document is released (i.e., copied or sent to a display
                                device) from a document management system that maintains revision
                                control over the document. Once valued, cannot be changed. Intent of
                                this attribute is to give the viewer of the document some notion as
                                to how long the document has been out of the safe context of its
                                document management system.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="TS"/>
            </attribute>
            <attribute name="bibliographicDesignationText" sortKey="4" minimumMultiplicity="0"
                maximumMultiplicity="*" isMandatory="false">
                <annotations>
                    <definition>
                        <text>
                            <p>Citation for a cataloged document that permits its identification,
                                location and/or retrieval from common collections.</p>
                        </text>
                    </definition>
                </annotations>
                <type name="SET">
                    <supplierBindingArgumentDatatype name="ED"/>
                </type>
            </attribute>
        </class>
    </ownedClass>
    <ownedAssociation>
        <annotations>
            <definition>
                <text>
                    <p>Identifies the relationship between an acknowledgment and the error, warning
                        and informational detail accompanying that acknowledgment.</p>
                </text>
            </definition>
        </annotations>
        <connections>
            <traversableConnection name="acknowledgementDetail" minimumMultiplicity="1"
                maximumMultiplicity="1" participantClassName="AcknowledgementDetail" sortKey="B"/>
            <traversableConnection name="acknowledgement" minimumMultiplicity="0"
                maximumMultiplicity="*" participantClassName="Acknowledgement" sortKey="Z"/>
        </connections>
    </ownedAssociation>
    <ownedAssociation>
        <annotations>
            <definition>
                <text>
                    <p>Identifies the relationship between a transmission and the acknowledgements
                        that acknowledge that transmission.</p>
                </text>
            </definition>
        </annotations>
        <connections>
            <traversableConnection name="acknowledges" minimumMultiplicity="0"
                maximumMultiplicity="*" participantClassName="Transmission" sortKey="A"/>
            <traversableConnection name="acknowledgedBy" minimumMultiplicity="1"
                maximumMultiplicity="1" participantClassName="Acknowledgement" sortKey="C"/>
        </connections>
    </ownedAssociation>
    <ownedAssociation>
        <annotations>
            <definition>
                <text>
                    <p>Identifies the relationship between an acknowledgment and the transmission
                        conveying that acknowledgement.</p>
                </text>
            </definition>
        </annotations>
        <connections>
            <traversableConnection name="conveyingTransmission" minimumMultiplicity="0"
                maximumMultiplicity="*" participantClassName="Transmission" sortKey="Z"/>
            <traversableConnection name="conveyedAcknowledgement" minimumMultiplicity="1"
                maximumMultiplicity="1" participantClassName="Acknowledgement" sortKey="D"/>
        </connections>
    </ownedAssociation>
    <ownedAssociation>
        <connections>
            <traversableConnection name="source" minimumMultiplicity="0" maximumMultiplicity="*"
                participantClassName="Act" sortKey="A"/>
            <traversableConnection name="outboundRelationship" minimumMultiplicity="1"
                maximumMultiplicity="1" participantClassName="ActRelationship" sortKey="B"/>
        </connections>
    </ownedAssociation>
    <ownedAssociation>
        <connections>
            <traversableConnection name="target" minimumMultiplicity="0" maximumMultiplicity="*"
                participantClassName="Act" sortKey="B"/>
            <traversableConnection name="inboundRelationship" minimumMultiplicity="1"
                maximumMultiplicity="1" participantClassName="ActRelationship" sortKey="C"/>
        </connections>
    </ownedAssociation>
    <ownedAssociation>
        <connections>
            <traversableConnection name="transmission" minimumMultiplicity="0"
                maximumMultiplicity="*" participantClassName="Transmission" sortKey=""/>
            <traversableConnection name="attachment" minimumMultiplicity="0" maximumMultiplicity="1"
                participantClassName="Attachment" sortKey=""/>
        </connections>
    </ownedAssociation>
    <ownedAssociation>
        <annotations>
            <definition>
                <text>
                    <p>This relationship allows parameters for a technology-specific transport to be
                        represented in the V3 transmission outer wrapper.</p>
                </text>
            </definition>
        </annotations>
        <connections>
            <traversableConnection name="transmission" minimumMultiplicity="0"
                maximumMultiplicity="*" participantClassName="Transmission" sortKey="Z"/>
            <traversableConnection name="attentionLine" minimumMultiplicity="1"
                maximumMultiplicity="1" participantClassName="AttentionLine" sortKey="B"/>
        </connections>
    </ownedAssociation>
    <ownedAssociation>
        <connections>
            <traversableConnection name="transmission" minimumMultiplicity="0"
                maximumMultiplicity="1" participantClassName="Transmission" sortKey="Z"/>
            <traversableConnection name="batch" minimumMultiplicity="0" maximumMultiplicity="*"
                participantClassName="Batch" sortKey="Z"/>
        </connections>
    </ownedAssociation>
    <ownedAssociation>
        <connections>
            <traversableConnection name="payload" minimumMultiplicity="0" maximumMultiplicity="*"
                participantClassName="Message" sortKey="B"/>
            <traversableConnection name="controlAct" minimumMultiplicity="0" maximumMultiplicity="1"
                participantClassName="ControlAct" sortKey="Z"/>
        </connections>
    </ownedAssociation>
    <ownedAssociation>
        <annotations>
            <definition>
                <text>
                    <p>This relationship allows the entities playing the various communication
                        functions to be identified.</p>
                </text>
            </definition>
        </annotations>
        <connections>
            <traversableConnection name="communicationFunction" minimumMultiplicity="1"
                maximumMultiplicity="*" participantClassName="CommunicationFunction" sortKey="D"/>
            <traversableConnection name="entity" minimumMultiplicity="0" maximumMultiplicity="*"
                participantClassName="Entity" sortKey="Z"/>
        </connections>
    </ownedAssociation>
    <ownedAssociation>
        <connections>
            <traversableConnection name="languageCommunication" minimumMultiplicity="1"
                maximumMultiplicity="1" participantClassName="LanguageCommunication" sortKey="C"/>
            <traversableConnection name="entity" minimumMultiplicity="0" maximumMultiplicity="*"
                participantClassName="Entity" sortKey="Z"/>
        </connections>
    </ownedAssociation>
    <ownedAssociation>
        <connections>
            <traversableConnection name="queryByParameter" minimumMultiplicity="0"
                maximumMultiplicity="*" participantClassName="QueryByParameter" sortKey="Z"/>
            <traversableConnection name="parameter" minimumMultiplicity="0" maximumMultiplicity="1"
                participantClassName="Parameter" sortKey="Z"/>
        </connections>
    </ownedAssociation>
    <ownedAssociation>
        <annotations>
            <definition>
                <text>
                    <p>Specifies the relationship between a parameter list and the parameters which
                        are its content.</p>
                </text>
            </definition>
        </annotations>
        <connections>
            <traversableConnection name="parameter" minimumMultiplicity="0" maximumMultiplicity="1"
                participantClassName="Parameter" sortKey="Z"/>
            <traversableConnection name="parameterList" minimumMultiplicity="0"
                maximumMultiplicity="*" participantClassName="ParameterList" sortKey="Z"/>
        </connections>
    </ownedAssociation>
    <ownedAssociation>
        <connections>
            <traversableConnection name="act" minimumMultiplicity="0" maximumMultiplicity="*"
                participantClassName="Act" sortKey="A"/>
            <traversableConnection name="participation" minimumMultiplicity="1"
                maximumMultiplicity="1" participantClassName="Participation" sortKey="A"/>
        </connections>
    </ownedAssociation>
    <ownedAssociation>
        <connections>
            <traversableConnection name="role" minimumMultiplicity="0" maximumMultiplicity="*"
                participantClassName="Role" sortKey="B"/>
            <traversableConnection name="participation" minimumMultiplicity="1"
                maximumMultiplicity="1" participantClassName="Participation" sortKey="C"/>
        </connections>
    </ownedAssociation>
    <ownedAssociation>
        <connections>
            <traversableConnection name="controlAct" minimumMultiplicity="0" maximumMultiplicity="1"
                participantClassName="ControlAct" sortKey="Z"/>
            <traversableConnection name="queryEvent" minimumMultiplicity="1" maximumMultiplicity="1"
                participantClassName="QueryEvent" sortKey="A"/>
        </connections>
    </ownedAssociation>
    <ownedAssociation>
        <annotations>
            <definition>
                <text>
                    <p>The following constraint applies to this association:</p>
                    <p>Invariant (Role x) { not(x.player.equals(null)) or not(x.scoper.equals(null))
                        }</p>
                </text>
            </definition>
        </annotations>
        <connections>
            <traversableConnection name="player" minimumMultiplicity="0" maximumMultiplicity="*"
                participantClassName="Entity" sortKey="A"/>
            <traversableConnection name="playedRole" minimumMultiplicity="0" maximumMultiplicity="1"
                participantClassName="Role" sortKey="A"/>
        </connections>
    </ownedAssociation>
    <ownedAssociation>
        <annotations>
            <definition>
                <text>
                    <p>The following constraint applies to this association:</p>
                    <p>Invariant (Role x) { not(x.player.equals(null)) or not(x.scoper.equals(null))
                        }</p>
                </text>
            </definition>
        </annotations>
        <connections>
            <traversableConnection name="scoper" minimumMultiplicity="0" maximumMultiplicity="*"
                participantClassName="Entity" sortKey="B"/>
            <traversableConnection name="scopedRole" minimumMultiplicity="0" maximumMultiplicity="1"
                participantClassName="Role" sortKey="B"/>
        </connections>
    </ownedAssociation>
    <ownedAssociation>
        <connections>
            <traversableConnection name="source" minimumMultiplicity="0" maximumMultiplicity="*"
                participantClassName="Role" sortKey="A"/>
            <traversableConnection name="outboundLink" minimumMultiplicity="1"
                maximumMultiplicity="1" participantClassName="RoleLink" sortKey="D"/>
        </connections>
    </ownedAssociation>
    <ownedAssociation>
        <connections>
            <traversableConnection name="target" minimumMultiplicity="0" maximumMultiplicity="*"
                participantClassName="Role" sortKey="B"/>
            <traversableConnection name="inboundLink" minimumMultiplicity="1"
                maximumMultiplicity="1" participantClassName="RoleLink" sortKey="E"/>
        </connections>
    </ownedAssociation>
    <ownedAssociation>
        <connections>
            <traversableConnection name="leftSide" minimumMultiplicity="0" maximumMultiplicity="*"
                participantClassName="LogicalExpression" sortKey="A"/>
            <traversableConnection name="userAsLeft" minimumMultiplicity="0" maximumMultiplicity="1"
                participantClassName="SelectionExpression" sortKey="A"/>
        </connections>
    </ownedAssociation>
    <ownedAssociation>
        <connections>
            <traversableConnection name="queryBySelection" minimumMultiplicity="0"
                maximumMultiplicity="*" participantClassName="QueryBySelection" sortKey="Z"/>
            <traversableConnection name="selectionExpression" minimumMultiplicity="1"
                maximumMultiplicity="1" participantClassName="SelectionExpression" sortKey="Z"/>
        </connections>
    </ownedAssociation>
    <ownedAssociation>
        <connections>
            <traversableConnection name="rightSide" minimumMultiplicity="0" maximumMultiplicity="*"
                participantClassName="LogicalExpression" sortKey="B"/>
            <traversableConnection name="userAsRight" minimumMultiplicity="0"
                maximumMultiplicity="1" participantClassName="SelectionExpression" sortKey="B"/>
        </connections>
    </ownedAssociation>
    <ownedAssociation>
        <connections>
            <traversableConnection name="querySpec" minimumMultiplicity="0" maximumMultiplicity="*"
                participantClassName="QuerySpec" sortKey="Z"/>
            <traversableConnection name="sortControl" minimumMultiplicity="1"
                maximumMultiplicity="1" participantClassName="SortControl" sortKey="Z"/>
        </connections>
    </ownedAssociation>
    <ownedAssociation>
        <annotations>
            <definition>
                <text>
                    <p>This relation links a transmission to its sender, receiver, call-back party,
                        etc.</p>
                </text>
            </definition>
        </annotations>
        <connections>
            <traversableConnection name="communicationFunction" minimumMultiplicity="1"
                maximumMultiplicity="*" participantClassName="CommunicationFunction" sortKey="A"/>
            <traversableConnection name="transmission" minimumMultiplicity="0"
                maximumMultiplicity="*" participantClassName="Transmission" sortKey="Z"/>
        </connections>
    </ownedAssociation>
</staticModel>
