This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Vocab QA Requirements"

From HL7Wiki
Jump to navigation Jump to search
(Created page with "This is the working collaboration page for documenting the issues and requirements to be addressed by the project. This page will begin to put together the ideas from which t...")
 
Line 30: Line 30:
 
*Scope and Range of proposed Value Set
 
*Scope and Range of proposed Value Set
 
#Assessment of both fitness for purpose and possible negative effects of proposed changes
 
#Assessment of both fitness for purpose and possible negative effects of proposed changes
 +
 +
=Initial Ideas for Requirements=
 +
We really want to have all of these be SHALLs, but we recognize there may be issues around broad use.
 +
#Review process should be asynchronous
 +
#Review process should invite contributions from both members and non-members
 +
#Tooling should be used to ensure technical accuracy
 +
*Proposed content ready for use at time of submission
 +
*Proposed content should be free of spurious editorial error or structural mistakes (missing requirement elements, etc.)
 +
*Proposed content should be in a formal artifact and well structured
 +
#Tooling should be broadly available to enable creation and update of VSDs
 +
#Tooling should be broadly available to enable creation and update of HL7 code systems
 +
#Tooling must support the format for implementation use of the value sets and other vocabulary objects across all families
 +
*Ideally the tooling should provide a single set of capabilities and UI, and the product family differences are 'under the covers' in the background
 +
#It would be nice if the tooling did the automatic items, such as and OID is created automatically when a FHIR value set is created
 +
 +
=General Notions and Comments=
 +
*Some requirements are driven by the underlying code system requirements
 +
*Some requirements are driven by the product family
 +
*We should try to ensure that all value sets created are usable across product families
 +
*

Revision as of 21:43, 23 June 2015

This is the working collaboration page for documenting the issues and requirements to be addressed by the project. This page will begin to put together the ideas from which the document will eventually be produced.

Scope Items

Product Families

  1. Version 2
  2. Version 3
  3. CDA
  4. FHIR

Vocabulary Objects

  1. HL7 Defined Code Systems
  2. HL7 Authored and Published Value Sets

Draft list of issues for discussion

  1. Multi-code system value sets and their use in extensible bindings
  2. Use of value sets to control better use of null flavor
  3. Value set versioning
  4. Use of static binding
  5. Clarify use of immutable value set: ActClassProcedure – good example
  6. Not just value set – all terminology issues
  7. V2 table content issues
  8. Incorrect OID identifier and name of object
  9. Inconsistency in naming conventions
  10. Terminology source of truth for artifacts
  11. Terminology in the context of ballot review

List of principles

This is a working list to document general principles to be implemented with processes to achieve a higher level of quality in the HL7 Vocabulary management processes across the product families.

  1. Assessment of fitness for purpose of new value sets
  • Scope and Range of proposed Value Set
  1. Assessment of both fitness for purpose and possible negative effects of proposed changes

Initial Ideas for Requirements

We really want to have all of these be SHALLs, but we recognize there may be issues around broad use.

  1. Review process should be asynchronous
  2. Review process should invite contributions from both members and non-members
  3. Tooling should be used to ensure technical accuracy
  • Proposed content ready for use at time of submission
  • Proposed content should be free of spurious editorial error or structural mistakes (missing requirement elements, etc.)
  • Proposed content should be in a formal artifact and well structured
  1. Tooling should be broadly available to enable creation and update of VSDs
  2. Tooling should be broadly available to enable creation and update of HL7 code systems
  3. Tooling must support the format for implementation use of the value sets and other vocabulary objects across all families
  • Ideally the tooling should provide a single set of capabilities and UI, and the product family differences are 'under the covers' in the background
  1. It would be nice if the tooling did the automatic items, such as and OID is created automatically when a FHIR value set is created

General Notions and Comments

  • Some requirements are driven by the underlying code system requirements
  • Some requirements are driven by the product family
  • We should try to ensure that all value sets created are usable across product families