Parent:

Patient Billing Account (FIAB_DM000000UV)

The Account CMET is used to identify account information.

This is the identified variant of A_Account universal

Message Type List

A_Account identified

COCT_MT110001UV01

Parent:

Patient Billing Account (FIAB_DM000000UV)

Note: This CMET replaces or revises material in the HL7 V3 2005 Normative Edition standard. It will appear in the HL7 V3 2006 Normative Edition.

The Account CMET is used to identify account information. An account is an accumulator of financial transactions (e.g. charges, debits, credits) that have either a positive or negative affect on the balance of the account. Examples of accounts are patient billing accounts, cash, credit card, Payor accounts and Payee accounts.

This CMET describes the account, type of account, effective dates for the account (e.g. for credit cards, the start/end dates), an account name (e.g. name on the credit card) and balance.

The account holder is noted, which could either be an individual or organization. If the account holder is a person, it may be useful to note the language that the account holder is conversant in.

Message Type List

A_Account universal

COCT_MT110000UV04

Parent:

Patient Billing Account (FIAB_DM000000UV)

Note: This CMET replaces or revises material in the HL7 V3 2005 Normative Edition standard. It will appear in the HL7 V3 2006 Normative Edition.

The AccountGuarantor CMET is used to identify the guarantor for a particular account (e.g. patient billing account). A guarantor takes financial responsibility over the account.

This CMET describes the account, type of account, effective dates for the account (e.g. for credit cards, the start/end dates), an account name (e.g. name on the credit card) and balance.

The account holder is noted as the guarantor, which could either be an individual or organization. If the account holder is a person, it may be useful to note the language that the account holder is conversant in. The person that scopes the guarantor (e.g. patient) may also be noted.

Message Type List

A_AccountGuarantor universal

COCT_MT110300UV04

Parent:

Patient Billing Account (FIAB_DM000000UV)

Note: This CMET will appear in the HL7 V3 2006 Normative Edition.

This is the basic variant of A_AccountPayee universal. It is a set of minimal constaints upon the universal CMET.

Message Type List

A_AccountPayee basic

COCT_MT110202UV04

Parent:

Patient Billing Account (FIAB_DM000000UV)

Note: This CMET will appear in the HL7 V3 2006 Normative Edition.

This is the identified variant of A_AccountPayee universal

Message Type List

A_AccountPayee identified

COCT_MT110201UV04

Parent:

Patient Billing Account (FIAB_DM000000UV)

Note: This CMET replaces or revises material in the HL7 V3 2005 Normative Edition standard. It will appear in the HL7 V3 2006 Normative Edition.

The AccountPayee CMET specifies the Payee, in the context of an Invoice. A Payee is a person or organization that receives payment for services rendered and/or goods provided and receives payment on behalf of one or more Providers. As well, a Payee may be a person who has directly paid the Provider and is being reimbursed by the Payor. In some cases, a Payee may be the same as the Provider.

A Payee is specified in either of 3 ways:

• [1] Payee is a known entity and has an identifier (e.g. Provider or designate organization).

  In this case, only a Payee identifier is specified.

• [2] Payee is an individual listed on the insurance policy (e.g. policy holder or covered party).

  In this case, a Payee identifier is not specified. In its place would be a relationship code from the Payee to the policy (e.g. Policy Holder). Optional information would be Payee name, address, language and bank account information. Note that bank account information and address may be not on file with the Payor.

• [3] Payee is an individual not listed on the insurance policy (e.g. guarantor).

  In this case, a Payee identifier is not specified. In its place would be a relationship code from the Payee to the policy (e.g. Guarantor). Optional information would be Payee name, address, language and bank account information. Note that bank account information and address are likely not on file with the Payor.

Message Type List

A_AccountPayee universal

COCT_MT110200UV04

Parent:

Patient Billing Account (FIAB_DM000000UV)

Note: This CMET will appear in the HL7 V3 2006 Normative Edition.

This is the contact variant of A_AccountPayor universal.

Message Type List

A_AccountPayor contact

COCT_MT110102UV04

Parent:

Patient Billing Account (FIAB_DM000000UV)

Note: This CMET will appear in the HL7 V3 2006 Normative Edition.

This is the identified variant of A_AccountPayor universal

Message Type List

A_AccountPayor identified

COCT_MT110101UV04

Parent:

Patient Billing Account (FIAB_DM000000UV)

Note: This CMET replaces or revises material in the HL7 V3 2005 Normative Edition standard. It will appear in the HL7 V3 2006 Normative Edition.

The AccountPayor CMET contains the Payor's identifier. It is used to identify the Payor in the context of an Invoice. A Payor is an organization that establishes benefit/insurance plans, determines eligibility for benefits and funds payment for Goods and/or Services provided to a Person. A Payor may retain a TPA (Third Party Administrator) or Adjudicator to perform some or all of the invoice validation, adjudication and payment. Fundamentally, a Payor is the organization that pays the adjudicated invoice.

Message Type List

A_AccountPayor universal

COCT_MT110100UV04

Parent:

Patient Billing Account (FIAB_DM000000UV)

Overview:

The A_Charge (universal) CMET supports the conveyance of invoiced charges relating to a single billable act that is being or has been provided, as indicated by the moodCode EVN.

ChargeDetail

The ChargeDetail is conveyed with the classCode INVE for invoice.

A set of one or more ChargeDetail identifier is required to be sent if available to uniquely identify the invoice in one or more accounting systems.

The ChargeDetail code, which is required to be specified by ActInvoiceDetailCode value set, provides specific information related to the type of billable act provided, e.g., the type of service provided or the type of product dispensed, or the type of financial participation incurred on the part of the guarantor for the billable act.

The ChargeDetail effectiveTime denotes the time period of the billable acts referenced by the ChargeDetail.

The ChargeDetail confidentialityCode may be sent to control the collection, access, and use of information related to this charge. The level of confidentiality is conveyed by a coded concept from the Confidentiality vocabulary domain, which includes codes indicating the types of permitted access, restriction on access, reasons for confidentiality, such as celebrity status of patient, and types of sensitive services or health condition information that requires privacy protection.

The ChargeDetail modifierCode designates a modifier to the code attribute to provide additional information about the invoice element.

The ChargeDetail unitQuantity conveys the ratio of units per service provision or product dispense, e.g., 2 hour session of physical therapy or 3 boxes of a product per dispense.

The ChargeDetail unitPriceAmt conveys the price per unit, e.g., $50 CAD/1{box} or $100 per hour of physical therapy.

The ChargeDetail netAmt is expressed using a currency {the unit in which monetary amounts are denominated in different economic regions] to express the net amount charged based on the product of applicable ChargeDetail unity quantity, unitPriceAmt, factorNumber and pointsNumber attributes.

The ChargeDetail factorNumber is the multiplier or percentage used to calculate the rate for each unitQuantity/unitPriceAmt expressed with a Real integer, e.g., the tax rate.

The ChargeDetail pointsNumber is used where the netAmt is expressed in 'points', this expresses the weighting (based on difficulty, cost and/or resource intensiveness) associated with the good or service delivered.

Links to Other Acts

A ChargeDetail may link to other acts:

Coverage for the billable act by one or more policies or programs may be conveyed using the Coverage COVBY ActRelationship association to one or more PolicyOrProgram or A_Coverage CMET. Coordination of benefits among several PolicyOrPrograms may be conveyed in priorityNumber in terms of the priority of their responsibility for coverage.

A PolicyOrProgram is represented by the classCode COV. An identifier id is required to be sent if available. It is required to be fully specified by a policy or program type from the codeActCoverageTypeCode.

The reference ActRelationship REFR may be used to associate zero or more previouse charges to a ChargeDetail.

The PreviousCharge classCode INVE indicates that this is an invoice.

The PreviousCharge moodCode EVN indicates that an instance of a previous charge invoice actually happened.

The PreviousCharge id ione or more unique identifiers is required to be sent if available.

The author AUT participation may be used to associate one or more DataEnterer with the ChargeDetail. The DataEnterRole is represented by the qualified entityclassCode QUAL. The DataEnterer id is required to be sent if available and the DataEnterer name may be sent.

A DataEntererOrganization may scope the DataEntererRole. This is an organization entity instance with one or more required identifier, and optional name and telecom.

The reason RSON ActRelationship associates a choice of Billable Acts as reasons for the charge. The RSON priorityNumber allows the charges to be prioritized for coding and billing purposes.

The BillableActChoice box enables a choice of the following CMETs to convey information related to clinical or non-clinical acts: A_Billable universal, A_SupportingClinicalInformation universal, A_Transportation universal , or the A_Observation universal. In the future, other Acts or CMETs drawn from electronic provider health records (EHR) may be included in this choice box, which would support conveyance of charge information based on EHR systems.

The inFullfillmentOf ActRelationship associates the ChargeDetail with the BillingArrangementContract, a financial contract expressed with the classCode FCNTCT in definition mood DEF.

The BillingArrangementContract code provides specific information about the type of financial contract with a coded concept from the ActBillingArrangementCode value set, e.g., fee-for-service, capitation, block grant, etc.

The BillingArrangementContract id is required to be sent if available to identify the contract.

The reference REFR ActRelationship associates the BillingArrangementContract with the FeeSchedule expressed with the classCode INVE in definition mode.

The FeeSchedule id is required be sent if available to uniquely identify a fee schedule.

The FeeSchedule code from the ActInvoiceElementCode value set provides specific information about the type of charges that may be invoiced.

The FeeSchedule may carry unitQuantity, unitPriceAmt, and netAmt if these are different or more informative than those carried in the ChargeDetail.

The pertinentInformation ActRelationship typeCode PERTassociates the A_Encounter universal with the ChargeDetail. New in this ballot: The contextControlCode has been removed, because it does not support bi-directional overrides of the patient information. One can have a business rule that R_Patient in A_Encounter overrides patient information contained in the BillableActChoice and vice versa.

Common Message Element Types Used

A_EncounterUniversal	COCT_MT010000UV01
A_TransportationUniversal	COCT_MT060000UV01
A_BillableUniversal	COCT_MT280000UV04
A_CoverageUniversal	COCT_MT510000UV06
A_SupportingClinicalStatementUniversal	COCT_MT530000UV

Message Type List

A_Charge universal

COCT_MT400000UV07

Parent:

Patient Billing Account (FIAB_DM000000UV)

Overview: .

The A_CompositeCharge (universal) CMET supports the conveyance of groups of invoiced charges relating to one or more billable act that is being or has been provided, as indicated by the moodCode EVN. These may be a series of components, which may be other charge groups or charge details. The initial group is the root group. Child groups are nodes, and all paths must end with a charge detail. The various associated classes may either be linked at the group or detail levels, or are restricted to either the group or the detail level.

The focal class is the ChargeGroup which is conveyed with the the classCode for invoice (INVE).

ChargeGroup Attributes

One or more ChargeGroup id is required to identify the ChargeGroup instance.

The ChargeGroup code, which is specified by the ActInvoiceGroupCode, is the category of billable acts charges as conveyed by one or more component ChargeGroups or ChargeDetails.

The ChargeGroup effectiveTime denotes the time period of the billable acts referenced by the ChargeGroup.

The ChargeGroup confidentialityCode is used to control the collection, access, and use of information related to this charge group. The level of confidentiality is conveyed by a coded concept from the Confidentiality vocabulary domain, which includes codes indicating the types of permitted access, restriction on access, reasons for confidentiality, such as celebrity status of patient, and types of sensitive services or health condition information that requires privacy protection. The confidentiality code selected at the ChargeGroup level may be overridden by the confidentiality code selected at the ChargeDetail level.

The ChargeGroup netAmt conveys the total of the amounts charged for each component ChargeDetail.

The focal act ChargeGroup is the root group, which must be a composite of either one or more ChargeGroup or one or more ChargeDetails. The composition is conveyed using the component ActRelationship with a sequenceNumber for structuring the hierarchy, i.e., ordering the elements from the parent groups to the detail elements.

The ChargeDetail is conveyed with the classCode for invoice (INVE).

ChargeDetail Attributes

A set of one or more ChargeDetail identifiers may be used to uniquely identify the invoice in one or more accounting systems.

The ChargeDetail code, which is specified by ActInvoiceDetailCode vocabulary domain, provides specific information related to the type of billable act provided, e.g., the type of service provided or the type of product dispensed, or the type of financial participation incurred on the part of the guarantor for the billable act.

The ChargeDetail effectiveTime denotes the time period of the billable acts referenced by the ChargeDetail.

The ChargeDetail modifierCode designates a modifier to the code attribute to provide additional information about the invoice element, e.g., body site codes or organ donor or how the service was performed.

The ChargeDetail unitQuantity conveys the ratio of units per service provision or product dispense, e.g., 2 hour session of physical therapy or 3 boxes of a product per dispense.

The ChargeDetail unitPriceAmt conveys the price per unit, e.g., $50 CAD/1{box} or $100 per hour of physical therapy.

The ChargeDetail netAmt is expressed using a currency {the unit in which monetary amounts are denominated in different economic regions] to express the net amount charged based on the product of applicable ChargeDetail unity quantity, unityPriceAmt, factorNumber and pointsNumber attributes.

The ChargeDetail factorNumber is the multiplier or percentage used to calculate the rate for each unitQuanitity/unitPriceAmt expressed with a Real integer, e.g., the tax rate.

The ChargeDetail pointsNumber is used where the netAmount is expressed in 'points', this expresses the weighting (based on difficulty, cost and/or resource intensiveness) associated with the good or service delivered.

Links to Other Acts

A ChargeDetail may link to other acts:

Coverage for the billable act by one or more policies or programs may be conveyed using the Coverage (COVBY) association to one or more PolicyOrProgram or A_Coverage CMET. Coordination of benefits among several PolicyOrPrograms may be conveyed in sequenceNumber in terms of the priority of their responsibility for coverage.

A PolicyOrProgram is represented by the classCode COV. It may have an id. It is fully specified by a policy or program type from the code vocabulary domain ActCoverageTypeCode.

The author participation may be used to associate one or more DataEnterer with the ChargeDetail. The DataEnterRole is represented by the qualified entityclassCode QUAL. The DataEnterer id is required and the DataEnterer name is optional.

A DataEntererOrganization may scope the DataEntererRole. This is an organization entity instance with one or more required identifier, name and telecom.

The reasonActRelationship associates a choice of Billable Acts as reasons for the charge only to a ChargeDetail. The reason contextControlCode is valued as additive, propagating and the contextConductionInd has default value of "true". This enables context conduction of the R_Patient from the A_Encounter through to the BillableAct, and overrides any patient role information that may be carried therein. The RSON priorityNumber allows the charges to be prioritized for coding and billing purposes.

The BillableActChoice box enables a choice of the following CMETs to convey information related to clinical or non-clinical acts: A_Billable (universal), A_SupportingClinicalInformation (universal), A_Transportation (universal) or the A_Observation (universal). In the future, other Acts or CMETs drawn from electronic provider health records (HER) may be included in this choice box, which would support conveyance of charge information based on HER systems.

The referenceActRelationship may associate the ChargeGroup or ChargeDetail with a previousCharge ChargeGroup or ChargeDetail. One or more identifiers are required.

The inFullfillmentOfActRelationship associates the ChargeGroup or ChargeDetail with the BillingArrangementContract , a financial contract expressed with the classCode FCNTCT.

The BillingArrangementContract code provides specific information about the type of financial contract with a coded concept from the ActBillingArrangementCode vocabulary domain, e.g., fee-for-service, capitation, block grant, etc.

The reference ActRelationship associates the BillingArrangementContract with the FeeSchedule expressed with the Act.classCode INV in definition mode.

The FeeSchedule id may be used to identify an item in a fee schedule.

The FeeSchedule code ActInvoiceElementCode provides specific information about the type of charges that may be invoiced.

The FeeSchedule may carry unitQuantity, unitPriceAmt, and netAmt if these are different or more informative than those carried in the ChargeDetail.

The pertinentInformation ActRelationship typeCode PERTassociates the A_Encounter universal with the ChargeDetail. New in this ballot: The contextControlCode has been removed, because it does not support bi-directional overrides of the patient information. One can have a business rule that R_Patient in A_Encounter overrides patient information contained in the BillableActChoice and vice versa.

Common Message Element Types Used

A_EncounterUniversal	COCT_MT010000UV01
A_TransportationUniversal	COCT_MT060000UV01
A_BillableUniversal	COCT_MT280000UV04
A_CoverageUniversal	COCT_MT510000UV06
A_SupportingClinicalStatementUniversal	COCT_MT530000UV

Message Type List

A_CompositeCharge universal

COCT_MT400100UV07

Parent:

Clinical Genomics (POCG_DM000023UV)

The documentaion of the GeneticLoci model can be found in the Clinical Genomics Domain / Genotype Topic / R-MIM "GeneticLoci(POCG_RM000050UV)".

Common Message Element Types Used

R_PatientClinical	COCT_MT050004UV01
R_AssignedEntityUniversal	COCT_MT090000UV01
A_SupportingClinicalInformationUniversal	COCT_MT200000UV01
A_GeneticLocusUniversal	COCT_MT930000UV

Message Type List

A_GeneticLoci universal

COCT_MT540000UV

Parent:

Clinical Genomics (POCG_DM000023UV)

The documentation of the GeneticLocus model can be found in the Clinical Genomics Domain / Genotype Topic / R-MIM "GeneticLocus(POCG_RM000010UV)".

Common Message Element Types Used

R_AssignedEntityUniversal	COCT_MT090000UV01
A_SupportingClinicalInformationUniversal	COCT_MT200000UV01

Message Type List

A_GeneticLocus universal

COCT_MT930000UV

Parent:

None

Note: This is the second Normative ballot of the A_ValuedItem CMET. There are several variants: universal, basic, minimal, definitional, informational, and identifiable.

Overview

This CMET is used to convey information related to a ValuedItem in terms of its measurable or countable units. All Variants may include pricing information needed to calculate the net amount. In the minimal, basic, and universal variants, the ValuedItem may be composed of one or more ValuedUnitItems, which may or may not be priced. The universal and basic variants include coverage related information such as charges, financial participation, fee schedule, and coverage policies such as the health status of the subject of care that is conveyed in the A_Benefit CMET.

The identified variant is used to convey the identity of the ValuedItem information in the definition mood. The identifier is mandatory for the identified variant.

The definitional variant is used to convey the identity of the ValuedItem information in the definition mood. The identifier is optional for this variant.

The informational variant is used to convey the ValuedItem information in the definition or event mood. The identifier is required for this variant.

The minimal variant is used to convey optionally identifiable ValuedItem information in the definition or event mood, which may be composed of ValuedUnitItems.

The basic variant may include association to policy or program benefits to which it pertains, which are conveyed in the A_Benefit (basic) CMET COCT_MT770005UV.

The universal variant is used to convey more extensive ValuedItem information typical of knowledge base and payer benefit repository records.

How the ValuedUnitItem is used to compose a ValuedItem: A DME provider prices the frame and "add-on" components required to meet health needs of the patient. Component ValuedUnitItems may convey the InvoiceDetailCode for DME, e.g., UPC codes, and the unitPriceAmt for each part. For example, a DME provider prices the frame and "add-on" components required to meet health needs of the patient. Component ValuedUnitItems may convey the InvoiceDetailCode for DME, e.g., UPC codes, and the unitPriceAmt for each part. For an example see: DME_Table.doc

How Pricing is used:For each variant, one and only one ValuedItem is required to be sent. For the basic and universal variant, one or more ValuedUnitItem may be sent. If the act.mood of the ValuedItem or any ValuedUnitItems is in definition mood, the price may be as yet unspecified. In this case, the MO numerator for unspecified price is constrained to "UNK" for "unknown"; the PQ property denominator must be nonNull; and the netAmt is not valued. For example, in the case of product labeling, only the valued countable or measurable item is defined, but the price per unit or net amount is not yet determined.

If ValuedItem is in event mood and no ValuedUnitItem is sent, then the ValuedItem netAmt must be sent as the product of the ValuedItem unitPricedAmt and unitQuantity.

See Foundation Section 3.1.12 Class: InvoiceElement (in Acts) "For leaf-level amounts, this will be the value of the unitQuantity * unitPriceAmt [ * factorNumber] [* pointsNumber]. For grouping invoice elements, this will be the sum of the netAmt attributes of all contained InvoiceElements http://hl7.org/v3ballot/html/infrastructure/rim/rim.htm#InvoiceElement-cls

If any ValuedUnitItem act.mood is event, then the ValuedItem act.mood must be event. In this case, any ValuedUnitItem unitQuantity and unitPriceAmt attributes must be nonNull, and the ValuedUnitItem netAmt must be the product of these attributes. In addition, the ValuedItem netAmt must be the sum of any ValuedUnitItem netAmts. Since a ValuedItem unitPriceAmt is required to be sent, the MO numerator and PQ denominator must either both be UNK; or MO numerator must be equal to the ValuedItem netAmt and the PQ denominator must have a fixed value of 1.

NOTE: The RTO is NI because the MO numerator for unspecified price is set to "UNK" for "unknown" while the PQ denominator is nonNull. However, because RTO is NI, to ensure that there is information contained in the ratio, the unitPriceAmt is required with cardinality of 1...1. Thus:

<value xsi:type="RTO" nullFlavor="NI"> <numerator xsi:type="MO" nullFlavor="UNK"/> <denominator xsi:type="PQ" value="50" unit="mg"/> </value>

For more information see http://hl7.org/v3ballot/html/infrastructure/itsxml/datatypes-its-xml.htm#dtimpl-RTO

For more information on the derivation of CMET variants, see Refinement, Constraint and Localization, Release 2 Section 2.4.2 Common Message Element Types (CMETs) http://hl7.org/v3ballot/html/infrastructure/constraints/constraints.htm

Walk-through

ValuedItem

The ValuedItem classCode INVE: The focal class indicates the countable or measurable item (e.g., a product, device, or service) that may be or has been priced.

The ValuedItem moodCodeActMoodDefEvn: The ValuedItem is something that may be or has been priced.

The ValuedItem id: Optionally identifies an instance of ValuedItem information, e.g. as used on a particular product label.

The ValuedItem code from the ActInvoiceDetailCode concept domain, to which value set may be bound to provide specific information about the type of items that that may be or has been priced. For example, if the ActInvoiceDetailDrugProduct sub-concept domain is used, then the value set could include NDC, UPC or GTIN. When this code is the same as the code on a class in the base model to which this CMET is associated, do not valued this attribute or ensure that the codes are the same. For example, a Medication message may include the NDC code used in this CMET's attribute in an Entity class describing the drug.

The ValuedItem effectiveTime indicates the time during which ValuedItem information is effective.

The ValuedItem unitQuantityRTO<PQ,PQ> specifies the units by which the ValuedItem is measured or counted, and quantifies the countable or measurable ValuedItem instances. Required to be sent if known. The PQ units and values are aligned with the type of ValuedItem specified by the value set or coding system bound to the ValuedItem InvoiceDetailCode or its child concept domain.

For example, if the ActInvoiceDetailDrugCode is bound to the NDC codes, then the PQ unit value set is the NCPDP Billing Unit Standard http://www.ncpdp.org/PDF/Basic_guide_to_standards.pdf. For more information see Foundation Section 3.1.12.2 InvoiceElement.unitQuantity: RTO<PQ,PQ> (0..1).

One and only one ValuedItem unitPriceAmtRTO<MO,PQ> is required to be sent to quantify the ratio of the price per countable or measurable instance of an item that may be or has been priced. If the act.mood of the ValuedItem is in definition mood, the price may be as yet unspecified. In this case, the MO numerator for unspecified price is constrained to "UNK" for "unknown"; the PQ denominator must be nonNull; and the netAmt is not valued. For example, in the case of product labeling, only the valued countable or measurable item is defined, but the price per unit or net amount is not yet determined.

The ValuedItem netAmtMO may be sent to express the product of the ValuedItem unitQuantity and the unitPriceAmt. If the unitPriceAmt MO is UNK, then the netAmt is UNK or not sent. If any ValuedUnitItem act.mood is event, then the ValuedItem act.mood must be event. In this case, any ValuedUnitItem unitQuantity and unitPriceAmt attributes must be nonNull, and the ValuedUnitItem netAmt must be the product of these attributes. In addition, the ValuedItem netAmt must be the sum of any ValuedUnitItem netAmts. Since a ValuedItem unitPriceAmt is required to be sent, the MO numerator and PQ denominator must either be both be UNK; or MO numerator must be equal to the ValuedItem netAmt and the PQ denominator must have a fixed value of '1'.

The ValuedItem factorNumberREAL may be sent to represent a multiplier used in determining the overall cost of services delivered and/or goods received. The concept of a Factor allows for a discount or surcharge multiplier to be applied to a monetary amount. For example, the formula, with a factor would be: unitQuantity * unitPrice (Cost/Point) * factorNumber = netAmt.

The ValuedItem pointNumberMO may be sent to express the weighting (based on difficulty, cost and/or resource intensiveness) associated with the good or service delivered. The concept of Points allows for assignment of point values for services and/or goods, such that a monetary amount can be assigned to each point. For example, the formula, with points would be: unitQuantity * pointsNumber * unitPriceAmt (Cost/Point) = netAmt.

For more information see Foundation Section 3.1.12

The ActRelationship typeCode COMP: The ValuedItem may be linked to zero or more ValuedUnitItems. The component association indicates that the ValuedItem may be comprised of one or more ValuedUnitItems, which may or may not be priced.

Constraint: If any ValuedUnitItems are priced, then theValuedItem netAmount is the sum of these component prices, and the ValuedItem unitPriceAmt must not be valued .

ValuedUnitItem

ValuedUnitItem classCode INVE: The focal class indicates the countable or measurable unit item (e.g., a product, device, or service) that are components to a ValuedItem. A ValuedUnitItem may be or has been priced.

The ValuedUnitItem moodCode: The mood of this act is ActMoodDefEvn, that is, a ValuedUnitItem is something that may be or has been priced.

The ValuedUnitItem id: Optionally identifies an instance of ValuedUnitItem information, e.g. as used on a particular product label.

The ValuedUnitItem code from the ActInvoiceDetailCode concept domain, to which value set may be bound to provide specific information about the type of unit items that that may be or has been priced. For example, if the ActInvoiceDetailDrugProduct sub-concept domain is used, then the value set could include NDC, UPC or GTIN. When this code is the same as the code on a class in the base model to which this CMET is associated, do not valued this attribute or ensure that the codes are the same. For example, a Medication message may include the NDC code used in this CMET's attribute in an Entity class describing the drug.

