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 1: | Line 1: | ||
| − | |||
<!-- | <!-- | ||
EDITORS - When converting the content from Agenda to minutes: | EDITORS - When converting the content from Agenda to minutes: | ||
| Line 6: | Line 5: | ||
2) Delete the Logistics template reference | 2) Delete the Logistics template reference | ||
{{:MnM Conference Call Logistics}} below | {{:MnM Conference Call Logistics}} below | ||
| − | -->[[Category:2012 MnM Minutes| | + | -->[[Category:2012 MnM Minutes|2012 MnM Minutes]] |
__NOTOC__ | __NOTOC__ | ||
| − | = | + | =Harmonization Conference Call 12:00PM Eastern Time (Date above)= |
| − | |||
[[:Category:2012 MnM Minutes|Return to MnM Minutes]] | [[:Category:2012 MnM Minutes|Return to MnM Minutes]] | ||
==Agenda== | ==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: | ||
| + | |||
| + | ** Code Systems; | ||
| + | ** Concept codes (for internal); | ||
| + | ** Valuse Set definition; | ||
| + | *** isImmutable - the definition cannot be changed, but the expansion may change for an ointentional value | ||
| + | |||
| + | set | ||
| + | ** Binding | ||
| + | * Deprecation - This 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 cur=rent 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. | ||
==Agenda Item 1== | ==Agenda Item 1== | ||
Revision as of 17:00, 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:
- Code Systems;
- Concept codes (for internal);
- Valuse Set definition;
- isImmutable - the definition cannot be changed, but the expansion may change for an ointentional value
set
- Binding
- Deprecation - This 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 cur=rent 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.
Agenda Item 1
Goes here
Review Action Items For MnM
Note the following list, and amend the list to assign selected items:
