Meaningful Use IFR Comments

Like just about everyone else I know involved in healthcare in the US, I've been reviewing the IFR and the NPRM. As you can imagine, I have quite a few comments on the IFR that I'd like to share. 

The IFR seems to be a very realistic and pragmatic approach.  That part of it appeals to the pragmatist in me, but there are other parts that are disconcerting.  Given the state of the industry, this IFR can work, however, as a taxpayer, I really wish the IFR was making better use of the incentives that are being provided.  I'm also an optimist, and I may be too optimistic in my hopes that we can move faster -- time will tell.

The IFR represents a state of EMR use that is just a little bit more than the status quo for organizations that have already implemented an electronic medical record system. While the EHR industry itself seems ready for more than what's been specified, it appears that ONC expects that deployed systems are not. If you look at the adoption numbers for EMR systems, this seems to be reasonable. Providers are still somewhere in the 10-25% range for adoption depending on whose statistics you look at and what markets you are focused upon.  The adoption rate has also increased quite a bit in the last few years (though not as much in the last year I expect).  That means that there are a lot of providers out there with relatively recent EMR implementations that may not be completely ready for meaningful use.  Many will need to have new interfaces implemented to support the IFR.  Given the low bar that has been set, it appears that upgrades might be able to be avoided for many providers with existing systems.  Providers may want to upgrade anyway to get better implementations of the standards that have been selected by the IFR.

What is most disappointing are some mistakes made in the regulation with regard to the capabilities of the standards, and some factual misstatements in the prefatory material.  I understand how difficult it is to write 136 pages of complex text in 3 months, but the key to avoiding them is in following the standards activities.  Many of the issues I identify below have been discussed in great detail here, in SDO discussions, HITSP discussions and in discussions with NHIN work groups, and I believe could have been avoided if there had been more direct ONC participation in harmonization efforts.  I hope this will be addressed in the future.

I won't provide comments here on the prefatory material in the Interim Final Rule, as that material is not itself the regulation.  What follows are some of my observations about the IFR.

§170.202 Transport standards for exchanging electronic health information.
If you want to find the SOAP 1.2 standard, please look on the W3C web site and not the OASIS web site.With all of the discussion of SOAP vs. REST that has been going on in the HIT Standards and Policy Committees, I would expect ONC to demonstrate a better understanding of these standards in the IFR.

Also, with regard to REST, does ONC really mean to suggest that any transport that uses a RESTful approach should be supported?  REST is an architectural approach that can work with HTTP, FTP and SMTP (ever used subscription commands with a mailing list server? That's RESTful). Most RESTful architectures use HTTP as their transport standard.  I would suggest that intention was to use HTTP in a RESTful manner and would hope that they clarify the in the final rule that HTTP is the other transport standard.

§170.205 Content exchange and vocabulary standards for exchanging electronic health information.
(a)(1)

The IFR defines both "Implementation Specifications" and "Standards".  But the IFR adopts an Implementation Guide as a standard.  I would hope that IFR acknowledges the CDA Standard as well as the CCD Implementation Specification.

The magic of the AND in the IFR is a perpetuation of the un-harmonized use of standards in the industry that we've been trying to move away from since about 2006.  We must support two standards, and then make one of them go away in two years.  I really don't have any concern about a competition between the selected standards, because I believe the best one will win.  What I am concerned about is that the IFR makes no choice now, and thus incentives are A) not supporting movement in the industry, and B) supporting duplicated effort the costs of which will be borne by providers.  I don't think this was the point of choosing standards in the first place.



(a)(2)(iv)  and (c)(2)
While we'd like everyone to use RxNORM eventually, the IFR itself selects the vocabularies that went into it but not RxNORM itself.  I believe this is just an oversight and hope that it too is corrected in the final rule.