The ValuedUnitItem effectiveTime indicates the time during which ValuedItem information is effective.

The ValuedUnitItem unitQuantityRTO<PQ,PQ> specifies the units by which the ValuedUnitItem is measured or counted, and quantifies the countable or measurable ValuedItem instances. Required to be sent if known. The PQ units and values are aligned with the type of ValuedUnitItem specified by the value set or coding system bound to the ValuedItem InvoiceDetailCode or its child concept domain.

For example, if the ActInvoiceDetailDrugCode is bound to the NDC codes, then the PQ unit value set is the NCPDP Billing Unit Standard http://www.ncpdp.org/PDF/Basic_guide_to_standards.pdf. For more information see Foundation Section 3.1.12.2 InvoiceElement.unitQuantity: RTO<PQ,PQ> (0..1)

One and only one ValuedUnitItem unitPriceAmtRTO<MO,PQ> is required to be sent to quantify the ratio of the price per countable or measurable instance of an item that may be or has been priced. If the act.mood of the ValuedUnitItem is in definition mood, the price may be as yet unspecified. In this case, the MO numerator for unspecified price is constrained to "UNK" for "unknown"; the PQ denominator must be nonNull; and the netAmt is not valued. For example, in the case of product labeling, only the valued countable or measurable item is defined, but the price per unit or net amount is not yet determined.

The ValuedUnitItem netAmtMO may be sent to express the product of the ValuedUnitItem unitQuantity and the unitPriceAmt. If the unitPriceAmt MO numerator is UNK, then the netAmt is UNK or not sent.

The ValuedUnitItem factorNumberREAL may be sent to represent a multiplier used in determining the overall cost of services delivered and/or goods received. The concept of a Factor allows for a discount or surcharge multiplier to be applied to a monetary amount. For example, the formula, with a factor would be: unitQuantity * unitPrice (Cost/Point) * factorNumber = netAmt.

The ValuedUnitItem pointNumberMO may be sent to express the weighting (based on difficulty, cost and/or resource intensiveness) associated with the good or service delivered. The concept of Points allows for assignment of point values for services and/or goods, such that a monetary amount can be assigned to each point. For example, the formula, with points would be: unitQuantity * pointsNumber * unitPriceAmt (Cost/Point) = netAmt.

The ActRelationship typeCodePERT: The ValuedItem may be linked to zero or more A_Benefit (basic) CMET. The association indicates that the ValuedItem may pertain to zero or more benefits under a Program or Policy.

Common Message Element Types Used

A_BenefitBasic

COCT_MT770005UV09

Message Type List

A_ValuedItem basic

COCT_MT440005UV09

Parent:

None

Note: This is the second Normative ballot of the A_ValuedItem CMET. There are several variants: universal, basic, minimal, definitional, informational, and identifiable.

Overview

This CMET is used to convey information related to a ValuedItem in terms of its measurable or countable units. All Variants may include pricing information needed to calculate the net amount. In the minimal, basic, and universal variants, the ValuedItem may be composed of one or more ValuedUnitItems, which may or may not be priced. The universal and basic variants include coverage related information such as charges, financial participation, fee schedule, and coverage policies such as the health status of the subject of care that is conveyed in the A_Benefit CMET.

The identified variant is used to convey the identity of the ValuedItem information in the definition mood. The identifier is mandatory for the identified variant.

The definitional variant is used to convey the identity of the ValuedItem information in the definition mood. The identifier is optional for this variant.

The informational variant is used to convey the ValuedItem information in the definition or event mood. The identifier is required for this variant.

The minimal variant is used to convey optionally identifiable ValuedItem information in the definition or event mood, which may be composed of ValuedUnitItems.

The basic variant may include association to policy or program benefits to which it pertains, which are conveyed in the A_Benefit (basic) CMET COCT_MT770005UV.

The universal variant is used to convey more extensive ValuedItem information typical of knowledge base and payer benefit repository records.

How the ValuedUnitItem is used to compose a ValuedItem: A DME provider prices the frame and "add-on" components required to meet health needs of the patient. Component ValuedUnitItems may convey the InvoiceDetailCode for DME, e.g., UPC codes, and the unitPriceAmt for each part. For example, a DME provider prices the frame and "add-on" components required to meet health needs of the patient. Component ValuedUnitItems may convey the InvoiceDetailCode for DME, e.g., UPC codes, and the unitPriceAmt for each part. For an example see: DME_Table.doc

How Pricing is used:For each variant, one and only one ValuedItem is required to be sent. For the basic and universal variant, one or more ValuedUnitItem may be sent. If the act.mood of the ValuedItem or any ValuedUnitItems is in definition mood, the price may be as yet unspecified. In this case, the MO numerator for unspecified price is constrained to "UNK" for "unknown"; the PQ property denominator must be nonNull; and the netAmt is not valued. For example, in the case of product labeling, only the valued countable or measurable item is defined, but the price per unit or net amount is not yet determined.

If ValuedItem is in event mood and no ValuedUnitItem is sent, then the ValuedItem netAmt must be sent as the product of the ValuedItem unitPricedAmt and unitQuantity.

See Foundation Section 3.1.12 Class: InvoiceElement (in Acts) "For leaf-level amounts, this will be the value of the unitQuantity * unitPriceAmt [ * factorNumber] [* pointsNumber]. For grouping invoice elements, this will be the sum of the netAmt attributes of all contained InvoiceElements http://hl7.org/v3ballot/html/infrastructure/rim/rim.htm#InvoiceElement-cls

If any ValuedUnitItem act.mood is event, then the ValuedItem act.mood must be event. In this case, any ValuedUnitItem unitQuantity and unitPriceAmt attributes must be nonNull, and the ValuedUnitItem netAmt must be the product of these attributes. In addition, the ValuedItem netAmt must be the sum of any ValuedUnitItem netAmts. Since a ValuedItem unitPriceAmt is required to be sent, the MO numerator and PQ denominator must either both be UNK; or MO numerator must be equal to the ValuedItem netAmt and the PQ denominator must have a fixed value of 1.

NOTE: The RTO is NI because the MO numerator for unspecified price is set to "UNK" for "unknown" while the PQ denominator is nonNull. However, because RTO is NI, to ensure that there is information contained in the ratio, the unitPriceAmt is required with cardinality of 1...1. Thus:

<value xsi:type="RTO" nullFlavor="NI"> <numerator xsi:type="MO" nullFlavor="UNK"/> <denominator xsi:type="PQ" value="50" unit="mg"/> </value>

For more information see http://hl7.org/v3ballot/html/infrastructure/itsxml/datatypes-its-xml.htm#dtimpl-RTO

For more information on the derivation of CMET variants, see Refinement, Constraint and Localization, Release 2 Section 2.4.2 Common Message Element Types (CMETs) http://hl7.org/v3ballot/html/infrastructure/constraints/constraints.htm

Walk-through

ValuedItem

The ValuedItem classCode INVE: The focal class indicates the countable or measurable item (e.g., a product, device, or service) that may be or has been priced.

The ValuedItem moodCodeDEF: The ValuedItem is something that may be or has been priced.

The ValuedItem id: Optionally identifies an instance of ValuedItem information, e.g. as used on a particular product label.

The ValuedItem code from the ActInvoiceDetailCode concept domain, to which value set may be bound to provide specific information about the type of items that that may be or has been priced. For example, if the ActInvoiceDetailDrugProduct sub-concept domain is used, then the value set could include NDC, UPC or GTIN. When this code is the same as the code on a class in the base model to which this CMET is associated, do not valued this attribute or ensure that the codes are the same. For example, a Medication message may include the NDC code used in this CMET's attribute in an Entity class describing the drug.

The ValuedItem effectiveTime indicates the time during which ValuedItem information is effective.

The ValuedItem unitQuantityRTO<PQ,PQ> specifies the units by which the ValuedItem is measured or counted, and quantifies the countable or measurable ValuedItem instances. Required to be sent if known. The PQ units and values are aligned with the type of ValuedItem specified by the value set or coding system bound to the ValuedItem InvoiceDetailCode or its child concept domain.

For example, if the ActInvoiceDetailDrugCode is bound to the NDC codes, then the PQ unit value set is the NCPDP Billing Unit Standard http://www.ncpdp.org/PDF/Basic_guide_to_standards.pdf. For more information see Foundation Section 3.1.12.2 InvoiceElement.unitQuantity: RTO<PQ,PQ> (0..1).

One and only one ValuedItem unitPriceAmtRTO<MO,PQ> is required to be sent to quantify the ratio of the price per countable or measurable instance of an item that may be or has been priced. If the act.mood of the ValuedItem is in definition mood, the price may be as yet unspecified. In this case, the MO numerator for unspecified price is constrained to "UNK" for "unknown"; the PQ denominator must be nonNull; and the netAmt is not valued. For example, in the case of product labeling, only the valued countable or measurable item is defined, but the price per unit or net amount is not yet determined.

The ValuedItem netAmtMO may be sent to express the product of the ValuedItem unitQuantity and the unitPriceAmt. If the unitPriceAmt MO is UNK, then the netAmt is UNK or not sent. If any ValuedUnitItem act.mood is event, then the ValuedItem act.mood must be event. In this case, any ValuedUnitItem unitQuantity and unitPriceAmt attributes must be nonNull, and the ValuedUnitItem netAmt must be the product of these attributes. In addition, the ValuedItem netAmt must be the sum of any ValuedUnitItem netAmts. Since a ValuedItem unitPriceAmt is required to be sent, the MO numerator and PQ denominator must either be both be UNK; or MO numerator must be equal to the ValuedItem netAmt and the PQ denominator must have a fixed value of '1'.

The ValuedItem factorNumberREAL may be sent to represent a multiplier used in determining the overall cost of services delivered and/or goods received. The concept of a Factor allows for a discount or surcharge multiplier to be applied to a monetary amount. For example, the formula, with a factor would be: unitQuantity * unitPrice (Cost/Point) * factorNumber = netAmt.

The ValuedItem pointNumberMO may be sent to express the weighting (based on difficulty, cost and/or resource intensiveness) associated with the good or service delivered. The concept of Points allows for assignment of point values for services and/or goods, such that a monetary amount can be assigned to each point. For example, the formula, with points would be: unitQuantity * pointsNumber * unitPriceAmt (Cost/Point) = netAmt.

For more information see Foundation Section 3.1.12

Message Type List

A_ValuedItem definitional

COCT_MT440006UV09

Parent:

None

Note: This is the second Normative ballot of the A_ValuedItem CMET. There are several variants: universal, basic, minimal, definitional, informational, and identifiable.

Overview

This CMET is used to convey information related to a ValuedItem in terms of its measurable or countable units. All Variants may include pricing information needed to calculate the net amount. In the minimal, basic, and universal variants, the ValuedItem may be composed of one or more ValuedUnitItems, which may or may not be priced. The universal and basic variants include coverage related information such as charges, financial participation, fee schedule, and coverage policies such as the health status of the subject of care that is conveyed in the A_Benefit CMET.

The identified variant is used to convey the identity of the ValuedItem information in the definition mood. The identifier is mandatory for the identified variant.

The definitional variant is used to convey the identity of the ValuedItem information in the definition mood. The identifier is optional for this variant.

The informational variant is used to convey the ValuedItem information in the definition or event mood. The identifier is required for this variant.

The minimal variant is used to convey optionally identifiable ValuedItem information in the definition or event mood, which may be composed of ValuedUnitItems.

The basic variant may include association to policy or program benefits to which it pertains, which are conveyed in the A_Benefit (basic) CMET COCT_MT770005UV.

The universal variant is used to convey more extensive ValuedItem information typical of knowledge base and payer benefit repository records.

How the ValuedUnitItem is used to compose a ValuedItem: A DME provider prices the frame and "add-on" components required to meet health needs of the patient. Component ValuedUnitItems may convey the InvoiceDetailCode for DME, e.g., UPC codes, and the unitPriceAmt for each part. For example, a DME provider prices the frame and "add-on" components required to meet health needs of the patient. Component ValuedUnitItems may convey the InvoiceDetailCode for DME, e.g., UPC codes, and the unitPriceAmt for each part. For an example see: DME_Table.doc

How Pricing is used:For each variant, one and only one ValuedItem is required to be sent. For the basic and universal variant, one or more ValuedUnitItem may be sent. If the act.mood of the ValuedItem or any ValuedUnitItems is in definition mood, the price may be as yet unspecified. In this case, the MO numerator for unspecified price is constrained to "UNK" for "unknown"; the PQ property denominator must be nonNull; and the netAmt is not valued. For example, in the case of product labeling, only the valued countable or measurable item is defined, but the price per unit or net amount is not yet determined.

If ValuedItem is in event mood and no ValuedUnitItem is sent, then the ValuedItem netAmt must be sent as the product of the ValuedItem unitPricedAmt and unitQuantity.

See Foundation Section 3.1.12 Class: InvoiceElement (in Acts) "For leaf-level amounts, this will be the value of the unitQuantity * unitPriceAmt [ * factorNumber] [* pointsNumber]. For grouping invoice elements, this will be the sum of the netAmt attributes of all contained InvoiceElements http://hl7.org/v3ballot/html/infrastructure/rim/rim.htm#InvoiceElement-cls

If any ValuedUnitItem act.mood is event, then the ValuedItem act.mood must be event. In this case, any ValuedUnitItem unitQuantity and unitPriceAmt attributes must be nonNull, and the ValuedUnitItem netAmt must be the product of these attributes. In addition, the ValuedItem netAmt must be the sum of any ValuedUnitItem netAmts. Since a ValuedItem unitPriceAmt is required to be sent, the MO numerator and PQ denominator must either both be UNK; or MO numerator must be equal to the ValuedItem netAmt and the PQ denominator must have a fixed value of 1.

NOTE: The RTO is NI because the MO numerator for unspecified price is set to "UNK" for "unknown" while the PQ denominator is nonNull. However, because RTO is NI, to ensure that there is information contained in the ratio, the unitPriceAmt is required with cardinality of 1...1. Thus:

<value xsi:type="RTO" nullFlavor="NI"> <numerator xsi:type="MO" nullFlavor="UNK"/> <denominator xsi:type="PQ" value="50" unit="mg"/> </value>

For more information see http://hl7.org/v3ballot/html/infrastructure/itsxml/datatypes-its-xml.htm#dtimpl-RTO

For more information on the derivation of CMET variants, see Refinement, Constraint and Localization, Release 2 Section 2.4.2 Common Message Element Types (CMETs) http://hl7.org/v3ballot/html/infrastructure/constraints/constraints.htm

Walk-through

ValuedItem

The ValuedItem classCode INVE: The focal class indicates the countable or measurable item (e.g., a product, device, or service) that may be or has been priced.

The ValuedItem moodCodeActMoodDefEvn: The ValuedItem is something that may be or has been priced.

The ValuedItem id: Shall be used to identify an instance of ValuedItem information, e.g. as used on a particular product label.

The ValuedItem code from the ActInvoiceDetailCode concept domain, to which value set may be bound to provide specific information about the type of items that that may be or has been priced. For example, if the ActInvoiceDetailDrugProduct sub-concept domain is used, then the value set could include NDC, UPC or GTIN. When this code is the same as the code on a class in the base model to which this CMET is associated, do not valued this attribute or ensure that the codes are the same. For example, a Medication message may include the NDC code used in this CMET's attribute in an Entity class describing the drug.

The ValuedItem effectiveTime indicates the time during which ValuedItem information is effective.

The ValuedItem unitQuantityRTO<PQ,PQ> specifies the units by which the ValuedItem is measured or counted, and quantifies the countable or measurable ValuedItem instances. Required to be sent if known. The PQ units and values are aligned with the type of ValuedItem specified by the value set or coding system bound to the ValuedItem InvoiceDetailCode or its child concept domain.

For example, if the ActInvoiceDetailDrugCode is bound to the NDC codes, then the PQ unit value set is the NCPDP Billing Unit Standard http://www.ncpdp.org/PDF/Basic_guide_to_standards.pdf. For more information see Foundation Section 3.1.12.2 InvoiceElement.unitQuantity: RTO<PQ,PQ> (0..1).

One and only one ValuedItem unitPriceAmtRTO<MO,PQ> is required to be sent to quantify the ratio of the price per countable or measurable instance of an item that may be or has been priced. If the act.mood of the ValuedItem is in definition mood, the price may be as yet unspecified. In this case, the MO numerator for unspecified price is constrained to "UNK" for "unknown"; the PQ denominator must be nonNull; and the netAmt is not valued. For example, in the case of product labeling, only the valued countable or measurable item is defined, but the price per unit or net amount is not yet determined.

The ValuedItem netAmtMO may be sent to express the product of the ValuedItem unitQuantity and the unitPriceAmt. If the unitPriceAmt MO is UNK, then the netAmt is UNK or not sent. If any ValuedUnitItem act.mood is event, then the ValuedItem act.mood must be event. In this case, any ValuedUnitItem unitQuantity and unitPriceAmt attributes must be nonNull, and the ValuedUnitItem netAmt must be the product of these attributes. In addition, the ValuedItem netAmt must be the sum of any ValuedUnitItem netAmts. Since a ValuedItem unitPriceAmt is required to be sent, the MO numerator and PQ denominator must either be both be UNK; or MO numerator must be equal to the ValuedItem netAmt and the PQ denominator must have a fixed value of '1'.

The ValuedItem factorNumberREAL may be sent to represent a multiplier used in determining the overall cost of services delivered and/or goods received. The concept of a Factor allows for a discount or surcharge multiplier to be applied to a monetary amount. For example, the formula, with a factor would be: unitQuantity * unitPrice (Cost/Point) * factorNumber = netAmt.

The ValuedItem pointNumberMO may be sent to express the weighting (based on difficulty, cost and/or resource intensiveness) associated with the good or service delivered. The concept of Points allows for assignment of point values for services and/or goods, such that a monetary amount can be assigned to each point. For example, the formula, with points would be: unitQuantity * pointsNumber * unitPriceAmt (Cost/Point) = netAmt.

For more information see Foundation Section 3.1.12

Message Type List

A_ValuedItem identified

COCT_MT440001UV09

Parent:

None

Note: This is the second Normative ballot of the A_ValuedItem CMET. There are several variants: universal, basic, minimal, definitional, informational, and identifiable.

Overview

This CMET is used to convey information related to a ValuedItem in terms of its measurable or countable units. All Variants may include pricing information needed to calculate the net amount. In the minimal, basic, and universal variants, the ValuedItem may be composed of one or more ValuedUnitItems, which may or may not be priced. The universal and basic variants include coverage related information such as charges, financial participation, fee schedule, and coverage policies such as the health status of the subject of care that is conveyed in the A_Benefit CMET.

The identified variant is used to convey the identity of the ValuedItem information in the definition mood. The identifier is mandatory for the identified variant.

The definitional variant is used to convey the identity of the ValuedItem information in the definition mood. The identifier is optional for this variant.

The informational variant is used to convey the ValuedItem information in the definition or event mood. The identifier is required for this variant.

The minimal variant is used to convey optionally identifiable ValuedItem information in the definition or event mood, which may be composed of ValuedUnitItems.

The basic variant may include association to policy or program benefits to which it pertains, which are conveyed in the A_Benefit (basic) CMET COCT_MT770005UV.

The universal variant is used to convey more extensive ValuedItem information typical of knowledge base and payer benefit repository records.

How the ValuedUnitItem is used to compose a ValuedItem: A DME provider prices the frame and "add-on" components required to meet health needs of the patient. Component ValuedUnitItems may convey the InvoiceDetailCode for DME, e.g., UPC codes, and the unitPriceAmt for each part. For example, a DME provider prices the frame and "add-on" components required to meet health needs of the patient. Component ValuedUnitItems may convey the InvoiceDetailCode for DME, e.g., UPC codes, and the unitPriceAmt for each part. For an example see: DME_Table.doc

How Pricing is used:For each variant, one and only one ValuedItem is required to be sent. For the basic and universal variant, one or more ValuedUnitItem may be sent. If the act.mood of the ValuedItem or any ValuedUnitItems is in definition mood, the price may be as yet unspecified. In this case, the MO numerator for unspecified price is constrained to "UNK" for "unknown"; the PQ property denominator must be nonNull; and the netAmt is not valued. For example, in the case of product labeling, only the valued countable or measurable item is defined, but the price per unit or net amount is not yet determined.

If ValuedItem is in event mood and no ValuedUnitItem is sent, then the ValuedItem netAmt must be sent as the product of the ValuedItem unitPricedAmt and unitQuantity.

See Foundation Section 3.1.12 Class: InvoiceElement (in Acts) "For leaf-level amounts, this will be the value of the unitQuantity * unitPriceAmt [ * factorNumber] [* pointsNumber]. For grouping invoice elements, this will be the sum of the netAmt attributes of all contained InvoiceElements http://hl7.org/v3ballot/html/infrastructure/rim/rim.htm#InvoiceElement-cls

If any ValuedUnitItem act.mood is event, then the ValuedItem act.mood must be event. In this case, any ValuedUnitItem unitQuantity and unitPriceAmt attributes must be nonNull, and the ValuedUnitItem netAmt must be the product of these attributes. In addition, the ValuedItem netAmt must be the sum of any ValuedUnitItem netAmts. Since a ValuedItem unitPriceAmt is required to be sent, the MO numerator and PQ denominator must either both be UNK; or MO numerator must be equal to the ValuedItem netAmt and the PQ denominator must have a fixed value of 1.

NOTE: The RTO is NI because the MO numerator for unspecified price is set to "UNK" for "unknown" while the PQ denominator is nonNull. However, because RTO is NI, to ensure that there is information contained in the ratio, the unitPriceAmt is required with cardinality of 1...1. Thus:

<value xsi:type="RTO" nullFlavor="NI"> <numerator xsi:type="MO" nullFlavor="UNK"/> <denominator xsi:type="PQ" value="50" unit="mg"/> </value>

For more information see http://hl7.org/v3ballot/html/infrastructure/itsxml/datatypes-its-xml.htm#dtimpl-RTO

For more information on the derivation of CMET variants, see Refinement, Constraint and Localization, Release 2 Section 2.4.2 Common Message Element Types (CMETs) http://hl7.org/v3ballot/html/infrastructure/constraints/constraints.htm

Walk-through

ValuedItem

The ValuedItem classCode INVE: The focal class indicates the countable or measurable item (e.g., a product, device, or service) that may be or has been priced.

The ValuedItem moodCodeActMoodDefEvn: The ValuedItem is something that may be or has been priced.

The ValuedItem id: Optionally identifies an instance of ValuedItem information, e.g. as used on a particular product label.

The ValuedItem code from the ActInvoiceDetailCode concept domain, to which value set may be bound to provide specific information about the type of items that that may be or has been priced. For example, if the ActInvoiceDetailDrugProduct sub-concept domain is used, then the value set could include NDC, UPC or GTIN. When this code is the same as the code on a class in the base model to which this CMET is associated, do not valued this attribute or ensure that the codes are the same. For example, a Medication message may include the NDC code used in this CMET's attribute in an Entity class describing the drug.

The ValuedItem effectiveTime indicates the time during which ValuedItem information is effective.

The ValuedItem unitQuantityRTO<PQ,PQ> specifies the units by which the ValuedItem is measured or counted, and quantifies the countable or measurable ValuedItem instances. Required to be sent if known. The PQ units and values are aligned with the type of ValuedItem specified by the value set or coding system bound to the ValuedItem InvoiceDetailCode or its child concept domain.

For example, if the ActInvoiceDetailDrugCode is bound to the NDC codes, then the PQ unit value set is the NCPDP Billing Unit Standard http://www.ncpdp.org/PDF/Basic_guide_to_standards.pdf. For more information see Foundation Section 3.1.12.2 InvoiceElement.unitQuantity: RTO<PQ,PQ> (0..1).

One and only one ValuedItem unitPriceAmtRTO<MO,PQ> is required to be sent to quantify the ratio of the price per countable or measurable instance of an item that may be or has been priced. If the act.mood of the ValuedItem is in definition mood, the price may be as yet unspecified. In this case, the MO numerator for unspecified price is constrained to "UNK" for "unknown"; the PQ denominator must be nonNull; and the netAmt is not valued. For example, in the case of product labeling, only the valued countable or measurable item is defined, but the price per unit or net amount is not yet determined.

The ValuedItem netAmtMO may be sent to express the product of the ValuedItem unitQuantity and the unitPriceAmt. If the unitPriceAmt MO is UNK, then the netAmt is UNK or not sent. If any ValuedUnitItem act.mood is event, then the ValuedItem act.mood must be event. In this case, any ValuedUnitItem unitQuantity and unitPriceAmt attributes must be nonNull, and the ValuedUnitItem netAmt must be the product of these attributes. In addition, the ValuedItem netAmt must be the sum of any ValuedUnitItem netAmts. Since a ValuedItem unitPriceAmt is required to be sent, the MO numerator and PQ denominator must either be both be UNK; or MO numerator must be equal to the ValuedItem netAmt and the PQ denominator must have a fixed value of '1'.

The ValuedItem factorNumberREAL may be sent to represent a multiplier used in determining the overall cost of services delivered and/or goods received. The concept of a Factor allows for a discount or surcharge multiplier to be applied to a monetary amount. For example, the formula, with a factor would be: unitQuantity * unitPrice (Cost/Point) * factorNumber = netAmt.

The ValuedItem pointNumberMO may be sent to express the weighting (based on difficulty, cost and/or resource intensiveness) associated with the good or service delivered. The concept of Points allows for assignment of point values for services and/or goods, such that a monetary amount can be assigned to each point. For example, the formula, with points would be: unitQuantity * pointsNumber * unitPriceAmt (Cost/Point) = netAmt.

For more information see Foundation Section 3.1.12

Message Type List

A_ValuedItem informational

COCT_MT440007UV09

Parent:

None

Note: This is the second Normative ballot of the A_ValuedItem CMET. There are several variants: universal, basic, minimal, definitional, informational, and identifiable.

Overview

This CMET is used to convey information related to a ValuedItem in terms of its measurable or countable units. All Variants may include pricing information needed to calculate the net amount. In the minimal, basic, and universal variants, the ValuedItem may be composed of one or more ValuedUnitItems, which may or may not be priced. The universal and basic variants include coverage related information such as charges, financial participation, fee schedule, and coverage policies such as the health status of the subject of care that is conveyed in the A_Benefit CMET.

The identified variant is used to convey the identity of the ValuedItem information in the definition mood. The identifier is mandatory for the identified variant.

The definitional variant is used to convey the identity of the ValuedItem information in the definition mood. The identifier is optional for this variant.

The informational variant is used to convey the ValuedItem information in the definition or event mood. The identifier is required for this variant.

The minimal variant is used to convey optionally identifiable ValuedItem information in the definition or event mood, which may be composed of ValuedUnitItems.

The basic variant may include association to policy or program benefits to which it pertains, which are conveyed in the A_Benefit (basic) CMET COCT_MT770005UV.

The universal variant is used to convey more extensive ValuedItem information typical of knowledge base and payer benefit repository records.

How the ValuedUnitItem is used to compose a ValuedItem: A DME provider prices the frame and "add-on" components required to meet health needs of the patient. Component ValuedUnitItems may convey the InvoiceDetailCode for DME, e.g., UPC codes, and the unitPriceAmt for each part. For example, a DME provider prices the frame and "add-on" components required to meet health needs of the patient. Component ValuedUnitItems may convey the InvoiceDetailCode for DME, e.g., UPC codes, and the unitPriceAmt for each part. For an example see: DME_Table.doc

How Pricing is used:For each variant, one and only one ValuedItem is required to be sent. For the basic and universal variant, one or more ValuedUnitItem may be sent. If the act.mood of the ValuedItem or any ValuedUnitItems is in definition mood, the price may be as yet unspecified. In this case, the MO numerator for unspecified price is constrained to "UNK" for "unknown"; the PQ property denominator must be nonNull; and the netAmt is not valued. For example, in the case of product labeling, only the valued countable or measurable item is defined, but the price per unit or net amount is not yet determined.

If ValuedItem is in event mood and no ValuedUnitItem is sent, then the ValuedItem netAmt must be sent as the product of the ValuedItem unitPricedAmt and unitQuantity.

See Foundation Section 3.1.12 Class: InvoiceElement (in Acts) "For leaf-level amounts, this will be the value of the unitQuantity * unitPriceAmt [ * factorNumber] [* pointsNumber]. For grouping invoice elements, this will be the sum of the netAmt attributes of all contained InvoiceElements http://hl7.org/v3ballot/html/infrastructure/rim/rim.htm#InvoiceElement-cls

If any ValuedUnitItem act.mood is event, then the ValuedItem act.mood must be event. In this case, any ValuedUnitItem unitQuantity and unitPriceAmt attributes must be nonNull, and the ValuedUnitItem netAmt must be the product of these attributes. In addition, the ValuedItem netAmt must be the sum of any ValuedUnitItem netAmts. Since a ValuedItem unitPriceAmt is required to be sent, the MO numerator and PQ denominator must either both be UNK; or MO numerator must be equal to the ValuedItem netAmt and the PQ denominator must have a fixed value of 1.

NOTE: The RTO is NI because the MO numerator for unspecified price is set to "UNK" for "unknown" while the PQ denominator is nonNull. However, because RTO is NI, to ensure that there is information contained in the ratio, the unitPriceAmt is required with cardinality of 1...1. Thus:

<value xsi:type="RTO" nullFlavor="NI"> <numerator xsi:type="MO" nullFlavor="UNK"/> <denominator xsi:type="PQ" value="50" unit="mg"/> </value>

For more information see http://hl7.org/v3ballot/html/infrastructure/itsxml/datatypes-its-xml.htm#dtimpl-RTO

For more information on the derivation of CMET variants, see Refinement, Constraint and Localization, Release 2 Section 2.4.2 Common Message Element Types (CMETs) http://hl7.org/v3ballot/html/infrastructure/constraints/constraints.htm

Walk-through

ValuedItem

The ValuedItem classCode INVE: The focal class indicates the countable or measurable item (e.g., a product, device, or service) that may be or has been priced.

The ValuedItem moodCodeActMoodDefEvn: The ValuedItem is something that may be or has been priced.

The ValuedItem id: Optionally identifies an instance of ValuedItem information, e.g. as used on a particular product label.

The ValuedItem code from the ActInvoiceDetailCode concept domain, to which value set may be bound to provide specific information about the type of items that that may be or has been priced. For example, if the ActInvoiceDetailDrugProduct sub-concept domain is used, then the value set could include NDC, UPC or GTIN. When this code is the same as the code on a class in the base model to which this CMET is associated, do not valued this attribute or ensure that the codes are the same. For example, a Medication message may include the NDC code used in this CMET's attribute in an Entity class describing the drug.

The ValuedItem effectiveTime indicates the time during which ValuedItem information is effective.

The ValuedItem unitQuantityRTO<PQ,PQ> specifies the units by which the ValuedItem is measured or counted, and quantifies the countable or measurable ValuedItem instances. Required to be sent if known. The PQ units and values are aligned with the type of ValuedItem specified by the value set or coding system bound to the ValuedItem InvoiceDetailCode or its child concept domain.

For example, if the ActInvoiceDetailDrugCode is bound to the NDC codes, then the PQ unit value set is the NCPDP Billing Unit Standard http://www.ncpdp.org/PDF/Basic_guide_to_standards.pdf. For more information see Foundation Section 3.1.12.2 InvoiceElement.unitQuantity: RTO<PQ,PQ> (0..1).

One and only one ValuedItem unitPriceAmtRTO<MO,PQ> is required to be sent to quantify the ratio of the price per countable or measurable instance of an item that may be or has been priced. If the act.mood of the ValuedItem is in definition mood, the price may be as yet unspecified. In this case, the MO numerator for unspecified price is constrained to "UNK" for "unknown"; the PQ denominator must be nonNull; and the netAmt is not valued. For example, in the case of product labeling, only the valued countable or measurable item is defined, but the price per unit or net amount is not yet determined.

The ValuedItem netAmtMO may be sent to express the product of the ValuedItem unitQuantity and the unitPriceAmt. If the unitPriceAmt MO is UNK, then the netAmt is UNK or not sent. If any ValuedUnitItem act.mood is event, then the ValuedItem act.mood must be event. In this case, any ValuedUnitItem unitQuantity and unitPriceAmt attributes must be nonNull, and the ValuedUnitItem netAmt must be the product of these attributes. In addition, the ValuedItem netAmt must be the sum of any ValuedUnitItem netAmts. Since a ValuedItem unitPriceAmt is required to be sent, the MO numerator and PQ denominator must either be both be UNK; or MO numerator must be equal to the ValuedItem netAmt and the PQ denominator must have a fixed value of '1'.

The ValuedItem factorNumberREAL may be sent to represent a multiplier used in determining the overall cost of services delivered and/or goods received. The concept of a Factor allows for a discount or surcharge multiplier to be applied to a monetary amount. For example, the formula, with a factor would be: unitQuantity * unitPrice (Cost/Point) * factorNumber = netAmt.

The ValuedItem pointNumberMO may be sent to express the weighting (based on difficulty, cost and/or resource intensiveness) associated with the good or service delivered. The concept of Points allows for assignment of point values for services and/or goods, such that a monetary amount can be assigned to each point. For example, the formula, with points would be: unitQuantity * pointsNumber * unitPriceAmt (Cost/Point) = netAmt.

For more information see Foundation Section 3.1.12

The ActRelationship typeCode COMP: The ValuedItem may be linked to zero or more ValuedUnitItems. The component association indicates that the ValuedItem may be comprised of one or more ValuedUnitItems, which may or may not be priced.

Constraint: If any ValuedUnitItems are priced, then theValuedItem netAmount is the sum of these component prices, and the ValuedItem unitPriceAmt must not be valued .

ValuedUnitItem

ValuedUnitItem classCode INVE: The focal class indicates the countable or measurable unit item (e.g., a product, device, or service) that are components to a ValuedItem. A ValuedUnitItem may be or has been priced.

The ValuedUnitItem moodCode: The mood of this act is ActMoodDefEvn, that is, a ValuedUnitItem is something that may be or has been priced.

The ValuedUnitItem id: Optionally identifies an instance of ValuedUnitItem information, e.g. as used on a particular product label.

The ValuedUnitItem code from the ActInvoiceDetailCode concept domain, to which value set may be bound to provide specific information about the type of unit items that that may be or has been priced. For example, if the ActInvoiceDetailDrugProduct sub-concept domain is used, then the value set could include NDC, UPC or GTIN. When this code is the same as the code on a class in the base model to which this CMET is associated, do not valued this attribute or ensure that the codes are the same. For example, a Medication message may include the NDC code used in this CMET's attribute in an Entity class describing the drug.

The ValuedUnitItem effectiveTime indicates the time during which ValuedItem information is effective.

The ValuedUnitItem unitQuantityRTO<PQ,PQ> specifies the units by which the ValuedUnitItem is measured or counted, and quantifies the countable or measurable ValuedItem instances. Required to be sent if known. The PQ units and values are aligned with the type of ValuedUnitItem specified by the value set or coding system bound to the ValuedItem InvoiceDetailCode or its child concept domain.

For example, if the ActInvoiceDetailDrugCode is bound to the NDC codes, then the PQ unit value set is the NCPDP Billing Unit Standard http://www.ncpdp.org/PDF/Basic_guide_to_standards.pdf. For more information see Foundation Section 3.1.12.2 InvoiceElement.unitQuantity: RTO<PQ,PQ> (0..1)

One and only one ValuedUnitItem unitPriceAmtRTO<MO,PQ> is required to be sent to quantify the ratio of the price per countable or measurable instance of an item that may be or has been priced. If the act.mood of the ValuedUnitItem is in definition mood, the price may be as yet unspecified. In this case, the MO numerator for unspecified price is constrained to "UNK" for "unknown"; the PQ denominator must be nonNull; and the netAmt is not valued. For example, in the case of product labeling, only the valued countable or measurable item is defined, but the price per unit or net amount is not yet determined.

The ValuedUnitItem netAmtMO may be sent to express the product of the ValuedUnitItem unitQuantity and the unitPriceAmt. If the unitPriceAmt MO numerator is UNK, then the netAmt is UNK or not sent.

The ValuedUnitItem factorNumberREAL may be sent to represent a multiplier used in determining the overall cost of services delivered and/or goods received. The concept of a Factor allows for a discount or surcharge multiplier to be applied to a monetary amount. For example, the formula, with a factor would be: unitQuantity * unitPrice (Cost/Point) * factorNumber = netAmt.

The ValuedUnitItem pointNumberMO may be sent to express the weighting (based on difficulty, cost and/or resource intensiveness) associated with the good or service delivered. The concept of Points allows for assignment of point values for services and/or goods, such that a monetary amount can be assigned to each point. For example, the formula, with points would be: unitQuantity * pointsNumber * unitPriceAmt (Cost/Point) = netAmt.

Message Type List

A_ValuedItem minimal

COCT_MT440004UV09

Parent:

None

Note: This is the second Normative ballot of the A_ValuedItem CMET. There are several variants: universal, basic, minimal, definitional, informational, and identifiable.

Overview

This CMET is used to convey information related to a ValuedItem in terms of its measurable or countable units. All Variants may include pricing information needed to calculate the net amount. In the minimal, basic, and universal variants, the ValuedItem may be composed of one or more ValuedUnitItems, which may or may not be priced. The universal and basic variants include coverage related information such as charges, financial participation, fee schedule, and coverage policies such as the health status of the subject of care that is conveyed in the A_Benefit CMET.

The identified variant is used to convey the identity of the ValuedItem information in the definition mood. The identifier is mandatory for the identified variant.

The definitional variant is used to convey the identity of the ValuedItem information in the definition mood. The identifier is optional for this variant.

The informational variant is used to convey the ValuedItem information in the definition or event mood. The identifier is required for this variant.

The minimal variant is used to convey optionally identifiable ValuedItem information in the definition or event mood, which may be composed of ValuedUnitItems.

The basic variant may include association to policy or program benefits to which it pertains, which are conveyed in the A_Benefit (basic) CMET COCT_MT770005UV.

The universal variant is used to convey more extensive ValuedItem information typical of knowledge base and payer benefit repository records.

How the ValuedUnitItem is used to compose a ValuedItem: A DME provider prices the frame and "add-on" components required to meet health needs of the patient. Component ValuedUnitItems may convey the InvoiceDetailCode for DME, e.g., UPC codes, and the unitPriceAmt for each part. For example, a DME provider prices the frame and "add-on" components required to meet health needs of the patient. Component ValuedUnitItems may convey the InvoiceDetailCode for DME, e.g., UPC codes, and the unitPriceAmt for each part. For an example see: DME_Table.doc

How Pricing is used:For each variant, one and only one ValuedItem is required to be sent. For the basic and universal variant, one or more ValuedUnitItem may be sent. If the act.mood of the ValuedItem or any ValuedUnitItems is in definition mood, the price may be as yet unspecified. In this case, the MO numerator for unspecified price is constrained to "UNK" for "unknown"; the PQ property denominator must be nonNull; and the netAmt is not valued. For example, in the case of product labeling, only the valued countable or measurable item is defined, but the price per unit or net amount is not yet determined.

If ValuedItem is in event mood and no ValuedUnitItem is sent, then the ValuedItem netAmt must be sent as the product of the ValuedItem unitPricedAmt and unitQuantity.

See Foundation Section 3.1.12 Class: InvoiceElement (in Acts) "For leaf-level amounts, this will be the value of the unitQuantity * unitPriceAmt [ * factorNumber] [* pointsNumber]. For grouping invoice elements, this will be the sum of the netAmt attributes of all contained InvoiceElements http://hl7.org/v3ballot/html/infrastructure/rim/rim.htm#InvoiceElement-cls

If any ValuedUnitItem act.mood is event, then the ValuedItem act.mood must be event. In this case, any ValuedUnitItem unitQuantity and unitPriceAmt attributes must be nonNull, and the ValuedUnitItem netAmt must be the product of these attributes. In addition, the ValuedItem netAmt must be the sum of any ValuedUnitItem netAmts. Since a ValuedItem unitPriceAmt is required to be sent, the MO numerator and PQ denominator must either both be UNK; or MO numerator must be equal to the ValuedItem netAmt and the PQ denominator must have a fixed value of 1.

NOTE: The RTO is NI because the MO numerator for unspecified price is set to "UNK" for "unknown" while the PQ denominator is nonNull. However, because RTO is NI, to ensure that there is information contained in the ratio, the unitPriceAmt is required with cardinality of 1...1. Thus:

<value xsi:type="RTO" nullFlavor="NI"> <numerator xsi:type="MO" nullFlavor="UNK"/> <denominator xsi:type="PQ" value="50" unit="mg"/> </value>

For more information see http://hl7.org/v3ballot/html/infrastructure/itsxml/datatypes-its-xml.htm#dtimpl-RTO

For more information on the derivation of CMET variants, see Refinement, Constraint and Localization, Release 2 Section 2.4.2 Common Message Element Types (CMETs) http://hl7.org/v3ballot/html/infrastructure/constraints/constraints.htm

Walk-through

ValuedItem

The ValuedItem classCode INVE: The focal class indicates the countable or measurable item (e.g., a product, device, or service) that may be or has been priced.

The ValuedItem moodCodeActMoodDefEvn: The ValuedItem is something that may be or has been priced.

The ValuedItem id: Optionally identifies an instance of ValuedItem information, e.g. as used on a particular product label.

The ValuedItem code from the ActInvoiceDetailCode concept domain, to which value set may be bound to provide specific information about the type of items that that may be or has been priced. For example, if the ActInvoiceDetailDrugProduct sub-concept domain is used, then the value set could include NDC, UPC or GTIN. When this code is the same as the code on a class in the base model to which this CMET is associated, do not valued this attribute or ensure that the codes are the same. For example, a Medication message may include the NDC code used in this CMET's attribute in an Entity class describing the drug.

The ValuedItem effectiveTime indicates the time during which ValuedItem information is effective.

The ValuedItem unitQuantityRTO<PQ,PQ> specifies the units by which the ValuedItem is measured or counted, and quantifies the countable or measurable ValuedItem instances. Required to be sent if known. The PQ units and values are aligned with the type of ValuedItem specified by the value set or coding system bound to the ValuedItem InvoiceDetailCode or its child concept domain.

For example, if the ActInvoiceDetailDrugCode is bound to the NDC codes, then the PQ unit value set is the NCPDP Billing Unit Standard http://www.ncpdp.org/PDF/Basic_guide_to_standards.pdf. For more information see Foundation Section 3.1.12.2 InvoiceElement.unitQuantity: RTO<PQ,PQ> (0..1).

One and only one ValuedItem unitPriceAmtRTO<MO,PQ> is required to be sent to quantify the ratio of the price per countable or measurable instance of an item that may be or has been priced. If the act.mood of the ValuedItem is in definition mood, the price may be as yet unspecified. In this case, the MO numerator for unspecified price is constrained to "UNK" for "unknown"; the PQ denominator must be nonNull; and the netAmt is not valued. For example, in the case of product labeling, only the valued countable or measurable item is defined, but the price per unit or net amount is not yet determined.

The ValuedItem netAmtMO may be sent to express the product of the ValuedItem unitQuantity and the unitPriceAmt. If the unitPriceAmt MO is UNK, then the netAmt is UNK or not sent. If any ValuedUnitItem act.mood is event, then the ValuedItem act.mood must be event. In this case, any ValuedUnitItem unitQuantity and unitPriceAmt attributes must be nonNull, and the ValuedUnitItem netAmt must be the product of these attributes. In addition, the ValuedItem netAmt must be the sum of any ValuedUnitItem netAmts. Since a ValuedItem unitPriceAmt is required to be sent, the MO numerator and PQ denominator must either be both be UNK; or MO numerator must be equal to the ValuedItem netAmt and the PQ denominator must have a fixed value of '1'.

The ValuedItem factorNumberREAL may be sent to represent a multiplier used in determining the overall cost of services delivered and/or goods received. The concept of a Factor allows for a discount or surcharge multiplier to be applied to a monetary amount. For example, the formula, with a factor would be: unitQuantity * unitPrice (Cost/Point) * factorNumber = netAmt.

The ValuedItem pointNumberMO may be sent to express the weighting (based on difficulty, cost and/or resource intensiveness) associated with the good or service delivered. The concept of Points allows for assignment of point values for services and/or goods, such that a monetary amount can be assigned to each point. For example, the formula, with points would be: unitQuantity * pointsNumber * unitPriceAmt (Cost/Point) = netAmt.

For more information see Foundation Section 3.1.12

The ActRelationship typeCode COMP: The ValuedItem may be linked to zero or more ValuedUnitItems. The component association indicates that the ValuedItem may be comprised of one or more ValuedUnitItems, which may or may not be priced.

Constraint: If any ValuedUnitItems are priced, then theValuedItem netAmount is the sum of these component prices, and the ValuedItem unitPriceAmt must not be valued .

ValuedUnitItem

ValuedUnitItem classCode INVE: The focal class indicates the countable or measurable unit item (e.g., a product, device, or service) that are components to a ValuedItem. A ValuedUnitItem may be or has been priced.

The ValuedUnitItem moodCode: The mood of this act is ActMoodDefEvn, that is, a ValuedUnitItem is something that may be or has been priced.

The ValuedUnitItem id: Optionally identifies an instance of ValuedUnitItem information, e.g. as used on a particular product label.

The ValuedUnitItem code from the ActInvoiceDetailCode concept domain, to which value set may be bound to provide specific information about the type of unit items that that may be or has been priced. For example, if the ActInvoiceDetailDrugProduct sub-concept domain is used, then the value set could include NDC, UPC or GTIN. When this code is the same as the code on a class in the base model to which this CMET is associated, do not valued this attribute or ensure that the codes are the same. For example, a Medication message may include the NDC code used in this CMET's attribute in an Entity class describing the drug.

The ValuedUnitItem effectiveTime indicates the time during which ValuedItem information is effective.

The ValuedUnitItem unitQuantityRTO<PQ,PQ> specifies the units by which the ValuedUnitItem is measured or counted, and quantifies the countable or measurable ValuedItem instances. Required to be sent if known. The PQ units and values are aligned with the type of ValuedUnitItem specified by the value set or coding system bound to the ValuedItem InvoiceDetailCode or its child concept domain.

For example, if the ActInvoiceDetailDrugCode is bound to the NDC codes, then the PQ unit value set is the NCPDP Billing Unit Standard http://www.ncpdp.org/PDF/Basic_guide_to_standards.pdf. For more information see Foundation Section 3.1.12.2 InvoiceElement.unitQuantity: RTO<PQ,PQ> (0..1)

One and only one ValuedUnitItem unitPriceAmtRTO<MO,PQ> is required to be sent to quantify the ratio of the price per countable or measurable instance of an item that may be or has been priced. If the act.mood of the ValuedUnitItem is in definition mood, the price may be as yet unspecified. In this case, the MO numerator for unspecified price is constrained to "UNK" for "unknown"; the PQ denominator must be nonNull; and the netAmt is not valued. For example, in the case of product labeling, only the valued countable or measurable item is defined, but the price per unit or net amount is not yet determined.

The ValuedUnitItem netAmtMO may be sent to express the product of the ValuedUnitItem unitQuantity and the unitPriceAmt. If the unitPriceAmt MO numerator is UNK, then the netAmt is UNK or not sent.

The ValuedUnitItem factorNumberREAL may be sent to represent a multiplier used in determining the overall cost of services delivered and/or goods received. The concept of a Factor allows for a discount or surcharge multiplier to be applied to a monetary amount. For example, the formula, with a factor would be: unitQuantity * unitPrice (Cost/Point) * factorNumber = netAmt.

The ValuedUnitItem pointNumberMO may be sent to express the weighting (based on difficulty, cost and/or resource intensiveness) associated with the good or service delivered. The concept of Points allows for assignment of point values for services and/or goods, such that a monetary amount can be assigned to each point. For example, the formula, with points would be: unitQuantity * pointsNumber * unitPriceAmt (Cost/Point) = netAmt.

The ActRelationship typeCodePERT: The ValuedItem may be linked to zero or more A_Benefit (universal) CMET. The association indicates that the ValuedItem may pertain to zero or more benefits under a Program or Policy.

Common Message Element Types Used

A_BenefitUniversal

COCT_MT770000UV09

Message Type List

A_ValuedItem universal

COCT_MT440000UV09

Parent:

None

Note: This is the first Normative ballot of the A_Benefit basic CMET. There is is also a universal variant.

Overview

The A_Benefit CMET is used to convey a benefit covered by a policy or program (P/P). The universal variant optionally includes financial information related to the provider contract and the covered party's financial participation in the cost of a health service or product. This is the basic variant which omits the financial information classes.

The Benefit is an act with a classCodePCPR: This class indicates a service provision benefit under a P/P, which may be further specified by associated acts, e.g., the benefit may have a supporting clinical statement about care provided or the condition of the subject of care as a precondition; may refer to coverage policies related to the provision of the benefit; or may be limited by the charges covered under a P/P or financial participations required of the covered party.

The Benefit id: Optionally identifies a benefit.

The Benefit moodCode: The mood of this act is ActMoodCompletionTrack, that is, a P/P Benefit is either something that is being provided, has been provided, can be provided, or is intended or requested to be provided.

The Benefit code: The type of benefit is required be specified by a code from the x_ActBillableCode value set if known. For example, medical, chiropractic, dental care, social work, hospice, long term care, ambulance, acupuncture, pharmacy, psychiatry, naturopathy, physical therapy, etc.

The Benefit effectiveTime: The effective date range for a benefit may be sent.

The Benefit reasonCode: These are the reasons or criteria specified by codes from the ActCoverageReason value set, relating to coverage of a benefit provided under a policy or program. May be used to convey reasons pertaining to coverage contractual provisions, e.g., relating to who may provide the benefit in order to effect coverage.

The Benefit precondition ActRelationshipType code PRCN: The Benefit may be associated to one or more A_SupportingClinicalStatement CMET, which convey the services that must be received as a precondition of coverage of the Benefit, e.g., a diagnostic test is required to validate the medical necessity of a procedure in order for that procedure to be a covered benefit under a P/P.

The Benefit reference ActRelationshipType code REFR: The Benefit may reference zero or more CoveragePolicy with an act classCodePOL, which conveys the coverage policy or policies that sets rules for the coverage of the Benefit charges and financial participations.

The CoveragePolicy moodCodeDEF: The mood of this act is Definition, that is, coverage for a Benefit is defined by the CoveragePolicy.

The CoveragePolicy id: One or more unique identifiers for the CoveragePolicy may be sent.

The CoveragePolicy ActCode: The type of policy is required to be specified if known by codes from the ActPolicyType value set.

The CoveragePolicy statusCode: The status of this CoveragePolicy, e.g., obsolete if this CoveragePolicy has been replaced but applied to a Benefit during the P/P effective time so as to be applicable to the coverage of a Benefit during that time span.

The CoveragePolicy effectiveTime: The effective date range for a coverage policy may be sent.

The CoveragePolicy reasonCode: These are the reasons or criteria for the CoveragePolicy specified by codes from the ActCoverageReason value set, e.g., coverage policy for a Benefit may be related to medical necessity or evidence that a drug is not being used "off-label" or a service is not an "experimental treatment".

Common Message Element Types Used

A_SupportingClinicalStatementUniversal

COCT_MT530000UV

Message Type List

A_Benefit basic

COCT_MT770005UV09

Parent:

None

Note: This is the first Normative ballot of the A_Benefit universal CMET. There is is also a basic variant.

Overview

The A_Benefit CMET is used to convey a benefit covered by a Policy or Program (P/P). The universal variant optionally includes financial information related to the provider contract and the covered party's financial participation in the cost of a health service or product.

The Benefit is an act with a classCodePCPR: This class indicates a service provision benefit under a P/P, which may be further specified by associated acts, e.g., the benefit may have a supporting clinical statement about care provided or the condition of the subject of care as a precondition; may refer to coverage policies related to the provision of the benefit; or may be limited by the charges covered under a P/P or financial participations required of the covered party.

The Benefit id: Optionally identifies a benefit.

The Benefit moodCode: The mood of this act is ActMoodCompletionTrack, that is, a P/P Benefit is either something that is being provided, has been provided, can be provided, or is intended or requested to be provided.

The Benefit code: The type of benefit is required be specified by a code from the x_ActBillableCode value set if known. For example, medical, chiropractic, dental care, social work, hospice, long term care, ambulance, acupuncture, pharmacy, psychiatry, naturopathy, physical therapy, etc.

The Benefit effectiveTime: The effective date range for a benefit may be sent.

The Benefit reasonCode: These are the reasons or criteria specified by codes from the ActCoverageReason value set, relating to coverage of a benefit provided under a policy or program. May be used to convey reasons pertaining to coverage contractual provisions, e.g., relating to who may provide the benefit in order to effect coverage.

