MeaningfulUse Stage2 Wave 2 Test Procedures

Wave 2 of the Meaningful Use Stage 2 test methods were released last Friday.  Just to repeat, I'm only covering those that address interoperability standards, not other functional requirements.

I missed a test procedure released as part of wave 1 when I reviewed them a week ago (since it was released a couple of days late).  That is also included below:

Wave 1: Immunization Transmission

This one uses the NIST HL7 Version 2 Conformance testing tools.  It identifies seven separate test cases, and provides test data for each:

1. Admin for Child
2. Admin for Adult
3. Historical for Child
4. Consented Child
5. Refused Toddler
6. Varicella History Child
7. Complete Record 

What is interesting here is that they include a good cross section of test cases, testing new administrations (1 & 2), recording of historical immunizations (3), recording consent (using PD1-12) in (4), recording refusal (using RXA-18) in (5), recording a case where a prior history of disease (e.g., varicella) occured (6),  and lastly, a case where both a historical and new administration are reported (7).

These test cases raise the bar for immunization reporting from prior test procedures.  

1. You must be able to show that you can record consent in (PDI-12).
2. You must be able to show that you can record a refusal to immunize (RXA-18)
3. You must be able to record prior history of an immunizable disease (using an OBX segment).

This is in part as a result of dropping to one guide, and thus being able to provide more thorough testing.  Trying to test these three cases above using either the 2.3.1 or 2.5.1 guides would have been very challenging.  But also, I believe that the intent has been to raise the bar on interoperability between stages.  So, while the immunization requirement has not disappeared, and in fact, no new guide has been introduced, the capabilities that the EHR must be able to demonstrate are higher for Stage 2.

Wave 2: Demographics

On this test, it principally verifies that race, ethnicity, gender, and preferred language can be recorded, uses appropriate categories, allows MORE THAN ONE race to be recorded, and allows information about race, ethnicity and preferred language to be recorded as "declined to specify", representing the voluntary nature of this recording.  A lot of systems will need to look out for how to correctly handle more than one race (you need more than one row in your table, or field in your record, as "multiracial" is not an acceptable response), and ensure that "declined to specify" is one of the choices.

Family History

I was really looking forward to seeing this test procedure, because I hoped it would clarify ONC's intent for Family History, given the muddy distinction between selection of an exchange standard (The HL7 Clinical Genomics Pedigree Model), and a vocabulary standard (SNOMED CT).  I'm still clueless as to how they would test this.  

The functional requirement here is for record, change and access, for which the CG Pedigree model doesn't really apply, or only applies to the degree that the "model" and/or interactions are somehow represented within the EHR.  There's never any inspection as to whether the information is ever exchanged using the CG Pedigree Interactions or Messages.

CCDA Supports exchange of Family History information using SNOMED CT, but once again, exchange isn't part of the requirements, simply record, change and access.

The test data is "vendor supplied."  I'd be a bit more concrete, requiring demonstration of the following relationships: Mother, Father, Sister, Brother, Son, Daughter, and specify specific conditions, e.g., Breast Cancer, Stroke, CHF, Diabetes, et cetera, with different relationships.

Cancer Reporting

Despite assertions (see page 2 of the test procedure) that Cancer Registry Implementation Guide was "harmonized with the Consolidated CDA", the guide still uses templates that were antecedents to C-CDA, rather than the newer Consolidated CDA templates.  It's a shame, because this could have been fixed by replacing the old templates using the map in Consolidated CDA appendix in a matter of hours.  The test procedure is basically to run the document through the NIST CDA Validator with a specific rule set.  No real issues with this test, but I think we'll see it being little used because it's an optional criteria, and is incompatible with C-CDA (which is required).