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.
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.
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.
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)
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 andremoves 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.
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.
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?
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.
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.
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.
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.
20 Comments
Nick Radov
Should we add a document metadata bullet point to specify the sponsoring work groups, if applicable?
Anthony Julian
Agreed and Done
Nick Radov
Under Technical Requirements Segments I recommend adding "Additional fields not defined in the baseline Segment definition SHALL NOT be appended".
Nick Radov
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.
Anthony Julian
Good Idea. Would be problematic unless we have HL7 create a permalink for each IG.
Craig Newman
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.
Mead Walker
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.
Craig Newman
We should also think about best practices for:
Anthony Julian
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.
Anthony Julian
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.
Craig Newman
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.
Craig Newman
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?
Anthony Julian
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
We need to think about the selective adoption guidance before we finalize guidance on version selection.
Craig Newman
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.
Anthony Julian
Definitely need to get input from Lynn Laakso on release numbering. I <<think>> there are some sticky ANSI rules.
Lynn Laakso
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.
Craig Newman
We should comment on a minimum allowed base version (eg 2.5.1) if we want projects to have a floor.
Anthony Julian
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.
Anthony Julian
For ballot purposes these have been combined into a single word document available at Version 2 Quality Metrics Document