The Benefit precondition ActRelationshipType code PRCN: The Benefit may be associated to one or more A_SupportingClinicalStatement CMET, which convey the services that must be received as a precondition of coverage of the Benefit, e.g., a diagnostic test is required to validate the medical necessity of a procedure in order for that procedure to be a covered benefit under a P/P.

The Benefit reference ActRelationshipType code REFR: The Benefit may reference zero or more CoveragePolicy with an act classCodePOL, which conveys the coverage policy or policies that sets rules for the coverage of the Benefit charges and financial participations.

The CoveragePolicy moodCodeDEF: The mood of this act is Definition, that is, coverage for a Benefit is defined by the CoveragePolicy.

The CoveragePolicy id: One or more unique identifiers for the CoveragePolicy may be sent.

The CoveragePolicy ActCode: The type of policy is required to be specified if known by codes from the ActPolicyType value set.

The CoveragePolicy statusCode: The status of this CoveragePolicy, e.g., obsolete if this CoveragePolicy has been replaced but applied to a Benefit during the P/P effective time so as to be applicable to the coverage of a Benefit during that time span.

The CoveragePolicy effectiveTime: The effective date range for a coverage policy may be sent.

The CoveragePolicy reasonCode: These are the reasons or criteria for the CoveragePolicy specified by codes from the ActCoverageReason value set, e.g., coverage policy for a Benefit may be related to medical necessity or evidence that a drug is not being used "off-label" or a service is not an "experimental treatment".

The Benefit limitation ActRelationshipType code LIMIT: The Benefit may be associated with zero or more CoverageChargeChoice acts, either CoverageCharge or FinancialParticipationCharge.

The CoverageCharge act classCodeINVE: This class indicates the rules relating to the charges for a benefit that a P/P will cover.

The CoverageCharge moodCodeCRT: The mood of this act is Criterion, which conveys the conditions that must be met for the charges related to the Benefit to be covered.

The CoverageCharge id: One or more unique identifiers for the CoverageCharge rule may be sent.

The CoverageCharge code: The type of coverage charge rule is required to be specified if known by codes from the ActCoverageLimitCode value set, e.g., the net amount, unit quantity, or unit price.

The CoverageCharge effectiveTime: The effective date range for a coverage charge rule.

The CoverageCharge unitQuantity conveys the ratio of units per service provision or product dispense, e.g., 2 hour session of physical therapy or 3 boxes of a product per dispense.

The CoverageCharge unitPriceAmt conveys the price per unit, e.g., $50 CAD/1{box} or $100 per hour of physical therapy.

The CoverageCharge netAmt is expressed using a currency {the unit in which monetary amounts are denominated in different economic regions] to express the net amount charged based on the product of applicable coverage charge unity quantity, unityPriceAmt, factorNumber and pointsNumber attributes.

The CoverageCharge factorNumber is the multiplier or percentage used to calculate the rate for each unitQuanitity/unitPriceAmt expressed with a Real integer, e.g., the out-of-network vs. the in-network percentage charge.

The FinancialParticipationCharge classCodeINVE: This class indicates the rules relating to the limits of charges for a benefit that a P/P will cover.

The FinancialParticipationCharge moodCodeCRT: The mood of this act is Criterion, which conveys the financial participation charges that the covered party must pay in order for the Benefit to be covered by the P/P.

The FinancialParticipationCharge id: One or more unique identifiers for the FinancialParticipationCharge may be sent.

The FinancialParticipationCharge code: The type of financial participation required of covered parties may be specified by codes from the ActInvoiceDetailGenericAdjudicationCode value set, e.g., copayment, deductible, or coinsurance.

The FinancialParticipationCharge effectiveTime: The effective date range for a financial participation rule.

The FinancialParticipationCharge unitQuantityconveys the ratio of units per service provision or product dispense for purpose of calculating financial participation, e.g., a 30 or 90 day supply of a product per dispense.

The FinancialParticipationCharge unitPriceAmt conveys the financial participation required per unit of service covered under the benefit, e.g., $15 per hour of physical therapy.

The FinancialParticipationCharge netAMT is expressed using a currency {the unit in which monetary amounts are denominated in different economic regions] to express the net financial participation amount charged based on the product of applicable financial participation unity quantity, unityPriceAmt, factorNumber and pointsNumber attributes.

The FinancialParticipationCharge factorNumber is the multiplier or percentage used to calculate the rate for each unitQuanitity/unitPriceAmt expressed with a Real integer, e.g., the out-of-network financial participation charge is 10% higher than the in-network financial participation charge.

The CoverageCharge may be linked by the inFullfillmentOf ActRelationshipType code FLFS to zero or more A_ProviderContract (basic) CMET.

The ActRelationshipType code REFER: The CoverageChargeChoice may be associated to one or more CoverageChargePolicy, which conveys the coverage policy or policies that sets rules for the coverage of the Benefit charges and financial participations.

The CoverageChargePolicy moodCodeDEF: The mood of this act is Definition, that is, a Benefit CoveragePolicy is defined by this class's attributes.

The CoverageChargePolicy id: One or more unique identifiers for the CoverageChargePolicy may be sent.

The CoverageChargePolicy code: The type of policy may be specified by codes from the ActPolicyType value set.

The CoverageChargePolicy statusCode: The status of this CoveragePolicy, obsolete if this CoverageChargePolicy has been replaced but applied to a Benefit during the P/P effective time and was applicable to the coverage of a Benefit charge or financial participation during that time span.

The CoverageChargePolicy effectiveTime: The effective date range for a coverage charge policy.

The CoverageChargePolicy reasonCode: One or more reason codes related to the coverage charge policy may be selected from the ActCoverageReason value set, e.g., a spend down requirement is the reason for a policy referenced by a financial participation charge deductible that limits the clinical services covered during the benefit effective time.

Common Message Element Types Used

A_SupportingClinicalStatementUniversal	COCT_MT530000UV
A_ProviderContractBasic	COCT_MT780005UV09

Message Type List

A_Benefit universal

COCT_MT770000UV09

Parent:

None

The A_ProviderContract (basic) CMET conveys provider contract information, which may reference a fee schedule describing the billing arrangement components of a service charge under the contract.

ProviderContract is a financial contract typically between a provider and a payer that is expressed with the classCodeFCNTCT .

The BillingArrangementContract moodDEF conveys the type of definition of billing arrangement contract rather than an executed instance.

The BillingArrangementContract id is required to be sent if available to identify the contract.

The BillingArrangementContract code provides specific information about the type of financial contract with a coded concept from the ActBillingArrangementCode value set, e.g., fee-for-service, capitation, block grant, etc.

The BillingArrangementContract id is required to be sent if available to identify the contract.

The BillingArrangementContract effectiveTime may be sent to indicate the time during which the contract is in effect.

The referenceActRelationshipTypeREFR associates the BillingArrangementContract with the FeeSchedule expressed with the classCodeINVE in definition mode.

The FeeSchedule mood conveys that this is the type of fee schedule that would be applied to the associated coverage charge under a particular billing arrangement contract.

The FeeSchedule id is required be sent if available to uniquely identify a fee schedule.

The FeeSchedule code from the ActInvoiceElementCode value set provides specific information about the type of charges that may be invoiced.

The FeeSchedule may carry unitQuantity, unitPriceAmt, netAmt, factorNumber, and points if these are more informative than or impacts those carried in the an invoice class to which the A_ProviderContract may be associated, e.g., the A_Benefit ChargeDetail.

Message Type List

A_ProviderContract basic

COCT_MT780005UV09

Parent:

Claims & Reimbursement (FICR_DM000000UV03)

Note: This CMET is normative in the HL7 V3 2006 Normative Edition.

The Adjudication Observation CMET is a choice amongst various adjudication observations such as contraindications. Adjudication observations provide clinical content created during the Adjudication of Invoices.

Additional CMETs will be added to the choice box over time as other adjudication observations are identified and modeled.

Common Message Element Types Used

A_DetectedMedicationIssueNoText

COCT_MT260003UV

Message Type List

A_AdjudicationObservation universal

COCT_MT320000UV04

Parent:

Claims & Reimbursement (FICR_DM000000UV03)

Note: This CMET is normative in the HL7 V3 2006 Normative Edition.

The Billable CMET is a choice amongst the various billable acts that have the clinical content for services and/or products that are included in financial Invoices (billing).

In addition, there is a CrossReference used to reference a previous billable act by including its service/product identifier. The cross reference can only be used to reference another billable act within the same physical message (otherwise, this would require the receiver of the message to keep a large number of identifiers).

Additional CMETs will be added to the choice box over time as other billable acts are identified and modeled.

Common Message Element Types Used

A_BillableClinicalServiceUniversal	COCT_MT290000UV06
A_BillablePharmacyDispenseUniversal	COCT_MT300000UV04
A_BillablePreferredAccomodationUniversal	COCT_MT310000UV04
A_BillableClinicalProductUniversal	COCT_MT490000UV04
A_BillableVisionDispenseUniversal	COCT_MT600000UV06
A_BillableOralHealthServiceUniversal	COCT_MT740000UV04

Message Type List

A_Billable universal

COCT_MT280000UV04

Parent:

Claims & Reimbursement (FICR_DM000000UV03)

Note: This CMET is intended to replace or revise material in the HL7 V3 2006 Normative Edition standard.

Overview:

The Billable Clinical Service encounter CMET is intended to provide detailed clinical information on orderable or billable health care related services including clinical interventions, procedures or services; observations; accommodations; substance administration; encounters; transportation; oral health care; or any care provided to living subjects, required to support the generation or posting of a Charge; an Invoice, Pre-Determination, Coverage Extension or Authorization in the event and intent mood.

The elements (classes, attributes, relationships) of this CMET are a subset of the elements of its parent CMET. For descriptions of the elements of this CMET, see the descriptions of the relevant elements of the parent CMET, which can be found via the following link: A_BillableClinicalServices universal

Common Message Element Types Used

R_PatientUniversal	COCT_MT050000UV01
R_ServiceDeliveryLocationContact	COCT_MT240003UV02

Message Type List

A_BillableClinicalService Encounter

COCT_MT290004UV06

Parent:

Claims & Reimbursement (FICR_DM000000UV03)

Note: This CMET is intended to replace or revise material in the HL7 V3 2006 Normative Edition standard.

Overview:

The Billable Clinical Service basic CMET is intended to provide detailed clinical information on orderable or billable health care related services including clinical interventions, procedures or services; observations; accommodations; substance administration; encounters; transportation; oral health care; or any care provided to living subjects, required to support the generation or posting of a Charge; an Invoice, Pre-Determination, Coverage Extension or Authorization in the event and intent mood; or to describe detailed benefits covered under a policy or program in the definition mood.

The elements (classes, attributes, relationships) of this CMET are a subset of the elements of its parent CMET. For descriptions of the elements of this CMET, see the descriptions of the relevant elements of the parent CMET, which can be found via the following link: A_BillableClinicalServices univeral

Common Message Element Types Used

R_ServiceDeliveryLocationContact

COCT_MT240003UV02

Message Type List

A_BillableClinicalService basic

COCT_MT290002UV06

Parent:

Claims & Reimbursement (FICR_DM000000UV03)

Note: This CMET is intended to replace or revise material in the HL7 V3 2006 Normative Edition standard.

Overview:

The BillableClinicalService referral CMET is intended to provide detailed clinical information on orderable health care related services needed for a referral including clinical interventions, procedures or services; observations; accommodations; substance administration; encounters; transportation; oral health care; or any care provided to living subjects, required to support the generation or posting of a Pre-Determination, Coverage Extension, or Authorization in the intent mood.

The elements (classes, attributes, relationships) of this CMET are a subset of the elements of its parent CMET. For descriptions of the elements of this CMET, see the descriptions of the relevant elements of the parent CMET, which can be found via the following link: A_BillableClinicalServices univeral

Common Message Element Types Used

R_PatientUniversal	COCT_MT050000UV01
R_ServiceDeliveryLocationContact	COCT_MT240003UV02

Message Type List

A_BillableClinicalService referral

COCT_MT290003UV07

Parent:

Claims & Reimbursement (FICR_DM000000UV03)

Note: This CMET is normative in the HL7 V3 2006 Normative Edition.

The BillableOralHealthService CMET provides oral health information required to support billing for an Invoice, Pre-Determination, Coverage Extension or Authorization.

The patient is not referenced in this billable act as it is inherited from the parent model (as CoveredPartyAsPatient).

