CDC PHIN Syndromic Surveillance Message Guide

Most of you have probably read the notice on the Messaging Guide for Syndromic Surveillance published by PHIN (CDC). The CDC is requesting feedback on this implementation guide by June 20, 2011. If you missed the notice, here is the summary:

The Centers for Disease
Control and Prevention (CDC), located
within the Department of Health and
Human Services (HHS) is requesting
public comment on the draft PHIN
Messaging Guide for Syndromic
Surveillance. The document translates
the business requirement
recommendations from the International
Society for Disease Surveillance to
technical specifications to support
meaningful use of electronic health
records for syndromic surveillance.
Comments will be used to inform and
finalize the Messaging Guide.

You can find all the relevant information at Regulations.gov. Several people and organizations will probably provide feedback. I know that HL7 will be doing so through the PHER working group. Below are some of my thoughts.

Here are some of my comments (as an implementer as well as a standards expert):

1. This isn't a comment on the document, but on the actual notice. NOTE that this Messaging Guide as of this writing has *not* been added to the Meaningful Use requirements. I simply want to make this clear. The guide mentions a lot about Meaningful Use, and almost seems to imply that it is the selected implementation specification by CMS and ONC for Meaningful Use. As of this blog entry's publication, this is not the case.
2. Before I dive into some of the comments, I would like to commend the authors on doing the best job that I have seen so far for defining a good Syndromic Surveillance Implementation Guide. I may not agree with all the data requirements, but this has been the best effort so far.
3. Having said 2., I would like to add that there are still a few clarifications needed in the guide to make it a good implementation specification. The other thing to note is that this was written by the CDC without following a standards process open to all parties that will be involved in this information exchange.
4. The Purpose, Audience and Scope sections of the document are very clearly written. I especially would like to point to fact that the Scope section discusses that ADT messages were selected instead of ORU messages by ISDS because ADT allows better flexibility. I applaud CDC and ISDS for making a decision (one way or the other) and specifying it in the guide.
5. I was not a fan of the Extensibility section - it basically says that state and local PHA's are welcome to add optional data elements. I have discussed the Federal v/s State jurisdictional issues in my previous post, and will not go into detail. However, at some point, we have to stop 50 or more different implementation specifications and guides from showing up in the country. This is time-wasting for vendors as well as organizations who are spread across several states / locations. My suggestions would be that the CDC bring the States together and get their buy-in on one single implementation specification.
6. Getting into the details next - I didn't quite understand the need for optional segments PR1 and IN1. If you are creating an implementation guide, the guide is assumed to be meant for the sending system. In my experience, if any sending system has the option to send something (or not to send it), it will probably end up not sending the segments. If there is a reason that optionality is introduced at the segment level, it is important to explain *why*.
7. PID-3: In PID-3, the guide specifies that "Patient Account Number" is a valid Patient Identifier. According to the HL7 standards, this should be sent in PID-18. I would like to see this corrected.
8. PID-5: X'ing out a subcomponent within the name (degree) seems challenging. It might be better to make it optional.
9. PV2-3: The value set column introduces optionality here. It is unclear as to who this optionality applies to, sender or receiver. Leaving the optionality to both would make this filed potentially useless. Requiring the sender to support all three would mean that all organizations submitting the data would need to either capture the data using 3 different value sets, or have a translation available between them. It makes most sense that the receiver support all 3 and the sender have the option to send any one of them. This should be clarified.
10. DG1-3: See #9 above.
11. PR1 segment: What is the rationale of including the PR1 segment in Syndromic Surveillance? This needs to be clarified.
12. IN1 segment: What is the rationale of including the IN1 segment in Syndromic Surveillance? This needs to be clarified.
13. MSA segment: For an acknowledge message, the document should clarify who the "sender" and who the "receiver" are. This can be confusing based on how you look at it.
14. This document doesn't seem like the right place for describing the "Future Data Elements" that might be considered. Either include the data elements, or don't include them and put this in an appendix or a different version of the document.
15. "Age" is annoying - learn to deal with "Date of Birth" as it is a more accurate piece of information.

I hope this small list is useful. Are there others that you as a reader believes should be important comments? Add your comments by commenting on this entry.