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

1. The technical id (Thing.id/anEntity.id/anAct.id) should always SET<II> (or DSET<II> in Data types R2)

The reason for making this a set rather than a singleton is similar to the argument for not using CV: fixing it to a single II will prevent organisations from ever re-organising their persistent identification mechanisms. If there is some case where this clearly doesn't apply, then SET<> is not needed. HL7 provides no clarification whether all or just one of the ids must be matched, but for real world usage, it should just be one. This should be clarified in narrative.

2. The technical identifiers do not include any unverified ids

This is fairly straight forward: unverified IDs are always human identifiers not technical identifiers, as their provenance (usually a user typing in the system directly) can never be ascertained. Note that the notion of unverified ids is introduced in R2.

3. The technical identifiers should not include business ids

In general, ids are labelled as business ids because they are re-used to identify multiple objects of different classes that are linked by a common business process. An example is the notion of an order number - it may be associated with several different acts in different moods (there might be another pattern there). Because the scope in which the technical identifiers are used for matching is not defined (and is supposed to be globally unique), it is potentially dangerous to allow business identifiers as technical identifiers. If it is done, the scope of the matching of the technical identifiers should be clearly identified in the narrative, and the nature of the use of the business identifiers should be clearly identified.

4. If the object carries human readable identifiers, the otherIds class should be used

In the context of RIM modeling, this means a Role or an ActRelationship pattern as shown above. Human readable identifiers always carry meaning, and the meaning should generally be conveyed. Inherent in this pattern is that some identifiers may be carried twice - once as a technical id and once as a human readable identifier. Although there is technical duplication, this clearly defines the dual roles that the identifier plays.

If this pattern is not used, implementors will be forced to use a variety of dirty tricks to convey the type of the identifier, which is generally necessary in an implementation environment.

5. The otherIds class must have a single identifier

This identifier is that human readable identifier. Generally it would be expected to have an extension in the II. Duplicate identifiers are not required and would be confusing.

6. The otherIds class must have a Id type (somewhere in it's associations)

So the users can mark up the type. There's some doubt about quite what the best form of the type attribute is. In some cases the type is not very useful and the identifier of the provider of the identifier is required. Comment required

7. The otherIds class should have a status and a validTime

The notion is not that this id will be reused for another object (that would be BAD), but that the id has a limited period of validity (perhaps there was a duplicate record, and it's now retired). This is not required but is a relatively harmless addition to an actual model.

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