The oral health procedure (e.g. cleaning, tooth extraction(is supported by the specification of a oral health provider (e.g. dentist), referral, previous teeth extractions, previous oral health procedures, diagnosis and location.

Common Message Element Types Used

R_ServiceDeliveryLocationContact

COCT_MT240003UV02

Message Type List

A_BillableOralHealthService universal

COCT_MT740000UV04

Parent:

Claims & Reimbursement (FICR_DM000000UV03)

Note: This CMET is normative in the HL7 V3 2006 Normative Edition.

This is a variant of the A_BillablePharmacyDispense universal (COCT_MT300000) CMET.

The BillablePharmacyDispense CMET provides pharmacy dispense information, required to support billing information for an Invoice, Pre-Determination, Coverage Extension or Authorization. It is derived from the Pharmacy Domain Model.

The patient is not referenced in this billable act as it is inherited from the parent model (as CoveredPartyAsPatient).

The supply act represents the dispensing of a drug and is supported by the prescriber and performer (pharmacist, dispenser) and can indicate the order that was filled, alert(s), shipping location and methadone dose control information.

A drug form may also be specified for compounds. However, the drug dispensed is not identified in this CMET, as it will be described in the Invoice (i.e. the drug is what is being billed for).

If the service was provided in the context of an encounter, admit and discharge dates may need to be specified.

Common Message Element Types Used

R_ServiceDeliveryLocationContact	COCT_MT240003UV02
R_ServiceDeliveryLocationContact	COCT_MT240003UV02
R_ServiceDeliveryLocationContact	COCT_MT240003UV02
A_DetectedMedicationIssueNoText	COCT_MT260003UV

Message Type List

A_BillablePharmacyDispense Basic

COCT_MT300001UV04

Parent:

Claims & Reimbursement (FICR_DM000000UV03)

Note: This CMET is normative in the HL7 V3 2006 Normative Edition.

The BillablePharmacyDispense CMET provides pharmacy dispense information, required to support billing information for an Invoice, Pre-Determination, Coverage Extension or Authorization. It is derived from the Pharmacy Domain Model.

The patient is not referenced in this billable act as it is inherited from the parent model (as CoveredPartyAsPatient).

The supply act represents the dispensing of a drug and is supported by the prescriber and performer (pharmacist, dispenser) and can indicate the order that was filled, alert(s), shipping location and methadone dose control information.

A drug form may also be specified for compounds. However, the drug dispensed is not identified in this CMET, as it will be described in the Invoice (i.e. the drug is what is being billed for).

If the service was provided in the context of an encounter, admit and discharge dates may need to be specified.

Common Message Element Types Used

R_ServiceDeliveryLocationContact	COCT_MT240003UV02
R_ServiceDeliveryLocationContact	COCT_MT240003UV02
R_ServiceDeliveryLocationContact	COCT_MT240003UV02
A_DetectedMedicationIssueNoText	COCT_MT260003UV

Message Type List

A_BillablePharmacyDispense universal

COCT_MT300000UV04

Parent:

Claims & Reimbursement (FICR_DM000000UV03)

Note: This CMET is normative in the HL7 V3 2006 Normative Edition.

The BillablePreferredAccommodation CMET provides institutional preferred accommodation information, required to support billing information for an Invoice, Pre-Determination, Coverage Extension or Authorization.

The patient is not referenced in this billable act as it is inherited from the parent model (as CoveredPartyAsPatient).

The accommodation supplied is supported with the accommodation requested (and by whom) and the minimum accommodation available at the time of the request. Additional information such as the location of the accommodation supplied, the encounter and medical service may be supplied.

Common Message Element Types Used

R_ServiceDeliveryLocationContact

COCT_MT240003UV02

Message Type List

A_BillablePreferredAccomodation universal

COCT_MT310000UV04

Parent:

Claims & Reimbursement (FICR_DM000000UV03)

The BillableSocialService CMET provides detailed information on social services, required to support billing information for an Invoice, Pre-Determination, Coverage Extension or Authorization.

The BillableSocialService CMET supports the conveyance of the health, socio-economic, and functional assessment observations about the client who is the subject of the social service that augments information typically conveyed about a patient of clinical services.

Common Message Element Types Used

E_PersonUniversal	COCT_MT030200UV09
E_OrganizationUniversal	COCT_MT150000UV02
R_ServiceDeliveryLocationContact	COCT_MT240003UV02
E_PlaceUniversal	COCT_MT710000UV07
A_SpatialCoordinateUniversal	COCT_MT960000UV05

Message Type List

A_BillableSocialService universal

COCT_MT610000UV06

Parent:

Claims & Reimbursement (FICR_DM000000UV03)

Note: This is a membership 1 ballot of the second release of this CMETThis CMET is normative in the HL7 V3 2006 Normative Edition. Release 2 includes changes to vocabulary and class attributes.

The BillableVisionDispense CMET provides vision dispense information, required to support billing information for an Invoice, Pre-Determination, Coverage Extension or Authorization.

The patient is not referenced in this billable act as it is inherited from the parent model (as CoveredPartyAsPatient).

The supply event is supported by the specification of the product, the performer, prescription and prescriber, diagnosis and location.

Common Message Element Types Used

R_ServiceDeliveryLocationUniversal	COCT_MT240000UV01
R_ServiceDeliveryLocationContact	COCT_MT240003UV02
R_ServiceDeliveryLocationContact	COCT_MT240003UV02

Message Type List

A_BillableVisionDispense universal

COCT_MT600000UV06

Parent:

Claims & Reimbursement (FICR_DM000000UV03)

Note: This CMET is normative in the HL7 V3 2006 Normative Edition.

The CMET is used to supply clinical content for services performed and/or delivered to support invoicing (billing).

Common Message Element Types Used

A_OralHealthObservationUniversal

COCT_MT760000UV04

Message Type List

A_BillingSupportObservation universal

COCT_MT750000UV04

Parent:

Claims & Reimbursement (FICR_DM000000UV03)

Note: This CMET is new in this ballot. This is committee ballot 1.

Overview:

The Coverage basic CMET provides detailed information required to support management of a record regarding any current or previous coverages available to a beneficiary, such as a patient, under kind of insurance policy or government program (P/P), including services covered and financial participations. This CMET is intended to convey coverage information needed to manage, for example, accounts receivables related to the provision of services related to benefits; eligibility determination, eligibility verification, enrollment, and administration of a Covered Party's record.

The elements (classes, attributes, relationships) of this CMET are a subset of the elements of its parent CMET. For descriptions of the elements of this CMET, see the descriptions of the relevant elements of the parent CMET, which can be found via the following link: A_Coverage universal

Common Message Element Types Used

E_LivingSubjectInformational	COCT_MT030007UV
A_TransportationUniversal	COCT_MT060000UV01
E_OrganizationUniversal	COCT_MT150000UV02
E_OrganizationUniversal	COCT_MT150000UV02
A_BillableUniversal	COCT_MT280000UV04
A_SupportingClinicalStatementUniversal	COCT_MT530000UV
A_VerificationUniversal	COCT_MT810000UV

Message Type List

A_Coverage basic

COCT_MT510005UV06

Parent:

Claims & Reimbursement (FICR_DM000000UV03)

Note: This CMET is new in this ballot. This is committee ballot 1.

Overview:

The Coverage contact CMET provides sufficient information to support contacting the covered party and the payor for coverage under any kind of insurance policy or government program (P/P). This CMET is intended to convey coverage information needed to manage, for example, accounts receivables related to the provision of services related to benefits; eligibility determination, eligibility verification, enrollment, and administration of a Covered Party's record.

The elements (classes, attributes, relationships) of this CMET are a subset of the elements of its parent CMET. For descriptions of the elements of this CMET, see the descriptions of the relevant elements of the parent CMET, which can be found via the following link: A_Coverage universal

Common Message Element Types Used

E_LivingSubjectInformational

COCT_MT030007UV

Message Type List

A_Coverage contact

COCT_MT510003UV06

Parent:

Claims & Reimbursement (FICR_DM000000UV03)

Note: This CMET is new in this ballot. This is committee ballot 1.

Overview:

The Coverage identified CMET provides sufficient information to identify the covered party and the coverage under any kind of insurance policy or government program (P/P). This CMET is intended to convey coverage information needed to manage, for example, accounts receivables related to the provision of services related to benefits; eligibility determination, eligibility verification, enrollment, and administration of a Covered Party's record.

The elements (classes, attributes, relationships) of this CMET are a subset of the elements of its parent CMET. For descriptions of the elements of this CMET, see the descriptions of the relevant elements of the parent CMET, which can be found via the following link: A_Coverage universal

Message Type List

A_Coverage identified

COCT_MT510001UV06

Parent:

Claims & Reimbursement (FICR_DM000000UV03)

Note: This CMET is new in this ballot. This is committee ballot 1.

A_Coverage identified-confirmable (COCT_RM51002)

Overview:

The Coverage identified-confirmable CMET provides sufficient information to confirm the identity of the covered party and the coverage under any kind of insurance policy or government program (P/P). This CMET is intended to convey coverage information needed to manage, for example, accounts receivables related to the provision of services related to benefits; eligibility determination, eligibility verification, enrollment, and administration of a Covered Party's record.

The elements (classes, attributes, relationships) of this CMET are a subset of the elements of its parent CMET. For descriptions of the elements of this CMET, see the descriptions of the relevant elements of the parent CMET, which can be found via the following link: A_Coverage universal

Common Message Element Types Used

E_LivingSubjectInformational

COCT_MT030007UV

Message Type List

A_Coverage identified-confirmable

COCT_MT510002UV06

Parent:

Claims & Reimbursement (FICR_DM000000UV03)

Note: This CMET is new in this ballot. This is committee ballot 1.

Overview:

The Coverage minimal CMET provides sufficient information required to support management of a record regarding any current of previous coverages available to a beneficiary, such as a patient, under kind of insurance policy or government program (P/P). This CMET is intended to convey coverage information needed to manage, for example, accounts receivables related to the provision of services related to benefits; eligibility determination, eligibility verification, enrollment, and administration of a Covered Party's record.

The elements (classes, attributes, relationships) of this CMET are a subset of the elements of its parent CMET. For descriptions of the elements of this CMET, see the descriptions of the relevant elements of the parent CMET, which can be found via the following link: A_Coverage universal

Common Message Element Types Used

E_LivingSubjectInformational

COCT_MT030007UV

Message Type List

A_Coverage minimal

COCT_MT510004UV06

Parent:

Claims & Reimbursement (FICR_DM000000UV03)

Note: This CMET is normative in the HL7 V3 2006 Normative Edition. This is release 1 of A_Coverage.

The Coverage CMET is used to reference an insurance policy for a specific covered party. For the purposes of this CMET, the covered party may not actually be named on the insurance policy (e.g. pedestrian in an auto accident), but may be specified as a covered party when submitting a claim for services.

The policy is described by its policy identifier (may be made up of multiple parts such as plan id, group id, division, section, etc.), type (e.g. private, public, auto, WCB), status and effective date (i.e. date policy in effect).

The author of the policy, known as the insurance carrier, may be noted.

Up to 1 beneficiary/covered party/insured can be specified. Note: more than one beneficiary typically exists for family plans, but only 1 is noted for this CMET. The covered party may be either an animal (e.g. pet insurance) or individual. If the covered party is an individual, then the parent or guardian may be specified for under age individuals.

The policy holder/subscriber may also be noted as an individual (e.g. parent) or organization (e.g. employer).

Message Type List

A_Coverage universal

COCT_MT180000UV04

Parent:

Claims & Reimbursement (FICR_DM000000UV03)

Note: This CMET was new for the Jan 2007 ballot. This is release 2 of A_Coverage, membership ballot 2.

Overview:

The Coverage universal CMET provides detailed information about coverage under any kind of insurance policy or government program (P/P). This CMET is intended to convey coverage information needed to manage, for example, accounts receivables related to the provision of services related to benefits; eligibility determination, eligibility verification, enrollment, and administration of a Covered Party's record.

Policies are differentiated from programs because of substantial differences in their rules for eligibility determination, the types of benefits covered, the rules for coverage, their accountability and oversights, and the degree to which coverage decisions, premiums, reimbursements, and financial participations are related to insurance risk. A policy for insurance coverage is risk based and typically underwritten by a commercial entity. A program is typically subsidized by government funds; not wholly risk-based; and sponsored, underwritten, and administered by government entities or their contractors.

Coverage is to be distinguished from benefits in that benefits are promised under the terms of the contract and awarded if the terms of the contract are met. Coverage is the potential to be awarded benefits. Coverage is "actualized" when an underwriter recognizes and pays the claim for a benefit, e.g., a service required to indemnify the Covered Party for a loss that is covered or "indemnified" under the terms of a policy or program.

The type of benefits that may be covered under a policy or program is specified by the covered benefits(s). A policy or program covers or explicitly does not cover benefits. Each benefit type is a list of financial, service, or product benefits that may be covered, and may include conditions relating to whether the loss indemnified meets the coverage terms. With respect to a health P/P, this may include whether the service is a covered benefit; the medical necessity of the service; and the type and affiliation of providers who may render the services; and may include the financial participation required of a covered party such as deductibles, coinsurance, and copays, and the limits of coverage. With respect to a property and casualty policy, whether the losses result from perils insured against, and may include information relating to the type of property covered, locations covered, individuals' insured, financial participation such as deductibles, and the limits of indemnification. In life insurance covered services specify the causes of death that are explicitly covered or not covered, the benefits covered for beneficiaries, and may include conditions under which the covered party with a terminal illness may receive benefits under the policy while living.

Structurally, this CMET supports conveyance of an entity's coverage record, which may be composed of zero to many P/Ps. A P/P for coverage is an instance of a contract or program that is effective for a specified time period, and may have priority in terms of liability for coverage over other P/Ps in effect. It is the scope of benefits that may be covered, the costs for which the policy holder is indemnified against by the underwriter.

This CMET is a second release of the A_Coverage COCT_RM180000, and is derived from the yet to be released FICO_RM030000 Entity Eligibility Details. This CMET will be used in the FIAB Account Management messages to convey P/P information related to an account. It may also be used in the Patient RMIM (PRPA_RM201301) in future iterations.

The beneficiary of the service to which coverage applies is not referenced in this CMET, since it is inherited from the parent model that uses this CMET, and is in most cases played by the same entity that plays the CoveredParty role. When this CMET is used in the Patient RMIM, the beneficiary and covered party is typically the patient. An exception to this rule is that under some health P/P (1) a newborn may be a patient and a beneficiary, but is not the CoveredParty; in that case, the mother plays the CoveredParty role; or (2) the beneficiary may be a family member of a patient and covered party to whom counseling or care instructions relating to the patient is being provided.

CoverageRecord

The focal class of the Coverage CMET is the CoverageRecord class. This is a grouper class whose purpose is to group one or more policies or programs (P/Ps). It can group many P/Ps under different act statuses. That is, it may be used to group together those P/Ps which are:

...active (in one group) versus

...cancelled (in another group) versus

...suspended versus

...yet to become effective

The parent model should allow this CMET to repeat.

The attributes of the CoverageRecord are:

The CoverageRecord classCode: This class has an act type of Coverage.

The CoverageRecord moodCode: The mood of this act is Event, that is, the coverage contract is something that actually happens.

A beneficiary may not have coverage, the coverage may be unknown, or there may be a record of coverage (CoverageRecord) that includes 0...* coverages, the applicability of which may be known or unknown at a particular point in time. This CMET is intended to support all of these use cases. This is conveyed differently depending upon the context in which the A_Coverage CMET is used.

To indicate that a Patient in the Patient PRPA_RM201301 has no coverage, the Participation coveredPartyOf would not be sent. If it is unknown, a null flavor may be sent.

To indicate that a patient in the FIAB_RM10000 Release 2 has no coverage, the ActRelationship Coverage would not be sent. If it is unknown, a null flavor may be sent.

To indicate that a beneficiary has a record of coverage that includes 0...* coverages, the applicability of which may be known or unknown at a particular point in time, the A_Coverage CMET is sent. If the CoverageRecord has no component P/Ps, this indicates that the beneficiary has a record of coverage that includes no information about P/Ps. The CoverageRecord may consist of one or more P/Ps that have status codes indicating that they are not in effect or suspended. It may include one or more P/Ps under which the beneficiary is not covered because the type of encounter or services required are not covered by these P/Ps. Alternatively, the CoverageRecord could consist of a charity program for which a beneficiary without alternative coverages may be eligible.

The CoverageRecord statusCode: The status of the grouped P/Ps, that is, active, cancelled, completed (expired), suspended, etc. To be specified by a code from the ActStatus code.

The CoverageRecord effectiveTime: The effective date range of the statusCode for this CoverageRecord for this group of P/Ps. This may be important for billing purposes to ensure that coverage information used in a claim is current for the dates of service.

The CoverageRecord may be associated with zero to one beneficiary, which may be represented by R_Patient (univeral) CMET or the Beneficiary Role

The attributes of the Beneficiary are:

The Beneficiary classCode: This class has a a role type of Qualified Entity as denoted by the roleClassCode QUAL, which is an entity that has been recognized as having certain characteristics qualitying it as the beneficiary of services that may be covered by a policy or program within the coverage record.

The Beneficiary code: he type of beneficiary may be specified by a code from the QualifiedRoleType value set, which is used to further qualify an entity playing a qualified role.

The Beneficiary id: Optionally one or more unique identifiers for the beneficiary.

The Beneficiary status: The state of the beneficiary role may be specified by a code from the RoleStatus domain, e.g., the player of the role may be an applicant pending eligibility determination by the scoping organization.

The Beneficiary may be played by an organization, or a living subject, which may be a person.

The Beneficiary is scoped by an organization that sets the criteria for qualifying as a beneficiary.

The CoverageRecord will always be linked to one or more P/Ps.

PolicyOrProgram: This is an instance of a policy or program that is in effect.

The component relationship typeCode: The purpose of this ActRelationship link is that the CoverageRecord "has components".

The component relationship priorityNumber: This link attribute prioritizes coverages, that is, "1" is the primary coverage, "2" is the secondary coverage, etc. Coverage priority determines which of the P/Ps has primary responsibility for coverage and will impact coordination of benefits during the adjudication process.

The attributes of the PolicyOrProgram are:

The PolicyOrProgram classCode: This class has an act type of Coverage.

The PolicyOrProgram moodCode: The mood of this act is Event, that is, the coverage contract is something that actually happens.

The PolicyOrProgram id: One or more unique identifiers for this policy or program. Required to be sent if available.

The PolicyOrProgram code: The coverage type of the P/P shall be specified by a code from the ActCoverageTypeCode value set, e.g., a policy for health, property and casualty, or life insurance, or a program for worker compensation, crime victim compensation, or government subsidized health program .

The PolicyOrProgram statusCode: The status of this P/P, that is, active, cancelled, completed (expired), suspended.

The PolicyOrProgram effectiveTime: The policy or program's effective date and expiration date. This is the plan begin and end date range.

A PolicyOrProgram has associations to the following classes.

CoveredParty:

The P/P is required to be linked to one and only one CoveredParty role if known, which must be played by a kind or instance of a person, an organization, or a non-person living subject that is eligible for P/P benefits. Under a health insurance policy, the Covered Party is the person who is either the subscriber or dependent named in the P/P. Under a health program, the Covered Party is a program eligible. Under property and casualty insurance, the covered party is, for example, the claimant in a liability case or auto accident. Under life insurance, the Covered Party is the person in whose life the beneficiary has an insurable interest. Under reinsurance, the Covered Party is an underwriter. If the CoveredParty is not known, a null flavor is sent.

Both subscriber and dependent can be covered parties (aka beneficiaries). Whether the patient is the subscriber or dependent is distinguished by Beneficiary role code.

A CoveredParty may be a single person, organization, or non-person living subject. A designated population that is not individually differentiated as members of a group may play the role of Covered Party by being a "kind" of person or non-person living subject receiving benefits under a P/P, e.g., reproductive health education provided to all seventh grade children in a school district; needle exchange provided to all needle users within vicinity; or vaccination of a herd of cattle. Note that a kind of organization may not be a Covered Party.

A Covered Party may or may not be played by the same entity who is the beneficiary, e.g., the Covered Party under a life insurance policy is typically not the beneficiary of the policy except in the case of a viatical settlement where the policy is sold at a discount from its face value to pay for care for a terminal illness.

Covered Parties may be scoped by any of the Organizations playing participatory roles in the P/P as underwriters, sponsors or payors.

The CoveredParty participation typeCode: This ActRelationship shall associate one and only one CoveredParty as the target of coverage under the P/P.

The CoveredParty participation sequenceNumber: When a P/P covers multiple named parties, this is the optional ranking order of the covered party, e.g., under a health policy, the subscriber would usually be first.

The CoveredParty negationID: Indicates that the CoveredParty is not covered under a particular P/P under the circumstances. For example, although the beneficiary's CoverageRecord indicates coverage under a worker compensation program, if the current encounter is not work-related, then the person playing the CoveredParty with respect to the worker compensation program may not be deemed to have coverage under that program at the initiation of an encounter. However, this status may change during the course of the encounter if there is a subsequent finding that the patient condition is in fact work-related.

The CoveredParty classCode: This shall be specified by a code from the RoleClassCoveredParty value set, e.g., claimant, program eligible, named insured, individual, subscriber, or dependent.

The CoveredParty id: The primary identifiers for this covered party role, assigned/scoped by either the sponsor, the underwriter or payor. These identifiers are the Covered Party's identification numbers on under a policy or program, and may be carried on an identification card. In atypical cases, there may be more than one, e.g., covered party under a Medicaid managed care plan may be identified with both the person's identifier as a Medicaid eligible and the identifier assigned by the contracting Medicaid managed care plan. The covered party identifier is not necessarily an OID, but may be based on the root OID of the assigning entity.

The CoveredParty code: The type of covered party role is required to be specified by a code from the CoverageRoleType value set, which further specifies the Covered Party Role.class, e.g., handicapped, student, military, injured worker, animal, crime victim, unemployed worker, etc. For example, a Covered Party status may be the result of having a Role.class of Named Insured where the person playing the role has is covered under university health plan as a student. In addition or as an alternative, the same person may play a Covered Party with the Role.class of Dependent where that status is a result of also being a full time student under the age of 23. Thus, the CoveredParty Role.code of "full time student" further specifies both the Role.class of Named Insured and that of Dependent.

The CoveredParty addr: The address of the Covered Party.

The CoveredParty effectiveTime: The effective date and expiration date when the covered party is covered by the P/P. If a dependent is added or deleted from the P/P, then the dependent's effective dates will be different than the P/P effective dates. This is the benefit begin and end date range for the Covered Party.

The CoveredParty may be optionally linked to the PolicyHolder, who has indirect authority over the CoveredParty role status of the playing entity by virtue of discretion afforded the PolicyHolder to cover a particular entity or type of CoveredParty. For example, a PolicyHolder has discretion to purchase a automobile liability policy that covers family members, and may agree to insure only some of members of the family.

The CoveredParty may be the subject of zero or more A_Verifcation (universal) CMET and/or EligibilityStatusObservation, which convey information about the verification of the eligibility.

EligibilityStatusObservation:

The EligibilityStatusObservation classCode: This class has the act type of "observation".

The EligibilityStatusObservation moodCode: The mood of this act is Event, which conveys that an eligibility status observation occurred.

The EligibilityStatusObservation id: The unique identifier(s) for this observation act.

The EligibilityStatusObservation code: The result of the observation may be specified by a code from the ObservationEligibilityIndicatorType value set to indicate the type of information observed to establish eligibility. E.g., evidence of the covered party's health/socio-economic status.

The EligibilityStatusObservation value: Value related to the eligibility status evidence, e.g., a scanned copy of evidence.

PersonalRelationship

The PersonalRelationship Part RoleLink typeCode: The CoveredParty role may be further specified by the Part RoleLink association to its PersonalRelationship role, e.g. as a adopted child, dependent, spouse, etc., to a scoping person. This Personal Relationship is pertinent to the CoveredParty role where the scoper is also playing applicable ResponsibleParty roles, such as subscriber, trustee, or guardian and/or the PolicyHolder role.

The Covered Party may have zero to one personal relationships, which are prioritized in terms of their relevance to the CoveredParty role.

The PersonalRelationship Part participation priorityNumber: Related persons are prioritized in terms of their relevance to the covered party role. For example, the covered party is both the neice and the adopted child of the subscriber and the priorityNumber is which role is has priority for the coverage, i.e., the adopted child.

The PersonalRelationship Part participation effectiveTime: The date range of the personal relationship, that is the begin and end date range of a marriage, adoption, guardian relationship, etc.

PersonalRelationship classCode This role is played by a person.

PersonalRelationship code This code indicates what the personal relationship is with the covered party. This is required to be specified by a code from the PersonalRelationshipRoleType value set, that is, a personal relationship which is relevant to the covered party role, e.g., adopted child, spouse.

ResponsibleParty:

The ResponsibleParty is a person or organization who/which has indirect control over the covered party status. For example, when a CEO has life insurance provided by an employer, then the employer is the responsible party. A subscriber is usually the party responsible for the covered party status of a dependent. An executor of a will may be the party responsible for the healthcare coverage status of dependents.

The ResponsibleParty indirectAuthority participation typeCode: The responsible party may not have sole authority over the covered pary's status, but has partial authority. The policy holder may have overriding authority. A subscriber, who is an absentee parent, has indirect authority to choose not to cover dependents; however a government program may require that the subscriber enroll the dependents in lieu of more costly coverage under the government program.

The responsible party role may be played by a person, such as subscriber, trustee, guardian ad litem, who is authorized to act on behalf of the covered party.

The responsible party may be scoped by an organization, e.g.,a Guardian Ad Lidem may be scoped by a court.

The ResponsibleParty classCode: This role class type is agent, a player who is authorized to act on behalf of a scoper.

The ResponsibleParty code: The responsible party role type is required to be specified by a code from the ResponsibleParty value set. E.g., guardian (of a ward) or subscriber (of dependent).

PolicyHolder:

The P/P may be linked to zero or one PolicyHolder role. The policy holder is the one who holds the policy for health insurance or auto insurance. The holder may be the subscriber for health insurance. An employer may be the policy holder for employees. The policy holder may be a person or organization. The policy holder may be the same person as the covered party, when the subscriber is the patient.

If the covered party is the same person/entity as the policy holder (e.g., subscriber/insured), then the person in the CoveredParty's Beneficiary-CoveredPartyChoice box will be identical to the person in the policy holder's scoping EntityChoice box.

The Holder participation typeCode: The purpose of this ActRelationship link (between P/P and PolicyHolder) is that the P/P is "held by" the policy holder.

The PolicyHolder is an indirect authority over the fact that an entity is a CoveredParty for the policy holder's P/P. An employee/subscriber can add or remove a dependent from being a covered party under the P/P.

The PolicyHolder classCode: This class has a role type of "policy holder" that is scoped by either the sponsor or underwriter.

The PolicyHolder id: The primary identifier for this policy holder role is assigned by the underwriter.

The PolicyHolder addr: The address of the policy holder, which may differ from that of the covered party.

Sponsor

The P/P may be linked to zero or one Sponsor role. The sponsor is the party responsible for providing coverage, e.g., a governmental agency. A role played by an entity, usually an organization that is the sponsor of an insurance plan or a health program. A sponsor is the party that is ultimately accountable for the coverage by employment contract or by law. An sponsor can be an employer, union, government agency, or association. The sponsor decides whether to enter into a coverage contract with an underwriter.

The author participation typeCode: The type of role for this relationship is "responsible party".

The author participation functionCode: An optional code specifying additional detail about the function that the Participation has in the Act, if such detail is not implied by the Participation.typeCode. This shall be specified by a code from the ParticipationFunction value set. New values being added Fall 2006.

The Sponsor classCode: This class has a role type of "sponsor".

The Sponsor id: Optionally one or more unique identifiers for the sponsor. For example, corporation identifiers.

The Sponsor code: The type of sponsor may be specified by a code from the CoverageSponsorRoleType value set, e.g., Multiple Employee Welfare Association (MEWA) or unions or chambers of commerce, which acts as an umbrella sponsor for their members. Some sponsors are fully insured, that is, they delegate risk downstream to an underwriter. Some sponsors are self-insured, that is they are both the sponsor and underwriter, and may also play the role of the payor.

The Sponsor name: The name of the sponsor.

The Sponsor addr: The address of the sponsor.

The Sponsor telecom: The contact numbers for the sponsor.

The Sponsor effectiveTime: The effective date range for an organization in this role of sponsor.

A Sponsor has direct authority over an Underwriter, as the party who contract with the underwriter.

A Sponsor Role may be scoped by an organization authorized to grant recognition to the entity playing this role. E.g., Jurisdictions may recognize an entity as (1) a government agency charged with sponsoring a subsidized health program; or (2) as a Multiple Employer Welfare Association responsible to sponsor health insurance for employees.

Underwriter

The P/P may be linked to zero or one Underwriter role. The underwriter is the author of the contract, for example, an insurance company, reinsurer, self-insured employer, or government sponsored program, such as U.S. Medicaid. There may be multiple underwriters involved in a P/P.

The author participation typeCode: The type of role for this relationship is "author" of the contract.

The author participation functionCode: An optional code which indicates how the underwriter and the payor participate in the coverage act. This shall be specified by a code from the ParticipationFunction value set, for example, primary, subcontracting, passing on risk. New values being added Fall 2006.

The Underwriter classCode: This class has a role type of "underwriter".

The Underwriter id: Optionally one or more unique identifiers for the underwriter. For example, an NAIC identifier.

The Underwriter code: The type of underwriter may be specified by a code from the RoleCode domain. An UnderwriterRoleCode value set will be developed, to include, e.g., property and casaulty, high risk, life, healthcare, worker's compensation.

The Underwriter name: The name of the underwriter.

The Underwriter addr: The address of the underwriter.

The Underwriter telecom: The contact numbers for the underwriter.

The Underwriter effectiveTime: The effective date range for an organization in this role of underwriter.

One underwriter may have direct authority over another underwriter. An underwriter for a P/P may contract with a second underwriter to provide reinsurance. An underwriter may also contract with other underwriters to provide a P/P for some subset of coverages, for example, a managed care plan may subcontract with a provider organization to assume risk for some covered parties. One underwriter may play the role of reinsurer or stop loss carrier to the underwriter that is the primary on the contract with the sponsor. This has consequences in healthcare because the reinsurer may take over the authorization of benefits when stop loss for a covered party is reached.

An Underwriter may have direct authority over a Payor, because they contracted with the payor to administer the P/P.

Payor

The P/P may be linked to zero or one Payor role. The payor is the party responsible for administering the P/P, e.g., paying claims/invoices.

The primaryPerformer participation typeCode: The type of role for this relationship is "performer". There may be multiple payors involved in a P/P.

The primaryPerformer participation functionCode: An optional code which indicates how the payor and the payor participate in the coverage act. This shall be specified by a code from the ParticipationFunction value set. New values being added Fall 2006.

The attributes of Payor are:

The Payor classCode: This class has a role type of "payor".

The Payor id: Optionally one or more unique identifiers for the payor. For example, an NAIC identifier.

The Payor code: The type of payor may be specified by a code from the PayorRoleType value set, e.g., enrollment broker or third party administrator.

The Payor name: The name of the payor.

The Payor addr: The address of the payor.

The Payor telecom: The contact numbers for the payor.

The Payor effectiveTime: The effective date range for an organization in this role of payor.

The Payor may perform or subcontract with 0...* other Payors to perform enrollment, adjudication, utilization management, or provider contracting. For example, a health plan may contract with a third party billing service, an eligibility verification vendor, and a utilization management vendor to perform payor functions.

PreviousPolicyOrProgram

The P/P may be linked to 0..1 PreviousPolicyOrProgram. The parent P/P is replacing or related to or succeeds the previous policy or program.

The replacementOf relationship typeCode: The type of role for this relationship is "replacement".

The PreviousPolicyOrProgram classCode: This class has a role type of "coverage".

The PreviousPolicyOrProgram moodCode: The mood of this act is Event, that is, the coverage contract is something that actually happens.

The PreviousPolicyOrProgram id: Optionally one or more unique identifiers for the PreviousPolicyOrProgram.

The PreviousPolicyOrProgram statusCode: The status of this previous P/P. For example, obsolete if this P/P has been replaced. See pending new x_PreviousActStatus with values: cancelled, nullified and obsolete.

The PreviousPolicyOrProgram effectiveTime: The effective date range for the PreviousPolicyOrProgram.

Benefit

The ActRelationship COVBY typeCode: The P/P may be linked to one or more Benefit(s). The coverage association indicates that the P/P may provide coverage for a benefit if the provision of the benefit meet the coverage rules; or may explicitly exclude coverage for a benefit, in which case the negation indicator is used.

The Benefit classCode PCPR: This class indicates the service provided as a P/P benefit, which may be further specified by associated acts, e.g., the Benefit may have a supporting clinical statement about care provided or the condition of the subject of care as a precondition; may refer to coverage policies related to the provision of the benefit; may be limited by the charges covered under the P/P or financial participations required of the covered party; or may be defined in terms of the service specifications in the BenefitChoice.

The Benefit moodCode: The mood of this act is Definition, that is, a P/P Benefit is defined by this class's attributes, associations, and associated classes.

The Benefit code: The type of benefit is required be specified by a code from the x_ActBillableCode value set if known. For example, medical, chiropractic, dental care, social work, hospice, long term care, ambulance, acupuncture, pharmacy, psychiatry, naturopathy, physical therapy, etc.

The Benefit negationInd: Used to say that this benefit is excluded from coverage, e.g., cosmetic surgery

The Benefit effectiveTime: The effective date range for a benefit.

The Benefit reasonCode: These are the reasons or criteria specified by codes from the ActCoverageReason value set, relating to coverage of a benefit 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.

The ActRelationship INST typeCode: The Benefit may be associated to one or more ServiceChoices. The coverage association indicated that the Benefit may be instantiated by one or more A_Billable, A_SupportingClinicalStatement, A_Transportation CMET or ServiceDefinition that more fully specify the service instantiating the benefit definition. The ServiceDefinition is an act in definition mood that defines services that may be further specified by codes from the x_ActBillableCode

The ActRelationship PRCN typeCode: The Benefit may be associated to one or more A_SupportingClinicalStatement CMET, which convey the services that must be received as a precondition of coverage of the Benefit, e.g., a diagnostic test is required to validate the medical necessity of a procedure in order for that procedure to be a covered benefit under a P/P.

The ActRelationship REFER typeCode: The Benefit may be associated to one or more CoveragePolicy act POLclassCode, which convey the coverage policy or policies that sets rules for the coverage of the Benefit.

The CoveragePolicy moodCode: The mood of this act is Definition, that is, a Benefit CoveragePolicy is defined by this class's attributes.

The CoveragePolicy id: Optionally one or more unique indentifiers for the CoveragePolicy.

The CoveragePolicy code: The type of policy may be specified by codes from the ActPolicyType value set.

The CoveragePolicy statusCode: The status of this CoveragePolicy, obsolete if this CoveragePolicy has been replaced but applied to a Benefit during the P/P effective time and was applicable to the coverage of a Benefit during that time span.

The CoveragePolicy effectiveTime: The effective date range for a coverage policy.

The CoveragePolicy reasonCode: One or more reason codes related to the coverage policy may be selected from the ActCoverageReason value set, e.g., a pre-existing condition exclusion may be the reason for a coverage policy that is referenced by a Benefit that is not covered, i.e., with negationInd set to "true".

The ActRelationship LIMIT typeCode: The Benefit may be associated to one or more CoverageChargeChoice acts.

The CoverageCharge classCodeINVE: This class indicates the rules relating to the limits of charges for a benefit that a P/P will cover.

The CoverageCharge moodCode: The mood of this act is Criterion, which conveys the conditions that must be met for the charges related to the Benefit to be covered.

The CoverageCharge id: Optionally one or more unique indentifiers for the CoverageCharge.

The CoverageCharge code: The type of coverage charge may be specified by codes from the ActCoverageLimitCode value set, e.g., the net amount, unit quantity, or unit price.

The CoverageCharge effectiveTime: The effective date range for a coverage charge rule.

The CoverageCharge unitQuantity conveys the ratio of units per service provision or product dispense, e.g., 2 hour session of physical therapy or 3 boxes of a product per dispense.

The CoverageCharge unitPriceAmt conveys the price per unit, e.g., $50 CAD/1{box} or $100 per hour of physical therapy.

The CoverageCharge netAmt is expressed using a currency {the unit in which monetary amounts are denominated in different economic regions] to express the net amount charged based on the product of applicable coverage charge unity quantity, unityPriceAmt, factorNumber and pointsNumber attributes.

The CoverageChargefactorNumber is the multiplier or percentage used to calculate the rate for each unitQuanitity/unitPriceAmt expressed with a Real integer, e.g., the out-of-network vs. the in-network percentage charge.

The FinancialParticipationCharge classCodeINVE: This class indicates the rules relating to the limits of charges for a benefit that a P/P will cover.

The FinancialParticipationCharge moodCode: The mood of this act is Criterion, which conveys the financial participation charges that the covered party must pay in order for the Benefit to be covered by the P/P.

The FinancialParticipationCharge id: Optionally one or more unique indentifiers for the FinancialParticipationCharge.

The FinancialParticipationCharge code: The type of financial participation required of covered parties may be specified by codes from the ActInvoiceDetailGenericAdjudicationCode value set, e.g., copayment, deductible, or coinsurance.

The FinancialParticipationCharge effectiveTime: The effective date range for a financial participation rule.

The FinancialParticipationCharge unitQuantity conveys the ratio of units per service provision or product dispense for purpose of calculating financial participation, e.g., a 30 or 90 day supply of a product per dispense.

The FinancialParticipationChargeunitPriceAmt conveys the financial participation required per unit of service covered under the benefit, e.g., $15 per hour of physical therapy.

The FinancialParticipationCharge netAmt is expressed using a currency {the unit in which monetary amounts are denominated in different economic regions] to express the net financial participation amount charged based on the product of applicable financial participation unity quantity, unityPriceAmt, factorNumber and pointsNumber attributes.

The FinancialParticipationChargel factorNumber is the multiplier or percentage used to calculate the rate for each unitQuanitity/unitPriceAmt expressed with a Real integer, e.g., the out-of-network financial participation charge is 10% higher than the in-network financial participation charge.

The ActRelationship REFER typeCode: The CoverageChargeChoice may be associated to one or more CoverageChargePolicy POLclassCode, which convey the coverage policy or policies that sets rules for the coverage of the Benefit.

The CoverageChargePolicy moodCode: The mood of this act is Definition, that is, a Benefit CoveragePolicy is defined by this class's attributes.

The CoverageChargePolicy id: Optionally one or more unique indentifiers for the CoverageChargePolicy.

The CoverageChargePolicy code: The type of policy may be specified by codes from the ActPolicyType value set.

The CoverageChargePolicy statusCode: The status of this CoveragePolicy, obsolete if this CoveragePolicy has been replaced but applied to a Benefit during the P/P effective time and was applicable to the coverage of a Benefit during that time span.

The CoverageChargePolicy effectiveTime: The effective date range for a coverage charge policy.

The CoverageChargePolicy reasonCode: One or more reason codes related to the coverage charge policy may be selected from the ActCoverageReason value set, e.g., a dental coverage charge policy reason of "maximum total amount" is referenced by a CoverageCharge rule with the net amount that will be covered for a dental benefit; or a spend down requirement is the reason for a policy referenced by a financial participation charge deductible that limits the clinical services covered during the benefit effective time.

The PolicyOrProgramLimit

The ActRelationship LIMIT typeCode: The P/P may be associated to one or more PolicyOrProgramLimits, which conveys coverage limitations such as the maximum coverage amounts, maximum coverage period, and covered party type limitations.

The PolicyOrProgramLimit OBSclassCode: This class has an act type of Observation.

The PolicyOrProgramLimit moodCode: The mood of this act is Definition, that is, a PolicyOrProgramLimit is defined by this class's attributes.

The PolicyOrProgramLimit id: Optionally one or more unique idenfiers for the PolicyOrProgramLimit.

The PolicyOrProgramLimit code: The type of P/P limit may be specified by a code from the ActCoverageLimitType, e.g., limit on the maximum period, amount, unit price, or type of covered party. value set.

The PolicyOrProgramLimit effectiveTime: The effective date range for a PolicyOrProgramLimit.

The PolicyOrProgramLimit reasonCode: The policy or program reason may be specified by a code from the ActCoverageLevelReasonCode, e.g., covered parties are limited to spouse and children only.

The PolicyOrProgramLimit value: May be used to specify a coverage limit observation value, e.g., the life-time maximum for a P/P is one million dollars.

Common Message Element Types Used

E_LivingSubjectInformational	COCT_MT030007UV
R_PatientUniversal	COCT_MT050000UV01
A_TransportationUniversal	COCT_MT060000UV01
E_OrganizationUniversal	COCT_MT150000UV02
E_OrganizationUniversal	COCT_MT150000UV02
A_BillableUniversal	COCT_MT280000UV04
A_SupportingClinicalStatementUniversal	COCT_MT530000UV
A_SupportingClinicalStatementUniversal	COCT_MT530000UV
A_VerificationUniversal	COCT_MT810000UV

Message Type List

Cr Event New A_Coverage universal

COCT_MT510000UV06

Parent:

Claims & Reimbursement (FICR_DM000000UV03)

Note: This CMET is normative in the HL7 V3 2006 Normative Edition.

The FinancialTransaction CMET is used to associate costs, charges or other financial transactions with an act or entity.

The financial transaction includes transaction type, amount and exchange rates.

Common Message Element Types Used

A_AccountPayorUniversal	COCT_MT110100UV04
A_AccountPayeeUniversal	COCT_MT110200UV04

Message Type List

A_FinancialTransaction universal

COCT_MT190000UV04

Parent:

Claims & Reimbursement (FICR_DM000000UV03)

Note: This CMET is normative in the HL7 V3 2006 Normative Edition.

The InvoiceCoordination CMET is used to package explanation of benefits (EOB) information from one Adjudicator to be included in a subsequent Invoice to a downstream Adjudicator for coordinating Invoices amongst Adjudicators (COB - coordination of benefits).

Message Type List

A_InvoiceCoordination basic

COCT_MT680002UV04

Parent:

Claims & Reimbursement (FICR_DM000000UV03)

Note: This CMET is normative in the HL7 V3 2006 Normative Edition.

The InvoiceCoordination CMET is used to package explanation of benefits (EOB) information from one Adjudicator to be included in a subsequent Invoice to a downstream Adjudicator for coordinating Invoices amongst Adjudicators (COB - coordination of benefits).

Common Message Element Types Used

A_BillableUniversal

COCT_MT280000UV04

Message Type List

A_InvoiceCoordination enhanced

COCT_MT680003UV04

Parent:

Claims & Reimbursement (FICR_DM000000UV03)

Note: This CMET is normative in the HL7 V3 2006 Normative Edition.

The InvoiceCoordination CMET is used to package explanation of benefits (EOB) information from one Adjudicator to be included in a subsequent Invoice to a downstream Adjudicator for coordinating Invoices amongst Adjudicators (COB - coordination of benefits).

Common Message Element Types Used

A_BillableUniversal

COCT_MT280000UV04

Message Type List

A_InvoiceCoordination universal

COCT_MT680000UV04

Parent:

Claims & Reimbursement (FICR_DM000000UV03)

Note: This CMET is normative in the HL7 V3 2006 Normative Edition.

The BillableClinicalProduct CMET provides detailed information on clinical products, required to support billing information for an Invoice, Pre-Determination, Coverage Extension or Authorization.

The patient is not referenced in this billable act as it is inherited from the parent model (as CoveredPartyAsPatient).

How the product was provided is specified in the ClinicalBillableProduct act and the product relationship provides serial number, identifier, manufacturer, packaging and warrantor. It is supported by the performer, referrer and consultant, the diagnosis and the indicating of the locations for source and to/from delivery information. The order and who ordered it may be identified.

Common Message Element Types Used

R_ServiceDeliveryLocationContact	COCT_MT240003UV02
R_ServiceDeliveryLocationContact	COCT_MT240003UV02
R_ServiceDeliveryLocationContact	COCT_MT240003UV02

Message Type List

A_BillableClinicalProduct universal

COCT_MT490000UV04

Parent:

Claims & Reimbursement (FICR_DM000000UV03)

Note: This CMET is intended to replace or revise material in the HL7 V3 2006 Normative Edition standard. This is the first membership ballot for this CMET and its basic, referral and encounter variants.

Overview:

The BillableClinicalService universal CMET provides detailed clinical information on orderable or billable health care related services including clinical interventions, procedures or services; observations; accommodations; substance administration; encounters; transportation; oral health care; or any care provided to living subjects, required to support the generation or posting of a Charge; an Invoice, Pre-Determination, Coverage Extension or Authorization in the event and intent mood; or to describe detailed benefits covered under a policy or program in the definition mood.

The patient may be referenced in this billable act via the R_Patient (universal), or it may be inherited from the parent model (as CoveredPartyAsPatient or the R_Patient CMET information that may propagate from an ancestral A_Charge). If patient information contained in this CMET differs from patient information propagated from any ancestor Acts to which the A_BillableClinicalService CMET is associated, then it the patient information at this level overrides that propagated by the ancestor, but does not propagate further.

The service ordered (intent mood) or billed (event mood) is specified in the ClinicalBillableService act. Information relating to the service includes details about the provider (performer), and one or more assisting providers, e.g., a supervisor (as secondary performers), referrers, or consultants. Substitution can be indicated. Details relating to an encounter for the service and any related diagnosis may be sent.

Reasons for the service may be an injury, which may or may not be an accident, and may include a description of the injury site location. The location where a service was provided may be indicated as well as the location where a specimen was collected.

If the service was provided in the context of an encounter, admit and discharge dates may need to be specified.

If the service affected a product (e.g. repair a wheelchair), then the product is identified.

If the service involved a reusable device (e.g. durable medical equipment), then the device is identified.

Please note that in an Invoice, the billing codes transmitted may or may not differ from the clinical information coding. Clinical information is carried in this BillableClinicalService CMET included in the Invoice, however, the billing codes themselves are in the InvoiceElementDetail.code and InvoiceElementDetail.modifierCode, not in this CMET.

BillableClinicalService Attributes

The focal class (and entry point) of the BillableClinicalService RMIM is the BillableClinicalService class. The attributes of the BillableClinicalService are:

The BillableClinicalService classCode: The x_ActOrderableOrBillableService.classCode value set includes those relevant healthcare acts class shall be sent. The domain x_ActOrderableOrBillableService.classCode allows this CMET to be used for other types of acts, in addition to procedures.

The BillableClinicalService moodCode shall be selected from the ActMoodCompletionTrack for services that are orderable (intent mood), billable (event mood), or covered as orderable or billable (definition mood).

The BillableClinicalService id: One or more unique identifiers for this specific billable service. Required to be sent if available.

The BillableClinicalService code: The type of billable service shall be specified by a code from the x_ActBillableServiceCode value set. The x_ActBillableServiceCode vocabulary expands the use of this CMET to other Acts besides procedures and defines a subset of ActCodes for those acts that are billable.

The BillableClinicalService effectiveTime: The duration and date/time of the occurrence of a billable service or the time of interest from the perspective of the intent to provide the billable service shall be sent.

The BillableClinicalService repeatNumber: Sent to indicate the minimal and maximal number of repetitions of the billable service, e.g., the same service delivered twice on the same day, or e.g., quantity range for pre-determination or authorization of multiple occurrences of the same service. Required to be sent if available.

The BillableClinicalServiceconfidentialityCode: May be sent to indicate one or more codes that control the disclosure of all information related to the BillableService conveyed in an instance of the CMET.

The BillableClinicalService reasonCode: May be sent to indicate one or more reasons for the performance of the BillableClinicalService that are related but not integral to the service, such as patient's preference, medical necessity, duplicate therapy, fraudulent prescription, or care protocol. Value sets within the ActOrderableOrBillableServiceReason vocabulary domain are available in the universal, and the variants as appropriate to the choice of value set from the classCode vocabulary domain, Actx_OrderableOrBillableService.

Vocabulary domain ActOrderableOrBillableServiceReason includes other act reasons, not just procedure reasons. This domain excludes reasons specified by diagnosed conditions. Examples of applicable values from this domain include duplicate therapy and fraudulent prescription codes from the subset ActBillableClnicalServiceReason abstract value set. This is a subset of ActReason for those ActReasons which can be used for orderable or billable acts.

Links to Other Acts

A BillableClinicalService may link to other acts:

New to this ballot: The ActRelationship subject1: This is a link to the patient information conveyed from the R_Patient (universal) CMET via context conduction.

The Participation reusableDevice: The BillableClinicalService may be linked to one Device role, which indicates that a reusable device, e.g., durable medical equipment was involved in this BillableClinicalService.

The Device id is a mandatory unique identifier for the device, e.g., equipment ID.

The ActRelationship subjectOf2: The BillableClinicalService may be linked to one Substitution act.

The Substitution act indicates that this BillableClinicalService was substituted for another, unspecified service.

The ActRelationship subjectOf1: The BillableClinicalService may be linked to one BillableModifier observation event by the subjectOf1 association of the BillableModifier to the BillableClinicalService.

The BillableModifier observation event indicates that this BillableClinicalService is the subject of a modifying code.

A procedure code in the focal class may be modified by related information provided by the BillableModifier observation event, i.e., codes modifying ActBillableCodes, e.g., Left, Right. The modifier is determined by the BillableModifier.code, which is selected from the ActBillableModifierCode vocabulary Domain, and which must be sent if available. Note that this code may be incorporated as an InvoiceElement.modifierCode in an Invoice related to this service.

The ActRelationship componentOf: The BillableClinicalService may be linked to one PatientEncounter act event. The relationship is componentOf, because if there is an association to an encounter, then that encounter is intrinsic to the service being ordered or billed.

The PatientEncounter id is one or more unique identifier for the encounter, e.g., the encounter number, which is required to be sent if available.

The PatientEncounter code is an optional code for encounter type, e.g., ambulatory, emergency, home health, short stay. Code strength is CWE.

New to this ballot (definition changed): The PatientEncounter effectiveTime, the "administrative" time, i.e., the encounter start and end date required to be chosen by business rules, e.g., the activity time would be from set up of a surgical suite through the clean up vs. the time the patient was in surgery, as opposed to the actual time the encounter took place.

New to this ballot: The PatientEncounter activityTime is the actual patient activity time interval starting with the administrative onset of the encounter (e.g. admission, registration, patient arrival) and ending with the patient's departure (e.g. discharge). For active encounters the end of the effectiveTime range is the anticipated end date-time. Required to be sent if available. This is the actual time the encounter took place.

The PatientEncounter priorityCode (admission type) is drawn from the x_EncounterAdmissionUrgency value set to indicate the urgency for starting a patient encounter, e.g., routine, urgent, emergency, or elective.

The PatientEncounter admissionReferralSource code used to categorize the type of place or organization responsible for the patient immediately prior to their admission; for example, in the United States, this is identified in UB-92 Form Locator 20, Source of Adm(ission). The code is selected from the EncounterReferralSource value set

The PatientEncounter dischargeDispositionCode is selected from the EncounterDischargeDisposition vocabulary domain.

New for this ballot: The ActRelationship sourceOf DIAG: The PatientEncounter may be linked to one or more PresentingDiagnosis observations. This diagnosis is the reason for the patient encounter, i.e., the presenting diagnosis for symptoms, which may differ from the administrative diagnoses (admit, discharge, etc.).

The priorityNumber may be used to indicate primary diagnosis, secondary diagnosis, etc.

The Diagnosis code ObservationIndicationType shall indicate the type of types of indications such as diagnosis, symptom and other indications such as contrast agents for lab tests.

The Diagnosis text can be used to supplement a diagnostic code.

The Diagnosis value shall indicate 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., and is selected from the ObservationValue domain IndicationValue value set, which indicates the

New for this ballot: The ActRelationship sourceOf DIAG: The BillableClinicalService may be linked to one or moreAdministrativeDiagnosis observations. This diagnosis is the reason for a healthcare service, i.e., the administrative diagnoses (admit, discharge, etc.), which may differ from the presenting diagnosis for symptoms.

The priorityNumber may be used to indicate primary diagnosis, secondary diagnosis, etc.

The Diagnosis code ObservationDiagnosisType shall indicate the type of diagnosis, e.g., admission, intermediate, or discharge diagnosis.

The Diagnosis text can be used to supplement a diagnostic code.

The Diagnosis value shall indicate the diagnosis code itself, selected from the ObservationValue domain DiagnosisValue value set, which indicates the observed diagnosis.

The ActRelationship reason1: The BillableClinicalService may be linked to one or more Injury observation events. The sequenceNumber shall be used to indicate the relevance of this injury observation to this service .

The Injury code ActInjuryCode shall indicate the type of injury that the injury coding specifies.

reason1: The BillableClinicalService is required to be linked to one or more Injury observation events if applicable. The sequenceNumber shall be used to indicate the relevance of this diagnosis to this service.

The Injury value has values for observations about the injury selected from the InjuryObservationValue value set, which is required to be sent if available.

The Injury targetSiteCode InjuryActSite indicates the site of the injury, i.e., the body part and side of the body.

The Participation origin: The Injury may be linked to one InjuryLocation, which is a role played by the location where the injury occurred, and which may be located by the distance measured from one or more reference places. Association is optional.

The InjuryLocation id is one or more unique identifiers for the injury location.

The InjuryLocation code indicates the location role type selected from the LocationRoleType vocabulary with coding strength CWE.

New for this ballot: the vocabulary domain changed from ServiceDeliveryLocationRoleType to LocationRoleType to allow other types of location than service delivery locations, such as injury/accident sites (stairs, playground, road).

The InjuryLocation name is one or more optional and unordered names for the injury location.

The InjuryLocation addr is an address for the injury location.

The InjuryLocation telecom is one or more optional and unordered phone numbers for the injury location.

The Participation subjectOf: The InjuryLocation may be the subject of one or moreA_SpatialCoordinate (universal) CMET COCT_MT960000., which conveys the distance between any one or more InjuryPlaces scoping the InjuryLocation where the injury occurred as played by another InjuryPlace. The association is required if there is a scoping InjuryPlace. For example, the InjuryLocation is played by an InjuryPlace, e.g., the middle of the Harvard Bridge, which is the subject of a distance measure with value of 10 smoots from the scoping InjuryPlace, the Cambridge entrance of the bridge and 2 smoots from the scoping Injury place, the west side of the bridge

One InjuryPlace entity may play the InjuryLocation role. One or more different InjuryPlace entities may scope the InjuryLocation. If there is one or more scoping InjuryPlace entities, then the InjuryLocation is required to be the subject of one or more DistanceMeaurements, all of which must have the InjuryLocation as their subject.

The InjuryPlace is an instance of a place entity that may have an id.

The InjuryPlace may have a code selected from the PlaceEntityType vocabulary domain.

The InjuryPlace may have one or more names.

The InjuryPlace may have a desc[ription].

component: The BillableClinicalService may be linked to one SpecimenCollectionEvent procedure event, if the service involves collection of a specimen.

location: The SpecimenCollectionEvent shall be linked to one R_ServiceDeliveryLocation which is a physical location where the specimen collection took place. This may be the same location as the location of the parent service.

product: The SpecimenCollectionEvent shall be linked to one Specimen, which is the product of the specimen collection event.

location: The BillableClinicalService may be linked to one R_ServiceDeliveryLocation.

inFullfillmentOf1: The BillableClinicalService may be linked to one or more ServiceRequests. This is the order placed for the service.

The ServiceRequest id is one or more optional unique identifiers for the ServiceRequest, e.g., an order number.

The ServiceRequest code is the clinical coding for what was ordered, which is required to be sent if available.

author: The ServiceRequest is required to be linked to one AssignedEntity if applicable. This is the provider who placed the order for the service.

The Assigned Entity role may be played by a ProviderPerson, an Animal, or a Device2 as appropriate to the participation of the AssignedEntity in the BillableClinicalService.

The AssignedEntity id is one or more unique identifiers for the provider, e.g., institutional provider number, National Provider Identifier (NPI), etc. Required to be sent if available.

The AssignedEntity role.code the functional role assigned by the entity (organization, board, institution) that scopes the playing entity, and may support crosswalks between the HealthCareProvider role type and local provider or specialty code sets. Required to be sent if available.

IndirectAuthority: The AssignedEntity role may be linked to one or more HealthCareProvider roles.

The HealthCareProvider id is one or more optional unique identifiers for the provider type, e.g., a provider taxonomy code in the US realm.

The HealthCareProvider role.code may further specify the provider type, and is selected from the HealthCareProviderRoleType abstract value set. In the U.S. realm, this would be the provider taxonomy code.

The HealthCareProvider effectiveTime is optional time stamp or time interval during which the provider's role type is in effect.

The HealthCareProvider role may be played by a ProviderPerson entity.

The Participation consultant: The BillableClinicalService may be linked to one or more AssignedEntity. This is a provider who was brought in for a consultation regarding this case. Constraint: The consultant, if indicated, shall be played by either be a ProviderPerson or a Device2.

The Participation responsibleParty: The BillableClinicalService may be linked to oneAssignedEntity. This is the provider who is ultimately responsible for providing this service, i.e., the supervisor, e.g., the attending physician, or the doctor for a nurse. If not present, it should be assumed that the performer is the responsibleParty. Constraint: The responsibleParty, if indicated, shall be played by a ProviderPerson.

The Participation author: The BillableClinicalService may be linked to one AssignedEntity. This is the provider who reports the clinical service, who stated what the service was and who is responsible for doing so. Others may not be allowed to alter the reporting of the service. Constraint: The playing entity, if indicated, shall be played by a ProviderPerson.

The Participation secondaryPerformer: The BillableClinicalService may be linked to one or more AssignedEntity. This is a provider who assists the primary performer. A secondaryPerformer may be played by a ProviderPerson, a Device2 (e.g., robot) or an Animal (e.g., a service animal).

The Participation performer: The BillableClinicalService may be linked to one AssignedEntity. This is the provider who is the primary performer of the service. A performer may be played by a ProviderPerson, a Device2 (e.g., robot) or a NonPersonLivingSubject (e.g., a service animal, fish used for Ichtiotherapy, bacteriophage).

The AssignedEntity role may be played by a ProviderPerson.

The ProviderPerson name shall be the name of the provider person.

The ProviderPerson telecom is the contact number(s) of the provider person, and is required to be sent if available.

The ProviderPerson administrativeGenderCode is the gender of the provider person, and is required to be sent if available.

The ProviderPerson birthTime is the birth date of the provider person, which is required to be sent if available.

The ProviderPerson addr[ess] is the address of the provider person, which is required to be sent if available.

The assignedEntity role may be played by an NonPersonLivingSubject (NPLS).

The NPLS id is an optional unique identifier for the NPLS.

The NPLS code NonPersonLivingSubjectEntityType is an optional code for the type of NPLS, e.g., dog.

The NPLS name is optional text for the name the of the NPLS.

The assignedEntity role may be played by a Device2.

The Device2 id is the optional unique identifier of the device.

The Device2 code is an optional code for the type of device.

The Device2 name is optional text for the name of the device.

The Device2 manufacturerModelName is an optional character string with code (SC data type) for the manufacturer's model name for the device, which is selected from the ManufacturerModelName vocabulary domain.

TheDevice2 softwareName is an optional character string with code (SC data type) for the device's software name, which is selected from the SofwareName vocabulary domain.

The ActRelationship reason2:: The BillableClinicalService may be linked to one or more reasons, each of which is a choice between a PatientCareProvisionRequest or diagnosis.

The reason2 sequenceNumber is an optional number indicating the primacy of referrals or diagnoses where more than one diagnosis or request is the reason for the BillableClinicalService. This will support indicating primary and secondary diagnoses.

PatientCareProvisionRequest. This is the referral from another provider.

The PatientCareProvisionRequest id is one or more unique identifiers for the referral, e.g., the referral number, which is required to be sent if available.

The PatientCareProvisionRequest code may specify the type of service referral and is selected from the ActCode domain.

The PatientCareProvisionRequest effectiveTime is the time or time period during which a referral request is in effect, which is required to be sent if available.

The Participation author: The PatientCareProvisionRequest is required to be linked to one AssignedEntity. This is the provider who made the referral request.

The author time is the time when the referral request was made, which must be sent if available.

diagnosis: One or more diagnoses which are the reason for the service, or the reason the referral was made. This is a shadow of the Diagnosis observation associated with the PatientEncounter, and has the same attributes.

product: The BillableClinicalService may be linked to one or more ManufacturedProduct roles.

TheManufacturedProduct role is any product used while providing the service, e.g., a drug or device.

The ManufacturedProduct id is a unique identifiers for one specific instance of a product, e.g., serial number, which must be sent if available.

The ManufacturedProduct code is a code which identifies what the product is, e.g., a catalogue number or a model number. Required to be sent if available.

The ManufacturedProduct role may be scoped by a ManufacturedProductOrganizationentity.

The ManufacturedProductOrganization entity is the manufacturer of the product.

The ManufacturedProductOrganization name is the name or the manufacturer, which is required to be sent if available.

The ManufacturedProductOrganization telcom is the phone number (and/or other contact numbers) of the manufacturer, which is required to be sent if available.

The ManufacturedProduct role may be played by a Manufacturedmaterial entity.

The ManufacturedProduct is the manufacturer of the product.

The Manufacturedmaterial code identifies the type of material entity by a selection from the MaterialEntityClassType vocabulary domain, e.g., a HCPCS code, which is required to be sent if available.

Common Message Element Types Used

R_PatientUniversal	COCT_MT050000UV01
R_ServiceDeliveryLocationContact	COCT_MT240003UV02
A_SpatialCoordinateUniversal	COCT_MT960000UV05

Message Type List

A_BillableClinicalService universal

COCT_MT290000UV06

Parent:

Claims & Reimbursement (FICR_DM000000UV03)

Note: This CMET is normative in the HL7 V3 2006 Normative Edition.

The CoveredParty CMET specifies a particular covered party under an insurance policy. For the purposes of this CMET, the covered party may not actually be named on the insurance policy (e.g. pedestrian in an auto accident), but may be specified as a covered party when submitting a claim for services.

The policy is described by its policy identifier (may be made up of multiple parts such as plan id, group id, division, section, etc.), type (e.g. private, public, auto, WCB), status and effective date (i.e. date policy in effect).

The policy holder/subscriber may also be noted as an individual (e.g. parent) or organization (e.g. employer).

Message Type List

R_CoveredParty universal

COCT_MT500000UV04

Parent:

Claims & Reimbursement (FICR_DM000000UV03)

Note: This CMET is normative in the HL7 V3 2006 Normative Edition.

The Guarantor CMET is used to identify the role of guarantor for a particular person (e.g. patient). A guarantor takes financial responsibility over an account.

This CMET describes the account, type of account, effective dates for the account (e.g. for credit cards, the start/end dates), an account name (e.g. name on the credit card) and balance.

The account holder is noted as the guarantor, which could either be an individual or organization. If the account holder is a person, it may be useful to note the language that the account holder is conversant in. The person that scopes the guarantor (e.g. patient) may also be noted.

Message Type List

R_Guarantor universal

COCT_MT670000UV04

Parent:

Clinical Statement Pattern (COCS_DM000000UV)

The OralHealth CMET is used to describe an Oral Health observation that is pertinent to adjudication of an invoice

Message Type List

A_OralHealthObservation universal

COCT_MT760000UV04

Parent:

Clinical Statement Pattern (COCS_DM000000UV)

This CMET is used to supply clinical information in support of clinical services (ordering, scheduling, reporting, etc.). This CMET is based on the Clinical Statement Pattern but constrained to limit the complexity of supporting information.

Common Message Element Types Used

R_PatientPersonInformational	COCT_MT050207UV07
R_PatientPersonInformational	COCT_MT050207UV07
R_SpecimenLite	COCT_MT080200UV09
R_SpecimenLite	COCT_MT080200UV09
R_AssignedEntityUniversal	COCT_MT090000UV01

Message Type List

A_SupportingClinicalStatement minimal

COCT_MT530004UV

Parent:

Clinical Statement Pattern (COCS_DM000000UV)

This CMET is used to supply clinical information in support of clinical services (ordering, scheduling, reporting, etc.). This CMET is based on the Clinical Statement Pattern with derived objects where necessary (sourceOf/targetOf to sourceOf and targetOf).

Common Message Element Types Used

R_PatientUniversal	COCT_MT050000UV01
R_PatientUniversal	COCT_MT050000UV01
R_SpecimenUniversal	COCT_MT080000UV09
R_SpecimenUniversal	COCT_MT080000UV09
R_AssignedEntityUniversal	COCT_MT090000UV01
R_AssignedPersonIdentified/confirmable	COCT_MT090102UV02
R_MedicationUniversal	COCT_MT230100UV

Message Type List

A_SupportingClinicalStatement universal

COCT_MT530000UV

Parent:

None

This is the informational variant of E_Device universal.

Message Type List

E_Device informational

COCT_MT140007UV

Parent:

None

This CMET is used in several places where an "intelligent" device is playing a role in healthcare. Current usage examples include devices acting as "agents" and devices receiving an identity as an "identified" device. The core class includes the code attribute to provide for identification of the type of device, and both manufacturer and software names to characterize what is frequently a computer system.

Further, the device includes an optional repeating Role association that is played by the device and scoped by a person. This allows the sender to further characterize the device according to the person assigned the device to its task, certified it for service, owns it, , etc.

Message Type List

E_Device universal

COCT_MT140000UV02

Parent:

None

The A_DicomCompositeObjectReference minimal CMET is used to reference DICOM composite objects within HL7 Version 3 messages in the context of acts and observations. It provides detailed information on the referenced DICOM composite object such as images, presentation states and DICOM structured documents. Mappings from DICOM object attributes to the various Act attributes are provided. The CMETs for the HL7 V3 message DICOM composite object references and the corresponding CDA Release 2 section entries are structurally identical. For the CDA section entries different clone names are used according to the specified entry names in the CDA Release2.

Note: The A_DicomCompositeObjectReference minimal CMET COCT_RM830120 may be used in combination with COCT_RM830110 which provides a single location for lookup of referenced DICOM composite objects of an HL7 V3 message (identifying information on the DICOM study/series/instance hierarchy can be found there).

The following description of the act classes and act relationships contains the attribute mappings of HL7 V3 attributes to DICOM (Digital Imaging and Communications in Medicine) tags. The group and element number of the mapped DICOM tags are listed in parenthesis. The CDA mappings specify the use of the CMET act classes and act relationships as CDA Release 2 document section entries.

1 SopInstance

The SopInstance act class contains the DICOM Service Object Pair (SOP) Instance information for referenced DICOM composite objects. The SopInstance act class is used to reference both, image and non-image DICOM instances. The text attribute contains the DICOM WADO (Web Access to Persistent DICOM Objects, DICOM Standard PS 3.18) reference.

Table 1 DICOM Composite Object Reference in an HL7 v3 Act

Attribute	Data Type	Multiplicity	Value
classCode	CS	1..1	DGIMG
moodCode	CS	1..1	EVN
id	II	1..1	<SOP Instance UID (0008,0018) as root property with no extension property> Uniquely identifies the SOP Instance.
code	CE	1..1	<SOP Class UID (0008,0016) as code property, 1.2.840.10008.2.6.1 as codeSystem property, DCMUID as codeSystemName property, SOP Class UID Name (from PS3.6) as displayName property>: Unique Identifier for the SOP Class as Code Property
title	ST	0..1	SOP Class UID derived name
text	ED	0..1	<application/DICOM as mediaType property, WADO reference (see Table X.3-6) as reference property>
effectiveTime	TS	0..1	<Content Date (0008,0023): The date the content creation (e.g. image pixel data, document) started; and Content Time (0008,0033 ): The time the content creation (e.g. image pixel data, document) started.>

Note: The DGIMG classCode is used to reference all DICOM Composite Instances, not just diagnostic images.

WADO is a service that enables the Web Client System to retrieve DICOM Persistent Objects managed by a Web Enabled DICOM Server, through the HTTP/HTTPs protocol. The WADO reference uses an URI with query parameters (Table 7). Access to the content of a data object is enabled by specifying a "link" pointing to a specific DICOM Persistent Object by means of its URL/URI and specifying its DICOM object Instance UID and the transfer syntax to be employed.

Table 2 WADO Reference in HL7 DGIMG Observation.Text

WADO Component	Source
<scheme>://<authority>/<path>	Configuration setting, used by the conversion process, identifying the WADO server
?requestType=WADO	Fixed
&studyUID=<uid>	Study Instance UID for referenced instance
&seriesUID=<uid>	Series Instance UID for referenced instance
&objectUID=<uid>	SOP Instance UID for referenced instance
&contentType=application/DICOM	Fixed

1.1 CDA Mapping (Class Name and Attributes used for CDA Documents)

• Act clone name of the CDA entry is "Observation" instead of "SopInstance". The attributes and attribute values of this CDA entry "Observation" are identical to those listed in table 1 and 2.

2 ActRelationship SUBJECT (SopInstance recursive actRelationship)

This optional recursive "SUBJECT" actRelationship is used to link a referenced DICOM Presentation State to one or more associated referenced DICOM images (SopInstance act class is used in both cases) it is applied to.

2.1 CDA Mapping (ActRelationship Name and Attributes used for CDA Documents)

• ActRelationship Clone name: entryRelationship (replaces SUBJECT)
• ActRelationship.typeCode: x_ActRelationshipEntry (Constraint: Fixed value = SUBJ)
• ActRelationship.contextControlCode: "AP" (Additive Propagating)
• ContextConductionInd: "true"

3 ActRelationship REASON (SopInstance to PurposeOfReference)

This optional "REASON" actRelationship is used to relate a referenced DICOM composite object (SopInstance ActClass) with the PurposeOfReference ActClass which includes the coded purpose(s) of reference.

3.1 CDA Mapping (ActRelationship Name and Attributes used for CDA Documents)

• ActRelationship Clone name: entryRelationship (replaces REASON)
• ActRelationship.typeCode: x_ActRelationshipEntry (Constraint: Fixed value = RSON)
• ActRelationship.contextControlCode: "AP" (Additive Propagating)
• ContextConductionInd: "true"

4 PurposeOfReference

Describes the purpose the DICOM composite object reference is made for. Appropriate codes such as externally defined DICOM codes may be used to specify the semantics of the purpose of reference. When absent, implies that the reason for the reference is unknown.

Codes specified in DICOM Part 16 "Content Mapping Resource" (DICOM PS 3.16) shall be used to designate the coded purpose of reference. Candidate codes are contained in the DICOM Context Groups 3407, 7002, 7003 and 7005. The attribute mapping for the code attributes are listed in table 3.

Table 3 DICOM Coded Purpose of Reference in an HL7 v3 Act

Attribute	Data Type	Multiplicity	Value
classCode	CS	1..1	OBS
moodCode	CS	1..1	EVN
code	CE	1..1	<Code Value (0008,0100) as code property, 1.2.840.10008.2.16.4 as codeSystem property, Coding Scheme Designator (0008,0102) as codeSystemName property, Code Meaning (0008,0104) as displayName property>

4.1 CDA Mapping (Class Name and Attributes used for CDA Documents)

• Act Clone Name: Observation
• Act clone name of the CDA entry is "Observation" instead of "PurposeOfReference"
• The attributes and attribute values of this "Observation" CDA entry are identical to those listed in table 3

5 ActRelationship COMPONENT (SopInstance to ReferencedFrames)

This optional "COMPONENT" actRelationship is used to link a referenced DICOM composite object to one or more frames of a DICOM multi-frame image SOP instance.

5.1 CDA Mapping (ActRelationship Name and Attributes used for CDA Documents)

• ActRelationship Clone name: entryRelationship (replaces COMPONENT)
• ActRelationship.typeCode: x_ActRelationshipEntry (Constraint: Fixed value = COMP)
• ActRelationship.contextControlCode: "AP" (Additive Propagating)
• ContextConductionInd: "true"

6 ReferencedFrames

This act class shall be used if the referenced DICOM SOP instance is a multi-frame image and the reference does not apply to all frames. The list of integer values for the referenced frames of a DICOM multi-frame image SOP instance is contained in the Boundary ActClass.

Table 4 DICOM Referenced Frames in an HL7 v3 Act

Attribute	Data Type	Multiplicity	Value
classCode	CS	1..1	ROIBND
moodCode	CS	1..1	EVN
code	CV	1..1	<Code Value (0008,0100) as code property, 1.2.840.10008.2.16.4 as codeSystem property, DCM as codeSystemName property, Code Meaning (0008,0104) as displayName property>: Proposal to define an appropriate DICOM code has been submitted

6.1 CDA Mapping (Class Name and Attributes used for CDA Documents)

• Act Clone Name: Observation
• Act clone name of the CDA entry is "Observation" instead of "ReferencedFrames"

7 ActRelationship Component (ReferencedFrames to Boundary)

This "COMPONENT" actRelationship is used to link the ReferencedFrames ActClass to the Boundary ActClass which contains the list of integer values for the referenced frames of a DICOM multi-frame image SOP instance.

7.1 CDA Mapping (ActRelationship Name and Attributes used for CDA Documents)

• ActRelationship Clone name: entryRelationship (replaces COMPONENT)

• ActRelationship.typeCode: x_ActRelationshipEntry (Contstraint: Fixed value = COMP)

8 Boundary

The act class contains a list of integer values for the referenced frames of a DICOM multi-frame image SOP instance. It identifies the frame numbers within the Referenced SOP Instance to which the reference applies. The first frame shall be denoted as frame number 1. This act class shall be used if the referenced DICOM SOP instance is a multi-frame image and the reference does not apply to all frames.

Table 5 Boundary ActClass

Attribute	Data Type	Multiplicity	Value
classCode	CS	1..1	OBS
moodCode	CS	1..1	EVN
code	CE	1..1	<Code Value (0008,0100) as code property, 1.2.840.10008.2.16.4 as codeSystem property, DCM as codeSystemName property, Code Meaning (0008,0104) as displayName property>: Proposal to define an appropriate DICOM code has been submitted
value	LIST<INT>	1..*	<Referenced Frame Number (0008,1160)> Identifies the frame numbers within the Referenced SOP Instance to which the reference applies. The first frame shall be denoted as frame number 1. Values shall be provided if the Referenced SOP Instance is a multi-frame image and the reference does not apply to all frames.

8.1 CDA Mapping (Class Name and Attributes used for CDA Documents)

• Act Clone Name: ObservationAct clone name of the CDA entry is "Observation" instead of "Boundary"

Message Element Types Used

None

Message Type List

A_DicomCompositeObjectReference minimal

COCT_MT830120UV05

Parent:

None

The A_DicomSequence minimal CMET is used to reference DICOM composite objects within HL7 Version 3 messages. It provides a single location for the identifying information of the study/series/instance hierarchical context of DICOM composite objects that are referenced for a specific purpose. Additional information on this context (e.g. Study Description) may optionally be added. Mappings from DICOM object attributes to the various Act attributes are provided. The CMETs for the HL7 V3 message sequence and the CDA Release 2 section are structurally identical. For the CDA section pattern different clone names are used according to the specified entry names of CDA Release 2.

Note: The A_DicomSequence minimal CMET may be used in combination with COCT_RM830120 to provide additional structured information on individual references to DICOM composite objects. COCT_RM830120 is used to put the references into the context of other acts and observations (e.g. relate referenced DICOM images to lab observations).

The following description of the act classes and act relationships contains the attribute mappings of HL7 V3 attributes to DICOM (Digital Imaging and Communications in Medicine) tags. The group and element number of the mapped DICOM tags are listed in parenthesis. The CDA mappings specify the use of the CMET act classes and act relationships for a CDA Release 2 document section which contains section entries.

1 Sequence

The DICOM Objects Sequence contains the identifying information on DICOM composite objects referenced in a HL7 V3 message for a specific purpose. The sequence can be used for any HL7 V3 message which includes references to composite DICOM objects, such as images and structured reports. Information on one or more referenced DICOM composite objects on the study, series and instance level can be included in a sequence.

Table 1 Sequence Act

Attribute	Data Type	Multiplicity	Value
classCode	CS	1..1	ACT
moodCode	CS	1..1	EVN
id	II	0..1	Sequence Identifier
code	CE	1..1	Externally defined DICOM codes, e.g. <121181 as code property, 1.2.840.10008.2.16.4 as codeSystem property, DCM as codeSystemName property, e.g. "DICOM Object Catalog" as displayName property>
title	ST	0..1	<e.g. "DICOM Object Catalog">

1.1 CDA Mapping (Class Name and Attributes used for CDA Documents)

Section (replaces Sequence)

The CDA DICOM Objects Section contains the identifying information on DICOM composite objects referenced in a CDA Release2 document for a specific purpose. The CDA DICOM Objects Section can be used within any CDA Release 2 document which includes references to composite DICOM objects in the structured part of the CDA document, such as images and structured reports. Information on one or more referenced DICOM composite objects on the study, series and instance level can be included in this section.

Table 2 Section Act

Attribute	Data Type	Multiplicity	Value
classCode	CS	1..1	ACT
moodCode	CS	1..1	EVN
id	II	0..1	Section Identifier
code	CE	1..1	Externally defined DICOM codes, e.g. <121181 as code property, 1.2.840.10008.2.16.4 as codeSystem property, DCM as codeSystemName property, e.g. "DICOM Object Catalog" as displayName property>
title	ST	0..1	<e.g. "DICOM Object Catalog">

DICOM Supplement 101:

Specifies the semantics of the section e.g. "DICOM Object Catalog" (DICOM Code Value: 121181) which contains information on the full set of DICOM composite objects referenced in the CDA document: "It is recommended that this list be transcoded to CDA Entries in a Section with Section.Title "DICOM Object Catalog" and a Section.Code of 121181 from the DICOM Controlled Terminology (see PS3.16)."

2 ActRelationship COMPONENT (Sequence to Study)

This actRelationship "COMPONENT" is used to link Sequence with one or more associated study acts.

2.1 CDA Mapping (ActRelationship Name and Attributes used for CDA Documents)

• ActRelationship Clone name: entry (replaces COMPONENT)
• ActRelationship.typeCode: x_ActRelationshipEntry (Constraint: Fixed value = COMP)
• ContextConductionInd: "true"

3 Study

The Study act class contains the DICOM study information that defines the characteristics of a referenced medical study performed on a patient. A study is a collection of one or more series of medical images, presentation states, SR documents, overlays and/or curves that are logically related for the purpose of diagnosing a patient. Each study is associated with exactly one patient. A study may include composite instances that are created by a single modality, multiple modalities or by multiple devices of the same modality. The study information is modality independent.

Table 3 DICOM Study Reference in an HL7 v3 Act

Attribute	Data Type	Multiplicity	Value
classCode	CS	1..1	ACT
moodCode	CS	1..1	EVN
id	II	1..1	<Study Instance UID (0020,000D) as root property with no extension property>: Unique identifier for the Study
code	CV	1..1	<113014 as code property, 1.2.840.10008.2.16.4 as codeSystem property, DCM as codeSystemName property, "DICOM Study" as displayName property>
text	ST	0..1	<Study Description (0008,1030)> Institution-generated description or classification of the Study (component) performed.
effectiveTime	TS	0..1	<Study Date (0008,0020): Date the Study started; and Study Time (0008,0030): Time the Study started.>

3.1 CDA Mapping (Class Name and Attributes used for CDA Documents)

• Act clone name of the CDA entry is "Act" instead of "Study". The attributes and attribute values of this CDA entry "Act" are identical to those listed in table 3.

4 ActRelationship COMPONENT (Study to Series)

This actRelationship "COMPONENT" is used to link one study act with one or more associated series acts.

4.1 CDA Mapping (ActRelationship Name and Attributes used for CDA Documents)

• ActRelationship Clone name: entryRelationship (replaces COMPONENT)
• ActRelationship.typeCode: x_ActRelationshipEntry (Constraint: Fixed value = COMP)
• ActRelationship.contextControlCode: "AP" (Additive Propagating)
• ContextConductionInd: "true"

5 Series

The Series act class contains the DICOM series information for referenced DICOM composite objects. The series information defines the attributes that are used to group composite instances into distinct logical sets. Each series is associated with exactly one study.

Table 4 DICOM Series Reference in an HL7 v3 Act

Attribute	Data Type	Multiplicity	Value
classCode	CS	1..1	ACT
moodCode	CS	1..1	EVN
id	II	1..1	<Series Instance UID (0020,000E) as root property with no extension property> ): Unique identifier of the Series.
code	CD	0..1	<113015 as code property, 1.2.840.10008.2.16.4 as codeSystem property, DCM as codeSystemName property, "DICOM Series" as displayName property, Modality as qualifier property (see text and Table 5)>
text	ST	0..1	<Series Description (0008,103E)> User provided description of the Series
effectiveTime	TS	0..1	<Series Date (0008,0021) : Date the Series started. and Series Time (0008,0031): Time the Series started.>

The code for the Act representing a Series uses a qualifier property to indicate the modality. The qualifier property is a list of coded name/value pairs. For this use, only a single list entry is used, as described in Table 5.

Table 5 Modality Qualifier for the Series Act.Code

Property	Data Type	Value
name	CV	<121139 as code property, 1.2.840.10008.2.16.4 as codeSystem property, DCM as codeSystemName property, "Modality" as displayName property>
value	CD	<Modality (0008,0060) as code property, 1.2.840.10008.2.16.4 as codeSystem property, DCM as codeSystemName property, Modality code meaning (from PS3.16) as displayName property>

5.1 CDA Mapping (Class Name and Attributes used for CDA Documents)

• Act Clone Name: Act
• Act clone name of the CDA entry is "Act" instead of "Series". The attributes and attribute values of this CDA entry "Act" are identical to those listed in table 4 and 5.

6 ActRelationship COMPONENT (Series to SopInstance)

This actRelationship "COMPONENT" is used to link one series act with one or more associated SopInstance acts.

6.1 CDA Mapping (ActRelationship Name and Attributes used for CDA Documents)

• ActRelationship Clone name: entryRelationship (replaces COMPONENT)
• ActRelationship.typeCode: x_ActRelationshipEntry (Constraint: Fixed value = COMP)
• ActRelationship.contextControlCode: "AP" (Additive Propagating)
• ContextConductionInd: "true"

7 SopInstance

Please refer to A_DicomCompositeObjectReference minimal CMETfor the description of the SopInstance act class.

Message Element Types Used

None

Message Type List

A_DicomSequence minimal

COCT_MT830110UV05

Parent:

Laboratory Observation (POLB_DM000000UV)

CMET NAME: A_Order_options

DOMAIN OVERVIEW The A_Order_options CMET is used to specify additional information specific to laboratory order. The information provided can be used by automation systems to specify additional configurable parameters related to the automated analysis of a specimen. This includes things like the endogenous content of a diluent; whether the instrument is given permission to repeat a test, with or without a specified dilution; perform an unordered test (reflex) based on results for something ordered.

FOCAL AREA STRUCTURE All of the characteristics described are observations and hence the entry point into the Order Options CMET is a choice among these observations.

REQUIRED ELEMENTS MANDATORY There are no mandatory elements beyond the structural elements required by the RIM. MUST SUPPORT All elements occurring in the Specimen CMET must be supported.

FOCAL CLASS CMET NAME: A_Order_options

Message Type List

A_OrderOptions universal

COCT_MT210000UV02

Parent:

Laboratory Observation (POLB_DM000000UV)

The A_LaboratoryProcessStep universal CMET is used to communicate where the laboratory is in the process of producing a test result.

Model Walkthrough

LabProcessStep: The LabProcessStep is an ACT that is used to document various parts of the Lab workflow associated with producing a laboratory result.

• classCode: The classCode for the LabProcessStep class is drawn from a value set which includes values such as ACSN (accession), CONTREG (container registration), PROC (procedure), SPECCOLLECT (specimen collection), SPCTRN (specimen treatment) and TRNS (transport).
• The mood of LabProcessStep is always EVN (event).
• id: The optional id attribute is used to carry one or more identifiers which uniquely identify this process step from all other process steps.
• code: The mandatory code attribute is used to further identify the specific process step this class is documenting.
• text: The optional text attribute is used to describe the process step.
• statusCode: The mandatory statusCode attribute is used to communicate the state of the process step. Complete would indicate the process step has been finished. Active would indicate the process step is still in progress, etc.
• effectiveTime: The optional effectiveTime attribute is used to indicate the time (or interval of time) that the process step was active.

LabProcessStep Participations:

Performer: The Performer participation is used only when the process step is a Specimen Collection process.

• typeCode: The Participation.typeCode has been restricted to PRF (performer).
• contextControlCode: The mandatory contextControlCode has been given a default value of "ON" indicating the context is overriding and non-propagating by default.

Collector: Performer associates the LabProcessStep with the Collector role. The Collector Role (as an assigned entity) is used to document at a high level what role is responsible for collecting a specimen. This class carries some of the functionality found in the 2.x Specimen Action Code (OBR.11).

• code: The mandatory code attribute is used to identify at a high level who is responsible for collecting a specimen. Types of values include "laboratory", "phlebotomist", "pathologist", etc.

Message Type List

A_LaboratoryProcessStep universal

COCT_MT570000UV09

Parent:

Laboratory Observation (POLB_DM000000UV)

The R_LabTestKit universal CMET universal is used to identify and characterize a test kit used to produce a test result.

Model Walkthrough

LabTestKit: The LabTestKit is a manufactured product role (RoleClassManufacturedProduct) that is used to identify the lab test kit. The role is played the manufactured material representing the test kit. The role is scoped by the organization manufacturing the test kit.

LabTestKit Associations:

manufacturerOrganization: The LabTestKit role is scoped by the manufacturerOrganization. The manufacturerOrganization is documented using the E_Organization universal CMET. There may be 0..1 manufacturerOrganizations. If TestKit.lotNumberText is present, then manufacturerOrganization is mandatory. The manufacturerOrganization is mandatory in this circumstance because lot numbers are unique only in conjunction with the code identifying the test kit and the manufacturer of the test kit.

manufacturedTestKit: The LabTestKit role is played by the manufacturedTestKit. The manufacturedTestKit is documented using a Manufactured Material (MMAT) Entity. There may be 0..1 manufacturedTestKits. If the LabTestKit.id is not present, then the manufacturedTestKit must be present in the CMET. This means the test kit must either be identified, or it must be described.

Common Message Element Types Used

E_OrganizationUniversal

COCT_MT150000UV02

Message Type List

R_LabTestKit universal

COCT_MT430000UV09

Parent:

Laboratory Observation (POLB_DM000000UV)

CMET NAME: Reagent

DOMAIN OVERVIEW The Reagent CMET provides information specific to the reagent used in the analysis of a specimen. It provides information that relates to the manufacturer of the reagent and more specific information such as the lot and expiration date of the reagent.

FOCAL AREA STRUCTURE The concept of the CMET is to associate the reagent with its manufacturer, expiration date and lot number.

REQUIRED ELEMENTS MANDATORY There are no mandatory elements beyond the structural elements required by the RIM. MUST SUPPORT All elements occurring in the Reagent CMET must be supported.

FOCAL CLASS

R_Reagent The focal class R_Reagent. The substance named by the id attribute plays the role of reagent.

Common Message Element Types Used

E_OrganizationUniversal

COCT_MT150000UV02

Message Type List

R_Reagent universal

COCT_MT250000UV03

Parent:

None

This is the entry point to the Medication Model for messages concerned with a medication supplied or administered to a patient . This may be an a medication or a packaged medicine.

Note: This model is a subset from the POME DMIM and a full walkthrough is desccribed there.

Common Message Element Types Used

R_BillableMedicationUniversal	COCT_MT220300UV
R_MedicationUniversal	COCT_MT230100UV

Message Type List

R_AdministerableMedication universal

COCT_MT220200UV

Parent:

None

This is the entry point to the Medication Model for messages concerned with identifying a medication supplied or administered to a patient from a billing perspective ..

Note: This model is a subset from the POME DMIM and a full walkthrough is desccribed there.

Common Message Element Types Used

A_ValuedItemIdentified

COCT_MT440001UV09

Message Type List

R_BillableMedication uiniversal

COCT_MT220300UV

Parent:

None

This is the entry point to the Medication Model for messages concerned with a medication rather than a packaged medicine.

Note: This model is a subset from the POME DMIM and a full walkthrough is desccribed there.

Common Message Element Types Used

A_ValuedItemIdentified

COCT_MT440001UV09

Message Type List

R_Medication universal

COCT_MT230100UV

Parent:

None

This is the entry point to the Medication Model for messages concerned with a medication ingredient.

Note: This model is now based on the Common Product Model DMIM.

Common Message Element Types Used

A_ValuedItemIdentified

COCT_MT440001UV09

Message Type List

R_MedicationIngredient universal

COCT_MT230200UV

Parent:

None

This is the entry point to the Medication Model for messages concerned with a order medication for a patient. This may be an ingredient, a medication or a packaged medicine.

Note: This model is a subset from the POME DMIM and a full walkthrough is desccribed there.

Common Message Element Types Used

R_BillableMedicationUniversal	COCT_MT220300UV
R_MedicationUniversal	COCT_MT230100UV
R_MedicationIngredientUniversal	COCT_MT230200UV

Message Type List

R_OrderableMedication

COCT_MT220100UV

Parent:

Medical Records (RCMR_DM000050UV)

A consent where one or more parties (the Consenters) agree to the subject as described in the A_Consent.text. The performer of the consent is considered the person who obtains the consent from the consenter(s). The consent CMET is usually linked to an Act that is the topic of the consent (for example, a surgical procedure, or another health care service). The link is made using an Act relationship from A_Consent to the Act being the topic of the consent, where the ActRelationship type is PERT (pertains-to) or a specialization thereof.

Common Message Element Types Used

R_ResponsiblePartyUniversal	COCT_MT040200UV09
R_AssignedEntityUniversal	COCT_MT090000UV01

Message Type List

A_Consent universal

COCT_MT470000UV

Parent:

Medical Records (RCMR_DM000050UV)

Usage Notes: This CMET conveys a Consent Directive that may authorize or prohibit one or more information transfers or "access" by recipients to perform system operations for specified purposed under certain conditions with certain obligations on types or instances of information artifacts over which the authoring party has control. The CMET may be sent in conjunction with the transmission of an information artifact, a query, a query response, and may reference the content of one or more prior Consent Directive instances in whole or part. In future ballots, CMET variants may be developed to reference a Consent Directive instance rather than convey details that a receiving system does not need to receive because it can directly access the consent directive details.

The Data Consent CMET captures the data and associations needed to (1) record or report a consumer's consent or dissent to authorize the collection, access, use, or disclosure of personally identifiable information; (2) convey a provider's request or intent to override a patient's recorded consent or dissent; (3) report a provider's actual override of a patient's recorded consent or dissent for audit purposes; (4) convey a type of consent directive associated with a privacy policy; or (5) to record or report a consumer's consent directive, which is to be applied to future access, collection, use or disclosure of personally identifiable information. This CMET may be attached to a message or used in association with the transmission of a clinical document to specify the consent directives of the subject of personal health information therein conveyed. Note that a consumer may or may not be a patient and the information to which the consent directive applies may or may not be health information. It must be personally identifiable information. For the purposes of this walk through, "consumer" means both an actual and a potential consumer of services such as healthcare.

The subject of a consumer's consent directive include specific instances or categories of information, including orders and results for lab, medications, diagnostic imaging; allergy and intolerance, medical condition, observations, demographics, immunizations, providers, and encounters. Note that categories of information may relate to a particular structuring of information, such medication lists or summary health record, or it may relate to groupings of value sets and particular classes and attributes that may be indicative of a category of information or from which a category of information may be inferred. As stated in the HL7 Reference Information Model at 3.1.1.14 Act.confidentialityCode: "Inference means that filtered sensitive information can still be assumed given the other information that was not filtered. The simplest form of inference is that even the existence of a test order for an HIV Western Blot test or a T4/T8 lymphocyte count is a strong indication for an existing HIV infection, even if the results are not known. Very often, diagnoses can be inferred from medication, such as Zidovudin for treatment of HIV infections."

The Attributes of the Focal Class ConsentDirective

The ConsentDirective classCode CONS: The act class consent refers in this context to consent related to the collection, access, use, or disclosure of a consumer's personally identifiable information. The type of consent is specified at a high level by the ActConsentType code. If the ConsentDirective type authorizes the transfer of one or more InformationArtifacts, then further detail is required to be conveyed if known such as the recipients of subject InformationArtifacts; operations permitted to be performed on those InformationArtifacts; the purposes for which an operation may be performed; the roles permitted to perform the operations, as well as any preconditions or resulting obligations. NOTE Constraint: If ActConsentType is INFA, then the PermissionToTransfer must be present. This is required regardless of whether the negationInd is null, true or false. In the case where consent to access is not granted, the PermissionToTransfer and its associated classes are used to specify the details of a masking directive.

The ConsentDirective moodCode x_ActMoodCompletionCriterion may be used (1) in the event mood EVN to indicate that a consumer has consented or dissented to authorize the collection, access, use, or disclosure of personally identifiable information; and to report a provider's actual override of a patient's recorded consent or dissent, which may be used for audit purposes; (2) in the intent INT or request RQO mood to convey a provider's intent or request to override a patient's recorded consent or dissent; (3) in the definition mood DEF to convey a type of consent directive associated with a privacy policy; or (4) in the criterion mood CRIT to record or report a consumer's consent directive, which is to be applied to future collection, access, use or disclosure of the consumer's personally identifiable information.

The ConsentDirective id II BUS_VER: A consent directive identifier is required to be sent if known. This uniquely identifies a consent directive or consent directive override instance as a business object and as a version of that business object as it exists at a given point in time. Note that this is a Release 2 Data Type that supports a scope attribute on the Instance Identifier. In the Data Types - Abstract Specification, Release 2 at 4.13.4, a Business Identifier is defined as: "An identifier that is associated with the object due to the business practices associated with the object. The scope of the use of the id may not be restricted to a single object, but may be reused for other objects closely associated with the object due to business practice." A Version Identifier is defined as: "An identifier that references a particular object as it existed at a given point in time. The identifier can be considered an identifier of a static snapshot of the object. The identifier changes with each state transition on the object. I.e. the version identifier of an object prior to a 'suspend' state transition is distinct from the identifier of the object after the state transition. Each version identifier can be tied to exactly one ControlAct event which brought that version into being (though the control act may never be instantiated). NOTE: Applications that do not support versioning of objects must ignore and not persist these ids to avoid confusion resulting from leaving the same identifier on an object that undergoes changes."

The ConsentDirective code ActConsentType: The type of consent being granted, refused, revoked, or overridden shall be specified by a code from the ActConsentType concept domain, e.g., consent to collect, access, use, or disclose, e.g., for research.

The ConsentDirective negationInd with default set to "false": The presence of the negation indicator set to "false" indicates that the consumer consents to grant the permission indicated by the ActConsentType. A negation indicator is set to "true" indicates a consumer's dissent. If a consumer had previously consented to access, that permission may be revoked by sending a second Data Consent message/CMET with the same Consent Directive, as indicated by an identical consent directive Business Identifier and a new Version Identifier, and setting the negationInd to "true". Note that the negationInd must either be non-null or not sent, the later case may be an indication that the consumer's consent was deemed or implied, i.e., the consumer did not have or is not provided an opportunity to actively consent or dissent to any or all permissions relating to collection, access, use, and disclosure of personally identifiable information. NOTE Constraint: If the negationInd is "false", then the PermissionToInform is mandatory.

The ConsentDirective statusCode: A statusCode from the specializable ActStatusNormal concept domain must be sent.

The ConsentDirective effectiveTime: The Consent effective and end time is required to be sent if known.

The ConsentDirective reasonCode: If a provider or other authorized assigned entity is participating in the ConsentDirective as author1, then a code from the ActConsentInformationAccessOverrideReason concept domain must be sent if known to indicate the provider's reason for overriding a patient's consent directive. Otherwise, the ActConsentInformationAccessOverrideReason must not be used. Note that this is a constraint.

The ConsentDirective shall be linked with the subject participation typeCode SBJ to the choice of either the R_ResponsibleParty (universal) or R_Patient (universal) CMET indicating that one and only one consumer or patient shall be the subject of the ConsentDirective.

The subject participation contextControlCode OP indicates that any party participating as a subject in the ConsentDirective overrides all subjects from any ancestral subject participations and propagate to all descendant acts reached by conducting ActRelationships.

NOTE Constraints: The ConsentDirective must be linked by an AUT participation to one and only one type of authoring role, either "author2" the consenter role, which may be the patient and/or one or more responsible parties; or "author1", which may be zero to one assigned entity. If author1 then there must be a responsibleParty who is ultimately responsible for author1.

The author2 participation typeCode AUT is required to link the ConsentDirective to zero to many consenting party, which may be either a Patient of roleClassPAT who is the same person entity referenced in the R_Patient CMET; or a consumer or one or more delegates of a consumer or patient as represented by the R_ResponsibleParty CMET. Note that the R_ResponsibleParty is used here rather than the more constrained R_AssignedParty, because the former does not specify the type of scoping organization, if any, while the latter may only be scoped by an organization, thereby implying that an organization is to some extent accountable for the functions undertaken by a player of an AssignedParty role.

The author2 participation functionCode may be sent using codes from the ConsenterParticipationFunction concept domain to indicate the function served by the a R_ResponsibleParty participation in the authoring of a consent directive, e.g., as a legal guardian or a representative with powers of attorney.

The mandatory author2 participation contextControlCode OP indicates that any consenting party participating as an author in the ConsentDirective overrides all authors from any ancestral author participations and propagate to all descendant acts reached by conducting ActRelationships.

The author2 participation time must be sent to indicate the time at which the consenting party authored the consent directive.

The author2 participation modeCode must be sent if available to indicate the modality by which the consenter participated in authoring the consent directive, using codes from the ParticipationMode domain to specifies whether the consent was provided e.g., in person, over the telephone; or verbally, electronically, or on paper .

The author2 participation signatureCode must be sent if available to specify whether and how the participant has attested to his or her participation through a signature.

The author2 participation signatureText may be sent used to send a textual or multimedia depiction of the signature by which the participant endorses his or her participation in the Act as the author, and that he or she agrees to assume the associated accountability.

The author1 participation typeCode AUT is required to link the ConsentDirective to zero or one assignedEntity, which is conveyed by the R_AssignedEntity (universal) CMET.

The author1 participation functionCode may be sent using codes from the OverrideParticipationFunction concept domain to indicate the function served by the a R_AssignedParty in the authoring of a consent directive override, e.g., as an authorized clerical staff charged with creating a default consent directive or updating an existing consent directive based on changed privacy policy; a resident authoring an override for a a responsible party to mask information from the consumer; or a provider that is authorized to "break the glass" to access critical health information.

The mandatory author1 participation contextControlCode OP indicates that any assigned entity participating as an author in the ConsentDirective overrides all authors from any ancestral author participations and propagate to all descendant acts reached by conducting ActRelationships.

The author1 participation time may be sent to indicate the time at which the AssignedEntity authored the consent directive override.

The author1 participation signatureCode must be sent if available to specify whether and how the participant has attested to his or her participation through a signature.

The author1 participation signatureText may be sent used to send a textual or multimedia depiction of the signature by which the participant endorses his or her participation in the Act as specified an author, and that he or she agrees to assume the associated accountability.

The responsibleParty typeCode RESP is required to link the ConsentDirective to zero or one assignedEntity, which is conveyed by the R_AssignedEntity (universal) CMET.

The ConsentDirective may have a predecessor relationship typeCode SUCC as the source act to zero to many PriorConsentDirective(s) target acts in circumstances where one or more prior consent directive types such as a notice of privacy practices, an opt-in to collection, a restriction on disclosure for non-treatment purposes, and a delegation to a healthcare representative, typically a paper or online form is replaced or succeeded by the focal coded ConsentDirective that is substantially equivalent to and fully specifies the content expressed by one or more PriorConsentDirectives types.

The ConsentDirective may have a reference relationship typeCode REFR as a source act of zero to many PriorConsentDirective(s) target acts in circumstances where the prior consent directive artifacts are captured and maintained in hard-copy as validation of the focal coded ConsentDirective especially in circumstances where the healthcare consumer's digital signature may not be legally accepted or technically supported for purposes of attestation of the ConsentDirective.

Attributes of PriorConsentDirective: One or more consent directives may be predecessors of the focal consent directive. A predecessor consent directives may be captured as an Xform; an electronic text image; or hard copy unstructured text . If a hard-copy consent directive is used as evidence of the consenter's attestation to the focal ConsentDirective, e.g., in situations where legally, a signature is required but digital signatures is not technically supported or not legally binding, then attaching a scanned consent directive or text image file with a wet signature may satisfy the business requirement.

The PriorConsentDirective classCode: This class has an act type of CONS or "consent", which is the legal transaction between a healthcare consumer and an actual or potential custodian of the consumer's information conveying grants or denials of permission to collect, access, use or disclose this information.

The PriorConsentDirective moodCode: The mood of this act is event EVN, indicating that the prior consent directive has occurred or is in the process of occurring.

The PriorConsentDirective id: A set of zero to many identifiers is required to be sent if known to identify a prior consent directive.

The PriorConsentDirective code ActConsentDirectiveType may be used to convey the type of prior consent directive types that may be singly or combined into the focal fully specified, structured Consent Directive, e.g. a notice of privacy practices, an opt-in to collection, a restriction on disclosure for non-treatment purposes, of a delegation to a healthcare representative. NOTE: This ActCode was approved during the Fall 2007 Harmonization Meeting, and is defined as the type of consent directive indicated by an ActClassPolicy e.g., a 3rd party authorization to disclose or a consent for a substitute decision maker (SDM) or a notice of privacy policy. It is a sibling to ActPrivacyPolicyType and a child of ActPolicyType.

The PriorConsentDirective text of type ED: A PriorConsentDirective text image may be attached. Where a consent directive is substantially equivalent predecessor of the focal consent directive, and the prior consent directive is used as evidence of the consenter's attestation to the focal ConsentDirective, e.g., in situations where legally, a signature is required but digital signatures is not technically supported or not legally binding, then attaching e.g., a scanned consent directive with a wet signature and/or referencing the PriorConsentDirective identifier may be legally sufficient proof of attestation as long as the association to the signed directive is maintained.

The PriorConsentDirective statusCode: A statusCode with the default of "complete" may be sent.

The PriorConsentDirective effectiveTime: The Consent effective and end time must be sent if known. This is of importance where the signature on the PriorConsentDirective is the legal basis for attestation of the focal ConsentDirective.

The PriorConsentDirective languageCode HumanLanguage: The language used in the PriorConsentDirective may be sent.

The ConsentDirective may have a reference relationship typeCode COMPLY to the PrivacyPolicy meaning that the source act, the focal ConsentDirective complies with, adheres to, conforms to, or is permissible under (in whole or in part) the policy, contract, agreement, law, conformance criteria, certification guidelines or requirement conveyed by the PrivacyPolicy as the target act. NOTE: This ActRelationshipType was approved during the Fall 2007 Harmonization meeting, and means that the source act complies with, adheres to, conforms to, or is permissible under the target act, either in whole or in part. Example act types include policies, contracts, agreements, laws, conformance criteria, certification guidelines, and requirements.

Attributes of PrivacyPolicy

The PrivacyPolicy classCode: This class has an act type of POLICY, which is defined as a mandate, regulation, obligation, requirement, rule, or expectation unilaterally imposed by one party on the activity or behavior of another party, or on the manner in which an act is executed. In this context, the policy relates to a jurisdictional or organizational policy relating to the healthcare consumer's right of privacy in personal information and any confidentiality requirements related to its use.

The PrivacyPolicy moodCode: The mood of this act is permission EVN, indicating that the PrivacyPolicy is or has been in effect.

The PrivacyPolicy id: A set of zero to many identifiers is required be used to identify this policy if known.

The PrivacyPolicy code is required be specified if known from the ActPrivacyPolicyType concept domain to identify the type of privacy policy governing the ConsentDirective, e.g., privacy policy about the consent requirements for disclosure of health information related to treatment in a substance abuse program. NOTE: This ActCode was approved during the Fall 2007 Harmonization Meeting, and is defined as the type of privacy policy indicated by an ActClassPolicy, e.g., privacy policy about the consent requirements for disclosure of health information related to treatment in a substance abuse program covered by 42 CFR Part 2. It is a sibling to ActConsentDirectiveType.

The ConsentDirective may have an authorization relationship typeCode AUTH of zero to many PermissionToTransfer acts.

The authorization relationship is required have one contextControlCode set to ON to indicate that the author may override but not propagate authorship to the child Acts, i.e., if author1 overrides a consent directive with certain permissions, then the overriding author does not author those permissions.

The authorization relationship contextConductionInd is set to true to indicate that the context marked as conducting will conducts to child acts.

Attributes of PermissionToTransfer

The PermissionToTransfer classCode: This class has an act type of TRFR or "transfer", which is defined as "The act of transferring or providing access to information about a topic to a subject."

The PermissionToTransfer moodCode: The mood of this act is permission PERM, indicating that informing recipients about the subject act is authorized by the ConsentDirective author.

The PermissionToTransfer id: A set of zero to many identifiers may be used to identify this act.

The PermissionToTransfer code may be specified from the ActInformationTransferCode concept domain to provide information about the protocols by which the information transfer is permitted, e.g., in accordance with legal or regulatory requirements. NOTE: This ActCode was approved during the Fall 2007 Harmonization Meeting.

The receiver participation typeCode RCV is required to link the PermissionToTransfer to zero or more recipients being granted permission, which may be either an assigned person conveyed by the R_AssignedPerson (universal) CMET or a service delivery location conveyed by the R_ServiceDeliveryLocation (universal) CMET.

The receiver participation contextControlCode OP indicates that any recipients receiving permission to be informed override all recipients from any ancestral receiver participation and propagate to all descendant acts reached by conducting ActRelationships.

The receiver participation participationFunction may be sent using codes from the AuthorizedReceiverParticipationFunction concept domain to indicate the receiver functions of the R_AssignedEntity or the R_ServiceDeliveryLocation roles, such as information custodian, care team, or work area.

The PermissionToTransfer shall have as subjects one or more InformationArtifact(s) via the subject relationship typeCode SUBJ. The contextControlCode ON indicates that the permitted release of information applies only to the target InformationArtifact and overrides any propagating ancestor acts to which it is subject, e.g., a previous refusal to permit release of information, but will not propagate further. The contextConductInd is a Boolean set to 'false' meaning that the target InformationArtifact may not have the PermissionToTransfer as a subject where the author is not granting consent to collect, access, use, or disclose subject information.

Attributes of InformationArtifact

The InformationArtifact classCode ACT: This act type indicates that any act in definition or event mood ActMoodDefEvn may be the subject of an information transfer, e.g., an act that may meet the definition or any act instance.

The InformationArtifact id: A set of zero to many identifiers may be used to identify this InformationArtifact.

The InformationArtifact code shall be specified with a code from the ActInformationAccessCode concept domain to provide more precise description of the type of information within the InformationArtifact that is the subject of the permitted disclosure. The ActInformationAccessCode is defined as the type of personal health information to which the subject of the information or the subject's delegate consents or dissents to authorize access. Examples of the type of information include: allergy, adverse drug, demographic, immunization, lab results, mediation, medical condition, observations, policy or program, provider, or services.

The InformationArtifact may reference zero to many InformationArtifactChoice via the reference relationship typeCode REFR to permit the InformationArtifact to reference the A_Coverage (universal) CMET, which may convey demographic and coverage information; the A_Appointment CMET, which may convey information related to an appointment scheduling healthcare services; the A_Billable CMET (universal), which may convey encounter information including diagnoses, procedures, service locations, and providers; the A_SupportingClinicalStatement (universal), which may convey any type of clinical encounter or healthcare services in great detail; and the A_Transportation CMET, which may convey confidential information about transportation for health services, including locations.

The PermissionToTransfer is required to have a component relationship typeCode COMP of zero to many ConsentPermission acts.

Attributes of ConsentPermisson

The ConsentPermission classCode: This class has an act type of CACT or "control act", which is defined as: "An act representing a system action such as the change of state of another act or the initiation of a query. All control acts represent trigger events in the HL7 context. ControlActs may occur in different moods.

The ConsentPermission moodCode: The mood of this act is permission PERM, indicating that specified acts or operations on one or more information artifacts, which are the subject of the PermissionToTransfer are permitted.

The ConsentPermission id A set of zero to many identifiers may be used to identify this act.

The ConsentPermission code must be specified from the HL7TriggerEventCode concept domain to indicate the available trigger events used in the release of HL7 identified by the versionCode that are permitted acts or operations.

The ConsentPermission reasonCode may be specified from the PatientProfileQueryReasonCode concept domain to indicate the purposes for which permission to perform the acts or operations indicated by the HL7TriggerEventCode is granted, e.g., for treatment, payment, operations, disclosure to third parties, marketing, public health surveillance or reporting, or research.

The ConsentPermission may have a precondition relationship typeCode PRCN of zero to many ConsentPermissionCondition acts.

The precondition sequenceNumber indicates the relative order in which the associated ConsentPermissionCondition is considered and may associate enumerated condition(s) with one or more ConsentPermissionObligations with the same sequence number to indicate that if the condition for the ConsentPermission is met, the associated ConsentPermissionObligation is a required post condition.

The precondition checkpointCode indicates when in the course of a permitted 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).

