ABCDEFGHIJKLMNOPQRSTUVW
1
Issue #Date submittedType of IssueSummary of IssueDate of ResponseStatus/ISDS Response
2
3
14/16/2013Value Set/ Data ElementI’ve been verifying that hospitals are using the appropriate value sets when one is named. I noticed that they sent “U” for ethnicity (PID-22.1). I presume this to mean unknown. They were using the wrong value set (HL70189), but I still looked up the recommended value set. When I looked up the suggested value set in the PHIN v1.1 IG (PHVS_EthnicityGroup_CDC), I found that this value set does not have an option for unknown ethnicity. What do you suggest people do when ethnicity is unknown? Should they just leave PID-22 blank? I did notice that PHVS_EthnicityGroup_CDC_Unk gives an option for unknown. 4/2013Race data set also does not provide option for unknown. Both data elements are RE, so for now yes, leave blank. This is a change we may want to make to the recommended Value Set in the future.
4
25/9/2013Message segmentIn what sequence should we put DG1? The implementation guide is somewhat confusing in that regard.

Page 108 states "This field is a repeatable field; multiple codes may be sent." Neither the base standard nor the definition in the guide (page 72) allows for that. We assume that this meant to state "segment".

Page 108 then also states "The first diagnosis code should be the primary / diagnosis." We assume that this means that the first DG1 contains the primary diagnosis and the "/" is extraneous. More appropriately DG1-15 would have been used to indicate which diagnosis is primary rather than segment sequence, which is generally not recommended.

Page 121/122 lists an example where the admitting diagnosis is listed before the final diagnosis. However, one would think the final diagnosis is more likely to be the primary diagnosis when both are sent.

In the absence of fixes to the guide to address the above issues as that is not likely / reasonable with current timeframes, what sequence is will the test accept when examples are expressed in snapshot mode?

Is it reasonable to put them in reverse order as they become known? I.e., first transaction would have A; second transaction W W A; third transaction F F W A (assuming one working diagnosis remains open upon discharge)?

5/2013ISDS/CDC Notes: These do look like valid concerns but I think the suggested resolution is not correct. The root problem for ‘repeating’ language is the mixing of the term ‘data element’ and ‘field’. It may make sense to change how we use those terms in the next version of the Guide.

