Is it Time for a “Simple” Electronic Health Record System?

by Jerome Carter on February 16, 2015 · 14 comments

Recently, I participated in a series of emails about creating teaching materials for a course on clinical software design.   This may come as a surprise, but there are no books on the topic of clinical software design.   Of course, there are plenty of books about clinical software systems, especially EHR systems, but none that describe in detail how to design and build clinical care systems.

One reason for the lack of books is that most clinical software is designed and built by commercial entities.   The resulting systems are proprietary and the processes used to build them, trade secrets.   In light of the recent statements from the AMA (1) and ACP (2) regarding EHR usability and support for clinical documentation, obviously more needs to be done. A general picture of desirable clinical care system features emerges from those reports and other sources. The ideal systems are modular, recognize that one size does not fit all, have explicit support for workflows, allow for a degree of end-user configuration, support collaboration and communication, and can easily share data. As I have said many times, requirements are wishes until rendered in code.   So how do we turn wishes and user complaints into next-generation products? Guess what? No one knows for sure…

Vendors are not withholding features or deliberately building systems that underwhelm users. There is no conspiracy.   They are building exactly what has been requested—electronic replacements for paper charts (see Is the Electronic Health Record Defunct?). Meaningful use, while a distraction for sure, does not explain why pre-HITECH EHR systems lacked workflow support or collaboration tools or could not readily share information.   Those functions were simply not considered compelling at the time.

Consider current EHR products from another angle.   A few major academic systems spent years and a lot of dollars developing in-house clinical systems. Yet many of those centers are abandoning their homegrown systems for commercial products. Why? VistA, an enterprise-level EHR system developed for VA Medical Centers, is free. Why has it not been widely adopted? VistA was built over years and could be readily customized, but still evinces many of the same issues seen in commercial systems (3, 4, 5).  I am not knocking anyone. However, if, after years of effort, the brains and money at the VA and top academic centers were not enough to build the type of systems that are being demanded, then something more than commercial vendors listening to their clients is required.   But what???

We need more experimentation with computerization of clinical concepts, and the details of those experiments need to be shared.   While there are many papers available that discuss the EHR systems from the VA and academic centers, few papers discuss the nuts of bolts of coding the systems, object models, data models, or why specific designs were used or abandoned. Publications lack the information needed to extract design principles, engineering hints, or coding best practices. As more homegrown systems are replaced with commercial ones, it becomes less likely that this information will ever be shared.   So how do we develop scientific and engineering principles for clinical care systems if no information is shared?

Simple EHR: a reference clinical care system
Perhaps creating a simple EHR system that could act as a reference clinical care system (RCCS) that anyone could download and work with is a good starting point. “Simple” means that the RCCS would begin with a few basic attributes (a user interface, standard data set, and clinical work models). Most problems articulated by clinicians involve one or more of these components, which is why I think they should be first.  Starting with these basic components, researchers, hobbyists, entrepreneurs — anyone — would be invited to create a working implementation of a clinical care system that could be used to document visits.   Such an approach would attract more minds while making it easier for all involved to share ideas, frustrations and breakthroughs using a common set of terms, concepts, and code.

An RCCS should NOT be constrained by trying to make it fit current informatics standards (e.g., SNOMED, CDA, etc.).   Those standards are from a different era with a different view of clinical care systems.   We are not trying to renovate the past, but invent the future.

There is no need to try and build a complete software system in a few months.   The goal is promoting experimentation, which requires the ability to ask questions and challenge the conventional wisdom.

Clinical work models
Experts in usability, cognitive engineering, socio-technical theory, and human factors recognize the importance of workflow and information needs, but there is no standard way of annotating or describing clinical work concepts across these domains. (I’ll discuss clinical work models in detail in upcoming Clinical Workflow Center articles). Fortunately, clinicians are making clinical work support a high-profile concern (1, 2, 6, 7). Working with clinicians to build clinical work models is the next logical step. Again, experimentation is the key. Models must be testable, and testing should not be delayed for years.   Starting with a basic notion of clinical work, a few models could be built, vetted, and tested with all the details and lessons learned made public.

Standard data set
A standard data set (SDS) defined for key patient record elements would provide a good foundation for experimenting with data exchange and data quality issues.    A SDS would set standards for element names, codes, data formats, types, etc. Compliant data schema could be created from the SDS specification, allowing everyone to use the storage system of his/her choice while maintaining a standard information model. Every provider organization would have a unique SDS code and sharing data would consist of sending data in SDS format along with provider provenance information.   Using SDS as described would simultaneously constrain meaning (semantics) while making data origin and movement explicit.

