Inm V2 chapter2 issues

InM V2 Chapter 2 issues discovered:

Issues found

The following items have been found:

Chapter 2, page 68

Chapter 2, page 68, section 2.14.11 OVR segment The standard says that the datatype is CWE in the segment table, and in the component description, but in 2.14.11.1, in parentheses it says CNE. I assume it is supposed to be CWE, but this clear inconsistency should be...what?

Chapter 2A Datatypes

Chapter 2A Datatypes, section 2.A.31 FT - formatted text data The last paragraph is a windy explanation about arbitrarily long FT fields. The very last last sentence is:"The contents of an FT field may be truncated, but the truncation pattern does not apply."

Truncation issues

1. My assumption is that if the truncation character is not included in the MSH-2 (only the historical standard delimiters are defined), then any occurrence of a hash mark (#) in a ST, TX, or FT field are treated as just a regular character, even if it appears as the last character of a string. Please let me know if I am mistaken.
2. If a hash mark is defined as the truncation character in MSH-2, and a hash wants to be used in the text in an OBX-5 of datatype TX or FT, there is no escape sequence character to place this in, correct? The only way to do it is to insert the hex value of the hash mark (0x23, or 0d35) using the escape sequence to insert a hex or decimal number, yes?

I believe that this has been addressed in v2.8, yes? Regardless, the escape sequence for inserting the hex codes could be used for any delimiter character instead of using the special formatting codes? If yes, which of these two techniques is preferred, or proper? How should this be indicated in a conformance profile?

Appendix a

1. A boo-boo was made in transcribing Appendix A code tables stuff to Chapter 2C, in that the two allergy tables (0127, 0128) are still in Appendix A but do not appear in Chapter 2C. I assume this has also been addressed in v2.8?
2. Fixed in 2.8 per Sandy

Acknowledgement modes

Interesting question about acknowledgement modes - the class asked for expected behavior for EVERY permutation of the possible codes for MSH-15 and MSH-16.

They asked if MSH-15 is NE and MSH-16 is AL (Accept acknowledgement type is Never, Application acknowledgement type is Always) is this not the same as leaving both blank (Original mode, which is Application acknowledgment only). I had to think a moment, but I think they are correct. Are they? And if both are set to NE, that means nothing is ever acknowledged? ==CWE==And another thing that has widespread impact on both slides and the examples scattered in the chapters of the spec, including the datatypes chapter, is this little gem in the CWE definition on page 27 in 2.A.13.3 for CWE.3 - second sentence:

As of v2.7 this component is required when CWE.1 is populated and CWE.14 is not populated.

This affects examples throughout our slides and chapters. We have lots of datatypes with Administrative Sex, which is now a CWE, as a component. For instance, RFR, where the 2nd component is CWE. An example in the section is:

b) A normal range that depends on sex, such as Hgb, is transmitted as: |13.5&18^M~12.0 & 16^F| which, according to the articulated rule on CWE, really should rather be:

|13.5&18^M&&HL70001~12.0 & 16^F^^HL70001|

This thing, especially for Sex code which is now CWE with this new rule, I think has huge and widespread impact. All examples all over the place with PID, where only a single character has been shown for the Sex code, now must be updated to the character plus the CWE.3; is this desired? Is this realized? Do we need to do something about this? Does this mean that virtually all of our examples and slides now are non-compliant because the violate this little gem in the CWE.3 explanation? Patrick Loyd: To the CWE.3 issue; after re-checking the actual langauge in the standard....

I like the requirement for CWE.3 be populated when CWE.1 is present; and I do think the examples in the slides should be fixed. I can take that on in the next week before slides are due for the January WGM (depending on what you fixed in the last round of corrections).

I would think any corrections to the examples in the v2.7 Standard itself make their way into the v2.7 errata document. Not sure about corrections in v2.7.1; but I would doubt these were corrected in that version.

P

XON

In the XON datatype, XON.3 ID number has been withdrawn. The question is: what then do the check digit and check digit scheme (XON.4 and XON.5) refer to? XON.10 Organization identifier? Nothing? The text description for them in 2.A.88.4 still refers to its use when the identifier is populated - but also erroneously refers to XON.1 as the identifier, which is the Organization name. Basically this datatype component descriptions are a bit of a mess and need to be cleaned up.

-Ted

DSC examples

In the examples and narrative in 2.17.4 Message it is implied that the DSC protocol is always combined with the ADD protocol – which as I read the chapter is false.

DSC and ADD are may be applied separately.