EMR is an acronym for Electronic Medical Record. 

Technically, therefore, any medical record that is stored in a digital format may be considered an EMR and many products use this technicality as a selling point that they are providing physicians with a solution that meets the needs of their practice.  This is not always true.  EMR's may also be incorrectly referred to as EHR's or Electronic Health Records.

So What is the Difference between an Electronic Medical Record (EMR) and an Electronic Health Record (EHR)?

In its most basic sense, an EMR is a computer application that allows you to create, store, edit, retrieve and organize your patient records electronically via a computer. It often mimics the function of your paper medical record system; however, it can do more. The term EMR has been previously referred to as the computerized medical record, computerized patient record, and computer-based patient record.

The EHR on the other hand, is a much more robust version of the EMR. Its advanced functionality allows the EHR system to link to other sources of information, combining data from and interoperating with several different computer applications and databases (i.e., laboratory, radiology, public health registries, prescription order entry systems, etc). This robust capability of the EHR allows access to a vast pool of information for better and more efficient use of clinical information

For simplicity, we will refer to the singular term EMR for the remainder of this discussionThe Three EMR Types:

There is a difference in how digital formats are stored which drastically effects how the data may be utilized.  There are basically only three formats in which the EMR data is stored in today's EMR solutions:  (1) image files such as scanned images of charts, (2) text files such as digital dictation storage or text-based EMR solutions, and (3) encoded data or codified data which is the next generation of EMR solution (very few EMR solutions utilize this last format exclusively).  A select few EMR's utilize combinations of the three.

Below we will discuss all three:

Image format:

Limitations of this type system?

The biggest limitation to this type of system is there is no automatic E&M coding available and there is no way to quantify or analyze data for disease or patient management.  yDocuments™, as well as other imaging-based systems are primarily storage solutions that address the paper portion of every practice.  Return On Investment (ROI) on this type of system is realized primarily through improved office efficiency, re-claimed storage space, and faster EOB turn-around given the quick access to copies of the original documents.  The the aforementioned reasons, this type system is not suitable as a mainstream EMR platfom.  It is however, an ideal ancillary solution for Practice Management/EMR systems.

Text format:

Text format is generally a misnomer, because stored text may only be a part of what the EMR stores.  An EMR may utilize an advanced database system to encode and store data such as SQL or Oracle and an advanced program "front end" to access the data, but the inclusion of text-based elements, such as digital dictation, precludes the ability to completely encode data for later advanced uses.  Typically, due to the limitations of including text-based elements, E&M coding and disease management cannot be aggregated into useful information and the physician must select his or her own code for each visit. Many systems offer a coding assistant based on the number of items selected in a particular category.  These systems are easily recognized because a physician must still choose the level of complexity of the visit.  Text format systems cannot code based on the narrative -- they can only assist.  There may be a Return On Investment (ROI) with text-based EMR's, depending on the solution selected, but it is minimal; typically savings realized in office efficiency and decreased transcription costs.  Text based systems may present themselves in many different formats, such as voice dictation systems, list driven systems, or template-based systems.  The key point to remember, regardless of it's data entry method, is the end result of Text format systems is plain text.

Encoded Data:

This is the most exciting new development in EMR solutions and definitely the future of fast, efficient EMR's that allow doctors to spend less time on charting and more time with patient care, as well as increasing E&M codes for visits that can increase the income of the clinic dramatically.  In this type of EMR solution all data is "codified" or encoded in such a way as to be available for computations that include E&M coding (the AMA estimates that approximately 33% of all visits are under-coded by $27 or more); dynamic automated charting which completely eliminates transcription; as well as advanced disease and patient management, research capabilities and diagnostic queuing.  With this type of product, the physician's office can realize a substantial increase in revenue by the elimination of transcription, increased E&M coding, and improved office and doctor efficiency.  In addition, codified data allows for incredible opportunities in research, data sharing between facilities that preserves patient confidentiality, yet allows for advanced access to patient data.

1. There are basically two standardized codified nomenclatures in use today: SNOMED® and MEDCIN®.

2. Brief itemized list of differences between MEDCIN® & SNOMED®:
   MEDCIN® is a point-of-care nomenclature designed for direct use by physicians; SNOMED® (both SNOMED RT® & SNOMED CT®) was designed for indexing clinical data.  For more than 25 years Medicomp Systems has been designing MEDCIN® specifically for direct use by physicians; for more than 25 years the College of American Pathologists (CAP) has been designing SNOMED® for use by pathologists and epidemiologists as a classification system.

    

   MEDCIN® was designed for use at the point-of-care.  SNOMED® was designed as a classification system to be used after acquisition.  Both systems reflect their beginnings and initial design.  MEDCIN® is a user interface terminology: SNOMED® is a reference terminology.

     

   • Example: SNOMED® references "arm" and "pain" but not "arm pain".  "Arm tenderness" has no meaning in SNOMED®.  MEDCIN® has only meaningful clinical characteristics relating to "arm".  MEDCIN® references "arm pain" or "arm tenderness", rather than "chest" or "pain", as that is more meaningful to the physician.

   • MEDCIN® was built for structured data entry at the point-of-care so each MEDCIN® term is clinically meaningful.  Very few SNOMED® terms are clinically meaningful by themselves, they have to be combined with other terms to give meaning.

   • Users can easily navigate to a MEDCIN® term by drilling "down the tree" of clinical propositions; navigation in SNOMED^® is very difficult unless all terms are pre-built for the user.  Because there are many different ways to say the same thing in SNOMED®, navigation of terms is very hard for the user.  SNOMED® is aware of its lack with structured data entry.

   • Because SNOMED® builds clinical propositions out of smaller units it cannot map directly to other terminologies, such as CPT, nor can it generate E&M codes or address billing issues.  MEDCIN® is composed of clinical propositions which map very clearly to both CPT and E&M code4 bullets such as those in the CMS 1997 guidelines.

   • SNOMED® has difficulty determining the meaning of a concept due to the various ways a term can be constructed.  Each MEDCIN® proposition is clinically explicit because it was built to help describe a diagnosis.

   • MEDCIN® can build sentence and phrasing for text generation from structured data.  SNOMED® cannot, except if a list or form explicitly defines the narrative -- there is no narrative generation engine as in MEDCIN®.

   • MEDCIN® provides tools for building forms, narrative generation, and intelligent prompting.  SNOMED® has no native tools.