Years have been spent trying to create a system that could export an arbitrary set of data elements from one EHR system’s proprietary data model, encode them within a rich semantic framework, then have them imported into a second arbitrary EHR system, which then decodes the semantic information and inserts those data into its proprietary model.   This approach has not worked. HL7 V3 RIM, the exemplar of this approach, could have been designed by Immanuel Kant, and it would have been less obtuse. There is a reason FHIR is eagerly anticipated.

Sharing data is much easier if everyone shares the same definitions.   Why not focus on the definitions instead of trying to build a universal translator?  The purpose of data exchange is making clinically-relevant information available to support clinical work. Exchange standards should focus on getting information to humans who are interacting with patients and making decisions; that is what clinical care is about. Period.

Data quality cannot be overlooked. Poor quality data is a safety issue. Where are the metrics for clinical data quality (8)?   A standard data set could provide the basis for developing data quality assessments (see Wrestling with EHR Data Quality ).

User interface
Two types of user interface issues seem to be dominant: documentation creation and clinical work support. Being very different issues, the solutions will be different.

Documentation support is driven by billing and regulatory issues as much as it is by the need for clinicians to keep a record of what they do.   Getting rid of E & M coding would certainly help.   Meaningful use has contributed to documentation woes as well. In cases where the problem is a need to check off specific items, a solution might be to move data capture to another job role.

Supporting clinical work means understanding what is being done, the information required, and in what form that information must be.   Generally speaking, clinical work support has been addressed by putting every possible piece of information on the screen, which makes locating and reading a specific item difficult.   Models of clinical work would offer more specific guidance on information displays. In addition, models would make it easier to test display layouts and compare results.

Targeted training and research
Obviously, clinical software design cuts across many domains and each domain has its own professional societies and academic journals. Most formal work on business processes and workflow does not appear in PubMed, though it is readily applicable to clinical software design.   Progress, at some point, absolutely requires a common literature, conferences, textbooks, and courses so that a shared vocabulary and conceptual framework can gel.

It is time for the First Annual Conference on Clinical Software Design, the first edition of Clinical Software Design Book of Knowledge, and the first issue of the Journal of Clinical Software Design. Further, that journal should devote space to case studies in application design, user interface tweaks, and other practice-focused articles. A few trade publications, a la Dr. Dobb’s Journal, would be nice, too.

Creating the next generation of clinical software requires new thinking and new approaches. Everything must be questioned—rounding up the usual suspects will not do…

  1. Improving Care: Priorities to Improve Electronic Health Record Usability. American Medical Association, 2014. Accessed at https://download.ama-assn.org/resources/doc/ps2/x-pub/ehr-priorities.pdf
  2. Kuhn T, Basch P, Barr M, Yackel T; for the Medical Informatics Committee of the American College of Physicians*. Clinical Documentation in the 21st Century: Executive Summary of a Policy Position Paper From the American College of Physicians. Ann Intern Med. 2015 Jan 13. [E]
  3. Saleem JJ, Russ AL, Justice CF, Hagg H, Ebright PR, Woodbridge PA, Doebbeling BN. Exploring the persistence of paper with the electronic health record. Int J Med Inform. 2009 Sep;78(9):618-28.
  4. Flanagan ME, Saleem JJ, Millitello LG, Russ AL, Doebbeling BN. Paper- and computer-based workarounds to electronic health record use at three benchmark institutions. J Am Med Inform Assoc. 2013 Jun;20(e1):e59-66.
  5. Saleem JJ, Flanagan ME, Wilck NR, Demetriades J, Doebbeling BN. The next-generation electronic health record: perspectives of key leaders from the US Department of Veterans Affairs. J Am Med Inform Assoc. 2013 Jun;20(e1):e175-7.
  6. Sinsky CA, Beasley JW, Simmons GE, Baron RJ.Electronic health records: design, implementation, and policy for higher-value primary care. Ann Intern Med. 2014 May 20;160(10):727-8.
  7. Krist AH, Beasley JW, Crosson JC, Kibbe DC, et al.Electronic health record functionality needed to better support primary care. J Am Med Inform Assoc. 2014 Jan 15. [E]
  8. Weiskopf NG, Weng C.Methods and dimensions of electronic health record data quality assessment: enabling reuse for clinical research. J Am Med Inform Assoc.  2013 Jan 1;20(1):144-51.

 

Facebooktwitterpinterestlinkedinmail

Leave a Comment

{ 14 comments… read them below or add one }

jim ryan February 19, 2015 at 11:19 PM

just reading the comments shows the need to have a vocabulary to discuss the processes that a system attempts to accomplish. there could be many core systems, many core processes upon which health care can benefit. we can only imagine those systems that we can imagine, but collectively and over time there will be more. you analogies to optics again returns. how can i compare my process to those of other systems as they emerge?
https://vimeo.com/115371174 (for the guys who haven’t seen it)
i often struggle trying to explain the elements to others, i can’t wait for you to put your model forth.
i’m posting a link to a book that is worth a gander, he has some good ideas.
http://www.amazon.com/gp/product/9198170600/ref=oh_aui_detailpage_o04_s00?ie=UTF8&psc=1
this site is getting more exciting, looking forward to your next post.

