Ontology
imports: vocab codeSystem.owl
imports: vocab conceptDomain.owl
imports: vocab valueSet.owl
version info: 0.1 (30.05.2010 21:51:26)
imports: CSO.owl

AcknowledgementCondition-ConceptDomain
type: Class
comment: Acknowledgement Condition codes describe the conditions under which accept or application level acknowledgements are required to be returned in response to the message send operation.
subclass of: conceptDomain
subclass of: Restriction
  on property: hasValueSet
  all values from: AcknowledgementCondition-ValueSet

AcknowledgementDetailCode-ConceptDomain
type: Class
comment: A site specific code indicating the specific problem being reported by this Ack Detail.
subclass of: conceptDomain
subclass of: Restriction
  on property: hasValueSet
  all values from: AcknowledgementDetailCode-ValueSet

AcknowledgementDetailNotSupportedCode-ConceptDomain
type: Class
comment: Refelects rejections because elements of the communication are not supported in the current context.
subclass of: AcknowledgementDetailCode-ConceptDomain
subclass of: Restriction
  on property: hasValueSet
  all values from: AcknowledgementDetailNotSupportedCode-ValueSet

AcknowledgementDetailSyntaxErrorCode-ConceptDomain
type: Class
comment: Reflects errors in the syntax or structure of the communication.
subclass of: AcknowledgementDetailCode-ConceptDomain

AcknowledgementDetailType-ConceptDomain
type: Class
comment: A code identifying the specific message to be provided. A textual value may be specified as the print name, or for non-coded messages, as the original text.Discussion: 'Required attribute xxx is missing', 'System will be unavailable March 19 from 0100 to 0300'Examples:
subclass of: conceptDomain

AcknowledgementMessageCode-ConceptDomain
type: Class
comment: A code identifying the specific message to be provided. Discussion: A textual value may be specified as the print name, or for non-coded messages, as the original text. Examples: 'Required attribute xxx is missing', 'System will be unavailable March 19 from 0100 to 0300'
subclass of: conceptDomain

AcknowledgementType-ConceptDomain
type: Class
comment: Acknowledgement code as described in HL7 message processing rules.
subclass of: conceptDomain

AcknowledgmentMessageType-ConceptDomain
type: Class
comment: Identifies the the kind of information specified in the acknowledgement message. Options are: Error, Warning or Information.
subclass of: AcknowledgementDetailType-ConceptDomain

ActAdjudicationInformationCode-ConceptDomain
type: Class
comment: Explanatory codes that provide information derived by an Adjudicator during the course of adjudicating an Invoice. Codes from this domain are purely information and do not materially affect the adjudicated Invoice. That is, codes do not impact or explain financial adjustments to an Invoice. A companion domain (ActAdjudicationReason) includes information reasons which have a financial impact on an Invoice (claim). Example adjudication information code is 54540 - Patient has reached Plan Maximum for current year. Codes from this domain further rationalizes ActAdjudicationCodes (e.g. AA - Adjudicated with Adjustment), which are used to describe the process of adjudicating an Invoice.
subclass of: HL7DefinedActCodes-ConceptDomain

HL7DefinedActCodes-ConceptDomain
type: Class
comment: Domain provides the root for HL7-defined detailed or rich codes for the Act classes.
subclass of: ActCode-ConceptDomain

ActBillableServiceCode-ConceptDomain
type: Class
comment: Definition: An identifying code for billable services, as opposed to codes for similar services used to identify them for functional purposes.
subclass of: ActProcedureCode-ConceptDomain

ActProcedureCode-ConceptDomain
type: Class
comment: An identifying code for healthcare interventions/procedures.
subclass of: HL7DefinedActCodes-ConceptDomain

ActBillableServiceReason-ConceptDomain
type: Class
comment: Definition: This domain is used to document reasons for providing a billable service; the billable services may include both clinical services and social services.
subclass of: ActReason-ConceptDomain

ActReason-ConceptDomain
type: Class
comment: A code specifying the motivation, cause, or rationale of an Act, when such rationale is not reasonably representable as an ActRelationship of type "has reason" linking to another Act. Examples: 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". Discussion 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. 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.
subclass of: conceptDomain

ActCareProvisionCode-ConceptDomain
type: Class
comment: Description:The type and scope of responsibility taken-on by the performer of the Act for a specific subject of care.
subclass of: ActCode-ConceptDomain

ActCode-ConceptDomain
type: Class
comment: The table that provides the detailed or rich codes for the Act classes.
subclass of: conceptDomain
subclass of: Restriction
  on property: hasValueSet
  all values from: ActCode-ValueSet

ActClass-ConceptDomain
type: Class
comment: A code specifying the major type of Act that this Act-instance represents. Constraints: The classCode domain is a tightly controlled vocabulary, not an external or user-defined vocabulary. Every Act-instance must have a classCode. If the act class is not further specified, the most general Act.classCode (ACT) is used. 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, Act.code is not a "modifier" that can alter the meaning of a class code. (See Act.code for contrast.)
subclass of: conceptDomain
subclass of: Restriction
  on property: hasValueSet
  all values from: ActClass-ValueSet

ActClassComposition-ConceptDomain
type: Class
comment: A context representing a grouped commitment of information to the EHR. It is considered the unit of modification of the record, the unit of transmission in record extracts, and the unit of attestation by authorizing clinicians. A composition represents part of a patient record originating from a single interaction between an authenticator and the record. Unless otherwise stated all statements within a composition have the same authenticator, apply to the same patient and were recorded in a single session of use of a single application. A composition contains organizers and entries.
subclass of: ActContainer-ConceptDomain

ActContainer-ConceptDomain
type: Class
comment: Used to group a set of acts sharing a common context. Container structures can nest within other context structures - such as where a document is contained within a folder, or a folder is contained within an EHR extract. Open issue: There is a clear conflict between this act and the use of the more general "component" ActRelationship. The question that must be resolved is what should be the class code of the parent (or containing) Act.
subclass of: ActClass-ConceptDomain

ActClassEntry-ConceptDomain
type: Class
comment: This context represents the information acquired and recorded for an observation, a clinical statement such as a portion of the patient's history or an inference or assertion, or an action that might be intended or has actually been performed. This class may represent both the actual data describing the observation, inference, or action, and optionally the details supporting the clinical reasoning process such as a reference to an electronic guideline, decision support system, or other knowledge reference.
subclass of: ActContainer-ConceptDomain

ActClassExposure-ConceptDomain
type: Class
comment: Description:The interaction of entities whereupon a subject entity is brought into proximity to a physical, chemical or biological agent. This includes intended exposure (e.g. administering a drug product) as well as accidental or environmental exposure. (Note: This class deals only with proximity and not the effectiveness of the exposure, i.e. not all exposed will suffer actual harm or benefit.) Examples:Exposure to radiation, drug administration, inhalation of peanut aerosol or viral particles.
subclass of: ActClass-ConceptDomain

ActClassExtract-ConceptDomain
type: Class
comment: This context represents the part of a patient record conveyed in a single communication. It is drawn from a providing system for the purposes of communication to a requesting process (which might be another repository, a client application or a middleware service such as an electronic guideline engine), and supporting the faithful inclusion of the communicated data in the receiving system. An extract may be the entirety of the patient record as held by the sender or it may be a part of that record (e.g. changes since a specified date). An extract contains folders or compositions. An extract cannot contain another extract.
subclass of: ActContainer-ConceptDomain

ActClassGenomicObservation-ConceptDomain
type: Class
comment: Description:An observation of genomic phenomena.
subclass of: ActClass-ConceptDomain

ActClassOrganizer-ConceptDomain
type: Class
comment: Organizer of entries. Navigational. No semantic content. Knowledge of the section code is not required to interpret contained observations. Represents a heading in a heading structure, or "organizer tree". The record entries relating to a single clinical session are usually grouped under headings that represent phases of the encounter, or assist with layout and navigation. Clinical headings usually reflect the clinical workflow during a care session, and might also reflect the main author's reasoning processes. Much research has demonstrated that headings are used differently by different professional groups and specialties, and that headings are not used consistently enough to support safe automatic processing of the E H R.
subclass of: ActContainer-ConceptDomain

ActClassPolicy-ConceptDomain
type: Class
comment: Description:A mandate, regulation, obligation, requirement, rule, or expectation unilaterally imposed by one party on: The activity of another party The behavior of another party The manner in which an act is executed
subclass of: ActClass-ConceptDomain

ActClassProcedure-ConceptDomain
type: Class
comment: ################
subclass of: ActClass-ConceptDomain

ActClassStorage-ConceptDomain
type: Class
comment: The act of putting something away for safe keeping. The "something" may be physical object such as a specimen, or information, such as observations regarding a specimen.
subclass of: ActClass-ConceptDomain

ActCognitiveProfessionalServiceCode-ConceptDomain
type: Class
comment: Denotes the specific service that has been performed. This is obtained from the professional service catalog pertaining to the discipline of the health service provider. Professional services are generally cognitive in nature and exclude surgical procedures. E.g. Provided training, Provided drug therapy review, Gave smoking-cessation counseling, etc.
subclass of: ActCode-ConceptDomain

ActConsentInformationAccessOverrideReason-ConceptDomain
type: Class
comment: Definition: Use to convey the reason that a provider may or has accessed personal healthcare information. Typically, this involves overriding the subject's consent directives.
subclass of: ActReason-ConceptDomain

ActConsentType-ConceptDomain
type: Class
comment: Definition: The type of consent directive, e.g., to consent or dissent to collect, access, or use in specific ways within an EHRS or for health information exchange; or to disclose health information for purposes such as research.
subclass of: ActCode-ConceptDomain

ActCoverageAssessmentObservationValue-ConceptDomain
type: Class
comment: Codes specify the category of observation, evidence, or document used to assess for services, e.g., discharge planning, or to establish eligibility for coverage under a policy or program. The type of evidence is coded as observation values.
subclass of: ObservationValue-ConceptDomain

ObservationValue-ConceptDomain
type: Class
comment: This domain is the root domain to which all HL7-recognized value sets for the Observation.value attribute will be linked when Observation.value has a coded data type.
subclass of: conceptDomain

ActCoverageLevelRasonCode-ConceptDomain
type: Class
comment: Description:Represents the reason for the level of coverage provided under the policy or program in terms of the types of entities that may play covered parties based on their personal relationships or employment status.
subclass of: ActReason-ConceptDomain

ActCoverageLimitCode-ConceptDomain
type: Class
comment: Criteria that are applicable to the authorized coverage.
subclass of: HL7DefinedActCodes-ConceptDomain

ActCoveragePartyLimitGroupCode-ConceptDomain
type: Class
comment: Codes representing the level of coverage provided under the policy or program in terms of the types of entities that may play covered parties based on their personal relationships or employment status.
subclass of: ActCoveredPartyLimitCode-ConceptDomain

ActCoveredPartyLimitCode-ConceptDomain
type: Class
comment: Codes representing the types of covered parties that may receive covered benefits under a policy or program.
subclass of: ActCoverageLimitCode-ConceptDomain

ActCoverageProviderReason-ConceptDomain
type: Class
comment: Description:Identifies the reason or rationale for coverage of a service or product based on characteristics of the provider, e.g., contractual relationship to payor, such as in or out-of-network; relationship of the covered party to the provider. Example:In closed managed care plan, a covered party is assigned a primary care provider who provides primary care services and authorizes referrals and ancillary and non-primary care services.
subclass of: ActCoverageReason-ConceptDomain

ActCoverageReason-ConceptDomain
type: Class
comment: Description:Codes used to specify reasons or criteria relating to coverage provided under a policy or program. May be used to convey reasons pertaining to coverage contractual provisions, including criteria for eligibility, coverage limitations, coverage maximums, or financial participation required of covered parties.
subclass of: ActReason-ConceptDomain

