Nov 26, 2019 Actor Type Activity Version
Anthony Julian Comment commented 9:54 PM

For ballot purposes these have been combined into a single word document available at Version 2 Quality Metrics Document

From Sep 17, 2019 to Nov 26, 2019
Anthony Julian Edit updated the page at 6:20 PM
Anthony Julian Comment commented 6:13 PM

Link to conformance document

Comment commented 6:12 PM

Link to Conformance Document

Comment commented 2:23 PM

Harmonize with base criteria

May 29, 2019
Lynn Laakso Comment commented 9:52 AM

For informative documents (and STU) as are "most" IGs, there are no ANSI rules. We only worry about ANSI rules for normative, of which we have no V2 IGs that are currently normative.

STU documents are meant to be on a normative track (e.g. 2.8.2 Immunization messaging, V2.5.1 ELR/LRI/LTCF, Vital Records) but none have submitted for Normative currently (waiting on CCHD, EHDI). These will be expected to be called Release 1 by ANSI but we can request a different name.

May 17, 2019
Anthony Julian Comment commented 4:00 PM

Definitely need to get input from Lynn Laakso on release numbering.  I <<think>> there are some sticky ANSI rules.

Comment commented 3:51 PM

IMO projects intended to align with U.S. MU requirements should base on 2.5.1.  Those with no such limitations should only be allowed against current, or current -1. 

Comment commented 3:48 PM

IMHO Version should be specified at the IG level; profiles within the IG can then further restrict.  Allowing profiles to specify alternate versions leads to chaos.

Craig Newman Comment commented 3:28 PM

We should comment on a minimum allowed base version (eg 2.5.1) if we want projects to have a floor.

Comment commented 3:28 PM

We should add guidance on release numbering. What is the process for determining the appropriate numbering. Lynn may already know about existing documentation we can point to.

Mar 29, 2019
Craig Newman Edit updated the page at 9:58 AM
Comment commented 9:44 AM

We need to think about the selective adoption guidance before we finalize guidance on version selection.

Edit updated the page at 9:43 AM
Mar 15, 2019
Craig Newman Comment commented 9:39 AM

while pre- or post-adoption may be allowed, do we want to say that the "base" version is applied at the IG level rather than at the profile level? In other words, within a single IG, can one profile be based on v2.3.1 while another profile is based on v2.5.1 or should all profiles be based on the same base standard version?

Comment commented 8:15 AM

Proposed wording for a "slicing" best practice:

For fields that can repeat, a given occurrence number SHOULD NOT be designated for a particular type of data (eg, the first occurrence shall be the legal name). Rather, where the data type used contains a "type" component (eg. name type, address type, use code, etc), the type component SHOULD be required and used to indicate the particular type of data being conveyed.

Mar 14, 2019
Anthony Julian Edit updated the page at 3:14 PM
Feb 22, 2019
Anthony Julian Comment commented 5:27 PM

RE: pre-adoption versus post-adoption

Pre-adoption means that you want to pick and choose which new features of the standard you want to adopt. 

The purpose of a standard is to standardize. 

IMHO - although there has been a precedent set, this is bad practice and should be disallowed.

Comment commented 5:14 PM

RE: Slicing by occurrence:

IMHO This should be considered on a case-by-case basis, and not a general rule:

PID-13 stated "The first sequence is considered the primary number (for backward compatibility).  If the primary number is not sent, then a repeat delimiter is sent in the first sequence" -

but PID-40 (the replacement as of 2.7) states "This field replaces PID-13 – Phone Number - Home and PID-14 – Phone Number – Business with the intention that the components of the XTN data type be used to identify phone usage (Telecommunication use code) and type of equipment (telecommunication equipment type). Jointly, these components will describe the nature of the telecommunication data contained in this field and removes the sequenced-based assumptions in PID-13 and PID-14."

I do not see a valid reason to reverse this statement in an IG.

Ditto for PID-5 Patient name.  The standard clearly states "The XPN.7 Name Type Code, and not the order, conveys how the name should be interpreted. As of v2.7, Name Type Code is Required. Refer to HL7 Table 0200 - Name Type in Chapter 2C, Code Tables, for valid values.  Specification of meaning based on sequence is deprecated."

I do not see a valid reason to reverse this statement in an IG either. 

I will agree that the IG may restrict the name types requiring some, but I am not in favor of restricting the order.


Craig Newman Comment commented 9:20 AM

We should also think about best practices for:

  • pre-adoption versus post-adoption
  • slicing by occurrence (ex. first occurrence must be the legal name and the second occurrence must be the "nickname" an dif there is no legal name, then the first occurrence must be empty) 
Feb 15, 2019
Mead Walker Comment commented 10:35 AM

There needs to be language enjoining IG creators to make the document accessible to reviewers.   This includes not putting redundant content in.   I have seen that as an issue for documents created from IGAMT in which use of profile components ends up creating multiple dummy segment flavors which appear in the IG.

Feb 05, 2019
Craig Newman Comment commented 2:22 PM

We should state whether or not there are any differences between STU and Normative IGs. I suspect there won't be, but we should say so one way or the other.

Feb 04, 2019
Anthony Julian Edit updated the page at 2:42 PM
Comment commented 2:40 PM

Good Idea.  Would be problematic unless we have HL7 create a permalink for each IG.

Comment commented 2:38 PM

Agreed and Done

Nick Radov Comment commented 2:35 PM

Should we add a document metadata bullet point with a "SHOULD" recommendation to include the URL of the HL7.org web page containing the IG? People often pass around IGs as email attachments and then they end up with outdated copies. So I'd like everyone to know where to go to find more information and download the latest version.

Comment commented 2:31 PM

Under Technical Requirements Segments I recommend adding "Additional fields not defined in the baseline Segment definition SHALL NOT be appended".

Comment commented 2:24 PM

Should we add a document metadata bullet point to specify the sponsoring work groups, if applicable?

Anthony Julian Comment commented 1:16 PM

Should get VOCAB involved for the shall/should of value sets


Comment commented 1:13 PM

Think this should be a SHALL

Comment commented 1:13 PM

Actually, I personally think this should be a SHALL.  Otherwise how does one know whether the message is useful?


Feb 01, 2019
Anthony Julian Edit updated the page at 12:29 PM
Anthony Julian Edit created the page at 11:58 AM