The precondition conjunctionCode specifies the logical conjunction of the criteria among all the precondition-links of permitted acts (e.g., and, or, exclusive-or).

Attributes of ConsentPermissonCondition

The ConsentPermissionCondition classCode: This class has an act type of COND or "condition": An observable finding or state that persists over time and tends to require intervention or management, and, therefore, distinguished from an Observation made at a point in time; may exist before an Observation of the Condition is made or after interventions to manage the Condition are undertaken.

The ConsentPermissionCondition moodCode: The mood of this act is permission CRT, indicating a condition criterion that must obtain in order for an act or operation is permitted to be performed on an information artifact.

The ConsentPermissionCondition id: A set of zero to many identifiers may be used to identify a condition, which may be used when evaluating the status of one or more conditions.

The ConsentPermissionCondition code must be specified from the ActPrivilegeCategorizationType concept domain to indicate the observations used to characterize a privilege, under which this additional permission condition information is classified. Examples include security or privacy policy requirements, e.g., the manner, time, and location in which an act or operation is permitted on an information artifact.

The ConsentPermissionCondition statusCode indicates the state of the act, e.g., active vs. completed.

The ConsentPermissionCondition negationInd indicates whether the negation of the specified condition is required for the act or operation to be permitted.

The ConsentPermissionCondition effectiveTime indicates the focal or operative time of the condition necessary for the permitted act or operation.