Regarding order and priority, DG1-6 is used to convey the ‘type’ of diagnosis (final, admitting, working). Regarding the ‘order’ of the diagnosis, there is debate on the use of DG1-15 for ‘primary’ especially for clinical analysis. We debated this in BioSense and determined it was technically a priority used by medical coding system to calculate the DRG in order to maximize reimbursement. An example given was a patient being treated for an infectious disease and, while in the hospital, had a heart attack or stroke or some other event that actually took up more clinician time and, perhaps, more life threatening. In many cases, these what some might call ‘secondary’ diagnoses would actually show up a higher ‘priority’ for billing purposes. Therefore, a decision was made that DG1-15 could not be counted on as showing a true priority from public health’s perspective. From an HL7 purest perspective, I agree that order is not appropriate but I’m guessing that is why the SS guide is the way it is.
5
35/2013Data ElementWhy is Chief Complaint/Reason for visit only a single element? 5/2013The Meaningful Use Workgroup Recommendations condensed these 2 data elements into one because they wanted to show that only one needed to be sent. We will consider separating out in next versions of Guide.
6
45/8/2013Data ElementCertification testing is generating an error when running the Syndromic Message Report without Facility Type data element5/20135/2013: ISDS/CDC Note: The Syndromic Surveillance (SS) Implementation Guide (IG) (all versions) show this as a required element. Per Table 4-2-1, in the PHIN Messaging Guide for Syndromic Surveillance: Emergency Department and Urgent Care Data Version 1.0 specification, the usage for this data element is “R” (Required) (screen shot below). However, the implementation notes in this specification state, “This data can also be accommodated in the Facility Registration process as defined by ISDS for facilities where a single facility/visit type is expected.” We’re seeing that readers are assuming that the note means that, if the data is captured as part of the Facility Registration process, it would not be necessary to including it in each Syndromic Surveillance HL7 message sent by that facility. Unfortunately, the guide still shows this as Required (R), not Required but may be Empty (RE). Therefore, PHIN MQF will generate an error if there is not an OBX segment included in the message to pass the “Facility Visit / Type” data element (Observation Identifier in OBX-3.1 = SS003). We discussed this with NIST. Their response is that it is not clear that this is a requirement because of the fuzzy language in this section. Prior to developing the NIST testing tool, NIST and ISDS reviewed the IG and tried to extract the actual requirements and developed the addendum and clarification document. It was never concluded that this was a requirement, therefore the validation to test for it (in general) was not written although it is believe that the test case specific testing does. I will forward this to the SS IG team and, if this is a requirement they want to enforce, then we will need to make this clear in the next release of the clarification document. Once that is completed NIST will update the validation accordingly.
7
55/2013Data ElementConfusion over what exactly is required for Chief Complaint/Reason for Visit value sets5/2013Change “or” in value set descriptions to be “AND” so that implementers are aware that they need to support all values (e.g., ICD-9, ICD-10, SnoMed, free text, coded, etc.)→ or at least discuss the options (may be OR with conformance statement clarifying what the OR means)
8
67/16/2013Message updatesI still don’t understand why updates were considered unnecessary for inpatient admissions. I think there are drawbacks to getting data only at admission and discharge for two reasons. 1. There could be a long lag between admission and discharge during which time more complete/usable information may be entered into the EHR. In the inpatient data that we currently receive, a patient is usually admitted with a single admitting diagnosis. During the course of their stay, the diagnoses often change to a set of working diagnoses. In some cases, the admitting diagnosis may be very different from the working diagnoses. For example, we may see someone with an admitting diagnosis of flu and then maybe once they get some lab results back, the working diagnosis gets changed to something completely different. If we had to wait until the patient was discharged for this information, we would be using inaccurate data for a longer period of time (depending on how long the person is hospitalized). I will say it is more technically challenging to deal with, but we retain all diagnoses and then just use the most current set of diagnoses (final over working over admitting). 2. When a patient is discharged, their record is not necessarily complete. Maybe this is unique to our sources of data, but many people do not have a final diagnosis until ~9 days after they are discharged from the hospital. My suspicion is that this may be due to the diagnoses being coded by a billing office instead of on-the-spot by the physician. If the final message we received was always at the point of discharge, our data would be much less complete. The general interest in our agency around syndromic seems to be very dependent on whether or not we received coded diagnoses. There is very little interest in text diagnoses or chief complaints (even though I keep try to convince them that they can have some use). So it is very important that we receive the coded diagnoses even if it is days after discharge.7/2013It appears that the recommendations are more flexible than what the messaging guide implies. The recommendations are intended to set a floor and yet leave room for PHAs with greater capacity (or ambition) to build more robust interfaces.

The messaging guide implies that A01 and A04 message types are the only two for inpatient information. This is a bit contrary to the spirit and intent of the recommendations which explicitly support jurisdictions in setting when they would like to receive the post-discharge message, or more frequent updates between admission and discharge.

