Ballot SubmissionTriage & Committee ResolutionBallot Comment Tracking
Comment NumberBallotChapterSectionPage #Line #Artifact IDResource(s)HTML Page name(s)URLVote and TypeSub-categoryTracker #Existing WordingProposed WordingBallot CommentSummaryIn person resolution requestedComment groupingScheduleTriage NotePubsDisposition WGDispositionDisposition Comment or Retract/Withdraw detailsDisposition/Retract/ Withdrawal DateMover / seconderFor AgainstAbstainRetracted / WithdrawnDisposition External OrganizationResponsible PersonChange AppliedSubstantive ChangeSubmitted ByOrganizationOn behalf ofCommenter EmailSubmitter Tracking IDReferred ToReceived FromNotes
1PH33.2.312A-QSo, if the field is a required field in a required segment and the code is invalid then the entire message should be rejected.Please confirm that this statement is accurate. For example, if an ORU message has multiple OBX segments and OBX-3 in one of those OBX segments is bad, none of the other observations should be stored. Is that accurate?For Lura DiscussionThoughts on this? I think it might be best to accept partial messages Craig - I agree that it should be up to the receiving system to determine if the message contains enough data to fulfill the recevier's business rules and use case. Proposed Disposition Comment: We will remove all text that specifies recipient behavior and replace it with text that indicates the recipient's behavior should be based on their own business rules and that non-compliant messages can still be accepted if they meet local business needs.Craig Newman
2PH44.2.118A-SIt seems odd that CWE.3 is only RE when CWE.1 is R. Is there a specific scenario where it would be valid to send a code but no coding system? If not, make the Usage of CWE.3 R.Block 2Persuasive with modWe will remove all text that specifies recipient behavior and replace it with text that indicates the recipient's behavior should be based on their own business rules and that non-compliant messages can still be accepted if they meet local Craig Newman
3PH4Table 4-621A-TThe atomic element of the person’s family name. IN most Western usage, this is the person’s last name.The atomic element of the person’s family name. In most Western usage, this is the person’s last name."N" in "IN" doesn't need to be capitalizedBlock 2PersuasiveWill update to InCraig Newman
4PH44.2.721A-SNote that the HD data type has been constrained to carry an OID identifying an application, a facility, or an assigning authority.This is inconsistent with the Comment for HD.2 where an OID is only "recommended". I suggest you make them consistentBlock 2PersuasiveWill update to make them consistent and constrain it to always be an OIDCraig Newman
5PH44.2.722A-TExample: |Hospital^1.3.6.1.4.1.23437.12.51.32^HL7|Example: |Hospital^1.3.6.1.4.1.23437.12.51.32^ISO|Universal ID Type in the example is wrongBlock 2PersuasiveWill update the 3rd component to "ISO"Craig Newman
6PH44.2.1022A-TFor EHDI messages, this is ORU^R01For EHDI messages, this is ORU_R01The ^ should be a _Block 2PersuasiveWill update to a _Craig Newman
7PH44.2.1022A-SThe comments for the MSG data type only cover the ORU message, in the ACK acknowledgement message, the values are different. I suggest you clarify the appropriate values for each message type.Block 2Persuasive with modCustom value sets will be created for all three MSG data type elements. The value sets will include only values for ORU and ACK messages. The comments in Table 4.2.10 will be updated so they aren't just referencing the ORU message type.Craig Newman
8PH44.2.1022A-SIn other data types, the Value Set includes the "HL7" prefix in addition to the table number. I suggest you follow that convention here.Block 2PersuasiveThe Value Set will be udpated to include the HL7 prefixCraig Newman
9PH44.2.1223A-THl70302HL70302The "L" in the value set should be capitalizedBlock 2PersuasiveWill update to LCraig Newman
10PH44.2.1524A-THL7 0103<none>The SI data type shouldn't have a Value Set. I think this is a cut and paste error from the PT data type.Block 2PersuasiveWill update to remove the value setCraig Newman
11PH44.2.1825A-SMaking VID.2 and VID.3 RE put a burden on sending systems to populate these fields when they are very uncommon in the real world (at least in my experience). If you don't have a specific use case for these elements, I suggest making them O.Block 2PersuasiveSuggestion accepted will make them OCraig Newman
12PH44.2.1825A-TUsage: The TX data type is meant for user display.I think this VID Usage note is a cut and paste error from the TX data type.Block 2PersuasiveWill update the VID usage note to read "This data type is used to identify the HL7 version."Craig Newman
13PH44.2.2727A-QUsage: This data type is used when there is a need to specify the ID number and name of an organization.The XON Usage note indicates an ID number can be sent, but XON.10 is not part of the data type definition in the IG. Should it be?Block 2Persuasive with modThe XON data type in EHDI will be synced up with CCHD which does permit an ID in XON.10Craig Newman
14PH5Table 5-129A-SMost Segment Group lines (Patient Begin, Visit Begin, etc) don't have a Usage but Observation Begin (and End) have a Usage. I suggest you be consistent and either inclue a Usage for all segment groups or none of them.Block 2PersuasiveWe will add a Usage for all segment groups in the message definition tablesCraig Newman
15PH55.231A-STable 5-1 indicates the Observation Group and Observation Segment are RE but Table 5-2 indicates that the OBX segment has a Usage of R. Is an OBX segment required in every message? Please clarify if an OBX is required in every message.Block 2PersuasiveAn OBX is required with every message. Will update the IG to reflect this. Craig Newman
16PH5Table 5-231A-SThe OBR segment has a Cardinality of 3..3. I think this should be at the ORDER_OBSERVATION group level as it's the group (the OBR along with associated OBX segments) which is allowed to repeat. Within an ORDER_OBSERVATION group, only a single OBR segment is allowed.For Lura DiscussionCraig - I want to confirm that the OBXs supporting the overarching OBR should immediately follow that OBR and that the OBXs supporting the left and right ear should immediately follow the appropriate OBR. If that is the case, then this should be persuasive and the segment group that should repeat (and each occurence should have only a single OBR). A related question is whether all 3 OBR segments must be in every message or if it's permissble to have only 1 or 2 OBR segments. The text in 5.5 suggests all 3 are required in all messages.Craig Newman
17PH55.2A-SThe ORU^R01 message MAY contain a single Observation Request (OBR) for the newborn hearing screening panel, 0 to 1.I don't think MAY is correct here given the cardinality of the OBR segment (or the ORDER_OBSERVATION group) is 3..3. I think this should be SHALL. I'm also not sure what the "0 to 1" refers to.For Lura DiscussionOther than the last sentence in section 5.2 (Batch messaging SHALL not be supported.), I'm not sure what the point of Section 5.2 is. Can we remove the narrative description of the message structure? Do we need to expand discussion of batch messaging? Is this a statement about the IG being silent or batch messaging or is this a directive that senders and receivers can't use batch messaging for EHDI data?Craig Newman
18PH5Table 5-333A-SThis segment is sent if there is an error identified in the message. If MSA-1 (Message Acknowledgment) is not valued as AA or CA.It appears that MSH-15 is constrained to AL (indicating a requirement for a communication level ack and the possibility for either a CE or CR code) but MSH-16 doesn't seem to have any such requirement. It's not clear if application level ACKs are in the scope of this document and therefore it's not clear if AE or AR is a possibility. The fact that ERR-5 (application error code) is not included in table 5-11 suggests that application level ACKs are not in scope for this document. If application level ACKs are not in scope, I suggest you remove the reference to AA in this sentence and update Table 6-28.Block 2Not persuasiveBoth styles of ACK messag are possible and would use the same ACK message definition.Craig Newman
19PH5Table 5-436A-SWhen the name of the patient is not known, a value must still be placed in this field since the field is required. In that case, “|~^^^^^^U|” SHALL be used.It's not clear if this is a requirement for a compliant system. Please clarify if systems must support this. If so, you'll want to also update the XPN data type so that support for the name type in XPN.7 is required (it's currently not in the data type definition and so is presumably Optional)Block 2Persuasive with modSystems must support sending a patient Last name. Will update the XPN data type in chapter 4 to reflect patient's last name is required. And we'll remove the current wording about using “|~^^^^^^U|"Craig Newman
20PH5Table 5-436A-QWhy are some fields in the PID segment defintion missing and others present with a Usage of O? Are fields not listed assumed to have a Usage of X? Some clarification might be warranted.Block 2Persuasive with modThe default usage is O. Optional field will not be included in the segment tables but a note will be added that they are optional and users should refer to the base standard for detailsCraig Newman
21PH5Table 5-437A-SLocation of patient’s birth, i.e. hospital name. The address is in PID-11.Location of patient’s birth, i.e. hospital name. The patient's address is in PID-11.I suggest clarifying which address is in PID-11.Block 2PersuasiveText will be updated as suggestedCraig Newman
22PH5Table 5-740A-SThe alternate code to use is a SNOMED-CT code: 417491009, Neonatal Hearing Test procedureUnless there is a compelling use case for sending the SNOMED code, I would suggest removing this as an option so that all messages consistently use the LOINC code. If you implement this suggestion, table 6-12 can be removed as well.Block 2PersuasiveTo option to use the SNOMED code will be removedCraig Newman
23PH5Table 5-741A-SThe people who are to receive copies of the results.What is the use case for supporting OBR-28? Is the receiving system expected to send copies of the results to the individuals in OBR-28? Is this a list of people that the EHR has already sent copies to? This field caused a lot of confusion in the LRI implementation guide. I suggest you clarify the use case for this field.Block 2Persuasive with modThere is no clear use case for OBR-28 and we will make it OptionalCraig Newman
24PH55.5.241A-SOBR|1|123456^ HOSPITAL^9999999999^NPI|999555^PublicHealth^77D77712547^HL7|54111I know this is only an example message, but I think having "PublicHealth" as the Filler ID namespace is going to be confusing to readers. Is it realistic that the PH jurisdiction will have performed the test (as is the definition of the Filler ID)? I suggest you change this to something else.Block 2PersuasiveWill update Public health to another word.Craig Newman
25PH55.5.241A-SOBR|1|123456^ HOSPITAL^9999999999^NPI|999555^PublicHealth^77D77712547^HL7|54111The EI data type which is used for OBR-2 and OBR-3 says in section 4.1.7 that EI.3 "Must be an OID". The values in the example are not OIDs nor is EI.4 "ISO" as would be expected for an OID. I suggest you update the example message.Block 2PersuasiveCraig - Same comment as #44 in CCHD. Presumably the same disposition is applied in bothCraig Newman
26PH55.642A-TFor these two OBRS, one OBX is always required.For these two OBRs, one OBX is always required.The S in OBRs shouldn't be capitalizedBlock 2PersuasiveWill remove the S and make it a sCraig Newman
27PH55.642A-SThe OBX Universal Service ID values will be drawn from the concept value set that is newborn hearing screening panelThe Universal Service ID is in the OBR segment, not the OBX segment. Please clarify the meaning in this sentence.Block 2Persuasive with modThis sentence is unnecessary and will be removedCraig Newman
28PH5Table 5-947A-S{} should be used if the measure is unitless.I find this wording for OBX-6 to be confusing for many observations. Does this mean that OBX-6 should always contain {} for the CCHD Newborn Screening Interpretation segment? If not, is there a subset of values in the answer list that should be accompanied by {}? In the example segment before, OBX-6 is not populated. Please clarify which observations types might have to use {} for unitsFor Lura DiscussionCraig - Same comment as #52 in CCHD. Presumably the same disposition is applied in bothCraig Newman
29PH5Table 5-948A-SScreening Result not Performed Value SetIs there really a reference range (OBX-7) possible for this observation? If not, I suggest you remove "May be Populated" from that column for both the right and left ear observationsBlock 2Persuasive with modThe OBX-7 Reference Range column in Table 5-9 will not be populated when OBX-5 isn't of a data type that supports a reference rangeCraig Newman
30PH6651A-SThis section shows the various Value Set/Codes used in this implementation guide and provides values for those HL7 tables that are constrained by this IG. Hl7 tables in this guide are as specified in the HL7 version 2.6 standard.Please indicate if a conformant system must support all values listed in each value set. For example, for Name Type, does a sending system have to be able to support all 5 codes (A, B, C, L and U)? Also please indicate if these value sets can be expanded locally, For example, can E (emergency) be added to the Patient Location value set for PV1-2?For Lura DiscussionCraig - Same comment as #53 in CCHD. Presumably the same disposition is applied in bothCraig Newman
31PH6Table 6-251A-QGiven that there is a value set for Name Code, does that mean that the name code in the XPN data type must be supported?For Lura DiscussionCraig - Same comment as #54 in CCHD. Presumably the same disposition is applied in bothCraig Newman
32PH6Table 6-652A-SGiven that PID-24 is Optional, is it necessary to include a value set in this document? I suggest removing it.Block 2Not persuasive with modPID-24 should be R in the EHDI IG as it is in the CCHD IGCraig Newman
33PH6Table 6-1053A-SI suggest you reduce the values in the table 0203 value set to those that must be supported by a conformant system (those that have a clear use case). For example, do U (unspecified identifier) and DL (drivers license) really need to be supported?For Lura DiscussionCraig - Is it OK to indicate that values provided in value sets should (SHALL??) be supported but other values in the HL7 table (or other code system) may be supported by trading partner agreement? If that is the case, is there any particular ID Types in table 0203 that need to be supported? NPI? MRCraig Newman
34PH6Table 6-1455A-SSome value types don't seem to make sense for OBX-2. Things like ERL, MSG, VID probably don't belong in this list. I suggest you limit the values to those you expect to be needed for the observations outlined by this document.Block 2Persuasive with modThe list of values fro OBX-2 (table 6-14) will be limited to the data types in the OBX co-constraints table (Table 5-9). TX, CWE and NMCraig Newman
35PH22.28Figures, 2-1, 2-2, 2-3A-SIn the 3 interaction diagrams, ACKs are referenced. In diagram 2-1 (patient care device and PH system) the received message can either be rejected as invalid, or accepted. In the subsequent two diagrams, received messages can either be rejected as invalid or not available, or accepted. Reading this i had questions about whether or not the ACKs represented are application ACKs or communication ACKs, or both for the 2 subsequent diagrams. The narrative imidately preceeding references acknowledging the receipt of the message, but not processing it into the consuming application. Knowing that you will go into more detail later in the IG on ACKs, it might be worth either 1) adding a bit of explanation about the Message Rejected bubble for the 3 diagrams in the narrative following table 2-1, reference where to find more information on rejecting messages elsewhere in the IG, or just reference Message Rejected in the bubble for all three diagrams. For Lura DiscussionCraig - for both Igs, we need to discuss the need for accept and application acksErin Holt CoyneTN Department of Health
36PH5A-SSince this implementation guide states that it can be used for reporting from EHRs to public health, consider incorporating the recently defined and backwards compatible OH2 (Past or Present Job) and OH3 (Usual Work) segments to the NK1 message segment (ref. May 2018 V2.9 ballot). YesBlock 2Not persuasiveCurrently, programs don't collect occupational data for the next of kin. Should this requirement change in the future, we will use the OH* segments to exchange the data.Genny LuensmanCDC/NIOSH
37PHGeneralNEGAs this is intended to be an HL7 implementation guide it should be more consistent in flow and content to other recently issued HL7 implementation guides.  That includes clearly defined conformance statements, use of data type flavors to disambiguiate data type component use in variant fields, and identification of the implementation guide that conformance is claimed to.Block 2PersuasiveThe contents of the IG will be updated to more closely align with recent v2 IGs. The NIST IGAMT authoring tool will be used. Hans BuitendijkCerner
38PH55.4.2NEGMSH should include MSH.21 as a required field to clearly indicate which implementation guide the transaction intents to conform to.  The guide can be registered with an HL7 issued OID to ensure unambiguous identification.Block 1Persuasive Can update IG to add MSH.21 and make it R. Will create profile ID and get OIDs assigned. Lura/Erin700Hans BuitendijkCerner
39PHGeneralNEGThe usage of C or CE as the Usage Code should have an associated computable condition (preferred) or otherwise clear statement.  IF it cannot be computable, the usage code should be RE.Block 1PersuasiveWill review the IG for C or CE codes and update accordingly. The full IG including segments and datatypesLura/Erin700Hans BuitendijkCerner
40PH44.2.22NEGBy way of an example, the XPN data type is used in PID-5 and NK1-2.  It seems that the component requirements are not the same whether a patient or next of kin name is involved (e.g., at least a family name should be present for a patient if name type is not unknown) while for a next of kin that may not required.Block 1Persuasive with modWill define the data type flavor for XPN distinguishing differences. Will update the IG to reflect the datatype flavorsLura/Erin700Hans BuitendijkCerner
41PH22.1.17A-TElectronic Health Record system (EHR-s)Electronic Health Record System (EHR-S)Capitalize 'system' and the 's' in the acronym to be consistent with references throughout the guide.Block 2PersuasiveWill capitlize S to be consistent with other references in the IGKanwarpreet SethiLantana Consulting GroupLynn Perrinelynn.perrine@lantanagroup.com
42PH22.1.17A-SFlow of Events: A newborn has a hearing screening administered by a hearing screener. The screener uses either an Otoacoustic Emissions (OAE) or an Automated Auditory Brainstem Response (AABR) device to conduct the hearing screening on the newborn. The right ear and left ear are screened and data elements including if the patient pass or referred, ...… The right ear and left ear are screened and data elements, including if the patient passed or was referred, … Suggest revising the wording to be gramatically correct. An alternate suggestion to consider based on the data elements would be: … The right ear and left ear are screened and data elements including pass or refer, ...For Lura DiscussionPersuasiveThe proposed wording will be usedKanwarpreet SethiLantana Consulting GroupLynn Perrinelynn.perrine@lantanagroup.com
43PH33.1.110A-SData Type: The unit that is used to construct or restrict the contents of the data field. They are 2 or 3 letter codes. Table 4.1 contains all data types used in this IG.General comment: inconsistent use of the following terms to describe this implementation guide, including: 'IG', 'this Guide', and 'implementation guide'. Suggest using one way of expressing it throughout. Block 2Persuasive"Implementation Guide" will be spelled out once at the beginning and associated with "IG". Afte that IG will be used.Kanwarpreet SethiLantana Consulting GroupLynn Perrinelynn.perrine@lantanagroup.com
44PH33.1.111A-QCode Sets/Systems: Most data elements will have associated lists of acceptable values in tables supported by a standards organization such as HL7 or CDC.Is CDC considered a standards organization? Block 2Persuasive with modThe word "standards" will be removedKanwarpreet SethiLantana Consulting GroupLynn Perrinelynn.perrine@lantanagroup.com
45PH33.314A-SThe following table describes …Table 3-5 describes …Suggest referencing the table number within the narrative to improve clarity rather than 'the following table' or 'table above' Block 2Persuasive with modTable references will use the table name ("Message Attributes" in this case) so that if the table number changes over time, the narrative references don't become inaccurate.Kanwarpreet SethiLantana Consulting GroupLynn Perrinelynn.perrine@lantanagroup.com
46PH33.315A-SSee table with Usage Code Interpretation above.See Table 3-3 with Usage Code Interpretation. In the usage description for Table 3-5, suggest referencing the table number within the narrative to improve clarity rather than see table with ...' Block 2Persuasive with modTable references will use the table name ("Message Attributes" in this case) so that if the table number changes over time, the narrative references don't become inaccurate.Kanwarpreet SethiLantana Consulting GroupLynn Perrinelynn.perrine@lantanagroup.com
47PH33.3 16A-SSee Usage Code Interpretation, above.See Usage Code Interpretation in Table 3-3. In the usage description for Table 3-6, suggest referencing the table number for the usage code interpretatioin to improve clarity. Block 2Persuasive with modTable references will use the table name ("Message Attributes" in this case) so that if the table number changes over time, the narrative references don't become inaccurate.Kanwarpreet SethiLantana Consulting GroupLynn Perrinelynn.perrine@lantanagroup.com
48PH4417A-QHL7 Data Types (4)What is the significance of the 4 in parenthesis? Block 2Persuasive with modThat is an extraneous reference to the chapter number and will be removed.Kanwarpreet SethiLantana Consulting GroupLynn Perrinelynn.perrine@lantanagroup.com
49PH44.217A-TCoded Values for HL7 TablesCoded Values for HL7-Defined TablesAdd '-Defined' to the Data Type Name for ID in Table 4-1 to be consistent with table 4-9Block 2PersuasiveWill add -DefinedKanwarpreet SethiLantana Consulting GroupLynn Perrinelynn.perrine@lantanagroup.com
50PH44.2.621A-TIN most Western usage, this is the person’s last name.In most Western usage, this is the person’s last name.Very minor, but only the 'i' in the first word needs to be capitalized in table 4-6 comments. Block 2PersuasiveWill update to InKanwarpreet SethiLantana Consulting GroupLynn Perrinelynn.perrine@lantanagroup.com
51PH44.2.721A-TTable numbering appears to be off. Table 4-7 is in the narrative immediately following the sub-heading but the table is labeled Table 4-8. All subsequent tables follow after 8. Block 2PersuasiveWill update table numberingKanwarpreet SethiLantana Consulting GroupLynn Perrinelynn.perrine@lantanagroup.com
52PH44.2.822A-TTable 4-9. Coded Value for HL7 Defined-tablesTable 4-9. Coded Value for HL7-Defined TablesMove the hyphen so it is after 'HL7' and capitalize 'tables' for consistencyBlock 2PersuasiveWill move the hyphenKanwarpreet SethiLantana Consulting GroupLynn Perrinelynn.perrine@lantanagroup.com
53PH55.4.133A-TTable 5-3 MSH Segment and Field DescriptionsTable 5-4 MSH Segment and Field DescriptionsTable 5-3 is duplicate, this should be labeled as table 5-4 and subsequent numbering should be corrected. Block 2PersuasiveWill change label of table and subsequent numberingKanwarpreet SethiLantana Consulting GroupLynn Perrinelynn.perrine@lantanagroup.com
54PH55.4.135A-SFor the sender of the acknowledgement it should always be NE.For the sender of the acknowledgement it should always be NE, Never.For Seq 15, in the comments/description column, consider adding 'Never' following NE for consistency with the Always value in the preceding sentence. Block 2PersuasiveText will be updated as suggestedKanwarpreet SethiLantana Consulting GroupLynn Perrinelynn.perrine@lantanagroup.com
55PH55.539A-TThis SHALL be followed by an OBR for the newborn hearing loss panel of the right ear and an OBR for the newborn hearing panel of the left ear.This SHALL be followed by an OBR for the newborn hearing panel of the right ear and an OBR for the newborn hearing panel of the left ear.Remove 'loss' from the right ear screen (so it is 'hearing panel of the right ear'). Block 2Persuasivewill remove the word lossKanwarpreet SethiLantana Consulting GroupLynn Perrinelynn.perrine@lantanagroup.com
56PH55.6.445A-TOBX Segments: Newborn Hearing screen right and Newborn Hearing Screen LeftOBX Segments: Newborn Hearing Screen Right and Newborn Hearing Screen LeftCapitalize 'screen right' for consistencyBlock 2PersuasiveWill capitalize "Screen Right"Kanwarpreet SethiLantana Consulting GroupLynn Perrinelynn.perrine@lantanagroup.com
57PH6651A-THL7 tables in this guide are as specified in the HL7 Version 2.6.1 Standard.HL7 tables in this guide are as specified in the HL7 Version 2.6 Standard.Believe this should be v2.6 not v2.6.1Block 2PersuasiveWill update to 2.6Kanwarpreet SethiLantana Consulting GroupLynn Perrinelynn.perrine@lantanagroup.com
58PH22.1.16A-Q(Table 2-1) Receive an acknowledgement that data has been transmittedWill the submitter of the information be alerted to missing or incompatible information being included in the transmission?Block 2Considered - Question AnsweredThe acknowledgement message may contain ERR (error) segments that detail any issues encountered by the receiving system. It is out of the scope of this guide to be perscriptive about the types of errors that can/should be returned.Kanwarpreet SethiLantana Consulting GroupKimberly Glennkimberly.glenn@lantanagroup.com
59PH22.1.16A-TProvide information to ensure the child if identified with hearing loss is connected with the appropriate servicesProvide information to ensure the child, if identified with hearing loss, is connected with the appropriate servicesInclude commas in the appropriate placesBlock 2persuasiveWill include commasKanwarpreet SethiLantana Consulting GroupKimberly Glennkimberly.glenn@lantanagroup.com
60PH22.1.17A-TThe right ear and left ear are screened and data elements including if the patient pass or referred, risk factors for hearing loss, demographic information and contact information, are collected in the device. The right ear and left ear are screened and data elements including if the patient passed or was referred for services, risk factors for hearing loss, demographic information and contact information, are collected in the device. Change the tense of "pass" and include "to services" after referralBlock 2persuasiveWill update to suggested languageKanwarpreet SethiLantana Consulting GroupKimberly Glennkimberly.glenn@lantanagroup.com
61PH22.117A-QThe provider conducting the hearing screening test MAY also need to incorporate that information in the newborn EHR.Is the information that may need to be included the acknowledgment of the receipt or is it information about the test specifically?Block 2Persuasive with modThis sentence will be updated to read "The provider conducting the hearing screening test may also need to incorporate that information in the EHR if the the EHDI system and the EHR are not interoperable."Kanwarpreet SethiLantana Consulting GroupKimberly Glennkimberly.glenn@lantanagroup.com
62PH33.1.111A-TTable 2-3: Make no changes to the record in the receiving data base. The sending system has no information on this field.Make no changes to the record in the receiving database. The sending system has no information on this field.Remove the space between data and baseBlock 2persuasivewill remove the space to databaseKanwarpreet SethiLantana Consulting GroupKimberly Glennkimberly.glenn@lantanagroup.com
63PH44.2.2026A-QTable 4-21How will multiple surnames be treated?Block 2Considered - Question AnsweredThe components of the XCN data type itself cannot repeat (only the field that uses the XCN data type could repeat). Given that XCN is typically used for providers (not patients), it's unlikely that there will be a need to repeat the providers name. As well, XCN.2 uses the FN data type which allows a string for the surname as well as additional sub-components for Own Surname and Spouse's Surname.Kanwarpreet SethiLantana Consulting GroupKimberly Glennkimberly.glenn@lantanagroup.com
64PH55.5.139A-T This contains observations relevant to the hearing screening and It MAY be followed by supporting OBX segments that include details on any comments or discussion and/or the hearing loss risk indicators (risk factors). This contains observations relevant to the hearing screening and it MAY be followed by supporting OBX segments that include details on any comments or discussion and/or the hearing loss risk indicators (risk factors). Do not capitalize "It"Block 2PersuasiveWill remove capital IKanwarpreet SethiLantana Consulting GroupKimberly Glennkimberly.glenn@lantanagroup.com
65PH55.5.1/.239A-SNewborn Hearing Screeing Panel and Newborn Hearing Screen PanelGeneral comment: inconsistent use of "Newborn Hearing Screening Panel" and "Newborn Hearing Screen Panel" Block 2Persuasive"Newborn Hearing Screeing Panel " will be used throughout the documentKanwarpreet SethiLantana Consulting GroupKimberly Glennkimberly.glenn@lantanagroup.com
66SM55.6.546 (48 of PDF)NEGOBX|1|NM|73740-3^Duration of screening right ear^LNOBX|1|NM|73743-7^Duration of screening right ear^LNIn the OBX examples given, the LOINC code for "right ear" is incorrect.Changing the LOINC to illustrate the correct laterality is recommended.Block 1PersuasiveWill update to the correct LOINCLura/Erin700Laura RappleyeAltarumTroy Abrahams
67SM55.6.546 (48 of PDF)NEGOBX|2|NM|73743-7^Duration of screening left ear^LNOBX|2|NM|73740-3^Duration of screening left ear^LNIn the OBX examples given, the LOINC code for left ear" is incorrect.Changing the LOINC to illustrate the correct laterality is recommended.Block 1PersuasiveWill update to the correct LOINCLura/Erin700Laura RappleyeAltarumTroy Abrahams
68SM55.6.648 (50 of PDF)NEGDuration of Screening Right EarDuration of Screening Left EarTable 5-9. The text in the column for Supporting OBX Segments is incorrectly indicating left vs. right.Changing the name of the Supporting OBX Segment to correctly illustrate the laterality is recommended.Block 1PersuasiveWill update to correctly illustrate the lateralityLura/Erin700Laura RappleyeAltarumTroy Abrahams
69SM55.6.648 (50 of PDF)NEGDuration of Screening Left EarDuration of Screening Right EarTable 5-9. The text in the column for Supporting OBX Segments is incorrectly indicating left vs. right.Changing the name of the Supporting OBX Segment to correctly illustrate the laterality is recommended.Block 1PersuasiveWill update to correctly illustrate the lateralityLura/Erin700Laura RappleyeAltarumTroy Abrahams
70SM7Appendix A64 (66 of PDF)A-SOBX|2|NM|73740-3^Duration of screening right ear^LNOBX|2|NM|73743-7^Duration of screening right ear^LNIn the first example message given, the LOINC code used for "right ear" is incorrect.Changing the LOINC to illustrate the correct laterality is recommended.Block 2PersuasiveThe LOINC code will be updated to match the description of the LOINC codeLaura RappleyeAltarumTroy Abrahams
71SM7Appendix A64 (66 of PDF)A-SOBX|2|NM|73743-7^Duration of screening left ear^LNOBX|2|NM|73740-3^Duration of screening left ear^LNIn the first example message given, the LOINC code used for "left ear" is incorrect.Changing the LOINC to illustrate the correct laterality is recommended.Block 2PersuasiveThe LOINC code will be updated to match the description of the LOINC codeLaura RappleyeAltarumTroy Abrahams
72SM66.659 (61 of PDF)A-TTable 6—24 Units of Time – OBX 6 The Values column contains descriptions, and the Description column contains values.For Lura DiscussionCraig - Is OBX-6 constrained to UCUM codes? If so, several of the codes in table 6-24 are not the UCUM codes (eg Year and Second)PersuasiveWill change column headersLaura RappleyeAltarumTroy Abrahams
73SM44.2.319 (21 of PDF)A-SExample: |20130523082-0600|Example: |20130523082059-0600|The example given for a date looks to be incomplete.Adding the additional digit for Minutes and two digits for Seconds will complete the example.Block 2PersuasiveThe example will be updated to give a complete date/time stampLaura RappleyeAltarumTroy Abrahams
74EHDI5.55-739A-SOBR-2 is marked ROBR-2 is REOBR-2 is marked “R”, required, in the EHDI DSTU, but will not be present in any of the OBR segments in the message from Telepathy™ EHDI.For Lura DiscussionCraig - this seems reasonable unless the expectation is that the device creating the message will always have access to the ordering provider's order ID. Unless the order ID is critical, it may actually be better to make it O rather than RE. Even if it's RE, Telepathy will still have to have the ability to populate OBR-2 (even it's not in every message instance)Lura DaussatPHIISarah Shawsshaw@oz-systems.com
75EHDI5-95-947A-Tthis is text of any comments or discussionThis is text of any comments or discussionCapitalize the TBlock 2persuasiveWill update to TLura DaussatPHII
76EHDINEGThe documentation provides several unique interaction models in section 2.2. Providing multiple methods of submitting the same information will damage attempts to standardize a workflow across the industry. Before the standard moves to Normative, a single, best workflow approach should be selected.Block 1PersuasiveData is gathered and provided to public health. May use data to send data to electronic health . Sender and the receiver. Different entities can play each of these roles. Initiating system and responding system rather than the sender vs. the receiver. Try to clarify the sender/receiver . Will update the IG to reflect one data flow diagram. Will update the surrounding use case text here as well.Lura/John700Nell LapresEPIC