Testing for MeaningfulUse Stage2 with Consolidated CDA

Nope, sorry, my schematron generator isn't done.  This is actually on a separate topic.

My rant from yesterday inspired a number of questions, key among them being how would you test the use of Consolidated CDA to support Meaningful Use.  This is actually a good thing, because where we need to be going with Consolidated CDA is towards testing and implementation, not shaking things up again and therefore scaring away implementers (which is what happens when you tell them that the standard is going to change).

Let's assume that ONC and CMS clean up their definitions of a summary care record as I've previously suggested (I have a few suggested edits that help even further).

There are three criteria that mention summary of care record:

1. 170.314(b)(1) Transitions of care -- incorporate summary care record.
2. 170.314(b)(2) Transitions of care -- create and transmit summary care record.
3. 170.314 (e)(1) View, download, and transmit to 3rd party. ... (B)(2) A summary care record ...

I'll skip view, download and transmit because that is all after the fact once you've created an appropriate document from the Consolidated CDA.

For create and transmit above, one of the questions that arises is which CDA Consolidation document should be created.  With the exception of the Unstructured Document, I would allow you to test with any one of them (you could choose to test with more than one, but only one is sufficient).  You would have to demonstrate several things:

1. The document you create is valid according to one of the CDA Consolidation Guide document templates that contains structured data.
2. The data elements in that document meet the meaningful use criteria found in my proposed section 170.208(a)
3. The data elements in that document match the standards specified for them in the Standards rule (see my proposed 170.208(b) at the same location)

To verify #1, you could used MDHT, the CDA Consolidation Schematron that I expect to appear on the S&I Framework Wiki, or a schematron generated from the Trifolia database (which I'm still working on).

Not every document in the Consolidated CDA tells you how to meet the meaningful use requirements explicitly.  This post explains which Consolidated CDA sections can be used to match up to the data elements.  So, to verify #2 above, you'd need a separate test to ensure that the document under test include at least one (and possibly more than one) of the sections which I've mapped to the data elements in the table.

Finally, to verify #3, you'd need to add some tests on vocabulary, where Meaningful Use requirements are stronger than those in the Consolidated CDA specifications.  That's a few additional assertions in a separate schematron, or similar testing capability.

Incorporate is a defined term in the proposed rule.  It means  "to electronically import, attribute, associate, or link information in EHR technology."

As defined, it could match up with IHE "Discrete Data Import" option,  "Section Import" option, or "Document Import" option.  If you proudly explain that you've imported this whole document into your EHR to the test examiners, and then show them where they can pull up the document, my personal feeling as a patient is that I'd hope that would fail.  As I read the rule, the goal behind incorporate is closer to what it means for lab results, which is really import, but they allow for other alternatives, and I've seen some really creative ideas here.  There are some real challenges with respect to incorporate vs. import which I will address in a separate blog post.

Some things might need to be incorporated at a "Section Level", like the care plan, where the details are not yet well standardized, and text is the norm.  But for other things, like problems, medications and allergies, what I expect you will need to show is a patient record that has nothing, then you perform an import, then you show the examiners where each required data element now appears in the EHR.  BTW:  This is the kind of testing that IHE would do for the discrete data import option.

We'd need to understand in the regulation, which of the data elements are expected to be imported discretely, and which could be imported at a higher level (e.g., section or document).  The data elements for which vocabulary is proposed (or would be if it were available in the case of allergies), is probably the maximum limit for could be reasonable expected to be "discretely imported".  The remainder could be imported at a higher level (section or document).

That leads to the following clarification for 170.208(b) in my previous suggestion:


§170.208 Summary Care Record
...
(b) Standards When supplied in an electronic form, the summary care record shall be formatted according to the standards specified in §170.205(a)(3):
(1) Document.  The document shall contain structured entries for data elements described in section 170.208(a)(1) through 170.208(a)(17)
(2) Vocabulary.  The vocabulary used for structured entries must conform to the following standards:
(i) Race and ethnicity. The standard specified in § 170.207(f)
(ii) Preferred language. The standard specified in § 170.207(j)
(iii) Smoking status. The standard specified in § 170.207(l)
(iv) Problems. At a minimum, the version of the standard specified in § 170.207(a)(3)
(v) Encounter diagnoses. The standard specified in § 170.207(m)
(vi) Medications. At a minimum, the version of the standard specified in § 170.207(h); and
(vii) Reserved (For Allergies)
(viii) Procedures. The standard specified in § 170.207(b)(2) or § 170.207(b)(3)
(ix) Immunizations. The standard specified in § 170.207(i)
(x) Laboratory test(s). At a minimum, the version of the standard specified in § 170.207(g)

The bold and italicized text is new.  It is what makes sure that developers can only use the documents with structured entries, and so prevents someone from trying to use the "Unstructured Document" to meet MU requirements.