This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Vocab QA Requirements"
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.
Contents
Scope Items
Product Families
- Version 2
- Version 3
- CDA
- FHIR
Vocabulary Objects
- HL7 Defined Code Systems
- HL7 Authored and Published Value Sets
Draft list of issues for discussion
- Multi-code system value sets and their use in extensible bindings
- Use of value sets to control better use of null flavor
- Value set versioning
- Use of static binding
- Clarify use of immutable value set: ActClassProcedure – good example
- Not just value set – all terminology issues
- V2 table content issues
- Incorrect OID identifier and name of object
- Inconsistency in naming conventions
- Terminology source of truth for artifacts
- 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.
- Assessment of fitness for purpose of new value sets
- Scope and Range of proposed Value Set
- 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