ActCoverageQuantityLimitCode-ConceptDomain
type: Class
comment: Maximum amount paid or maximum number of services/products covered; or maximum amount or number covered during a specified time period under the policy or program.
subclass of: ActCoverageLimitCode-ConceptDomain

ActCoverageServiceReason-ConceptDomain
type: Class
comment: Description:Identifies the reason or rationale for coverage of a service or product based on clinical efficacy criteria or practices prescribed by the payor.
subclass of: ActCoverageReason-ConceptDomain

ActCoverageTypeCode-ConceptDomain
type: Class
comment: Definition: Set of codes indicating the type of insurance policy or program that pays for the cost of benefits provided to covered parties.
subclass of: HL7DefinedActCodes-ConceptDomain

ActCredentialedCareCode-ConceptDomain
type: Class
comment: Description:The type and scope of legal and/or professional responsibility taken-on by the performer of the Act for a specific subject of care as described by a credentialing agency, i.e. government or non-government agency. Failure in executing this Act may result in loss of credential to the person or organization who participates as performer of the Act. Excludes employment agreements. Example:Hospital license; physician license; clinic accreditation.
subclass of: ActCareProvisionCode-ConceptDomain

ActCredentialedCareProvisionPersonCode-ConceptDomain
type: Class
comment: Description:The type and scope of legal and/or professional responsibility taken-on by the performer of the Act for a specific subject of care as described by an agency for credentialing individuals.
subclass of: ActCredentialedCareCode-ConceptDomain

ActCredentialedCareProvisionProgramCode-ConceptDomain
type: Class
comment: Description:The type and scope of legal and/or professional responsibility taken-on by the performer of the Act for a specific subject of care as described by an agency for credentialing programs within organizations.
subclass of: ActCredentialedCareCode-ConceptDomain

ActExposureCode-ConceptDomain
type: Class
comment: Concepts that identify the type or nature of exposure interaction. Examples include "household", "care giver", "intimate partner", "common space", "common substance", etc. to further describe the nature of interaction.
subclass of: HL7DefinedActCodes-ConceptDomain

ActExposureLevelCode-ConceptDomain
type: Class
comment: A qualitative measure of the degree of exposure to the causative agent. This includes concepts such as "low", "medium" and "high". This quantifies how the quantity that was available to be administered to the target differs from typical or background levels of the substance.
subclass of: conceptDomain

ActFinancialStatusObservationValue-ConceptDomain
type: Class
comment: Code specifying financial indicators used to assess or establish eligibility for coverage under a policy or program; e.g., pay stub; tax or income document; asset document; living expenses.
subclass of: ActCoverageAssessmentObservationValue-ConceptDomain

ActHealthInsuranceTypeCode-ConceptDomain
type: Class
comment: Definition: Set of codes indicating the type of health insurance policy that covers health services provided to covered parties. A health insurance policy is a written contract for insurance between the insurance company and the policyholder, and contains pertinent facts about the policy owner (the policy holder), the health insurance coverage, the insured subscribers and dependents, and the insurer. Health insurance is typically administered in accordance with a plan, which specifies (1) the type of health services and health conditions that will be covered under what circumstances (e.g., exclusion of a pre-existing condition, service must be deemed medically necessary; service must not be experimental; service must provided in accordance with a protocol; drug must be on a formulary; service must be prior authorized; or be a referral from a primary care provider); (2) the type and affiliation of providers (e.g., only allopathic physicians, only in network, only providers employed by an HMO); (3) financial participations required of covered parties (e.g., co-pays, coinsurance, deductibles, out-of-pocket); and (4) the manner in which services will be paid (e.g., under indemnity or fee-for-service health plans, the covered party typically pays out-of-pocket and then file a claim for reimbursement, while health plans that have contractual relationships with providers, i.e., network providers, typically do not allow the providers to bill the covered party for the cost of the service until after filing a claim with the payer and receiving reimbursement).
subclass of: ActInsuranceTypeCode-ConceptDomain

ActInsuranceTypeCode-ConceptDomain
type: Class
comment: Definition: Set of codes indicating the type of insurance policy. Insurance, in law and economics, is a form of risk management primarily used to hedge against the risk of potential financial loss. Insurance is defined as the equitable transfer of the risk of a potential loss, from one entity to another, in exchange for a premium and duty of care. A policy holder is an individual or an organization enters into a contract with an underwriter which stipulates that, in exchange for payment of a sum of money (a premium), one or more covered parties (insureds) is guaranteed compensation for losses resulting from certain perils under specified conditions. The underwriter analyzes the risk of loss, makes a decision as to whether the risk is insurable, and prices the premium accordingly. A policy provides benefits that indemnify or cover the cost of a loss incurred by a covered party, and may include coverage for services required to remediate a loss. An insurance policy contains pertinent facts about the policy holder, the insurance coverage, the covered parties, and the insurer. A policy may include exemptions and provisions specifying the extent to which the indemnification clause cannot be enforced for intentional tortious conduct of a covered party, e.g., whether the covered parties are jointly or severably insured. Discussion: In contrast to programs, an insurance policy has one or more policy holders, who own the policy. The policy holder may be the covered party, a relative of the covered party, a partnership, or a corporation, e.g., an employer. A subscriber of a self-insured health insurance policy is a policy holder. A subscriber of an employer sponsored health insurance policy is holds a certificate of coverage, but is not a policy holder; the policy holder is the employer. See CoveredRoleType.
subclass of: ActCoverageTypeCode-ConceptDomain

ActIdentityDocumentCode-ConceptDomain
type: Class
comment: Code identifying the type of identification document (e.g. passport, drivers license) Implementation Note:The proposal called for a domain, but a code was also provided. When codes are available for the value set the code IDENTDOC (identity document) will be used as the headcode for the specializable value set.
subclass of: DocumentType-ConceptDomain

DocumentType-ConceptDomain
type: Class
comment: The kind of document. Possible values: discharge summary, progress note, Oncology note, etc.
subclass of: ExternallyDefinedActCodes-ConceptDomain

ActImmunizationReason-ConceptDomain
type: Class
comment: Description:A coded description of the reason for why a patient was administered an immunization. Examples:Post Exposure - Reason, Universal Immunization Program, Outbreak Control, Universal School Program
subclass of: ActReason-ConceptDomain

ActIncidentCode-ConceptDomain
type: Class
comment: Definition: Set of codes indicating the type of incident or accident.
subclass of: HL7DefinedActCodes-ConceptDomain

ActInformationAccessCode-ConceptDomain
type: Class
comment: Definition: The type of personal health information to which the subject of the information or the subjectaTMs delegate consents or dissents to authorize access.
subclass of: ActConsentType-ConceptDomain

ActInformationAccessContextCode-ConceptDomain
type: Class
comment: Concepts conveying the context in which consent to transfer specified patient health information for collection, access, use or disclosure applies.
subclass of: HL7DefinedActCodes-ConceptDomain

ActInformationCategoryCode-ConceptDomain
type: Class
comment: Definition:Indicates the set of information types which may be manipulated or referenced, such as for recommending access restrictions.
subclass of: ActCode-ConceptDomain

ActInjuryCode-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: ActCode-ConceptDomain

ActInvoiceDetailClinicalProductCode-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: ActInvoiceDetailCode-ConceptDomain

ActInvoiceDetailCode-ConceptDomain
type: Class
comment: Codes representing a service or product that is being invoiced (billed). The code can represent such concepts as "office visit", "drug X", "wheelchair" and other billable items such as taxes, service charges and discounts.
subclass of: ActInvoiceElementCode-ConceptDomain

ActInvoiceDetailClinicalServiceCode-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: ActInvoiceDetailCode-ConceptDomain

ActInvoiceElementCode-ConceptDomain
type: Class
comment: Type of invoice element that is used to assist in describing an Invoice that is either submitted for adjudication or for which is returned on adjudication results.
subclass of: HL7DefinedActCodes-ConceptDomain

ActInvoiceElementModifier-ConceptDomain
type: Class
comment: Processing consideration and clarification codes.
subclass of: conceptDomain

ActiveIngredientDrugEntityType-ConceptDomain
type: Class
comment: Any substance which, when combined with other ingredients, delivers all or part of the therapeutic benefit associated with a medication.
subclass of: ClinicalDrug-ConceptDomain

ClinicalDrug-ConceptDomain
type: Class
comment: Any substance or mixture of substances manufactured, sold or represented for use in: (a) the diagnosis, treatment, mitigation or prevention of a disease, disorder, abnormal physical state, or its symptoms, in human beings or animals; (b) restoring, correcting or modifying organic functions in human beings or animals.
subclass of: DrugEntity-ConceptDomain

ActListCode-ConceptDomain
type: Class
comment: Provides codes associated with ActClass value of LIST (working list)
subclass of: HL7DefinedActCodes-ConceptDomain

ActMedicalBillableServiceCode-ConceptDomain
type: Class
comment: Definition: An identifying code for billable medical services, as opposed to codes for similar services to identify them for clinical purposes.
subclass of: ActBillableServiceCode-ConceptDomain

ActMedicationDocumentCode-ConceptDomain
type: Class
comment: Indicates the types of documents that can be associated with a medication or group of medications. Examples include: Patient monographs, Provider monographs, Drug protocols, etc.
subclass of: DocumentType-ConceptDomain

ActMedicationTherapyDurationWorkingListCode-ConceptDomain
type: Class
comment: Definition:A collection of concepts that identifies different types of 'duration-based' mediation working lists. Examples:"Continuous/Chronic" "Short-Term" and "As Needed"
subclass of: ActTherapyDurationWorkingListCode-ConceptDomain

ActTherapyDurationWorkingListCode-ConceptDomain
type: Class
comment: Codes used to identify different types of 'duration-based' working lists. Examples include "Continuous/Chronic", "Short-Term" and "As-Needed".
subclass of: ActListCode-ConceptDomain

ActMood-ConceptDomain
type: Class
comment: A code distinguishing whether an Act is conceived of as a factual statement or in some other manner as a command, possibility, goal, etc. Constraints: An Act-instance must have one and only one moodCode value. The moodCode of a single Act-instance never changes. Mood is not state. 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.type.) Discussion: 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 as 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. 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 can not change throughout the lifetime of an act object. 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 ac…
subclass of: conceptDomain
subclass of: Restriction
  on property: hasValueSet
  all values from: ActMood-ValueSet

ActMoodProposal-ConceptDomain
type: Class
comment: A non-mandated intent to perform an act. Used to record intents that are explicitly not Orders. Professional responsibility for the 'proposal' may or may not be present.
subclass of: ActMood-ConceptDomain