Perhaps the thing to do is make small changes in the messaging guide so that it is clear an A08 can be used for communicating inpatient data; we will consider this for future Guide versions.
9
77/30/2013Message triggersOn page 257, there is no 1 sentence description of an A03 message like there are for A01, A04, and A08 (pages 78, 139, 196). For consistency, it would be nice to have one for A03. I struggle to keep these triggers straight in my head...partially because a few of them sound similar. The 1 sentence descriptions help me figure out in which settings each of them applies (since I have been asked that a few times). In the future, it might be nice to have a table or something that explicitly details which messages go along with each care setting. 8/2013We agree--it isn't clear without careful reading which message types are applicable to which settings. We'll take this into consideration when making revisions.
10
810/4/2013Data ElementWhat do you send for Zip Code if the patient is from a non-US country? The data element is RE but asks for USPS which does not exist for other countries10/2013This is something to pay attention to for next time, we may want to develop a specification to address this issue.
11
911/2013IntroductionThe guidance provides a definition for ED and Urgent care, but it doesn’t make any attempt to define an inpatient setting. I’m just waiting for the first hospital to ask me to define that. What do I tell them about all their specialty departments (e.g. cancer care, obstetrics)? I think most people are thinking general med/surg type of care including the ICUs, but I can see this getting very hairy.11/2013We had purposely avoided definining inpatient settings because it might be construed as overly restrictive. However, in future revisions we agree that it would be useful to define inpatient in a way that is sufficient without being constraining.
12
1011/2013Message specificationsI'm having some issues with the address field and wonder if you can shed some light on this. Take, for instance, the example address field from page 351: |^^^^59101^^^^30111| According to the spec, this field should be: |^^BILLINGS^30^59101^USA^^^30111| Now, I agree that there's redundancy built into the zip code, but wonder why the example doesn't include city name? And, if they are RE fields, why not also include state and country?11/2013Though some segments of the Patient Address (e.g., ZIP/Postal Code) are RE, City is O, or Optional. So, the example on page 351 is correct. It would also be correct if it contained the detailed City information. You can see a detailed breakdown of the Patient Address specification for ADT A01 messages on Page 94.
13
1111/2013Message specificationsThe address example on page 69 shows the name of the county versus the FIPS code (but the FIPS code is in the specs as the value set):

OBX|1|XAD|SS002^TREATING FACILITY
LOCATION^PHINQUESTION||^^^13^30341^USA^C^^DEKALB||||||F|||201102091114 		11/2013You are correct, the specification does refer to the FIPS value set. Prior to revising the Guide we will check with the CDC vocabulary team and see if County Name (the Concept Name in the Value Set) would fulfill this spec or if this example is indeed wrong.
14
1210/2013GeneralWould be nice to include the page numbers for the trigger events in the index/table of contents (e.g. A01 start on page X, A03 starts on page X).11/2013Agreed. Will recommend for the next revision.
15
1310/2013Data ElementGuidance for how to send chief complaint is given several times in the document. It seems like the guidance is presented in slightly different ways each time it is described. I’m not sure that these would result in differences, but it might be nice to present the guidance in a consistent manner.
11/2013Good point, when the Guide is revised we will aim to choose one phrasing and ensure it is consistent.
16
1410/2013GeneralPage 6: Under the description for Chapter 5, there is a reference to Chapter 6, but as far as I can tell, there is no Chapter 6.

11/2013You are correct, there is no Chapter 6. I believe this reference should refer to Appendix B: Syndromic Surveillance Message Examples.
17
1510/2013GeneralPage 8: The definition of Emergency Services kind of makes it sounds like data from an ED should only include those visits that are for an “emergency medical condition”. In reading the referenced rules, it would be better if this only included the definition for Emergency Services and didn’t try to tie what an ED is to an emergency medical condition.
11/2013This definition was chosen since it is provided by CMS and is the basis for defining ED/UC for Meaningful Use. However, we are open to exploring other definitions that will help avoid ambiguity.
18
1610/2013GeneralPage 19: There is a reference to section 3.7 in the header of Table 2-3, but I haven’t figured out what that reference refers to.
11/2013Table 3-7 is located in Chapter 5, p. 327, and describes the Batch Simple File Structure. However, this numbering is incorrect and the table number should reflect its placement in Chapter 5, not Chapter 3.
19
1710/2013GeneralPage 30: There is a reference in the “Recommended HL7 Location” column to OBX-5, CWE: 9. This type of notation is used throughout the IG, but I was not able to find anywhere that it described what CWE: 9 meant. I assume this is simply a shorthand way of saying subcomponent 9 of a CWE value type, but it would be nice it that was stated clearly.
11/2013CWE is classified as a data type, and stands for “Coded with exceptions” (Link). In this context, it is in the 9th component of the OBX-5 field, which is why it is represented as OBX-5:9. I do think this would be helpful to clarify directly in the text, probably on p. 56 where the data types are described in detail.
20
1810/2013GeneralPage 55: There is a reference to table 5-3A in Table 4-2. I was unable to find table 5-3A.
11/2013Table 5-3A begins on p. 80 and depicts the MSH segment. This is the first message segment (MSH for A01) so I believe that is why it was chosen as the example.
21
1910/2013Message specificationsPage 56: Under the definition for CWE there it says “1) specified vocabulary is defined or 3) when text is in place, the code may be omitted”. What happened to 2?11/2013This is a typo. Thanks for pointing it out!
22
2010/2013Message specificationsPage 57: The text says that components 1-3 & 7 are used in one of three ways, but only 2 ways are listed (e.g. coded and uncoded).11/2013The explanation of CWE is confusing and should be revisited. We will discuss this further with CDC technical team prior to revising.
23
2110/2013Message specificationsPage 114: Not all data elements of interest are listed in OBX-3. I think this is misleading since it looks like it is intended to be a list of all data elements of interest that apply. The data elements missing appear to be: hospital unit, age unit (maybe this is implied with age), temperature units (maybe this is implied with temperature), systolic and diastolic bp, observations, symptoms, clinical findings, date of onset, and initial pulse oximetry.11/2013The wording says “Data Elements of Interest communicated in OBX segment may include:”, but this could be sharpened to be more precise. Recommendation: “The following are some examples of Data Elements of Interest communicated in the (an?) OBX segment:”
24
2210/2013Message specificationsPage 115: Under Description/Comments for Observation Value, specific data elements are named for some of the data types but not others. Would be good to be consistent.11/2013This would be a good change to make. For instance, Clinical Impression’s Data Type is identified as TX on p. 114, but it is not cross-references on p. 115 under the TX Data Type.
25
2310/2013Message specificationsPage 184: DG1-3.1: shouldn’t the cardinality be [1..1] instead of [0..1] if sender usage is R?11/2013Sender usage may be incorrect (e.g., the intention may have been for this to be RE). We will verify this with the CDC vocabulary team prior to revising. If R is the correct Sender Usage, than the cardinality will need to changed as noted.
26
2410/2013Message specificationsPage 341: HL7 segment column for initial pulse oximetry refers to temperature units.11/2013Good catch! This is an error.
27
2510/2013Sample MessagesPage 344: There is no discharge date/time in PV1-45 (at least not one that matches the scenario description).11/2013You are correct, the discharge date/time is listed in the EVN segment but not in PV1-45, where it is required in an A03 message. This line needs to be changed: PV1|1||||||||||||||||||2222_001^^^^VN|||||||||||||||||01||||||||201208171200
28
2610/2013Sample MessagesPage 345: Visit time is not in 24 hour time (PV1-44)11/2013Correct! This: PV1|1|E|||||||||||||||||3333_001^^^^VN|||||||||||||||||||||||||201208021145
needs to change to this:
PV1|1|E|||||||||||||||||3333_001^^^^VN|||||||||||||||||||||||||201208022345

29
2710/2013Sample MessagesA08 Message Example: (p. 346) A08 Message Example: (p. 346)
MSH segment gives a message time of 4pm (1600) instead of 4am as described in the scenario.

