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, September 28, 2010

Some Sample Messages for Disease Surviellance

Someone recently asked me if I had sample messages for Disease Surviellance.  I already gave you a recipe, and I don't usually go out of my way to create or supply sample data (but will reference what I know is available), but this requests helps me to prove a point.

Going to the Certification Rule (45 CFR Part 170), specifically section 302(l) we see:
Public health surveillance. Electronically record, modify, retrieve, and submit syndrome-based public health surveillance information in accordance with the standard (and applicable implementation specifications) specified in §170.205(d)(1) or §170.205(d)(2).

Back once more to 205(d) (1) or (2)...
Electronic submission to public health agencies for surveillance or reporting.
(1) Standard. HL7 2.3.1 (incorporated by reference in §170.299).
(2) Standard. HL7 2.5.1 (incorporated by reference in §170.299). Implementation specifications. Public Health Information Network HL7 Version 2.5 Message Structure Specification for National Condition Reporting Final Version 1.0 and Errata and Clarifications National Notification Message Structural Specification (incorporated by reference in §170.299).

So, as you can see, if you use HL7 Version 2.3.1, you have choices, and if you use 2.5.1, you are supposed to use this other guide which ONC has acknowledged is incorrect.

If you want to implement today under the rule, and you don't want to chose a path that you know will change, you would be likely to chose §170.205(d)(1).
But now you need to come up with some content to send, and I have a suggestion for how to do that too.

 So, if you look at page 16 of the HITSP C39 specification, you will see three examples, which are reproduced below under the ANSI terms of copyright found in the C39 specification

© 2009 ANSI. This material may be copied without permission from ANSI only if and to the extent that the text is not altered in any fashion and ANSI’s copyright is clearly noted.
Guidelines and Examples
This is an inpatient admit message that contains Chief Complaint and Admitting Diagnosis data elements.
OBX|1|NM|21612-7^REPORTED PATIENT AGE^LN||40|a^Year^UCUM|||||F
This is a discharge message where the patient has expired.
DG1|1||0005.0^STAPH FOOD POISONING^I9C||200750816|F
DG1|2||535.61^DUODENITIS W/HEMORRHAGE^I9C||200750816|F
DG1|3||787.01^NAUSEA WITH VOMITING^I9C||200750816|F
This is an A08 Patient Information Update message used to convey additional clinical information as OBX segments.
PV2|||^^^^SOB, looks dusky and is coughing up blood. States has just gotten over the measles.
OBX|1|TS|11368-8^ILLNESS/INJURY ONSET DATE/TIME^LN||2007509092230||||||F
OBX|2|NM|8310-5^BODY TEMPERATURE^LN||101.3|[degF]^^UCUM|||||F|||200750816124045
OBX|3|SN|35094-2^BLOOD PRESSURE PANEL^LN||^140^/^84|mm[Hg]^Millimeters of Mercury^UCUM|||||F
DG1|1||055.1^POSTMEASLES PNEUMONIA^I9C||200750816|W

To end this do-it-yourself guide, you need to make these messages version 2.3.1 compliant.  As far as I know, all that takes is to take the last part of the first line containing "|D|2.5" and change it to "|D|2.3.1", and replace the various occurences of ‹OID› with an appropriate value for sending or recieving application identifiers. Whalla, you have a set of sample messages that support Disease Surveillance that seem to meet the requirements under the rule. 

The final test would of course be to develop software that can be certified, but let's take the pre-test as it were.  The approved certification test methods are specified by NIST, you can find the specifics for this criterion here.

And here is what that guide has to say about test data on Page 2:
HL7 v2.3.1 conformance is evaluated in terms of the relevant conformance statements in the HL7.2.3.1 standard based on the specific message type(s) submitted by the Vendor. Since no implementation guide has been specified, Vendors may select the message type(s) they wish to submit. The Vendor supplies the test data for this test.

Then we have the test procedure on page 3, with my emphasis on how to address the results:
  • Submit – evaluates the capability of the EHR to electronically generate the Vendor-selected syndromic surveillance information in a conformant HL7 v2.3.1 or v2.5.1 message

    • The Vendor identifies the version of HL7 to be used for this test (HL7v2.3.1 or v2.5.1). If v2.5.1 is selected, the Vendor also selects a Message Mapping Guide
    • The Vendor instantiates the Vendor-supplied test data in the EHR
    • Using EHR function(s) identified by the Vendor, the Tester verifies the presence of the test data in the EHR, generates the syndromic surveillance message and verifies that the message is conformant to the selected HL7 standard and, if applicable, the PHIN implementation guide and case notification message mapping guide.
Finally, we look at the evaluation critiera on page 4.
Inspection Test Guide – HL7 v2.3.1

IN170.302.1 – 1.01: Tester shall verify that the message is conformant with the HL7v2.3.1 for the message type and message segments generated by the EHR. The Tester may utilize an automated test tool or conduct a visual inspection of the message to conduct the evaluation. The Tester shall only evaluate those items identified as “R=Required” in HL7v2.3.1.

Your final challenge is to discover whether or not you can find someone in public health at the State level to read them.  These are not difficult messages to process, but State public health agencies may not be ready to accept the data, nor have the infrastructure or programs to do so.  It seems like that might have been a better way for CDC to spend their money rather than making us wait for yet another implementation guide that has no industry participation as of yet.