ActNoImmunizationReason-ConceptDomain
type: Class
comment: A coded description of the reason for why a patient did not receive a scheduled immunization. (important for public health strategy
subclass of: ActReason-ConceptDomain

ActNonMedicalBillableServiceCode-ConceptDomain
type: Class
comment: Definition: An identifying code for billable services that are not medical procedures, such as social services or governmental program services. Example: Building a wheelchair ramp, help with groceries, giving someone a ride, etc.
subclass of: ActBillableServiceCode-ConceptDomain

ActNonObservationIndicationCode-ConceptDomain
type: Class
comment: Description:Concepts representing indications (reasons for clinical action) other than diagnosis and symptoms.
subclass of: ActCode-ConceptDomain

ActObservationVerificationType-ConceptDomain
type: Class
comment: Identifies the type of verification investigation being undertaken with respect to the subject of the verification activity. Examples: Verification of eligibility for coverage under a policy or program - aka enrolled/covered by a policy or program Verification of record - e.g., person has record in an immunization registry Verification of enumeration - e.g. NPI Verification of Board Certification - provider specific Verification of Certification - e.g. JAHCO, NCQA, URAC Verification of Conformance - e.g. entity use with HIPAA, conformant to the CCHIT EHR system criteria Verification of Provider Credentials Verification of no adverse findings - e.g. on National Provider Data Bank, Health Integrity Protection Data Base (HIPDB)
subclass of: HL7DefinedActCodes-ConceptDomain

ActOralHealthProcedureCode-ConceptDomain
type: Class
comment: Description:An identifying code for oral health interventions/procedures.
subclass of: ActProcedureCode-ConceptDomain

ActPatientSafetyIncidentCode-ConceptDomain
type: Class
comment: Definition: A code specifying the particular kind of Patient Safety Incident that the Incident class instance represents. Examples:"Medication incident", "slips, trips and falls incident".The actual value set for the domain will be determined by each (realm) implementation, whose Patient Safety terminology will be specific, although probably linked to the WHO Patient Safety Taxonomy that is currently under development
subclass of: ActIncidentCode-ConceptDomain

ActPatientTransportationModeCode-ConceptDomain
type: Class
comment: Definition: Characterizes how a patient was or will be transported to the site of a patient encounter. Examples: Via ambulance, via public transit, on foot.
subclass of: ActTransportationModeCode-ConceptDomain

ActTransportationModeCode-ConceptDomain
type: Class
comment: Characterizes how a transportation act was or will be carried out. Examples: Via private transport, via public transit, via courier.
subclass of: ActCode-ConceptDomain

ActPaymentReason-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: ActReason-ConceptDomain

ActPolicyType-ConceptDomain
type: Class
comment: Description:Types of policies that further specify the ActClassPolicy value set.
subclass of: HL7DefinedActCodes-ConceptDomain

ActPriority-ConceptDomain
type: Class
comment: 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. Discussion: 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.
subclass of: conceptDomain

ActPrivilegeCategorization-ConceptDomain
type: Class
comment: An Act which characterizes a Privilege can have additional observations to provide a finer definition of the requested or conferred privilege. This domain describes the categories under which this additional information is classified.
subclass of: HL7DefinedActCodes-ConceptDomain

ActPrivilegeCategorizationType-ConceptDomain
type: Class
comment: This domain includes observations used to characterize a privilege, under which this additional information is classified. Examples:A privilege to prescribe drugs has a RESTRICTION that excludes prescribing narcotics; a surgical procedure privilege has a PRE-CONDITION that it requires prior Board approval.
subclass of: ObservationType-ConceptDomain

ObservationType-ConceptDomain
type: Class
comment: Identifies the kinds of observations that can be performed
subclass of: ActCode-ConceptDomain

ActProcedureCategoryList-ConceptDomain
type: Class
comment: Description:Describes the high level classification of professional services for grouping. Examples:Education, Counseling, Surgery, etc.
subclass of: ActListCode-ConceptDomain

ActProgramTypeCode-ConceptDomain
type: Class
comment: Definition: A set of codes used to indicate coverage under a program. A program is an organized structure for administering and funding coverage of a benefit package for covered parties meeting eligibility criteria, typically related to employment, health, financial, and demographic status. Programs are typically established or permitted by legislation with provisions for ongoing government oversight. Regulations may mandate the structure of the program, the manner in which it is funded and administered, covered benefits, provider types, eligibility criteria and financial participation. A government agency may be charged with implementing the program in accordance to the regulation. Risk of loss under a program in most cases would not meet what an underwriter would consider an insurable risk, i.e., the risk is not random in nature, not financially measurable, and likely requires subsidization with government funds. Discussion: Programs do not have policy holders or subscribers. Program eligibles are enrolled based on health status, statutory eligibility, financial status, or age. Program eligibles who are covered parties under the program may be referred to as members, beneficiaries, eligibles, or recipients. Programs risk are underwritten by not for profit organizations such as governmental entities, and the beneficiaries typically do not pay for any or some portion of the cost of coverage. See CoveredPartyRoleType.
subclass of: ActCoverageTypeCode-ConceptDomain

ActRelationshipCheckpoint-ConceptDomain
type: Class
comment: 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.) Discussion: 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. 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". 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. 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. 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. 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 interruptibleInd) and will eventually terminate. 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 …
subclass of: conceptDomain

ActRelationshipEntry-ConceptDomain
type: Class
comment: Used to enumerate the relationships between a CDA section and its contained entries.
subclass of: ActRelationshipType-ConceptDomain

ActRelationshipType-ConceptDomain
type: Class
comment: 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. Discussion: The types of act relationships fall under one of 5 categories: 1.) (De)-composition, with composite (source) and component (target) 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. 3.) Pre-condition, trigger, reason, contraindication, with the conditioned Act at the source and the condition or reason at the target. 4.) Post-condition, outcome, goal and risk, with the Act at the source having the outcome or goal at the target. 5.) A host of functional relationships including support, cause, derivation, etc. generalized under the notion of "pertinence".
subclass of: conceptDomain

ActRelationshipEntryRelationship-ConceptDomain
type: Class
comment: Description still needed
subclass of: ActRelationshipType-ConceptDomain

ActRelationshipJoin-ConceptDomain
type: Class
comment: A code specifying how concurrent Acts are resynchronized in a parallel branch construct. Discussion: 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 braches are resynchronized. 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). 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.
subclass of: conceptDomain

ActRelationshipRelatedOrder-ConceptDomain
type: Class
comment: Description still needed
subclass of: ActRelationshipType-ConceptDomain

ActRelationshipSplit-ConceptDomain
type: Class
comment: A code specifying how branches in an action plan are selected among other branches. Discussion: 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. In addition to exlusive 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. 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.
subclass of: conceptDomain

ActRelationshipSubset-ConceptDomain
type: Class
comment: Used to indicate that the target of the relationship will be a filtered subset of the total related set of targets. 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.
subclass of: conceptDomain

ActSite-ConceptDomain
type: Class
comment: An anatomical location on an organism which can be the focus of an act.
subclass of: conceptDomain

ActSpecimenTransportCode-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: HL7DefinedActCodes-ConceptDomain

ActStatus-ConceptDomain
type: Class
comment: Contains the names (codes) for each of the states in the state-machine of the RIM Act class.
subclass of: conceptDomain
subclass of: Restriction
  on property: hasValueSet
  all values from: ActStatus-ValueSet

ActSubstanceAdministrationCode-ConceptDomain
type: Class
comment: Describes the type of substance administration being performed.
subclass of: HL7DefinedActCodes-ConceptDomain

ActSubstanceAdministrationImmunizationCode-ConceptDomain
type: Class
comment: The introduction of ??? with the intent of stimulating an immune response, aimed at preventing subsequent infections by more viable agents.
subclass of: ActSubstanceAdministrationCode-ConceptDomain

ActSupplyFulfillmentRefusalReason-ConceptDomain
type: Class
comment: Indicates why a fulfiller refused to fulfill a supply order, and considered it important to notify other providers of their decision. E.g. "Suspect fraud", "Possible abuse", "Contraindicated". (used when capturing 'refusal to fill' annotations)
subclass of: ActReason-ConceptDomain

ActTaskCode-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: ActCode-ConceptDomain

