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
1PH11.31A-SBullet points in the two lists have inconsistent capitalization of the first word. Please make them consistentBlock 2PersuasiveWill make the bullets consistentCraig Newman
2PH33.1.19A-SRefer to Chapter 5 for the full message structure.Refer to Chapter 5 of this document for the full message structure.My first thought that this referred to chaper 5 of the base standard, not of the IG. It would be chapter 7 of the base standard. I suggest you clarify the specific Chapter 5 being referencedBlock 2PersuasiveWill make the suggested change to make it more clear.Craig Newman
3PH33.1.19A-STable 3-2 is inconsistent. Most segments are followed by "|…" but NK1 has nothing and PV1 is followed by commas rather than periods. Unless there is a subtle distinction, please make these consistent.Block 2PersuasiveSuggestion accepted. Will make them consistentCraig Newman
4PH33.1.110A-STable 3.5 contains all data types.Table 4-1 contains all data types.It looks like the table reference is wrong and should either be Table 4-1 or Chapter 4. Please updateBlock 2PersuasiveWill update to Chapter 4Craig Newman
5PH33.1.110A-SThe null value is transmitted as two double quote marks (" ") between delimiters.The null value is transmitted as two double quote marks ("") between delimiters.There shouldn't be a space between the quotation marks. Please remove it.Block 2PersuasiveWill remove the space and make it ""Craig Newman
6PH33.1.111A-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?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
7PH44.1.217A-SIt seems odd that CNE.3 is only RE when CNE.1 is R. Is there a specific scenario where it would be valid to send a code but no coding system? If not, I suggest making the Usage of CNE.3 R.Block 2PersuasiveThe coding system will be requiredCraig Newman
8PH44.1.318A-SIf the first component is present then 8 and 9 must be present or both 10 and 11 must be valued.The base standard says that 8 or 9 or 10&11 must be populated, but this says 8 and 9. It is also at odds with the comments for CNN.9 CNN.10 and CNN.11. Is that accurate? As well, if 8 is potentially required, it should be included in this table, but it currently isn't. I suggest reviewing this requirement.Block 2PersuasiveWill review and update this data type to reflect what is in the base standardCraig Newman
9PH44.1.318A-SThis is the Assigning Authority’s Universal ID of CNN.1.This is the Assigning Authority’s Universal ID Type of CNN.1.The comment for CNN.11 should indicate it's the Universal ID Type not the Universal ID (which is CNN.10)Block 2PersuasiveWill update to include the word "type"Craig Newman
10PH44.1.318A-SExample: |1453^Doctor^Heart^A^III^Dr^MD^^DOC^2.16.840.1.113883.12.3.3^ISO|Example: |1453^Doctor^Heart^A^Jr^Dr^MD^^DOC^2.16.840.1.113883.12.3.3^ISO|Given the font used, the Suffix in CNN.5 of the example makes it look like there are 3 pipes (field delimiters). I suggest you change to "Jr" or something else that won't look quite so confusing.Block 2PersuasiveWill update to change from III to JrCraig Newman
11PH44.1.419A-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, I suggest making the Usage of CWE.3 R.Block 2PersuasiveThe coding system will be requiredCraig Newman
12PH44.1.419A-QIf CWE.3 is populated with a value of HL7nnnn and nnnn is of table type HL7, version ID may have an actual value or it may be absentI'm not sure this is possible given the definition of C which says "If the predicate is NOT satisfied: A conformant sending application must NOT send the element.". Please confirm if you think this is valid.Block 2Persuasive with modCWE.7 is not particularly important, and it will be given a Usage of O and remove references in the IGCraig Newman
13PH44.1.419A-QIf CWE.3 is populated with a value other than HL7nnnn or is of table type user-defined, version ID must be valuedDoes this mean that the example you give of a LOINC code must include the version ID? It currently doesn't.Block 2Persuasive with modCWE.7 is not particularly important, and it will be given a Usage of O and remove references in the IGCraig Newman
14PH44.1.419A-QIf CWE.3 is populated with a value other than HL7nnnn or is of table type user-defined, version ID must be valuedWhy does CWE require support for version ID but CNE doesn't? CWE in the EHDI spec doesn't require version be support. Is it more important in CCHD?Block 2CWE.7 is not particularly important, and it will be given a Usage of O and remove references in the IGCraig Newman
15PH44.1.520A-TExample:|12345^^^NPI&2.16.840.1.113883.^MR^Hospital&2.16.840.1.113883.^^TX^Hospital|Example:|12345^^^NPI&2.16.840.1.113883.^MR^Hospital&2.16.840.1.113883.^^^TX^Hospital|I think you're missing a ^ in your example. TX and Hospital are in components 8 and 9 in the example but should be in 9 and 10Block 1TueQ3PersuasiveWill add a ^ to the exampleLura/John700Craig Newman
16PH44.1.721A-SExample: |Maismo~Rad7~Instance1~1234abc~WellBaby CCHD screener|I suggest having at least one of the examples include a Namespace or Universal IDBlock 2PersuasiveWill update to include a namespace or universal idCraig Newman
17PH44.1.721A-QExample: |Maismo~Rad7~Instance1~1234abc~WellBaby CCHD screener|Please confirm that it's OK to send an ID without any Namspace or Universal ID. Given the definition of the HD data type (which requires Namespace) is there any reason not to require EI.2?Block 2Persuasive with modThe EI data type flavor will be updated to Require EI.2 (Namespace). The example will also be updated to reflect that requirementCraig Newman
18PH44.1.721A-QWhy are EI.3 and EI.4 RE while CNN.10 and CNN.11 C with a predicate on each other (to ensure if a Universal ID is sent, it has a Universal ID Type). The EI elements seem fundamentally similarBlock 2Persuasive with modBoth CNN.10/CNN.11 and EI.3/EI.4 will be updated to to more explictly indicate that if a Universal ID is provided, then the Universal ID Type is Required (otherwise it's prohibited). We will also make more clear that if CNN.10 is not valued then CNN.9 is required (otherwise it will be RE)Craig Newman
19PH44.1.821A-TExample: |MSH^3|Example: |MSH^1^3|MSH.2 is the segment sequence, not the field position, so your example indicates the error is with the 3th occurrence of the MSH segment in the message. I think you need "^1" inserted into the exampleBlock 1TueQ3PersuasiveWill update example with a ^1Lura/John700Craig Newman
20PH44.1.922A-QWhy is Universal ID in some data types (CWE) required to be an OID, recommended to be an OID (HD) or silent on ID type (CNN)? Does this reflect different requirements where these data types are used? If possible, I would harmonize the requirementsBlock 2Persuasive with modAnywhere a Universal ID is R or RE, the Universal ID Type will be constrained to an OID. This is consistent with most other v2 IG documents.Craig Newman
21PH44.1.922A-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
22PH44.1.922A-TExample: |Hospital^^HL7|Example: |Hospital^^ISO|Universal ID Type in the example is wrongBlock 1TueQ3PersuasiveWill update to ISOLura/John700Craig Newman
23PH44.1.1022A-SThere shall be an HL7 table number associated with ID data types.It's not clear to me where this association happens. Does this mean that in the IG, everywhere an element uses the ID data type a value set (HL7 table will be specified)? Given that the HL7 table can't be part of the data sent in an actual message in an ID data type element, I'm assuming this is the meaning, but it might benefit from some clarification here and also for the IS data type.Block 1The base standard says: The value of such a field follows the formatting rules for an ST field except that it is drawn from a table of legal values. There shall be an HL7 table number associated with ID data types. An example of an ID field is OBR-25-result status. This data type should be used only for HL7 tables (see section, "Table"). The reverse is not true, since in some circumstances it is more appropriate to use the CNE or CWE data type for HL7 tables.PersuasiveRemove this sentence from the description. Lura/Craig700Craig Newman
24PH44.1.1223A-TFor CCHD messages, this is ORU^R01For CCHD messages, this is ORU_R01The ^ should be a _Block 1TueQ3PersuasiveWill change from ^ to Lura/John700Craig Newman
25PH44.1.1223A-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 1PersuasiveWill update the MSG data type table to clarify the appropriate values for each message type, the ORU and ACK. Lura/Erin700Craig Newman
26PH44.1.1223A-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 2PersuasiveWill add the HL7 prefix in addition to the table numberCraig Newman
27PH44.1.1324A-SUsage: Specifies the name of the person performing a service, when the person performed the service and where the person performed the service. In CCHD screening, this is the physician or other clinician who interpreted the observation, which can be different the person performing the screen.This note seems contradictory. The first sentences say it is related to the person who performed the service, but the last sentence say it's the person who interpreted the data which may be different than the person who performed it. I suggest you clarify which person this refers to. It might be easier to make the NDL data type independent of any sort of data sent in the message and instead describe the role of the person (performer, interpreter) in the context of the segment field using the data type.Block 1From V2.6 Ch 4Definition: Specifies the name of the person performing a service, when the person performed the service and where the person performed the service. Retained for backward compatibility as of v2.6.PersuasiveWill remove the last sentence in the IG and stick to the definition from the base standard.Lura/Craig700Craig Newman
28PH44.1.1524A-THl70302HL70302The "L" in the value set should be capitalizedBlock 1TueQ3PersuasiveWill make it HL7Lura/John700Craig Newman
29PH44.1.1825A-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 1TueQ3PersuasiveWill update the data setLura/John700Craig Newman
30PH44.1.2126A-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
31PH44.1.2126A-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 1TueQ3PersuasiveWill update the text Lura/John700Craig Newman
32PH44.1.2327A-TExample |1000 Heart Screen Street^Suite CCHD^Dallas^TX^99999^USA^^^WA^|This example for XCN is a cut and paste error from the XAD data typeBlock 1TueQ3PersuasiveWill update the text Lura/John700Craig Newman
33PH44.1.2428A-QAre XON.6, XON.7 and XON.8 related only to the ID in XON.10 or are they also related to the Name in XON.1? If they are only relevant to XON.10, I suggest the Usage be C based on the presence of an ID in XON.10. If this is the case, then in the example, a ID in XON.10 should be part of the example.Block 2PersuasiveXON.6/.7/.8 will be updated to have a Usage of C(R/X) based on the presence of XON.10. An example will be providedCraig Newman
34PH5Table 5-130A-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
35PH55.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? Given that section 5.4.6 says that a screeing interpretation OBX is required, it seems like it may be R. But given that I (no results available) seems to be a valid value for OBR-25, it's not clear if there is a use case for an OBX-less 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
36PH55.233A-SThe ORU^R01 message SHALL contain a single Observation Request (OBR) for a CCHD newborn screening panel for a single patient.This statement is a little at odds with the message structure. While the Cardinality of the OBR segment is 1..1 within the ORDER_OBSERVATION segment group, the segment group itself is allows to repeat as indicated by the curly braces in tables 5-1 and 5-2. I suggest you clarify if the segment group is intended to be allowed to repeat. Depending on the answer, you may want to update the OBR-1 comment in table 5-7 which seems to imply mulitple OBR segments are allowed in a single messageBlock 1OBR should only be present 1 time per messagePersuasiveWill update the tables in 5.1 and 5.2 to clarify that OBR can be present 1 time.Lura/Erin700Craig Newman
37PH5Table 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
38PH5Table 5-536A-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
39PH5Table 5-536A-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
40PH5Table 5-537A-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 2PersuasiveWill add patient's addressCraig Newman
41PH5Table 5-741A-SThe status of results for this order. C should be used for a correction to results. F should indicate the Final results; results stored and verified and can only be changed with a corrected result. I should be used to indicate No results are available, if the procedure was incomplete. R should be used if results are entered and they are not verified.I suggest you clarify if all conformant systems need to support values of C, F, I and R. In particular, if I and R must be supported, what is the trigger event for such a message? What about P (Preliminary), is that required to be supported too?For Lura DiscussionNeed some assistance on this one. Craig is following up with Michigan to see if they get anything other than finals or correctionsCraig Newman
42PH5Table 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
43PH5Table 5-741A-TThis could be relevant if someone overrides a result of if they use a device that does not have an interpretation algorithm,This could be relevant if someone overrides a result or if they use a device that does not have an interpretation algorithm,I think "of" should be "or"Block 1TueQ3PersuasiveWill change of to orLura/John700Craig Newman
44PH55.4.541A-SOBR|1|123456^HOSPITAL^9999999999^NPI|999555^PublicHealth^77D77712547^HL7I 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
45PH55.4.541A-SOBR|1|123456^HOSPITAL^9999999999^NPI|999555^PublicHealth^77D77712547^HL7The 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 2PersuasiveWill update the example messageCraig Newman
46PH5Table 5-842A-SThis field is used to distinguish between multiple OBX segments with the same observation ID organized under 1 OBR. Required if there is more than one OBX with the same OBX-3 Observation Identifier associated with the same OBR. This should be used with group observations.The Usage of OBX-4 is CE but the predicate seems to say that it is Required. Would C be a better Usage? I'm also concerned that the definition of both C and CE would preclude sending a subID if OBX-3 is not repeated in a message. This seems burdensome on implementers. May RE is a better Usage. I suggest you clarify when OBX-4 can and must be populated.For Lura DiscussionIf OBX-3 repeats, then OBX-4 should be used. Can RE be used or is it a CE? Craig - the LRI IG has an OBX-4 Usage of C(R/RE) with a Condition of "If there are multiple OBX segments associated with the same OBR segment that have the same OBX-3 values for (OBX-3.1 and OBX-3.3) or (OBX-3.4 and OBX-3.6)." - will this this work OK here?Craig Newman
47PH5Table 5-843A-SIndicator of the normalcy of the result found in OBX-5. Null should be used if there is no reference range.In my experience labs are reluctant to declare something "normal" and typically only declare when something is abnormal. It's not clear whether or not N must be sent if a value is with the normal reference range. I suggest you clarify this scenario.Block 2Persuasive with modWill update the descripition to read "This field contains an interpretation code forf the result. We strongly recommend sending this field when applicable"Craig Newman
48PH5Table 5-843A-SThis field contains the observation result status. F should be used for the final results. C indicates a Correction to Results. P indicates Preliminary Results.I suggest you also indicate the appropriate usage of R as described earlier in the section for results recorded but not used for an overall outcomeBlock 2PersuasiveWill update to indicate the appropriate usage of R. R can be used when Results are entered -- not verifiedCraig Newman
49PH5Table 5-843A-SIn CCHD screening, the protocol used in interpreting the screen should be recorded in a text value in OBX 17.2.How does this relate to the CWE definition in Section 4.1.4 where CWE.1 is Required. Is a code required in OBX-17 or is the text in CWE.2 sufficient? If the latter, I suggest you develop a second CWE data type flavor that doesn't require a coded value.Block 2PersuasiveThe text is sufficient so we will create a new CWE data type that uses CWE.9 Original Text to indicate the methodCraig Newman
50PH5Table 5-843A-SThis field contains the equipment instance responsible for the production of the observation. In CCHD screening the relevant fields to report on a piece of equipment are: Brand, model, version, instance data, serial number, local nameIt's not clear if all of these fields (brand, model, etc) are to be reported in repeats of OBX-18. Please clarify how to message these different concepts.For Lura DiscussionCraig Newman
51PH55.4.650A-SIf a patient is in the NICU, their status can be recorded in an optional OBX segment.If a patient is in the NICU, their status can be recorded in one or more optional OBX segments.I suggest updating the wording to indicate that this observation can repeat.For Lura DiscussionCraig - I'm not sure if I agree with this comment or not anymore .There would only be one OBX indicating the infant is in the NICU. What I think is confusing is that the other OBXs in the example use the same LOINC code (infant NICU factors) but include values that may not be unique to the NICU workflows. Are the other OBX segments correct? Note that the name of the LOINC code is actually "Infant factors that affect newborn screening interpretation". I wonder if this section is more about factors influencing screening (of which being in the NICU is one)PersuasiveWill update wordingCraig Newman
52PH5Table 5-952A-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 Discussionnot all of the values in the OBX segments will have a unit. Is it recommended that it be blank or it be {}? Craig - OBX is optional, so should be OK for the field to be empty. Craig Newman
53PH6657A-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 - My proposed disposition would be "Future versions of this IG will apply value specific Usages "Craig Newman
54PH6Table 6-257A-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 - this may depend on the outcome of comment 38 which seems to imply the need for a name type code. Either XPN.8 should be R or O (I lean O as how many different name types would a newborn be expected to have? However this may raise the issue of reporting for newborns who don't have a legal name yet (eg Baby Boy Smith) and whether or not these should be sent. This is a major issue for immunization reporting)Craig Newman
55PH6Table 6-1361A-SIn Table 5-7, the comment for OBR-45 says "In CCHD screening, this SHALL indicate the pulse oximetry was collected as intermittent (spot-check) values; “7087005^Intermittent(qualifier value)^SCT”" which suggests only a single value is acceptable. Yet Table 6-13 provides 2 codes for use in OBR-45. Is it OK to send a value for Continuous? I suggest you clarify the use of OBR-45Block 2PersuasiveWe will clarify that either code is acceptable to use in OBR-45Craig Newman
56PH6Table 6-1461A-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 2PersuasiveWill include only those that are needed for this observationCraig Newman
57PH6Table 6-1762A-SSome coding systems don't seem to make sense for use in the OBX segments you've described. Things like AS4, CAS, CVX, etc 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 2PersuasiveWill remove to include only limited valuesCraig Newman
58PH4A-SIf the FN data type is used by CCHD (as indicated by Table 4-1), then you should define the data type in Chapter 4. The EHDI IG does define an FN data type that you can probably copy.Block 2PersuasiveWill define and add FN data typeCraig Newman
59PHGeneralNEGAs 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 2TueQ3PersuasiveThe 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
60PH505.04.01NEGMSH 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 1TueQ3Can use a namespace to populate this field. Make it a R. Point is to be able to know what message is and what rules to apply. EI datatype example Z22^PHINVADS^ - review EI data type. Have two different defintions of the datatype (one requires OIDs and one does not). Can chose to use the OIDPersuasive Can update IG to add MSH.21 and make it R. Will create profile ID and get OIDs assigned. Lura/Erin701Hans BuitendijkCerner
61PHGeneralNEGThe 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 1TueQ3PersuasiveWill review the IG for C or CE codes and update accordingly. The full IG including segments and datatypesLura/Erin800Hans BuitendijkCerner
62PHGeneralNEGBy 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 1TueQ3Persuasive with modWill define the data type flavor for XPN distinguishing differences. Will update the IG to reflect the datatype flavorsLura/Erin800Hans BuitendijkCerner
63PH55.4.644 (50 of pdf)A-T...values for Left Foot, Right Food or Right Hand.values for Left Foot, Right Foot or Right Hand.Misspelling, meant to indicate 'foot' not 'food.'Fixing the spelling avoids confusion.Block 1TueQ3PersuasiveWill fix the spelling from food to footLura/John700Laura RappleyeAltarumTim
64PH7Appendix A75 (81 of pdf)A-SOBX|1|CWE|73698-3^Reason CCHD oxygen saturation screening not performed^LN|1|LA19819-4^Prior prenatal diagnosis of CCHD^LN|||A|||F|||201201311234-0600|||||201201311234- 0600||||Heart Hospital|123 Street^Suite A^Arlington^TX^71211|1001001^Smith^Theodore^^^Dr^^^^^^^NPI|OBX|1|CWE|73700-7^CCHD newborn screening interpretation^LN|1|LA7304-4^Not Performed^LN|||N|||F|||201201311234-0600||||Maismo~Rad7|201201311234-0600||||Heart Hospital|123 Street^Suite A^Arlington^TX^71211|1001001^Smith^Theodore^^^Dr^^^^^^^NPI| OBX|2|CWE|73698-3^Reason CCHD oxygen saturation screening not performed^LN|1|LA19819-4^Prior prenatal diagnosis of CCHD^LN|||A|||F|||201201311234-0600|||||201201311234- 0600||||Heart Hospital|123 Street^Suite A^Arlington^TX^71211|1001001^Smith^Theodore^^^Dr^^^^^^^NPI|Example ought to include the required screening interpretation segment, valued with 'not performed'.Not clarifying this could lead implementers to omit the screening interpretation, whereas receivers write business rules to require its presence on every message.Block 2PersuasiveWill add OBX with example of "not performed" as a screening interpretation. Laura RappleyeAltarumTim
65CCHD55.4.237A-SPID-24 R PID -24 REThis field is often not available from the device or the intermediary software that collects data on CCHD screening. Suggest that this field be RE and not R, as mulitple birth indicator is not always available. Block 2PersuasiveWill make multiple birth indicator as RELura DaussatPHIISarah Shaw, Implementation Manager at OZ
66CCHD55.4.237A-SPID-25 RPID -25 REThis field is often not available from the device or the intermediary software that collects data on CCHD screening. Suggest that this field be RE and not R, as birth order is not always available. Block 2PersuasiveWill make birth order RELura DaussatPHIISarah Shaw, Implementation Manager at OZ
67CCHD55.4.539A-SOBR-2 ROBR-2 REThere is not always a placer order number available in the CCHD screening software or screening device. This field should be RE for the CCHD messagesBlock 2PersuasiveWill make placer order number RELura DaussatPHIISarah Shaw, Implementation Manager at OZ
68CCHD55.4644A-SOBX-20OBX-20The screening device does not indicate if it is the right or the left foot. Is there a generic code for foot that could be used instead?For Lura DiscussionNeed some input on this Craig - if laterality is now required by the receiving system then presumably either 302545001 (Entire Foot) or 56459004 (Foot Structure) would be used. There are also codes for a number of sub-structures in the foot if there is a more specific part of the foot that is used Craig - is there a set of LOINC codes that require an observation site? Or does it apply to all observation types?Lura DaussatPHIISarah Shaw, Implementation Manager at OZ
69CCHD6Table 6-1865A-S2339919000 Left Foot and 239830003 Right FootSuggest using a generic code for footThe screening device does not indicate if it is the right or the left foot. Is there a generic code for foot that could be used instead?For Lura DiscussionNeed some input on this Craig - is this a duplicate to #68? Is there a reason why the same comment is not being made for right hand? Is the left hand never used?Lura DaussatPHIISarah Shaw, Implementation Manager at OZ
70CCHDNEGThe 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 1TueQ3Could simplify this to one diagram - results to a receiver, either Public Health or an eHR. Can we have two receipients in one diagram? PersuasiveData 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/Amit701Nell LapresEPIC