This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Requirements-Concept Domains

From HL7Wiki
Revision as of 05:50, 16 July 2009 by Lmckenzi (talk | contribs)
Jump to navigation Jump to search

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

Requirement Concept domains may have a number of different types of annotations
Rationale See rationales for individual annotations types

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

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

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-vocabulary-model.xsd/ConceptDomain/@specializesDomain
  • mif-vocabulary-model.xsd/ConceptDomain/@specializedByDomain

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:
  • A binding to a value set in a universal binding realm
  • A binding to a value set in a representative binding realm
  • A binding to a value set in an example binding realm
  • Print names for at least three example codes
MIF mif-vocabulary-model.xsd/ConceptDomain/@exampleConcept

Requirement ???? (Waiting on Woody)
Rationale ????
Methodology Concept domains have properties (name-value pairs)
MIF mif-vocabulary-model.xsd/ConceptDomain/@property