ActUncertainty-ConceptDomain
type: Class
comment: A code indicating whether the Act statement as a whole, with its subordinate components has been asserted to be uncertain in any way. Examples: Patient might have had a cholecystectomy procedure in the past (but isn't sure). Constraints: 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. Discussion: This is not intended for use to replace or compete with uncertainty associated with a Observation.values 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<PQ> in the value and NOT using the uncertaintyCode. Also, when differential diagnoses are enumerated or weighed for probability, the UVP<CD> or UVN<CD> 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. 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.
subclass of: conceptDomain

AddressPartType-ConceptDomain
type: Class
comment: Discussion: The hierarchical nature of these concepts shows composition. E.g. "Street Name" is part of "Street Address Line"
subclass of: conceptDomain

AddressUse-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: PostalAddressUse-ConceptDomain

PostalAddressUse-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: conceptDomain

AdministrativeGender-ConceptDomain
type: Class
comment: The gender of a person used for adminstrative purposes (as opposed to clinical gender)
subclass of: conceptDomain
subclass of: Restriction
  on property: hasValueSet
  all values from: AdministrativeGender-ValueSet

AdvanceBeneficiaryNoticeType-ConceptDomain
type: Class
comment: Description: Represents types of consent that patient must sign prior to receipt of service, which is required for billing purposes. Examples: Advanced beneficiary medically necessity notice. Advanced beneficiary agreement to pay notice. Advanced beneficiary requests payer billed.
subclass of: HL7DefinedActCodes-ConceptDomain

AdverseSubstanceAdministrationEventActionTakenType-ConceptDomain
type: Class
comment: Definition: Indicates the class of actions taken with regard to a substance administration related adverse event. This characterization offers a judgment of the practitioner's response to the patient's problem. Examples: Example values include dose withdrawn, dose reduced, dose not changed. NOTE: The concept domain is currently supported by a value set created by the International Conference on Harmonization
subclass of: ObservationType-ConceptDomain

AffiliationRoleType-ConceptDomain
type: Class
comment: Concepts characterizing the type of association formed by player and scoper when there is a recognized Affiliate role by which the two parties are related. Examples: Business Partner, Business Associate, Colleague
subclass of: RoleCode-ConceptDomain

RoleCode-ConceptDomain
type: Class
comment: Specific classification codes for further qualifying RoleClass codes.
subclass of: conceptDomain

AllergyTestObservationMethod-ConceptDomain
type: Class
comment: Description:Provides additional methodology information not present in the associated AllergyTestCode term.
subclass of: ObservationMethod-ConceptDomain

ObservationMethod-ConceptDomain
type: Class
comment: A code that provides additional detail about the means or technique used to ascertain the observation. Examples: Blood pressure measurement method: arterial puncture vs. sphygmomanometer (Riva-Rocci), sitting vs. supine position, etc. Constraints: In all observations the method is already partially specified by the Act.code. In this case, the methodCode NEED NOT be used at all. The methodCode MAY 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 SHOULD NOT depend on this methodCode information for method detail that is implied by the Act.code. If the methodCode is used to express method detail that is also implied by the Act.code, the methodCode MUST NOT be in conflict with the implied method of the Act.code. Discussion: 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. Particularly, most LOINC codes are defined for specific methods as long as the method makes a practical difference in interpretation. For example, the difference between susceptibility studies using the "minimal inhibitory concentration" (MIC) or the "agar diffusion method" (Kirby-Baur) are specifically assigned to different LOINC codes. The methodCode therefore is only an additional qualifier to specify what may not be known already from the Act.code. 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.
subclass of: conceptDomain

AllergyTestValue-ConceptDomain
type: Class
comment: Indicates the result of a particular allergy test. E.g. Negative, Mild, Moderate, Severe
subclass of: ObservationValue-ConceptDomain

AmericanIndianAlaskaNativeLanguages-ConceptDomain
type: Class
comment: American Indian and Alaska Native languages currently being used in the United States.
subclass of: conceptDomain

AssignedNonPersonLivingSubjectRoleType-ConceptDomain
type: Class
comment: Description:A role type that is used to further qualify a non-person subject playing a role where the role class attribute is set to RoleClass AssignedEntity
subclass of: RoleCode-ConceptDomain

AttentionKeyword-ConceptDomain
type: Class
comment: Provides coded key words for attribute AttentionLine.keyWordText, which has data type SC.
subclass of: conceptDomain

AttentionLineValue-ConceptDomain
type: Class
comment: Definition:The domain of possible values used as the value of attention line specifications in AttentionLine directives.
subclass of: conceptDomain

AuthorizedParticipationFunction-ConceptDomain
type: Class
comment: This code is used to specify the exact function an actor is authorized to have in a service in all necessary detail.
subclass of: ParticipationFunction-ConceptDomain

ParticipationFunction-ConceptDomain
type: Class
comment: This code is used to specify the exact function an actor had in a service in all necessary detail. This domain may include local extensions (CWE).
subclass of: conceptDomain

AuthorizedReceiverParticipationFunction-ConceptDomain
type: Class
comment: This code is used to specify the exact function an actor is authorized to have as a receiver of information that is the subject of a consent directive or consent override.
subclass of: AuthorizedParticipationFunction-ConceptDomain

BatchName-ConceptDomain
type: Class
comment: Provides coded names for attribute Batch.name, which has data type SC.
subclass of: conceptDomain

Calendar-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: conceptDomain

CalendarCycle-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: conceptDomain

CalendarCycleOneLetter-ConceptDomain
type: Class
comment: One letter calendar cycle abbreviations (Temporary - remove when RoseTree is fixed)
subclass of: CalendarCycle-ConceptDomain

CalendarCycleTwoLetter-ConceptDomain
type: Class
comment: Two letter calendar cycle abbreviations (Temporary - remove when RoseTree is fixed)
subclass of: CalendarCycle-ConceptDomain

CalendarType-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: conceptDomain

CaseDetectionMethod-ConceptDomain
type: Class
comment: 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.
subclass of: conceptDomain

CaseDiseaseImported-ConceptDomain
type: Class
comment: 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.
subclass of: conceptDomain

CaseTransmissionMode-ConceptDomain
type: Class
comment: 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. OpenIssue: Consider moving this attribute to Observation.
subclass of: conceptDomain

Charset-ConceptDomain
type: Class
comment: Internet Assigned Numbers Authority (IANA) Charset Types
subclass of: conceptDomain

DrugEntity-ConceptDomain
type: Class
comment: A substance whose therapeutic effect is produced by chemical action within the body.
subclass of: MaterialEntityClassType-ConceptDomain

ClinicalResearchEventReason-ConceptDomain
type: Class
comment: Definition:Specifies the reason that an event occurred in a clinical research study.
subclass of: ClinicalResearchReason-ConceptDomain

ClinicalResearchReason-ConceptDomain
type: Class
comment: Definition:Contains domains for act reasons used in clinical research.
subclass of: ActReason-ConceptDomain

ClinicalResearchObservationReason-ConceptDomain
type: Class
comment: Definition:SSpecifies the reason that a test was performed or observation collected in a clinical research study. Note:This set of codes are not strictly reasons, but are used in the currently Normative standard. Future revisions of the specification will model these as ActRelationships and thes codes may subsequently be retired. Thus, these codes should not be used for new specifications.
subclass of: ClinicalResearchReason-ConceptDomain

CodeSystem-ConceptDomain
type: Class
comment: Code systems used in HL7 standards.
subclass of: conceptDomain

CodeSystemType-ConceptDomain
type: Class
comment: How a code system is maintained by HL7
subclass of: conceptDomain

CodingRationale-ConceptDomain
type: Class
comment: Identifies how to interpret the instance of the code, codeSystem value in a set of translations. Since HL7 (or a government body) may mandate that codes from certain code systems be sent in conformant messages, other synonyms that are sent in the translation set need to be distinguished among the originally captured source, the HL7 specified code, or some future role. When this code is NULL, it indicates that the translation is an undefined type. When valued, this property must contain one of the following values: SRC - Source (or original) code HL7 - HL7 Specified or Mandated SH - both HL7 mandated and the original code (precoordination) There may be additional values added to this value set as we work through the use of codes in messages and determine other Use Cases requiring special interpretation of the translations.
subclass of: conceptDomain

CombinedPharmacyOrderSuspendReasonCode-ConceptDomain
type: Class
comment: Description:Indicates why the prescription should be suspended.
subclass of: ControlActReason-ConceptDomain

ControlActReason-ConceptDomain
type: Class
comment: Identifies why a specific query, request, or other trigger event occurred.
subclass of: ActReason-ConceptDomain

CommonClinicalObservationAssertionValue-ConceptDomain
type: Class
comment: Definition: The non-laboratory, non-DI (diagnostic imaging) coded observation if no value is also required to convey the full meaning of the observation. This may be a single concept code or a complex expression.
subclass of: CommonClinicalObservationValue-ConceptDomain

CommonClinicalObservationValue-ConceptDomain
type: Class
comment: Description:Used in a patient care message to value simple clinical (non-lab) observations.
subclass of: ObservationValue-ConceptDomain

CommonClinicalObservationMethod-ConceptDomain
type: Class
comment: Description:Used in a patient care message to value simple clinical (non-lab) observation methods, such as found in SOAP (subjective, objective, assessment, plan) progress notes: subjective section (used for history from patient and other informants); objective section (used for physical exam, lab, and other common results), and assessment section (used for the clinicians assessment of the implications of subjective and objective sections).
subclass of: ObservationMethod-ConceptDomain

CommonClinicalObservationResultValue-ConceptDomain
type: Class
comment: Definition: The non-laboratory, non-diagnostic imaging coded result of the coded observable or "question" represented by the paired concept from the the NonLabDICodedObservationType domain. ] Examples:An APGAR result, a functional assessment, etc. The value must not require a specific unit of measure.
subclass of: CommonClinicalObservationValue-ConceptDomain

CommonClinicalObservationType-ConceptDomain
type: Class
comment: Used in a patient care message to report and query simple clinical (non-lab) observations.
subclass of: ObservationType-ConceptDomain

CommunicationFunctionType-ConceptDomain
type: Class
comment: Describes the type of communication function that the associated entity plays in the associated transmission.
subclass of: conceptDomain

CompressionAlgorithm-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: conceptDomain

ConceptCodeRelationship-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: conceptDomain

ConceptGenerality-ConceptDomain
type: Class
comment: Indicates whether the concept that is the target should be interpreted as itself, or whether it should be expanded to include its child concepts, or both when it is included in the source domain/valueset.
subclass of: conceptDomain

ConceptPropertyId-ConceptDomain
type: Class
comment: Property identifiers for a concept code
subclass of: conceptDomain

ConceptStatus-ConceptDomain
type: Class
comment: Possible states of concept in HL7
subclass of: conceptDomain

Confidentiality-ConceptDomain
type: Class
comment: Values that control disclosure of information. Example: Normal, restricted, substance abuse related.
subclass of: conceptDomain

ConrolActNullificationReasonCode-ConceptDomain
type: Class
comment: Description:Identifies reasons for nullifying (retracting) a particular control act. Examples:"Entered in error", "altered decision", etc.
subclass of: ControlActReason-ConceptDomain

ConsenterParticipationFunction-ConceptDomain
type: Class
comment: This code is used to specify the exact function an actor is authorized to have in authoring a consent directive.
subclass of: AuthorizedParticipationFunction-ConceptDomain

ContainerCap-ConceptDomain
type: Class
comment: The type of cap associated with a container
subclass of: conceptDomain

ContainerSeparator-ConceptDomain
type: Class
comment: A material in a blood collection container that facilites the separation of of blood cells from serum or plasma
subclass of: conceptDomain

ContentProcessingMode-ConceptDomain
type: Class
comment: Description:Identifies the order in which content should be processed.
subclass of: conceptDomain

ContextControl-ConceptDomain
type: Class
comment: This table contains the control codes that are used to manage the propagation and scope of a particular ActRelationship or Participation within a set of Acts.
subclass of: conceptDomain

ControlActReasonConditionNullify-ConceptDomain
type: Class
comment: Indicates why the ConditionaTMs status was changed to Nullified. Examples administrative error, diagnostic error.
subclass of: ControlActReason-ConceptDomain

Country-ConceptDomain
type: Class
comment: Countries of the world. ISO 3166, part 1, alpha-3 set.
subclass of: conceptDomain

CoverageChemicalDependencyValue-ConceptDomain
type: Class
comment: Definition: The category of addiction used for coverage purposes that may refer to a substance, the consumption of which may result in physical or emotional harm.
subclass of: ObservationValue-ConceptDomain

CoverageEligibilityReason-ConceptDomain
type: Class
comment: Definition: Identifies the reason or rational for why a person is eligibile for benefits under an insurance policy or progam. Examples: A person is a claimant under an automobile insurance policy are client deceased & adopted client has been given a new policy identifier. A new employee is eligible for health insurance as an employment benefit. A person meets a government program eligibility criteria for financial, age or health status.
subclass of: EligibilityActReasonCode-ConceptDomain

EligibilityActReasonCode-ConceptDomain
type: Class
comment: Identifies the reason or rational for why a person is eligibile for benefits under an insurance policy or progam. Examples: A person is a claimant under an automobile insurance policy are client deceased & adopted client has been given a new policy identifier. A new employee is eligible for health insurance as an employment benefit. A person meets a government program eligibility criteria for financial, age or health status.
subclass of: ActCoverageReason-ConceptDomain

CoverageExclusionReason-ConceptDomain
type: Class
comment: Description:Identifies the reason or rationale for coverage of a service or product based on coverage exclusions related the risk of adverse selection by covered parties.
subclass of: ActCoverageReason-ConceptDomain

CoverageFinancialParticipationReason-ConceptDomain
type: Class
comment: Description:Identifies the reason or rationale for coverage of a service or product based on financial participation responsibilities of the covered party.
subclass of: ActCoverageReason-ConceptDomain

CoverageLimitationReason-ConceptDomain
type: Class
comment: Description:Identifies the reason or rationale for limitations on the coverage of a service or product based on coverage contract provisions. Example:The maximum cost per unit; or the maximum number of units per period, which is typically the policy or program effective time.
subclass of: ActCoverageReason-ConceptDomain

CoverageParticipationFunction-ConceptDomain
type: Class
comment: Definition: Set of codes indicating the manner in which sponsors, underwriters, and payers participate in a policy or program.
subclass of: ParticipationFunction-ConceptDomain

CoverageSponsorRoleType-ConceptDomain
type: Class
comment: Description:Codes that indicate a specific type of sponsor. Used when the sponsor's role is only either as a fully insured sponsor or only as a self-insured sponsor. NOTE: Where a sponsor may be either, use the SponsorParticipationFunction.code (fully insured or self insured) to indicate the type of responsibility. (CO6-0057)
subclass of: AffiliationRoleType-ConceptDomain

CoveredPartyRoleType-ConceptDomain
type: Class
comment: A role recognized through the eligibility of an identified living subject for benefits covered under an insurance policy or a program. Eligibility as a covered party may be conditioned on a relationship with (1) the policy holder such as the policy holder who is covered as an individual under a poliy or as a party sponsored for coverage by the policy holder. Example:An employee as a subscriber; or (2) on being scoped another covered party such as the subscriber, as in the case of a dependent. Discussion: The Abstract Value Set "CoverageRoleType", which was developed for use in the Canadian realm "pre-coordinate" coverage roles with other roles that a covered party must play in order to be eligible for coverage, e.g., "handicapped dependent". Other codes in the Abstract Value Set CoveredPartyRoleType domain can be "post-coordinated" with the EligiblePartyRoleType codes to denote comparable concepts. Decoupling the concepts is intended to support a wider range of concepts and semantic comparability of coded concepts.
subclass of: RoleCode-ConceptDomain

Currency-ConceptDomain
type: Class
comment: The currency unit as defined in ISO 4217
subclass of: conceptDomain

DataType-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: conceptDomain

DecisionObservationMethod-ConceptDomain
type: Class
comment: Provides codes for decision methods, initially for assessing the causality of events.
subclass of: ObservationMethod-ConceptDomain

DedicatedServiceDeliveryLocationRoleType-ConceptDomain
type: Class
comment: A role of a place that further classifies a setting that is intended to house the provision of services.
subclass of: RoleCode-ConceptDomain

DeviceAlertLevel-ConceptDomain
type: Class
comment: Domain values for the Device.Alert_levelCode
subclass of: conceptDomain

Diagnosis-ConceptDomain
type: Class
comment: Set of codes depicting clinical disease and conditions
subclass of: conceptDomain

DiagnosisValue-ConceptDomain
type: Class
comment: Diagnosis Value
subclass of: IndicationValue-ConceptDomain

IndicationValue-ConceptDomain
type: Class
comment: Indicates the specific observation result which is the reason for the action (prescription, lab test, etc.). E.g. Headache, Ear infection, planned diagnostic image (requiring contrast agent), etc.
subclass of: ObservationValue-ConceptDomain

DiagnosticImageCode-ConceptDomain
type: Class
comment: Identifies the types of diagnostic image. Examples: Echocardiogram, electocardiogram, X-ray.
subclass of: ObservationType-ConceptDomain

DocumentCompletion-ConceptDomain
type: Class
comment: Identifies the current completion state of a clinical document.
subclass of: conceptDomain

DocumentStorage-ConceptDomain
type: Class
comment: Identifies the storage status of a document.
subclass of: conceptDomain

ExternallyDefinedActCodes-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: ActCode-ConceptDomain

MaterialEntityClassType-ConceptDomain
type: Class
comment: Types of Material for EntityClass "MAT"
subclass of: EntityCode-ConceptDomain

EditStatus-ConceptDomain
type: Class
comment: The status of an entry as it pertains to its review and incorporation into the HL7 domain specification database.
subclass of: conceptDomain

EducationLevel-ConceptDomain
type: Class
comment: Years of education that a person has completed
subclass of: conceptDomain

ElementName-ConceptDomain
type: Class
comment: Provides coded names for attribute SortControl.elementName , which has data type SC.
subclass of: conceptDomain

EmployeeJob-ConceptDomain
type: Class
comment: A code specifying the job performed by the employee for the employer. For example, accountant, programmer analyst, patient care associate, staff nurse, etc.
subclass of: conceptDomain

EmployeeJobClass-ConceptDomain
type: Class
comment: A code qualifying the employment in various ways, such as, full-time vs. part time, etc.
subclass of: conceptDomain

EmployeeOccupationCode-ConceptDomain
type: Class
comment: Industry and/or jurisdictional classification system for kind-of-work performed by an employee. Occupation codes are intended primarily as work descriptions that are suitable for a multitude of public uses e.g., job matching, employment counseling, occupational and career guidance, and labor market information services.
subclass of: EmployeeJobClass-ConceptDomain

EmployeeSalaryType-ConceptDomain
type: Class
comment: A code specifying the method used by the employer to compute the employee's salary or wages. For example, hourly, annual, or commission.
subclass of: conceptDomain

EmploymentStatus-ConceptDomain
type: Class
comment: A code used to define the employment status of the insured individual identified in UB-92 FL 58. UB-92 Form locator 64:Employment Status Code of the Insured. Can be used with Employee_Employer_statusCode in HL7. Values include Employed Full Time, Employed Part Time, Not Employed, Retired, On Active Military Duty
subclass of: conceptDomain

EncounterAccident-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: conceptDomain

EncounterAcuity-ConceptDomain
type: Class
comment: A code depicting the acuity (complexity of patient care, resource intensiveness of the patient care) of a patient's medical condition upon arrival. Values may be derived from formal acuity coding schemes such as RBS.
subclass of: conceptDomain

EncounterAdmissionSource-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: conceptDomain

EncounterDischargeDisposition-ConceptDomain
type: Class
comment: A code indicating patient status as of the ending service date of the period covered on this bill, as reported in FL6, Statement Covers Period. Values such as: Discharged to home or self care; Discharged/transferred to SNF, Discharged/transferred to an intermediate care facility (ICF); Expired; Hospice-medical facility. NUBC Form Locator 22
subclass of: conceptDomain

EncounterReferralSource-ConceptDomain
type: Class
comment: A code used to define the place or organization responsible for the patient immediately prior to their admission; for example, in the United States, as this is identified in UB-92 Form Locator 20, Source of Adm(ission).
subclass of: conceptDomain

EncounterSpecialCourtesy-ConceptDomain
type: Class
comment: A code identifying special courtesies extended to the patient. For example, no courtesies, extended courtesies, professional courtesy, VIP courtesies.
subclass of: conceptDomain

EntityClass-ConceptDomain
type: Class
comment: Classifies the Entity class and all of its subclasses. The terminology is hierarchical. At the top is this HL7-defined domain of high-level categories (such as represented by the Entity subclasses). Each of these terms must be harmonized and is specializable. The value sets beneath are encoded in Entity.code and are drawn from multiple, frequently external, domains that reflect much more fine-grained typing.
subclass of: conceptDomain
subclass of: Restriction
  on property: hasValueSet
  all values from: EntityClass-ValueSet

EntityCode-ConceptDomain
type: Class
comment: A value representing the specific kind of Entity the instance represents. Examples: A medical building, a Doberman Pinscher, a blood collection tube, a tissue biopsy. Rationale: 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.
subclass of: conceptDomain

EntityDeterminer-ConceptDomain
type: Class
comment: EntityDeterminer in natural language grammar is the class of words that comprises articles, demonstrative pronouns, and quantifiers. In the RIM, determiner is a structural code in the Entity class to distinguish whether any given Entity object stands for some, any one, or a specific thing.
subclass of: conceptDomain
subclass of: Restriction
  on property: hasValueSet
  all values from: EntityDeterminer-ValueSet

EntityHandling-ConceptDomain
type: Class
comment: Special handling requirements for an Entity. Example:Keep at room temperature; Keep frozen below 0 C; Keep in a dry environment; Keep upright, do not turn upside down.
subclass of: conceptDomain

EntityNamePartQualifier-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: conceptDomain

EntityNamePartType-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: conceptDomain

EntityNameSearchUse-ConceptDomain
type: Class
comment: A name intended for use in searching or matching
subclass of: EntityNameUse-ConceptDomain

EntityNameUse-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: conceptDomain

EntityRisk-ConceptDomain
type: Class
comment: The vocabulary table for the Entity.riskCode attribute
subclass of: conceptDomain

EntityStatus-ConceptDomain
type: Class
comment: The status of an instance of the RIM Entity class.
subclass of: conceptDomain

EPSG-GeodeticParameterDataset-ConceptDomain
type: Class
comment: Description: The EPSG (European Petroleum Survey Group) dataset represents all Datums, coordinate references (projected and 2D geographic) and coordinate systems (including Cartesian coordinate systems) used in surveying worldwide. Each record includes a 4-8 digit unique identifier. The current version is available from http://www.epsg.org/. The database contains over 4000 records covering spatial data applications worldwide.
subclass of: ActCode-ConceptDomain

EquipmentAlertLevel-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: conceptDomain

Ethnicity-ConceptDomain
type: Class
comment: In the United States, federal standards for classifying data on ethnicity determine the categories used by federal agencies and exert a strong influence on categorization by state and local agencies and private sector organizations. The federal standards do not conceptually define ethnicity, and they recognize the absence of an anthropological or scientific basis for ethnicity classification. Instead, the federal standards acknowledge that ethnicity is a social-political construct in which an individual's own identification with a particular ethnicity is preferred to observer identification. The standards specify two minimum ethnicity categories: Hispanic or Latino, and Not Hispanic or Latino. The standards define a Hispanic or Latino as a person of "Mexican, Puerto Rican, Cuban, South or Central America, or other Spanish culture or origin, regardless of race." The standards stipulate that ethnicity data need not be limited to the two minimum categories, but any expansion must be collapsible to those categories. In addition, the standards stipulate that an individual can be Hispanic or Latino or can be Not Hispanic or Latino, but cannot be both.
subclass of: conceptDomain

ExposureAgentEntityType-ConceptDomain
type: Class
comment: Indicates the material to which the patient was exposed which is believed to be related to the adverse reaction
subclass of: MaterialEntityClassType-ConceptDomain

ExposureMode-ConceptDomain
type: Class
comment: Code for the mechanism by which the exposure agent was exchanged or potentially exchanged by the participants involved in the exposure.
subclass of: conceptDomain

GenderStatus-ConceptDomain
type: Class
comment: A value representing whether the primary reproductive organs of NonPersonLivingSubject are present.
subclass of: conceptDomain

GenericUpdateReasonCode-ConceptDomain
type: Class
comment: Description:Identifies why a change is being made to a record.
subclass of: ControlActReason-ConceptDomain

GTSAbbreviation-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: conceptDomain

HCPCSAccommodationCode-ConceptDomain
type: Class
comment: Description:External value set for accommodation types used in the U.S. Health Care Financing Administration (HCFA) Common Procedure Coding System (HCPCS) including modifiers.
subclass of: HL7DefinedActCodes-ConceptDomain

HealthcareProviderTaxonomyHIPAA-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: conceptDomain

HL7AccommodationCode-ConceptDomain
type: Class
comment: Description:Accommodation type. In Intent mood, represents the accommodation type requested. In Event mood, represents accommodation assigned/used. In Definition mood, represents the available accommodation type.
subclass of: HL7DefinedActCodes-ConceptDomain

HL7CommitteeIDInRIM-ConceptDomain
type: Class
comment: Holds the codes used to identify the committees and SIGS of HL7 in RIM repository tables.
subclass of: conceptDomain

HL7ConformanceInclusion-ConceptDomain
type: Class
comment: These concepts represent theconformance requirments defined for including or valuing an element of an HL7 message. The concepts apply equally to conformance profiles defined for Version 2.x messgaes as defined by the Conformance SIG, and to the conformance columns for Version 3 messages as specified in the HMD.
subclass of: conceptDomain

HL7DefinedRoseProperty-ConceptDomain
type: Class
comment: The property Ids that HL7 has defined for customizing Rational Rose.
subclass of: conceptDomain

HL7ITSVersionCode-ConceptDomain
type: Class
comment: HL7 implementation technology specification versions. These codes will document the ITS type and version for message encoding. The code will appear in the instances based upon rules expressed in the ITS, and do not appear in the abstract message, either as it is presented to received from the ITS.
subclass of: conceptDomain

HL7StandardVersionCode-ConceptDomain
type: Class
comment: This is the domain of HL7 version codes for the Version 3 standards. Values are to be determined by HL7 and added with each new version of the HL7 Standard.
subclass of: conceptDomain

HL7TriggerEventCode-ConceptDomain
type: Class
comment: The trigger event referenced by the Control Act instance. Values are drawn from the available trigger events used in the release of HL7 identified by the versionCode.
subclass of: ActCode-ConceptDomain

HL7UpdateMode-ConceptDomain
type: Class
comment: The possible modes of updating that occur when an attribute is received by a system that already contains values for that attribute.
subclass of: conceptDomain

HtmlLinkType-ConceptDomain
type: Class
comment: HtmlLinkType values are drawn from HTML 4.0 and describe the relationship between the current document and the anchor that is the target of the link
subclass of: conceptDomain

HumanActSite-ConceptDomain
type: Class
comment: An anatomical location on a human which can be the focus of an act.
subclass of: ActSite-ConceptDomain

HumanLanguage-ConceptDomain
type: Class
comment: Codes for the representation of the names of human languages.
subclass of: conceptDomain

HumanSubstanceAdministrationSite-ConceptDomain
type: Class
comment: The set of body locations to or through which a drug product may be administered.
subclass of: HumanActSite-ConceptDomain

IdentifiedEntityType-ConceptDomain
type: Class
comment: Definition: A code representing the type of identifier that has been assigned to the identified entity (IDENT). Examples: Example values include Social Insurance Number, Product Catalog ID, Product Model Number.
subclass of: RoleCode-ConceptDomain

ImagingSubjectOrientation-ConceptDomain
type: Class
comment: A code specifying qualitatively the spatial relation between imaged object and imaging film or detector.
subclass of: SubjectPhysicalPosition-ConceptDomain

SubjectPhysicalPosition-ConceptDomain
type: Class
comment: The spatial relationship of a subject whether human, other animal, or plant, to a frame of reference such as gravity or a collection device.
subclass of: ActClass-ConceptDomain

IncidentalServiceDeliveryLocationRoleType-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: RoleCode-ConceptDomain

IndividualCaseSafetyReportCriteria-ConceptDomain
type: Class
comment: Description: Includes those concepts that are provided to justify the fact that an adverse event or product problem is required to be reported in an expedited fashion.
subclass of: ActCode-ConceptDomain

IndividualCaseSafetyReportProductCharacteristic-ConceptDomain
type: Class
comment: Description: Includes relevant pieces of information about a product or its process of creation. The vocabulary domain is used to characterize products when they are cited in adverse event or product problem reports. Examples:Weight, color, dimensions.
subclass of: ActCode-ConceptDomain

IndustryClassificationSystem-ConceptDomain
type: Class
comment: North American Industry Classification System(NAICS) for the United States, a new economic classification system that replaces the 1987 Standard Industrial Classification (SIC) for statistical purposes. NAICS is a system for classifying establishments by type of economic activity. Its purposes are: (1) to facilitate the collection, tabulation, presentation, and analysis of data relating to establishments, and (2) to promote uniformity and comparability in the presentation of statistical data describing the economy. NAICS will be used by Federal statistical agencies that collect or publish data by industry. http://www.census.gov/epcd/www/naicsusr.html
subclass of: conceptDomain

InjuryActSite-ConceptDomain
type: Class
comment: An anatomical location on a human of an injury or disease which is the focus of an act.
subclass of: HumanActSite-ConceptDomain

InjuryObservationValue-ConceptDomain
type: Class
comment: Values for observations of injuries.
subclass of: ObservationValue-ConceptDomain

IntegrityCheckAlgorithm-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: conceptDomain

IntoleranceValue-ConceptDomain
type: Class
comment: Codes identifying pariticular groupings of allergens and other agents which cause allergies and intolerances. E.g. the drug, allergen group, food or environmental agent which triggers the intolerance
subclass of: ObservationValue-ConceptDomain

InvoiceElementModifier-ConceptDomain
type: Class
comment: Designates a modifier to the code attribute to provide additional information about the invoice element. Examples: Isolation allowance; After-hours service Rationale: 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.
subclass of: conceptDomain

IssueFilterCode-ConceptDomain
type: Class
comment: Description:Indicates how result sets should be filtered based on whether they have associated issues.
subclass of: QueryParameterValue-ConceptDomain

QueryParameterValue-ConceptDomain
type: Class
comment: The domain of coded values used as parameters within QueryByParameter queries.
subclass of: conceptDomain

IssueTriggerObservationValue-ConceptDomain
type: Class
comment: The combined domain for different types of coded observation issue triggers, such as diagnoses, allergies, etc.
subclass of: ObservationValue-ConceptDomain

JobTitleName-ConceptDomain
type: Class
comment: Provides coded names for attribute Employee.jobTitleName, which has data type SC.
subclass of: conceptDomain

LanguageAbilityMode-ConceptDomain
type: Class
comment: A value representing the method of expression of the language. Example:Expressed spoken, expressed written, expressed signed, received spoken, received written, received signed.
subclass of: conceptDomain

LanguageAbilityProficiency-ConceptDomain
type: Class
comment: A value representing the level of proficiency in a language. Example:Excellent, good, fair, poor.
subclass of: conceptDomain

ListOwnershipLevel-ConceptDomain
type: Class
comment: A dynamic list of individual instances of Act which reflect the needs of an individual worker, team of workers, or an organization to view roups of Acts for clinical or administrative reasons. Discussion: The grouped Acts are related to the WorkingList via an ActRelationship of type 'COMP' component). Examples: Problem lists, goal lists, allergy lists, to-do lists, etc. Design note: This physical class contains but a single attribute, other than those that it inherits from Act. Use of that attribute in the design of RIM-based static models has been DEPRECATED in HL7 RIM Harmonization, effective November 2005. This action was based on ecommendations from the Patient Care Technical Committee. As a consequence, this class will cease to be shown as a physical class in the RIM, once the attribute is retired. Nevertheless, use of this class via an Act.classCode value of 'LIST' is entirely appropriate so long as only the attibutes inherited from Act are used.
subclass of: conceptDomain

LivingArrangement-ConceptDomain
type: Class
comment: A code depicting the living arrangements of a person
subclass of: conceptDomain

LocalMarkupIgnore-ConceptDomain
type: Class
comment: Tells a receiver to ignore just the local markup tags (local_markup, local_header, local_attr) when value="markup", or to ignore the local markup tags and all contained content when value="all"
subclass of: conceptDomain

LocalRemoteControlState-ConceptDomain
type: Class
comment: A value representing the current state of control associated with the device. Examples: A device can either work autonomously (localRemoteControlStateCode="Local") or it can be controlled by another system (localRemoteControlStateCode="Remote"). Rationale: 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.
subclass of: conceptDomain

ManagedParticipationStatus-ConceptDomain
type: Class
comment: The status of an instance of the RIM Participation class.
subclass of: conceptDomain

ManufacturerModelName-ConceptDomain
type: Class
comment: Provides coded names for attribute Device.manufacturerModelName, which has data type SC.
subclass of: conceptDomain

MapRelationship-ConceptDomain
type: Class
comment: The closeness or quality of the mapping between the HL7 concept (as represented by the HL7 concept identifier) and the source coding system. The values are patterned after the similar relationships used in the UMLS Metathesaurus. Because the HL7 coding sy
subclass of: conceptDomain

MaritalStatus-ConceptDomain
type: Class
comment: The domestic partnership status of a person. Example:Married, separated, divorced, widowed, common-law marriage.
subclass of: conceptDomain
subclass of: Restriction
  on property: hasValueSet
  all values from: MaritalStatus-ValueSet
subclass of: Restriction
  on property: hasValueSet
  all values from: MaritalStatusUB92-ValueSet

MaterialForm-ConceptDomain
type: Class
comment: A value representing the state (solid, liquid, gas) and nature of the material. Examples: For therapeutic substances, the dose form, such as tablet, ointment, gel, etc. OpenIssue: Vocabulary domain should include, but is broader than, the DoseForm domain.
subclass of: conceptDomain

MaterialType-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: conceptDomain

MDFAttributeType-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: conceptDomain

MdfHmdMetSourceType-ConceptDomain
type: Class
comment: Code to identify the source of a Message Element Type represented in the 'of MET' column of an HMD.
subclass of: conceptDomain

MdfHmdRowType-ConceptDomain
type: Class
comment: The row type codes for the tabular representation of a Hierarchical Message Description.
subclass of: conceptDomain

MdfRmimRowType-ConceptDomain
type: Class
comment: The row types for the tabular representation of an R-MIM.
subclass of: conceptDomain

MDFSubjectAreaPrefix-ConceptDomain
type: Class
comment: The standard prefixes used in Rose for RIM subject areas that determine the role or function of each subject area.
subclass of: conceptDomain

MediaType-ConceptDomain
type: Class
comment: Internet Assigned Numbers Authority (IANA) Mime Media Types
subclass of: conceptDomain

MedicallyNecessaryDuplicateProcedureReason-ConceptDomain
type: Class
comment: Definition: This domain is used to document why the procedure is a duplicate of one ordered/charged previously for the same patient within the same date of service and has been determined to be medically necessary. Example: A doctor needs a different view in a chest X-Ray.
subclass of: ActBillableServiceReason-ConceptDomain

MedicationGeneralizationRoleType-ConceptDomain
type: Class
comment: Identifies the specific hierarchical relationship between the playing and scoping medications. Examples: Generic, Generic Formulation, Therapeutic Class, etc.
subclass of: RoleCode-ConceptDomain

MedicationObservationType-ConceptDomain
type: Class
comment: Identifies types of observations that can be made about a particular drug or medication.
subclass of: ObservationType-ConceptDomain

MedicationOrderAbortReasonCode-ConceptDomain
type: Class
comment: Description:Indicates the reason the medication order should be aborted.
subclass of: ControlActReason-ConceptDomain

MedicationOrderReleaseReasonCode-ConceptDomain
type: Class
comment: Definition:A collection of concepts that indicate why the prescription should be released from suspended state.
subclass of: ControlActReason-ConceptDomain

MessageCondition-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: conceptDomain

MessageWaitingPriority-ConceptDomain
type: Class
comment: Indicates the highest importance level of the set of messages the acknowledging application has waiting on a queue for the receiving application. 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). 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.
subclass of: conceptDomain

ModifyIndicator-ConceptDomain
type: Class
comment: Indicates whether the subscription to a query is new or is being modified.
subclass of: conceptDomain

NationEntityType-ConceptDomain
type: Class
comment: Codes identifying nation states. Allows for finer grained specification of Entity with classcode <= NAT Example:ISO3166 country codes.
subclass of: EntityCode-ConceptDomain

NonDrugAgentEntity-ConceptDomain
type: Class
comment: Indicates types of allergy and intolerance agents which are non-drugs. (E.g. foods, latex, etc.)
subclass of: ExposureAgentEntityType-ConceptDomain

NonPerformanceReasonCode-ConceptDomain
type: Class
comment: The reason the action wasn't performed, e.g. why the medication was not taken. If an action wasn"t performed, it is often clinically important to know why the action wasn"t taken. Examples:Patient refused, clinically inappropriate, absolute contraindication etc.
subclass of: ActReason-ConceptDomain

NonPersonLivingSubjectEntityType-ConceptDomain
type: Class
comment: Description:Types of NonPersonLivingSubjects for the EntityClass 'NLIV'
subclass of: EntityCode-ConceptDomain

NullFlavor-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: conceptDomain
subclass of: Restriction
  on property: hasValueSet
  all values from: NullFlavor-ValueSet

ObservationActAgeGroupType-ConceptDomain
type: Class
comment: Description:To allow queries to specify useful information about the age of the patient without disclosing possible protected health information.
subclass of: ObservationType-ConceptDomain

ObservationAllergyTestCode-ConceptDomain
type: Class
comment: Description:Dianostic procedures ordered or performed to evaluate whether a sensitivity to a substance is present. This test may be associated with specimen collection and/or substance administration challenge actiivities. Example:Skin tests and eosinophilia evaluations.
subclass of: ObservationType-ConceptDomain

ObservationAllergyTestType-ConceptDomain
type: Class
comment: Indicates the type of allergy test performed or to be performed. E.g. the specific antibody or skin test performed
subclass of: ObservationType-ConceptDomain

ObservationCausalityAssessmentType-ConceptDomain
type: Class
comment: Description:A kind of observation that allows a Secondary Observation (source act) to assert (at various levels of probability) that the target act of the association (which may be of any type of act) is implicated in the etiology of another observation that is named as the subject of the Secondary Observation Example:Causality assertions where an accident is the cause of a symptom; predisposition assertions where the genetic state plus environmental factors are implicated in the development of a disease; reaction assertions where a substance exposure is associated with a finding of wheezing.
subclass of: ObservationType-ConceptDomain

