Requirements-CMETs

From HL7Wiki
Revision as of 18:01, 17 February 2010 by Danelson (talk | contribs)
Jump to navigation Jump to search
Requirement Model fragments that can be used by other model fragments (static models) are required. Expresses a common, useful, reuseable concepts expressed small model pieces (chunks)
Rationale Promotes Re-use by modelers; Common model enables domain knowledge to be used. Uniformly represents a concept for use by all interested committees
"Methodology" HDF methodology, metadata
MIF


Requirement Message type fragment that can be used by other message type fragments (static models). Expresses a common, useful, reuseable concepts expressed small model pieces (chunks)
Rationale Promotes Re-use by modelers; Common model enables domain knowledge to be used. Uniformly represents a concept for use by all interested committees
"Methodology" HDF methodology, metadata
MIF


Requirement May be referenced by both producing and other committees
Rationale Promotes Re-use by modelers; Common model enables domain knowledge to be used. Uniformly represents a concept for use by all interested committees
"Methodology" HDF methodology, metadata
MIF


Requirement A registry of CMETs should be accessible by static model designers
Rationale Promotes Re-use by providing a list of available CMETs to use, from a common library.
"Methodology" Metadata. Is an interface specification that is bound to a static mode
MIF


Requirement Provides robust binding to models both statically and dynamically (design or runtime). This must provide both early and late binding to model, including late binding to default/most recent model. Ability to choose between multiple class types in final message type is deferred until runtime
Rationale Provides encapsulation, some degree of polymorphism, model independence.
"Methodology" Metadata.
MIF


Requirement Ability of content of chunks to change without update/affecting referencing model. supports localization. provides abstractions. Allows model to be built with abstractions (literally).
Rationale Users need to be able to develop sections of models that conform to local and realm-specific uses and regulations. Larger domain models can be constructed independently. Design of model components isolated - encapsulation
"Methodology" metadata, use of interfaces and stubs.
MIF


Requirement Is available in local scope. Is available to multiple NE releases and models.
Rationale Users need to be able to choose from available off-the-shelf components
"Methodology" Interface file: realm-name-id, Binding by name, not identity. interface files that relate model to release, Indirection resolved by publishing process
MIF


Requirement Derived from a single DMIM. Content is direct subset of class clones and attributes defined in that DMIM - does not span DMIMs
Rationale Has model derivation using identical process to any static model. Keeps both users and modelers happy.
"Methodology" HDF, metadata
MIF


Requirement Has Semantic categories: attribution (level of property constraint), generalization (subsumption). Are derived by iterative refinement of a domain model
Rationale Has model derivation using identical process to any static model. Keeps both users and modelers happy.
"Methodology" metadata
MIF


Requirement Always at least one variant (univeral)
Rationale Equivalent to an unconstrained RMIM
"Methodology" metadata
MIF


Requirement Should be used to carry reference information only
Rationale Guidelines for use
"Methodology" publications
MIF
Requirement Model fragments that can be used by other model fragments (static models) are required. Expresses a common, useful, reuseable concepts expressed small model pieces (chunks)
Rationale Promotes Re-use by modelers; Common model enables domain knowledge to be used. Uniformly represents a concept for use by all interested committees
"Methodology" HDF methodology, metadata
MIF


Requirement Message type fragment that can be used by other message type fragments (static models). Expresses a common, useful, reuseable concepts expressed small model pieces (chunks)
Rationale Promotes Re-use by modelers; Common model enables domain knowledge to be used. Uniformly represents a concept for use by all interested committees
"Methodology" HDF methodology, metadata
MIF


Requirement May be referenced by both producing and other committees
Rationale Promotes Re-use by modelers; Common model enables domain knowledge to be used. Uniformly represents a concept for use by all interested committees
"Methodology" HDF methodology, metadata
MIF


Requirement A registry of CMETs should be accessible by static model designers
Rationale Promotes Re-use by providing a list of available CMETs to use, from a common library.
"Methodology" Metadata. Is an interface specification that is bound to a static mode
MIF


Requirement Provides robust binding to models both statically and dynamically (design or runtime). This must provide both early and late binding to model, including late binding to default/most recent model. Ability to choose between multiple class types in final message type is deferred until runtime
Rationale Provides encapsulation, some degree of polymorphism, model independence.
"Methodology" Metadata.
MIF


Requirement Ability of content of chunks to change without update/affecting referencing model. supports localization. provides abstractions. Allows model to be built with abstractions (literally).
Rationale Users need to be able to develop sections of models that conform to local and realm-specific uses and regulations. Larger domain models can be constructed independently. Design of model components isolated - encapsulation
"Methodology" metadata, use of interfaces and stubs.
MIF


Requirement Is available in local scope. Is available to multiple NE releases and models.
Rationale Users need to be able to choose from available off-the-shelf components
"Methodology" Interface file: realm-name-id, Binding by name, not identity. interface files that relate model to release, Indirection resolved by publishing process
MIF


Requirement Derived from a single DMIM. Content is direct subset of class clones and attributes defined in that DMIM - does not span DMIMs
Rationale Has model derivation using identical process to any static model. Keeps both users and modelers happy.
"Methodology" HDF, metadata
MIF


Requirement Has Semantic categories: attribution (level of property constraint), generalization (subsumption). Are derived by iterative refinement of a domain model
Rationale Has model derivation using identical process to any static model. Keeps both users and modelers happy.
"Methodology" metadata
MIF


Requirement Should be used to identify the focal class that is the target of a trigger event.
Rationale Guidelines for use
"Methodology" publications
MIF


Requirement Should not carry update values.
Rationale Guidelines for use
"Methodology" publications
MIF


Requirement Should not be used to simplify a diagram/model
Rationale Guidelines for use
"Methodology" publications
MIF


Requirement Cannot be individually constrained.
Rationale Guidelines for use
"Methodology" publications
"Note" This is a deficiency.



Requirement Behaves as a macro substitution..
Rationale Guidelines for use
"Methodology" metadata, publications
"MIF"