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