MnM Minutes Harmonization CC 20120315

Harmonization Conference Call 12:00PM Eastern Time (Date above)

Return to MnM Minutes

Agenda

• Management of vocabulary object properties for retirement, freezing, not maintaining, et cetera, and the management of retired objects in MIF packages
• Issues of Code Systems for Data Types that are close to being retired.
• Duplicate print names for concepts (within single code systems and/or across code systems)
• When a "representative" value set is deprecated, what should be done to prepare for the time to "pull the trigger" on retirement..
• Dealing with value sets based on changes to externally maintained code systems (examples in IETF, and so forth)

Attendees

Beeler; de Leon; Kreisler; Knight; James; van Hentenryck; McKenzie; Loyd; Knapp; Hendler; Hausam; Hamm; Klein; Huang

Management of vocabulary object properties

Examples of "state" for objects

• Retiring - Has been removed from common use. Retained for historical record.
• Freezing - Declare that at a point in time, there will be no further changes to the object. Persisted objects:
  • Concept domains;
  • Code Systems;
  • Concept codes (for internal);
  • Value Set definition;
    • isImmutable - the definition cannot be changed, but the expansion may change for an intentional value set
  • Binding
• Deprecation - Says that the object SHALL not be used for new normative artifacts (in some context like HL7) from the Deprecation date forward and that there is an intent to retire the object in the future until which time the object may be used, but user's should begin migration as soon as Deprecation occurs.

• Not being Maintained: What we are saying about some of the HL7-maintained code systems that such as ActCode, RoleCode, ObservationValue, (in particular)?
  • Suggest that what we are really saying is that we will continue to seek ways to express new concepts for these in LOINC or others in preference to adding here. BUt this is different from "not maintaining".
  • (Notwithstanding that some of the current content should be "purged.")
  • Aren't we saying this about ALL of the HL7-maintained code systems that are NOT MANDATED for use in HL7 (CS equivalent)?
  • Use Deprecation annotation to point to the preferred representation. What about adding a mapping to SNOMED (for example)?
  • Add UsageConstraints to Portions or all of a code system.

Conclusion: On code systems for the whole - use Deprecation and deprecation note to point to the preferred code system. Also use UsageConstraints to identify Code systems or branches thereof in Act Code. Should build list and add flags to the representations (RoseTree and Ballot HTML)

We will retire objects and never delete objects that have been released into use.

Issues of Code Systems for Data Types that are close to being retired

Deprecation was OK. The problem is that the specs point to the wrong code system, albeit with the correct values set in each instance. This requires a Technical Correction in Abstract DT R2 and in ISO Data Types because they point to the wrong CS which would not align with the intended value sets.

When a "representative" value set is deprecated

Users should be tracking the Value Set. Thus we need simply correct the binding end date when you retire the value set. Note this action in the Harmonization instructions tome.

Duplicate print names for concepts within single code systems

Appears to be a technical flaw in the analysis. Will revisit later.

Bindings to value sets Where External Maintenance Changes

Was discussed and resolved, but Ted will have to provide the minute.