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

A Technical Steering Committee (TSC) task force has been working on the HL7 Board's request to develop a method of categorizing the components of the set of HL7 standards. The initial categories are described here: Characteristics of Standards Categories

A set of HL7 work groups have been asked to classify their standards using these categories. Here are some FAQs to consider as you undertake this activity:

What is included in the categorization?

Q: Does this activity cover STUs?

A: Yes, this task applies to all standards on the standards grid, including Normative, Informative, DSTU, and STU published standards. It also includes withdrawn standards that no longer appear on the standards grid.

Q: For a given standard, if there are multiple releases (full releases or dot-releases) do we need to classify them individually or just the most recent one (and assume prior versions are "archived")?

A: Each release should be categorized.  There are situations where older releases are still in active use and may still be maintained via errata or be further specialized via Implementation Guides. In particular, we need to know if older releases should be archived, pointing implementer's to the more recent releases.

Q: What standards will work groups be asked to review?

A: The scope are those standards found in the HL7 Master Grid of Standards (found here: http://www.hl7.org/implement/standards/product_matrix.cfm?ref=nav). The plan is to provide a list of standards for work groups to classify. The list will be drawn from the standards grid. If a work group identifies that a standard is missing from the list, we certainly want to know that.

How do I choose the category?

Q: Does the standard need to exhibit all the characteristics in a category?

A: It does not need to exhibit all the characteristics provided for a category, but should at least exhibit several of the characteristics

Q: How do we assign a category if the standard exhibits characteristics from multiple categories?

A: Choose the category with the greater number of characteristics that apply to the standard.

Q:  What if it is a tossup on the category between stable and some other category?

A: Categorize the standard as stable.

Other Questions?

Q: Who should be involved in the completing the work?

A: We expect that this is a team effort on behalf of the Work Group/Management Group.  You may need to reach out to a specific project team to get information to assist you in categorizing the standard.

Q: What if we don't agree with one of the examples you've assigned to a category?

A: Assign another category as you see fit with associated rationale.

Q: What do we do if we find that a standard has a characteristic that is not currently listed?

A: Please document the characteristic as part of your rationale.

Q: Who should I reach out to if I have questions?

A: Reach out to the Agile Standards Task Force by adding a comment to the bottom of the page.






  • No labels

4 Comments

  1. For a given IG, if there are multiple releases (full releases or dot-releases) do we need to classify them individually or just the most recent one (and assume prior versions are "archived")?

    1. We need to classify each release. In particular, we need to know if older releases should be archived, pointing implementer's to the more recent releases.

  2. Do you have a list of withdrawn standards that are no longer on the standards grid? If not, do you have suggestions on how to go about finding all of these?

    1. The scope are those standards found in the standards grid, and the plan is to provide a list of standards for work groups to classify. The list will be drawn from the standards grid. If a work group identifies that a standard is missing from the list, we certainly want to know that.