CDA+-+Conformance+Verb+Matrix


 * **

The keywords **SHALL**, **SHOULD**, **MAY**, **NEED NOT**, **SHOULD NOT**, and **SHALL NOT** in this document are to be interpreted as described in the [|HL7 Version 3 Publishing Facilitator's Guide (http://www.hl7.org/v3ballot/html/help/pfg/pfg.htm)]:
 * **SHALL:** an absolute requirement
 * **SHALL NOT:** an absolute prohibition against inclusion
 * **SHOULD/SHOULD NOT:** valid reasons to include or ignore a particular item, but must be understood and carefully weighed
 * **MAY/NEED NOT:** truly optional; can be included or omitted as the author decides with no implications

The keyword "SHALL" implies a lower cardinality of 1, but allows NULL values. If NULL values are to be excluded, it will be via an additional explicit conformance statement.

Figure XX represents a matrix of the conformance verbs used across the standards reviewed for the consolidation guide. Cells with a dash (-) did not have an equivalent conformance convention. Absolute requirement of the specification || **SHALL** Required/Mandatory || **R** (Required) Element must be present but can be NULL || **R** (Required) Data elements must always be sent. A NULL can be sent. || **SHALL** Element must be present but can be NULL Where necessary to explicitly preclude nullFlavor (e.g. where you want to preclude nullFlavor on observation/value), can include something like "SHALL NOT include nullFlavor". Where SHALL is applied to an attribute, it must be present and cannot be a NULL || Absolute prohibition of the specification || **SHALL NOT** Not Required/Mandatory || - || - || **SHALL NOT** Absolute prohibition against inclusion || Recommended There may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. || **SHOULD** Best Practice or Recommendation || **R2** (Required if known) The sending application must be able to demonstrate that it can send all required if known elements, unless it does not in fact gather that data. If the information cannot be transmitted, the data element shall contain a value indicating the reason for omission of the data. || **R2** (Required if known) If the sending application has data for the data element, it is REQUIRED to populate the data element. If the value is not known, the data element need not be sent || **SHOULD** Best Practice or Recommendation There may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course || Not Recommended || **SHOULD NOT** Not Recommended || - || - || **SHOULD NOT** Not Recommended || Optional || **MAY** Accepted/Permitted || **O** (Optional) || **O** (Optional) || **MAY** Optional || A conditional data element is one that is required, required if known or optional depending upon other conditions. || **C** (Conditional) Required to be sent when the conditions specified in the HITSP additional specifications column are true || - ||
 * **RFC 2119** || **HL7** || **IHE** || **HITSP** || **Consolidation Proposal** ||
 * **SHALL**
 * **SHALL NOT**
 * **SHOULD**
 * **SHOULD NOT**
 * **MAY**
 * **-** || - || **C** (Conditional)

Raw notes from standards referenced
__**1. RFC 2119**__ ([])
 * 1) MUST - This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
 * 2) MUST NOT - This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.
 * 3) SHOULD - This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
 * 4) SHOULD NOT - This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
 * 5) MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)

__**2. HL7**__ – HL7 Version 3 Publishing Facilitator's Guide ([])
 * ===Stringent Use of SHALL, SHOULD and Other Modal Verbs=== ||
 * **To Convey the Sense of:** |||| **Use the Following:** ||
 * Required/Mandatory || SHALL || SHALL NOT ||
 * Best Practice/Recommendation || SHOULD || SHOULD NOT ||
 * Acceptable/Permitted || MAY || NEED NOT ||

__**3. IHE PCC**__ – 6.1 Conventions ([|IHE_PCC_TF_Rev6-0_Vol_2_2010-08-30.pdf])
 * R - A "Required" data element is one that shall always be provided. If there is information available, the data element must be present. If there is no information available, or it cannot be transmitted, the data element must contain a value indicating the reason for omission of the data. (See IHE PCC TF-2:5.3.4.2 for a list of appropriate statements).
 * R2 - A "Required if data present" data element is one that shall be provided when a value exists. If the information cannot be transmitted, the data element shall contain a value indicating the reason for omission of the data. If no such information is available to the creator or if such information is not available in a well identified manner (e.g., buried in a free form narrative that contains additional information relevant to other sections) or if the creator requires that information be absent, the R2 section shall be entirely absent. (See section IHE PCC TF-2:5.3.4.2 for a list of appropriate statements).
 * O - An optional data element is one that may be provided, irrespective of whether the information is available or not. If the implementation elects to support this optional section, then its support shall meet the requirement set forth for the "Required if data present" or R2.
 * C - A conditional data element is one that is required, required if known or optional depending upon other conditions. These will have further notes explaining when the data element is required, et cetera.
 * Note:** The definitions of R, R2, and O differ slightly from other IHE profiles. This is due in part to the fact that local regulations and policies may in fact prohibit the transmission of certain information, and that a human decision to transmit the information may be required in many cases.

__**4. HITSP**__ – [|C83]
 * R - **REQUIRED** - Required data elements must always be sent. Data elements that are required may under exceptional circumstances have an unknown value (e.g., the name of an unconscious patient). In these cases the sending application is required to indicate the reason that the data are not available where the standard permits. Some standards may not permit an unknown value at all
 * R2 - Required if known - If the sending application has data for the data element, it is **REQUIRED** to populate the data element. If the value is not known, the data element need not be sent
 * O - **OPTIONAL** - Data elements that are marked optional may be sent at the choice of the sending application. An optional element need not be sent, but when it is sent, the data module defines the meaning of that data element and a receiver can always be assured of what that data element represents when it is present. Senders should not send an optional data element with an unknown value. If the value is not known, simply do not send the data element
 * C - Conditional - Data elements that are marked conditional (C) are **REQUIRED** to be sent when the conditions specified in the HITSP additional specifications column are true. The conditions under which the data element is to be exchanged will be specified as a constraint on the data element in the last column.

__**5. HL7 wiki**__ – [|http://wiki.hl7.org/index.php?title=Conformance_validation]
 * SHALL/SHOULD/MAY vs. R/R2 vs. Required/Mandatory [see: []]
 * **SHALL:** Corresponds to HMD "Required" if on XML element (i.e. the element is there, but can be NULL); Corresponds to HMD "Mandatory" if on XML attribute. Corresponds to IHE "R".
 * **SHOULD:** Corresponds to IHE "R2".
 * Where necessary to explicitly preclude NULL (e.g. where you want to preclude NULL on observation/value), can include something like "SHALL NOT include nullFlavor".