|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| 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.
| A_DetectedMedicationIssueNoText | COCT_MT260003UV |
| 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.
| A_BillableClinicalServiceUniversal | COCT_MT290000UV06 |
| A_BillablePharmacyDispenseUniversal | COCT_MT300000UV04 |
| A_BillablePreferredAccomodationUniversal | COCT_MT310000UV04 |
| A_BillableClinicalProductUniversal | COCT_MT490000UV04 |
| A_BillableVisionDispenseUniversal | COCT_MT600000UV06 |
| A_BillableOralHealthServiceUniversal | COCT_MT740000UV04 |
| 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
| R_PatientUniversal | COCT_MT050000UV01 |
| R_ServiceDeliveryLocationContact | COCT_MT240003UV02 |
| 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
| R_ServiceDeliveryLocationContact | COCT_MT240003UV02 |
| 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
| R_PatientUniversal | COCT_MT050000UV01 |
| R_ServiceDeliveryLocationContact | COCT_MT240003UV02 |
| 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.
| R_ServiceDeliveryLocationContact | COCT_MT240003UV02 |
| 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.
| R_ServiceDeliveryLocationContact | COCT_MT240003UV02 |
| R_ServiceDeliveryLocationContact | COCT_MT240003UV02 |
| R_ServiceDeliveryLocationContact | COCT_MT240003UV02 |
| A_DetectedMedicationIssueNoText | COCT_MT260003UV |
| 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.
| R_ServiceDeliveryLocationContact | COCT_MT240003UV02 |
| R_ServiceDeliveryLocationContact | COCT_MT240003UV02 |
| R_ServiceDeliveryLocationContact | COCT_MT240003UV02 |
| A_DetectedMedicationIssueNoText | COCT_MT260003UV |
| 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.
| R_ServiceDeliveryLocationContact | COCT_MT240003UV02 |
| 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.
| E_PersonUniversal | COCT_MT030200UV09 |
| E_OrganizationUniversal | COCT_MT150000UV02 |
| R_ServiceDeliveryLocationContact | COCT_MT240003UV02 |
| E_PlaceUniversal | COCT_MT710000UV07 |
| A_SpatialCoordinateUniversal | COCT_MT960000UV05 |
| 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.
| R_ServiceDeliveryLocationUniversal | COCT_MT240000UV01 |
| R_ServiceDeliveryLocationContact | COCT_MT240003UV02 |
| R_ServiceDeliveryLocationContact | COCT_MT240003UV02 |
| 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).
| A_OralHealthObservationUniversal | COCT_MT760000UV04 |
| 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
| 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 |
| 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
| E_LivingSubjectInformational | COCT_MT030007UV |
| 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
| 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
| E_LivingSubjectInformational | COCT_MT030007UV |
| 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
| E_LivingSubjectInformational | COCT_MT030007UV |
| 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).
| 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.
| 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 |
| 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.
| A_AccountPayorUniversal | COCT_MT110100UV04 |
| A_AccountPayeeUniversal | COCT_MT110200UV04 |
| 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).
| 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).
| A_BillableUniversal | COCT_MT280000UV04 |
| 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).
| A_BillableUniversal | COCT_MT280000UV04 |
| 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.
| R_ServiceDeliveryLocationContact | COCT_MT240003UV02 |
| R_ServiceDeliveryLocationContact | COCT_MT240003UV02 |
| R_ServiceDeliveryLocationContact | COCT_MT240003UV02 |
| 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.
| R_PatientUniversal | COCT_MT050000UV01 |
| R_ServiceDeliveryLocationContact | COCT_MT240003UV02 |
| A_SpatialCoordinateUniversal | COCT_MT960000UV05 |
| 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).
| 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.
| R_Guarantor universal | COCT_MT670000UV04 | |
| Return to top of page |