"For decades, electronic patient records systems have been heralded as a potential game-changer..."

"For decades, electronic patient records systems have been heralded as a potential game-changer for the health care industry, leading to improved patient health outcomes, fewer duplicate tests and, eventually, savings for the health care industry."

While most clinicians and academics still believe the promise is there, the systems are coming under increased scrutiny from doctors, nurses and some on Capitol Hill who say the technology is poorly regulated, often unproven and occasionally unreliable.

As such, the health records systems haven’t yet lived up the promise that was made when the Obama administration won passage its 2009 stimulus bill, which included $25.8 billion for health IT investments and incentive payments.

“Like with any new technology, there’s going to be unintended consequences,” said William M. Marella, director of Patient Safety Reporting Programs for the suburban Philadelphia Emergency Care Research Institute. He’s also director of the state’s Patient Safety Reporting System, which tracks adverse events and near-misses in Pennsylvania.

“In the long run, [electronic health records] will make us safer than we were” using paper records, Mr. Marella said. “But in the short term, we’ve got a lot of [implementation] issues that need to be addressed before [electronic health records] meet their promise.”

Last month, the nation’‍s largest union of registered nurses sent a letter to the FDA asking for broader and more stringent oversight of electronic records systems and of computerized physician-order entry systems, which allow clinicians to log treatment instructions for patients.

The National Nurses United, as part of its broader campaign highlighting the potential dangers of “unproven medical technology,” says FDA officials should test electronic medical records as rigorously as they might a new drug or an artificial hip implant.

“I don’‍t think that opinion is an outlier opinion,” Mr. Marella said. “Lots of clinicians are unhappy with the way these systems work, and are unhappy with the documentation burden we put on them.”...

From this weekend's "Complaints about electronic medical records increase."

“We really have to do a lot more work in what we call human factors,” so that the systems are intuitive, he said. “We’re quite a long ways from there.”

Indeed. But, to the extent that "human factors" analysis remains focused on Health IT UX and workflow, it will continue to come up short. Recall my posts "Medical Error, Interop, and the Patient Safety-Health IT nexus" and 'The "Talking Stick" and the three-legged stool of sustained, transformative healthcare QI.'

It behooves us to study closely the works of Jerome Carter, MD, author of "EHR Science." e.g.,

• Is the Electronic Health Record Defunct?

• Building Clinical Care Software Systems, Part I: Issues and Challenges

• Building Clinical Care Systems, Part II: Patient Information

• Building Clinical Care Software Systems, Part III: The Electronic Health Record

"When building software, requirements are everything. And although good requirements do not necessarily lead to good software, poor requirements never do. So how does this apply to electronic health records?  Electronic health records are defined primarily as repositories or archives of patient data. However, in the era of meaningful use, patient-centered medical homes, and accountable care organizations, patient data repositories are not sufficient to meet the complex care support needs of clinical professionals. The requirements that gave birth to modern EHR systems are for building electronic patient data stores, not complex clinical care support systems–we are using the wrong requirements..."

"Creating software is hard. The entire process, from deciding that a piece of software is needed to implementation, requires analysis and problem-solving–every step.   I was reminded of this reality anew when I began the latest round of coding for my seemingly mythical startup. There are so many decisions to make that affect the final product, even though I consider what I am trying to build to be fairly straightforward in design and features. Building a good clinical care software system is many times more difficult.

Given the troubles that are plaguing EHR vendors in meeting MU stage 2 requirements, this seems like a good time to talk about what goes into building a system that supports clinical care. “Tweaking” a complex software system is not a good approach for adding features. It is sort of in the same category as knocking down a wall to enlarge a room.  Sometimes it’s okay, and sometimes there is a cave-in and a lot of noise. Complex software systems are designed holistically; they have an architecture and are designed to meet a specific set of requirements. Once a system is built, changing the requirements too much, too quickly, or both can cause problems. Imagine what happens when a third floor is added to a building that was designed to support only two..."

"This series of posts is about asking questions concerning clinical software design and looking for new pathways for clinical information system research, not offering a specific set of approaches or solutions. Yes, I have a few ideas and suggestions to share, but not in a dogmatic way. I have, by far, many more questions than answers..."

