"Clinical software requires models of work, and not simply models of data"

"Electronic records, in concept and rendition, address most directly those aspects of clinical care that are addressed by paper charts. Attempting to force EHR systems to exceed their original design conceptualizations will only continue to disrupt the work of busy clinicians while delaying serious investigation into better metaphors for clinical software designs."

I closely follow the posts of Jerome Carter, MD over at "EHRscience.com." It is an excellent resource. The foregoing comes from his May 11th, 2015 post. While the ARRA/HITECH Meaningful Use is not getting any love these days (particularly in Congress), Dr. Carter has a differing, more nuanced view.

"By encouraging adoption of HIT, the EHR incentive programs have forced everyone to deal with the realities of current EHR system designs. In fact, this might be one of the most significant outcomes of the entire program. Now that there is a general acceptance that HIT needs to evolve in order to better support clinical work, more research is becoming available that details how clinical professionals work and the nature of their information management needs.

Prior to the incentive programs, there was a mostly unchallenged assumption that EHR systems were capable of supporting clinical work needs. The national experiment in EHR adoption has proven this assumption to be false — but not in a bad way (I have no interest in bashing current products). Rather, in disproving the initial assumption, the incentive programs have engendered a level of research into clinical work, interoperability, safety, and clinical software design that I doubt would have ever happened absent the ONC’s efforts..."

One of my principal jobs while with my REC was that of assisting my Meaningful Use participant clients with workflow adjustments sufficient to assimilate the criteria into their normal workflows without costing them additional labor expense just to chase the incentive money (along with trying to help them improve the efficiency and effectiveness of their clinical processes more broadly in pursuit of the longer-term/bigger picture).

Click to enlarge.

I wish I could say I was routinely effective in this regard, but, candidly, my wins were relatively few and far between. Most of my MU caseload comprised economically-stressed small-shop (1-3 docs) outpatient primary care (including a bunch of Medicaid). They were all mostly content to just get through the day, and had little time or inclination to devote to QI initiatives.

I suspect that's still largely the case.

Click-through path-shortening to get at the MU criteria more quickly was about the only thing staff and docs were interested in (and I used to gripe to ONC and vendors that all MU numerator criteria data fields could and should be one-click macro-accessible), and, given that our REC "milestone" funding was tied to getting clients to Attestation, our short-term incentive was to play ball. Lofty talk about significant and sustainable clinical workflow and outcomes improvements remained just that -- high-minded QIO and REC talk.

The rigidities of the "certified" EHRs didn't help matters, nor did the fact that, as a "vendor neutral" REC we had to support about 40 platforms -- all replete with vendors' non-disclosure agreements (I had about 8 of them in my book, mostly eCW and e-MDs, along with a smattering of one-sie's/two-sie's).

More Jerome Carter:

HIT vendors could roll their own workflow tech or build static workflow capability into systems; however, the day when either made sense has surely passed. EHR systems have static workflows and adding new code to current EHR systems every time a new work support need arises makes no sense. Workflow technology is the only currently available approach that makes the problem tractable. The downside of this realization is that current systems would need substantial rewrites to make use of workflow tech; the upside is that the future is coming — no matter what.

I hope Dr. Carter gets some national traction with his work. I am a bit dismayed that the research into "clinical work support" has yet to become the priority it should be. And, I have to take seriously Margalit Gur-Arie's recent assertion that our out-of-focus "interoperability" obsession may be The Tail Wagging The Dog.

On the interop topic,

Stiff interoperability penalties in new 21st Century Cures Act
By Darius Tahir  | May 13, 2015

WASHINGTON—Electronic health-record vendors would have until Jan. 1, 2018, before facing stiff penalties for a lack of data-sharing in the newest version of the 21st Century Cures Act.

The addition is the latest to the smorgasbord of incentives, appropriations, deregulations and regulatory streamlining that make up the 21st Century Cures Act, a legislative package developed by the House Energy & Commerce Committee and intended to kick-start biomedical innovation.

