Design pattern: Observation grab bags

May 2009 WGM

Agreed to continue the treatment of this as part of the Design Patterns open issue. G Grieve, will move this and combine with Design Patterns open issues.

Issue

From time to time, data models will make the use of generic Observation classes as "name/value pair" constructs to allow the capture of "miscellaneous" or "other" data elements which may not be easily expressed within the framework of the base data model. There need to be guidelines on when it is appropriate to use such classes, what sorts of constraints should be placed on their use when they are used, and when it is more appropriate to model data explicitly.

The tendency to use name/value pairs has been described as pertinent information.

Discussion

Premises

1. It is always possible to express any data element explicitly using the RIM. In the worst case, the RIM can adjusted via harmonization to provide the necessary support.

2. It is equally possible to express any data model as a set of related Observations where all semantics are expressed through Observation.code and Observation.value

The extreme of approach 1 leads to in-efficient implementations, extremely large, complex models and unhappy implementers.

The extreme of approach 2 leads to a data model that takes little or no advantage of the RIM and results in substantially reduced likelihood of interoperability and increased effort to map between implementations

Considerations

• All other things being equal, explicit RIM modeling improves chances for interoperability and is therefore preferable
• Explicit modeling elements using the RIM inevitably means a loss of some efficiency. An "observation-based" approach should not be selected solely because a conveying a desired data element requires walking through 4 or 5 'empty' classes to reach it.
• The "inefficiency" argument associated with explicit modeling will be significantly reduced by a forthcoming ITS which allows for serialization of a collapsed model that avoids the need to communicate most, if not all empty classes.
• Messages which include 'generic' observation classes with broadly defined vocabulary domains will find that those classes become tempting targets for localized extension of messages, rather than using more explicit model-based localization approaches.
• As a result, it is better to create tighter Observation classes that ensure that only information related to the "desired" grab bag area can be included. For example, a domain name such as "FinancialAdjustmentModifierTypes" is better than a domain name "RelatedInformationTypes".
• Note that explicit modeling is not a panacea - modeling can be done poorly, structural vocabulary can be defined incorrectly or in a confusing manner, etc.
• Factors which tend towards explicit modeling:
  • attributes associated with explicit general business rules or which need to be available to low level processes such as security, audit, look-ups and preliminary screening
  • data requirements which are well known and static
  • data requirements which are consistent in interpretation and requirements across jurisdictions (note that it doesn't mean all jurisdictions must support the element - that's managed through optionality. What matters is that if an element is supported, jurisdictions typically need to express the same sort of information
  • data elements that are likely to need to appear as explicitly positioned and labeled elements in a user interface (as opposed to in a generic list of miscellaneous elements)
  • situations where the attributes of "Observation" other than 'code' and 'value' are either nonsensical or are extremely unlikely to ever be relevant
  • situations where there is a clear way to model the data element according to the RIM or where the data concept is already explicitly modeled in other domain models. (Note that this criteria requires a degree of modeling skill and knowledge of other domains. Modelers are encouraged to bring situations where they're not sure how to model a given concept forward to MnM.)
  • data with complex relationships that need to be exposed or where expressing a concept as an observation would require complex post/pre-coordinated codes
• Factors which tend towards the use of general observations:
  • requirements which cannot be nailed down at the time of design but which are expected to appear or evolve rapidly during a systems lifetime
  • requirements where wide variation in requirements is expected across jurisdictions
  • situations where the data can be handled generically by the receiver. Works best if the receiver can safely ignore repetitions it doesn't understand
  • situations where the data will tend to be displayed in a list with other repetitions of the observation rather than each repetition being assigned to explicitly labeled and positioned fields
  • elements which are not currently supported by the RIM, are extremely domain-specific and are unlikely to make sense, even from a generic perspective, in any other domain. (Note that this situation is quite unusual and it's usually best to bring the concept to MnM for evaluation before assuming that "no-one could ever use anything like this".)
  • data elements where the machinery of "Observation" (e.g. effectiveTime, author, methodCode, etc.) makes sense and is required by the use-case or can be reasonably be expected to be needed in the future
  • data that would be typically modeled as an observation if it were conveyed as a stand-alone message is appropriately modeled as an observation in other models
  • data that are simple and where the elements in the collection tend to be independent of one another
• As a fundamental guideline, there shouldn't be more than 2 or 3 grab bags in a given model, and even more than one grab bag should be evaluated cautiously.

Definition

I think we need a tighter definition of when an observation is used in this manner. I think the issue we are talking about here is when an observation merely modifies its parent (the source end of a COMP relationship) and not when it can stand on its own or makes sense on its own [Lee Coller]

[Lee Coller]Propose the following characteristics identify obs grab bags:

• Observation contains only the following attributes:
  • classCode <=OBS
  • moodCode = EVT
  • code - left unconstrained or is given a broad or vague definition
  • text - could be in place of value
  • value
    • Usually constrained to a CE/CV
• Target end of a COMP or PERT relationship or Navigated from a role
• Provides additional attributes about source act or role

Need to define the relationship between the grab bag and the thing it modifies. SubjectOf Relationship is usually most appropriate (observation is 'about' the related thing). Pertinent information may sometimes be appropriate (observation 'is somehow related' to the related thing)

Examples

In order to bring this to closure, or even to have effective discussion on it, we need a set of examples -- with some candidate "good practice" and candidate "bad practice", ideally from an online version of the ballot.

Action - Modelers are asked to identify candidate models they see issues (where grab-bags are used inappropriately or perhaps where grab-bags would be more appropriate or even where we have RIM attributes which would be better handled as observations). We will then evaluate the models against the criteria and use them to refine the criteria.

[Lee Coller]Have identified the following examples from CMETs (I make no claim as to whether any of these are inappropriate):

• COCT_RM930000UV (A_GeneticLocus)
  • GeneticLoci - hard to say if this is an appropriate grab-bag without business knowledge. The fact we're missing vocab definitions is problematic
  • AssociatedProperty
• COCT_RM290004UV (A_BillableClinicalService encounter)
  • BillableModifier - Not clear why this isn't sent as a qualifier within the code CD. Should use code + value, where code might just be assertion or something equivalent. However, this meets requirements for grab-bag
• COCT_RM610000UV (A_BillableSocialService universal)
  • LivingArrangementObservation (may not be a real example) - not a grab bag because it has many attributes
  • BillableModifier - see A_BillableClinicalService encounter
• COCT_RM510000UV (A_Coverage universal)
  • EligibilityStatusObservation (also includes effectiveTime) - not a grab bag - has effectiveTime
  • PolicyOrProgramLimit - not a grab bag - has effectiveTime
• COCT_RM120000UV (A_Observation)
  • Severity (0..1 relationship) - not a grab bag - code is tightly constrained
• COCT_RM830120UV (A_ReferencedDicomCompositeObject)
  • PurposeOfReference - Domain choice isn't constrained enough, not sure why not using reasonCode. Not a grab bag because we don't have name-value pairs. (Use of code not in alignement with term info.
• COCT_RM220200UV (R_AdministerableMedication)
  • Policy - code domains aren't properly defined, not sure why this is an observation
  • ObservationGoal - code domains aren't properly defined. Not a grab bag as this is clearly an observation as stand-alone
• COCT_RM010000UV (A_Encounter)
  • ObservationEvent02 (valuables observation, no code) - not a grab bag because no name-value pair. Model desparately needs a code to say this is a "valuable location" observation
• COCT_RM970000UV (A_ResearchSubjectEnrollment)
  • StudyInformation - domains not defined, not a grab bag because we're capturing effectiveTime
• COCT_RM080200UV (R_Specimen lite)
  • SpecimenObservationEvent - Significant issue of the use of SPCOBS and OBS classCodes to distinguish who the performer of the observation was. Particularly as SPCOBS is a specialization of OBS and the code domains are identical. From a modeling perspective, there's no way to interpret the semantics of the classes in the choice differently. However, from a grab-bag perspective, the use seems appropriate here.
  • AutomationSpecimenObservationEvent

Resolution

<Awaiting discussion on a conference call or WGM session>