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
| Line 40: | Line 40: | ||
We will '''retire''' objects and never '''delete''' objects that have been released into use. | 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. | |
{{:MnM Action Items from 201005}} | {{:MnM Action Items from 201005}} | ||
==Adjournment== | ==Adjournment== | ||
Revision as of 17: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.
Review Action Items For MnM
Note the following list, and amend the list to assign selected items:
