This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Requirements-Value Set Content"
Jump to navigation
Jump to search
Line 31: | Line 31: | ||
| mif-vocabulary-model.xsd/ContentDefinition/drawnFromCodeSystem | | mif-vocabulary-model.xsd/ContentDefinition/drawnFromCodeSystem | ||
|} | |} | ||
+ | |||
{| border="2" cellspacing="0" cellpadding="3" width="600" | {| border="2" cellspacing="0" cellpadding="3" width="600" | ||
Line 140: | Line 141: | ||
|- | |- | ||
| ''MIF'' | | ''MIF'' | ||
− | | mif-vocabulary-model.xsd/ContentDefinition/nonComputableContent|} | + | | mif-vocabulary-model.xsd/ContentDefinition/nonComputableContent |
+ | |} | ||
Revision as of 06:43, 27 November 2009
Value set content defines an enumeration or expression that resolves to a set of codes from one or more code systems.
Content
Requirement | Value Set content definitions may have a number of different types of annotations |
Rationale | See rationales for individual annotations types |
Implementation |
Requirement | Content definitions need to be able indicate which code system the content is being drawn from. |
Rationale | The code system determines the codes, properties, qualifiers and other relationships that can be used to define content. |
MIF | mif-vocabulary-model.xsd/ContentDefinition/drawnFromCodeSystem |
Requirement | Content definitions need to be able indicate which code system supplement(s), if any, they are based on. the content is being drawn from. |
Rationale | Code system supplements provide additional properties, relationships and representations that may be used to define value set content. |
MIF | mif-vocabulary-model.xsd/ContentDefinition/usesCodeSystemSupplement |
Requirement | Content definitions need to be able to identify which types of representations are allowed for the concepts selected by the content definition. |
Rationale | Some code systems may have multiple codes and/or multiple print names for a given concept. When defining the value set, there's often a need to constrain to only a single code or print name. For example, with ISO country codes, there might be a desire to constrain to only the 2-character codes. Or for multi-language code systems, to constrain to a particular language print name. |
MIF | mif-vocabulary-model.xsd/ContentDefinition/allowedRepresentation |
Filters
Requirement | Valueset content must support complex structures involving combinations of other content structures such as unions, intersections and exclusions. |
Rationale | Many value set definitions are complex. For example "all specializations of code X or code Y, except specializations of code Z" |
MIF | mif-vocabulary-model.xsd/ContentDefinition/combinedContent |
Requirement | Content needs to be able to be defined by enumerating a set of allowed codes |
Rationale | For simple value sets or unsophisticated code systems, enumeration of the allowed set of codes is the best or only way to define value set content |
MIF | mif-vocabulary-model.xsd/ContentDefinition/codeBasedContent |
Requirement | Content needs to be able to be defined as a code and/or codes that have relationships of a particular type to that code, including such constructs as direct relations to the head code, the complete set of codes found by traversing relationships of the specified type or "leaf" code - those codes that are part of the complete traversal set that have no outbound relationships. |
Rationale | This is a common mechanism for value set definition in code systems that have parent-child or similar relationships. |
MIF | mif-vocabulary-model.xsd/ContentDefinition/codeBasedContent |
Requirement | Content needs to be able to be defined based on properties held by the concepts. This might be inclusion of concepts that have specified values for certain properties or exclusion of concepts with specified values for certain properties. The values may either be strings or REGEX expressions |
Rationale | Examples include filtering on LOINC properties such as Class or B/R/O, or supplemental properties such as "orderable". For more complex code system properties, matches may need to be on such things as "starts with 'b'". |
MIF | mif-vocabulary-model.xsd/ContentDefinition/propertyBasedContent |
Requirement | Content needs to be able to be defined based on the actual string value of the codes for the property. |
Rationale | Some code systems, such as the ICD code systems embed semantics in the codes themselves rather than using properties or relationships. As a result, the only way to define expression based content filters is with filters on the code. |
Methodology | Two types of expression languages are supported - regex and Terminology Query Language (TQL) |
MIF | mif-vocabulary-model.xsd/ContentDefinition/codeFilterContent |
Requirement | Content needs to be able to be defined by referencing existing value sets |
Rationale | Some value sets are most efficiently composed by referencing other existing value sets. This supports re-use and simplifies maintenance. |
MIF | mif-vocabulary-model.xsd/ContentDefinition/codeFilterContent |
Requirement | In some cases, content needs to be defined using free text description. |
Rationale | Some content definitions cannot be defined by formal mechanisms due to limitations of the code system. In other casesthe initial requirement is captured as text and is only later formally represented. |
MIF | mif-vocabulary-model.xsd/ContentDefinition/nonComputableContent |
Qualifiers
Requirement | Valueset content that draws from code systems that support post-coordination needs to be able to indicate what types of qualifier relationships are allowed. |
Rationale | Post-coordination is complex and few systems can support (or want) all of the expressivity that post-coordination might allow. Therefore it is important to define what types of relationships can be used. |
MIF | mif-vocabulary-model.xsd/ValueSetVersion/allowedQualifiers |
Requirement | When identifying qualifiers, there's a need to identify what types of concepts are allowed as the target for a particular relationship. |
Rationale | When allowing qualifiers, it's not always sufficient to say "qualifier relationships of this type". For example, limiting which types of body sites can be communicated. |
MIF | mif-vocabulary-model.xsd/ValueSetVersion/allowedQualifiers/targetConcepts |
Requirement | When defining support for qualifier relationships, the value set must be able to assert conformance and cardinality constraints. |
Rationale | Concepts can have multiple qualifiers of the same type. However, systems may not be designed to handle multiple repetitions or may have limits on how many repetitions they can manage. In some cases, there might be a need for a certain minimum number of repetitions to be present. Similarly, the expectation for support of a particular qualifier might be optional, required, or even not permitted. And some systems might declare that they'll tolerate the presence of a given qualifier but will ignore it if present. |
MIF |
|
Requirement | Valueset content that draws from code systems that support post-coordination needs to indicate whether the default assumption is that qualifiers not specifically referenced are allowed or not permitted. |
Rationale | It is not always convenient to explicitly list every qualifier association that is possible for a particular code system, but it is not safe to assume that non-mentioned qualifiers are allowed. |
MIF | mif-vocabulary-model.xsd/ValueSetVersion/@areBaseQualifiersUnlimited |
Requirement | Valueset content that draws from code systems that support post-coordination and where concepts can be represented in both post-coordinated and pre-coordinated form need to indicate whether the preference for representing a concept is using the pre-coordinated or the post-coordinated form. |
Rationale | While some systems might easily support both types of representations, for other types of communications it will be easier if there is only a single way a particular concept is represented in an exchange. |
MIF | mif-vocabulary-model.xsd/ValueSetVersion/@postCoordinationPreference |