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

Common Design Patterns

From HL7Wiki
Revision as of 01:46, 9 May 2008 by GrahameGrieve (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


This hot topic concerns the notion that there are a number of common design patterns that should be well known to the v3 model designers, and should be used where appropriate.

MnM needs a process to gather these patterns, publish them in one place, and have a process that draws the attention of the target model designers to the patterns.


Note: These patterns are highly controversial and are offered as examples to start debate, not to serve as exemplary patterns that should be used.

Identifier Pattern

Where’s identifier type?


  • We need multiple technical identifiers (different scopes, data model re-organizations)
  • We also need multiple human readable identifiers for some things
  • For these, we need to know what real world concept they match to
  • II is just a technical identifier

UML for the pattern (TODO: replace with a Entity/Role and Act/ActRelationship examples)



  • id should always DSET<II>
  • Objects only carry technical ids
    • No Business identifiers
    • No Unverified identifiers
  • If this is human identifiable, OtherIds
    • id : the II, human readable part in extension
    • idType : the type of the id from some terminology
    • status: (in use, mistake, deprecated)
    • validTime : when the id was valid (not that it is reassigned, but that it is not longer valid)

Measurement Pattern

do I really have to use stinkin’ UCUM?


  • PQ only handles value and unit (See PQ Triad in Abstract Data Types)
  • Unit is strictly a UCUM code not an estimated measure
  • The context of use must specify what is measured
  • The context of use must allow a notional qualifier (“kind of measurement” - scoop, cup, etc)

UML for the pattern (TODO: replace with an observation example)



  • Measurements should always be identified
  • Measurements should always have a code : CD
  • Unless the units are fixed, the measurement needs some “measurement QualifierCode”
  • Measurements should always have a methodCode (optional)

Relative Timing Pattern

Can I have a new EIVL code

i.e. ... “draw CBC 5 days after TreatmentStartDate”


  • Need to express that some event happens at a time relative to some other event
  • Need to identify the other event specifically (by identifier, or by pattern)
  • Need to specify how long between the two events as time, possibly with some form of uncertainty
  • Must be computable

UML for the pattern (TODO: replace with proper Act/ActRelationship examples)



  • the definition of pauseQuantity needs to be adjusted to allow this pattern