Reply

Jerome Carter February 20, 2015 at 1:38 PM

Jim, thanks for your comment. It’s interesting that you mention having a common vocabulary. I have been fixated on definitions (math does that to one) for the last week. As a result, Bertrand Russell has become ever more interesting. At some point, I will have to do a post on “The present king of France is bald.” in the context of informatics.

Reply

Thomas Beale February 19, 2015 at 4:41 AM

Hi Jerome,
your challenge could be slightly restated as: provide a core EHR system that is open, scalable (if not, you have to rewrite it into something that is), sustainable (if not its development process can’t keep going), and semantically computable (if not, why bother, go back to paper).

Our experience in openEHR has shown us all these things are attainable. The main thing I would say here is: separating the clinical semantics (data and workflow) out of the software and DB are critical for success, in other words, the simplest thing you can do that will work is model-based engineering. If you are not doing that, you’ll fail on the sustainability and scalability requirements.

Stated another way, you don’t want a ‘standard data set’, you want a standard, repeatable content modelling process.

Reply

Jerome Carter February 19, 2015 at 8:21 PM

Thomas, thanks for your comment.

A few things…
When I use the term “EHR system, “ I am referring to a specific piece of end-user software, not a conceptual framework or specification.

I admire your work on openEHR, especially archetypes. I wish there was more practical implementation information available that showed how to, step-by-step, build an openEHR compliant EHR system with non-trivial code examples. Has someone created an ambulatory EHR system using openEHR for which the source code is available?

Actually, I do mean a standard data set. Primary care docs have different needs from cardiologists, for example. Specialty-specific products would better suit the needs of users than a generic platform. As I envision them, standard data sets are comprised of a specific collection of data elements that are considered essential for a specialty area with primary care being one such specialty domain. In some cases, standard sets might even be disease specific. Data quality is an important problem–a standard data set could help to address such issues. Standard data sets are not an alternative to archetypes.

There seems to be an unspoken assumption (not on your part, but in general) that providing EHR systems that are safe and that enhance clinician productivity will be trivial once semantic issues – terminologies, ontologies, semantic interop, etc. – are resolved. If all semantic problems were solved tomorrow, usability, safety, collaboration, practice optimization, patient engagement, and care coordination would still be problems for busy clinicians.

More needs to be done to encourage experimentation and research into the design and development of software that clinicians use, which is gist of my post.

Reply

Thomas Beale February 23, 2015 at 9:12 AM

Re: the standard data set, you said originally: Why not focus on the definitions instead of trying to build a universal translator?

I agree with this – it’s exactly what’s needed, and what the model-based approach is about, including catering for the differences between specialists, GPs (even for the same data) and other types of carers.

We model full data sets as templates based on archetypes – e.g. any kind of diabetic or cardiology data set – it’s an ADL template, based on the underlying data points defined in archetypes. These data sets are how real systems are built, with real forms, reports and so on.

The CIMI effort (opencimi.org) – led by Stan Huff @ Intermountain is just a more internationalised version of this.

I agree with you on the ‘unstated assumption’. The UI/UX is far from trivial, and it is a decades long exploration in itself. Some of the current systems whose data are terrible probably have some good quality UI/UX. I would say that the challenge is getting this all together in a single solution.

The only realistic way to do that is for high quality UI applications to be sitting over the top of an openEHR health information / workflow platform. Things like FHIR are an element in that – but are not yet model-based, so introduce a new layer of transformation.

I do agree that all the things you mention in your penultimate paragraph are real challenges. I would just say that without various platform layers that enable * data * workflow * notifications * higher level clinical concepts like managed care plans, and so on, that the applications of the future will only be available on top of totally proprietory systems, greatly limiting their value.

Reply

Thomas Beale February 23, 2015 at 9:13 AM

[correction] – I meant to say ‘over the top of a health information / workflow platform’. openEHR is clearly just one way of doing this.

Reply

Jerome Carter February 23, 2015 at 4:08 PM

Thomas, you don’t need to convince me of the value of the archetype approach. In the US, there does not seem to be much awareness of openEHR tech, especially among developers/entrepreneurs. What steps are being taken to spread the word within the US HIT developer community (that is, outside of large corps and academic circles)?

On another note…

Your essay, “The real reason most software fails,” is one of the best I have ever read on the topic. It is exactly the kind of content I would hope to see in a journal or trade publication dedicated to clinical software design. I have no idea how to start a journal, but there really needs to be one.

Reply

Adrian Wilkins February 17, 2015 at 12:20 PM

