|DotNet Class HL7Connect.Cda.CD|
A CD is a reference to a concept defined in an external code system, terminology, or ontology. A CD may contain a simple code - that is, a reference to a concept defined directly by the referenced code system, or it may contain an expression in some syntax defined by the referenced code system that can be meaningfully evaluated. e.g., the concept of a "left foot" as a postcoordinated term built from the primary code "FOOT" and the qualifier "LEFT".
A CD may also contain an original text or phrase that served as the basis of the coding. This is preserved to allow for validation of the representation of the concept in various fashions.
A CD can contain one or more translations into multiple coding systems. The translations are all representations of the same concept in various code systems. There is only one concept, and only the first CD may contain an original text. It is possible to represent the translation chain - which CD was translated from which - if desired. Each CD may also carry a rationale to indicate why it is represented.
A CD with no nullFlavor attribute SHALL have a code attribute or nonNull originalText attribute. A CD that has a code, codeSystem or originalText attribute but does not meet external constraints of the applicable value set SHALL have a nullFlavor attribute with a value of "OTH".
Attributes with type CD are generally bound by externally specified constraints which constrain the coded concepts to which a CD may refer. These constraints may be qualified as "extensible" (CWE) or "not extensible" (CNE). If the constraint is not extensible (CNE), then a the CD that does not have a nullFlavor SHALL contain a code that conforms to the constraint. If the constraint is extensible (CWE) then a CD that does not have a nullFlavor SHALL contain either a code that exists in the domain with which the attribute is associated, a code from a locally defined code system, or just some originalText that describes the concept. If the code is taken from a locally defined code system, then the codeSystem property SHALL specify the local code system.
For both CNE and CWE constraint types, the translations may contain nonNull codes from any source unless otherwise specified by the constraining model.
For code systems that define expression syntaxes, CNE constraints may be used, providing that the code system definitions define the appropriate support to enable value sets to make useful statements about how to control the expression syntax, and that the value set machinery used also has the appropriate suppor
|The plain code symbol defined by the code system, or an expression in a syntax defined by the code system which describes the concept. |
If a code is provided, it SHALL be an exact match to a plain code symbol or expression defined by the code system. If the code system defines a code or expression that includes whitespace, the code SHALL include the whitespace. An expression can only be used where the codeSystem either defines an expression syntax, or there is a generally accepted syntax for the codeSystem. A code system may be defined that only defines an expression syntax with bindings to other code Systems for the elements of the expression.
It is at the discretion of the interpreting system whether to check for an expression instead of a simple code and evaluate the expression instead of treating the expression as a code. In some cases, it may be unclear or ambiguous whether the code represents a single symbol or an expression. This usually arises where the code system defines an expression language and then defines pre-coordinated concepts with symbols which match their expression, e.g. UCUM. In other cases, it is safe to treat the expression as a symbol. There is no guarantee that this is always safe: the definitions of the codeSystem should always be consulted to determine how to handle potential expressions.
|The code system that defines the code, or if no code was found, the codeSystem in which no code was found. |
Code systems SHALL be referred to by a UID, which allows unambiguous reference to standard code systems and other local codesystems. Where either ISO or HL7 have assigned UID to code Systems, then these UIDs SHALL be used. Otherwise implementations SHALL use an appropriate ISO Object Identifier (OID) or UUID to construct a globally unique local coding system identifier.
A CD that has a code attribute SHALL have a codeSystem specifying the system of concepts that defines the code.
An CD with a nullFlavor OTH indicates that a concept could not be coded in the coding system or value set specified. Thus, for these coding exceptions, the code system or value set that did not contain the appropriate concept SHALL be provided in codeSystem or valueSet.
|The common name of the coding system. |
The code system name has no computational value. codeSystemName can never modify the meaning of codeSystem and cannot exist without codeSystem.
Information Processing Entities claiming direct or indirect conformance SHALL NOT functionally rely on codeSystemName. In addition, they MAY choose not to implement codeSystemName but SHALL NOT reject instances because codeSystemName is present.
Note: The purpose of a code system name is to assist an unaided human interpreter of a code value to interpret codeSystem.
|If applicable, a version descriptor defined specifically for the given code system.|
Different versions of one code system must be compatible. By definition a code symbol SHALL have the same meaning throughout all versions of a code system. Between versions, codes may be retired but not withdrawn or reused. Where the definition of the meaning of a code symbol changes, it must still be compatible (equal) between different code system versions.
Whenever a code system changes in an incompatible way, it will constitute a new code system, not simply a different version, regardless of how the vocabulary publisher calls it. For example, the publisher of ICD-9 and ICD-10 calls these code systems, "revision 9" and "revision 10" respectively. However, ICD-10 is a complete redesign of the ICD code, not a backward compatible version. Therefore, for the purpose of this datatype specification, ICD-9 and ICD-10 are different code systems, not just different versions. By contrast, when LOINC updates from revision "1.0j" to "1.0k", this would be considered as just another version of LOINC, since LOINC revisions are backwards compatible.
|The value set that applied when this CD was created.|
Value sets shall be referred to by an identifier name which allows unambiguous reference to a value set. Where either ISO or HL7 have assigned an identifying name to a value set, then that name shall be used.
In many cases, a CD is created from a value set - either a code/code system pair is chosen from a valueSet, or one is not chosen and the CD has the exceptional value of NullFlavor.OTH. If no code is chosen, it is generally inappropriate to reference the code system from which the code was chosen as the value set may not match the code system (may include a subset of the codeSystem, or additional terms from other code systems); instead, the value set should be provided. In addition, there are some known use cases where the value set that a user or system was offered when choosing a code affects the interpretation of the code.
If a code is provided, the meaning of the code must come from the definition of the code in the code system. The meaning of the code SHALL NOT depend on the value set. Information Processing Entities claiming direct or indirect conformance SHALL NOT be required to interpret the code in light of the valueSet, and they SHALL NOT reject an instance because of the presence or absence of any or a particular value set.
|The version of the valueSet in which no code was found.|
valueSetVersion SHALL be provided when a valueSet is provided, and otherwise SHALL be null. The value of the valueSetVersion must properly identify a particular version of the value set following the rules defined by the value set or its publisher.
It is generally recommended that value set publishers specify that the version is identified by the date/time that the value set version is published, and that the publication process makes the date/time explicitly clearclear.
|A name, title, or representation for the code or expression as it exists in the code system.|
If populated, the displayName SHALL be a valid human readable representation of the concept as defined by the code system at the time of data entry. The displayName SHALL conform to any rules defined by the codingSystem; if the codeSystem does not define a human representation for the code or expression, then none can be provided. displayName is included both as a courtesy to an unaided human interpreter of a code value and as a documentation of the name used to display the concept to the user. The display name has no functional meaning; it SHALL never exist without a code; and it SHALL never modify the meaning of the code. A display name may not be present if the code is an expression for which no display name has been assigned or can be derived. Information Processing Entities claiming direct or indirect conformance MAY choose not to implement displayName but SHALL NOT reject instances because displayName is present.
Display names SHALL not alter the meaning of the code value. Therefore, display names SHOULD NOT be presented to the user on a receiving application system without ascertaining that the display name adequately represents the concept referred to by the code value. Communication SHALL NOT simply rely on the display name. The display name's main purpose is to support implementation debugging.
|The text as seen and/or selected by the user who entered the data which represents the intended meaning of the user. |
Note: Local implementations may influence what is required to represent that original text.
Original text can be used in a structured user interface to capture what the user saw as a representation of the code on the data input screen, or in a situation where the user dictates or directly enters text, it is the text entered or uttered by the user.
It is valid to use the CD datatype to store only the text that the user entered or uttered. In this situation, original text will exist without a code. In a situation where the code is assigned sometime after the text was entered, originalText is the text or phrase used as the basis for assigning the code.
The details of the link in the originalText.reference between different artifacts of medical information (e.g., document and coded result) is outside the scope of this specification and may be further proscribed in specifications that use this specification.
The original text SHALL be an excerpt of the relevant information in the original sources, rather than a pointer or exact reproduction. Thus the original text SHALL be represented in plain text form. In specific circumstances, when clearly descirbed the context of use, the originalText may be a reference to some other text artefact for which the resolution scope is clearly described.
Values of type CD MAY have a original text despite not having a code. Any CD value with no code signifies a coding exception. In this case, originalText is a name or description of the concept that was not coded. Such CD values MAY also contain translations.
Translations directly encode the concept described in originalText. The originalText represents the originalText of the concept itself. Translations SHALL NOT have an originalText of their own.
|the reason why a particular CD has been provided, either as the root concept or as one of the translations.|
If populated, the value contained in this attribute SHALL be taken from this enumeration, composed from the HL7 CodingRationale code system -- Coding Rationale for why a code is provided (CD and PQ/PQR)
|A set of other CDs that each represent a translation of this CD into equivalent codes within the same code system or into corresponding concepts from other code systems.|
The translations are quasi-synonyms of one real-world concept. Every translation in the set is supposed to express the same meaning "in other words." However, exact synonymy rarely exists between two structurally different coding systems. For this reason, not all of the translations will be equally exact.
Translations SHALL NOT contain translations. The root CD has one set of translations which lists all the translations. The root translation is generally the one that best meets the conformance criteria for the CD. No implication about lineage of the translations can be drawn from the selection of the root code. Instead the properties codingRationale and source is used to trace lineage.
In the absence of a constraining model that makes constraints on the value domain of the CD, any of the translations MAY be the root CD. If the constraining model makes constraints on the value domain of the CD and there is a translation that meets the constraints, that translation SHOULD be the root CD. If the constraining model makes constraints on the value domain of the CD and there is no translation that meets the constraints, then any of the translations MAY be the root, as long as they are assigned a nullFlavor. An alternative is to put none of the translations in the root, and give it a nullFlavor of choice, and put all the translations in the translation property of the root.
|Specifies additional codes that increase the specificity of the the primary code.|
|HL7Connect.Cda.CD AddTranslation(string code, string codeSystem);|
|Shortcut method. Add an ED to the list of translations.|