This wiki has undergone a migration to Confluence found Here
CMET Management by MnM
Revision as of 16:12, 11 June 2013 by Astechishin (talk | contribs)
Concerns
- Manage the CMET Identifier and Name Spaces for HL7 UV CMETs
- Maintain CMET Master Spreadsheet - ok
- Manage "root" of cmet names as (example) A_ObservationYadaYadaYada
- Prefix is obvious
- second element is the name determined by the root classCode
- YadaYadaYada should be as generic as possible and represent the content
- Manage the "attribution-level" names and definitions
- Publish a pre-defined set as "preferrred" - if it matches your intentions, use it.
- Review non-"universal" attributions to be sure they are
- Proper constraint on the "universal", if a "universal" exists
- Constraint patterns are appropriate to attribution level definition
- Act as Coordinator
- Assure that Naming is "consistent"
- Needs strong Style Guides that are "testable"
- Allow as much independence to the domains as possible
- Have "managed" "UV" CMETs with domain identifiers from "parent" domain
- Verify that "new" publishing leaves CMET "primary" content in domain directories and builds the "Common" stuff by "including" these
- Revise and then Facilitate ANSI Registrations for releases
Resolution
Processes are being established from the request, assignment and tracking of individual CMETs through the ballot process.
- The request process is formalized through a GForge tracker.
- Balloting will be formalized via the NIB form (to be completed)
- Ballot results is currently a formal process
- As CMETs pass ballot, they will be submitted (via the request to publish form) to ANSI