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

Difference between revisions of "Information Model Design Patterns"

From HL7Wiki
Jump to navigation Jump to search
m (Added 'Design Patterns' category)
 
(17 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
[[Category: Design Patterns]]
 
= Design Patterns for HL7 Models =
 
= Design Patterns for HL7 Models =
  
 
This page documents a series of design patterns that provide guidance for modelers producing models for HL7 publications.  
 
This page documents a series of design patterns that provide guidance for modelers producing models for HL7 publications.  
  
The design patterns may apply to  
+
The design patterns '''may''' apply to  
 
* RIM-derived Information Models
 
* RIM-derived Information Models
* Behavioral Models following the Behavioral Framework
+
* Behavioral Models following the Behavioral Framework  
* UML based Logical Model Class Diagrams
+
**In future as SAIF work progresses although templates may obviate the need for these.
 +
* UML based Logical Model Class Diagrams  
  
 
Notes:
 
Notes:
* All RIM modellers should be aware of design patterns.
+
* All modellers deriving information models from the RIM should be aware of design patterns.
* Design patterns are subject to harmonization.  
+
* Design patterns are subject to harmonization.
 +
** To be "official" must be approved in Harmonization
 +
** To be basis ''prima facia'' for negative voting, should have been approved.
 
* Checking for the correct use of patterns is part of full ballot quality criteria checking.  
 
* Checking for the correct use of patterns is part of full ballot quality criteria checking.  
 
* Balloters are welcome to comment in ballot about whether patterns are followed.
 
* Balloters are welcome to comment in ballot about whether patterns are followed.
* Committee ballot decisions with respect to design patterns can be appealed to MnM. Final decision rests with TSC chair.
+
* Committee ballot decisions with respect to design patterns can be appealed to MnM.  
 +
** Final decision rests with TSC.
 +
* Include a document in ballot sites and elsewhere to publish adopted Design Patterns
  
 
== What is a design pattern? ==
 
== What is a design pattern? ==
  
A pattern provides guidance for a specific aspect of how to use the RIM to solve particular problems. The pattern is documented with example models, but these are not intended to be models from which working models are derived.  
+
A RIM Design Pattern provides guidance for a specific aspect of how to use the RIM to solve particular problems. The pattern is documented with example models, but these are not intended to be models from which working models are derived.
  
More substantial domain models such as Clinical Statement are sometimes described as design patterns, but are not included in this category.
+
Patterns should be granular and focused on specific, well-defined data exchange use-cases with a rationale for the use of the pattern.  Most RIM patterns can be expressed with fewer than 10 classes and fewer than 10 attributes.
  
== Enforced Templates ==
+
More substantial domain models such as Clinical Statement are sometimes described as design patterns, but are not included in this category. 
 +
*Clinical statement as it stands is a "model" not a pattern.  Ideally it would be accompanied by or expressed as a set of patterns that could be enforced on other models.
 +
*Clinical statement "original enforcement rules" did not permit the use of the patterns in more general circumstances, rather than only as constraints.
 +
*A focus on limiting those things that can be bound to the model, such as limitations on Participations.
  
*[[:category:RIM Design Template|RIM Design Templates]]
+
M&M Will take an action to engage the key participants in Clinical Statement in the processes of defining, harmonizing, and publishing design patterns.
  
== Templates Under Development ==
+
== Approved Patterns ==
  
*[[:category:RIM Design Template Candidate|Candidate RIM Design Templates]]
+
*[[:category:Information Model Design Patterns - Approved|Approved Information Model Design Patterns]]
  
 +
== Patterns Under Development ==
  
== Template ==
+
*[[:category:Information Model Design Patterns - Candidate|Candidate Information Model Design Patterns]]
  
These sections should be found in the documentation of each pattern:
+
== Patterns ==
  
* what is the pattern?
+
These '''sections should be found''' in the documentation of each pattern:
* what kind of model does it apply to?
+
 
* why is it defined?
+
* Name: Descriptive label for the pattern
* when is it appropriate? (and in what design paradigm?)
+
* Effective Date: Date on which the pattern received final (ballot) approval.  (Leave blank for an initial submission.)
** when must/should it be used?
+
* Purpose: Why is this pattern needed and what does it accomplish?  What problem is it trying to solve?
** when must/should it not be used?
+
* Sponsor: Which Work Group has primary responsibility for the pattern and should be the first point of contact for proposed changes?
* where has it been used (example)?
+
* Diagram(s): Diagrams (generally incomplete HL7 RMIM-style diagrams) that show the key elements of the pattern (what connects to what, what constraints apply, etc.)
* where has it not been used (example)?
+
* Description: Explanation of the pattern and how it works
* who maintains the pattern?
+
* Applicable circumstances: Identifies the model circumstances in which the pattern applies.  Use "MAY" for optional and "SHALL" for mandatory
* other variations
+
* Non-applicable circumstances: Identifies the model circumstances in which the does not pattern applies.  Use "SHOULD NOT" for optional and "SHALL NOT" for mandatory
 +
* Examples: Reference to models (and locations within them) where the pattern has been used
 +
* Variations: Other variations of this pattern

Latest revision as of 07:05, 25 November 2011

Design Patterns for HL7 Models

This page documents a series of design patterns that provide guidance for modelers producing models for HL7 publications.

The design patterns may apply to

  • RIM-derived Information Models
  • Behavioral Models following the Behavioral Framework
    • In future as SAIF work progresses although templates may obviate the need for these.
  • UML based Logical Model Class Diagrams

Notes:

  • All modellers deriving information models from the RIM should be aware of design patterns.
  • Design patterns are subject to harmonization.
    • To be "official" must be approved in Harmonization
    • To be basis prima facia for negative voting, should have been approved.
  • Checking for the correct use of patterns is part of full ballot quality criteria checking.
  • Balloters are welcome to comment in ballot about whether patterns are followed.
  • Committee ballot decisions with respect to design patterns can be appealed to MnM.
    • Final decision rests with TSC.
  • Include a document in ballot sites and elsewhere to publish adopted Design Patterns

What is a design pattern?

A RIM Design Pattern provides guidance for a specific aspect of how to use the RIM to solve particular problems. The pattern is documented with example models, but these are not intended to be models from which working models are derived.

Patterns should be granular and focused on specific, well-defined data exchange use-cases with a rationale for the use of the pattern. Most RIM patterns can be expressed with fewer than 10 classes and fewer than 10 attributes.

More substantial domain models such as Clinical Statement are sometimes described as design patterns, but are not included in this category.

  • Clinical statement as it stands is a "model" not a pattern. Ideally it would be accompanied by or expressed as a set of patterns that could be enforced on other models.
  • Clinical statement "original enforcement rules" did not permit the use of the patterns in more general circumstances, rather than only as constraints.
  • A focus on limiting those things that can be bound to the model, such as limitations on Participations.

M&M Will take an action to engage the key participants in Clinical Statement in the processes of defining, harmonizing, and publishing design patterns.

Approved Patterns

Patterns Under Development

Patterns

These sections should be found in the documentation of each pattern:

  • Name: Descriptive label for the pattern
  • Effective Date: Date on which the pattern received final (ballot) approval. (Leave blank for an initial submission.)
  • Purpose: Why is this pattern needed and what does it accomplish? What problem is it trying to solve?
  • Sponsor: Which Work Group has primary responsibility for the pattern and should be the first point of contact for proposed changes?
  • Diagram(s): Diagrams (generally incomplete HL7 RMIM-style diagrams) that show the key elements of the pattern (what connects to what, what constraints apply, etc.)
  • Description: Explanation of the pattern and how it works
  • Applicable circumstances: Identifies the model circumstances in which the pattern applies. Use "MAY" for optional and "SHALL" for mandatory
  • Non-applicable circumstances: Identifies the model circumstances in which the does not pattern applies. Use "SHOULD NOT" for optional and "SHALL NOT" for mandatory
  • Examples: Reference to models (and locations within them) where the pattern has been used
  • Variations: Other variations of this pattern