This wiki has undergone a migration to Confluence found Here
Difference between revisions of "MnM Harmonization Notes April 2008"
Jump to navigation
Jump to search
Line 79: | Line 79: | ||
* The forms are positioned as aids to the committees in preparing and "debating" their proposals. They can also feed the update process directly, whether manual, wizard-based, an editor, or whatnot. | * The forms are positioned as aids to the committees in preparing and "debating" their proposals. They can also feed the update process directly, whether manual, wizard-based, an editor, or whatnot. | ||
* Bind the forms into the current coversheet/proposal documents, using a common proposal identifier. | * Bind the forms into the current coversheet/proposal documents, using a common proposal identifier. | ||
− | + | ||
− | * | + | ===Tutorial at the Phoenix WGM=== |
− | + | * Audiences: | |
− | + | ** Committee designer seeking to extend our models (RIM, class codes, etc.) | |
− | *** Implementor trying to determine what codes, value sets, etc., they need in order to build and instance. | + | ** Committee designer seeking to produce a finer grained constraint than they can find in the vocabulary -- including domain specific constraints and value sets. |
+ | ** Users or realms requiring a content binding to a defined value set (including, over time, a value set defined and maintained external to HL7, but that supports a CTS API). | ||
+ | ** Implementor trying to determine what codes, value sets, etc., they need in order to build and instance. |
Revision as of 19:11, 2 April 2008
Contents
Tuesday, April 1, 2008
Attendees
- In person: Nelson (MnM), Van Hentenryck, Klein (Vocab), Seppala (PA), Walker (RCRIM), Loyd (OO), Hausam (Lab), George, Raiford, Parker (CDS), Stewart (INM), McKenzie (International), Beeler
- Online: Kreisler, Dolin (SD), Glover (Pharmacy), James, Eckerson (PHER), De Jong
Brief Summary of Harmonization Results
ID | File Name | Result |
010102 | 2008Apr_HARM_PROPOSAL_RIM_MEDREC_netherlands_2_SubsAdmin as Procedure_20080306041729.doc | Approved |
020102 | 2008Apr_HARM_COVERPAGE_VOCAB_INM_grahame_grieve_IdentifierReliability.VER definition_20080302063228.doc | Approved |
020103 | 2008Apr_HARM_COVERPAGE_VOCAB_INM_grahame_grieve_PostalAddressUse.NameRepresentationUse definition_20080302183210.doc | Approved |
020104 | 2008Apr_HARM_COVERPAGE_VOCAB_INM_grahame_grieve_EntityNamePartType.SFX definition_20080302183156.doc | Approved |
020105 | 2008Apr_HARM_COVERPAGE_VOCAB_MNM_grahame_grieve_UpdateMode_20080302195151.doc | Approved |
020106 | 2008Apr_HARM_COVERPAGE_VOCAB_INM_grahame_grieve_NullFlavor_20080302195133.doc | Approved |
020107 | 2008Apr_HARM_COVERPAGE_VOCAB_INM_grahame_grieve_EntityNamePartQualifier definition_20080302183140.doc | Approved |
020108 | 2008Apr_HARM_COVERPAGE_VOCAB_INM_grahame_grieve_EntityNameUse definition_20080302185414.doc | Approved |
020109 | 2008Apr_HARM_COVERPAGE_VOCAB_INM_grahame_grieve_PostalAddressUse.SRCH definition_20080302185254.doc | Approved |
020113 | 2008Apr_HARM_COVERPAGE_VOCAB_INM_grahame_grieve_MediaType.PlainText definition_20080302062344.doc | Approved |
020121 | 2008Apr_HARM_PROPOSAL_VOCAB_LAB_robert_hausam_x_LabSpecimenCollectionProviders _20080316235831.doc | Approved |
020122 | 2008Apr_HARM_COVERPAGE_VOCAB_LAB_robert_hausam_PartOfWholeRelationship_20080302232915.doc | Withdrawn |
020123 | 2008Apr_HARM_PROPOSAL_VOCAB_LAB_robert_hausam_BatteryClassDefinition_20080316224613.doc | Approved |
030100 | 2008Apr_HARM_COVERPAGE_VOCAB_RCRIM_g_schadow_BasisOfStrength_20080303003543.doc | Approved |
030101 | 2008Apr_HARM_PROPOSAL_VOCAB_NoCommittee_g_schadow_ActClassCodes_20080316105135.doc | Rejected |
030102 | 2008Apr_HARM_PROPOSAL_VOCAB_RCRIM_g_schadow_ActCode_20080316105048.doc | Duplicate of 030101 |
030103 | 2008Apr_HARM_PROPOSAL_VOCAB_RCRIM_g_schadow_TherapeuticEquivalenceRoleCode_20080316115132.doc | Tabled |
030104 | 2008Apr_HARM_PROPOSAL_VOCAB_RCRIM_g_schadow_ActRelationshipDocument_20080316110424.doc | Approved |
030105 | 2008Apr_HARM_COVERPAGE_VOCAB_RCRIM_g_schadow_ActRelationshipDocument_20080303002827.wbk | Duplicate of 030105 |
Wednesday, April 2, 2008
Attendees
- In person: Dale Nelson, Ted Klein, Gregg Seppala, Mead Walker, Patrick Loyd, Rob Hausam, Lloyd McKenzie, Joyce George, Robin Raiford, Sandy Stuart, Sara Ryan, Woody Beeler, Craig Parker
- Online: Patricia Grimes, Ioana Singureanu, Russ Hamm, Austin Kreisler
Discussion
- How can we make it easier for committees to submit proposals?
- Wizards were discussed. It was generally agreed that they can be helpful, but they are seldom capable of handling the more difficult cases.
- There was discussion about creating several different submission forms, tailored to assisting with the submission of different types of proposals.
- There was discussion about more human assistance from HQ in the submission processing (triage, checking for complexity, etc.).
- How can we make it easier to process the approved proposals in a timely fashion?
- The better form that the original submission is in, the easier it is to process.
- More structured submission mechanisms lead to more automated processing of the changes.
Agreements
- Goal of a "tool" that allows editing of vocabulary content by the membership, that can then be validated, summarized and applied to the vocabulary after approval.
- Develop a set of simple forms with surrounding instructions and style guides for additions or changes of:
- code systems
- coded concepts
- concept domains
- value set definitions
- context binding statements
- Use the ballot's HTML representation as a starting point.
- The surrounding instructions will define dependencies between the forms.
- The forms are positioned as aids to the committees in preparing and "debating" their proposals. They can also feed the update process directly, whether manual, wizard-based, an editor, or whatnot.
- Bind the forms into the current coversheet/proposal documents, using a common proposal identifier.
Tutorial at the Phoenix WGM
- Audiences:
- Committee designer seeking to extend our models (RIM, class codes, etc.)
- Committee designer seeking to produce a finer grained constraint than they can find in the vocabulary -- including domain specific constraints and value sets.
- Users or realms requiring a content binding to a defined value set (including, over time, a value set defined and maintained external to HL7, but that supports a CTS API).
- Implementor trying to determine what codes, value sets, etc., they need in order to build and instance.