Electronic Medical Records

08/02/2005 20:11:51
tags: medicine

MedicalThoughts

Requirements for an Electronic Medical Records System

You would think that the people who write the software don’t bother to actually get input from practicing clinicians…

Here are some basic requirements for a solid electronic medical records system, as well as features that could really improve healthcare for the practitioner and the patient:

  • Open Standards - the file format and interfaces must be built on non-proprietary standards to allow communication between systems

  • Multi-platform - let’s face it - Windows sucks. I won’t build the information infrastructure of my practice on a substandard operating system when better (and cheaper) alternatives exist

  • Open-Source - ideally the core of the software would be open-source. The way that EMR systems will get better, is by feedback and improvements from the people who actually use them. There are a large number of physicians and other healthcare professionals who are also “computer-geeks”. They are the ones who are going to come up with the best ideas!

  • Adaptive - the software should adjust to the way I work, not the other way around. See software such as Launchbar and Quicksilver for examples of software that learns your shortcuts and makes common tasks simple

  • Intelligent - it should recognize what you are trying to do, and provide you with the information you need for the task at hand, while filtering out other information. For example, when entering information about a patient’s diabetes, pertinent labs, medications, and health maintenance items should be displayed to the side for easy reference.

  • Assist with following the myriad of regulations that exist - validate that you have met the criteria for the episode’s level of service for insurance billing

  • identify trends early - computers can pick up certain patters more readily than a busy human - a warning should appear when certain values are headed in a dangerous direction, BEFORE the cross the threshold to an “abnormal” value (e.g. when a patients platelet count begins to fall - the trend can be identified before the absolute value is technically abnormal)

  • communicate with other systems - identify when a patients’ prescriptions are running out of refills and flag this before it becomes an “emergent” issue at 3 am on a Sunday morning, or when prescriptions are not being filled - this could prompt a follow-up call to see whether funding has become an issue, etc.

  • track the “little things” - it’s easy to lose site of the big picture amidst an onslaught of problem-focused visits. A computer can easily track whether your diabetic patients are having Hgb A1C’s checked appropriately, yearly eye exams, etc. There is no reason that a person, much less the physician, needs to comb through charts to keep track of this when a computer can do it faster and more accurately

NOTE

As I think about this, I would be interested in forming a group of healthcare practitioners/computer-geeks who share my dissatisfaction with the current state of medical computing and want to do something about it. I don’t know where this would lead - writing software? Compiling a list of requirements? Evaluating current software? If you’re interested in this concept, let me know.

Similar Pages

Comments

Leave a comment