"The informational aspects of patient data are familiar to everyone because those aspects are well known from paper charts. Problem lists, medication lists, SOAP notes, lab reports, etc. provide the information needed for clinical care.  And when building electronic systems that replace paper charts, it is obvious that the informational aspects of patient data must be maintained.  No argument there. However, when building an electronic system to replicate the informational aspects of paper charts, it is easy to overlook the fact that patient data in electronic form should be structured in a way that allows their computational properties to be fully expressed..."
"EHR systems are offered as being both clinical care support systems and replacements for the paper chart, which are two very different things.

Paper charts have non-clinical uses, and those aspects must be supported by any electronic system that purports to replace them. Over the course of their existence, paper charts evolved from being primarily repositories of clinical notes to serving administrative, financial, legal, and regulatory purposes.  Since paper charts serve multiple purposes, designing electronic versions to replace them is much harder than it might first appear because there are so many (potentially conflicting) requirements. One such conflict that is often mentioned by clinicians is the data entry burden.

Designing an electronic system optimized for data capture is obviously not the same as designing one that intimately supports clinical work—ergo, clinician complaints. That being said, these requirements are not mutually-exclusive; however, designing a system that accommodates all of them equally well requires an understanding of how they differ and what they have in common..."

Dr. Carter's site comprises a motherload of relevant HIT information and insight. This (below) particuarly caught my eye:

Is it time for a standard patient data set?
Determining the computational aspects of patient data requires research. At present, this is being done mostly at individual companies. As a result, every EHR system has its own database design with proprietary names, formats, properties, and groupings for data elements.   The same freedom exists for representing higher concepts such as the problem list, medication list, or family history.  Currently, it is difficult for clinical software designers to build on the work of others because so little is discussed publicly concerning clinical system design and construction.  What if clinical software designers setting out to build a clinical system did not have to reinvent the patient-data-model wheel?

Wouldn’t life be easier for everyone if a standard data set specification existed that provided a data model that included the metadata, context, and provenance information suggested by JASON?   The patient data set specification could be managed at a central location (e.g., the National Library of Medicine), and protocols would be in place for adding, naming, and revising data elements and their extended properties.  The latest version of the data set definition and a working implementation example would be available for download.

Such an approach might actually stimulate innovation because modeling for patient data is a huge headache for anyone designing clinical software.  I know this from personal experience… When designing the EHR at UAB, I spent over eight months tweaking the data model. I would have welcomed a “drop in” patient data specification—especially one that had been vetted by a community of researchers and software companies...

 "Standard patient data set"? What have I been arguing for all along?

One.Single.Core.Comphrehensive.Data.Dictionary.Standard
One. That’s what the word “Standard” means -- er, should mean. To the extent that you have a plethora of contending “standards” around a single topic, you effectively have none. You have simply a no-value-add “standards promulgation” blindered busywork industry frenetically shoveling sand in the Health IT gears under the illusory guise of doing something goalworthy.

One. Then stand back and watch the private HIT market work its creative, innovative, utilitarian magic in terms of features, functionality, and usability. Let a Thousand RDBMS Schema and Workflow Logic Paths Bloom. Let a Thousand Certified Health IT Systems compete to survive on customer value (including, most importantly, seamless patient data interchange for that most important customer). You need not specify by federal regulation (other than regs pertaining to ePHI security and privacy) any additional substantive “regulation” of the “means” for achieving the ends that we all agree are necessary and desirable. There are, after all, only three fundamental data types at issue: text (structured, e.g., ICD9, those within other normative vocabulary code sets, and unstructured, e.g., open-ended free-form SOAP note narratives), numbers (integer and floating-point decimal), and images. All things above that are mere “representations” of the basic data (e.g., text lengths, datetime formats, Boolean/logical, .pngs, bmps, .tiffs, .jpegs etc)...

From my post "The Interoperability Conundrum."

I have to further mull Dr. Carter's work in this area over in the context of the Weeds' seminal "Medicine in Denial."

It does little good to subsidize the purchase of EHRs if their inputs are not guided and defined by knowledge coupling software compatible with the EHR design. It does little good to equip practitioners with knowledge coupling software if they are left free to exercise judgment on when to use the software or what data to collect. It does little good to design interoperable EHRs for exchanging patient data if the design does not also organize the data for coordinated care of multiple problems by multiple practitioners over time. It does little good for multiple EHR vendors to separately design such EHRs if variations reduce interoperability and ready comprehension by all. [pg 174]

___

More to come...