The data type for Real World Concepts shall be defined in as the "Concept Descriptor".
Note that this proposed data type is a redefinition without changes, but check out last notes and comments: [version 1].
| Concept Descriptor | |||
|---|---|---|---|
| A concept descriptor communicates a real world concept (such as a finding or a diagnosis). A given concept may be expressed in multiple terms where each term is a translation of some other term, or is a (re-)encoding of the original human readable text. | |||
| component name | type/domain | optionality | description |
| translations |
SET OF Code Translations |
required | These are the translations or quasi-synonyms of one real world concept. Every translation in the set is supposed to "say the same thing in different words." The translations in the set form one directed graph that is fully connected. |
| original text | Free Text | optional | This is the original text or phrase entered by a clinician that was the basis for the initial coding. This can also be the text that was displayed to the clinician in a selection menu and thus was the basis for the selection of the particular initial code term in the set of translations. |
[A summary of previous and recent comments on this data type will soon appear here. See also the previous conference notes.]
Note that this proposed data type is a redefinition without changes, but check out last notes and comments: [version 1].
| Code Translation | |||
|---|---|---|---|
| This data type holds one code phrase as one translation in a set of translations describing a concept. The additional information in this data type points to the source code used in the translation process and describes who or what performed the translation and what the quality of this translation is. | |||
| component name | type/domain | optionality | description |
| term | Code Phrase | required | All the meaning of the translation is found here, the rest is descriptive stuff. |
| origin |
reference to CodeTranslation |
required | This is the code in the list of translations on which this translation was based. This is a required component which means, whoever adds an additional translation must reference the source code. No reference here means that the given translation is the original code. |
| producer |
Unravelable Instance Identifier |
optional | This identifier tells what system performed the translation. This information can be useful to audit the translation process or to estimate the quality of the term based on prior experience with a the translation of a given producer. This identifier refers to some system not a particular human coding clerk. However, the system identifier can be fine grained enough so that the human operator can be determined in the process of unraveling the identifier. |
| quality |
Floating Point Number [0..1] |
optional | An estimation of the translation quality. This is a value between 0 and 1, where 1 stands for an absolutely accurate translation and 0 stands for random fuzz. We do not require a special method to be used here to estimate the quality. This can just be a subjective estimation of the form we use in eliciting probablilities for a belief network. But we can recommend some example methods of how those values can be computed. We can also map all other quality estimations mentioned in the literature onto the interval [0..1] of real numbers. |
[A summary of previous and recent comments on this data type will soon appear here. See also the previous conference notes.]
Note that this proposed data type is a redefinition without changes, but check out last notes and comments: [version 1].
| Code Phrase | |||
|---|---|---|---|
| A code phrase is a list of code values which all together make up a meaning. This can be used for example in SNOMED, where you can combine multiple codes into a new composite meaning. HL7 used to combine codes and modifiers for the OBR specimen source. And HCFA procedure codes also come with modifiers. | |||
| ORDERED LIST OF Code Value |
[A summary of previous and recent comments on this data type will soon appear here. See also the previous conference notes.]
See also the prior versions of this proposed type and its notes and comments [version 2] [version 1]
| Code Value | |||
|---|---|---|---|
| A code value is exactly one symbol in a code system. The meaning of the symbol is defined exclusively and completely by the code system that the symbol is from. | component name | type/domain | optionality | description |
| value | Character String | required |
this is the plain symbol, like "784.0"
|
| code system | a code by itself | required, can be fixed by context |
denotes the code system that defined the plain symbol |
| code system version | Character String | optional | a version descriptor defined specifically for the given code system. |
| print name | Character String | optional | a sensible name for the code as a curtesy to an interpreter of the message. THE PRINTNAME HAS NO MEANING, it can never be sent alone and it can never modify the meaning of the code value |
| replacement | Character String | conditional, iff value is not set |
a name for the concept to be used in case that the concept is not codeable in the specified coding system. If the value attribute is set, the replacement attribute MUST NOT be set. In no way can a replacement string modify the meaning of the code value |
[A summary of previous and recent comments on this data type will soon appear here. See also the previous conference notes.]