Page tree
Skip to end of metadata
Go to start of metadata

Enter proposed definitions/characteristics of each status category for HL7 artifacts below:

Guidance on Categorizing Standards

  • Make sure your work/management group is familiar with the definitions of each category and the associated characteristics.
  • A standard does not need to exhibit all the characteristics provided for a category, but should at least exhibit several of the characteristics
  • A standard may exhibit characteristics from a couple of categories. In that case, select the category with greater number of characteristics that apply to the standard.
  • If it's a tossup between Stable and another category, then Stable is the preferred choice.
  • Make sure to document the rationale for the category selected for a standard. This best done by identifying the characteristics that standard exhibits for that category
  • If you believe a standard has characteristics that aren't documented below, that you believe should be added to the set below, please document that also. Part of the purpose of this pilot is intended to determine if we've covered the categories correctly
  • This is intended to be a team effort on the part of the work group/management group. The work/management group may need to reach out to the project team that put together the standard to assess the category it fits in. At a minimum, the work/management group should review and approve the proposed categorizations of their standards, and the approval should be documented in minutes. 
  • If a group is having trouble categorizing a specific standard, they may reach out to the Agile Standards Task Force for assistance during the pilot phase.
  • As part of the pilot, we are also gathering lessons learned regarding the process, categories, and characteristics.
  • Select one active release and up to three stable releases of a single standard; the rest must be retired unless an appeal is made with rationale to the TSC.

Active:

A standard that 1) has been published, 2) is known to be or planned to be in use, and 3) is planned to have future maintenance releases.

  • Characteristics:
    • Is currently undergoing or is expected to undergo significant change and/or enhancement
    • Is being actively monitored and tracked by WGs and/or management groups
    • WGs have open trackers/issues they expect to resolve
    • Provide essential value to the community
    • Generates interest/participation/member activity
    • Groups are willing to provide resources for it
    • May be required by regulation/law now or in the future
    • Has high impact on a large number of stakeholders 
    • Consumes organizational resources
    • If a WG designates something Active, they are accepting responsibility for updating the standard as necessary.
  • Examples:
    • FHIR R4
    • FHIR IGs
    • CDA R2.1
    • Many CDA IGs
    • Some V2 IGs

Stable:

A standard that may be in use and may generate some feedback and questions, but is not under active review, or expected to be updated in the foreseeable future.

  • Characteristics:
    • Development on this standard is inactive
    • Not changing or expected to be changed
      • New version updates are unlikely; errata are possible
    • Low use of HL7 organizational resources
    • Low or null levels of community feedback
    • Widespread use
    • May still be adoption underway
    • Reduced number of knowledgeable standards developers
      • Communities interested in continuing development need to secure knowledgeable standards developers
  • Examples
    • V2.3.1, 2.5.1
    • V3 messaging
    • CDA R2
    • Original CDA CCD-IG
    • CCOW
    • FHIR STU 2, STU 3

Retired:

A standard that has no current or planned standards development activity within the community; which may no longer be in use, or which we don't want people to consider for use.

  • Characteristics:
    • Withdrawn or retired
    • Not being used broadly by the community
      • Need to be able to measure this. Possibilities include surveying membership.
    • May no longer be supportable due to lack of availability of knowledgeable standards developers.
    • May continue to be in place in certain implementations
    • New adoption should not be encouraged
    • Original scope may be better addressed by newer solutions
  • Examples
    • CDA R1
    • IDMP specifications
    • V2.0, 2.1, 2.3, 2.4...
    • FHIR DSTU 1


  • No labels