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

Difference between revisions of "Requirements-CMETs"

From HL7Wiki
Jump to navigation Jump to search
Line 82: Line 82:
 
| ''MIF''  
 
| ''MIF''  
 
|
 
|
 +
|-
 +
|}
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''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''
 +
|
 +
|-
 +
|}
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''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''
 +
|
 +
|-
 +
|}
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''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''
 +
|
 +
|-
 +
|}
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''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''
 +
|
 +
|-
 +
|}
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Always at least one variant (univeral)
 +
|-
 +
| ''Rationale''
 +
| Equivalent to an unconstrained RMIM
 +
|-
 +
| "Methodology"
 +
| metadata
 +
|
 +
|-
 +
| ''MIF''
 +
|
 +
|-
 +
|}
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Should be used to carry reference information only
 +
|-
 +
| ''Rationale''
 +
| Guidelines for use
 +
|-
 +
| "Methodology"
 +
| publications
 +
|
 +
|-
 +
| ''MIF''
 +
|
 +
|-
 +
|}
 +
 +
{{V3 Methodology Requirements}}
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''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''
 +
|
 +
|-
 +
|}
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''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''
 +
|
 +
|-
 +
|}
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''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''
 +
|
 +
|-
 +
|}
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''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''
 +
|
 +
|-
 +
|}
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''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''
 +
|
 +
|-
 +
|}
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''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''
 +
|
 +
|-
 +
|}
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''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''
 +
|
 +
|-
 +
|}
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''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''
 +
|
 +
|-
 +
|}
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''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''
 +
|
 +
|-
 +
|}
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Should be used to identify the focal class that is the target of a trigger event.
 +
|-
 +
| ''Rationale''
 +
| Guidelines for use
 +
|-
 +
| "Methodology"
 +
| publications
 +
|
 +
|-
 +
| ''MIF''
 +
|
 +
|-
 +
|}
 +
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Should not carry update values.
 +
|-
 +
| ''Rationale''
 +
| Guidelines for use
 +
|-
 +
| "Methodology"
 +
| publications
 +
|
 +
|-
 +
| ''MIF''
 +
|
 +
|-
 +
|}
 +
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Should not be used to simplify a diagram/model
 +
|-
 +
| ''Rationale''
 +
| Guidelines for use
 +
|-
 +
| "Methodology"
 +
| publications
 +
|
 +
|-
 +
| ''MIF''
 +
|
 +
|-
 +
|}
 +
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Cannot be individually constrained.
 +
|-
 +
| ''Rationale''
 +
| Guidelines for use
 +
|-
 +
| "Methodology"
 +
| publications
 +
|
 +
|-
 +
| "Note"
 +
| This is a deficiency.
 +
|-
 +
|}
 +
 +
 +
 +
 +
{| border="2" cellspacing="0" cellpadding="3" width="600"
 +
| '''Requirement'''
 +
| Behaves as a macro substitution..
 +
|-
 +
| ''Rationale''
 +
| Guidelines for use
 +
|-
 +
| "Methodology"
 +
| metadata, publications
 +
|
 +
|-
 +
| "MIF"
 +
|
 
|-
 
|-
 
|}
 
|}

Revision as of 18:01, 17 February 2010

This page documents one or more V3 Methodology Requirements

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

This page documents one or more V3 Methodology Requirements

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"
Retrieved from "https://wiki.hl7.org/w/index.php?title=Requirements-CMETs&oldid=32951"