11/2013This appears consistent to us. The story says the update message was sent at 5:15 PM. MSH segment reads (in part): MSH|^~\&||DownTownProcessing^2231237890^NPI|||201212271715||ADT^A08^ADT_A01
30
2810/2013Sample MessagesA08 Message Example: (p. 346) A08 Message Example: (p. 346)
PV1-44 is date of update instead of visit date/time. I was under the impression that PV1-44 should give the time/date of the visit and this should be static. It appears in the examples that it actually changes every time there is an update to the update date/time. We wouldn’t want to lose the original visit date/time unless it was actually corrected, would we?
11/2013The note on p. 224 reads “Note: Date and time of the patient presentation” so your interpretation seems correct. In this case, the PV1 segment should read:
PV1|1|E|||||||||||||||||4444_001^^^^VN|||||||||||||||||||||||||201212271530
Instead of
PV1|1|E|||||||||||||||||4444_001^^^^VN|||||||||||||||||||||||||201212271700
31
2910/2013Sample MessagesA08 Message Example: (p. 346)
Order of the segments is wrong. An A08 message should have the DG1 segment after the OBX segment.
11/2013You are correct. This was verified by referring to Table 5-5 on p. 196
32
3010/2013Sample MessagesA03 Message Example:
PID-29: Time of patient death does not match what was given in the narrative.
11/2013Correct, this should be changed.
Currently:
PID|1||3333^^^^MR||^^^^^^~^^^^^^S|||M||2106-3^^CDCREC||||||||||||21865^^CDCREC||||
||||201208030830|Y|
should be:
PID|1||3333^^^^MR||^^^^^^~^^^^^^S|||M||2106-3^^CDCREC||||||||||||21865^^CDCREC||||
||||201208030855|Y|
33
3110/2013Sample MessagesA03 Message Example:
PV1-44: Date of update given instead of time of visit.
11/2013Correct, this should be changed.
Currently reads:
PV1|1|E|||||||||||||||||3333_001^^^^VN|||||||||||||||||||||||||201208031430
Should read:
PV1|1|E|||||||||||||||||3333_001^^^^VN|||||||||||||||||||||||||201208022345
34
3210/2013Sample MessagesPage 347: The narrative says this example uses chief complaint as an unstructured, free-text. The example message has chief complaint in OBX-5, CWE: 2 instead of CWE:9. Isn’t OBX-5, CWE:9 where unstructured, free-text is supposed to go? I thought CWE:2 was for structured text. This issue exists for all example messages related to Case 3.
11/2013Yes, free text should be in OBX-5, CWE:9, not OBX-5, CWE:2. We will revisit this with our technical writers.
35
3310/2013Sample MessagesPage 348: Page 348:
PV1-44: Update time is used instead of visit time in the A08 example.

11/2013Correct, this should be changed.
Currently:
PV1|1|E|||||||||||||||||4444_001^^^^VN|||||||||||||||||||||||||201212271700
Should be:
PV1|1|E|||||||||||||||||4444_001^^^^VN|||||||||||||||||||||||||201212271530

36
3410/2013Sample MessagesPage 348: The guidance advises not using decimals in ICD9 codes, but decimals are included in the ICD9 codes in the examples.11/2013Interesting point. We’ll revisit the rationale behind advising against decimals and make this change if the reason is valid.
37
3510/2013Sample MessagesPage 348: Typo: There are parentheses around the word cough (DG1-3.2)11/2013That does appear to be a typo. We will look into the reason for this
DG1|2||786.2^(cough)^I9CDX||201012271700|W^Working^2.16.840.1.114222.4.11.827

38
3610/2013Sample MessagesPage 348:
Only the discharge date/time is provided in the A03 message (PV1-45). The original visit date/time is excluded. Isn’t each message supposed to contain all of the information from previous messages (i.e. they become more comprehensive…assuming the information isn’t actually being updated/corrected).
11/2013I believe this correctly captures the intent of a discharge message. This assumes that we are treating the patient’s admission and discharge as two separate events, which is the minimal requirement of the messaging guide. In this case, the discharge message need only contain verified discharge-related information.
39
3710/2013Sample MessagesPage 349:
A01 message:
The DG1 and OBX segments are flipped. The DG1 segment should be the last segment.
11/2013You are correct. This was verified by referring to Table 5-3 on p. 78. One small clarification: the DG1 segment is the last segment in this example, but if there was an optional PR1 segment that would last.
40
3810/2013Sample MessagesA01 message:
The final trailing zero is missing on PV1-44 (admit time). In other words, there is a character missing.
11/2013Correct (Step 4, Case 3)
Currently reads: Unit^^^^^^^^^^^||||||||||||||||4444_001^^^^VN|||||||||||||||||09|||||||||20101227200
Should read:
Unit^^^^^^^^^^^||||||||||||||||4444_001^^^^VN|||||||||||||||||09|||||||||201012272000

