This wiki has undergone a migration to Confluence found Here
Difference between revisions of "MnM Minutes Harmonization CC 20120315"
Jump to navigation
Jump to search
| (7 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | + | [[Category:2012 MnM Minutes]] | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
__NOTOC__ | __NOTOC__ | ||
=Harmonization Conference Call 12:00PM Eastern Time (Date above)= | =Harmonization Conference Call 12:00PM Eastern Time (Date above)= | ||
| Line 20: | Line 14: | ||
Examples of "state" for objects | Examples of "state" for objects | ||
* Retiring - Has been removed from common use. Retained for historical record. | * 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: | + | * Freezing - Declare that at a point in time, there will be no further changes to the object. Persisted objects: |
| + | ** Concept domains; | ||
** Code Systems; | ** Code Systems; | ||
** Concept codes (for internal); | ** Concept codes (for internal); | ||
| Line 37: | Line 32: | ||
'''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) | '''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. | ||
==Adjournment== | ==Adjournment== | ||
Latest revision as of 19:23, 15 March 2012
Harmonization Conference Call 12:00PM Eastern Time (Date above)
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.
