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
(New page: {{V3 Methodology Requirements}} Business names allow for one or more domain-specific and/or language-specific labels to be assigned to an element in additional to its formal HL7 English RI...)
 
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
{{V3 Methodology Requirements}}
 
{{V3 Methodology Requirements}}
−
Business names allow for one or more domain-specific and/or language-specific labels to be assigned to an element in additional to its formal HL7 English RIM-speak name.  E.g. Even in English, the HL7 term "SubstanceAdministrationRequest" might be known as "Prescription", "Med Order" or "Script" depending on the jurisdiction and context.
 
  
−
To ensure interoperability, it's essential that the names of common elements not vary across languages and common business terms. However, being able to include a language-specific or common business term as a supplement aids in understanding.
+
{| 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''
 +
|
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-In UML}} Inheritance and aggregation
 +
|}
 +
 
 +
 
 +
{| 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''
 +
|
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-In UML}} Inheritance and aggregation
 +
|}
 +
 
 +
 
 +
{| 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''
 +
|
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-In UML}} Inheritance and aggregation
 +
|}
 +
 
 +
 
 +
{| 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''
 +
|
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}} Add stereotype and place CMETs into a package
 +
|}
 +
 
 +
 
 +
{| 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''
 +
|
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-Not Supported}} This appears to be a Methodology issue not modeling
 +
|}
 +
 
 +
 
 +
{| 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''
 +
|
 +
|-
 +
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-Not Supported}} Translations to other languages will require specific tool support
 +
 
 +
|}
 +
 
  
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
{| border="2" cellspacing="0" cellpadding="3" width="600"
 
| '''Requirement'''  
 
| '''Requirement'''  
−
| Business labels must identify the language and context (or contexts) they apply to
+
| Is available in local scope. Is available to multiple NE releases and models.
 
|-
 
|-
 
| ''Rationale''  
 
| ''Rationale''  
−
| In some cases multiple business names may be present on a particular element.  When publishing an artifact for a particular language group or business context, you want to use the labels most appropriate for that language or context.
+
| 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''  
 
| ''MIF''  
 
|
 
|
−
* mif-core-base.xsd/BusinessName/realmNamespace/value
 
−
* mif-core-base.xsd/BusinessName/@lang
 
 
|-
 
|-
−
| ''MIF Issue''  
+
|-
 +
| ''OMG Mapping''
 +
| {{OMG-MIF-HL7 Profile}} Add stereotype and place CMETs into a package
 +
|}
 +
 
 +
 
 +
{| 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 Not Used}}
+
|-
−
mif-vocabulary-model.xsd/ConceptDomain: We don't presently maintain business names at the UV level, though at least one realm assigns them before publishing
+
| ''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''
 +
|
 +
|-
 +
|}
 +
 
 +
=Properties=
 +
{| 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"
 +
|
 +
|-
 
|}
 
|}

Latest revision as of 16:34, 11 August 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
OMG Mapping

In UML: This MIF requirement is already supported by the base UML specification (mapping details below)

Inheritance and aggregation


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
OMG Mapping

In UML: This MIF requirement is already supported by the base UML specification (mapping details below)

Inheritance and aggregation


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
OMG Mapping

In UML: This MIF requirement is already supported by the base UML specification (mapping details below)

Inheritance and aggregation


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
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

Add stereotype and place CMETs into a package


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
OMG Mapping

Not Supported: This MIF requirement is not supportable within existing OMG specifications.

This appears to be a Methodology issue not modeling


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
OMG Mapping

Not Supported: This MIF requirement is not supportable within existing OMG specifications.

Translations to other languages will require specific tool support


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
OMG Mapping

HL7 Profile: This MIF requirement would best be supported via an HL7-specific UML profile. Recommendations on profile elements to best support the extension within UML tools are listed below:

Add stereotype and place CMETs into a package


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

Properties

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=39901"