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

Design Pattern: Administrative Observations vs. Explicit Modeling

From HL7Wiki
Jump to navigation Jump to search

Introduction

There was a harmonization proposal from PA to create observation codes for concepts such as "mothers maiden name", "preferred contact method", "preferred contact time", "shared secret", etc. There were concerns raised that these concepts were not appropriately handled as observation because they are explicitly modelable in the RIM, and in some cases, are already modeled explicitly in other domains. There was a concern that capturing these things as Observations was the start of a slippery path that would lead committees to move to using observations for anything that was particularly difficult or complex to model.

Issue

We need a recommendation on what circumstances it is reasonable to use observations vs. explicit models

Discussion

(From Jan. 2010 WGM - Mon. Q3)

Consideration: Before undertaking the analysis suggested below, be certain that you understand the context of the information element you are undertaking to model. For example: "mother's maiden name" as a "Shared secret". The answers you get will change depending on exactly what it is you're trying to model.

Note: What is a "grab bag"? It is a set of values (name/value pairs) that are not tightly controlled at design time, as to what information goes there.

Goal: Good-practice guidelines for model development in the context of a RIM. (Caveats or exceptions for constrained environments may be included.)

Goal: The fundamental requirement is that the element in question is clearly and unambiguously defined regardles of "how" it is modeled.

Rule: If constrained to using an Observation for one of several reaons (below), the "definition" of the observation should include an explicit RIM-based model of that observation. Look to Canadian and Australian implementation guide methods of documenting model paths and content.

Rule: Not knowing how to explicitly model something, or even certainty that the RIM cannot currently explicitly model something, is not itself a reason to use Observation. Any data element *can* be expressed using the RIM, though harmonization proposals may be necessary to enable this. Therefore use the criteria to determine what approach to use, and if explicit modeling is the resulting recommendation consult MnM and if necessary submit the necessary proposals to allow explicit modeling.

Basis for decisions:

  1. You may not be able to do full v3 modeling in environments that constrain the RIM. E.g. CDA, Clinical Statement
  2. Might there need to be additional attributes in future that would be included in the explicit model (favors explicit). E.g. dates, authors, other stuff.
  3. Consistency with other models. Particularly where there may be a need to share or resolve information across model structures. (If A choses a particular approach, and B is sharing, then B should choose same solution). (could favor either)
  4. Centrality of the concept to the model (closer to central...more likely explicit)
  5. Volume: A sparse matrix of information, with a single element in each, observations become more efficient (in terms of modeled information matchung actual instance content)
  6. Do you know all elements a priori, or might I need to extend in future, and thus could benefit from adding a new obseravtion when I find new need. Can't have explicit modeling if you don't know what data elements you're going to communicate.
  7. Balance in (or How "ugly" is) the model? - predicated on the premise that the tangential issues should not over whelm the primary content, or if interpretation of the explicit model is very difficult. E.g. "Do you need to walk 20 classes to represent 1 element?"
  8. How inter-related is the concept to other elements in the same model? If inter-related, be explicit.
  9. If widely adopted observation code systems (SNOMED, LOINC) include the full concept. Implementation as an observation is appropriate.

Remaining steps

  • Expand the above into coherent English
  • Organize the above into a hierarchical decision tree and distinguish those which are "firm" decision criteria from those that are subjective
  • Provide examples
  • Seek endorsement