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
 
(47 intermediate revisions by 3 users not shown)
Line 1: Line 1:
−
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.
+
This is the working collaboration page for documenting the issues and requirements to be addressed by the Vocab QA project.  This page will begin to put together the ideas from which the document will eventually be produced.
 
[http://wiki.hl7.org/index.php?title=Vocabulary_Quality_Assurance_Project Project Main Page]
 
[http://wiki.hl7.org/index.php?title=Vocabulary_Quality_Assurance_Project Project Main Page]
  
 
=Scope Items=
 
=Scope Items=
−
Project ID: 1196
+
Project ID: 1196<br>
 +
Three current areas of focus, each with a separate sub-group working on this activity
 +
#Vocabulary glossary across HL7
 +
##Lead - Heather, Lisa
 +
#General vocabulary issues - Vocabulary facilitators
 +
##Lead - Rob McClure and Susan Barber
 +
## This includes Binding
 +
#Governance of creating, maintaining, delivering terminology content from HL7 specs
 +
## Lead - Ted K. and Lloyd M.
 +
##This includes Harmonization
 +
# Publication of terminology
 +
##Lead - Susan M, Richard E.
  
 
==Product Families==
 
==Product Families==
−
#Version 2
+
#Version 2 - Rob Snelick
−
#Version 3
+
#Version 3 - Ted Klein
−
#CDA
+
#CDA - Lisa Nelson, Rob H.
−
#FHIR
+
#FHIR - Lloyd M., Rob H.
 +
# CIMI - Susan M., Richard E.
 +
 
 +
==Definitions and Critical Concepts==
 +
 
 +
==Definitions Last updated on [enter date]==
 +
<!-- Copy the following template to the end of the table to add a new comment
 +
    Replace each <> with your comment (remove the <>'s)
 +
    COPY BELOW THIS LINE
 +
|-
 +
|<IF>
 +
|<Topic Name>
 +
|<Context for definition>
 +
|<Definition>
 +
|<Definition problems - not in line with SKMT>
 +
|<Known Overlaps and conflicting definitions>
 +
STOP HERE - DO NOT COPY THIS LINE -->
 +
 
 +
 
 +
{| class="wikitable sortable" style="font-size:90%; width:99%;"
 +
|-
 +
! style="font-size:110%; background: #B0C4DE" | Id
 +
! style="font-size:110%; width:140px; background: #B0C4DE" | Item
 +
! style="font-size:110%; background: #B0C4DE" | Context
 +
! style="font-size:110%; background: #B0C4DE" | Draft Definition
 +
! style="font-size:110%; background: #B0C4DE" | Noted Issues for draft definition
 +
! style="font-size:110%; background: #B0C4DE" | Usage notes
 +
 
 +
 
 +
|-
 +
|I.
 +
|Overarching Terms - How are these concepts the same or different?
 +
|V3 Core Principles
 +
| (copy in the V3 definition)
 +
| (note where this def doesn't meet SKMT definition guidelines
 +
| (note known issues for this term)
 +
 
 +
|-
 +
|I.1
 +
|Terminology
 +
|From the SKMT
 +
|Structured, human and machine-readable representation of concepts.
 +
|
 +
|
 +
 
 +
|-
 +
|I.2
 +
|Vocabulary
 +
|SKMT from Merriam-Webster's Dictionary (ISO adopted)
 +
|Sum or stock of words employed by a language, group, individual work or in a field of knowledge
 +
|
 +
|
 +
 
 +
|-
 +
|I.3.
 +
|Code System
 +
|TQA WG
 +
|a managed collection of concepts represented by at least one internally unique code that may include a language-dependent description. 
 +
|Based on, but changed substantially from V3 Core Principles
 +
|If more than one unique code is used then the code system is said to have multiple concept representations.
 +
 
 +
|-
 +
|I.4.
 +
|V2 Table
 +
|HL7 Version 2 Health Exchange Standard
 +
|
 +
|
 +
|
 +
 
 +
|-
 +
|I.5.
 +
|Ontology
 +
|[http://www.oxforddictionaries.com/us/definition/american_english/ontology Oxford English Dictionary]
 +
|A set of concepts and categories in a subject area or domain that shows their properties and the relations between them.
 +
|HL7 Core Principles does not give a specific definition for Ontology.
 +
|
 +
 
 +
|-
 +
|I.6.
 +
|Concept Domain
 +
|TQA WG
 +
|A named category intended to represent the scope of ideas that will eventually be represented by a set of specific encodings.
 +
|Based on the information in HL7 V3 Core Principles.
 +
|
 +
 
 +
|-
 +
|II.
 +
|Specific Definitions - What are the definitions for these key terms?
 +
|
 +
|
 +
|
 +
|
 +
 
 +
|-
 +
|II.1.
 +
|Concept
 +
|TQA WG
 +
|a unitary mental representation of a real or abstract thing – an atomic unit of thought. It should be unique in a given Code System. A concept may have a language-dependant description and may also have description synonyms. A concept may represent a single atom in a code system, or may be constructed of multiple concepts (i.e. post-coordinated concepts).
 +
|minor change to V3 Core Principles definition
 +
|
 +
 
 +
|-
 +
|II.2.
 +
|Code System
 +
|TQA WG
 +
|a managed collection of concepts represented by at least one internally unique code that may include a language-dependant description. 
 +
|Based on, but changed substantially from V3 Core Principles
 +
|If more than one unique code is used then the code system is said to have multiple concept representations.
 +
 
 +
|-
 +
|II.3.
 +
|Value Set
 +
|Rob McClure
 +
|A subset of concepts drawn from one or more code systems, where the concepts included in the subset share a common scope of use
 +
|
 +
|
 +
 
 +
|-
 +
|II.4.
 +
|Value Set Definition
 +
|V3 Core Principles
 +
|
 +
|
 +
|
 +
 
 +
|-
 +
|II.4.1
 +
|Extensional Value Set Definition
 +
|V3 Core Principles
 +
|
 +
|
 +
|
 +
 
 +
|-
 +
|II.4.2
 +
|Intensional Value Set Definition
 +
|V3 Core Principles
 +
|
 +
|
 +
|
 +
 
 +
|-
 +
|II.4.3
 +
|Value Set Expansion
 +
|V3 Core Principles
 +
|
 +
|
 +
|
 +
 
 +
|-
 +
|II.4.4
 +
|Grouping Value Set
 +
|V3 Core Principles
 +
|
 +
|
 +
|
 +
 
 +
|-
 +
|II.4.5
 +
|Value Set Scope (Purpose)
 +
|V3 Core Principles
 +
|
 +
|
 +
|
 +
 
 +
|-
 +
|II.4.6
 +
|"Locked" Value Set
 +
|V3 Core Principles
 +
|
 +
|
 +
|
 +
 
 +
 
 +
|-
 +
|III.
 +
|Versioning - What is versioning and how does it apply in this context?
 +
|
 +
|
 +
|
 +
|
 +
 
 +
 
 +
|-
 +
|IV.
 +
|Application of Value Set concepts
 +
|
 +
|
 +
|
 +
|
 +
|-
 +
|IV.1
 +
|Use of Value Sets - What is the purpose of making a value set binding in a model?
 +
|
 +
|
 +
|
 +
|
 +
|-
 +
|IV.2.
 +
|Use of Null (information transport versus metadata bout the value exchanged)
 +
|
 +
|
 +
|
 +
|
 +
 
 +
|-
 +
|IV.3.
 +
|Use of Negation (as defining types of concepts to be included)
 +
|
 +
|
 +
|
 +
|
 +
 
 +
|-
 +
|IV.4.
 +
|Use of MIN, MAX, and IGNORE
 +
|
 +
|
 +
|
 +
|
 +
 
 +
|-
 +
|V.
 +
|Mechanics of using Value Sets
 +
|
 +
|
 +
|
 +
|
 +
 
 +
|-
 +
|V.1.
 +
|How to build a value set
 +
|
 +
|
 +
|
 +
|
 +
 
 +
|-
 +
|V.2.
 +
|What is Binding (Do we say "Value Set Binding"? "Vocabulary Binding?" What is the syntax for expressing the binding?)
 +
|
 +
|
 +
|
 +
|
 +
 
 +
|-
 +
|V.2.1
 +
|What is Binding Strength?
 +
|
 +
|
 +
|
 +
|
 +
 
 +
|-
 +
|V.1.2
 +
|What is Binding Stability? (Static and Dynamic)
 +
|
 +
|
 +
|
 +
|
 +
 
 +
|-
 +
|V.2
 +
|Selection of Code System(s)
 +
|
 +
|
 +
|
 +
|
 +
 
 +
|-
 +
|V.3
 +
|Use of concept descriptions
 +
|
 +
|
 +
|
 +
|
 +
 
 +
|-
 +
|V.4
 +
|What is VS Expansion information and what is in the definition ( See II.4.3)
 +
|
 +
|
 +
|
 +
|
 +
 
 +
|-
 +
|V.5
 +
|Use of concepts not in the bound value set (open/closed, strength, extensability)
 +
|
 +
|
 +
|
 +
|
 +
|}
 +
 
 +
== Terms to Clarify and Create/Identify Our Working Definition ==
 +
Similarities and differences between these ideas.
 +
# Terminology
 +
##[get definition from Core Principles]
 +
# Vocabulary
 +
##[get definition from Core Principles]
 +
#Code System
 +
##[get definition from Core Principles]
 +
#Concepts
 +
##[get definition from Core Principles]
 +
#Value Set
 +
##[get definition from VSD]
 +
#Value Set Definition
 +
#Value Set Expansion
 +
#Relationship
 +
#Hierarchy
 +
#Display Name
 +
#Controlled Vocabulary
 +
#Binding
 +
#Model Binding
 +
#Context Binding
 +
#Concept Domain
 +
#Coded Element
 +
#Metadata
 +
#Version and Versioning
 +
#Conformance
 +
#Normative
 +
 
 +
 
 +
=== Value Set Definition ===
 +
TQA should utilize [http://wiki.hl7.org/index.php?title=Value_Set_Definition_Standard_Project Value Set Set Def Project]
 +
# Intensional & Extensional
 +
## Value Set Expansions
 +
## Grouping value set
 +
## VS Scope (Purpose) - critical elements
 +
## "Locked"
 +
 
 +
===V2 Table===
 +
# Code usage (Required, Permitted, Excluded)
 +
===Terminology artifact versioning===
 +
[How is versioning applied for the main aspects]
 +
 
 +
===Use of value sets - Binding===
 +
TQA should utilize [http://wiki.hl7.org/index.php?title=Binding_Syntax HL7 Binding Semantics Project]
 +
# Use of Null (information transport versus metadata about the value exchanged)
 +
# Negation (as defining types of concepts to be included)
 +
# MIN, MAX, IGNORE
 +
 
 +
===How to build a value set===
 +
# Binding
 +
## Binding Strength
 +
## Binding Stability (Static and Dynamic)
 +
# Selection of code system
 +
# Use of concept descriptions
 +
# What is VS Expansion information and what is in the definition
 +
# Allowance for use of concepts not in the value set (Open/Closed, ~strength, extensability)
  
 
==Vocabulary Objects==
 
==Vocabulary Objects==
 
#HL7 Defined Code Systems
 
#HL7 Defined Code Systems
 
#HL7 Authored and Published Value Sets
 
#HL7 Authored and Published Value Sets
 +
 +
==Projects External  to TQA that should feed the final Process document==
 +
# VSD
 +
#Vocabulary Binding semantics
 +
#Harmonization submission materials and Processes
 +
#Terminfo?
  
 
==Common Elements Across Families==
 
==Common Elements Across Families==
Line 64: Line 430:
 
## Ease of ballot review and understanding
 
## Ease of ballot review and understanding
 
## Vocabulary Darwin award winners
 
## Vocabulary Darwin award winners
 +
# Restructure the ballot documents so that the vocabulary content is easily reviewable and the context of use is easy to determine
  
 
=List of principles=
 
=List of principles=
Line 79: Line 446:
 
*Proposed content should be free of spurious editorial error or structural mistakes (missing requirement elements, etc.)
 
*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
 
*Proposed content should be in a formal artifact and well structured
 +
*Proposed content should have a clear path to implementability
 
#Tooling should be broadly available to enable creation and update of VSDs
 
#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 should be broadly available to enable creation and update of HL7 code systems
Line 108: Line 476:
 
### Incremental build of supporting tooling
 
### Incremental build of supporting tooling
 
#### Can we have tooling that changes as requirements change
 
#### Can we have tooling that changes as requirements change
 +
# Consider using survey monkey to gather current processes
 +
 +
=Initial ideas on TQA Process actions=
 +
Based on 2016-01-11 discussion at Orlando Monday Q2 meeting<br>
 +
Focus on:
 +
# Provide WG with actionable Guidance
 +
# Provide Governance for the process overall
 +
# Determine a Management process for this
 +
<br>
 +
Actionable tasks leads to the following as initial test processes to understand what exists and how to impact:
 +
# Review Harmonization and new Tables Project forms with the intent to create "a form" that will be applied to CDA-based guides and also FHIR resources and Profiles
 +
## Expect that this will result in a cataloging of terminology use but ''but not change the use'' as proposed.
 +
### Direct terminology information gathered in this way to HTA if it uses external terminology
 +
## Identify "pure" HL7 code system and value set elements
 +
# For the identified "pure" HL7 content - begin constructing comprehensive guidance and directly address overall harmonization for this.
 +
 +
=Considerations for Model Element Naming Based on Terminology Issues=
 +
Some possible '''Rules''':
 +
# Where possible use a more specific term and avoid generic categorization terms for property names; i.e., Plan.planPurpose rather than Plan.category.
 +
# Where the property is really a semantic definition of the class instance itself, in order to avoid constructions like Goal.goal, use Kind, i.e., a specific kind, e.g. Goal.kind = HbA1c, or Concern.kind =Type 1 Diabetes.
 +
# Where we have other groupings,
 +
## A general broad grouping is Category. Concern.category might be Diagnosis, e.g., or Complaint. (If the choices were admitting, working, rule-out, etc. see rule #1.)
 +
## Classification, as you say, has a specific statistical meaning, and we shouldn’t use it unless we anticipate something like an ICD code.
 +
# Type is overdetermined in the modeling space; don’t use (unless we identify another requirement)
 +
# Code is a design term, not a requirements term; don’t use.

Latest revision as of 22:08, 21 November 2016

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

Scope Items

Project ID: 1196
Three current areas of focus, each with a separate sub-group working on this activity

  1. Vocabulary glossary across HL7
    1. Lead - Heather, Lisa
  2. General vocabulary issues - Vocabulary facilitators
    1. Lead - Rob McClure and Susan Barber
    2. This includes Binding
  3. Governance of creating, maintaining, delivering terminology content from HL7 specs
    1. Lead - Ted K. and Lloyd M.
    2. This includes Harmonization
  4. Publication of terminology
    1. Lead - Susan M, Richard E.

Product Families

  1. Version 2 - Rob Snelick
  2. Version 3 - Ted Klein
  3. CDA - Lisa Nelson, Rob H.
  4. FHIR - Lloyd M., Rob H.
  5. CIMI - Susan M., Richard E.

Definitions and Critical Concepts

Definitions Last updated on [enter date]

Id Item Context Draft Definition Noted Issues for draft definition Usage notes


I. Overarching Terms - How are these concepts the same or different? V3 Core Principles (copy in the V3 definition) (note where this def doesn't meet SKMT definition guidelines (note known issues for this term)
I.1 Terminology From the SKMT Structured, human and machine-readable representation of concepts.
I.2 Vocabulary SKMT from Merriam-Webster's Dictionary (ISO adopted) Sum or stock of words employed by a language, group, individual work or in a field of knowledge
I.3. Code System TQA WG a managed collection of concepts represented by at least one internally unique code that may include a language-dependent description. Based on, but changed substantially from V3 Core Principles If more than one unique code is used then the code system is said to have multiple concept representations.
I.4. V2 Table HL7 Version 2 Health Exchange Standard
I.5. Ontology Oxford English Dictionary A set of concepts and categories in a subject area or domain that shows their properties and the relations between them. HL7 Core Principles does not give a specific definition for Ontology.
I.6. Concept Domain TQA WG A named category intended to represent the scope of ideas that will eventually be represented by a set of specific encodings. Based on the information in HL7 V3 Core Principles.
II. Specific Definitions - What are the definitions for these key terms?
II.1. Concept TQA WG a unitary mental representation of a real or abstract thing – an atomic unit of thought. It should be unique in a given Code System. A concept may have a language-dependant description and may also have description synonyms. A concept may represent a single atom in a code system, or may be constructed of multiple concepts (i.e. post-coordinated concepts). minor change to V3 Core Principles definition
II.2. Code System TQA WG a managed collection of concepts represented by at least one internally unique code that may include a language-dependant description. Based on, but changed substantially from V3 Core Principles If more than one unique code is used then the code system is said to have multiple concept representations.
II.3. Value Set Rob McClure A subset of concepts drawn from one or more code systems, where the concepts included in the subset share a common scope of use
II.4. Value Set Definition V3 Core Principles
II.4.1 Extensional Value Set Definition V3 Core Principles
II.4.2 Intensional Value Set Definition V3 Core Principles
II.4.3 Value Set Expansion V3 Core Principles
II.4.4 Grouping Value Set V3 Core Principles
II.4.5 Value Set Scope (Purpose) V3 Core Principles
II.4.6 "Locked" Value Set V3 Core Principles


III. Versioning - What is versioning and how does it apply in this context?


IV. Application of Value Set concepts
IV.1 Use of Value Sets - What is the purpose of making a value set binding in a model?
IV.2. Use of Null (information transport versus metadata bout the value exchanged)
IV.3. Use of Negation (as defining types of concepts to be included)
IV.4. Use of MIN, MAX, and IGNORE
V. Mechanics of using Value Sets
V.1. How to build a value set
V.2. What is Binding (Do we say "Value Set Binding"? "Vocabulary Binding?" What is the syntax for expressing the binding?)
V.2.1 What is Binding Strength?
V.1.2 What is Binding Stability? (Static and Dynamic)
V.2 Selection of Code System(s)
V.3 Use of concept descriptions
V.4 What is VS Expansion information and what is in the definition ( See II.4.3)
V.5 Use of concepts not in the bound value set (open/closed, strength, extensability)

Terms to Clarify and Create/Identify Our Working Definition

Similarities and differences between these ideas.

  1. Terminology
    1. [get definition from Core Principles]
  2. Vocabulary
    1. [get definition from Core Principles]
  3. Code System
    1. [get definition from Core Principles]
  4. Concepts
    1. [get definition from Core Principles]
  5. Value Set
    1. [get definition from VSD]
  6. Value Set Definition
  7. Value Set Expansion
  8. Relationship
  9. Hierarchy
  10. Display Name
  11. Controlled Vocabulary
  12. Binding
  13. Model Binding
  14. Context Binding
  15. Concept Domain
  16. Coded Element
  17. Metadata
  18. Version and Versioning
  19. Conformance
  20. Normative


Value Set Definition

TQA should utilize Value Set Set Def Project

  1. Intensional & Extensional
    1. Value Set Expansions
    2. Grouping value set
    3. VS Scope (Purpose) - critical elements
    4. "Locked"

V2 Table

  1. Code usage (Required, Permitted, Excluded)

Terminology artifact versioning

[How is versioning applied for the main aspects]

Use of value sets - Binding

TQA should utilize HL7 Binding Semantics Project

  1. Use of Null (information transport versus metadata about the value exchanged)
  2. Negation (as defining types of concepts to be included)
  3. MIN, MAX, IGNORE

How to build a value set

  1. Binding
    1. Binding Strength
    2. Binding Stability (Static and Dynamic)
  2. Selection of code system
  3. Use of concept descriptions
  4. What is VS Expansion information and what is in the definition
  5. Allowance for use of concepts not in the value set (Open/Closed, ~strength, extensability)

Vocabulary Objects

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

Projects External to TQA that should feed the final Process document

  1. VSD
  2. Vocabulary Binding semantics
  3. Harmonization submission materials and Processes
  4. Terminfo?

Common Elements Across Families

  1. Code system metadata
    1. Code system Identifiers
    2. HL7 code system component syntax
      1. Code case
      2. Use of special characters, etc
      3. Expectations on specification of a particular concept representation for use
  2. Value Set metadata
    1. Value set identifiers
    2. Value set definition constructs
      1. QA considerations to be considered when changes are proposed
  3. Binding information
    1. Common components and naming
    2. Min and Max
    3. Expectations on adherence to versions and behavior when expected version is not available
      1. Expectations to include
        1. Version update timeliness
        2. Impact on backwards compatibility and restrictions that must be considered when changes are proposed
  4. Clarify how partially/unconstrained specifications are to be fully constrained
    1. If every HL7 specification provides through binding and guidance all information necessary to fully specify binding, then HL7 does not need to provide expansions because this should mean that any entity could follow the specification (knowing the allowed defaults and default behavior) to arrive at the correct deterministic expansion
    2. HL7 will define final defaults for all parameters so that if a specification does not address the approach for arriving at a deterministic specification, the HL7 default will govern.

What is needed for each of these

  1. Similar sub-elements
  2. Unified governance
  3. Where there are differences
    1. Allow differences or require harmonization

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
  12. If a code system is represented in an HL7 spec, the code system:
    1. Needs an identifier "known to HL7 users"
    2. Has a documented steward
  13. Example of situation that should be avoided
    1. Abnormal / Interpretation flags in v2 lab / v3 lab
  14. Explain the ROI for following these guidelines
    1. Enhanced ease of implementation
    2. Ease of ballot review and understanding
    3. Vocabulary Darwin award winners
  15. Restructure the ballot documents so that the vocabulary content is easily reviewable and the context of use is easy to determine

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
  • Proposed content should have a clear path to implementability
  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
  2. Asynchronous but consistent process - need off-line functionality
  3. Should we continue to support inconsistent ballot processes timing and approach across families
    1. may need to consider what could change here

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
  • The current notion is that a value set expansion contains a particular set of concepts from underlying terminologies, but different expansions made from the same VSD may have differences in additional baggage; but all must have the same set of concepts
  • Our processes should ensure that whatever gets submitted is consistent with what our documented notions of what value sets actually are.
  • Our processes should allow for the possibility that validation requirements for value sets may vary based on the product family or models they are being designed for use with.
  • See if our tooling and practices can make effective use of social media so that the review process can scale by taking advantage of crowd-sourcing notions

Systematic Approach

  1. Alternative approaches:
    1. Gather Input by meeting with key collaborator for each product family to find issues
      1. Decided against this. Decided to build stawman to discuss with product families first.
    2. Develop and initial strawman then review with product families
      1. Document process
        1. Incrementally add specificity over time
        2. Focus on critical areas and allow other items to not change initially
          1. Identify common elements across all families but are not approached in same way
      2. Incremental build of supporting tooling
        1. Can we have tooling that changes as requirements change
  2. Consider using survey monkey to gather current processes

Initial ideas on TQA Process actions

Based on 2016-01-11 discussion at Orlando Monday Q2 meeting
Focus on:

  1. Provide WG with actionable Guidance
  2. Provide Governance for the process overall
  3. Determine a Management process for this


Actionable tasks leads to the following as initial test processes to understand what exists and how to impact:

  1. Review Harmonization and new Tables Project forms with the intent to create "a form" that will be applied to CDA-based guides and also FHIR resources and Profiles
    1. Expect that this will result in a cataloging of terminology use but but not change the use as proposed.
      1. Direct terminology information gathered in this way to HTA if it uses external terminology
    2. Identify "pure" HL7 code system and value set elements
  2. For the identified "pure" HL7 content - begin constructing comprehensive guidance and directly address overall harmonization for this.

Considerations for Model Element Naming Based on Terminology Issues

Some possible Rules:

  1. Where possible use a more specific term and avoid generic categorization terms for property names; i.e., Plan.planPurpose rather than Plan.category.
  2. Where the property is really a semantic definition of the class instance itself, in order to avoid constructions like Goal.goal, use Kind, i.e., a specific kind, e.g. Goal.kind = HbA1c, or Concern.kind =Type 1 Diabetes.
  3. Where we have other groupings,
    1. A general broad grouping is Category. Concern.category might be Diagnosis, e.g., or Complaint. (If the choices were admitting, working, rule-out, etc. see rule #1.)
    2. Classification, as you say, has a specific statistical meaning, and we shouldn’t use it unless we anticipate something like an ICD code.
  4. Type is overdetermined in the modeling space; don’t use (unless we identify another requirement)
  5. Code is a design term, not a requirements term; don’t use.
Retrieved from "https://wiki.hl7.org/w/index.php?title=Vocab_QA_Requirements&oldid=129236"