I’ve actually seen healthcare IT code that is pleased to cite disciples of Kant…

I think the focus on structured data is taken too far.

After all, what is the primary purpose of a medical record? To communicate, either with those who are working on the same case, or those who will work on that case later, or even with yourself.

You only need the fully structured communications where a machine has to do some work. For everything else, you should only need plain text, and maybe the ability to capture doodles. Humans have a marvellous ability to convey and infer meaning.

The traditional cardboard notes folder aids communication by dint of collecting notes from clinicians dealing with their case, and by following the patient. The majority of the benefits of an EHR could be realized by removing the need for their notes to follow them around physically.

Focussing on special UIs for this and that and everything else makes learning to use the system a pain. You shouldn’t have to learn a system – you should just pick up where you left off, but the notes are on a screen, not a piece of paper. The extension of the “correspondence” paradigm of work flow management which dominated paper medical records (referral letters, lab reports, etc) should integrate simply and intuitively – you should have an inbox, not have to visit several different applications to receive all the updates you need to view.

Note that I’m coming from the UK / NHS point of view here. Billing is not such a concern. I think much of the imeptus for all that structured data comes from the perceived need to use the medical record to drive billing : you only have to look at HL7 v2 with at least 2 chapters devoted to billing and insurance claims.

Reply

Jerome Carter February 17, 2015 at 2:14 PM

Adrian, thanks for your comment!

I agree–systems should be easy to learn. Billing has had a significant impact on system designs and subsequent complaints. At some point, it all boils down to helping clinicians do their jobs. User interfaces should be configurable. When text works best, that should be available and when structured data would be best, then that should be available. Ultimately, helping someone do his/her job is a matter of understanding what they actually do and why. Using clinical work as a design aid is the best way to build systems that are easy to learn.

Reply

Titus Schleyer February 16, 2015 at 11:43 AM

<>

Actually, I do not think that is quite true. http://inspiredehrs.org/ is billed as a book and certainly looks like one.

Thanks for the post!

Titus


Titus Schleyer, DMD, PhD
Clem McDonald Professor of Biomedical Informatics
Director, Center for Biomedical Informatics
Regenstrief Institute, Inc., 410 West 10th Street, Suite 2000, Indianapolis, IN 46202-3012
Web: http://www.regenstrief.org/cbmi/, Blog: http://titusschleyer.wordpress.com

Reply

Jerome Carter February 16, 2015 at 3:42 PM

Titus, thanks for your comment!

This book, along with the text from UT-Houston, and the HL7 EHR Functional Profile, provide information about various aspects of clinical software. And certainly, these usability books are needed and welcomed, but moving EHR design from being about user-interfaces linked to data stores requires deeper architectural and design investigations. Where are the computable models of clinical work? Should user-interfaces be configurable by end users, and if so, what is the best architecture to support that capability? Should a medication list be intelligent (have access to problems and labs)? What is the best object model for clinical decision support? What are the best algorithms for data quality monitoring?
Building next-generation systems requires that clinical software design be studied as a scientific/engineering discipline. More attention should be paid to what exists between the user-interface and the database.

During the Middle Ages, great cathedrals were constructed based on the arcane knowledge of master architects who passed their knowledge on to their apprentices. Today, structural engineering, architecture, materials science, and other disciplines have formalized that knowledge, making it readily available. Clinical software design/development must undergo a similar evolution.

Reply

Sandra Raup February 16, 2015 at 11:24 AM

I have been impressed with the Oscar EMR project at McMasters University in Hamilton, Ontario. It’s an open source project that has a academic institution behind it – it looks like they have a lot of clinical input to the project. I have often wondered why such a project wasn’t undertaken somewhere in the U.S. They probably don’t have the same billing issues we do, but I also wondered if the Meaningful Use initiative was actually anti-innovation.
http://oscarcanada.org/about-oscar/what-users-say-about-oscar

Reply

Jerome Carter February 16, 2015 at 3:52 PM

Sandra, the Oscar EMR is a great open source project, as are OpenMRS and OpenEMR. Anyone interested in clinical software should review their code. In would be great if there was a book that dissected each system to see how much they have in common in terms of basic functions. For example, it would interesting to analyze how each represents family relationships or monitors data quality. There is wisdom in any code; too bad so little EHR code of is analyzed or even available for review. That is why I think a reference system available to all is needed.

Reply

Sandra Raup February 23, 2015 at 4:50 PM

You are absolutely right. I really get confused when trying to compare systems used in other countries because they often have similar but not exactly the same methods and requirements. It sounds like OSCAR is very usable for a practice, but how it is able to use data for secondary purposes isn’t as clear, at least to me here in the U.S. But it’s impressive that they are able to get a high quality system at such a low cost, and I think having the university stewardship certainly helps.

Reply

Previous post:

Next post: