This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Requirements-Value Set Conformance"
Jump to navigation
Jump to search
EdSeidewitz (talk | contribs) |
|||
(6 intermediate revisions by one other user not shown) | |||
Line 4: | Line 4: | ||
{| border="2" cellspacing="0" cellpadding="3" width="600" | {| border="2" cellspacing="0" cellpadding="3" width="600" | ||
| '''Requirement''' | | '''Requirement''' | ||
− | | When identifying the set of codes associated with an element, there's a need to identify the total set of codes that are potentially allowed to be sent, regardless of whether all implementations will support all codes. | + | | When identifying the set of codes associated with an element, there's a need to identify the total set of codes ([[Requirements-Value Sets|Value Set]]) that are potentially allowed to be sent, regardless of whether all implementations will support all codes. |
|- | |- | ||
| ''Rationale'' | | ''Rationale'' | ||
Line 12: | Line 12: | ||
| ''MIF'' | | ''MIF'' | ||
| mif-core-base.xsd/VocabularyValueSetBinding/baseValueSet | | mif-core-base.xsd/VocabularyValueSetBinding/baseValueSet | ||
+ | |- | ||
+ | | ''OMG Mapping'' | ||
+ | | {{OMG-MIF-In UML}} Use the UML representation of the value set (either an enumeration or a class) as the type. | ||
+ | |} | ||
+ | |||
+ | |||
+ | {| border="2" cellspacing="0" cellpadding="3" width="600" | ||
+ | | '''Requirement''' | ||
+ | | When defining a set of codes for use in a specification, there's a need to differentiate whether the set of codes ([[Requirements-Value Sets|Value Set]]) is considered exhaustive (i.e. all codes must come from the specified value set) or as the base preferred set that must be used if an appropriate code is available. | ||
+ | |- | ||
+ | | ''Rationale'' | ||
+ | | | ||
+ | * Not all code systems or sets of code systems will necessarily fully encompass a domain space | ||
+ | * New concepts can arise that need to be communicated before a code is available in a standardized code system | ||
+ | |- | ||
+ | | ''Methodology'' | ||
+ | | | ||
+ | Coding Strength is a conformance assertion that indicates whether the base set of codes referenced represents the complete set of codes allowed to be used or whether the set of codes can be supplemented with local codes or original text in circumstances where the concept can't be appropriately represented with one of the codes in the approved set. | ||
+ | |||
+ | Allowed values are: | ||
+ | *CWE (Coded with Extensibility), indicating that local codes or original text is allowed. | ||
+ | *CNE (Coded, no Extensibility), indicating that only the specified set of codes may be used | ||
+ | |- | ||
+ | |''MIF'' | ||
+ | | mif-core-staticBase.xsd/CompleteVocabularyValueSetRef/@codingStrength | ||
+ | |- | ||
+ | | ''OMG Mapping'' | ||
+ | | {{OMG-MIF-HL7 Profile}} Tagged value on a stereotype on a property typed by a value set. | ||
|} | |} | ||
Line 17: | Line 45: | ||
{| border="2" cellspacing="0" cellpadding="3" width="600" | {| border="2" cellspacing="0" cellpadding="3" width="600" | ||
| '''Requirement''' | | '''Requirement''' | ||
− | | When identifying the set of codes associated with an element, there's a need to know what subset of those must be fully supported by implementations. | + | | When identifying the set of codes associated with an element, there's a need to know what subset of those ([[Requirements-Value Sets|Value Set]]) must be fully supported by implementations. |
|- | |- | ||
| ''Rationale'' | | ''Rationale'' | ||
Line 25: | Line 53: | ||
| ''MIF'' | | ''MIF'' | ||
| mif-core-base.xsd/VocabularyValueSetBinding/minimumValueSet | | mif-core-base.xsd/VocabularyValueSetBinding/minimumValueSet | ||
+ | |- | ||
+ | | ''OMG Mapping'' | ||
+ | | {{OMG-MIF-In UML}} Additional constraint on a property typed by a value set. | ||
|} | |} | ||
Line 38: | Line 69: | ||
| ''MIF'' | | ''MIF'' | ||
| mif-core-base.xsd/VocabularyValueSetBinding/ignoredValueSet | | mif-core-base.xsd/VocabularyValueSetBinding/ignoredValueSet | ||
+ | |- | ||
+ | | ''OMG Mapping'' | ||
+ | | {{OMG-MIF-In UML}} Additional constraint on a property typed by a value set. | ||
|} | |} | ||
Line 43: | Line 77: | ||
{| border="2" cellspacing="0" cellpadding="3" width="600" | {| border="2" cellspacing="0" cellpadding="3" width="600" | ||
| '''Requirement''' | | '''Requirement''' | ||
− | | | + | | There is a need to define re-usable "sets" of codes that can be referenced as part of bindings |
|- | |- | ||
| ''Rationale'' | | ''Rationale'' | ||
| | | | ||
− | * | + | * Coded data is a critical aspect of healthcare interoperability because coded data allows for better analysis, searching and decision support |
− | * | + | * A set of codes defined for one use may often be valuable for other uses. Given the maintenance effort required to define sets of codes, re-use of previously defined code sets is essential. |
|- | |- | ||
| ''Methodology'' | | ''Methodology'' | ||
− | | [[Requirements- | + | | [[Requirements-Value Sets|Value Set]] |
+ | |} | ||
+ | |||
+ | |||
+ | {| border="2" cellspacing="0" cellpadding="3" width="600" | ||
+ | | '''Requirement''' | ||
+ | | When defining support for a particular set of codes, there's a need for an implementer to know how frequently they're expected to keep up-to-date with changes to the set of codes | ||
+ | |- | ||
+ | | ''Rationale'' | ||
+ | | | ||
+ | * Healthcare is a dynamic environment. Code systems evolve as do value set definitions | ||
+ | * There is a cost to updating the codes supported by an implementation | ||
+ | * Failure to update an implementation frequently enough can lead to interoperability issues | ||
+ | |- | ||
+ | | ''Methodology'' | ||
+ | | There are two categories of coded attributes: | ||
+ | * Frozen at publication: Implementations are not expected to support changes to the underlying code systems and value sets from what is declared in a given version of a specification unless they choose to support a newer version of the specification. Hard-coding of terminology is possible. | ||
+ | * Dynamic: Implementations are expected to reference the newest set of codes as published by the code system using the value set definition declared. Hard-coding of terminology is not possible. | ||
+ | |- | ||
+ | | ''MIF'' | ||
+ | | mif-core-base.xsd/VocabularyValueSetBinding/@revisionFrequency | ||
+ | |- | ||
+ | | ''OMG Mapping'' | ||
+ | | {{OMG-MIF-In UML}} Additional constraint on a property typed by a value set. | ||
+ | |} | ||
+ | |||
+ | |||
+ | {| border="2" cellspacing="0" cellpadding="3" width="600" | ||
+ | | '''Requirement''' | ||
+ | | When binding to value sets whose definition can change and/or which references code systems whose content can change, there's sometimes a need to lock the binding to a static set of codes "as the value set was" at a particular time. | ||
+ | |- | ||
+ | | ''Rationale'' | ||
+ | | Using valuesets whose resolution to an enumeration of codes is constantly changing value sets makes things more difficult for implementers and can cause interoperability issues as two applications rarely have exactly the same version of the value set and code systems at the same time. While sometimes this difficult is unavoidable, if it can be avoided, that is useful. Freezing the enumeration as of a particular time is the easiest way to fix the enumeration without having to explicitly list all of the codes (when there may be 100s or 1000s). | ||
+ | |- | ||
+ | | ''Methodology'' | ||
+ | | When a static binding date is specified, the value set versions and code system versions are set to be the "most recent available" as of that date, unless they are already hard-coded in the definition of the value set. | ||
+ | |- | ||
+ | | ''MIF'' | ||
+ | | mif-core-base.xsd/VocabularyValueSetBinding/@staticBindingDate | ||
+ | |- | ||
+ | | ''OMG Mapping'' | ||
+ | | {{OMG-MIF-In UML}} Additional constraint on a property typed by a value set. | ||
|} | |} |
Latest revision as of 18:03, 21 July 2010
When defining the set of codes allowed for a given element there's actually more to do than just referencing the set of codes. There's also a question of defining the conformance expectations for how the referenced set of codes are expected to be used. I.e. Are implementations restricted to the set of codes specified, must they support all of the codes, etc.
Requirement | When identifying the set of codes associated with an element, there's a need to identify the total set of codes (Value Set) that are potentially allowed to be sent, regardless of whether all implementations will support all codes. |
Rationale |
|
MIF | mif-core-base.xsd/VocabularyValueSetBinding/baseValueSet |
OMG Mapping | Use the UML representation of the value set (either an enumeration or a class) as the type. |
Requirement | When defining a set of codes for use in a specification, there's a need to differentiate whether the set of codes (Value Set) is considered exhaustive (i.e. all codes must come from the specified value set) or as the base preferred set that must be used if an appropriate code is available. |
Rationale |
|
Methodology |
Coding Strength is a conformance assertion that indicates whether the base set of codes referenced represents the complete set of codes allowed to be used or whether the set of codes can be supplemented with local codes or original text in circumstances where the concept can't be appropriately represented with one of the codes in the approved set. Allowed values are:
|
MIF | mif-core-staticBase.xsd/CompleteVocabularyValueSetRef/@codingStrength |
OMG Mapping | Tagged value on a stereotype on a property typed by a value set. |
Requirement | When identifying the set of codes associated with an element, there's a need to know what subset of those (Value Set) must be fully supported by implementations. |
Rationale |
|
MIF | mif-core-base.xsd/VocabularyValueSetBinding/minimumValueSet |
OMG Mapping | Additional constraint on a property typed by a value set. |
Requirement | When defining a constraint on an existing set of vocabulary, there's a need to differentiate between codes that are not supported (those outside the base value set) and will likely raise an error if transmitted and those that simply won't be processed but will not result in an error. |
Rationale |
|
MIF | mif-core-base.xsd/VocabularyValueSetBinding/ignoredValueSet |
OMG Mapping | Additional constraint on a property typed by a value set. |
Requirement | There is a need to define re-usable "sets" of codes that can be referenced as part of bindings |
Rationale |
|
Methodology | Value Set |
Requirement | When defining support for a particular set of codes, there's a need for an implementer to know how frequently they're expected to keep up-to-date with changes to the set of codes |
Rationale |
|
Methodology | There are two categories of coded attributes:
|
MIF | mif-core-base.xsd/VocabularyValueSetBinding/@revisionFrequency |
OMG Mapping | Additional constraint on a property typed by a value set. |
Requirement | When binding to value sets whose definition can change and/or which references code systems whose content can change, there's sometimes a need to lock the binding to a static set of codes "as the value set was" at a particular time. |
Rationale | Using valuesets whose resolution to an enumeration of codes is constantly changing value sets makes things more difficult for implementers and can cause interoperability issues as two applications rarely have exactly the same version of the value set and code systems at the same time. While sometimes this difficult is unavoidable, if it can be avoided, that is useful. Freezing the enumeration as of a particular time is the easiest way to fix the enumeration without having to explicitly list all of the codes (when there may be 100s or 1000s). |
Methodology | When a static binding date is specified, the value set versions and code system versions are set to be the "most recent available" as of that date, unless they are already hard-coded in the definition of the value set. |
MIF | mif-core-base.xsd/VocabularyValueSetBinding/@staticBindingDate |
OMG Mapping | Additional constraint on a property typed by a value set. |