41
3910/2013Sample MessagesPage 349:
A01 message:
A final diagnosis is listed in the message. This is the final diagnosis that was assigned to the patient when discharged from the ED. Once a patient is admitted, should the diagnosis from the ED actually be labeled as the admitting diagnosis? The patient may get different diagnoses assigned to them once they have been admitted to the hospital (e.g. if additional information is gathered or new issues develop).
11/2013Your point is a good one; admitting diagnosis would make more sense. It would be useful to explore what people are actually receiving in these A01 messages.
42
4010/2013Sample MessagesPage 349:
A03 message:
The message creation date is December instead of January as described in the narrative.
11/2013Step 5: Discharge trigger
“The next day, at 12:00 PM on December 3, 2010” should read “The next day, at 12:00 PM on January) 3, 2010”
43
4110/2013Sample MessagesPage 349:
A03 message:
Should PV1-45 contain the discharge date/time or the transfer time? That is the field designated for discharge date/time. It currently has transfer date/time.
11/2013See Issue #23. This should be changed to discharge date/time.
Currently:
PV1|1|I|Pediatric||||||||||||||||4444_001^^^^VN|||||||||||||||||01|||||||||201012281930
Should read:
PV1|1|I|Pediatric||||||||||||||||4444_001^^^^VN|||||||||||||||||01|||||||||201001021500
44
4210/2013Sample MessagesPage 350: Under the description for Case 4, why was a Receiver usage of R or RE chosen for the example instead of the Sender usage of R or RE? How can a receiver have a usage of RE?
11/2013I do think this should read “…all of the hospital inpatient data elements of interest with a SENDER usage of R or RE”
45
4310/2013Sample MessagesPage 351:
A01 message:
The DG1 and OBX segments are flipped.
11/2013Correct, same note as Issue #38.
46
4410/2013Sample MessagesPage 351:
A01 message:
DG1-5 (Diagnosis date/time) appears to be incorrect.
11/2013Step 1, Case 4: This should be changed.
DG1|1||487.1^ Influenza with other respiratory manifestations^I9CDX||201012271700
Should read:
DG1|1||487.1^ Influenza with other respiratory manifestations^I9CDX||200906071300
47
4510/2013Sample MessagesPage 351:
A01 message:
Why is diagnosis recorded as working when the narrative says it is the admitting diagnosis?
11/2013Step 1, Case 4: This should be changed.
W^Working^2.16.840.1.114222.4.11.827
Should read:
A^Admitting^2.16.840.1.114222.4.11.827
48
4610/2013Sample MessagesPage 351:
Both A01 and A03 messages:
The facility/visit type data element of interest is only recommended for Urgent Care and ED settings. These examples are for an inpatient visit, but that data element is included in the messages. Why?
11/2013This should be changed. Only Patient Class should be included, not Facility/Visit Type
(see expanded conversation below on Facility/Visit Type & Patient Class and recommended changes)
- - - Response to similar question re: Facility/Visit Type and Patient Class - - - (Issue #8)
This question points out an important ambiguity in Release 1.9 that we would like to resolve in the next Guide revision. We think that the best solution may be to change Facility/Visit Type to Facility Type (only), and keep both that and Patient Class as Required data elements. The inclusion of "Visit" type is what creates the ambiguity and potential redundancy.

For example, we would ideally like to be able to classify a patient's Patient Class as "Outpatient" and their Facility Type as "UC". We're tracking this issue for future revisions. It may require changes to the PHIN VADS value sets, as well.
49
4710/2013Sample MessagesPage 351:
Both A01 and A03 messages:
The chief complaint is in OBX-5, CWE:2, but the chief complaint is unstructured, free-text. Shouldn’t it be in OBX-5, CWE: 9?
11/2013Yes, free text should be in OBX-5, CWE:9.
50
4810/2013Sample MessagesPage 351:
Both A01 and A03 messages:
There is no hospital unit even though that data element is RE for inpatient visits.
11/2013Correct. We either need to change the narrative (i.e., not say that all R/RE data elements will be included) or add in hospital unit.
51
4910/2013Sample MessagesPage 351:
Both A01 and A03 messages:
It appears that patient ID and visit ID are the same. To work as designed (e.g. have one that follows the patient with each visit and one that uniquely identifies the visit), don’t these need to be different?
11/2013This is correct as written. Patient ID and Visit ID may be the same and are combined into a single data element (see p. 26 for more details). As long as there is at least a visit ID to link a single patient’s ADT messages across an encounter or admission, that is sufficient.

Is this something we should reconsider for next time? It fits with the intention of the MU Workgroup (2012).
52
5010/2013Sample MessagesPage 373: How should patient name be transmitted if unknown or known but not desired to be sent? |~^^^^^^U| OR |^^^^^^~^^^^^^U| I have seen both representations in the guidance so I’m not sure which one is correct.
11/2013We should verify this with the technical writers.
However, on p. 71 it says:
| ~^^^^^^S| is how PID 5 (Patient Name) should be sent if it is known but not desired to be sent.
On p. 91:
|~^^^^^^U| is how PID 5 (Patient Name) should be sent if it is unknown.

Should make sure this is consistent throughout the Guide.

53
5110/2013Version changesPage 384: Row 2, existing column appears to have the wrong text in it.
11/2013This should be changed. Original verbiage said:

OBX Segment (CWE Data Type, 5th field) with LOINC Code (8661-1) Observation Identifier

Example OBX Segment (free text):
OBX|3|CWE|8661-1^CHIEFCOMPLAINT:FIND:PT:PATIENT:NOM:REPORTED^LN||^^^^^^^^STOMACHACHE||||||F|||201102171531<cr>

Example OBX Segment (coded and free text):
OBX|3|CWE|8661-1^CHIEFCOMPLAINT:FIND:PT:PATIENT:NOM:REPORTED^LN||7804^Dizziness and giddiness
[780.4]^I9CDX^^^^^^DIZZY||||||F|||201102171531<cr>
54
5210/2013Version changesPage 387:
Row 1: field name appears to be incorrect. Based on looking at the other columns it appears that this is possibly supposed to be chief complaint/reason for visit. If diagnosis, then the guidance in the corrected column would be wrong (it talks about using OBX instead of DG1).
11/2013This is an error as currently written in the Guide. It looks to us like maybe the first row should be “Primary Diagnosis” and the second row should be “Additional Diagnosis”. Also, the Corrected column is wrong if that is the case.
55
5310/2013Version changesPage 387:
Row 2: The corrected column text doesn’t seem right based on the other columns.
11/2013See Issue #51—same problem. Need to check with CDC to verify what Corrections these are supposed to refer to.
56
5410/2013Version changesPage 389:
Row 3 (Diagnosis date/time): The change says this data element was moved from the future element of interest, but I don’t see it in the data elements of interest. Was it eliminated?
11/2013This data element is located in DG1-5 and is Optional (base HL7 standard). However, it is not a data element of interest. I think this is supposed to refer to discharge date/time (which is RE, p. 37)
57
551/2014TypoGuide refers to PHINQUESTION in some places and PHINQUESTIONS in others1/2014This should read "PHINQUESTION"
58
561/2014Value Set/ Data ElementI identified two different values OBX-3.1 for initial temperature.

One is 11289-6 (from the Observation Identifier (Syndromic Surveillance) value set. Elsewhere, the guide references 8610-5 from Vital Sign Result Value Set. Any idea which one should be used?
1/2014Sent to CDC for response.
59
573/2014Message frequencySpecifications in Release 1.1 and 1.9 are not specific enough to be useful for syndromic surveillance purposes; information should be no more than 24 hours old when sent. Current specs: send every 24 hours leave a loophole.3/2014Agreed, will recommend changes for Release 2.0.
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100