ObservationDosageDefinitionPreconditionType-ConceptDomain
type: Class
comment: Definition: The set of observation type concepts that can be used to express pre-conditions to a particular dosage definition. Rationale: Used to constrain the set of observations to those related to the applicability of a dosage, such as height, weight, age, pregnancy, liver function, kidney function, etc. For example, in drug master-file type records indicating when a specified dose is applicable.
subclass of: ObservationType-ConceptDomain

ObservationGenomicFamilyHistoryType-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: ObservationType-ConceptDomain

ObservationIndicationType-ConceptDomain
type: Class
comment: Includes all codes defining types of indications such as diagnosis, symptom and other indications such as contrast agents for lab tests
subclass of: ObservationType-ConceptDomain

ObservationInterpretation-ConceptDomain
type: Class
comment: One or more codes specifying a rough qualitative interpretation of the observation, such as "normal", "abnormal", "below normal", "change up", "resistant", "susceptible", etc. Discussion: 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."
subclass of: conceptDomain

ObservationIssueTriggerCodedObservationType-ConceptDomain
type: Class
comment: Distinguishes the kinds of coded observations that could be the trigger for clinical issue detection. These are observations that are not measurable, but instead can be defined with codes. Coded observation types include: Allergy, Intolerance, Medical Condition, Pregnancy status, etc.
subclass of: ObservationType-ConceptDomain

ObservationIssueTriggerMeasuredObservationType-ConceptDomain
type: Class
comment: Distinguishes between the kinds of measurable observations that could be the trigger for clinical issue detection. Measurable observation types include: Lab Results, Height, Weight.
subclass of: ObservationType-ConceptDomain

ObservationQueryMatchType-ConceptDomain
type: Class
comment: Definition: An observation related to a query response. Example:The degree of match or match weight returned by a matching algorithm in a response to a query.
subclass of: ObservationType-ConceptDomain

ObservationVisionPrescriptionType-ConceptDomain
type: Class
comment: Definition: Identifies the type of Vision Prescription Observation that is being described.
subclass of: ObservationType-ConceptDomain

OrderableDrugForm-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: MaterialForm-ConceptDomain

OrganizationIndustryClass-ConceptDomain
type: Class
comment: Domain provides classification systems for industries.
subclass of: conceptDomain

OrganizationNameType-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: conceptDomain

OtherIndicationValue-ConceptDomain
type: Class
comment: Indicates an observed reason for a medical action other than an indication or symptom. E.g. Need for a contrast agent prior to a diagnostic image, need for anesthesia prior to surgery, etc.
subclass of: IndicationValue-ConceptDomain

OverriderParticipationFunction-ConceptDomain
type: Class
comment: This code is used to specify the exact function an actor is authorized to have in authoring a consent override.
subclass of: AuthorizedParticipationFunction-ConceptDomain

ParameterizedDataType-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: conceptDomain

ParticipationMode-ConceptDomain
type: Class
comment: Identifies the primary means by which an Entity participates in an Act.
subclass of: conceptDomain

ParticipationSignature-ConceptDomain
type: Class
comment: A code specifying whether and how the participant has attested his participation through a signature and or whether such a signature is needed. Examples: 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.)
subclass of: conceptDomain

ParticipationSubset-ConceptDomain
type: Class
comment: Used to indicate that the participation is a filtered subset of the total participations of the same type owned by the Act. Used when there is a need to limit the participations to the first, the last, the next or some other filtered subset.
subclass of: ActRelationshipSubset-ConceptDomain

ParticipationType-ConceptDomain
type: Class
comment: 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. Constraints: 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.
subclass of: conceptDomain

PatientCharacteristicObservationType-ConceptDomain
type: Class
comment: Indicates the type of characteristics a patient should have for a given therapy to be appropriate. E.g. Weight, Age, certain lab values, etc.
subclass of: ObservationType-ConceptDomain

PatientImportance-ConceptDomain
type: Class
comment: Patient VIP code
subclass of: conceptDomain

PatientProfileQueryReasonCode-ConceptDomain
type: Class
comment: Definition:A collection of concepts identifying why the patient's profile is being queried.
subclass of: ControlActReason-ConceptDomain

PaymentTerms-ConceptDomain
type: Class
comment: Describes payment terms for a financial transaction, used in an invoice. This is typically expressed as a responsibility of the acceptor or payor of an invoice.
subclass of: conceptDomain

PayorParticipationFunction-ConceptDomain
type: Class
comment: Definition: Set of codes indicating the manner in which payors participate in a policy or program.</
subclass of: CoverageParticipationFunction-ConceptDomain

PayorRoleType-ConceptDomain
type: Class
comment: Description:PayorRoleType for a particular type of policy or program benefit package or plan where more detail about the coverage administration role of the Payor is required. The functions performed by a Payor qualified by a PayorRoleType may be specified by the PayorParticpationFunction value set. Examples:A Payor that is a TPA may administer a managed care plan without underwriting the risk.
subclass of: AffiliationRoleType-ConceptDomain

PersonDisabilityType-ConceptDomain
type: Class
comment: A code identifying a person's disability.
subclass of: conceptDomain

PharmacySupplyEventStockReasonCode-ConceptDomain
type: Class
comment: Definition:A collection of concepts that indicates the reason for a "bulk supply" of medication.
subclass of: ActReason-ConceptDomain

PharmacySupplyRequestRenewalRefusalReasonCode-ConceptDomain
type: Class
comment: Definition:A collection of concepts that identifies why a renewal prescription has been refused.
subclass of: ControlActReason-ConceptDomain

PowerOfAttorney-ConceptDomain
type: Class
comment: A relationship between two people in which one person authorizes another to act for him in a manner which is a legally binding upon the person giving such authority as if he or she personally were to do the acts.
subclass of: ResponsibleParty-ConceptDomain

ResponsibleParty-ConceptDomain
type: Class
comment: The role played by a party who has legal responsibility for another party.
subclass of: AffiliationRoleType-ConceptDomain

PrescriptionDispenseFilterCode-ConceptDomain
type: Class
comment: A "helper" vocabulary used to construct complex query filters based on how and whether a prescription has been dispensed.
subclass of: QueryParameterValue-ConceptDomain

ProbabilityDistributionType-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: conceptDomain

ProcedureMethod-ConceptDomain
type: Class
comment: Identifies the technique used to perform a procedure.
subclass of: conceptDomain

ProcessingID-ConceptDomain
type: Class
comment: This attribute defines whether the message is part of a production, training, or debugging system.
subclass of: conceptDomain

ProcessingMode-ConceptDomain
type: Class
comment: This attribute defines whether the message is being sent in current processing, archive mode, initial load mode, restore from archive mode, etc.
subclass of: conceptDomain

ProductEntityType-ConceptDomain
type: Class
comment: An identifying data string for healthcare products. Example code sets include Healthcare Common Procedure Coding System (HCPCS) and Universal Product Code (UPC).
subclass of: MaterialEntityClassType-ConceptDomain

ProductProcessingOrganizationRoleType-ConceptDomain
type: Class
comment: Description: Indicates the role that an organization takes in the process by which a product goes from an original manufacturer to the eventual consumer. Examples:Manufacturer, re-processor Note:These two values are currently used in adverse event and product problem reporting.
subclass of: RoleCode-ConceptDomain

ProductSafetyReportPartyRoleType-ConceptDomain
type: Class
comment: Description:Captures the different roles that are recorded to characterize the qualifications or stations in life of persons or organizations who participate as senders or as receivers of adverse event or product problem reports. Example:Example values may include: physician, healthcare facility, attorney, family member, regulatory agency. Initial effort to find defined concepts for this value set will focus on the HIPAA provider taxonomy.
subclass of: RoleCode-ConceptDomain

ProviderCodes-ConceptDomain
type: Class
comment: Healthcare Provider Taxonomy Codes
subclass of: conceptDomain

QueryPriority-ConceptDomain
type: Class
comment: Identifies the time frame in which the response is expected.
subclass of: conceptDomain

QueryQuantityUnit-ConceptDomain
type: Class
comment: Values in this domain specify the units of a query quantity limited request.
subclass of: conceptDomain

QueryRequestLimit-ConceptDomain
type: Class
comment: Defines the units associated with the magnitude of the maximum size limit of a query response that can be accepted by the requesting application
subclass of: conceptDomain

QueryResponse-ConceptDomain
type: Class
comment: Values in this domain allow a query response system to return a precise response status.
subclass of: conceptDomain

QueryStatusCode-ConceptDomain
type: Class
comment: State attributes for Query event
subclass of: conceptDomain

Race-ConceptDomain
type: Class
comment: In the United States, federal standards for classifying data on race determine the categories used by federal agencies and exert a strong influence on categorization by state and local agencies and private sector organizations. The federal standards do not conceptually define race, and they recognize the absence of an anthropological or scientific basis for racial classification. Instead, the federal standards acknowledge that race is a social-political construct in which an individual's own identification with one more race categories is preferred to observer identification. The standards use a variety of features to define five minimum race categories. Among these features are descent from "the original peoples" of a specified region or nation. The minimum race categories are American Indian or Alaska Native, Asian, Black or African American, Native Hawaiian or Other Pacific Islander, and White. The federal standards stipulate that race data need not be limited to the five minimum categories, but any expansion must be collapsible to those categories.
subclass of: conceptDomain

Realm-ConceptDomain
type: Class
comment: When valued in an instance, this attribute signals the imposition of realm-specific constraints. The value of this attribute identifies the realm in question.
subclass of: conceptDomain

ReferralReasonCode-ConceptDomain
type: Class
comment: The reason a referral was made. Examples:Specialized Medical Assistance, Other Care Requirements.
subclass of: ActReason-ConceptDomain

RelationalName-ConceptDomain
type: Class
comment: Provides coded names for attribute RelationalExpression.elementName, which has data type SC.
subclass of: conceptDomain

RelationalOperator-ConceptDomain
type: Class
comment: Identifies common relational operators used in selection criteria.
subclass of: conceptDomain

RelationshipConjunction-ConceptDomain
type: Class
comment: A code specifying the logical conjunction of the criteria among all the condition-links of Acts (e.g., and, or, exclusive-or.) Constraints: 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.
subclass of: conceptDomain

ReligiousAffiliation-ConceptDomain
type: Class
comment: Assigment of spiritual faith affiliation
subclass of: conceptDomain

ResearchSubjectRoleBasis-ConceptDomain
type: Class
comment: Specifies the administrative functionality within a formal experimental design for which the ResearchSubject role was established. Examples: screening - role is used for pre-enrollment evaluation portion of the design; enrolled - role is used for subjects admitted to the active treatment portion of the design.
subclass of: RoleCode-ConceptDomain

ResourceGroupEntityType-ConceptDomain
type: Class
comment: Codes to characterize a Resource Group using categories that typify its membership and/or function . Example: PractitionerGroup
subclass of: EntityCode-ConceptDomain

ResponseLevel-ConceptDomain
type: Class
comment: Specifies whether a response is expected from the addressee of this interaction and what level of detail that response should include
subclass of: conceptDomain

ResponseModality-ConceptDomain
type: Class
comment: Defines the timing and grouping of the response instances.
subclass of: conceptDomain

ResponseMode-ConceptDomain
type: Class
comment: Specifies the mode, immediate versus deferred or queued, by which a receiver should communicate its receiver responsibilities.
subclass of: conceptDomain

