Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Tuesday, December 7, 2010

PublicHealth Surveilance Recommendations for MeaningfulUse Published for Comment

At the beginning of December ISDS published its recommendations for Disease Surveillance for Meaningful Use.  I've commented on this work in this blog before.  It's now out for a second round of public comment. 

ISDS, while reporting that they have convened a workgroup of Meaningful Use stakeholders, definately did not include the stakeholders who have to implement the requirements described in their deliberations on the creation of this specification. This is pretty important in standards development.  You need to have the producers as well as the consumers present in the discussion, or you wind up with an unbalanced approach.

What has changed for the better though is that they report that the implementation guide work will be done in HL7, and they've simply reported the required data elements, rather than how they are to be built into an HL7 messaqge. I'm very happy to see this change.  It means that the standards development work will be done in an experiencd SDO which has balanced participation in the the development process.


I have a couple of comments on the document that they published:

1.  On reporting, they recommend reporting from Hospitals and Urgent Care centers every 24 hours, and indicate that there is a belief that ambulatory reporting would be beneficial, but there is a lack of experience in this space.  I would have to agree on the experience space.  I have a hypothesis that ambulatory reporting would not only be beneficial, but also, significantly better than hospital and urgent care reporting based one what I've learned from others.  I suspect that disease activitity in ambulatory care settings spikes ahead of urgent care centers and hospitals, because that is where patients with health coverage will go when they first start having symptoms of disease, whereas patients without will seek urgent or emergency care only after symptoms become severe.  This could amount to a several day lead on existing surveillance efforts.
So, it might be cheap and easy to get large volumes of data from hospitals, but the signal will be smaller and more delayed.  It might be more difficult or expensive to get data from ambulatory providers, but the signal will likely be stronger and sooner (but also different due to change in symptom severity).

From a policy perspective:  I would recommend research and funding into studies on the effectiveness of disease surveillance from the ambulatory perspective.  I would NOT postpone deployment of basic surveillance into urgent and hospital care settings, but would postpone advanced deployment into those settings until it has been determined whether that setting or the ambulatory setting would be the better place to spend money.

2.  On data elements:
Facility name and address data is noted as being RE, required to be sent when known.  I cannot imagine a hospital or urgent care center that does not have that data available.  It should be required.

Unique Patient Identifier and Medical Record Number are two different kinds of patient identifier.  No need to separate these.

Age is required but Gender is RE.  I don't get it.  If you can always figure out the age, then gender should be as easy.  Many of the reasons why you wouldn't be able to ascertain age would also impact gender (patient not concious).  I would assume that these two data elements would have the same level of requirement, and that it should likely be RE (because you may not be able to determine age).

For age, units should also be allowed to be decades, because after a certain age, that's all that HIPAA allows you to indicate.

For patient class, I would limit the value set to Emergency, Outpatient or Inpatient.  Other distinctions, such as obstetric, recurring, or pre-admit are variations on Outpatient as far as I can tell, and not of great utility in surveillance.  While these are values used in the HL7 standard, they don't seem as applicable to the surveillance task.

On Chief Complaint/Reason for Visit, I understand the desire for free text content, but would separate the requirements for free text and coded data and make both RE (send if you have it).  Having both fields for surveillance may be valuable, as you can make associatations between coded values and free text content based on entered data that could be useful later.

I'm curious while tempurature and pulse oximetry are RE, but other vital signs are not included.  I'm not a public health specialist, I can imagine that blood pressure might not correspond to a public health problem, but I could imagine that pulse and respiration might.  What's the significance of the signal conveyed by these data elements, and what is the significance criteria by which a data elements are chosen to be included in this data set.  Hmm, there's some interesting math to do on this set... it strikes me that there's at least a good research paper in evaluating the predictive value of various data elements in the recommended set to public health surveillance.

3 comments:

  1. Hey Keith,
    Just curious if you had time to submit those recommendations to the syndromic.org website. Either way, you make some great points about the data elements. We are paying attention to the "internets" comments as well :P

    ReplyDelete
  2. I did submit them, right after I finished the post.

    ReplyDelete
  3. Keith:

    Regarding "RE" values on Facility Name/Address info; as I understood it they are trying to pare down the transaction size by not having to send that with every message, but having it be defined to the PHA through an "agreement" where those values would be specified (metadata) for that sender.

    I get the point of slimming down message size but relying on paper agreements to define and update data is a poor second to sending it with the rest. It leaves more room for human error/delay to timely update the "metadata" and ensure that it's accurate and in sync with the rest of the message data...just good policy in general.

    ReplyDelete