Monday, November 15, 2010

Some Thoughts on MeaningfulUse Phase 2

Last week I was kicking around some ideas for phase 2 of Meaningful use with some colleagues in the standards and interoperability space.  My basic idea is that now that ONC has taught itself and some EHR vendors how use a hammer, we should move on to the other tools in our tool box.  Essentially, what I'd like to see is that all summary documents meet the ONC data requirements, without necessarily requiring it to be a C32 document.  It just needs to conform to the section and entry requirements:

The change in the regulation is pretty simple:
§ 170.205 Content exchange standards and implementation specifications for exchanging electronic health information. The Secretary adopts the following content exchange standards and associated implementation specifications:
(a) Patient summary record—
(1) Standard. Health Level Seven Clinical Document Architecture (CDA) Release 2, Continuity of Care Document (CCD) (incorporated by reference in §170.299). Implementation specifications. The Healthcare Information Technology Standards Panel (HITSP) CDA Content Modules ComponentSummary Documents Using HL7 CCD Component/C32C83incorporated by reference in §170.299).
(2) Standard. ASTM E2369 Standard Specification for Continuity of Care Record and Adjunct to ASTM E2369 (incorporated by reference in §170.299).
Essentially, what we are saying is that the test results, problems, medications, allergies (and procedures if a hospital or CAH) would be in conformance with HITSP/C83 CDA Content Modules, per the following rules:

§ 170.304 Specific certification criteria for Complete EHRs or EHR Modules designed for an ambulatory setting.
(f) Electronic copy of health information. Enable a user to create an electronic copy of a patient's clinical information, including, at a minimum, diagnostic test results, problem list, medication list, and medication allergy list in ... The standard ... specified in §170.205(a)(1) or §170.205(a)(2)...

(h) Clinical summaries. Enable a user to provide clinical summaries to patients for each office visit that include, at a minimum, diagnostic test results, problem list, medication list, and medication allergy list. If the clinical summary is provided electronically it must be ...Provided on electronic media or through some other electronic means in accordance with  ... The standard ... specified in §170.205(a)(1) or §170.205(a)(2)...


(i) Exchange clinical information and patient summary record — (1) Electronically receive and display. Electronically receive and display a patient's summary record, from other providers and organizations including, at a minimum, diagnostic tests results, problem list, medication list, and medication allergy list in accordance with the standard  ... The standard ... specified in §170.205(a)(1) or §170.205(a)(2)...


(2) Electronically transmit. Enable a user to electronically transmit a patient summary record to other providers and organizations including, at a minimum, diagnostic test results, problem list, medication list, and medication allergy list in accordance with ... The standard ... specified in §170.205(a)(1) or §170.205(a)(2)...
§ 170.306 Specific certification criteria for Complete EHRs or EHR Modules designed for an inpatient setting.

(d) Electronic copy of health information. (1) Enable a user to create an electronic copy of a patient's clinical information, including, at a minimum, diagnostic test results, problem list, medication list, medication allergy list, and procedures ... The standard ... specified in §170.205(a)(1) or §170.205(a)(2)...
(f) Exchange clinical information and patient summary record — (1) Electronically receive and display. Electronically receive and display a patient's summary record from other providers and organizations including, at a minimum, diagnostic test results, problem list, medication list, medication allergy list, and procedures in accordance with  ... The standard ... specified in §170.205(a)(1) or §170.205(a)(2)...
(2) Electronically transmit. Enable a user to electronically transmit a patient's summary record to other providers and organizations including, at a minimum, diagnostic results, problem list, medication list, medication allergy list, and procedures in accordance with ... The standard ... specified in §170.205(a)(1) or §170.205(a)(2)...
So, what changes are required for systems meeting Phase I requirements to meet that requirement?  Depending on how they are written, none, but otherwise small.  If those solutions were written to import data based on whether they used the C83 defined sections, there are NO changes required.  If they were written to only work with the HITSP C32, then, they have to condition the imports on the C83 defined sections and entries (which by the way, C32 already requires).
What changes in the tests?  Instead of looking for the C32 template ID, you look for the C83 template ID, and if present, you test for presense of appropriate entries from C83 to meet the criteria.  Again, not a big change. 

