This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Requirements-Concept Domains"
Jump to navigation
Jump to search
EdSeidewitz (talk | contribs) (Added OMG mapping tags.) |
|||
(3 intermediate revisions by one other user not shown) | |||
Line 17: | Line 17: | ||
| ''MIF'' | | ''MIF'' | ||
| mif-vocabulary-model.xsd/ConceptDomain/@name | | mif-vocabulary-model.xsd/ConceptDomain/@name | ||
+ | |- | ||
+ | | ''OMG'' | ||
+ | | {{OMG-MIF-In UML}} A concept domain can be represented as a class, which can have a name. | ||
|} | |} | ||
Line 36: | Line 39: | ||
* [[Requirements-Annotations#Design Comments|Design Comments]] | * [[Requirements-Annotations#Design Comments|Design Comments]] | ||
* [[Requirements-Annotations#Stability Remarks|Stability Remarks]] | * [[Requirements-Annotations#Stability Remarks|Stability Remarks]] | ||
− | |||
− | |||
* [[Requirements-Annotations#Other Annotation|Other Annotation]] | * [[Requirements-Annotations#Other Annotation|Other Annotation]] | ||
− | |||
− | |||
* [[Requirements-Annotations#Open Issue|Open Issue]] | * [[Requirements-Annotations#Open Issue|Open Issue]] | ||
− | |||
* [[Requirements-Annotations#Ballot Comment|Ballot Comment]] | * [[Requirements-Annotations#Ballot Comment|Ballot Comment]] | ||
* [[Requirements-Annotations#Change Request|Change Request]] | * [[Requirements-Annotations#Change Request|Change Request]] | ||
Line 58: | Line 56: | ||
| ''MIF'' | | ''MIF'' | ||
| mif-vocabulary-model.xsd/ConceptDomain/annotations/documentation/definition | | mif-vocabulary-model.xsd/ConceptDomain/annotations/documentation/definition | ||
+ | |- | ||
+ | | ''OMG'' | ||
+ | | {{OMG-MIF-In UML}} Presuming this definition is textual, it can be attached as a UML Comment. | ||
|} | |} | ||
Line 72: | Line 73: | ||
| ''MIF'' | | ''MIF'' | ||
| mif-vocabulary-model.xsd/ConceptDomain/@isBindable | | mif-vocabulary-model.xsd/ConceptDomain/@isBindable | ||
+ | |- | ||
+ | | ''OMG'' | ||
+ | | {{OMG-MIF-HL7 Profile}} A tagged value of a ConceptDomain stereotype. | ||
|} | |} | ||
Line 89: | Line 93: | ||
* mif-vocabulary-model.xsd/ConceptDomain/@specializesDomain | * mif-vocabulary-model.xsd/ConceptDomain/@specializesDomain | ||
* mif-vocabulary-model.xsd/ConceptDomain/@specializedByDomain | * mif-vocabulary-model.xsd/ConceptDomain/@specializedByDomain | ||
+ | |- | ||
+ | | ''OMG'' | ||
+ | | {{OMG-MIF-In UML}} UML generalization between concept domain classes. | ||
|} | |} | ||
Line 108: | Line 115: | ||
| ''MIF'' | | ''MIF'' | ||
| mif-vocabulary-model.xsd/ConceptDomain/@exampleConcept | | mif-vocabulary-model.xsd/ConceptDomain/@exampleConcept | ||
+ | |- | ||
+ | | ''OMG'' | ||
+ | | {{OMG-MIF-HL7 Profile}} Either a tagged value that points to example concepts or stereotyped dependencies that do so. | ||
|} | |} | ||
Line 113: | Line 123: | ||
{| border="2" cellspacing="0" cellpadding="3" width="600" | {| border="2" cellspacing="0" cellpadding="3" width="600" | ||
| '''Requirement''' | | '''Requirement''' | ||
− | | | + | | Concept domains sometimes need to be able to reference other terminology objects |
|- | |- | ||
| ''Rationale'' | | ''Rationale'' | ||
− | | | + | | When defining the concept sub-domains for ActCode, RoleCode, etc., we want to be able to identify the classCode that serves as the anchor for those concept domains. |
|- | |- | ||
| ''Methodology'' | | ''Methodology'' | ||
Line 123: | Line 133: | ||
| ''MIF'' | | ''MIF'' | ||
| mif-vocabulary-model.xsd/ConceptDomain/@property | | mif-vocabulary-model.xsd/ConceptDomain/@property | ||
+ | |- | ||
+ | | ''OMG'' | ||
+ | | {{OMG-MIF-In UML}} UML attributes on the concept domain class. | ||
+ | |} | ||
+ | |||
+ | |||
+ | {| border="2" cellspacing="0" cellpadding="3" width="600" | ||
+ | | '''Requirement''' | ||
+ | | Concept domains need to be able to track statuses over time. | ||
+ | |- | ||
+ | | ''Rationale'' | ||
+ | | Like other vocabulary objects, Concept domains can be draft, active, deprecated or even retired. In some cases, they even get resurrected. Users need to know what the status of a concept domain is right now as well as what it was at times in the past. | ||
+ | |- | ||
+ | | ''MIF'' | ||
+ | | mif-vocabulary-model.xsd/ConceptDomain/statusInfo | ||
+ | |- | ||
+ | | ''OMG'' | ||
+ | | {{OMG-MIF-Model Management}} This seems to be primarily a model management or tooling issue, though the information could also be provided using tagged values. | ||
|} | |} |
Latest revision as of 16:40, 1 September 2010
Concept Domains are named categories of concepts maintained by HL7. They are referenced by static models in circumstances where binding to a specific set of codes is not possible. Binding to codes might not be possible for a variety of reasons:
- The category of concepts is too broad to assign a set of codes to
- It is not possible to gain consensus on the set of codes
- The set of codes may need to vary based on different contexts
MIF: mif-vocabulary-model.xsd/ConceptDomain
Requirement | Concept domains must have a name |
Rationale | By definition, concept domains are "named categories", so a name is pretty essential . . . The name is what's used to reference the concept domains from models that need to constrain the set of allowed concepts. |
MIF | mif-vocabulary-model.xsd/ConceptDomain/@name |
OMG | A concept domain can be represented as a class, which can have a name. |
Requirement | Concept domains may have a number of different types of annotations |
Rationale | See rationales for individual annotations types |
Implementation |
Requirement | Concept domains must have a formal definition |
Rationale | The purpose of a concept domain is to provide a label to a category of concepts. A definition is essential to identify the category of concepts the concept domain represents. |
MIF | mif-vocabulary-model.xsd/ConceptDomain/annotations/documentation/definition |
OMG | Presuming this definition is textual, it can be attached as a UML Comment. |
Requirement | Concept domains must indicate whether they are bindable or not |
Rationale | Some concept domains are too generic for it to be appropriate to establish bindings for them of any sort. They are useful in high-level abstract models that are not intended to be implemented directly. For example "ActCode" which covers the concepts that describes types of acts for all possible acts (encounters, observations, procedures, billing, consent, etc.) cannot reasonably be bound to a value set. Instead it is a placeholder for refinement. Specializations of the ActCode domain, such as ActProcedureCode might reasonably be bound.
An indicator provides information about how a concept domain is expected to be used. It also acts a mechanism to prevent bindings from being created where they should not. |
MIF | mif-vocabulary-model.xsd/ConceptDomain/@isBindable |
OMG | A tagged value of a ConceptDomain stereotype. |
Requirement | Concept domains must be constrainable |
Rationale | HL7 methodology is dependent on the idea of constraint (see Constraint Derivation). A broad concept domain such as "All act types" in the RIM needs to be constrainable to narrower concept domains such as "All procedure codes" or even "All dental procedure codes" when creating models based on the RIM. |
Methodology | A concept domain can specialize other concept domains. |
MIF |
|
OMG | UML generalization between concept domain classes. |
Requirement | A concept domain needs to identify sample codes to give an idea of what types of codes might be bound to it. |
Rationale | Eventually, the concept domain needs to be bound. In addition, sample instances need to be constructed to document models and it helps to know some example concepts even if there aren't any specific codes bound. To ensure that we can validate that examples are present, it helps to have example concepts expressed explicitly rather than embedded as part of the definition. |
Methodology | Concept domains are required to have one of the following:
|
MIF | mif-vocabulary-model.xsd/ConceptDomain/@exampleConcept |
OMG | Either a tagged value that points to example concepts or stereotyped dependencies that do so. |
Requirement | Concept domains sometimes need to be able to reference other terminology objects |
Rationale | When defining the concept sub-domains for ActCode, RoleCode, etc., we want to be able to identify the classCode that serves as the anchor for those concept domains. |
Methodology | Concept domains have properties (name-value pairs) |
MIF | mif-vocabulary-model.xsd/ConceptDomain/@property |
OMG | UML attributes on the concept domain class. |
Requirement | Concept domains need to be able to track statuses over time. |
Rationale | Like other vocabulary objects, Concept domains can be draft, active, deprecated or even retired. In some cases, they even get resurrected. Users need to know what the status of a concept domain is right now as well as what it was at times in the past. |
MIF | mif-vocabulary-model.xsd/ConceptDomain/statusInfo |
OMG | This seems to be primarily a model management or tooling issue, though the information could also be provided using tagged values. |