The ConsentPermissionCondition value indicates the condition value assigned to the ActPrivilegeCategorizationType.

The ConsentPermission may have a precondition relationship typeCode TRIG of zero to many ConsentPermissionObligation acts in criterion mood indicating that the ConsentPermission triggers a ConsentPermissionObligation as a post-condition.

The trigger sequenceNumber indicates the relative order in which the associated ConsentPermissionObligation is considered and may associate enumerated obligation(s) with one or more ConsentPermissionConditions with the same sequence number to indicate that if the condition(s) for the ConsentPermission is met, the associated ConsentPermissionObligation is a required post condition.

The trigger splitCode indicates how multiple ConsentPermissionObligations with the same sequence numbers are to be evaluated exclusively or inclusively.

The trigger conjunctionCodespecifies the logical conjunction of the criteria among all the post-conditions of permitted acts (e.g., and, or, exclusive-or).

Attributes of ConsentPermissonObligation

The ConsentPermissionObligation classCode: This class has an act type of POLICY or "policy", which is an obligation under a privacy or security policy that is triggered by the permitted act or operation on an information artifact. For example, a typical security policy is the obligation to log and audit an operation performed on a protected information artifact

The ConsentPermissionObligation moodCode: The mood of this act is permission CRT, indicating an obligation that is the required post-condition of a permitted act or operation.