Huh?  What is the point of this change?
The point is that ONC use of the C32 is as a hammer right now.  The way the regs are currently written, physicians document their care, and incorporate content from what they've already documented into a C32.  What we can do under the rules as rewritten above is actually use and exchange the original documentation created by the healthcare provider during the encounter.  That way, a History and Physical, Consult Note, Discharge Summary, Referral Note, et cetera, which contains the same summary information as a C32 can stand in its place.

Now, it really only took a year or two for many engineers to pick up on this concept at IHE Connectathons.  This is because engineers are inherently lazy (I speak for myself in this), and in a good way.  We want to avoid writing new code, and so look for ways to reuse stuff we have already written.  So, by making sure that problem, allergy and medications lists show up the same way in every IHE profile, we made sure that we didn't have to rewrite code that dealt with them.  The same thing is true in the HITSP Specifications as much as possible (we didn't have time to fix everything, but we did cover most of it).  So, if your system can generate a consult note (C84), H&P (C84), referral note (C48), discharge Summary (C48), ED Note (C28) or patient summary (C32), you can meet the criteria as rewritten above because they all rely on the same definitions in C83.

There are other advantages:
1.  The same documents that are generated as part of existing provider workflows can be used to meet the patient summary requirements.  There are just more kinds of documents, and the additional content can be made available to patients for better patient access.  For example, the discharge summary (required under existing regulations in inpatient settings), can be used to meet both the discharge summary and patient summary requirements.
2.  Documents are identified based on the type of visit: Consultation, H and P, Discharge, ED Note, et cetera, so when patients or providers go looking for information, they can see the type of service provided.
3.  The same content used for clinical care can support claims attachments for just about every kind of note described in the Clinical Reports attachment guide, which is another regulatory requirement we'll be required to meet by 2014 under ARRA.

For #3, the Patient Protection and Affordable Care Act (P.L. 111-148) states in §1104(c)(3):
(3) HEALTH CLAIMS ATTACHMENTS.—The Secretary shall promulgate a final rule to establish a transaction standard and a single set of associated operating rules for health claims attachments (as described in section 1173(a)(2)(B) of the Social Security Act (42 U.S.C. 1320d–2(a)(2)(B))) that is consistent with the X12 Version 5010 transaction standards. The Secretary may do so on an interim final basis and shall adopt a transaction standard and a single set of associated operating rules not later than January 1, 2014, in a manner ensuring that such standard is effective not later than January 1, 2016.
Now, wouldn't it be novel if the care we were getting and the information which was being used to pay claims for that care were using the same standards?

3 comments:

  1. Thanks Keith, this is obviously well thought out and put together.

    Just some thoughts:

    My only comment is about packaging/messaging (not HL7, but marketing/PR type). It is easy to call out a requirement by pointing to a single standard/specification. It becomes more complex when we start to point to a container specification and try to point out the required sections for specific purposes, particularly when done in an inexact way (e.g. medications – does that mean the medications section, Admission medication history section, Hosp discharge meds section, and/or medications administered section). This is why, in part, there is a reliance on pointing out the simple document name (type). Believe me, I understand what we are going for here, and I understand the structure just about as well as anyone else (some present company excluded of course).

    My concern is about messaging and ease of addressability. The beauty of it will be lost on some people because of perceived complexity. Seems simple to you and I, but maybe not as much to others that have not been as involved. I am not saying this is not the direction needed to be taken (in fact I share your vision), my question is how can we make this more easily digestible. That is what brings us back to the document type. If we are defining minimal section requirements, doesn’t that effectively start to equate to a document type? Or perhaps for the regulations it is ok enough to say “clinical summary” or “patient summary record” (as long as it is used consistently). But the question also extends to testing. In order for testing tools to be sure the required sections are included, they will either need some sort of identifier telling it so, or will require a person asserting what the requirements are.

    ReplyDelete
  2. Thanks Keith,
    I am new to HL7 and I had soe questions about Electronic Copy of Health Information, how to achieve this using CCD firmat or which format is recommendn to achieve for certification criteria please give me example which of the hl7 datafields are implemented in ccd or how the structure of CCD

    Thanks,
    Ashish

    ReplyDelete