Common Design Patterns

Introduction

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.

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?

Requirements:

• 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 general pattern

Entity-Role Equivalent:

Act-ActRelationship Equivalent:

Notes:

• technical id should always DSET<II>
• Objects only carry technical ids
  • No Business identifiers
  • No Unverified identifiers
• If the object is human identifiable, OtherIds should be added
  • id : the II, human readable part in extension
  • idType : the type of the id from some terminology
  • status: (in use, mistake, deprecated etc)
  • 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?

Requirements:

• 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)

Notes:

• 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”

Requirements:

• 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)

Notes:

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