RoleClass-ConceptDomain
type: Class
comment: This table includes codes for the Role class hierarchy. The values in this hierarchy, represent a Role which is an association or relationship between two entities - the entity that plays the role and the entity that scopes the role. Roles names are derived from the name of the playing entity in that role. The role hierarchy stems from three core concepts, or abstract domains: RoleClassOntological is an abstract domain that collects roles in which the playing entity is defined or specified by the scoping entity. RoleClassPartitive collects roles in which the playing entity is in some sense a "part" of the scoping entity. RoleClassAssociative collects all of the remaining forms of association between the playing entity and the scoping entity. This set of roles is further partitioned between: RoleClassPassive which are roles in which the playing entity is used, known, treated, handled, built, or destroyed, etc. under the auspices of the scoping entity. The playing entity is passive in these roles in that the role exists without an agreement from the playing entity. RoleClassMutualRelationship which are relationships based on mutual behavior of the two entities. The basis of these relationship may be formal agreements or they may be de facto behavior. Thus, this sub-domain is further divided into: RoleClassRelationshipFormal in which the relationship is formally defined, frequently by a contract or agreement. Personal relationship which inks two people in a personal relationship. The hierarchy discussed above is represented In the current vocabulary tables as a set of abstract domains, with the exception of the "Personal relationship" which is a leaf concept.
subclass of: conceptDomain

RoleLinkType-ConceptDomain
type: Class
comment: A code specifying the kind of connection represented by this RoleLink, e.g., has-part, has-authority.
subclass of: conceptDomain

RoleStatus-ConceptDomain
type: Class
comment: The status of an instance of the RIM Role class.
subclass of: conceptDomain

RouteOfAdministration-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: conceptDomain

SCDHEC-GISSpatialAccuracyTiers-ConceptDomain
type: Class
comment: Description: The South Carolina Department of Health and Environmental Control GIS Spatial Data Accuracy Tiers have been derived from the National Standard for Spatial Data Accuracy as a means to categorize the accuracy of spatial data assignment utilizing a variety of tools for capturing coordinates including digitizers, geocoding software and global positioning system devices.
subclass of: ActCode-ConceptDomain

Sequencing-ConceptDomain
type: Class
comment: Specifies sequence of sort order.
subclass of: conceptDomain

SetOperator-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: conceptDomain

SimpleMeasurableClinicalObservationType-ConceptDomain
type: Class
comment: Types of measurement observations typically performed in a clinical (non-lab) setting. E.g. Height, Weight, Blood-pressure
subclass of: ObservationType-ConceptDomain

SoftwareName-ConceptDomain
type: Class
comment: Provides coded names for attribute Device.softwareName, which has data type SC.
subclass of: conceptDomain

SpecialArrangement-ConceptDomain
type: Class
comment: 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.
subclass of: conceptDomain

SponsorParticipationFunction-ConceptDomain
type: Class
comment: Definition: Set of codes indicating the manner in which sponsors participate in a policy or program. NOTE: use only when the Sponsor is not further specified with a SponsorRoleType as being either a fully insured sponsor or a self insured sponsor.
subclass of: CoverageParticipationFunction-ConceptDomain

SQLConjunction-ConceptDomain
type: Class
comment: 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.
subclass of: conceptDomain

StyleType-ConceptDomain
type: Class
comment: (abstract) Used within an instance to give the author some control over various aspects of rendering
subclass of: conceptDomain

SubjectBodyPosition-ConceptDomain
type: Class
comment: Contains codes for defining the observed, physical position of a subject, such as during an observation, assessment, collection of a specimen, etc. ECG waveforms and vital signs, such as blood pressure, are two examples where a general, observed position typically needs to be noted.
subclass of: SubjectPhysicalPosition-ConceptDomain

SubstanceAdminSubstitutionNotAllowedReason-ConceptDomain
type: Class
comment: Reasons why substitution of a substance administration request is not permitted.
subclass of: ActReason-ConceptDomain

SubstanceAdminSubstitutionReason-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: ActReason-ConceptDomain

SubstitutionCondition-ConceptDomain
type: Class
comment: Identifies what sort of change is permitted or has occurred between the item that was ordered/requested and the one that was/will be provided.
subclass of: conceptDomain

SupplyOrderAbortReasonCode-ConceptDomain
type: Class
comment: Definition:A collection of concepts that indicates why the prescription should no longer be allowed to be dispensed (but can still administer what is already being dispensed).
subclass of: ControlActReason-ConceptDomain

SymptomValue-ConceptDomain
type: Class
comment: Indicates an observed abnormality in the patientaTMs condition, but does not assert causation. E.g. Runny nose, swelling, flaky skin, etc.
subclass of: IndicationValue-ConceptDomain

TableCellHorizontalAlign-ConceptDomain
type: Class
comment: These values are defined within the XHTML 4.0 Table Model
subclass of: conceptDomain

TableCellScope-ConceptDomain
type: Class
comment: These values are defined within the XHTML 4.0 Table Model
subclass of: conceptDomain

TableCellVerticalAlign-ConceptDomain
type: Class
comment: These values are defined within the XHTML 4.0 Table Model
subclass of: conceptDomain

TableFrame-ConceptDomain
type: Class
comment: These values are defined within the XHTML 4.0 Table Model
subclass of: conceptDomain

TableRules-ConceptDomain
type: Class
comment: These values are defined within the XHTML 4.0 Table Model
subclass of: conceptDomain

TargetAwareness-ConceptDomain
type: Class
comment: A code specifying the extent to which the Entity playing the participating Role (usually as a target Participation) is aware of the associated Act. Examples: For diagnostic observations, is the patient, family member or other participant aware of his terminal illness? Discussion: 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.
subclass of: conceptDomain

TelecommunicationAddressUse-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: conceptDomain

TimingEvent-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: conceptDomain

TransmissionRelationshipTypeCode-ConceptDomain
type: Class
comment: Description:A code specifying the meaning and purpose of every TransmissionRelationship instance. Each of its values implies specific constraints to what kinds of Transmission objects can be related and in which way.
subclass of: conceptDomain

TribalEntityUS-ConceptDomain
type: Class
comment: INDIAN ENTITIES RECOGNIZED AND ELIGIBLE TO RECEIVE SERVICES FROM THE UNITED STATES BUREAU OF INDIAN AFFAIRS
subclass of: conceptDomain

UnderwriterParticipationFunction-ConceptDomain
type: Class
comment: Definition: Set of codes indicating the manner in which underwriters participate in a policy or program.
subclass of: CoverageParticipationFunction-ConceptDomain

UnitOfMeasurePrefixInsens-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: UnitsOfMeasureCaseInsensitive-ConceptDomain

UnitsOfMeasureCaseInsensitive-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: conceptDomain

UnitOfMeasurePrefixSens-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: UnitsOfMeasureCaseSensitive-ConceptDomain

UnitsOfMeasureCaseSensitive-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: conceptDomain

URLScheme-ConceptDomain
type: Class
comment: A Universal Resource Locator (URL) is a type of telecommunications address specified as Internet standard RFC 1738 [http://www.isi.edu/in-notes/rfc1738.txt]. The URL specifies the protocol and the contact point defined by that protocol for the resource.
subclass of: conceptDomain

VaccineManufacturer-ConceptDomain
type: Class
comment: The manufacturer of a vaccine.
subclass of: conceptDomain

VaccineType-ConceptDomain
type: Class
comment: The kind of vaccine.
subclass of: conceptDomain

ValueSetOperator-ConceptDomain
type: Class
comment: Operations that can be used to associate concepts in a terminology.
subclass of: conceptDomain

ValueSetPropertyId-ConceptDomain
type: Class
comment: Property identifiers for a value sets
subclass of: conceptDomain

ValueSetStatus-ConceptDomain
type: Class
comment: Possible states of a value set in HL7
subclass of: conceptDomain

VerificationMethod-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: ObservationMethod-ConceptDomain

VerificationOutcomeValue-ConceptDomain
type: Class
comment: Values for observations of verification act results Examples: Verified, not verified, verified with warning.
subclass of: ObservationValue-ConceptDomain

VocabularyDomainQualifier-ConceptDomain
type: Class
comment: Vocabulary domain qualifiers are concepts that are used in domain constraints to specify behavior of the new domain.
subclass of: conceptDomain

WorkPlaceAddressUse-ConceptDomain
type: Class
comment: An office address. First choice for business related contacts during business hours.
subclass of: PostalAddressUse-ConceptDomain

X ActEncounterReason-ConceptDomain
type: Class
comment: Administrative reasons for patient encounters. Example:Medical necessity, patient request and dependency.
subclass of: ActReason-ConceptDomain

X ActMoodPermPermrq-ConceptDomain
type: Class
comment: Enumerates the moods that an Act can take when describing privileges.
subclass of: conceptDomain

X ActRelationshipPertinentInfo-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: ActRelationshipType-ConceptDomain

X ClinicalStatementActMood-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: ActMood-ConceptDomain

X ClinicalStatementEncounterMood-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: ActMood-ConceptDomain

X ClinicalStatementObservationMood-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: ActMood-ConceptDomain

X ClinicalStatementProcedureMood-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: ActMood-ConceptDomain

X ClinicalStatementSubstanceMood-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: ActMood-ConceptDomain

X ClinicalStatementSupplyMood-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: ActMood-ConceptDomain

X DocumentActMood-ConceptDomain
type: Class
comment: Used to enumerate the moods that an act can take within the body of a clinical document.
subclass of: ActMood-ConceptDomain

X DocumentEncounterMood-ConceptDomain
type: Class
comment: Used to enumerate the moods that an encounter can take within the body of a clinical document.
subclass of: ActMood-ConceptDomain

X DocumentProcedureMood-ConceptDomain
type: Class
comment: Used to enumerate the moods that a procedure can take within the body of a clinical document.
subclass of: ActMood-ConceptDomain

X DocumentSubstanceMood-ConceptDomain
type: Class
comment: Used to enumerate the moods that a substance administration can take within the body of a clinical document.
subclass of: ActMood-ConceptDomain

X EncounterAdmissionUrgency-ConceptDomain
type: Class
comment: The urgency for starting a patient encounter. Example:Routine, urgent, emergency, and elective.
subclass of: ActPriority-ConceptDomain

X EntityClassDocumentReceiving-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: EntityClass-ConceptDomain

X EntityClassPersonOrOrgReceiving-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: EntityClass-ConceptDomain

X LabSpecimenCollectionProviders-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: RoleCode-ConceptDomain

X MedicationOrImmunization-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: ActSubstanceAdministrationCode-ConceptDomain

X OrganizationNamePartType-ConceptDomain
type: Class
comment: A name for an organization, such as "Health Level Seven, Inc." An organization name consists only of untyped name parts, prefixes, suffixes, and delimiters.
subclass of: EntityNamePartType-ConceptDomain

X ParticipationEntVrf-ConceptDomain
type: Class
comment: A person that contributed to recording or validating the act.
subclass of: ParticipationType-ConceptDomain

X ParticipationPrfEntVrf-ConceptDomain
type: Class
comment: A person that performed, contributed in recording or validating the act.
subclass of: ParticipationType-ConceptDomain

X PersonNamePartType-ConceptDomain
type: Class
comment: **** MISSING DEFINITIONS ****
subclass of: EntityNamePartType-ConceptDomain

X PhoneOrEmailURLScheme-ConceptDomain
type: Class
comment: Restricts scheme to e-mail or phone numbers at which a human can be reached
subclass of: URLScheme-ConceptDomain

X PhoneURLScheme-ConceptDomain
type: Class
comment: Restricts scheme to phone numbers at which a human can be reached
subclass of: URLScheme-ConceptDomain

X PhysicalVerbalParticipationMode-ConceptDomain
type: Class
comment: Restricts participation to either physical or verbal
subclass of: ParticipationMode-ConceptDomain

X SubstitutionConditionNoneOrUnconditional-ConceptDomain
type: Class
comment: Restricts substitution to effectively a yes/no decision
subclass of: SubstitutionCondition-ConceptDomain

X VeryBasicConfidentialityKind-ConceptDomain
type: Class
comment: Limits confidentiality to effectively a yes/no decision.
subclass of: Confidentiality-ConceptDomain