§170.210 Standards for health information technology to protect electronic health information created, maintained, and exchanged.
(a)(1) I was able to find at least 10 symmetric 128 bit fixed block ciphers capable of using a 128, 192, or 256 bit encryption key.  That's not sufficient identification of a standard, and as John Moehrke points out in his blog, could allow XOR with a fixed encryption key which is extremely insecure (it can be broken in seconds).  Most of the cipher algorithms have notable defects and several were NOT chosen as the replacement for DES because of those defects.  Couldn't we just say "AES", or better yet, "a FIPS 140-2 approved cipher function" (see Annex A of FIPS 140-2).  This might provide an incentive for some vendors to support AES in versions of their IT products installed at healthcare institutions today.  Furthermore, it would also support other suitably secure ciphers readily available by providers for communication and storage (e.g., via VPN, TLS and through disk encryption).



(b) This is just a minor nit.  With regard to SHA-1 or higher, I'd prefer that they list out the specifics (SHA-1 or SHA-2 family).  SHA-3 is currently under development and is expected in 2012, but do we want to identify something that doesn't exist yet?  There should be sufficient time to change the regulation to adopt SHA-3 when it becomes readily available (which will be a couple of years after it gets selected).



§170.299 Incorporation by reference.
(c)(3) The title of the HL7 CCD does not contain the words "Level 2".  That's a concept found in the CDA Standard.  Inclusion of this term could imply that "Level 3" is prohibited, but that would be counterproductive given other requirements of the IFR (e.g., medication reconciliation) which would seem to require it.



§170.302 General certification criteria for Complete EHRs or EHR Modules.
I find the text which appears in multiple locations following this structure to be confusing to read.
At a minimum, the version of the standard specified in §170.###(a)(#)(i)(A).
It should be altered to read:
The standard specified in §170.###(a)(#)(i)(A) or a later version of that standard.
It means the same thing and is easier to understand.


(j) Check insurance Eligibility and (k) Submit Claims
These two functions are more often found in what the industry calls "practice management" or "revenue cycle management" systems rather than EHR systems.  I agree with the selected standards, but wonder whether conflating these systems together with the EHR is useful.

The text found in §170.306 (d) regarding Electronic copies of healthcare information should be moved up to §170.302 and altered slightly.  First of all, the need to be able to view discharge summaries is much more frequent in ambulatory settings where followup care is performed, than in inpatient settings, where one would hope the patient wouldn't wide up again, so both ambulatory and inpatient settings need to be able to view the discharge summary.  

§170.306 Specific certification criteria for Complete EHRs or EHR Modules designed for an inpatient setting.(d) This text talks about exchanging diagnostic test results, problem list, medication list, medication allergy list, immunizations, procedures and discharge summaries in a CCD.  

I've said in the past (see If I had a Hammer) , repeatedly that neither the CCR nor the CCD contain appropriate sections for discharge summaries.  These are ancillary documents that can be referenced by the CCD or CCR, but should not be incorporated into it as a whole document for several reasons.

1. The discharge summary is a separate report required by accreditation agencies of inpatient hospitals
   
2. It contains information duplicated (problems, meds, allergies, procedures, et cetera, ) in the standards identified in §170.205(a)(1) of the IFR (CCD and CCR).
3. But there is no place in the CCR (or the CCD) for a "complete" discharge summary.  These are transmitted in both as references to other docuements.
   
4. The discharge summary also contains important information for which there is no real place in the CCR (and thus the CCD).  For example, the discharge summary contains Admission and Discharge Diagnoses, and Hospital Course.  You could put the Admission and Discharge diagnoses in the problem list, but you would have no way to identify them as such, and that could be confusing and might result in patient safety issues if the Admission DX which was changed at Discharge to something else (e.g., from Heart Attack to Ulcer).  Not having a place to put Hospital Course misses much of the detail of the Discharge Summary.
   
5. Presently, it is often available as text, which would make it suitable for transmission using CDA, but not CCD.

This post is already long enough, so I'll comment later on the NPRM.  

As always, the comments that I make upon this blog reflect my own opinions and not necessarily that of my employer.