When Clinical Documents are not Enough

One of the queries in ONC's 2014 Standards and Certification Criteria was on something that was originally described as a "Green Button"  (see slide 13) in a list of ONC Proposed S&I Initiatives back in late 2010.  Of course that button color has since been taken over by Smart Grid to enable customers to download their power consumption data, so they'd have to choose another color for it.

The request is under a section on Data Portability in the proposed rule.

We seek public comment on whether we should adopt a certification criterion that focuses on the portability of data stored within CEHRT. When a provider seeks to change EHR technology, we believe that they should have the ability to easily switch EHR technology—at a low cost—and migrate most or all of their data in structured form to another EHR technology. In the absence of this capability, providers may be “locked-in” to their current EHR technology. This could ultimately impede innovation and is a key aspect of the EHR technology market that requires significant maturity. With these considerations, we seek responses to the following questions:

1. Is EHR technology capable of electronically providing a sufficient amount of a patient's health history using summary of care records formatted according to the Consolidated CDA for the scenario described above?
2. Is all of the data in a provider's EHR #1 necessary to migrate over to EHR #2 in the event the provider wants to switch? We recognize that medical record retention laws affect the provider's overall approach in terms of a full archived data set, but our question seeks to determine whether the loss of some data would be tolerable and if so, which data?
3. Considering the standards we have adopted and propose for adoption in this rule, we request comment on what additional standards and guidance would be necessary to meet these market needs for data portability, including the portability of administrative data such as Medicare and Medicaid eligibility and claims. Additionally, we are interested in commenters' thoughts related to an incremental approach where a specific set of patient data could be used as a foundation to improve data portability for the situation described above as well as other situations.
4. Does the concept of a capability to batch export a single patient's records (or a provider's entire patient population) pose unintended consequences from a security perspective? What factors should be considered to mitigate any potential abuse of this capability, if it existed?

This request is naive, in that it focuses primarily on clinical data used to document encounters in questions 1 and 2.  In terms of what constitutes tolerable loss with respect to clinical history, that really depends on the healthcare provider.  Just looking at what providers are willing to tolerate with respect to transitioning from paper records, I've seen some that scan all at once, others scan for each patient on their next visit, some only scan the last year's history, others scan all data they have, and some just do the last visit.  Some also reenter a complete history (e.g., as my provider did on his transition from paper), so there are a variety of levels for what providers will tolerate.

The documents described in the Consolidated CDA guide are really designed to summarize the important outcomes of an encounter, or perhaps an episode of care.  They were never designed to function as an EHR dump (nor was CCR for that matter).  That doesn't mean some people haven't tried to use them that way.  I've heard reports from one person on Twitter that he's aware of on EHR that dumps their entire patient history into a multi-megabyte CCD.  

ONC does then attempt to address administrative data, in question 3.  But they fail to account for operational data related to dynamic transactions (orders and payments), quality measurement, master file content, or user and access control information.  One of the challenges in quality measurement today (and which is currently being looked at by both the HIT Standards and Policy Committees), is the disconnect between CQM data and EHR data.  There are many questions of intent explicit in CQMs that aren't captured in the EHR, often because they are questions of clinical judgement, (e.g., medical appropriateness),  In a system or workflow where the intent is to document what has been done (or in some cases not done), often what is not captured is why, and that is often the focus of exceptions in CQMs.  So, the documents will have the what, but not often the why.

With regard to question 4, of course there are consequences that must be addressed and mitigations necessary.  Whenever you add new functionality to a product, you need to perform a risk assessment.  I would hope that should be obvious.  I won't get into what those issues are because I'm not a security expert (although John Moehrke is).

In summary: 
So much data goes into the configuration of an EHR, including test compendiums, medication formularies, order processing (including prescriptions), referral networks, data needed to conduct transactions, workflow configurations, clinical decision support configurations, documentation templates, et cetera.  The patient's clinical data is but one component of the data needed.

The real challenge in transitioning is not exchanging clinical data that it manages, but rather, it is in configuring the EHR (which is more of a platform rather than an application) to match the processes of the healthcare provider, and to ensure that the data management supported by the EHR matches those processes.

Are there any other products where such a transition is possible?  Can you just dump all of your SAP data and move it over to Oracle's CRM solution, or to Salesforce.com?  (Unlikely) How about HR Management system?  (Also unlikely) What about your business accounting data; could you just dump your info from one accounting system to another? (It depends on size of the organization and scale of the system -- for anything over small business size, not readily).