The ConsentPermissionObligation id: A set of zero to many identifiers may be used to identify this obligation, which may be used when evaluating the status of one or more obligations.

The ConsentPermissionObligation code must be specified from the ActPolicyType concept domain to further specify an obligation that results from a permitted act or operation on an information artifact, e.g., the obligation to log and audit.

The ConsentPermissionObligation effectiveTime indicates the focal or operative time of the obligation necessary for the permitted act or operation.

The ConsentPermissionObligation activityTime specifies the time in which the obligation is ordered or scheduled to happen as a post-condition for the permitted act or operation.

The ConsentPermission shall be linked with the performer participation typeCode PRF to the OperationPerformer role indicating that one to many performers shall perform the act or operation condoned by the ConsentPermission.

The mandatory performer participation contextControlCode ON indicates that any role participating as performing operator in the ConsentPermission overrides all roles from any ancestral participations but does not propagate to all descendant acts reached by conducting ActRelationships. That is, the operation performer does not have an authoring relationship to the consent authorizing the transfer of specified information, but is not the same role as the authoring role. However, the entities playing these roles could be the same, e.g., the representative of the healthcare consumer may be the performer of an operation, the permission for which was granted by the consumer to the consumer as a recipient of the transferred information, e.g., query the consumer's health information. This requirement is further specified by the following constraint: The OperationPerformer identifier must match a recipient identifier on its parent PermissionToTransfer.

Common Message Element Types Used

A_AppointmentUniversal	COCT_MT020000UV01
R_ResponsibleUniversal	COCT_MT040000UV09
R_ResponsiblePartyUniversal	COCT_MT040200UV09
R_PatientUniversal	COCT_MT050000UV01
A_TransportationUniversal	COCT_MT060000UV01
R_AssignedEntityUniversal	COCT_MT090000UV01
R_AssignedEntityUniversal	COCT_MT090000UV01
R_ServiceDeliveryLocationUniversal	COCT_MT240000UV01
A_BillableUniversal	COCT_MT280000UV04
A_CoverageUniversal	COCT_MT510000UV06
A_SupportingClinicalStatementUniversal	COCT_MT530000UV

Message Type List

A_DataConsent universal

COCT_MT580000UV07

Parent:

None

Observation General CMET

A general observation represents the fact that the Lab Observation DMIM also serves to represent a wide variety of relatively unspecialized observations. All the participations general observation are addressed within the Laboratory Domain Message Information Model (DMIM) Act Relationships

There is a single act relationship that is not addressed within the Laboratory DMIM. Reference Range

An observation event is associated with zero to many observation event criteria. These are acts that contain additional information that provides context for the data passed in observation event value. Typical reference ranges indicate the normal high and low values of an observation for a particular population. The reader should note that the particular criteria for a specific reference range are captured as an associated observation.

Common Message Element Types Used

R_AssignedEntityUniversal

COCT_MT090000UV01

Message Type List

A_ObservationGeneral universal

COCT_MT120500UV

Parent:

None

Observation Intolerance CMET

An observation intolerance (AKA allergy) provides the attributes and associations needed for the specification of an intolerance or allergy. An allergy is a hypersensitive state acquired through exposure to a particular allergen. Those participations and act relationship that are valid for intolerances, and that are not addressed in the Laboratory Observation Domain Message Information Model are described below. Participations

There are no participations that are specific to an intolerance Act Relationships

The following associations have particular relevance for an intolerance. Adverse Reaction:

An intolerance can be associated with zero to many adverse reactions. For the most part, intolerances are discovered and confirmed through the observation of an adverse reaction. However, an intolerance may be reported without providing specific information on related adverse reactions. At the same time, an allergic person may experience many reactions as a result of multiple exposures. Severity:

It is relevant, though not mandatory or universal to record the severity of a person's adverse reaction. Each severity observation is related to a single adverse reaction. Note, however, that it is possible to record the severity of allergic reactions without specific documentation of the adverse reaction itself.

Common Message Element Types Used

R_AssignedEntityUniversal

COCT_MT090000UV01

Message Type List

A_ObservationIntolerence universal

COCT_MT120300UV

Parent:

None

Observation Supporting Information CMET

Observation supporting information provides the ability to include relevant supporting information for an observation. This CMET allows information related to a variety of act types to be associated with an observation. Currently, it is expected that supporting information will constitute one of the following: an instance of medication administration or the intent to administer medication, an observation intolerance or allergy, a procedure or the intent to perform a procedure, a diagnosis, or a general (generic) observation.

In the case of medications and procedures, it is assumed that now participation or additional act relationship information will be included. The reader should refer to the relevant CMET discussions for information on participations and act relationships for intolerances, diagnoses, and/or general observations.

Common Message Element Types Used

A_ObservationDxUniversal	COCT_MT120100UV
A_ObservationIntoleranceUniversal	COCT_MT120300UV
A_ObservationGeneralUniversal	COCT_MT120500UV

Message Type List

A_SupportingClinicalInfo universal

COCT_MT200000UV01

Parent:

None

Annotation CMET

Text-based comments made about a record, patient, or other object to which this CMET is attached. Provides for greater documentation and communication. All the participations for this CMET are addressed within the Observations Domain Message Information Model (DMIM) Walkthrough

Common Message Element Types Used

R_AssignedEntityUniversal

COCT_MT090000UV01

Message Type List

A_annotation Universal

COCT_MT590000UV

Parent:

None

This is the minimal variant of A_ObservationDx universal

Overview

A diagnosis is an observation that represents the determination of the nature of a case of disease. The diagnosis code is captured as the value of the observation, while act code indicates the type of diagnosis, e.g., admitting, billing. All the participations relevant to a diagnosis are addressed in the discussion of the Laboratory Domain Message Information Model. There are not specific act relationships.

Common Message Element Types Used

R_AssignedEntityIdentified

COCT_MT090001UV01

Message Type List

A_ObservationDx minimal

COCT_MT120104UV

Parent:

None

This is the universal variant of the A_ObservationDx CMET.

Overview

A diagnosis is an observation that represents the determination of the nature of a case of disease. The diagnosis code is captured as the value of the observation, while act code indicates the type of diagnosis, e.g., admitting, billing. All the participations relevant to a diagnosis are addressed in the discussion of the Laboratory Domain Message Information Model. There are not specific act relationships.

Common Message Element Types Used

R_AssignedEntityUniversal

COCT_MT090000UV01

Message Type List

A_ObservationDx universal

COCT_MT120100UV

Parent:

Patient Administration (PRPA_DM000000UV)

This is the identified variant of A_Encounter universal. This CMET supports the use case of closely coupled systems where the receiver only needs the patient encounter's identifier.

Encounter -- An interaction between a patient and care provider(s) for the purpose of providing healthcare-related services. Healthcare services include health assessment.

• id - one or more unique identifiers for this encounter (mandatory)
• code - type of encounter (such as ambulatory, inpatient, emergency, home health)
• effectiveTime - the time interval starting with the administrative onset of the encounter (e.g. admission, registration, patient arrival) and ending with the patient's departure (e.g. discharge). For active encounters the end of the effectiveTime range is the anticipated end date-time.

Message Type List

A_Encounter identified

COCT_MT010001UV01

Parent:

Patient Administration (PRPA_DM000000UV)

This is the minimal variant of A_Encounter universal.

The encounter is described by type (e.g., ambulatory, inpatient), identifier(s), status, and effective time. The included participations are attending practitioner(s), assigned patient location(s), relevant account(s), and the patient. No act relationships are included.

Common Message Element Types Used

R_PatientIdentified/confirmable	COCT_MT050002UV07
R_AssignedPersonIdentified/confirmable	COCT_MT090102UV02
A_AccountIdentified	COCT_MT110001UV01
R_ServiceDeliveryLocationIdentified/confirmable	COCT_MT240002UV02

Message Type List

A_Encounter minimal

COCT_MT010004UV02