The revised bill—released Wednesday morning—is difficult to digest in one sitting, and touches on many areas of controversy. For example, consumer advocates may be concerned by the restoration of exclusivity periods for drugs treating rare or pediatric diseases, which had drawn criticism in previous iterations of the bill.

But the most significant addition may be the tough interoperability provisions for EHR vendors, intended to ensure that there are no technical or economic barriers obstructing providers from sharing clinical data... 

Interesting that the JAMIA research paper Dr. Carter cites in his post also mentions "interoperability."

Interoperability

Participants emphasized the need to exchange clinical data with providers within and outside of their own PCMH networks. All PCMH participants expressed frustration with and concern about their ability to appropriately coordinate care and meet PCMH reporting requirements using current HIE. This was particularly challenging for each of the two PCMH organizations (A and B) in which practice sites could use different EHRs. Although both PCMHs were sending clinical data to partnering RHIOs, participants from PCMHs and RHIOs each discussed having to dedicate resources to clean and harmonize CCD-based data. The challenges at these two organizations led the PCMH participants and non-vendor stakeholders to conclude that their quality and cost-containment efforts would have been more effective had each PCMH mandated use of the same EHRs. PCMH C noted that its health system’s providers had difficulty exchanging data with specialists outside the system. EHR vendor participants also recognized there were barriers to interoperability using today’s CCD standard, which could limit care coordination among PCMHs.

PCMH participants expressed a need for low-cost solutions for HIE interfaces to achieve effective interoperability. Given that PCMHs A and B maintained multiple EHRs, they noted that the costs were too high for them to pay vendors to develop and maintain HIE interfaces between those EHRs. Still, the reported needing lower cost HIE interfaces extended to PCMH C, which used a single EHR system: “The maintenance of all those interfaces – the costs are ridiculous …”

...As discussed previously, participants described a growing need to support data sharing efforts among PCMHs both within and outside of their health systems, for collaborative efforts. However, challenges with interoperability – including uniform agreement on the types of data to collect, how the data would be collected, and how the data would be stored for eventual reporting requirements – impede such data sharing. This issue speaks to acknowledged needs for increased standardization in data representations...

CONCLUSIONS
We conducted interviews with PCMHs, health IT vendors, and associated stakeholders to assess, based on their experiences, how health IT could better support future efforts towards care coordination. We discovered important needs for monitoring tools that enable PCMHs to analyze patient populations; notification tools that enable PCMHs and care managers to detect or be alerted to patterns in their patient populations; collaboration tools that bring together providers and non-providers within as well as across care settings; data extraction tools that enable more efficient reporting; and robust HIE that enables these activities to be achieved efficiently and economically. We encourage further efforts between PCMHs and health IT vendors to focus on these areas of needs in order to improve ongoing and future care coordination efforts.

A good paper, but I found myself chafing at the lack of any detailed discussion as to what precisely constitutes a "clinical support model," one, for purposes here, going to the increasing imperative of "care coordination." Many industrial/manufacturing workflows, and even many service sector workflows, are relatively easy to model and map, given that task variation requiring extensive logic "conditionals" -- branching and looping amid sequential and parallel tasks comprise relatively small exceptions to the aggregate start-to-finish process flows, rather than the norm -- as some would argue to be the prevalent, irreducible circumstance in health care. It is that apparent latter reality that leads, IMO, to frustration with the "hard-coding rigidity" of the current generation EHRs, which are not modular at the task level and endlessly and effortlessly "Lego block" re-configurable.

Another concern is an old one: the "productivity treadmill" reimbursement system that continues to stymie the best efforts at rational and effective "clinical support model" health IT.

Finally, if you're going to derive progressive "models" leading to revised, putatively more efficient and effective "clinical care" policies and procedures devolving down to staff in the trenches, you'd better be able to sell them to staff in a language they can grasp and willingly productively implement. And, ideally, under the "Lean" philosophy to which I ascribe, in-the-trenches staff should be the ones identifying the care support models in the first place.
__

ERRATA

My side project blog concerning the California drought continues.

IDC-10 WATCH

Lordy. Seriously, dude?
___

More to come...