Common Design Patterns
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.
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)
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