|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
| Parent: | None |
The Account CMET is used to identify account information.
This is the identified variant of A_Account universal
| A_Account identified | COCT_MT110001UV01 |  |
| Parent: | None |
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.
| A_Account universal | COCT_MT110000UV04 | |
| Parent: | None |
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.
| A_AccountGuarantor universal | COCT_MT110300UV04 | |
| Parent: | None |
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.
| A_AccountPayee basic | COCT_MT110202UV04 | |
| Parent: | None |
Note: This CMET will appear in the HL7 V3 2006 Normative Edition.
This is the identified variant of A_AccountPayee universal
| A_AccountPayee identified | COCT_MT110201UV04 | |
| Parent: | None |
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.
| A_AccountPayee universal | COCT_MT110200UV04 | |
| Parent: | None |
Note: This CMET will appear in the HL7 V3 2006 Normative Edition.
This is the contact variant of A_AccountPayor universal.
| A_AccountPayor contact | COCT_MT110102UV04 | |
| Parent: | None |
Note: This CMET will appear in the HL7 V3 2006 Normative Edition.
This is the identified variant of A_AccountPayor universal
| A_AccountPayor identified | COCT_MT110101UV04 | |
| Parent: | None |
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.
| A_AccountPayor universal | COCT_MT110100UV04 | |
| Parent: | None |
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.
| A_EncounterUniversal | COCT_MT010000UV01 |
| A_TransportationUniversal | COCT_MT060000UV01 |
| A_BillableUniversal | COCT_MT280000UV04 |
| A_CoverageUniversal | COCT_MT510000UV06 |
| A_SupportingClinicalStatementUniversal | COCT_MT530000UV |
| A_Charge universal | COCT_MT400000UV07 | |
| Parent: | None |
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.
| A_EncounterUniversal | COCT_MT010000UV01 |
| A_TransportationUniversal | COCT_MT060000UV01 |
| A_BillableUniversal | COCT_MT280000UV04 |
| A_CoverageUniversal | COCT_MT510000UV06 |
| A_SupportingClinicalStatementUniversal | COCT_MT530000UV |
| A_CompositeCharge universal | COCT_MT400100UV07 | |
| Parent: | Trigger Event Control Act Infrastructure (MCAI_DM700200UV) |
A Common Message Element Type (CMET) used to refer to the detected issues in the trigger event control acts. It will not be utilized by itself, but as a reusable model artifact.
NOTE: This CMET was originally published as a "local" CMET in the Control Act Infrastructure domain. It is being reintroduved here, with a common identifier, to supoport its use by other domains.
| A_DetectedIssue | COCT_MT900000UV | |
| Parent: | Clinical Genomics (POCG_DM000020UV) |
Model walk-through
The Genetic Variation model described here specifies the structure and semantics for the transmission of information created during single or multiple gene testing and analysis of a single subject with chromosomal based DNA. This model is not meant to be a biological model; rather it is aimed at the needs of healthcare with the vision of personalized medicine in mind. It also facilitates genetic analysis within clinical research conducted within the healthcare enterprises. Human medical patients, human clinical research subjects, animal clinical research subjects and animal medical patients can all have genetic test results transmitted in an HL7 message that uses the Genetic Variation model as its payload. This CMET is a constrained version of the Genetic Variation model targeted to be used as a result payload plugged into other fully functional HL7 V3 messages used in genetic diagnostic testing and clinical research trials.
Genetic Variation Scope and ModularityThe model presented in this ballot is further constrained to genetic variation analyses based upon sequence variation and derived from a set of scientific laboratory methods (such as SNP probes, sequencing and genotype chip arrays) that focus on small scale genetic changes, usually in the coding region(s) of one or a small number of genes. Gene expression analysis, Non-DNA based methods and viral genotyping are not suitable for the Genetic Variation model and are (or will be) addressed by different models within the HL7 Clinical Genomics Work Group.
The model presented here is based upon use of predecessor DTSU R-MIMs (GeneticLocus - POCG_MT000010 and GeneticLoci - POCG_MT000050) as well as respective CMETs that have now been combined into this one, unified CMET. During the Draft Standard for Trial Use (DSTU) period of those predecessor models, various members of the HL7 Clinical Genomics Work Group worked with data derived from Sequence, Probe and Genotype Chip methods of single subject genetic analysis. These use cases derive from genetic testing messaging within the clinical practice and the clinical research areas, and the input from both environments is consolidated to provide one unified, interoperable view of the now unified Genetic Variation R-MIM.Main Model Characteristics
- The core genomic observation are listed as choices in a large choice box titled "Genomic Statement". The classes in this choice box can be associated with each other through specific associations described below. The motivation to organize the core genomic observations in a choice box is to allow common structures to be associated with all classes in the choice box without needing to repeat those structures for each class. For example, associations to phenotype, associated properties, associated observations, annotations, control acts, etc.
- The entry point to this model is a GeneticLoci act which represents the ordered "test" or planned "assay", whether that involves a single gene/genetic locus or multiple genes/genetic loci.
- The Genetic Locus specifies each gene or locus involved in the analysis, and the locus can be associated with a pair of alleles on paternal and maternal homologous chromosomes.
- Core observations associated directly with the allele are Sequence, and Sequence Variation. These core classes are also the ones which encapsulate raw genetic data (although it's possible to encapsulate raw data within GeneticLoci, e.g., SNP genotyping results). Reference values should be specified in definitional mood ("DEF"), while observed values are specified in event mood ("EVN").
- Alternatively, sequence and sequence variation data could be associated directly with the Genetic Locus observation if data is not available at the allelic level of granularity.
- In addition to the core classes, the Phenotype CMET is provided as a model associated with all core classes, to allow for complex interpretations that can not fit within each class's interpretation code.
- All core classes can be associated with two generic classes: AssociatedProperty and AssociatedObservation. An associated property should have been (and eventually may be) an inherent part of the parent class attributes and thus doesn't have id, time stamp, method, performer, etc. which are context set by the parent observation. An associated observation, in contrast, is an independent observation. Both classes are controlled by vocabularies which are emerging within major international coding schemes such as LOINC (see an example in the Sequence Variation class) below.
- In all classes, the effective Time attribute should only be used when an observation is not associated with a specimen. When an observation is associated with a specimen, the effective Time of the observation is the collection time of that specimen.
- Control Acts: Through the subjectOf act relationship coming off the Genomic Statement choice box, it is made possible for any of the core genomic classes to be the subject of a Control Act. These Control Acts communicate the trigger event and other "action" information regarding the associated act when the model is used in an HL7 dynamic model. One particularly important use is to communicate that an observation event has been "corrected". In this case, the statusCode of a corrected genomic observation shows as "completed", so the ControlActEvent.code carrying the corrected trigger event is the only mechanism indicating the genomic class has been corrected.
Model Walkthrough
Notes on the use of the 'id', 'code' and 'value' attributes
The use of these attributes in the various Genetic Variation model classes depends on the extent to which the data has being personalized and how different are the results from known, published parts of the human (or animal) genome. It is also different in those classes that encapsulate raw genomic data.
For example, when using the Individual Allele class, in the case that the patient's allele was fully sequenced and found to be identical to a reference sequence registered in a reference database, then in this case the ID of the reference sequence is the ID (accession number) from a reference database, the allele value is the code for the normal human (wildtype) allele from the reference database and will contribute to the interpretation, and the observed sequence value is the only raw data observation (there being no variation). If variation is present and the variation pattern does not match that of an allele defined within the reference database, then a temporary identifier could be placed in the id attribute, a code used that indicates this is a novel allele pattern, and the full sequence and variation point values should be reported, since they are not derivable from the reference database's accession number.
In the 'encapsulating' Sequence class the 'value' attribute should hold the bioinformatics markup itself. In this case, the code should hold an indication of the exact bioinformatics format used to populate the 'value' attribute.
The following overview presents a high level walkthrough of each act, and its relationships to acts and participations that link to that act.
Entry Point and Core ClassesGenetic Loci
The Genetic Loci class is the entry point of the Genetic Variation model. It allows several genes (or several locus regions) to be grouped together in a "test order", and for an interpretation to be made that considers information from the combined gene/locus analyses. It also allows a report to be attached at a level that covers the analysis as a whole. If the reported analysis is based on only a single gene or locus, then the GeneticLoci class has a code and value identical to that of the Genetic Locus below.
The Genetic Loci act allows relationships with the following acts:- Genetic Locus - The core backbone path to the model, each genetic loci analysis must contain one or more individual genetic locus acts.
- Genetic Document - A genetic loci analysis may be linked to one or more genetic documents, that may explicate the test/analysis methodology, or report the results of the testing.
- Associated Property - A genetic loci analysis may be linked to one or more associated properties, which on an individual basis further define inherent attributes of the analysis as a whole.
- Associated Observation - A genetic loci analysis may be linked to one or more associated observations, which on an individual basis report ancillary observations about the analysis as a whole.
- Phenotype - A genetic loci analysis may be linked to one or more phenotypic interpretations, which specify a complex interpretation of the results of the genetic loci analysis as a whole.
- Subject - A genetic loci analysis may be linked to one subject (e.g., the patient, the clinical trials subject). This participant should be used only if not specified by a wrapper message or when needing to override the propagated participant.
- Specimen - A genetic loci analysis may be linked to one or more specimens. The specimen should represent merely the genetic material and not the original specimen or the process/preparation by which the genetic material was extracted. This participant should be used only if not specified by a wrapper message or when needing to override the propagating specimen.
- Performer - A genetic loci analysis may be linked to one or more performers. The genetic loci performer participation should be used only if the same organization performed all laboratory and analytic acts within that instance of the model. If multiple performers were involved, specify the performer on each lower level act.
- Author - A genetic loci analysis may be linked to one or more authors. The genetic loci author participation should be used when a specific individual can be identified as the author of the analysis.
- Verifier - A genetic loci analysis may be linked to one or more verifiers. The genetic loci verifier participation should be used when a specific individual can be identified as the reviewer and approver of the observational results and analysis.
- id - The id attribute is a globally unique instance identifier for the Genetic Loci act. The Genetic Loci id should remain constant across all genetic variation analysis interpretation revisions that derive from a common original genetic test observation or set of observations.
- code - The Genetic Loci code is required, and identifies the type of genetic loci being analyzed. For example, a multi-gene Alzheimer's Disease propensity panel would have a code defining it as such, and would then contain several calls for the Genetic Locus act to define the variation within each gene that contributed to the analysis.
- value - The value attribute identifies the set of loci through a name drawn from a recognized terminology (e.g., HLA haplotypes) or through compositional notations or through the encapsulation of raw data (e.g., SNP genotyping results).
- valueNegationInd - This negation indicator is an optional attribute that allows the sender to indicate that a Genetic Loci was not found. The Negation Indicator is a Boolean that is set to "True" when, for example, a specific set of loci (e.g., SNP haplotype) was looked for and wasn't found in the subject specimen.
- title - The Genetic Loci title is an optional attribute used to provide a short print label when the genetic test group/panel can not be defined by a coded reference (see the value field) to a gene testing database.
- text - The Genetic Loci text field is used when the suite of genes or genetic locus that are part of the loci group need human readability. A free text description of the Loci for visual display or reporting can be included in this text field. Note that comments should be added through the A_Annotation CMET and not through the text attribute which is supposed to contain a complete rendering of the observation.
- statusCode - This required status code indicates if a Genetic Loci test is cancelled, completed, or in process (in the latter case, partial results are being reported because this is a constrained CMET for results only).
- effectiveTime - This required attribute identifies the biologically relevant time of this observation, typically the collection time of the specimen used in the assay or testing. The GeneticLoci.effectiveTime attribute should thus be equal to or earlier than the time of any analysis or interpretation of the data under the Genetic Loci instance.
- confidentialityCode - This required attribute allows the sender to define the confidentiality status for all information about the Genetic Loci analysis. This confidentiality code will be conducted to all acts under the Genetic Loci, unless it is overridden by a different value at a lower level.
- reasonCode - This optional attribute defines one or more reasons (administrative in nature) that a Genetic Loci instance is being created. If the interpretation code attribute (see below) is populated, then the clinical practice or research reason shall be provided by traversing the RSON act relationship, in order to provide the semantic context for the interpretation.
- methodCode - This optional attribute defines one or more methods used to perform the genetic variation analysis. The values for the genetic Loci methodCode are intended to be very high level, and are used to indicate the type(s) for test methods used in the analysis. (e.g. a genotype chip for 8 genes may be combined with sequence results for two additional genes to produce the overall suite of genes combined in the Genetic Loci analysis).
- interpretationCode - This optional attribute defines one or more interpretations derived from a genetic variation test whose
"raw" data may or may not be included in the instance. The interpretation code should carry a phenotypic interpretation when
the interpretation can be expressed as a single (or small number of) short, concise statements that are easily coded. If a
more elaborate discussion of the phenotype is required, the Phenotype CMET model should be used.
This attribute may be bound to the following LOINC value sets used in the clinical environment (note that the LOINC code identifying
the value set should be placed in the code attribute):
LOINC "Genetic disease analysis overall interpretation" - 51968-6
- LA6576-8: Positive
- LA6577-6: Negative
- LA9663-1: Inconclusive
- LA9664-9: Failure
LOINC "Genetic disease analysis overall carrier interpretation" - 53039-4
- LA10314-5: Carrier
- LA6577-6: Negative
- LA9663-1: Inconclusive
- LA9664-9: Failure
LOINC "Drug efficacy analysis overall interpretation" - 51964-5
- LA6677-4: Responsive
- LA6676-6: Resistant
- LA6577-6: Negative
- LA9663-1: Inconclusive
- LA9664-9: Failure
LOINC "Drug metabolism analysis overall interpretation" - 51971-0
- LA10315-2: Ultrarapid metabolizer
- LA10316-0: Extensive metabolizer
- LA10317-8: Intermediate metabolizer
- LA9657-3: Poor metabolizer
Genetic Locus
The Genetic Locus class is the critical child act of a Genetic Loci analysis. Each Genetic Locus object defines one gene (or other genetic locus, e.g., unnamed genetic region) to be defined and associated with a suite of observations and statements abut that gene (or locus). A Genetic Locus instance is thus composed of one or more gene (genetic locus) result sets.
The Genetic Locus act allows relationships with the following acts:- Individual Allele - This association reflects the biological core backbone path of this model. Each genetic locus will usually contain two (maternal and paternal) allele acts. For technologies that do not result in an allelic analysis, direct linkage to genetic variations and sequences may be used (see the next two classes below).
- Sequence - A genetic locus may be directly linked to one or more sequence acts. For example, to-date, in most sequence-based analyses of known genes, the observed and reference sequences can be defined by this relationship bypassing the Individual Allele class if an allelic interpretation is not being used.
- Sequence Variation - A genetic locus may be linked directly to one or more sequence variation observations. In sequence based analyses of known genes, adjustments to the reference sequence used can be defined by this relationship. An observed sequence variation (or set of sequence variation observations) may also be linked if an allelic interpretation is not being used.
- Associated Property - A genetic locus may be linked to one or more associated properties, which further define the locus of the subject. When a named gene can not be used in the Genetic Locus code attribute, one or more Associated Property acts should be used to define the genetic location (e.g. the chromosome, start position, and end position)
- Associated Observation - A genetic locus analysis may be linked to one or more associated observations, which on an individual basis report ancillary observations about the locus, such as a copy number when a gene has been duplicated.
- Phenotype - A genetic loci analysis may be linked to one or more phenotypic interpretations, which specify a complex interpretation of the results of the genetic loci analysis as a whole (represented by the Phenotype CMET).
The Genetic Locus observation act allows all the participations attached to the Genomic Statement choice box and are described under Genetic Loci. Note that the genetic locus performer participation should be used if one organization performed the locus analysis (e.g. a laboratory did the sequencing and allele read) and a second organization performed the phenotypic interpretation act (at the locus or loci level).
Genetic Locus Attributes- id - The id attribute is a globally unique instance identifier for the genetic Locus act. The Genetic Locus id should remain constant across all genetic variation analysis revisions that derive from a common original genetic test observation or set of observations about the locus.
- code - The Genetic Locus code is required, and identifies the genetic locus as a gene, or as a defined locus with semantics such as a genetic bio-marker.
- value - The value attribute identifies the genetic locus through a name drawn from a recognized terminology (e.g., HUGO) or through compositional notations.
- valueNegationInd - This negation indicator is an optional attribute that allows the sender to indicate that a Genetic Locus was not found. The Negation Indicator is a Boolean that is set to "True" when, for example, a specific locus (e.g., a genetic bio-marker) was looked for and wasn't found in the subject specimen.
- title - The Genetic Locus title is an optional attribute used to provide a short print label when the gene or genetic region of interest can not be defined by a coded reference (see the value field) to a gene database with human readable display names for its genes.
- text - The Genetic Locus text attribute is used when the gene or genetic locus that is being analyzed needs need human readability. A free text description or multimedia representation of the Genetic Locus for visual display or reporting can be included in this text field. Note that comments should be added through the A_Annotation CMET and not through the text attribute which is supposed to contain a complete rendering of the observation.
- statusCode - This required code indicates if a Genetic Locus analysis is cancelled, completed, or in process (in the latter case, partial results are being reported).
- effectiveTime - This required attribute identifies the biologically relevant time of this observation, typically the collection time of the specimen used in the assay or testing. The GeneticLocus.effectiveTime attribute should thus be equal to or earlier than the time of any analysis or interpretation of the data represented by this observation.
- confidentialityCode - This required attribute allows the sender to define the confidentiality level for all information about the Genetic Locus analysis. This confidentiality code will be conducted to all acts under the Genetic Locus, unless it is overridden by a different value at a lower level. If specified, it also supercedes the confidentiality set in the Genetic Loci act.
- reasonCode - This optional attribute defines one or more reasons (administrative in nature) that a Genetic Locus instance is being created. If the interpretation code attribute (see below) is populated, then the clinical practice or research reason shall be provided by traversing the RSON act relationship, in order to provide the semantic context for the interpretation. If not used, the Genetic Loci reason applies to the locus.
- interpretationCode - This optional attribute defines one or more interpretations about the gene or locus derived from a genetic variation test whose "raw" data may or may not be included in the message. The interpretation code should carry a phenotypic interpretation when the interpretation can be expressed as a single (or small number of) short, concise statements that are easily coded. If a more elaborate discussion of the phenotype is required, the Phenotype CMET model should be used.
- methodCode - This required attribute defines the method used to perform the genetic variation analysis of this instance of the gene or locus. The values for the Genetic Locus methodCode are intended to be very high level, and are used to indicate the general type of test method (e.g. DNA sequencing).
Individual Allele
The Individual Allele class is used when the sequencing or other genetic method produces observations about the maternal and paternal alleles of the gene or genetic locus, and the observed values and/or variation can be linked to a specific allele. A Genetic Locus instance can thus be composed of one or more allele result sets.
The Individual Allele act allows relationships with the following acts:- Sequence - An allele instance may be linked to one or more sequence acts that report the observed sequence (or set of sequences). In most cases, an allele requires only one sequence, but if a gene has widely separated coding regions, multiple sequences may be present from the method.
- Sequence Variation - An allele may be linked to one or more sequence variation acts that record the variation within that allele from a reference sequence.
- Associated Property - An allele may be linked to one or more associated properties, which on an individual basis further define the allele normative definition or the process of defining the allele value from observed variation.
- Associated Observation - An allele may be linked to one or more associated observations, which on an individual basis report ancillary observations about the allele.
- Phenotype - An allele may be linked to one or more phenotypic interpretations, which specify a complex interpretation of the results of the alleles observed genetic variation as a whole. Individual allele phenotypes contribute to the full subject's phenotypic interpretation at the gene of loci level.
- id - The id attribute is a globally unique instance identifier for the Individual Allele act. The Individual Allele ID should remain constant across all genetic variation analysis revisions that derive from a common original genetic test observation or set of observations about the gene or locus.
- code - The Individual Allele code is required, and identifies the act as an observation of an allele and further defines the type of the allele, e.g., maternal or paternal. Note that the class code is SEQVAR and thus it is necessary to distinguish this class from the Sequence Variation class that has the same class code.
- valueNegationInd - This negation indicator is an optional attribute that allows the sender to indicate that the allele was not found. The negation indicator is a Boolean that is set to "True" when, for example, a specific allele (e.g., HLA allele) was looked for and wasn't found in the subject specimen.
- title - The Allele title is an optional attribute used to provide a short print label when the allele value of interest needs a human readable print label for reporting.
- text - The text attribute is used when the allele being described does not have a suite of coded allele state defined in a reference database or in the literature, and thus the allele must be described in free text or some multimedia format. Note that comments should be added through the A_Annotation CMET and not through the text attribute which is supposed to contain a complete rendering of the observation.
- statusCode - This required code indicates for example if an allelic observation is cancelled or completed.
- effectiveTime - This required attribute identifies the biologically relevant time of this observation, typically the collection time of the specimen used in the assay or testing. The IndividualAllele.effectiveTime attribute should thus be equal to or earlier than the time of any analysis or interpretation of the data represented by this observation.
- reasonCode - This optional attribute defines one or more reasons (administrative in nature) that an Individual Allele instance is being created. If the interpretation code attribute (see below) is populated, then the clinical practice or research reason shall be provided by traversing the RSON act relationship, in order to provide the semantic context for the interpretation.
- value - The value attribute is used when the allele being described can be specified by assigning a suite of coded allele states defined in a reference database (e.g., HLA database) or in the literature, otherwise it is possible to use compositional notations or even encapsulate raw data in bioinformatics markups.
- interpretationCode - This optional field defines one or more interpretations about the allele The interpretation code should carry a phenotypic interpretation when the interpretation can be expressed as a single (or small number of) short, concise statements that are easily coded. If a more elaborate discussion of the phenotype is required, the Phenotype CMET model should be used.
Sequence
The Sequence class is used when the full or partial gene sequencing is the primary genetic test method and the sequence variation is being defined by comparing the subject's observed sequences (usually one for each allele if allelic data was collected) with a reference sequence. A sequence act can be in a definitional mood (moodCode = DEF) when it is being used to define the reference sequence, or in an event mood (EVN) when it is being used to report the observed sequence(s).
The Sequence act allows relationships with the following acts:- Sequence Variation - A sequence instance that is in Definitional mood may be linked to one or more sequence variation acts that are also in Definitional mood in order to specify specific changes to the definition of the reference sequence as drawn from a database or published source.
- Associated Property - A sequence may be linked to one or more associated properties, which on an individual basis further define the sequence normative definition (when a reference sequence is being described) or the process of obtaining the observed sequence.
- Associated Observation - A sequence may be linked to one or more associated observations, which on an individual basis report ancillary observations about the sequence not able to be included in the encapsulated sequence data.
- Phenotype - A sequence may be linked to one or more phenotypic interpretations, which specify a complex interpretation of the results of the observed sequence as a whole. Sequence phenotypes are used primarily when a well defined gene has only a short sequence needed to identify a single (or small set) of relevant mutations and can thus directly link to an interpretation.
- Performer - The Sequence observation act allows all the participations attached to the Genomic Statement choice box and are described under Genetic Loci. Note that the sequence performer participation should be used if one organization performed the sequencing and a second organization performed the analysis and phenotypic interpretation at the allele, gene or loci level.
- id - The id attribute is a globally unique instance identifier for the Sequence act. The sequence id should remain constant across all genetic variation analysis revisions that derive from a common original sequence observation. The Sequence id may be following the OMG LSID specification if the sequence information has been deposited in a repository and no details are being provide in this particular message instance.
- code - The code attribute indicates the type of representation used in the value attribute, e.g., BSML.
- valueNegationInd - The negation indicator is an optional attribute that allows the sender to indicate that the specific sequence assigned in the value attribute was not found. Note that when, for example, a gene's maternal or paternal chromosome arm has broken and no sequence read was possible, it should be represented through the status and reason codes and not through the negation indicator.
- title - The Sequence title is an optional attribute used to provide a short print label when the sequence of interest needs a human readable print label for reporting. A Sequence title is generally used when interpretation is based on very short, highly targeted sequences.
- text - The text attribute is used when the sequence is being described for human readability purposes. Note that comments should be added through the A_Annotation CMET and not through the text attribute which is supposed to contain a complete rendering of the observation.
- statusCode - This optional code indicates if a sequence observation (in event mood) was cancelled, completed or only partial results are available.
- effectiveTime - This required attribute identifies the biologically relevant time of this observation, typically the collection time of the specimen used in the assay or testing. The Sequence.effectiveTime attribute should thus be equal to or earlier than the time of any analysis or interpretation of the data represented by this observation.
- reasonCode - This optional attribute defines one or more reasons (administrative in nature) that a Sequence object is being created. If the interpretation code attribute (see below) is populated, then the clinical practice or research reason shall be provided by traversing the RSON act relationship, in order to provide the semantic context for the interpretation. This attribute is not used if the Genetic Loci or Locus reason code applies to the child sequence observations.
- value - The value field is used when the sequence (reference or observed) is being described within an encapsulated format (e.g. BSML embedded within the HL7 XML).
- methodCode - This attribute is required when in the Sequence observation act is in Event mood, and defines the method used to perform the sequencing of the DNA. Additional supporting method definition may be provided in the Associated Property act.
- interpretationCode - The interpretation code for a sequence may be used primarily when a well defined gene has only a short sequence needed to identify a single (or small set) of relevant mutations and can thus directly link to a simple, coded interpretation, other wise use the association to the Phenotype CMET.
Sequence Variation
The Sequence Variation class is used to describe the subject's point(s) of genetic variation from a defined reference sequence or normative definition of certain genetic locations (e.g. with a SNP Probe technology).
The Sequence Variation act allows relationships with the following acts:- Associated Property - A sequence variation may be linked to one or more associated properties, which on an individual basis
further define the sequence variation or its attributes that could be known a priori.
A major challenge is to accurately identify the type of sequence variation. In the clinical environment, a set of DNA sequence variation types represented here by their LOINC codes may be used to bind the code and value attributes of this class and thus furter define the sequence variation. The LOINC code that identifies the following value set is 48019-4 representing the LOINC component "DNA sequence variation type". Thus, it is sufficient to place this LOINC code in the code attribute of the AssociatedProperty class (associated with the SequenceVariation class) and one of the codes from the list below in its value attribute.
LOINC "DNA sequence variation type" - 48019-4
- LA9658-1: Wild type
- LA6692-3: Deletion
- LA6686-5: Duplication
- LA6687-3: Insertion
- LA6688-1: Insertion/Deletion
- LA6689-9: Inversion
Another example is value set is the value set "Amino acid change type" - LOINC code 48006-1. It is possible to place this LOINC code in the code attribute of the AssociatedProperty class (associated with the SequenceVariation class) and one of the codes from the list below in its value attribute.
LOINC "Amino acid change type" - 48006
- LA9658-1: Wild type
- LA6692-3: Deletion
- LA6686-5: Duplication
- LA6694-9: Frameshift
- LA6695-6: Initiating Methionine
- LA9659-9: Insertion and Deletion
- LA6698-0: Missense
- LA6699-8: Nonsense
- LA6700-4: Silent
- LA6701-2: Stop Codon Mutation
- Associated Observation - A sequence variation may be linked to one or more associated observations, which on an individual basis report ancillary observations about the sequence variation not able to be included in the value. For example, a codon (3 base pairs) insertion may be the observed sequence variation, and an associated observation needed to state that six copies of the codon were inserted.
- Phenotype - An individual Sequence Variation act may be linked to one or more phenotypic interpretations, which specify a complex interpretation of the specific genetic variation being reported. Individual sequence variation phenotypes contribute to the full subject's phenotypic interpretation at the gene of loci level.
- id - The id attribute is a globally unique instance identifier for the Sequence Variation act. The sequence variation id should identify a distinct variation observation object possibly along with an interpretation. If a second analysis is performed against an update gene database, then a new object should be created assigned with a different id with its own performer and effective time.
- code - The Sequence Variation code is required, and indicates the type of representation used in the value attribute, e.g., dbSNP, HGVS, BSML. Since this class can accommodate a wide range of representations from raw data to compositional notations and codes drawn from a coding system, this code attribute eases the parsing of that class in a way that the parsing application can look in this attribute to know how to parse the content of the value attribute.
- valueNegationInd - This negation indicator is an optional attribute that allows the sender to indicate that a Sequence Variation represented by the value attribute was not found. In cases when the variation could not be observed due to technical reasons, use the status and reason codes to describe this situation.
- title - The sequence variation title field is used when the sequence variation is relatively complex and needs a short print label for reporting purposes.
- text - The Sequence Variation text field is used when the variation needs human readability. A free text description (or multimedia representation) of the variation for visual display or reporting can be included in this text field. Note that comments should be added through the A_Annotation CMET and not through the text attribute which is supposed to contain a complete rendering of the observation.
- statusCode - This optional code indicates if a sequence variation observation was cancelled, completed or only partial results are available.
- effectiveTime - This required attribute identifies the biologically relevant time of this observation, typically the collection time of the specimen used in the assay or testing. The SequenceVariation.effectiveTime attribute should thus be equal to or earlier than the time of any analysis or interpretation of the data represented by this observation.
- value - The value field is used when the sequence variation can be described in a short concise form, such as the HUGO/HGVS nomenclature and thus carried as a controlled format text value. In other, rare instances where the variation is highly complex, a coded value, or an encapsulated XML blob may also be used as the Sequence Variation value. The value attribute is typed as ANY and should be set accordingly. Note that this class could represent raw data if for example the sequence variation was tested directly and not through full sequencing, but at the same time this class could represent 'bubbled-up' information when it is derived from an observed sequence encapsulated in a Sequence class.
- interpretationCode - This optional field defines one or more interpretations about the sequence variation. The interpretation
code should carry a phenotypic interpretation when the interpretation can be expressed as a single (or small number of) short,
concise statements that are easily coded. If a more elaborate discussion of the phenotype is required, the Phenotype CMET
model should be used.
This attribute may be bound to the following LOINC value set (note that the LOINC code indetifying the value set should
be placed in the code attribute):
LOINC "Genetic disease sequence variation interpretation" - 53037-8
- LA6668-3: Pathogenic
- LA6669-1: Presumed pathogenic
- LA6682-4: Unknown significance
- LA6675-8: Benign
- LA6674-1: Presumed benign
Sequence variation interpretation realted to drug efficacy is represented by the following LOINC answer list:
LOINC "Drug efficacy sequence variation interpretation" - 51961-1
- LA6676-6:Resistant
- LA6677-4:Responsive
- LA9660-7: Presumed resistant
- LA9661-5: Presumed responsive
- LA6682-4: Unknown Significance
- LA6675-8: Benign
- LA6674-1: Presumed Benign
- LA9662-3: Presumed non-responsive
Genetic Document
The Genetic Document class is used to connect a human readable supporting or summary document to the genetic analysis as a whole. Note that the Clinical Genomics and Structured Documents Work Groups develop a CDA Implementation guide for Genetic Testing Reports which could then be used as a default in this association. Note that class is essentially a stub and its attributes are taken from the document attributes and represent essential metadata about the document to allow parsing application locating the document.
The Genetic Document act allows the following participations:- Author - A Genetic Document may be linked to one author. The Genetic Document author should be specified if the Author participation at the Genetic Loci was not used, or if the document author is different from the author of the analysis as a whole.
- id - The id attribute is a globally unique instance identifier for the Genetic Document. The ID should identify a distinct report instance, with its own effective time. If a second analysis is performed against an update gene database, and a second report generated, then a new Genetic report id should be used as this is a new instance with its own author and effective time. Every Genetic Document should also have another id attribute 'setId' which remains constant across all revisions of the document that pertains to the genetic variation instance.
- code - The Genetic Document code is required, and further identifies the type of genetic document (e.g., genetic variations report, gene expression testing report, etc.)
- title - Every Genetic Document instance has an optional title, with a data type of ST that allows free text entry of the human readable title of the report.
- text - The text field is used when the report is being referenced from or encapsulated within the text attribute of the Genetic Document act, or a pointer/URL is being provided to locate the report.
- statusCode - This optional code indicates if a genetic report cancelled, completed or partially populated but already available.
- effectiveTime - This required attribute identifies the point in time that the report was issued. The Genetic Document effective time should thus be equal to or later than the effectiveTime stamp of the Genetic Loci act that is its parent.
- confidentialityCode - This required attribute allows the sender to define the confidentiality status for all information within the genetic document. This confidentiality value may override the confidentiality at the Genetic Loci parent level.
- languageCode - This optional attribute defines human language used to write the report.
- versionNumber - When a Genetic Document has been updated/revised and is being re-sent as part of a transmission, the sender may wish to indicate that this is a new version of the document. The Genetic Document act has an optional version number that contains an integer number that indicates the document version.
| R_SpecimenUniversal | COCT_MT080000UV |
| R_AssignedEntityUniversal | COCT_MT090000UV01 |
| R_AssignedPersonUniversal | COCT_MT090100UV01 |
| R_AssignedPersonUniversal | COCT_MT090100UV01 |
| R_AssignedDeviceUniversal | COCT_MT090300UV01 |
| A_PhenotypeUniversal | COCT_MT340000UV |
| A_PhenotypeUniversal | COCT_MT340000UV |
| A_SupportingClinicalStatementUniversal | COCT_MT530000UV |
| R_SubjectUniversal | COCT_MT560000UV07 |
| A_AnnotationUniversal | COCT_MT590000UV |
| A_GeneticLoci GeneticVariation eventual | COCT_MT540006UV | |
| Parent: | Clinical Genomics (POCG_DM000020UV) |
The Phenotype CMET is meant to complement or replace the use of the interpretation codes presnet in all core classes of the Clinical Genomics models. While the interpretatioon code attribute could hold a single code, the Phenotype model has the full expressiveness of the Clinical Statement model. Phenotype is a separate model for modularity reasons - it is possible to make changes in this model without changing any of the utilizing models.
The entry point to this model is a choice box that has two 'stub' observations targeted at distinguishing between two basic types of phenotypes: observed phenotypes and interpretive phenotypes. While the former represents observations made in the subject, the latter is an interpretation based on some evidence. To represent a complex phenotype (whether observed or interpretive), the choice box is associated with the Clinical Statement CMET so that the full expressiveness of that model is available to represent phenotypic data.
| R_AssignedEntityUniversal | COCT_MT090000UV01 |
| R_MedicationUniversal | COCT_MT230100UV |
| A_SupportingClinicalStatementUniversal | COCT_MT530000UV |
| A_Phenotype universal | COCT_MT340000UV | |
| Parent: | Clinical Genomics (POCG_DM000020UV) |
The Pedigree CMET is the exact same model as the RMIM of the Clinical Genomics Pedigree Topic and the model walk-through can be found there. It conveys a pedigree of a patient with the option of holding clinical and genomic data for each of the patient's relatives. In addition, it can convey results of running risk analysis algorithms.
| 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.
| A_BenefitBasic | COCT_MT770005UV |
| A_ValuedItem basic | COCT_MT440005UV | |
| 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
| A_ValuedItem definitional | COCT_MT440006UV | |
| 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
| A_ValuedItem identified | COCT_MT440001UV | |
| 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
| A_ValuedItem informational | COCT_MT440007UV | |
| 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.
| A_ValuedItem minimal | COCT_MT440004UV | |
| 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.
| A_BenefitUniversal | COCT_MT770000UV |
| A_ValuedItem universal | COCT_MT440000UV | |
| 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".
| A_SupportingClinicalStatementUniversal | COCT_MT530000UV |
| A_Benefit basic | COCT_MT770005UV | |
| 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.
| A_SupportingClinicalStatementUniversal | COCT_MT530000UV |
| A_ProviderContractBasic | COCT_MT780005UV |
| A_Benefit universal | COCT_MT770000UV | |
| 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.