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
Line 26: Line 26:
 
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.
 
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.
+
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 a set of patterns that could be enforced on other models.
  
 
== Approved Patterns ==
 
== Approved Patterns ==

Revision as of 17:12, 14 July 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 a set of patterns that could be enforced on other models.

Approved Patterns

Patterns Under Development

Patterns

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

  • what is the pattern?
  • what problem(s) is the use of the pattern to apply to?
  • what kind of models or model portions does it apply to?
  • when is it appropriate? (and in what design paradigm?)
    • when must/should it be used?
    • when must/should it not be used?
  • where has it been used (example)?
  • where has it not been used (example)?
  • who maintains the pattern?
  • other variations of the pattern (ideally as references to other patterns